Architecture de transport des données

Le système de transport des données de la technologie Bluetooth s'appuie sur une architecture en couches. La présentation qui suit décrit les couches de transport principales Bluetooth de ce système ainsi que les voies L2CAP. Les modes de fonctionnement de la technologie Bluetooth s'appuient tous sur une architecture de transport générique identique.

Pour plus d'efficacité et en raison de comportements hérités, l'architecture de transport Bluetooth comporte une sous-section au niveau de la couche logique qui permet de faire la différence entre les liaisons logiques et les transports logiques. Cette sous-section propose un concept de liaison logique générique et compréhensible qui permet de générer un transport autonome entre deux périphériques ou plus. La sous-couche de transport logique est requise pour pouvoir décrire la relation d'interdépendance entre certains types de liaisons logiques, ceci principalement en raison de comportements patrimoniaux.

La spécification Bluetooth 1.1 décrit les liaisons ACL et SCO comme des liaisons physiques. En raison de l'ajout de la liaison SCO étendue (eSCO) et dans le cadre d'ajouts futurs, il est préférable de considérer à présent ces liaisons comme des types de transports logiques, ce qui correspond mieux à la fonction qu'elles remplissent. Toutefois, elles ne sont pas aussi autonomes que cela pourrait s'avérer souhaitable. Elles partagent en effet les mêmes ressources dans certains cas, par exemple les ressources LT_ADDR et AQR (acknowledgement/repeat request - requête de répétition/d'acquittement) Par conséquent, l'architecture n'est pas en mesure de représenter ces transports logiques à l'aide d'une seule couche de transport. La couche de transport logique supplémentaire décrit jusqu'à un certain point ce comportement.

Principaux supports de transmission

Les liaisons logiques sont nommées en utilisant le nom du transport logique qui leur est associé ainsi qu'un suffixe indiquant le type de données transportées : C pour les liaisons de contrôle transportant des messages LMP, U pour les liaisons L2CAP transportant des données utilisateur (PDU L2CAP) et S pour les liaisons de flux transportant des données non formatées synchrones ou isochrones. Il n'est pas rare que ce suffixe soit supprimé sans risque d'ambiguïté. Par exemple, lorsqu'il est fait référence à un transport logique ACL, il peut s'agir en fait de la liaison logique ACL-C dans le cadre d'une discussion portant sur le protocole LMP ou de la liaison logique ACL-U dans le cadre d'une discussion portant sur la couche L2CAP.

Le mappage des types de trafics d'application avec les principaux supports de transmission du trafic Bluetooth dépend des caractéristiques des types de trafics et de celles des supports de transmission. Il est conseillé d'utiliser ces mappages. Il s'agit en effet de la méthode de transport des données la mieux adaptée en fonction de leurs caractéristiques et également de la méthode la plus simple et la plus efficace.

Dans le cadre de certaines installations ou applications, il peut arriver que le système principal Bluetooth choisisse d'utiliser des supports de transmission du trafic différents ou un autre mappage pour obtenir un résultat similaire. Par exemple, dans un pico-réseau disposant d'un seul périphérique esclave, le périphérique maître peut choisir de transporter les diffusions générales L2CAP sur les liaisons logiques ACL-U plutôt que sur les liaisons logiques ASB-U ou PSB-U. Cette solution sera probablement plus efficace en termes de bande passante si la qualité du canal physique n'est pas trop détériorée. L'utilisation d'autres chemins de transport est acceptable uniquement si les caractéristiques du type de trafic d'application sont conservées.

Ces types de trafics sont utilisés afin de classer les types de données susceptibles d'être soumis au système principal Bluetooth. Le type de trafic initial peut ne pas être le même que le type soumis au système principal Bluetooth si un processus d'intervention le modifie. Par exemple, les données vidéo sont générées à un débit constant. Toutefois, un processus de codage intermédiaire (par exemple, le processus d'encodage MPEG4) peut transformer ce débit en débit variable. Dans le cadre du système principal Bluetooth, seules les caractéristiques des données soumises représentent un intérêt.

Trafic de données tramées

Des voies L2CAP orientées connexion peuvent être générées pour le transport des données à diffusion individuelle (point à point) entre deux périphériques compatibles Bluetooth. Il existe un canal L2CAP sans connexion pour le transport des données à diffusion générale. Dans le cadre des pico-réseaux, le périphérique maître est toujours l'expéditeur des données à diffusion générale et les périphériques esclaves leurs destinataires. Le trafic sur le canal L2CAP à diffusion générale est unidirectionnel. Les canaux L2CAP à diffusion individuelle peuvent être unidirectionnels ou bidirectionnels.

Un paramètre QoS est associé aux canaux L2CAP. Il définit des contraintes de livraison pour les trames de données. Ces paramètres QoS peuvent être utilisés pour indiquer, par exemple, que les données sont isochrones et donc que leur durée de vie est limitée, qu'elles doivent être livrées avant l'expiration d'une période définie ou pour indiquer que les données sont fiables et qu'elles doivent donc être livrées sans erreur, peu importe le temps requis pour y parvenir.

Le gestionnaire des canaux L2CAP est chargé d'organiser le transport des trames de données d'une voie L2CAP sur une liaison logique de bande de base appropriée, éventuellement en multiplexant cette liaison sur la liaison logique de bande de base d'autres canaux L2CAP, partageant des caractéristiques similaires.

Haut de page

Trafic de données non tramées

Le système principal Bluetooth prend en charge le transport direct des données d'application isochrones à débit constant (débit en bit ou débit en trames pour les données prétramées) en utilisant une liaison logique SCO-S ou eSCO-S. Ces liaisons logiques préservent la bande passante du canal physique et permettent un transport des données à débit constant cadencé en fonction de l'horloge du pico-réseau. Les données sont transportées à intervalles fixes dans des paquets dont la taille reste identique. Ces deux paramètres sont négociés lors de l'établissement du canal. Les liaisons eSCO offrent un choix plus étendu de débits en bits et sont plus fiables car elles utilisent la retransmission limitée en cas d'erreur. Le mode de fonctionnement Débit de données rehaussé est pris en charge par les transports logiques eSCO, mais non par les transports logiques SCO. Les transports logiques SCO et eSCO ne prennent pas en charge les liaisons logiques multiplexées ou toute autre organisation supplémentaire en couches au sein du système principal Bluetooth. Une application peut choisir d'organiser en couches un certain nombre de flux parmi les flux SCO/eSCO soumis, à condition que le flux soumis soit un flux à débit constant ou en ait l'apparence.

L'application sélectionne le type de liaison logique le plus approprié parmi celles disponibles au niveau de la bande de base, la génère, la configure pour le transport du flux de données, puis la libère. Cette application utilisera en principe un canal tramé à diffusion individuelle L2CAP afin d'acheminer ses informations de plan C jusqu'à l'application paire du périphérique distant.

Lorsque les données d'application sont isochrones et à débit variable, elles peuvent uniquement être transportées sur le canal à diffusion individuelle L2CAP et sont donc considérées comme des données tramées.

Fiabilité des supports de transmission du trafic

Sur les transports logiques ACL, les résultats de l'algorithme de détection des erreurs sont utilisés pour lancer un protocole ARQ simple. Ceci permet d'améliorer la fiabilité en transmettant de nouveau les paquets pour lesquels l'algorithme de détection d'erreurs du récepteur a relevé des erreurs. Cette procédure peut être modifiée afin que les paquets sensibles au temps d'attente soient également pris en charge, c'est-à-dire qu'ils soient rejetés au niveau de l'émetteur lorsque leur durée de vie est arrivée à échéance. Pour améliorer la fiabilité du système, les liaisons eSCO utilisent une version modifiée de cette procédure en autorisant un nombre limité de retransmissions.

L'utilisation du protocole ARQ permet d'améliorer la fiabilité du système uniquement dans la mesure où les codes HEC et CRC détectent de manière efficace les erreurs. Dans la plupart des cas, l'utilisation de ces codes suffit pour détecter les erreurs. Toutefois, il a été démontré que pour les types de paquets plus longs, les probabilités de non-détection d'erreurs sont trop élevées pour permettre la prise en charge d'applications standard, tout particulièrement celles pour lesquelles de larges volumes de données sont transportés.

La couche L2CAP fournit un niveau de contrôle supplémentaire pour détecter les erreurs qui ne le sont pas quelquefois au niveau de la couche de bande de base, puis envoie une requête afin que les données erronées soient à nouveau transmises. Ce processus fournit le niveau de fiabilité requis par les applications Bluetooth standard.

Les liaisons à diffusion générale ne disposent pas de voie de retour et ne peuvent donc pas utiliser le protocole ARQ, bien que le récepteur soit encore en mesure de détecter les erreurs dans les paquets reçus. Pour remédier à ce problème, chaque paquet est transmis plusieurs fois en espérant que le récepteur recevra au moins un exemplaire de ces paquets correctement, mais cela n'est absolument pas garanti. Par conséquent, les liaisons de ce type ne sont pas considérées comme fiables.

En résumé, une liaison ou un canal sont considérés comme fiables lorsque le récepteur est capable de détecter les éventuelles erreurs dans les paquets reçus, puis d'envoyer des requêtes de retransmission jusqu'à correction des erreurs détectées. En raison des systèmes de détection d'erreurs utilisés, il est possible que certaines erreurs ne soient parfois pas détectées dans les paquets reçus. Ce niveau de non-détection pour les canaux L2CAP est comparable à celui d'autres systèmes de communications. Cependant, ce niveau est quelque peu plus élevé pour les liaisons logiques.

L'émetteur peut supprimer des paquets de la liste de transmission afin que le récepteur ne reçoive pas tous les paquets figurant dans la séquence. Lorsque cela se produit, la détection des paquets manquants est déléguée à la couche L2CAP.

Sur une liaison non fiable, le récepteur peut encore détecter les erreurs dans les paquets reçus, mais ne peut pas envoyer de requête de retransmission. Les paquets transférés au récepteur peuvent être exempts d'erreur, mais il n'est pas garanti que ce récepteur reçoive effectivement tous les paquets contenus dans la séquence. C'est pourquoi cette liaison n'est pas considérée comme fiable. L'utilisation de telles liaisons est limitée et dépend en principe de la répétition en continu des données à partir des couches supérieures pendant toute la durée de leur validité.

La fiabilité des liaisons de flux se situe entre celle d'une liaison fiable et d'une liaison non fiable, elle varie en fait en fonction des conditions de fonctionnement.

Haut de page

Entités d'architecture de transport

Structure générique des paquets Bluetooth

En principe, les paquets comportent uniquement les champs nécessaires à la représentation des couches requises par la transaction. Par conséquent, une simple requête d'informations sur un canal physique de traitement des requêtes d'informations ne génère ni ne nécessite aucune liaison logique ou couche supérieure et comprend donc uniquement un code d'accès de canal, associé au canal physique. Au sein d'un pico-réseau, les communications standard s'appuient sur des paquets qui intègrent tous les champs, toutes les couches d'architecture étant utilisées.

Tous les paquets comportent un code d'accès de canal. Ce code permet d'identifier les communications sur un canal physique particulier et d'exclure ou d'ignorer les paquets d'un canal physique différent qui utilise la même onde porteuse RF à proximité.

La structure des paquets Bluetooth ne comporte aucun champ contenant des informations en lien direct avec les liaisons physiques. Ces informations sont contenues de manière implicite dans l'adresse de transport logique (LT_ADDR) présente dans l'en-tête de paquet.

La plupart des paquets comporte un en-tête. Les paquets transmis sur les canaux physiques prenant en charge les liaisons physiques, les transports logiques et les liaisons logiques contiennent toujours un en-tête. L'en-tête de paquet contient l'adresse LT_ADDR. Celle-ci est utilisée pour acheminer le paquet en interne et également par chaque périphérique récepteur afin de déterminer si le paquet lui est adressé.

Cet en-tête contient également une partie du protocole LC utilisé par les transports logiques (sauf par les transports ACL et SCO qui utilise le protocole LC partagé transporté sur l'un ou l'autre des transports logiques).

Deux paramètres supplémentaires sont définis pour les paquets avec Débit de données rehaussé : temps de garde et séquence de synchronisation, en amont des données utiles. Il s'agit d'un champ utilisé pour la modification de couche physique du schéma de modulation.

L'en-tête de données utiles est présent dans tous les paquets sur transports logiques prenant en charge plusieurs liaisons logiques. L'en-tête de données utiles comporte un champ d'identification de liaison logique utilisé pour acheminer les données utiles et un champ indiquant la longueur des données utiles. Certains types de paquets intègrent également un processus CRC qui s'effectue en aval des données utiles. Il est utilisé afin de détecter les plupart des éventuelles erreurs pouvant figurer dans les paquets reçus. Les paquets avec Débit de données rehaussé intègrent également une queue de bande en aval du processus CRC.

Les données utiles de paquet sont utilisées pour transporter les données utilisateur. L'interprétation de ces données varie en fonction des identifiants de liaison logique et de transport logique. Sur les transports logiques ACL, les messages LMP et les signaux L2CAP sont transportés avec les données utiles de paquet, en même temps que les données utilisateur d'ordre général provenant des applications. Sur les transports logiques SCO et eSCO, les données utiles comportent les données utilisateur destinées à la liaison logique.

Canaux physiques

Deux périphériques compatibles Bluetooth partagent le même canal physique pour communiquer. Pour pouvoir communiquer, les émetteurs-récepteurs des périphériques doivent être réglés au même moment sur la même fréquence RF et se trouver à une distance nominale l'un de l'autre.

Étant donné que le nombre d'ondes porteuses RF est limité et qu'un grand nombre de périphériques compatibles Bluetooth peut fonctionner de manière autonome dans la même zone temporelle et spatiale, il y a de grandes chances que les émetteurs-récepteurs de deux périphériques compatibles Bluetooth autonomes soient réglés au même moment sur la même onde porteuse RF, provoquant ainsi une collision au niveau du canal physique. Pour atténuer les effets indésirables de cette collision, toute transmission sur le canal physique est précédée d'un code d'accès utilisé par tous les périphériques réglés sur le même canal physique. Ce code d'accès de canal est une propriété du canal physique. Le code d'accès précède toujours chaque paquet transmis.

Quatre canaux physiques Bluetooth sont définis. Chacun d'eux est optimisé et utilisé à des fins différentes. Deux de ces canaux physiques, le canal physique basique et le canal physique sélectif, sont utilisés pour permettre aux périphériques connectés de communiquer et sont associés à un pico-réseau spécifique. Les autres canaux physiques sont utilisés pour détecter les périphériques compatibles Bluetooth (canal de traitement de requête d'informations) et pour connecter des périphériques compatibles Bluetooth (canal de traitement de requête de connexion).

Un périphérique compatible Bluetooth peut utiliser un seul de ces canaux physiques à la fois. Afin de pouvoir traiter plusieurs opérations simultanément, le périphérique utilise le multiplexage par répartition dans le temps entre les canaux. De cette manière, un périphérique compatible Bluetooth peut participer simultanément à plusieurs pico-réseaux tout en restant détectable et connectable.

À chaque fois qu'un périphérique Bluetooth est synchronisé en fonction de la temporisation, de la fréquence et du code d'accès d'un canal physique, on considère qu'il est connecté à ce canal (qu'il communique activement ou non via ce canal). La spécification Bluetooth part du principe qu'un périphérique peut se connecter à un seul canal physique à la fois. Les périphériques avancés peuvent se connecter simultanément à plusieurs canaux physiques, mais la spécification part du principe que cela n'est pas possible.

Haut de page

Canal de pico-réseau basique

Présentation

Caractéristiques

Ce canal est divisé en slots, chacun correspondant à une fréquence de saut RF. Des sauts consécutifs correspondent à des fréquences de saut RF différentes. Le nombre de slots est fonction de l'horloge Bluetooth du périphérique maître du pico-réseau. Les paquets sont transmis par les périphériques Bluetooth participant au pico-réseau. Ces paquets sont alignés pour démarrer à la limite d'un slot. Chaque paquet est précédé par le code d'accès de canal, obtenu à partir de l'adresse du périphérique maître du pico-réseau.

Sur le canal de pico-réseau basique, le périphérique maître contrôle l'accès au canal. Le périphérique entame la transmission uniquement sur les slots de nombre pair. Les paquets transmis par le périphérique maître sont alignés par rapport au slot de départ et définissent la temporisation du pico-réseau. Les paquets transmis par le périphérique maître peuvent occuper jusqu'à cinq slots. Cela varie en fonction du type de paquet transmis.

Chaque transmission du périphérique maître correspond à un paquet transportant des informations sur l'un des transports logiques. Les périphériques esclaves peuvent répondre à ces transmissions en envoyant des données sur le canal physique. Les paramètres de leur réponse sont définis par le transport logique destinataire.

Par exemple, sur un transport logique asynchrone orienté connexion, le périphérique esclave destinataire répond en transmettant un paquet contenant des informations destinées au même transport logique aligné nominalement avec le slot de départ suivant (de nombre impair). Un tel paquet peut occuper jusqu'à cinq slots, selon son type. Sur un transport logique à diffusion générale, les périphériques esclaves ne sont pas autorisés à répondre.

Le canal physique de pico-réseau basique utilise certains slots réservés pour transmettre une séquence de balises. Il s'agit d'une caractéristique spécifique de ce type de canal. Cette séquence de balises est utilisée uniquement lorsque certains périphériques esclaves connectés au pico-réseau sont parqués. Dans une telle situation, le périphérique maître transmet un paquet sur les slots réservés de séquence de balises. Ce type de paquet est ensuite utilisé par le périphérique esclave pour se synchroniser de nouveau avec le canal physique de pico-réseau. Le périphérique maître peut transmettre des paquets à partir de n'importe quel transport logique via ces slots, à condition qu'une transmission démarre dans chacun d'eux. Lorsque des informations provenant du transport logique à diffusion générale du périphérique esclave parqué doivent être transmises, elles le sont sur les slots de séquence de balises et deviennent prioritaires par rapport à n'importe quel autre transport logique.

Topologie

Toutefois, seul un nombre restreint de transports logiques peut être pris en charge simultanément sur le pico-réseau. Cela signifie que seul un nombre restreint de périphériques esclaves compatibles Bluetooth peuvent échanger au même moment des données avec le périphérique maître, bien qu'en théorie aucune limite ne soit définie.

Couches prises en charge

Canal de pico-réseau sélectif

Présentation

Le canal de pico-réseau sélectif utilisant la même temporisation et le même code d'accès que le canal de pico-réseau basique, les deux coïncident souvent. Il ne s'agit pas d'un effet indésirable, au contraire, puisqu'il permet aux périphériques esclaves utilisant le canal de pico-réseau basique ou sélectif de se synchroniser par rapport au périphérique maître.

La topologie et les couches prises en charge du canal physique de pico-réseau sélectif sont identiques à celles du canal physique de pico-réseau basique.

Haut de page

Canal de traitement de requête d'informations

Présentation

Caractéristiques

Les canaux de traitement de requête d'informations « puisent » ce code d'accès dans un ensemble réservé de codes d'accès de requête utilisés par tous les périphériques compatibles Bluetooth. Un code d'accès est utilisé par les requêtes d'ordre général et un certain nombre de codes d'accès supplémentaires est réservé aux requêtes limitées. Chaque périphérique peut accéder à un certain nombre de canaux de traitement de requête d'informations. Tous ces canaux partageant le même modèle de saut de fréquence, un périphérique peut occuper simultanément plusieurs canaux de traitement de requête d'informations, à condition qu'il soit capable de mettre en relation plusieurs codes d'accès à la fois.

Un périphérique qui utilise l'un de ses canaux de traitement de requête d'informations demeure passif jusqu'à ce qu'il reçoive sur ce canal une requête d'informations provenant d'un autre périphérique compatible Bluetooth Cette requête est identifiée à l'aide du code d'accès de requête d'informations approprié. Le périphérique recevant cette requête envoie une réponse au périphérique initiateur en se conformant à la procédure de réponse aux requêtes.

Afin de détecter d'autres périphériques compatibles Bluetooth, le périphérique initiateur leur envoie une requête d'informations via leur canal de traitement de requête d'informations. Ce périphérique ne disposant d'aucune information sur ces périphériques, il ne connaît pas les caractéristiques exactes de leur canal de traitement de requête d'informations.

Il tire alors avantage du fait que ces canaux utilisent un nombre restreint de fréquences de saut et qu'ils « sautent » de fréquences en fréquences plus lentement. Le périphérique initiateur envoie des requêtes d'informations sur toutes les fréquences de saut utilisées par ces canaux, puis écoute les éventuelles réponses. Cette opération s'effectue plus rapidement, permettant ainsi au périphérique initiateur de couvrir toutes les fréquences utilisées dans un délai relativement court.

Topologie

Couches prises en charge

Canal de traitement de requête de connexion

Présentation

Caractéristiques

Un périphérique utilisant son canal de traitement de requête de connexion reste passif jusqu'à ce qu'il reçoive une requête de connexion d'un autre périphérique compatible Bluetooth. Cette requête est identifiée par le code d'accès du canal de traitement de requête de connexion. Les deux périphériques établissent ensuite une connexion en se conformant à la procédure requise. Lorsque la procédure de connexion a réussi, les deux périphériques basculent vers le canal de pico-réseau basique, la fonction de périphérique maître étant remplie par le périphérique ayant soumis la requête de connexion.

Lorsqu'un périphérique souhaite se connecter à un autre périphérique compatible Bluetooth, il utilise le canal de traitement de requête de connexion de ce dernier pour lui envoyer des requêtes de connexion. Lorsque le périphérique souhaitant se connecter ne connaît pas la phase utilisée par ce canal, il ne peut pas connaître la fréquence de saut utilisée par ce périphérique. Dans un tel cas, il envoie des requêtes de connexion sur chacune des fréquences de saut utilisées par le canal de traitement de requête de connexion de ce périphérique, puis écoute les éventuelles réponses à sa requête. Cette opération s'effectue plus rapidement, permettant ainsi au périphérique expéditeur de couvrir toutes les fréquences utilisées dans un délai relativement court.

Il est possible que le périphérique expéditeur dispose déjà de certaines informations sur l'horloge du périphérique compatible Bluetooth auquel il souhaite se connecter (par exemple, s'il a déjà communiqué avec ce périphérique lors d'un précédente transaction ou lors d'une participation à un même pico-réseau). Dans un tel cas, il peut déterminer la phase utilisée par le canal de traitement de requête de connexion de ce périphérique. Il peut également utiliser cette information afin d'optimiser la synchronisation entre les processus de requête de connexion et d'écoute de requête de connexion, permettant ainsi à la connexion de s'établir plus rapidement.

Topologie

Couches prises en charge

Liaisons physiques

Au sein d'un système sans fil Bluetooth, une liaison physique est en fait un concept virtuel, car elle n'est pas représentée concrètement au niveau de la structure de transmission d'un paquet. Le champ de paquet de code d'accès, l'horloge et l'adresse du périphérique maître compatible Bluetooth sont utilisés pour identifier les canaux physiques. Toutefois, aucune des sections ultérieures du paquet ne permet d'identifier directement les liaisons physiques. Il est cependant possible de les identifier à l'aide du transport logique qui leur est attribué, celui-ci leur étant propre.

Les propriétés de certains types de liaisons physiques peuvent être modifiées, par exemple la puissance de transmission. Toutes les liaisons physiques ne disposent pas de telles propriétés. Lorsque certaines propriétés des liaisons physiques peuvent être modifiées, le protocole LM est utilisé à cette fin. Le protocole LM étant pris en charge par une liaison logique au niveau d'une couche supérieure, les liaisons physiques concernées sont identifiées, par déduction, à partir de cette liaison logique.

Lorsqu'une transmission est diffusée via plusieurs liaisons physiques différentes, les paramètres de transmission sont sélectionnés de sorte qu'ils soient compatibles avec toutes les liaisons physiques.

Haut de page

Liaisons prises en charge par les canaux physiques de pico-réseau sélectif et basique

Liaison physique active

Les propriétés de la liaison physique active correspondent à celles de la puissance de transmission radio dans les deux sens. Les transmissions émanant du périphérique esclave sont toujours acheminées vers le périphérique maître via cette liaison physique active et utilisent la puissance de transmission fournie à cette liaison par le périphérique esclave pour ce faire. Les transmissions émanant du périphérique maître sont acheminées vers un périphérique esclave spécifique via une liaison physique active unique ou vers un groupe de périphériques esclaves par le biais de plusieurs liaisons. Dans le cadre d'une transmission point à point, le périphérique maître utilise la puissance de transmission requise par la liaison physique le reliant au périphérique esclave. Dans le cadre de transmissions point à multipoint, le périphérique maître utilise la puissance de transmission requise par le groupe de périphériques destinataires.

Les liaisons physiques actives peuvent être basculées en mode En attente ou Renifleur. L'activation de l'un ou l'autre de ces modes modifie les périodes au cours desquelles les liaisons physiques sont actives et peuvent donc transporter des données. Les transports logiques dont les caractéristiques de planification sont définies ne sont pas affectés par ces modes et continuent à fonctionner selon ces paramètres prédéfinis. Le transport logique ACL par défaut et les liaisons dont les caractéristiques de planification ne sont pas définies sont soumis au mode de fonctionnement de la liaison physique active.

Liaison physique parquée

Un périphérique esclave est parqué (sa liaison physique active devient parquée) à l'aide de la procédure de parcage. Le périphérique maître n'est pas autorisé à parquer un périphérique esclave disposant d'un transport logique généré par un utilisateur et pris en charge par la liaison physique. Ce transport logique doit d'abord être supprimé ainsi que tous les canaux L2CAP élaborés à partir de celui-ci. Le transport logique à diffusion générale et les transports logiques ACL par défaut ne sont pas considérés comme ayant été générés par un utilisateur et ne sont donc pas explicitement supprimés. Lorsque la liaison active est remplacée par une liaison parquée, les transports logiques ACL par défaut sont supprimés de manière implicite. Les liaisons logiques et les canaux L2CAP pris en charge ne sont pas supprimés, mais sont mis en attente. Tant que la liaison n'est pas à nouveau active, elles ne peuvent pas être utilisées pour transporter la signalisation ou des données de transport.

La procédure de déparcage permet de réactiver un périphérique esclave parqué. Le périphérique esclave envoie une requête de déparcage au niveau d'une fenêtre d'accès. La procédure de déparcage est ensuite initiée par le périphérique maître. Suite à la procédure de déparcage, la liaison physique parquée est transformée en liaison physique active et le transport logique ACL par défaut est de nouveau généré. Les canaux L2CAP mis en attente lors de la dernière procédure de parcage sont associés au nouveau transport logique ACL par défaut et deviennent de nouveau actifs.

Les liaisons parquées ne prennent pas en charge la fonction de contrôle de puissance radio, car les périphériques parqués ne disposent pas de voie de retour pour communiquer au périphérique maître la puissance du signal qu'ils reçoivent ou permettant au périphérique maître de mesurer la puissance du signal qu'ils reçoivent depuis les périphériques esclaves parqués. Les transmissions effectuées via les liaisons parquées utilisent la puissance nominale des périphériques.

Les liaisons parquées utilisent le même canal physique que les liaisons actives qui leur sont associées. Lorsqu'un périphérique maître gère un pico-réseau contenant des périphériques esclaves parqués qui utilisent le canal basique ou sélectif, il doit créer un transport logique à diffusion générale de périphérique esclave parqué (et un transport afférent) pour chacun de ces canaux.

Les périphériques esclaves parqués peuvent utiliser les périodes d'inactivité de ces transports logiques à diffusion générale pour réaliser des économies d'énergie ou se livrer à des activités sur d'autres canaux physiques sans lien avec le pico-réseau au sein duquel ils sont parqués.

Liaisons prises en charge par les canaux physiques de traitement de requête d'informations/de connexion

Liaisons logiques et transports logiques

L'identifiant des transports logiques et la signalisation en temps réel (contrôle des liaisons) sont transportés dans l'en-tête de paquet. Dans le cadre de certaines liaisons logiques, cet identifiant est transporté dans l'en-tête de données utiles. Les signalisations de contrôle ne nécessitant pas de temps de réponse sur slot unique sont acheminées à l'aide du protocole LMP.

Le tableau suivant répertorie tous les types de transports logiques, les types de liaisons logiques compatibles, les types de liaisons et canaux physiques qui les prennent en charge ainsi qu'une brève explication présentant leur rôle.

Haut de page

Les noms assignés aux liaisons logiques et transports logiques rappellent parfois les noms utilisés dans la version 1.1 de la spécification Bluetooth pour assurer une certaine continuité entre les versions et conserver un cadre déjà familier. Toutefois, ces noms n'ont pas de rapport avec le schéma homogène présenté ci-dessous.

Les liaisons sont classées selon trois types de procédures de sélection.

Diffusion

• Liaisons à diffusion individuelle. Les liaisons à diffusion individuelle relient uniquement deux points limites. Sur les liaisons à diffusion individuelle, les données peuvent être acheminées dans les deux sens. Toutes les liaisons à diffusion individuelle sont orientées connexion. Cela signifie qu'une connexion doit être établie pour que la liaison puisse être utilisée. Dans le cadre des liaisons ACL par défaut, la procédure de connexion constitue une étape implicite de la procédure de requête de connexion globale utilisée pour créer des pico-réseaux ad hoc.
• Liaisons à diffusion générale. Les liaisons à diffusion générale sont établies entre un périphérique expéditeur et zéro ou plusieurs périphériques destinataires. Sur ces liaisons, le trafic est unidirectionnel, c'est-à-dire que les données peuvent uniquement être acheminées du périphérique expéditeur aux périphériques destinataires. Les liaisons à diffusion générale ne nécessitent pas de connexion. Cela signifie qu'aucune procédure n'est requise pour les créer et qu'elles peuvent être utilisées à tout moment pour acheminer des données. Les liaisons à diffusion générale ne sont pas fiables et n'offrent aucune garantie quant à la bonne réception des données.

Schéma de planification et d'acquittement

La deuxième catégorie correspond au schéma de planification et d'acquittement des liaisons et prend en compte le type de trafic pris en charge par ces dernières. Ces liaisons sont synchrones, isochrones ou asynchrones. Aucune liaison isochrone spécifique n'est définie dans la version 1.2 de la spécification Bluetooth Version 1.2. Toutefois la liaison ACL par défaut peut être configurée de sorte à fonctionner de cette manière.

• Liaisons synchrones. Les liaisons synchrones permettent d'associer l'horloge de pico-réseau Bluetooth aux données transportées. Cette opération est effectuée en réservant des slots réguliers sur le canal physique et en transmettant des paquets de taille fixe au niveau de ces slots. De telles liaisons conviennent aux données isochrones à débit constant.
• Liaisons asynchrones. Les liaisons asynchrones permettent de transporter des données non définies en fonction de paramètres de temporisation. En principe, les données sont retransmises jusqu'à leur réception. Chaque entité de données peut être traitée à tout moment après réception sans référence au temps de réception des entités qui la précède ou la suit dans le flux (à condition que l'ordre des entités de données soit préservé).
• Liaisons isochrones. Les liaisons isochrones permettent de transporter des données non définies en fonction de paramètres de temporisation. Les données peuvent être retransmises jusqu'à leur réception ou leur expiration. Il n'est pas nécessaire que le débit de données sur la liaison soit constant. Il s'agit de la principale différence par rapport aux liaisons synchrones.

