Principaux blocs de l'architecture
Contenus
Définition du système centralLe système principal Bluetooth prend en charge les quatre protocoles de couches inférieures et les protocoles afférents, ainsi qu'ils sont définis dans la spécification Bluetooth, un protocole de couche de service et le protocole de service SDP (Service Discovery Protocol). Le profil GAP (Generic Access Profile) définit les exigences du profil global. Une application Bluetooth intégrale nécessite le recours à un certain nombre de protocoles de services supplémentaires et de protocoles de couches supérieures, lesquels sont définis dans la spécification Bluetooth.
Contrôleur BluetoothLes trois couches inférieures sont parfois regroupées dans un sous-système appelé contrôleur Bluetooth. Il s'agit d'un type commun de mise en œuvre qui fait appel à une interface physique de communications standard pour relier le contrôleur Bluetooth au reste du système Bluetooth, c'est-à-dire à l'hôte Bluetooth, comprenant des couches L2CAP, des couches de service et des couches supérieures. Bien que cette interface soit facultative, l'architecture du système est conçue pour la prendre en charge. La spécification Bluetooth assure l'interopérabilité des systèmes Bluetooth autonomes en définissant les messages de protocole échangés entre les couches correspondantes ainsi que l'interopérabilité des sous-systèmes Bluetooth autonomes en définissant une interface commune pour les contrôleurs et les hôtes Bluetooth.
Un certain nombre de blocs fonctionnels sont illustrés ainsi que le chemin emprunté par les services et les données lorsque ces derniers circulent entre les blocs. Les blocs fonctionnels illustrés sur le schéma le sont à titre informatif. En principe, la spécification Bluetooth ne définit pas les détails relatifs aux mises en œuvres sauf si cela est nécessaire à des fins d'interopérabilité.
Protocoles et signalisation du système centralLes interactions sont définies pour toutes les opérations inter-périphériques standard, c'est-à-dire lorsque des périphériques Bluetooth échangent la signalisation de protocole conformément à la spécification Bluetooth. Les protocoles du système principal Bluetooth sont les suivants : protocole radio RF, protocole LC (Link Control), protocole LM (Link Manager) et protocole L2CAP (Logical Link Control and Adaptation Protocol). Tous ces protocoles sont définis de manière exhaustive dans les sections ultérieures de la spécification Bluetooth. En outre, le protocole SDP (Service Discovery Protocol) est un protocole de couche de service requis par toutes les applications Bluetooth.
Le système principal Bluetooth offre des services via un certain nombre de points d'accès aux services, illustrés sur le schéma par des ellipses. Ces services s'appuient sur les fonctions de base qui contrôlent le système principal Bluetooth. Ils peuvent être répartis en trois catégories distinctes. Le premier type de service correspond aux services de contrôle des périphériques qui modifient le comportement et les modes de fonctionnement d'un périphérique Bluetooth. Le deuxième type correspond aux services de contrôle du transport qui génèrent, modifient et libèrent les supports de transmission du trafic (canaux et liaisons). Enfin, le dernier type correspond aux services de données qui sont utilisés pour diffuser les données par le biais des supports de transmission du trafic. On considère en principe que les deux premiers types de services appartiennent au plan C et le troisième type de service au plan U.
HCI (Host to Controller Interface - Interface entre l'hôte et le contrôleur) : définit les fonctions hôte et contrôleur de la pile Bluetooth Une interface de service est définie pour le sous-système de contrôleur Bluetooth de sorte que ce contrôleur puisse être considéré comme un élément standard. Dans cette configuration, le contrôleur Bluetooth utilise les trois couches inférieures et la couche L2CAP est intégrée au reste de l'application Bluetooth au sein d'un système hôte. L'interface standard est appelée HCI (Host to Controller Interface - Interface entre l'hôte et le contrôleur). La mise en œuvre de cette interface de service standard est facultative.
L'architecture Bluetooth étant définie pour permettre les communications entre un hôte et un contrôleur via une interface HCI, un certain nombre d'hypothèses peuvent être émises. On part du principe que le contrôleur Bluetooth dispose de capacités plus limitées que l'hôte pour la mise en mémoire tampon des données. Par conséquent, on peut supposer que la couche L2CAP sert au transport de données de gestion peu complexes lors de la soumission des PDU L2CAP au contrôleur pour leur transport jusqu'au périphérique pair. Ce processus comprend la segmentation des SDU L2CAP en PDU plus faciles à gérer, puis la fragmentation des PDU en paquets de départ et de continuation dont la taille est adaptée aux mémoires tampons du contrôleur et assure ainsi la disponibilité des canaux de communication dans le respect des exigences QoS (Quality of Service).
Détection des erreurs sur la couche L2CAPLa couche de bande de base offre le protocole ARQ basique à la technologie Bluetooth. La couche L2CAP offre en option une fonction de détection supplémentaire des erreurs et de retransmission des données pour les PDU L2CAP. L'utilisation de cette fonctionnalité est recommandée lorsque les probabilités d'erreurs non détectées au niveau des données utilisateur doivent rester faibles. La couche L2CAP offre en option une autre fonction de contrôle du débit basée sur fenêtre qui peut être utilisée pour gérer l'allocation de la mémoire tampon sur le périphérique récepteur. Ces deux fonctions en option permettent d'améliorer les performances QoS pour un certain nombre d'utilisations.
Bien que ces hypothèses puissent ne pas s'avérer utiles pour les mises en œuvre dans lesquelles toutes les couches de l'architecture Bluetooth sont intégrées à un seul système, les modèles généraux d'architecture et de QoS sont définis en ayant ces hypothèses à l'esprit. Elles constituent dans les faits le plus petit dénominateur commun.
Test des interfaces : RF et TCI (Test Control Interface)Des tests de conformité automatisés doivent être effectués sur les mises en œuvre du système principal Bluetooth. Pour ce faire, le système testeur doit pouvoir contrôler la mise en œuvre via l'interface RF, commune à tous les systèmes Bluetooth et via l'interface TCI (Test Control Interface), requise uniquement pour les tests de conformité.
Le système testeur échange des données avec la mise en œuvre soumise au test via l'interface RF afin d'assurer une réponse correcte aux requêtes envoyées par les périphériques distants. Le système testeur contrôle la mise en œuvre soumise au test via l'interface TCI afin de la contraindre à générer des échanges via l'interface RF et ainsi pouvoir s'assurer que ces échanges sont conformes.
L'interface TCI utilise un répertoire de commandes différent (interface de service) pour effectuer les tests sur chaque protocole et couche de l'architecture. Un sous-répertoire dans le répertoire de commandes HCI est généré pour servir d'interface de service TCI à l'ensemble des couches et protocoles utilisés par le contrôleur Bluetooth. Une interface de service distincte est utilisée pour tester la couche et le protocole L2CAP. La spécification principale Bluetooth ne définissant pas d'interface de service L2CAP, cette dernière est définie de manière distincte dans les spécifications TCI. La mise en œuvre de l'interface de service L2CAP est requise uniquement pour les tests de conformité.
Haut de page
Principaux blocs de l'architecture
Gestionnaire des canauxLe gestionnaire des canaux permet la création, la gestion, puis la destruction des canaux L2CAP pour le transport des protocoles de service et des flux de données d'application. Le gestionnaire des canaux utilise le protocole L2CAP pour interagir avec le gestionnaire des canaux qui se trouve sur le périphérique pair distant afin de générer les canaux L2CAP et de raccorder leurs points limites aux entités adéquates. Le gestionnaire des canaux interagit avec le gestionnaire de liaisons local afin de créer de nouvelles liaisons logiques (si besoin est) et de les configurer de façon à assurer le niveau QoS exigé pour le type de données transmises.
Gestionnaire des ressources L2CAPLe gestionnaire des ressources L2CAP permet de gérer les requêtes effectuées pour soumettre les fragments PDU à la bande de base et permet d'assurer une certaine planification entre les canaux afin d'éviter que les canaux L2CAP devant se conformer à des critères QoS ne puissent pas accéder au canal physique en raison d'un manque de ressources du contrôleur Bluetooth. Ce bloc est indispensable car le modèle d'architecture ne part pas du principe que le contrôleur Bluetooth dispose d'une capacité de mise en mémoire tampon infinie ni que l'interface HCI dispose d'une largeur de bande infinie.
Le gestionnaire des ressources L2CAP peut également vérifier la conformité du trafic afin de garantir que les SDU L2CAP soumis par les applications respectent les paramètres QoS négociés. Le modèle de transport des données général de la technologie Bluetooth part du principe que les applications ont un comportement non délictueux et par conséquent ne définit pas la manière dont une mise en œuvre est censée traiter ce problème.
Gestionnaire des périphériquesLe gestionnaire des périphériques correspond au bloc fonctionnel opérant sur la bande de base qui contrôle le comportement global des périphériques Bluetooth. Il gère toutes les opérations du système Bluetooth qui n'ont pas un lien direct avec le transport de données, par exemple les requêtes d'informations sur d'autres périphériques Bluetooth, les connexions à d'autres périphériques Bluetooth ou les opérations permettant aux autres périphériques de détecter le périphérique Bluetooth local et de s'y connecter.
Le gestionnaire des périphériques envoie une requête au contrôleur des ressources de la bande de base pour accéder au système de transport des radiofréquences et ainsi effectuer les tâches qui lui sont assignées.
Le gestionnaire des périphériques contrôle également le comportement du périphérique local via un certain nombre de commandes HCI, telles que la fonction de gestion du nom local du périphérique, la fonction de gestion de toutes les clés de liaison stockées, etc.
Haut de page
Gestionnaire des liaisonsLe gestionnaire des liaisons permet la création, la modification et la libération des liaisons logiques et de leur transport logique associé (le cas échéant) ainsi que la mise à jour des paramètres des liaisons physiques entre les périphériques. Le gestionnaire des liaisons effectue ces opérations en communiquant, à l'aide du protocole LMP (Link Management Protocol), avec le gestionnaire des liaisons des périphériques Bluetooth distants.
Le protocole LMP permet la création de nouveaux transports et liaisons logiques entre les périphériques lorsque cela est nécessaire ainsi que le contrôle global des attributs de liaison et transport, par exemple activation du cryptage sur le transport logique, adaptation de la puissance de transmission sur la liaison logique ou réglage des paramètres QoS la concernant.
Gestionnaire des ressources de bande de baseLe gestionnaire des ressources de bande de base gère tous les accès au système de transport des radiofréquences. Il remplit deux fonctions principales. Sa première fonction consiste à accorder aux entités qui ont négocié des contrats d'accès des plages de temps sur les canaux physiques. Sa seconde fonction consiste à négocier des contrats d'accès avec ces entités. Via ces contrats d'accès, le gestionnaire s'engage à fournir un certain niveau de QoS à l'entité et ainsi à délivrer à l'application utilisateur les performances escomptées.
Ces deux fonctions doivent prendre en compte les comportements s'appuyant sur la fonction radio de la technologie Bluetooth. Il peut s'agir, par exemple, de l'échange standard de données entre des périphériques connectés via des liaisons et transports logiques, de l'utilisation du système de transport radio pour transporter les requêtes d'informations, établir des connexions, permettre la détection et la connexion ou effectuer des relevés à partir des ondes porteuses non utilisées en mode AFH.
Dans certains cas, la planification d'une liaison logique peut aboutir à l'utilisation d'un canal physique différent de celui précédemment utilisé. Cela peut être dû, par exemple, à l'utilisation d'un réseau éclaté, à une fonction de requête d'informations périodique ou à la recherche de périphériques. Lorsque les canaux physiques ne sont pas alignés par rapport aux slots temporels, le gestionnaire des ressources prend en compte le temps nécessaire au réalignement des slots du canal physique d'origine et de ceux du nouveau canal physique. Dans certains cas, les slots s'alignent naturellement, une horloge de périphérique identique étant utilisée comme référence pour les deux canaux physiques.
Contrôleur des liaisonsLe contrôleur des liaisons permet l'encodage et le décodage des paquets Bluetooth à partir des données utiles et des paramètres afférents au canal physique, au transport et à la liaison logiques.
Le contrôleur des liaisons procède à la signalisation du protocole LC (en collaborant étroitement avec la fonction de planification du gestionnaire des ressources). Cette signalisation permet de communiquer les signaux de requête de retransmission, d'acquittement et de contrôle de flux. L'interprétation de ces signaux constitue l'une des caractéristiques du transport logique associé au paquet de bande de base. L'interprétation et le contrôle de la signalisation du protocole LC sont en principe associés à la fonction de planification du gestionnaire des ressources.
Bloc RFLe bloc RF permet la transmission et la réception des paquets d'informations sur le canal physique. Un chemin de contrôle entre la bande de base et le bloc RF permet au bloc de la bande de base de contrôler l'onde porteuse de fréquence et de temporisation du bloc RF. Le bloc RF assure la transformation des flux de données en direction et à partir du canal physique et de la bande de base dans les formats requis.
Haut de page
|