FR2832827A1 - Procedes et dispositifs de gestion des transmissions de donnees isochrones sur des supports non dedies - Google Patents

Abstract

La présente invention concerne le transfert de données dans un réseau de communication dans lequel les données sont groupées en paquets, une communication étant formée d'un ensemble de paquets transmis entre des hôtes du réseau fonctionnant comme sources etlou comme récepteurs de données, et reliés entre eux par l'intermédiaire d'un réseau comprenant au moins un premier sous-réseau (2) et un deuxième sous-réseau (4) interconnectés par un moyen d'interconnexion (7), la bande passante dudit premier sous-réseau (2) étant supérieure à la bande passante dudit deuxième sous-réseau (4). L'invention permet notamment d'assurer, au sein d'un tel réseau comprenant des liens dédiés au transport isochrone, les transferts de données isochrones sur un support de transmission, par exemple radio, qui n'est pas dédié au transport isochrone.Application aux systèmes audiovisuels, notamment ceux utilisant des bus filaires selon la norme IEEE1394 et des liens radio selon la norme IEEE802. 11 b.

Description

<Desc/Clms Page number 1>

La présente invention concerne le transfert de données dans un réseau de communication, dans lequel les données sont groupées en paquets de longueur fixe ou variable qui sont transmis entre des hôtes du réseau ( hosts en anglais) fonctionnant comme sources et/ou comme récepteurs de données. Ces paquets contiennent des données utiles ( message payload en anglais), et des données de service placées dans l'en-tête et/ou l'appendice du paquet.

Un tel réseau de communication peut être subdivisé en sous-réseaux pouvant utiliser des supports de transmission, aussi appelés liens , différents (filaire, radio, ou autre) et/ou pouvant disposer de bandes passantes différentes.

L'invention concerne plus particulièrement des procédés et des dispositifs aptes à assurer le transfert des paquets de données à travers un réseau constitué de sous-réseaux de différents types dont certains disposent d'une bande passante inférieure aux autres sous-réseaux, et/ou lorsqu'aucun mécanisme de synchronisation du transfert entre tous les sous-réseaux n'a été prévu a priori, par exemple en appliquant une norme appropriée.

Dans un réseau de communication, les sous-réseaux sont habituellement interconnectés au moyen de dispositifs appelés moyens d'interconnexion ou ponts ( bridges en anglais). Ces dispositifs ont pour fonction de recevoir des paquets de données, de les analyser et les faire suivre vers leur destination. Plus précisément, un paquet arrivant dans un pont en provenance d'un sous-réseau est passé à la couche de liaison de données du pont pour analyse ; le pont retransmet ensuite le paquet vers sa destination sur un autre sous-réseau. Le pont peut effectuer des opérations mineures sur le paquet avant de le retransmettre comme, par exemple, ajouter ou supprimer des champs contenant des données de service. Les ponts jouent donc un rôle essentiel en ce qui concerne la gestion du transfert des paquets entre les hôtes du réseau.

Les réseaux de communication modernes ont souvent pour tâche de transmettre des données de divers types comme de la vidéo, du son, des photos, des fichiers de texte, et ainsi de suite. Or la transmission de ces

<Desc/Clms Page number 2>

données est soumise à des exigences variables selon le type de données considéré.

En effet, la vidéo par exemple demande un transfert de données à un débit régulier ; c'est encore plus vrai pour le son : on dit alors qu'on a affaire à des données isochrones . Un mode de transmission isochrone est un mode de transmission synchrone garantissant une date de réception des données, mais sans garantie de réception sans erreur, et sans retransmission possible en cas d'erreur.

En revanche, il n'est pas nécessaire de transmettre les données d'un fichier de texte de manière régulière, ou même continue : on dit alors qu'on a affaire à des données asynchrones ; comme autres exemples de données asynchrones, on peut citer les commandes de mise en marche ou d'arrêt de divers appareils, et aussi les données alimentant les imprimantes. Un mode de transmission asynchrone garantit la réception des données sans erreur avec envoi à la source d'un paquet servant d'accusé de réception, mais ne garantit pas une date de réception des données.

Les dispositifs capables de manipuler toutes ces données, appelés aujourd'hui communément dispositifs multimedia, doivent donc pouvoir transmettre des données asynchrones aussi bien que des données isochrones.

La norme IEEE1394 (également appelée FireWire ) définit une technologie de bus de communication série possédant des performances élevées, et véhiculant des données par paquets à des vitesses comprises entre 100 et 200 Mbps, voire de l'ordre de 400 Mbps. Ces bus sont destinés à relier des hôtes constitués par des appareils de traitement de données numériques tels que des systèmes informatiques ou des produits d'électronique grand public, par exemple des serveurs, ordinateurs personnels, téléviseurs, magnétoscopes, caméscopes, imprimantes, télécopieurs, scanners, décodeurs, tuners satellite, appareils photographiques numériques ou écrans haute définition. Cette norme stipulant des modes de communication isochrone et asynchrone pour le transfert de données, ces bus de communication sont adaptés aux applications multimédia, notamment dans la version haute

<Desc/Clms Page number 3>

performance de ces bus ( High Performance Serial Bus en anglais), qui est définie par la norme IEEE1394a-2000.

De plus, une norme appelée P1394.1, actuellement en phase finale d'écriture et d'adoption, concerne les ponts reliés à des bus selon la norme IEEE1394a-2000.

Comme expliqué ci-dessous, une application particulière de la présente invention concerne la communication entre sous-réseaux au travers d'un pont servant à connecter un bus série filaire, tel que défini par la norme IEEE1394a-2000, avec un lien radio, tel que défini par exemple par la norme IEEE802. 11 b.

