Titre : Procédés et dispositifs de configuration d'un module DNS et de résolution d'adresse pour 'er la diffusion de flux de contenus multimédias dans un réseau de télécommunications

Arrière-plan de l'invention

La présente invention se situe dans le domaine de la gestion de la diffusion de flux de contenus multimédias dans un réseau de télécommunications. Elle s'applique en particulier à la diffusion de contenus audiovisuels d’un service OTT (Over the Top ou par contournement en Français). Ces contenus sont proposés au moyen d'une simple connexion Internet et délivrer en streaming unicast à un récepteur (décodeur OTT) via le Web.

Dans un mode de diffusion unicast, un équipement émetteur (serveur de streaming) appartenant généralement à un CDN (réseau de fourniture de contenu, en anglais Content Delivery Network)) émet un flux par client/équipement récepteur (décodeur OTT) ayant demandé le contenu (mode client /serveur). Par conséquent, si plusieurs clients accèdent à un même contenu simultanément, par exemple au Live (direct) d'une chaine TV, plusieurs flux identiques circulent dans le réseau. Cette méthode présente l'inconvénient d'occuper une bande passante importante du réseau en cas de demandes simultanées importantes pour un service linéaire (direct).

Cette transmission unicast est généralement réalisée avec des contenus préparés en ABR (Adaptative Bit Rate) ou à débit binaire adaptatif dans lequel le contenu source est codé selon plusieurs débits binaires, chacun segmenté en petites parties de plusieurs secondes, typiquement entre deux et dix secondes, les segments des flux disponibles et leurs débits binaires respectifs étant renseignés dans un fichier téléchargeable par les clients (décodeurs OTT). Lorsqu'un client commence à recevoir un flux, il demande généralement les segments du flux à débit binaire le plus faible et s'il détermine que le débit du réseau est supérieur au débit du segment téléchargé, il demande un segment à débit plus élevé. Au contraire, si un client constate que le débit du réseau s’est détérioré, il peut demander un segment à débit plus faible. Chaque client met en œuvre un algorithme de débit binaire adaptatif pour décider quels segments à débit binaire télécharger, en fonction de l’état actuel du réseau.

Historiquement, la diffusion de flux Linéaire utilisait des méthodes de transmission point à multipoints comme le Broadcast (câble, satellite...) ou le Multicast (IPTV...), ces méthodes consistant à émettre un seul flux à destination d'une pluralité de récepteurs. Ces méthodes économisent de la bande passante puisque dans le réseau, un seul flux circule pour l'ensemble des récepteurs. En revanche ces méthodes nécessitaient l'utilisation de récepteurs dédiés au mode de transmission (Récepteur Satellite , décodeur IPTV...) et aux caractéristiques du réseau de transmission (association chaine TV et fréquence de diffusion ou adresse multicast...) ce qui n'est pas compatibles avec des décodeurs OTT. Depuis 2020, de nouveaux standards sont apparus tel que le M-ABR (exemple : DVB ETSI TS 103 769 VI.1.1, standard inspiré des travaux antérieurs 3GGP et ATSC) combinant les formats d'encodage et de conditionnement des médias existants (ABR) avec l'efficacité de la distribution point à multipoint jusqu'à la périphérie des réseaux d'accès basés sur IP. Il devient possible de concevoir un système de distribution linéaire des médias à la fois efficace et évolutif vers de très larges audiences, tout en restant techniquement compatible avec le plus grand ensemble possible d'équipements d'utilisateurs finaux déjà déployés (décodeurs OTT). Les topologies point à multipoint offrent également des possibilités de pré-positionnement efficace des actifs sur les appareils à la périphérie du réseau. Cela prend en charge des cas d'utilisation non linéaires supplémentaires et peut aider à atténuer la demande de pointe sur le réseau d'accès aux points de synchronisation dans l'horaire linéaire.

