SIST EN 62379-1:2008

SLOVENSKI STANDARD
01-februar-2008
6NXSQLNUPLOQLYPHVQLN]DGLJLWDOQHDYGLRLQYLGHRL]GHONHYNOMXþHQHYRPUHåMH
GHO6SORãQR,(&
Common control interface for networked digital audio and video products -- Part 1:
General
Gemeinsame Steuerschnittstelle für netzwerkbetriebene digitale Audio- und Videogeräte
-- Teil 1: Allgemeines
Interface de commande commun destiné aux produits audio et video numériques
connectés en réseau -- Partie 1: Généralités
Ta slovenski standard je istoveten z: EN 62379-1:2007
ICS:
33.160.01 Avdio, video in avdiovizualni Audio, video and audiovisual
sistemi na splošno systems in general
35.200 Vmesniška in povezovalna Interface and interconnection
oprema equipment
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD
EN 62379-1
NORME EUROPÉENNE
November 2007
EUROPÄISCHE NORM
ICS 33.160; 35.100
English version
Common control interface
for networked digital audio and video products -
Part 1: General
(IEC 62379-1:2007)
Interface de commande commun destiné Gemeinsame Steuerschnittstelle
aux produits audio et video numériques für netzwerkbetriebene digitale
connectés en réseau - Audio- und Videogeräte -
Partie 1: Généralités Teil 1: Allgemeines
(CEI 62379-1:2007) (IEC 62379-1:2007)

This European Standard was approved by CENELEC on 2007-10-01. CENELEC members are bound to comply
with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this European Standard
the status of a national standard without any alteration.

Up-to-date lists and bibliographical references concerning such national standards may be obtained on
application to the Central Secretariat or to any CENELEC member.

This European Standard exists in two official versions (English and German). A version in any other language
made by translation under the responsibility of a CENELEC member into its own language and notified to the
Central Secretariat has the same status as the official versions.

CENELEC members are the national electrotechnical committees of Austria, Belgium, Bulgaria, Cyprus, the
Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia,
Lithuania, Luxembourg, Malta, the Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain,
Sweden, Switzerland and the United Kingdom.

CENELEC
European Committee for Electrotechnical Standardization
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für Elektrotechnische Normung

Central Secretariat: rue de Stassart 35, B - 1050 Brussels

© 2007 CENELEC - All rights of exploitation in any form and by any means reserved worldwide for CENELEC members.
Ref. No. EN 62379-1:2007 E
Foreword
The text of document 100/1248/FDIS, future edition 1 of IEC 62379-1, prepared by IEC TC 100, Audio,
video and multimedia systems and equipment, was submitted to the IEC-CENELEC parallel vote and was
approved by CENELEC as EN 62379-1 on 2007-10-01.
The following dates were fixed:
– latest date by which the EN has to be implemented
at national level by publication of an identical
national standard or by endorsement (dop) 2008-07-01
– latest date by which the national standards conflicting
with the EN have to be withdrawn (dow) 2010-10-01
Annex ZA has been added by CENELEC.
__________
Endorsement notice
The text of the International Standard IEC 62379-1:2007 was approved by CENELEC as a European
Standard without any modification.
__________
- 3 - EN 62379-1:2007
Annex ZA
(normative)
Normative references to international publications
with their corresponding European publications

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.

NOTE  When an international publication has been modified by common modifications, indicated by (mod), the relevant EN/HD
applies.
Publication Year Title EN/HD Year

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

1)
RFC 1157 - Simple Network Management Protocol - -
(SNMP) (IETF Standard #15)
1)
RFC 1441 - Introduction to version 2 of the Internet-- -
standard Network Management Framework
(IETF)
1)
RFC 3411-3418 - Simple Network Management Protocol - -
version 3 (IETF Standard #62)
1)
Undated reference.
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 curre
...