WO2006120438A1

WO2006120438A1 - Operational support system

Info

Publication number: WO2006120438A1
Application number: PCT/GB2006/001708
Authority: WO
Inventors: Frederick James Bolin
Original assignee: Fighting Bull Broadcast Technologies Limited
Priority date: 2005-05-10
Filing date: 2006-05-10
Publication date: 2006-11-16
Also published as: GB0509413D0

Abstract

An operational support system (OSS), adapted for use with a network of devices, comprising device interface means which obtains device information comprising device identity and device status from a plurality of media devices; service path determination means which uses the device information to determine at least one service path defined by at least some of the devices; and display means comprising a graphics engine for displaying a representation of the service path. A “media device” for the purposes of this invention means any device that has a function in the generation or transmission of analogue or digital visual or audio or data signals, such as analogue television or radio, digital television or radio, high-definition television, internet television (such as IPTV), video to mobile phones.

Description

Operational Support System

The present invention relates to an operational support system (OSS) , and in particular for an OSS for the media industries .

Operational system support first appeared in the telecommunications market in the late 1980s as billing integration systems . The telecommunications regulatory environment was poised for upheaval, and the analogue to digital conversion was underway and required investment. Customers increased demands for new services while proving increasingly difficult to hold on to. There was little room for error as the industry entered a long period of acquisitions and mergers.

New breeds of OSS soon appeared, providing system integration, network management and even equipment inventory management. One of the objectives of OSS in this field, is ultimately to reduce operational expenditure, increase profit margins and thus commercial viability.

The media industries include all industries that distribute televisual media, such as the broadcast industry, satellite operators, and cable companies. Also, increasingly, the telecommunications industry is introducing new media distribution techniques that diverge from their traditional services and overlap with the types of content traditionally distributed by other industries, for example distribution of video clips to mobile telephones.

However, to better understand the context of the present invention, we now turn to discuss the differences between the traditional telecommunications industry and the broadcast industry. It will be understood that the following discussion applies equally to other media industries, for example, satellite networks and cable providers.

There are some similarities between the telecommunications industry and the broadcast industry - both have faced the analogue to digital conversion, both are ultimately concerned with distribution of digital content, and technology is a significant business driver in both industries.

However, in the broadcast industry, there is a different regulatory environment, different revenue models, and the size of "providers" is different: the broadcast industry, is characterized by a small number of large operators , while the telecommunications industry is fragmented and characterized by a large number of operators of different sizes .

As broadcasters steadily dismantle their stovepiped analogue infrastructures and replace them with file- based digital content generation and playout, the spotlight will gradually shift to that of capping or reducing operational expenditure. The telecommunications experience is that gaining control over the network and the integrated applications is the first step. Broadcasters need to be sure that the network is cost effective, capable of delivering regulator-demanded and customer-preferred products, and flexible enough to easily integrate next generation products.

Broadcast infrastructures share many characteristics with technologies found in the telecommunication and IT industries, but are also characterized by proprietary interfaces and protocols and a significant lack of systems integration standards with industry-wide adoption.

However, the telecommunications OSS products will not be an exact fit for broadcasters. A particular aspect of a broadcast infrastructure which is clearly different from that of telecommunication of ISP infrastructures is the necessary focus on integrity of signal paths for televisual signals. Digital broadcast infrastructures, by definition, provide greater flexibility in order to enable diverse permutations of resources to be deployed in prograinme construction. Regional variations and rights issues mean that broadcast networks have to merge and diverge in complex permutations .

Maintaining the necessary focus on integrity of signal paths regardless of complex operational configurations is vital in maintaining quality of service, but is both layout intensive and highly dependent on operator skill level. Skilled operators have a particular ability to instinctively understand signal path configurat;Lons and deal with any issues that arise, but such skills are not universal and are costly to attain and maintain.

This is one aspect of broadcast operations where operational services support system software can reduce operational expenditure by providing tools and management information that help manage and maintain the infrastructure.

According to a first aspect of the present invention, there is provided an operational support system (OSS) , adapted for use with a network of devices, comprising: device interface means which obtains device information comprising device identity and device status from a plurality of media devices; 1 service path determination means which uses the

2 device information to determine at least one service

3. path defined by at least some of the devices,- and

4 display means comprising a graphics engine for

5 displaying a representation of the service path. 6

7 A "media device" for the purposes of this invention

8 means any device that has a function in the

9 generation or transmission of analogue or digital 0 visual or audio or data signals, such as analogue 1 television or radio, digital television or radio, 2 high-definition television, internet television 3 (such as IPTV), video to mobile phones. 4 5 The OSS may comprise an access module. The access 6 module may comprise the device interface means.

8 The device interface means may comprise at least one gateway which obtains the device information. The 0 or each or some of the gateways may obtain device information directly from the devices. The or each or some of the gateways may obtain device information via external data sources associated with the devices.

The or each or some of the gateways are preferably capable of obtaining device information from any device or external data source associated with a device. The or each gateway may be configurable to communicate with one or more outputs of one or more devices, which outputs all use a pre-determined communication protocol. The or each gateway may be configurable by comprising application software that loads a configuration file for the or each output of the or each device. The or each gateway may use data from the configuration files to set up communication with the or each output of the or each device, using the pre-determined communication protocol . The pre-determined protocol may comprise a protocol such as SNMP, SERIAL, GPI/GPO.

