ETSI TS 101 699-1999 Digital Video Broadcasting (DVB) Extensions to the Common Interface Specification (V1 1 1)《数字电视广播(DVB) 通用接口规范的扩展》.pdf

1、ETSI TS I01 699 1.1.1 (1999-11) Technical Specification Digital Video Broadcasting (DVB); Extensions to the Common Interface Specification STD-ETSI TS 101 b99-ENGL 1999 3400655 O4b8005 714 2 Reference DTWJTC-DVB-94 (fqcOicr.PDF) Keywords Broadcast, TV ETSI Postai address F-O6921 Sophia Antipolis Ced

2、ex - FRANCE Ofice address 650 Route des Lucioles -Sophia Antipolis Valbonne - FRANCE Siret N“ 348 623 562 00017 - NAF 742 C Assoclation a but non lucratif enregistre a la Sous-Pkfecture de Grasse (06) N“ 7803/88 Tel.: +33 4 92 94 42 O0 Fax: +33 4 93 65 47 16 Internet ETSI TS 101 699Vl.l.l (1999-11)

3、secrelarialetsi.fr Individual copies of this ETSI deliverable can be downloaded from http:lhww.eki.org If you find errors in the present document, send your comment to: ediioretsi.fr Important notice This ETSI deliverable may be made available in more than one electronic version or in print. in any

4、case of existing or perceived difference in contents behveen such versions, the reference version is the Portable Document Format (PDF). In case of dispute, the reference should be the printing on ETSI printers of the PDF version kept on a specific network drive within ETSI Secretariat. Copyright No

5、 fification No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media. O European Telecommunications Standards Institute 1999. O European Broadcasting Union 1999. Ail rights reserved. ETSI STDmETSI TS 101 b99

6、-ENGL 1999 3400855 04bB00b b50 m 3 ETSI TS 101 699 Vl.l.1 (1999-11) Contents intellectual Property Rights . 6 Foreword 6 1 Scope 7 1.1 From version 1 2 References . 9 3 Definitions and abbreviations 9 3.1 . * . 9 3.2 Abbreviations 10 4 Command interface - Resource Management . 11 . . . . . . . . Def

7、initions . . . . . . . . . . . . . . . . 4.1 4.2 4.2.1 4.2.1.1 4.2.1.2 4.2.1.3 4.2.1.4 4.2.1.5 4.2.1.6 4.2.1.7 4.2.1.8 4.3 4.3.1 4.3.2 4.3.2.1 4.3.2.2 4.3.2.3 4.3.2.4 4.3.2.5 4.3.3 4.3.3.1 4.3.3.2 Extending use of the resource ID type fie Establishing the Module ID Resource Manager - ver 11 12 13 Re

8、source Manager Protocol 13 Module ID establishment . . . . . . . . .13 Profile Enquiry . . 15 Profile Reply . . 15 Profile Changed 16 . 17 Resource profile establishment . = 2) resource-class resou rce-t ype resource-instance resource-version 1 / resource manager VI private resource coding else if (

9、resource-id-type = 3) - close session request: close a session to a resource; - Senddata: send an APDU on a session; - receivedata: receive an APDU on a session. All the functions shall return state information about the success or u-mvise of the operation. These -Actions are sufficient to provide c

10、ommunication to all resources, however particular host implementations may add extra functionality for reasons of performance or application simplicity. For example, there may be additionai functions to give direct access to the Resource Managers resource database, bypassing the Resource manager pro

11、tocol defmed in EN 50221 5. There may also be additional functions giving more direct access to host-based resources, or host-based resources may be used entirely independently of the Common Interface infrastructure. This is entirely the decision of the host designer. ETSI 21 ETSI TS 101 699 Vl.1.l

12、(1999-11) 5 Command interface - application information 5.1 Application information - version 2 5.1.1 New application types Version 2 of the application information resource (with resource ID 0x00020042) extends the set of application-tpe values that can be coded in the Application Info object. Tabl

13、e 11 defines the extended list. Table 11: Application type coding Ireserved I other values J Software-upgrade Modules that upload software to the host to upgrade the software in the host. No specific upload protocol is implied by this application type. Unclassified Modules that dont fall into any ot

14、her category may be “unclassified“. A new module application type is not usually allocated unless it is likely that a host will have more than one of a type installed. Audience metering modules are in this type. Network-interface Any type of input module (including both types A and B described in th

15、e present document) can present an application of Network-interface type. Accessibility -aids Modules that provide a facility to for those with some form of disability or impairment can use this application type. Audio description modules are in this type. 5.1.2 Unrecognized application type semanti

