DVB-RCS網路中，FCA機制對TCP效能的影響

國

立

交

通

大

學

資訊科學與工程研究所

碩

士

論

文

DVB-RCS 網路中，FCA 機制對 TCP 效能的影

響

The Effects of FCA Mechanism on TCP Performance

over DVB-RCS Networks

研 究 生：邱耀宏

指導教授：王協源 教授

DVB-RCS 網路中，FCA 機制對 TCP 效能的影響

The Effects of FCA Mechanism on TCP Performance

over DVB-RCS Networks

研 究 生：邱耀宏 Student：Yao-Hung Chiu

指導教授：王協源 Advisor：Shie-Yuan Wang

國 立 交 通 大 學

資 訊 科 學 與 工 程 系

碩 士 論 文

A Thesis

Submitted to Institute of Computer Science and Engineering College of Computer Science

National Chiao Tung University in partial Fulfillment of the Requirements

for the Degree of Master

in

Computer Science

July 2007

Hsinchu, Taiwan, Republic of China

D V B - R C S

網 路 中 ， F C A

機 制 對

T C P

效 能 的 影 響

學生：

邱耀宏

指導教授：

王協源 老師

國立交通大學資訊科學與工程學系﹙研究所﹚碩士班

摘

要

在 IP 網路盛行的今天，DVB-RCS 衛星網路越顯重要。許多的研究報告在探討

DVB-RCS 網路中的資源分配系統，不過鮮少提及其中的 FCA 機制，因此我們希望藉

由模擬方式來探討 FCA 機制對 TCP 效能的影響。礙於目前尚無一套開發完整的

DVB-RCS 模擬平台可提供做為研究使用，我們在 NCTUns（交大網路模擬器）上開發

一套 DVB-RCS 模擬平台。NCTUns 是一套開放的網路模擬器，我們所設計的 DVB-RCS

模擬平台將會在 NCTUns 4.0 釋出。除了探討 FCA 機制，本論文亦詳細描述 DVB-RCS

模擬平台的設計與實作，想要利用 NCTUns 作為研究工具的研究者可透過本論文認

識該平台的核心架構。

The Effects of FCA Mechanism on TCP Performance over DVB-RCS Networks

Student：Yao-Hung Chiu Advisor：Dr. Shie-Yuan Wang

Institute of Computer Science and Engineering

National Chiao Tung University

ABSTRACT

Many studies discuss the capacity allocation over DVB-RCS networks. However,

few of them refer to the FCA mechanism. We discuss the effect of FCA mechanism on

TCP performance over DVB-RCS networks via the simulation methodology. We develop

a DVB-RCS simulation platform on NCTUns network simulator. In addition to the

discussion over FCA mechanism, this thesis describes the design and implementation of

the simulation platform.

誌

謝

首先感謝恩師王協源教授多年以來對我的指導與照顧，除了讓我在課業上進步良多之外，也 讓我學習到許多待人處事的道理。 感謝各位口試委員撥冗來到交通大學，聽取我們的論文報告並加以指導，有了委員們的建 議，使得這篇論文得以更加完善。 感謝網路與系統實驗室的所有成員，有了你們這些伙伴的陪伴與支持，讓我在研究所兩年之 中帶著愉快的心情學習。 最後，感謝父母對我的栽培，家人對我的照顧，有了他們的鼓勵，我才能夠完成本篇論文。

目

錄

中文摘要 ...- i - 英文摘要 ...- ii - 致謝 ...- iii - 目錄 ...- iv - 表目錄 ...- vi - 圖目錄 ...- vii - 一、 介紹 ...- 1 - 二、 背景 ...- 2 - 2.1. 標準介紹 ... - 2 - 2.1.1. MPEG2系統編碼 ... - 2 - 2.1.2. DVB標準 ... - 2 - 2.1.3. DVB-S以及DVB-S2標準 ... - 3 - 2.1.4. DVB-RCS標準 ... - 4 - 2.2. NCTUns介紹 ... - 6 - 三、 DVB-RCS模擬的設計與實作 ...- 8 - 3.1. 網路拓樸 ... - 8 - 3.1.1. 正向通道上的資料流向 ...- 9 - 3.1.2. 反向通道上的資料流向 ...- 10 - 3.2. 控制訊息 ... - 11 - 3.2.1. 控制表格 ... - 11 - 3.2.2. 用戶端要求訊息 ...- 13 - 3.3. 協定堆設計 ... - 15 - 3.3.1. SAT節點上的模組 ... - 19 - 3.3.2. FD節點上的模組 ... - 19 - 3.3.3. GW節點上的模組... - 20 - 3.3.4. NCC節點上的模組 ... - 20 - 3.3.5. SP節點上的模組 ... - 21 - 3.3.6. RCST節點上的模組 ... - 22 - 3.4. 通道資源分配系統 ... - 25 - 3.4.1. 分配者 ...- 25 - 3.4.2. 要求者 ...- 30 - 四、 DVB-RCS模擬及正確性驗證 ...- 35 - 4.1. 系統測試相關參數 ... - 35 - 4.2. UDP模擬數據與驗證 ... - 36 - 4.2.1. 正向通道 ...- 36 - 4.2.2. 反向通道 ...- 41 -

4.3. FCA行為驗證... - 44 - 4.4. TCP公平性 ... - 46 - 4.4.1. 正向通道 ...- 46 - 4.4.2. 反向通道 ...- 47 - 五、 FCA對TCP效能的影響 ...- 49 - 5.1. TCP公平性 ... - 49 - 5.2. TCP起步 ... - 51 - 5.2.1. FCA-PR-m權數值的影響 ... - 52 - 5.2.2. VBDC_MAX_RATE的影響 ... - 53 - 六、 結論 ...- 57 - 附錄一 ...- 59 -

表

目

錄

表1正向通道及反向通道的比較 ...- 6 - 表2 正向通道相關參數 ...- 35 - 表3 反向通道相關參數 ...- 35 - 表4 FEC編碼前以及編碼後的區塊大小 ...- 38 - 表5 正向通道上，不同實體層模式對應的傳輸率 ...- 40 - 表6 4.2.2節所用到的模擬參數 ...- 43 - 表7 反向通道上，不同CC編碼率對應的傳輸率 ...- 43 - 表8 4.3節所用到的模擬參數 ...- 44 - 表9 4.3節所用到的UDP設定檔 ...- 44 - 表10 RCST節點的時槽需求個數 ...- 45 - 表11 RCST節點分配到的時槽個數...- 45 - 表12 4.4.2節所用到的模擬參數 ...- 47 - 表13 5.1節所用到的模擬參數 ...- 49 -

圖

目

錄

圖1 DVB-RCS系統架構圖 ...- 4 - 圖2正向通道及反向通道的協定堆 ...- 5 - 圖3模組化的網路架構 ...- 6 - 圖4 NCTUns中的模組骨架 ...- 7 - 圖5 DVB-RCS網路架構 ...- 9 - 圖6 正向通道上的資料流向 ...- 10 - 圖7 反向通道上的資料流向 ... - 11 - 圖8 正向通道上的多工/解多工 ...- 12 - 圖9 反向通道上的頻道分割 ...- 12 - 圖10 六個DVB-RCS節點以及對應的協定堆 ...- 16 - 圖11 使用者資料在正向通道上經過的模組...- 17 - 圖12 使用者資料在反向通道上經過的模組 ...- 18 - 圖13 正向通道上的通道編碼 ...- 19 - 圖14 反向通道上的通道編碼 ...- 25 - 圖15 模擬使用的拓樸 ...- 36 - 圖16 正向通道的資料封裝過程 ...- 37 - 圖17 反向通道的資料封裝過程 ...- 41 - 圖18 TCP在正向通道上的公平性 ...- 47 - 圖19 TCP在反向通道上的公平性 ...- 48 - 圖20 FCA-RR機制下的TCP公平性...- 50 - 圖21 FCA-PR-0.8機制下的TCP公平性...- 50 - 圖22 FCA-RR機制下的TCP起步...- 51 - 圖23 FCA-PR-0.8機制下的TCP起步...- 52 - 圖24 FCA-PR-0.2機制下的TCP起步...- 53 - 圖25 FCA-PR-0.95機制下的TCP起步...- 53 - 圖26 模擬結果：FCA-RR機制搭配VBDC_MAX_RATE = 1.15Mbits/sec...- 54 - 圖27 模擬結果：FCA-RR機制搭配VBDC_MAX_RATE = 2.3Mbits/sec...- 54 - 圖28 模擬結果：FCA-RR機制搭配VBDC_MAX_RATE = 4.6Mbits/sec...- 55 - 圖29 模擬結果：FCA-PR-0.8機制搭配VBDC_MAX_RATE = 1.15Mbits/sec...- 55 - 圖30 模擬結果：FCA-PR-0.8機制搭配VBDC_MAX_RATE = 2.3Mbits/sec...- 56 - 圖31 模擬結果：FCA-PR-0.8機制搭配VBDC_MAX_RATE = 4.6Mbits/sec...- 56 -

一、 介紹

DVB-RCS [1] 是一套支援雙向溝通的衛星網路系統，DVB-RCS 以中央控管方式做

資源管理，而FCA 是 DVB-RCS 系統中負責分配資源的機制之一。自從 DVB-RCS 標準

公開以來，許多的期刊論文及博士專題都在討論此標準，但其中鮮少對FCA 機制做探

討。

在DVB-RCS 系統中有許多研究議題，比如服務品質（QoS, Quality of Service）、動

態頻寬機制（BoD, Bandwidth on Demand）、以及網路效能等，研究此系統的研究者通常

開發自己的模擬程式，用來評估提出的方案或驗證自己的分析 [2] [3]。這些模擬程式通 常不是通用的而且也不是公開的；此外，許多模擬程式精確度並不是很高，使得模擬結

果令人質疑。因此，一個公開且高品質的DVB-RCS 網路模擬器是備受渴望的，它對於

想開發、測試、或者改進DVB-RCS 系統的研究者來說具有相當高的價值。

基於上述的動機，我們在交大網路模擬器（NCTUns Network Simulator） [4] 中設計並

