FLASH INFORMATIQUE FI



Bluetooth, 50 ou 723.2 kb/s ?




Jean-Frédéric WAGEN

Damien VIONNET


Le contexte du projet Personal Assistance Networks (PAN)

Les écoles d’ingénieurs d’Yverdon (EIVD) et de Fribourg (EIA-FR) se lancent dans la télémédecine avec le projet PAN (Personal Assistance Networks). Ce projet consiste à mettre en place une chaîne de surveillance pour des patients en milieu non hospitalier (fig. 1). Chaque patient est équipé de différents capteurs médicaux reliés au réseau Internet via un terminal mobile tel qu’un PDA ou un Smartphone. Les données des différents capteurs sont envoyées puis traitées par un serveur d’applications capable de générer des notifications ou des alarmes au personnel soignant (médecin, ambulancier, aide,...). Ce suivi à distance permet à des patients à faible risque, mais que l’on préfère actuellement garder dans un hôpital pour des raisons de sécurité, de profiter d’une surveillance à distance qui leur permettrait de rester à la maison, de se déplacer où bon leur semble et ainsi de jouir d’une plus grande liberté. Cette liberté devrait permettre une qualité de vie accrue propice à un meilleur rétablissement. Coûts et économies étant des termes dominants actuellement, nos solutions sont basées autant que possible sur des appareils relativement peu coûteux, des technologies existantes et des logiciels libres.

JPEG - 14.7 ko
fig. 1
architecture du projet PAN

Afin d’améliorer et de simplifier la vie du patient, nous avons décidé d’utiliser des capteurs sans fil. Il existe différentes technologies de transmission sans fil, mais la technologie la plus développée semble être Bluetooth. Cette technologie permet d’émettre à une distance raisonnable tout en utilisant peu de puissance. Pour définir les débits et/ou le nombre maximal de capteurs que nous pouvons utiliser avec une connectique Bluetooth, l’EIA-FR a étudié cette technologie dans un premier temps, puis effectué différentes mesures afin de déterminer le débit utile réellement disponible en pratique.
La présentation de notre étude commence par une brève introduction sur la technologie sans fil Bluetooth en se concentrant sur les aspects de la transmission radio et de l’utilisation des Application Programming Interface (API) pour contrôler cette transmission Bluetooth. Une API Java a été choisie afin d’offrir le maximum de portabilité. La section Mesures du débit utile décrit notre modèle de mesures ; elle est suivie d’une présentation et d’une analyse des résultats des mesures et d’une conclusion.

Bluetooth

Introduction

Bluetooth est une technologie sans fil permettant de créer des réseaux ad hoc entre au maximum 8 appareils. Son rayon d’action est d’environ dix mètres, ce qui est relativement faible, mais largement suffisant pour créer un réseau avec des appareils relativement proches tel qu’un réseau de capteurs sur un patient. Un grand avantage de Bluetooth est qu’il est conçu pour fonctionner sur des appareils à faible puissance d’où une faible consommation d’énergie. D’autre part, l’utilisation de Bluetooth progresse ; ainsi, des capteurs SpO2 (Saturation de l’hémoglobine en oxygène par oxymétrie de pouls) existent déjà commercialement. De plus, contrairement à l’IRDa (norme de transmission infrarouge), les ondes radio Bluetooth dans la bande libre ISM aux environs de 2.4 GHz n’ont pas besoin de la vue directe entre les équipements. Finalement, Bluetooth résiste mieux que le Wi-Fi lorsqu’ils s’interfèrent dans la bande ISM. 
Les spécifications de Bluetooth annoncent un débit maximum de 723 kb/s en utilisation asymétrique. En pratique, les conditions de propagation, les équipements et les couches logicielles intervenant dans les applications ne permettent pas d’atteindre ce maximum. Pour des applications en télémédecine, il est critique de connaître quels capteurs peuvent être utilisés. Ainsi, nous avons décidé de vérifier les débits utiles de Bluetooth aux niveaux applicatifs avec un des outils actuels de programmation et des équipements disponibles commercialement : la Java API for Bluetooth (JSR-82) sur PC, un PocketPC/Smartphone. Ceci devrait permettre aux créateurs d’applications et aux gestionnaires de projets de mieux cerner les possibilités de Bluetooth.

Possibilités d’interconnexion Bluetooth

Notion de Maître / Esclave

Pour chaque connexion Bluetooth il y a un appareil maître et un ou des appareils esclaves (fig. 2). Les esclaves peuvent communiquer uniquement avec le maître. C’est aussi le maître qui définit la séquence des changements de canal radio (voir § Accès à la bande radio). Ainsi, chaque esclave est synchronisé avec son maître.