L'invention vise en particulier un mécanisme pour aiguiller les requêtes d'accès à des contenus émises par le client (décodeur OTT). Dans le standard DVB (DVB ETSI TS 103 769 VI.1.1), le dispositif en charge d'un tel dispositif d'aiguillage porte le nom de rendez-vous service. Il permet de rediriger une requête d'accès à un contenu soit vers un serveur unicast CDN (le mode classique), soit une « passerelle multicast » (en anglais « multicast gateway »). La passerelle multicast reçoit les contenus via un transport multicast (voir broadcast) et les délivre au client en unicast.

La figure 1 représente un premier procédé de gestion de diffusion de flux multimédia en unicast vers un récepteur OTT, ce procédé étant conforme à l'état de la technique.

Un dispositif récepteur OTT (en anglais OTT end device) comporte une application CP_APP d'un fournisseur de contenu (en anglais Content Provider Application), un décodeur de flux multimédia et un module DNS (en anglais Domain Name Server) référencé DNSJDTT.

Ce dispositif récepteur OTT est connecté par un réseau local LAN à une passerelle domestique HGW (Home Gateway en anglais). Cette passerelle domestique HGW comporte un module DNS, référencé DNS_HGW.

La passerelle domestique HGW est connectée à un réseau de télécommunications NET comportant un serveur DNS DNS_NET.

Un serveur de contenu (en anglais Content Provider server ou CP server) CP_SRV d'un réseau de diffusion de contenu (en anglais Content Delivery Network) CDN est connecté au réseau NET. On note « CP.net», le nom de domaine (FQDN, en anglais Fully Qualified Domain Name) et « @IP_CDN », l'adresse IP du serveur de contenu CP_SRV.

Dans ce document, les noms de domaine sont en fait les noms de domaine pleinement qualifiés, on utilise l'expression nom de domaine dans un souci de simplification.

Lorsque l'utilisateur du dispositif récepteur OTT souhaite accéder au contenu délivré par le serveur de contenu CP_SRV, le dispositif OTT envoie (étape 1E10) une requête «RESOLVE CP.net » pour résoudre le nom de domaine FQDN de ce serveur.

Cette requête est reçue par le module DNS DNSJDTT du dispositif récepteur OTT et si ce module ne peut pas résoudre la requête (c'est-à-dire s'il n'a jamais traité une requête similaire ou si la réponse qu'il détient est devenue obsolète) ,il transfère la requête au module DNS suivant pour résolution, soit au DNS_HGW de la passerelle domestique HGW. Sur ce même principe, si ce module DNS_HGW ne peut pas résoudre la requête, il la transmet au serveur DNS suivant, c'est-à-dire dans cet exemple au serveur DNS DNS_NET du réseau.

Le serveur DNS DNS_NET du réseau renvoie (étape 1E20) l'adresse IP @IP_CDN de diffusion de contenu CP au module DNS l'ayant interrogé, c'est-à-dire au module DNS DNS_HGW, et cela se répète jusqu' au dispositif récepteur OTT.

Le dispositif récepteur OTT envoie (étape 1E30) une requête « GET CP.net/content » à l'adresse IP @IP_CDN pour obtenir (étape 1E40) le contenu du serveur de contenu CP_SRV en mode unicast.

La figure 2 représente un deuxième procédé de gestion de diffusion de flux multimédia conforme à l'état de la technique et illustre en particulier trois modules fonctionnels supplémentaires permettant de délivrer au dispositif récepteur OTT un contenu en multicast ABR M-ABR (par exemple conformément à l'architecture de référence DVB ETSI TS 103 769 VI.1.1).

Un module « Multicast server » (MC_SRV), ou « serveur multicast », récupère du serveur de diffusion de contenu CP_SRV, les contenus (étape 2E70) à émettre et les diffuse en mode point- multipoints (étape 2E80). Conformément au protocole M-ABR, le mode de diffusion est réalisé en multicast.

Un module « Rendez Vous Service » (RDV) a la connaissance des contenus diffusés en M-ABR. L'application CP_APP du dispositif récepteur PTT s'adresse au module RDV pour obtenir un contenu du serveur de contenu CP_SRV (étape 2E90).