實作一個DVB-RCS 網路模擬平台，系統中的機制（比如中央排程系統以及控制訊息交 換等）皆受到嚴謹的實作、測試、以及驗證過程。我們在實作出的模擬平台上設計了許 多模擬範例，在這些範例中觀察以及探討FCA 機制對 TCP 效能的影響。 我們的貢獻主要有三項。首先，我們在通用的NCTUns 模擬器上提供 DVB-RCS 網 路模擬平台，除此之外，我們還在論文中呈現設計以及實作的細節，最後我們呈現FCA 機制對TCP 效能的影響。 接下來的章節，我們在第二章介紹DVB-RCS 網路以及 NCTUns 網路模擬器，在第 三章描述DVB-RCS 網路模擬平台的設計與實作，接著在第四章對模擬平台做驗證，在 第五章探討FCA 機制對 TCP 效能的影響，最後在第六章做總結。

二、 背景

在衛星網路中，DVB-RCS 一直是備受討論的公開標準，在過去的十年中，數百篇 的期刊論文及博士專題都在討論此標準。DVB-RCS 立基於 DVB 標準 [5] 制訂出一套 可支援服務供應商與客戶端之間雙向溝通的系統，我們將在以下章節介紹DVB 以及 DVB-RCS 的背景知識。為了深入探討 DVB-RCS 系統，我們在 NCTUns 網路模擬器上 開發DVB-RCS 系統模擬功能，我們在 2.2 節對 NCTUns 網路模擬器做基本介紹。

2.1. 標準介紹

2.1.1. MPEG2 系統編碼

由於DVB 標準採用 MPEG2 系統編碼 [6] 作為傳輸格式，所以我們在介紹 DVB 標

準前先稍微介紹MPEG2 系統編碼。MPEG-2 是於 1994 年由 MPEG 工作團隊所發佈的

視頻及音頻壓縮的國際標準。而MPEG-2 通常用來為廣播信號提供視頻及音頻編碼，其

應用包括了數位衛星電視、有線電視等。MPEG-2 系統編碼並非是對影音編碼進行標準 化，而是為經過影音編碼的位元流以及其他未經過影音標碼的位元流提供了一種標準格 式。MPEG-2 系統編碼的主要功能是將多條資料串流（整合前的串流稱為「基本串流」） 整合成單一條資料串流，使其適合儲存或傳輸介面。MPEG-2 系統編碼為不同的需求提 供兩組編碼格式：Transport Stream (TS)以及 Program Stream (PS)，TS 主要應用在不可靠

的傳輸媒介，而PS 主要應用在可靠的傳輸媒介上。

DVB 標準採用 MPEG-TS 格式，在 DVB 系統中，資料經由 MPEG2-TS 系統編碼後

形成一個個封包，這些封包稱為MPEG2-TS 封包（MPEG2-TS Packet），而連續的

MPEG2-TS 封包被稱為 MPEG2-TS 串流（MPEG2-TS Steam）。

2.1.2. DVB 標準

DVB 是由歐洲電信標準協會、歐洲電子標準化組織（CENELEC, European Committee for Electrotechnical Standardization）及歐洲廣播聯盟（EBU, European Broadcasting Union） 聯合組成的「聯合專家組」（JTC, Joint Technical Committee）所發起的一系列國際承認 的數位電視廣播標準，這套標準在歐洲使用的相當普及。DVB 提供服務供應商將資料 傳送至客戶端的功能，以下我們將服務供應商至客戶端的傳輸通道稱為正向通道 （Forward Link）。

DVB 標準針對不同的需求提供了以下幾種資料廣播的模式： z 資料管道（Data Piping）

z 資料流（Data Streaming）

z 多協定封裝（MPE, Multi-protocol Encapsulation） z 資料傳送帶（Data Carousels）

資料管道：

資料管道模式提供簡單的、非同步的（Asynchronous）的資料傳送方式。資料

管道模式並沒有定義封裝及切割的動作，所需廣播的資料作為MPEG2-TS 封包的負

載（Payload）直接插入到 MPEG2-TS，如何由 MPEG2-TS 解析出資料是由應用層 所負責。 資料流： 資料流模式定義了一種封裝方式，用以滿足同步（Synchronous）與同步化 （Synchronized）資料串流的需求。同步資料串流適用在收端具有穩定播放速率的 服務類型。為了達到同步資料串需求，送端在送出的封包的標頭（Header）中置入 時脈（Clock）資訊，可讓收端實現校時動作。同步化資料流適用在多個資料流之 間必須達到同步回放（Play Back in Synchronization），比如一個服務可將電影的聲 音以及影像資料分成兩個串流傳送，收端收到兩個串流可藉由標頭中的時脈資訊將 聲音及影像同步回放。

多協定封裝：

多協定封裝提供了在MPEG2-TS 之上支援通訊資料網路協定（Transporting

Data Network Protocol）的一種機制。多協定封裝將通訊資料網路協定的協定資料單 元（PDU, Protocol Data Unit）封裝成一種稱為 MPE section 的封包格式。如果通訊

資料網路協定的協定資料單元大於4080 位元組（Byte），多協定封裝會將通訊資料 網路協定的協定資料單元切割成多個Section。多協定封裝採納 LLC／SNAP 協定來 封裝其他協定的資料，而為了對傳送IP 協定做最佳化，允許在不接受 LLC／SNAP 封裝之下傳遞IP 封包，但在這種封裝模式下，IP 封包的大小必須限制在 4080 位元 組以下。 資料傳送帶： 資料傳送帶提供一套機制讓服務提供者循環式廣播一群資料模組。服務提供者 可從資料傳送帶中及時的更新、添加或刪除內容；而接收端如果想要獲得特定資料 模組中的內容，僅僅只需再等待該模再次被廣播就可以了。 在本論文中，我們將著重於「多協定封裝」的討論。這是因為我們希望能夠觀察IP 網路協定在這樣的系統下所得到的效能，而不是著重於視訊傳輸及音訊傳輸。

2.1.3. DVB-S 以及 DVB-S2 標準

DVB 系統傳輸方式有以下幾種： z 衛星（DVB-S 及 DVB-S2） z 有線電纜（DVB-C）

z 地面無線（DVB-T） z 手持地面無線（DVB-H） Satellite Gateway 1 Feeder 1 Service Provider 2 Network Control Center Κإٻຏሐ Κ֘ٻຏሐ RCST RCST Network 1 Gateway 2 Feeder 2 RCST RCST Network 2 Service Provider 1 圖1 DVB-RCS 系統架構圖 DVB-S 是使用空氣作為傳輸媒介並使用衛星作為轉送器（Transponder）的一套 DVB 系統。在近十年中，DVB-S 已經成為最受喜好的數位電視廣播系統，尤其是在地域廣大 的歐洲。用來取代DVB-S 的新標準，稱為 DVB-S2，已經在 2005 年制訂出。DVB-S2

標準引進了適應編碼調製（ACM, Adaptive Coding and Modulation），使得衛星系統的利 用更為有效率。

2.1.4. DVB-RCS 標準

在介紹完了MPEG-2 及 DVB 後，我們可以發現 DVB 只有支援單向服務，也就是

說資料只透過正向通道經由服務供應商到客戶端。而在這一節我們會引進反向通道 （Return Link）的概念，也就是這節要介紹的 DVB-RCS（DVB-Return Channel via Satellite）標準。 圖1 為 ETSI 的 DVB-RCS 標準中互動式衛星網路的示意圖，我們列出在 DVB-RCS 中幾個重要的節點： z 衛星（SAT, Satellite） z 饋送者（FD, Feeder） z 閘道（GW, Gateway）

z 服務提供商（SP, Service Provider）

z 衛星地面接收站（RCST, Return Channel Satellite Terminal）

DVB-RCS 的網路系統中，所有送給客戶端的封包都是透過正向通道來傳送，反之 由客戶端傳回的封包都是透過反向通道來傳送。一個DVB-RCS 的網路系統是由一個或 多個子網路所組成，每個子網路都有一個FD 來將封包送入正向通道以及一個 GW 用來 將封包送入反向通道，使這個子網路能利用衛星資源。整個DVB-RCS 網路的資源都是 由統一的NCC 集中管理，使此網路中的每一個 RCST 可以分配到適當的網路資源。除 了管理網路資源，NCC 亦負責控管 RCST 進出 DVB-RCS 網路。想要進入 DVB-RCS 網 路的RCST 向 NCC 發出登入請求，NCC 對登入請求有權決定是否允許。為了讓 DVB-RCS 網路可以與Internet 網路互動，NCC 可以將其所擁有的資源下放給服務提供商，如此一 來這些服務提供商就可以利用其原本Internet 網路的資源及 DVB-RCS 網路中的 GW 和 FD 將 DVB-RCS 網路中的封包轉出到 Internet 網路或是將 Internet 網路中的封包轉入到 DVB-RCS 網路。RCST 是一個具有 IP 路由能力的客戶端設備，其後端可連接個人電腦 或一個區域網路。 DVB-RCS 標準對於如何支援 IP 通訊協定有明確的定義。如圖 2 所示，IP 封包在正 向通道的傳送有兩種封裝模式，其中一種是利用多協定封裝及MPEG-2 TS，另一種是利 用ATM／AAL5 協定搭配 MPEG-2 TS，後者是用在新生代網路系統中提供 RCST 之間 直接溝通，在本論文中我們僅討論第一種封裝模式。我們可看到IP 封包在反向通道的 傳送亦有兩種封裝模式，ATM／AAL5 協定或多協定封裝搭配 MPEG-2 TS，在本論文中 我們對反向通道僅探討ATM／AAL5 封裝模式。 MPE MPEG2-TS AAL5 ATM IP 802.3 10 base T DVB-S LAN Forward Link MPE MPEG2-TS AAL5 ATM IP 802.3 10 base T Return-Link PHY LAN Return Link 圖2 正向通道及反向通道的協定堆

表1 列出正向通道及反向通道在實體層（PHY, Physical Layer）所使用的調變（Modulation） 及通道編碼（Channel Coding）、在媒體存取控制層（MAC, Media Access Control Layer） 所使用的存取機制（Multiple Access Scheme）。

