李笳平，卜方玲，孟凡榮，劉 航

（1.武漢大學 電子信息學院，湖北 武漢430079；2.中國科學院研究生院 光電研究所，北京100190）

0 引 言

20世紀80年代中期，美國劇場技術協(xié)會提出了只要一對線路就可以傳輸512路燈光亮度數(shù)據(jù)的DMX512（digital multiplex with 512pieces of information）協(xié)議標準［1］，圖1是傳統(tǒng)的DMX512協(xié)議舞臺燈光控制模型［2］。隨著舞臺燈光控制的規(guī)模不斷擴大，而且為了追求更絢麗的效果而使用如換色器、煙霧器、吊掛器等其它類型設備，使得燈光控制系統(tǒng)需要提升規(guī)模和性能。以以太網(wǎng)為代表的網(wǎng)絡技術不僅具有可擴展性、傳輸速度快、規(guī)模大等優(yōu)點，而且網(wǎng)絡配置簡單［3－4］，因此基于網(wǎng)絡的燈光控制協(xié)議如ACN、sACN正在被研究和發(fā)展［5－6］。本文在研究和實現(xiàn)sACN協(xié)議的基礎上，分析了共享介質以太網(wǎng)服務端發(fā)送sACN數(shù)據(jù)包可支持的客戶端規(guī)模。由于sACN協(xié)議服務器端（sACN燈光控制臺）依靠連續(xù)不停的發(fā)送燈光數(shù)據(jù)以避免丟包，導致網(wǎng)絡負載加重，不利于網(wǎng)絡擴展，為了提高網(wǎng)絡資源利用率，而且為了在舞臺燈光控制中sACN服務端能監(jiān)測到sACN客戶端 （接收燈光數(shù)據(jù)的調光模塊）的數(shù)據(jù)收發(fā)狀態(tài)和設備性能狀態(tài)等有用信息，本文設計了一種sACN舞臺燈光應答幀格式，用于客戶端在收到sACN協(xié)議數(shù)據(jù)后回復應答幀給服務端。如果大量的客戶端向服務端回復應答幀，在傳統(tǒng)的共享介質以太網(wǎng)中，會產(chǎn)生信號沖突，CSMA/CD機制在網(wǎng)絡負載重時會導致網(wǎng)絡延時增大，不能滿足舞臺燈光控制的實時性要求［7］，因此，本文提出了一種順序應答機制的沖突避免機制，并設計了以交換機為中心節(jié)點的星型舞臺燈光控制網(wǎng)絡，達到在多客戶端回復應答幀時網(wǎng)絡延時最小化的目的，提高舞臺燈光控制網(wǎng)絡的數(shù)據(jù)傳輸和資源利用的效率。

1 基于sACN協(xié)議數(shù)據(jù)包的網(wǎng)絡時延分析

1.1 sACN協(xié)議

sACN （streaming ACN）協(xié)議標準是由美國娛樂服務和技術協(xié)會 （ESTA）在制定 ACN （architecture control network）協(xié)議后制定的介于DMX512和ACN之間的過渡協(xié)議。它通過使用ACN整體協(xié)議中的一部分用于在TCP/IP網(wǎng)絡中傳輸DMX512數(shù)據(jù)包，利用單播或多播地址傳輸數(shù)據(jù)鏈 （universe）來控制調光器。sACN協(xié)議在UDP/IP上定義了三層結構用于封裝DMX512數(shù)據(jù)包，分別是：DMP Layer、Framing Layer、Root Layer。如圖2所示為sACN協(xié)議模型圖。

圖2 sACN協(xié)議層次結構

sACN協(xié)議數(shù)據(jù)包基本長度為638字節(jié)，其中包括513字節(jié)的DMX512燈光數(shù)據(jù)和125字節(jié)的報頭數(shù)據(jù)。

1.2 sACN數(shù)據(jù)包傳輸時延分析

