FR2929469A1

FR2929469A1 - Procede de detection de paquets ip manquants dans un flux dvb-h

Info

Publication number: FR2929469A1
Application number: FR0801683A
Authority: FR
Inventors: Williams Guitton
Original assignee: Enensys Technologies SA
Current assignee: Enensys Technologies SA
Priority date: 2008-03-27
Filing date: 2008-03-27
Publication date: 2009-10-02
Anticipated expiration: 2028-03-27
Also published as: WO2009118258A1; FR2929469B1

Abstract

La présente invention concerne le domaine de la diffusion de services multimédia à destination de terminaux de restitution de ces services. Plus particulièrement, on s'intéresse à la diffusion de services en mode salve (burst en anglais) à destination de terminaux mobiles comme c'est le cas, par exemple, dans la norme de diffusion DVB-H (Digital Video Broadcasting - Handheld en anglais) définie dans le document "ETSI EN 302 304, DVB-H - Transmission System for Handheld Terminals".L'invention propose un procédé permettant de détecter la perte de paquets IP dans un flux DVB-H reçu en mode de transmission par salve. Dans le cas où le flux est envoyé sans correction d'erreur de type FEC (Forward Error Correction en anglais), l'invention propose un procédé de génération d'un flux adapté pour permettre la détection facile de la perte de paquets IP.

Description

La présente invention concerne le domaine de la diffusion de services multimédia à destination de terminaux de restitution de ces services. Plus particulièrement, on s'intéresse à la diffusion de services en mode salve (burst en anglais) à destination de terminaux mobiles comme c'est le cas, par exemple, dans la norme de diffusion DVB-H (Digital Video Broadcasting ù Handheld en anglais) définie dans le document "ETSI EN 302 304, DVB-H ù Transmission System for Handheld Terminals". Un ensemble de services numériques à destination de terminaux mobiles est généralement diffusé sous la forme d'un flux de données numériques. Pour la diffusion de ces flux de données, le protocole IP (Internet Protocol en anglais défini par la RFC 791) tend à se généraliser. Chaque service est alors divisé en paquets IP. Dans les systèmes de diffusion de type DVB, ces flux de données IP sont encapsulés selon un protocole appelé MPE (MPE : Multi Protocol Encapsulation en anglais défini par le document ETSI EN 301 192). Le protocole MPE définit des paquets de données appelées sections. Ces sections sont constituées d'un entête et d'une partie donnée. La partie donnée contient généralement exactement un paquet IP du service à diffuser. Ces sections constituant les différents services sont alors multiplexées, c'est-à-dire mélangées, au sein du flux. Pour la diffusion proprement dite, ces sections sont elles-mêmes encapsulées dans un flux dit flux de transport ou flux TS (Transport Stream en anglais) selon le protocole MPEG-2 (Moving Picture Experts Group en anglais défini pour la partie transport dans le document ISO/CEI13818•-1). Les sections sont alors découpées et transportées dans des paquets appelés paquets TS. Dans le cas de terminaux mobiles, il est courant de rassembler des sections d'un même service au sein de salves. Dans ce cas, la diffusion comporte l'émission successive de salves constituées de sections d'un même service. De cette manière, le terminal de réception peut stopper sa partie radio entre les salves du service cu'il écoute. En bout de chaîne de transmission DVB-H, un service peut être dégradé à cause de différents facteurs. Il est bien souvent difficile de situer la source du problème. Ce genre de situation peut avoir comme conséquence un son inaudible ou une image de mauvaise qualité. Il arrive que, au niveau du récepteur, le service soit dégradé alors que tous les indicateurs de réception sont corrects. Dans ce cas, la cause la plus probable est la perte d'un paquet IP. Pour pouvoir diagnostiquer correctement l'origine d'un éventuel problème, il est avantageux de pouvoir détecter la perte de datagramme IP sur une transmission DVB-H. L'invention propose un procédé permettant de délecter la perte de paquets IP dans un flux DVB-H reçu en mode de transmission par salves. Dans le cas où le flux est envoyé sans correction d'erreur de type FEC (Forward Error Correction en anglais), l'invention propose un procédé de génération d'un flux adapté pour permettre la détection facile de la perte de paquets IP. L'invention concerne un procédé de détection de datagrammes IP manquants dans un flux de données diffusé selon la norme DVB-H, le flux de données comprenant des sections de données transportant chacune un datagramme IP, chaque section de données comprenant un entête, l'entête comprenant une structure de données comprenant un champ appelé address, la valeur de ce champ address indiquant l'adresse dans une table de données du premier octet du datagramme IP transporté. Ledit procédé comprenant une étape de réception d'une section de données; une étape de lecture du champ address (2.2) et une étape de détection de datagrammes IF manquants dans le flux reçu par analyse de la séquence des valeurs du champ address des sections reçues. Selon un mode particulier de réalisation de l'invention, l'étape de détection est faite périodiquement après stockage d'un ensemble de datagrammes dans une table de 20 données aux adresses correspondant à la valeur du champ address. L'étape de détection est faite par calcul sur la valeur du champ address de la section précédente et de la taille du datagramme IP précédent, leur somme étant comparée à la valeur du champ address de la section courante. L'invention concerne également un procédé de génération d'un flux de données 25 diffusé selon la norme DVB-H, comprenant une étape d'insertion dans le flux de données de sections de données transportant chacune un datagramme IP, chaque section de données comprenant un entête ; une étape de génération de l'entête desdites sections comprenant une structure de données comprenant un champ appelé address ; une étape de calcul de la valeur de ce champ address indiquant l'adresse dans une 30 table de données du premier octet du datagramme IP transporté, caractérisé en ce que ledit procédé ne comporte pas d'étape d'insertion dans le flux de sections transportant des données de redondance de type FEC.