The or each gateway may obtain the device information in one or more formats, and may convert the device information into a unitary, pre- determined format.

The display means may obtain information from the devices on a substantially continuous basis. This may be achieved by polling the devices at regular intervals. This may be achieved by listening for signals from the devices substantially continuously or at regular intervals.

The OSS may comprise a data module. The data module may comprise the service path determination means. The data module may receive the device information in the unitary, pre-determined format, and store the device information. The service path determination means may use the device information in the unitary predetermined format to determine the service path.

The data module may store the configuration file for the or each output of the or each device of each gateway, and output the configuration files to the gateways .

The service path may be defined by the functional relationships between the devices which make up the service path, and media services with which the devices are associated.

The display means may provide a real time or near real time representation of the or each service path. The representation of the or each service path may comprise a string of devices which make up the service path.

The OSS may comprise a visualisation module. The visualisation module may comprise the display means.

The visualisation module may use the display means to display a plurality of services provided by the devices to a user of the OSS. The services may be displayed on one or more wheels . The visualisation^' module may comprise selection means which allows the user to select a service. The user may select a service using the or each or some of the wheels. The visualisation module may comprise read means to read the selected service. The service path determination means may access the read means and determine at least one service path of the selected service. The visualisation module may display a representation of the or each or some of the service paths of the selected service. The visualisation module may comprise selection means to allow a user to select any particular device of a service path and display a representation of the selected device. The visualisation module may use the display means to simultaneously display the representation of the selected device and the representation of at least the service path comprising the device. Thus a device can be selected for inspection, without losing track of the rest of the service path.

The visualisation module may use the display means to change the representation of a service path in response to a change in the status of the path or of a device in the path. The change in representation is most preferably implemented in real time or near real time. The visualisation module may comprise alarm means to issue an alarm in response to a change in the status of the service path or of a device in the path.

The OSS may comprise a communication module. The communication module may act as the main control and communications interface for the access, data and visualisation modules of the OSS. The communication module may receive the device information from the device interface means of the access module and pass this to the data module. The communication module may comprise means for queuing and regulating information transfers between one or more device interface means and one or more display means. 1 The OSS may provide a service path replay means .

2. This may enable the OSS to access details, of

3 historical service paths . The replay means may be

4 operated by selecting a start date and time of a

5 desired historical service path, and the service

6 path determination means may use the device

7 information to reconstruct the service path, as it

8 was at that start date and time The display means

9 may then display the service path. The replay means 0 may also be used to select an end date and time for 1 the historical service path, and the service path 2 determination means may determine any changes which 3 occurred in the historical service path between the 4 start date and time and the end date and time. The 5 display means may then display the changes to the 6 historical path as they occurred in real time. 7 8 The OSS may provide a replay means for each resource device from which information has been obtained. 0 The OSS may provide a report generation means . This may enable the OSS to generate a variety of reports, using the device information obtained from the devices.

According to a second aspect of the present invention, there is provided a method of operational support comprising the steps of: obtaining device information comprising device identity and device status from a plurality of media devices; using the device information to determine at least one service path defined by at least some of the devices ; and constructing and displaying a representation of the service path.

The user may be able to monitor the service paths using the OSS. The user can then access the network comprising the devices and service paths, and using the representation of the service path, to control the operation and management of the service path in the network.

The present invention will now be described, by way of example only, with reference to the accompanying drawings, in which:

Fig. 1 shows an overview of a operational support system architecture according to an embodiment of the invention;

Fig. 2 illustrates in more detail the access layer architecture of Fig. 1;

Fig. 3 illustrates in more detail the communication layer architecture of Fig. 1;

Fig. 4 illustrates in more detail the data layer architecture of Fig. 1; Fig. 5 illustrates a Society of Motion Picture and Television Engineers (SMPTE) broadcast system architecture model;

Fig. 6 illustrates in more detail the visualisation layer architecture of Fig. 1;

Fig. 7 shows an example screen shot from a representation according .to a first embodiment of the invention;

Fig. 8 shows an expansion of the screen shot of Fig. 6;

Fig. 9 shows an example screen shot from a representation according to a second embodiment of the invention, and

Fig. 10 shows an expansion of the screen shot of Fig. 9.

In the described embodiments of the invention, the operational support system (OSS) is used in the support of the operation and the management of a media network, which generates and transmits various media services. It will be understood, however, that the OSS of the invention may be used in other applications. The media network may be a broadcast network, a satellite transmission network, a cable network or, in general, any network which distributes televisual and/or audio and/or data content. The network provides a number of services, such as visual, audio, data, analogue and digital services, in the form of, for example,, television or radio programmes . The media network comprises a plurality of resources in the form of physical devices, which are responsible for the generation and transmission of the services . The resource devices together define various paths for the services. Each service may have a multiple of possible service paths.