Dans un mode « REDIRECT » particulier de réalisation décrit ici, le module rendez-vous service RDV répond à l'application CP_APP (étapes 2E101 et 2E102) d'aller chercher directement le contenu désiré en unicast sur la Multicast Gateway (étapes 2E112 et 2E122) ou sur le serveur CP_SRV (étapes 2E111 et 2E121).

Une passerelle de diffusion multicast (module de MC_GW) a pour rôle de récupérer le contenu demandé (étape 2E112) diffusé en multicast(en cas de M-ABR). A cet effet, la passerelle de diffusion multicast MC_GW s'abonne au flux multicast correspondant (étape 2E80) et le transmet à l'application CP_APP à l'étape 2E122.

La figure 3 représente un procédé de gestion de diffusion de flux multimédia en mode M-ABR conforme à l'état de la technique dans lequel :

- le serveur multicast MC_SRV et le module rendez-vous service RDV sont localisés dans le réseau NET de l'opérateur ; et

- la passerelle de multidiffusion multicast MC_GW est intégrée dans la passerelle domestique HGW.

De façon connue, le serveur multicast MC_SRV utilise des ressources de diffusion point multipoint (étape 3E02) mises à disposition par l'opérateur du réseau (dans le cadre du M-ABR, ces ressources sont des adresses IP multicast) et récupère les contenus à diffuser en M-ABR (étape 3E01) au niveau du serveur de contenu CP_SRV. Le module de rendez-vous service RDV doit également avoir la connaissance des contenus diffusés en M-ABR et la passerelle de diffusion multicast MC_GW connait l'association entre le (ou les) contenu(s) diffusé(s) en M-ABR et la (ou les) ressource(s) de diffusion point multipoints utilisé(s) réalisée au niveau du serveur multicast MC_SRV.

Dans cet exemple, lors de l'activation du module RDV dans le réseau, l'opérateur de réseau déclare deux nouvelles règles (étape 3E03) dans le DNS réseau (DNS_NET) :

- la première règle (CP.net=>@IP_RDV) redéfinit la résolution du FQDN principal « CP.net » soit par l'adresse IP @IP_RDV du module RDV (en remplacement de l'adresse IP du serveur CP_SRV de diffusion de contenu). En variante non représentée ici, le FQDN principal « CP.net » peut être résolu par un nouveau FQDN « RDV.net » qui est résolu par l'adresse IP du module RDV ;

- la seconde règle (CPBIS.net=>@IP_CDN) définit un FQDN secondaire « CPBIS.net » résolue par l'adresse IP @IP_CDN du serveur de contenu CP_SRV.

Par ailleurs, au niveau de la passerelle domestique HGW, lors de l'activation de la passerelle de diffusion multicast MC_GW, une nouvelle règle DNS (MC_GW.Ian => @IP_MC_GW) est insérée (étape 3E05) dans le DNS DNS_HGW de la passerelle domestique HGW résolvant l'URL « MC_GW.Ian » par l'adresse IP @IP_MC_GW de la passerelle de diffusion multicast.

Au cours d'une étape 3E04, la passerelle de diffusion multicast MC_GW s'enregistre dans une base de données au niveau du module rendez-vous service RDV. Ainsi quand un dispositif sollicite le module rendez-vous service RDV via cette passerelle domestique HGW, le module rendez-vous service RDV sait si une passerelle de diffusion multicast MC_GW est présente pour ce dispositif.

Dans l'exemple de la figure 3, lorsque l'application CP_APP du dispositif récepteur OTT réalise la résolution du nom de domaine « CP.net », il obtient l'adresse IP @IP_RDV du module rendez-vous service RDV (étapes 3E10, 3E20), ainsi sa demande de contenu (étape 3E30) est redirigée vers le module RDV.

Le module rendez-vous service RDV réalise un fonction d'aiguillage. En effet, la réponse à la demande de contenu est une demande de redirection de la requête vers le FQDN «MC_GW.Ian » (étape 3E42) si d'une part la passerelle de diffusion multicast MC_GW a été enregistrée sur le module rendez-vous service RDV et si d'autre part, le contenu est diffusé en mode M-ABR. Cette réponse, une fois résolue (étapes 3E52 et 3E62) permet au dispositif récepteur OTT d'obtenir le contenu de la passerelle de diffusion multicast MC_GW (étapes 3E72, 3E82 et 3E92).

