COMMON INTERFACE SPECIFICATION FOR
`CONDITIONAL ACCESS AND OTHER DIGITAL
`VIDEO BROADCASTING DECODER
`APPLICATIONS
`
`DVB DOCUMENT A017
`May 1996
`
`Reproduction of the document in whole or in part without prior permission of the DVB Project Office
`is
` forbidden.
`
`DVB Project Office
`31 May 1996
`
`1
`
`KINGSTON 1008
`
`

`

`1.
`
`2.
`
`3.
`
`4.
`4.1.
`4.2.
`4.3.
`4.4.
`4.5.
`4.6.
`5.
`5.1.
`5.2.
`5.3.
`5.4.
`
`5.5.
`6.
`6.1.
`6.2.
`6.3.
`7.
`7.1.
`
`7.2.
`
`8.
`8.1.
`8.2.
`
`CONTENTS
`
`INTRODUCTION AND SCOPE
`
`DEFINITIONS
`
`REFERENCES
`
`DESIGN PHILOSOPHY
`LAYERING
`PHYSICAL IMPLEMENTATION
`CLIENT-SERVER
`CODING OF DATA
`EXTENSIBILITY
`INCORPORATION OF EXISTING STANDARDS
`DESCRIPTION AND ARCHITECTURE
`OVERVIEW
`TRANSPORT STREAM INTERFACE
`COMMAND INTERFACE
`PHYSICAL REQUIREMENTS
`INTRODUCTION
`5.4.1.
`5.4.2. DATA AND COMMAND LOGICAL CONNECTIONS
`5.4.3. CONNECTION AND DISCONNECTION BEHAVIOUR
`5.4.4. MULTIPLE MODULES
`OPERATIONAL EXAMPLE
`TRANSPORT STREAM INTERFACE (TSI)
`TSI - PHYSICAL, LINK LAYERS
`TSI - TRANSPORT LAYER
`TSI - UPPER LAYERS
`COMMAND INTERFACE - TRANSPORT & SESSION LAYERS
`GENERIC TRANSPORT LAYER
`INTRODUCTION
`TRANSPORT PROTOCOL OBJECTS
`TRANSPORT PROTOCOL
`SESSION LAYER
`INTRODUCTION
`7.2.1.
`SESSION PROTOCOL OBJECTS
`7.2.2.
`SESSION PROTOCOL
`7.2.3.
`SPDU STRUCTURE
`7.2.4.
`TRANSPORTATION OF SPDU
`7.2.5.
`SESSION HEADERS DESCRIPTION
`7.2.6.
`7.2.6.1. Open Session Request
`7.2.6.2. Open Session Response
`7.2.6.3.
`Create Session
`7.2.6.4.
`Create Session Response
`7.2.6.5.
`Close Session Request
`7.2.6.6.
`Close Session Response
`7.2.6.7.
`Session Number
`7.2.7. CODING OF THE SESSION TAGS
`COMMAND INTERFACE - APPLICATION LAYER
`INTRODUCTION
`RESOURCES
`INTRODUCTION
`8.2.1.
`8.2.2. RESOURCE IDENTIFIER
`
`7.1.1.
`7.1.2.
`7.1.3.
`
`3
`
`7
`
`8
`
`8
`
`8
`8
`9
`9
`9
`9
`9
`10
`10
`10
`10
`11
`11
`11
`12
`12
`13
`13
`13
`13
`14
`14
`14
`14
`15
`16
`19
`19
`20
`20
`22
`22
`22
`22
`23
`24
`24
`24
`25
`25
`26
`27
`27
`27
`27
`27
`
`2
`
`

`

