IEC 62379
Common Control Interface
for
networked audio and video equipment
The technology in IEC 62379 was originally developed for audio over ATM (Asynchronous Transfer Mode) in radio broadcasting. It has been extended to encompass video and other time-critical media, also other networking technologies (including systems in which more than one technology is used) and other applications in both professional and consumer environments.
Currently IEC 62379 consists of the following Parts:
Part 1 specifies aspects which are common to all equipment, and includes an introduction to the Common Control Interface.
Parts 2 and 3 specify control of internal functions specific to audio and video equipment.
Part 5 specifies control of transmission of these media over each individual network technology. It includes network specific management interfaces along with network specific control elements that integrate into the control framework. Within part 5:
Follow this link for more detail of sub-parts 1 and 2.
Part 7 specifies managed objects used for measuring network performance according to EBU Tech 3345.
The missing part numbers are reserved for future standardisation. Part 4 is intended to be similar to Parts 2 and 3 and apply to other forms of time-critical media, for instance RS232 or RS422 data for applications such as machine control, or the state of the “on air” light in a broadcast studio, or new kinds such as tactile feedback. Part 6 is intended for carriage of management messages over non-network connections such as RS232.
A piece of equipment (a “unit”) is regarded as being composed of functional elements or “blocks” which may be linked to each other through internal routing.
Blocks may have inputs, outputs and internal functionality. In general, the output of one block connects to the input of the next block in the processing chain. Blocks can have some associated control parameters and/or status monitoring accessible via the control framework management interface.
Figure 1: a block
A typical block might be a pre-amplifier, which has one input, one output, and a parameter which sets the gain. Another would be a mixer, with several inputs, one output, and parameters to select the contribution of each input to the mix; these parameters are effectively fader settings. A tone generator would have one output and no inputs, and parameters that set the level, frequency, etc.
There is a special class of blocks called “ports”; ports provide an external connection to other equipment. An “input port” is one where audio, video, or other data enters the unit, and an “output port” is one where it leaves the unit. Sometimes the port corresponds to a physical connection, for instance a socket for analogue audio; sometimes it is a virtual entity which can be one end of a connection across a network, or one channel on an interface such as AES10 (MADI) which conveys multiple audio streams.
Figure 2: ports
An input port has no inputs (or rather, no internal inputs; it will have an external input, but that is not part of the model of the internal structure of the unit) and a single output, which supplies the incoming stream to the inputs of other blocks. In the case of a network port, parameters would specify the network address; a physical audio port might have parameters which show the sampling rate and bit depth. Similarly, an output port has a single input and no (internal) outputs.
Figure 3 shows an example of how the various blocks connect together within a unit. Note that each input is connected to exactly one output, but an output may be connected to several inputs, or to none.
Figure 3: example of a “unit”
There is a block which performs a mix between three inputs, two from the network and one from a physical audio port (or, looking at it another way, two from remote sources and one from a local source). The local source is connected via a pre-amplifier. The resulting signal is output locally at output 2 and also transmitted on the network. There is another local output which carries a copy of one of the remote sources.
The set of available blocks, the connectivity between them, and the parameter settings for each may be fixed, or changeable by a management terminal, or read-only but changeable by external factors. Where blocks are implemented in software, a unit may provide the ability for a management terminal to create and delete them. Where blocks are implemented in physical hardware, the blocks themselves cannot be changed but it may still be possible for the management terminal to reprogram the routing between them.
The control framework consists of two lists; a list of blocks (also called control elements), and a list of connections between them.
Groups of blocks that are connected together are called processing chains. A processing chain typically represents what a unit does as a whole, so for instance a unit that alters the gain of an input to produce an output would have one simple processing chain that consists of an input port connected to a gain block which is connected to an output port.
The standard anticipates that many control blocks will be designed and implemented over time to control the many different sorts of functionality audio and audiovisual units provide.
Units can be built from existing blocks or new ones created as required. It will often be possible to represent complex, product-specific control functionality using a number of linked instances of simpler, standard blocks that together provide the functionality required.
A management terminal simply needs to recognise those blocks that are relevant to the functions it controls. (The term “management terminal” covers a wide variety of equipment, from a broadcast control system to the user interface of a device on a home network.)
It can discover what units are present on the network and what functions each contains; it does not need to recognise the units themselves, only the blocks that describe the functionality in which it is interested.
The discovery process would be:
For instance, the user interface to a surround-sound audio system might search for units containing audio sources, find those for which a processing chain exists that allows them to be made available to the user, and offer them in a menu. It would also identify functions in the processing chain such as volume control and playout controls (pause, rewind, skip track, etc).
In a radio broadcast control system, a similar process could be performed when the system is installed, and at any time when equipment is added or replaced. This process would be under the control of the installer, rather than occurring automatically, but should at least relieve the installer of the necessity to type in network addresses.
Blocks are referred to in the block list using their identifying block OID (see “other uses of OIDs” below) and a block id. The block OID is a globally unique value that identifies the block type definition. The block id is a number that is unique across all blocks in a unit and is used to identify an individual block.
The main requirement when adding a new block to the control framework is for its block type definition to follow the conditions below:
In effect the framework provides the entry point to controlling each block of functionality. The actual details of how to control that functionality will always need to be specified individually.
Communication between the management terminal and the managed unit is by a protocol similar to the Simple Network Management Protocol (SNMP). All management operations are defined in terms of reads and writes on a hierarchically organised collection of variables, or “managed objects”, known as a Management Information Base (MIB).
Each object is identified by an “object identifier” (OID) which is a sequence of numbers; in the descriptions they are separated by dots, and there are also alphanumeric names which can be used instead. The numbers form a hierarchy in a similar way to domain names, except that the top level is at the left whereas with domain names it is at the right. Identifiers of objects defined in Part p of IEC 62379 begin 1.0.62379.p; if (like Part 5) it is divided into sub-parts, identifiers of objects defined in sub-part s begin 1.0.62379.p.s. Identifiers of product-specific objects typically begin with 1.3.6.1.4.1.n, where n is the manufacturer's Enterprise Number.
Each block is described by a group of objects (a “record”). These objects are the control parameters and status variables. For each type of block, the structure of the record is specified in one of the Parts of IEC 62379, or (for product-specific or application-specific blocks) elsewhere. The connectivity is described by a table containing an identification of the output to which each input is connected.
Thus the management terminal can discover what functionality a unit has, and may be able to reprogram some of it. A command to change an object should always be confirmed by a message showing the new value of the object, so if a unit does not support the full range of possible values of a parameter it can choose the one nearest to the requested value and report back to the management terminal exactly what it has done. (Note that this is not supported by SNMP, which requires the requested value to be returned even if the parameter has not been set to it.)
Sometimes OIDs are used to identify things other than objects. Each block type is represented by an OID; in this case it is also the root (the first few numbers in the sequence) of the OIDs for all the objects in the table that describes each block of that type.
The OIDs are not confined to those specified in the various Parts of IEC 62379; for product-specific blocks, implementers may define other types with OIDs rooted at, for example, 1.3.6.1.4.1.n, where n is the Enterprise Number of the manufacturer of the unit. A general-purpose management terminal which only recognised the standard OIDs would see these product-specific blocks as “black boxes”; it would recognise their connectivity but not be able to control or monitor their operation.
Media formats (audio, video, etc) are also identified by OIDs. Here, again, OIDs not rooted at 1.0.62379 may be used for formats that are not defined in IEC 62379; provided the sending and receiving devices both support the format, a call can be set up without the management terminal needing to recognise it.
A status broadcast reports the values of a group of objects. Typical objects to be reported would be the peak level of an audio signal, the format being received at a media input, or information about what is connected to a network port.
Each part of IEC 62379 defines groups of the objects specified in it that should be available to be reported in status broadcasts. Manufacturers may also define product-specific status pages and groups.
All the objects in the group are reported periodically, and any object whose value changes is reported immediately. This ensures that a unit receiving the broadcast has the latest information, and also that if for any reason it misses an update it will discover the new value at the next periodic report, so there is no need for the recipient to acknowledge receipt of the messages.
Status broadcasts are the preferred method for regularly monitoring a unit's state. Polling fields in the MIB puts more load on both the unit and the network, because it requires the unit to process a management request on every occasion, rather than just once to set up the broadcast. Frequent polling increases this load further, whereas infrequent polling would mean a longer delay before discovering that an object's value has changed. If the same information is required at multiple locations, there will be a separate request from each, and multiple copies of the information must be sent, whereas with the broadcast only one copy is sent, being duplicated by the network as required to reach all its destinations.
The functions specified in IEC 62379 require the network to provide two kinds of service:
The procedures used for connecting media streams support a wide variety of networking technologies, and include reporting of the Quality of Service which the media stream will experience. The receiving unit can therefore know, for example, for each stream, whether it can minimise latency by using a small FIFO buffer, or needs to use a large buffer to absorb the kind of variations in arrival time that occur in umanaged packet networks such as the Internet.
A wide variety of addressing schemes is supported, including IP addresses and URLs.
Where a stream passes through a gateway between one networking technology and another, the gateway may need to repackage or even transcode the stream; the messages include information to control and report on this process.
The procedures also support per-call charging, and collection of billing information. If implemented in the Internet this would, for example, allow users to pay for content through a mechanism similar to premium-rate phone calls, or the way in which mobile phone ring tones are purchased, rather than by signing up separately with each content provider.
Throughout IEC 62379, the concept of “privilege levels” is used to distinguish different kinds of user. This concept was developed for radio broadcasting studios, and the names of the levels reflect that, but will be useful in other applications also.
Four privilege levels are defined:
Listener is the lowest privilege level, intended for use by those who wish to monitor audio or video signals passing through the unit (e.g. someone who wishes to listen in on the output of a studio via their PC). Listeners can set up calls from audio and video sources to equipment which is local to them, but cannot change anything that would affect the experience of other users.
Operator is the next privilege level, intended for use by those who are controlling the day to day operation of the unit (e.g. a studio technical operator). Operators can change things which affect other users, such as the mix of signals that provides the output from a studio, or by issuing “pause”, “seek”, etc commands to playout equipment.
Supervisor is the next privilege level, intended for use by those who are controlling and maintaining the network such as a control room technical operator.
Maintenance is the highest privilege level, intended for use by those who need to perform tasks that might disrupt normal operation of the unit, such as updating firmware or causing the unit to enter a diagnostic mode.
Privilege levels are intended to be used for two purposes. The first is to allow management call capacity to be reserved for each category of caller, to prevent important management calls being blocked because too many lower-level calls are in progress. The second is to prevent callers from performing inappropriate control tasks, by limiting the commands accepted at lower levels.
To enable the latter functionality, every call has a privilege level associated with it, and a call may not be set up, modified, or torn down by a management call of lower privilege. For instance, an operator can set up calls with operator privilege which then cannot be affected by management calls that only have listener privilege, although they can be modified or torn down by other operators and by supervisors. Supervisors can set up calls which neither listeners nor operators can disturb; the connection between a continuity studio and the transmission chain might be an example.
This specification requires that at least one management call must be accepted at each privilege level at any given time. In practice the call capacity that needs to be reserved for each level is likely to depend on the context within which the unit is used, so a means of configuring this is also specified. It is intended that any unreserved call capacity will be allocated on a first come, first served basis.
The automation mechanism allows for single or multiple values to be set at a given time. The actual scheme uses a list of automation events where each event consists of a time, the OID of an object in the MIB, and the value to put in it at that time.
This removes the uncertainty introduced by the best-effort service on the network; the controller can add the event to the table far enough in advance to give time to repeat the request if it is lost. Also, it can program a number of events to occur simultaneously.
Also, multiple events can be associated so they occur one after the other much like a macro.
Part 1 includes a mechanism for updating software and other configuration information in units supporting the Common Control Interface.
The intention is for a management terminal (including the user's remote control in a home network) to be able to update software in pieces of equipment from different manufacturers without needing to run product-specific applications.
MIB objects are defined in IEC 62379-1 that provide a model which is common to all the various kinds of memory that might be used in the managed unit. A unit may contain more than one “class” of memory; different classes may be physically different, for instance flash memory and rotating magnetic memory, and/or reserved for different kinds of data, for instance software and audio clips.
EXAMPLE 1: simple system using flash memory
Flash memory is composed of blocks, typically 64K bytes each. An individual byte can be written provided this does not involves changing any bit from 0 to 1. A whole block can be “erased”, after which every bit in the block is a 1.
Each area consists of either a single block or several adjacent blocks; a few bytes are reserved to hold the length, type, and serial number. The “handle” which identifies an area is the high part of the address of the first byte of the area.
Deletion is by erasing all the blocks that comprise the area, which may take several seconds for some flash memory chips. After deletion, if there is an adjacent empty area the two areas are merged to form a single empty area (so one of them will disappear from the table).
If there is no other memory into which components can be loaded, all areas should be class 1.
EXAMPLE 2: disc with filing system
Each file is an “area”, and there is another (single) area containing all the free space. In the case of a Unix filing system, the “handle” might be the file's inode number.
If the product has both disc and flash, it might identify the flash as class 2 and the disc as class 1; or it might divide the disc into separate partitions identified as classes 3, 4, etc.
One object for each area shows the access permitted, i.e. whether it may be written and/or erased. Whether an area is included in the table, and the access permitted if so, may depend on the privilege level. The management terminal may be able to change the access, but usually this will be controlled by the managed unit, for instance it may set all areas required to load the software currently running to read-only (i.e. not writable) and the rest to full access so that new software can be uploaded into currently unused areas but the current software cannot be overwritten until the new software has been completely loaded.
Another is the status which shows what operation is being performed on the area. The management terminal requests deletion of an area by setting its status to “erasing”; the managed unit will then delete its current contents and set the status to “empty”. It may then amalgamate it with another empty area in the same class of memory.
An area also has a serial number; new software is given the serial number next in sequence after that for the current software. When the unit is restarted, the (valid) software with the most recent serial number is loaded; the procedures ensure that partly-loaded software will not be valid, for instance if the unit is restarted before the uploading process is complete. Thus if the unit is restarted before the new software has been completely loaded the old software will run; if after, the new software will run.
Two methods of software distribution are supported. The software may be supplied as a package, for instance on a CD or by e-mailing a ZIP file; when new software is available, a new package must be distributed. Alternatively, a “product file” containing a URL may be supplied, and the software downloaded over the Internet. It is made easy for the management terminal to check whether new software is available.