Protocolo de Control y Adaptación de Enlace Lógico

L2CAP soporta dos tipos de conexiones, la primera se conoce como orientada a la conexión

(bidireccional) y la segunda se denomina sin conexión (unidireccional), estas conexiones se hacen usando la primitiva de servicio connect del paquete javax.microedition.io como se puede ver en la

Figura 3.5, la cual es proporcionada por la capa L2CAP orientada a la conexión del stack de protocolos de Bluetooth. Para establecer los canales de datos sin conexión se utiliza el concepto de comunicación de grupo proporcionado por la capa L2CAP.

Figura 3.5 Marco de Conexión L2CAP

3.1.13.1 Configuración del canal

Los canales orientados a la conexión necesitan ser configurados una vez se establece la conexión. Los parámetros relacionados con la configuración del canal que se negocian entre los dispositivos Bluetooth son:

 Unidad de Transmisión Máxima (MTU) – Hace referencia al máximo tamaño de la carga útil (en bytes) que el remitente es capaz de enviar. La aplicación puede especificar la MTU entrante que le gustaría usar durante la conexión; si dicho valor no se especifica, entonces se emplea el DEFAULT_MTU de 672 bytes; así mismo la aplicación puede especificar el MTU deseado para el dispositivo remoto, es decir, el MTU saliente, si dicho valor no se especifica, entonces éste será menor o igual al MTU entrante anunciado por el dispositivo remoto durante la configuración del canal.

 Interrupción Flush – Se refiere a la cantidad de tiempo para el cual la gestión del enlace intentará transmitir un paquete con éxito antes de vaciar el paquete. Un valor de 0xFFFF22

indica que el paquete se transmitirá hasta que sea reconocido o hasta que el enlace ACL termine, este valor brinda una fiabilidad en el enlace de comunicación. L2CAP proporciona un canal de comunicación full-dúplex el cual entrega las unidades de datos del protocolo

L2CAP de manera ordenada, sin embargo no se ofrece ningún mecanismo que permita asegurar una transmisión fiable de las unidades de datos del protocolo, no obstante cuenta con un proceso de retransmisión a nivel de banda-base que permite soportar suficientes canales de comunicación confiables para las capas más altas.

 Calidad de Servicio (QoS) – La pila de protocolos de Bluetooth determina los valores de QoS, sin embrago este patrón hace referencia a una descripción de flujo del tráfico.

3.1.13.1.1 Unidad de Transmisión máxima (MTU)

Antes de que cualquier operación de lectura/escritura pueda llevarse a cabo durante el proceso de conexión, la aplicación debe responder por la configuración del canal brindando una MTU ya sea predefinido o requerido al usuario. El ReceiveMTU es el número máximo de bytes que el dispositivo local puede recibir en la carga útil. El TransmitMTU es el número máximo de bytes que el dispositivo local puede enviar al dispositivo remoto en la carga útil. Sí DevA es el dispositivo local y DevB es el dispositivo remoto, se definen las siguientes variantes para el ReceiveMTU:

 ReceiveMTUA: Es el máximo tamaño de la carga útil propuesto por una aplicación en el

DevA para las cargas útiles L2CAP recibidas en el DevA.

 ReceiveMTUB: Es el máximo tamaño de la carga útil propuesto por una aplicación en el

DevB para las cargas útiles L2CAP recibidas en el DevB.

 ReceiveMTUAB: Es el máximo tamaño de la carga útil acordado por el DevA y el DevB para

cargas útiles L2CAP recibidas por una aplicación en el DevA.

Ocurre lo mismo para el TransmitMTU:

 TransmitMTUA: Es el máximo tamaño de la carga útil propuesto por una aplicación en el

DevA para las cargas útiles L2CAP enviadas por el DevA.

 TransmitMTUB: Es el máximo tamaño de la carga útil propuesto por una aplicación en el

DevB para las cargas útiles L2CAP enviadas por el DevB.

 TransmitMTUAB: Es el máximo tamaño de la carga útil acordado por el DevA y el DevB

