FR2850232A1 - Procede de transmission entre deux processeurs d'une unite de radiocommunication - Google Patents

Abstract

Un procédé de transmission entre deux processeurs (2, 3) disposés à l'intérieur d'une unité de radiocommunication (1) et reliés entre eux par une connexion (4) interne à l'unité comprend des dispositions de détection d'erreurs de transmission. Pour cela, des codes transmis sont répartis dans des trames comprenant des indicateurs inscrits par le processeur émetteur des trames. A la réception des trames, les indicateurs sont utilisés par le processeur récepteur pour valider les trames reçues. Les codes transmis peuvent correspondre à des informations contenues dans des paquets. Les informations d'un paquet destinées à être transmises par la connexion interne (4) peuvent être placées dans une trame unique associée au paquet.

Description

PROCEDE DE TRANSMISSION ENTRE DEUX PROCESSEURS D'UNE UNITE DE

RADIOCOMMUNICATION

La présente invention concerne un procédé de transmission au sein d'une unité de radiocommunication comprenant deux processeurs reliés entre eux par une connexion interne à l'unité de radiocommunication.

On entend par unité de radiocommunication un dispositif capable d'échanger des données avec d'autres dispositifs équipés de moyens d'émission et de réception radio compatibles avec ceux de ladite unité. Une telle unité peut être, par exemple, une unité informatique, une console de jeux, 10 un clavier, un écran de visualisation, une imprimante, un instrument domotique, un terminal de communication, etc. Chacune de ces unités contient au moins un programme applicatif, ou application, permettant en particulier à 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 15 clavier, un affichage de données pour un écran, une impression pour une imprimante, etc. Il est souvent avantageux de répartir, au sein de l'unité de communication, les fonctions exécutées par cette unité entre deux processeurs reliés entre eux par une connexion interne.

Le premier processeur peut être spécialement adapté à la fonction principale de l'unité. Pour cela, il peut comporter des moyens spécifiquement appropriés pour l'exécution de l'application correspondant à cette fonction, tels que des éléments de mémoire particuliers ou un contrôleur spécifique d'interfaces de saisie d'entrées et/ou de présentation de données à un 25 utilisateur de l'unité.

Le second processeur peut exécuter des opérations, dites opération de bas niveau, nécessaires pour la transmission des données entre cette unité de radiocommunication et un dispositif extérieur. Outre la commande d'un émetteur-récepteur radio, il configure les données sous une forme adaptée à 30 leur transmission par radio, telle que, par exemple, une répartition des données dans des paquets successivement transmis. Inversement, il regroupe des données de paquets successivement reçus par radio, qui correspondent à une même session de communication.

Un tel second processeur peut être d'un modèle commun à toutes les unités de communication qui utilisent un même mode de transmission radio. Il en résulte une réduction du cot du second processeur, par effet d'échelle lors 5 de sa fabrication. Par contre, ce second processeur peut être associé dans une même unité à un premier processeur d'un modèle 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 obtenue, tout en bénéficiant de la réduction de cot liée à un modèle unique de second 10 processeur.

On considère dans la suite une telle structure d'unité de radiocommunication, ayant deux processeurs reliés entre eux par une connexion interne.

Les signaux radio émis ou reçus par l'unité provoquent des parasites 15 de nature électromagnétique qui peuvent perturber les transmissions effectuées par la connexion interne entre les deux processeurs. Des erreurs de transmission apparaissent alors lors du déchiffrage des codes transmis par la connexion interne.

Des parasites d'autres origines peuvent aussi perturber la transmission 20 des codes entre les deux processeurs, tels que, notamment, des microdécharges électriques survenant au niveau de la connexion interne. Un rapport "signal sur bruit" particulièrement faible peut par conséquent être observé sur la connexion interne.

Pour une unité alimentée par une source d'énergie autonome, de type 25 piles ou batteries, il est connu d'interrompre momentanément un fonctionnement de l'un des deux processeurs pour réduire la consommation énergétique de l'unité. Ce processeur ne reprend son fonctionnement que lorsqu'il est sollicité, notamment lorsqu'il reçoit des codes par la connexion interne en provenance de l'autre processeur. Cette reprise du fonctionnement 30 requiert souvent un délai de redémarrage, même court, durant lequel des codes reçus par la connexion interne peuvent être perdus ou entachés d'erreur.

Des erreurs de transmission entre les deux processeurs engendrent par la suite des opérations aberrantes exécutées par l'application ou des défauts de communication entre les unités reliées par radio.

