EP4595411A1 - Procédés et dispositifs de configuration d'un module dns et de résolution d'adresse pour gérer la diffusion de flux de contenus multimédias dans un réseau de télécommunications - Google Patents

Procédés et dispositifs de configuration d'un module dns et de résolution d'adresse pour gérer la diffusion de flux de contenus multimédias dans un réseau de télécommunications

Info

Publication number
EP4595411A1
EP4595411A1 EP23782181.4A EP23782181A EP4595411A1 EP 4595411 A1 EP4595411 A1 EP 4595411A1 EP 23782181 A EP23782181 A EP 23782181A EP 4595411 A1 EP4595411 A1 EP 4595411A1
Authority
EP
European Patent Office
Prior art keywords
content
multicast
net
gateway
request
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
EP23782181.4A
Other languages
German (de)
English (en)
Inventor
Elisabeth Lepoil
Sylvain CHAUVEL
Serge Rigaudeau
Philippe GRAVE
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 EP4595411A1 publication Critical patent/EP4595411A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast

Definitions

  • the present invention is in the field of managing the distribution of multimedia content streams in a telecommunications network. It applies in particular to the broadcasting of audiovisual content from an OTT (Over the Top or over-the-top in French) service.
  • OTT Over the Top or over-the-top in French
  • This content is offered using a simple Internet connection and delivered in unicast streaming to a receiver (OTT decoder) via the Web.
  • a transmitter equipment In a unicast broadcast mode, a transmitter equipment (streaming server) generally belonging to a CDN (Content Delivery Network) transmits a stream per client/receiver equipment (OTT decoder) having requested the content (client/server mode). Consequently, if several clients access the same content simultaneously, for example live (direct) from a TV channel, several identical streams circulate in the network.
  • This method has the disadvantage of occupying significant network bandwidth in the event of significant simultaneous requests for a linear (direct) service.
  • This unicast transmission is generally carried out with content prepared in ABR (Adaptive Bit Rate) or adaptive bit rate in which the source content is encoded according to several bit rates, each segmented into small parts of several seconds, typically between two and ten seconds, the segments of the available streams and their respective bit rates being entered in a file downloadable by clients (OTT decoders).
  • ABR Adaptive Bit Rate
  • OTT decoders clients
  • Each client implements an adaptive bitrate algorithm to decide which bitrate segments to download, based on the current network state.
  • Linear stream broadcasting used point-to-multipoint transmission methods such as Broadcast (cable, satellite, etc.) or Multicast (IPTV, etc.), these methods consisting of transmitting a single stream to a plurality of of receptors. These methods save bandwidth since in the network, a single flow circulates for all receivers. On the other hand, these methods required the use of receivers dedicated to the transmission mode (Satellite receiver, IPTV decoder, etc.) and to the characteristics of the transmission network (TV channel association and broadcast frequency or multicast address, etc.), which does not is not compatible with OTT decoders.
  • the invention aims in particular at a mechanism for directing requests for access to content sent by the client (OTT decoder).
  • OTT decoder the device in charge of such a switching device is called a service appointment. It allows you to redirect a content access request either to a CDN unicast server (classic mode) or to a “multicast gateway”.
  • the multicast gateway receives content via multicast transport (see broadcast) and delivers it to the client in unicast.
  • Figure 1 represents a first method for managing the distribution of unicast multimedia streams to an OTT receiver, this method being consistent with the state of the art.
  • An OTT receiver device (in English OTT end device) comprises a CP_APP application of a content provider (in English Content Provider Application), a multimedia stream decoder and a DNS module (in English Domain Name Server) referenced DNSJDTT.
  • a content provider in English Content Provider Application
  • a multimedia stream decoder in English Domain Name Server
  • This OTT receiver device is connected by a local LAN network to a HGW home gateway (Home Gateway in English).
  • This HGW domestic gateway includes a DNS module, referenced DNS_HGW.
  • the HGW home gateway is connected to a NET telecommunications network including a DNS_NET DNS server.
  • a content server in English Content Provider server or CP server
  • CP_SRV of a content delivery network in English Content Delivery Network
  • NET Network
  • CP.net the domain name (FQDN, in English Fully Qualified Domain Name)
  • IP_CDN the IP address of the CP_SRV content server.
  • domain names are in fact fully qualified domain names; we use the expression domain name for the sake of simplification.
  • the OTT device When the user of the OTT receiving device wishes to access the content delivered by the content server CP_SRV, the OTT device sends (step 1E10) a “RESOLVE CP.net” request to resolve the FQDN domain name of this server.
  • This query is received by the DNS module DNSJDTT of the OTT receiving device and if this module cannot resolve the query (i.e. if it has never processed a similar query or if the response it holds has become obsolete), it forwards the request to the next DNS module for resolution, or to DNS_HGW of the HGW home gateway. On this same principle, if this DNS_HGW module cannot resolve the request, it transmits it to the next DNS server, that is to say in this example to the network's DNS_NET DNS server.
  • the DNS server DNS_NET of the network returns (step 1E20) the IP address @IP_CDN for broadcasting content CP to the DNS module which queried it, that is to say to the DNS module DNS_HGW, and this is repeated up to the device OTT receiver.
  • the OTT receiver device sends (step 1E30) a “GET CP.net/content” request to the IP address @IP_CDN to obtain (step 1E40) the content of the CP_SRV content server in unicast mode.
  • Figure 2 represents a second method for managing the distribution of multimedia streams in accordance with the state of the art and illustrates in particular three additional functional modules making it possible to deliver to the OTT receiver device ABR M-ABR multicast content (for example in accordance with the DVB reference architecture ETSI TS 103 769 VI.1.1).
  • a “Multicast server” (MC_SRV) module retrieves from the content distribution server CP_SRV, the contents (step 2E70) to be transmitted and broadcasts them in point-multipoint mode (step 2E80).
  • the broadcast mode is multicast.
  • a “Rendez Vous Service” (RDV) module has knowledge of the content broadcast in M-ABR.
  • the CP_APP application of the PTT receiver device addresses the RDV module to obtain content from the CP_SRV content server (step 2E90).
  • the RDV service appointment module responds to the CP_APP application (steps 2E101 and 2E102) to directly fetch the desired content in unicast on the Multicast Gateway (steps 2E112 and 2E122 ) or on the CP_SRV server (steps 2E111 and 2E121).
  • a multicast broadcast gateway (MC_GW module) has the role of retrieving the requested content (step 2E112) broadcast in multicast (in the case of M-ABR).
  • the multicast broadcast gateway MC_GW subscribes to the corresponding multicast stream (step 2E80) and transmits it to the application CP_APP in step 2E122.
  • Figure 3 represents a method for managing the distribution of multimedia streams in M-ABR mode conforming to the state of the art in which:
  • the MC_SRV multicast server and the RDV service appointment module are located in the operator's NET network;
  • the multicast server MC_SRV uses point multipoint broadcast resources (step 3E02) made available by the network operator (in the context of M-ABR, these resources are multicast IP addresses) and retrieves the contents at broadcast in M-ABR (step 3E01) at the CP_SRV content server.
  • the RDV service appointment module must also have knowledge of the content broadcast in M-ABR and the multicast broadcast gateway MC_GW knows the association between the content(s) broadcast in M-ABR and the point multipoint broadcast resource(s) used carried out at the level of the MC_SRV multicast server.
  • the network operator when activating the RDV module in the network, the network operator declares two new rules (step 3E03) in the network DNS (DNS_NET):
  • the first rule redefines the resolution of the main FQDN “CP.net” either by the IP address @IP_RDV of the RDV module (replacing the IP address of the content delivery server CP_SRV ).
  • the main FQDN “CP.net” can be resolved by a new FQDN “RDV.net” which is resolved by the IP address of the RDV module;
  • the multicast broadcast gateway MC_GW registers in a database at the RDV service appointment module. So when a device requests the RDV service appointment module via this HGW domestic gateway, the RDV service appointment module knows if a multicast broadcast gateway MC_GW is present for this device.
  • the appointment service appointment module performs a referral function.
  • the response to the content request is a request for redirection of the request to the FQDN “MC_GW.Ian” (step 3E42) if on the one hand the multicast broadcast gateway MC_GW has been registered on the rendezvous module RDV service and if on the other hand, the content is broadcast in M-ABR mode.
  • This response once resolved (steps 3E52 and 3E62) allows the OTT receiver device to obtain the content of the multicast broadcast gateway MC_GW (steps 3E72, 3E82 and 3E92).
  • the response to the content request (3E30) is a redirection request to the secondary FQDN “CPBIS.net” which once resolved (steps 3E51 and 3E61) will make it possible to obtain the content from the CP_SRV content server (steps 3E71 and 3E81 ).
  • this broadcast method has a major drawback in that it requires declaring (in step 3E04) the multicast broadcast gateway MC_GW to the RDV service appointment module. Indeed, assuming that this recording is not carried out, and therefore that the service module systematically returns, in step 3E42, as soon as the requested content is accessible by multicast, a redirection instruction to a name of domain associated with a multicast broadcast gateway, even in the absence of such an MC-GW gateway, then step 3E52 of resolving this domain name would result in a service interruption, typically an HTTP 404 code error.
  • a known solution consists of managing such a response at the level of the CP_APP application of the OTT decoder to redirect the request to the server for this CP_SRV content for unicast reception.
  • the invention aims at a diffusion method which does not have these drawbacks.
  • the invention relates to a method of configuring a DNS module implemented by a domestic gateway configured to interconnect a local network with an operator network, said configuration comprising at least:
  • the invention relates to a device for configuring a DNS module included in a domestic gateway configured to interconnect a local network with an operator network, said configuration comprising at least:
  • the method of configuring a DNS module according to the invention is remarkable in that it makes it possible to intelligently direct the unicast or multicast stream to the OTT receiver depending on the broadcast mode of this stream, without requiring recording. prior or declaration of the multicast broadcast gateway to the service appointment module, nor modification of the software of the OTT receivers.
  • the invention also relates to an address resolution device configured by the configuration method mentioned above and an address resolution method implemented by such a device.
  • the invention relates to an address resolution method implemented by an entity constituted by a domestic gateway configured to interconnect a local network with an operator network, this method comprising:
  • a routing module located in the operator's network said routing module being configured to, upon receipt of a request access to content,:
  • the invention relates to an address resolution device intended to be integrated into a domestic gateway configured to interconnect a local network with an operator network, this device comprising:
  • the invention also relates to a domestic gateway configured to interconnect a local network with an operator network, this gateway being characterized in that it comprises a configuration device as mentioned above.
  • the invention also relates to a multicast gateway integrated into a home gateway as mentioned above and configured to respond to a request for access to content by sending this content in unicast, this content being received by said gateway multicast in multicast from a multicast broadcast server of this content, said multicast gateway comprising a configuration device as mentioned above.
  • the configuration method is implemented upon detection of the presence of the multicast gateway.
  • the home gateway detects the presence of the broadcast gateway, it configures its DNS with the two rules (i) and (ii) mentioned above.
  • the configuration method is implemented by the multicast gateway, preferably as soon as it starts.
  • it is the multicast gateway which itself configures the DNS of the home gateway with the two rules (i) and (ii) mentioned above.
  • the different stages of the configuration method and/or the address resolution method are determined by computer program instructions or are implemented by a silicon chip which comprises transistors adapted to constitute logic gates of non-programmable hardwired logic.
  • the invention also relates to a computer program on an information medium, this program being capable of being implemented in a controller computer, this program comprising instructions adapted to the implementation of the steps of an address configuration and/or resolution method as described above.
  • This program may use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other desirable shape.
  • the invention also relates to an information medium readable by a computer, and comprising instructions for a computer program as mentioned above.
  • the information carrier can be any entity or device capable of storing the program.
  • the medium may include a storage means, such as a ROM, a non-volatile memory of the flash type or even a magnetic recording means, for example a hard disk.
  • the information carrier may be a transmissible medium such as an electrical or optical signal, which may be carried via an electrical or optical cable, by radio or by other means.
  • the program according to the invention can in particular be downloaded onto an Internet type network.
  • the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in executing the method in question. Brief description of the designs:
  • FIG. 4 represents a configuration method and an address resolution method conforming to a particular embodiment of the invention
  • FIG. 5 represents a configuration device conforming to a particular embodiment of the invention
  • FIG. 7 represents a domestic gateway, and a multicast gateway conforming to a particular embodiment of the invention.
  • Figure 4 represents a method of configuring a DNS module and an address resolution method conforming to a particular embodiment of the invention.
  • the configuration method and the address resolution method is implemented by an HGW domestic gateway providing the interconnection between a local network LAN and a NET operator network.
  • the HGW home gateway includes a DNS_HGW DNS module and a MC_GW multicast multicast gateway.
  • CP_SRV content server of a CDN content distribution network is connected to the NET network.
  • CP.net the FQDN domain name
  • IP_CDN the IP address of the CP_SRV content server.
  • an OTT receiver device comprising a CP_APP application from a content provider, a decoder not shown and a DNS module DNSJDTT.
  • a multicast server MC_SRV of the operator's network NET uses point multipoint broadcast resources (step 4E02) and retrieves the content to be broadcast in M-ABR mode (step 4E01) at the content server CP_SRV.
  • An appointment switching module providing a service appointment function is installed in the operator's NET network.
  • a CTR controller of the home gateway HGW detects the presence of the multicast gateway MC_GW.
  • CP.net from the CP_SRV content server by the IP address @IP_RDV of an RDV switching module located in the operator's network.
  • the OTT receiver device sends a RESOLVE CP.net request to resolve the main domain name of the content server CP_SRV.
  • This request is received by the DNS module DNSJDTT of the OTT receiving device and transferred to the DNS module DNSJHGW of the home gateway.
  • the DNS module DNS_HGW of the home gateway responds (step 4E20) to the OTT receiver device that the IP address of the content server CP_SRV is the IP address @IP_RDV of the RDV routing module.
  • the OTT receiver device sends (step 4E30) a request for access to GET CP.net/content content to the IP address @IP_RDV of the RDV routing module.
  • the RDV routing module determines whether the URL associated with the content is, in a configuration file, associated with an ABR multicast broadcast mode.
  • the RDV routing module sends (step 4E42) to the OTT receiver device a REDIRECT MC_GW.Ian/content redirection request so that the latter sends its content access request to the gateway multicast MC_GW.
  • the OTT receiver device sends a “RESOLVE MC_GW.Ian” request to resolve the domain name FQDN of the multicast gateway MC_GW.
  • This request is received by the DNS module DNSJDTT of the OTT receiving device and transferred to the DNS module DNS_HGW of the home gateway HGW.
  • the home gateway HGW returns (step 4E62) to the OTT receiver device the IP address @IP_MC_GW of the multicast gateway MC_GW. This is also the IP address of the HGW Home Gateway.
  • the OTT receiver device sends (step 4E72) the “GET MC_GW.Ian/content” content access request to the IP address of the MC_GW multicast gateway.
  • This multicast gateway MC_GW ensures the conversion, into unicast for restitution by the OTT receiver device, of the stream received in multicast coming from the multicast broadcast server MC_SRV.
  • the multicast gateway MC_GW sends (step 4E92) in unicast to the decoder DEC, the content received (4E82) in multicast from the multicast broadcast server MC_SRV.
  • the RDV referral module determines that the URL associated with the content is not associated with an ABR multicast broadcast mode, the RDV referral module sends (step 4E41) to the device OTT receiver a REDIRECT CPBIS.net/content redirection request to the secondary FQDN of the CP_SRV content server.
  • the OTT receiver device sends a “RESOLVE CPBIS.net” request to resolve the secondary FQDN domain name of the unicast content server CP_SRV.
  • This request is received by the DNS module DNSJDTT of the OTT receiving device and transferred to the DNS module DNSJHGW of the home gateway HGW, which transfers it to the DNS module DNS_NET of the operator.
  • the operator's DNS_NET module returns (step 4E61) to the OTT receiver device the IP address @IP_CDN of the unicast content server CP_SRV.
  • the OTT receiver device sends (step 4E71) the “GET CPBIS.net/content” content access request to the IP address IP_CDN of the unicast content server CP_SRV.
  • the unicast content server CP_SRV sends the content to the OTT receiver device during a step 4E81.
  • Figure 5 represents a DC device for configuring a module according to the invention. This device is intended to be integrated into an HGW home gateway between a local network and a NET operator network, the HGW home gateway comprising a MC_GW multicast gateway.
  • the DC configuration device has the hardware architecture of a computer II comprises a processor 10, a ROM type read only memory 11, a RAM 12, a rewritable non-volatile memory 14 and means communication 15.
  • the ROM type read only memory 11 constitutes a recording medium within the meaning of the invention. It comprises a PGC computer program comprising instructions for executing the steps of a configuration method according to the invention when this program is executed by the processor 10.
  • the communication means 15 are configured to configure a DNS module DNS_HGW with configuration rules comprising at least:
  • Figure 6 represents a DR address resolution device according to the invention. This device is intended to be integrated into a HGW home gateway between a local network and a NET operator network.
  • the address resolution device DR has the hardware architecture of a computer II comprises a processor 20, a ROM type read only memory 21, a RAM 22, a rewritable non-volatile memory 24 and means of communication 25.
  • the ROM type read only memory 21 constitutes a recording medium within the meaning of the invention. It comprises a computer program PGR comprising instructions for executing the steps of an address resolution method according to the invention when this program is executed by the processor 20.
  • the communication means 25 are in particular configured to receive a request for resolution of a domain name from a content server and send, in response to this resolution request, a response comprising the IP address of a module.
  • RDV switching located in the operator's network, this RDV switching module being configured for, upon receipt of a request for access to content:
  • Figure 7 represents a home gateway HGW and a multicast gateway MC_GW conforming to the invention.
  • the HGW domestic gateway comprises a DNS-HGW DNS module, a DC configuration device and an address resolution DR device in accordance with the invention.
  • the DC configuration device is integrated into the MC_GW multicast gateway.
  • the multicast gateway then conforms to the invention.
  • the DC device for configuring the home gateway HGW is not integrated into the multicast gateway MC_GW.
  • the address resolution device DR is integrated into the DNS module DNSJHGW.

