引言
VoIP是當今熱門技術，而越來越多的用戶提出了在VoIP網絡的用戶側一端構建起無線網絡，傳統(tǒng)意義上的VoIP終端充當VoIP網關的方案。當前許多解決方案采用了藍牙或其他技術，不難發(fā)現(xiàn)這些技術均有成本高，技術復雜等缺點。飛思卡爾MC13192是一款低功耗的射頻芯片，具有低成本、低功耗、性能穩(wěn)定等優(yōu)點，適用于低速率無線網絡的射頻芯片。用戶可以通過該芯片及zigbee協(xié)議棧實現(xiàn)無線網絡的構建，該技術已經被普遍用于家電控制。本文介紹了一種利用此技術實現(xiàn)VoIP兩路語音通信的方案，是無線語音網絡的一種新的低成本、低功耗的解決方案。
設計實現(xiàn)
MC13192簡介
飛思卡爾MC13192收發(fā)器是一個典型的ZigBee產品。芯片采用16通道、2.4GHz的頻帶，數(shù)據速率為250kb/s。它們可與32位嵌入式控制器(如飛思卡爾的MCF523x系列)協(xié)同使用。MC13192采用標準的4線SPI及7根GPIO與MCU通信，MCU可以通過對SPI的讀寫來設置及獲取MC13192的寄存器，還可以通過對特定GPIO的電平設置來將MC13192的特定引腳置高或者拉低。
MC13192同32位嵌入式處理器的通信
由于處理器及開發(fā)板的差異，MCU同MC13192相聯(lián)接的引腳會有所差異，因此為了實現(xiàn)MC13192同MCU的正常通信，必須首先配置相關引腳的方向及功能，本文所描述的方案基于飛思卡爾MCF5234平臺，該平臺同MC13192的引腳對應關系如表1所示。
引腳的配置分為三部分：QSPI的初始化、GPIO的初始化以及中斷引腳的配置。QSPI和中斷引腳的配置相對比較簡單，下面首先對這兩部分做一個介紹。
QSPI的初始化要完成對模式寄存器及環(huán)繞寄存器的初始化，值得一提的是方式寄存器初始化需要設置宏MCF_QSPI_QMR_BAUD(x)，該宏用于設置QSPI的波特率，括號內的數(shù)值x需要根據硬件環(huán)境及用戶需要的QSPI的時鐘頻率來確定，計算公式為：
x= 系統(tǒng)時鐘頻率
4xQSPI時鐘頻率
MCF5234的時鐘頻率為150MHz，在本系統(tǒng)中使用的QSPI的頻率為2MHz,因此波特率數(shù)值約等于19。對于中斷引腳的初始化則更為簡單，初始化過程包括觸發(fā)方式、引腳方向以及中斷允許三步。其中觸發(fā)方式需要選擇下降沿觸發(fā)，引腳方向要設置為輸出，由于MC13192使用IRQ3，因此最后要允許來自IRQ3的中斷。
GPIO的初始化主要分為三步：引腳配置，方向寄存器初始化，以及數(shù)據寄存器的初始化。首先需要將要使用的GPIO引腳配置為GPIO功能，然后要將這些引腳配置為輸出(因為這些引腳均被MCU用來控制MC13192，方向是從MCU輸出)，最后要將這些引腳上的數(shù)據配置為初始值。
通過以上步驟，就完成了射頻芯片和MCU的引腳聯(lián)接，可以進行下一步的設計。
IEEE 802.15.4協(xié)議MAC層的實現(xiàn)
由于本方案需要通過射頻芯片來進行語音數(shù)據的傳輸，因此需要一個可靠的MAC層協(xié)議的支持，可以采用IEEE802.15.4協(xié)議的一部分來滿足本方案的要求，由于MC13192包含4個定時器，因此可以利用這4個定時器來劃分時槽從而實現(xiàn)時分復用。
網絡結構設計
本方案實現(xiàn)了兩路語音通信，即兩個手持設備通過無線網絡與網關進行通信，網關通過有線網絡連接到因特網。手持設備可以同時與外界進行通話。
MAC協(xié)議設計
本方案采用時槽的方式實現(xiàn)兩路語音的復用，因此需要手持設備和網關之間時槽的嚴格同步。根據協(xié)議，每16個時槽作為一個超幀，網關在每個超幀的第一個時槽發(fā)送Baecon幀，第2到第8時槽是競爭時槽，因此在本方案中保留這7個時槽，第9到第16時槽是無競爭時槽，用于時分復用，在本方案中，將8個時槽分為4部分，分別用于兩個手持設備的上下行數(shù)據傳輸。
MAC協(xié)議的實現(xiàn)
MC13192自帶有4個定時器，每個定時器定時結束時產生一個中斷，可以通過MC13192中斷狀態(tài)寄存器獲知中斷源，例如，當定時器1定時結束，則會產生一個中斷，此時的中斷狀態(tài)寄存器的第9位被置高，因此在中斷服務程序中加入對定時器中斷的處理，可以實現(xiàn)時槽的劃分，并且根據當前的時槽數(shù)來決定數(shù)據的收發(fā)，可以實現(xiàn)MAC層協(xié)議所要求的功能。在本設計中，我們采用30ms作為一個超幀的長度。以網關為例，處理定時器中斷的程序如下所示：
if(u16StatusContent & TIMER1_IRQ_MASK)
//中斷類別為定時器1中斷
{
time_slot++; //每次超時都將時槽加1
if(time_slot==16)
time_slot=0; //時槽數(shù)的合法數(shù)值為0-15
PLMEEnableMC13192Timer1(1875);
//每個時槽的長度為1.875ms
switch(time_slot)
{
case 0: LoadBaecon(&tx_pkt);//讀取一個Baecon
MCPSDataRequest(&tx_pkt);//發(fā)送Baecon
break;
case 8:
MLMERXEnableRequest(&rx_pkt1,0);
//打開接收天線，并將數(shù)據保存到rx_pkt1
break;
case 9:
MLMERXEnableRequest(&rx_pkt2,0);
break;
case 10:
LoadPacket(&tx_pkt,0,1); //讀取一個數(shù)據包
MCPSDataRequest(&tx_pkt);//發(fā)送數(shù)據
case 11:
LoadPacket(&tx_pkt,0,1); //讀取一個數(shù)據包
MCPSDataRequest(&tx_pkt);//發(fā)送數(shù)據
//12-15時槽略
}}
手持設備的程序設計與網關設計大同小異，所不同的是，網關在每個超幀的開始自動發(fā)送Baecon，而手持設備則被動的接收Baecon，每次收到Baecon之后才打開定時器來劃分時槽，而第15個時槽完畢后，手持設備需要打開接收天線以接收下一個超幀的Baecon。
MC13192與語音編解碼器及網絡設備的協(xié)同工作
因為MC13192支持的速率僅為250kbit/s，因此在網關與手持設備之間必須只能傳輸編碼后的語音數(shù)據。在選擇編解碼方案之前，首先需要粗略估計一下帶寬，由于極限速率為250Kbit/s，而由于協(xié)議所限，僅有一半時槽可供使用，即125Kbit/s，供兩個設備上下行使用。這樣，每個設備的單向極限速率僅為31.25kbit/s。而MC13192自身的切換時間為144us，而如2.3.3節(jié)描述，30ms為一個超幀，每個時槽長度為1.875ms，再加上物理層頭部的消耗，每設備單項可用速率約為20kbit/s。所以，在本方案中選用ITU-T G.726作為語音編解碼方案。G.726語音編碼消耗帶寬16kbit/s，可以滿足MC13192的帶寬要求。
對于網關而言，需要記錄每個手持設備的通話對象，它通過MC13192及802.15.4 MAC協(xié)議獲得時槽中的數(shù)據，根據對應的時槽確定數(shù)據屬于哪個手持設備。最后將收到的語音數(shù)據封裝成RTP包發(fā)送到手持設備的目的地。對于從網絡上收到的語音數(shù)據，則需要確定屬于哪一個手持設備，再通過MC13192在特定的時槽發(fā)送出去。
對于手持設備則比較簡單，它只需要在特定的時槽發(fā)送要編碼后的數(shù)據，再在特定的時槽接收數(shù)據。
設計總結
該設計方案已經被用于本人參與的基于MC13192的zigbee電話項目中。經過實際測試，在40M范圍內，可以實現(xiàn)無誤碼通信，通話質量優(yōu)良。相對于基于其他技術的同類方案，本方案具有低成本、低功耗等優(yōu)點，是一種比較有經濟和技術價值的設計。
下載文檔
