Documentos de Académico
Documentos de Profesional
Documentos de Cultura
TG OscarRodriguez RicardoMaya
TG OscarRodriguez RicardoMaya
BLUETOOTH
Director
FABIO G. GUERRERO MORENO
___________________________________
___________________________________
___________________________________
___________________________________
___________________________________
___________________________________
___________________________________
Director: Fabio G. Guerrero Moreno
___________________________________
Jurado: Asfur Baradica López
___________________________________
Jurado: Oscar Polanco Sarmiento
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.
pág.
INTRODUCCIÓN 22
1.1.4 Paquetes. 31
1.1.6 Transmisión/Recepción. 34
1.4.1 Canales. 43
1.4.4 Eventos. 45
1.4.5 Acciones. 45
1.5.3 El protocolo. 47
1.6 RFCOMM 49
BLUETOOTH 88
6. CONCLUSIONES 147
REFERENCIAS
LISTA DE FIGURAS
pág.
Figura 1-11. Diagrama general end to end de las capas de software más bajas 42
Hardware 87
Figura 4-1. Ubicación del BNEP dentro de la Torre de protocolos de Bluetooth. 110
BNEP_COMPRESSED_ETHERNET 115
BNEP_COMPRESSED_ETHERNET_SOURCE_ONLY 115
BNEP_COMPRESSED_ETHERNET_DEST_ONLY 116
Figura 4-9. Ejemplo del envío de un paquete IPv4 usando BNEP entre un dispositivo con
Figura 4-17. Stack para un enlace en una red Ad-hoc Bluetooth 125
pág.
Tabla 4-1. Valores para el campo BNEP Type el cual define el tipo de paquete BNEP 112
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
DRIVER: controlador que permite gestionar los periféricos que están conectados
al ordenador (http://www.guiahost.com/servicios/glosario).
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).
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.
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.
I2C: 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.
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.
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).
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 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
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.
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].
• Carga útil. La carga útil de un paquete puede ser dividida en dos campos:
• 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.
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].
• 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.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.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
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.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.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.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.
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.
Banda Base: Se usa una estructura de red ad-hoc con un número máximo de
ocho unidades activas en una sola piconet.
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.
• 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.”
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.
• 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.
ANTENA RANGESTAR
Bluetooth, 802.11b
Aplicaciones Teléfonos móviles, dispositivos portátiles, PDAs, aplicaciones
industriales, instrumentos.
Rango de Frecuencia
2400 - 2483.5
(MHz)
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
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
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.
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).
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].
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.
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.
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.
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.
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.
Paquete affix-kernel. Los siguientes son los pasos para compilar e instalar
affix-kernel:
Paquete affix
Para compilar e instalar el paquete affix se deben seguir los siguientes pasos:
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:
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.
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.
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
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
Reservado para los Paquetes LLC de 802.2 por IEEE 802.15.1
0x7F
WG
Paquete BNEP Depende del valor que se haya consignado en el campo del
Tipo de BNEP.
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.
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.
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
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.
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:
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í:
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
250
Pared de Madera
entre los Nodos
200
Distancia (m)
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:
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-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
20
Pared de Madera
entre los Nodos
15
Pared de Madera
entre los Nodos y
10 Tarjetas en caja
Plástica
Línea de Vista entre
5 los Nodos yTarjetas
en Caja Plástica
0
0 1 2 3 4 5 6 7 8 9 10 11 12
Distancia (m)
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 Tabla 5-9 muestra para cada rango de distancia Do, el porcentaje de variación
promedio de la rata de bits.
316.2
LV 8.5 0.8
314.2
LVP 8.5 1.69
299.4
M 6.5 3.76
294.6
MP 6.5 1.94
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
Para mirar una lista de las conexiones remitidas sobre el bridge, se escribe:
[root@localhost.localdomain]# brctl showmacs
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
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.
[39] Código fuente del paquete bridge-utils. Disponible en Internet: < URL:
http://bridge.sourceforge.net/download.html>.
[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>.
[46] Swiss Federal Institute of Technology Zurich. Sitio en Internet disponible en:
< URL: http://www.ethz.ch/>.