IEC 62379-1:2007

Common control interface for networked digital audio and video products - Part 1: General

IEC 62379-1:2007 specifies a control interface for products which convey audio and/or video across digital networks. This bilingual version (2012-08) corresponds to the monolingual English version, published in 2007-08.

Interface de commande commune des produits audio et vidéo numériques connectés en réseaux - Partie 1: Généralités

La CEI 62379:2007 spécifie une interface de commande pour des produits transmettant des signaux audio et/ou vidéo sur des réseaux numériques. La présente version bilingue (2012-08) correspond à la version anglaise monolingue publiée en 2007-08.

General Information

• Status: Published
• Publication Date: 29-Aug-2007
• ICS: 33.160.01 - Audio, video and audiovisual systems in general
• ICS: 35.100.05 - Multilayer applications
• Technical Committee: TC 100 - Audio, video and multimedia systems and equipment
• Current Stage: PPUB - Publication issued
• Start Date: 30-Aug-2007
• Completion Date: 30-Sep-2007

Overview

IEC 62379-1:2007 defines the common control interface and general framework for products that convey audio and/or video across digital networks. Part 1 establishes the core model and services used across the IEC 62379 family, enabling consistent control, discovery and management of networked digital audio and video devices. This edition covers unit modelling in terms of blocks, management via a Management Information Base (MIB), status broadcasts, calls, privilege levels, automation and procedures such as software uploads and scheduled operations.

Key Topics

• Control framework and block model: Devices are represented as “units” composed of functional blocks (inputs, outputs, processing). The framework defines how blocks are described, linked and discovered to enable modular, scalable designs.
• Management Information Base (MIB): Standardized MIB objects convey unit identity, block configuration, real-time clock and reference clock information, software upload status and scheduled operations.
• Status broadcasts and page groups: Mechanisms and formats for broadcasting unit status (basic identity, time-of-day, scheduled operations) to facilitate monitoring and “plug-and-play” behaviour.
• Procedures and operations: Defined procedures for uploading software components, defining file formats and areas, requesting/executing/delaying/aborting scheduled operations.
• Control transport and encapsulation: Guidelines for how control and status messages are carried and encapsulated over networks (see Parts 5 and 6 for network-specific transports).
• Security and management: Support for privilege levels, calls, automation and migration pathways (e.g., OIDs and XML) to integrate with enterprise management systems.

Applications and Who Uses It

IEC 62379-1 is intended for professionals and organizations designing, deploying or managing networked AV systems, including:

• Manufacturers of networked audio, video and multimedia equipment (encoders, decoders, mixers, routers)
• Broadcast system integrators and facility engineers seeking interoperable control interfaces
• Network architects implementing AV over IP, broadcast distribution or studio automation
• Software developers building device management and monitoring tools that use MIBs or status broadcasts

Practical benefits include plug-and-play discovery, consistent device control, easier integration of new functionality, and standardized mechanisms for software updates and scheduled tasks.

Related Standards

• IEC 62379 Parts 2–6 (media-specific and network/transmission subparts): Part 2 (Audio), Part 3 (Video), Part 4 (Data), Part 5 (Transmission over networks), Part 6 (Packet transfer service)
• SNMP/management frameworks and OID/XML mappings referenced for MIB interoperability

Keywords: IEC 62379-1, common control interface, networked digital audio and video, MIB, plug-and-play, status broadcasts, software upload, scheduled operations, control framework.

Standards Content (Sample)

IEC 62379-1
Edition 1.0 2007-08
INTERNATIONAL
STANDARD
Common control interface for networked digital audio and video products –
Part 1: General
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form
or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from
either IEC or IEC's member National Committee in the country of the requester.
If you have any questions about IEC copyright or have an enquiry about obtaining additional rights to this publication,
please contact the address below or your local IEC member National Committee for further information.

IEC Central Office
3, rue de Varembé
CH-1211 Geneva 20
Switzerland
Email: [e-mail]
Web: www.iec.ch
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.

About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigenda or an amendment might have been published.
ƒ Catalogue of IEC publications: www.iec.ch/searchpub
The IEC on-line Catalogue enables you to search by a variety of criteria (reference number, text, technical committee,…).
It also gives information on projects, withdrawn and replaced publications.
ƒ IEC Just Published: www.iec.ch/online_news/justpub
Stay up to date on all new IEC publications. Just Published details twice a month all new publications released. Available
on-line and also by email.
ƒ Electropedia: www.electropedia.org
The world's leading online dictionary of electronic and electrical terms containing more than 20 000 terms and definitions
in English and French, with equivalent terms in additional languages. Also known as the International Electrotechnical
Vocabulary online.
ƒ Customer Service Centre: www.iec.ch/webstore/custserv
If you wish to give us your feedback on this publication or need further assistance, please visit the Customer Service
Centre FAQ or contact us:
Email: [e-mail]
Tel.: [phone]
Fax: [phone]
IEC 62379-1
Edition 1.0 2007-08
INTERNATIONAL
STANDARD
Common control interface for networked digital audio and video products –
Part 1: General
INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
PRICE CODE
XB
ICS 33.160; 35.100 ISBN 2-8318-9279-1

