av/c ca subunit specification - 1394 trade...

TA Document 1999007

AV/C CA Subunit Specification

Version 1.0April 6, 1999

Sponsored by:Audio/Video Working Group of the 1394 Trade Association

Approved for Release by:This document has been approved for release by the 1394 Trade AssociationBoard of Directors

Abstract: This document defines a model and command set for a Conditional Access, orCA subunit. The command set makes use of the Function Control Protocol (FCP) definedby IEC 61883, Digital Interface for Consumer Electronic Audio/Video Equipment, for thetransport of audio/video command requests and responses. The audio/video devices areimplemented as a common unit architecture within IEEE std. 1394–1995.

Keywords: Conditional Access, 1394, Networked CA.

1394 Trade AssociationRegency Plaza Suite 350, 2350 Mission College Blvd., Santa Clara, CA 95054, USAhttp://www.1394TA.orgCopyright 1998-1999 by the 1394 Trade Association. Permission is granted to members of the 1394 TradeAssociation to reproduce this document for their own use or the use of other 1394 Trade Association membersonly, provided this notice is included. All other rights reserved. Duplication for sale, or for commercial or for-profit use is strictly prohibited without the prior written consent of the 1394 Trade Association.

AV/C CA Subunit Specification. 1.0 April 6, 1999, 1999007

Page ii Copyright 1998-1999, 1394 Trade Association. All rights reserved.

1394 Trade Association Specifications are developed within Working Groups of the 1394 TradeAssociation, a non-profit industry association devoted to the promotion of and growth of the marketfor IEEE 1394-compliant products. Participants in working groups serve voluntarily and withoutcompensation from the Trade Association. Most participants represent member organisations ofthe 1394 Trade Association. The specifications developed within the working groups represent aconsensus of the expertise represented by the participants.

Use of a 1394 Trade Association Specification is wholly voluntary. The existence of a 1394 TradeAssociation Specification is not meant to imply that there are not other ways to produce, test,measure, purchase, market or provide other goods and services related to the scope of the 1394Trade Association Specification. Furthermore, the viewpoint expressed at the time a specificationis approved and issued is subject to change brought about through developments in the state of theart and comments received from users of the specification. Users are cautioned to check todetermine that they have the latest revision of any 1394 Trade Association Specification.

Comments for revision of 1394 Trade Association Specifications are welcome from any interestedparty, regardless of membership affiliation with the 1394 Trade Association. Suggestions forchanges in documents should be in the form of a proposed change of text, together withappropriate supporting comments.

Interpretations: Occasionally, questions may arise about the meaning of specifications inrelationship to specific applications. When the need for interpretations is brought to the attention ofthe 1394 Trade Association, the Association will initiate action to prepare appropriate responses.

Comments on specifications and requests for interpretations should be addressed to:

Editor, 1394 Trade AssociationRegency Plaza Suite 3502350 Mission College Blvd.Santa Clara, Calif. 95054, USA

1394 Trade Association Specifications are adopted by the 1394 TradeAssociation without regard to patents which may exist on articles, materials orprocesses, or to other proprietary intellectual property which may exist within aspecification. Adoption of a specification by the 1394 Trade Association does notassume any liability to any patent owner or any obligation whatsoever to thoseparties who rely on the specification documents. Readers of this document areadvised to make an independent determination regarding the existence ofintellectual property rights which may be infringed by conformance to thisspecification.

April 6, 1999, 1999007 AV/C CA Subunit Specification 1.0

Copyright 1998-1999, 1394 Trade Association. All rights reserved. Page iii

Table of Contents

1. NORMATIVE REFERENCES .........................................................................................21.1 Contact Information .....................................................................................................2

1.1.1 1394 Trade Association (1394 TA) .......................................................................21.1.2 European Telecommunications Standards (ETSI) ..................................................21.1.3 International Electrotechnical Commission (IEC) (contact in the USA)..................21.1.4 The Institute of Electrical and Electronic Engineers, Inc. (IEEE) ...........................31.1.5 The Digital Transmission License Administrator, (DTLA).....................................3

1.2 1394 Trade Association Specifications..........................................................................31.3 Related Specifications ..................................................................................................3

2. CHANGE HISTORY.........................................................................................................4

3. DEFINITIONS AND ABBREVIATIONS.........................................................................53.1 Conformance Glossary .................................................................................................53.2 Technical Glossary .......................................................................................................5

4. CA SUBUNIT MODEL .....................................................................................................64.1 The Basic CA Subunit ..................................................................................................6

4.1.1 CA subunit destination plug ..................................................................................64.1.2 CA subunit source plug.........................................................................................64.1.3 Multiple plugs ......................................................................................................64.1.4 Connections..........................................................................................................7

4.2 Full and Partial Transport Stream Handling ..................................................................84.3 Protection of Copyrighted Material...............................................................................8

5. CA SUBUNIT IDENTIFIER DESCRIPTOR, STATUS DESCRIPTOR, OBJECTSAND OBJECT LISTS ...............................................................................................................9

5.1 Text Field Encoding .....................................................................................................95.2 CA Subunit Identifier Descriptor ..................................................................................95.3 CA Subunit Status Descriptor .....................................................................................11

5.3.1 General CA Subunit Status Area Info Block (90 0016) .........................................125.3.2 Source Plug Status Area Info Block (90 0116) ......................................................135.3.3 Plug Status Info Block (90 0216)..........................................................................135.3.4 Descriptor Identifier for the CA subunit Status Descriptor ...................................14

5.4 CA Model Objects and Object Lists............................................................................14

6. CA SUBUNIT COMMANDS...........................................................................................156.1 CA_ENABLE ............................................................................................................15

6.1.1 CA_ENABLE Control Command .......................................................................156.1.1.1 DVB System Specific Operands .................................................................................. 16

6.1.2 Response to a CA_ENABLE Control Command .................................................176.1.2.1 DVB System Specific Operands .................................................................................. 17

6.1.3 CA_ENABLE Status and Notify Commands.......................................................186.1.3.1 DVB System Specific Operands .................................................................................. 19