The OSS of the invention is able to obtain information concerning the resource devices, use the information to determine at least one service path provided by the resource devices, and display a representation of the service path. A user of the system can select a service path, and the representation of the service path will be displayed to the user. The user can then access the media network, and using the representation of the service path, control the operation and management of the service path in the media network. The OSS of the invention is also able to provide a service path replay function to the user, which allows the user to select a time at which they would like to examine a service path, and the system will determine the path at that time, and display the path to the user. The OSS further allows the user to generate a number of reports concerning a service path and the devices in the path, for example a report on the usage of the devices in the path. As shown in Fig. 1, the embodiment of the OSS comprises four main modules or layers; a visualization layer 10, an access layer 12, a communications layer 14, and a data layer 16. It will be appreciated that this is an example of a layout for the OSS, and the various components of each layer may be alternatively arranged.

The access layer 12 provides the device interface means, and uses this to obtain information concerning the resource devices of the media network. The access layer 12 further comprises data conversion means, which converts the resource device information into a predetermined format, and forwards this to the communication layer 14. The resource device information is further forwarded to the data layer 16, where it is used to determine at least one service path provided by the resource devices. The visualisation means 10 provides the display means, and receives the determined service path or paths, and displays a representation of these to a user of the OSS.

The components of the OSS will now be described in more detail.

Access Layer

The access layer 12 is where raw information is collected from individual resource devices and transformed into a standard format for presentation to the communication layer 14, and onwards to the data layer 16. Signals, for example comprising details of events, generated by the resource devices - 18 are collected by the access layer 12, by gateways 20 listening via various communication protocols. The access layer 12 automates the main input of information to the OSS, by collecting resource device information using the gateways 20, which may, for example, run on PCs through a dedicated Linux gateway server.

Information from the raw resource devices 18 is communicated to the gateways 20, which communicate with the communication layer 14. The information can be sent directly from the resource devices 18 to the gateways 20, or the gateways 20 can receive data via external data sources 22 associated with the resource devices 18. The access layer 12 also provides a video streamer 24, to stream an output directly from the resource devices 18 to the visualisation layer 10 of the OSS.

The resource devices 18 may, for example, include aspect ratio converters, audio distributional amplifiers, video distributional amplifiers, analogue to digital converters, digital to analogue converters, analogue to digital converters with distributional amplification, digital to analogue converters with distributional amplification, frame synchronizers, line synchronizers, teletext generators, graphics logo generator, ProcAmp processors, teletext inserters, keyers, video and audio processors, multiplexers, demultiplexers, digital probes, analogue probes, device suppliers' own systems, routers, switches, and sound-in-sync coders, decoders and strippers. This list is by no means exhaustive.

As shown in Fig. 2, the resource devices 18 may -comprise broadcast devices, resource devices of a broadcast network control system (BNCS) network 32 (as developed by the British Broadcasting Corporation) , and resource devices of a DART network 36 (which is a controller area network (CAN) for devices supplied by Pro-Bel Vistek electronics). It is to be appreciated that these are specific examples of resource devices and connecting networks only. It is also to be appreciated that different numbers and types of resource devices and physical and network connections could be incorporated into the OSS.

The broadcast devices 18 are connected to a communication port rack 28 and a general purpose interface (GPI) rack 30, the resource devices of the BNCS network are connected to a Fabian server 34, and the resource devices of the DART network are connected to a ViewNet Gateway system 38. The Fabian server and the ViewNet Gateway system act as external data sources for the resource devices of the BNCS network and the DART network. The racks 28, 30, the Fabian server 34 and the ViewNet Gateway system 38 are each connected to a separate gateway provided on a Matador agent server 26. This communicates with a Matador communication server in the communication layer. The gateways receive resource device information in a number of formats, and convert the information into a unitary format for transmission to the communication layer 14.

The gateways 20 of the access layer 12 are capable of interfacing with and collecting information from any resource device or external data source associated with a resource device using any connection protocol. Each gateway 20 is configurable ^' to communicate with one or more outputs of one or more resource devices which outputs use the same communication protocol. The configurability or each gateway negates the need for expensive software updates when new resource devices are deployed in a network. Each gateway is configurable by comprising application software that loads a configuration file for the or each output of the or each resource device. This enables each gateway 20 to set up communication with the or each output of the or each resource device, using the communication protocol. Therefore a gateway need not be provided for each output of each resource device, but rather for outputs of resource devices which use a particular communication protocol.

In the embodiment being described, four gateways 20 are provided on the Matador agent server 26. The outputs of the resource devices 18 connected to the communication port rack 28 use a Serial GATEWAY communication protocol. A first gateway 20 receives information from these outputs of these resource devices 18. This gateway 20 is configured to load configuration files of these outputs of these resource devices, and communicate with them using the Serial GATEWAY communication protocol . The outputs of the resource devices 18 connected to the GPI rack 30 use a GPI communication protocol. A second gateway 20 receives information from these outputs of these resource devices 18. This gateway 20 is configured to load configuration files of these outputs of these resource devices, and communicate with them using the GPI communication protocol . The outputs of the resource devices connected to the BNCS network 32 use a BNCS communication protocol. A third gateway 20 receives information from these outputs of these resource devices, via the Fabian server 34. This gateway 20 is configured to load configuration files of these outputs of these resource devices, and communicate with them using the BNCS communication protocol. The outputs of the resource devices connected to the DART network 36 use a DART communication protocol. A fourth gateway 20 receives information from these outputs of these resource devices 18. This gateway 20 is configured to load configuration files of these outputs of these resource devices, and communicate with them using the DART communication protocol.