16、cs A host with a version 2 application information resource will understand the full set of application types listed in table 11. When presented with an unrecognized application type they shall treat them as Unclassified (type 06). 6 Command interface - additional resources 6. I Input modules Two ty

17、pes of input modules are defined A and BI. Type A is a shple, potentially low-cost module for delivery of broadcast services via DVB-C, DVB-S or DVB-T networks to hosts. Type B (see “Type B Input Modules“) supports these types of service and in addition allows other types of service and network to b

18、e delivered. ETSI STD.ETS1 TS LO1 b-ENGL L999 M 3400855 04b8025 502 111 22 ETSI TS 101 699 V1.l.l (1999-11) 6.1 .I Requirements for both input module types 6.1.1.1 TS format Where the input module delivers a Transport Stream (TS) to the host the TS itself and the data streams within it shall conform

19、 to the appropriate DVB specifications for a broadcast TS. In particular: - TS, PSI, Audio and Video data shall conform to ETR 154 2; - SI shall codorm to ETS 300 468 i and ETR 21 1 4. 6.1.1.2 TS control input modules shall continue to pass the host supplied TS fiom its Transport Stream input to its

20、 Transport Stream Output until the host opens a session to the control resource (e.g. Streaminput or ServiceGateway) of the module and sends a command requesting the module to deliver a stredservice (e.g. TuneTSReq or GetServiceReq). When the host requests the module to stop providing the streadserv

21、ice or closes the session to the control resource the TS output by the module shall revert to being that supplied by the host. This requirement does not preclude the module also including CA fwictions to descramble some or all of the data passing through the module. 6.1.1.3 Input module sessions Mod

22、ule ID derived resource instances Each input module shall have a Module ID (see “Extending use of the resource ID type field“) and use this ID in the resource ID of the resources that it provides. The resource ID for type A input modules is of the form 0000 O000 loo0 O000 0001 iiii ii00 0001. The re

23、source ID of a type BI input module1 has the form 0000 0000 1000 O001 0001 iiii ii00 0001. in each case iiiiii is the Module ID of the input module. Examde An example is illustrated in figure 14. Here 3 modules are inserted into a host. Two of these modules are input modules which present resource I

24、DS derived fiom their Module ID. Applications (either host or module resident) can open sessions to each instance of the input module. One module is a CA module which also has a Module ID, but isnt an input module, so doesnt present this type of resource. Navigator moale-id = 2 Appicaim session tore

25、sourceid= OxO08110C1 u Figure 4: Use of module IDS in input module resource presentation ETSI 23 ETSI TS 101 699 V1.l.l (1999-11) 6.1.2 Type A input modules 6.1.2.1 Introduction (informative) Module overview Figure 5 illustrates a possible type A module. Here a low performance microcontroller provid

26、es local intelligence within the module. The functions this is will support are: - user Set-up screens, for example, to allow the user to configure a satellite module with regard to the characteristics of the LNB NOTE 1: This feature is optional but is likely to be a practical requirement of all rea

27、l modules. - the ability to search for transport streams; - the ability to tune to transport streams as directed and then remained locked to them. T uner Demod Dernux - I- Figure 5: Iiiustratlve type A module Sofhvare model overview Module man machine interface All input modules shal support host-mo

28、dule communications from the Application Information resource. In particular if a module provides Set-up screens these shall be. accessible at least in response to Enter Menu message from the host. Hosts supporting input modules shall provide the user with a method to access the top level menu of ea

29、ch module. Inout Set-uE Depending on the delivery system connected to the module it may be appropriate for the module to provide Set-up screens, using the normal CI MMI methods, to assist installers Set-up the input to the host. For example, these screens might provide display of signal strength to

30、assist antenna pointing etc. Autoscan set-uo Depending on the delivery system connected to the module it may be appropriate for the module to provide Set-up screens to configure its autoscan process. See below. Host resuonsihiliiv The host has no responsibility in these area other than providing a m

31、ethod for the user to activate the top-level user interface screens of the module. Scanning for TS The host is responsible for initiating the frequency scanning process. This applies whether module autoscan feature is used or whether the host directs the scanning in a more hands-on way. ETSI 24 ETSI

