|
Topologie des pico-réseaux
Toutes les liaisons sans fil Bluetooth sont établies dans le cadre d'un pico-réseau. Un pico-réseau comporte au minimum deux périphériques qui utilisent le même canal physique (ce qui signifie qu'ils sont synchronisés par rapport à une même horloge et séquence de sauts). L'horloge standard du pico-réseau correspond à l'horloge Bluetooth du périphérique maître dans ce même pico-réseau. La séquence de sauts est déterminée à partir de l'horloge et de l'adresse du périphérique maître Bluetooth. Tous les autres périphériques synchronisés sont considérés comme des esclaves au sein du pico-réseau. Les termes « maître » et « esclave » sont utilisés uniquement pour décrire le rôle des périphériques au sein d'un pico-réseau. Plusieurs pico-réseaux autonomes peuvent coexister à un même endroit. Chaque pico-réseau dispose d'un canal physique différent (c'est-à-dire d'un périphérique maître, d'une horloge et d'une séquence de sauts qui lui sont propres).
Un périphérique Bluetooth peut participer simultanément à deux pico-réseaux ou plus. Cette participation s'effectue via un multiplexage par répartition dans le temps. Un périphérique Bluetooth ne peut être le périphérique maître que d'un seul pico-réseau à la fois, ce dernier étant défini par synchronisation avec l'horloge du périphérique maître. Un périphérique Bluetooth peut, en revanche, être un périphérique esclave dans plusieurs pico-réseaux à la fois.
On dit d'un périphérique Bluetooth qui participe à plusieurs pico-réseaux à la fois qu'il est impliqué dans un réseau éclaté. Cette implication dans un réseau éclaté ne signifie pas nécessairement que le périphérique Bluetooth est doté d'une fonction d'acheminement des données. Les principaux protocoles Bluetooth n'offrent pas et ne sont pas conçus pour offrir une telle fonctionnalité, seuls des protocoles de niveau supérieur peuvent le faire. Il s'agit en outre d'une fonction qui dépasse la portée de la spécification principale Bluetooth.
Les transports logiques, les liaisons logiques et les canaux L2CAP sont utilisés pour fournir des fonctions de transport de données.
Modes et procédures de fonctionnementEn mode standard de fonctionnement, un périphérique Bluetooth est connecté à d'autres périphériques Bluetooth (sur un pico-réseau) avec lesquels il échange des données. La technologie sans fil Bluetooth étant une technologie de communications ad hoc sans fil, un certain nombre de procédures de fonctionnement sont disponibles. Elles permettent la création des pico-réseaux et donc l'établissement de communications supplémentaires. Ces modes et procédures sont utilisés au niveau des différentes couches de l'architecture. Par conséquent, un périphérique peut faire appel simultanément à un certain nombre de ces procédures et modes.
Haut de page
Procédure de requête d'informations (détection)Les périphériques Bluetooth utilisent cette procédure de requête d'informations afin de détecter les autres périphériques se trouvant dans leur voisinage ou pour permettre aux autres périphériques de détecter leur présence.
La procédure de requête d'informations est asymétrique. Un périphérique Bluetooth qui essaie de détecter les autres périphériques se trouvant à sa proximité est dit périphérique initiateur et envoie un certain nombre de requêtes d'informations. Les périphériques Bluetooth qui peuvent être détectés sont dits « périphériques détectables ». Ils écoutent ces requêtes, puis y répondent. La procédure de requête d'informations utilise un canal physique spécial pour les requêtes et les réponses.
Les périphériques initiateurs et détectables peuvent déjà être connectés à d'autres périphériques compatibles Bluetooth d'un autre pico-réseau. Le temps passé sur le canal physique de traitement des requêtes d'informations doit être équilibré par rapport à celui que nécessite le respect des critères QoS sur les transports logiques existants.
La procédure de requête d'informations n'utilise aucune des couches de l'architecture situées au-dessus du canal physique. Toutefois, l'existence d'une liaison physique temporaire est envisageable lorsque des informations de requête et de réponse sont échangées.
Procédure de requête de connexion
La procédure d'établissement des connexions est asymétrique. Le périphérique Bluetooth doit l'effectuer tandis que l'autre périphérique Bluetooth est connectable (requête de connexion). La procédure de requête de connexion est ciblée de sorte que seul le périphérique Bluetooth spécifié puisse y répondre.
Le périphérique connectable utilise un canal physique spécifique afin d'écouter les paquets de requête de connexion émis par le périphérique souhaitant se connecter à lui. Le canal physique utilisé par le premier périphérique est doté d'attributs spécifiques. Par conséquent, seul un périphérique disposant des informations concernant ce premier périphérique peut utiliser ce canal pour communiquer avec lui.
Il se peut que les périphériques initiateur et connectable soient déjà connectés à d'autres périphériques Bluetooth via un autre pico-réseau. Le temps passé sur le canal physique de traitement des requêtes de connexion doit être équilibré par rapport à celui que nécessite le respect des critères QoS sur les transports logiques existants.
Mode ConnectéLorsque la procédure de connexion a réussi, les périphériques sont connectés physiquement l'un à l'autre via un pico-réseau. Cela signifie que les deux périphériques sont connectés au même canal physique et donc qu'une liaison physique a été établie entre eux. Les liaisons logiques par défaut ACL-C et ACL-U sont également présentes. En mode connecté, il est possible de créer et de libérer des liaisons logiques supplémentaires et de modifier les modes de fonctionnement des liaisons logiques et physiques tout en maintenant la connexion au canal physique du pico-réseau. Les périphériques peuvent également lancer des procédures de requête d'informations ou de requête de connexion et se connecter à d'autres pico-réseaux sans avoir à se déconnecter du canal physique du premier pico-réseau auquel ils se sont connectés.
Le gestionnaire des liaisons crée des liaisons logiques supplémentaires en échangeant des messages LMP (Link Manager Protocol) avec le périphérique compatible Bluetooth distant. Ces messages lui permettent de négocier la création de ces liaisons ainsi que la définition de leurs paramètres. Les liaisons logiques ACL-C et ACL-U par défaut sont toujours créées pendant le processus de connexion. Ces liaisons sont utilisées pour les messages LMP et le canal de signalisation L2CAP respectivement.
Remarque : deux liaisons logiques par défaut sont créées lorsque deux périphériques se connectent pour la première fois. La liaison ACL-C, qui n'est pas visible par les couches situées au-dessus du gestionnaire des liaisons, transporte le protocole LMP. La liaison ACL-U transporte le protocole de signalisation L2CAP ainsi que tous les canaux multiplexés L2CAP de type meilleur effort. On parle souvent d'un transport logique ACL par défaut, lequel peut être résolu par le contexte, mais il s'agit généralement d'une liaison logique par défaut ACL-U. Notez également que ces deux liaisons logiques partagent un même transport logique.
Un transport logique ACL par défaut relie le périphérique maître au périphérique esclave pendant toute la période au cours de laquelle ce dernier est connecté de manière active au pico-réseau. Il existe deux méthodes pour supprimer le transport logique ACL par défaut. La première méthode consiste à déconnecter le périphérique du canal physique du pico-réseau. Cette opération provoque la suppression de l'intégralité de la hiérarchie des canaux L2CAP, liaisons logiques et transports logiques.
La seconde méthode consiste à parquer la liaison physique du périphérique esclave. Au cours de cette opération, la liaison abandonne son transport logique ACL par défaut. Cette opération est possible uniquement si tous les autres transports logiques ont été supprimés. Cette règle ne s'applique pas au transport logique ASB, celui-ci ne pouvant pas être explicitement créé ou supprimé. Il est impossible de parquer un périphérique qui utilise des transports logiques autres que les transports logiques ASB et ACL par défaut.
Lorsque la liaison physique du périphérique esclave est parquée, son transport logique ACL par défaut est libéré et le transport logique ASB est remplacé par un transport logique PSB. Les liaisons logiques ACL-C et ACL-U, multiplexées sur le transport logique ACL par défaut ne sont pas supprimées, mais ne peuvent pas être utilisées pour le transport des données. Le gestionnaire des liaisons du périphérique maître utilise uniquement les messages LMP dont le transport sur la liaison logique PSB-C est autorisé. Le gestionnaire des canaux et le gestionnaire des ressources L2CAP s'assurent qu'aucun trafic de données L2CAP à diffusion individuelle n'est soumis au contrôleur lorsque le périphérique est parqué. Le gestionnaire des canaux peut décider de s'occuper de la gestion du parcage et du déparcage du périphérique, si nécessaire, afin de permettre le transport des données.
Haut de page
Mode En attenteCe mode ne correspond pas à un mode de fonctionnement générique des périphériques, mais s'applique aux slots non réservés sur la liaison physique. Lorsque ce mode est activé, la liaison physique est active uniquement pendant les slots réservés au fonctionnement des liaisons synchrones de type SCO et eSCO. Toutes les liaisons asynchrones sont inactives. Ce mode est activé à chaque invocation, puis désactivé au terme de celle-ci, avec retour au mode précédent.
Mode RenifleurCe mode ne correspond pas à un mode de fonctionnement générique des périphériques, mais s'applique aux transports logiques ACL par défaut. Lorsque ce mode est activé, la disponibilité de ces transports logiques est modifiée en définissant des cycles de présence et d'absence. Les périphériques dont les transports logiques ACL par défaut sont en mode Renifleur peuvent utiliser les cycles d'absence pour commencer à échanger des données via un autre canal physique ou pour basculer en mode d'économie d'énergie. Le mode Renifleur concerne uniquement les transports logiques ACL par défaut (c'est-à-dire les transports logiques ACL partagés) et ne s'appliquent pas aux transports logiques SCO ou eSCO supplémentaires susceptibles d'être actifs. Les cycles de présence et d'absence de la liaison physique sur le canal physique du pico-réseau sont définis à partir du regroupement de tous les transports logiques générés sur la liaison physique.
Remarque : aucune attente n'est définie en termes de présence ou d'absence pour les transports logiques à diffusion générale. Un périphérique maître doit toujours essayer de planifier les diffusions générales de manière à ce qu'elles coïncident avec les cycles de présence de la liaison physique au sein du canal physique du pico-réseau. Dans les faits, cela n'est pas toujours possible. La répétition des diffusions générales est définie afin d'améliorer les possibilités d'accéder à plusieurs périphériques esclaves sans provoquer le chevauchement des cycles de présence. Toutefois, les transports logiques à diffusion générale ne peuvent pas être considérés comme fiables.
État parquéUn périphérique esclave peut rester connecté à un pico-réseau même si sa liaison physique est parquée. En revanche, il ne peut pas prendre en charge les liaisons logiques le reliant au périphérique maître, en dehors des liaisons logiques PSB-C et PSB-U qui lui permettent de continuer à communiquer avec ce dernier. Lorsque la liaison physique d'un périphérique esclave est parquée, cela signifie que ses possibilités de communication avec le périphérique maître sont restreintes. Ces limites sont définies par les paramètres du transport logique PSB. Pendant les périodes où le transport logique PSB est inactif ou absent, les périphériques peuvent essayer de communiquer en utilisant d'autres canaux physiques ou basculer en mode d'économie d'énergie.
Procédure de basculement des rôlesCette méthode permet d'intervertir le rôle de deux périphériques connectés à un pico-réseau. Cette procédure implique le basculement du canal physique défini par l'ancien périphérique maître vers le canal physique défini par le nouveau périphérique maître. Lorsque les canaux physiques sont intervertis, la hiérarchie des liaisons physiques et des transports logiques est supprimée, puis reconstruite. Les transports logiques PSB et ASB sous-tendus par la topologie ne sont, en revanche, pas conservés. Une fois les rôles intervertis, le canal physique du pico-réseau initial peut disparaître. Il reste présent lorsque l'ancien périphérique maître continue de jouer ce rôle pour d'autres périphériques esclaves toujours connectés au canal.
Cette procédure copie uniquement les liaisons logiques ACL par défaut et les couches requises vers le nouveau canal physique. Elle ne copie pas les autres transports logiques. Si cela est toutefois nécessaire, leur copie doit être effectuée par les couches supérieures. Les attributs LT_ADDR de tous les transports affectés ne peuvent pas être conservés, leurs valeurs pouvant déjà être utilisées sur le nouveau canal physique.
Lorsque des critères QoS ou des modes tels que le mode Renifleur sont définis sur les transports logiques d'origine, ces derniers ne sont pas conservés. Ils doivent être renégociés une fois la procédure d'interversion des rôles terminée.
Débit de données rehausséIl s'agit d'une solution qui permet d'augmenter les capacités des types de paquets Bluetooth et d'améliorer leur qualité afin d'augmenter le débit maximum de données, d'offrir un soutien amélioré à plusieurs connexions et de diminuer la consommation d'énergie, sans modifier le reste de l'architecture.
Cette solution peut être utilisée comme un mode opérant de manière autonome sur chaque transport logique. En mode Débit de données rehaussé, les bits présents dans l'en-tête de paquet ne sont pas interprétés de la même manière qu'en mode Débit de base. Cette interprétation différente est clarifiée à l'aide du champ d'adresse de transport logique qui figure dans l'en-tête de paquet. L'en-tête de paquet de données utiles et les données utiles sont reçus et démodulés en fonction du résultat de cette interprétation. Le mode Débit de données rehaussé peut uniquement être activé pour les transports logiques ACL-U et eSCO-S. Il ne peut donc pas être utilisé pour les transports logiques ACL-C et SCO-S ni pour les transports logiques à diffusion générale.
Haut de page
|