電子類畢業(yè)設(shè)計(jì)中英文翻譯

1、<p><b>　　譯　文</b></p><p>　　翻譯中文（摘自DVB-CI(EN50221)規(guī)范）</p><p><b>　　1.設(shè)計(jì)體系</b></p><p><b>　　1.1.層次化</b></p><p>　　為了適應(yīng)在將來的實(shí)現(xiàn)中無法預(yù)料的變化，

2、DVB－CI規(guī)范描述采用分層結(jié)構(gòu) (其層次結(jié)構(gòu)將在下文中詳細(xì)闡述) 。此處對(duì)幾個(gè)層次作簡(jiǎn)要的敘述。應(yīng)用層和會(huì)話層的定義適用于命令接口的所有應(yīng)用程序。在會(huì)話層之下的傳輸層和鏈接層在一定程度上要依賴于物理層的某些具體的執(zhí)行規(guī)范。除了對(duì)上述各層的詳細(xì)描述，DVB－CI規(guī)范還定義了物理接口以及模塊的物理實(shí)現(xiàn)的某些標(biāo)準(zhǔn)。</p><p>　　規(guī)范的層次化描述使得條件存取(CA)模塊周圍的一系列應(yīng)用程序與之的接口的設(shè)計(jì)更加靈

3、活。該規(guī)范還允許基于同一臺(tái)主機(jī)有多個(gè)條件存取模塊以及其相應(yīng)的應(yīng)用程序共存。</p><p>　　命令接口的基本分層結(jié)構(gòu)如圖4.1所示。圖中顯示了主機(jī)和一個(gè)模塊之間的通信連接，當(dāng)然主機(jī)可以和不止一個(gè)模塊建立通信連接，這些模塊可以直接或間接的和主機(jī)相連。 值得注意的是每一條傳輸鏈路在其對(duì)應(yīng)的模塊存在(被主機(jī)識(shí)別)的時(shí)候都要保持。 基于一條傳輸鏈路，模塊和主機(jī)之間可以建立多個(gè)針對(duì)不同資源的會(huì)話連接</p>

4、<p><b>　　1.2.物理實(shí)現(xiàn)</b></p><p>　　DVB－CI規(guī)范的底層描述包括具體實(shí)現(xiàn)的物理接口的和廣泛應(yīng)用于PC產(chǎn)業(yè)的PC卡標(biāo)準(zhǔn)保持著很好的兼容性?；谄渌涌诘奈锢韺?shí)現(xiàn)將會(huì)在以后被慢慢允許。</p><p>　　1.3.客戶端服務(wù)器</p><p>　　該通用接口的設(shè)計(jì)基于的基本原則是：客戶端利用服務(wù)器提供的資

5、源。而且，通過主機(jī)的管理，任何一個(gè)模塊的應(yīng)用程序和資源不僅可以供主機(jī)使用還可以供其他模塊使用。我們?cè)谶@兒用“資源”這個(gè)術(shù)語(yǔ)而不用用“服務(wù)”，主要是為了避免和電視，廣播領(lǐng)域比較常用的“服務(wù)”的說法相混淆。</p><p><b>　　1.4.數(shù)據(jù)譯碼</b></p><p>　　下文中會(huì)提到，通用接口邏輯上分為兩部分，傳送流接口和命令接口，此處簡(jiǎn)要闡述一下命令接口的數(shù)據(jù)

6、譯碼。命令接口間的數(shù)據(jù)通信是通過一系列的對(duì)象單元來完成的。這些對(duì)象單元采用來自于ASN.1語(yǔ)法編碼的“標(biāo)志－長(zhǎng)度－數(shù)據(jù)”的編碼形式。通常這是可以根據(jù)需要或是技術(shù)的發(fā)展更新而擴(kuò)充的。針對(duì)PC卡的實(shí)現(xiàn)有一特殊的傳輸層編碼，該編碼對(duì)其它的物理實(shí)現(xiàn)可能需要點(diǎn)改變。但，其語(yǔ)義應(yīng)當(dāng)是一樣的。</p><p><b>　　1.5.可擴(kuò)展性</b></p><p>　　通用接口的分層