`8.3.
`
`8.4.
`
`8.5.
`
`8.6.
`
`8.7.
`
`8.2.3. APPLICATIONS AND RESOURCE PROVIDERS
`APPLICATION PROTOCOL DATA UNITS
`INTRODUCTION
`8.3.1.
`8.3.2. CHAINING OF APDU DATA FIELDS
`8.3.3.
`TRANSPORTATION OF APDU WITHIN SPDU
`SYSTEM MANAGEMENT RESOURCES
`8.4.1. RESOURCE MANAGER
`8.4.1.1.
`Resource Manager Protocol
`8.4.1.2.
`Profile Enquiry
`8.4.1.3.
`Profile Reply
`8.4.1.4.
`Profile Changed
`8.4.2. APPLICATION INFORMATION
`8.4.2.1. Application Info Enquiry
`8.4.2.2. Application Info
`8.4.2.3.
`Enter Menu
`8.4.3. CONDITIONAL ACCESS SUPPORT
`8.4.3.1.
`CA Info Enquiry
`8.4.3.2.
`CA Info
`8.4.3.3.
`Selection of services to be descrambled
`8.4.3.4.
`CA_PMT
`8.4.3.5.
`CA PMT Reply
`HOST CONTROL AND INFORMATION RESOURCES
`8.5.1. DVB HOST CONTROL
`8.5.1.1.
`Tune
`36
`8.5.1.2.
`Replace
`8.5.1.3.
`Clear Replace
`8.5.1.4. Ask Release
`8.5.2. DATE AND TIME
`8.5.2.1. Date-Time Enquiry
`8.5.2.2. Date-Time
`MAN-MACHINE INTERFACE RESOURCE
`INTRODUCTION
`8.6.1.
`8.6.2. OBJECTS USED IN BOTH MODES
`8.6.2.1.
`Close MMI
`8.6.2.2. Display Control
`8.6.2.3. Display Reply
`8.6.3.
`LOW-LEVEL MMI KEYPAD OBJECTS
`8.6.3.1. Keypad Control
`8.6.3.2. Keypress
`8.6.3.3.
`Table of key codes
`8.6.4.
`LOW-LEVEL MMI DISPLAY OBJECTS
`8.6.4.1. Delivery of DVB Subtitle data
`8.6.4.2.
`Segment Encapsulation
`8.6.4.3. Display System Messages
`8.6.4.4.
`Temporal Control
`8.6.4.5. Object Download
`8.6.4.6.
`The Subtitling Decoder Model when addressed from the Common Interface
`8.6.5. HIGH-LEVEL MMI OBJECTS
`8.6.5.1.
`Text
`51
`8.6.5.2.
`Enq
`51
`8.6.5.3. Answ 52
`8.6.5.4. Menu 52
`8.6.5.5. Menu Answ
`8.6.5.6.
`List
`53
`COMMUNICATIONS RESOURCES
`LOW-SPEED COMMUNICATION RESOURCE CLASS
`8.7.1.
`8.7.1.1.
`Introduction
`8.7.1.2.
`Requirements
`8.7.1.3. Objects Supporting the Low-Speed Communications Resource
`8.7.1.4.
`Comms Cmd
`
`4
`
`28
`28
`28
`29
`29
`29
`29
`29
`30
`30
`30
`31
`31
`31
`32
`32
`32
`32
`33
`33
`35
`36
`36
`
`36
`37
`37
`37
`38
`38
`38
`38
`39
`39
`39
`41
`43
`43
`44
`44
`45
`45
`45
`45
`46
`48
`50
`50
`
`53
`
`54
`54
`54
`54
`54
`55
`
`3
`
`