JPEG - 12 ko
fig.2
Maître/Esclave

Piconet

Une possibilité d’interconnexion définie par Bluetooth permet de créer un mini réseau d’appareils. Un appareil est le maître et les autres appareils sont les esclaves. Il peut y avoir au maximum 7 esclaves actifs en même temps ou 255 esclaves inactifs. Ceci est appelé un Piconet (fig. 3).

JPEG - 16.5 ko
fig. 3
exemple de Piconet

Scatternet

La troisième et dernière possibilité est de créer un Scatternet (fig. 4). Cela est représenté par une interconnexion de Piconet via un appareil appartenant à deux Piconets. Cet appareil permettant l’interconnexion peut être :

JPEG - 26.8 ko
fig.4
exemple de Scatternet
  • soit esclave d’un Piconet et maître de l’autre Piconet ou
  • esclave des 2 Piconets.
    Il est par contre impossible d’avoir un appareil étant maître pour 2 Piconets. On peut interconnecter au maximum 10 Piconets.

Limitations

Bluetooth permet un nombre maximum de 8 équipements actifs simultanément par Piconet. Un autre mode Bluetooth : le mode parked permet d’étendre cette limitation à 256 au prix de délais pour réveiller les équipements parqués.

Accès à la bande radio

La technologie Bluetooth utilise une bande de fréquence dite ISM (Industrial, Scientific, and Medical) de 2.4 GHz à 2.4835 GHz. Cette bande de fréquence est divisée en 79 canaux de 1 MHz. Pour permettre à plusieurs appareils de transmettre en même temps, Bluetooth utilise 2 principes.

  • Frequency Hopping ->le saut de fréquence pour la communication entre l’émetteur et le récepteur.
  • Time Division Duplex ->la division de temps pour le duplexage entre le maître et chaque esclave.

Frequency Hopping

Ce principe consiste à ce que tous les appareils communiquant ensemble effectuent un saut de fréquence (changement de canal) à une fréquence déterminée par le maître. Cette technique implique que tous les esclaves doivent être synchronisés sur l’horloge du maître afin d’effectuer en même temps le saut de fréquence. Le nombre de sauts de fréquence est de 1600/s durant la connexion, soit un saut toutes les 625 µs. Lors de la recherche d’appareils ou de l’établissement de la connexion, le nombre de sauts de fréquence est doublé pour atteindre 3200/s.

Time Division Duplex

Pendant la durée d’une connexion, le temps est divisé en time slot d’une durée de 625 µs (=1/1600 s). Chaque transmission doit commencer au début d’un time slot et dure 1, 3 ou 5 time slots. Le numéro du time slot correspond à la valeur de l’horloge du maître. L’horloge d’un appareil Bluetooth est un compteur sur 28 bits allant ainsi de 0 à 228-1 time slots. Les numéros se ne répètent donc que tous les 2 jours de transmission continue. Le maître doit commencer une émission sur les slots pairs tandis que les esclaves doivent commencer une émission sur les slots impairs. Le débit radio est de 1 Mb/s pour la modulation binaire spécifiée dans Bluetooth (version 1.x, c’est-à-dire sans enhanced data rate). Ainsi, au niveau radio, le duplexage temporel ne permet qu’un débit symétrique de 500 kb/s (1/2 de 1 Mb/s). Les débits asymétriques sont de 833 kb/s et 167 kb/s (5/6ème et 1/6ème de 1 Mb/s) en utilisant une transmission sur 5 time slots puis une réception sur un seul time slot. Les en-têtes nécessaires à la transmission des données utiles diminuent encore les débits disponibles pour les applications (voir tableau 1).

JPEG - 10 ko
fig. 5
exemple de transmission


TypeEn-tête[B]Données [B]FECSymétrique [kb/s]Asymétrique [kb/s]
EnvoiRetour
DM110 - 172/3108.8108.8108.8
DH110 - 27Aucun172.8172.8172.8
DM320 - 1212/3258.1387.254.4
DH320 - 183Aucun390.4585.686.4
DM520 - 2242/3286.7477.836.3
DH520 - 339Aucun433.9723.257.3

tableau 1 - types de paquets ACL


Les protocoles Bluethooth

La pile des couches des protocoles définis par le standard Bluetooth est séparée en deux types : les couches de haut niveau et les couches de bas niveau.
Pour les couches de bas niveau nous avons :

la couche baseband :

La couche baseband gère les différents types de liaisons Bluetooth :

  • Liaison synchrone (SCO) : ce type de liaisons offre un débit synchrone de 64 kb/s dans les deux directions. En théorie, Bluetooth permet 3 liaisons synchrones simultanées (ce type de liaison n’est pas investigué ici).
  • Liaison asynchrone (ACL) : ce type de liaisons offre un débit maximal de 732 kb/s pour la transmission de donnée sans garantie de délai.