7、模型的上面各層的設(shè)計(jì)充分考慮了可擴(kuò)展性。正像前面提到的，用于通信的對(duì)象單元所采用的“標(biāo)志－長(zhǎng)度－數(shù)據(jù)”編碼具有很好的可擴(kuò)展性，新的對(duì)象單元可以加進(jìn)來，現(xiàn)有的對(duì)象單元也可以作相應(yīng)的延展。此處不必?fù)?dān)心標(biāo)志編碼空間被用完，也不必?fù)?dān)心長(zhǎng)度編碼對(duì)接下來的數(shù)據(jù)編碼的限制。資源管理器(只可由主機(jī)提供的資源)提供了可擴(kuò)充主機(jī)提供的資源范圍的機(jī)制，該機(jī)制同樣可以適用于條件存取程序和其他的基于模塊的應(yīng)用程序。</p><p>　　1

8、.6.現(xiàn)有標(biāo)準(zhǔn)的合并</p><p>　　在該規(guī)范的起草過程中，適當(dāng)?shù)牟捎昧爽F(xiàn)有的一些標(biāo)準(zhǔn)。這種做法對(duì)規(guī)范更快的投入市場(chǎng)，投入使用大有益處，畢竟很多的標(biāo)準(zhǔn)規(guī)范的開發(fā)工作已經(jīng)完成了，適當(dāng)?shù)牟捎帽闶∪チ撕芏嘀貜?fù)的開發(fā)工作。這還使的該標(biāo)準(zhǔn)的實(shí)現(xiàn)更為方便，對(duì)于針對(duì)現(xiàn)有的標(biāo)準(zhǔn)已開發(fā)完畢的硬件和軟件可以在此再次使用，由此帶來了很多意想不到的益處。</p><p><b>　　2.體系結(jié)構(gòu)闡述

9、</b></p><p><b>　　2.1.概述</b></p><p>　　為了在主機(jī)上開出一個(gè)空間作為命令接口，現(xiàn)在先假定主機(jī)具有部分該邏輯結(jié)構(gòu)。這樣做使得由于主機(jī)設(shè)計(jì)者的選擇造成的影響降低到最小。圖 1.1顯示了一個(gè)典型的主機(jī)結(jié)構(gòu)和嵌入其中的接口的位置。此處要注意，一臺(tái)主機(jī)中也許有不止一個(gè)接口。</p><p>　　前面曾提

10、到過，該通用接口邏輯上由兩部分構(gòu)成，傳送流接口和命令接口。為了使整個(gè)接口的設(shè)計(jì)和實(shí)現(xiàn)更容易，兩接口都采用分層的體系。對(duì)所有的實(shí)現(xiàn)，上層的實(shí)現(xiàn)都是一樣的，底層的實(shí)現(xiàn)可有多種選擇。該規(guī)范當(dāng)前是基于PC卡標(biāo)準(zhǔn)的，基于其它物理接口的實(shí)現(xiàn)可能會(huì)在將來的版本中被加入。</p><p><b>　　2.2.傳送流接口</b></p><p>　　作為通用接口的兩個(gè)邏輯接口之一的傳送

11、流接口負(fù)責(zé)在輸入輸出兩個(gè)方向上傳送MPEG－2傳送包（即TS流）。當(dāng)主機(jī)選擇了某些服務(wù)(比如某電視臺(tái))，模塊將對(duì)經(jīng)傳送流接口送入其中的TS流進(jìn)行處理，那些攜帶選中的服務(wù)的數(shù)據(jù)包會(huì)被解密后輸出，其他的數(shù)據(jù)包將不予理會(huì)。應(yīng)當(dāng)注意的是在大多數(shù)情況下，模塊和與之關(guān)聯(lián)的物理層之間條件邏輯的保持在傳送流接口處存在一定的延遲。傳送流接口的分層模型如下圖所示。其中的傳輸層和所有上層在MPEG－2規(guī)范－ISO 13818中皆有定義和相應(yīng)的闡述。</

12、p><p><b>　　2.3.命令接口</b></p><p>　　通用接口的另一個(gè)邏輯接口命令接口負(fù)責(zé)主機(jī)和運(yùn)行在模塊上的應(yīng)用程序之間的通信。為了方便的實(shí)現(xiàn)一系列的功能，命令接口的通信協(xié)議同樣劃分為若干層次來闡述。這些功能包括：支持在同一臺(tái)主機(jī)上多個(gè)模塊共存，支持主機(jī)和模塊之間較復(fù)雜的傳輸通信，以及支持對(duì)主機(jī)提供給模塊使用的功能單元的擴(kuò)展。其分層模型如下圖所示：<

