星載交換機是以衛(wèi)星為核心的天基信息系統的關鍵子系統，是制約天基信息系統發(fā)展的關鍵技術之一，而星載交換機的核心是高性能的交換芯片。由于太空劇烈變化的環(huán)境溫度和各種離子的影響，使得宇航級電子器件的性能指標遠高于地面設備電子器件，而可選用作為宇航級電子器件的范圍又遠低于地面設備器件的選用范圍，同時星載設備對可靠性的要求遠高于地面設備。這就要求星載交換機在技術體制、電路結構、數據包隊列管理方式、調度算法等都與地面的交換機有很大不同，這些問題均有待于進行深入研究。

對于以衛(wèi)星為核心的天基信息系統，利用地面高性能IP交換機仍然存在較大問題，使其在天基信息系統中的使用受到了限制。

（1）功耗：星上設備對功耗有嚴格的控制，地面高性能骨干IP交換機的功耗通常在數百瓦到幾千瓦，這對于星載設備來說是難以承受的。

（2）系統可靠性：星上設備對系統可靠性要求極高，需要在不同層面上考慮冗余備份問題。

（3）系統重量與體積：星上載荷的重量是衛(wèi)星系統的重要指標，星載高性能交換機在體積和重量上與地面設備相比必須大幅度減輕。

（4）系統硬件結構優(yōu)化：IP交換機系統的硬件復雜度和集成度非常高，但由于空間溫度環(huán)境、空間粒子流等的影響，元器件選擇上存在很大制約，地面設備中廣泛使用的SDRAM、DDR、高性能CPU等器件都無法直接使用，這要求系統硬件結構和算法的復雜度必須降低，使之在可用宇航級元器件（如低速SRAM、處理器和存儲器）的基礎上實現較高的交換能力。

（5）系統軟件結構優(yōu)化：IP路由器系統的軟件復雜度非常高，由于在天基信息系統中高性能網絡處理器無法直接使用，所以部分傳統上采用軟件實現的功能和算法要采用硬件固化的方法來實現。這就需要簡化復雜的IP協議棧。

基于以上分析，地面高性能IP交換機在天基信息系統中的使用受到了很大限制。由于星上存儲器容量不能像地面那樣寬裕，隊列長度受限，而衛(wèi)星空中接口的往返傳播時延又大于地面，為了更好地設計流量控制，需要在星載交換機結構中使用一個復雜度低且有效的隊列管理器，減少對緩存區(qū)容量的要求，保證低時延，降低掉包率，達到用戶的QoS要求，提高吞吐量。

1基本概念

在星載交換機中，為了實現IP數據包快速轉發(fā)，一般采用基于定長信元的體制，IP數據包在進入交換結構前，被分割成許多固定長度的分組（下文統稱為信元）。交換結構的緩存方式主要有輸入緩存、輸出緩存和共享緩存。對于一個N×N交換結構，輸出緩存中存儲器的訪問速度是線路速率的（N+1）倍；采用共享緩存方式是線路速率的2×N倍；而對于輸入緩存方式，存儲器的訪問速度是線路速率的兩倍，與交換機的端口數目無關。為了增大交換機的容量，支持更高的線路速率，在星載交換機中有必要研究輸入緩存的方式。

對于輸入緩存中存在的隊頭阻塞HOL（HeadofLineblocking）問題，采用虛擬輸出排隊（VOQ）技術可改善該問題，使吞吐量達到100％。VOQ要獲得高的性能，關鍵問題是要設計一個匹配輸入和空閑輸出端口的高效、公平的調度算法，也就是二部圖的匹配問題。

采用虛擬輸出排隊機制的輸入排隊交換結構模型如圖1所示。在每個輸入端口的緩存區(qū)中，設置N個（N為交換機端口數目）FIFO隊列，每個FIFO隊列對應一個輸出端口。也就是說，將輸入端口為i，輸出端口為j的分組緩存到虛擬輸出隊列VOQi，j中，在調度器的控制下，將匹配的VOQi，j中的分組調度出去。

2隊列管理器結構

隊列管理器由輸入控制接口電路、多隊列請求處理電路、多端口請求處理電路、緩沖區(qū)接口控制電路、調度器等模塊組成。隊列管理器的基本結構如圖2所示。

輸入控制接口電路將接收到的IP數據包切割成許多長度為64B的信元，并做必要的標識，以便進行IP數據包的重組。每個信元都包含一個信頭，信頭結構包括目的輸出端口、優(yōu)先級和可以擴展的標識。多隊列請求處理電路根據信元的輸出端口和優(yōu)先級將信元流分成多個VOQ隊列，多端口請求處理電路在調度器的控制下將信元從信元緩沖區(qū)讀出。

設星載交換機有K個輸出端口，信元有N個優(yōu)先級。信元緩沖區(qū)（SRAM）的地址空間被劃分成K個私有區(qū)和1個共享區(qū)。私有區(qū)k（1≤k≤K）只能被去往第k個輸出端口的信元占用，而共享區(qū)可以被去往任何輸出端口的信元占用。設置K個私有FIFO（PFIFO1，PFIFO2，…，PFIFOK）和1個共享FIFO（SFIFO）。私有區(qū)k（1≤k≤K）的全部可用地址被記錄在（PFIFOK）中，共享區(qū)的全部可用地址被記錄在SFIFO中。