Classe de données

La troisième et dernière catégorie correspond à la classe de données transportée par la liaison. Il peut s'agir de données de contrôle (LMP) ou de données utilisateur. La catégorie des données utilisateur est divisée en deux sous-catégories : données L2CAP (ou tramées) et données de flux (ou non tramées).

• Liaisons de contrôle. Les liaisons de contrôle sont uniquement utilisées pour transporter des messages LMP entre deux gestionnaires de liaisons. Ces liaisons ne sont pas visibles au-dessus de la couche de bande de base. Elles peuvent être instanciées, configurées ou libérées par les applications uniquement en faisant appel aux services de connexion et déconnexion qui provoquent implicitement ces opérations. Les liaisons de contrôle sont toujours multiplexées avec une liaison L2CAP équivalente sur un transport logique ACL. Soumis aux règles qui régissent les fonctions ARQ, le trafic de liaison de contrôle a toujours la priorité sur le trafic de liaison L2CAP.
• Liaisons L2CAP. Les liaisons L2CAP sont utilisées pour transporter les PDU L2CAP qui peuvent contenir le canal de signalisation L2CAP (liaison logique ACL-U par défaut uniquement) ou des données utilisateur tramées soumises aux canaux L2CAP instanciées par les utilisateurs. Les trames L2CAP soumises à la bande de base peuvent être plus grandes que les paquets de bande de base disponibles. Le protocole LC intégré au champ LLID permet de conserver la structure de début et de continuation de trame lorsque la trame est transmise en plusieurs parties au récepteur.
• Liaisons de flux. Les liaisons de flux sont utilisées pour transporter les données utilisateur dont le tramage inhérent n'a pas besoin d'être conservé lorsqu'elles sont livrées. Au niveau du récepteur, les données perdues peuvent être remplacées par des données factices (processus de remplissage).