13、;/p><p>　　從圖中我們可以看到，接口所采用的物理接口－PC卡有其自己的各個(gè)層次，當(dāng)然PC卡的實(shí)現(xiàn)協(xié)議中已對(duì)其自身的物理層，鏈接層以及傳輸?shù)讓幼隽岁U述。如果以后要采用其它的物理實(shí)現(xiàn)接口（不局限于采用PC卡接口時(shí)），則基于物理接口的底層要發(fā)生一些變化，其他上層的變化將會(huì)收到一定程度的限制。PC卡的傳輸?shù)讓用枋隽讼⒔粨Q協(xié)議的具體細(xì)節(jié)以及消息的編碼格式，而通用接口中的傳輸層主要描述了傳輸層連接的驗(yàn)證，初始化以及終止

14、等操作。規(guī)范中對(duì)會(huì)話層，資源以及應(yīng)用層的定義及闡述對(duì)所有的物理實(shí)現(xiàn)都是適用的。</p><p>　　至于接口的應(yīng)用層，其設(shè)計(jì)也遵循一定的應(yīng)用層的語(yǔ)義。在應(yīng)用層上，主機(jī)還給運(yùn)行在模塊上的應(yīng)用程序提供了一些用于通信的資源，例如用戶接口交互界面，低速率的通信等等。這種設(shè)計(jì)體系使得模塊不僅僅執(zhí)行條件存取的任務(wù)還有其他任務(wù)都變得很容易。</p><p><b>　　2.4.. 簡(jiǎn)介<

15、/b></p><p>　　這部分主要對(duì)物理層上為了實(shí)現(xiàn)其上層的諸多功能及函數(shù)需要滿足的要求進(jìn)行闡述。當(dāng)然，盡管物理層應(yīng)用的規(guī)范定義了諸如主機(jī)和模塊間的機(jī)械和電氣連接模式，例如接口類型和大小，引腳數(shù)目，電壓值，阻抗以及電源限制，但具體實(shí)現(xiàn)時(shí)并不是必須遵循這些物理層的特性描述，不必過分拘泥于此。以下的物理層的特性要求和限制定義如下：</p><p><b>　　? 數(shù)據(jù)速率&

16、lt;/b></p><p><b>　　? 底層的初始化</b></p><p><b>　　? 多個(gè)模塊的使用</b></p><p>　　2.4.1. 數(shù)據(jù)連接和邏輯命令連接</p><p>　　物理層需要支持兩個(gè)獨(dú)立的邏輯上的連接，其一為傳送流，另一為主機(jī)和模塊間通信的命令。</

17、p><p>　　對(duì)于傳送流接口，應(yīng)當(dāng)可以接受包含傳送數(shù)據(jù)包的MPEG－2傳送流，無論傳送流是連續(xù)的還是由空數(shù)據(jù)隔開的。從接口中返回的傳送流因?yàn)榻?jīng)過CAM的處理，則有可能含有被解密過的傳送數(shù)據(jù)包。傳送流接口要遵循下面的一些限制。</p><p>　　1、 當(dāng)模塊是其中某一路傳送流的源頭時(shí)，其輸出應(yīng)當(dāng)遵循ISO/IEC 13818-9標(biāo)準(zhǔn)。</p><p>　　2、 如果模

18、塊作為數(shù)據(jù)包的一個(gè)源，那么輸入數(shù)據(jù)包連續(xù)的情況下，輸出數(shù)據(jù)包也應(yīng)連續(xù)。</p><p>　　3、 模塊應(yīng)當(dāng)在其處理輸入數(shù)據(jù)包時(shí)引入一個(gè)適當(dāng)?shù)难訒r(shí)，及采用以下公式的適用于任何字節(jié)的最大的延時(shí)變化。</p><p>　　tmdvmax = (n * TMCLKI) + (2 * TMCLKO).</p><p><b>　　和</b></p&

19、gt;<p>　　tmdvmax <= 1 microsecond when n = 0</p><p><b>　　此處：</b></p><p>　?。?）tmdv =模塊延時(shí)變化量</p><p>　?。?）n =存在于相應(yīng)的輸入數(shù)據(jù)包中的間隙的數(shù)目</p><p>　　（3）TMCLKI =輸

20、入數(shù)據(jù)的時(shí)鐘周期</p><p>　?。?）TMCLKO =輸出數(shù)據(jù)的時(shí)鐘周期</p><p>　?。?） 間隙指的是當(dāng)MIVAL信號(hào)無效時(shí)一個(gè)MCLKI的上升沿</p><p>　　（6） 此處強(qiáng)烈推薦所有的主機(jī)都輸出連續(xù)的傳送數(shù)據(jù)包</p><p>　?。?） 當(dāng)其執(zhí)行少于3個(gè)通用接口槽時(shí)，主機(jī)有可能輸出不連續(xù)的傳送數(shù)據(jù)包。</p&