Au contraire, si la passerelle de diffusion multicast MC_GW n'a pas été enregistrée dans la base de données, ou si le contenu demandé n'est pas diffusé en mode M-ABR ; la réponse à le demande de contenu (3E30) est une requête de redirection vers le FQDN secondaire « CPBIS.net » qui une fois résolue (étapes 3E51 et 3E61) permettra d'obtenir le contenu du serveur de contenu CP_SRV (étapes 3E71 et 3E81).

Il est important de noter que ce procédé de diffusion présente un inconvénient majeur en ce qu'il nécessite de déclarer (à l'étape 3E04), la passerelle de diffusion multicast MC_GW auprès du module rendez-vous service RDV. En effet, en supposant que cet enregistrement ne soit pas effectué, et donc que le module rendez- vous service renvoie systématiquement, à l'étape 3E42, dès lors que le contenu demandé est accessible en multicast, une instruction de redirection vers un nom de domaine associé à une passerelle de diffusion multicast, même en l'absence d'une telle passerelle MC-GW, alors, l'étape 3E52 de résolution de ce nom de domaine entraînerait une rupture de service, typiquement une erreur de code HTTP 404. Pour éviter un tel désagrément, une solution connue consiste à gérer une telle réponse au niveau de l'application CP_APP du décodeur OTT pour rediriger la requête vers le serveur ce contenu CP_SRV pour une réception en unicast.

Cette solution n'est pas satisfaisante en ce qu'elle impose une modification du logiciel des récepteurs OTT.

L'invention vise un procédé de diffusion qui ne présente pas ces inconvénients.

Objet et résumé de l'invention

Ainsi, et selon un premier aspect, l'invention concerne un procédé de configuration d'un module DNS mis en œuvre par une passerelle domestique configurée pour interconnecter un réseau local avec un réseau d'opérateur, ladite configuration comportant avec au moins :

(i) un enregistrement d'un nom de domaine pointant vers une passerelle de multidiffusion comprise dans ladite passerelle domestique et configurée pour répondre à une requête d'accès à un contenu reçue sur le réseau local, par l'envoi de ce contenu en monodiffusion, ledit contenu étant reçu en multidiffusion par la passerelle de multidiffusion en provenance d'un serveur de multidiffusion de ce contenu via le réseau de l'opérateur ;

(ii) une règle de résolution d'un nom de domaine d'au moins un serveur de contenu avec l'adresse d'un module d'aiguillage localisé dans le réseau de l'opérateur, ledit module d'aiguillage étant configuré pour, sur réception d'une requête d'accès à un contenu :

- répondre par une requête de redirection vers ledit nom de domaine pointant vers ladite passerelle de multidiffusion si le contenu doit être accédé en multidiffusion ; et

- répondre par une requête de redirection vers un nom de domaine secondaire pouvant être résolu en l'adresse du serveur dudit contenu si le contenu doit être accédé en monodiffusion.

Corrélativement, l'invention concerne un dispositif de configuration d'un module DNS compris dans une passerelle domestique configurée pour interconnecter un réseau local avec un réseau d'opérateur, ladite configuration comportant avec au moins :

(i) un enregistrement d'un nom de domaine pointant vers une passerelle de multidiffusion comprise dans ladite passerelle domestique et configurée pour répondre à une requête d'accès à un contenu reçue sur le réseau local, par l'envoi de ce contenu en monodiffusion, ledit contenu étant reçu en multidiffusion par la passerelle de multidiffusion en provenance d'un serveur de multidiffusion de ce contenu via le réseau de l'opérateur ;

(ii) une règle de résolution d'un nom de domaine d'au moins un serveur de contenu avec l'adresse IP d'un module d'aiguillage localisé dans le réseau de l'opérateur, ledit module d'aiguillage étant configuré pour, sur réception d'une requête d'accès à un contenu :

