FR2890519A1 - Procede d'optimisation de l'utilisation de la bande passante d'une emission a diffusion en rafales - Google Patents

Procede d'optimisation de l'utilisation de la bande passante d'une emission a diffusion en rafales Download PDF

Info

Publication number
FR2890519A1
FR2890519A1 FR0509094A FR0509094A FR2890519A1 FR 2890519 A1 FR2890519 A1 FR 2890519A1 FR 0509094 A FR0509094 A FR 0509094A FR 0509094 A FR0509094 A FR 0509094A FR 2890519 A1 FR2890519 A1 FR 2890519A1
Authority
FR
France
Prior art keywords
data
fec
burst
columns
dvb
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR0509094A
Other languages
English (en)
Other versions
FR2890519B1 (fr
Inventor
Benoit Oger
Stephane Quemener
Richard Lhermitte
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.)
Thales SA
Original Assignee
Thales 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 Thales SA filed Critical Thales SA
Priority to FR0509094A priority Critical patent/FR2890519B1/fr
Priority to PCT/EP2006/065990 priority patent/WO2007028786A1/fr
Publication of FR2890519A1 publication Critical patent/FR2890519A1/fr
Application granted granted Critical
Publication of FR2890519B1 publication Critical patent/FR2890519B1/fr
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/23614Multiplexing of additional data and video streams
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2381Adapting the multiplex stream to a specific network, e.g. an Internet Protocol [IP] network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/435Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/436Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
    • H04N21/4363Adapting the video stream to a specific local network, e.g. a Bluetooth® network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/438Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
    • H04N21/4381Recovering the multiplex stream from a specific network, e.g. recovering MPEG packets from ATM cells
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61Network physical structure; Signal processing
    • H04N21/6106Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6131Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via a mobile phone network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643Communication protocols
    • H04N21/64315DVB-H

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

La présente invention a pour objet un procédé d'optimisation de l'utilisation de la bande passante d'une émission à diffusion en rafales, en particulier en remplissant de la façon la plus judicieuse possible les parties inutilisées des rafales de données, et elle est caractérisée en ce que l'on insère dans au moins une de ces parties des données supplémentaires. Lorsque la norme de transmission est DVB-H, on insère dans les « FEC-Frame » d'au moins une partie des rafales des données de contrôle et/ou on insère des données applicatives dans la partie applicative de ces FEC-Frame.

Description

