導語：如何才能寫好一篇網絡協(xié)議規(guī)范，這就需要搜集整理更多的資料和文獻，歡迎閱讀由公務員之家整理的十篇范文，供你借鑒。

篇1

關鍵詞：Libnet；協(xié)議測試；DHCP

中圖分類號：TP311 文獻標識碼：A 文章編號：1009-3044（2013）32-7218-03

計算機網絡在各行業(yè)的廣泛應用促使許多新的協(xié)議規(guī)范被制定，在協(xié)議規(guī)范被實現(xiàn)后投入應用前需要進行測試，全面的網絡協(xié)議測試能夠保證協(xié)議實現(xiàn)按照協(xié)議規(guī)范穩(wěn)定可靠地運行。協(xié)議測試的研究涉及了協(xié)議描述、測試生成、測試集描述法、測試實現(xiàn)等多個環(huán)節(jié)，在這些方面，國內外研究人員經過多年努力達成了很多共識，例如：網絡協(xié)議測試類型包括一致性測試，互操作性測試，性能測試和健壯性測試[1]。測試理論的形式化方法主要包括：SDL，LOTOS，Petri網，Estelle等[2-4]。該文研究的重點是測試實現(xiàn)部分，介紹基于Libnet與WinPcap函數(shù)庫的協(xié)議測試系統(tǒng)的實現(xiàn)方法，并結合DHCP協(xié)議進行測試從而驗證測試系統(tǒng)的有效性。

1 協(xié)議測試技術

網絡協(xié)議測試屬于計算機軟件測試的一個分支，在測試領域中測試方法分為3種：白盒測試、黑盒測試和灰盒測試。白盒測試通過每條語句至少執(zhí)行一次來全面檢查整個程序代碼，而黑盒測試只測試軟件外部可以觀察到的行為，不涉及程序的內部結構。白盒測試的測試能力非常強，但是過程過于復雜，對被測軟件要求也很高。黑盒測試只關心被測軟件的輸入和輸出，測試能力雖然弱了些，但是測試過程本身相對簡單，對被測軟件要求也無特殊要求。灰盒測試是將白盒測試和黑盒測試結合起來形成的一種測試方法，吸收了兩種方法的優(yōu)點。在通信測試中，協(xié)議測試因為協(xié)議實現(xiàn)的復雜性往往采用黑盒測試，它并不檢查協(xié)議代碼，而是按照協(xié)議標準，通過控制觀察被測協(xié)議實現(xiàn)或系統(tǒng)的外部行為對其進行評價。

協(xié)議測試中用來描述特定協(xié)議或協(xié)議族測試的實體稱為測試集，它由多個測試組構成，測試組對應于此協(xié)議族的一個標準協(xié)議規(guī)范，測試例對應于一個標準協(xié)議規(guī)范的某一項功能描述，完成一個測試例可能需要不同的測試過程，一個測試過程的完成需要進行初始化、發(fā)包、收包、比較以及處理結果等步驟，每一個動作稱為一個測試步，它是測試集中最小的單位。在構造用于測試協(xié)議實現(xiàn)的輸入數(shù)據包時采用了Libnet函數(shù)庫，在捕獲協(xié)議實現(xiàn)的反饋輸出數(shù)據包時采用了WinPcap函數(shù)庫，Libnet與WinPcap都是免費開源的函數(shù)庫，它們封裝了常用繁瑣的網絡開發(fā)過程函數(shù)，開放出簡單統(tǒng)一的API接口功能函數(shù)，方便用戶調用，使開發(fā)人員能夠忽略網絡底層細節(jié)的實現(xiàn)，從而專注于程序本身具體功能的設計與開發(fā)。Libnet與WinPcap都是基于C語言的函數(shù)庫，具備低層網絡數(shù)據包操控能力。

2 測試系統(tǒng)總體結構

測試系統(tǒng)包括測試集管理，測試例構造與測試結果管理3個功能模塊，系統(tǒng)執(zhí)行測試時的順序與測試例構造模塊中構造的測試步順序一致。在對被測系統(tǒng)開始測試前需要針對協(xié)議規(guī)范設計測試例，所有測試例由測試集管理模塊維護，最終的測試結果生成依賴測試例的執(zhí)行結果。測試例由許多測試步組成，測試步包括兩種執(zhí)行邏輯：激勵數(shù)據包發(fā)送和反饋數(shù)據包捕獲。發(fā)送的激勵數(shù)據包根據被測協(xié)議的類型與數(shù)據報文的類型設定首部各字段與報文數(shù)據，它的作用是激勵被測系統(tǒng)內部產生狀態(tài)變遷并發(fā)送反饋數(shù)據包。測試系統(tǒng)能夠實時捕獲所有數(shù)據包，根據filter條件過濾后選出特定報文并與測試步匹配，根據匹配結果系統(tǒng)決定測試步執(zhí)行狀態(tài)：丟棄報文繼續(xù)阻塞，定時器清零繼續(xù)下一測試步或者測試完成。在測試步執(zhí)行過程中設置定時器，定時器時間的指定在測試例構造中完成。測試系統(tǒng)的總體結構如圖1所示。

3 測試系統(tǒng)的設計與實現(xiàn)

本測試系統(tǒng)與被測實體部署在同一個交換網絡中，被測實體是特定協(xié)議的一個實現(xiàn)，可以位于計算機或路由器等網絡設備中，通過構造特定數(shù)據包并且捕獲響應報文對協(xié)議外部行為進行分析測試。關鍵模塊包括測試例構造，數(shù)據包構造與發(fā)送，數(shù)據包捕獲與過濾。

3.1 測試例構造

系統(tǒng)實現(xiàn)時在測試例的構造模塊中設置了行為選項來區(qū)分發(fā)送數(shù)據包與捕獲數(shù)據包，測試步間隔時間選項用于控制相鄰測試步執(zhí)行的時機。對于發(fā)送數(shù)據包，根據協(xié)議的類型構造數(shù)據包設置頁面，在此頁面中設置首部字段與數(shù)據包內容，由于libnet提供自動計算校驗和功能，此頁面中首部校驗和字段設置為0。對于捕獲數(shù)據包，設置了匹配選項與傳遞選項，匹配選項用于判定數(shù)據包特征并觸發(fā)下一測試步，傳遞選項用于決定是否需要將捕獲數(shù)據定字段復制到下一測試步發(fā)送數(shù)據包特定字段中以及復制內容。對構造完的測試例啟用測試將順序執(zhí)行其中的測試步，遇到捕獲測試步將阻塞并啟用超時定時器，每一個測試步執(zhí)行過程都記錄在日志文件中。

3.2 數(shù)據包構造與發(fā)送

系統(tǒng)實現(xiàn)使用Libnet函數(shù)庫構造底層數(shù)據包，在依照協(xié)議字段長度與類型對測試例中設置的各字段進行合法性校驗后調用libnet_init （）函數(shù)初始化函數(shù)庫，此函數(shù)調用了WSAStartup（）函數(shù)開啟網絡，同時分配一塊內存區(qū)域建立libnet_t結構并返回此結構的描述符，這個描述符作為參數(shù)傳遞給構造數(shù)據包函數(shù)和發(fā)送數(shù)據包函數(shù)。測試步中設置的協(xié)議及各字段進行格式轉換后傳遞給構造數(shù)據包函數(shù)，數(shù)據包構造函數(shù)根據協(xié)議族中的位置自頂向下建立數(shù)據報文頭部，待發(fā)送的數(shù)據作為協(xié)議首部的有效載荷被加載，構造函數(shù)具備自動計算協(xié)議首部校驗和字段的功能。測試報文發(fā)送函數(shù)根據協(xié)議類型調用socket函數(shù)將已構造好的緩沖區(qū)中的數(shù)據通過網卡發(fā)送到網絡上，它的函數(shù)原型為：int libnet_write（libnet_t *l），此函數(shù)實現(xiàn)中調用了函數(shù)PacketSendPacket（），此函數(shù)在頭文件packet32.h中聲明，Packet32.lib與Packet32.dll是相應的靜態(tài)鏈接庫與動態(tài)鏈接庫。WinPcap開發(fā)包中自帶了Packet32，在工程項目中需要設置合適的系統(tǒng)路徑。測試完成后使用libnet_destroy（）函數(shù)來釋放所占用的SOCKET連接、緩沖區(qū)等資源。

3.3 數(shù)據包捕獲與過濾

捕獲響應數(shù)據包使用WinPcap函數(shù)庫，它的核心是NPF協(xié)議驅動，符合NDIS規(guī)范。在捕獲數(shù)據包的線程里使用pcap_open（）打開網絡接口，pcap_next_ex（）讀取網卡接收的數(shù)據包，網卡在混雜模式會捕獲大量的數(shù)據包，如果逐一比對測試步將消耗大量資源，在系統(tǒng)實現(xiàn)時調用pcap_setfilter（）設置數(shù)據包過濾器，在調用pcap_setfilter前先使用pcap_compile（）函數(shù)把高層的過濾規(guī)則解釋成能被過濾引擎集成到數(shù)據包驅動中的低級字節(jié)碼。

4 DHCP協(xié)議測試與結果分析

在對特定協(xié)議進行測試時需要根據協(xié)議的行為特征設計測試拓撲。某些協(xié)議的數(shù)據交換行為局限于測試平臺與被測實體間，這種情況下只需將其部署在交換環(huán)境下即可，例如TCP協(xié)議的測試。而對于路由協(xié)議這樣的協(xié)議而言，則需要設計更為復雜的拓撲，路由器的多個端口都需要部署測試平臺進行協(xié)同測試。在協(xié)議安全性測試時借助交換機端口映射功能可以模擬攻擊的拓撲結構。

為驗證測試平臺的有效性，選擇DHCP協(xié)議進行測試。DHCP協(xié)議動態(tài)管理IP地址，工作在傳輸層之上，使用UDP提供的服務。其數(shù)據包封裝格式如圖2所示：

依照圖2中DHCP數(shù)據包封裝的結構，在構造DHCP數(shù)據包時調用函數(shù)依次為libnet_build_dhcpv4（），libnet_build_udp（），libnet_build_ipv4（），libnet_autobuild_ethernet（），Winpcap過濾DHCP數(shù)據包使用協(xié)議限定符“bootp”。測試采用的拓撲如圖3所示：

測試拓撲中使用路由器作為DHCP服務器，在路由器上啟用DHCP server服務，并且配置地址池、網關、地址租期等信息。

