FR3081277A1 - Procede de gestion des priorites de traitement de paquets de donnees, dans un environnement linux - Google Patents

Procede de gestion des priorites de traitement de paquets de donnees, dans un environnement linux Download PDF

Info

Publication number
FR3081277A1
FR3081277A1 FR1858048A FR1858048A FR3081277A1 FR 3081277 A1 FR3081277 A1 FR 3081277A1 FR 1858048 A FR1858048 A FR 1858048A FR 1858048 A FR1858048 A FR 1858048A FR 3081277 A1 FR3081277 A1 FR 3081277A1
Authority
FR
France
Prior art keywords
data
interface
priority
queue
data packets
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
FR1858048A
Other languages
English (en)
Other versions
FR3081277B1 (fr
Inventor
Djelal Raouf
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.)
Continental Automotive GmbH
Continental Automotive France SAS
Original Assignee
Continental Automotive GmbH
Continental Automotive France SAS
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 Continental Automotive GmbH, Continental Automotive France SAS filed Critical Continental Automotive GmbH
Priority to FR1858048A priority Critical patent/FR3081277B1/fr
Publication of FR3081277A1 publication Critical patent/FR3081277A1/fr
Application granted granted Critical
Publication of FR3081277B1 publication Critical patent/FR3081277B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/50Queue scheduling
    • H04L47/62Queue scheduling characterised by scheduling criteria
    • H04L47/6215Individual queue per QOS, rate or priority
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/50Queue scheduling
    • H04L47/62Queue scheduling characterised by scheduling criteria
    • H04L47/6285Provisions for avoiding starvation of low priority queues

Abstract

La présente invention a pour objet un procédé de gestion des priorités dans un calculateur exécutant un système d'exploitation Linux, ledit système comprenant une première interface de données (Rmnet0), prioritaire, et une deuxième interface de données (Rmnet1), lesdites interfaces de données (Rmnet0, Rmnet1) recevant (11, 21) des paquets de données, ainsi qu'une interface radio physique unique, ledit procédé comprenant : • la mise en œuvre d'une règle de trafic, attachée aux interfaces de données (Rmnet0, Rmnet1), pour rediriger (12, 22) les paquets de données vers une pseudo-interface (IFB) de type bloc de flux intermédiaire, • la mise en œuvre d'une règle de file d'attente, attachée la pseudo-interface (IFB), de telle sorte que les paquets de données issus de la première interface de données (Rmnet0) sont classés dans une file d'attente présentant une priorité supérieure, • la réémission (13, 23) des paquets de données par la pseudo-interface (IFB) à destination de leur interface de données d'origine respective (RMnet0, Rmnet1), en fonction de la règle de file d'attente, • la transmission (14, 24) des paquets de données réémis à l'interface radio physique, en vue de leur émission vers l'extérieur.

Description