6.1.4 Response to a CA_ENABLE Status and Notify Commands.................................196.1.4.1 DVB System Specific Operands .................................................................................. 19

6.2 CA_ENTITLEMENT.................................................................................................206.2.1 CA_ENTITLEMENT Command ........................................................................20

6.2.1.1 DVB System Specific Operands .................................................................................. 206.2.2 CA_ENTILEMENT Response ............................................................................21

6.2.2.1 DVB System Specific Operands .................................................................................. 21

AV/C CA Subunit Specification. 1.0 April 6, 1999, 1999007

Page iv Copyright 1998-1999, 1394 Trade Association. All rights reserved.

6.3 SECURITY................................................................................................................22

7. OPERATIONAL GUIDELINES (INFORMATIVE)......................................................237.1 Bandwidth Utilization ................................................................................................247.2 EMM Handling ..........................................................................................................257.3 Out-Of-Band (OOB) Support......................................................................................257.4 Implementations Where a Tuner Subunit is Absent .....................................................25

List of Figures

FIGURE 4-1 THE BASIC CA SUBUNIT ............................................................................................6FIGURE 4-2 CA SUBUNIT LOGICAL CONNECTIONS.........................................................................7FIGURE 5-1 CA SUBUNIT IDENTIFIER DESCRIPTOR ........................................................................9FIGURE 5-2 SYSTEM SPECIFICATION ...........................................................................................10FIGURE 5-3 CA STATUS DESCRIPTOR .........................................................................................11FIGURE 5-4 GENERAL_CA_SUBUNIT_STATUS_AREA_INFO_BLOCK...............................................12FIGURE 5-5 SOURCE_PLUG_STATUS_AREA_INFO_BLOCK .............................................................13FIGURE 5-6 PLUG_STATUS_INFO_BLOCK .....................................................................................13FIGURE 6-1 CA_ENABLE CONTROL COMMAND ........................................................................15FIGURE 6-2 DVB SPECIFIC DATA ENTRIES..................................................................................16FIGURE 6-3 ELEMENTARY_PID_DEFINITION ................................................................................17FIGURE 6-4 CA_ENABLE RESPONSE .........................................................................................17FIGURE 6-5 DVB SPECIFIC RESPONSE FOR CA_ENABLE ...........................................................17FIGURE 6-6 STATUS OR NOTIFY COMMAND STRUCTURE FOR DVB BROADCAST SYSTEM..............19FIGURE 6-7 STATUS OR NOTIFY RESPONSE STRUCTURE FOR DVB BROADCAST SYSTEM...............19FIGURE 6-8 FORMAT OF CA_ENTITLEMENT COMMAND ..........................................................20FIGURE 6-9 DVB SPECIFIC OPERANDS FOR CA_ENTITLEMENT COMMAND .............................20FIGURE 6-10 CA_ENTITLEMENT RESPONSE ...........................................................................21FIGURE 6-11 DVB SPECIFIC OPERANDS FOR CA_ENTITLEMENT RESPONSE.............................21FIGURE 6-12 FORMAT OF SECURITY CONTROL COMMAND .......................................................22FIGURE 7-1 SATELLITE IRD CONNECTED TO NCAM...................................................................23FIGURE 7-2 COMMAND EXCHANGE BETWEEN CONTROLLER AND CA SUBUNIT ............................24

List of Tables

TABLE 4-1 ALLOWED CONNECTIONS TO A CA SUBUNIT ................................................................8TABLE 5-1 DEFINITION OF CA_SUBUNIT_VERSION ......................................................................10TABLE 5-2 SYSTEM ID CODES ....................................................................................................10TABLE 5-3 IMPLEMENTATION PROFILES ......................................................................................11TABLE 5-4 STATUS DESCRIPTION ................................................................................................14TABLE 5-5 CA SUBUNIT STATUS DESCRIPTOR IDENTIFIER...........................................................14TABLE 6-1 CA SUBUNIT COMMANDS..........................................................................................15TABLE 6-2 SYSTEM ID CODES ....................................................................................................15TABLE 6-3 DEFINITION OF ACTION ..............................................................................................16TABLE 6-4 DEFINITION OF STATUS ..............................................................................................18TABLE 6-5 DEFINITION OF STATUS FIELD.....................................................................................18TABLE 6-6 DEFINITION OF STATUS FIELD FOR STATUS AND NOTIFY COMMANDS .....................20TABLE 6-7 DEFINITION OF ENTITLEMENT_STATUS .......................................................................21

April 6, 1999, 1999007 AV/C CA Subunit Specification. 1.0

Copyright 1998-1999, 1394 Trade Association. All rights reserved. Page 1

Preface

This document is the specification for an AV/C CA subunit. The CA subunit is a stand-alone pieceof functionality that is used to descramble selected scrambled services. The model describes ageneric functional block and command set that is compatible with multiple conditional access andbroadcast systems.

The CA Subunit provides the core functionality that is required to descramble selected services.The CA Subunit supports commands that allow the user to select a service or group of services tobe descrambled, assuming that they have entitlement, and to query a future service for entitlement.

AV/C CA Subunit Specification 1.0 April 6, 1999, 1999007

Page 2 Copyright 1998-1999, 1394 Trade Association. All rights reserved.

1. Normative References

The following documents may be useful to the reader interested in learning about the full AV/Cprotocol and related technologies. All standards are subject to revision; the reader is encouraged toinvestigate the possibility of applying the most recent editions of the documents listed below.

This AV/C CA Model and Command Set Specification must be used in conjunction with thegeneral AV/C specification. These specifications are referenced below.

1.1 Contact Information

The documents referenced herein may be obtained from the following organizations:

1.1.1 1394 Trade Association (1394 TA)

The 1394 Trade Association can be contacted via the references provided on the cover page of thisand all AV/C specification documents.

1.1.2 European Telecommunications Standards (ETSI)

