This file is raw output from pdftotext and may not be ideal for distribution. If you are a maintainer for Hackipedia, please sit down when you have time and clean this text version up. Source PDF: /mnt/main/jmc-storage/docs/DVB/ETSI 50221 Common Interface Spec for Conditional Access and other DVB Decoder Applications v1 (February 1997).pdf Like all conversions the text below should be fully readable as UTF-8 unicode text. --------------------------------------------------------------- EUROPEAN STANDARD EN 50221 NORME EUROPÉENNE EUROPÄISCHE NORM February 1997 UDC XXX Descriptors: TBD English Version Common Interface Specification for Conditional Access and other Digital Video Broadcasting Decoder Applications © 1996 Copyright reserved to DVB Members Ref No. EN 50221:1996 E Page 2 EN 50221:1997 Foreword This draft European Standard was prepared by the Technical Committee CENELEC TC 206, Broadcast Receiving Equipment. The text of the draft was submitted to the Unique Acceptance Procedure and was approved by CENELEC as EN 50221 on 1997-02-15. The following dates were fixed: - latest date by which the EN has to be implemented at national level by publication of an identical national standard or by endorsement (dop) 1997-10-01 - latest date by which national standards conflicting with the EN have to be withdrawn (dow) 1997-10-01 _________ Page 3 EN 50221:1997 Contents 1 Introduction and scope 4 2 Definitions 5 4 Design philosophy 5 4.1 Layering 6 4.2 Physical implementation 6 4.3 Client-server 6 4.4 Coding of data 6 4.5 Extensibility 6 4.6 Incorporation of existing standards 7 5 Description and architecture 7 5.1 Overview 7 5.2 Transport Stream Interface 7 5.3 Command Interface 7 5.4 Physical requirements 8 5.5 Operational example 10 6 Transport Stream Interface (TSI) 10 6.1 TSI - physical, link layers 10 6.2 TSI - transport layer 11 6.3 TSI - upper layers 11 7 Command interface - Transport & Session Layers 11 7.1 Generic Transport Layer 12 7.2 Session Layer 16 8 Command interface - Application layer 23 8.1 Introduction 23 8.2 Resources 23 8.3 Application protocol data units 24 8.4 System management resources 25 8.5 Host control and information resources 33 8.6 Man-machine interface resource 35 8.7 Communications resources 50 8.8 Resource identifiers and application object tags 54 Annex A : PC Card based physical layer (normative) 58 A.1 General description 58 A.2 Electrical interface 59 A.3 Link layer 61 A.4 Implementation-specific Transport sublayer over PC Card Interface 62 A.5 PC Card subset to be used by conformant Hosts and Modules 70 Annex B : Additional objects (informative) 78 B.1 Authentication 78 B.2 EBU Teletext Display Resource 79 B.3 Smart Card Reader Resource Class 80 B.4 DVB EPG Future Event Support Class 84 Page 4 EN 50221:1997 1 Introduction and scope A set of standards has been designed to be used in digital video broadcasting. These standards include source coding, channel coding, service information and decoder interfaces. In addition, a conditional access system is used when there is a need to control access to a broadcast service. It has been decided that the conditional access system need not be standardised, although a common scrambling algorithm is provided. It remains for broadcasters to access decoders with different conditional access systems and to ensure that they have choice of supply of such systems. A solution is to use the common scrambling algorithm and to execute solutions for access based on commercial agreements between operators. This solution can operate with single CA systems embedded in decoders. A second solution is based on a standardised interface between a module and a host where CA and more gen- erally defined proprietary functions may be implemented in the module. This solution also allows broadcasters to use modules containing solutions from different suppliers in the same broadcast system, thus increasing their choice and anti-piracy options. The scope of this document is to describe this common interface. The decoder, referred to in this specification as the host, includes those functions that are necessary to receive MPEG-2 video, audio and data in the clear. This specification defines the interface between the host and the scrambling and CA applications, which will operate on an external module. RGB Out RF In Tuner Demodulator MPEG Decoder Audio Out Remote Microprocessor Demultiplexer Host Scrambled Descrambled Common Interface Control Transport Stream Transport Stream Descrambler Microprocessor Module Smart Card (Optional) Figure 1: Example of single module in connection with host Two logical interfaces, to be included on the same physical interface, are defined. The first interface is the MPEG-2 Transport Stream. The link and physical layers are defined in this specification and the higher layers are defined in the MPEG-2 specifications. The second interface, the command interface, carries commands between the host and the module. Six layers are defined for this interface. An example of a single module in connection with a host is shown in figure 1. Page 5 EN 50221:1997 This specification only defines those aspects of the host that are required to completely specify the interactions across the interface. The specification assumes nothing about the host design except to define a set of services which are required of the host in order to allow the module to operate. The specification does not define the operation or functionality of a conditional access system application on the module. The applications which may be performed by a module communicating across the interface are not limited to conditional access or to those described in this specification. More than one module may be sup- ported concurrently. 2 Definitions For the purposes of this standard, the following definitons apply: application : An application runs in a module, communicating with the host, and provides facilities to the user over and above those provided directly by the host. An application may process the Transport Stream. host : A device where module(s) can be connected, for example : an IRD, a VCR, a PC ... module : A small device, not working by itself, designed to run specialised tasks in association with a host, for example : a conditional access sub system, an electronic program guide application module, or to provide resources required by an application but not provided directly by the host resource : A unit of functionality provided by the host for use by a module. A resource defines a set of objects exchanged between module and host by which the module uses the resource. service : A set of elementary streams offered to the user as a program. They are related by a common syn- chronisation. They are made of different data, i.e., video, audio, subtitles, other data... transport stream : MPEG-2 Transport Stream. 3 Normative references This European Standard incorporates by dated or undated reference, provisions from other publications. These normative references are cited at the appropriate places in the text and the publications are listed hereafter. For dated references, subsequent amendments to or revisions of any of these publications apply to this European Standard only when incorporated in it by amendment or revision. For undated references the latest edition of the publication referred to applies (including amendments). [1] ISO/IEC 13818-1 Information technology - Generic coding of moving pictures and associated audio information: Systems [2] ISO 8824 1987 Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1) [3] ISO 8825 1987 Open Systems Interconnection - Specification of basic encoding rules for Abstract Syntax Notation One (ASN.1) [4] ETS 300 468 Specification for Service Information (SI) in Digital Video Broadcasting (DVB) systems [5] ETR 162 Allocation of Service Information (SI) codes for Digital Video Broadcasting (DVB) Systems [6] PC Card Standard Volume 2 - Electrical Specification, February 1995, Personal Computer Memory Card International Association, Sunnyvale, California [7] PC Card Standard Volume 3 - Physical Specification, February 1995, Personal Computer Memory Card International Association, Sunnyvale, California [8] PC Card Standard Volume 4 - Metaformat Specification, February 1995, Personal Computer Memory Card International Association, Sunnyvale, California [9] prETS 300 743 DVB Subtitling Specification Page 6 EN 50221:1997 4 Design philosophy 4.1 Layering The specification is described in layers in order to accommodate future variations in implementation. 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 physical interface is defined within this specification and includes the complete physical specification of the module The layering of the specification allows flexibility in the use of the interface for a range of applications beyond CA. It also allows for multiple instance of CA processes to exist for the same host. A representation of the basic layering on the command interface is shown in figure 2. 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 number of different sessions with the host. Transport Appplication HOST Session Connection Process Figure 2: Layering on the command interface 4.2 Physical implementation The baseline specification includes the implementation on a physical interface compatible with the PC Card standard used in the Personal Computer industry. Other physical implementations are allowed for in the future. 4.3 Client-server The interface is designed on the principle 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’ 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. 4.4 Coding of data 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]). 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. 4.5 Extensibility 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 problem about running out of tag coding space, or length restrictions on the values. The Resource Manager resource provides a mecha- nism for extending the range of resources provided by hosts, both for CA purposes and for other module-based applications. Page 7 EN 50221:1997 4.6 Incorporation of existing standards Existing standards have been used, where possible and appropriate, as building blocks for this specification. 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 standards may be re-used here, with potential cost benefits. 5 Description and architecture 5.1 Overview A partial logical architecture has been assumed for 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 minimised. Figure 1 shows a simplified picture of a typical host architecture and the posi- tioning of the interface within it. Note that there can be more than one instance of the interface on a host. The common interface consists of two components, the Transport Stream Interface and the Command Inter- face. Both are layered to make the overall interface design and implementation easier. The upper layers are common to all implementations but alternative lower-layer implementations are possible. This specification includes one based upon the PC Card standard but others may be included in future versions. 5.2 Transport Stream Interface 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 pack- ets carrying those services will be returned descrambled, and the other packets are not modified. On the Trans- port Stream Interface a constant delay through the module and any associated physical layer conditioning logic is preserved under most conditions (see 5.4.2). The Transport Stream Interface layers are shown in figure 3 below. The Transport Layer and all upper layers are defined in the MPEG-2 specification - ISO 13818. Upper Layers Transport Layer PC Card Link Layer PC Card Physical Layer Figure 3: Transport Stream Interface Layers 5.3 Command Interface The Command Interface carries all the communication between the application(s) running 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 modules on one host, the ability to support complex combinations of transaction between module and host, and an extensible set of func- tional primitives (objects) which allow the host to provide resources to the module. The layering is shown in figure 4 below. The 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 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 sublayer defines identification, initiation and termination of Transport layer connections. The Session, Resource and Application layers are common to all physical implementations. Page 8 EN 50221:1997 Application Resources : User Interface Low-Speed System Optional extensions Communications Session Layer Generic Transport Sublayer PC Card Transport Sublayer PC Card Link Layer PC Card Physical Layer Figure 4: Command Interface Layers As far as possible the Application layer of the interface has been designed to be free of specific application semantics. Communication is in terms of resources, such as User Interface interaction, and low-speed commu- nications, that the host provides to the application(s) running on a module. This strategy makes it very much easier to provide modules performing other tasks than just Conditional Access. 5.4 Physical requirements 5.4.1 Introduction This clause defines the requirements the Physical Layer must meet in order to carry out all the required func- 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, i.e. socket type & size, number of pins, voltages, impedances, power limits. Requirements and limits on the following Physical Layer characteristics are defined here: • Transport Stream and Command logical connections; • data rates; • connection & disconnection behaviour; • low-level initialisation; • use of multiple modules. 5.4.2 Data and Command logical connections The Physical Layer shall support independent both-way logical connections for the Transport Stream and for commands. The Transport Stream Interface shall accept an MPEG-2 Transport Stream, consisting of a sequence of Trans- port Packets, either contiguously or separated by null data. The returned Transport Stream may have some of the incoming transport packets returned in a descrambled form. The Transport Stream Interface is subject to the following restrictions: 1 When the module is the source of a transport stream its output shall comply with ISO/IEC 13818-9. 2 Each output packet shall be contiguous if the module is the source of the packet or the input packet is contiguous. Page 9 EN 50221:1997 3 A module shall introduce a constant delay when processing an input transport packet, with a maximum delay variation (tmdv) applied to any byte given by the following formula: tmdvmax = (n * TMCLKI) + (2 * TMCLKO). and tmdvmax <= 1 microsecond when n = 0 where: tmdv = Module Delay Variation n = Number of gaps present within the corresponding input transport packet TMCLKI = Input data clock period TMCLKO = Output data clock period * A `gap' is defined to be one MCLKI rising edge for which the MIVAL signal is inactive. * All hosts are strongly recommended to output contiguous transport packets. * Hosts may only output non-contiguous transport packets if they implement less than 3 common interface sockets. * Inter packet gaps may vary considerably. 4 A CI 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 transport 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 followed by (Nm - 1) modules. 5 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. 6 All interfaces shall support a minimum byte transfer clock period of 111 ns. 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 direction shall be at least 3,5 Megabits/sec. 5.4.3 Connection and disconnection behaviour The Physical layer shall support connection and disconnection of the module at any time, 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. 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 initiate a low-level initialisation sequence with the module. This will carry out whatever low-level connection establishment procedures are used by the particular Physical Layer, and then establish that the module is a conformant DVB module. If successfully completed, the host shall establish the Transport Stream connection by inserting the module into the host's Transport Stream path. It is acceptable that some Transport Stream data is lost during this process. At the same time a Transport Layer connection shall be established on the Command Interface to allow Application Layer initialisation to take place and normal Application Layer communications to proceed. If 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 shall not attempt to complete initialisation as though it were a DVB-conformant module. Optionally, the host may signal to the user that an unrecognised module has been connected. On disconnection of the 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 connec- tion shall be terminated by the host. Page 10 EN 50221:1997 5.4.4 Multiple modules The Application Layer places no limit on the number of modules which may be connected to the host at any time. However, particular Physical Layers 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 connection. Ideally the Physical Layer specification should place no hard limit on the number of modules, but if a limit is imposed, then it shall be set at no less than 15 modules. Where there is provision for more than one module to be connected, the Transport Stream Interface connection shall be daisy-chained through each module in turn, as illustrated in figure 5 below. The host shall maintain separate and simultaneous Command Interface connections to 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 disturbed or terminated. 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). Host CA module 1 CA module 2 CA module n Figure 5: Transport Stream Interface chaining between modules 5.5 Operational example 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 initialisation commences with sensing 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 the module, such as PC Card read and write addresses used by the module, and indicates to the host that it is a DVB-conformant mod- ule. The host now turns off the Transport Stream Interface bypass link and allows the transport packets to flow through the module. This introduces a delay, and consequently a short gap in the Transport Stream data, but this is unavoidable. At the same time the physical layer interface initialisation process takes place to negotiate the buffer size to be used for communication. At this point the physical layer initialisation process is complete and the upper-layer initialisation process, common to all physical implementations, commences with the host creating a Transport Layer connection to the module. This process and the rest of the upper-layer initialisation process are described elsewhere in this document. The initialisation process will be logically similar for other physical implementations though the details will differ. 6 Transport Stream Interface (TSI) 6.1 TSI - physical, link layers These layers depend on the physical implementation of the module. Page 11 EN 50221:1997 6.2 TSI - transport layer The transport layer used is the same as the MPEG-2 System transport layer. Data travelling over the transport stream interface is organised in MPEG-2 Transport 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 packet belongs to the selected service and the module can give access to that service, then the module returns the corresponding descrambled packet with the trans- port_scrambling_control flag set to '00'. If scrambling is performed at Packetised Elementary Stream (PES) level, then 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'. The transport packet and the PES packet are completely defined in the MPEG-2 System specification [1]. 6.3 TSI - upper layers Apart from the Packetised Elementary Stream, any layering or structure of the MPEG-2 data above the Trans- port 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 ECM and EMM messages, directly from the Transport Stream. 7 Command Interface - Transport & Session Layers 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. Table 1: Length field used by all Protocol Data Units at Transport, Session & Application Layers Syntax No. of bits Mnemonic length_field() { size_indicator 1 bslbf if (size_indicator == 0) length_value 7 uimsbf else if (size_indicator == 1) { length_field_size 7 uimsbf for (i=0; imodule Topen_session_request '91' P <--- Topen_session_response '92' P ---> Tcreate_session '93' P ---> Tcreate_session_response '94' P <--- Tclose_session_request '95' P <---> Tclose_session_response '96' P <---> Tsession_number '90' P <---> Other values in the ranges 80-8F, 90-9F, A0-AF, B0-BF are reserved. 8 Command Interface - application layer 8.1 Introduction The application layer implements a set of protocols based upon the concept of a resource. A resource defines a unit of functionality which is available to applications running on a module. Each resource supports a set of objects and a protocol for interchanging them to use the resource. Communication with a resource is by means of a session created to that particular resource. This clause describes the minimum set of resources that all hosts conformant to this specification shall provide. Note that some resources in clause 8 have "DVB" as a prefix in their name. These make use of DVB-specific features which may not be present in all possible situations where this interface may be used. The DVB-prefixed resources must be provided in any DVB- compliant host and may optionally be provided in other hosts. Other optional resources are described in annex B to this specification and may be described in further annexes. 8.2 Resources 8.2.1 Introduction A resource may be provided by the host directly or it may reside in another module. A resource is identified by a resource identifier which comprises three components: resource class, resource type and resource version. Resource class defines a set of objects and a protocol for using them. Resource type defines distinct resource units within a class. All resource types within a class use the same objects and protocol but offer different services or are different instances of the same service. Resource version allows the host to identify the latest version (highest version number) of a resource where more than one of the same class and type are present. This allows updated or enhanced resources to be supplied on a module to supersede existing resources in the host or on another module. Resources with higher version numbers shall be backwards compatible with previ- ous versions, so that applications requesting a previous version will have a resource with expected behaviour. Resources are used by an application creating a session to a resource (see 7.2). By an initialisation process car- ried out by the Resource Manager the host will have identified all available resources, whether self-provided or provided on another module, and can complete the session to the appropriate place. Once the session has been created the application can then use the resource by an exchange of objects according to the defined protocol. Page 24 EN 50221:1997 An example of the use of the resource concept is the Low-Speed Communications resource class (see 8.7.1). This provides a common mechanism for using a serial communications link - typically a modem or a return channel on a cable system. Resource types are defined for different speeds of modem as identified by ITU-T recommendation numbers - e.g. V21, V.22, V.32bis. Most modern modems offer a range of speeds so that one modem may exhibit several resource types and the speed selection is made by creating a session to the particular resource type which offers it. 8.2.2 Resource identifier A resource identifier consists of 4 octets. The two most significant bits of the first octet indicate whether the resource is public or private and hence the structure of the remainder of the field. Values of 0,1 and 2 indicate a public resource. A value of 3 indicates a private resource. Public resource classes have values allocated in the range 1 to 49150, treating the resource_id_type field as the most significant part of resource_class. Value 0 is reserved. The maximum (all-ones) value of all fields is reserved. Private resources are identified by a private resource definer, that is the organisation that defines a private resource. Each private resource definer can define the structure and content of the pri- vate_resource_identity field in any way he chooses except that the maximum (all-ones) value is reserved. Table 15: resource_identifier coding Syntax No. of bits Mnemonic resource_identifier() { resource_id_type 2 uimsbf if (resource_id_type != 3) { resource_class 14 uimsbf resource_type 10 uimsbf resource_version 6 uimsbf } else { private_resource_definer 10 uimsbf private_resource_identity 20 uimsbf } } 8.2.3 Applications and resource providers These are the two types of application layer entity that can reside on a module. Applications make use of resources to perform tasks for the user of the host. Resource providers provide resources additional to those available directly in the host, or a newer version of a resource replacing one previously provided by the host, or on another module. To avoid deadlock problems and complexities of initialisation resource providers shall not be dependent on the presence of any other resources, except the Resource Manager, to provide the resources they offer. 8.3 Application Protocol Data Units 8.3.1 Introduction All protocols in the Application Layer use a common Application Protocol Data Unit (APDU) structure to send application data between module and host or between modules. The APDU structure is illustrated by figure 12 and table 16 below : Header Body apdu_tag length_field [data field] Figure 12 - APDU structure Page 25 EN 50221:1997 Table 16: APDU coding Syntax No. of bits Mnemonic APDU() { apdu_tag 24 uimsbf length_field() for (i=0;i= bytes_used Where bytes used is calculated by the algorithm shown below: bytes_used = 0; for (depth=0; depth < number_pixel_depth; depth++) { for (region=0; region < number of regions with pixel depth == depth; region++) { bytes_used += (region_width(region, depth) * region_height(region, depth)) / pixels_per_byte(depth); bytes_used += region_overhead(depth); } } character_table_byte In [4] character table selection for text fields (if different from the default) is indicated by the initial byte (or bytes) of the text field. The character table bytes are a non-ordered list of the character table selection bytes defined by [4]. All hosts must support input and output using the default (table 0) Latin Alphabet as defined by [4]. 8.6.3 Low-Level MMI Keypad objects The objects below are used in low level MMI mode only. 8.6.3.1 Keypad Control The application makes the assumption that the host has a keypad and that the user uses this keypad in the man machine dialogue. This keypad may be virtual : the user may enter commands or choices in another way (e.g. : voice) and the host translates these user actions into virtual keypresses for the application. Table 36: Keypad Control object coding Syntax No. of bits Mnemonic keypad_control() { keypad_control_tag 24 uimsbf length_field() keypad_control_cmd 8 uimsbf if (keypad_control_cmd == intercept_selected_keypress) { for (i=0;i /* bottom line */ < THE FIRST 3 MINUTES ARE FREE OF CHARGE > Page 50 EN 50221:1997 8.6.5.6 List This object is used to send a list of items to be displayed (e.g. during a consultation of the entitlements). It has exactly the same syntax as the Menu object, and is used in conjunction with the Menu_answ object. Table 51: List object coding Syntax No. of bits Mnemonic list () { list_tag 24 uimsbf length_field() item_nb 8 uimsbf TEXT() /* title text*/ TEXT() /* sub-title text */ TEXT() /* bottom text */ for (i=0;iapp Tprofile_enq 9F 80 10 resource mgr. <---> Tprofile 9F 80 11 resource mgr. <---> Tprofile_change 9F 80 12 resource mgr. <---> Tapplication_info_enq 9F 80 20 application info. ---> Tapplication_info 9F 80 21 application info. <--- Tenter_menu 9F 80 22 application info. ---> Tca_info_enq 9F 80 30 CA Support ---> Tca_info 9F 80 31 CA Support <--- Tca_pmt 9F 80 32 CA Support ---> Tca_pmt_reply 9F 80 33 CA Support <--- Ttune 9F 84 00 Host Control <--- Treplace 9F 84 01 Host Control <--- Tclear_replace 9F 84 02 Host Control <--- Task_release 9F 84 03 Host Control ---> Tdate_time_enq 9F 84 40 Date-time <--- Tdate_time 9F 84 41 Date-time ---> Tclose_mmi 9F 88 00 MMI ---> Tdisplay_control 9F 88 01 MMI <--- Tdisplay_reply 9F 88 02 MMI ---> Ttext-last 9F 88 03 MMI <--- Ttext-more 9F 88 04 MMI <--- Tkeypad_control 9F 88 05 MMI <--- Tkeypress 9F 88 06 MMI ---> Page 57 EN 50221:1997 Table 58: Application object tag values (end) apdu_tag tag value Resource Direction (hex) host<-->app Tenq 9F 88 07 MMI <--- Tansw 9F 88 08 MMI ---> Tmenu_last 9F 88 09 MMI <--- Tmenu_more 9F 88 0A MMI <--- Tmenu_answ 9F 88 0B MMI ---> Tlist_last 9F 88 0C MMI <--- Tlist_more 9F 88 0D MMI <--- Tsubtitle_segment_last 9F 88 0E MMI <--- Tsubtitle_segment_more 9F 88 0F MMI ---> Tdisplay_message 9F 88 10 MMI <--- Tscene_end_mark 9F 88 11 MMI <--- Tscene_done 9F 88 12 MMI <--- Tscene_control 9F 88 13 MMI ---> Tsubtitle_download_last 9F 88 14 MMI <--- Tsubtitle_download_more 9F 88 15 MMI ---> Tflush_download 9F 88 16 MMI <--- Tdownload_reply 9F 88 17 MMI <--- Tcomms_cmd 9F 8C 00 low-speed comms. <--- Tconnection_descriptor 9F 8C 01 low-speed comms. <--- Tcomms_reply 9F 8C 02 low-speed comms. ---> Tcomms_send_last 9F 8C 03 low-speed comms. <--- Tcomms_send_more 9F 8C 04 low-speed comms. <--- Tcomms_rcv_last 9F 8C 05 low-speed comms. ---> Tcomms_rcv_more 9F 8C 06 low-speed comms. ---> Page 58 EN 50221:1997 Annex A (normative) PC card-based physical layer A.1 General description The physical interface between module and host and the form-factor and mechanical characteristics of the module are a variant of the PC Card specification [6], [7], [8]. Figure A.1 shows a typical module architecture. PC Card Interface Host Module Transport Stream Input Descrambler Filter/Extract Transport Stream Output Internal Bus Control Address Command Interface Data ROM/ RAM/ Security CPU EPROM NVRAM Processor Figure A.1: Typical CA module architecture showing the position of the PC Card interface A.1.1 PC Card interface It is described in the following subclauses. It is a variant of the PC Card specification. The variant provides the following facilities : • Transport Stream Interface for MPEG-2 data consisting of an 8-bit parallel input to the module and a separate 8-bit parallel output, together with control signals and a byte clock. • Command Interface for command traffic between host and module consisting of an 8-bit bi-directional data bus together with address and control signals. • Attribute Memory Interface to allow the host to read the Card Information Structure on the module and to configure the module into its normal operating mode. Page 59 EN 50221:1997 A.1.2 Descrambler The descrambler selectively descrambles transport packets within the Transport Stream. It may also descramble at the Packetised Elementary Stream level if configured to do so. It is configured by particular values (Control Words) loaded into it periodically by the CPU. Since the descrambler may have to descramble several services simultaneously it would normally maintain a list of Control Words associated with the PIDs required to be descrambled. The descrambler will not attempt to descramble any Transport Packets where the trans- port_scrambling_control flag is set to '00', even if the PID matches with a current control word. This same constraint applies with regard to the PES_scrambling_control flag if PES level scrambling is used. A.1.3 Filter/Extract Some of the data required by a CA system to operate successfully is carried within the Transport Stream. The Filter/Extract circuit is configured to extract the data required by the CA module for the programmes/services it has been asked to descramble. A.1.4 CPU This runs the CA process and orchestrates the flow of data within the module and between module and host to carry out the CA functions. A.1.5 ROM/EPROM and RAM/NVRAM These contain the program and data implementing the CA process. The ROM may also contain the Attribute Memory which is a necessary feature of the PC Card initialisation process. A.1.6 Security processor This is a separate processor, manufactured to much higher security requirements than the main CPU, which carries out security functions, such as decryption and also stores secure information, such as keys and entitle- ments. It may be embedded within the PC Card module or it may reside on an associated detachable module, such as a smart card. A.2 Electrical interface The Electrical characteristics of this interface comply with the specified variant of Version 2.1 of the PC Card standard - see A.5. A.2.1 Transport Stream Interface MPEG-2 data from the host is presented to the module on an 8-bit data bus MDI0 to MDI7. In addition there are two control signals, MISTRT and MIVAL. These are clocked into the module by a clock signal MCLK. The MPEG-2 data returns from the module on another 8-bit data bus MDO0 to MDO7. Similarly there are two control signals MOSTRT and MOVAL. A detailed description of the operation of this interface is given in A.5. A.2.2 Command Interface A.2.2.1. Hardware interface description The hardware interface consists of several registers occupying 4 bytes of address space on the PC Card interface. Byte offset 0 is the Data Register. This is read to transfer data from the module and written to transfer data to the module. At byte offset 1 are the Control Register and Status Register. Reading at offset 1 reads the Status Register, and writing at offset 1 writes to the Control Register. The Size Register is a 16-bit register at byte offsets 2 and 3. Offset 2 is the Least Significant half and offset 3 the Most Significant half. The register map is shown in figure A.2.1. Only two address lines, A0 and A1, are decoded by the interface. The host designer is free to place this block of 4 bytes anywhere within his own address space by suitable decoding or mapping of other address lines within the host. Page 60 EN 50221:1997 Offset Register 0 Data Register 1 Command/Status Register 2 Size Register (LS) 3 Size Register (MS) Figure A.2: Map of Hardware Interface Registers The Status Register looks like this: bit 7 6 5 4 3 2 1 0 DA FR R R R R WE RE DA (Data Available) is set to '1' when the module has some data to send to the host. FR (Free) is set to '1' when the module is free to accept data from the host, and at the conclusion of a Reset cycle initiated by either a module hardware reset, or by the RS command.. R indicates reserved bits. They read as zero. WE (Write Error) and RE (Read Error) are used to indicate length errors in read or write operations. The Command Register looks like this: bit 7 6 5 4 3 2 1 0 R R R R RS SR SW HC RS (Reset) is set to '1' to reset the interface. It does not reset the whole module. SR (Size Read) is set to '1' to ask the module to provide its maximum buffer size. It is reset to '0' by the host after the data transfer. SW (Size Write) is set to '1' to tell the module what buffer size to use. It is reset to '0' by the host after the data transfer. HC (Host Control) is set to '1' by the host before starting a data write sequence. It is reset to '0' by the host after the data transfer. R indicates reserved bits. They shall always be written as zero. A.2.2.1.1 Initialisation During module initialisation, and at other times if there is an error, the host needs to be able to reset the interface. It does this by writing a '1' to the RS bit in the Control Register. The module clears out any data in its data transfer buffer(s) and sets the interface so that it can perform the buffer size negotiation protocol. The module signals that the Reset operation is complete by setting the FR bit to ‘ . 1’ After initialisation the host must find out the internal buffer size of the module by operating the buffer size negotiation protocol. Neither host nor module may use the interface for transferring data until this protocol has completed. The host starts the negotiation by writing a '1' to the SR bit in the Control Register, waiting for the DA bit to be set and then reading the buffer size by a module to host transfer operation as described below. At the end of the transfer operation the host resets the SR bit to '0'. The data returned will be 2 bytes with the most significant byte first. Modules shall support a minimum buffer size of 16 bytes. The maximum is set by the limitation of the Size Register (65535 bytes). Similarly the host may have a buffer size limitation that it imposes. The host shall support a minimum buffer size of 256 bytes but it can be up to 65535 bytes. After reading the buffer size the module can support, the host takes the lower of its own buffer size and the module buffer size. This will be the buffer size used for all subsequent data transfers between host and module. The host now tells the module to use this buffer size by writing a ‘ to the SW bit in the Command Register, 1’ waiting until the FR bit is set and then writing the size as 2 bytes of data, most significant byte first, using the host to module transfer operation described below. At the end of the transfer the host sets the SW bit to '0'. The negotiated buffer size applies to both directions of data flow, even in double buffer implementations. Page 61 EN 50221:1997 A.2.2.1.2 Host to Module Transfers The host sets the HC bit and then tests the FR bit. If FR is ‘ then the interface is busy and the host must reset 0’ HC and wait a period before repeating the test. If FR is ‘ then the host writes the number of bytes it wishes to 1’ send to the module into the Size register and then writes that number of data bytes to the Data register. This multiple write shall not be interrupted by any other operations on the interface except for reads of the Status Register. When the first byte is written the module sets WE to ‘ and sets FR to '0'. During the transfer the 1’ WE bit remains at ‘ until the last byte is written, at which point it is set to ‘ . If any further bytes are written 1’ 0’ then the WE bit is set to ‘ . At the end of the transfer the host shall reset the HC bit by writing ‘ to it. 1’ 0’ The host must test the DA bit before initiating the host-to-module cycle above in order to avoid deadlock in the case of a single buffer implementation in the module. This C code fragment illustrates the host side process: if (Status_Reg & 0x80) /* go to module-to-host transfer (see below) */ Command_Reg = 0x01; if (Status_Reg & 0x40) { Size_Reg[0] = bsize & 0xFF; Size_Reg[1] = bsize >> 8; for (i=0; imodule TSB '80' P <---- TRCV '81' P ----> Tcreate_t_c '82' P ----> Tc_t_c_reply '83' P <---- Tdelete_t_c '84' P <----> Td_t_c_reply '85' P <----> Trequest_t_c '86' P <---- Tnew_t_c '87' P ----> Tt_c_error '88' P ----> Tdata_last 'A0' C <----> Tdata_more 'A1' C <----> A.5 PC Card subset to be used by conformant Hosts and Modules A.5.1 Objectives The objective of this clause is to capture all the necessary information required to interpret the PC Card speci- fication [6], [7], [8] and make the appropriate choices to successfully develop a minimally conformant host and module. A.5.2 Introduction This clause defines the minimum subset of the PC Card specification which is to be used by both hosts and modules. Nothing in this clause prevents hosts from implementing more than the minimum subset, for example to support other types of PC Card devices. However, all modules shall be implemented such that they will operate correctly in hosts conforming to the minimum subset specification described here. This clause makes extensive reference to the PC Card specification documents [6], [7], [8]. A.5.3 Terminology In several places in this clause hexadecimal numbers are shown. The format used is the hexadecimal number, using upper case A to F for the final 6 digits, followed by the lower case 'h' - for example 7FFh. Page 71 EN 50221:1997 A.5.4 Physical Specification A.5.4.1 Card dimensions The host shall accept both Type 1 and Type II PC Cards, cf. clause 3 in [7]. Host support for Type III cards is optional. A.5.4.2 Connector Clause 4 in [7] applies. A.5.4.3 PC Card Guidance Clause 5 in [7] applies. A.5.4.4 Grounding/EMI Clips Clause 6 in [7] applies. A.5.4.5 Connector Reliability Clause 7 in [7] applies. A.5.4.6 Connector Durability Subclause 8.2 (Harsh Environment) in [7] applies. A.5.4.7 PC Card Environmental Clause 9 in [7] applies. With regard to temperature specification the module shall operate at up to 55 deg Celsius, as defined in the PC Card Specification. This is primarily to enable reliable battery operation in modules. In order to facilitate this operating environment limit the host shall limit the temperature rise between the ambient environment outside the host and the ambient environment surrounding the module to 15 deg Celsius when the module is dissipating its full rated power. Note that this may not guarantee that the 55 deg Celsius limit for modules is met in all environmental conditions otherwise acceptable to the host. Module designers shall minimise the risk of misoperation of modules containing batteries by following the recommendations in the PC Card standard on battery placement and host designers should be aware of these recommendations when doing host thermal design. Note that designers will also have to conform to any relevant mandatory safety specifications with regard to module temperature. A.5.5 Electrical Specification A Common Interface module is implemented as a variant of the 16-bit PC Card Electrical Interface (Clause 4 of [6]). The command interface uses the least significant byte of the data bus, together with the lower part of the address bus (A0-A14), and appropriate control signals. The command interface operates in I/O interface mode. The upper address lines (A15-A25), the most significant half of the data bus (D8-D15), and certain other control signals are redefined for the this interface variant. When first plugged in and before configuration, a module conforming to this interface specification shall behave as a Memory-Only device with the following restrictions: a) Signals D8-D15 shall remain in the high-impedance state. b) 16-bit read and write modes are not available. CE2# shall be ignored and interpreted by the module as always being in the ‘High’state. Page 72 EN 50221:1997 c) Address lines A15-A25 shall not be available for use as address lines. The maximum address space available on the module is limited to 32768 bytes (16384 bytes of Attribute Memory as it only appears at even addresses). d) Signals BVD1 and BVD2 shall remain ‘High’. A.5.5.1 Card Type Detection Clause 3 of [6] applies. Hosts shall support 5v working and may optionally support 3.3v working. In the latter case hosts shall use the detection mechanisms described in [6] to determine module operating voltage. Hosts shall follow the rules for type of socket according to whether they provide 3.3v working - Subclause 3.2 of [6]. Hosts need not support the detection mechanisms for CardBus PC Cards, but may optionally do so - Subclause 3.3 of [6]. A.5.5.2 Pin assignments When in memory card mode, just after reset, the pin assignments in the left hand column of Tables 4-1 and 4-2 of [6] are used. When the module is configured as the Common Interface variant during the initialisation proc- ess, the following reassignments are made: The pins carrying signals A15-A25, D8-D15, BVD1, BVD2 and VS2# are used to provide high-speed input and output buses for the MPEG-2 multiplex data. All other pins retain their assignment as an I/O & Memory Card interface, except that IOIS16# is never asserted and CE2# is ignored. The pin assignments for the custom interface are defined in table A.17 below. Page 73 EN 50221:1997 Table A.17: Pin assignments for this PC CARD variant Pin Signal I/O Function Pin Signal I/O Function 1 GND Ground 35 GND Ground 2 D3 I/O Data bit 3 36 CD1# O Card detect 1 3 D4 I/O Data bit 4 37 MDO3 O MP data out 3 4 D5 I/O Data bit 5 38 MDO4 O MP data out 4 5 D6 I/O Data bit 6 39 MDO5 O MP data out 5 6 D7 I/O Data bit 7 40 MDO6 O MP data out 6 7 CE1# I Card enable 1 41 MDO7 O MP data out 7 8 A10 I Address bit 10 42 CE2# I Card enable 2 9 OE# I Output enable 43 VS1# O Voltage sense 1 10 A11 I Address bit 11 44 IORD# I I/O read 11 A9 I Address bit 9 45 IOWR# I I/O write 12 A8 I Address bit 8 46 MISTRT I MP in start 13 A13 I Address bit 13 47 MDI0 I MP data in 0 14 A14 I Address bit 14 48 MDI1 I MP data in 1 15 WE# I Write enable 49 MDI2 I MP data in 2 16 IREQ# O Interrupt request 50 MDI3 I MP data in 3 17 VCC Vcc 51 VCC Vcc 18 VPP1 Program voltage 1 52 VPP2 Program voltage 2 19 MIVAL I MP in valid 53 MDI4 I MP data in 4 20 MCLKI I MPEG-2 Clock input 54 MDI5 I MP data in 5 21 A12 I Address bit 12 55 MDI6 I MP data in 6 22 A7 I Address bit 7 56 MDI7 I MP data in 7 23 A6 I Address bit 6 57 MCLKO O MPEG-2 Clock output 24 A5 I Address bit 5 58 RESET I Card reset 25 A4 I Address bit 4 59 WAIT# O Extend bus cycle 26 A3 I Address bit 3 60 INPACK# O Input port ack 27 A2 I Address bit 2 61 REG# I Register select 28 A1 I Address bit 1 62 MOVAL O MP out valid 29 A0 I Address bit 0 63 MOSTRT O MP out start 30 D0 I/O Data bit 0 64 MDO0 O MP data out 0 31 D1 I/O Data bit 1 65 MDO1 O MP data out 1 32 D2 I/O Data bit 2 66 MDO2 O MP data out 2 33 IOIS16# 16bit I/O (always high) 67 CD2# O Card detect 2 34 GND Ground 68 GND Ground A.5.5.3 16-bit PC Card features Subclause 4.3 in [6] applies. It is recommended that at least 12 bits of address be decoded on the module (4096 bytes) during memory accesses. A lower number of bits, as specified in the CIS, shall be decoded during I/O accesses. A.5.5.4 Signal Description Subclauses 4.4, 4.6 and 4.7 of [6] apply. The following information also amends the specification: MPEG-2 transport stream interface input and output buses are provided (MDI0-7, MDO0-7). Control signals MCLKI, MCLKO, MISTRT, MIVAL, MOSTRT, MOVAL are also provided. MCLKI runs at the rate at which bytes are offered to the module on MDI0-7. MCLKO runs at the rate at which bytes are offered by the module on MDO0-7. For modules which pass the transport stream through, then MCLKO will in most cases be a buffered version of MCLKI with a small delay. For modules which originate data, for example a detachable front-end or a network connection, then MCLKO may be derived from that data source. Figure A.18 shows the relative timing relationship of the data signals associated with the MPEG-2 Page 74 EN 50221:1997 transport stream interface and MCLKI, MCLKO, and Table A.18 gives limits to these timing relationships. Note that the specification for output timing limits can normally be met easily by generating the output from the falling edge of MCLKO. There is no specification for delay between MCLKI and MCLKO. In the case of a module providing its own MCLKO, they may not even be the same frequency. Hosts shall daisy-chain MCLKO from one module to MCLKI of the next module where they support multiple Common Interface sockets, and the transport stream clock reference for the rest of the host shall be derived from MCLKO of the final socket in the chain. Both MCLKI and MCLKO shall be continuous. It is not intended that burst clocking should be employed. Bursty data is handled by the appropriate use of MIVAL and MOVAL. MISTRT is valid during the first byte of each transport packet on MDI0-7. The edge timing of this signal shall be the same as for MDI0-7. tclkp tclkh MCLKI tsu th tclkl MDI, MISTRT, MIVAL tclkp tclkh MCLKO tclkl tosu toh MDO, MOSTRT, MOVAL Figure A.18: Timing relationships for Transport Stream Interface signals Page 75 EN 50221:1997 Table A.18: Timing relationship limits Item Symbol Min Max Clock period tclkp 111 ns Clock High time tclkh 40 ns Clock Low time tclkl 40 ns Input Data Setup tsu 15 ns Input Data Hold th 10 ns Output Data Setup tosu 20 ns Output Data Hold toh 15 ns MIVAL indicates valid data bytes on MDI0-7. All bytes of a transport packet may be consecutive in time, in which case MIVAL will be at logic 1 for the whole of the duration of the transport packet. However certain clocking strategies adopted in hosts may require there to be gaps of one or more byte times between some con- secutive bytes within and/or between transport packets. In this case MIVAL will go to logic 0 for one or more byte times to indicate data bytes which should be ignored. MDO0-7 is the output bus for the MPEG-2 transport stream interface. Where MCLKO is derived from MCLKI, and correspondingly the data on MDO0-7 is a delayed and possibly descrambled version of the data on MDI0-7, then the timing relationship between the input data and the output data shall be governed by the rules in 5.4.2 of this specification. MOSTRT is valid during the first byte of an output transport packet. MOVAL indicates the validity of bytes on MDO0-7 in a similar manner to MIVAL. MOVAL may not neces- sarily be a time-delayed version of MIVAL (see 5.4.2 of this specification). Support for Interrupt Requests by hosts as defined in subclause 4.4.7 of [6] is optional. This function shall not be used by CA modules. Interrupt support by modules may be added to a future version of the specification and host designers may wish to note this. Whenever the module responds to an I/O operation it shall assert INPACK# (see subclause 4.4.22 of [6]). A.5.5.5 Memory function Subclause 4.6 in [6] applies. Attribute Memory function support by hosts is mandatory. Note that Attribute Memory is byte-wide - Attribute Memory data only appears on data lines D7-D0. Also consecutive bytes are at consecutive even addresses (0, 2, 4, etc.). Note also that Attribute memory must still be able to be read or written to even when the module is configured to operate with the DVB Common Interface. Common Memory function support in the host is optional. Modules shall not use Common Memory. A.5.5.6 Timing Functions Subclause 4.7 in [6] applies. Attribute Memory support by hosts is mandatory. Common Memory support in the host is optional. A.5.5.7 Electrical interface Subclause 4.9 in [6] applies. Support by hosts for overlapping I/O address windows as defined in subclause 4.9.3.2 is optional. Modules shall use an independent I/O address window 4 bytes in size. A.5.5.8 Card detect Subclause 4.10 in [6] applies. Page 76 EN 50221:1997 A.5.5.9 Battery Voltage Detect Modules shall not implement or require this function. Support for it by hosts is optional. A.5.5.10 Power-up and power-down Subclause 4.12 in [6] applies, including the average current during configuration specification. The module shall specify its operating current in the CIS (subclause 3.3.2 of [8]). Each module shall neither consume nor dissipate more than 1.5 watts. Additionally the power supply current to each module (sum of Vcc current and Vpp current) shall not exceed 300mA long term, and the short-term peak current is limited to 500mA for no more than 1ms. Hosts need not support alternate values of Vpp. If they do not it shall be the same voltage as Vcc. A.5.5.11 I/O Function Subclause 4.13 in [6] applies excepting that modules shall only use 8-bit read and write modes. A.5.5.12 Function Configuration Subclause 4.14 in [6] applies. Modules shall support only the Configuration Option Register. Host support for registers other than the Configuration Option Register is optional. A.5.5.13 Card Configuration Subclauses 4.15 and 4.15.1 in [6] apply. A.5.6 Metaformat Specification This subclause defines the minimum set of tuples that a Common Interface module must have in its Card Infor- mation Structure. This is also the minimum set that a host needs to be able to recognise. Only clauses 1, 2 and 3 of [8] apply. The following tuples are the minimum set used by Common Interface modules and are the only set required to be recognised by hosts. The tuple chain formed by them must be the first one in Attribute Memory, in this order, though it may be followed by others, not required to be recognised by hosts. The host must take account of the possibility that these may be followed by other tuples. The chain shall be terminated by a CISTPL_NOLINK tuple. All subclause references here are to subclauses in [8]. 1 CISTPL_DEVICE_OA: Coded according to subclauses 3.2.3 & 3.2.4. 2 CISTPL_DEVICE_OC: Coded according to subclauses 3.2.3 & 3.2.4. 3 CISTPL_VERS_1: TPLLV1_MAJOR = 05h; TPLLV1_MINOR = 00h; other fields defined by module manufacturer according to subclause 3.2.10. 4 CISTPL_MANFID: Defined by manufacturer according to subclause 3.2.9. 5 CISTPL_CONFIG: Defined by manufacturer according to subclause 3.3.4. The Configuration Register Base Address shall not be greater than FFEh. There shall be one subtuple in the TPCC_SBTPL field - see subclause 3.3.4.5. In this subtuple STCI_IFN shall contain the ID number 0241h issued by PCMCIA for this class of module, and STCI_STR shall contain the single string 'DVB_CI_V1.00'. The value of STCI_IFN is the specific indication that this is a DVB Common Interface compliant module. The STCI_STR string indicates the version number. The last 5 characters of this string will always be 'Vx.xx' where x is a digit, and will indicate the specification version with which the module complies. Page 77 EN 50221:1997 6 CISTPL_CFTABLE_ENTRY: Defined according to subclause 3.3.2. Modules shall support at least one of these. For the first entry TPCE_INDX has both bits 6 (Default) and 7 (Intface) set. The Configuration Entry Number can be any convenient value other than zero. TPCE_IF = 04h - indicating Custom Interface 0. TPCE_FS shall indicate the presence of both I/O and power configuration entries. TPCE_IO is a 1-byte field with the value 22h - see subclause 3.3.2.6. The information means: 2 address lines are decoded by the module and it uses only 8-bit accesses. The power configuration entry - required by subclause A.5.5.10 of this specification, shall follow the PC Card specification, [8]. The CFtable entry also contains the two following subtuples: 7 STCE_EV: see subclause 3.3.2.10.1. Only the system name 'DVB_HOST' is present. 8 STCE_PD: see subclause 3.3.2.10.2. Only the physical device name 'DVB_CI_MODULE' is present. 9 CISTPL_END: the value FFh. If the CA module contains other tuples in addition to those defined above then these will come before CISTPL_END. Page 78 EN 50221:1997 Annex B (informative) Additional objects B.1 Authentication This optional resource is included in hosts which support authentication to enable the transmission of authenti- cation commands between a detachable module and a host such that the use of any authentication procedure is under the control of a CA system operator only in respect of signals controlled by him. A broadcaster and/or CA system operator who does not wish to use the authentication protocol must be able to transmit signals which will pass through the common interface without the intervention of any authentication process. The resource consists of two objects, Authentication Request and Authentication Response which are used to implement an authentication protocol. The particular use is defined between CA manufacturers and manufac- turers of hosts which include this resource and is not defined here. B.1.1 Authentication Request and Authentication Response These objects are identical except for the tag value. Syntax No. of bits Mnemonic auth_req () { auth_req_tag 24 uimsbf length_field() auth_protocol_id 16 uimsbf for (i=0; iapp Tauth_req 9F 82 00 Authentication <--- Tauth_resp 9F 82 01 Authentication ---> Page 79 EN 50221:1997 B.2 EBU Teletext Display Resource The resource defines an object and protocol for communication with the host if it signals that the EBU Teletext (EBT) Display resource is present. EBT is a means of delivering text-oriented data for display on a television screen. It is normally transported on spare lines in the field blanking interval of conventional TV signals, and will be carried in data transport streams in the multiplex of MPEG-2 broadcasts. EBT defines a particular display capability in the TV set, and the following set of objects is defined to convey data for display using this capability. The full specification is in [B1] but the salient features for display purposes are repeated here. B.2.1 Display characteristics The display consists of a two-dimensional alpha-mosaic character grid of from 40 to 160 characters per row and up to 101 rows. However on 4:3 aspect ratio 625-line displays this will be limited to 40 characters per row and 25 rows. The specification uses a defined character set for display but it also allows Dynamically Redefin- able Character Sets (DRCS). It uses a standard set of colours for display but also allows a map of different col- our tables to be downloaded. As well as an alpha-mosaic display capability, the standard also provides for alpha-geometric and alpha-photographic displays but the current version of this resource does not support them. The display shall accept Presentation Level Two syntax. B.2.2 Object communication philosophy The communications philosophy adopted here is to provide the EBT display with data as if it had been deliv- ered over air on a TV line or in a MPEG-2 transport stream. A EBT Packets object is provided for this purpose. A session is set up to the EBT display resource, which succeeds if no other application is using it. Whilst the application has control any incoming teletext service is denied access to the display. The display is allocated on a first come first served basis to the applications. After the first EBT Packets object is received the display shall switch from picture to text mode and display what has been loaded. Further EBT Packets objects can be sent if required. On clear-down of the session the display shall revert to picture mode. B.2.3 EBT Packets Syntax No. of bits Mnemonic ebt_packets() { ebt_packet_tag 24 uimsbf length_field() for (i:=0; iapp Tebt_packets 9F 90 00 EBU Teletext <--- B.2.5 References [B1] EBU SPB 492: Teletext Specification (625 line television systems), EBU, Geneva. B.3 Smart Card Reader Resource Class This document describes an optional smart card reader resource which can be provided by a host directly or by another module. This resource uses commands at the card instruction level (header, data and status bytes). The commands are defined in the ISO 7816-1,2,3 specifications. Four objects are defined. Smart Card Cmd and Smart Card Reply perform control and response functions. Smart Card Send and Smart Card Rcv send and receive data. The resource allows multiple sessions to be set up to it so that different applications can interro- gate the resource, but only one session can be in the ‘connected’state at any time. The resource is intended to support a smart card reader in a host or on a module used for short-term sessions, such as Bank Card, teleshopping or pay-per-view transactions. It is not recommended that it be used for long- period sessions to smart cards required for ongoing security operations to maintain access to a scrambled serv- ice. This is because the smart card reader resource is thereby tied up and not available for other uses, and also because no guarantee of bounded response delay can be given. B.3.1 Objects B.3.1.1 Smart Card Cmd Syntax No. of Bits Mnemonic smart_card_cmd () { smart_card_cmd_tag 24 uimsbf length_field () smart_card_cmd_id 8 uimsbf } smart_card_cmd_id id value connect 01 disconnect 02 power_on_card 03 power_off_card 04 reset_card 05 read_status 06 read_answ_to_reset 07 reserved other values Page 81 EN 50221:1997 This command is issued by the application once a session has been set up to the resource. In response a Smart Card Reply object is returned by the resource. The following commands are available: • connect: connect this session to the card reader. If the connection is successful then the reply id will be ‘connected’ with an appropriate card status - card_inserted, no_card, etc. If the card reader is already , connected on another session then the reply id ‘busy’is returned. • disconnect: disconnect the card reader from this session. The card is powered off. The reply id ‘free’ is returned with the appropriate card status. If the card reader is connected in another session then the reply id ‘busy’is returned. • power_on_card: switch on the card interface by connection and activation of the contacts by the inter- face device (Vcc then RAZ according to ISO 7816 specification). The command also resets the card. This command is only allowed once the card reader is connected in this session. The response is ‘ free’ if the card reader is not connected, ‘busy’ if it is connected in another session, ‘answ_to_reset’ if a card is inserted and performed a reset correctly, and ‘ no_answ_to_reset‘ if there is no card, or the card did not reset properly. • power_off_card: powers off the card interface according to the ISO 7816 specification. The response is ‘connected’ if the session is connected & the operation succeeded, ‘free’ if the session is not connected, and ‘busy’if another session is connected. • reset_card: resets the card interface when the smart card is switched on. The responses are the same as for power_on_card. • read_status: reads the current connection and card status. It is not necessary to connect to issue this command. • read_answ_to_reset: gets the answer-to-reset message for the current card, if one is in the socket. It is not necessary to connect to issue this command. The response is ‘answ_to_reset’ if one is available, oth- erwise ‘no_answ_to_reset’ . B.3.1.2 Smart Card Reply Syntax No. of Bits Mnemonic smart_card_reply() { smart_card_reply_tag 24 uimsbf length_field () smart_card_reply_id 8 uimsbf smart_card_status 8 uimsbf if (smart_card_reply_id == answ_to_reset) { for (i=0; i < n; i++) { char_value 8 uimsbf } } } Page 82 EN 50221:1997 smart_card_reply_id id value connected 01 free 02 busy 03 answ_to_reset 04 no_answ_to_reset 05 reserved other values smart_card_status value card_inserted 01 card_removed 02 card_in_place_power_off 03 card_in_place_power_on 04 no_card 05 unresponsive_card 06 refused_card 07 reserved other values Smart Card Reply is returned in response to a Smart Card Cmd object, or in response to a Smart Card Send object if send is an inappropriate operation at that point. It is also sent unrequested on the connected session (if any) when a card is removed or inserted to signal the fact. The reply id values are: • connected: the response on a connected session where answ_to_reset or no_answ_to_reset does not need to be sent. • free: sent in response to a ‘disconnect’ command, or to other commands if the smart card reader is not connected. • busy: sent in response to commands not allowed to a smart card reader already connected on another session. • answ_to_reset: sent with the answer-to-reset message from the card. • no_answ_to_reset: sent when answer-to-reset has been requested but is not available. Each reply also carries the card status at that time. The following status values are used: • card_inserted: sent unrequested on a connected session when a card is inserted. • card_removed: sent unrequested on a connected session when a card is removed. • card_in_place_power_off: sent in all replies when a card is inserted and recognised and the card is not powered. • card_in_place_power_on: sent in all replies when a card is inserted and recognised and the card is powered. • no_card: sent in all replies when no card is plugged in. • unresponsive_card: in all replies after the plugged in card does not reply to a reset or if it fails to respond to a Smart Card Send. • refused_card: sent in all replies after a card responds to a reset, but not in an expected way. Page 83 EN 50221:1997 B.3.1.3 Smart Card Send Syntax No. of Bits Mnemonic smart_card_send () { smart_card_send_tag 24 uimsbf length_field () CLA 8 uimsbf INS 8 uimsbf P1 8 uimsbf P2 8 uimsbf length_in 16 uimsbf for (i=0; iapp Tsmart_card_cmd 9F 8E 00 Smart Card reader <--- Tsmart_card_reply 9F 8E 01 Smart Card reader ---> Tsmart_card_send 9F 8E 02 Smart Card reader <--- Tsmart_card_rcv 9F 8E 03 Smart Card reader ---> Page 84 EN 50221:1997 B.3.2.1 Resource type coding The Smart Card Reader resource may have up to 16 instances, supplied either by the host or by other modules. The application selects the required reader by specifying the required device number as the four least signifi- cant bits of the resource type field, as shown in Figure B.1. bit 9 8 7 6 5 4 3 2 1 0 0 0 0 0 0 0 device no. Figure B.1: Smart Card reader resource type structure B.4 DVB EPG Future Event Support Class This resource is made available by an EPG application to support communication of entitlement information from CA modules to Electronic Programme Guides - whether host-based or module-based. CA modules which offer entitlement information to EPG applications shall create a session to all instances of this resource indicated by the Resource Manager and shall operate the protocol as required by the EPG application. The protocol uses two objects - an event_enquiry object and an event_reply object. The protocol allows an EPG to enquire of the entitlement status of a current or future event, identified by its Event ID in the Service Information. The CA module can reply indicating that entitlement for the event is available, is not available, may be available after dialogue (e.g. pay-per-view), or its entitlement status is unknown. Additionally the protocol supports a process for allowing a CA module to start a dialogue to make a potential entitlement available, e.g. for pay-per-view, and then returning to the EPG dialogue. This resource does not prevent EPG and CA applications from the same or co-operating providers using the private resource mechanism to integrate operation of EPG and CA more completely. However CA modules wishing to provide entitlement information to independent EPGs shall use this resource. B.4.1 Objects B.4.1.1 Event Enquiry Object This is a query from EPG to CA module. Table B.1: Event Enquiry object coding Syntax No. of bits Mnemonic event_enquiry () { event_enquiry_tag 24 uimsbf length_field() event_cmd_id 8 uimsbf network_id 16 uimsbf original_network_id 16 uimsbf transport_stream_id 16 uimsbf service_id 16 uimsbf event_id 16 uimsbf } event_cmd_id This can have the following values: event_cmd_id value mmi 02 query 03 reserved other values Page 85 EN 50221:1997 The 'mmi' command allows the CA module to start a MMI dialogue to make entitlement available. It is typically used after the EPG has already determined (by a previous 'query' command) that an MMI session is required by the CA module, and has closed its own MMI session temporarily to make the MMI resource available to the CA module. The 'query' command is used to just ask for the current entitlement status of an event without requesting a dialogue. The event ID is fully qualified by all the other location identifiers in SI which make it unique. B.4.1.2 Event Reply Object This is a reply from CA module to EPG. Table B.2: Event Reply object coding Syntax No. of bits Mnemonic event_reply () { event_reply_tag 24 uimsbf length_field() event_status 8 uimsbf } event_status This can have the following values: event_status value entitlement_unknown 00 entitlement_available 01 entitlement_not_available 02 mmi_dialogue_required 03 mmi_complete_unknown 04 mmi_complete_available 05 mmi_complete_not_available 06 reserved other values 'entitlement_unknown' means that the CA module cannot determine the entitlement status of this event. 'entitlement_available' means that entitlement for this event is currently available. 'entitlement_not_available' means that entitlement for this event is not currently available and cannot be made available by any user dialogue with the CA module. 'mmi_dialogue_required' indicates that entitlement is not currently available but could be made available after a dialogue between CA and user. 'mmi_complete_unknown' is returned in response to a event_enquiry with the 'mmi' command after the CA mmi dialogue is complete and the entitlement status is still unknown. 'mmi_complete_available' is returned in response to a event_enquiry with the 'mmi' command after the CA mmi dialogue is complete and the entitlement has been granted. 'mmi_complete_not_available' is returned in response to a event_enquiry with the 'mmi' command after the CA mmi dialogue is complete and the entitlement has not been granted, for example if the user decided, in the dialogue, not to purchase the event after all. Note that the event_reply object returned refers to the preceding event_enquiry object received, so the EPG must not send another event_enquiry object until it receives the event_reply for the current enquiry. Page 86 EN 50221:1997 B.4.1.3 Example of Use A typical protocol exchange is described. This uses an enhancement of the MMI resources allowing the application to close a MMI session with a short delay before returning to the current service to allow another application to start its own dialogue seamlessly with the previous one. EPG: event_query(query, event x) CA: event_reply(mmi_dialogue_required) EPG: close_mmi(delay); remember context EPG: event_query(mmi, event x) CA: open mmi; perform dialogue CA: close_mmi(delay) CA: event_reply(mmi_complete_available) (may also reply not_available or unknown) EPG: open mmi; continue EPG dialogue from remembered context B.4.2 EPG Future Event Support resource coding Resource class type version resource identifier EPG Future Event Support 120 see §B.4.2.1 1 00780041 apdu_tag tag value Resource Direction (hex) EPG<-->CA Tevent_enquiry 9F 8F 00 EPG Future Evt Supp ---> Tevent_reply 9F 8F 01 EPG Future Evt Supp <--- B.4.2.1 Resource type coding It may be that there is more than one EPG on a host. For example the host may support an internal EPG application and the user may have also purchased a module-based EPG. In this case the host shall allocate resource type numbers, beginning at zero, to distinguish the instances of EPG running. CA modules which support EPGs using this resource shall create a session to each instance of this class advertised as a different resource type by the Resource Manager.