智慧城市物聯網傳輸頻寬的實務分析

智慧城市物聯網傳輸頻寬的實務分析

工研院資通所  溫穗安 周奕宇 陳峻志 佟興无 阮聖彰


智慧城市的建置與發展需在物聯網的通訊基礎之下,必須對功耗與傳輸頻寬進行取捨,才能設計出滿足系統的規格需求。智慧城市的建置與發展需在物聯網的通訊基礎之下,必須對功耗與傳輸頻寬進行取捨,才能設計出滿足系統的規格需求。

 

智慧城市架構在物聯網的通訊基礎建設下,需要對通訊協定有基本的認知,才能就功耗與傳輸頻寬進行取捨,滿足系統設計規格需求。基於傳統廣域網路(WAN)耗電且物聯網具低資料傳輸量的應用特性假設,因而提出LPWAN(Low-Power Wide-Area Network,低功率廣域網路)做為實現智慧城市的骨幹通訊架構,導致群雄並起爭取成為物聯網通訊標準的局勢。然而不管採用哪種通訊協定,傳輸功耗正比於傳輸量以及傳輸距離是共通的原理。

易立信(Ericsson)最早在1994年提出建構一短距離無線通訊連線,期望透過標準化的通訊規範,在短距離通訊以無線方式取代有線連線。在1998年,IBM、Intel、Nokia、Toshiba等當時知名龍頭科技大廠紛紛跟進,與易立信一同創立Bluetooth(藍牙) SIG(Special Interest Group)協會[1],期望在短距離範圍內建立一個低成本、低功耗、可以任意無線連線之通訊技術標準。至今藍牙熱潮仍持續加溫,藍牙通訊技術拓展至各種應用層次,行動裝置(手機)、工業IT裝置(電腦、滑鼠)、休閒娛樂(耳機)、醫療保健、運動健身、感測器物聯網等眾多領域。搭上萬物聯網的浪潮,與2014年低功耗藍牙(Bluetooth Low Energy, BLE)4.2規範發表,藍牙的技術與應用已是短距離無線通訊最廣泛被使用的標準之一。

在2016年,藍牙通訊聯盟(Bluetooth SIG)發布藍牙5.0[1]技術規格,較於藍牙4.2,藍牙5.0不論是在傳輸速度、傳輸距離或是傳輸資料量上均有提升,傳輸速度能提升是因為擁有藍牙4.2的兩倍帶寬,能允許PHY 2Mbps的高傳輸模式[2-3]。本篇將以BLE 4.1/5 開發平台為主軸,簡介影響應用資料傳輸頻寬的參數,接著介紹BLE開發平台以及實驗機制和結果。


低功耗藍牙傳輸資料量

兩個裝置間無線傳輸速度跟應用面相關,也與當時傳輸環境有關,分別說明如下:(A)藍牙運行在2.4GHz頻段,無線傳輸必須考慮其他訊號干擾狀況,例如WiFi訊號。傳輸距離遠、訊號干擾較大,較容易掉資料,也影響實際資料可傳輸速度;(B)藍牙通訊聯盟(Bluetooth SIG)制訂藍牙通訊規範,但是不同科技廠商實現(Implementation)方式不盡一樣,因此不同BLE晶片商方案,其效能也不會相同。假若有一份180KB的資料需要傳送,裝置實際傳輸速度只到3KB/s,也就是需要約1分鐘完成資料傳遞,拉高實際傳輸速度必定可以縮短傳輸資料耗時,端看使用者是否可以接受。在接下來小節裡,我們整理幾項影響BLE實際傳輸速度之因素[4]。


1. 應用資料吞吐量理論計算公式

計算BLE應用資料吞吐量(Throughput)公式[4],如公式(1)。

公式(1)
公式(1)

其中,CI,Connection Interval,表示BLE裝置資料傳遞時間間隔;L,代表每一個BLE封包(packet)含應用資料大小;E,表示在每一次的資料傳遞(connection event)內可傳遞封包數量。


2. Connection Interval

藍牙連接過程中,所有的數據通信都在Connection Event中進行,而沒有進行數據通信的時間稱之為Sleeping,Connection Interval是由Connection Event 和Sleeping兩種狀態時間加總而來,參考圖1 示意圖。調整Connection Interval即決定了Master端和Slave端進行資料交換Connection Event所需的間隔時間。Connection Interval須以1.25ms為單位,可設定的範圍在7.5ms~4s之間,若時間設定越長,則BLE進行資料傳遞需間隔越久的時間。