PROCEDE D'OPTIMISATION DE L'UTILISATION DE LA BANDE
PASSANTE D'UNE EMISSION A DIFFUSION EN RAFALES La présente invention se rapporte à un procédé d'optimisation de l'utilisation de la bande passante d'une émission à diffusion en rafales.
Un exemple de norme de diffusion en rafales est la DVB-H. Cette norme a été définie pour la diffusion de données à destination de petits récepteurs comme les téléphones portables, organisateurs de poche, etc.... Elle se base sur DVB-T (standard de transmission numérique terrestre) en lui ajoutant un mécanisme d'émission sous forme de rafales. Le contenu des rafales correspond à un ou plusieurs flux de réseaux dont le débit n'est pas obligatoirement constant, comme par exemple de la vidéo.
Le standard DVB-H est très récent. Des déploiements devraient bientôt être réalisés, cependant les protocoles des couches supérieures sont encore en cours de normalisation. La présente invention a pour objectif d'anticiper un besoin des futurs opérateurs DVB-H. L'insertion opportuniste de données en vue d'optimiser l'utilisation de la bande passante est une technique déjà utilisée pour les transmissions numériques classiques mais le principe est très différent dans le mode DVB-H en raison des contraintes dues à l'émission en rafales.
Afin de maximiser l'utilisation de la bande passante réservée pour un service DVB-H, il est possible en premier lieu d'ajouter des données utiles à transmettre. Pour cela l'idée consiste à associer à l'entrée un flux réseau supplémentaire de données dont le débit de la source est contrôlable. Cette condition est nécessaire puisque la quantité de données à ajouter par rafale est variable et non prévisible.
Dans le cas où le service utiliserait le système de protection de données décrit par le standard DVB-H, il est également possible d'utiliser la bande passante restante pour accroître la quantité de données de contrôle et ainsi se servir de l'espace libre pour augmenter la robustesse des informations transmises.
Le Time-Slicing (partage temporel) du standard DVB-H fonctionne de la manière suivante. Ce standard DVB-H concerne l'émission de données numériques sur des réseaux terrestres. Il repose sur le standard DVB-T, utilisé pour la TNT (Télévision Numérique Terrestre) par exemple. Plus particulièrement DVB-H a été conçu pour la diffusion de contenus multimédias à destination de récepteurs mobiles: téléphones, voitures ou autres. L'une des problématiques à laquelle cette norme devait répondre est la réduction de la consommation de l'énergie fournie par les batteries d'alimentation des terminaux mobiles. C'est dans cette optique qu'a été introduit le procédé de Time-Slicing (découpage temporel). Le but est de réduire le temps pendant lequel le récepteur est en écoute du signal DVB, ce temps étant un processus très consommateur d'énergie. Pour y parvenir, les différents services sont diffusés non plus de manière continue, mais sous forme de rafales de données à un débit plus important, à raison d'une rafale par service. Le terminal peut alors mettre son système de réception en veille jusqu'à la prochaine rafale de données. Les calculs de rendement de ce processus prévoient des économies d'énergie pouvant atteindre 90%.
On a représenté en figure 1 un exemple très simplifié de diffusion en time-slicing d'un service quelconque. Les données de ce service sont diffusées en rafales, 15 telles que les rafales 1 et 2 de la figure 1.
Le processus de time-slicing est défini par deux principaux paramètres, à savoir le débit de rafale et la période de time-slicing. Le débit de rafale représente le débit selon lequel les rafales de données vont être générées. Pour que le time-slicing soit efficace, il est conseillé d'avoir un débit de rafales supérieur au débit des services d'au moins un facteur 10 environ.
Pour pouvoir mettre en veille son module de réception, le récepteur DVB-H doit nécessairement connaître le moment où il devra se remettre en écoute. Or les services sujets au time-slicing ne sont pas organisés dans des slots à intervalles fixes et prédéterminés dans le temps. Au contraire, l'intervalle entre deux rafales d'un même service est susceptible d'être différent de la période de time-slicing lors d'ajout ou de suppression de services sujets au time-slicing. L'émetteur DVB-H envoie donc dans une rafale la valeur du délai jusqu'au début de la prochaine rafale du même service. En fait, cette information est désignée sous le nom de DeltaT (AT). Elle est transmise en entête de chaque datagramme encapsulé dans une rafale. Le AT représente le temps compris entre une section considérée qui le contient et le début de la prochaine rafale du service considéré. Chaque section contient un AT. Sa valeur dépend donc de la position de la section. Plus celle ci est proche de la fin de la rafale courante et plus le AT diminue. Le AT de la première section d'une rafale donne le temps jusqu'au début de la prochaine rafale donc l'intervalle entre deux rafales consécutives, ce qui correspond à la période de Time- Slicing. On a représenté en 3, à titre de comparaison, le débit de données pour un service qui serait diffusé en continu.
Sur la figure 2, on a représenté deux rafales consécutives de données 4 et 5 (rafales N et N+l). Chacune de ces rafales comporte plusieurs colonnes de datagrammes (modules élémentaires de données du service transmis), qui sont dits encapsulés en sections suivant le protocole MPE, puis transmis en paquets MPEG2 pendant la rafale.
Le remplissage des rafales de données se fait de la manière suivante. La norme DVB-H précise que les données envoyées en mode time-slicing sont obligatoirement des datagrammes IP (v4 ou v6) encapsulés suivant le standard MPE (Multi-Protocol Encapsulation), formant des sections MPE. La norme DVB repose sur le standard MPEG-2, ces sections sont donc ensuite transportées dans la charge utile de paquets MPEG-2 de transport. Par abus de langage, on dit que les rafales contiennent une suite de sections MPE.
On peut aussi rencontrer des données autres que des sections MPE dans les rafales de données. En effet, la norme DVB-H fournit également un système de protection des données contre les éventuelles corruptions ou suppressions induites par les perturbations de transmission. Pour générer ces données de contrôle, le standard DVB-H utilise une structure appelée FEC-Frame. Il s'agit d'un tableau d'octets dont le nombre de colonnes est 255 et le nombre de lignes est une valeur parmi 256, 512, 768 ou 1024. Ce tableau est divisé en deux, tout d'abord la partie dite applicative, destinée à contenir les datagrammes IP, qui occupe les 191 premières colonnes. La seconde est la partie FEC, qui contient les octets de contrôle et occupe les 64 colonnes restantes. L'algorithme de protection est un Reed-Solomon (191, 255).
Afin d'optimiser la protection des données, la norme DVB-H prévoit de placer les datagrammes IP dans le tableau FEC-Frame verticalement, colonne après colonne, alors que les codes de contrôle sont calculés ligne par ligne. Ces octets de protection sont envoyés en les encapsulant colonne par colonne dans des structures appelées sections MPE-FEC . La norme DVB-H impose qu'un seul tableau FEC- Frame peut être envoyé par rafale et qu'il doit être transmis intégralement. De plus, on ne peut émettre que des datagrammes complets.
Le remplissage de la partie applicative de la FEC-Frame dépend de sa taille, du débit du trafic IP et de la période de time-slicing. Comme précisé précédemment, les deux parties peuvent occuper au maximum respectivement 191 et 64 colonnes.
Cette configuration offre un ratio de protection de 3/4 (le surplus de débit est de 25%). La norme prévoit d'augmenter ou de réduire ce ratio. Pour cela, il est possible de diminuer le nombre de colonnes utilisables par chacune des parties. Par exemple, en réduisant le nombre maximum de colonnes applicatives à 64, on offre un ratio de protection de 1/2. La figure 3 représente un exemple de remplissage classique de
tableau FEC-Frame.
Sur cette figure 3, la surface 6 représente les datagrammes IP qui vont être encapsulés et envoyés dans la prochaine rafale de donnée. La surface 7 représente l'espace réservé aux datagrammes IP qui n'a pas été remplie (en raison d'un débit trop faible, par exemple). L'aire 8 correspond à des colonnes applicatives non utilisables, c'est à dire que l'on réduit volontairement la taille maximale de la partie applicative qui peut être remplie. Ce mécanisme est décrit dans la norme, et son but est de modifier la robustesse obtenue. Par exemple, pour obtenir une robustesse de codage de 2/3, il suffit de réduire le nombre de colonnes applicatives utilisables de 191 à 128 et de transmettre les 64 colonnes de FEC. Le remplissage de la partie applicative ne pourra donc excéder 128 colonnes alors que le nombre de colonnes de FEC sera toujours de 64. Le ratio codage sera alors par conséquent au maximum de 2/3 ou plus petit (donc plus robuste) si les 128 colonnes utilisables de la partie applicative ne sont pas toutes remplies.
Une fois que le remplissage de la partie applicative est achevé (soit parce qu'il n'y a plus de place pour le prochain datagramme, soit parce que le temps de remplissage est écoulé), on calcule les octets de contrôle. Les 64 octets sont toujours 2890519 5 calculés, en revanche, il est possible de n'envoyer qu'une partie des colonnes de FEC, ce qui a pour effet de réduire la protection des données, mais aussi le surplus de débit. Il faut faire une distinction entre la surface 7 et la surface 8. En effet, même si toutes les deux représentent un espace non utilisé de la partie applicative, la première correspond à de la bande passante réservée, contrairement à la seconde. La surface 7 se traduit donc par de la bande passante non utilisée (perdue). Les surfaces 6 à 8 représentent la partie applicative, tandis que les surfaces 9 et 10 représentent la partie FEC.
Une grande partie des flux qui sont sujets à être diffusés via DVB-H peuvent avoir un débit fluctuant. C'est le cas des flux vidéo, dont le débit dépend du type de scène (fixe, sport, ...). Il existera donc une quantité variable de bande passante inutilisée pour chacun de services de ce type. Cette bande passante représente un investissement financier non négligeable. Les clients de ces services sont donc sensibles à leur utilisation optimale.
La présente invention a pour objet un procédé d'optimisation de l'utilisation de la bande passante d'une émission à diffusion en rafales, en particulier en remplissant de la façon la plus judicieuse possible les parties inutilisées des rafales de données.
Le procédé conforme à l'invention est un procédé d'optimisation de l'utilisation de la bande passante réservée d'une émission diffusée en rafales, du type à rafales comportant au moins une partie réservée aux données utiles d'un service, et il est caractérisé en ce que l'on insère dans cette partie des données supplémentaires.
Selon une caractéristique de l'invention, lorsque ces rafales comportent en outre au moins une partie réservée aux données de contrôle, on insère des données supplémentaires de contrôle dans au moins une de ces parties réservées aux données de contrôle, afin d'augmenter la robustesse de transmission des données utiles.
Selon une autre caractéristique de l'invention, on insère des données supplémentaires dans la partie correspondante des rafales, le flux de ces données étant contrôlé, du fait qu'on ne peut pas prévoir la place disponible pour ces données supplémentaires.
2890519 6 Selon encore une autre une caractéristique de l'invention, lorsque la norme de transmission est DVB-H, on insère dans les FECFrame d'au moins une partie des rafales des données de contrôle et/ou on insère des données applicatives dans la partie applicative de ces FECFrame.
La présente invention sera mieux comprise à la lecture de la description détaillée d'un mode de réalisation, pris à titre d'exemple non limitatif et illustré par le dessin annexé, sur lequel: - la figure 1, déjà décrite ci-dessus, est un bloc-diagramme simplifié d'un exemple de time-slicing , la figure 2, également décrite ci-dessus, est un bloc-diagramme simplifié de deux rafales consécutives d'une émission DVB-H, - la figure 3, également décrite ci-dessus, est un bloc-diagramme simplifié de remplissage du tableau de FEC-Frame d'une émission DVB-H, la figure 4 est un bloc-diagramme d'un exemple de remplissage d'une partie des colonnes applicatives d'un tableau FEC-Frame, conformément au procédé de l'invention, - la figure 5 est un bloc-diagramme d'un exemple de processus d'insertion opportuniste de données utiles dans une rafale d'émission 20 DVB-H, conformément au procédé de l'invention, et - La figure 6 est un bloc-diagramme d'un exemple de processus d'insertion opportuniste combinée de données utiles et de données de contrôle dans au moins une rafale d'émission DVB-H, conformément au procédé de l'invention.
La présente invention est décrite en détail ci-dessous en référence à une émission DVB-H, mais il est bien entendu qu'elle n'est pas limitée à cette seule application, et qu'elle peut être mise en oeuvre pour d'autre types d'émissions à diffusion en rafales, ces rafales comportant au moins une partie réservée aux données, et éventuellement une partie réservée aux données de contrôle, une bande passante déterminée étant réservée aux rafales, et n'étant pas obligatoirement utilisée en entier par les données normalement transmises.
Selon une première caractéristique de l'invention, pour réutiliser la bande passante disponible on effectue le remplissage d'une partie des colonnes applicatives d'un tableau FEC-Frame par augmentation de la protection, si cela est possible. En effet, le ratio de protection est un compromis entre bande passante et robustesse. Il est donc possible que toutes les colonnes de FEC ne soient pas transmises. Par exemple une protection 5/6 se traduit par un tableau FEC-Frame offrant au maximum 190 colonnes applicatives et 38 colonnes de FEC. Si, par exemple, au moment de transmettre une rafale, on constate que sa FEC-Frame ne contient que 170 colonnes applicatives remplies, il est possible de remplacer les 20 colonnes non utilisées par 20 colonnes de FEC supplémentaires. Le seul effet sera une robustesse accrue.
On a schématiquement représenté en figure 4 un exemple d'un tel processus d'augmentation de la protection des données transmises. Sur la figure 4, on a représenté, tout en haut, un tableau de FEC-Frame 11 similaire à celui de la figure 3 et comportant les surfaces 12 à 15, correspondant respectivement aux surfaces 6, 7, 9 et 10. Une fois les données applicatives chargées dans les colonnes de la surface 12, on constate que des colonnes applicatives de la surface 13 ne sont pas utilisées. Selon une première caractéristique de l'invention, on augmente le nombre de colonnes de FEC transmises, afin de profiter des colonnes applicatives utilisables mais non remplies, car elles correspondent à de la bande passante qui leur est réservée.
Dans le tableau de FEC-Frame 11A, établi conformément à l'invention, (au milieu de la figure 4), la partie applicative, comportant les surfaces 12 et 13, est la même que dans le tableau 11, seule la partie FEC est modifiée. Cette modification consiste à augmenter la partie dédiée aux sections MPE-FEC (référencée 14 dans le tableau 11, et qui devient la partie 14A dans le tableau 11A), tout en réduisant la partie dédiée aux sections MPE-FEC non transmises (référencée 15 dans le tableau 11 et qui devient la partie 15A dans le tableau 11A). On gagne ainsi dans la partie FEC un emplacement 14B dont les colonnes peuvent être utilisées par des données de contrôle supplémentaires en vue d'améliorer la qualité de protection des données de la partie applicative.
On a représenté en bas de la figure 4 deux diagrammes d'évolution dans le temps du débit de la diffusion DVB-H d'une rafale de données. Le premier diagramme (16) correspond à une rafale sans insertion de données de contrôle supplémentaires, tandis que le second (16A) correspond à une rafale avec insertion de telles données de contrôle. Dans ces deux diagrammes, la première partie (17) de la rafale est occupée par des sections MPE (correspondant aux données de la surface 12). Le diagramme 16 comprend deux autres parties, 18 et 19, correspondant respectivement à des sections MPE-FEC et à du bourrage MPEG2 (c'est-à-dire des paquets MPEG2 dont la charge utile n'a pas de signification et servant à maintenir constant le débit du flux MPEG2). Par contre, dans le diagramme 16A, il n'existe plus que deux parties, à savoir la partie 17 et une partie 18A, dont la surface est égale à la somme des surfaces des parties 18 et 19, et qui est entièrement utilisée par des sections MPE-FEC.
Ce processus est simple et efficace, mais il existe cependant une limitation. En fait, le nombre maximum de colonnes de FEC est 64 on ne peut donc utiliser autant de colonnes que l'on souhaite afin d'améliorer davantage la qualité de protection. Ainsi dans la situation la plus désavantageuse où les 64 colonnes de FEC seraient déjà transmises, il ne serait pas possible d'effectuer cette amélioration. De plus, tous les services DVB-H n'utilisent pas obligatoirement la protection FEC.
Selon une deuxième caractéristique de l'invention, on effectue un remplissage par insertion de données utiles dites opportunistes dans la partie applicative à la place de l'augmentation de la protection ou en plus de celle-ci. La première caractéristique de l'invention précédente illustre comment il est possible d'utiliser de la bande passante disponible pour un service DVB-H en jouant sur la partie FEC. L'objectif de la deuxième caractéristique est d'ajouter des données utiles afin de ne pas avoir de colonnes applicatives non utilisées. Comme la quantité de données insérées est variable, il est nécessaire que leur source mette en oeuvre un contrôle de flux. Il peut s'agir par exemple de transferts de fichier. La figure 5 suivante illustre ce processus d'insertion de données opportunistes.
Sur la figure 5, on a représenté, en haut de la figure, un tableau FECFrame 20 qui est, dans cet exemple, le même que le tableau 11 de la figure 3. Ce tableau 20 comporte, dans sa partie applicative, les surfaces 21 et 22, et dans sa partie FEC les surfaces 23 et 24, ces surfaces étant respectivement les mêmes que les surfaces 12 à de la figure 3. Comme précédemment, juste après remplissage des colonnes applicatives de la FEC-Frame, on contrôle le nombre de colonnes applicatives disponibles, puis on calcule les octets de contrôle, et on constate que des colonnes applicatives disponibles, correspondant à la surface 22, ne sont pas utilisées. Selon la deuxième caractéristique de l'invention, on complète la partie applicative non utilisée par des datagrammes provenant d'une source de données à débit contrôlé. On obtient alors, comme représenté au milieu de la figure 5, le tableau 20A, qui diffère du tableau 16 par l'insertion desdits datagrammes de données dans la partie 22, qui devient alors la partie 22A.
On a représenté en bas de la figure 5 deux diagrammes d'évolution dans le temps du débit de la diffusion DVB-H d'une rafale de données. Le premier diagramme (25) correspond à une rafale sans insertion de données utiles supplémentaires, tandis que le second (25A) correspond à une rafale avec insertion de telles données utiles. Dans ces deux diagrammes, la première partie (26) de la rafale est occupée par des sections MPE (correspondant aux données de la surface 12). Le diagramme 20 comprend deux autres parties, 27 et 28, correspondant respectivement à des sections MPE-FEC et à du bourrage MPEG2. Dans le diagramme 25A, après la partie 26, on transmet la partie 29, correspondant à la partie 22A du tableau 20A, puis la partie 27 entièrement occupée par des sections MPE- FEC, correspondant à la surface 23 du tableau 20A.
Cette solution a l'avantage premier de ne pas avoir une efficacité dépendant de la configuration de l'entrée (FEC utilisée ou non, nombre de colonnes applicatives utilisables, nombre de colonnes de FEC transmises... ). Elle permet une utilisation optimale de la bande passante réservée dès lors que la source de données peut fournir suffisamment de datagrammes. Le contrôle de flux de données opportunistes peut être géré directement au niveau des couches réseaux comme avec TCP ou bien par l'intermédiaire d'un protocole tel que SMPTE325.
L'insertion des datagrammes opportunistes est effectuée lorsque le temps de remplissage de la partie applicative du tableau FEC-Frame est fini. Une mémoire tampon telle qu'une Fifo indépendante est alimentée par le flux de données opportunistes, et son remplissage cadence l'algorithme de contrôle de flux. Cette Fifo 2890519 10 doit être dimensionnée en fonction de la bande passante réservée pour le service concerné. En effet il est très important que l'insertion de datagrammes opportunistes consomme le moins de temps possible. Il faut donc que la capacité de la Fifo soit aussi grande que le contenu d'une rafale de données.
Les données susceptibles d'être transmises par ce biais peuvent être des fichiers contenant des applications interactives, des informations complémentaires sur le service courant ou encore le programme des autres services.
Si les fichiers transmis de manière opportuniste sont nécessaires pour l'utilisateur, il faut modifier un peu le processus d'insertion de données. En effet, une transmission opportuniste pure ne garantit par définition aucun débit minimum en soi, puisqu'elle utilise uniquement la bande passante restante, laquelle peut être éventuellement nulle. Il peut donc être intéressant d'allouer au flux opportuniste un débit garanti. Dans ce cas, l'insertion opportuniste est vue comme une accélération du transfert. Par exemple cela peut se traduire par une application interactive qui se charge plus vite.
Selon une troisième caractéristique de l'invention, on utilise de façon combinée les deux premières solutions. Ces deux premières solutions sont indépendantes l'une de l'autre. Toutefois, elles peuvent également être appliquées simultanément. Comme exposé ci-dessus, l'augmentation de la robustesse des données est limitée par le nombre de colonnes de contrôle. Il est donc possible de mettre en oeuvre un processus d'insertion opportuniste procédant en priorité à l'ajout de données de contrôle, puis, si l'on a épuisé les données de contrôle disponibles, on procède à l'ajout de données utiles. La figure 6 présente un exemple de fonctionnement de ce processus.
Sur la figure 6, on a représenté deux diagrammes d'évolution dans le temps d'émission de services DVB-HT. Le diagramme supérieur, relatif à un procédé de l'art antérieur (c'est-à-dire sans insertion de FEC et/ou de données MPE), comporte deux rafales successives 30, 31 d'un service donné, et des rafales de données relatives à d'autres services DVB-H, traités de la même façon que le service décrit ici. Ces autres services sont référencés 32 dans leur ensemble, et ne seront pas décrits ici.
Les rafales 30 et 31 comportent respectivement une partie 33, 33A occupée par une section MPE, une partie 34, 34A occupée par des sections MPE-FEC et une partie 35, 35A de bourrage MPEG2. Dans l'exemple représenté, qui est un cas général, les surfaces des parties 33A à 35A ne sont pas égales aux surfaces 33 à 35 respectivement, mais leurs surfaces totales sont égales.
Le diagramme inférieur de la figure 6 se rapporte à la troisième caractéristique de l'invention. On y a représenté deux rafales successives 36, 37 du même service que celui auquel appartiennent les rafales 30 et 31 et correspondant respectivement aux rafales 30, 31. Ces deux rafales comportent d'abord des parties 38, 38A occupées par des sections MPE et correspondant respectivement aux parties 33 et 33A. Dans la rafale 36, la partie 38 est suivie d'une partie 39 occupée par des sections MPE-FEC (comme la partie 34) et d'une partie 40 occupée par des sections MPE-FEC ajoutées (remplaçant du bourrage MPEG2 tel que le bourrage 35). Dans la rafale 37, la partie 38A est suivie d'une partie 41 occupée par des sections MPE insérées, d'une partie 42 occupée par des sections MPE-FEC et d'une partie 43 occupée par des sections MPE-FEC ajoutées.
Dans le diagramme inférieur, pour la première rafale, on ajoute des colonnes de FEC pour réutiliser la bande passante de colonnes applicatives non utilisées, mais il n'y a pas suffisamment de bande passante disponible (colonnes applicatives non utilisées) pour que l'on arrive au nombre maximal de colonnes de FEC (64). Donc, pour cette rafale, la bande passante disponible a été réutilisée uniquement par ajout de colonnes de FEC. En revanche, pour la deuxième rafale, il y a suffisamment de colonnes applicatives non utilisées pour que le maximum des colonnes de FEC soient ajoutées (colonnes de FEC déjà présentes + colonnes de FEC ajoutées = 64). Dans ce cas, on continue l'optimisation en utilisant la bande passante encore restante pour ajouter des données opportunistes. On procède dans cet ordre pour l'exemple décrit ici, mais il est possible d'envisager n'importe quel ordre d'insertion.
2890519 12