– 2 – 62379-1 © IEC:2007(E)
CONTENTS
FOREWORD.4

0 Introduction .6
0.1 Overview .6
0.2 Structure of the family of standards .6
0.3 Model of the equipment being controlled .7
0.3.1 Blocks .7
0.3.2 Control framework .8
0.3.3 How the framework helps when designing units .9
0.3.4 How the framework enables "plug and play" .9
0.3.5 Defining a new type of block.9
0.4 Management information base (MIB) .10
0.4.1 Objects.10
0.4.2 Other uses of OIDs.10
0.4.3 Migration to XML .10
0.5 Status broadcasts .11
0.5.1 Introduction .11
0.5.2 Status page information sources.11
0.5.3 Status page general format.11
0.6 Calls.11
0.7 Privilege levels .12
0.8 Automation.13
0.9 Uploading software.13
0.10 Encapsulation of messages .14
0.11 Further information.14
1 Scope.15
2 Normative references .15
3 Terms and definitions .15
4 Unit management .18
4.1 Protocol.18
4.2 MIB definitions .19
4.2.1 General .19
4.2.2 Application-wide type definitions.20
4.2.3 Conceptual row type definitions .24
4.2.4 MIB objects for basic unit identity and status information.25
4.2.5 MIB objects for the block framework .28
4.2.6 MIB objects for real time clock information.30
4.2.7 MIB objects for reference clock information .31
4.2.8 MIB objects for software upload.32
4.2.9 MIB objects for scheduled operations .34
5 Procedures.36
5.1 Real-time clocks.36
5.2 Procedures for uploading software .36
5.2.1 Areas.36
5.2.2 Contents.37
5.2.3 Procedure for updating a software component .37

62379-1 © IEC:2007(E) – 3 –
5.2.4 File format for a software component.38
5.2.5 Format for product files .39
5.2.6 Software distribution.40
5.3 Scheduled operations.40
5.3.1 Requesting a scheduled operation.40
5.3.2 Executing a scheduled operation .42
5.3.3 Delaying a scheduled operation.42
5.3.4 Aborting a scheduled operation .42
5.3.5 State of relative operations.42
6 Status broadcasts.42
6.1 General .42
6.2 Page formats.44
6.2.1 Basic unit identity page .44
6.2.2 Time-of-day page .44
6.2.3 Scheduled operations page .45
6.3 Page groups.45
6.3.1 basicUnitStatus.45
6.3.2 timeOfDay .45
6.3.3 scheduledOps .45

Annex A (informative) Background information.47
Annex B (informative) Machine-readable MIB definitions.50
Annex C (informative) Machine-readable status page-group definitions .68

Bibliography.69

Figure 1 – A block.7
Figure 2 – Ports .7
Figure 3 – Example of a "unit".8

Table 1 – Managed objects conveying information about the unit.25
Table 2 – Managed objects for block and connector configuration.28
Table 3 – Managed objects for real-time clock information .30
Table 4 – Managed objects for reference clock information.31
Table 5 – Managed objects for software upload .32
Table 6 – Managed objects for scheduled operations.34

– 4 – 62379-1 © IEC:2007(E)
INTERNATIONAL ELECTROTECHNICAL COMMISSION
________________
COMMON CONTROL INTERFACE FOR NETWORKED DIGITAL
AUDIO AND VIDEO PRODUCTS –
Part 1: General
FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote
international co-operation on all questions concerning standardization in the electrical and electronic fields. To
this end and in addition to other activities, IEC publishes International Standards, Technical Specifications,
Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC
Publication(s)”). Their preparation is entrusted to technical committees; any IEC National Committee interested
in the subject dealt with may participate in this preparatory work. International, governmental and non-
governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely
with the International Organization for Standardization (ISO) in accordance with conditions determined by
agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence
between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in
the latter.
5) IEC provides no marking procedure to indicate its approval and cannot be rendered responsible for any
equipment declared to be in conformity with an IEC Publication.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of
patent rights. IEC shall not be held responsible for identifying any or all such patent rights.
International Standard IEC 62379-1 has been prepared by IEC technical committee 100:
Audio, video and multimedia systems and equipment.
The text of this standard is based on the following documents:
FDIS Report on voting
100/1248/FDIS 100/1281/RVD
Full information on the voting for the approval of this standard can be found in the report on
voting indicated in the above table.
This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.

62379-1 © IEC:2007(E) – 5 –
The committee has decided that the contents of this publication will remain unchanged until
the maintenance result date indicated on the IEC web site under "http://webstore.iec.ch" in
the data related to the specific publication. At this date, the publication will be
• reconfirmed,
• withdrawn,
• replaced by a revised edition, or
• amended.
A bilingual version of this publication may be issued at a later date.