正向通道 反向通道 調變模式 QPSK、8PSK、 16APSK、32APSK QPSK Turbo code 通道編碼 BCH code 搭配

LDPC code Convolution code 搭配

Reed-Solomon（RS）code

存取機制 TDM MF-TDMA

表1 正向通道及反向通道的比較

2.2. NCTUns 介紹

NCTUns 網路模擬器是一套具有高精準度以及可擴充性的網路模擬器。NCTUns 使 用新穎的核心重入（Kernel Re-entering）模擬方法，此方法直接使用 UNIX 核心中的 TCP/IP 協定堆來產生模擬結果。同樣的，UNIX 上的應用程式也可以在不經過修改之下， 直接執行在我們的模擬環境之中。 Switch FIFO 802.3 PHY Link FIFO 802.3 PHY Link FIFO 802.3 PHY Link ARP Interface FIFO 802.3 PHY Link ARP Interface Node 1 Switch Node 2 圖3 模組化的網路架構

NCTUns 的模擬引擎使用分散式事件模擬方法（Discrete-event Simulation Method）， 因此，模擬的效能主要與事件個數相關，模擬之中產生越多的事件，則模擬速度就越慢。 NCTUns 採用開放式的系統架構，而且提供模組化的開發平台。圖 3 是模組化平台

中一個網路拓樸範例，此拓樸由三個節點組成，各節點的架構也展現在圖中。圖4 顯示

出一個模組的骨幹，立基於此，研究者可以輕易地開發出他們自己的模組，並將開發出 的模組整合至模擬器。

Module

Upper-layer module Lower-layer module recv() send() sendtarget_ recvtarget_ class NslObject { private: char *name_; u_int32_t nodeID_; u_int32_t portid_; u_int32_t nodeType_; public: MBinder *recvtarget_; MBinder *sendtarget_; virtual inline int int();

virtual inline int recv(ePacket_ *); virtual inline int send(ePacket_ *); ...

};

三、 DVB-RCS 模擬的設計與實作

我們在這一章展現我們在NCTUns 網路模擬器上開發的 DVB-RCS 模擬平台。我們 一開始先展示我們的DVB-RCS 網路的概觀，隨後我們介紹 NCTUns 上為了支援 DVB-RCS 網路而新增的模組，最後我們對 DVB-RCS 網路核心元件「通道資源分配」 做詳細說明。

3.1. 網路拓樸

在DVB-RCS 系統中我們設計了六種節點，如下圖 5。以 OSI 七層協定的角度可將 此六種節區分為三類，分別是： z 第一層節點：SAT 節點、FD 節點和 GW 節點 z 第二層節點：NCC 節點 z 第三層節點：SP 節點以及 RCST 節點 第一層節點主要的工作是提供一個能與衛星溝通的界面，相距遙遠的兩個節點可以 利用這些統一的界面透過衛星來溝通而不需要考慮與發送或接收衛星訊號的方法。 在我們的設計中只有一個節點為第二層節點，即是NCC 節點，它只負責 DVB-RCS 網路中所有的資源分配而不須要瞭解如何與外界的Internet 網路溝通。 第三層節點分別是SP 節點以及 RCST 節點，這兩種節點都有一個共通的工作，即 它們都必須負責DVB-RCS 網路與外界網路之間的溝通，所以這兩種節點上需要有路由 （Routing）的能力，所以皆被設計為第三層的節點。

Satellite RCST 1 RCST 1 Internet Gateway Feeder Service Provider Network Control Center Κإٻຏሐ Κ֘ٻຏሐ RCST N 圖5 DVB-RCS 網路架構

3.1.1. 正向通道上的資料流向

以下我們藉由圖6 展現正向通道上資料的流向。任何要送至 RCST 的資料皆會先被 路由至SP 節點，如果資料的發送者為 RCST 節點，資料必須先穿越反向通道到達 SP 節點。一旦SP 節點收到資料並判斷該資料的接收者位址處於同屬的 DVB-RCS 網路， SP 節點把資料路由至 FD 節點。FD 節點將每筆收到的資料轉發至 SAT 節點，SAT 節點 會將收到的資料廣播到DVB-RCS 網路內各個 RCST 節點，各個 RCST 節點要負責判斷 是否要接收正向通道送來的資料，最後RCST 節點將接收到的資料路由至後端區域網路。

Satellite RCST 1 RCST 1 Internet Gateway Feeder Service Provider Network Control Center Κإٻຏሐ Κ֘ٻຏሐ RCST N ΚإٻຏሐՂऱᇷறੌٻ 圖6 正向通道上的資料流向

3.1.2. 反向通道上的資料流向

圖7 展現反向通道上資料的流向。RCST 節點從後端區域網路接收到欲向外傳送的 資料時，RCST 節點將收到的資料往 SAT 節點傳送。SAT 節點收到來自任一個 RCST 節 點的資料，都會直接向GW 節點轉發，而 GW 節點將 SAT 送來的資料送往 SP 節點。一 旦SP 節點收到資料，SP 視接收者位址決定把資料路由至 Internet 網路端或是將資料導 入正向通道。

Satellite RCST 1 RCST 1 Internet Gateway Feeder Service Provider Network Control Center Κإٻຏሐ Κ֘ٻຏሐ RCST N Κ֘ٻຏሐՂऱᇷறੌٻ 圖7 反向通道上的資料流向

3.2. 控制訊息

3.2.1. 控制表格

為了管理以及控制DVB-RCS 網路系統，SP 節點以及 NCC 節點會透過正向通道廣 播控制資訊到網路中所有RCST 節點，這類控制訊息被稱為「控制表格」（Control Table）。 DVB-RCS 系統中控制表格有非常多的種類，但是有多種的控制表格是為了提供廠商或 使用者能夠更有彈性的管理或使用這個系統，因此在我們的設計之下，只有使用其中最 重要的八種控制表格：PAT、PMT、NIT、INT、SCT、FCT、TCT、以及 TBTP。 以下 我們概略介紹這八種控制表格的作用，控制表格詳細說明請參考 [7] [8]。

圖8 正向通道上的多工/解多工

正向通道上的多工／解多工（Multiplexing/De-multiplexing）

在我們的系統中PAT、PMT、NIT、以及 INT 四種控制表格用來達成正向通道上的

多工／解多工。在第二章有提到DVB-RCS 在正向通道上利用 MPEG2-TS 格式來傳輸資

料，當IP 封包要進入正向通道時，會被封裝成 MPE section 並切割成一或多個 MPEG2-TS

封包。而在我們的系統中，正向通道上送往一個RCST 節點的資料被視為一條基本串流，

所有基本串流會被合併成一條MPEG2-TS 串流以 TDM 方式送上正向通道，為了做到多

工／解多工每一條基本串流被給予一個唯一的辨認碼，稱為PID（Packet Identifier），也

可視為各個RCST 擁有一個 PID 值。SP 節點會定期發送 PAT、PMT、NIT、以及 INT

控制表格，每一個RCST 節點可透過查詢這四種表格找到屬於自己的 PID。以圖 8 為例，

Pa 表示一個送往 RCST A 的 IP 封包；Pb 表示一個送往 RCST B 的 IP 封包。在進入正向

通道前Pa 被切割成 Pa1、Pa2 兩個 MPEG2-TS 封包，每一個封包皆帶有 RCST A 的 PID

值1；而 Pb 被切割成 Pb1、Pb2、Pb3 三個 MPEG2-TS 封包，每一個封包皆帶有 RCST B

的PID 值 2。RCST A 知道自己的 PID 為 1，所以當以上五個封包傳送至 RCST A 時，只

會接收Pa1 以及 Pa2 並組合回 IP 封包「Pa」；相同地，RCST B 接收 Pb1、Pb2、以及 Pb3

並組合回IP 封包「Pb」。 Frequency Time Channel 1 S Y N C S Y N C ... T R F ... T R F S Y N C S Y N C ... T R F ... T R F S Y N C S Y N C ... T R F ... T R F S Y N C S Y N C ... T R F ... T R F S Y N C S Y N C ... T R F ... T R F S Y N C S Y N C ... T R F ... T R F Frame 1 Frame 2 Superframe 1 Channel 2 Channel 3 圖9 反向通道上的頻道分割

反向通道的存取控制 在我們的系統中SCT、FCT、TCT、以及 TBTP 四種控制表格用來達成反向通道的 存取控制，介紹這四種控制表之前，我們先介紹反向通道的存取控制。圖9 說明我們系 統中反向通道架構，反向通道由一個個位於不同頻帶且頻率寬（Frequency Bandwidth） 相同的頻道（Channel）組成，每一個 RCST 節點固定使用一個頻道，而使用相同頻道 的所有RCST 節點共同分享頻道資源。每一個頻道在時間上劃分成一個個相同長度的時 段，稱為超視框（Superframe）。每一個超視框被劃分成長度相同的時段，稱為視框 （Frame），視框是反向通道資源分配的週期，NCC 每間隔一個視框執行一次資源分配。 每一個視框又被劃分成長度相同的時段，稱為時槽（Timeslot），時槽是反向通道資源分 配的基本單位，一個時槽可以傳送一個Burst。我們的系統中實作了兩種 Burst：ATM

traffic Burst 以及 SYNC（Synchronization） Burst。在 2.1.4 節中有提到 IP 封包在反向通

道會被切割並封裝成ATM 封包，而 ATM traffic Burst 便是用來傳遞 ATM 封包，也就是

說ATM traffic Burst 傳遞使用者資料。SYNC Burst 的主要用途是用來維持同步以及讓

RCST 節點回傳控制訊息，為了簡化設計，我們在目前系統沒有模擬同步程序而僅模擬

同步所需的額外負載（Overhead）。為了讓RCST 節點可傳遞要求訊息（Request Message）

至NCC 節點，DVB-RCS 標準制訂了四種傳遞方法，我們實作了其中一種，也就是將