ip dhcp excluded-address 172.16.1.1 172.16.1.100

ip dhcp pool net172

network 172.16.1.0 255.255.255.0

default-router 172.16.1.254

dns-server 172.16.1.253

lease 30

在測試機上設置測試例Ts_sc，配置測試步：TS_DHCPDISCOVER，TS_DHCPOFFER，TS_DHCPREQUEST和TS_DHCPACK，其中TS_DHCPDISCOVER和TS_DHCPREQUEST是構造的激勵數(shù)據報文，TS_DHCPOFFER與TS_DHCPACK為反饋數(shù)據報文。測試系統(tǒng)上啟用測試執(zhí)行Ts_sc測試例，在路由器上啟用DHCP event調試，調試信息顯示路由器DHCP服務狀態(tài)發(fā)生變化，測試系統(tǒng)完成所有測試步后成功獲得172.16.1.0網段IP，使用show ip dhcp server statistics查看DHCP服務器統(tǒng)計信息，與測試系統(tǒng)結果一致。

5 結束語

本文基于Libnet與WinPcap函數(shù)庫設計并實現(xiàn)了一個網絡協(xié)議測試系統(tǒng)。在用于協(xié)議一致性測試時可手工設置測試用例，靈活配置協(xié)議首部字段，能夠對常見網絡協(xié)議進行測試。在用于網絡性能測試時可以設置數(shù)據包類型與數(shù)據包的發(fā)送數(shù)量，網絡注入速度受數(shù)據包長度與網卡接口速度、交換機背板帶寬等因素限制，可分布多臺測試系統(tǒng)在網絡中同時注入從而提高注入速度。經過多年的研究，在協(xié)議一致性測試集自動生成技術方面，研究人員提出了多種可行的方法，下一步的主要工作是整合測試集自動生成技術從而完成協(xié)議自動測試，同時進一步完善支持的協(xié)議類型，增強擴展性。

參考文獻：

[1] 畢軍，史美林.計算機網絡協(xié)議測試及其發(fā)展[J].電信科學，1996（12）：51-54.

[2] 章韻，楊庚，錢恩淵.基于SDL語言的通信協(xié)議系統(tǒng)設計方法[J].計算機工程與應用，2001（22）：95-98.

[3] 潘紅艷，于全.用于通信網絡協(xié)議開發(fā)的形式化方法[J].計算機工程，2004（2）：129-134.

[4] 羅軍舟，沈俊，顧冠群.從Petri網到形式描述技術和協(xié)議工程[J].軟件學報，2000（5）：606-615.

[5] 劉瀏，陳曉梅.基于測試套優(yōu)化的DHCP協(xié)議一致性可擴展測試系統(tǒng)設計[J].信息網絡安全，2012（8）：206-209.

[6] 程方，王鵬.現(xiàn)代網絡測試技術發(fā)展綜述[J].重慶郵電大學學報：自然科學版，2008（6）：57-60.

[7] 劉洪霞，趙保華.基于協(xié)議實現(xiàn)的網絡安全測試[J].小型微型計算機系統(tǒng)，2007（4）：619-621.

[8] 尹霞，王之梁，景傳明，施新剛.一種基于TTCN-3的協(xié)議測試系統(tǒng)及其擴展研究[J].中國科學：E輯：信息科學，2008（10）：1594-1613.

[9] 李堯，胡玲，郝文.基于狀態(tài)的自動化無線協(xié)議安全測試平臺設計[J].計算機應用與軟件，2012（11）：168-171.

篇2

【關鍵詞】EtherCAT ETG GB/T

一、引言

EtherCAT作為最新一代的開放的實時以太網現(xiàn)場總線協(xié)議，最早是由德國的倍福自動化有限公司（Beckhoff Automation GmbH）研發(fā)。現(xiàn)在由EtherCAT技術協(xié)會（EtherCAT Technology Group，簡稱ETG）來統(tǒng)一組織和管理。EtherCAT技術是基于工業(yè)以太網技術的開發(fā)的，這樣的話，用戶只需要主板集成的MAC口或者廉價的標準網卡，就可以完成組態(tài)，系統(tǒng)價格與其余現(xiàn)場總線相當，甚至是更加便宜。但是相比其他現(xiàn)場總線技術，性能卻要強勁許多，包括65535個從站節(jié)點，自動設置地址，通訊速度更快等等。所以，EtherCAT非常適用于高速、精密控制等場合。現(xiàn)在，EtherCAT技術已經廣泛地應用于設備控制、機器人、嵌入式系統(tǒng)、樓宇自動化、運輸系統(tǒng)等領域，并且呈現(xiàn)出越發(fā)強勁的發(fā)展勢頭。有鑒于此，國家標準化委員會正在積極地為EtherCAT制定相應的國家標準，筆者有幸參與了送審稿的翻譯和校隊工作。本文通過對EtherCAT的技術優(yōu)勢的分析，國家標準化的制定流程，工業(yè)以太網國標送審稿的研究，總結EtherCAT現(xiàn)場總線的優(yōu)勢，并給出相應的依據。

二、EtherCAT現(xiàn)場總線優(yōu)勢

（一）開放性

EtherCAT的協(xié)議是完全公開的；并且已經成為了IEC、ISO及SEMI的標準協(xié)議。對應的協(xié)議號是IEC61158、IEC61784、ISO15745和SEMI E54.20， 并且我國正在為其指定國家標準。

為了推廣技術和保證技術的開放性，以技術主要發(fā)起人為主，成立了EtherCAT技術小組。小組的主要任務是支持、完善和推廣EtherCAT技術。截止2012年7月2日，ETG共計有2050個會員，光是從2011年的5月到2012年的5月，就新增加了超過380個會員[1]。現(xiàn)在ETG已經成為了全球最大的現(xiàn)場總線組織[1]。在中國，截止2012年2月，中國區(qū)共有超過200個會員，也正是因為EtherCAT在我國的蓬勃發(fā)展，所以國家急需要制定相應的國家標準。

（二）高速性

EtherCAT突破了其他以太網解決方案固有的局限性：從站設備在報文經過其節(jié)點時讀取帶有相應尋址信息的數(shù)據；同樣，輸入數(shù)據也是在報文經過時插入至報文中。整個過程，報文只有幾個納秒的時間延遲。這樣發(fā)送和接收的以太網幀壓縮了大量數(shù)據，所以通道的利用率可以達到90%，100Mb/s的全雙工特性可以完全得到利用。

下面舉一個具體的例子來更好的體現(xiàn)EtherCAT的高速性[2]。

在一個有40軸（每軸20字節(jié)輸入輸出數(shù)據）、50個I/O站、2000個數(shù)字量和200個模擬量的總線環(huán)境下，各種工業(yè)以太網技術的循環(huán)時間如下表所示：

（三）低價

過去的現(xiàn)場總線無論主站還是從站設備都需要專用的設備，整個系統(tǒng)構建下來花費不小。使用EtherCAT技術的成本可以做到更低。

從硬件角度看，主站不需要專用插卡，集成的網口就可以滿足要求了，現(xiàn)在許多的自動化設備都標配有網口，這樣就不需要新的成本投入；從站采用低成本的從站控制器FPGA或者ASIC，不需要功能強大的微處理器；輔助設備方面，不需要交換機/集線器，只要使用標準的以太網線纜和接頭就可以完成網絡組態(tài)了。

下面我們用一個網絡配置的實例來說明[2]：

如果我們要配置一個擁有10個站點，400個數(shù)字輸入，400個數(shù)字輸出的，100米長線纜，11個現(xiàn)場總線接頭的網絡。EtherCAT網絡的總成本是最低的。Profibus貴了21.5%，DeviceNet貴了23.7%，CAN Open貴了21.9%.

三、EtherCAT現(xiàn)場總線標準化

（一）中國國家標準

我國將標準劃分為四個層次，即國家標準、行業(yè)標準、地方標準、企業(yè)標準。各層次之間有一定的依從關系和內在聯(lián)系，形成一個覆蓋全國又層次分明的標準體系。

國家標準分為強制性國標（簡稱GB）、推薦性國標（簡稱GB/T）和指導性國家標準（GB/Z）。

EtherCAT在我們申請的國標是GB/T，推薦性國家標準。

GB/T是指推薦性國家標準，其中的“T”是推薦的意思。推薦性國標是指生產、交換、使用等方面，通過經濟手段調節(jié)而自愿采用的一類標準，又稱自愿標準。但推薦性標準國標一經接受并采用，或各方商定同意納入經濟合同中，就成為各方必須遵守的技術依據，具有法律上的約束性。

（二）申請國家標準的條件

現(xiàn)場總線的種類繁多，但是真正入選成為我國國家標準的現(xiàn)場總線并不多。這是因為在我國工業(yè)控制網絡標準的制定是需要滿足對應的條件的[4]。

申請GB/T需要滿足下面的兩個條件：1.國內有產品開發(fā)、生產；2.測試本體化。如上文所述，ETG在中國國內的會員超過200位，提供了許多的EtherCAT相關產品，所以第一個條件滿足。對于測試本土化，現(xiàn)在ETG已經在中國北京航空航天大學的數(shù)控與自動化實驗室（LNC）建立了測試中心，這為EtherCAT在我國的標準化掃清了最后的障礙。

（三） 國標制作流程

工作組成員一般分為國內專家小組和國外專家小組。包括制造商、最終用戶、集成商等成員。委員會審核通過的標準是75%以上成員贊成25%以下反對，如果委員會由超過25%以上成員反對，那么就需要重新審議項目。

EtherCAT申請國標的工作從2012年2月份開始正式啟動，2012年7月成立了工作組，前后經過1年左右的翻譯、校隊工作后，2013年的2月份發(fā)出了征求意見稿，2013年6月發(fā)出送審稿，現(xiàn)在正在收集送審稿的投票工作，預計在2013

（四） EtherCAT國標整體結構

國標共分為6個部分。

第一部分：概述

第二部分：物理層服務和協(xié)議規(guī)范

第三部分：數(shù)據鏈路層服務定義

第四部分：數(shù)據鏈路層協(xié)議規(guī)范

第五部分：應用層服務定義

第六部分：應用層協(xié)議規(guī)范

