IMPLEMENTACIN DE UNA RED INALMBRICA BLUETOOTH

OSCAR DARO RODRGUEZ CALVACHI RICARDO ANDRS MAYA CORAL

Trabajo de grado presentado como requisito para obtener el ttulo de Ingeniero Electrnico

Director FABIO G. GUERRERO MORENO

UNIVERSIDAD DEL VALLE FACULTAD DE INGENIERA ESCUELA DE INGENIERA ELCTRICA Y ELECTRNICA PROGRAMA DE INGENIERA ELECTRNICA SANTIAGO DE CALI 2003

Nota de aceptacin:

___________________________________ ___________________________________ ___________________________________ ___________________________________ ___________________________________ ___________________________________

___________________________________ Director: Fabio G. Guerrero Moreno

___________________________________ Jurado: Asfur Baradica Lpez

___________________________________ Jurado: Oscar Polanco Sarmiento

Santiago de Cali, Agosto de 2003

A mis padres, por todos sus consejos y apoyo incondicional. A mis hermanos, que es por quienes trato de ser cada da mejor para ser un ejemplo a seguir. A toda mi familia, que es mi apoyo en todo difcil momento de la vida. A todos ellos

Oscar Daro Rodrguez Calvachi

A mis padres, por su cario, comprensin y confianza. A mis hermanos que son mi pilar de apoyo y a mi familia, la fuente que me anima a seguir mi camino.

Ricardo Andrs Maya Coral

AGRADECIMIENTOS

A Fabio Guerrero, por su confianza y apoyo, a todos nuestros compaeros y amigos, quienes siempre estuvieron pendientes y nos apoyaron constantemente, a las empresas Ericsson Suiza y Dinamarca, RangStar USA y Suyin USA, por su invaluable ayuda, y a todos las personas que directa o indirectamente colaboraron en el desarrollo de este proyecto.Gracias.

CONTENIDO
pg.

INTRODUCCIN

22

1. DESCRIPCIN GENERAL DE LA TECNOLOGA INALMBRICA BLUETOOTH 1.1 BANDA BASE 1.1.1 Descripcin general. 1.1.2 Canal fsico. 1.1.3 Enlace fsico. 1.1.4 Paquetes. 1.1.5 Correccin de errores. 1.1.6 Transmisin/Recepcin. 1.1.7 Control de Canal. 1.1.8 Seguridad en Bluetooth. 1.2 PROTOCOLO DE GESTIN DE ENLACE (LMP) 1.2.1 Establecimiento de conexin. 1.3 INTERFAZ DEL CONTROLADOR DE HOST (HCI) 1.3.1 Capas mas bajas del stack Bluetooth. 1.3.2 Posibles arquitecturas de bus fsico. 1.4 PROTOCOLO DE CONTROL Y ADAPTACIN DE ENLACE LGICO (L2CAP) 1.4.1 Canales. 1.4.2 Operaciones entre Capas.

23 29 29 30 30 31 33 34 35 38 38 39 40 40 42 43 43 43

1.4.3 Segmentacin y Reensamblado. 1.4.4 Eventos. 1.4.5 Acciones. 1.4.6 Formato del paquete de datos. 1.4.7 Calidad de servicio (QoS). 1.5 PROTOCOLO DE DESCUBRIMIENTO DE SERVICIO (SDP) 1.5.1 Descripcin General. 1.5.2 Registros de servicio. 1.5.3 El protocolo. 1.6 RFCOMM 1.7 PERFILES BLUETOOTH 1.7.1 Perfil Genrico de Acceso (GAP). 1.7.2 Perfil de Puerto Serial. 1.7.3 Perfil de Aplicacin de Descubrimiento de Servicio (SDAP). 1.7.4 Perfil Genrico de Intercambio de Objetos (GOEP). 1.7.5 Perfil de Telefona Inalmbrica 1.7.6 Perfil de Intercomunicador. 1.7.7 Perfil de Manos Libres. 1.7.8 Perfil Dial-up Networking. 1.7.9 Perfil de Fax. 1.7.10 Perfil de Acceso LAN. 1.7.11 Perfil Object Push. 1.7.12 Perfil de Transferencia de Archivos.

44 45 45 45 46 47 47 47 47 49 50 51 51 52 52 52 52 53 53 53 53 54 54

1.7.13 Perfil de Sincronizacin. 2. DESCRIPCIN DE HARDWARE Y PRODUCTOS BLUETOOTH 2.1 TARJETAS BLUEBOARDUV 2.1.1 Descripcin de las tarjetas BlueboardUV. 2.1.2 Descripcin de componentes y requerimientos en las tarjetas BlueboardUV. 2.1.2.1 Mdulo Bluetooth Ericsson ROK101007/8. 2.1.2.2 Diseo de Antena. 2.1.2.3 Antenas RangeStar. 2.1.2.4 Regulador de Voltaje National LP2987. 2.1.2.5 MAXIM MAX3232. 2.1.2.6 Soporte SUYIN BT001A-30G2T. 2.1.3 Fotografas de las tarjetas BlueboardUV. 2.2 PRODUCTOS BLUETOOTH 2.3 PROCEDIMIENTO DE CALIFICACIN BLUETOOTH 2.4 ANTENAS EN F INVERTIDA INTEGRADAS

54 55 55 57 63 63 67 72 76 77 77 78 81 82 83

3. SOFTWARE PARA EL HOST BLUETOOTH 3.1 ARQUITECTURAS DE INTEGRACIN DEL STACK DE PROTOCOLOS BLUETOOTH 3.2 PRINCIPALES SOFTWARE PARA EL HOST 3.2.1 Software Bluetooth con propiedad de licencia. 3.2.2 Software Bluetooth con licencia pblica (GPL) 3.3 CONCEPTOS DEL CORE DE LINUX

85

88 90 91 93 95

3.4 DESCRIPCIN DEL STACK DE PROTOCOLOS DE AFFIX 3.4.1 Arquitecturas Soportadas 3.4.2 Hardware Soportado 3.4.3 Arquitectura de Affix 3.4.4 Utilidades de Affix 3.4.5 Instrucciones de Instalacin 3.5 DESCRIPCIN DEL STACK DE PROTOCOLOS BLUEZ 3.5.1 Compilacin e Instalacin

98 98 99 99 102 102 103 105

4. CONCEPTOS BSICOS PARA LA IMPLEMENTACIN DE UNA RED DE AREA PERSONAL BLUETOOTH 4.1 PROTOCOLO DE ENCAPSULAMIENTO DE RED BNEP 4.1.1 Consideraciones 4.1.2 Orden de los Bytes y Valores numricos 4.1.3 Encapsulamiento de Paquetes 4.1.4 Formato de los Encabezados BNEP 4.1.5 Tipo de Paquete BNEP_GENERAL_ETHERNET 4.1.6 Tipo de Paquete BNEP_CONTROL 4.1.7 Tipo de Paquete BNEP_COMPRESSED_ETHERNET 4.1.8 Tipo de Paquete BNEP_COMPRESSED_ETHERNET_SOURCE_ONLY 4.1.9 Tipo de Paquete BNEP_COMPRESSED_ETHERNET_DEST_ONLY 4.2 Piconet y scatternet 4.3 PERFIL DE RED DE AREA PERSONAL (PAN PROFILE) 108 108 109 110 111 111 113 114 114 115 116 117 120

4.3.1 Consideraciones 4.3.2 Puntos de Acceso a una red (NAP) 4.3.3 Grupo de Red Ad-hoc 4.3.4 PANU PANU

121 121 123 125

5. PRUEBAS DE DESEMPEO Y APLICACIN PARA LAS TARJETAS BLUEBOARD_UV01 Y BLUEBOARD_UV02 5.1 PRUEBAS DE DESEMPEO 5.1.1 Configuracin para las Pruebas 5.1.2 Descripcin de las Pruebas 126 127 127 127

5.1.3 Dependencias entre la velocidad de transmisin, los obstculos y la distancia entre los nodos 130

5.1.4 Estabilidad de la velocidad de transmisin respecto a la distancia y los obstculos entre los nodos 5.2 IMPLEMENTACIN DE UNA RED DE AREA PERSONAL BLUETOOTH 5.2.1 Configuracin de la PAN 5.2.2 Ethernet Bridging 5.2.3 Nodo maestro GN 5.2.4 Nodos esclavos PANU1 y PANU2 5.3 Software bluetooth para sistemas embebidos 136 140 141 142 143 144 145

6. CONCLUSIONES

147

REFERENCIAS

LISTA DE FIGURAS

pg.

Figura 1-1. Stack de Protocolo Bluetooth Figura 1-2. Modelo de referencia OSI y Bluetooth Figura 1-3. Diagrama de una piconet. Figura 1-4. Transmisin en una piconet. Figura 1-5. Formato de paquete general Figura 1-6. Formato de cabecera de paquete Figura 1-7. Iniciacin de comunicacin sobre el nivel banda base Figura 1-8. Direccin de dispositivo Bluetooth Figura 1-9. Establecimiento de la conexin Figura 1-10. Diagrama general de las capas ms bajas Figura 1-11. Diagrama general end to end de las capas de software ms bajas Figura 1-12. Arquitectura L2CAP Figura 1-13. Segmentacin L2CAP Figura 1-14. Paquete L2CAP Figura 1-15. Varios puertos seriales emulados mediante RFCOMM Figura 1.16. Los Perfiles Bluetooth Figura 2-1. Diagrama de Bloques de las tarjetas BlueboardUV Figura 2-2. Diagrama esquemtico de las tarjetas BlueboardUV Figura 2-3. Diagrama del hardware de la tarjeta BlueboardUV01

24 28 29 30 31 33 37 37 40 41 42 44 45 46 49 51 56 59 61

Figura 2-4. Diagrama del hardware de la tarjeta BlueboardUV02 Figura 2-5. HW/FW del mdulo Ericsson ROK101007 Figura 2-6. Configuracin Tpica USB para el ROK101007 Figura 2-7. Configuracin Tpica UART o PCM para el ROK101007 Figura 2-8. Ganancia Pico vs. Longitud PCB Figura 2-9. Ruteo de la parte superior de la tarjeta BlueboardUV01 Figura 2-10. Ruteo de la parte inferior de la tarjeta BlueboardUV01 Figura 2-11. Ruteo de la parte superior de la tarjeta BlueboardUV02 Figura 2-12. Ruteo de la parte inferior de la tarjeta BlueboardUV03 Figura 2-13. Antena RangeStar 100929 Figura 2-14. Antena RangeStar 100930 Figura 2-15. Requerimientos para las antenas RangeStar 100929 y100930 Figura 2-16. Diagrama de bloques del regulador de voltaje LP2987 Figura 2-17. Bluetooth Carrier Socket SUYIN BT001A-30G2T Figura 2-18. Tarjeta BlueboardUV01 Figura 2-19. Mdulo Bluetooth dentro del soporte en la tarjeta BlueboardUV01 Figura 2-20. Tarjeta BlueboardUV01 en funcionamiento Figura 2-21. Tarjeta BlueboardUV02 Figura 2-22. Antena en F Invertida Integrada (IIFA) Figura 3-1. Modelo de implementacin del protocolo Bluetooth, Host Hardware Figura 3-2. Modelo de Implementacin del protocolo Bluetooth. Software Firmware Hardware Figura 3-3. Tres modelos de Integracin del stack de protocolos Bluetooth

62 65 66 67 69 70 71 71 72 74 74 76 77 78 79 79 80 80 84 86

87 89

Figura 3-4. Arquitectura de Red de Linux Figura 3-5. Modelo de la Arquitectura de Affix Figura 3-6. Diagrama de los Componentes de Affix Figura 3-7. Diagrama de la Arquitectura de Bluez Figura 4-1. Ubicacin del BNEP dentro de la Torre de protocolos de Bluetooth. Figura 4-2. Encapsulamiento de un Paquete Ethernet en un paquete L2CAP Figura 4-3. Formato de los Encabezados BNEP

95 100 101 104 110 111 112

Figura 4-4. Formato del Encabezado para un paquete BNEP_GENERAL_ETHERNET 113 Figura 4-5. Formato del Encabezado para un paquete BNEP_CONTROL Figura 4-6. Formato del encabezado para un paquete BNEP_COMPRESSED_ETHERNET Figura 4-7. Formato del encabezado para un paquete BNEP_COMPRESSED_ETHERNET_SOURCE_ONLY Figura 4-8. Formato del encabezado para un paquete BNEP_COMPRESSED_ETHERNET_DEST_ONLY 116 115 115 114

Figura 4-9. Ejemplo del envo de un paquete IPv4 usando BNEP entre un dispositivo con direccin IEEE y otro con direccin Bluetooth Figura 4-10. Esquema de una Piconet Figura 4-11. Ejemplo de una Piconet Figura 4-12. Esquema de una Scatternet Figura 4-13. Ejemplo de una Scatternet Figura 4-14. Dos Puntos de Acceso a Red Figura 4-15. Stack para el rol NAP 117 118 118 119 120 122 123

Figura 4-16. Esquema para un Grupo de Red Ad-hoc (GN) Figura 4-17. Stack para un enlace en una red Ad-hoc Bluetooth Figura 5-1. Arquitectura utilizada en las pruebas de desempeo Figura 5-2. Rata de Bits Promedio Vs. Distancia Figura 5-3. Porcentaje de variacin de la rata de Bits Vs. Distancia Figura 5-4. Arquitectura de la red de rea personal

124 125 128 133 138 141

LISTA DE TABLAS

pg.

Tabla 2-1. Lista de componentes para la tarjeta BlueboardUV.........................................60 Tabla 2-2. Caractersticas de las antenas RangeStar 100929 y 100930 ..........................75 Tabla 2-3. Algunos productos Bluetooth disponibles en el mercado.................................81 Tabla 3-1. Software Bluetooth para el Host con propiedad de licencia.............................92 Tabla 4-1. Valores para el campo BNEP Type el cual define el tipo de paquete BNEP 112 Tabla 5-1. Rata de Bits promedio con LV........................................................................131 Tabla 5-2. Rata de Bits promedio con M .........................................................................131 Tabla 5-3. Rata de Bits promedio con MP.......................................................................131 Tabla 5-4. Rata de Bits promedio con LVP .....................................................................132 Tabla 5-5. Porcentaje de Variacin del Promedio de la rata de Bits con LV...................136 Tabla 5-6. Porcentaje de Variacin del Promedio de la rata de Bits con M ....................136 Tabla 5-7. Porcentaje de Variacin del Promedio de la rata de Bits con MP..................137 Tabla 5-8. Porcentaje de Variacin del Promedio de la rata de Bits con LVP ................137 Tabla 5-9. Porcentaje de Variacin Promedio para cada Do ..........................................140

GLOSARIO

ACL: asynchronous Connectionless (asncrono no orientado a la conexin).

ANSI: American National Standards Institute.

API: application program interface (Interfaz del programa de aplicacin).

ARQUITECUTURA: intel, ARM (iPaq, ARM9 y otras) y PowerPC (iMac) entre otras.

ATM: (modo de transferencia asncrona) dentro del medio informtico hace referencia a la conmutacin de paquetes (cells -- celdas o clulas) de un tamao fijo con alta carga, rpida velocidad (entre 1,544 Mbps. y 1,2 Gbps) y una asignacin dinmica de ancho de banda. Tambin se conoce como "paquete veloz" (fast packet).

BD_ADDR: direccin del dispositivo Bluetooth.

BNEP: Bluetooth network encapsulation protocol.

BQP Bluetooth Qualification Program.

CAD: computer aided design (diseo asistido por computador).

CID: identificador de canal.

CRC: chequeo de redundancia cclica.

DBI: sigla para decibeles relativos a una fuente isotrpica.

DCE: data communications equipment. Dispositivo que provee una trayectoria de comunicacin entre dos equipos. Por ejemplo el mdem en un computador.

