Rapport Bluetooth

Rapport sur les systèmes Bluetooth

Sébastien PRINEAU (prineau)
Luc MARTIN (lmartin)

Bordeaux 1
-
Maîtrise d'Informatique
2001/2002
Groupe 1

Sommaire

Résumé

Introduction

Partie Principale
  Composants des systèmes Bluetooth
  Les couches Bluetooth
      Bluetooth Radio
      Baseband
      LMP : Link Manager Protocol
      L2CAP : Logical Link Control and Adaptation Protocol
      SDP : Service Discovery Protocol

Bilan de l'étude

Bibliographie

Acronymes

Résumé

On va traiter dans ce rapport, les différents protocoles mise en oeuvre par le système Bluetooth.
L'introduction va présenter Bluetooth en expliquant brièvement quelle est l'utilité d'une telle technologie.

Ensuite, dans la partie principale, une présentation des couches de protocole sera suivie de leurs explications plus détaillées. Bien entendu, il serait trop long de les présenter toutes dans le détail. C'est pour cela que l'on va faire une vue générale du système, puis seules les parties de niveau les plus basses seront expliquées de manière plus approfondie.
Un point technique particulier de ces couches basses sera choisi pour être développé et expliqué complètement.

Ensuite, on dressera un bilan de cette étude et on y apportera quelques données économiques relatives à l'exploitation de ce système de transmission de données.
Et enfin, on terminera par une bibliographie contenant les références de nos sources d'informations, que l'on commentera succinctement.

Introduction

Qu'est-ce que Bluetooth ?
La technologie Bluetooth est un système permettant de relier des outils de communication portables ou fixes entre eux afin de leurs permettre d'échanger les informations.
Il s'agit d'une technologie de communication sans fil à courte distance. Le transport d'information se fait par des moyens radioélectriques.

L'avantage principal lors de la mise en oeuvre d'une telle connexion est l'absence de travaux d'infrastructure. Bluetooth est capable de réaliser des petits réseaux locaux, mais aussi de communiquer et de commander autre chose que des ordinateurs. Téléphones portables, FAX, ... Et tout autre type de matériel intégrant la technologie Bluetooth.
Ce système se veut robuste, simple, économique en énergie et peu coûteux.
Par contre, le principal inconvénient réside dans l'exposition aux parasites atmosphériques. De plus sa portée et son débit binaire son faible par rapport à d'autres types de réseaux locaux (comme Ethernet par exemple).

Nous allons étudier les différentes couches de protocoles du système Bluetooth.

Partie Principale

Voici le modèle en couche des protocoles relatifs au système Bluetooth. On peut y remarquer des couleurs différentes représentant les diverses que l'on va étudier dans ce rapport.

Couche Bleu : Système de communication Bluetooth (seul).

Couche Grise : Protocoles de communication avec la téléphonie (Ce sert de la partie Audio).

Couche Bleu claire : Protocole simple de transmission de données. RFCOMM, sert entre autre à l'émulation de ports série.

Couche Verte : Protocoles adoptés par le système Bluetooth.

Couche Rouge : Applications de haut niveau.

Figure 1 : Les différentes couches des protocoles Bluetooth

Les parties en bleu représentent les différentes couches de protocole directement liées aux systèmes Bluetooth. On va s'efforcer de les décrire dans les parties suivantes.

Composants des systèmes Bluetooth

On peut dénombrer plusieurs composants indispensables dans un système Bluetooth :

L'antenne de réception/émission des fréquences radio :
Ce composant n'a pas de spécifications générales pour tous les systèmes. L'antenne dépend du type d'appareil sur lequel Bluetooth est implémenté. C'est pour cela qu'elle n'est pas représentée sur la figure 1.

Système radio et Baseband :
Il s'agit ici, de la partie liaison physique avec la couche de plus bas niveau (Bluetooth Radio) et la deuxième couche (Baseband).
- La couche radio est destinée à émettre et recevoir les ondes radio des systèmes environnent. Elle fait la conversion des ondes radio (dont la fréquence de base est 2.4 GHz) en signaux électriques utilisables par la couche supérieure (Baseband).
- La couche Baseband inclue des routines de liaison bas niveau servant à établir les communications entre les systèmes Bluetooth. Elle permet, entre autre, le contrôle des liaisons entre une ou plusieurs unités Bluetooth, la définition des paquets de données, la détection et correction d'erreurs de bas niveau, la gestion des canaux logiques et la gestion des intervalles de temps de transmission.

