Tektronix products are covered by U.S. and foreign patents, issued and pending. Information in this publication supercedes
that in all previously published material. Specifications and price change privileges reserved.
TEKTRONIX and TEK are registered trademarks of Tektronix, Inc.
Contacting Tektronix
Tektronix, Inc.
14150 SW Karl Braun Drive
P.O. Box 500
Beaverton, OR 97077
USA
For product information, sales, service, and technical support:
HIn North America, call 1-800-833-9200.
HWorldwide, visit www.tektronix.com to find contacts in your area.
Warranty 2
Tektronix warrants that this product will be free from defects in materials and workmanship for a period of one (1)
year from the date of shipment. If any such product proves defective during this warranty period, Tektronix, at its
option, either will repair the defective product without charge for parts and labor, or will provide a replacement in
exchange for the defective product. Parts, modules and replacement products used by Tektronix for warranty work
may be new or reconditioned to like new performance. All replaced parts, modules and products become the
property of Tektronix.
In order to obtain service under this warranty, Customer must notify Tektronix of the defect before the expiration
of the warranty period and make suitable arrangements for the performance of service. Customer shall be
responsible for packaging and shipping the defective product to the service center designated by Tektronix, with
shipping charges prepaid. Tektronix shall pay for the return of the product to Customer if the shipment is to a
location within the country in which the Tektronix service center is located. Customer shall be responsible for
paying all shipping charges, duties, taxes, and any other charges for products returned to any other locations.
This warranty shall not apply to any defect, failure or damage caused by improper use or improper or inadequate
maintenance and care. Tektronix shall not be obligated to furnish service under this warranty a) to repair damage
resulting from attempts by personnel other than Tektronix representatives to install, repair or service the product;
b) to repair damage resulting from improper use or connection to incompatible equipment; c) to repair any
damage or malfunction caused by the use of non-Tektronix supplies; or d) to service a product that has been
modified or integrated with other products when the effect of such modification or integration increases the time
or difficulty of servicing the product.
THIS WARRANTY IS GIVEN BY TEKTRONIX WITH RESPECT TO THE PRODUCT IN LIEU OF ANY
OTHER WARRANTIES, EXPRESS OR IMPLIED. TEKTRONIX AND ITS VENDORS DISCLAIM ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
TEKTRONIX’ RESPONSIBILITY TO REPAIR OR REPLACE DEFECTIVE PRODUCTS IS THE SOLE AND
EXCLUSIVE REMEDY PROVIDED TO THE CUSTOMER FOR BREACH OF THIS WARRANTY.
TEKTRONIX AND ITS VENDORS WILL NOT BE LIABLE FOR ANY INDIRECT, SPECIAL, INCIDENTAL,
OR CONSEQUENTIAL DAMAGES IRRESPECTIVE OF WHETHER TEKTRONIX OR THE VENDOR HAS
ADVANCE NOTICE OF THE POSSIBILITY OF SUCH DAMAGES.
Warranty 9(b)
Tektronix warrants that the media on which this software product is furnished and the encoding of the programs on
the media will be free from defects in materials and workmanship for a period of three (3) months from the date of
shipment. If any such medium or encoding proves defective during the warranty period, Tektronix will provide a
replacement in exchange for the defective medium. Except as to the media on which this software product is
furnished, this software product is provided “as is” without warranty of any kind, either express or implied.
Tektronix does not warrant that the functions contained in this software product will meet Customer’s
requirements or that the operation of the programs will be uninterrupted or error-free.
In order to obtain service under this warranty, Customer must notify Tektronix of the defect before the expiration
of the warranty period. If Tektronix is unable to provide a replacement that is free from defects in materials and
workmanship within a reasonable time thereafter, Customer may terminate the license for this software product
and return this software product and any associated materials for credit or refund.
THIS WARRANTY IS GIVEN BY TEKTRONIX WITH RESPECT TO THE PRODUCT IN LIEU OF ANY
OTHER WARRANTIES, EXPRESS OR IMPLIED. TEKTRONIX AND ITS VENDORS DISCLAIM ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
TEKTRONIX’ RESPONSIBILITY TO REPLACE DEFECTIVE MEDIA OR REFUND CUSTOMER’S
PAYMENT IS THE SOLE AND EXCLUSIVE REMEDY PROVIDED TO THE CUSTOMER FOR BREACH OF
THIS WARRANTY. TEKTRONIX AND ITS VENDORS WILL NOT BE LIABLE FOR ANY INDIRECT,
SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES IRRESPECTIVE OF WHETHER TEKTRONIX
OR THE VENDOR HAS ADVANCE NOTICE OF THE POSSIBILITY OF SUCH DAMAGES.
DTV Monitors MPEG Transport Stream Monitor Programmer Manual
iii
Table of Contents
iv
DTV Monitors MPEG Transport Stream Monitor Programmer Manual
Preface
Model Numbers
This document specifies the DTV Monitors (MTM400A, IPM400A, QAM400A,
and RFM300) remote control and status monitoring interfaces available to a
Management application. Two interfaces are provided; SNMP and an HTTP
Web-based interface.
The manual is organized into the following sections:
HIntroduction
HDTV Monitor MIB (Management Information Base)
HMIB Group Overview
HSystem Structure
HMPEG Structure
HWeb Server URLs
This document describes the MIB for the DTV Monitors (MTM400A,
IPM400A, QAM400A, and RFM300) and the MTM400 instruments. The
software is common to all instruments and care has been taken to ensure that all
the interfaces remain consistent. Any DTV Monitor will return “MTM400” as a
model number through the MIB. This is to ensure that it would be an exact
replacement for the MTM400 in customer systems. The IPM400A, QAM400A,
and RFM300 variants of the MTM400 have reduced functionality.
References to the either “DTV Monitor” or “MTM400A” in this manual should
be taken to refer to all of the DTV Monitors, that is the MTM400A, IPM400A,
QAM400A, and the RFM300, unless otherwise specified.
DTV Monitors MPEG Transport Stream Monitor Programmer Manual
v
Preface
Related Material
The following documents are available on the Tektronix Web site
(www.tektronix.com) and the docuemntation disk supplied with the instruments.
Additional documentation, such as Read Me files, may also be included on the
documentation disk.
HATSC standards (Advanced Television Systems Committee)
www.atsc.org/
HISDB/ARIB standards (Association of Radio Industries and Businesses)
www.arib.or.jp/english/
HSCTE Society of Cable Television Engineers
www.scte.org/
DTV Monitors MPEG Transport Stream Monitor Programmer Manual
vii
Preface
viii
DTV Monitors MPEG Transport Stream Monitor Programmer Manual
Introduction
Introduction
This document specifies the DTV Monitor remote control and status monitoring
interfaces available to a Management application. Two interfaces are provided;
SNMP and an HTTP Web-based interface.
NOTE. The DTV Monitor Programmer Interface MIB file accompanying this
document contains entries not described in the manual. These entries should not
be used.
This document should be read in conjunction with the DTV Monitor Quick Start
User Manual and Technical Reference. The reader must be thoroughly familiar
with the operation of the DTV Monitors and have detailed knowledge of SNMP
and HTTP.
Do not use multiple variable binding SET requests. Only single variable binding
SET requests should be used.
SNMP and MIBs
This document specifies the facilities provided by the DTV Monitor Simple
Network Management Protocol (SNMP) agent, which allows various parameters
within the DTV Monitor to be viewed and set. This will allow you to develop
management applications that can control the DTV Monitor instrument across a
network using SNMP.
The DTV Monitor SNMP agent has been implemented as an extensible agent
under Nucleus, and as such conforms to SNMP v1.
The Simple Network Management Protocol (SNMP) is an Internet standard
protocol for remote management of entities on a network. It is defined in Internet
documents STD-15 (RFC1157) and STD-16 (RFC1155 and RFC1212). STD-15
defines the protocol operations; STD-16 defines the way in which information is
structured under SNMP (SMI - Structure of Management Information).
SNMP defines a way of structuring information in a hierarchy of objects
supporting both single objects and tables of objects, and making the information
available through a network protocol.
Each object can be one of four types, namely:
HInteger. Represents numerical values.
HOctetString. Represents byte streams.
DTV Monitors MPEG Transport Stream Monitor Programmer Manual
1−1
Introduction
HDisplayString. Represents printable strings.
HObject Identifier (OID). References other objects within SNMP.
There are essentially three types of operations that can be performed on each
object:
HGet. Retrieves the value of an object.
HGetNext. Retrieves the value of an object along with the OID of the next
object available.
HSet. Sets the value of an object.
The complete set of objects accessible through an SNMP agent is called the
Management Information Base (MIB). The MIB is a tree structure with MIB
objects at the leaves of the tree. Every branch and leaf of the tree is numbered
according to a scheme ultimately under the administration of either ISO or the
CCITT (or the ITU-T as they are now called). (The root of the tree has three
branches: branch 0 is owned by the CCITT, 1 by ISO and 2 is jointly owned by
ISO and the CCITT.) These organizations have delegated various branches of
this tree to other authorities. Everything of interest to SNMP is under the control
of the IANA (Internet Assigned Numbers Authority), which owns the branch
named:
iso (1).org (3).dod (6).internet (1)
The strings of numbers identifying parts of the MIB tree are called Object
Identifiers (OIDs).
The Internet standard management sub-trees are all under
iso (1).org (3).dod (6).internet (1).mgmt (2).
However the IANA also allocates numbers to other organizations. Companies
can obtain their own sub-trees under
iso (1).org (3).dod (6).internet (1).private (4).enterprises (1).
This entire tree structure is called the MIB. A MIB module is a set of sub-sections of this tree that form some coherent function or set of functions, usually
described in a single document and qualified with some other title, such as
RMON MIB.
NOTE. A MIB module is sometimes referred to as the MIB.
1−2
DTV Monitors MPEG Transport Stream Monitor Programmer Manual
A MIB Module is defined in a text file using ASN.1 (Abstract Syntax Notation
One).
For more detailed explanations of network management using SNMP, you can
refer to The Simple Book: An Introduction to Internet Management (Marshall T.
Rose, Prentice Hall, ISBN 0-13-451659-1).
DTV Monitor SNMP Community
SNMP provides a simple mechanism for security, there are community strings to
govern read and write to the MIB; these function as passwords.
For the DTV Monitors, the community string “public” is used for read and write
access. It is possible to add a second community string. However, the “public“
access will still work.
DTV Monitor SNMP Traps
Introduction
SNMP provides a mechanism for a device to send a notification message to the
management system when an event occurs. This means that the management
system can poll the device less often and so reduce network traffic.
The important point to note here is that it does not mean that the management
system can stop polling the device. Traps are sent using the UDP network
protocol. This mechanism does not guarantee arrival of all packets; a trap
message can be lost.
Trap messages may be lost not only in the UDP transport layer, but inside the
device. The DTV Monitors take steps to avoid flooding the network with traps;
this means some traps are discarded when there are a burst of errors in a stream.
A trap should be thought of as a prompt to visit the device to discover status
rather than a mechanism to completely know the status.
To prevent a flood of trap messages on a network, the DTV Monitors have a
throttling mechanism. A flood of trap messages is to be avoided since this could
hamper the operator’s ability to use the network to understand and contain an
error condition. In the extreme case a flood of trap messages could cause the
management system to fail.
On the DTV Monitor, a maximum number of trap messages per second is
defined. This is in total, so, if a limit of 10 per second is set, this will yield 5 per
second if two trap consumers are subscribed. Internally, there is a buffer for 100
traps so a short burst can be accommodated without losing messages. If the
buffer overflows, trap messages are discarded.
The implication of the preceding information is that network bandwidth, or trap
handling capability, is treated as a limited resource. To avoid wasting this
DTV Monitors MPEG Transport Stream Monitor Programmer Manual
1−3
Introduction
resource, steps are taken to ensure that any management system subscribed for
trap messages still requires these messages. So when a management system
subscribes to trap messages, this is only for a few minutes. The management
system must repeatedly subscribe in order to continue to receive trap messages.
This provides protection in the case of a management system exiting improperly.
Some users do not want to repeatedly subscribe. In this situation, the trap
timeout can be set to zero, in which case, subscription is suspended and trap
messages are sent indefinitely.
NOTE. If the trap timeout is set to zero, a central error in a network of DTV
Monitors may cause every monitor to report its full rate of traps, which can limit
the user’s ability to control the network and correct the error.
DTV Monitor Web Server
The DTV Monitors have a Web server interface on HTTP port 80. A number of
URLs are supported and are used primarily for transferring bulk data, unsuited to
SNMP, to and from the DTV Monitors.
A full list of supported Web server URLs is given in this manual (see Web ServerURLs section).
1−4
DTV Monitors MPEG Transport Stream Monitor Programmer Manual
DTV Monitor MIB
DTV Monitor MIB
MIB Types
Tektronix has been assigned the following root OID:
iso.org.dod.internet.private.enterprises.128
Under this OID Tektronix can define its own MIB for various products.
The MIB subtree for DTV Monitors is under the following OID:
The tree is specified in the two ASN.1 text files: ADSYS.MIB defines the
structure of device specific elements and ADMPEG.MIB defines the structure of
the MPEG Interface specific elements.
The supplied MIB includes some items that do not apply to the DTV Monitors,
because the MIB is common to several products.
The DTV Monitor MIB defines the following extra MIB types.
EVID
EvState
This type defines events that can occur within the DTV Monitor . It is essentially
a WORD, where values 0x1xxx represent events that are generated by the DTV
Monitor, such as Clock and Battery errors. Values over and including 0x2000
represent events that are generated by specific MPEG Interfaces such as Sync
Lock or Continuity errors. The full list of these events can be found in the
MTM400A, IPM400A, QAM400A, and RFM300 Test Parameter and Configuration File Technical Reference (Tektronix part number: 077-0177-xx).
This type represents the state of a given event which can be Green, Yellow or
Red. Green indicates that there is no error, yellow indicates that there has been
an error since this event was last reset, and red indicates that there is a persistent
error.
This is essentially a WORD. Green is defined as 0x1000, yellow as 0x2000 and
red as 0x3xxx, where
that the state is unknown (for example, during the settling time of a test), and
0x4000 means that the event is disabled. Two final values are also possible:
0x5000 is the maintenance state and 0x6000 is N/A (for example, SFN testing
when there is no SFN data).
xxx is the specific error number. A value of 0x0000 means
DTV Monitors MPEG Transport Stream Monitor Programmer Manual
2−1
DTV Monitor MIB
ÏÏ
ÏÏ
AlmValue
Simple Boolean
Log Index
Time Stamp
This specifies which alarms are activated when an event occurs. It is an integer
type and can take combinations of the following values:
This enumerated type is used to represent a Boolean value.
This type represents an integer index into a log.
Time stamps are used in several MIB items to specify the time of events. Each
time stamp is stored as an eight-byte structure, which consists of an 11-bit signed
integer representing the UTC offset and a 53 bit signed integer representing the
UTC time. The UTC offset is the number of minutes that must be added to UTC
time to obtain the local time on the DTV Monitor. The UTC time is the number
of microseconds since midnight Greenwich Mean Time (GMT) January 1, 1970.
Figure 2−1 shows that the time stamp is actually stored with the UTC offset,
followed by the UTC Time in MSB format. However, the bytes are reversed
when the time stamp is presented as part of an Octet String through SNMP so
that the numbers are in LSB format. Care should be taken with byte 6 because it
contains both the UTC offset and UTC time.
UTC Offset
11 bits
Stored Format
SNMP Format
MSBLSB
76543210
01234567
LSB
Figure 2−1: Time stamp storage
UTC Time
53 bits
MSB
2−2
DTV Monitors MPEG Transport Stream Monitor Programmer Manual
Accessing MIB Objects
DTV Monitor MIB
This section describes how to access objects within the DTV Monitor MIB.
SNMP Access
Operations
Single Leaf Objects
Tables
The DTV Monitor SNMP agent fully supports the standard SNMP GetRequest,
GetNextRequest, and SetRequest PDU operations. This document specifies the
access permissions for each object within the DTV Monitor MIB using the
following conventions:
H‘Get’ indicates that the GetRequest and GetNextRequest can be used.
H‘Set’ indicates that the SetRequest can be used.
Single Leaf Objects are single-value elements whose values can be accessed
using the standard SNMP access operations by appending ‘0’ to the appropriate
OID specified in the MIB. For example, in order to access the program name
within the System Information Group, use the following OID:
‘…adsysProductName.0’.
The DTV Monitor MIB defines a number of tables. Tables normally contain
objects that can have multiple values, each referenced by appending the required
row number to the OID of the object specified in the MIB. Management
applications typically access values of objects within tables by first performing a
GetNextRequest-PDU on the OID object that will return the OID of the first
value. Subsequent calls to the GetNextRequest operation will obtain the values
for this object within the table. When the operation returns the ‘No Such Name’
error, this indicates that the last value has been reached.
Some tables within the DTV Monitor MIB are indexed by two or more values,
so accessing object values becomes a little more complex. For example, the
Event State Table is indexed by stream number and event id, so in order to
reference a specific value, the OID should be created by appending the stream
number and the event id to the OID specified for this object in the MIB.
Consequently, in order to access the EventState for an event on a specific stream,
use the following OID:
‘…mivevtEventState.<interface_no>.<eventid>’.
The GetNextRequest-PDU operation will return the OID of the next eventid,
until they have all been exhausted for that stream. At this point it will return the
next interface_no, and the first event_id on that interface (or ‘No Such Error’ if
no more interfaces exist to indicate that the end of the table has been reached).
DTV Monitors MPEG Transport Stream Monitor Programmer Manual
2−3
DTV Monitor MIB
When a table is defined within the MIB, each table leaf object is represented by
the following OID:
The ‘table_entry_oid’s within the DTV Monitor MIB are always given the value
1, and are not shown on the structure charts within this document because it
would complicate the diagrams. However, it should be recognized that these
must be included in the OIDs when referencing objects.
2−4
DTV Monitors MPEG Transport Stream Monitor Programmer Manual
MIB Group Overview
MIB Group Overview
The following sections define the groups of the MIB modules that make up the
DTV Monitor SNMP interface. There is a split between MPEG-related and
non-MPEG-related objects, and so the groups have been separated into two MIB
modules. The System MIB module contains all non-MPEG-specific groups;
MPEG-specific groups are found in the MPEG MIB module. Figures 3−1 to 3−4
show the overall structure of the DTV Monitor MIB subtree.
Figure 3−1: Overall MIB structure
DTV Monitors MPEG Transport Stream Monitor Programmer Manual
This area has one entry: product. Reading this entry returns the value
“MTM400”. This section of the MIB is used to identify the product name.
The standard mib-2 sysObjectID leaf
(iso(1).org(3).dod(6).internet(1).mgmt(2).mib−2(1).system(1).sysObjectID(2))
returns the OID of this section (1.3.6.1.4.1.128.5.2.16) for identification.
DTV Monitors MPEG Transport Stream Monitor Programmer Manual
3−3
MIB Group Overview
3−4
DTV Monitors MPEG Transport Stream Monitor Programmer Manual
Loading...
+ 108 hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.