21、gt;<p>　?。?） 數(shù)據(jù)包的間隙有可能變化很不定。</p><p>　　4、 主機(jī)應(yīng)當(dāng)設(shè)計(jì)成可支持Nm個(gè)模塊的。Nm為具體實(shí)現(xiàn)時(shí)主機(jī)最大所支持的CI槽的數(shù)目或是為16。當(dāng)然，隨著模塊的數(shù)目Nm的增加，輸入的傳送流的不穩(wěn)定和抖動(dòng)也會(huì)隨之更顯著些。最壞的情況有可能出現(xiàn)在一是從主機(jī)自身的輸入的數(shù)據(jù)流輸出后緊跟了Nm個(gè)模塊，一是從一個(gè)模塊輸入的ISO/IEC 13818－9復(fù)合數(shù)據(jù)流輸出后緊跟了（Nm

22、－1）個(gè)模塊。</p><p>　　5、所有的接口應(yīng)當(dāng)支持在連續(xù)的傳送流數(shù)據(jù)包的同步字節(jié)間的一周期至少為58 Mb/s的平均數(shù)據(jù)速率。</p><p>　　6、 所有的接口應(yīng)當(dāng)支持最小為111ns的字節(jié)傳送時(shí)鐘周期。</p><p>　　相應(yīng)的，命令接口應(yīng)當(dāng)能夠在兩個(gè)方向上傳遞由該規(guī)范定義的傳輸層部分的命令。其支持的每個(gè)方向上的數(shù)據(jù)速率至少為3.5Megabits/

23、sec.</p><p>　　2.4.2建立連接和斷開連接</p><p>　　無論主機(jī)是否處于加電狀態(tài)，其物理層接口應(yīng)當(dāng)能夠支持模塊任何時(shí)候的建立連接和斷開連接。而且，建立連接和斷開連接的行為不應(yīng)當(dāng)對(duì)主機(jī)或是模塊造成電氣上的損害，也不應(yīng)當(dāng)對(duì)模塊中存儲(chǔ)的可擦寫的數(shù)據(jù)有任何不當(dāng)?shù)母?。?dāng)模塊沒有插入的時(shí)候，傳送流接口應(yīng)當(dāng)設(shè)置一旁路繞過模塊以使得數(shù)據(jù)可以送入主機(jī)，此時(shí)，針對(duì)模塊的命令接口應(yīng)當(dāng)設(shè)

24、置為無效狀態(tài)。模塊一旦插入，主機(jī)將調(diào)用一底層的初始化流程來初始化模塊，以及相應(yīng)的接口。初始化工作要完成的有，執(zhí)行基于特定的物理層的底層連接程序，并判斷插入的模塊是否為所需要的DVB模式的模塊。如果上述步驟順利完成，主機(jī)將關(guān)閉本來的傳送流的連接，而后將構(gòu)建一個(gè)這樣的傳送流通路，即將模塊插入傳送流的通路中，使得傳送流通過模塊進(jìn)入主機(jī)。在這個(gè)過程中，一些傳送流的數(shù)據(jù)有可能丟失，不過這是可以想象同樣也可以接受的。同時(shí)，命令接口上需要建立一個(gè)傳輸

25、層上的連接，基于這個(gè)連接就可以開始完成應(yīng)用層上的初始化，初始化后，應(yīng)用層上的通信就可以繼續(xù)下去了。</p><p>　　如果物理層接口被用于其他的應(yīng)用程序而不是DVB模式的模塊連接，或是一個(gè)不是需要的模式的模塊插入主機(jī)，這些情況如果發(fā)生，那么不應(yīng)當(dāng)對(duì)主機(jī)或是模塊造成任何損害，而且主機(jī)也不試圖去完成初始化工作，即使它是一個(gè)DVB模式的模塊。此外，當(dāng)一個(gè)不能被識(shí)別的模塊插入時(shí)，主機(jī)應(yīng)當(dāng)通知用戶，告知這一情況。<

26、/p><p>　　模塊拔出后，主機(jī)應(yīng)采取相應(yīng)的措施將模塊從設(shè)置的傳送流通路中去除掉。和插入時(shí)一樣，該過程也會(huì)有一些傳送流數(shù)據(jù)丟失，這同樣是可以想象也可以接受的。同樣，此時(shí)主機(jī)應(yīng)當(dāng)關(guān)閉命令接口的連接。</p><p>　　以上所提及的都是基于單個(gè)模塊的，該規(guī)范同樣描述了基于多個(gè)模塊的情況。規(guī)范的應(yīng)用層對(duì)于在同一時(shí)間和主機(jī)相連接的模塊的數(shù)目沒有作限制。但，具體實(shí)現(xiàn)時(shí)選用的物理層接口和特定的主機(jī)設(shè)計(jì)