Plusieurs modes de communication entre deux processeurs ont déjà été développés, qui ont notamment pour but de réduire les erreurs de transmission. Chacun de ces modes est plus spécifiquement adapté à un type particulier d'interface de communication. La plupart d'entre eux sont conformes à la norme HDLC ("High-level Data Link Control" établie par l'International 10 Standard Organization en 1976 (voir par exemple ISO/IEC 13239 - 1997)), ou sont dérivés de cette norme par introduction de procédures simplifiées ou complémentaires adaptées à des types particuliers d'interface de communication. Chaque mode de communication ainsi conçu reprend certains types de trames définis par la norme HDLC, en les affectant spécifiquement à 15 des catégories de messages déterminées. Parmi ces modes de communications, on peut citer: - le protocole PPP ("Point-to-Point Protocol", voir par exemple IETF Request for Comments 1134) utilisé pour les modems de liaison à un réseau téléphonique. Le protocole PPP prévoit en particulier 20 l'introduction périodique de bits nuls afin d'éviter une confusion entre des bits de données et des bits de contrôle; - le protocole GSM ("Global System for Mobile communications", voir GSM 07.10 Technical Specification 101 369 V6.3.0 publié par l'ETSI mars 1999) particulièrement adapté pour réaliser un multiplexage de 25 plusieurs applications hébergées dans une unité mobile de communication; le protocole HCI RS232, connu de l'homme du métier, utilisé pour la communication entre un processeur hôte d'au moins une application et un processeur de radiocommunication internes à une unité de 30 communication BluetoothT. Ce protocole est très peu utilisé à cause de sa complexité; enfin, le protocole B-ISDN ("Broadband Integrated Services Digital Network", voir ITU-T Recommandation 1.365.4 - 1996) qui propose une correspondance entre des trames AAL 5 de type CPCS ("Common Part Convergence Sublayer") et des trames de la norme HDLC.

Ces différents modes de communication sont mal adaptés pour une transmission de données entre deux processeurs d'une même unité de radiocommunication. En effet, ils sont complexes, sans qu'une telle complexité soit nécessaire, et n'apportent pas une sécurisation suffisante des données transmises.

Un but de la présente invention consiste donc à sécuriser de façon simple et efficace les données transmises entre deux processeurs d'une unité de radiocommunication.

L'invention concerne par conséquent un procédé de transmission entre deux processeurs disposés à l'intérieur d'une unité de radiocommunication, et 15 reliés entre eux par une connexion interne à l'unité de radiocommunication. Le premier processeur exécute au moins une application et le second processeur exécute des opérations de radiocommunication entre ladite unité et des unités de communication extérieures. Selon l'invention, le procédco-prend les étapes suivantes: - répartition de codes par l'un des deux processeurs, émetteur desdits codes, dans des trames ayant des longueurs respectives; - inscription d'éléments par le processeur émetteur dans des champs dédiés de chaque trame, parmi lesquels éléments la longueur de la trame, 25. une valeur d'un indicateur d'erreur de transmission déterminée par le processeur émetteur à partir de certains au moins des codes placés dans la trame, un indicateur de début de trame et un indicateur de fin de trame; - transmission des trames par la connexion interne; - pour chaque trame, vérification par l'autre processeur, récepteur desdits codes: de l'identité entre la longueur de la trame reçue et la longueur inscrite, de l'identité entre la valeur inscrite de l'indicateur d'erreur et une valeur de cet indicateur d'erreur déterminée par le processeur 5 récepteur à partir de certains au moins des codes reçus dans la trame, et de la présence des indicateurs de début et de fin de trame; - dans le cas de vérifications positives, production par le processeur récepteur d'un message d'acquittement envoyé au processeur 10 émetteur par la connexion interne.

Ainsi, selon l'invention, le procédé de transmission entre les deux processeurs par la connexion interne combine plusieurs dispositions de détection d'erreurs de transmission. Un processeur qui reçoit des codes pour lesquels il détecte une erreur de transmission peut soit ignorer ces codes, soit 15 demander une nouvelle transmission des mêmes codes. Dans les deux cas, les codes erronés ne provoquent pas de fonctionnement aberrant du processeur récepteur.

Eventuellement, la validation par le processeur récepteur d'une trame reçue peut être complétée par une condition de séparation des trames 20 successives. Par exemple, le processeur récepteur peut vérifier que l'indicateur de début d'une nouvelle trame est reçu après un délai de séparation déterminé à partir de la réception de l'indicateur de fin de la dernière trame précédemment reçue. Une meilleure sécurisation de la transmission entre les deux processeurs est ainsi obtenue.

Le procédé de transmission de l'invention peut en outre procurer les fonctions suivantes: - établissement d'une communication entre les deux processeurs, - vérification de l'état du lien de communication entre les deux processeurs, - contrôle et supervision d'une communication en cours, - transmission prioritaire de certaines informations, et - interruption d'une communication commandée par l'un quelconque des deux processeurs.

Pour cela, des trames transmises entre les deux processeurs par la connexion interne à l'unité de radiocommunication peuvent être associées à des primitives produites au sein de chaque processeur. En particulier, une 5 trame peut être émise en réponse à une primitive d'un premier type produite au sein du processeur émetteur, et une primitive d'un second type peut être produite au sein -du -processeur récepteur en réponse à la réception d'une trame. Un relais continu de commande et d'information peut ainsi être établi entre une application finale exécutée par le processeur applicatif et un module 10 du processeur de radiocommunication.

En particulier, une trame contenant des codes de requête de fin de transmission peut être émise par l'un quelconque des deux processeurs préalablement à une interruption d'un fonctionnement de ce processeur. Une telle interruption peut être motivée par une économie d'énergie d'alimentation 15 de l'unité, lorsque aucune transmission d'information n'est intervenue entre les deux processeurs depuis une durée supérieure à une durée prédéfinie.

Eventuellement, certains codes de la requête de fin de transmission peuvent indiquer l'état du processeur émetteur de la trame de requête après l'interruption du fonctionnement du processeur émetteur. Le processeur 20 récepteur de la requête est alors informé de l'état du processeur émetteur de celle-ci, ce qui permet d'adapter des conditions d'une reprise ultérieure d'une transmission entre les deux processeurs, de façon à réduire une éventuelle perte de codes au début de la nouvelle transmission.

Dans une mise en oeuvre préférée du procédé de l'invention, les codes 25 correspondent à des informations contenues dans des paquets. Le processeur émetteur répartit les codes correspondant aux informations d'un paquet dans une trame unique associée audit paquet. Une correspondance un pour un est alors établie entre les trames et les paquets, permettant un traitement séquentiel et séparé des paquets pour leur transmission par la connexion 30 interne. Lesdits paquets peuvent être, en particulier, des paquets de données ou des paquets de signalisation.

En outre, des trames de types prédéfinis distincts peuvent être associées aux paquets en fonction du type de chaque paquet. Ainsi une trame associée à un paquet de données peut être d'un type différent de celui d'une trame associée à un paquet de signalisation, par exemple. Il est ainsi possible d'adapter le traitement de chaque trame en fonction du type d'information qu'elle transporte.

L'invention concerne aussi un processeur comprenant une interface de connexion d'un autre processeur, adapté pour la mise en oeuvre d'un procédé de transmission tel que décrit précédemment. Un tel processeur comprend notamment: - des moyens de production de trames contenant des codes répartis dans des champs déterminés; - des moyens de détermination de la valeur d'un indicateur d'erreur de transmission à partir de certains au moins des codes placés dans une trame; - des moyens d'inscription d'éléments dans des champs dédiés de chaque trame, parmi lesquels éléments: la longueur de la trame, la valeur de l'indicateur d'erreur déterminée pour la trame, un indicateur de début de trame et un indicateur de fin de trame; 20 - des moyens d'émission de trames par ladite interface; - des moyens de réception de trames par ladite interface; - des moyens de mesure de la longueur d'une trame reçue; - des moyens de vérification dans une trame reçue: de l'identité entre la longueur mesurée et la longueur inscrite dans 25 la trame reçue, de l'identité entre la valeur de l'indicateur d'erreur inscrite dans la trame reçue et une valeur de cet indicateur d'erreur déterminée à partir de certains au moins des codes reçus dans la trame, de la présence des indicateurs de début et de fin de trame; - des moyens de production de messages d'acquittement agencés pour envoyer un message d'acquittement par ladite interface en réponse à une trame reçue validée par les moyens de vérification.

Le processeur peut comprendre en outre des moyens de mesure de la 5 durée entre la réception de l'indicateur de début d'une nouvelle trame et la réception de l'indicateur de fin de la dernière trame précédemment reçue, ainsi que-des moyens de vérification que ladite durée est supérieure à un délai de séparation déterminé.

Un tel processeur peut héberger par ailleurs au moins une application 10 à laquelle sont destinées certaines données transmises par le procédé de l'invention. Dans ce cas, le processeur comprend des moyens d'exécution de cette application, des moyens de traitement selon ladite application d'informations correspondant à une partie des codes contenus dans des trames reçues par ladite interface, et des moyens de production de codes à 15 répartir dans des trames en utilisant des informations produites par l'application.

Un processeur selon l'invention peut aussi être un processeur de contrôle d'une unité de radiocommunication. Il comprend alors en outre des moyens d'exécution d'opérations de radiocommunication avec des unités radio 20 extérieures, des moyens de production de signaux radio émis en utilisant une partie des codes contenus dans des trames reçues par ladite interface, et des moyens de production de codes à répartir dans des trames en utilisant des signaux radio reçus.

L'invention concerne encore une unité de radiocommunication qui 25 comprend un processeur hôte d'une application et un processeur de contrôle de l'unité de radiocommunication tels que décrits précédemment. Les deux processeurs sont reliés entre eux au niveau de leurs interfaces respectives par une connexion interne à l'unité de radiocommunication. Eventuellement, une telle unité peut être alimentée par une source d'énergie autonome, telle qu'une 30 batterie rechargeable ou des piles.

L'invention concerne en outre un système de radiocommunication comprenant une telle unité de radiocommunication.

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 une architecture de protocoles selon l'art antérieur d'une unité de radiocommunication à laquelle s'applique l'invention; - la figure 3 illustre l'architecture de protocoles d'une unité de radiocommunication selon la présente invention; - la figure 4 illustre la structure générale d'une trame utilisée dans le procédé de l'invention; - la figure 5 est un tableau de structures de champs de contrôle pour trois types de trames; la figure 6 illustre différentes séquences d'une procédure 15 d'établissement d'une communication selon l'invention; - la figure 7 illustre différentes séquences d'une procédure de contrôle de flux d'une transmission selon l'invention; - la figure 8 illustre différentes séquences d'une procédure d'attente de transmission selon l'invention.

L'invention est maintenant décrite en détail pour un réseau de transmission conforme à la norme "BluetoothTM", connue de l'homme du métier. Dans un tel réseau, les données sont transmises par radio en utilisant la bande de fréquence 2400 - 2483,5 MHz, sous la forme de paquets de données ayant des formats et/ou des structures déterminées.

La figure 1 représente trois unités d'un même réseau local, parmi lesquelles l'unité 1 remplit, par exemple, une fonction de maître. Les unités 100 et 200 sont alors des esclaves de l'unité 1. Chaque unité 1, 100, 200 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 30 domotique, un terminal de communication, etc. Cette unité contient au moins un programme applicatif, ou application, lui permettant en particulier de remplir sa fonction principale, à savoir un - 10 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, chaque unité est conçue selon une pile de protocoles 5 lui permettant d'échanger des données de façon compatible avec les autres unités du réseau local. 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 et 200; - un protocole d'exécution d'opérations de couche basse, tel que le protocole "Link Controller" (ou LC), et correspondant aux couches 106 et 206 pour les unités 100 et 200; - un protocole d'initialisation et de gestion des communications entre les unités du réseau local correspondant aux couches 107 et 207, tel que, 15 par exemple, le protocole "Link Manager" (ou LM); - un protocole de multiplexage des signaux destinés, notamment, à des applications différentes résidant simultanément dans certaines des unités du réseau local. Ce peut être le protocole "Logical Link Control and Adaptation Protocol" (ou L2CAP). Les couches 112 et 212 du 20 protocole L2CAP assurent en particulier, la mise sous forme de paquets des données à transmettre par radio, ou, à l'inverse, le regroupement de données reçues par radio dans des paquets successifs; et - au moins une application 113, 213 résidant dans chaque unité 100, 25 200. Ces applications sont les destinataires finals des données échangées au sein du réseau local. Plusieurs unités échangeant des données relatives à une application déterminée doivent contenir chacune un programme de cette application afin de produire, interpréter et traiter les données échangées dans le cadre de cette 30 application.

Deux structures sont possibles pour chaque unité de radiocommunication. Selon l'une de ces structures, désignée par "embedded", - 11 les opérations de tous les protocoles cités précédemment ainsi que les opérations des applications sont exécutées dans un processeur unique de l'unité. Les unités 100 et 200 de la figure 1 possèdent cette structure.

Pour la mise en oeuvre de l'invention, l'unité 1 possède une structure 5 différente, à deux processeurs, connue de l'homme du métier et reprise en détail sur la figure 2. Un premier processeur 2, appelé hôte ("host processor"), héberge au moins une application 13 supportée par l'unité 1, ainsi que le protocole L2CAP 12. Un second processeur 3, dit processeur de contrôle ("controller processor", ou CTRL), héberge les couches inférieures 10 correspondant aux opérations relatives à la transmission radio, à savoir les couches 5, 6, et 7 (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 15 exemple, une connexion USB ("Universal Serial Bus"), une connexion UART ("Universal Asynchronous Receiver Transceiver") ou un module de mémoire à deux entrées DPRAM ("Dual Port Random Access Memory "). Elle relie des interfaces d'échange de données respectives des processeurs 2 et 3, associées aux couches physiques 1Qa et 1Ob au sein de chaque processeur.

Deux couches 8 et 11 d'un protocole supplémentaire, pouvant être le protocole "Host Controller Interface" (ou HCI), assurent au sein de chaque processeur 2, 3 la mise en forme et le rétablissement des données échangées par la connexion 4. La couche 8 portée par le processeur de contrôle 3 est appelée "HCI firmware" et la couche 11 portée par le processeur hôte 2 est 25 appelée "HCI driver". Les données échangées par la connexion 4 sont réparties dans des paquets de données spécifiques traités par les couches 8 et 11, appelés paquets HCI.

La figure 3 reprend la figure 2 en ajoutant les moyens de mise en oeuvre spécifiques de l'invention. Une couche de protocole supplémentaire est 30 ajoutée au sein de la pile de protocoles correspondant à chacun des deux processeurs 2 et 3. Cette couche, de niveau transport, est nommée dans la suite HSTL ("HCI Secure Transport Layer"). Sa mise en oeuvre au sein du 12 processeur 2 correspond à la référence 9b. Elle intercalée entre la couche physique 1 Ob et la couche "HCI driver" 11. De même pour le processeur de contrôle 3, la couche HSTL 9a est intercalée entre la couche physique 1Qa et la couche "HCI firmware" 8. A la différence des couches 8 et 11 qui possèdent 5 chacune des caractères spécifiques associés au processeur 2 ou au processeur 3, les fonctions des couches HSTL 9a et 9b peuvent être identiques pour les deux processeurs 2 et 3. Les modules dédiés respectivement à l'exécution des fonctions des couches HSTL 9b et 9a dans les processeurs 2 et 3 peuvent alors être identiques.

Selon la mise en oeuvre de l'invention décrite, chaque paquet HCI produit selon la couche "HCI firmware" 8 du processeur de contrôle 3 est encapsulé selon la couche HSTL 9a dans une trame HSTL dédiée à ce paquet HCI. Cette trame HSTL est transmise par la connexion 4 à destination du processeur hôte 2. Lors de la réception de cette trame par le processeur hôte 15 2, la couche HSTL 9b permet de restituer le paquet HCI initial et le transmet pour être traité selon la couche "HCI driver" 1.

Réciproquement, un paquet HCI produit par la couche "HCI driver" 11 du processeur hôte 2 et transmis à destination du processeur de contrôle 3 est encapsulé de façon analogue dans une trame HSTL de la couche 9b. Après la 20 transmission de la trame HSTL par la connexion 4, le paquet HCI est restitué au niveau de la couche HSTL 9a. Il est ensuite transmis pour être traité selon la couche "HCI firmware" 8 du processeur de contrôle 3.

La figure 4 représente la structure d'une trame HSTL utilisée dans l'invention. La référence 20 désigne une telle trame HSTL qui correspond aux 25 spécifications de la norme HDLC et qui comporte les champs suivants: - deux champs 21 et 22 destinés à recevoir respectivement un indicateur de début de trame et un indicateur de fin de trame inscrits par le processeur émetteur avant l'émission de la trame; - un champ d'adresse 23, de un octet par exemple, utilisé de la façon 30 prescrite par la norme HDLC; - un champ de contrôle 24, de un octet par exemple, dont le contenu est explicité plus loin; - un champ de longueur 25, de un octet par exemple, destiné à recevoir une indication de longueur de la trame inscrite par le processeur émetteur; - un champ 26 de longueur variable dans lequel le processeur émetteur peut inscrire des données destinées à être transmises entre les deux processeurs; et - un champ 27, par exemple de deux octets, destiné à la détection d'erreurs de transmission, parfois appelé CRC (pour " Cyclic 10 Redundancy Check ").

Pour une application de l'invention dans le cadre d'un système de communication Bluetooth, tel que considéré ici, le champ de données 26 est destiné à recevoir un paquet HCI issu de la couche 8 ou 11 de protocole HCI, respectivement du processeur 3 ou 2 émetteur de la trame 20.

La figure 5 indique le contenu du champ de contrôle 24 pour trois types de trames distincts du protocole HDLC repris dans la présente invention. Ces types de trames sont désignés par I (" Information "), S (" Supervision ") et U (" Unnumbered "). Le type de la trame HSTL associée à un paquet HCI destiné à être transmis entre les deux processeurs par la connexion 4 est 20 déterminé en fonction du type du paquet HCI. Selon la mise en oeuvre décrite de l'invention, une trame I est utilisée pour la transmission d'un paquet de données HCI transportant des informations destinées à l'application 13 ou issue de cette application (ACL data), ou des données de contrôle HCI ("HCI commands/events"). Une trame U est utilisée pour la gestion de la 25 communication HSTL ou pour des paquets transportant la voix ("SCO data").

Le sous-ensemble de trames U utilisées pour la gestion de la communication HSTL regroupe les trames SABM, UA, DISC et DM, et des trames Ul sont utilisées pour les paquets transportant de voix. Enfin, une trame S est utilisée pour émettre un message de supervision d'une transmission par la connexion 30 4. Un tel message de supervision relève du protocole HSTL. Les trames S ne comportent pas de champ de données 26. Le sous-ensemble des trames S - 14 retenues est RR et RNR.

Le type de la trame est indiqué au moyen d'un code de distinction par les bits 0 et 1 du champ de contrôle 24, situés à droite sur la figure 5. A titre d'exemple, le bit 0, lorsqu'il contient la valeur 0, suffit à indiquer le type de 5 trame 1. Les types de trames S et U correspondent à une valeur 1 du bit 0, et sont distingués entre eux par la valeur du bit 1. Chaque processeur 2, 3 comprend des moyens pour inscrire de la sorte le type de chaque trame dans son champ de contrôle 24.

Pour les trois types de trames 1, U et S, le bit 4 indique si la trame 10 requiert une réponse de la part du processeur récepteur ou n'en requiert pas (bit P/F).

Les bits 1, 2 et 3 d'une trame I indiquent le numéro de cette trame dans une séquence de trames I successives, et les bits 5, 6 et 7 indiquent le numéro de la trame I suivante dans la séquence.

Pour une trame S, les bits 5, 6 et 7 indiquent aussi le numéro de la trame I suivante d'une séquence en cours de transmission, et les bits 2 et 3 sont réservés pour un code de supervision de la communication entre les deux processeurs 2 et 3.

Les trames U ne sont pas numérotées, et les bits 2, 3, 5, 6 et 7 d'une 20 trame U ainsi disponibles sont réservés pour des informations de signalisation.

Divers exemples d'utilisations des trames 1, S et U selon le procédé de transmission de l'invention sont maintenant décrits.

Pour l'application de l'invention à une unité de communication Bluetooles données destinées à être transmises entre les deux processeurs 25 2 et 3 sont présentées à la couche HSTL sous forme de paquets de. données HCI, conformément aux couches de protocole 8 et 11. Chaque paquet de données HCI est placé dans le champ de données 26 d'une trame 20 de type 1.

Préalablement à l'émission de la trame par la connexion 4, le processeur émetteur remplit alors les champs d'indicateurs 21 et 22 de début et de fin de 30 trame, d'adressage 23, de contrôle 24, de longueur 25 et d'indicateur d'erreur de transmission 27. La valeur de l'indicateur d'erreur de transmission inscrite - 15 dans le champ 27 est déterminée à partir d'une partie du contenu de la trame à transmettre par des moyens appropriés de mise en oeuvre du protocole HSTL.

Selon une mise en oeuvre particulière, la valeur de l'indicateur est calculée comme un reste d'une division d'un polynôme construit à partir de certains au 5 moins des codes contenus dans la trame par un polynôme générateur. Si le polynôme générateur utilisé est de degré 16, la valeur inscrite de l'indicateur d'erreur occupe les deux octets du champ 27.

Lors de la réception de la trame, le processeur récepteur évalue de nouveau la longueur de la trame et l'indicateur d'erreur à partir du contenu de 10 la trame reçue. La longueur de la trame reçue doit être supérieure à cinq octets, correspondant au champ d'adresse 23, au champ de contrôle 24, au champ de longueur 25 et au champ d'indicateur d'erreur de transmission 27 (deux octets). Il compare la longueur trouvée à la valeur inscrite dans le champ de longueur 25, et la valeur de l'indicateur d'erreur trouvée à la valeur inscrite 15 dans le champ 27. Une erreur de transmission portant sur un bit ou une partie plus importante de la trame est détectée lorsque l'une au moins des deux valeurs déterminées à la réception de la trame diffère de la valeur correspondante inscrite dans la trame. Le processeur récepteur est ainsi alerté de la présence d'une erreur de transmission et doit ignorer la trame. 20 L'acquittement n'est pas envoyé au processeur émetteur.

Eventuellement, le processeur récepteur peut procéder en outre à un test de séparation des trames reçues. Un tel test consiste à vérifier que la réception de l'indicateur de début d'une seconde trame suivant une première trame est séparée de la réception de l'indicateur de fin de la première trame 25 par une durée supérieure à un délai déterminé. Ce délai minimal de séparation des trames peut correspondre, par exemple, au temps nécessaire pour la transmission de quatre octets successifs. Une telle séparation permet de garantir un traitement séquentiel des trames reçues successivement par chaque processeur, en évitant une congestion des circuits de traitement des 30 trames reçues. Si une trame suit de façon trop rapprochée une trame précédente, elle doit être ignorée par le processeur récepteur.

Lorsque les tests précédents valident une trame reçue, le processeur récepteur de la trame retourne un message d'acquittement au processeur émetteur par la connexion 4. Ce message d'acquittement peut être l'objet d'une trame spécifique de type S, ou bien peut être regroupé dans une trame de type I véhiculant d'autres données transmises par le processeur récepteur de la première trame I au processeur émetteur.

Le processeur récepteur de la première trame I procède à l'extraction du paquets HCI à partir du champ de données 26. Le paquet HCI extrait est alors traité par le processeur récepteur conformément au protocole HCI.

Le procédé de transmission de l'invention peut être complété selon les 10 deux perfectionnements suivants: - lorsqu'une trame de type I a été envoyée par l'un des deux processeurs à l'autre, et que le processeur émetteur de cette trame I ne reçoit pas de message d'acquittement en retour, il peut répéter l'envoi de la trame I après un délai d'attente courant à partir de l'envoi de la trame 1. 15 L'envoi de la trame I peut être itéré à plusieurs reprises si aucun message d'acquittement n'est reçu, et ce jusqu'à un nombre maximal d'envois d'une même trame. Le délai d'attente avant la répétition de l'envoi d'une trame ainsi que le nombre maximal de répétitions de l'envoi d'une même trame peuvent être des paramètres ajustables d'un 20 mode de transmission avancé; - plusieurs canaux logiques de transmission ayant des caractéristiques de transmission différentes peuvent être disponibles. Le canal utilisé pour une communication déterminée est alors fixé lors de l'établissement de cette communication. Des caractéristiques de canaux particuliers 25 peuvent être, à titre d'exemples: une priorité des trames transmises par un canal par rapport aux trames transmises par d'autres canaux, certains canaux plus spécifiquement adaptés pour la transmission de données ou de signaux de voix, ou encore des canaux réservés pour la transmission de certains types de paquets HCI. Ainsi un canal 30 particulier peut être notamment dédié aux paquets de contrôle HCI, ou des trames I associées à un niveau de priorité élevé sont utilisées pour les paquets de contrôle HCI, alors que des trames I associées à un - 17 niveau de priorité plus bas sont utilisées pour des paquets HCI de données relatives à une application.

L'utilisation selon l'invention des trames U est maintenant décrite en détail dans le cadre de l'établissement d'une communication entre les 5 processeurs 2 et 3. L'établissement d'une communication n'est considéré qu'à titre d'exemple d'utilisation des trames U, étant entendu que les trames U peuvent aussi être utilisées pour la transmission entre les processeurs 2 et 3 de paquets transportant de la voix (trames UI).

L'établissement d'une nouvelle communication peut être requis par le 10 processeur 2 ou par le processeur 3. Selon la procédure illustrée par la figure 6, la communication est demandée par le processeur hôte 2 au processeur de contrôle 3. Elle peut être en particulier demandée par l'application 13 hébergée par le processeur 2. La figure 6 est un diagramme chronologique de la procédure d'établissement d'une communication, en référence à l'axe de temps 15 t orienté du haut vers le bas de la figure. Initialement, les deux processeurs 2 et 3 sont en état de veille ("IDLE"), conformément à l'indication d'état 100 de chaque processeur. Une primitive de requête de connexion 101 ("CONNREQ") est produite au sein du-procÙèsséur-2,àauniveau de la couche 11 de protocole HCI. En réponse à cette primitive 101, le processeur 2 produit, 20 selon le protocole HSTL (couche 9b), une trame de type U, référencée 102 sur la figure 6. Il inscrit dans cette trame une commande d'établissement de connexion de type "Asynchronous Balanced Mode" connue de l'homme du métier (commande SABM pour "Set Asynchronous Balanced Mode") . La commande SABM est spécifiée par les bits 2, 3, 5, 6 et 7 du champ de contrôle 25 24 de la trame U. Le bit 4 de la trame U indique que le processeur 2 attend une réponse de la part du processeur 3. Une telle trame U de requête de connexion peut être dépourvue de champ de données 26. La trame 102 est envoyée par la connexion 4 au processeur 3, et le processeur 2 se place dans un état 103 d'attente d'établissement de communication ("WAITCONNOUT").

Lors de la réception de la trame 102, la commande SABM est lue par le processeur 3 qui produit une primitive 104 d'indication de connexion ("CONNIND") au niveau de la couche 9a de protocole HSTL. Le processeur 18 3 se place alors à son tour dans un état d'attente d'établissement de communication ("WAITCONN_IN"), indiqué par la référence 105.

Lorsque le processeur 3 est prêt pour l'établissement de la communication, une primitive 106 de réponse de connexion ("CONN_RESP") 5 est produite au sein du processeur 3, selon protocole HCI de la couche 8. Le processeur 3 produit alors, selon le protocole HSTL de la couche 9a, une nouvelle trame 107 de type U comprenant un acquittement ("UA" pour "Unnumbered Acknowledgement") indiqué par les bits 2, 3, 5, 6 et 7 du champ de contrôle 24. Le bit 4 de cette nouvelle trame U ne requiert pas de réponse. 10 Le processeur 3 se place alors dans un état connecté 109.

A la réception de la trame 107, le processeur 2 lit le message d'acquittement UA conformément au protocole HSTL et produit une primitive 108 de confirmation de connexion ("CONNCONF"). La primitive 108 est traitée conformément au protocole HCI (couche 11) et le processeur 2 se place 15 à son tour dans l'état connecté 109.

De même que pour la transmission de trames I précédemment décrite, un délai d'attente peut être défini, qui limite la durée LtRESP entre l'émission de la trame 102 et la réception de la trame 107 par le processeur demandeur de l'établissement de la communication. Lorsque ce délai est atteint, le processeur 20 à l'initiative de la demande d'établissement de communication peut répéter la trame 102, et ce jusqu'à un nombre maximal fixé de répétitions. Lorsque ce nombre est atteint, un échec d'établissement de la communication est définitivement déclaré.

Dans le cas o le procédé de transmission de l'invention est mis en 25 oeuvre avec des voies de transmission séparées et indépendantes pour les deux sens de transmission entre les processeurs 2 et 3 ("fulI duplex"), les deux processeurs peuvent requérir simultanément l'établissement d'une communication. Une telle situation est couramment qualifiée de collision de requêtes. Les deux requêtes sont alors satisfaites.

Une procédure analogue d'interruption d'une communication entre les deux processeurs peut être mise en oeuvre en utilisant le procédé de - 19 l'invention. Cette procédure amène les deux processeurs de l'état connecté ("CONN") à l'état de veille ("IDLE"), en passant par un état intermédiaire d'attente de déconnexion. L'interruption de communication est requise par l'un des deux processeurs en transmettant à l'autre processeur par la connexion 4 5 une première trame U du protocole HSTL contenant une commande de déconnexion. Le processeur récepteur de cette première trame U retourne alors une seconde trame U qui confirme la déconnexion.

Une telle procédure d'interruption de communication peut notamment être mise en oeuvre avant le passage de l'un au moins des deux processeurs 10 en mode de veille, par exemple pour diminuer sa consommation énergétique pendant une période d'inactivité. Elle peut aussi être mise en oeuvre à la suite d'un dysfonctionnement de l'un des deux processeurs, ou à la suite de la détection d'une erreur de transmission systématique par la connexion 4. Une fois la communication interrompue, chaque processeur connaît ainsi l'état 15 d'activité ou d'inactivité de l'autre processeur. Il peut alors adapter les conditions d'établissement d'une nouvelle communication pour en réduire le délai et diminuer le risque de perte d'information en début de nouvelle communication.

L'utilisation selon l'invention de trames S dédiées à la supervision 20 d'une communication est maintenant décrite dans le cadre d'un contrôle du flux de transmission entre les deux processeurs 2 et 3, en référence à la figure 7.

La structure de la figure 7 est analogue à celle de la figure 6, l'axe de temps t étant encore orienté du haut vers le bas de la figure. Les deux processeurs sont initialement en état connecté (référence 200 sur la figure 7): une 25 transmission 202 de trames I est en cours par la connexion 4, par exemple du processeur de contrôle 3 vers le processeur hôte 2. Chaque trame 202 transmise suit une primitive 201 d'émission de données ("DATAREQ") produite au sein du processeur 3.

A un instant donné, la couche 11 de protocole HCI émet une primitive 30 203 au sein du processeur 2 signifiant que la mémoire tampon de réception des trames I est pleine. Une telle situation peut se produire, par exemple, lorsque l'application 13 à laquelle sont destinées les données transportées par - 20 les trames I les traite avec un débit inférieur au débit de transmission de la connexion 4 et au débit d'émission des trames par le processeur 3. La primitive 203 indique que le processeur 2 n'est pas disponible pour recevoir plus d'une trame I supplémentaire (primitive de type "FLOWREQ (BUSY)").

Suite à la réception par le processeur 2 d'une trame I supplémentaire, le processeur 2 émet une trame 204 de type S portant les deux messages suivants: acquittement (ACK) de la dernière trame I reçue et indication d'indisponibilité du processeur 2 (RNR pour "Receiver Not Ready").

L'acquittement est stipulé par le numéro de la trame I suivante indiqué dans les 10 bits 5 à 7 du champ de contrôle 24 de la trame S et par la valeur "poli" du bit 4. L'indisponibilité du processeur 2 est indiquée par les bits 2 et 3 du champ 24. En outre, le second bit du champ d'adresse 23 de la trame 204 est utilisé de la façon prévue par la norme HDLC pour indiquer que cette trame possède une signification de réponse.

Suite à la réception de la trame 202, une primitive 205 est produite au sein du processeur 2 au niveau de la couche HSTL 9b (primitive "DATA IND") . Indépendamment, une primitive 206 d'indication d'indisponibilité du processeur 2 ("FLOW IND (BUSY)") est produite au sein du processeur 3 en réponse à la réception de la trame 204. Le processeur 3 20 suspend alors l'envoi de trames I par la connexion 4, jusqu'à la réception d'un message indiquant que le processeur 2 est de nouveau disponible.

Le processeur 2 procède alors au traitement des données contenues dans les trames I déjà reçues. Après une durée déterminée AtFLOW, une primitive 207 interne au processeur 2 indique qu'il est de nouveau disponible 25 ("FLOWREQ (NOT BUSY)"). Selon le protocole HSTL de l'invention, le processeur 2 transmet alors par la connexion 4 une nouvelle trame S (208).

Cette trame 208 indique de nouveau le numéro de la trame I suivant la trame 202 dans la séquence des trames transmises par le processeur 3 au processeur 2, avec une valeur "poli" du bit 4 de son champ de contrôle. La 30 trame 208 contient aussi une indication de disponibilité (RR pour "Reciever Ready") portée par les bits 2 et 3 du champ de contrôle 24. En réponse à la réception de la trame 208, le processeur 3 produit une primitive 209 de type - 21 "FLOWIND (NOT BUSY)" qui déclenche la reprise de la transmission des trames 1 (210) du processeur 3 vers le processeur 2.

Le diagramme de la figure 8 correspond à une évolution de la communication entre les deux processeurs, alternative à celle de la figure 7. 5 Cette évolution correspond à la situation selon laquelle le processeur 2 attend des données de la part du processeur 3, que celui-ci tarde à fournir. Des trames S transmises périodiquement par la connexion 4 permettent alors de maintenir la communication entre les deux processeurs dans un état d'attente, tout en vérifiant le fonctionnement de la connexion 4.

L'état initial des deux processeurs et le début de la communication portée par la connexion 4 indiqués sur la figure 8 sont les mêmes que ceux de la figure 7. Les références 200, 201, 202 et 205 de la figure 8 ont des significations identiques à celles de la figure 7.

La trame S d'acquittement (ACK) 204 qui appelle la trame I suivante 15 est envoyée par le processeur 2 en réponse à la trame 202. Cette fonction de réponse (REP) est indiquée par le second bit du champ d'adresse 23. Or les données destinées à être véhiculées par la trame I suivante ne sont pas immédiatement disponibles au sein du processeur 3. Après un délai d'attente de fourniture de ces données, désigné par AtNo EXCH sur la figure 8, le 20 processeur 3 émet une trame 211 de type S à destination du processeur 2. La trame 211 est identique à la trame 204, hormis que le second bit du champ d'adresse 23 est utilisé pour indiquer que cette trame possède une signification de commande ("COMM").

Le processeur 2 répond à la trame 211 en émettant à son tour une 25 trame 212. La trame 212 est obtenue par le processeur 2 à partir de la trame 211 en changeant la valeur du second bit du champ d'adresse 23. La trame 212 possède ainsi une signification de réponse ("REP") à la trame 211.

L'échange des trames 204, 211 et 212 permet de vérifier l'état de la communication entre les deux processeurs au niveau des couches de transport 30 HSTL 9a et 9b, sans faire intervenir les couches supérieures de chaque processeur. Le processeur 3 peut ainsi compter sur l'état de disponibilité de la connexion 4 avant d'émettre la trame I suivante. Il est informé en cas d'échec - 22 de la séquence de supervision.

La séquence d'envoi des trames 211 et 212 est répétée tant que le processeur 3 ne peut délivrer une nouvelle trame 1. Ainsi le processeur 3 émet une trame 211 bis identique à la trame 211 après un nouveau délai AtNO EXCH 5 courant à partir de la réception de la trame 212. Le processeur 2 répond à la trame 211 bis par une trame 212bis identique à la trame 212.

Il est entendu que des fonctions supplémentaires par rapport à celles décrites précédemment peuvent être ajoutées au protocole de communication objet de l'invention, désigné par HSTL ci-dessus. Les fonctions qui ont été 10 décrites en détail ne sont donc pas limitatives, mais constituent un noyau de dispositions combinées entre elles pour assurer un bon niveau de qualité des communications entre deux processeurs. - 23

Claims (27)

REVENDICATIONS

1. Procédé de transmission entre deux processeurs disposés à l'intérieur d'une unité de radiocommunication (1) et reliés entre eux par une connexion (4) interne à l'unité de radiocommunication, le premier processeur 5 (2) exécutant au moins une application (13) et le second processeur (3) exécutant des opérations 'de radiocommunication entre ladite unité et des unités de communication extérieures (100, 200), le procédé comprenant les étapes suivantes: - répartition de codes par l'un des deux processeurs, émetteur desdits 10 codes, dans des trames (20) ayant des longueurs respectives; - inscription d'éléments par le processeur émetteur dans des champs dédiés de chaque trame, parmi lesquels éléments la longueur de la trame, une valeur d'un indicateur d'erreur de transmission déterminée 15 par le processeur émetteur à partir de certains au moins des codes placés dans la trame, un indicateur de début de trame et un indicateur de fin de trame; - transmission des trames (20, 202) par la connexion interne (4); - pour chaque trame, vérification par l'autre processeur, récepteur 20 desdits codes: de l'identité entre la longueur de la trame reçue et la longueur inscrite, de l'identité entre la valeur inscrite de l'indicateur d'erreur et une valeur de cet indicateur d'erreur déterminée par le processeur 25 récepteur à partir de certains au moins des codes reçus dans la trame, et de la présence des indicateurs de début et de fin de trame; - dans le cas de vérifications positives, production par le processeur récepteur d'un message d'acquittement (204) envoyé au processeur 30 émetteur par la connexion interne (4). - 24

2. Procédé selon la revendication 1, dans lequel le processeur récepteur vérifie en outre que l'indicateur de début d'une seconde trame reçue juste après une première trame, selon l'ordre chronologique de réception des trames, soit reçu après un délai de séparation déterminé à partir de la réception de l'indicateur de fin de ladite première trame.

3. Procédé selon la revendication 1 ou 2, dans lequel les trames comprennent au moins un champ de contrôle (24) contenant un code de distinction entre plusieurs types de trames.

4. Procédé selon l'une quelconque des revendications 1 à 3, dans lequel une trame (102, 107, 202, 208) est émise par la connexion interne (4) en réponse à une primitive d'un premier type (101, 106, 201, 207) produite au sein du processeur émetteur, et dans lequel une primitive d'un second type (104, 108, 205, 209) est produite au sein du processeur récepteur en réponse à la réception d'une trame (102, 107, 202, 208) par la connexion interne (4).

5. Procédé selon l'une quelconque des revendications 1 à 4, dans lequel la trame contient des codes de requête de fin de transmission par la connexion interne, et est émise préalablement à une interruption d'un fonctionnement du processeur émetteur.

6. Procédé selon la revendication 5, dans lequel les codes de requête de fin de transmission comprennent des codes indiquant l'état du processeur émetteur après l'interruption de fonctionnement du processeur émetteur.

7. Procédé selon l'une quelconque des revendications 1 à 6, dans lequel la valeur de l'indicateur d'erreur de transmission est donnée par le reste d'une division d'un polynôme construit à partir de certains au moins des codes 25 contenus dans la trame par un polynôme générateur.

8. Procédé selon l'une quelconque des revendications 1 à 7, dans lequel les codes correspondent à des informations contenues dans des paquets, et dans lequel le processeur émetteur répartit les codes correspondant aux informations d'un paquet dans une trame unique associée audit paquet.

9. Procédé selon la revendication 8, dans lequel ledit paquet est un paquet de données ou un paquet de signalisation.

---- Pr-océ-d-è-slon larevigndication -3-et- la revendication 8 ou 9, dans lequel chaque paquet est d'un type prédéfini, et dans lequel le type de la trame associée à un paquet est déterminé en fonction du type du paquet.

11. Procédé selon la revendication 10, dans lequel - une trame I du protocole HDLC est associée à un paquet de données destinées à ou issues de l'application (13) ou un paquet de contrôle, - une trame Ul du protocole HDLC est associée à un paquet transportant de la voix, et - une trame U SABM, UA, DISC ou DM est associée à la signalisation de 15 la communication.

12. Procédé selon l'une quelconque des revendications précédentes, dans lequel une trame S du protocole HDLC est utilisée pour émettre un message de supervision d'une transmission par la connexion interne (4).

13. Processeur comprenant une interface (4) de connexion d'un autre processeur, et comprenant en outre: - des moyens de production de trames (20) contenant des codes répartis dans des champs déterminés (21-27); des moyens de détermination de la valeur d'un indicateur d'erreur de transmission à partir de certains au moins des codes placés dans une 25 trame; - des moyens d'inscription d'éléments dans des champs dédiés de chaque trame, parmi lesquels éléments: la longueur de la trame, - 26 la valeur de l'indicateur d'erreur déterminée pour la trame, un indicateur de début de trame et un indicateur de fin de trame; - des moyens d'émission de trames par ladite interface (4); - des moyens de réception de trames par ladite interface (4); 5 - des moyens de mesure de la longueur d'une trame reçue; - des moyens de vérification dans une trame reçue: de l'identité entre la longueur mesurée et la longueur inscrite dans la trame reçue, de l'identité entre la valeur de l'indicateur d'erreur inscrite dans la 10 trame reçue et une valeur de cet indicateur d'erreur déterminée à partir de certains au moins des codes reçus dans la trame, de la présence des indicateurs de début et de fin de trame; - des moyens de production de messages d'acquittement agencés pour envoyer un message d'acquittement par ladite interface (4) en réponse 15 à une trame reçue validée par les moyens de vérification.

14. Processeur selon la revendication 13, comprenant en outre des moyens de mesure de la durée entre la réception de l'indicateur de début d'une seconde trame reçue par ladite interface (4) après une première trame, selon l'ordre chronologique de réception des trames, et la réception de l'indicateur de 20 fin de ladite première trame, et comprenant des moyens de vérification que ladite durée est supérieure à un délai de séparation déterminé.

15. Processeur selon la revendication 13 ou 14, comprenant en outre des moyens pour inscrire un code de type de trame dans au moins un champ de contrôle (24) de chaque trame (20).

16. Processeur selon l'une quelconque des revendications 13 à 15, comprenant en outre des moyens de production de primitives, dans lequel les moyens d'émission des trames par ladite interface (4) sont agencés de façon à émettre une trame (102, 107, 202, 208) contenant des codes déterminés en réponse à une primitive d'un premier type (1 01, 106, 201, 207) produite au sein - 27 dudit processeur, et dans lequel les moyens de production de primitives sont agencés de façon à produire une primitive d'un second type (104, 108, 205, 209) en réponse à une trame (102, 107, 202, 208) contenant des codes déterminés reçue par ladite interface (4).

17. Processeur selon l'une quelconque des revendications 13 à 16, dans lequel les moyens d'émission des trames sont agencés pour émettre par ladite interface (4) une trame contenant des codes de requête de fin de transmission préalablement à une interruption d'un fonctionnement du processeur.

18. Processeur selon la revendication 17, dans lequel les moyens d'émission des trames comprennent des moyens d'introduction dans la trame contenant les codes de requête de fin de transmission, de codes indiquant l'état du processeur après l'interruption de fonctionnement du processeur.

19. Processeur selon l'une quelconque des revendications 13 à 18, dans lequel les moyens de détermination de la valeur de l'indicateur d'erreur comprennent des moyens de calcul du reste d'une division d'un polynôme construit à partir de certains au moins des codes contenus dans une trame par un polynôme générateur.

20. Processeur selon l'une quelconque des revendications 13 à 19, dans lequel les codes correspondent à des informations contenues dans des paquets, et dans lequel les moyens de répartition des codes sont agencés pour répartir les codes correspondant aux informations d'un paquet dans une trame unique associée audit paquet.

21. Processeur selon les revendications 15 et 20, dans lequel chaque paquet est d'un type prédéfini, et dans lequel les moyens de production des trames sont agencés pour associer à un paquet une trame de type déterminé en fonction du type du paquet. - 28

22. Processeur selon la revendication 21, dans lequel les moyens de production des trames sont agencés pour associer une trame I du protocole HDLC à un paquet de données, et pour associer une trame U du protocole HDLC à un paquet de signalisation.

23. Processeur selon l'une quelconque des revendications 13 à 22, dans lequel les moyens de production des trames sont agencés pour produire une trame S du p--rotocole HDLC pour émettre un message de supervision d'une transmission par ladite interface (4).

24. Processeur (2) selon l'une quelconque des revendications 13 à 23, comprenant des moyens d'exécution d'une application (13), des moyens de traitement selon ladite application d'informations correspondant à une partie des codes contenus dans des trames reçues par ladite interface (4), et des moyens de production de codes à répartir dans des trames en utilisant des informations produites par ladite application.

25. Processeur (3) selon l'une quelconque des revendications 13 à 23, comprenant des moyens d'exécution d'opérations de radiocommunication avec des unités de communication extérieures (100, 200), des moyens de production de signaux radio émis en utilisant une partie des codes contenus dans des trames reçues par ladite interface (4), et des moyens de production 20 de codes à répartir dans des trames en utilisant des signaux radio reçus.

26. Unité de radiocommunication (1), comprenant un processeur (2) selon la revendication 24 et un processeur (3) selon la revendication 25 reliés au niveau de leurs interfaces respectives par une connexion (4) interne à l'unité de radiocommunication.

27. Unité de radiocommunication selon la revendication 26, comprenant en outre une source d'énergie autonome pour l'alimentation électrique des deux processeurs.

28. Système de radiocommunication comprenant une unité de radiocommunication (1) selon la revendication 26 ou 27.