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

篇1

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

中圖分類號：TP311 文獻(xiàn)標(biāo)識碼：A 文章編號：1009-3044（2013）32-7218-03

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

1 協(xié)議測試技術(shù)

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

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

2 測試系統(tǒng)總體結(jié)構(gòu)

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

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

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

3.1 測試?yán)龢?gòu)造

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

3.2 數(shù)據(jù)包構(gòu)造與發(fā)送

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

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

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

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

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

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

依照圖2中DHCP數(shù)據(jù)包封裝的結(jié)構(gòu)，在構(gòu)造DHCP數(shù)據(jù)包時調(diào)用函數(shù)依次為libnet_build_dhcpv4（），libnet_build_udp（），libnet_build_ipv4（），libnet_autobuild_ethernet（），Winpcap過濾DHCP數(shù)據(jù)包使用協(xié)議限定符“bootp”。測試采用的拓?fù)淙鐖D3所示：

測試拓?fù)渲惺褂寐酚善髯鳛镈HCP服務(wù)器，在路由器上啟用DHCP server服務(wù)，并且配置地址池、網(wǎng)關(guān)、地址租期等信息。

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

在測試機(jī)上設(shè)置測試?yán)齌s_sc，配置測試步：TS_DHCPDISCOVER，TS_DHCPOFFER，TS_DHCPREQUEST和TS_DHCPACK，其中TS_DHCPDISCOVER和TS_DHCPREQUEST是構(gòu)造的激勵數(shù)據(jù)報文，TS_DHCPOFFER與TS_DHCPACK為反饋數(shù)據(jù)報文。測試系統(tǒng)上啟用測試執(zhí)行Ts_sc測試?yán)诼酚善魃蠁⒂肈HCP event調(diào)試，調(diào)試信息顯示路由器DHCP服務(wù)狀態(tài)發(fā)生變化，測試系統(tǒng)完成所有測試步后成功獲得172.16.1.0網(wǎng)段IP，使用show ip dhcp server statistics查看DHCP服務(wù)器統(tǒng)計信息，與測試系統(tǒng)結(jié)果一致。

5 結(jié)束語

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

參考文獻(xiàn)：

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

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

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

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

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

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

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

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

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

篇2

【關(guān)鍵詞】EtherCAT ETG GB/T

一、引言

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

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

（一）開放性

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

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

（二）高速性

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

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

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

（三）低價

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

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

下面我們用一個網(wǎng)絡(luò)配置的實(shí)例來說明[2]：

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

三、EtherCAT現(xiàn)場總線標(biāo)準(zhǔn)化

（一）中國國家標(biāo)準(zhǔn)

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

國家標(biāo)準(zhǔn)分為強(qiáng)制性國標(biāo)（簡稱GB）、推薦性國標(biāo)（簡稱GB/T）和指導(dǎo)性國家標(biāo)準(zhǔn)（GB/Z）。

EtherCAT在我們申請的國標(biāo)是GB/T，推薦性國家標(biāo)準(zhǔn)。

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

（二）申請國家標(biāo)準(zhǔn)的條件

現(xiàn)場總線的種類繁多，但是真正入選成為我國國家標(biāo)準(zhǔn)的現(xiàn)場總線并不多。這是因?yàn)樵谖覈I(yè)控制網(wǎng)絡(luò)標(biāo)準(zhǔn)的制定是需要滿足對應(yīng)的條件的[4]。

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

（三） 國標(biāo)制作流程

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

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

（四） EtherCAT國標(biāo)整體結(jié)構(gòu)

國標(biāo)共分為6個部分。

第一部分：概述

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

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

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

第五部分：應(yīng)用層服務(wù)定義

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

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

EtherCAT文檔結(jié)構(gòu)和OSI模型的對應(yīng)關(guān)系如圖3所示

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

四、結(jié)論

EtherCAT總線協(xié)議有許多吸引自控行業(yè)的特點(diǎn)：高速、開放、安全、冗余。正因?yàn)槿绱?，該技術(shù)自誕生起就取得了飛速的發(fā)展。鑒于此，國家標(biāo)準(zhǔn)機(jī)構(gòu)正在積極的推進(jìn)EtherCAT的國標(biāo)化。

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

參考文獻(xiàn)：

[1] EtherCAT Technology Group， EtherCAT工業(yè)以太網(wǎng)現(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技術(shù)協(xié)會， 一致性與互操作性， 2011

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

作者簡介：

篇3

關(guān)鍵詞：信令分析；呼叫失?。桓兄?；滿意度

1 引言

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

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

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

⑴用戶會懷疑運(yùn)營商的網(wǎng)絡(luò)質(zhì)量問題，對運(yùn)營商失去信心，久而久之將極有可能導(dǎo)致用戶流失；

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

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

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

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

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

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

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

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

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

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

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

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

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

⑶由于用戶行為導(dǎo)致的呼叫失敗

⑷由于用戶終端導(dǎo)致的呼叫失敗

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

4 主叫用戶提醒方案設(shè)計

4.1 呼叫失敗提醒的設(shè)計框架

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

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

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

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

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

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

4.2 方案拓?fù)浣Y(jié)構(gòu)

呼叫失敗提醒方案是以信令分析為基礎(chǔ)一種解決方案，需要對現(xiàn)網(wǎng)各接口進(jìn)行信令搭接，其拓?fù)浣Y(jié)構(gòu)如下圖：

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

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

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

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

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

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

4.3 應(yīng)用案例

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

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

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

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

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

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