- répondre par une requête de redirection vers le nom de domaine pointant vers ladite passerelle de multidiffusion si le contenu doit être accédé en multidiffusion ; et

- répondre par une requête de redirection vers un nom de domaine secondaire pouvant être résolu en l'adresse dudit serveur de contenu si le contenu doit être accédé en monodiffusion.

Le procédé de configuration d'un module DNS selon l'invention est remarquable en ce qu'il permet d'aiguiller intelligemment le flux en unicast ou en multicast vers le récepteur OTT selon le mode de diffusion de ce flux, sans nécessiter d'enregistrement préalable ou de déclaration de la passerelle de diffusion multicast auprès du module rendez-vous service, ni de modification du logiciel des récepteurs OTT.

L'invention vise également un dispositif de résolution d'adresse configuré par le procédé de configuration mentionné ci-dessus et un procédé de résolution d'adresse mis en œuvre par un tel dispositif.

Ainsi, selon un deuxième aspect, l'invention concerne un procédé de résolution d'adresse mis en œuvre par une entité constituée par une passerelle domestique configurée pour interconnecter un réseau local avec un réseau d'opérateur, ce procédé comportant :

- une étape de réception d'une requête de résolution d'un nom de domaine d'un serveur de contenu

- une étape de réponse à ladite requête de résolution par l'envoi de l'adresse IP d'un module d'aiguillage localisé dans le réseau de l'opérateur, ledit module d'aiguillage étant configuré pour, sur réception d'une requête d'accès à un contenu,:

- répondre par une requête de redirection vers un nom de domaine d'une passerelle de multidiffusion comprise dans ladite passerelle domestique si le contenu doit être accédé en multidiffusion ; et

- répondre par une requête de redirection vers un nom de domaine secondaire pouvant être résolu en l'adresse d'un serveur dudit contenu si le contenu doit être accédé en monodiffusion.

Corrélativement, l'invention concerne un dispositif de résolution d'adresse destiné à être intégré dans une passerelle domestique configurée pour interconnecter un réseau local avec un réseau d'opérateur, ce dispositif comportant :

- un module de réception, d'une requête de résolution d'un nom de domaine d'un serveur de contenu ; et

- un module d'envoi d'une réponse à ladite requête de résolution, ladite réponse comportant l'adresse IP d'un module d'aiguillage localisé dans le réseau de l'opérateur, ledit module d'aiguillage étant configuré pour, sur réception d'une requête d'accès à un contenu,:

- répondre par une requête de redirection vers le nom de domaine d'une passerelle de multidiffusion comprise dans ladite passerelle domestique si le contenu doit être accédé en multidiffusion ; et

- répondre par une requête de redirection vers un nom de domaine secondaire pouvant être résolu en l'adresse d'un serveur dudit contenu si le contenu doit être accédé en monodiffusion. L'invention concerne aussi une passerelle domestique configurée pour interconnecter un réseau local avec un réseau d'opérateur, cette passerelle étant caractérisée en ce qu'elle comporte un dispositif de configuration tel que mentionné ci-dessus.

L'invention concerne aussi une passerelle de multidiffusion intégrée à une passerelle domestique telle que mentionnée ci-dessus et configurée pour répondre à une requête d'accès à un contenu par l'envoi en monodiffusion de ce contenu, ce contenu étant reçu par ladite passerelle de multidiffusion en multidiffusion à partir d'un serveur de diffusion multicast de ce contenu, ladite passerelle de multidiffusion comportant un dispositif de configuration tel que mentionné ci-dessus.

Dans un mode de réalisation de l'invention, le procédé de configuration est mis en œuvre sur détection de la présence de la passerelle de multidiffusion. Dans ce mode de réalisation, dès que la passerelle domestique détecte la présence de la passerelle de diffusion, elle configure son DNS avec les deux règles (i) et (ii) précitées.

Dans un mode de réalisation, le procédé de configuration est mis en œuvre par la passerelle de multidiffusion, préférentiellement dès son démarrage. Dans ce mode de réalisation, c'est la passerelle de multidiffusion qui configure elle-même le DNS de la passerelle domestique avec les deux règles (i) et (ii) précitées.