時延是指一個報文或分組從一個網(wǎng)絡的一端傳送到另一個端所需要的時間，它包括了發(fā)送時延、傳輸時延 （傳播時延包含在內）、節(jié)點處理時延、排隊時延 （即等待時延）［8］。一般情況下，發(fā)送時延與報文長度有關，報文越長發(fā)送時延越大。本文所研究的時延限制在局域網(wǎng)中，所指的時延是局域網(wǎng)中點與點之間的時延。

發(fā)送時延——Tsend；傳輸時延——Tts；處理時延——Trev；排隊時延——Twait，網(wǎng)絡時延數(shù)學表達式為

首先分析舞臺燈光控制網(wǎng)絡的服務端發(fā)送sACN協(xié)議數(shù)據(jù)包可支持的客戶端數(shù)量。sACN協(xié)議中，在UDP/IP、數(shù)據(jù)鏈路層、物理層之上的三層——DMP Layer、Framing Layer、Root Layer的數(shù)據(jù)包長度為638字節(jié)，UDP、IP、數(shù)據(jù)鏈路層都有各自的封裝頭長度。定義應用層 （即sACN協(xié)議上3層）一路數(shù)據(jù)包長為LsACN，UDP頭長為LUDP，IP頭長為LIP，數(shù)據(jù)鏈路層頭長為LDLL（data link layer）這些量的單位都是字節(jié) （Byte），則在網(wǎng)絡上傳輸?shù)臄?shù)據(jù)包總長為

式 （1）是針對一路數(shù)據(jù)的，而當在同一以太網(wǎng)線上傳輸n路sACN數(shù)據(jù)時，公式為

當n為1時，網(wǎng)上傳輸Ltotal長度的一幀的時間為τtotal，網(wǎng)絡的帶寬為V，單位為Mbps（這里V是指在局域網(wǎng)情況下，一般是10/100Mbps，常用的是100Mbps，如果是在公網(wǎng)上，V是受電信運營商限制的），所以在網(wǎng)絡帶寬V完全利用的情況下，得到最小傳輸時間τ，關系為 （式 （4）乘以8是由于1Byte＝8bit）

在程序設計中，應用層的數(shù)據(jù)包發(fā)送間隔可以通過代碼控制 （如sleep（）函數(shù)），定義為Tival（interval，單位為ms）。根據(jù)DMX512協(xié)議燈光照明標準定義，DMX512數(shù)據(jù)同一路數(shù)據(jù) （如相同的接收機接收到第n路數(shù)據(jù)和下一次接收到第n路數(shù)據(jù)）之間傳輸時延最大為22.5ms（用T表示，單位為ms），最小傳輸速率為250kbps（用vmin）。Tival通過程序控制，范圍為 ［0，22.5）。

發(fā)送時延為Tival，傳輸時延為傳輸Ltotal長度的時間（這里不考慮傳播時延，因為傳播時延太小，可以忽略不記）。理想情況下，在不考慮排隊時延 （不考慮競爭的情形下）和接收處理時延 （CPU處理速度非常快和緩存非常大，此處時延忽略不記）的情況下，研究達到T標準（22.5ms）的數(shù)據(jù)發(fā)送服務器所支持的理想最大傳輸路數(shù)（n）。理想情況下不等關系為

由于在傳輸中sACN數(shù)據(jù)包長度相比整個包的IP頭大很多，為簡單起見，在不考慮LUDP、LIP、LDDL報頭長度的情況下，有

定義傳輸LsACN長度的時間為τ，有

式 （7）代入不等式 （6）有

對于通常使用的以太網(wǎng)局域網(wǎng)，V為100Mbps，又LsACN為638Byte，代入得到τ＝51.04μs，為使n取得最大值，取Tival為0，不等式取等號，有

