3. 系統設計概念與背景
3.3. Application Information Table
3.3.3. Application Icons Descriptor
Application icons descriptor在AIT當中屬於選擇性的參數，會記錄影像或是可 用來表示這一個應用程式的圖片。它的格式如Figure 23所示。
z descriptor_tag，長度為 8 bits，值固定為 0x0B，用來確認被記錄的是 application icons descriptor。
z descriptor_length，長度為 8 bits，用來記錄這個 descriptor 的長度。
z icon_locator_length，長度為 8 bits，用來記錄 icon 所在的檔案名稱長度。
z icon_locator_byte，具體指明了 icon 的真正位置。
Syntax No. of bits
reserved_future_use 8
} }
Figure 23. Syntax of Application Icons Descriptor 3.3.4. DVB-J Application Descriptor
DVB-J Application Descriptor告訴接收者當這個應用程式要被執行時，需要 傳遞哪些參數給這個應用程式。它的格式如Figure 24所示。
z descriptor_tag，長度為 8 bits，值固定為 0x03，用來確認被記錄的是 DVB-J application descriptor。
z parameter_length，長度為 8 bits，記錄了要傳遞的參數的長度。
z parameter_byte，這是一個 string 的陣列，記錄了所有要傳給這個應用程 式的參數。
Syntax No. of bits
for(j=0; j<parameter_length; j++){
parameter_byte 8
} } }
Figure 24. Syntax of DVB-J Application Descriptor 3.3.5. DVB-J Application Location Descriptor
DVB-J application location descriptor用來告訴接收者這個應用程式的base directory在哪邊，標示應用程式的main class，以及指示與應用程式相關的class時 的路徑。它的格式如Figure 25所示。
z descriptor_tag，長度為 8 bits，值固定為 0x04，用來確認被記錄的是 DVB-J application location descriptor。
z base_directory_length，長度為 8 bits，用來指明 base_directory_byte 的長 度。
z base_directory_byte，記錄了一個從 file system 的 root 開始的 directory name，而這個路徑也是這個應用程式要開始執行的 base path name。
z classpath_extension_byte，記錄了除了 base directory 之外，如果還要搜 查其他的 classpath 的話，這些 classpath 被存放的路徑。
z initial_class_byte，包含了一個 string，記錄了 the name of the object in the system that is the class implementing the Xlet interface。而這個 string 是一
個 DVB-J 可 以 在 classpath 中 找 到 的 class name ，
Classpath_extension_length 8
for(i=0; i<N; i++){
Figure 25. Syntax of DVB-J Application Location Descriptor
3.4. Section Filter
在經過 Demux 以及 Service Information 的處理之後，SI 擁有 PMT，可得知 每一個 PID 所對應到的 packet 是屬於什麼樣的類型的應用程式，而 DSM-CC 這 時就可以經由 SI 取得 DSM-CC 相關資料的 PID。DSM-CC 再以所欲取得之資料 的 PID 向 Section Filter 取得包含 DSM-CC 資料的 sections。
在Figure 26中，我們可以看出sections，blocks，modules，還有DSM-CC object carousel之間的關係。當SF收到各類資料的sections，會把從Demux端接收到的 sections按照不同的類型送給對應的功能模組處理；當SF收到DSM-CC相關的 sections，則將其交給DSM-CC功能模組處理。
Figure 26. Relationship between sections, blocks, modules, and DSM-CC object carousel
3.4.1. Sections
從Demux端收到的sections是由一個或是多個packets所組合而成的，而其中 每個section的長度最大不超過 4099 bytes，section的syntax如Figure 27所示。
z table_id，長度是 8 bits，我們主要用到的table_id值為 0x3B跟 0x3C兩種，
0x3B 對 應 到 的 是 Download Server Initiate(DSI) 跟 Download Info Indication(DII)兩種，0x3C對應到的是Download Data Block(DDB)，
table_id的值在DSM-CC中的定義如Table 7所示。
z dsmcc_section_length，長度為 12 bits，用來記錄這個 section 的真正長 度，所以一個 section 的長度最多不超過 4099bytes。
z table_id_extension，長度為 16 bits，只有在 table_id 是 0x3B 時有用，功 能是判別這個 section 是屬於 DSI 或是 DII。如果 table_id_extension 的
值是 0x0000 及 0x0001 的話，那這是屬於 DSI，其他 table_id_extension
if(table_id == 0x3A){
LLCSNAP() }
else if (table_id == 0x3B){
userNetworkMessage() }
else if (table_id == 0x3C){
downloadDataMessage() }
else if (table_id == 0x3D){
DSMCC_descriptor_list() }
else if (table_id == 0x3E){
for (i = 0;i < dsmcc_section_length - 9;i++){
private_data_byte }
}
if(section_syntax_indicator == "0"){
checksum 32
Figure 27. Syntax of the DSM-CC section
Table 7. DSM-CC table_id assignment Table_id DSM-CC Section Type
0x3A DSM-CC Section containing multi-protocol encapsulated data
0x3B DSM-CC Section containing U-N Message, except Download Data Message
0x3C DSM-CC Section containing Download Data Message
0x3D DSM-CC Section containing Stream Descriptor 0x3E DSM-CC Section containing private Data 0x3F ISO/IEC 13818-6 reserved
3.5. Digital Storage Media Command and Control
DVB-MHP的規範是利用DSM-CC來傳送加值應用程式及其所需的資料的 [11][12][13]，當機上盒系統收到了DSM-CC sections，可由section header判斷該 section所含之資料的類型，再分別將這些sections依序排成完整的DSM-CC資料。
當DSM-CC資料被重組完成之後，就可以傳給解碼器處理。解碼時，DSM-CC再 分別以對應的解碼方式處理。DSM-CC共包含三種類型的資料：包含實際OC內 容的DDB, 描述OC架構的DII, 以及帶有gateway參照資料的DSI。
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 =
z dird的profile_objectKey為 0A，代表在step. 4 讀到具有objectKey =