El estándar de intercambio de datos inalámbricos Bluetooth utiliza una variedad de protocolos . Los protocolos básicos están definidos por 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 básicos y los protocolos adoptados que se utilizan ampliamente.
El Bluetooth se divide en dos partes: una "pila de controlador" que contiene la interfaz de radio crítica para la sincronización y una "pila de host" que se ocupa de los datos de alto nivel. La pila de controlador 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 un sistema sin host .
El tipo normal de enlace de radio utilizado para paquetes de datos generales que utilizan un esquema de sondeo TDMA 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 la corrección de un enlace de radio que está sujeto a interferencias. Para los datos isócronos , la cantidad de retransmisiones se puede limitar mediante un tiempo de espera de vaciado; pero sin utilizar el modo de control de flujo y retransmisión 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 los datos de voz. Un enlace SCO es un conjunto de intervalos de tiempo reservados separados por el intervalo SCO Tsco que se determina durante el establecimiento del enlace lógico por el dispositivo central. Cada dispositivo transmite datos de voz codificados en el intervalo de tiempo reservado. No hay retransmisiones, pero se puede aplicar opcionalmente la corrección de errores de reenvío. Los paquetes SCO se pueden enviar cada 1, 2 o 3 intervalos de tiempo.
Los enlaces SCO mejorados (eSCO) permiten una mayor flexibilidad en la configuración de enlaces: pueden usar retransmisiones para lograr confiabilidad, permiten una variedad más amplia de tipos de paquetes y mayores intervalos entre paquetes que SCO, aumentando así la disponibilidad de radio para otros enlaces.
Se utiliza para controlar el enlace de radio entre dos dispositivos, DMV móvil, consultar las capacidades del dispositivo y controlar la potencia. Se implementa en el controlador.
Comunicación estandarizada entre la pila del host (por ejemplo, un sistema operativo de PC o teléfono móvil) y el controlador (el circuito integrado (IC) de Bluetooth). Este estándar permite intercambiar la pila del host o el IC del controlador 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 los dispositivos Bluetooth con funcionalidades simples (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 administra 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 del host (HCI) o, en un sistema sin host, directamente al enlace del administrador de enlaces/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 el modo básico, L2CAP proporciona paquetes con una carga útil configurable hasta 64 kB, con 672 bytes como la MTU predeterminada y 48 bytes como la MTU mínima obligatoria admitida. En los modos de retransmisión y control de flujo, L2CAP se puede configurar para datos confiables o asincrónicos por canal realizando retransmisiones y verificaciones de CRC. La confiabilidad en cualquiera de estos modos está garantizada opcionalmente y/o adicionalmente por la interfaz aérea Bluetooth BDR/EDR de capa inferior configurando la cantidad 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 mejorado (ERTM) adicional a la especificación principal, que es una versión mejorada de los modos de retransmisión y control de flujo. ERTM es necesario cuando se utiliza un AMP (MAC/PHY alternativo), como 802.11abgn.
BNEP [1] se utiliza para enviar paquetes de red sobre 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.
A veces, RFCOMM se denomina emulación de puerto serie . El perfil de puerto serie (SPP) de Bluetooth se basa en este protocolo.
RFCOMM proporciona al usuario un flujo de datos simple y confiable, similar a TCP. Muchos perfiles relacionados con la telefonía lo utilizan directamente como portador de comandos AT, además de ser una capa de transporte para OBEX sobre Bluetooth.
Muchas aplicaciones Bluetooth utilizan RFCOMM debido a su amplio soporte y a que la API está disponible públicamente en la mayoría de los sistemas operativos. Además, las aplicaciones que utilizaban un puerto serial para comunicarse pueden migrarse 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 los demás y qué parámetros utilizar para conectarse a ellos. Por ejemplo, al conectar un teléfono móvil a un auricular Bluetooth, se utilizará SDP para determinar qué perfiles Bluetooth son compatibles con el auricular ( perfil de auricular , perfil de manos libres , perfil de distribución de audio avanzado , etc.) y los ajustes del multiplexor de protocolo necesarios para conectarse a cada uno de ellos. Cada servicio se identifica mediante un identificador único universal (UUID), y a los servicios oficiales (perfiles Bluetooth) se les asigna un UUID de forma corta (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 establecer y controlar llamadas de voz y datos entre dispositivos Bluetooth. El protocolo se basa en la norma ITU-T Q.931 , con las disposiciones del Anexo D aplicadas, realizando únicamente los cambios mínimos necesarios para Bluetooth.
El protocolo de control de transmisión ( TCS) se utiliza en 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 confusiones 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 un auricular 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. Destinado para ser utilizado por el perfil de distribución de video.
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 Infrared Data Association , pero también lo ha adoptado el Bluetooth Special Interest Group 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.).
Similar en alcance a SDP pero especialmente adaptado y simplificado para Bluetooth de bajo consumo. Permite que un cliente lea o escriba ciertos atributos expuestos por el servidor de una manera sencilla y que consume poca energía.
En la pila de protocolos, ATT está vinculado a L2CAP.
Las implementaciones de Bluetooth Low Energy lo utilizan para el emparejamiento y la distribución de claves específicas del transporte.
En la pila de protocolos, SMP está vinculado a L2CAP.