– 6 – 62379-1 © IEC:2007(E)
0 Introduction
0.1 Overview
This family of standards specifies a control framework for networked audiovisual equipment.
It provides a means for management entities to control not only transmission across the
network but also other functions within interface equipment.
Although it was originally developed for audio over asynchronous transfer mode (ATM) in
radio broadcasting, the control framework has been extended to encompass video and other
time-critical media, as well as other networking technologies and other applications in both
professional and consumer environments.
The control framework provides a number of key features:
• it provides a consistent interface to the functionality in an audiovisual unit;
• it enables systems to be built that are truly "plug and play", by providing the means for
equipment to discover what units are connected to the network and what their capabilities
are;
• it links discrete areas or blocks of functionality together in a consistent and structured
way;
• it allows us to define small focused building blocks from which more complex functionality
can be built;
• it ensures new functionality can be developed and integrated consistently and easily into
the framework.
The functionality provided by an audiovisual unit is represented using one or more "blocks"
(such as a cross-point switch or a gain control), structured and connected together using the
control framework.
As a further aid to the "plug-and-play" functionality, a common format for audio and video
being conveyed across the network is also specified, to avoid situations in which two pieces
of equipment fail to communicate because there is no format which both support. Equipment
may, of course, also support other formats appropriate to particular applications, and the
standard mechanisms for initiating and terminating communication will work for those formats
in the same way as for the standard formats.
0.2 Structure of the family of standards
IEC 62379 is intended to include the following parts:
Part 1: General
Part 2: Audio
Part 3: Video
Part 4: Data
Part 5: Transmission over networks
Part 6: Packet transfer service
Part 1 specifies aspects which are common to all equipment.
Parts 2 to 4 specify control of internal functions specific to equipment carrying particular types
of media; in the case of Part 4, this would be time-critical media other than audio and video,
for instance, RS232 and RS422 data for applications such as machine control, or the state of

62379-1 © IEC:2007(E) – 7 –
the “on air” light in a broadcast studio. Part 4 does not refer to packet data such as the control
messages themselves.
Part 5 specifies control of transmission of these media over each individual network
technology, with a separate subpart for each technology. It includes network specific
management interfaces along with network specific control elements that integrate into the
control framework.
Part 6 specifies carriage of control and status messages and non-audiovisual data over
transports that do not support audio and video, such as RS232 serial links, with (as with
Part 5) a separate subpart for each technology.
0.3 Model of the equipment being controlled
0.3.1 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.
Inputs Outputs
IEC  1627/07
Figure 1 – A block
A typical block would 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, an XLR 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.

Input
Output
port
port
IEC  1628/07
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

– 8 – 62379-1 © IEC:2007(E)
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.
Input
Network interface
channel 1
Input Input
channel 2 channel 1
Audio
output 1
Mixer
Audio
Pre-amp
input 1
Audio
output 2
IEC  1629/07
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 reprogramme the routing between them.
0.3.2 Control framework
The control framework consists of two lists; a list of blocks (also called control elements), and
a list of connections between them. In both lists, an individual block is identified by a "block
id", which is a number that is different for each block in a unit.
A block's entry in the list of blocks shows what type of block it is, represented by a globally
unique value as described in 0.3 . 5.
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.