la couche HCI (Host Controller Interface)

La couche HCI permet aux couches supérieures d’accéder aux couches inférieures en leur offrant une liste de primitives de service.
La Java API for Bluetooth (JSR-82) ne permet pas d’accéder à ces couches de bas niveau.
Pour les couches de haut niveau nous avons :

la couche L2CAP (Logical Link Control and Adaptation Protocol) :

Cette couche offre la possibilité de créer des liaisons asynchrones (ACL) entre les appareils. Ces liaisons peuvent être sans connexion ou orientées connexion. Le L2CAP gère donc les problèmes de multiplexages, la segmentation, le réassemblage et la qualité de service. La taille maximale de la charge utile d’une trame L2CAP est définie lors de l’établissement de la connexion. Cette taille est appelée MTU (Maximum Transmission Unit). La taille minimale d’un MTU est de 48 bytes, mais la valeur par défaut est souvent de 672 bytes. L’OS Symbian (pour les mobiles Nokia et Ericsson par exemple) limite ce MTU à un maximum de 672 bytes. Le flux, par paquets d’au moins 384 bits, est encapsulé puis passé à la couche HCI qui les répartit sur les n fois 625 bits de la couche baseband (n=1 à 5).
La Java API for Bluetooth (JSR-82) permet de choisir la taille des MTU (émission et réception).

la couche RFCOMM (Radio Frequency Communication) :

Cette couche permet de créer une connexion série/RS-232 entre deux appareils via Bluetooth. La taille maximale d’une trame RFCOMM est définie lors de l’établissement de la connexion de manière invisible pour la Java API for Bluetooth (JSR-82).

JPEG - 15.9 ko
fig. 6
modèle Bluetooth vs modèle OSI

Les types de paquets ACL

Les paquets Bluetooth de la couche baseband peuvent être de tailles différentes même si un nombre entier de time slots est utilisé. Ainsi, même un paquet de 10 bytes peut occuper 5 time slots. Le tableau 1 Types de paquets ACL décrit les différents types de paquets qui sont disponibles lors d’une liaison asynchrone ACL ainsi que les débits théoriques correspondants. Les différences sont dues à :

  • la protection des données : pour un codage FEC 2/3, trois bits sont transmis pour 2 bits utiles.
  • le nombre de slots qu’utilise l’émetteur. Ce nombre peut être de 1, 3 ou 5 (fig. 7).
    JPEG - 10.3 ko
    fig. 7
    exemple d’utilisation de slots pour l’émission par le master de paquet DH3 puis DH5

Le CQDDR (Channel Quality Driven Data Rate) s’occupe de choisir le type de paquets le plus approprié à utiliser parmi ceux indiqués dans le tableau 1. Ce choix de type de paquets est fait avant l’établissement de la connexion L2CAP via le protocole LMP (Link Manager Protocol). Le CQDDR dépend du fabricant. Aucun contrôle n’est possible avec la Java API for Bluetooth (JSR-82). Ainsi, il est possible, comme les mesures tendent à le montrer, que 5 slots soient réservés pour envoyer un faible nombre de bits si le programmeur d’une application n’y prend pas garde.

Segmentation & réassemblage

Afin de préciser les opérations de segmentation, réassemblage et l’encapsulation des paquets dans les couches mentionnées ci-dessus, la figure 8 montre un exemple pour un paquet de données au niveau RFCOMM et son encapsulation dans 3 paquets transmis par l’émetteur Bluetooth.

JPEG - 5.5 ko
fig. 8
exemple de fragmentation au niveau baseband

En partant de la couche RFCOMM, voici comment sont choisies les tailles de paquets, comme résumé de ce qui a été mentionné dans la section précédente :

Couche RFCOMM

La taille d’un paquet RFCOMM est négociée lors de l’établissement de la connexion RFCOMM par le firmeware Bluetooth. Le programmeur d’application utilise la connexion RFCOMM comme un port série (port COM), c’est-à-dire comme l’écriture ou la lecture d’un fichier. Il n’y a aucune notion de taille de paquet dans l’utilisation de RFCOMM : utilisation d’un flux (stream).

Couche L2CAP

La taille des paquets est définie lors de l’établissement de la connexion par l’API JSR-82. Le programmeur peut donner ce paramètre appelé MTU (Maximum Transmission Unit) qui vaut au minimum 48 bytes et 672 bytes par défaut.

Couche HCI

La couche HCI ne segmente pas les paquets. Seule une en-tête est ajoutée.

Couche baseband