Lorsque l'un des deux portails (en anglais, portais ) du pont d'interconnexion est connecté à un canal de transmission radio de type IEEE802. 11b par exemple, plusieurs problèmes se présentent lorsque l'on souhaite transmettre des données en mode isochrone.

Un premier problème concerne la synchronisation du transfert, compte tenu de la différence de bande passante entre les deux supports de transmission.

Selon la norme IEEE1394a-2000, une transmission isochrone sur un bus consiste à transférer exactement un paquet par cycle, chaque cycle ayant une durée de 125 fls : on transfère donc 8000 paquets par seconde. Chaque hôte émetteur doit normalement fournir au moins un paquet isochrone par cycle.

De manière générale, lorsque des informations sont transmises entre un appareil multimédia émetteur vers un second appareil multimédia récepteur, au sein de l'appareil multimédia émetteur les données sont formées en trames vidéo, qui sont ensuite subdivisées en paquets. Ces paquets sont alors transmis par exemple sur un réseau IEEE1394. On appellera communication toute transmission d'un ensemble de paquets entre deux hôtes d'un réseau de communication, par exemple deux appareils multimédia.

Pour les hôtes sources émettant des paquets à un débit plus faible (notamment les appareils électroniques audio/vidéo), il a été prévu, dans une norme appelée IEC61883, qu'une couche d'interface insère des paquets

<Desc/Clms Page number 4>

isochrones vides ( empty packets en anglais), c'est-à-dire sans données utiles , à chaque cycle de 125 ils lorsque l'application multimédia dudit hôte source n'a fourni aucun paquet de données utiles. Par exemple, une caméra vidéo au format PAL fournit 25 images par seconde ; si une image correspond à 300 paquets isochrones (de 496 octets chacun), cela correspond à un débit de 7500 paquets par seconde ; il faut donc ajouter 500 paquets vides par seconde, soit un paquet vide tous les 15 paquets vidéo. Naturellement, chaque hôte adapté à la réception de tels paquets (par exemple, un moniteur vidéo) est lui aussi équipé d'une interface à la norme IEC61883, qui est chargée de supprimer ces paquets vides véhiculés par le bus, de manière à ce que le débit de paquets utiles effectivement reçu par l'application multimédia de cet hôte récepteur soit conforme au débit qu'il attend (par exemple, 7500 paquets par seconde).

En revanche, rien n'a été prévu dans les normes connues en ce qui concerne les sous-réseaux présentant une bande passante plus faible.

Dans ces conditions, un premier but de l'invention est de proposer un procédé et un dispositif permettant de gérer le transfert de données isochrones à travers un pont pour lequel il existe une différence entre les bandes passantes des sous-réseaux situés de part et d'autre du pont. On notera que, dans le cas de réseaux comprenant des liens selon la norme IEEE1394a-2000, la mise en oeuvre de l'invention revient à ajouter des caractéristiques aux stipulations de la norme P1394. 1, sans violer aucune de ces stipulations.

L'invention concerne donc, selon un premier aspect, un procédé de transfert de données dans un réseau de communication dans lequel les données utiles sont groupées en paquets, une communication étant formée d'un ensemble de paquets transmis entre des hôtes du réseau fonctionnant comme sources et/ou comme récepteurs de données, et reliés entre eux par l'intermédiaire d'un réseau comprenant au moins un premier sous-réseau et un deuxième sous-réseau interconnectés par un moyen d'interconnexion, la bande passante dudit premier sous-réseau étant supérieure à la bande passante dudit deuxième sous-réseau, ledit procédé étant remarquable en ce que, lorsqu'une communication du premier sous-réseau vers le second sous-réseau comprend

<Desc/Clms Page number 5>

sur le premier sous-réseau au moins un paquet vide, ledit moyen d'interconnexion supprime ledit au moins un paquet vide.

Grâce à ces dispositions, au moyen du pont situé à l'entrée du sousréseau à faible bande passante, par exemple un lien radio selon IEEE802. 11 b, on supprime certains, ou tous les paquets vides provenant du sous-réseau à haute bande passante, par exemple un bus filaire selon IEEE1394a-2000. Un hôte de réception, adapté à recevoir ce type de paquets, pourra alors le traiter directement s'il est connecté à un dispositif de réception radio. Par exemple, l'hôte source pourra être une caméra vidéo au format PAL, et l'hôte récepteur un moniteur pour visualiser les images, tous deux utilisant un débit de 7500 paquets utiles par seconde, pourvu naturellement que le lien radio soit apte à véhiculer un tel débit.

Dans d'autres cas, on souhaitera retransmettre les paquets isochrones sur un bus filaire après leur réception du lien radio. Si la bande passante du lien radio est inférieure à la celle du bus filaire, le problème qui se pose alors est l'adaptation du débit des paquets en fonction des bandes passantes disponibles des deux sous-réseaux.

Selon donc un deuxième aspect de l'invention, celle-ci concerne un procédé de transfert de données dans un réseau de communication dans lequel les données utiles sont groupées en paquets, une communication étant formée d'un ensemble de paquets transmis entre des hôtes du réseau fonctionnant comme sources et/ou comme récepteurs de données, et reliés entre eux par l'intermédiaire d'un réseau comprenant au moins un premier sous-réseau et un deuxième sous-réseau interconnectés par un moyen d'interconnexion, la bande passante dudit premier sous-réseau étant supérieure à la bande passante dudit deuxième sous-réseau, ledit procédé étant remarquable en ce que, lorsqu'une communication se dirige du deuxième sous-réseau vers le premier sousréseau, - on détermine le type de données transférées, et - ledit moyen d'interconnexion insère au moins un paquet vide dans ladite communication si le type de données utiles correspond à au moins un type prédéterminé.