Couches de protocole logiciel (bas niveau) :
Ces différentes couches logiciels peuvent être perçues comme des drivers. Elles permettent de faire la liaison entre les couches supérieures (en vert ou gris sur la figure 1) et la partie matérielle (Radio et Baseband).
Les couches à prendre en compte, ici, sont les suivantes :
- Gestion des liaisons (Link Manager et le protocole LMP),
- Contrôle des liens logiques et adaptation des protocoles (Logical Link Control and Adaptation Protocol : L2CAP),
- Interface de contrôle de l'hôte (Host Control Interface : HCI) et
- Protocole de découverte de service (Service Discovery Protocol : SDP).

Autres couches de protocole logiciel (moyen niveau) :
Ces couches sont représentées en gris et bleu clair sur la figure 1.
- Pour la couche TCS BIN (Telephony Control protocol Specification BINary), il s'agit d'un protocole permettant de communiquer avec des outils de téléphonie, type téléphone portable par exemple, possédant la technologie Bluetooth. Il permet de transmettre la voix (via la passerelle Audio) et des données.
- La couche AT-Commands sert à communiquer avec appareils de type modem, téléphones mobile acceptant les commandes AT et les FAX (compatibilité avec plusieurs classes). Cette couche communique avec la couche inférieure (RFCOMM) décrite ci-dessous.
- Le protocole RFCOMM sert à transmettre des données aux couches de haut niveau (Couleur Verte). De plus, ce protocole permet l'émulation de liaison série du type RS232 pour tout types d'applications. Notamment, pour la communication avec des commandes AT.

Protocoles et Applications de haut niveau :
Il s'agit des couches vertes et rouges. Ces couches ont été adoptées par le système Bluetooth afin de permettre aux applications traditionnelles de fonctionner indépendamment des systèmes Bluetooth. En effet, les protocoles, adoptés ici, ont été légèrement modifiés pour être adaptés au système. Les protocoles/applications des couches supérieures (utilisant les protocoles adaptés) peuvent être, donc, réutilisés sans modification.

Les Couches Bluetooth

Dans cette partie, on va traiter plus en profondeur les couches Bluetooth proprement dites. C'est à dire les parties bleues de la figure 1. On va décrire protocole par protocole les différentes informations circulant à travers les couches.

Bluetooth Radio

Afin de minimiser la complexité des transmissions, la modulation de fréquence (bande FM) est utilisée.
Cette couche est la couche matérielle de plus bas niveau. Elle sert à transformer les données binaires en ondes radio. Ces ondes utilisent la fréquence 2.4 GHz ISM (Insdustrial Scientific Medecine) variant entre une bande de 2400 - 2483.5 MHz dans la plupart des pays.

Géographie	Bande de fréquence	Canaux de fréquences radio
USA, Europe et autres pays	2.400-2.4835 GHz	f=2402+k MHz, k=0,...,78

En France, les limitations imposent une utilisation plus réduite de la bande de fréquence : 2.4465-2.4835 GHz avec des canaux f=2454+k MHz, k=0,...,22
Il est donc possible de communiquer avec 79 (23 pour la France) canaux pour un mini réseau.

L'espace alloué à un canal est de 1MHz. De plus, pour éviter que les canaux interfèrent les uns avec les autres, on laisse des bandes de sécurités entre eux :

Géographie	Bande inférieure	Bande supérieure
USA, Europe et autres pays	2 MHz	3.5 MHz

La puissance d'émission d'un système bluetooth est rangée en trois classes :

Classe 1 : Sortie entre 2.5mW (+4 dBm) et 100mW (+20 dBm) pour une portée maximale.

Classe 2 : Sortie entre 0.25mW (-6 dBm) et 2.5mW (+4 dBm).

Classe 3 : Sortie de 1mW (+0 dBm). Il s'agit d'une puissance de sortie standard.