Landscapes

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

Abstract

Ce procédé de configuration permet la configuration d'un module DNS (DNS_OTT, DNS_HGW) mis en œuvre par une entité (OTT, LB) constitué par une passerelle (LB) configurée pour interconnecter un réseau local avec un réseau d'opérateur (NET) ou par un équipement (OTT) dudit réseau local, ladite configuration comportant au moins : (i) un enregistrement d'un nom de domaine (MC_GW.fr) pointant vers une passerelle de multidiffusion (MC_GW) comprise dans ladite entité (OTT, LB) 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 ( 4E82) en multidiffusion par la passerelle de multidiffusion (MC_GW) en provenance d'un serveur de multidiffusion de ce contenu (MC_SRV) via le réseau d'opérateur (NET); (ii) une règle de résolution d'un nom de domaine (CP.COM) d'au moins un serveur de contenu avec l'adresse IP (@IP_RDV) d'un module d'aiguillage (RDV) localisé dans le réseau de l'opérateur (NET), (iii) un enregistrement d'un nom de domaine secondaire (CPBIS.COM) pointant vers ledit serveur de contenu (CP.COM); ledit module d'aiguillage (RDV) étant configuré pour, sur réception (E40) d'une requête d'accès à un contenu : - répondre (E60) par une requête de redirection vers le nom de domaine (MC_GW.fr) pointant vers ladite passerelle de multidiffusion si le contenu doit être accédé en multidiffusion; et - répondre (E110) par une requête de redirection vers le nom de domaine secondaire (CPBIS.COM) pointant vers le serveur dudit contenu (CP.COM) si le contenu doit être accédé en monodiffusion.