<Desc/Clms Page number 6>

Selon des caractéristiques particulières, ledit moyen d'interconnexion insère un nombre prédéterminé de paquets vides qui dépend dudit type de données utiles.

Grâce à ces dispositions, au moyen du pont situé à la sortie du sousréseau à faible bande passante, par exemple un lien radio selon IEEE802. 11 b, on insère des paquets vides lors de la rémission sur le sous-réseau à haute bande passante, par exemple un bus filaire selon IEEE1394, en fonction de la bande passante requise par ce dernier. On notera que cette fonctionnalité se distingue de la tâche effectuée par une interface selon IEC61883, en ce que le pont d'interconnexion selon l'invention peut insérer des paquets vides lors de la réémission sur le bus filaire alors qu'il dispose en mémoire de paquets de données utiles arrivés par le lien radio. Cette fonctionnalité peut être notamment très utile pour des raisons de fiabilité : par exemple, on pourra s'assurer que l'on a reçu une image complète avant de la retransmettre sur le sous-réseau subséquent.

Il est clair que l'invention selon ce deuxième aspect est particulièrement avantageuse lorsque lesdites données utiles sont des données isochrones, compte tenu de la régularité de transmission requise.

Cependant, on doit alors résoudre un problème corollaire, qui concerne la capacité pour un pont selon l'invention de détecter qu'une communication isochrone arrive à sa fin.

