3. 系統設計概念與背景
3.5. Digital Storage Media Command and Control
3.5.1. DSI and DII
DSI跟DII用於描述資料來源之gateway以及OC內容的檔案層級架構，包含一 個OC被分割成多少模組，module的id，size，模組共包含多少的DDB等等訊息，
而這兩種格式的Header是一樣的，如Figure 28所示。
3.5.1.1. DSM-CC Message Header
z protocolDiscriminator，長度為 1 bytee，值固定為 0x11。
z DSM-CCType，長度為 1 byte，主要是用來確認它是屬於MPEG-2 DSM-CC message中的哪一種type，它的值是 0x03。DSM-CCType的內 容如Table 8所示。
z messageId，長度為 2 bytes，用來確認要處理的message是屬於哪一種類
型，它的值由DSM-CCType來決定，值的對應表如Table 9所示。
z messageLength，長度為 2 bytes，記錄了這個 message 真正的長度(包含 Header)。當我們要抓資料時，只要從 messageLength 扣掉 headerLength 就可以知道我們真正要抓取的資料長度了。
Syntax No. of bytes
dsmccMessageHeader(){
protocolDiscriminator 1
dsmccType 1
if(adaptationLength > 0){
dsmccAdaptationHeader() }
}
Figure 28. Syntax of Mpeg-2 DSM-CC Message Header Table 8. MPEG-2 DSM-CC dsmccType values dsmccType Description
0x00 ISO/IEC 13818-6 Reserved
0x01 Identifies the message as an ISO/IEC 13818-6 IS User-to-Network configuration message.
0x02 Identifies the message as an ISO/IEC 13818-6 IS User-to-Network session message.
0x03 Identifies the message as an ISO/IEC 13818-6 IS Download message.
0x04 Identifies the message as an ISO/IEC 13818-6 IS SDB Channel Change Protocol message.
0x05 Identifies the message as an ISO/IEC 13818-6 IS User-to- Network pass-thru message.
0x06-0x7F ISO/IEC 13818-6 Reserved.
0x80-0xFF User Defined message type.
Table 9. DSM-CC Download messageId assignment Message Name messageId Description
DownloadInfoRequest 0x1001 Client requests download parameters DownloadInfoResponse,
DownloadInfoIndication 0x1002 Download Server provides download parameters
DownloadDataBlock 0x1003 Download Server sends one download data block
DownloadDataRequest 0x1004 Client acknowledges downloaded data blocks
DownloadCancel 0x1005 Client or Download Server aborts the download scenario in progress
DownloadServerInitiate 0x1006 Download Server requests Client to initiate a download
3.5.1.2. DownloadServerInitiate Message
當應用程式極大, 以至於存在雙層的Object carousel時，DSI可用來記錄各個 不同的DII之間的關係的。DSI的格式如Figure 29所示。
Syntax No. of bytes
DownloadServerInitiate(){
dsmccMessageHeader()
serverId 20
compatibilityDescriptor()
privateDateLength 2
for(i = 0 ; i < privateDateLength ; i++){
privateDateByte 1
} }
Figure 29. Syntax of DownloadServerInitiate Message 3.5.1.3. DownloadInfoIndication Message
DII記錄著跟Object carousel中包含的資料，包括了number of modules，module ID，module size…等等和我們要解出DDB中包含的資料時相關的訊息。DII的格 式如Figure 30所示。
z downloadId，長度為 4 bytes，用來確認我們所收到的每一個 block 都是 屬於同一個 object carousel，downloadId 的值是在傳送時，由 network
指定，在之後使用的 DownloadDataBlock 都會有相同的 downloadId。
z blockSize，長度是 2 bytes，用來告知處理器這個 service 的所有 block 的大小，除了方便處理器對每一個 block 作處理之外，也可以讓我們方 便得知每一個 module 被切成幾個 blocks。
z numberOfModules，長度是 2 bytes，用來記錄這個 service 中總共包含了 幾個 modules。
z moduleId，長度 2 bytes，功用是用來確認 DownloadDataBlock 是屬於這 個 module。
z moduleSize，長度是 4 bytes，用來記錄這個 module 的大小，配合前面 的 blockSize 的話，我們可以得知這個 module 總共被切成幾個 blocks，
並由此判斷我們是不是已經收到全部的 blocks。
moduleInfoLength 1 for(i = 0;i < moduleInfoLength;i++){
moduleInfoByte 1
} }
privateDataLength 2
for(i = 0;i < privateDataLength;i++){
privateDataByte 1
for(i = 0;i < numberOfModules;i++){
moduleId 2
moduleSize 4
moduleVersion 1
Figure 30. Syntax of DownloadInfoIndication Message 3.5.2. DownloadDataBlock Message
順利解出DSI跟DII當中包含的訊息之後，即可確認這一個service當中，總共 包含了幾個modules，然後每一個module各自被切成幾個blocks，這時我們就可以 一一的把真正存有資料的DDB抓進來，依序填到它們應該在的module中正確的 位置，直到每一個module都被重新合併完成之後，再進行OC（以Broadcast Inter-ORB(Object Request Broker) Protocol(BIOP)格式編碼）的解碼。其中DDB的
格式如Figure 31，Figure 32所示。。
z downloadId，長度為 4 bytes，用來和 DII 中的 downloadId 比對，以確定 我們收到的是屬於同一個 service。
z moduleId，長度為 2 bytes，用來確認這個 block 是屬於哪一個 module。
z blockNumber，長度為 2 bytes，因為每一個 module 都會被分成一個或 是多個 blocks，但是在接收時，並沒有辦法保證我們收到跟處理是照次 序的，所以要靠 blockNumber 幫它們重新照次序組合。
Syntax No. of bytes
dsmccDownloadDataHeader(){
protocolDiscriminator 1
dsmccType 1
if(adaptationLength > 0){
dsmccAdaptationHeader() }
}
Figure 31.
Figure 32.
Syntax of DownloadDataBlock Header
Syntax No. of bytes
DownloadDataBlock(){
dsmccDownloadDataHeader()
moduleId 2
Syntax of DownloadDataBlock
3.5.3. BIOP
BIOP 的全名為 Broadcast Inter-ORB Protocol，它主要是由多個 modules 所組 成的，裡面包含的就是最原始檔案的資料，包括了檔案名稱、檔案內容、檔案之 間的結構。其中還可以再細分成為 SrgandDir Message，File Message，Stream Message，StreamEvent Message 等種類。
3.5.3.1. BIOP SRGandDIR Message
當我們收到的一份完整的資料，包含資料夾、檔案，它們在原始的資料提供 者端被以樹狀結構(tree structure)階層式儲存，而其中所有樹狀結構的根部節點 (root)就是SrgandDir Message，也就是Service Gateway Message(Srg)，在一個OC 中只會出現一次。之後再收到的每一個SrgandDir message都是屬於Directory message(Dir)，除非這份資料當中存在兩個以上的樹狀結構。SrgandDir message 的格式如Figure 33所示。
z Magic，長度為 4 bytes，它的值被固定為 0x42494F50，用來確認這是 BIOP message 的開頭。
z objectKey_length，長度為 1 byte，用來決定 objectKey_data_byte 的長度。
z objectKey_data_byte，長度由 objectKey_length 決定，如果是 Directory Message 的話，可以和 BIOP Profile Body 中的 objectKey_data_byte 比較 來判斷這一個 Directory 的父節點是哪一個。如果是 File Message 的話，
則可以用來判斷它所儲存的資料是屬於哪一個檔案。
z objectKind_length，長度為 4 bytes，如果是 SRG Message 的話，其值為 0x73726700，如果是 DIR Message 的話，其值為 0x64697200。除了 objectKind_length 之外，SRG 跟 DIR 的其他格式都是一樣的。
z bindings_count，長度為 2 bytes，主要是記錄這個資料夾底下，包含了 幾個資料夾或是檔案。
z nameComponents_count，長度為 1 byte，記錄了現在我們讀到的這份資 料，它的名稱我們用幾個 bytes 來儲存它。
z id_length，記錄了我們現在讀到的這份資料，它名稱的長度。
z id_data_byte，真正記錄我們現在讀到的這份資料的名稱。
z kind_data_byte，記錄了我們現在讀到的這份資料是屬於哪一種類型，
dir、fil、str，ste。
z IOR，如Figure 34所示。其中從IOP::taggedProfile()這個function之後的 內容屬於BIOP Profile Body，如Figure 35所示。
z Profile_tag，長度為 4 bytes，其值是 0x49534F06，用來確認這是 BIOP Profile Body 的開頭。
z objectKey_length，長度為 1 byte，用來決定後面的 objectKey_data_byte 的長度，因為它的名稱和之前在 BIOP 的 message 中出現過，所以這邊 稱為 profile_objectKey_length。
z objectKey_data_byte，長度由 profile_objectKey_length 決定，只有在 SrgandDir message 中會出現，用來和前面的 objectKey_data_byte 互相參 考，以重建整個樹狀結構。
Syntax No. of bits
serviceContextList_count 8
for (i = 0; i < N3; i++){
Figure 33. Syntax of BIOP Directory Message
Syntax No. of bits
Figure 34. Syntax of IOP:IOR()
Syntax No. of bits BIOPProfileBody{
profileId_tag 32
profile_data_length 32
profile_data_byte_order 8
liteComponents_count 8
BIOP::ObjectLocation{
Figure 35. Syntax of BIOP Profile Body
3.5.3.2. BIOP File Message
記錄了每一個對應到的檔名，它的真正檔案內容，
格式
，長度為 4 bytes，其值被固定為 0x66696C00。
，記錄了真正的檔案資料內容。
Figure 36. Syntax of BIOP File Message 3.5.3.3. Example
，這是一個BIOP資料原始樹狀結構的例子。下面的步驟就 是我
BIOP file message當中，
如Figure 36所示。
z objectKind_data z content_data_byte
Syntax No. of bits
ntent_length
}
DSM::File::ContentSize 64
for (i = 0; i < N2 - 8; i++){
objectInfo_data_byte 8 }
ceContextList_count 8
for (i = 0; i < N3; i++) {
1) 讀取到 dir，objectKey 是 06，然後它的 bindings_count 為 1。
z rofile_objectKey為 04，代表在step. 2 讀到具有objectKey = 04
z tKey為 08，代表在step. 3 讀到具有objectKey = 08 的dir就是dir。
z fileName：file6，profile_objectKey是 07。
讀到 dir，objectKey 是 04，然後它的 bindings_c z fileName：file3，profile_objectKey是 05。
z dirName：dire，profile_objectKey是 06。
讀到 dir，objectKey 是 08，然後它的 bindings_
z fileName：file4，profile_objectKey是 09。
讀到 dir，objectKey 是 0A，然後它的 bindings_
z fileName：file5，profile_objectKey是 0B。
讀到 srg，objectKey 是 01，然後它的 bindings_c z fileName：file1，profile_objectKey是 02。
z fileName：file2，profile_objectKey是 03。
z dirName：dirb，profile_objectKey是 04。
z dirName：dirc，profile_objectKey是 08。
z dirName：dird，profile_objectKey是 0A。
重建樹狀結構。
z 由srg開始，它 dire。
dirb的p
的dir就是dirb。 dirc的profile_objec
z dird的profile_objectKey為 0A，代表在step. 4 讀到具有objectKey = 0A的dir就是dird。
7)
它儲 。
者端重新 cation manager 來讀取並執行了。
z dire的profile_objectKey為 06，代表在step. 1 讀到具有objectKey = 06 的dir就是dire。
讀到fil，objectKey是 02，和step. 5 中file1的profile_objectKey相同，代表 存的是file1的資料
8) 讀到fil，objectKey是 03，和step. 5 中file2的profile_objectKey相同，代表 它儲存的是file2的資料。
9) 讀到fil，objectKey是 05，和step. 2 中file3的profile_objectKey相同，代表 它儲存的是file3的資料。
10) 讀到fil，objectKey是 07，和step. 1 中file6的profile_objectKey相同，代表 它儲存的是file6的資料。
11) 讀到fil，objectKey是 09，和step. 3 中file4的profile_objectKey相同，代表 它儲存的是file4的資料。
12) 讀到fil，objectKey是 0B，和step. 4 中file5的profile_objectKey相同，代 表它儲存的是file5的資料。
處理到這邊，我們就可以把資料原本的被傳送端處理過之前的樣子，在接收 建立起來，並且準備等 appli
Figure 37. Example of BIOP
4. 系統架構設計與實作
在本論文當中，實作與實驗的系統，主要是參照 13818-1 的規格書、13818-6 的規格書、以及DVB-MHP的規格書中所制定相關的部份加以整理，並且考慮將 子系統的各個部份整合時的效能考量，所設計出來的一套可以各種平台(包括 windows及Unix like)上獨立執行的系統。根據實作時的作法以及效能的考量，整 個系統架構如Figure 38所示。
其中主要分成三個部份：
1) TS Parser，處理 transport stream 的 packets 以及跟 Service Information 相 關的部份，包含 Demux 和 Section Filter 中與 packets 處理相關的功能、
以及 Service Information 中對於 PAT 及 PMT 處理的功能。
2) AIT Decoder，包含 AIT 的剖析，以及 application manager 中查詢 AIT 與 DVB-J Applicatoins 的功能，用來確認我們的設計是實際可行的。
3) DSM-CC，包含了 DSM-CC 以及 Section Filter 的部份，負責整個 object carousel 由接收到解碼以及儲存的處理，從 Sections 的處理直到完整的 解出資料來為止。
Figure 38. System Architecture of DSM-CC decoder
4.1. Transport Stream Parser
在 Service Information 的工作當中，只有 PAT 以及 PMT 的部份和 DSM-CC 相關。所以如果把 SI 這部份獨立出來實作的話，除了增加實作上的困難之外，
在資料的傳輸上的時間耗費以及解出來的資料在送給 Demux 處理之前的記憶體 使用，都是一種不必要的負擔。
所以在這個部份，本論文特別把Demux和PAT、PMT的處理這部份，以及 Section Filter中處理packets的部份合併成為TS Parser，專門處理將AIT的資料及 DSM-CC的資料抽取出來的工作。流程大致上如Figure 39所示。
Figure 39. Block Diagram Transport Stream Parser 4.1.1. PAT and PMT
在本論文的實作系統當中，如果收到了一段 transport stream 的話，就會開始 處理去讀出每一個 packet 的 PID。然後在處理到 PID= 0x0000 的 packet 之前(也 就是 PAT)，所有收到的 packet 都全部忽略不繼續處理。
等到取得PAT的資料並且完成處理之後，我們可以透過PAT的內容得知PMT 的PID，這時就開始處理PMT的內容，並且建立不同的table來儲存DSM-CC資料 的PID以及AIT資料的PID。如Figure 40所示。
Figure 40. The procedure of PAT and PMT parsing 4.1.2. Section Filter
在取得 DSM-CC 跟 AIT 資料的 PID 之後，我們會開始讀取該 PID 對應的 packets。
以AIT為例，首先先檢查這個packet的PID是不是屬於AIT，如果不是的話，
就把整個packet丟掉，再往下讀一個packet。如果是屬於AIT的話，則檢查它的 payloadUnitStartIndicator的值。如Figure 41所示。
1) 如果 payloadUnitStartIndicator = 0，表示在這個 packet 當中，沒有新的 section 的開頭，則檢查它相對應的 temp file 是不是空的。
A. 如果 temp file 是空的，代表這個 section 還沒有被處理過，但是若 是一個新的 AIT section 的話，那它的 payloadUnitStartIndicator 應 該會被設為 1，由此可知，這其中應該有丟失封包，所以我們必須 把這個 packet 整個略過不處理，直接去讀取下一個 packet。
的值，則我們要作的就是把資料讀入 temp file，再去讀取下一個 packet。
2) 如果 payloadUnitStartIndicator = 1 的話，表示在這個 packet 中，存在一 個新的 section 的開頭，這時我們就要去檢查 pointerField。
2) 如果 payloadUnitStartIndicator = 1 的話，表示在這個 packet 中，存在一 個新的 section 的開頭，這時我們就要去檢查 pointerField。