Bluetooth 50 ou 723.2 kb/s?

Bluetooth 50 ou 723.2 kb/s? Damien Vionnet (damien.vionnet@eif.ch) & Jean-Frédéric Wagen (wagen@eif.ch) HES-SO EIA-Fribourg 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 suite en page 5 fig. 1 architecture du projet PAN

suite de la première page 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. 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. 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. 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). 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 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: FI 8 25 octobre 2005 page 5

z soit esclave d un Piconet et maître de l autre Piconet ou z 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. Time Division Duplex Pendant la durée d une connexion, le temps est divisé en time slot d une durée de 625 ms (=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). fig. 4 exemple de Scatternet 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 ms. 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. fig. 5 exemple de transmission 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: z 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). z 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: FI 8 25 octobre 2005 page

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). 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 à: Type z la protection des données: pour un codage FEC 2/3, trois bits sont transmis pour 2 bits utiles. z le nombre de slots qu utilise l émetteur. Ce nombre peut être de 1, 3 ou 5 (fig. 7). 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. En-tête [B] Données [B] FEC 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). Symétrique [kb/s] Asymétrique [kb/s] Envoi Retour DM1 1 0-17 2/3 108.8 108.8 108.8 DH1 1 0-27 Aucun 172.8 172.8 172.8 DM3 2 0-121 2/3 258.1 387.2 54.4 DH3 2 0-183 Aucun 390.4 585.6 86.4 DM5 2 0-224 2/3 286.7 477.8 36.3 DH5 2 0-339 Aucun 433.9 723.2 57.3 tableau 1 types de paquets ACL 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: FI 8 25 octobre 2005 page 7

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). 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 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 z Pentium 4 2,8 GHz avec 496 MB de RAM. z Windows XP Service Pack 2. z ANYCOMM BT-120 Bluetooth USB dongle. z Stack Bluetooth: 1.4.3 de WIDCOMM. z jsdk 1.4.2_05. z Api JSR-82 de Avetana pour l accès à Bluetooth via JAVA. z Quick n Easy FTP serveur 3.0 Professionnel (Démo version) fig. 9 schéma de mesure 1 Un PC portable z Pentium M 1.4 GHz avec 768 MB de RAM z Windows XP Service Pack 2. z Acer BT-600 Bluetooth USB dongle z Stack Bluetooth: 1.3.2.7 de WIDCOMM z Quick n Easy FTP serveur 3.0 Professionnel (Démo version) fig. 10 schéma de mesure 2 Un Pocket PC z Qtek 9090 de 400 MHz et 128 MB de RAM. z Stack Bluetooth: BT-PPC/PE 1.0.0.3900 de WIDCOMM. z JVM 4.00 de CrEme. z Api JSR-82 de Avetana pour l accès à Bluetooth via JAVA Dans cette première expérience, nous réalisons un transfert de fichier FTP entre le PC et le portable (fig. 9). 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). 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 FI 8 25 octobre 2005 page 8

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. 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). 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 X i d une taille de x bytes à l esclave. Puis l esclave, une fois le paquet X i lu, envoie un paquet Y i 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 X i et la fin de la réception du paquet Y i. Les différents temps de traitement (processsing time) Tp sont indiqués ci-dessous (fig. 11) mais seul le temps total DT 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: z le temps d initialisation de l envoi du paquet X i (T p1 ). z le temps de traitement du paquet X i + le temps d initialisation de l envoi du paquet Y i (T p2 ). z le temps de traitement du paquet Y i (T p3 ). graphique 2 débit utile lors de mesures avec NetPerf fig. 11 schéma de mesure FI 8 25 octobre 2005 page 9

Comme nous pouvons choisir les tailles des paquets et mesurer le temps DT, 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. z 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 z z Les variables concernant les différents débits D x = débit du maître vers l'esclave (voir tableau 1) D y = débit de l'esclave vers le maître (voir tableau 1) D ux = débit utile du maître vers l'esclave D uy = débit utile de l'esclave vers le maître Les variables concernant les différents temps de traitement DT = temps entre l envoi d un paquet et la réception d un paquet du côté maître T p1 = temps de traitement pour l envoi d un paquet du côté maître T p2 = temps de traitement pour la réception d un paquet puis l envoi d un autre paquet du côté esclave T p3 = 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. Puis en utilisant une centaine de mesures, nous utilisons la méthode des moindres carrés afin de trouver les inconnues D ux et D uy. Une fois ces 2 inconnues trouvées nous pouvons facilement déterminer la valeur de D ux et de D uy. 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 DT 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 DT en fonction de la taille des paquets utiles en bytes. Les 2 courbes décrivent le temps DT 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. La méthode des moindres carrés permet d obtenir de ces mesures les débits utiles suivants: D1 154kb/s D 137 kb/s 2 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 Méthode utilisée pour la résolution du système L équation qui nous intéresse est l équation suivante: x est connu y est connu DT est mesuré D ux est la 1ère inconnue D uy est la 2ème inconnue 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: 1 ' Dux D ' ' ux T x Dux y Duy 1 ' Duy D uy graphique 3 moyenne sur 100 aller-retour (points) et 1000 aller-retour (lignes). 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. Le tableau 2 comprend les différents temps que nous calculons dans notre application test. FI 8 25 octobre 2005 page 10