para cargas útiles L2CAP enviadas por una aplicación en el DevA.

 Si ReceiveMTUA ≥ TransmitMTUB, entonces ReceiveMTUAB ≤ ReceiveMTUA. Y si

ReceiveMTUA < TransmitMTUB, entonces la conexión entre DevA y DevB falla.

 Si TransmitMTUA ≤ ReceiveMTUB, entonces TransmitMTUAB = TransmitMTUA. Y si

TransmitMTUA> ReceiveMTUB, entonces la conexión entre DevA y DevB falla.

Cuando la aplicación en el dispositivo local, DevA, invoca:

Connector.open(“btl2cap://...;ReceiveMTU=1024;TransmitMTU=512”),

Cuando la aplicación en el dispositivo remoto, DevB, invoca:

Connector.open(“btl2cap://...;ReceiveMTU=2048;TransmitMTU=512”)

ReceiveMTUB = 2048 y TransmitMTUB = 512. Para este caso, se puede establecer una conexión

entre DevA y DevB debido a que ReceiveMTUAB ≤ 1024 y TransmitMTUAB = 512.

Existen varias maneras de que la aplicación configure la MTU cuando se hace una solicitud de conexión:

1. La aplicación especifica el ReceiveMTUA y el TransmitMTUA. En este caso, la aplicación

advierte al dispositivo remoto el valor del ReceiveMTUA en la solicitud de la configuración,

si el dispositivo remoto retorna una respuesta de configuración negativa, la conexión se considera no exitosa, mientras que si el dispositivo remoto retorna una respuesta de configuración positiva, la aplicación queda esperando la solicitud de configuración del dispositivo remoto. Cuando el dispositivo local recibe una solicitud de configuración desde el dispositivo remoto, compara los valores del ReceiveMTUB en la solicitud entrante al

TransmitMTUA y si el tamaño máximo que la aplicación planea enviar, es decir

TransmitMTUA, resulta ser menor o igual al tamaño máximo que el dispositivo remoto

puede recibir, es decir ReceiveMTUB, la conexión tiene éxito; de otra manera la conexión

falla.

2. La aplicación especifica el ReceiveMTUA, sin embargo no especifica el TransmitMTUA. En

este caso, la configuración con respecto al ReceiveMTUA es similar al párrafo anterior,

pero en el caso que en la solicitud de configuración recibida desde el dispositivo remoto el TransmitMTUAB sea menor o igual al ReceiveMTUB la aplicación debe usar el método

getTransmitMTU() de la clase L2CAPConnection para obtener el valor del MTU saliente y así evitar que se envíen demasiado datos.

3. La aplicación no especifica el ReceiveMTUA, pero si especifica el TransmitMTUA, en este

caso, la aplicación advierte al dispositivo remoto en la solicitud de la configuración que ReceiveMTUA tiene el valor DEFAULT_MTU (672 bytes); mientras que el manejo del

TransmitMTUA es similar al del caso 1.

4. La aplicación no especifica ni el ReceiveMTUA ni el TransmitMTUA, para este caso

entonces, el manejo de ReceiveMTUA es similar al del caso 3, y el manejo de

3.1.13.2 Clases de Conexión L2CAP

Para la conexión L2CAP la especificación proporciona dos interfaz y una clase: L2CAPConnection,

L2CAPConnectionNotifier y BluetoothConnectionException, respectivamente, las cuales se encuentran dentro del paquete javax.bluetooth.

Interfaz javax.bluetooth.L2CAPConnection

Esta interfaz representa las conexiones L2CAP. Contiene métodos que permiten obtener los MTUs usadas, enviar y recibir datos.

Interfaz javax.bluetooth.L2CAPConnectionNotifier

El único método en esta interfaz es acceptAndOpen() el cual se usa por los servidores L2CAP para escuchar las conexiones entrantes del cliente.

Clase javax.bluetooth.BluetoothConnectionException

Esta excepción se ejecuta cuando una conexión Bluetooth (RFCOMM o L2CAP) no se puede establecer con éxito. El método getStatus() de esta clase indicará la razón por la que fracaso la conexión.