BLE吞吐量测试

介绍

本章分别测试了 TI CC2640R2F LaunchPad 和 LECONIOT CC2640R2F Evaluation Board开发板吞吐量，并提供了两个例程供大家参考测试，分别是 ble5_throughput_peripheral 和 ble5_throughput_central 。文末附对应测试程序下载链接。

该工程中进行了一些修改以方便进行吞吐量测试:

• 改变项目 MTU 大小
• 通过消息计数器发送通知
• 增加 Throughput 配置文件
• 增加按键菜单

硬件环境

使用 USB 连接 CC2640R2F Evaluation Board ，确保跳线帽正确连接，如下图所示：

参数修改

基本思想是不断发送 GATT 通知，尽可能减少开销，尽可能减少停机时间。
以下参数在增加吞吐量时必须加以考虑：

ATT_MTU大小

有关最大传输单元（ATT_MTU）的说明，请参见 LE Data Length Extension 和 Logical Link Control and Adaptation Layer Protocol (L2CAP)。

这里定义 6 个Tx缓冲区，每个缓冲区 251 字节。用户应用程序应根据自身堆栈情况进行分配。如果没有足够的堆栈，可以减少 MAX_NUM_PDU ，但这样可能导致吞吐量的损失。实际使用中的最坏情况是 MAX_NUM_PDU 和 MAX_PDU_SIZE 的乘积，即缺乏堆栈时能减少的最大值。设计人员应该根据设备的可用内存来平衡这些参数。

#define MAX_NUM_PDU                   6
#define MAX_PDU_SIZE                  251

注意：最好在 options->C/C++ Compiler->Defined symbols 里进行修改。

注意：MTU 更新过程在连接之后主机自动发起和从机进行协商。选择双方支持最大 MTU。

LE 2M PHY

这里使用 2M PHY，使每个连接事件期间从 PHY 发送的数据增加一倍（需要连接之后通过按键菜单自行选择）。

LE 数据长度拓展

在蓝牙 4.2 规范中允许控制器发送最多 251 个字节的单个数据包，这与以前的 27 个字节相比大大增加了吞吐量，此功能称为数据长度拓展。有关这方面详细介绍请参考 LE Data Length Extension 以及 BLE 一次能传多少数据（ ATT_MTU 设置/LE Data 扩展）。
下面的 PDU 更新过程的代码片段可以在 throughput_peripheral.c 文件中找到

//examples\rtos\CC2640R2_LAUNCHXL\ble5apps\throughput_peripheral\src\app\throughput_peripheral.c SimpleBLEPeripheral_doSetDLEPDU line 1213
bool SimpleBLEPeripheral_doSetDLEPDU(uint8 index)
{
  switch (index)
  {
  case 0:
    txOctets = DEFAULT_PDU_SIZE;
    txTime = DEFAULT_TX_TIME;
    break;
  case 1:
    txOctets = DLE_MAX_PDU_SIZE;
    txTime = DLE_MAX_TX_TIME;
    break;
  }
 HCI_LE_SetDataLenCmd(connectionHandle, txOctets, txTime);
}

连接间隔

根据前后处理数量，控制器需要 2-3ms 来准备下一个连接事件，因此更长的连接间隔可以提高吞吐量。由于使用 notify 方式传输，增加连接间隔意味着连接事件减少。此示例将使用 100ms 的连接间隔，在实际情况下增加连接间隔有着明显的缺点：由于射频干扰导致的连接事件将大大降低吞吐量。因此用户需要根据所需吞吐量进行权衡，当连接间隔大于 100ms 后，吞吐量将不会增加。

通知排队

这段代码设计能保证队列中始终有需要发送的数据，避免在通知开始时处于饥饿状态。

//examples\rtos\CC2640R2_LAUNCHXL\ble5apps\throughput_peripheral\src\app\throughput_peripheral.c SimpleBLEPeripheral_blastData line 1329
static void blastData()
{
  uint16 len = MAX_PDU_SIZE-7;
  attHandleValueNoti_t noti;
  bStatus_t status;
  noti.handle = 0x1E;
  noti.len = len;

  while(1)
  {
    //attempt to allocate payload
    noti.pValue = (uint8 *)GATT_bm_alloc( 0, ATT_HANDLE_VALUE_NOTI, GATT_MAX_MTU, &len );

    if ( noti.pValue != NULL ) //if allocated
    {
      //place index
      noti.pValue[0] = (msg_counter >> 24) & 0xFF;
      noti.pValue[1] = (msg_counter >> 16) & 0xFF;
      noti.pValue[2] = (msg_counter >> 8) & 0xFF;
      noti.pValue[3] = msg_counter & 0xFF;
      status = GATT_Notification( 0, &noti, 0 );    //attempt to send
      if ( status != SUCCESS ) //if noti not sent
      {
        GATT_bm_free( (gattMsg_t *)&noti, ATT_HANDLE_VALUE_NOTI );
      }
      else //noti sent, increment counter
      {
        msg_counter++;
      }
    }
    else
    {
      //bleNoResources
      asm("NOP");
    }
  }
}

本代码仅为最大吞吐量测试，在实际应用中，由于其他处理需求，应用程序可能无法维持此吞吐量（例如必须通过串口传输有效数据负载）。此外 blastData 函数最大限度的增加了数据的排队，因此 GATT_Notification 会返回非 SUCCESS 状态，例如队列已满时的 blePending。Tx 队列的深度由 MAX_NUM_PDU 决定。

分组开销

主机和从机的有效数据载荷已经被优化为 251 字节，这是吞吐量的最大值。由于 ATT 和 L2CAP 级别的开销，并不是所有 251 个字节都可以用作应用程序数据，这是蓝牙规范所必须的。对 ATT 和 L2CAP 的简要说明如下：

ATT 通知头

所有 ATT 通知包具有标识
发送通知的属性的操作码和句柄所需的 3 字节头。
发送 ATT 通知有 3 字节开销。

L2CAP头

在 L2CAP 层，需要类似的开销来设置分组的长度
和适当的信道标识符（CID）。
这些字段中的每一个都是 16 位（ 2 字节），导致 4 个字节的 L2CAP 开销。
结合 L2CAP 和 ATT 数据包开销产生：

TOTAL_PACKET_OVERHEAD = 7 bytes

测试结果

分别对 PDU 为 27 Bytes 和 251 Bytes 以及 PHY 为 1 Mbps、2 Mbps、Coded:S2、Coded:S8.模式进行测试。下面给出表格方便查阅。

TI CC2640R2F LaunchPad

CC2640R2F Evaluation Board

可以看出我们的开发板和 TI CC2640R2F LaunchPad在不同模式下速率是一致的。读者可以自行下载例程测试。下图展示了在 2 Mbps/251bytes 模式下的传输速率。

测试用例下载

[](http://www.leconiot.com/md_res/cc2640r2f/ble_stack_app/app_examples/ble_throughput/files/ble_throughput.zip)

下载 BLE Throughput 测试例程.

注意:需要配合 CC2640RF SDK使用，本文使用的是 simplelink_cc2640r2_sdk_1_35_00_33 。文件解压后放在该 SDK 同级目录，即 C:ti。

加入我们

文章所有代码、工具、文档开源。加入我们QQ群 591679055获取更多支持，共同研究CC2640R2F&BLE5.0。