Transport logique asynchrone orienté connexion (ACL)

Un transport logique ACL par défaut est créé entre un périphérique maître et un périphérique esclave lorsque ce périphérique se connecte au pico-réseau (c'est-à-dire lorsqu'il se connecte au canal physique de pico-réseau basique). Le périphérique maître de pico-réseau attribue une adresse de transport logique (LT_ADDR) au transport ACL par défaut. Cette adresse LT_ADDR est également utilisée pour identifier la liaison physique active ou pour identifier les participants actifs de pico-réseau lorsque cela est nécessaire.

L'attribut LT_ADDR des transports par défaut ACL est réutilisé pour les transports logiques SCO qui relient le périphérique maître au périphérique esclave pour des raisons de compatibilité avec les versions antérieures de la spécification Bluetooth. Par conséquent, l'attribut LT_ADDR ne permet pas à lui seul d'identifier les transports logiques ACL par défaut. Cependant, les types de paquets utilisés sur les transports ACL sont différents de ceux utilisés sur les transports logiques SCO. Les transports logiques ACL peuvent donc être identifiés en utilisant à la fois le champ LT_ADDR figurant dans l'en-tête de paquet et le champ de type de paquet.

Les transports ACL par défaut peuvent être utilisés pour transporter des données isochrones. Ils doivent alors être configurés de sorte à se débarrasser automatiquement des paquets de données après l'arrivée à échéance de ces derniers.

