Arquitectura de protocolos Bluetooth
La pila de protocolos Bluetooth
La pila o stack de protocolos Bluetooth
se basa en el modelo de referencia OSI (Open System Interconnect) de
ISO (Internacional Standard Organization) para interconexión de
sistemas abiertos. La especificación Bluetooth utiliza una arquitectura
de protocolos que divide las diversas funciones de red en un sistema de
niveles. En conjunto, permiten el intercambio transparente de
información entre aplicaciones diseñadas de acuerdo con dicha
especificación y fomentan la interoperabilidad entre los productos de
diferentes fabricantes.
La pila de protocolos Bluetooth se divide en dos zonas, cada una de las
cuales se implementa en distintos procesadores:
- El módulo Bluetooth (hardware), encargado de las tareas relacionadas con el envío de información a través del interfaz de radiofrecuencia.
- El host Bluetooth (software), encargado de la parte relacionada con las capas superiores de enlace y aplicación.
Ambas zonas están comunicadas por el Interfaz de Controlador
de Host (HCI).
Sobre la capa de protocolos específicos de Bluetooth, cada fabricante
puede implementar su capa de protocolos de aplicación propietarios. De
esta forma, la especificación abierta de Bluetooth expande enormemente
el número de aplicaciones que pueden beneficiarse de las capacidades
que ofrece esta tecnología inalámbrica. Sin embargo, la especificación
Bluetooth exige que, a pesar de la existencia de diferentes pilas de
protocolos de aplicación propietarios, se mantenga la interoperabilidad
entre dispositivos que implementen diferentes pilas.
Las pilas de protocolos Bluetooth más conocidas son Widcomm, Toshiba
Bluetooth Stack, Microsoft Windows XP Bluetooth y IVT BlueSoleil Stack.
Linux dispone de las pilas de protocolos Bluetooth BlueZ, OpenBT y
Affix, de Nokia.
Capa de banda base e interfaz de radio
En la base de la pila de protocolos Bluetooth se encuentran
la capa de banda base y el interfaz de radio. Su función principal es
permitir el enlace físico por radiofrecuencia (RF) entre unidades
Bluetooth dentro de una picorred realizando tareas de modulación y
demodulación de los datos en señales RF que se transmiten por el aire.
El nivel de banda base proporciona los dos tipos de enlace físico:
- Enlace asíncrono sin conexión (ACL, Asynchronous
Connectionless):
- Conexiones simétricas o asimétricas punto-multipunto entre maestro y esclavo.
- Conexión utilizada para tráfico de datos.
- Sin garantía de entrega, se retransmiten paquetes.
- La máxima velocidad de envío es de 721 Kbps en una
dirección 57.6 Kbps en la otra.
- Enlace síncrono orientado a conexión (SCO, Synchronous
Connection-Oriented):
- Conexiones simétricas punto a punto entre maestro y esclavo.
- Conexión capaz de soportar voz en tiempo real y tráfico multimedia.
- Velocidad de transmisión de 64 KB/s
Capa de Protocolo de Gestión de Enlace (LMP)
LMP (Link Manager Protocol) es el responsable de la
configuración y control de enlace entre dispositivos Bluetooth,
incluyendo el control y negociación del tamaño de los paquetes de banda
base.
Cuando dos dispositivos Bluetooth se encuentran dentro del radio de
acción del otro, el gestor de enlace (Link Manager) de cada dispositivo
se comunica con su homólogo por medio de mensajes a través del
protocolo LMP. Estos mensajes realizan el establecimiento del enlace
entre ambos dispositivos, incluyendo mecanismos de seguridad tales como
la autenticación y cifrado, que comprende la generación, intercambio y
comprobación de claves de enlace y de cifrado. Por medio de este
intercambio de mensajes, LMP también controla los modos de
administración de energía y los ciclos de trabajo de los dispositivos
de radio Bluetooth, así como los estados de conexión de las unidades
Bluetooth situadas dentro de una piconet. El gestor de enlace filtra e
interpreta estos mensajes y no los propaga hacia los niveles
superiores.
El gestor de enlace es un módulo software que se ejecuta en un
microprocesador dentro de la unidad Bluetooth para gestionar la
comunicación entre dispositivos. Cada dispositivo Bluetooth tiene su
propio gestor de enlace, que se encarga de descubrir otros gestores de
enlace remotos y comunicarse con los mismos para gestionar el
establecimiento del enlace, la autenticación, la configuración y otras
funciones.
Para realizar su papel de proveedor de servicios, el gestor de enlace
hace uso de las funciones que ofrece el controlador de enlace (LC, Link
Controller) subyacente, un módulo de supervisión que maneja todas las
funciones de la banda base de Bluetooth y da soporte al gestor de
enlace. El controlador de enlace envía y recibe datos, solicita la
identificación del dispositivo emisor, autentica el enlace, establece
el tipo de enlace SCO o ACL y determina el tipo de trama a utilizar en
cada paquete.
Los mensajes que se intercambian entre los gestores de enlace toman la
forma de unidades de datos de protocolo (PDU, Protocol Data Unit).
Estos datos tienen una prioridad más alta que los datos del usuario,
para que un mensaje que el gestor de enlace necesite enviar no se vea
retardado por el tráfico L2CAP.
Capa de Interfaz de Controlador de Host (HCI)
La capa HCI (Host Controller Interface) actúa como frontera
entre las capas de protocolo relativas al hardware (módulo Bluetooth) y
las relativas al software (host Bluetooth). Proporciona una interfaz de
comandos para la comunicación entre el dispositivo y el firmware del
módulo Bluetooth y permite disponer de una capa de acceso homogénea
para todos los módulos Bluetooth de banda base, aunque sean de
distintos fabricantes.
Una de las tareas más importantes del interfaz HCI es el descubrimiento
de dispositivos Bluetooth que se encuentren dentro del radio de
cobertura. Esta operación se denomina consulta o inquiry
y funciona del siguiente modo:
- Inicialmente, el dispositivo origen envía paquetes inquiry y se mantiene en espera de recibir respuestas de otros dispositivos presentes en su zona de cobertura.
- Si los dispositivos destino están configurados en modo visible (discoverable) se encontrarán en estado inquiry_scan y en predisposición de atender estos paquetes. En este caso, al recibir un paquete inquiry cambiarán a estado inquiry_response y enviarán una respuesta al host origen con sus direcciones MAC y otros parámetros.
- Los dispositivos que estén configurados en modo no visible (non discoverable) se encontrarán en modo inquiry_response y, por tanto, no responderán al host origen y permanecerán ocultos.
La pila de protocolos BlueZ para Linux dispone de dos herramientas que permiten realizar funciones específicas del interfaz HCI:
- La herramienta Hciconfig
permite configurar el interfaz del módulo Bluetooth conectado al
dispositivo.
- La herramienta Hcitool
permite realizar operaciones relativas a la gestión de enlace con otros
dispositivos Bluetooth, tales como enviar paquetes inquiry
para la detección de equipos cercanos, resolución de nombres,
identificación de clases, etc.
Direccionamiento de dispositivos Bluetooth
Al
igual que en otros estándares de comunicaciones IEEE 802, Bluetooth
utiliza direcciones MAC de 6 bytes para el direccionamiento de equipos
a nivel de red. De esta forma, un dispositivo queda identificado
unívocamente por su dirección MAC, comúnmente denominada BD_ADDR.
Capa de Protocolo de Adaptación y Control del Enlace Lógico (L2CAP)
La especificación Bluetooth incluye el protocolo L2CAP
(Logical Link Control and Adaptation Protocol), que se encarga de la
multiplexación de protocolos, ya que el protocolo de banda base no
soporta un campo tipo para identificar el
protocolo de nivel superior al que quiere transmitir la información,
por ejemplo SDP, RFCOMM y TCS.
Otra función que se realiza en el nivel L2CAP es la segmentación y
recomposición de paquetes, necesaria para permitir la utilización de
protocolos que utilicen paquetes de mayor tamaño que los soportados por
la capa de banda base. Los paquetes L2CAP de gran tamaño se deben
segmentar en múltiples paquetes de formato banda base más pequeños
antes de su transmisión. En el lado del receptor, los paquetes de banda
base se recomponen en paquetes L2CAP más grandes tras comprobar su
integridad.
El proceso de establecimiento de la conexión L2CAP también permite el
intercambio de información referente a la calidad de servicios (QoS)
que se espera entre dos dispositivos Bluetooth. La implementación L2CAP
en cada uno de los extremos controla los recursos utilizados por el
protocolo y se asegura de que se cumplen los contratos de calidad de
servicio.
La especificación L2CAP está definida únicamente para enlaces
asíncronos sin conexión (ACL) y no puede existir más que un enlace
entre dos dispositivos.
Capa de Protocolo de Descubrimiento de Servicios (SDP)
El descubrimiento de servicios hace referencia a la capacidad
de buscar y encontrar servicios disponibles en dispositivos Bluetooth.
A través de los servicios, dos dispositivos pueden ejecutar
aplicaciones comunes e intercambiar datos.
El protocolo SDP (Service Discovery Protocol) permite a una aplicación
cliente obtener información sobre servidores SDP disponibles en otros
dispositivos Bluetooth cercanos, enumerar los servicios que ofrecen y
las características de dichos servicios. Después de haber localizado
los servicios disponibles en un dispositivo, el usuario puede elegir
aquel de ellos que resulte más apropiado para el tipo de comunicación
que desea establecer.
Un servicio es cualquier entidad que puede ofrecer información,
ejecutar una acción o controlar un recurso. Un servicio puede estar
implementado como hardware, software o una combinación de hardware y
software.
Services Classes
Un servicio concreto soportado por cierto dispositivo es una instancia de un Service Class o clase de servicio. El Service Class describe los servicios genéricos soportados por un dispositivo:
- Positioning (Location identification)
- Networking (LAN, Ad hoc, ...)
- Rendering (Printing, Speaker, ...)
- Capturing (Scanner, Microphone, ...)
- Object Transfer (v-Inbox, v-Folder, ...)
- Audio (Speaker, Microphone, Headset service, ...)
- Telephony (Cordless telephony, Modem, Headset service, ...)
- Information (WEB-server, WAP-server, ...)
Para dar a conocer los servicios genéricos que soporta un
dispositivo Bluetooth, este incorpora en la cabecera de nivel de banda
base de sus paquetes un campo Class of Device/Service
que contiene información acerca de su Service Class.
Fuente:
https://www.bluetooth.org/foundry/assignnumb/document/baseband
El campo reservado para el Service Class se
compone de 11 bits, del bit 23 al 13. En la especificación de banda
base 1.1 de Bluetooth, se describe la siguiente relación entre los bits
marcados en el campo Service Class y los
servicios genéricos soportados por el dispositivo.
Fuente:
https://www.bluetooth.org/foundry/assignnumb/document/baseband
Conociendo el Class of Device/Service de un
dispositivo Bluetooth, se puede averiguar fácilmente el conjunto de
servicios genéricos soportados por el mismo.
En este ejemplo, la herramienta Hcitool
ha detectado un dispositivo cuyo Class of Device/Service
es 0x320114.
La representación de 0x320114 en binario es la siguiente:
Nº bit: 23 22 21 20 19 18 17 16 15 14 13 | 12 11 10 09 08 07 | 06 05 04
03 02 | 01 00
Valor: 0 0 1 1 0 0 1 0 0 0 0 | 0 0 0 0 1 0 | 0 0 1 0 1 | 0 0
Se observa que aparecen marcados los bits 21, 20 y 17, que, tal y como
establece la tabla Major Service Classes,
representan la disponibilidad de los siguientes servicios genéricos:
- bit 21: Audio (Speaker, Microphone, Headset service, ...)
- bit 20: Object Transfer (v-Inbox, v-Folder, ...)
- bit 17: Networking (LAN, Ad hoc, ...)
Service Record
Toda la información relacionada con un servicio que mantiene un servidor SDP está contenida en un Service Record o registro individual de servicio.
Un Service Record consiste en una lista de atributos que describen características de un servicio: Service Name, Service Description, Provider Name, Service Record Handle, Service Class ID List, Service Record State, Service ID, Protocol Description List, Browse Group List, Language Base Attribute ID List, Service Info Time To Live, Service Avaliability y Bluetooth Profile Descriptor List.
El protocolo SDP permite realizar dos tipos de operaciones relacionadas con el descubrimiento de servicios en dispositivos Bluetooth: búsqueda y enumeración de servicios.
- La operación búsqueda de servicios (Service Searching) permite a un cliente SDP encontrar dispositivos que ofrecen un servicio específico.
- La operación enumeración de servicios (Service Browsing) permite a un cliente SDP conocer los servicios ofrecidos por un determinado dispositivo.
En ambos casos, el resultado de la petición SDP devolverá al
cliente que la originó una lista de servicios descubiertos acompañada
por la definición de los mismos a través de sus Service Records.
La pila de protocolos BlueZ para Linux dispone de una herramienta de
gestión SDP llamada Sdptool
que permite llevar a cabo los dos tipos de operaciones anteriormente
descritos.
Sdptool permite
buscar dispositivos cercanos que ofrezcan un servicio específico, como
por ejemplo Puerto Serie, Manos Libres, etc.
La especificación de la herramienta Sdptool
establece los siguientes servicios disponibles para operaciones de
búsqueda: DID, SP, DUN, LAN, FAX, OPUSH, FTP, HS, HF, SAP, NAP, GN,
PANU, HID, CIP, CTP, A2SRC, A2SNK, AVRCT, AVRTG, SR1, SYNCML,
ACTIVESYNC, HOTSYNC, PALMOS, NOKIA PCSUITE.
Sdptool también
permite enumerar todos los servicios disponibles en un determinado
dispositivo.
Capa RFCOMM
El protocolo RFCOMM (Radio Frequency Communication) es un
protocolo de emulación de línea serie basado en el estándar ETSI TS
07.10. Proporciona una emulación de los puertos serie RS-232 sobre el
protocolo L2CAP.
Este protocolo de “sustitución de cable serie” emula las señales de
control y datos RS-232 sobre la banda base, proporcionando capacidades
de transporte a los servicios de niveles superiores que utilizan el
cable serie como mecanismo de transporte.
Para los propósitos de RFCOMM, un camino de comunicación directa
involucra siempre a dos aplicaciones que se ejecutan en dos
dispositivos distintos extremos de la comunicación. Entre ellos existe
un segmento que los comunica, en este caso, un enlace Bluetooth desde
un dispositivo al otro. RFCOMM pretende soportar aquellas aplicaciones
que utilizan los puertos serie de los dispositivos donde se ejecutan.
RFCOMM es un protocolo de transporte sencillo que soporta hasta 9
puertos serie RS-232 y permite hasta 60 conexiones simultáneas (canales
RFCOMM) entre dos dispositivos Bluetooth.
El comando Rfcomm de
la pila de protocolos BlueZ para Linux permite establecer comunicación
con un dispositivo Bluetooth.
Comandos AT
Los comandos AT son instrucciones codificadas que conforman
un lenguaje de comunicación entre el hombre y un terminal módem. Los
comandos AT se denominan así por la abreviatura de attention.
El juego de comandos AT fue desarrollado en 1977 por Dennis Hayes como
un interfaz de comunicación con un módem para poder configurarlo y
proporcionarle instrucciones, tales como marcar un número de teléfono.
Más adelante, fueron las compañías Microcomm y US Robotics las que
siguieron desarrollando y expandiendo el juego de comandos hasta
universalizarlo.
La telefonía móvil GSM también ha adoptado como estándar este lenguaje
para poder comunicarse con sus terminales. De esta forma, todos los
teléfonos móviles GSM poseen un juego de comandos AT específico que
sirve de interfaz para configurar y proporcionar instrucciones a los
terminales.
El juego de comandos AT puede encontrarse en la documentación técnica
de los terminales GSM y permite acciones tales como realizar llamadas
de datos o de voz, leer y escribir entradas en la agenda de contactos y
gestión de mensajes SMS, además de muchas otras opciones de
configuración del terminal.
La implementación de los comandos AT es específica del terminal GSM y
no depende del canal de comunicación a través del cual los comandos
sean enviados, ya sea cable de serie, canal Infrarrojos o Bluetooth. De
esta forma, existen en el mercado distintos teléfonos móviles que
implementan el juego completo de comandos AT o sólo parcialmente, en
cuyo caso implementarán uno o varios de los siguientes bloques de
comandos AT:
- Bloque básico de comandos AT, relacionado con la configuración y el envío de instrucciones al terminal. Permite llevar a cabo, entre otras, las siguientes operaciones: Realizar llamadas de voz y de datos, configurar desvíos de llamadas, obtener información básica sobre la marca, modelo e IMEI (Internacional Mobile Equipment Identity) del terminal, así como del nivel de batería, calidad de cobertura, etc.
- Bloque de comandos AT referido a la gestión de la agenda de contactos, ya sea la memoria contenida en la tarjeta SIM o la lista de últimas llamadas realizadas, perdidas y recibidas almacenada en el terminal. Se pueden llevar a cabo las siguientes acciones: leer un contacto, añadir y eliminar una entrada de la agenda, buscar un contacto por nombre, etc.
- Bloque de comandos AT referido a la gestión de mensajes SMS. Permite ejecutar las siguientes operaciones: obtener el listado de los mensajes SMS almacenados en memoria, leer un mensaje SMS de la bandeja de entrada, eliminar un mensaje SMS existente, escribir un nuevo mensaje SMS, enviar mensajes SMS, etc.
Ejemplo de tabla comparativa con el grado de implementación de
los bloques de comandos AT en algunos de los teléfonos móviles más
populares:
Esquema gráfico del modelo petición/respuesta de los comandos AT:
Ejemplo de una sesión de comandos AT con un teléfono móvil:
Referencias y documentación técnica:
- Juego de Comandos AT GSM
- AT Command Set For Nokia GSM Products
- AT Command Set For Nokia GSMA and WCDMA Products v1.1