Each gateway 20 is configured to communicate using a particular communication protocol. If all the outputs of a resource device use the same communication protocol, then a single gateway will communicate with all of the outputs of this resource device. However, some resource devices may comprise outputs which use different communication protocols . For these resource devices, a number of gateways will be used to communicate with the resource device, according to the number of different protocols used by the outputs of the device. This can be useful for resource devices which have an output providing , for example, status information using a BNCS communication protocol, and an output providing, for example, information relating to power supply units (PSUs) in the device using a GPI communication protocol.

The outputs of the resource devices may communicate with the OSS via communication protocols such as SNMP, SERIAL and GPI/GPO. Some specific examples of resource devices and their communication with the OSS will now be discussed.

BNCS

Resource devices connected to a BNCS network, and controlled through existing BNCS drivers, can communicate with a BNCS Fabian server as part of an installation of a media network. The Fabian server offers a telnet session to other machines connected on a TCP/IP network and allows external queries. A Matador agent server establishes links with the Fabian server, and receives information therefrom. For this, the standard BNCS Fabian Applcore command set is used. PRO-BEL VISTEK

Resource devices in the form of Pro-Bel Vistek cards can be connected, through racks, to a Pro-Bel Vistek Dartnet, a CanBus network. The Viewnet Gateway system establishes control and reporting of all Pro- Bel Vistek equipment, including rack PSUs. External communication with this Viewnet Gateway system via TCP/IP is available through either a telnet server path or an HTTP direct path. In the telnet server path, the Viewnet Gateway system offers a telnet connection similar to the BNCS Fabian server interface, and may require a Viewnet interface server. Information is passed in XML format, and passed onto a gateway of the OSS. Alternatively a gateway of the OSS can set up a direct telnet session with the Viewnet Gateway system and parse the information. In the_^ HTTP direct path, a gateway of the OSS can have the ability to directly connect to the Viewnet Gateway system through HTTP. This provides small XML responses and notifications to get raw information, which is then parsed by the gateway.

Simple Network Management Protocol (SNMP)

Several manufacturers offer an SNMP port on devices, connected through TCP/IP. In some devices there is already a SNMP collection tool e.g. Vistalink for Evertz equipment, which offers similar functionality to Pro-Bel Vistek equipment connections. These tools then provide secondary status reports from their control applications through SNMP messages. Direct SKIMP connections to individual resource devices, such as Quartz routers and MRG equipment, can be handled through a specific manufacturer's management information base (MIB) for that device. This requires prior definition of the SNMP message formats, to decode them through a specific SNMP MIB for that associated manufacturer.

PING

Some of the 'computer' type resource devices, e.g. BORIS, operate on a media network, but have no other communications ports available. For these the TCP/IP PING protocol is used, to confirm if the device is 'alive'. These entities are unable to provide any further status information.

SERIAL

In certain cases it will be necessary to connect to a resource device directly through a serial communications port, such as an RS232/422/485 connection between the controlling machine and the resource device. Serial port configuration, speed, data bits, parity etc., are defined by the manufacturer and will be loaded as part of the resource device ID from the configuration file. This is associated with the specific resource device that is being controlled. Command protocols would then need to be interpreted. While these are also manufacturer specific, there are now some industry wide protocols, such as those by Pro-Bel and Sony. The physical connection can comprise direct COM ports . This is where the controlling resource device , i.e. PC, server etc., has a physical COM port enabled and directly wired to the resource device. Usually these are RS232 connections, however adapters and other installed cards can provide RS422/485 depending on the resource device requirements . Alternatively, the physical connection can comprise rocket ports. These provide a number of remote physical COM ports clustered around the physical resource devices, allowing the controlling machines to be located virtually anywhere in the infrastructure of the network. Typically 16 COM ports from a breakout box will connect to 16 resource devices while the box is attached via the TCP/IP network to the controlling machines. These units can operate in two modes; a client-server mode and a server only mode. In a client-server mode, each machine that needs to access one of the COM ports on the remote breakout unit will run a RP utility which maps the COM port settings from that machine to an IP address for the remote unit. Any applications which attempt to send commands to the standard COM port on the machine, e.g., BNCS drivers and Matador agent servers, see no difference in the location of the COM port. Hence standard port commands are used by the controlling application.. The RP utility provides the connection through a TCP/IP network for the remote resource devices. If a machine is running an older operating system, such as Win 3-11/95, they will need an additional rocket port unit to convert the standard Com port to Ethernet connectivity, which tunnels the com messages to the breakout unit. In a server only mode, each resource device controller loads a different communication library which provides a mapping service directly to the rocket port breakout unit by addressing the COM port messages using 'sockets' to the TCP/IP network. This library needs to be coded into a gateway application, a difficulty with existing controlling agents, e.g. BNCS drivers.

GPI / GPO

