Background

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.

Structure of the family of standards

Currently IEC 62379 consists of the following Parts:

1. General

2. Audio

3. Video

5. Transmission over networks

7. Measurements

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:

sub-part 1 specifies management of aspects which are common to all network technologies;

sub-part 2 specifies protocols which can be used between networking equipment to enable the setting up of calls which are routed across different networking technologies; and

Part 7 specifies managed objects used for measuring network performance according to EBUTech 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.

Model of the equipment being controlled

Blocks

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.

Control framework

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.

How the framework helps when
designing units

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.

How the framework enables “plug
and play”

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:

create a list of the units, beginning with those to which it is directly connected; each unit has a 64-bit globally unique identifier which may be its EUI-64 (which may in turn be derived from the 48-bit MAC address of one of its interfaces) or may be issued to it by the network

retrieve the list of blocks from each device on the list; if any are network ports which give access to further devices, add those devices to the list (unless they are already on it)

retrieve the connectivity between any blocks for which it is relevant.

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.

Defining a new block

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:

the globally unique OID identifies a
MIB table or group of MIB tables, with each table containing a
variable number of rows.

the table(s) are indexed using the
block id to access control objects associated with individual
instances of this block type.

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.

Management Information Base (MIB)

Objects

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.)

Other uses
of OIDs

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.

Status broadcasts

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.

Service provided by the network

The functions specified in IEC 62379 require the network to provide two
kinds of service:

fixed bit rate one-to-many service for live media streams and status
broadcasts, ideally with guaranteed latency and throughput

“best effort” one-to-one packet transfer service for
control messages and other less time-critical data

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.

Privilege levels

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

operator

supervisor

maintenance

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.

Automation

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.

Uploading software

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.