27、將會(huì)對(duì)此有一定的限制。盡管一個(gè)比較小型的主機(jī)有可能被設(shè)計(jì)成僅可提供一路連接，但物理層的規(guī)范必須允許可以有多個(gè)模塊同時(shí)和主機(jī)相連，并保持通信。在理想情況下，物理層的規(guī)范應(yīng)當(dāng)對(duì)模塊的數(shù)目不作限制，如果作了限制，那么它至少應(yīng)該可以支持15個(gè)模塊。</p><p>　　當(dāng)有多于一個(gè)模塊和主機(jī)相連時(shí)，傳送流接口的連接應(yīng)當(dāng)如下圖5.3所示，使得傳送流可以依次從每個(gè)模塊流經(jīng)。主機(jī)應(yīng)當(dāng)同時(shí)對(duì)每一個(gè)模塊維持一個(gè)獨(dú)立的命令接口的連接

28、，這樣，每一個(gè)模塊都可以獨(dú)立的處理其和主機(jī)之間的通信。但，主機(jī)必須采取某些措施保證當(dāng)插入其中的某一個(gè)模塊拔出后，其他模塊的命令接口的傳輸層連接不會(huì)受到干擾或是終止。</p><p>　　當(dāng)主機(jī)連接多個(gè)模塊時(shí)，主機(jī)應(yīng)能夠選擇其中合適的模塊來解密選中的服務(wù)（節(jié)目）。</p><p><b>　　2.5.運(yùn)作實(shí)例</b></p><p>　　為了舉例

29、說明上面描述的一系列的特性，現(xiàn)在考慮這樣一個(gè)實(shí)際運(yùn)作的例子：一個(gè)PC卡模塊插入某一主機(jī)。當(dāng)被插入的模塊檢測(cè)到接口的引腳的存在時(shí)，PC卡將會(huì)調(diào)用它自己的初始化程序?qū)ζ渥陨磉M(jìn)行初始化。之后，主機(jī)從模塊的屬性存儲(chǔ)空間中讀出PC卡的基本信息結(jié)構(gòu)（CIS）。該結(jié)構(gòu)中包含了模塊的底層的一些十分重要的配置信息，比如模塊要使用的PC卡的讀寫IO端口的基址，還有一些用于告知主機(jī)這是個(gè)DVB模式的模塊的信息等。若主機(jī)通過分析讀出的CIS得知這是個(gè)DVB－C

30、I接口的卡，那么主機(jī)將關(guān)閉傳送流接口的旁路連接，打開另一通路，允許傳送流數(shù)據(jù)從該通路流入模塊，經(jīng)模塊處理后送回主機(jī)。當(dāng)然，這個(gè)過程將會(huì)有一定的延時(shí)而且使得傳送流數(shù)據(jù)有短暫的間隙，但這一點(diǎn)是沒有辦法避免的。與此同時(shí)，物理層上的接口上的初始化程序開始運(yùn)行，用于主機(jī)和模塊之間商討用于通信的緩沖區(qū)的大小。物理層上的初始化程序結(jié)束后，主機(jī)將會(huì)調(diào)用其上層的初始化程序，這些對(duì)于所有的物理執(zhí)行都是通用的，其要做的首先是創(chuàng)建一個(gè)主機(jī)和模塊之間的傳輸層上的

31、連接。這些程序和其余的上層的初始化程序在本文檔的其他地方亦有描述。</p><p>　　上述例子中的初始化的流程對(duì)于基于其他的物理實(shí)現(xiàn)邏輯上應(yīng)很相似，當(dāng)然，其具體實(shí)現(xiàn)的細(xì)節(jié)上也會(huì)有些區(qū)別。</p><p>　　3.傳送流接口(TSI)</p><p>　　3.1.傳送流接口－物理層，鏈接層</p><p>　　傳送流接口的物理層和鏈接層都要依