L'invention concerne également un flux de données diffusé selon la norme DVB-H, comprenant des sections de données transportant chacune un datagramme IP, chaque section de données comprenant un entête, chaque entête desdites sections comprenant une structure de données comprenant un champ appelé address, la valeur de ce champ address indiquant l'adresse dans une table de données du premier octet du datagramme IP transporté, caractérisé en ce que ledit flux ne comporte pas de sections transportant des données de redondance de type FEC. Les caractéristiques de l'invention mentionnées ci-dessus, ainsi que d'autres, apparaîtront plus clairement à la lecture de la description suivante d'un exemple de réalisation, ladite description étant faite en relation avec les dessins joints, parmi lesquels : La Fig. 1 illustre l'architecture d'un flux de données DVB-H. La Fig. 2 illustre un exemple de procédé de détection de la perte de paquets IP. En référence à la Fig. 1, nous allons décrire la structure d'un flux de données DVB-H. Le flux reçu est un flux de transport MPEG-2 TS composé de paquets TS tels les paquets 1.1, 1.2, 1.3 et 1.4. Ces paquets TS ont typiquement une taille de 188 octets. Ils transportent dans leur partie donnée des sections MPE 1.5 et 1.6. Ces sections MPE ont une taille nettement plus élevée et sont donc découpées en fragments au sein des paquets TS. Ces sections MPE sont composées d'un entête, d'une partie donnée et d'une somme de contrôle CRC ((ÿclic redundancy check en anglais). Les sections MPE de données transportent les datagrammes IP 1.8 composant le service diffusé. Le flux de sections MPE peut être protégé par un code correcteur d'erreurs. Ce code correcteur d'erreurs est appelé FEC (F'orward Error Correction en anglais). Ce code est calculé de la manière suivante. Les datagrammes sont rangés dans une table dite d'application (Application Data Table en anglais) correspondant à la table 1.10. Le nombre de lignes de cette table correspond à une puissance de 2 et peut être égale à 256, 512, 768 ou 1024. Les datagrammes IP sont groupés en trame FEC (FEC' frarnes en anglais). Les datagrammes IP sont rangés dans cette table en colonne, le premier datagramme démarrant en haut à gauche de la table. Le second datagramme IP démarre à la suite du premier. Tout datagramme ne rentrant pas dans une solo Zne unique est divisé sur deux colonnes. La table est composée de 191 colonnes. Si les datagrammes ne remplissent pas intégralement la table, les dernières colonnes sont remplies de données de bourrage. Une seconde table de 64 colonnes et d'autant de lignes que la table de données est alors calculée. Cette seconde table 1.11 est appelée table de données RS (Reed Solomon en anglais). Pour chaque ligne de la :able d'application, u.ne fonction RS est calculée qui donne 64 octets de redondance que l'on stocke dans la table de données RS.