ETSI SecretariatPostal Address: F–06921 Sophia Antipolis Cedex – FranceOffice Address: 650 Route des Lucioles – Sophia Antipolis

Valbonne – France

Phone: +33 4 92 94 42 00Fax: +33 4 93 65 47 16Internet: [email protected]

http://www.etsi.fr

1.1.3 International Electrotechnical Commission (IEC)(contact in the USA)

U.S. National Committee of the IEC ANSI11, West 42nd Street, 13th FloorNew York, NY 10036

Phone: +1 212 642 4900+1 212 642 4980 (sales)

Fax: +1 212 398 0023Internet: http://www.ansi.org

Documents can be ordered from

http://www.iec.ch/cs1ord-e.htmhttp://www/iec.ch/cs10i-e.htm



1.1.4 The Institute of Electrical and Electronic Engineers,Inc. (IEEE)

The IEEE can be contacted via their WWW homepage at: http://www.ieee.org

1.1.5 The Digital Transmission License Administrator,(DTLA)

The DTLA can be contacted via their WWW homepage at: http://www.dtcp.com

or via Email: [email protected]

1.2 1394 Trade Association Specifications

[1] AV/C Digital Interface Command Set, Version 3.0, April 15, 1998.[2] AV/C Tuner Model and Command Set, Version 1.0, April 15,1998.[3] Enhancements to the AV/C General Specification 3.0, Version 1.0 FC2.[4] AV/C Compatible Asynchronous Serial Bus Connections, Version 1.0 FC2.[5] AV/C Digital Interface Command Set for Secure Bus System, Version 1.0 FC2.

1.3 Related Specifications

[6] IEEE 1394-1995, Standard for a High Performance Serial Bus, 30 August 1996.[7] pr ETS 300 468 Specification for Service Information (SI) in Digital Video Broadcasting

(DVB) Systems.[8] ISP/IEC 13818–1 Generic Coding of Moving Picture and Associated Audio Systems.



2. Change History

There are no change notes for version 1.0 of the document.



3. Definitions and Abbreviations

3.1 Conformance Glossary

Several keywords are used to differentiate between different levels of requirement and optionality,as follows:

expected: A keyword used to describe the behavior of the hardware or software in thedesign models assumed by this specification. Other hardware and softwaredesign models also may be implemented.

may: A keyword that indicates flexibility of choice with no implied preference.shall: A keyword indicating a mandatory requirement. Designers are required to

implement all such mandatory requirements to ensure interoperability with otherproducts conforming to this specification.

should: A keyword indicating flexibility of choice with a strongly preferred alternative.Equivalent to the phrase “is recommended”.

3.2 Technical Glossary

CA: Conditional Access, a mechanism to control access to private data broadcasts,such as subscription services and pay per view services.

DTV: Digital Television, a device that is capable of receiving and displaying digitalcontent.

DVB: Digital Video Broadcasting.EMM: Entitlement Management Message.EPG: Electronic Program Guide.IRD: Integrated Receiver Decoder, a device that is used to decode and/or display

digitally broadcast material.IHDN: In Home Digital Network, a collection of devices that are interconnected using

IEEE 1394-1995.MMI: Man Machine Interface, an interface that is provided to allow the user to interact

with a device.MPEG: Motion Picture Expert Group.NCAM: Networked Conditional Access, a device that is used to descramble material that is

protected using a particular Conditional Access system. Networked ConditionalAccess differs from conventional CA systems by allowing the device thatdescrambles the content to exist somewhere on the IHDN rather than requiring itto be either embedded or implemented as a private resource to a single IRD.

OSD: On Screen Display, graphics that are presented on a display device to conveyinformation to the user.

PANEL: This term is used to describe OSD information that a device can export to anothersuitable device for display and possible user interaction.

PID: Packet Identifier, a number used in MPEG–2 transmission to distinguish betweendifferent packets of data. Each service is made up from different packets of data,for example, video and audio.

PMT: Program Map Table.TS: Transport Stream. The term for a data channel that contains information relating to

audio, visual and data services.



4. CA Subunit Model

4.1 The Basic CA Subunit

The CA subunit models the core functionality of a descrambler. The CA subunit receivesscrambled streams, descrambles them, and then outputs a descrambled stream. The CA subunitcommunicates with other required subunits via asynchronous commands across the 1394 [6]network.

The CA subunit can be a stand-alone device or integrated into another device. The followingdiagram illustrates the simplest model.

Figure 4-1 The Basic CA Subunit

4.1.1 CA subunit destination plug

The CA subunit destination plug is the input to the subunit. The signal format shall be compliantwith the system(s) supported by the CA mechanism. The CA subunit destination plug can connecteither directly to the serial bus (1394) input plug or to the source plug of another suitable subunit;for example the input to the CA subunit could be a tuner subunit.

4.1.2 CA subunit source plug

The CA subunit source plug is the output of the subunit. The signal format shall be compliant withthe system(s) supported by the CA mechanism. The CA subunit source plug can connect eitherdirectly to the serial bus output plug or to the destination plug of another suitable subunit.

4.1.3 Multiple plugs

A CA subunit that implements a single source and destination plug is potentially capable ofdescrambling one or more services within an isochronous channel from a single source, providingthe CA system is compatible with the source material.

Depending on the hardware capability of the CA subunit it is possible to implement multipledestination and source plugs. There should be an equal number of source and destination plugs.Such a configuration would allow a single CA subunit to provide descrambling of severalindependent streams/services at the same time. This model allows a very flexible, distributed AVnetwork environment.

The Basic CA subunit

CA subunitdestination plug CA subunit

source plug

CA subunitdestination plug CA subunit

source plug



4.1.4 Connections

When making connections between the CA subunit destination plug and either the serial bus inputor another subunit the connection must be established manually using a CONNECT command.This connection must be made before issuing a CA command. If the CA subunit is operating in astand-alone mode then the destination and source plugs of the subunit can be permanentlyconnected to the input and output serial bus plugs.