La vitesse de transmission maximale théorique est de 1Mbit/s, mais en réalité, elle situe aux environs des 720 Kbit/s.
La distance entre deux unités Bluetooth en communication, est de 10 mètres avec une antenne standard d'une puissance de 0 dBm. Mais dans des conditions optimales avec une antenne de puissance 20 dBm, on peut espérer obtenir une portée de 100 mètres.

Baseband

Cette couche va permettre de contrôler/commander la couche radio en fonction des données qui lui seront transmise.
Tout d'abord, il faut savoir que les informations qui vont circuler par les ondes seront découpées en intervalle de temps. On va appeler slot cet intervalle de temps.
La durée normale d'un slot est de 625 µs.
Pour effectuer des transmissions en Full Duplex, on utilisera la méthode du temps partagé (Time-Division Duplex : TDD).

Figure 2.1 : Slot et TDD

Pour être transmise, les informations font être encapsulées dans des paquets. Et normalement, un paquet rentre dans un seul slot. Mais il est possible d'étendre un paquet sur un maximum de cinq slots.

Figure 2.2 : Paquets sur plusieurs slots

Entre le maître (Emetteur) et le (ou les) esclave(s) (Récepteur), deux types de liens peuvent être établis :

Liaison à Connexion Synchrone (Synchronous Connection-Oriented : SCO) ou

Liaison à Connexion Asynchrone (Asynchronous Connection-Less : ACL).

La connexion SCO est une liaison point à point. Le maître ne peut avoir qu'un seul esclave. Le maître maintien la connexion en envoyant et recevant des slots à intervalle régulier. Cette connexion est utilisée pour la voix et a un débit de 64 kb/s.
La connexion ACL est une liaison point à plusieurs point (point-to-multipoint). Ici, le maître communique avec tous les esclaves participant au mini réseau. Cette connexion est utilisée pour le transfert de données. Son débit est de 723.2 kb/s en asymmétrique (57.6 kb/s en retour) ou 433.9 kb/s en symmétrique.

Il est possible qu'un maître établisse une connexion ACL avec des esclaves déjà engagés dans des liaisons SCO. Certains esclaves des liaisons ACL peuvent très bien être des maîtres sur les liaisons SCO. On appel ce genre de liaison dans les mini réseaux : scatternet.

Liaisons possibles

Figure 2.3 : Les Liaisons Maître/Esclave en SCO (a), ACL (b) et scattnet (c)

La forme générale d'un paquet transmit est celle-ci :

Liaisons possibles

Mais nous ne rentrerons pas dans les détails pour cette partie, ainsi que pour la correction d'erreur et la sécurisation des données à ce niveau.

LMP : Link Manager Protocol (Protocole de Gestion des Liaisons)

Généralités

Les messages LMP (Link manager Protocol) sont utilisés pour établir une connexion, pour la securiser et la contrôler. Ils sont transférés dans le corps des trames L2CAP et sont distingués par une valeur réservée dans le champ L_CH de l'entête. Les messages sont filtrés et interprétés par la couche LM du côté récepteur et ne sont pas transmis aux couches supérieures.

Figure 3.1 : Place générale de la couche de connexion

Les messages LMP ont une plus grande priorité que les messages utilisateurs. Ce qui signifie que si la couche de connexion (LM) a besoin d'envoyer un message, il ne sera pas retardé par le trafique de la couche L2CAP, bien qu'il puisse être retardé par plusieurs retransmission des paquets.
Le temps de réponse à un message LMP doit être inférieur au timeout des messages LMP qui est de 30 secondes.

Format des messages LMP

Les messages LM sont toujours envoyés dans des paquets uniques et l'entête est toujours d'un octet. Les 2 bits de poids faible déterminent le canal logique (LC). Pour les messages LMP ces bits sont :

Figure 3.2 : Entête des trames LMP

Figure 3.3 : Format des trames LMP

Protocole de communication

Réponses générales

Les messages LMP_accepted et LMP_not_accepted sont utilisés comme réponses à un grand nombre de messages. Ils incluent l'OpCode du message accepté ou non et la raison pour laquelle le message n'a pas été accepté.

Authentification