又T為22.5ms，所以得到n的最大值為440.83，舍去小數(shù)點后值為440。對于普通的支持256個IP地址的以太網(wǎng)來說，除去數(shù)據(jù)服務器和路由器 （或集線器、交換機等），最大支持254個數(shù)據(jù)接收機，從440這個結果來看支持254個接收機是可以達到延時要求，但這只是在理想情況下，因為并沒有考慮的底層的這些頭長以及排隊時延這種重要因素，擁塞對網(wǎng)絡帶寬又有很大限制，V是受其影響的，滿足要求的數(shù)據(jù)接收機的數(shù)量事實上小于440這個上限，但是可以支持254個數(shù)據(jù)接收機。

1.3 舞臺燈光控制網(wǎng)絡架構設計

從1.2節(jié)的分析可知，對于支持256個IP地址的共享介質的總線型以太網(wǎng)而言，雖然可以滿足服務端所支持的sACN協(xié)議數(shù)據(jù)包傳輸客戶端數(shù)量要求，但是，在舞臺燈光控制中，出故障的節(jié)點需要快速定位并進行處理，以減小設備性能損壞對燈光控制的影響，總線型網(wǎng)絡的故障診斷和隔離是比較困難的。

此外，sACN協(xié)議在數(shù)據(jù)傳輸中依靠不停的發(fā)送燈光數(shù)據(jù)來抑制數(shù)據(jù)丟包造成的影響，但是這種數(shù)據(jù)傳輸模式造成網(wǎng)絡負載加重，不利于網(wǎng)絡擴展。本文針對sACN協(xié)議的缺點對其功能進行了擴展，設計了舞臺燈光應答幀?？蛻舳嘶貜蛻饚倪^程中，總線型網(wǎng)絡使用的CSMA/CD機制會導致沖突過多，對實時性要求很高的舞臺燈光系統(tǒng)來說是不能容忍的。

相比總線型網(wǎng)絡，星型網(wǎng)絡不僅和總線型以太網(wǎng)一樣可以支持sACN協(xié)議數(shù)據(jù)傳輸?shù)目蛻舳藬?shù)量要求，而且對于出故障的節(jié)點也能迅速定位處理。傳統(tǒng)的使用集線器的星型網(wǎng)絡在邏輯上仍然屬于總線型網(wǎng)絡 （共享介質），因此本文在進行sACN舞臺燈光控制網(wǎng)絡設計時，選擇以交換機為中心節(jié)點的星型網(wǎng)絡作為舞臺燈光控制網(wǎng)絡的拓撲結構，在進行多客戶端節(jié)點向服務器回復應答信號過程中，采用順序應答機制的軟件控制方法發(fā)送舞臺燈光應答幀，在實現(xiàn)sACN協(xié)議數(shù)據(jù)傳輸?shù)耐瑫r，能通過應答信號的信息來反映工作節(jié)點的狀態(tài)及確認信息，同時，減小數(shù)據(jù)沖突，對sACN協(xié)議的功能進行了擴展，為舞臺燈光控制網(wǎng)絡的未來發(fā)展提供一種思路［9］。

2 舞臺燈光控制網(wǎng)絡沖突避免機制

由于sACN協(xié)議使用不可靠的UDP傳輸機制傳輸燈光數(shù)據(jù)，不保證所有的數(shù)據(jù)包都被接收，服務端總是向客戶端不停的發(fā)送燈光數(shù)據(jù)來抑制或消除數(shù)據(jù)包丟失的影響，這樣會使網(wǎng)絡負載加重。本節(jié)首先定義了一種舞臺燈光應答幀格式，當客戶端接收到sACN協(xié)議數(shù)據(jù)后向服務端回復應答幀，告知其收發(fā)狀態(tài)、儀器性能等。當多客戶端都發(fā)送應答幀時，傳統(tǒng)的CSMA/CD機制會導致客戶端等待時間延長，效率降低，本文提出了順序應答機制來避免回復時的數(shù)據(jù)沖突，提高傳輸效率［10］。

2.1 舞臺燈光應答幀設計

