基于低能耗藍牙的半雙工語音通信
低能耗藍牙被業(yè)界廣泛認為是實現(xiàn)物聯(lián)網(wǎng)(IoT)應用愿景的關鍵技術。事實上,極低的功耗使其成為電池供電的物聯(lián)網(wǎng)產(chǎn)品最理想的無線通信解決方案,盡管目前低能耗藍牙技術規(guī)范還是局限于幾種特定應用,但是,創(chuàng)新的解決方案可促使這項技術拓展到不同的應用領域,例如,多媒體流。按照這個發(fā)展方向,本文介紹一個叫做BlueVoice的低能耗藍牙設備語音流應用。
本文引用地址:http://www.ex-cimer.com/article/201605/291324.htm本文從支持語音流服務所需的擴展服務集開始介紹BlueVoice應用,然后在實際硬件設備上評估BlueVoice的性能。在所選的硬件平臺上,BlueVoice應用完全支持語音流服務,同時避免能源浪費。
I. 前言
經(jīng)歷過去幾十年的快速增長,互聯(lián)網(wǎng)幾乎滲透到人類社會日常生活的方方面面。未來互聯(lián)網(wǎng)將擴展到萬物互聯(lián),數(shù)十億甚至數(shù)百億個有唯一身份的“物品”通過無線通信與人類和周圍環(huán)境交互,執(zhí)行高級任務。在這一構想中,“物品”可能是傳感器、致動器、家電、玩具,總之,可以是任何能夠被識別的虛擬或實體物品,這種互聯(lián)網(wǎng)演進構想被稱為物聯(lián)網(wǎng)(IoT)。
物聯(lián)網(wǎng)概念是通過標準協(xié)議解決方案(即互聯(lián)網(wǎng)協(xié)議)和無線通信接口,把所有產(chǎn)品設備連接在一起,組成一個全球網(wǎng)絡。實現(xiàn)萬物互聯(lián),雖然可以使用現(xiàn)有的大量的射頻通信技術,但是當物聯(lián)網(wǎng)產(chǎn)品是部署在現(xiàn)場的自主型電池供電裝置時,低功耗無線通信技術才會是最適合的通信解決方案。在這個方面,低能耗藍牙(Bluetooth LE) [1]技術被視為最有效的物聯(lián)網(wǎng)通信解決方案,同時正在融入互聯(lián)網(wǎng)世界[2]。
在今天的物聯(lián)網(wǎng)應用中,低能耗藍牙解決方案主要用于生命參數(shù)監(jiān)視用途。除傳統(tǒng)的監(jiān)視服務外,近幾年業(yè)界開始探索基于其它技術的先進應用。例如,參考文獻[3]提出并分析了基于IEEE802.15.4的網(wǎng)絡[4]語音通信。在這個方面,通過低能耗藍牙傳輸多媒體數(shù)據(jù)還是處于起步階段,缺少可用的解決方案主要是因為最初設想時未考慮到這些應用(例如,最初主要考慮的是醫(yī)療、健身等應用)。本文以在低能耗藍牙設備上支持語音流服務的BlueVoice應用為例,探討如何解決這些技術限制問題。我們先了解一下低能耗藍牙技術,然后詳細介紹支持該新應用概念所需的擴展服務集,再介紹應用設計,最后在STM32 Nucleo L476板上測試實際性能。
本文的有要內容安排如下:第二章介紹低能耗藍牙工作原理,先描述整個工作棧;然后介紹配置文件(Profiles)概念。第三章介紹應用方案設計,描述其低能耗藍牙配置文件,然后介紹其設計原則、設計實現(xiàn)及實際性能。第四章是結論。
M. Gentili and R. Sannino are with AST Audio/Sensors Platforms R&D and Audio SW Ecosystem, STMicroelectronics, Agrate Brianza, Italy (e-mail: [maurizio.gentilijroberto.sannino]@st.com).
M. Petracca is with Scuola Superiore Sant’Anna di Pisa and National Inter-University Consortium for Telecommunications, Pisa, Italy (e-mail:matteo.petracca@sssup.it) .
II. 低能耗藍牙技術概述
BLE低能耗藍牙規(guī)范于2010年寫入藍牙4.0核心規(guī)范,盡管與基本藍牙相似,但是低能耗藍牙規(guī)范主要是為超低功耗應用設計開發(fā)。通過低能耗藍牙技術連接電池供電設備的潛在應用非常少,醫(yī)療、健身和智慧家居是其中僅有的幾例。
圖1. 低能耗藍牙協(xié)議棧
如圖1所示,低能耗藍牙協(xié)議??傮w結構主要由兩個部分組成:控制器和主機。應用軟件使用協(xié)議棧主機層的協(xié)議提供的服務。主機層分為五層:邏輯鏈路控制和適配協(xié)議(L2CAP)、屬性協(xié)議(ATT)、通用屬性配置文件(GATT)、安全管理協(xié)議(SM)、通用訪問配置文件(GAP)。控制器部分只有兩層:物理層(PHY)和鏈路層(LL)。如圖1所示,主機-控制器(HCI)接口是控制器與主機的通信通道。
物理層負責比特調制,通過無線通道收發(fā)數(shù)據(jù)。最高數(shù)據(jù)速率是1 Mb/s,典型通信距離是幾十米。
鏈路層規(guī)定兩個設備之間雙向通信的功能。低能耗藍牙節(jié)點有兩個角色:主設備和從設備。通常是主設備(例如,筆記本電腦、智能手機)搜索從設備(例如,體感設備);必要時,從設備向主設備發(fā)送數(shù)據(jù)。從設備通常處于睡眠狀態(tài),并在固定間隔內喚醒,以便被主設備搜到。
在鏈路層之上,邏輯鏈路控制和適配協(xié)議(L2CAP)有兩個主要功能。該協(xié)議的主要作用是提供多路傳輸功能,按照標準低能耗藍牙分組數(shù)據(jù)格式,封裝轉換頂層多協(xié)議數(shù)據(jù)。安全管理協(xié)議(SM)和通用訪問配置文件(GAP)分別提供數(shù)據(jù)安全和服務管理功能。詳細的說,安全管理協(xié)議定義密鑰的生成方式,以及如何在兩個設備(主從設備)之間交換密鑰,建立安全加密通信通道,而通用訪問配置文件則規(guī)定兩個設備如何在底層交互操作
屬性協(xié)議(ATT)和通用屬性配置文件是開發(fā)新應用時需要重點考慮的兩個協(xié)議組件。屬性協(xié)議是一個無狀態(tài)的客戶機/服務器協(xié)議:不考慮設備的底層角色是主設備還是從設備,每個設備都可以設為服務器、客戶機或是客戶機兼服務器。客戶機請求服務器數(shù)據(jù)發(fā)送數(shù)據(jù),服務器向客戶機發(fā)送數(shù)據(jù),數(shù)據(jù)以屬性的形式保存在服務器內,每個屬性都含有GATT管理的數(shù)據(jù),而且該數(shù)據(jù)被分配一個通用唯一標識符(UUID)。通過一個L2CAP專用通道,屬性協(xié)議在服務器屬性與客戶機之間建立一條通信通道。通用屬性配置文件(GATT)在屬性協(xié)議層添加一個數(shù)據(jù)抽象模型,負責搜索屬性協(xié)議保存的數(shù)據(jù),在兩個設備之間交換特征。每個低能耗藍牙設備都有一套可能屬性(存儲服務)和特征(與存儲服務相關的屬性)。如果在低能耗藍牙棧上建立一個新應用,則必須定義屬性和特征。某一特定應用的特征、屬性和底層規(guī)范合稱配置文件,標準配置文件可保證不同品牌的產(chǎn)品能夠互聯(lián)互通。
III. BLUEVOICE應用
下面我們介紹BlueVoice應用,首先定義語音通信低能耗藍牙配置文件,然后討論所涉及設備的通信角色、音頻處理和壓縮選擇、數(shù)據(jù)分組問題和帶寬要求。我們提出兩個在音頻采集和功耗方面不同的系統(tǒng)配置,以滿足不同的應用要求。本章最后一部分介紹在一個實際硬件設備上實現(xiàn)的BlueVoice應用,然后比較并討論實際測量到的應用性能,例如,功耗、存儲器占用、處理性能要求和自動語音識別(ASR)性能。
A. 服務定義
考慮到音頻流用例不屬于低能耗藍牙標準配置文件,為實現(xiàn)語音流服務,BlueVoice應用在低能耗藍牙協(xié)議棧上,定義了一個叫做BlueVoice Service(BVS)的“廠商專用配置文件”,指定了服務器與客戶機之間交換語音數(shù)據(jù)的方式。此外,考慮到半雙工通信需要特別的設計選擇,本章稍后詳細討論這個問題。
如前文所述,屬性協(xié)議ATT是通用屬性配置文件GATT在不同設備之間交換數(shù)據(jù)的傳輸協(xié)議,屬性是ATT定義的最小的實體,是可尋址的信息段(內置UUID標識碼),可能含有用戶數(shù)據(jù)或關于屬性本身架構的元信息,例如,權限、加密和授權屬性。GATT服務器屬性按特定順序組成一個服務序列,序列開始部分是服務聲明屬性,后面跟一個或多個特征和可能的描述符。每個特征都是一個被披露的屬性。除標準配置文件UUID外,在定制應用中,開發(fā)人員可使用獨有的和廠商專用的UUID開發(fā)有自己特征的新服務,BlueVoice應用就是這種情況??紤]到單向音頻流系統(tǒng)不對稱性,服務器通過BVS配置文件向客戶機披露數(shù)據(jù)類型和格式以及訪問方式。BVS服務包含下列屬性,如圖2所示。
服務聲明(Handle 0x0010)
– UUID: 標準16位UUID,用于主服務聲明(0x2800).
– 權限:讀
– 數(shù)值: 獨有128位BVS UUID.
特征聲明 (Handle 0x0011)
– UUID: 標準16位UUID,用于特征聲明 (0x2803).
– 權限: 讀
– 數(shù)值: 獨有128位音頻UUID, 僅用于通知, Handle: 0x012.
特征數(shù)據(jù) (Handle 0x0012)
– UUID: 獨有128位音頻UUID.
– 權限: 無
– 數(shù)值: 實際音頻數(shù)據(jù)
特征聲明 (Handle 0x0014)
– UUID: 標準16位UUID,用于特征聲明 (0x2803).
– 權限:讀
– 數(shù)值: 獨有128位同步UUID,僅用于通知,Handle: 0x0015.
特征數(shù)據(jù) (Handle 0x0015)
– UUID: 獨有128位同步UUID.
– 權限: 無
– 數(shù)值: 實際同步數(shù)據(jù)
根據(jù)該標準,主服務聲明是服務的第一個屬性,其數(shù)值域包含該聲明引入的UUID定義。BlueVoice應用聲明使用一個128位獨有的UUID(BVS UUID)。BVS包含兩個特征,分別叫做音頻(Audio)和同步(Sync) 特征。在低能耗藍牙規(guī)范中,每個特征至少包含兩個屬性,分別是特征聲明和特征數(shù)值。特征聲明以元數(shù)據(jù)的形式定義其屬性,特征數(shù)值則是包含實際特征數(shù)據(jù)。在BlueVoice情況中,音頻和同步特征都包含一個單一的由獨有128位UUID定義 (AudioData和SyncData UUID) 的屬性,分別含有實際音頻數(shù)據(jù)和邊信息同步數(shù)值。音頻和同步特征聲明將AudioData和SyncData屬性定義為”僅通知”,未取得客戶機的讀寫權限,表示音頻數(shù)據(jù)和同步數(shù)據(jù)只以通知的形式傳輸,服務器不答復客戶機。為與低能耗藍牙服務的分層架構一致,其它特征可能會增加到未來發(fā)布的BlueVoice應用。
圖2. BlueVoice服務(BVS)定義
B. 應用設計
本章主要介紹BlueVoice應用設計的(i)低能耗藍牙通信(ii)音頻處理。
1) 低能耗藍牙通信
按照低能耗藍牙協(xié)議,通信可以是多點廣播,也可以是點對點連接。BlueVoice應用鏈路層使用連接通信模式,在兩個設備之間建立永久性的點對點連接,這兩個設備扮演兩個不同的角色:中央設備和周邊設備。中央設備又稱主設備,支持與周邊設備(從設備)相關的復雜功能。中央設備是發(fā)起通信連接,執(zhí)行自適應跳頻,數(shù)據(jù)加密,管理通信時序,定義設備間數(shù)據(jù)交換方式。該角色分配符合低能耗藍牙的非對稱設計概,為能效要求高的設備分配更少的工作任務。電池供電的便攜設備通常是從設備,不過,必須說明的是,根據(jù)規(guī)范[1],每個設備在每個連接事件發(fā)生時可單獨發(fā)送數(shù)據(jù),且角色不在數(shù)據(jù)吞吐量上強加限制或優(yōu)先權??紤]到半雙工通信情況,BlueVoice應用可運行在自主的電池供電無線傳感設備上,且這些設備配備麥克風(和最終標量傳感器,如典型物聯(lián)網(wǎng)概念中無處不在的監(jiān)視應用), 因此,角色分配不再與收發(fā)功能有關。
在鏈路層之上,GATT層定義互動設備的客戶機和服務器角色,與前文描述的主設備和從設備無關。服務器是提供信息的設備,而客戶機是請求或接收最新信息的設備。考慮到單向音頻流是非對稱系統(tǒng),裝備麥克風的設備是唯一有語音信息的設備,因此可將其視為通信服務器,另一個設備是客戶機,向服務器發(fā)送信息請求,并接收服務器發(fā)起的含有語音數(shù)據(jù)的更新信息。在雙向通信系統(tǒng)中,語音數(shù)據(jù)是雙向傳輸,架構是對稱的,中央設備和周邊設備都配備麥克風,都可以充當服務器,輸出任何屬性格式的音頻數(shù)據(jù)。同時,服務器也能充當客戶機,發(fā)送信息請求,并接受另一個設備發(fā)送的更新信息。
雙向語音數(shù)據(jù)流是基于服務器以固定間隔向客戶機發(fā)送通知,不需要接收設備發(fā)送請求或回復信號。從設備在上電階段進入廣播模式,以低頻發(fā)送廣播數(shù)據(jù)包,主設備進入搜索模式,掃描是否有其它設備存在,反之亦然。收到廣播數(shù)據(jù)包代表主設備發(fā)現(xiàn)了相關從設備,然后,主設備發(fā)送一個連接請求。在連接建立過程結束后,按照所選的通信傳輸方向:中央設備至周邊設備或周圍設備-中央設備,以固定間隔從服務器向客戶機發(fā)送含有音頻數(shù)據(jù)的異步通知數(shù)據(jù)包。圖3所示是BlueVoice在GATT 層的角色分配。
圖3:BlueVoice配置文件角色分配
評論