Many resource devices use a General Purpose (GP) interface to signal a simple on/off message. This can be in the form of a relay switch open or closed or the connection of voltage. GPs are split into two types: 1) An input to the resource device, a GPI, usually used to send a command to control the resource^' device, and 2) An output from the resource device, a GPO, often used to indicate PSU status for a resource device separately from general resource device status obtained through another output or source. Therefore it is possible to be aware of device failure due to power failure rather than simply through a loss of communication. The resource device would otherwise be unable to tell the OSS that it has lost power, while by using a GPO, the loss of voltage on the GPO would indicate the loss of power. GPs need to be detected at a physical level, by a resource device capable of using the relay contact/voltages . A GP collection resource device, capable of detecting multiple GPOs or generating multiple GPIs must be installed. Several manufacturers, such as Pro-Bel and MRG, have different options, and these collection resource devices then communicate the status of the detected GPs through their standard methods, such as Viewnet for Pro-Bel Vistek products, Vistalink for Evertz, or BNCS for those without their own. These can be interrogated from a gateway as above.

The processes that take place in the access layer 12 of the OSS, can be controlled according to a number of message types:

• A Device Configuration Request is generated after a gateway manager has detected a failed gateway. It provides the startup configuration data to the gateway manager to allow for a restart of the gateway.

• A Device Configuration Change Notification Message is generated when a gateway detects that a resource device has had a firmware upgrade i.e. current firmware version does not match config details.

• A Device Status Alert Message is generated after a gateway has received a Status Change Alert Message from a resource device i.e. ARC mode change .

• A Path Change Alert Message is generated when a router or switch revert has been notified or static data, has been amended and the user requests a Path Refresh. This causes service paths to be deleted and rebuilt to match the new path configurations .

• A Control Agent Status Alert message is generated when a control agent is no longer transmitting a heartbeat signal. A restart will be attempted and a "CONTROL AGENT RESTARTED" message or a "CONTROL AGENT FAILURE" message will be notified.

• A Gateway Status Alert message is generated when a gateway is no longer transmitting a heartbeat signal to an access control agent. The access control agent will attempt to restart the gateway and notify an "GATEWAY RESTARTED" message or an "GATEWAY FAILURE" message.

* An Update Access Control Agent ID message is generated after a access control agent has been identified for each resource device.

The configuration files of the resource devices, which are loaded by the gateways 20, are stored in the data layer 16. It will be appreciated that the configuration files may be stored in the data layer 16 on setting up of the OSS, and may be added to as - the OSS is required to receive information from outputs of resource devices which use different communication protocols. On start-up of the OSS, each gateway receives a list of the outputs of resource devices with which the gateway is intended to communicate, from the data layer 16. Each gateway also receives a configuration file for each output, and also a Get Status Message, which causes ^' the gateway to try to obtain information from the output of the resource device. On receipt of resource device information, each 'gateway converts the received information into a pre-determined, e.g. XML, format, and outputs the information to the communication layer 14, for onward transmission to the data layer 16, for storage therein.

The access layer 12 may obtain information from the resource devices on a substantially continuous basis. This may be achieved by polling the devices at regular intervals, for example, at 2 second, 5 second, 10 second or 20 second intervals. Polling could also be carried out is information has not been received from an output of a resource device for a pre-determined time. The access layer 12 may also obtain resource device information by listening for signals produced by the devices, either continuously or at regular intervals. The access layer 12 will therefore provide substantially continuous, i.e. real-time, information on the status of resource devices and hence service paths of the media network.

Communication Layer

The communication layer 14 is the main control and communication interface for the OSS. Links are created and maintained with the visualization layer 10 via visualization control agents 50; the access layer 12 via access control agents 52; and the data layer 16 via database control agents 54.

A central processor, or communication engine 56, is further controlled via communication control agents 58.

The communication layer 14 architecture is further illustrated in Fig. 3. Data flow into and from the engine core 60 is managed by an input queue 62 and an output queue 64 associated with each control agent 50,52,54,58. As shown, a plurality of each type of control agent 50,52,54,58 is provided.

The communication layer 14 handles all data transfers and routes all requests and responses, between the various other layers of the OSS. The processes that take place in the communication layer 14 can be controlled according to a number of message types:

• A System Startup message is generated at system start-up by a communication control agent for all gateways^'. No confirmation is required, since a lack of heartbeat will initiate a Gateway Status Alert.

• A Gateway Startup message is generated by the communication control agent for all gateways . No confirmation is required, since a lack of heartbeat will initiate a Gateway Status Alert.

• A System Shutdown message is generated at system shutdown by the communication control agent for all gateways.

• An Agent ID Notification message is generated by access agents to inform the data layer which access agents have been allocated to which resource devices .

• A Path Analyser Request message is generated by a comm control agent at system start-up and at SANITY_CHECK intervals. It is also initiated from the MONITOR_PATH_QUERY and the PATH_CHANGB_ALERT .

• A Sanity Check is initiated by the communication layer every 60 minutes to provide assurance that all alerts are being received and recorded by the data layer. Data Layer

The data layer 16 is used to store all information gathered by the access layer 12. The data layer 16 is also used to store configuration files for each of the outputs of each of the resource devices from which information is to be obtained by the access layer 12.