L’invention concerne la gestion des priorités de traitement de paquets de données émis depuis deux interfaces réseaux en vue d’être transmis via une seule interface radio physique, dans un environnement Linux.
En particulier, dans un boîtier télématique embarqué dans un véhicule, ledit boîtier télématique peut comprendre un unique modem cellulaire, autrement dit une seule interface radio physique apte à émettre des données vers l’extérieur, et deux noms de point d’accès, en anglais « Access Point Names », désignés sous l’abrégé APN bien connu de l’homme du métier.
Les véhicules actuels comprennent généralement une unité de contrôle télématique, ou boîtier télématique, ou encore boîtier TCU, embarquant un modem cellulaire, pour connecter lesdits véhicules à une liaison de données par l’intermédiaire d’un réseau de télécommunication mobile.
Comme cela est connu, un tel service de télécommunication mobile permet à un abonné de bénéficier d’une liaison téléphonique et ou de données par l’intermédiaire d’un réseau de télécommunication mobile, par exemple de type GSM (pour « Global System for Mobile Communication » selon l’acronyme anglais signifiant « système global de communication mobile », technologie également désignée sous l’appellation 2G), UMTS (pour « Universal Mobile Telecommunications System » selon l’acronyme anglais signifiant « système de télécommunications mobile universel », technologie également désignée sous l’appellation 3G), LTE (pour «Long Term Evolution» selon l’acronyme anglais signifiant « évolution à long terme », technologie également désignée sous l’appellation 4G) ou CDMA (pour « Code Division Multiple Access » selon l’acronyme anglais signifiant « accès multiple par répartition en code »).
Comme cela est connu également, l’APN est un identifiant qui permet à un utilisateur d’un service de télécommunication mobile de se connecter au réseau de télécommunication correspondant, notamment pour accéder à l’internet, en identifiant la passerelle d’interconnexion entre le réseau de paquets de données mobile émis et les réseaux externes, ladite passerelle étant désignée « Gateway GPRS Support Node » (GGSN) en 2G et 3G, et « Packet Data Network Gateway » (P-GW) en 4G, qu'il souhaite utiliser.
Dans le contexte d’un boîtier TCU comprenant un unique modem cellulaire et deux APN, l’un des APN peut être dédié à des applications prioritaires, par exemple pour émettre des données télématiques sur l’état du véhicule, l’autre APN étant dédié à des applications secondaires, par exemple pour émettre des données relatives à des applications de divertissement.
La présente invention se situe dans le contexte où, dans un environnement Linux, c’est-à-dire dans un calculateur exécutant un système d’exploitation Linux, deux interfaces de données réseaux émettent en parallèle des paquets IP, pour « Internet Protocol » en anglais, destinés à être émis via une unique interface radio physique, à destination de l’extérieur.
Ainsi, un véhicule peut être équipé d’un modem cellulaire permettant la connexion à un réseau de télécommunication mobile par l’intermédiaire des informations relatives à un abonnement souscrit auprès d’un opérateur de télécommunication mobile.
Dans certains cas, l’abonnement souscrit auprès de l’opérateur de télécommunication mobile permet de créer deux liaisons de données au réseau de télécommunication sans fil, via deux APN.
Typiquement, une première liaison de données est dédiée à des applications télématiques, tandis qu’une deuxième liaison de données est dédiée à des applications d’info-divertissement.
Sous Linux, ces deux liaisons de données sont vues comme deux interfaces réseaux distinctes, comme le seraient deux interfaces Ethernet physiques par exemple.
Seulement, pour transmettre les paquets IP issus de ces deux interfaces de données, le boîtier TCU ne dispose généralement que d’une interface radio physique unique.
Or la liaison de données télématique doit être prioritaire devant la liaison de données d’info-divertissement.
Dans l’environnent Linux, il est connu de recourir à un service de contrôle du trafic, également désigné TC pour « Traffic Control » en anglais. Le service TC permet de définir des profils du trafic réseau, en matière de bande passante dédiée et de redirection notamment, mais uniquement pour une interface de données considérée.
Le service TC ne peut cependant pas prioriser nativement une interface de données par rapport à une autre.
Il existe donc un besoin pour un procédé permettant de gérer la priorisation des paquets IP issus d’une interface de données par rapport à une autre, en vue de leur émission prioritaire par l’unique interface physique.
A cette fin, la présente invention propose de rediriger, au moyen d’une règle définie grâce au service TC, les paquets IP issus de chaque interface de données vers une pseudo-interface IFB commune, pour « intermediate flow block » en anglais signifiant bloc d’écoulement intermédiaire, ladite pseudo-interface IFB étant configurée au moyen d’un paramètre de catégorisation de trafic, autrement désigné règle de file d’attente, permettant de prioriser les paquets IP issus d’une interface de données prédéfinie comme prioritaire devant l’autre interface de données.
Ainsi, plus précisément, l’invention a pour objet un procédé de gestion des priorités dans un calculateur exécutant un système d’exploitation Linux, ledit système comprenant une première interface de données recevant des paquets de données destinés à être traités de façon prioritaire et une deuxième interface de données recevant des paquets de données destinés à être traités de façon non prioritaire, ainsi qu’une interface physique unique configurée pour émettre successivement des paquets de données provenant desdites première et deuxième interfaces de données, ledit procédé comprenant :
• la mise en œuvre d’une règle de trafic, attachée aux première et deuxième interfaces de données, pour rediriger les paquets de données issus des première et deuxième interfaces de données vers une pseudo-interface de type bloc de flux intermédiaire, • la mise en œuvre d’un règle de file d’attente, attachée la pseudo-interface, de telle sorte que les paquets de données issus de la première interface de données sont classés dans une file d’attente présentant une première priorité et que les paquets de données issus de la deuxième interface de données sont classés dans une file d’attente présentant une deuxième priorité, inférieure à la première priorité, • la réémission des paquets de données par la pseudo-interface à destination de leur interface de données d’origine respective, en fonction de la règle de file d’attente, les paquets de données de la file d’attente présentant la première priorité étant émis avant les paquets de données de la file d’attente présentant la deuxième priorité, • la transmission des paquets de données réémis à l’interface radio physique, en vue de leur émission vers l’extérieur.
Avantageusement, le procédé comprend une étape préalable d’initialisation des interfaces de données et de la pseudo-interface.
Selon un mode de réalisation, le procédé est destiné à être mis en œuvre dans une unité de contrôle télématique comprenant un premier et un deuxième noms de point d’accès, le premier nom de point d’accès étant dédié à des services télématiques et émettant des données définies comme prioritaires, le deuxième nom de point d’accès étant dédié à des services d’info-divertissement et émettant des données définies comme non prioritaires, les données émises sur le premier nom de point d’accès étant traitées par la première interface de données et les données émises sur le deuxième nom de point d’accès étant traitées par la deuxième interface de données.
Selon un mode de réalisation, le système comprend une troisième interface de données recevant des paquets de données devant être traités de façon non prioritaire, ledit procédé comprend :
• la mise en œuvre de la règle de trafic, également attachée aux première et deuxième interfaces de données, pour rediriger les paquets de données reçus par la troisième interface de données vers la pseudo-interface, • la mise en œuvre d’une règle de file d’attente, attachée la pseudo-interface, de telle sorte que les paquets de données issus de la troisième interface de données sont classés dans une file d’attente présentant une troisième priorité, inférieure à la deuxième priorité, • la réémission des paquets de données par la pseudo-interface à destination de leur interface de données d’origine respective, en fonction de la règle de file d’attente, les paquets de données de la file d’attente présentant la troisième priorité étant émis après les paquets de données de la file d’attente présentant la deuxième priorité, • la transmission des paquets de données réémis à l’interface radio physique, en vue de leur émission vers l’extérieur.
Selon un mode de réalisation, un ou plusieurs paquets de données de la file d’attente présentant la deuxième priorité sont réémis par la pseudo-interface, y compris si la file d’attente présentant la première priorité n’est pas vide, lorsqu’une durée prédéfinie est écoulée depuis la dernière réémission d’un paquet de données de ladite file d’attente présentant la troisième priorité.
Selon un mode de réalisation, un ou plusieurs paquets de données de la file d’attente présentant la troisième priorité sont réémis par la pseudo-interface, y compris si la file d’attente présentant la deuxième priorité n’est pas vide et y compris si la file d’attente présentant la première priorité n’est pas vide, lorsqu’une durée prédéfinie est écoulée depuis la dernière réémission d’un paquet de données de ladite file d’attente présentant la troisième priorité.
La figure 1 illustre un schéma représentant la mise en œuvre du procédé selon l’invention.
L'invention est envisagée principalement en vue d’une mise en œuvre dans un véhicule équipé d’un boîtier TCU comprenant deux noms de point d’accès, désignés APN comme cela a été indiqué précédemment, dont l’un doit être traité de façon prioritaire. La présente invention s’applique, en dehors d’un véhicule, dans tout contexte similaire où, dans un environnement Linux, deux interfaces de données produisent des paquets de données à émettre via une interface radio physique unique, les paquets de données issus de l’une de ces interfaces de données devant être émis de façon prioritaire.
Il est à noter cependant que le nombre d’APN peut être supérieur à deux. La présente invention couvre également ce cas de figure.
Il s’agit par exemple, comme exposé précédemment, d’émettre des paquets de données produits pour un premier APN dans un boîtier TCU de véhicule, dédié à des applications télématiques, avant d’émettre des paquets de données produits pour un deuxième APN dédié à des applications d’info-divertissement.
En référence à la figure 1, le procédé selon l’invention est mis en œuvre dans un environnement Linux dans lequel deux interfaces de données RmnetO et Rmnetl cherchent à transmettre des paquets de données, par exemple selon le protocole IP, en vue de leur émission vers l’extérieur via une interface radio physique unique.
Les interfaces de données RmnetO et Rmnetl reçoivent 11, 21 des données issues d’applications dédiées respectivement à des services télématiques et à des services d’info-divertissement.
Selon l’invention le service TC, pour «Traffic Control» en anglais, est configuré pour rediriger 12, 22 les paquets de données issus respectivement de la première interface de données RmnetO et de la deuxième interface de données Rmnetl vers la pseudo-interface IFB, pour « Intermediate Flow Block » en anglais.
La fonction de la pseudo-interface IFB est de réémettre 13, 23 tout paquet IP reçu vers l’interface de données émettrice du paquet de données correspondant.
Avant de réémettre les paquets de données reçus, ces derniers sont, au sein de la pseudo-interface IFB, catégorisés. A cette fin, une règle de file d’attente, désignée « queueing discipline » en anglais, est établie. Une telle règle de file d’attente est désignée « Qdisc » sous Linux.
De préférence, on recourt à la règle de file d’attente nommée PRIO dans un environnement Linux. Selon la règle de file d’attente PRIO, les paquets de données reçus par la pseudo-interface IFB sont classés en fonction de leur origine. Les paquets de données reçus de la première interface RmnetO, considérée pour cet exemple comme prioritaire, sont classés dans une file d’attente prioritaire Q1, correspondant typiquement à une classe 1 selon la règle de file d’attente PRIO appliquée.
De façon correspondante, les paquets de données reçus de la deuxième interface Rmnetl, considérée pour cet exemple comme non prioritaire, sont classés dans une file d’attente non prioritaire Q2, correspondant typiquement à une classe 2 selon la règle de file d’attente PRIO appliquée.
Conformément à la règle de file d’attente PRIO appliquée ici, les paquets de données de la file d’attente Q1 (classe 1) sont réémis 13 de façon prioritaire, vers leur interface de données d’origine, à savoir la première interface de données RmnetO.
Autrement dit, les paquets de données de la file d’attente Q2 (classe 2) ne sont réémis 23, selon un mode de réalisation, que si la file d’attente Q1 (classe 1) est vide.
Les paquets IP réémis par la pseudo-interface IFB sont ensuite transmis 14, 24 vers l’interface radio physique unique apte à les émettre vers l’extérieur, les paquets de données provenant de la première interface de données RmnetO étant par conséquent émis par ladite interface radio physique de façon prioritaire.
De cette façon, on a créé une règle de priorisation des paquets de données issus d’une interface de données prioritaire par rapport à une autre interface de données.
Comme expliqué précédemment, une application particulière envisagée se situe dans le contexte d’un boîtier TCU de véhicule comprenant deux APN, l’un étant dédié à des services télématiques et l’autre à des services d’info-divertissement.
L’APN dédié à des services télématiques est défini comme prioritaire et émet des paquets de données via la première interface de données RmnetO tandis que l’autre APN, dédié à des applications d’info-divertissement, émet des paquets de données non prioritaires via la deuxième interface de données Rmnetl.
Comme décrit ci-dessus en regard de la figure 1, les paquets de données passant par la première interface de données RmnetO sont traités de façon prioritaire par rapport aux paquets de données passant par la deuxième interface de données Rmnetl.
Il est à noter que des règles supplémentaires de file d’attente, ou « queueing discipline » en anglais, peuvent être introduites, en complément, pour optimiser encore la gestion de la priorisation d’une interface de données par rapport à une autre, notamment pour éviter toute saturation d’une file d’attente en classe 2 qui serait impossible à dépiler parce que des paquets de données seraient redirigés de façon continue dans la file d’attente en classe 1.
A cette fin, par exemple, un ou plusieurs paquets de données de la file d’attente Q2 sont réémis par la pseudo-interface IFB, même si la file d’attente Q1 n’est pas vide, lorsqu’une durée prédéfinie est écoulée depuis la dernière réémission d’un paquet de données de ladite file d’attente Q2.
Il est précisé, en outre, que la présente invention n’est pas limitée aux exemples décrits ci-dessus et est susceptible de variantes accessibles à l’homme de l’art. En particulier, la présente invention couvre également le cas où plus de deux APN sont présentes pour un unique modem cellulaire.
Dans ce cas, au moins une troisième interface de données est traitée avec une priorité différente de celle associée aux premier et deuxième interfaces de données. Par exemple, la troisième interface de données est associée à une priorité réduite, inférieure à celle de la deuxième interface de données. Dès lors, les paquets de données reçus par ladite troisième interface de données sont redirigés, comme ceux reçus par les première et deuxième interfaces de données RmnetO, Rmnetl, vers la pseudointerface IFB, et stockés dans une file d’attente présentant une priorité réduite, inférieure à celle de la file d’attente Q2 dans laquelle sont stockés les paquets de données issus de la deuxième interface de données Rmnetl. Les paquets de données stockés dans la file 5 d’attente de priorité réduite, issus de la troisième interface de données, sont réémis par la pseudo-interface IFB lorsque la file d’attente Q2 est vide.
Toutefois, selon un mode de réalisation, un ou plusieurs paquets de données de la file d’attente de priorité réduite sont réémis par la pseudo-interface IFB, même si la file d’attente Q2 n’est pas vide, voire même si la file d’attente Q1 n’est pas vide, 10 lorsqu’une durée prédéfinie est écoulée depuis la dernière réémission d’un paquet de données de ladite file d’attente de priorité réduite.
Dans le contexte d’un boîtier TCU de véhicule comprenant trois APN, le troisième APN pouvant être utilisé pour télécharger des cartes pour la conduite autonome, ledit troisième APN émet des paquets de données via ladite troisième interface de 15 données.