If the CA subunit has an existing connection which has been locked and an additional connectionis requested then a response of REJECTED shall be returned. If the connection is permanent thenthe conflicting command shall generate a response of NOT IMPLEMENTED.

It is necessary to use the CONNECT command to connect the CA subunit source plugs to eitheranother subunit or the serial bus output plugs.

All current connections of CA subunits shall be reported by the CONNECT status orCONNECTIONS status commands. This includes all permanent connections. A controller candetermine if a connection is permanent by examining the “perm” flag of the responses for theCONNECT status and CONNECTIONS status commands.

The connection of the CA subunit to other subunits is implementation specific. Whether it islogical to allow the connection of the CA subunit to certain other subunits should be considered atimplementation time.

The normal scenario for the implementation of a CA subunit is to either have the subunit inside areceiver, which is a device defined as one that contains a tuner subunit, or as a stand-alone device.The following diagram illustrates how a CA subunit would appear in a receiver; in a stand-alonedevice, there would likely be no antenna input plug (only 1394 serial bus and possibly “external”input plugs).

Figure 4-2 CA Subunit Logical Connections

The following table illustrates the various combinations of connections between a receiver unitand a CA subunit plugs and which ones are valid or not. All invalid connections shall generate aresponse of NOT IMPLEMENTED.

External inputplug

Serial Bus(1394) inputplug

CA subunitdestinationplug

CA subunitsource plug

CA subunit

Antennainput plug

Serial Bus(1394) outputplug

Externaloutput plug

Receiver Unit



Non CA Subunit Plug CA Subunit Plug ConnectionValid ?

Comments

External antenna input plug CA destination plug NO XExternal antenna input plug CA source plug NO XExternal input plug CA destination plug NO XExternal input plug CA source plug NO XExternal output plug CA destination plug NO XExternal output plug CA source plug NO XSerial bus input plug CA destination plug YES This connection must be

created using a CONNECTcommand, or it may be a

permanent connectionSerial bus input plug CA source plug NO XSerial bus output plugs CA destination plug NO XSerial bus output plugs CA source plug YES This connection must be


permanent connectionSubunit source plug CA destination plug YES This connection must be


permanent connectionSubunit source plug CA source plug NO XSubunit destination plug CA destination plug NO XSubunit destination plug CA source plug YES This connection must be


permanent connection

Table 4-1 Allowed Connections to a CA Subunit

When issuing the CONNECT Command the lock bit should be used to ensure that connections arenot broken by third parties.

4.2 Full and Partial Transport Stream Handling

The CA subunit can handle both full and partial transport streams. It is beneficial for the source tocreate a partial transport stream containing the elements of the service it wishes descrambled inorder to save bandwidth on the bus. In the case where a partial transport stream is created and theEMMs are embedded in the transport stream the source must take care to include the EMMs in thepartial transport stream. It will not be possible for the CA subunit to descramble the desiredservices if the data contained in the EMMs is not present.

4.3 Protection of Copyrighted Material

The CA system is used to prevent unauthorised access to broadcast material. Clearly once thematerial has been descrambled it must be protected when carried over the IHDN. The CA subunitshould implement a suitable Copy Protection system on both its destination and source plugs.



5. CA Subunit Identifier Descriptor, StatusDescriptor, Objects and Object Lists

5.1 Text Field Encoding

All text fields in the descriptors specified in this section (subunit identifier descriptor and statusdescriptor) shall be encoded as printable English ASCII text as defined in the IEEE 1212 standard,section 8.1.4 of the 1994-10-05 edition. Each text character is one byte.

The exception to this rule is for those data structure fields which are defined by the particularbroadcast system that they represent. In those cases, the broadcast system will specify the textfield encoding rules.

5.2 CA Subunit Identifier Descriptor

In the case of a CA subunit, the SUBUNIT IDENTIFIER describes the characteristics of thebroadcast system(s) and CA system(s) supported by the CA device. More than one broadcastingsystem and CA system may be supported by a CA subunit.

The CA subunit will use the defined general subunit identifier descriptor. The general descriptor isfully explained in the AV/C Digital Interface Command Set reference [1].

The CA subunit shall have the following subunit_dependent_information within the subunitidentifier descriptor.

Address offset msb lsb

0016

0116

CA_subunit_dependent_info_fields_length

0216 CA_subunit_version0316 number_of_systems [n]0416

:system_specification[0]

: :::

system_specification[n-1]

:::

optional info blocks for future expansion

Figure 5-1 CA Subunit Identifier Descriptor

The CA_subunit_dependent_info_fields_length field specifies the number of bytes for the non-infoblock fields of the subunit dependent information; in this case, through thesystem_specification[n-1].

Controllers should be prepared to find any number of information blocks following this field, incase the CA subunit dependent information needs to be extended in the future. Controllers caneasily determine if any info blocks exist here by comparing the CA_subunit_dependent_length andCA_subunit_dependent_info_fields_length fields. If the following formula is true:



CA_subunit_dependent_length > (CA_subunit_dependent_info_fields_length + 2)

then info blocks exist in this structure.

The CA_subunit_version field indicates the version number of CA subunit command specificationthat the CA subunit conforms to. The upper 4 bits show the major version number and the lower 4bits the minor version number.

CA_subunit_version meaning1016 Version 1.0 of the CA subunit specification

all others Reserved for future specification

Table 5-1 Definition of CA_subunit_version

The number_of_systems field specifies how many broadcast systems are supported by this CAsubunit.

The system_specification field describes each broadcast system, each has the following format.

Address offset msb lsb

0016

0116

specification_length

0216 system_id0316 implementation_profile_id0416 number_of_CA_system_ids(m)0516 CA_system_id_length[0]

:: CA_system_id[0]:: :: CA_system_id_length[m-1]:: CA_system_id[m-1]:

Figure 5-2 System Specification

The specification_length field indicates the size, in bytes of the entire system_specificationstructure.

The system_id field indicates a broadcast system that the CA subunit supports. The followingbroadcast systems are currently defined:

system_id name2016 DVB

other values reserved

Table 5-2 System ID Codes