EtherCAT國標內容是使用翻譯法修改采用ETG.1000《EtherCAT規(guī)范》[5]，在技術內容上與原國際標準沒有差異，對文本進行了適當?shù)木庉嬓哉{整。

EtherCAT文檔結構和OSI模型的對應關系如圖3所示

所有的網絡協(xié)議都是基于OSI網絡模型的，EtherCAT也不例外。EtherCAT總共使用了OSI中的應用層、數(shù)據鏈路層和物理層，而第3到第6層沒有在EtherCAT中實現(xiàn)。這樣保證了EtherCAT協(xié)議的簡潔、高效，正因為剝離了IP，TCP等傳統(tǒng)的以太網網絡層、傳輸層實現(xiàn)，所以使得EtherCAT的實時性得到了極大的保證。

四、結論

EtherCAT總線協(xié)議有許多吸引自控行業(yè)的特點：高速、開放、安全、冗余。正因為如此，該技術自誕生起就取得了飛速的發(fā)展。鑒于此，國家標準機構正在積極的推進EtherCAT的國標化。

本文介紹了國標制作的流程、條件，并且說明了EtherCAT國標文檔的結構。對EtherCAT總線技術的進一步發(fā)展和應用具有一定的意義，對于其他現(xiàn)場總線相關的研究亦有一定的參考價值。

參考文獻：

[1] EtherCAT Technology Group， EtherCAT工業(yè)以太網現(xiàn)場總線，2012

[2] EtherCAT Technology Group， Industrial Ethernet Technologies： Overview，2011

[3] 國際電工委員會， Serving global industrial automation ： IEC publishes new Field Standard. 2012-12-14

[4] EtherCAT技術協(xié)會， 一致性與互操作性， 2011

[5] EtherCAT技術協(xié)會，EtherCAT規(guī)范， 2013

作者簡介：

篇3

關鍵詞：信令分析；呼叫失敗；感知；滿意度

1 引言

信令分析是運營商網絡故障定位的常用手段，近年來基于信令分析進行網絡故障定位、隱患排查等項目也逐步在國內各運營商鋪開，但從項目的成果看，大多停留在分析研究上，并未能將這些成果很好的落地。筆者從大量信令分析服務項目成果中進行總結與提煉，提出一種基于呼叫失敗信令分析的提醒服務方案，旨在幫助運營商通過提升用戶感知度，強化運營商的競爭力，達到用戶、運營商雙方得益的局面。

2 呼叫失敗的現(xiàn)狀

呼叫失敗是指主叫用戶撥打號碼后，在還沒有聽到回鈴音之前，由網絡下發(fā)釋放消息、中止呼叫。呼叫失敗時，主叫用戶一般都能聽到網絡下發(fā)的通知音解釋本次呼叫未能接通的原因，但是還有相當數(shù)量的呼叫失敗表現(xiàn)為主叫用戶呼叫后直接返回待機狀態(tài)，沒有任何解釋，這類呼叫失敗現(xiàn)象會嚴重影響用戶感知度，而且會造成其他負面后果，主要表現(xiàn)為以下兩方面：

⑴用戶會懷疑運營商的網絡質量問題，對運營商失去信心，久而久之將極有可能導致用戶流失；

⑵大量用戶出現(xiàn)呼叫失敗而又沒有任何提示時，一般會繼續(xù)多次撥打，存在著引發(fā)“雪崩效應”的隱患，使站點或交換機負荷過高而癱瘓，引發(fā)更為嚴重的通信故障。

事實上，這些呼叫失敗并非都是網絡質量問題導致。移動通信是一個復雜的系統(tǒng)，用戶的行為、手機終端、業(yè)務功能等方面因素都有可能導致呼叫失敗，但是對于用戶來說，用戶并不知道其呼叫失敗的原因，用戶在遇到呼叫失敗時會迷惘，不知所措。所謂“知情就是力量”，不管是什么原因導致的呼叫失敗，只要能第一時間告知用戶，或許用戶的感受、行為就能發(fā)生根本性的變化。

3 基于信令的呼叫失敗分析

呼叫失敗在信令流程中表現(xiàn)為用戶發(fā)起“CM_SERVICE_REQUEST”消息后，在其后的流程中沒有收到ALERTING、CONNECT、CONNECT_ACK等接通的消息，而由網絡側下發(fā)釋放消息中止呼叫。

網絡下發(fā)的釋放消息一般有“CM_SERVICE_REJECT”和“DISCONNECT”兩種，前者是在CM服務尚未建立就被網絡中止呼叫，后者一般為CM服務建立后網絡下發(fā)的釋放消息，但這些釋放消息都帶有一個原因值，一般稱為Cause值，指示了本次釋放的原因，這些Cause值都可以在3GPP協(xié)議規(guī)范中找到其解釋，有些解釋很明顯的指示了失敗原因，如電路擁塞、無線資源不可用等，也有些解釋比較籠統(tǒng)，如DTAP_CC層的Temporary failure、DTAP_MM層的Network failure等，從Cause的字面解釋無法知道釋放消息的真正原因，這時就需要根據本次呼叫失敗的信令模型、用戶行為、多接口關聯(lián)等分析手段對呼叫失敗進行原因追查。

3.1 基于信令的呼叫失敗分析一般流程如下

⑴建立A接口呼叫失敗的呼叫模型，即手機主叫發(fā)起CM SERVICE REQUEST，在A接口會話中，沒有ALERTING、CONNECT，排除正常的呼叫終結Cause值。

⑵統(tǒng)計A接口上釋放消息所帶的Cause值，并進行數(shù)量的上排序。

⑶對數(shù)量較大、異常的Cause值進行原因追查，查詢下放釋放消息的前一條消息的詳細內容，如仍無法明確原因則需要進行多接口關聯(lián)，直至關聯(lián)到被叫端無線側，追蹤下發(fā)釋放消息的根節(jié)點，如在根節(jié)點仍無法明確原因，則需要查詢用戶行為，看是否由用戶行為導致的呼叫失敗。

⑷對明確原因的Cause提出優(yōu)化建議及實施。

3.2 我們一般將呼叫失敗原因歸為四種類型

⑴由于無線環(huán)境質差導致的呼叫失敗

⑵由于核心網存在隱患、故障引發(fā)的呼叫失敗

⑶由于用戶行為導致的呼叫失敗

⑷由于用戶終端導致的呼叫失敗

基于信令分析的呼叫失敗優(yōu)化項目能對前兩種原因引起的呼叫失敗進行優(yōu)化，而對于后兩類原因只停留在分析研究上，其成果效益并不明顯。

4 主叫用戶提醒方案設計

4.1 呼叫失敗提醒的設計框架

呼叫失敗用戶提醒的核心思想是將基于呼叫信令的分析成果進行落地，將研究成果真正惠及用戶，其整體設計框架如下所示：

⑴當用戶出現(xiàn)呼叫失敗時，其信令數(shù)據被信令采集設備所采集、解碼并存入信令數(shù)據庫。

⑵信令系統(tǒng)對呼叫失敗的會話進行建模，建模要點包括會話所包含的消息、釋放消息攜帶的Cause值、釋放消息出現(xiàn)的位置。

⑶將建立呼叫失敗模型與呼叫失敗模型庫進行比較匹配，如果匹配成功，則根據呼叫失敗模型庫中對該呼叫失敗模型的原因解釋以及用戶操作建議以短信的形式發(fā)送給用戶。

⑷如果匹配不成功，則需要對該種類型的呼叫失敗模型進行研究，追蹤其失敗原因，再將新的成果輸入到呼叫失敗模型庫中去。

圖中循環(huán)1是信令分析應用部分，即為用戶提供呼叫失敗提醒功能；循環(huán)2相當于一個改進系統(tǒng)，為系統(tǒng)提供持續(xù)動力，令整個呼叫失敗提醒功能不斷完善，不斷適應復雜的環(huán)境。

4.2 方案拓撲結構

呼叫失敗提醒方案是以信令分析為基礎一種解決方案，需要對現(xiàn)網各接口進行信令搭接，其拓撲結構如下圖：

信令搭接的涉及到的網絡接口和協(xié)議有：

⑴Mc接口，主要采集BSSAP、RANAP、H.248、BICC協(xié)議的信令數(shù)據（適用于IP化軟交換局）

⑵A接口，主要采集BSSAP協(xié)議的信令數(shù)據（適用于傳統(tǒng)非軟交換局）

⑶C接口（MSC-S＼MSC與LSTP的接口），主要采集MAP協(xié)議的信令數(shù)據

⑷A-bis接口，采集BSC側以下的信令數(shù)據

信令采集系統(tǒng)通過IP網絡與短信中心建立連接，為給用戶下發(fā)短信建立通道。

4.3 應用案例

用戶在某一建了MSC IN POOL的城市出現(xiàn)呼叫困難現(xiàn)象，而在其它非POOL城市則能正常使用。具體表現(xiàn)為每次呼叫需要重復撥7-8次才能呼叫成功，呼叫失敗時手機顯示“連接錯誤”。

信令系統(tǒng)捕捉到該用戶的呼叫失敗信令流程，如下所示：

用戶在呼叫過程中收到網絡下發(fā)CM_SERVICE_REJECT攜帶Dtap_Cause_4，協(xié)議規(guī)范解釋為“IMSI UNKNOW IN VLR”。

系統(tǒng)將該呼叫失敗模型與已知的呼叫失敗模型庫進行匹配，得到該呼叫失敗的原因以及用戶操作建議：

系統(tǒng)提取呼叫失敗模型庫中該呼叫失敗的提醒短信內容，及時向主叫用戶發(fā)送呼叫失敗提醒短信。

上述案例為非網絡質量導致的呼叫失敗，如果沒有呼叫失敗用戶提醒短信，用戶會由于不知情而懷疑運營商的網絡質量。呼叫失敗用戶提醒短信可以消除用戶的疑惑，既讓用戶明白其呼叫失敗并非網絡原因，及時改變聯(lián)系方式避免誤事，又能讓用戶感受到運營商的貼心服務和技術含量，增加了用戶對運營商的認同感與依賴度，可謂一舉多得。

5 小結

通過對各類呼叫失敗過程的信令監(jiān)測，結合模型庫數(shù)據的比對，分析呼叫失敗的原因，通過短信方式將呼叫失敗的原因、用戶操作建議及時地送達客戶，讓客戶感受到運營商的貼心服務，是一種“以人為本”的服務理念。在高速發(fā)展的移動通信市場上，運營商必須采用創(chuàng)新的手段為客戶提供新的亮點，增強用戶感知度、吸引用戶、留住用戶，方能在激烈的市場競爭中領先一步。

[參考文獻]

[1]袁永福，洪燁.GSM手機引起用戶感知度下降的原因.通信管理與技術，2008，（2）

篇4

1.1信息家電網絡系統(tǒng)的體系結構

電力線信息家電網絡系統(tǒng)是以家庭電力線作為傳輸介質的局域網，就網絡本身而言，它符合通用的4層網絡體系結構．根據目前家庭網絡所承擔的主要業(yè)務，從網絡分層的角度可以將信息家電網絡系統(tǒng)分為3層．

(1)物理介質層(Media)是信息家電網絡的物理層，以電力線為傳輸介質，以擴頻載波技術(SpreadSpectrumCarrier，SSC)為信號傳輸基礎．

(2)底層協(xié)議層(Protocol)對應于OSI參考模型的數(shù)據鏈路層和網絡層．數(shù)據通信采用帶有避免沖突的載波偵聽多路訪問(CSMA/CA)機制來確保數(shù)據包按照最快的路徑正確收發(fā)．網絡控制層從底層接收數(shù)據，并為信息家電協(xié)議提供接口．

(3)應用程序接口層(API)是信息家電網絡的應用層，擔負著實現(xiàn)信息家電網絡內部管理以及與外部互聯(lián)網絡信息交互的重任．具體包含的功能有數(shù)據格式轉化，信息家電功能狀態(tài)解析，信息家電服務控制管理等．

1.2協(xié)議規(guī)范

電力線信息家電網絡是按層的方式來組織的，每一層都建立在其下層之上，這種協(xié)議分層設計的方式也符合當前軟件設計結構化和面向對象的思想．

(1)介質訪問協(xié)議在信息家電網絡中，由于在一條電力線上接入了多個信息家電設備，而每個設備之間是平等的，沒有專門的控制中心來負責對通信信道的訪問，對時隙也不進行預先分配，因此需要采用預約信道的方式，即采用帶有避免沖突的載波偵聽多路訪問機制來避免數(shù)據包出錯．由于每個設備遇到沖突后隨機等待的時間不同，因此可以大大減少數(shù)據沖突的機會，但這種等待時間的隨機性，也造成了延時時間的不可預測，從而影響到信息家電的使用效率．

(2)通信協(xié)議基于電力線的優(yōu)勢，信息家電可以根據不同的需要和功能使用不同的標準和協(xié)議，如X-10，CEBus，LonWorks等．X-10接口技術是一種以電力線作為信號傳輸介質，為家庭用戶提供家用電器的遠程控制、家庭安全控制等方面應用的通信協(xié)議．CEBus是一種針對現(xiàn)代智能家庭電子產品的開放性協(xié)議(KIA-600協(xié)議)．CEBus物理層中使用最廣泛的傳輸介質就是電力線，電力線載波信號在其上進行傳輸時數(shù)據傳輸速率可達10GB/s，完全可以滿足信息家電的高速通信需求．LonWorks技術的LonTalk通訊協(xié)議提供了OSI參考模型中定義的全部7層服務，便于將家用電器、電表、燈光控制設備等互相連接并與互聯(lián)網絡集成，主要適用于信息家電網絡中的安全控制設備．物理層使用電力線通信技術時通信速度可達5．4kB/s．

(3)網絡協(xié)議UPnP(universalplugandplay)協(xié)議使用開放的標準協(xié)議和通用的網絡媒體，不僅適用于電源線網絡，而且其設備架構更適合于信息家電網絡中的設備識別和訪問控制．由于它是一種即插即用協(xié)議，因此便于信息家電的自動發(fā)現(xiàn)與連接、自動控制以及網絡互連．

1.3信息家電網絡系統(tǒng)的硬件設計方案

基于電力線通信的信息家電網絡系統(tǒng)硬件架構．其硬件平臺實現(xiàn)的基礎是在信息家電和其他智能家用設備內部嵌入PLC芯片，作為接入互聯(lián)網絡的接口．許多新型家電設備內部都置有微控制器，將PLC芯片通過標準的輸入輸出接口與各種微控制器相接，就可以實現(xiàn)信息家電網絡內部設備之間的通信以及與外部網絡的連接．信息家電、監(jiān)控設備、計算機等家庭設備若想共享互聯(lián)網資源，還必須在電力線上連接一個PLC路由器作為選通設備．若將PDA等移動設備作為無線接入點，與掛在電力線上的各種設備進行通信時，只需要將無線網絡基站作為內置PLC芯片的信息家電即可．除了完成信息家電網絡內部的通信外，各住宅網絡還可以通過電力線MODEM連接到互聯(lián)網上．PLC網關一方面負責獲取住宅內信息家電的狀態(tài)信息，另一方面負責傳送遠程控制系統(tǒng)的命令，同時將家電的響應信息反饋給遠程控制系統(tǒng)．

2結語

篇5

編者按：現(xiàn)代物流是現(xiàn)代服務的主要內容之一，具有跨部門、多行業(yè)、專業(yè)領域覆蓋面廣的特點。提高物流系統(tǒng)中供應鏈各環(huán)節(jié)的效率、降低物流成本，引起了國內外、業(yè)內外各方人士的普遍關注。本文撰稿人劉放先生，多年從事商業(yè)流通科技研究，是國家級重大基礎研究課題“物流配送標準體系及關鍵標準研究”項目負責人之一。本文是作者根據該項目研究成果濃縮而成。本刊從2013年第2期開始分數(shù)次在《前沿導向》欄目連載，本文是連載之七。

（3）聯(lián)合計劃、預測、補貨作業(yè)流程實施規(guī)范

補貨是指物流及供應鏈上合作伙伴通過共享需求信息、預測信息、資源信息，來實施聯(lián)合計劃、預測和補貨。通過供應鏈中的伙伴相互協(xié)作共享標準化的信息來制定目標計劃、進行有效的市場預測并實施及時訂單補貨，為供應鏈中各個企業(yè)降低庫存成本、減少運營費用、提高銷售額、以實現(xiàn)有關方共贏。聯(lián)合計劃、預測、補貨的目標是改變現(xiàn)有的伙伴關系模式，以更精準的信息使供應鏈各方的銷售額和利潤更大化，其流程表現(xiàn)在四個部分：全面協(xié)議和聯(lián)合商業(yè)計劃（包括各項目小組對銷售、庫存、零售網點分布和商品類型款式在可見未來的變化決策）；銷售預測協(xié)會（零售商和供應商共同需求預測，比較和甄別各自預測曲線的不協(xié)調點，找出問題并修改計劃）；定單預測協(xié)作（零售商和供應商共享補貨計劃，甄別不協(xié)調點并解決之）；定單生成/交貨執(zhí)行（即結果數(shù)據共享，包括銷售地占、定單、運貨班期，現(xiàn)有庫存等，甄別預測準確度的偏差，庫存狀況及執(zhí)行中的問題并予以解決）。

4.基于XML的物流信息交換

在物流系統(tǒng)中，當供應商、制造商、批發(fā)商、零售商和顧客之間傳遞商務及其他物流信息時，雙方的電腦間進行電子數(shù)據的交換方式一般采用EDI方式，按標準協(xié)議規(guī)范化和格式化的業(yè)務信息通過電子數(shù)據網絡，利用增值網或專用網在不同電腦間進行自動交換和處理。但建設EDI增殖網或專用網投資較大，又缺乏開放性。這種以標準固定格式傳遞業(yè)務信息的方式，適用于交易雙方有經常性業(yè)務聯(lián)系的大型企業(yè)之間進行，對于只有偶爾業(yè)務聯(lián)系的企業(yè)間或小企業(yè)就很難實施，而現(xiàn)代物流系統(tǒng)及供應鏈網絡，一方面需要在不同行業(yè)各類企業(yè)間進行廣泛的業(yè)務、商務聯(lián)系；另一方面供應鏈合作伙伴間的戰(zhàn)略聯(lián)盟雖有長期性，但更多的是一種動態(tài)同盟關系，這樣傳統(tǒng)的EDI方式就不適于這種大范圍的、動態(tài)的信息交換，這就必須研制、、宣貫投資少、更開放的物流信息交換標準體系結構。（待續(xù)）

篇6

據研究人員介紹，該系統(tǒng)名為“自行組控藍牙網絡”。該網絡通過在家居環(huán)境中各個需要或開或關的裝置中都嵌入藍牙裝置來組建，無論是各個居室的窗戶或是燈，又或者是各類電器設備，只需要進行相應的改進，便都可以納入該系統(tǒng)之內。

而該系統(tǒng)配備的一個藍牙手機，則成為所有設備的遙控器。只要主人攜帶這部手機回到家中，手機就會通過藍牙裝置自動接入家居環(huán)境中的上述網絡，而無需進行有線連接或是其他的繁瑣操作。這樣，你只需要通過操作手機上簡單的幾個按鈕，便可以對家中的各類設備進行遙控了。

既然藍牙技術這么神奇，那讓我們走進它。

藍牙技術簡介

1. 藍牙簡介

藍牙技術是Ericsson移動通信公司在1994年開始啟動的，1998年5月，Ericsson聯(lián)合Nokia、Intel、IBM、Toshiba這4家公司一起成立了藍牙特別興趣小組（Special Interest Group，SIG），負責藍牙技術標準的制定、產品測試，并協(xié)調各國藍牙的具體使用。3Com、Lucent、Microsoft和Motorola很快加盟SIG，與SIG的5個創(chuàng)始公司一同成為SIG的9個倡導發(fā)起者。自藍牙規(guī)范1.0版推出后，藍牙技術的推廣與應用得到了迅猛發(fā)展。截至目前，SIG的成員已經超過了2500家，幾乎覆蓋了全球各行各業(yè)，包括通信廠商、網絡廠商、外設廠商、芯片廠商、軟件廠商等，甚至消費類電器廠商和汽車制造商也加入了SIG。

“藍牙（Bluetooth）是一個開放性的、短距離無線通信技術標準，也是目前國際上最新的一種公開的無線通信技術規(guī)范。它可以在較小的范圍內，通過無線連接的方式、安全、低成本、低功耗的網絡互聯(lián)，使得近距離內各種通信設備能夠實現(xiàn)無縫資源共享，也可以實現(xiàn)在各種數(shù)字設備之間的語音和數(shù)據通信。由于藍牙技術可以方便地嵌入到單一的CMOS芯片中，因此，特別選用于小型的移動通信設備，使設備去掉了連接電纜的不便，通過無線建立通信。

藍牙技術工作在全球通用的2.4GHz ISM頻段。從理論上講，以2.4GHz ISM頻段運行的技術能使用距30m以內的設備互相連接，但實際上很難達到。現(xiàn)階段，藍牙的發(fā)射范圍可達10m，可以同時實現(xiàn)8臺設備的相互聯(lián)通。當檢測到距離小于10m時，接收設備可動態(tài)地調節(jié)功能；當業(yè)務量減小或停止時，藍牙設備即可進入低功耗工作模式。

2.藍牙中的關鍵技術

2.1 跳頻技術

藍牙工作的頻段是全球通用的2.4GHz ISM頻段。該頻段對所有無線電系統(tǒng)都開放，因此，藍牙在使用過程中經常會遇到不可預測的干擾源，例如手機、無繩電話、微波爐等。這使得藍牙系統(tǒng)的傳送錯誤率遠遠高于實際應用水平，為此，采用跳頻技術是避免干擾的一項有效措施。

所謂跳頻技術，就是將整個頻帶分成若干跳頻信道（Hop Channel）。在一次連接中，藍牙芯片所控制的收發(fā)器按照一定的碼序列，不斷地從一個信道跳轉到另一個信道；而接收方也是按照相同的跳轉規(guī)律進行通信。這實際上屬于一種硬件加密手段，除非第三方掌握了接收雙方的切換信道干什么，否則，從理論上是無法完整獲得信息的，而干擾源也是不可能按同樣的規(guī)律進行干擾的。跳頻的瞬時帶寬很窄，但通過擴展頻譜技術，可以使這個窄帶寬被成倍地擴展成寬頻帶，使擾的可能性變得很小，由此就可以保證傳送的完整性和系統(tǒng)的穩(wěn)定性。

2.2 糾錯技術

在藍牙技術中使用了三種糾錯方案：1/3比例前向糾錯碼（1/3FEC）、2/3比例前向糾錯碼（2/3FEC）和用于數(shù)據的自動請求重發(fā)（ARQ）方式。

1/3比例前向糾錯碼是一種較簡單的糾錯碼方式，屬于重復碼，實現(xiàn)時對每位信息重復三次。2/3比例前向糾錯碼是一種（15，10）精簡的漢明碼表示方法，用于部分分組。

使用ARQ方式，在一個時隙中傳送的數(shù)據必須在下一個時隙得到確認（或超時）信息。只有數(shù)據在接收端通過了報頭錯誤檢測和循環(huán)冗余檢測，被認為無錯后，才向發(fā)送端返回確認信息；否則，返回一個錯誤信息。

2.3 微微網

藍牙支持點對點和點對多點的通信，其最基本的網絡組成是微微網。微微網是通過藍牙技術連接起來的一種微型網絡，由一個主設備（Master）和若干個從設備（Slave）組成，且從設備最多為7臺。主設備負責通信協(xié)議的動作，而從設備則受控于主設備。一個微微網可以是2臺相連的設備，也可以是8臺連在一起的設備，所有設備單元均采用同一跳頻序列。

藍牙給每個微微網都提供了特定的跳轉模式，因此，它允許大量的微微網同時存在。同一區(qū)域內，多個微微網互聯(lián)形成了分散網。不同的微微網信道有不同的主單元，因而存在不同的跳轉模式。

2.4 安全性

藍牙技術的無線傳輸特性使它非常容易受到攻擊，因此，安全機制在藍牙技術中顯得尤為重要。雖然藍牙系統(tǒng)所采用的跳頻技術已經提供了一定的安全保障，但藍牙技術仍然需要在應用層和鏈路層上提供安全措施。該措施將用于對等環(huán)境，即藍牙系統(tǒng)每個單元中設備的匹配和加密規(guī)則都將以同樣的方法實現(xiàn)。在鏈路層，藍牙使用四個參數(shù)來保證系統(tǒng)的安全性：每個用戶唯一的48位地址、用戶的128位驗證密鑰、用戶的8～128位加密密鑰、設備產生的一個128位隨機數(shù)RAND。

藍牙的低層安全是通過基帶和鏈路管理中的鑒權、匹配和加密完成的。

鑒權基于“競爭-應答”算法，是藍牙系統(tǒng)中的關鍵部分，它允許用戶為個人的藍牙設備建立一個信任域。校驗器發(fā)送一個LMP-au-rand PDU分組給請求者，該PDU（協(xié)議數(shù)據單元）分組含有一個隨機數(shù)。請求者根據獲取的分組計算出應答值，然后將應答值發(fā)回給校驗器，驗證應答值是否正確。

當兩臺設備無共用鏈接字時，則基于個人識別碼PIN和隨機數(shù)創(chuàng)建初始化字Kinit，這一過程為匹配。Kinit字在校驗器向請求者發(fā)出LMP-in-rand時創(chuàng)建，然后進行鑒權，共計算過程基于Kinit字，而不是鏈接字。通過鑒權后，鏈接字即被創(chuàng)建。

加密被用來保護連接中的個人信息，密鑰由程序的高層來管理。網絡傳送協(xié)議和應用程序，可以為用戶提供一個較強的安全機制，需要注意的是，加密字節(jié)不同于鑒權字。鑒權字具有靜態(tài)性，而一旦建立加密字，就由運行在藍牙設備上的具體應用，來決定什么時候和是否需要修改加密字。

藍牙技術的協(xié)議標準

SIG 所頒布的藍牙規(guī)范（Specification of the Bluetooth System）就是藍牙無線通信協(xié)議標準，它規(guī)定了藍牙應用產品應遵循的標準和需要達到的要求。

藍牙規(guī)范包括核心協(xié)議（Core）與應用框架（Profiles）兩個文件。協(xié)議規(guī)范部分定義了藍牙的各層通信協(xié)議，應用框架指出了如何采用這些協(xié)議實現(xiàn)具體的應用產品。藍牙協(xié)議規(guī)范遵循開放系統(tǒng)互連參考模型（Open System Interconnetion/Referenced Model, OSI/RM），從低到高地定義了藍牙協(xié)議堆棧的各個層次。

按照藍牙協(xié)議的邏輯功能，協(xié)議堆棧由下至上分為3個部分：傳輸協(xié)議、中介協(xié)議和應用協(xié)議。其功能簡介如下：

本文為全文原貌 未安裝PDF瀏覽器用戶請先下載安裝 原版全文

1.傳輸協(xié)議

負責藍牙設備間相互確認對方的位置，以及建立和管理藍牙設備間的物理和邏輯鏈路。這一部分又進一步分為低層傳輸協(xié)議和高層傳輸協(xié)議。低層傳輸協(xié)議側重于語音與數(shù)據無線傳輸?shù)奈锢韺崿F(xiàn)以及藍牙設備的物理和邏輯鏈路。低層傳輸協(xié)議包括藍牙的射頻（Radio）部分、基帶與鏈路管理協(xié)議（Baseband & Link Manager Protocol, LMP）。高層傳輸協(xié)議包括邏輯鏈路控制的物理實現(xiàn)以及藍牙設備間的連接與組網。高層傳輸協(xié)議包括邏輯鏈路控制與適配協(xié)議（Logical Link Control and Adaptation Protocol, L2CAP）和主機控制器接口（Host Controller Interface, HCI）。這部分為高層應用程序屏蔽了諸如跳頻序列選擇等低層傳輸操作，并為高層應用傳輸提供了更加有效和更有利于實現(xiàn)的數(shù)據分組格式。

