Responsibility Statement March 5,
NOTE 22: CONTINGENCIES
Los paquetes ACL satisfacen el tipo de conexión soportado por el perfil PAN y encapsulación de la información a través de BNEP que a su vez, es recibido por la capa L2CAP, definiendo así los tipos de paquetes ofrecidos en la Tabla 3.1.
Tipo Encabezado Carga Útil (bytes) Carga Útil (bytes) FEC CRC Máx. Tasa Simétrica (Kbps) Máx. Tasa Simétrica (Kbps) Adelante Atrás DM1 1 0 - 17 2/3 si 108,8 108,8 108,8 DH1 1 0 - 27 no si 172,8 172,8 172,8 DM3 2 0 -121 2/3 si 258,1 387,2 54,4 DH3 2 0 - 183 no si 390,4 585,6 86,4 DM5 2 0 - 224 2/3 si 286,7 477,8 36,3 DH5 2 0 - 339 no si 433,9 723,2 57,6 AUX1 1 0 - 29 no no 185,6 185,6 185,6
Tabla 3.1 Tipos de paquete ACL [3].
Los paquetes ACL (Tabla 3.1) Bluetooth pueden tener diferentes tamaños. El paquete más pequeño, DM1 (Data - Medium Rate Data packet type for medium rate), transporta hasta 17 bytes de datos de usuario y usa una suma de verificación (FEC) de 2/3 para confiabilidad del mismo; usando una ranura de tiempo. El paquete DH1 (Data-High Rate Data packet type for high rate data) transporta hasta 27 bytes en una ranura de tiempo, omitiendo los bits correspondientes al FEC de 2/3. Los paquetes también pueden abarcar múltiples ranuras de tiempo: Cada paquete DM3 y DH3 usa 3 ranuras de tiempo, mientras que los paquetes DM5 y DH5 usan 5. Éstos existen en modos simétricos y asimétricos: el modo simétrico permite tanto al maestro como al esclavo enviar paquetes igual de grandes.
En el modo asimétrico, solo el maestro envía grandes paquetes, mientras que el esclavo está limitado a enviar paquetes de una ranura de tiempo. Esto aumenta el flujo del ancho de banda del maestro y disminuye el del esclavo. Los valores en la Tabla 1 son, por supuesto, valores teóricos sin el encabezado del paquete. Por ejemplo, en un enlace ACL usando DH5, se pueden enviar alrededor de 300 o 320 Kbps de datos de usuario UDP [3].
Bluetooth está diseñado fundamentalmente para el uso de dispositivos en estados conectados. Debido al soporte de QoS brindado por L2CAP existen factores que afectan directamente un canal ACL que deben ser considerados:
• Intervalo de encuesta - éste es el intervalo máximo en el cual el maestro de la piconet debe transmitir a un esclavo, permitiendo que el esclavo responda. Este intervalo es por lo tanto un factor determinante en el retardo máximo de transmisión de una aplicación. El retardo máximo también es afectada por otros factores por ejemplo la perdida de datos y ruido del radioenlace.
• Tipo de paquete - la mayoría de los paquetes contienen un cheksum CRC para comprobar errores, y los paquetes DM incluyen FEC para la corrección de errores. Los dispositivos que soportan Tasa de Datos que Maneja Calidad del Canal (CQDDR, Channel Quality Driven Data Rate) intentaran elegir el tipo de paquete para la tasa de datos máxima, bajo condiciones de radiocomunicación actuales.
• Modo de retransmisión - los paquetes ACL con CRC pueden ser retransmitidos en un período definido por el flush timeout.
• Flush Timeout - éste define por cuánto tiempo se retransmite un paquete y es declarado en banda base. Un flush timeout infinito significa que un paquete está siendo retransmitido continuamente hasta que se reciba correctamente. Con timeout finito, se desechan los paquetes si no transmitieron con éxito dentro del intervalo timeout.
• Modos de ahorro de energía (Park, Hold y Sniff). Estos modos permiten que los dispositivos estén ausentes de conexión, por lo tanto el retardo aumenta y reduce el ancho de banda para conservar energía. El cambio a estos estados es iniciado desde un estado de conexión normal. El uso de modos con baja potencia pueden ser iniciados por el maestro o el esclavo en cualquier momento durante una conexión. En general, cada dispositivo es responsable de sus propios modos de potencia, esperando que los dispositivos con baterías soliciten dichos modos cuando sea posible [20].
Al hablar de QoS en Bluetooth, deben tenerse en cuenta ciertos parámetros que definen el préstamo de éste:
• Ancho de Banda
• Retardo
• Tasa de Error (corregida)
Sin embargo, para cada uno de estos parámetros, es posible especificar límites en la variación de éstos, por ejemplo variación del retardo. Es también útil para sistemas que ofrecen como servicio el tener cierta información sobre variación en los parámetros, por ejemplo la pérdida del flujo de datos afecta el buffering.
Aunque hay solamente algunos factores que definen el uso de QoS, claramente existen diferentes maneras de usar una radiocomunicación para optimizar uno o más parámetros de QoS. Estos factores están ligados; por lo tanto hay un grado de libertad limitado al mejorar un factor sin afectar contrariamente a otro. Por ejemplo, si se requiere una tasa de error cero entonces puede dar como resultado un retardo infinito porque un paquete puede ser transmitido indefinidamente bajo condiciones de radio adversas.
Diferentes tecnologías de radiocomunicaciones tienen capacidades diferentes para brindar niveles de QoS. El mayor desafío es detallar los rangos de QoS que se puedan especificar de manera universal, tales que cualquier tecnología de radiocomunicación pueda implementar los servicios requeridos apropiadamente [19].
Cuando se establece un enlace ACL la configuración se distribuye en dos niveles:
• Banda Base: los tipos de paquetes, se negocia el intervalo de encuesta y flush timeout.
• L2CAP: L2CAP define dos niveles de servicio que son Mejor Desempeño y Garantizado. Mejor desempeño significa que no hay QoS de ningún tipo, mientras que Garantizado se define usando cinco parámetros adicionales de QoS:
o Token Rate.
o Tamaño del Token Bucket.
o Ancho de banda máximo.
o Retardo.
o Variación del retardo.
Los campos de datos opcionales son los siguientes:
• Flags (8 bits): reservado para uso futuro y debe ser establecido con valor 0 e ignorado por el receptor.
• Service type (8 bits): este campo indica el nivel de servicio requerido. El valor por defecto es el de mejor desempeño, como también puede ser garantizado, sin tráfico o reservado. Si es dejado en el estado por defecto los parámetros restantes se deben tratar como opcionales en el dispositivo remoto, pero si es configurado sin tráfico los campos restantes deben ser ignorados por qué no hay datos enviados a través del canal.
• Token Rate (4 bytes): el valor de este campo representa la rata de datos promedio establecida por la aplicación. La aplicación debe enviar datos a una rata continua. En escala de tiempos cortos la aplicación puede enviar datos excediendo la rata de datos promedio, dependiendo del tamaño del token bucket y el ancho de banda máximo.
• Tamaño del token bucket (4 bytes): este campo especifica el límite de sobrecarga con la cual la aplicación puede transmitir datos. La aplicación puede ofrecer una carga de datos igual al tamaño instantáneo del token bucket, limitado por el ancho de banda máximo.
• Ancho de banda máximo: el valor de este campo, limita cuán rápido los paquetes son enviados desde la aplicación en una conexión extremo a extremo. Algunos sistemas pueden tomar ventaja de esta información, dando como resultado una asignación de recursos más eficiente.
• Latencia: el valor de este campo es el retardo máximo aceptable de un paquete L2CAP una vez es enviado desde banda base.
• Variación del retardo: el valor de este campo es la diferencia, en microsegundos, entre el máximo y el mínimo retardo posible de una comunicación entre 2 capas L2CAP [3].