當客戶端節(jié)點接收到sACN協(xié)議數(shù)據(jù)后，如果向服務器回復反饋信息，首先就需要確定服務器的位置，而在回復信息中又需要包含自己的位置信息和一些狀態(tài)信息——如本機是否運行正常、是否接收到服務器的sACN數(shù)據(jù)等。

在以太網(wǎng)局域網(wǎng)中，服務器和每一個客戶端都會分配到一個IP地址，在局域網(wǎng)中，每一個設備的IP地址都是不同的，因此在局域網(wǎng)中可以使用其32位IP地址來確定各自的位置。而如果控制規(guī)模擴展到多個局域網(wǎng)，服務器收到的IP地址信息就不能確定客戶端是屬于哪一個局域網(wǎng)。在ACN協(xié)議中，每一個燈光設備都有一個唯一的標識符 CID （component identifier）［11］， 由 于 sACN 協(xié) 議 使 用ACN整體協(xié)議的一部分，sACN是支持CID使用的。無論是在單局域網(wǎng)內還是多局域網(wǎng)內，CID都可以準確定位到客戶端的位置。如圖3所示，是設計的舞臺燈光應答幀格式。Sequence Number是表示該應答幀的序列號；A（ACK）指示是否收到sACN協(xié)議數(shù)據(jù)，1代表收到，0代表沒收到；S（State）表示客戶機的狀態(tài)，1代表功能正常，0代表異常；Options為以后的功能做預留；Length表示該應答幀的長度；CID指客戶機的唯一設備標識符。每一個服務端都有一個CID的映射表，記錄了服務端所管理的所有客戶端的信息如CID、狀態(tài)信息。當服務端接收到應答幀時，根據(jù)應答幀中的CID來查詢服務端中的映射表，讀取S狀態(tài)信息來實時修改客戶端狀態(tài)；根據(jù)A信息來判斷客戶端收發(fā)sACN燈光數(shù)據(jù)的情況，用以確定是否需要重新發(fā)送燈光數(shù)據(jù)。

圖3 舞臺燈光應答幀格式

2.2 CSMA/CD機制

CSMA/CD機制是以太網(wǎng)中使用最多的沖突避免機制之一。以太網(wǎng)局域網(wǎng)中的節(jié)點是通過廣播信道進行互聯(lián)的，因此當一個節(jié)點發(fā)送一個以太網(wǎng)幀時，局域網(wǎng)上的所有節(jié)點都會接收到該幀。傳統(tǒng)的共享介質以太網(wǎng)中，節(jié)點使用CSMA/CD機制來競爭信道的使用權。CSMA/CD的工作原理是：在發(fā)送數(shù)據(jù)前，先監(jiān)聽信道是否空閑，如果空閑就立即發(fā)送數(shù)據(jù)；在發(fā)送數(shù)據(jù)時，繼續(xù)監(jiān)聽信道，如果監(jiān)聽到信道沖突，就立即停止發(fā)送數(shù)據(jù)，等待一段隨機時間后再重新嘗試發(fā)送［12］。

CSMA/CD的發(fā)送控制流程如圖4所示。常用的退避算法是截斷的二進制指數(shù)退避算法［13］，即當一個節(jié)點發(fā)現(xiàn)線路忙時，要等待一個延時時間M，然后再進行監(jiān)聽工作。延時時間M由以下算法決定：M＝0到2k－1之間的一個隨機數(shù)乘以512比特時間 （例如對于10Mbps以太網(wǎng)，1比特時間為0.1μs），k為沖突 （碰撞）的次數(shù)，M的最大值為1023，即當k＝10及以后M始終是0到1023之間的一個隨機值與512比特時間的乘積，當k增加到16時，就發(fā)出錯誤信息。

圖4 CSMA/CD發(fā)送控制流程