2.中介協(xié)議

為高層應用協(xié)議或程序在藍牙邏輯鏈路上工作提供了必要的支持，為應用層提供了各種不同的標準接口。這部分協(xié)議包括以下幾部分：

串口仿真協(xié)議（RFCOMM）

基于歐洲電信標準化協(xié)會（European Telecommunication Standardization Institute, ETSI）的TS07.10標準制定。該協(xié)議用于模擬串行接口環(huán)境，使得基于串口的傳統(tǒng)應用僅作少量的修改或者不做任何修改可以直接在該層上運行。

服務發(fā)現(xiàn)協(xié)議（Service Discovery Protocol，SDP）

為實現(xiàn)藍牙設備之間相互查詢及訪問對方提供的服務。

IrDA（Infrared Data Association）互操作協(xié)議

藍牙規(guī)范采用了IrDA的對象交換協(xié)議（OBEX），使得傳統(tǒng)的基于紅外技術的對象（如電子名片（vCard）和電子日歷（vCal）等）交換應用同樣可以運行在藍牙無線接口之上。

網絡訪問協(xié)議

該部分協(xié)議包括點對點協(xié)議（Point to Point Protocol, PPP）、網際協(xié)議（Internet Protocol, IP）、傳輸控制協(xié)議（Transfer Control Protocol, TCP）和用戶數(shù)據報協(xié)議（User Datagram Protocol, UDP）等，用于實現(xiàn)藍牙設備的撥號上網，或通過網絡接入點訪問Internet 和本地局域網。

