Comtech EF Data VMS v3.12.x Vipersat - Manual (Page 503)

Appendix F - Northbound Interface F-5
MN/22156, rev 12 Operational Status Queries
Hub Demodulator Eb/No
One of the main preferences is to correlate the Eb/No for the Hub demodulator
of a switched Remote modulator, which can be obtained by querying the
modem via the proxy for the “unitInbandReturnPathEbN0” variable in the
switching MIB. This variable is designed to look like part of the Remote
modem, when in reality the VMS intercepts the request and fills in the Eb/No of
the currently allocated Hub demodulator. This allows for a very simple way of
monitoring the quality of a dynamic link without the complexity of multiple
queries involving different community strings.
For example, if the Remote data unit is a CDM-840 with an IP address of
172.18.100.1, the operator would use the VMS as a proxy by directing the
SNMP requests to the VMS using a community string such as
“[email protected]”. Along with querying the Remote modem for standard
values like “cdm840TxFrequency” or “cdm840RxLock”, a request for
“unitInbandReturnPathEbN0” can be included to get the Eb/No of the currently
receiving Hub demodulator as well. This variable operates much like one of the
cached modem parameters. To determine the value for this parameter, the VMS
searches for an allocation associated with the specified unit's first modulator. If
the modulator has an associated allocation, it queries the first allocated demodu-
lator (which is always at the Hub) for its last known Eb/No value. If the modula-
tor does not have an associated allocation, the value returned is null.
Tables Support
The current support for tables is limited. It is roughly equivalent to SNMP
version 1. There is support for Get, Get Next, and Walk, but no support for
GETBULK requests. The way to enumerate a table is to send Get Next or Table
View.