Claims (6)

  1. REVENDICATIONS
    1. Procédé de gestion des priorités dans un calculateur exécutant un système d’exploitation Linux, ledit système comprenant une première interface de données (RmnetO) recevant (11) des paquets de données destinés à être traités de façon prioritaire et une deuxième interface de données (Rmnetl) recevant (21) des paquets de données destinés à être traités de façon non prioritaire, ainsi qu’une interface physique unique configurée pour émettre successivement des paquets de données provenant desdites première et deuxième interfaces de données (RmnetO, Rmnetl), ledit procédé comprenant :
    • la mise en œuvre d’une règle de trafic, attachée aux première et deuxième interfaces de données (RmnetO, Rmnetl), pour rediriger (12, 22) les paquets de données reçus par les première et deuxième interfaces de données (RmnetO, Rmnetl) vers une pseudo-interface (IFB) de type bloc de flux intermédiaire, • la mise en œuvre d’une règle de file d’attente, attachée la pseudo-interface (IFB), de telle sorte que les paquets de données issus de la première interface de données (RmnetO) sont classés dans une file d’attente (Q1) présentant une première priorité et que les paquets de données issus de la deuxième interface de données (Rmnetl) sont classés dans une file d’attente (Q2) présentant une deuxième priorité, • la réémission (13, 23) des paquets de données par la pseudo-interface (IFB) à destination de leur interface de données d’origine respective (RmnetO, Rmnetl), en fonction de la règle de file d’attente, les paquets de données de la file d’attente présentant la première priorité (Q1) étant émis avant les paquets de données de la file d’attente présentant la deuxième priorité (Q2), • la transmission (14, 24) des paquets de données réémis à l’interface radio physique, en vue de leur émission vers l’extérieur.
  2. 2. Procédé selon la revendication précédente, comprenant une étape préalable d’initialisation des interfaces de données (RmnetO, Rmnetl) et de la pseudointerface (IFB).
  3. 3. Procédé selon l’une quelconque des revendications précédentes, destiné à être mis en œuvre dans une unité de contrôle télématique comprenant un premier et un deuxième noms de point d’accès, le premier nom de point d’accès étant dédié à des services télématiques et émettant des données définies comme prioritaires, le deuxième nom de point d’accès étant dédié à des services d’info-divertissement et émettant des données définies comme non prioritaires, les données émises sur le premier nom de point d’accès étant traitées par la première interface de données (RmnetO) et les données émises sur le deuxième nom de point d’accès étant traitées par la deuxième interface de données (Rmnetl).
  4. 4. Procédé selon l’une quelconque des revendications précédentes, le système comprenant une troisième interface de données recevant des paquets de données devant être traités de façon non prioritaire, ledit procédé comprenant :
    • la mise en œuvre de la règle de trafic, également attachée aux première et deuxième interfaces de données (RmnetO, Rmnetl), pour rediriger les paquets de données reçus par la troisième interface de données vers la pseudointerface (IFB), • la mise en œuvre d’une règle de file d’attente, attachée la pseudo-interface (IFB), de telle sorte que les paquets de données issus de la troisième interface de données sont classés dans une file d’attente présentant une troisième priorité, inférieure à la deuxième priorité, • la réémission des paquets de données par la pseudo-interface (IFB) à destination de leur interface de données d’origine respective, en fonction de la règle de file d’attente, les paquets de données de la file d’attente présentant la troisième priorité étant émis après les paquets de données de la file d’attente présentant la deuxième priorité (Q2), • la transmission des paquets de données réémis à l’interface radio physique, en vue de leur émission vers l’extérieur.
  5. 5. Procédé selon l’une quelconque des revendications précédentes, dans lequel un ou plusieurs paquets de données de la file d’attente (Q2) présentant la deuxième priorité sont réémis par la pseudo-interface (IFB), y compris si la file d’attente (Q1) présentant la première priorité n’est pas vide, lorsqu’une durée prédéfinie est écoulée depuis la dernière réémission d’un paquet de données de ladite file d’attente (Q2) présentant la deuxième priorité.
  6. 6. Procédé selon l’une quelconque des revendications 1 à 4, dans lequel un ou plusieurs paquets de données de la file d’attente présentant la troisième priorité sont réémis par la pseudo-interface (IFB), y compris si la file d’attente (Q2) présentant la deuxième priorité n’est pas vide et y compris si la file d’attente (Q1) présentant la première priorité n’est pas vide, lorsqu’une durée prédéfinie est écoulée depuis la dernière réémission d’un paquet de données de ladite file d’attente présentant la troisième priorité.