Dans un mode particulier de réalisation, les différentes étapes du procédé de configuration et/ou du procédé de résolution d'adresse sont déterminées par des instructions de programmes d’ordinateurs ou sont implémentées par une puce en silicium qui comprend des transistors adaptés pour constituer des portes logiques d’une logique câblée non programmable.

En conséquence, l’invention vise aussi un programme d’ordinateur sur un support d’informations, ce programme étant susceptible d’être mis en œuvre dans un ordinateur contrôleur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes d’un procédé de configuration et/ou de résolution d'adresse tel que décrit ci-dessus.

Ce programme peut utiliser n’importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable.

L’invention vise aussi un support d’informations lisible par un ordinateur, et comportant des instructions d’un programme d’ordinateur tel que mentionné ci-dessus. Le support d’informations 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, une mémoire non volatile de type flash ou encore un moyen d’enregistrement magnétique, par exemple un disque dur. D’autre part, le support d’informations 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. Le programme selon l’invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d’informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l’exécution du procédé en question. Brève description des dessins :

D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent des exemples de réalisation dépourvus de tout caractère limitatif. Sur les figures :

- la figure 1, déjà décrite, représente un procédé de gestion de diffusion de flux multimédia en unicast conforme à l'état de la technique ;

- la figure 2, déjà décrite, représente un autre procédé de gestion de diffusion de flux multimédia conforme à l'état de la technique ;

- la figure 3, déjà décrite, représente un autre procédé de gestion de diffusion de flux multimédia conforme à l'état de la technique ;

- la figure 4 représente un procédé de configuration et un procédé de résolution d'adresse conformes à un mode particulier de réalisation de l'invention ;

- la figure 5 représente un dispositif de configuration conforme à un mode particulier de réalisation de l'invention ;

- la figure 6 représente un dispositif de résolution d'adresse conforme à un mode particulier de réalisation de l'invention ; et

- la figure 7 représente une passerelle domestique, et une passerelle de multidiffusion conformes à un mode particulier de réalisation de l'invention.

Description détaillée

La figure 4 représente un procédé de configuration d'un module DNS et un procédé de résolution d'adresse conformes à un mode particulier de réalisation de l'invention.

Dans ce mode de réalisation, le procédé de configuration et le procédé de résolution d'adresse est mis en œuvre par une passerelle domestique HGW réalisant l'interconnexion entre un réseau local LAN et un réseau d'opérateur NET.

Dans ce mode de réalisation, la passerelle domestique HGW comporte un module DNS DNS_HGW et une passerelle de multidiffusion multicast MC_GW.

Sur la figure 4, on a représenté un serveur de contenu CP_SRV d'un réseau de diffusion de contenu CDN est connecté au réseau NET. On note respectivement « CP.net», le nom de domaine FQDN et « @IP_CDN », l'adresse IP du serveur de contenu CP_SRV.

Sur la figure 4, on a représenté un dispositif récepteur OTT comportant une application CP_APP d'un fournisseur de contenu, un décodeur non représenté et un module DNS DNSJDTT.

Un serveur multicast MC_SRV du réseau de l'opérateur NET utilise des ressources de diffusion point multipoint (étape 4E02) et récupère les contenus à diffuser en mode M-ABR (étape 4E01) au niveau du serveur de contenu CP_SRV.

Un module d'aiguillage RDV assurant une fonction de rendez-vous service est installé dans le réseau NET de l'opérateur. Dans le mode de réalisation décrit ici, au cours d'une étape 4E03, lors de l'activation du module d'aiguillage RDV dans le réseau, l'opérateur de réseau déclare une nouvelle règle dans le DNS réseau DNS_NET (CPBIS.net=>@IP_CDN) qui définit un FQDN secondaire « CPBIS.net » résolue par l'adresse IP @IP_CDN du serveur de contenu CP_SRV.

Au cours d'une étape 4E04, un contrôleur CTR de la passerelle domestique HGW détecte la présence de la passerelle de multidiffusion MC_GW.