DRIVER: controlador que permite gestionar los perifricos que estn conectados al ordenador (http://www.guiahost.com/servicios/glosario).

ESPACIO DE KERNEL: espacio de memoria ocupado por el cdigo compilado del kernel de linux.

ESPACIO DE USUARIO: espacio de memoria ocupado por el cdigo compilado de los programas de aplicacin del usuario.

ETHERNET: red de rea local (LAN) desarrollada por Xerox, Digital e Intel. Es el mtodo de acceso LAN que ms se utiliza (seguido por Token Ring). Ethernet es una LAN de medios compartidos. Todos los mensajes se diseminan a todos los nodos en el segmento de red (http://www.guiahost.com/servicios/glosario).

ETSI: European Telecommunications Standards Institute. Organizacin sin nimo de lucro cuya misin es crear estndares de telecomunicaciones para ser usados por dcadas en Europa (http://www.etsi.org).

FCC: Comisin Federal de Comunicaciones. Su principal funcin es la de mantener el control sobre el amplio sector de las telecomunicaciones en los Estados Unidos (http://www.guiahost.com/servicios/glosario).

FIFO: first In first out. El primero en entrar es el primero en salir.

FIRMWARE: parte del software de un ordenador que no puede modificarse por encontrarse en la ROM o memoria de slo lectura, Read Only Memory. Es una mezcla o hbrido entre el hardware y el software, es decir tiene parte fsica y una parte de programacin consistente en programas internos implementados en memorias no voltiles. Un ejemplo tpico de Firmware lo constituye la BIOS. (http://www.guiahost.com/servicios/glosario).

GAP: generic access profile (perfil genrico de acceso).

GNU: es un acrnimo recursivo para ``no es Unix'' Se crea en 1984 sin mucho xito, bajo la filosofa del software libre, muy al estilo de UNIX.

GOEP: generic object exchange profile (perfil genrico de intercambio de objetos).

GPL: licencia pblica general (general public license), desarrollada por la FSF o Free Software Foundation. Puede ser instalado sin limitacin en uno o varios ordenadores. En las distribuciones de estos programas debe estar incluido el cdigo fuente.

HARDWARE: componentes electrnicos y electro-mecnicos de una computadora o cualquier otro sistema. Este trmino es usado para distinguir estos componentes fsicos de los datos y programas.

HCI: host controller interface (interfaz controladora del host).

HEC: chequeo de redundancia cclica de encabezados.

HOST: sistema microprocesado programable (PCs, telfonos celulares, mouse, impresoras, teclados, sensores inalmbricos, etc.), capaz de ejecutar las lneas de cdigo correspondientes al stack de protocolos Bluetooth para el host.

HW / FW: hardware / firmware. I2C: interfaz de datos de dos lneas (SDA y SCL) que utiliza palabras de 8 bits y es usada para comunicar memorias, controladores de video, preamplificadores de audio y otros dipositivos.

IAC: codigo de acceso de bsqueda.

IFA: inverted F antenna (antena en F invertida).

ISM: industrial, scientific, medical.

KERNEL: ncleo, es la parte fundamental de un programa, por lo general de un sistema operativo, que reside en memoria todo el tiempo y que provee los servicios bsicos. Es la parte del sistema operativo que est ms cerca de la mquina y puede activar el hardware directamente o unirse a otra capa de software que maneja el hardware (http://www.guiahost.com/servicios/glosario).

L2CAP: logical link controller and adaptation protocol (protocolo de adaptacin y control de enlace lgico).

LMP: link manager protocol (Protocolo del administrador de enlace).

ME: management entity (entidad de administracin o manejo).

MODULO BLUETOOTH: mdulo multichip que implementa en hardware y firmware las capas bajas del stack de protocolos Bluetooth.

MTU: maximun transmission unit.

PAD: punto de conexin del terminal de un dispositivo.

PAGING: servicio para transferencia de sealizacin o informacin en un sentido, mediante paquetes, tonos, etc

PAN: personal area networking.

PATH: es la trayectoria de una pista en un circuito impreso.

PCB: printed Circuit Board (Tarjeta de circuito impreso).

PPP: point to point protocol (Protocolo punto-a-punto).

QoS: calidad de servicio.

RF: radio frecuencia.

RFCOMM: serial port emulation basado en el estndar ETSI TS07.10.

SAR: segmentacin y reensamblado.

SCO: synchronous connection oriented (Sncrono orientado a la conexin).

SDAP: service discovery aplication protocol (perfil de aplicacin de descubrimiento de servicio).

SDP: service discovery protocol (protocolo de descubrimiento de servicio).

SIG: special interest group.

SOCKET: es una abstraccin de red para los terminales de un canal. El Socket est asociado con el protocolo; usualmente, el PF_INET es usado para asociar un socket con el protocolo TCP/IP.

TIMEOUT: tiempo de espera excedido.

TIMESLOT: ranura de tiempo. En Bluetooth tiene una duracin de 625 us.

TOKEN RING: el anillo de Fichas (token ring), es una red de topologa de anillo que se sirve del pase de fichas para el control de acceso. La frase tambin se aplica a una topologa de pase de fichas especfica definida por la IBM Corporation (http://www.guiahost.com/servicios/glosario).

TRANSCEIVER: transmisor-receptor.

UART: el transmisor receptor universal asncrono (universal asynchronous receiver transmitter), es un dispositivo que multiplexa datos paralelos en seriales para ser transmitidos y convierte en paralelos los datos seriales recibidos.

USB: la caracterstica principal del bus serie universal (universal serial bus) reside en que los perifricos pueden conectarse y desconectarse con el equipo en marcha, configurndose de forma automtica. Conector externo que llega a transferencias de 12 millones de bits por segundo. Totalmente PnP, sustituir al puerto serie y paralelo, gracias a la posibilidad de conectar 127 dispositivos. (http://www.guiahost.com/servicios/glosario).

WAP: wireless application protocol (protocolo para aplicaciones inalmbricas).

RESUMEN

El aporte principal de este trabajo es el desarrollo de un sistema Bluetooth semiembebido. En principio, se analiz detalladamente la especificacin Bluetooth y se hizo un estudio de los productos disponibles en el mercado. Con el conocimiento adquirido se disearon y construyeron dos tipos de tarjeta Bluetooth, BlueBoard_UV01 y BlueBoard_UV02. En este documento se describe en detalle su funcionamiento, al igual que se presentan sus diagramas, caractersticas y materiales empleados, entre otros. Adems se analizaron diferentes stacks de protocolos Bluetooth (Affix y Bluez), con los cuales y utilizando las tarjetas construidas, se implement una red inalmbrica de carcter didctico. Con los sistemas desarrollados, se hicieron pruebas de desempeo logrando verificar y analizar principios bsicos de operacin de esta tecnologa.

PALABRAS CLAVE:

Bluetooth Redes Inalmbricas Comunicaciones Mviles

INTRODUCCIN

Estamos en un mundo en el cual la movilidad es una necesidad en constante aumento y en el que el acceso a la informacin no puede tener lmites. En aras de satisfacer estas necesidades, han surgido nuevas tecnologas, cada una enfocada en un campo de accin especfico. Telfonos mviles (acceso a WAN), WLAN IEEE 802.11 (acceso a LAN) y Bluetooth (acceso a PAN), son ejemplos de tecnologas inalmbricas, cada una con un campo de accin diferente, pero que en conjunto conforman una completa solucin a los problemas de movilidad.

Colombia est en una poca de transicin tecnolgica, modernizando su infraestructura de comunicaciones y masificando poco a poco el acceso a la misma. Casos como el de la telefona mvil de segunda y tercera generacin (PCS y otras que usan GSM), implican ms y mejores servicios (transmisin de audio y video con buena definicin), que promueven e incentivan el uso de tecnologas como Bluetooth.

Este trabajo de grado, cimienta las bases para conocer y aprender la tecnologa inalmbrica Bluetooth en la Universidad del Valle, disear hardware Bluetooth y realizar aplicaciones prcticas dirigidas a desarrollar nuevos sistemas que con la ayuda de otros campos de la electrnica como por ejemplo la instrumentacin y la automtica, resuelvan otro tipo de problemas a travs de redes de censado y actuadores inalmbricos.

1. DESCRIPCIN GENERAL DE LA TECNOLOGA INALMBRICA BLUETOOTH

La tecnologa inalmbrica Bluetooth ofrece una forma de remplazar cables y enlaces infrarrojos que interconectan dispositivos por un enlace de radio universal de corto alcance, con capacidad de crear pequeas radio LANs. El nombre Bluetooth viene de un rey dans llamado Harald Blaatand (en ingls Bluetooth) quien vivi entre los aos 940 y 981 y quien control a Noruega y Dinamarca.

En Febrero de 1998, se fund el Bluetooth Special Interest Group (SIG), creado con el fin de ofrecer soporte para la nueva tecnologa. Actualmente, ms de mil compaas lo integran y trabajan conjuntamente por un estndar abierto para el concepto Bluetooth [1].

Bluetooth es un sistema de radio que opera en la banda de frecuencia libre de 2.4 GHz, esta banda de frecuencia est disponible en la mayor parte del mundo. En Colombia el Ministerio de Comunicaciones reglamenta su uso as: Las bandas, 902 - 924 MHz, 2 400 - 2 483,5 MHz y 5 725 - 5 850 MHz se atribuyen a ttulo secundario, conforme con la resolucin 3382 de 15 de diciembre de 1995, para los sistemas de espectro ensanchado [2]. Bluetooth utiliza 79 canales de radio frecuencia con un ancho de banda de 1 MHz cada uno y una rata mxima de smbolos de 1 MSmbolo/s. Despus de que cada paquete es enviado en una determinada frecuencia de transmisin, sta cambia a otra de las 79 frecuencias [3]. El rango tpico de operacin de Bluetooth es menor a 10 m, sin embargo se pueden alcanzar distancias de hasta 100 m con el uso de amplificadores.

Como se puede observar en la Figura 1-1, la comunicacin sobre Bluetooth se divide en varias capas. A continuacin se presenta una breve descripcin de algunas de ellas y se tratarn en mayor detalle en sub-captulos posteriores.

Figura 1-1. Stack de Protocolo Bluetooth

La capa de comunicacin ms baja es llamada banda base. Esta capa implementa el canal fsico real. Emplea una secuencia aleatoria de saltos a travs de 79 frecuencias de radio diferentes. Los paquetes son enviados sobre el canal fsico, donde cada uno es enviado en una frecuencia de salto diferente. La Banda

Base controla la sincronizacin de las unidades Bluetooth y la secuencia de saltos en frecuencia, adems es la responsable de la informacin para el control de enlace a bajo nivel como el reconocimiento, control de flujo y caracterizacin de carga til y soporta dos tipos de enlace: sncrono orientado a la conexin (SCO), para datos y asncrono no orientado a la conexin (ACL), principalmente para audio. Los dos pueden ser multiplexados para usar el mismo enlace RF. Usando ancho de banda reservado, los enlaces SCO soportan trfico de voz en tiempo real.

El Link Manager Protocol (LMP) o Protocolo de Gestin de Enlace es el responsable de la autenticacin, encriptacin, control y configuracin del enlace. El LMP tambin se encarga del manejo de los modos y consumo de potencia, adems soporta los procedimientos necesarios para establecer un enlace SCO.

El Host Controller Interface (HCI) o Interfaz del Controlador de Enlace brinda un mtodo de interfaz uniforme para acceder a los recursos de hardware de Bluetooth. ste contiene una interfaz de comando para el controlador banda base y la gestin de enlace y para acceder al hardware.

El Logical Link Control and Adaptation Protocol (L2CAP) o Protocolo de Control y Adaptacin de Enlace Lgico, corresponde a la capa de enlace de datos. sta brinda servicios de datos orientados y no orientados a la conexin a capas superiores. L2CAP multiplexa los protocolos de capas superiores con el fin de enviar varios protocolos sobre un canal banda base. Con el fin de manipular paquetes de capas superiores ms grandes que el mximo tamao del paquete banda base, L2CAP los segmenta en varios paquetes banda base. La capa L2CAP del receptor reensambla los paquetes banda base en paquetes ms

grandes para la capa superior. La conexin L2CAP permite el intercambio de informacin referente a la calidad de la conexin, adems maneja grupos, de tal manera que varios dispositivos pueden comunicarse entre s. El Sevice Discovery Protocol (SDP) o Protocolo de Descubrimiento de Servicio define cmo acta una aplicacin de un cliente Bluetooth para descubrir servicios disponibles de servidores Bluetooth, adems de proporcionar un mtodo para determinar las caractersticas de dichos servicios.

El protocolo RFCOMM ofrece emulacin de puertos seriales sobre el protocolo L2CAP. RFCOMM emula seales de control y datos RS-232 sobre la banda base Bluetooth. ste ofrece capacidades de transporte a servicios de capas superiores (por ejemplo OBEX) que usan una lnea serial como mecanismo de transporte. RFCOMM soporta dos tipos de comunicacin, directa entre dispositivos actuando como endpoints y dispositivo-modem-dispositivo, adems tiene un esquema para emulacin de null modem.

El control de telefona binario (TCS binario) es un protocolo que define la sealizacin de control de llamadas, para el establecimiento y liberacin de una conversacin o una llamada de datos entre unidades Bluetooth. Adems, ste ofrece funcionalidad para intercambiar informacin de sealizacin no relacionada con el progreso de llamadas.

La capa de Audio es una capa especial, usada slo para enviar audio sobre Bluetooth. Las transmisiones de audio pueden ser ejecutadas entre una o ms unidades usando muchos modelos diferentes. Los datos de audio no pasan a travs de la capa L2CAP, pero s directamente despus de abrir un enlace y un establecimiento directo entre dos unidades Bluetooth.

 Protocolos Especficos

Control de telefona Comandos AT. Bluetooth soporta un nmero de comandos AT para el control de telefona a travs de emulacin de puerto serial (RFCOMM).

Protocolo Punto-a-Punto (PPP).

El PPP es un protocolo orientado a

paquetes y por lo tanto debe usar su mecanismo serial para convertir un torrente de paquetes de datos en una corriente de datos seriales. Este protocolo corre sobre RFCOMM para lograr las conexiones punto-a-punto.

Protocolos UDP/TCP IP. Los estndares UDP/TCP e IP permiten a las unidades Bluetooth conectarse, por ejemplo a Internet, a travs de otras unidades conectadas. Por lo tanto, la unidad puede actuar como un puente para Internet. La configuracin TCP/IP/PPP est disponible como un transporte para WAP.

Wireless

Aplication

Protocol

(WAP)

Protocolo

de

Aplicacin

Inalmbrica.

WAP es una especificacin de protocolo inalmbrica que

trabaja con una amplia variedad de tecnologas de red inalmbricas conectando dispositivos mviles a Internet. Bluetooth puede ser usado como portador para ofrecer el transporte de datos entre el cliente WAP y su servidor de WAP adyacente. Adems, las capacidades de red de Bluetooth dan a un cliente WAP posibilidades nicas en cuanto a movilidad comparado con otros portadores WAP. Un ejemplo de WAP sobre Bluetooth sera un almacn que transmite ofertas especiales a un cliente WAP cuando ste entra en el rango de cobertura.

Protocolo OBEX. OBEX es un protocolo opcional de nivel de aplicacin diseado para permitir a las unidades Bluetooth soportar comunicacin

infrarroja para intercambiar una gran variedad de datos y comandos. ste usa un modelo cliente-servidor y es independiente del mecanismo de transporte y del API (Application Program Interface) de transporte. OBEX usa RFCOMM como principal capa de transporte.

La Figura 1-2 muestra una comparacin del stack Bluetooth con el modelo de referencia estndar Open Systems Interconect, OSI, para stacks de protocolo de comunicaciones. A pesar de que Bluetooth no concuerda exactamente con el modelo, esta comparacin es muy til para relacionar las diferentes partes del stack Bluetooth con las capas del modelo OSI. Dado que el modelo de referencia es un stack ideal y bien particionado, la comparacin sirve para resaltar la divisin de funciones en el stack Bluetooth.

Figura 1-2. Modelo de referencia OSI y Bluetooth

1.1 BANDA BASE

1.1.1 Descripcin general. Bluetooth soporta un canal de datos asncrono de hasta tres canales de voz simultneos. El canal asncrono soporta comunicacin simtrica y asimtrica. En la comunicacin asimtrica pueden ser enviados 723.3 kb/s desde el servidor y 57.6 kb/s hacia el servidor, mientras que en la comunicacin simtrica pueden ser enviados 433 kb/s en ambas direcciones.

Bluetooth brinda conexin punto-a-punto o conexin punto-a-multipunto. Dos o ms unidades compartiendo el mismo canal forman una piconet. Cada piconet debe tener un maestro y puede tener hasta siete esclavos activos, adems pueden haber muchos ms esclavos en estado parked. Estos esclavos no estn activos en el canal sin embargo estn sincronizados con el maestro con el fin de asegurar una rpida iniciacin de comunicacin. La interconexin de varias piconets forma una scatternet. Informacin ms detallada se encuentra en la especificacin Bluetooth [3]. En la Figura 1-3 se puede observar una piconet donde el PC acta como maestro y los otros dispositivos son conectados como esclavos.

Figura 1-3. Diagrama de una piconet.

1.1.2 Canal fsico. El canal fsico contiene 79 frecuencias de radio diferentes, las cuales son accedidas de acuerdo a una secuencia de saltos aleatoria. La rata de saltos estndar es de 1600 saltos/s. El canal est dividido en timeslots (ranuras de tiempo), cada slot (ranura) corresponde a una frecuencia de salto y tiene una longitud de 625 us. Cada secuencia de salto en una piconet est determinada por la direccin del maestro de la piconet. Todos los dispositivos conectados a la piconet estn sincronizados con el canal en salto y tiempo. En una transmisin, cada paquete debe estar alineado con el inicio de un slot y puede tener una duracin de hasta cinco timeslots. Durante la transmisin de un paquete la frecuencia es fija. Para evitar fallas en la transmisin, el maestro inicia enviando en los timeslots pares y los esclavos en los timeslots impares [3]. En la Figura 14 se puede observar este esquema de transmisin.

Figura 1-4. Transmisin en una piconet.

1.1.3 Enlace fsico. La comunicacin sobre Bluetooth es perfecta para enlaces SCO o enlaces ACL. El enlace SCO es una conexin simtrica punto-a-punto entre el maestro y un esclavo especfico. Para lograr la comunicacin, el enlace SCO reserva slots en intervalos regulares en la iniciacin, por esto el enlace

puede ser considerado como una conexin de conmutacin de circuitos. El enlace ACL es un enlace punto-a-multipunto entre el maestro y uno o ms esclavos activos en la piconet. Este enlace de comunicacin es un tipo de conexin de conmutacin de paquetes. Todos los paquetes son retransmitidos para asegurar la integridad de los datos. El maestro puede enviar mensajes broadcast (de difusin) a todos los esclavos conectados dejando vaca la direccin del paquete, as todos los esclavos leern el paquete [3].

1.1.4 Paquetes. Los datos enviados sobre el canal de la piconet son convertidos en paquetes, stos son enviados y el receptor los recibe iniciando por el bit menos significativo. Como se observa en la Figura 1-5, el formato de paquete general consta de tres campos: cdigo de acceso, cabecera y carga til [3].

Figura 1-5. Formato de paquete general

Cdigo de acceso. Es usado para sincronizacin e identificacin. Todos los paquetes comunes que son enviados sobre el canal de la piconet estn precedidos del mismo cdigo de acceso al canal. Existen tres tipos diferentes de cdigo de acceso:

Cdigo de acceso al canal - Para identificar los paquetes sobre el canal de la piconet.

Cdigo de acceso de dispositivo Para procedimientos de sealizacin especiales, paging (servicio para transferencia de sealizacin o informacin en un sentido), entre otros.

Cdigo de Acceso de Bsqueda (IAC) llamado IAC general cuando se quiere descubrir a otras unidades Bluetooth dentro del rango, o IAC dedicado cuando se desea descubrir unidades de un tipo especfico.

Cabecera de paquete. Como se observa en la Figura 1-6, la cabecera de paquete consta de seis campos:

Direccin Una direccin de dispositivo para distinguirlo de los dems dispositivos activos en la piconet.

Tipo Define qu tipo de paquete es enviado.

Flujo El bit de control de flujo es usado para notificar al emisor cundo el buffer del receptor est lleno.

ARQN Acknowledge Receive Data o reconocimiento de datos recibidos.

SEQN Sequential Numbering o numeracin secuencial para ordenar los datos sobre el canal.

HEC Chequeo de redundancia cclica de cabecera.

Figura 1-6. Formato de cabecera de paquete

Carga til. La carga til de un paquete puede ser dividida en dos campos:

Campo de Voz Consta de datos de voz de longitud fija y existe en paquetes de alta calidad de voz y paquetes combinados de datos-voz. No es necesaria ninguna cabecera de carga til.

Campo de Datos Consta de tres partes, cabecera de carga til, datos de carga til, y cdigo CRC.

1.1.5 Correccin de errores. En una comunicacin Bluetooth existen varios esquemas diferentes de correccin de errores [3]:

En la cabecera, cada bit es repetido tres veces.

En la carga til se usa un esquema de cdigo Hamming. Los bits de informacin son agrupados en secuencias de 10 bits, stos son enviados como 15 bits y el algoritmo corrige todos los errores de un bit y detecta los errores de dos bits.

Para garantizar una recepcin correcta, todos los paquetes de datos son retransmitidos hasta que el emisor reciba una confirmacin. La confirmacin es enviada en la cabecera de los paquetes retornados.

Los paquetes broadcast son paquetes transmitidos desde el maestro a todos los esclavos. No hay posibilidad de usar confirmacin para esta comunicacin, sin embargo, para incrementar la posibilidad de recibir correctamente un paquete, cada bit en el paquete es repetido un nmero fijo de veces.

El chequeo de redundancia cclica (CRC) se usa para detectar errores en la cabecera. La suma de comprobacin CRC est contenida en el campo HEC de la cabecera de paquete. Los chequeos de redundancia cclica tambin se aplican sobre la carga til en la mayora de los paquetes.

Para asegurar que no desaparezcan paquetes completos, Bluetooth usa nmeros de secuencia. Actualmente slo se usa un nmero de secuencia de un bit.

1.1.6

Transmisin/Recepcin.

Como se mencion antes, el maestro de la

piconet empieza enviando en timeslots pares y el esclavo en los impares. Solamente el ltimo esclavo direccionado est autorizado para enviar en el timeslot de los esclavos. Esto no causa problemas ya que el maestro siempre est inicializando todas las conexiones y transmisiones nuevas. Cada esclavo espera las oportunidades de conexin dadas por el maestro. Los paquetes pueden ser ms grandes que un timeslot, debido a esto el maestro puede continuar enviando en los timeslots impares y viceversa. El sistema de reloj del maestro sincroniza a toda la piconet. El maestro nunca ajusta su sistema de reloj durante la existencia de una piconet, son los esclavos quienes adaptan sus relojes con un offset de tiempo con el fin de igualarse con el reloj del maestro. Este offset es actualizado cada vez que es recibido un paquete desde el maestro.

1.1.7 Control de Canal. El control de canal describe cmo se establece el canal de una piconet y cmo las unidades pueden ser adicionadas o liberadas en la piconet. La direccin del maestro determina la secuencia de saltos y el cdigo de acceso al canal. La fase de la piconet est determinada por el sistema de reloj del maestro. Por definicin, la unidad Bluetooth que inicia la conexin representa al maestro.

En Bluetooth, la capa de control de enlace se divide en dos estados principales: standby y conexin. Adems existen siete sub-estados: page, page scan,

inquiry (bsqueda), inquiry scan, respuesta de maestro, respuesta de esclavo y respuesta a inquiry. Los sub-estados son usados para agregar nuevos esclavos a una piconet [3]. Para moverse de un estado a otro se usan comandos de capas ms altas o seales internas.

En Bluetooth se define un procedimiento de bsqueda que se usa en aplicaciones donde la direccin del dispositivo de destino es desconocida para la fuente. Esto puede ser usado para descubrir qu otras unidades Bluetooth estn dentro del rango. Durante un sub-estado de inquiry o bsqueda, la unidad de descubrimiento recoge la direccin del dispositivo y el reloj de todas las unidades que respondan al mensaje de bsqueda, entonces la unidad puede iniciar una conexin con alguna de las unidades descubiertas. El mensaje de bsqueda difundido por la fuente no contiene informacin de ella, sin embargo, puede indicar qu clase de dispositivos deberan responder. Una unidad que permita ser descubierta, regularmente entra en un sub-estado de inquiry scan para responder a los mensajes de bsqueda.

Existen dos formas de detectar otras unidades. La primera, detecta todas las otras unidades en el rango de cobertura, y la segunda, detecta un tipo especfico de unidades. Los esclavos que se encuentran en el sub-estado de page scan, escuchan esperando su propio cdigo de acceso de dispositivo. El maestro en el sub-estado page activa y conectan a un esclavo. El maestro trata de capturar al esclavo transmitiendo repetidamente el cdigo de acceso de dispositivo en diferentes canales de salto. Debido a que los relojes del maestro y del esclavo no estn sincronizados, el maestro no sabe exactamente cundo y en qu frecuencia de salto se activar el esclavo.

Despus de haber recibido su propio cdigo de acceso de dispositivo, el esclavo transmite un mensaje de respuesta. Este mensaje de respuesta es simplemente el cdigo de acceso de dispositivo del esclavo. Cuando el maestro ha recibido este paquete, enva un paquete de control con informacin acerca de su reloj, direccin, clase de dispositivo, etc... El esclavo responde con un nuevo mensaje donde enva su direccin. Si el maestro no obtiene esta respuesta en un determinado tiempo, l reenva el paquete de control. Si el esclavo excede el tiempo de espera, entonces retorna al sub-estado de page scan. Si es el maestro quien lo excede, entonces retorna al sub-estado de page e informa a las capas superiores.

Cuando se establece la conexin, la comunicacin inicia con un paquete de sondeo desde el maestro hacia el esclavo. Como respuesta se enva un nuevo paquete de sondeo y de esta forma se verifica que la secuencia de salto y la sincronizacin sean correctas. La Figura 1-7 muestra la inicializacin de la comunicacin sobre el nivel banda base.

Cada transceiver (receptor-transmisor) Bluetooth tiene una nica direccin de dispositivo de 48 bits asignada, la cual est dividida en tres campos: campo LAP, campo UAP y campo NAP [3]. Los campos LAP y UAP forman la parte significativa del cdigo de acceso. En la Figura 1-8 se puede observar el formato de la direccin para un dispositivo Bluetooth. La direccin del dispositivo es conocida pblicamente y puede ser obtenida a travs de una rutina inquiry.

Figura 1-7. Iniciacin de comunicacin sobre el nivel banda base

Figura 1-8. Direccin de dispositivo Bluetooth

1.1.8 Seguridad en Bluetooth. Con el fin de brindar proteccin y confidencialidad a la informacin, el sistema debe ofrecer medidas de seguridad en las dos capas, la de aplicacin y de enlace. Todas las unidades Bluetooth tienen implementadas las mismas rutinas de autenticacin y encriptacin. En la capa de enlace, estas rutinas constan de cuatro entidades diferentes: una nica direccin pblica, dos llaves secretas y un nmero aleatorio el cual es diferente para cada transaccin. Solamente es encriptada la carga til. El cdigo de acceso y la cabecera de paquete nunca son encriptados.

Cada tipo de unidad Bluetooth tiene una rutina de autenticacin comn. El maestro genera un nmero aleatorio y lo enva al esclavo, el esclavo usa este nmero y su propia identidad para calcular el nmero de autenticacin. Luego, este nmero es enviado al maestro quien hace el mismo clculo. Si los dos nmeros generados son iguales entonces la autenticacin es concedida. La encriptacin, frecuentemente est restringida por leyes de varios pases. Para evitar estas limitaciones, en Bluetooth la llave de encriptacin no es esttica, sta es deducida de la llave de autenticacin cada vez que se activa la encriptacin [3].

1.2 PROTOCOLO DE GESTIN DE ENLACE (LMP)

En el protocolo de gestin de enlace, LMP, se usan mensajes asociados con el establecimiento, seguridad y control. Los mensajes son enviados en la carga til y no en los mensajes de datos de L2CAP. Los mensajes LMP son separados de los dems por medio de un valor reservado en uno de los campos de la cabecera de carga til. Todos los mensajes LMP son extrados e interpretados por la capa LMP del receptor, esto significa que ningn mensaje es enviado a capas superiores. Los mensajes LMP tienen mayor prioridad que los datos de usuario, esto significa que si la gestin de enlace necesita enviar un mensaje, ste no debe ser retrasado por otro trfico. Solamente las retransmisiones de los paquetes del nivel de banda

base pueden retrasar los mensajes LMP. Adems, stos no necesitan rutinas de reconocimiento ya que la capa banda base asegura un enlace confiable [3]. El protocolo de gestin enlace soporta mensajes para:

Autenticacin Paridad Encriptacin Temporizacin y sincronizacin Versin y caractersticas Switch para desempeo como maestro o esclavo dependiendo de si el dispositivo es quien inicia (maestro) o no (esclavo) el enlace con otro dispositivo.

Peticin de nombre Desconexin Modo hold: el maestro ordena al esclavo entrar en este estado para ahorro de potencia. Modo sniff: para envo de mensajes en timeslots especficos. Modo park: para que el esclavo permanezca inactivo pero sincronizado en la piconet. Enlaces SCO Control de paquetes multi-slot Supervisin de enlace

1.2.1

Establecimiento de conexin.

Despus del procedimiento paging, el

maestro debe encuestar al esclavo enviando paquetes de sondeo. El otro lado recibe este mensaje y lo acepta o rechaza, si es aceptado, la comunicacin incluyendo las capas superiores estn disponibles (ver Figura 1-9).

Figura 1-9. Establecimiento de la conexin

1.3

INTERFAZ DEL CONTROLADOR DE HOST (HCI)

La HCI proporciona una interfaz de comando al controlador banda base y a la gestin de enlace, adems de acceso al hardware y a los registros de control. Esta interfaz brinda un mtodo estndar para acceder a los recursos de banda base Bluetooth [3].

1.3.1 Capas mas bajas del stack Bluetooth. A continuacin se hace una breve descripcin de las capas ms bajas del stack de software y hardware Bluetooth. La Figura 1-10 da una idea de estas capas.

Figura 1-10. Diagrama general de las capas ms bajas

El firmware HCI implementa los comandos HCI para el hardware a travs del acceso de comandos banda base, comandos de la gestin de enlace, hardware de registros de estado, registros de control y registros de eventos. La Figura 1-11 muestra el recorrido de un dato transferido de un dispositivo a otro. El driver HCI (en el host) intercambia datos y comandos con el firmware HCI (en el hardware). El driver de la capa de transporte, por ejemplo un bus fsico, brinda a las dos capas HCI la posibilidad de intercambiar informacin.

Figura 1-11. Diagrama general end to end de las capas de software ms bajas

1.3.2 Posibles arquitecturas de bus fsico. Los dispositivos Bluetooth tienen varias interfaces de bus fsicas que pueden ser usadas para conectar el hardware. Estos buses pueden tener diferentes arquitecturas y parmetros. El controlador de host soporta tres arquitecturas de bus fsico, USB, UART y PC Card. Todas ellas pueden manejar varios canales lgicos sobre el mismo canal fsico simple (a travs de endpoints), por lo tanto los canales de control, datos y voz no requieren alguna interfaz fsica adicional.

El objetivo principal de la capa de transporte del controlador de host es la transparencia entre el driver del controlador de host y el controlador de host.

1.4

PROTOCOLO DE CONTROL Y ADAPTACIN DE ENLACE

LGICO (L2CAP)
L2CAP se encuentra sobre el protocolo de gestin de enlace (LMP) y reside en la capa de enlace de datos. L2CAP permite a protocolos de niveles superiores y a aplicaciones la transmisin y recepcin de paquetes de datos L2CAP de hasta 64 kilobytes, con capacidad de multiplexacin de protocolo, operacin de

segmentacin y reensamble, y abstraccin de grupos. Para cumplir sus funciones, L2CAP espera que la banda base suministre paquetes de datos en full duplex, que realice el chequeo de integridad de los datos y que reenve los datos hasta que hayan sido reconocidos satisfactoriamente. Las capas superiores que se comunican con L2CAP son por ejemplo el protocolo de descubrimiento de servicio (SDP), el RFCOMM y el control de telefona (TCS) [3].

1.4.1 Canales. L2CAP est basado en el concepto de canales. Se asocia un identificador de canal, CID, a cada uno de los endpoints de un canal L2CAP. Los CIDs estn divididos en dos grupos, uno con identificadores reservados para funciones L2CAP y otro con identificadores libres para implementaciones particulares. Los canales de datos orientados a la conexin representan una conexin entre dos dispositivos, donde un CID identifica cada endpoint del canal. Los canales no orientados a la conexin limitan el flujo de datos a una sola direccin. La sealizacin de canal es un ejemplo de un canal reservado. Este canal es usado para crear y establecer canales de datos orientados a la conexin y para negociar cambios en las caractersticas de esos canales.

1.4.2 Operaciones entre Capas. Las implementaciones L2CAP deben transferir datos entre protocolos de capas superiores e inferiores. Cada implementacin debe soportar un grupo de comandos de sealizacin, adems, debe ser capaz de

aceptar ciertos tipos de eventos de capas inferiores y generar eventos para capas superiores. En la Figura 1-12 se muestra esta arquitectura.

Figura 1-12. Arquitectura L2CAP

1.4.3 Segmentacin y Reensamblado. Los paquetes de datos definidos por el protocolo banda base estn limitados en tamao. Los paquetes L2CAP grandes deben ser segmentados en varios paquetes banda base ms pequeos antes de transmitirse y luego deben ser enviados a la gestin de enlace. En el receptor los pequeos paquetes recibidos de la banda base son reensamblados en paquetes L2CAP ms grandes. Varios paquetes banda base recibidos pueden ser reensamblados en un solo paquete L2CAP seguido de un simple chequeo de integridad. La segmentacin y reensamblado, SAR, funcionalmente es

absolutamente necesaria para soportar protocolos usando paquetes ms grandes que los soportados por la banda base. La Figura 1-13 muestra la segmentacin L2CAP.

Figura 1-13. Segmentacin L2CAP

1.4.4 Eventos. Todos los mensajes y timeouts que entran en la capa L2CAP, son llamados eventos. Los eventos se encuentran divididos en cinco categoras: indicaciones y confirmaciones de capas inferiores, peticiones de seal y respuestas de capas L2CAP, datos de capas L2CAP, peticiones y respuestas de capas superiores, y eventos causados por expiraciones de tiempo.

1.4.5 Acciones. Todos los mensajes y timeouts enviados desde la capa L2CAP son llamados acciones (en el lado del receptor estas acciones son llamadas eventos). Las acciones se encuentran divididas en cinco categoras: peticiones y respuestas a capas inferiores, peticiones y respuestas a capas L2CAP, datos a capas L2CAP, indicaciones a capas superiores, y configuracin de timers.

1.4.6 Formato del paquete de datos. L2CAP est basado en paquetes pero sigue un modelo de comunicacin basado en canales. Un canal representa un flujo de datos entre entidades L2CAP en dispositivos remotos. Los canales pueden ser o no orientados a la conexin. Como se puede observar en la Figura 1-14, los paquetes de canal orientado a la conexin estn divididos en tres campos: longitud de la informacin, identificador de canal, e informacin.

Figura 1-14. Paquete L2CAP

Los paquetes de canal de datos no orientados a la conexin son iguales a los paquetes orientados a la conexin pero adicionalmente incluyen un campo con informacin multiplexada de protocolo y servicio.

1.4.7 Calidad de servicio (QoS). La capa L2CAP transporta la informacin de calidad de servicio a travs de los canales y brinda control de admisin para evitar que canales adicionales violen contratos de calidad de servicio existentes.

Algunos esclavos pueden requerir un alto rendimiento o una respuesta rpida. Antes de que un esclavo con grandes peticiones sea conectado a una piconet, el esclavo trata de obtener una garanta a sus demandas. Puede solicitar una determinada rata de transmisin, tamao del buffer de trfico, ancho de banda, tiempo de recuperacin de datos, etc. Por lo tanto, antes de que el maestro conecte a un nuevo esclavo o actualice la configuracin de calidad, debe chequear si posee timeslots y otros recursos libres.

1.5 PROTOCOLO DE DESCUBRIMIENTO DE SERVICIO (SDP)

El protocolo de descubrimiento de servicio, SDP, brinda a las aplicaciones recursos para descubrir qu servicios estn disponibles y determinar las caractersticas de dichos servicios.

1.5.1

Descripcin General.

Un servicio es una entidad que puede brindar

informacin, ejecutar una accin o controlar un recurso a nombre de otra entidad. El SDP ofrece a los clientes la facilidad de averiguar sobre servicios que sean requeridos, basndose en la clase de servicio o propiedades especficas de estos servicios. Para hacer ms fcil la bsqueda, el SDP la habilita sin un previo conocimiento de las caractersticas especficas de los servicios. Las unidades Bluetooth que usan el SDP pueden ser vistas como un servidor y un cliente. El servidor posee los servicios y el cliente es quien desea acceder a ellos. En el SDP esto es posible ya que el cliente enva una peticin al servidor y el servidor responde con un mensaje. El SDP solamente soporta el descubrimiento del servicio, no la llamada del servicio [3].

1.5.2 Registros de servicio. Los registros de servicio contienen propiedades que describen un servicio determinado. Cada propiedad de un registro de servicio consta de dos partes, un identificador de propiedad y un valor de propiedad. El identificador de propiedad es un nmero nico de 16 bits que distingue cada propiedad de servicio de otro dentro de un registro. El valor de propiedad es un campo de longitud variable que contiene la informacin.

1.5.3 El protocolo. El protocolo de descubrimiento de servicio (SDP) usa un modelo peticin/respuesta. En la Figura 1-15 se muestra el procedimiento SDP. Note que las flechas no continuas no forman parte de ste.

 Peticin de bsqueda de servicio: se genera por el cliente para localizar registros de servicio que concuerden con un patrn de bsqueda dado como parmetro. Aqu el servidor examina los registros en su base de datos y responde con una respuesta a bsqueda de servicio. Respuesta a bsqueda de servicio: se genera por el servidor despus de recibir una peticin de bsqueda de servicio vlida. Peticin de propiedad de servicio: una vez el cliente ya ha recibido los servicios deseados, puede obtener mayor informacin de uno de ellos dando como parmetros el registro de servicio y una lista de propiedades deseadas. Respuesta a propiedad de servicio: El SDP genera una respuesta a una peticin de propiedad de servicio. sta contiene una lista de propiedades del registro requerido. Peticin de bsqueda y propiedad de servicio: se suministran un patrn de servicio con servicios deseados y una lista de propiedades deseadas que concuerden con la bsqueda. Respuesta de bsqueda y propiedad de servicio: como resultado se puede obtener una lista de servicios que concuerden con un patrn dado y las propiedades deseadas de estos servicios.

1.6 RFCOMM
El protocolo RFCOMM brinda emulacin de puertos seriales sobre el protocolo L2CAP. La capa RFCOMM es una simple capa de transporte provista adicionalmente de emulacin de circuitos de puerto serial RS-232. El protocolo RFCOMM soporta hasta 60 puertos emulados simultneamente. Dos unidades Bluetooth que usen RFCOMM en su comunicacin pueden abrir varios puertos seriales emulados, los cuales son multiplexados entre s. La Figura 1-15 muestra el esquema de emulacin para varios puertos seriales.

Figura 1-15. Varios puertos seriales emulados mediante RFCOMM

Muchas aplicaciones hacen uso de puertos seriales. El RFCOMM est orientado a hacer ms flexibles estos dispositivos, soportando fcil adaptacin de

comunicacin Bluetooth. Un ejemplo de una aplicacin de comunicacin serial es el protocolo punto-a-punto (PPP). El RFCOMM tiene construido un esquema para emulacin de null modem y usa a L2CAP para cumplir con el control de flujo requerido por alguna aplicacin [3].

1.7 PERFILES BLUETOOTH

El estndar Bluetooth fue creado para ser usado por un gran nmero de fabricantes e implementado en reas ilimitadas. Para asegurar que todos los dispositivos que usen Bluetooth sean compatibles entre s son necesarios esquemas estndar de comunicacin en las principales reas. Para evitar diferentes interpretaciones del estndar Bluetooth acerca de cmo un tipo especfico de aplicacin debera ser implementado, el Bluetooth Special Interest Group (SIG), ha definido modelos de usuario y perfiles de protocolo. Un perfil define una seleccin de mensajes y procedimientos de las especificaciones Bluetooth y ofrece una descripcin clara de la interfaz de aire para servicios especficos. Un perfil puede ser descrito como una rebanada completa del stack de protocolo. Existen cuatro perfiles generales definidos, en los cuales estn basados directamente algunos de los modelos de usuario ms importantes y sus perfiles. Estos cuatro modelos son Perfil Genrico de Acceso (GAP), Perfil de Puerto Serial, Perfil de Aplicacin de Descubrimiento de Servicio (SDAP) y Perfil Genrico de Intercambio de Objetos (GOEP). A continuacin se hace una breve descripcin de estos y algunos otros perfiles Bluetooth [4]. La Figura 1-16 muestra el esquema de los perfiles Bluetooth. En ella se puede observar la jerarqua de los perfiles, como por ejemplo que todos los perfiles estn contenidos en el Perfil Genrico de Acceso (GAP).

Figura 1.16. Los Perfiles Bluetooth

1.7.1 Perfil Genrico de Acceso (GAP). Este perfil define los procedimientos generales para el descubrimiento y establecimiento de conexin entre dispositivos Bluetooth. El GAP maneja el descubrimiento y establecimiento entre unidades que no estn conectadas y asegura que cualquier par de unidades Bluetooth, sin importar su fabricante o aplicacin, puedan intercambiar informacin a travs de Bluetooth para descubrir qu tipo de aplicaciones soportan las unidades.

1.7.2

Perfil de Puerto Serial.

Este perfil define los requerimientos para

dispositivos Bluetooth, necesarios para establecer una conexin de cable serial emulada usando RFCOMM entre dos dispositivos similares. Este perfil solamente requiere soporte para paquetes de un slot. Esto significa que pueden ser usadas ratas de datos de hasta 128 kbps. El soporte para ratas ms altas es opcional.

RFCOMM es usado para transportar los datos de usuario, seales de control de modem y comandos de configuracin. El perfil de puerto serial es dependiente del GAP.

1.7.3 Perfil de Aplicacin de Descubrimiento de Servicio (SDAP). Este perfil define los protocolos y procedimientos para una aplicacin en un dispositivo Bluetooth donde se desea descubrir y recuperar informacin relacionada con servicios localizados en otros dispositivos. El SDAP es dependiente del GAP.

1.7.4 Perfil Genrico de Intercambio de Objetos (GOEP). Este perfil define protocolos y procedimientos usados por aplicaciones para ofrecer caractersticas de intercambio de objetos. Los usos pueden ser, por ejemplo, sincronizacin, transferencia de archivos o modelo Object Push. Los dispositivos ms comunes que usan este modelo son agendas electrnicas, PDAs, telfonos celulares y telfonos mviles. El GOEP es dependiente del perfil de puerto serial.

1.7.5 Perfil de Telefona Inalmbrica. Este perfil define cmo un telfono mvil puede ser usado para acceder a un servicio de telefona de red fija a travs de una estacin base. Es usado para telefona inalmbrica de hogares u oficinas pequeas. El perfil incluye llamadas a travs de una estacin base, haciendo llamadas de intercomunicacin directa entre dos terminales y accediendo adicionalmente a redes externas. Es usado por dispositivos que implementan el llamado telfono 3-en-1.

1.7.6 Perfil de Intercomunicador. Este perfil define usos de telfonos mviles los cuales establecen enlaces de conversacin directa entre dos dispositivos. El

enlace directo es establecido usando sealizacin de telefona sobre Bluetooth. Los telfonos mviles que usan enlaces directos funcionan como walkie-talkies.

1.7.7

Perfil de Manos Libres.

Este perfil define los requerimientos, para

dispositivos Bluetooth, necesarios para soportar el uso de manos libres. En este caso el dispositivo puede ser usado como unidad de audio inalmbrico de entrada/salida. El perfil soporta comunicacin segura y no segura.

1.7.8

Perfil Dial-up Networking.

Este perfil define los protocolos y

procedimientos que deben ser usados por dispositivos que implementen el uso del modelo llamado Puente Internet. Este perfil es aplicado cuando un telfono celular o modem es usado como un modem inalmbrico.

1.7.9 Perfil de Fax. Este perfil define los protocolos y procedimientos que deben ser usados por dispositivos que implementen el uso de fax. En el perfil un telfono celular puede ser usado como un fax inalmbrico.

1.7.10 Perfil de Acceso LAN. Este perfil define el acceso a una red de rea local, LAN, usando el protocolo punto-a-punto, PPP, sobre RFCOMM. PPP es ampliamente usado para lograr acceder a redes soportando varios protocolos de red. El perfil soporta acceso LAN para un dispositivo Bluetooth sencillo, acceso LAN para varios dispositivos Bluetooth y PC-a-PC (usando interconexin PPP con emulacin de cable serial).

1.7.11 Perfil Object Push. Este perfil define protocolos y procedimientos usados en el modelo object push. Este perfil usa el GOEP. En el modelo object push hay procedimientos para introducir en el inbox, sacar e intercambiar objetos con otro dispositivo Bluetooth.

1.7.12

Perfil de Transferencia de Archivos.

Este perfil define protocolos y

procedimientos usados en el modelo de transferencia de archivos. El perfil usa el GOEP. En el modelo de transferencia de archivos hay procedimientos para chequear un grupo de objetos de otro dispositivo Bluetooth, transferir objetos entre dos dispositivos y manipular objetos de otro dispositivo. Los objetos podran ser archivos o flderes de un grupo de objetos tal como un sistema de archivos.

1.7.13 Perfil de Sincronizacin. Este perfil define protocolos y procedimientos usados en el modelo de sincronizacin. ste usa el GOEP. El modelo soporta intercambios de informacin, por ejemplo para sincronizar calendarios de diferentes dispositivos.

2. DESCRIPCIN DE HARDWARE Y PRODUCTOS BLUETOOTH

Despus de analizar y comprender la tecnologa Bluetooth se procedi a hacer una bsqueda de productos disponibles en el mercado con el fin de conocer las diversas aplicaciones que se ofrecen y principalmente determinar qu producto adquirir o implementar para el desarrollo de esta tesis. En este captulo se presenta una descripcin detallada del hardware implementado y se hace una breve descripcin de los diferentes tipos de productos Bluetooth disponibles as como el procedimiento mediante el cual se califica un producto como producto Bluetooth.

2.1 TARJETAS BLUEBOARDUV

Uno de los puntos esenciales para el desarrollo de esta tesis fue la utilizacin de hardware para la implementacin. Despus de conocer los diferentes tipos de productos Bluetooth disponibles (ver seccin 2.2), se hizo un anlisis de las mejores opciones teniendo en cuenta ventajas, desventajas, costo, accesibilidad, etc. Para cumplir con el objetivo principal de este trabajo, es decir, la implementacin de una red Bluetooth, se decidi construir sistemas semiembebidos Bluetooth utilizando mdulos, antenas y dems dispositivos perifricos necesarios. A las tarjetas construidas se les dieron los nombres de

BlueboardUV01 y BlueboardUV02. La diferencia principal entre los dos tipos de tarjeta radica nicamente en el tipo de antena utilizado y por consiguiente los requerimientos de antena tenidos en cuenta para cada una son diferentes. En la Figura 2-1 se muestra el diagrama de bloques de las tarjetas BlueboardUV. En la grfica se pueden observar las principales partes que las conforman.

Figura 2-1. Diagrama de Bloques de las tarjetas BlueboardUV

Los bloques funcionales de las tarjetas son: Mdulo Bluetooth: es el chip-multichip que tiene implementadas las capas ms bajas del stack y posee diferentes interfaces para lograr comunicacin de voz y datos. Es el bloque ms importante del sistema. Antena: ya que el mdulo no incluye una antena, ste es un dispositivo externo necesario para lograr la comunicacin Bluetooth. Es el dispositivo con ms requerimientos de diseo.

Transceiver RS-232: necesario para convertir las seales RS-232 de una fuente de menor a mayor valor de voltaje (de 3.0V a 5.5V). Regulacin de voltaje: necesario para el suministro de potencia del mdulo y el transceiver RS-232. El voltaje regulado es de 3.3V.

2.1.1 Descripcin de las tarjetas BlueboardUV. A continuacin se presenta una descripcin general de las tarjetas, informacin ms detallada se presenta en secciones posteriores. Entre las principales caractersticas de las tarjetas BlueboardUV estn: Mdulo de acuerdo a la versin 1.0b de Bluetooth Mdulo removible usando el Carrier Socket de SUYIN para mdulos Bluetooth Acceso a todas las seales del mdulo Pin de encendido externo Salida RF de potencia clase 2 (0dBm-rango de 10m) LED de monitoreo para suministro de energa Tres interfaces para diversas aplicaciones; UART para datos PCM para voz USB para datos Rata mxima de transmisin de datos sobre UART de 460,8 kbps Reset manual Capas inferiores del stack Bluetooth incluidas en el hardware, desde el HCI hasta la capa de radio. Antena RangeStar 100929 100930 incluida Operacin Punto a Multi-Punto (dependiendo del mdulo utilizado)

Las tarjetas BlueboardUV nicamente soportan comunicacin de datos, sin embargo poseen una interfaz PCM disponible para comunicacin de voz. La comunicacin entre la tarjeta y el controlador de host se hace a travs de la interfaz USB o la interfaz UART/PCM. El mdulo ROK101007/8 usado soporta todos los perfiles definidos en la versin 1.0b de la especificacin Bluetooth.

Las tarjetas BlueboardUV necesitan una alimentacin de 5VDC que pueden suministrarse a travs del conector USB o por medio de un terminal macho genrico. Poseen un convertidor DC/DC que proporciona la alimentacin al mdulo Bluetooth Ericsson ROK101007/8. El diagrama esquemtico de las tarjetas se muestra en la Figura 2-2. Se pueden observar los dispositivos utilizados para los diferentes bloques funcionales: mdulo Ericsson ROK101007, antena RangeStar 100929 100930, transceiver Maxim MAX3232 y regulador de voltaje National LP2987.

El voltaje regulado necesario para la alimentacin del mdulo y el transceiver RS232 es suministrado por el LP2987. Su circuito, tiene un pin de encendido externo (ON/OFF), que permite habilitar el suministro de potencia a la tarjeta. Adems, para verificar el estado de la excitacin, posee un LED de monitoreo (D1). El voltaje regulado es de 3.3V. El mdulo posee diferentes interfaces de comunicacin: USB, RS-232, PCM e I2C. Las seales RS-232 que salen del mdulo, antes de ir al conector macho RS232 son convertidas a un voltaje mayor por medio del MAX3232. Al usar la interfaz UART el mdulo funciona como un Equipo de Comunicacin de Datos (DCE), con una velocidad de 57,6 kbps por defecto. La interfaz USB cumple con la especificacin 1.1. Las seales USB, PCM e I2C estn conectadas directamente a su correspondiente conector macho (CONECTOR_USB, PCM, I2C). La seal ANT del mdulo est conectada directamente al terminal de alimentacin de la antena (RangeStar 100929/30).

Figura 2-2. Diagrama esquemtico de las tarjetas BlueboardUV

En la Tabla 2-1 se presenta la lista de componentes de una tarjeta BlueboardUV detallando las referencias dentro de la tarjeta y de fabricante para cada componente.

Tabla 2-1. Lista de componentes para la tarjeta BlueboardUV No Tipo de Dispositivo 1 2 3 4 5

Antena [7] C1206 Capacitor 0,1uF 3x1,5x1mm IC, Mdulo Bluetooth Soporte Carrier socket IC, Regulador de Voltaje IC, Interfaz RS-232 SO16L(W) M08A [6] [5]

Tipo de paquete

Referencia de Componente
ERICSSON ROK101007 / 8 SUYIN BT001A-30G2T NATIONAL LP2987AIM 3.3V SMD MAXIM MAX3232 EEWE/CWE 3.3V SMD RANGESTAR 100929 100930 Cond. 0,1uF/50V SMD Monolitico Cond. 0,47uF/50V 10%

Cant.

Referencia en Tarjeta (Ver Figuras 2-3 y 2-4)

Sobre el soporte

CARRIER SOCKET

CARRIER SOCKET

M08A

MAX3232 Rangestar

100929 100930

6 7
Capacitor 0,47uF

C4, C5, C6, C7,C8

KEMET_C KEMET_C

SMD Tantalio SPRAG Cond. 4.7uF/20V SMD Tantalio 5% 1/8W SMD 5% 1/8W SMD 5% 1/4W SMD LED uMiniatura 1,7mcd

C2

8
Capacitor 4.7uF

6032 R1206 R1206 R1206

2 1 1 1

C1, C3 R1 R2 R3

9 10 11 12

Resistencia 100K Resistencia 330K Resistencia 220

Diodo LED

SOT-23 PN87520 B3F-10XX MA02-1 MA02-2 MA05-2

LiteOn SMD CON-BERG Switch-omron 10-XX con-lstb con-lstb con-lstb

1 1 1 1 1 2

D1 USB_CONNECTOR S1 ON/OFF I2C PCM, RS232

13 14 15 16 17

Conector USB Switch Jum 1X2 Jum 2X2 Jum 5X2

Total de partes

23

Las Figuras 2-3 y 2-4 muestran diagramas del hardware de las tarjetas BlueboardUV01 y BlueboardUV02 respectivamente. Las grficas son una representacin detallada de las tarjetas. Cada dispositivo utilizado tiene asociada una referencia, facilitando su localizacin fsica. El tamao real de las tarjetas es de 8,5 x 7,5 cm.

Figura 2-3. Diagrama del hardware de la tarjeta BlueboardUV01

Figura 2-4. Diagrama del hardware de la tarjeta BlueboardUV02

Con el fin de conocer y entender mejor el funcionamiento de las tarjetas BlueboardUV, a continuacin se hace una descripcin detallada de los principales dispositivos utilizados y los requerimientos que se debieron tener en cuenta para la implementacin de las tarjetas.

2.1.2 Descripcin de componentes y requerimientos en las tarjetas BlueboardUV.

2.1.2.1 Mdulo Bluetooth Ericsson ROK101007/8. Para la implementacin de las tarjetas BlueboardUV01 y BlueboardUV02 se utilizaron los mdulos de Ericsson ROK101007 y ROK101008. Su escogencia se hizo teniendo en cuenta la robustez y la compatibilidad con otros dispositivos. El ROK101007 se diferencia del ROK101008 nicamente en que el primero soporta conexin punto a punto y punto a multi-punto y el segundo nicamente conexin punto a punto, por esto de aqu en adelante solamente se hace referencia al mdulo ROK101007. A continuacin se presenta una descripcin general del mdulo. Mayor informacin se encuentra en la Web [5].

Las principales ventajas del mdulo Ericsson ROK101007 son: Pre-calificado con la especificacin Bluetooth 1.0B Potencia de salida RF clase 2 Aprobado por la FCC y la ETSI Rata mxima sobre UART de 460 kb/s Distintas interfaces: UART para datos, PCM para voz y USB para voz y datos. Interfaz I2C Cristal oscilador interno Firmware HCI incluido Blindado

El ROK101007 es un mdulo de corto rango para implementaciones Bluetooth en diferentes dispositivos electrnicos que soporta transmisiones de datos y voz. La comunicacin entre el mdulo y el controlador de host se lleva a cabo a travs de

una interfaz de alta velocidad USB acorde a las especificaciones USB 1.1 o a travs de una interfaz UART/PCM. Al utilizar la interfaz USB, el mdulo funciona como un dispositivo esclavo USB y por lo tanto no requiere recursos del PC. El ROK101007 es un mdulo Bluetooth Clase 2 (0dBm) y adems soporta todos los perfiles Bluetooth.

El ROK101007 es un chip multi-chip de 30 pines de 3.3 x 1.7cm aproximadamente, que por su dimensin facilita implementaciones en dispositivos porttiles y de tamao reducido. El mdulo consta de tres partes principales; Controlador Banda Base, Memoria Flash y Radio. Los bloques operacionales del ROK101007 los conforman los tres anteriores, ms un bloque de Manejo de Potencia y otro de Reloj.

El Controlador Banda Base es un ARM7 que controla la operacin del radio transceiver a travs de una interfaz USB o UART, y adicionalmente tiene una interfaz de voz PCM y una interfaz I2C La Memoria Flash es usada con el Controlador Banda Base El Radio es implementado con el radio Ericsson PBA 913 01/2 En el Manejo de Potencia se regula y filtra el voltaje de alimentacin Vcc que tpicamente es de 3.3V El Reloj interno trabaja a 13MHz con una precisin en el oscilador de cristal de 20ppm.

Partes Hardware / Firmware del ROK101007. El mdulo ROK101007 incluye partes HW/FW del stack de protocolo Bluetooth. Las partes de HW incluidas son el Radio y la Banda Base, y las de FW, las cuales residen en la Flash, son la Interfaz del Controlador de Host, HCI, y el Manejador de Enlace, LM. En la Figura 2-5 se pueden observar las partes de HW/FW incluidas en el mdulo.

Figura 2-5. HW/FW del mdulo Ericsson ROK101007

Interfaz de Radio: el mdulo es un dispositivo clase 2 con una salida mxima de potencia de 4dBm. El rango nominal del mdulo con una antena tpica es de hasta 10 m (a 0 dBm).

Banda Base: Se usa una estructura de red ad-hoc con un nmero mximo de ocho unidades activas en una sola piconet.

Interfaces HW del Mdulo.

Interfaz USB: El mdulo es un dispositivo USB de alta velocidad (12Mbps) que tiene toda la funcionalidad de un esclavo USB y est de acuerdo con la especificacin USB 1.1 La transferencia de datos se hace a travs de los puertos bidireccionales D+ & D-, y adicionalmente se usan las lneas Wake_up y Detach. En la Figura 2-6 se puede observar la configuracin tpica para una aplicacin USB.

Interfaz UART: esta interfaz es acorde al estndar industrial 16C450 y soporta las siguientes ratas de bits: 300, 600, 900, 1200, 1800, 2400, 4800, 9600, 19200, 38400, 57600, 115200, 230400 y 460800 bits/s. Existen FIFOs de 128 bytes asociadas con la UART. Para esta interfaz se tienen cuatro seales, TxD & RxD se usan para flujo de datos, y RTS & CTS se usan para control de flujo. En la Figura 2-7 se muestra la configuracin tpica para una aplicacin UART o PCM.

Interfaz de voz PCM: la interfaz estndar PCM tiene una rata de muestreo de 8kHz (PCM_SYNC). El reloj PCM es variable entre 200kHz y 2MHz. Los datos PCM pueden ser: PCM 13-16 bits, u-Law 8 bits A-Law 8 bits. En este caso se tienen cuatro lneas de conexin PCM_IN, PCM_OUT, PCM_SYNC y PCM_CLK. En la Figura 2-7 se puede observar la configuracin tpica para una aplicacin UART O PCM.

Interfaz I2C: En el mdulo se encuentra disponible una interfaz I2C maestro.

Figura 2-6. Configuracin Tpica USB para el ROK101007

Figura 2-7. Configuracin Tpica UART o PCM para el ROK101007

2.1.2.2 Diseo de Antena. En cualquier sistema de comunicacin inalmbrica, la antena es un componente crtico cuya implementacin influye significativamente en el desempeo global del sistema. Esto se debe a que la antena es el elemento que convierte las seales elctricas conducidas por las pistas de la tarjeta de circuito impreso (PCB) a seales que se propagan a travs del espacio libre; por lo tanto acta como una impedancia y un dispositivo de conversin. No obstante la antena normalmente es uno de los componentes ms descuidados en un sistema de comunicacin inalmbrica.

Principales parmetros de la Antena. Una antena se caracteriza por varios parmetros relevantes que deben ser tenidos en cuenta para el diseo de un sistema inalmbrico. Entre los ms importantes estn: la Frecuencia de

Operacin, el Ancho de Banda, la Impedancia de Entrada, la Ganancia de Antena, la Eficiencia de Radiacin y el Tamao de la Antena.

 Banda de frecuencia Bluetooth.

A pesar de que algunos pases han

especificado diferentes rangos de frecuencia para la banda 2.4 GHz ISM (Bluetooth), todos ellos estn contenidos dentro del rango de frecuencia de 2.4002.497GHz. Por consiguiente para una implementacin Bluetooth se debe utilizar una antena que trabaje sobre todo este rango, para asegurar la mxima compatibilidad del dispositivo y el uso de los canales disponibles.

Ganancia de Antena.

Tal como los rayos de sol son menos intensos a

mayores distancias, la potencia de todas las antenas decrece con el incremento de la distancia. Adems, la rata a la cual esta potencia decrementa es siempre la misma, por lo tanto, la nica forma de incrementar la potencia recibida en un lugar apartado es aumentando la potencia de RF (Radio Frecuencia) en esa direccin. Es aqu donde la ganancia de la antena es til; esta debe ser tenida en cuenta, ya que tiene un impacto directo en el desempeo y el rango mximo de un dispositivo Bluetooth, adems de ser uno de los nicos elementos controlables en la trayectoria de la seal desde el transmisor hasta el receptor. El uso de antenas con baja ganancia limita ampliamente la mxima distancia de alcance de una seal Bluetooth. La unidad de medida para la ganancia de una antena est dada usualmente en dBi, que es una sigla para decibeles relativos a una fuente isotrpica.

El Plano de Tierra. La mayora de antenas inalmbricas requieren un Plano de Tierra sobre el PCB. Su longitud debe ser aproximadamente un cuarto () de la longitud de onda de operacin. As, si la frecuencia de trabajo en Bluetooth es de 2425 MHz, la longitud de onda () es 124 mm y de esta manera la mnima longitud del Plano de Tierra sera de 31 mm. A medida que la longitud del Plano de Tierra se hace mayor a de la longitud de onda, el patrn de radiacin se hace cada vez ms multi-lbulo. Esto generalmente no afecta a la mayora de

aplicaciones. Sin embargo, si el Plano de Tierra es significativamente menor a de la longitud de onda, la sintonizacin se hace cada vez ms difcil y el desempeo global disminuye. Esto es comn en todas las antenas, por ejemplo, las antenas de los beepers son muy ineficientes debido a su tamao, el cual es significativamente ms pequeo que su longitud de onda de operacin. En la Figura 2-8 se observa el comportamiento de la Ganancia de Antena con respecto al tamao del Plano de Tierra.

Figura 2-8. Ganancia Pico vs. Longitud PCB

Fuente: RangeStar Wireless, Inc.

Segn la Figura 2-8, para lograr un ptimo desempeo de la antena se debe tratar de obtener un plano de tierra de 0.33 veces la longitud de onda de operacin. En las tarjetas BlueboardUV el plano de tierra se implement por las dos caras del PCB y se interconectaron los dos planos por medio de vas localizadas en toda la superficie de las tarjetas con el fin de evitar diferencias de potencial mnimas que puedan afectar el desempeo del sistema. En las Figuras 2-9 a 2-12 se pueden observar el plano de tierra y las vas implementadas en las tarjetas. stas

muestran el ruteo por ambas caras de la Tarjeta de Circuito Impreso (PCB) para las tarjetas BlueboardUV. Informacin ms detallada se puede encontrar en el CDROM anexo con este documento.

Figura 2-9. Ruteo de la parte superior de la tarjeta BlueboardUV01

Figura 2-10. Ruteo de la parte inferior de la tarjeta BlueboardUV01

Figura 2-11. Ruteo de la parte superior de la tarjeta BlueboardUV02

Figura 2-12. Ruteo de la parte inferior de la tarjeta BlueboardUV03

Efectos de localizacin de la antena. La localizacin de la antena sobre el PCB afecta el desempeo del sistema en mayor proporcin que el tamao del Plano de Tierra. En general, las esquinas son el mejor lugar de montaje. La localizacin de la antena no debe ser escogida solamente por su patrn de radiacin, tambin se debe tener en cuenta que la antena no perturbe otras partes del sistema y que ningn disturbio sea introducido al sistema Bluetooth a travs de la antena.

2.1.2.3 Antenas RangeStar.

En este proyecto se utilizaron las antenas

RangeStar 100929 y 100930 [7]. A continuacin se presentan sus principales

caractersticas adems de una descripcin de los requerimientos tenidos en cuenta para la construccin de las tarjetas BlueboardUV.

Diseo del PCB.

Las antenas de RangeStar estn diseadas para ser

montadas al final de un PCB, as se utiliza la mxima longitud del Plano de Tierra para emitir las ondas electromagnticas y a pesar de que haya una pequea diferencia en el desempeo global, estas antenas se deben montar junto al dispositivo que emite mayor energa.

Estas antenas tienen varios terminales, cada uno de ellos con una funcin diferente. Un terminal sirve como alimentacin de la seal RF mientras que los dems pueden servir como conexin a tierra, como conexin de soporte o las dos (conexin a tierra y soporte). El pad del terminal de alimentacin se debe conectar a una lnea de transmisin de 50 Ohm y los pads de los terminales de conexin a tierra, se deben conectar elctricamente al Plano de Tierra del PCB. Cada antena tiene una distancia de aislamiento recomendada, que corresponde a la mnima distancia permitida entre la antena y cualquier conductor sobre el PCB. Si algn conductor est ms cerca que la distancia de aislamiento especificada el desfase de capacitancia generado des-sintoniza la antena.

Ya que Bluetooth implica el uso de RF y adems la frecuencia de operacin est en la banda de los 2.4 GHz, las precauciones que se deben tener en cuenta al trabajar en este rango de frecuencia son severas e indispensables. Las especificaciones del fabricante se deben cumplir con la mayor precisin posible y el sistema no se debe encerrar dentro de una estructura metlica para evitar efectos similares al de una Jaula de Faraday, que puede generar un bajo desempeo.

 Antenas RangeStar 100929 y 100930.

Las antenas RangeStar 100929 y

100930 se caracterizan por tener un buen ancho de banda, alta ganancia en tamao reducido, son pequeas, livianas y fciles de usar. Las Figuras 2-13 y 2-14 muestran las antenas RangeStar 100929 y 100930 respectivamente, al igual que el patrn de radiacin para cada una de ellas. En la Tabla 2-2 se presentan las principales caractersticas de cada una.

Figura 2-13. Antena RangeStar 100929

Figura 2-14. Antena RangeStar 100930

Tabla 2-2. Caractersticas de las antenas RangeStar 100929 y 100930

ANTENA RANGESTAR CARACTERSTICAS 100929 Bluetooth, 802.11b Aplicaciones Telfonos mviles, dispositivos porttiles, PDAs, aplicaciones industriales, instrumentos. Rango de Frecuencia (MHz) Pico de Ganancia VSWR Haz Impedancia del Punto de Alimentacin Tamao 29.0 x 11.6 x 3.0 mm > 4.5dBi < 2.0 : 1 Omnidireccional 50 Ohms 16mm diam. X 6.0mm 2400 - 2483.5 > 4 dBi < 2.5 : 1 Patrn Hemisfrico 100930

Para el diseo del PCB en las tarjetas BlueboardUV se tuvieron en cuenta varios requerimientos de antena tales como la distancia de aislamiento, el tamao y localizacin de los pads para cada terminal, el rea clara alrededor de los pads, el rea libre de componentes, el rea clara alrededor de la lnea de alimentacin de la antena, entre otros [7]. Uno de los requerimientos ms importantes es que la distancia desde el pin de salida RF hasta la antena debe ser lo ms corta posible. Los requerimientos de antena son diferentes para cada tipo de antena y se aplicaron con la mayor precisin posible. En la Figura 2-15 se pueden observar las dos libreras creadas en el programa CAD para los dos tipos de antena utilizados. En ella se pueden visualizar los diferentes requerimientos que se tuvieron en cuenta y que son necesarios para cada una de las antenas.

Figura 2-15. Requerimientos para las antenas RangeStar 100929 y100930

2.1.2.4 Regulador de Voltaje National LP2987. Para la regulacin de voltaje de las tarjetas BlueboardUV se us el regulador de voltaje National LP2987AIM 3.3. ste es un regulador de voltaje de 200mA de salida fija con un reset de retardo de encendido implementado con un capacitor externo. El voltaje regulado necesario en las tarjetas BlueboardUV es de 3.3V, con el cual se alimentan el mdulo Bluetooth y el MAX232. El regulador tiene una salida de precisin de 0.5%. La Figura 2-16 muestra el diagrama de bloques para el LP2987. Para mayor informacin se puede consultar la pgina web de National Semiconductors [8].

Figura 2-16. Diagrama de bloques del regulador de voltaje LP2987

Fuente: National Semiconductors

2.1.2.5 MAXIM MAX3232. El MAXIM MAX3232 es una interfaz de comunicacin con requerimientos de baja potencia. Este transceiver habilita el cambio en RS232 de una alimentacin de 3.0V a una de 5.5V. Tiene 2 receptores y 2 drivers. El MAX3232 solamente requiere cuatro pequeos capacitares externos de 0.1uF y es garantizado para correr a una rata de datos de 120kbps (MAX3232) o 250kbps (MAX3232E) manteniendo los niveles de salida RS-232. Para encontrar informacin ms detallada se puede consultar en la pgina web de MAXIM [9].

2.1.2.6

Soporte SUYIN BT001A-30G2T.

Con el fin de hacer de las tarjetas

BlueboardUV sistemas ms flexibles, se utiliz una base soporte para el mdulo de Ericsson ROK101007. El soporte es el Bluetooth Carrier Socket BT001A30G2T de SUYIN CONNECTOR [6]. Este soporte permite intercambiar mdulos sin necesidad de recurrir a desoldar las tarjetas. En la Figura 2-17 se puede

observar la librera del soporte que se implement en el programa CAD para el diseo de las tarjetas. ste posee 30 pines de conexin al igual que el mdulo de Ericsson utilizado.

Figura 2-17. Bluetooth Carrier Socket SUYIN BT001A-30G2T

2.1.3 Fotografas de las tarjetas BlueboardUV.

Las Figuras 2-18 a 2-21

muestran varias fotografas de las tarjetas BlueboardUV, en la Figura 2-20 se puede observar la tarjeta BlueboardUV01 en funcionamiento, conectada a un PC por medio de un cable USB.

Figura 2-18. Tarjeta BlueboardUV01

Figura 2-19. Mdulo Bluetooth dentro del soporte en la tarjeta BlueboardUV01

Figura 2-20. Tarjeta BlueboardUV01 en funcionamiento

Figura 2-21. Tarjeta BlueboardUV02

2.2 PRODUCTOS BLUETOOTH

La oferta de productos Bluetooth en el mercado es muy amplia y variada. Existen productos de muchos tipos y de diversos fabricantes. Entre los tipos de productos ms destacados estn: partes para integrar sistemas Bluetooth, tales como amplificadores, radio transceivers, controladores, antenas, mdulos etc.; productos embebidos tales como kits, herramientas de desarrollo, adaptadores USB, tarjetas PC, tarjetas PCMCIA y productos especficos muy variados; y por ltimo, productos de software Bluetooth. En la Tabla 2-3 se nombra algunos de ellos, sin embargo, se puede encontrar informacin ms detallada de productos y fabricantes en el CD-ROM anexo a este libro.

Tabla 2-3. Algunos productos Bluetooth disponibles en el mercado

TIPO DE PRODUCTO

FABRICANTE
CSR BLUEFROG

REFERENCIA
BC01MOD2B rbm3rc-r LMX982x ROK101007 Blue Snake Kit AT76C551-BLSNK Development System MkII Demo Card Application and Training Tool Kit

MAS INFO. [10] [11] [12] [5] [13] [11] [14] [5] [5] [15] [16]

MDULOS

NATIONAL ERICSSON ATMEL BLUEFROG

KITS

DIGIANSWER

TELECA 3COM TARJETAS SMART

Development Kit PC Card y adaptador USB Bluesapphire tarjeta PCMCIA Core Bluetooth Software Stack,

SOFTWARE

TELECA

Profiles, Bluetooth HCI Toolbox, Bluetooth Log Analyzer

[5]

TIPO DE PRODUCTO

FABRICANTE
ANOTO

REFERENCIA
Bluetooth Pen

MAS INFO.

[17]

OTROS

TELECA

Solucin de audfonos Bluetooth Remote Speaker Microphone HMN3158A

[5]

MOTOROLA

[18]

2.3 PROCEDIMIENTO DE CALIFICACIN BLUETOOTH

El propsito de este sub-captulo es brindar una descripcin del procedimiento que se debe seguir para calificar un producto como Producto Bluetooth. Con el propsito de minimizar o eliminar problemas de interoperatividad el Bluetooth Qualification Program (BQP) ha definido un grupo especfico de procedimientos. Este es un requerimiento necesario antes de que un producto pueda ser calificado de acuerdo con Bluetooth. La calificacin Bluetooth es el proceso mediante el cual un fabricante demuestra conformidad con la especificacin Bluetooth y el BQP es la base que establece las reglas y procedimientos de calificacin. El BQP fue creado independientemente de algn tipo de aprobacin administrativa obligatoria de reglamentaciones nacionales o internacionales.

Un fabricante de productos con la tecnologa inalmbrica Bluetooth debe suscribirse al contrato de membresa del SIG Bluetooth. Cuando el producto

cumple con la especificacin Bluetooth, es adicionado a la lista de productos Bluetooth. Esto otorga a la Compaa Miembro una licencia que cubre los

derechos de patente de la propiedad intelectual de derechos de autor y le permite usar la marca Bluetooth en productos y actividades de mercadeo de acuerdo con el libro de la marca Bluetooth. Informacin ms detallada acerca de la calificacin

Bluetooth se puede encontrar en enlace Developer Information ->Qualification Program de la pgina oficial de Bluetooth [19].

2.4 ANTENAS EN F INVERTIDA INTEGRADAS

Una buena posibilidad para la construccin de PCBs que impliquen el uso de antenas, es el diseo de Antenas en F Invertida (IFAs). Estas antenas tienen una estructura de bajo perfil, son livianas y fciles de integrar en equipos de comunicacin personales. A pesar de que en esta tesis no se implement una antena de este tipo, la informacin que se describe a continuacin acerca de este tema puede resultar muy til para posteriores proyectos.

Existen tres clases de IFAs: las IFAs con elementos convencionales, las antenas en F invertida planares (PIFAs) y las Antenas en F Invertida Integradas (IIFAs). Para hacer ms compactas las IFAs, los elementos de la antena se pueden imprimir en el plano superior del substrato del PCB, para formar una IIFA. Este tipo de antenas ya se ha usado en aplicaciones Bluetooth [20]. Esto significa que al disear un sistema inalmbrico, no se hace obligatoria la compra o adquisicin de una antena sino que se puede disear en el PCB. En el diseo de este tipo de antenas se tienen en cuenta parmetros tales como el espesor, la constante dielctrica y la caracterstica de impedancia del substrato, as como la separacin y el ancho de las lneas y por supuesto la frecuencia de operacin. Se puede conseguir informacin ms detallada en distintas fuentes incluso en la web [20] [21]. En la Figura 2-22 se observa un esbozo de una Antena en F Invertida

Integrada (IIFA).

Figura 2-22. Antena en F Invertida Integrada (IIFA)

3. SOFTWARE PARA EL HOST BLUETOOTH

El software para el host Bluetooth corresponde a las capas del stack de protocolos y utilidades Bluetooth implementadas en software e instaladas en el host. Un host puede ser cualquier sistema microprocesado programable (PCs, telfonos celulares, mouse, impresoras, teclados, sensores inalmbricos, etc.), capaz de ejecutar las lneas de cdigo correspondientes al stack de protocolos para el host. En esta plataforma es necesario tener una interfaz UART o USB para comunicar el host y el mdulo Bluetooth.

Son muchos los stacks de protocolos Bluetooth disponibles para el host, implementados en diversos lenguajes de programacin y sobre distintas plataformas, siendo tambin muchas las empresas interesadas en su desarrollo. Independientemente de la plataforma o el lenguaje de programacin, estos se basan en el CORE [3] y los PROFILES [4] de la especificacin del sistema Bluetooth.

Figura 3-1. Modelo de implementacin del protocolo Bluetooth, Host Hardware

La Figura 3-1 muestra un modelo de implementacin del stack de protocolos Bluetooth, discriminando las capas que estn implementadas en el host y las que estn en el Hardware Bluetooth (mdulos, tarjetas, sistemas de desarrollo Bluetooth), como es el caso de las tarjetas Blueboard_UV01 y Blueboard_UV02 desarrolladas en esta tesis.

Figura 3-2. Modelo de Implementacin del protocolo Bluetooth. Software Firmware Hardware

La Figura 3-2 describe esquemticamente la implementacin del stack de protocolos Bluetooth al nivel de software, firmware y hardware, especificando su ubicacin ya sea en el host o en el hardware Bluetooth.

El host y el hardware Bluetooth se comunican a travs del HCI (Host Controller Interface) o Interfaz Controladora de host. El firmware HCI implementa los Comandos HCI para el hardware Bluetooth teniendo acceso a los comandos de

banda base, manejador de enlace, registros de estatus del hardware, registros de control y registros de eventos.

Muchas capas pueden existir entre el driver HCI ubicado en el host y el firmware HCI ubicado en el hardware Bluetooth. Estas capas intermedias, se encargan del control y transporte de datos a travs de un medio fsico (un bus fsico ya sea USB, PC Card, RS232, u otro), para que se establezca una comunicacin transparente entre el driver HCI y el firmware HCI, permitiendo el intercambio de datos y comandos entre estos dos.

El host recibir notificaciones asncronas de los eventos HCI independientemente de la capa de control de transporte del host que se est usando. Los eventos HCI son usados para notificar al host cuando algo ocurre.

3.1

ARQUITECTURAS DE INTEGRACIN DEL STACK DE PROTOCOLOS BLUETOOTH

La mayor o menor integracin del stack de protocolos Bluetooth en un sistema, depende del tipo de producto que se est desarrollando; de esta manera y como se puede observar en la Figura 3-3, tres diferentes arquitecturas podran implementarse. Cabe resaltar que no son las nicas.

Figura 3-3. Tres modelos de Integracin del stack de protocolos Bluetooth

La Figura 3-3 a describe una solucin estndar de dos procesadores, en donde la divisin entre las capas altas de protocolo y las bajas toma lugar en el HCI, esto asume que el host es en general algn tipo de plataforma computacional cuyas capacidades de comunicacin son ilimitadas. Este es el caso de las computadoras personales.

En la Figura 3-3 b se puede observar una arquitectura embebida de dos procesadores, la cual permite que los productos puedan disearse para incorporar Bluetooth donde el host es un recurso limitado y no es capaz de soportar la

adicin de una funcionalidad Bluetooth. Un ejemplo de este caso es un telfono mvil; no todos los telfonos mviles tienen los suficientes recursos para implementar pilas de protocolo adicionales.

La Figura 3-3 c muestra una arquitectura embebida de un procesador; este es el caso de un producto que implementa el stack de protocolos Bluetooth completo en un solo chip. Un ejemplo es un manos libres inalmbrico, sin embargo, el modelo aplica a cualquier dispositivo inalmbrico pequeo [22].

3.2

PRINCIPALES SOFTWARE PARA EL HOST

Son muchas las compaas que trabajan en el desarrollo de stacks de protocolos Bluetooth para el host, en especial, los fabricantes de mdulos Bluetooth, quienes ofrecen productos de prueba y kits de desarrollo que incluyen software para el host, cuya finalidad es facilitar y agilizar el desarrollo de aplicaciones. Este software no es usualmente de libre distribucin, es decir que su licencia tiene un costo, el cual, en la mayora de los casos, est incluido en el costo del kit de desarrollo.

Sin embargo, los fabricantes de mdulos Bluetooth no son los nicos que ofrecen software para el host, hay muchas otras empresas y universidades interesadas en su desarrollo, razn por la cual es posible encontrar software demostrativo y de libre distribucin con licencia pblica GPL (GNU Public License).

En esta tesis se trata nicamente el software para sistemas cuyo host corresponde a un PC, es decir, no se cubre software para sistemas embebidos.

Los requerimientos tales como sistema operativo, capacidad de memoria, entre otros, son propios de cada software.

3.2.1 Software Bluetooth con propiedad de licencia. Debido a que muchas de las caractersticas de estos diferentes tipos de software son muy parecidas, se da una breve descripcin de los ms representativos.

Bluetooth Host Stack Software para el host desarrollado por Ericsson, el cual implementa las siguientes capas del stack de protocolos: driver HCI, L2CAP, RFCOMM, SDP y opcionalmente OBEX y TCS. Este stack est

escrito en ANSI C, y es independiente del ambiente de desarrollo (compilador, debugger, linker, etc.); esto sumado al concepto de Sistema Operativo Virtual, hace que este stack, sea adaptable tanto a sistemas operativos para sistemas embebidos como a los sistemas operativos estndar tales como Linux y Windows. Las siguientes son herramientas de software disponibles para Windows, basadas en el Bluetooth Host Stack de Ericsson: Bluetooth PC reference Stack, Bluetooth Development Kit y Bluetooth Application Tool Kit [23].

Bluetooth Software Suite

Desarrollado por Digianswer A/S, este software

escrito para Microsoft Windows adems de brindar un API (Interfaz de Programa de Aplicacin) de fcil uso, soporta los siguientes perfiles: acceso general, servicio de descubrimiento de aplicaciones, puerto serial, red de acceso conmutado, fax, acceso a LAN, OBEX, Object Push, transferencia de archivos y Ethernet [24].

BlueStack Software desarrollado por MEZOE, una divisin de Cambridge Consultants Ltd. Escrito en lenguaje C, implementa al igual que los dos anteriores, un driver HCI y las capas superiores del protocolo Bluetooth. Son ofrecidos varios productos basados en el BlueStack para Microsoft Windows: este es el caso de StackPrimer, Proto Developer e Interface Express [22].

La Tabla 3-1 muestra una recopilacin de algunos productos con propiedad de licencia que implementan el stack de protocolos Bluetooth para el host; se indica adems la empresa que lo desarrolla, herramientas de desarrollo para cada stack y el sistema operativo sobre el cual corre.

Tabla 3-1. Software Bluetooth para el Host con propiedad de licencia

NOMBRE DEL STACK Bluetooth Host Snack

FABRICANTE

HERRAMIENTAS DE DESARROLLO Bluetooth PC reference Stack Bluetooth Development Kit Bluetooth Application Tool Kit Digianswer Bluetooth Software Suite Digianswer Bluetooth Digianswer Bluetooth Statistics Digianswer Bluetooth HCI Router Digianswer HCI Test Application Digianswer API Proto Developer Tool Stack Partner Program

Ericsson

SISTEMA OPERATIVO SOPORTADO POR LA HERRAMIENTA Microsoft Windows

Bluetooth Software Suite

Digianswer A/S

Microsoft Windows

HCI

BlueStack Stack Partner Program

Mezoe National Semiconductor

Microsoft Windows Microsoft Win98, ME, 2000 y XP Microsoft WinCE Linux

NOMBRE DEL STACK Rappore Technologies' Software Developers Kit Socket Bluetooth Software BlueStack Software Development Kit Bluefrog Demostration FrogStack

FABRICANTE

HERRAMIENTAS DE DESARROLLO Software Developers Kit

Rappore Technologies

Socket

Bluetooth Connection Kit

Cambridge Silicon Radio Reselec ag Bluefrog

BlueStack Software Development Kit Bluefrog Demostration FrogSatck

SISTEMA OPERATIVO SOPORTADO POR LA HERRAMIENTA No especificado Cdigo fuente desarrollado en lenguaje C, C++ y Java Windows Powered Pocket PC Windows CE Windows NT

Net OS 3.0 Linux

3.2.2 Software Bluetooth con licencia pblica (GPL) En esta seccin se tratan las principales caractersticas de los tipos de productos de libre distribucin con licencia GPL desarrollados para Linux y disponibles en Internet. Los principales son: OpenBT, BlueDrekar, Bluez y Affix.

OpenBT Axis Communications Inc. desarroll, en primera instancia, un driver Bluetooth para Linux llamado OpenBT, el cual puede ser usado tanto en ambientes eLinux (Linux Embebido) como en Linux para PC. Este fue el primer stack de protocolos disponible, siendo ahora un proyecto de cdigo fuente abierto, desarrollado en un kernel de Linux 2.0.33, de tal manera que no debe presentar problemas de funcionamiento en versiones posteriores del kernel. Implementa el perfil de LAN mediante enlaces PPP sobre RFCOMM y adems una forma simple del perfil de descubrimiento de servicios (SDPP) [25].

El cdigo fuente en sus versiones para PC y eLinux, se encuentra disponible en el portal de Internet de Sourceforge [26], y es posible conseguir ms informacin en el portal del proyecto [27].

BlueDrekar

El driver Bluetooth de IBM, disponible bajo licencia GPL,

implementa la capa de transporte UART de la Interfaz Controladora del host (HCI). Este cdigo sirve de referencia para escribir drivers para otras capas de transporte HCI, como USB. El BlueDrekar middleware es una implementacin de referencia de las capas altas del protocolo Bluetooth, disponible bajo licencia alpha Works [28].

Segn el fabricante, este cdigo ha sido desarrollado y probado en PCs con procesadores de arquitectura i486 o superior, corriendo un kernel de Linux 2.2.12-20 (Red Hat 6.1), 2.2.14-5.0 (Red Hat 6.2), 2.2.16-22 (Red Hat 7). Han sido utilizados para realizar las pruebas de desempeo los mdulos Bluetooth de Ericsson con la capa de transporte UART y firmware versin P7C (v1.0A) y P3E (v1.0B).

Affix Este stack de protocolo para Linux fue desarrollado por el Centro de Investigacin de Nokia en Helsinki, Finlandia. El software Bluetooth de Affix trabaja sobre plataformas Intel, ARM (iPaq, ARM9 y otras) y PowerPC (iMac). Las ltimas versiones del software estn disponibles en el sitio web de Affix [29].

Bluez

Este es el stack de protocolos Bluetooth oficial de Linux, el cual es

parte del kernel 2.4 y posteriores. Bluez brinda a sus usuarios la capacidad de comunicacin con dispositivos Bluetooth, entre los que se tienen adaptadores USB, telfonos mviles y puntos de acceso entre otros, adems de conexin inalmbrica entre dos o ms computadoras. Bluez consta del core HCI, drivers HCI para UART, USB y emulador de HCI, mdulo del protocolo L2CAP y utilidades de configuracin y prueba [30].

3.3

CONCEPTOS DEL CORE DE LINUX

Estos conceptos bsicos sobre el subsistema de red de Linux son fundamentales para entender la manera como los drivers para los dispositivos de red (tarjetas de red) interactan con el sistema operativo, independientemente del protocolo con el que operan (Ethernet, X.25, Bluetooth, etc.). Estos conceptos son tomados del documento Affix in a Nutshell [31], disponible en el sitio web de Affix [29].

El sistema operativo Linux implementa el socket API estndar de Berkeley, desarrollado para UNIX. La figura 3-4 describe la arquitectura del subsistema de red de Linux, donde sus componentes estndar son: interfaz del Socket Berkeley y la interfaz del driver del dispositivo de red (Network Device Driver Interface).

Figura 3-4. Arquitectura de Red de Linux

La interfaz del socket Berkeley permite a los programas abrir terminales de comunicaciones para dispositivos remotos en el espacio de usuario. El socket es una abstraccin de red para los terminales de un canal y est asociado con el protocolo; usualmente, el PF_INET es usado para asociar un socket con el protocolo TCP/IP.

La interfaz del driver del dispositivo de red permite el uso simultneo de mltiples dispositivos de red, cada uno de los cuales tiene un tipo apropiado para distinguir la clase de dispositivo a la cual pertenece, es decir, Ethernet, PPP, X.25, etc. El driver del dispositivo registra el dispositivo de red en el sistema.

La interfaz del driver de red incluye un paquete encargado de organizar los diferentes tipos de dispositivos (Packet Scheduler), para lo cual implementa una disciplina de colas.

La capa de protocolo corresponde al protocolo que se est implementando. Cada protocolo debe registrarse por si mismo tanto en la interfaz del socket con la familia de protocolo (PF_XXX) apropiada como en la interfaz del driver del dispositivo con el tipo de protocolo apropiado. De esta manera cada paquete recibido ser entregado a la capa de protocolo correspondiente.

Tanto en este diseo como en la mayora de los kernel de Linux la capa de red es orientada a objetos, siendo estos los objetos ms importantes:

Dispositivo o Interfaz: Una interfaz de red es el cdigo programado para enviar y recibir paquetes de datos. Usualmente una interfaz se usa para un dispositivo como es el caso de una tarjeta Ethernet; sin embargo, muchos dispositivos corresponden nicamente a software, como es el caso del dispositivo de realimentacin (loopback) usado para el envo de datos dentro del mismo sistema.

Protocolo: Cada protocolo es un lenguaje diferente de red. En el kernel de Linux cada protocolo corresponde a un mdulo de cdigo aparte el cual brinda servicios a la capa del socket.

Socket: Es un terminal de conexin que suministra un archivo de entrada/salida (I/O) y existe como un archivo descriptor para el programa de usuario. En el kernel cada socket corresponde a un par de estructuras que representan el nivel alto de la interfaz del socket y el nivel bajo de la interfaz de protocolo.

Sk_buff: Todos los buffers usados por las capas de red son sk_buffs. El control de estos buffers es suministrado por las rutinas de bajo nivel del Core de libreras, disponible para todo el sistema de red. Estas primitivas (sk_buffs) brinda los buffers generales y las facilidades de control de flujo que necesitan los protocolos de red.

Para probar el desempeo de las tarjetas Blueboard_UV01 y Blueboard_UV02, en esta tesis se utilizaron como herramientas de software los stacks de protocolos de Affix y Bluez. Por esta razn a continuacin se hace una descripcin ms detallada de estos stacks de protocolos, en cuanto a su instalacin, principales caractersticas y utilidades.

3.4

DESCRIPCIN DEL STACK DE PROTOCOLOS DE AFFIX

El stack de protocolos de Affix fue desarrollado en el Laboratorio de Redes Mviles del Centro de Investigacin de Nokia, bajo licencia GPL, sin ser un producto oficial de Nokia.

La informacin contenida aqu es una recopilacin de los ms importantes apartes del documento Affix in a Nutshell [31], disponible en el sitio web de Affix [29].

Affix soporta los protocolos del Core Bluetooth HCI, L2CAP, RFCOMM, SDP y varios de los perfiles. Adems tiene una implementacin modular, una interfaz socket para los protocolos HCI, L2CAP y RFCOMM, es independiente de la interfaz del mdulo Bluetooth y soporta mltiples dispositivos Bluetooth.

3.4.1 Arquitecturas Soportadas Affix soporta las siguientes arquitecturas: i386 ARM (por ejemplo Compaq iPaq) PowerPC (por ejemplo iMac) Sparc

En general Affix se puede ejecutar en cualquier arquitectura que corra bajo Linux.

3.4.2 Hardware Soportado En principio Affix soporta todos los dispositivos que cumplan con la especificacin Bluetooth. La lista completa del hardware soportado se puede consultar en el sitio de Affix en Internet [29] o en el CD ROM que acompaa este libro.

Affix soporta los siguientes perfiles Bluetooth: Perfil de acceso general Perfil de descubrimiento de servicios Perfil de puerto serial Perfil de acceso conmutado a la red (Red Dial-Up) Perfil de acceso a LAN Perfil OBEX Object Push Perfil OBEX File Transfer Perfil de red de rea personal (PAN)

Affix consta de los siguientes paquetes: Affix Kernel Affix

Adems ofrece herramientas de control, libreras y demonios de servicios.

3.4.3 Arquitectura de Affix La arquitectura general de Affix se puede observar en la Figura 3-5. En general el software de Affix puede ser dividido en dos componentes:

Componente de protocolo, el cual implementa el stack de protocolo.

Componente de Administracin o de Manejo, el cual controla el componente de protocolo y representa la parte inteligente del software.

Figura 3-5. Modelo de la Arquitectura de Affix

La filosofa UNIX (y Linux) es que el kernel debe brindar los mecanismos bsicos y las aplicaciones deben implementar la lgica en el espacio de usuario [32]. Los beneficios de tener ms funcionalidad en el espacio de usuario radican en la facilidad en el proceso de implementacin y mayor estabilidad del sistema ya que en caso de presentarse errores estos se localizan en la aplicacin, en donde es posible usar muchas herramientas de depuracin.

De acuerdo a esta filosofa, el stack de protocolos de Affix corre en el espacio de kernel mientras que la Entidad de Manejo ME (Management Entity) corre en el espacio de usuario. Todo el trfico de paquetes de la red viene a Affix desde el espacio de kernel, de modo que por razones de desempeo, una ptima solucin es implementar aqu el core de protocolos.

La ME complementa la funcionalidad del stack de protocolos Bluetooth, siendo implementada como una aplicacin en el espacio de usuario. Es posible reimplementar la ME sin modificar el cdigo en el espacio de kernel. Un diagrama prctico de los componentes de Affix se muestra en la Figura 3-6.

Figura 3-6. Diagrama de los Componentes de Affix

Si se necesita informacin a cerca de los modelos de seguridad de Affix, el API y el socket de familia PF_AFFIX, esta se encuentra en el CD ROM que acompaa este libro (versin en espaol) o en el sitio de Affix en Internet [29][31].

3.4.4 Utilidades de Affix Affix incluye una utilidad de control (btctl) y un sper servidor (btsrv). Una descripcin completa de los comandos de estas utilidades, se puede encontrar en las pginas del manual, el cual est incluido en los paquetes instalados por Affix [29] o en el CD ROM anexo a este libro (versin en espaol).

3.4.5 Instrucciones de Instalacin Affix se compone de dos paquetes: affix y affix-kernel. affix contiene los archivos fuente para compilar e instalar los programas del modo de usuario y affix-kernel las fuentes para compilar los mdulos del kernel.

Paquete affix-kernel. Los siguientes son los pasos para compilar e instalar affix-kernel:

1. Copiar el archivo affix-kernel-xxx-kernel-xxx.tgz en el directorio /usr/src 2. Desempaquetar el archivo: tar -xzvf affix-kernel-xxx-kernel-xxx.tgz 3. Correr el script de configuracin y contestar las preguntas (s/n) dependiendo de la configuracin deseada: make config 4. Compilar las fuentes: make all

5. Instalar el paquete (requiere privilegios de root): make install 6. Actualizar los alias de protocolo: Esto es requerido para que los mdulos de Affix se carguen automticamente cuando las aplicaciones necesiten soporte de Affix. Si la distribucin de Linux es diferente de Debian, debe adicionarse las siguientes lneas en el archivo /etc/modules.conf:

alias net-pf-27 alias char-major-60

affix affix_rfcomm

Paquete affix Para compilar e instalar el paquete affix se deben seguir los siguientes pasos:

1. Copiar el paquete affix-xxx.tgz en el directorio /usr/src 2. Desempaquetar el archivo: tar xzvf affix-xxx.tgz 3. Correr el script de configuracin: ./configure 4. Compilar el paquete: make 5. Instalar el paquete (requiere privilegios de root): make install

3.5

DESCRIPCIN DEL STACK DE PROTOCOLOS BLUEZ

Bluez es el stack Bluetooth oficial de Linux, el cual brinda soporte para las capas y protocolos del core Bluetooth. La informacin contenida en este tem es una sntesis de los principales apartes del HowTo de Bluez disponible en el sitio oficial de Bluez en Internet [33].

Estas son sus principales caractersticas: Arquitectura flexible, eficiente y modular. Soporta mltiples dispositivos Bluetooth. Procesamiento de datos para multienlaces. Abstraccin del Hardware. Interfaz de socket estndar para todas las capas.

Bluez consta de: Core HCI. drivers HCI para UART, USB y emulador de HCI. Mdulos para el protocolo L2CAP. Utilidades de configuracin y prueba.

Figura 3-7. Diagrama de la Arquitectura de Bluez

La Figura 3-7 es un esquema de la arquitectura de Bluez, que indica las capas implementadas por este software dentro del stack de protocolos Bluetooth. El cdigo fuente de Bluez se puede obtener de la pgina oficial de Bluez en Internet [30]. Requiere para su funcionamiento un Kernel de Linux 2.4.4 o posterior. Si se desea utilizar las ltimas versiones del stack, es necesario deshabilitar del kernel el soporte nativo de Bluetooth. Bluez se puede usar con dispositivos Bluetooth con interfaz Serial o USB, adems brinda un dispositivo HCI virtual (vhci) el cual permite depurar y probar las aplicaciones sin necesidad de tener conectados dispositivos Bluetooth reales.

3.5.1 Compilacin e Instalacin Bluez se compone de los siguientes paquetes: bluez-kernel-X.X.tar.gz bluez-utils-X.X.tar.gz bluez-libs-X.X.tar.gz bluez-SDP-X.X.tar.gz bluez-PAN-X.X.tar.gz.

Los archivos README o INSTALL incluidos dentro de cada paquete contienen toda la informacin sobre los requerimientos e instrucciones para su instalacin. Los procedimientos de compilacin e instalacin son muy parecidos para cada uno de estos paquetes; en general el siguiente procedimiento para instalar el paquete bluez-kernel-X.X.tgz se puede seguir con los dems paquetes, reemplazando el nombre del archivo por el correspondiente:

1. Copiar las fuentes en el directorio /usr/src 2. Desempaquetar el archivo fuente: tar xzvf bluez-kernel-X.X.tar.gz 3. Ubicarse dentro del directorio bluez-kernel-X.X (o el correspondiente a instalar) cd bluez-kernel-X.X 4. Correr el script de configuracin: ./configure 5. Compilar las fuentes: make 6. Instalar las fuentes: make install

Debe escribirse las siguientes lneas de cdigo en el la lnea de comandos de Linux, nicamente despus de instalar el paquete bluez-kernel-X.X, esto con el fin de crear el dispositivo HCI virtual (vhci):

mknod /dev/vhci c 10 250 chmod 664/dev/vhci C=0; While [$C -lt 256]; do if [ ! -c /dev/rfcomm$C ]; then mknod -m 666 /dev/rfcomm$C c 216 $C fi C=`expr $C + 1` done

Para que Bluez trabaje correctamente se deben escribir las siguientes lneas en el archivo /etc/modules.conf:

alias net-pf-31 bluez alias bt-proto-0 l2cap alias bt-proto-2 sco alias bt-proto-3 rfcomm alias bt-proto-4 bnep alias tty-ldisc-15 hci_uart alias char-major-10-250 hci_vhci

Despus de esto se debe correr el comando depmod a para habilitar la carga automtica de los mdulos Bluez. Estos mdulos tambin se pueden cargar manualmente mediante el comando modprobe acompaado de uno de los siguientes mdulos:

bluez

Core Bluetooth.

hci_usb Driver HCI USB. hci_uart Driver HCI UART. hci_vhci Driver para el dispositivo virtual HCI. l2cap sco Mdulo L2CAP. Mdulo SCO (Synchronous Connection Oriented).

rfcomm Mdulo RFCOMM.

Una descripcin completa de los comandos de Bluez est disponible en el sitio oficial de Bluez en Internet [30][33] o en el CD ROM que acompaa este libro (versin en espaol).

4. CONCEPTOS BSICOS PARA LA IMPLEMENTACIN DE UNA RED DE AREA PERSONAL BLUETOOTH

La especificacin Bluetooth define perfiles o esquemas estndar de los escenarios de desarrollo para las aplicaciones Bluetooth, varios de ellos ya se han mencionado en el captulo 1. Uno de estos escenarios corresponde al perfil de red de rea personal o perfil PAN (Personal Area Networking Profile) [34]. El perfil PAN brinda capacidades de red a los dispositivos Bluetooth para lo cual utiliza el Protocolo de Encapsulamiento de Red BNEP (Bluetooth Network Encapsulation Protocol) [35], de gran importancia ya que encapsula los paquetes provenientes de varios protocolos de red (IPv4, IPv6 e IPX entre otros) y los transporta directamente sobre la capa de protocolo L2CAP de Bluetooth, haciendo posible que la red Bluetooth se comporte y forme parte de una red TCP/IP.

4.1 PROTOCOLO DE ENCAPSULAMIENTO DE RED BNEP

El protocolo de encapsulamiento de red de Bluetooth encapsula los paquetes de los protocolos de red ms utilizados, para ser transportados sobre la capa L2CAP. BNEP soporta los mismos protocolos de red soportados por el estndar IEEE 802.3 para ecapsulamiento Ethernet (IPv4, IPv6, IPX entre otros). BNEP requiere adems un formato de encapsulamiento que optimice los bits de cabecera de tal manera que se ofrezca un manejo eficiente del ancho de banda. Los siguientes apartes son tomados de la especificacin del protocolo BNEP publicada por el SIG Bluetooth [35].

4.1.1 Consideraciones 1. Este protocolo est implementado usando canales L2CAP orientados a conexin. 2. Bluetooth se considera un medio de transmisin al mismo nivel OSI de Ethernet, Token Ring, ATM, etc. 3. Se considera a L2CAP como la capa de control de acceso al medio MAC (Media Access Control) de Bluetooth. 4. BNEP especifica una mnima MTU (Unidad mxima de transmisin) para L2CAP de 1691 bytes1. 5. Se deben aplicar a Bluetooth las reglas de conectividad y las topologas de red definidas por el estndar IEEE 802.3 [36][37]. 6. El espacio de direccin Bluetooth BD_ADDR es administrado por IEEE, y es asignado desde el espacio de direccin de Ethernet. De esta manera es posible construir un punto de acceso de red Bluetooth como un puente entre los dispositivos Bluetooth y una red Ethernet.

La Figura 4-1 muestra la ubicacin del BNEP dentro de la torre de protocolos de Bluetooth.

La mnima MTU (Mxima Unidad de Transmisin) de 1691 se seleccion con base en el mximo

paquete de carga til de Ethernet (1500 bytes ms 15 bytes de encabezado de BNEP y otros de extensin). 1691=5*339 (Tamao de un DH5) 4 (Encabezado de L2CAP).

Figura 4-1. Ubicacin del BNEP dentro de la Torre de protocolos de Bluetooth.

4.1.2 Orden de los Bytes y Valores numricos Todos los valores contenidos en este captulo se presentan en notacin hexadecimal. Los campos que contienen mltiples bytes (bits) se muestran con los bytes (bits) ms significativos hacia la izquierda y los menos significativos hacia la derecha. Los bytes de los encabezados de BNEP se disponen en el formato estndar de red Big Endian, en donde los bytes ms significativos se transmiten antes que los menos significativos. El byte 0 es el ms significativo.

4.1.3 Encapsulamiento de Paquetes La Figura 4-2 muestra la manera como BNEP remueve los encabezados de un paquete Ethernet y los reemplaza por un encabezado BNEP. El paquete resultante (Carga til de Ethernet y el encabezado de BNEP) es encapsulado en un paquete L2CAP y enviado sobre Bluetooth.

Figura 4-2. Encapsulamiento de un Paquete Ethernet en un paquete L2CAP

BNEP es usado para transportar sobre Bluetooth tanto paquetes de datos como paquetes de control, de esta manera brinda a los dispositivos Bluetooth capacidades de red similares a las ofrecidas por Ethernet.

4.1.4 Formato de los Encabezados BNEP Todos los encabezados de BNEP siguen el formato que se muestra en la Figura 4-3.

Figura 4-3. Formato de los Encabezados BNEP

Tipo de BNEP Este campo tiene un tamao de siete bits e identifica el tipo de encabezado BNEP que contiene el paquete. Los posibles valores que puede tomar y la descripcin de los mismos se muestra en la Tabla 4-1.

Tabla 4-1. Valores para el campo BNEP Type el cual define el tipo de paquete BNEP

Valor 0x00 0x01 0x02 0x03 0x04 0x05-0x7E 0x7F

Tipo de Paquete BNEP BNEP_GENERAL_ETHERNET BNEP_CONTROL BNEP_COMPRESSED_ETHERNET BNEP_COMPRESSED_ETHERNET_SOURCE_ONLY BNEP_COMPRESSED_ETHERNET_DEST_ONLY Reservado para un futuro uso Reservado para los Paquetes LLC de 802.2 por IEEE 802.15.1 WG

Bandera de Extensin (E) Corresponde a un bit de extensin que indica si existe uno o ms encabezados de extensin entre el encabezado de BNEP y la carga til. Si toma un valor de 0x1, entonces uno o ms encabezados de

extensin se ubican antes de la carga til. Si el valor que tiene es 0x0, la carga til sigue despus del encabezado BNEP.

Paquete BNEP Depende del valor que se haya consignado en el campo del Tipo de BNEP.

4.1.5 Tipo de Paquete BNEP_GENERAL_ETHERNET El paquete general de Ethernet para BNEP se debe usar para transportar paquetes Ethernet desde y hacia redes Bluetooth. Como se puede apreciar en la Figura 4-4 el paquete est conformado por una direccin destino, una direccin origen y el tipo de protocolo de red contenido en la carga til (IPv4, IPv6, etc). Cualquiera de las direcciones ya sea origen o destino puede corresponder a una direccin Ethernet IEEE, si el origen o destino es un dispositivo IEEE y no un dispositivo Bluetooth.

Figura 4-4. Formato del Encabezado para un paquete BNEP_GENERAL_ETHERNET

4.1.6 Tipo de Paquete BNEP_CONTROL El paquete de control de BNEP es utilizado para intercambiar informacin de control. En este tipo de paquete, toda la informacin de control est contenida en el encabezado del BNEP_CONTROL de tal manera que el campo de carga til no contiene informacin alguna. Por el momento hay siete tipos de paquetes de control BNEP. El tipo de paquete de control es definido por el valor que se consigne en el campo tipo de control de BNEP; no se entra en detalle sobre cada tipo de paquete de control ya que esto no est dentro de los alcances de la Tesis. La Figura 4-5 muestra el formato para el encabezado de un paquete BNEP_CONTROL.

Figura 4-5. Formato del Encabezado para un paquete BNEP_CONTROL

4.1.7 Tipo de Paquete BNEP_COMPRESSED_ETHERNET El paquete Ethernet comprimido de BNEP se usa para transportar paquetes Ethernet hacia o desde dispositivos que tienen una conexin directa al nivel de la capa L2CAP usando BNEP. Debido a la existencia de una conexin L2CAP entre lo dos dispositivos Bluetooth no es necesario incluir dentro del paquete las direcciones de origen y destino. Se debe anotar que las direcciones de multicast o broadcast no deben ser comprimidas. La Figura 4-6 muestra el formato de un paquete BNEP_COMPRESSED_ETHERNET.

Figura 4-6. Formato del encabezado para un paquete BNEP_COMPRESSED_ETHERNET

4.1.8 Tipo de Paquete BNEP_COMPRESSED_ETHERNET_SOURCE_ONLY Este paquete Ethernet comprimido se usa para transportar paquetes Ethernet hacia un dispositivo el cual siempre ser el destino final para todos los paquetes. Por esta razn los dispositivos no necesitan incluir la direccin destino en los paquetes siendo esta la misma direccin correspondiente al canal L2CAP sobre el cual se envan los paquetes. Se debe anotar que las direcciones de multicast o broadcast no deben ser comprimidas.

Figura 4-7. Formato del encabezado para un paquete BNEP_COMPRESSED_ETHERNET_SOURCE_ONLY

4.1.9 Tipo de Paquete BNEP_COMPRESSED_ETHERNET_DEST_ONLY Este paquete comprimido Ethernet es usado para transportar paquetes desde un dispositivo el cual es la fuente del paquete. De esta manera los dispositivos no necesitan incluir la direccin de la fuente del paquete ya que esta fuente puede determinarse a partir de la conexin L2CAP.

Figura 4-8. Formato del encabezado para un paquete BNEP_COMPRESSED_ETHERNET_DEST_ONLY

El siguiente es un ejemplo en el cual un paquete IP es enviado usando BNEP. Un paquete IPv4 es enviado desde un dispositivo con una direccin IEEE de 48 bits (00:AA:00:55:44:33) hacia un dispositivo con una direccin Bluetooth

(00:30:B7:45:67:89). En este caso el paquete BNEP utilizado es del tipo BNEP_GENERAL_ETHERNET como se ilustra en la Figura 4-9.

Figura 4-9. Ejemplo del envo de un paquete IPv4 usando BNEP entre un dispositivo con direccin IEEE y otro con direccin Bluetooth

4.2 Piconet y scatternet Dos o ms dispositivos Bluetooth que comparten el mismo canal de conexin conforman una piconet. Esta se establece a travs de enlaces punto-multipunto, en donde uno de los dispositivos cumple el rol de maestro mientras los dems actan como esclavos. Una piconet puede tener un mximo de siete esclavos activos. Las Figuras 4-10 y 4-11 ilustran respectivamente el esquema y un ejemplo de una piconet.

Figura 4-10. Esquema de una Piconet

Figura 4-11. Ejemplo de una Piconet

En una piconet los enlaces se establecen sobre todas las capas de protocolo Bluetooth desde banda base hasta L2CAP. BNEP utiliza estos enlaces L2CAP para encapsular los protocolos de red de capas superiores de tal manera que el medio de transporte (Bluetooth) es transparente para las aplicaciones. El perfil

PAN describe los mecanismos mediante los cuales se brindan propiedades de red a los dispositivos Bluetooth que forman parte de una piconet.

Mltiples piconets en donde sus rangos de cobertura se traslapan conforman una scatternet. Cada piconet debe tener un nico maestro, sin embargo, los esclavos pueden participar en diferentes piconets. Adems un maestro de una piconet puede ser esclavo en otra. Las Figuras 4-12 y 4-13 ilustran respectivamente el esquema y un ejemplo de una scatternet.

Figura 4-12. Esquema de una Scatternet

Figura 4-13. Ejemplo de una Scatternet

4.3 PERFIL DE RED DE AREA PERSONAL (PAN PROFILE)

El perfil PAN (Personal Area Networking Profile) describe como usar el protocolo BNEP para brindar capacidades de red a los dispositivos Bluetooth. Estos apartes son tomados del documento Personal Area Networking Profile publicado por el SIG. Bluetooth [34]. El perfil PAN presenta los siguientes requerimientos funcionales:

Define una red IP ad-hoc, dinmica y personal Debe ser independiente del sistema operativo, lenguaje y dispositivo Brinda soporte para los protocolos de red ms comunes como IPv4 e IPv6. Brinda soporte para puntos de acceso en donde la red puede ser una LAN corporativa, GSM u otro tipo de red de datos.

Debe acomodarse a los recursos reducidos disponibles en los dispositivos pequeos respecto a memoria, capacidad de procesamiento y uso de interfaces.

4.3.1 Consideraciones El perfil PAN debe soportar IPv4 e IPv6. Los otros protocolos pueden estar o no habilitados. En una red generalizada, la trayectoria del trfico originado desde un dispositivo hacia otro puede estar conformada por uno o varios medios de transporte, por ejemplo, Bluetooth, Ethernet, Token Ring, PSTN, ISDN, ATM, GSM, etc.

Son tres escenarios propuestos para el perfil PAN: Puntos de acceso a una red (Network access points), Grupo de red Ad-hoc (Group Ad-hoc Networks) y PANU-PANU (PAN USER). Cada uno de estos escenarios define el rol y el servicio que deben asumir los dispositivos involucrados en una de estas arquitecturas.

4.3.2 Puntos de Acceso a una red (NAP) Un punto de acceso a una red (NAP) corresponde a una unidad que contiene uno o ms dispositivos Bluetooth y acta como puente, proxy o enrutador, entre una red Bluetooth y otro tipo de tecnologa de red (Ethernet, GSM, ISDN, Home PNA, Cable Mdem y Celular). La Figura 4-14 ilustra la arquitectura para dos puntos de acceso a red.

Figura 4-14. Dos Puntos de Acceso a Red

Para la Fase I del perfil PAN, el dispositivo que soporta el servicio NAP (Network Access Point) debe cumplir con las caractersticas de un Puente Ethernet para soportar de esta manera los servicios de red. El dispositivo NAP distribuye los paquetes Ethernet entre los dispositivos Bluetooth conectados o PAN Users (PANU). Los NAP pueden requerir caractersticas adicionales en los casos en que el puente sea hacia otro tipo de redes, por ejemplo GPRS. La Figura 4-15 muestra la interaccin de las capas de protocolo del modelo Bluetooth para el rol NAP.

Figura 4-15. Stack para el rol NAP

4.3.3 Grupo de Red Ad-hoc La versin 1.0 del Perfil PAN [34], especifica el escenario para una red personal ad-hoc el cual consiste en una simple piconet con conexiones entre dos o ms dispositivos Bluetooth. Un maestro y un mximo de siete esclavos conforman esta red. El lmite de siete esclavos se debe al esquema activo de direccionamiento de Bluetooth [3]. La Figura 4-16 es un esquema para una red Ad-hoc.

Figura 4-16. Esquema para un Grupo de Red Ad-hoc (GN)

Un grupo de red ad-hoc se establece para que un conjunto de dispositivos conforme una red temporal e intercambien informacin. El dispositivo cuyo rol es GN (Group Ad-hoc Network) soporta el servicio GN. La Figura 4-17 ilustra a nivel de las capas de protocolo un enlace entre un GN y un PANU.

Figura 4-17. Stack para un enlace en una red Ad-hoc Bluetooth

4.3.4 PANU PANU En este escenario se establece una conexin punto a punto entre dos usuarios de PAN (PANU), permitindose as una comunicacin directa entre ellos. El PANU es el dispositivo Bluetooth que usa los servicios NAP o GN. El PANU asume el rol de cliente de los roles NAP o GN.

5. PRUEBAS DE DESEMPEO Y APLICACIN PARA LAS TARJETAS BLUEBOARD_UV01 Y BLUEBOARD_UV02

Como

se

explic

en

el

segundo

captulo

de

este

libro,

las

tarjetas

BlueBoard_UV01 y BlueBoard_UV02 tienen diseos muy similares. Estos dos diseos difieren en el tipo de antena que utilizan, Rangestar 100929 para la BlueBoard_UV01 y Rangestar 100930 para la BlueBoard_UV02.

Por otro lado las tarjetas poseen interfaces HCI para USB y RS232. Adems se cuenta con los mdulos Bluetooth ROK 101 007/21E y ROK 101 008 de Ericsson, removibles e intercambiables gracias al carrier socket BT001A-30G2T de Suyin que posee cada tarjeta. Todo esto sumado con las herramientas de prueba y utilidades que brindan los stack de protocolo BlueZ y Affix, crea una potente plataforma de pruebas tanto para el hardware (antenas Rangestar y mdulos Bluetooth de Ericsson) como para aplicaciones Bluetooth.

El plan de pruebas se divide en dos grupos: el primero lo conforman las pruebas de desempeo del hardware Bluetooth que permite definir las caractersticas de operacin de las tarjetas, y el segundo una serie de pruebas para implementar una Red de Area Personal (PAN), principal objetivo de esta tesis.

5.1 PRUEBAS DE DESEMPEO

Estas pruebas muestran el desempeo de las tarjetas BlueBoard_UV01 y BlueBoard_UV02, midiendo la rata de transferencia de bits para distintas distancias y bajo diferentes condiciones. Para esto se utiliz dos nodos (N1 y N2), cada uno equipado con una tarjeta Bluetooth conectada a un PC a travs de una interfaz USB.

5.1.1 Configuracin para las Pruebas Hardware Cada nodo (N1 y N2) corresponde a un PC DELL Pentium III, el cual tiene conectada una tarjeta Bluetooth BlueBoard_UV02 a travs del puerto USB. Mdulos Bluetooth ROK 101 007/21E de Ericsson.

Software Cada PC tiene un sistema operativo Linux RedHat 7.0 e instalados todos los paquetes de Bluez (core, libreras y utilidades). Direccin Bluetooth de N1: 00:80:37:15:C9:64 Direccin Bluetooth de N2: 00:80:37:15:C9:67 N1 es el nodo Fijo y N2 es el nodo mvil.

5.1.2 Descripcin de las Pruebas Para estas pruebas de desempeo, N1 enva paquetes de bits que son recibidos por N2. El nodo N2 tiene el rol de servidor y escucha constantemente en espera de paquetes de datos de tamao mnimo (MTU) negociado con el nodo cliente N1, gracias a la utilidad de Bluez l2test [33]. l2test es una herramienta de pruebas para L2CAP, la cual calcula y despliega en el servidor (N2) la velocidad (kb/s) a la que los datos se transmiten sobre una conexin L2CAP. Se puede conseguir ms

informacin de la utilidad l2test en el HowTo de Bluez [33] o en el CD-ROM anexo a este libro (versin en espaol). La arquitectura utilizada para las pruebas de desempeo se muestra en la Figura 5-1.

Figura 5-1. Arquitectura utilizada en las pruebas de desempeo

Con una distancia inicial de 0 m y desplazando el nodo mvil N2 en intervalos de 1 m, se registr para cada intervalo la rata de bytes calculada por l2test para los paquetes enviados desde N1. Para cada intervalo de distancia se tomaron aproximadamente 17 registros para paquetes de 100128 bytes. Para distancias de 6 m en adelante, los paquetes de bytes enviados desde N1 en algunos casos se redujeron a 20160 bytes y 50400 bytes, para agilizar la captura de los datos.

En la Figura 5-1 la pared representa dos obstculos, una pared de madera que coloca a los nodos en cubculos separados simulando un ambiente de oficina y dos cajas plsticas (una por nodo) en las que se introducen las tarjetas para de esta manera simular la atenuacin provocada por la cobertura plstica propia de los dispositivos mviles (telfonos celulares, palm, computadoras porttiles, etc.).

De esta manera se tomaron datos para cuatro escenarios de prueba distintos:

Lnea de vista entre los nodos (LV) Pared de madera entre los nodos (M) Pared de madera entre los nodos y cada tarjeta dentro de una caja plstica (MP) Lnea de vista entre los nodos y cada tarjeta dentro de una caja plstica (LVP)

Se debe correr l2test primero en el servidor N2 y despus en el cliente N1 de la siguiente manera:

N2 (Servidor) [root@localhost /root]# l2test -I 2000 -r l2test[1358]: Waiting for connection on psm 10 ... De esta manera el servidor N2 espera una conexin L2CAP proveniente desde el cliente N1 con una MTU entrante de 2000 bytes.

N1 (Cliente) [root@localhost /root]# l2test -O 2000 -s -b 100000 00:80:37:15:C9:67 El cliente N1 establece una conexin L2CAP con el servidor N2 y le enva paquetes de 100000 bytes, valor aproximado por l2test a 100128 bytes. Este nmero vara dependiendo de la cantidad de bytes del paquete que se desea enviar.

En el servidor N2, los datos recibidos se muestran as:

[root@localhost /root]# l2test -I 2000 -r l2test[1358]: Waiting for connection on psm 10 ... l2test[1359]: Connect from 00:80:37:15:C9:64 [imtu 2000, omtu 672, flush_to 65535] l2test[1359]: Receiving ... l2test[1359]: 100128 bytes in 2.35 sec, 41.52 kb/s l2test[1359]: 100128 bytes in 2.36 sec, 41.44 kb/s l2test[1359]: 100128 bytes in 2.36 sec, 41.44 kb/s l2test[1359]: 100128 bytes in 2.36 sec, 41.41 kb/s l2test[1359]: 100128 bytes in 2.36 sec, 41.36 kb/s l2test[1359]: 100128 bytes in 2.33 sec, 41.89 kb/s l2test[1359]: 100128 bytes in 2.36 sec, 41.44 kb/s l2test[1359]: 100128 bytes in 2.36 sec, 41.44 kb/s l2test[1359]: 100128 bytes in 2.37 sec, 41.28 kb/s l2test[1359]: 100128 bytes in 2.37 sec, 41.30 kb/s l2test[1359]: 100128 bytes in 2.37 sec, 41.34 kb/s l2test[1359]: 100128 bytes in 2.34 sec, 41.87 kb/s l2test[1359]: 100128 bytes in 2.36 sec, 41.39 kb/s l2test[1359]: 100128 bytes in 2.36 sec, 41.36 kb/s l2test[1359]: 100128 bytes in 2.37 sec, 41.22 kb/s l2test[1359]: 100128 bytes in 2.36 sec, 41.51 kb/s l2test[1359]: 100128 bytes in 2.36 sec, 41.45 kb/s

Estos datos se copian en un editor de texto y despus se procesan en una hoja de clculo. Para cada intervalo de distancia y variante, se registr y tabul los datos ofrecidos por l2test, y se calcul la rata de bits promedio, desviacin estndar, mediana, moda, varianza y porcentaje de variacin.

5.1.3 Dependencias entre la velocidad de transmisin, los obstculos y la distancia entre los nodos La rata de bits promedio es utilizada para dar un estimativo de la dependencia de la velocidad de transmisin respecto a la distancia para cada una de las variantes ya mencionadas. Estos datos se consignan en las tablas 5-1, 5-2, 5-3 y 5-4.

Tabla 5-1. Rata de Bits promedio con LV Lnea de Vista entre los Nodos Distancia (m) 0 1 2 4 6 8 10 12 Rata de Bits Promedio (kbps) 331.605 331.153 330.536 331.101 328.894 243.835 115.083 37.169

Tabla 5-2. Rata de Bits promedio con M Pared de Madera entre los Nodos Distancia (m) Rata de Bits Promedio (kbps) 0 2 4 6 8 331.534 330.776 283.576 251.813 103.245

Tabla 5-3 Rata de Bits promedio con MP Pared de Madera entre los Nodos y Cada Tarjeta dentro de una Caja Plstica Distancia (m) Rata de Bits Promedio (kbps) 0 2 4 6 7 331.200 331.176 265.365 250.480 111.856

Tabla 5-4. Rata de Bits promedio con LVP Lnea de Vista entre los Nodos y Cada Tarjeta dentro de una Caja Plstica Distancia (m) Rata de Bits Promedio (kbps) 0 1 2 4 6 8 10 330.946 315.741 331.468 330.998 331.026 245.049 25.110

La figura 5-2 muestra, para cada una de las variantes ya mencionadas, la manera como evoluciona la velocidad de transmisin, representada por la rata de bits promedio, con respecto a la distancia.

Figura 5-2. Rata de Bits Promedio Vs. Distancia

Rata de Bits Promedio Vs. Distancia

350
Lnea de Vista entre los Nodos Pared de Madera entre los Nodos Pared de Madera entre los Nodos y Tarjetas en caja Plstica Lnea de Vista entre los Nodos yTarjetas en Caja Plstica

Rata de Bits (Kbps)

300 250 200 150 100 50 0 0 1 2 3 4 5 6 7 8 9 10 11 12

Distancia (m)

La Figura 5-2 brinda valiosa informacin sobre el desempeo de las tarjetas BlueBoard_UV01 y BlueBoard_UV02, respecto a tres puntos claves:

La atenuacin de la seal de radio debido a los obstculos La atenuacin de la seal de radio debido a la distancia La conjuncin de las dos anteriores

La atenuacin en la seal de radio se refleja en la disminucin de la rata de bits promedio.

Atenuacin de la seal de radio debido a los obstculos. Esta se puede observar al comparar la rata de bits para cada variante de obstculos a la

misma distancia entre los nodos. Analizando lo mencionado, se puede concluir lo siguiente: La atenuacin de la seal de radio es igual, con o sin obstculos (madera o plstico), hasta una distancia entre los nodos de 2 m, con una rata de bits promedio de 329.3 kbps. La mayor atenuacin se presenta cuando hay una Pared de Madera entre los nodos y las tarjetas estn dentro de una caja Plstica La menor atenuacin se da cuando hay lnea de vista entre los nodos Es mayor la atenuacin causada por la pared de madera que la debida a las cajas plsticas.

Atenuacin de la seal de radio debido a la distancia Mayor atenuacin: A mayor distancia mayor atenuacin, especialmente visible despus de 6m. Distancia Mxima de Transmisin: 12 m, con lnea de vista entre los nodos a 37.169 kbps. Rata de Bits mxima: 331.6 kp/s a una distancia de 0 m (2 cm aprox.) y con lnea de vista entre los nodos

Atenuacin de la seal de radio debido a los obstculos y la distancia A partir de una distancia entre los nodos de 6 m, aumenta considerablemente la rata a la que disminuye la velocidad de transmisin. Para cada una de las variantes de obstculos, esta disminucin en la rata de bits presenta una tendencia lineal con pendiente negativa, de esta manera:

LV: M:

-50.196 kbps/m -74.284 kbps/m

LVP: MP:

-76.479 kbps/m -128.62 kbps/m

Es as como para LV se tiene la menor pendiente, ya que la rata de bits disminuye 50.196 kbps por cada metro que se aleja el nodo mvil N2, en cambio para MP se tiene la mayor pendiente, ya que la rata de bits cae 128.62 kbps por cada metro que se aleja N2.

Para calcular los rangos de distancia en los que el rendimiento de las tarjetas es ptimo, se hace analoga con la teora de filtros, en donde la frecuencia de corte (Fc) es la frecuencia a la cual la potencia corresponde al 70.7% de la mxima potencia. Ya que nuestro canal (aire con obstculos) se comporta como un filtro, se estima que el rango de distancia entre nodos para un ptimo desempeo de la tarjeta (Do) es la distancia en la que la rata de bits (Rb) corresponde al 70.7% de la mxima rata de bits. De esta manera cada variante de obstculos tendr su correspondiente Do, como se muestra a continuacin: Do 8.5 m Do 8.5 m Do 6.5 m Do 6.5 m

LV:

Rb = 234.44 kbps

LVP: Rb = 233.98 kbps M: MP: Rb = 234.39 kbps Rb = 234.15 kbps

Se puede concluir entonces que para LV y M, los rangos de distancia entre los nodos para un ptimo desempeo (Do) son 8.5 m y 6.5 m respectivamente, adems, no dependen de la cobertura plstica que en un eventual caso puedan presentar las tarjetas BlueBoard_UV01 y BlueBoard_UV02. Los efectos de atenuacin de la seal de radio se hacen notables para distancias superiores al rango de distancia entre los nodos para un ptimo desempeo (Do).

5.1.4 Estabilidad de la velocidad de transmisin respecto a la distancia y los obstculos entre los nodos Es interesante tambin analizar para cada una de las variantes de obstculos, la estabilidad en la velocidad de transmisin a medida que aumenta la distancia. Para este fin se utiliz el porcentaje de variacin ya que este es una medida relativa de la dispersin de los datos para cada distancia respecto a la rata de bits promedio correspondiente. Las tablas 5-5, 5-6, 5-7 y 5-8, muestran los porcentajes de variacin para cada distancia y variante de obstculos.

Tabla 5-5. Porcentaje de Variacin del Promedio de la rata de Bits con LV Lnea de Vista entre los Nodos Distancia (m) Porcentaje de Variacin (%) 0 1 2 4 6 8 10 12 0.43 0.62 0.60 0.50 0.77 1.88 7.90 14.36

Tabla 5-6. Porcentaje de Variacin del Promedio de la rata de Bits con M Pared de Madera entre los Nodos Distancia (m) Porcentaje de Variacin (%) 0 2 4 6 0.47 0.77 2.36 11.42

Tabla 5-7. Porcentaje de Variacin del Promedio de la rata de Bits con MP Pared de Madera entre los Nodos Cada Tarjeta dentro de una Caja Plstica Distancia (m) Porcentaje de Variacin (%) 0 2 4 6 7 0.62 0.52 2.51 4.12 8.79

Tabla 5-8. Porcentaje de Variacin del Promedio de la rata de Bits con LVP Lnea de Vista entre los Nodos Cada Tarjeta dentro de una Caja Plstica Distancia (m) Porcentaje de Variacin (%) 0 1 2 4 6 8 10 0.58 1.70 0.44 0.58 0.55 6.27 21.56

La Figura 5-3 muestra para cada una de las variantes de obstculos mencionadas (LV, M, MP, LVP) el porcentaje de variacin de la rata de bits en funcin de la distancia entre los nodos.

Figura 5-3. Porcentaje de variacin de la rata de Bits Vs. Distancia

Porcentaje de Variacin de la rata de Bits Vs. Distancia

25
Lnea de Vista entre los Nodos

Porcentaje de Variacin (%)

20
Pared de Madera entre los Nodos

15
Pared de Madera entre los Nodos y Tarjetas en caja Plstica Lnea de Vista entre los Nodos yTarjetas en Caja Plstica

10

0 0 1 2 3 4 5 6 7 8 9 10 11 12

Distancia (m)

El porcentaje de variacin brinda una buena estimacin de qu tan dispersa est la velocidad de los paquetes de datos enviados para una distancia y obstculos fijos respecto a la velocidad promedio calculada para cada caso. El anlisis de la Figura 5-3 se enfoca en los siguientes puntos:

La dispersin de la rata de bits debido a los obstculos La dispersin de la rata de bits debido a la distancia entre los nodos La conjuncin de las dos anteriores

Dispersin de la rata de bits debido a los obstculos La dispersin de la rata de bits hasta los 2 m de distancia entre los nodos es la misma sin importar la presencia de obstculos, con un porcentaje de variacin promedio de 0.7 %.

La mayor dispersin se presenta cuando entre los nodos hay una pared de madera que los ubica en cubculos separados La menor dispersin se da cuando hay lnea de vista entre los nodos Es mayor la dispersin causada por la pared de madera que la debida a las cajas plsticas

Dispersin de la rata de bits debido a la distancia entre los nodos Mayor dispersin registrada: 21.56 % a una distancia de 10 m, con lnea de vista entre los nodos y las tarjetas dentro de una caja plstica Menor dispersin registrada: 0.43 % a una distancia de 0 m, con lnea de vista entre los nodos

Dispersin de la rata de bits debido a los obstculos y a la distancia Para cada variante de obstculos, despus de cierta distancia, el porcentaje de variacin de la rata de bits aumenta linealmente con una pendiente distinta para cada caso de la siguiente manera: LV: a partir de los 8 m aumenta con una pendiente de 3.12 % / m M: a partir de los 4 m aumenta con una pendiente de 4.65 % / m MP: a partir de los 6 m aumenta con una pendiente de 4.68 % / m LVP: a partir de los 8 m aumenta con una pendiente de 7.65 % / m

De esta manera LV tiene la menor pendiente ya que el porcentaje de variacin aumenta 3.12 % por cada metro que se aleja el nodo mvil N2 despus de los 8 m; a partir de esta distancia la mayor pendiente se presenta para LVP, ya que el porcentaje de variacin de la rata de bits aumenta 7.65 % por cada metro que se aleja N2. Cabe anotar que para M y MP el aumento considerable en la dispersin de la rata de bits se da a distancias menores (4 m y 6 m respectivamente) que las registradas para LV y LVP.

Para los rangos de distancia entre nodos para un ptimo desempeo (Do) calculados en el tem 5.1.1, se encuentra el promedio del porcentaje de variacin para cada escenario de prueba (ver Tabla 5-9).

La Tabla 5-9 muestra para cada rango de distancia Do, el porcentaje de variacin promedio de la rata de bits.

Tabla 5-9. Porcentaje de Variacin Promedio para cada Do

Porcentaje de Variacin Variante de Obstculos Do (m) Promedio (%) Rata de bits promedio (kbps) para Do

LV LVP M MP

8.5 8.5 6.5 6.5

0.8 1.69 3.76 1.94

316.2 314.2 299.4 294.6

5.2 IMPLEMENTACIN DE UNA RED DE AREA PERSONAL BLUETOOTH

El objetivo final de esta tesis es la implementacin de una red de rea personal Bluetooth. Esta implementacin recopila todos los conceptos que se han tratado a lo largo de este documento, siendo una excelente aplicacin demostrativa que nos muestra los alcances y proyecciones de esta tecnologa. El perfil de red de rea personal de Bluetooth (PAN Profile) para esta demostracin es el de Grupo de red Ad-hoc o GN (Group Ad-hoc Networks). La PAN consta de tres nodos (GN,

PANU1 y PANU2), cada uno conformado por una tarjeta Blueboard_UV conectada a un PC a travs de una interfaz USB. La arquitectura de la red de rea personal implementada, se puede observar en la Figura 5-4.

Figura 5-4. Arquitectura de la red de rea personal

5.2.1 Configuracin de la PAN

Hardware GN y PANU2: cada uno corresponde a un PC DELL Pentium III con una tarjeta BlueBoard_UV02 conectada a travs del puerto USB. PANU1: corresponde a un PC Genrico Pentium II, el cual tiene conectada una tarjeta BlueBoard_UV01 a travs del puerto USB.

Cada tarjeta est equipada con un mdulo Bluetooth Ericsson ROK101007/21E.

Software GN: sistema operativo Linux RedHat 7.0, Kernel 2.4.18 habilitadas las opciones network filter, iptable, NAT, 802.1d ethernet bridge, e

instalados los paquetes de Affix y el paquete bridge-utils-0.9.6 (paquete de utilidades para bridge). Este nodo se configura como un servidor de Telnet. PANU1: sistema operativo Linux RedHat 8.0, Kernel 2.4.18, instalados los paquetes de Affix y cliente Telnet. PANU2: sistema operativo Linux RedHat 7.0, Kernel 2.4.19, instalados los paquetes de Affix y el cliente telnet. Direccin Bluetooth de GN: 00:80:37:15:C9:67 Direccin Bluetooth de PANU1: 00:80:37:15:C9:64 Direccin Bluetooth de PANU2: 00:80:37:15:C9:66 Direccin IP de GN: 10.0.0.1 Direccin IP de PANU1: 10.0.0.2 Direccin IP de PANU2: 10.0.0.3

5.2.2 Ethernet Bridging Un bridge, es un puente que sirve para unir dos o ms interfaces de red (tarjetas de red - NICs) para que el trfico fluya entre ellas de manera libre y en forma transparente. De esta manera se puede conectar un PC a la LAN como si este fuera un hub o un switch. Los PCs detrs del bridge no lo vern y el trfico fluir en forma transparente [38]. Affix y Bluez utilizan el 802.1d ethernet bridge y el paquete de utilidades bridge-utils-0.9.6 disponible en Internet [39], nicamente

para combinar, en una sola interfaz,

interfaces de red separadas. Se puede

encontrar fcilmente en Internet tutoriales, guas de Instalacin y configuracin del bridge, tanto en ingls [40] como en espaol [38].

Los pasos que se muestran a continuacin, para la configuracin de una red de rea personal basada en Affix, siguen un modelo tomado del documento DEMONSTRATE THE PAN IN LINUX SYSTEM [40], siendo adaptados a los recursos disponibles en este proyecto. Para cada uno de los casos, los mdulos de Affix deben estar correctamente cargados.

5.2.3 Nodo maestro GN Se define el bridge con el nombre br0 (puede tener cualquier nombre no necesariamente este): [root@localhost.localdomain]# brctl addbr br0 [root@localhost.localdomain]# ifconfig br0 10.0.0.1

Se deshabilita las caractersticas inteligentes del

802.1d ethernet bridge:

protocolo STP (spanning tree protocol) y los estados de aprendizaje y atencin. Como resultado el puente se activar instantneamente despus de que la interfaz pan0 de Affix haya sido creada. Si no se hacen estas llamadas el establecimiento puede tomar unos 30 s, dependiendo de la complejidad de la red [42]:

[root@localhost.localdomain]# brctl setfd br0 0 [root@localhost.localdomain]# brctl stp br0 disable

Se crea la interfaz pan0 de Affix

[root@localhost.localdomain]# btctl paninit gn bt0

Se aade pan0 al bridge y se configura su direccin IP en 0.0.0.0 para que sea transparente [root@localhost.localdomain]# brctl addif br0 pan0 [root@localhost.localdomain]# ifconfig pan0 0.0.0.0

Para revisar el estado actual del bridge, se escribe: [root@localhost.localdomain]# brctl show

Para mirar una lista de las conexiones remitidas sobre el bridge, se escribe: [root@localhost.localdomain]# brctl showmacs

5.2.4 Nodos esclavos PANU1 y PANU2 La configuracin de estos nodos difiere nicamente de la direccin IP asignada a cada uno. Se ha de seguir el mismo procedimiento para cada caso con las direcciones IP correspondientes: Se crea la interfaz pan0 de Affix [root@localhost.localdomain]# btctl paninit panu bt0

Se configura la direccin IP para cada interfaz de Affix En PANU1: [root@localhost.localdomain]# ifconfig pan0 10.0.0.2 En PANU2: [root@localhost.localdomain]# ifconfig pan0 10.0.0.3

Para revisar la correcta configuracin de las interfaces de red, se escribe: [root@localhost.localdomain]# ifconfig

Ahora es necesario definir la ruta por defecto para la interfaz de Affix creada: [root@localhost.localdomain]# route add default gw 10.0.0.1

Se debe verificar el estado de la tabla de enrutamiento escribiendo: [root@localhost.localdomain]# route

En este punto se tiene ya establecida una red de tres nodos, TCP/IP sobre Bluetooth. Desde el Nodo maestro GN, se escribe en la lnea de comandos: [root@localhost.localdomain]# ping 10.0.0.2 PING 10.0.0.2 (10.0.0.2) from 10.0.0.1 : 56(84) bytes of data. 64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=143 ms 64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=74.2 ms

[root@localhost.localdomain]# ping 10.0.0.3 PING 10.0.0.3 (10.0.0.2) from 10.0.0.1 : 56(84) bytes of data. 64 bytes from 10.0.0.3: icmp_seq=1 ttl=64 time=144 ms 64 bytes from 10.0.0.3: icmp_seq=2 ttl=64 time=75.2 ms

Esto permite probar la existencia de la red TCP/IP, donde Bluetooth es transparente. En teora cualquier servicio IP disponible en la red (telnet, ftp, servicios web, etc.) debera accederse desde otro nodo de la misma red.

5.3 Software bluetooth para sistemas embebidos Esta seccin hace referencia al proyecto BTnode rev 2.2 [43], conjuntamente desarrollado por el laboratorio de redes e Ingeniera de la computacin TIK [44] y el Grupo de investigacin para sistemas distribuidos [45] pertenecientes al Instituto

federal Suizo de tecnologa con sede en Zurich [46]. Este proyecto puede ser de gran ayuda para futuras tesis interesadas en el desarrollo de sistemas autnomos inalmbricos y plataformas embebidas basadas en microcontrolador y que utilicen interfaz Bluetooth.

BTnode tiene las siguientes caractersticas:

Microcontrolador: Atmel Atmega 128 L Memoria: RAM de 64 kbyte, Flash ROM de 128 kbyte y 4 kbyte de EEPROM. Mdulo Bluetooth ROK 101 007 de Ericsson

El sitio en Internet de este proyecto [43] ofrece documentacin completa sobre el diseo del Hardware, herramientas de desarrollo para software (versiones para linux y windows), cdigo fuente y archivos binarios del stack embebido para el sistema BTnode y entre otras cosas una lista de correos para los interesados y colaboradores de este proyecto.

CONCLUSIONES

En este proyecto se ha implementado satisfactoriamente una red inalmbrica Bluetooth de tres nodos, dentro de un rango de 10 m y utilizando las tarjetas BlueBoard_UV desarrolladas. La comunicacin se hizo usando tres PCs mediante el uso de los stack Bluez y Affix, los cuales ofrecen herramientas que permitieron realizar y verificar diferentes conceptos de esta tecnologa inalmbrica.

Se estudi detalladamente la versin 1.0b de la especificacin Bluetooth, as como los stack de protocolos Affix y Bluez. Los conceptos de Bluetooth adquiridos fueron esenciales para el desarrollo de este proyecto y se aplicaron especficamente en la implementacin de la red inalmbrica Bluetooth, principal objetivo planteado.

Se ha podido investigar y analizar ampliamente el mercado de circuitos integrados y sistemas embebidos Bluetooth encontrndose que la cantidad y diversidad de productos disponibles en el mercado son muy amplias, al igual que el nmero de fabricantes que los ofrecen. La Informacin detallada al respecto se puede encontrar en el CD-ROM adjunto.

A lo largo del proyecto, se han podido corroborar las principales ventajas de la tecnologa Bluetooth tales como tamao reducido y bajo consumo de potencia. No se puede afirmar lo mismo acerca del bajo costo, ya que realmente no es aplicable en este momento en Colombia debido a que la mayor parte de los dispositivos

requeridos para el desarrollo o compra de sistemas Bluetooth no est disponible en nuestro pas, incrementando los costos. A la fecha (Agosto/2003), la circuitera necesaria para la implementacin de una tarjeta BlueBoard_UV es de aproximadamente US $200.

Las arquitecturas utilizadas por Affix y Bluez para implementar las capas superiores del stack de protocolos Bluetooth son muy similares y se basan en conceptos del subsistema de red de linux (como el de socket Berkeley entre otros), usados por los drivers de los dispositivos de red independientemente del protocolo que utilicen (Ethernet, X.25, etc).

Para lograr que una red de dispositivos Bluetooth interacte con otras tecnologas como Ethernet, Token Ring, ATM, etc., y adems brinde y utilice los servicios TCP/IP que estn disponibles en la red, existen el protocolo de encapsulamiento de red BNEP de Bluetooth y el perfil PAN. Para lograr esto, Affix y Bluez, se valen del estndar IEEE 802.1d ethernet bridge, implementado por Linux y utilizado para unificar en el nodo maestro las interfaces de red de Bluetooth en una sola interfaz la cual a su vez puede servir de puente hacia una interfaz ethernet, de tal manera que la red Bluetooth y esta ltima conformen una red TCP/IP transparente a la tecnologa de transporte de datos.

Las pruebas de desempeo de las tarjetas BlueBoard_UV, realizadas en este trabajo, revelaron valiosos datos de operacin de los sistemas Bluetooth. Los valores mximos de distancia y velocidad de transmisin y los rangos de distancia entre nodos para un ptimo desempeo (Do) tabulados y calculados como parte de este anlisis, demuestran el buen funcionamiento de las tarjetas BlueBoard_UV en ambientes ideales (en los que existe lnea de vista entre nodos) y en ambientes

reales (tales como oficinas, plantas de produccin y el hogar en los que las condiciones de operacin no permiten esta lnea de vista). La cobertura plstica propia de equipos porttiles, tales como telfonos celulares, agendas electrnicas y teclados, refleja su incidencia en el desempeo de las tarjetas de manera significativa solamente para los rangos mayores a Do. Adems se logr establecer comunicacin entre tarjetas BlueBoard_UV hasta una distancia mxima de 12m en condiciones normales de operacin. Informacin detallada de las pruebas efectuadas, se puede encontrar en el captulo 5 de este documento.

El conjunto de interfaces de las tarjetas BlueBoard_UV01 y BlueBoard_UV02 (USB, UART, I2C y PCM), hacen de stas sistemas muy flexibles y completos que facilitan la integracin de la tecnologa, en general, a cualquier sistema microprocesado o microcontrolado. Las capas superiores del stack de protocolos Bluetooth en sus versiones para PC y sistemas embebidos se encuentran disponibles en internet bajo licencia GPL, ya sea para su directa utilizacin o para ser tomados como modelo de referencia para el desarrollo de stacks ms sencillos y dedicados a aplicaciones especficas. Las aplicaciones donde pueden utilizarse las tarjetas son ilimitadas, ofreciendo muchas posibilidades para futuros proyectos. Un ejemplo sera la implementacin de un sistema microprocesado o microcontrolado que contenga las capas superiores del stack Bluetooth (host stack) no contenidas en las tarjetas BlueBoard_UV. Este sistema interconectado con una tarjeta BlueBoard_UV conformara un sistema embebido muy flexible y til para aplicaciones especficas tales como redes de sensores y actuadores inalmbricos.

REFERENCIAS

[1]

BLUETOOTH SPECIAL INTEREST GROUP. Disponible en Internet: < URL: http://www.bluetooth.com >.

[2]

MINISTERIO

DE

COMUNICACIONES

DE

COLOMBIA.

CuadroAtribucion.pdf [Archivo PDF], Disponible en Internet: < URL: http://www.mincomunicaciones.gov.co >.

[3]

BLUETOOTH

SPECIAL

INTEREST

GROUP. <

Bluetooth

Core,

Specification of the Bluetooth System, Versin 1.1, 22 de Febrero de 2003. Disponible en Internet: URL: http: http://www.bluetooth.com/dev/specifications.asp >.

[4]

BLUETOOTH

SPECIAL

INTEREST

GROUP. <

Bluetooth

Profiles,

Specification of the Bluetooth System, Versin 1.1, 22 de Febrero de 2003. Disponible en Internet: URL: http:// www.bluetooth.com/dev/specifications.asp >. <

[5]

Disponible

en

Internet:

URL:

http://

www.teleca.com,

http://

www.comtec.teleca.se >. Disponible en Internet: < URL: http:// www.suyin.de >. Disponible en Internet: < URL: http:// www.rangestar.com >.

[6]

[7]

[8]

Disponible en Internet: < URL: http:// www.national.com >. Disponible en Internet: < URL: http:// www.maxim-ic.com >. Disponible en Internet: < URL: http:// www.csr.com >. Disponible en Internet: < URL: http:// www.bluefrogsolution.com >. Disponible en Internet: < URL: http:// www.national.com/bluetooth >. Disponible en Internet: < URL: http:// www.atmel.com >. Disponible en Internet: < URL: http:// www.digianswer.com >. Disponible en Internet: < URL: http:// www.3com.com >. Disponible en Internet: < URL: http:// www.smartm.com >. Disponible en Internet: < URL: http:// www.anoto.com >. Disponible en Internet: < URL: http:// www.motorola.com >. Disponible en Internet: < URL: http:// qualweb.opengroup.org >.

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

M. Ali and G. J. Hayes, Analysis of Integrated-F Antennas for Bluetooth Applications, 2000 IEEE-APS Conference on Antennas and Propagation for Wireless Communications, November 2000.

[21]

R. Wansch, H. Humpfer, and J. Hupp, An Integrated F-Antenna for Diversity Reception in a DECT Data Transmission Module, IEEE Antennas Propagation Society International Symposium, July 2000.

[22]

MEZOE, Cambridge Consultants Ltd. BlueStack User Manual, 2001, p. 20 22. Disponible en Internet: < URL: http://www.mezoe.com >.

[23]

ERICSSON MOBILE COMMUNICATIONS. Bluetooth HOST Stack, HostSW0601.pdf [Archivo PDF], Lund (Sweden), Octubre de 2000. Disponible en Internet: < URL: http://www.ericsson.com/bluetooth/ >.

[24]

DIGIANSWER. Bluetooth MkII Democard, productsheet-dc-mk2.pdf [Archivo PDF]. Disponible en Internet: <URL: http://www.digianswer.com>.

[25]

Heuser, Werner. Laptops, Bluetooth(TM) and Linux, 23 de Abril de 2003. Disponible en Internet: <URL: http://tuxmobil.org/bluetooth_linux.html>.

[26]

AXIS, Cdigo fuente de OpenBt [Archivo tar.gz]. Disponible en Internet: <URL: http://sourceforge.net/projects/openbt/>.

[27]

AXIS,

Portal

en

Internet:

<

URL:

http://developer.axis.com/software/bluetooth/>.

[28]

IBM,

Sitio

de

Internet

de

Alpha

Works:

<

URL:

http://www.alphaworks.ibm.com/tech/bluedrekar>.

[29]

AFFIX, portal en Internet: < URL: http://affix.sourceforge.net>.

[30]

BlueZ, disponible en Internet: <URL: http://bluez.sourceforge.net >.

[31]

KASATKIN, Dmitri. Affix in a Nutshell, Nokia Corporation, 2001-2002. Disponible en Internet: [Formato html]: < URL: http://affix.sourceforge.net/affix-doc/index.html >. [Formato PDF]: < URL: http://affix.sourceforge.net/affix-doc/affix-doc.pdf >.

[32]

UNIX Networking Programming, Volmen 1: Networking APIs - Sockets and XTI, Prentice Hall, 17 de Octubre de 1997.

[33]

BEUTEL, Jan y KRASNYANSKIY, Maksim. Linux BlueZ Howto, 14 de Noviembre de 2001. Disponible en Internet [En lnea]: < URL: http://bluez.sourceforge.net/howto/index.html >.

[34]

BLUETOOTH SPECIAL INTEREST GROUP. Personal Area Networking Profile. Specification of the Bluetooth System, Versin 1.0, 14 de Febrero de 2003. Disponible en Internet: < URL:

http://www.bluetooth.com/dev/specifications.asp>.

[35]

BLUETOOTH

SPECIAL

INTEREST

GROUP.

Bluetooth

Network

Encapsulation Protocol (BNEP) Specification. Specification of the Bluetooth System, Versin 1.0, 14 de Febrero de 2003. Disponible en Internet: < URL: http://www.bluetooth.com/dev/specifications.asp>. <

[36]

Disponible

en

Internet:

URL:

http://

http://www.iana.org/assignments/ethernet-numbers >.

[37]

DIGITAL EQUIPMENT CORPORATION, INTEL CORPORATION, XEROX CORPORATION. The Ethernet A Local Area Network, Versin 1.0. Septiembre de 1980.

[38]

BJAR, Eduardo. Linux Ethernet Bridge, Guia de Instalacin, 8 de Noviembre de 2002. Disponible en Internet: < URL: http://www.linkabu.net/linux/ >. Cdigo fuente del paquete bridge-utils. Disponible en Internet: < URL: http://bridge.sourceforge.net/download.html>.

[39]

[40]

Layer 2 ethernet bridging with Linux, 7 de Noviembre de 2001. Disponible en Internet: < URL: http://bridge.sourceforge.net/>.

[41]

Demonstrate the PAN in Linux system. Disponible en Internet [Formato html]: < URL: http://affix.sourceforge.net/archive/PAN/affix_pan_demo.html > [Formato pdf]: < URL:

http://affix.sourceforge.net/archive/PAN/aff_pan_dem.pdf>.

[42]

SCHMIDT, Michael. HowTo set up common PAN scenarios with BlueZ's integrated PAN support. University of Siegen, Germany. Disponible en Internet: < URL: http://bluez.sourceforge.net/contrib/HOWTO-PAN>. <

[43]

BTnod

rev

2.2

project.

Disponible

en

Internet:

URL:

http://www.inf.ethz.ch/vs/res/proj/smart-its/btnode.html#sw>.

[44]

Computer Engineering and Networks Laboratory (tik). Sitio en Internet disponible en: < URL: http://www.tik.ee.ethz.ch/>.

[45]

Research Group for Distributed Systems. Sitio en Internet disponible en: < URL: http://www.inf.ethz.ch/vs/>.

[46]

Swiss Federal Institute of Technology Zurich. Sitio en Internet disponible en: < URL: http://www.ethz.ch/>.