DIGITAL VIDEO BROADCAST SYSTEM

Abstract: The invention provides a method for facilitating the management and running of a digital video broadcast (DVB) system. In a typical DVB system there are often a number of functions which must be co-ordinated and synchronized. The invention provides a monitoring point for managing the total multiplex, and controlling the mix of services being transmitted. The system fulfils most of the software integration requirements in a broadcast centre. A central database, held in the operational areas, is provided and is the reference point to which other systems refer. A large protocol converter is provided which links the scheduling system to the playout and conditional access (CA) systems.

Description: Digital Video Broadcast System This invention relates to a Digital Video Broadcast (DVB) system, in particular to a system and method for integrating and managing the components of such a system in a manner which improves overall data throughput and control thereof. In a typical DVB system there are often a number of functions which must be co-ordinated and synchronised. Each of these functions are generally controlled independently by a separate system which is controlled by an individual user. In this manner it is not unusual for a given function to be co-ordinated and controlled on two separate levels, which is obviously an unnecessary waste of resources. In addition the individual user may set restrictions and operating criteria which badly effect the operation of the broadcast as a whole. A further problem which can arise is in relation to the scheduling of programs and the transmission of data. If there are unexpected changes to the scheduling, such as a ball game going into extra time or a news flash, the changes caused may influence all other events and programs. This can mean that each operator of the individual functions has to amend the inputs to the broadcaster, this is inconvenient and time consuming. In addition, conventional systems do not centralise all the required information to provide comprehensive engineering and monitoring facilities. According to one aspect of the present invention, there is provided a method of managing a digital multiplex in response to one or more changes to the event scheduling, wherein the digital multiplex forms part of a digital video system comprising system elements such as an event synchroniser including a data cache, a service information controller, a multiplexer controller, and a conditional access controller including a broadcast control centre, the method comprising the steps of: updating the data stored in the data cache in response to the change or changes in the scheduling; synchronising the updated data across the different system elements to ensure correct referencing and; formatting the multiplexer according to the change or changes in the scheduling. According to a second aspect of the invention, there is provided apparatus for managing a digital multiplex in response to one or more changes to the event scheduling, wherein the digital multiplex forms part of a digital video system comprising system elements such as an event synchroniser including a data cache, a service information controller, a multiplexer controller, and a conditional access controller including a broadcast control centre, the apparatus comprising: updating means for updating the data stored in the data cache in response to the change or changes in the scheduling; synchronising means for synchronising the updated data across the different system elements to ensure correct referencing and; formatting means for formatting the multiplexer according to the change or changes in the scheduling. The present invention has many advantages over the prior art. The present invention centralises and facilitates the management of a digital video broadcast system, bringing together many of the functions of the prior art and enabling changes to made in one central place and having the information disseminated to any other point that needs to know. Without the present invention, responding to unexpected changes was physically impossible, now unexpected changes are dealt with without problem. Multiplex management is facilitated further by enabling easy re-apportionment of bit-streams across multiplexers. The present invention also provides advantages over the prior art by reducing the number of interfaces that are required between the different systems. In a typical prior art system traffic would have to talk directly to the automation system, the multiplexers, and conditional access systems, The automation system would have to talk to the multiplexers and conditional access systems. Synchronising all these different changes is problematical. With the present invention the traffic system talks to the AFS, the automation system talks to the AFS, and the AFS co-ordinates the required changes with the down-stream systems. Reference will now be made, by way of example, to the accompanying drawings, in which: Figure 1 is a block diagram of a preferred embodiment of the present invention; Figure 2 is a block diagram showing the interfaces adopted in the Figure 1 system; and Figure 3 shows the software configuration for the system. In a DVB system there are a number of functions which must be controlled. The system of the present invention, referred to as the Automatic File Server (AFS) bridges a critical gap in the range of studio control systems which are required to construct a multiplexed Digital Video Broadcast (DVB) system. The AFS illustrated in Figure 1 provides a number of functions. It provides a monitoring and control point for managing the total multiplex, and controlling the mix of services being transmitted. The system fulfils most of the software integration requirements in a broadcast centre. A central database, held in the operational areas, is provided and is the reference point to which other systems refer. A large protocol converter (not shown) which forms part of the Event Synchroniser 14 is provided which links the scheduling system to the playout and conditional access (CA) systems. The protocol converter is responsible for data translation from the AFS internal format into messages that can be understood by Conditional Access and associated program information (CA-PIMS) 16, Multiplex Control (MCC) 18 and Service Information Control (SIC) 20. This type of system will be of use when a variety of requirements are required, either alone or in combination. The system is also useful when addition or removal of services is required within the Multiplex at any time during operation. When using CA blackouts and replacement services or Near Video on Demand (NVOD) services and associated pay per view events the system of the invention provides an invaluable tool as explained below. In addition, when merging independent schedules from diverse services and using a central editing point for schedules and network tables the AFS provides advantages over the prior art. For example, when monitoring the services across a Multiplexer (mux) and when warning of bit-rate overload the AFS can provide improved performance. The major functions provided by the AFS will be described in more detail below, but generally include the following. The use of the AFS as a tool for Multiplex Management, as a cohesive system within the studio complex, and as a central repository of information for all the different types of schedule driven systems. Referring to Figure 1 , a typical AFS system 10 is illustrated. The system 10 is implemented in two parts, namely a schedule database 12 utilising for example Oracle 7.0 and a real-time cache system (the Event Synchroniser 14), which improves the resilience of the system to failure and increases its data throughput. The AFS monitors the state of all the on-air services event by event and formats the digital multiplex to accept them. In addition, the AFS also synchronises the data across all the playout systems so they reference each other correctly. As a result of the location of the AFS in the playout hierarchy, it also makes possible a number of important operational facilities which are described in greater detail below. The automation system 28 is the part of the broadcast system responsible for the playout of source material according to the schedule provided by the traffic system 32. The source material could be provided by video or audio tapes, disks or other media. The media manager 34 is responsible for keeping track of the source material and the location of the source - for example, if the source material is held on tape it knows which tape holds the required material. The event synchroniser 14 controls a number of systems and provides real time control of a number of them. These include Conditional Access and associated program information (CAPIMS) 16, Multiplex control (MCC) 18 and Service Information Control (SIC) 20 and the associated supported navigation tools. The CAPIMS system includes a Broadcast control centre (BCC) 22 which produces Entitlement Control messages (ECMs) 24 which are transmitted via the MUX and future ECMs 26 which are stored on the AFS for later transmission via the SIC. The SIC supported Navigation tools include, for example, Mosaic, Event Listings and Replacement services which can make up an Electronic Program Guide (EPG). The event synchroniser receives real time messages from an automation system 28 and passes them to all of the transmission related control systems including the transmission sub-system 30. In the situation where the automation system is unavailable the same messages can be simulated by the event synchroniser, using the nominal schedule time of the event. The schedule database has two way communications with the event synchroniser, a traffic system 32 and a media manager 34. The schedule database receives data from either the traffic system or from a file input 36 and transmits information to the transmission sub-system, which include the SIC, the CAPIMS and one or more user interfaces 38 via an Open Database Connectivity (ODBC). The Schedule Database 12 is the storage point for all attributes related to a programme event e.g.: nominal start time, the start of a message, CA services and blackout restrictions and the number of subtitle languages. The database is used by 'client' sub-systems which draw off the relevant data they require. The definition of this data set effectively defines the operation of the DVB system. The structure of the database is designed around an analysis of the information required to control the downstream systems and holds the data in an appropriate form. The Event Synchroniser 14 acts as the real-time element of the Database. The synchroniser caches approximately 6 hours of schedule data in memory to guard against down-time of the schedule database. By holding this data in memory, the Event Synchroniser can respond very quickly to real- time cues. Thus, the playout system is free to insert, drop or move events as programme requirements dictate, whilst the Event Synchroniser can prepare the downstream systems with no additional overhead. The automation system could do this task directly if it was designed with MUX control in mind. However, given that there may be a video playout system, a radio automation system and a data playout system, the synchroniser provides the most open architecture while requiring little extra customisation of the other systems. The MCC, the CA(PIMS) and the SIC make up what is known as the low level control systems. The actual function of each is described in greater detail below. The Multiplexer Control Computer (MCC) controls the Multiplexer with regard to the combination of all the video, audio and data components and their various characteristics. Information within the Event Synchroniser informs the mux about the bit-rate which should be allocated to each service, and also the list of components associated with the current events. The AFS has a valuable role in the integration of the CA system with the MCC in that it assigns the correct encryption key (ECM) to each service or component. The CA interfacing philosophy balances the needs of both CA security and traffic system flexibility. The CA must operate in a secure environment and be responsible for the low level formatting of instructions to the subscriber smart card. CA-PIMS provides a high level interface which protects this operation. The traffic system should be able to assign particular CA parameters to events using a simple set of pre-configured instructions, but also in such a way that they can be fine tuned if necessary. The traffic system must also be able to derive the detail in these instructions, so that censorship violations can be spotted early in the scheduling process. The interfacing method adopted uses a series of templates which can be equally applied on a simple subscription per channel basis, but also control complex mapping Pay per View (PPV) events and taping instructions. The Service Information Controller (SIC) provides information within the broadcast data stream so that the subscriber receiver (IRD) can locate all the services being transmitted. The information held on the SIC is mastered in the AFS system and ultimately by the traffic system. This data can be viewed as a list or groups of services, and can also be supported using mosaics or more complex composite pages of video and text. If the CA system is requested to blackout a particular event, a 'replacement' service can be flagged within the SIC which will be used if the subscriber is refused access to the particular service. When the blackout event finishes, the SIC informs the subscriber IRD to switch back to the normal service. Without the AFS there is no easy method of evaluating the mix of services being transmitted within the digital transport stream. Whenever bandwidth is at a premium, bit-rates will need to be adjusted in order to allow the flexible addition and removal of services. The AFS provides a method of viewing the mux wide view and consequently can be used to re-apportion bit-rates as business requirements develop. An example of how this could work is where different services are provided during the day to those during the night. For example it may be possible to have 7 normal channels which can be augmented by 3 further data channels at night. If the merging of the additional channels is handled by the AFS, then any unexpected events, such as a ball game running into extra time can be taken into consideration. If the game is scheduled to finish at 10.00pm but doesn't and the extra channels are due to start at the end of the game any changes can be easily handled by the AFS, such that the transmission of the extra channels is delayed until the game does actually finish. The advantages of using a digital conditional access system from a scheduling perspective are that specific events can be given individual access parameters. These types of event include, pay per view events, black-out events across regional and demographic boundaries (e.g. close to the venue of a sports event) and replacement services needed to overcome censorship violations. As mentioned above, the operational management must focus not only on an individual channel, but also at the mux layer. Many automation systems cannot provide a Multi-channel view of schedules - which is where the AFS can provide a very useful editing facility and tool. The editing point can be utilised locally by transmission controllers or remotely via traffic system personnel. The effect of the AFS is to take the scheduling directly to the heart of the transmission system such that events about to be transmitted are now accessible to the topmost scheduling process. Thus, if there are any changes they can be entered at one point only and dynamically disseminated to any other point which needs to know. This allows the system to have strong control over features such as delays, overloads and the like. The editing capabilities of the AFS are such as to allow changes to be made from a traffic system at any time up to broadcast time. User interfaces are also provided that allow last-minute changes to be made simply. Any required changes need only be made in one place and the information is 1 ? automatically distributed to all relevant systems. This is an important advantage over prior art systems. The present invention also allows, from a central point, monitoring of bandwidth allocation on all multiplexers as well as allowing bandwidth allocation to be adjusted on an event-by-event basis to optimise usage of any program stream. Referring to Figure 2 it is shown that the AFS supports interfaces to two categories of system, the low level control systems mentioned above and the higher level systems discussed in greater detail below. Low level drivers are used to interface to the three systems which control the make-up of the DVB multiplex. Custom interfaces have been developed to support high level studio system for scheduling and programme layout. The custom interfaces provide interfaces between schedule database 12 and both traffic system 32 and file input 36. The traffic system provides direct filling of the AFS database however, with file input 36 parsers are required to translate the information in the files into data suitable for populating the AFS database tables. The present invention also provides advantages over the prior art by reducing the number of interfaces that are required between the different systems. In a typical prior art system traffic would have to talk directly to automation, the muxes, and Conditional access systems, Automation would have to talk to the Muxes and conditional Access systems. Synchronising all L3 these different changes is problematical. With the present invention Traffic talks to the AFS, Automation talks to the AFS, and the AFS co-ordinates the required changes with the down-stream systems. The AFS database 40 is shown in figure 2 and has drivers 42 and interfaces 44 associated therewith. The drivers control communications to the MCC, the CA and the SI modules. The interfaces provide the links to a mux input assignment module 46, an on-screen display driver and subtitling module 48, a real time playout controller 50 and one or more schedulers 52 and 54. The first scheduler 52 is part of an alternative playout or scheduling system and the second 54 is part of a station-wide automation system 56. The high level studio systems mentioned above which are provided by the system can be categorised into a traffic system, an automation system and a number of user interfaces. The traffic system is actually a short hand term which describes a large number of programme scheduling and material management systems. Traffic' represents the point at which this data is merged to produce a specific programme schedule in detail. The AFS supports two types of interface to the traffic system, either an ODBC interface which allows database replication and hence is very responsive to changes, or a Flat-File interface which supports 'snapshot' schedule transfers. The AFS can therefore support schedule downloads from a number of diverse scheduling systems ranging from main frame machines to personal computers. The studio automation system utilises the AFS schedule database as its source of play-lists for one or more channels. As with the other client systems, these lists are filtered to extract only the relevant fields which are required. In the reverse direction real-time event cues generated by the automation system are sent to the Event Synchroniser. Two cues are normally generated - a 'tension' command which is sent approximately 20 seconds before an event begins, or a 'take' command at the actual programme transition. The automation system references the events concerned in the event synchroniser memory by event number which in turn sends a translated message to each clients system. Since the two cues from the automation system are relatively simple, the AFS is not tied to working with one particular type of automation system. In order to implement the key features of the invention, a number of user interfaces are required. The types of interface which must be supported relate to mux-wide edit views, network information table settings (satellite polarisation, frequency etc.), mux-wide component views including CA keys and bit rate, maintenance and alarm terminals, and a status display showing current on-air events and next events on a station-wide basis. The status display may be available as a video feed which can be displayed in monitor racks. In general the displays are configurable on a system by system basis. As previously mentioned the Schedule Database can be based upon an Oracle database such as the Oracle 7 RDBMS. The interface to the various client systems is achieved using triggers as illustrated in Figure 3. The triggers are configured to notify the sub-systems of changes to the data which affects them. The client systems are then responsible for querying the relevant tables to extract the new information. This exploits the inbuilt connectivity of the system. The secondary benefit of this type of interfacing approach is that the server is not responsible for updating a client system if the latter fails or switches over to a backup system. In these cases, it is also possible for the server to know the state of the failed system. The Event Synchroniser does however run custom software to provide the real-time messages to the client systems. In this instance, the trigger method is too cumbersome to translate the cues from the automation system and the event synchroniser generates it's own custom real time messages. This is shown in figure 1. The custom software on the Event Synchroniser 14 receives real-time cues from the automation system 28 which identify the start of program events. This cue information is distributed by the event synchroniser 14 to the relevant downstream systems which, acting on this 'event-starting' information perform appropriate system reconfigurations. In a preferred embodiment the hardware configuration utilises separate redundant pairs of servers, for both the synchroniser and the database. The database servers are designed with data integrity as their most critical design feature. Down-time in the database is masked by the synchroniser configuration, which utilises switch-over software to ensure an extremely rapid use of the backup system. Each of the sub systems can independently maintain their own local data backup which offers protection against Network failure. Hardware reliability is provided by a number of features which occur in the event of a failure. Disks are protected against failure by using a mirrored disk system. Power supply failure is provided for by the use of automatic switch over to another system. Automatic failure recovery software provides for the event of a processor or memory failure. In the event of complete bus failure, the software package automatically switches to the secondary server. The system is based upon a redundant network architecture. In the event of a client failure the operator can move to a backup machine and continue working. The main feature of the AFS tool have been detailed above, it will however be evident that a number of variations of the system are possible which will be evident to the person skilled in the art.

