implementación de una red inalámbrica bluetooth - Universidad del ...

IMPLEMENTACIÓN DE UNA RED INALÁMBRICA
BLUETOOTH
OSCAR DARÍO RODRÍGUEZ CALVACHI
RICARDO ANDRÉS MAYA CORAL
Trabajo de grado presentado como requisito para obtener el título de
Ingeniero Electrónico
Director
FABIO G. GUERRERO MORENO
UNIVERSIDAD DEL VALLE
FACULTAD DE INGENIERÍA
ESCUELA DE INGENIERÍA ELÉCTRICA Y ELECTRÓNICA
PROGRAMA DE INGENIERÍA ELECTRÓNICA
SANTIAGO DE CALI
2003

Santiago de Cali, Agosto de 2003
Nota de aceptación:
___________________________________
___________________________________
___________________________________
___________________________________
___________________________________
___________________________________
___________________________________
Director: Fabio G. Guerrero Moreno
___________________________________
Jurado: Asfur Baradica López
___________________________________
Jurado: Oscar Polanco Sarmiento

A mis padres, por todos sus consejos y apoyo incondicional. A mis hermanos, que
es por quienes trato de ser cada día mejor para ser un ejemplo a seguir. A toda mi
familia, que es mi apoyo en todo difícil momento de la vida. A todos ellos…
Oscar Darío Rodríguez Calvachi
A mis padres, por su cariño, comprensión y confianza. A mis hermanos que son mi
pilar de apoyo y a mi familia, la fuente que me anima a seguir mi camino.
Ricardo Andrés Maya Coral

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

CONTENIDO
INTRODUCCIÓN 22
1. DESCRIPCIÓN GENERAL DE LA TECNOLOGÍA INALÁMBRICA BLUETOOTH 23
1.1 BANDA BASE 29
1.1.1 Descripción general. 29
1.1.2 Canal físico. 30
1.1.3 Enlace físico. 30
1.1.4 Paquetes. 31
1.1.5 Corrección de errores. 33
1.1.6 Transmisión/Recepción. 34
1.1.7 Control de Canal. 35
1.1.8 Seguridad en Bluetooth. 38
1.2 PROTOCOLO DE GESTIÓN DE ENLACE (LMP) 38
1.2.1 Establecimiento de conexión. 39
1.3 INTERFAZ DEL CONTROLADOR DE HOST (HCI) 40
1.3.1 Capas mas bajas del stack Bluetooth. 40
1.3.2 Posibles arquitecturas de bus físico. 42
1.4 PROTOCOLO DE CONTROL Y ADAPTACIÓN DE ENLACE LÓGICO (L2CAP) 43
1.4.1 Canales. 43
1.4.2 Operaciones entre Capas. 43
pág.

1.4.3 Segmentación y Reensamblado. 44
1.4.4 Eventos. 45
1.4.5 Acciones. 45
1.4.6 Formato del paquete de datos. 45
1.4.7 Calidad de servicio (QoS). 46
1.5 PROTOCOLO DE DESCUBRIMIENTO DE SERVICIO (SDP) 47
1.5.1 Descripción General. 47
1.5.2 Registros de servicio. 47
1.5.3 El protocolo. 47
1.6 RFCOMM 49
1.7 PERFILES BLUETOOTH 50
1.7.1 Perfil Genérico de Acceso (GAP). 51
1.7.2 Perfil de Puerto Serial. 51
1.7.3 Perfil de Aplicación de Descubrimiento de Servicio (SDAP). 52
1.7.4 Perfil Genérico de Intercambio de Objetos (GOEP). 52
1.7.5 Perfil de Telefonía Inalámbrica 52
1.7.6 Perfil de Intercomunicador. 52
1.7.7 Perfil de Manos Libres. 53
1.7.8 Perfil Dial-up Networking. 53
1.7.9 Perfil de Fax. 53
1.7.10 Perfil de Acceso LAN. 53
1.7.11 Perfil Object Push. 54
1.7.12 Perfil de Transferencia de Archivos. 54

1.7.13 Perfil de Sincronización. 54
2. DESCRIPCIÓN DE HARDWARE Y PRODUCTOS BLUETOOTH 55
2.1 TARJETAS BLUEBOARDUV 55
2.1.1 Descripción de las tarjetas BlueboardUV. 57
2.1.2 Descripción de componentes y requerimientos en las tarjetas BlueboardUV. 63
2.1.2.1 Módulo Bluetooth Ericsson ROK101007/8. 63
2.1.2.2 Diseño de Antena. 67
2.1.2.3 Antenas RangeStar. 72
2.1.2.4 Regulador de Voltaje National LP2987. 76
2.1.2.5 MAXIM MAX3232. 77
2.1.2.6 Soporte SUYIN BT001A-30G2T. 77
2.1.3 Fotografías de las tarjetas BlueboardUV. 78
2.2 PRODUCTOS BLUETOOTH 81
2.3 PROCEDIMIENTO DE CALIFICACIÓN BLUETOOTH 82
2.4 ANTENAS EN F INVERTIDA INTEGRADAS 83
3. SOFTWARE PARA EL HOST BLUETOOTH 85
3.1 ARQUITECTURAS DE INTEGRACIÓN DEL STACK DE PROTOCOLOS
BLUETOOTH 88
3.2 PRINCIPALES SOFTWARE PARA EL HOST 90
3.2.1 Software Bluetooth con propiedad de licencia. 91
3.2.2 Software Bluetooth con licencia pública (GPL) 93
3.3 CONCEPTOS DEL CORE DE LINUX 95

3.4 DESCRIPCIÓN DEL STACK DE PROTOCOLOS DE AFFIX 98
3.4.1 Arquitecturas Soportadas 98
3.4.2 Hardware Soportado 99
3.4.3 Arquitectura de Affix 99
3.4.4 Utilidades de Affix 102
3.4.5 Instrucciones de Instalación 102
3.5 DESCRIPCIÓN DEL STACK DE PROTOCOLOS BLUEZ 103
3.5.1 Compilación e Instalación 105
4. CONCEPTOS BÁSICOS PARA LA IMPLEMENTACIÓN DE UNA RED DE AREA
PERSONAL BLUETOOTH 108
4.1 PROTOCOLO DE ENCAPSULAMIENTO DE RED BNEP 108
4.1.1 Consideraciones 109
4.1.2 Orden de los Bytes y Valores numéricos 110
4.1.3 Encapsulamiento de Paquetes 111
4.1.4 Formato de los Encabezados BNEP 111
4.1.5 Tipo de Paquete BNEP_GENERAL_ETHERNET 113
4.1.6 Tipo de Paquete BNEP_CONTROL 114
4.1.7 Tipo de Paquete BNEP_COMPRESSED_ETHERNET 114
4.1.8 Tipo de Paquete BNEP_COMPRESSED_ETHERNET_SOURCE_ONLY 115
4.1.9 Tipo de Paquete BNEP_COMPRESSED_ETHERNET_DEST_ONLY 116
4.2 Piconet y scatternet 117
4.3 PERFIL DE RED DE AREA PERSONAL (PAN PROFILE) 120

4.3.1 Consideraciones 121
4.3.2 Puntos de Acceso a una red (NAP) 121
4.3.3 Grupo de Red Ad-hoc 123
4.3.4 PANU – PANU 125
5. PRUEBAS DE DESEMPEÑO Y APLICACIÓN PARA LAS TARJETAS
BLUEBOARD_UV01 Y BLUEBOARD_UV02 126
5.1 PRUEBAS DE DESEMPEÑO 127
5.1.1 Configuración para las Pruebas 127
5.1.2 Descripción de las Pruebas 127
5.1.3 Dependencias entre la velocidad de transmisión, los obstáculos y la distancia entre
los nodos 130
5.1.4 Estabilidad de la velocidad de transmisión respecto a la distancia y los obstáculos
entre los nodos 136
5.2 IMPLEMENTACIÓN DE UNA RED DE AREA PERSONAL BLUETOOTH 140
5.2.1 Configuración de la PAN 141
5.2.2 Ethernet Bridging 142
5.2.3 Nodo maestro GN 143
5.2.4 Nodos esclavos PANU1 y PANU2 144
5.3 Software bluetooth para sistemas embebidos 145
6. CONCLUSIONES 147
REFERENCIAS

LISTA DE FIGURAS
Figura 1-1. Stack de Protocolo Bluetooth 24
Figura 1-2. Modelo de referencia OSI y Bluetooth 28
Figura 1-3. Diagrama de una piconet. 29
Figura 1-4. Transmisión en una piconet. 30
Figura 1-5. Formato de paquete general 31
Figura 1-6. Formato de cabecera de paquete 33
Figura 1-7. Iniciación de comunicación sobre el nivel banda base 37
Figura 1-8. Dirección de dispositivo Bluetooth 37
Figura 1-9. Establecimiento de la conexión 40
Figura 1-10. Diagrama general de las capas más bajas 41
Figura 1-11. Diagrama general end to end de las capas de software más bajas 42
Figura 1-12. Arquitectura L2CAP 44
Figura 1-13. Segmentación L2CAP 45
Figura 1-14. Paquete L2CAP 46
Figura 1-15. Varios puertos seriales emulados mediante RFCOMM 49
Figura 1.16. Los Perfiles Bluetooth 51
Figura 2-1. Diagrama de Bloques de las tarjetas BlueboardUV 56
Figura 2-2. Diagrama esquemático de las tarjetas BlueboardUV 59
Figura 2-3. Diagrama del hardware de la tarjeta BlueboardUV01 61
pág.

Figura 2-4. Diagrama del hardware de la tarjeta BlueboardUV02 62
Figura 2-5. HW/FW del módulo Ericsson ROK101007 65
Figura 2-6. Configuración Típica USB para el ROK101007 66
Figura 2-7. Configuración Típica UART o PCM para el ROK101007 67
Figura 2-8. Ganancia Pico vs. Longitud PCB 69
Figura 2-9. Ruteo de la parte superior de la tarjeta BlueboardUV01 70
Figura 2-10. Ruteo de la parte inferior de la tarjeta BlueboardUV01 71
Figura 2-11. Ruteo de la parte superior de la tarjeta BlueboardUV02 71
Figura 2-12. Ruteo de la parte inferior de la tarjeta BlueboardUV03 72
Figura 2-13. Antena RangeStar 100929 74
Figura 2-14. Antena RangeStar 100930 74
Figura 2-15. Requerimientos para las antenas RangeStar 100929 y100930 76
Figura 2-16. Diagrama de bloques del regulador de voltaje LP2987 77
Figura 2-17. Bluetooth Carrier Socket SUYIN BT001A-30G2T 78
Figura 2-18. Tarjeta BlueboardUV01 79
Figura 2-19. Módulo Bluetooth dentro del soporte en la tarjeta BlueboardUV01 79
Figura 2-20. Tarjeta BlueboardUV01 en funcionamiento 80
Figura 2-21. Tarjeta BlueboardUV02 80
Figura 2-22. Antena en F Invertida Integrada (IIFA) 84
Figura 3-1. Modelo de implementación del protocolo Bluetooth, Host – Hardware 86
Figura 3-2. Modelo de Implementación del protocolo Bluetooth. Software – Firmware –
Hardware 87
Figura 3-3. Tres modelos de Integración del stack de protocolos Bluetooth 89

Figura 3-4. Arquitectura de Red de Linux 95
Figura 3-5. Modelo de la Arquitectura de Affix 100
Figura 3-6. Diagrama de los Componentes de Affix 101
Figura 3-7. Diagrama de la Arquitectura de Bluez 104
Figura 4-1. Ubicación del BNEP dentro de la Torre de protocolos de Bluetooth. 110
Figura 4-2. Encapsulamiento de un Paquete Ethernet en un paquete L2CAP 111
Figura 4-3. Formato de los Encabezados BNEP 112
Figura 4-4. Formato del Encabezado para un paquete BNEP_GENERAL_ETHERNET 113
Figura 4-5. Formato del Encabezado para un paquete BNEP_CONTROL 114
Figura 4-6. Formato del encabezado para un paquete
BNEP_COMPRESSED_ETHERNET 115
Figura 4-7. Formato del encabezado para un paquete
BNEP_COMPRESSED_ETHERNET_SOURCE_ONLY 115
Figura 4-8. Formato del encabezado para un paquete
BNEP_COMPRESSED_ETHERNET_DEST_ONLY 116
Figura 4-9. Ejemplo del envío de un paquete IPv4 usando BNEP entre un dispositivo con
dirección IEEE y otro con dirección Bluetooth 117
Figura 4-10. Esquema de una Piconet 118
Figura 4-11. Ejemplo de una Piconet 118
Figura 4-12. Esquema de una Scatternet 119
Figura 4-13. Ejemplo de una Scatternet 120
Figura 4-14. Dos Puntos de Acceso a Red 122
Figura 4-15. Stack para el rol NAP 123

Figura 4-16. Esquema para un Grupo de Red Ad-hoc (GN) 124
Figura 4-17. Stack para un enlace en una red Ad-hoc Bluetooth 125
Figura 5-1. Arquitectura utilizada en las pruebas de desempeño 128
Figura 5-2. Rata de Bits Promedio Vs. Distancia 133
Figura 5-3. Porcentaje de variación de la rata de Bits Vs. Distancia 138
Figura 5-4. Arquitectura de la red de área personal 141

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

GLOSARIO
ACL: asynchronous Connectionless (asíncrono no orientado a la conexión).
ANSI: American National Standards Institute.
API: application program interface (Interfaz del programa de aplicación).
ARQUITECUTURA: intel, ARM (iPaq, ARM9 y otras) y PowerPC (iMac) entre
otras.
ATM: (modo de transferencia asíncrona) dentro del medio informático hace
referencia a la conmutación de paquetes (cells -- celdas o células) de un tamaño
fijo con alta carga, rápida velocidad (entre 1,544 Mbps. y 1,2 Gbps) y una
asignación dinámica de ancho de banda. También se conoce como "paquete
veloz" (fast packet).
BD_ADDR: dirección del dispositivo Bluetooth.
BNEP: Bluetooth network encapsulation protocol.
BQP Bluetooth Qualification Program.
CAD: computer aided design (diseño asistido por computador).
CID: identificador de canal.