Selon la norme IEEE1394a-2000 (Section 8.4. 3), les transferts de données se font suivant des cycles ayant une structure bien définie. Chaque cycle de 125 f. ls peut être divisé en canaux isochrones de longueur variable (le nombre de canaux pouvant ainsi être alloués à chaque cycle pouvant aller jusqu'à 63). Un paquet d'un type appelé début de cycle ( cycle start en anglais) comportant des informations temporelles concernant le bus IEEE 1394, matérialise le début d'un nouveau cycle. Ce paquet sert de référence pour les hôtes connectés sur ce bus qui veulent transmettre un paquet de données dans un canal isochrone qu'ils auront préalablement réservé.

Une communication isochrone entre deux hôtes interconnectés par l'entremise d'un bus série se fait en plusieurs étapes :

<Desc/Clms Page number 7>

- l'hôte source fait une réservation de canal isochrone auprès du dispositif responsable de la gestion des communications isochrones (en anglais, /sochronous Resource Manager ), - l'hôte source insère à chaque cycle un paquet isochrone dans le canal qui lui a été alloué, chaque hôte destinataire se mettant à l'écoute sur ce canal pour recevoir les paquets, et - la communication se termine lorsqu'aucun paquet n'est inséré dans le canal approprié.

Dans ces conditions, le problème qui se pose quand on utilise un pont selon l'invention, tel que décrit succinctement ci-dessus, est le suivant : comment donner instruction à ce pont d'arrêter d'insérer des paquets vides dans ledit canal après qu'il ait retransmis le dernier paquet isochrone utile ?
Certains réseaux radio tels que définis par la norme HiperLAN2 (plus précisément par les normes HiperLAN2 SSCS et HiperLAN2 Bridge Sublayer) définissent des protocoles de communication pour détecter la fin des communications isochrones à partir d'un signal radio physique de synchronisation.

En revanche, la norme IEEE802. 11 b pour réseaux radio, par exemple, ne prévoit pas un tel protocole. Un second but de l'invention est de suppléer à cette lacune.

Selon donc des caractéristiques particulières de l'invention selon son premier aspect, ledit moyen d'interconnexion insère un nombre prédéterminé de paquets vides dans ladite communication lorsque celle-ci se termine.

Grâce à ces dispositions, un pont émettant une communication sur un lien radio peut informer le pont recevant cette communication à l'autre extrémité de ce lien radio, que la communication prend fin.

De même, selon des caractéristiques particulières de l'invention selon son deuxième aspect, lorsque ledit moyen d'interconnexion détecte une suite d'un nombre prédéterminé de paquets vides dans ladite communication, ce moyen d'interconnexion arrête la communication.

Ces dispositions sont particulièrement avantageuses quand les données utiles sont des données isochrones : on émet sur le lien radio en

<Desc/Clms Page number 8>

succession un nombre prédéterminé de paquets vides, afin de notifier au pont récepteur la fin de la transmission isochrone ; celui-ci s'arrêtera alors d'insérer des paquets isochrones vides dans le canal utilisé pour cette communication sur le lien filaire auquel ce pont récepteur est connecté, ce qui sera automatiquement compris par les hôtes à l'écoute comme signifiant une fin de communication.

On voit donc que l'invention, dans ses divers aspects, permet d'assurer, au sein d'un réseau de communication comprenant des liens dédiés au transport isochrone, les transferts de données isochrones sur un support de transmission, par exemple radio, qui n'est pas dédié au transport isochrone.

L'invention concerne aussi divers dispositifs.

Elle concerne ainsi, premièrement, un moyen d'interconnexion destiné à interconnecter un premier sous-réseau et un deuxième sous-réseau faisant partie d'un réseau de communication dans lequel les données utiles sont groupées en paquets, une communication étant formée d'un ensemble de paquets transmis entre des hôtes du réseau fonctionnant comme sources et/ou comme récepteurs de données, et reliés entre eux par l'intermédiaire dudit réseau, la bande passante dudit premier sous-réseau étant supérieure à la bande passante dudit deuxième sous-réseau, ledit moyen d'interconnexion étant remarquable en ce qu'il comprend - une unité de réception et de transmission de paquets, - une unité de détection apte à détecter d'éventuels paquets vides, et - une unité de suppression apte à supprimer au moins un paquet vide dans une communication du premier sous-réseau vers le second sous-réseau.

Selon des caractéristiques particulières, ce moyen d'interconnexion comprend également une unité de gestion apte à gérer l'émission de paquets vides.

L'invention concerne aussi, deuxièmement, un moyen d'interconnexion destiné à interconnecter un premier sous-réseau et un deuxième sous-réseau faisant partie d'un réseau de communication dans lequel les données utiles sont groupées en paquets, une communication étant formée d'un ensemble de paquets transmis entre des hôtes du réseau fonctionnant

<Desc/Clms Page number 9>

comme sources et/ou comme récepteurs de données, et reliés entre eux par l'intermédiaire dudit réseau, la bande passante dudit premier sous-réseau étant supérieure à la bande passante dudit deuxième sous-réseau, ledit moyen d'interconnexion étant remarquable en ce qu'il comprend - une unité de réception et de transmission de paquets, - une unité de gestion apte à gérer l'émission de paquets vides, et - une unité de stockage apte à stocker des paquets de données en mémoire.

Selon des caractéristiques particulières, ce moyen d'interconnexion comprend également une unité d'achèvement apte à détecter la succession d'un nombre prédéterminé de paquets vides en provenance dudit deuxième sous-réseau.

L'invention vise également : - un réseau de communication, comprenant au moins un moyen d'interconnexion tel que décrit succinctement ci-dessus, - un moyen de stockage de données comportant des instructions de code de programme informatique pour l'exécution des étapes de l'un quelconque des procédés succinctement exposés ci-dessus, - un moyen de stockage de données amovibles, partiellement ou totalement, comportant des instructions de code de programme informatique pour l'exécution des étapes de l'un quelconque des procédés succinctement exposés ci-dessus, et - un programme d'ordinateur, contenant des instructions telles que, lorsque ledit programme commande un dispositif de traitement de données programmable, lesdites instructions font que ledit dispositif de traitement de données met en oeuvre l'un des procédés succinctement exposés ci-dessus.

Les avantages offerts par ces moyens d'interconnexion, réseaux de communication, moyens de stockage de données et programmes d'ordinateur sont essentiellement les mêmes que ceux offerts par les procédés selon l'invention.

D'autres aspects et avantages de l'invention apparaîtront à la lecture de la description détaillée ci-dessous de modes particuliers de réalisation,

<Desc/Clms Page number 10>

donnés à titre d'exemples non limitatifs. La description se réfère aux dessins qui l'accompagnent, dans lesquels : - la figure 1 représente de façon schématique un réseau de communication comprenant des liens filaires et des liens radio, - la figure 2 représente un format classique pour les paquets de données isochrones, - la figure 3 représente le format des cycles de transfert de données selon la norme IEEE1394, - la figure 4 montre la structure connue d'un pont d'interconnexion selon la norme P1394.1, - la figure 5 montre la structure d'un pont d'interconnexion selon un mode de réalisation de l'invention, - la figure 6 est un organigramme représentant les étapes successives principales d'un procédé selon l'invention pour la suppression de paquets vides, - la figure 7 est un organigramme représentant les étapes successives principales d'un procédé selon l'invention pour la retransmission sur un bus filaire de paquets isochrones reçus par radio, et - la figure 8 est un organigramme représentant les étapes successives principales conduisant, au cours de l'exécution du procédé illustré sur la figure 7, à l'émission d'un paquet isochrone sur le bus filaire.

La figure 1 illustre de façon schématique une structure possible pour un réseau de communication mettant en oeuvre l'invention. Ce réseau comprend : - deux sous-réseaux, par exemple des bus série selon la norme IEEE1394a-2000, sur lesquels sont connectés un sous-système A pour l'un et un sous-système B pour l'autre, et - un troisième sous-réseau, par exemple un lien radio selon la norme IEEE802. 11b, sur lequel est connecté un sous-système C, chaque sous-réseau pouvant communiquer avec chaque autre sous-réseau par l'intermédiaire d'un pont selon l'invention.

L'invention s'applique aussi bien aux liens radio unidirectionnels qu'aux liens radio bidirectionnels.

<Desc/Clms Page number 11>

La figure 2 représente le format d'un paquet de données utilisé classiquement pour le mode de transmission isochrone. Le paquet isochrone est composé d'un bloc de données et d'un en-tête de paquet .

Ledit bloc de données comprend : - des données utiles (par exemple des données vidéo), - des données CRC (initiales des mots anglais Cyclic Redundancy Check ) correspondant à la Vérification par code Cyclique Redondant de l'intégrité des données utiles reçues, et - un en-tête CIP caractérisant l'application.

Les en-têtes CIP (initiales des mots anglais Common Isochronous Packet signifiant Paquet Isochrone Commun) sont utilisés pour encapsuler par exemple les données de type DV (initiales des mots anglais Digital Video signifiant Vidéo Numérique), et caractérisent le format de données.

Ledit en-tête de paquet comprend : - un champ data~length représentant la longueur du paquet isochrone, - un champ tag caractérisant le format de données, - un champ channel représentant le numéro du canal (selon la norme IEEE1394) dans lequel le paquet isochrone a été émis, - un champ tcode représentant le type de paquet IEEE1394, par exemple un paquet de données vidéo, - un champ sy utilisé pour la synchronisation des images vidéo, et - un en-tête CRC pour vérifier l'intégrité des données d'en-tête.

La figure 3 représente le format des cycles selon la norme IEEE1394.

Ces cycles ont tous une durée de 125 lis. Comme on l'a mentionné plus haut, chaque cycle commence par la transmission d'un paquet caractéristique de début de cycle ( cycle start en anglais). A la réception de ce paquet de début de cycle, chaque hôte connecté au bus IEEE1394, et qui aura préalablement réservé un des 63 canaux isochrones possibles, envoie un paquet isochrone dans le canal qui lui aura été préalablement attribué.

Une fois que chaque hôte a positionné un paquet dans les canaux préalablement réservés, le temps restant du cycle est consacré à la

<Desc/Clms Page number 12>

transmission des paquets asynchrones. La figure 3 illustre deux cycles successifs, le premier contenant un paquet de données asynchrone A, et le second un paquet de données asynchrone B. Enfin, on voit sur cette figure des paquets nommés ack : chaque fois qu'un paquet asynchrone est reçu par son destinataire, ce dernier émet un tel paquet ack à titre d'accusé de réception.

La figure 4 est un diagramme synoptique d'un pont d'interconnexion classique selon la norme P1394.1. Ce pont 1 est utilisé pour connecter un bus série filaire 2 à la norme IEEE1394, relié à un premier sous-système (non représenté), avec un autre bus série filaire 3 à la norme IEEE1394, relié à un deuxième sous-système (non représenté).

Le pont 1 comporte deux portails d'entrée/sortie 11 et 12. Chacun des portails 11 et 12 comprend des fonctionnalités de réception, de transmission et de gestion des paquets de données. Ces fonctionnalités sont réparties dans différentes couches fonctionnelles : couche physique PHY (111,121), couche de liaison LINK (112,122) et couche de transaction TR (113,123). Ces couches peuvent être constituées d'éléments matériels ( hardware ) et/ou logiciels ( software ). La couche physique représente les aspects électriques et mécaniques des connexions, ainsi que le processus effectif d'émission et de réception des signaux sur le bus. La couche de liaison représente les protocoles de distribution des paquets isochrones et asynchrones. Enfin, la couche de transaction représente certaines procédures nécessaires au transfert des paquets asynchrones, telles que la lecture, l'écriture, et le verrouillage ( read, write, and lock en anglais).

Chacun des portails 11 et 12 comporte une unité de contrôle de portail (114,124) rassemblant une série de registres de contrôle et d'état pour le portail considéré ainsi que pour les couches fonctionnelles précitées. Chacun des portails 11 et 12 est muni d'une mémoire de configuration (115,125) de type mémoire ROM (initiales de Read Only Memory , c'est-à-dire mémoire morte).

Les portails (11,12) sont conçus pour répondre à différents types de requêtes émises par les hôtes connectés aux bus fixés sur ces portails. Ces

<Desc/Clms Page number 13>

requêtes sont par exemple des requêtes de type isochrone (une trame de données par cycle de 125 lits), ou de type asynchrone (lecture, écriture, et verrouillage).

A cet effet, le pont 1 comprend une unité de transfert 13 ( switching fabric en anglais) associée à des files d'attente ( queues en anglais) (131,132) réalisées de préférence sous forme de mémoires FIFO (initiales des mots anglais first-in first-out signifiant premier-entré premier-sorti ). Dans les mémoires FIFO, les données sont lues dans l'ordre dans lequel elles ont été préalablement écrites ; le remplissage et le vidage de chaque zone mémoire peuvent alors s'effectuer en même temps, et de manière indépendante, ce qui permet de désynchroniser les opérations de lecture et d'écriture des données.

Les mémoires FIFO (131,132) servent à mettre en file d'attente des paquets de données de type asynchrone ou isochrone.

De plus, chaque portail (11, resp. 12) utilise une table de routage mémorisée dans l'unité de routage (116, resp. 126) pour déterminer les transactions qui doivent être transmises, au travers de l'unité de transfert 13, à l'autre portail du pont. L'unité de transfert 13 est ainsi capable de transférer n'importe quel paquet de données depuis un portail du pont 1 vers l'autre portail.

Le pont 1 comprend en outre une unité de synchronisation 14 servant à synchroniser une horloge contenue dans le portail 11 avec une horloge contenue dans le portail 12.

La figure 5 représente un pont d'interconnexion selon un mode de réalisation de l'invention. Ce pont d'interconnexion 7 est utilisé pour connecter un bus série filaire 2 conforme à la norme IEEE1394, relié à un premier sous-système (non représenté), avec un lien radio 4, relié à un deuxième sous-système (non représenté).

Le portail 71 du pont 7 est analogue au portail 11 du pont 1, et les éléments 711 à 716 notamment jouent un rôle analogue aux éléments respectifs 111 à 116.

<Desc/Clms Page number 14>

De même, l'unité de transfert 73 et ses mémoires FIFO (731,732) du pont 7 jouent un rôle analogue à l'unité de transfert 13 et ses mémoires FIFO (131,132) du pont 1.

Le portail 72, dans ce mode de réalisation de l'invention, comprend notamment : - une unité 721 de réception et de transmission de paquets, - une unité 722 servant à détecter d'éventuels paquets vides, - une unité 724 servant à supprimer au moins un paquet vide d'une communication provenant du bus filaire 2, - une unité 723 servant à gérer l'émission de paquets vides, soit vers le bus filaire 2, soit vers le lien radio 4, munie d'un générateur de paquets vides 729 et d'un compteur de périodicité 727, - une unité 725 servant à stocker des paquets de données en mémoire, munie d'un compteur de stockage 728, et - une unité 726 servant à détecter la fin des transmissions isochrones arrivant par le lien radio 4.

L'unité de réception et de transmission de paquets 721 et l'unité de stockage 725 traitent les paquets isochrones ou asynchrones (selon ce qui est transmis) de manière adéquate ; en particulier, le traitement des paquets asynchrones est conforme à la norme P1394. 1 et se fait de manière connue.

Selon l'invention, les paquets isochrones reçus par l'unité 721 en provenance du lien radio 4 sont transmis à l'unité de gestion 723, qui les met en mémoire dans l'unité de stockage 725, avant de gérer leur retransmission. Ce faisant, l'unité de gestion 723 contrôle que le portail 71 émette bien, dans le canal réservé à cette communication sur le bus filaire 2, un paquet isochrone par cycle ; en particulier, l'unité de gestion 723 fait appel au générateur 729 pour insérer des paquets vides, en fonction des besoins se manifestant au cours de cette retransmission et à l'aide du compteur de périodicité 727. On peut ainsi compenser une différence éventuelle de bande passante existant entre les sous-réseaux 2 et 4.

Selon un mode de réalisation particulièrement avantageux de l'invention, notamment en ce qui concerne la fiabilité des transmissions de type

<Desc/Clms Page number 15>

vidéo par exemple, on pourra ne retransmettre des paquets isochrones constituant une trame vidéo entière, qu'après avoir vérifié que le pont 7 a reçu tous les paquets de ladite trame vidéo. On vérifiera dans ce cas, à l'aide du compteur de stockage 728, que l'unité de stockage 725 a bien reçu un groupe complet de paquets, avant de retransmettre ce groupe sur le bus 2 (avec insertion de paquets vides selon les besoins). Si l'unité de stockage vient à contenir un groupe incomplet de paquets, le générateur 729 émet des paquets vides sur le bus 2 (à raison d'un par cycle de 125 lis) en attendant que la réception dudit groupe soit complète.

On trouvera ci-dessous, en référence aux figures 7 et 8, un exemple d'algorithme pour mettre en oeuvre cette fonctionnalité de l'unité de gestion 723.

Dans ce mode de réalisation de l'invention, l'unité de gestion 723 remplit une autre fonctionnalité : quand le pont 7 fonctionne comme émetteur d'une transmission radio isochrone sur le lien 4, et que cette transmission arrive à sa fin, l'unité de gestion 723 commande au générateur 729 la production d'une série de paquets vides en nombre prédéterminé, qui sont envoyés en succession sur le lien radio 4 via l'unité 721, afin de signaler la fin de la communication isochrone au pont recevant la transmission radio.

Quand le pont 7 fonctionne comme récepteur d'une communication isochrone transmise sur le lien radio 4, et que cette communication arrive à sa fin, l'unité d'achèvement 726 détecte la présence de cette série de paquets vides dans le flot de données entrant par le portail 72. Le pont 7 cesse alors de transmettre dans le canal réservé à cette communication sur le bus filaire 2.

Enfin, on notera que le pont 7 selon l'invention, contrairement au pont 1 reliant deux bus filaires, n'est pas équipé ici d'une unité de synchronisation : en effet, le portail 72 n'a pas à être muni d'une horloge dans la mesure où ce portail 72 est dédié à la connexion à un sous-système, tel que le sous-système radio 4, pour lequel un protocole de communication synchrone n'a pas nécessairement été prévu.

La figure 6 est un organigramme représentant les étapes successives principales d'un procédé selon l'invention pour la suppression de paquets vides qui ont été reçus par le pont 7 en provenance du bus filaire 2.

<Desc/Clms Page number 16>

A l'étape 200, l'unité de détection 722 reçoit un paquet isochrone en provenance de la mémoire FIFO 732.

A l'étape 210, !'unité de détection 722 lit, dans l'en-tête du paquet, le champ datajength , et détermine sa valeur à l'étape 220.

Si la valeur de data-length est nulle, à l'étape 230, !'unité de détection 722 transmet ce paquet à l'unité de suppression 724 aux fins d'effacement puisqu'il s'agit d'un paquet vide.

Si en revanche la valeur de data-length n'est pas nulle, à l'étape 240, l'unité de détection 722 transmet ce paquet à l'unité 721 aux fins de transmission sur le lien radio 4.

La figure 7 est un organigramme représentant les étapes successives principales d'un procédé selon l'invention pour la retransmission sur le bus filaire 2 de paquets isochrones reçus sur le lien radio 4. Ce procédé permet de définir le rythme de production de paquets vides, notamment en fonction du type d'application (par exemple, un format vidéo particulier) concernée par cette communication.

A l'étape 300, l'unité de réception et de transmission 721 identifie qu'un paquet reçu sur le lien radio 4 est un paquet isochrone. L'unité 721 transmet alors ce paquet à l'unité de gestion 723.

A l'étape 310, l'unité de gestion 723 détermine si ce paquet est le premier d'une communication, en lisant par exemple dans l'en-tête du paquet le numéro du canal utilisé lors de la transmission sur le lien filaire. Si ce numéro de canal n'était pas utilisé auparavant, l'unité de gestion 723 accomplit d'abord les étapes 320 et 330. Sinon, on passe directement à l'étape 340.

A l'étape 320, l'unité de gestion 723 lit l'en-tête CIP de ce paquet, qui, comme expliqué ci-dessus en référence à la figure 2, caractérise l'application concernée par les données contenues dans ce paquet. Par exemple, s'il s'agit de données vidéo, l'en-tête CIP en indique le format. S'il ne s'agit pas de données vidéo, ces paquets sont traités de manière conforme à la norme P1394.1.

A l'étape 330, l'unité de gestion 723 en déduit la fréquence de production de paquets vides requise pour adapter le débit de paquets reçu au

<Desc/Clms Page number 17>

débit retransmis (par exemple, de 7500 paquets par seconde à 8000 paquets par seconde) ; autrement dit, l'unité de gestion 723 calcule le nombre P de paquets utiles correspondant à chaque paquet vide produit (dans notre exemple, P = 15).

Comme expliqué ci-dessus, on peut optionnellement souhaiter ne transmettre les paquets utiles de la communication qu'après réception d'un groupe complet de G paquets. Par exemple, dans le cas d'une communication vidéo au format PAL, on pourra souhaiter ne retransmettre les paquets qu'après avoir reçu une image complète. Si l'on choisit cette option, l'unité de gestion 723 détermine la valeur adéquate de G (par exemple, G = 300) d'après les informations contenues dans l'en-tête CIP du premier paquet de la communication.

A l'étape 340, l'unité de gestion 723 transmet les paquets isochrones, au fur et à mesure de leur réception par l'unité 721, à l'unité de stockage 725, et gère la transmission de ces paquets à l'unité de transfert 73 selon l'algorithme décrit ci-dessous en référence à la figure 8.

Quand la communication arrive à sa fin, à l'étape 350, l'unité d'achèvement 726 détecte la présence d'une série de paquets vides en nombre prédéterminé dans les paquets reçus, et en informe l'unité de gestion 723 qui interrompt alors le processus de production de paquets vides et de comptage de paquets isochrones (notamment, le compteur 728 est remis à zéro).

La figure 8 est un organigramme représentant les étapes successives principales conduisant, au cours de l'exécution de l'étape 340 du procédé illustré sur la figure 7, à l'émission d'un paquet isochrone, utile ou vide, sur le bus filaire 2.

A l'étape 400, l'unité de gestion 723 reçoit un message de la part du portail 71 indiquant qu'un paquet isochrone doit être émis vers l'unité de transfert 73 (ce message est fourni suite à la réception d'un paquet de type début de cycle en provenance du lien 2). A l'étape 410, l'unité de gestion 723 lit la valeur indiquée par le compteur de stockage 728.

Si le compteur de stockage 728 affiche une valeur inférieure à G, c'est-à-dire si le pont 7 n'a pas reçu suffisamment de paquets isochrones du

<Desc/Clms Page number 18>

lien radio 4, l'unité de gestion 723 demande au générateur 729, à l'étape 420, de produire un paquet vide, et transmet ce paquet, à l'étape 470, à l'unité de transfert 73.

Si en revanche le compteur de stockage 728 affiche une valeur

supérieure ou égale à G, l'unité de gestion 723 vérifie, à l'étape 430, si le compteur de périodicité 727 a atteint la valeur P, c'est-à-dire s'il est temps d'émettre un paquet vide.

Si c'est le cas, l'unité de gestion 723 remet à zéro, à l'étape 440, le compteur de périodicité 727, et le procédé se poursuit avec les étapes 420 et 470 décrites précédemment.

Si en revanche le compteur de périodicité 727 n'a pas encore atteint la valeur P, c'est-à-dire s'il est temps d'émettre un paquet utile, l'unité de gestion 723 incrémente, à l'étape 450, le compteur de périodicité 727, sélectionne dans l'unité de stockage 725, à l'étape 460, le paquet isochrone situé en tête de file (c'est-à-dire, contenant le paquet utile le plus anciennement arrivé), et transmet ce paquet, à l'étape 470, à l'unité de transfert 73.

La présente invention ne se limite pas aux modes de réalisation décrits ci-dessus : en fait, l'homme de l'art pourra mettre en oeuvre diverses variantes de l'invention tout en restant à l'intérieur de la portée des revendications ci-jointes.

Par exemple, les données de service utilisées par l'invention pourront, en fonction des normes concernant la structure des paquets, se trouver dans l'appendice aussi bien que dans l'en-tête des paquets. Par ailleurs, les hôtes du réseau selon l'invention peuvent être des appareils aptes à émettre ou recevoir des données de nature autre que les données multimédias.

Claims (20)

REVENDICATIONS

1. Procédé de transfert de données dans un réseau de communication dans lequel les données utiles sont groupées en paquets, une communication étant formée d'un ensemble de paquets transmis entre des hôtes du réseau fonctionnant comme sources et/ou comme récepteurs de données, et reliés entre eux par l'intermédiaire d'un réseau comprenant au moins un premier sous-réseau (2) et un deuxième sous-réseau (4) interconnectés par un moyen d'interconnexion (7), la bande passante dudit premier sous-réseau (2) étant supérieure à la bande passante dudit deuxième sous-réseau (4), caractérisé en ce que, lorsqu'une communication du premier sous-réseau (2) vers le second sous-réseau (4) comprend sur le premier sousréseau (2) au moins un paquet vide, ledit moyen d'interconnexion (7) supprime ledit au moins un paquet vide.

2. Procédé selon la revendication 1, caractérisé en ce que ledit moyen d'interconnexion (7) insère un nombre prédéterminé de paquets vides dans ladite communication lorsque celle-ci se termine.

3. Procédé de transfert de données dans un réseau de communication dans lequel les données utiles sont groupées en paquets, une communication étant formée d'un ensemble de paquets transmis entre des hôtes du réseau fonctionnant comme sources et/ou comme récepteurs de données, et reliés entre eux par l'intermédiaire d'un réseau comprenant au moins un premier sous-réseau (2) et un deuxième sous-réseau (4) interconnectés par un moyen d'interconnexion (7), la bande passante dudit premier sous-réseau (2) étant supérieure à la bande passante dudit deuxième sous-réseau (4), caractérisé en ce que, lorsqu'une communication se dirige du deuxième sous-réseau (4) vers le premier sous-réseau (2), - on détermine le type de données transférées, et - ledit moyen d'interconnexion (7) insère au moins un paquet vide dans ladite communication si le type de données utiles correspond à au moins un type prédéterminé.

<Desc/Clms Page number 20>

4. Procédé selon la revendication 3, caractérisé en ce que ledit moyen d'interconnexion (7) insère un nombre prédéterminé de paquets vides qui dépend dudit type de données utiles.

5. Procédé de transfert de données selon la revendication 4, caractérisé en ce que lesdites données utiles sont des données isochrones.

6. Procédé selon la revendication 5, caractérisé en ce que l'on identifie ledit type de données utiles au moins en lisant dans les données de service d'un paquet faisant partie de ladite communication.

7. Procédé selon la revendication 3, caractérisé en ce que, lorsque ledit moyen d'interconnexion (7) détecte une suite d'un nombre prédéterminé de paquets vides dans ladite communication, le moyen d'interconnexion (7) arrête la communication.

8. Procédé de transfert de données selon l'une quelconque des revendications 1 à 7, caractérisé en ce que ledit premier sous-réseau (2) est un bus filaire obéissant à la norme IEEE1394.

9. Procédé de transfert de données selon l'une quelconque des revendications 1 à 7, caractérisé en ce que ledit second sous-réseau (4) est un sous-réseau radio obéissant à la norme IEEE802. 11 b.

10. Moyen d'interconnexion (7) destiné à interconnecter un premier sous-réseau (2) et un deuxième sous-réseau (4) faisant partie d'un réseau de communication dans lequel les données utiles sont groupées en paquets, une communication étant formée d'un ensemble de paquets transmis entre des hôtes du réseau fonctionnant comme sources et/ou comme récepteurs de données, et reliés entre eux par l'intermédiaire dudit réseau, la bande passante dudit premier sous-réseau (2) étant supérieure à la bande passante dudit deuxième sous-réseau (4), ledit moyen d'interconnexion (7) étant caractérisé en ce qu'il comprend - une unité de réception et de transmission de paquets (721), - une unité de détection (722) apte à détecter d'éventuels paquets vides, et

<Desc/Clms Page number 21>

- une unité de suppression (724) apte à supprimer au moins un paquet vide dans une communication du premier sous-réseau (2) vers le second sousréseau (4).

11. Moyen d'interconnexion selon la revendication 10, caractérisé en ce qu'il comprend également une unité de gestion (723) apte à gérer l'émission de paquets vides.

12. Moyen d'interconnexion (7) destiné à interconnecter un premier sous-réseau (2) et un deuxième sous-réseau (4) faisant partie d'un réseau de communication dans lequel les données utiles sont groupées en paquets, une communication étant formée d'un ensemble de paquets transmis entre des hôtes du réseau fonctionnant comme sources et/ou comme récepteurs de données, et reliés entre eux par l'intermédiaire dudit réseau, la bande passante dudit premier sous-réseau (2) étant supérieure à la bande passante dudit deuxième sous-réseau (4), ledit moyen d'interconnexion (7) étant caractérisé en ce qu'il comprend - une unité de réception et de transmission de paquets (721), - une unité de gestion (723) apte à gérer l'émission de paquets vides, et - une unité de stockage (725) apte à stocker des paquets de données en mémoire.

13. Moyen d'interconnexion selon la revendication 12, caractérisé en ce qu'il comprend également une unité d'achèvement (726) apte à détecter la succession d'un nombre prédéterminé de paquets vides en provenance dudit deuxième sous-réseau (4).

14. Moyen d'interconnexion selon l'une quelconque des revendications 10 à 13, caractérisé en ce que ledit premier sous-réseau (2) est un bus filaire obéissant à la norme IEEE1394.

15. Moyen d'interconnexion selon l'une quelconque des revendications 10 à 13, caractérisé en ce que ledit second lien (4) est un sousréseau radio obéissant à la norme IEEE802. 11 b.

16. Réseau de communication, caractérisé en ce qu'il comprend au moins un moyen d'interconnexion selon l'une des revendications 10 à 15.

<Desc/Clms Page number 22>

17. Réseau de communication selon la revendication 16, caractérisé en ce que lesdites données représentent des informations audiovisuelles.

18. Moyen de stockage permanent de données, caractérisé en ce qu'il comporte des instructions de code de programme informatique pour l'exécution des étapes d'un procédé selon l'une quelconque des revendications 1 à 9.

19. Moyen de stockage de données amovibles, partiellement ou totalement, caractérisé en ce qu'il comporte des instructions de code de programme informatique pour l'exécution des étapes d'un procédé selon l'une quelconque des revendications 1 à 9.

20. Programme d'ordinateur, caractérisé en ce qu'il contient des instructions telles que, lorsque ledit programme commande un dispositif de traitement de données programmable, lesdites instructions font que ledit dispositif de traitement de données met en oeuvre un procédé selon l'une quelconque des revendications 1 à 9.