The data layer 16 comprises database technology that provides a central repository allowing for a scalable solution for the OSS, while also providing management information and maintenance of static data. A path analyser and process module 70 communicate with the communication layer 14, and a management information services (MIS) and maintenance module 72 is also provided. The data is stored on databases 74,76.

Fig. 4 shows an expanded view of the data layer 16. The databases 74,76 are written to by an MIS module and maintenance module 78 (which together form the MIS and maintenance module 72) . Path analyser 82 and process modules 84 communicate with the databases 74,76 and the database control agents 54 of the communication layer 14.

The path analyser 82 is responsible for determining the one or more service paths, using resource device information collected by the access layer 12 and stored in the databases 74, 76 of the data layer 16. Once determined, a service path is passed to the communication layer 14, for onward transmission to the visualisation layer 10, for display thereof.

All data layer processes are initiated within the database 74,76 by the use of database triggers.

The processes that take place in the data layer 16 can be controlled according to a number of message types :

• An Audit Service message is used to maintain an audit of changes to services .

• An Audit Path List is used to maintain a history for all service paths.

• An Audit Visualised Path message is used to maintain a history for all visualised service paths .

• An Audit Device Detail is used to maintain a history for all resource device status details.

• An Audit Dynamic Crosspoint is used to maintain a history for all router crosspoint revertives .

• An Audit Device Usage message is used to record resource device usages for MIS purposes.

• An Audit Location message is used to record resource device movements for MIS purposes. Visualisation layer

The visualisation layer 10 functions to provide a representation of the or each service path of the media network, which has been determined using the information obtained by the access layer 12.

As shown in Fig. 1, a plurality of user stations 90 can be provided for rendering a visualization to a user of the OSS. The user stations 90, which are most preferably computers running a suitable computer program, communicate with the visualization control agents 50 in the communication layer 14.

The OSS visualisation layer uses the reference model provided by the Society of Motion Picture and Television Engineers (SMPTE) , to visualise the determined service paths, and their resource devices, of the media network. As shown in Fig. 5, this reference model comprises five component planes, a resource plane 92, a path plane 94, a service plane 96, a content plane 98 and a management services plane 100, which all interact in different ways with various communication layers, namely a physical layer 102, a data link layer 104, a network layer 106, and an application layer 108. The component planes are the means of programme generation and transmission in a media network, while the communication layers relate to the standard ISO/OSI 7-layer stack. The resource plane of the OSS of the invention, corresponding to the SMPTE resource plane 92, represents actual physical resource devices such as routers, amplifiers, coders and synchronizers. Each resource device is represented using a Java container, which stores and displays information about the resource device's behavioral properties, the device's physical location (in the form of rack and bay numbers), identity, port and connection information, and alarms and other status details. Each resource device container provides a gateway into manufacturer-specific diagnostic tools outside of the abstract world. Adjacent placing of resource device containers in the resource plane represents a service path of the network.

In the path plane of the OSS of the invention, corresponding to the SMPTE path plane 94, multiple resource devices are strung together to represent service paths.

The service plane of the OSS of the invention, corresponding to the SMPTE service plane 96, represents the different services provided by the media network.

Fig. 6 illustrates an architecture for the visualization layer 10. Exchange of data with the communication layer 14 is managed by a communication manager 130. A visualization component (shown above the communication manager 130 in Fig. 6) comprises an event handler 132, layout engine 134, 3D model generator 136, in-memory database 138 that stores path, device, port, link and attribute data, and a scene generator 140.

The visualisation layer 10 further comprises a 3D engine module 142 (provided to the right of the communication manager 130) , which comprises scene graph, input, windowing, rendering, operating system abstraction, and utilities functionality.

In order to perform the visualization of one or more paths of a service of the media network, the OSS requires all information from the resource plane, the path plane and the service planes of the system. All this information will be obtained from the path analyser 82 in the data layer 12, using information stored in databases 74,76 in the data layer 16. The or each service path is then displayed to a user of the OSS, using a user interface of the visualisation layer 10.

Figs. 7 and 8 show a first embodiment of a user interface of the visualisation layer 10. The media network monitored by the OSS in this embodiment, comprises a plurality of services in the form of television and radio channels, each channel comprising various data streams, such as audio, visual, analogue, and digital. Each service of the network will therefore comprise a number of service paths, depending on the data stream or streams used for the channel. The channels are represented in the user interface as 3D objects 112, on a first selection wheel 110. The data streams are represented in the user interface as 3D objects 116, on a second selection wheel 114. The user interface provides for the selection of a particular service. A channel 112 is selectable from the first selection wheel 110, and a data stream is selectable from the second selection wheel 114. In this example, the television channel "BBC ONE" is selected using the first selection wheel 110, and thereafter the second selection wheel 114 enables the selection of one or more data streams 116, including digital pictures for broadcast, analogue pictures for broadcast, digital teletext services, analogue teletext services, audio descriptors, etc. Any live output provided by a live service path of the selected service, is represented in a separate panel 118 of the user interface.

Once a service has been selected, one or more service paths thereof then grow downwards from the selections wheels, as illustrated in Fig. 8. As • seen therein, a string of the resource devices making up the service paths are displayed by the user interface. The resource devices 120, shown in a solid representation, display a live service path of the selected service. The resource devices 124, shown in a transparent representation, display a redundant service path of the selected service. For each service path, the user interface provides a user navigable up/down link between path containers of the service path and dependent resource device containers of the resource devices of the service path.