Lorsque le transport logique par défaut ACL est supprimé de la liaison physique active, tous les autres transports logiques existants entre le périphérique maître et le périphérique esclave sont également supprimés. En cas de perte inattendue de synchronisation par rapport au canal physique de pico-réseau, la liaison physique, les liaisons logiques ainsi que tous les transports logiques cessent d'être présents dès que cette perte est détectée.

Un périphérique peut supprimer son transport logique ACL par défaut (et donc sa liaison physique active) tout en restant synchronisé par rapport au pico-réseau. Cette procédure est dite procédure de parcage. Un périphérique qui reste synchronisé par rapport à un pico-réseau sans avoir de liaison physique active est considéré comme étant parqué au sein de ce pico-réseau.

Lorsqu'un périphérique accède au statut de périphérique parqué, les liaisons logiques ACL par défaut acheminées sur son transport logique ACL par défaut ne sont pas supprimées, mais sont mises en attente. Aucune donnée ne peut être transférée via une liaison logique mise en attente. Lorsqu'un périphérique redevient actif, un nouveau transport logique ACL par défaut est créé (son attribut LT_ADDR peut être différent de celui du précédent transport), les liaisons logiques mises en attente précédemment lui sont alors associées et celles-ci redeviennent actives.

Transport synchrone orienté connexion (SCO)