電話控制協(xié)議

該協(xié)議包括TCS、AT指令集和音頻。電話控制協(xié)議性能（Telephone Control Protocol Specification，TCS）是基于國際電信聯(lián)盟電信標準化部門（International Telecommunication Union-Telecommunication，ITU-T）的Q.931標準制定的，用于支持電話功能；藍牙直接在基帶上處理音頻信號（主要指數(shù)字語音信號），采用SCO鏈路傳輸語音，可以實現(xiàn)頭戴式耳機和無繩電話等的應用。

3.應用協(xié)議

是指那些位于藍牙協(xié)議堆棧之上的應用軟件和其中所涉及的協(xié)議，包括開發(fā)驅動各種諸如撥號上網和通信等功能的藍牙應用程序。藍牙規(guī)范提供了傳輸層及中介層定義和應用框架，在傳輸層及中介層之上，不同的藍牙設備必須采用統(tǒng)一符合藍牙規(guī)范的形式；而在應用層上，完全由開發(fā)人員自主實現(xiàn)。事實上，許多傳統(tǒng)的應用都可以幾乎不用修改就在藍牙協(xié)議堆棧之上運行，如基于串口和OBEX協(xié)議的應用。通常藍牙技術應用程序接口（Application Programming Interface，API）函數(shù)的開發(fā)由開發(fā)工具的設計人員來完成，這樣有利于藍牙技術與各類應用的緊密結合。

藍牙技術在智能家居系統(tǒng)中的應用

由于藍牙技術的免布線、低成本、低功耗、高速率、高可靠性和兼容性等特點，使得基于藍牙技術的智能家居系統(tǒng)能為人們所接受。

家庭電器控制