32、賴于模塊的具體的物理執(zhí)行。</p><p>　　3.2.傳送流接口－傳輸層</p><p>　　傳送流接口的傳輸層和MPEG－2系統(tǒng)中的傳輸層的描述是一樣的。經(jīng)傳送流接口傳遞的數(shù)據(jù)需要在送入前封裝成MPEG－2傳送包。</p><p>　　整個(gè)復(fù)用的MPEG－2的TS流送入傳送流接口，經(jīng)處理后，部分或是全部被解密的TS流送出。如果數(shù)據(jù)沒有被加密，那么模塊將把其原樣輸

33、出。如果數(shù)據(jù)是加密過的，而且是主機(jī)選擇的服務(wù)對(duì)應(yīng)的數(shù)據(jù)，且模塊可以對(duì)該服務(wù)存取，那么模塊將把對(duì)應(yīng)的解密過的數(shù)據(jù)包輸出，并將其包頭中的傳送流加密控制標(biāo)準(zhǔn)位置為‘00’。</p><p>　　如果數(shù)據(jù)是在分組原始流的層次上加密的，那么模塊的處理流程和處理方法和上面所敘述的情況一樣，相應(yīng)的返回解密后的分組原始流，并將其包頭中的傳送流加密控制標(biāo)準(zhǔn)位置為‘00’。</p><p>　　上面提到的傳送

34、流數(shù)據(jù)包和分組原始流數(shù)據(jù)包都在MPEG－2系統(tǒng)規(guī)范[1]中有詳細(xì)的定義和闡述。</p><p>　　3.3.傳送流接口－所有上層</p><p>　　在DVB－CI規(guī)范中，沒有具體描述在傳送流接口之上的從原始數(shù)據(jù)流中分離的MPEG－2數(shù)據(jù)的分層和結(jié)構(gòu)，其詳細(xì)的說明可以在MPEG－2的規(guī)范中找到。當(dāng)然，該規(guī)范假定模塊可以直接從TS流中找到并提取出系統(tǒng)所需要的數(shù)據(jù)，比如ECM（訪問控制信息）和

35、EMM（訪問控制管理信息）信息，這些自然是要模塊來完成的。</p><p>　　1. DESIGN PHILOSOPHY</p><p>　　1.1. Layering</p><p>　　The specification is described in layers in order to accommodate future variations in imp

36、lementation. The application and session layers are defined for all applications of the common interface. The transport and link layers may be dependent on the physical layer used in a particular implementation. The phys

37、ical interface is defined within this specification and includes the complete physical specification of the module</p><p>　　The layering of the specification allows flexibility in the use of the interface fo

38、r a range of applications beyond CA. It also allows for multiple instances of CA processes to exist for the same host.</p><p>　　A representation of the basic layering on the command interface is shown in fig

39、ure 4.1. The host may set up transport connections with more than one module, which may be connected directly or indirectly to the host. Each connection is maintained while the module is present. Each module may manage a

40、 number of different sessions with the host.</p><p>　　1.2. Physical Implementation</p><p>　　The baseline specification includes the implementation on a physical interface compatible with the PC

41、Card standard used in the Personal Computer industry. Other physical implementations are allowed for in the future.</p><p>　　1.3. Client-Server</p><p>　　The interface is designed on the principl

42、e that applications, as clients, use resources provided by a server. The applications reside on a module and resources can be served either by the host or another module in a way managed by the host. The term ‘resources’

43、 has been used in preference to ‘services’ as that term is common in the broadcasting field for TV and radio services and there is a need to avoid confusion.</p><p>　　1.4. Coding of Data</p><p>

44、　　The communication of data across the command interface is defined in terms of objects. The objects are coded by means of a general Tag-Length-Value coding derived from that used to code ASN.1 syntax (see [2] and [3]).

45、This is generally extensible. There is a particular transport layer coding for the PC Card implementation but it may be different in other physical implementations. However the semantics would be identical.1.5. Extensib

46、ility</p><p>　　The higher layers have been designed to be extensible. As indicated above, the TLV coding used is extensible so that new objects can be added, and existing objects can be extended. There is no

47、 problem about running out of tag coding space, or length restrictions on the values. The Resource Manager resource provides a mechanism for extending the range of resources provided by hosts, both for CA purposes and fo

48、r other module-based applications.</p><p>　　1.6. Incorporation of Existing Standards</p><p>　　Existing standards have been used, where possible and appropriate, as building blocks for this speci

49、fication. This gives important time-to-market benefits, as all the standards development work has already been done. It also gives implementation benefits in that software and hardware already developed for existing stan

50、dards may be re-used here, with potential cost benefits.</p><p>　　2. DESCRIPTION AND ARCHITECTURE</p><p>　　2.1. Overview</p><p>　　A partial logical architecture has been assumed for