The implementation_profile_id field specifies the profile ID of the CA subunit for this system_id.A CA subunit may be implemented with a different profile for each of the broadcast systems thatit supports. There shall be one profile for each supported system. The following profiles arecurrently defined:



implementation_profile_id meaningE016 conformant_implementation – a CA subunit with this implementation

profile ID was created based on the AV/C CA Specification version 1.0.The set of features (commands and data structures) supported by thisimplementation is defined by the manufacturer. This profile ID appliesto all broadcast systems.

E116 conformant_full_implementation – a CA subunit with this profileimplementation is as described above, but it implements all of thecommands and relevant data structures for the specified broadcastsystem, as defined in the AV/C CA Specification version 1.0. Thisprofile ID applies to all broadcast systems.

All other values reserved for future specification in this AV/C CA Specification

Table 5-3 Implementation Profiles

The number_of_CA_system_ids field indicates the number of CA systems the CA subunit iscompatible with.

The CA_system_id fields identify a particular CA system. The values for CA_system_id aresystem_id dependent and in the DVB case they are defined in [7]. The CA_system_id_length fielddefines the length in bytes of the CA_system_id field.

5.3 CA Subunit Status Descriptor

The CA status descriptor structure is specific to CA subunits. It holds information about the CAsubunit in general, and about the information that is on each of its source plugs. The data heldwithin this structure is dynamic and is kept up to date by the CA subunit. A controller mayexamine this structure in order to determine the operational status of the CA subunit and its sourceplugs.

The general format of the CA status descriptor is as follows:

address offset msb lsb

00 0016 descriptor_length00 0116

00 0216

: general_CA_subunit_status_info_block::::

source_plug_status_area_info_block

Figure 5-3 CA Status Descriptor

The descriptor_length is the number of bytes for the CA subunit status descriptor structure, notincluding the descriptor_length field.



5.3.1 General CA Subunit Status Area Info Block (90 001 6)

The general_CA_subunit_status_area_info_block contains status information about the CAsubunit that is not specific to a particular destination or source plug. It has the following format.


00 0016

00 0116

compound_length

00 0216

00 0316

info_block_type = 90 0016 (general_CA_subunit_status_area_info_block)

00 0416

00 0516

primary_field_length

00 0616 reserved00 0716 available_bandwidth_upper00 0816 available_bandwidth_lower

Figure 5-4 general_CA_subunit_status_area_info_block

The compound_length field specifies the number of bytes for the remainder of this informationblock (including any nested information blocks which may occur after the last well defined field).

The primary_field_length is the number of bytes for the remaining fields.

The available_bandwidth_upper and available_bandwidth_lower fields should be read togetherand indicate the bandwidth capacity the CA subunit has available. Theavailable_bandwidth_upper field indicates the integer amount of bandwidth available in Mbps.The available_bandwidth_lower indicates the fractional amount of bandwidth available in Mbps.

For example if the CA subunit has 34.8Mbps of bandwidth available it would be represented asfollows.

available_bandwidth_upper = 00 2216

available_bandwidth_lower = 0816

The values of 0F FF16 for available_bandwidth_upper and FF16 for available_bandwidth_lower arereserved and indicate that the CA Subunit cannot determine the amount of available bandwidth.

This allows a device such as a tuner subunit to determine whether the CA subunit has enoughspare capacity for additional services to be descrambled. If the CA subunit can support thesimultaneous descrambling of multiple services from multiple sources then theavailable_bandwidth can be read in conjunction with the destination_plug_status fields to allow acontroller to determine whether it is able to connect an additional source to the CA subunit.



5.3.2 Source Plug Status Area Info Block (90 011 6)


0016

0116

compound_length

0216

0316

info_block_type = 90 0116 (source_plug_status_area_info_block)

0416

0516

primary_fields_length

0616 number_of_source_plugs (n)0716

::

nested plug_status_info_block structures

Figure 5-5 source_plug_status_area_info_block

The number_of_source_plugs field specifies the number of source plugs on this subunit, andhence the number of plug_status_info_block structures that are nested in this info block. Thestructures are located sequentially, not nested inside of each other. Most simple CA subunits willprobably have only one source plug.

5.3.3 Plug Status Info Block (90 021 6)

The plug_status_info_block[x] fields provide status information for each of the source plugs.There shall be one of these structures for each source plug on the CA subunit, even if the plugcurrently has no status information to report. These fields are each split into two general areas, asshown below.


00 0016

00 0116

compound_length

00 0216

00 0316

info_block_type = 90 0216 (plug_status_info_block)

00 0416

00 0516

primary_fields_length

00 0616 source_plug00 0716 destination_plug00 0816 status

Figure 5-6 plug_status_info_block

The source_plug field indicates the actual source plug number.

The destination_plug field indicates the destination_plug number that this source_plug is relevantto.

The status field describes the current situation of the source_plug according to the table below.

value status description0016 No information instances are on the specified

source plug.



1016 A descrambled version of the service(s) requestedfor descrambling is(are) currently on the specifiedsource plug.

2016 A descrambled version of the service(s) requestedshould be on the specified source plug, however itis (they are) not currently on the plug.

Table 5-4 status Description

Case 1016 is used when the CA subunit is functioning correctly and is outputting the requestedservice in a descrambled state. Case 2016 is used when the CA subunit has responded that it candescramble the selected service but at present the descrambled service is not available on the plug.

5.3.4 Descriptor Identifier for the CA subunit StatusDescriptor

The CA subunit Status descriptor is specific to the CA subunit type; it has the following typevalue.

descriptor_type meaning8016 CA Status Descriptor

Table 5-5 CA Subunit Status Descriptor Identifier

The descriptor_type_specific_reference field does not exist because there is only one CA statusdescriptor for a CA subunit.

5.4 CA Model Objects and Object Lists

The CA subunit model does not feature any object lists.



6. CA Subunit Commands

CA subunit commands are identified by a subunit_type of 0616 (provisional). This section defineshow the commands are used.

Support level(by ctype)