Chaque liaison logique SCO-S est prise en charge par un unique transport logique SCO auquel est attribuée la même adresse LT_ADDR que celle attribuée au transport logique ACL par défaut qui existe entre les deux périphériques. C'est pourquoi le champ LT_ADDR ne permet pas à lui seul d'identifier la destination d'un paquet reçu. Les liaisons SCO utilisant des slots réservés, les périphériques se servent à la fois de l'attribut LT_ADDR, des numéros de slots (propriété du canal physique) et du type de paquet afin d'identifier les transmissions sur la liaison SCO.

Cette réutilisation de l'adresse LT_ADDR est un comportement hérité de la version 1.1 de la spécification Bluetooth. Dans les versions antérieures de la spécification Bluetooth, l'attribut LT_ADDR (alors appelé adresse de participant actif) était utilisé pour identifier les participants de pico-réseau impliqués dans les transmissions. Ce champ pouvant difficilement être modifié afin de permettre la prise en charge d'un plus grand nombre de liaisons logiques, son objectif a été redéfini avec la mise en œuvre des nouvelles fonctionnalités. Toutefois, certaines fonctionnalités de la version 1.1 de la spécification Bluetooth n'étaient vraiment pas adaptées à la définition plus formelle de la nouvelle architecture.

Bien que les slots soient réservés aux transports SCO, il est possible d'utiliser un slot de temps réservé pour le trafic provenant d'un autre type de canal, lorsque ce trafic bénéficie d'une plus haute priorité. Cela peut s'avérer nécessaire pour respecter les critères QoS ou pour envoyer la signalisation LMP sur le transport logique ACL par défaut lorsque les transports SCO occupent la totalité de la bande passante du canal physique. Les transports logiques SCO transportant des types de paquets différents de ceux transportés par les transports ACL, ces types peuvent être utilisés afin d'identifier le trafic SCO (en plus des numéros de slot et du champ LT_ADDR). Aucune autre couche d'architecture transportée via une liaison SCO n'est définie par la spécification principale Bluetooth. Un certain nombre de formats standard sont définis pour le flux 64 kbits/s transporté. Un flux non formaté est également autorisé lorsque l'application est chargée d'interpréter l'encodage du flux.