`

`8.8.
`
`8.7.1.5.
`8.7.1.6.
`8.7.1.7.
`
`Comms Reply
`Comms Send
`Comms Rcv
`RESOURCE IDENTIFIERS AND APPLICATION OBJECT TAGS
`8.8.1. RESOURCE IDENTIFIERS
`8.8.1.1.
`Low-Speed Communications Resource Types
`8.8.2. APPLICATION OBJECT TAGS
`ANNEX A : PC CARD-BASED PHYSICAL LAYER (NORMATIVE)
`
`56
`57
`57
`58
`58
`58
`60
`62
`
`62
`62
`62
`63
`
`A.5.
`
`A.3.
`A.3.1.
`A.3.2.
`A.4.
`
`GENERAL DESCRIPTION
`A.1.
`PC CARD INTERFACE
`A.1.1.
`DESCRAMBLER
`A.1.2.
`FILTER/EXTRACT
`A.1.3.
`CPU 63
`A.1.4.
`ROM/EPROM AND RAM/NVRAM
`A.1.5.
`63
`SECURITY PROCESSOR
`A.1.6.
`63
`63
`ELECTRICAL INTERFACE
`A.2.
`63
`TRANSPORT STREAM INTERFACE
`A.2.1.
`COMMAND INTERFACE
`A.2.2.
`63
`63
`A.2.2.1. HARDWARE INTERFACE DESCRIPTION
`64
`A.2.2.1.1 Initialisation
`65
`A.2.2.1.2 Host to Module Transfers
`65
`A.2.2.1.3 Module to Host Transfers
`A.2.2.2. HARDWARE SUPPORT IN THE MODULE
`65
`66
`LINK LAYER
`66
`TRANSPORT STREAM INTERFACE
`COMMAND INTERFACE
`66
`IMPLEMENTATION-SPECIFIC TRANSPORT SUBLAYER OVER PC CARD
`INTERFACE
`67
`TRANSPORT PROTOCOL OBJECTS
`67
`A.4.1.
`A.4.1.1. COMMAND TPDU
`67
`A.4.1.2. RESPONSE TPDU
`67
`A.4.1.3. CHAINING OF COMMAND OR RESPONSE TPDU DATA FIELDS
`68
`A.4.1.4. CREATE TRANSPORT CONNECTION (CREATE_T_C)
`69
`A.4.1.5. CREATE TRANSPORT CONNECTION REPLY (C_T_C_REPLY)
`69
`A.4.1.6. DELETE TRANSPORT CONNECTION (DELETE_T_C)
`70
`A.4.1.7. DELETE TRANSPORT CONNECTION REPLY (D_T_C_REPLY)
`70
`A.4.1.8. REQUEST TRANSPORT CONNECTION (REQUEST_T_C)
`71
`A.4.1.9. NEW TRANSPORT CONNECTION (NEW_T_C)
`71
`A.4.1.10.
`TRANSPORT CONNECTION ERROR (T_C_ERROR)
`72
`A.4.1.11.
`LIST OF C_TPDUS AND ASSOCIATED R_TPDUS
`72
`A.4.1.11.1 Send Data command
`72
`A.4.1.11.2 Receive Data command
`73
`A.4.1.12.
`RULES FOR THE POLLING FUNCTION
`73
`A.4.1.13.
`LIST OF TRANSPORT TAGS
`74
`PC CARD SUBSET TO BE USED BY CONFORMANT HOSTS AND MODULES
`75
`OBJECTIVES
`A.5.1.
`INTRODUCTION
`A.5.2.
`TERMINOLOGY
`A.5.3.
`PHYSICAL SPECIFICATION
`A.5.4.
`A.5.4.1. CARD DIMENSIONS
`A.5.4.2. CONNECTOR 75
`A.5.4.3. PC CARD GUIDANCE
`A.5.4.4. GROUNDING/EMI CLIPS
`
`75
`75
`75
`75
`75
`
`75
`75
`
`5
`
`4
`
`