FR1858048A 2018-09-07 2018-09-07 Procede de gestion des priorites de traitement de paquets de donnees, dans un environnement linux Active FR3081277B1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR1858048A FR3081277B1 (fr) 2018-09-07 2018-09-07 Procede de gestion des priorites de traitement de paquets de donnees, dans un environnement linux

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1858048A FR3081277B1 (fr) 2018-09-07 2018-09-07 Procede de gestion des priorites de traitement de paquets de donnees, dans un environnement linux

Publications (2)

Publication Number Publication Date
FR3081277A1 true FR3081277A1 (fr) 2019-11-22
FR3081277B1 FR3081277B1 (fr) 2021-05-28

Family

ID=65201321

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1858048A Active FR3081277B1 (fr) 2018-09-07 2018-09-07 Procede de gestion des priorites de traitement de paquets de donnees, dans un environnement linux

Country Status (1)

Country Link
FR (1) FR3081277B1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040092278A1 (en) * 2002-11-13 2004-05-13 Wilhelmus Diepstraten Managing priority queues and escalation in wireless communication systems
US20090198845A1 (en) * 2008-02-05 2009-08-06 Samsung Electronics Co. Ltd. System for processing routing according to priorities of logical interfaces and method for controlling the same
US20100232396A1 (en) * 2009-03-11 2010-09-16 Sony Corporation Quality of service architecture for home mesh network
CN102916901A (zh) * 2012-10-12 2013-02-06 烽火通信科技股份有限公司 基于Linux软件实现上行QoS调度的方法及装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040092278A1 (en) * 2002-11-13 2004-05-13 Wilhelmus Diepstraten Managing priority queues and escalation in wireless communication systems
US20090198845A1 (en) * 2008-02-05 2009-08-06 Samsung Electronics Co. Ltd. System for processing routing according to priorities of logical interfaces and method for controlling the same
US20100232396A1 (en) * 2009-03-11 2010-09-16 Sony Corporation Quality of service architecture for home mesh network
CN102916901A (zh) * 2012-10-12 2013-02-06 烽火通信科技股份有限公司 基于Linux软件实现上行QoS调度的方法及装置

