手機電視(DVB-H)軟件接收器

4.5錯誤產生、偵測與分類機制

當接收端硬件接收到由傳送端所傳送的傳輸串流封包時，硬件會先對封包進行一次所羅門譯碼，若是超出其糾錯解a能力時，將會把封包標頭內的錯誤指標字段(ErrorIndicator)設定為1，藉此來標示發生錯誤的封包，而本研究于錯誤偵測判斷時，即是根據此標頭字段值，并透過設定此字段值來產生顯著的錯誤數據，以突顯MPE-FEC機制的運作。當發現錯誤封包之后，將立即執行錯誤分類機制來找出錯誤發生在整個section的哪個區段并在一個與MPE-FEC框架相同大小的ErrorBit-mapBuffer(EBB)中的相對應位置設成1來表示其在框架中的錯誤位置，以便提供往后所羅門譯碼所需的錯誤位置數據，而整個錯誤分類機制的虛擬程序代碼如表3所示。

表3 錯誤分類機制虛擬程序代碼

If ErrorIndicator is equal to 1

If HeaderDecoded is true

If error at middle of section

Set 1 in EBB according to the TS payload

region of this section in MPE-FEC frame

Drop this TS packet

else

If packet carry part of next section header

Set 1 in EBB according to the TS payload

region of this section and whole the next

section payload region in MPE-FEC

frame

Drop this TS packet and drop all TS

packets of next section

else

Set 1 in EBB according to the TS

payload region of this section in

MPE-FEC frame

Drop this packet

else

Set 1 in EBB at whole section payload

region in MPE-FEC frame

Drop all TS packets of this section

當傳輸串流分派器收到封包并立即偵測與判斷封包標頭中的錯誤指標字段是否為1，若為1則表示發生錯誤而進一步開始找出此錯誤封包所載送的數據是位于整個section的哪個區段位置，若是發生在section標頭部位，由于標頭是載送整個section最重要的信息來源位置，因此為了能正確地接收往后的section，故當發生錯誤的封包包含任一字節的標頭信息時，將會將整個section數據完全丟棄而等待下一個正確載送section標頭的封包進來。如果發生錯誤的封包是載送標頭信息之外的部份時，則再進一步判斷封包中載送的數據范圍是位于整個section數據的哪個區段，若僅是中間部位，則只丟棄該封包而等待下一個正確封包即可，但若是section末端數據的話，則需再進一步的判斷是否包含到下一個section標頭信息，如果有的話，則一并把載送下一個section數據的所有封包丟棄而等待下一個正確載送section標頭的封包進來，反之則一樣僅丟棄該封包即可。

4.6Time-Slicing傳輸機制設計

DVB-H傳送數據的方式是采用Burst傳輸方式，采用此種方式時，則必須精確地得知下一個Burst的抵達時間與傳輸該Burst數據的最大傳輸時間，才能讓硬件能于正確時間點開關接收器來接收數據，而接收端在接收數據時，必須滿足兩個時間要求：

(1) 當Burst到來，并接收到第一個MPEsection進行解讀時，section標頭必須在Delta-TJitter時間內解a并將Delta-T值回傳到實體層。

(2) IP解封裝器必須于Delta-T時間內完成所有section的譯碼與MPE-FEC機制的運作，并將數據輸出到終端。

由于未必能在Burst的最大維持時間內將所有section數據解讀完成，故接收端必須以緩沖器暫存整個Burst時間內的所有section封包，而封包的譯碼工作在剩余的Delta-T時間內完成即可。

除此之外，由于在處理的過程中使用緩沖器來暫存section封包數據，而再取出解讀時，其標頭中所挾帶的實時性Delta-T信息已失效，僅有解讀第一個MPEsection所造成的延遲時間最為短暫。

因此，在實作上即采用第一個MPEsection標頭所挾帶的Delta-T信息來告知實體層下一個Burst的到來時間，而其余section標頭內的Delta-T信息將不被讀取采用。整個section封包處理延遲時間示意圖即以圖9呈現。

圖9 section封包處理延遲時間示意圖

5、 實驗模擬結果

本研究整個實驗模擬結果均是利用個人計算機(PC)進行測試，個人計算機的配備如表4所呈現，并以公視試播計劃所提供的傳輸串流當作是播放測試檔案，而表5則是從公視所提的串流檔案擷取出來的信息。

5.1正確性驗證

本研究糾錯后的數據驗證是利用文字處理軟件Ultra-Edit所提供的二進制檔案比對來完成，分別將添加錯誤的每個Burst數據與修正后的數據存成檔案后再與驗證檔案進行比對。

5.2效能評估

本文的MPE架構與Time-Slicing傳輸機制設計主要采用[4]的觀實作觀念與架構，[4]中對每個Burst數據(僅有針對MPEsection)的處理時間已有相當完整的分析信息，故本論文即針對主要設計的MPE-FEC糾錯機制做實作上的效能分析與探討。

表4個人計算機基本配備表

處理器廠牌規格

Intel Pentium 4

處理器處理速度

3.0 GHz

硬盤大小

80 GBytes

內存容量

512 MBytes

表5公視影像來源參數數據

參數

數值

檔案大小

755,605,652(bytes)

封包總數

4,019,179(封包以188個bytes為單位)

MPE-FEC框架總列數

512列

Delta-T

1250 ms

Delta-T Jitter

7.5 ms

最大Burst持續時間

200 ms

省電效率

79.7%

每秒畫面更新速率

15 (frame per second,

整個傳輸流檔案中，每個Burst所挾帶的框架大小為255×512，而框架資料量大小為1Mbits(128kBytes)，每個MPE-FEC框架執行的RS糾錯運算次數為512次(即每一列執行一次RS糾錯運算)，編碼率(coderate)為2/3的情況條件下，10個Burst、50個Burst與100個Burst單純使用Java以及RS譯碼采用Euclid算法在Windows上的完整MPE-FEC糾錯機制與單純RS譯碼的平均執行時間如圖13所示。