CRC: chequeo de redundancia cíclica.
DBI: sigla para “decibeles relativos a una fuente isotrópica”.
DCE: data communications equipment. Dispositivo que provee una trayectoria de
comunicación entre dos equipos. Por ejemplo el módem en un computador.
DRIVER: controlador que permite gestionar los periféricos que están conectados
al ordenador (http://www.guiahost.com/servicios/glosario).
ESPACIO DE KERNEL: espacio de memoria ocupado por el código compilado del
kernel de linux.
ESPACIO DE USUARIO: espacio de memoria ocupado por el código compilado
de los programas de aplicación del usuario.
ETHERNET: red de área local (LAN) desarrollada por Xerox, Digital e Intel. Es el
método de acceso LAN que más se utiliza (seguido por Token Ring). Ethernet es
una LAN de medios compartidos. Todos los mensajes se diseminan a todos los
nodos en el segmento de red (http://www.guiahost.com/servicios/glosario).
ETSI: European Telecommunications Standards Institute. Organización sin ánimo
de lucro cuya misión es crear estándares de telecomunicaciones para ser usados
por décadas en Europa (http://www.etsi.org).
FCC: Comisión Federal de Comunicaciones. Su principal función es la de
mantener el control sobre el amplio sector de las telecomunicaciones en los
Estados Unidos (http://www.guiahost.com/servicios/glosario).
FIFO: first In first out. El primero en entrar es el primero en salir.

FIRMWARE: parte del software de un ordenador que no puede modificarse por
encontrarse en la ROM o memoria de sólo lectura, Read Only Memory. Es una
mezcla o híbrido entre el hardware y el software, es decir tiene parte física y una
parte de programación consistente en programas internos implementados en
memorias no volátiles. Un ejemplo típico de Firmware lo constituye la BIOS.
(http://www.guiahost.com/servicios/glosario).
GAP: generic access profile (perfil genérico de acceso).
GNU: es un acrónimo recursivo para ``no es Unix'' Se crea en 1984 sin mucho
éxito, bajo la filosofía del software libre, muy al estilo de UNIX.
GOEP: generic object exchange profile (perfil genérico de intercambio de objetos).
GPL: licencia pública general (general public license), desarrollada por la FSF o
Free Software Foundation. Puede ser instalado sin limitación en uno o varios
ordenadores. En las distribuciones de estos programas debe estar incluido el
código fuente.
HARDWARE: componentes electrónicos y electro-mecánicos de una computadora
o cualquier otro sistema. Este término es usado para distinguir estos componentes
físicos de los datos y programas.
HCI: host controller interface (interfaz controladora del host).
HEC: chequeo de redundancia cíclica de encabezados.
HOST: sistema microprocesado programable (PCs, teléfonos celulares, mouse,
impresoras, teclados, sensores inalámbricos, etc.), capaz de ejecutar las líneas de
código correspondientes al stack de protocolos Bluetooth para el host.

HW / FW: hardware / firmware.
I 2 C: interfaz de datos de dos líneas (SDA y SCL) que utiliza palabras de 8 bits y es
usada para comunicar memorias, controladores de video, preamplificadores de
audio y otros dipositivos.
IAC: codigo de acceso de búsqueda.
IFA: inverted F antenna (antena en F invertida).
ISM: industrial, scientific, medical.
KERNEL: núcleo, es la parte fundamental de un programa, por lo general de un
sistema operativo, que reside en memoria todo el tiempo y que provee los
servicios básicos. Es la parte del sistema operativo que está más cerca de la
máquina y puede activar el hardware directamente o unirse a otra capa de
software que maneja el hardware (http://www.guiahost.com/servicios/glosario).
L2CAP: logical link controller and adaptation protocol (protocolo de adaptación y
control de enlace lógico).
LMP: link manager protocol (Protocolo del administrador de enlace).
ME: management entity (entidad de administración o manejo).
MODULO BLUETOOTH: módulo multichip que implementa en hardware y
firmware las capas bajas del stack de protocolos Bluetooth.
MTU: maximun transmission unit.

PAD: punto de conexión del terminal de un dispositivo.
PAGING: servicio para transferencia de señalización o información en un sentido,
mediante paquetes, tonos, etc…
PAN: personal area networking.
PATH: es la trayectoria de una pista en un circuito impreso.
PCB: printed Circuit Board (Tarjeta de circuito impreso).
PPP: point to point protocol (Protocolo punto-a-punto).
QoS: calidad de servicio.
RF: radio frecuencia.
RFCOMM: serial port emulation basado en el estándar ETSI TS07.10.
SAR: segmentación y reensamblado.
SCO: synchronous connection oriented (Síncrono orientado a la conexión).
SDAP: service discovery aplication protocol (perfil de aplicación de descubrimiento
de servicio).
SDP: service discovery protocol (protocolo de descubrimiento de servicio).
SIG: special interest group.

SOCKET: es una abstracción de red para los terminales de un canal. El Socket
está asociado con el protocolo; usualmente, el PF_INET es usado para asociar un
socket con el protocolo TCP/IP.
TIMEOUT: tiempo de espera excedido.
TIMESLOT: ranura de tiempo. En Bluetooth tiene una duración de 625 us.
TOKEN RING: el anillo de Fichas (token ring), es una red de topología de anillo
que se sirve del pase de fichas para el control de acceso. La frase también se
aplica a una topología de pase de fichas específica definida por la IBM Corporation
(http://www.guiahost.com/servicios/glosario).
TRANSCEIVER: transmisor-receptor.
UART: el transmisor receptor universal asíncrono (universal asynchronous
receiver transmitter), es un dispositivo que multiplexa datos paralelos en seriales
para ser transmitidos y convierte en paralelos los datos seriales recibidos.
USB: la característica principal del bus serie universal (universal serial bus) reside
en que los periféricos pueden conectarse y desconectarse con el equipo en
marcha, configurándose de forma automática. Conector externo que llega a
transferencias de 12 millones de bits por segundo. Totalmente PnP, sustituirá al
puerto serie y paralelo, gracias a la posibilidad de conectar 127 dispositivos.
(http://www.guiahost.com/servicios/glosario).
WAP: wireless application protocol (protocolo para aplicaciones inalámbricas).

RESUMEN
El aporte principal de este trabajo es el desarrollo de un sistema Bluetooth semiembebido.
En principio, se analizó detalladamente la especificación Bluetooth y se
hizo un estudio de los productos disponibles en el mercado. Con el conocimiento
adquirido se diseñaron y construyeron dos tipos de tarjeta Bluetooth,
BlueBoard_UV01 y BlueBoard_UV02. En este documento se describe en detalle
su funcionamiento, al igual que se presentan sus diagramas, características y
materiales empleados, entre otros. Además se analizaron diferentes stacks de
protocolos Bluetooth (Affix y Bluez), con los cuales y utilizando las tarjetas
construidas, se implementó una red inalámbrica de carácter didáctico. Con los
sistemas desarrollados, se hicieron pruebas de desempeño logrando verificar y
analizar principios básicos de operación de esta tecnología.
PALABRAS CLAVE: Bluetooth
Redes Inalámbricas
Comunicaciones Móviles

INTRODUCCIÓN
Estamos en un mundo en el cual la movilidad es una necesidad en constante
aumento y en el que el acceso a la información no puede tener límites. En aras de
satisfacer estas necesidades, han surgido nuevas tecnologías, cada una enfocada
en un campo de acción específico. Teléfonos móviles (acceso a WAN), WLAN
IEEE 802.11 (acceso a LAN) y Bluetooth (acceso a PAN), son ejemplos de
tecnologías inalámbricas, cada una con un campo de acción diferente, pero que
en conjunto conforman una completa solución a los problemas de movilidad.
Colombia está en una época de transición tecnológica, modernizando su
infraestructura de comunicaciones y masificando poco a poco el acceso a la
misma. Casos como el de la telefonía móvil de segunda y tercera generación
(PCS y otras que usan GSM), implican más y mejores servicios (transmisión de
audio y video con buena definición), que promueven e incentivan el uso de
tecnologías como Bluetooth.
Este trabajo de grado, cimienta las bases para conocer y aprender la tecnología
inalámbrica Bluetooth en la Universidad del Valle, diseñar hardware Bluetooth y
realizar aplicaciones prácticas dirigidas a desarrollar nuevos sistemas que con la
ayuda de otros campos de la electrónica como por ejemplo la instrumentación y la
automática, resuelvan otro tipo de problemas a través de redes de censado y
actuadores inalámbricos.

1. DESCRIPCIÓN GENERAL DE LA TECNOLOGÍA
INALÁMBRICA BLUETOOTH
La tecnología inalámbrica Bluetooth ofrece una forma de remplazar cables y
enlaces infrarrojos que interconectan dispositivos por un enlace de radio universal
de corto alcance, con capacidad de crear pequeñas radio LANs. El nombre
Bluetooth viene de un rey danés llamado Harald Blaatand (en inglés “Bluetooth”)
quien vivió entre los años 940 y 981 y quien controló a Noruega y Dinamarca.
En Febrero de 1998, se fundó el Bluetooth Special Interest Group (SIG), creado
con el fin de ofrecer soporte para la nueva tecnología. Actualmente, más de mil
compañías lo integran y trabajan conjuntamente por un estándar abierto para el
concepto Bluetooth [1].
Bluetooth es un sistema de radio que opera en la banda de frecuencia libre de 2.4
GHz, esta banda de frecuencia está disponible en la mayor parte del mundo. En
Colombia el Ministerio de Comunicaciones reglamenta su uso así: “Las bandas,
902 - 924 MHz, 2 400 - 2 483,5 MHz y 5 725 - 5 850 MHz se atribuyen a título
secundario, conforme con la resolución 3382 de 15 de diciembre de 1995, para los
sistemas de espectro ensanchado” [2]. Bluetooth utiliza 79 canales de radio
frecuencia con un ancho de banda de 1 MHz cada uno y una rata máxima de
símbolos de 1 MSímbolo/s. Después de que cada paquete es enviado en una
determinada frecuencia de transmisión, ésta cambia a otra de las 79 frecuencias
[3]. El rango típico de operación de Bluetooth es menor a 10 m, sin embargo se
pueden alcanzar distancias de hasta 100 m con el uso de amplificadores.

Como se puede observar en la Figura 1-1, la comunicación sobre Bluetooth se
divide en varias capas. A continuación se presenta una breve descripción de
algunas de ellas y se tratarán en mayor detalle en sub-capítulos posteriores.
Figura 1-1. Stack de Protocolo Bluetooth
La capa de comunicación más baja es llamada banda base. Esta capa
implementa el canal físico real. Emplea una secuencia aleatoria de saltos a través
de 79 frecuencias de radio diferentes. Los paquetes son enviados sobre el canal
físico, donde cada uno es enviado en una frecuencia de salto diferente. La Banda

Base controla la sincronización de las unidades Bluetooth y la secuencia de saltos
en frecuencia, además es la responsable de la información para el control de
enlace a bajo nivel como el reconocimiento, control de flujo y caracterización de
carga útil y soporta dos tipos de enlace: síncrono orientado a la conexión (SCO),
para datos y asíncrono no orientado a la conexión (ACL), principalmente para
audio. Los dos pueden ser multiplexados para usar el mismo enlace RF. Usando
ancho de banda reservado, los enlaces SCO soportan tráfico de voz en tiempo
real.
El Link Manager Protocol (LMP) o Protocolo de Gestión de Enlace es el
responsable de la autenticación, encriptación, control y configuración del enlace.
El LMP también se encarga del manejo de los modos y consumo de potencia,
además soporta los procedimientos necesarios para establecer un enlace SCO.
El Host Controller Interface (HCI) o Interfaz del Controlador de Enlace brinda un
método de interfaz uniforme para acceder a los recursos de hardware de
Bluetooth. Éste contiene una interfaz de comando para el controlador banda base
y la gestión de enlace y para acceder al hardware.
El Logical Link Control and Adaptation Protocol (L2CAP) o Protocolo de
Control y Adaptación de Enlace Lógico, corresponde a la capa de enlace de datos.
Ésta brinda servicios de datos orientados y no orientados a la conexión a capas
superiores. L2CAP multiplexa los protocolos de capas superiores con el fin de
enviar varios protocolos sobre un canal banda base. Con el fin de manipular
paquetes de capas superiores más grandes que el máximo tamaño del paquete
banda base, L2CAP los segmenta en varios paquetes banda base. La capa
L2CAP del receptor reensambla los paquetes banda base en paquetes más

grandes para la capa superior. La conexión L2CAP permite el intercambio de
información referente a la calidad de la conexión, además maneja grupos, de tal
manera que varios dispositivos pueden comunicarse entre sí.
El Sevice Discovery Protocol (SDP) o Protocolo de Descubrimiento de Servicio
define cómo actúa una aplicación de un cliente Bluetooth para descubrir servicios
disponibles de servidores Bluetooth, además de proporcionar un método para
determinar las características de dichos servicios.
El protocolo RFCOMM ofrece emulación de puertos seriales sobre el protocolo
L2CAP. RFCOMM emula señales de control y datos RS-232 sobre la banda base
Bluetooth. Éste ofrece capacidades de transporte a servicios de capas superiores
(por ejemplo OBEX) que usan una línea serial como mecanismo de transporte.
RFCOMM soporta dos tipos de comunicación, directa entre dispositivos actuando
como endpoints y dispositivo-modem-dispositivo, además tiene un esquema
para emulación de null modem.
El control de telefonía binario (TCS binario) es un protocolo que define la
señalización de control de llamadas, para el establecimiento y liberación de una
conversación o una llamada de datos entre unidades Bluetooth. Además, éste
ofrece funcionalidad para intercambiar información de señalización no relacionada
con el progreso de llamadas.
La capa de Audio es una capa especial, usada sólo para enviar audio sobre
Bluetooth. Las transmisiones de audio pueden ser ejecutadas entre una o más
unidades usando muchos modelos diferentes. Los datos de audio no pasan a
través de la capa L2CAP, pero sí directamente después de abrir un enlace y un
establecimiento directo entre dos unidades Bluetooth.

• Protocolos Específicos
� Control de telefonía – Comandos AT. Bluetooth soporta un número de
comandos AT para el control de telefonía a través de emulación de puerto
serial (RFCOMM).
� Protocolo Punto-a-Punto (PPP). El PPP es un protocolo orientado a
paquetes y por lo tanto debe usar su mecanismo serial para convertir un
torrente de paquetes de datos en una corriente de datos seriales. Este
protocolo corre sobre RFCOMM para lograr las conexiones punto-a-punto.
� Protocolos UDP/TCP – IP. Los estándares UDP/TCP e IP permiten a las
unidades Bluetooth conectarse, por ejemplo a Internet, a través de otras
unidades conectadas. Por lo tanto, la unidad puede actuar como un puente
para Internet. La configuración TCP/IP/PPP está disponible como un
transporte para WAP.
� Wireless Aplication Protocol (WAP) o Protocolo de Aplicación
Inalámbrica. WAP es una especificación de protocolo inalámbrica que
trabaja con una amplia variedad de tecnologías de red inalámbricas
conectando dispositivos móviles a Internet. Bluetooth puede ser usado
como portador para ofrecer el transporte de datos entre el cliente WAP y su
servidor de WAP adyacente. Además, las capacidades de red de Bluetooth
dan a un cliente WAP posibilidades únicas en cuanto a movilidad
comparado con otros portadores WAP. Un ejemplo de WAP sobre Bluetooth
sería un almacén que transmite ofertas especiales a un cliente WAP cuando
éste entra en el rango de cobertura.
� Protocolo OBEX. OBEX es un protocolo opcional de nivel de aplicación
diseñado para permitir a las unidades Bluetooth soportar comunicación

infrarroja para intercambiar una gran variedad de datos y comandos. Éste
usa un modelo cliente-servidor y es independiente del mecanismo de
transporte y del API (Application Program Interface) de transporte. OBEX
usa RFCOMM como principal capa de transporte.
La Figura 1-2 muestra una comparación del stack Bluetooth con el modelo de
referencia estándar Open Systems Interconect, OSI, para stacks de protocolo
de comunicaciones. A pesar de que Bluetooth no concuerda exactamente con el
modelo, esta comparación es muy útil para relacionar las diferentes partes del
stack Bluetooth con las capas del modelo OSI. Dado que el modelo de referencia
es un stack ideal y bien particionado, la comparación sirve para resaltar la división
de funciones en el stack Bluetooth.
Figura 1-2. Modelo de referencia OSI y Bluetooth

1.1 BANDA BASE
1.1.1 Descripción general. Bluetooth soporta un canal de datos asíncrono de
hasta tres canales de voz simultáneos. El canal asíncrono soporta comunicación
simétrica y asimétrica. En la comunicación asimétrica pueden ser enviados 723.3
kb/s desde el servidor y 57.6 kb/s hacia el servidor, mientras que en la
comunicación simétrica pueden ser enviados 433 kb/s en ambas direcciones.
Bluetooth brinda conexión punto-a-punto o conexión punto-a-multipunto. Dos o
más unidades compartiendo el mismo canal forman una piconet. Cada piconet
debe tener un maestro y puede tener hasta siete esclavos activos, además
pueden haber muchos más esclavos en estado parked. Estos esclavos no están
activos en el canal sin embargo están sincronizados con el maestro con el fin de
asegurar una rápida iniciación de comunicación. La interconexión de varias
piconets forma una scatternet. Información más detallada se encuentra en la
especificación Bluetooth [3]. En la Figura 1-3 se puede observar una piconet
donde el PC actúa como maestro y los otros dispositivos son conectados como
esclavos.
Figura 1-3. Diagrama de una piconet.

1.1.2 Canal físico. El canal físico contiene 79 frecuencias de radio diferentes, las
cuales son accedidas de acuerdo a una secuencia de saltos aleatoria. La rata de
saltos estándar es de 1600 saltos/s. El canal está dividido en timeslots (ranuras
de tiempo), cada slot (ranura) corresponde a una frecuencia de salto y tiene una
longitud de 625 us. Cada secuencia de salto en una piconet está determinada por
la dirección del maestro de la piconet. Todos los dispositivos conectados a la
piconet están sincronizados con el canal en salto y tiempo. En una transmisión,
cada paquete debe estar alineado con el inicio de un slot y puede tener una
duración de hasta cinco timeslots. Durante la transmisión de un paquete la
frecuencia es fija. Para evitar fallas en la transmisión, el maestro inicia enviando
en los timeslots pares y los esclavos en los timeslots impares [3]. En la Figura 1-
4 se puede observar este esquema de transmisión.
Figura 1-4. Transmisión en una piconet.
1.1.3 Enlace físico. La comunicación sobre Bluetooth es perfecta para enlaces
SCO o enlaces ACL. El enlace SCO es una conexión simétrica punto-a-punto
entre el maestro y un esclavo específico. Para lograr la comunicación, el enlace
SCO reserva slots en intervalos regulares en la iniciación, por esto el enlace

puede ser considerado como una conexión de conmutación de circuitos. El enlace
ACL es un enlace punto-a-multipunto entre el maestro y uno o más esclavos
activos en la piconet. Este enlace de comunicación es un tipo de conexión de
conmutación de paquetes. Todos los paquetes son retransmitidos para asegurar la
integridad de los datos. El maestro puede enviar mensajes broadcast (de
difusión) a todos los esclavos conectados dejando vacía la dirección del paquete,
así todos los esclavos leerán el paquete [3].
1.1.4 Paquetes. Los datos enviados sobre el canal de la piconet son convertidos
en paquetes, éstos son enviados y el receptor los recibe iniciando por el bit menos
significativo. Como se observa en la Figura 1-5, el formato de paquete general
consta de tres campos: código de acceso, cabecera y carga útil [3].
Figura 1-5. Formato de paquete general
• Código de acceso. Es usado para sincronización e identificación. Todos los
paquetes comunes que son enviados sobre el canal de la piconet están
precedidos del mismo código de acceso al canal. Existen tres tipos diferentes de
código de acceso:
� Código de acceso al canal - Para identificar los paquetes sobre el canal
de la piconet.

� Código de acceso de dispositivo – Para procedimientos de señalización
especiales, paging (servicio para transferencia de señalización o
información en un sentido), entre otros.
� Código de Acceso de Búsqueda (IAC) – llamado IAC general cuando se
quiere descubrir a otras unidades Bluetooth dentro del rango, o IAC
dedicado cuando se desea descubrir unidades de un tipo específico.
• Cabecera de paquete. Como se observa en la Figura 1-6, la cabecera de
paquete consta de seis campos:
� Dirección – Una dirección de dispositivo para distinguirlo de los demás
dispositivos activos en la piconet.
� Tipo – Define qué tipo de paquete es enviado.
� Flujo – El bit de control de flujo es usado para notificar al emisor cuándo el
buffer del receptor está lleno.
� ARQN – Acknowledge Receive Data o reconocimiento de datos recibidos.
� SEQN – Sequential Numbering o numeración secuencial para ordenar los
datos sobre el canal.
� HEC – Chequeo de redundancia cíclica de cabecera.

Figura 1-6. Formato de cabecera de paquete
• Carga útil. La carga útil de un paquete puede ser dividida en dos campos:
� Campo de Voz – Consta de datos de voz de longitud fija y existe en
paquetes de alta calidad de voz y paquetes combinados de datos-voz. No
es necesaria ninguna cabecera de carga útil.
� Campo de Datos – Consta de tres partes, cabecera de carga útil, datos de
carga útil, y código CRC.
1.1.5 Corrección de errores. En una comunicación Bluetooth existen varios
esquemas diferentes de corrección de errores [3]:
• En la cabecera, cada bit es repetido tres veces.
• En la carga útil se usa un esquema de código Hamming. Los bits de
información son agrupados en secuencias de 10 bits, éstos son enviados
como 15 bits y el algoritmo corrige todos los errores de un bit y detecta los
errores de dos bits.
• Para garantizar una recepción correcta, todos los paquetes de datos son
retransmitidos hasta que el emisor reciba una confirmación. La confirmación
es enviada en la cabecera de los paquetes retornados.

• Los paquetes broadcast son paquetes transmitidos desde el maestro a
todos los esclavos. No hay posibilidad de usar confirmación para esta
comunicación, sin embargo, para incrementar la posibilidad de recibir
correctamente un paquete, cada bit en el paquete es repetido un número
fijo de veces.
• El chequeo de redundancia cíclica (CRC) se usa para detectar errores en la
cabecera. La suma de comprobación CRC está contenida en el campo HEC
de la cabecera de paquete. Los chequeos de redundancia cíclica también
se aplican sobre la carga útil en la mayoría de los paquetes.
• Para asegurar que no desaparezcan paquetes completos, Bluetooth usa
números de secuencia. Actualmente sólo se usa un número de secuencia
de un bit.
1.1.6 Transmisión/Recepción. Como se mencionó antes, el maestro de la
piconet empieza enviando en timeslots pares y el esclavo en los impares.
Solamente el último esclavo direccionado está autorizado para enviar en el
timeslot de los esclavos. Esto no causa problemas ya que el maestro siempre
está inicializando todas las conexiones y transmisiones nuevas. Cada esclavo
espera las oportunidades de conexión dadas por el maestro. Los paquetes pueden
ser más grandes que un timeslot, debido a esto el maestro puede continuar
enviando en los timeslots impares y viceversa. El sistema de reloj del maestro
sincroniza a toda la piconet. El maestro nunca ajusta su sistema de reloj durante la
existencia de una piconet, son los esclavos quienes adaptan sus relojes con un
offset de tiempo con el fin de igualarse con el reloj del maestro. Este offset es
actualizado cada vez que es recibido un paquete desde el maestro.

1.1.7 Control de Canal. El control de canal describe cómo se establece el canal
de una piconet y cómo las unidades pueden ser adicionadas o liberadas en la
piconet. La dirección del maestro determina la secuencia de saltos y el código de
acceso al canal. La fase de la piconet está determinada por el sistema de reloj del
maestro. Por definición, la unidad Bluetooth que inicia la conexión representa al
maestro.
En Bluetooth, la capa de control de enlace se divide en dos estados principales:
standby y conexión. Además existen siete sub-estados: page, page scan,
inquiry (búsqueda), inquiry scan, respuesta de maestro, respuesta de esclavo y
respuesta a inquiry. Los sub-estados son usados para agregar nuevos esclavos a
una piconet [3]. Para moverse de un estado a otro se usan comandos de capas
más altas o señales internas.
En Bluetooth se define un procedimiento de búsqueda que se usa en aplicaciones
donde la dirección del dispositivo de destino es desconocida para la fuente. Esto
puede ser usado para descubrir qué otras unidades Bluetooth están dentro del
rango. Durante un sub-estado de inquiry o búsqueda, la unidad de
descubrimiento recoge la dirección del dispositivo y el reloj de todas las unidades
que respondan al mensaje de búsqueda, entonces la unidad puede iniciar una
conexión con alguna de las unidades descubiertas. El mensaje de búsqueda
difundido por la fuente no contiene información de ella, sin embargo, puede indicar
qué clase de dispositivos deberían responder. Una unidad que permita ser
descubierta, regularmente entra en un sub-estado de inquiry scan para responder
a los mensajes de búsqueda.

Existen dos formas de detectar otras unidades. La primera, detecta todas las otras
unidades en el rango de cobertura, y la segunda, detecta un tipo específico de
unidades. Los esclavos que se encuentran en el sub-estado de page scan,
escuchan esperando su propio código de acceso de dispositivo. El maestro en el
sub-estado page activa y conectan a un esclavo. El maestro trata de capturar al
esclavo transmitiendo repetidamente el código de acceso de dispositivo en
diferentes canales de salto. Debido a que los relojes del maestro y del esclavo no
están sincronizados, el maestro no sabe exactamente cuándo y en qué frecuencia
de salto se activará el esclavo.
Después de haber recibido su propio código de acceso de dispositivo, el esclavo
transmite un mensaje de respuesta. Este mensaje de respuesta es simplemente el
código de acceso de dispositivo del esclavo. Cuando el maestro ha recibido este
paquete, envía un paquete de control con información acerca de su reloj,
dirección, clase de dispositivo, etc... El esclavo responde con un nuevo mensaje
donde envía su dirección. Si el maestro no obtiene esta respuesta en un
determinado tiempo, él reenvía el paquete de control. Si el esclavo excede el
tiempo de espera, entonces retorna al sub-estado de page scan. Si es el maestro
quien lo excede, entonces retorna al sub-estado de page e informa a las capas
superiores.
Cuando se establece la conexión, la comunicación inicia con un paquete de
sondeo desde el maestro hacia el esclavo. Como respuesta se envía un nuevo
paquete de sondeo y de esta forma se verifica que la secuencia de salto y la
sincronización sean correctas. La Figura 1-7 muestra la inicialización de la
comunicación sobre el nivel banda base.

Cada transceiver (receptor-transmisor) Bluetooth tiene una única dirección de
dispositivo de 48 bits asignada, la cual está dividida en tres campos: campo LAP,
campo UAP y campo NAP [3]. Los campos LAP y UAP forman la parte significativa
del código de acceso. En la Figura 1-8 se puede observar el formato de la
dirección para un dispositivo Bluetooth. La dirección del dispositivo es conocida
públicamente y puede ser obtenida a través de una rutina inquiry.
Figura 1-7. Iniciación de comunicación sobre el nivel banda base
Figura 1-8. Dirección de dispositivo Bluetooth

1.1.8 Seguridad en Bluetooth. Con el fin de brindar protección y confidencialidad
a la información, el sistema debe ofrecer medidas de seguridad en las dos capas,
la de aplicación y de enlace. Todas las unidades Bluetooth tienen implementadas
las mismas rutinas de autenticación y encriptación. En la capa de enlace, estas
rutinas constan de cuatro entidades diferentes: una única dirección pública, dos
llaves secretas y un número aleatorio el cual es diferente para cada transacción.
Solamente es encriptada la carga útil. El código de acceso y la cabecera de
paquete nunca son encriptados.
Cada tipo de unidad Bluetooth tiene una rutina de autenticación común. El maestro
genera un número aleatorio y lo envía al esclavo, el esclavo usa este número y su
propia identidad para calcular el número de autenticación. Luego, este número es
enviado al maestro quien hace el mismo cálculo. Si los dos números generados
son iguales entonces la autenticación es concedida.
La encriptación, frecuentemente está restringida por leyes de varios países. Para
evitar estas limitaciones, en Bluetooth la llave de encriptación no es estática, ésta
es deducida de la llave de autenticación cada vez que se activa la encriptación [3].
1.2 PROTOCOLO DE GESTIÓN DE ENLACE (LMP)
En el protocolo de gestión de enlace, LMP, se usan mensajes asociados con el
establecimiento, seguridad y control. Los mensajes son enviados en la carga útil y
no en los mensajes de datos de L2CAP. Los mensajes LMP son separados de los
demás por medio de un valor reservado en uno de los campos de la cabecera de
carga útil. Todos los mensajes LMP son extraídos e interpretados por la capa LMP
del receptor, esto significa que ningún mensaje es enviado a capas superiores.
Los mensajes LMP tienen mayor prioridad que los datos de usuario, esto significa
que si la gestión de enlace necesita enviar un mensaje, éste no debe ser retrasado
por otro tráfico. Solamente las retransmisiones de los paquetes del nivel de banda

ase pueden retrasar los mensajes LMP. Además, éstos no necesitan rutinas de
reconocimiento ya que la capa banda base asegura un enlace confiable [3]. El
protocolo de gestión enlace soporta mensajes para:
• Autenticación
• Paridad
• Encriptación
• Temporización y sincronización
• Versión y características
• Switch para desempeño como maestro o esclavo dependiendo de si el
dispositivo es quien inicia (maestro) o no (esclavo) el enlace con otro
dispositivo.
• Petición de nombre
• Desconexión
• Modo hold: el maestro ordena al esclavo entrar en este estado para ahorro
de potencia.
• Modo sniff: para envío de mensajes en timeslots específicos.
• Modo park: para que el esclavo permanezca inactivo pero sincronizado en
la piconet.
• Enlaces SCO
• Control de paquetes multi-slot
• Supervisión de enlace
1.2.1 Establecimiento de conexión. Después del procedimiento paging, el
maestro debe encuestar al esclavo enviando paquetes de sondeo. El otro lado
recibe este mensaje y lo acepta o rechaza, si es aceptado, la comunicación
incluyendo las capas superiores están disponibles (ver Figura 1-9).

Figura 1-9. Establecimiento de la conexión
1.3 INTERFAZ DEL CONTROLADOR DE HOST (HCI)
La HCI proporciona una interfaz de comando al controlador banda base y a la
gestión de enlace, además de acceso al hardware y a los registros de control. Esta
interfaz brinda un método estándar para acceder a los recursos de banda base
Bluetooth [3].
1.3.1 Capas mas bajas del stack Bluetooth. A continuación se hace una breve
descripción de las capas más bajas del stack de software y hardware Bluetooth.
La Figura 1-10 da una idea de estas capas.

Figura 1-10. Diagrama general de las capas más bajas
El firmware HCI implementa los comandos HCI para el hardware a través del
acceso de comandos banda base, comandos de la gestión de enlace, hardware de
registros de estado, registros de control y registros de eventos. La Figura 1-11
muestra el recorrido de un dato transferido de un dispositivo a otro. El driver HCI
(en el host) intercambia datos y comandos con el firmware HCI (en el hardware).
El driver de la capa de transporte, por ejemplo un bus físico, brinda a las dos
capas HCI la posibilidad de intercambiar información.

Figura 1-11. Diagrama general end to end de las capas de software más bajas
1.3.2 Posibles arquitecturas de bus físico. Los dispositivos Bluetooth tienen
varias interfaces de bus físicas que pueden ser usadas para conectar el hardware.
Estos buses pueden tener diferentes arquitecturas y parámetros. El controlador de
host soporta tres arquitecturas de bus físico, USB, UART y PC Card. Todas ellas
pueden manejar varios canales lógicos sobre el mismo canal físico simple (a
través de endpoints), por lo tanto los canales de control, datos y voz no requieren
alguna interfaz física adicional.
El objetivo principal de la capa de transporte del controlador de host es la
transparencia entre el driver del controlador de host y el controlador de host.

1.4 PROTOCOLO DE CONTROL Y ADAPTACIÓN DE ENLACE
LÓGICO (L2CAP)
L2CAP se encuentra sobre el protocolo de gestión de enlace (LMP) y reside en la
capa de enlace de datos. L2CAP permite a protocolos de niveles superiores y a
aplicaciones la transmisión y recepción de paquetes de datos L2CAP de hasta 64
kilobytes, con capacidad de multiplexación de protocolo, operación de
segmentación y reensamble, y abstracción de grupos. Para cumplir sus funciones,
L2CAP espera que la banda base suministre paquetes de datos en full duplex,
que realice el chequeo de integridad de los datos y que reenvíe los datos hasta
que hayan sido reconocidos satisfactoriamente. Las capas superiores que se
comunican con L2CAP son por ejemplo el protocolo de descubrimiento de servicio
(SDP), el RFCOMM y el control de telefonía (TCS) [3].
1.4.1 Canales. L2CAP está basado en el concepto de canales. Se asocia un
identificador de canal, CID, a cada uno de los endpoints de un canal L2CAP. Los
CIDs están divididos en dos grupos, uno con identificadores reservados para
funciones L2CAP y otro con identificadores libres para implementaciones
particulares. Los canales de datos orientados a la conexión representan una
conexión entre dos dispositivos, donde un CID identifica cada endpoint del canal.
Los canales no orientados a la conexión limitan el flujo de datos a una sola
dirección. La señalización de canal es un ejemplo de un canal reservado. Este
canal es usado para crear y establecer canales de datos orientados a la conexión
y para negociar cambios en las características de esos canales.
1.4.2 Operaciones entre Capas. Las implementaciones L2CAP deben transferir
datos entre protocolos de capas superiores e inferiores. Cada implementación
debe soportar un grupo de comandos de señalización, además, debe ser capaz de

aceptar ciertos tipos de eventos de capas inferiores y generar eventos para capas
superiores. En la Figura 1-12 se muestra esta arquitectura.
Figura 1-12. Arquitectura L2CAP
1.4.3 Segmentación y Reensamblado. Los paquetes de datos definidos por el
protocolo banda base están limitados en tamaño. Los paquetes L2CAP grandes
deben ser segmentados en varios paquetes banda base más pequeños antes de
transmitirse y luego deben ser enviados a la gestión de enlace. En el receptor los
pequeños paquetes recibidos de la banda base son reensamblados en paquetes
L2CAP más grandes. Varios paquetes banda base recibidos pueden ser
reensamblados en un solo paquete L2CAP seguido de un simple chequeo de
integridad. La segmentación y reensamblado, SAR, funcionalmente es
absolutamente necesaria para soportar protocolos usando paquetes más grandes
que los soportados por la banda base. La Figura 1-13 muestra la segmentación
L2CAP.

Figura 1-13. Segmentación L2CAP
1.4.4 Eventos. Todos los mensajes y timeouts que entran en la capa L2CAP,
son llamados eventos. Los eventos se encuentran divididos en cinco categorías:
indicaciones y confirmaciones de capas inferiores, peticiones de señal y
respuestas de capas L2CAP, datos de capas L2CAP, peticiones y respuestas de
capas superiores, y eventos causados por expiraciones de tiempo.
1.4.5 Acciones. Todos los mensajes y timeouts enviados desde la capa L2CAP
son llamados acciones (en el lado del receptor estas acciones son llamadas
eventos). Las acciones se encuentran divididas en cinco categorías: peticiones y
respuestas a capas inferiores, peticiones y respuestas a capas L2CAP, datos a
capas L2CAP, indicaciones a capas superiores, y configuración de timers.
1.4.6 Formato del paquete de datos. L2CAP está basado en paquetes pero
sigue un modelo de comunicación basado en canales. Un canal representa un
flujo de datos entre entidades L2CAP en dispositivos remotos. Los canales pueden
ser o no orientados a la conexión. Como se puede observar en la Figura 1-14, los
paquetes de canal orientado a la conexión están divididos en tres campos:
longitud de la información, identificador de canal, e información.

Figura 1-14. Paquete L2CAP
Los paquetes de canal de datos no orientados a la conexión son iguales a los
paquetes orientados a la conexión pero adicionalmente incluyen un campo con
información multiplexada de protocolo y servicio.
1.4.7 Calidad de servicio (QoS). La capa L2CAP transporta la información de
calidad de servicio a través de los canales y brinda control de admisión para evitar
que canales adicionales violen contratos de calidad de servicio existentes.
Algunos esclavos pueden requerir un alto rendimiento o una respuesta rápida.
Antes de que un esclavo con grandes peticiones sea conectado a una piconet, el
esclavo trata de obtener una garantía a sus demandas. Puede solicitar una
determinada rata de transmisión, tamaño del buffer de tráfico, ancho de banda,
tiempo de recuperación de datos, etc. Por lo tanto, antes de que el maestro
conecte a un nuevo esclavo o actualice la configuración de calidad, debe chequear
si posee timeslots y otros recursos libres.

1.5 PROTOCOLO DE DESCUBRIMIENTO DE SERVICIO (SDP)
El protocolo de descubrimiento de servicio, SDP, brinda a las aplicaciones
recursos para descubrir qué servicios están disponibles y determinar las
características de dichos servicios.
1.5.1 Descripción General. Un servicio es una entidad que puede brindar
información, ejecutar una acción o controlar un recurso a nombre de otra entidad.
El SDP ofrece a los clientes la facilidad de averiguar sobre servicios que sean
requeridos, basándose en la clase de servicio o propiedades específicas de estos
servicios. Para hacer más fácil la búsqueda, el SDP la habilita sin un previo
conocimiento de las características específicas de los servicios. Las unidades
Bluetooth que usan el SDP pueden ser vistas como un servidor y un cliente. El
servidor posee los servicios y el cliente es quien desea acceder a ellos. En el SDP
esto es posible ya que el cliente envía una petición al servidor y el servidor
responde con un mensaje. El SDP solamente soporta el descubrimiento del
servicio, no la llamada del servicio [3].
1.5.2 Registros de servicio. Los registros de servicio contienen propiedades
que describen un servicio determinado. Cada propiedad de un registro de servicio
consta de dos partes, un identificador de propiedad y un valor de propiedad. El
identificador de propiedad es un número único de 16 bits que distingue cada
propiedad de servicio de otro dentro de un registro. El valor de propiedad es un
campo de longitud variable que contiene la información.
1.5.3 El protocolo. El protocolo de descubrimiento de servicio (SDP) usa un
modelo petición/respuesta. En la Figura 1-15 se muestra el procedimiento SDP.
Note que las flechas no continuas no forman parte de éste.

• Petición de búsqueda de servicio: se genera por el cliente para localizar
registros de servicio que concuerden con un patrón de búsqueda dado
como parámetro. Aquí el servidor examina los registros en su base de datos
y responde con una respuesta a búsqueda de servicio.
• Respuesta a búsqueda de servicio: se genera por el servidor después de
recibir una petición de búsqueda de servicio válida.
• Petición de propiedad de servicio: una vez el cliente ya ha recibido los
servicios deseados, puede obtener mayor información de uno de ellos
dando como parámetros el registro de servicio y una lista de propiedades
deseadas.
• Respuesta a propiedad de servicio: El SDP genera una respuesta a una
petición de propiedad de servicio. Ésta contiene una lista de propiedades
del registro requerido.
• Petición de búsqueda y propiedad de servicio: se suministran un patrón
de servicio con servicios deseados y una lista de propiedades deseadas que
concuerden con la búsqueda.
• Respuesta de búsqueda y propiedad de servicio: como resultado se
puede obtener una lista de servicios que concuerden con un patrón dado y
las propiedades deseadas de estos servicios.

1.6 RFCOMM
El protocolo RFCOMM brinda emulación de puertos seriales sobre el protocolo
L2CAP. La capa RFCOMM es una simple capa de transporte provista
adicionalmente de emulación de circuitos de puerto serial RS-232. El protocolo
RFCOMM soporta hasta 60 puertos emulados simultáneamente. Dos unidades
Bluetooth que usen RFCOMM en su comunicación pueden abrir varios puertos
seriales emulados, los cuales son multiplexados entre sí. La Figura 1-15 muestra
el esquema de emulación para varios puertos seriales.
Figura 1-15. Varios puertos seriales emulados mediante RFCOMM
Muchas aplicaciones hacen uso de puertos seriales. El RFCOMM está orientado a
hacer más flexibles estos dispositivos, soportando fácil adaptación de
comunicación Bluetooth. Un ejemplo de una aplicación de comunicación serial es
el protocolo punto-a-punto (PPP). El RFCOMM tiene construido un esquema para
emulación de null modem y usa a L2CAP para cumplir con el control de flujo
requerido por alguna aplicación [3].

1.7 PERFILES BLUETOOTH
El estándar Bluetooth fue creado para ser usado por un gran número de
fabricantes e implementado en áreas ilimitadas. Para asegurar que todos los
dispositivos que usen Bluetooth sean compatibles entre sí son necesarios
esquemas estándar de comunicación en las principales áreas. Para evitar
diferentes interpretaciones del estándar Bluetooth acerca de cómo un tipo
específico de aplicación debería ser implementado, el Bluetooth Special Interest
Group (SIG), ha definido modelos de usuario y perfiles de protocolo. Un perfil
define una selección de mensajes y procedimientos de las especificaciones
Bluetooth y ofrece una descripción clara de la interfaz de aire para servicios
específicos. Un perfil puede ser descrito como una “rebanada” completa del stack
de protocolo.
Existen cuatro perfiles generales definidos, en los cuales están basados
directamente algunos de los modelos de usuario más importantes y sus perfiles.
Estos cuatro modelos son Perfil Genérico de Acceso (GAP), Perfil de Puerto
Serial, Perfil de Aplicación de Descubrimiento de Servicio (SDAP) y Perfil Genérico
de Intercambio de Objetos (GOEP). A continuación se hace una breve descripción
de estos y algunos otros perfiles Bluetooth [4]. La Figura 1-16 muestra el esquema
de los perfiles Bluetooth. En ella se puede observar la jerarquía de los perfiles,
como por ejemplo que todos los perfiles están contenidos en el Perfil Genérico de
Acceso (GAP).

Figura 1.16. Los Perfiles Bluetooth
1.7.1 Perfil Genérico de Acceso (GAP). Este perfil define los procedimientos
generales para el descubrimiento y establecimiento de conexión entre dispositivos
Bluetooth. El GAP maneja el descubrimiento y establecimiento entre unidades que
no están conectadas y asegura que cualquier par de unidades Bluetooth, sin
importar su fabricante o aplicación, puedan intercambiar información a través de
Bluetooth para descubrir qué tipo de aplicaciones soportan las unidades.
1.7.2 Perfil de Puerto Serial. Este perfil define los requerimientos para
dispositivos Bluetooth, necesarios para establecer una conexión de cable serial
emulada usando RFCOMM entre dos dispositivos similares. Este perfil solamente
requiere soporte para paquetes de un slot. Esto significa que pueden ser usadas
ratas de datos de hasta 128 kbps. El soporte para ratas más altas es opcional.

RFCOMM es usado para transportar los datos de usuario, señales de control de
modem y comandos de configuración. El perfil de puerto serial es dependiente del
GAP.
1.7.3 Perfil de Aplicación de Descubrimiento de Servicio (SDAP). Este perfil
define los protocolos y procedimientos para una aplicación en un dispositivo
Bluetooth donde se desea descubrir y recuperar información relacionada con
servicios localizados en otros dispositivos. El SDAP es dependiente del GAP.
1.7.4 Perfil Genérico de Intercambio de Objetos (GOEP). Este perfil define
protocolos y procedimientos usados por aplicaciones para ofrecer características
de intercambio de objetos. Los usos pueden ser, por ejemplo, sincronización,
transferencia de archivos o modelo Object Push. Los dispositivos más comunes
que usan este modelo son agendas electrónicas, PDAs, teléfonos celulares y
teléfonos móviles. El GOEP es dependiente del perfil de puerto serial.
1.7.5 Perfil de Telefonía Inalámbrica. Este perfil define cómo un teléfono móvil
puede ser usado para acceder a un servicio de telefonía de red fija a través de una
estación base. Es usado para telefonía inalámbrica de hogares u oficinas
pequeñas. El perfil incluye llamadas a través de una estación base, haciendo
llamadas de intercomunicación directa entre dos terminales y accediendo
adicionalmente a redes externas. Es usado por dispositivos que implementan el
llamado “teléfono 3-en-1”.
1.7.6 Perfil de Intercomunicador. Este perfil define usos de teléfonos móviles
los cuales establecen enlaces de conversación directa entre dos dispositivos. El

enlace directo es establecido usando señalización de telefonía sobre Bluetooth.
Los teléfonos móviles que usan enlaces directos funcionan como walkie-talkies.
1.7.7 Perfil de Manos Libres. Este perfil define los requerimientos, para
dispositivos Bluetooth, necesarios para soportar el uso de manos libres. En este
caso el dispositivo puede ser usado como unidad de audio inalámbrico de
entrada/salida. El perfil soporta comunicación segura y no segura.
1.7.8 Perfil Dial-up Networking. Este perfil define los protocolos y
procedimientos que deben ser usados por dispositivos que implementen el uso del
modelo llamado Puente Internet. Este perfil es aplicado cuando un teléfono celular
o modem es usado como un modem inalámbrico.
1.7.9 Perfil de Fax. Este perfil define los protocolos y procedimientos que deben
ser usados por dispositivos que implementen el uso de fax. En el perfil un teléfono
celular puede ser usado como un fax inalámbrico.
1.7.10 Perfil de Acceso LAN. Este perfil define el acceso a una red de área local,
LAN, usando el protocolo punto-a-punto, PPP, sobre RFCOMM. PPP es
ampliamente usado para lograr acceder a redes soportando varios protocolos de
red. El perfil soporta acceso LAN para un dispositivo Bluetooth sencillo, acceso
LAN para varios dispositivos Bluetooth y PC-a-PC (usando interconexión PPP con
emulación de cable serial).

1.7.11 Perfil Object Push. Este perfil define protocolos y procedimientos usados
en el modelo object push. Este perfil usa el GOEP. En el modelo object push
hay procedimientos para introducir en el inbox, sacar e intercambiar objetos con
otro dispositivo Bluetooth.
1.7.12 Perfil de Transferencia de Archivos. Este perfil define protocolos y
procedimientos usados en el modelo de transferencia de archivos. El perfil usa el
GOEP. En el modelo de transferencia de archivos hay procedimientos para
chequear un grupo de objetos de otro dispositivo Bluetooth, transferir objetos entre
dos dispositivos y manipular objetos de otro dispositivo. Los objetos podrían ser
archivos o fólderes de un grupo de objetos tal como un sistema de archivos.
1.7.13 Perfil de Sincronización. Este perfil define protocolos y procedimientos
usados en el modelo de sincronización. Éste usa el GOEP. El modelo soporta
intercambios de información, por ejemplo para sincronizar calendarios de
diferentes dispositivos.

2. DESCRIPCIÓN DE HARDWARE Y PRODUCTOS
BLUETOOTH
Después de analizar y comprender la tecnología Bluetooth se procedió a hacer
una búsqueda de productos disponibles en el mercado con el fin de conocer las
diversas aplicaciones que se ofrecen y principalmente determinar qué producto
adquirir o implementar para el desarrollo de esta tesis. En este capítulo se
presenta una descripción detallada del hardware implementado y se hace una
breve descripción de los diferentes tipos de productos Bluetooth disponibles así
como el procedimiento mediante el cual se califica un producto como producto
Bluetooth.
2.1 TARJETAS BLUEBOARDUV
Uno de los puntos esenciales para el desarrollo de esta tesis fue la utilización de
hardware para la implementación. Después de conocer los diferentes tipos de
productos Bluetooth disponibles (ver sección 2.2), se hizo un análisis de las
mejores opciones teniendo en cuenta ventajas, desventajas, costo, accesibilidad,
etc. Para cumplir con el objetivo principal de este trabajo, es decir, la
implementación de una red Bluetooth, se decidió construir sistemas semiembebidos
Bluetooth utilizando módulos, antenas y demás dispositivos periféricos
necesarios. A las tarjetas construidas se les dieron los nombres de
BlueboardUV01 y BlueboardUV02. La diferencia principal entre los dos tipos de
tarjeta radica únicamente en el tipo de antena utilizado y por consiguiente los
requerimientos de antena tenidos en cuenta para cada una son diferentes. En la
Figura 2-1 se muestra el diagrama de bloques de las tarjetas BlueboardUV. En la
gráfica se pueden observar las principales partes que las conforman.

Figura 2-1. Diagrama de Bloques de las tarjetas BlueboardUV
Los bloques funcionales de las tarjetas son:
• Módulo Bluetooth: es el chip-multichip que tiene implementadas las capas
más bajas del stack y posee diferentes interfaces para lograr comunicación
de voz y datos. Es el bloque más importante del sistema.
• Antena: ya que el módulo no incluye una antena, éste es un dispositivo
externo necesario para lograr la comunicación Bluetooth. Es el dispositivo
con más requerimientos de diseño.

• Transceiver RS-232: necesario para convertir las señales RS-232 de una
fuente de menor a mayor valor de voltaje (de 3.0V a 5.5V).
• Regulación de voltaje: necesario para el suministro de potencia del módulo
y el transceiver RS-232. El voltaje regulado es de 3.3V.
2.1.1 Descripción de las tarjetas BlueboardUV. A continuación se presenta una
descripción general de las tarjetas, información más detallada se presenta en
secciones posteriores. Entre las principales características de las tarjetas
BlueboardUV están:
• Módulo de acuerdo a la versión 1.0b de Bluetooth
• Módulo removible usando el Carrier Socket de SUYIN para módulos Bluetooth
• Acceso a todas las señales del módulo
• Pin de encendido externo
• Salida RF de potencia clase 2 (0dBm-rango de 10m)
• LED de monitoreo para suministro de energía
• Tres interfaces para diversas aplicaciones;
UART para datos
PCM para voz
USB para datos
• Rata máxima de transmisión de datos sobre UART de 460,8 kbps
• Reset manual
• Capas inferiores del stack Bluetooth incluidas en el hardware, desde el HCI
hasta la capa de radio.
• Antena RangeStar 100929 ó 100930 incluida
• Operación Punto a Multi-Punto (dependiendo del módulo utilizado)

Las tarjetas BlueboardUV únicamente soportan comunicación de datos, sin
embargo poseen una interfaz PCM disponible para comunicación de voz. La
comunicación entre la tarjeta y el controlador de host se hace a través de la
interfaz USB o la interfaz UART/PCM. El módulo ROK101007/8 usado soporta
todos los perfiles definidos en la versión 1.0b de la especificación Bluetooth.
Las tarjetas BlueboardUV necesitan una alimentación de 5VDC que pueden
suministrarse a través del conector USB o por medio de un terminal macho
genérico. Poseen un convertidor DC/DC que proporciona la alimentación al
módulo Bluetooth Ericsson ROK101007/8. El diagrama esquemático de las
tarjetas se muestra en la Figura 2-2. Se pueden observar los dispositivos utilizados
para los diferentes bloques funcionales: módulo Ericsson ROK101007, antena
RangeStar 100929 ó 100930, transceiver Maxim MAX3232 y regulador de voltaje
National LP2987.
El voltaje regulado necesario para la alimentación del módulo y el transceiver RS-
232 es suministrado por el LP2987. Su circuito, tiene un pin de encendido externo
(ON/OFF), que permite habilitar el suministro de potencia a la tarjeta. Además,
para verificar el estado de la excitación, posee un LED de monitoreo (D1). El
voltaje regulado es de 3.3V. El módulo posee diferentes interfaces de
comunicación: USB, RS-232, PCM e I2C. Las señales RS-232 que salen del
módulo, antes de ir al conector macho RS232 son convertidas a un voltaje mayor
por medio del MAX3232. Al usar la interfaz UART el módulo funciona como un
Equipo de Comunicación de Datos (DCE), con una velocidad de 57,6 kbps por
defecto. La interfaz USB cumple con la especificación 1.1. Las señales USB, PCM
e I2C están conectadas directamente a su correspondiente conector macho
(CONECTOR_USB, PCM, I2C). La señal ANT del módulo está conectada
directamente al terminal de alimentación de la antena (RangeStar 100929/30).

Figura 2-2. Diagrama esquemático de las tarjetas BlueboardUV

En la Tabla 2-1 se presenta la lista de componentes de una tarjeta BlueboardUV
detallando las referencias dentro de la tarjeta y de fabricante para cada
componente.
Tabla 2-1. Lista de componentes para la tarjeta BlueboardUV
No Tipo de Tipo de Referencia de Cant. Referencia en Tarjeta
Dispositivo paquete Componente
(Ver Figuras 2-3 y 2-4)
1 IC, Módulo
ERICSSON
Sobre el soporte
Bluetooth
[5] ROK101007 / 8 1 CARRIER SOCKET
2 Soporte
SUYIN
Carrier socket [6] BT001A-30G2T 1 CARRIER SOCKET
3 IC, Regulador de
NATIONAL
Voltaje
M08A LP2987AIM 3.3V SMD 1
M08A
4 IC, Interfaz
MAXIM MAX3232
RS-232 SO16L(W) EEWE/CWE 3.3V SMD 1
MAX3232
5
RANGESTAR
Rangestar
Antena
[7] 100929 ó 100930 1 100929 ó 100930
6
C1206 Cond. 0,1uF/50V SMD
Capacitor 0,1uF 3x1,5x1mm Monolitico
5 C4, C5, C6, C7,C8
7
Cond. 0,47uF/50V 10%
Capacitor 0,47uF KEMET_C SMD Tantalio SPRAG 1
C2
8
KEMET_C Cond. 4.7uF/20V SMD
Capacitor 4.7uF 6032
Tantalio
2
C1, C3
9 Resistencia 100KΩ R1206 5% 1/8W SMD 1 R1
10 Resistencia 330KΩ R1206 5% 1/8W SMD 1 R2
11 Resistencia 220Ω R1206 5% 1/4W SMD 1 R3
12
LED uMiniatura 1,7mcd
Diodo LED SOT-23 LiteOn SMD
1
D1
13 Conector USB PN87520 CON-BERG 1 USB_CONNECTOR
14 Switch B3F-10XX Switch-omron 10-XX 1 S1
15 Jum 1X2 MA02-1 con-lstb 1 ON/OFF
16 Jum 2X2 MA02-2 con-lstb 1 I2C
17 Jum 5X2 MA05-2 con-lstb 2 PCM, RS232
Total de partes 23

Las Figuras 2-3 y 2-4 muestran diagramas del hardware de las tarjetas
BlueboardUV01 y BlueboardUV02 respectivamente. Las gráficas son una
representación detallada de las tarjetas. Cada dispositivo utilizado tiene asociada
una referencia, facilitando su localización física. El tamaño real de las tarjetas es
de 8,5 x 7,5 cm.
Figura 2-3. Diagrama del hardware de la tarjeta BlueboardUV01

Figura 2-4. Diagrama del hardware de la tarjeta BlueboardUV02
Con el fin de conocer y entender mejor el funcionamiento de las tarjetas
BlueboardUV, a continuación se hace una descripción detallada de los principales
dispositivos utilizados y los requerimientos que se debieron tener en cuenta para
la implementación de las tarjetas.

2.1.2 Descripción de componentes y requerimientos en las tarjetas
BlueboardUV.
2.1.2.1 Módulo Bluetooth Ericsson ROK101007/8. Para la implementación de
las tarjetas BlueboardUV01 y BlueboardUV02 se utilizaron los módulos de
Ericsson ROK101007 y ROK101008. Su escogencia se hizo teniendo en cuenta la
robustez y la compatibilidad con otros dispositivos. El ROK101007 se diferencia
del ROK101008 únicamente en que el primero soporta conexión punto a punto y
punto a multi-punto y el segundo únicamente conexión punto a punto, por esto de
aquí en adelante solamente se hace referencia al módulo ROK101007. A
continuación se presenta una descripción general del módulo. Mayor información
se encuentra en la Web [5].
Las principales ventajas del módulo Ericsson ROK101007 son:
• Pre-calificado con la especificación Bluetooth 1.0B
• Potencia de salida RF clase 2
• Aprobado por la FCC y la ETSI
• Rata máxima sobre UART de 460 kb/s
• Distintas interfaces: UART para datos, PCM para voz y USB para voz y datos.
• Interfaz I 2 C
• Cristal oscilador interno
• Firmware HCI incluido
• Blindado
El ROK101007 es un módulo de corto rango para implementaciones Bluetooth en
diferentes dispositivos electrónicos que soporta transmisiones de datos y voz. La
comunicación entre el módulo y el controlador de host se lleva a cabo a través de

una interfaz de alta velocidad USB acorde a las especificaciones USB 1.1 o a
través de una interfaz UART/PCM. Al utilizar la interfaz USB, el módulo funciona
como un dispositivo esclavo USB y por lo tanto no requiere recursos del PC. El
ROK101007 es un módulo Bluetooth Clase 2 (0dBm) y además soporta todos los
perfiles Bluetooth.
El ROK101007 es un chip multi-chip de 30 pines de 3.3 x 1.7cm
aproximadamente, que por su dimensión facilita implementaciones en dispositivos
portátiles y de tamaño reducido. El módulo consta de tres partes principales;
Controlador Banda Base, Memoria Flash y Radio. Los bloques operacionales del
ROK101007 los conforman los tres anteriores, más un bloque de Manejo de
Potencia y otro de Reloj.
� El Controlador Banda Base es un ARM7 que controla la operación del
radio transceiver a través de una interfaz USB o UART, y adicionalmente
tiene una interfaz de voz PCM y una interfaz I 2 C
� La Memoria Flash es usada con el Controlador Banda Base
� El Radio es implementado con el radio Ericsson PBA 913 01/2
� En el Manejo de Potencia se regula y filtra el voltaje de alimentación Vcc
que típicamente es de 3.3V
� El Reloj interno trabaja a 13MHz con una precisión en el oscilador de
cristal de 20ppm.
• Partes Hardware / Firmware del ROK101007. El módulo ROK101007 incluye
partes HW/FW del stack de protocolo Bluetooth. Las partes de HW incluidas son
el Radio y la Banda Base, y las de FW, las cuales residen en la Flash, son la
Interfaz del Controlador de Host, HCI, y el Manejador de Enlace, LM. En la Figura
2-5 se pueden observar las partes de HW/FW incluidas en el módulo.

Figura 2-5. HW/FW del módulo Ericsson ROK101007
Interfaz de Radio: el módulo es un dispositivo clase 2 con una salida máxima de
potencia de 4dBm. El rango nominal del módulo con una antena típica es de
hasta 10 m (a 0 dBm).
Banda Base: Se usa una estructura de red ad-hoc con un número máximo de
ocho unidades activas en una sola piconet.
• Interfaces HW del Módulo.
Interfaz USB: El módulo es un dispositivo USB de alta velocidad (12Mbps) que
tiene toda la funcionalidad de un esclavo USB y está de acuerdo con la
especificación USB 1.1 La transferencia de datos se hace a través de los puertos
bidireccionales D+ & D-, y adicionalmente se usan las líneas Wake_up y Detach.
En la Figura 2-6 se puede observar la configuración típica para una aplicación
USB.

Interfaz UART: esta interfaz es acorde al estándar industrial 16C450 y soporta las
siguientes ratas de bits: 300, 600, 900, 1200, 1800, 2400, 4800, 9600, 19200,
38400, 57600, 115200, 230400 y 460800 bits/s. Existen FIFOs de 128 bytes
asociadas con la UART. Para esta interfaz se tienen cuatro señales, TxD & RxD
se usan para flujo de datos, y RTS & CTS se usan para control de flujo. En la
Figura 2-7 se muestra la configuración típica para una aplicación UART o PCM.
Interfaz de voz PCM: la interfaz estándar PCM tiene una rata de muestreo de
8kHz (PCM_SYNC). El reloj PCM es variable entre 200kHz y 2MHz. Los datos
PCM pueden ser: PCM 13-16 bits, u-Law 8 bits ó A-Law 8 bits. En este caso se
tienen cuatro líneas de conexión PCM_IN, PCM_OUT, PCM_SYNC y PCM_CLK.
En la Figura 2-7 se puede observar la configuración típica para una aplicación
UART O PCM.
Interfaz I 2 C: En el módulo se encuentra disponible una interfaz I 2 C maestro.
Figura 2-6. Configuración Típica USB para el ROK101007

Figura 2-7. Configuración Típica UART o PCM para el ROK101007
2.1.2.2 Diseño de Antena. En cualquier sistema de comunicación inalámbrica, la
antena es un componente crítico cuya implementación influye significativamente
en el desempeño global del sistema. Esto se debe a que la antena es el elemento
que convierte las señales eléctricas conducidas por las pistas de la tarjeta de
circuito impreso (PCB) a señales que se propagan a través del espacio libre; por lo
tanto actúa como una impedancia y un dispositivo de conversión. No obstante la
antena normalmente es uno de los componentes más descuidados en un sistema
de comunicación inalámbrica.
• Principales parámetros de la Antena. Una antena se caracteriza por varios
parámetros relevantes que deben ser tenidos en cuenta para el diseño de un
sistema inalámbrico. Entre los más importantes están: la Frecuencia de
Operación, el Ancho de Banda, la Impedancia de Entrada, la Ganancia de Antena,
la Eficiencia de Radiación y el Tamaño de la Antena.

• Banda de frecuencia Bluetooth. A pesar de que algunos países han
especificado diferentes rangos de frecuencia para la banda “2.4 GHz ISM”
(Bluetooth), todos ellos están contenidos dentro del rango de frecuencia de 2.400-
2.497GHz. Por consiguiente para una implementación Bluetooth se debe utilizar
una antena que trabaje sobre todo este rango, para asegurar la máxima
compatibilidad del dispositivo y el uso de los canales disponibles.
• Ganancia de Antena. Tal como los rayos de sol son menos intensos a
mayores distancias, la potencia de todas las antenas decrece con el incremento
de la distancia. Además, la rata a la cual esta potencia decrementa es siempre la
misma, por lo tanto, la única forma de incrementar la potencia recibida en un lugar
apartado es aumentando la potencia de RF (Radio Frecuencia) en esa dirección.
Es aquí donde la ganancia de la antena es útil; esta debe ser tenida en cuenta, ya
que tiene un impacto directo en el desempeño y el rango máximo de un dispositivo
Bluetooth, además de ser uno de los únicos elementos controlables en la
trayectoria de la señal desde el transmisor hasta el receptor. El uso de antenas
con baja ganancia limita ampliamente la máxima distancia de alcance de una
señal Bluetooth. La unidad de medida para la ganancia de una antena está dada
usualmente en dBi, que es una sigla para “decibeles relativos a una fuente
isotrópica.”
• El Plano de Tierra. La mayoría de antenas inalámbricas requieren un Plano
de Tierra sobre el PCB. Su longitud debe ser aproximadamente un cuarto (¼) de
la longitud de onda de operación. Así, si la frecuencia de trabajo en Bluetooth es
de 2425 MHz, la longitud de onda (λ) es 124 mm y de esta manera la mínima
longitud del Plano de Tierra sería de 31 mm. A medida que la longitud del Plano
de Tierra se hace mayor a ¼ de la longitud de onda, el patrón de radiación se
hace cada vez más multi-lóbulo. Esto generalmente no afecta a la mayoría de

aplicaciones. Sin embargo, si el Plano de Tierra es significativamente menor a ¼
de la longitud de onda, la sintonización se hace cada vez más difícil y el
desempeño global disminuye. Esto es común en todas las antenas, por ejemplo,
las antenas de los beepers son muy ineficientes debido a su tamaño, el cual es
significativamente más pequeño que su longitud de onda de operación. En la
Figura 2-8 se observa el comportamiento de la Ganancia de Antena con respecto
al tamaño del Plano de Tierra.
Figura 2-8. Ganancia Pico vs. Longitud PCB
Fuente: RangeStar Wireless, Inc.
Según la Figura 2-8, para lograr un óptimo desempeño de la antena se debe tratar
de obtener un plano de tierra de 0.33 veces la longitud de onda de operación. En
las tarjetas BlueboardUV el plano de tierra se implementó por las dos caras del
PCB y se interconectaron los dos planos por medio de vías localizadas en toda la
superficie de las tarjetas con el fin de evitar diferencias de potencial mínimas que
puedan afectar el desempeño del sistema. En las Figuras 2-9 a 2-12 se pueden
observar el plano de tierra y las vías implementadas en las tarjetas. Éstas

muestran el ruteo por ambas caras de la Tarjeta de Circuito Impreso (PCB) para
las tarjetas BlueboardUV. Información más detallada se puede encontrar en el CD-
ROM anexo con este documento.
Figura 2-9. Ruteo de la parte superior de la tarjeta BlueboardUV01

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

Figura 2-12. Ruteo de la parte inferior de la tarjeta BlueboardUV03
• Efectos de localización de la antena. La localización de la antena sobre el
PCB afecta el desempeño del sistema en mayor proporción que el tamaño del
Plano de Tierra. En general, las esquinas son el mejor lugar de montaje. La
localización de la antena no debe ser escogida solamente por su patrón de
radiación, también se debe tener en cuenta que la antena no perturbe otras partes
del sistema y que ningún disturbio sea introducido al sistema Bluetooth a través de
la antena.
2.1.2.3 Antenas RangeStar. En este proyecto se utilizaron las antenas
RangeStar 100929 y 100930 [7]. A continuación se presentan sus principales

características además de una descripción de los requerimientos tenidos en
cuenta para la construcción de las tarjetas BlueboardUV.
• Diseño del PCB. Las antenas de RangeStar están diseñadas para ser
montadas al final de un PCB, así se utiliza la máxima longitud del Plano de Tierra
para emitir las ondas electromagnéticas y a pesar de que haya una pequeña
diferencia en el desempeño global, estas antenas se deben montar junto al
dispositivo que emite mayor energía.
Estas antenas tienen varios terminales, cada uno de ellos con una función
diferente. Un terminal sirve como alimentación de la señal RF mientras que los
demás pueden servir como conexión a tierra, como conexión de soporte o las dos
(conexión a tierra y soporte). El pad del terminal de alimentación se debe conectar
a una línea de transmisión de 50 Ohm y los pads de los terminales de conexión a
tierra, se deben conectar eléctricamente al Plano de Tierra del PCB. Cada antena
tiene una distancia de aislamiento recomendada, que corresponde a la mínima
distancia permitida entre la antena y cualquier conductor sobre el PCB. Si algún
conductor está más cerca que la distancia de aislamiento especificada el desfase
de capacitancia generado des-sintoniza la antena.
Ya que Bluetooth implica el uso de RF y además la frecuencia de operación está
en la banda de los 2.4 GHz, las precauciones que se deben tener en cuenta al
trabajar en este rango de frecuencia son severas e indispensables. Las
especificaciones del fabricante se deben cumplir con la mayor precisión posible y
el sistema no se debe encerrar dentro de una estructura metálica para evitar
efectos similares al de una Jaula de Faraday, que puede generar un bajo
desempeño.

• Antenas RangeStar 100929 y 100930. Las antenas RangeStar 100929 y
100930 se caracterizan por tener un buen ancho de banda, alta ganancia en
tamaño reducido, son pequeñas, livianas y fáciles de usar. Las Figuras 2-13 y 2-14
muestran las antenas RangeStar 100929 y 100930 respectivamente, al igual que
el patrón de radiación para cada una de ellas. En la Tabla 2-2 se presentan las
principales características de cada una.
Figura 2-13. Antena RangeStar 100929
Figura 2-14. Antena RangeStar 100930

Tabla 2-2. Características de las antenas RangeStar 100929 y 100930
ANTENA RANGESTAR
CARACTERÍSTICAS 100929 100930
Aplicaciones
Rango de Frecuencia
(MHz)
Bluetooth, 802.11b
Teléfonos móviles, dispositivos portátiles, PDAs, aplicaciones
industriales, instrumentos.
2400 - 2483.5
Pico de Ganancia > 4.5dBi > 4 dBi
VSWR
< 2.0 : 1 < 2.5 : 1
Haz Omnidireccional Patrón Hemisférico
Impedancia del Punto
de Alimentación
50 Ohms
Tamaño 29.0 x 11.6 x 3.0 mm 16mm diam. X 6.0mm
Para el diseño del PCB en las tarjetas BlueboardUV se tuvieron en cuenta varios
requerimientos de antena tales como la distancia de aislamiento, el tamaño y
localización de los pads para cada terminal, el área clara alrededor de los pads, el
área libre de componentes, el área clara alrededor de la línea de alimentación de
la antena, entre otros [7]. Uno de los requerimientos más importantes es que la
distancia desde el pin de salida RF hasta la antena debe ser lo más corta posible.
Los requerimientos de antena son diferentes para cada tipo de antena y se
aplicaron con la mayor precisión posible. En la Figura 2-15 se pueden observar las
dos librerías creadas en el programa CAD para los dos tipos de antena utilizados.
En ella se pueden visualizar los diferentes requerimientos que se tuvieron en
cuenta y que son necesarios para cada una de las antenas.

Figura 2-15. Requerimientos para las antenas RangeStar 100929 y100930
2.1.2.4 Regulador de Voltaje National LP2987. Para la regulación de voltaje de
las tarjetas BlueboardUV se usó el regulador de voltaje National LP2987AIM 3.3.
Éste es un regulador de voltaje de 200mA de salida fija con un reset de retardo de
encendido implementado con un capacitor externo. El voltaje regulado necesario
en las tarjetas BlueboardUV es de 3.3V, con el cual se alimentan el módulo
Bluetooth y el MAX232. El regulador tiene una salida de precisión de 0.5%. La
Figura 2-16 muestra el diagrama de bloques para el LP2987. Para mayor
información se puede consultar la página web de National Semiconductors [8].

Figura 2-16. Diagrama de bloques del regulador de voltaje LP2987
Fuente: National Semiconductors
2.1.2.5 MAXIM MAX3232. El MAXIM MAX3232 es una interfaz de comunicación
con requerimientos de baja potencia. Este transceiver habilita el cambio en RS-
232 de una alimentación de 3.0V a una de 5.5V. Tiene 2 receptores y 2 drivers. El
MAX3232 solamente requiere cuatro pequeños capacitares externos de 0.1uF y es
garantizado para correr a una rata de datos de 120kbps (MAX3232) o 250kbps
(MAX3232E) manteniendo los niveles de salida RS-232. Para encontrar
información más detallada se puede consultar en la página web de MAXIM [9].
2.1.2.6 Soporte SUYIN BT001A-30G2T. Con el fin de hacer de las tarjetas
BlueboardUV sistemas más flexibles, se utilizó una base soporte para el módulo
de Ericsson ROK101007. El soporte es el Bluetooth Carrier Socket BT001A-
30G2T de SUYIN CONNECTOR [6]. Este soporte permite intercambiar módulos
sin necesidad de recurrir a desoldar las tarjetas. En la Figura 2-17 se puede

observar la librería del soporte que se implementó en el programa CAD para el
diseño de las tarjetas. Éste posee 30 pines de conexión al igual que el módulo de
Ericsson utilizado.
Figura 2-17. Bluetooth Carrier Socket SUYIN BT001A-30G2T
2.1.3 Fotografías de las tarjetas BlueboardUV. Las Figuras 2-18 a 2-21
muestran varias fotografías de las tarjetas BlueboardUV, en la Figura 2-20 se
puede observar la tarjeta BlueboardUV01 en funcionamiento, conectada a un PC
por medio de un cable USB.

Figura 2-18. Tarjeta BlueboardUV01
Figura 2-19. Módulo Bluetooth dentro del soporte en la tarjeta BlueboardUV01

Figura 2-20. Tarjeta BlueboardUV01 en funcionamiento
Figura 2-21. Tarjeta BlueboardUV02

2.2 PRODUCTOS BLUETOOTH
La oferta de productos Bluetooth en el mercado es muy amplia y variada. Existen
productos de muchos tipos y de diversos fabricantes. Entre los tipos de productos
más destacados están: partes para integrar sistemas Bluetooth, tales como
amplificadores, radio transceivers, controladores, antenas, módulos etc.;
productos embebidos tales como kits, herramientas de desarrollo, adaptadores
USB, tarjetas PC, tarjetas PCMCIA y productos específicos muy variados; y por
último, productos de software Bluetooth. En la Tabla 2-3 se nombra algunos de
ellos, sin embargo, se puede encontrar información más detallada de productos y
fabricantes en el CD-ROM anexo a este libro.
Tabla 2-3. Algunos productos Bluetooth disponibles en el mercado
TIPO DE
PRODUCTO
FABRICANTE REFERENCIA
MÓDULOS
KITS
MAS
INFO.
CSR BC01MOD2B [10]
BLUEFROG rbm3rc-r [11]
NATIONAL LMX982x [12]
ERICSSON ROK101007 [5]
ATMEL Blue Snake Kit AT76C551-BLSNK [13]
BLUEFROG Development System [11]
DIGIANSWER MkII Demo Card [14]
Application and Training Tool Kit [5]
TELECA Development Kit [5]
3COM PC Card y adaptador USB [15]
TARJETAS SMART Bluesapphire tarjeta PCMCIA [16]
SOFTWARE
TELECA
Core Bluetooth Software Stack,
Profiles, Bluetooth HCI Toolbox,
Bluetooth Log Analyzer
[5]

TIPO DE
PRODUCTO
OTROS
FABRICANTE REFERENCIA
ANOTO Bluetooth Pen
TELECA Solución de audífonos Bluetooth
MOTOROLA
Remote Speaker Microphone
HMN3158A
2.3 PROCEDIMIENTO DE CALIFICACIÓN BLUETOOTH
MAS
INFO.
El propósito de este sub-capítulo es brindar una descripción del procedimiento que
se debe seguir para calificar un producto como Producto Bluetooth. Con el
propósito de minimizar o eliminar problemas de interoperatividad el Bluetooth
Qualification Program (BQP) ha definido un grupo específico de procedimientos.
Este es un requerimiento necesario antes de que un producto pueda ser calificado
de acuerdo con Bluetooth. La calificación Bluetooth es el proceso mediante el cual
un fabricante demuestra conformidad con la especificación Bluetooth y el BQP es
la base que establece las reglas y procedimientos de calificación. El BQP fue
creado independientemente de algún tipo de aprobación administrativa obligatoria
de reglamentaciones nacionales o internacionales.
Un fabricante de productos con la tecnología inalámbrica Bluetooth debe
suscribirse al contrato de membresía del SIG Bluetooth. Cuando el producto
cumple con la especificación Bluetooth, es adicionado a la lista de productos
Bluetooth. Esto otorga a la Compañía Miembro una licencia que cubre los
derechos de patente de la propiedad intelectual de derechos de autor y le permite
usar la marca Bluetooth en productos y actividades de mercadeo de acuerdo con
el libro de la marca Bluetooth. Información más detallada acerca de la calificación
[17]
[5]
[18]

Bluetooth se puede encontrar en enlace Developer Information ->Qualification
Program de la página oficial de Bluetooth [19].
2.4 ANTENAS EN F INVERTIDA INTEGRADAS
Una buena posibilidad para la construcción de PCBs que impliquen el uso de
antenas, es el diseño de Antenas en F Invertida (IFAs). Estas antenas tienen una
estructura de bajo perfil, son livianas y fáciles de integrar en equipos de
comunicación personales. A pesar de que en esta tesis no se implementó una
antena de este tipo, la información que se describe a continuación acerca de este
tema puede resultar muy útil para posteriores proyectos.
Existen tres clases de IFAs: las IFAs con elementos convencionales, las antenas
en F invertida planares (PIFAs) y las Antenas en F Invertida Integradas (IIFAs).
Para hacer más compactas las IFAs, los elementos de la antena se pueden
imprimir en el plano superior del substrato del PCB, para formar una IIFA. Este tipo
de antenas ya se ha usado en aplicaciones Bluetooth [20]. Esto significa que al
diseñar un sistema inalámbrico, no se hace obligatoria la compra o adquisición de
una antena sino que se puede diseñar en el PCB. En el diseño de este tipo de
antenas se tienen en cuenta parámetros tales como el espesor, la constante
dieléctrica y la característica de impedancia del substrato, así como la separación
y el ancho de las líneas y por supuesto la frecuencia de operación. Se puede
conseguir información más detallada en distintas fuentes incluso en la web [20]
[21]. En la Figura 2-22 se observa un esbozo de una Antena en F Invertida
Integrada (IIFA).

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

3. SOFTWARE PARA EL HOST BLUETOOTH
El software para el host Bluetooth corresponde a las capas del stack de
protocolos y utilidades Bluetooth implementadas en software e instaladas en el
host. Un host puede ser cualquier sistema microprocesado programable (PCs,
teléfonos celulares, mouse, impresoras, teclados, sensores inalámbricos, etc.),
capaz de ejecutar las líneas de código correspondientes al stack de protocolos
para el host. En esta plataforma es necesario tener una interfaz UART o USB
para comunicar el host y el módulo Bluetooth.
Son muchos los stacks de protocolos Bluetooth disponibles para el host,
implementados en diversos lenguajes de programación y sobre distintas
plataformas, siendo también muchas las empresas interesadas en su desarrollo.
Independientemente de la plataforma o el lenguaje de programación, estos se
basan en el CORE [3] y los PROFILES [4] de la especificación del sistema
Bluetooth.

Figura 3-1. Modelo de implementación del protocolo Bluetooth, Host – Hardware
La Figura 3-1 muestra un modelo de implementación del stack de protocolos
Bluetooth, discriminando las capas que están implementadas en el host y las que
están en el Hardware Bluetooth (módulos, tarjetas, sistemas de desarrollo
Bluetooth), como es el caso de las tarjetas Blueboard_UV01 y Blueboard_UV02
desarrolladas en esta tesis.

Figura 3-2. Modelo de Implementación del protocolo Bluetooth. Software – Firmware –
Hardware
La Figura 3-2 describe esquemáticamente la implementación del stack de
protocolos Bluetooth al nivel de software, firmware y hardware, especificando su
ubicación ya sea en el host o en el hardware Bluetooth.
El host y el hardware Bluetooth se comunican a través del HCI (Host Controller
Interface) o Interfaz Controladora de host. El firmware HCI implementa los
Comandos HCI para el hardware Bluetooth teniendo acceso a los comandos de

anda base, manejador de enlace, registros de estatus del hardware, registros de
control y registros de eventos.
Muchas capas pueden existir entre el driver HCI ubicado en el host y el firmware
HCI ubicado en el hardware Bluetooth. Estas capas intermedias, se encargan del
control y transporte de datos a través de un medio físico (un bus físico ya sea
USB, PC Card, RS232, u otro), para que se establezca una comunicación
transparente entre el driver HCI y el firmware HCI, permitiendo el intercambio de
datos y comandos entre estos dos.
El host recibirá notificaciones asíncronas de los eventos HCI independientemente
de la capa de control de transporte del host que se esté usando. Los eventos HCI
son usados para notificar al host cuando algo ocurre.
3.1 ARQUITECTURAS DE INTEGRACIÓN DEL STACK DE
PROTOCOLOS BLUETOOTH
La mayor o menor integración del stack de protocolos Bluetooth en un sistema,
depende del tipo de producto que se está desarrollando; de esta manera y como
se puede observar en la Figura 3-3, tres diferentes arquitecturas podrían
implementarse. Cabe resaltar que no son las únicas.

Figura 3-3. Tres modelos de Integración del stack de protocolos Bluetooth
La Figura 3-3 a describe una solución estándar de dos procesadores, en donde la
división entre las capas altas de protocolo y las bajas toma lugar en el HCI, esto
asume que el host es en general algún tipo de plataforma computacional cuyas
capacidades de comunicación son “ilimitadas”. Este es el caso de las
computadoras personales.
En la Figura 3-3 b se puede observar una arquitectura embebida de dos
procesadores, la cual permite que los productos puedan diseñarse para incorporar
Bluetooth donde el host es un recurso limitado y no es capaz de soportar la

adición de una funcionalidad Bluetooth. Un ejemplo de este caso es un teléfono
móvil; no todos los teléfonos móviles tienen los suficientes recursos para
implementar pilas de protocolo adicionales.
La Figura 3-3 c muestra una arquitectura embebida de un procesador; este es el
caso de un producto que implementa el stack de protocolos Bluetooth completo
en un solo chip. Un ejemplo es un “manos libres” inalámbrico, sin embargo, el
modelo aplica a cualquier dispositivo inalámbrico pequeño [22].
3.2 PRINCIPALES SOFTWARE PARA EL HOST
Son muchas las compañías que trabajan en el desarrollo de stacks de protocolos
Bluetooth para el host, en especial, los fabricantes de módulos Bluetooth, quienes
ofrecen productos de prueba y kits de desarrollo que incluyen software para el
host, cuya finalidad es facilitar y agilizar el desarrollo de aplicaciones. Este
software no es usualmente de libre distribución, es decir que su licencia tiene un
costo, el cual, en la mayoría de los casos, está incluido en el costo del kit de
desarrollo.
Sin embargo, los fabricantes de módulos Bluetooth no son los únicos que ofrecen
software para el host, hay muchas otras empresas y universidades interesadas en
su desarrollo, razón por la cual es posible encontrar software demostrativo y de
libre distribución con licencia pública GPL (GNU Public License).
En esta tesis se trata únicamente el software para sistemas cuyo host
corresponde a un PC, es decir, no se cubre software para sistemas embebidos.

Los requerimientos tales como sistema operativo, capacidad de memoria, entre
otros, son propios de cada software.
3.2.1 Software Bluetooth con propiedad de licencia.
Debido a que muchas de las características de estos diferentes tipos de software
son muy parecidas, se da una breve descripción de los más representativos.
� Bluetooth Host Stack Software para el host desarrollado por Ericsson, el
cual implementa las siguientes capas del stack de protocolos: driver HCI,
L2CAP, RFCOMM, SDP y opcionalmente OBEX y TCS. Este stack está
escrito en ANSI C, y es independiente del ambiente de desarrollo (compilador,
debugger, linker, etc.); esto sumado al concepto de Sistema Operativo Virtual,
hace que este stack, sea adaptable tanto a sistemas operativos para sistemas
embebidos como a los sistemas operativos estándar tales como Linux y
Windows. Las siguientes son herramientas de software disponibles para
Windows, basadas en el Bluetooth Host Stack de Ericsson: Bluetooth PC
reference Stack, Bluetooth Development Kit y Bluetooth Application Tool Kit
[23].
� Bluetooth Software Suite Desarrollado por Digianswer A/S, este software
escrito para Microsoft Windows además de brindar un API (Interfaz de
Programa de Aplicación) de fácil uso, soporta los siguientes perfiles: acceso
general, servicio de descubrimiento de aplicaciones, puerto serial, red de
acceso conmutado, fax, acceso a LAN, OBEX, Object Push, transferencia de
archivos y Ethernet [24].

� BlueStack Software desarrollado por MEZOE, una división de Cambridge
Consultants Ltd. Escrito en lenguaje C, implementa al igual que los dos
anteriores, un driver HCI y las capas superiores del protocolo Bluetooth. Son
ofrecidos varios productos basados en el BlueStack para Microsoft Windows:
este es el caso de StackPrimer, Proto Developer e Interface Express [22].
La Tabla 3-1 muestra una recopilación de algunos productos con propiedad de
licencia que implementan el stack de protocolos Bluetooth para el host; se indica
además la empresa que lo desarrolla, herramientas de desarrollo para cada stack
y el sistema operativo sobre el cual corre.
Tabla 3-1. Software Bluetooth para el Host con propiedad de licencia
NOMBRE DEL
STACK
Bluetooth Host
Snack
Bluetooth
Software Suite
FABRICANTE HERRAMIENTAS DE
DESARROLLO
Ericsson • Bluetooth PC reference
Stack
• Bluetooth Development
Kit
• Bluetooth Application
Tool Kit
Digianswer A/S • Digianswer Bluetooth
Software Suite
• Digianswer Bluetooth
HCI
• Digianswer Bluetooth
Statistics
• Digianswer Bluetooth
HCI Router
• Digianswer HCI Test
Application
• Digianswer API
SISTEMA OPERATIVO
SOPORTADO POR LA
HERRAMIENTA
Microsoft Windows
Microsoft Windows
BlueStack Mezoe • Proto Developer Tool Microsoft Windows
Stack Partner
Program
National
Semiconductor
• Stack Partner Program • Microsoft Win98, ME,
2000 y XP
• Microsoft WinCE
• Linux

NOMBRE DEL
STACK
Rappore
Technologies'
Software
Developers Kit
Socket Bluetooth
Software
BlueStack
Software
Development Kit
Bluefrog
Demostration
FrogStack
FABRICANTE HERRAMIENTAS DE
DESARROLLO
Rappore
Technologies
• Software Developers Kit
SISTEMA OPERATIVO
SOPORTADO POR LA
HERRAMIENTA
• No especificado
• Código fuente
desarrollado en lenguaje
C, C++ y Java
Socket • Bluetooth Connection Kit • Windows Powered
Pocket PC
Cambridge
Silicon Radio
Reselec ag
Bluefrog
• BlueStack Software
Development Kit
• Bluefrog Demostration
FrogSatck
3.2.2 Software Bluetooth con licencia pública (GPL)
• Windows CE
• Windows NT
• Net OS 3.0
• Linux
En esta sección se tratan las principales características de los tipos de productos
de libre distribución con licencia GPL desarrollados para Linux y disponibles en
Internet. Los principales son: OpenBT, BlueDrekar, Bluez y Affix.
� OpenBT Axis Communications Inc. desarrolló, en primera instancia, un driver
Bluetooth para Linux llamado OpenBT, el cual puede ser usado tanto en
ambientes eLinux (Linux Embebido) como en Linux para PC. Este fue el primer
stack de protocolos disponible, siendo ahora un proyecto de código fuente
abierto, desarrollado en un kernel de Linux 2.0.33, de tal manera que no debe
presentar problemas de funcionamiento en versiones posteriores del kernel.
Implementa el perfil de LAN mediante enlaces PPP sobre RFCOMM y además
una forma simple del perfil de descubrimiento de servicios (SDPP) [25].
El código fuente en sus versiones para PC y eLinux, se encuentra disponible
en el portal de Internet de Sourceforge [26], y es posible conseguir más
información en el portal del proyecto [27].

� BlueDrekar El driver Bluetooth de IBM, disponible bajo licencia GPL,
implementa la capa de transporte UART de la Interfaz Controladora del host
(HCI). Este código sirve de referencia para escribir drivers para otras capas de
transporte HCI, como USB. El BlueDrekar middleware es una implementación
de referencia de las capas altas del protocolo Bluetooth, disponible bajo
licencia alpha Works [28].
Según el fabricante, este código ha sido desarrollado y probado en PCs con
procesadores de arquitectura i486 o superior, corriendo un kernel de Linux
2.2.12-20 (Red Hat 6.1), 2.2.14-5.0 (Red Hat 6.2), 2.2.16-22 (Red Hat 7). Han
sido utilizados para realizar las pruebas de desempeño los módulos Bluetooth
de Ericsson con la capa de transporte UART y firmware versión P7C (v1.0A) y
P3E (v1.0B).
� Affix Este stack de protocolo para Linux fue desarrollado por el Centro de
Investigación de Nokia en Helsinki, Finlandia. El software Bluetooth de Affix
trabaja sobre plataformas Intel, ARM (iPaq, ARM9 y otras) y PowerPC (iMac).
Las últimas versiones del software están disponibles en el sitio web de Affix
[29].
� Bluez Este es el stack de protocolos Bluetooth oficial de Linux, el cual es
parte del kernel 2.4 y posteriores. Bluez brinda a sus usuarios la capacidad de
comunicación con dispositivos Bluetooth, entre los que se tienen adaptadores
USB, teléfonos móviles y puntos de acceso entre otros, además de conexión
inalámbrica entre dos o más computadoras. Bluez consta del core HCI,
drivers HCI para UART, USB y emulador de HCI, módulo del protocolo L2CAP
y utilidades de configuración y prueba [30].

3.3 CONCEPTOS DEL CORE DE LINUX
Estos conceptos básicos sobre el subsistema de red de Linux son fundamentales
para entender la manera como los drivers para los dispositivos de red (tarjetas de
red) interactúan con el sistema operativo, independientemente del protocolo con el
que operan (Ethernet, X.25, Bluetooth, etc.). Estos conceptos son tomados del
documento Affix in a Nutshell [31], disponible en el sitio web de Affix [29].
El sistema operativo Linux implementa el socket API estándar de Berkeley,
desarrollado para UNIX. La figura 3-4 describe la arquitectura del subsistema de
red de Linux, donde sus componentes estándar son: interfaz del Socket Berkeley
y la interfaz del driver del dispositivo de red (Network Device Driver Interface).
Figura 3-4. Arquitectura de Red de Linux

La interfaz del socket Berkeley permite a los programas abrir terminales de
comunicaciones para dispositivos remotos en el espacio de usuario. El socket es
una abstracción de red para los terminales de un canal y está asociado con el
protocolo; usualmente, el PF_INET es usado para asociar un socket con el
protocolo TCP/IP.
La interfaz del driver del dispositivo de red permite el uso simultáneo de múltiples
dispositivos de red, cada uno de los cuales tiene un tipo apropiado para distinguir
la clase de dispositivo a la cual pertenece, es decir, Ethernet, PPP, X.25, etc. El
driver del dispositivo registra el dispositivo de red en el sistema.
La interfaz del driver de red incluye un paquete encargado de organizar los
diferentes tipos de dispositivos (Packet Scheduler), para lo cual implementa una
disciplina de colas.
La capa de protocolo corresponde al protocolo que se está implementando. Cada
protocolo debe registrarse por si mismo tanto en la interfaz del socket con la
familia de protocolo (PF_XXX) apropiada como en la interfaz del driver del
dispositivo con el tipo de protocolo apropiado. De esta manera cada paquete
recibido será entregado a la capa de protocolo correspondiente.
Tanto en este diseño como en la mayoría de los kernel de Linux la capa de red es
orientada a objetos, siendo estos los objetos más importantes:

• Dispositivo o Interfaz: Una interfaz de red es el código programado para
enviar y recibir paquetes de datos. Usualmente una interfaz se usa para un
dispositivo como es el caso de una tarjeta Ethernet; sin embargo, muchos
dispositivos corresponden únicamente a software, como es el caso del
dispositivo de realimentación (loopback) usado para el envío de datos dentro
del mismo sistema.
• Protocolo: Cada protocolo es un lenguaje diferente de red. En el kernel de
Linux cada protocolo corresponde a un módulo de código aparte el cual brinda
servicios a la capa del socket.
• Socket: Es un terminal de conexión que suministra un archivo de
entrada/salida (I/O) y existe como un archivo descriptor para el programa de
usuario. En el kernel cada socket corresponde a un par de estructuras que
representan el nivel alto de la interfaz del socket y el nivel bajo de la interfaz
de protocolo.
• Sk_buff: Todos los buffers usados por las capas de red son sk_buffs. El
control de estos buffers es suministrado por las rutinas de bajo nivel del Core
de librerías, disponible para todo el sistema de red. Estas primitivas (sk_buffs)
brinda los buffers generales y las facilidades de control de flujo que necesitan
los protocolos de red.
Para probar el desempeño de las tarjetas Blueboard_UV01 y Blueboard_UV02, en
esta tesis se utilizaron como herramientas de software los stacks de protocolos de
Affix y Bluez. Por esta razón a continuación se hace una descripción más
detallada de estos stacks de protocolos, en cuanto a su instalación, principales
características y utilidades.

3.4 DESCRIPCIÓN DEL STACK DE PROTOCOLOS DE AFFIX
El stack de protocolos de Affix fue desarrollado en el Laboratorio de Redes
Móviles del Centro de Investigación de Nokia, bajo licencia GPL, sin ser un
producto oficial de Nokia.
La información contenida aquí es una recopilación de los más importantes apartes
del documento Affix in a Nutshell [31], disponible en el sitio web de Affix [29].
Affix soporta los protocolos del Core Bluetooth HCI, L2CAP, RFCOMM, SDP y
varios de los perfiles. Además tiene una implementación modular, una interfaz
socket para los protocolos HCI, L2CAP y RFCOMM, es independiente de la
interfaz del módulo Bluetooth y soporta múltiples dispositivos Bluetooth.
3.4.1 Arquitecturas Soportadas
Affix soporta las siguientes arquitecturas:
• i386
• ARM (por ejemplo Compaq iPaq)
• PowerPC (por ejemplo iMac)
• Sparc
En general Affix se puede ejecutar en cualquier arquitectura que corra bajo Linux.

3.4.2 Hardware Soportado
En principio Affix soporta todos los dispositivos que cumplan con la especificación
Bluetooth. La lista completa del hardware soportado se puede consultar en el sitio
de Affix en Internet [29] o en el CD ROM que acompaña este libro.
Affix soporta los siguientes perfiles Bluetooth:
• Perfil de acceso general
• Perfil de descubrimiento de servicios
• Perfil de puerto serial
• Perfil de acceso conmutado a la red (Red Dial-Up)
• Perfil de acceso a LAN
• Perfil OBEX Object Push
• Perfil OBEX File Transfer
• Perfil de red de área personal (PAN)
Affix consta de los siguientes paquetes:
• Affix Kernel
• Affix
Además ofrece herramientas de control, librerías y demonios de servicios.
3.4.3 Arquitectura de Affix
La arquitectura general de Affix se puede observar en la Figura 3-5. En general el
software de Affix puede ser dividido en dos componentes:
• Componente de protocolo, el cual implementa el stack de protocolo.

• Componente de Administración o de Manejo, el cual controla el componente
de protocolo y representa la parte inteligente del software.
Figura 3-5. Modelo de la Arquitectura de Affix
La filosofía UNIX (y Linux) es que el kernel debe brindar los mecanismos básicos y
las aplicaciones deben implementar la lógica en el espacio de usuario [32]. Los
beneficios de tener más funcionalidad en el espacio de usuario radican en la
facilidad en el proceso de implementación y mayor estabilidad del sistema ya que
en caso de presentarse errores estos se localizan en la aplicación, en donde es
posible usar muchas herramientas de depuración.
De acuerdo a esta filosofía, el stack de protocolos de Affix corre en el espacio de
kernel mientras que la Entidad de Manejo ME (Management Entity) corre en el
espacio de usuario. Todo el tráfico de paquetes de la red viene a Affix desde el
espacio de kernel, de modo que por razones de desempeño, una óptima solución
es implementar aquí el core de protocolos.

La ME complementa la funcionalidad del stack de protocolos Bluetooth, siendo
implementada como una aplicación en el espacio de usuario. Es posible reimplementar
la ME sin modificar el código en el espacio de kernel. Un diagrama
práctico de los componentes de Affix se muestra en la Figura 3-6.
Figura 3-6. Diagrama de los Componentes de Affix

Si se necesita información a cerca de los modelos de seguridad de Affix, el API y
el socket de familia PF_AFFIX, esta se encuentra en el CD ROM que acompaña
este libro (versión en español) o en el sitio de Affix en Internet [29][31].
3.4.4 Utilidades de Affix
Affix incluye una utilidad de control (btctl) y un “súper servidor” (btsrv). Una
descripción completa de los comandos de estas utilidades, se puede encontrar en
las páginas del manual, el cual está incluido en los paquetes instalados por Affix
[29] o en el CD ROM anexo a este libro (versión en español).
3.4.5 Instrucciones de Instalación
Affix se compone de dos paquetes: affix y affix-kernel. affix contiene los archivos
fuente para compilar e instalar los programas del modo de usuario y affix-kernel
las fuentes para compilar los módulos del kernel.
� Paquete affix-kernel. Los siguientes son los pasos para compilar e instalar
affix-kernel:
1. Copiar el archivo affix-kernel-xxx-kernel-xxx.tgz en el directorio /usr/src
2. Desempaquetar el archivo:
tar -xzvf affix-kernel-xxx-kernel-xxx.tgz
3. Correr el script de configuración y contestar las preguntas (s/n)
dependiendo de la configuración deseada:
make config
4. Compilar las fuentes:
make all

5. Instalar el paquete (requiere privilegios de root):
make install
6. Actualizar los alias de protocolo: Esto es requerido para que los módulos de
Affix se carguen automáticamente cuando las aplicaciones necesiten
soporte de Affix. Si la distribución de Linux es diferente de Debian, debe
adicionarse las siguientes líneas en el archivo /etc/modules.conf:
alias net-pf-27 affix
alias char-major-60 affix_rfcomm
� Paquete affix
Para compilar e instalar el paquete affix se deben seguir los siguientes pasos:
1. Copiar el paquete affix-xxx.tgz en el directorio /usr/src
2. Desempaquetar el archivo:
tar –xzvf affix-xxx.tgz
3. Correr el script de configuración:
./configure
4. Compilar el paquete:
make
5. Instalar el paquete (requiere privilegios de root):
make install
3.5 DESCRIPCIÓN DEL STACK DE PROTOCOLOS BLUEZ
Bluez es el stack Bluetooth oficial de Linux, el cual brinda soporte para las capas y
protocolos del core Bluetooth. La información contenida en este ítem es una
síntesis de los principales apartes del HowTo de Bluez disponible en el sitio oficial
de Bluez en Internet [33].

Estas son sus principales características:
• Arquitectura flexible, eficiente y modular.
• Soporta múltiples dispositivos Bluetooth.
• Procesamiento de datos para multienlaces.
• Abstracción del Hardware.
• Interfaz de socket estándar para todas las capas.
Bluez consta de:
• Core HCI.
• drivers HCI para UART, USB y emulador de HCI.
• Módulos para el protocolo L2CAP.
• Utilidades de configuración y prueba.
Figura 3-7. Diagrama de la Arquitectura de Bluez

La Figura 3-7 es un esquema de la arquitectura de Bluez, que indica las capas
implementadas por este software dentro del stack de protocolos Bluetooth.
El código fuente de Bluez se puede obtener de la página oficial de Bluez en
Internet [30]. Requiere para su funcionamiento un Kernel de Linux 2.4.4 o
posterior. Si se desea utilizar las últimas versiones del stack, es necesario
deshabilitar del kernel el soporte nativo de Bluetooth. Bluez se puede usar con
dispositivos Bluetooth con interfaz Serial o USB, además brinda un dispositivo HCI
virtual (vhci) el cual permite depurar y probar las aplicaciones sin necesidad de
tener conectados dispositivos Bluetooth reales.
3.5.1 Compilación e Instalación
Bluez se compone de los siguientes paquetes:
• bluez-kernel-X.X.tar.gz
• bluez-utils-X.X.tar.gz
• bluez-libs-X.X.tar.gz
• bluez-SDP-X.X.tar.gz
• bluez-PAN-X.X.tar.gz.
Los archivos README o INSTALL incluidos dentro de cada paquete contienen
toda la información sobre los requerimientos e instrucciones para su instalación.
Los procedimientos de compilación e instalación son muy parecidos para cada uno
de estos paquetes; en general el siguiente procedimiento para instalar el paquete
bluez-kernel-X.X.tgz se puede seguir con los demás paquetes, reemplazando el
nombre del archivo por el correspondiente:

1. Copiar las fuentes en el directorio /usr/src
2. Desempaquetar el archivo fuente:
tar –xzvf bluez-kernel-X.X.tar.gz
3. Ubicarse dentro del directorio bluez-kernel-X.X (o el correspondiente a
instalar)
cd bluez-kernel-X.X
4. Correr el script de configuración:
./configure
5. Compilar las fuentes:
make
6. Instalar las fuentes:
make install
Debe escribirse las siguientes líneas de código en el la línea de comandos de
Linux, únicamente después de instalar el paquete bluez-kernel-X.X, esto con el fin
de crear el dispositivo HCI virtual (vhci):
mknod /dev/vhci c 10 250 chmod 664/dev/vhci
C=0;
While [$C -lt 256];
do
if [ ! -c /dev/rfcomm$C ];
then
mknod -m 666 /dev/rfcomm$C c 216 $C
fi
C=`expr $C + 1`
done
Para que Bluez trabaje correctamente se deben escribir las siguientes líneas en el
archivo /etc/modules.conf:

alias net-pf-31 bluez
alias bt-proto-0 l2cap
alias bt-proto-2 sco
alias bt-proto-3 rfcomm
alias bt-proto-4 bnep
alias tty-ldisc-15 hci_uart
alias char-major-10-250 hci_vhci
Después de esto se debe correr el comando “depmod –a” para habilitar la carga
automática de los módulos Bluez. Estos módulos también se pueden cargar
manualmente mediante el comando “modprobe” acompañado de uno de los
siguientes módulos:
• bluez Core Bluetooth.
• hci_usb Driver HCI USB.
• hci_uart Driver HCI UART.
• hci_vhci Driver para el dispositivo virtual HCI.
• l2cap Módulo L2CAP.
• sco Módulo SCO (Synchronous Connection Oriented).
• rfcomm Módulo RFCOMM.
Una descripción completa de los comandos de Bluez está disponible en el sitio
oficial de Bluez en Internet [30][33] o en el CD ROM que acompaña este libro
(versión en español).

4. CONCEPTOS BÁSICOS PARA LA IMPLEMENTACIÓN
DE UNA RED DE AREA PERSONAL BLUETOOTH
La especificación Bluetooth define perfiles o esquemas estándar de los
escenarios de desarrollo para las aplicaciones Bluetooth, varios de ellos ya se han
mencionado en el capítulo 1. Uno de estos escenarios corresponde al perfil de red
de área personal o perfil PAN (Personal Area Networking Profile) [34]. El perfil
PAN brinda capacidades de red a los dispositivos Bluetooth para lo cual utiliza el
Protocolo de Encapsulamiento de Red BNEP (Bluetooth Network Encapsulation
Protocol) [35], de gran importancia ya que encapsula los paquetes provenientes
de varios protocolos de red (IPv4, IPv6 e IPX entre otros) y los transporta
directamente sobre la capa de protocolo L2CAP de Bluetooth, haciendo posible
que la red Bluetooth se comporte y forme parte de una red TCP/IP.
4.1 PROTOCOLO DE ENCAPSULAMIENTO DE RED BNEP
El protocolo de encapsulamiento de red de Bluetooth encapsula los paquetes de
los protocolos de red más utilizados, para ser transportados sobre la capa L2CAP.
BNEP soporta los mismos protocolos de red soportados por el estándar IEEE
802.3 para ecapsulamiento Ethernet (IPv4, IPv6, IPX entre otros). BNEP requiere
además un formato de encapsulamiento que optimice los bits de cabecera de tal
manera que se ofrezca un manejo eficiente del ancho de banda. Los siguientes
apartes son tomados de la especificación del protocolo BNEP publicada por el SIG
Bluetooth [35].

4.1.1 Consideraciones
1. Este protocolo está implementado usando canales L2CAP orientados a
conexión.
2. Bluetooth se considera un medio de transmisión al mismo nivel OSI de
Ethernet, Token Ring, ATM, etc.
3. Se considera a L2CAP como la capa de control de acceso al medio MAC
(Media Access Control) de Bluetooth.
4. BNEP especifica una mínima MTU (Unidad máxima de transmisión) para
L2CAP de 1691 bytes 1 .
5. Se deben aplicar a Bluetooth las reglas de conectividad y las topologías de
red definidas por el estándar IEEE 802.3 [36][37].
6. El espacio de dirección Bluetooth BD_ADDR es administrado por IEEE, y
es asignado desde el espacio de dirección de Ethernet. De esta manera es
posible construir un punto de acceso de red Bluetooth como un puente
entre los dispositivos Bluetooth y una red Ethernet.
La Figura 4-1 muestra la ubicación del BNEP dentro de la torre de protocolos de
Bluetooth.
1
La mínima MTU (Máxima Unidad de Transmisión) de 1691 se seleccionó con base en el máximo
paquete de carga útil de Ethernet (1500 bytes más 15 bytes de encabezado de BNEP y otros de
extensión). 1691=5*339 (Tamaño de un DH5) – 4 (Encabezado de L2CAP).

Figura 4-1. Ubicación del BNEP dentro de la Torre de protocolos de Bluetooth.
4.1.2 Orden de los Bytes y Valores numéricos
Todos los valores contenidos en este capítulo se presentan en notación
hexadecimal. Los campos que contienen múltiples bytes (bits) se muestran con los
bytes (bits) más significativos hacia la izquierda y los menos significativos hacia la
derecha. Los bytes de los encabezados de BNEP se disponen en el formato
estándar de red Big Endian, en donde los bytes más significativos se transmiten
antes que los menos significativos. El byte 0 es el más significativo.

4.1.3 Encapsulamiento de Paquetes
La Figura 4-2 muestra la manera como BNEP remueve los encabezados de un
paquete Ethernet y los reemplaza por un encabezado BNEP. El paquete resultante
(Carga útil de Ethernet y el encabezado de BNEP) es encapsulado en un paquete
L2CAP y enviado sobre Bluetooth.
Figura 4-2. Encapsulamiento de un Paquete Ethernet en un paquete L2CAP
BNEP es usado para transportar sobre Bluetooth tanto paquetes de datos como
paquetes de control, de esta manera brinda a los dispositivos Bluetooth
capacidades de red similares a las ofrecidas por Ethernet.
4.1.4 Formato de los Encabezados BNEP
Todos los encabezados de BNEP siguen el formato que se muestra en la Figura
4-3.

Figura 4-3. Formato de los Encabezados BNEP
� Tipo de BNEP Este campo tiene un tamaño de siete bits e identifica el tipo de
encabezado BNEP que contiene el paquete. Los posibles valores que puede
tomar y la descripción de los mismos se muestra en la Tabla 4-1.
Tabla 4-1. Valores para el campo BNEP Type el cual define el tipo de paquete BNEP
Valor Tipo de Paquete BNEP
0x00 BNEP_GENERAL_ETHERNET
0x01 BNEP_CONTROL
0x02 BNEP_COMPRESSED_ETHERNET
0x03 BNEP_COMPRESSED_ETHERNET_SOURCE_ONLY
0x04 BNEP_COMPRESSED_ETHERNET_DEST_ONLY
0x05-0x7E Reservado para un futuro uso
0x7F
Reservado para los Paquetes LLC de 802.2 por IEEE 802.15.1
WG
� Bandera de Extensión (E) Corresponde a un bit de extensión que indica si
existe uno o más encabezados de extensión entre el encabezado de BNEP y la
carga útil. Si toma un valor de 0x1, entonces uno o más encabezados de

extensión se ubican antes de la carga útil. Si el valor que tiene es 0x0, la carga
útil sigue después del encabezado BNEP.
� Paquete BNEP Depende del valor que se haya consignado en el campo del
Tipo de BNEP.
4.1.5 Tipo de Paquete BNEP_GENERAL_ETHERNET
El paquete general de Ethernet para BNEP se debe usar para transportar
paquetes Ethernet desde y hacia redes Bluetooth. Como se puede apreciar en la
Figura 4-4 el paquete está conformado por una dirección destino, una dirección
origen y el tipo de protocolo de red contenido en la carga útil (IPv4, IPv6, etc).
Cualquiera de las direcciones ya sea origen o destino puede corresponder a una
dirección Ethernet IEEE, si el origen o destino es un dispositivo IEEE y no un
dispositivo Bluetooth.
Figura 4-4. Formato del Encabezado para un paquete BNEP_GENERAL_ETHERNET

4.1.6 Tipo de Paquete BNEP_CONTROL
El paquete de control de BNEP es utilizado para intercambiar información de
control. En este tipo de paquete, toda la información de control está contenida en
el encabezado del BNEP_CONTROL de tal manera que el campo de carga útil no
contiene información alguna. Por el momento hay siete tipos de paquetes de
control BNEP. El tipo de paquete de control es definido por el valor que se
consigne en el campo tipo de control de BNEP; no se entra en detalle sobre cada
tipo de paquete de control ya que esto no está dentro de los alcances de la Tesis.
La Figura 4-5 muestra el formato para el encabezado de un paquete
BNEP_CONTROL.
Figura 4-5. Formato del Encabezado para un paquete BNEP_CONTROL
4.1.7 Tipo de Paquete BNEP_COMPRESSED_ETHERNET
El paquete Ethernet comprimido de BNEP se usa para transportar paquetes
Ethernet hacia o desde dispositivos que tienen una conexión directa al nivel de la
capa L2CAP usando BNEP. Debido a la existencia de una conexión L2CAP entre
lo dos dispositivos Bluetooth no es necesario incluir dentro del paquete las
direcciones de origen y destino. Se debe anotar que las direcciones de multicast
o broadcast no deben ser comprimidas. La Figura 4-6 muestra el formato de un
paquete BNEP_COMPRESSED_ETHERNET.

Figura 4-6. Formato del encabezado para un paquete BNEP_COMPRESSED_ETHERNET
4.1.8 Tipo de Paquete BNEP_COMPRESSED_ETHERNET_SOURCE_ONLY
Este paquete Ethernet comprimido se usa para transportar paquetes Ethernet
hacia un dispositivo el cual siempre será el destino final para todos los paquetes.
Por esta razón los dispositivos no necesitan incluir la dirección destino en los
paquetes siendo esta la misma dirección correspondiente al canal L2CAP sobre el
cual se envían los paquetes. Se debe anotar que las direcciones de multicast o
broadcast no deben ser comprimidas.
Figura 4-7. Formato del encabezado para un paquete
BNEP_COMPRESSED_ETHERNET_SOURCE_ONLY

4.1.9 Tipo de Paquete BNEP_COMPRESSED_ETHERNET_DEST_ONLY
Este paquete comprimido Ethernet es usado para transportar paquetes desde un
dispositivo el cual es la fuente del paquete. De esta manera los dispositivos no
necesitan incluir la dirección de la fuente del paquete ya que esta fuente puede
determinarse a partir de la conexión L2CAP.
Figura 4-8. Formato del encabezado para un paquete
BNEP_COMPRESSED_ETHERNET_DEST_ONLY
El siguiente es un ejemplo en el cual un paquete IP es enviado usando BNEP. Un
paquete IPv4 es enviado desde un dispositivo con una dirección IEEE de 48 bits
(00:AA:00:55:44:33) hacia un dispositivo con una dirección Bluetooth
(00:30:B7:45:67:89). En este caso el paquete BNEP utilizado es del tipo
BNEP_GENERAL_ETHERNET como se ilustra en la Figura 4-9.

Figura 4-9. Ejemplo del envío de un paquete IPv4 usando BNEP entre un dispositivo con
dirección IEEE y otro con dirección Bluetooth
4.2 Piconet y scatternet
Dos o más dispositivos Bluetooth que comparten el mismo canal de conexión
conforman una piconet. Esta se establece a través de enlaces punto-multipunto,
en donde uno de los dispositivos cumple el rol de maestro mientras los demás
actúan como esclavos. Una piconet puede tener un máximo de siete esclavos
activos. Las Figuras 4-10 y 4-11 ilustran respectivamente el esquema y un ejemplo
de una piconet.

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

PAN describe los mecanismos mediante los cuales se brindan propiedades de red
a los dispositivos Bluetooth que forman parte de una piconet.
Múltiples piconets en donde sus rangos de cobertura se traslapan conforman una
scatternet. Cada piconet debe tener un único maestro, sin embargo, los esclavos
pueden participar en diferentes piconets. Además un maestro de una piconet
puede ser esclavo en otra. Las Figuras 4-12 y 4-13 ilustran respectivamente el
esquema y un ejemplo de una scatternet.
Figura 4-12. Esquema de una Scatternet

Figura 4-13. Ejemplo de una Scatternet
4.3 PERFIL DE RED DE AREA PERSONAL (PAN PROFILE)
El perfil PAN (Personal Area Networking Profile) describe como usar el
protocolo BNEP para brindar capacidades de red a los dispositivos Bluetooth.
Estos apartes son tomados del documento Personal Area Networking Profile
publicado por el SIG. Bluetooth [34]. El perfil PAN presenta los siguientes
requerimientos funcionales:
• Define una red IP ad-hoc, dinámica y personal
• Debe ser independiente del sistema operativo, lenguaje y dispositivo
• Brinda soporte para los protocolos de red más comunes como IPv4 e IPv6.
• Brinda soporte para puntos de acceso en donde la red puede ser una LAN
corporativa, GSM u otro tipo de red de datos.

• Debe acomodarse a los recursos reducidos disponibles en los dispositivos
pequeños respecto a memoria, capacidad de procesamiento y uso de
interfaces.
4.3.1 Consideraciones
• El perfil PAN debe soportar IPv4 e IPv6. Los otros protocolos pueden estar o
no habilitados.
• En una red generalizada, la trayectoria del tráfico originado desde un
dispositivo hacia otro puede estar conformada por uno o varios medios de
transporte, por ejemplo, Bluetooth, Ethernet, Token Ring, PSTN, ISDN, ATM,
GSM, etc.
Son tres escenarios propuestos para el perfil PAN: Puntos de acceso a una red
(Network access points), Grupo de red Ad-hoc (Group Ad-hoc Networks) y
PANU-PANU (PAN USER). Cada uno de estos escenarios define el rol y el
servicio que deben asumir los dispositivos involucrados en una de estas
arquitecturas.
4.3.2 Puntos de Acceso a una red (NAP)
Un punto de acceso a una red (NAP) corresponde a una unidad que contiene uno
o más dispositivos Bluetooth y actúa como puente, proxy o enrutador, entre una
red Bluetooth y otro tipo de tecnología de red (Ethernet, GSM, ISDN, Home PNA,
Cable Módem y Celular). La Figura 4-14 ilustra la arquitectura para dos puntos de
acceso a red.

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

Figura 4-15. Stack para el rol NAP
4.3.3 Grupo de Red Ad-hoc
La versión 1.0 del Perfil PAN [34], especifica el escenario para una red personal
ad-hoc el cual consiste en una simple piconet con conexiones entre dos o más
dispositivos Bluetooth. Un maestro y un máximo de siete esclavos conforman esta
red. El límite de siete esclavos se debe al esquema activo de direccionamiento de
Bluetooth [3]. La Figura 4-16 es un esquema para una red Ad-hoc.

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

Figura 4-17. Stack para un enlace en una red Ad-hoc Bluetooth
4.3.4 PANU – PANU
En este escenario se establece una conexión punto a punto entre dos usuarios
de PAN (PANU), permitiéndose así una comunicación directa entre ellos. El PANU
es el dispositivo Bluetooth que usa los servicios NAP o GN. El PANU asume el rol
de cliente de los roles NAP o GN.

5. PRUEBAS DE DESEMPEÑO Y APLICACIÓN PARA LAS
TARJETAS BLUEBOARD_UV01 Y BLUEBOARD_UV02
Como se explicó en el segundo capítulo de este libro, las tarjetas
BlueBoard_UV01 y BlueBoard_UV02 tienen diseños muy similares. Estos dos
diseños difieren en el tipo de antena que utilizan, Rangestar 100929 para la
BlueBoard_UV01 y Rangestar 100930 para la BlueBoard_UV02.
Por otro lado las tarjetas poseen interfaces HCI para USB y RS232. Además se
cuenta con los módulos Bluetooth ROK 101 007/21E y ROK 101 008 de Ericsson,
removibles e intercambiables gracias al carrier socket BT001A-30G2T de Suyin
que posee cada tarjeta. Todo esto sumado con las herramientas de prueba y
utilidades que brindan los stack de protocolo BlueZ y Affix, crea una potente
plataforma de pruebas tanto para el hardware (antenas Rangestar y módulos
Bluetooth de Ericsson) como para aplicaciones Bluetooth.
El plan de pruebas se divide en dos grupos: el primero lo conforman las pruebas
de desempeño del hardware Bluetooth que permite definir las características de
operación de las tarjetas, y el segundo una serie de pruebas para implementar una
Red de Area Personal (PAN), principal objetivo de esta tesis.

5.1 PRUEBAS DE DESEMPEÑO
Estas pruebas muestran el desempeño de las tarjetas BlueBoard_UV01 y
BlueBoard_UV02, midiendo la rata de transferencia de bits para distintas
distancias y bajo diferentes condiciones. Para esto se utilizó dos nodos (N1 y N2),
cada uno equipado con una tarjeta Bluetooth conectada a un PC a través de una
interfaz USB.
5.1.1 Configuración para las Pruebas
� Hardware
• Cada nodo (N1 y N2) corresponde a un PC DELL Pentium III, el cual
tiene conectada una tarjeta Bluetooth BlueBoard_UV02 a través del
puerto USB.
• Módulos Bluetooth ROK 101 007/21E de Ericsson.
� Software Cada PC tiene un sistema operativo Linux RedHat 7.0 e instalados
todos los paquetes de Bluez (core, librerías y utilidades).
� Dirección Bluetooth de N1: 00:80:37:15:C9:64
� Dirección Bluetooth de N2: 00:80:37:15:C9:67
� N1 es el nodo Fijo y N2 es el nodo móvil.
5.1.2 Descripción de las Pruebas
Para estas pruebas de desempeño, N1 envía paquetes de bits que son recibidos
por N2. El nodo N2 tiene el rol de servidor y escucha constantemente en espera
de paquetes de datos de tamaño mínimo (MTU) negociado con el nodo cliente N1,
gracias a la utilidad de Bluez l2test [33]. l2test es una herramienta de pruebas para
L2CAP, la cual calcula y despliega en el servidor (N2) la velocidad (kb/s) a la que
los datos se transmiten sobre una conexión L2CAP. Se puede conseguir más

información de la utilidad l2test en el HowTo de Bluez [33] o en el CD-ROM anexo
a este libro (versión en español). La arquitectura utilizada para las pruebas de
desempeño se muestra en la Figura 5-1.
Figura 5-1. Arquitectura utilizada en las pruebas de desempeño
Con una distancia inicial de 0 m y desplazando el nodo móvil N2 en intervalos de 1
m, se registró para cada intervalo la rata de bytes calculada por l2test para los
paquetes enviados desde N1. Para cada intervalo de distancia se tomaron
aproximadamente 17 registros para paquetes de 100128 bytes. Para distancias de
6 m en adelante, los paquetes de bytes enviados desde N1 en algunos casos se
redujeron a 20160 bytes y 50400 bytes, para agilizar la captura de los datos.
En la Figura 5-1 la pared representa dos obstáculos, una pared de madera que
coloca a los nodos en cubículos separados simulando un ambiente de oficina y
dos cajas plásticas (una por nodo) en las que se introducen las tarjetas para de
esta manera simular la atenuación provocada por la cobertura plástica propia de
los dispositivos móviles (teléfonos celulares, palm, computadoras portátiles, etc.).

De esta manera se tomaron datos para cuatro escenarios de prueba distintos:
• Línea de vista entre los nodos (LV)
• Pared de madera entre los nodos (M)
• Pared de madera entre los nodos y cada tarjeta dentro de una caja plástica
(MP)
• Línea de vista entre los nodos y cada tarjeta dentro de una caja plástica (LVP)
Se debe correr l2test primero en el servidor N2 y después en el cliente N1 de la
siguiente manera:
� N2 (Servidor)
[root@localhost /root]# l2test -I 2000 -r
l2test[1358]: Waiting for connection on psm 10 ...
De esta manera el servidor N2 espera una conexión L2CAP proveniente desde el
cliente N1 con una MTU entrante de 2000 bytes.
� N1 (Cliente)
[root@localhost /root]# l2test -O 2000 -s -b 100000 00:80:37:15:C9:67
El cliente N1 establece una conexión L2CAP con el servidor N2 y le envía
paquetes de 100000 bytes, valor aproximado por l2test a 100128 bytes. Este
número varía dependiendo de la cantidad de bytes del paquete que se desea
enviar.

En el servidor N2, los datos recibidos se muestran así:
[root@localhost /root]# l2test -I 2000 -r
l2test[1358]: Waiting for connection on psm 10 ...
l2test[1359]: Connect from 00:80:37:15:C9:64 [imtu 2000, omtu 672, flush_to 65535]
l2test[1359]: Receiving ...
l2test[1359]: 100128 bytes in 2.35 sec, 41.52 kb/s
l2test[1359]: 100128 bytes in 2.36 sec, 41.44 kb/s
l2test[1359]: 100128 bytes in 2.36 sec, 41.44 kb/s
l2test[1359]: 100128 bytes in 2.36 sec, 41.41 kb/s
l2test[1359]: 100128 bytes in 2.36 sec, 41.36 kb/s
l2test[1359]: 100128 bytes in 2.33 sec, 41.89 kb/s
l2test[1359]: 100128 bytes in 2.36 sec, 41.44 kb/s
l2test[1359]: 100128 bytes in 2.36 sec, 41.44 kb/s
l2test[1359]: 100128 bytes in 2.37 sec, 41.28 kb/s
l2test[1359]: 100128 bytes in 2.37 sec, 41.30 kb/s
l2test[1359]: 100128 bytes in 2.37 sec, 41.34 kb/s
l2test[1359]: 100128 bytes in 2.34 sec, 41.87 kb/s
l2test[1359]: 100128 bytes in 2.36 sec, 41.39 kb/s
l2test[1359]: 100128 bytes in 2.36 sec, 41.36 kb/s
l2test[1359]: 100128 bytes in 2.37 sec, 41.22 kb/s
l2test[1359]: 100128 bytes in 2.36 sec, 41.51 kb/s
l2test[1359]: 100128 bytes in 2.36 sec, 41.45 kb/s
Estos datos se copian en un editor de texto y después se procesan en una hoja de
cálculo. Para cada intervalo de distancia y variante, se registró y tabuló los datos
ofrecidos por l2test, y se calculó la rata de bits promedio, desviación estándar,
mediana, moda, varianza y porcentaje de variación.
5.1.3 Dependencias entre la velocidad de transmisión, los obstáculos y la
distancia entre los nodos
La rata de bits promedio es utilizada para dar un estimativo de la dependencia de
la velocidad de transmisión respecto a la distancia para cada una de las variantes
ya mencionadas. Estos datos se consignan en las tablas 5-1, 5-2, 5-3 y 5-4.

Tabla 5-1. Rata de Bits promedio con LV
Línea de Vista entre los Nodos
Distancia
Rata de Bits Promedio (kbps)
(m)
0 331.605
1 331.153
2 330.536
4 331.101
6 328.894
8 243.835
10 115.083
12 37.169
Tabla 5-2. Rata de Bits promedio con M
Pared de Madera entre los Nodos
Distancia (m) Rata de Bits Promedio (kbps)
0 331.534
2 330.776
4 283.576
6 251.813
8 103.245
Tabla 5-3 Rata de Bits promedio con MP
Pared de Madera entre los Nodos y
Cada Tarjeta dentro de una Caja Plástica
Distancia (m) Rata de Bits Promedio (kbps)
0 331.200
2 331.176
4 265.365
6 250.480
7 111.856

Tabla 5-4. Rata de Bits promedio con LVP
Línea de Vista entre los Nodos y
Cada Tarjeta dentro de una Caja Plástica
Distancia (m) Rata de Bits Promedio (kbps)
0 330.946
1 315.741
2 331.468
4 330.998
6 331.026
8 245.049
10 25.110
La figura 5-2 muestra, para cada una de las variantes ya mencionadas, la manera
como evoluciona la velocidad de transmisión, representada por la rata de bits
promedio, con respecto a la distancia.

Figura 5-2. Rata de Bits Promedio Vs. Distancia
Rata de Bits (Kbps)
350
300
250
200
150
100
50
0
Rata de Bits Promedio Vs. Distancia
0 1 2 3 4 5 6 7 8 9 10 11 12
Distancia (m)
Línea de Vista
entre los Nodos
Pared de Madera
entre los Nodos
Pared de Madera
entre los Nodos y
Tarjetas en caja
Plástica
Línea de Vista
entre los Nodos
yTarjetas en Caja
Plástica
La Figura 5-2 brinda valiosa información sobre el desempeño de las tarjetas
BlueBoard_UV01 y BlueBoard_UV02, respecto a tres puntos claves:
• La atenuación de la señal de radio debido a los obstáculos
• La atenuación de la señal de radio debido a la distancia
• La conjunción de las dos anteriores
La atenuación en la señal de radio se refleja en la disminución de la rata de bits
promedio.
� Atenuación de la señal de radio debido a los obstáculos. Esta se puede
observar al comparar la rata de bits para cada variante de obstáculos a la

misma distancia entre los nodos. Analizando lo mencionado, se puede concluir
lo siguiente:
• La atenuación de la señal de radio es igual, con o sin obstáculos
(madera o plástico), hasta una distancia entre los nodos de 2 m, con una
rata de bits promedio de 329.3 kbps.
• La mayor atenuación se presenta cuando hay una Pared de Madera
entre los nodos y las tarjetas están dentro de una caja Plástica
• La menor atenuación se da cuando hay línea de vista entre los nodos
• Es mayor la atenuación causada por la pared de madera que la debida a
las cajas plásticas.
� Atenuación de la señal de radio debido a la distancia
• Mayor atenuación: A mayor distancia mayor atenuación, especialmente
visible después de 6m.
• Distancia Máxima de Transmisión: 12 m, con línea de vista entre los
nodos a 37.169 kbps.
• Rata de Bits máxima: 331.6 kp/s a una distancia de 0 m (2 cm aprox.) y
con línea de vista entre los nodos
� Atenuación de la señal de radio debido a los obstáculos y la distancia
• A partir de una distancia entre los nodos de 6 m, aumenta
considerablemente la rata a la que disminuye la velocidad de
transmisión. Para cada una de las variantes de obstáculos, esta
disminución en la rata de bits presenta una tendencia lineal con
pendiente negativa, de esta manera:
� LV: -50.196 kbps/m
� M: -74.284 kbps/m

� LVP: -76.479 kbps/m
� MP: -128.62 kbps/m
Es así como para LV se tiene la menor pendiente, ya que la rata de bits
disminuye 50.196 kbps por cada metro que se aleja el nodo móvil N2, en
cambio para MP se tiene la mayor pendiente, ya que la rata de bits cae
128.62 kbps por cada metro que se aleja N2.
Para calcular los rangos de distancia en los que el rendimiento de las tarjetas es
óptimo, se hace analogía con la teoría de filtros, en donde la frecuencia de corte
(Fc) es la frecuencia a la cual la potencia corresponde al 70.7% de la máxima
potencia. Ya que nuestro canal (aire con obstáculos) se comporta como un filtro,
se estima que el rango de distancia entre nodos para un óptimo desempeño de la
tarjeta (Do) es la distancia en la que la rata de bits (Rb) corresponde al 70.7% de
la máxima rata de bits. De esta manera cada variante de obstáculos tendrá su
correspondiente Do, como se muestra a continuación:
• LV: Rb = 234.44 kbps Do ≅ 8.5 m
• LVP: Rb = 233.98 kbps Do ≅ 8.5 m
• M: Rb = 234.39 kbps Do ≅ 6.5 m
• MP: Rb = 234.15 kbps Do ≅ 6.5 m
Se puede concluir entonces que para LV y M, los rangos de distancia entre los
nodos para un óptimo desempeño (Do) son 8.5 m y 6.5 m respectivamente,
además, no dependen de la cobertura plástica que en un eventual caso puedan
presentar las tarjetas BlueBoard_UV01 y BlueBoard_UV02. Los efectos de
atenuación de la señal de radio se hacen notables para distancias superiores al
rango de distancia entre los nodos para un óptimo desempeño (Do).

5.1.4 Estabilidad de la velocidad de transmisión respecto a la distancia y los
obstáculos entre los nodos
Es interesante también analizar para cada una de las variantes de obstáculos, la
estabilidad en la velocidad de transmisión a medida que aumenta la distancia.
Para este fin se utilizó el porcentaje de variación ya que este es una medida
relativa de la dispersión de los datos para cada distancia respecto a la rata de bits
promedio correspondiente. Las tablas 5-5, 5-6, 5-7 y 5-8, muestran los porcentajes
de variación para cada distancia y variante de obstáculos.
Tabla 5-5. Porcentaje de Variación del Promedio de la rata de Bits con LV
Línea de Vista entre los Nodos
Distancia (m) Porcentaje de Variación (%)
0 0.43
1 0.62
2 0.60
4 0.50
6 0.77
8 1.88
10 7.90
12 14.36
Tabla 5-6. Porcentaje de Variación del Promedio de la rata de Bits con M
Pared de Madera entre los Nodos
Distancia (m) Porcentaje de Variación (%)
0 0.47
2 0.77
4 2.36
6 11.42

Tabla 5-7. Porcentaje de Variación del Promedio de la rata de Bits con MP
Pared de Madera entre los Nodos
Cada Tarjeta dentro de una Caja Plástica
Distancia (m) Porcentaje de Variación (%)
0 0.62
2 0.52
4 2.51
6 4.12
7 8.79
Tabla 5-8. Porcentaje de Variación del Promedio de la rata de Bits con LVP
Línea de Vista entre los Nodos
Cada Tarjeta dentro de una Caja Plástica
Distancia (m) Porcentaje de Variación (%)
0 0.58
1 1.70
2 0.44
4 0.58
6 0.55
8 6.27
10 21.56
La Figura 5-3 muestra para cada una de las variantes de obstáculos mencionadas
(LV, M, MP, LVP) el porcentaje de variación de la rata de bits en función de la
distancia entre los nodos.

Figura 5-3. Porcentaje de variación de la rata de Bits Vs. Distancia
Porcentaje de Variación (%)
25
20
15
10
5
0
Porcentaje de Variación de la rata de Bits Vs. Distancia
0 1 2 3 4 5 6 7 8 9 10 11 12
Distancia (m)
Línea de Vista entre
los Nodos
Pared de Madera
entre los Nodos
Pared de Madera
entre los Nodos y
Tarjetas en caja
Plástica
Línea de Vista entre
los Nodos yTarjetas
en Caja Plástica
El porcentaje de variación brinda una buena estimación de qué tan dispersa está
la velocidad de los paquetes de datos enviados para una distancia y obstáculos
fijos respecto a la velocidad promedio calculada para cada caso. El análisis de la
Figura 5-3 se enfoca en los siguientes puntos:
• La dispersión de la rata de bits debido a los obstáculos
• La dispersión de la rata de bits debido a la distancia entre los nodos
• La conjunción de las dos anteriores
� Dispersión de la rata de bits debido a los obstáculos
• La dispersión de la rata de bits hasta los 2 m de distancia entre los
nodos es la misma sin importar la presencia de obstáculos, con un
porcentaje de variación promedio de 0.7 %.

• La mayor dispersión se presenta cuando entre los nodos hay una pared
de madera que los ubica en cubículos separados
• La menor dispersión se da cuando hay línea de vista entre los nodos
• Es mayor la dispersión causada por la pared de madera que la debida a
las cajas plásticas
� Dispersión de la rata de bits debido a la distancia entre los nodos
• Mayor dispersión registrada: 21.56 % a una distancia de 10 m, con
línea de vista entre los nodos y las tarjetas dentro de una caja plástica
• Menor dispersión registrada: 0.43 % a una distancia de 0 m, con línea
de vista entre los nodos
� Dispersión de la rata de bits debido a los obstáculos y a la distancia
Para cada variante de obstáculos, después de cierta distancia, el porcentaje de
variación de la rata de bits aumenta linealmente con una pendiente distinta para
cada caso de la siguiente manera:
• LV: a partir de los 8 m aumenta con una pendiente de 3.12 % / m
• M: a partir de los 4 m aumenta con una pendiente de 4.65 % / m
• MP: a partir de los 6 m aumenta con una pendiente de 4.68 % / m
• LVP: a partir de los 8 m aumenta con una pendiente de 7.65 % / m
De esta manera LV tiene la menor pendiente ya que el porcentaje de
variación aumenta 3.12 % por cada metro que se aleja el nodo móvil N2
después de los 8 m; a partir de esta distancia la mayor pendiente se presenta
para LVP, ya que el porcentaje de variación de la rata de bits aumenta 7.65
% por cada metro que se aleja N2. Cabe anotar que para M y MP el aumento
considerable en la dispersión de la rata de bits se da a distancias menores (4
m y 6 m respectivamente) que las registradas para LV y LVP.

Para los rangos de distancia entre nodos para un óptimo desempeño (Do)
calculados en el ítem 5.1.1, se encuentra el promedio del porcentaje de variación
para cada escenario de prueba (ver Tabla 5-9).
La Tabla 5-9 muestra para cada rango de distancia Do, el porcentaje de variación
promedio de la rata de bits.
Tabla 5-9. Porcentaje de Variación Promedio para cada Do
Variante de Obstáculos Do (m)
LV
LVP
M
MP
Porcentaje de Variación
Promedio (%)
8.5 0.8
8.5 1.69
6.5 3.76
6.5 1.94
Rata de bits promedio
(kbps) para Do
316.2
314.2
299.4
294.6
5.2 IMPLEMENTACIÓN DE UNA RED DE AREA PERSONAL
BLUETOOTH
El objetivo final de esta tesis es la implementación de una red de área personal
Bluetooth. Esta implementación recopila todos los conceptos que se han tratado a
lo largo de este documento, siendo una excelente aplicación demostrativa que nos
muestra los alcances y proyecciones de esta tecnología. El perfil de red de área
personal de Bluetooth (PAN Profile) para esta demostración es el de Grupo de red
Ad-hoc o GN (Group Ad-hoc Networks). La PAN consta de tres nodos (GN,

PANU1 y PANU2), cada uno conformado por una tarjeta Blueboard_UV conectada
a un PC a través de una interfaz USB. La arquitectura de la red de área personal
implementada, se puede observar en la Figura 5-4.
Figura 5-4. Arquitectura de la red de área personal
5.2.1 Configuración de la PAN
� Hardware
• GN y PANU2: cada uno corresponde a un PC DELL Pentium III con una
tarjeta BlueBoard_UV02 conectada a través del puerto USB.
• PANU1: corresponde a un PC Genérico Pentium II, el cual tiene
conectada una tarjeta BlueBoard_UV01 a través del puerto USB.

• Cada tarjeta está equipada con un módulo Bluetooth Ericsson
ROK101007/21E.
� Software
• GN: sistema operativo Linux RedHat 7.0, Kernel 2.4.18 habilitadas las
opciones “network filter”, “iptable”, “NAT”, “802.1d ethernet bridge”, e
instalados los paquetes de Affix y el paquete bridge-utils-0.9.6 (paquete
de utilidades para bridge). Este nodo se configura como un servidor de
Telnet.
• PANU1: sistema operativo Linux RedHat 8.0, Kernel 2.4.18, instalados
los paquetes de Affix y cliente Telnet.
• PANU2: sistema operativo Linux RedHat 7.0, Kernel 2.4.19, instalados los
paquetes de Affix y el cliente telnet.
� Dirección Bluetooth de GN: 00:80:37:15:C9:67
� Dirección Bluetooth de PANU1: 00:80:37:15:C9:64
� Dirección Bluetooth de PANU2: 00:80:37:15:C9:66
• Dirección IP de GN: 10.0.0.1
• Dirección IP de PANU1: 10.0.0.2
• Dirección IP de PANU2: 10.0.0.3
5.2.2 Ethernet Bridging
Un bridge, es un puente que sirve para unir dos o más interfaces de red (tarjetas
de red - NICs) para que el tráfico fluya entre ellas de manera libre y en forma
transparente. De esta manera se puede conectar un PC a la LAN como si este
fuera un hub o un switch. Los PCs detrás del bridge no lo verán y el tráfico fluirá
en forma transparente [38]. Affix y Bluez utilizan el 802.1d ethernet bridge y el
paquete de utilidades bridge-utils-0.9.6 disponible en Internet [39], únicamente

para combinar, en una sola interfaz, interfaces de red separadas. Se puede
encontrar fácilmente en Internet tutoriales, guías de Instalación y configuración del
bridge, tanto en inglés [40] como en español [38].
Los pasos que se muestran a continuación, para la configuración de una red de
área personal basada en Affix, siguen un modelo tomado del documento
DEMONSTRATE THE PAN IN LINUX SYSTEM [40], siendo adaptados a los
recursos disponibles en este proyecto. Para cada uno de los casos, los módulos
de Affix deben estar correctamente cargados.
5.2.3 Nodo maestro GN
� Se define el bridge con el nombre br0 (puede tener cualquier nombre no
necesariamente este):
[root@localhost.localdomain]# brctl addbr br0
[root@localhost.localdomain]# ifconfig br0 10.0.0.1
� Se deshabilita las características inteligentes del 802.1d ethernet bridge:
protocolo STP (spanning tree protocol) y los estados de aprendizaje y
atención. Como resultado el puente se activará instantáneamente después de
que la interfaz pan0 de Affix haya sido creada. Si no se hacen estas llamadas
el establecimiento puede tomar unos 30 s, dependiendo de la complejidad de
la red [42]:
[root@localhost.localdomain]# brctl setfd br0 0
[root@localhost.localdomain]# brctl stp br0 disable

� Se crea la interfaz pan0 de Affix
[root@localhost.localdomain]# btctl paninit gn bt0
� Se añade pan0 al bridge y se configura su dirección IP en 0.0.0.0 para que
sea transparente
[root@localhost.localdomain]# brctl addif br0 pan0
[root@localhost.localdomain]# ifconfig pan0 0.0.0.0
� Para revisar el estado actual del bridge, se escribe:
[root@localhost.localdomain]# brctl show
� Para mirar una lista de las conexiones remitidas sobre el bridge, se escribe:
[root@localhost.localdomain]# brctl showmacs
5.2.4 Nodos esclavos PANU1 y PANU2
La configuración de estos nodos difiere únicamente de la dirección IP asignada a
cada uno. Se ha de seguir el mismo procedimiento para cada caso con las
direcciones IP correspondientes:
� Se crea la interfaz pan0 de Affix
[root@localhost.localdomain]# btctl paninit panu bt0
� Se configura la dirección IP para cada interfaz de Affix
En PANU1: [root@localhost.localdomain]# ifconfig pan0 10.0.0.2
En PANU2: [root@localhost.localdomain]# ifconfig pan0 10.0.0.3
� Para revisar la correcta configuración de las interfaces de red, se escribe:
[root@localhost.localdomain]# ifconfig

� Ahora es necesario definir la ruta por defecto para la interfaz de Affix creada:
[root@localhost.localdomain]# route add default gw 10.0.0.1
� Se debe verificar el estado de la tabla de enrutamiento escribiendo:
[root@localhost.localdomain]# route
En este punto se tiene ya establecida una red de tres nodos, TCP/IP sobre
Bluetooth. Desde el Nodo maestro GN, se escribe en la línea de comandos:
[root@localhost.localdomain]# ping 10.0.0.2
PING 10.0.0.2 (10.0.0.2) from 10.0.0.1 : 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=143 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=74.2 ms
[root@localhost.localdomain]# ping 10.0.0.3
PING 10.0.0.3 (10.0.0.2) from 10.0.0.1 : 56(84) bytes of data.
64 bytes from 10.0.0.3: icmp_seq=1 ttl=64 time=144 ms
64 bytes from 10.0.0.3: icmp_seq=2 ttl=64 time=75.2 ms
Esto permite probar la existencia de la red TCP/IP, donde Bluetooth es
transparente. En teoría cualquier servicio IP disponible en la red (telnet, ftp,
servicios web, etc.) debería accederse desde otro nodo de la misma red.
5.3 Software bluetooth para sistemas embebidos
Esta sección hace referencia al proyecto BTnode rev 2.2 [43], conjuntamente
desarrollado por el laboratorio de redes e Ingeniería de la computación TIK [44] y
el Grupo de investigación para sistemas distribuidos [45] pertenecientes al Instituto

federal Suizo de tecnología con sede en Zurich [46]. Este proyecto puede ser de
gran ayuda para futuras tesis interesadas en el desarrollo de sistemas autónomos
inalámbricos y plataformas embebidas basadas en microcontrolador y que utilicen
interfaz Bluetooth.
BTnode tiene las siguientes características:
� Microcontrolador: Atmel Atmega 128 L
� Memoria: RAM de 64 kbyte, Flash ROM de 128 kbyte y 4 kbyte de EEPROM.
� Módulo Bluetooth ROK 101 007 de Ericsson
El sitio en Internet de este proyecto [43] ofrece documentación completa sobre el
diseño del Hardware, herramientas de desarrollo para software (versiones para
linux y windows), código fuente y archivos binarios del stack embebido para el
sistema BTnode y entre otras cosas una lista de correos para los interesados y
colaboradores de este proyecto.

CONCLUSIONES
En este proyecto se ha implementado satisfactoriamente una red inalámbrica
Bluetooth de tres nodos, dentro de un rango de 10 m y utilizando las tarjetas
BlueBoard_UV desarrolladas. La comunicación se hizo usando tres PC´s mediante
el uso de los stack Bluez y Affix, los cuales ofrecen herramientas que permitieron
realizar y verificar diferentes conceptos de esta tecnología inalámbrica.
Se estudió detalladamente la versión 1.0b de la especificación Bluetooth, así como
los stack de protocolos Affix y Bluez. Los conceptos de Bluetooth adquiridos
fueron esenciales para el desarrollo de este proyecto y se aplicaron
específicamente en la implementación de la red inalámbrica Bluetooth, principal
objetivo planteado.
Se ha podido investigar y analizar ampliamente el mercado de circuitos integrados
y sistemas embebidos Bluetooth encontrándose que la cantidad y diversidad de
productos disponibles en el mercado son muy amplias, al igual que el número de
fabricantes que los ofrecen. La Información detallada al respecto se puede
encontrar en el CD-ROM adjunto.
A lo largo del proyecto, se han podido corroborar las principales ventajas de la
tecnología Bluetooth tales como tamaño reducido y bajo consumo de potencia. No
se puede afirmar lo mismo acerca del bajo costo, ya que realmente no es aplicable
en este momento en Colombia debido a que la mayor parte de los dispositivos

equeridos para el desarrollo o compra de sistemas Bluetooth no está disponible
en nuestro país, incrementando los costos. A la fecha (Agosto/2003), la circuitería
necesaria para la implementación de una tarjeta BlueBoard_UV es de
aproximadamente US $200.
Las arquitecturas utilizadas por Affix y Bluez para implementar las capas
superiores del stack de protocolos Bluetooth son muy similares y se basan en
conceptos del subsistema de red de linux (como el de socket Berkeley entre
otros), usados por los drivers de los dispositivos de red independientemente del
protocolo que utilicen (Ethernet, X.25, etc).
Para lograr que una red de dispositivos Bluetooth interactúe con otras tecnologías
como Ethernet, Token Ring, ATM, etc., y además brinde y utilice los servicios
TCP/IP que estén disponibles en la red, existen el protocolo de encapsulamiento
de red BNEP de Bluetooth y el perfil PAN. Para lograr esto, Affix y Bluez, se valen
del estándar IEEE 802.1d ethernet bridge, implementado por Linux y utilizado para
unificar en el nodo maestro las interfaces de red de Bluetooth en una sola interfaz
la cual a su vez puede servir de puente hacia una interfaz ethernet, de tal manera
que la red Bluetooth y esta última conformen una red TCP/IP transparente a la
tecnología de transporte de datos.
Las pruebas de desempeño de las tarjetas BlueBoard_UV, realizadas en este
trabajo, revelaron valiosos datos de operación de los sistemas Bluetooth. Los
valores máximos de distancia y velocidad de transmisión y los rangos de distancia
entre nodos para un óptimo desempeño (Do) tabulados y calculados como parte
de este análisis, demuestran el buen funcionamiento de las tarjetas BlueBoard_UV
en ambientes ideales (en los que existe línea de vista entre nodos) y en ambientes

eales (tales como oficinas, plantas de producción y el hogar en los que las
condiciones de operación no permiten esta línea de vista). La cobertura plástica
propia de equipos portátiles, tales como teléfonos celulares, agendas electrónicas
y teclados, refleja su incidencia en el desempeño de las tarjetas de manera
significativa solamente para los rangos mayores a Do. Además se logró establecer
comunicación entre tarjetas BlueBoard_UV hasta una distancia máxima de 12m en
condiciones normales de operación. Información detallada de las pruebas
efectuadas, se puede encontrar en el capítulo 5 de este documento.
El conjunto de interfaces de las tarjetas BlueBoard_UV01 y BlueBoard_UV02
(USB, UART, I2C y PCM), hacen de éstas sistemas muy flexibles y completos que
facilitan la integración de la tecnología, en general, a cualquier sistema
microprocesado o microcontrolado. Las capas superiores del stack de protocolos
Bluetooth en sus versiones para PC y sistemas embebidos se encuentran
disponibles en internet bajo licencia GPL, ya sea para su directa utilización o para
ser tomados como modelo de referencia para el desarrollo de stacks más
sencillos y dedicados a aplicaciones específicas. Las aplicaciones donde pueden
utilizarse las tarjetas son ilimitadas, ofreciendo muchas posibilidades para futuros
proyectos. Un ejemplo sería la implementación de un sistema microprocesado o
microcontrolado que contenga las capas superiores del stack Bluetooth (host
stack) no contenidas en las tarjetas BlueBoard_UV. Este sistema interconectado
con una tarjeta BlueBoard_UV conformaría un sistema embebido muy flexible y útil
para aplicaciones específicas tales como redes de sensores y actuadores
inalámbricos.

REFERENCIAS
[1] BLUETOOTH SPECIAL INTEREST GROUP. Disponible en Internet: < URL:
http://www.bluetooth.com >.
[2] MINISTERIO DE COMUNICACIONES DE COLOMBIA.
CuadroAtribucion.pdf [Archivo PDF], Disponible en Internet: < URL:
http://www.mincomunicaciones.gov.co >.
[3] BLUETOOTH SPECIAL INTEREST GROUP. “Bluetooth Core”,
Specification of the Bluetooth System, Versión 1.1, 22 de Febrero de 2003.
Disponible en Internet: < URL: http:
http://www.bluetooth.com/dev/specifications.asp >.
[4] BLUETOOTH SPECIAL INTEREST GROUP. “Bluetooth Profiles”,
Specification of the Bluetooth System, Versión 1.1, 22 de Febrero de 2003.
Disponible en Internet: < URL: http://
www.bluetooth.com/dev/specifications.asp >.
[5] Disponible en Internet: < URL: http:// www.teleca.com, http://
www.comtec.teleca.se >.
[6] Disponible en Internet: < URL: http:// www.suyin.de >.
[7] Disponible en Internet: < URL: http:// www.rangestar.com >.

[8] Disponible en Internet: < URL: http:// www.national.com >.
[9] Disponible en Internet: < URL: http:// www.maxim-ic.com >.
[10] Disponible en Internet: < URL: http:// www.csr.com >.
[11] Disponible en Internet: < URL: http:// www.bluefrogsolution.com >.
[12] Disponible en Internet: < URL: http:// www.national.com/bluetooth >.
[13] Disponible en Internet: < URL: http:// www.atmel.com >.
[14] Disponible en Internet: < URL: http:// www.digianswer.com >.
[15] Disponible en Internet: < URL: http:// www.3com.com >.
[16] Disponible en Internet: < URL: http:// www.smartm.com >.
[17] Disponible en Internet: < URL: http:// www.anoto.com >.
[18] Disponible en Internet: < URL: http:// www.motorola.com >.
[19] Disponible en Internet: < URL: http:// qualweb.opengroup.org >.
[20] M. Ali and G. J. Hayes, “Analysis of Integrated-F Antennas for Bluetooth
Applications,” 2000 IEEE-APS Conference on Antennas and Propagation for
Wireless Communications, November 2000.

[21] R. Wansch, H. Humpfer, and J. Hupp, “An Integrated F-Antenna for
Diversity Reception in a DECT Data Transmission Module,” IEEE Antennas
Propagation Society International Symposium, July 2000.
[22] MEZOE, Cambridge Consultants Ltd. BlueStack User Manual, 2001, p. 20 –
22. Disponible en Internet: < URL: http://www.mezoe.com >.
[23] ERICSSON MOBILE COMMUNICATIONS. Bluetooth HOST Stack,
HostSW0601.pdf [Archivo PDF], Lund (Sweden), Octubre de 2000.
Disponible en Internet: < URL: http://www.ericsson.com/bluetooth/ >.
[24] DIGIANSWER. Bluetooth MkII Democard, productsheet-dc-mk2.pdf [Archivo
PDF]. Disponible en Internet: .
[25] Heuser, Werner. Laptops, Bluetooth(TM) and Linux, 23 de Abril de 2003.
Disponible en Internet: .
[26] AXIS, Código fuente de OpenBt [Archivo tar.gz]. Disponible en Internet:
.
[27] AXIS, Portal en Internet: < URL:
http://developer.axis.com/software/bluetooth/>.
[28] IBM, Sitio de Internet de Alpha Works: < URL:
http://www.alphaworks.ibm.com/tech/bluedrekar>.
[29] AFFIX, portal en Internet: < URL: http://affix.sourceforge.net>.

[30] BlueZ, disponible en Internet: .
[31] KASATKIN, Dmitri. Affix in a Nutshell, Nokia Corporation, 2001-2002.
Disponible en Internet: [Formato html]: < URL:
http://affix.sourceforge.net/affix-doc/index.html >. [Formato PDF]: < URL:
http://affix.sourceforge.net/affix-doc/affix-doc.pdf >.
[32] UNIX Networking Programming, Volúmen 1: Networking APIs - Sockets and
XTI, Prentice Hall, 17 de Octubre de 1997.
[33] BEUTEL, Jan y KRASNYANSKIY, Maksim. Linux BlueZ Howto, 14 de
Noviembre de 2001. Disponible en Internet [En línea]: < URL:
http://bluez.sourceforge.net/howto/index.html >.
[34] BLUETOOTH SPECIAL INTEREST GROUP. Personal Area Networking
Profile. Specification of the Bluetooth System, Versión 1.0, 14 de Febrero de
2003. Disponible en Internet: < URL:
http://www.bluetooth.com/dev/specifications.asp>.
[35] BLUETOOTH SPECIAL INTEREST GROUP. Bluetooth Network
Encapsulation Protocol (BNEP) Specification. Specification of the Bluetooth
System, Versión 1.0, 14 de Febrero de 2003. Disponible en Internet: < URL:
http://www.bluetooth.com/dev/specifications.asp>.
[36] Disponible en Internet: < URL: http://
http://www.iana.org/assignments/ethernet-numbers >.

[37] DIGITAL EQUIPMENT CORPORATION, INTEL CORPORATION, XEROX
CORPORATION. The Ethernet – A Local Area Network, Versión 1.0.
Septiembre de 1980.
[38] BÉJAR, Eduardo. Linux Ethernet Bridge, Guia de Instalación, 8 de
Noviembre de 2002. Disponible en Internet: < URL:
http://www.linkabu.net/linux/ >.
[39] Código fuente del paquete bridge-utils. Disponible en Internet: < URL:
http://bridge.sourceforge.net/download.html>.
[40] Layer 2 ethernet bridging with Linux, 7 de Noviembre de 2001. Disponible
en Internet: < URL: http://bridge.sourceforge.net/>.
[41] Demonstrate the PAN in Linux system. Disponible en Internet [Formato
html]: < URL: http://affix.sourceforge.net/archive/PAN/affix_pan_demo.html >
[Formato pdf]: < URL:
http://affix.sourceforge.net/archive/PAN/aff_pan_dem.pdf>.
[42] SCHMIDT, Michael. HowTo set up common PAN scenarios with BlueZ's
integrated PAN support. University of Siegen, Germany. Disponible en
Internet: < URL: http://bluez.sourceforge.net/contrib/HOWTO-PAN>.
[43] BTnod rev 2.2 project. Disponible en Internet: < URL:
http://www.inf.ethz.ch/vs/res/proj/smart-its/btnode.html#sw>.
[44] Computer Engineering and Networks Laboratory (tik). Sitio en Internet
disponible en: < URL: http://www.tik.ee.ethz.ch/>.

[45] Research Group for Distributed Systems. Sitio en Internet disponible en: <
URL: http://www.inf.ethz.ch/vs/>.
[46] Swiss Federal Institute of Technology Zurich. Sitio en Internet disponible en:
< URL: http://www.ethz.ch/>.