RCST 的要求訊息裝載在 SYNC Burst。在以下章節我們把傳送 ATM traffic Burst 的時槽 稱為「資料時槽」（TRF Timeslot）；而把傳送SYNC Burst 的時槽稱為「要求時槽」（Request Timeslot）。 為了讓網路中所有RCST 節點知道如何利用反向通道，NCC 節點定期發送 SCT、 FCT、TCT、以及 TBTP 四種控制表格。SCT 控制表格中主要描述各個超視框開始時間 以及內部各個視框的相對位置；FCT 控制表格中主要描述視框內部各個時槽的相對位 置；TCT 控制表格描述時槽的參數，比如符號傳輸率（Symbol Rate）、編碼率（Coding Rate）、負載類型等。藉由查詢 SCT、FCT、以及 TCT 三張控制表格，RCST 節點可建 出如圖9 所表示的反向通道架構，而時槽的分配則由 TBTP 控制表格敘述，每當 NCC 節點完成反向通道資源分配，NCC 節點將 TBTP 向所有 RCST 節點廣播，各個 RCST 節點可藉由查詢TBTP 控制表格得知接下來的視框中有哪些時槽是分配給自己。

3.2.2. 用戶端要求訊息

DVB-RCS 標準將反向通道頻寬分配方式分成以下幾種： z CRA（Continuous Rate Assignment）

z RBDC（Rate Based Dynamic Capacity）

z VBDC／AVBDC（Volume Based Dynamic Capacity／Absolute Volume Based Dynamic Capacity）

CRA： CRA 是一種用戶端與系統服務者簽約書上協定的一種頻寬分配，一旦 RCST 登入 DVB-RCS 網路，CRA 就會持續提供固定大小的頻寬（Bandwidth）給該 RCST，這種資 源是自動分配，不需要RCST 節點發出要求訊息。即使 RCST 節點並沒有資料要傳送， CRA 分配方式依舊會將頻寬分配出去，所以這種分配可能造成反向通道的頻寬浪費。 CRA 分配通常用於需要固定而且受保證的頻寬、最小延遲（Delay）、以及最小延遲差異

（Delay Jitter）的資料流（Traffic Flow）。

RBDC： RBDC 是一種動態的頻寬分配方式，RCST 節點週期性量測使用者送出資料的速率 並發出要求訊息（此類要求稱為「RBDC 要求」）到 NCC 節點，送到 NCC 節點的 RBDC 要求會維持一段有效期，直到被新的RBDC 要求覆蓋或是期限終止。 VBDC／AVBDC： VBDC 與 RBDC 一樣是一種動態的頻寬分配方式，RCST 節點週期性量測緩衝空間 內的資料量，並發出要求訊息（此類要求稱為「VBDC 要求」）到 NCC 節點，VBDC 要 求是累加性的，也就是說，RCST 節點發出的 VBDC 要求會加到之前發出的要求。VBDC 要求不受到保證，若NCC 節點在做排程時沒有足夠的頻寬可滿足某一個 RCST 節點的 VBDC 要求，NCC 會將不足的數量記錄下來，我們把 NCC 節點為各個 RCST 節點記錄 的不足數量稱為「VBDC 積欠量」。AVBDC 與 VBDC 相似，唯一差別在於 AVBDC 要

求不具有累加性，每一個AVBDC 要求覆蓋掉之前發出的 VBDC／AVBDC 要求，AVBDC

通常用在RCST 節點發現所發出的 VBDC 要求遺失時。 FCA： NCC 節點完成上述幾種分配方式之後如果有剩餘的頻寬，依據系統服務者制訂的 政策，NCC 節點可決定是否要將這些頻寬分配出去，將剩餘頻寬分配出去就叫做 FCA。 這些頻寬如果沒有分配出去就會造成閒置，而RCST 節點利用 FCA 分配的頻寬可以減 少等待的時間，所以FCA 分配的目的是提高反向通道使用率（Utilization）以及減少延 遲。FCA 與 CRA 一樣是自動分配，不需要 RCST 節點發出要求訊息。 上述幾種頻寬分配中，RBDC、VBDC、以及 AVBDC 都需要 RCST 節點向 NCC 節 點發出要求訊息，RCST 節點發出要求訊息直到收到回應的這段期間稱為「要求延遲」。 如3.2.1 節提到的，每一個 RCST 節點會在分配給自己的要求時槽內，將這些要求裝載 在SYNC Burst 送出。 以下提出在我們設計中，RCST 節點幾個與頻寬分配相關的參數：

z CRA_MAX_RATE：RCST 節點的 CRA 額度，指的是 CRA 分配中可拿到的固定頻 寬。

z RBDC_MAX_RATE：RCST 節點的 RBDC 額度，指的是 RBDC 分配中可拿到的最 大頻寬。在我們設計中，RBDC 要求是被保證的，也就是說，RCST 節點的 RBDC

要求只要低於RBDC_MAX_RATE，所發出的要求一定被滿足。 z RBDC_TIMEOUT：此參數代表的是 RBDC 要求的有效期，可以是 1 至 15 個超視 框。 z VBDC_MAX_RATE：此參數代表的是 RCST 節點可拿到的頻寬上限。VBDC 要求 不受保證，所以即使RCST 節點發出的 VBDC 要求低於 VBDC_MAX_RATE，所發 出的要求也不一定被滿足。

3.3. 協定堆設計

模組化有利於讓研究者在一個系統中開發他們感興趣的主題。在NCTUns 網路模擬 器中，我們以模組方式開發及模擬各式各樣的協定，比如我們有ARP 模組、AODV 模 組等。因此，使用NCTUns 的研究者可以修改或置換他們感興趣的模組，做為自己的研 究平台。 為了支援DVB-RCS 網路模擬，我們在 NCTUns 上開發了一些新的模組。圖 10 顯 示六個新開發的節點以及個別對應的模組，圖中深色的是專為DVB-RCS 網路系統新增 的模組，其餘的是原有的且經過長期嚴格測試的模組。圖11 以及 12 個別顯示使用者資 料在正向通道以及反向通道上所流經的模組。以下子章節中，我們針對新開發節點上各 個模組做說明。

SP NCC Interface SP_CTL MPE SECTION MPEG2_TS RCS_MAC_ SP RCS_ATM_ SP RCST Interface RCST_CTL MPEG2_TS RCS_MAC_ RCST RCS_ATM_ RCST NCC_CTL SECTION MPEG2_TS RCS_MAC_ NCC DVB_S2_R CST Feeder DVB_S2_Feeder SAT DVB_S2_SAT GW DVB_RCS_GW DVB_RCS_ RCST Interface ARP FIFO MAC8023 PHY LAN Interface ARP FIFO MAC8023 PHY Internet Κ֘ٻຏሐ Κإٻຏሐ MPE SECTION 圖10 六個 DVB-RCS 節點以及對應的協定堆

SP NCC Interface SP_CTL MPE SECTION MPEG2_TS RCS_MAC_ SP RCS_ATM_ SP RCST Interface RCST_CTL MPEG2_TS RCS_MAC_ RCST RCS_ATM_ RCST NCC_CTL SECTION MPEG2_TS RCS_MAC_ NCC DVB_S2_R CST Feeder DVB_S2_Feeder SAT DVB_S2_SAT GW DVB_RCS_GW DVB_RCS_ RCST Interface ARP FIFO MAC8023 PHY LAN Interface ARP FIFO MAC8023 PHY Internet Κ֘ٻຏሐ Κإٻຏሐ MPE SECTION 圖11 使用者資料在正向通道上經過的模組

SP NCC Interface SP_CTL MPE SECTION MPEG2_TS RCS_MAC_ SP RCS_ATM_ SP RCST Interface RCST_CTL MPEG2_TS RCS_MAC_ RCST RCS_ATM_ RCST NCC_CTL SECTION MPEG2_TS RCS_MAC_ NCC DVB_S2_R CST Feeder DVB_S2_Feeder SAT DVB_S2_SAT GW DVB_RCS_GW DVB_RCS_ RCST Interface ARP FIFO MAC8023 PHY LAN Interface ARP FIFO MAC8023 PHY Internet Κ֘ٻຏሐ Κإٻຏሐ MPE SECTION 圖12 使用者資料在反向通道上經過的模組

BB ৞ᇘ໢ ց BB ᧓႖ᕴ Constellation Mapper ᓳ᧢ᕴ ٌᙑᕴ BCH ᒳᒘᕴ LDPC ᒳᒘᕴ FEC ᒳᒘᕴ MPEG2-TS ৞ץ BBFRAME FECFRAME PL ৞ᇘ໢ ց PL ᧓႖ᕴ PLFRAME ᓡਣຏሐ 圖13 正向通道上的通道編碼

3.3.1. SAT 節點上的模組

DVB_S2_SAT 模組 在這一版本的設計上，衛星是一個單純的中繼器（Repeater），所以當DVB_S2_SAT 模組收到任何下層的資料，對資料不做任何改變，依據資料類型將資料轉送到GW 節點 或網路中所有RCST 節點。 除了轉送資料，DVB_S2_SAT 模組還負責模擬訊號從衛星到達地面所經過的傳輸延

遲（Propagation Delay），傳輸延遲的計算為衛星與地面距離除上光速。所以DVB_S2_SAT

模組收到資料時會經過延遲後才做轉送動作。

3.3.2. FD 節點上的模組

DVB_S2_Feeder 模組

圖13 顯示 DVB-RCS 標準中描述的正向通道實體層 [9]，DVB_S2_Feeder 模組負責

模擬正向通道實體層行為，以下我們依序描述此模組的行為。

一旦從MPEG2_TS 模組收到 MPEG2-TS 封包，DVB_S2_Feeder 模組中的 BB（Base Band）封裝單元先將 MPEG2-TS 封包封裝成稱為 BBFRAME 的格式。首先 BB 封裝單

元會對每一個MPEG2-TS 封包做 CRC-8 編碼，MPEG2-TS 標頭的第一個位元組稱為同 步位元組（Synchronization Byte），這個位元組在 DVB-RCS 正向通道中沒有作用，所以 BB 封裝單元將計算出的 CRC-8 Code 取代這個位元組，最後將 CRC-8 編碼後的封包放 入到一個緩衝區暫放。DVB_S2_Feeder 模組每隔一段時間會做傳送動作，此時 BB 封裝 單元從上述緩衝區擷取一段資料並加上一個標頭，產生一個BBFRAME 後傳遞給 BB 攪 亂器（Scrambler）。 收到BBFRAME，BB 攪亂器將 BBFRAME 打散，以避免連串的零或一。經過攪亂

