EP4785538A1 - Procédé d'optimisation de la diffusion d'un contenu multicast au sein d'un réseau de communication mettant en oeuvre une pluralité de tranches réseau - Google Patents

Procédé d'optimisation de la diffusion d'un contenu multicast au sein d'un réseau de communication mettant en oeuvre une pluralité de tranches réseau

Info

Publication number
EP4785538A1
EP4785538A1 EP24772310.9A EP24772310A EP4785538A1 EP 4785538 A1 EP4785538 A1 EP 4785538A1 EP 24772310 A EP24772310 A EP 24772310A EP 4785538 A1 EP4785538 A1 EP 4785538A1
Authority
EP
European Patent Office
Prior art keywords
multicast
network
network slice
terminal
broadcasting
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.)
Pending
Application number
EP24772310.9A
Other languages
German (de)
English (en)
Inventor
Mohamed Boucadair
Christian Jacquenet
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.)
Orange SA
Original Assignee
Orange SA
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 Orange SA filed Critical Orange SA
Publication of EP4785538A1 publication Critical patent/EP4785538A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/185—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with management of multicast group membership
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1886—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with traffic restrictions for efficiency improvement, e.g. involving subnets or subdomains
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/189—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast in combination with wireless systems

Landscapes

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

Abstract

L'invention se rapporte à un procédé d'optimisation de la diffusion d'un contenu multicast au sein d'un réseau de communication mettant en œuvre une pluralité de tranches réseau, comprenant : - la réception (11), en provenance d'un terminal, d'un message de signalisation représentatif d'une demande d'adhésion dudit terminal à un groupe multicast associé à la diffusion dudit flux multicast, ledit message comprenant une adresse multicast identifiant ledit groupe multicast, et un identifiant de tranche réseau représentatif d'une tranche réseau candidate privilégiée par ledit terminal pour l'acheminement dudit flux multicast; - l'obtention (12) d'un identifiant d'une tranche réseau cible pour l'acheminement dudit flux multicast, en fonction dudit identifiant de tranche réseau candidate et de données représentatives d'un état courant dudit réseau de communication; - le raccordement (13) dudit terminal à un arbre de distribution dudit flux multicast déployé dans ladite tranche réseau cible.

