Why do we need BLE CoC?
The target markets for Bluetooth Low Energy (BLE) include the smart home, health, sport and fitness areas. All early BLE profiles, like BLP, CSCP and HOGP, are based on GATT, a general specification for sending and receiving short pieces of data known as attributes over a low energy link. The size of data may only be several or a dozen bytes. The data could be temperature, speed, heart-rate and so on. All of them are short pieces of data. The fixed channel for GATT is suitable for the short pieces of data. The default protocol payload for the channel is limited to the default MTU of L2CAP for BLE, 23 bytes which are enough for the short pieces of data.
However, the new requirements for transferring the large amounts of data have arisen. For example, syncing GPX file and updating firmware, the size of data may be dozens of kilobytes and even more than 100 KB. Let’s say the size is 65535 Bytes (65 KB), we need 2850 L2CAP packets to transfer the data (ceil(65535 / 23) = 2850). There are two drawbacks: lowering throughput rate and blocking protocols multiplex.
- 2850 L2CAP basic headers and ATT parameters for write command have to be transferred, that wastes the bandwidth. It needs more CPU cycles to split the large service data into many short pieces of L2CAP payload.
- The higher layers are aware of only their own needs and do not worry about multiplexing other protocols – this functionality is assumed in L2CAP. ATT will reserve next 2850 packets on radio. During this transfer, no other interactions (example SMP) can occur.
L2CAP Connection Oriented Channel in addition to MTU provides the concept of MPS which determines the size of segments that should be used to send a large chunk of data. The value of MPS may be 65533, so we can transfer a large amounts of data in a LE-frame. L2CAP Connection Oriented Channel has an explicit connection procedure to the Protocol Service Multiplexer (PSM) identifying the protocol or service that you need to connect to. Currently, Internet Protocol Support Profile (IPSP) and Object Transfer Profile (OTP) are the two users of BLE CoC.
What is BLE CoC?
Connection-oriented channel (CoC) is defined in L2CAP. CoC may be created for transport of unicast (point-to-point) data between two Bluetooth devices. QoS parameters or flow and error control modes may be applied in CoC. L2CAP channels may be connection-oriented or connectionless. Fixed channels other than the L2CAP connectionless channel (CID 0x0002) and the two L2CAP signaling channels (CIDs 0x0001 for classic and 0x0005 for LE) are considered connection-oriented. All channels with dynamically assigned CIDs are connection-oriented.
There are three modes for connection-oriented channel
- Connection-oriented channel in basic L2CAP mode
- Connection-oriented channel in retransmission/flow control mode
- Connection-oriented channel in LE credit based flow control mode
BLE CoC is only in LE credit based flow control mode in which the L2CAP PDU on a connection-oriented channel is LE-frame.
*L2CAP SDU Length field is only contained in the first LE-frame of the SDU to specify the total number of octets in the SDU. All subsequent LE-frames that are parts of the same SDU shall not contain the L2CAP SDU Length field.
MTU = maximum SDU size
MPS = maximum PDU payload size
The local device sends LE Credit Based Connection Request packet to create a connection. The remote device sendsLE Credit Based Connection Response packet when receives the request packet. The local and remote devices inform/negotiate the parameters to create and configure an L2CAP connection-oriented channel in theConfiguration Process. These parameters areLE_PSM, Source/DestinationCID,MTU,MPS and Initial Credits.
The initial credit value indicates the number of LE-frames that the peer device can send to the local device. The initial credit value shall be in the range of 0 to 65535. LE-frames shall only be sent on LE CoC if the device has a credit count greater than zero for that channel. For each LE-frame sent the device decreases the credit count for that channel by one. The peer device may send aLE Flow Control Credit packet to increase the credit count for that channel by the value of the Credits field in this packet. One credit represents the permission to send one LE-frame over the established channel. The attempt to send more LE-frames than the permitted results in the receiving device closing the channel.
A Protocol Service Multiplexer (PSM) must be associated with any credit-based connection. LE_PSM is a two-byte value identifying the protocol that uses the credit-based connection. LE_PSM values are separated into two ranges which are defined in the table below.
*0x0023 is reserved by Internet Protocol Support Profile (IPSP), and 0x0025 is reserved by Object Transfer Profile (OTP).
Let’s assume that device A sends 95 bytes SDU to device B.
The first LE-frame Payload starts with 2 bytes of SDU Length ‘95’ then follow the first MPS-2 bytes of SDU. The second LE-frame contains MPS bytes of SDU. The last LE-frame contains less than MPS bytes.
Does Android support BLE CoC?
LE CoC is a feature of Core spec v4.1. Theimplementation for LE CoC has been merged in AOSP, but the APIs are hidden. So app cannot use the APIs which are not exposed in Android 7.
BluetoothAdapter::listenUsingL2capOn() is used to create L2CAP server socket, including LE CoC. A specified value of parameter ‘port’ is passed to Fluoride Bluetooth stack to create LE CoC. ‘L2CAP_MASK_LE_COC_CHANNEL’ is used to check if the value of ‘channel’ corresponding to ‘port’ is for LE CoC in Fluoride BT stack. The snippet of setting ‘is_le_coc’ flag is in aosp/system/bt/btif/src/btif_sock_l2cap.c.
How to create a BLE CoC server in Android?
BluetoothAdapter::listenUsingL2capOn() is not exposed to app developer in Android 7, but there are still two method to create LE CoC server socket.
Method 1: Remove ‘@hide’, and rebuild AOSP to create the customized image and SDK. Then directly call BluetoothAdapter::listenUsingL2capOn() in your app.
Method 2: Call BluetoothAdapter::listenUsingL2capOn() using Java reflection on AOSP image. The example snippet is below, and you can access my github to get source code.
If the LE CoC server socket is created successfully, you can see the logs below in logcat.
Note: The two method are only for experimental purpose. For example, you can test LE CoC between your wearable device and Android phone.