La taille des paquets est définie par le type de paquet DM ou DH et du nombre de time slots utilisés pour un lien ACL (voir tableau 1).
Mesures du débit utile

Le but des mesures est de pouvoir déterminer les débits utiles à disposition pour une application utilisant une connexion Bluetooth en général et la Java API for Bluetooth (JSR-82) en particulier.

Matériels utilisés

Un PC

  • Pentium 4 2,8 GHz avec 496 MB de RAM. 
  • Windows XP Service Pack 2.
  • ANYCOMM BT-120 Bluetooth USB dongle.
  • Stack Bluetooth : 1.4.3 de WIDCOMM. 
  • jsdk 1.4.2_05.
  • Api JSR-82 de Avetana pour l’accès à Bluetooth via JAVA.
  • Quick n’ Easy FTP serveur 3.0 Professionnel (Démo version)

Un PC portable

  • Pentium M 1.4 GHz avec 768 MB de RAM
  • Windows XP Service Pack 2.
  • Acer BT-600 Bluetooth USB dongle
  • Stack Bluetooth : 1.3.2.7 de WIDCOMM
  • Quick n’ Easy FTP serveur 3.0 Professionnel (Démo version)

Un Pocket PC

  • Qtek 9090 de 400 MHz et 128 MB de RAM. 
  • Stack Bluetooth : BT-PPC/PE 1.0.0.3900 de WIDCOMM. 
  • JVM 4.00 de CrEme.
  • Api JSR-82 de Avetana pour l’accès à Bluetooth via JAVA

Contexte des mesures

Les mesures ont été prises dans un environnement de bureau relativement classique. La pièce est un grand bureau pour 4 personnes. Le PC et ainsi le dongle Bluetooth se trouvent sous le bureau. Le PC portable est posé sur le bureau. Le Qtek et le téléphone portable sont posés dans leurs stations à moins d’un mètre du PC. Dans le bureau où les mesures ont été effectuées, un réseau Wi-Fi offre une bonne couverture, mais la borne Wi-Fi la plus proche est à plus de 4 mètres des équipements Bluetooth utilisés et ne devrait donc pas influencer les mesures (voir Références Interférence Bluetooth - WLAN).
Notre application est une application JAVA utilisant une implémentation faite par la société Avetana de l’Api JSR-82 pour le contrôle de Bluetooth par notre logiciel de mesure.

Expérience 1

Schéma de mesure

Dans cette première expérience, nous réalisons un transfert de fichier FTP entre le PC et le portable (fig. 9).

JPEG - 17 ko
fig. 9
schéma de mesure 1

Puis nous allons effectuer une deuxième mesure en utilisant le logiciel d’analyse de débit utile NetPerf entre les mêmes appareils (fig. 10).

JPEG - 12.2 ko
fig. 10
schéma de mesure 2

Nous utilisons le service Bluetooth permettant de créer des réseaux IP (service Network access ou PAN). Notre serveur FTP est un le serveur Quick n’Easy 3.0 Professionnel version DEMO et le client FTP de la console de Windows XP. Le client FTP indique quel était le débit durant le transfert du fichier. Le logiciel NetPerf retourne un débit utile mesuré pendant un intervalle de temps donné (10 s par défaut).

Résultat

FTP

Deux fichiers de 264 kB et 792 kB ont été transférés 3 fois du FTP serveur au client (fig. 15). Les résultats sont présentés dans la figure suivante.

JPEG - 5.8 ko
graphique 1
débit utile lors d’un transfert de fichiers FTP

Un débit utile de plus de 600 kb/s est obtenu. Les débits sont marginalement supérieurs dans le cas PC serveur vers Laptop client, c’est-à-dire lorsque les paquets TCP transportant des données utiles sont envoyés du PC vers le laptop.

NetPerf

En utilisant le logiciel NetPerf, les mesures de débits utiles ci-dessous ont été réalisées. La durée des mesures est de 3 ou 10 secondes. La taille des paquets est de 1, 500 ou 1000 octets (données TCP).

JPEG - 9.1 ko
graphique 2
débit utile lors de mesures avec NetPerf

Les résultats confirment que le PC envoie les paquets (PC client NetPerf, Laptop serveur NetPerf) marginalement plus vite que le Laptop. La dispersion des mesures ne semble pas être influencée par la durée des mesures.
Ces mesures montrent qu’un débit de 600 kb/s peut être obtenu avec Bluetooth. Ce débit de 600 kb/s ne peut être obtenu qu’avec des paquets DH5 qui permettent d’offrir le plus grand débit de l’interface radio Bluetooth. Comme nous désirons programmer notre propre application utilisant Bluetooth et mesurer les performances dans ces nouvelles conditions, les mesures FTP et NetPerf ne sont pas poursuivies.