Opcode Value

C S N

Comments

CA_ENABLE CC16 M M O Used to instruct the CA subunitto begin descrambling theservice defined in the broadcastspecific data.

CA_ENTITLEMENT CD16 – O O Used to allow a controller toquery the CA subunit todetermine whether the user hasentitlement for a specifiedservice.

SECURITY 0F16 O O O Used for validation purposesbetween a controller and theCA Subunit

Key: M= mandatory, O = optional and – = not supported

Table 6-1 CA Subunit Commands

6.1 CA_ENABLE

The CA_ENABLE command is used to instruct the CA subunit as to which service it shoulddescramble. The command is broadcast specific.

6.1.1 CA_ENABLE Control Command

The CA_ENABLE control command will take the following form.

msb lsbopcode CA_ENABLE (CC16)

operand[0] system_idoperand[1]

: broadcast_system_specific_data

:

Figure 6-1 CA_ENABLE Control Command

The system_id field denotes which broadcast system the following command relates to. Thefollowing systems are currently defined:

system_id name2016 DVB

Other values reserved

Table 6-2 System ID Codes

The broadcast_system_specific_data field contains operands that are specific to the system beingused.



6.1.1.1 DVB System Specific Operands

The following operands fully specify the service to be descrambled. The PID for each componentof the service is identified.

If one of the component subunits of a controller is a tuner subunit then the controller has theservice_id and PID values available to it privately. However, if a controller wishes to make use ofanother suitable receiving device then the controller must inspect the service and componentdescriptors of the tuner subunit in the receiving device. The controller must define the PIDs of thecomponents of the desired service.

msb lsboperand [1] actionoperand [2] FF16

operand [3]operand [4]

service_id

operand [5] number_of_elementary_PID_definitions[m]operand [6]operand [7]operand [8]

elementary_PID_definition[1]

: :operand [x]

operand [x+1]operand [x+2]

elementary_PID_definition[m-1]

Figure 6-2 DVB Specific Data Entries

A separate CA_ENABLE command is sent for each service that is to be descrambled. The actionfield is used to update the list of selected services stored in the CA subunit. The following valuesare defined.

action valueadd 0016

update 1016

remove 2016

remove_all 3016

reserved Other values

Table 6-3 Definition of action

When action is set to “add” the selected service is added to the list of services selected fordescrambling. “update” indicates that a selected service should be modified in some way. Sincethe list management commands only act at the program level, any changes at the elementarystream level in an existing service must be signalled by an 'update' command with the completeelementary stream list re-sent. “remove” allows one service to be deleted from the list.“remove_all” is used when the descrambling of all services is no longer required.

The service_id field specifies the service to which the program_map_PID is applicable.

The number_of_elementary_PID_definitions field indicates the number of followingelementary_PID fields.



msb lsboperand [x] stream_type

operand [x+1] reserved elementary_PIDoperand [x+2]

Figure 6-3 elementary_PID_definition

The stream_type field identifies the type of service element carried within the packets with thePID whose value is specified by the elementary _PID. The values are defined in table 2–29 of [8].

The elementary_PID field specifies the PID of the transport stream packets that carry theassociated service element.

6.1.2 Response to a CA_ENABLE Control Command

The response will have the following format.

msb lsbopcode CA_ENABLE (CC16)


: broadcast_system_specific_data

:

Figure 6-4 CA_ENABLE response

The operands have the same meaning as for the CA_ENABLE control command.


Currently the CA_ENABLE response is defined for the DVB broadcast system.

msb lsboperand [1] actionoperand [2] statusoperand [3]operand [4]

service_id



: :operand [x]



Figure 6-5 DVB Specific Response for CA_ENABLE

The response format is the same as for the control command with the addition of the statusoperand.

In the case where action is “add” or “update” and the CA_ENABLE command is successful theresponse will be ACCEPTED. status can take on the following values. The value of status reflectsthe action.



action status Valueadd descrambling 0016

add descrambling possible under conditions (purchase dialog) 0116

add descrambling possible under conditions (technical dialog) 0216

update descrambling 1016

update descrambling possible under conditions (purchase dialog) 1116

update descrambling possible under conditions (technical dialog) 1216

remove remove_successful 2016

remove_all remove_successful 3016

Table 6-4 Definition of status

In the case where an add or update command is successful then the response is “descrambling”.However there may be some cases where it is theoretically possible to descramble the service butthere are certain conditions that must first be satisfied. The “descrambling possible underconditions” messages are returned in this case. There are two types of conditional responses,“purchase dialogue” and “technical dialog”. Both dialogs require an interaction with the user viathe man machine interface (MMI).

The purchase dialog is required, for example, where the user has requested a pay per view service.Here a dialog with the user might be required to confirm the cost of the service before viewing cancommence.

The technical dialog is required when there is a technical issue to overcome before the CA subunitcan determine whether it is possible or not to descramble the service. This could occur, forexample, when the user needs to insert the smart card.

In the case where the CA_ENABLE command is unsuccessful the response frame will use theresponse code of REJECTED. The status field will take on the following values to reflect thenature of the error. The value of status reflects the action.

action status Valueadd descrambling not possible 8016

add descrambling not possible (because no entitlement) 8116

add descrambling not possible (for technical reasons) 8216

add descrambling not possible (Insufficient bandwidth in CA subunit) 8316

add descrambling not possible (Incompatible CA system) 8416

update descrambling not possible 9016

update descrambling not possible (because no entitlement) 9116

update descrambling not possible (for technical reasons) 9216

update descrambling not possible (Insufficient bandwidth in CA subunit) 9316

update descrambling not possible (Incompatible CA system) 9416

remove remove failed –service not present A016

remove remove failed – unknown reason A116

remove_all remove failed – service not present B016

remove_all remove failed – unknown reason B116

Table 6-5 Definition of status field

6.1.3 CA_ENABLE Status and Notify Commands