fig. 12 schéma de mesures pour L2CAP fig. 13 schéma de mesures pour RFCOMM 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 (D y ) est d environ 100 kb/s supérieur au débit maître esclave (D x ). 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 (D y ) est supérieur au débit maître esclave (D x ). De plus, nos mesures indiquent l inefficacité surprenante du PC lorsqu il est le maître. Nom Connexion Rôle Début Fin T S L2CAP M Avant l envoi de x 1 Avant la réception de y 1 T R L2CAP M Avant la réception de y 1 Après la réception de y n T S L2CAP E Après la réception de x n Après la réception du paquet de 1 byte T R L2CAP E Avant la réception de x 1 Après la réception de x n T S RFCOMM M Avant l envoi de x 1 A lecture du 1er Byte de y 1 T R RFCOMM M A la réception du 1er byte de y 1 Après la réception de x n T S RFCOMM E Après la réception de x n Après la réception du paquet de 1 byte T R RFCOMM E A la réception du 1er byte de x 1 Après la réception de x n tableau 2 FI 8 25 octobre 2005 page 11

graphique 4 débit utile pour une connexion L2CAP graphique 5 débit utile pour une connexion RFCOMM 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) 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. 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. fig. 14 schéma de mesure Nom Connexion Rôle Début Fin T S L2CAP/RFCOMM M Après l envoi du paquet A Après la réception du paquet B T R L2CAP/RFCOMM M Après la réception du paquet B Après la réception de y n T S L2CAP/RFCOMM E Après la réception de x n Après la réception du paquet C T R L2CAP/RFCOMM E Après la réception du paquet A Après la réception de x n FI 8 25 octobre 2005 page 12 tableau 3

graphique 6 débit utile pour une connexion L2CAP graphique 7 débit utile pour une connexion RFCOMM 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. Comme pour les mesures avec L2CAP, les débits cidessus 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 (D y ) est supérieur au débit maître-esclave(d x ). 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: D x-l2cap l 8 6728 717 kb/s 12 12 625 10 Byte bit L2CAP Byte s 6 T time slot 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: D x-l2cap l 8 3368 358kb/s 12 12 625 10 Byte bit L2CAP Byte s 6 T time slot 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: D x-rfcomm l 8 1268 134kb/s 12 12 625 10 Byte bit RFCOMM Byte s 6 T time slot Ainsi, en admettant: l la taille en bytes des données utiles dans un paquet L2CAP. l MTU la taille maximale à spécifier dans l établissement de la connexion avec JSR-82. l Baseband la taille en bytes de données utiles dans un paquet baseband (DHx ou DMx, voir tableau 1). N Tx le nombre de time slots utilisés pour l émission: 1, 3 ou 5. N Rx le nombre de time slots utilisés pour la réception: toujours égal à 1. T time slot la durée en seconde d un time slot: 625 ms. l 8 l 8 Dx l kb/s l 672 MTU 6 ( N ) (5 1) 625 10 Tx NRx Ttime slot l 339 Baseband le débit utile D x 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: FI 8 25 octobre 2005 page 13

z l environnement de propagation, z l implémentation de l API, z le système d exploitation ou z 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 œuvre 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 fig. 15 démonstrateur du projet PAN FI 8 25 octobre 2005 page 14

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 œuvre 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. Références z Spécifications Bluetooth: Coverd core package v 1.2: www.bluetooth.com (visité le 05.08.2005) z An Introduction to Programming the Java APIs for Bluetooth (JSR 82) on Symbian OS: www.symbian. com/developer/techlib/papers/jabwt/jabwt_1_0.pdf (visité le 16.09.2005) z Spécifications pour RFCOMM: TS 07.10 version 7.10: www.etsi.org (visité le 05.08.2005) z Présentation couche HCI et L2CAP: www.xgarreau. org/aide/devel/bluetooth/slides_bluetooth.pdf (visité le 05.08.2005) z Cours sur Bluetooth par Stéphane Ubéda, INSA Lyon: citi.insa-lyon.fr/~subeda/(visité le 12.09.2005) z Présentation de Bluetooth par Apurva Kumar du centre de recherche d IBM en Inde: bluehoc.sourceforge.net/pres/ pres3/bt-pres_files/bt-pres.ppt (visité le 05.08.2005) z Introduction à Bluetooth par Luc Bergevin: www. dmi.usherb.ca/~sgiroux/cours/2004/ift689/fichiers/transparents/ift689_9_bluetooth.ppt (visité le 05.08.2005) z Interférence Bluetooth - WLAN: www.ee.ucl.ac.uk/lcs/ papers2003/125.pdf (visité le 12.09.2005) z API JSR-82 d Avetana: www.avetana-gmbh.de/avetanagmbh/produkte/jsr82.eng.xml (visité le 23.09.2005) n