Density Parity Check）編碼器，形成稱為 FECFRAME 的資料區塊。接下來交錯器 （Interleaver）把 FECFRAME 內的資料交錯擺置以減少連串錯誤帶來的影響。由於軟體

無法模擬信號層級的行為，所以從Constellation Mapper 之後的單元都沒有實作，我們只

計算調變出來的符號（Symbol）量並模擬其所需花費的傳輸時間。

最後DVB_S2_Feeder 模組將產生出的 FECFRAME 轉送至 DVB_S2_SAT 模組，為

了模擬訊號從FD 節點到達 SAT 節點所需的傳輸延遲，此轉送會被延遲執行。

3.3.3. GW 節點上的模組

DVB_RCS_GW 模組 DVB_RCS_GW 模組把在反向通道收到由衛星送下來的封包做通道解編碼（Channel Decoding）以及反亂碼（De-randomization），經過這些處理後會還原成一個 Burst，之後 就會將其送到對應的NCC 節點以及 SP 節點。在我們的系統設計中，我們把 GW、NCC、 SP、以及 FD 四個節點視為緊密相連的設備，所以忽略彼此之間的傳輸延遲。因此 DVB_RCS_GW 模組一旦解出 Burst 就立刻傳遞給 NCC 節點以及 SP 節點，不模擬傳輸 延遲。

3.3.4. NCC 節點上的模組

NCC_CTL 模組 NCC 節點主要的功能是管理整個 DVB-RCS 網路中所有的資源，NCC_CTL 模組便 是負責這個任務的模組。NCC_CTL 下掛有兩串不同協定堆，正向通道上的協定堆是用 來傳送控制表格，而反向通道上的是用來接收RCST 節點送來的要求訊息。 在3.2.1 節中有提到，為了讓網路中所有 RCST 節點知道如何利用反向通道，NCC 會定期廣播SCT、FCT、TCT、以及 TBTP 四種控制表格。因此，NCC_CTL 模組負責 維護SCT、FCT、以及 TCT 三種控制表格，並設置一個計時器，每隔一個超視框就廣 播這三種控制表格。除此之外，NCC_CTL 模組中含有一個單元稱為分配者（Allocator）， 分配者依據所有RCST 節點的要求，分配反向通道的頻寬，並將分配結果透過 TBTP 告 知所有RCST 節點。分配者是 DVB-RCS 系統的核心，我們在 3.4.1 節中將有詳細說明。 SECTION 模組 由於NCC_CTL 模組所發送的控制表格的大小不一，可能會超過 DVB 規格中所定 義的最大section 長度，所以 NCC 節點上的 SECTION 模組負責將控制表格包裝成一或 多個section。

MPEG2_TS 模組

在正向通道上，無論是控制表格或是使用者資料都將是以MPEG2-TS 封包格式傳

送。控制表格／使用者資料在SECTION 模組／MPE 模組被封裝成 section 格式，而依

照 [6] 中所定義的 MPEG2-TS 封包格式封裝 section 即是 MPEG2_TS 模組的功能。封裝

完成後就會將產生的MPEG2-TS 封包送到 FD 節點。 RCS_MAC_NCC 模組 由於反向通道是使用MF-TDMA 的存取機制，RCS_MAC_NCC 模組要能模擬同時 接收多組頻道訊號的行為，因此每當收到從GW 節點送過來的 Burst 時，這個模組設定 此Burst 所用的頻道的計時器來計數接收時間。為了模擬碰撞的情況，在接收時間結束 之前若是又收到來自相同頻道的Burst，則該頻道上重疊的 Burst 就會被破壞，必須將其 丟棄；反之在接收時間結束之前都沒有收到同頻道的訊號，則在接收時間結束時就會將 這個Burst 轉換回 ATM 封包送給 RCS_ATM 模組。

3.3.5. SP 節點上的模組

SP_CTL 模組 SP 節點主要的功能是讓 DVB-RCS 網路中的 RCST 節點能正確地送收 IP 封包， SP_CTL 模組便是負責這個任務的模組。SP_CTL 下掛有兩串不同協定堆，正向通道上 的協定堆是用來傳送控制表格以及IP 封包到 RCST 節點，而反向通道上的是用來接收 RCST 節點送來的 IP 封包。 正向通道方面，在3.2.1 節中有提到為了達到正向通道上的多工／解多工，SP 節點 會定期發送PAT、PMT、NIT、以及 INT 控制表格。所以我們在 SP_CTL 模組中維護這 四種控制表格，並設置一個計時器，每隔一個超視框就廣播這些控制表格。由於RCST 節點是藉由MPEG2-TS 封包上的 PID 值來判斷是否要接收封包，所以 SP_CTL 模組在 將IP 封包送往下層之前，要先知道目的端（RCST 節點）的 PID 值，並指定送出的 MPEG2-TS 封包上的 PID 值。首先，SP_CTL 模組由設定檔取得每一個 RCST 節點以及 RCST 節點後端子網路的 IP 位址，所以當 SP_CTL 模組由 Interface 模組收到一個 IP 封 包時，它能由該封包的目的位址查表決定這個封包應該要送到那一個RCST 節點，以及 這個IP 封包在封裝成 MPEG2-TS 封包後的 PID 值。接下來，SP_CTL 便把 IP 封包連同

PID 值往 MPE 模組傳遞，MPE 模組完成 MPE 封裝後把 MPE section 連同收到的 PID 值

傳遞給MPEG2_TS 模組，MPEG2_TS 模組在封裝 MPEG2_TS 封包的時候便直接將此

PID 值填入標頭中的 PID 欄位，最後 MPEG2_TS 封包經由正向通道到達 RCST 節點時， RCST 節點就可判斷是否要接收封包。

反向通道方面，當SP_CTL 模組在反向通道這串協定堆收到一個 IP 封包時，它會

轉送這個封包，若是這個封包的目的位址為Internet 網路中的某一台 Host，則這個封包 就會被轉到SP 節點中對應到 Internet 網路的那串協定堆；若是目的位址為 DVB-RCS 網 路中某RCST 節點後端的 Host，則這個封包就會被轉到 SP 節點中對應到 DVB-RCS 網 路的那串協定堆，之後就會依照上一段所敘述的正向通道機制把這個封包送到特定的 RCST 節點。 MPE 模組

SP 節點上的 MPE 模組負責將 IP 封包封裝成 MPE section，為了簡化設計，我們只

實作2.1.2 中描述的最佳化封裝模式。 SECTION 模組 略。與NCC 節點中的 SECTION 模組相同。 MPEG2_TS 模組 略。與NCC 節點中的 MPEG2_TS 模組相同。 RCS_ATM_SP 模組

RCS_ATM_SP 模組負責將 ATM 封包組合成 IP 封包。每當從 RCS_MAC_SP 模組收

到一個ATM 封包，RCS_ATM_SP 模組先對收到的封包做 CRC 檢查以確認封包沒有錯 誤。接下來RCS_ATM_SP 模組檢查 ATM 標頭中的「最後封包標記」，如果該標記顯示 這封包是一串ATM 封包的最後一個，RCS_ATM_SP 模組將這封包連同之前收到的封包 集合成一個AAL5 封包，並對此 AAL5 封包做 CRC 檢查。CRC 檢查通過之後， RCS_ATM_SP 模組從 AAL5 的負載欄位取出 IP 封包，並將 IP 封包送至 SP_CTL 模組。 RCS_MAC_SP 模組 略。與NCC 節點中的 RCS_MAC_NCC 模組相同。

3.3.6. RCST 節點上的模組

RCST_CTL 模組 RCST_CTL 模組之下掛有兩串不同的協定堆，一串是用來接收正向通道中的控制表 格或是IP 封包，另一串用來透過反向通道發送 IP 封包。此模組的工作主要是：管理 RCST 節點收到的控制表格、將送往反向通道上的資料流做分類、以及發出要求訊息。 反向通道的傳輸資源是由NCC 節點排程，並利用 TBTP 控制表格將時槽分配表通

知各個RCST 節點。收到 TBTP 控制表格後，RCST_CTL 模組從表中取出分配到的時槽 的編號，接著拿編號查詢SCT、FCT、TCT 三張表格，取出時槽參數（比如開始時間、 頻率、負載種類等），RCST_CTL 模組會紀錄這些參數作為往後視框中傳送 Burst 的依 據，直到時槽過期才將對應時槽參數清除。 在反向通道上，我們以「來源IP 位址」、「目的 IP 位址」、「來源埠口（Port）」、「目 的埠口」、以及協定種類（UDP 或 TCP）五個值綜合起來作為「資料流辨識碼」，為了

做資源管理，一個資料流會對應到一個RCS_MAC_RCST 模組中的 ATM 佇列（Queue）。

當RCST_CTL 模組從 Interface 收到一個 IP 封包時，它會拿 IP 封包上的資料流辨識碼到

設定檔取得對應的佇列辨識碼，並將此IP 封包連同查出的辨識碼一併送往

RCS_ATM_RCST 模組，RCS_ATM_RCST 模組將 IP 封包切割成 ATM 封包之後，將 ATM

封包連同收到的佇列辨識碼一併送往RCS_MAC_RCST 模組，RCS_MAC_RCST 模組便 依據佇列辨識碼來將ATM 封包導入到指定的 ATM 佇列。 RCST_CTL 模組負責發出頻寬要求。每當分配到一個要求時槽，此模組會向 RCS_MAC_RCST 模組詢問頻寬需求量，並依照標準所訂的格式產生要求訊息，在要求 時槽開始時間將要求訊息透過下層模組送出。 MPE 模組

RCST 節點上的 MPE 模組與 SP 節點上的 MPE 模組對稱，它負責將 IP 封包從 MPE section 中取出。

SECTION 模組

RCST 模組中的 SECTION 模組負責將 section 組回控制表格。SECTION 模組有緩衝