Lorsque le flux de sections MPE est protégé par un code FEC comme précédemment décrit, les données de redondance sont transportées au sein de sections appelées MPE-FEC 1.6. Ces sections contiennent exactement une colonne 1.9 de la table de données RS. La norme EN 301 192 précise que dans le cas d'un flux formé en salve (burst en anglais) et/ou protégé par un code FEC, l'entête des sections MPE de données contient une structure de données appelée RealTimeParameterO 1.7 qui contient quatre champs. Un premier champ est appelé delta-t et est une information temporelle relative au moment d'émission de la salve suivante pour le même service. Le champ tableboundary est un drapeau signalant la dernière section d'une table. Le champ frame_boundary est un drapeau signalant la dernière section d'une trame. Le champ address est l'adresse du premier octet du datagramme IP transporté dans la table de données utilisée pour le calcul du code d'erreur FEC. Lors de la réception d'une section MPE, le récepteur utilise donc la valeur du champ address pour ranger dans la table 1.10 le datagramme IP stocké dans la partie données de la section. Les sections MPE-FEC reçues ensuite sont rangées dans la table 1.11. Le récepteur est alors à même de pouvoir effectuer l'étape de correction d'erreur pour réparer les données erronées à l'aide des informations de redondance dans la limite du code correcteur utilisé. Dans le cas où le flux diffusé n'est pas conformé en salves et que le mécanisme de protection du flux par FEC n'est pas utilisé, la norme EN 301 192 ne prévoit pas l'utilisation dans les entêtes de section de la structure RealTimeParameterO. Dans le cas où le flux est conformé en salve mais où le mécanisme de protection par FEC n'est pas utilisé, la structure est présente mais le champ address est alors non utilisé et forcé à une valeur Ox3 FFFF correspondant à tous les bits à 1.

Dans le cas d'un flux protégé par un mécanisme de FEC, pour résoudre le problème de la détection des datagrammes IP manquants, les inventeurs ont eu l'idée d'utiliser les paramètres contenus dans la structure RealTimeParameterO et en particulier le champ address. En effet, la longueur des datagrammes IP étant connue, il est facile de vérifier que les valeurs des champs address des sections de données reçues suivent une progression régulière par bond correspondant à la taille du datagramme modulo la taille de la table. La Fig. 2 illustre un procédé de détection de la perte de datagrammes IP selon un exemple de réalisation de l'invention. Lors d'une première étape 2.1, une section 5 MPE est reçue. Le récepteur lit alors la valeur du champ address dans l'entête de cette section lors d'une étape 2.2. Il utilise alors cette valeur pour le stockage du datagramme IP contenu dans la partie donnée. Ce datagramme est alors rangé dans la table de données 1.10 à l'adresse lue lors de l'étape 2.2. C'est l'étape 2.3. Le récepteur se pose alors la question de savoir s'il s'agit de la dernière section de donnée reçue pour cette trame lors d'une étape 2.4. Il suffit de lire la valeur du champ tableboundary de l'entête de la section. Dans le cas où l'on n'est pas en fin de table, le récepteur boucle sur la réception de la section suivante. Dans le cas où l'on est en fin de table, le récepteur opère une détection des datagrammes IP manquants sur la table reçue lors d'une étape 2.5. Pour ce faire, il lui suffit de vérifier qu'il n'existe pas de trous dans cette table. Ce procédé n'est qu'un exemple de réalisation, il est évident que cette détection des paquets manquants peut être effectuée de diverses manières en utilisant les mêmes informations. En particulier, il est possible d'effectuer cette détection après la réception de chaque paquet et non pas uniquement après avoir reçu la table complète.

De même, cette étape peut être faite par un simple calcul sur la valeur du champ address de la section précédente, la taille du datagramme précédent et de comparer leur somme à la valeur du champ address de la section courante. Ce calcul est fait modulo la taille de la table. On peut donc effectuer cette détection indépendamment du stockage des datagrammes pour l'étape de correction d'erreur FEC. En particulier, dans certains modes de réalisation, la correction des erreurs FEC peut être omise et dans ce cas, l'étape de stockage des données 2.3 a lieu dans un tampon du récepteur et non pas dans une table de données FEC. Dans tous les cas, la détection des datagrammes IP manquants se fait par analyse de la séquence des valeurs du champ address des sections reçues.

Le procédé selon l'invention utilise donc les données de la structure RealTimeParameter initialement prévue pour régler les problèmes de temps réels du mode de transmission par salve et le stockage des données dans une table en vue du calcul de correction d'erreur FEC pour résoudre le problème de la détection des datagrammes IP manquants.