3.5.6 Transport synchrone orienté connexion étendu (eSCO)
Le transport logique eSCO correspond à une liaison asymétrique ou à une liaison point à point entre le périphérique maître et un périphérique esclave spécifique. Le transport logique eSCO réserve des slots sur le canal physique et peut donc être considéré comme une liaison commutée entre le périphérique maître et le périphérique esclave. Les liaisons eSCO offrent un certain nombre de fonctionnalités supplémentaires par rapport aux liaisons SCO standard : elles prennent en charge un ensemble plus flexible de types de paquets et de contenus sélectionnables de données et donc un plus large éventail de débits de bits synchrones.

Les liaisons eSCO proposent également une fonction de retransmission limitée de paquets (à la différence des liaisons SCO où les données ne peuvent pas faire l'objet d'une retransmission). Lorsque ces transmissions sont nécessaires, elles ont lieu sur les slots qui suivent les slots réservés. Dans le cas contraire, ces slots peuvent être utilisés pour transporter d'autres données.

Chaque liaison logique eSCO-S est prise en charge par un seul transport logique eSCO identifié par un attribut LT_ADDR qui reste unique au sein du pico-réseau pour toute la durée de la liaison eSCO. Les liaisons eSCO-S, qui sont créées à l'aide de la signalisation LM, suivent des règles de planification similaires à celles des liaisons SCO-S.

