GB2336744A - Method of implementing a Command Interface over an IEEE 1394 Bus - Google Patents

Abstract

A method of implementing a Conditional Access Module (CAM) Command Interface over an IEEE 1394 serial bus comprises opening at least one isochronous channel over the bus and transmitting Command Interface data over the channel. Preferably, a Common Interface IEEE 1394 Specific Transport Layer is provided between the Generic Transport layer of the Common Interface and an IEC 1883 Implementation Link Layer. The Common Interface Specific Transport Layer and the Implementation Link Layer act to set up the appropriate isochronous channels without the need for any modification to the Common Interface. By implementing a Conditional Access Module on a bus network of digital multi-media devices, it is possible for the various functions available in the module to be provided to all the devices on the network.

Description

2336744 - 1 DIGITAL MULTI-MEDIA DEVICE AND METHOD RELATING THERETO The

present invention relates to a digital multimedia device such as a digital video device and an arrangement and method which allows the device to communicate with another device on a common bus.

In the field of digital video processing, it is known to code digital video signals such that special processing is needed in the receiver to be able to reproduce the video signals. In particular, it has been proposed to provide a Conditional Access Module which can perfor-m all of the descrambling and other conditional access functions of the digital TV receiver. This allows conditional access and signal decoding functions to be separated from a host receiver, such that a generic digital TV receiver can operate wilth many different conditional access systems in different Conditional Access Modules.

To allow communication between a Conditional Access Module and a digital TV receiver, a Common Interface has been proposed and standardized by CENELEC (E11,750221 Common Interface Specification for Conditional Access and other

Digital video Broadcasting Decoder Applications) This standard Common Interface defines a transport stream interface in which various virtual channels are time multiplexed and a Command Interface over which various additional command data are sent. The Common Interface thus allows connection of a Conditional Access Module to a - 2 digitall TV receiver or indeed any other digital video device.

As a basis for the present invention, it is now recognised that it would be advantageous to provide a Conditional Access Module on a local network of digital multi-media devices including audio and video devices, such that the various functions available in the Conditional Access Module can be provided to all of the devices on the network.

A standard has been proposed for connecting together varilous digital video devices on a local network. In,:,art-c.-,lar, I= 1394 is a 1995 IEEr- standard for a high ner.crTriance serial bus and defines a bus, which will be,-e-erre-- to as an I= 1394 Serial Bus, for connecting IS 1----=e--he-. various digital consumer audio/visual products.

The I= 1394 specification defines a physical ectrical signalling and a set of link and cz-,-iec:or, e-L transaction protocols allowing the serial bus to self and carry efficiently.

A further set'of additional protocols have also been defined to carry MPEG data and provide control mechanisms between, different items of equipment on the I= 1394 Serial Bus. These protocols are defined in the spec ifi ca t ion "Digital Interface for Consumer Electronic A-, jdio/Video Equipment" (IEC 1883).

The IEEF, 1394 specification defines mechanisms and protocols to carry two types of data, namely asynchronous and isochronous data.

Asynchronous data generally has no requirements on the transport mechanism regarding time, for example the jitter imposed or the delay in transmission. This data can be used for instance for file data or general command and status data.

on the other hand, isochronous data has strong requ'rements for low jitter and a fixed or bounded delay for transmission and may be used for MPEG coded audio and v-'de- data.

in view of the developments with the I= 1394 Serial Bus, -Lt is now considered to connect a Conditional Access Module to a number of different digital multi-media devices such as audio and/or video devices using the I= 1394 Seriall Bus. Unfortunately, however there are significant p.roblems in impIementing such a system. I= 1394 related prozo----ls have been deve'Loped that are intended for use screa7ns of s.- nc!'Le cha-.ne'-, YPEG, data and its o.w-r, protocols are provided for various command data. In particular, the Conditional Access Common Interface and the IEEE 1394 serial bus have set different standards.

The present invention concerns implementing the Command Interface over the I= 1394 Serial Bus.

According to the present invention there is provided a method of implementing a Common Interface Command inter-face over an IEEE 1394 Serial Bus comprising:

2 C opening at least one isochronous channel over the IEEE 1394 Serial Bus; and transmitting command data of the Command Interface over the isochronous channel.

According to the present invention there is provided a digital multi-media device comprising:

a port for an I= 1394 Serial Bus for communicating command data of a Command Interface; means for setting up at least one isochronous channel between the port and a remote device connected to the I= 1394 Serial Bus; and means for transmitting and/or receiving command data of the Command Interface over the isochronous channel.

According to the present invention there is also provided a digital multi-media device comprising:

a port for an I= 1394 Serial Sus for communicating com-mand data of a command interface; means for responding to a remote device on the I= 139-1- Serial Bus to set up at least one isochronous channel between the port and said remote device; and Tneans for transmitting and/or receiving command data of a Command Interface of the remote device from the isochronous channel.