51、 a host in order to define the place in the host where the common interface can logically occur. The impact upon the freedom of choice for host designers in other respects has been minimized. Figure 1.1 shows a simplifie

52、d picture of typical host architecture and the positioning of the interface within it. Note that there can be more than one instance of the interface on a host.</p><p>　　The common interface consists of two

53、components, the Transport Stream Interface and the Command Interface. Both are layered to make the overall interface design and implementation easier. The upper layers are common to all implementations but alternative lo

54、wer-layer implementations are possible. This specification includes one based upon the PC Card standard but others may be included in future versions.</p><p>　　2.2. Transport Stream Interface</p><

55、p>　　The Transport Stream Interface carries MPEG-2 transport packets in both directions. If the module gives access to any services in the transport stream and those services have been selected by the host, then the pa

56、ckets carrying those services will be returned descrambled, and the other packets are not modified. On the Transport Stream Interface a constant delay through the module and any associated physical layer conditioning log

57、ic is preserved under most conditions (see section 5.4.2). The Tran</p><p>　　2.3. Command Interface</p><p>　　The Command Interface carries all the communication between the application(s) runnin

58、g in the module and the host. The communication protocols on this interface are defined in several layers in order to provide the necessary functionality. This functionality includes: the ability to support multiple modu

59、les on one host, the ability to support complex combinations of transaction between module and host, and an extensible set of functional primitives (objects) which allow the host to provide resou</p><p>　　Th

60、e PC Card implementation described in this specification has its own Physical and Link layers, and also its own Transport lower sublayer. A future different physical implementation is likely to differ in these layers and

61、 any difference will be restricted to these layers. The implementation-specific features of the Transport lower sublayer are limited to coding and specific details of the message exchange protocol, and the common upper s

62、ublayer defines identification, initiation and termination</p><p>　　As far as possible the Application layer of the interface has been designed to be free of specific application semantics. Communication is

63、in terms of resources, such as User Interface interaction, and low-speed communications, that the host provides to the application(s) running on a module. This strategy makes it very much easier to provide modules perfor

64、ming other tasks than just Conditional Access.</p><p>　　2.4.. Introduction</p><p>　　This section defines the requirements the Physical Layer must meet in order to carry out all the required func

65、tions. The following Physical Layer characteristics are not constrained here, although the specification for any Physical Layer used will define them: mechanical and electrical connection between the host and the module,

66、 i.e. socket type & size, number of pins, voltages, impedances, power limits. Requirements and limits on the following Physical Layer characteristics are defined here:</p><p>　　? Transport Stream and Com

67、mand logical connections</p><p>　　? data rates</p><p>　　? connection & disconnection behavior</p><p>　　? low-level initialization</p><p>　　? use of multiple modules

68、</p><p>　　2.4.1. Data and Command Logical Connections</p><p>　　The Physical Layer shall support independent both-way logical connections for the Transport Stream and for commands.</p><

69、;p>　　The Transport Stream Interface shall accept an MPEG-2 Transport Stream, consisting of a sequence of Transport Packets, either contiguously or separated by null data. The returned Transport Stream may have some of

70、 the incoming transport packets returned in a descrambled form. The Transport Stream Interface is subject to the following restrictions:</p><p>　　1、 When the module is the source of a transport stream its ou

71、tput shall comply with ISO/IEC 13818-9.</p><p>　　2、 Each output packet shall be contiguous if the module is the source of the packet or the input packet is contiguous.</p><p>　　3、 A module shall

72、 introduce a constant delay when processing an input transport packet, with a maximum delay</p><p>　　Variation (tmdv) applied to any byte given by the following formula:</p><p>　　tmdvmax = (n *

73、TMCLKI) + (2 * TMCLKO).</p><p><b>　　And</b></p><p>　　tmdvmax <= 1 microsecond when n = 0</p><p><b>　　where:</b></p><p>　　（1）tmdv = Module Del

74、ay Variation（2）n = Number of gaps present within the corresponding input transport packet</p><p>　　（3）TMCLKI = Input data clock period</p><p>　?。?）TMCLKO = Output data clock period</p>&