Description

Description
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.

Claims

REVENDICATIONS
[Revendication 1] Procédé de configuration d'un module DNS (DNSJHGW) mis en œuvre par une passerelle domestique (HGW) configurée pour interconnecter un réseau local (LAN) avec un réseau d'opérateur (NET) ladite configuration comportant au moins :
(i) un enregistrement d'un nom de domaine (MC_GW.Ian) pointant vers une passerelle de multidiffusion (MC_GW) comprise dans ladite passerelle domestique (HGW) 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 ( 4E82) en multidiffusion par la passerelle de multidiffusion (MC_GW) en provenance d'un serveur de multidiffusion de ce contenu (MC_SRV) via le réseau d'opérateur (NET) ;
(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), ledit module d'aiguillage (RDV) étant configuré pour, sur réception (4E30) d'une requête d'accès à un contenu :
- répondre (4E42) par une requête de redirection vers ledit nom de domaine (MC_GW.Ian) pointant vers ladite passerelle de multidiffusion (MC_GW) si le contenu doit être accédé en multidiffusion ; et
- répondre (4E41) par une requête de redirection vers un nom de domaine secondaire (CPBIS.net) pouvant être résolu en l'adresse (@IP_CDN) dudit serveur de contenu (CP_SRV) si le contenu doit être accédé en monodiffusion.
[Revendication 2] Procédé de configuration selon la revendication 1, ledit procédé étant mis en œuvre sur détection (4E04) de la présence de la passerelle de multidiffusion (MC_GW).
[Revendication 3] Procédé de configuration selon la revendication 1, ledit procédé étant mis en œuvre par la passerelle de multidiffusion (MC_GW).
[Revendication 4] Procédé de résolution d'adresse mis en œuvre par une passerelle domestique (HGW) configurée pour interconnecter un réseau local avec un réseau d'opérateur (NET), ce procédé comportant :
- une étape (4E20) de réception d'une requête de résolution d'un nom de domaine (CP.net) d'un serveur de contenu (CP_SRV) ;
- une étape (4E20) de réponse à ladite requête de résolution par l'envoi de l'adresse IP (@IP_RDV) d'un module d'aiguillage (RDV) localisé dans le réseau de l'opérateur (NET), ledit module d'aiguillage (RDV) étant configuré pour, sur réception (4E30) d'une requête d'accès à un contenu :
- répondre (4E42) par une requête de redirection vers un nom de domaine (MC_GW.Ian) d'une passerelle de multidiffusion (MC_GW) comprise dans ladite passerelle domestique (HGW) si le contenu doit être accédé en multidiffusion ; et
- répondre (4E41) par une requête de redirection vers un nom de domaine secondaire (CPBIS.net) pouvant être résolu en l'adresse (@IP_CDN) d'un serveur (CP_SRV) dudit contenu si le contenu doit être accédé en monodiffusion.
[Revendication 5] Dispositif (DC) de configuration d'un module DNS (DNS_HGW) compris dans une passerelle domestique (HGW) configurée pour interconnecter un réseau local (LAN) avec un réseau d'opérateur (NET), ladite configuration comportant au moins :
(i) un enregistrement d'un nom de domaine (MC_GW.fr) pointant vers une passerelle de multidiffusion (MC_GW) comprise dans ladite passerelle domestique (HGW) et configurée pour répondre à une requête d'accès à un contenu reçue sur le réseau local, par l'envoi (4E92) de ce contenu en monodiffusion, ledit contenu étant reçu ( 4E82) en multidiffusion par la passerelle de multidiffusion (MC_GW) en provenance d'un serveur de diffusion (MC_SRV) de ce contenu via le réseau d'opérateur (NET) ;
(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), ledit module d'aiguillage (RDV) étant configuré pour, sur réception (4E30) d'une requête d'accès à un contenu, :
- répondre (4E42) par une requête de redirection vers le nom de domaine (MC_GW.Ian) pointant vers ladite passerelle de multidiffusion (MC_GW) si le contenu doit être accédé en multidiffusion ; et
- répondre (E110) par une requête de redirection vers un nom de domaine secondaire (CPBIS.net) pouvant être résolu en l'adresse (@IP_CDN) dudit serveur de contenu (CP_SRV) si le contenu doit être accédé en monodiffusion.
[Revendication 6] Passerelle domestique (HGW) configurée pour interconnecter un réseau local (LAN) avec un réseau d'opérateur (NET), ladite passerelle domestique(HGW) étant caractérisée en ce qu'elle comporte un dispositif de configuration (DC) selon la revendication 5.
[Revendication 7] Passerelle de multidiffusion (MC_GW) intégrée à une passerelle domestique selon la revendication 6 et configurée pour répondre à une requête d'accès à un contenu par l'envoi (4E92) en monodiffusion de ce contenu, ce contenu étant reçu ( 4E82) par ladite passerelle de multidiffusion (MC_GW) en multidiffusion à partir d'un serveur de diffusion multicast (MC_SRV) de ce contenu, ladite passerelle de multidiffusion (MC_GW) étant caractérisée en ce qu'elle comporte un dispositif de configuration (DC) selon la revendication 5.
[Revendication 8] Dispositif de résolution (DR) d'adresse destiné à être intégré dans une passerelle domestique (HGW) configurée pour interconnecter un réseau local avec un réseau d'opérateur (NET), ce dispositif comportant :
- un module (25) de réception d'une requête de résolution d'un nom de domaine (CP.net) d'un serveur de contenu (CP_SRV) ; et
- un module (25) d'envoi d'une réponse à ladite requête de résolution, ladite réponse comportant l'adresse IP (@IP_RDV) d'un module d'aiguillage (RDV) localisé dans le réseau de l'opérateur (NET), ledit module d'aiguillage (RDV) étant configuré pour, sur réception (4E30) d'une requête d'accès à un contenu :
- répondre (4E42) par une requête de redirection vers un nom de domaine (MC_GW.Ian) d'une passerelle de multidiffusion (MC_GW) comprise dans ladite passerelle domestique (HGW) si le contenu doit être accédé en multidiffusion ; et
- répondre (4E41) par une requête de redirection vers un nom de domaine secondaire (CPBIS.net) pouvant être résolu en l'adresse (@IP_CDN) d'un serveur (CP_SRV) dudit contenu si le contenu doit être accédé en monodiffusion.
[Revendication 9] Programme d'ordinateur (PGC) comportant des instructions pour l'exécution des étapes du procédé de configuration selon l'une quelconque des revendications 1 à 3 lorsque ledit programme est exécuté par un ordinateur.
[Revendication 10] Programme d'ordinateur (PGR) comportant des instructions pour l'exécution des étapes du procédé de résolution d'adresse selon la revendication 4 lorsque ledit programme est exécuté par un ordinateur.
EP23782181.4A 2022-09-28 2023-09-26 Procédés et dispositifs de configuration d'un module dns et de résolution d'adresse pour gérer la diffusion de flux de contenus multimédias dans un réseau de télécommunications Pending EP4595411A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2209817A FR3140233A1 (fr) 2022-09-28 2022-09-28 Procédés et dispositifs de configuration d’un module DNS et de résolution d’adresse pour gérer la diffusion de flux de contenus multimédias dans un réseau de télécommunications
PCT/EP2023/076536 WO2024068627A1 (fr) 2022-09-28 2023-09-26 Procédés et dispositifs de configuration d'un module dns et de résolution d'adresse pour gérer la diffusion de flux de contenus multimédias dans un réseau de télécommunications