若少量客戶端進行競爭信道待發(fā)送舞臺燈光應答幀時，CSMA/CD機制有其靈活的優(yōu)點。但是在舞臺燈光領域，控制的客戶端規(guī)模巨大，在此情形下，若依然使用CSMA/CD機制去競爭信道，必然會由于網(wǎng)絡負載加重導致回復時節(jié)點沖突增多，延時增加，效率下降。若CSMA/CD在沖突處理中使用的二進制指數(shù)退避算法會導致某一節(jié)點退避次數(shù)過多造成節(jié)點發(fā)送延時較大甚至發(fā)送失敗。

2.3 順序應答機制

本文提出了這樣一種順序應答機制來解決網(wǎng)絡高負載下的沖突處理問題。本文設計舞臺燈光控制網(wǎng)絡結構是單服務器多客戶端。順序應答機制是一種軟件沖突避免方法，其原理是：對N個客戶端節(jié)點進行排序，即第1、2、3……N個客戶端節(jié)點，在sACN燈光網(wǎng)絡中，當服務器向客戶端發(fā)送sACN數(shù)據(jù)幀時，客戶端被動的使用條件觸發(fā)機制，即在固定時間τ內收到sACN數(shù)據(jù)后才會啟動順序應答的服務過程，若超出τ表示沒有收到sACN數(shù)據(jù)包同時也會啟動順序應答的服務過程，此時應答幀中回復沒有收到數(shù)據(jù)的信息，根據(jù)其排序位置來確定發(fā)送回復幀的延時間隔，單位延時時間為舞臺燈光應答幀從客戶端到服務端的傳輸時間，可適當延長，編號為1的客戶端等待1個單位延時T后發(fā)送應答幀，編號為2的客戶端等待2個單位延時T后發(fā)送，以此類推。這樣N個客戶端經(jīng)過N×T的總延時后都向服務器回復了應答信息。

sACN燈光控制網(wǎng)絡的順序應答機制流程圖如圖5所示。

圖5 順序應答機制流程

3 仿真實驗

本文使用OPNET在星型網(wǎng)絡結構，分別對CSMA/CD機制和順序應答機制進行了仿真實驗，通過仿真結果說明其在不同負載下的沖突程度和平均延遲時間［14］。共享介質以太網(wǎng)采用CSMA/CD機制，交換式以太網(wǎng)采用順序應答機制，對不同負載下的平均延時和中心節(jié)點流通量進行仿真實驗，分析比較這兩種機制的性能［15］。

3.1 仿真模型與參數(shù)設置

本文創(chuàng)建了4個星型網(wǎng)絡，如圖6所示，分別是：使用集線器連接的30個節(jié)點網(wǎng)絡1命名為net＿hub＿30，位于圖中右上，node＿267為集線器，hub＿30為服務器，其他節(jié)點為客戶端節(jié)點；使用交換機連接的30個節(jié)點網(wǎng)絡2命名為net＿switch＿30，位于圖中右下，node＿236為交換機，switch＿30為服務器，其他節(jié)點為客戶端節(jié)點；使用集線器連接的100個節(jié)點網(wǎng)絡3命名為net＿hub＿100，位于圖中左上，node＿100為集線器，hub＿100為服務器，其他節(jié)點為客戶端節(jié)點；使用交換機連接的100個節(jié)點網(wǎng)絡4命名為net＿switch＿100，位于圖中左下，node＿202為交換機，switch＿100為服務器，其他節(jié)點為客戶端節(jié)點。

使用集線器的星型網(wǎng)絡 （net＿hub＿30和網(wǎng)絡net＿hub＿100）實際上就是共享網(wǎng)絡帶寬，邏輯上屬于總線型網(wǎng)絡，機制是CSMA/CD；而使用交換機的星型網(wǎng)絡 （網(wǎng)絡net＿switch＿30和網(wǎng)絡net＿switch＿100）是交換式以太網(wǎng)。