`

`A.5.4.5. CONNECTOR RELIABILITY
`A.5.4.5. CONNECTOR RELIABILITY
`A.5.4.6. CONNECTOR DURABILITY
`A.5.4.6. CONNECTOR DURABILITY
`A.5.4.7. PC CARD ENVIRONMENTAL
`A.5.4.7. PC CARD ENVIRONMENTAL
`A.5.5.
`ELECTRICAL SPECIFICATION
`A5.5.
`ELECTRICAL SPECIFICATION
`A.5.5.1. CARD TYPE DETECTION
`A.5.5.1. CARD TYPE DETECTION
`A.5.5.2. PIN ASSIGNMENTS
`A.5.5.2, PIN ASSIGNMENTS
`A.5.5.3. 16-BIT PC CARD FEATURES
`A.5.5.3. 16-BIT PC CARD FEATURES
`A.5.5.4. SIGNAL DESCRIPTION
`A.5.5.4. SIGNAL DESCRIPTION
`A.5.5.5. MEMORY FUNCTION
`A.5.5.5. MEMORY FUNCTION
`A.5.5.6. TIMING FUNCTIONS
`A.5.5.6. TIMING FUNCTIONS
`A.5.5.7. ELECTRICAL INTERFACE
`A.5.5.7, ELECTRICAL INTERFACE
`A.5.5.8. CARD DETECT
`A.5.5.8. CARD DETECT
`A.5.5.9. BATTERY VOLTAGE DETECT
`A.5.5.9. BATTERY VOLTAGE DETECT
`A.5.5.10.
`POWER-UP AND POWER-DOWN
`A.5.5.10.
`POWER-UP AND POWER-DOWN
`A.5.5.11.
`I/O FUNCTION
`A.5.5.11.
`I/O FUNCTION
`A.5.5.12.
`FUNCTION CONFIGURATION
`A.5.5.12.
`FUNCTION CONFIGURATION
`A.5.5.13.
`CARD CONFIGURATION
`A.5.5.13.
`CARD CONFIGURATION
`A.5.6.
`METAFORMAT SPECIFICATION
`A.5.6.
`METAFORMAT SPECIFICATION
`ANNEX B : ADDITIONAL OBJECTS (OPTIONAL)
`ANNEX B : ADDITIONAL OBJECTS (OPTIONAL
`
`AUTHENTICATION
`B.1.
`AUTHENTICATION
`B.1.
`AUTHENTICATION REQUEST AND AUTHENTICATION RESPONSE
`B.1.1.
`AUTHENTICATION REQUEST AND AUTHENTICATION RESPONSE
`B.1.1.
`AUTHENTICATION RESOURCE CODING
`B.1.2.
`AUTHENTICATION RESOURCE CODING
`B.1.2.
`EBU TELETEXT DISPLAY RESOURCE
`B.2.
`EBU TELETEXT DISPLAY RESOURCE
`B.2.
`DISPLAY CHARACTERISTICS
`B.2.1.
`DISPLAY CHARACTERISTICS
`B.2.1.
`OBJECT COMMUNICATION PHILOSOPHY
`B.2.2.
`OBJECT COMMUNICATION PHILOSOPHY
`B.2.2.
`EBT PACKETS
`B.2.3.
`EBT PACKETS
`B.2.3.
`EBU TELETEXT RESOURCE CODING
`B.2.4.
`EBU TELETEXT RESOURCE CODING
`B.2.4.
`REFERENCES
`B.2.5.
`REFERENCES
`B.2.5,
`SMART CARD READER RESOURCE CLASS
`B.3.
`SMART CARD READER RESOURCE CLASS
`B.3.
`OBJECTS
`B.3.1.
`OBJECTS
`B3.1.
`B.3.1.1. SMART CARD CMD
`B.3.1.1. SMART CARD CMD
`B.3.1.2. SMART CARD REPLY
`B.3.1.2. SMART CARD REPLY
`B.3.1.3. SMART CARD SEND
`B.3.1.3. SMART CARD SEND
`B.3.1.4. SMART CARD RCV
`B.3.1.4. SMART CARD RCV
`B.3.2.
`SMART CARD READER RESOURCE CODING
`B.3.2.
`SMART CARD READER RESOURCE CODING
`B.3.2.1. RESOURCE TYPE CODING
`B.3.2.1. RESOURCE TYPE CODING
`DVB EPG FUTURE EVENT SUPPORT CLASS
`B.4.
`DVB EPG FUTURE EVENT SUPPORT CLASS
`B.4.
`OBJECTS
`B.4.1.
`OBJECTS
`B.4.1.
`B.4.1.1. EVENT ENQUIRY OBJECT
`B.4.1.1. EVENT ENQUIRY OBJECT
`B.4.1.2. EVENT REPLY OBJECT
`B.4.1.2. EVENT REPLY OBJECT
`B.4.1.3. EXAMPLE OF USE
`B.4.1.3. EXAMPLE OF USE
`B.4.2.
`EPG FUTURE EVENT SUPPORT RESOURCE CODING
`B.4.2.
`EPG FUTURE EVENT SUPPORT RESOURCE CODING
`B.4.2.1. RESOURCE TYPE CODING
`B.4.2.1. RESOURCE TYPE CODING
`
`75
`75
`75
`75
`75
`715
`76
`76
`76
`716
`76
`716
`77
`77
`77
`77
`79
`719
`79
`719
`79
`719
`79
`719
`79
`719
`80
`80
`80
`80
`80
`80
`80
`80
`80
`80
`82
`82
`
`82
`82
`82
`82
`82
`82
`83
`83
`83
`83
`83
`83
`83
`83
`84
`84
`84
`84
`85
`85
`85
`85
`85
`85
`86
`86
`87
`87
`88
`88
`88
`88
`88
`88
`89
`89
`89
`89
`89
`89
`90
`90
`90
`90
`91
`91
`91
`91
`
`6
`6
`
`5
`
`

`