La spécification principale Bluetooth ne définit aucune autre couche d'architecture transportée par les liaisons eSCO-S. Les applications peuvent, en revanche, utiliser le flux de données comme elles l'entendent, à condition que les caractéristiques de transport du flux soient adaptées aux types de données qu'elles souhaitent transmettre.

Haut de page

Transport à diffusion générale de périphérique esclave actif (ASB)

Les transports logiques ASB sont par définition non fiables étant donné l'absence de procédure d'acquittement. Pour améliorer la fiabilité des transmissions, chaque paquet de données est retransmis un certain nombre de fois. Un nombre identique de séquences est utilisé pour aider au filtrage des retransmissions au niveau des périphériques esclaves.

Les transports logiques ASB sont identifiés par une adresse LT_ADDR réservée. Cette adresse est également utilisée par les transports logiques PSB. Un périphérique esclave actif reçoit du trafic sur ces deux transports logiques et ne peut pas immédiatement distinguer ces derniers. Les transports logiques ASB ne transportant pas de trafic LMP, un périphérique esclave actif peut ignorer les paquets reçus sur la liaison logique LMP via ce type de transport. Cependant, les périphériques esclaves actifs reçoivent du trafic L2CAP via les transports logiques PSB et les transports logiques ASB. Ils ne sont pas en mesure de faire la différence entre ces deux types de trafics L2CAP.

La formation d'un pico-réseau génère toujours implicitement la création de transports ASB. Chacun des canaux physiques du pico-réseau sélectifs ou basiques dispose d'un transport ASB. Les canaux physiques basiques ou sélectifs coïncidant dans la plupart des cas, les périphériques esclaves ne peuvent pas savoir quel canal ASB est utilisé pour transmettre les paquets. Ce phénomène ne fait qu'ajouter au manque général de fiabilité des canaux ASB. Ils ne sont, toutefois, pas forcément moins fiables en termes de paquets omis.

Le périphérique maître peut choisir d'utiliser un seul transport ASB (lorsqu'il dispose d'un canal physique sélectif et d'un canal physique basique), un nombre suffisant de retransmissions lui permettant d'envoyer des données aux deux groupes de périphériques esclaves à partir d'un seul canal ASB.

Les canaux ASB ne sont jamais utilisés pour transporter des signaux de contrôle LMP ou L2CAP.

Transport à diffusion générale de périphérique parqué (PSB)

Les transports logiques PSB sont plus complexes que les autres transports logiques, car ils comportent un certain nombre de phases remplissant chacune des fonctions différentes. Ces phases sont les suivantes : phase d'informations de contrôle (utilisée pour transporter les liaisons logiques LMP) et phase d'accès (utilisée pour transporter la signalisation de bande de base). Les phases d'informations de contrôle et de diffusions générales s'excluent en principe mutuellement, une seule d'entre elles pouvant être prise en charge sur un seul intervalle de balises. Même lorsqu'il n'y a pas de phase d'informations de contrôle utilisateur, le périphérique maître doit transmettre un paquet sur les slots de balises afin que les périphériques esclaves parqués puissent de nouveau se synchroniser. La phase d'accès est en principe présente à moins qu'elle n'ait été annulée par un message d'informations de contrôle.