The CA_ENABLE command can also be sent with a ctype of STATUS and NOTIFY as describedin the AV/C Tuner Specification [2]. The Status and Notify command frames have the same formas the Control command. The command is used to determine whether the CA subunit is capable ofdescrambling the selected service.




msb lsboperand [1] actionoperand [2] FF16


service_id



: :operand [x]



Figure 6-6 Status or Notify Command Structure for DVB Broadcast System

The fields are the same as for the Control Command.

6.1.4 Response to a CA_ENABLE Status and NotifyCommands


msb lsboperand [1] actionoperand [2] statusoperand [3]operand [4]

service_id



: :operand [x]



Figure 6-7 Status or Notify Response Structure for DVB Broadcast System

The fields are the same as for the COMMAND response with the exception of the status field,which can take the values defined below. The “remove” action is not valid for STATUS orNOTIFY commands.

action status Valueadd descrambling will be possible 0016

add descrambling will be possible under conditions (purchase dialog) 0116

add descrambling will be possible under conditions (technical dialog) 0216

update descrambling will be possible 1016

update descrambling will be possible under conditions (purchase dialog) 1116

update descrambling will be possible under conditions (technical dialog) 1216

add descrambling will not be possible 8016

add descrambling will not be possible (because no entitlement) 8116



add descrambling will not be possible (for technical reasons) 8216

add descrambling will not be possible (Insufficient bandwidth in CA subunit) 8316

add descrambling will not be possible (Incompatible CA system) 8416

update descrambling will not be possible 9016

update descrambling will not be possible (because no entitlement) 9116

update descrambling will not be possible (for technical reasons) 9216

update descrambling will not be possible (Insufficient bandwidth in CA subunit) 9316

update descrambling will not be possible (Incompatible CA system) 9416

Table 6-6 Definition of Status field for STATUS and NOTIFY Commands

6.2 CA_ENTITLEMENT

This command is used by EPG applications to interrogate the CA subunit to determine whatentitlement the user has to services found in the EPG. The command can be used with a ctype ofSTATUS and NOTIFY. This command does not prevent EPG and CA applications from the sameor co-operating suppliers to develop private means of passing entitlement information. Thiscommand should be used by independent EPGs to interrogate CA modules.

6.2.1 CA_ENTITLEMENT Command

msb lsbopcode CA_ENTITLEMENT (CD16)


: broadcast_system_specific_data:

Figure 6-8 Format of CA_ENTITLEMENT Command

The system_id field has the same meaning as for the CA_ENABLE command.

The broadcast_system_specific_data field contains operands that are specific to the system beingused.


msb lsboperand [1]operand [2]

network_id


original_network_id


transport_stream_id


service_id


event_id

operand [11] FF16

Figure 6-9 DVB Specific Operands for CA_ENTITLEMENT Command

The operands network_id, original_network_id, transport_stream_id, service_id and event_idspecify the service that the entitlement query is for. These operands are specified in [7]. Theevent_id is fully qualified by the other location identifiers in the service information.



6.2.2 CA_ENTILEMENT Response

The CA_ENTITLEMENT has the following response.

msb lsbopcode CA_ENTITLEMENT (CD16)


: broadcast_system_specific_data:

Figure 6-10 CA_ENTITLEMENT Response


msb lsboperand [1]operand [2]

network_id


original_network_id


transport_stream_id


service_id


event_id

operand [11] entitlement_status

Figure 6-11 DVB Specific Operands for CA_ENTITLEMENT Response

The operands network_id, original_network_id, transport_stream_id, service_id and event_id arethe same as for the command. The entitlement_status field denotes the whether or not the user hasentitlement to the selected service.

value entitlement_status Description00 entitlement unknown The CA subunit cannot determine the

entitlement status for this service01 entitlement available Entitlement for this service is currently

available02 entitlement not available Entitlement for this event is not currently

available and cannot be made available by anyuser dialogue with the CA subunit

03 user dialogue required Entitlement is not currently available but couldbe made available after a user dialogue withthe CA subunit

04 user dialogue complete unknown The user dialogue is complete the entitlementis unknown

05 user dialogue complete available The user dialogue is complete and entitlementhas been granted

06 user dialogue complete notavailable

The user dialogue is complete and entitlementhas not been granted

other values reserved The remaining values are reserved for futureuse

Table 6-7 Definition of entitlement_status



6.3 SECURITY

Although the concept of the CA Subunit is to allow generic receivers to work with multiple CAsystems there may be some cases when a service provider will wish to associate a certain CASubunit with a certain IRD. In this case authentication is used between the CA Subunit and theIRD to ensure that each device only works with its respective partner.

The SECURITY command is independent of broadcast system as it is uniquely defined for eachapplication. The SECURITY Command is currently defined in AV/C Digital Interface CommandSet for Secure Bus System [5]. The authentication protocol is a process whereby the IRD and CASubunit pass between themselves control codes to allow each device to satisfy itself that the otheris genuine. The authentication protocol could be as simple as transferring two known keysbetween the devices or a more complex key exchange based upon, for example, public keyprotocols.

msb lsbopcode SECURITY (0F16)

operand[0] category (msb)operand[1]

:operand[x]

category dependant field(lsb)

Figure 6-12 Format of SECURITY Control Command

The category field defines the authentication and key exchange protocol that is used in thefollowing category dependant field. Currently the only category defined is the Authentication andKey Exchange defined by the DTLA.

Implementers wishing to make use of this command must either define the format of the categorydependent field and update the AV/C Digital Interface Command Set for Secure Bus Systemspecification accordingly or can use a vendor unique protocol.



7. Operational Guidelines (Informative)

The following provides an explanation as to how the CA Subunit will be implemented and theprocedure that shall be followed to make use of the CA Subunit.

The NCAM is a logical collection of subunits that provide the required functionality to implementa networked conditional access system. The CA subunit is the core of the system and relies onother subunits to provide a source and sink for the material that requires descrambling andcommunication with both the user and outside world. As such the CA subunit must be aware ofthe tuner subunit and panel subunit.