Expérience 2

Schéma de mesure

Nous avons programmé une application de test en JAVA permettant d’établir une connexion RFCOMM/Bluetooth entre deux appareils. Le RFCOMM a été choisi pour sa simplicité de programmation. L’API JSR 82 nous permet de choisir le maître. Ainsi dans notre application le maître va envoyer un paquet Xi d’une taille de x bytes à l’esclave. Puis l’esclave, une fois le paquet Xi lu, envoie un paquet Yi d’acquittement d’une taille de y bytes. Enfin, du côté maître, l’application calcule la différence de temps entre le début de l’envoi du paquet Xi et la fin de la réception du paquet Yi. Les différents temps de traitement (processsing time) Tp sont indiqués ci-dessous (fig. 11) mais seul le temps total DeltaT peut être mesuré précisément au niveau des API et logiciels à disposition. La gestion des mémoires tampons de transmission et de réception n’est pas contrôlée par l’API JSR-82. On définit :

  • le temps d’initialisation de l’envoi du paquet Xi (Tp1).
  • le temps de traitement du paquet Xi + le temps d’initialisation de l’envoi du paquet Yi (Tp2).
  • le temps de traitement du paquet Yi (Tp3).
    JPEG - 18.9 ko
    fig. 11
    schéma de mesure

Comme nous pouvons choisir les tailles des paquets et mesurer le temps DeltaT, nous pouvons admettre un certain modèle pour les temps inconnus, puis obtenir ces inconnues en variant les paramètres connus pour obtenir des équations à résoudre par la méthodes des moindres carrés.

Résolution

Définition des différentes variables

Nous définissons 3 types de variables concernant (1) la taille des paquets, (2) les débits, et (3) les temps de traitement.

  • Les variables concernant les paquets envoyés
    x = taille des paquets envoyés par le maître
    y = taille des paquets envoyés par l’esclave
  • Les variables concernant les différents débits
    Dx = débit du maître vers l’esclave (voir tableau 1)
    Dy= débit de l’esclave vers le maître (voir tableau 1)
    Dux = débit utile du maître vers l’esclave
    Duy = débit utile de l’esclave vers le maître
  • Les variables concernant les différents temps de traitement
    DeltaT = temps entre l’envoi d’un paquet et la réception d’un paquet du côté maître
    Tp1 = temps de traitement pour l’envoi d’un paquet du côté maître
    Tp2 = temps de traitement pour la réception d’un paquet puis l’envoi d’un autre paquet du côté esclave
    Tp3 = temps de traitement pour la réception d’un paquet du côté maître

Voici les différentes équations qui nous permettent de déterminer les débits utiles.


Méthode utilisée pour la résolution du système

L’équation qui nous intéresse est l’équation suivante :



C’est cette équation qui permet de déterminer les débits utiles. Pour résoudre cette équation, nous allons effectuer plusieurs mesures afin d’obtenir un système surdéterminé.
Nous allons ensuite résoudre ce système à l’aide d’une substitution pour avoir des équations de la forme :


Puis en utilisant une centaine de mesures, nous utilisons la méthode des moindres carrés afin de trouver les inconnues Dux’ et Duy’ . Une fois ces 2 inconnues trouvées nous pouvons facilement déterminer la valeur de Dux et de Duy .
Maintenant que nous connaissons les 2 débits utiles, il devrait être possible de retrouver les valeurs des débits réels, mais étant donné que nous ne pouvons pas déterminer le temps de traitement, nous ne pouvons qu’estimer les débits radio du tableau 1 qui pourrait être utilisé en faisant des hypothèses sur les temps de traitements.

Résultats

Les résultats bruts, donnant le temps total DeltaT en ms, sont présentés dans les figures suivantes. Les résultats sont discutés dans le chapitre suivant.
Chaque figure présente 2 courbes de DeltaT en fonction de la taille des paquets utiles en bytes. Les 2 courbes décrivent le temps DeltaT mis par le maître pour envoyer un paquet de x bytes et de lire un paquet d’acquittement de y bytes en fonction de la taille totale de bytes transmits (x+y). Sur le Graphique 3, chaque point représente une moyenne sur 100 échanges. Les courbes représentent des moyennes sur 1000 échanges.

JPEG - 8.2 ko
graphique 3
moyenne sur 100 aller-retour (points) et 1000 aller-retour (lignes)

La méthode des moindres carrés permet d’obtenir de ces mesures les débits utiles suivants :


Ces débits sont 5 fois plus petits que ceux obtenus dans les mesures avec FTP et NetPerf. Nous avons donc modifié notre application pour analyser ce résultat étonnant.

Connexion RFCOMM entre le PC et Qtek

