BLE吞吐量測試

本章分別測試了TI CC2640R2F LuanchPad和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通知頭

所有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

模式	1 Mbps	2 Mbps	Coded:S2	Coded:S8
27 Bytes	288.896 (kb/s)	390.400 (kb/s)	101.504 (kb/s)	29.280 (kb/s)
251 Bytes	780.800 (kb/s)	1366.400 (kb/s)	175.680 (kb/s)	58.560 (kb/s)

CC2640R2F Evaluation Board

模式	1 Mbps	2 Mbps	Coded:S2	Coded:S8
27 Bytes	288.896 (kb/s)	390.400 (kb/s)	101.504 (kb/s)	29.280 (kb/s)
251 Bytes	780.800 (kb/s)	1366.400 (kb/s)	175.680 (kb/s)	58.560 (kb/s)

可以看出我們的開發板和TI CC2640R2F LaunchPad在不同模式下速率是一致的。讀者可以自行下載例程測試。下圖展示了在2 Mbps/251bytes模式下的傳輸速率。

測試用例下載

 

下載 BLE Throughput 測試例程.

注意:需要配合CC2640RF SDK使用，筆者目前使用的是simplelink_cc2640r2_sdk_1_35_00_33。文件解壓後放在該SDK同級目錄，即C:\ti。