FR3099332A1 - Procédé et dispositif de contrôle de la congestion dans un réseau maillé - Google Patents

Procédé et dispositif de contrôle de la congestion dans un réseau maillé Download PDF

Info

Publication number
FR3099332A1
FR3099332A1 FR1908443A FR1908443A FR3099332A1 FR 3099332 A1 FR3099332 A1 FR 3099332A1 FR 1908443 A FR1908443 A FR 1908443A FR 1908443 A FR1908443 A FR 1908443A FR 3099332 A1 FR3099332 A1 FR 3099332A1
Authority
FR
France
Prior art keywords
node
congestion
congestion information
block
network
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR1908443A
Other languages
English (en)
Other versions
FR3099332B1 (fr
Inventor
Moussa ABOUBAKAR
Mounir Kellil
Pierre Roux
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Commissariat a lEnergie Atomique et aux Energies Alternatives CEA
Original Assignee
Commissariat a lEnergie Atomique CEA
Commissariat a lEnergie Atomique et aux Energies Alternatives CEA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Commissariat a lEnergie Atomique CEA, Commissariat a lEnergie Atomique et aux Energies Alternatives CEA filed Critical Commissariat a lEnergie Atomique CEA
Priority to FR1908443A priority Critical patent/FR3099332B1/fr
Publication of FR3099332A1 publication Critical patent/FR3099332A1/fr
Application granted granted Critical
Publication of FR3099332B1 publication Critical patent/FR3099332B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/11—Identifying congestion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/31—Flow control; Congestion control by tagging of packets, e.g. using discard eligibility [DE] bits
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/12—Shortest path evaluation
    • H04L45/125—Shortest path evaluation based on throughput or bandwidth
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/28—Routing or path finding of packets in data switching networks using route fault recovery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/021—Traffic management, e.g. flow control or congestion control in wireless networks with changing topologies, e.g. ad-hoc networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0284—Traffic management, e.g. flow control or congestion control detecting congestion or overload during communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/18—Self-organising networks, e.g. ad-hoc networks or sensor networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L’invention concerne un dispositif et un procédé de contrôle de la congestion dans un réseau maillé. Le procédé mis en œuvre par ordinateur permet de 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 nœud émetteur et un nœud récepteur, et permet de recevoir par le nœud récepteur un message IP ; de déterminer si le message IP contient un bloc d’informations de congestion (BIC) ; si oui, de déterminer l’adresse source du nœud émetteur du message IP ; et d’analyser le bloc d’informations de congestion pour identifier tous les nœuds de congestion sur le chemin de routage du message IP entre le nœud émetteur et le nœud récepteur. Figure pour l’abrégé : Fig.3a. …..

Description

Procédé et dispositif de contrôle de la congestion dans un réseau maillé
L’invention se situe dans 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é.
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.
Le 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.
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/sortie. 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.
Des solutions de gestion de la congestion dans les réseaux existent. Ainsi, par exemple :
La demande de brevet KR100865722B1, propose une méthode de notification explicite d’un état de congestion au niveau d’un nœud pour les réseaux de capteurs sans fil. Cette méthode permet de détecter et localiser le nœud congestionné par le « sink » (gateway). Dans cette méthode, un champ est utilisé pour marquer l’identifiant du nœud en situation de congestion et un autre champ pour inclure une notification explicite de la congestion. L’inconvénient est que l’identifiant du nœud congestionné est automatiquement transmis avec l’information de congestion, ce qui impacte le volume de trafic dans le réseau.
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 nœud é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 invention n’offre pas de moyen d’identification du/des nœud (s) congestionnés afin de prendre une décision de reconfiguration centrale du réseau.
Le brevet US5457687 propose une méthode pour le contrôle de la congestion dans les réseaux ATM (« Asynchronous Transfer Mode »). Un nœud 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 nœud différent. De plus, l’identifiant du nœud congestionné est indiqué lors de l’envoi de l’information de congestion, ce qui impacte le volume de trafic dans le réseau.
Dans la demande de brevet US 20110170410A1, la congestion est indiquée par le nœud 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 nœud é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 nœud congestionné est indiqué lors de l’envoi de l’information de congestion, ce qui impacte le volume de trafic dans le réseau.
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 flag CE (« Congestion Experienced »). L’inconvénient de cette méthode est qu’elle n’offre pas de moyen d’identification du/des nœud (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.
La demande de brevet US 20060176810 A1 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 nœud 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 nœuds en situation de congestion, et n’offre pas de possibilité d’envoi unique de plusieurs informations de congestion.
Les auteurs de l’article « ESRT : Event-to-Sink Reliable Transport in Wireless Sensor Networks », Yogesh Sankarasubramaniam, Özgür B. Akan et Ian F. Akyildiz in Broadband & Wireless Networking Laboratory, School of Electrical & Computer Engineering, Georgia Institute 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 nœud 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 nœuds congestionnés.
Les auteurs de l’article « ECODA: Enhanced Congestion Detection and Avoidance for Multiple Class of Traffic in Sensor », 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 base de deux valeurs seuils pour le registre d’entrée/sortie du trafic. Ces deux valeurs seuils découpent donc le buffer en trois parties (“accept state”, “filter state” et “reject state), afin de pouvoir accepter ou refuser des paquets. Dans cette approche, chaque nœud du réseau surveille l’état de son registre et informe les autres nœuds 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 nœuds congestionnés.
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 nœuds voisins de son état de congestion afin que ces nœuds 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 nœud) et elle n’offre pas de possibilité d’envoi unique de plusieurs informations de congestion, ni celle de ne pas indiquer les identifiants des nœuds congestionnés.
Les auteurs de l’article « CCRPM : Centralized Congestion Control Routing Protocol » Yao Yukun, Liu Jiangbing, Xu Dongliang, Ren Zhi 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 nœuds ‘fils’ d’un nœud congestionné de pouvoir prendre un nouveau parent moins congestionné. Dans cette solution, le nœud 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 nœuds sur un même chemin de routage vers un point central (par exemple, le nœud RPL root), d’un envoi unique de plusieurs informations de congestion, ni celle de ne pas indiquer les identifiants des nœuds congestionnés.
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.
La présente invention permet de pallier les inconvénients des approches connues et de répondre aux besoins précités.
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 nœuds sur un même chemin de routage. Sur la base 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 nœuds ayant rapporté une information de congestion et si nécessaire, procéder à la reconfiguration du réseau.
L’invention permet à un ensemble de nœuds sur un chemin de routage d’un réseau maillé de remonter vers un contrôleur du réseau (par exemple un nœud 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é.
Avantageusement, l’agrégation des informations de congestion des nœuds 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 nœud est agrégée dans un bloc d’informations de congestion (BIC) sans inclure l’identifiant du nœud. Le BIC va contenir les informations de congestion de l’ensemble des nœuds 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 nœud désirant y inclure son information de congestion.
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 nœud correspondant considéré.
Dans un mode de réalisation, la 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 nœud correspondant considéré.
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.
Dans un mode de réalisation, un nœud rapporte un état de congestion en remplissant le BIC avec une valeur booléenne égale à ‘vrai’ ou à ‘1’.
A réception d’un BIC, le contrôleur du réseau peut déterminer l’association {information de congestion, identifiant du nœud} 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 nœud qui a envoyé une information de congestion, sur la base 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.
Une fois les nœuds 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 nœuds concernés par la congestion
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 nœuds congestionnés par le contrôleur du réseau, sans pour autant que leur identifiant ne soit transmis avec l’information de congestion.
La présente invention trouvera de nombreux domaines d’application et en particulier celui de l’Internet 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.
Ainsi l’invention est applicable au contexte de l’industrie du futur, le bâtiment intelligent, 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 nœuds congestionnés.
Pour obtenir les résultats recherchés, il est proposé un procédé mis en œuvre 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 nœud émetteur et un nœud récepteur, le procédé comprenant les étapes de :
- recevoir par le nœud 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 nœud émetteur du message IP ; et
- analyser le bloc d’informations de congestion pour identifier tous les nœuds de congestion sur le chemin de routage du message IP entre le nœud émetteur et le nœud récepteur.
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 nœud émetteur du message IP consiste à identifier dans le champ d’entête du message IP, l’adresse source du nœud émetteur.
- l’étape d’analyser le bloc d’informations de congestion comprend les étapes de :
- vérifier si l’adresse source du nœud émetteur du message IP est présente dans une table de routage du nœud 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 nœud 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 nœud émetteur du message IP.
- le procédé comprend de plus une étape d’ajouter l’adresse dudit au moins un nœud en dépassement de seuil à une liste d’exclusion de nœuds en dépassement de seuil.
- le procédé comprend de plus une étape de reconfigurer le réseau en excluant ledit au moins un nœud en dépassement de seuil.
- le bloc d’informations de congestion est généré par l’un des nœuds du chemin de routage entre le nœud émetteur du message IP et le nœud récepteur, ledit nœud 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 nœud récepteur contient de plus des informations de congestion ajoutées par au moins un nœud intermédiaire sur le chemin de routage entre le nœud qui a généré le bloc d’informations de congestion et le nœud récepteur, ledit nœud 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 nœud qui a généré le bloc d’informations de congestion et le nœud récepteur.
- ledit au moins un nœud intermédiaire est configuré pour envoyer ledit bloc d’informations de congestion vers un prochain nœud dudit chemin de routage.
- 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 nœud correspondant.
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.
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 œuvre les étapes du procédé revendiqué de contrôle de congestion du réseau.
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é.
L’invention vise de plus un réseau maillé comprenant au moins un contrôleur réseau tel que revendiqué et une pluralité de nœuds configurés tels que revendiqués.
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 :
montre un exemple d’implémentation du dispositif de l’invention dans un contexte de ville intelligente ;
illustre un exemple de réseau maillé pour mettre en œuvre le procédé de l’invention dans un mode de réalisation ;
et
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 ;
montre un enchainement d’étapes pour générer un premier bloc d’informations de congestion (BIC) selon un mode de réalisation du procédé de l’invention ;
montre un enchainement d’étapes pour mettre à jour un BIC pour un nœud intermédiaire, selon un mode de réalisation du procédé de l’invention ;
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 ;
montre une représentation d’une table de routage (700) et d’une table de correspondance (720) dans un mode de réalisation du procédé de l’invention ;
montre un exemple d’architecture d’un nœud d’un réseau permettant de mettre en œuvre le procédé de l’invention selon un mode de réalisation ; et
montre un exemple d’architecture d’un nœud contrôleur de réseau permettant de mettre en œuvre le procédé de l’invention selon un mode de réalisation.
La figure 1 montre un exemple d’implémentation du dispositif de l’invention dans un contexte de ville intelligente.
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 (TIC) et divers dispositifs physiques connectés à un réseau de capteurs tel l'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.
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.
Les réseaux peuvent mettre en œuvre 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, Bluetooth, 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.
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.
La figure 2 illustre un exemple de réseau maillé (200) permettant de mettre en œuvre 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 nœuds ayant une puissance limitée, une faible mémoire, une 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, Bluetooth, Low Power WiFi, ou CPL).
L’IETF (« Internet Engineering Task Force »), l’organisme en charge de la standardisation 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 Networks ») qui permet de construire une topologie de routage sur les réseaux contraints et de définir la manière de transporter des datagrammes IPv6 sur des liens à bas débit et à faible consommation.
Les réseaux de capteurs peuvent être construits selon différents types d’architecture logique comme la topologie en maillage ou « mesh » 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 nœuds (202) convergeant vers un nœud racine (204). Dans la littérature, un nœud à l’extrémité d’un réseau structuré en arbre peut être désigné comme un nœud feuille. Dans la suite de la description, le terme nœud sera indifféremment utilisé pour désigner un nœud quelconque du réseau qu’il soit un nœud feuille ou non. Le terme « nœud » 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 nœud racine (204) peut jouer le rôle de contrôleur du réseau, les nœuds (N1 à N21) étant les capteurs du réseau maillé RPL. Dans ce type de réseau, les données peuvent transiter dans un sens ascendant des nœuds vers la racine (par exemple pour des remontées de températures, d’alarmes, etc., émanant de nœuds feuilles et/ou de nœuds sur le chemin vers la racine ) ou bien les données peuvent transiter dans un sens descendant du nœud racine vers les nœuds (par exemple pour des requêtes ou des commandes émanant de la racine vers des nœuds feuilles et/ou vers des nœuds sur le chemin entre la racine et des nœuds feuilles).
Selon le principe de l’invention, un nœud (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 nœud du réseau à l’origine de cette information et en lui permettant de décider d’une reconfiguration du réseau maillé ou non.
Dans un mode de réalisation de l’invention, l’information de congestion d’un nœud, peut représenter le taux d’occupation de la mémoire d’entrée/sortie de ce nœud. 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 nœud.
Dans un mode de réalisation préféré, l’information de congestion transmise par tout nœud 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 nœud du réseau donné vers le nœud racine, chaque nœud 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 nœud racine (i.e. le contrôleur réseau).
Lorsque le nœud 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 nœud 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 nœud 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) nœud(s) ayant rapporté un dépassement de la valeur seuil de congestion.
Les figures 3a et 3b 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 Area Networks »), la présence d’un bloc d’informations de congestion (BIC) selon deux modes de réalisation de l’invention. 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 (nœud émetteur).
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 nœuds 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 nœud source du paquet contenant le BIC. Elle peut être remplie par un nœud congestionné ou non congestionné.
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 d’emplacements occupés.
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 nœud vers la racine, la première information de congestion peut être générée par n’importe quel nœud du chemin, mis à part le nœud racine si le contrôleur réseau est co-localisé à la racine. Si le contrôleur réseau est découplé du nœud racine, celui-ci peut avoir son information de congestion dans le bloc au même titre que les autres nœuds du réseau.
La première étape du procédé est la génération d’un BIC (402) pour un nœud ‘i’ du réseau. La génération d’un BIC au niveau d’un nœud ‘i’ peut être initiée soit par le contrôleur du réseau soit par le nœud ‘i’. Dans le cas d’une initiation par le contrôleur du réseau, celui-ci envoie une demande explicite au nœud ‘i’ l’invitant à générer le BIC.
Le contrôleur du réseau peut initier la génération d’un BIC au niveau d’un nœud ‘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 base de modèles prédictifs de congestion ou de pannes dans le réseau, etc.). De manière alternative, un nœud ‘i’ peut initier la génération d’un BIC périodiquement ou sur évènement prédit ou non.
Quand le bloc d’informations de congestion est généré par l’un des nœuds du chemin de routage entre le nœud émetteur du message IP et le nœud racine récepteur, le nœud 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 nœud ‘i’, puis de le comparer (406) à une valeur seuil critique de congestion, qui a été préétablie pour ce nœud. 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.
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.
Dans une variante de réalisation, un nœud peut ne mettre aucune entrée dans un BIC s’il reçoit un paquet avec un BIC déjà initialisé avec la valeur binaire correspondant à sa situation de congestion ou non-congestion.
Dans une étape suivante (414), le procédé se poursuit par l’envoi du BIC 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 nœud 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 paquet IP ;
- la génération d’un paquet IP pour l’envoi du BIC : dans ce cas, le nœud 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 nœud.
La figure 5 illustre les étapes (500) du procédé de remplissage d’un BIC applicable à un nœud ‘parent’ qui reçoit un BIC existant d’un nœud ‘fils’. Le nœud 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 nœud. 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 nœud 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 nœud 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.
Revenant sur l’étape de remplissage du BIC (412 ou 512), le procédé permet de rechercher à quelle position l’information de congestion associée à un nœud 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 nœud 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 nœud feuille. Ainsi, en considérant par exemple la branche ‘Racine-N20-N16-N7’ de la figure 2, les nœuds N20, N16, et N7 auront respectivement les index 1, 2, et 3, et les nœuds N20, N16 et N7 porteront leur valeur binaire respective aux emplacements correspondants, comme illustré par la table suivante :
Dans un mode de réalisation où un nœud ‘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 nœud sur le chemin allant du nœud ‘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 nœuds N7, N16 et N20, où le premier nœud N7 crée le BIC avec une première valeur ‘0’, puis le nœud suivant N16, ajoute sa valeur de BIC ‘1’ et le nœud suivant N20 ajoute sa valeur de BIC ‘0’ à la fin :
Dans un mode de réalisation préférentiel, tous les nœuds 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 nœuds sur le chemin allant du nœud 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 nœud 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 nœud générateur du BIC et est alors ignorée par le contrôleur du réseau.
La figure 6 montre un enchainement 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 nœud racine. Dans l’exemple du réseau en arbre RPL, il s’agit de tous les chemins entre les nœuds feuilles et le nœud racine, et le nœud racine stocke en mémoire tous les chemins de routage allant des nœuds feuilles vers le nœud racine.
Le procédé débute quand le contrôleur réseau reçoit (602) un paquet contenant un BIC d’un nœud 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 nœuds sur le chemin entre l’adresse source et le contrôleur qui ont rapporté 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 nœud source du message, l’adresse du nœud en dépassement de seuil.
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 nœud d’index 2 rapporte une information de congestion. En effet, sur la base 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 nœuds (N20, N16, N7), le procédé permet de déterminer que l’adresse du nœud d’index 2 est celle du nœud N16 : @N16.
La figure 7 illustre une représentation d’une table de routage (700) et d’une table de correspondance (720) (index BIC, adresse Nœud) générée de manière temporaire à partir de la table de correspondance pour un nœud 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èmebond est associée à l’index ‘3’, la colonne (712) du 2èmebond est associée à l’index ‘2’ et la colonne (714) du 1erbond 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).
Revenant au procédé de la figure 6, après avoir déterminé l’adresse d’un nœud indiquant une valeur de dépassement de seuil (étape 610), le procédé permet d’ajouter (612) l’adresse du nœud en dépassement de seuil à une liste d’exclusion de nœuds 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.
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 nœuds ayant rapporté un dépassement.
En cas de changement dans un chemin du réseau RPL, les nœuds 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-by-hop » de l’entête d’extension IPv6, par la valeur ‘rang’ (« rank ») du message ‘DIO’ (« DODAG Information Object ») 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.
La figure 8 illustre un exemple d’architecture d’un nœud (800) d’un réseau permettant de mettre en œuvre le procédé de l’invention selon différents modes de réalisation. Dans un mode de réalisation particulier, un tel nœud 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).
Les interfaces d’Entrée/Sortie (808) permettent de connecter le nœud (800) au réseau auquel il appartient afin de transmettre vers et/ou recevoir des messages d’autres nœuds et/ou d’un contrôleur de réseau.
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.
Les différents programmes comprennent au moins un programme lié à un processus de routage (812) des messages entre les nœuds 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 l’invention, tels que décrits par les figures 4 et 5.
La figure 9 illustre un exemple d’architecture d’un nœud contrôleur de réseau (900) permettant de mettre en œuvre 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 nœuds ayant une architecture selon la figure 8.
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/Sortie (906), et une mémoire (910) interconnectée aux autres composants par un bus (912).
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 nœuds (800) du réseau.
La mémoire (910) est configurée pour stocker des instructions de code de différents programmes (916, 918) exécutables par le(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.
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.
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.
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.

Claims (15)

  1. Un procédé mis en œuvre 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 nœud émetteur et un nœud récepteur, le procédé comprenant les étapes suivantes :
    - recevoir par le nœud 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 nœud émetteur du message IP ; et
    - analyser le bloc d’informations de congestion pour identifier tous les nœuds de congestion sur le chemin de routage du message IP entre le nœud émetteur et le nœud récepteur.
  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.
  3. Le procédé selon la revendication 1 ou 2 dans lequel l’étape de déterminer l’adresse source du nœud émetteur du message IP consiste à identifier dans le champ d’entête du message IP, l’adresse source du nœud émetteur.
  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 nœud émetteur du message IP est présente dans une table de routage du nœud 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 nœud 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 nœud émetteur du message IP.
  5. Le procédé selon la revendication 4 comprenant de plus une étape d’ajouter l’adresse dudit au moins un nœud en dépassement de seuil à une liste d’exclusion de nœuds en dépassement de seuil.
  6. Le procédé selon la revendication 5 comprenant de plus une étape de reconfigurer le réseau en excluant ledit au moins un nœud en dépassement de seuil.
  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 nœuds du chemin de routage entre le nœud émetteur du message IP et le nœud récepteur, ledit nœud 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.
  8. Le procédé selon la revendication 7 dans lequel le bloc d’informations de congestion reçu par le nœud récepteur contient de plus des informations de congestion ajoutées par au moins un nœud intermédiaire sur le chemin de routage entre le nœud qui a généré le bloc d’informations de congestion et le nœud récepteur, ledit nœud 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 nœud qui a généré le bloc d’informations de congestion et le nœud récepteur.
  9. Le procédé selon la revendication 8 dans lequel ledit au moins un nœud intermédiaire est configuré pour envoyer ledit bloc d’informations de congestion vers un prochain nœud dudit chemin de routage.
  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.
  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 nœud correspondant.
  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.
  13. Un dispositif pour contrôler la congestion d’un réseau maillé, le dispositif comprenant des moyens pour mettre en œuvre les étapes du procédé de contrôle de congestion du réseau selon l’une quelconque des revendications 1 à 11.
  14. Un contrôleur réseau d’un réseau maillé de type « Low-Power and Lossy Network » comprenant un dispositif selon la revendication 13.
  15. Un réseau maillé comprenant au moins un contrôleur réseau selon la revendication 14 et une pluralité de nœuds configurés selon l’une quelconque des revendications 7 à 9.
FR1908443A 2019-07-25 2019-07-25 Procédé et dispositif de contrôle de la congestion dans un réseau maillé Active FR3099332B1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR1908443A FR3099332B1 (fr) 2019-07-25 2019-07-25 Procédé et dispositif de contrôle de la congestion dans un réseau maillé

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1908443A FR3099332B1 (fr) 2019-07-25 2019-07-25 Procédé et dispositif de contrôle de la congestion dans un réseau maillé
FR1908443 2019-07-25

Publications (2)

Publication Number Publication Date
FR3099332A1 true FR3099332A1 (fr) 2021-01-29
FR3099332B1 FR3099332B1 (fr) 2022-06-17

Family

ID=68733273

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1908443A Active FR3099332B1 (fr) 2019-07-25 2019-07-25 Procédé et dispositif de contrôle de la congestion dans un réseau maillé

Country Status (1)

Country Link
FR (1) FR3099332B1 (fr)

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5457687A (en) 1993-09-02 1995-10-10 Network Equipment Technologies, Inc. Method and apparatus for backward explicit congestion notification (BECN) in an ATM network
US6741555B1 (en) 2000-06-14 2004-05-25 Nokia Internet Communictions Inc. Enhancement of explicit congestion notification (ECN) for wireless network applications
US20060176810A1 (en) 2005-02-09 2006-08-10 Nokia Corporation Congestion notification in 3G radio access
EP1810463A1 (fr) * 2004-11-12 2007-07-25 TELEFONAKTIEBOLAGET LM ERICSSON (publ) Gestion de congestion dans un domaine de reseau a commutation par paquets
KR100865722B1 (ko) 2007-06-25 2008-10-28 순천대학교 산학협력단 유비쿼터스 센서 네트워크에서 이씨엔 비트를 이용한혼잡제어 방법
US20110170408A1 (en) 2010-01-11 2011-07-14 Research In Motion Limited Congestion level indication with explicit congestion notification in communication systems
US20110170410A1 (en) 2010-01-11 2011-07-14 Research In Motion Limited Explicit congestion notification based rate adaptation using binary marking in communication systems
US20190020563A1 (en) * 2017-07-13 2019-01-17 Avago Technologies General Ip (Singapore) Pte. Ltd Apparatus and method for performance measurements using local timestamp and sequency number insertion at intermediate nodes

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5457687A (en) 1993-09-02 1995-10-10 Network Equipment Technologies, Inc. Method and apparatus for backward explicit congestion notification (BECN) in an ATM network
US6741555B1 (en) 2000-06-14 2004-05-25 Nokia Internet Communictions Inc. Enhancement of explicit congestion notification (ECN) for wireless network applications
EP1810463A1 (fr) * 2004-11-12 2007-07-25 TELEFONAKTIEBOLAGET LM ERICSSON (publ) Gestion de congestion dans un domaine de reseau a commutation par paquets
US20060176810A1 (en) 2005-02-09 2006-08-10 Nokia Corporation Congestion notification in 3G radio access
KR100865722B1 (ko) 2007-06-25 2008-10-28 순천대학교 산학협력단 유비쿼터스 센서 네트워크에서 이씨엔 비트를 이용한혼잡제어 방법
US20110170408A1 (en) 2010-01-11 2011-07-14 Research In Motion Limited Congestion level indication with explicit congestion notification in communication systems
US20110170410A1 (en) 2010-01-11 2011-07-14 Research In Motion Limited Explicit congestion notification based rate adaptation using binary marking in communication systems
US20190020563A1 (en) * 2017-07-13 2019-01-17 Avago Technologies General Ip (Singapore) Pte. Ltd Apparatus and method for performance measurements using local timestamp and sequency number insertion at intermediate nodes

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
JOSEPH AUXILIUS JUDEV. C. DINIESH: "DACC: Dynamic Agile Congestion Control Scheme for Effective Multiple Traffic Wireless Sensor Networks", INTERNATIONAL CONFÉRENCE ON WIRELESS COMMUNICATIONS, SIGNAL PROCESSING AND NETWORKING (WISPNET, 2017
LI QIANG TAOFENG QI YU: "ECODA: Enhanced Congestion Détection and Avoidance for Multiple Class of Traffic in Sensor", IEEE TRANSACTIONS ON CONSUMER ELECTRONICS, vol. 56, no. 3, August 2010 (2010-08-01)
TIANKUN LI ET AL: "The Research on the Application of an Improved Algorithm in the Zigbee Network", WIRELESS COMMUNICATIONS, NETWORKING AND MOBILE COMPUTING, 2009. WICOM '09. 5TH INTERNATIONAL CONFERENCE ON, IEEE, PISCATAWAY, NJ, USA, 24 September 2009 (2009-09-24), pages 1 - 4, XP031554700, ISBN: 978-1-4244-3692-7 *
YAO YUKUNLIU JIANGBINGXU DONGLIANGREN ZHIHU QING: "CCRPM : Centralized Congestion Control Routing Protocol", THE JOURNAL OF CHINA UNIVERSITIES OF POSTS AND TÉLÉCOMMUNICATIONS, 12 December 2017 (2017-12-12)
YOGESH SANKARASUBRAMANIAMOZGÜR B. AKANIAN F. AKYILDIZ: "Broadband & Wireless Networking Laboratory", 2003, SCHOOL OF ELECTRICAL & COMPUTER ENGINEERING, article "ESRT : Event-to-Sink Reliable Transport in Wireless Sensor Networks"

Also Published As

Publication number Publication date
FR3099332B1 (fr) 2022-06-17

Similar Documents

Publication Publication Date Title
US10097379B2 (en) Managing communication congestion for internet of things devices
US10057150B2 (en) Managing communication congestion for internet of things devices
US9923821B2 (en) Managing communication congestion for internet of things devices
FR3012895A1 (fr) Procede et programme d'ordinateur pour l'execution deportee de taches informatiques d'un equipement sans fil
Sakellari The cognitive packet network: A survey
EP3189636B1 (fr) Procédé de surveillance et d'alerte de configuration de routage dans un cluster comprenant des liens de communication statiques et programme d'ordinateur mettant en oeuvre ce procédé
CN109219942B (zh) 控制消息模式的方法及装置
CN109639648A (zh) 一种基于采集数据异常的采集策略生成方法及系统
EP1958398A1 (fr) Procede de reconstruction d'un reseau ad hoc et des n uds du reseau correspondant
US10764219B2 (en) Message schema control
CN103312607A (zh) 一种传输路径选择方法及装置
Mekala et al. Equilibrium transmission bi-level energy efficient node selection approach for internet of things
Sheltami et al. A publish/subscribe middleware cost in wireless sensor networks: A review and case study
FR3099332A1 (fr) Procédé et dispositif de contrôle de la congestion dans un réseau maillé
Waheed et al. Traffic queuing management in the Internet of Things: An optimized RED algorithm based approach
EP3953717B1 (fr) Detection de fraude a la consommation energetique dans un service de distribution electrique
EP3900386A1 (fr) Procédé de gestion d'un dispositif de communication de données et dispositif pour la mise en oeuvre du procédé
Yang et al. Topology tomography in wireless sensor networks based on data aggregation
Mershad A framework for controlling the operations of sensor networks from the cloud
EP3811655A1 (fr) Procédé d'évaluation de la consommation d'énergie d'une tranche service dans un réseau de communications
EP4020926B1 (fr) Procédé de routage pour router un flux élastique dans un réseau de transport
Kouhdaragh et al. A reliable, secure, and energy efficient smart grid node allocation algorithm for heterogeneous network scenarios
CN118138479A (zh) 一种模型训练方法、系统、通信实体及存储介质
EP2850779B1 (fr) Système de supervision, procédé et programme d'ordinateur correspondant
Kriouile Asymptotically Optimal Scheduling Schemes for Large Networks

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20210129

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 5

PLFP Fee payment

Year of fee payment: 6