Au cours de cette même étape 4E04, le contrôleur CTR configure le module DNS DNS_HGW de la passerelle domestique. Plus précisément : il enregistre un nom de domaine MC_GW.Ian pointant vers la passerelle de multidiffusion MC_GW. La passerelle de multidiffusion MC_GW étant comprise dans la passerelle domestique HGW, la passerelle de multidiffusion MC_GW et la passerelle domestique HGW ont la même adresse IP est l'adresse IP @IP_MC_GW; il enregistre une règle (CP.net=>@IP_RDV) qui redéfinit la résolution du FQDN principal

« CP.net » du serveur de contenu CP_SRV par l'adresse IP @IP_RDV d'un module d'aiguillage RDV localisé dans le réseau de l'opérateur.

Au cours d'une étape 4E10, le dispositif récepteur OTT envoie une requête RESOLVE CP.net pour résoudre le nom de domaine principal du serveur de contenu CP_SRV.

Cette requête est reçue par le module DNS DNSJDTT du dispositif récepteur OTT et transférée au module DNS DNSJHGW de la passerelle domestique.

Le module DNS DNS_HGW de la passerelle domestique répond (étape 4E20) au dispositif récepteur OTT que l'adresse IP du serveur de contenu CP_SRV est l'adresse IP @IP_RDV du module d'aiguillage RDV.

Le dispositif récepteur OTT envoie (étape 4E30) une requête d'accès à un contenu GET CP.net/content à l'adresse IP @IP_RDV du module d'aiguillage RDV.

Au cours d'une étape 4E50, le module d'aiguillage RDV détermine si l'URL associée au contenu est, dans un fichier de configuration, associée à un mode de diffusion multicast ABR.

Si c'est le cas, le module d'aiguillage RDV envoie (étape 4E42) au dispositif récepteur OTT une requête de redirection REDIRECT MC_GW.Ian/content pour que celui-ci envoie sa requête d'accès au contenu à destination de la passerelle de multidiffusion MC_GW.

Au cours d'une étape 4E52, le dispositif récepteur OTT envoie une requête «RESOLVE MC_GW.Ian » pour résoudre le nom de domaine FQDN de la passerelle de multidiffusion MC_GW.

Cette requête est reçue par le module DNS DNSJDTT du dispositif récepteur OTT et transférée au module DNS DNS_HGW de la passerelle domestique HGW.

La passerelle domestique HGW renvoie (étape 4E62) au au dispositif récepteur OTT l'adresse IP @IP_MC_GW de la passerelle de multidiffusion MC_GW. Il s'agit également de l'adresse IP de la passerelle domestique HGW. Le dispositif récepteur OTT envoie (étape 4E72) la requête « GET MC_GW.Ian/content » d'accès au contenu à l'adresse IP de la passerelle de multidiffusion MC_GW.

Cette passerelle de multidiffusion MC_GW assure la conversion, en unicast pour restitution par le dispositif récepteur OTT, du flux reçu en multicast en provenance du serveur de diffusion multicast MC_SRV.

La passerelle de multidiffusion MC_GW envoie (étape 4E92) en unicast au décodeur DEC, le contenu reçu (4E82) en multicast du serveur de diffusion multicast MC_SRV.

Si, au cours de l'étape 4E50, le module d'aiguillage RDV détermine que l'URL associée au contenu n'est pas associée à un mode de diffusion multicast ABR, le module d'aiguillage RDV envoie (étape 4E41) au dispositif récepteur OTT une requête de redirection REDIRECT CPBIS.net/content vers le FQDN secondaire du serveur de contenu CP_SRV.

Au cours d'une étape 4E51, le dispositif récepteur OTT envoie une requête «RESOLVE CPBIS.net » pour résoudre le nom de domaine FQDN secondaire du serveur de contenu unicast CP_SRV.

Cette requête est reçue par le module DNS DNSJDTT du dispositif récepteur OTT et transférée au module DNS DNSJHGW de la passerelle domestique HGW, qui la transfère au module DNS DNS_NET de l'opérateur.

Le module DNS_NET de l'opérateur renvoie (étape 4E61) au dispositif récepteur OTT l'adresse IP @IP_CDN du serveur de contenu unicast CP_SRV.