圖1 Connection Interval/Connection Event示意圖

 

3. ATT MTU

ATT是Attribute Protocol的簡稱,是應用層的線路協議,而ATT MTU(Maximum Transmission Unit)代表的是ATT Packet最大可傳輸的資料長度,在Master裝置和Slave裝置建立連線後,會由Client發起進行交換MTU資訊的請求,以確保兩端ATT Packet傳輸資料長度相同。表1 為一個Uncoded LE data packet的資料格式[2],其中ATT MTU所能影響的即為ATT Data所能傳輸的資料量,而在Connection Interval固定的情況下,每次Connection Event所能傳遞的封包(packet)數量是有限制的,因此若是單一封包所能傳遞的ATT Payload越大,資料傳遞的吞吐量也會上升。

表1  BLE Uncoded LE data packet的資料格式[2]

 

4. Maximum number of packets per connection interval

在一個Connection Event時間內能夠進行多個封包的資料傳輸,然而在不同的作業系統或裝置下會有不同的最大傳輸量限制,以Android為例Nexus系列裝置能夠允許在每個Connection Event中傳遞6個封包,而iPhone或Macbook等搭載iOS的裝置在每個Connection Event中能傳遞4個封包,每個Connection Interval能傳遞的最大封包數量會直接影響到每次Connection Event的資料傳輸量,能允許的封包數量越多,吞吐量也會越大。


5. Receiver端的影響

BLE應用資料傳輸頻寬,除了前面提到BLE晶片實作方案因素之外,另一個決定因子是要看接收端的能力。在討論BLE資料吞吐量時,若手機/平板(Android or iOS)擔任receiver端的角色,其韌體設計也必須要考慮進去。而Android 或 iOS作業系統不斷更新,其穩定性與效能也不斷精進,Connection Interval的最小數值,在各個Android 或 iOS版本皆不盡相同[5],本文不特別針對此議題進行探究。


測試與驗證

1.實驗環境介紹

在本章節當中,我們將以Nordic Semiconductor[6] BLE硬體平台方案作為主軸,調整BLE韌體相關參數設定,並實測資料傳輸量數據。本文選擇兩組BLE開發平台,一為工研院自製的BLE開發平台,如圖2左側所示,其名為BLEIoT。BLEIoT平台是以「MDBT40 nano (BT4.1 Module)藍牙系統模組[7]」方案作為設計參考,核心為內含支援藍牙無線傳輸通訊協定嵌入式2.4GHz收發器之系統單晶片「nRF51822 SoC」[8],其主要組成單元包括一個位於AHB匯流排之32位元處理器(ARM Cortex-M0)[9]、16KB隨機存取記憶體(Random Access Memory)、256KB非揮發性記憶體(Non-Volatile Memory, NVM);第二組藍牙開發平台為Raytac MDBT42Q-DB[10],如圖2右側所示。MDBT42Q-DB核心為內含支援藍牙5傳輸通訊協定之「nRF52832 SoC」[11]系統單晶片,包括一32位元處理器(ARM Cortex-M4F)[9]、64KB隨機存取記憶體、512KB非揮發性記憶體。上述兩組實驗平台核心差異彙整資料,如表2。

圖2 BLE藍牙開發板
表2  BLE藍牙實驗平台特性比較表
表2  BLE藍牙實驗平台特性比較表

2.實驗流程簡介

本文為計算藍牙傳輸頻寬最大傳輸速度,實驗設計上是由BLE開發平台硬體端UART介面負責接收來自電腦端程式產生的資料,同時並透過BLE傳送至手機端「nRF UART v2.0」APP[12]顯示資料,若BLE傳輸速度無法負荷UART傳輸的資料量,會產生「BLE_ERROR_NO_TX_BUFFERS」隨即導致藍牙斷線,此訊息出現代表BLE已無法正確地傳遞資料,為了找到BLE UART最大傳輸量,我們在測試程式中逐步增加UART傳遞的Bytes數,2直到藍牙出現斷線。藍牙頻寬實驗截圖,如圖3;實測實驗手機端規格資訊,彙整於表3;傳輸頻寬之實驗步驟,彙整於表4。