仿真中采集的統(tǒng)計量為：服務器的平均延時 （delay）、CSMA/CD機制的數(shù)據(jù)平均碰撞次數(shù) （collision Count）、集線器和交換機的轉發(fā)流量 （traffic forwarded）。離散仿真時間為30分鐘。

圖6 仿真網(wǎng)絡模型

3.2 仿真結果分析

（1）數(shù)據(jù)傳輸平均碰撞次數(shù)

CSMA/CD機制下不同負載時的數(shù)據(jù)傳輸平均碰撞次數(shù)比較如圖7所示。從圖中可以看出，客戶端節(jié)點數(shù)為100的負載下比客戶端節(jié)點為30的負載下的數(shù)據(jù)碰撞次數(shù)高。說明CSMA/CD機制在網(wǎng)絡負載大時，數(shù)據(jù)傳輸沖突大，網(wǎng)絡性能低。

圖7 不同負載下CSMA/CD數(shù)據(jù)傳輸沖突次數(shù)比較

（2）服務器平均延時

圖8所示為共享介質以太網(wǎng)和交換式以太網(wǎng)的服務器平均延時比較。

從圖8中可以看出，共享介質以太網(wǎng)的服務器平均延時要高于交換式以太網(wǎng)。因此，在舞臺燈光控制領域，選擇服務器延時更小的交換式以太網(wǎng)更容易達到舞臺燈光實時控制的要求，并且易于實現(xiàn)功能擴展。

圖8 共享介質以太網(wǎng)和交換式以太網(wǎng)服務器平均延時

（3）中心節(jié)點流通量

圖9所示為共享介質以太網(wǎng)的中心節(jié)點集線器與交換式以太網(wǎng)的中心節(jié)點交換機的數(shù)據(jù)流通量的比較。從圖9中可以看出，交換機的數(shù)據(jù)轉發(fā)量比集線器大，雖然交換機的工作量相比集線器稍大，但是它的工作量使得交換式以太網(wǎng)的服務器的延時降低，從舞臺燈光控制角度來說，服務器的延時要求優(yōu)先。

圖9 共享介質以太網(wǎng)和交換式以太網(wǎng)中心節(jié)點流通量

4 結束語

本文設計了一種基于sACN協(xié)議的舞臺燈光控制網(wǎng)絡，對sACN協(xié)議的功能進行了拓展，為了提高數(shù)據(jù)傳輸?shù)目煽啃?，減小網(wǎng)絡負載，設計了舞臺燈光應答幀，為了避免回復應答數(shù)據(jù)沖突，提出了順序應答機制沖突避免方法，該方法是以交換機為中心節(jié)點的交換式以太網(wǎng)進行sACN協(xié)議舞臺燈光控制。仿真實驗證明，選擇交換式以太網(wǎng)和順序應答機制進行sACN舞臺燈光控制比CSMA/CD機制的沖突數(shù)量少，延遲時間短，流量高。本文的提出方法將有助于未來的智能燈光控制的研究和發(fā)展。

［1］DMX512－A data transmission protocol for stage light controlling［S］.Ministry of Culture of the People’s Republic of China，2008 （in Chinese）.［WH/T 32－2008.DMX512－A燈光控制數(shù)據(jù)傳輸協(xié)議 ［S］.中華人民共和國文化部，2008.］

［2］JU Jie，SUN Ziqiang.RS485based intelligent light control system ［C］.Shanghai：The 7th Conference on Industrial Instrument and Automation，2006 （in Chinese）. ［鞠潔，孫自強.基于RS485總線的只能燈光控制系統(tǒng) ［C］.上海：第七屆工業(yè)儀表與自動化學術會議，2006.］

［3］LI Zhenfeng，LI Haixia.Design of intelligent lighting controller based on ARM ［J］.Low Voltage Apparatus，2007 （2）：28－30（in Chinese）.［李振峰，李海峽.基于ARM的智能燈光控制器設計 ［J］.低壓電器，2007 （2）：28－30.］