Cette détection n'est pas possible dans le cas où le mécanisme de correction d'erreur FEC n'est pas utilisé. En effet, dans ce cas, la norme nous dit de fixer la valeur du champ address à une valeur constante Ox3FFFF. Selon un aspect de l'invention, le flux généré est adapté et même dans le cas où le mécanisme de correction d'erreur FEC n'est pas utilisé, on génère des sections de données possédant un champ address dont la valeur est calculée de la même manière que si la correction FEC était utilisée. La génération du flux comprendra donc une étape de calcul de la valeur du champ address correspondant à l'adresse de stockage du datagramme dans une table de données FEC en l'absence de calcul et d'insertion de sections MPE-FEC dans le flux. Le flux généré selon ce procédé est donc composé de sections de données MPE comprenant dans leur entête une structure de données RealTimeParameterO comprenant un champ address dont la valeur correspond à l'adresse dans une table de données FEC du premier octet du datagramme IP stocké dans la partie données de la section. Le flux généré ne comprenant pas de sections MPE-FEC, donc de sections transportant des données de redondance de type FEC. Cette détection n'est également pas possible dans le cas où le flux diffusé, bien que restant conforme à DVB-H, n'est pas conformé en salves et que le mécanisme de protection du flux par FEC n'est pas utilisé. En effet, dans ce cas, la norme ne demande pas d'utiliser la structure de données RealTimeParameter(). Selon un aspect de l'invention, le flux généré est adapté et même dans le cas où le mécanisme de correction d'erreur FEC n'est pas utilisé et que le flux n'est pas conformé en salves, on génère des sections de données possédant la structure de données RealTimeParameter() et dans celles-ci un champ address dont la valeur est calculée de la même manière que si la correction FEC était utilisée. La génération du flux comprendra donc une étape de calcul de la valeur du champ address correspondant à l'adresse de stockage du datagramme dans une table de données FEC en l'absence de calcul et d'insertion de sections MPE-FEC dans le flux. Le flux généré selon ce procédé est donc composé de sections de données MPE comprenant dans leur entête une structure de données RealTimeParameter() comprenant un champ address dont la valeur correspond à l'adresse dans une table de données FEC du premier octet du datagramme IP stocké dans la partie données de la section. Le flux généré n'étant pas conformé en salves et ne comprenant pas de 7 sections MPE-FEC, donc de sections transportant des données de redondance de type FEC.

Claims

REVENDICATIONS1/ Procédé de détection de datagrammes IP manquants dans un flux de données diffusé selon la norme DVB-H, le flux de données comprenant des sections de données transportant chacune un datagramme IP, chaque section de données comprenant un entête, l'entête comprenant une structure de données comprenant un champ appelé address, la valeur de ce champ address indiquant l'adresse dans une table de données du premier octet du datagramme IP transporté, comprenant les étapes suivantes : - une étape de réception d'une section de données (2.1) ; - une étape de lecture du champ address (2.2) ; caractérisé en ce qu'il comprend en outre : - une étape de détection de datagrammes IP manquants dans le flux reçu par analyse de la séquence des valeurs du champ address des sections reçues. 2/ Procédé de détection selon la revendication 1, caractérisé en ce que l'étape de détection est faite périodiquement après stockage d'un ensemble de datagrammes dans une table de données aux adresses correspondant à la valeur du champ address. 3/ Procédé de détection selon la revendication 1, caractérisé en ce que l'étape de détection est faite par calcul sur la valeur du champ address de la section précédente et de la taille du datagramme IP précédent, leur somme étant comparée à la valeur du champ address de la section courante. 25 4/ Procédé de génération d'un flux de données diffusé selon la norme IDVB-H, comprenant : - une étape d'insertion dans le flux de données de sections de données transportant chacune un datagramme IP, chaque section de données comprenant un 30 entête ; - une étape de génération de l'entête desdites sections comprenant une structure de données comprenant un champ appelé address ; - une étape de calcul de la valeur de ce champ address indiquant l'adresse dans une table de données du premier octet du datagramme IP transporté, caractérisé en ce20 9 que ledit procédé ne comporte pas d'étape d'insertion dans le flux de sections transportant des données de redondance de type FEC. 5/ Flux de données diffusé selon la norme DVB-H., comprenant des sections de données transportant chacune un datagramme IP, chaque section de données comprenant un entête, chaque entête desdites sections comprenant une structure de données comprenant un champ appelé address, la valeur de ce champ address indiquant l'adresse dans une table de données du premier octet du datagramme IP transporté, caractérisé en ce que ledit flux ne comporte pas de sections transportant des données de redondance de type FEC.