Claims (4)

REVENDICATIONS
1. Procédé d'optimisation de l'utilisation de la bande passante d'une émission à diffusion en rafales, du type à rafales comportant au moins une partie réservée aux données utiles d'un service, caractérisé en ce que l'on insère dans au moins cette partie des données supplémentaires.
2. Procédé selon la revendication 1, pour lequel les rafales comportent en outre au moins une partie réservée aux données de contrôle, caractérisé en ce que l'on insère des données supplémentaires de contrôle dans au moins une de ces parties réservées aux données de contrôle, afin d'augmenter la robustesse de transmission des données utiles.
3. Procédé selon la revendication 1 ou 2, caractérisé en ce que 1' on insère des données supplémentaires dans la partie correspondante des rafales, le flux de ces données étant contrôlé.
4. Procédé selon la revendication 1 2 ou 3, caractérisé en ce que lorsque la norme de transmission est DVB-H, on insère dans les FECFrame d'au moins une partie des rafales des données de contrôle et/ou on insère des données applicatives dans la partie applicative de ces FEC-Frame.
FR0509094A 2005-09-06 2005-09-06 Procede d'optimisation de l'utilisation de la bande passante d'une emission a diffusion en rafales Expired - Fee Related FR2890519B1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
FR0509094A FR2890519B1 (fr) 2005-09-06 2005-09-06 Procede d'optimisation de l'utilisation de la bande passante d'une emission a diffusion en rafales
PCT/EP2006/065990 WO2007028786A1 (fr) 2005-09-06 2006-09-05 Procede d'optimisation de l'utilisation de la bande passante d'une emission a diffusion en rafales

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0509094A FR2890519B1 (fr) 2005-09-06 2005-09-06 Procede d'optimisation de l'utilisation de la bande passante d'une emission a diffusion en rafales