62379-1 © IEC:2007(E) – 9 –
0.3.3 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.
0.3.4 How the framework enables "plug and play"
A management terminal simply needs to recognize 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 recognize the units themselves, only the blocks that describe the
functionality in which it is interested.
The discovery process would be:
• to create a list of the units, beginning with those to which it is directly connected; units can
be uniquely identified by their 48-bit MAC address;
• to retrieve the list of blocks from each device on the list; if any are network ports which
give access to further devices, to add those devices to the list (unless they are already on
it);
• to 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 play-out 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.
0.3.5 Defining a new type of block
A block's entry in the block list shows what type of block it is, represented by an object
0.4.2) which is a globally unique value that identifies the block type
identifier (OID) (see
definition.
The main requirement when adding a new type of 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.

– 10 – 62379-1 © IEC:2007(E)
0.4 Management information base (MIB)
0.4.1 Objects
Communication between the management terminal and the managed unit is by the simple
network management protocol (SNMP), which defines all management operations in terms of
reads and writes on a hierarchically organized collection of variables, or "managed objects",
known as a MIB.
Each object is identified by an 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.
Identifiers of objects defined in one of this family of standards begin 1.0.62379.p if defined in
part p, or 1.0.62379.p.s if defined in part p-s.
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 (see connectorTable in 4.2 . 5) .
Thus, the management terminal can discover what functionality a unit has and may be able to
reprogramme some of it. The SNMP protocol dictates that a command to change an object is
always 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 will report back to the management terminal exactly what it has done.
0.4.2 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 record 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 recognized the standard OIDs would see these
product-specific blocks as "black boxes"; it would recognize 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 this family of standards; provided
the sending and receiving devices both support the format, a call can be set up without the
management terminal being able to recognize it, though the management terminal might not
be able to display a user-friendly description of it.
0.4.3 Migration to XML
Increasingly, XML is being used as the interface to network management applications.
However, communication with the management agents in the networked devices is usually
through a gateway that translates between SNMP and XML, so that the managed unit only
needs to support SNMP.
A future addition to IEC 62379 (amendment or additional part) might standardize the XML
form; however, in that event, the underlying managed objects would remain the same in both
forms.
62379-1 © IEC:2007(E) – 11 –
0.5 Status broadcasts
0.5.1 Introduction
Status pages are messages containing structured values representing some internal state of a
unit. Each page is organized into a fixed format of related information. A unit may define and
support multiple types of status page.
Related status pages are collected together into groups called status broadcast groups. When
a remote entity requests a status broadcast, it specifies which group it wants to receive.
Status broadcast groups are identified by OIDs.
Status pages are the preferred method for regularly monitoring the state of a unit. Polling
fields in the MIB put more load on both the unit and the network, because they require the unit
to process an SNMP request on every occasion, rather than just once to set up the broadcast.
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.
This standard defines a number of status pages and groups. Other parts define their own
status pages and groups. Manufacturers may also define product-specific status pages and
groups.
0.5.2 Status page information sources
Status pages and groups may be associated either with a single block or with the unit as a
whole.
Three pieces of information are required to initiate a status page broadcast call (other
information may be required; however, this will be network-specific and specified in the
relevant subpart of Part 5):
• the block id – of the block that is to be the source of the status broadcast group call (a null
value is used for status broadcasts associated with the unit as a whole);
• the page group OID – of the particular status broadcast group to be produced;
• the required page rate – the rate at which the pages are generated.
If a unit supports multiple instances of a block type (for instance, an AES3 audio output,
which supports an audio level status broadcast group), it is not required to implement the
associated status broadcast group for each instance – it may implement it for just a subset of
them.
0.5.3 Status page general format
The first two octets of a status page indicate the page type. Page type identifiers are required
to be unique for all pages that are part of a given page group, but otherwise may be freely
allocated by the organization or manufacturer that specifies the page content. The format of
the rest of the page depends on the page type; the maximum length is 484 octets.
Numbers are coded in binary using a fixed number of bytes and big-endian. Text strings are in
UTF-8.
0.6 Calls
The network is expected to provide the following two kinds of services.
• Fixed bit rate one-to-many service for media streams and status broadcasts, with
guaranteed latency and throughput.
• "Best-effort" bidirectional one-to-one packet transfer service for control messages.

– 12 – 62379-1 © IEC:2007(E)
On an ATM network, these map onto CBR point-to-multipoint and UBR point-to-point calls,
respectively.
On a connectionless (and stateless) network such as IP, there is no direct equivalent of the
concept of an ATM "call". However, if the network is to provide the necessary quality of
service (QoS) guarantees for media streams, there will need to be some kind of mechanism
for allocating the resources needed for a stream. This mechanism must, in many ways, be
similar to the call set-up process on connection-oriented networks.
In the case of the packet transfer service, which may well be connectionless at the network
layer, for many applications there will be a relationship between the management terminal and
the managed unit within which some "state" information persists between transactions. For
instance, when updating software in the unit (see 0.9), only one management terminal can
write a given memory area at a time. Thus a "session" will exist between the management
terminal and the managed unit, which corresponds to a call on a connection-oriented network.
Associated with any media stream is "call identity" information which can include information
about the stream itself, the point where it enters the system, and each destination.
Destinations have an "importance" assigned to them, and it is normally only the most
important destinations that are reported. More details are given in Clause A. 4 .
0.7 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 also be useful in other applications.
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 (for example, 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 (for example, 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 play-out 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.
62379-1 © IEC:2007(E) – 13 –
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.
0.8 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 programme a number of events to occur simultaneously.
Also, multiple events can be associated so they occur one after the other much like a macro.
0.9 Uploading software
This standard includes (in 4. 2. 8 a nd 5.2) a mechanism for updating software and other
configuration information in units supporting the common control interface.
The intention is for a management terminal to be able to update software in a large number of
different pieces of equipment from different manufacturers without needing to run
manufacturer-specific applications.
The MIB objects defined in 4.2.8 are intended to 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.

– 14 – 62379-1 © IEC:2007(E)
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 serialNumber; 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 in 5.2.3 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, as specified in 5 . 2. 6. 1; w hen 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 as
specified in 5.2.6.2. It is made easy for the management terminal to check whether new
software is available.
0.10 Encapsulation of messages
Throughout this family of standards, the word "message" is used to mean an octet string
which is conveyed across the network as a single unit. On an IP network, it will be the "data"
part of a packet or datagram, i.e. excluding all the headers and framing. In the case of an
ATM network, it will normally be an AAL5-SDU.
Thus on an IP network SNMP messages are packaged in the normal way for SNMP, i.e. using
UDP over IP. On an ATM network they are packaged directly in AAL5, in the same way as in
ILMI.
0.11 Further information
Additional explanations of some aspects of this standard are given in Annex A.

62379-1 © IEC:2007(E) – 15 –
COMMON CONTROL INTERFACE FOR NETWORKED DIGITAL
AUDIO AND VIDEO PRODUCTS –
Part 1: General
1 Scope
This part of IEC 62379 specifies a control interface for products which convey audio and/or
video across digital networks.
Separate documents specify items specific to a particular type of traffic, a particular
networking technology, or a particular class of application.
2 Normative references
The following referenced documents are indispensable for the application of this document.
For dated references, only the edition cited applies. For undated references, the latest edition
of the referenced document (including any amendments) applies.
ISO/IEC 646:1991, Information technology – ISO 7-bit coded character set for information
interchange
ISO/IEC 8824-1:2002, Information technology – Abstract Syntax Notation One (ASN.1):
Specification of basic notation
IEEE Std 802:2001, IEEE Standard for Local and Metropolitan Area Networks: Overview and
Architecture
RFC1157, Simple Network Management Protocol (SNMP) (IETF Standard #15 STANDARD)
RFC 1441, Introduction to version 2 of the Internet-standard Network Management Framework
(IETF)
RFC 3411-3418, Simple Network Management Protocol version 3 (IETF Standard #62)
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
coordinated universal time
UTC
time scale which forms the basis of
...

IEC 62379-1 ®
Edition 1.0 2007-08
INTERNATIONAL
STANDARD
NORME
INTERNATIONALE
colour
inside
Common control interface for networked digital audio and video products –
Part 1: General
Interface de commande commune pour produits audio et vidéo numériques
connectés en réseaux –
Partie 1: Généralités
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form
or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from
either IEC or IEC's member National Committee in the country of the requester.
If you have any questions about IEC copyright or have an enquiry about obtaining additional rights to this publication,
please contact the address below or your local IEC member National Committee for further information.

Droits de reproduction réservés. Sauf indication contraire, aucune partie de cette publication ne peut être reproduite ni
utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie et les
microfilms, sans l'accord écrit de la CEI ou du Comité national de la CEI du pays du demandeur.
Si vous avez des questions sur le copyright de la CEI ou si vous désirez obtenir des droits supplémentaires sur cette
publication, utilisez les coordonnées ci-après ou contactez le Comité national de la CEI de votre pays de résidence.

IEC Central Office Tel.: [phone]
3, rue de Varembé Fax: [phone]
CH-1211 Geneva 20 [e-mail]
Switzerland www.iec.ch
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.

About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigenda or an amendment might have been published.

Useful links:
IEC publications search - www.iec.ch/searchpub Electropedia - www.electropedia.org
The advanced search enables you to find IEC publications The world's leading online dictionary of electronic and
by a variety of criteria (reference number, text, technical electrical terms containing more than 30 000 terms and
committee,…). definitions in English and French, with equivalent terms in
It also gives information on projects, replaced and additional languages. Also known as the International
withdrawn publications. Electrotechnical Vocabulary (IEV) on-line.

IEC Just Published - webstore.iec.ch/justpublished Customer Service Centre - webstore.iec.ch/csc
Stay up to date on all new IEC publications. Just Published If you wish to give us your feedback on this publication
details all new publications released. Available on-line and or need further assistance, please contact the
also once a month by email. Customer Service Centre: [e-mail].

A propos de la CEI
La Commission Electrotechnique Internationale (CEI) est la première organisation mondiale qui élabore et publie des
Normes internationales pour tout ce qui a trait à l'électricité, à l'électronique et aux technologies apparentées.

A propos des publications CEI
Le contenu technique des publications de la CEI est constamment revu. Veuillez vous assurer que vous possédez
l’édition la plus récente, un corrigendum ou amendement peut avoir été publié.

Liens utiles:
Recherche de publications CEI - www.iec.ch/searchpub Electropedia - www.electropedia.org
La recherche avancée vous permet de trouver des Le premier dictionnaire en ligne au monde de termes
publications CEI en utilisant différents critères (numéro de électroniques et électriques. Il contient plus de 30 000
référence, texte, comité d’études,…). termes et définitions en anglais et en français, ainsi que
Elle donne aussi des informations sur les projets et les les termes équivalents dans les langues additionnelles.
publications remplacées ou retirées. Egalement appelé Vocabulaire Electrotechnique
International (VEI) en ligne.
Just Published CEI - webstore.iec.ch/justpublished
Service Clients - webstore.iec.ch/csc
Restez informé sur les nouvelles publications de la CEI.
Just Published détaille les nouvelles publications parues. Si vous désirez nous donner des commentaires sur
Disponible en ligne et aussi une fois par mois par email. cette publication ou si vous avez des questions
contactez-nous: [e-mail].
IEC 62379-1 ®
Edition 1.0 2007-08
INTERNATIONAL
STANDARD
NORME
INTERNATIONALE
colour
inside
Common control interface for networked digital audio and video products –

Part 1: General
Interface de commande commune pour produits audio et vidéo numériques

connectés en réseaux –
Partie 1: Généralités
INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
COMMISSION
ELECTROTECHNIQUE
PRICE CODE
INTERNATIONALE
CODE PRIX XB
ICS 33.160; 35.100 ISBN 978-2-83220-239-5

– 2 – 62379-1  IEC:2007
CONTENTS
FOREWORD . 4

0 Introduction . 6
0.1 Overview . 6
0.2 Structure of the family of standards . 6
0.3 Model of the equipment being controlled . 7
0.3.1 Blocks . 7
0.3.2 Control framework . 8
0.3.3 How the framework helps when designing units . 9
0.3.4 How the framework enables "plug and play" . 9
0.3.5 Defining a new type of block . 9
0.4 Management information base (MIB) . 10
0.4.1 Objects . 10
0.4.2 Other uses of OIDs . 10
0.4.3 Migration to XML . 10
0.5 Status broadcasts . 11
0.5.1 Introduction . 11
0.5.2 Status page information sources . 11
0.5.3 Status page general format. 11
0.6 Calls . 11
0.7 Privilege levels . 12
0.8 Automation . 13
0.9 Uploading software . 13
0.10 Encapsulation of messages . 14
0.11 Further information . 14
1 Scope . 15
2 Normative references . 15
3 Terms and definitions . 15
4 Unit management . 18
4.1 Protocol . 18
4.2 MIB definitions . 19
4.2.1 General . 19
4.2.2 Application-wide type definitions . 20
4.2.3 Conceptual row type definitions . 24
4.2.4 MIB objects for basic unit identity and status information . 25
4.2.5 MIB objects for the block framework . 28
4.2.6 MIB objects for real time clock information. 30
4.2.7 MIB objects for reference clock information . 31
4.2.8 MIB objects for software upload . 32
4.2.9 MIB objects for scheduled operations . 34
5 Procedures . 36
5.1 Real-time clocks . 36
5.2 Procedures for uploading software . 36
5.2.1 Areas. 36
5.2.2 Contents . 37
5.2.3 Procedure for updating a software component . 37

62379-1  IEC:2007 – 3 –
5.2.4 File format for a software component . 38
5.2.5 Format for product files . 39
5.2.6 Software distribution . 40
5.3 Scheduled operations . 40
5.3.1 Requesting a scheduled operation . 40
5.3.2 Executing a scheduled operation . 42
5.3.3 Delaying a scheduled operation . 42
5.3.4 Aborting a scheduled operation . 42
5.3.5 State of relative operations . 42
6 Status broadcasts . 42
6.1 General . 42
6.2 Page formats . 44
6.2.1 Basic unit identity page . 44
6.2.2 Time-of-day page . 44
6.2.3 Scheduled operations page . 45
6.3 Page groups . 45
6.3.1 basicUnitStatus . 45
6.3.2 timeOfDay . 45
6.3.3 scheduledOps . 45

Annex A (informative) Background information . 47
Annex B (informative) Machine-readable MIB definitions . 50
Annex C (informative) Machine-readable status page-group definitions . 68

Bibliography . 69

Figure 1 – A block . 7
Figure 2 – Ports . 7
Figure 3 – Example of a "unit" . 8

Table 1 – Managed objects conveying information about the unit . 25
Table 2 – Managed objects for block and connector configuration . 28
Table 3 – Managed objects for real-time clock information . 30
Table 4 – Managed objects for reference clock information . 31
Table 5 – Managed objects for software upload . 32
Table 6 – Managed objects for scheduled operations . 34

– 4 – 62379-1  IEC:2007
INTERNATIONAL ELECTROTECHNICAL COMMISSION
________________
COMMON CONTROL INTERFACE FOR NETWORKED DIGITAL
AUDIO AND VIDEO PRODUCTS –
Part 1: General
FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote
international co-operation on all questions concerning standardization in the electrical and electronic fields. To
this end and in addition to other activities, IEC publishes International Standards, Technical Specifications,
Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC
Publication(s)”). Their preparation is entrusted to technical committees; any IEC National Committee interested
in the subject dealt with may participate in this preparatory work. International, governmental and non-
governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely
with the International Organization for Standardization (ISO) in accordance with conditions determined by
agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence
between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in
the latter.
5) IEC provides no marking procedure to indicate its approval and cannot be rendered responsible for any
equipment declared to be in conformity with an IEC Publication.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of
patent rights. IEC shall not be held responsible for identifying any or all such patent rights.
International Standard IEC 62379-1 has been prepared by IEC technical committee 100:
Audio, video and multimedia systems and equipment.
This bilingual version (2012-08) corresponds to the monolingual English version, published in
2007-08.
The text of this standard is based on the following documents:
FDIS Report on voting
100/1248/FDIS 100/1281/RVD
Full information on the voting for the approval of this standard can be found in the report on
voting indicated in the above table.
The French version of this standard has not been voted upon.
This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.

62379-1  IEC:2007 – 5 –
The committee has decided that the contents of this publication will remain unchanged until
the maintenance result date indicated on the IEC web site under "http://webstore.iec.ch" in
the data related to the specific publication. At this date, the publication will be
• reconfirmed,
• withdrawn,
• replaced by a revised edition, or
• amended.
IMPORTANT – The 'colour inside' logo on the cover page of this publication indicates
that it contains colours which are considered to be useful for the correct
understanding of its contents. Users should therefore print this document using a
colour printer.
– 6 – 62379-1  IEC:2007
0 Introduction
0.1 Overview
This family of standards specifies a control framework for networked audiovisual equipment.
It provides a means for management entities to control not only transmission across the
network but also other functions within interface equipment.
Although it was originally developed for audio over asynchronous transfer mode (ATM) in
radio broadcasting, the control framework has been extended to encompass video and other
time-critical media, as well as other networking technologies and other applications in both
professional and consumer environments.
The control framework provides a number of key features:
• it provides a consistent interface to the functionality in an audiovisual unit;
• it enables systems to be built that are truly "plug and play", by providing the means for
equipment to discover what units are connected to the network and what their capabilities
are;
• it links discrete areas or blocks of functionality together in a consistent and structured
way;
• it allows us to define small focused building blocks from which more complex functionality
can be built;
• it ensures new functionality can be developed and integrated consistently and easily into
the framework.
The functionality provided by an audiovisual unit is represented using one or more "blocks"
(such as a cross-point switch or a gain control), structured and connected together using the
control framework.
As a further aid to the "plug-and-play" functionality, a common format for audio and video
being conveyed across the network is also specified, to avoid situations in which two pieces
of equipment fail to communicate because there is no format which both support. Equipment
may, of course, also support other formats appropriate to particular applications, and the
standard mechanisms for initiating and terminating communication will work for those formats
in the same way as for the standard formats.
0.2 Structure of the family of standards
IEC 62379 is intended to include the following parts:
Part 1: General
Part 2: Audio
Part 3: Video
Part 4: Data
Part 5: Transmission over networks
Part 6: Packet transfer service
Part 1 specifies aspects which are common to all equipment.
Parts 2 to 4 specify control of internal functions specific to equipment carrying particular types
of media; in the case of Part 4, this would be time-critical media other than audio and video,
for instance, RS232 and RS422 data for applications such as machine control, or the state of

62379-1  IEC:2007 – 7 –
the “on air” light in a broadcast studio. Part 4 does not refer to packet data such as the control
messages themselves.
Part 5 specifies control of transmission of these media over each individual network
technology, with a separate subpart for each technology. It includes network specific
management interfaces along with network specific control elements that integrate into the
control framework.
Part 6 specifies carriage of control and status messages and non-audiovisual data over
transports that do not support audio and video, such as RS232 serial links, with (as with
Part 5) a separate subpart for each technology.
0.3 Model of the equipment being controlled
0.3.1 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.
Inputs Outputs
IEC  1627/07
Figure 1 – A block
A typical block would 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, an XLR 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.

Input
Output
port
port
IEC  1628/07
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

– 8 – 62379-1  IEC:2007
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.
Input
Network interface
channel 1
Input Input
channel 2 channel 1
Audio
output 1
Mixer
Audio
Pre-amp
input 1
Audio
output 2
IEC  1629/07
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 reprogramme the routing between them.
0.3.2 Control framework
The control framework consists of two lists; a list of blocks (also called control elements), and
a list of connections between them. In both lists, an individual block is identified by a "block
id", which is a number that is different for each block in a unit.
A block's entry in the list of blocks shows what type of block it is, represented by a globally
unique value as described in 0.3.5.
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.

62379-1  IEC:2007 – 9 –
0.3.3 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.
0.3.4 How the framework enables "plug and play"
A management terminal simply needs to recognize 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 recognize the units themselves, only the blocks that describe the
functionality in which it is interested.
The discovery process would be:
• to create a list of the units, beginning with those to which it is directly connected; units can
be uniquely identified by their 48-bit MAC address;
• to retrieve the list of blocks from each device on the list; if any are network ports which
give access to further devices, to add those devices to the list (unless they are already on
it);
• to 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 play-out 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.
0.3.5 Defining a new type of block
A block's entry in the block list shows what type of block it is, represented by an object
identifier (OID) (see 0.4.2) which is a globally unique value that identifies the block type
definition.
The main requirement when adding a new type of 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.

– 10 – 62379-1  IEC:2007
0.4 Management information base (MIB)
0.4.1 Objects
Communication between the management terminal and the managed unit is by the simple
network management protocol (SNMP), which defines all management operations in terms of
reads and writes on a hierarchically organized collection of variables, or "managed objects",
known as a MIB.
Each object is identified by an 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.
Identifiers of objects defined in one of this family of standards begin 1.0.62379.p if defined in
part p, or 1.0.62379.p.s if defined in part p-s.
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 (see connectorTable in 4.2.5).
Thus, the management terminal can discover what functionality a unit has and may be able to
reprogramme some of it. The SNMP protocol dictates that a command to change an object is
always 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 will report back to the management terminal exactly what it has done.
0.4.2 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 record 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 recognized the standard OIDs would see these
product-specific blocks as "black boxes"; it would recognize 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 this family of standards; provided
the sending and receiving devices both support the format, a call can be set up without the
management terminal being able to recognize it, though the management terminal might not
be able to display a user-friendly description of it.
0.4.3 Migration to XML
Increasingly, XML is being used as the interface to network management applications.
However, communication with the management agents in the networked devices is usually
through a gateway that translates between SNMP and XML, so that the managed unit only
needs to support SNMP.
A future addition to IEC 62379 (amendment or additional part) might standardize the XML
form; however, in that event, the underlying managed objects would remain the same in both
forms.
62379-1  IEC:2007 – 11 –
0.5 Status broadcasts
0.5.1 Introduction
Status pages are messages containing structured values representing some internal state of a
unit. Each page is organized into a fixed format of related information. A unit may define and
support multiple types of status page.
Related status pages are collected together into groups called status broadcast groups. When
a remote entity requests a status broadcast, it specifies which group it wants to receive.
Status broadcast groups are identified by OIDs.
Status pages are the preferred method for regularly monitoring the state of a unit. Polling
fields in the MIB put more load on both the unit and the network, because they require the unit
to process an SNMP request on every occasion, rather than just once to set up the broadcast.
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.
This standard defines a number of status pages and groups. Other parts define their own
status pages and groups. Manufacturers may also define product-specific status pages and
groups.
0.5.2 Status page information sources
Status pages and groups may be associated either with a single block or with the unit as a
whole.
Three pieces of information are required to initiate a status page broadcast call (other
information may be required; however, this will be network-specific and specified in the
relevant subpart of Part 5):
• the block id – of the block that is to be the source of the status broadcast group call (a null
value is used for status broadcasts associated with the unit as a whole);
• the page group OID – of the particular status broadcast group to be produced;
• the required page rate – the rate at which the pages are generated.
If a unit supports multiple instances of a block type (for instance, an AES3 audio output,
which supports an audio level status broadcast group), it is not required to implement the
associated status broadcast group for each instance – it may implement it for just a subset of
them.
0.5.3 Status page general format
The first two octets of a status page indicate the page type. Page type identifiers are required
to be unique for all pages that are part of a given page group, but otherwise may be freely
allocated by the organization or manufacturer that specifies the page content. The format of
the rest of the page depends on the page type; the maximum length is 484 octets.
Numbers are coded in binary using a fixed number of bytes and big-endian. Text strings are in
UTF-8.
0.6 Calls
The network is expected to provide the following two kinds of services.
• Fixed bit rate one-to-many service for media streams and status broadcasts, with
guaranteed latency and throughput.
• "Best-effort" bidirectional one-to-one packet transfer service for control messages.

– 12 – 62379-1  IEC:2007
On an ATM network, these map onto CBR point-to-multipoint and UBR point-to-point calls,
respectively.
On a connectionless (and stateless) network such as IP, there is no direct equivalent of the
concept of an ATM "call". However, if the network is to provide the necessary quality of
service (QoS) guarantees for media streams, there will need to be some kind of mechanism
for allocating the resources needed for a stream. This mechanism must, in many ways, be
similar to the call set-up process on connection-oriented networks.
In the case of the packet transfer service, which may well be connectionless at the network
layer, for many applications there will be a relationship between the management terminal and
the managed unit within which some "state" information persists between transactions. For
instance, when updating software in the unit (see 0.9), only one management terminal can
write a given memory area at a time. Thus a "session" will exist between the management
terminal and the managed unit, which corresponds to a call on a connection-oriented network.
Associated with any media stream is "call identity" information which can include information
about the stream itself, the point where it enters the system, and each destination.
Destinations have an "importance" assigned to them, and it is normally only the most
important destinations that are reported. More details are given in Clause A.4.
0.7 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 also be useful in other applications.
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 (for example, 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 (for example, 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 play-out 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.
62379-1  IEC:2007 – 13 –
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.
0.8 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 programme a number of events to occur simultaneously.
Also, multiple events can be associated so they occur one after the other much like a macro.
0.9 Uploading software
This standard includes (in 4.2.8 and 5.2) a mechanism for updating software and other
configuration information in units supporting the common control interface.
The intention is for a management terminal to be able to update software in a large number of
different pieces of equipment from different manufacturers without needing to run
manufacturer-specific applications.
The MIB objects defined in 4.2.8 are intended to 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.

– 14 – 62379-1  IEC:2007
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 “
...