Brevet FR2964001A1 — publié le 20120224

Établissement d'un flux de paquets possédant une qualité de service symétrique par négociation de l'indicateur de qualité La présente invention est relative aux réseaux de communication multimédia. Ces réseaux peuvent transmettre du trafic de différentes natures (voix, vidéo, données...) correspondant à des applications variées : téléphonie, vidéophonie, navigation sur internet, téléchargement de fichiers, discussion textuelle en temps-réel (« instant messaging » ou « chat »)... Ces trafic sont transmis classiquement sous la forme de flux de paquets, notamment de paquet IP (pour « Internet Protocol »). Un même message applicatif peut être transmis en plusieurs paquet IP et il doit être reconstruit à réception avant délivrance à l'application. Ces applications et ces types de trafic sont associés à des critères de qualité de service différents et, dans la mesure où la capacité de transmission des réseaux est limité, il apparaît un besoin de donner une priorité plus important à certains couples applications/trafic qu'à d'autre. Par exemple, dans le cas d'une communication voix, le retard prit par certains paquets peut engendrer une perte de qualité de la voix. Dans le pire cas, le message audio pourra être inaudible ou incompréhensible. Dans le cas d'une navigation sur internet, un retard pris par certains paquets peut éventuellement engendrer la sensation d'un système plus lent, mais la plupart du temps l'effet est imperceptible. Il apparaît donc naturel de donner une importance plus forte au trafic de voix en comparaison du trafic de données. 806957 Il existe des solutions techniques permettant une affectation de priorités aux différents flux de données transmis par un réseau. Une de ces solutions est le mécanisme DiffServ, tel que notamment défini dans le RFC 2474 de l'IETF, « Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers ». Le principe de ce mécanisme DiffServ est d'insérer dans les paquets d'un flux un champ, DS Field, dont la valeur détermine une classe de service (ou code-point). Les équipements de réseau (routeurs, passerelles...) situés sur le chemin du flux de paquets doivent lire le champ DS Field et traiter la retransmission des paquets en fonction de cette valeur, les paquets de classe de service la plus élevée étant les plus prioritaires. De cette façon, les flux requérant une qualité de service élevée peuvent 15 être privilégiés par le réseau de communication par rapport aux flux n'en exigeant pas. Toutefois, aucun mécanisme ne vient préciser comment la classe de service doit être déterminée. Chaque équipement insérant une classe de 20 service dans un flux de paquets détermine la valeur selon des mécanismes propres et en fonction des différents flux qu'il peut avoir à gérer. Ces mécanismes peuvent dépendre du fournisseur de l'équipement. Dans le cadre d'une communication bidirectionnelle, il peut souvent en 25 résulter que chacun des deux terminaux (ou les équipements d'accès associés) utilise des politiques différentes pour déterminer la classe de service. Du coup, les flux de chaque direction appartiennent à des classes de service différentes et, donc, le comportement du réseau de communication à leur égard est différent et engendrer des qualités de service perçues différentes pour les deux 30 directions. 806957 Par exemple, dans le cas d'une communication voix bidirectionnelle, un flux équipement connecté à un réseau sensible à l'écho pourrait requérir une diminution du délai. Si cela n'est pas appliqué les utilisateurs pourraient souffrir de problèmes d'écho (le paramètre délai amplifie la perception d'écho). Le but de l'invention est de palier ce problème en offrant un mécanisme garantissant la même qualité de service perçue pour l'ensemble des directions 10 d'une session de communication. Pour ce faire, l'invention a pour objet un équipement de réseau comportant des moyens pour établir un flux de paquets avec un autre équipement au travers d'un réseau de communication, des moyens pour déterminer une première valeur d'un indicateur de priorité en fonction du 15 type de ce flux de données et des moyens pour échanger avec cet autre équipement des messages de signalisation pour permettre l'établissement du flux de données. L'équipement de l'invention dispose en outre de moyens pour insérer cette première valeur dans le premier des messages de signalisation et des moyens pour, à réception d'un message de signalisation 20 (si, s2) comportant une valeur reçue de l'indicateur de priorité, déterminer une valeur émise à partir de la valeur reçue et insérer cette valeur émise dans les paquets du flux de paquets. L'invention a également pour objet un procédé pour l'établissement d'un 25 flux de paquets avec un autre équipement au travers d'un réseau de communication, comportant une étape de détermination d'une première valeur d'un indicateur de priorité en fonction du type du flux de données et une étape d'échange, avec cet autre équipement, de messages de signalisation pour permettre l'établissement du flux de données. La première 30 valeur est insérée dans le premier de ces messages de signalisation. À 806957 réception d'un message de signalisation comportant une valeur reçue de cet indicateur de priorité, une valeur émise est déterminée à partir de cette valeur reçue, et insérée dans les paquets du flux de paquets. Selon un mode de réalisation de l'invention, la valeur émise est la valeur maximale entre la valeur reçue et la valeur déterminée par l'équipement en fonction du type de flux de paquets. L'indicateur de priorité peut être conforme au mécanisme DiffServ et l'équipement peut alors être adapté pour insérer la troisième valeur dans le 10 champ « DS Field » du flux de paquets. La valeur émise peut être insérée dans un attribut conforme au protocole SDP dans les messages de signalisation. La valeur émise peut être insérée dans un champ « DS Field » des paquets du flux de paquets. 15 L'invention apparaîtra de façon plus claire dans la description qui va suivre en liaison avec la figure annexée. Cette figure schématise les messages échangés entre deux équipements reliés par un réseau de communication et mettant en oeuvre l'invention. 20 La mise en oeuvre d'une session sur un réseau de communication, notamment sur un réseau de données de type « internet », comporte d'une façon générale deux phases : une phase d'établissement, durant laquelle les parties à la session échangent des messages de signalisation, et une phase de 25 communication proprement dite durant laquelle les parties échangent les données: voix, vidéos, texte... Dans la mise en oeuvre représentée sur la figure 1, deux équipements A et B sont connectés via un réseau de communication N. L'invention est 30 toutefois tout à fait susceptible de s'appliquer avec d'avantage de parties, et 806957 donc au cas des « conférences » audios ou vidéos. Les deux équipements peuvent être des terminaux de communication : téléphones fixes ou mobiles, ordinateurs, assistants numériques personnels (ou PDA pour Personal Digital Assistants) etc. Il peut aussi s'agir d'équipements hébergés chez un fournisseur de service, tel des serveurs. Par exemple, la communication peut être une communication entre un serveur de contenu et un terminal de communication permettant à l'utilisateur de ce dernier d'accéder à des contenus audio, vidéo... Il peut également s'agir d'équipements virtuels. Dans l'exemple de la figure 1, on suppose que l'équipement A initie la création de la session de communication. Il adresse à l'équipement B un premier message de signalisation, S1. Ce message peut typiquement être un message d'invitation conforme au protocole SIP tel que défini dans le RFC 3261 de l'IETF, « Session Invitation Protocol ». Ce message « Invite » peut être relayé par différents dispositifs, tels des « SIP Proxy », au sein du réseau de communication N. Ceux-ci ne sont pas représentés sur la figure 1 et ne seront pas plus décrits dans la mesure où ils n'influencent pas l'invention proprement dite. L'équipement A possède des moyens pour déterminer une valeur d'un indicateur de priorité p en fonction du type du flux de données qui doit composer la session de communication. On appelle « type » ici la nature des données à transmettre : vidéo, audio, audio-vidéo, texte, texte en temps-réel de type « messaging » ou « chat », etc. Le type peut en outre être plus précis et il peut être possible de décliner un type gros-grain comme « vidéo » en plusieurs types. Le fournisseur de l'équipement A paramètre généralement une table de correspondance entre ces types de flux de données et une valeur de 30 l'indicateur de priorité. 806957 Cet indicateur de priorité est préférentiellement conforme au mécanisme DiffServ tel que spécifié par le RFC 2474, « Definition of the Differentiated Serviecs Field (DS Field) in the IPv4 and IPv6 Headers ». L'équipement A peut être prévu pour disposer directement d'une table de correspondance entre type de flux de données et « codepoint ». Selon l'invention, l'équipement possède des moyens pour insérer cette valeur, vl, dans le premier message de signalisation S1, c'est-à-dire celui d'invitation. Cette valeur peut être insérée dans un attribut approprié du protocole SDP (Session Description Protocole) tel que défini par le RFC 4566 de l'IETF. Cet attribut peut être codé sur 8 bits. Il peut être par exemple nommé « Traffic-class ». Selon la grammaire ABNF (Augmented Backus-Naur Form), cet attribut peut être de la forme: Traffic-class = « a=traffic-class: » Traffic-class-value Traffic-class-value = *DIGIT La valeur qui peut être prise par cet attribut est un entier compris entre 0 20 et 255. Dans l'exemple de la figure, on peut trouver un attribut SDP dans le message SIP « Invite » S1 de type: a=traffic-class:vl 25 A la réception du message de signalisation S1, l'équipement B doit lire cette valeur reçue vl de l'indicateur de priorité p. Il renvoie à l'équipement émetteur A un message de signalisation S2 qui, classiquement, est un message SIP « 200 Ok ». 806957 Il dispose également des moyens pour insérer dans ce message de signalisation S2 une valeur « émise » de l'indicateur de priorité p. Cette valeur émise est déterminée à partir de la valeur reçue vl. Selon un mode de réalisation de l'invention, cette valeur émise (v3) est égale à la valeur reçue. Selon un autre mode de réalisation de l'invention, cette valeur émise est égale au maximum entre la valeur reçue vl et une valeur déterminée par en fonction du type de flux de données. En effet, tout comme l'équipement A, il possède des moyens pour déterminer une valeur v2 pour l'indicateur de priorité p associée au type de flux de données. Il peut déterminer le type de flux de données grâce à d'autres champs et attributs du message de signalisation S1. Notamment, l'attribut « m » de la description du média, SDP, peut être utilisé pour déterminer cette valeur v2. La valeur insérée dans le message S2 est donc une valeur v3=max(vl,v2). Et le message S2 comporte un attribut a=traffic-class:v3 A la réception de ce message S2, l'équipement A peut lire cet attribut et prendre connaissance de cette valeur v3. Dans certaines situations, l'équipement A peut renvoyer un message de signalisation suivant S3. Il peut s'agir d'un message SIP « ACK ». Il n'est pas nécessaire d'y insérer un indicateur de priorité puisqu'à ce moment-là les deux équipements se sont déjà. Toutefois, l'invention s'applique évidemment au cas où cet indicateur est inséré dans les éventuels autres messages de signalisation S3. 806957 Les équipements A et B possèdent en outre des moyens pour établir le flux F de paquets au travers du réseau de communication N, selon les modalités et paramètres négociés durant les messages de signalisation (CODEC etc.) Ils peuvent insérer au sein de ces paquets la valeur de l'indicateur de priorité déterminée précédemment, c'est-à-dire cette valeur v3. Comme évoqué précédemment, cette valeur peut être conforme aux spécifications de DiffServ. Elle peut notamment être codée sur 8 bits, avec un champ DSCP (Differentiated Services CodePoint) de 6 bits, tels que spécifiés au paragraphe 3 du RFC 2474 de l'IETF. Ainsi, la valeur de l'indicateur de priorité peut être directement insérée dans le champ « DS Field » des paquets sortants. L'insertion dans le champ DS Field des paquets est effectuée de façon connue en soi. La façon dont est déterminée la valeur insérée est par contre novatrice : selon l'invention, un équipement conforme à l'invention doit donc choisir comme indicateur DiffServ à utiliser pour un flux de paquets la valeur reçue dans le dernier message de signalisation reçu concernant ce flux. De cette façon, le flux de paquets possède la même valeur DiffServ dans les deux sens. La transmission des paquets est donc symétrique et la qualité de service perçue par les deux équipements A et B est identique. Bien que les modes de réalisations décrits ci-dessus utilisent le mécanisme DiffServ, l'invention n'est pas limité à ce mécanisme mais peut au contraire s'appliquer à tout protocole permettant de définir une priorité ou un indicateur de qualité de service à un paquet de données. 806957 REVENDICATIONS1) Équipement de réseau (A, B) comportant des moyens pour établir un flux (F) de paquets avec un autre équipement au travers d'un réseau de communication (N), des moyens pour déterminer une première valeur (vl ) d'un indicateur de priorité (p) en fonction du type dudit flux de données et des moyens pour échanger avec ledit autre équipement des messages de signalisation (si, s2, s3) pour permettre l'établissement dudit flux de données, disposant en outre des moyens pour insérer ladite première valeur dans le premier (si) desdits messages de signalisation et des moyens pour, à réception d'un message de signalisation (si, s2) comportant une valeur reçue dudit indicateur de priorité, déterminer une valeur émise à partir de ladite valeur reçue et insérer ladite valeur émise dans les paquets dudit flux de paquets. 2) Équipement de réseau selon la revendication 1, dans lequel ladite valeur émise est la valeur maximale entre ladite valeur reçue et la valeur 20 déterminée par ledit équipement en fonction dudit type de flux de paquets. 3) Équipement de réseau selon l'une des revendications 1 ou 2 dans lequel ledit indicateur de priorité est conforme au mécanisme DiffServ, et adapté pour insérer ladite troisième valeur dans le champ « DS Field » dudit 25 flux de paquets. 4) Équipement de réseau selon l'une des revendications précédentes, adapté pour insérer ladite valeur émise dans un attribut conforme au protocole SDP dans lesdits messages de signalisation. 9 30 806957 5) Equipement de réseau selon l'une des revendications précédentes, adapté pour insérer ladite valeur émise dans un champ « DS Field » des paquets dudit flux de paquets. 6) Procédé pour l'établissement d'un flux (F) de paquets avec un autre équipement au travers d'un réseau de communication (N), comportant une étape de détermination d'une première valeur (vl) d'un indicateur de priorité (p) en fonction du type dudit flux de données et une étape d'échange avec ledit autre équipement de messages de signalisation (si, s2, s3) pour permettre l'établissement dudit flux de données, dans lequel ladite première valeur est insérée dans le premier (si) desdits messages de signalisation, et dans lequel, à réception d'un message de signalisation (si, s2) comportant une valeur reçue dudit indicateur de priorité, une valeur émise est déterminée à partir de ladite valeur reçue et insérée dans les paquets dudit flux de paquets. 7) Procédé selon la revendication précédente, dans lequel ladite valeur émise est la valeur maximale entre ladite valeur reçue et la valeur déterminée par ledit équipement en fonction dudit type de flux de paquets. 8) Procédé selon l'une des revendications 6 ou 7 dans lequel ledit indicateur de priorité est conforme au mécanisme DiffServ, et adapté pour insérer ladite troisième valeur dans le champ « DS Field » dudit flux de paquets. 9) Procédé selon l'une des revendications 5 à 8, dans lequel ladite valeur émise est insérée dans un attribut conforme au protocole SDP dans lesdits messages de signalisation. 25 806957 10) Procédé selon l'une des revendications 5 à 9, dans lequel ladite valeur émise est insérée dans un champ « DS Field » des paquets dudit flux de paquets. 10 15 20 25 30 806957