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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

18、塊作為數(shù)據(jù)包的一個源，那么輸入數(shù)據(jù)包連續(xù)的情況下，輸出數(shù)據(jù)包也應連續(xù)。</p><p>　　3、 模塊應當在其處理輸入數(shù)據(jù)包時引入一個適當?shù)难訒r，及采用以下公式的適用于任何字節(jié)的最大的延時變化。</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 =模塊延時變化量</p><p>　?。?）n =存在于相應的輸入數(shù)據(jù)包中的間隙的數(shù)目</p><p>　　（3）TMCLKI =輸

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

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

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

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

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

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

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

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

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

29、說明上面描述的一系列的特性，現(xiàn)在考慮這樣一個實際運作的例子：一個PC卡模塊插入某一主機。當被插入的模塊檢測到接口的引腳的存在時，PC卡將會調用它自己的初始化程序對其自身進行初始化。之后，主機從模塊的屬性存儲空間中讀出PC卡的基本信息結構（CIS）。該結構中包含了模塊的底層的一些十分重要的配置信息，比如模塊要使用的PC卡的讀寫IO端口的基址，還有一些用于告知主機這是個DVB模式的模塊的信息等。若主機通過分析讀出的CIS得知這是個DVB－C

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

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

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

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

34、流數(shù)據(jù)包和分組原始流數(shù)據(jù)包都在MPEG－2系統(tǒng)規(guī)范[1]中有詳細的定義和闡述。</p><p>　　3.3.傳送流接口－所有上層</p><p>　　在DVB－CI規(guī)范中，沒有具體描述在傳送流接口之上的從原始數(shù)據(jù)流中分離的MPEG－2數(shù)據(jù)的分層和結構，其詳細的說明可以在MPEG－2的規(guī)范中找到。當然，該規(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>　　（6） 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