implementación de una red inalámbrica bluetooth - Universidad del ...
implementación de una red inalámbrica bluetooth - Universidad del ...
implementación de una red inalámbrica bluetooth - Universidad del ...
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
IMPLEMENTACIÓN DE UNA RED INALÁMBRICA<br />
BLUETOOTH<br />
OSCAR DARÍO RODRÍGUEZ CALVACHI<br />
RICARDO ANDRÉS MAYA CORAL<br />
Trabajo <strong>de</strong> grado presentado como requisito para obtener el título <strong>de</strong><br />
Ingeniero Electrónico<br />
Director<br />
FABIO G. GUERRERO MORENO<br />
UNIVERSIDAD DEL VALLE<br />
FACULTAD DE INGENIERÍA<br />
ESCUELA DE INGENIERÍA ELÉCTRICA Y ELECTRÓNICA<br />
PROGRAMA DE INGENIERÍA ELECTRÓNICA<br />
SANTIAGO DE CALI<br />
2003
Santiago <strong>de</strong> Cali, Agosto <strong>de</strong> 2003<br />
Nota <strong>de</strong> aceptación:<br />
___________________________________<br />
___________________________________<br />
___________________________________<br />
___________________________________<br />
___________________________________<br />
___________________________________<br />
___________________________________<br />
Director: Fabio G. Guerrero Moreno<br />
___________________________________<br />
Jurado: Asfur Baradica López<br />
___________________________________<br />
Jurado: Oscar Polanco Sarmiento
A mis padres, por todos sus consejos y apoyo incondicional. A mis hermanos, que<br />
es por quienes trato <strong>de</strong> ser cada día mejor para ser un ejemplo a seguir. A toda mi<br />
familia, que es mi apoyo en todo difícil momento <strong>de</strong> la vida. A todos ellos…<br />
Oscar Darío Rodríguez Calvachi<br />
A mis padres, por su cariño, comprensión y confianza. A mis hermanos que son mi<br />
pilar <strong>de</strong> apoyo y a mi familia, la fuente que me anima a seguir mi camino.<br />
Ricardo Andrés Maya Coral
AGRADECIMIENTOS<br />
A Fabio Guerrero, por su confianza y apoyo, a todos nuestros compañeros y<br />
amigos, quienes siempre estuvieron pendientes y nos apoyaron constantemente, a<br />
las empresas Ericsson Suiza y Dinamarca, RangStar USA y Suyin USA, por su<br />
invaluable ayuda, y a todos las personas que directa o indirectamente colaboraron<br />
en el <strong>de</strong>sarrollo <strong>de</strong> este proyecto….Gracias.
CONTENIDO<br />
INTRODUCCIÓN 22<br />
1. DESCRIPCIÓN GENERAL DE LA TECNOLOGÍA INALÁMBRICA BLUETOOTH 23<br />
1.1 BANDA BASE 29<br />
1.1.1 Descripción general. 29<br />
1.1.2 Canal físico. 30<br />
1.1.3 Enlace físico. 30<br />
1.1.4 Paquetes. 31<br />
1.1.5 Corrección <strong>de</strong> errores. 33<br />
1.1.6 Transmisión/Recepción. 34<br />
1.1.7 Control <strong>de</strong> Canal. 35<br />
1.1.8 Seguridad en Bluetooth. 38<br />
1.2 PROTOCOLO DE GESTIÓN DE ENLACE (LMP) 38<br />
1.2.1 Establecimiento <strong>de</strong> conexión. 39<br />
1.3 INTERFAZ DEL CONTROLADOR DE HOST (HCI) 40<br />
1.3.1 Capas mas bajas <strong>de</strong>l stack Bluetooth. 40<br />
1.3.2 Posibles arquitecturas <strong>de</strong> bus físico. 42<br />
1.4 PROTOCOLO DE CONTROL Y ADAPTACIÓN DE ENLACE LÓGICO (L2CAP) 43<br />
1.4.1 Canales. 43<br />
1.4.2 Operaciones entre Capas. 43<br />
pág.
1.4.3 Segmentación y Reensamblado. 44<br />
1.4.4 Eventos. 45<br />
1.4.5 Acciones. 45<br />
1.4.6 Formato <strong>de</strong>l paquete <strong>de</strong> datos. 45<br />
1.4.7 Calidad <strong>de</strong> servicio (QoS). 46<br />
1.5 PROTOCOLO DE DESCUBRIMIENTO DE SERVICIO (SDP) 47<br />
1.5.1 Descripción General. 47<br />
1.5.2 Registros <strong>de</strong> servicio. 47<br />
1.5.3 El protocolo. 47<br />
1.6 RFCOMM 49<br />
1.7 PERFILES BLUETOOTH 50<br />
1.7.1 Perfil Genérico <strong>de</strong> Acceso (GAP). 51<br />
1.7.2 Perfil <strong>de</strong> Puerto Serial. 51<br />
1.7.3 Perfil <strong>de</strong> Aplicación <strong>de</strong> Descubrimiento <strong>de</strong> Servicio (SDAP). 52<br />
1.7.4 Perfil Genérico <strong>de</strong> Intercambio <strong>de</strong> Objetos (GOEP). 52<br />
1.7.5 Perfil <strong>de</strong> Telefonía Inalámbrica 52<br />
1.7.6 Perfil <strong>de</strong> Intercomunicador. 52<br />
1.7.7 Perfil <strong>de</strong> Manos Libres. 53<br />
1.7.8 Perfil Dial-up Networking. 53<br />
1.7.9 Perfil <strong>de</strong> Fax. 53<br />
1.7.10 Perfil <strong>de</strong> Acceso LAN. 53<br />
1.7.11 Perfil Object Push. 54<br />
1.7.12 Perfil <strong>de</strong> Transferencia <strong>de</strong> Archivos. 54
1.7.13 Perfil <strong>de</strong> Sincronización. 54<br />
2. DESCRIPCIÓN DE HARDWARE Y PRODUCTOS BLUETOOTH 55<br />
2.1 TARJETAS BLUEBOARDUV 55<br />
2.1.1 Descripción <strong>de</strong> las tarjetas BlueboardUV. 57<br />
2.1.2 Descripción <strong>de</strong> componentes y requerimientos en las tarjetas BlueboardUV. 63<br />
2.1.2.1 Módulo Bluetooth Ericsson ROK101007/8. 63<br />
2.1.2.2 Diseño <strong>de</strong> Antena. 67<br />
2.1.2.3 Antenas RangeStar. 72<br />
2.1.2.4 Regulador <strong>de</strong> Voltaje National LP2987. 76<br />
2.1.2.5 MAXIM MAX3232. 77<br />
2.1.2.6 Soporte SUYIN BT001A-30G2T. 77<br />
2.1.3 Fotografías <strong>de</strong> las tarjetas BlueboardUV. 78<br />
2.2 PRODUCTOS BLUETOOTH 81<br />
2.3 PROCEDIMIENTO DE CALIFICACIÓN BLUETOOTH 82<br />
2.4 ANTENAS EN F INVERTIDA INTEGRADAS 83<br />
3. SOFTWARE PARA EL HOST BLUETOOTH 85<br />
3.1 ARQUITECTURAS DE INTEGRACIÓN DEL STACK DE PROTOCOLOS<br />
BLUETOOTH 88<br />
3.2 PRINCIPALES SOFTWARE PARA EL HOST 90<br />
3.2.1 Software Bluetooth con propiedad <strong>de</strong> licencia. 91<br />
3.2.2 Software Bluetooth con licencia pública (GPL) 93<br />
3.3 CONCEPTOS DEL CORE DE LINUX 95
3.4 DESCRIPCIÓN DEL STACK DE PROTOCOLOS DE AFFIX 98<br />
3.4.1 Arquitecturas Soportadas 98<br />
3.4.2 Hardware Soportado 99<br />
3.4.3 Arquitectura <strong>de</strong> Affix 99<br />
3.4.4 Utilida<strong>de</strong>s <strong>de</strong> Affix 102<br />
3.4.5 Instrucciones <strong>de</strong> Instalación 102<br />
3.5 DESCRIPCIÓN DEL STACK DE PROTOCOLOS BLUEZ 103<br />
3.5.1 Compilación e Instalación 105<br />
4. CONCEPTOS BÁSICOS PARA LA IMPLEMENTACIÓN DE UNA RED DE AREA<br />
PERSONAL BLUETOOTH 108<br />
4.1 PROTOCOLO DE ENCAPSULAMIENTO DE RED BNEP 108<br />
4.1.1 Consi<strong>de</strong>raciones 109<br />
4.1.2 Or<strong>de</strong>n <strong>de</strong> los Bytes y Valores numéricos 110<br />
4.1.3 Encapsulamiento <strong>de</strong> Paquetes 111<br />
4.1.4 Formato <strong>de</strong> los Encabezados BNEP 111<br />
4.1.5 Tipo <strong>de</strong> Paquete BNEP_GENERAL_ETHERNET 113<br />
4.1.6 Tipo <strong>de</strong> Paquete BNEP_CONTROL 114<br />
4.1.7 Tipo <strong>de</strong> Paquete BNEP_COMPRESSED_ETHERNET 114<br />
4.1.8 Tipo <strong>de</strong> Paquete BNEP_COMPRESSED_ETHERNET_SOURCE_ONLY 115<br />
4.1.9 Tipo <strong>de</strong> Paquete BNEP_COMPRESSED_ETHERNET_DEST_ONLY 116<br />
4.2 Piconet y scatternet 117<br />
4.3 PERFIL DE RED DE AREA PERSONAL (PAN PROFILE) 120
4.3.1 Consi<strong>de</strong>raciones 121<br />
4.3.2 Puntos <strong>de</strong> Acceso a <strong>una</strong> <strong>red</strong> (NAP) 121<br />
4.3.3 Grupo <strong>de</strong> Red Ad-hoc 123<br />
4.3.4 PANU – PANU 125<br />
5. PRUEBAS DE DESEMPEÑO Y APLICACIÓN PARA LAS TARJETAS<br />
BLUEBOARD_UV01 Y BLUEBOARD_UV02 126<br />
5.1 PRUEBAS DE DESEMPEÑO 127<br />
5.1.1 Configuración para las Pruebas 127<br />
5.1.2 Descripción <strong>de</strong> las Pruebas 127<br />
5.1.3 Depen<strong>de</strong>ncias entre la velocidad <strong>de</strong> transmisión, los obstáculos y la distancia entre<br />
los nodos 130<br />
5.1.4 Estabilidad <strong>de</strong> la velocidad <strong>de</strong> transmisión respecto a la distancia y los obstáculos<br />
entre los nodos 136<br />
5.2 IMPLEMENTACIÓN DE UNA RED DE AREA PERSONAL BLUETOOTH 140<br />
5.2.1 Configuración <strong>de</strong> la PAN 141<br />
5.2.2 Ethernet Bridging 142<br />
5.2.3 Nodo maestro GN 143<br />
5.2.4 Nodos esclavos PANU1 y PANU2 144<br />
5.3 Software <strong>bluetooth</strong> para sistemas embebidos 145<br />
6. CONCLUSIONES 147<br />
REFERENCIAS
LISTA DE FIGURAS<br />
Figura 1-1. Stack <strong>de</strong> Protocolo Bluetooth 24<br />
Figura 1-2. Mo<strong>de</strong>lo <strong>de</strong> referencia OSI y Bluetooth 28<br />
Figura 1-3. Diagrama <strong>de</strong> <strong>una</strong> piconet. 29<br />
Figura 1-4. Transmisión en <strong>una</strong> piconet. 30<br />
Figura 1-5. Formato <strong>de</strong> paquete general 31<br />
Figura 1-6. Formato <strong>de</strong> cabecera <strong>de</strong> paquete 33<br />
Figura 1-7. Iniciación <strong>de</strong> comunicación sobre el nivel banda base 37<br />
Figura 1-8. Dirección <strong>de</strong> dispositivo Bluetooth 37<br />
Figura 1-9. Establecimiento <strong>de</strong> la conexión 40<br />
Figura 1-10. Diagrama general <strong>de</strong> las capas más bajas 41<br />
Figura 1-11. Diagrama general end to end <strong>de</strong> las capas <strong>de</strong> software más bajas 42<br />
Figura 1-12. Arquitectura L2CAP 44<br />
Figura 1-13. Segmentación L2CAP 45<br />
Figura 1-14. Paquete L2CAP 46<br />
Figura 1-15. Varios puertos seriales emulados mediante RFCOMM 49<br />
Figura 1.16. Los Perfiles Bluetooth 51<br />
Figura 2-1. Diagrama <strong>de</strong> Bloques <strong>de</strong> las tarjetas BlueboardUV 56<br />
Figura 2-2. Diagrama esquemático <strong>de</strong> las tarjetas BlueboardUV 59<br />
Figura 2-3. Diagrama <strong>de</strong>l hardware <strong>de</strong> la tarjeta BlueboardUV01 61<br />
pág.
Figura 2-4. Diagrama <strong>de</strong>l hardware <strong>de</strong> la tarjeta BlueboardUV02 62<br />
Figura 2-5. HW/FW <strong>de</strong>l módulo Ericsson ROK101007 65<br />
Figura 2-6. Configuración Típica USB para el ROK101007 66<br />
Figura 2-7. Configuración Típica UART o PCM para el ROK101007 67<br />
Figura 2-8. Ganancia Pico vs. Longitud PCB 69<br />
Figura 2-9. Ruteo <strong>de</strong> la parte superior <strong>de</strong> la tarjeta BlueboardUV01 70<br />
Figura 2-10. Ruteo <strong>de</strong> la parte inferior <strong>de</strong> la tarjeta BlueboardUV01 71<br />
Figura 2-11. Ruteo <strong>de</strong> la parte superior <strong>de</strong> la tarjeta BlueboardUV02 71<br />
Figura 2-12. Ruteo <strong>de</strong> la parte inferior <strong>de</strong> la tarjeta BlueboardUV03 72<br />
Figura 2-13. Antena RangeStar 100929 74<br />
Figura 2-14. Antena RangeStar 100930 74<br />
Figura 2-15. Requerimientos para las antenas RangeStar 100929 y100930 76<br />
Figura 2-16. Diagrama <strong>de</strong> bloques <strong>de</strong>l regulador <strong>de</strong> voltaje LP2987 77<br />
Figura 2-17. Bluetooth Carrier Socket SUYIN BT001A-30G2T 78<br />
Figura 2-18. Tarjeta BlueboardUV01 79<br />
Figura 2-19. Módulo Bluetooth <strong>de</strong>ntro <strong>de</strong>l soporte en la tarjeta BlueboardUV01 79<br />
Figura 2-20. Tarjeta BlueboardUV01 en funcionamiento 80<br />
Figura 2-21. Tarjeta BlueboardUV02 80<br />
Figura 2-22. Antena en F Invertida Integrada (IIFA) 84<br />
Figura 3-1. Mo<strong>de</strong>lo <strong>de</strong> <strong>implementación</strong> <strong>de</strong>l protocolo Bluetooth, Host – Hardware 86<br />
Figura 3-2. Mo<strong>de</strong>lo <strong>de</strong> Implementación <strong>de</strong>l protocolo Bluetooth. Software – Firmware –<br />
Hardware 87<br />
Figura 3-3. Tres mo<strong>de</strong>los <strong>de</strong> Integración <strong>de</strong>l stack <strong>de</strong> protocolos Bluetooth 89
Figura 3-4. Arquitectura <strong>de</strong> Red <strong>de</strong> Linux 95<br />
Figura 3-5. Mo<strong>de</strong>lo <strong>de</strong> la Arquitectura <strong>de</strong> Affix 100<br />
Figura 3-6. Diagrama <strong>de</strong> los Componentes <strong>de</strong> Affix 101<br />
Figura 3-7. Diagrama <strong>de</strong> la Arquitectura <strong>de</strong> Bluez 104<br />
Figura 4-1. Ubicación <strong>de</strong>l BNEP <strong>de</strong>ntro <strong>de</strong> la Torre <strong>de</strong> protocolos <strong>de</strong> Bluetooth. 110<br />
Figura 4-2. Encapsulamiento <strong>de</strong> un Paquete Ethernet en un paquete L2CAP 111<br />
Figura 4-3. Formato <strong>de</strong> los Encabezados BNEP 112<br />
Figura 4-4. Formato <strong>de</strong>l Encabezado para un paquete BNEP_GENERAL_ETHERNET 113<br />
Figura 4-5. Formato <strong>de</strong>l Encabezado para un paquete BNEP_CONTROL 114<br />
Figura 4-6. Formato <strong>de</strong>l encabezado para un paquete<br />
BNEP_COMPRESSED_ETHERNET 115<br />
Figura 4-7. Formato <strong>de</strong>l encabezado para un paquete<br />
BNEP_COMPRESSED_ETHERNET_SOURCE_ONLY 115<br />
Figura 4-8. Formato <strong>de</strong>l encabezado para un paquete<br />
BNEP_COMPRESSED_ETHERNET_DEST_ONLY 116<br />
Figura 4-9. Ejemplo <strong>de</strong>l envío <strong>de</strong> un paquete IPv4 usando BNEP entre un dispositivo con<br />
dirección IEEE y otro con dirección Bluetooth 117<br />
Figura 4-10. Esquema <strong>de</strong> <strong>una</strong> Piconet 118<br />
Figura 4-11. Ejemplo <strong>de</strong> <strong>una</strong> Piconet 118<br />
Figura 4-12. Esquema <strong>de</strong> <strong>una</strong> Scatternet 119<br />
Figura 4-13. Ejemplo <strong>de</strong> <strong>una</strong> Scatternet 120<br />
Figura 4-14. Dos Puntos <strong>de</strong> Acceso a Red 122<br />
Figura 4-15. Stack para el rol NAP 123
Figura 4-16. Esquema para un Grupo <strong>de</strong> Red Ad-hoc (GN) 124<br />
Figura 4-17. Stack para un enlace en <strong>una</strong> <strong>red</strong> Ad-hoc Bluetooth 125<br />
Figura 5-1. Arquitectura utilizada en las pruebas <strong>de</strong> <strong>de</strong>sempeño 128<br />
Figura 5-2. Rata <strong>de</strong> Bits Promedio Vs. Distancia 133<br />
Figura 5-3. Porcentaje <strong>de</strong> variación <strong>de</strong> la rata <strong>de</strong> Bits Vs. Distancia 138<br />
Figura 5-4. Arquitectura <strong>de</strong> la <strong>red</strong> <strong>de</strong> área personal 141
LISTA DE TABLAS<br />
Tabla 2-1. Lista <strong>de</strong> componentes para la tarjeta BlueboardUV.........................................60<br />
Tabla 2-2. Características <strong>de</strong> las antenas RangeStar 100929 y 100930 ..........................75<br />
Tabla 2-3. Algunos productos Bluetooth disponibles en el mercado.................................81<br />
Tabla 3-1. Software Bluetooth para el Host con propiedad <strong>de</strong> licencia.............................92<br />
Tabla 4-1. Valores para el campo BNEP Type el cual <strong>de</strong>fine el tipo <strong>de</strong> paquete BNEP 112<br />
Tabla 5-1. Rata <strong>de</strong> Bits promedio con LV........................................................................131<br />
Tabla 5-2. Rata <strong>de</strong> Bits promedio con M.........................................................................131<br />
Tabla 5-3. Rata <strong>de</strong> Bits promedio con MP.......................................................................131<br />
Tabla 5-4. Rata <strong>de</strong> Bits promedio con LVP .....................................................................132<br />
Tabla 5-5. Porcentaje <strong>de</strong> Variación <strong>de</strong>l Promedio <strong>de</strong> la rata <strong>de</strong> Bits con LV...................136<br />
Tabla 5-6. Porcentaje <strong>de</strong> Variación <strong>de</strong>l Promedio <strong>de</strong> la rata <strong>de</strong> Bits con M ....................136<br />
Tabla 5-7. Porcentaje <strong>de</strong> Variación <strong>de</strong>l Promedio <strong>de</strong> la rata <strong>de</strong> Bits con MP..................137<br />
Tabla 5-8. Porcentaje <strong>de</strong> Variación <strong>de</strong>l Promedio <strong>de</strong> la rata <strong>de</strong> Bits con LVP ................137<br />
Tabla 5-9. Porcentaje <strong>de</strong> Variación Promedio para cada Do ..........................................140<br />
pág.
GLOSARIO<br />
ACL: asynchronous Connectionless (asíncrono no orientado a la conexión).<br />
ANSI: American National Standards Institute.<br />
API: application program interface (Interfaz <strong>de</strong>l programa <strong>de</strong> aplicación).<br />
ARQUITECUTURA: intel, ARM (iPaq, ARM9 y otras) y PowerPC (iMac) entre<br />
otras.<br />
ATM: (modo <strong>de</strong> transferencia asíncrona) <strong>de</strong>ntro <strong>de</strong>l medio informático hace<br />
referencia a la conmutación <strong>de</strong> paquetes (cells -- celdas o células) <strong>de</strong> un tamaño<br />
fijo con alta carga, rápida velocidad (entre 1,544 Mbps. y 1,2 Gbps) y <strong>una</strong><br />
asignación dinámica <strong>de</strong> ancho <strong>de</strong> banda. También se conoce como "paquete<br />
veloz" (fast packet).<br />
BD_ADDR: dirección <strong>de</strong>l dispositivo Bluetooth.<br />
BNEP: Bluetooth network encapsulation protocol.<br />
BQP Bluetooth Qualification Program.<br />
CAD: computer ai<strong>de</strong>d <strong>de</strong>sign (diseño asistido por computador).<br />
CID: i<strong>de</strong>ntificador <strong>de</strong> canal.
CRC: chequeo <strong>de</strong> <strong>red</strong>undancia cíclica.<br />
DBI: sigla para “<strong>de</strong>cibeles relativos a <strong>una</strong> fuente isotrópica”.<br />
DCE: data communications equipment. Dispositivo que provee <strong>una</strong> trayectoria <strong>de</strong><br />
comunicación entre dos equipos. Por ejemplo el mó<strong>de</strong>m en un computador.<br />
DRIVER: controlador que permite gestionar los periféricos que están conectados<br />
al or<strong>de</strong>nador (http://www.guiahost.com/servicios/glosario).<br />
ESPACIO DE KERNEL: espacio <strong>de</strong> memoria ocupado por el código compilado <strong>de</strong>l<br />
kernel <strong>de</strong> linux.<br />
ESPACIO DE USUARIO: espacio <strong>de</strong> memoria ocupado por el código compilado<br />
<strong>de</strong> los programas <strong>de</strong> aplicación <strong>de</strong>l usuario.<br />
ETHERNET: <strong>red</strong> <strong>de</strong> área local (LAN) <strong>de</strong>sarrollada por Xerox, Digital e Intel. Es el<br />
método <strong>de</strong> acceso LAN que más se utiliza (seguido por Token Ring). Ethernet es<br />
<strong>una</strong> LAN <strong>de</strong> medios compartidos. Todos los mensajes se diseminan a todos los<br />
nodos en el segmento <strong>de</strong> <strong>red</strong> (http://www.guiahost.com/servicios/glosario).<br />
ETSI: European Telecommunications Standards Institute. Organización sin ánimo<br />
<strong>de</strong> lucro cuya misión es crear estándares <strong>de</strong> telecomunicaciones para ser usados<br />
por décadas en Europa (http://www.etsi.org).<br />
FCC: Comisión Fe<strong>de</strong>ral <strong>de</strong> Comunicaciones. Su principal función es la <strong>de</strong><br />
mantener el control sobre el amplio sector <strong>de</strong> las telecomunicaciones en los<br />
Estados Unidos (http://www.guiahost.com/servicios/glosario).<br />
FIFO: first In first out. El primero en entrar es el primero en salir.
FIRMWARE: parte <strong>de</strong>l software <strong>de</strong> un or<strong>de</strong>nador que no pue<strong>de</strong> modificarse por<br />
encontrarse en la ROM o memoria <strong>de</strong> sólo lectura, Read Only Memory. Es <strong>una</strong><br />
mezcla o híbrido entre el hardware y el software, es <strong>de</strong>cir tiene parte física y <strong>una</strong><br />
parte <strong>de</strong> programación consistente en programas internos implementados en<br />
memorias no volátiles. Un ejemplo típico <strong>de</strong> Firmware lo constituye la BIOS.<br />
(http://www.guiahost.com/servicios/glosario).<br />
GAP: generic access profile (perfil genérico <strong>de</strong> acceso).<br />
GNU: es un acrónimo recursivo para ``no es Unix'' Se crea en 1984 sin mucho<br />
éxito, bajo la filosofía <strong>de</strong>l software libre, muy al estilo <strong>de</strong> UNIX.<br />
GOEP: generic object exchange profile (perfil genérico <strong>de</strong> intercambio <strong>de</strong> objetos).<br />
GPL: licencia pública general (general public license), <strong>de</strong>sarrollada por la FSF o<br />
Free Software Foundation. Pue<strong>de</strong> ser instalado sin limitación en uno o varios<br />
or<strong>de</strong>nadores. En las distribuciones <strong>de</strong> estos programas <strong>de</strong>be estar incluido el<br />
código fuente.<br />
HARDWARE: componentes electrónicos y electro-mecánicos <strong>de</strong> <strong>una</strong> computadora<br />
o cualquier otro sistema. Este término es usado para distinguir estos componentes<br />
físicos <strong>de</strong> los datos y programas.<br />
HCI: host controller interface (interfaz controladora <strong>de</strong>l host).<br />
HEC: chequeo <strong>de</strong> <strong>red</strong>undancia cíclica <strong>de</strong> encabezados.<br />
HOST: sistema microprocesado programable (PCs, teléfonos celulares, mouse,<br />
impresoras, teclados, sensores inalámbricos, etc.), capaz <strong>de</strong> ejecutar las líneas <strong>de</strong><br />
código correspondientes al stack <strong>de</strong> protocolos Bluetooth para el host.
HW / FW: hardware / firmware.<br />
I 2 C: interfaz <strong>de</strong> datos <strong>de</strong> dos líneas (SDA y SCL) que utiliza palabras <strong>de</strong> 8 bits y es<br />
usada para comunicar memorias, controladores <strong>de</strong> vi<strong>de</strong>o, preamplificadores <strong>de</strong><br />
audio y otros dipositivos.<br />
IAC: codigo <strong>de</strong> acceso <strong>de</strong> búsqueda.<br />
IFA: inverted F antenna (antena en F invertida).<br />
ISM: industrial, scientific, medical.<br />
KERNEL: núcleo, es la parte fundamental <strong>de</strong> un programa, por lo general <strong>de</strong> un<br />
sistema operativo, que resi<strong>de</strong> en memoria todo el tiempo y que provee los<br />
servicios básicos. Es la parte <strong>de</strong>l sistema operativo que está más cerca <strong>de</strong> la<br />
máquina y pue<strong>de</strong> activar el hardware directamente o unirse a otra capa <strong>de</strong><br />
software que maneja el hardware (http://www.guiahost.com/servicios/glosario).<br />
L2CAP: logical link controller and adaptation protocol (protocolo <strong>de</strong> adaptación y<br />
control <strong>de</strong> enlace lógico).<br />
LMP: link manager protocol (Protocolo <strong>de</strong>l administrador <strong>de</strong> enlace).<br />
ME: management entity (entidad <strong>de</strong> administración o manejo).<br />
MODULO BLUETOOTH: módulo multichip que implementa en hardware y<br />
firmware las capas bajas <strong>de</strong>l stack <strong>de</strong> protocolos Bluetooth.<br />
MTU: maximun transmission unit.
PAD: punto <strong>de</strong> conexión <strong>de</strong>l terminal <strong>de</strong> un dispositivo.<br />
PAGING: servicio para transferencia <strong>de</strong> señalización o información en un sentido,<br />
mediante paquetes, tonos, etc…<br />
PAN: personal area networking.<br />
PATH: es la trayectoria <strong>de</strong> <strong>una</strong> pista en un circuito impreso.<br />
PCB: printed Circuit Board (Tarjeta <strong>de</strong> circuito impreso).<br />
PPP: point to point protocol (Protocolo punto-a-punto).<br />
QoS: calidad <strong>de</strong> servicio.<br />
RF: radio frecuencia.<br />
RFCOMM: serial port emulation basado en el estándar ETSI TS07.10.<br />
SAR: segmentación y reensamblado.<br />
SCO: synchronous connection oriented (Síncrono orientado a la conexión).<br />
SDAP: service discovery aplication protocol (perfil <strong>de</strong> aplicación <strong>de</strong> <strong>de</strong>scubrimiento<br />
<strong>de</strong> servicio).<br />
SDP: service discovery protocol (protocolo <strong>de</strong> <strong>de</strong>scubrimiento <strong>de</strong> servicio).<br />
SIG: special interest group.
SOCKET: es <strong>una</strong> abstracción <strong>de</strong> <strong>red</strong> para los terminales <strong>de</strong> un canal. El Socket<br />
está asociado con el protocolo; usualmente, el PF_INET es usado para asociar un<br />
socket con el protocolo TCP/IP.<br />
TIMEOUT: tiempo <strong>de</strong> espera excedido.<br />
TIMESLOT: ranura <strong>de</strong> tiempo. En Bluetooth tiene <strong>una</strong> duración <strong>de</strong> 625 us.<br />
TOKEN RING: el anillo <strong>de</strong> Fichas (token ring), es <strong>una</strong> <strong>red</strong> <strong>de</strong> topología <strong>de</strong> anillo<br />
que se sirve <strong>de</strong>l pase <strong>de</strong> fichas para el control <strong>de</strong> acceso. La frase también se<br />
aplica a <strong>una</strong> topología <strong>de</strong> pase <strong>de</strong> fichas específica <strong>de</strong>finida por la IBM Corporation<br />
(http://www.guiahost.com/servicios/glosario).<br />
TRANSCEIVER: transmisor-receptor.<br />
UART: el transmisor receptor universal asíncrono (universal asynchronous<br />
receiver transmitter), es un dispositivo que multiplexa datos paralelos en seriales<br />
para ser transmitidos y convierte en paralelos los datos seriales recibidos.<br />
USB: la característica principal <strong>de</strong>l bus serie universal (universal serial bus) resi<strong>de</strong><br />
en que los periféricos pue<strong>de</strong>n conectarse y <strong>de</strong>sconectarse con el equipo en<br />
marcha, configurándose <strong>de</strong> forma automática. Conector externo que llega a<br />
transferencias <strong>de</strong> 12 millones <strong>de</strong> bits por segundo. Totalmente PnP, sustituirá al<br />
puerto serie y paralelo, gracias a la posibilidad <strong>de</strong> conectar 127 dispositivos.<br />
(http://www.guiahost.com/servicios/glosario).<br />
WAP: wireless application protocol (protocolo para aplicaciones <strong>inalámbrica</strong>s).
RESUMEN<br />
El aporte principal <strong>de</strong> este trabajo es el <strong>de</strong>sarrollo <strong>de</strong> un sistema Bluetooth semiembebido.<br />
En principio, se analizó <strong>de</strong>talladamente la especificación Bluetooth y se<br />
hizo un estudio <strong>de</strong> los productos disponibles en el mercado. Con el conocimiento<br />
adquirido se diseñaron y construyeron dos tipos <strong>de</strong> tarjeta Bluetooth,<br />
BlueBoard_UV01 y BlueBoard_UV02. En este documento se <strong>de</strong>scribe en <strong>de</strong>talle<br />
su funcionamiento, al igual que se presentan sus diagramas, características y<br />
materiales empleados, entre otros. A<strong>de</strong>más se analizaron diferentes stacks <strong>de</strong><br />
protocolos Bluetooth (Affix y Bluez), con los cuales y utilizando las tarjetas<br />
construidas, se implementó <strong>una</strong> <strong>red</strong> <strong>inalámbrica</strong> <strong>de</strong> carácter didáctico. Con los<br />
sistemas <strong>de</strong>sarrollados, se hicieron pruebas <strong>de</strong> <strong>de</strong>sempeño logrando verificar y<br />
analizar principios básicos <strong>de</strong> operación <strong>de</strong> esta tecnología.<br />
PALABRAS CLAVE: Bluetooth<br />
Re<strong>de</strong>s Inalámbricas<br />
Comunicaciones Móviles
INTRODUCCIÓN<br />
Estamos en un mundo en el cual la movilidad es <strong>una</strong> necesidad en constante<br />
aumento y en el que el acceso a la información no pue<strong>de</strong> tener límites. En aras <strong>de</strong><br />
satisfacer estas necesida<strong>de</strong>s, han surgido nuevas tecnologías, cada <strong>una</strong> enfocada<br />
en un campo <strong>de</strong> acción específico. Teléfonos móviles (acceso a WAN), WLAN<br />
IEEE 802.11 (acceso a LAN) y Bluetooth (acceso a PAN), son ejemplos <strong>de</strong><br />
tecnologías <strong>inalámbrica</strong>s, cada <strong>una</strong> con un campo <strong>de</strong> acción diferente, pero que<br />
en conjunto conforman <strong>una</strong> completa solución a los problemas <strong>de</strong> movilidad.<br />
Colombia está en <strong>una</strong> época <strong>de</strong> transición tecnológica, mo<strong>de</strong>rnizando su<br />
infraestructura <strong>de</strong> comunicaciones y masificando poco a poco el acceso a la<br />
misma. Casos como el <strong>de</strong> la telefonía móvil <strong>de</strong> segunda y tercera generación<br />
(PCS y otras que usan GSM), implican más y mejores servicios (transmisión <strong>de</strong><br />
audio y vi<strong>de</strong>o con buena <strong>de</strong>finición), que promueven e incentivan el uso <strong>de</strong><br />
tecnologías como Bluetooth.<br />
Este trabajo <strong>de</strong> grado, cimienta las bases para conocer y apren<strong>de</strong>r la tecnología<br />
<strong>inalámbrica</strong> Bluetooth en la <strong>Universidad</strong> <strong>de</strong>l Valle, diseñar hardware Bluetooth y<br />
realizar aplicaciones prácticas dirigidas a <strong>de</strong>sarrollar nuevos sistemas que con la<br />
ayuda <strong>de</strong> otros campos <strong>de</strong> la electrónica como por ejemplo la instrumentación y la<br />
automática, resuelvan otro tipo <strong>de</strong> problemas a través <strong>de</strong> re<strong>de</strong>s <strong>de</strong> censado y<br />
actuadores inalámbricos.
1. DESCRIPCIÓN GENERAL DE LA TECNOLOGÍA<br />
INALÁMBRICA BLUETOOTH<br />
La tecnología <strong>inalámbrica</strong> Bluetooth ofrece <strong>una</strong> forma <strong>de</strong> remplazar cables y<br />
enlaces infrarrojos que interconectan dispositivos por un enlace <strong>de</strong> radio universal<br />
<strong>de</strong> corto alcance, con capacidad <strong>de</strong> crear pequeñas radio LANs. El nombre<br />
Bluetooth viene <strong>de</strong> un rey danés llamado Harald Blaatand (en inglés “Bluetooth”)<br />
quien vivió entre los años 940 y 981 y quien controló a Noruega y Dinamarca.<br />
En Febrero <strong>de</strong> 1998, se fundó el Bluetooth Special Interest Group (SIG), creado<br />
con el fin <strong>de</strong> ofrecer soporte para la nueva tecnología. Actualmente, más <strong>de</strong> mil<br />
compañías lo integran y trabajan conjuntamente por un estándar abierto para el<br />
concepto Bluetooth [1].<br />
Bluetooth es un sistema <strong>de</strong> radio que opera en la banda <strong>de</strong> frecuencia libre <strong>de</strong> 2.4<br />
GHz, esta banda <strong>de</strong> frecuencia está disponible en la mayor parte <strong>de</strong>l mundo. En<br />
Colombia el Ministerio <strong>de</strong> Comunicaciones reglamenta su uso así: “Las bandas,<br />
902 - 924 MHz, 2 400 - 2 483,5 MHz y 5 725 - 5 850 MHz se atribuyen a título<br />
secundario, conforme con la resolución 3382 <strong>de</strong> 15 <strong>de</strong> diciembre <strong>de</strong> 1995, para los<br />
sistemas <strong>de</strong> espectro ensanchado” [2]. Bluetooth utiliza 79 canales <strong>de</strong> radio<br />
frecuencia con un ancho <strong>de</strong> banda <strong>de</strong> 1 MHz cada uno y <strong>una</strong> rata máxima <strong>de</strong><br />
símbolos <strong>de</strong> 1 MSímbolo/s. Después <strong>de</strong> que cada paquete es enviado en <strong>una</strong><br />
<strong>de</strong>terminada frecuencia <strong>de</strong> transmisión, ésta cambia a otra <strong>de</strong> las 79 frecuencias<br />
[3]. El rango típico <strong>de</strong> operación <strong>de</strong> Bluetooth es menor a 10 m, sin embargo se<br />
pue<strong>de</strong>n alcanzar distancias <strong>de</strong> hasta 100 m con el uso <strong>de</strong> amplificadores.
Como se pue<strong>de</strong> observar en la Figura 1-1, la comunicación sobre Bluetooth se<br />
divi<strong>de</strong> en varias capas. A continuación se presenta <strong>una</strong> breve <strong>de</strong>scripción <strong>de</strong><br />
alg<strong>una</strong>s <strong>de</strong> ellas y se tratarán en mayor <strong>de</strong>talle en sub-capítulos posteriores.<br />
Figura 1-1. Stack <strong>de</strong> Protocolo Bluetooth<br />
La capa <strong>de</strong> comunicación más baja es llamada banda base. Esta capa<br />
implementa el canal físico real. Emplea <strong>una</strong> secuencia aleatoria <strong>de</strong> saltos a través<br />
<strong>de</strong> 79 frecuencias <strong>de</strong> radio diferentes. Los paquetes son enviados sobre el canal<br />
físico, don<strong>de</strong> cada uno es enviado en <strong>una</strong> frecuencia <strong>de</strong> salto diferente. La Banda
Base controla la sincronización <strong>de</strong> las unida<strong>de</strong>s Bluetooth y la secuencia <strong>de</strong> saltos<br />
en frecuencia, a<strong>de</strong>más es la responsable <strong>de</strong> la información para el control <strong>de</strong><br />
enlace a bajo nivel como el reconocimiento, control <strong>de</strong> flujo y caracterización <strong>de</strong><br />
carga útil y soporta dos tipos <strong>de</strong> enlace: síncrono orientado a la conexión (SCO),<br />
para datos y asíncrono no orientado a la conexión (ACL), principalmente para<br />
audio. Los dos pue<strong>de</strong>n ser multiplexados para usar el mismo enlace RF. Usando<br />
ancho <strong>de</strong> banda reservado, los enlaces SCO soportan tráfico <strong>de</strong> voz en tiempo<br />
real.<br />
El Link Manager Protocol (LMP) o Protocolo <strong>de</strong> Gestión <strong>de</strong> Enlace es el<br />
responsable <strong>de</strong> la autenticación, encriptación, control y configuración <strong>de</strong>l enlace.<br />
El LMP también se encarga <strong>de</strong>l manejo <strong>de</strong> los modos y consumo <strong>de</strong> potencia,<br />
a<strong>de</strong>más soporta los procedimientos necesarios para establecer un enlace SCO.<br />
El Host Controller Interface (HCI) o Interfaz <strong>de</strong>l Controlador <strong>de</strong> Enlace brinda un<br />
método <strong>de</strong> interfaz uniforme para acce<strong>de</strong>r a los recursos <strong>de</strong> hardware <strong>de</strong><br />
Bluetooth. Éste contiene <strong>una</strong> interfaz <strong>de</strong> comando para el controlador banda base<br />
y la gestión <strong>de</strong> enlace y para acce<strong>de</strong>r al hardware.<br />
El Logical Link Control and Adaptation Protocol (L2CAP) o Protocolo <strong>de</strong><br />
Control y Adaptación <strong>de</strong> Enlace Lógico, correspon<strong>de</strong> a la capa <strong>de</strong> enlace <strong>de</strong> datos.<br />
Ésta brinda servicios <strong>de</strong> datos orientados y no orientados a la conexión a capas<br />
superiores. L2CAP multiplexa los protocolos <strong>de</strong> capas superiores con el fin <strong>de</strong><br />
enviar varios protocolos sobre un canal banda base. Con el fin <strong>de</strong> manipular<br />
paquetes <strong>de</strong> capas superiores más gran<strong>de</strong>s que el máximo tamaño <strong>de</strong>l paquete<br />
banda base, L2CAP los segmenta en varios paquetes banda base. La capa<br />
L2CAP <strong>de</strong>l receptor reensambla los paquetes banda base en paquetes más
gran<strong>de</strong>s para la capa superior. La conexión L2CAP permite el intercambio <strong>de</strong><br />
información referente a la calidad <strong>de</strong> la conexión, a<strong>de</strong>más maneja grupos, <strong>de</strong> tal<br />
manera que varios dispositivos pue<strong>de</strong>n comunicarse entre sí.<br />
El Sevice Discovery Protocol (SDP) o Protocolo <strong>de</strong> Descubrimiento <strong>de</strong> Servicio<br />
<strong>de</strong>fine cómo actúa <strong>una</strong> aplicación <strong>de</strong> un cliente Bluetooth para <strong>de</strong>scubrir servicios<br />
disponibles <strong>de</strong> servidores Bluetooth, a<strong>de</strong>más <strong>de</strong> proporcionar un método para<br />
<strong>de</strong>terminar las características <strong>de</strong> dichos servicios.<br />
El protocolo RFCOMM ofrece emulación <strong>de</strong> puertos seriales sobre el protocolo<br />
L2CAP. RFCOMM emula señales <strong>de</strong> control y datos RS-232 sobre la banda base<br />
Bluetooth. Éste ofrece capacida<strong>de</strong>s <strong>de</strong> transporte a servicios <strong>de</strong> capas superiores<br />
(por ejemplo OBEX) que usan <strong>una</strong> línea serial como mecanismo <strong>de</strong> transporte.<br />
RFCOMM soporta dos tipos <strong>de</strong> comunicación, directa entre dispositivos actuando<br />
como endpoints y dispositivo-mo<strong>de</strong>m-dispositivo, a<strong>de</strong>más tiene un esquema<br />
para emulación <strong>de</strong> null mo<strong>de</strong>m.<br />
El control <strong>de</strong> telefonía binario (TCS binario) es un protocolo que <strong>de</strong>fine la<br />
señalización <strong>de</strong> control <strong>de</strong> llamadas, para el establecimiento y liberación <strong>de</strong> <strong>una</strong><br />
conversación o <strong>una</strong> llamada <strong>de</strong> datos entre unida<strong>de</strong>s Bluetooth. A<strong>de</strong>más, éste<br />
ofrece funcionalidad para intercambiar información <strong>de</strong> señalización no relacionada<br />
con el progreso <strong>de</strong> llamadas.<br />
La capa <strong>de</strong> Audio es <strong>una</strong> capa especial, usada sólo para enviar audio sobre<br />
Bluetooth. Las transmisiones <strong>de</strong> audio pue<strong>de</strong>n ser ejecutadas entre <strong>una</strong> o más<br />
unida<strong>de</strong>s usando muchos mo<strong>de</strong>los diferentes. Los datos <strong>de</strong> audio no pasan a<br />
través <strong>de</strong> la capa L2CAP, pero sí directamente <strong>de</strong>spués <strong>de</strong> abrir un enlace y un<br />
establecimiento directo entre dos unida<strong>de</strong>s Bluetooth.
• Protocolos Específicos<br />
� Control <strong>de</strong> telefonía – Comandos AT. Bluetooth soporta un número <strong>de</strong><br />
comandos AT para el control <strong>de</strong> telefonía a través <strong>de</strong> emulación <strong>de</strong> puerto<br />
serial (RFCOMM).<br />
� Protocolo Punto-a-Punto (PPP). El PPP es un protocolo orientado a<br />
paquetes y por lo tanto <strong>de</strong>be usar su mecanismo serial para convertir un<br />
torrente <strong>de</strong> paquetes <strong>de</strong> datos en <strong>una</strong> corriente <strong>de</strong> datos seriales. Este<br />
protocolo corre sobre RFCOMM para lograr las conexiones punto-a-punto.<br />
� Protocolos UDP/TCP – IP. Los estándares UDP/TCP e IP permiten a las<br />
unida<strong>de</strong>s Bluetooth conectarse, por ejemplo a Internet, a través <strong>de</strong> otras<br />
unida<strong>de</strong>s conectadas. Por lo tanto, la unidad pue<strong>de</strong> actuar como un puente<br />
para Internet. La configuración TCP/IP/PPP está disponible como un<br />
transporte para WAP.<br />
� Wireless Aplication Protocol (WAP) o Protocolo <strong>de</strong> Aplicación<br />
Inalámbrica. WAP es <strong>una</strong> especificación <strong>de</strong> protocolo <strong>inalámbrica</strong> que<br />
trabaja con <strong>una</strong> amplia variedad <strong>de</strong> tecnologías <strong>de</strong> <strong>red</strong> <strong>inalámbrica</strong>s<br />
conectando dispositivos móviles a Internet. Bluetooth pue<strong>de</strong> ser usado<br />
como portador para ofrecer el transporte <strong>de</strong> datos entre el cliente WAP y su<br />
servidor <strong>de</strong> WAP adyacente. A<strong>de</strong>más, las capacida<strong>de</strong>s <strong>de</strong> <strong>red</strong> <strong>de</strong> Bluetooth<br />
dan a un cliente WAP posibilida<strong>de</strong>s únicas en cuanto a movilidad<br />
comparado con otros portadores WAP. Un ejemplo <strong>de</strong> WAP sobre Bluetooth<br />
sería un almacén que transmite ofertas especiales a un cliente WAP cuando<br />
éste entra en el rango <strong>de</strong> cobertura.<br />
� Protocolo OBEX. OBEX es un protocolo opcional <strong>de</strong> nivel <strong>de</strong> aplicación<br />
diseñado para permitir a las unida<strong>de</strong>s Bluetooth soportar comunicación
infrarroja para intercambiar <strong>una</strong> gran variedad <strong>de</strong> datos y comandos. Éste<br />
usa un mo<strong>de</strong>lo cliente-servidor y es in<strong>de</strong>pendiente <strong>de</strong>l mecanismo <strong>de</strong><br />
transporte y <strong>de</strong>l API (Application Program Interface) <strong>de</strong> transporte. OBEX<br />
usa RFCOMM como principal capa <strong>de</strong> transporte.<br />
La Figura 1-2 muestra <strong>una</strong> comparación <strong>de</strong>l stack Bluetooth con el mo<strong>de</strong>lo <strong>de</strong><br />
referencia estándar Open Systems Interconect, OSI, para stacks <strong>de</strong> protocolo<br />
<strong>de</strong> comunicaciones. A pesar <strong>de</strong> que Bluetooth no concuerda exactamente con el<br />
mo<strong>de</strong>lo, esta comparación es muy útil para relacionar las diferentes partes <strong>de</strong>l<br />
stack Bluetooth con las capas <strong>de</strong>l mo<strong>de</strong>lo OSI. Dado que el mo<strong>de</strong>lo <strong>de</strong> referencia<br />
es un stack i<strong>de</strong>al y bien particionado, la comparación sirve para resaltar la división<br />
<strong>de</strong> funciones en el stack Bluetooth.<br />
Figura 1-2. Mo<strong>de</strong>lo <strong>de</strong> referencia OSI y Bluetooth
1.1 BANDA BASE<br />
1.1.1 Descripción general. Bluetooth soporta un canal <strong>de</strong> datos asíncrono <strong>de</strong><br />
hasta tres canales <strong>de</strong> voz simultáneos. El canal asíncrono soporta comunicación<br />
simétrica y asimétrica. En la comunicación asimétrica pue<strong>de</strong>n ser enviados 723.3<br />
kb/s <strong>de</strong>s<strong>de</strong> el servidor y 57.6 kb/s hacia el servidor, mientras que en la<br />
comunicación simétrica pue<strong>de</strong>n ser enviados 433 kb/s en ambas direcciones.<br />
Bluetooth brinda conexión punto-a-punto o conexión punto-a-multipunto. Dos o<br />
más unida<strong>de</strong>s compartiendo el mismo canal forman <strong>una</strong> piconet. Cada piconet<br />
<strong>de</strong>be tener un maestro y pue<strong>de</strong> tener hasta siete esclavos activos, a<strong>de</strong>más<br />
pue<strong>de</strong>n haber muchos más esclavos en estado parked. Estos esclavos no están<br />
activos en el canal sin embargo están sincronizados con el maestro con el fin <strong>de</strong><br />
asegurar <strong>una</strong> rápida iniciación <strong>de</strong> comunicación. La interconexión <strong>de</strong> varias<br />
piconets forma <strong>una</strong> scatternet. Información más <strong>de</strong>tallada se encuentra en la<br />
especificación Bluetooth [3]. En la Figura 1-3 se pue<strong>de</strong> observar <strong>una</strong> piconet<br />
don<strong>de</strong> el PC actúa como maestro y los otros dispositivos son conectados como<br />
esclavos.<br />
Figura 1-3. Diagrama <strong>de</strong> <strong>una</strong> piconet.
1.1.2 Canal físico. El canal físico contiene 79 frecuencias <strong>de</strong> radio diferentes, las<br />
cuales son accedidas <strong>de</strong> acuerdo a <strong>una</strong> secuencia <strong>de</strong> saltos aleatoria. La rata <strong>de</strong><br />
saltos estándar es <strong>de</strong> 1600 saltos/s. El canal está dividido en timeslots (ranuras<br />
<strong>de</strong> tiempo), cada slot (ranura) correspon<strong>de</strong> a <strong>una</strong> frecuencia <strong>de</strong> salto y tiene <strong>una</strong><br />
longitud <strong>de</strong> 625 us. Cada secuencia <strong>de</strong> salto en <strong>una</strong> piconet está <strong>de</strong>terminada por<br />
la dirección <strong>de</strong>l maestro <strong>de</strong> la piconet. Todos los dispositivos conectados a la<br />
piconet están sincronizados con el canal en salto y tiempo. En <strong>una</strong> transmisión,<br />
cada paquete <strong>de</strong>be estar alineado con el inicio <strong>de</strong> un slot y pue<strong>de</strong> tener <strong>una</strong><br />
duración <strong>de</strong> hasta cinco timeslots. Durante la transmisión <strong>de</strong> un paquete la<br />
frecuencia es fija. Para evitar fallas en la transmisión, el maestro inicia enviando<br />
en los timeslots pares y los esclavos en los timeslots impares [3]. En la Figura 1-<br />
4 se pue<strong>de</strong> observar este esquema <strong>de</strong> transmisión.<br />
Figura 1-4. Transmisión en <strong>una</strong> piconet.<br />
1.1.3 Enlace físico. La comunicación sobre Bluetooth es perfecta para enlaces<br />
SCO o enlaces ACL. El enlace SCO es <strong>una</strong> conexión simétrica punto-a-punto<br />
entre el maestro y un esclavo específico. Para lograr la comunicación, el enlace<br />
SCO reserva slots en intervalos regulares en la iniciación, por esto el enlace
pue<strong>de</strong> ser consi<strong>de</strong>rado como <strong>una</strong> conexión <strong>de</strong> conmutación <strong>de</strong> circuitos. El enlace<br />
ACL es un enlace punto-a-multipunto entre el maestro y uno o más esclavos<br />
activos en la piconet. Este enlace <strong>de</strong> comunicación es un tipo <strong>de</strong> conexión <strong>de</strong><br />
conmutación <strong>de</strong> paquetes. Todos los paquetes son retransmitidos para asegurar la<br />
integridad <strong>de</strong> los datos. El maestro pue<strong>de</strong> enviar mensajes broadcast (<strong>de</strong><br />
difusión) a todos los esclavos conectados <strong>de</strong>jando vacía la dirección <strong>de</strong>l paquete,<br />
así todos los esclavos leerán el paquete [3].<br />
1.1.4 Paquetes. Los datos enviados sobre el canal <strong>de</strong> la piconet son convertidos<br />
en paquetes, éstos son enviados y el receptor los recibe iniciando por el bit menos<br />
significativo. Como se observa en la Figura 1-5, el formato <strong>de</strong> paquete general<br />
consta <strong>de</strong> tres campos: código <strong>de</strong> acceso, cabecera y carga útil [3].<br />
Figura 1-5. Formato <strong>de</strong> paquete general<br />
• Código <strong>de</strong> acceso. Es usado para sincronización e i<strong>de</strong>ntificación. Todos los<br />
paquetes comunes que son enviados sobre el canal <strong>de</strong> la piconet están<br />
precedidos <strong>de</strong>l mismo código <strong>de</strong> acceso al canal. Existen tres tipos diferentes <strong>de</strong><br />
código <strong>de</strong> acceso:<br />
� Código <strong>de</strong> acceso al canal - Para i<strong>de</strong>ntificar los paquetes sobre el canal<br />
<strong>de</strong> la piconet.
� Código <strong>de</strong> acceso <strong>de</strong> dispositivo – Para procedimientos <strong>de</strong> señalización<br />
especiales, paging (servicio para transferencia <strong>de</strong> señalización o<br />
información en un sentido), entre otros.<br />
� Código <strong>de</strong> Acceso <strong>de</strong> Búsqueda (IAC) – llamado IAC general cuando se<br />
quiere <strong>de</strong>scubrir a otras unida<strong>de</strong>s Bluetooth <strong>de</strong>ntro <strong>de</strong>l rango, o IAC<br />
<strong>de</strong>dicado cuando se <strong>de</strong>sea <strong>de</strong>scubrir unida<strong>de</strong>s <strong>de</strong> un tipo específico.<br />
• Cabecera <strong>de</strong> paquete. Como se observa en la Figura 1-6, la cabecera <strong>de</strong><br />
paquete consta <strong>de</strong> seis campos:<br />
� Dirección – Una dirección <strong>de</strong> dispositivo para distinguirlo <strong>de</strong> los <strong>de</strong>más<br />
dispositivos activos en la piconet.<br />
� Tipo – Define qué tipo <strong>de</strong> paquete es enviado.<br />
� Flujo – El bit <strong>de</strong> control <strong>de</strong> flujo es usado para notificar al emisor cuándo el<br />
buffer <strong>de</strong>l receptor está lleno.<br />
� ARQN – Acknowledge Receive Data o reconocimiento <strong>de</strong> datos recibidos.<br />
� SEQN – Sequential Numbering o numeración secuencial para or<strong>de</strong>nar los<br />
datos sobre el canal.<br />
� HEC – Chequeo <strong>de</strong> <strong>red</strong>undancia cíclica <strong>de</strong> cabecera.
Figura 1-6. Formato <strong>de</strong> cabecera <strong>de</strong> paquete<br />
• Carga útil. La carga útil <strong>de</strong> un paquete pue<strong>de</strong> ser dividida en dos campos:<br />
� Campo <strong>de</strong> Voz – Consta <strong>de</strong> datos <strong>de</strong> voz <strong>de</strong> longitud fija y existe en<br />
paquetes <strong>de</strong> alta calidad <strong>de</strong> voz y paquetes combinados <strong>de</strong> datos-voz. No<br />
es necesaria ning<strong>una</strong> cabecera <strong>de</strong> carga útil.<br />
� Campo <strong>de</strong> Datos – Consta <strong>de</strong> tres partes, cabecera <strong>de</strong> carga útil, datos <strong>de</strong><br />
carga útil, y código CRC.<br />
1.1.5 Corrección <strong>de</strong> errores. En <strong>una</strong> comunicación Bluetooth existen varios<br />
esquemas diferentes <strong>de</strong> corrección <strong>de</strong> errores [3]:<br />
• En la cabecera, cada bit es repetido tres veces.<br />
• En la carga útil se usa un esquema <strong>de</strong> código Hamming. Los bits <strong>de</strong><br />
información son agrupados en secuencias <strong>de</strong> 10 bits, éstos son enviados<br />
como 15 bits y el algoritmo corrige todos los errores <strong>de</strong> un bit y <strong>de</strong>tecta los<br />
errores <strong>de</strong> dos bits.<br />
• Para garantizar <strong>una</strong> recepción correcta, todos los paquetes <strong>de</strong> datos son<br />
retransmitidos hasta que el emisor reciba <strong>una</strong> confirmación. La confirmación<br />
es enviada en la cabecera <strong>de</strong> los paquetes retornados.
• Los paquetes broadcast son paquetes transmitidos <strong>de</strong>s<strong>de</strong> el maestro a<br />
todos los esclavos. No hay posibilidad <strong>de</strong> usar confirmación para esta<br />
comunicación, sin embargo, para incrementar la posibilidad <strong>de</strong> recibir<br />
correctamente un paquete, cada bit en el paquete es repetido un número<br />
fijo <strong>de</strong> veces.<br />
• El chequeo <strong>de</strong> <strong>red</strong>undancia cíclica (CRC) se usa para <strong>de</strong>tectar errores en la<br />
cabecera. La suma <strong>de</strong> comprobación CRC está contenida en el campo HEC<br />
<strong>de</strong> la cabecera <strong>de</strong> paquete. Los chequeos <strong>de</strong> <strong>red</strong>undancia cíclica también<br />
se aplican sobre la carga útil en la mayoría <strong>de</strong> los paquetes.<br />
• Para asegurar que no <strong>de</strong>saparezcan paquetes completos, Bluetooth usa<br />
números <strong>de</strong> secuencia. Actualmente sólo se usa un número <strong>de</strong> secuencia<br />
<strong>de</strong> un bit.<br />
1.1.6 Transmisión/Recepción. Como se mencionó antes, el maestro <strong>de</strong> la<br />
piconet empieza enviando en timeslots pares y el esclavo en los impares.<br />
Solamente el último esclavo direccionado está autorizado para enviar en el<br />
timeslot <strong>de</strong> los esclavos. Esto no causa problemas ya que el maestro siempre<br />
está inicializando todas las conexiones y transmisiones nuevas. Cada esclavo<br />
espera las oportunida<strong>de</strong>s <strong>de</strong> conexión dadas por el maestro. Los paquetes pue<strong>de</strong>n<br />
ser más gran<strong>de</strong>s que un timeslot, <strong>de</strong>bido a esto el maestro pue<strong>de</strong> continuar<br />
enviando en los timeslots impares y viceversa. El sistema <strong>de</strong> reloj <strong>de</strong>l maestro<br />
sincroniza a toda la piconet. El maestro nunca ajusta su sistema <strong>de</strong> reloj durante la<br />
existencia <strong>de</strong> <strong>una</strong> piconet, son los esclavos quienes adaptan sus relojes con un<br />
offset <strong>de</strong> tiempo con el fin <strong>de</strong> igualarse con el reloj <strong>de</strong>l maestro. Este offset es<br />
actualizado cada vez que es recibido un paquete <strong>de</strong>s<strong>de</strong> el maestro.
1.1.7 Control <strong>de</strong> Canal. El control <strong>de</strong> canal <strong>de</strong>scribe cómo se establece el canal<br />
<strong>de</strong> <strong>una</strong> piconet y cómo las unida<strong>de</strong>s pue<strong>de</strong>n ser adicionadas o liberadas en la<br />
piconet. La dirección <strong>de</strong>l maestro <strong>de</strong>termina la secuencia <strong>de</strong> saltos y el código <strong>de</strong><br />
acceso al canal. La fase <strong>de</strong> la piconet está <strong>de</strong>terminada por el sistema <strong>de</strong> reloj <strong>de</strong>l<br />
maestro. Por <strong>de</strong>finición, la unidad Bluetooth que inicia la conexión representa al<br />
maestro.<br />
En Bluetooth, la capa <strong>de</strong> control <strong>de</strong> enlace se divi<strong>de</strong> en dos estados principales:<br />
standby y conexión. A<strong>de</strong>más existen siete sub-estados: page, page scan,<br />
inquiry (búsqueda), inquiry scan, respuesta <strong>de</strong> maestro, respuesta <strong>de</strong> esclavo y<br />
respuesta a inquiry. Los sub-estados son usados para agregar nuevos esclavos a<br />
<strong>una</strong> piconet [3]. Para moverse <strong>de</strong> un estado a otro se usan comandos <strong>de</strong> capas<br />
más altas o señales internas.<br />
En Bluetooth se <strong>de</strong>fine un procedimiento <strong>de</strong> búsqueda que se usa en aplicaciones<br />
don<strong>de</strong> la dirección <strong>de</strong>l dispositivo <strong>de</strong> <strong>de</strong>stino es <strong>de</strong>sconocida para la fuente. Esto<br />
pue<strong>de</strong> ser usado para <strong>de</strong>scubrir qué otras unida<strong>de</strong>s Bluetooth están <strong>de</strong>ntro <strong>de</strong>l<br />
rango. Durante un sub-estado <strong>de</strong> inquiry o búsqueda, la unidad <strong>de</strong><br />
<strong>de</strong>scubrimiento recoge la dirección <strong>de</strong>l dispositivo y el reloj <strong>de</strong> todas las unida<strong>de</strong>s<br />
que respondan al mensaje <strong>de</strong> búsqueda, entonces la unidad pue<strong>de</strong> iniciar <strong>una</strong><br />
conexión con alg<strong>una</strong> <strong>de</strong> las unida<strong>de</strong>s <strong>de</strong>scubiertas. El mensaje <strong>de</strong> búsqueda<br />
difundido por la fuente no contiene información <strong>de</strong> ella, sin embargo, pue<strong>de</strong> indicar<br />
qué clase <strong>de</strong> dispositivos <strong>de</strong>berían respon<strong>de</strong>r. Una unidad que permita ser<br />
<strong>de</strong>scubierta, regularmente entra en un sub-estado <strong>de</strong> inquiry scan para respon<strong>de</strong>r<br />
a los mensajes <strong>de</strong> búsqueda.
Existen dos formas <strong>de</strong> <strong>de</strong>tectar otras unida<strong>de</strong>s. La primera, <strong>de</strong>tecta todas las otras<br />
unida<strong>de</strong>s en el rango <strong>de</strong> cobertura, y la segunda, <strong>de</strong>tecta un tipo específico <strong>de</strong><br />
unida<strong>de</strong>s. Los esclavos que se encuentran en el sub-estado <strong>de</strong> page scan,<br />
escuchan esperando su propio código <strong>de</strong> acceso <strong>de</strong> dispositivo. El maestro en el<br />
sub-estado page activa y conectan a un esclavo. El maestro trata <strong>de</strong> capturar al<br />
esclavo transmitiendo repetidamente el código <strong>de</strong> acceso <strong>de</strong> dispositivo en<br />
diferentes canales <strong>de</strong> salto. Debido a que los relojes <strong>de</strong>l maestro y <strong>de</strong>l esclavo no<br />
están sincronizados, el maestro no sabe exactamente cuándo y en qué frecuencia<br />
<strong>de</strong> salto se activará el esclavo.<br />
Después <strong>de</strong> haber recibido su propio código <strong>de</strong> acceso <strong>de</strong> dispositivo, el esclavo<br />
transmite un mensaje <strong>de</strong> respuesta. Este mensaje <strong>de</strong> respuesta es simplemente el<br />
código <strong>de</strong> acceso <strong>de</strong> dispositivo <strong>de</strong>l esclavo. Cuando el maestro ha recibido este<br />
paquete, envía un paquete <strong>de</strong> control con información acerca <strong>de</strong> su reloj,<br />
dirección, clase <strong>de</strong> dispositivo, etc... El esclavo respon<strong>de</strong> con un nuevo mensaje<br />
don<strong>de</strong> envía su dirección. Si el maestro no obtiene esta respuesta en un<br />
<strong>de</strong>terminado tiempo, él reenvía el paquete <strong>de</strong> control. Si el esclavo exce<strong>de</strong> el<br />
tiempo <strong>de</strong> espera, entonces retorna al sub-estado <strong>de</strong> page scan. Si es el maestro<br />
quien lo exce<strong>de</strong>, entonces retorna al sub-estado <strong>de</strong> page e informa a las capas<br />
superiores.<br />
Cuando se establece la conexión, la comunicación inicia con un paquete <strong>de</strong><br />
son<strong>de</strong>o <strong>de</strong>s<strong>de</strong> el maestro hacia el esclavo. Como respuesta se envía un nuevo<br />
paquete <strong>de</strong> son<strong>de</strong>o y <strong>de</strong> esta forma se verifica que la secuencia <strong>de</strong> salto y la<br />
sincronización sean correctas. La Figura 1-7 muestra la inicialización <strong>de</strong> la<br />
comunicación sobre el nivel banda base.
Cada transceiver (receptor-transmisor) Bluetooth tiene <strong>una</strong> única dirección <strong>de</strong><br />
dispositivo <strong>de</strong> 48 bits asignada, la cual está dividida en tres campos: campo LAP,<br />
campo UAP y campo NAP [3]. Los campos LAP y UAP forman la parte significativa<br />
<strong>de</strong>l código <strong>de</strong> acceso. En la Figura 1-8 se pue<strong>de</strong> observar el formato <strong>de</strong> la<br />
dirección para un dispositivo Bluetooth. La dirección <strong>de</strong>l dispositivo es conocida<br />
públicamente y pue<strong>de</strong> ser obtenida a través <strong>de</strong> <strong>una</strong> rutina inquiry.<br />
Figura 1-7. Iniciación <strong>de</strong> comunicación sobre el nivel banda base<br />
Figura 1-8. Dirección <strong>de</strong> dispositivo Bluetooth
1.1.8 Seguridad en Bluetooth. Con el fin <strong>de</strong> brindar protección y confi<strong>de</strong>ncialidad<br />
a la información, el sistema <strong>de</strong>be ofrecer medidas <strong>de</strong> seguridad en las dos capas,<br />
la <strong>de</strong> aplicación y <strong>de</strong> enlace. Todas las unida<strong>de</strong>s Bluetooth tienen implementadas<br />
las mismas rutinas <strong>de</strong> autenticación y encriptación. En la capa <strong>de</strong> enlace, estas<br />
rutinas constan <strong>de</strong> cuatro entida<strong>de</strong>s diferentes: <strong>una</strong> única dirección pública, dos<br />
llaves secretas y un número aleatorio el cual es diferente para cada transacción.<br />
Solamente es encriptada la carga útil. El código <strong>de</strong> acceso y la cabecera <strong>de</strong><br />
paquete nunca son encriptados.<br />
Cada tipo <strong>de</strong> unidad Bluetooth tiene <strong>una</strong> rutina <strong>de</strong> autenticación común. El maestro<br />
genera un número aleatorio y lo envía al esclavo, el esclavo usa este número y su<br />
propia i<strong>de</strong>ntidad para calcular el número <strong>de</strong> autenticación. Luego, este número es<br />
enviado al maestro quien hace el mismo cálculo. Si los dos números generados<br />
son iguales entonces la autenticación es concedida.<br />
La encriptación, frecuentemente está restringida por leyes <strong>de</strong> varios países. Para<br />
evitar estas limitaciones, en Bluetooth la llave <strong>de</strong> encriptación no es estática, ésta<br />
es <strong>de</strong>ducida <strong>de</strong> la llave <strong>de</strong> autenticación cada vez que se activa la encriptación [3].<br />
1.2 PROTOCOLO DE GESTIÓN DE ENLACE (LMP)<br />
En el protocolo <strong>de</strong> gestión <strong>de</strong> enlace, LMP, se usan mensajes asociados con el<br />
establecimiento, seguridad y control. Los mensajes son enviados en la carga útil y<br />
no en los mensajes <strong>de</strong> datos <strong>de</strong> L2CAP. Los mensajes LMP son separados <strong>de</strong> los<br />
<strong>de</strong>más por medio <strong>de</strong> un valor reservado en uno <strong>de</strong> los campos <strong>de</strong> la cabecera <strong>de</strong><br />
carga útil. Todos los mensajes LMP son extraídos e interpretados por la capa LMP<br />
<strong>de</strong>l receptor, esto significa que ningún mensaje es enviado a capas superiores.<br />
Los mensajes LMP tienen mayor prioridad que los datos <strong>de</strong> usuario, esto significa<br />
que si la gestión <strong>de</strong> enlace necesita enviar un mensaje, éste no <strong>de</strong>be ser retrasado<br />
por otro tráfico. Solamente las retransmisiones <strong>de</strong> los paquetes <strong>de</strong>l nivel <strong>de</strong> banda
ase pue<strong>de</strong>n retrasar los mensajes LMP. A<strong>de</strong>más, éstos no necesitan rutinas <strong>de</strong><br />
reconocimiento ya que la capa banda base asegura un enlace confiable [3]. El<br />
protocolo <strong>de</strong> gestión enlace soporta mensajes para:<br />
• Autenticación<br />
• Paridad<br />
• Encriptación<br />
• Temporización y sincronización<br />
• Versión y características<br />
• Switch para <strong>de</strong>sempeño como maestro o esclavo <strong>de</strong>pendiendo <strong>de</strong> si el<br />
dispositivo es quien inicia (maestro) o no (esclavo) el enlace con otro<br />
dispositivo.<br />
• Petición <strong>de</strong> nombre<br />
• Desconexión<br />
• Modo hold: el maestro or<strong>de</strong>na al esclavo entrar en este estado para ahorro<br />
<strong>de</strong> potencia.<br />
• Modo sniff: para envío <strong>de</strong> mensajes en timeslots específicos.<br />
• Modo park: para que el esclavo permanezca inactivo pero sincronizado en<br />
la piconet.<br />
• Enlaces SCO<br />
• Control <strong>de</strong> paquetes multi-slot<br />
• Supervisión <strong>de</strong> enlace<br />
1.2.1 Establecimiento <strong>de</strong> conexión. Después <strong>de</strong>l procedimiento paging, el<br />
maestro <strong>de</strong>be encuestar al esclavo enviando paquetes <strong>de</strong> son<strong>de</strong>o. El otro lado<br />
recibe este mensaje y lo acepta o rechaza, si es aceptado, la comunicación<br />
incluyendo las capas superiores están disponibles (ver Figura 1-9).
Figura 1-9. Establecimiento <strong>de</strong> la conexión<br />
1.3 INTERFAZ DEL CONTROLADOR DE HOST (HCI)<br />
La HCI proporciona <strong>una</strong> interfaz <strong>de</strong> comando al controlador banda base y a la<br />
gestión <strong>de</strong> enlace, a<strong>de</strong>más <strong>de</strong> acceso al hardware y a los registros <strong>de</strong> control. Esta<br />
interfaz brinda un método estándar para acce<strong>de</strong>r a los recursos <strong>de</strong> banda base<br />
Bluetooth [3].<br />
1.3.1 Capas mas bajas <strong>de</strong>l stack Bluetooth. A continuación se hace <strong>una</strong> breve<br />
<strong>de</strong>scripción <strong>de</strong> las capas más bajas <strong>de</strong>l stack <strong>de</strong> software y hardware Bluetooth.<br />
La Figura 1-10 da <strong>una</strong> i<strong>de</strong>a <strong>de</strong> estas capas.
Figura 1-10. Diagrama general <strong>de</strong> las capas más bajas<br />
El firmware HCI implementa los comandos HCI para el hardware a través <strong>de</strong>l<br />
acceso <strong>de</strong> comandos banda base, comandos <strong>de</strong> la gestión <strong>de</strong> enlace, hardware <strong>de</strong><br />
registros <strong>de</strong> estado, registros <strong>de</strong> control y registros <strong>de</strong> eventos. La Figura 1-11<br />
muestra el recorrido <strong>de</strong> un dato transferido <strong>de</strong> un dispositivo a otro. El driver HCI<br />
(en el host) intercambia datos y comandos con el firmware HCI (en el hardware).<br />
El driver <strong>de</strong> la capa <strong>de</strong> transporte, por ejemplo un bus físico, brinda a las dos<br />
capas HCI la posibilidad <strong>de</strong> intercambiar información.
Figura 1-11. Diagrama general end to end <strong>de</strong> las capas <strong>de</strong> software más bajas<br />
1.3.2 Posibles arquitecturas <strong>de</strong> bus físico. Los dispositivos Bluetooth tienen<br />
varias interfaces <strong>de</strong> bus físicas que pue<strong>de</strong>n ser usadas para conectar el hardware.<br />
Estos buses pue<strong>de</strong>n tener diferentes arquitecturas y parámetros. El controlador <strong>de</strong><br />
host soporta tres arquitecturas <strong>de</strong> bus físico, USB, UART y PC Card. Todas ellas<br />
pue<strong>de</strong>n manejar varios canales lógicos sobre el mismo canal físico simple (a<br />
través <strong>de</strong> endpoints), por lo tanto los canales <strong>de</strong> control, datos y voz no requieren<br />
alg<strong>una</strong> interfaz física adicional.<br />
El objetivo principal <strong>de</strong> la capa <strong>de</strong> transporte <strong>de</strong>l controlador <strong>de</strong> host es la<br />
transparencia entre el driver <strong>de</strong>l controlador <strong>de</strong> host y el controlador <strong>de</strong> host.
1.4 PROTOCOLO DE CONTROL Y ADAPTACIÓN DE ENLACE<br />
LÓGICO (L2CAP)<br />
L2CAP se encuentra sobre el protocolo <strong>de</strong> gestión <strong>de</strong> enlace (LMP) y resi<strong>de</strong> en la<br />
capa <strong>de</strong> enlace <strong>de</strong> datos. L2CAP permite a protocolos <strong>de</strong> niveles superiores y a<br />
aplicaciones la transmisión y recepción <strong>de</strong> paquetes <strong>de</strong> datos L2CAP <strong>de</strong> hasta 64<br />
kilobytes, con capacidad <strong>de</strong> multiplexación <strong>de</strong> protocolo, operación <strong>de</strong><br />
segmentación y reensamble, y abstracción <strong>de</strong> grupos. Para cumplir sus funciones,<br />
L2CAP espera que la banda base suministre paquetes <strong>de</strong> datos en full duplex,<br />
que realice el chequeo <strong>de</strong> integridad <strong>de</strong> los datos y que reenvíe los datos hasta<br />
que hayan sido reconocidos satisfactoriamente. Las capas superiores que se<br />
comunican con L2CAP son por ejemplo el protocolo <strong>de</strong> <strong>de</strong>scubrimiento <strong>de</strong> servicio<br />
(SDP), el RFCOMM y el control <strong>de</strong> telefonía (TCS) [3].<br />
1.4.1 Canales. L2CAP está basado en el concepto <strong>de</strong> canales. Se asocia un<br />
i<strong>de</strong>ntificador <strong>de</strong> canal, CID, a cada uno <strong>de</strong> los endpoints <strong>de</strong> un canal L2CAP. Los<br />
CIDs están divididos en dos grupos, uno con i<strong>de</strong>ntificadores reservados para<br />
funciones L2CAP y otro con i<strong>de</strong>ntificadores libres para implementaciones<br />
particulares. Los canales <strong>de</strong> datos orientados a la conexión representan <strong>una</strong><br />
conexión entre dos dispositivos, don<strong>de</strong> un CID i<strong>de</strong>ntifica cada endpoint <strong>de</strong>l canal.<br />
Los canales no orientados a la conexión limitan el flujo <strong>de</strong> datos a <strong>una</strong> sola<br />
dirección. La señalización <strong>de</strong> canal es un ejemplo <strong>de</strong> un canal reservado. Este<br />
canal es usado para crear y establecer canales <strong>de</strong> datos orientados a la conexión<br />
y para negociar cambios en las características <strong>de</strong> esos canales.<br />
1.4.2 Operaciones entre Capas. Las implementaciones L2CAP <strong>de</strong>ben transferir<br />
datos entre protocolos <strong>de</strong> capas superiores e inferiores. Cada <strong>implementación</strong><br />
<strong>de</strong>be soportar un grupo <strong>de</strong> comandos <strong>de</strong> señalización, a<strong>de</strong>más, <strong>de</strong>be ser capaz <strong>de</strong>
aceptar ciertos tipos <strong>de</strong> eventos <strong>de</strong> capas inferiores y generar eventos para capas<br />
superiores. En la Figura 1-12 se muestra esta arquitectura.<br />
Figura 1-12. Arquitectura L2CAP<br />
1.4.3 Segmentación y Reensamblado. Los paquetes <strong>de</strong> datos <strong>de</strong>finidos por el<br />
protocolo banda base están limitados en tamaño. Los paquetes L2CAP gran<strong>de</strong>s<br />
<strong>de</strong>ben ser segmentados en varios paquetes banda base más pequeños antes <strong>de</strong><br />
transmitirse y luego <strong>de</strong>ben ser enviados a la gestión <strong>de</strong> enlace. En el receptor los<br />
pequeños paquetes recibidos <strong>de</strong> la banda base son reensamblados en paquetes<br />
L2CAP más gran<strong>de</strong>s. Varios paquetes banda base recibidos pue<strong>de</strong>n ser<br />
reensamblados en un solo paquete L2CAP seguido <strong>de</strong> un simple chequeo <strong>de</strong><br />
integridad. La segmentación y reensamblado, SAR, funcionalmente es<br />
absolutamente necesaria para soportar protocolos usando paquetes más gran<strong>de</strong>s<br />
que los soportados por la banda base. La Figura 1-13 muestra la segmentación<br />
L2CAP.
Figura 1-13. Segmentación L2CAP<br />
1.4.4 Eventos. Todos los mensajes y timeouts que entran en la capa L2CAP,<br />
son llamados eventos. Los eventos se encuentran divididos en cinco categorías:<br />
indicaciones y confirmaciones <strong>de</strong> capas inferiores, peticiones <strong>de</strong> señal y<br />
respuestas <strong>de</strong> capas L2CAP, datos <strong>de</strong> capas L2CAP, peticiones y respuestas <strong>de</strong><br />
capas superiores, y eventos causados por expiraciones <strong>de</strong> tiempo.<br />
1.4.5 Acciones. Todos los mensajes y timeouts enviados <strong>de</strong>s<strong>de</strong> la capa L2CAP<br />
son llamados acciones (en el lado <strong>de</strong>l receptor estas acciones son llamadas<br />
eventos). Las acciones se encuentran divididas en cinco categorías: peticiones y<br />
respuestas a capas inferiores, peticiones y respuestas a capas L2CAP, datos a<br />
capas L2CAP, indicaciones a capas superiores, y configuración <strong>de</strong> timers.<br />
1.4.6 Formato <strong>de</strong>l paquete <strong>de</strong> datos. L2CAP está basado en paquetes pero<br />
sigue un mo<strong>de</strong>lo <strong>de</strong> comunicación basado en canales. Un canal representa un<br />
flujo <strong>de</strong> datos entre entida<strong>de</strong>s L2CAP en dispositivos remotos. Los canales pue<strong>de</strong>n<br />
ser o no orientados a la conexión. Como se pue<strong>de</strong> observar en la Figura 1-14, los<br />
paquetes <strong>de</strong> canal orientado a la conexión están divididos en tres campos:<br />
longitud <strong>de</strong> la información, i<strong>de</strong>ntificador <strong>de</strong> canal, e información.
Figura 1-14. Paquete L2CAP<br />
Los paquetes <strong>de</strong> canal <strong>de</strong> datos no orientados a la conexión son iguales a los<br />
paquetes orientados a la conexión pero adicionalmente incluyen un campo con<br />
información multiplexada <strong>de</strong> protocolo y servicio.<br />
1.4.7 Calidad <strong>de</strong> servicio (QoS). La capa L2CAP transporta la información <strong>de</strong><br />
calidad <strong>de</strong> servicio a través <strong>de</strong> los canales y brinda control <strong>de</strong> admisión para evitar<br />
que canales adicionales violen contratos <strong>de</strong> calidad <strong>de</strong> servicio existentes.<br />
Algunos esclavos pue<strong>de</strong>n requerir un alto rendimiento o <strong>una</strong> respuesta rápida.<br />
Antes <strong>de</strong> que un esclavo con gran<strong>de</strong>s peticiones sea conectado a <strong>una</strong> piconet, el<br />
esclavo trata <strong>de</strong> obtener <strong>una</strong> garantía a sus <strong>de</strong>mandas. Pue<strong>de</strong> solicitar <strong>una</strong><br />
<strong>de</strong>terminada rata <strong>de</strong> transmisión, tamaño <strong>de</strong>l buffer <strong>de</strong> tráfico, ancho <strong>de</strong> banda,<br />
tiempo <strong>de</strong> recuperación <strong>de</strong> datos, etc. Por lo tanto, antes <strong>de</strong> que el maestro<br />
conecte a un nuevo esclavo o actualice la configuración <strong>de</strong> calidad, <strong>de</strong>be chequear<br />
si posee timeslots y otros recursos libres.
1.5 PROTOCOLO DE DESCUBRIMIENTO DE SERVICIO (SDP)<br />
El protocolo <strong>de</strong> <strong>de</strong>scubrimiento <strong>de</strong> servicio, SDP, brinda a las aplicaciones<br />
recursos para <strong>de</strong>scubrir qué servicios están disponibles y <strong>de</strong>terminar las<br />
características <strong>de</strong> dichos servicios.<br />
1.5.1 Descripción General. Un servicio es <strong>una</strong> entidad que pue<strong>de</strong> brindar<br />
información, ejecutar <strong>una</strong> acción o controlar un recurso a nombre <strong>de</strong> otra entidad.<br />
El SDP ofrece a los clientes la facilidad <strong>de</strong> averiguar sobre servicios que sean<br />
requeridos, basándose en la clase <strong>de</strong> servicio o propieda<strong>de</strong>s específicas <strong>de</strong> estos<br />
servicios. Para hacer más fácil la búsqueda, el SDP la habilita sin un previo<br />
conocimiento <strong>de</strong> las características específicas <strong>de</strong> los servicios. Las unida<strong>de</strong>s<br />
Bluetooth que usan el SDP pue<strong>de</strong>n ser vistas como un servidor y un cliente. El<br />
servidor posee los servicios y el cliente es quien <strong>de</strong>sea acce<strong>de</strong>r a ellos. En el SDP<br />
esto es posible ya que el cliente envía <strong>una</strong> petición al servidor y el servidor<br />
respon<strong>de</strong> con un mensaje. El SDP solamente soporta el <strong>de</strong>scubrimiento <strong>de</strong>l<br />
servicio, no la llamada <strong>de</strong>l servicio [3].<br />
1.5.2 Registros <strong>de</strong> servicio. Los registros <strong>de</strong> servicio contienen propieda<strong>de</strong>s<br />
que <strong>de</strong>scriben un servicio <strong>de</strong>terminado. Cada propiedad <strong>de</strong> un registro <strong>de</strong> servicio<br />
consta <strong>de</strong> dos partes, un i<strong>de</strong>ntificador <strong>de</strong> propiedad y un valor <strong>de</strong> propiedad. El<br />
i<strong>de</strong>ntificador <strong>de</strong> propiedad es un número único <strong>de</strong> 16 bits que distingue cada<br />
propiedad <strong>de</strong> servicio <strong>de</strong> otro <strong>de</strong>ntro <strong>de</strong> un registro. El valor <strong>de</strong> propiedad es un<br />
campo <strong>de</strong> longitud variable que contiene la información.<br />
1.5.3 El protocolo. El protocolo <strong>de</strong> <strong>de</strong>scubrimiento <strong>de</strong> servicio (SDP) usa un<br />
mo<strong>de</strong>lo petición/respuesta. En la Figura 1-15 se muestra el procedimiento SDP.<br />
Note que las flechas no continuas no forman parte <strong>de</strong> éste.
• Petición <strong>de</strong> búsqueda <strong>de</strong> servicio: se genera por el cliente para localizar<br />
registros <strong>de</strong> servicio que concuer<strong>de</strong>n con un patrón <strong>de</strong> búsqueda dado<br />
como parámetro. Aquí el servidor examina los registros en su base <strong>de</strong> datos<br />
y respon<strong>de</strong> con <strong>una</strong> respuesta a búsqueda <strong>de</strong> servicio.<br />
• Respuesta a búsqueda <strong>de</strong> servicio: se genera por el servidor <strong>de</strong>spués <strong>de</strong><br />
recibir <strong>una</strong> petición <strong>de</strong> búsqueda <strong>de</strong> servicio válida.<br />
• Petición <strong>de</strong> propiedad <strong>de</strong> servicio: <strong>una</strong> vez el cliente ya ha recibido los<br />
servicios <strong>de</strong>seados, pue<strong>de</strong> obtener mayor información <strong>de</strong> uno <strong>de</strong> ellos<br />
dando como parámetros el registro <strong>de</strong> servicio y <strong>una</strong> lista <strong>de</strong> propieda<strong>de</strong>s<br />
<strong>de</strong>seadas.<br />
• Respuesta a propiedad <strong>de</strong> servicio: El SDP genera <strong>una</strong> respuesta a <strong>una</strong><br />
petición <strong>de</strong> propiedad <strong>de</strong> servicio. Ésta contiene <strong>una</strong> lista <strong>de</strong> propieda<strong>de</strong>s<br />
<strong>de</strong>l registro requerido.<br />
• Petición <strong>de</strong> búsqueda y propiedad <strong>de</strong> servicio: se suministran un patrón<br />
<strong>de</strong> servicio con servicios <strong>de</strong>seados y <strong>una</strong> lista <strong>de</strong> propieda<strong>de</strong>s <strong>de</strong>seadas que<br />
concuer<strong>de</strong>n con la búsqueda.<br />
• Respuesta <strong>de</strong> búsqueda y propiedad <strong>de</strong> servicio: como resultado se<br />
pue<strong>de</strong> obtener <strong>una</strong> lista <strong>de</strong> servicios que concuer<strong>de</strong>n con un patrón dado y<br />
las propieda<strong>de</strong>s <strong>de</strong>seadas <strong>de</strong> estos servicios.
1.6 RFCOMM<br />
El protocolo RFCOMM brinda emulación <strong>de</strong> puertos seriales sobre el protocolo<br />
L2CAP. La capa RFCOMM es <strong>una</strong> simple capa <strong>de</strong> transporte provista<br />
adicionalmente <strong>de</strong> emulación <strong>de</strong> circuitos <strong>de</strong> puerto serial RS-232. El protocolo<br />
RFCOMM soporta hasta 60 puertos emulados simultáneamente. Dos unida<strong>de</strong>s<br />
Bluetooth que usen RFCOMM en su comunicación pue<strong>de</strong>n abrir varios puertos<br />
seriales emulados, los cuales son multiplexados entre sí. La Figura 1-15 muestra<br />
el esquema <strong>de</strong> emulación para varios puertos seriales.<br />
Figura 1-15. Varios puertos seriales emulados mediante RFCOMM<br />
Muchas aplicaciones hacen uso <strong>de</strong> puertos seriales. El RFCOMM está orientado a<br />
hacer más flexibles estos dispositivos, soportando fácil adaptación <strong>de</strong><br />
comunicación Bluetooth. Un ejemplo <strong>de</strong> <strong>una</strong> aplicación <strong>de</strong> comunicación serial es<br />
el protocolo punto-a-punto (PPP). El RFCOMM tiene construido un esquema para<br />
emulación <strong>de</strong> null mo<strong>de</strong>m y usa a L2CAP para cumplir con el control <strong>de</strong> flujo<br />
requerido por alg<strong>una</strong> aplicación [3].
1.7 PERFILES BLUETOOTH<br />
El estándar Bluetooth fue creado para ser usado por un gran número <strong>de</strong><br />
fabricantes e implementado en áreas ilimitadas. Para asegurar que todos los<br />
dispositivos que usen Bluetooth sean compatibles entre sí son necesarios<br />
esquemas estándar <strong>de</strong> comunicación en las principales áreas. Para evitar<br />
diferentes interpretaciones <strong>de</strong>l estándar Bluetooth acerca <strong>de</strong> cómo un tipo<br />
específico <strong>de</strong> aplicación <strong>de</strong>bería ser implementado, el Bluetooth Special Interest<br />
Group (SIG), ha <strong>de</strong>finido mo<strong>de</strong>los <strong>de</strong> usuario y perfiles <strong>de</strong> protocolo. Un perfil<br />
<strong>de</strong>fine <strong>una</strong> selección <strong>de</strong> mensajes y procedimientos <strong>de</strong> las especificaciones<br />
Bluetooth y ofrece <strong>una</strong> <strong>de</strong>scripción clara <strong>de</strong> la interfaz <strong>de</strong> aire para servicios<br />
específicos. Un perfil pue<strong>de</strong> ser <strong>de</strong>scrito como <strong>una</strong> “rebanada” completa <strong>de</strong>l stack<br />
<strong>de</strong> protocolo.<br />
Existen cuatro perfiles generales <strong>de</strong>finidos, en los cuales están basados<br />
directamente algunos <strong>de</strong> los mo<strong>de</strong>los <strong>de</strong> usuario más importantes y sus perfiles.<br />
Estos cuatro mo<strong>de</strong>los son Perfil Genérico <strong>de</strong> Acceso (GAP), Perfil <strong>de</strong> Puerto<br />
Serial, Perfil <strong>de</strong> Aplicación <strong>de</strong> Descubrimiento <strong>de</strong> Servicio (SDAP) y Perfil Genérico<br />
<strong>de</strong> Intercambio <strong>de</strong> Objetos (GOEP). A continuación se hace <strong>una</strong> breve <strong>de</strong>scripción<br />
<strong>de</strong> estos y algunos otros perfiles Bluetooth [4]. La Figura 1-16 muestra el esquema<br />
<strong>de</strong> los perfiles Bluetooth. En ella se pue<strong>de</strong> observar la jerarquía <strong>de</strong> los perfiles,<br />
como por ejemplo que todos los perfiles están contenidos en el Perfil Genérico <strong>de</strong><br />
Acceso (GAP).
Figura 1.16. Los Perfiles Bluetooth<br />
1.7.1 Perfil Genérico <strong>de</strong> Acceso (GAP). Este perfil <strong>de</strong>fine los procedimientos<br />
generales para el <strong>de</strong>scubrimiento y establecimiento <strong>de</strong> conexión entre dispositivos<br />
Bluetooth. El GAP maneja el <strong>de</strong>scubrimiento y establecimiento entre unida<strong>de</strong>s que<br />
no están conectadas y asegura que cualquier par <strong>de</strong> unida<strong>de</strong>s Bluetooth, sin<br />
importar su fabricante o aplicación, puedan intercambiar información a través <strong>de</strong><br />
Bluetooth para <strong>de</strong>scubrir qué tipo <strong>de</strong> aplicaciones soportan las unida<strong>de</strong>s.<br />
1.7.2 Perfil <strong>de</strong> Puerto Serial. Este perfil <strong>de</strong>fine los requerimientos para<br />
dispositivos Bluetooth, necesarios para establecer <strong>una</strong> conexión <strong>de</strong> cable serial<br />
emulada usando RFCOMM entre dos dispositivos similares. Este perfil solamente<br />
requiere soporte para paquetes <strong>de</strong> un slot. Esto significa que pue<strong>de</strong>n ser usadas<br />
ratas <strong>de</strong> datos <strong>de</strong> hasta 128 kbps. El soporte para ratas más altas es opcional.
RFCOMM es usado para transportar los datos <strong>de</strong> usuario, señales <strong>de</strong> control <strong>de</strong><br />
mo<strong>de</strong>m y comandos <strong>de</strong> configuración. El perfil <strong>de</strong> puerto serial es <strong>de</strong>pendiente <strong>de</strong>l<br />
GAP.<br />
1.7.3 Perfil <strong>de</strong> Aplicación <strong>de</strong> Descubrimiento <strong>de</strong> Servicio (SDAP). Este perfil<br />
<strong>de</strong>fine los protocolos y procedimientos para <strong>una</strong> aplicación en un dispositivo<br />
Bluetooth don<strong>de</strong> se <strong>de</strong>sea <strong>de</strong>scubrir y recuperar información relacionada con<br />
servicios localizados en otros dispositivos. El SDAP es <strong>de</strong>pendiente <strong>de</strong>l GAP.<br />
1.7.4 Perfil Genérico <strong>de</strong> Intercambio <strong>de</strong> Objetos (GOEP). Este perfil <strong>de</strong>fine<br />
protocolos y procedimientos usados por aplicaciones para ofrecer características<br />
<strong>de</strong> intercambio <strong>de</strong> objetos. Los usos pue<strong>de</strong>n ser, por ejemplo, sincronización,<br />
transferencia <strong>de</strong> archivos o mo<strong>de</strong>lo Object Push. Los dispositivos más comunes<br />
que usan este mo<strong>de</strong>lo son agendas electrónicas, PDAs, teléfonos celulares y<br />
teléfonos móviles. El GOEP es <strong>de</strong>pendiente <strong>de</strong>l perfil <strong>de</strong> puerto serial.<br />
1.7.5 Perfil <strong>de</strong> Telefonía Inalámbrica. Este perfil <strong>de</strong>fine cómo un teléfono móvil<br />
pue<strong>de</strong> ser usado para acce<strong>de</strong>r a un servicio <strong>de</strong> telefonía <strong>de</strong> <strong>red</strong> fija a través <strong>de</strong> <strong>una</strong><br />
estación base. Es usado para telefonía <strong>inalámbrica</strong> <strong>de</strong> hogares u oficinas<br />
pequeñas. El perfil incluye llamadas a través <strong>de</strong> <strong>una</strong> estación base, haciendo<br />
llamadas <strong>de</strong> intercomunicación directa entre dos terminales y accediendo<br />
adicionalmente a re<strong>de</strong>s externas. Es usado por dispositivos que implementan el<br />
llamado “teléfono 3-en-1”.<br />
1.7.6 Perfil <strong>de</strong> Intercomunicador. Este perfil <strong>de</strong>fine usos <strong>de</strong> teléfonos móviles<br />
los cuales establecen enlaces <strong>de</strong> conversación directa entre dos dispositivos. El
enlace directo es establecido usando señalización <strong>de</strong> telefonía sobre Bluetooth.<br />
Los teléfonos móviles que usan enlaces directos funcionan como walkie-talkies.<br />
1.7.7 Perfil <strong>de</strong> Manos Libres. Este perfil <strong>de</strong>fine los requerimientos, para<br />
dispositivos Bluetooth, necesarios para soportar el uso <strong>de</strong> manos libres. En este<br />
caso el dispositivo pue<strong>de</strong> ser usado como unidad <strong>de</strong> audio inalámbrico <strong>de</strong><br />
entrada/salida. El perfil soporta comunicación segura y no segura.<br />
1.7.8 Perfil Dial-up Networking. Este perfil <strong>de</strong>fine los protocolos y<br />
procedimientos que <strong>de</strong>ben ser usados por dispositivos que implementen el uso <strong>de</strong>l<br />
mo<strong>de</strong>lo llamado Puente Internet. Este perfil es aplicado cuando un teléfono celular<br />
o mo<strong>de</strong>m es usado como un mo<strong>de</strong>m inalámbrico.<br />
1.7.9 Perfil <strong>de</strong> Fax. Este perfil <strong>de</strong>fine los protocolos y procedimientos que <strong>de</strong>ben<br />
ser usados por dispositivos que implementen el uso <strong>de</strong> fax. En el perfil un teléfono<br />
celular pue<strong>de</strong> ser usado como un fax inalámbrico.<br />
1.7.10 Perfil <strong>de</strong> Acceso LAN. Este perfil <strong>de</strong>fine el acceso a <strong>una</strong> <strong>red</strong> <strong>de</strong> área local,<br />
LAN, usando el protocolo punto-a-punto, PPP, sobre RFCOMM. PPP es<br />
ampliamente usado para lograr acce<strong>de</strong>r a re<strong>de</strong>s soportando varios protocolos <strong>de</strong><br />
<strong>red</strong>. El perfil soporta acceso LAN para un dispositivo Bluetooth sencillo, acceso<br />
LAN para varios dispositivos Bluetooth y PC-a-PC (usando interconexión PPP con<br />
emulación <strong>de</strong> cable serial).
1.7.11 Perfil Object Push. Este perfil <strong>de</strong>fine protocolos y procedimientos usados<br />
en el mo<strong>de</strong>lo object push. Este perfil usa el GOEP. En el mo<strong>de</strong>lo object push<br />
hay procedimientos para introducir en el inbox, sacar e intercambiar objetos con<br />
otro dispositivo Bluetooth.<br />
1.7.12 Perfil <strong>de</strong> Transferencia <strong>de</strong> Archivos. Este perfil <strong>de</strong>fine protocolos y<br />
procedimientos usados en el mo<strong>de</strong>lo <strong>de</strong> transferencia <strong>de</strong> archivos. El perfil usa el<br />
GOEP. En el mo<strong>de</strong>lo <strong>de</strong> transferencia <strong>de</strong> archivos hay procedimientos para<br />
chequear un grupo <strong>de</strong> objetos <strong>de</strong> otro dispositivo Bluetooth, transferir objetos entre<br />
dos dispositivos y manipular objetos <strong>de</strong> otro dispositivo. Los objetos podrían ser<br />
archivos o fól<strong>de</strong>res <strong>de</strong> un grupo <strong>de</strong> objetos tal como un sistema <strong>de</strong> archivos.<br />
1.7.13 Perfil <strong>de</strong> Sincronización. Este perfil <strong>de</strong>fine protocolos y procedimientos<br />
usados en el mo<strong>de</strong>lo <strong>de</strong> sincronización. Éste usa el GOEP. El mo<strong>de</strong>lo soporta<br />
intercambios <strong>de</strong> información, por ejemplo para sincronizar calendarios <strong>de</strong><br />
diferentes dispositivos.
2. DESCRIPCIÓN DE HARDWARE Y PRODUCTOS<br />
BLUETOOTH<br />
Después <strong>de</strong> analizar y compren<strong>de</strong>r la tecnología Bluetooth se procedió a hacer<br />
<strong>una</strong> búsqueda <strong>de</strong> productos disponibles en el mercado con el fin <strong>de</strong> conocer las<br />
diversas aplicaciones que se ofrecen y principalmente <strong>de</strong>terminar qué producto<br />
adquirir o implementar para el <strong>de</strong>sarrollo <strong>de</strong> esta tesis. En este capítulo se<br />
presenta <strong>una</strong> <strong>de</strong>scripción <strong>de</strong>tallada <strong>de</strong>l hardware implementado y se hace <strong>una</strong><br />
breve <strong>de</strong>scripción <strong>de</strong> los diferentes tipos <strong>de</strong> productos Bluetooth disponibles así<br />
como el procedimiento mediante el cual se califica un producto como producto<br />
Bluetooth.<br />
2.1 TARJETAS BLUEBOARDUV<br />
Uno <strong>de</strong> los puntos esenciales para el <strong>de</strong>sarrollo <strong>de</strong> esta tesis fue la utilización <strong>de</strong><br />
hardware para la <strong>implementación</strong>. Después <strong>de</strong> conocer los diferentes tipos <strong>de</strong><br />
productos Bluetooth disponibles (ver sección 2.2), se hizo un análisis <strong>de</strong> las<br />
mejores opciones teniendo en cuenta ventajas, <strong>de</strong>sventajas, costo, accesibilidad,<br />
etc. Para cumplir con el objetivo principal <strong>de</strong> este trabajo, es <strong>de</strong>cir, la<br />
<strong>implementación</strong> <strong>de</strong> <strong>una</strong> <strong>red</strong> Bluetooth, se <strong>de</strong>cidió construir sistemas semiembebidos<br />
Bluetooth utilizando módulos, antenas y <strong>de</strong>más dispositivos periféricos<br />
necesarios. A las tarjetas construidas se les dieron los nombres <strong>de</strong><br />
BlueboardUV01 y BlueboardUV02. La diferencia principal entre los dos tipos <strong>de</strong><br />
tarjeta radica únicamente en el tipo <strong>de</strong> antena utilizado y por consiguiente los<br />
requerimientos <strong>de</strong> antena tenidos en cuenta para cada <strong>una</strong> son diferentes. En la<br />
Figura 2-1 se muestra el diagrama <strong>de</strong> bloques <strong>de</strong> las tarjetas BlueboardUV. En la<br />
gráfica se pue<strong>de</strong>n observar las principales partes que las conforman.
Figura 2-1. Diagrama <strong>de</strong> Bloques <strong>de</strong> las tarjetas BlueboardUV<br />
Los bloques funcionales <strong>de</strong> las tarjetas son:<br />
• Módulo Bluetooth: es el chip-multichip que tiene implementadas las capas<br />
más bajas <strong>de</strong>l stack y posee diferentes interfaces para lograr comunicación<br />
<strong>de</strong> voz y datos. Es el bloque más importante <strong>de</strong>l sistema.<br />
• Antena: ya que el módulo no incluye <strong>una</strong> antena, éste es un dispositivo<br />
externo necesario para lograr la comunicación Bluetooth. Es el dispositivo<br />
con más requerimientos <strong>de</strong> diseño.
• Transceiver RS-232: necesario para convertir las señales RS-232 <strong>de</strong> <strong>una</strong><br />
fuente <strong>de</strong> menor a mayor valor <strong>de</strong> voltaje (<strong>de</strong> 3.0V a 5.5V).<br />
• Regulación <strong>de</strong> voltaje: necesario para el suministro <strong>de</strong> potencia <strong>de</strong>l módulo<br />
y el transceiver RS-232. El voltaje regulado es <strong>de</strong> 3.3V.<br />
2.1.1 Descripción <strong>de</strong> las tarjetas BlueboardUV. A continuación se presenta <strong>una</strong><br />
<strong>de</strong>scripción general <strong>de</strong> las tarjetas, información más <strong>de</strong>tallada se presenta en<br />
secciones posteriores. Entre las principales características <strong>de</strong> las tarjetas<br />
BlueboardUV están:<br />
• Módulo <strong>de</strong> acuerdo a la versión 1.0b <strong>de</strong> Bluetooth<br />
• Módulo removible usando el Carrier Socket <strong>de</strong> SUYIN para módulos Bluetooth<br />
• Acceso a todas las señales <strong>de</strong>l módulo<br />
• Pin <strong>de</strong> encendido externo<br />
• Salida RF <strong>de</strong> potencia clase 2 (0dBm-rango <strong>de</strong> 10m)<br />
• LED <strong>de</strong> monitoreo para suministro <strong>de</strong> energía<br />
• Tres interfaces para diversas aplicaciones;<br />
UART para datos<br />
PCM para voz<br />
USB para datos<br />
• Rata máxima <strong>de</strong> transmisión <strong>de</strong> datos sobre UART <strong>de</strong> 460,8 kbps<br />
• Reset manual<br />
• Capas inferiores <strong>de</strong>l stack Bluetooth incluidas en el hardware, <strong>de</strong>s<strong>de</strong> el HCI<br />
hasta la capa <strong>de</strong> radio.<br />
• Antena RangeStar 100929 ó 100930 incluida<br />
• Operación Punto a Multi-Punto (<strong>de</strong>pendiendo <strong>de</strong>l módulo utilizado)
Las tarjetas BlueboardUV únicamente soportan comunicación <strong>de</strong> datos, sin<br />
embargo poseen <strong>una</strong> interfaz PCM disponible para comunicación <strong>de</strong> voz. La<br />
comunicación entre la tarjeta y el controlador <strong>de</strong> host se hace a través <strong>de</strong> la<br />
interfaz USB o la interfaz UART/PCM. El módulo ROK101007/8 usado soporta<br />
todos los perfiles <strong>de</strong>finidos en la versión 1.0b <strong>de</strong> la especificación Bluetooth.<br />
Las tarjetas BlueboardUV necesitan <strong>una</strong> alimentación <strong>de</strong> 5VDC que pue<strong>de</strong>n<br />
suministrarse a través <strong>de</strong>l conector USB o por medio <strong>de</strong> un terminal macho<br />
genérico. Poseen un convertidor DC/DC que proporciona la alimentación al<br />
módulo Bluetooth Ericsson ROK101007/8. El diagrama esquemático <strong>de</strong> las<br />
tarjetas se muestra en la Figura 2-2. Se pue<strong>de</strong>n observar los dispositivos utilizados<br />
para los diferentes bloques funcionales: módulo Ericsson ROK101007, antena<br />
RangeStar 100929 ó 100930, transceiver Maxim MAX3232 y regulador <strong>de</strong> voltaje<br />
National LP2987.<br />
El voltaje regulado necesario para la alimentación <strong>de</strong>l módulo y el transceiver RS-<br />
232 es suministrado por el LP2987. Su circuito, tiene un pin <strong>de</strong> encendido externo<br />
(ON/OFF), que permite habilitar el suministro <strong>de</strong> potencia a la tarjeta. A<strong>de</strong>más,<br />
para verificar el estado <strong>de</strong> la excitación, posee un LED <strong>de</strong> monitoreo (D1). El<br />
voltaje regulado es <strong>de</strong> 3.3V. El módulo posee diferentes interfaces <strong>de</strong><br />
comunicación: USB, RS-232, PCM e I2C. Las señales RS-232 que salen <strong>de</strong>l<br />
módulo, antes <strong>de</strong> ir al conector macho RS232 son convertidas a un voltaje mayor<br />
por medio <strong>de</strong>l MAX3232. Al usar la interfaz UART el módulo funciona como un<br />
Equipo <strong>de</strong> Comunicación <strong>de</strong> Datos (DCE), con <strong>una</strong> velocidad <strong>de</strong> 57,6 kbps por<br />
<strong>de</strong>fecto. La interfaz USB cumple con la especificación 1.1. Las señales USB, PCM<br />
e I2C están conectadas directamente a su correspondiente conector macho<br />
(CONECTOR_USB, PCM, I2C). La señal ANT <strong>de</strong>l módulo está conectada<br />
directamente al terminal <strong>de</strong> alimentación <strong>de</strong> la antena (RangeStar 100929/30).
Figura 2-2. Diagrama esquemático <strong>de</strong> las tarjetas BlueboardUV
En la Tabla 2-1 se presenta la lista <strong>de</strong> componentes <strong>de</strong> <strong>una</strong> tarjeta BlueboardUV<br />
<strong>de</strong>tallando las referencias <strong>de</strong>ntro <strong>de</strong> la tarjeta y <strong>de</strong> fabricante para cada<br />
componente.<br />
Tabla 2-1. Lista <strong>de</strong> componentes para la tarjeta BlueboardUV<br />
No Tipo <strong>de</strong> Tipo <strong>de</strong> Referencia <strong>de</strong> Cant. Referencia en Tarjeta<br />
Dispositivo paquete Componente<br />
(Ver Figuras 2-3 y 2-4)<br />
1 IC, Módulo<br />
ERICSSON<br />
Sobre el soporte<br />
Bluetooth<br />
[5] ROK101007 / 8 1 CARRIER SOCKET<br />
2 Soporte<br />
SUYIN<br />
Carrier socket [6] BT001A-30G2T 1 CARRIER SOCKET<br />
3 IC, Regulador <strong>de</strong><br />
NATIONAL<br />
Voltaje<br />
M08A LP2987AIM 3.3V SMD 1<br />
M08A<br />
4 IC, Interfaz<br />
MAXIM MAX3232<br />
RS-232 SO16L(W) EEWE/CWE 3.3V SMD 1<br />
MAX3232<br />
5<br />
RANGESTAR<br />
Rangestar<br />
Antena<br />
[7] 100929 ó 100930 1 100929 ó 100930<br />
6<br />
C1206 Cond. 0,1uF/50V SMD<br />
Capacitor 0,1uF 3x1,5x1mm Monolitico<br />
5 C4, C5, C6, C7,C8<br />
7<br />
Cond. 0,47uF/50V 10%<br />
Capacitor 0,47uF KEMET_C SMD Tantalio SPRAG 1<br />
C2<br />
8<br />
KEMET_C Cond. 4.7uF/20V SMD<br />
Capacitor 4.7uF 6032<br />
Tantalio<br />
2<br />
C1, C3<br />
9 Resistencia 100KΩ R1206 5% 1/8W SMD 1 R1<br />
10 Resistencia 330KΩ R1206 5% 1/8W SMD 1 R2<br />
11 Resistencia 220Ω R1206 5% 1/4W SMD 1 R3<br />
12<br />
LED uMiniatura 1,7mcd<br />
Diodo LED SOT-23 LiteOn SMD<br />
1<br />
D1<br />
13 Conector USB PN87520 CON-BERG 1 USB_CONNECTOR<br />
14 Switch B3F-10XX Switch-omron 10-XX 1 S1<br />
15 Jum 1X2 MA02-1 con-lstb 1 ON/OFF<br />
16 Jum 2X2 MA02-2 con-lstb 1 I2C<br />
17 Jum 5X2 MA05-2 con-lstb 2 PCM, RS232<br />
Total <strong>de</strong> partes 23
Las Figuras 2-3 y 2-4 muestran diagramas <strong>de</strong>l hardware <strong>de</strong> las tarjetas<br />
BlueboardUV01 y BlueboardUV02 respectivamente. Las gráficas son <strong>una</strong><br />
representación <strong>de</strong>tallada <strong>de</strong> las tarjetas. Cada dispositivo utilizado tiene asociada<br />
<strong>una</strong> referencia, facilitando su localización física. El tamaño real <strong>de</strong> las tarjetas es<br />
<strong>de</strong> 8,5 x 7,5 cm.<br />
Figura 2-3. Diagrama <strong>de</strong>l hardware <strong>de</strong> la tarjeta BlueboardUV01
Figura 2-4. Diagrama <strong>de</strong>l hardware <strong>de</strong> la tarjeta BlueboardUV02<br />
Con el fin <strong>de</strong> conocer y enten<strong>de</strong>r mejor el funcionamiento <strong>de</strong> las tarjetas<br />
BlueboardUV, a continuación se hace <strong>una</strong> <strong>de</strong>scripción <strong>de</strong>tallada <strong>de</strong> los principales<br />
dispositivos utilizados y los requerimientos que se <strong>de</strong>bieron tener en cuenta para<br />
la <strong>implementación</strong> <strong>de</strong> las tarjetas.
2.1.2 Descripción <strong>de</strong> componentes y requerimientos en las tarjetas<br />
BlueboardUV.<br />
2.1.2.1 Módulo Bluetooth Ericsson ROK101007/8. Para la <strong>implementación</strong> <strong>de</strong><br />
las tarjetas BlueboardUV01 y BlueboardUV02 se utilizaron los módulos <strong>de</strong><br />
Ericsson ROK101007 y ROK101008. Su escogencia se hizo teniendo en cuenta la<br />
robustez y la compatibilidad con otros dispositivos. El ROK101007 se diferencia<br />
<strong>de</strong>l ROK101008 únicamente en que el primero soporta conexión punto a punto y<br />
punto a multi-punto y el segundo únicamente conexión punto a punto, por esto <strong>de</strong><br />
aquí en a<strong>de</strong>lante solamente se hace referencia al módulo ROK101007. A<br />
continuación se presenta <strong>una</strong> <strong>de</strong>scripción general <strong>de</strong>l módulo. Mayor información<br />
se encuentra en la Web [5].<br />
Las principales ventajas <strong>de</strong>l módulo Ericsson ROK101007 son:<br />
• Pre-calificado con la especificación Bluetooth 1.0B<br />
• Potencia <strong>de</strong> salida RF clase 2<br />
• Aprobado por la FCC y la ETSI<br />
• Rata máxima sobre UART <strong>de</strong> 460 kb/s<br />
• Distintas interfaces: UART para datos, PCM para voz y USB para voz y datos.<br />
• Interfaz I 2 C<br />
• Cristal oscilador interno<br />
• Firmware HCI incluido<br />
• Blindado<br />
El ROK101007 es un módulo <strong>de</strong> corto rango para implementaciones Bluetooth en<br />
diferentes dispositivos electrónicos que soporta transmisiones <strong>de</strong> datos y voz. La<br />
comunicación entre el módulo y el controlador <strong>de</strong> host se lleva a cabo a través <strong>de</strong>
<strong>una</strong> interfaz <strong>de</strong> alta velocidad USB acor<strong>de</strong> a las especificaciones USB 1.1 o a<br />
través <strong>de</strong> <strong>una</strong> interfaz UART/PCM. Al utilizar la interfaz USB, el módulo funciona<br />
como un dispositivo esclavo USB y por lo tanto no requiere recursos <strong>de</strong>l PC. El<br />
ROK101007 es un módulo Bluetooth Clase 2 (0dBm) y a<strong>de</strong>más soporta todos los<br />
perfiles Bluetooth.<br />
El ROK101007 es un chip multi-chip <strong>de</strong> 30 pines <strong>de</strong> 3.3 x 1.7cm<br />
aproximadamente, que por su dimensión facilita implementaciones en dispositivos<br />
portátiles y <strong>de</strong> tamaño <strong>red</strong>ucido. El módulo consta <strong>de</strong> tres partes principales;<br />
Controlador Banda Base, Memoria Flash y Radio. Los bloques operacionales <strong>de</strong>l<br />
ROK101007 los conforman los tres anteriores, más un bloque <strong>de</strong> Manejo <strong>de</strong><br />
Potencia y otro <strong>de</strong> Reloj.<br />
� El Controlador Banda Base es un ARM7 que controla la operación <strong>de</strong>l<br />
radio transceiver a través <strong>de</strong> <strong>una</strong> interfaz USB o UART, y adicionalmente<br />
tiene <strong>una</strong> interfaz <strong>de</strong> voz PCM y <strong>una</strong> interfaz I 2 C<br />
� La Memoria Flash es usada con el Controlador Banda Base<br />
� El Radio es implementado con el radio Ericsson PBA 913 01/2<br />
� En el Manejo <strong>de</strong> Potencia se regula y filtra el voltaje <strong>de</strong> alimentación Vcc<br />
que típicamente es <strong>de</strong> 3.3V<br />
� El Reloj interno trabaja a 13MHz con <strong>una</strong> precisión en el oscilador <strong>de</strong><br />
cristal <strong>de</strong> 20ppm.<br />
• Partes Hardware / Firmware <strong>de</strong>l ROK101007. El módulo ROK101007 incluye<br />
partes HW/FW <strong>de</strong>l stack <strong>de</strong> protocolo Bluetooth. Las partes <strong>de</strong> HW incluidas son<br />
el Radio y la Banda Base, y las <strong>de</strong> FW, las cuales resi<strong>de</strong>n en la Flash, son la<br />
Interfaz <strong>de</strong>l Controlador <strong>de</strong> Host, HCI, y el Manejador <strong>de</strong> Enlace, LM. En la Figura<br />
2-5 se pue<strong>de</strong>n observar las partes <strong>de</strong> HW/FW incluidas en el módulo.
Figura 2-5. HW/FW <strong>de</strong>l módulo Ericsson ROK101007<br />
Interfaz <strong>de</strong> Radio: el módulo es un dispositivo clase 2 con <strong>una</strong> salida máxima <strong>de</strong><br />
potencia <strong>de</strong> 4dBm. El rango nominal <strong>de</strong>l módulo con <strong>una</strong> antena típica es <strong>de</strong><br />
hasta 10 m (a 0 dBm).<br />
Banda Base: Se usa <strong>una</strong> estructura <strong>de</strong> <strong>red</strong> ad-hoc con un número máximo <strong>de</strong><br />
ocho unida<strong>de</strong>s activas en <strong>una</strong> sola piconet.<br />
• Interfaces HW <strong>de</strong>l Módulo.<br />
Interfaz USB: El módulo es un dispositivo USB <strong>de</strong> alta velocidad (12Mbps) que<br />
tiene toda la funcionalidad <strong>de</strong> un esclavo USB y está <strong>de</strong> acuerdo con la<br />
especificación USB 1.1 La transferencia <strong>de</strong> datos se hace a través <strong>de</strong> los puertos<br />
bidireccionales D+ & D-, y adicionalmente se usan las líneas Wake_up y Detach.<br />
En la Figura 2-6 se pue<strong>de</strong> observar la configuración típica para <strong>una</strong> aplicación<br />
USB.
Interfaz UART: esta interfaz es acor<strong>de</strong> al estándar industrial 16C450 y soporta las<br />
siguientes ratas <strong>de</strong> bits: 300, 600, 900, 1200, 1800, 2400, 4800, 9600, 19200,<br />
38400, 57600, 115200, 230400 y 460800 bits/s. Existen FIFOs <strong>de</strong> 128 bytes<br />
asociadas con la UART. Para esta interfaz se tienen cuatro señales, TxD & RxD<br />
se usan para flujo <strong>de</strong> datos, y RTS & CTS se usan para control <strong>de</strong> flujo. En la<br />
Figura 2-7 se muestra la configuración típica para <strong>una</strong> aplicación UART o PCM.<br />
Interfaz <strong>de</strong> voz PCM: la interfaz estándar PCM tiene <strong>una</strong> rata <strong>de</strong> muestreo <strong>de</strong><br />
8kHz (PCM_SYNC). El reloj PCM es variable entre 200kHz y 2MHz. Los datos<br />
PCM pue<strong>de</strong>n ser: PCM 13-16 bits, u-Law 8 bits ó A-Law 8 bits. En este caso se<br />
tienen cuatro líneas <strong>de</strong> conexión PCM_IN, PCM_OUT, PCM_SYNC y PCM_CLK.<br />
En la Figura 2-7 se pue<strong>de</strong> observar la configuración típica para <strong>una</strong> aplicación<br />
UART O PCM.<br />
Interfaz I 2 C: En el módulo se encuentra disponible <strong>una</strong> interfaz I 2 C maestro.<br />
Figura 2-6. Configuración Típica USB para el ROK101007
Figura 2-7. Configuración Típica UART o PCM para el ROK101007<br />
2.1.2.2 Diseño <strong>de</strong> Antena. En cualquier sistema <strong>de</strong> comunicación <strong>inalámbrica</strong>, la<br />
antena es un componente crítico cuya <strong>implementación</strong> influye significativamente<br />
en el <strong>de</strong>sempeño global <strong>de</strong>l sistema. Esto se <strong>de</strong>be a que la antena es el elemento<br />
que convierte las señales eléctricas conducidas por las pistas <strong>de</strong> la tarjeta <strong>de</strong><br />
circuito impreso (PCB) a señales que se propagan a través <strong>de</strong>l espacio libre; por lo<br />
tanto actúa como <strong>una</strong> impedancia y un dispositivo <strong>de</strong> conversión. No obstante la<br />
antena normalmente es uno <strong>de</strong> los componentes más <strong>de</strong>scuidados en un sistema<br />
<strong>de</strong> comunicación <strong>inalámbrica</strong>.<br />
• Principales parámetros <strong>de</strong> la Antena. Una antena se caracteriza por varios<br />
parámetros relevantes que <strong>de</strong>ben ser tenidos en cuenta para el diseño <strong>de</strong> un<br />
sistema inalámbrico. Entre los más importantes están: la Frecuencia <strong>de</strong><br />
Operación, el Ancho <strong>de</strong> Banda, la Impedancia <strong>de</strong> Entrada, la Ganancia <strong>de</strong> Antena,<br />
la Eficiencia <strong>de</strong> Radiación y el Tamaño <strong>de</strong> la Antena.
• Banda <strong>de</strong> frecuencia Bluetooth. A pesar <strong>de</strong> que algunos países han<br />
especificado diferentes rangos <strong>de</strong> frecuencia para la banda “2.4 GHz ISM”<br />
(Bluetooth), todos ellos están contenidos <strong>de</strong>ntro <strong>de</strong>l rango <strong>de</strong> frecuencia <strong>de</strong> 2.400-<br />
2.497GHz. Por consiguiente para <strong>una</strong> <strong>implementación</strong> Bluetooth se <strong>de</strong>be utilizar<br />
<strong>una</strong> antena que trabaje sobre todo este rango, para asegurar la máxima<br />
compatibilidad <strong>de</strong>l dispositivo y el uso <strong>de</strong> los canales disponibles.<br />
• Ganancia <strong>de</strong> Antena. Tal como los rayos <strong>de</strong> sol son menos intensos a<br />
mayores distancias, la potencia <strong>de</strong> todas las antenas <strong>de</strong>crece con el incremento<br />
<strong>de</strong> la distancia. A<strong>de</strong>más, la rata a la cual esta potencia <strong>de</strong>crementa es siempre la<br />
misma, por lo tanto, la única forma <strong>de</strong> incrementar la potencia recibida en un lugar<br />
apartado es aumentando la potencia <strong>de</strong> RF (Radio Frecuencia) en esa dirección.<br />
Es aquí don<strong>de</strong> la ganancia <strong>de</strong> la antena es útil; esta <strong>de</strong>be ser tenida en cuenta, ya<br />
que tiene un impacto directo en el <strong>de</strong>sempeño y el rango máximo <strong>de</strong> un dispositivo<br />
Bluetooth, a<strong>de</strong>más <strong>de</strong> ser uno <strong>de</strong> los únicos elementos controlables en la<br />
trayectoria <strong>de</strong> la señal <strong>de</strong>s<strong>de</strong> el transmisor hasta el receptor. El uso <strong>de</strong> antenas<br />
con baja ganancia limita ampliamente la máxima distancia <strong>de</strong> alcance <strong>de</strong> <strong>una</strong><br />
señal Bluetooth. La unidad <strong>de</strong> medida para la ganancia <strong>de</strong> <strong>una</strong> antena está dada<br />
usualmente en dBi, que es <strong>una</strong> sigla para “<strong>de</strong>cibeles relativos a <strong>una</strong> fuente<br />
isotrópica.”<br />
• El Plano <strong>de</strong> Tierra. La mayoría <strong>de</strong> antenas <strong>inalámbrica</strong>s requieren un Plano<br />
<strong>de</strong> Tierra sobre el PCB. Su longitud <strong>de</strong>be ser aproximadamente un cuarto (¼) <strong>de</strong><br />
la longitud <strong>de</strong> onda <strong>de</strong> operación. Así, si la frecuencia <strong>de</strong> trabajo en Bluetooth es<br />
<strong>de</strong> 2425 MHz, la longitud <strong>de</strong> onda (λ) es 124 mm y <strong>de</strong> esta manera la mínima<br />
longitud <strong>de</strong>l Plano <strong>de</strong> Tierra sería <strong>de</strong> 31 mm. A medida que la longitud <strong>de</strong>l Plano<br />
<strong>de</strong> Tierra se hace mayor a ¼ <strong>de</strong> la longitud <strong>de</strong> onda, el patrón <strong>de</strong> radiación se<br />
hace cada vez más multi-lóbulo. Esto generalmente no afecta a la mayoría <strong>de</strong>
aplicaciones. Sin embargo, si el Plano <strong>de</strong> Tierra es significativamente menor a ¼<br />
<strong>de</strong> la longitud <strong>de</strong> onda, la sintonización se hace cada vez más difícil y el<br />
<strong>de</strong>sempeño global disminuye. Esto es común en todas las antenas, por ejemplo,<br />
las antenas <strong>de</strong> los beepers son muy ineficientes <strong>de</strong>bido a su tamaño, el cual es<br />
significativamente más pequeño que su longitud <strong>de</strong> onda <strong>de</strong> operación. En la<br />
Figura 2-8 se observa el comportamiento <strong>de</strong> la Ganancia <strong>de</strong> Antena con respecto<br />
al tamaño <strong>de</strong>l Plano <strong>de</strong> Tierra.<br />
Figura 2-8. Ganancia Pico vs. Longitud PCB<br />
Fuente: RangeStar Wireless, Inc.<br />
Según la Figura 2-8, para lograr un óptimo <strong>de</strong>sempeño <strong>de</strong> la antena se <strong>de</strong>be tratar<br />
<strong>de</strong> obtener un plano <strong>de</strong> tierra <strong>de</strong> 0.33 veces la longitud <strong>de</strong> onda <strong>de</strong> operación. En<br />
las tarjetas BlueboardUV el plano <strong>de</strong> tierra se implementó por las dos caras <strong>de</strong>l<br />
PCB y se interconectaron los dos planos por medio <strong>de</strong> vías localizadas en toda la<br />
superficie <strong>de</strong> las tarjetas con el fin <strong>de</strong> evitar diferencias <strong>de</strong> potencial mínimas que<br />
puedan afectar el <strong>de</strong>sempeño <strong>de</strong>l sistema. En las Figuras 2-9 a 2-12 se pue<strong>de</strong>n<br />
observar el plano <strong>de</strong> tierra y las vías implementadas en las tarjetas. Éstas
muestran el ruteo por ambas caras <strong>de</strong> la Tarjeta <strong>de</strong> Circuito Impreso (PCB) para<br />
las tarjetas BlueboardUV. Información más <strong>de</strong>tallada se pue<strong>de</strong> encontrar en el CD-<br />
ROM anexo con este documento.<br />
Figura 2-9. Ruteo <strong>de</strong> la parte superior <strong>de</strong> la tarjeta BlueboardUV01
Figura 2-10. Ruteo <strong>de</strong> la parte inferior <strong>de</strong> la tarjeta BlueboardUV01<br />
Figura 2-11. Ruteo <strong>de</strong> la parte superior <strong>de</strong> la tarjeta BlueboardUV02
Figura 2-12. Ruteo <strong>de</strong> la parte inferior <strong>de</strong> la tarjeta BlueboardUV03<br />
• Efectos <strong>de</strong> localización <strong>de</strong> la antena. La localización <strong>de</strong> la antena sobre el<br />
PCB afecta el <strong>de</strong>sempeño <strong>de</strong>l sistema en mayor proporción que el tamaño <strong>de</strong>l<br />
Plano <strong>de</strong> Tierra. En general, las esquinas son el mejor lugar <strong>de</strong> montaje. La<br />
localización <strong>de</strong> la antena no <strong>de</strong>be ser escogida solamente por su patrón <strong>de</strong><br />
radiación, también se <strong>de</strong>be tener en cuenta que la antena no perturbe otras partes<br />
<strong>de</strong>l sistema y que ningún disturbio sea introducido al sistema Bluetooth a través <strong>de</strong><br />
la antena.<br />
2.1.2.3 Antenas RangeStar. En este proyecto se utilizaron las antenas<br />
RangeStar 100929 y 100930 [7]. A continuación se presentan sus principales
características a<strong>de</strong>más <strong>de</strong> <strong>una</strong> <strong>de</strong>scripción <strong>de</strong> los requerimientos tenidos en<br />
cuenta para la construcción <strong>de</strong> las tarjetas BlueboardUV.<br />
• Diseño <strong>de</strong>l PCB. Las antenas <strong>de</strong> RangeStar están diseñadas para ser<br />
montadas al final <strong>de</strong> un PCB, así se utiliza la máxima longitud <strong>de</strong>l Plano <strong>de</strong> Tierra<br />
para emitir las ondas electromagnéticas y a pesar <strong>de</strong> que haya <strong>una</strong> pequeña<br />
diferencia en el <strong>de</strong>sempeño global, estas antenas se <strong>de</strong>ben montar junto al<br />
dispositivo que emite mayor energía.<br />
Estas antenas tienen varios terminales, cada uno <strong>de</strong> ellos con <strong>una</strong> función<br />
diferente. Un terminal sirve como alimentación <strong>de</strong> la señal RF mientras que los<br />
<strong>de</strong>más pue<strong>de</strong>n servir como conexión a tierra, como conexión <strong>de</strong> soporte o las dos<br />
(conexión a tierra y soporte). El pad <strong>de</strong>l terminal <strong>de</strong> alimentación se <strong>de</strong>be conectar<br />
a <strong>una</strong> línea <strong>de</strong> transmisión <strong>de</strong> 50 Ohm y los pads <strong>de</strong> los terminales <strong>de</strong> conexión a<br />
tierra, se <strong>de</strong>ben conectar eléctricamente al Plano <strong>de</strong> Tierra <strong>de</strong>l PCB. Cada antena<br />
tiene <strong>una</strong> distancia <strong>de</strong> aislamiento recomendada, que correspon<strong>de</strong> a la mínima<br />
distancia permitida entre la antena y cualquier conductor sobre el PCB. Si algún<br />
conductor está más cerca que la distancia <strong>de</strong> aislamiento especificada el <strong>de</strong>sfase<br />
<strong>de</strong> capacitancia generado <strong>de</strong>s-sintoniza la antena.<br />
Ya que Bluetooth implica el uso <strong>de</strong> RF y a<strong>de</strong>más la frecuencia <strong>de</strong> operación está<br />
en la banda <strong>de</strong> los 2.4 GHz, las precauciones que se <strong>de</strong>ben tener en cuenta al<br />
trabajar en este rango <strong>de</strong> frecuencia son severas e indispensables. Las<br />
especificaciones <strong>de</strong>l fabricante se <strong>de</strong>ben cumplir con la mayor precisión posible y<br />
el sistema no se <strong>de</strong>be encerrar <strong>de</strong>ntro <strong>de</strong> <strong>una</strong> estructura metálica para evitar<br />
efectos similares al <strong>de</strong> <strong>una</strong> Jaula <strong>de</strong> Faraday, que pue<strong>de</strong> generar un bajo<br />
<strong>de</strong>sempeño.
• Antenas RangeStar 100929 y 100930. Las antenas RangeStar 100929 y<br />
100930 se caracterizan por tener un buen ancho <strong>de</strong> banda, alta ganancia en<br />
tamaño <strong>red</strong>ucido, son pequeñas, livianas y fáciles <strong>de</strong> usar. Las Figuras 2-13 y 2-14<br />
muestran las antenas RangeStar 100929 y 100930 respectivamente, al igual que<br />
el patrón <strong>de</strong> radiación para cada <strong>una</strong> <strong>de</strong> ellas. En la Tabla 2-2 se presentan las<br />
principales características <strong>de</strong> cada <strong>una</strong>.<br />
Figura 2-13. Antena RangeStar 100929<br />
Figura 2-14. Antena RangeStar 100930
Tabla 2-2. Características <strong>de</strong> las antenas RangeStar 100929 y 100930<br />
ANTENA RANGESTAR<br />
CARACTERÍSTICAS 100929 100930<br />
Aplicaciones<br />
Rango <strong>de</strong> Frecuencia<br />
(MHz)<br />
Bluetooth, 802.11b<br />
Teléfonos móviles, dispositivos portátiles, PDAs, aplicaciones<br />
industriales, instrumentos.<br />
2400 - 2483.5<br />
Pico <strong>de</strong> Ganancia > 4.5dBi > 4 dBi<br />
VSWR<br />
< 2.0 : 1 < 2.5 : 1<br />
Haz Omnidireccional Patrón Hemisférico<br />
Impedancia <strong>de</strong>l Punto<br />
<strong>de</strong> Alimentación<br />
50 Ohms<br />
Tamaño 29.0 x 11.6 x 3.0 mm 16mm diam. X 6.0mm<br />
Para el diseño <strong>de</strong>l PCB en las tarjetas BlueboardUV se tuvieron en cuenta varios<br />
requerimientos <strong>de</strong> antena tales como la distancia <strong>de</strong> aislamiento, el tamaño y<br />
localización <strong>de</strong> los pads para cada terminal, el área clara alre<strong>de</strong>dor <strong>de</strong> los pads, el<br />
área libre <strong>de</strong> componentes, el área clara alre<strong>de</strong>dor <strong>de</strong> la línea <strong>de</strong> alimentación <strong>de</strong><br />
la antena, entre otros [7]. Uno <strong>de</strong> los requerimientos más importantes es que la<br />
distancia <strong>de</strong>s<strong>de</strong> el pin <strong>de</strong> salida RF hasta la antena <strong>de</strong>be ser lo más corta posible.<br />
Los requerimientos <strong>de</strong> antena son diferentes para cada tipo <strong>de</strong> antena y se<br />
aplicaron con la mayor precisión posible. En la Figura 2-15 se pue<strong>de</strong>n observar las<br />
dos librerías creadas en el programa CAD para los dos tipos <strong>de</strong> antena utilizados.<br />
En ella se pue<strong>de</strong>n visualizar los diferentes requerimientos que se tuvieron en<br />
cuenta y que son necesarios para cada <strong>una</strong> <strong>de</strong> las antenas.
Figura 2-15. Requerimientos para las antenas RangeStar 100929 y100930<br />
2.1.2.4 Regulador <strong>de</strong> Voltaje National LP2987. Para la regulación <strong>de</strong> voltaje <strong>de</strong><br />
las tarjetas BlueboardUV se usó el regulador <strong>de</strong> voltaje National LP2987AIM 3.3.<br />
Éste es un regulador <strong>de</strong> voltaje <strong>de</strong> 200mA <strong>de</strong> salida fija con un reset <strong>de</strong> retardo <strong>de</strong><br />
encendido implementado con un capacitor externo. El voltaje regulado necesario<br />
en las tarjetas BlueboardUV es <strong>de</strong> 3.3V, con el cual se alimentan el módulo<br />
Bluetooth y el MAX232. El regulador tiene <strong>una</strong> salida <strong>de</strong> precisión <strong>de</strong> 0.5%. La<br />
Figura 2-16 muestra el diagrama <strong>de</strong> bloques para el LP2987. Para mayor<br />
información se pue<strong>de</strong> consultar la página web <strong>de</strong> National Semiconductors [8].
Figura 2-16. Diagrama <strong>de</strong> bloques <strong>de</strong>l regulador <strong>de</strong> voltaje LP2987<br />
Fuente: National Semiconductors<br />
2.1.2.5 MAXIM MAX3232. El MAXIM MAX3232 es <strong>una</strong> interfaz <strong>de</strong> comunicación<br />
con requerimientos <strong>de</strong> baja potencia. Este transceiver habilita el cambio en RS-<br />
232 <strong>de</strong> <strong>una</strong> alimentación <strong>de</strong> 3.0V a <strong>una</strong> <strong>de</strong> 5.5V. Tiene 2 receptores y 2 drivers. El<br />
MAX3232 solamente requiere cuatro pequeños capacitares externos <strong>de</strong> 0.1uF y es<br />
garantizado para correr a <strong>una</strong> rata <strong>de</strong> datos <strong>de</strong> 120kbps (MAX3232) o 250kbps<br />
(MAX3232E) manteniendo los niveles <strong>de</strong> salida RS-232. Para encontrar<br />
información más <strong>de</strong>tallada se pue<strong>de</strong> consultar en la página web <strong>de</strong> MAXIM [9].<br />
2.1.2.6 Soporte SUYIN BT001A-30G2T. Con el fin <strong>de</strong> hacer <strong>de</strong> las tarjetas<br />
BlueboardUV sistemas más flexibles, se utilizó <strong>una</strong> base soporte para el módulo<br />
<strong>de</strong> Ericsson ROK101007. El soporte es el Bluetooth Carrier Socket BT001A-<br />
30G2T <strong>de</strong> SUYIN CONNECTOR [6]. Este soporte permite intercambiar módulos<br />
sin necesidad <strong>de</strong> recurrir a <strong>de</strong>soldar las tarjetas. En la Figura 2-17 se pue<strong>de</strong>
observar la librería <strong>de</strong>l soporte que se implementó en el programa CAD para el<br />
diseño <strong>de</strong> las tarjetas. Éste posee 30 pines <strong>de</strong> conexión al igual que el módulo <strong>de</strong><br />
Ericsson utilizado.<br />
Figura 2-17. Bluetooth Carrier Socket SUYIN BT001A-30G2T<br />
2.1.3 Fotografías <strong>de</strong> las tarjetas BlueboardUV. Las Figuras 2-18 a 2-21<br />
muestran varias fotografías <strong>de</strong> las tarjetas BlueboardUV, en la Figura 2-20 se<br />
pue<strong>de</strong> observar la tarjeta BlueboardUV01 en funcionamiento, conectada a un PC<br />
por medio <strong>de</strong> un cable USB.
Figura 2-18. Tarjeta BlueboardUV01<br />
Figura 2-19. Módulo Bluetooth <strong>de</strong>ntro <strong>de</strong>l soporte en la tarjeta BlueboardUV01
Figura 2-20. Tarjeta BlueboardUV01 en funcionamiento<br />
Figura 2-21. Tarjeta BlueboardUV02
2.2 PRODUCTOS BLUETOOTH<br />
La oferta <strong>de</strong> productos Bluetooth en el mercado es muy amplia y variada. Existen<br />
productos <strong>de</strong> muchos tipos y <strong>de</strong> diversos fabricantes. Entre los tipos <strong>de</strong> productos<br />
más <strong>de</strong>stacados están: partes para integrar sistemas Bluetooth, tales como<br />
amplificadores, radio transceivers, controladores, antenas, módulos etc.;<br />
productos embebidos tales como kits, herramientas <strong>de</strong> <strong>de</strong>sarrollo, adaptadores<br />
USB, tarjetas PC, tarjetas PCMCIA y productos específicos muy variados; y por<br />
último, productos <strong>de</strong> software Bluetooth. En la Tabla 2-3 se nombra algunos <strong>de</strong><br />
ellos, sin embargo, se pue<strong>de</strong> encontrar información más <strong>de</strong>tallada <strong>de</strong> productos y<br />
fabricantes en el CD-ROM anexo a este libro.<br />
Tabla 2-3. Algunos productos Bluetooth disponibles en el mercado<br />
TIPO DE<br />
PRODUCTO<br />
FABRICANTE REFERENCIA<br />
MÓDULOS<br />
KITS<br />
MAS<br />
INFO.<br />
CSR BC01MOD2B [10]<br />
BLUEFROG rbm3rc-r [11]<br />
NATIONAL LMX982x [12]<br />
ERICSSON ROK101007 [5]<br />
ATMEL Blue Snake Kit AT76C551-BLSNK [13]<br />
BLUEFROG Development System [11]<br />
DIGIANSWER MkII Demo Card [14]<br />
Application and Training Tool Kit [5]<br />
TELECA Development Kit [5]<br />
3COM PC Card y adaptador USB [15]<br />
TARJETAS SMART Bluesapphire tarjeta PCMCIA [16]<br />
SOFTWARE<br />
TELECA<br />
Core Bluetooth Software Stack,<br />
Profiles, Bluetooth HCI Toolbox,<br />
Bluetooth Log Analyzer<br />
[5]
TIPO DE<br />
PRODUCTO<br />
OTROS<br />
FABRICANTE REFERENCIA<br />
ANOTO Bluetooth Pen<br />
TELECA Solución <strong>de</strong> audífonos Bluetooth<br />
MOTOROLA<br />
Remote Speaker Microphone<br />
HMN3158A<br />
2.3 PROCEDIMIENTO DE CALIFICACIÓN BLUETOOTH<br />
MAS<br />
INFO.<br />
El propósito <strong>de</strong> este sub-capítulo es brindar <strong>una</strong> <strong>de</strong>scripción <strong>de</strong>l procedimiento que<br />
se <strong>de</strong>be seguir para calificar un producto como Producto Bluetooth. Con el<br />
propósito <strong>de</strong> minimizar o eliminar problemas <strong>de</strong> interoperatividad el Bluetooth<br />
Qualification Program (BQP) ha <strong>de</strong>finido un grupo específico <strong>de</strong> procedimientos.<br />
Este es un requerimiento necesario antes <strong>de</strong> que un producto pueda ser calificado<br />
<strong>de</strong> acuerdo con Bluetooth. La calificación Bluetooth es el proceso mediante el cual<br />
un fabricante <strong>de</strong>muestra conformidad con la especificación Bluetooth y el BQP es<br />
la base que establece las reglas y procedimientos <strong>de</strong> calificación. El BQP fue<br />
creado in<strong>de</strong>pendientemente <strong>de</strong> algún tipo <strong>de</strong> aprobación administrativa obligatoria<br />
<strong>de</strong> reglamentaciones nacionales o internacionales.<br />
Un fabricante <strong>de</strong> productos con la tecnología <strong>inalámbrica</strong> Bluetooth <strong>de</strong>be<br />
suscribirse al contrato <strong>de</strong> membresía <strong>de</strong>l SIG Bluetooth. Cuando el producto<br />
cumple con la especificación Bluetooth, es adicionado a la lista <strong>de</strong> productos<br />
Bluetooth. Esto otorga a la Compañía Miembro <strong>una</strong> licencia que cubre los<br />
<strong>de</strong>rechos <strong>de</strong> patente <strong>de</strong> la propiedad intelectual <strong>de</strong> <strong>de</strong>rechos <strong>de</strong> autor y le permite<br />
usar la marca Bluetooth en productos y activida<strong>de</strong>s <strong>de</strong> merca<strong>de</strong>o <strong>de</strong> acuerdo con<br />
el libro <strong>de</strong> la marca Bluetooth. Información más <strong>de</strong>tallada acerca <strong>de</strong> la calificación<br />
[17]<br />
[5]<br />
[18]
Bluetooth se pue<strong>de</strong> encontrar en enlace Developer Information ->Qualification<br />
Program <strong>de</strong> la página oficial <strong>de</strong> Bluetooth [19].<br />
2.4 ANTENAS EN F INVERTIDA INTEGRADAS<br />
Una buena posibilidad para la construcción <strong>de</strong> PCBs que impliquen el uso <strong>de</strong><br />
antenas, es el diseño <strong>de</strong> Antenas en F Invertida (IFAs). Estas antenas tienen <strong>una</strong><br />
estructura <strong>de</strong> bajo perfil, son livianas y fáciles <strong>de</strong> integrar en equipos <strong>de</strong><br />
comunicación personales. A pesar <strong>de</strong> que en esta tesis no se implementó <strong>una</strong><br />
antena <strong>de</strong> este tipo, la información que se <strong>de</strong>scribe a continuación acerca <strong>de</strong> este<br />
tema pue<strong>de</strong> resultar muy útil para posteriores proyectos.<br />
Existen tres clases <strong>de</strong> IFAs: las IFAs con elementos convencionales, las antenas<br />
en F invertida planares (PIFAs) y las Antenas en F Invertida Integradas (IIFAs).<br />
Para hacer más compactas las IFAs, los elementos <strong>de</strong> la antena se pue<strong>de</strong>n<br />
imprimir en el plano superior <strong>de</strong>l substrato <strong>de</strong>l PCB, para formar <strong>una</strong> IIFA. Este tipo<br />
<strong>de</strong> antenas ya se ha usado en aplicaciones Bluetooth [20]. Esto significa que al<br />
diseñar un sistema inalámbrico, no se hace obligatoria la compra o adquisición <strong>de</strong><br />
<strong>una</strong> antena sino que se pue<strong>de</strong> diseñar en el PCB. En el diseño <strong>de</strong> este tipo <strong>de</strong><br />
antenas se tienen en cuenta parámetros tales como el espesor, la constante<br />
dieléctrica y la característica <strong>de</strong> impedancia <strong>de</strong>l substrato, así como la separación<br />
y el ancho <strong>de</strong> las líneas y por supuesto la frecuencia <strong>de</strong> operación. Se pue<strong>de</strong><br />
conseguir información más <strong>de</strong>tallada en distintas fuentes incluso en la web [20]<br />
[21]. En la Figura 2-22 se observa un esbozo <strong>de</strong> <strong>una</strong> Antena en F Invertida<br />
Integrada (IIFA).
Figura 2-22. Antena en F Invertida Integrada (IIFA)
3. SOFTWARE PARA EL HOST BLUETOOTH<br />
El software para el host Bluetooth correspon<strong>de</strong> a las capas <strong>de</strong>l stack <strong>de</strong><br />
protocolos y utilida<strong>de</strong>s Bluetooth implementadas en software e instaladas en el<br />
host. Un host pue<strong>de</strong> ser cualquier sistema microprocesado programable (PCs,<br />
teléfonos celulares, mouse, impresoras, teclados, sensores inalámbricos, etc.),<br />
capaz <strong>de</strong> ejecutar las líneas <strong>de</strong> código correspondientes al stack <strong>de</strong> protocolos<br />
para el host. En esta plataforma es necesario tener <strong>una</strong> interfaz UART o USB<br />
para comunicar el host y el módulo Bluetooth.<br />
Son muchos los stacks <strong>de</strong> protocolos Bluetooth disponibles para el host,<br />
implementados en diversos lenguajes <strong>de</strong> programación y sobre distintas<br />
plataformas, siendo también muchas las empresas interesadas en su <strong>de</strong>sarrollo.<br />
In<strong>de</strong>pendientemente <strong>de</strong> la plataforma o el lenguaje <strong>de</strong> programación, estos se<br />
basan en el CORE [3] y los PROFILES [4] <strong>de</strong> la especificación <strong>de</strong>l sistema<br />
Bluetooth.
Figura 3-1. Mo<strong>de</strong>lo <strong>de</strong> <strong>implementación</strong> <strong>de</strong>l protocolo Bluetooth, Host – Hardware<br />
La Figura 3-1 muestra un mo<strong>de</strong>lo <strong>de</strong> <strong>implementación</strong> <strong>de</strong>l stack <strong>de</strong> protocolos<br />
Bluetooth, discriminando las capas que están implementadas en el host y las que<br />
están en el Hardware Bluetooth (módulos, tarjetas, sistemas <strong>de</strong> <strong>de</strong>sarrollo<br />
Bluetooth), como es el caso <strong>de</strong> las tarjetas Blueboard_UV01 y Blueboard_UV02<br />
<strong>de</strong>sarrolladas en esta tesis.
Figura 3-2. Mo<strong>de</strong>lo <strong>de</strong> Implementación <strong>de</strong>l protocolo Bluetooth. Software – Firmware –<br />
Hardware<br />
La Figura 3-2 <strong>de</strong>scribe esquemáticamente la <strong>implementación</strong> <strong>de</strong>l stack <strong>de</strong><br />
protocolos Bluetooth al nivel <strong>de</strong> software, firmware y hardware, especificando su<br />
ubicación ya sea en el host o en el hardware Bluetooth.<br />
El host y el hardware Bluetooth se comunican a través <strong>de</strong>l HCI (Host Controller<br />
Interface) o Interfaz Controladora <strong>de</strong> host. El firmware HCI implementa los<br />
Comandos HCI para el hardware Bluetooth teniendo acceso a los comandos <strong>de</strong>
anda base, manejador <strong>de</strong> enlace, registros <strong>de</strong> estatus <strong>de</strong>l hardware, registros <strong>de</strong><br />
control y registros <strong>de</strong> eventos.<br />
Muchas capas pue<strong>de</strong>n existir entre el driver HCI ubicado en el host y el firmware<br />
HCI ubicado en el hardware Bluetooth. Estas capas intermedias, se encargan <strong>de</strong>l<br />
control y transporte <strong>de</strong> datos a través <strong>de</strong> un medio físico (un bus físico ya sea<br />
USB, PC Card, RS232, u otro), para que se establezca <strong>una</strong> comunicación<br />
transparente entre el driver HCI y el firmware HCI, permitiendo el intercambio <strong>de</strong><br />
datos y comandos entre estos dos.<br />
El host recibirá notificaciones asíncronas <strong>de</strong> los eventos HCI in<strong>de</strong>pendientemente<br />
<strong>de</strong> la capa <strong>de</strong> control <strong>de</strong> transporte <strong>de</strong>l host que se esté usando. Los eventos HCI<br />
son usados para notificar al host cuando algo ocurre.<br />
3.1 ARQUITECTURAS DE INTEGRACIÓN DEL STACK DE<br />
PROTOCOLOS BLUETOOTH<br />
La mayor o menor integración <strong>de</strong>l stack <strong>de</strong> protocolos Bluetooth en un sistema,<br />
<strong>de</strong>pen<strong>de</strong> <strong>de</strong>l tipo <strong>de</strong> producto que se está <strong>de</strong>sarrollando; <strong>de</strong> esta manera y como<br />
se pue<strong>de</strong> observar en la Figura 3-3, tres diferentes arquitecturas podrían<br />
implementarse. Cabe resaltar que no son las únicas.
Figura 3-3. Tres mo<strong>de</strong>los <strong>de</strong> Integración <strong>de</strong>l stack <strong>de</strong> protocolos Bluetooth<br />
La Figura 3-3 a <strong>de</strong>scribe <strong>una</strong> solución estándar <strong>de</strong> dos procesadores, en don<strong>de</strong> la<br />
división entre las capas altas <strong>de</strong> protocolo y las bajas toma lugar en el HCI, esto<br />
asume que el host es en general algún tipo <strong>de</strong> plataforma computacional cuyas<br />
capacida<strong>de</strong>s <strong>de</strong> comunicación son “ilimitadas”. Este es el caso <strong>de</strong> las<br />
computadoras personales.<br />
En la Figura 3-3 b se pue<strong>de</strong> observar <strong>una</strong> arquitectura embebida <strong>de</strong> dos<br />
procesadores, la cual permite que los productos puedan diseñarse para incorporar<br />
Bluetooth don<strong>de</strong> el host es un recurso limitado y no es capaz <strong>de</strong> soportar la
adición <strong>de</strong> <strong>una</strong> funcionalidad Bluetooth. Un ejemplo <strong>de</strong> este caso es un teléfono<br />
móvil; no todos los teléfonos móviles tienen los suficientes recursos para<br />
implementar pilas <strong>de</strong> protocolo adicionales.<br />
La Figura 3-3 c muestra <strong>una</strong> arquitectura embebida <strong>de</strong> un procesador; este es el<br />
caso <strong>de</strong> un producto que implementa el stack <strong>de</strong> protocolos Bluetooth completo<br />
en un solo chip. Un ejemplo es un “manos libres” inalámbrico, sin embargo, el<br />
mo<strong>de</strong>lo aplica a cualquier dispositivo inalámbrico pequeño [22].<br />
3.2 PRINCIPALES SOFTWARE PARA EL HOST<br />
Son muchas las compañías que trabajan en el <strong>de</strong>sarrollo <strong>de</strong> stacks <strong>de</strong> protocolos<br />
Bluetooth para el host, en especial, los fabricantes <strong>de</strong> módulos Bluetooth, quienes<br />
ofrecen productos <strong>de</strong> prueba y kits <strong>de</strong> <strong>de</strong>sarrollo que incluyen software para el<br />
host, cuya finalidad es facilitar y agilizar el <strong>de</strong>sarrollo <strong>de</strong> aplicaciones. Este<br />
software no es usualmente <strong>de</strong> libre distribución, es <strong>de</strong>cir que su licencia tiene un<br />
costo, el cual, en la mayoría <strong>de</strong> los casos, está incluido en el costo <strong>de</strong>l kit <strong>de</strong><br />
<strong>de</strong>sarrollo.<br />
Sin embargo, los fabricantes <strong>de</strong> módulos Bluetooth no son los únicos que ofrecen<br />
software para el host, hay muchas otras empresas y universida<strong>de</strong>s interesadas en<br />
su <strong>de</strong>sarrollo, razón por la cual es posible encontrar software <strong>de</strong>mostrativo y <strong>de</strong><br />
libre distribución con licencia pública GPL (GNU Public License).<br />
En esta tesis se trata únicamente el software para sistemas cuyo host<br />
correspon<strong>de</strong> a un PC, es <strong>de</strong>cir, no se cubre software para sistemas embebidos.
Los requerimientos tales como sistema operativo, capacidad <strong>de</strong> memoria, entre<br />
otros, son propios <strong>de</strong> cada software.<br />
3.2.1 Software Bluetooth con propiedad <strong>de</strong> licencia.<br />
Debido a que muchas <strong>de</strong> las características <strong>de</strong> estos diferentes tipos <strong>de</strong> software<br />
son muy parecidas, se da <strong>una</strong> breve <strong>de</strong>scripción <strong>de</strong> los más representativos.<br />
� Bluetooth Host Stack Software para el host <strong>de</strong>sarrollado por Ericsson, el<br />
cual implementa las siguientes capas <strong>de</strong>l stack <strong>de</strong> protocolos: driver HCI,<br />
L2CAP, RFCOMM, SDP y opcionalmente OBEX y TCS. Este stack está<br />
escrito en ANSI C, y es in<strong>de</strong>pendiente <strong>de</strong>l ambiente <strong>de</strong> <strong>de</strong>sarrollo (compilador,<br />
<strong>de</strong>bugger, linker, etc.); esto sumado al concepto <strong>de</strong> Sistema Operativo Virtual,<br />
hace que este stack, sea adaptable tanto a sistemas operativos para sistemas<br />
embebidos como a los sistemas operativos estándar tales como Linux y<br />
Windows. Las siguientes son herramientas <strong>de</strong> software disponibles para<br />
Windows, basadas en el Bluetooth Host Stack <strong>de</strong> Ericsson: Bluetooth PC<br />
reference Stack, Bluetooth Development Kit y Bluetooth Application Tool Kit<br />
[23].<br />
� Bluetooth Software Suite Desarrollado por Digianswer A/S, este software<br />
escrito para Microsoft Windows a<strong>de</strong>más <strong>de</strong> brindar un API (Interfaz <strong>de</strong><br />
Programa <strong>de</strong> Aplicación) <strong>de</strong> fácil uso, soporta los siguientes perfiles: acceso<br />
general, servicio <strong>de</strong> <strong>de</strong>scubrimiento <strong>de</strong> aplicaciones, puerto serial, <strong>red</strong> <strong>de</strong><br />
acceso conmutado, fax, acceso a LAN, OBEX, Object Push, transferencia <strong>de</strong><br />
archivos y Ethernet [24].
� BlueStack Software <strong>de</strong>sarrollado por MEZOE, <strong>una</strong> división <strong>de</strong> Cambridge<br />
Consultants Ltd. Escrito en lenguaje C, implementa al igual que los dos<br />
anteriores, un driver HCI y las capas superiores <strong>de</strong>l protocolo Bluetooth. Son<br />
ofrecidos varios productos basados en el BlueStack para Microsoft Windows:<br />
este es el caso <strong>de</strong> StackPrimer, Proto Developer e Interface Express [22].<br />
La Tabla 3-1 muestra <strong>una</strong> recopilación <strong>de</strong> algunos productos con propiedad <strong>de</strong><br />
licencia que implementan el stack <strong>de</strong> protocolos Bluetooth para el host; se indica<br />
a<strong>de</strong>más la empresa que lo <strong>de</strong>sarrolla, herramientas <strong>de</strong> <strong>de</strong>sarrollo para cada stack<br />
y el sistema operativo sobre el cual corre.<br />
Tabla 3-1. Software Bluetooth para el Host con propiedad <strong>de</strong> licencia<br />
NOMBRE DEL<br />
STACK<br />
Bluetooth Host<br />
Snack<br />
Bluetooth<br />
Software Suite<br />
FABRICANTE HERRAMIENTAS DE<br />
DESARROLLO<br />
Ericsson • Bluetooth PC reference<br />
Stack<br />
• Bluetooth Development<br />
Kit<br />
• Bluetooth Application<br />
Tool Kit<br />
Digianswer A/S • Digianswer Bluetooth<br />
Software Suite<br />
• Digianswer Bluetooth<br />
HCI<br />
• Digianswer Bluetooth<br />
Statistics<br />
• Digianswer Bluetooth<br />
HCI Router<br />
• Digianswer HCI Test<br />
Application<br />
• Digianswer API<br />
SISTEMA OPERATIVO<br />
SOPORTADO POR LA<br />
HERRAMIENTA<br />
Microsoft Windows<br />
Microsoft Windows<br />
BlueStack Mezoe • Proto Developer Tool Microsoft Windows<br />
Stack Partner<br />
Program<br />
National<br />
Semiconductor<br />
• Stack Partner Program • Microsoft Win98, ME,<br />
2000 y XP<br />
• Microsoft WinCE<br />
• Linux
NOMBRE DEL<br />
STACK<br />
Rappore<br />
Technologies'<br />
Software<br />
Developers Kit<br />
Socket Bluetooth<br />
Software<br />
BlueStack<br />
Software<br />
Development Kit<br />
Bluefrog<br />
Demostration<br />
FrogStack<br />
FABRICANTE HERRAMIENTAS DE<br />
DESARROLLO<br />
Rappore<br />
Technologies<br />
• Software Developers Kit<br />
SISTEMA OPERATIVO<br />
SOPORTADO POR LA<br />
HERRAMIENTA<br />
• No especificado<br />
• Código fuente<br />
<strong>de</strong>sarrollado en lenguaje<br />
C, C++ y Java<br />
Socket • Bluetooth Connection Kit • Windows Powe<strong>red</strong><br />
Pocket PC<br />
Cambridge<br />
Silicon Radio<br />
Reselec ag<br />
Bluefrog<br />
• BlueStack Software<br />
Development Kit<br />
• Bluefrog Demostration<br />
FrogSatck<br />
3.2.2 Software Bluetooth con licencia pública (GPL)<br />
• Windows CE<br />
• Windows NT<br />
• Net OS 3.0<br />
• Linux<br />
En esta sección se tratan las principales características <strong>de</strong> los tipos <strong>de</strong> productos<br />
<strong>de</strong> libre distribución con licencia GPL <strong>de</strong>sarrollados para Linux y disponibles en<br />
Internet. Los principales son: OpenBT, BlueDrekar, Bluez y Affix.<br />
� OpenBT Axis Communications Inc. <strong>de</strong>sarrolló, en primera instancia, un driver<br />
Bluetooth para Linux llamado OpenBT, el cual pue<strong>de</strong> ser usado tanto en<br />
ambientes eLinux (Linux Embebido) como en Linux para PC. Este fue el primer<br />
stack <strong>de</strong> protocolos disponible, siendo ahora un proyecto <strong>de</strong> código fuente<br />
abierto, <strong>de</strong>sarrollado en un kernel <strong>de</strong> Linux 2.0.33, <strong>de</strong> tal manera que no <strong>de</strong>be<br />
presentar problemas <strong>de</strong> funcionamiento en versiones posteriores <strong>de</strong>l kernel.<br />
Implementa el perfil <strong>de</strong> LAN mediante enlaces PPP sobre RFCOMM y a<strong>de</strong>más<br />
<strong>una</strong> forma simple <strong>de</strong>l perfil <strong>de</strong> <strong>de</strong>scubrimiento <strong>de</strong> servicios (SDPP) [25].<br />
El código fuente en sus versiones para PC y eLinux, se encuentra disponible<br />
en el portal <strong>de</strong> Internet <strong>de</strong> Sourceforge [26], y es posible conseguir más<br />
información en el portal <strong>de</strong>l proyecto [27].
� BlueDrekar El driver Bluetooth <strong>de</strong> IBM, disponible bajo licencia GPL,<br />
implementa la capa <strong>de</strong> transporte UART <strong>de</strong> la Interfaz Controladora <strong>de</strong>l host<br />
(HCI). Este código sirve <strong>de</strong> referencia para escribir drivers para otras capas <strong>de</strong><br />
transporte HCI, como USB. El BlueDrekar middleware es <strong>una</strong> <strong>implementación</strong><br />
<strong>de</strong> referencia <strong>de</strong> las capas altas <strong>de</strong>l protocolo Bluetooth, disponible bajo<br />
licencia alpha Works [28].<br />
Según el fabricante, este código ha sido <strong>de</strong>sarrollado y probado en PCs con<br />
procesadores <strong>de</strong> arquitectura i486 o superior, corriendo un kernel <strong>de</strong> Linux<br />
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<br />
sido utilizados para realizar las pruebas <strong>de</strong> <strong>de</strong>sempeño los módulos Bluetooth<br />
<strong>de</strong> Ericsson con la capa <strong>de</strong> transporte UART y firmware versión P7C (v1.0A) y<br />
P3E (v1.0B).<br />
� Affix Este stack <strong>de</strong> protocolo para Linux fue <strong>de</strong>sarrollado por el Centro <strong>de</strong><br />
Investigación <strong>de</strong> Nokia en Helsinki, Finlandia. El software Bluetooth <strong>de</strong> Affix<br />
trabaja sobre plataformas Intel, ARM (iPaq, ARM9 y otras) y PowerPC (iMac).<br />
Las últimas versiones <strong>de</strong>l software están disponibles en el sitio web <strong>de</strong> Affix<br />
[29].<br />
� Bluez Este es el stack <strong>de</strong> protocolos Bluetooth oficial <strong>de</strong> Linux, el cual es<br />
parte <strong>de</strong>l kernel 2.4 y posteriores. Bluez brinda a sus usuarios la capacidad <strong>de</strong><br />
comunicación con dispositivos Bluetooth, entre los que se tienen adaptadores<br />
USB, teléfonos móviles y puntos <strong>de</strong> acceso entre otros, a<strong>de</strong>más <strong>de</strong> conexión<br />
<strong>inalámbrica</strong> entre dos o más computadoras. Bluez consta <strong>de</strong>l core HCI,<br />
drivers HCI para UART, USB y emulador <strong>de</strong> HCI, módulo <strong>de</strong>l protocolo L2CAP<br />
y utilida<strong>de</strong>s <strong>de</strong> configuración y prueba [30].
3.3 CONCEPTOS DEL CORE DE LINUX<br />
Estos conceptos básicos sobre el subsistema <strong>de</strong> <strong>red</strong> <strong>de</strong> Linux son fundamentales<br />
para enten<strong>de</strong>r la manera como los drivers para los dispositivos <strong>de</strong> <strong>red</strong> (tarjetas <strong>de</strong><br />
<strong>red</strong>) interactúan con el sistema operativo, in<strong>de</strong>pendientemente <strong>de</strong>l protocolo con el<br />
que operan (Ethernet, X.25, Bluetooth, etc.). Estos conceptos son tomados <strong>de</strong>l<br />
documento Affix in a Nutshell [31], disponible en el sitio web <strong>de</strong> Affix [29].<br />
El sistema operativo Linux implementa el socket API estándar <strong>de</strong> Berkeley,<br />
<strong>de</strong>sarrollado para UNIX. La figura 3-4 <strong>de</strong>scribe la arquitectura <strong>de</strong>l subsistema <strong>de</strong><br />
<strong>red</strong> <strong>de</strong> Linux, don<strong>de</strong> sus componentes estándar son: interfaz <strong>de</strong>l Socket Berkeley<br />
y la interfaz <strong>de</strong>l driver <strong>de</strong>l dispositivo <strong>de</strong> <strong>red</strong> (Network Device Driver Interface).<br />
Figura 3-4. Arquitectura <strong>de</strong> Red <strong>de</strong> Linux
La interfaz <strong>de</strong>l socket Berkeley permite a los programas abrir terminales <strong>de</strong><br />
comunicaciones para dispositivos remotos en el espacio <strong>de</strong> usuario. El socket es<br />
<strong>una</strong> abstracción <strong>de</strong> <strong>red</strong> para los terminales <strong>de</strong> un canal y está asociado con el<br />
protocolo; usualmente, el PF_INET es usado para asociar un socket con el<br />
protocolo TCP/IP.<br />
La interfaz <strong>de</strong>l driver <strong>de</strong>l dispositivo <strong>de</strong> <strong>red</strong> permite el uso simultáneo <strong>de</strong> múltiples<br />
dispositivos <strong>de</strong> <strong>red</strong>, cada uno <strong>de</strong> los cuales tiene un tipo apropiado para distinguir<br />
la clase <strong>de</strong> dispositivo a la cual pertenece, es <strong>de</strong>cir, Ethernet, PPP, X.25, etc. El<br />
driver <strong>de</strong>l dispositivo registra el dispositivo <strong>de</strong> <strong>red</strong> en el sistema.<br />
La interfaz <strong>de</strong>l driver <strong>de</strong> <strong>red</strong> incluye un paquete encargado <strong>de</strong> organizar los<br />
diferentes tipos <strong>de</strong> dispositivos (Packet Scheduler), para lo cual implementa <strong>una</strong><br />
disciplina <strong>de</strong> colas.<br />
La capa <strong>de</strong> protocolo correspon<strong>de</strong> al protocolo que se está implementando. Cada<br />
protocolo <strong>de</strong>be registrarse por si mismo tanto en la interfaz <strong>de</strong>l socket con la<br />
familia <strong>de</strong> protocolo (PF_XXX) apropiada como en la interfaz <strong>de</strong>l driver <strong>de</strong>l<br />
dispositivo con el tipo <strong>de</strong> protocolo apropiado. De esta manera cada paquete<br />
recibido será entregado a la capa <strong>de</strong> protocolo correspondiente.<br />
Tanto en este diseño como en la mayoría <strong>de</strong> los kernel <strong>de</strong> Linux la capa <strong>de</strong> <strong>red</strong> es<br />
orientada a objetos, siendo estos los objetos más importantes:
• Dispositivo o Interfaz: Una interfaz <strong>de</strong> <strong>red</strong> es el código programado para<br />
enviar y recibir paquetes <strong>de</strong> datos. Usualmente <strong>una</strong> interfaz se usa para un<br />
dispositivo como es el caso <strong>de</strong> <strong>una</strong> tarjeta Ethernet; sin embargo, muchos<br />
dispositivos correspon<strong>de</strong>n únicamente a software, como es el caso <strong>de</strong>l<br />
dispositivo <strong>de</strong> realimentación (loopback) usado para el envío <strong>de</strong> datos <strong>de</strong>ntro<br />
<strong>de</strong>l mismo sistema.<br />
• Protocolo: Cada protocolo es un lenguaje diferente <strong>de</strong> <strong>red</strong>. En el kernel <strong>de</strong><br />
Linux cada protocolo correspon<strong>de</strong> a un módulo <strong>de</strong> código aparte el cual brinda<br />
servicios a la capa <strong>de</strong>l socket.<br />
• Socket: Es un terminal <strong>de</strong> conexión que suministra un archivo <strong>de</strong><br />
entrada/salida (I/O) y existe como un archivo <strong>de</strong>scriptor para el programa <strong>de</strong><br />
usuario. En el kernel cada socket correspon<strong>de</strong> a un par <strong>de</strong> estructuras que<br />
representan el nivel alto <strong>de</strong> la interfaz <strong>de</strong>l socket y el nivel bajo <strong>de</strong> la interfaz<br />
<strong>de</strong> protocolo.<br />
• Sk_buff: Todos los buffers usados por las capas <strong>de</strong> <strong>red</strong> son sk_buffs. El<br />
control <strong>de</strong> estos buffers es suministrado por las rutinas <strong>de</strong> bajo nivel <strong>de</strong>l Core<br />
<strong>de</strong> librerías, disponible para todo el sistema <strong>de</strong> <strong>red</strong>. Estas primitivas (sk_buffs)<br />
brinda los buffers generales y las facilida<strong>de</strong>s <strong>de</strong> control <strong>de</strong> flujo que necesitan<br />
los protocolos <strong>de</strong> <strong>red</strong>.<br />
Para probar el <strong>de</strong>sempeño <strong>de</strong> las tarjetas Blueboard_UV01 y Blueboard_UV02, en<br />
esta tesis se utilizaron como herramientas <strong>de</strong> software los stacks <strong>de</strong> protocolos <strong>de</strong><br />
Affix y Bluez. Por esta razón a continuación se hace <strong>una</strong> <strong>de</strong>scripción más<br />
<strong>de</strong>tallada <strong>de</strong> estos stacks <strong>de</strong> protocolos, en cuanto a su instalación, principales<br />
características y utilida<strong>de</strong>s.
3.4 DESCRIPCIÓN DEL STACK DE PROTOCOLOS DE AFFIX<br />
El stack <strong>de</strong> protocolos <strong>de</strong> Affix fue <strong>de</strong>sarrollado en el Laboratorio <strong>de</strong> Re<strong>de</strong>s<br />
Móviles <strong>de</strong>l Centro <strong>de</strong> Investigación <strong>de</strong> Nokia, bajo licencia GPL, sin ser un<br />
producto oficial <strong>de</strong> Nokia.<br />
La información contenida aquí es <strong>una</strong> recopilación <strong>de</strong> los más importantes apartes<br />
<strong>de</strong>l documento Affix in a Nutshell [31], disponible en el sitio web <strong>de</strong> Affix [29].<br />
Affix soporta los protocolos <strong>de</strong>l Core Bluetooth HCI, L2CAP, RFCOMM, SDP y<br />
varios <strong>de</strong> los perfiles. A<strong>de</strong>más tiene <strong>una</strong> <strong>implementación</strong> modular, <strong>una</strong> interfaz<br />
socket para los protocolos HCI, L2CAP y RFCOMM, es in<strong>de</strong>pendiente <strong>de</strong> la<br />
interfaz <strong>de</strong>l módulo Bluetooth y soporta múltiples dispositivos Bluetooth.<br />
3.4.1 Arquitecturas Soportadas<br />
Affix soporta las siguientes arquitecturas:<br />
• i386<br />
• ARM (por ejemplo Compaq iPaq)<br />
• PowerPC (por ejemplo iMac)<br />
• Sparc<br />
En general Affix se pue<strong>de</strong> ejecutar en cualquier arquitectura que corra bajo Linux.
3.4.2 Hardware Soportado<br />
En principio Affix soporta todos los dispositivos que cumplan con la especificación<br />
Bluetooth. La lista completa <strong>de</strong>l hardware soportado se pue<strong>de</strong> consultar en el sitio<br />
<strong>de</strong> Affix en Internet [29] o en el CD ROM que acompaña este libro.<br />
Affix soporta los siguientes perfiles Bluetooth:<br />
• Perfil <strong>de</strong> acceso general<br />
• Perfil <strong>de</strong> <strong>de</strong>scubrimiento <strong>de</strong> servicios<br />
• Perfil <strong>de</strong> puerto serial<br />
• Perfil <strong>de</strong> acceso conmutado a la <strong>red</strong> (Red Dial-Up)<br />
• Perfil <strong>de</strong> acceso a LAN<br />
• Perfil OBEX Object Push<br />
• Perfil OBEX File Transfer<br />
• Perfil <strong>de</strong> <strong>red</strong> <strong>de</strong> área personal (PAN)<br />
Affix consta <strong>de</strong> los siguientes paquetes:<br />
• Affix Kernel<br />
• Affix<br />
A<strong>de</strong>más ofrece herramientas <strong>de</strong> control, librerías y <strong>de</strong>monios <strong>de</strong> servicios.<br />
3.4.3 Arquitectura <strong>de</strong> Affix<br />
La arquitectura general <strong>de</strong> Affix se pue<strong>de</strong> observar en la Figura 3-5. En general el<br />
software <strong>de</strong> Affix pue<strong>de</strong> ser dividido en dos componentes:<br />
• Componente <strong>de</strong> protocolo, el cual implementa el stack <strong>de</strong> protocolo.
• Componente <strong>de</strong> Administración o <strong>de</strong> Manejo, el cual controla el componente<br />
<strong>de</strong> protocolo y representa la parte inteligente <strong>de</strong>l software.<br />
Figura 3-5. Mo<strong>de</strong>lo <strong>de</strong> la Arquitectura <strong>de</strong> Affix<br />
La filosofía UNIX (y Linux) es que el kernel <strong>de</strong>be brindar los mecanismos básicos y<br />
las aplicaciones <strong>de</strong>ben implementar la lógica en el espacio <strong>de</strong> usuario [32]. Los<br />
beneficios <strong>de</strong> tener más funcionalidad en el espacio <strong>de</strong> usuario radican en la<br />
facilidad en el proceso <strong>de</strong> <strong>implementación</strong> y mayor estabilidad <strong>de</strong>l sistema ya que<br />
en caso <strong>de</strong> presentarse errores estos se localizan en la aplicación, en don<strong>de</strong> es<br />
posible usar muchas herramientas <strong>de</strong> <strong>de</strong>puración.<br />
De acuerdo a esta filosofía, el stack <strong>de</strong> protocolos <strong>de</strong> Affix corre en el espacio <strong>de</strong><br />
kernel mientras que la Entidad <strong>de</strong> Manejo ME (Management Entity) corre en el<br />
espacio <strong>de</strong> usuario. Todo el tráfico <strong>de</strong> paquetes <strong>de</strong> la <strong>red</strong> viene a Affix <strong>de</strong>s<strong>de</strong> el<br />
espacio <strong>de</strong> kernel, <strong>de</strong> modo que por razones <strong>de</strong> <strong>de</strong>sempeño, <strong>una</strong> óptima solución<br />
es implementar aquí el core <strong>de</strong> protocolos.
La ME complementa la funcionalidad <strong>de</strong>l stack <strong>de</strong> protocolos Bluetooth, siendo<br />
implementada como <strong>una</strong> aplicación en el espacio <strong>de</strong> usuario. Es posible reimplementar<br />
la ME sin modificar el código en el espacio <strong>de</strong> kernel. Un diagrama<br />
práctico <strong>de</strong> los componentes <strong>de</strong> Affix se muestra en la Figura 3-6.<br />
Figura 3-6. Diagrama <strong>de</strong> los Componentes <strong>de</strong> Affix
Si se necesita información a cerca <strong>de</strong> los mo<strong>de</strong>los <strong>de</strong> seguridad <strong>de</strong> Affix, el API y<br />
el socket <strong>de</strong> familia PF_AFFIX, esta se encuentra en el CD ROM que acompaña<br />
este libro (versión en español) o en el sitio <strong>de</strong> Affix en Internet [29][31].<br />
3.4.4 Utilida<strong>de</strong>s <strong>de</strong> Affix<br />
Affix incluye <strong>una</strong> utilidad <strong>de</strong> control (btctl) y un “súper servidor” (btsrv). Una<br />
<strong>de</strong>scripción completa <strong>de</strong> los comandos <strong>de</strong> estas utilida<strong>de</strong>s, se pue<strong>de</strong> encontrar en<br />
las páginas <strong>de</strong>l manual, el cual está incluido en los paquetes instalados por Affix<br />
[29] o en el CD ROM anexo a este libro (versión en español).<br />
3.4.5 Instrucciones <strong>de</strong> Instalación<br />
Affix se compone <strong>de</strong> dos paquetes: affix y affix-kernel. affix contiene los archivos<br />
fuente para compilar e instalar los programas <strong>de</strong>l modo <strong>de</strong> usuario y affix-kernel<br />
las fuentes para compilar los módulos <strong>de</strong>l kernel.<br />
� Paquete affix-kernel. Los siguientes son los pasos para compilar e instalar<br />
affix-kernel:<br />
1. Copiar el archivo affix-kernel-xxx-kernel-xxx.tgz en el directorio /usr/src<br />
2. Desempaquetar el archivo:<br />
tar -xzvf affix-kernel-xxx-kernel-xxx.tgz<br />
3. Correr el script <strong>de</strong> configuración y contestar las preguntas (s/n)<br />
<strong>de</strong>pendiendo <strong>de</strong> la configuración <strong>de</strong>seada:<br />
make config<br />
4. Compilar las fuentes:<br />
make all
5. Instalar el paquete (requiere privilegios <strong>de</strong> root):<br />
make install<br />
6. Actualizar los alias <strong>de</strong> protocolo: Esto es requerido para que los módulos <strong>de</strong><br />
Affix se carguen automáticamente cuando las aplicaciones necesiten<br />
soporte <strong>de</strong> Affix. Si la distribución <strong>de</strong> Linux es diferente <strong>de</strong> Debian, <strong>de</strong>be<br />
adicionarse las siguientes líneas en el archivo /etc/modules.conf:<br />
alias net-pf-27 affix<br />
alias char-major-60 affix_rfcomm<br />
� Paquete affix<br />
Para compilar e instalar el paquete affix se <strong>de</strong>ben seguir los siguientes pasos:<br />
1. Copiar el paquete affix-xxx.tgz en el directorio /usr/src<br />
2. Desempaquetar el archivo:<br />
tar –xzvf affix-xxx.tgz<br />
3. Correr el script <strong>de</strong> configuración:<br />
./configure<br />
4. Compilar el paquete:<br />
make<br />
5. Instalar el paquete (requiere privilegios <strong>de</strong> root):<br />
make install<br />
3.5 DESCRIPCIÓN DEL STACK DE PROTOCOLOS BLUEZ<br />
Bluez es el stack Bluetooth oficial <strong>de</strong> Linux, el cual brinda soporte para las capas y<br />
protocolos <strong>de</strong>l core Bluetooth. La información contenida en este ítem es <strong>una</strong><br />
síntesis <strong>de</strong> los principales apartes <strong>de</strong>l HowTo <strong>de</strong> Bluez disponible en el sitio oficial<br />
<strong>de</strong> Bluez en Internet [33].
Estas son sus principales características:<br />
• Arquitectura flexible, eficiente y modular.<br />
• Soporta múltiples dispositivos Bluetooth.<br />
• Procesamiento <strong>de</strong> datos para multienlaces.<br />
• Abstracción <strong>de</strong>l Hardware.<br />
• Interfaz <strong>de</strong> socket estándar para todas las capas.<br />
Bluez consta <strong>de</strong>:<br />
• Core HCI.<br />
• drivers HCI para UART, USB y emulador <strong>de</strong> HCI.<br />
• Módulos para el protocolo L2CAP.<br />
• Utilida<strong>de</strong>s <strong>de</strong> configuración y prueba.<br />
Figura 3-7. Diagrama <strong>de</strong> la Arquitectura <strong>de</strong> Bluez
La Figura 3-7 es un esquema <strong>de</strong> la arquitectura <strong>de</strong> Bluez, que indica las capas<br />
implementadas por este software <strong>de</strong>ntro <strong>de</strong>l stack <strong>de</strong> protocolos Bluetooth.<br />
El código fuente <strong>de</strong> Bluez se pue<strong>de</strong> obtener <strong>de</strong> la página oficial <strong>de</strong> Bluez en<br />
Internet [30]. Requiere para su funcionamiento un Kernel <strong>de</strong> Linux 2.4.4 o<br />
posterior. Si se <strong>de</strong>sea utilizar las últimas versiones <strong>de</strong>l stack, es necesario<br />
<strong>de</strong>shabilitar <strong>de</strong>l kernel el soporte nativo <strong>de</strong> Bluetooth. Bluez se pue<strong>de</strong> usar con<br />
dispositivos Bluetooth con interfaz Serial o USB, a<strong>de</strong>más brinda un dispositivo HCI<br />
virtual (vhci) el cual permite <strong>de</strong>purar y probar las aplicaciones sin necesidad <strong>de</strong><br />
tener conectados dispositivos Bluetooth reales.<br />
3.5.1 Compilación e Instalación<br />
Bluez se compone <strong>de</strong> los siguientes paquetes:<br />
• bluez-kernel-X.X.tar.gz<br />
• bluez-utils-X.X.tar.gz<br />
• bluez-libs-X.X.tar.gz<br />
• bluez-SDP-X.X.tar.gz<br />
• bluez-PAN-X.X.tar.gz.<br />
Los archivos README o INSTALL incluidos <strong>de</strong>ntro <strong>de</strong> cada paquete contienen<br />
toda la información sobre los requerimientos e instrucciones para su instalación.<br />
Los procedimientos <strong>de</strong> compilación e instalación son muy parecidos para cada uno<br />
<strong>de</strong> estos paquetes; en general el siguiente procedimiento para instalar el paquete<br />
bluez-kernel-X.X.tgz se pue<strong>de</strong> seguir con los <strong>de</strong>más paquetes, reemplazando el<br />
nombre <strong>de</strong>l archivo por el correspondiente:
1. Copiar las fuentes en el directorio /usr/src<br />
2. Desempaquetar el archivo fuente:<br />
tar –xzvf bluez-kernel-X.X.tar.gz<br />
3. Ubicarse <strong>de</strong>ntro <strong>de</strong>l directorio bluez-kernel-X.X (o el correspondiente a<br />
instalar)<br />
cd bluez-kernel-X.X<br />
4. Correr el script <strong>de</strong> configuración:<br />
./configure<br />
5. Compilar las fuentes:<br />
make<br />
6. Instalar las fuentes:<br />
make install<br />
Debe escribirse las siguientes líneas <strong>de</strong> código en el la línea <strong>de</strong> comandos <strong>de</strong><br />
Linux, únicamente <strong>de</strong>spués <strong>de</strong> instalar el paquete bluez-kernel-X.X, esto con el fin<br />
<strong>de</strong> crear el dispositivo HCI virtual (vhci):<br />
mknod /<strong>de</strong>v/vhci c 10 250 chmod 664/<strong>de</strong>v/vhci<br />
C=0;<br />
While [$C -lt 256];<br />
do<br />
if [ ! -c /<strong>de</strong>v/rfcomm$C ];<br />
then<br />
mknod -m 666 /<strong>de</strong>v/rfcomm$C c 216 $C<br />
fi<br />
C=`expr $C + 1`<br />
done<br />
Para que Bluez trabaje correctamente se <strong>de</strong>ben escribir las siguientes líneas en el<br />
archivo /etc/modules.conf:
alias net-pf-31 bluez<br />
alias bt-proto-0 l2cap<br />
alias bt-proto-2 sco<br />
alias bt-proto-3 rfcomm<br />
alias bt-proto-4 bnep<br />
alias tty-ldisc-15 hci_uart<br />
alias char-major-10-250 hci_vhci<br />
Después <strong>de</strong> esto se <strong>de</strong>be correr el comando “<strong>de</strong>pmod –a” para habilitar la carga<br />
automática <strong>de</strong> los módulos Bluez. Estos módulos también se pue<strong>de</strong>n cargar<br />
manualmente mediante el comando “modprobe” acompañado <strong>de</strong> uno <strong>de</strong> los<br />
siguientes módulos:<br />
• bluez Core Bluetooth.<br />
• hci_usb Driver HCI USB.<br />
• hci_uart Driver HCI UART.<br />
• hci_vhci Driver para el dispositivo virtual HCI.<br />
• l2cap Módulo L2CAP.<br />
• sco Módulo SCO (Synchronous Connection Oriented).<br />
• rfcomm Módulo RFCOMM.<br />
Una <strong>de</strong>scripción completa <strong>de</strong> los comandos <strong>de</strong> Bluez está disponible en el sitio<br />
oficial <strong>de</strong> Bluez en Internet [30][33] o en el CD ROM que acompaña este libro<br />
(versión en español).
4. CONCEPTOS BÁSICOS PARA LA IMPLEMENTACIÓN<br />
DE UNA RED DE AREA PERSONAL BLUETOOTH<br />
La especificación Bluetooth <strong>de</strong>fine perfiles o esquemas estándar <strong>de</strong> los<br />
escenarios <strong>de</strong> <strong>de</strong>sarrollo para las aplicaciones Bluetooth, varios <strong>de</strong> ellos ya se han<br />
mencionado en el capítulo 1. Uno <strong>de</strong> estos escenarios correspon<strong>de</strong> al perfil <strong>de</strong> <strong>red</strong><br />
<strong>de</strong> área personal o perfil PAN (Personal Area Networking Profile) [34]. El perfil<br />
PAN brinda capacida<strong>de</strong>s <strong>de</strong> <strong>red</strong> a los dispositivos Bluetooth para lo cual utiliza el<br />
Protocolo <strong>de</strong> Encapsulamiento <strong>de</strong> Red BNEP (Bluetooth Network Encapsulation<br />
Protocol) [35], <strong>de</strong> gran importancia ya que encapsula los paquetes provenientes<br />
<strong>de</strong> varios protocolos <strong>de</strong> <strong>red</strong> (IPv4, IPv6 e IPX entre otros) y los transporta<br />
directamente sobre la capa <strong>de</strong> protocolo L2CAP <strong>de</strong> Bluetooth, haciendo posible<br />
que la <strong>red</strong> Bluetooth se comporte y forme parte <strong>de</strong> <strong>una</strong> <strong>red</strong> TCP/IP.<br />
4.1 PROTOCOLO DE ENCAPSULAMIENTO DE RED BNEP<br />
El protocolo <strong>de</strong> encapsulamiento <strong>de</strong> <strong>red</strong> <strong>de</strong> Bluetooth encapsula los paquetes <strong>de</strong><br />
los protocolos <strong>de</strong> <strong>red</strong> más utilizados, para ser transportados sobre la capa L2CAP.<br />
BNEP soporta los mismos protocolos <strong>de</strong> <strong>red</strong> soportados por el estándar IEEE<br />
802.3 para ecapsulamiento Ethernet (IPv4, IPv6, IPX entre otros). BNEP requiere<br />
a<strong>de</strong>más un formato <strong>de</strong> encapsulamiento que optimice los bits <strong>de</strong> cabecera <strong>de</strong> tal<br />
manera que se ofrezca un manejo eficiente <strong>de</strong>l ancho <strong>de</strong> banda. Los siguientes<br />
apartes son tomados <strong>de</strong> la especificación <strong>de</strong>l protocolo BNEP publicada por el SIG<br />
Bluetooth [35].
4.1.1 Consi<strong>de</strong>raciones<br />
1. Este protocolo está implementado usando canales L2CAP orientados a<br />
conexión.<br />
2. Bluetooth se consi<strong>de</strong>ra un medio <strong>de</strong> transmisión al mismo nivel OSI <strong>de</strong><br />
Ethernet, Token Ring, ATM, etc.<br />
3. Se consi<strong>de</strong>ra a L2CAP como la capa <strong>de</strong> control <strong>de</strong> acceso al medio MAC<br />
(Media Access Control) <strong>de</strong> Bluetooth.<br />
4. BNEP especifica <strong>una</strong> mínima MTU (Unidad máxima <strong>de</strong> transmisión) para<br />
L2CAP <strong>de</strong> 1691 bytes 1 .<br />
5. Se <strong>de</strong>ben aplicar a Bluetooth las reglas <strong>de</strong> conectividad y las topologías <strong>de</strong><br />
<strong>red</strong> <strong>de</strong>finidas por el estándar IEEE 802.3 [36][37].<br />
6. El espacio <strong>de</strong> dirección Bluetooth BD_ADDR es administrado por IEEE, y<br />
es asignado <strong>de</strong>s<strong>de</strong> el espacio <strong>de</strong> dirección <strong>de</strong> Ethernet. De esta manera es<br />
posible construir un punto <strong>de</strong> acceso <strong>de</strong> <strong>red</strong> Bluetooth como un puente<br />
entre los dispositivos Bluetooth y <strong>una</strong> <strong>red</strong> Ethernet.<br />
La Figura 4-1 muestra la ubicación <strong>de</strong>l BNEP <strong>de</strong>ntro <strong>de</strong> la torre <strong>de</strong> protocolos <strong>de</strong><br />
Bluetooth.<br />
1<br />
La mínima MTU (Máxima Unidad <strong>de</strong> Transmisión) <strong>de</strong> 1691 se seleccionó con base en el máximo<br />
paquete <strong>de</strong> carga útil <strong>de</strong> Ethernet (1500 bytes más 15 bytes <strong>de</strong> encabezado <strong>de</strong> BNEP y otros <strong>de</strong><br />
extensión). 1691=5*339 (Tamaño <strong>de</strong> un DH5) – 4 (Encabezado <strong>de</strong> L2CAP).
Figura 4-1. Ubicación <strong>de</strong>l BNEP <strong>de</strong>ntro <strong>de</strong> la Torre <strong>de</strong> protocolos <strong>de</strong> Bluetooth.<br />
4.1.2 Or<strong>de</strong>n <strong>de</strong> los Bytes y Valores numéricos<br />
Todos los valores contenidos en este capítulo se presentan en notación<br />
hexa<strong>de</strong>cimal. Los campos que contienen múltiples bytes (bits) se muestran con los<br />
bytes (bits) más significativos hacia la izquierda y los menos significativos hacia la<br />
<strong>de</strong>recha. Los bytes <strong>de</strong> los encabezados <strong>de</strong> BNEP se disponen en el formato<br />
estándar <strong>de</strong> <strong>red</strong> Big Endian, en don<strong>de</strong> los bytes más significativos se transmiten<br />
antes que los menos significativos. El byte 0 es el más significativo.
4.1.3 Encapsulamiento <strong>de</strong> Paquetes<br />
La Figura 4-2 muestra la manera como BNEP remueve los encabezados <strong>de</strong> un<br />
paquete Ethernet y los reemplaza por un encabezado BNEP. El paquete resultante<br />
(Carga útil <strong>de</strong> Ethernet y el encabezado <strong>de</strong> BNEP) es encapsulado en un paquete<br />
L2CAP y enviado sobre Bluetooth.<br />
Figura 4-2. Encapsulamiento <strong>de</strong> un Paquete Ethernet en un paquete L2CAP<br />
BNEP es usado para transportar sobre Bluetooth tanto paquetes <strong>de</strong> datos como<br />
paquetes <strong>de</strong> control, <strong>de</strong> esta manera brinda a los dispositivos Bluetooth<br />
capacida<strong>de</strong>s <strong>de</strong> <strong>red</strong> similares a las ofrecidas por Ethernet.<br />
4.1.4 Formato <strong>de</strong> los Encabezados BNEP<br />
Todos los encabezados <strong>de</strong> BNEP siguen el formato que se muestra en la Figura<br />
4-3.
Figura 4-3. Formato <strong>de</strong> los Encabezados BNEP<br />
� Tipo <strong>de</strong> BNEP Este campo tiene un tamaño <strong>de</strong> siete bits e i<strong>de</strong>ntifica el tipo <strong>de</strong><br />
encabezado BNEP que contiene el paquete. Los posibles valores que pue<strong>de</strong><br />
tomar y la <strong>de</strong>scripción <strong>de</strong> los mismos se muestra en la Tabla 4-1.<br />
Tabla 4-1. Valores para el campo BNEP Type el cual <strong>de</strong>fine el tipo <strong>de</strong> paquete BNEP<br />
Valor Tipo <strong>de</strong> Paquete BNEP<br />
0x00 BNEP_GENERAL_ETHERNET<br />
0x01 BNEP_CONTROL<br />
0x02 BNEP_COMPRESSED_ETHERNET<br />
0x03 BNEP_COMPRESSED_ETHERNET_SOURCE_ONLY<br />
0x04 BNEP_COMPRESSED_ETHERNET_DEST_ONLY<br />
0x05-0x7E Reservado para un futuro uso<br />
0x7F<br />
Reservado para los Paquetes LLC <strong>de</strong> 802.2 por IEEE 802.15.1<br />
WG<br />
� Ban<strong>de</strong>ra <strong>de</strong> Extensión (E) Correspon<strong>de</strong> a un bit <strong>de</strong> extensión que indica si<br />
existe uno o más encabezados <strong>de</strong> extensión entre el encabezado <strong>de</strong> BNEP y la<br />
carga útil. Si toma un valor <strong>de</strong> 0x1, entonces uno o más encabezados <strong>de</strong>
extensión se ubican antes <strong>de</strong> la carga útil. Si el valor que tiene es 0x0, la carga<br />
útil sigue <strong>de</strong>spués <strong>de</strong>l encabezado BNEP.<br />
� Paquete BNEP Depen<strong>de</strong> <strong>de</strong>l valor que se haya consignado en el campo <strong>de</strong>l<br />
Tipo <strong>de</strong> BNEP.<br />
4.1.5 Tipo <strong>de</strong> Paquete BNEP_GENERAL_ETHERNET<br />
El paquete general <strong>de</strong> Ethernet para BNEP se <strong>de</strong>be usar para transportar<br />
paquetes Ethernet <strong>de</strong>s<strong>de</strong> y hacia re<strong>de</strong>s Bluetooth. Como se pue<strong>de</strong> apreciar en la<br />
Figura 4-4 el paquete está conformado por <strong>una</strong> dirección <strong>de</strong>stino, <strong>una</strong> dirección<br />
origen y el tipo <strong>de</strong> protocolo <strong>de</strong> <strong>red</strong> contenido en la carga útil (IPv4, IPv6, etc).<br />
Cualquiera <strong>de</strong> las direcciones ya sea origen o <strong>de</strong>stino pue<strong>de</strong> correspon<strong>de</strong>r a <strong>una</strong><br />
dirección Ethernet IEEE, si el origen o <strong>de</strong>stino es un dispositivo IEEE y no un<br />
dispositivo Bluetooth.<br />
Figura 4-4. Formato <strong>de</strong>l Encabezado para un paquete BNEP_GENERAL_ETHERNET
4.1.6 Tipo <strong>de</strong> Paquete BNEP_CONTROL<br />
El paquete <strong>de</strong> control <strong>de</strong> BNEP es utilizado para intercambiar información <strong>de</strong><br />
control. En este tipo <strong>de</strong> paquete, toda la información <strong>de</strong> control está contenida en<br />
el encabezado <strong>de</strong>l BNEP_CONTROL <strong>de</strong> tal manera que el campo <strong>de</strong> carga útil no<br />
contiene información alg<strong>una</strong>. Por el momento hay siete tipos <strong>de</strong> paquetes <strong>de</strong><br />
control BNEP. El tipo <strong>de</strong> paquete <strong>de</strong> control es <strong>de</strong>finido por el valor que se<br />
consigne en el campo tipo <strong>de</strong> control <strong>de</strong> BNEP; no se entra en <strong>de</strong>talle sobre cada<br />
tipo <strong>de</strong> paquete <strong>de</strong> control ya que esto no está <strong>de</strong>ntro <strong>de</strong> los alcances <strong>de</strong> la Tesis.<br />
La Figura 4-5 muestra el formato para el encabezado <strong>de</strong> un paquete<br />
BNEP_CONTROL.<br />
Figura 4-5. Formato <strong>de</strong>l Encabezado para un paquete BNEP_CONTROL<br />
4.1.7 Tipo <strong>de</strong> Paquete BNEP_COMPRESSED_ETHERNET<br />
El paquete Ethernet comprimido <strong>de</strong> BNEP se usa para transportar paquetes<br />
Ethernet hacia o <strong>de</strong>s<strong>de</strong> dispositivos que tienen <strong>una</strong> conexión directa al nivel <strong>de</strong> la<br />
capa L2CAP usando BNEP. Debido a la existencia <strong>de</strong> <strong>una</strong> conexión L2CAP entre<br />
lo dos dispositivos Bluetooth no es necesario incluir <strong>de</strong>ntro <strong>de</strong>l paquete las<br />
direcciones <strong>de</strong> origen y <strong>de</strong>stino. Se <strong>de</strong>be anotar que las direcciones <strong>de</strong> multicast<br />
o broadcast no <strong>de</strong>ben ser comprimidas. La Figura 4-6 muestra el formato <strong>de</strong> un<br />
paquete BNEP_COMPRESSED_ETHERNET.
Figura 4-6. Formato <strong>de</strong>l encabezado para un paquete BNEP_COMPRESSED_ETHERNET<br />
4.1.8 Tipo <strong>de</strong> Paquete BNEP_COMPRESSED_ETHERNET_SOURCE_ONLY<br />
Este paquete Ethernet comprimido se usa para transportar paquetes Ethernet<br />
hacia un dispositivo el cual siempre será el <strong>de</strong>stino final para todos los paquetes.<br />
Por esta razón los dispositivos no necesitan incluir la dirección <strong>de</strong>stino en los<br />
paquetes siendo esta la misma dirección correspondiente al canal L2CAP sobre el<br />
cual se envían los paquetes. Se <strong>de</strong>be anotar que las direcciones <strong>de</strong> multicast o<br />
broadcast no <strong>de</strong>ben ser comprimidas.<br />
Figura 4-7. Formato <strong>de</strong>l encabezado para un paquete<br />
BNEP_COMPRESSED_ETHERNET_SOURCE_ONLY
4.1.9 Tipo <strong>de</strong> Paquete BNEP_COMPRESSED_ETHERNET_DEST_ONLY<br />
Este paquete comprimido Ethernet es usado para transportar paquetes <strong>de</strong>s<strong>de</strong> un<br />
dispositivo el cual es la fuente <strong>de</strong>l paquete. De esta manera los dispositivos no<br />
necesitan incluir la dirección <strong>de</strong> la fuente <strong>de</strong>l paquete ya que esta fuente pue<strong>de</strong><br />
<strong>de</strong>terminarse a partir <strong>de</strong> la conexión L2CAP.<br />
Figura 4-8. Formato <strong>de</strong>l encabezado para un paquete<br />
BNEP_COMPRESSED_ETHERNET_DEST_ONLY<br />
El siguiente es un ejemplo en el cual un paquete IP es enviado usando BNEP. Un<br />
paquete IPv4 es enviado <strong>de</strong>s<strong>de</strong> un dispositivo con <strong>una</strong> dirección IEEE <strong>de</strong> 48 bits<br />
(00:AA:00:55:44:33) hacia un dispositivo con <strong>una</strong> dirección Bluetooth<br />
(00:30:B7:45:67:89). En este caso el paquete BNEP utilizado es <strong>de</strong>l tipo<br />
BNEP_GENERAL_ETHERNET como se ilustra en la Figura 4-9.
Figura 4-9. Ejemplo <strong>de</strong>l envío <strong>de</strong> un paquete IPv4 usando BNEP entre un dispositivo con<br />
dirección IEEE y otro con dirección Bluetooth<br />
4.2 Piconet y scatternet<br />
Dos o más dispositivos Bluetooth que comparten el mismo canal <strong>de</strong> conexión<br />
conforman <strong>una</strong> piconet. Esta se establece a través <strong>de</strong> enlaces punto-multipunto,<br />
en don<strong>de</strong> uno <strong>de</strong> los dispositivos cumple el rol <strong>de</strong> maestro mientras los <strong>de</strong>más<br />
actúan como esclavos. Una piconet pue<strong>de</strong> tener un máximo <strong>de</strong> siete esclavos<br />
activos. Las Figuras 4-10 y 4-11 ilustran respectivamente el esquema y un ejemplo<br />
<strong>de</strong> <strong>una</strong> piconet.
Figura 4-10. Esquema <strong>de</strong> <strong>una</strong> Piconet<br />
Figura 4-11. Ejemplo <strong>de</strong> <strong>una</strong> Piconet<br />
En <strong>una</strong> piconet los enlaces se establecen sobre todas las capas <strong>de</strong> protocolo<br />
Bluetooth <strong>de</strong>s<strong>de</strong> banda base hasta L2CAP. BNEP utiliza estos enlaces L2CAP<br />
para encapsular los protocolos <strong>de</strong> <strong>red</strong> <strong>de</strong> capas superiores <strong>de</strong> tal manera que el<br />
medio <strong>de</strong> transporte (Bluetooth) es transparente para las aplicaciones. El perfil
PAN <strong>de</strong>scribe los mecanismos mediante los cuales se brindan propieda<strong>de</strong>s <strong>de</strong> <strong>red</strong><br />
a los dispositivos Bluetooth que forman parte <strong>de</strong> <strong>una</strong> piconet.<br />
Múltiples piconets en don<strong>de</strong> sus rangos <strong>de</strong> cobertura se traslapan conforman <strong>una</strong><br />
scatternet. Cada piconet <strong>de</strong>be tener un único maestro, sin embargo, los esclavos<br />
pue<strong>de</strong>n participar en diferentes piconets. A<strong>de</strong>más un maestro <strong>de</strong> <strong>una</strong> piconet<br />
pue<strong>de</strong> ser esclavo en otra. Las Figuras 4-12 y 4-13 ilustran respectivamente el<br />
esquema y un ejemplo <strong>de</strong> <strong>una</strong> scatternet.<br />
Figura 4-12. Esquema <strong>de</strong> <strong>una</strong> Scatternet
Figura 4-13. Ejemplo <strong>de</strong> <strong>una</strong> Scatternet<br />
4.3 PERFIL DE RED DE AREA PERSONAL (PAN PROFILE)<br />
El perfil PAN (Personal Area Networking Profile) <strong>de</strong>scribe como usar el<br />
protocolo BNEP para brindar capacida<strong>de</strong>s <strong>de</strong> <strong>red</strong> a los dispositivos Bluetooth.<br />
Estos apartes son tomados <strong>de</strong>l documento Personal Area Networking Profile<br />
publicado por el SIG. Bluetooth [34]. El perfil PAN presenta los siguientes<br />
requerimientos funcionales:<br />
• Define <strong>una</strong> <strong>red</strong> IP ad-hoc, dinámica y personal<br />
• Debe ser in<strong>de</strong>pendiente <strong>de</strong>l sistema operativo, lenguaje y dispositivo<br />
• Brinda soporte para los protocolos <strong>de</strong> <strong>red</strong> más comunes como IPv4 e IPv6.<br />
• Brinda soporte para puntos <strong>de</strong> acceso en don<strong>de</strong> la <strong>red</strong> pue<strong>de</strong> ser <strong>una</strong> LAN<br />
corporativa, GSM u otro tipo <strong>de</strong> <strong>red</strong> <strong>de</strong> datos.
• Debe acomodarse a los recursos <strong>red</strong>ucidos disponibles en los dispositivos<br />
pequeños respecto a memoria, capacidad <strong>de</strong> procesamiento y uso <strong>de</strong><br />
interfaces.<br />
4.3.1 Consi<strong>de</strong>raciones<br />
• El perfil PAN <strong>de</strong>be soportar IPv4 e IPv6. Los otros protocolos pue<strong>de</strong>n estar o<br />
no habilitados.<br />
• En <strong>una</strong> <strong>red</strong> generalizada, la trayectoria <strong>de</strong>l tráfico originado <strong>de</strong>s<strong>de</strong> un<br />
dispositivo hacia otro pue<strong>de</strong> estar conformada por uno o varios medios <strong>de</strong><br />
transporte, por ejemplo, Bluetooth, Ethernet, Token Ring, PSTN, ISDN, ATM,<br />
GSM, etc.<br />
Son tres escenarios propuestos para el perfil PAN: Puntos <strong>de</strong> acceso a <strong>una</strong> <strong>red</strong><br />
(Network access points), Grupo <strong>de</strong> <strong>red</strong> Ad-hoc (Group Ad-hoc Networks) y<br />
PANU-PANU (PAN USER). Cada uno <strong>de</strong> estos escenarios <strong>de</strong>fine el rol y el<br />
servicio que <strong>de</strong>ben asumir los dispositivos involucrados en <strong>una</strong> <strong>de</strong> estas<br />
arquitecturas.<br />
4.3.2 Puntos <strong>de</strong> Acceso a <strong>una</strong> <strong>red</strong> (NAP)<br />
Un punto <strong>de</strong> acceso a <strong>una</strong> <strong>red</strong> (NAP) correspon<strong>de</strong> a <strong>una</strong> unidad que contiene uno<br />
o más dispositivos Bluetooth y actúa como puente, proxy o enrutador, entre <strong>una</strong><br />
<strong>red</strong> Bluetooth y otro tipo <strong>de</strong> tecnología <strong>de</strong> <strong>red</strong> (Ethernet, GSM, ISDN, Home PNA,<br />
Cable Mó<strong>de</strong>m y Celular). La Figura 4-14 ilustra la arquitectura para dos puntos <strong>de</strong><br />
acceso a <strong>red</strong>.
Figura 4-14. Dos Puntos <strong>de</strong> Acceso a Red<br />
Para la Fase I <strong>de</strong>l perfil PAN, el dispositivo que soporta el servicio NAP (Network<br />
Access Point) <strong>de</strong>be cumplir con las características <strong>de</strong> un Puente Ethernet para<br />
soportar <strong>de</strong> esta manera los servicios <strong>de</strong> <strong>red</strong>. El dispositivo NAP distribuye los<br />
paquetes Ethernet entre los dispositivos Bluetooth conectados o PAN Users<br />
(PANU). Los NAP pue<strong>de</strong>n requerir características adicionales en los casos en que<br />
el puente sea hacia otro tipo <strong>de</strong> re<strong>de</strong>s, por ejemplo GPRS. La Figura 4-15 muestra<br />
la interacción <strong>de</strong> las capas <strong>de</strong> protocolo <strong>de</strong>l mo<strong>de</strong>lo Bluetooth para el rol NAP.
Figura 4-15. Stack para el rol NAP<br />
4.3.3 Grupo <strong>de</strong> Red Ad-hoc<br />
La versión 1.0 <strong>de</strong>l Perfil PAN [34], especifica el escenario para <strong>una</strong> <strong>red</strong> personal<br />
ad-hoc el cual consiste en <strong>una</strong> simple piconet con conexiones entre dos o más<br />
dispositivos Bluetooth. Un maestro y un máximo <strong>de</strong> siete esclavos conforman esta<br />
<strong>red</strong>. El límite <strong>de</strong> siete esclavos se <strong>de</strong>be al esquema activo <strong>de</strong> direccionamiento <strong>de</strong><br />
Bluetooth [3]. La Figura 4-16 es un esquema para <strong>una</strong> <strong>red</strong> Ad-hoc.
Figura 4-16. Esquema para un Grupo <strong>de</strong> Red Ad-hoc (GN)<br />
Un grupo <strong>de</strong> <strong>red</strong> ad-hoc se establece para que un conjunto <strong>de</strong> dispositivos<br />
conforme <strong>una</strong> <strong>red</strong> temporal e intercambien información. El dispositivo cuyo rol es<br />
GN (Group Ad-hoc Network) soporta el servicio GN. La Figura 4-17 ilustra a nivel<br />
<strong>de</strong> las capas <strong>de</strong> protocolo un enlace entre un GN y un PANU.
Figura 4-17. Stack para un enlace en <strong>una</strong> <strong>red</strong> Ad-hoc Bluetooth<br />
4.3.4 PANU – PANU<br />
En este escenario se establece <strong>una</strong> conexión punto a punto entre dos usuarios<br />
<strong>de</strong> PAN (PANU), permitiéndose así <strong>una</strong> comunicación directa entre ellos. El PANU<br />
es el dispositivo Bluetooth que usa los servicios NAP o GN. El PANU asume el rol<br />
<strong>de</strong> cliente <strong>de</strong> los roles NAP o GN.
5. PRUEBAS DE DESEMPEÑO Y APLICACIÓN PARA LAS<br />
TARJETAS BLUEBOARD_UV01 Y BLUEBOARD_UV02<br />
Como se explicó en el segundo capítulo <strong>de</strong> este libro, las tarjetas<br />
BlueBoard_UV01 y BlueBoard_UV02 tienen diseños muy similares. Estos dos<br />
diseños difieren en el tipo <strong>de</strong> antena que utilizan, Rangestar 100929 para la<br />
BlueBoard_UV01 y Rangestar 100930 para la BlueBoard_UV02.<br />
Por otro lado las tarjetas poseen interfaces HCI para USB y RS232. A<strong>de</strong>más se<br />
cuenta con los módulos Bluetooth ROK 101 007/21E y ROK 101 008 <strong>de</strong> Ericsson,<br />
removibles e intercambiables gracias al carrier socket BT001A-30G2T <strong>de</strong> Suyin<br />
que posee cada tarjeta. Todo esto sumado con las herramientas <strong>de</strong> prueba y<br />
utilida<strong>de</strong>s que brindan los stack <strong>de</strong> protocolo BlueZ y Affix, crea <strong>una</strong> potente<br />
plataforma <strong>de</strong> pruebas tanto para el hardware (antenas Rangestar y módulos<br />
Bluetooth <strong>de</strong> Ericsson) como para aplicaciones Bluetooth.<br />
El plan <strong>de</strong> pruebas se divi<strong>de</strong> en dos grupos: el primero lo conforman las pruebas<br />
<strong>de</strong> <strong>de</strong>sempeño <strong>de</strong>l hardware Bluetooth que permite <strong>de</strong>finir las características <strong>de</strong><br />
operación <strong>de</strong> las tarjetas, y el segundo <strong>una</strong> serie <strong>de</strong> pruebas para implementar <strong>una</strong><br />
Red <strong>de</strong> Area Personal (PAN), principal objetivo <strong>de</strong> esta tesis.
5.1 PRUEBAS DE DESEMPEÑO<br />
Estas pruebas muestran el <strong>de</strong>sempeño <strong>de</strong> las tarjetas BlueBoard_UV01 y<br />
BlueBoard_UV02, midiendo la rata <strong>de</strong> transferencia <strong>de</strong> bits para distintas<br />
distancias y bajo diferentes condiciones. Para esto se utilizó dos nodos (N1 y N2),<br />
cada uno equipado con <strong>una</strong> tarjeta Bluetooth conectada a un PC a través <strong>de</strong> <strong>una</strong><br />
interfaz USB.<br />
5.1.1 Configuración para las Pruebas<br />
� Hardware<br />
• Cada nodo (N1 y N2) correspon<strong>de</strong> a un PC DELL Pentium III, el cual<br />
tiene conectada <strong>una</strong> tarjeta Bluetooth BlueBoard_UV02 a través <strong>de</strong>l<br />
puerto USB.<br />
• Módulos Bluetooth ROK 101 007/21E <strong>de</strong> Ericsson.<br />
� Software Cada PC tiene un sistema operativo Linux RedHat 7.0 e instalados<br />
todos los paquetes <strong>de</strong> Bluez (core, librerías y utilida<strong>de</strong>s).<br />
� Dirección Bluetooth <strong>de</strong> N1: 00:80:37:15:C9:64<br />
� Dirección Bluetooth <strong>de</strong> N2: 00:80:37:15:C9:67<br />
� N1 es el nodo Fijo y N2 es el nodo móvil.<br />
5.1.2 Descripción <strong>de</strong> las Pruebas<br />
Para estas pruebas <strong>de</strong> <strong>de</strong>sempeño, N1 envía paquetes <strong>de</strong> bits que son recibidos<br />
por N2. El nodo N2 tiene el rol <strong>de</strong> servidor y escucha constantemente en espera<br />
<strong>de</strong> paquetes <strong>de</strong> datos <strong>de</strong> tamaño mínimo (MTU) negociado con el nodo cliente N1,<br />
gracias a la utilidad <strong>de</strong> Bluez l2test [33]. l2test es <strong>una</strong> herramienta <strong>de</strong> pruebas para<br />
L2CAP, la cual calcula y <strong>de</strong>spliega en el servidor (N2) la velocidad (kb/s) a la que<br />
los datos se transmiten sobre <strong>una</strong> conexión L2CAP. Se pue<strong>de</strong> conseguir más
información <strong>de</strong> la utilidad l2test en el HowTo <strong>de</strong> Bluez [33] o en el CD-ROM anexo<br />
a este libro (versión en español). La arquitectura utilizada para las pruebas <strong>de</strong><br />
<strong>de</strong>sempeño se muestra en la Figura 5-1.<br />
Figura 5-1. Arquitectura utilizada en las pruebas <strong>de</strong> <strong>de</strong>sempeño<br />
Con <strong>una</strong> distancia inicial <strong>de</strong> 0 m y <strong>de</strong>splazando el nodo móvil N2 en intervalos <strong>de</strong> 1<br />
m, se registró para cada intervalo la rata <strong>de</strong> bytes calculada por l2test para los<br />
paquetes enviados <strong>de</strong>s<strong>de</strong> N1. Para cada intervalo <strong>de</strong> distancia se tomaron<br />
aproximadamente 17 registros para paquetes <strong>de</strong> 100128 bytes. Para distancias <strong>de</strong><br />
6 m en a<strong>de</strong>lante, los paquetes <strong>de</strong> bytes enviados <strong>de</strong>s<strong>de</strong> N1 en algunos casos se<br />
<strong>red</strong>ujeron a 20160 bytes y 50400 bytes, para agilizar la captura <strong>de</strong> los datos.<br />
En la Figura 5-1 la pa<strong>red</strong> representa dos obstáculos, <strong>una</strong> pa<strong>red</strong> <strong>de</strong> ma<strong>de</strong>ra que<br />
coloca a los nodos en cubículos separados simulando un ambiente <strong>de</strong> oficina y<br />
dos cajas plásticas (<strong>una</strong> por nodo) en las que se introducen las tarjetas para <strong>de</strong><br />
esta manera simular la atenuación provocada por la cobertura plástica propia <strong>de</strong><br />
los dispositivos móviles (teléfonos celulares, palm, computadoras portátiles, etc.).
De esta manera se tomaron datos para cuatro escenarios <strong>de</strong> prueba distintos:<br />
• Línea <strong>de</strong> vista entre los nodos (LV)<br />
• Pa<strong>red</strong> <strong>de</strong> ma<strong>de</strong>ra entre los nodos (M)<br />
• Pa<strong>red</strong> <strong>de</strong> ma<strong>de</strong>ra entre los nodos y cada tarjeta <strong>de</strong>ntro <strong>de</strong> <strong>una</strong> caja plástica<br />
(MP)<br />
• Línea <strong>de</strong> vista entre los nodos y cada tarjeta <strong>de</strong>ntro <strong>de</strong> <strong>una</strong> caja plástica (LVP)<br />
Se <strong>de</strong>be correr l2test primero en el servidor N2 y <strong>de</strong>spués en el cliente N1 <strong>de</strong> la<br />
siguiente manera:<br />
� N2 (Servidor)<br />
[root@localhost /root]# l2test -I 2000 -r<br />
l2test[1358]: Waiting for connection on psm 10 ...<br />
De esta manera el servidor N2 espera <strong>una</strong> conexión L2CAP proveniente <strong>de</strong>s<strong>de</strong> el<br />
cliente N1 con <strong>una</strong> MTU entrante <strong>de</strong> 2000 bytes.<br />
� N1 (Cliente)<br />
[root@localhost /root]# l2test -O 2000 -s -b 100000 00:80:37:15:C9:67<br />
El cliente N1 establece <strong>una</strong> conexión L2CAP con el servidor N2 y le envía<br />
paquetes <strong>de</strong> 100000 bytes, valor aproximado por l2test a 100128 bytes. Este<br />
número varía <strong>de</strong>pendiendo <strong>de</strong> la cantidad <strong>de</strong> bytes <strong>de</strong>l paquete que se <strong>de</strong>sea<br />
enviar.
En el servidor N2, los datos recibidos se muestran así:<br />
[root@localhost /root]# l2test -I 2000 -r<br />
l2test[1358]: Waiting for connection on psm 10 ...<br />
l2test[1359]: Connect from 00:80:37:15:C9:64 [imtu 2000, omtu 672, flush_to 65535]<br />
l2test[1359]: Receiving ...<br />
l2test[1359]: 100128 bytes in 2.35 sec, 41.52 kb/s<br />
l2test[1359]: 100128 bytes in 2.36 sec, 41.44 kb/s<br />
l2test[1359]: 100128 bytes in 2.36 sec, 41.44 kb/s<br />
l2test[1359]: 100128 bytes in 2.36 sec, 41.41 kb/s<br />
l2test[1359]: 100128 bytes in 2.36 sec, 41.36 kb/s<br />
l2test[1359]: 100128 bytes in 2.33 sec, 41.89 kb/s<br />
l2test[1359]: 100128 bytes in 2.36 sec, 41.44 kb/s<br />
l2test[1359]: 100128 bytes in 2.36 sec, 41.44 kb/s<br />
l2test[1359]: 100128 bytes in 2.37 sec, 41.28 kb/s<br />
l2test[1359]: 100128 bytes in 2.37 sec, 41.30 kb/s<br />
l2test[1359]: 100128 bytes in 2.37 sec, 41.34 kb/s<br />
l2test[1359]: 100128 bytes in 2.34 sec, 41.87 kb/s<br />
l2test[1359]: 100128 bytes in 2.36 sec, 41.39 kb/s<br />
l2test[1359]: 100128 bytes in 2.36 sec, 41.36 kb/s<br />
l2test[1359]: 100128 bytes in 2.37 sec, 41.22 kb/s<br />
l2test[1359]: 100128 bytes in 2.36 sec, 41.51 kb/s<br />
l2test[1359]: 100128 bytes in 2.36 sec, 41.45 kb/s<br />
Estos datos se copian en un editor <strong>de</strong> texto y <strong>de</strong>spués se procesan en <strong>una</strong> hoja <strong>de</strong><br />
cálculo. Para cada intervalo <strong>de</strong> distancia y variante, se registró y tabuló los datos<br />
ofrecidos por l2test, y se calculó la rata <strong>de</strong> bits promedio, <strong>de</strong>sviación estándar,<br />
mediana, moda, varianza y porcentaje <strong>de</strong> variación.<br />
5.1.3 Depen<strong>de</strong>ncias entre la velocidad <strong>de</strong> transmisión, los obstáculos y la<br />
distancia entre los nodos<br />
La rata <strong>de</strong> bits promedio es utilizada para dar un estimativo <strong>de</strong> la <strong>de</strong>pen<strong>de</strong>ncia <strong>de</strong><br />
la velocidad <strong>de</strong> transmisión respecto a la distancia para cada <strong>una</strong> <strong>de</strong> las variantes<br />
ya mencionadas. Estos datos se consignan en las tablas 5-1, 5-2, 5-3 y 5-4.
Tabla 5-1. Rata <strong>de</strong> Bits promedio con LV<br />
Línea <strong>de</strong> Vista entre los Nodos<br />
Distancia<br />
Rata <strong>de</strong> Bits Promedio (kbps)<br />
(m)<br />
0 331.605<br />
1 331.153<br />
2 330.536<br />
4 331.101<br />
6 328.894<br />
8 243.835<br />
10 115.083<br />
12 37.169<br />
Tabla 5-2. Rata <strong>de</strong> Bits promedio con M<br />
Pa<strong>red</strong> <strong>de</strong> Ma<strong>de</strong>ra entre los Nodos<br />
Distancia (m) Rata <strong>de</strong> Bits Promedio (kbps)<br />
0 331.534<br />
2 330.776<br />
4 283.576<br />
6 251.813<br />
8 103.245<br />
Tabla 5-3 Rata <strong>de</strong> Bits promedio con MP<br />
Pa<strong>red</strong> <strong>de</strong> Ma<strong>de</strong>ra entre los Nodos y<br />
Cada Tarjeta <strong>de</strong>ntro <strong>de</strong> <strong>una</strong> Caja Plástica<br />
Distancia (m) Rata <strong>de</strong> Bits Promedio (kbps)<br />
0 331.200<br />
2 331.176<br />
4 265.365<br />
6 250.480<br />
7 111.856
Tabla 5-4. Rata <strong>de</strong> Bits promedio con LVP<br />
Línea <strong>de</strong> Vista entre los Nodos y<br />
Cada Tarjeta <strong>de</strong>ntro <strong>de</strong> <strong>una</strong> Caja Plástica<br />
Distancia (m) Rata <strong>de</strong> Bits Promedio (kbps)<br />
0 330.946<br />
1 315.741<br />
2 331.468<br />
4 330.998<br />
6 331.026<br />
8 245.049<br />
10 25.110<br />
La figura 5-2 muestra, para cada <strong>una</strong> <strong>de</strong> las variantes ya mencionadas, la manera<br />
como evoluciona la velocidad <strong>de</strong> transmisión, representada por la rata <strong>de</strong> bits<br />
promedio, con respecto a la distancia.
Figura 5-2. Rata <strong>de</strong> Bits Promedio Vs. Distancia<br />
Rata <strong>de</strong> Bits (Kbps)<br />
350<br />
300<br />
250<br />
200<br />
150<br />
100<br />
50<br />
0<br />
Rata <strong>de</strong> Bits Promedio Vs. Distancia<br />
0 1 2 3 4 5 6 7 8 9 10 11 12<br />
Distancia (m)<br />
Línea <strong>de</strong> Vista<br />
entre los Nodos<br />
Pa<strong>red</strong> <strong>de</strong> Ma<strong>de</strong>ra<br />
entre los Nodos<br />
Pa<strong>red</strong> <strong>de</strong> Ma<strong>de</strong>ra<br />
entre los Nodos y<br />
Tarjetas en caja<br />
Plástica<br />
Línea <strong>de</strong> Vista<br />
entre los Nodos<br />
yTarjetas en Caja<br />
Plástica<br />
La Figura 5-2 brinda valiosa información sobre el <strong>de</strong>sempeño <strong>de</strong> las tarjetas<br />
BlueBoard_UV01 y BlueBoard_UV02, respecto a tres puntos claves:<br />
• La atenuación <strong>de</strong> la señal <strong>de</strong> radio <strong>de</strong>bido a los obstáculos<br />
• La atenuación <strong>de</strong> la señal <strong>de</strong> radio <strong>de</strong>bido a la distancia<br />
• La conjunción <strong>de</strong> las dos anteriores<br />
La atenuación en la señal <strong>de</strong> radio se refleja en la disminución <strong>de</strong> la rata <strong>de</strong> bits<br />
promedio.<br />
� Atenuación <strong>de</strong> la señal <strong>de</strong> radio <strong>de</strong>bido a los obstáculos. Esta se pue<strong>de</strong><br />
observar al comparar la rata <strong>de</strong> bits para cada variante <strong>de</strong> obstáculos a la
misma distancia entre los nodos. Analizando lo mencionado, se pue<strong>de</strong> concluir<br />
lo siguiente:<br />
• La atenuación <strong>de</strong> la señal <strong>de</strong> radio es igual, con o sin obstáculos<br />
(ma<strong>de</strong>ra o plástico), hasta <strong>una</strong> distancia entre los nodos <strong>de</strong> 2 m, con <strong>una</strong><br />
rata <strong>de</strong> bits promedio <strong>de</strong> 329.3 kbps.<br />
• La mayor atenuación se presenta cuando hay <strong>una</strong> Pa<strong>red</strong> <strong>de</strong> Ma<strong>de</strong>ra<br />
entre los nodos y las tarjetas están <strong>de</strong>ntro <strong>de</strong> <strong>una</strong> caja Plástica<br />
• La menor atenuación se da cuando hay línea <strong>de</strong> vista entre los nodos<br />
• Es mayor la atenuación causada por la pa<strong>red</strong> <strong>de</strong> ma<strong>de</strong>ra que la <strong>de</strong>bida a<br />
las cajas plásticas.<br />
� Atenuación <strong>de</strong> la señal <strong>de</strong> radio <strong>de</strong>bido a la distancia<br />
• Mayor atenuación: A mayor distancia mayor atenuación, especialmente<br />
visible <strong>de</strong>spués <strong>de</strong> 6m.<br />
• Distancia Máxima <strong>de</strong> Transmisión: 12 m, con línea <strong>de</strong> vista entre los<br />
nodos a 37.169 kbps.<br />
• Rata <strong>de</strong> Bits máxima: 331.6 kp/s a <strong>una</strong> distancia <strong>de</strong> 0 m (2 cm aprox.) y<br />
con línea <strong>de</strong> vista entre los nodos<br />
� Atenuación <strong>de</strong> la señal <strong>de</strong> radio <strong>de</strong>bido a los obstáculos y la distancia<br />
• A partir <strong>de</strong> <strong>una</strong> distancia entre los nodos <strong>de</strong> 6 m, aumenta<br />
consi<strong>de</strong>rablemente la rata a la que disminuye la velocidad <strong>de</strong><br />
transmisión. Para cada <strong>una</strong> <strong>de</strong> las variantes <strong>de</strong> obstáculos, esta<br />
disminución en la rata <strong>de</strong> bits presenta <strong>una</strong> ten<strong>de</strong>ncia lineal con<br />
pendiente negativa, <strong>de</strong> esta manera:<br />
� LV: -50.196 kbps/m<br />
� M: -74.284 kbps/m
� LVP: -76.479 kbps/m<br />
� MP: -128.62 kbps/m<br />
Es así como para LV se tiene la menor pendiente, ya que la rata <strong>de</strong> bits<br />
disminuye 50.196 kbps por cada metro que se aleja el nodo móvil N2, en<br />
cambio para MP se tiene la mayor pendiente, ya que la rata <strong>de</strong> bits cae<br />
128.62 kbps por cada metro que se aleja N2.<br />
Para calcular los rangos <strong>de</strong> distancia en los que el rendimiento <strong>de</strong> las tarjetas es<br />
óptimo, se hace analogía con la teoría <strong>de</strong> filtros, en don<strong>de</strong> la frecuencia <strong>de</strong> corte<br />
(Fc) es la frecuencia a la cual la potencia correspon<strong>de</strong> al 70.7% <strong>de</strong> la máxima<br />
potencia. Ya que nuestro canal (aire con obstáculos) se comporta como un filtro,<br />
se estima que el rango <strong>de</strong> distancia entre nodos para un óptimo <strong>de</strong>sempeño <strong>de</strong> la<br />
tarjeta (Do) es la distancia en la que la rata <strong>de</strong> bits (Rb) correspon<strong>de</strong> al 70.7% <strong>de</strong><br />
la máxima rata <strong>de</strong> bits. De esta manera cada variante <strong>de</strong> obstáculos tendrá su<br />
correspondiente Do, como se muestra a continuación:<br />
• LV: Rb = 234.44 kbps Do ≅ 8.5 m<br />
• LVP: Rb = 233.98 kbps Do ≅ 8.5 m<br />
• M: Rb = 234.39 kbps Do ≅ 6.5 m<br />
• MP: Rb = 234.15 kbps Do ≅ 6.5 m<br />
Se pue<strong>de</strong> concluir entonces que para LV y M, los rangos <strong>de</strong> distancia entre los<br />
nodos para un óptimo <strong>de</strong>sempeño (Do) son 8.5 m y 6.5 m respectivamente,<br />
a<strong>de</strong>más, no <strong>de</strong>pen<strong>de</strong>n <strong>de</strong> la cobertura plástica que en un eventual caso puedan<br />
presentar las tarjetas BlueBoard_UV01 y BlueBoard_UV02. Los efectos <strong>de</strong><br />
atenuación <strong>de</strong> la señal <strong>de</strong> radio se hacen notables para distancias superiores al<br />
rango <strong>de</strong> distancia entre los nodos para un óptimo <strong>de</strong>sempeño (Do).
5.1.4 Estabilidad <strong>de</strong> la velocidad <strong>de</strong> transmisión respecto a la distancia y los<br />
obstáculos entre los nodos<br />
Es interesante también analizar para cada <strong>una</strong> <strong>de</strong> las variantes <strong>de</strong> obstáculos, la<br />
estabilidad en la velocidad <strong>de</strong> transmisión a medida que aumenta la distancia.<br />
Para este fin se utilizó el porcentaje <strong>de</strong> variación ya que este es <strong>una</strong> medida<br />
relativa <strong>de</strong> la dispersión <strong>de</strong> los datos para cada distancia respecto a la rata <strong>de</strong> bits<br />
promedio correspondiente. Las tablas 5-5, 5-6, 5-7 y 5-8, muestran los porcentajes<br />
<strong>de</strong> variación para cada distancia y variante <strong>de</strong> obstáculos.<br />
Tabla 5-5. Porcentaje <strong>de</strong> Variación <strong>de</strong>l Promedio <strong>de</strong> la rata <strong>de</strong> Bits con LV<br />
Línea <strong>de</strong> Vista entre los Nodos<br />
Distancia (m) Porcentaje <strong>de</strong> Variación (%)<br />
0 0.43<br />
1 0.62<br />
2 0.60<br />
4 0.50<br />
6 0.77<br />
8 1.88<br />
10 7.90<br />
12 14.36<br />
Tabla 5-6. Porcentaje <strong>de</strong> Variación <strong>de</strong>l Promedio <strong>de</strong> la rata <strong>de</strong> Bits con M<br />
Pa<strong>red</strong> <strong>de</strong> Ma<strong>de</strong>ra entre los Nodos<br />
Distancia (m) Porcentaje <strong>de</strong> Variación (%)<br />
0 0.47<br />
2 0.77<br />
4 2.36<br />
6 11.42
Tabla 5-7. Porcentaje <strong>de</strong> Variación <strong>de</strong>l Promedio <strong>de</strong> la rata <strong>de</strong> Bits con MP<br />
Pa<strong>red</strong> <strong>de</strong> Ma<strong>de</strong>ra entre los Nodos<br />
Cada Tarjeta <strong>de</strong>ntro <strong>de</strong> <strong>una</strong> Caja Plástica<br />
Distancia (m) Porcentaje <strong>de</strong> Variación (%)<br />
0 0.62<br />
2 0.52<br />
4 2.51<br />
6 4.12<br />
7 8.79<br />
Tabla 5-8. Porcentaje <strong>de</strong> Variación <strong>de</strong>l Promedio <strong>de</strong> la rata <strong>de</strong> Bits con LVP<br />
Línea <strong>de</strong> Vista entre los Nodos<br />
Cada Tarjeta <strong>de</strong>ntro <strong>de</strong> <strong>una</strong> Caja Plástica<br />
Distancia (m) Porcentaje <strong>de</strong> Variación (%)<br />
0 0.58<br />
1 1.70<br />
2 0.44<br />
4 0.58<br />
6 0.55<br />
8 6.27<br />
10 21.56<br />
La Figura 5-3 muestra para cada <strong>una</strong> <strong>de</strong> las variantes <strong>de</strong> obstáculos mencionadas<br />
(LV, M, MP, LVP) el porcentaje <strong>de</strong> variación <strong>de</strong> la rata <strong>de</strong> bits en función <strong>de</strong> la<br />
distancia entre los nodos.
Figura 5-3. Porcentaje <strong>de</strong> variación <strong>de</strong> la rata <strong>de</strong> Bits Vs. Distancia<br />
Porcentaje <strong>de</strong> Variación (%)<br />
25<br />
20<br />
15<br />
10<br />
5<br />
0<br />
Porcentaje <strong>de</strong> Variación <strong>de</strong> la rata <strong>de</strong> Bits Vs. Distancia<br />
0 1 2 3 4 5 6 7 8 9 10 11 12<br />
Distancia (m)<br />
Línea <strong>de</strong> Vista entre<br />
los Nodos<br />
Pa<strong>red</strong> <strong>de</strong> Ma<strong>de</strong>ra<br />
entre los Nodos<br />
Pa<strong>red</strong> <strong>de</strong> Ma<strong>de</strong>ra<br />
entre los Nodos y<br />
Tarjetas en caja<br />
Plástica<br />
Línea <strong>de</strong> Vista entre<br />
los Nodos yTarjetas<br />
en Caja Plástica<br />
El porcentaje <strong>de</strong> variación brinda <strong>una</strong> buena estimación <strong>de</strong> qué tan dispersa está<br />
la velocidad <strong>de</strong> los paquetes <strong>de</strong> datos enviados para <strong>una</strong> distancia y obstáculos<br />
fijos respecto a la velocidad promedio calculada para cada caso. El análisis <strong>de</strong> la<br />
Figura 5-3 se enfoca en los siguientes puntos:<br />
• La dispersión <strong>de</strong> la rata <strong>de</strong> bits <strong>de</strong>bido a los obstáculos<br />
• La dispersión <strong>de</strong> la rata <strong>de</strong> bits <strong>de</strong>bido a la distancia entre los nodos<br />
• La conjunción <strong>de</strong> las dos anteriores<br />
� Dispersión <strong>de</strong> la rata <strong>de</strong> bits <strong>de</strong>bido a los obstáculos<br />
• La dispersión <strong>de</strong> la rata <strong>de</strong> bits hasta los 2 m <strong>de</strong> distancia entre los<br />
nodos es la misma sin importar la presencia <strong>de</strong> obstáculos, con un<br />
porcentaje <strong>de</strong> variación promedio <strong>de</strong> 0.7 %.
• La mayor dispersión se presenta cuando entre los nodos hay <strong>una</strong> pa<strong>red</strong><br />
<strong>de</strong> ma<strong>de</strong>ra que los ubica en cubículos separados<br />
• La menor dispersión se da cuando hay línea <strong>de</strong> vista entre los nodos<br />
• Es mayor la dispersión causada por la pa<strong>red</strong> <strong>de</strong> ma<strong>de</strong>ra que la <strong>de</strong>bida a<br />
las cajas plásticas<br />
� Dispersión <strong>de</strong> la rata <strong>de</strong> bits <strong>de</strong>bido a la distancia entre los nodos<br />
• Mayor dispersión registrada: 21.56 % a <strong>una</strong> distancia <strong>de</strong> 10 m, con<br />
línea <strong>de</strong> vista entre los nodos y las tarjetas <strong>de</strong>ntro <strong>de</strong> <strong>una</strong> caja plástica<br />
• Menor dispersión registrada: 0.43 % a <strong>una</strong> distancia <strong>de</strong> 0 m, con línea<br />
<strong>de</strong> vista entre los nodos<br />
� Dispersión <strong>de</strong> la rata <strong>de</strong> bits <strong>de</strong>bido a los obstáculos y a la distancia<br />
Para cada variante <strong>de</strong> obstáculos, <strong>de</strong>spués <strong>de</strong> cierta distancia, el porcentaje <strong>de</strong><br />
variación <strong>de</strong> la rata <strong>de</strong> bits aumenta linealmente con <strong>una</strong> pendiente distinta para<br />
cada caso <strong>de</strong> la siguiente manera:<br />
• LV: a partir <strong>de</strong> los 8 m aumenta con <strong>una</strong> pendiente <strong>de</strong> 3.12 % / m<br />
• M: a partir <strong>de</strong> los 4 m aumenta con <strong>una</strong> pendiente <strong>de</strong> 4.65 % / m<br />
• MP: a partir <strong>de</strong> los 6 m aumenta con <strong>una</strong> pendiente <strong>de</strong> 4.68 % / m<br />
• LVP: a partir <strong>de</strong> los 8 m aumenta con <strong>una</strong> pendiente <strong>de</strong> 7.65 % / m<br />
De esta manera LV tiene la menor pendiente ya que el porcentaje <strong>de</strong><br />
variación aumenta 3.12 % por cada metro que se aleja el nodo móvil N2<br />
<strong>de</strong>spués <strong>de</strong> los 8 m; a partir <strong>de</strong> esta distancia la mayor pendiente se presenta<br />
para LVP, ya que el porcentaje <strong>de</strong> variación <strong>de</strong> la rata <strong>de</strong> bits aumenta 7.65<br />
% por cada metro que se aleja N2. Cabe anotar que para M y MP el aumento<br />
consi<strong>de</strong>rable en la dispersión <strong>de</strong> la rata <strong>de</strong> bits se da a distancias menores (4<br />
m y 6 m respectivamente) que las registradas para LV y LVP.
Para los rangos <strong>de</strong> distancia entre nodos para un óptimo <strong>de</strong>sempeño (Do)<br />
calculados en el ítem 5.1.1, se encuentra el promedio <strong>de</strong>l porcentaje <strong>de</strong> variación<br />
para cada escenario <strong>de</strong> prueba (ver Tabla 5-9).<br />
La Tabla 5-9 muestra para cada rango <strong>de</strong> distancia Do, el porcentaje <strong>de</strong> variación<br />
promedio <strong>de</strong> la rata <strong>de</strong> bits.<br />
Tabla 5-9. Porcentaje <strong>de</strong> Variación Promedio para cada Do<br />
Variante <strong>de</strong> Obstáculos Do (m)<br />
LV<br />
LVP<br />
M<br />
MP<br />
Porcentaje <strong>de</strong> Variación<br />
Promedio (%)<br />
8.5 0.8<br />
8.5 1.69<br />
6.5 3.76<br />
6.5 1.94<br />
Rata <strong>de</strong> bits promedio<br />
(kbps) para Do<br />
316.2<br />
314.2<br />
299.4<br />
294.6<br />
5.2 IMPLEMENTACIÓN DE UNA RED DE AREA PERSONAL<br />
BLUETOOTH<br />
El objetivo final <strong>de</strong> esta tesis es la <strong>implementación</strong> <strong>de</strong> <strong>una</strong> <strong>red</strong> <strong>de</strong> área personal<br />
Bluetooth. Esta <strong>implementación</strong> recopila todos los conceptos que se han tratado a<br />
lo largo <strong>de</strong> este documento, siendo <strong>una</strong> excelente aplicación <strong>de</strong>mostrativa que nos<br />
muestra los alcances y proyecciones <strong>de</strong> esta tecnología. El perfil <strong>de</strong> <strong>red</strong> <strong>de</strong> área<br />
personal <strong>de</strong> Bluetooth (PAN Profile) para esta <strong>de</strong>mostración es el <strong>de</strong> Grupo <strong>de</strong> <strong>red</strong><br />
Ad-hoc o GN (Group Ad-hoc Networks). La PAN consta <strong>de</strong> tres nodos (GN,
PANU1 y PANU2), cada uno conformado por <strong>una</strong> tarjeta Blueboard_UV conectada<br />
a un PC a través <strong>de</strong> <strong>una</strong> interfaz USB. La arquitectura <strong>de</strong> la <strong>red</strong> <strong>de</strong> área personal<br />
implementada, se pue<strong>de</strong> observar en la Figura 5-4.<br />
Figura 5-4. Arquitectura <strong>de</strong> la <strong>red</strong> <strong>de</strong> área personal<br />
5.2.1 Configuración <strong>de</strong> la PAN<br />
� Hardware<br />
• GN y PANU2: cada uno correspon<strong>de</strong> a un PC DELL Pentium III con <strong>una</strong><br />
tarjeta BlueBoard_UV02 conectada a través <strong>de</strong>l puerto USB.<br />
• PANU1: correspon<strong>de</strong> a un PC Genérico Pentium II, el cual tiene<br />
conectada <strong>una</strong> tarjeta BlueBoard_UV01 a través <strong>de</strong>l puerto USB.
• Cada tarjeta está equipada con un módulo Bluetooth Ericsson<br />
ROK101007/21E.<br />
� Software<br />
• GN: sistema operativo Linux RedHat 7.0, Kernel 2.4.18 habilitadas las<br />
opciones “network filter”, “iptable”, “NAT”, “802.1d ethernet bridge”, e<br />
instalados los paquetes <strong>de</strong> Affix y el paquete bridge-utils-0.9.6 (paquete<br />
<strong>de</strong> utilida<strong>de</strong>s para bridge). Este nodo se configura como un servidor <strong>de</strong><br />
Telnet.<br />
• PANU1: sistema operativo Linux RedHat 8.0, Kernel 2.4.18, instalados<br />
los paquetes <strong>de</strong> Affix y cliente Telnet.<br />
• PANU2: sistema operativo Linux RedHat 7.0, Kernel 2.4.19, instalados los<br />
paquetes <strong>de</strong> Affix y el cliente telnet.<br />
� Dirección Bluetooth <strong>de</strong> GN: 00:80:37:15:C9:67<br />
� Dirección Bluetooth <strong>de</strong> PANU1: 00:80:37:15:C9:64<br />
� Dirección Bluetooth <strong>de</strong> PANU2: 00:80:37:15:C9:66<br />
• Dirección IP <strong>de</strong> GN: 10.0.0.1<br />
• Dirección IP <strong>de</strong> PANU1: 10.0.0.2<br />
• Dirección IP <strong>de</strong> PANU2: 10.0.0.3<br />
5.2.2 Ethernet Bridging<br />
Un bridge, es un puente que sirve para unir dos o más interfaces <strong>de</strong> <strong>red</strong> (tarjetas<br />
<strong>de</strong> <strong>red</strong> - NICs) para que el tráfico fluya entre ellas <strong>de</strong> manera libre y en forma<br />
transparente. De esta manera se pue<strong>de</strong> conectar un PC a la LAN como si este<br />
fuera un hub o un switch. Los PCs <strong>de</strong>trás <strong>de</strong>l bridge no lo verán y el tráfico fluirá<br />
en forma transparente [38]. Affix y Bluez utilizan el 802.1d ethernet bridge y el<br />
paquete <strong>de</strong> utilida<strong>de</strong>s bridge-utils-0.9.6 disponible en Internet [39], únicamente
para combinar, en <strong>una</strong> sola interfaz, interfaces <strong>de</strong> <strong>red</strong> separadas. Se pue<strong>de</strong><br />
encontrar fácilmente en Internet tutoriales, guías <strong>de</strong> Instalación y configuración <strong>de</strong>l<br />
bridge, tanto en inglés [40] como en español [38].<br />
Los pasos que se muestran a continuación, para la configuración <strong>de</strong> <strong>una</strong> <strong>red</strong> <strong>de</strong><br />
área personal basada en Affix, siguen un mo<strong>de</strong>lo tomado <strong>de</strong>l documento<br />
DEMONSTRATE THE PAN IN LINUX SYSTEM [40], siendo adaptados a los<br />
recursos disponibles en este proyecto. Para cada uno <strong>de</strong> los casos, los módulos<br />
<strong>de</strong> Affix <strong>de</strong>ben estar correctamente cargados.<br />
5.2.3 Nodo maestro GN<br />
� Se <strong>de</strong>fine el bridge con el nombre br0 (pue<strong>de</strong> tener cualquier nombre no<br />
necesariamente este):<br />
[root@localhost.localdomain]# brctl addbr br0<br />
[root@localhost.localdomain]# ifconfig br0 10.0.0.1<br />
� Se <strong>de</strong>shabilita las características inteligentes <strong>de</strong>l 802.1d ethernet bridge:<br />
protocolo STP (spanning tree protocol) y los estados <strong>de</strong> aprendizaje y<br />
atención. Como resultado el puente se activará instantáneamente <strong>de</strong>spués <strong>de</strong><br />
que la interfaz pan0 <strong>de</strong> Affix haya sido creada. Si no se hacen estas llamadas<br />
el establecimiento pue<strong>de</strong> tomar unos 30 s, <strong>de</strong>pendiendo <strong>de</strong> la complejidad <strong>de</strong><br />
la <strong>red</strong> [42]:<br />
[root@localhost.localdomain]# brctl setfd br0 0<br />
[root@localhost.localdomain]# brctl stp br0 disable
� Se crea la interfaz pan0 <strong>de</strong> Affix<br />
[root@localhost.localdomain]# btctl paninit gn bt0<br />
� Se aña<strong>de</strong> pan0 al bridge y se configura su dirección IP en 0.0.0.0 para que<br />
sea transparente<br />
[root@localhost.localdomain]# brctl addif br0 pan0<br />
[root@localhost.localdomain]# ifconfig pan0 0.0.0.0<br />
� Para revisar el estado actual <strong>de</strong>l bridge, se escribe:<br />
[root@localhost.localdomain]# brctl show<br />
� Para mirar <strong>una</strong> lista <strong>de</strong> las conexiones remitidas sobre el bridge, se escribe:<br />
[root@localhost.localdomain]# brctl showmacs<br />
5.2.4 Nodos esclavos PANU1 y PANU2<br />
La configuración <strong>de</strong> estos nodos difiere únicamente <strong>de</strong> la dirección IP asignada a<br />
cada uno. Se ha <strong>de</strong> seguir el mismo procedimiento para cada caso con las<br />
direcciones IP correspondientes:<br />
� Se crea la interfaz pan0 <strong>de</strong> Affix<br />
[root@localhost.localdomain]# btctl paninit panu bt0<br />
� Se configura la dirección IP para cada interfaz <strong>de</strong> Affix<br />
En PANU1: [root@localhost.localdomain]# ifconfig pan0 10.0.0.2<br />
En PANU2: [root@localhost.localdomain]# ifconfig pan0 10.0.0.3<br />
� Para revisar la correcta configuración <strong>de</strong> las interfaces <strong>de</strong> <strong>red</strong>, se escribe:<br />
[root@localhost.localdomain]# ifconfig
� Ahora es necesario <strong>de</strong>finir la ruta por <strong>de</strong>fecto para la interfaz <strong>de</strong> Affix creada:<br />
[root@localhost.localdomain]# route add <strong>de</strong>fault gw 10.0.0.1<br />
� Se <strong>de</strong>be verificar el estado <strong>de</strong> la tabla <strong>de</strong> enrutamiento escribiendo:<br />
[root@localhost.localdomain]# route<br />
En este punto se tiene ya establecida <strong>una</strong> <strong>red</strong> <strong>de</strong> tres nodos, TCP/IP sobre<br />
Bluetooth. Des<strong>de</strong> el Nodo maestro GN, se escribe en la línea <strong>de</strong> comandos:<br />
[root@localhost.localdomain]# ping 10.0.0.2<br />
PING 10.0.0.2 (10.0.0.2) from 10.0.0.1 : 56(84) bytes of data.<br />
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=143 ms<br />
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=74.2 ms<br />
[root@localhost.localdomain]# ping 10.0.0.3<br />
PING 10.0.0.3 (10.0.0.2) from 10.0.0.1 : 56(84) bytes of data.<br />
64 bytes from 10.0.0.3: icmp_seq=1 ttl=64 time=144 ms<br />
64 bytes from 10.0.0.3: icmp_seq=2 ttl=64 time=75.2 ms<br />
Esto permite probar la existencia <strong>de</strong> la <strong>red</strong> TCP/IP, don<strong>de</strong> Bluetooth es<br />
transparente. En teoría cualquier servicio IP disponible en la <strong>red</strong> (telnet, ftp,<br />
servicios web, etc.) <strong>de</strong>bería acce<strong>de</strong>rse <strong>de</strong>s<strong>de</strong> otro nodo <strong>de</strong> la misma <strong>red</strong>.<br />
5.3 Software <strong>bluetooth</strong> para sistemas embebidos<br />
Esta sección hace referencia al proyecto BTno<strong>de</strong> rev 2.2 [43], conjuntamente<br />
<strong>de</strong>sarrollado por el laboratorio <strong>de</strong> re<strong>de</strong>s e Ingeniería <strong>de</strong> la computación TIK [44] y<br />
el Grupo <strong>de</strong> investigación para sistemas distribuidos [45] pertenecientes al Instituto
fe<strong>de</strong>ral Suizo <strong>de</strong> tecnología con se<strong>de</strong> en Zurich [46]. Este proyecto pue<strong>de</strong> ser <strong>de</strong><br />
gran ayuda para futuras tesis interesadas en el <strong>de</strong>sarrollo <strong>de</strong> sistemas autónomos<br />
inalámbricos y plataformas embebidas basadas en microcontrolador y que utilicen<br />
interfaz Bluetooth.<br />
BTno<strong>de</strong> tiene las siguientes características:<br />
� Microcontrolador: Atmel Atmega 128 L<br />
� Memoria: RAM <strong>de</strong> 64 kbyte, Flash ROM <strong>de</strong> 128 kbyte y 4 kbyte <strong>de</strong> EEPROM.<br />
� Módulo Bluetooth ROK 101 007 <strong>de</strong> Ericsson<br />
El sitio en Internet <strong>de</strong> este proyecto [43] ofrece documentación completa sobre el<br />
diseño <strong>de</strong>l Hardware, herramientas <strong>de</strong> <strong>de</strong>sarrollo para software (versiones para<br />
linux y windows), código fuente y archivos binarios <strong>de</strong>l stack embebido para el<br />
sistema BTno<strong>de</strong> y entre otras cosas <strong>una</strong> lista <strong>de</strong> correos para los interesados y<br />
colaboradores <strong>de</strong> este proyecto.
CONCLUSIONES<br />
En este proyecto se ha implementado satisfactoriamente <strong>una</strong> <strong>red</strong> <strong>inalámbrica</strong><br />
Bluetooth <strong>de</strong> tres nodos, <strong>de</strong>ntro <strong>de</strong> un rango <strong>de</strong> 10 m y utilizando las tarjetas<br />
BlueBoard_UV <strong>de</strong>sarrolladas. La comunicación se hizo usando tres PC´s mediante<br />
el uso <strong>de</strong> los stack Bluez y Affix, los cuales ofrecen herramientas que permitieron<br />
realizar y verificar diferentes conceptos <strong>de</strong> esta tecnología <strong>inalámbrica</strong>.<br />
Se estudió <strong>de</strong>talladamente la versión 1.0b <strong>de</strong> la especificación Bluetooth, así como<br />
los stack <strong>de</strong> protocolos Affix y Bluez. Los conceptos <strong>de</strong> Bluetooth adquiridos<br />
fueron esenciales para el <strong>de</strong>sarrollo <strong>de</strong> este proyecto y se aplicaron<br />
específicamente en la <strong>implementación</strong> <strong>de</strong> la <strong>red</strong> <strong>inalámbrica</strong> Bluetooth, principal<br />
objetivo planteado.<br />
Se ha podido investigar y analizar ampliamente el mercado <strong>de</strong> circuitos integrados<br />
y sistemas embebidos Bluetooth encontrándose que la cantidad y diversidad <strong>de</strong><br />
productos disponibles en el mercado son muy amplias, al igual que el número <strong>de</strong><br />
fabricantes que los ofrecen. La Información <strong>de</strong>tallada al respecto se pue<strong>de</strong><br />
encontrar en el CD-ROM adjunto.<br />
A lo largo <strong>de</strong>l proyecto, se han podido corroborar las principales ventajas <strong>de</strong> la<br />
tecnología Bluetooth tales como tamaño <strong>red</strong>ucido y bajo consumo <strong>de</strong> potencia. No<br />
se pue<strong>de</strong> afirmar lo mismo acerca <strong>de</strong>l bajo costo, ya que realmente no es aplicable<br />
en este momento en Colombia <strong>de</strong>bido a que la mayor parte <strong>de</strong> los dispositivos
equeridos para el <strong>de</strong>sarrollo o compra <strong>de</strong> sistemas Bluetooth no está disponible<br />
en nuestro país, incrementando los costos. A la fecha (Agosto/2003), la circuitería<br />
necesaria para la <strong>implementación</strong> <strong>de</strong> <strong>una</strong> tarjeta BlueBoard_UV es <strong>de</strong><br />
aproximadamente US $200.<br />
Las arquitecturas utilizadas por Affix y Bluez para implementar las capas<br />
superiores <strong>de</strong>l stack <strong>de</strong> protocolos Bluetooth son muy similares y se basan en<br />
conceptos <strong>de</strong>l subsistema <strong>de</strong> <strong>red</strong> <strong>de</strong> linux (como el <strong>de</strong> socket Berkeley entre<br />
otros), usados por los drivers <strong>de</strong> los dispositivos <strong>de</strong> <strong>red</strong> in<strong>de</strong>pendientemente <strong>de</strong>l<br />
protocolo que utilicen (Ethernet, X.25, etc).<br />
Para lograr que <strong>una</strong> <strong>red</strong> <strong>de</strong> dispositivos Bluetooth interactúe con otras tecnologías<br />
como Ethernet, Token Ring, ATM, etc., y a<strong>de</strong>más brin<strong>de</strong> y utilice los servicios<br />
TCP/IP que estén disponibles en la <strong>red</strong>, existen el protocolo <strong>de</strong> encapsulamiento<br />
<strong>de</strong> <strong>red</strong> BNEP <strong>de</strong> Bluetooth y el perfil PAN. Para lograr esto, Affix y Bluez, se valen<br />
<strong>de</strong>l estándar IEEE 802.1d ethernet bridge, implementado por Linux y utilizado para<br />
unificar en el nodo maestro las interfaces <strong>de</strong> <strong>red</strong> <strong>de</strong> Bluetooth en <strong>una</strong> sola interfaz<br />
la cual a su vez pue<strong>de</strong> servir <strong>de</strong> puente hacia <strong>una</strong> interfaz ethernet, <strong>de</strong> tal manera<br />
que la <strong>red</strong> Bluetooth y esta última conformen <strong>una</strong> <strong>red</strong> TCP/IP transparente a la<br />
tecnología <strong>de</strong> transporte <strong>de</strong> datos.<br />
Las pruebas <strong>de</strong> <strong>de</strong>sempeño <strong>de</strong> las tarjetas BlueBoard_UV, realizadas en este<br />
trabajo, revelaron valiosos datos <strong>de</strong> operación <strong>de</strong> los sistemas Bluetooth. Los<br />
valores máximos <strong>de</strong> distancia y velocidad <strong>de</strong> transmisión y los rangos <strong>de</strong> distancia<br />
entre nodos para un óptimo <strong>de</strong>sempeño (Do) tabulados y calculados como parte<br />
<strong>de</strong> este análisis, <strong>de</strong>muestran el buen funcionamiento <strong>de</strong> las tarjetas BlueBoard_UV<br />
en ambientes i<strong>de</strong>ales (en los que existe línea <strong>de</strong> vista entre nodos) y en ambientes
eales (tales como oficinas, plantas <strong>de</strong> producción y el hogar en los que las<br />
condiciones <strong>de</strong> operación no permiten esta línea <strong>de</strong> vista). La cobertura plástica<br />
propia <strong>de</strong> equipos portátiles, tales como teléfonos celulares, agendas electrónicas<br />
y teclados, refleja su inci<strong>de</strong>ncia en el <strong>de</strong>sempeño <strong>de</strong> las tarjetas <strong>de</strong> manera<br />
significativa solamente para los rangos mayores a Do. A<strong>de</strong>más se logró establecer<br />
comunicación entre tarjetas BlueBoard_UV hasta <strong>una</strong> distancia máxima <strong>de</strong> 12m en<br />
condiciones normales <strong>de</strong> operación. Información <strong>de</strong>tallada <strong>de</strong> las pruebas<br />
efectuadas, se pue<strong>de</strong> encontrar en el capítulo 5 <strong>de</strong> este documento.<br />
El conjunto <strong>de</strong> interfaces <strong>de</strong> las tarjetas BlueBoard_UV01 y BlueBoard_UV02<br />
(USB, UART, I2C y PCM), hacen <strong>de</strong> éstas sistemas muy flexibles y completos que<br />
facilitan la integración <strong>de</strong> la tecnología, en general, a cualquier sistema<br />
microprocesado o microcontrolado. Las capas superiores <strong>de</strong>l stack <strong>de</strong> protocolos<br />
Bluetooth en sus versiones para PC y sistemas embebidos se encuentran<br />
disponibles en internet bajo licencia GPL, ya sea para su directa utilización o para<br />
ser tomados como mo<strong>de</strong>lo <strong>de</strong> referencia para el <strong>de</strong>sarrollo <strong>de</strong> stacks más<br />
sencillos y <strong>de</strong>dicados a aplicaciones específicas. Las aplicaciones don<strong>de</strong> pue<strong>de</strong>n<br />
utilizarse las tarjetas son ilimitadas, ofreciendo muchas posibilida<strong>de</strong>s para futuros<br />
proyectos. Un ejemplo sería la <strong>implementación</strong> <strong>de</strong> un sistema microprocesado o<br />
microcontrolado que contenga las capas superiores <strong>de</strong>l stack Bluetooth (host<br />
stack) no contenidas en las tarjetas BlueBoard_UV. Este sistema interconectado<br />
con <strong>una</strong> tarjeta BlueBoard_UV conformaría un sistema embebido muy flexible y útil<br />
para aplicaciones específicas tales como re<strong>de</strong>s <strong>de</strong> sensores y actuadores<br />
inalámbricos.
REFERENCIAS<br />
[1] BLUETOOTH SPECIAL INTEREST GROUP. Disponible en Internet: < URL:<br />
http://www.<strong>bluetooth</strong>.com >.<br />
[2] MINISTERIO DE COMUNICACIONES DE COLOMBIA.<br />
CuadroAtribucion.pdf [Archivo PDF], Disponible en Internet: < URL:<br />
http://www.mincomunicaciones.gov.co >.<br />
[3] BLUETOOTH SPECIAL INTEREST GROUP. “Bluetooth Core”,<br />
Specification of the Bluetooth System, Versión 1.1, 22 <strong>de</strong> Febrero <strong>de</strong> 2003.<br />
Disponible en Internet: < URL: http:<br />
http://www.<strong>bluetooth</strong>.com/<strong>de</strong>v/specifications.asp >.<br />
[4] BLUETOOTH SPECIAL INTEREST GROUP. “Bluetooth Profiles”,<br />
Specification of the Bluetooth System, Versión 1.1, 22 <strong>de</strong> Febrero <strong>de</strong> 2003.<br />
Disponible en Internet: < URL: http://<br />
www.<strong>bluetooth</strong>.com/<strong>de</strong>v/specifications.asp >.<br />
[5] Disponible en Internet: < URL: http:// www.teleca.com, http://<br />
www.comtec.teleca.se >.<br />
[6] Disponible en Internet: < URL: http:// www.suyin.<strong>de</strong> >.<br />
[7] Disponible en Internet: < URL: http:// www.rangestar.com >.
[8] Disponible en Internet: < URL: http:// www.national.com >.<br />
[9] Disponible en Internet: < URL: http:// www.maxim-ic.com >.<br />
[10] Disponible en Internet: < URL: http:// www.csr.com >.<br />
[11] Disponible en Internet: < URL: http:// www.bluefrogsolution.com >.<br />
[12] Disponible en Internet: < URL: http:// www.national.com/<strong>bluetooth</strong> >.<br />
[13] Disponible en Internet: < URL: http:// www.atmel.com >.<br />
[14] Disponible en Internet: < URL: http:// www.digianswer.com >.<br />
[15] Disponible en Internet: < URL: http:// www.3com.com >.<br />
[16] Disponible en Internet: < URL: http:// www.smartm.com >.<br />
[17] Disponible en Internet: < URL: http:// www.anoto.com >.<br />
[18] Disponible en Internet: < URL: http:// www.motorola.com >.<br />
[19] Disponible en Internet: < URL: http:// qualweb.opengroup.org >.<br />
[20] M. Ali and G. J. Hayes, “Analysis of Integrated-F Antennas for Bluetooth<br />
Applications,” 2000 IEEE-APS Conference on Antennas and Propagation for<br />
Wireless Communications, November 2000.
[21] R. Wansch, H. Humpfer, and J. Hupp, “An Integrated F-Antenna for<br />
Diversity Reception in a DECT Data Transmission Module,” IEEE Antennas<br />
Propagation Society International Symposium, July 2000.<br />
[22] MEZOE, Cambridge Consultants Ltd. BlueStack User Manual, 2001, p. 20 –<br />
22. Disponible en Internet: < URL: http://www.mezoe.com >.<br />
[23] ERICSSON MOBILE COMMUNICATIONS. Bluetooth HOST Stack,<br />
HostSW0601.pdf [Archivo PDF], Lund (Swe<strong>de</strong>n), Octubre <strong>de</strong> 2000.<br />
Disponible en Internet: < URL: http://www.ericsson.com/<strong>bluetooth</strong>/ >.<br />
[24] DIGIANSWER. Bluetooth MkII Democard, productsheet-dc-mk2.pdf [Archivo<br />
PDF]. Disponible en Internet: .<br />
[25] Heuser, Werner. Laptops, Bluetooth(TM) and Linux, 23 <strong>de</strong> Abril <strong>de</strong> 2003.<br />
Disponible en Internet: .<br />
[26] AXIS, Código fuente <strong>de</strong> OpenBt [Archivo tar.gz]. Disponible en Internet:<br />
.<br />
[27] AXIS, Portal en Internet: < URL:<br />
http://<strong>de</strong>veloper.axis.com/software/<strong>bluetooth</strong>/>.<br />
[28] IBM, Sitio <strong>de</strong> Internet <strong>de</strong> Alpha Works: < URL:<br />
http://www.alphaworks.ibm.com/tech/bluedrekar>.<br />
[29] AFFIX, portal en Internet: < URL: http://affix.sourceforge.net>.
[30] BlueZ, disponible en Internet: .<br />
[31] KASATKIN, Dmitri. Affix in a Nutshell, Nokia Corporation, 2001-2002.<br />
Disponible en Internet: [Formato html]: < URL:<br />
http://affix.sourceforge.net/affix-doc/in<strong>de</strong>x.html >. [Formato PDF]: < URL:<br />
http://affix.sourceforge.net/affix-doc/affix-doc.pdf >.<br />
[32] UNIX Networking Programming, Volúmen 1: Networking APIs - Sockets and<br />
XTI, Prentice Hall, 17 <strong>de</strong> Octubre <strong>de</strong> 1997.<br />
[33] BEUTEL, Jan y KRASNYANSKIY, Maksim. Linux BlueZ Howto, 14 <strong>de</strong><br />
Noviembre <strong>de</strong> 2001. Disponible en Internet [En línea]: < URL:<br />
http://bluez.sourceforge.net/howto/in<strong>de</strong>x.html >.<br />
[34] BLUETOOTH SPECIAL INTEREST GROUP. Personal Area Networking<br />
Profile. Specification of the Bluetooth System, Versión 1.0, 14 <strong>de</strong> Febrero <strong>de</strong><br />
2003. Disponible en Internet: < URL:<br />
http://www.<strong>bluetooth</strong>.com/<strong>de</strong>v/specifications.asp>.<br />
[35] BLUETOOTH SPECIAL INTEREST GROUP. Bluetooth Network<br />
Encapsulation Protocol (BNEP) Specification. Specification of the Bluetooth<br />
System, Versión 1.0, 14 <strong>de</strong> Febrero <strong>de</strong> 2003. Disponible en Internet: < URL:<br />
http://www.<strong>bluetooth</strong>.com/<strong>de</strong>v/specifications.asp>.<br />
[36] Disponible en Internet: < URL: http://<br />
http://www.iana.org/assignments/ethernet-numbers >.
[37] DIGITAL EQUIPMENT CORPORATION, INTEL CORPORATION, XEROX<br />
CORPORATION. The Ethernet – A Local Area Network, Versión 1.0.<br />
Septiembre <strong>de</strong> 1980.<br />
[38] BÉJAR, Eduardo. Linux Ethernet Bridge, Guia <strong>de</strong> Instalación, 8 <strong>de</strong><br />
Noviembre <strong>de</strong> 2002. Disponible en Internet: < URL:<br />
http://www.linkabu.net/linux/ >.<br />
[39] Código fuente <strong>de</strong>l paquete bridge-utils. Disponible en Internet: < URL:<br />
http://bridge.sourceforge.net/download.html>.<br />
[40] Layer 2 ethernet bridging with Linux, 7 <strong>de</strong> Noviembre <strong>de</strong> 2001. Disponible<br />
en Internet: < URL: http://bridge.sourceforge.net/>.<br />
[41] Demonstrate the PAN in Linux system. Disponible en Internet [Formato<br />
html]: < URL: http://affix.sourceforge.net/archive/PAN/affix_pan_<strong>de</strong>mo.html ><br />
[Formato pdf]: < URL:<br />
http://affix.sourceforge.net/archive/PAN/aff_pan_<strong>de</strong>m.pdf>.<br />
[42] SCHMIDT, Michael. HowTo set up common PAN scenarios with BlueZ's<br />
integrated PAN support. University of Siegen, Germany. Disponible en<br />
Internet: < URL: http://bluez.sourceforge.net/contrib/HOWTO-PAN>.<br />
[43] BTnod rev 2.2 project. Disponible en Internet: < URL:<br />
http://www.inf.ethz.ch/vs/res/proj/smart-its/btno<strong>de</strong>.html#sw>.<br />
[44] Computer Engineering and Networks Laboratory (tik). Sitio en Internet<br />
disponible en: < URL: http://www.tik.ee.ethz.ch/>.
[45] Research Group for Distributed Systems. Sitio en Internet disponible en: <<br />
URL: http://www.inf.ethz.ch/vs/>.<br />
[46] Swiss Fe<strong>de</strong>ral Institute of Technology Zurich. Sitio en Internet disponible en:<br />
< URL: http://www.ethz.ch/>.