La machine qui veut vérifier l'authenticité de son correspondant envoie un message LMP_au_rand qui contient un nombre aléatoire.
Le client calcul une réponse qui est une fonction ayant comme paramètre le chiffre aléatoire, l'adresse du client et une clef secrète. La réponse est renvoyée vers la machine qui souhaitait une authentification et vérifie si la réponse est correcte. Pour que cette vérification soit correcte il faut que les deux machines possèdent la même clef secrète (voir plus loin comment cette clef est transmise).
Les messages suivants sont utilisés :

Figure 3.4 : Messages pour l'authentification

Le client possède une clef

Si le client a déjà une clef associée a la machine qui souhaite l'authentification, il calcul la réponse et la renvoie avec LMP_sres. Le serveur vérifie alors la réponse. Si celle ci n'est pas correcte il peut fermer la connexion avec LMP_detach.
Si le client a reçu LMP_AU_RAND et veut en même temps faire une demande d'authentification il doit d'abord répondre LMP_res avant de commencer sa propre vérification.

Le client n'a pas de clef

Si le client n'a pas de clef associée avec le serveur il retourne LMP_NOT_ACCEPTED avec comme raison "key missing".

Création de la clef

Quand aucun des deux côtés n'a une clef de connexion, une clef d'initialisation est crée (kinit) à partir d'un PIN (Personal Identification Number), d'un nombre aléatoire et de l'adresse de la machine. Quand les deux côtés ont créé leur clef, la connexion peut s'établir et au final une authentification mutuelle est faite.
Les messages utilisés pour cette connexion sont :

Figure 3.5 : Messages pour la création de la clef

Une fois cette kinit créé, la clef de connexion doit être faite entre les deux systèmes souhaitant dialoguer. Cette clef est soit la combinaison des deux kinit, soit une des deux suivant les règles suivantes :

Si un côté envoie LMP_unit_key et l'autre envoie LMP_comb_key, la clef envoyée par LMP_unit_key sera la clef de connexion.

Si les deux côtés envoient LMP_unit_key la clef du maître deviendra la clef de connexion.

Si les deux côtés envoient LMP_comb_key, on calcul une clef de connexion qui dépendra des deux clefs envoyées par chacun des deux côtés.

Etablir une connexion

Quant un côté souhaite créer une connexion, il envoie LMP_host_connection_req.
Lorsque l'autre côté reçoit ce message, l'hôte est informé d'une connexion. Il peut accepter ou rejeter la demande de connexion en envoyant soit LMP_host_connection_req soit LMP_not_accepted.

Figure 3.6 : Connexion

Si le message LMP est accepte, les procédures LMP (authentification par exemples) peuvent être appelées.
Quand toutes ces procédures sont terminées, l'envoie du message LMP_setup_complete est effectué par les deux côtés.
Et enfin, on peut commencer à envoyer les premiers paquets sur un canal logique.

L2CAP : Logical Link Control and Adaptation Protocol (Contrôle des Liaisons Logiques et Protocole d'Adaptation)

Ce protocole permet l'utilisation de protocoles de moyen niveau (cf. Composants des systèmes Bluetooth) et le multiplexage des informations qui sont transmise par ses même protocoles.
Il fait donc la transition entre le HCI (Host Controller Interface) et le logiciel. Il permet de segmenter et de reconstituer les paquets qu'il reçoit. Les paquets créés à destinations des couches inférieures ont une taille de 64 koctets. Les paquets devant excéder cette taille sont découpés en plusieurs morceaux, puis réassemblés à l'arrivé par ce même protocole.

Les services de base disponibles par ce protocole sont les suivant :

Connection: setup , configure , disconnect
Data: read , write
Group: create, close, add member, remove member , get membership
Information: ping, get info, request a call-back at the occurrence of an event
Connection-less Traffic: enable, disable

Nous en resterons là pour cette partie.

SDP : Service Discovery Protocol (Protocole de Découverte des Services)

Ce protocole est utile pour se renseigner sur l'environnement extérieur. Il permet aux applications de découvrir les services disponibles et de déterminer les caractéristiques de ces services.
Le SDP utilise le modèle Question/Réponse. Cela consiste à envoyer une seule requête et à recevoir une seule réponse.

Requête Client/Serveur SDP

Figure 6 : Communication un Client et un Serveur SDP

Le principe de SDP est le suivant :

L'application client demande une ressource particulière (service d'une autre unité Bluetooth),