Publications (1)

Publication Number Publication Date
EP4595411A1 true EP4595411A1 (fr) 2025-08-06

Family

ID=84887902

Family Applications (1)

Application Number Title Priority Date Filing Date
EP23782181.4A Pending EP4595411A1 (fr) 2022-09-28 2023-09-26 Procédés et dispositifs de configuration d'un module dns et de résolution d'adresse pour gérer la diffusion de flux de contenus multimédias dans un réseau de télécommunications

Country Status (4)

Country Link
US (1) US20260129018A1 (fr)
EP (1) EP4595411A1 (fr)
FR (1) FR3140233A1 (fr)
WO (1) WO2024068627A1 (fr)

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9743151B2 (en) * 2015-06-24 2017-08-22 Time Warner Cable Enterprises Llc Multicast video program switching architecture
US12003788B2 (en) * 2018-11-28 2024-06-04 Broadpeak Method and system for audio-visual live content delivery

Also Published As

Publication number Publication date
WO2024068627A1 (fr) 2024-04-04
US20260129018A1 (en) 2026-05-07
FR3140233A1 (fr) 2024-03-29

Similar Documents

Publication Publication Date Title
EP3054652B1 (fr) Ajustement dynamique du mode de transmission dans un systeme de communication satellite
JP2004517412A (ja) コンテンツ配信網のストリーミング・メディア配信機構
EP1252575A1 (fr) Systeme et procede de reecriture d'une demande de supports d'information et/ou d'une reponse a cette demande entre un serveur d'origine et un client
FR2879385A1 (fr) Methode d'agregation de decouverte de service dans un reseau local et appareil implementant la methode
US12088653B2 (en) Method and apparatus for processing multicast signal
FR2917554A1 (fr) Dispositif de gestion de reception par des terminaux de contenus multimedia transmis par des infrastructures mettant en oeuvre des techniques de transmission differentes
WO2015049431A1 (fr) Procede d'abonnement a des flux en provenance de clients multicast
FR2903268A1 (fr) Procede de reception de services audio/video, terminal et systeme correspondants
EP1964313B1 (fr) Procédé de transmission de services de télévision numérique, passerelle et réseau correspondants
JP2012503908A (ja) 高速チャネル変更およびマルチメディアサービスの確実な配信のためのサービス構成および管理
WO2006016055A2 (fr) Procede et serveur de referencement de diffusion poste a poste de fichiers demandes par telechargement a ce serveur
WO2010026355A1 (fr) Procede et dispositif de redirection d'une requete de controle d'un flux de donnees
WO2024068627A1 (fr) Procédés et dispositifs de configuration d'un module dns et de résolution d'adresse pour gérer la diffusion de flux de contenus multimédias dans un réseau de télécommunications
EP3231190B1 (fr) Procédé et dispositifs permettant une transmission d'un flux de données selon un mode de transmission multipoint
FR2933213A1 (fr) Methode d'affichage d'interface utilisateur et methode d'emission correspondante
WO2019002729A1 (fr) Procédé et dispositif de téléchargement de contenu audiovisuel
EP2589202B1 (fr) Procédé et système de gestion de sessions de communication
EP1430648A2 (fr) Procede et dispositif de reception de contenus diffuses
EP2055042A2 (fr) Mecanisme pour la gestion de connexions de recepteurs / decodeurs
FR3147677A1 (fr) procédé de gestion de l’accès à un contenu multimédia et de la lecture de ce contenu.
FR3021477A1 (fr) Telechargement de contenu et mise a disposition de reseaux de telecommunications etendus en vue d'un tel telechargement.
EP4468686A1 (fr) Basculement optimisé depuis un serveur de contenu unicast vers un serveur de contenu multicast
RU2791242C2 (ru) Способ и система доставки аудиовизуального контента в режиме реального времени
EP4131889A1 (fr) Procédé permettant de réduire l'empreinte carbone de la distribution de contenus numériques, notamment par le recours à un réseau de diffusion et un stockage local des contenus
EP4521753A1 (fr) Procédé de gestion du traitement d'un flux vidéo dans un réseau local

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: 20250408

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

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20260625