Also Published As

Publication number Publication date
FR3081277B1 (fr) 2021-05-28

Similar Documents

Publication Publication Date Title
EP1792447A1 (fr) Procede de preemption pour la gestion des ressources radio dans un reseau de communication mobile
EP1665661A1 (fr) Procede de differenciation de la qualite de service dans les reseaux de communication mobile en mode paquets
WO2005084061A1 (fr) Procede de gestion des ressources radio dans un reseau d’acces radio de type utran
EP3771161A1 (fr) Sélection d'une instanciation de tranche de réseau pour la transmission de paquets montants
EP2460322B1 (fr) Procede et systeme pour la selection automatique de media de transmission
WO2019043324A1 (fr) Procédé de taxation de données d'une application acheminées sur une tranche d'un réseau de communication
US7296071B2 (en) Service transmission in a packet data network
EP2939450B1 (fr) Transmission d'un message multimédia doublée par émission d'un message textuel
WO2019185552A1 (fr) Procede de communication
EP1337074A1 (fr) Système de gestion de réseau avec validation de règles
FR2836315A1 (fr) Correlation des requetes en qualite de service au sein d'un systeme de controle d'un reseau de donnees
FR3081277A1 (fr) Procede de gestion des priorites de traitement de paquets de donnees, dans un environnement linux
EP1439672A1 (fr) Méthode de configuration d'un chemin de routage dans un routeur ip
EP3295613B1 (fr) Procédé et dispositif de contrôle de la transmission de trames dans un réseau vidéo bidirectionnel.
EP1850602A2 (fr) Procédé et système pour accelérer l'accès à un contenu à partir d'un terminal mobile
EP2858327B1 (fr) Procédé de mise en oeuvre d'une session de communication entre une pluralité de terminaux
US9143352B2 (en) Method and device for monitoring service quality in a network
EP2165485B1 (fr) Gestion de paquets de couche reseau dans un reseau d'acces d'un reseau de telecommunications
EP3446470B1 (fr) Procédé de gestion de la réception d'un appel téléphonique sur un terminal de communication appelé
EP4335144A1 (fr) Parametrage d'un terminal
FR2977434A1 (fr) Procede et systeme de communication au sein d'une communaute heterogene d'utilisateurs
WO2005013559A1 (fr) Procede et systeme de transmission de donnees a haut debit et a qualite de service predeterminee
FR2836318A1 (fr) Systeme de transmission de contenus mutimedias apte a accorder les contenus au cours de leur transmission
EP1356635A1 (fr) Procede et serveur d'acces a un reseau numerique
WO2016156386A1 (fr) Système de diffusion de contenus audio et/ou vidéo par un réseau wifi local, et appareils mettant en œuvre le procédé

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20191122

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