The NCAM can be implemented with only the tuner, CA and Panel subunits; these are theminimum requirements. The resources that the CA system may also require such as a modemand/or smart card reader can be implemented and accessed privately when they form part of thesame unit.

The procedure for decoding a scrambled transport stream is as follows. The following assumesthat the tuner subunit will be the source of the scrambled stream, either an off air signal via asuitable front end or directly from the demux via an alternative source such as a DVCR. The userwill a make a channel selection and the tuner subunit will detect that the stream is scrambled.

PanelSubunit

CA Subunit

DemuxTunerSubnunit

Satellite

MPEG

Scrambled Transport Stream

Clear Transport Stream

Controller

Control Commands

PanelSubunit

Figure 7-1 Satellite IRD Connected to NCAM

The controller can make an intelligent prediction as to which CA subunit to use based upon theCA_system_id field from the transport stream and CA_system_id of the CA subunit. For examplein Figure 7–1 satellite IRD is connected to a CA Subunit via 1394.

The controller establishes an isochronous channel between the tuner and CA subunits to transmitthe scrambled service to the CA subunit. A second channel from the CA subunit to the desiredsink, this can be the unit that originates the scrambled source material or a separate unit, is set up.The 5C Copy Protection system can be used to protect the descrambled transport stream fromunauthorised copying.

The controller then sends the CA_ENABLE command to inform the CA subunit of which serviceor services it would like descrambled. When the CA subunit receives the CA_ENABLE commandit determines whether or not it is capable of descrambling the selected service. This may involvesetting up a dialog with the user to determine whether they are prepared to pay for the service orrequest them to insert their bank card or pin number. Some communication with the outside worldvia the modem may be required.



If following the user dialog the CA subunit is capable of descrambling the selected services itupdates its internal status registers and starts output the descrambled data.

Due to the nature of AV/C commands whereby each command requires a response, if the originalCA_ENABLE command is met with a REJECTED response due to a user or technical dialoguebeing required then once the dialogue is resolved the controller will not know the outcome.Therefore if a CA_ENABLE command is rejected for dialogue reasons then the controller shouldsend a NOTIFY command to be informed when the state of the CA subunit changes.

1394Controller CA

Subunit

Return CAsystem id

User selects a scrambled service towatch. Controller sets up isochronouschannels

Controller sends CA Enable commandwith details of service to bedescrambled

CA Subunit returns a response,OK or refused for technical orpurchase dialog

Start PanelSession CA Subunit enters into dialog

with the user

Controller can use notify or statuscommands to discover a change of statethat may occur in the CA subunit as aresult of the dialog with the user

If the dialog is successful the CAsubunit returns the descrambledstream

Figure 7-2 Command Exchange between Controller and CA Subunit

7.1 Bandwidth Utilization

The controller should handle the transport stream intelligently. The IHDN is of limited bandwidth,so partial transport streams should be passed to the CA subunit. The controller must ensure that alltables are suitably modified to indicate that the stream is a partial transport stream. Some of thedata carried to enable conditional access is carried in private data fields. Hence the controller mustnot send only the relevant audio and video channels. One possible method for reducing thebandwidth of the transport stream is to remove those audio and video channels that are notrequired and modifying the required tables to indicate the channels form a partial transport stream.



7.2 EMM Handling

In some implementations of a DTV receiver the CA module can receive EMMs whilst the DTV isin standby and on power states. This allows the CA module to continually update the entitlementthat the user has.

In a network environment the TS must be routed to the CA subunit to allow the subunit to processthe EMM packets. This means that if the CA subunit remains powered off or a TS is not connectedto it for a period of time then the entitlement stored in the CA subunit may become out of date.Therefore at periodic intervals the CA subunit should contact the tuner subunit and request the TSfor a period of time to allow it to update the EMMs. This should be done at times when the userexperience will not be compromised. The controller should ensure that the channel is not changedwhile the user is watching a particular service.

7.3 Out-Of-Band (OOB) Support

Some broadcast mechanisms use out-of-band (OOB) data as part of the conditional accessmechanism. In such systems, receivers generally need a separate antenna to receive the OOB data,and subsequently route it to the CA mechanism inside the receiver (set top box). The NCAMmodel can easily support such systems, making use of the AV/C and 1394 technologies.

The implementation of how the OOB data is supplied to the CA subunit is dependent on theimplementation. If the CA subunit is located in a device that has an OOB tuner then the OOB datacan be routed to the CA subunit in a private manner that is outside the scope of this document.

Alternative methods are to stream the OOB data across an isochronous channel to the CA subunit.However this method requires extra hardware capabilities in the device. For example the linkdevice would have to be capable of supporting at least three isochronous FIFOs, perhaps fourdepending on how the return channel is implemented.

The Asynchronous Connections protocol [4] could be used instead. In this case the OOB data issent streamed across an Asynchronous Connection. This method does not require additionalhardware capabilities but does have the drawback in that when the data traffic on the IHDN is at apeak the performance of the Asynchronous Connection is decreased. This may lead to lost packets.However as the receiver does not need to process every piece of OOB data, only those packets thatare addressed to it this level of service may be acceptable.

The return channel to the Cable Modem could be implemented privately if the OOB tuner isimplemented in the same device as the CA Subunit as communication can be carried out privately.If either of the other two methods are selected then commands must be devised to control the flowof OOB data across the IHDN. At the moment this is considered as future work.

7.4 Implementations Where a Tuner Subunit is Absent

The benefit of using a CA subunit in a network where a tuner subunit also exists comes when thecontroller is external to both the unit that contains the tuner subunit and the unit that contains theCA subunit. This allows the controller to discover the services that the tuner subunit is capable ofreceiving and can instruct the CA subunit to descramble a number of these services.

In some cases the CA subunit will exist in a network where there is no tuner subunit. In this casein order for a device to make use of the CA subunit the controller must exist in the same unit asthat of the signal source. The controller must be capable of privately inspecting the transportstream and determining the PIDs of the elements of the service it wishes descrambled. Again theEMM stream must be included with the PIDs of the elements that are to be descrambled.