`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 decoderinterfaces. In addition, a conditional access system is used when there
`is a need to control access to a broadcastservice. 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 opera-
`tors. 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 generally
`defined proprietary functions may be implemented in the module. This solution also allows broadcasters to use modules
`contaming solutions from different suppliers in the same broadcast system, thus increasing their choice and anti-piracy
`options. The scope of this documentis to describe this commoninterface.
`
`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.
`
`Tuner
`
`|——» Demodulator
`
`MPEG Decoder
`
`RGB Out
`
`Audio Out
`
`
`
`
`
`
`
`
`( Remote )
`
`Demultiplexer
`
`Host
`
`
`
`
`Descrambled
`Scrambled
`
`Transport Stream
`Transport Stream
`
`Control
`
`Common Interface
`-
`
`Microprocessor
`
`Descrambler
`
`Module
`
`
`
`
`
`
`
`
`Figure 1.1 - Example of single module in connection with host
`
`Two logical interfaces, to be included on the same physical interface, are defined. Thefirst 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 forthis interface. An example of a single module in connection with a host is shown in
`Figure 1.1.
`
`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.
`
`7 6
`
`6
`
`

`

`The specification does not define the operation or functionality of a conditional access system application on the mod-
`ule. 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 supported concurrently.
`
`2. DEFINITIONS
`
`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 synchronisation.
`They are made of different data, i.e., video, audio, subtitles, other data...
`
`Transport Stream : MPEG-2 Transport Stream.
`
`3. REFERENCES
`
`[1] ISO/IEC 13818-1: Generic Coding of Moving Picture and Associated Audio : 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] pr ETS 300 468: "Specification for Service Information (SI) in Digital Video Broadcasting (DVB) systems".
`[5] ETR XXX: "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] pr ETS xxx xxx: DVB Subtitling Specification (A009?)
`
`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 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 number of different sessions with the host.
`
`8
`
`7
`
`

`

`HOST
`
`Transport
`Connection
`
`Session
`
`Appplication
`Process
`
`Figure 4.1 - 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 applica-
`tions 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 mechanism for extending the
`range of resources provided by hosts, both for CA purposes and for other module-based applications.
`
`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.
`
`9
`
`8
`
`

`

`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 min-
`imised. Figure 1.1 shows a simplified picture of a 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.
`
`The common interface consists of two 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 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 packets carrying those ser-
`vices 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 logic is preserved under most
`conditions (see section 5.4.2). The Transport Stream Interface layers are shown 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 5.1 - 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 func-
`tionality. This functionality includes: the ability to support multiple modules on one host, the ability to support com-
`plex combinations of transaction between module and host, and an extensible set of functional primitives (objects)
`which allow the host to provide resources to the module. The layering is shown below:
`
`Optional extensions
`
`User Interface
`
`Application
`Resources :
`
`System
`
`Low-Speed
`Communications
`Session Layer
`Generic Transport Sublayer
`PC Card Transport Sublayer
`PC Card Link Layer
`PC Card Physical Layer
`
`Figure 5.2 - Command Interface Layers
`
`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
`10
`
`9
`
`