空間用來暫存那些還無法組成控制表格的section，每當從 MPEG2_TS 模組收到一個

section，就會檢查是否已經可組合一張控制表格，當一個控制表格成功的被組合回來 時，SECTION 模組就會把這個控制表格送往 MPE 模組。

MPEG2_TS 模組

RCST 節點中的 MPEG2_TS 模組負責將 MPEG2-TS 封包組合成 section。在 RCST

節點中的MPEG2_TS 模組，每一個 PID 都有一個對應的緩衝空間，其用途是暫存那些

還無法組成一個section 的 MPEG2-TS 封包，在 MPEG2_TS 模組收到一個 MPEG2-TS

封包時，由該封包的標頭取出PID，嘗試將這個封包與那些在緩衝空間中，有相同 PID

的MPEG2-TS 封包組合成一個 section，當一個 section 成功的組合回來時，MPEG2_TS

模組就會把這個section 送往 SECTION 模組。

RCS_ATM_RCST 模組

包，RCS_ATM_RCST 模組先將 IP 封包後面加上一個 AAL5 標尾（Trailer），其中包含 CRC32 的訊息，之後把這段資料填充成 48 位元組的倍數，並以 48 位元組為一個單位

切割這個封包。在切割完成後，依據ATM 規格中的定義為每一個 48 位元組長的封包

加上5 位元組的 ATM 標頭。在 ATM 標頭中有一個位元稱作「最後封包標記」是用來

表示該ATM 封包是否為這一串 ATM 封包的最後一個，ATM 標頭中也包含 CRC8 的訊

息。

由於要求訊息並不是以ATM 封包方式傳遞，所以從 RCST_CTL 模組收到要求訊息

時，RCS_ATM_RCST 模組不作任何處理，直接將要求訊息傳遞給下層。

RCS_MAC_RCST 模組

RCS_MAC_RCST 模組的主要工作是把一個或多個 ATM 封包封裝成一個 ATM traffic Burst，並在 RCST_CTL 所指定的時槽開始時間把 TRF Burst 送出。反向通道以 ATM 格式來傳送 IP 封包，每一個送往反向通道的 IP 封包都會在 RCS_ATM_RCST 模組

被切割並封裝成ATM 封包，隨後 ATM 封包被送往 RCS_MAC_RCST 模組，ATM 封包

進入到RCS_MAC_RCST 模組並不是立刻被送出，而是被暫放在佇列中等待可利用的時 槽。為了管理頻寬資源以及提供資料流不同的服務品質，我們設計了四種佇列來放置 ATM 封包，分別是「RT」、「VR-RT」、「VR-JT」、以及「JT」，每一個 RCST 節點可以有 一或多個佇列，而RCST 節點送往反向通道的各條資料流會被導入其對應的佇列。 RT 佇列擁有一個參數「CRA_MAX」，此參數代表一個固定大小且受保證的頻寬 （RCST 節點中所有 RT 佇列的 CRA_MAX 值的總和不能超過 RCST 節點的 CRA_MAX_RATE），RT 佇列通常用在需要固定頻寬、最小延遲、以及最小延遲差異的 資料流。VR-RT 佇列同時擁有 CRA 以及 RBDC 額度，VR-RT 與 RT 佇列同樣擁有參數 「CRA_MAX」，不同的是，對VR-RT 佇列來說，CRA_MAX 表示一個基本頻寬，VR-RT 佇列可以藉由發出RBDC 要求以取得額外的頻寬，參數「RBDC_MAX」表示此佇列可 得的最大額外頻寬，VR-RT 佇列通常用在變速率的資料流。VR-JT 佇列與 VR-RT 佇列 相似，不同的地方在於VR-JT 佇列沒有 CRA 額度，所以通常資料流在 VR-JT 佇列遭遇 的延遲會比在VR-RT 佇列還高。JT 佇列不擁有任何受保證的頻寬額度，JT 佇列必須透 過發出VBDC 要求來取得頻寬，由於我們的 BoD 機制無法保證滿足 VBDC 要求，所以 JT 佇列通常服務可容忍較高延遲差異的資料流。 在我們的設計中有一個稱為「要求者（Requestor）」的函式單元負責計算 RCS_MAC_RCST 模組中各個佇列的頻寬需求，並負責將 RCST 節點取得的時槽分配到 各個佇列，要求者是DVB-RCS 系統的核心，我們在 3.4.2 節中將有詳細說明。 DVB_S2_RCST 模組 DVB_S2_RCST 模組與 DVB_S2_Feeder 模組相對應，流程與 DVB_S2_Feeder 模組 相反，請參考3.3.2 節。需注意的是，DVB_S2_RCST 模組不負責模擬傳輸延遲而是負

向上層模組傳送的動作。

DVB_RCS_RCST 模組

圖14 顯示 DVB-RCS 的反向通道實體層。其中的 Burst 封裝單元由 RCS_MAC_RCST

模組負責。與正向通道實體層一樣，我們沒有模擬Constellation Mapper 以及調變器，只

計算調變出來的符號量並模擬所需花費的傳輸時間。DVB_RCS_RCST 模組負責其餘的 亂碼器（Randomizer）以及 FEC 編碼器。此模組支援具彈性的 FEC 編碼系統，它的 FEC

編碼系統使用里德所羅門碼（RS code）加上迴旋碼（Convolution Code），編碼率可支援 1/2、2/3、3/4、5/6、7/8。此模組還負責模擬傳輸延遲，編碼後產生的資料區塊會被送 至DVB_S2_SAT 模組，為了模擬訊號從 RCST 節點到達 SAT 節點所需的傳輸延遲，此 轉送會被延遲執行。 Burst ৞ᇘ໢ց ႖ᒘᕴ Constellation Mapper ᓳ᧢ᕴ RS ᒳᒘᕴ CC ᒳᒘᕴ FEC ᒳᒘᕴ ATM ৞ץ Burst ᓡਣຏሐ 圖14 反向通道上的通道編碼

3.4. 通道資源分配系統

3.4.1. 分配者

我們在這一節介紹NCC_CTL 模組中一個稱為分配者的函式單元，分配者的工作是 分配反向通道資源。分配者將所有RCST 節點送來的要求訊息記錄在一個陣列，我們稱 之為「要求陣列」。在每一個視框開始時間，分配者呼叫內部函式「frame_scheduing( )」 來依據要求陣列做資源分配，並產生描述分配結果的TBTP 控制表格。此函式的實作與 使用的分配機制相關，模擬器使用者可以在檔案「timeslot_scheduler.cc」內重新定義自 己的分配機制。以下我們用偽碼（Pseudo Code）形式來介紹我們的分配者設計。

在frame_scheduing( )中，「request timeslot allocation」分配要求時槽；而「CRA allocation」、「RBDC allocation」、「VBDC/AVBDC allocation」、以及「FCA allocation」分

RCST 節點，然後換下一個 RCST 節點，直到所有要求時槽都分配完或者每一個 RCST 節點都有一個要求時槽。在我們的設計中，CRA 以及 RBDC 兩種額度都是受到保證， 所以CRA 以及 RBDC 分配要放置在其他資料時槽分配方式前面；而 FCA 是負責分配剩 餘的時槽，所以放在最後面。當時槽分配完畢之後，分配者就會按照分配表產生TBTP 控制表格，並發送給每一個RCST 節點。 分配者中使用的資料結構：

A[ ] //A[i] stores the total number of TRF timeslot allocated to RCST i. RV[ ] //RV[i] stores the value of previous RBDC request from RCST i. VV[ ] //VV[i] stores the backlog of VBDC/AVBDC request from RCST i. CRA[ ] //CRA[i] stores the number of TRF timeslot to meet the

//CRA_MAX_RATE of RCST i.

RMAX[ ] //RMAX[i] stores the number of TRF timeslot to meet the //RBDC_MAX_RATE of RCST i.

VMAX[ ] //VMAX[i] stores the number of TRF timeslot to meet the //VBDC_MAX_RATE of RCST i.

history[ ] //history[i] stores the history of VBDC requests from RCST i.

frame_scheduling()

1: for each return link channel Sp do

2: //assume all of the RCSTs on Sp are RCST 1, RCST 2, ..., RCST n. 3: reset A[ ] to be a zero vector

4: do request timeslot allocation for Sp 5: do CRA allocation for Sp

6: do RBDC allocation for Sp

7: do VBDC/AVBDC allocation for Sp 8: if FCA scheme is turned on then 9: do FCA allocation for Sp

10: end if 11: end for

3.4.1.1. CRA 分配

下面是CRA 分配的偽碼。CRA 分配中做的事相當簡單，它分配時槽給頻道上擁有 CRA 配額的 RCST 節點。

3.4.1.2. RBDC 分配

下面是RBDC 分配的偽碼。由於 RBDC 要求具有延續性，所以 RBDC 分配會先將 收集到的每一個RBDC 要求記錄到 RV 陣列，來自相同 RCST 節點的前一次 RBDC 要求 會被覆蓋掉。接下來是依據RV 陣列中尚未過期的 RBDC 要求分配時槽給 RCST 節點。 由於各個RCST 節點在 RBDC 分配中可拿到的頻寬有個上限值，所以在第七行中，分配 者對分配出去的時槽量做限制。

3.4.1.3. VBDC 分配

下面是VBDC 分配的偽碼。由於 VBDC 要求具有累加性，所以 VBDC 分配一開始

CRA allocation procedure

1: for i = 1 to n do 2: A[i] Å A[i] + CRA[i] 3: end for

RBDC allocation procedure

1: for each RBDC request Ri do

2: //assume Ri is submitted from RCST(Ri) and of value value(Ri). 3: RV[RCST(Ri)] Å value(Ri)

4: end for

5: for i = 1 to n do

6: if RV[i] has not expired yet then 7: A[i] Å A[i] + min(RV[i] ,RMAX[i]) 8: end if