Si la ressource existe et est disponible alors le serveur renvoi des informations de connexion.

Dans le cas contraire (n'existe pas ou n'est pas disponible), une réponse négative (message d'erreur) est envoyée. Ou une absence de réponse est détectée.

Et enfin, lorsqu'une ressource est trouvée, la connexion à l'unité Bluetooth se fait au moyen des protocoles habituels.

Bilan de l'étude

Dans ce rapport, on a étudié les différentes couches de protocole du système Bluetooth, et on a développé le protocole LMP en détail.
On a vu l'utilité d'une telle technologie, mais certains problèmes de sécurité sont discutables.
Notamment la création de la clef d'initialisation basée sur le code PIN, généralement composé de 4 digits est discutable.
Et aussi l'utilisation du No de série dans les mécanismes de sécurité pourrais rendent le système non confidentiel.

La première version de Bluetooth était défaillante dans certaines parties. Des bug avaient été détectés. Selon certains articles, le système Bluetooth n'était pas compétitif et le prix était encore trop élevé par rapport aux services rendus.
A présent, avec la version 1.1, on peut espérer voir se produit émerger d'avantage.

Il est indéniable qu'un système de communication sans fil sera largement utilisé dans un futur proche. Son utilisation touche tous les domaines et sera répandu à très grande échelle. Bluetooth a tous les atouts lui permettant de devenir la norme de communication sans fil du futur : en plus d'être robuste, fiable et peu chère, la technologie bluetooth a réuni de nombreux partenaires importants. La plupart préparent pour l'année 2001 et 2002 des appareils bluetooth. Les deux années à venir seront déterminantes.
De plus, bluetooth ne souffre pas de trop grande concurrence : la seule solution réellement concurrente est Airport (développé par Apple). Airport offre une meilleure bande passante (10Mb/s) mais il est surtout prévu pour une utilisation en LAN, contrairement à blutooth qui possède un domaine d'application nettement plus grand ! De plus, Airport est une solution bien plus cher que bluetooth et, vu son domaine d'application restreint, n'est pas amené à baisser.
Malgré tout, les débits que bluetooth offre pour le moment ne sont pas suffisant pour les applications de demain (relier le lecteur de DVD à la télévision, ...) et cette norme doit évoluer pour suivre une demande qui deviendra de plus en plus exigeante.

La norme Bluetooth 2.0 est déjà en cours d´élaboration. Elle repoussera les distances de communication à une centaine de mètres et devrait encore étendre le nombre de périphériques communicants au sein des réseaux Bluetooth. Le débit autorisé devrait également passer à 10 Mb/s.

Est ce que bluetooth réussira son pari et deviendra la norme de connexion sans fil ? Seul l'avenir nous le dira.

Bibliographie

bluetooth.org	Sur ce site, on peut trouver la "Specification of the Bluetooth System" version 1.1 en date du 22 Février 2001. Il s'agit de notre manuel de référence (sous format PDF).
Bluetooth ressource center	Ce site nous a aidé à mieux comprendre les spécifications du manuel précédent.
Site officiel de Bluetooth	Ce site est à but commercial. On n'a pas trouver d'information réellement pertinentes.
Le Monde de L'Informatique	Certaines informations de ce site ont vraiment été utiles à la compréhension de certains points. De plus, ce site regorge d'informations économiques.
Bluetooth sur m-indya.com	Sur ce site, on trouve des descriptions intéressantes qui nous ont permis de démarrer ce rapport.
Google	Ce moteur de recherche nous a livré quelques sites d'ordre secondaire, mais toutefois utiles.

Acronymes

ACL	Asynchronous Connection-Less
HCI	Host Controller Interface
L2CAP	Logical Link Control and Adaptation Protocol
LMB	bit de poids fort
LMP	Link Manager et le protocole
LSB	bit de poids faible
PDU	Protocol Data Unit (message)
RFCOMM	Emulation du protocole de câble série
SCO	Synchronous Connection-Oriented
SDP	Service Discovery Protocol
slot	Intervalle de temps minimum pour la transmission d'une information. Sa valeur est de 625 µs.
TCS BIN	Telephony Control protocol Specification BINary
WAP	Protocole d'emission sans fil