`

`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.
`
`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 communications, 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 section defines the requirements the Physical Layer must meet in order to carry out all the required functions.
`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 com-
`mands.
`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 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.
`
`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).
`tmdvmax <= 1 microsecond when n = 0
`
`and
`
`where:
`
`= Module Delay Variation
` tmdv
`= Number of gaps present within the corresponding input transport packet
` n
` 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.
`
`11
`
`10
`
`

`

`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 specifica-
`tion 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 connec-
`tion 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 pro-
`ceed.
`
`If the Physical Layer is used in other applications than as a DVB-conformant module connection, and if a non-confor-
`mant 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 accept-
`able that some Transport Stream data is lost during this process. Also, the Command Interface connection shall be
`terminated by the host.
`
`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.3 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 connec-
`tion 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).
`
`12
`
`11
`
`

`

`Host
`
`CA module 1
`
`CA module 2
`
`CA module n
`
`Figure 5.3 - 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 module. The host now turns off
`the Transport Stream Interface bypass link and allows the transport packets to flow through the module. This intro-
`duces 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.
`
`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 transport_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].
`
`13
`
`12
`
`

`

`6.3. TSI - upper layers
`Apart from the Packetised Elementary Stream, any layering or structure 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 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.
`
`Syntax
`length_field() {
`size_indicator
`if (size_indicator == 0)
`length_value
`else if (size_indicator == 1) {
`length_field_size
`for (i=0; i<length_field_size; i++) {
`length_value_byte
`
`}
`
`}
`
`}
`
`No. of bits
`
`Mnemonic
`
`1
`
`7
`
`7
`
`8
`
`bslbf
`
`uimsbf
`
`uimsbf
`
`bslbf
`
`Table 7.1: Length field used by all Protocol Data Units at Transport, Session & Application Layers
`
`This section describes the ASN.1 objects for the Transport and Session Layers that travel over the command interface.
`For all these objects, and for the Application Layer objects in section 8, the coding in Table 7.1 applies for the Length
`field, which indicates the number of bytes in the following Value field.
`
`Size_indicator is the first bit of the length_field. If size_indicator = 0, the length of the data field is coded in the
`succeeding 7 bits. Any length from 0 to 127 can thus be encoded on one byte. If the length exceeds 127, then
`size_indicator is set to 1. In this case, the succeeding 7 bits code the number of subsequent bytes in the length field.
`Those subsequent bytes shall be concatenated, first byte at the most significant end, to encode an integer value. Any
`value field length up to 65535 can thus be encoded by three bytes.
`
`The indefinite length format specified by the basic encoding rules of ASN.1 (see [3]) is not used.
`
`7.1. Generic Transport Layer
`
`7.1.1. Introduction
`The Transport Layer of the Command Interface operates on top of a Link Layer provided by the particular physical
`implementation used. For the baseline PC Card physical implementation the Link Layer is described in Normative
`Annex A. The transport protocol assumes that the Link Layer is reliable, that is, data is conveyed in the correct order
`and with no deletion or repetition of data.
`
`The transport protocol is a command-response protocol where the host sends a command to the module, using a
`Command Transport Protocol Data Unit (C_TPDU) and waits for a response from the module with a Response
`Transport Protocol Data Unit (R_TPDU). The module cannot initiate communication: it must wait for the host to poll
`it or send it data first. The protocol is supported by eleven Transport Layer objects. Some of them appear only in
`C_TPDUs from the host, some only in R_TPDUs from the module and some can appear in either. Create_T_C and
`C_T_C_Reply, create new Transport Connections. Delete_T_C and D_T_C_Reply, clear them down. Request_T_C
`and New_T_C allow a module to request the host to create a new Transport Connection. T_C_Error allows error
`conditions to be signalled. T_SB carries status information from module to host. T_RCV requests waiting data from a
`module and T_Data_More and T_Data_Last convey data from higher layers between host and module. T_Data_Last
`with an empty data field is used by the host to poll regularly for data from the module when it has nothing to send
`itself.
`
`14
`
`13
`
`

`

`A C_TPDU from the host contains only one Transport Protocol Object. A R_TPDU from a module may carry one