當前人們信息通信的需求不斷增長，互聯網的應用也迅猛發展。據介紹，截至2005年6月底，我民的數量已達到1．03億。雖然寬帶用戶在數量上發展很快，但是大部分用戶尤其是一些高端用戶，對寬帶接入的速度還不滿意。另外，一些高帶寬消耗業務如IPTV的迅速發展，更加提升了對高帶寬提供能力的需求。以太網無源光網絡(EPo)結合了以太網簡單易用、價格低廉以及無源光網絡(PON術之一。2004年6月，IEEE802．3工作組『F式發布了EPoN標準IEEE802．3ah。目前，國內外的許多廠商已經投入到了PON至已經成功的推出自己的和設備。EPoN已經形成了一個比較完整和成，這將有利于EPON過程中占得了先機。本文首先分析了EPoN的研究背景以及發展狀況，并全面的介紹了EPON系統實現的幾種關鍵技術，包括MPCP協議、0Nu的發現 和測距過程、動態帶寬分配以及0AM功能等。然后著重研究了OAM子層的結構和功能，并通過對各種OAMPu結構的詳細分析描述了各種OM功能的實現方式。在上述研究和分析的基礎上，本文提出了對OAM子層的擴展協議。擴展OAM協議實現了配置下發、配置查詢、事件通知、批量配置下發、批量配置查詢以及文件下發等功能。最后，本文用軟件描述了擴展0AM協議的實現，并分析了協議的缺點及進向。擴展0AM協議基于EPON系統實現，在EPON設備開發的過程中對OAM子層進行功能的擴展。0AM擴展的功能主要是為一些二層交換機協議的實現以及用戶端設備測試等功能提供了必要的接口。擴展OAM協議的實現要求具有一致性(oLT和ONU)、準確性以及實時性。 MPCP，0NU，0LT商已經相繼推出了各自的EPN，如以色列的PAsAvE、的dloⅦs以及國內的格林威爾等。在這些設備制造商如、UT斯達康等也開始積極開發自己的EPON設備。目前，EPON電、杭州網通等運營商也已經開始積極部署EPON系統。我們有充分的理由相信，Frrx市場的啟動條件已經具備，而EPON作為FTTk的最佳解決方案之一將迅速在PoN接入技術中，除EPON之外，還有APoN和GPoN。APON(PNlTMIT—TQ983，由FsAN(FullsrieAccessNetworkIT—APN久的應用，其下行的速率可以達到622M，上行155M，上下行波長分離(1310)。但是，由于ATM協議復雜，接口昂貴，使APON就像ATM本生一樣，一直也沒有大規模應用。從目前的發展情況來看，APoN很有可能被EPON和GPoN所取代。GPON的標準是ITU—TG984系列標準，規定了GP0雌的物理層、Tc層和OAM相關功能。GPON標準的制訂考慮了對傳統TDM業務的支持，并且為了支持ATM等多種協議，GPON定義了一種全新的封裝結構enc印sulationmethod)，可以把刪和其他協議的數據混合封裝成幀。雖然圖5．9 數據庫網雄體喜——石務蛋M叢引趲p樣就很大程下來的寶貴技術經驗。其次的利用率、服務質量、多業務支持方面比EPaN技術更好，而且GPON的標準由ITU—T制定，定義的OAM信息比EPON標準定義的豐富。與GPoN相比，EPON是一種基于IEEE的標準，缺乏電信運營級的 、保護和 恢復功能。同時，由于缺乏相應的標準和行業支持的互通協議，EPoN設備無法在行業范圍內實現廠商之間的互通。本 基于EPON系統的上述缺點，通過0AM子層提供的擴展功能制定并實現了擴展OAM協議，實現了運營商對用戶設備(ONu操作、和管理。本文研究的EPoN系統EPON系統通過分光器實現了點到多點(P2MP)的拓撲結構。其上下行的通過不同的波長來區分，EPON系統中的下行數據采用1490m波長，而上行數據采用1310砌。在上行數據方面，EPoN采用時分復用技術(TDMA)使得在任一時刻只能有一個ONU進行數據的傳輸，并通過DA算法實現0Nu分配【3】。從理論上來說，EPN系統可以通過不同的波長實現上下行1．25b／s的速率，隨著萬兆以太網技術的成熟，最大速率可達10Gb／s，可以支持1020公里兩種最大傳輸距離，并且支持的分支數不低于32路。本人在讀研期間參與了在交換機基礎上的EPON系統設備的開發工作，開發過程中采用了知名公司的EPON套片。支持32路分光比，20公里光模塊，并實現了IEEE802．3a11標準中定義的大多數必須協議和可選協議，包括ONu的自動發現、0AM協議、MPcP協議等。在及其驅動提供功能的基礎上，EPON系統設備的開發工作進一步實現了一些二層協議的開發以及設備的管理測試，其中的二層協議包括生成樹協議(MSTP)、組播偵聽協議(IGMP-sNOO)、80．1x本人主要參與了EPON系統中軟件部分的開發。EI，0N系統的軟件分為兩個部分：oLT軟件和ONu軟件。0LT軟件包括大多數協議算法的實現、0LT和0NU的大多數配置管理以及事件處理等功能；ONu軟件主要完成對OLT0U0Nu過和設備擴展的0AM協議進行通信，從而實現OLT對ONU的管理和。在整個EPON系統軟件的開發過程中，本人主要負責完成擴展OAM協議的設計第二章EPoN系統的[本章】本章首先介紹了EPo了MPP、測距過程和系統同步、動態帶寬分配、OM功能等EPN實現的關鍵技術。2．1EPoN系統的工作EPON標準是由IEEE的EM工作小組最早 ，在很大程度上繼承了ITu．T和FsAN制定的APON標ITu．T G983，并采用了符合IEEE802．3協議的以太幀承載業務信息。EP咐是OL．T(光線終端、oNU()ODN(分／光器)單元成的到多的系，其結構一為星或樹型分支結構。EPON的上、下行數據采用一根光纖通過波分復用技術實現了全雙工通信模式，數據傳輸的速度均為1Gb／s(由于其物編碼方式為8B／10B，所以其路速為125Gbs)[4】。 的下行數據，根據不同的LLID值提取屬于各自的數據并去掉 ，其構示意圖如下所示匝面／由匝面回匝Ⅱ]E駔霉≥白Ⅱ圈(壺塑．＼＼]工＼＼、圖2—1：EPoNF上行方向(由ONU到Oul)采用時分復用的方式共享系統，任一時一個oNU發送上行數據；數據首先在ONU處打上各自的LLID，LLID是指邏輯鏈路ID號，0LT為每一個上的oNU都分配一個LLID；然后根／畝旦日曰匹亙四一零?：??田由里至圖2—2：EPoN上行數據2．2EPoN的協議層次IEEE802．3a11定義的EPON協議分層結構如下圖所LANOsl標準模型層 會話網絡

LAN屢圖2—3：EPON數據鏈路層相關層次包括：RS調和子層、MAC子層、多點控制子層、子層以及MAc客戶子層(LLc)。MAc實體實現以太網幀的接收和發送，OLT包括多個MA實體，以對應于多個oNU的MA程中，Rs調和子層對LLID和相應的MAc實體進行映射。MPcP制協議，EPON通過MPcP協議實現了偽州的發現和過程，并通過REPORT和GNT消息協助實現了動態帶寬分配功能【”。OM子層是可選子層，定義了管理、鏈路等功能，另外可以通過對原有協議的擴展，在子層實現OLT對oNu的各種配置狀態的管理。EPoN實現的關鍵MPCPMPCP協議位于MAC子層之上，0AM予層之下，提供了點，并維持了良好的TDMA機制【“。MPCP協議在MAC控制子層增加了5條消息：GATE、REPORT、REGISTERREQ、REGISTERACK、RGSR。MPCP協議幀的基本格式如下圖所86624404

長度，類型皿蛐gd胛ype)=88·08IMAc控制幀時間戳(Timest帥數據，填_觸擴展域fDd協，Pad艉eseⅣ酣幀校驗圖2—4：MPCPMPcP定義幀屬于MAC控制幀，協議類型為0x8808，目的MAC為01—80—c2一OO一00—01，且幀長度恒為64字節(不包括前導碼)，4字節的時間戳用于測距和時延補償，操作碼定義MAc控制幀的類型，5種MPcP幀的編碼分別從Ox00-02到Ox00一06(0x00—01為PAusE幀)。MPcPMPCP任一時刻只能有～個MAC能發送或接收數據幀，且控制幀的優先級要高于數據幀。在網絡中發現 新接入的oNu協助實現網絡中oNu的帶寬動態分配(DBAoNU的發當有新的0Nu加入系統的時候，MPcP協議將發現并使其能夠正常的工作。發現和過程通過MPCP協議幀，并由OLT主導完成。每一個新站點過程如下圖所圖2— 過程不意(11OLT發送一條DiscoveryGate廣播消息(LLID為32767)，消息的內容包括發f21已 的oNu將忽略此消息， 的0NU收到DiscoveryGate發送Rcgister_req消息，在其中包括了0咐u的MAc地址和表示其能力的PendingFants(3)0LT接收到Register_req消息后，開始為其分配新的LLID并將LLIDoNU的MAC地址綁定，并計算RTT，然后給oNU發送Register消息，消息的內容包括分配給這個oNu的LLID值、0LT所支持的ONu能力、以及對ONu能力的回應等。f41OLT已經擁有了oNU的足夠信息，再向oNu發送Gate消息并等待回應，如果收到包含一系列確認信息的Register_ack消息則發現過程完成o“。8。。————————：警———。￡的時隙，ONu根據相應的時隙發送信息吼ONu向LT發送的砌!POR消息包含ou中8求傳輸數據的大小，O￡T將根據隊列中等待傳輸數據的大小以及隊列的優先級進行帶寬的分配和流量的控制。0u’也可以根據paIldinggrant的值，通過GATE消息的向oNU分配多個【9】。2．3．50AM功對于以太網來說，最后 接入是一個全新的應用，需要一個完整的新的電信運營級的管理。和傳統的局域網不同，攝后的終端用戶不是按照以太網業務提供者的要求而配置的，最后 包括局端設備(0U)和用戶端設備(oNU)，因此，局端設備必須要有能力監測業務提供網絡和用戶駐地網之間的物理鏈路和設備的些要信息1o【1。EF工作組經決定供的oAM功能包括：遠錯誤指示，遠端環回，鏈路監視。0AM的消息通道采用可變長度且類型為Ox8809的慢速協議幀【12】。OAM協議的細節問題 在以后的章節中深入的討論。2．3．6AAA認EPoN系統屬于面向用戶的寬帶接入系統，運營商需要對用戶進行管理和計費，所以認證、、計費(AAA)功能是EPON系統所必須考慮的。802．1x的認證體系是基于端口認證的二層協議，與EPN效的優勢。802．1x在接入端口將業務流和認證流分離，避免了給認證者帶來處理能力上的壓力。802，1x依托EPON的匯聚能力將眾多的認證點的信息匯聚后再傳遞給認證服務器，在減小認證服務器并發連接數的同時，也增加了服務器同時管理用戶的數量。EPoN的AAA認證示意圖如下所剝13圖2—7：EPONAAA認證2．3．7安全性EPON下行方向的數據采用廣播形式，每個ONu能接收到所有廣播的下行數據，802．3all標準中為每個連接的0Nu設定LLID值，每個ONu只能接收帶有屬于自己的LLID的數據包和廣播數據包，其余的數據包丟棄不再轉發。在正段獲取所有LLID的信息，為此需要在下行方向對每個ONu另外，EPN通過MPP幀和0M幀來實現LT與Ou括：帶寬請求、帶寬、測距等等。由于MPcP幀和0AM幀的幀格式與以太網幀是一樣對用戶是透明的，且ON作為用戶側設備為用戶提供以太網口接入，這樣可能存在合法的用戶MPCP幀或0AM幀，來更改系統配置或搗毀系統的MCPOAIEEE802．3all沒有對加密的具體方案作描述，各廠家可以通過不同的第三章oAM子層研[本章】本章首先介紹了0AM協議在IEEE802．3ah0AMPD0AMA3．1oAM協議的引自以太網技術誕生三十多年來，以其價格低、可靠性高、可擴展性好、易于管理等優點逐步成為局域網(LAN)主導技術。目前，全球互聯網上98％的數據是通過以太網端口傳送的，在我國現有的局域網中80％以上為以太網【1”。隨著千兆、萬兆乃至十萬兆以太網技術的相繼出臺，以及其普及性、支持IP業務的優向城域網0以N)和廣域網(wAN)方向拓展，在城域網和廣域網中實施以太網 用者承擔，這樣的水平遠遠不到電信級的水平與SD、ATI~I等技術相比)于過局域的用者常是建者所者，盡管運營 面的水平過低，一般用戶還是可以接受的【l“。但是，以太網要進入需 的電信運營領域這樣運方式和 水平遠達到要。傳的以網乏一種高可性的絡理、行和 制以網要電信的網，先需要解決的是如何提供這種可靠的網絡運行、管理和 機制[17】。EPN接入對于以太網來說是一個全新的應用，主要包括局端設備(L1遠端設備(ONu)。局端設備必須要有能力監測業務提供網絡和用戶駐地網之間的物理鏈路和設備的一些重要的信息【18】，OAM的提出正是為了很好地解決這些問題。AMOM其網絡管理的目的。EFM工作組針對以太網無源光網絡(EPON)作為一個接入網技術需要額外的管理功能，而專門成立了oAM研究小組制定了oAM標準。802．3all，標準『F式引入了EFM的OAM規范。802．3all在OSI模型中的第二層(數據鏈路層)定義了0AM子層，OAM子層作為一個可選子層位于MAC客戶子層(LLC等)和MAC控制子層之間，如下圖所示：表示層會話層傳輸層

MAc控制(可選 圖3—1：oAM0AM協議是基于兩端DTE實現的，當鏈路兩端的OAM都運行時，兩個連接的0AM子層間交互OAMPDu，OAMAC0APDU。0MDU幀兼容IEE802t3定義的以太網幀結構，長度在“字節到1518字節之間，且遵循慢速幀協議。由于IEEE802．3all修正后的慢速協議定義1秒時間最多發送10個報文，所以盡管OAMPDU占用帶內帶寬(0AMPDU和數據幀共享信道)，但是對正常的數據通信是沒有影響的。慢速協議(SlowProtoc01OAM協議遵從IEEE802．3定義的慢速協議，慢速協議考慮了協議報文對帶寬的消耗以及協議的性能的影響，所以在定義中包含了一些限制。IEEE802．3中規定一條鏈路允許通過的最大慢速協議流量是1秒內通過50個最大長度AC幀(1518IEEE802．3規定的慢速協議限制條件如下：●1秒鐘內傳送的幀數目過5個慢速協議的協議報文類型(Subtype) 過10種，這里慢速協議定義的對應于當前協議類型(長度／類型字段)的最大類型數目。這就是說在超過10種的慢速協議子類型，但是對應于相同的協議類 10個子類型所有的慢速協議幀的大小都必須符合IEEE802．3的規范，IEEE802．3標協議產生的PDu遵從基本幀結構，不帶 由于EPON系統的特殊性，IEEE802．3a11對IEEE802-3的內容作了一些修改：對于每個點到點鏈路，1秒鐘時問內可以通過100個最大長度慢速協議MAC幀；1秒鐘內傳送的OAM幀數目 過10個；0AM報文的長度是可變的[19】[20】。3．2．2慢速協議幀的解析每一個接收到的MAc幀，如果其長度／類型(Leng“Typ)字段是慢速協議類型fox8．091IEEE802．3標準規定對慢速協議幀的統一 的慢速協議幀，則不往MAcclient傳送而直接判斷如果其子類型為合法且是上表中所定義的子類型，則傳送此數據幀到相應的協議實體；判斷如果其子類型為合法卻是保留類型的，則傳送此數據幀到MACCin】。3．30AMIEEE802．3MAC幀靠a802．3 MAC幀包括8個域：前導碼，幀起始分隔符(SFD)，幀目的MAC地址，幀的源MAC地址，協議報文的類型或報文的長度，數據部分，填充部分(PAD，如果報文不滿4字節時需要填充)以及幀校驗序列Fs)。除了數據部分和之外，8個域中的其它部分都是固定大小的。這三個域的大小是非固定的，但是幀的總長度必須滿足802．標準規定處于字節和 字節之間。MAC式如下圖所示【22】：766246—1500字4

前導碼幀起始分隔符目的M^c源MAc地址(DA長度，類型(LengIt竹填充數據口幀校驗序列圖3—2：MAC幀格 幀起始分隔符(SFD)：幀起始分隔符包含1個字節，其內容是10101011，幀起始分隔符的內容緊跟導碼的后面，而它的后面是MAc幀的起 目的MAC地址(DA)：目的MAC地址表示此MAC幀需要發送到的目的站點的地址，包含6個字節。MAC地址的內容可以是單播地址，組源MA(sMAMAMA包含6個字節。源MAC地址必須是單播地址(即第一個bit位必須是01。·長度／類型(Lengtb，r卯e)：長度／類型包含2個字節，作為一個數值型解析。這里根據這個數值的大小包含兩種情≯當小于或者等于MAC幀的最大有效值1500(十進制)時，這個數值表示緊跟在它后面的數據域的字節數；當大于或者等于1536時，這個數值表示MAcclient數據的類型。MAc幀最小有效值64(十進制)時，PAD域需進行填充數據和填充域(Data&隊D)：數據字段包含 協議，大小范圍為幀校驗序列域(FCS)：幀校驗序列包含4個字節，是對數據幀的CRCo』蝴PDu基本結OAMPDu幀基于802．3MAC幀(不帶TAG)，把原來的數據域分割成三個部分：標志域(Flag)，操作碼(Code)，數據域(Dat)。【3】OAMDU圖所示【24】：66源MAC地址2長度，類型(L朗gth廠rypc)=88-09【慢速協議予類型2標志域(Fl鹋u幀固定頭齜分操作碼42．1496數據，填充域(D砒{汗4幀校驗序列圖3—3：OAMl幀基本0AMPDu幀包括了以下幾個部 (DA)0AMPu組播地址01_80．c2。00—00—02；·源地址(sA)：0AMPDu幀的源地址上一次轉發此0AMPDu幀的設備的長度／類型(Length廠I卯e)且其值為0x88．09；所以在0AMPDU幀中此字段的值也為88一子類型(subtype)：此字段代表是何種慢速協議報文，這里OAMPDu標志域(Flags操作碼(Code)：操作碼表示OAMPDU的類型，具體請參看下面章充字段，確保幀的大小大于最小幀長標志域標志域定義了一些重要的鏈路事件，包括本地和遠端0觸Ⅵ實體的發現過程狀態和三個緊急鏈路事件‘川。標志域包含兩個字節，取值如下表所示名描為兼容以后可能OAMPDu時必須置保留位為0，接OAMPDu時忽略保遠端穩當變量remotestatevalid為TRuE時6(Rernote 遠端穩定性和遠端評測的值遠端評 次收到0AMPDU對應本地穩定性和5@emotcEvaluating)地評測的拷貝值；否則將置為O本地穩定性位和本地評測位作為本地穩定 4(Local 0x0=本地DTE發現過程不能滿不能完成發現過本地 0x3=保留，不能發送此類幀；如(Local 到此類幀，直接丟棄且不改何當前嚴重事 l=發生不明嚴重鏈路事2(Critical O=未發生不明嚴重鏈路不可恢復錯 l=發生不可恢復錯l(Dying O=未發生不可恢錯誤信 檢測到錯誤信O(Link 未檢測到錯表3—1：oAMPDu(E玎oredSybolP謝odEvent)、錯誤幀事件(Erro愴dFramevtTLErredFrmeeioden)以及錯誤幀秒數統計事件(Erro陀dF舊meSecondsSumaryEvent)。事件的具體定義在上一章中已經具有詳細的定義，事件的L、，描述本文將不作具體描述，請參考IEEE802．3h。3．3．7變量請求，響應變量請求0AMPDu用于向對端DTE請求MIB變量，一個變量請求OAMPDU可以包括一個或多個變量描述符127l。變量請求OAMPDu的結構圖如下所示：日的MAC源MAc地址長度，類型(E哪歸t九了子類型 標志域(F】操作碼

數據，填充域《Dat＆佻 幀校驗序列圖3—6：變量請求OAMPDU結變量響應OAMPDU用于對交量請求OAMPDu的響應，一個變量響應OAMPDU必須包括一個或多個變量容器。當OAMCliem接收到變量請求OAMPDU時，必須在1秒鐘的時間內發出變量響應0AMPDu；如果不能滿足相應的變量請求，則必須在1秒鐘時間內發出相應的錯誤信息。變量響應0AMPDU的結構圖如下所示：目的MAc源MAc地址長度，類型(Lcng【}l仃標志域操作碼數捌填充域(D砒n，P日幀校驗序列

圖3—7：變量響應OAMPDuMIB變量以及其變量描述符、變量容器等相關內容請參考IEEE802．3IEEE802．3ah標準，本文不作深入介3．3．8環回控制。舢垤環回控制OAMPDU用來控制遠端環回模式，其結構如下圖所目的MAc地址源MAC地址睦度，類型(Le“g山 標志域(FI昭操作碼數據填充域幀校驗序列

圖3—8：環回控制oAMPDu在環回控制0AMPDu中數據部分占用1個字節，當取值為Ox叭時表示進入環回模式，當取值為0x023-3．9組織擴展組織擴展OAMPDu是各組織根據自己特殊的功能需求對O—～M協議進UniqueIdentifier)。結構如下圖目的MAC源MAc地址長度，類型(LengtI哪于類型【操作碼(code)z0x03數據，填充域

圖3—9：組織擴展OAMPDu通過對OAMPDU的擴展我們可以實現獨立的0AM擴展協議，使生產商完成標準有自己獨特的業務，而完全的滿足，所以在IEEE802．3ah的基礎上，EPON的設備生產商將需要進一步實現自己的擴展OAM協議，以滿足特殊功能的管理需求【291。3．4oAM子層的結oAM●OAM子層必須向上層(包括MACCliem和鏈路聚IEEE802．3MAC服務●OAM子層可以使用下層(包括MAC和MAC控制子層)提供的標IEEE802．3MAC服務從上層向下傳輸的所有幀將象OAMPDU一樣經過OAM子層再通過同一個接口傳往下層；co舡oDiscvey0AM鏈路，Trallsmit過程用來傳輸0AMPDU，Receipt過程用來接收OAMPDu。當OAM子層接收到對端OAM實體發送的OAMPDu時，通過Con乜01模塊將0舢“PDu傳送到oAMC1ient；當OAMClientOAMDcntoAMD到Multiplexe模塊。●Multiplexer模塊：作為OAM子層的復用接口，所有的報通過Multiplexer傳送到下層的MAc控制層或MAC層。當OAMClient向對端OAMCiient發送OAMPDu時，Control模塊調用CTL：OAM．feqest原語向Multiplexer模塊傳送OAMPD；當MACClem向對端MACClientOAMPDU幀時，MACCliem調用MADATA．request原語向MultiplcXer模塊傳送報文；當本地0AM子層處于環回模式，Parser模塊收到報文時，將調用LBF：OAMI．rcquest原語向Multiplexer模塊傳送環回報文。在接收到任何一個原語后，Multiplexer模塊通過復用并向下層調用Ac：MADArA．request第四章oAM協議的【本章]本章根據EPoN系統設備開發中的實際需求，詳細描述了擴展OAM協議實現的基本思想以及其功能。整章圍繞擴展OAM協議的載體OAMPDu的結構設計以及的實現流程展開分析。4．1EoAM協議的引在上面的章節中，我們介紹了IEEE802．3all中規定的OAM子層包括遠端錯誤顯示、遠端環回測試和鏈路等功能。除此之外，由于IEEE802．3ah標準中定義的0M只能夠管理從0L’到0u的ON端口，而未涉及對0M來實現【32l。IEEE802．3ah定義的OAM協議中包括六種常用OAMPDu：信息事件通告OAMPDU，變量請求0AMPDU，變量響應0AMPDU，環回控制0AMPDU。OAMPDU類型通過操作碼的編碼來區分，除了五種常用的OAMPDU外，OAM協議還在操作碼定義了一個擴展碼。當操作碼為OxFE時，表示為擴展oAMPDU，本文將通過擴展OAMPDu來實現一些特殊功能的操作、 和管理。在本章中， 從EPON設備生產商的角度，通過OAM協議的可擴展特性來實現擴展0AM協議——Extended0AMProtocol(以下簡稱EOAM4．2EoAM協議EPoN系統屬于接入范疇，由光線路終端(OLT)元(aNU)組成，采用樹形拓撲結構。0u、放置在中心局端，分配和控制信道的連接，并有實時、管理及功能。ONu放置在用戶側，0L1’與ONu之間通過無源分光器連接。EPoN系統實現了光纖到戶(FTTH)，其典型應用如下圖所示：操作成功，則在ack中保存操作成功以及相應的操作結果，否則在ack中保存操作失敗，然后向發送端發送包含ack的確認報文。接收端協議的基本設計思想偽碼如下：VoidreceiVe_data()While(存在待接收數據({){){))}對于發送端來說，在發送報文之前先進行口原語操作。發送完報文后等待接收端發送的確認報文，如果在特定時間內未能收到確認報文或者收到ack．ODeratcCoⅡect為烈se的確認報文，則需要對報文進行重傳，3次重傳后未能收到確認報文或者收到ackOperatecorrect為fale的確認報文，則向客戶返回操作false信息；如果在特定時間內收到ack．OperateCorrect為tme的確認報文，則向客戶返回操作te信息以及相應的操作結果。發送端協議的基本設計思想偽碼如Vo|dsend—{wh¨e(存在待發送數據{從源端取得數據包把包放入待發送幀中while(特定時間內未接收到{If(已經重傳3次{獲取)}{獲取AckOperateResun和){獲取)))另外，對于某些單向的操作(ONU向0LT傳輸事件)，我們不用確認機制，而采用多次傳輸以確保報文正確的到達目的端。4．4EoAM協議功能實現在EPON系統運行中，OLT設備通過oA協議實時的控制和ONu設備的運行狀態。ONu設備可以通過一些程序接口對其進行必要的配置，比如ONu接口的流量控制、虛擬局域性(VLAN)、生成樹協議狀態(sTP)、組播協議狀態(IGP)等等。由于Ou權限一般不對普通用戶開放，所以局端的’將實現對Nu操作。本文EOAM協議正是在0A協議的基礎上，實現了OLT對更進一步的操作、和管理操作。EOAM協議需要實現的功能總結如下：浙江大·配置下發操作：局端設備OLT將通過EOAM協議實現對用戶端設備的配置操作。設置操作包括端口認證的設置、STP開關操作、端口vLAN值設置以及其他一些端口管理命令和設備測試的下發操作。設置操作可以根據用戶特定的功能需求進行擴展。配置查詢操作：局端設備OLT將通過EOAM協議實現對用戶端設備oNU配置信息的查詢操作。與設置操作相對應，查詢操作包括端口認證的查詢、sTP開關狀態以及端口sTP狀態查詢、端口VLAN值查詢以及其他一些端口狀態的查詢操作。查詢操作可以根據自己的需要進行功能擴展。●aNU事件發送：對于處于遠端的OLl、設備來說，有時候需要實時的知道ONU側的一些狀態比如ONu側的用戶網絡接口(UNI義了ONU事件發送功能，當aNU設備發生某一預先定義好的事件時，立即向0LT發送事件消息。·批量配置下發：端設備OLT對用戶端設備Ou進行配置以后，需要對配置信息進行保存，ONU在重新以后可以恢復原來的配置信息。配置信息可以保存在局端設備OI』側，也可以保存在用戶端設備ONu側。對于保存在OLT側的配置信息，當ONU重新以后將通過EOAM協議定義的OAMPDU報文批量傳送到ONu側進行配置。另外，在某些時候用戶需要的下發多個配置。批量配置查詢：局端設備OLT需要知道用戶端設備ONU的所有配置信息，除了部分的配置保存在L1’之外，對保存在ONu的配置的查詢需文件下發：局端設備Ou’和用戶端設備0NU之間需要實現一些較大文件的輸。Nu的作、 管都是Ou來現的包括其件的升級，通過 的文件傳輸我們可以實現0NU軟件的 升級。由于一個OAMPDu的數據容量大概是1k，所以一般超過1k的數據我們都用文件下發功能。這里需要 是，在實際應中般的傳輸都在lkb數據以下，而用到文件的下發功能的 軟件升級和 B00TRoM升級其傳輸大小都在幾百kb或者更大。ONU向0LT反饋配置OLT向0Nu查詢單個的配置Ox配置0x事件用于通告ONu狀態的改Ou’向ONu批量下發配0x批量配置ONU向O【T果OLT向ONu查詢批量配置信批量配置ONU向OLT反饋批量配置信文件0L1’向ONU下發大容量的保保表4—1：EOA^IPDU類型編碼·ONLLONulOLT應的所有0Nu操作，值為0表示對單個Ou操作。本章我們主要實現的是單個NU的相關操作，即此字段值恒為O，對于oNu批量操作的實現在下一章進行一定的探討。一個新的EOAMPDU此字段值加1，重傳的時候，此字段值不·有效數據域長度：有效數據域長度字段包含2個字節，用來描述數據／填充域中有效信息的長度。4．5．1配置下發在EON系統的典型應用中，局端的OLl需要通過OAM協議實現對的操作、和管理。LT可以通過命令的方式向Nu下發配置，我們這旱定義了配置下發EOAMPDU。OLT通過配置下發EOAPDu向ONU發送配置信息，ONU收到EOAMPDu后進行相應的配置操作，并通過EOAMPDu向T配置下發EOAMPDu的EOAM報文類型編碼是0x00，通過配置0x VLAN通過列表0x QINQ開0x 認證用戶名 設Ox 端口0x 光模塊Ox EEPROM澳們0x FLASH測表4—2操作結果(RETuRN)：操作結果字段包含1個字節，用來描述0Nu配置結果信息。此字段僅在oNU向Oul發送配置反饋的OAMPDu時有效，在OLT向Ou發送配置下發EOADPu時此字段無效。當操作結果字段值為1時表示配置成功，值為0表示配置失敗。數據長度(LENGTH)：數據長度字段包含2個字節，用在OLT向0NU發送配置下發EOAMDPu時，表示數據域有用字段的長度。當此EOAMDPu數據／填充(DAT，PAD)：的字節數可以在28．1482之間。擴展OAM根據配置類型的不同對數據域進行了相應的編碼，本文限于篇幅不對每個配置類型進行描述，l字 l字 26字幽4—4：VLAN模式配置下≯ ：操作的端口，根據實際的需要進行定義，對于單一端口ONu設計此字段無效如下圖所示 挪匝EoM報文序號有效數據域長度

30-圖4—5：事件通知EoAMP叫結事件類型(EVENT_TYPE)：事件類型包含1個字節，最多可以定義種事件類型。這里定義了幾種比較常用的事件類型，用戶還可以在事件類型(EVENT 事件名0x UNI端口0x uNI端口Ox 軟件升級表4—4：EoAMPDu數據長度(LENGTH)：數據長度字段包含2個字節，描述數據字段有效數據的字節數目。 數據／填充域(D刪PAD批量配置下發在EPON系統的某些應用場合中，OLT需要對單個0Nu批量下發一些令。例如當0NU重新的時候，0LT需要將保存在OLT側的aNU配置目的MAcI．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．一總配置項數據，填充域(D越胛幀校驗序列

總配置k圖4—6：批量配置r發EOAMP總配置項數：此字段描述批量下發配置EOAMPDU中配置項的數目，包含2個字節。總配置長度：此字段描述所有配置項描述信息的長度，包含2個字總配置結果：此字段描述所有配置的結果，包含1個字節，在0NU向0LT發送批量配置反饋的EOAMPDU時有效。如果批量配置的所有配置項都返回正確，則總配置結果返回正確，否則總配置結果返回錯誤。值為1表示正確，值為0表示錯誤。配置n撐：配置字段表示批量下發配置中的某一項的配置類型以及參數。配置項包括4個子字段：≯配置類型(OPTYPE)包含2個字節，其編碼如5．5．1節所示≯操作結果包含1個字節，用來描述ONu配置結果信息。此字段僅在oNu向ou、發送批量配置反饋的EOAMPDU時有效。當操作結果字段值為1時表示配置成功，值為0表示配置失敗。≯數據長度包含2個字節，描述數據內容即配置參數或配置結果的度填充域：如果報文未能達到6464字節這里需要 的是這里僅支持配置容量(即配置參數)較小的批量配置，一次批量配置的配置信息的大小 出一個報文的范圍。批量配置查詢批量配置查詢EOAMPDu的EOAMTYPE值為o)【04，其基本結構跟批量配置下發EOAMPDU基本相似。批量配景查詢EOAMPDU的結構圖請參看上一節的批量配置下發EOAMPDu結構。各字段的含義也基本相同，區別僅在于：批量配置下發EOAMDPu的數據字段描述的是配置下發的參數信息，而配置查詢EOAMPDU的數據字段描述的是批量配置查詢的返回信息。文件下發在EPON系統的應用中，某些時候需要由局端設備oT向用戶端設備ONu傳送較大容量的文件，比如0Nu軟件、BOOTLOADE等。由于文件的容量往往超出一個報文的數據域長度(1487字節)，所以需要定義一種特殊的機制。這EAMPDu傳送到接收到分塊的文件后組合再成一個完整的文件。文件下發EOAMPDu的EOAMTYPE字段編碼為Ox05，在文件下發的過程中，我們分別定義了七類型的文件下發EOAMDPU：傳輸請求、請求確認、數據傳輸、數據確認、傳輸完成、校驗確認以及傳輸確認。OLT在下 件之前先發送一個傳輸請求報文，請求信息包括文件類型、文件大小、CRC 以及22字節的填充信息；ONu在收到傳輸請求報文后，保存請消息并斷是滿請求條件主是否存文件，通過求確認向OT判的；OT請認后始傳，傳輸的過程當中每一個數據幀都需要ONU的數據確認；數據傳輸完成后0LT發送文件傳輸完成；ONU收到傳輸完成后，對數據進行cRc校驗，并向OLT回校驗結果；0LT收到校驗結果后，向ONU回送傳輸確認報文。七 類型數據2字 4字

2字 2字 22字2寧 字字 字 字 25一1479字字 字 字字 31字傳輸完

2字 30字

廠—————T2字2字 l字 30寧

1．．．。。．．．．．．。．．．．．．．．。．．．．．．．．．．．．．．。．．．【．，．，．+．．．．+．．．。．．．．．。．。．．。．．．．，J．．．．．．．．．．．．．．．．．．．．．．．．．．．．一圖4—7：文件F發EOAMPDU結傳輸請求：傳輸請求用于OLT向0Nu發起一次文件傳輸。這里包含62件大小、分塊數目、CRC以及填充域。傳輸請求的文件下發EOAMPDU大小為固定64字節，各字段描述如下：1接收到文件之后根據不同的文件類型對文件做相應的操作。文件類文件類 名0x 軟Ox Ox02— 保表4—5：EOAMPDu≯文件大小：此字段包含4個字節，描述待傳輸文件的字節≯分塊數目：此字段包含2進行傳輸。 》PAD：此字段用于填充報文至64字節·請求確認：請求確認用來答復0LT的文件傳輸請求。這里包含2個字段：報文編號字段、確認結果字段以及PAD字段，且報文的長度固定為字節。確認結果字段包含1個字節，用于描述NU是否有能力接收傳輸請求中描述的文件，確認結果字段值為1表示Nu接受發送報文，值為0表示ONu不接受發送報文。數據傳輸：數據傳輸用來傳輸文件的內容。這里包含4編號、分塊編號、分塊大小以及數據填充域。≯分塊編號：分塊編號字段包含2個字節，描述當前傳送EOAMDu≯分塊大小：分塊大小字段包含2據的大小，取值范圍為27．1481。》數據／填充域：數據／填充域字段用來存放文件的有效數據，可能包含27—41EoMPu數據字段未滿141字節外，其他EAMU段都是148l字節。數據確認：每當接收到OLT下傳的數據傳輸，0NU即需要向OLT一個數據確認，OLl’64傳輸完成：當收到最后一個數據報文的數據確認報文后，OLT需要向ONu發送傳輸完成報文。傳輸完成報文僅包括報文編號。校驗確認：當收到傳輸完成后，0NU針對整個文件進行CRC校驗，并與OLl、發送過來的 進行比較，如果相等則表示文件被正確傳送，否則傳送失敗。這里僅有傳送結果一個有用字段，包含1個字節，值為l表示傳送正確，值為0表示傳有誤。EoAM面的章節中我們已經提到，我們實現的擴展OAM協議采用Active—Passive模式，即OIT端的0M子層采用Acive模式，ONu端的M子層采用Pssie模式。除了aNu主OLl發送事件之外，所有的操作均是由OLT主動發起的。所有的操作都需要同步，即在同一時刻僅可能有一種操作單個配置下發／查詢和批量配置下發／查詢的過程涉及到一個OLT的發送和等待過程，與文件下發操作相比，其過程要簡單的多，其工作模式如下：首先由0L1、向0Nu發送控制命令EOAMPDU，然后等待ONU回應的oNu收到控制命令EoAMPDu之后對報文內容進行解析，根據報文中包含的參數信息進行相應的操作，操作完成后0巾fu向OLT發送包含操作結果的響應EOAMPDU。由于Ou’和ONu之問的鏈路可能存在的問題，OLl、或ONu在接收不到響應報文的情況下需要重發同一個控制命令，3次重傳失敗后作為錯誤退出。由于重傳機制的存在，OLT或oNU有可能收到相同的控制命令或響應報文，當ONUOLT0u、收到相同的響應報文時直接丟棄。 開始前OLT需要先計算此 ，ONu在接收到整個文件后也計算，并判 的值是否相同。CRC的生成多項式采用CRc．16碼G(x)=x16+x15+x2+1，生成多項式為Oxc5，計算過程的具體細節請參看相關料文件下發的處理流程與其他操作也有所不同，過程相對比較復雜，涉及到多次EOAPDuOL和ONu處理過程。文件下發操作包括3個過程，分別是建立連接、數據傳輸以及釋放連接。其過程如下圖所示：圖4—8》OLT向ONu下發傳輸請求報文，然后等待傳輸確認EOAMPDu如果特定時間內不能等到請求確認報文，OLTPDu，重傳次數不得超過3次，3次重傳以后還不能收到請求確認報文將作為失敗處理。》0NU收到傳輸請求報文后先判斷如果能夠滿足傳輸請求的資源f這LT收到0NUL輸。>文件被分為多個數據傳輸報文進行傳輸。每傳輸一個數據報文LT都需要等待到數據確認報文后才可以繼續發送下一個數據報文，特敗后退出。≯0Nu收到數據報文后根據文件塊的編號保存數據，并向OLT個數據確認報文。≯0u、在收到最后一個數據確認報文后，向ONu發送傳輸完成報文，然后等待校驗確認報文，特定時間內未能接收到校驗確認報文時重傳傳輸完成報文，且支持3≯oNUCROLON3次重傳以后還是未能收到傳輸確認報文則傳輸失敗并退出。ou收到傳輸確認報文表示oNU》0LT接收到校驗確認報文后，首先向ONu發送傳輸確認報文，并根據校驗結果判斷文件是否正確下發。傳輸確認報文發送完成后，表示OLT側文件下發過程的結束。另外需要注意的是，文件下發過程中存在的重傳機制提高了可靠性，但是在文件下發開始后，可能在某些特殊情況下3次重傳都不能到達對端，而使對端一和0咐U件下發開始時打開定時器，一旦收到文件下發類型EOAMPDu定時器便重新囂位，3秒溢出，定時器溢出表示文件下發失敗。第五章EoAM協議的【本章]本章根據上一章描述的EOAM協議詳細介紹了OLT和oNu結構和處理過程。整章圍繞ONu和0L，T的EOAM軟件模塊，詳細描述了各種不同的操作分別在oL，T和0NU兩側的處理過程以及軟件的具體實現。5．1軟硬件環境EPON系統的軟硬件實現包括OLT和ONU兩部分，通過ODN實現點到多點模式，這里我們支持的分光比是1：32，即一個OLT可以對應32個0Nu。0IJ和0N的光模塊分別是0公里光模塊，即OT和U的最遠距離可以是公里。上下行數據分別采用不同的波長，且下行數據通過波長區分普通數據和CAⅣ。上行數據的波長是1310nm，下行數據的波長是1490帆，CATvf只有行1的數據波長是1550nm攝沅距離，一????廠普通數據，一????廠

，L廠—i]?????!?∥弛．蟹}———

＼、匪圖5—1：EPON工作我們這里采用了以色列公司PASSAvE的EPON：蒼片。OLT的件結構設計比較復雜，基于特定的交換機且與本文的軟件無直接聯系，我們這罩不作描述。ONu的硬件除了包括 的PON ，還括4M的FLASH、16M的sDRAM、20公里光模、12字節的EPROM、ssIM以及交換 。其件構下所：幽5～2：0NUEPON軟件系統包括ONu和OLT兩個部分，其中ONu采用了uc／0s系統，0LT采用了Vxworks操作系統。整個EPON軟件系統分為三層：最下層是操作系統以及底層驅動，底層驅動主要由生產商提供，用于向適配層軟件提供一些接口AP；中間的適配層軟件用于向上層軟件提供協議或其它操作實現的接口，并實現ONU和Ou’的擴展OAM協議；最上層的軟件用戶用于實現各種協議以及用戶命令的下發。EPaNoNu部 0LT部@圖5—3：EPON軟件本章所要實現的擴展OAM軟件位于EPoN系統的適配層，主要包括兩個部分：oNU擴展OAM軟件和OLT擴展OAM軟件。從適配層軟件的角度來看，ONU和0u’之間的唯一交互是EOAMPDU，即0NU適配層軟件和OⅡ適配軟件的通信必須通過擴展OAM軟件來實5．2EoAM模塊概述EOAM模塊包括兩個部分：Ou、擴展OAM模塊和oN擴展0AM模塊。EPON的管理模塊通過調用0LT擴展0AM模塊提供的接口向0NuEOAMPDU，ONuOAM模處于 態，收EOAMPDU報文進行相的作通EOAPD向oT回作果從oN返操結由OLT擴展0AM模塊進行解析并返回給EPON管理模塊。具體的操作流程如下圖所示EPoN管理；)LT擴J挺0AM遠距離光纖，發0Nu擴展OAM逅oNu圖5—4：EOM5．3ou’擴展oAM模塊的實5．3．1oLT擴展oAMEPoN系統軟件實現OLT對0NU的操作、試、協議下發、配置管理、日志管理等相關的功能。一個0LT跟32個0Nu進行交互，0Nu的端從O到31分配。0I_，T向0Nu發送的數據屬于廣播報文，0Nu在Rs子層對數據進行過濾，接收LLID與自己相等的報文，丟棄LLDONu。u、將建立全局oNu結構，獲得并保存0u的LID、Mc地址以及M版本等，0N的全局結構和定義如下：圖5—6：oLT側非文件下發報文接收操作流程在收到EOAM報文后首先判斷是否為事件通知EOAM知EOAM報文，則解析相應的事件類型并作相應的事件處理，否則繼續判斷EOAM類型是否匹配，對于配置下發和配置查詢類型EOAM判斷配置類型是否匹配，如果類型存在不匹配則作相關錯誤處理并退出；如果EOAM類型以及配置類型(配置下發和配置查詢)都匹配，報文接收進程保存報文內容并通知命令下發進程，然后結束返回。當0u、接收到正確的響應報文后首先需要判斷oNU的操作是否成功，在oNU操作成功的情況下EOAM模塊才報文數據域并向EPON管理層返回正圖5—7：0LT在批量操作過程中需要注意的是，ONu執行成功表示所有的配置操作都成功，而失敗則表示存在某一個或多個配置操作失敗。另外，由于NU件的時候采用了3次重復發送以提高可靠性，所以在事件處理前需要判斷接收到一報文計數器值相同的事件報文即為重復事件。oLl’擴展oAM模塊的文件操作處理文件下發的操作中涉及到了7類型的文件下發EOAMPDu，包含了三個過程：建立連接、數據傳輸和釋放連接。上一章已經對三個過程中OLT和的報文和狀態交互過程做了詳細的描述，下面將分別描述三個過程中0u、的操作流程：首先由OLT構造傳輸請求報文并向oNU發送，傳輸請求報文的內容包括文件類型、文件大小、分塊數目以及cRc。發送完傳輸請求后OLT等待ONu的請求確認報文，收到請求確認報文表示文件傳輸連接的建立。如果在00LT報文，圖5—9：OLT側文件下發數據傳輸過程的處理·釋放連接數據傳輸，OLT向ONu發送傳輸完成報文。然后等待校驗確然后根據校驗結果判斷文件傳輸是否成功，并向EPON管理層返回操作結果。圖5—10：0LT側文件F5．3．3oLT擴展oAM在上一節中已經提到OLT擴展0AM模塊存在命令下發以及報文接收兩個進程。在系統的實現中，OLl、的擴展0AM模塊需要同32個ONu的擴展OAM模回之前不可能產生另外一個新令下發進程，這個互斥過程由EPON管理模

進程 全局變 進程、、、廠進程 全局變 進程／／_竺三蟲幽5一11：0LT側文件下發0u、擴展OAM模塊定義EOAMPDus結構的全局變量用于保存發送的報文。在超時重傳的情況下，0U、需要重新發送上一次構造的報文，EOAMPDUs的結構定義如下：／．EOAMPDU strucI{unsIgnedshOrt 0AMPDU—HEAD—SstOamHead：EOAM—RECoRD—_SStEoamRecord)EOAMPDU—

另外，在OLT接收到EOAM報文時，需要對保存的報文內容和新接收到的報文內容進行比較，對報文的EOAM子類型是否匹配以及報文是否重復等進行判斷。比較的內容主要是EOAM擴展各字段，EOA—RECORJ)_S的結構定義rEOAM字段結typedefslruclstLEOAM—{unsjgnedcharaucOu_【OUl_LEN】 ，‘產商標識unsignedchar ，’EOAM子類unsignedchar r是否批量unsignedshort ，+EoAM報文序unsignedshort ，+報文有效數據unsignedcharaucPduData【MAx_EOAMPDU—E】 ，+有效數據域)EOAMRECORD5．4ONu擴展oAMoNU擴展oAMoNu擴展oAM模塊非文件操作處理流 擴展OAM模塊的非文件操作的處理流程如下所示批精配置查詢．1根據類型作批量套 。l構造包含配置礴詢結果的配置¨『一一 詢操 『 反饋EoAM報浙麥桎鱒移積摳鱈辨烈辯鞘笛∞鮭豁批；坼犁暨￡鋈哩鞋翳的婦“兢鉑耨孔丑創虬i奏霎甌蓊滋僭猿彰囂H積∞鞘繇j如攀濰憎萋塞鰻肘秦鬟薹齲髏鞋萎兩曝薔國隋倆頂僻|1j囊帶舊州塞謄菩擊鞘鬈孽饅漤；㈢㈣強霎鞫舉￡缸參耐獸引器朝；薹霪萋引#輔引巖群～#翻手越跳j姘酬合奪誶論簧萋霧冀摹萋囊聚羥針釜不柏j記錄進行信息提取，最后利用本體描傳輸狀態位，然后向0LT發送請求結果為成功的響應報文。這里所要保存的參數包括文件的類型、文件的大小、文件的分塊數目以及CRC 。文件傳狀態位是一個全局變量，用來標識是否處于文件傳輸狀態。ONU建立連接流程i收到傳輸請<乏受至>竺一L傳輸狀態位，請求結 l請求結果置L發送請求確認報匙多—————!——— 丌始文件內容傳輸 I文件F發失敗退圖5一15：0NU側文件F其次是數據傳輸過程，連接建立以后，ONu開始等待OLT發送的數據傳輸OLTsou圖所示圖5—16：ONU側文件’r發數據傳輸流最后是釋放連接過程，在釋放連接之前需要判斷文件是否被正確傳輸。當ONu接收到傳輸完成報文后，首先對下發的文件進行cRc校驗，并向OLT發aNU出200毫秒ONU需要重傳校驗確認報文，最多支持重傳3次，3次重傳失敗表示文件傳輸失敗。釋放連接過程的過程如下圖所示：圖5—17：0NU側文件FoNu擴展oAM0Nu擴展OAM模塊的是EOAM初始化函數，由ONu軟件在啟動的初始化函數中調用。EOAM初始化函數啟動EOAM處理任務，并由EOAM處理任務處理OLT發送過來的各種OAMPDu報文以及發送ONu產生的事件。由于0u1下發EOAMDu之后，只有在收到Ou響應EOMPDU或超時的情況下才可能發送下一次EOAMPDu，所以0Nu側的軟件邏輯處理比較簡單，其函數浙江大＼圖5一17：EOAM模塊0NUONu擴展oAM軟件在EOAM初始化函數中啟動了EOAM處理任務并定義≯定義EoAMREcORDSEOAMPDU各字段，每收到一個有效的EOAMPDu，都需要更新這個全EAMD 定義發送EOAMPDU序號，每產生一個EOAMPDU1一次，ONU每收到一個EOAMPDU都需要判斷此序號的值，如果全局變量的序號與接收到的報文序號值相同，標識收到重復報文；>定義EOAMPDUPAcKETS類型的全局變量，用來保存發送≯定義文件傳輸狀態位，用來標識當前是否處于文件傳輸狀態，當收到文位還原。5．5擴展oAM模塊接口實OLT擴展OAM模塊向適配層模塊提供EOAM命令下發的接口，以實現塑堅查堂堡主蘭堡絲對ONUOL和NEOAM模塊。EOAM模塊向oLT適配層模塊提供三個接口：單個配置操作，批量配置操作，文件下發操作。三個接口的描述如下：unsignedIongEoam—S．ngIe—Request(unsignedcharunsjgnedshortunsignedshOrtusWaitTime，EOAM—0PERATEI-lNFo— 批量配置下發／查詢接口p～——一一一一——一-一一一一一-一一一一一——一一一一——一一-一～——一一-～一函數名

Eoam—Batch—unsignedcharunslgnedshortusLf-d：unsignedshOrtusW臺itTime：unsignedshOrfEOAM一0PERATE-|NFCI_Sstope怕teInfo

1O表示批量配置查詢操作發送的L|id號，O一32批量配置下發或杏詢信息unsignedlongEoam—Balch—Request(unsIgnedcharuns的nedusUid．unsignedshortusWaifrime．unsignedshOrfEOAM一0PERATE—lNFo—SstOperateInfo口配置下發，查詢和批量配置下發／查詢中，所有的配置信息保存在結構體據內容，EOAM一0PERATE—INFO_一S結構定義如下浙江大廣配置下發，查詢結構士typedefstructstr_EOAM—OPERATE-{EOAM—OPERATE— blOpResuunsigned unsigned )

，t枚舉變量描述配置類，‘ONU操作成功，★數據內EOAM—OPERATEI-INF()—-文件下發，’一一一一一一一?-一一——～一～——一一一一一一一——一一函數名 EOAMFiIeunsignedshOrtusLlid：unsignedshortusFHeTypeNumunsignedIOnguIFiIeLength：unsignedchar‘pucFiIeConlentunsignedchar

發送的L|id號，0—????——一～一一????～一一一一?～一一一～～一——??-。unsignedIongEOAM—FiIe—DownIoad(uns．gnedshortunsjgnedshOrtusFiIeTypeNum，unsjgnedlOngulFileLength，unsignedchar．pucFileContent，unsignedchartpucOpResull文件下發操作需要進行報文的多次交互，這里定義的接口并非直接下EOAMPDU，而是通過了另外一個發送文件下發類型EOAMPDU的接函數名 F¨e．-unsignedshOrtusUid：unsignedshortusWaitTjme：unsignedshortusDataLengthunsignedcharFiIeContent：

數據???～一一一??～??一一???～一一一??～??一一一??～?一????～一一一unsignedshOnusWbitTime，unsignedshorfusDataLength，unsjgnedchar在上述接口中，當LLID值為32時表示進行批量的操作(僅支持單個配第六章總結與以太網無源光網絡(EPON)是一項新的接入技術，由于其靈活性、低成本等特性已經取代了APN成為了目前ON市場的主流。盡管EPONGPN，但是相比之下EPN的技術更加成熟并且成本優勢明顯，所以當前的接入應用中EPON是最具競爭力的。目前，EPaN和設備的研發已經成為國內外一些科研單位和設備生產商的重點。本人在讀研期間參與了EPoN終端設備(包括u、和oN)軟件的開發，本文正是作者在參與開發的過程中完成的。完成的主要EPN系統的開發過程涉及到了從 到設備的軟硬實現，本人在整過程中參與了0AM協議的研究和系統軟件部分的開發，提出了一套可方便定義各種AM功能的展OA協，并負責了擴展0A議的設計和軟件實現。 主要完成了以下內容(二)介紹了EPCIN系統的工作原理和協議層次模型，詳細分析了EPON系統實現的關鍵技術包括MPcP協議、0Nu的發現和過程、動態帶寬分配的實現、OAM功能以及EPON的安全性。(三)介紹了0AM協議的引入過程和慢速協議的特點，分析了0AM幀的基本結構以及五種oAM幀的處理方式的功能，并在此基礎上通過對OAM子層的內部結構模型及其服務接口的描述，詳細分析了oAM子層的工作過程。OA協議所要實現的功能(配置下發、配置查詢、事件通知、批量配置下發、批量配置查詢以及文件下發)，并根據其定義的功能設計了擴展OAM協議幀結構及其實現的各種功能的基本處理流程。(五)介紹了擴展OAM協議實現的軟硬件環境及其軟件模塊結構，并描述軟件模塊的接口以及OLT和ONu兩側軟件的實現過程，其中詳細的描述了各種操作功能在OLT和ONu兩側的實現過程，并進一步設計了批量ONu現方法和過程。最后分析了擴展0AM協議的性能，并提出了其改進的方向。展EPON的0AM能力離電信運營級網絡所要求的能力還是有一定的差距的，在支持的范圍和具體功能方面都還沒有非常具體的定義。而由國際電信(ITU．T)制定的GPON標準在這方面做的非常出色，GPON定義的OAMAM、POM和OC0NU要想在寬帶接入領域繼續保持整體優勢，EPON必須對自己的OAM行全面的提高，使其達到電信運營級的要求。本文對EPON的OAM能力進行了擴展，使LTONEPON系統開發和研究中參與的時陽J比較短，對一些關鍵性的技術還不能做到非常透徹的理解，擴展0AM協議的實現也僅僅做到了特定系統上的功能可用性，作中，EPON系統在0AM方面需要解決下面兩個問題： 由于OAM遵從慢速協議，oLT和ONu之間較大文件傳輸解決方案響應過式用來快速傳輸文件。本人在實際EPON系統上設計的擴展OAM協議方案，基本上屬于ONU管uOU功能。由于不同設備生產商對ONU的管理有不同的機制，所以限制了EPON系統的互操作性。在將來的工作中我們需要繼續對EPON系統的管理功能進GPON和AONPON的0AM能力進行進一步的加強并使其標準化，使其達到電信運營能力的要求。Majntenance(OAM)一A’I Hwmetmethemetfomm．org／PDFs，EFMA／EFM％200AM％20Tbtorial％20v2．pdf2005—1l一[20】Britishcolumbiacommunityconnectivitycoop．EthemctPassaveOpticalNetworks．wwwbc3．c“media／te