每個輸出端口均維持N個邏輯隊列，第n（1≤n≤N）個邏輯隊列對應于第n種優(yōu)先級信元。每個邏輯隊列由兩部分組成；第一部分位于私有區(qū)，第二部分位于共享區(qū)。邏輯隊列可能只存在第一部分，而不存在第二部分。在信元緩沖區(qū)中一共形成N×K個邏輯隊列。

在電路模塊中，設置N×K組寄存器，每個邏輯隊列分別使用一組寄存器來控制信元的寫入與讀出，每組寄存器包括：header、tailer、depth3個寄存器。其中header為隊首寄存器，記錄每條邏輯隊列的隊首地址；tailer為隊尾寄存器，記錄每條邏輯隊列的隊尾地址；depth為深度寄存器，記錄每條邏輯隊列的信元個數。每條邏輯隊列中上(前)一個信元和下(后)一個信元的存儲地址分別由前向地址指針pre_addr、后向地址指針nxt_addr記錄。

圖3中給出了前向地址指針pre_addr、后向地址指針nxt_addr以及信元存儲地址之間關系的一個示例。圖中所示的邏輯隊列的隊首地址由header記錄，隊尾地址由tailer記錄。該邏輯隊列中信元的存儲地址依次是4（隊首），7026，3900，5732，5733，7025，1（隊尾）。

在本隊列管理器設計中，交換機的端口數目和信元的優(yōu)先級可以根據星載交換機的設計要求和交換容量進行動態(tài)地擴展，私有區(qū)和共享區(qū)的存儲容量也可以根據流量管理的要求進行動態(tài)地擴展。前向地址指針pre_addr、后向地址指針nxt_addr利用FPGA內置RAM實現；PFIFO1、PFIFO2，…，PFIFOK和SFIFO利用FPGA內置FIFO實現；隊首寄存器header和隊尾寄存器tailer利用寄存器實現。[!--empirenews.page--]

3隊列管理器工作方法

當系統復位后，隊列管理器對地址空間進行初始化，將可用的地址指針寫入到地址空間。信元存儲空間分為兩部分，一部分為共享存儲空間，另一部分為K個針對每個端口固定分配的信元空間，以確保每個端口都有可用的存儲空間。當一個信元到達時，如果固定分配的空間和共享空間剩余容量之和不能滿足該信元時，則拒絕該信元。隊列管理器只需要知道到達信元的輸出端口和優(yōu)先級，就可以確定其進入哪個邏輯隊列。信元的寫入和讀出采用狀態(tài)機進行控制。

當有新的信元（n，k）到達時，其中n為優(yōu)先級，1≤n≤N；k為輸出端口，1≤k≤K。信元寫入控制流程如圖4所示。最后根據wr_addr，將信元寫入緩沖區(qū)。如果發(fā)生隊列擠占，則被擠占的邏輯隊列需要被更新，如果僅有一個信元，則header和tailer都被置0；反之，用前一個信元的地址來更新tailer。寫入信元的邏輯隊列需要被更新：如果該邏輯隊列沒有信元，則header和tailer都被置為wr_addr；反之，將tailer的內容記錄在pre_addr的第wr_addr個地址中，將wr_addr記錄在nxt_addr的第tailer個地址中，tailer的內容被更新為wr_addr。

當有信元讀出時，各輸出端口采用輪詢的方式，信元讀出控制流程如圖5所示。讀出信元的邏輯隊列需要被更新：如果僅有一個信元，則header和tailer都被置0；反之，用下一個信元的地址來更新header，tailer不變。

4仿真結果

本設計采用XilinxVertex-5FPGA實現，開發(fā)環(huán)境是Xilinx集成開發(fā)環(huán)境ISE13.1，電路核心模塊用VerilogHDL編程實現，仿真工具采用ModelSimSE。星載交換機有16個輸出端口，信元有4個優(yōu)先級，PFIFOk為256，SFIFO為4096。仿真驗證結果表明電路功能符合設計要求。

4.1寄存器讀寫指針時序仿真

由仿真時序圖6可以看出，初始狀態(tài)時，PFIFO0、PFIFO2、…、PFIFO15和SFIFO都為空，隊列管理器將空閑指針依次寫入PFIFO0、PFIFO2、…、PFIFO15中，當它們都為滿時，最后寫入SFIFO中。

由仿真時序圖7可以看出，隊列管理器首先從PFIFO0中讀出可用指針，當其為空時，就從SFIFO中讀出，然后依次從PFIFO0、PFIFO2、…、PFIFO15中讀出可用指針。當它們都為空時，則從SFIFO中讀出，直到no_ptr=1，說明地址空間無可用指針。

4.2信元的讀寫時序仿真

由仿真時序圖8可以看出，隊列管理器根據信頭中的輸出端口和優(yōu)先級，依次將信元寫入信元存儲器，信元存儲器形成64個邏輯隊列，然后在調度器的控制下，依次將信元從相應的邏輯隊列中讀出。

在衛(wèi)星通信中，業(yè)務種類繁多且突發(fā)性強，用戶對服務質量（QoS）要求較高，而衛(wèi)星網絡拓撲結構變化快，傳播時延大，這就要求星載交換機具有較小的交換時延和丟包率。本文設計了一種高性能隊列管理器，通過硬件仿真驗證，其基本能夠滿足星載交換機的各種性能指標要求，本隊列管理器采用動態(tài)擴展的設計方式，靈活度較大，但也存在許多不足之處，如組播信元的處理考慮不足、可能存在隊頭阻塞問題及IP包的管理問題，有可能由于一個信元的丟失導致整個IP包無法接受，這些都是今后進一步的研究工作。