Claims: CLAIMS 1. Apparatus for managing a digital multiplex in response to one or more changes to the event scheduling, wherein the digital multiplex forms part of a digital video system comprising system elements such as an event synchroniser including a data cache, a service information controller, a multiplexer controller, and a conditional access controller including a broadcast control centre, the apparatus comprising: updating means for updating the data stored in the data cache in response to the change or changes in the scheduling; synchronising means for synchronising the updated data across the different system elements to ensure correct referencing and; formatting means for formatting the multiplexer according to the change or changes in the scheduling. 2. The apparatus of claim 1 , wherein the event synchroniser comprises a real¬ time data cache. 3. The apparatus of claims 1 or 2, wherein the event synchroniser provides real-time control of the conditional access controller, the service information controller, the multiplexer controller and one or more navigation tools. 4. The apparatus of claims 1 , 2 or 3, further including a schedule database containing all information relating to an event including nominal start time, conditional access services, blackout restrictions and a number of subtitle languages. 5. The apparatus of claims 1 , 2, 3 or 4, wherein the event synchroniser receives real-time cues identifying the start of program events. 6. The apparatus of any of claims 1 to 5, further including an automation system responsible for the playout of source material according to the schedule. 7. The apparatus of any of claims 1 to 6, further including a media manager for sub-management of source material. 8. The apparatus of any of claims 1 to 7, wherein the multiplex controller controls and formats the multiplexer according to the required video, audio and data components. 9. The apparatus of any of claims 1 to 8, wherein the updating of the data in the data cache, the synchronising of the updated data across the different system elements and the formatting of the multiplexer are all carried out in real-time. 10. The apparatus of any of claims 1 to 9, wherein changes to the event schedule are disseminated to the event synchroniser, the data cache, the 21) service information controller, the multiplex controller and the conditional access controller as required. 11. The apparatus of any of claims 1 to 10, wherein the event synchroniser responds to unexpected changes to the event scheduling. 12. The apparatus of any of claims 1 to 11 , wherein the event synchroniser responds to pre-planned changes to the event scheduling or multiplexer formatting. 13. The apparatus of any of claims 1 to 12, wherein the data cache maintains a 6 hour window of event data. 14. The apparatus of any of claims 1 to 13, further comprising controlling means to provide real-time control of the conditional access controller, the service information controller, the multiplexer controller and one or more navigation tools. 15. A method of managing a digital multiplex in response to one or more changes to the event scheduling, wherein the digital multiplex forms part of a digital video system comprising system elements such as an event synchroniser including a data cache, a service information controller, a multiplexer controller, and a conditional access controller including a broadcast control centre, the method comprising the steps of: updating the data stored in the data cache in response to the change or changes in the scheduling; synchronising the updated data across the different system elements to ensure correct referencing and; formatting the multiplexer according to the change or changes in the scheduling.

Inventors: FELDMAN YURAI, GOLD MARTIN, THEXTON NICHOLAS, FELDMAN, YURAI, GOLD, MARTIN, THEXTON, NICHOLAS
Applicants: FELDMAN YURAI, GOLD MARTIN, NDS LTD, THEXTON NICHOLAS, FELDMAN, YURAI, GOLD, MARTIN, NDS LIMITED, THEXTON, NICHOLAS
Application year: 1997
Main classification: H04N7
IPC codes: H04H1, H04N5, H04N7