Expérience 3

Schéma de mesure

Nous avons programmé une application test permettant de déterminer quels sont les différents débits utiles d’une connexion L2CAP (fig. 12) ou RFCOMM (fig. 13). L’appareil Maître va envoyer n paquets de x bytes à l’appareil Esclave. L’appareil Esclave va ensuite renvoyer n paquets de y bytes à l’appareil Maître et pour finir l’appareil Maître envoie un paquet de 1 byte à l’appareil Esclave.

JPEG - 24.3 ko
fig. 12
schéma de mesures pour L2CAP
JPEG - 26.9 ko
fig. 13
schéma de mesures pour RFCOMM

Le tableau 2 comprend les différents temps que nous calculons dans notre application test.

Nom Connexion Rôle Début Fin
TS L2CAP M Avant l’envoi de x1 Avant la réception de y1
TR L2CAP M Avant la réception de y1 Après la réception de yn
TS L2CAP E Après la réception de xn Après la réception du paquet de 1 byte
TR L2CAP E Avant la réception de x1 Après la réception de xn
TS RFCOMM M Avant l’envoi de x1 A lecture du 1er Byte de y1
TR RFCOMM M A la réception du 1er byte de y1 Après la réception de xn
TS RFCOMM E Après la réception de xn Après la réception du paquet de 1 byte
TR RFCOMM E A la réception du 1er byte de x1 Après la réception de xn

tableau 2

Calculs de débits utiles

Pour déterminer les débits utiles, nous effectuons les calculs suivants :



Résultats des mesures

Les résultats sont présentés sous forme de graphe représentant le débit utile en fonction de la taille des paquets envoyés. Les résultats sont discutés dans le chapitre suivant.
Pour L2CAP, le débit utile peut atteindre 600 kb/s si les paquets sont suffisamment grands (672 bytes), mais peut être inférieur à 50 kb/s en utilisant des petits paquets (10 bytes). Le graphique 4 montre qu’indépendamment de l’appareil (Qtek ou PC) le débit de l’esclave vers le maître (Dy) est d’environ 100 kb/s supérieur au débit maître esclave (Dx).
RFCOMM offre des débits d’environ 100 kb/s soit 6 fois inférieurs à ceux de L2CAP. Comme pour L2CAP, le graphique 5 montre, qu’indépendamment de l’appareil (Qtek ou PC), le débit de l’esclave vers le maître (Dy) est supérieur au débit maître esclave (Dx). De plus, nos mesures indiquent l’inefficacité surprenante du PC lorsqu’il est le maître.

Expérience 4

Schéma de mesure

Cette dernière expérience ressemble fortement à l’expérience précédente. Elle va aussi nous permettre de déterminer quels sont les différents débits utiles d’une connexion L2CAP ou RFCOMM. (fig. 14)

JPEG - 28.2 ko
fig. 14
schéma de mesure

L’appareil Maître va envoyer 1 paquet de 1 byte (paquet A) puis n paquets de x bytes à l’appareil Esclave. L’appareil Esclave va ensuite renvoyer 1 paquet de 1 byte (paquet B) puis n paquets de y bytes à l’appareil Maître et pour finir l’appareil Maître envoi un paquet de 1 byte (paquet C) à l’appareil Esclave. Les différents paquets de 1 byte (A, B et C) agissent comment une barrière de synchronisation.
Le tableau 3 comprend les différents temps que nous calculons.

Nom Connexion Rôle Début Fin
TS L2CAP/RFCOMM M Après l’envoi du paquet A Après la réception du paquet B
TR L2CAP/RFCOMM M Après la réception du paquet B Après la réception de yn
TS L2CAP/RFCOMM E Après la réception de xn Après la réception du paquet C
TR L2CAP/RFCOMM E Après la réception du paquet A Après la réception de xn

tableau 3


Résolution

Pour déterminer les débits utiles, nous effectuons les calculs suivants :


Les temps d’envoi et de réception des paquets d’un byte de synchronisation ainsi que les temps de traitement de notre application sont négligés.

Résultat

Les résultats sont présentés sous forme de graphe représentant le débit utile en fonction de la taille des paquets envoyés.
Les débits ci-dessus sont comparables à ceux de l’expérience 3 (graphique 4), mais la dispersion des valeurs est nettement plus faible. Il est par contre surprenant que pour les paquets de taille moyenne (336 bytes), le débit en transmission du PC lorsqu’il est le maître est diminué d’un facteur 2. Aucun moyen n’a été trouvé pour démontrer la cause de cette curieuse diminution.

JPEG - 7.1 ko
graphique 4
débit utile pour une connexion L2CAP