75、lt;p>　?。?） A `gap' is defined to be one MCLKI rising edge for which the MIVAL signal is inactive.</p><p>　?。?） All hosts are strongly recommended to output contiguous transport packets.</p><

76、;p>　　（7） Hosts may only output non-contiguous transport packets if they implement less than 3 common interface sockets.</p><p>　?。?） Inter packet gaps may vary considerably.</p><p>　　4、 A CI

77、compliant host should be designed to support Nm modules. Nm is the greater of the number of CI sockets implemented by the host or 16. It should tolerate the jitter resulting from Nm modules plus the jitter in the input t

78、ransport stream. The worst case jitter may arise either from the host's own input followed by Nm modules or an input module with a ISO/IEC 13818-9 compliant output followedby (Nm - 1) modules.</p><p>　　5

79、、 All interfaces shall support a data rate of at least 58 Mb/s averaged over the period between the sync bytes of successive transport packets.</p><p>　　6、 All interfaces shall support a minimum byte transfe

80、r clock period of 111 ns.</p><p>　　The Command Interface shall transfer commands as defined by the appropriate Transport Layer part of this specification in both directions. The data rate supported in each d

81、irection shall be at least 3.5 Megabits/sec.</p><p>　　2.4.2. Connection and Disconnection Behavior</p><p>　　The Physical layer shall support connection and disconnection of the module at any tim

82、e, whether the host is powered or not. Connection or disconnection shall not cause any electrical damage to either module or host, and shall not cause any spurious modification of stored non-volatile data in the module.

83、When a module is not connected the Transport Stream Interface shall bypass the module, and the Command Interface to that module shall be inactive. On connection of a module, the host shall initi</p><p>　　If

84、the Physical Layer is used in other applications than as a DVB-conformant module connection, and if a non-conformant module is connected to the host, no damage shall be caused to the module or the host, and the host shal

85、l not attempt to complete initialization as though it were a DVB-conformant module. Optionally, the host may signal to the user that an unrecognized module has been connected. </p><p>　　On disconnection of t

86、he module, the host shall remove the module from the Transport Stream data path. It is acceptable that some Transport Stream data is lost during this process. Also, the Command Interface connection shall be terminated by

87、 the host.</p><p>　　2.4.3. Multiple Modules</p><p>　　The Application Layer places no limit on the number of modules that may be connected to the host at any time. However, particular Physical La

88、yers and particular host design choices may do so. The Physical Layer specification must allow there to be several modules connected simultaneously to the host, even though a minimum host design may only provide for one

89、connection. Ideally the Physical Layer specification should place no hard limit on the number of modules, but if a limit is imposed, then i</p><p>　　Where there is provision for more than one module to be co

90、nnected, the Transport Stream Interface connection shall be daisy-chained through each module in turn, as illustrated in figure 5.3 below. The host shall maintain separate and simultaneous Command Interface connections t

91、o each module, so that transactions between host and module are treated independently for each module. When a module is unplugged the Command Interface transport layer connection to any other module shall not be disturbe

92、d </p><p>　　When several modules are connected to a host, the host should be able to select the module(s) relevant for the descrambling of the selected service(s).</p><p>　　2.5. Operational Exam

93、ple</p><p>　　To illustrate some of the features described above consider this example of the processes that occur when a PC Card module is plugged into a host. The PC Card initialization commences with sensi

94、ng of the module being plugged in by sense pins on the interface. The host then reads the Card information Structure residing in the Attribute Memory of the module. This contains low-level configuration information for t

95、he module, such as PC Card read and writes addresses used by the module, and indicates</p><p>　　The initialization process will be logically similar for other physical implementations though the details will

96、 differ.</p><p>　　3. TRANSPORT STREAM INTERFACE (TSI)</p><p>　　3.1. TSI - physical, link layers</p><p>　　These layers depend on the physical implementation of the module.</p>

97、<p>　　3.2. TSI - transport layer</p><p>　　The transport layer used is the same as the MPEG-2 System transport layer. Data traveling over the transport stream interface is organized in MPEG-2 Transport

98、Packets. The whole MPEG-2 multiplex is sent over this transport stream interface and is received back fully or partly descrambled. If the packet is not scrambled, the module returns it as is. If it is scrambled and the p

99、acket belongs to the selected service and the module can give access to that service, then the module returns the corresp</p><p>　　If scrambling is performed at Packetised Elementary Stream (PES) level, then

100、 the module reacts in the same way and under the same conditions as above, and returns the corresponding descrambled PES with the PES_scrambling_control flag set to '00'.</p><p>　　The transport packe

101、t and the PES packet are completely defined in the MPEG-2 System specification [1].</p><p>　　3.3. TSI - upper layers</p><p>　　Apart from the Packetised Elementary Stream, any layering or structu

102、re of the MPEG-2 data above the Transport Stream layer is not relevant to this specification. However the specification does assume that the module will find and extract certain data required for its operation, such as E