Brevet FR2841669A1 — publié le 20040102

PROCEDE DE TRANSMISSION DE PAQUETS DE DONNEES ENTRE DEUX UNITES ESCLAVES ET UNE UNITE MA TRE COMPRENANT DEUX PROCESSEURS La présente invention concerne un procédé de transmission de paquets de données par radio au sein d'un réseau local comprenant au moins deux unités de communication esclaves et une unité de communication maître par laquelle transitent tous les paquets de données transmis au sein du réseau. Elle concerne plus particulièrement un tel procédé adapté à une configuration de l'unité maître selon laquelle celle-ci comprend deux processeurs reliés entre eux par une interface interne. Il est connu d'utiliser une structure en étoile pour la transmission de données au sein d'un réseau comprenant au moins trois unités de communication. Une telle structure est particulièrement adaptée pour des réseaux comprenant un nombre réduit d'unités en communication les unes avec les autres. Dans une telle structure de réseau, l'une des unités joue un rôle de coordonnateur auquel sont asservies les autres unités. Toutes les données destinées à être transmises entre deux unités quelconques d'un tel réseau sont d'abord reçues par l'unité maître qui ré- émet ensuite à destination de l'une des unités esclaves les données initialement destinées à cette dernière. Il est par ailleurs souvent avantageux de répartir, au sein d'une unité de communication, les fonctions exécutées par cette unité entre deux processeurs reliés entre eux par une connexion interne à l'unité. Le premier processeur peut être plus spécialement adapté pour l'exécution d'une application particulière. Pour cela, il peut comporter des moyens spécifiquement appropriés pour l'exécution du programme de cette application, tels que des éléments de mémoire déterminés ou un contrôleur déterminé d'interfaces de saisie d'entrées et/ou de présentation de données destinées à un utilisateur de l'unité. Le second processeur exécute des opérations dites de bas niveau nécessaires pour la transmission de données entre cette unité de - 2 communication et une unité extérieure appartenant au réseau. Il configure notamment les données sous une forme adaptée à leur transmission, telle que, notamment, une répartition des données dans des paquets adaptés au type de transmission utilisé entre les différentes unités de communication. Il commande en outre un émetteur-récepteur de signaux échangés avec les unités de communication extérieures. Un tel modèle de second processeur peut être commun à toutes les unités de communication fonctionnant selon un même mode de transmission. Il en résulte une réduction du cot du second processeur, par effet d'échelle pour sa fabrication. Par contre, ce second processeur peut être associé dans une même unité à un premier processeur de ^ade variable en fonction de l'application principale destinée à être exécutée dans cette unité. Une spécialisation de chaque unité de communication est ainsi possible, tout en bénéficiant de la réduction de cot liée au second processeur. On considère dans la suite une répartition des fonctions entre les deux processeurs d'une unité de communication selon laquelle l'application exécutée par le premier processeur gère la transmission des données relatives à cette application au sein de l'ensemble du réseau. En particulier, la transmission de données entre deux unités esclaves est contrôlée par l'application elle-même, qui remplit une fonction de pivot de retransmission de données à destination d'une unité esciave, en fonction de l'uniié destinataire identifiée pour ces données. Un tel rôle est couramment dévolu au programme d'application résidant dans l'unité maître, du fait qu'il est seul capable d'interpréter toutes les données qui se rapportent à l'application et, par conséquent, de déterminer si un traitement doit être appliqué à ces données ou si celles-ci doivent être retransmises sans modifications à l'une des unités esclaves. Toutes les données échangées entre deux unités quelconques du réseau sont donc transmises au premier processeur de l'unité maître par la connexion entre les deux processeurs interne à cette unité. Il en résulte une consommation d'énergie liée à cette transmission interne, d'autant plus notable que la quantité de données échangées au sein du réseau est considérable. -3 Dans le cas o l'unité maître possède une source d'alimentation autonome, de type piles ou batteries, son autonomie est alors réduite du fait de la transmission en interne d'une quantité importante de données. Un autre inconvénient de la transmission d'une quantité importante de données entre les deux processeurs de l'unité maître réside dans la nécessité d'équiper la connexion interne de transmission entre les deux processeurs d'une mémoire tampon suffisante. Outre le cot de cette mémoire tampon, celle-ci engendre encore une consommation d'énergie supplémentaire. Un but de la présente invention consiste à pallier les inconvénients précités. L'invention concerne donc un procédé de transmission de paquets de données par radio au sein d'un réseau local comprenant au moins trois unités de communication, l'une de ces unités ayant un rôle d'unité maître et les autres unités ayant un rôle d'unités esclaves coordonnées par l'unité maître, l'unité 1 5 maître comprenant un premier et un second processeurs reliés entre eux par une connexion interne à l'unité maître. Le premier processeur exécute une application et le second processeur exécute des opérations de transmission de données entre l'unité maître et l'une quelconque des unités esclaves. Selon l'invention, le procédé comprend les étapes suivantes pour la transmission de données produites par une première unité esclave à destination d'une seconde unité esclave: aémission de premiers paquets de données par la première unité esclave; bréception des premiers paquets de données par l'unité maître; c- analyse par le second processeur d'éléments d'adressage associés aux premiers paquets de données pour déterminer si certains éléments d'adressage satisfont une condition spécifiée dans une consigne de réadressage; et dsi la condition est satisfaite, émission par l'unité maître à destination de la seconde unité esclave de seconds paquets de données correspondant aux premiers paquets de données. Outre la réduction précitée de la consommation énergétique de l'unité - 4 maître, un avantage du procédé de l'invention réside dans une réduction de la durée de transmission entre deux unités esclaves. En effet, de telles données ne transitent plus par le premier processeur de l'unité maître, ce qui supprime par conséquent les délais liés à la transmission entre les deux processeurs de l'unité maître. Parmi les délais supprimés figurent ceux des étapes de mise en forme des données pour la transmission entre les deux processeurs, d'attente des données dans une mémoire tampon avant cette transmission, ainsi que de traitement des données par l'application au sein du premier processeur. Dans le mode de mise en oeuvre préféré de l'invention, si certains des éléments d'adressage analysés ne satisfont pas la condition spécifiée, le second processeur transmet au premier processeur par la coni-iex on Interne à l'unité maître, lors de l'étape d, une partie au moins des données correspondant aux premiers paquets auxquels sont associés ces éléments d'adressage. Ainsi, le procédé de l'invention n'entrave pas l'accès au programme d'application de l'unité maître, pour des données qui sont destinées à ce programme en provenance de l'une quelconque des unités esclaves. Le second processeur possède par conséquent une fonction d'aiguillage des données correspondant à tous les premiers paquets reçus par l'unité maître, soit à destination d'une unité esclave sous forme de seconds paquets ré-émis, soit à destination du premier processeur par la connexion interne à l'unité maître L'application exécutée dans le premier processeur de l'unité maître, en tant que programme assurant le contrôle des données échangées entre les différentes unités, associe des éléments d'adressage entre eux, à partir desquels est produite la consigne de réadressage. Ces éléments d'adressage associés entre eux sont transmis au second processeur par la connexion interne à l'unité maître. Ils peuvent être obtenus par une interrogation spécifique des unités esclaves par l'unité maître. Ils peuvent aussi être lus par le second processeur dans des paquets de signalisation échangés lors d'établissements de connexions entre des unités esclaves et l'unité maître. Cette consigne de ré-adressage possède deux fonctions. D'une part elle spécifie des critères de sélection mis en oeuvre par le second processeur - 5 pour trier parmi tous les paquets de données reçus par l'unité maître de la part des unités esclaves ceux qui sont destinés à une autre unité esclave, sans traitement intermédiaire par le programme d'application résidant dans l'unité maître. Cette sélection est opérée sur la base de la condition spécifiée dans la consigne de ré-adressage et portant sur certains des éléments d'adressage associés aux paquets. Ces éléments d'adressage peuvent être déterminés par le second processeur d'après des paramètres particuliers de transmission tels que, par exemple, une référence de canal logique. Ils peuvent aussi être lus dans certains au moins des paquets de données reçus par l'unité maître de la part des unités esclaves, soit au niveau d'une en-tête des ces paquets, soit dans les données transportées par ces paquets. Dans ce dernier cas, la consigne de ré-adressage contient une indication de l'emplacement des éléments d'adressage concernés au sein des paquets de données. Le ou les éléments d'adressage lus dans les paquets de données reçus peuvent être, en particulier, un indicateur de l'unité de communication destinataire de données contenues dans ces paquets reçus. Selon certains mode de communication, des données d'une même session de communication entre deux unités sont contenues dans une série de paquets de données successivement émis par une première unité productrice des données, et une partie au moins des éléments d'adressage associés à tous les paquets de la série est portée nWr le prenmier paquet de!adite série. Dans ce cas, le second processeur détermine d'après le premier paquet, en fonction de la consigne et de la condition de ré-adressage, le traitement à appliquer individuellement à l'ensemble des paquets de données de la série. La seconde fonction de la consigne de ré-adressage consiste à spécifier le mode de construction des seconds paquets de données émis lors de l'étape d correspondant à des premiers paquets de données dont les éléments d'adressage satisfont la condition de ré-adressage. Les seconds paquets de données peuvent, par exemple, être directement obtenus par le second processeur à partir des premiers paquets de données auxquels ils correspondent individuellement en remplaçant, pour certains au moins des premiers paquets, des éléments d'adressage initiaux par des éléments d'adressage correspondant à l'unité esclave destinataire des données. - 6 L'invention concerne aussi un système de transmission de paquets de données adapté pour la mise en oeuvre d'un procédé de transmission tel que décrit précédemment. L'invention concerne encore un processeur de contrôle d'une transmission de données par radio sous forme de paquets comprenant une interface permettant de connecter ledit processeur de contrôle à un processeur hôte d'une application de traitement de données, et comprenant en outre: - des moyens de réception par l'interface de connexion de signaux correspondant à des éléments d'adressage associés entre eux; - des moyens d'élaboration d'une consigne de ré-adressage à partir des éléments d'adressage associés entre eux, la zcnsn, de ré adressage comprenant une condition de réadressage; - des moyens d'enregistrement de la consigne de ré-adressage; des moyens d'analyse de paquets de données reçus en fonction de la condition de ré-adressage; - des moyens de remplacement d'éléments d'adressage initiaux de certains au moins des paquets de données reçus satisfaisant la condition de ré-adressage par de nouveaux éléments d'adressage déterminés d'après la consigne de ré-adressage; et - des moyens de commande d'une émission de paquets de données correspondant aux paquets de données reçus satisfaisant la condition de ré-adressage. Les éléments d'adressage remplacés peuvent comprendre, en particulier, un indicatif de connexion et/ou une référence de canal logique. Eventuellement, le processeur de contrôle peut comprendre en outre des moyens de lecture dans certains au moyens des paquets reçus d'une référence de canal logique et/ou d'un indicateur de l'unité de communication destinataire des données contenues dans les paquets reçus. Il peut comprendre encore des moyens de transmission par l'interface de connexion de données correspondant à des paquets reçus ne satisfaisant pas la condition de ré-adressage. L'invention concerne en outre une unité de communication par radio -7 comprenant un tel processeur de contrôle. Elle concerne enfin un processeur hôte d'au moins une application comprenant des moyens d'exécution de l'application, des moyens de gestion de communications au sein d'un réseau local en tant qu'unité maître, et des moyens pour associer des éléments d'adressage de paquets de données entre eux, ce processeur hôte comprenant en outre une interface de connexion d'un processeur de contrôle d'une transmission de paquets de données au sein du réseau local, et des moyens de transmission par l'interface de connexion de signaux correspondant aux éléments d'adressage associés entre eux ou porteurs de données traitées par l'application. D'autres particularités et avantages de la présente invention apparaîtront dans la description ci-après d'un exemple de mise en oeuvre non limitatif, en référence aux dessins annexés, dans lesquels: - la figure 1 représente un réseau local auquel s'applique l'invention; - la figure 2 illustre la structure de protocoles d'une unité maître à laquelle s'applique l'invention; - la figure 3 représente une structure de paquets de données échangés entre les deux processeurs de l'unité maître de la figure 2; - la figure 4 illustre la structure de protocoles d'un processeur de contrôle selon l'invention. L'invention est maintenant décrite en détail pour un réseau de transmission conforme à la norme "Bluetooth T", bien connue de l'Homme du métier. La norme Bluetooth concerne en particulier la transmission de données entre plusieurs unités de communication formant un réseau local, appelé "siQnet". Ce réseau, dans le mode de fonctionnement considéré dans la suite, comprend une unité maître telle qu'introduite précédemment, et au plus sept unités esclaves coordonnées par l'unité maître. Selon une particularité des des "piconets" spécifiée par la norme Bluetooth, toutes les unités de communication d'un "piconet" sont interchangeables vis-àvis des rôles d'unité maître ou esclave. Pour cela, chaque unité de communication incorpore des - 8 moyens pour coordonner des communications au sein du "piconet" et des moyens pour fonctionner de façon coordonnée par une unité maître extérieure, ces moyens étant alternativement activés en fonction de l'unité de communication ayant le rôle d'unité maître. La figure 1 représente trois unités d'un même "piconet", parmi lesquelles l'unité 1 remplit la fonction du maître. Ce rôle est attribué à l'unité 1 dans toute la suite. Les unités 100 et 200 sont esclaves. Chaque unité 1, 100, peut être de type varié, tel que, par exemple, une unité informatique, une console de jeux, un clavier, un écran de visualisation, une imprimante, un instrument domotique, un terminal de communication, etc. Il contient au moins un programme applicatif, ou programme d'application, permettant en particuler à cette unité de remplir sa fonction principale, à savoir un traitement de données pour une unité informatique ou une console de jeux, une saisie de données pour un clavier, un affichage de données pour un écran, une impression pour une imprimante, etc. De façon usuelle dans le domaine des communications, chaque unité est conçue conformément à une pile de protocoles lui permettant d'échanger des données de façon compatible avec les autres unités du "piconet". Parmi ces protocoles peuvent figurer, par exemple: un protocole de commande d'émission et de réception RF, correspondant aux couches 105 et 205 respectivement pour les unités 100 et ; - un protocole d'exécution d'opérations dites de bas niveau de transmission (ou "baseband"), tel que le protocole "Link Controller" (ou LC) connu de l'Homme du métier, et correspondant aux couches 106 et 206 pour les unités 1 00 et 200; - un protocole d'initialisation et de gestion des communications entre les unités du "piconet" correspondant aux couches 107 et 207, tel que, par exemple, le protocole "Link Manager" (ou LM) aussi connu de l'Homme du métier; - un protocole de multiplexage des signaux destinés, notamment, à des applications différentes. Ce peut être le protocole "Logical Link Control and Adaptation Protocol" (ou L2CAP), encore connu de l'Homme du métier. Les -9 couches 110 et 210 du protocole L2CAP assurent en outre, notamment, la mise sous forme de paquets des données destinées à être transmises, ou, à l'inverse, le regroupement de données reçues dans des paquets successifs; et - au moins un programme d'application 111, 211 résidant dans chaque unité. Ces programme d'applications sont les destinataires finals des données échangées au sein du "piconet". Plusieurs unités échangeant des données relatives à une application déterminée doivent contenir chacun un programme de cette application afin de produire, interpréter et traiter les données échangées dans le cadre de cette application. Chaque application est identifiée par une valeur spécifique d'un indicateur d'application appelé "Protocoi Service Multiplexer" les données. Deux structures sont possibles pour chaque unité de communication. Dans l'une de ces structures, couramment désignée par "embedded", les opérations de tous les protocoles cités précédemment ainsi que celles des programmes d'applications sont exécutées dans un processeur unique de l'unité. Les unités 100 et 200 de la figure J pousèdent cette structurd. Pour la mise en oeuvre de l'invention, l'unité maître 1 possède une structure différente, à deux processeurs, détaillée à la figure 2. Un premier processeur 2, appelé hôte (ou "host processor"), héberge au moins un programme d'une application 11 supportée par l'unité 1, ainsi que le protocole L2CAP 10. Un second processeur 3, dit processeur de contrôle (ou "host controller processor"), héberge les couches dites de niveaux inférieurs correspondant aux opérations relatives à la transmission radio, à savoir les couches 5, 6, et 7 respectivement des protocoles RF, LC et LM. Dans cette structure à deux processeurs, les processeurs 2 et 3 sont connectés entre eux pour échanger des données au travers d'une connexion 4 interne à l'unité 1. Cette connexion 4 peut être de différents types, tels que, par exemple, une connexion USB ("Universal Serial Bus") ou une connexion UART ("Universal Asynchronous Receiver Transceiver"). Elle correspond aux interfaces d'échange de données 4b et 4a des processeurs 2 et 3 respectivement. Deux couches 8 et 9 d'un protocole supplémentaire, pouvant être le protocole "Host Controller Interface" (ou HCI), connu de l'Homme du métier, assurent au sein de chaque processeur 2, 3 la mise en forme et le rétablissement des données échangées par leurs interfaces respectives 4b et 4a. La couche 8 portée par le processeur de contrôle 3 est appelée "HCI firmware" et la couche 9 portée par le processeur hôte 2 est appelée "HCI driver". Les données échangées par la connexion interne 4 sont réparties dans des paquets de données spécifiques, appelés paquets HCI. L'échange de données entre des unités distinctes du "piconet" est effectué sous forme de paquets de données transmis par radio, en utilisant la bande de fréquence 2400 - 2483,5 MégaHertz, par exemple. En relation avec la norme Bluetooth, on se restreint dans la suite à un mode de communication asynchrone ("Asynchronous Connection-Less link" ou ACL) entre les différentes unités du "piconet". Ce mode est particulièrement adapté à la transmission de données, pouvant être éventuellement des données audio ou vidéo, par opposition à une transmission de parole. Dans le fonctionnement du "piconet" considéré, tous les paquets de données émis par une unité quelconque du réseau sont destinés à une autre unité déterminée du réseau. Ce fonctionnement est qualifié de "point à point". Pour cela, des éléments d'adressage sont associés à chaque paquet de données transmis qui permettent de déterminer l'unique unité destinataire des données de ce paquet. D'après la structure de communication en étoile au sein d'un "piconet", avec un rôle d'aiguilleur des données pour l'unité maître au centre le l'étoile, des paquets de données émis par une unité esclave sont systématiquement adressés en premier lieu à l'unité maître. Le programme d'application résidant dans l'unité maître doit alors déterminer si ces données lui sont destinées ou si elles sont destinées au programme d'application résidant dans l'une des autres unités esclaves. - 11 On suppose qu'une liaison ACL est établie entre l'unité maître 1 et l'unité esclave 100 d'une part, et entre l'unité maître 1 et l'unité esclave 200 d'autre part. Les trois unités sont par conséquent dans un état d'attente de réception de données, couramment qualifié d'état "open" par l'Homme du métier. A partir de cet état, l'unité esclave 100 peut émettre des données à destination soit de l'unité maître 1, soit de l'unité esclave 200. Dans les deux cas, ces données sont transmises sous forme de paquets reçus dans un premier temps par le processeur de contrôle 3 de l'unité maître 1 qui doit en transmettre le contenu soit au processeur hôte 2 par la connexion interne 4, soit à l'unité esclave 200 par une seconde émission radio. La figure 3 représente unÙ structure d'un paquet de données 80 émis par l'unité esclave 100 au niveau de la couche de protocole L2CAP 110. De façon connue, ce paquet de données 80 peut posséder les champs suivants: un champ 83 de données (ou "payload"), par exemple limité à 65533 octets, dédié à des données destinées à être traitées par le programme d'application 11 de l'unité maître 1 ou par celui 211 de l'unité esclave 200 - un champ 81 indiquant la longueur en bytes du champ 83; et - un champ 82 de deux octets contenant une référence de canal logique ("Channel IDentifier" ou CID) attribué par le programme d'application 11 du maître 1 à des paquets de données 80 émis par l'esclave 100. Plusieurs CID distincts peuvent être ieutés par te- programme d'application 11 identifié par l'indicateur PSM pour des paquets de données L2CAP émis par l'unité esclave 100. Dans ce cas, deux CID différents peuvent être utilisés de façon à distinguer des paquets émis par l'unité esclave 100 contenant des données destinées au programme d'application 11 de l'unité maître 1 d'une part, de paquets émis par l'unité esclave 100 contenant des données destinées au programme d'application 211 de l'unité esclave 200 d'autre part. Dans ce cas, la détermination du CID des paquets de données L2CAP au niveau du processeur de contrôle 3 permet d'orienter les données contenues par ceux-ci soit vers le processeur hôte 2 par la connexion interne 4, soit pour une ré-émission par radio à destination de l'unité esclave 200. Le programme d'application 11 identifié par l'indicateur PSM peut aussi 12 affecter le même CID à des paquets L2CAP émis par l'unité esclave 100 contenant des données destinées au programme d'application 11 du maître 1 ou au programme d'application 211 de l'unité esclave 200. Dans ce cas, pour mettre en oeuvre le procédé de l'invention, le processeur 3 est programmé pour lire dans le champ de données 83 un élément d'adressage supplémentaire permettant de différencier l'unité maître 1 de l'unité esclave 200 comme destinataire des données du paquet L2CAP. Pour être transmis par la connexion 4 entre la couche HCI "firmware" 8 hébergée par le processeur de contrôle 3 et la couche HCI "driver" 9 hébergée par le processeur hôte 2 au sein de l'unité maître 1, les paquets de données L2CAP sont découpés en segments successifs et etcipsulês dans des paquets HCI transmis un à un. De façon connue de l'Homme du métier, chaque paquet HCI 50, 60, 70 (figure 3) comprend les champs suivants: - un champ 51 de 12 bits, réservé à un indicateur de canal de transmission au niveau de la couche de protocole HCI, appelé indicatif de connexion (ou "connection handle"). L'indicatif de connexion peut être considéré comme un tunnel spécialement dédié à la transmission de paquets HCI entre deux unités de communication; - un champ 55 de données dans lequel est placé un segment de paquet de données L2CAP 80; - un champ 54 de deux hytes d'indication de la longueur des données exprimée en bytes; - un champ 53 d'un indicateur de mode de communication en diffusion ("BroadCast flag" ou BC). Ce champ contient la valeur réservée 00 pour le fonctionnement point à point considéré pour la mise en oeuvre de l'invention; et - un champ 52 d'un indicateur de poursuite d'une série de paquets HCI ("Packet Boundary" ou PB) recevant une valeur O1 ou 10 selon si le paquet HCI est ou non le premier paquet d'une série de paquets HCI transportant comme données des segments successifs d'un même paquet L2CAP. Les données émises par l'unité esclave 100 sont reçues par le processeur 3 sous forme de paquets L2CAP 80 répartis dans une série de paquets HCI successifs 50, 60, 70,... Tous les paquets HCI d'une même série, - 13 possédant la valeur 10 dans le champ PB 52 après un premier paquet HCI de la série possédant la valeur 01 dans ce champ, sont donc associés à un même canal logique caractérisé par une même valeur de CID. Le processeur 3 détermine, au niveau de la couche HCI "firmware" 8, l'orientation à affecter à chaque paquet HCI, en fonction d'éléments d'adressage associés à ce paquet HCI. Pour cela, un ensemble d'associations entre des éléments d'adressage identifiés est mémorisé au niveau de la couche HCI "firmware" 8, permettant d'orienter le contenu de chaque paquet HCI soit vers le processeur hôte 2 soit pour une réémission à destination de l'unité esclave 200. Selon un premier mode de mise en oeuvre de l'invention, cette orientation est déterminée en fonction du CID du paquet L2CAP contenu dans une série de paquets HCI 50, 60, 70,... successivement reçus. L'unité esclave et l'unité maître 1 sont alors associées à des CID respectifs distincts pourdes paquets émis par l'unité esclave 100 et contenant des données destinées soit à l'unité esclave 200 soit à l'unité maître 1. Le premier paquet HCI 50 d'une série correspondant à un paquet L2CAP donné est identifié d'après son champ PB 52, et la valeur de CID caractéristique du paquet de données L2CAP est lue dans le champ 55 de ce premier paquet HCI 50. Cette valeur de CID lue est alors automatiquement associée à tous les paquets HCI ultérieurs se rapportant au même paquet de données L2CAP, portant la valeur 10 dans leurs champs PB 52 respectifs, jusqu'à la lecture de la valeur 01 dans le champ PB 52 d'un paquet HCI marquant le début d'une nouvelle série, associée à un autre paquet de données L2CAP. Si la valeur de CID lue correspond à celle réservée à des données destinées au programme d'application 11 de l'unité maître 1, le processeur de contrôle 3 transmet tous les paquets HCI successifs 50, 60, 70,... de la série au processeur hôte 2 par la connexion interne 4. Les données de ces paquets HCI sont alors traitées de façon usuelle par les couches 9 et 10, puis par le programme d'application 11, si la valeur de PSM associée correspond au programme d'application 11. Si la valeur de CID lue correspond à celle réservée à des données - 14 destinées au programme d'application 211 de l'unité esclave 200, le processeur de contrôle 3 remplace, dans le champ 55 du premier paquet HCI de la série, la valeur de CID initiale, correspondant à des paquets transmis entre l'unité esclave 100 et l'unité maître 1 pour des données destinées à l'unité esclave 200, par la valeur de CID réservée à des paquets de données en provenance de l'unité esclave 100 et retransmis par l'unité maître 1 à l'unité esclave 200. Le PSM indiqué dans le champ 55 du premier paquet HCI 50 est inchangé. Tous les paquets HCI de la série 50, 60, 70,... sont alors successivement traités par le processeur 3 pour leur émission à destination de l'unité esclave 200, selon la valeur de CID associée au paquet L2CAP auquel ils correspondent. En particulier, l'indicatif de connexion 51 initial de chaque paquet HCI est remplacé par l'indicatif de connexion dédié à la transmission de paquets HCI de l'unité maître 1 à l'unité esclave 200. Ainsi, au niveau HCI, un paquet de données ré-émis par l'unité maître 1 à destination de l'unité esclave 200 possède une structure identique à celle d'un paquet HCI en provenance de l'unité esclave 100, hormis l'indicatif de connexion 51, et le CID 82 pour le premier paquet HCI d'une série correspondant à un paquet de données L2CAP donné. La nouvelle valeur de CID 82 est celle attribuée aux retransmissions de données en provenance de l'unité esclave 100, par l'unité maître 1 vers l'unité esclave 200. Le nouvel indicatif de connexion 51 est celui attribué aux transmissions de données ACL entre l'unité maître 1 et l'unité esclave 200. Les données 83 du paquet L2CAP 80 sont ensuite traitées par le programme d'application 211 si la valeur de PSM associée correspond au programme d'application 211. Selon un second mode de mise en oeuvre de l'invention, l'unité esclave et l'unité maître 1 sont associées à des canaux logiques 82 identiques pour des paquets émis par l'unité esclave 100 et contenant des données destinées soit à!'urn!tA esclave 200 soit à l'unité maître 1. Par conséquent, la valeur de CID lue dans le premier paquet HCI 50 de la série relative à un même paquet de données L2CAP ne permet plus de déterminer l'unité de communication du "piconet" destinataire des données. L'analyse par le processeur 3 des éléments d'adressage associés aux paquets HCI 50, 60, ,... comprend alors une lecture d'au moins un élément d'adressage supplémentaire dans certains au moins des paquets HCI pour déterminer l'unité de communication destinataire. Cet élément d'adressage lu dans le champ de données 55 du premier paquet HCI 50 de la série est un indicateur de l'unité destinataire des données. Cet indicateur peut être, par exemple, une adresse Bluetooth distinctive affectée à cette unité lors de sa fabrication (ou BDADDR) ou une adresse logique appelée "application slave identifier" (APPID) affectée par le programme d'application 11. Pour cela, la consigne de ré-adressage doit contenir une indication de l'emplacement, dans le champ de données 55, auquel se trouve l'indicateur de l'unité destinataire des données. Cette indication a la forme, par exemple, d'un nombre d'octets (connu sous l'appellation de "offset") comptés à partir du premier octet d'un paquet HCI. Afin que le processeur 3 puisse ré-orienter tous les paquets HCI d'une même série, l'indicateur de l'unité destinataire des données doit figurer dans le champ de données 55 du premier paquet HCI 50 de la série. Le processeur 3 détermine ainsi l'unité destinataire de tous les paquets HCI de la série d'après le premier paquet HCI 50 de la série, et lui adresse un par un tous les paquets HCI successifs en remplaçant dans chacun d'eux l'indicatif de connexion initial 51 par l'indicatif de connexion dédié à une transmission de l'unité maître 1 vers l'unité esclave 200. Il remplace en outre dans le premier paquet HCI 50 la valeur de CID 82 caractéristique de paquets HCI transmis de l'unité esclave 100 vers l'unité maître 1. par la valeur de CID caractéristique de paquets HCI transmis de l'unité maître 1 vers l'unité esclave 200. Ce renvoi systématique des paquets HCI 50, 60, 70,... par le processeur 3 est arrêté pour le premier paquet HCI présentant la valeur 01 dans le champ PB 52. L'analyse et la retransmission éventuelle de paquets HCI précédemment décrites peuvent être illustrées schématiquement par l'ajout d'une partie de protocole HCI à la pile de protocole hébergée par le processeur 3 (figure 4). Outre les couches de protocole représentées à la figure 2, correspondant aux fonctions connues de l'Homme du métier, la partie 8a de protocole intitulée commutation HCI (ou "HCI switching") correspond aux fonctions suivantes: - élaboration de la consigne de ré-adressage à partir d'éléments - 16 d'adressage associés entre eux reçus par l'interface 4a; mémorisation de la consigne de ré-adressage; - analyse des paquets HCI produits par la couche "HCI firmware" 8 selon la consigne de ré-adressage; et - orientation de ces paquets HCI soit vers l'interface 4a soit en vue d'un traitement correspondant à la couche LC 6. La consigne de ré-adressage comprend une table de commutation associant des éléments d'adressage finals à des éléments d'adressage initiaux figurant en entrée de la table. La condition de ré-adressage permet de déterminer si les éléments d'adressage associés à un paquet HCI donné correspondent à l'un des éléments d'adressage initiaux. Dans le cas positif, les éléments d'adressage finals indiqués par la table de commutation sont affectés au paquet HCI afin que celui-ci soit ré-émis à destination de l'unité esclave destinataire des données portées par ce paquet. Une première méthode d'actualisation de la table de commutation utilise la primitive PING connue de l'Homme du métier. Cette primitive est produite par le programme d'application 11 de l'unité maître 1 pour la couche L2CAP 10 et concerne chaque unité esclave identifiée, par exemple, par son adresse Bluetooth (BD ADDR). Cette primitive déclenche une interrogation de toutes les unités esclaves par l'unité maître 1, au niveau de la couche L2CAP. De façon connue en soi, cette interrogation peut procéder, notamment, par l'envoi par radio d'un paquet de type ECHOREQUEST à chaque unité esclave. Chaque unité esclave répond alors à l'unité maître 1 par un paquet de type ECHORESPONSE comprenant les CID affectés à l'unité maître 1 et à cette unité esclave particulière pour des paquets de données L2CAP envoyés respectivement par l'unité maître 1 à cette unité esclave et par cette unité esclave à l'unité maître 1. Ces éléments sont ensuite retransmis au programme d'application 11 de l'unité maître 1 par la primitive PING. Le programme d'application 11 de l'unité maître 1 dispose alors de tous les éléments d'adressage intervenant lors d'échanges de données se rapportant à l'application concernée, à savoir, les CID des unités 100, 200 et - 17 de l'unité maître 1 pour chaque sens de transmission, le BDADDR et le APPID de chaque unité esclave. Le programme d'application 11 envoie ensuite à la couche HCI "firmware" 8 un paquet de commande HCI spécialement dédié lors de la conception des processeurs 2 et 3. Ce paquet HCI peut être repéré par une valeur spécifique placée, par exemple, dans le champ OGF ("Opcode Group Field") de ce paquet, connu de l'Homme du métier. Ce paquet de commande HCI contient une instruction d'association entre des éléments d'adressage initiaux et finals. Une seconde méthode d'actualisation de la table de commutation peut consister en un repérage par la couche 8 de paquets de signalisation L2CAP de type CONNECTION REQUEST et CONNECTION RESPONSE uiJ5,ss loiS de l'établissement d'une connexion entre une unité esclave et l'unité maître. Ce repérage est concentré initialement sur les paquets de signalisation CONNECTION REQUEST contenant une valeur de PSM correspondant à l'application concernée. Les paquets de signalisation CONNECTION RESPONSE associés contiennent alors les CID appariés affectés à des échanges bilatéraux entre une unité esclave donnée et l'unité maître 1 pour cette application. La couche 8 adresse alors ces éléments au programme d'application 11 par un paquet HCI spécialement dédié. De la même façon que dans la première méthode d'actualisation, le programme d'application 11 retourne au processeur 3 une instruction d'assnciation d'éléments d'adressage nécessaire à l'orientation des paquets HCI 50, 60, 70,... A l'inverse, une telle association est supprimée lors du repérage par la couche 8 de paquets L2CAP de fermeture d'une connexion intervenant dans l'association. Un avantage de cette seconde méthode est d'être entièrement interne à l'unité maître 1, par opposition à la première méthode qui nécessite un échange spécifique de paquets de données entre l'unité maître 1 et les unités esclaves. La couche 8 "HCI firmware" dispose donc d'associations entre des éléments d'adressage pour chaque programme d'application 11 résidant dans le processeur hôte 2, identifié par le PSM de l'application. La consigne de réadressage élaborée à partir de ces associations comprend la table de - 18 commutation et la condition de ré-adressage. Ces éléments de la consigne de ré-adressage permettent l'élaboration, au niveau de la couche 8, d'un programme d'orientation des paquets HCI. Des lignes d'instructions de ce programme sont données ci-dessous à titre d'exemple, en référence aux figures 3 et 4, pour le traitement d'un paquet HCI ACL Data en provenance de l'esclave 100, dans le cas o des CID distincts sont utilisés pour des données destinées à l'unité esclave 200 ou à l'unité maître 1 Si PB = 01, alors lire le Local CID dans le champ de données si Local CID e liste des CID commutés, alors lire Destinataire-CID (de l'unité esclave 200) dans la table de commutation lire le BDADDR de l'unité destinataire final (de l'unité esclave 200) chercher le "connection handle (BDADDR)" construire un nouveau paquet HCI ACL Data champ 51 v- "connection handle (BDADDR)" champ 52 Fin Si. - 19 REVENDICATIONS 1. Procédé de transmission de paquets de données par radio au sein d'un réseau local comprenant au moins trois unités de communication, l'une de ces unités (1) ayant un rôle d'unité maître et les autres unités (100, 200) ayant un rôle d'unités esclaves coordonnées par l'unité maître, l'unité maître comprenant un premier (2) et un second (3) processeurs reliés entre eux par une connexion (4) interne à l'unité maître, le premier processeur exécutant une application et le second processeur exécutant des opérations de transmission de données entre l'unité maître et l'une quelconque des unités esclaves, procédé dans lequel la transmission de données produites par une première unité esclave à destination d'une seconde unité esclave comprend les étapes suivantes: aémission de premiers paquets de données (50, 60, 70) par la première unité esclave; b- réception des premiers paquets de données par l'unité maître; c- analyse par le second processeur d'éléments d'adressage associés aux premiers paquets de données pour déterminer si certains éléments d'adressage satisfont une condition spécifiée dans une consigne de réadressage; et d- si la condition est satisfaite, émission par l'unité maître à destination de la seconde unité esclave de seconds paquets de données correspondant aux premiers paquets de données. 2. Procédé selon la revendication 1, dans lequel, lors de l'étape d, si certains des éléments d'adressage analysés ne satisfont pas la condition spécifiée, le second processeur (3) transmet au premier processeur (2) une partie au moins des données correspondant aux premiers paquets de données par la connexion (4) interne à l'unité maître (1). 3. Procédé selon la revendication 1 ou 2, dans lequel la consigne de réadressage est produite à partir d'éléments d'adressage associés entre eux - 20 par l'application (11) exécutée dans le premier processeur (2), et transmis au second processeur (3) par la connexion (4) interne à l'unité maître (1). 4. Procédé selon la revendication 3, dans lequel les éléments d'adressage à partir desquels est produite la consigne de ré-adressage sont obtenus par interrogation des unités esclaves (100, 200) par l'unité maître (1). 5. Procédé selon la revendication 3, dans lequel les éléments d'adressage à partir desquels est produite la consigne de ré-adressage sont lus par le second processeur (3) dans des paquets de signalisation échangés lors d'établissements de connexions entre des unités esclaves et l'unité maître. 6. Procédé selon l'une quelconque des revendications précédentes, dans lequel les seconds paquets de données émis lors de l'étape d sont obtenus par le second processeur (3) à partir des premiers paquets de données (50, 60, 70) auxquels ils correspondent en remplaçant, pour certains au moins des premiers paquets, des éléments d'adressage initiaux par des nouveaux éléments d'adressage correspondant à la seconde unité esclave. 7. Procédé selon la revendication 6, dans lequel les éléments d'adressage remplacés comprennent un indicatif de connexion (51) dans chaque premier paquet et/ou une référence de canal logique (82). 8. Procédé selon la revendication 6 ou 7, dans lequel l'étape c d'analyse d'éléments d'adressage associés aux piei"eirs paquets (50, 60,70) de données comprend une étape de lecture d'au moins un élément d'adressage comprenant une référence de canal logique (82) dans certains au moins des premiers paquets de données. 9. Procédé selon la revendication 8, dans lequel la seconde unité esclave (200) et l'unité maître (1) sont associées à des canaux logiques respectifs distincts pour des paquets émis par la première unité esclave (100) et contenant des données destinées soit à la seconde unité esclave soit à l'unité maître, et dans lequel les nouveaux éléments d'adressage sont déterminés en utilisant la référence de canal logique lue (82). 10. Procédé selon la revendication 8, dans lequel la seconde unité esclave (200) et l'unité maître (1) sont associées à des canaux logiques - 21 identiques pour des paquets émis par la première unité esclave (100) et contenant des données destinées soit à la seconde unité esclave soit à l'unité maître, dans lequel l'étape c d'analyse d'éléments d'adressage associés aux premiers paquets (50, 60, 70) de données comprend une étape de lecture d'au moins un élément d'adressage supplémentaire comprenant un indicateur de l'unité de communication destinataire des données dans certains au moins des premiers paquets de données, et dans lequel les nouveaux éléments d'adressage sont déterminés en utilisant l'indicateur lu de l'unité de communication destinataire des données. 11. Procédé selon l'une quelconque des revendications précédentes, dans lequel les données sont contenues dans une série de prem^;,_ paquets de données (50, 60, 70) successivement émis par la première unité esclave (100), et dans lequel une partie au moins des éléments d'adressage associés aux dits premiers paquets de la série est portée par un paquet de ladite série émis avant les autres paquets de ladite série. 12. Système de transmission de paquets de données par radio comprenant au moins trois unités de communication, l'une de ces unités (1) ayant un rôle d'unité maître et les autres unités (100, 200) ayant un rôle d'unités esclaves coordonnées par l'unité maître, l'unité maître comprenant des moyens pour gérer une transmission de données échangées avec l'une Uelconque dés unités esclaves, et l'ui-nité maître comprenar,-; un premier (2) et un second (3) processeurs reliés entre eux par une connexion (4) disposée pour transmettre des données entre les deux processeurs, le premier processeur étant agencé pour exécuter une application et le second processeur étant agencé pour exécuter des opérations de transmission de données entre l'unité maître et l'une quelconque des unités esclaves, le système étant adapté pour la mise en oeuvre d'un procédé de transmission selon l'une quelconque des revendications 1 a 11. 13. Processeur de contrôle (3) d'une transmission de données par radio sous forme de paquets de données comprenant une interface (4a) permettant de connecter ledit processeur de contrôle à un processeur hôte (2) d'une application, et comprenant en outre: - 22 - des moyens de réception par l'interface de connexion (4a) de signaux correspondant à des éléments d'adressage associés entre eux; - des moyens d'élaboration d'une consigne de ré-adressage à partir des éléments d'adressage associés entre eux, la consigne de ré-adressage comprenant une condition de ré-adressage; - des moyens d'enregistrement de la consigne de ré-adressage; - des moyens d'analyse de paquets de données reçus en fonction de la condition de réadressage; - des moyens de remplacement d'éléments d'adressage initiaux de certains au moins des paquets de données reçus satisfaisant la condition de ré-adressage par de nouveaux éléments d'adressage déterminés d'après la consigne de ré-adressage; et - des moyens de commande d'une émission de paquets de données correspondant aux paquets de données reçus satisfaisant la condition de ré-adressage. 14. Processeur de contrôle selon la revendication 13, comprenant en outre des moyens de transmission par l'interface de connexion (4a) de données correspondant à des paquets reçus ne satisfaisant pas la condition de réadressage. 15. Processeur de contrôle selon la revendication 13 ou 14, dans lequel les moyens de remplacement d'éléments d'adressage comprennent des moyens de remplacement d'un indicatif de connexion (51) et/ou d'une référence de canal logique (82). 16. Processeur de contrôle selon l'une quelconque des revendications 13 à 15, comprenant des moyens de lecture dans certains au moyens des paquets reçus d'une référence de canal logique et/ou d'un indicateur de l'unité de communication destinataire des données contenues dans les paquets reçus. - 23 17. Unité de communication (1) par radio comprenant un processeur de contrôle selon l'une quelconque des revendications 13 à 16. 18. Processeur hôte (2) d'au moins une application comprenant des moyens d'exécution de l'application, des moyens de gestion de communications au sein d'un réseau local en tant qu'unité maître, et des moyens pour associer des éléments d'adressage de paquets de données entre eux, le processeur hôte comprenant en outre une interface (4b) de connexion d'un processeur de contrôle (3) d'une transmission de paquets de données au sein du réseau local, et des moyens de transmission par l'interface de connexion de signaux correspondant aux éléments d'adressage associés entre eux ou porteurs de données traitées par l'application.