嵌入了藍牙芯片的“信息家電”，也具有了網絡信息終端的功能，可以主動地、獲取和處理相關信息，使得個人家庭與現(xiàn)代信息社會的信息高速公路通信網緊密相連。可以設想一下，所有的信息家電通過一個遙控器來進行控制，既可以控制電視，也可以控制計算機和空調器，同時還可以用作無繩電話或者移動電話，甚至可以在這些信息家電之間共享有用的信息，在家庭內部形成一個個人智能網絡。

家庭流量計費

目前，大多數(shù)遠傳計量系統(tǒng)采用如下方式：在各個房間內的遠傳表，通過專用的布線系統(tǒng)連接至各個節(jié)點流量控制器，再匯總到物業(yè)管理中心進行上位管理。在智能家居系統(tǒng)中如果采用了藍牙技術，就會出現(xiàn)新的三表遠傳流量計費系統(tǒng)的局面。

通過在支持藍牙的微芯片中置入相應程序，并置入流量表中，可以去掉流量表與節(jié)點控制器之間的連線，使每個計量末端采用無線方式，降低系統(tǒng)由于線路損壞而帶來的系統(tǒng)故障，提高了系統(tǒng)的可靠性。

安防系統(tǒng)

智能家居的基本目標為人們提供一個舒適、安全、方便和高效率的生活環(huán)境。這就需要一個安全的家庭體系，其中既包括人身和家庭財產的安全，也包括家庭設備的安全。為了實現(xiàn)這種安全體系，需要配備相關的防衛(wèi)措施，例如電子門禁、對講系統(tǒng)、電子防盜系統(tǒng)、玻璃破檢測報警系統(tǒng)、室內跑水檢測與報警系統(tǒng)、室內有毒/害氣體的檢測等。

報警控制器連接至社警鈴、報警指示燈、電話，若報警，可按預先設置的若干個電話號碼，自動拔通進行報警，并報出家中具體是哪個系統(tǒng)報警了。

藍牙技術可以使數(shù)據采集和家庭安防監(jiān)控靈活方便，擺脫了布線系統(tǒng)的束縛。

篇7

近兩年數(shù)據泄漏事件接連發(fā)生，讓企業(yè)對業(yè)務安全及應用安全的重視達到前所未有的高度。杭州安恒信息技術有限公司（簡稱安恒信息）總裁范淵對當前的Web應用安全現(xiàn)狀非常擔憂，在他看來，“我們現(xiàn)在面臨的是一個岌岌可危的網絡安全環(huán)境，用戶就好比《皇帝的新裝》中的帝王一樣，毫無隱私可言” 。

90%以上WAF可能被繞過

黑客的攻擊目標正在從網絡服務器轉向Web應用。“近些年，云計算、物聯(lián)網、移動互聯(lián)備受關注，但人們卻忽略了一個本質問題——安全。沒有安全的保障，一切新技術、新趨勢都是一紙空談，很容易成為新興攻擊方式誕生的溫床，其結果是造成無盡的危害。”安恒信息安全服務部副總監(jiān)吳卓群從產品及技術的角度指出：“盡管Web 應用的各個層面都已使用各種技術來確保其安全性，但由于Web應用的開放性、各種Web軟硬件漏洞的不可避免性，以及網絡攻擊技術日趨成熟，三分之二的Web站點都相當脆弱。然而，絕大多數(shù)企業(yè)仍然將IT支出花在了購買網絡和服務器安全解決方案上，對于Web應用的安全防護，并沒有采取針對性的有效措施。”

WAF（Web應用防火墻）是企業(yè)應對Web應用攻擊的主要方法。但是，隨著攻擊技術的日新月異，攻擊方式的不斷變化，攻擊者仍然會經常讓企業(yè)感到措手不及：針對Web應用的零日攻擊屢屢得逞；社交工程學攻擊、APT攻擊則讓企業(yè)遭受重創(chuàng)……

美國舉辦的2012黑帽大會上披露的一個消息令人咂舌：安全廠商Qualys工程經理Ivan Ristic用一個新的工具測試WAF是否存在漏洞，結果是WAF可以被150多種協(xié)議級避讓技巧繞過。這意味著黑客只要稍微修改惡意請求的URL路徑，就可以輕松繞過WAF的檢測。對此，吳卓群認為：“WAF本是保護Web應用安全的設備，但它卻缺乏足夠的安全測試，有大量攻擊手段和方法可完全繞過WAF的防護策略，對Web網站進行攻擊。更大的風險是，攻擊者利用解析錯誤徹底繞過安全防護策略。當前，國內外無論是硬件WAF還是云WAF，至少有90%以上存在被徹底繞過的風險。”

主動防御的安全策略

面對攻擊者多種多樣的繞過方法，WAF廠商該如何應對？安恒信息的策略是變被動為主動。“作為國內最早研發(fā)Web應用防火墻的企業(yè)，安恒信息逐漸認識到這點。”吳卓群表示，“經過多年的實踐，安恒信息總結出一套可行的技術方法，有效地解決了目前針對WAF的繞過保護問題，使得WAF成為實實在在的能有效抵御Web攻擊的最佳防御方式。”

從2007年國內第一款透明Web應用防火墻至今，安恒信息在WAF領域成果累累，其WAF產品明御Web應用防火墻不僅內置了30余類的通用Web攻擊特征，能夠有效防御來自外部的SQL注入、文件注入、命令注入、配置注入、LDAP注入和跨站腳本等攻擊，而且通過HTTP協(xié)議規(guī)范性檢測，可以實現(xiàn)Web主動防御功能，比如通過設置請求頭長度限制、請求編碼類型限制等方式，能有效攔截大部分非法的未知攻擊行為。

篇8

【關鍵詞】NATVPNIPSec通道安全

一、前言

采用RFC1918編址方式節(jié)約IP地址的方法通稱為NAT，NAT分為三類：靜態(tài)NAT、動態(tài)NAT、NAPT。NAPT應用最為廣泛。NAT技術是為了節(jié)約IP地址，在網絡內部采用私有地址，在出口采用公網地址，內部地址要訪問外網時，需要將內網地址轉換為公網地址，這種轉換主要是IP地址和端口的轉換，涉及到修改每個IP包的IP地址和端口值。而IPSec是一套網絡安全協(xié)議規(guī)范，常用于組建VPN，構建兩個遠程局域網之間的安全隧道，進而把位于兩地的兩個局域網合并成一個可以通過不安全的互聯(lián)網相互聯(lián)系的一個局域網，而IPSec中使用的協(xié)議不允許修改IP報頭內容，因此，NAT和IPSec相互矛盾，不能在一起混用。雖然目前有一些方法克服這種矛盾，比如IP OVER TCP，IP OVER UDP，NAT-T等，但是都是對IP報文結構的一種破壞，本文根據NAT和IPSec的不同用途，客戶端采用NAT和IPSec分別訪問不同的對象，在配置上巧妙避開矛盾，使兩種協(xié)議各司其職，互不影響。

二、NAT結構分析

私有網絡192.168.1.0/24的多臺計算機，需要訪問internet，但是只有一個公網地址，在路由器R1上啟用NAPT功能，將源地址為192.168.1.x的私有地址轉換成internet中可以識別和交換的公網地址200.1.1.1，同時將端口進行相應的轉換，并在R1中儲存對應表，如圖1所示。

三、IPSec VPN解析

IPSec是一種IP層的數(shù)據加密方法，它包含兩種模式：傳輸模式和隧道模式，有兩種封裝：AH和ESP，兩種模式和兩種封裝共組合成四種應用，比較常見的是隧道模式的ESP封裝。其基本封裝原理如圖2所示。

四、配置與驗證

試驗網絡拓撲如圖3所示。

4.1NAT配置與驗證

首先在R1上設置NAT，排除到對端的流量，其余流量均采用NAT。

R1（config）#access list 102 deny ip 192.168.1.0 0.0.0.255 172.16.1.0 0.0.0.255

R1（config）#access list 102 permit ip any any

R1（config）#ip nat inside source list 102 int f0/1 overload

R1（config）#int f0/1

R1（config）#ip nat outside

R1（config）#int f0/0

R1（config）#ip nat inside

在R3上設置NAT，排除到對端的流量，其余流量均采用NAT。

R3 （config）#access list 102 deny ip 172.16.1.0 0.0.0.255 192.168.1.0.0.0.0.255

R3（config）#access list 102 permit ip any any

R3（config）#ip nat inside source list 102 int f0/1 overload

R3（config）#int f0/1

R3（config）#ip nat outside

R3（config）#int f0/0

R3（config）#ip nat inside

實驗的關鍵是NAT的訪問控制列表范圍的規(guī)定，前往對端私用網絡的源IP不要轉換，而去往公網的源地址需要轉換，采用debug ip nat驗證NAT轉換過程。

4.2IPSec配置與驗證

第一步配置IKE協(xié)商

R1（config）#crypto isakmp policy 100建立IKE協(xié)商策略

R1（config-isakmap）# authentication pre-share預共享密鑰認證

R1 （config）# crypto isakmp key wwp address 201.1.1.2設置共享密鑰和對端地址

R3（config）#crypto isakmp policy 100建立IKE協(xié)商策略

R3（config-isakmap）# authentication pre-share預共享密鑰

R3 （config）# crypto isakmp key wwp address 200.1.1.1設置共享密鑰和對端地址

第二步配置IPSEC相關參數(shù)

R1 （config）# crypto ipsec transform-set wwpset esp-des配置轉換集、驗證算法、加密算法

R1（config）# access-list 101 permit ip 192.168.1.0 0.0.0.255 172.16.1.0 0.0.0.255定義訪問控制列表

R2 （config）# crypto ipsec transform-set wwpset esp-des傳輸模式

R2（config）# access-list 101 permit ip 172.16.1.0 0.0.0.255 192.168.1.0 0.0.0.255

第三步應用配置到接口

R1 （config）#crypto map wwpmap 110 ipsec-isakmp采用IKE協(xié)商，優(yōu)先級為110

R1（config-crypto-map）#set peer 201.1.1.2指定VPN鏈路對端IP地址

R1 （config-crypto-map）#set transform-set wwpset指定轉換集

R1（config-crypto-map）#match address 101指定訪問控制列表，匹配信息流

R1（config）# int f0/1

R1（config-if）# crypto map wwpmap應用此表到端口

R3 （config）#crypto map wwpmap 110 ipsec-isakmp采用IKE協(xié)商，優(yōu)先級為110

R2（config-crypto-map）#set peer 200.1.1.1指定VPN鏈路對端的IP地址