Comme pour les mesures avec L2CAP, les débits ci-dessus sont comparables à ceux de l’expérience précédente (expérience 3, graphique 5), mais la dispersion des valeurs est plus faible. Les mesures RFCOMM confirment la conclusion surprenante que le débit en transmission du PC lorsqu’il est le maître est plus faible. Ces mesures montrent à nouveau, qu’indépendamment de l’appareil (Qtek ou PC), le débit de l’esclave vers le maître (Dy) est supérieur au débit maître-esclave(Dx).

JPEG - 10.6 ko
graphique 5
débit utile pour une connexion RFCOMM
JPEG - 9.7 ko
graphique 6
débit utile pour une connexion L2CAP
JPEG - 10.1 ko
graphique 7
débit utile pour une connexion RFCOMM

Discussion des résultats

Dans les mesures avec FTP et NetPerf où les protocoles TCP/IP utilisent les logiciels fournis avec le dongle pour la gestion de Bluetooth, les résultats montrent un débit d’environ 620 kb/s ; légèrement inférieur au débit théorique maximum de 723 kb/s.
Les résultats des mesures utilisant les applications programmées avec l’API JSR-82 montrent des débits utiles variant de 1 à 600 kb/s. Pourquoi de telles différences entre l’utilisation de FTP et les applications utilisant l’API JSR-82 ?
Dans un premier temps, les débits ont été supposés indépendamment de la taille des paquets comme avec FTP ou NetPerf. Cette hypothèse s’est avérée partiellement fausse. En effet, le débit utile dépend de la taille des paquets L2CAP et du type de paquets baseband (DMx ou DHx). Bluetooth utilise une division temporelle qui permet d’expliquer la grande variation de débits utiles mesurés. Par exemple : deux appareils sont connectés via une liaison L2CAP. Les MTU sont de 672 bytes et le type de paquets baseband utilisés est DH5. Un paquet DH5 utilise 5 time slots et transporte une charge utile (payload) de 339 bytes. Ainsi, pour envoyer un paquet L2CAP de 672 bytes il faut 2 paquets baseband de 339 bytes. Le temps que met un appareil Bluetooth pour envoyer 2 paquets DH5 correspond à 2 fois « 5+1 » time slots soit 12 time slots. Le débit utile L2CAP sera donc de :


Le débit utile de 717 kb/s approche les 723 kb/s décrit en théorie. Par contre si un appareil envoie un paquet L2CAP de 336 bytes et que les paquets baseband sont de type DH5 le débit utile L2CAP sera plus faible :


Dans les expériences avec les connexions RFCOMM, l’analyseur de trame SpyLitle d’Anycom montre que le flux de données utiles est segmenté en paquet de 126 bytes. Ainsi, lorsque l’application écrit, par exemple, un paquet de 672 bytes, celui-ci est fragmenté en 5 paquets de 126 bytes et 1 paquet de 42 bytes. Le débit utile RFCOMM sera donc de :


Ainsi, en admettant :

l la taille en bytes des données utiles dans un paquet L2CAP.
lMTU la taille maximale à spécifier dans l’établissement de la connexion avec JSR-82.
lBaseband la taille en bytes de données utiles dans un paquet baseband (DHx ou DMx, voir tableau 1).
NTx le nombre de time slots utilisés pour l’émission : 1, 3 ou 5.
NRx le nombre de time slots utilisés pour la réception : toujours égal à 1.
Ttime slot la durée en seconde d’un time slot : 625 µs.



le débit utile Dx en [kb/s] est égale à la taille l en bytes si la taille de la MTU est de 672 bytes et le type de paquet est DH5.
Cette relation approximative ne tient pas compte d’autres paramètres pouvant influencer le débit, comme :

  • l’environnement de propagation,
  • l’implémentation de l’API,
  • le système d’exploitation ou
  • l’implémentation de l’application utilisant Bluetooth.
    Ainsi, dans de bonnes conditions de transmission, c’est-à-dire lorsqu’on suppose que Bluetooth transmet des paquets DH5, le programmeur devrait utiliser L2CAP au lieu de RFCOMM et segmenter les données en paquets de 600 bytes pour profiter du meilleur débit possible.


Conclusion

Sur les mesures