Any particular resource device of a service path can be selected for closer inspection. Fig. 8 shows a selected resource device 122. This is displayed along with the representation of the service paths . Thus a resource device can be selected for inspection, without losing track of the rest of the service paths.

Once a service path has been visualized, any changes in any resource device of the path, can be notified to the user by a visual and/or an audible alarm of the user interface. For example, service paths could be colour coded to provide different levels of alarm. A green service path could indicate a normal state, and different colours could indicate different levels of alarm,- for example, yellow could represent a change of status of a resource device, for example an aspect ratio change of a device from 4:3 to 16:9; amber could warn of resource device problems, for example a resource device fault on a non live service path; or red could represent a fatal error with a live service path resource device, for example a power failure.

Figs. 9 and 10 show a second embodiment of a user interface of the visualisation layer 10. Again, the media network monitored by the OSS in this embodiment, comprises a plurality of services in the form of television and radio channels, each channel comprising various data streams The channels are represented, in the user interface as 3D objects 210, on a first selection wheel 212. The data streams are represented in the user interface as 3D objects 214, on a second selection wheel 216. The user interface again provides for the selection of a particular service, as in the first embodiment, by selecting a channel 210 from the first selection wheel 212, and selecting a data stream from the second selection wheel 216.

Once a service has been selected, one or more service paths thereof then grow outwards from the selections wheels, as illustrated in Fig. 10. As seen therein, a string of the resource devices making up the service paths are displayed by the user interface. The resource devices 220, shown in a solid representation, display a live service path of the selected service. The resource devices 224, shown in a transparent representation, display a redundant service path of the selected service. For each service path, the user interface provides a user navigable up/down link between path containers of the service path and dependent resource device containers of the resource devices of the service path.

The resource devices of a service path may comprise a colour coded border, to provide information concerning the device. For example, a black border around a resource device could indicate that the resource device is not monitored by the OSS and is shown for completeness of the service path only. A white border around a resource device could indicate that the resource device is in test mode and no alarm conditions will be raised. A green border around a resource device could indicate that the resource, device is currently being shown in a device panel view. A red border around a resource device could indicate that the resource device is on a live service path and has an open high level alert. An amber border around a resource device could indicate that the resource device is on a redundant service path and has an open high level alert. A yellow border around a resource device could indicate that the resource device has an open low level alert.

Once a service path has been visualized, any changes in any resource device of the path, can be notified to the user by a visual and/or an audible alarm of the user interface. For example, a change in colour of a resource device border may be displayed. Any resource devices which have red or amber borders, may also generate a service alert tab in the user interface screen.

Any particular resource device of a service path can be selected for closer inspection. This may be achieved by selecting the resource device of interest, e.g. by using a mouse to hover a cursor on the device and double clicking the mouse. This may open up a resource device tab panel in the user interface screen for the device. In a third embodiment of the user interface of the visualisation layer 10, the interface provides a pull down menu, with submenus, which displays the services of the media network. A user may then select a service by selecting it from the menus .and submenus. Once the service has been selected, one or more service paths may be displayed as described above. This method of selecting a service may be provided in addition to the methods described in the first and second embodiments of the user interface.

As described in these embodiments, the user interface of the visualisation layer 10 preferably provides a three dimensional representation of at least the or each service path, and may also provide a three dimensional representation of the services of the network. The whole of each service path is preferably visualized on a single screen of the interface, which simulates a 3-D environment, which a user of the interface can zoom in and out of.

Any user interface of the visualisation layer 10 may use a standard Windows (RTM) format, to present various menus of functions provided by the OSS. For example, a menu may be provided which comprises exit and logout functions, a menu may be provided which comprises show service path and hide service path functions, a menu may be provided which comprises a list of all services available for selection, a menu may be provided which comprises a resource device browser function and a video window on/off toggle function (allowing display of the output of an end resource device or of pre-selected monitor resource devices of a service path, of a selected service) , a menu may be provided which allows selection of a representation of an actual physical view of a service path.

As the access layer 12 is obtaining information from the resource devices of the media network on a substantially continuous basis, the service paths can be determined and displayed in real time or near real time. Information on any changes which happen to resource devices of a service path will be obtained in at least near real time, and the service path determination and display can be updated in at least near real time. The OSS therefore provides a user with current, up to date, representations of service paths, which are essential for management of the media network.

The OSS also provides a service path replay means. This allows a user of the OSS to access details of historical service paths . The user selects a start date and time of a desired historical service path, and the path analyser 82 of the data layer lβ uses the information stored in the data layer 16 to reconstruct the service path, as it was at that start date and time, and the visualisation layer 10 displays the service path. The user can also select an end date and time for the historical service path. The path analyser 82 will then determine any changes which occurred in the historical service path between the start date and time and the end date and time, and the visualisation layer 10 displays the changes to the historical path as they occurred in real time .

The OSS also provides a replay means, as described above, for each resource device from which information has been obtained. This replay means will allow a user to see the signals obtained from a resource device, at a particular date and time, and over a selected date and time interval.