La phase d'informations de contrôle est utilisée par le périphérique maître pour envoyer aux périphériques esclaves parqués des informations sur les modifications apportées aux attributs de transport PSB, aux séquences de balises ou contenant une requête de déparcage concernant un périphérique parqué du pico-réseau. Ces informations de contrôle sont transportées dans des messages LMP via une liaison logique LMP. La phase d'informations de contrôle est également présente lorsque les informations utilisateur nécessitent plusieurs paquets de bande de base.

Les paquets de la phase d'informations de contrôle peuvent uniquement être transmis sur les slots de séquence de balises des canaux physiques. Lorsque les informations de contrôle sont contenues dans un seul paquet DM1, elles sont réitérées sur chaque slot de séquence de balises au sein d'un même intervalle de balises. Lorsqu'il n'y a pas d'informations de contrôle, il est possible que les slots de balises soient occupés par une phase d'informations utilisateur. Lorsque aucune de ces deux phases n'utilise les slots de balises, ces derniers sont utilisés pour le trafic d'autres transports logiques ou pour le transport des paquets NULL.

Le périphérique maître utilise la phase d'informations utilisateur pour envoyer les paquets L2CAP destinés à l'ensemble des périphériques esclaves du pico-réseau. Les informations utilisateur peuvent être contenues dans un seul ou dans plusieurs paquets de bande de base. Lorsque les informations utilisateur sont contenues dans un seul paquet, ce dernier est réitéré sur chaque slot de séquence de balises des canaux physiques du pico-réseau.

Lorsque les informations utilisateur sont contenues dans plusieurs paquets de bande de base, ces derniers sont transmis sur les slots de temps, après la séquence de balises (fenêtre de traitement de la diffusion générale). Les slots de séquence de balises sont utilisés pour envoyer un message de phase d'informations de contrôle contenant les attributs de temporisation de cette fenêtre. Ce processus est nécessaire afin que les périphériques esclaves parqués puissent rester connectés au canal physique de pico-réseau et recevoir des informations utilisateur.

La phase d'accès est en principe présente à moins qu'elle n'ait été temporairement annulée par un message de contrôle envoyé via la phase de diffusion générale d'informations de contrôle. La fenêtre d'accès se compose d'une séquence de balises, suivie d'une séquence de slots. Pour qu'un périphérique parqué puisse de nouveau être actif au sein d'un pico-réseau, il doit envoyer une requête d'accès au périphérique maître à l'aide de cette fenêtre d'accès. Une adresse de requête d'accès est allouée à chaque périphérique esclave (elle ne lui est pas nécessairement propre) qui contrôle à quel moment le périphérique esclave peut effectuer sa requête d'accès lorsque la fenêtre d'accès est ouverte.

Les transports logiques PSB sont identifiés par l'adresse LT_ADDR réservée de 0. Cette adresse est également utilisée par les transports logiques ASB. En principe, les périphériques esclaves ne sont pas perturbés par la double utilisation de l'attribut LT_ADDR, ceux-ci étant connectés au canal physique du pico-réseau uniquement pendant l'utilisation du transport PSB.

Liaisons logiques

Liaison logique de contrôle ou ACL-C

Liaison logique isochrone/asynchrone utilisateur (ACL-U)

Liaisons logiques synchrones/synchrones étendues utilisateur (CO-S/eSCO-S)

Les liaisons logiques SCO-S ou eSCO-S ne peuvent pas transporter des données isochrones à débit variable. Des liaisons logiques ACL-U doivent être utilisées pour ce faire. Elles ont en effet recours à des paquets qui contiennent des en-têtes de données utiles. Les limites de la technologie sans fil Bluetooth se font sentir lorsque des données isochrones à débit variable doivent être transmises en même temps que des données utilisateurs fiables.

Canaux L2CAP

Les points limites de canal L2CAP sont identifiés sur leurs clients à l'aide d'un identifiant de canal (CID - Channel Identifier) attribué par le protocole L2CAP. Les points limites de canal L2CAP dispose sur chaque périphérique d'un identifiant (CID) spécifique.

Les canaux L2CAP peuvent être configurés de façon à fournir les paramètres QoS requis à l'application. Le protocole L2CAP mappe le canal sur la liaison logique ACL-U.

Le protocole L2CAP prend en charge les canaux orientées connexion ainsi que les canaux orientés groupe. Les canaux orientés groupe peuvent être mappés sur la liaison logique ASB-U ou mis en œuvre en les retransmettant via la liaison logique ACL-U à chacun des membres du pico-réseau.

Outre la création, la configuration et la suppression des canaux L2CAP, l'autre principale fonction du protocole L2CAP consiste à multiplexer les SDU (Service Date Unit) depuis les clients de canaux sur les liaisons logiques ACL-U ainsi qu'à planifier la sélection, puis à sélectionner les SDU en fonction de leur niveau relatif de priorité.

Le protocole L2CAP peut fournir un contrôle de flux par canal à l'aide de la couche L2CAP paire. Cette option est sélectionnée par l'application lorsque le canal est établi. Le protocole L2CAP permet également d'améliorer le processus de détection des erreurs ainsi que le processus de retransmission, ceci (a) afin de réduire le nombre d'erreurs non détectées susceptibles d'être transmises à l'application et (b) afin de pouvoir récupérer les portions de données utilisateur perdues lorsque la couche de bande de base s'est débarrassée de certains paquets figurant sur la liaison logique ACL-U.

Lorsqu'une interface HCI est utilisée, le protocole L2CAP doit également procéder à la segmentation des SDU L2CAP en fragments adaptés aux mémoires tampons de bande de base. Enfin, il doit effectuer une procédure de contrôle du flux basée sur des jetons de l'interface HCI et soumettre les fragments obtenus à la bande de base uniquement lorsqu'il y est autorisé. Cela peut avoir des conséquences sur l'algorithme de planification.

Haut de page