Les différentes mesures ont fait ressortir l’importance du choix du type de connexion (RFCOMM ou L2CAP) et de la taille des paquets pour les applications utilisant la Java API for Bluetooth (JSR-82). En effet si le développeur ne gère pas correctement la connexion Bluetooth, le débit à disposition pourrait devenir très faible ( 10 kb/s). Par contre lorsque la taille des paquets est choisie correctement, le débit à disposition devient 500 kb/s ou plus. Les variations des résultats montrent que le développeur doit aussi tenir compte d’autres paramètres pouvant influencer le débit utile tels que l’environnement de propagation, interférence dans la bande ISM, le système Windows, l’implémentation de l’API, etc.
Les résultats indiquent qu’avec l’API utilisée (Avetana JSR-82), une connexion L2CAP offre les plus hauts débits utiles aux prix d’une plus grande complexité de mise en oeuvre par rapport à RFCOMM. En utilisant L2CAP il est conseillé d’utiliser une taille de paquets égale à la MTU pour maximiser le débit utile. Avec l’API JSR-82 d’Avetana la MTU par défaut est de 672 bytes, ainsi la taille des paquets devrait être proche de cette valeur ( 600 bytes). De plus, une taille de MTU inférieure à la taille de la charge utile en baseband (type de paquets) diminue le débit utile. Malheureusement, l’API JSR-82 ne permet pas de connaître quel est le type de paquets baseband utilisé. Ainsi, il est conseillé d’utiliser une taille de paquets multiple de 300 bytes lorsque les conditions de propagation sont bonnes.
L’utilisation de RFCOMM est déconseillée pour l’API JSR-82 d’Avetana car la mise en oeuvre de RFCOMM ne permet pas de gérer la taille des paquets, ce qui risque de diminuer d’un facteur 6 le débit utile à l’application programmée.


Utilisation de Bluetooth dans notre Projet PAN

Dans le contexte du projet PAN, cette étude permet de dimensionner correctement l’application gérant les capteurs Bluetooth. L’intégration des capteurs suivants ne pose aucun problème pour l’application, par contre celle-ci devrait utiliser les paquets de type DH1 ou DM1 pour être efficace.

Capteur ECG à 12 dérivations -> 12 kb/s
Capteur Température -> 1 mesure (64 bits) chaque seconde
Récepteur GPS -> 9.6 kb/s
Saturométre -> 1 mesure (64 bits) chaque seconde



Si l’application gère correctement la connexion Bluetooth, il semble tout à fait plausible d’utiliser ce type de communication entre l’application du projet PAN et un grand nombre de capteurs. Par contre, un piconet Bluetooth ne peut avoir que 8 appareils actifs simultanément, cette limitation domine.
Actuellement le projet PAN utilise Bluetooth dans la configuration présentée à la figure 15. Trois connexions Bluetooth sont établies simultanément avec un Pocket PC (Qtek 9090). Les trois capteurs sont un téléphone portable Nokia 7610 simulant un capteur ECG, un téléphone portable Sony Ericsson P910 représentant un capteur de pression et un récepteur GPS de Tomtom. Pour les téléphones portables et Pocket PC les développements logiciels concernant Bluetooth se basent sur la Java API for Bluetooth (JSR-82) analysée dans cet article. L’intégration du récepteur GPS avec sa propre mise en oeuvre de Bluetooth n’a pas posé de problème malgré l’utilisation de l’API JSR-82 pour la réception. Dans la version actuelle les connexions Bluetooth utilisent le protocole RFCOMM, mais vu les résultats des expériences le protocole L2CAP sera utilisé dès que possible.
Des tests devraient être encore menés pour confirmer les avantages de L2CAP lorsque 2 ou plusieurs patients se trouvent proches les uns des autres.

JPEG - 17.6 ko
fig. 15
configuration du projet PAN


Références




Cherchez ...

- dans tous les Flash informatique
(entre 1986 et 2001: seulement sur les titres et auteurs)
- par mot-clé

Avertissement

Cette page est un article d'une publication de l'EPFL.
Le contenu et certains liens ne sont peut-être plus d'actualité.

Responsabilité

Les articles n'engagent que leurs auteurs, sauf ceux qui concernent de façon évidente des prestations officielles (sous la responsabilité du DIT ou d'autres entités). Toute reproduction, même partielle, n'est autorisée qu'avec l'accord de la rédaction et des auteurs.


Archives sur clé USB

Le Flash informatique ne paraîtra plus. Le dernier numéro est daté de décembre 2013.

Taguage des articles

Depuis 2010, pour aider le lecteur, les articles sont taggués:
  •   tout public
    que vous soyiez utilisateur occasionnel du PC familial, ou bien simplement propriétaire d'un iPhone, lisez l'article marqué tout public, vous y apprendrez plein de choses qui vous permettront de mieux appréhender ces technologies qui envahissent votre quotidien
  •   public averti
    l'article parle de concepts techniques, mais à la portée de toute personne intéressée par les dessous des nouvelles technologies
  •   expert
    le sujet abordé n'intéresse que peu de lecteurs, mais ceux-là seront ravis d'approfondir un thème, d'en savoir plus sur un nouveau langage.