The OSS provides a report generation means . This allows a user of the system to generate a variety of reports, using the resource device information stored in the data layer 16. For example, a report can be generated of a resource device utilisation details such as time spent on live service paths. A report can be generated of frequency and details of alarms generated by a resource device, allowing a user to determine, for example, which devices are failing on a regular basis. A report can be generated comprising data representations of one or more service paths. A report can be generated comprising details of actions taken to remedy faults detected for resource devices.

The OSS provides a management console. This allows access to the system for control of the configuration of the system.

To ensure integrity of information carried by the OSS and to prevent the system from misuse, the system can provide a series of security measures. Access to the OSS can be controlled, by challenge and response passwords . Various maintenance and administration accounts can be set up for different users, giving them different permissions to alter or configure the OSS. The OSS can also conform to set security policies for virus protection and software update procedures . Backup and recovery procedures can also be carried out, with online information being transferred to a physical storage medium for later disaster recovery purposes.

By providing information concerning the resource devices and service paths of the media network in a unified, easily understood 3D manner, the OSS of the invention creates a very useful tool for various operators of the network. As the resource device information is obtained in substantially continuously, the OSS will allow operators to access the at least near real time configuration of the network and, for example, to trace alarms and accurately identify faults on resource devices, throughout the infrastructure of the network, and to rectify any faults in a timely fashion. Representations of historical service paths are also available, which can be used to analyse previous fault detection and rectification methods. Operators are able to monitor active services and workflow of the network. A network master control room can be provided with a totally integrated monitoring tool, and operations management are enabled to monitor the entire network broadcast infrastructure at work.

Claims

1. An operational support system (OSS), adapted for use with a network of devices, comprising: device interface means which obtains device information comprising device identity and device status from a plurality of media devices; service path determination means which uses the device information to determine at least one service path defined by at least some of the devices; and display means comprising a graphics engine for displaying a representation of the service path.

2. An operational support system according to claim 1 which comprises an access module which comprises the device interface means.

3. An operational support system according to claim 1 or claim 2 in which the device interface means comprises at least one gateway which obtains the device information.

4. An operational support system according to claim 3 in which the or each gateway is capable of obtaining device information from any device or external data source associated with a device.

5. An operational support system according to claim 4 in which the or each gateway is configurable to communicate with one or more outputs of one or more devices, which outputs all use a pre-determined communication protocol.

1 6. An operational support system according to

2 claim 5 in which the or each gateway is configurable

3 by comprising application software that loads a

4 configuration file for the or each output of the or B each device.

6

7 7. An operational support system according to

8 claim 6 in which the or each gateway uses data from

9 the configuration files to set up communication with 0 the or each output of the or each device. 1 2 8. An operational support system according to any 3 of claims 3 to 7 in which the or each gateway 4 receives device information in one or more formats 5 and converts the device information into a unitary, 6 predetermined format.

8 10. An operational support system according to any preceding claim in which the device interface means 0 obtains information from the devices on a . substantially continuous basis.

11. An operational support system according to any preceding claim in which the OSS comprises a data module and the data module comprises the service path determination means.

12. An operational support system according to claim 8 in which the service path determination means uses the device information in the unitary, predetermined format to determine the service path.

13. An operational support system according to any preceding claim in which the display means provides a real time or near real time representation of the or each service path.

14. An operational support system according to any preceding claim in which the representation of the or each service path comprises a string of devices which make up the service path.

15. An operational support system according to any preceding claim which comprise a visualisation module which comprises the display means.

16. An operational support system according to claim 15 in which the visualisation module uses the display means to display a plurality of services provided by the devices to a user of the OSS.

17. An operational support system according to claim 16 in which the services are displayed on one or more wheels.

18. An operational support system according to any of claims 15 to 17 in which the visualisation module comprises selection means which allows the user to select a service.

19. An operational support system according to claim 18 as dependent from claim 17 in which the user may select a service using the or each or some of the wheels.

20. An operational support system according to claim 18 or claim 19 in which the visualisation module comprises read means to read the selected service.

21. An operational support system according to claim 20 in which the service path determination means accesses the read means and determines at least one service path of the selected service.

22. An operational support system according to any of claims 13 to 21 in which the visualisation module comprises selection means to allow a user to select any particular device of a service path and display a representation of the selected device.

23. An operational support system according to claim 22 in which the visualisation module uses the display means to simultaneously display the representation of the selected device and the representation of at least the service path comprising the device.

24. An operational support system according to any or claims 13 to 23 in which the visualisation module comprises means to change the representation of a service path in response to a change in the status of the path or of a device in the path.

25. An operational support system according to claim 24 in which the change in representation is implemented in real time or near real time.

26. An operational support system according to any preceding claim comprising a communication module which acts as the main control and communications interface for the OSS.

27. An operational support system according to any preceding claim comprising a service path replay means which enables the OSS to access details of historical service paths.

28. An operational support system according to any preceding claim comprising a report generation means .

29. A method of operational support comprising the steps of: obtaining device information comprising device identity and device status from a plurality of media devices ; using the device information to determine at least one service path defined by at least some of the devices; and constructing and displaying a representation of the service path.