R2 （config-crypto-map）#set transform-set wwpset指定轉換集

R2（config-crypto-map）#match address 101指定訪問控制列表匹配需要加密的信息流

R2（config）# int f0/1

R2（config-if）# crypto map wwpmap應用此表到端口

IPSEC VPN配置完成后，首先采用ping命令，測試到對端私網和公網是否暢通；其次，采用show命令查看IPSec狀態(tài)，R1#show crypto ipsec sa，R1#show crypto isakmp sa，R1# show crypto isakmp policy；最后，采用debug crypto isakmp和debug crypto ipsec命令，查看IPSec運行情況。

五、結論

根據VPN和NAT的不同應用范圍，靈活配置策略，精細化配置測試，可以采用不同信息流量采用不同途徑的方法，分別使用NAT和VPN，達到到達對端采用VPN，到達公網采用NAT，各司其職，既保障了訪問公網的靈活性，又保證了私網通信的安全性。

參考文獻

[1]洪洲. NAT的UDP穿透技術分析與實現(xiàn).廣州城市職業(yè)學院學報[J]，2009，2：27-31

[2]楊翼平.雙重NAT技術在集中網絡管理業(yè)務中的應用.中國新通信[J]，2012，10：49-51

[3]吳麗華，肖子玉. IMS組網中的NAT/防火墻穿越方案.電信工程技術與標準化[J]，2009，5：16-21頁

[4]蔡琴.運用VPN技術組建新疆黨校虛擬專用網絡.無線互聯(lián)科技[J]，2012，11：8-9

[5]黃益彬，呂洋，楊維永.智能終端網絡安全防護設計.計算機與現(xiàn)代化[J]，2012，12：106-109

[6]程龍，張學平，王海濤.基于OPNET的IPSec協(xié)議性能監(jiān)測與仿真.計算機安全[J]，2012，11：51-55

篇9

關鍵詞：物聯(lián)網；課程性質；教學的開發(fā)思路；教學內容和要求；課程考核

1課程性質

“無線傳感器網絡技術”涉及通信技術、計算機技術和傳感器技術等多種技術領域，因此本課程是一門理論綜合性高，應用實踐性強的課程。通過本課程的學習和實踐，旨在使學生了解WSN和ZigBee協(xié)議規(guī)范的基礎知識，為進行ZigBee項目開發(fā)提供了理論基礎。

2課程設計理念

在本課程教學設計過程中，遵循“項目為載體，模塊遞進”的原則，在夯實學生WSN和ZigBee協(xié)議理論基礎的同時，培養(yǎng)學生對ZigBee技術的應用能力，并引進ZigBee項目，采用任務驅動的方式，充分體現(xiàn)WSN的教學實踐。將專業(yè)教學過程，技能訓練過程有機結合起來，有效地提高課程教學的實踐性、開發(fā)性和有效性。

3課程開發(fā)思路

本課程的教學過程要實現(xiàn)課堂案例教學和實踐任務導向教學相結合，將項目式案例引入課堂教學，以真實項目為對象進行工作導向組織教學，從教學過程和形式上體現(xiàn)“學”和“做”的緊密結合。課程模擬完成企業(yè)“項目任務”貫穿整個教學過程。通過問題、項目導入（實踐）學生思考、分析、回答、教師評議、總結（理論）擴展應用（實踐）的方式進行，使授課內容與工作實際緊密結合[2]。項目實施過程中教師加強對學生的引導，并且進行過程性評價，教會學生怎樣應付大量的信息，引導學生如何在實踐中發(fā)現(xiàn)新知識，掌握新內容。教師要成為教學策劃和導演，在教學過程中起指導作用[3]。

4課程目標

本課程的項目強調從學生的學習和認知水平出發(fā)，通過理論、實踐相結合的教學方式，邊講邊學、邊學邊做、做中學、學中做，把學生培養(yǎng)成為具有良好職業(yè)道德的、具有嵌入式系統(tǒng)開發(fā)、程序設計的管理理論和實踐能力的、具有可持續(xù)發(fā)展能力的高素質高技能型物聯(lián)網專門人才，以適應市場對物聯(lián)網人才的需求[4]。

5課程內容和要求

本課程的內容主要包括以下4大模塊：無線傳感器網絡、無線片上系統(tǒng)、ZigBee網絡協(xié)議、TIZ-Stack協(xié)議棧的使用，具體要求如表1所示。

6課程考核

本課程的考核采用過程考核和結果考核相結合的方法。過程考核根據課堂提問、課堂練習、課后作業(yè)和學習態(tài)度而定，是形成性考核；結果考核根據學生的考試成績而定。本課程對各學習模塊的考核標準如下文所示。6.1無線傳感器網絡能夠闡述WSN的特點、體系結構和關鍵技術。6.2無線片上系統(tǒng)（1）會對芯片GPIO相關寄存器進行配置。（2）根據開關Led的原理，會設置Led驅動。（3）會切換時鐘源來控制時鐘頻率。（4）能夠設置外部中斷相關寄存器。（5）會使用串口通信收發(fā)字符串。（6）能夠獲取片內溫度傳感器的溫度值，并能通過串口發(fā)送到上位機。（7）會根據定時器中斷配置步驟來會配置T1寄存器，完成T1中斷程序。（8）會設置睡眠定時器的定時間隔，會設置系統(tǒng)功耗模式。本課程的教學不是單一機械地向學生傳授知識和技能，也不是一種向學生灌輸式傳授知識的過程，而是一種啟發(fā)引導學生自主探索學習、總結、體會知識和技能的過程。

[參考文獻]

[1]謝金龍，鄧人銘.物聯(lián)網無線傳感器網絡技術與應用[M].北京：人民郵電出版社，2016.

[2]桂小林.物聯(lián)網技術專業(yè)課程體系探索[J].計算機教育，2010（16）：1-3.

[3]李強.淺談我國高校物聯(lián)網專業(yè)教學模式創(chuàng)新[J].北京師范大學學報，2010（2）：30-35.

[4]施炯,楊亞萍，梁豐.“物聯(lián)網工程導論”課程教學探索與實踐[J].中國電力教育，2013（28）：106-107.

篇10

在現(xiàn)有的即時通信系統(tǒng)中，實現(xiàn)音視頻通信的核心組件包括音視頻處理框架和即時通信協(xié)議兩個部分。音視處理框架集成了音視頻采集、音視頻編解碼、音視頻分流控制、音視頻數(shù)據流網絡擁塞控制等技術模塊，能夠完成音視頻數(shù)據流的采集、編碼、分流等基本處理流程;即時通信協(xié)議則負責為音視頻數(shù)據協(xié)商傳輸通道，并且在協(xié)商好的傳輸通道上建立對應的連接，從而為音視頻數(shù)據的順暢傳輸提供保障。

1即時通信協(xié)議

即時通信協(xié)議是進行即時通信必須遵循的信息規(guī)范，主要負責完成用戶信息傳輸通道協(xié)商，客戶端與服務器通信信令傳輸控制等任務。XMPP是主流即時通信協(xié)議之一，是基于可擴展標記語言(XML)的協(xié)議，其繼承了在XML的高可擴展性，可以通過發(fā)送擴展的信息來處理用戶需求。目前最常用的即時通信協(xié)議體系主要是SIP和XMPP協(xié)議體系，兩者都可以完成音視頻通信功能。另外，一些商業(yè)公司自行開發(fā)私有的即時通信協(xié)議實現(xiàn)了相對封閉的通信環(huán)境，例如QQ和MSN。XMPP協(xié)議是個總稱，包括核心協(xié)議，擴展協(xié)議等。

核心協(xié)議只規(guī)定了很小、很基本的一些功能，大部分功能都是在擴展協(xié)議中規(guī)定的。實際上，XMPP協(xié)議只是作為協(xié)商協(xié)議應用，真正的P2P連接和實時通信是通過其擴展協(xié)議實現(xiàn)的。Jingle就是典型的擴展協(xié)議案例。Jingle［6］是Google開發(fā)的XMPP協(xié)議上的擴展，其解決了在XMPP協(xié)議體系下點對點的P2P連接問題。Jingle協(xié)議提供了多種傳輸方式用于數(shù)據傳輸，而針對多媒體數(shù)據的最為常見的模式是兩種UDP傳輸方式。一種傳輸模型是RAWUDP［9］，RAWUDP是在UDP協(xié)議上發(fā)送媒體數(shù)據包的傳輸通道模型，可以實現(xiàn)在同一局域網下的P2P連接，沒有網絡穿越功能，無法實現(xiàn)遠程通信;另一種模型則是功能更為強大的ICE－UDP［8］，ICE－UDP也是在UDP協(xié)議上發(fā)送媒體數(shù)據包，并且可以實現(xiàn)具有防火墻的網絡穿越和ICE連接性檢查，實現(xiàn)遠程通信。ICE是標準的建立P2P連接性檢查的協(xié)議，其自身不能獨立工作，必需在信號通道的協(xié)調下建立連接，而XMPP協(xié)議就可以作為ICE通道協(xié)商的協(xié)議標準。

基于Jingle/XMPP協(xié)議實現(xiàn)的即時通信框圖如圖1所示。Jingle通過XMPP完成P2P通道的協(xié)商任務，同時通過Jingle協(xié)議建立P2P通道并進行連接性檢查，然后建立并完成RTP會話，從而完成音視頻通信。如果選擇ICE－UDP通道傳輸模型進行RTP視頻數(shù)據傳輸，XMPP服務器可以使用STUN［2］服務器收集用戶的地址，包括NAT［3］后面的私有地址以及NAT與互聯(lián)網連接的公共地址，并且以此為基礎建立映射機制，完成會話參與者跟具體的網絡地址間的轉換和NAT穿越。

2音視頻處理框架

即時通信系統(tǒng)中的音視頻處理框架主要為用戶提供一組多媒體數(shù)據處理的接口，用戶可以用這些接口實現(xiàn)從多媒體采集卡上獲得數(shù)據，進行壓縮編碼、格式轉換、數(shù)據封包等一系列操作，從而完成多媒體的實時處理傳輸功能，大大簡化多媒體處理的復雜性。目前具有二次開發(fā)功能的音視頻處理框架包括Gstreamer，Directshow，Opencore等。其中DirectShow是微軟公司在ActiveMovie和VideoforWindows基礎上推出的基于COM的流媒體處理開發(fā)包。運用DirectShow可以很方便地從支持Windows驅動模型的采集卡上捕獲數(shù)據，并進行相應的后期處理乃至存儲到文件中。OpenCore則是手機操作系統(tǒng)Android的多媒體核心，OpenCore的代碼非常龐大，是一個基于C++的實現(xiàn)，定義了全功能的操作系統(tǒng)移植層，各種基本的功能均被封裝成類的形式，各層次之間的接口多使用繼承等方式。而基于Linux平臺的GStreamer則是完全開源的多媒體框架庫，利用其可以構建一系列媒體處理模塊，包括從簡單的Ogg播放功能到復雜的音頻混音和視頻非線性編輯處理。Gstreamer應用非常廣泛，大多數(shù)手機平臺及個人電腦Linux平臺均采用Gstreamer進行音視頻處理開發(fā)。

