El estándar de intercambio inalámbrico de datos Bluetooth utiliza una variedad de protocolos . Los protocolos principales los define la organización comercial Bluetooth SIG . Se han adoptado protocolos adicionales de otros organismos de normalización. Este artículo ofrece una descripción general de los protocolos principales y de los protocolos adoptados que se utilizan ampliamente.
El Bluetooth se divide en dos partes: una "pila de controladores" que contiene la interfaz de radio de sincronización crítica y una "pila de host" que se ocupa de datos de alto nivel. La pila de controladores generalmente se implementa en un dispositivo de silicio de bajo costo que contiene la radio Bluetooth y un microprocesador. La pila de host generalmente se implementa como parte de un sistema operativo o como un paquete instalable sobre un sistema operativo. Para dispositivos integrados como auriculares Bluetooth, la pila de host y la pila de controlador se pueden ejecutar en el mismo microprocesador para reducir los costos de producción en masa; esto se conoce como sistema sin host .
El tipo normal de enlace de radio utilizado para paquetes de datos generales que utilizan un esquema TDMA de sondeo para arbitrar el acceso. Puede transportar paquetes de varios tipos, que se distinguen por:
Se debe configurar y aceptar explícitamente una conexión entre dos dispositivos antes de que se puedan transferir paquetes.
Los paquetes ACL se retransmiten automáticamente si no se reconocen, lo que permite corregir un enlace de radio que está sujeto a interferencias. Para datos isócronos , el número de retransmisiones puede limitarse mediante un tiempo de espera de descarga; pero sin utilizar el modo de retransmisión y control de flujo L2PLAY o EL2CAP, una capa superior debe manejar la pérdida de paquetes.
Los enlaces ACL se desconectan si no se recibe nada durante el período de tiempo de espera de supervisión; el tiempo de espera predeterminado es de 20 segundos, pero el maestro puede modificarlo.
El tipo de enlace de radio utilizado para datos de voz. Un enlace SCO es un conjunto de intervalos de tiempo reservados en un enlace ACL existente. Cada dispositivo transmite datos de voz codificados en el intervalo de tiempo reservado. No hay retransmisiones, pero opcionalmente se puede aplicar la corrección de errores hacia adelante. Los paquetes SCO se pueden enviar cada 1, 2 o 3 intervalos de tiempo.
Los enlaces SCO mejorados (eSCO) permiten una mayor flexibilidad en el establecimiento de enlaces: pueden utilizar retransmisiones para lograr confiabilidad, permitir una variedad más amplia de tipos de paquetes y mayores intervalos entre paquetes que los SCO, aumentando así la disponibilidad de radio para otros enlaces.
Se utiliza para el control del enlace de radio entre dos dispositivos, dmv móvil, consulta de capacidades del dispositivo y control de energía. Implementado en el controlador.
Comunicación estandarizada entre la pila de host (por ejemplo, una PC o un sistema operativo de teléfono móvil) y el controlador (el circuito integrado (IC) de Bluetooth). Este estándar permite intercambiar la pila de host o el controlador IC con una adaptación mínima.
Existen varios estándares de capa de transporte HCI, cada uno de los cuales utiliza una interfaz de hardware diferente para transferir los mismos paquetes de comandos, eventos y datos. Los más utilizados son USB (en PC) y UART (en teléfonos móviles y PDA).
En dispositivos Bluetooth con funcionalidad simple (por ejemplo, auriculares), la pila de host y el controlador se pueden implementar en el mismo microprocesador. En este caso, la HCI es opcional, aunque a menudo se implementa como una interfaz de software interna.
Este es el equivalente LMP de Bluetooth Low Energy (LE), pero es más simple. Se implementa en el controlador y gestiona la publicidad, el escaneo, la conexión y la seguridad desde un nivel bajo, cercano al punto de vista del hardware desde la perspectiva de Bluetooth.
L2CAP se utiliza dentro de la pila de protocolos Bluetooth. Pasa paquetes a la interfaz del controlador de host (HCI) o, en un sistema sin host, directamente al enlace Link Manager/ACL.
Las funciones de L2CAP incluyen:
L2CAP se utiliza para comunicarse a través del enlace ACL del host. Su conexión se establece después de que se haya configurado el enlace ACL.
En modo básico, L2CAP proporciona paquetes con una carga útil configurable de hasta 64 kB, con 672 bytes como MTU predeterminada y 48 bytes como MTU mínima obligatoria admitida. En los modos de retransmisión y control de flujo, L2CAP se puede configurar para datos confiables o asíncronos por canal realizando retransmisiones y verificaciones CRC. La confiabilidad en cualquiera de estos modos está garantizada opcional y/o adicionalmente por la interfaz aérea Bluetooth BDR/EDR de capa inferior mediante la configuración del número de retransmisiones y el tiempo de espera de vaciado (tiempo después del cual la radio vaciará los paquetes). La secuenciación en orden está garantizada por la capa inferior.
La especificación EL2CAP agrega un modo de retransmisión mejorada (ERTM) adicional a la especificación principal, que es una versión mejorada de los modos de retransmisión y control de flujo. Se requiere ERTM cuando se utiliza un AMP (MAC/PHY alternativo), como 802.11abgn.
BNEP [1] se utiliza para entregar paquetes de red además de L2CAP. Este protocolo lo utiliza el perfil de red de área personal (PAN) . BNEP realiza una función similar al Protocolo de acceso a subred (SNAP) en LAN inalámbrica.
En la pila de protocolos, BNEP está vinculado a L2CAP.
El protocolo Bluetooth RFCOMM es un conjunto simple de protocolos de transporte, creado sobre el protocolo L2CAP, que proporciona puertos serie RS-232 emulados (hasta sesenta conexiones simultáneas a un dispositivo Bluetooth a la vez). El protocolo se basa en el estándar ETSI TS 07.10.
RFCOMM a veces se denomina emulación de puerto serie . El perfil del puerto serie de Bluetooth (SPP) se basa en este protocolo.
RFCOMM proporciona al usuario un flujo de datos simple y confiable, similar a TCP. Es utilizado directamente por muchos perfiles relacionados con la telefonía como portador de comandos AT, además de ser una capa de transporte para OBEX a través de Bluetooth.
Muchas aplicaciones Bluetooth utilizan RFCOMM debido a su soporte generalizado y a su API disponible públicamente en la mayoría de los sistemas operativos. Además, las aplicaciones que utilizaban un puerto serie para comunicarse se pueden migrar rápidamente para utilizar RFCOMM.
En la pila de protocolos, RFCOMM está vinculado a L2CAP.
Se utiliza para permitir que los dispositivos descubran qué servicios admiten entre sí y qué parámetros usar para conectarse a ellos. Por ejemplo, al conectar un teléfono móvil a unos auriculares Bluetooth, se utilizará SDP para determinar qué perfiles Bluetooth son compatibles con los auriculares ( perfil de auriculares , perfil de manos libres , perfil de distribución de audio avanzado , etc.) y la configuración del multiplexor de protocolo necesaria para conectarse a cada uno de ellos. Cada servicio se identifica mediante un Identificador Universalmente Único (UUID), y a los servicios oficiales (perfiles de Bluetooth) se les asigna un UUID de formato corto (16 bits en lugar de los 128 completos).
En la pila de protocolos, SDP está vinculado a L2CAP.
También conocido como especificación binaria del protocolo de control de telefonía (TCS binario)
Se utiliza para configurar y controlar llamadas de voz y datos entre dispositivos Bluetooth. El protocolo se basa en el estándar ITU-T Q.931 , aplicándose las disposiciones del Anexo D, realizando solo los cambios mínimos necesarios para Bluetooth.
TCS es utilizado por los perfiles de intercomunicación (ICP) y telefonía inalámbrica (CTP). La especificación del protocolo de control telefónico no se denomina TCP, para evitar confusión con el protocolo de control de transmisión (TCP) utilizado para la comunicación por Internet.
Utilizado por el perfil de control remoto para transferir comandos AV/C a través de un canal L2CAP. Los botones de control de música de unos auriculares estéreo utilizan este protocolo para controlar el reproductor de música.
En la pila de protocolos, AVCTP está vinculado a L2CAP.
Utilizado por el perfil de distribución de audio avanzado para transmitir música a auriculares estéreo a través de un canal L2CAP. Diseñado para ser utilizado por el perfil de distribución de videos.
En la pila de protocolos, AVDTP está vinculado a L2CAP.
El intercambio de objetos (OBEX; también denominado IrOBEX ) es un protocolo de comunicaciones que facilita el intercambio de objetos binarios entre dispositivos. Lo mantiene la Asociación de Datos Infrarrojos , pero también lo ha adoptado el Grupo de Interés Especial de Bluetooth y el ala SyncML de la Open Mobile Alliance (OMA).
En Bluetooth, OBEX se utiliza para muchos perfiles que requieren un intercambio de datos simple (por ejemplo, envío de objetos, transferencia de archivos, imágenes básicas, impresión básica, acceso a la agenda telefónica, etc.).
De alcance similar al SDP pero especialmente adaptado y simplificado para Bluetooth de bajo consumo. Permite a un cliente leer y/o escribir ciertos atributos expuestos por el servidor de una manera no compleja y amigable con bajo consumo de energía.
En la pila de protocolos, ATT está vinculado a L2CAP.
Esto lo utilizan las implementaciones de Bluetooth Low Energy para emparejar y transportar la distribución de claves específicas.
En la pila de protocolos, SMP está vinculado a L2CAP.