先將每一個收到的VBDC 要求累加到 VBDC 積欠量上；而 AVBDC 要求具有覆蓋性， 所以VBDC 分配會把每一個收到的 AVBDC 要求直接覆蓋掉原先的 VBDC 積欠量。接 下來VBDC 分配以 Round-Robin 方式做時槽分配，輪到的 RCST 節點如果尚有 VBDC 積欠量，而且該RCST 節點分配到的個數還沒到達上限值的話，就會分配一個時槽給它， 接著換下一個RCST 節點，直到所有的時槽都分配出去或者每一個 RCST 節點的 VBDC 積欠量都清空。

3.4.1.4. FCA 分配

FCA 分配的探討是我們這篇論文的主題，為了觀察 FCA 分配對網路效能的影響，

我們設計實作兩種FCA 機制：FCA-RR 以及 FCA-PR-m。FCA-RR 機制是把剩餘時槽做

平均分配；而FCA-PR-m 是把剩餘時槽依照每一個 RCST 節點發出的 VBDC 要求量做

比例性分配。

VBDC/AVBDC allocation procedure

1: declare AV[ ] //AV[i] records the number of TRF timeslot allocated to //RCST i in the VBDC/AVBDC allocation.

2: for each VBDC request Vi do

3: //assume Vi was submitted from RCST(Vi) and of value value(Vi). 4: VV[RCST(Vi)] ÅVV[RCST(Vi)] + value(Vi)

5: end for

6: for all AVBDC request Vi do

7: //assume Vi was submitted from RCST(Vi) and of value value(Vi). 8: VV[RCST(Vi)] Å value(Vi)

9: end for

10: while there exists spare TRF timeslots and VV[ ] is not a zero vector do 11: for i = 1 to n do

12: if there exists no spare TRF timeslots then 13: stop VBDC/AVBDC allocation

14: end if

15: if VV[i] ≠ 0 and AV[i] ≤ VMAX[i] then 16: AV[i] Å AV[i] + 1 17: A[i] Å A[i] + 1 18: VV[i] Å VV[i] − 1 19: end if 20: end for 21: end while

FCA-RR 分配機制

下面是FCA-RR 分配的偽碼。FCA-RR 分配以 Round-Robin 方式做時槽分配，一次

分配一個時槽給一個RCST 節點，然後換下一個 RCST 節點。在我們的設計中，FCA 分 配的時槽是給RCST 節點中的 JT 佇列使用，而 JT 是以 VBDC 方式來要求頻寬，所以當 FCA 分配時槽給某個 RCST 節點時，應該減低該 RCST 節點的 VBDC 積欠量。 FCA-PR-m 分配機制 FCA-PR-m 依據以往各個 RCST 節點發出的 VBDC 要求量來分配時槽，為此，分配 者使用一個歷史函式（History Function）來紀錄各個 RCST 節點的 VBDC 要求量，下面 這段偽碼被安插在VBDC/AVBDC allocation 之中來實現 VBDC 歷史紀錄，其中 m 值是 0 至 1 之間的權數。 下面是FCA-PR-m 分配的偽碼。首先分配者先將所有 RCST 節點的 VBDC 歷史值 做加總，接著依照RCST 節點的 VBDC 歷史值佔總值的比例做時槽分配，依照比例分配 後如果還有剩餘的時槽，以Round-Robin 方式分配剩餘時槽。與 FCA-RR 分配相同，當 FCA 分配時槽給某個 RCST 節點時，應該減低該 RCST 節點的 VBDC 積欠量。 1: for each RCST i do

2: history[i] = history[i] * m + VBDC_REQ_VALUE(i) * (1-m) 3: endfor

FCA allocation procedure – RR

1: while there exists spare TRF timeslot do 2: for i = 1 to n do

3: if there exists no spare TRF timeslot then 4: stop FCA allocation

5: end if 6: A[i] Å A[i] + 1 7: if VV[i] ≠ 0 then 8: VV[i] Å VV[i] − 1 9: end if 10: end for 11: end while

3.4.2. 要求者

我們在這一節介紹RCST_CTL 模組中一個稱為要求者（Requestor）的函式單元， 要求者的工作是向RCS_MAC_RCST 模組內每一個佇列的代理者（Agent）詢問頻寬需 求，並將所有需求整理後產生要求訊息。每一個視框計算一次頻寬需求，而每一個佇列 的需求量會被個別紀錄，作為將來分配時槽的依據。要求者還有一項工作是負責將RCST 節點得到的時槽分配到各個佇列，時槽分配必須參考先前記錄的佇列需求量來執行。在 每一個視框開始時間，要求者呼叫內部函式「grant_demand_and_compute_demand( )」來 執行上述工作。以下我們用偽碼形式來介紹我們的要求者設計。 在以下程式碼中，我們以next_demand[i]表示佇列 Qi 的需求量，每當有 ATM 封包 進入佇列Qi 時，next_demand[i]的值會增加。我們以 f 表示將開始的視框的編號、並以 d 表示分配延遲。grant_demand_and_compute_demand( )中，要求者先為 RT 以及 VR-RT 佇列分配CRA 配額，接著為 VR-RT 以及 VR-JT 分配 RBDC 配額，最後才是將剩餘的 時槽分配給JT 佇列。

FCA allocation procedure – PR-m

1: //assume there are u spare TRF timeslots. 2: sum_history Å sum of history[ ]

3: for i = 1 to n do

4: alloc Å ceil (u * history[i] / sum_history) 5: A[i] Å A[i] + alloc

6: if VV[i] ≥ alloc then 7: VV[i] Å VV[i] − alloc 8: else

9: VV[i] Å 0 10: end if

11: if there exists spare TRF timeslots then

12: dispatch spare timeslots in Round-Robin fashion 13: end if

下列偽碼中，CRA_demand[i][f]表示佇列 Qi 期待在視框 f 中取得的時槽個數。在計 算時槽需求量時，如果當時佇列的長度不超過佇列的CRA 額度（CRA_MAX），則佇列 會期待在即將開始的視框f 中取得足夠的時槽來清空整個佇列。相反的，如果當時佇列 的長度超過CRA 額度，則佇列期待拿到符合 CRA 額度的時槽量。 grant_CRA_demand(Qi)負責分配時槽，如果得到的時槽個數無法滿足 Qi 的期待個 數（這種狀況發生在通道錯誤率高使得TBTP 控制表格遺失時），為了不讓延遲增加， Qi 會將 ATM 封包丟棄。

compute_CRA_demand(Qi)

1: CRA_demand[i][f] Å min (CRA_MAX[i], next_demand[i]) 2: next_demand[i] Å next_demand[i] − CRA_demand[i][f] 3: return zero

grant_demand_and_compute_demand( )

1: for each RT or VR-RT queue Qi do 2: compute_CRA_demand(Qi)

3: end for

4: for each RT or VR-RT queue Qi do 5: grant_CRA_demand(Qi)

6: end for

7: for each VR-RT or VR-JT queue Qi do 8: grant_RBDC_demand(Qi)

9: end for

10: grant_VBDC_demand( )

11: for each VR-RT or VR-JT queue Qi do 12: compute_RBDC_demand(Qi)

13: end for

14: for each JT queue Qi do 15: compute_VBDC_demand(Qi) 16: end for

grant_RBDC_demand(Qi)負責分配 RBDC 配額，如果時槽數量不足（這種狀況發生 在通道錯誤率高使得TBTP 控制表格或要求訊息遺失時），VR-JT 的處理方式是為不足 的部分重新發出要求，而VR-RT 佇列的處理方式是丟棄 ATM 封包，以避免延遲增加。 在compute_RBDC_demand(Qi)中，RBDC_demand[i][f]表示佇列 Qi 期待在視框 f 中 取得的時槽個數，由於送出的要求訊息要經過d 視框後才得到回應，所以分配者在視框 f 中的計算是反應在將來的視框 f+d。如果視框 f 內有機會發送要求訊息，則 Qi 會期待 在視框f+d 中得到符合所發出的訊息的時槽數。如果無法發出要求訊息而且上一次發出 的RBDC 要求還沒過期，則 Qi 會期待得到符合上次要求的時槽數。若是無法送出要求 而且上一次發出的RBDC 要求已經過期，則 Qi 在視框 f+d 將拿不到時槽。

grant_RBDC_demand(Qi)

1: if available_timeslot ≥ RBDC_demand[i][f] then 2: dispatch RBDC_demand[i][f] timeslots to Qi 3: else

4: dispatch available_timeslot timeslots to Qi 5: if Qi is a VR-RT queue then

6: drop data of size RBDC_demand[i][f] – available_timeslot from head of Qi 7: else

8: next_demand[i] Å next_demand[i] + RBDC_demand[i][f] – vailable_timeslot 9: end if

10: end if

grant_CRA_demand(Qi)

1: if available_timeslot ≥ CRA_demand[i][f] then 2: dispatch CRA_demand[i][f] timeslots to Qi 3: else

4: drop data of size CRA_demand[i][f] from head of Qi 5: end if

JT 佇列中，我們把 ATM 封包分成以下三類： 1. 已經為其發出要求而且發出時間已經超過分配延遲 2. 已經為其發出要求但發出時間尚未超過分配延遲 3. 尚未為其發出 VBDC 要求的封包 分配者為JT 佇列分配時槽時，是依照各個佇列中，三種封包的數量。因為第一類的封 包是三種封包中最早進入RCST 節點的，所以分配者為 JT 佇列分配時槽時，應該先分 給第一類的封包使用，也就是說，分配者會先統計每一個佇列中的第一類的封包量，將 時槽先分配給那些擁有第一類的封包的佇列。為第一類封包分配時槽後如果還有剩餘時 槽（表示RCST 節點因 FCA 機制取得多餘的時槽，或者是因為 RCST 節點中具有 CRA 配額的佇列並沒有將全部配額用盡），接著分給第三類封包，最後是第二類封包。我們 以next_demand[Qi]表示佇列 Qi 中第一類封包的總和、以 sum_expired_demand[Qi]表示 第二類的總和、並以sum_non_expired_demand[Qi]表示第三類的總和。 grant_VBDC_demand( )負責分配時槽給 RCST 節點中的各個 JT 佇列，首先是取 sum_expired_demand[ ]作為分配上限，以 Round-Robin 方式分配，也就是說一次分配一 個時槽給一個佇列，每當輪到佇列Qi 時，如果 Qi 已經拿到 sum_expired_demand[Qi]個 時槽，則不分配給Qi，直接換下一個佇列。接著取 next_demand[ ]作為分配上限，同樣 以Round-Robin 方式分配，最後取 sum_non_expired_demand[ ]作為分配上限，以 Round-Robin 方式分配。