Publications (2)

Publication Number Publication Date
FR2890519A1 true FR2890519A1 (fr) 2007-03-09
FR2890519B1 FR2890519B1 (fr) 2007-12-28

Family

ID=36579453

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0509094A Expired - Fee Related FR2890519B1 (fr) 2005-09-06 2005-09-06 Procede d'optimisation de l'utilisation de la bande passante d'une emission a diffusion en rafales

Country Status (2)

Country Link
FR (1) FR2890519B1 (fr)
WO (1) WO2007028786A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2932631A1 (fr) * 2008-06-13 2009-12-18 Enensys Technologies Procede et dispositif de controle de la transmission d'un flux de donnees numeriques conformees en salves.

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004079982A1 (fr) * 2003-03-05 2004-09-16 Nokia Corporation Procede et systeme de correction d'erreurs sans voie de retour
WO2004107619A1 (fr) * 2003-05-30 2004-12-09 Nokia Corporation Transmission par rafales

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004079982A1 (fr) * 2003-03-05 2004-09-16 Nokia Corporation Procede et systeme de correction d'erreurs sans voie de retour
WO2004107619A1 (fr) * 2003-05-30 2004-12-09 Nokia Corporation Transmission par rafales

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
"Digital Video Broadcasting (DVB); DVB specification for data broadcasting; ETSI EN 301 192", ETSI STANDARDS, EUROPEAN TELECOMMUNICATIONS STANDARDS INSTITUTE, SOPHIA-ANTIPO, FR, vol. BC, no. V141, November 2004 (2004-11-01), XP014026918, ISSN: 0000-0001 *
DVB: "DVB-H Implementation Guidelines", DIGITAL VIDEO BROADCASTING, July 2005 (2005-07-01), XP002376159 *
YAO J ET AL: "IP datacasting and channel error handling with DVB-H", EMERGING INFORMATION TECHNOLOGY CONFERENCE, 2005 NTU, TAIPEI, TAIWAN AUG. 15-16, 2005, PISCATAWAY, NJ, USA,IEEE, 15 August 2005 (2005-08-15), pages 61 - 63, XP010856441, ISBN: 0-7803-9328-7 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2932631A1 (fr) * 2008-06-13 2009-12-18 Enensys Technologies Procede et dispositif de controle de la transmission d'un flux de donnees numeriques conformees en salves.

