FR 2936672 A1 20100402 FR 0856551 A 20080930 Procédé de transmission et de réception de données dans un réseau de communication synchrone, produit programme d'ordinateur, moyen de stockage et noeuds correspondants. 1. DOMAINE DE L'INVENTION Le domaine de l'invention est celui des systèmes de communications synchrones. Plus précisément, l'invention concerne la transmission de données asynchrones dans un système de communication synchrone (ou réseau de communication synchrone), tel que par exemple un système audio à n voies. 2. ART ANTÉRIEUR On se place dans la suite dans le cadre d'un système de communication synchrone sans-fil par exemple du type maillé comprenant une pluralité de noeuds. Un tel système de communication nécessite un partage de la bande passante utile entre les différents noeuds. L'ensemble de la bande passante disponible délivrée par le système est découpé en canaux virtuels synchrones. Les noeuds opèrent dans la bande d'onde millimétrique (c'est-à-dire autour de 60GHz). Pour permettre à chaque noeud du système de transmettre de l'information dans des intervalles de temps régulièrement espacés, on peut utiliser un medium (aussi appelé support de transmission) à accès multiplexé suivant un mode de multiplexage du type TDMA (pour � Time Division Multiple Access � en anglais, et � accès multiple à répartition dans le temps � en français). Selon le multiplexage TDMA, le domaine temporel est divisé en une pluralité de cycles de transmission de données synchrone (ou cycle � SDTC � pour � Synchronous Data Transmission Cycle � en anglais). Chaque cycle SDTC est divisé en une pluralité d'intervalles de temps. Dans un système de communication synchrone sans-fil utilisant un multiplexage TDMA, chaque noeud émet et reçoit dans des intervalles de temps déterminés (aussi appelés par la suite durées de temps de parole) et doit orienter son antenne en réception à chacun de ces intervalles de temps (ou � Time slot � en anglais). En plus de leurs données synchrones (aussi appelées données utiles), les noeuds du système doivent être capable de transmettre et recevoir pendant leurs temps de parole des données asynchrones (aussi appelées données de contrôle) permettant d'assurer le bon fonctionnement du système. Ainsi, chaque noeud du système met en oeuvre un protocole de contrôle pour transmettre et recevoir de telles données asynchrones. On connaît déjà plusieurs techniques de transport de données asynchrones sur des réseaux synchrones. D'une façon générale, on cherche notamment à concilier au moins certains des objectifs suivants : - réactivité du contrôle, le protocole de contrôle devant être très réactif (i.e contrôle temps réel), de façon à minimiser le temps des états transitoires du système. En effet, les systèmes de communication synchrones doivent pouvoir réagir très vite au changement de conditions afin d'être en mesure d'assurer leur communication suivant les critères qui leur sont propres comme, par exemple, le temps de transfert constant, un temps de parole disponible pour chaque noeud, la cohérence et la fiabilité des données ; - efficacité de gestion de la bande passante ; - simplicité de la couche physique du système de communication ; - simplicité et faible coût de la mise en oeuvre. Parmi les différentes techniques de transport connues, une première technique consiste à réserver, pour un noeud donné et pendant chacun de ses temps de parole, un canal virtuel (dit canal virtuel réservé) pour le transport de données de contrôle de type temps réel (� Event Data � en anglais) (appelées ci-après données de � status �). Cette première technique est notamment mise en oeuvre dans le cadre des systèmes de communications de type TTP. L'inconvénient majeur de cette première technique connue réside dans le fait qu'il n'est pas possible d'utiliser un canal virtuel réservé pour transporter autre chose que des paquets de données de � status �. Ainsi, la bande passante associée au canal virtuel réservé est perdue lorsqu'il n'y a pas de données de � status � à transmettre. Par ailleurs, cette première technique ne permet pas de transmettre un paquet de données de � status � de taille supérieure à celle du canal virtuel réservé. Il existe donc un risque élevé qu'un noeud transmette des données de � status � incomplètes. Les données de � status � non-transmises sont perdues. Une deuxième technique, notamment présentée dans le document de brevet US 7,333,512, prévoit d'insérer des paquets asynchrones (aussi appelés par la suite paquets de données de contrôle) dans les trames de la couche physique d'un système de communication synchrone tel que, par exemple, SONET (pour � Synchronous Optical Networking � en anglais). Cependant, cette deuxième technique connue présente certains inconvénients. Tout d'abord, lorsque les canaux d'une trame physique sont tous alloués (c'est-à-dire occupés par des données synchrones), il n'est plus possible d'envoyer des paquets de données de contrôle. Avec une telle technique, on peut également se retrouver dans une situation où il n'y a pas suffisamment de canaux libérés pour transmettre l'ensemble des données de contrôle. Ceci n'est donc pas compatible avec un système qui nécessite un protocole de contrôle très réactif. En outre, cette deuxième technique a pour inconvénient de mettre en oeuvre deux modes de transmissions distincts au niveau de la couche physique. La couche physique est donc complexe. Dans le document de brevet US 7,103,063, il est proposé une amélioration de la technique décrite dans le document US 7,333,512. En effet, cette troisième technique connue prévoit de segmenter les paquets de données de contrôle suivant un protocole du type HDLC (pour � High Level Data Link Control � en anglais). Le protocole HDLC permet l'interruption de l'envoi d'un paquet de basse priorité pour permettre l'envoi d'un paquet de haute priorité. Pour ce faire, le protocole HDLC met en oeuvre trois symboles distincts, un symbole de début de paquet permettant d'identifier le type de paquet (paquet de basse priorité ou de haute priorité), un symbole d'interruption permettant d'interrompre l'envoi d'un paquet de basse priorité, et un symbole de fin d'interruption. Ainsi, contrairement à la technique décrite dans le document US 7,333,512, cette troisième technique permet d'avoir un protocole de contrôle plus réactif. Cependant, cette troisième technique connue a également pour inconvénient de mettre en oeuvre deux modes de transmissions distincts au niveau de la couche physique. La couche physique est donc complexe. Par ailleurs, cette troisième technique présente l'inconvénient majeur d'utiliser un grand nombre de symboles pour interrompre l'envoi d'un paquet. Ceci se traduit, coté émetteur et coté récepteur, par des temps de traitements plus longs. 3. OBJECTIFS DE L'INVENTION L'invention, dans au moins un mode de réalisation, a notamment pour objectif de pallier ces différents inconvénients de l'état de la technique. Plus précisément, dans au moins un mode de réalisation de l'invention, un objectif est de fournir une technique de transmission de données asynchrones qui permette de transmettre des paquets de données de tailles variables dans un réseau de communication synchrone. En effet, l'invention vise notamment à fournir un protocole de transmission de données asynchrones très réactif. Un autre objectif de l'invention, dans au moins un de ses modes de réalisation, est de mettre en oeuvre une telle technique qui permette d'utiliser un canal virtuel réservé pour transporter différents types de paquets de données asynchrones. Un autre objectif de l'invention, dans au moins un de ses modes de réalisation, est de mettre en oeuvre une telle technique qui permette une meilleure gestion de la bande passante. Un autre objectif de l'invention, dans au moins un de ses modes de réalisation, est de mettre en oeuvre une telle technique qui permette d'interrompre l'émission/réception d'un paquet de données non-prioritaire en cours d'émission /réception sur le canal virtuel réservé, au moyen d'un nombre réduit de symboles. Au moins un mode de réalisation de l'invention a également pour objectif de fournir une telle technique qui ne nécessite aucune modification lourde et complexe de la couche physique du réseau de communication Un autre objectif de l'invention, dans au moins un de ses modes de réalisation, est de mettre en oeuvre une telle technique qui permette d'utiliser un canal virtuel, distinct du canal virtuel réservé, pour transporter des paquets de données asynchrones prioritaires, lorsque le canal virtuel réservé transporte déjà d'autres données asynchrones prioritaires. L'invention, dans au moins un de ses modes de réalisation, a encore pour objectif de fournir une telle technique qui soit simple à mettre en oeuvre et pour un faible coût. 4. EXPOSÉ DE L'INVENTION Dans un mode de réalisation particulier de l'invention, il est proposé un procédé de transmission de données par un noeud émetteur vers au moins un noeud récepteur, dans un réseau de communication synchrone comprenant une pluralité de noeuds, ledit réseau mettant en oeuvre un cadencement qui définit un cycle réseau pour la transmission de données sur ledit réseau, le cycle réseau comprenant une pluralité de premiers canaux virtuels permettant la transmission de données synchrones et au moins un second canal virtuel permettant la transmission d'un premier type de paquets de données asynchrones. Selon l'invention, le procédé est effectué par le noeud émetteur. Le procédé comprend les étapes suivantes : - première détection, permettant de détecter une requête de transmission d'un second type de paquet de données asynchrones sur ledit second canal virtuel ; - deuxième détection, permettant de détecter une transmission en cours d'un premier type de paquet de données asynchrones sur ledit second canal virtuel ; - en cas de deuxième détection positive, construction d'un symbole de début de paquet asynchrone, comprenant un identifiant de symbole et un champ utile contenant un en-tête dudit second type de paquet de données asynchrones et au moins une partie d'un ensemble de données utiles asynchrones dudit second type de paquet de données asynchrones ; - interruption de la transmission dudit premier type de paquet de données asynchrones par insertion dudit symbole de début de paquet asynchrone dans ledit second canal virtuel ; - transmission dudit symbole de début de paquet asynchrone sur ledit second canal virtuel. L'invention propose donc de mettre en oeuvre un canal virtuel réservé pour le transport de deux types de paquets de données asynchrones. Ainsi, l'invention permet une meilleure gestion de la bande passante du réseau. L'invention prévoit avantageusement un mécanisme de gestion de priorité. En effet, le canal virtuel réservé permet de transporter des paquets prioritaires (dits second type de paquets de données asynchrones ou paquets de second type) et des paquets non- prioritaires (dits premier type de paquets de données asynchrones ou paquets de premier type). Ainsi, dans le cas où un paquet non-prioritaire est en cours de transmission sur le canal virtuel réservé et lorsque le noeud émetteur veut transmettre un paquet prioritaire, le noeud émetteur suspend la transmission du paquet non-prioritaire et commence l'envoi du paquet prioritaire. Ainsi, l'invention permet d'avoir un protocole de transmission de données asynchrones très réactif. L'invention propose en outre de mettre en oeuvre un nouveau symbole (appelé symbole de début de paquet asynchrone) qui peut être utilisé aussi bien dans le � monde asynchrone � que dans le � monde synchrone �. Selon un premier mode de réalisation particulier de l'invention, le procédé comprend les étapes suivantes : - lecture, dans l'en-tête de la taille dudit second type de paquet de données asynchrones ; - si la taille dudit second type de paquet de données asynchrones est supérieure à la taille du champ utile dudit symbole de début de paquet asynchrone, segmentation dudit second type de paquet de données asynchrones en une séquence de segments comprenant : un premier segment ayant une taille inférieure ou égale à la taille du champ utile dudit symbole de début de paquet asynchrone, et au moins un second segment ayant une taille inférieure ou égale à la taille d'un champ utile d'un conteneur de données asynchrones ; Selon l'invention, l'étape de construction dudit symbole de début de paquet asynchrone comprend une étape d'insertion du premier segment de ladite séquence dans le champ utile dudit symbole de début de paquet asynchrone. Le procédé comprend en outre une étape de construction d'au moins un conteneur de données asynchrones, chaque conteneur de données asynchrones comprenant un identifiant de conteneur de données et un champ utile contenant un second segment de ladite séquence. Selon un mode de réalisation particulier de l'invention, l'étape de transmission dudit symbole de début de paquet asynchrone sur ledit second canal virtuel, est effectuée pendant un premier cycle réseau. Le procédé comprend également une étape de transmission dudit au moins un conteneur de données asynchrones sur ledit second canal virtuel, chaque conteneur de données asynchrones étant transmis pendant un cycle réseau postérieur audit premier cycle réseau. Ainsi, grâce à cette segmentation le noeud émetteur peut transmettre sur le canal virtuel réservé un paquet de second type de n'importe quelle taille. En effet, si la taille du paquet de second type est supérieure à la taille du champ de données utiles du symbole de début de paquet asynchrone, le noeud émetteur segmente le paquet de second type en une pluralité de segments transportables sur le canal virtuel réservé. Ainsi, si la taille du paquet de second type est supérieure à la taille du champ de données utiles du symbole de début de paquet asynchrone, le noeud émetteur segmente le paquet de second type en une pluralité de segments qui sont ensuite transmis les uns après les autres (c'est-à-dire pendant des cycles réseau successifs) sur le canal virtuel réservé. Ainsi, il n'y a aucune perte de données d'un paquet de second type. Avantageusement, le noeud émetteur effectue une étape de reprise de la transmission, sur ledit second canal virtuel, dudit premier type de paquet de données asynchrones interrompu, après que le second type de paquet de données asynchrones a été entièrement transmis sur ledit second canal virtuel. Ainsi, il n'y a aucune perte de données d'un paquet de premier type (aussi appelé par la suite premier type de paquet de données asynchrones). De façon avantageuse, le procédé comprend les étapes suivantes : - troisième détection, permettant de détecter une transmission en cours d'un autre second type de paquet de données asynchrones sur ledit second canal virtuel, ledit autre second type de paquet de données asynchrones étant distinct du second type de paquet de données asynchrones faisant l'objet de ladite requête de transmission ; - en cas de troisième détection positive, sélection d'un canal virtuel parmi ladite pluralité de premiers canaux virtuels ; - construction d'un symbole de début de paquet asynchrone, comprenant un identifiant de symbole et un champ utile contenant l'en-tête et au moins une partie de l'ensemble de données utiles asynchrones dudit second type de paquet de données asynchrones ; - interruption de la transmission de données synchrones sur le canal virtuel sélectionné par insertion dudit symbole de début de paquet asynchrone dans ledit canal sélectionné ; - transmission dudit symbole de début de paquet asynchrone sur ledit canal sélectionné. Ainsi, dans le cas où un paquet prioritaire est déjà en cours de transmission sur le canal virtuel réservé et lorsque le noeud émetteur veut transmettre un autre paquet prioritaire, le noeud émetteur n'interromps en aucun cas le paquet prioritaire en cours de transmission sur le canal virtuel réservé, mais sélectionne un canal virtuel (dit canal virtuel sélectionné) qui est normalement utilisé pour le transport de données synchrones, puis purge les données synchrones en cours de transmission sur ce canal virtuel sélectionné, et enfin commence l'envoi de l'autre paquet prioritaire sur ce canal virtuel sélectionné. Ainsi, l'invention permet d'avoir un protocole de transmission de données asynchrones très réactif. L'invention concerne aussi un procédé de réception de données par un noeud récepteur, dans un réseau de communication synchrone comprenant une pluralité de noeuds, ledit réseau mettant en oeuvre un cadencement qui définit un cycle réseau pour la transmission de données sur ledit réseau, le cycle réseau comprenant une pluralité de premiers canaux virtuels permettant la transmission de données synchrones et au moins un second canal virtuel permettant la transmission d'un premier type de paquets de données asynchrones. Selon l'invention, le procédé est effectué par le noeud récepteur. Le procédé comprend les étapes suivantes : - réception d'un symbole de début de paquet asynchrone, comprenant un identifiant de symbole et un champ utile contenant un en-tête d'un second type de paquet de données asynchrones et au moins une partie d'un ensemble de données utiles asynchrones dudit second type de paquet de données asynchrones, ledit symbole de début de paquet asynchrone étant transmis par un noeud émetteur sur ledit second canal virtuel ; - sur réception dudit symbole de début de paquet asynchrone, première détection, permettant de détecter une réception en cours d'un premier type de paquet de données asynchrones sur ledit second canal virtuel ; - en cas de première détection positive, interruption de la réception dudit premier type de paquet de données asynchrones ; - extraction, dudit symbole de début de paquet asynchrone, de l'en-tête et de ladite au moins une partie d'un ensemble de données utiles asynchrones dudit second type de paquet de données asynchrones. L'invention permet avantageusement d'utiliser le symbole de début de paquet asynchrone comme un symbole d'interruption. Contrairement, aux techniques connues décrites ci-dessus, le mécanisme de gestion d'interruption de paquet de l'invention ne nécessite pas l'utilisation d'un symbole de début d'interruption et d'un symbole de fin d'interruption. Ainsi on gère moins de symboles, ce qui se traduit par une simplification des traitements. Selon un premier mode de réalisation particulier de l'invention, le procédé comprend les étapes suivantes : - lecture, dans l'en-tête, de la taille dudit second type de paquet de données asynchrones ; - si la taille dudit second type de paquet de données asynchrones est supérieure à la taille du champ utile dudit symbole de début de paquet asynchrone : - réception dudit symbole de début de paquet asynchrone sur ledit second canal virtuel, pendant un premier cycle réseau, ledit symbole de début de paquet asynchrone comprenant, dans le champ utile dudit symbole, un premier segment d'une séquence de segments, issue de la segmentation dudit second type de paquet de données asynchrones, ledit premier segment ayant une taille inférieure ou égale à la taille du champ utile dudit symbole de début de paquet asynchrone ; - extraction, dudit symbole de début de paquet asynchrone, dudit premier segment ; - réception d'au moins un conteneur de données asynchrones sur ledit 25 30 second canal virtuel, pendant un cycle réseau postérieur audit premier cycle réseau, chaque conteneur de données asynchrones comprenant un identifiant de conteneur de données et un champ utile contenant un second segment de ladite séquence, ledit second segment ayant une taille inférieure ou égale à la taille du champ utile dudit conteneur de données asynchrones; - extraction, de chaque conteneur de données asynchrones, dudit second segment ; - reconstruction dudit second type de paquet de données asynchrones, par concaténation des premier et second(s) segments extraits. De façon avantageuse, le noeud récepteur effectue une étape de reprise de la réception, sur ledit second canal virtuel, dudit premier type de paquet de données asynchrones interrompu, après que le second type de paquet de données asynchrones a été entièrement reçu sur ledit second canal virtuel. Selon un aspect avantageux de l'invention, le procédé comprend les étapes suivantes : - deuxième détection, permettant de détecter une réception en cours d'un autre second type de paquet de données asynchrones sur ledit second canal virtuel, ledit autre second type de paquet de données asynchrones étant distinct du 20 second type de paquet de données asynchrones dont l'en-tête est compris dans le champ utile du symbole de début de paquet asynchrone reçu ; - en cas de deuxième détection positive, détermination d'un canal virtuel sélectionné, par ledit noeud émetteur, parmi ladite pluralité de canaux non réservés ; 25 - interruption de la réception de données synchrones sur le canal virtuel déterminé ; - réception d'un symbole de début de paquet asynchrone sur ledit canal virtuel déterminé, ledit symbole de début de paquet asynchrone, comprenant un identifiant de symbole et un champ utile contenant l'en-tête et au moins une 30 partie de l'ensemble de données utiles asynchrones dudit second type de paquet 10 15 de données asynchrones. Selon un second mode de réalisation particulier, le procédé comprend les étapes suivantes : - lecture, dans l'en-tête, de la taille dudit second type de paquet de données asynchrones ; - si la taille dudit second type de paquet de données asynchrones est supérieure à la taille du champ utile dudit symbole de début de paquet asynchrone : - réception dudit symbole de début de paquet asynchrone sur ledit canal déterminé, pendant un premier cycle réseau, ledit symbole de début de paquet asynchrone comprenant, dans le champ utile dudit symbole, un premier segment d'une séquence de segments, issue de la segmentation dudit second type de paquet de données asynchrones, ledit premier segment ayant une taille inférieure ou égale à la taille du champ utile dudit symbole de début de paquet asynchrone ; - extraction, dudit symbole de début de paquet asynchrone, dudit premier segment ; - réception d'au moins un conteneur de données asynchrones sur ledit canal déterminé, pendant un cycle réseau postérieur audit premier cycle réseau, chaque conteneur de données asynchrones comprenant un identifiant de conteneur de données et un champ utile contenant un second segment de ladite séquence, ledit second segment ayant une taille inférieure ou égale à la taille du champ utile dudit conteneur de données asynchrones; - extraction, de chaque conteneur de données asynchrones, dudit second segment ; - reconstruction dudit second type de paquet de données asynchrones, par concaténation des premier et second(s) segments extraits. L'invention concerne également un produit programme d'ordinateur, téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur comprenant des instructions de code de programme pour la mise en oeuvre du procédé de transmission tel que précédemment décrit et/ou du procédé de réception tel que précédemment décrit. L'invention concerne également un moyen de stockage, éventuellement totalement ou partiellement amovible, lisible par un ordinateur, stockant un jeu d'instructions exécutables par ledit ordinateur pour mettre en oeuvre le procédé de transmission tel que précédemment décrit et/ou le procédé de réception tel que précédemment décrit. Dans un autre mode de réalisation, l'invention concerne un noeud émetteur comprenant des moyens de transmission de données vers au moins un noeud récepteur dans un réseau de communication synchrone, ledit réseau comprenant une pluralité de noeuds et mettant en oeuvre un cadencement qui définit un cycle réseau pour la transmission de données sur ledit réseau, le cycle réseau comprenant une pluralité de premiers canaux virtuels permettant la transmission de données synchrones et au moins un second canal virtuel permettant la transmission d'un premier type de paquets de données asynchrones. Selon l'invention, le noeud émetteur comprend : - des premiers moyens de détection permettant de détecter une requête de transmission d'un second type de paquet de données asynchrones sur ledit second canal virtuel ; - des deuxièmes moyens de détection permettant de détecter une transmission en cours d'un premier type de paquet de données asynchrones sur ledit second canal virtuel ; - des moyens de construction d'un symbole de début de paquet asynchrone, ledit symbole de début de paquet asynchrone comprenant un identifiant de symbole et un champ utile contenant un en-tête dudit second type de paquet de données asynchrones et au moins une partie d'un ensemble de données utiles asynchrones dudit second type de paquet de données asynchrones ; - des moyens d'interruption de la transmission dudit premier type de paquet de données asynchrones par insertion dudit symbole de début de paquet asynchrone dans ledit second canal virtuel ; - des moyens de transmission dudit symbole de début de paquet asynchrone sur ledit second canal virtuel. De façon avantageuse, le noeud émetteur comprend : - des moyens de lecture, dans l'en-tête, de la taille dudit second type de paquet de données asynchrones ; - des moyens de segmentation dudit second type de paquet de données asynchrones en une séquence de segments comprenant : un premier segment ayant une taille inférieure ou égale à la taille du champ utile dudit symbole de début de paquet asynchrone, et au moins un second segment ayant une taille inférieure ou égale à la taille d'un champ utile d'un conteneur de données asynchrones ; Selon l'invention, lesdits moyens de construction dudit symbole de début de paquet asynchrone comprennent des moyens d'insertion du premier segment de ladite séquence dans le champ utile dudit symbole de début de paquet asynchrone. Le noeud émetteur comprend en outre des moyens de construction d'au moins un conteneur de données asynchrones, chaque conteneur de données asynchrones comprenant un identifiant de conteneur de données et un champ utile contenant un second segment de ladite séquence. Les moyens de transmission transmettent ledit symbole de début de paquet asynchrone sur ledit second canal virtuel, pendant un premier cycle réseau. Le noeud émetteur comprend des moyens de transmission dudit au moins un conteneur de données asynchrones sur ledit second canal virtuel, chaque conteneur de données asynchrones étant transmis pendant un cycle réseau postérieur audit premier cycle réseau. Avantageusement, le noeud émetteur comprend des moyens de reprise permettant la reprise de la transmission, sur ledit second canal virtuel, dudit premier type de paquet de données asynchrones interrompu, après que le second type de paquet de données asynchrones a été entièrement transmis sur ledit second canal virtuel De façon avantageuse, le noeud émetteur comprend : - des troisièmes moyens de détection permettant de détecter une transmission en cours d'un autre second type de paquet de données asynchrones sur ledit second canal virtuel, ledit autre second type de paquet de données asynchrones étant distinct du second type de paquet de données asynchrones faisant l'objet de ladite requête de transmission ; - des moyens de sélection d'un canal virtuel parmi ladite pluralité de premiers canaux virtuels ; - des moyens de construction d'un symbole de début de paquet asynchrone, comprenant un identifiant de symbole et un champ utile contenant l'en-tête et au moins une partie de l'ensemble de données utiles asynchrones dudit second type de paquet de données asynchrones ; - des moyens d'interruption de la transmission de données synchrones sur le canal virtuel sélectionné par insertion dudit symbole de début de paquet asynchrone dans ledit canal sélectionné ; - des moyens de transmission dudit symbole de début de paquet asynchrone sur ledit canal sélectionné. Dans un autre mode de réalisation, l'invention concerne un noeud récepteur comprenant des moyens de réception de données dans un réseau de communication synchrone, ledit réseau comprenant une pluralité de noeuds et mettant en oeuvre un cadencement qui définit un cycle réseau pour la transmission de données sur ledit réseau, le cycle réseau comprenant une pluralité de premiers canaux virtuels permettant la transmission de données synchrones et au moins un second canal virtuel permettant la transmission d'un premier type de paquets de données asynchrones. Selon l'invention, le noeud récepteur comprend : - des moyens de réception d'un symbole de début de paquet asynchrone, ledit symbole de début de paquet asynchrone comprenant un identifiant de symbole et un champ utile contenant un en-tête d'un second type de paquet de données asynchrones et au moins une partie d'un ensemble de données utiles asynchrones dudit second type de paquet de données asynchrones, ledit symbole de début de paquet asynchrone étant transmis par un noeud émetteur sur ledit second canal virtuel ; - des premiers moyens de détection permettant de détecter une réception en cours d'un premier type de paquet de données asynchrones sur ledit second canal virtuel ; - des moyens d'interruption de la réception dudit premier type de paquet de données asynchrones; - des moyens d'extraction permettant d'extraire, dudit symbole de début de paquet asynchrone, l'en-tête et ladite au moins une partie d'un ensemble de données utiles asynchrones dudit second type de paquet de données asynchrones. Avantageusement, le noeud récepteur comprend : - des moyens de lecture, dans l'en-tête, de la taille dudit second type de paquet de données asynchrones ; - des moyens de réception permettant de recevoir ledit symbole de début de paquet asynchrone sur ledit second canal virtuel, pendant un premier cycle réseau, ledit symbole de début de paquet asynchrone comprenant, dans le champ utile dudit symbole, un premier segment d'une séquence de segments, issue de la segmentation dudit second type de paquet de données asynchrones, ledit premier segment ayant une taille inférieure ou égale à la taille du champ utile dudit symbole de début de paquet asynchrone ; - des moyens d'extraction permettant d'extraire, dudit symbole de début de paquet asynchrone, ledit premier segment ; - des moyens de réception permettant de recevoir au moins un conteneur de données asynchrones sur ledit second canal virtuel, pendant un cycle réseau postérieur audit premier cycle réseau, chaque conteneur de données asynchrones comprenant un identifiant de conteneur de données et un champ utile contenant un second segment de ladite séquence, ledit second segment ayant une taille inférieure ou égale à la taille du champ utile dudit conteneur de données asynchrones; - des moyens d'extraction permettant d'extraire, de chaque conteneur de données asynchrones, ledit second segment ; - des moyens de reconstruction dudit second type de paquet de données asynchrones, par concaténation des premier et second(s) segments extraits. De façon avantageuse, le noeud récepteur comprend des moyens de reprise permettant la reprise de la réception, sur ledit second canal virtuel, dudit premier type de paquet de données asynchrones interrompu, après que le second type de paquet de données asynchrones a été entièrement reçu sur ledit second canal virtuel. Avantageusement, le noeud récepteur comprend : - des deuxièmes moyens de détection permettant de détecter une réception en cours d'un autre second type de paquet de données asynchrones sur ledit second canal virtuel, ledit autre second type de paquet de données asynchrones étant distinct du second type de paquet de données asynchrones dont l'en-tête est compris dans le champ utile du symbole de début de paquet asynchrone reçu ; - des moyens de détermination d'un canal virtuel sélectionné, par ledit noeud émetteur, parmi ladite pluralité de premiers canaux virtuels ; - des moyens d'interruption de la réception de données synchrones sur le canal virtuel déterminé ; - des moyens de réception permettant de recevoir un symbole de début de paquet asynchrone sur ledit canal virtuel déterminé, ledit symbole de début de paquet asynchrone, comprenant un identifiant de symbole et un champ utile contenant l'en-tête et au moins une partie de l'ensemble de données utiles asynchrones dudit second type de paquet de données asynchrones. Selon un mode de réalisation avantageux, le noeud récepteur comprend : - des moyens de lecture, dans l'en-tête, de la taille dudit second type de paquet de données asynchrones ; - des moyens de réception permettant de recevoir ledit symbole de début de paquet asynchrone sur ledit canal déterminé, pendant un premier cycle réseau, ledit symbole de début de paquet asynchrone comprenant, dans le champ utile dudit symbole, un premier segment d'une séquence de segments, issue de la segmentation dudit second type de paquet de données asynchrones, ledit premier segment ayant une taille inférieure ou égale à la taille du champ utile dudit symbole de début de paquet asynchrone ; - des moyens d'extraction permettant d'extraire, dudit symbole de début de paquet asynchrone, ledit premier segment ; - des moyens de réception permettant de recevoir au moins un conteneur de données asynchrones sur ledit canal déterminé, pendant un cycle réseau postérieur audit premier cycle réseau, chaque conteneur de données asynchrones comprenant un identifiant de conteneur de données et un champ utile contenant un second segment de ladite séquence, ledit second segment ayant une taille inférieure ou égale à la taille du champ utile dudit conteneur de données asynchrones ; - des moyens d'extraction permettant d'extraire, de chaque conteneur de données asynchrones, ledit second segment ; - des moyens de reconstruction dudit second type de paquet de données asynchrones, par concaténation des premier et second(s) segments extraits. 5. LISTE DES FIGURES D'autres caractéristiques et avantages de modes de réalisation de l'invention apparaîtront à la lecture de la description suivante, donnée à titre d'exemple indicatif et non limitatif (tous les modes de réalisation de l'invention ne sont pas limités aux caractéristiques et avantages des modes de réalisation décrits ci-après), et des dessins annexés, dans lesquels : - la figure 1 présente un exemple de système de communication radio à 60 GHz selon un mode de réalisation préférentiel de l'invention ; - la figure 2 présente un exemple d'architecture du module de communication synchrone apparaissant sur la figure 1, selon un mode de réalisation particulier de l'invention ; - la figure 3 présente un exemple de structure d'un canal virtuel, selon un mode de réalisation particulier de l'invention ; - la figure 4 présente un exemple de structure d'un paquet de données de contrôle, selon un mode de réalisation particulier de l'invention ; - la figure 5 présente les étapes principales d'un algorithme de traitement mis en oeuvre par le gestionnaire de bus TDM, compris dans un noeud et apparaissant sur la figure 2, selon un mode de réalisation particulier de l'invention ; - la figure 6a présente les sous-étapes de l'étape de sélection d'une FIFO de transmission, apparaissant sur la figure 5, selon un mode de réalisation particulier de l'invention, et dans le cas où on transmet un canal virtuel comprenant des données synchrones ; - la figure 6b présente les sous-étapes de l'étape de sélection d'une FIFO de transmission, apparaissant sur la figure 5, selon un mode de réalisation particulier de l'invention, et dans le cas où on transmet un canal virtuel comprenant des données asynchrones ; - la figure 7a présente les sous-étapes de l'étape de sélection d'une FIFO de réception, apparaissant sur la figure 5, selon un mode de réalisation particulier de l'invention, et dans le cas où on reçoit un canal virtuel comprenant des données synchrones; - les figures 7b et 7c les sous-étapes de l'étape de sélection d'une FIFO de réception, apparaissant sur la figure 5, selon un mode de réalisation particulier de l'invention, et dans le cas où on reçoit un canal virtuel comprenant des données asynchrones ; - la figure 8a présente les étapes principales d'un algorithme de traitement mis en oeuvre par le bloc d'insertion de symboles, compris dans un noeud et apparaissant sur la figure 2, selon un mode de réalisation particulier de l'invention ; - la figure 8b présente les étapes principales d'un algorithme de traitement mis en oeuvre par le bloc d'analyse de symboles, compris dans un noeud et apparaissant sur la figure 2, selon un mode de réalisation particulier de l'invention ; et la figure 9 présente un exemple d'architecture du registre TDM_MAP de répartition TDM selon le mode de réalisation particulier de l'invention. 6. DESCRIPTION DÉTAILLÉE Sur toutes les figures du présent document, les éléments et étapes identiques sont 30 désignés par une même référence numérique. 10 15 20 25 6.1 Exemple de système de communication radio à 60 GHz (système audio 8 voies) On décrit, en relation avec la figure 1, un exemple de système de communication radio à 60 GHz selon un mode de réalisation préférentiel de l'invention. Dans ce mode de réalisation, le système de communication 2000 selon l'invention comprend neuf noeuds de communication. Plus précisément, le système de communication 2000 comprend huit noeuds la, 2a, 3a, 4a, 6a, 7a, 8a, et 9a de type � WAR � (pour � Wireless Audio Renderer � en anglais ou � récepteur audio sans fil � en français) comprenant chacun des moyens de restitution de canal audio numérique (ou � Digital Audio Channel Amplifier � en anglais) lb, 2b, 3b, 4b, 6b, 7b, 8b, et 9b. Ces moyens de restitution comprennent, par exemple, un haut-parleur (ou � speaker � en anglais). Le système de communication 2000 comprend en outre un noeud 5a de type � WAD � (pour � Wireless Audio Decoder � en anglais ou � décodeur audio sans fil � en français) comprenant lui-même un décodeur audio multi voies (ou � Surround sound decoder � en anglais) 5b. Ce décodeur audio multi voies 5b est intégré, par exemple, dans un écran plat et est susceptible de transmettre de manière synchronisée, via le système de communication 2000, les différents canaux audio associés à la vidéo affichée sur l'écran. Chacun des noeuds la, 2a, 3a, 4a, 5a, 6a, 7a, 8a, et 9a comprend un module de communication synchrone, noté � SCM � (pour � Synchronous Communication Module � en anglais). 6.2 Principe général du système On rappelle que l'ensemble de la bande passante disponible délivrée par le système est découpé en canaux virtuels synchrones. Le débit utile est caractérisé par la fréquence de traitement des canaux virtuels (par exemple 8KHz) ainsi que par la taille des échantillons (par exemple 48 bits). Dans le présent exemple, un canal virtuel (� VC � pour � Virtual Channel � en anglais) a un débit constant de 384 Kbps (kilobits par seconde). La séquence complète, qui comprend un échantillon de chacun des canaux virtuels disponibles, constitue un cycle complet de traitement de données synchrone (appelé cycle SDPC). Dans le présent exemple, où la fréquence de traitement des canaux virtuels est de 8KHz, la durée d'un cycle SDPC est de 125�s. Un canal audio de résolution 96KHz-24bits utilisera donc 6 canaux virtuels soit, par exemple pour un système audio 8 voies (classiquement appelé 7.1), un total de 48 canaux virtuels. Le débit utile nécessaire pour le transfert de l'information audio est donc de 18,432 Mbps (mégabit par seconde). Si l'on ajoute 9 canaux virtuels supplémentaires (alloués à l'ensemble des noeuds de transmission du système) pour le transfert d'informations supplémentaires (contrôle du système, protocole, commande utilisateur,...), alors le cycle SDPC comprend 57 canaux virtuels, soit un débit utile de 21,888 Mbps. Dans la suite de la description, on suppose que les informations supplémentaires sont, par exemple, des informations de protocole de contrôle. Les canaux virtuels VC48 à VC56 sont utilisés par les noeuds du système de communication 2000 pour échanger des données de protocole de contrôle. Ainsi, au moins un canal virtuel dédié à l'émission de ces données de protocole de contrôle à destination des autres noeuds du système de communication 2000 (appelés noeuds récepteur) est alloué à chaque noeud (WAR ou WAD) (appelé noeud émetteur) du système de communication 2000. On alloue par exemple : le canal virtuel VC48 au noeud WAD 5a ; le canal virtuel VC49 au noeud WAR 9a ; le canal virtuel VC50 au noeud WAR 4a ; le canal virtuel VC51 au noeud WAR 7a ; le canal virtuel VC52 au noeud WAR 3a ; le canal virtuel VC53 au noeud WAR 8a ; le canal virtuel VC54 au noeud WAR 2a ; le canal virtuel VC55 au noeud WAR la ; et le canal virtuel VC56 au noeud WAR 6a. A chaque cycle SDPC, le module de communication synchrone SCM de chaque noeud récepteur collecte des données écrites par le noeud émetteur sur les canaux virtuels qui lui sont alloués. Si le noeud émetteur n'a pas écrit de données sur un canal virtuel donné, alors le module de communication synchrone SCM du noeud récepteur écrit sur ce canal virtuel donné un symbole de silence (décrit en détail ci-après en relation avec la figure 3). Du fait que le système de communication est du type synchrone, l'acheminement des données est effectué en temps constant (� SL � pour � Synchronous Latency � en anglais). Ce temps constant comprend une étape de réception des données envoyées par chaque noeud du réseau, puis la présentation des canaux virtuels reconstitués au niveau de chaque noeud du réseau sur les canaux virtuels ouverts en lecture (ou alloué aux noeuds distants). On note qu'il existe des risques de pertes de données dans un système de communication synchrone sans fil (c'est-à-dire un système de communication synchrone doté d'un mode de transport non fiable). La contrainte de latence fixe interdit l'utilisation de tout type de mécanisme de retransmission (en effet, la mise en oeuvre d'un tel mécanisme rendrait la latence variable). Ainsi toute donnée non reçu à temps est perdue. 6.3 Types de paquets de données transportés sur les canaux virtuels Chaque noeud du système de communication 2000 met en oeuvre un protocole de communication asynchrone permettant d'émettre et de recevoir des données (par exemple, des paquets de données de contrôle) via des canaux virtuels. Dans le présent exemple de réalisation, un canal virtuel peut transporter, à chaque cycle SDPC, un paquet de données dont la taille maximale est de 48 bits. Ainsi, lorsqu'on souhaite envoyer un paquet de données de taille supérieure à 48 bits, celui-ci doit être segmenté en plusieurs sous-paquets de taille inférieure ou égale à 48 bits. Ces sous-paquets sont ensuite transmis l'un après l'autre à des cycles SDPC différents. Le mécanisme de segmentation est décrit en détail ci-après. On distingue deux types de paquets de données : - les paquets de premier type, aussi appelés paquets asynchrones ; et - les paquets de second type, aussi appelés paquets à durée de vie critique (� TS � pour � Time Sensitive � en anglais). Les paquets de second type (Time Sensitive) sont prioritaires par rapport aux paquets de premier type (paquets asynchrones). Comme on le verra par la suite, pour minimiser la latence des paquets de second type, l'invention propose d'interrompre l'envoi d'un paquet de premier type (qui est, par exemple, envoyé sur plusieurs cycles SDPC). En revanche, l'envoi d'un paquet de second type reste prioritaire et ne peut donc pas être interrompu au détriment d'un paquet de premier type. L'invention prévoit également d'insérer un paquet de second type (Time Sensitive) dans un flux synchrone sur un canal virtuel dédié au transport de données synchrone, telles que par exemple des données audio. Comme décrit en détail ci-après, l'invention prévoit avantageusement d'utiliser un symbole de silence spécifique pour marquer le début d'un paquet de données. Ainsi, et contrairement aux techniques de l'art antérieur qui nécessite la détection de plusieurs symboles pour interrompre l'envoi d'un paquet de données, l'invention propose de détecter uniquement un symbole de silence spécifique pour réaliser cette opération d'interruption. 6.4 Architecture d'un module de communication synchrone On présente, en relation avec la figure 2, un exemple d'architecture d'un module de communication synchrone (SCM) générique d'un noeud WAR ou WAD du système de communication 2000 selon un mode de réalisation particulier de l'invention. Comme illustré, le module de communication synchrone 3000 comprend une unité centrale de traitement 87 (qui est par exemple un microprocesseur référencé CPU) coopérant avec un bloc de mémoire d'exécution 86 (RAM) et un bloc de mémoire non volatile 85 (ROM). L'unité centrale 87 communique avec un module radio 84 via une interface 93 (CPU IF). L'interface 93 gère notamment les interruptions à destination du microprocesseur (CPU), ainsi que les échanges de données entre les différents blocs du module radio 84 et l'unité centrale 87. On note que l'unité centrale 87 génère et traite les paquets de premier (paquets asynchrones) et de second (paquets Time Sensitive) types. Ainsi, à l'initialisation du système, l'unité centrale 87 effectue le transfert des informations de configuration depuis la mémoire non volatile 85 vers l'interface 93. Ces informations de configuration comprennent, par exemple, une séquence prédéterminée d'allocation de canaux virtuels stockée dans un registre TDM_MAP 13 de répartition TDM. Dans une variante de réalisation, il est possible d'envisager de sélectionner une configuration parmi une pluralité de configurations système (par exemple, stockée préalablement dans la mémoire non volatile 85), en fonction d'informations (par exemple, sur l'application et l'environnement du système) provenant d'un utilisateur. Le module radio 84 coopère avec un bloc d'interface radio 60GHz 99 et un bloc d'interface audio synchrone 98. Comme illustré, le bloc d'interface audio synchrone 98 comprend une FIFO de transmission 171 de données synchrones (� SSTF � pour � Synchronous Stream Transmit Fifo � en anglais) et une FIFO de réception 172 de données synchrones (� SSRF � pour � Synchronous Stream Receive Fifo � en anglais). Le bloc d'interface audio synchrone 98 communique avec un module de traitement de canaux audio 82. Le module radio 84 permet donc de transférer des données synchrones depuis le bloc d'interface radio 60GHz 99 vers le module de traitement de canaux audio 82, et inversement. Dans le cas d'un noeud de type WAR la,2a.. (Wireless Audio Renderer), le module de traitement de canaux audio 82 est un moyen de restitution de canal audio numérique (� Digital Audio Channel Amplifier � en anglais). Dans le cas d'un noeud de type WAD 5a (Wireless Audio Decoder), le module de traitement de canaux audio 82 est un décodeur audio multi voies (� Surround sound decoder � en anglais). Le bloc d'interface en mode paquet 10 permet donc de transmettre et de recevoir des paquets de données sur le canal virtuel (dédié au transport de données de contrôle) alloué au noeud émetteur. Comme illustré, le bloc d'interface en mode paquet 10 comprend, côté émission des paquets de données, une première FIFO de transmission AsyOut de paquets de premier type (paquets asynchrones) et une deuxième FIFO de transmission TsOut_1 de paquets de second type (Time Sensitive). Dans le présent mode de réalisation, le bloc d'interface en mode paquet 10 comprend en outre une troisième FIFO de transmission TsOut_2 permettant de transmettre des paquets de second type (Time Sensitive) sur un canal virtuel dédié au transport de données synchrone, telles que par exemple des données audio. Comme on le verra par la suite, la troisième FIFO TsOut 2 est utilisée en cas de débordement. Le bloc d'interface en mode paquet 10 comprend, côté réception des paquets de données, un premier ensemble de huit FIFOs de réception AsyIn(8) permettant de recevoir des paquets de premier type (paquets asynchrones) et un second ensemble de huit FIFOs de réception Tsin 1(8) permettant de recevoir des paquets de second type (Time Sensitive). Dans le présent mode de réalisation, le bloc d'interface en mode paquet 10 comprend en outre une quatrième FIFO de réception Tsln_2 permettant de recevoir des paquets de second type (Time Sensitive) sur un canal virtuel dédié au transport de données synchrone, telles que par exemple des données audio. Le module radio 84 comprend un module d'adaptation TDM AL 12 permettant de recevoir des données de type audio (provenant du bloc d'interface audio synchrone 98) et des données de type paquet (provenant du bloc d'interface en mode paquet 10) et de les convertir dans un format TDM (communication synchrone par circuits). A l'inverse, le module d'adaptation TDM AL 12 permet de recevoir des données au format TDM et d'extraire à partir des données reçues des données de type audio et de type paquet pour les transmettre vers le bloc d'interface audio synchrone 98 et le bloc d'interface en mode paquet 10, respectivement. Le module radio 84 comprend également un bloc de transport TDM 18. Plus précisément, le bloc de transport TDM 18 permet de transférer de manière synchrone des données depuis le module d'adaptation TDM AL 12 vers le bloc d'interface radio 60GHz 99, et inversement. On note qu'à chaque cycle SDPC, le module d'adaptation TDM AL 12 transmet au bloc d'interface radio 60GHz 99 des données relatives à des canaux virtuels alloués en écriture. Dans le présent exemple, ces données proviennent des blocs d'interfaces 10 et 98. On note également qu'à chaque cycle SDPC, le bloc de transport TDM 18 transmet au module d'adaptation TDM AL 12 des données relatives à des canaux virtuels alloués en lecture. Après analyse, le module d'adaptation TDM AL 12 envoie ces données vers le bloc d'interface en mode paquet 10 ou le bloc d'interface audio synchrone 98. Comme illustré sur la figure 2, le module d'adaptation TDM AL 12 comprend : - le registre TDM_MAP 13 de répartition TDM comprenant des informations d'allocation des canaux virtuels ; - un gestionnaire de bus TDM 14 permettant de gérer les échanges de données entre les blocs d'interfaces 10 et 98 et le bloc de transport TDM 18 ; - un bloc d'insertion de symboles 15 permettant d'insérer un symbole de silence (NULL) ou un symbole de début de paquet dans le paquet de données à destination du bloc de transport TDM 18 ; et - un bloc d'analyse de symboles 16 permettant de déterminer la nature du symbole contenu dans le paquet de données provenant du bloc de transport TDM 18. En d'autres termes, on détermine si c'est un symbole de silence (par exemple, le symbole � NULL � 301), un symbole indiquant une perte de données (symbole � MISSING � 302) ou un symbole de début de paquet 304. 6.4 Structure d'un canal virtuel Comme illustré sur la figure 3, un canal virtuel VC comprend un champ d'identification 307 (� flag � en anglais) (aussi appelé par la suite bit d'entête) et un champ de données utiles 308 comprenant un ensemble de blocs de données. Dans le mode de réalisation illustré, la taille du champ d'identification 307 est de 1 bit, et la taille du champ de données utiles 308 est de 48 bits. Selon l'invention, le champ d'identification 307 commande la sémantique du champ de données utiles 308. Plus précisément, le champ d'identification 307 peut prendre la valeur � 1 � ou � 0 � : - si le champ d'identification 307 prend la valeur � 1 �, alors cela signifie que le canal virtuel VC transporte un symbole spécial 306. Comme illustré, le symbole spécial 306 peut être : o un symbole � MISSING � 302 caractérisé par le fait que son champ de données utiles 308 est égal à la valeur hexadécimale 0x555555555555. Comme indiqué ci-dessus, le symbole � MISSING � 302 est inséré par les noeuds récepteurs en cas de perte de données d'un paquet en réception ; ou 25 o un symbole de silence 305 spécifique à l'invention. Comme illustré, le symbole de silence 305 peut se décliner en deux sous-symboles : un symbole � NULL � 301 caractérisé par le fait que son champ de données utiles est entièrement à � 0 �, c'est-à-dire égal à la valeur hexadécimale 0x000000000000. Le symbole � NULL � 301 est 30 envoyé par le système en tant que silence lorsque aucune donnée n'est envoyée sur le canal virtuel VC. Ainsi, ce symbole � NULL � 10 15 20 301 permet de notifier à un noeud récepteur une absence de données pour un cycle SDPC donnée ; un symbole de début de paquet 304 (� Start_packet symbol � en anglais) caractérisé par le fait que son champ de données utiles est différent des valeurs hexadécimales 0x555555555555 et 0x000000000000; - si le champ d'identification 307 prend la valeur � 0 �, alors cela signifie que le canal virtuel VC transporte des conteneurs de données asynchrones 303. Comme décrit en détail ci-après en relation avec la figure 4, un noeud émetteur peut segmenter un paquet de données asynchrone à transmettre, si la taille du paquet est supérieure à la taille du champ de données utiles du symbole de début de paquet asynchrone 304. 6.5 Structure d'un paquet de données de contrôle Comme illustré sur la figure 4, un paquet de données de contrôle 4000 comprend 15 un champ en-tête 400 et un champ de données utiles 401. Dans le mode de réalisation illustré, la taille du champ en-tête 400 est de 24 bits, et la taille du champ de données utiles 401 est variable. On note que la taille du paquet de données de contrôle 4000 est limitée par la capacité des FIFOs du bloc d'interface en mode paquet 10 (décrit en référence à la figure 2). En outre, il est important de noter que, dans un mode de 20 réalisation particulier de l'invention, le symbole de début de paquet 304 comprend le champ d'identification 307 (décrit ci-dessus en relation avec la figure 3), le champ en-tête 400 et une partie du champ de données utiles 401. Plus précisément, le champ en-tête 400 comprend : - un champ � Packet type � 402. Dans le mode de réalisation illustré, la taille du 25 champ � Packet type � 402 est de 1 bit. Le champ � Packet type � 402 indique le type de paquet de données de contrôle. En d'autres termes, le champ � Packet type � 402 indique si le paquet de données de contrôle est du premier type (paquets asynchrones) ou du second type (Time Sensitive) ; - un champ � Node_id � 403. Dans le mode de réalisation illustré, la taille du 30 champ � Node_id � 403 est de 6 bits. Le champ � Node_id � 403 indique l'identité du noeud émetteur ; 10 - un champ � Unique id � 404. Dans le mode de réalisation illustré, la taille du champ � Unique id � 404 est de 6 bits. Le champ � Unique id � 404 comprend un identifiant généré par le noeud à l'origine du paquet. Cet identifiant est unique localement à ce noeud d'origine. Ainsi, en combinant l'identifiant du noeud d'origine avec l'identifiant du noeud émetteur, on obtient un identifiant unique dans le réseau pour le paquet ; - un champ � Size � 405. Dans le mode de réalisation illustré, la taille du champ � Size � 405 est de 7 bits. Le champ � Size � 405 indique la taille du paquet en nombre de canaux virtuels. Comme illustré sur la figure 4, si la taille du paquet de données de contrôle 4000 est supérieure à la taille du champ de données utiles du symbole de début de paquet asynchrone 304, le noeud émetteur segmente le paquet de données de contrôle 4000 en une séquence de segments comprenant : un premier segment ayant une taille inférieure ou égale à la taille du champ utile du symbole de début de paquet asynchrone 304, et une pluralité de seconds segments ayant une taille inférieure ou égale à la taille d'un champ utile d'un conteneur de données asynchrones 303. On note que le symbole de début de paquet asynchrone 304 comprend, dans son champ utile, le premier segment de la séquence. On note également que chaque conteneur de données asynchrones 303 comprend un identifiant de conteneur de données 307 et un champ utile contenant un des seconds segments de la séquence. Après segmentation, le noeud émetteur transmet le symbole de début de paquet asynchrone 304 sur le canal réservé (aussi appelé par la suite second canal virtuel) pendant un premier cycle réseau, et les conteneurs de données 307 pendant des cycles réseau postérieurs au premier cycle réseau. 6.6 Architecture d'un registre de répartition TDM On présente, en relation avec la figure 9, un exemple d'architecture du registre TDM_MAP de répartition TDM 13 selon le mode de réalisation particulier de l'invention. Le registre TDM_MAP de répartition TDM 13 comprend une zone mémoire de 32 bits pour chaque canal virtuel. Les données dans le registre TDM_MAP de répartition TDM 13 sont ordonnancées selon la numérotation des canaux virtuels: à la première adresse décalée (� offset � en anglais) alignée sur 32 bits du registre se trouve la zone mémoire correspondant au canal virtuel 0 et à la nième adresse décalée (� offset � en anglais) alignée sur 32 bits du registre se trouve la zone mémoire correspondant au canal virtuel n. La zone mémoire 800 d'un canal virtuel donné comprend six champs : - un champ � fonction � 801 qui comprend deux bits et qui identifie la nature du canal 5 virtuel, par exemple b00 signifie � canal virtuel en lecture �, b01 signifie � canal virtuel en écriture � et b lx signifie � canal virtuel non utilisé � ; - un champ � SSRF � 802 qui comprend six bits et qui identifie la FIFO SSRF qui est associée au canal virtuel, par exemple, b000000 signifie que c'est la FIFO SSRF[0], b000001 signifie que c'est la FIFO SSRF[1], et bllllll signifie qu'aucune FIFO 10 SSRF n'est associée au canal virtuel ; - un champ � SMRF � 803 qui comprend six bits et qui identifie la FIFO de réception AsyIn en mode paquet associée au canal virtuel dans le cas où le paquet reçu est un paquet de premier type (paquets asynchrones), ou la FIFO de réception Tsin 1 en mode paquet associée au canal virtuel dans le cas où le paquet reçu est un paquet de 15 second type (Time Sensitive). Par exemple, b000000 signifie que c'est la FIFO Asyln[0] ou Tsin 1[0] selon le type de paquet reçu, b000001 signifie que c'est la FIFO Asyln[1] ou Tsin 1[1], et bllllll signifie qu'aucune FIFO en mode paquet n'est associée au canal virtuel ; - un champ � SSTF � 804 qui comprend six bits et qui identifie la FIFO SSTF qui est 20 associée au canal virtuel, par exemple, b000000 signifie que c'est la FIFO SSTF[0], b000001 signifie que c'est la FIFO SSTF[1], et bllllll signifie qu'aucune FIFO SSTF n'est associée au canal virtuel ; - un champ � SMTF � 805 qui comprend six bits et qui identifie la FIFO de transmission AsyOut en mode paquet associée au canal virtuel dans le cas où le paquet 25 transmis est un paquet de premier type (paquets asynchrones), ou la FIFO de transmission TsOut en mode paquet associée au canal virtuel dans le cas où le paquet transmis est un paquet de second type (Time Sensitive). Par exemple, b000000 signifie que c'est la FIFO AsyOut ou TsOut, et bllllll signifie qu'aucune FIFO en mode paquet n'est associée au canal virtuel ; 30 - un champ � reservé � 806 qui comprend six bits qui sont réservés pour toute prochaine application. 6.7 Fonctionnement du gestionnaire de bus TDM On présente, en relation avec la figure 5, les étapes principales d'un algorithme de traitement mis en oeuvre par le gestionnaire de bus TDM 14 (décrit en relation avec la figure 2), compris dans un noeud générique (noeud maître ou esclave), selon un mode de réalisation particulier de l'invention. Après une phase d'initialisation, le gestionnaire de bus TDM 14 attends dans une étape 1200 un signal (aussi appelé événement) TDM_cycle_start indiquant le début d'un cycle TDM. Dans une étape 1201, le gestionnaire de bus TDM 14 reçoit le signal TDM_cycle_start. Dans une étape 1202, un compteur de canaux virtuels TDM_VC est initialisé à zéro. Dans une étape 1203, le gestionnaire de bus TDM 14 lit les registres du module TDM_MAP 13 (décrit en relation avec la figure 2) à l'adresse décalée (� offset � en anglais) définie par la valeur du compteur TDM_VC. Ainsi, le gestionnaire de bus TDM 14 obtient des informations sur l'état de configuration (mode écriture ou mode lecture) du canal virtuel courant et des informations de sélection d'une FIFO (FIFO de transmission (SSTF, AsyOut, TsOut) ou FIFO de réception (SSRF, AsyIn, Tsln)). Dans une étape 1204, on vérifie l'état de configuration du canal virtuel courant. Si le canal virtuel courant est un canal virtuel alloué en écriture, c'est-à-dire dans le cas où le noeud envoie des données, alors on passe à une étape 1205. En revanche, si le canal virtuel courant est un canal virtuel alloué en lecture, alors on passe à une étape 1207. Dans l'étape 1205, on vérifie la nature de la FIFO de transmission indiquée dans le module TDM MAP 13. Si la FIFO de transmission est une FIFO de transmission de données synchrones 171 (FIFO � SSTF �), alors l'étape 1205 comprend les étapes d'un algorithme de traitement décrit ci-après en relation avec la figure 6a. En revanche, si la FIFO de transmission est une FIFO de transmission de données asynchrones (FIFO � AsyOut � ou FIFO � TsOut �), alors l'étape 1205 comprend les étapes d'un algorithme de traitement décrit ci-après en relation avec la figure 6b. À l'issue de cette étape 1205, on sélectionne l'une des FIFOs de transmission et on la place en mode lecture. Dans une étape 1206, on envoie au bloc d'insertion de symboles 15 une requête de lecture de la FIFO sélectionnée à l'étape 1205. Puis, on passe à une étape 1210. Dans l'étape 1207, le gestionnaire de bus TDM 14 vérifie que le canal virtuel courant est un canal virtuel alloué en lecture. En cas de vérification positive, on passe à une étape 1208, sinon (cela signifie que le canal virtuel courant n'est pas affecté pour la transmission de données) on passe à l'étape 1210. Dans l'étape 1208, on vérifie la nature de la FIFO de réception indiquée dans le module TDM_MAP 13. Si la FIFO de réception est une FIFO de réception 172 de données synchrones (FIFO � SSRF �), alors l'étape 1208 comprend les étapes d'un algorithme de traitement décrit ci-après en relation avec la figure 6a. En revanche, si la FIFO de réception est une FIFO de réception de données asynchrones (FIFO � AsyIn � ou FIFO � Tsln �), alors l'étape 1208 comprend les étapes d'un algorithme de traitement décrit ci-après en relation avec la figure 6b. À l'issue de cette étape 1208, on sélectionne l'une des FIFOs de réception et on la place en mode écriture. Dans une étape 1209, on envoie au bloc d'analyse de symboles 16 une requête d'écriture dans la FIFO sélectionnée à l'étape 1208. Puis, on passe à l'étape 1210. Dans l'étape 1210, on incrémente d'une unité la valeur du compteur TDM_VC. Enfin dans une étape 1211, le gestionnaire de bus TDM 14 vérifie si tous les canaux virtuels du cycle TDM ont été traités. En cas de vérification positive, on retourne à l'étape 1200, sinon on retourne à l'étape 1203. On présente, en relation avec la figure 6a, les sous-étapes de l'étape de sélection d'une FIFO de transmission (étape 1205 décrite ci-dessus en relation avec la figure 5), dans le cas où on transmet un canal virtuel courant comprenant des données synchrones (par exemple des données audio). Dans une sous-étape 500, on vérifie la nature des données qui sont envoyées sur le canal virtuel courant. Si on détecte un paquet de second type (Time Sensitive) en cours d'envoi (c'est-à-dire si on détecte que la variable TS_en_cours_audio est égale à 1), alors on passe à une sous-étape 501, sinon (cela signifie qu'il n'y a pas de paquet de second type en cours d'envoi sur le canal virtuel courant et que la variable TS_en_cours_audio est égale à 0) on passe à une sous-étape 503. Dans la sous-étape 501, on purge les données synchrones (par exemple des données audio) en provenance de la FIFO de transmission 171 de données synchrones (FIFO � SSTF �). Dans une sous-étape 502, on place la FIFO TsOut_2 en mode lecture et on continue l'envoi du paquet de second type (Time Sensitive) sur le canal virtuel courant. Si la donnée à lire constitue la dernière donnée de la FIFO TsOut 2 alors la variable TS en cours audio est remise à zéro. Dans la sous-étape 503, on vérifie s'il y a un paquet de second type (Time Sensitive) prêt à être envoyé sur le canal virtuel courant. En d'autres termes, on vérifie s'il y a des données Time Sensitive dans la FIFO TsOut_2. En cas de vérification positive, on passe à une sous-étape 505, sinon (cela signifie qu'il n'y a pas de paquet de second type (Time Sensitive) à transmettre) on passe à une sous-étape 504. Dans la sous-étape 505, on purge les données synchrones (par exemple des données audio) en provenance de la FIFO de transmission 171 de données synchrones (FIFO � SSTF �). Dans une sous-étape 506, on commence à transmettre le paquet de second type (Time Sensitive) (détecté à la sous-étape 503) sur le canal virtuel courant. A cette sous-étape 506, on positionne le symbole de début de paquet 304 (i.e signal start_packet) spécifique à l'invention (décrit en relation avec la figure 3). On note également que la FIFO TsOut_2 est placée dans le mode lecture. Si la donnée à lire constitue la dernière donnée de la FIFO TsOut 2 alors la variable TS en cours audio est remise à zéro. Dans la sous-étape 504, on continue l'envoi des données synchrones sur le canal virtuel courant. On note que la FIFO � SSTF � 171 est placée dans le mode lecture. On présente, en relation avec la figure 6b, les sous-étapes de l'étape de sélection d'une FIFO de transmission (étape 1205 décrite ci-dessus en relation avec la figure 5), dans le cas où on transmet un canal virtuel courant comprenant des données asynchrones (i.e paquets de premier type). Dans une sous-étape 550, on vérifie la nature des données qui sont envoyées sur le canal virtuel courant. Si on détecte un paquet de second type (Time Sensitive) (c'est- à-dire si on détecte que la variable TS_en_cours_paquet est égale à 1), alors on passe à une sous-étape 551, sinon (cela signifie qu'il n'y a pas de paquet de second type en cours d'envoi sur le canal virtuel courant et que la variable TS_en_cours_paquet est égale à 0) on passe à une sous-étape 552. Dans la sous-étape 551, on place la FIFO TsOut_1 en mode lecture et on continue l'envoi du paquet de second type (Time Sensitive) sur le canal virtuel courant. Si la donnée à lire constitue la dernière donnée de la FIFO TsOut 1 alors la variable TS_en_cours_paquet est remise à zéro. Dans la sous-étape 552, on vérifie s'il y a des données asynchrones (i.e paquet de premier type) en cours de traitement (c'est-à-dire si la variable Asy_en_cours est égale à 1). En cas de vérification positive, on passe à une sous-étape 553, sinon on passe à une sous-étape 557. Dans la sous-étape 553, on vérifie s'il y a une nouvelle requête de transfert d'un paquet de second type (Time Sensitive). En d'autres termes, on vérifie s'il y a des données Time Sensitive dans la FIFO TsOut_1. En cas de vérification positive, on passe à une sous-étape 554, sinon on passe à une sous-étape 556. Dans la sous-étape 554, on positionne la variable Ts_en_cours_paquet à 1 de manière à suspendre le transfert en cours des données asynchrones (i.e paquet de premier type). Ainsi, on donne la priorité au paquet de second type (Time Sensitive). Dans une sous-étape 555, on commence à transmettre le paquet de second type (Time Sensitive) sur le canal virtuel courant. A cette sous-étape 555, on positionne le symbole de début de paquet 304 (i.e signal start_packet) spécifique à l'invention (décrit en relation avec la figure 3). On note également que la FIFO TsOut_1 est placée dans le mode lecture. Si la donnée à lire constitue la dernière donnée de la FIFO TsOut 1 alors la variable TS_en_cours_paquet est remise à zéro. Dans la sous-étape 556, on place la FIFO AsyOut en mode lecture et on continue l'envoi des données asynchrones (i.e paquet de premier type) en cours. Si la donnée à lire constitue la dernière donnée de la FIFO AsyOut alors la variable Asy_en_cours est remise à zéro. Dans la sous-étape 557, on vérifie s'il y a une nouvelle requête de transfert d'un paquet de second type (Time Sensitive). En d'autres termes, on vérifie s'il y a des données Time Sensitive dans la FIFO TsOut_1. En cas de vérification positive, on passe à une sous-étape 558, sinon on passe à une sous-étape 559. Dans la sous-étape 558, on commence à transmettre le paquet de second type (Time Sensitive) sur le canal virtuel courant. A cette sous-étape 558, on positionne le symbole de début de paquet 304 (i.e signal start_packet) spécifique à l'invention (décrit en relation avec la figure 3). On note également que la FIFO TsOut_1 est placée dans le mode lecture. Si la donnée à lire constitue la dernière donnée de la FIFO TsOut 1 alors la variable TS_en_cours_paquet est remise à zéro, sinon elle est positionnée à 1. Dans la sous-étape 559 (c'est-à-dire dans le cas où il n'y a pas de nouvelle requête de transfert de paquet de type Time Sensitive), on vérifie s'il y a une nouvelle requête de transfert d'un paquet de premier type. En d'autres termes, on vérifie s'il y a des données asynchrones dans la FIFO AsyOut. En cas de vérification positive, on passe à une sous-étape 560, sinon on passe à une sous-étape 561. Dans la sous-étape 560, on commence à transmettre le paquet de premier type (paquet asynchrone) sur le canal virtuel courant. A cette sous-étape 560, on positionne le symbole de début de paquet 304 (i.e signal start_packet) spécifique à l'invention (décrit en relation avec la figure 3). On note également que la FIFO AsyOut est placée dans le mode lecture. Si la donnée à lire constitue la dernière donnée de la FIFO AsyOut alors la variable Asy_en_cours est remise à zéro, sinon elle est positionnée à 1. Dans la sous-étape 561 (c'est-à-dire dans le cas où il n'y a aucune requête de transfert), on transmet un symbole de silence sur le canal virtuel courant. Pour ce faire, on place la FIFO AsyOut dans le mode lecture. En effet, la FIFO AsyOut étant vide, le bloc d'insertion de symboles 15 va insérer un symbole de silence 301 (� NULL �) sur le canal virtuel courant. On présente, en relation avec la figure 7a, les sous-étapes de l'étape de sélection d'une FIFO de réception (étape 1208 décrite ci-dessus en relation avec la figure 5) dans le cas où on reçoit un canal virtuel courant comprenant des données synchrones (par exemple des données audio). Dans une sous-étape 600, on vérifie si on reçoit un symbole ou une donnée en provenance du bloc d'analyse de symboles 16. Si on reçoit un symbole, alors on passe à une sous-étape 601. En revanche, si on reçoit une donnée, alors on passe à une sous- étape 616. Dans la sous-étape 601, on vérifie la nature du symbole reçu à la sous-étape 600. Si le symbole reçu est un symbole indiquant une perte de données (symbole � MISSING �), alors on passe à une sous-étape 602. En revanche, si le symbole reçu est un symbole de silence 305, alors on passe à une sous-étape 605. Dans la sous-étape 602, on vérifie s'il y a un paquet de second type (paquet de type Time Sensitive) dans le flux de données en cours de réception. En cas de vérification positive (c'est-à-dire si on détecte que la variable Ts_rx_en_cours_audio est égale à 1), on passe à une sous-étape 603, sinon (cela signifie qu'il n'y a pas de paquet de type Time Sensitive en cours de réception) on passe à une sous-étape 604. Dans la sous-étape 603, on marque la FIFO Tsln_2 comme contenant un paquet erroné. S'il s'agit de la dernière donnée attendue pour la réception du paquet en cours, alors une notification de réception de paquet par la FIFO Tsln_2 est envoyée à l'unité centrale de traitement 87. Dans la sous-étape 604, on détecte une perte de synchronisation. Plus 15 précisément, on détecte soit la perte d'une donnée synchrone soit la perte d'un début d'un nouveau paquet de type Time Sensitive. Dans le présent mode de réalisation, on considère par défaut qu'il s'agit d'une perte de donnée synchrone. Ainsi, si lors des cycles suivant la suite d'un paquet de type Time Sensitive était envoyé par erreur au bloc d'interface audio synchrone 98, alors le bloc d'interface audio synchrone 98 20 gommerait ces erreurs selon des techniques de dissimulation d'erreur bien connues de l'Homme du Métier (et donc pas décrits dans le présent document). Dans la sous-étape 605, on vérifie la nature du symbole de silence 305. Si le symbole de silence 305 est un � vrai � silence (i.e symbole � NULL � 301), alors on passe à une sous-étape 606. En revanche, si le symbole de silence 305 est un symbole de 25 début de paquet 304, alors on passe à une sous-étape 609. Dans la sous-étape 606, on vérifie si un paquet de type Time Sensitive est en cours de réception. En d'autres termes, on vérifie si la variable Ts_rx_en_cours_audio est égale à 1. En cas de vérification positive, on passe à une sous-étape 607, sinon on passe à une sous-étape 608. 30 Dans la sous-étape 607, on détecte la présence d'une erreur exceptionnelle. En effet, le protocole de transport de paquet ne prévoit pas de période de silence lors de la 10 transmission d'un paquet. A titre d'exemple, une panne du noeud émetteur peut être à l'origine de cette erreur exceptionnelle. Ainsi dans la sous-étape 607, on notifie l'erreur exceptionnelle à l'unité centrale de traitement 87, puis on marque la FIFO Tsln_2 comme contenant un paquet erroné. S'il s'agit de la dernière donnée attendue pour la réception du paquet en cours, alors une notification de réception de paquet par la FIFO Tsln_2 est envoyée à l'unité centrale de traitement 87. Dans la sous-étape 608, on détecte la présence d'un silence applicatif audio. Lors de cette sous-étape 608, aucun traitement n'est effectué. Dans la sous-étape 609, on vérifie s'il y a déjà un paquet de type Time Sensitive en cours de réception. En cas de vérification positive, on passe à une sous-étape 610, sinon on passe à une sous-étape 612. Dans la sous-étape 610, on détecte la présence d'une erreur exceptionnelle. En effet, le protocole de transport de paquet ne prévoit pas l'interruption de paquet de type Time Sensitive. Ainsi dans la sous-étape 610, on notifie l'erreur exceptionnelle à l'unité centrale de traitement 87, puis on marque la FIFO Tsln_2 comme contenant un paquet erroné. S'il s'agit de la dernière donnée attendue pour la réception du paquet en cours, alors une notification de réception de paquet par la FIFO Tsln_2 est envoyée à l'unité centrale de traitement 87. Puis, on passe à la sous-étape 612. Dans la sous-étape 612, on vérifie la nature du paquet en provenance du bloc d'analyse de symboles 16. Si le paquet en provenance du bloc d'analyse de symboles 16 est un paquet de second type (Time Sensitive), alors on passe à une sous-étape 613. En revanche, si le paquet en provenance du bloc d'analyse de symboles 16 est un paquet de premier type (i.e données asynchrones), alors on passe à une sous-étape 614. Dans la sous-étape 613, on transmet un signal de suspension du flux de données synchrones au bloc d'interface audio synchrone 98. Dans une sous-étape 611, on place la FIFO Tsln_2 en mode lecture et on met à 1 la variable Ts_rx_en_cours_audio, pour commencer la réception d'un nouveau paquet de type Time Sensitive. S'il s'agit de la dernière donnée attendue pour la réception du paquet en cours, alors une notification de réception de paquet par la FIFO Tsin 2 est envoyée à l'unité centrale de traitement 87. Dans la sous-étape 614, on détecte la présence d'une erreur exceptionnelle. En effet, selon le protocole de transport de paquet mis en oeuvre par le noeud, seuls les paquets de type Time Sensitive sont autorisés à être transmis sur des canaux virtuels dédiés aux flux de données synchrones. Ainsi dans la sous-étape 614, on notifie l'erreur exceptionnelle à l'unité centrale de traitement 87. On note qu'aucune FIFO n'est positionnée en mode lecture, la donnée sera de ce fait purgée. Dans la sous-étape 616, on vérifie s'il y a un paquet de type Time Sensitive dans le flux de données en cours de réception. En cas de vérification positive (c'est-à-dire si on détecte que la variable Ts_rx_en_cours_audio est égale à 1), on passe à une sous- étape 617, sinon (cela signifie qu'il y a une donnée synchrone dans le flux de données en cours de réception) on passe à une sous-étape 618. Dans la sous-étape 617, on place la FIFO Tsln_2 en mode lecture. S'il s'agit de la dernière donnée attendue pour la réception du paquet en cours, alors une notification de réception de paquet par la FIFO Tsln_2 est envoyée à l'unité centrale de traitement 87, et la variable Ts_rx_en_cours_audio est remise à zéro. Dans la sous-étape 618, on place la FIFO SSRF en mode lecture. On présente, en relation avec les figures 7b et 7c, les sous-étapes de l'étape de sélection d'une FIFO de réception (étape 1208 décrite ci-dessus en relation avec la figure 5) dans le cas où on reçoit un canal virtuel courant comprenant des données asynchrones (i.e canal virtuel en mode paquet). Par souci de simplification de la description, dans la suite de ce document on utilisera le terme de FIFO AsyIn pour désigner une FIFO permettant de recevoir des paquets de premier type (paquets asynchrones) et le terme de FIFO Tsln_1 pour désigner une FIFO permettant de recevoir des paquets de second type (Time Sensitive). Bien entendu, et comme indiqué précédemment, il y a autant de FIFOs AsyIn et Tsln_1 que de canaux virtuels de contrôle en mode réception, l'indice de la FIFO AsyIn ou AsyIn_1 est donné par le registre TDM_MAP 13 (décrit en relation avec la figure 2). Dans une sous-étape 650, on vérifie la nature du canal virtuel 300 tel que reçu par le bloc d'analyse de symboles 16. En d'autres termes, on vérifie si le canal virtuel 300 transporte un symbole spécial 306 ou un conteneur de données asynchrones 303. Si le canal virtuel est du type transportant un symbole spécial 306, alors on passe à une sous-étape 651. En revanche, si le canal virtuel est du type transportant un conteneur de données asynchrones 303, alors on passe à une sous-étape 663. Dans la sous-étape 651, on vérifie la nature du symbole reçu à la sous-étape 650 (par le bloc d'analyse de symboles 16). Si le symbole reçu est un symbole indiquant une perte de données (symbole � MISSING � 302), alors on passe à une sous-étape 652. En revanche, si le symbole reçu est un symbole de silence 305, alors on passe à une sous-étape 657. Dans la sous-étape 652, on vérifie s'il y a un paquet de second type (paquet de type Time Sensitive) dans le flux de données en cours de réception. En cas de vérification positive (c'est-à-dire si on détecte que la variable Ts_en_cours_paquet est égale à 1), on passe à une sous-étape 653, sinon (cela signifie qu'il n'y a pas de paquet de type Time Sensitive en cours de réception) on passe à une sous-étape 654. Dans la sous-étape 653, on marque la FIFO Tsln_1 comme contenant un paquet erroné. S'il s'agit de la dernière donnée attendue pour la réception du paquet en cours, alors une notification de réception de paquet par la FIFO Tsln_1 est envoyée à l'unité centrale de traitement 87, puis on passe la variable Ts_en_cours_paquet à zéro. Dans la sous-étape 654, on vérifie s'il y a un paquet de type asynchrone (i.e paquet de premier type) en cours de réception. En d'autres termes, on vérifie si la variable Asy_en_cours est égale à 1. En cas de vérification positive, on passe à une sous-étape 655, sinon on passe à une sous-étape 656. Dans la sous-étape 655, on marque la FIFO Asyln comme contenant un paquet erroné. S'il s'agit de la dernière donnée attendue pour la réception du paquet en cours, alors une notification de réception de paquet par la FIFO AsyIn est envoyée à l'unité centrale de traitement 87, puis on passe la variable Asy_en_cours à zéro. On note qu'il y a un risque de désynchronisation de paquet. En effet, le canal virtuel perdu en cours de traitement pourrait avoir contenu une marque de début de nouveau paquet. Dans ce cas, la suite de la réception pourrait générer une erreur exceptionnelle. Dans la sous-étape 656, on purge le canal virtuel reçu à la sous-étape 650. La purge consiste à ne valider aucune FIFO en mode écriture. Dans la sous-étape 657, on vérifie la nature du symbole de silence 305. Si le symbole de silence 305 est un � vrai � silence (i.e symbole � NULL � 301), alors on passe à une sous-étape 658. En revanche, si le symbole de silence 305 est un symbole de début de paquet 304, alors on passe à une sous-étape 669 (cf. figure 7c). Dans la sous-étape 658, on vérifie si un paquet de type Time Sensitive est en cours de réception. En d'autres termes, on vérifie si la variable Asy_en_cours est égale à 1. En cas de vérification positive, on passe à une sous-étape 659, sinon on passe à une sous-étape 660. Dans la sous-étape 659, on détecte la présence d'une erreur exceptionnelle. Ainsi dans la sous-étape 659, on notifie l'erreur exceptionnelle à l'unité centrale de traitement 87, puis on marque la FIFO Tsln_1 comme contenant un paquet erroné. S'il s'agit de la dernière donnée attendue pour la réception du paquet en cours, alors une notification de réception de paquet par la FIFO Tsln_1 est envoyée à l'unité centrale de traitement 87, puis on passe la variable Ts_en_cours_paquet à zéro. Dans la sous-étape 660, on vérifie si un paquet de premier type (i.e paquet asynchrone) est en cours de réception. En cas de vérification positive, on passe à une sous-étape 661, sinon on passe à une sous-étape 662. Dans la sous-étape 661, on détecte la présence d'une erreur exceptionnelle. En effet, le protocole de transport de paquets ne prévoit pas de silence au cours de la transmission de paquets. Ainsi dans la sous-étape 661, on notifie l'erreur exceptionnelle à l'unité centrale de traitement 87, puis on marque la FIFO Asynln comme contenant un paquet erroné. S'il s'agit de la dernière donnée attendue pour la réception du paquet en cours, alors une notification de réception de paquet par la FIFO Asynln est envoyée à l'unité centrale de traitement 87, puis on passe la variable Asy_en_cours à zéro. Dans la sous-étape 662, on détecte la présence d'un silence applicatif audio. Lors de cette sous-étape 662, aucun traitement n'est effectué. Dans la sous-étape 663, on vérifie s'il y a un paquet de type Time Sensitive dans le flux de données en cours de réception. En cas de vérification positive (c'est-à-dire si on détecte que la variable Ts_en_cours_paquet est égale à 1), on passe à une sous-étape 664, sinon on passe à une sous-étape 665. Dans la sous-étape 664, on place la FIFO Tsln_1 en mode écriture. S'il s'agit de la dernière donnée attendue pour la réception du paquet en cours, alors une notification de réception de paquet par la FIFO Tsln_1 est envoyée à l'unité centrale de traitement 87, et la variable Ts_en_cours_paquet est remise à zéro. Dans la sous-étape 665, on vérifie s'il y a un paquet de type asynchrone (i.e paquet de premier type) en cours de réception. En d'autres termes, on vérifie si la variable Asy_en_cours est égale à 1. En cas de vérification positive, on passe à une sous-étape 666, sinon on passe à une sous-étape 667. Dans la sous-étape 666, on place la FIFO AsyIn en mode écriture. S'il s'agit de la dernière donnée attendue pour la réception du paquet en cours, alors une notification de réception de paquet par la FIFO AsyIn est envoyée à l'unité centrale de traitement 87, et la variable Asy_en_cours est remise à zéro. Dans la sous-étape 667, on purge le canal virtuel reçu à la sous-étape 650 (du fait qu'un paquet doit commencer par une marque de début de paquet). La purge consiste à ne valider aucune FIFO en mode écriture. On note que ce cas n'est pas une erreur exceptionnelle. En effet, il peut se produire au démarrage lorsque le noeud émetteur démarre plus vite que le noeud récepteur. Dans la sous-étape 669 (cf. figure 7c), on vérifie si un paquet de type Time Sensitive est en cours de réception. En d'autres termes, on vérifie si la variable Ts_en_cours_paquet est égale à 1. En cas de vérification positive, on passe à une sous-étape 670, sinon on passe à une sous-étape 671. Dans la sous-étape 670, on détecte la présence d'une erreur exceptionnelle. En effet, le protocole ne prévoit pas qu'un paquet de type Time Sensitive soit interrompu. Ainsi dans la sous-étape 670, on notifie l'erreur exceptionnelle à l'unité centrale de traitement 87, on marque ensuite la FIFO Tsln_1 comme contenant un paquet erroné, puis on notifie l'unité centrale de traitement 87 de la réception d'un paquet dans la FIFO Tsin 1, et enfin on passe la variable Ts_en_cours_paquet à zéro. Puis, on passe à une sous-étape 679. Dans la sous-étape 671, on vérifie s'il y a un paquet de type asynchrone (i.e paquet de premier type) en cours de réception. En d'autres termes, on vérifie si la variable Asy_en_cours est égale à 1. En cas de vérification positive, on passe à une sous-étape 672, sinon on passe à la sous-étape 679. Dans la sous-étape 672, on vérifie la nature du symbole de début de paquet 304. S'il s'agit du début d'un paquet de type Time Sensitive, alors on passe à une sous-étape 673, sinon on passe à une sous-étape 675. Dans la sous-étape 673, on suspend la réception du paquet asynchrone et on maintient la variable Asy_en_cours à 1. On note que la FIFO AsyIn n'est pas mise en mode écriture. Puis, on passe à une sous-étape 674. Dans la sous-étape 674, on place la FIFO AsyIn_1 en mode écriture et on met à 1 la variable Ts_en_cours_paquet, pour commencer la réception d'un nouveau paquet de type Time Sensitive. S'il s'agit d'un paquet de taille 1, alors l'unité centrale de traitement 87 est notifié de la réception d'un paquet dans la FIFO Tsln_1 et la variable Ts_en_cours_paquet est à nouveau remise à 0. Dans la sous-étape 675, on détecte la présence d'une erreur exceptionnelle. En effet, le protocole de transport de paquets ne prévoit pas qu'un paquet de type asynchrone puisse interrompre un quelconque autre paquet. Ainsi dans la sous-étape 675, on notifie l'erreur exceptionnelle à l'unité centrale de traitement 87. La FIFO Asynln est donc purgée de ces données. Puis, on passe à une sous-étape 676. Dans la sous-étape 679, on vérifie la nature du symbole de début de paquet 304. S'il s'agit du début d'un paquet de type Time Sensitive, alors on passe à la sous-étape 674, sinon on passe à la sous-étape 676. Dans la sous-étape 676, on place la FIFO AsyIn en mode écriture et on met à 1 la variable Asy_en_cours, pour commencer la réception d'un nouveau paquet de type asynchrone (i.e paquet de premier type). 6.8 Fonctionnement du bloc d'insertion de symboles On présente, en relation avec la figure 8a, les étapes principales d'un algorithme de traitement mis en oeuvre par le bloc d'insertion de symboles 15 (décrit en relation avec la figure 2), compris dans un noeud générique (noeud maître ou esclave), selon un mode de réalisation particulier de l'invention. Après une phase d'initialisation, le bloc d'insertion de symboles 15 attends dans une étape 1300 une requête de lecture d'une FIFO de transmission (SSTF, AsyOut ou TsOut) en provenance du gestionnaire de bus TDM 14 (décrit en relation avec la figure 2). Dans une étape 1301, le bloc d'insertion de symboles 15 reçoit la requête de lecture d'une FIFO de transmission (SSTF, AsyOut ou TsOut), appelée ci-après FIFO sélectionnée. Dans une étape 1302, le bloc d'insertion de symboles 15 vérifie : - si la FIFO sélectionnée est vide, alors dans ce cas on passe à une étape 1303 ; - si la FIFO sélectionnée n'est pas vide, alors dans ce cas on passe à une étape 1305 ; - si un signal de début de paquet à été émis par le gestionnaire de bus TDM 14, alors dans ce cas on passe à l'étape 1303. Dans l'étape 1303, si la FIFO sélectionnée est déclarée vide (du fait que la FIFO sélectionnée présente une quantité de données disponibles inférieure à la capacité d'un canal virtuel (48bits)) ou si un signal de début de paquet à été émis par le gestionnaire de bus TDM 14, alors le bloc d'insertion de symboles 15 attribue la valeur � 1 � au bit d'entête 307 de l'échantillon de données pour le canal virtuel. Puis, on passe à une étape 1304. Dans l'étape 1304, dans le cas où la FIFO sélectionnée est déclarée vide, le bloc d'insertion de symboles 15 écrit, dans la FIFO d'interface d'émission du bloc de transport TDM 18, l'échantillon de données avec un entête à � 1 � à laquelle le bloc d'insertion de symboles 15 concatène un symbole � NULL � 301 (dans un mode de réalisation particulier, le symbole � NULL � est égal à la valeur hexadécimale 0x000000000000). En revanche, dans le cas où un signal de début de paquet à été émis par le gestionnaire de bus TDM 14, le bloc d'insertion de symboles 15 écrit, dans la FIFO d'interface d'émission du bloc de transport TDM 18, l'échantillon de données avec un entête à � 1 � à laquelle le bloc d'insertion de symboles 15 concatène le début de paquet contenant un header 402 (i.e champ � Packet type �) tel qu'envoyé par l'unité centrale de traitement 87 lors de l'écriture du paquet dans la FIFO correspondante. Puis on retourne à l'étape 1300. Dans l'étape 1305, le bloc d'insertion de symboles 15 lit l'échantillon de données (de 48 bits) dans la FIFO sélectionnée. Dans une étape 1306, le bloc d'insertion de symboles 15 attribue la valeur � 0 � au bit d'entête 307 de l'échantillon de données pour le canal virtuel. Dans une étape 1307, le bloc d'insertion de symboles 15 écrit, dans la FIFO d'interface d'émission du module TDM transport 18, l'échantillon de données avec un entête à � o � à laquelle le bloc d'insertion de symboles 15 concatène les données de la FIFO sélectionnée. Puis on retourne à l'étape 1300. 6.9 Fonctionnement du bloc d'analyse de symboles On présente, en relation avec la figure 8b, les étapes principales d'un algorithme de traitement mis en oeuvre par le bloc d'analyse de symboles 16 (décrit en relation avec la figure 2), compris dans un noeud générique (noeud maître ou esclave), selon un mode de réalisation particulier de l'invention. Après une phase d'initialisation, le bloc d'analyse de symboles 16 attends dans une étape 1310 une requête d'écriture dans une FIFO de réception (SSRF, AsyIn, Tsln) en provenance du gestionnaire de bus TDM 14 (décrit en relation avec la figure 2). Dans une étape 1311, le bloc d'analyse de symboles 16 reçoit la requête d'écriture dans une FIFO de réception (SSRF, AsyIn, Tsln), appelée ci-après FIFO sélectionnée. Dans une étape 1312, le bloc d'analyse de symboles 16 vérifie : - si la FIFO d'interface de réception du module TDM transport 18 est déclarée vide (du fait qu'aucun échantillon n'est disponible dans la FIFO), alors dans ce cas on retourne à l'étape 1310 ; - si la FIFO d'interface de réception du module TDM transport 18 n'est pas déclarée vide, alors dans ce cas on passe à une étape 1313. Dans l'étape 1313, le bloc d'analyse de symboles 16 lit l'échantillon de données (de 49 bits) dans la FIFO d'interface de réception du module TDM transport 18. Dans une étape 1314, le bloc d'analyse de symboles 16 extrait de l'échantillon de données lu à l'étape 1313 le bit le plus significatif correspondant au bit d'entête 307 de validité du canal virtuel. A cette étape 1314, le bloc d'analyse de symboles 16 vérifie si la valeur du bit d'entête 307 est égale à 1. En cas de vérification positive, on passe à une étape 1315, sinon on retourne à l'étape 1310. Dans l'étape 1315, le fait d'avoir la valeur du bit d'entête 307 est égale à 1, signifie que le canal virtuel comprend un symbole spécial 306. Le bloc d'analyse de symboles 16 transmet au gestionnaire de bus TDM 14 une information indiquant le type de symbole (symbole � MISSING � 302 ou symbole de silence 305). Si l'information indique un symbole de silence 305, alors on précise s'il s'agit d'un � vrai � silence (i.e symbole � NULL � 301) ou d'un symbole de début de paquet 304 (i.e signal start_packet). Dans le cas où il s'agit d'un symbole de début de paquet 304 l'information de type de paquet (i.e champ � Packet type � 402) est aussi transmise vers le gestionnaire de bus TDM 14. En revanche, dans le cas où il s'agit d'un � vrai � silence (i.e symbole � NULL � 301) ou d'un symbole � MISSING � 302, le symbole est purgé de la FIFO d'interface de réception du module TDM transport 18. Puis on retourne à l'étape 1310.10 REVENDICATIONS1. Procédé de transmission de données par un noeud émetteur (la) vers au moins un noeud récepteur (2a), dans un réseau de communication synchrone (2000) comprenant une pluralité de noeuds, ledit réseau mettant en oeuvre un cadencement qui définit un cycle réseau pour la transmission de données sur ledit réseau, le cycle réseau comprenant une pluralité de premiers canaux virtuels permettant la transmission de données synchrones et au moins un second canal virtuel permettant la transmission d'un premier type de paquets de données asynchrones, ledit procédé étant effectué par le noeud émetteur et caractérisé en ce qu'il comprend les étapes suivantes : - première détection (553), permettant de détecter une requête de transmission d'un second type de paquet de données asynchrones sur ledit second canal virtuel - deuxième détection (552), permettant de détecter une transmission en cours d'un premier type de paquet de données asynchrones sur ledit second canal virtuel ; - en cas de deuxième détection positive, construction d'un symbole de début de paquet asynchrone (304), comprenant un identifiant de symbole (307) et un champ utile (308) contenant un en-tête (400) dudit second type de paquet de données asynchrones et au moins une partie d'un ensemble de données utiles asynchrones dudit second type de paquet de données asynchrones ; - interruption (554) de la transmission dudit premier type de paquet de données asynchrones par insertion dudit symbole de début de paquet asynchrone (304) dans ledit second canal virtuel ; - transmission (555) dudit symbole de début de paquet asynchrone (304) sur ledit second canal virtuel. 2. Procédé de transmission selon la revendication 1, caractérisé en ce qu'il comprend les étapes suivantes : - lecture, dans l'en-tête (400), de la taille dudit second type de paquet de données asynchrones ;- si la taille dudit second type de paquet de données asynchrones est supérieure à la taille du champ utile dudit symbole de début de paquet asynchrone (304), segmentation dudit second type de paquet de données asynchrones en une séquence de segments comprenant : un premier segment ayant une taille inférieure ou égale à la taille du champ utile dudit symbole de début de paquet asynchrone (304), et au moins un second segment ayant une taille inférieure ou égale à la taille d'un champ utile d'un conteneur de données asynchrones (303) ; en ce que l'étape de construction dudit symbole de début de paquet asynchrone (304) comprend une étape d'insertion du premier segment de ladite séquence dans le champ utile dudit symbole de début de paquet asynchrone (304), en ce que le procédé comprend une étape de construction d'au moins un conteneur de données asynchrones (303), chaque conteneur de données asynchrones (303) comprenant un identifiant de conteneur de données (307) et un champ utile contenant un second segment de ladite séquence, en ce que ladite étape de transmission (555) dudit symbole de début de paquet asynchrone (304) sur ledit second canal virtuel, est effectuée pendant un premier cycle réseau, et en ce que le procédé comprend une étape de transmission dudit au moins un conteneur de données asynchrones (303) sur ledit second canal virtuel, chaque conteneur de données asynchrones (303) étant transmis pendant un cycle réseau postérieur audit premier cycle réseau. 3. Procédé de transmission selon l'une quelconque des revendications 1 et 2, caractérisé en ce que le noeud émetteur effectue une étape de reprise de la transmission, sur ledit second canal virtuel, dudit premier type de paquet de données asynchrones interrompu, après que le second type de paquet de données asynchrones a été entièrement transmis sur ledit second canal virtuel. 4. Procédé de transmission selon l'une quelconque des revendications 1 à 3, caractérisé en ce qu'il comprend les étapes suivantes : - troisième détection, permettant de détecter une transmission en cours d'unautre second type de paquet de données asynchrones sur ledit second canal virtuel, ledit autre second type de paquet de données asynchrones étant distinct du second type de paquet de données asynchrones faisant l'objet de ladite requête de transmission ; en cas de troisième détection positive, sélection d'un canal virtuel parmi ladite pluralité de premiers canaux virtuels ; construction d'un symbole de début de paquet asynchrone (304), comprenant un identifiant de symbole (307) et un champ utile contenant l'en-tête (400) et au moins une partie de l'ensemble de données utiles asynchrones dudit second type de paquet de données asynchrones ; interruption de la transmission de données synchrones sur le canal virtuel sélectionné par insertion dudit symbole de début de paquet asynchrone (304) dans ledit canal sélectionné ; transmission (555) dudit symbole de début de paquet asynchrone (304) sur ledit canal sélectionné. Procédé de réception de données par un noeud récepteur (2a), dans un réseau de communication synchrone (2000) comprenant une pluralité de noeuds, ledit réseau mettant en oeuvre un cadencement qui définit un cycle réseau pour la transmission de données sur ledit réseau, le cycle réseau comprenant une pluralité de premiers canaux 20 virtuels permettant la transmission de données synchrones et au moins un second canal virtuel permettant la transmission d'un premier type de paquets de données asynchrones, ledit procédé étant effectué par le noeud récepteur et caractérisé en ce qu'il comprend les étapes suivantes : 25 - réception (657) d'un symbole de début de paquet asynchrone (304), comprenant un identifiant de symbole (307) et un champ utile contenant un en- tête (400) d'un second type de paquet de données asynchrones et au moins une partie d'un ensemble de données utiles asynchrones dudit second type de paquet de données asynchrones, ledit symbole de début de paquet asynchrone 30 étant transmis par un noeud émetteur (la) sur ledit second canal virtuel ; - - - -5.- sur réception dudit symbole de début de paquet asynchrone (304), première détection, permettant de détecter une réception en cours d'un premier type de paquet de données asynchrones sur ledit second canal virtuel ; - en cas de première détection positive, interruption (673) de la réception dudit premier type de paquet de données asynchrones ; - extraction, dudit symbole de début de paquet asynchrone (304), de l'en-tête (400) et de ladite au moins une partie d'un ensemble de données utiles asynchrones dudit second type de paquet de données asynchrones. 6. Procédé de réception selon la revendication 5, caractérisé en ce qu'il comprend les étapes suivantes : - lecture, dans l'en-tête (400), de la taille dudit second type de paquet de données asynchrones ; - si la taille dudit second type de paquet de données asynchrones est supérieure à la taille du champ utile dudit symbole de début de paquet asynchrone (304) : - réception dudit symbole de début de paquet asynchrone (304) sur ledit second canal virtuel, pendant un premier cycle réseau, ledit symbole de début de paquet asynchrone (304) comprenant, dans le champ utile dudit symbole, un premier segment d'une séquence de segments, issue de la segmentation dudit second type de paquet de données asynchrones, ledit premier segment ayant une taille inférieure ou égale à la taille du champ utile dudit symbole de début de paquet asynchrone (304) ; - extraction, dudit symbole de début de paquet asynchrone (304), dudit premier segment ; - réception d'au moins un conteneur de données asynchrones (303) sur ledit second canal virtuel, pendant un cycle réseau postérieur audit premier cycle réseau, chaque conteneur de données asynchrones (303) comprenant un identifiant de conteneur de données (307) et un champ utile contenant un second segment de ladite séquence, ledit second segment ayant une taille inférieure ou égale à la taille du champ utile 20 25 30dudit conteneur de données asynchrones (303) ; - extraction, de chaque conteneur de données asynchrones (303), dudit second segment ; - reconstruction dudit second type de paquet de données asynchrones, par concaténation des premier et second(s) segments extraits. 7. Procédé de réception selon l'une quelconque des revendications 5 et 6, caractérisé en ce que le noeud récepteur effectue une étape de reprise de la réception, sur ledit second canal virtuel, dudit premier type de paquet de données asynchrones interrompu, après que le second type de paquet de données asynchrones a été entièrement reçu sur ledit second canal virtuel. 8. Procédé de réception selon l'une quelconque des revendications 5 à 7, caractérisé en ce qu'il comprend les étapes suivantes : - deuxième détection, permettant de détecter une réception en cours d'un autre second type de paquet de données asynchrones sur ledit second canal virtuel, ledit autre second type de paquet de données asynchrones étant distinct du second type de paquet de données asynchrones dont l'en-tête (400) est compris dans le champ utile du symbole de début de paquet asynchrone (304) reçu ; - en cas de deuxième détection positive, détermination d'un canal virtuel sélectionné, par ledit noeud émetteur (la), parmi ladite pluralité de canaux non réservés ; - interruption de la réception de données synchrones sur le canal virtuel déterminé ; - réception d'un symbole de début de paquet asynchrone (304) sur ledit canal virtuel déterminé, ledit symbole de début de paquet asynchrone (304), comprenant un identifiant de symbole (307) et un champ utile contenant l'en-tête (400) et au moins une partie de l'ensemble de données utiles asynchrones dudit second type de paquet de données asynchrones. 9. Procédé de réception selon la revendication 8, caractérisé en ce qu'il comprend les étapes suivantes : - lecture, dans l'en-tête (400), de la taille dudit second type de paquet de donnéesasynchrones ; - si la taille dudit second type de paquet de données asynchrones est supérieure à la taille du champ utile dudit symbole de début de paquet asynchrone (304) : - réception dudit symbole de début de paquet asynchrone (304) sur ledit canal déterminé, pendant un premier cycle réseau, ledit symbole de début de paquet asynchrone (304) comprenant, dans le champ utile dudit symbole, un premier segment d'une séquence de segments, issue de la segmentation dudit second type de paquet de données asynchrones, ledit premier segment ayant une taille inférieure ou égale à la taille du champ utile dudit symbole de début de paquet asynchrone (304) ; - extraction, dudit symbole de début de paquet asynchrone (304), dudit premier segment ; - réception d'au moins un conteneur de données asynchrones (303) sur ledit canal déterminé, pendant un cycle réseau postérieur audit premier cycle réseau, chaque conteneur de données asynchrones (303) comprenant un identifiant de conteneur de données (307) et un champ utile contenant un second segment de ladite séquence, ledit second segment ayant une taille inférieure ou égale à la taille du champ utile 20 dudit conteneur de données asynchrones (303) ; - extraction, de chaque conteneur de données asynchrones (303), dudit second segment ; - reconstruction dudit second type de paquet de données asynchrones, par concaténation des premier et second(s) segments extraits. 25 10. Produit programme d'ordinateur, téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, caractérisé en ce qu'il comprend des instructions de code de programme pour la mise en oeuvre du procédé d'émission selon l'une au moins des revendications 1 à 4 et/ou du procédé de réception selon l'une au moins des 30 revendications 5 à 9, lorsque ledit programme est exécuté sur un ordinateur. 10 1511. Moyen de stockage, éventuellement totalement ou partiellement amovible, lisible par un ordinateur, stockant un jeu d'instructions exécutables par ledit ordinateur pour mettre en oeuvre le procédé d'émission selon l'une au moins des revendications 1 à 4 et/ou le procédé de réception selon l'une au moins des revendications 5 à 9. 12. Noeud émetteur (la) comprenant des moyens de transmission de données vers au moins un noeud récepteur (2a) dans un réseau de communication synchrone (2000), ledit réseau comprenant une pluralité de noeuds et mettant en oeuvre un cadencement qui définit un cycle réseau pour la transmission de données sur ledit réseau, le cycle réseau comprenant une pluralité de premiers canaux virtuels permettant la transmission de données synchrones et au moins un second canal virtuel permettant la transmission d'un premier type de paquets de données asynchrones, caractérisé en ce que le noeud émetteur comprend : - des premiers moyens de détection permettant de détecter une requête de transmission d'un second type de paquet de données asynchrones sur ledit second canal virtuel ; - des deuxièmes moyens de détection permettant de détecter une transmission en cours d'un premier type de paquet de données asynchrones sur ledit second canal virtuel ; - des moyens de construction d'un symbole de début de paquet asynchrone (304), ledit symbole de début de paquet asynchrone comprenant un identifiant de symbole (307) et un champ utile (308) contenant un en-tête (400) dudit second type de paquet de données asynchrones et au moins une partie d'un ensemble de données utiles asynchrones dudit second type de paquet de données asynchrones; - des moyens d'interruption de la transmission dudit premier type de paquet de données asynchrones par insertion dudit symbole de début de paquet asynchrone dans ledit second canal virtuel ; - des moyens de transmission dudit symbole de début de paquet asynchrone sur ledit second canal virtuel. 13. Noeud émetteur selon la revendication 12, caractérisé en ce qu'il comprend :- des moyens de lecture, dans l'en-tête (400), de la taille dudit second type de paquet de données asynchrones ; - des moyens de segmentation dudit second type de paquet de données asynchrones en une séquence de segments comprenant : un premier segment ayant une taille inférieure ou égale à la taille du champ utile dudit symbole de début de paquet asynchrone (304), et au moins un second segment ayant une taille inférieure ou égale à la taille d'un champ utile d'un conteneur de données asynchrones (303) ; en ce que lesdits moyens de construction dudit symbole de début de paquet asynchrone (304) comprennent des moyens d'insertion du premier segment de ladite séquence dans le champ utile dudit symbole de début de paquet asynchrone (304), en ce que le noeud émetteur comprend en outre des moyens de construction d'au moins un conteneur de données asynchrones (303), chaque conteneur de données asynchrones (303) comprenant un identifiant de conteneur de données (307) et un champ utile contenant un second segment de ladite séquence, en ce que lesdits moyens de transmission transmettent ledit symbole de début de paquet asynchrone (304) sur ledit second canal virtuel, pendant un premier cycle réseau, et en ce que le noeud émetteur comprend des moyens de transmission dudit au moins un conteneur de données asynchrones (303) sur ledit second canal virtuel, chaque conteneur de données asynchrones (303) étant transmis pendant un cycle réseau postérieur audit premier cycle réseau. 14. Noeud émetteur selon l'une quelconque des revendications 12 et 13, caractérisé en ce qu'il comprend des moyens de reprise permettant la reprise de la transmission, sur ledit second canal virtuel, dudit premier type de paquet de données asynchrones interrompu, après que le second type de paquet de données asynchrones a été entièrement transmis sur ledit second canal virtuel. 15. Noeud émetteur selon l'une quelconque des revendications 12 à 14, caractérisé en ce qu'il comprend : - des troisièmes moyens de détection permettant de détecter une transmission en cours d'un autre second type de paquet de données asynchrones sur leditsecond canal virtuel, ledit autre second type de paquet de données asynchrones étant distinct du second type de paquet de données asynchrones faisant l'objet de ladite requête de transmission ; des moyens de sélection d'un canal virtuel parmi ladite pluralité de premiers canaux virtuels ; des moyens de construction d'un symbole de début de paquet asynchrone (304), comprenant un identifiant de symbole (307) et un champ utile contenant l'en-tête (400) et au moins une partie de l'ensemble de données utiles asynchrones dudit second type de paquet de données asynchrones ; des moyens d'interruption de la transmission de données synchrones sur le canal virtuel sélectionné par insertion dudit symbole de début de paquet asynchrone (304) dans ledit canal sélectionné ; des moyens de transmission dudit symbole de début de paquet asynchrone (304) sur ledit canal sélectionné. Noeud récepteur (2a) comprenant des moyens de réception de données dans un réseau de communication synchrone (2000), ledit réseau comprenant une pluralité de noeuds et mettant en oeuvre un cadencement qui définit un cycle réseau pour la transmission de données sur ledit réseau, le cycle réseau comprenant une pluralité de premiers canaux virtuels permettant la transmission de données synchrones et au moins 20 un second canal virtuel permettant la transmission d'un premier type de paquets de données asynchrones, caractérisé en ce que le noeud récepteur comprend : - des moyens de réception d'un symbole de début de paquet asynchrone (304), ledit symbole de début de paquet asynchrone (304) comprenant un identifiant 25 de symbole (307) et un champ utile contenant un en-tête (400) d'un second type de paquet de données asynchrones et au moins une partie d'un ensemble de données utiles asynchrones dudit second type de paquet de données asynchrones, ledit symbole de début de paquet asynchrone étant transmis par un noeud émetteur (la) sur ledit second canal virtuel ; 30 - des premiers moyens de détection permettant de détecter une réception en - - - - 16.cours d'un premier type de paquet de données asynchrones sur ledit second canal virtuel ; - des moyens d'interruption de la réception dudit premier type de paquet de données asynchrones; - des moyens d'extraction permettant d'extraire, dudit symbole de début de paquet asynchrone (304), l'en-tête (400) et ladite au moins une partie d'un ensemble de données utiles asynchrones dudit second type de paquet de données asynchrones. 17. Noeud récepteur selon la revendication 16, caractérisé en ce qu'il comprend : - des moyens de lecture, dans l'en-tête (400), de la taille dudit second type de paquet de données asynchrones ; - des moyens de réception permettant de recevoir ledit symbole de début de paquet asynchrone (304) sur ledit second canal virtuel, pendant un premier cycle réseau, ledit symbole de début de paquet asynchrone (304) comprenant, dans le champ utile dudit symbole, un premier segment d'une séquence de segments, issue de la segmentation dudit second type de paquet de données asynchrones, ledit premier segment ayant une taille inférieure ou égale à la taille du champ utile dudit symbole de début de paquet asynchrone (304) ; - des moyens d'extraction permettant d'extraire, dudit symbole de début de paquet asynchrone (304), ledit premier segment ; - des moyens de réception permettant de recevoir au moins un conteneur de données asynchrones (303) sur ledit second canal virtuel, pendant un cycle réseau postérieur audit premier cycle réseau, chaque conteneur de données asynchrones (303) comprenant un identifiant de conteneur de données (307) et un champ utile contenant un second segment de ladite séquence, ledit second segment ayant une taille inférieure ou égale à la taille du champ utile dudit conteneur de données asynchrones (303) ; - des moyens d'extraction permettant d'extraire, de chaque conteneur de données asynchrones (303), ledit second segment ; - des moyens de reconstruction dudit second type de paquet de donnéesasynchrones, par concaténation des premier et second(s) segments extraits. 18. Noeud récepteur selon l'une quelconque des revendications 16 et 17, caractérisé en ce qu'il comprend des moyens de reprise permettant la reprise de la réception, sur ledit second canal virtuel, dudit premier type de paquet de données asynchrones interrompu, après que le second type de paquet de données asynchrones a été entièrement reçu sur ledit second canal virtuel. 19. Noeud récepteur selon l'une quelconque des revendications 16 à 18, caractérisé en ce qu'il comprend : - des deuxièmes moyens de détection permettant de détecter une réception en cours d'un autre second type de paquet de données asynchrones sur ledit second canal virtuel, ledit autre second type de paquet de données asynchrones étant distinct du second type de paquet de données asynchrones dont l'en-tête (400) est compris dans le champ utile du symbole de début de paquet asynchrone (304) reçu ; - des moyens de détermination d'un canal virtuel sélectionné, par ledit noeud émetteur (la), parmi ladite pluralité de premiers canaux virtuels ; - des moyens d'interruption de la réception de données synchrones sur le canal virtuel déterminé ; - des moyens de réception permettant de recevoir un symbole de début de paquet asynchrone (304) sur ledit canal virtuel déterminé, ledit symbole de début de paquet asynchrone (304), comprenant un identifiant de symbole (307) et un champ utile contenant l'en-tête (400) et au moins une partie de l'ensemble de données utiles asynchrones dudit second type de paquet de données asynchrones. 20. Noeud récepteur selon la revendication 19, caractérisé en ce qu'il comprend : - des moyens de lecture, dans l'en-tête (400), de la taille dudit second type de paquet de données asynchrones ; - des moyens de réception permettant de recevoir ledit symbole de début de paquet asynchrone (304) sur ledit canal déterminé, pendant un premier cycle réseau, ledit symbole de début de paquet asynchrone (304) comprenant, dans le 5 10 15champ utile dudit symbole, un premier segment d'une séquence de segments, issue de la segmentation dudit second type de paquet de données asynchrones, ledit premier segment ayant une taille inférieure ou égale à la taille du champ utile dudit symbole de début de paquet asynchrone (304) ; - des moyens d'extraction permettant d'extraire, dudit symbole de début de paquet asynchrone (304), ledit premier segment ; - des moyens de réception permettant de recevoir au moins un conteneur de données asynchrones (303) sur ledit canal déterminé, pendant un cycle réseau postérieur audit premier cycle réseau, chaque conteneur de données asynchrones (303) comprenant un identifiant de conteneur de données (307) et un champ utile contenant un second segment de ladite séquence, ledit second segment ayant une taille inférieure ou égale à la taille du champ utile dudit conteneur de données asynchrones (303) ; - des moyens d'extraction permettant d'extraire, de chaque conteneur de données asynchrones (303), ledit second segment ; - des moyens de reconstruction dudit second type de paquet de données asynchrones, par concaténation des premier et second(s) segments extraits.