compute_RBDC_demand(Qi)

1: if the RCST has opportunity to send capacity request then

2: RBDC_demand[i][f + d] Å min (VBDC_MAX[i], next_demand[i]) 3: else if previous RBDC request has not expired yet then

4: RBDC_demand[i][f + d] Å the value of previous request 5: else

6: RBDC_demand[i][f + d] Å zero 7: end if

8: next_demand[i] Å next_demand[i] − RBDC_demand[i][f + d] 9: return RBDC_demand[i][f+d]

要求者對VBDC 的處理與對 RBDC 一樣有做要求訊息遺失的處理，在我們的設計

中，判斷VBDC 要求遺失是依靠 TBTP 控制表格中，一個稱為「queue_empty」的欄位，

若RCST 節點 R1 在 NCC 節點的 VBDC 積欠量為零，TBTP 控制表格上就會將 R1 的

queue_empty 設為 true，當 R1 收到 TBTP 控制表格，發現此欄位為 true，而且 R1 中有 JT 佇列的 sum_expired_demand 不為零，則表示有要求訊息遺失。上述狀況發生時，要

求者會為歸類為第一類的ATM 封包重新要求時槽。

compute_VBDC_demand(Qi)

1: if request loss happened then

2: next_demand[i] Å next_demand[i] + sum_expired_demand[i] 3: end if

4: if the RCST has opportunity to send capacity request then 5: VBDC_demand[i][f + d] Å next_demand[i] 6: else 7: VBDC_demand[i][f + d] Å zero 8: end if 9: next_demand[i] Å zero 10: return VBDC_demand[i][f+d]

grant_VBDC_demand( )

1: compute sum_expired_demand[ ] and sum_non_expired_demand[ ] 2: dispatch timeslots in Round-Robin fashion depending on

sum_expired_demand[ ] 3: if available_timeslot ≠ 0

4: dispatch timeslots in Round-Robin fashion depending on next_demand[ ] 5: endif

6: if available_timeslot ≠ 0

7: dispatch timeslots in Round-Robin fashion depending on sum_non_expired_demand[ ]

四、 DVB-RCS 模擬及正確性驗證

4.1. 系統測試相關參數

我們在這一章中以模擬方式驗證系統的正確性，我們把模擬所使用的重要系統參數 列在表2 以及表 3，並將使用的拓樸顯示在圖 15。表 3 僅列出共通的參數，額外的參數 將於個別模擬範例中描述。 參數名稱 參數值 參數描述 PUDP 1472 位元組 UDP 封包的負載大小 RS 16 Mboud 符號傳輸率 SFEC Normal（8100 位元組） 經過FEC 編碼後的區塊大小 調變模式 QPSK LDPC 編碼率 1/3 表2 正向通道相關參數 參數名稱 參數值 參數描述

PUDP 1472 Bytes UDP 封包的負載大小

RS 9.935 Mboud 符號傳輸率

RCC 1/2 CC 編碼率

NATM 2 一個TRF Burst 裝載的 ATM 封包個數

NTB 98 一個視框中的資料時槽個數

NRB 2 一個視框中的要求時槽個數

LP 16 Symbols Preamble Length

TG 2 * 10-7 sec Guard Time

TT 10-4 sec 時槽長度 FT 10-2 sec 視框長度 分配延遲 50 視框 RCST 節點發出要求訊息與收到回應之間的時 間 頻道總頻寬 7.5 Mbits/sec 反向通道上每一個頻道的傳輸率上限值 調變模式 QPSK 表3 反向通道相關參數

Satellite Gateway Feeder SP Service Provider Network Control Center Κإٻຏሐ Κ֘ٻຏሐ RCST 2 RCST 1 圖15 模擬使用的拓樸

4.2. UDP 模擬數據與驗證

4.2.1. 正向通道

在這一節中，我們推算應用層在正向通道上可得傳輸率的理論值，並且在我們開發 的DVB-RCS 模擬平台上做模擬，將量測出來的數據與理論值比較。 理論值推導 在正向通道上有三個主要的額外負擔來源：控制表格、通道編碼、以及封裝。以下 為了簡化計算，我們忽略控制表格所帶來的額外負擔。為了方便數據推導，我們將封包 的封裝過程整理至圖16，詳細說明請參考第三章。 我們以APL表示每秒可傳送PLFRAME 的平均個數、以 ABB表示每秒可傳送

BBFRAME 的平均個數、以 ATS表示每秒可傳送MPEG2-TS 封包的平均個數、以 AMPE

表示每秒可傳送MPE section 的平均個數、以 TAPP表示應用層可拿到的傳輸率。以下我

PL Header Application Data IP Header UDP Header IP Datagram Payload Section Header TS Header Payload MPEG2-TS packet 1 4 184 TS Header Payload MPEG2-TS packet n 4 184 ... MPEG2-TS Stream ... ... ... ... ... Payload BB Header BBFRAME 10 BBFRAME BCH Code LDPC Code FECFRAME Payload 90 PLFRAME Modulating Unit MPE Section 圖16 正向通道的資料封裝過程 我們選用的QPSK 調變模式可用一個符號表示 2 位元資料，所以一個 FECFRAME

經過調變會成為SFEC * 8 / 2 個符號並當作 PLFRAME 的負載。一個 PLFRAME 附帶一個

大小為90 個符號的標頭，所以 PLFRAME 大小 SPL為： Symbols 32490 90 8100 90 S SPL FEC = + ∗ = + ∗ = 2 / 8 2 / 8 實體層每秒可以傳輸RS個符號，所以我們可以推得：

sec / 459 . 492 32490 / = ∗ = = 6 PL S PL 10 16 S / R A

一個PLFRAME 攜帶一個 FECFRAME，而且一個 FECFRAME 攜帶一個 BBFRAME，

所以ABB=APL。為了算ATS，我們先算出一個BBFRAME 平均可以裝載的 MPEG2-TS

封包個數。表4 為 DVB-RCS 標準書中通道編碼的參數，我們選用 1/3 的 LDPC 編碼率

以及8100 位元組的 FECFRAME，從表中我們可知道未編碼區塊大小（也就是 BBFRAME

大小）為2676 位元組，而 BBFRAME 標頭大小為 10 位元組，所以可以算出 BBFRAME

負載大小SBB為2686 位元組。MPEG2-TS 封包大小固定為 188 位元組，而 BBFRAME

在封裝MPEG2-TS 封包時可以將 MPEG2-TS 封包切割成兩份放置在不同 BBFRAME 送

出，以減少填塞帶來的額外負擔。所以一個BBFRAME 平均可以裝載 SBB / 188 個 MPEG2-TS 封包，我們可以推得： sec / 10 * 036 . 7 188 / 2686 3 = ∗ = ∗ = 492.459 188 / S A ATS BB BB 表4 FEC 編碼前以及編碼後的區塊大小 （單位：位元組）

Normal FECFRAME

Short FECFRAME

LDPC rate Uncoded block LDPC coded block BCH coded block LDPC rate Uncoded block LDPC coded block BCH coded block 1/4 2001 2025 8100 1/4 384 405 2025 1/3 2676 2700 8100 1/3 654 675 2025 2/5 3216 3240 8100 2/5 789 810 2025 1/2 4026 4050 8100 1/2 879 900 2025 3/5 4836 4860 8100 3/5 1184 1215 2025 2/3 5380 5400 8100 2/3 1329 1350 2025 3/4 6051 6075 8100 3/4 1464 1485 2025 4/5 6456 6480 8100 4/5 1554 1575 2025 5/6 6730 6750 8100 5/6 1644 1665 2025 8/9 7184 7200 8100 8/9 1779 1800 2025 9/10 7274 7290 8100 9/10 N/A N/A 2025

接下來我們推算一個MPE section 需要幾個 MPEG2-TS 封包來傳送。我們以 HUDP表示

UDP 標頭大小、以 HIP表示IP 標頭大小、以 HMPE表示MPE section 標頭大小。一個 MPE

section 裝載一個 IP 封包，UDP 標頭大小為 8 位元組、HMPE在我們的設計中為16 位元

組，最常見的IP 標頭大小為 20 位元組，因此 MPE section 的大小 SMPE為：

Bytes 1516 16 1472 8 20 H P H H

SMPE IP UDP UDP MPE

= + + + = + + + =

一個MPEG2-TS 封包可容納 184 位元組的負載，所以一個 MPE section 經過切割後，所

形成MPEG2-TS 封包的數量 NST可表示為：

(

)

(

)

9 184 / 1516 ceil 184 / S ceil NST MPE = = =

每一秒可傳送ATS個MPEG2-TS 封包，而每 NST個MPEG2-TS 封包可傳送一個 MPE

section，所以每一秒可傳送的 MPE section 個數為：

sec / 10 * 7.818 9 / / 2 = = = 10 * 7.036 N A A 3 ST TS MPE 一個MPE section 裝載一個 IP 封包，而一個 IP 封包裝載 1472 位元組來自應用層的資料， 所以應用層傳輸率為： Mbits/sec Bytes/sec 1472 * A TAPP MPE 208 . 9 10 * 151 . 1 1472 * 10 * 818 . 7 6 2 = = = = 模擬測試 為了測得應用層的傳輸率，我們設定一組簡單的網路拓樸，如同圖15 所示。我們

在SP 與 RCST 1 之間建立一條 UDP 連線，SP 設定一個 Greedy UDP 送端程式，Greedy UDP 送端程式會盡其可能地利用頻寬，我們並在 RCST 1 設定 UDP 收端程式。我們對

各種的實體層模式做模擬測試，所量測出來的應用層傳輸率顯示在表5，對應的理論值

也列在表中，理論值與量測值的差異來自於控制表格的額外負擔以及計算時四捨五入產 生的誤差。