In this way, once an isochronous channel is opened on the I= 1394 Serial Bus, there are no particular protocol re(-airements for the data transmitted over that channel.

Therefore, the Command Interface can transmit and receive command data over the set up isochronous channel without any need to modify the nature of the command data in accordance with the protocols used for the IEEE 1394 Serial Bus.

Preferably, at least two isochronous channels are set up between the port and the remote device to enable communication in both directions.

The present invention is applicable to any digital multi-media device including devices handling audio data, videc data, other multi-media data or a mixture thereof. it is particularly advantageous for digital video devices handling at least video data.

Preferably, the various devices may be Conditional mccess Modules, digital video receivers or other digital ILS video devices.

in th-'s way, devices connected to the IEEE 1394 Serial Bus may all make use of the functions of the Conditional Access Mc)dule.

In order to vary the bandwidth available for the command data, the host receiver or module that requires the extra bandwidth may contact the isochronous resource manager and request the extra bandwidth for this channel using I= 1394 protocols.

Preferably, a Common Interface IEEE 1394 Specific Transport Layer is provided between the Generic Transport Layer of the Common Interface and an iEC1883 Implementation Link Layer.

6 In this way, the Generic Transport Layer of the Common Interface may continue to operate in the same manner as proposed for the PC Card implementation with the lower different layers being transparent to it. The Common in'.',er"L'ace IEEE 1394 Specific Transport Layer and the IEC1883 Implementation Link Layer act to set up the appropriate isochronous channels without any need for modification of the Common Interface.

Thus, by virtue of the present invention, it is C. poss-be to preserve the higher layers of the existing DVB Common Interface as defined in EN50221, to make use of ex'st2-.ng protocols developed for the I= 1394 Serial Bus, to ensure operation alongside existing products designed use wIth the I= 1394 Pus, to ensure that the -- Lr-,--'.e7enl.ation allows further expansion to the DVB Common,n- erface standard to provide mechanisms to take advantage ol- the networked architecture of the IEEE 1394 Serial Bus and to ensure any extensions recraired to the DVB Common -nterface will still be com.nat-ible with the zresent specification.

The invention will be more clearly understood from the following description, given by way of example only, w-'th reference to the accompanying drawings in which:

Figure 1 illustrates a DVB Common Interface architecture; Figure 2(a) illustrates a network oil digital multimedia devices; Figure 2(b) illustrates a network of digital devices with a Conditional Access Module; Figure 3 illustrates an I= 1394 protocol stack; Figure 4 illustrates a DVB Common Interface PC card implementation protocol stack; Figure 5 illustrates a DVB Common Interface I= 1394 implementation protocol stack; Figure 6 illustrates schematically a device for implementing a Common Interface Command Interface over an I= 1394 Serial Bus; Figure 7 illustrates a DVB Common Interface IEEE 1394 implementation protocol stack; Figure 8 illustrates a device for implementing a Comm(:n Interface Command Interface over an I= 1394 Serial Bus; Faure 9 illustrates a Common Interface configuration usIng an IErEE 1394 Serial Bus; and Fig=re 10 illustrates a DVB Common Interface I= 1394 2Lrr.P-7ementa+.-ion Transport Stream Interface protocol stack; and Figures 11(a) and (b) illustrate a transport stream and associated table.

As mentioned above, a standard has already been specified for a Common Interface for a Conditional Access Module. Figure 1 illustrates the architecture of this standard.

As illustrated, a receiver or host 2 is connected to 2.11 v - 8 n 0 -L 1 5 a Common Interface Module such as a Conditional Access Module 4 by means of the Common Interface 6.

other types of Common Interface Module might include RF input front ends for receiving, for instance, satellite transmissions, audio decoders for 11Auditel" scene description for the visually impaired, audience metering modules, etc.

The DVB (Digital Video Broadcast) Common Interface spec if J-1cat ion currently defines the physical layer of the common interface to conform to the PC card standard as specified by the PCMCIA. In other words, physically the connection forming the Common Interface comprises a 68-way connector with the standard PC card arrangement as used in many personal computers today. However, the DVB Common Interface has been designed with a layered architecture to allow new physical layers (for example the smart card form factor) to be used with the same upper layer protocols. In other words, the processing conducted on either side of the Physical connection has been designed such that different physical arrangements can be used for the connection without changing the way in which the standardized Processing operates.

As illustrated in Figure 1, the DVB Common Interface includes two main parts, namely a transport stream interface 8 and a command interface 10.

The transport interface 8 is used to transfer a transport stream from the receiver or host 2 to the module - 9 4 and back to the receiver 2. In particular, the receiver 2 receives an RF input 12, a particular band is selected using a tuner 14 and this band is demodulated in the demodulator 16. The output of the demodulator 16 comprises a transport stream including time multiplexed virtual channels. These are transmitted over the transport stream interface 8 to a descrambler 18 in the module 4. The descram,bler 18 identifies those virtual channels for which it is intended and sends back to the receiver 2, over the transport stream interface 8, a transport stream in which selected virtual channels have been descrambled. In the rece-lver 2, a demultiplexer 20 selects a required virtual channel and passes MPEG packets relating to that virtual channel to an MPEG decoder 22 which, in turn, outputs an iS aud.bo/video output 24.

The second part of the DVB Common Interface is the command interface 10. This provides a high level protocol allo-wing the host receiver 2 and the module 4 to and, further-more, for Applications in either the host receiver 2 or module 4 to access Resources across the interface. In particular, standardized codes and data formats are provided for communication over the Command Interface.

A microprocessor 26 of the host receiver 2 and a Tr,..JLcropro--essor 28 of the module 4 can communicate using the Command Interface. Furthermore, the overall system may -,nclude a MODEM, a graphics generator, etc and the Command - 10 Interface can be used to transfer control information to these devices also. As an example, the module 4 may wish to communicate with a remote control centre via a MODEM for details of subscription fees and then control a TV display to indicate messages according to the subscription status. This communication can be achieved by means of the Command Interface 10.

As mentioned above, it has been proposed to link various digital video devices together using an IEEE 1394 Serial Bus. Fig-ure 2a illustrates a network in which a diwital TV receiver 30 is connected to a digital video recorder 32, in turn connected to a digital video disk machine 34, in turn connected to a personal computer 36.

The IEEE 1394 bus is a serial bus that allows a low cost mechanism to transmit audio, video and control information between equipment. It is very well suited to consumer audio/visual applications and is expected to bezo-me widely used for many new digital consumer audil c /visual products. It is particularly attractive in 2 G that it offers a "plug and play" operation. In other words, an additional device may be connected into the network without any special reconfiguring of the network and protocols are included whereby devices on the network automatically determine what other devices are present.

The I= 1394 Trade Association is an industry grouping that brings together all of the interested industry parties for the I= 1394 Serial Bus. This Trade Association has worked to define a set of protocols which of fer a set of commands to be carried over the I= 1394 Serial Bus in the format of the IEC 1883 Function Control Protocol (FCP) mentioned above. The set of commands are 5 known as Audio/Video Control -Command Transactions (AV/CCTS) and are specified in the AV/C digital Interface Command Set Document developed by the lEEE 1394 Trade Association (see AV/C Digital Interface Command Set Version 2.OD March 26, 1997 Audio/video Working Group of the I= 1394 Trade Association). The AV/C-CTS provides general set-up and control s,Decifically for a us--:ng a header and a payload. The header contains formation such as the destination address and the opcode -Ln.L I- snecifying the function of the command. Further operands of the commands are carried in the payload of the command.

commands and sets of commands digital VCR and tuner. They are encoded Thus, the communication of data over the I= 1394 Serial Bus may be considered as a layered structure, with the protocol stack, formed of the various protocol layers, beina illustrated in Figure 3.

For command information, for instance instructing a v'Ldec recorder to start replaying a video signal, data is sent as asynchronous data over the I= 1394 Serial Bus..his is illustrated in the left hand side of the protocol stack of Figure 3.

The commands are sent using the AV/C-CTS protocol, wth a particular M/CCTS command having a header which is - 12 specific to its destinat-ion unit, for instance a video recorder, and indicating the basic required function, for instance replay of a video tape. In particular, the AV/CCTS header specifies fields for command type (eg. control, status, inquiry, notify, etc), subunit type and subunit identifier, such that it defines the destination subunit for a command AV/C frame and the source subunit for a response AV/C frame. In this way, the AV/C-CTS works with a command/response scheme with a first subunit sending a io command AV/C frame to a second subunit and the second subunilt responding back with a response AV/C frame.

The opcode for the command is also specified in the header so as to indicate the basic function. The payload may be arranged to specify other operands or additional -Information, for instance indicating that play should occur at a certain speed, such as slow forward, fast forward, fastest, forward.

The protocol layer of the AV/C-CTS has been designed to con..P tor-m to the protocol layer beneath it, the IEC 1883 Function Control Protocol. This is a particular protocol for addressing a node (a unit on the network) with attached data. Thus, in this case, the IEC 1883 FCP would function to trans-m.it the AWC-CTS as the attached data.

AVIC-CTS protocols are a specific command set implementation of FCP. The AV/C-CTS commands are encoded us=q an FCP frame, the header of whilch specIfies the IE-EE 1394 node (device) destination and source addresses, frame - 13 data length, CRC and other information. In particular, the first four bits of the FCP frame payload make a field which specifies the command set being carried by the FCP frame. The FCP frame header carries a value of 11011 in this field 5 to indicate that it is carrying an AV/CCTS command. Command sets other than AV/C-CTS could be carried by the FCP frame using different values in this field. The rest of the FCP frame payload contains the AV/C header and payload.

The protocol layers defined in the IEEE 1994 specif-ication include a I= 1394 transaction layer which handles delivery and acknowledgement data for the data and a I.EEE 1394 link layer which provides the various data '--'nks to the various units. Finally, the lowest layer is _,5 the =EE 1394 physical layer comprising the physical connections.

he transaction layer provides a set of services to app,--ca---Jons running in devices on the IEEE 1394 bus, in par--'m.c,.i7-ar for as- ymchronous data only. These are services such as read and write and enable devices to access other devices on the bus by specifying a node id of the device and,' address within that node. The services are designed to provide reads and writes and provide acknowledgements back to the requester. The transaction layer also provides "lock" services. These are defined as "atomic" operations, meaning the operations are indivisible in time, so that for instance a "test and set" operation from one device on - 14 -, z another does not get interrupted half way through by L another device modifying the same location. This is very important for a peer-to-peer bus such as I= 1394 where many devices can access each other with equal priority.

The link layer provides the packetisation of the asynchronous and isochronous data. The link layer also provides cycle control which carried with low latencv allows isochronous data to be and bounded jitter.

The lowest layer is the physical layer (or PHY layer in 1-7-EE 1394 terminology) This provides the low level -lectrcal signalling and encoding of the data bits to be trarismi-tted and received. The PHY layer provides the lowlevel arbitration between devices on the bus so that only one device is driv.-'jna the bus at a time. The PHY layer alsc defines the connector and the required characteristics for the cable media.

The protocol layers for isochronous data, such as MPEG data, are illustrated on the right hand side of Figure 3.

The isochronous data is transmitted according to the IEC 1883 protocol 1. ayer. This is supported directly by the IE7-E 1394 link layer, which sets up the various connections with the lEE-E 1394 physical layer. In particular, the IEC -.883 protocol layer sets up an isochronous channel between tWO devices on the bus.

The I= 1394 specification defines the lower layers for the carriage of isochronous data, these being the - is - physical and link layers as described above. The IEC 1883 protocols provide mechanisms to allow the efficient transport of AV data utilising a Common Isochronous Packet (CIP) header. This allows AV data packets to be split up for transport over the I= 1394 bus and also has fields to signal data format (standard or high definition video data, 50 or 6CHz field rate). The IEC 1883 specification also provides the concept of logical channels and plugs for the carriage and connection of AV data between devices on the

1LO I= 1394 bus.

in this way, the I= 1394 Serial Bus and its related protocols provide a mechanism for audio/video peripherals to cc7-,m..un'-'cate command and control information, together wth d--"g-tal audio/video data.

As a basis for the present invention, it is proposed IL - -a-- a Common Interface Module such as a Conditional Access Modulle could also be connected to a network of digital V-.',dei: devices using an ILEEE 1394 Serial Bus.

Figure 2b illustrates the network of Figure 2a, but further including a Conditional Access Module 38. This arrangement has a number of significant advantages over using the previously proposed PC card implementation of the DVE Common Interface.

W'Lth the Conditional Access Module provided on the network, the conditional access functions can be used e=ally by every peripheral. Furthermore, no particular peripheral has to provide power to the Module or has to act is as a protocol bridge through which the Module communicates with the rest of the network.

Since the module on the network need not be closely phlysically bound to any particular receiver, there is more fl.exibility in the physical form and positioning of it. In other words, whereas previously a Conditional Access Module MIJIght be connected to the back of a receiver or video recorder, a network allows the module to be placed in any conve.-ient position and in any convenient form.

Finally, even if conditional access functions are embedded in a particular device, such as a receiver, rather than i- a separate Conditional Access Module, the network makes it possible for other devices to make use of the e-rbea"ded conditional access functions.

Fiaure 4 illustrates the various protocol layers no the protocol stack for the Command Interface of a cr7,- - - L C--m7on InterEace as implemented in a PC card format. The various sections of the Common Interface standards document 7N-z.-^22"- mentioned above are also given in this figure.

2G At- the highest layer, the Application Layer, the var, ious Applications and Resources are provided.

Below this is the Session Layer. Thus, when a particular device has an application requiring the use of a resource, it sets up a session by means of the Session 25 Layer with another Resource.

The process utilises each of the layers down to the iowest physical layer. From the lowest physical layer, all - 17 the various layers are then utilised up to the Resource of the other device. In other words, the data is transmitted between the resource and application by processing the data down from the application through each layer to the physical layer where it is then processed back up to the resource. The data can then return in a similar way from the resource back to the application.

In general, lower layers are transparent to the upper layers, such that when'an Application requires a session w-Lth a Resource, it is not aware of how the Session Layer or lower layers achieve that session.

The lowest generic layer of the DVB Common Interface s the Generic Transport Layer. This layer provides a set of eleven transport objects that are used to control the creation and deletion of transport connections and carry data over these transport connections.

Bei.ow the Generic Transport Layer, the PC card transport layer actually sets up the transmission of data:c be suitable for transmission over the PC Card defined electrical/physical interface. Thus, since lower layers are transparent, it is not important to the Generic Transport Layer how further communication of data takes place. In particular, it is not important to the Generic Transport Layer whether the PC card format is used.

With reference to Figure 5, a solution is proposed to the problem of providing the Command Interface on the I= 1394 Serial Bus.

This solution is based on sending the command data of the Command Interface by means of asynchronous data on the IEEE 1394 Serial Pus and proposes that the AV/C-CTS protoccis be extended to carry the command data.

As illustrated in Figure 5, the PC card transport layer which previously handles the higher Generic Transport Layer is replaced by a Common Interface IEEE 1394 Specific lransport Layer.

As mentioned above, the lower layers are transparent to the Generic Transport Layer. Therefore, the Generic be aware of the Lransport Layer and higher layers need =_ different Specific Transport Layer and the functioning of thAe standard Command Interface is not changed.

Commands are produced in the Generic Transport Layer -'n the same way as before. However, these are then handled b.,: the Common Interface IEE:E 1394 specific Transport Layer in accordance with the IEEE 1394 arrangement rather than the PC card arrancement.

The extended AV/C-CTS protocols provide a mechanism n =.7 f ---carry-ina- the command --'.n-.erj'ace protocols. L effect, the AV/C-CTS protocols carry the newly defined Common,nterface IEEE 1394 Specific Transport Layer.

The proposed extensions to the AV/C-CTS protocols are as follows. The eleven objects of the Command Interface are each given an AV/C-CTS opcode, such that there is a separate AWC-CTS command for each one of the eleven obiects of the Command Interface. The object of the 1 1 5 L 2 ^ 19 Command Interface can then be encoded within the payload of the AV/C- CTS command using a similar syntax as is used in the PC Card Implementation.

The AV/C-CTS protocol may be extended to cover other peripherals defined as "sub-unit types" and the Conditional Access Module can be defined as a new sub-unit type. In this way, each of the eleven new AV/C-CTS opcodes will be recognised as being intended for a Conditional Access Module, in contrast to opcodes intended for the TV iO rece-Lver, video recorder, etc.

In this way, the Command Interface can continue to function in the same way as previously defined for the PC Card Implementation. There is no need for modification of the upper layers or, indeed, any awareness of the means of the lower layer communication. Similarly, communication of the command interface data is achieved using the standards -1 such that no a--eady defined for the I= 1394 Serial Bus, mod-ifications are recFuired to these standards.

Thus, it is possible to provide a Cond-Ltional Access Module which operates over the I= 1394 Serial Bus, merely by providing add-1-tional AV/C-CTS opcodes corresponding to transport objects of the Com-mand Interface.

Figure 6 illustrates schematically a device such as a host receiver 2 or Conditional Access Module 4 implementing 25 a Command Interface over an IEEE 1394 Serial Bus.

A milcroprocessor 26,28 can continue to produce and receive command data in the normal way. However, add-itional functional blocks, namely a coder 40 and a decoder 42, are provided to convert the data according to the extended AV/C-CTS protocols.

The coder 40 produces appropriate AV/C-CTS commands with headers including appropriate ones of the eleven opcodes corresponding to the eleven objects of the Command interface. Objects of the Command Interface can then also be included in the payloads of the AV/C-CTS commands using a syntax similar to the PC Card Implementation syntax.

The decoder 42 on the other hand produces appropriate Command Interface objects from the opcodes and payloads of the recelived AV/C-CTS commands.

A transmitter 44 is provided to transmit the AV/C-CTS commands, for instance under the IEC 1883 protocol, via a port 48.

A receive.- 46 receives AV/C-CTS commands from the port 48 and distinguishes appropriate AV/C-CTS commands by Jden-ify-'Lng ones of the eleven new Common Interface type opcoA-t-s as opposed to opcodes used for other units.

Figure 7 illustrates an alternative solution to the problem of communicating Command Interface data over the lEEE 1394 Serial Bus.

In particular, it is proposed to use an isochronous channel to carry the Command Interface data. This has the advantage of being able to guarantee a bandwidth for DVB Common Interface Command Interface data, which is very useful when running applications that require a fast response and low delay, eg. graphics. It is proposed that, upon initialization, two isochronous channels would be created, one running from the host to the module and the other from the module to the host. By comparing Figures 4 and 7, it will be seen that the implementation

transport layer of Figure 7, namely the PC card transport layer, has interface I= 1394 specific Since lower layers are been replaced by a common transport layer. transparent to the Generic Transpo.rt Layer, replacement of the PC card transport layer will have no effect on the Generic Transport Layer and the Common Interface IEEE 1394 Specific Transport Layer will merelly handle the data of the Generic Transport Layer in a manner suitable for the IEEE 1394 Serial Bus. Thus, when a session is required to communicate Command Interface data bet-ween an Application and a Resource, the common interface TEEE 1394 specific transport layer and IEC 1883.: 'ementation link layer operate together to set up two isochronous channels over which the command data may be transmitted.

Figure 8 illustrates schematically a device such as a host receiver 2 or a module 4 with a corresponding microprocessor 26 or 28.

As illustrated, an additional functional block 50 is provided. This communicates with other devices over the IEEE 1394 Serial Bus, for instance by means of the IEC 1883 protocol, to set up isochronous channels. The command data - 22 of the Command Interface may then be sent or received over an appropriate channel.

once the isochronous transmission channels are set up, there is no need for acknowledgements and such like. Therefore, the I= 1394 Serial Bus side of the interface need not have a knowledge or require any modification in view of the Command Interface data being transmitted. Preferably, however, this implementation can include features of that discussed above. In particular, the AV/C- CTS protocol may nevertheless be extended so as to define a Conditional Access Module as another sub-unit type in addition to previous units such as the receiver and video recorder. This will allow increased inter- operability with other devices on the I= 1394 Serial Bus, in particular allowing the Conditional Access Module to be identified by other peripherals on the I= 1394 Serial Bus.

The transport objects of the Command Interface consist of objects used for transport connection creation and deletion and objects used to carry the data for upper protocol layers. The control related objects can be encoded as AV/C-CTS commands, either each in separate AV/C-CTS commands or in one generic AV/C-CTS command.

The objects used-for data carriage could then be used to carry the data to and from the module on the isochronous channels.

In other words, the generic transport layer defines e.Leven objects these can be separated into two sets. One 2 Z set is used for connection management, setting up and closing down, transport connections. The other set is used for data carriage over an existing transport connection previously set up using the other transport objects. Generally transport connections are set up infrequently and the most- heavily used transport objects are those used to carry data.

Use of the isochronous channel guarantees bandwidth.L.cr ap,-,'L icat ions. Hence, the transport objects used most io on the isochronous channel would be transport objects carryLng data; not- setting up connections etc. Hence, the connection management transport objects could be still carried as AV/C-CTS commands as previously discussed and it w:Du'.d not affect the efficiency of the scheme much. Since a -avered scheme is used, the generic transport layer need nct be aware of whether the objects were carried as asynchronous or isochronous data. The connection 7,-=:agi-z-,ment transport objects can be considered to be more sutable to be carried as AV/C-CTS commands.

on the other hand, all eleven of the transport objects of the command interface could be encoded in the same way as with the current DVB common interface specification and then carried in the I= 1394 isochronous channels. This avoids the use of the AV/C command set, since this is only required for use with the asynchronous data.

A disadvantaae of usina an isochronous channel for is 24 the Command Interface is that bandwidth allocated to the Command Interface will be wasted if it does not completely fill the isochronous channels provided. In particular, bandwidth allocated for intensive applications will be 5 wasted when those applications are not active.

It would be possible to allocate the bandwidth of the required isochronous channels dynamically, depending on how much the applications require at any one time. In particular, a host and module could initialize to a default -10 low value bandwidth for the Command Interface isochronous channels and then request allocation of more bandwidth if an application requires a faster response. In particular, the (host or module) requiring the extra bandwidth can contact the isochronous resource manager and request the extra bandwidth required. If available the bandwidth can the-be allocated to that device. Bandwidth can be a---ven up in the same way. The device requesting the bandw--'d,-h can then output on the existing isochronous channel, using the extra bandwidth and over the existing connection.

The isochronous resource manager is a device required on the bus if isochronous channels are to be allowed. Several devices could be isochronous resource manager capable and will arbitrate to allow one device to become 25-, the isochronous resource manager.

In order for a Conditional Access Module to be put on an!EEE 1394 Serial Bus network as mentioned above, it is - 25 also necessary for transport streams to flow to and from the Conditional Access Module.

The DVB Common Interface PC card implementation carries the transport streams using dedicated electrical connections on the host and module connectors. The I= 1394 Serial Bus provides no such physical connection, but only a set of isochronous channels providing logical connections between host and module. Therefore, a connection protocol needs to be defined to allow transport stream connections to be made between host and module.

The IEC 1883 implementat2ions regarding Serial Bus management are compliant with the I= 1394 Interface Standard. According to these implementations and sza-n-dards, an item of equipment, known as a node, connected to the lEEE 1394 through an interface board shall be cycle master capable. In ct-her words, a cycle master unit is ded to control the timing of the isochronous channels prcv 1 use-,.' by all the nodes on the I= 1394 Serial Bus. Each iS --7-so res2.urc-= manager carable, such that an isochronous resource manager can control the a','-, ocation of isochronous resources to nodes on the I= -13-04- Serial Bus. In other words, the resource manager can set up particular isochronous channels between particular nodes. Finally, a node which is transmitting or receiving isochronous packets shall provide plug control registers which themselves are used to set up and control audio/visual connections between nodes on the I= 1394 - 26 Ser-Lal Bus.

The protocols described in the IEC 1883 Standard provide a method of controlling isochronous data flow between devices connected using the I= 1394 Serial Bus.

According to this standard, devices have input and output plugs for transmitting and receiving isochronous data flows. Each plug can only carry one isochronous data,low and that isochronous data flow is carried in one sochronous channel which itself can carry only one 20 isochronous data flow.

A connection is made between two plugs and defines the ischronous channel number and the bandwidth rec.raired.

Connections can be overlaid on one plug to allow an -'sochronous data flow to be connected to more than one destination plug. In this case, although there is more t'_-a_--- cne connection, there is still only one isochronous carryinc the data flow.

Figure 9 -, L-1lustrates a possible configuration where a Access Mod-ale 38 is connected on an IE= 1394 1 C Thus, it is proposed to use isochronous channels to carry the MPEG transport streams. In particular, it is proposed that isochronous channels will use IEC 1883 prctocols to carry the MPEG transport strearr. using the common isochronous packet (CIP) header described above.

F-A'.gure 10 illustrates the various protocol layers making up the appropriate protocol stack.

27 - Thus, the upper layers correspond to the MPEG upper layers which would be used for the Common Interface, such that the higher generic protocol layers of the Common Interface do not need any modifications.

To implement this system it is proposed that the Conditional Access Module and the host receiver each i.nclude at least one input plug and one output plug as defined in IEC 1883, a master input and output plug control register as defined in IEC 1883 and an input and output io plu,g control register for each plug implemented, as defined in IEC 1883.

For the arrangement illustrated in Figure 9, there w'll now be described a connection protocol which could be used to transmit transport streams between the host receiver 30 and Conditional Access Module 38.

First, the host 30 identifies all the DVB Common interface Modules present on the network, preferably using the sub-unit me--han--'sm defined in the AV/C-C7PS protocol. The host 30 then requests from the isochronous resource manager the use of two isochronous channels each of the bandwidth necessary to carr-y the required transport stream.

The host 30 then configures the input plug control re=-'ster of the Conditional Access Module 38 to receive a transport stream on the first isochrcnous channel and con-figures its own output plug control register to output the transport stream on that channel. The host 30 then conficures the output plug control register of the module 2 G - 28 to output the transport stream on the second isochronous channel and configures its own input plug control register to receive the transport stream on that channel.

The host 30 can then send a scrambled transport stream over the first isochronous channel and receive the descrambled transport stream back from the module 38 on the second isochronous channel.

Since the Conditional Access Module 38 is not connected to any particular device, it is no longer 1-0 essential that a descrambled clear transport stream must be sent back to the source 30 of the scrambled stream. Thus, t'-,e Conditional Access Module 38 may be used more flexibly and- may send a clear stream, to a different device to that from. which the scrambled stream was received.

Clearly, the scrambled transport stream received by re--e-ve.- 30 must be sent to the Conditional Access Module 38. Fowever, it is then possible for the Conditional A--cess Module to send the descrambled transport stream only to the dilgital video recorder 32 (through the receiver) or to both the digital video recorder 32 and the receiver 30. Thus, the Conditional Access Module 38 must transmit to e-'Lther one or two destinations.

In the example illustrated in Figure 9, a first propcsa7. is that the receiver 30 will have the necessary transport stream switching resources to receive the transport stream frorr. the Conditional Access Module 38 and then reroute it on to the digital video recorder 32 via a - 29 th_1rd isochronous channel either as a normal IM Serial Bus transmission or as a Common Interface transport stream. Indeed, these resources will be used to route clear streams to the digital video recorder 32 when the Conditional Access Module 38 is not required. This proposal would allow only the program stream of interest to be sent to the digital video recorder 32, rather than the whole transport stream.

A second proposal is to use two transport stream connectLons, namely one from the host 30 to the module 38 and the other from the module 38 to the digital video recorder 32.

These connections could be set up and configured in a way to that described above, but with the second J.s--zl--ronous channel be-Ing set up between the module 38 and zh-= d--c-'L.al video recorder 32. This would have the advantage of avoiding the need for the host receiver 30 to -tse-f switch the program back to the digital video re=der 22. This in turn, will allow the use of the 2C resources in the host receiver 30 for other applications or a cheaper implementation of the host.

of course, in tl.-.is case, the digital video recorder 32 would receive the whole transport stream, but could be arranged to strip out all of the streams which are not of interest either under the direction of the host 30 or in a stan,d alone mode.

The arrangement of Figure 9 may also be configured as - 30 described below.

Instead of the host receiver 30 switching a required program stream back out to the digital video recorder 32, overlaid connections can be used. In particular, having set up isochronous connections between the host receiver 30 and the Conditional Access Module 38, the host receiver 30 then overlays a connection from the Conditional Access Module 38 to the digital video recorder 32. As mentioned above, overlaying a connection uses the same isochronous 1-0 channel, but directs it to an additional destination, in this case, the digital video recorder 32.

This configuration has the advantage that the switching resources of the host receiver 30 are not used and also that no additional bandwidth is used in $transmitting the transport stream on to the digital video recorder 32 in addition to the host receiver 30.

once again, the second destination, in this case the dilgital video recorder 32, would receive the whole transport stream. However this, could be an advantage where the second destination is perhaps a display in another room. In particular, it would allow the selection of the program stream to be made independently from the host receiver 30.

The use of Conditional Access Modules in conjunction with the IEEE Serial Bus brings about the possibility of communication of another type not previously considered for the I= 1394 Serial Bus. As an example, rather than return a descrambled transport stream to the host receiver 30, the transport stream can be passed on to a second Conditional Access Module (not shown) for further processing or descrambling of other virtual channels of the transport stream. To do this, it is proposed that the host receiver 30 contacts the isochronous resource manager to request a third isochronous channel, configures the output control register of the first module 38 to remove the return connection between the first module 38 and the host 30 and sets up a new connection between the first 38 and second modules using the second isochronous channel. The host 3C then configures the input plug register of the second module to receive a transport stream on the second isochronous channel and configures the output plug control rec-. Lster of the second module to set up a connection between the second module and the host 30 using the third isochronous channel. It then configures its own input plug control regIste.- to --eceive the transport stream, on the third isochronous channel.

Thus, whether all available modules or a selection of modules are utilised is at the option of the host.

According to the PC card implementation of the Conditional Access Module, the full transport stream as received by the host receiver is passed to the Conditional.

Access Module. Placing the transport stream at this level si-mplifies the interface, since the host receiver needs no knowledge of the operation of the Conditional Access - 32 Module. In particular, the Conditional Access Module can receive and use private streams of which the host receiver has no knowledge or understanding. These streams can -Include descrambling information, subscription information, etc.

The DVS Common Interface defines the transport stream bit rate as being at least 58 Mbit/s. Hence, to carry a transport stream to and from a Conditional Access Module over the I= 1394 Serial Bus requires a minimum of 116 Mb-1.t/s of bandwidth. Furthermore, each additional module would require at least a further 58 Mbit/s of bandwidth.

I= 1394 Serial Bus has various standard bandwidths..wowever, as will be apparent from the above, the 100 Mbit/s Serial Bus would be precluded and the 400 Mbit/s Serial Bus w2uld soon be filled up using Conditional Access Modules.

According to the I= 1394 Serial Bus standards, 63 devices may be used on any one bus. However, with Conditional Access Modules recfu4Lring such large bandwidths, the.-e is a relatively low limit on the number of independent Modules which can be used on the bus.

Transmission of the full transport stream, over the network is a very inefficient use of bandwidth, since any one Conditional Access Module usually descramiLbles only one or two virtual channels of the transport stream. The Conditional Access Module may also require other data streams in the transport stream, but these are generally of relatively small bit rates compared to the program streams - 33 containing video and audio information. Hence, it is likely that a large amount of information will be transferred around the network with only very little of it being processed by the Conditional Access Modules. This 5 results in a restriction of the applications of the Conditional Access Module and other devices using the IEEE 1394 Serial Bus.

one solution to this problem would be for the receiver 30 to send out only those program streams which are to be processed. Since generally only one or two program, streams are used at once, this would dramatically reduce the bit rate required and since the transport stream is a stream of packets, packets may be stripped out i-dependently of the packets of other streams so as to leave a transport streaT-,. which is still compatible with the D'V-E Common 'Interface.

However, a Conditional Access Module usually requires ad-ditional streams containing entitlement and encryption,,fcr-.at-on. If the host receiver cannot identify these streams, it is not able to determine which streams to send to each Conditional Access Module. Indeed, even if these streams can be identified, there may be so many different streams of information, that the number is beyond the capability of the host receiver to filter out and send.

Clearly, if these additional streams are not sent to the Conditional Access Module, then correct functioning of the module cannot be achieved.

- 34 A transport stream usually contains a table or map, example MPEG Program Specific Information (PSI), indicating the various program streams present and other -,.dent.-Lfying maps. However, since not all the data in the transport stream need be identified in the table, a host receiver may not be able to identify the presence of certa-'n data.

It would be possible for a Conditional Access Module to sianal to the host receiver which streams it requires. However, this would necessitate an extension or modification to the higher layer functionality of the Common Interface standards and this is preferably to be avoided.

Figure 11(a) illustrates schematically time mulltiplexed data streams, together with an associated table.

F-igure 11(bl illustrates schematically the table of Ficure ii(a.

As will be apparent, from the table, a device can 2 11- de termine -the content of assoc iated data streams, f or -1e tha data stream 1 relates to program Channel D.

examp However, as illustrated, not all the data streams need be 'dentified in the table.

It is proposed here that rather than have the host receiver identify the program streams which are required, i, should identify the program streams which are known not to be recraired. In this way, the host receiver can safely - 35 strip out all the program streams which are not required whilst ensuring that any other data streams required by the Condi-tional Access Module will still be present in the transport stream sent to the Conditional Access Module.

Thus, for the example of Figure 11, if Channel B to be descrambled by the Conditional Access Module, then the host receiver strips out streams 1, 2 and 6, which it can determine from the table relate to broadcast Channels A, C and D. In this way, if there is any additional information in streams 3 and 5 which are required by the Conditional Access Module, this will still be sent to the Condiltional Access Module.

is In the case of MPEG streams, only program streams the host receiver can identify from the MPEG Program Specific 'L nformation (PSI) data are removed. This PSI data is - ified in the MPEG -2 system specif'lcation (ISO/IEC 818-1 Generic Cod'ng of Moving Pcture and Associated Systems) and is always present in an MPEG transport stream and therefore can be used to identify the program streams present. By removing known program streams, private data of which the host receiver could have no knowledwe is retained in the transport stream sent over the Common Interface on the I= 1394 Serial Bus.

As the dominant portion of the transport stream will consLst of video program streams, removing unwanted video program streams will significantly reduce the bandwidth required by the Common Interface on the IEEE 1394 network.

Claims (11)

1. A digital multi-media device comprising: a port for an ME 1394 Serial Bus for communicating command data of a Command Interface; means for setting up at least one isochronous channel between the port and a remote device connected to the I= 1394 Serial Bus; and means for transmitting and/or receiving command data IC c-f the Command Interface over the isochronous channel.

2. A device according to claim 1 further comT)ris-ng:

means for responding to the or a remote device on the 1394 Serial Bus to set up at least one isochronous c--an-nel with said the or a remote device; and means for transmittIng and/or receiving command data 0- a Command Interface of said the or a remote device from the isoChronous channel.

3. A dialtal coT-.,pr--'s--'ng:

a port for an IEEE 1394 Serial Bus for communicating command data of a command interface; means for responding to a remote device on the I= 13014 Serial Bus to set up at least one isochronous channel between the port and said remote device; and means for transmitting and/or receiving command data of a Command Interface of the remote device from the;,sochronous channel.

4. A device according to any preceding claim wl.-lerei-n said device is a digital video device for handling at least video data.

5. A device according to any preceding claim comprising a Conditional Access Module.

6. A device according to any preceding claim comprising a digital video receiver.

7. A method of implementing a Common Interface Command Interface over an I= 1394 Serial Bus comprising:

opening at least one isochronous channel over the IEEE 1394 Serial Bus; and transmitting command data of the Command Interface over the isochronous channel.

8. A device according to any one of claims 1 to 6 or a method according to claim 7 wherein a Common Interface -TE-77- 1394 Specific Transport Layer is provided between the Generic Transport Layer of the Common Interface and an IEC1883 Implementation Link Layer so as to allow isochronous channels to be set up over the IEEE 1394 Serial Bus for the command data.

9. A device or method according to any preceding claim wherein at least two isochronous channels are set up respectively for communication in opposite d-Lrections.

10. A digital multi-media device constructed and 255. arranged substantially as hereinbefore described with reference to and as illustrated by Figures 2(b) and 5 to 11 of the accompanying drawings.

- 38

11. A met-hod of implementing a Conditional Access Module Command Interface over an IEEE 1394 Serial Bus substantially as hereinbefore described with reference to and as illustrated by Figures 2 (b) and 5 to 11 of the accompanying drawings.