圖3 藍牙模組頻寬實驗截圖圖3 藍牙模組頻寬實驗截圖
圖3 藍牙模組頻寬實驗截圖圖3 藍牙模組頻寬實驗截圖

實測實驗手機端規格資訊,彙整於表3
實測實驗手機端規格資訊,彙整於表3

傳輸頻寬之實驗步驟,彙整於表4


傳輸頻寬之實驗步驟,彙整於表4
 
圖8、APP收到BLE開發板送出資料截圖

3.應用資料吞吐量實驗數據

根據第二章節BLE應用資料吞吐量計算公式,資料傳輸頻寬與相鄰兩個BLE Connection間之時間間隔成反比、與每個封包可包含應用資料量大小成正比、也與每次Connection內可傳輸之封包數量成正比。本文以Connection Interval(CI)、與ATT MTU大小為變數,實際在BLEIoT與MDBT42Q-DB BLE藍牙開發平台,實測應用資料吞吐量實驗數據,相關變數設定與實測數據,整理於表5。實驗結果分別說明如下:


3.1 Connection Interval參數之影響

當拉長相鄰兩個BLE event時間間隔時,BLE應用資料吞吐量跟著降低,例如:

  • CASE1 vs. CASE2:
    CI拉長為10倍之時間間隔,BLEIoT 吞吐量約減少為原本之31%@ATT MTU=23;MDBT42Q-DB 吞吐量約減少為原本之66%@ATT MTU=23。
  • CASE3 vs. CASE4:
    MDBT42Q-DB 吞吐量約減少為原本之85%@ATT MTU=247。

換句話說,當縮短相鄰兩個BLE event時間間隔時,BLE應用資料吞吐量跟著增加,例如:

  • CASE2 vs. CASE1:
    CI縮短為1/10之時間間隔,BLEIoT 吞吐量約增加為原本之1.45倍@ATT MTU=23;MDBT42Q-DB 吞吐量約增加為原本之2.96倍@ATT MTU=23。
  • CASE4 vs. CASE3:
    MDBT42Q-DB 吞吐量約增加為原本之6.78倍@ATT MTU=247。

3.2 單一封包應用資料大小參數之影響

在Connection Interval固定的情況下,僅增大單一封包應用資料量之大小,BLE應用資料吞吐量跟著提升,例如:MDBT42Q-DB開發平台,ATT MTU 最大設定為247 Bytes,相較於ATT MTU設定為23 Bytes,ATT MTU約增加為原本之10.94倍,, MDBT42Q-DB 吞吐量約增加為原本之3.05倍@CI=40ms(CASE3 vs. CASE1);或是約增加為原本之1.33倍@CI=400ms(CASE4 vs. CASE2)。


3.3技術規範演進

在BLE 5技術規範,ATT MTU最大數值可為247 Bytes,對比於BLE 4.1技術規範最大ATT MTU為23 Bytes,同時考慮CI對傳輸速度效能之影響,本文實測由CASE2之CI=400ms縮短為1/10至CASE1之CI=40ms(ATT MTU同為23 Bytes),BLE應用資料吞吐量約增加為2.96倍;再將ATT MTU提高約10.94倍至247 Bytes(CASE3),BLE應用資料吞吐量約增加為3.05倍;CI縮短與ATT MTU增大之綜合效應(即CASE3 vs. CASE2),實驗數據得到吞吐量約可提升為9.04倍。


表5  藍牙傳輸吞吐量實驗數據整理
表5  藍牙傳輸吞吐量實驗數據整理


本文以BLE 4.1及BLE 5平台為實驗載具,探討影響物聯網傳輸頻寬之要素,包括:CI(Connection Interval,資料傳遞時間間隔)及ATT MTU(Maximum Transmission Unit,ATT packet最大可傳輸的資料長度),並實際量測資料傳輸頻寬;本文實驗數據顯示縮短CI及盡可能增加ATT MTU於BLE 5實驗平台之應用資料吞吐量約可提升為9倍。對應各種使用者之需求,建議系統開發人員(韌體/硬體)可評估適當硬體方案與韌體參數,開發符合應用需求與經濟效益之方案。


文章轉載自工研院電腦與通訊期刊