Le dispositif récepteur OTT envoie (étape 4E71) la requête « GET CPBIS.net/content» d'accès au contenu à l'adresse IP IP_CDN du serveur de contenu unicast CP_SRV.

Le serveur de contenu unicast CP_SRV envoie le contenu au dispositif récepteur OTT au cours d'une étape 4E81.

La figure 5 représente un dispositif DC de configuration d'un module conforme à l'invention. Ce dispositif est destiné à être intégré dans une passerelle domestique HGW entre un réseau local et un réseau d'opérateur NET, la passerelle domestique HGW comportant une passerelle de multidiffusion MC_GW.

Dans le mode de réalisation décrit ici, le dispositif de configuration DC a l'architecture matérielle d'un ordinateur II comporte un processeur 10, une mémoire morte de type ROM 11, une mémoire vive 12, une mémoire non volatile réinscriptible 14 et des moyens de communication 15.

La mémoire morte de type ROM 11 constitue un support d'enregistrement au sens de l'invention. Elle comporte un programme d'ordinateur PGC comportant des instructions pour l'exécution des étapes d'un procédé de configuration conforme à l'invention lorsque ce programme est exécuté par le processeur 10.

En particulier, les moyens de communication 15 sont configurés pour configurer un module DNS DNS_HGW avec des règles de configuration comportant au moins :

(i) un enregistrement d'un nom de domaine MC_GW.fr pointant vers la passerelle de multidiffusion MC_GW ; (ii) une règle de résolution d'un nom de domaine CP.net d'au moins un serveur de contenu CP_SRV avec l'adresse IP @IP_RDV d'un module d'aiguillage RDV localisé dans le réseau de l'opérateur NET,

La figure 6 représente un dispositif de résolution d'adresse DR conforme à l'invention. Ce dispositif est destiné à être intégré dans une passerelle domestique HGW entre un réseau local et un réseau d'opérateur NET.

Dans le mode de réalisation décrit ici, le dispositif de résolution d'adresse DR a l'architecture matérielle d'un ordinateur II comporte un processeur 20, une mémoire morte de type ROM 21, une mémoire vive 22, une mémoire non volatile réinscriptible 24 et des moyens de communication 25.

La mémoire morte de type ROM 21 constitue un support d'enregistrement au sens de l'invention. Elle comporte un programme d'ordinateur PGR comportant des instructions pour l'exécution des étapes d'un procédé de résolution d'adresse conforme à l'invention lorsque ce programme est exécuté par le processeur 20.

Les moyens de communication 25 sont notamment configurés pour recevoir une requête de résolution d'un nom de domaine d'un serveur de contenu et envoyer, en réponse à cette requête de résolution, une réponse comportant l'adresse IP d'un module d'aiguillage RDV localisé dans le réseau de l'opérateur, ce module d'aiguillage RDV étant configuré pour, sur réception d'une requête d'accès à un contenu :

- répondre par une requête de redirection vers un nom de domaine d'une passerelle de multidiffusion comprise dans la passerelle domestique si le contenu doit être accédé en multidiffusion ; et

- répondre par une requête de redirection vers un nom de domaine secondaire pouvant être résolu en l'adresse d'un serveur du contenu si le contenu doit être accédé en monodiffusion.

La figure 7 représente une passerelle domestique HGW et une passerelle de multidiffusion MC_GW conformes à l'invention.

La passerelle domestique HGW comporte un module DNS DNS-HGW, un dispositif DC de configuration et un dispositif DR de résolution d'adresse conformes à l'invention.

Dans un mode de réalisation, le dispositif de configuration DC est intégré à la passerelle de multidiffusion MC_GW. La passerelle de multidiffusion est alors conforme à l'invention.

Dans un autre mode de réalisation, le dispositif DC de configuration de la passerelle domestique HGW n'est pas intégré dans la passerelle de multidiffusion MC_GW.

Dans un mode de réalisation, le dispositif de résolution d'adresse DR est intégré au module DNS DNSJHGW.