2.1Gstreamer音視頻處理

Gstreamer通過其模塊化設計理念，更加便于構建流媒體應用程序。它將各個模塊封裝起來，以元件的形式提供給用戶使用。用戶可以利用庫中原有的元件進行應用程序的編程，同樣也可以編寫元件，然后插入到庫中，以便日后調用時使用。如果只利用庫中的元件來實現(xiàn)特定功能，只需要采用模塊化的方式編寫應用程序［4］。Gstreamer實現(xiàn)局域網內簡單多媒體音視頻傳輸發(fā)送端的框圖如圖2所示。對于視頻數(shù)據流，Gstreamer在發(fā)送端將攝像頭(v4l2src1)采集的數(shù)據依次經過色度空間轉換(ffmpegcsp1)、H263視頻編碼(ffenc_h263p1)、RTP［1］載荷頭添加(rtph263ppay1)，在gstrtpbin中實現(xiàn)實時傳輸協(xié)議(RTP)和實時傳輸控制協(xié)議(RTCP)數(shù)據包整合，并添加發(fā)送報告的背景時鐘時間戳，便于在接受端進行音視頻同步播放，然后發(fā)到UDP端口(udpsink)。在接收端，從UDP端口截獲的數(shù)據依次經過RTP和RTCP數(shù)據包解析、RTP載荷頭解碼、H263解碼器解碼視頻數(shù)據、色度空間轉換，最后經過視頻顯示插件顯示到窗口中。其中gstrtpbin是進行RTP會話管理的核心組件，可以完成RTP數(shù)據包傳輸控制、RTCP數(shù)據包生成、沖突檢測、音視頻分流等任務。

2.2Farsight視頻會議框架

通過Gstreamer開發(fā)庫中的基礎元件可以完成音視頻處理的功能，并且可以進行簡單的局域網內視頻通信。但是，在視頻會議等復雜應用中經常包含多個多媒體會話，而且多媒體會話之間的協(xié)調非常復雜，需要通過更為高層的處理框架來實現(xiàn)會話管理的功能。Farsight是以Gstreamer為基礎開發(fā)的視頻會議框架，它能夠提供一套完整的為多媒體流協(xié)議編寫插件的應用程序接口，同時還為用戶提供API調用這些插件。即時通信應用程序可以使用Farsight進行音視頻會議，而無須擔心底層的數(shù)據流和NAT穿越的問題。因為Farsight［5］是以Gstre-amer為基礎進行開發(fā)，所以開發(fā)新的元件能夠和已有的Gstreamer元件整合，實現(xiàn)完成視頻會議功能的多媒體框架。Farsight可以包含多路音視頻會話流，包含多個會話參與者，具有強大的音視頻會話管理功能。它通過模塊化設計為許多即時通信軟件提供音視頻會議的服務，大大擴展了多媒體處理的功能，并且可以實現(xiàn)更為強大的視頻會議功能。目前很多即時通信客戶端軟件都采用Farsight完成音視頻通信。本文以Gstreamer/Farsight音視頻處理框架為重點，詳述其內部結構及功能實現(xiàn)。

Farsight中包括4個核心概念:會議(Conference)、會話(Session)、參與者(Participant)、流(Stream)。會話參與者是指多媒體數(shù)據源，可以是音頻或視頻等;會話則代表一路音頻或視頻會話，通常有一個媒體類型和一個輸出端;會議則代表一個多媒體會議，可以包含多路會話，并且完成多路會話的協(xié)調管理;當參與者加入到會話中，就將多媒體數(shù)據引入會話中，使得數(shù)據能夠流動，從而構成數(shù)據流。另外，F(xiàn)arsight實現(xiàn)了網絡層的抽象，即將網絡抽象為一個發(fā)射器對象，當數(shù)據流被創(chuàng)建時就會建立發(fā)射器對象，然后通過設置發(fā)射器參數(shù)確定發(fā)送的目的地址。實際上，F(xiàn)arsight并沒有參與多媒體數(shù)據的采集和打包工作，它只是為多媒體數(shù)據流傳輸?shù)骄W絡端進行發(fā)送提供了一個通道，并且對通道進行協(xié)調管理，保證不同的會話參與者與其特定的數(shù)據流綁定以防止收發(fā)混淆。

Farsight實現(xiàn)RTP視頻會議的結構如圖3所示，其中FsRTPConference是Farsight框架下的一種插件，主要的RTP會話管理功能都在這個組件中實現(xiàn)。FsRTPConference中可以同時存在多路FsSession，每一路FsSession因參與者或音媒體源的不同代表不同的多媒體會話。編解碼器在雙方建立連接前無法確定，只有當通信雙方的客戶端協(xié)商之后，才會根據具體的編解碼器名字調用并進行插件的連接。

Farsight通過將gstrtpbin封裝到FsRTPConference中，添加一些其他的必要組件，實現(xiàn)RTP會話。RTP管理器主要由gstrtpbin負責完成RTP會話管理的操作。在發(fā)送端，視頻源和音頻源通過Sink接入到會話中，編解碼器協(xié)商成功后，將編碼器與數(shù)據源和過濾元件連接，然后通過RTP混合器將音視頻數(shù)據發(fā)送到RTP管理器中，完成RTCP數(shù)據包的生成以及RTP會話的管理。最后，經過數(shù)據發(fā)射器將數(shù)據發(fā)送到相應的數(shù)據通道中。在接收端，數(shù)據流同樣要經過類似的信息解碼過程得到音視頻數(shù)據。在發(fā)送端，數(shù)據發(fā)射器在Farsight中通常有多種插件選擇，例如多播UDP插件、Libnice插件等，目的是為了實現(xiàn)底層數(shù)據傳輸?shù)倪B接性檢查。Libnice是實現(xiàn)了ICE和STUN協(xié)議規(guī)范的軟件庫，開發(fā)者以此為基礎完成nice插件，可以實現(xiàn)基于ICE的數(shù)據發(fā)送。但是Libnice中只定義了如何在P2P連接確立后進行連接性檢查，以及如何在確定的P2P連接上進行數(shù)據傳輸?shù)木W絡穿越，并沒有定義如何進行P2P連接，即P2P通道的協(xié)商任務。Jingle協(xié)議規(guī)范則定義了P2P通道建立連接及通道協(xié)商的任務。目前，Jin-gle協(xié)議已經在Libpurple(多協(xié)議會話開發(fā)庫)中實現(xiàn)。

3即時通信系統(tǒng)中音視頻通信的實現(xiàn)

為了開發(fā)的便捷，Pidgin軟件的開發(fā)者將負責通信部分與圖形用戶界面部分分開，分離出來的核心代碼構成即時通信客戶端開發(fā)的核心部分，被稱為Libpurple。這個程序庫已被Adium與Proteus這些客戶端使用。完成分離后，開發(fā)者將有可能以各自的圖形程序庫編寫自己的客戶端接口。在Libpurple中，為實現(xiàn)多媒體通信，開發(fā)者將基于Farsight的多媒體處理框架進行繼承和封裝，實現(xiàn)即時通信協(xié)議，并提供接口供用戶使用，用戶可利用應用程序接口編寫程序實現(xiàn)網絡層的連接。使用者可以使用Libpur-ple直接編寫即時通信程序的核心代碼，并構建應用程序。

同時，Libpurple實現(xiàn)了許多即時通信協(xié)議的通信，例如MSN，XMPP，AIM等協(xié)議，同時完成了媒體后端流處理與相應即時通信協(xié)議的協(xié)同工作。Libpurple在Farsight的基礎上進行開發(fā)，實現(xiàn)了一套具備自身特點的流媒體模式。通過對Lipurple庫的理解分析［10］，得到了Libpurple實現(xiàn)音視頻數(shù)據流控制及會話管理的方法，如圖4所示。圖4中Src是音視頻數(shù)據源，傳輸?shù)紽sSession進行音視頻流整合、RTCP包生成、數(shù)據流管理等操作。Vol-ume和level則分別表示音頻的音量與消息控制插件。Libpurple采用FsSession做會話管理，并在FsSession的基礎上添加Gstreamer基礎元件進行控制，完成自己需要的功能。FsSession通過選擇不同的連接通道，將音視頻數(shù)據流通過發(fā)送器進行發(fā)送。

Libpurple中實現(xiàn)了Jingle協(xié)議進行RTP通信的規(guī)范，并提供兩種數(shù)據通道，RAWUDP和ICE－UDP供用戶使用。在進行具體RTP視頻通信時，程序根據不同情況選擇不同的通道使用。圖4選擇RAWUDP作為數(shù)據發(fā)送通道，用戶也可以選擇其他通道進行數(shù)據發(fā)送。為了與Jingle協(xié)議合作完成音視頻通信，Libpurple建立了一個組件對象purplemedia，這個對象在Farsight組件中提取相關的參數(shù)信息，例如編解碼器信息、發(fā)送目的地址等，并傳遞給Jingle協(xié)議，便于Jingle協(xié)議進行通道協(xié)商。當有新的即時通信協(xié)議需要利用Farsight完成視頻通信時，開發(fā)者往往需要以Libpurple為基礎進行開發(fā)，完成即時通信協(xié)議在Libpurple上的移植，以實現(xiàn)視頻通信。在眾多采用Libpurple庫開發(fā)的即時通信軟件客戶端中，Pidgin是最成功的，也是少數(shù)幾個可以實現(xiàn)音視頻通信的案例。Pidgin是一款支持多協(xié)議客戶端的圖形化即時通信應用程序，它可以使用AIM，Jabber，MSN，Yahoo等即時通信軟件的帳號進行登錄。并采用Libpurple作為開發(fā)庫，利用圖形開發(fā)工具包編寫用戶界面及各種事件提醒和任務管理，從而實現(xiàn)在多種即時通信協(xié)議基礎上的音視頻通信。