Also Published As

Publication number Publication date
FR2890519B1 (fr) 2007-12-28
WO2007028786A1 (fr) 2007-03-15

Similar Documents

Publication Publication Date Title
US11032344B2 (en) Content delivery
US9641578B2 (en) Minimizing unicast bandwidth in an adaptive bit rate system
US10812386B2 (en) Bulk data transport in a network
WO2018203336A1 (fr) Dispositif, système et procédé de prétraitement et de distribution de données pour des communications à liaisons multiples et pour un contenu multimédia
US20050013274A1 (en) System and method for data transmission and reception
US9729939B2 (en) Distribution of MPEG-2 TS multiplexed multimedia stream with selection of elementary packets of the stream
FR2927216A1 (fr) Methode de transmission d'images numeriques et de reception de paquets de transport.
US9516390B2 (en) Scaling video delivery
CN110099086B (zh) 一种基于融合传输系统的数据传输方法
FR2949931A1 (fr) Procedes et dispositifs de transmission d'un flux de donnees, produit programme d'ordinateur et moyen de stockage correspondants.
FR3032580A1 (fr) Ajustement dynamique du mode de transmission dans un systeme de communication satellite
EP1845685B1 (fr) Transmission perfectionnée de paquets IP de contenus, par adjonction à ces paquets IP de données d'information relatives aux contenus
EP2119077B1 (fr) Procede et dispositif contre la perte de salves dans un systeme de transmission dvb-h
EP1977600B1 (fr) Methodes de diffusion ou de reception de services de video numeriques, appareils correspondants
WO2011010297A2 (fr) Procede de diffusion de donnees numeriques
FR2922710A1 (fr) Procede optimise de transmission, vers des terminaux mobiles et via une infrastructure radio a methode d'acces de type tdm/tdma/ofdma, de contenus en couches, et dipositif de traitement associe
US20200228860A1 (en) Broadcast signal reception apparatus and broadcast signal processing method
FR2890519A1 (fr) Procede d'optimisation de l'utilisation de la bande passante d'une emission a diffusion en rafales
EP3780632A1 (fr) Systeme de distribution d'un contenu audiovisuel
FR2922401A1 (fr) Dispositif de reception en continu de paquets de donnees audio et/ou video
US11316776B2 (en) System and method for bypassing a content delivery network (CDN)
EP1853039B1 (fr) Équipements d'encapsulation IP et de modulation pour la transmission de paquets IP de données par synchronisation de méga-trames avec des méga-rafales
Bradbury A scalable distribution system for broadcasting over IP networks
FR3068559A1 (fr) Procede de generation d'un flux de donnees, passerelle de diffusion, procede et equipement de selection d'un flux de donnees et programme d'ordinateur correspondant
Chang et al. Adaptive streaming schemes for MPEG-DASH overWiFi multicast

Legal Events

Date Code Title Description
ST Notification of lapse

Effective date: 20090529