32、 TS 101 699 Vl.l.1 (1999-11) Messages are based on delivent svstem descriDtors The dialogues between the host and the input module are in terms of the payload of DVB SI delivery system descriptors. For all currently defined DVB delivery systems (DVB-C, DVB-S - the module might be supplied pre-initia

33、lized with data on the characteristics of various network operators (e.g. Astra and Eutelsat) and various LNB/dishes. The module shall then ask the user to tell it about the circumstances in which it is deployed (e.g. an Acme steerable dish with a Bloggs Inc. “Mark III“ LNB); - the module might prov

34、ide an “advanced user“ Set-up. For example, this might provide the user with the ability to configure the method the module should use to select polarization on an LNB (e.g. LNB voltage, 22 kHz tone, DiSEqC, etc.) Module controlled scanning The host instructs the module to autoscan. Each time the mo

35、dule “fmds“ a TS it stops scanning and delivers TuningIdormationMessage (in data equivalent to a DVB SI delivery system descriptor) to the host. TuneTSReq can be used by the host to request that the TS is delivered to the host. So, the host has an opportunity to store the TuningIdormationMessage and

36、 to analyse the SI in the TS allowing it to extract service lists etc. Altemativeiy, the host might just store the TuningInformationMessage and return later to analyse the SI in more detail. The host can teil the module to continue the search. Eventually the module will report “search done“. When th

37、e module performs a search for TS the host should not assume that the module has access to the SI within each TS. The host is responsible for analysing the SI in each TS found. For example, in a terrestrial environment the host may be able to get the same TS on more than one frequency. The host is r

38、esponsible for deciding which set(s) of tuning information to store for each TS. NOTE 2: It might be useful to store more than one set of uning information for a TS to accommodate variable reception conditions! Host controlled scanning The host can also construct tuning information to instruct the m

39、odule to tune. In this way the host can control the search strategy. This gives the host an opportunity to take advantage of any special knowledge it might have. For example, it might “know“ about a “barker channel“ which provides reliable tuning information. This might allow the host to accelerate

40、tuning. Features of this type are enabled but not required by the present document. They are therefore an area for product differentiation. Hosts should be aware that the tuning information provided by the NITS on some delivery systems (e.g. SMATV and Terrestrial) can be unreliable. Storing tuning i

41、nformaiion Durmg the TS scanning process the host will potentially discover many TS and services. It is a host implementation choice to decide how many to remember, and the facilities provided to the user for selecting services. ETSI STD-ETSI TS 101 b99-ENGL A999 3400855 04b8028 211 M 25 ETSI TS 101

42、 699 Vl.l.1 (1999-11) The minimum information that host needs to retain to be able to return to a TS is the tuning information provided by the module and a reference to the module (to identie it in the case that there is more than one input module in the host). To be able to return to a service the

43、host shall at least store the original network ID, the service ID and a reference to the TS holding that service. The quantity of information involved here is likely to be quite modest. Optilly hosts might store additional information associated with each service such as the service name. TS new del

44、ivery systems with different modulation parameters. - ScanStartReq Instructs the module to start scanning for TS from some “star point“ of its own choosing. On receiving this the module may open a MMI session to request the user u configure parameters affecting the scope of the search. The host shal

45、l be able to let the module open a session to the MMI resource. Syntax No. of bits Mnemonic ScanNextReq () ScanNextReqTag 24 bsibf length-field() Syntax ScanAck () ScanAckTaa 24 8 11x8 8 ScanNextReqTag This 24 bit field with value x9F8003 identifies this message. ScanAck Reply from the module to the

46、 host when a broadcast signal is found, or the search is completed. The TS found is not delivered to the host unless a TuneTSReq is sent. Table 18: ScanAck syntax bslbf uimcbf bsibf uirnsbf length-fieido TSSiale Tuning InformationMessage Scan Progress I ScanAckTag This 24 bit field with value x9F800

47、4 identifies this message. No. of bits I Mnemonic I I 28 ETSI TS I01 699 V1.1.1 (1999-11) Syntax No. of bits Mnemonic TuneTSReq () TuneTSReqTag 24 bslbf length-field() Tuning Information Message 11 x8 bslbf 1 TSState This 8 bit field delivers an unsigned integer indicating the availability of the TS

48、. The coding of this field is as follows: - O indicates no signai found - when auto-scanning for TS O indicates that the auto-scan process has searched all possible frequencies; 1 to 255 provide a normalized representation of the signal quality (bigger is better). - TuningInformationMessage This 1 1

49、 byte field carries a delivery system dependent coding of the tuning information to re-acquire the TS found by the module. Syntax TuneTSAck () TuneTSAckTag lenglh-field0 TSCale The value of this field is not defined if the TSState is O. No. of bits Mnemonic 24 bslbf 8 uimcbf Scanprogress This 8 bit unsigned integer provides an approximate proportional indication of how far through the auto-scanning process the module is. The range of allowed values is O to 255. The value increases as the scan progresses. TuneTSReq Th