Description

     Procédé d’optimisation de la diffusion d’un contenu multicast au sein d’un réseau de communication mettant en œuvre une pluralité de tranches réseau.
  • Le domaine de l’invention est celui des communications au sein d’au moins un réseau de communication, et notamment celui des services IP à valeur ajoutée. Plus précisément, l’invention se rapporte à la mise en œuvre de services de diffusion de contenus exploitant un mode de transmission multicast, dans un réseau de communication au sein duquel des tranches réseau (« network slices » ou « slices » en anglais) sont déployées.
    •  Art antérieur
  • La diffusion d’un même contenu à de multiples utilisateurs est un service couramment proposé et mis en œuvre via les réseaux de communication actuels, par exemple dans le cadre de la retransmission d’évènements culturels ou sportifs (retransmission d’un concert dans un métavers, retransmission d’un match de football en direct, etc.). Sur le plan technique, l’ingénierie de tels services de diffusion repose généralement sur un mode de transmission dit « multicast » (parfois également désigné sous les termes de « multidiffusion » ou « diffusion groupée »). Ce mode est en effet particulièrement adapté aux schémas de communication de groupes, tels que la diffusion de contenus à destination de plusieurs utilisateurs (récepteurs), ou encore la mise en œuvre de services de type visioconférence entre plusieurs utilisateurs où chaque participant est à tour de rôle source ou récepteur. Dans les réseaux IP (« Internet Protocol »), le mode de transmission multicast repose sur le calcul, l’établissement et la maintenance d’arbres de distribution par un protocole de routage dynamique, tel que le protocole PIM (« Protocol Independent Multicast », RFC7761). Un objectif principal de la mise en œuvre de tels arbres de diffusion est d’optimiser les ressources d’un réseau selon un mode de réplication déterministe des données.
  • Certains réseaux de communication récents, notamment les réseaux mobiles de cinquième génération (5G), offrent par ailleurs la possibilité aux opérateurs qui les exploitent de créer et déployer différentes tranches réseau sur une même infrastructure physique.
  • Une tranche réseau peut être définie comme une partition du réseau, telle qu’un réseau privé virtuel (RPV, ou VPN pour « Virtual Private Network » en anglais) déployé sur une infrastructure fixe, mobile, ou une combinaison des deux.
  • Les caractéristiques d’une tranche réseau sont essentiellement exprimées en termes de capacité (i.e. de bande passante), de qualité de service (par ex. latence ou temps de transit unidirectionnel), de sécurité (par ex. préservation de la confidentialité des informations transmises au sein de la tranche), d’isolation du trafic ou de disponibilité. Ainsi, un opérateur a la possibilité de configurer une pluralité de tranches réseau au sein d’un réseau de communication ; une tranche ou un groupe de tranches étant par exemple dédiés à la fourniture de services particuliers et/ou à satisfaire à des exigences techniques particulières, de sorte que le trafic caractéristique de ces services puisse bénéficier des meilleures conditions d’acheminement.
  • Classiquement, le trafic susceptible d’être acheminé au sein d’une tranche réseau fait l’objet d’une habilitation (aussi appelé contrôle d’accès) à emprunter les chemins établis au sein de la tranche en question. Une telle habilitation repose typiquement sur l’application de règles de classification de trafic, généralement appliquées par un point d’accès au réseau au sein duquel les tranches réseau sont déployées. Un tel point d’accès est un nœud situé en périphérie du réseau, par exemple déployé en frontal des accès clients ou bien utilisé pour connecter un réseau à d’autres réseaux voisins. Par exemple, ce point d’accès peut être situé à l’interface de raccordement d’une passerelle (par exemple une passerelle paquet, ou « Packet Gateway » en anglais, pour les générations les plus récentes – 4G, 5G – des réseaux mobiles) qui permet d’accéder au réseau Internet. Un tel point d’accès peut également se situer à l’interface de raccordement d’un terminal mobile (ou « User Equipment » ou UE en anglais) au réseau d’accès radio (ou « Radio Access Network » ou RAN en anglais), de façon notamment à optimiser l’usage des ressources radio en fonction du type de la tranche réseau et du profil du trafic qu’elle est susceptible d’acheminer.
  • Dans ce contexte, l’organisme 3GPP a défini différents types de tranches réseau, aux caractéristiques propres, comprenant notamment :
  • - un premier type de tranches réseau permettant d’offrir un service mobile large bande amélioré (« Enhanced Mobile BroadBand » ou eMBB en anglais) ;
  • - un deuxième type de tranches réseau permettant d’offrir un service dans le cadre d’un déploiement (massif) de l’Internet des Objets (« massive Internet of Things » ou mIoT en anglais) ; et
  • - un troisième type de tranches réseau permettant d’offrir un service de communication ultra fiable et à faible latence (« Ultra Reliable Low Latency Communications » ou URLLC en anglais).
  • Le choix de concevoir et de déployer un type de tranche réseau donné est conditionné par la nature du trafic caractéristique des applications ou services utilisés ou souscrits par un utilisateur. Par exemple, un service dit « immersif » qui exploite des techniques de réalité augmentée ou virtuelle est généralement très exigeant en termes de latence et de fiabilité des échanges de données : l’utilisation de tranches de type URLLC est donc privilégiée pour un tel service immersif.
  • Pour accéder à un contenu diffusé en multicast sur un réseau de communication mettant en œuvre des tranches réseau, un récepteur (terminal mobile, ordinateur personnel, poste de télévision) doit pouvoir se connecter à une voire plusieurs tranches réseau, qui d’une part hébergent l’arbre de distribution le long duquel le trafic sera acheminé depuis la source vers l’ensemble des récepteurs, et d’autre part présentent des caractéristiques reflétant celles du ou des services de diffusion. Par exemple, une tranche réseau sera conçue et dimensionnée (en termes de bande passante, de temps de transit unidirectionnel, etc.) pour acheminer du trafic encodé par la source en haute définition (HD, « High Definition » en anglais), une autre tranche pour acheminer le trafic encodé par la source en définition standard (SD, « Standard Definition » en anglais), etc.
  • La variété de telles tranches « multicast » doit non seulement pouvoir être signalée aux récepteurs, quelle que soit leur nature, quels que soient leurs moyens d’accès à l’une ou l’autre de ces tranches et que ces récepteurs soient en mouvement ou pas. Elle doit également permettre de basculer le trafic de diffusion d’une tranche à l’autre selon plusieurs considérations telles qu’un phénomène de congestion éventuel, les capacités d’accès des récepteurs à l’une ou l’autre des tranches, la nature du service de diffusion auquel un récepteur a souscrit, etc. De telles considérations permettent notamment d’ajuster dynamiquement les règles de classification de trafic qui régissent l’accès des récepteurs à l’une ou l’autre de ces tranches.
  • Or, si des outils – tels que des protocoles de souscription à un groupe multicast, des protocoles de routage dynamique multicast, etc. – existent pour faciliter la mise en place de services de diffusion reposant sur le mode de transmission multicast supporté par des réseaux IP, il n’existe en revanche aucun moyen de gérer simplement les règles de classification de trafic permettant d’accéder à des tranches « multicast » dans un contexte d’émergence de réseaux mobiles 5G, notamment. La mise en œuvre de telles règles de classification implique donc actuellement des configurations complexes du réseau, avec un risque substantiel d’erreurs lors des opérations de configuration en question.
  • Il existe donc un besoin pour une technique permettant d’optimiser la diffusion de contenus multicast au sein d’un réseau de communication au sein duquel plusieurs tranches réseau sont déployées.
    •
  • La présente invention propose une solution visant à remédier à certains inconvénients de l’art antérieur. Selon un aspect, la présente invention se rapporte en effet à un procédé d’optimisation de la diffusion d’un contenu multicast au sein d’un réseau de communication mettant en œuvre une pluralité de tranches réseau. Selon le principe général de l’invention proposée, un tel procédé comprend :
  • - la réception, en provenance d’un terminal connecté audit réseau, d’un message de signalisation représentatif d’une demande d’adhésion dudit terminal à un groupe multicast associé à la diffusion dudit flux multicast, ledit message de signalisation comprenant une adresse multicast identifiant ledit groupe multicast, et un identifiant de tranche réseau représentatif d’une tranche réseau privilégiée par ledit terminal pour l’acheminement dudit flux multicast, dite tranche réseau candidate ;
  • - l’obtention d’un identifiant d’une tranche réseau cible pour l’acheminement dudit flux multicast, en fonction dudit identifiant de tranche réseau candidate et de données représentatives d’un état courant dudit réseau de communication ;
  • - le raccordement dudit terminal à un arbre de distribution dudit flux multicast déployé dans ladite tranche réseau cible.
  • De cette manière, l’acheminement de contenus diffusés selon le mode de transmission multicast au sein d’un réseau de communication mettant en œuvre des tranches réseau est optimisé, en ce sens que l’invention fournit la possibilité à des terminaux sources et/ou récepteurs de transmettre au réseau, en fonction de leurs caractéristiques et/ou capacités techniques et/ou d'un contexte local, des préférences concernant une tranche à privilégier pour l’acheminement d’un flux multicast, tout en réservant la possibilité au réseau de prendre la décision d’acheminer le flux multicast sur une autre tranche, notamment en fonction de son état courant, s’il estime qu’une autre tranche présente de meilleures conditions d’acheminement dudit flux multicast.
  • Dans un mode de réalisation particulier, ledit identifiant de tranche réseau candidate est encodé dans ladite adresse multicast et/ou compris dans un champ de données libres dudit message de signalisation.
  • De cette manière, il est possible d’utiliser de manière transparente et astucieuse des échanges de signalisation multicast classiques pour informer le réseau d’une tranche réseau à privilégier pour acheminer un flux multicast.
  • Selon une caractéristique particulière, ladite adresse de groupe multicast est une adresse IPv6, et ledit l’identifiant de tranche réseau candidate est encodé au sein du champ « ff2 » de ladite adresse IPv6.
  • De cette manière, on dispose d’un moyen d’encoder de manière transparente un identifiant de tranche réseau (ou de type de tranche réseau) dans une adresse IPv6.
  • Selon une caractéristique particulière, ladite adresse de groupe multicast est une adresse IPv4, et en ce que ledit encodage de l’identifiant de tranche réseau candidate est mis en œuvre par la sélection d'une adresse de groupe multicast spécifique au sein de l’espace IPv4 « 239.0.0.0/10 ».
  • De cette manière, on dispose d’un moyen d’encoder de manière transparente un identifiant de tranche réseau (ou de type de tranche réseau) dans une adresse multicast IPv4.
  • Dans un mode de réalisation particulier, ledit champ de données libres dudit message de signalisation comprend en outre une information représentative d’un codage de flux multicast supporté par ledit terminal.
  • De cette manière, on dispose d’une donnée supplémentaire discriminante permettant de sélectionner un arbre de distribution à utiliser au sein de la tranche réseau cible, dans le cas ou plusieurs arbres de distribution associés chacun à l’acheminement du flux multicast selon un encodage particulier seraient hébergés au sein de cette tranche.
  • Dans un mode de réalisation particulier, ledit message de signalisation est un message de type « Report » (« Rapport » en français) selon le protocole de signalisation IGMP (Internet Group Management Protocol, RFC 3376) ou le protocole de signalisation MLD (Multicast Listener Discovery, RFC 3810), et ledit champ de données libres est le champ de données auxiliaires « Auxiliary Data » défini dans ledit protocole de signalisation IGMP ou un champ dédié pour ledit protocole de signalisation MLD.
  • De cette manière, la compatibilité avec les protocoles de signalisation multicast IGMP et MLD largement utilisés pour la mise en place de services de diffusion multicast dans un réseau IP est garantie.
  • Dans un mode de réalisation particulier, ledit raccordement dudit terminal à un arbre de distribution dudit flux multicast déployé dans ladite tranche réseau cible tient compte de ladite information représentative d’un codage de flux multicast supporté par ledit terminal, lorsqu’une telle information est présente dans ledit champ de données libres dudit message de signalisation.
  • Dans un mode de réalisation particulier, ladite réception d’un message de signalisation représentatif d’une demande d’adhésion dudit terminal au groupe multicast associé à la diffusion dudit flux multicast fait suite à l’émission d’un message de demande de signalisation comprenant une liste de groupes multicast connus du réseau, ladite liste comprenant au moins ledit groupe multicast associé à la diffusion dudit flux multicast, identifié par ladite adresse multicast, un identifiant de tranche réseau étant encodé dans ladite adresse multicast et/ou compris dans un champ de données libres dudit message de demande de signalisation.
  • De cette manière, on utilise de manière transparente et astucieuse des échanges de signalisation multicast classiques pour informer un terminal des tranches réseau disponibles dans le réseau de communication pour acheminer un flux multicast.
  • Dans un mode de réalisation particulier, le raccordement dudit terminal à un arbre de distribution dudit flux multicast déployé dans ladite tranche réseau cible comprend l’émission d’un message de demande de greffe audit arbre de distribution selon un protocole de routage dynamique, ledit message de demande de greffe comprenant un identifiant de ladite tranche réseau cible.
  • De cette manière, le protocole de routage dynamique utilisé pour raccorder le terminal à un arbre de distribution tient compte d’une tranche réseau cible à utiliser pour l’acheminement du flux multicast.
  • Selon une caractéristique particulière, ledit message de demande de greffe comprend en outre une donnée représentative d’un encodage dudit flux multicast ou représentative d’une absence d’information d’encodage dudit flux multicast.
  • De cette manière, le protocole de routage dynamique utilisé pour raccorder le terminal à un arbre de distribution tient compte de données supplémentaires concernant l’encodage du flux multicast afin d’identifier l’arbre de distribution à utiliser pour acheminer le flux multicast, notamment dans le cas ou plusieurs arbres de distribution seraient hébergés dans la tranche réseau cible,
  • Selon une caractéristique particulière, ledit protocole de routage dynamique est le protocole PIM (Protocol Independent Multicast (Sparse Mode), RFC 7761) et ledit message de demande de greffe est un message de type « JOIN » selon ledit protocole PIM, ledit message étant adapté pour inclure un champ comprenant ledit identifiant de ladite tranche réseau cible et ladite donnée représentative d’un encodage dudit flux multicast, lorsque ladite donnée représentative d’un encodage dudit flux multicast est disponible.
  • De cette manière, l’invention proposée repose sur une adaptation d’un protocole de routage dynamique reconnu et largement utilisé pour la mise en place de services de diffusion multicast sur un réseau IP.
  • Dans un mode de réalisation particulier, ledit procédé comprend préalablement à ladite réception d’un message de signalisation de type « Report » (« Rapport » en français), lorsque ledit terminal est une source de diffusion dudit flux multicast :
  • - la réception, en provenance dudit terminal source, d’une requête de souscription à un service de diffusion optimisé, comprenant des données d’identification dudit terminal source et des données représentatives de capacités techniques supportées par ledit terminal source ;
  • - la transmission, à destination dudit terminal source, d’un message de confirmation de souscription, comprenant au moins une association entre une adresse multicast utilisable par ledit terminal source pour la diffusion dudit flux multicast et un identifiant de tranche réseau déterminée comme étant adaptée pour la diffusion dudit flux multicast sur ledit réseau de communication, en fonction desdites données représentatives de capacités techniques supportées par ledit terminal source.
  • De cette manière, une étape préliminaire de souscription au service de diffusion optimisée peut être initialisée par un terminal source en amont de la diffusion de tout contenu, permettant par exemple au terminal source d’obtenir des informations techniques pertinentes et ciblées sur les ressources disponibles au sein du réseau de communication, notamment des informations sur les tranches réseau qui présentent un intérêt particulier pour ce terminal source, car sélectionnées sur la base de caractéristiques et capacités techniques associées à ce terminal source et le service sous-jacent.
  • Selon une caractéristique particulière de ce mode de réalisation, ladite association est mise en œuvre par encodage, dans ladite adresse multicast utilisable par ledit terminal source pour la diffusion dudit flux multicast, dudit identifiant de tranche réseau déterminée comme étant adaptée pour la diffusion dudit flux multicast.
  • De cette manière, une adresse multicast en tant que telle permet de définir à la fois un groupe multicast et une tranche réseau, pour l’acheminent d’un flux multicast au sein du réseau de communication.
  • Selon un autre aspect, l’invention se rapporte à un procédé d’adhésion d’un terminal à un groupe multicast associé à la diffusion d’un flux multicast au sein d’un réseau de communication mettant en œuvre des tranches réseau, ledit procédé étant mis en œuvre au niveau dudit terminal, ledit procédé comprenant :
  • - l’obtention, à partir d’un message reçu en provenance dudit réseau, d’au moins un identifiant de tranche réseau disponible pour l’acheminement d’un flux multicast ;
  • - la transmission, à destination dudit réseau, d’un message de signalisation représentatif d’une demande d’adhésion dudit terminal audit groupe multicast, ledit message de signalisation comprenant un identifiant de tranche réseau représentatif d’une tranche réseau privilégiée par ledit terminal pour l’acheminement dudit flux multicast, dite tranche réseau candidate, sélectionnée parmi ledit au moins un identifiant de tranche réseau disponible pour ledit acheminement.
  • De cette manière, un terminal source ou récepteur est apte à sélectionner par lui-même une tranche réseau optimisée pour l’acheminement d’un flux multicast, en fonction par exemple de ses propres capacités techniques (par ex. d’encodage ou de décodage).
  • Dans un mode de réalisation particulier :
  • - ledit au moins un identifiant de tranche réseau disponible est extrait par ledit terminal d’au moins une adresse multicast comprise dans ledit message reçu, au sein de laquelle il est encodé ; et/ou
  • - ledit au moins un identifiant de tranche réseau candidate est encodé par ledit terminal au sein d’au moins une adresse multicast identifiant ledit groupe multicast, transmise dans ledit message de signalisation.
  • De cette manière, le terminal est pleinement compatible avec la nouvelle structuration d’adresse multicast selon l’invention, que ce soit lorsqu’il s’agit d’extraire un identifiant de tranche réseau encodé dans une telle adresse, ou de construire une adresse multicast encodant une telle information.
  • Selon un autre aspect, l’invention concerne une entité routeur capable de mettre en œuvre le procédé d’optimisation de la diffusion d’un flux multicast décrit précédemment. Une telle entité pourra bien sûr présenter les différentes caractéristiques relatives au procédé d’optimisation selon l’invention, qui peuvent être combinées ou considérées isolément. Ainsi, les caractéristiques et avantages de cette entité sont les mêmes que ceux du procédé d’optimisation et ne sont pas détaillés plus amplement.
  • Selon un autre aspect, l’invention concerne un terminal (source ou récepteur) capable de mettre en œuvre le procédé d’adhésion à un groupe multicast décrit précédemment. Un tel terminal pourra bien sûr présenter les différentes caractéristiques relatives au procédé d’adhésion selon l’invention, qui peuvent être combinées ou considérées isolément. Ainsi, les caractéristiques et avantages de cette entité sont les mêmes que ceux du procédé d’adhésion et ne sont pas détaillés plus amplement.
  • Selon un autre aspect, l’invention proposée se rapporte également à un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, comprenant des instructions de code de programme pour l’exécution d'au moins un des procédés tels que décrits précédemment dans l’un quelconque de ses modes de réalisation, lorsque ce procédé est exécuté sur un ordinateur.
  • L’invention proposée vise également un support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur comprenant des instructions de code de programme pour l’exécution des étapes des procédés tel que décrits précédemment, dans l’un quelconque de leurs modes de réalisation.
  • Un tel support d'enregistrement peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une clé USB ou un disque dur.
  • D'autre part, un tel support d'enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens, de sorte que le programme d’ordinateur qu’il contient est exécutable à distance. Le programme selon l'invention peut être en particulier téléchargé sur un réseau, par exemple le réseau Internet.
  • Les différents modes de réalisation mentionnés ci-dessus sont combinables entre eux pour la mise en œuvre de l'invention.
    •  Figures
  • D’autres caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description suivante d’un mode de réalisation particulier, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels :
  • présente de manière schématique les différentes étapes d’un procédé d’optimisation de la diffusion d’un contenu multicast au sein d’un réseau de communication mettant en œuvre une pluralité de tranches réseau, dans un mode de réalisation particulier de l’invention proposée ;
  •  illustre de manière schématique la mise en œuvre de tranches réseau dédiées pour l’acheminement de flux multicast selon des encodages particuliers, dans un mode de réalisation particulier de l’invention proposée ;
  •  illustre un exemple de mécanisme de souscription d’une source à un service de diffusion optimisée de flux multicast, dans un mode de réalisation particulier de l’invention proposée ;
  • décrit un exemple de formalisme particulier d’adresse IPv4, dans un mode de réalisation particulier de l’invention proposée ;
  • décrit un exemple de formalisme particulier d’adresse IPv6, dans un mode de réalisation particulier de l’invention proposée ;
  •  illustre un exemple de formalisme d’un message de signalisation IGMP de type « Query », dans un mode de réalisation particulier de l’invention proposée ;
  •  illustre un exemple de formalisme d’un message de signalisation IGMP de type « Report », dans un mode de réalisation particulier de l’invention proposée ;
  •  illustre un exemple de formalisme d’un attribut « Auxiliary Data » d’un message de signalisation IGMP de type « Query » ou « Report », dans un mode de réalisation particulier de l’invention proposée ;
  •  illustre un exemple de formalisme d’un message de type PIM « Join », dans mode de réalisation particulier de l’invention proposée ;
  •  illustre un exemple de formalisme d’un nouvel attribut d’un message de type PIM « Join », dans mode de réalisation particulier de l’invention proposée ;
  • présente de manière schématique les différentes étapes d’un procédé d’adhésion d’un terminal à un groupe multicast associé à la diffusion d’un flux multicast au sein d’un réseau de communication mettant en œuvre des tranches réseau, dans un mode de réalisation particulier de l’invention proposée ;
  • décrit une architecture simplifiée des différentes entités pour la mise en œuvre de l’invention proposée.
    • Description détaillée de l’invention
  • 1. Principe général – procédé mis en œuvre côté réseau
  • L’invention décrite ci-après permet de remédier à certains des inconvénients précités.
  • Le mécanisme proposé permet notamment de gérer de manière optimisée l’acheminement de contenus multicast au sein d’un réseau de communication mettant en œuvre des tranches réseau. À cet effet, selon le principe général de l’invention et comme détaillé par la suite, il est notamment proposé différentes adaptations des protocoles de souscription d’un terminal (source ou récepteur) à un groupe multicast et des protocoles de routage dynamique multicast d’un flux multicast acheminé au sein d’un réseau ainsi qu’une structuration particulière des adresses multicast.
  • Il est à noter que la présente invention peut être mise en œuvre indépendamment :
  • - de la nature du contenu diffusé par les sources ;
  • - des capacités d’encodage éventuellement associées à la diffusion de tels contenus ;
  • - des capacités d’accès des terminaux récepteurs aux réseaux qui supportent lesdites tranches réseau multicast ;
  • - de la nature de ces réseaux (qui peuvent être fixes et/ou mobiles) ;
  • - des choix d’ingénierie retenus eu égard à la conception, au déploiement et à l’exploitation des tranches réseau multicast.
  • Sur toutes les figures du présent document, les éléments et étapes de même nature sont désignés par une même référence numérique.
  • Dans ce qui suit, le terme « tranche réseau » doit être entendu comme pouvant se rapporter non seulement à une tranche réseau en particulier, mais également à un type de tranche réseau. Ainsi, bien que le principe général de l’invention et ses divers modes de réalisation soient par la suite généralement décrits et revendiqués comme se rapportant à des « tranches réseau », ils s’appliquent également et indifféremment lorsqu’un « type de tranche réseau » est considéré, plutôt qu’une tranche réseau en particulier (un « identifiant de tranche réseau » devant alors à ce titre être par exemple entendu comme « un identifiant de type de tranche réseau », etc.).
  • Selon un premier aspect, la présente invention se rapporte à un procédé d’optimisation de la diffusion d’un flux multicast au sein d’un réseau de communication mettant en œuvre des tranches réseau. Un tel procédé, illustré par la , est mis en œuvre par un équipement routeur (plus simplement appelé routeur par la suite) du réseau de communication, typiquement situé à la périphérie du réseau (et qui peuvent être qualifiés à ce titre de routeurs d’accès, ou de bordure).
  • Dans une étape 11, un tel routeur reçoit, en provenance d’un terminal connecté au réseau, un message de signalisation représentatif d’une demande d’adhésion de ce terminal à un groupe multicast associé à la diffusion d’un flux multicast, ce message de signalisation comprenant de manière classique une adresse multicast identifiant ledit groupe multicast. Selon la terminologie usuelle des protocoles de signalisation multicast, un tel message de signalisation est qualifié de message de type « Report » (i.e. de type « Rapport », en français), cet aspect étant détaillé ultérieurement dans le présent document. Un tel message de signalisation peut être émis par un terminal source diffusant le flux multicast ou par un terminal récepteur pour annoncer qu’il souhaite recevoir (ou continuer à recevoir) le flux multicast en question. Selon le principe général de la présente invention, ce message de signalisation comprend un identifiant de tranche réseau (ou un identifiant de type de tranche réseau), représentatif d’une tranche réseau candidate (respectivement d’un type de tranche réseau candidat) privilégiée par ledit terminal pour l’acheminement du flux multicast au sein du réseau de communication. Lorsque le terminal est une source, le réseau est ainsi notifié d’un souhait de ce terminal d’utiliser une tranche particulière (respectivement un type de tranche particulier) du réseau pour transmettre le flux multicast émis, par exemple parce que ce terminal a connaissance de l’existence d’une tranche (respectivement d’un type de tranche réseau) qu’il estime appropriée pour une telle transmission. Par exemple, un terminal source SRC apte à encoder un même contenu multicast dans différentes définitions (SD, HD, 4k, 8k, etc.) est ainsi à même de sélectionner une tranche réseau optimisée pour la transmission du flux encodé en SD, une autre tranche réseau pour la transmission du flux encodé en 8k, etc., comme illustré par la . De manière similaire, lorsque le terminal est un récepteur, le réseau est ainsi notifié d’un souhait de ce terminal de se raccorder à une tranche particulière du réseau pour la réception du flux, pour des raisons qui peuvent par exemple être identiques à celles mentionnées précédemment (par ex., en fonction de ses capacités de décodage).
  • Dans une étape 12, le routeur obtient un identifiant de tranche réseau cible pour l’acheminement du flux multicast, en fonction de l’identifiant de tranche réseau candidate (ou type de tranche réseau candidate) reçu en étape 11 et de données représentatives d’un état courant dudit réseau de communication.
  • Plus particulièrement, en relation avec cette étape 12, le réseau détermine si la tranche réseau (ou type de tranche réseau) candidate telle qu’identifiée dans un message de signalisation reçu en provenance d’un terminal est bien une tranche réseau optimale pour l’acheminement du flux multicast, compte tenu notamment d’un état courant des ressources réseau (par exemple selon des informations relatives à la disponibilité ou l’indisponibilité de certaines tranches réseau au moment de la réception de ce message de signalisation).
  • Une telle détermination peut être effectuée par le routeur en charge du traitement du message « Report », ou, de manière alternative, par un équipement de contrôle du réseau de communication (plus simplement appelé contrôleur ou contrôleur réseau dans le présent document), par exemple sur sollicitation du routeur, sur la base de données reçues en provenance de divers dispositifs de contrôle déployés au sein du réseau (par ex. des sondes logicielles). Les données représentatives d’un état courant du réseau de communication comprennent par exemple des données indiquant l’indisponibilité ou la congestion de certaines tranches, des temps de latence trop longs mesurés sur certaines tranches, des temps de transit unidirectionnel trop importants, des taux de perte de données trop élevés, etc., qui constituent autant d’indicateurs de nature à encourager un basculement d’une tranche à une autre (notamment si ces indicateurs se dégradent au fil du temps par exemple). Par exemple, un nombre croissant de récepteurs peut provoquer une surcharge de trafic dans le réseau d’accès, de nature à provoquer des ralentissements de traitement susceptibles de dégrader la qualité du service de diffusion telle que perçue par l’utilisateur (par ex. phénomènes de pixélisation, image figée, ou écran noir).
  • Ainsi, bien qu’ayant reçu d’un terminal un souhait d’utiliser une tranche réseau particulière pour la diffusion et/ou la réception du flux multicast, un équipement du réseau peut évaluer – par exemple sur la base d’indicateurs variés, et/ou lorsqu’un niveau de qualité de service prédéterminé n’est pas atteint pour la tranche candidate – que ce choix n’est pas le plus approprié ou le plus optimal, et prendre la décision d’acheminer le flux multicast sur une autre tranche, dite tranche cible. Dans un mode de réalisation, lorsque cela est possible (i.e. si une telle tranche existe), la tranche réseau cible choisie par le réseau est une tranche satisfaisant au moins aux exigences techniques de la tranche candidate (par exemple en termes de latence ou de fiabilité des échanges de données), afin de ne pas dégrader la performance et/ou la qualité du service de diffusion par rapport à la tranche candidate initialement sélectionnée par un terminal.
  • Dans un mode de réalisation particulier, l’étape 12 peut être associée à une étape complémentaire de classification du trafic, dans laquelle un équipement du réseau (par exemple un routeur de bordure) peut, sur la base de critères tels que présentés précédemment ou d’autres critères, décider de classer le trafic par un marquage idoine, ou critère de classification, différent de l'identifiant de la tranche cible.
  • Dans une étape 13, le routeur raccorde le terminal à un arbre de distribution dudit flux multicast déployé dans la tranche réseau cible déterminée à l’étape 12 (qui peut être ou bien la tranche candidate, ou bien une autre tranche, en fonction du résultat de cette étape 12), pour l’acheminement du flux multicast. Une telle étape de raccordement repose sur l’utilisation d’un protocole de routage dynamique multicast adapté pour tenir compte d’un identifiant de tranche réseau et d’un éventuel critère de classification, tel que détaillé ultérieurement dans le présent document.
  • En d'autres termes, le principe général de la présente invention repose sur :
  • - une adaptation d’un protocole de signalisation utilisé par un terminal pour souscrire à un groupe multicast, consistant à permettre au terminal de solliciter l’utilisation d’une tranche particulière, dite tranche candidate, pour la diffusion ou la récupération du flux multicast associé au groupe multicast (étape 11 de la ) ;
  • - une prise de décision par un élément du réseau (typiquement un routeur d’accès ou un contrôleur), afin de déterminer si la tranche candidate est adaptée ou non, en fonction d’un état courant du réseau de communication, pour l’acheminement du flux multicast depuis ou vers le terminal en question, et, dans la négative, une détermination et une sélection d’une autre tranche réseau garantissant une diffusion optimisée, dite tranche cible (étape 12 de la ) ;
  • - une adaptation d’un protocole de routage dynamique multicast, de manière à rendre possible l’aiguillage du flux multicast vers la tranche cible, voire vers l’arbre de distribution le plus approprié au sein de cette tranche si plusieurs arbres y sont déployés (étape 13 de la ).
  • Ce principe général exposé, on s’intéresse maintenant à différents modes de réalisation de la présente invention, notamment en ce qui concernent les aspects de signalisation et de routage (étapes 11 et 13).
    • 2. Signalisation
  • Comme décrit précédemment, un premier aspect de la technique proposée se rapporte à des adaptations des mécanismes de signalisation. Dans ce cadre, différents modes de réalisation sont présentés par la suite pour :
  • - d’une part informer un terminal des capacités du réseau pour véhiculer un flux multicast, ceci afin que le terminal puisse déterminer la tranche (ou type de tranche) qu’il souhaite privilégier (i.e. la tranche candidate), éventuellement en fonction de ses propres capacités techniques (par ex. capacités d’encodage ou de décodage) et/ou d’un contexte courant local (indisponibilités ponctuelles de certaines interfaces du terminal, par exemple), pour diffuser ou recevoir un flux multicast ;
  • - d’autre part, une fois cette tranche candidate déterminée, transmettre cette information au réseau.
  • 2.1. Informer un terminal des tranches réseau déployées dans le réseau
  • Deux mécanismes (qui peuvent éventuellement être mis en œuvre de manière complémentaire) sont proposés pour signaler aux terminaux souhaitant diffuser ou accéder à un flux multicast la variété des tranches réseau disponibles dans le réseau à cet effet, ainsi que les capacités techniques qui y sont associées, le cas échéant.
  • 2.1.1. Premier mécanisme : souscription en amont de la signalisation
  • Un premier mécanisme prend la forme d’une phase de souscription au service de diffusion optimisée de flux multicast selon l’invention proposée, mise en œuvre en amont des opérations classiques de signalisation par lesquelles un terminal manifeste son intention de rejoindre un groupe multicast. Une telle phase de souscription, illustrée par la , concerne un terminal source SRC souhaitant diffuser des contenus multicast via le réseau de communication mettant en œuvre des tranches réseau, selon l’exemple de la . Dans un tel mode de réalisation particulier, la capacité du réseau à mettre en œuvre une diffusion optimisée selon la présente invention est par exemple exposée par le réseau au moyen d’une interface de programmation d'application («  Application Programming Interface » en anglais, ou API) dédiée. Selon une caractéristique particulière, un protocole de négociation dynamique tel que le protocole CPNP (« Connectivity Provisioning Negotiation Protocol », RFC8921) est utilisé pour exposer une telle interface, le réseau hébergeant un serveur CPNP tandis que le terminal source (typiquement un serveur d’application) embarque un client CPNP. Cet exemple est toutefois non limitatif, et d’autres protocoles tel que par exemple le protocole RESTCONF (RFC8040) peuvent également être utilisés pour exposer cette API.
  • La source SRC souhaitant souscrire au service de diffusion optimisée transmet, au moyen de l’API dédiée précédemment décrite, une demande de souscription SBSC, comprenant au moins un identifiant de source, typiquement une adresse IP (éventuellement associée à un numéro de port) à laquelle la source SRC de diffusion de contenu multicast peut être contactée. Selon une caractéristique particulière, la demande de souscription SBSC comprend également des données représentatives de capacités d’encodage (par ex. SD, HD, 4k, ou 8k) supportées par la source.
  • A réception d’une demande de souscription SBSC, un élément du réseau tel qu’un contrôleur identifie, sur la base des informations transmises dans la demande de souscription, au moins une tranche réseau déployée en son sein et adaptée pour l’acheminement de flux multicast émis par la source. Le cas échéant, une nouvelle tranche peut être créée à cet effet. La décision d’instancier une nouvelle tranche dépend d’une politique locale à l’opérateur réseau.
  • En réponse à la demande de souscription, le réseau envoie à la source un message ACK_SBSC confirmant la bonne souscription au service, et une liste (i.e. au moins une) d’adresses multicast utilisables par la source pour diffuser du contenu, chaque adresse multicast étant associée à une tranche réseau particulière mise en œuvre sur le réseau de communication. Des données représentatives de caractéristiques techniques associées à chaque tranche (ou type de tranche) sont également communiquées à la source SRC. Par exemple, le réseau informe une source ou un récepteur de l’existence en son sein de tranches réseau dédiées à l’acheminement de contenus SD, HD, 4k, 8k, etc.
  • De cette manière, le terminal source dispose, par le biais d’une telle phase de souscription, d’un premier mécanisme lui permettant d’avoir connaissance des tranches réseau disponibles au sein du réseau pour diffuser un flux multicast, ainsi que de leurs caractéristiques techniques et des adresses multicast associées.
  • 2.1.2. Deuxième mécanisme : adaptation des messages de signalisation de type « Query »
  • Un deuxième mécanisme repose sur une adaptation des opérations de signalisation par lesquelles un terminal manifeste son intention de rejoindre un groupe multicast.
  • On rappelle à ce titre que de manière classique dans le cadre d’un mode de transmission multicast, des messages de signalisation sont échangés entre le réseau et les terminaux (source et/ou récepteur) qui souhaitent rejoindre un groupe multicast , et que différents protocoles de signalisation existent à cette fin, tel que par exemple le protocole IGMP (« Internet Group Management Protocol », RFC3376) dans le contexte d’un environnement IPv4, ou le protocole MLD (« Multicast Listener Discovery », RFC3810) dans le contexte d’un environnement IPv6. Ces protocoles de signalisation existants reposent sur des principes de fonctionnement similaires : un équipement requérant du réseau de communication, typiquement un routeur, émet à fréquence régulière des messages de type « Query » (i.e. de type « Requête », en français) à destination des récepteurs connectés au réseau (via une adresse multicast disponible à cet effet, par exemple l’adresse 224.0.0.1 dans le cas d’une signalisation IGMP), lesquels récepteurs peuvent former en réponse des messages de type « Report » (i.e. de type « Rapport », en français) pour adhérer à tel ou tel groupe, et indiquer ainsi qu’ils souhaitent, recevoir le flux multicast associé à ce groupe. Un message de type « Report » renseigne de façon explicite les informations de joignabilité de la source ou du récepteur (typiquement une adresse IP) ainsi que la ou les adresse(s) de groupe multicast vers laquelle la source diffuse le contenu ou à laquelle le récepteur souhaite accéder.
  • Ainsi, de manière alternative ou complémentaire au premier mécanisme de souscription présenté précédemment, il est notamment proposé d’enrichir les messages de type « Query » classiquement émis à destination des terminaux connecté au réseau de communication, afin que ces messages de signalisation comprennent, en plus des informations classiques représentatives des groupes multicast connus du routeur requérant (« IGMP/MLD Querier » en anglais), des données complémentaires représentatives des tranches réseau disponibles pour accéder aux flux multicast, complétées éventuellement par des informations sur les capacités techniques de ces tranches.
  • Il convient de noter que le deuxième mécanisme qui vient d’être décrit (adaptation des messages de signalisation de type « Query ») peut être utilisé pour communiquer de telles informations relatives aux tranches disponibles dans un réseau de communication tant à une source de diffusion pour l’émission de flux multicast qu’à un terminal récepteur souhaitant y souscrire.
  • Selon la technique proposée, de telles données sont transmises selon un formalisme particulier, décrit ultérieurement au point 2.3 du présent document.
  • 2.2. Informer le réseau de la tranche candidate privilégiée par un terminal
  • Les mécanismes permettant au réseau d’informer un terminal des tranches disponibles pour acheminer un flux multicast ayant été présentés, une autre problématique se rapporte à la manière dont un terminal indique en retour au réseau de communication la tranche réseau qu’il souhaite utiliser de manière privilégiée pour diffuser ou recevoir un flux multicast.
  • Il est proposé, selon le principe général de la présente invention, de transmettre cette information au sein d’un message de signalisation de type « Report » transmis par le terminal au routeur requérant (« IGMP/MLD Querier »), en adoptant ici également le formalisme particulier mentionné précédemment et défini ci-après.
  • 2.3. Formalisme proposé pour l’intégration d’informations identifiant des tranches réseaux au sein de messages de signalisation
  • Deux solutions alternatives ou complémentaires sont décrites ci-après, dans divers modes de réalisation particuliers de la présente invention, afin d’enrichir des messages de signalisation de type « Query » ou « Report » par des informations relatives aux tranches réseau disponibles dans le réseau de communication (pour les messages de type « Query ») ou par des informations relatives aux tranches réseau sélectionnées par un terminal pour diffuser ou accéder à un flux multicast (pour les messages de type « Report »).
  • Comme montré ci-après, ces solutions présentent plus particulièrement l’avantage de maintenir une certaine compatibilité avec les protocoles de signalisation multicast existants, notamment les protocoles IGMP et MLD largement utilisés pour la mise en place de services de diffusion multicast sur un réseau IP/MPLS.
  • Une première solution consiste à utiliser des adresses de groupe multicast d’un format particulier pour transmettre de manière transparente au niveau protocolaire des informations identifiant des tranches réseau disponibles et/ou à utiliser. Cette approche permet d’associer une adresse multicast à une tranche réseau (ou à un type de tranche réseau) d’une manière algorithmique permettant ainsi aux différents éléments (sources, récepteurs, routeurs, contrôleurs) d’extraire une information caractéristique de la tranche réseau associée. Plus particulièrement, il est proposé selon cette première solution de créer une association entre une adresse multicast et un identifiant de tranche réseau (ou un type de tranche réseau), en encodant de manière astucieuse directement cet identifiant de tranche réseau (ou type de tranche) dans l’adresse multicast en question. De cette manière, il n’est pas nécessaire de modifier la manière dont sont construits les messages de signalisation (i.e. leur format). Dans la suite, la description utilise un exemple d’implémentation de l’invention qui repose sur l’utilisation d’un identifiant de tranche réseau mais la procédure s’applique aussi lorsqu’un type de tranche est utilisé.
  • Par exemple, selon une caractéristique particulière et comme illustré en relation avec la , lorsque l’adresse de groupe multicast est une adresse IPv4, il est proposé de sélectionner une adresse de groupe multicast spécifique au sein de l’espace IPv4 239.0.0.0/10 afin d’y encoder un identifiant de tranche particulier S_ID, un tel format reposant alors sur l’utilisation d’adresses multicast de portée administrative étendue telles que documentées dans la norme RFC2365.
  • Selon une autre caractéristique particulière et comme illustré par la , lorsque l’adresse de groupe multicast est une adresse IPv6, il est proposé d’encoder l’identifiant de tranche au sein d’un champ particulier de cette adresse, par ex. dans les tout ou partie des 4 bits du champ « ff2 » de ladite adresse IPv6 (bits 17 à 20) tels que définis dans la norme RFC7371. À noter que dans ce cadre, d’autres champs de l’adresse IPv6 (typiquement les champs « fff1 », « plen » et « network prefix » peuvent également servir à déterminer l’adresse de points de rendez-vous (« Rendezvous Point » ou RP en anglais) hébergés au sein d’une tranche réseau identifiée par l’identifiant véhiculé dans le champ « fff2 » de ce nouveau format d’adresse multicast IPv6. Ce dernier aspect se réfère au cas où l’ingénierie multicast repose sur le calcul, l’établissement et la maintenance d’arbres de distribution dont la racine est un RP (plusieurs RP pouvant être hébergés au sein d’une tranche réseau), selon une ingénierie typique d’un mode ASM (« Any Source Multicast ») souvent retenue pour le déploiement de services de visioconférences ou tout autre service de diffusion caractérisé par une heuristique source/récepteur. A contrario, les ingénieries des services de diffusion « grand public » (services de diffusion de programmes télévisés par exemple) sont typiques du mode SSM (« Source Specific Multicast ») qui conduit au déploiement d’arbres dont la racine est la source de diffusion (« Shortest Path Tree » ou SPT) elle-même, cas que le format de la permet également de couvrir, par exemple en fixant les champ « plen » et « network prefix » à la valeur zéro.
  • De cette manière, l’identifiant d’une tranche réseau pour l’acheminement d’un flux multicast est directement encodé dans l’adresse de groupe multicast associé à ce contenu. La construction et la disponibilité de telles adresses peut par exemple avoir été communiquée par le réseau de communication aux terminaux susceptibles de les utiliser au moyen de l’un ou l’autre des deux mécanismes précédemment décrits (souscription ou adaptation des messages de signalisation de type « Query »).
  • Cette première solution se prête bien aux réseaux de communication configurés de telle sorte que chaque tranche réseau multicast disponible implémente un seul arbre de distribution multicast. En effet, comme rappelé en relation avec l’art antérieur, un réseau de communication organisé en tranches peut comprendre une pluralité de tranches réseau capables d’acheminer un même contenu multicast, par exemple, dans le cas de l’acheminement d’un flux vidéo, une tranche réseau conçue et dimensionnée (en termes de bande passante, de temps de transit unidirectionnel, etc.) pour acheminer du trafic encodé en 4K, une autre tranche réseau conçue et dimensionnée (en termes de bande passante, de temps de transit unidirectionnel, etc.) pour acheminer du trafic encodé en haute définition (HD), encore une autre pour acheminer le trafic encodé en définition standard (SD), etc. Dans ce cas, chaque tranche réseau héberge son propre arbre de distribution du contenu multicast. Toutefois, il est également possible, en fonction des choix de conception et/ou configuration du réseau, qu’une même tranche réseau héberge plusieurs arbres de distribution d’un même contenu multicast. Ainsi un arbre de distribution utilisé pour acheminer du contenu encodé en 4K et un autre arbre de distribution utilisé pour acheminer du contenu encodé en haute définition peuvent par exemple être déployés au sein d’une même tranche du réseau de communication. Il peut alors être utile de disposer de critères supplémentaires, en plus d’un identifiant de tranche réseau, afin que le réseau soit en mesure d’identifier un arbre de distribution particulier à utiliser au sein d’une tranche pour la diffusion du flux multicast.
  • Par ailleurs, la première solution décrite précédemment soulève la question de l’aptitude de certains terminaux à pouvoir identifier une adresse multicast particulière formatée selon cette invention et à pouvoir ainsi en extraire un identifiant de tranche. Bien que, dans un mode de réalisation de l’invention proposée, il soit prévu que les terminaux sources ou récepteurs soient adaptés pour prendre en compte un tel nouveau format, il convient d’assurer une certaine compatibilité avec des terminaux qui ne disposent pas de moyens leur permettant de détecter un tel format particulier.
  • Aussi, une deuxième solution, alternative ou complémentaire à la première, consiste à utiliser un champ de données libres des messages de signalisation (de type « Query » et/ou « Report ») pour transmettre de manière plus explicite l’identifiant de tranche (ou type de tranche) associé à un flux multicast et, le cas échéant, d’accompagner cette information de données supplémentaires, typiquement des données représentatives d’un encodage du flux multicast.
  • Selon les modes de réalisation particuliers de l’invention proposée, une telle adaptation peut être mise en œuvre :
  • - dans les messages de signalisation de type « Query », lorsqu’il s’agit par exemple (i) d’informer un terminal source de l’existence au sein du réseau de communication de tranches dédiées à l’acheminement de flux multicast selon des encodages particuliers ; ou (ii) d’informer un terminal récepteur qui n’aurait pas les capacités d’identifier qu’une adresse multicast transmise dans un tel message est définie selon un formalisme particulier (i.e. qu’elle contient un identifiant de tranche réseau associé à la diffusion du flux multicast) des tranches réseau disponibles pour la réception d’un flux multicast ;
  • - dans les messages de signalisation de type « Report », lorsqu’il s’agit par exemple de communiquer au réseau des informations complémentaires lui permettant d’identifier, parmi plusieurs arbres de distribution déployés sur une même tranche, celui à utiliser pour acheminer le flux multicast.
  • Les figures 6, 7 et 8 illustrent la mise en œuvre de cette deuxième solution dans le cadre de messages de signalisation selon le protocole de signalisation IGMP, et plus particulièrement l’utilisation du champ de données auxiliaires « Auxiliary Data » défini dans ce protocole pour véhiculer de telles informations (une implémentation selon un principe similaire pouvant également être mise en œuvre dans le cadre de messages de signalisation selon le protocole MLD). Plus particulièrement :
  • - la présente le format d’un message IGMP de type « Query » où le champ de données auxiliaires « Auxiliary Data » est visible ;
  • - la présente le format d’un message IGMP de type « Report » où le champ de données auxiliaires « Auxiliary Data » est visible ;
  • - la présente comment le champ de données auxiliaires peut plus particulièrement être formaté pour y inclure des informations relatives à un identifiant de tranche réseau SID (pour « Slice Identifier », en anglais) et à un éventuel encodage associé ENCOD_TYPE (comprenant par exemple une donnée représentative d’un encodage particulier – SD, HD, 4k, 8k, etc. – du flux multicast, ou une donnée représentative d’une absence d’information d’encodage dudit flux multicast par exemple lorsque l’attribut ENCOD_TYPE est positionné à la valeur zéro).
    • 3. Routage
  • À l’issue des étapes 11 et 12 telles que présentées en relation avec la , le routeur qui met en œuvre le procédé a identifié la tranche réseau cible à laquelle il doit raccorder le terminal pour un acheminement optimisé du flux multicast. Pour opérer en pratique un tel raccordement, il est proposé selon la présente invention d’adapter le protocole de routage du flux multicast. Plus particulièrement, il est proposé d’adapter les messages de demandes de greffe à un arbre de distribution classiquement définis selon un tel protocole afin d’y ajouter des informations permettant d’identifier la tranche réseau (ou le type de tranche) dans laquelle est hébergé l’arbre de distribution ciblé. Un message de demande de greffe, généralement désigné sous le terme de message de type « Join », a pour objectif de connecter un terminal à l’arbre de distribution chargé d’acheminer le trafic correspondant au flux multicast considéré. Une telle greffe permet ensuite par exemple à un terminal récepteur de recevoir le contenu sélectionné. Ainsi, selon une caractéristique particulière de l’invention proposée, l’identifiant de la tranche réseau cible tel qu’obtenu en étape 12 est ajouté au message de demande de greffe. Dans la mesure où une même tranche réseau est également susceptible d’héberger plusieurs arbres de distribution (par exemple un arbre pour la diffusion SD et un autre pour la diffusion HD), il est également proposé selon une autre caractéristique particulière de l’invention proposée, d’ajouter, en plus de l’identifiant de tranche réseau cible, au moins une donnée discriminante utile dans le cas où la connaissance d’une tranche réseau cible ne suffirait pas à identifier de manière unique un arbre de distribution pour la diffusion optimisée du flux multicast. Une telle donnée discriminante peut par exemple prendre la forme d’une donnée représentative d’un encodage particulier dudit flux multicast ou représentative d’une absence d’information d’encodage dudit flux multicast. De manière complémentaire, selon une caractéristique particulière, un critère de classification tel que présenté précédemment en relation avec la peut également être ajouté dans le message de demande de greffe, et être par exemple encodé dans une adresse de groupe multicast incluse dans ce message ou inséré dans un champ particulier de ce message. Via le protocole de routage dynamique, un tel critère de classification est ainsi propagé aux routeurs en charge d’acheminer le flux multicast, qui peuvent le cas échéant, en fonction de ce critère et sur la base d’autres critères éventuels, mettre en œuvre divers traitements incluant par exemple des opérations de bascule de l’acheminement du flux multicast vers d’autres tranches.
  • Dans un mode de réalisation particulier, le protocole de routage est le protocole PIM (« Protocol Independent Multicast », RFC7761), et le message de demande de greffe prend la forme d’un message de type PIM « Join » dont le format général est illustré par la , Ce message comprend un nouvel attribut MSLICE identifiant notamment la tranche réseau hébergeant l’arbre de distribution auquel le routeur souhaite se greffer. Selon une caractéristique particulière illustrée par la , ce nouvel attribut est encodé selon un formalisme Type/Longueur/Valeur (TLV, RFC5384), le champ SID (pour « Slice Identifier », en anglais) comprenant l’identifiant de la tranche réseau cible et le champ ENCOD_TYPE comprenant éventuellement une donnée représentative d’un encodage particulier (SD, HD, 4k, 8k, etc.) du flux multicast, ou une données représentative d’une absence d’information d’encodage dudit flux multicast (par exemple lorsque l’attribut ENCOD_TYPE est positionné à la valeur zéro (« 0 »)), selon des caractéristiques déjà présentées précédemment. La procédure de greffe à l’arbre de distribution identifié par un tel message PIM « Join » est alors réalisée selon le mécanisme classique du protocole PIM-SM (« PIM Sparse Mode »).
    • 4. Procédé mis en œuvre côté terminal
  • Selon un autre aspect, l’invention se rapporte également à un procédé d’adhésion d’un terminal à un groupe multicast associé à la diffusion d’un flux multicast au sein d’un réseau de communication mettant en œuvre des tranches réseau. Un tel procédé, illustré par la dans un mode de réalisation particulier, est mis en œuvre par un terminal connecté au réseau, ce terminal souhaitant diffuser (terminal source) ou recevoir (terminal récepteur) le flux multicast.
  • Dans une étape 111, le terminal obtient, à partir d’un message reçu en provenance du réseau, au moins un identifiant de tranche réseau disponible pour l’acheminement d’un flux multicast. Comme décrit précédemment pour le procédé d’optimisation de la diffusion mis en œuvre côté réseau, un tel message peut par exemple prendre la forme d’un message de signalisation de type « Query » (i.e. de type « Requête », en français), ou encore d’un message de confirmation de la souscription du terminal à un service de diffusion optimisée de flux multicast proposé par le réseau.
  • Dans une étape 112, le terminal transmet au réseau un message de signalisation (typiquement un message de signalisation de type « Report » (« Rapport », en français)) représentatif d’une demande d’adhésion au groupe multicast associé à la diffusion du flux multicast, ce message de signalisation comprenant un identifiant de tranche réseau représentatif d’une tranche réseau privilégiée par le terminal pour l’acheminement dudit flux multicast, dite tranche réseau candidate, sélectionnée parmi les identifiants de tranche réseau disponibles pour ledit acheminement obtenus en étape 111. Une telle sélection d’une tranche candidate peut notamment être effectuée en fonction de caractéristiques techniques du terminal (telles que par exemple ses capacités d’encodage et/ou de décodage d’un flux multicast), ou encore d’un état courant dudit terminal (par exemple l’indisponibilité ou la congestion de certaines de ses interfaces réseau)
  • Selon une caractéristique particulière de l’invention, le terminal qui met en œuvre le procédé d’adhésion est un terminal adapté à la prise en charge du nouveau format d’adresse multicast particulière présenté précédemment dans le cadre de la description du procédé d’optimisation de la diffusion mis en œuvre côté réseau, selon lequel un identifiant de tranche réseau peut être encodé directement dans une adresse multicast. Lorsque que le terminal (source ou récepteur) est ainsi configuré, dans un mode de réalisation particulier de l’invention :
  • - au moins un identifiant de tranche réseau disponible pour l’acheminement d’un flux multicast est extrait par le terminal d’au moins une adresse multicast comprise dans le message reçu en provenance du réseau en étape 111, au sein de laquelle il est encodé ; et/ou
  • - au moins un identifiant de tranche réseau candidate est encodé par le terminal au sein d’au moins une adresse multicast identifiant ledit groupe multicast, transmise dans ledit message de signalisation émis à destination du réseau en étape 112.
    • 5. Dispositifs
  • On présente finalement, en relation avec la les structures simplifiées d’une entité, par exemple un routeur d’un réseau de communication ou un terminal source ou récepteur, selon au moins un mode de réalisation décrit ci-dessus.
  • Comme illustré par la , une telle entité comprend au moins une mémoire 121 comprenant une mémoire tampon, au moins une unité de traitement 122, équipée par exemple d’une machine de calcul programmable ou d’une machine de calcul dédiée, par exemple un processeur P, et pilotée par le programme d’ordinateur 123, mettant en œuvre des étapes d’au moins un procédé selon au moins un mode de réalisation de l’invention.
  • A l’initialisation, les instructions de code du programme d’ordinateur 123 sont par exemple chargées dans une mémoire RAM avant d’être exécutées par le processeur de l’unité de traitement 122.
  • Si l’entité est une entité réseau (par exemple un routeur) du réseau de communication mettant en œuvre des tranches réseau, le processeur de l’unité de traitement 122 met en œuvre des étapes du procédé d’optimisation de la diffusion d’un flux multicast au sein dudit réseau tel que décrit précédemment, selon les instructions du programme d’ordinateur 123, pour :
  • - recevoir, en provenance d’un terminal connecté audit réseau, un message de signalisation représentatif d’une demande d’adhésion dudit terminal à un groupe multicast associé à la diffusion dudit flux multicast, ledit message de signalisation comprenant une adresse multicast identifiant ledit groupe multicast, et un identifiant de tranche réseau représentatif d’une tranche réseau privilégiée par ledit terminal pour l’acheminement dudit flux multicast, dite tranche réseau candidate ;
  • - obtenir un identifiant d’une tranche réseau cible pour l’acheminement dudit flux multicast, en fonction dudit identifiant de tranche réseau candidate et de données représentatives d’un état courant dudit réseau de communication ;
  • - raccorder ledit terminal à un arbre de distribution dudit flux multicast déployé dans ladite tranche réseau cible.
  • Si l’entité est un terminal connecté audit réseau de communication, typiquement un terminal source souhaitant diffuser un flux multicast ou un terminal récepteur souhaitant le recevoir, le processeur de l’unité de traitement 122 met en œuvre des étapes du procédé d’adhésion à un groupe multicast décrit précédemment, selon les instructions du programme d’ordinateur 123, pour :
  • - obtenir, à partir d’un message reçu en provenance dudit réseau, au moins un identifiant de tranche réseau disponible pour l’acheminement d’un flux multicast ;
  • - transmettre, à destination dudit réseau, un message de signalisation représentatif d’une demande d’adhésion dudit terminal audit groupe multicast, ledit message de signalisation comprenant un identifiant de tranche réseau représentatif d’une tranche réseau privilégiée par ledit terminal pour l’acheminement dudit flux multicast, dite tranche réseau candidate, sélectionnée parmi ledit au moins un identifiant de tranche réseau disponible pour ledit acheminement.
    •

Claims (15)

  1. Procédé d’optimisation de la diffusion d’un flux multicast au sein d’un réseau de communication mettant en œuvre des tranches réseau, ledit procédé étant caractérisé en ce qu'il comprend :
    - la réception (11), en provenance d’un terminal connecté audit réseau, d’un message de signalisation représentatif d’une demande d’adhésion dudit terminal à un groupe multicast associé à la diffusion dudit flux multicast, ledit message de signalisation comprenant une adresse multicast identifiant ledit groupe multicast, et un identifiant de tranche réseau représentatif d’une tranche réseau privilégiée par ledit terminal pour l’acheminement dudit flux multicast, dite tranche réseau candidate ;
    - l’obtention (12) d’un identifiant d’une tranche réseau cible pour l’acheminement dudit flux multicast, en fonction dudit identifiant de tranche réseau candidate et de données représentatives d’un état courant dudit réseau de communication ;
    - le raccordement (13) dudit terminal à un arbre de distribution dudit flux multicast déployé dans ladite tranche réseau cible.
  2. Procédé selon la revendication 1, caractérisé en ce que ledit identifiant de tranche réseau candidate est encodé dans ladite adresse multicast et/ou compris dans un champ de données libres dudit message de signalisation.
  3. Procédé selon la revendication 2, caractérisé en ce que ladite adresse de groupe multicast est une adresse IPv6, et en ce que l’identifiant de tranche réseau candidate est encodé au sein du champ ff2 de ladite adresse IPv6.
  4. Procédé selon la revendication 2, caractérisé en ce que ladite adresse de groupe multicast est une adresse IPv4, et en ce que ledit encodage de l’identifiant de tranche réseau candidate est mis en œuvre par la sélection d'une adresse de groupe multicast spécifique au sein de l’espace IPv4 239.0.0.0/10.
  5. Procédé selon la revendication 2, caractérisé en ce que ledit message de signalisation est un message de type « Report » selon le protocole de signalisation IGMP ou le protocole de signalisation MLD, et en ce que ledit champ de données libres est le champ de données auxiliaires « Auxiliary Data » défini dans ledit protocole de signalisation IGMP ou ledit protocole de signalisation MLD.
  6. Procédé selon la revendication 1, caractérisé en ce que ladite réception d’un message de signalisation représentatif d’une demande d’adhésion dudit terminal au groupe multicast associé à la diffusion dudit flux multicast fait suite à l’émission d’un message de demande de signalisation comprenant une liste de groupes multicast connus du réseau, ladite liste comprenant au moins ledit groupe multicast associé à la diffusion dudit flux multicast, identifié par ladite adresse multicast, un identifiant de tranche réseau étant encodé dans ladite adresse multicast et/ou compris dans un champ de données libres dudit message de demande de signalisation .
  7. Procédé selon la revendication 1, caractérisé en ce que le raccordement dudit terminal à un arbre de distribution dudit flux multicast déployé dans ladite tranche réseau cible comprend l’émission d’un message de demande de greffe audit arbre de distribution selon un protocole de routage dynamique, ledit message de demande de greffe comprenant un identifiant de ladite tranche réseau cible.
  8. Procédé selon la revendication 7, caractérisé en ce que ledit protocole de routage dynamique est le protocole PIM et en ce que ledit message de demande de greffe est un message de type JOIN selon ledit protocole PIM, ledit message étant adapté pour inclure un champ comprenant ledit identifiant de ladite tranche réseau cible et une donnée représentative d’un encodage dudit flux multicast ou d’une absence d’information d’encodage dudit flux multicast.
  9. Procédé selon la revendication 1, caractérisé en ce qu'il comprend, préalablement à ladite réception d’un message de signalisation de type  « Report », lorsque ledit terminal est une source de diffusion dudit flux multicast :
    - la réception, en provenance dudit terminal source, d’une requête de souscription à un service de diffusion optimisé, comprenant des données d’identification dudit terminal source et des données représentatives de capacités techniques supportées par ledit terminal source ;
    - la transmission, à destination dudit terminal source, d’un message de confirmation de souscription, comprenant au moins une association entre une adresse multicast utilisable par ledit terminal source pour la diffusion dudit flux multicast et un identifiant de tranche réseau déterminée comme étant adaptée pour la diffusion dudit flux multicast sur ledit réseau de communication, en fonction desdites données représentatives de capacités techniques supportées par ledit terminal source.
  10. Procédé selon la revendication 9, caractérisé en ce que ladite association est mise en œuvre par encodage, au sein de ladite adresse multicast utilisable par ledit terminal source pour la diffusion dudit flux multicast, dudit identifiant de tranche réseau déterminée comme étant adaptée pour la diffusion dudit flux multicast.
  11. Procédé d’adhésion d’un terminal à un groupe multicast associé à la diffusion d’un flux multicast au sein d’un réseau de communication mettant en œuvre des tranches réseau, ledit procédé étant mis en œuvre au niveau dudit terminal, ledit procédé étant caractérisé en ce qu'il comprend :
    - l’obtention (111), à partir d’un message reçu en provenance dudit réseau, d’au moins un identifiant de tranche réseau disponible pour l’acheminement d’un flux multicast ;
    - la transmission (112), à destination dudit réseau, d’un message de signalisation représentatif d’une demande d’adhésion dudit terminal audit groupe multicast, ledit message de signalisation comprenant un identifiant de tranche réseau représentatif d’une tranche réseau privilégiée par ledit terminal pour l’acheminement dudit flux multicast, dite tranche réseau candidate, sélectionnée parmi ledit au moins un identifiant de tranche réseau disponible pour ledit acheminement.
  12. Procédé d’adhésion selon la revendication 11, caractérisé en ce que :
    - ledit au moins un identifiant de tranche réseau disponible est extrait par ledit terminal d’au moins une adresse multicast comprise dans ledit message reçu ; et/ou
    - ledit au moins un identifiant de tranche réseau candidate est encodé par ledit terminal au sein d’au moins une adresse multicast identifiant ledit groupe multicast, transmise dans ledit message de signalisation.
  13. Entité réseau pour l’optimisation de la diffusion d’un flux multicast au sein d’un réseau de communication mettant en œuvre des tranches réseau, comprenant au moins un processeur configuré pour :
    - recevoir, en provenance d’un terminal connecté audit réseau, un message de signalisation représentatif d’une demande d’adhésion dudit terminal à un groupe multicast associé à la diffusion dudit flux multicast, ledit message de signalisation comprenant une adresse multicast identifiant ledit groupe multicast, et un identifiant de tranche réseau représentatif d’une tranche réseau privilégiée par ledit terminal pour l’acheminement dudit flux multicast, dite tranche réseau candidate ;
    - obtenir un identifiant d’une tranche réseau cible pour l’acheminement dudit flux multicast, en fonction dudit identifiant de tranche réseau candidate et de données représentatives d’un état courant dudit réseau de communication ;
    - raccorder ledit terminal à un arbre de distribution dudit flux multicast déployé dans ladite tranche réseau cible.
  14. Terminal apte à adhérer à un groupe multicast associé à la diffusion d’un flux multicast au sein d’un réseau de communication mettant en œuvre des tranches réseau, comprenant au moins un processeur configuré pour :
    - obtenir, à partir d’un message reçu en provenance dudit réseau, au moins un identifiant de tranche réseau disponible pour l’acheminement d’un flux multicast ;
    - transmettre, à destination dudit réseau, un message de signalisation représentatif d’une demande d’adhésion dudit terminal audit groupe multicast, ledit message de signalisation comprenant un identifiant de tranche réseau représentatif d’une tranche réseau privilégiée par ledit terminal pour l’acheminement dudit flux multicast, dite tranche réseau candidate, sélectionnée parmi ledit au moins un identifiant de tranche réseau disponible pour ledit acheminement.
  15. Programme d’ordinateur comportant des instructions pour la mise en œuvre d’un procédé selon l'une quelconque des revendications 1 à 10 lorsque ce programme est exécuté par un processeur.
EP24772310.9A 2023-09-29 2024-09-16 Procédé d'optimisation de la diffusion d'un contenu multicast au sein d'un réseau de communication mettant en oeuvre une pluralité de tranches réseau Pending EP4785538A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2310417A FR3153713A1 (fr) 2023-09-29 2023-09-29 Procédé d’optimisation de la diffusion d’un contenu multicast au sein d’un réseau de communication mettant en œuvre une pluralité de tranches réseau.
PCT/EP2024/075717 WO2025067908A1 (fr) 2023-09-29 2024-09-16 Procédé d'optimisation de la diffusion d'un contenu multicast au sein d'un réseau de communication mettant en œuvre une pluralité de tranches réseau

Publications (1)

Publication Number Publication Date
EP4785538A1 true EP4785538A1 (fr) 2026-08-05

Family

ID=88839509

Family Applications (1)

Application Number Title Priority Date Filing Date
EP24772310.9A Pending EP4785538A1 (fr) 2023-09-29 2024-09-16 Procédé d'optimisation de la diffusion d'un contenu multicast au sein d'un réseau de communication mettant en oeuvre une pluralité de tranches réseau

Country Status (4)

Country Link
EP (1) EP4785538A1 (fr)
CN (1) CN121942170A (fr)
FR (1) FR3153713A1 (fr)
WO (1) WO2025067908A1 (fr)

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102217260A (zh) * 2011-05-17 2011-10-12 华为技术有限公司 组播数据流的处理方法及upe、npe
US11356940B2 (en) * 2019-07-30 2022-06-07 Qualcomm Incorporated Mobility enhancement with network slicing
CN112954615B (zh) * 2021-02-10 2023-05-23 腾讯科技（深圳）有限公司 多播广播业务的通信方法、装置、介质及电子设备

Also Published As

Publication number Publication date
CN121942170A (zh) 2026-04-28
FR3153713A1 (fr) 2025-04-04
WO2025067908A1 (fr) 2025-04-03

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20260219

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC ME MK MT NL NO PL PT RO RS SE SI SK SM TR