5 小結(jié)

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

[參考文獻(xiàn)]

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

篇4

1.1信息家電網(wǎng)絡(luò)系統(tǒng)的體系結(jié)構(gòu)

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

(1)物理介質(zhì)層(Media)是信息家電網(wǎng)絡(luò)的物理層，以電力線為傳輸介質(zhì)，以擴(kuò)頻載波技術(shù)(SpreadSpectrumCarrier，SSC)為信號傳輸基礎(chǔ)．

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

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

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

電力線信息家電網(wǎng)絡(luò)是按層的方式來組織的，每一層都建立在其下層之上，這種協(xié)議分層設(shè)計的方式也符合當(dāng)前軟件設(shè)計結(jié)構(gòu)化和面向?qū)ο蟮乃枷耄?/p>

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

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

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

1.3信息家電網(wǎng)絡(luò)系統(tǒng)的硬件設(shè)計方案

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

2結(jié)語

篇5

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

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

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

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

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

篇6

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

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

既然藍(lán)牙技術(shù)這么神奇，那讓我們走進(jìn)它。

藍(lán)牙技術(shù)簡介

1. 藍(lán)牙簡介

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

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

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

2.藍(lán)牙中的關(guān)鍵技術(shù)

2.1 跳頻技術(shù)

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

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

2.2 糾錯技術(shù)

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

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

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

2.3 微微網(wǎng)

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

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

2.4 安全性

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

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

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

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

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

藍(lán)牙技術(shù)的協(xié)議標(biāo)準(zhǔn)

SIG 所頒布的藍(lán)牙規(guī)范（Specification of the Bluetooth System）就是藍(lán)牙無線通信協(xié)議標(biāo)準(zhǔn)，它規(guī)定了藍(lán)牙應(yīng)用產(chǎn)品應(yīng)遵循的標(biāo)準(zhǔn)和需要達(dá)到的要求。

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

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

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

1.傳輸協(xié)議

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

2.中介協(xié)議

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

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

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

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

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

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

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

網(wǎng)絡(luò)訪問協(xié)議

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

電話控制協(xié)議

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

3.應(yīng)用協(xié)議

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

藍(lán)牙技術(shù)在智能家居系統(tǒng)中的應(yīng)用

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

家庭電器控制

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

家庭流量計費(fèi)

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

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

安防系統(tǒng)

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

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

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

篇7

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

90%以上WAF可能被繞過

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

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

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

主動防御的安全策略

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

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

篇8

【關(guān)鍵詞】NATVPNIPSec通道安全

一、前言

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

二、NAT結(jié)構(gòu)分析

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

三、IPSec VPN解析

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

四、配置與驗(yàn)證

試驗(yàn)網(wǎng)絡(luò)拓?fù)淙鐖D3所示。

4.1NAT配置與驗(yàn)證

首先在R1上設(shè)置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上設(shè)置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

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

4.2IPSec配置與驗(yàn)證

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

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

R1（config-isakmap）# authentication pre-share預(yù)共享密鑰認(rèn)證

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

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

R3（config-isakmap）# authentication pre-share預(yù)共享密鑰

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

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

R1 （config）# crypto ipsec transform-set wwpset esp-des配置轉(zhuǎn)換集、驗(yàn)證算法、加密算法

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

第三步應(yīng)用配置到接口

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指定轉(zhuǎn)換集

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

R1（config）# int f0/1

R1（config-if）# crypto map wwpmap應(yīng)用此表到端口

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指定轉(zhuǎn)換集

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

R2（config）# int f0/1

R2（config-if）# crypto map wwpmap應(yīng)用此表到端口

IPSEC VPN配置完成后，首先采用ping命令，測試到對端私網(wǎng)和公網(wǎng)是否暢通；其次，采用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運(yùn)行情況。

五、結(jié)論

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

參考文獻(xiàn)

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

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

[3]吳麗華，肖子玉. IMS組網(wǎng)中的NAT/防火墻穿越方案.電信工程技術(shù)與標(biāo)準(zhǔn)化[J]，2009，5：16-21頁

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

[5]黃益彬，呂洋，楊維永.智能終端網(wǎng)絡(luò)安全防護(hù)設(shè)計.計算機(jī)與現(xiàn)代化[J]，2012，12：106-109

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

篇9

關(guān)鍵詞：物聯(lián)網(wǎng)；課程性質(zhì)；教學(xué)的開發(fā)思路；教學(xué)內(nèi)容和要求；課程考核

1課程性質(zhì)

“無線傳感器網(wǎng)絡(luò)技術(shù)”涉及通信技術(shù)、計算機(jī)技術(shù)和傳感器技術(shù)等多種技術(shù)領(lǐng)域，因此本課程是一門理論綜合性高，應(yīng)用實(shí)踐性強(qiáng)的課程。通過本課程的學(xué)習(xí)和實(shí)踐，旨在使學(xué)生了解WSN和ZigBee協(xié)議規(guī)范的基礎(chǔ)知識，為進(jìn)行ZigBee項(xiàng)目開發(fā)提供了理論基礎(chǔ)。

2課程設(shè)計理念

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

3課程開發(fā)思路

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

4課程目標(biāo)

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

5課程內(nèi)容和要求

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

6課程考核

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

[參考文獻(xiàn)]

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

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

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

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

篇10

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

1即時通信協(xié)議

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

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

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

2音視頻處理框架

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

2.1Gstreamer音視頻處理

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

2.2Farsight視頻會議框架

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

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

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

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

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

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

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

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