［4］JIANG Wei，JIANG Yujian，REN Hui.Analysis and prospect of control system for stage lighting ［C］.Yantai：CISP，2010：3923－3929.

［5］ ［Arch］entertainment technology architecture for control networks，E1.17“ACN”architecture ［EB/OL］.［2005－10－14］.http：//www.esta.org/tsp/.

［6］ ANSI BSR E1.31－2009.Entertainment technology－lightweight streaming protocol for transport of DMX512using ACN ［S］.Entertainment Services and Technology Association，2009.

［7］SHEN Qing，GUI Weihua，YANG Tiejun.Real－time control performance analysis based on industrial ethernet ［J］.Computer Engineering，2007，33 （1）：233－235 （in Chinese）.［沈青，桂衛(wèi)華，楊鐵軍.基于工業(yè)以太網(wǎng)的實時控制性能分析［J］.計算機工程，2007，33 （1）：233－235.］

［8］DANG Anxi，PEI Shaojing，SHANG Yaodong，et al.Simulation and performance analysis of Ethernet delay ［J］.Computer Engineering and Applications，2009，45 （2）：119－121 （in Chinese）.［黨安喜，裴少婧，尚耀東，等.以太網(wǎng)時延仿真與性能分析［J］.計算機工程與應用，2009，45 （2）：119－121.］

［9］PENG Jie，YING Qijia.Analysis for switched Ethernet applied into industrial real－time communication ［J］.Low Voltage Apparatus，2007 （1）：33－35 （in Chinese）. ［彭杰，應啟戛.交換式以太網(wǎng)用于工業(yè)實時通信的分析 ［J］.低壓電器，2007（1）：33－35.］

［10］Ricardo Moraes，F(xiàn)rancisco Vasques.Paulo portugal，survey of real－time communication in CSMA－based networks ［J］.Networks Protocols and Algorithms，2010，2 （1）：158－183.

［11］BAI Shilei，REN Hui，JIANG Wei，et al.Research on device identify mechanism in performance light network control system ［J］.Journal of Communication University of China Science and Technology，2009，16 （2）：64－67 （in Chinese）.［白石磊，任慧，蔣偉，等.演藝燈光網(wǎng)絡控制系統(tǒng)設備識別機制的研究 ［J］.中國傳媒大學學報自然科學版，2009，16（2）：64－67.］

［12］HU Jianjun.Research of work theory for CSMA/CD protocol［J］.Science Technology and Engineering，2008，8 （24）：6622－6624 （in Chinese）. ［胡建軍.以太網(wǎng) CSMA/CD 工作原理 研 究 ［J］. 科 學 技 術 與 工 程，2008，8 （24）：6622－6624.］

［13］YU Li，CAO Limin，XIONG Hui.Simulation and analysis of the adaptive binary exponential back off algorithm ［J］.Journal of Huazhong University of Science and Technology（Natural Science Edition），2007，35 （1）：29－31 （in Chinese）.［喻莉，曹利敏，熊慧.改進的沖突檢測算法仿真與分析［J］.華中科技大學學報 （自然科學版），2007，35 （1）：29－31.］

［14］ZHEN Li，LIU Ke.Research of emulation for Ethernet based on OPNET modeler［J］.Industrial Control Computer，2008，21 （9）：35－36 （in Chinese）. ［甄力，劉克.基于 OPNET Modeler的以太網(wǎng)性能的仿真研究 ［J］.工業(yè)控制計算機，2008，21 （9）：35－36.］

［15］GONG Lining，XU Yubin，MU Xiaoguang.Study on realtime performance of switched Ethernet using OPNET simulation ［J］.Industrial Control Computer，2008，21 （4）：60－61（in Chinese）.［宮麗寧，徐玉斌，牟肖光.基于OPNET的交換式以太網(wǎng)實時性仿真分析 ［J］.工業(yè)控制計算機，2008，21 （4）：60－61.］