ST Engineering iDirect

Dialog R2.5.3

Monitoring API
Description

Revision 1.0
January 20, 2025
© 2025 ST Engineering iDirect (Europe) CY NV and/or its affiliates. All rights reserved.
Reproduction in whole or in part without permission is prohibited. Information contained herein is
subject to change without notice. The specifications and information regarding the products in this
document are subject to change without notice. While every effort has been made to ensure the
accuracy of the statements, information and recommendations in this document, they are provided
without warranty of any kind, express, or implied. Users must take full responsibility for their
application of any products. Trademarks, brand names and products mentioned in this document are
the property of their respective owners. All such references are used strictly in an editorial fashion
with no intent to convey any affiliation with the name or the product's rightful owner.

ST Engineering iDirect is a global leader in satellite communications (satcom) providing

technology and solutions that enable its customers to expand their business, differentiate their
services and optimize their satcom networks. Through the merger with Newtec, a recognized
industry pioneer, the combined business unites over 35 years of innovation focused on solving
satellite’s most critical economic and technology challenges, and expands a shared commitment to
shaping the future of how the world connects. The product portfolio represents the highest
standards in performance, efficiency and reliability, making it possible for its customers to deliver the
best satcom connectivity experience anywhere in the world. ST Engineering iDirect is the world’s
largest TDMA enterprise VSAT manufacturer and is the leader in key industries including broadcast,
mobility and military/government.

Company Website: www.idirect.net | Main Phone: +32 3 780 6500

Support Contact Information: Email: [email protected] | Website:
www.idirect.net/support-and-training
 Table of Contents

Table of Contents

1 About This Guide ............................................................................................ 1

1.1 Revision History ..................................................................................................................................... 1

1.2 Cautions and Symbols ........................................................................................................................... 1

2 What is ST Engineering iDirect Dialog ......................................................... 2

3 DataMiner® ..................................................................................................... 8
3.1 SOAP API .............................................................................................................................................. 8

3.2 SOAP Client ........................................................................................................................................... 8

3.3 How to Make a SOAP Call .................................................................................................................... 8

3.4 Common SOAP Call Identifiers .............................................................................................................. 9

3.4.1 connection ....................................................................................................................................... 9

3.4.2 dmaID ............................................................................................................................................ 10

3.4.3 elementID ....................................................................................................................................... 12

3.4.4 parameterID ................................................................................................................................... 14

3.5 SOAP Call Examples ........................................................................................................................... 15

3.5.1 Get Parameter Value of Forward Link ........................................................................................... 15

3.5.2 Get Parameter Value of Terminal with Standard Monitoring ......................................................... 19

3.5.3 Get Parameter Trend Data ............................................................................................................ 21

3.5.4 Get Value of Multiple Parameters ................................................................................................. 23

3.5.5 Get Value of Parameter in Table ................................................................................................... 26

3.5.6 Get Active Alarms .......................................................................................................................... 31

3.5.7 Set Parameter ................................................................................................................................ 32

4 TSDB .............................................................................................................. 35
4.1 REST API ............................................................................................................................................. 36

4.2 Terminal Metrics ................................................................................................................................... 37

4.2.1 modem.forward.encap ................................................................................................................... 38

4.2.2 modem.forward.S2 ......................................................................................................................... 39

4.2.3 modem.forward.tellinet ................................................................................................................... 39

4.2.4 modem.return.decap ...................................................................................................................... 40

4.2.5 modem.return.hrc_generic ............................................................................................................. 41

4.2.6 modem.return.hrc_shaping ............................................................................................................ 45

4.2.7 modem.return.mrc_generic ............................................................................................................ 46

Monitoring API Description v1 3/95

ST Engineering iDirect Dialog R2.5.3
 Table of Contents

4.2.8 modem.return.mrc_shaping ........................................................................................................... 49

4.2.9 modem.tellinet ............................................................................................................................... 49

4.2.10 modem.tcs ................................................................................................................................... 50

4.2.11 modem.remote.general ................................................................................................................ 51

4.2.12 modem.remote.demod ................................................................................................................. 52

4.2.13 modem.remote.encap .................................................................................................................. 53

4.2.14 modem.remote.tellinet ................................................................................................................. 54

4.2.15 modem.remote.bgp ...................................................................................................................... 54

4.2.16 modem.remote.netquality ............................................................................................................ 55

4.3 Satnet Metrics ...................................................................................................................................... 56

4.3.1 Forward Specific Metrics ............................................................................................................... 56

4.3.1.1 forward.shaper ............................................................................................................................ 56

4.3.1.2 forward.shaper.pools ................................................................................................................... 58

4.3.1.3 forward.shaper.multicast ............................................................................................................. 59

4.3.2 Return Specific Metrics .................................................................................................................. 60

4.3.2.1 return.decapsulator ..................................................................................................................... 61

4.3.2.2 return.decapsulator.return_capacity_group ................................................................................ 61

4.3.3 Return Technology Specific Metrics .............................................................................................. 62

4.3.3.1 return.hrc.transponder ................................................................................................................. 63

4.3.3.2 return.hrc.return_capacity_group ................................................................................................ 63

4.3.3.3 return.hrc.shaping ....................................................................................................................... 64

4.3.3.4 return.hrc.mcd ............................................................................................................................. 66

4.3.3.5 return.mrc .................................................................................................................................... 67

4.3.3.6 return.mrc.return_capacity_group ............................................................................................... 67

4.3.3.7 return.mrc_ulogon ....................................................................................................................... 69

4.3.3.8 return.mrc.shaping ...................................................................................................................... 69

4.3.4 Network Specific Metrics ............................................................................................................... 70

4.3.4.1 l3.vrf ............................................................................................................................................ 70

4.3.4.2 ospf ............................................................................................................................................. 73

4.3.4.3 bgp .............................................................................................................................................. 73

4.3.5 Infrastructure Specific Metrics ....................................................................................................... 75

4.3.5.1 infra.l2.dem ................................................................................................................................. 75

4.3.5.2 infra.l3.dem ................................................................................................................................. 77

4.3.5.3 infra.vrouter_cpu ......................................................................................................................... 78

4.3.5.4 tas ............................................................................................................................................... 79

4.4 Element Metrics ................................................................................................................................... 79

4.5 VerneMQ Metrics ................................................................................................................................. 80

4.6 Annex 1 - List of HRC MODCODs ....................................................................................................... 88

Monitoring API Description v1 4/95

ST Engineering iDirect Dialog R2.5.3
 Table of Contents

4.7 Annex 2 - List of S2(X) MODCODs ...................................................................................................... 89

5 Abbreviations ................................................................................................ 94

Monitoring API Description v1 5/95

ST Engineering iDirect Dialog R2.5.3
 About This Guide

1 About This Guide

The ST Engineering iDIrect Dialog Monitoring API Description provides detailed information about
monitoring the Dialog system using API.
There are three different ways in which metrics and statistics are collected and visualized in Dialog:
• Via DataMiner®
• Via Grafana and TSDB
• Via Kibana and Elasticsearch
Parameters stored in the DataMiner® database can be fetched using SOAP API.
Parameters stored in the TSDB database can be fetched using REST API.

Refer to the Dialog Monitoring User Guide for details about the monitored metrics and
statistics of the Dialog system and how to access these through the NMS GUI.

1.1 Revision History

Version Date Description

1 January, 2025 Initial version for this release.

1.2 Cautions and Symbols

The following symbols appear in this guide:

A caution message indicates a hazardous situation that, if not avoided, may result in
minor or moderate injury. It may also refer to a procedure or practice that, if not
correctly followed, could result in equipment damage or destruction.

A hint message indicates information for the proper operation of your equipment,
including helpful hints, shortcuts or important reminders.

A reference message is used to direct to a location in a document with related

document or a web-link.

Monitoring API Description v1 1/95

ST Engineering iDirect Dialog R2.5.3
 What is ST Engineering iDirect Dialog

2 What is ST Engineering iDirect Dialog

Dialog is a single-service and multi-service VSAT platform that allows operators and service
providers to build and adapt their infrastructure and satellite networking according to business or
missions at hand. Based on the cornerstones of flexibility, scalability and efficiency, the Dialog
platform gives the operator the power to offer a variety of services on a single platform.
Key characteristics are:
• Flexible service offering
• Flexible business models
• Multi-service operation
• Anywhere, anytime service
• Streamlined operations

The Dialog platform fully manages all aspects of a service: bandwidth usage, real-time
requirements, network characteristics and traffic classification. The platform offers these services
with carrier grade reliability through full redundancy of the platform components.
The Dialog platform supports multiple traffic types, such as the following:
• Video and audio
• Data
• Voice
• Data casting

Monitoring API Description v1 2/95

ST Engineering iDirect Dialog R2.5.3
 What is ST Engineering iDirect Dialog

The core of the Dialog platform is the Hub, which is located at a physical gateway site. A Dialog
platform can consist of one or more hubs, located at one or more gateways.
A hub consists of one or more Hub Modules. A hub module contains all hardware and software
required for aggregating and processing traffic of one or more satellite networks.
• The iDirect Hub Infrastructure for large networks provides full flexibility and scalability. It can
serve up to 18 satellite networks. It is the combination of one or two baseband hub modules and
one processing hub module:
– The baseband hub module holds the RF devices. There are two (2) supported baseband
hub module types : DBR1000 and DBR2100.
– The processing hub module holds the processing servers. It is also referred to as
DCR2000. The DCR2000 is deployed on the Common iDirect Deployment Infrastructure or
CIDI.

Equipment redundancy is supported for all devices in the hub module. A hub module may be
implemented fully redundant, non-redundant or partially redundant.
The Terminal is the equipment located at the end-user’s site. It consists of the outdoor unit
(antenna, LNB and BUC) and the indoor unit, i.e. the modem.

Monitoring API Description v1 3/95

ST Engineering iDirect Dialog R2.5.3
 What is ST Engineering iDirect Dialog

Dialog R2.5.3 does not support MDMxx00 modem types.

Monitoring API Description v1 4/95

ST Engineering iDirect Dialog R2.5.3
 What is ST Engineering iDirect Dialog

A hub module is connected to an IP backbone at one side and to an RF interface at the other side,
establishing the Satellite Network.
A satellite network is associated with forward link capacity from one physical or virtual (in case of
DVB-S2X Annex M) forward carrier and with the corresponding return link capacity. The forward link
is based on one of the following technologies:
• DVB-S2
• DVB-S2X
• DVB-S2X Annex M.
The return link supports multiple return link technologies:
• HRC Mx-DMA
• MRC Mx-DMA

Monitoring API Description v1 5/95

ST Engineering iDirect Dialog R2.5.3
 What is ST Engineering iDirect Dialog

Network Resources are configured on top of the physical satellite networks and are isolated from
each other using VLAN identifiers. Dialog provides end-to-end network connectivity for three types
of networks:
• Layer 3
• Layer 2
• Multicast
Layer 3 network resources consist of one or more virtual networks. A layer 3 virtual network is an
isolated IPv4 or IPv6 network. Devices within the same virtual network can directly communicate
with each other. A virtual network can independently use its own addressing scheme and the same
addressing schemes can be reused in different virtual networks.
Layer 2 network resources consist of one or more point-to-point virtual connections. A layer 2
point-to-point virtual connection can be considered as a virtual Ethernet pipe, which establishes
isolated communication between two devices.
A multicast network connects an uplink network on the hub side with one or more LAN networks on
the modem side. This consists of a single multicast routing instance providing unidirectional routing
of multicast IP traffic from the uplink network to the modem LAN networks. The MC network can
therefore be compared to a multicast router.

Monitoring API Description v1 6/95

ST Engineering iDirect Dialog R2.5.3
 What is ST Engineering iDirect Dialog

The Dialog platform is managed through a single Network Management System or NMS. The
NMS can be embedded in a hub module or it can be a standalone hub module, which is deployed on
a Common iDirect Deployment Infrastructure or CIDI.
The NMS provides a unified management interface to monitor, manage and control the Dialog
platform. It serves as a single point of access and embeds the following configuration and
management interfaces:
• Satellite resources
• Network resources
• Service and classification profile management
• Terminal provisioning
• Fault (alarms) and performance (metrics) management

Monitoring API Description v1 7/95

ST Engineering iDirect Dialog R2.5.3
 DataMiner®

3 DataMiner®

3.1 SOAP API

The DataMiner® API is a SOAP API.
An API is an Application Programming Interface. It is a set of rules that allow programs to talk to
each other. The API is created on a server and allows the client to talk to it.
SOAP or Simple Object Access Protocol is a protocol specification for exchanging structured
information in the implementation of Web Services. It uses XML for the message format and is
independent of the transport protocol.
One of the major benefits of SOAP is that you have a WSDL or Web Services Description Language
file. WSDL is an XML based definition language. It is used for describing the functionality of a SOAP
based web service.
Basically SOAP messages are the data you transmit, WSDL tells you what you can do and how to
make the calls.
There are two SOAP web services available on a Dialog system:
• V0: this has limited and basic monitoring functionality.
• V1: this has for more advanced monitoring functionality and provides access to the historical and
trended fault and performance information.
This document only considers the V1 web services, which is installed on each Dialog system by
default.
The V1 web service supports SOAP v1.1 as well as SOAP v1.2. Both SOAP Version 1.1 and 1.2 are
World Wide Web Consortium (W3C) standards.

3.2 SOAP Client

It is advised to use the SOAPUI client application to communicate with the SOAP API on the Dialog
hub.

3.3 How to Make a SOAP Call

The URLs in this guide use HTTP. If you want to use HTTPS, simply replace HTTP by
HTTPS in the URLs.

To get fault and performance information via a SOAP call, execute the following steps:
1. Open your SOAP client. For example, SoapUI.
2. Load the WSDL file.

Monitoring API Description v1 8/95

ST Engineering iDirect Dialog R2.5.3
 DataMiner®

– If you have connectivity to a Dialog system, enter the following URL:

http://<CMS_VIP>/API/v1/soap.asmx?WSDL
3. Get the connection string for the host using the given login and password. The host is your
Dialog NMS. Refer to connection on page 9 for more details.
4. Make your SOAP call. Each call requires the connection string as input.
If you have connectivity to a Dialog system, you can consult all available calls via
http://<CMS_VIP>/API/v1/soap.asmx
5. Use the Logout call to log out.

CMS_VIP is the virtual IP address of your NMS system. This IP address is set during
the installation of your hub module. Refer to the corresponding Dialog Hub Installation
Guide for more information.

3.4 Common SOAP Call Identifiers

A SOAP call requires one or more identifiers as input. The following paragraphs explain how to
retrieve the value of each identifier.

3.4.1 connection
Each SOAP call, except ConnectApp, requires a string that identifies the connection with the host.
Use the ConnectApp call to request a connection string.
The call requires the following input:
• host is the IP address of the Dialog NMS, or local host if you have installed the WSDL file locally
on your PC.
• login & password are the user credentials. They are required in order to retrieve a valid string.
These are used to provide domain-based security (VNO limited access based on views).
• clientAppName can have any value, but can not be empty.
• clientAppVersion & clientComputerName can be empty (future use).
An example request is shown below. The values for host, login and password have been blurred.

Monitoring API Description v1 9/95

ST Engineering iDirect Dialog R2.5.3
 DataMiner®

An example response with the connection string is shown below.

Use this string in all fault and performance SOAP API calls.

If the connection is not used for five minutes, the session will end. You will then need to
rerun the Connect App call again to request a new connection string.

3.4.2 dmaID
The DMA ID is linked with the DMA license of your Dialog NMS. The ID remains the same
throughout the lifecycle of the hub module.
Use the GetDataMinerAgentsInfo call to retrieve the DMA ID. The call requires the connection
string as input.
An example request is shown below.

Monitoring API Description v1 10/95

ST Engineering iDirect Dialog R2.5.3
 DataMiner®

An example response is shown below.

Alternatively, right-click on any element within the Dialog NMS surveyor tree and select Properties.
A pop-up window appears displaying the DMA ID at the left of the forward slash.

Monitoring API Description v1 11/95

ST Engineering iDirect Dialog R2.5.3
 DataMiner®

3.4.3 elementID
The element ID is created during the provisioning of resources on the Dialog system.
Use the GetElementsForView call to get an overview of all elements that exist within the specified
view. If you apply this call for the root view (which has -1 as view ID), you get all elements that exist
within the complete surveyor tree.
The call parameters includeSubViews and includeServices should be set to 'true' or 'false'.
An example request for the root view is shown below.

Monitoring API Description v1 12/95

ST Engineering iDirect Dialog R2.5.3
 DataMiner®

An example response for the root view is shown below.

Alternatively, right-click on the element within the Dialog NMS surveyor tree and select Properties.
A pop-up window appears displaying the Element ID at the right of the forward slash.

Monitoring API Description v1 13/95

ST Engineering iDirect Dialog R2.5.3
 DataMiner®

3.4.4 parameterID
Each element has a number of parameters that can be monitored. The parameter identifiers remain
the same within a Dialog software release.
Consult the Dataminer Driver Details file in the customer documentation portal to know which
parameters can be retrieved per driver and to know their corresponding parameter ID.
Alternatively, click on an element within the surveyor tree and double-click on a parameter. Then
click the DETAILS tab.
The example below displays the ID for the Forward Es/N0 parameter of a terminal element.

Monitoring API Description v1 14/95

ST Engineering iDirect Dialog R2.5.3
 DataMiner®

3.5 SOAP Call Examples

This chapter describes typical examples of SOAP API v1 calls. Some examples combine multiple
SOAP methods.

3.5.1 Get Parameter Value of Forward Link

Get the Forward Link Occupation of the forward link used for satellite network 1.
Execute the following steps:
1. Open the GetParameter request.
2. Enter the connection string. Remember that the connection times out after five minutes. Refer
to connection on page 9.
3. Enter the DMA ID. The ID of the DMA license of the Dialog NMS that we use for the example is
28741. Refer to dmaID on page 10.
4. Enter the ID of the forward link element. The ID is 4115. Refer to elementID on page 12.
5. Enter the ID of the Forward Link Occupation parameter. The ID is 280. Refer to parameterID on
page 14.
6. Run the request.

Monitoring API Description v1 15/95

ST Engineering iDirect Dialog R2.5.3
 DataMiner®

When retrieving a parameter for a terminal with Advanced Monitoring, the tableIndex
field in the request must be empty (no "?").

7. Look for the parameter value in the response.

Monitoring API Description v1 16/95

ST Engineering iDirect Dialog R2.5.3
 DataMiner®

Alternatively, use the GetParameterByName call. Execute the following steps:

1. Open the GetParameterByName request.
2. Enter the connection string. Remember that the connection times out after five minutes. Refer
to connection on page 9.
3. Enter the name of the forward link element. The name is
'dia4-satnet-1.FWL.dia4-sn1-forward-link'. Refer to elementID on page 12.

Monitoring API Description v1 17/95

ST Engineering iDirect Dialog R2.5.3
 DataMiner®

4. Enter the name of the Forward Link Occupation parameter. The name is 'Forward Link
Occupation'. Refer to parameterID on page 14.
5. Run the request.

When retrieving a parameter for a terminal with Advanced Monitoring, the tableIndex
field in the request must be empty (no "?").

6. Look for the parameter value in the response.

Monitoring API Description v1 18/95

ST Engineering iDirect Dialog R2.5.3
 DataMiner®

3.5.2 Get Parameter Value of Terminal with Standard Monitoring

A terminal using standard monitoring is not represented as a separate element in the surveyor tree
of Dialog NMS. The parameters of all standard terminals are available through the Standard
Terminal Manager element. However, this element cannot be polled via the SOAP API. All
parameters for terminals using standard monitoring are collected by the Performance element within
the hub module, meaning that you have to poll the table from the Performance element.

Monitoring API Description v1 19/95

ST Engineering iDirect Dialog R2.5.3
 DataMiner®

Get the Total Forward Throughput parameter of a terminal using standard monitoring.
Execute the following steps:
1. Open the GetParameter request.
2. Enter the connection string. Remember that the connection times out after five minutes. Refer
to connection on page 9.
3. Enter the DMA ID. The ID of the DMA license of the Dialog NMS that we use for the example is
28741. Refer to dmaID on page 10.
4. Enter the ID of the performance element. The ID is 4042. Refer to elementID on page 12.
5. Enter the ID of the Total Forward Throughput parameter. The ID is 2060. Refer to parameterID
on page 14.
6. Enter the table index. This is the identifier of the terminal within the table. This can be retrieved
from the NMS GUI. This ID in the example is 58435.

7. Run the request.

Monitoring API Description v1 20/95

ST Engineering iDirect Dialog R2.5.3
 DataMiner®

8. Look for the parameter value in the response.

3.5.3 Get Parameter Trend Data

Trend graphs make it possible to view and compare trend data logged by DataMiner. For
performance reasons, trending is only activated for a limited number of parameters. Trending
templates determine which parameters are trended.

Only Dialog NMS administrators can create or edit trending templates.

Parameters for which trending graphs are available are indicated with the trend graph icon .
Retrieve the trend data of the Forward Es/N0 of a terminal of a terminal with advanced monitoring
enabled.
Execute the following steps:
1. Open the GetTrendDataForParameter or GetTrendDataSimplifiedForParameter request.
2. Enter the connection string. Remember that the connection times out after five minutes. Refer
to connection on page 9.
3. Enter the DMA ID. The ID of the DMA license of the Dialog NMS that we use for the example is
28741. Refer to dmaID on page 10.

Monitoring API Description v1 21/95

ST Engineering iDirect Dialog R2.5.3
 DataMiner®

4. Enter the ID of the terminal element. The ID of the terminal element in the example is 7301.
Refer to elementID on page 12.
5. Enter the ID of the Forward Es/N0 parameter. The ID is 1004. Refer to parameterID on page
14.
6. Set the trendingSpanTime to 'LastHour', 'LastDay', 'LastWeek', 'LastMonth', or 'LastYear'.
7. Run the request.

When retrieving a parameter for a terminal with Advanced Monitoring, the tableIndex
field in the request must be empty (no "?").

8. Look for the parameter values in the response.

Monitoring API Description v1 22/95

ST Engineering iDirect Dialog R2.5.3
 DataMiner®

3.5.4 Get Value of Multiple Parameters

Get the Forward Link Max Symbol Rate, Forward Link Occupation and Send Symbol Rate of
the forward link used for satellite network 1, using one SOAP call.
Execute the following steps:
1. Open the GetParameters request.
2. Enter the connection string. Remember that the connection times out after five minutes. Refer
to connection on page 9.

Monitoring API Description v1 23/95

ST Engineering iDirect Dialog R2.5.3
 DataMiner®

3. Enter the DMA ID. The ID of the DMA license of the Dialog NMS that we use for the example is
28741. Refer to dmaID on page 10.
4. Enter the ID of the forward link element. The ID is 4115. Refer to elementID on page 12.
5. Enter the ID of the Forward Link Max Symbol Rate, Forward Link Occupation and Send Symbol
Rate parameters. The IDs are 10, 280, and 281. Refer to parameterID on page 14.
6. Run the request.

7. Look for the parameter values in the response.

Monitoring API Description v1 24/95

ST Engineering iDirect Dialog R2.5.3
 DataMiner®

Monitoring API Description v1 25/95

ST Engineering iDirect Dialog R2.5.3
 DataMiner®

3.5.5 Get Value of Parameter in Table

Get the PIR value for the BE Forward QoS Class of a terminal with advanced monitoring enabled.
The parameter is part of a table as shown in the NMS UI below.

Execute the following steps:

1. Get an overview of all available parameters on a specific DATA display for the terminal.
1. Open the GetParametersByPageForElement request.
2. Enter the connection string. Remember that the connection times out after five minutes.
Refer to connection on page 9.
3. Enter the DMA ID. The ID of the DMA license of the Dialog NMS that we use for the
example is 28741. Refer to dmaID on page 10.
4. Enter the ID of the terminal element. The ID of the terminal element in the example is
7295. Refer to elementID on page 12.
5. Enter the name of the element page. The page name in this example is 'Bidirectional
Unicast Circuit'.
6. Run the request.

Monitoring API Description v1 26/95

ST Engineering iDirect Dialog R2.5.3
 DataMiner®

7. Look for the identifier of the FWD QoS table in the response. This is the PrimaryKeyID.

8.
2. Get the identifier of the FWD QoS PIR parameter for the BE QoS class, using the ID of the
FWD QoS table you found via the previous call.
1. Open the GetTableForParameter request.
2. Enter the connection string. Remember that the connection times out after five minutes.
Refer to connection on page 9.

Monitoring API Description v1 27/95

ST Engineering iDirect Dialog R2.5.3
 DataMiner®

3. Enter the DMA ID. The ID of the DMA license of the Dialog NMS that we use for the
example is 28741. Refer to dmaID on page 10.
4. Enter the ID of the terminal element. The ID of the terminal element in the example is
7295. Refer to elementID on page 12.
5. Set the parameter ID to 1101.
6. Run the request.

7. Look for BE FWD QoS Class and then look for the PIR ID in the response.

Monitoring API Description v1 28/95

ST Engineering iDirect Dialog R2.5.3
 DataMiner®

3. Get the value of the FWD QoS BE PIR parameter.

1. Open the GetParameter request.
2. Enter the connection string. Remember that the connection times out after five minutes.
Refer to connection on page 9.
3. Enter the DMA ID. The ID of the DMA license of the Dialog NMS that we use for the
example is 28741. Refer to dmaID on page 10.
4. Enter the ID of the terminal element. The ID of the terminal element in the example is
7295. Refer to elementID on page 12.

Monitoring API Description v1 29/95

ST Engineering iDirect Dialog R2.5.3
 DataMiner®

5. Set the parameter ID to 1105.

6. Set the table index to 'BE'.
7. Run the request.

8. Look for the parameter value in the response.

Monitoring API Description v1 30/95

ST Engineering iDirect Dialog R2.5.3
 DataMiner®

3.5.6 Get Active Alarms

Get an overview of the currently active alarms. Execute the following steps:
1. Open the GetActiveAlarms request.
2. Enter the connection string. Remember that the connection times out after five minutes. Refer
to connection on page 9.
3. Run the request.

Monitoring API Description v1 31/95

ST Engineering iDirect Dialog R2.5.3
 DataMiner®

4. All active alarmsare displayed in the response.

3.5.7 Set Parameter

Set the chain redundancy of the second satellite network to chain B.

Monitoring API Description v1 32/95

ST Engineering iDirect Dialog R2.5.3
 DataMiner®

Execute the following steps:

1. Open the SetParameter request.
2. Enter the connection string. Remember that the connection times out after five minutes. Refer
to connection on page 9.
3. Enter the DMA ID. The ID of the DMA license of the Dialog NMS that we use for the example is
28741. Refer to dmaID on page 10.
4. Enter the ID of the REDCTL element. The ID is 4050. Refer to elementID on page 12.
5. Enter the ID of the Chain Redundancy Selection parameter. The ID is 3002. Refer to
parameterID on page 14.
6. Set the table index to 2. This corresponds with the chain of the second satellite network.
7. Set the value of the parameter to 'Select B'. Other possible values are 'Select A' and 'Automatic'.
8. Run the request.

9. If the parameter is successfully set, the response shows no errors.

Monitoring API Description v1 33/95

ST Engineering iDirect Dialog R2.5.3
 DataMiner®

10. Check the change in the DMA GUI.

Monitoring API Description v1 34/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

4 TSDB
The Dialog monitoring system collects metrics from the Dialog platform and stores them in a Time
Series Database (TSDB, i.e. InfluxDB).

where x = enclosure ID / HPS pool

• 0 for 1IF, 4IF and NMS
• 0, 1 or 2 for XIF
The metrics are gathered from various virtual machines. Python collection scripts, which run on the
virtual machines, fetch the data at a configured interval and dispatch it to a locally deployed
"Telegraf" daemon. The daemon flushes the metrics to the InfluxDB instance, which runs on a
dedicated MON virtual machine. MON is deployed on both the HMMS and NMS in an active standby
constellation.
Following metrics exist:
• Satnet metrics, such as forward shaper received bytes, number of provisioned terminals in the
HRC return capacity group, etc. These metrics are always collected.
• Terminal metrics, such as HRC requested volume, software version, etc. The collection of these
metrics is by default disabled.
To enable the collection:
– Set the ntc_rtmc_device_manager::terminal_real_time_monitoring parameter in the
customerconfig.yaml file to:

Monitoring API Description v1 35/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

• ADVANCED: only terminals for which the Monitoring Type is set to Advanced are
monitored.
• ALL: all terminals are monitored.
To disable the collection:
– Set the ntc_rtmc_device_manager::terminal_real_time_monitoring parameter in the
customerconfig.yaml file to NONE.
• Element metrics from each virtual Machine, such as CPU, memory, disk usage, etc. These
metrics are automatically collected every 10 seconds.
• Metrics from the internal MQTT broker (VerneMQ), such as ack message counters. These metrics
are automatically collected every 10 seconds.
The polling interval (~ granularity) for the satnet and terminal metrics is 10 seconds by default. To
change the polling interval:
• Set the value of the ntc_profile_metrics::node::extmon_collector::interval parameter in the
customerconfig.yaml file.

The setting of the polling interval depends on the configuration of the hub module in
terms of number of terminals and satellite networks. The polling interval should not
be set lower than 10 seconds.

To optimize performance it is recommended to set the Time Slice parameter in all

Advanced Terminal Main elements of the DMA to twice the polling interval.
For example, for a small deployment one can set the polling interval to 10 seconds
in the customerconfig.yaml file. In that case the Time Slice parameter in all
Advanced Terminal Main elements of the DMA should be set to '20s'.

The default retention time for all collected metrics is three weeks. To change this period:
• Set the value of the ntc_profile_metrics::server::influx_retention_telegraf parameter in the
customerconfig.yaml file.

In case the polling interval is set to 10 seconds, the retention time should not be set
higher than 10 days.

For more information on how to edit and apply the customerconfig.yaml file, refer to the
corresponding Dialog Hub Installation Guide.

The metrics can be retrieved from the system via REST API. A subset can also be viewed via a
web interface on the Dialog NMS (the Grafana graphs).

4.1 REST API

The TSDB API is a REST API.
An API is an Application Programming Interface. It is a set of rules that allow programs to talk to
each other. The API is created on a server and allows the client to talk to it.
REST or Representational State Transfer determines how the API looks like. It is a set of rules that
developers follow when they create their API. One of these rules states that you should be able to

Monitoring API Description v1 36/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

get a piece of data (called a resource) when you link to a specific URL. Each URL is called a request
while the data sent back to you is called a response.
The API is available on every HMGW (per enclosure of a hub module) and CMS (on the enclosure of
the NMS module) via port 8086. The name of the database where the metrics are stored is
'telegraf'.

Make sure your device connecting to the TSDB is known as a trusted host. Trusted hosts are
configured in the customerconfig.yaml file.

A metric is defined by a measurement, a timestamp, a field and tags. For more information on these
concepts, refer to InfluxDB Key Concepts.
To view all measurements in the TSDB, execute following command:

http://[hmgw-ip]:8086/query?pretty=true&db=telegraf&q=SHOW measurements

To view the field and tag keys of a measurement, execute following commands:

http://[hmgw-ip]:8086/query?pretty=true&db=telegraf&q=SHOW field keys FROM

"<measurement_name>"
http://[hmgw-ip]:8086/query?pretty=true&db=telegraf&q=SHOW tag keys FROM
"<measurement_name>"

For more information on how to explore the TSDB layout, refer to InfluxDB Schema Exploration.
To retrieve a metric, you can execute following command (just an example):

http://[hmgw-ip]:8086/query?pretty=true&db=telegraf&q=SELECT "<field_key>" FROM

"<measurement_name>" WHERE "<tag_key>"='x' and time>now()-10m

Only use tags to filter (WHERE clause) on queries.

Unlike fields, tags are indexed. This means that queries on tags are faster and less
stressful for the TSDB than queries on fields.
For more information, refer to Why indexing matters.

For more information on the query syntax, refer to InfluxDB Data Exploration.

4.2 Terminal Metrics

The terminal metrics are grouped in following measurements:
• modem.forward.encap
• modem.forward.S2
• modem.forward.tellinet
• modem.return.decap
• modem.return.hrc_generic
• modem.return.hrc_shaping
• modem.return.mrc_generic
• modem.return.mrc_shaping

Monitoring API Description v1 37/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

• modem.tellinet
• modem.tcs
• modem.remote.general
• modem.remote.demod
• modem.remote.encap
• modem.remote.tellinet
• modem.remote.bgp
• modem.remote.netquality

4.2.1 modem.forward.encap
The measurements are done at CSE level.

Tag key Description

modem_id ID of the modem. This ID can be retrieved via REST API: GET
/modem and search for id > systemId.

qos_class_id Identifier of the Quality of Service class:

• BE
• CD1..14
• RT1..3

hps ID of the hub processing segment. This ID can be retrieved via the
REST API: GET /hub-module and search for hpsId.

host PGICSE-x

Field key Description Units

received_bytes Total number of bytes that the CSE (shaper) bytes

receives for a modem and specific QoS class,
including eTCP overhead.

received_packets Total number of packets that the CSE (shaper) packets

receives for a modem and specific QoS class,
including eTCP overhead.

Monitoring API Description v1 38/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

sent_bytes Total number of bytes that the CSE (shaper) bytes

transmits for a modem and specific QoS class,
including eTCP overhead.

sent_packets Total number of packets that the CSE (shaper) packets

transmits for a modem and specific QoS class,
including eTCP overhead.

dropped_bytes Total number of bytes that the CSE (shaper) drops bytes
for a modem and specific QoS class, including eTCP
overhead.

dropped_packets Total number of packets that the CSE (shaper) drops packets
for a modem and specific QoS class, including eTCP
overhead.

avg_delay Average time that packets are queued in the CSE for milliseconds
a modem and specific QoS class,

4.2.2 modem.forward.S2
The measurements are done at terminal level and reported to the hub in the ACM signaling.

Tag key Description

modem_id ID of the modem. This ID can be retrieved via REST API: GET
/modem and search for id > systemId.

hps ID of the hub processing segment. This ID can be retrieved via the
REST API: GET /hub-module and search for hpsId.

host PGICSE-x

Field key Description Units

modcod MODCOD and frame size that the S2 forward

carrier is using.
For example: QPSK 1/2 normal

signalled_cni Carrier to Noise interference which equals to the dB

Es/N0 value.

sent_symbols Number of sent symbols by a modem in the S2

forward link.

4.2.3 modem.forward.tellinet
The measurements are done at TAS level.

Monitoring API Description v1 39/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

Tag key Description

modem_id ID of the modem. This ID can be retrieved via REST API: GET
/modem and search for id > systemId.

qos_class_id Identifier of the Quality of Service class:

• BE
• CD1..14
• RT1..3

hps ID of the hub processing segment. This ID can be retrieved via the
REST API: GET /hub-module and search for hpsId.

host PGITAS-x

forward_pool_id ID of the forward pool. This ID can be retrieved via REST APII: GET
/forward-link and search for forwardLinkIds > systemId.

Field key Description Units

dropped_bytes Total number of bytes dropped at the TAS bytes

(TelliNet) for a modem and specific QoS class,
including eTCP overhead.

dropped_packets Total number of packets dropped at the TAS packets

(TelliNet) for a modem and specific QoS class,
including eTCP overhead.

4.2.4 modem.return.decap
The measurements are done at DCP level.

Monitoring API Description v1 40/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

Tag key Description

modem_id ID of the modem. This ID can be retrieved via REST API: GET
/modem and search for id > systemId.

qos_class_id Identifier of the Quality of Service class:

• BE
• CD1..14
• RT1..3

hps ID of the hub processing segment. This ID can be retrieved via the
REST API: GET /hub-module and search for hpsId.

host PGIDCP-x

Field key Description Units

received_bytes Total number of bytes received at the DCP for the bytes
modem and a specific QoS class, including eTCP
overhead.

received_packets Total number of packets received at the DCP for packets

the modem and a specific QoS class, including
eTCP overhead.

multicast_received_bytes Total number of bytes received at the DCP of a bytes

specific multicast stream from the modem, including
GSE overhead.

multicast_received_packets Total number of packets received at the DCP for a packets

specific multicast stream from the modem, including
GSE overhead.

multicast_id ID of the multicast stream. This ID can be retrieved

via the REST API: GET /multicast-circuit and
search for id > systemId.

4.2.5 modem.return.hrc_generic
The measurements are done at HRCCTL level.

Tag key Description

modem_id ID of the modem. This ID can be retrieved via REST API: GET
/modem and search for id > systemId.

return_capacity_group_id ID of the return capacity group. This ID can be retrieved via the
. REST API: GET
• /hrc-mxdma-return-capacity-group
and search for id > systemId.

Monitoring API Description v1 41/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

type • mxdma
• scpc

hps ID of the hub processing segment. This ID can be retrieved via the
REST API: GET /hub-module and search for hpsId.

host PGIHRCCTL-x

Terminal Related Field Keys

Field key Description Units

state Current state of the modem:

• 0 (unknown)
• 1 (idle)
• 2 (waiting)
• 3 (logging on)
• 4 (acquiring)
• 5 (syncing)
• 6 (logged on)
• 7 (scheduling)
• 8 (log on failed)
• 9 (stopping)
• 10 (waiting ulogon)

chip_rate Current chip rate that the modem is using. chips/s

ModCod ID of the MODCOD that the modem is using in the

return link. See Annex 1 - List of HRC MODCODs
on page 88 to translate the ID to the actual
MODCOD.
The value is null if not available (e.g. during logon).

spread_factor Current spreading factor used by the modem.

assigned_mcd_role Defines the demodulator of the return traffic from

the modem.

Traffic Related Field Keys

Field key Description Units

allocated_bit_rate Bit rate allocated to the terminal. The rate includes bits/sec
encapsulation overhead. This value is averaged
over the measurement interval.

Monitoring API Description v1 42/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

bbp_occupation Indicates how many of the baseband packets are %

used. The value equals real data/total allocated bit
rate ratio.

bbp_count Total number of HRC baseband packets received. packets

bbp_error_count Total number of HRC baseband packets received packets

with an error.

errored_seconds_count Total number of measured errored seconds. An seconds

errored second is a second when a provisioned
terminal has no valid service without packet loss.

Link Quality Related Field Keys

Field key Description Units

ESN0 Energy per symbol (Es) to noise power spectral dB

density (N0) ratio of the return link of the terminal
measured at the HRC demodulator and signaled to
the HRC controller (HRCCTL). It is an indication of
the return link quality.

C0D Measured terminal carrier to distortion ratio. dB

C0ND Measured terminal carrier to noise + distortion ratio. dB

link_margin Difference between the measured EsN0 and the dB

required EsN0 to support the current MODCOD.

ACM_margin Difference with the link margin is that this value is dB

used by the internal algorithms.

phase_noise Measured terminal phase noise. dB

The measurement is according to the IESS-308
standard.

noDeviation Deviation of the noise of this terminal relative to its dB

associated demodulator average noise level (that is
compared to other terminals serviced by this MCD).
A significantly positive value indicates some kind of
interference or unexpected terminal signal quality
loss (e.g. BUC phase noise). When this value
surpasses 3 dB, the HRC controller raises the
alarm "HRC possible interference presence".

Frequency Related Field Keys

Field key Description Units

frequency Return frequency used by the modem. Hz

frequency_offset Measured offset from return frequency used. Hz

Monitoring API Description v1 43/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

BUC_frequency_offset Measured frequency offset from BUC. This value Hz

should be very small when the modem and BUC
are slaved to the same reference clock.

insufficient_carrier_guard_band Indicates whether the provisioned guard band for

the terminal is sufficient or not:
• true: the guard band is not large enough and
the carrier overlaps with the boundaries of the
HRC capacity group or with the guard band of
another terminal;
• false: the guard band is large enough.

Power Level Related Field Keys

Field key Description Units

rx_power Received power level measured at the hub. dBm

rx_power_density Received power level density measured at the hub. dBm/Hz

tx_power Power level transmitted by the terminal. This power dBm

level is signaled to the terminal.

tx_power_density Power level density transmitted by the terminal. dBm/Hz

This is signaled to the terminal.

regrowth_limited_power Indicates whether the modem transmit power level

is limited by regrowth. As a consequence the HRC
controller will request less power.
Values are:
• 0 (not applicable)
• 1 (true)
• 2 (false)
• 3 (indeterminate)

actual_BEPD Actual measured and calculated Bandwidth dBm/Hz

Equivalent Power Density for the terminal.
This represent the power level density, which is
received by the satellite transponder.

uplink_fade Terminal's estimated allowed uplink fade dB

compensation. This value will be lower than or
equal to the AUPC range.

Logon Related Field Keys

Field key Description Units

out_of_lock_count Total number of times that the terminal lost lock.

Monitoring API Description v1 44/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

logon_time Time it takes for the terminal to logon. seconds

logon_search_range During logon a terminal will scan a specific Hz

frequency range to compensate a possible
terminal TX frequency offset.
This value indicates the search range of the
previous log on attempt. This is independent
whether the previous logon attempt was
successful or not.

logging_on_carrier_guard Total number of times the measured carrier

_band_too_high_count offset was higher than the reserved guard band
during the terminal logon phase.

received_ulogon_msg_count Total number of ulogon messages received by

the HRC controller from the terminal.

requested_ulogon_count Total number of ulogon requests sent by the

HRC controller to the terminal.

4.2.6 modem.return.hrc_shaping
The measurements are done at HRCCTL level.

Tag key Description

modem_id ID of the modem. This ID can be retrieved via REST API: GET
/modem and search for id > systemId.

return_capacity_group_id ID of the return capacity group. This ID can be retrieved via the
REST API: GET
• /hrc-mxdma-return-capacity-group
and search for id > systemId.

qos_class_id Identifier of the Quality of Service class:

• BE
• CD1..14
• RT1..3
• MGMT
• RTSIGN
• circuit (in case of a transport-based shaping model or SCPC)

type • mxdma
• scpc

hps ID of the hub processing segment. This ID can be retrieved via the
REST API: GET /hub-module and search for hpsId.

Monitoring API Description v1 45/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

host PGIHRCCTL-x

Field key Description Units

requested_volume Bit rate that the modem requests for a specific QoS bits/sec
class or circuit. The rate includes encapsulation
overhead.

assigned_volume Bit rate allocated to the modem for a specific QoS bits/sec
class or circuit. The rate includes encapsulation
overhead.

4.2.7 modem.return.mrc_generic
The measurements are done at MRCCTL level.

Tag key Description

modem_id ID of the modem. This ID can be retrieved via REST API: GET
/modem and search for id > systemId.

hps ID of the hub processing segment. This ID can be retrieved via the
REST API: GET /hub-module and search for hpsId.

host PGIMRCCTL-x

Terminal Related Field Keys

Field key Description Units

state Indicates the current state of the modem:

• false (logged off)
• true (logged on)

symbol_rate Current symbol rate assigned for the modem. baud

mod_cod MODCOD that the modem is using in the return.

For example, 32APSK 9/10.
The value is null if not available (e.g. during logon).

frequency_offset Frequency off-set respect to the requested Hz

frequency value.

frequency_correction Correction applied to the Tx frequency of the Hz

terminal.

time_offset Measured time offset respect to the requested time us

value.

Acm_Margin_Total_Curr Current total ACM margin for the terminal. dB

ent

Monitoring API Description v1 46/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

Allowed_Fade_Compens Allowed uplink fade compensation in the terminal. dB

ation

Bbp_Occupation Baseband packet occupation

Bepd_Actual Actual Bandwidth Equivalent Power Density. dBm/Hz

Bepd_ClearSky Tracked clear sky BEPD power density limit at dBm/Hz

MCD where terminal traffic bursts are landing.

HpaModel_TxPower_Sat Current estimated transmission power at HPA dBm

saturation.

HpaModel_TxPower_Sat Current safety margin applied with respect to the dBm

_Margin transmission power saturation.

Path_Gain_ClearSky Tracked clear sky path gain for the terminal. dB

Path_Gain_Current Tracked current path gain for the terminal. dB

Regrowth_Limited Indicates whether the terminal TX power level has

been limited because of available BUC power.
Possible values: yes, no, indeterminate, not
applicable.

System_Noise_Density_ Tracked system noise density at the MCD where dBm/Hz

Current terminal traffic bursts are landing

RMS_phase_noise Root mean square of the measured phase noise degrees

expressed in degrees

Offset_to_phase_noise_ Offset to the default phase noise mask (-70dBc/Hz dB

mask at 1kHz) in dB.

For more information on transmit

modes and phase noise masks, please
refer to the Dialog Functional
Description.

Cycle_slip_bursts The cycle slip counter counts the number of times #

a high phase offset was measured in the phase
tracking loop.

Traffic Related Field Keys

Field key Description Units

allocated_bitrate Bit rate that is assigned to the terminal. The rate bits/sec
includes GSE overhead.

requested_bitrate Bit rate that the terminal requests. The rate includes bits/sec
encapsulation overhead.

Monitoring API Description v1 47/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

frame_error_ratio Indicates how many of the received frames have %

errors.

Codeword_error_ratio Ratio of undecodable FEC words to the total %

amount of received FEC words

Errored_Second_Event Number of measured errored seconds. An errored

second is a second when a provisioned terminal
has no valid service without packet loss.

Total_ACM_Margin Difference with the linnk margin is that this value is

used by the internal algorithms.

Power Related Field Keys

Field key Description Units

tx_power Power level transmitted by the terminal. This dBm

power level is signaled to the terminal.

tx_power_density Power level density transmitted by the dBm/Hz

terminal. This is signaled to the terminal.

rx_power_level Received power level measured at the MRC dBm

demodulator.

rx_power_level_density Received power level density measured at the dBm/Hz

MRC demodulator.

Link Quality Related Field Keys

Field key Description Units

EsN0 Energy per symbol (Es) to noise power spectral dB

density (N0) ratio of the return link of the terminal
measured at the MRC demodulator and signaled to
the MRC controller (MRCCTL). It is an indication of
the return link quality.

CN0 Carrier power level (C) to receiver noise density dB/Hz

(N0) ratio measured at the MRC demodulator and
signaled to the MRC controller (MRCCTL). It is an
indication of the return link quality.

CoD Carrier to distortion ratio of the terminal measured dB

at the MRC demodulator.

CoND Carrier to noise + distortion ratio of the terminal dB

measured at the MRC demodulator.

physical_layer_efficiency Efficiency of the physical layer: the number of bits bits/Hz

which are used per Hz

Monitoring API Description v1 48/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

4.2.8 modem.return.mrc_shaping
The measurements are done at MRCCTL level.

Tag key Description

modem_id ID of the modem. This ID can be retrieved via REST API: GET
/modem and search for id > systemId.

qos_class_id Identifier of the Quality of Service class:

• BE
• CD1..14
• RT1..3
• MGMT
• RTSIGN

hps ID of the hub processing segment. This ID can be retrieved via the
REST API: GET /hub-module and search for hpsId.

host PGIMRCCTL-x

Field key Description Units

requested_bitrate Average bit rate requested by the terminal for a bits/sec

specific QoS class or circuit, including GSE
overhead.

assigned_bitrate Average bit rate assigned to the terminal by the bits/sec

MRC controller for a specific QoS class or circuit,
including GSE overhead.

cir_congestion Indicates if there is CIR congestion or not:

• true: CIR congestion occurs; in this case a child
connected to the pool did not receive its
guaranteed CIR. This is an indication of serious
congestion.
• false: no CIR congestion occurs.

4.2.9 modem.tellinet
The measurements are done at TAS level.

Tag key Description

modem_id ID of the modem. This ID can be retrieved via REST API: GET
/modem and search for id > systemId.

Monitoring API Description v1 49/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

qos_class_id Identifier of the Quality of Service class:

• BE
• CD1..14
• RT1..3

hps ID of the hub processing segment. This ID can be retrieved via the
REST API: GET /hub-module and search for hpsId.

host PGITAS-x

forward_pool_id ID of the forward pool. This ID can be retrieved via REST APII: GET
/forward-link and search for forwardLinkIds > systemId.

Field key Description Units

acc_tcp_con Number of accelerated TCP connections for a bytes

modem and specific QoS class.

4.2.10 modem.tcs
The measurements are done at TCS level.

Tag key Description

modem_id ID of the modem. This ID can be retrieved via REST API: GET
/modem and search for id > systemId.

hps ID of the hub processing segment. This ID can be retrieved via the
REST API: GET /hub-module and search for hpsId.

host TCS-x-y

Field key Description Units

network_config_version Version number of the terminal configuration. This

number is updated when the terminal
configuration is changed.

sw_version Current software version installed on the modem.

time_last_network_config Date and time of the last time the terminal seconds
requested the terminal configuration, which is since epoch
managed by the hub.

satellite_configuration_ver Version number of the current terminal satellite

sion configuration.

required_satellite_configur Version number of the remote satellite

ation_version configuration that the terminal should apply.

Monitoring API Description v1 50/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

terminal_name Terminal name as configured by the operator.

Use this parameter to convert the modem id into
the terminal name.

candidate_satellite_configu Version number of the candidate terminal satellite

ration_version configuration.

available_network_config_ Latest version number of the terminal config

version available on the TCS

last_downloadded_satellite Date an time when the terminal downloaded the

_configuration_time last satellite configuration. The satellite
configuration is managed by the hub.

4.2.11 modem.remote.general
The measurements are done at terminal level.

Tag key Description

modem_id ID of the modem. This ID can be retrieved via REST API: GET
/modem and search for id > systemId.

hps ID of the hub processing segment. This ID can be retrieved via the
REST API: GET /hub-module and search for hpsId.

host TCS-x-y

Field key Description Units

uptime Indicates how long the terminal has been seconds

operational.

temperature Temperature measured at the terminal. °C

cpu CPU usage of the terminal. This is the average %

value of the CPU usage of the cores.

core.0 CPU usage of core 0.

core.1 CPU usage of core 1.

tcs_config_mismatches Number of times the modem received a config with

a different version than the requested one

temp_state Normal operation is established within the following

ranges (in °C): AMC5001: [-40, 100], MDM3100
and MDM3300: [0, 85], MDM3310 and MDM5000:
[0, 100]

Monitoring API Description v1 51/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

4.2.12 modem.remote.demod
The measurements are done at terminal level.

Tag key Description

modem_id ID of the modem. This ID can be retrieved via REST API: GET
/modem and search for id > systemId.

demod_id ID of the demodulator. Default ID is 0 but modems can have more

than one demodulator ID.

hps ID of the hub processing segment. This ID can be retrieved via the
REST API: GET /hub-module and search for hpsId.

host TCS-x-y

Field key Description Units

lock_status Terminal's lock status:

• true (lock)
• false (no lock)

locks Number of times the terminal acquired a terminal

lock.

ESN0 Measured forward EsN0. dB

rx_frequency Downlink RF receive frequency. Hz

total_phyfrms Total number of physical frames received.

total_dmmyfrms Total number of dummy frames received.

allowed_physfrms Total number of physical frames received for the

selected MODCOD or lower MODCOD.

allowed_droppfrms Total number of dropped frames for the selected

MODCOD or lower MODCOD.

phase_noise Measured terminal phase noise. dB

The measurement is according to the IESS-308
standard.

link_margin Difference between the measured EsN0 and the dB

required EsN0 to support the current MODCOD.

modcod MODCOD that is used for the terminal. It is

determined by the ACM algorithm (ACM client).
See Annex 2 - List of S2(X) MODCODs on page
89.

Monitoring API Description v1 52/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

active_bbd_drop_frms Total number of all dropped BaseBand frames from

all active MODCOD lower or equal to the requested
MODCOD.

active_bbd_frms Total number of received BaseBand frames from

all active MODCODs lower or equal to the
requested MODCOD.

cd Carrier to distortion. dB

cnd Carrier to noise and distortion. dB

rx_power_level Received power level. dB

4.2.13 modem.remote.encap
The measurements are done at terminal level.

Tag key Description

modem_id ID of the modem. This ID can be retrieved via REST API: GET
/modem and search for id > systemId.

qos_class_id Identifier of the Quality of Service class:

• BE
• CD1..14
• RT1..3
• Mgmnt
• RT-Mgmt

hps ID of the hub processing segment. This ID can be retrieved via the
REST API: GET /hub-module and search for hpsId.

host TCS-x-y

Field key Description Units

received_bytes Total number of bytes that the TelliNet client on the bytes
modem receives for a specific QoS class.

received_packets Total number of packets that the TelliNet client on packets

the modem receives for a specific QoS class.

receive_bitrate Rate at which the TelliNet client on the modem bits/sec

receives traffic bits for a specific QoS class.

sent_bytes Total number of bytes that the TelliShape client on bytes

the modem transmits for a specific QoS class. This
includes eTCP overhead.

Monitoring API Description v1 53/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

sent_packets Total number of packets that the TelliShape client packets

on the modem transmits for a specific QoS class.
This includes eTCP overhead.

sent_bitrate Rate at which the TelliShape client on the modem bits/sec

transmits traffic bits for a specific QoS class. This
includes eTCP overhead.

dropped_bytes Total number of bytes that the modem drops for a bytes
specific QoS class.

dropped_packets Total number of packets that the modem drops for packets
a specific QoS class.

avg_delay Average time that packets are queued in the mseconds

modem for a specific QoS class.

dropped_bitrate Total number of dropped bitrate for a specific Qos bits/sec

class on the modem.

traffic_type Options: "Layer 2", "Layer 3 unicast", "Layer 3",

"multicast", "Unknown"

4.2.14 modem.remote.tellinet
The measurements are done at terminal level.

Tag key Description

modem_id ID of the modem. This ID can be retrieved via REST API: GET
/modem and search for id > systemId.

qos_class_id Identifier of the Quality of Service class:

• BE
• CD1..14
• RT1..3

hps ID of the hub processing segment. This ID can be retrieved via the
REST API: GET /hub-module and search for hpsId.

host TCS-x-y

Field key Description Units

acc_tcp_con Number of accelerated TCP connections for a

modem and specific QoS class.

4.2.15 modem.remote.bgp
The measurements are done at terminal level.

Monitoring API Description v1 54/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

Tag key Description

modem_id ID of the modem. This ID can be retrieved via REST API: GET
/modem and search for id > systemId.

hps ID of the hub processing segment. This ID can be retrieved via the
REST API: GET /hub-module and search for hpsId.

host TCS-x-y

ip_address Modem IP address.

Field key Description Units

lastErrorCode Last error code.

learned_routes Number of actual learned routes in the routing

tables.

max_routes_reached Maximum number of learned routes reached.

status Actual status of the neighbour: Down/ Up/

Administratively shut down.

4.2.16 modem.remote.netquality
The measurements are done at terminal level.

Tag key Description

modem_id ID of the modem. This ID can be retrieved via REST API: GET
/modem and search for id > systemId.

hps ID of the hub processing segment. This ID can be retrieved via the
REST API: GET /hub-module and search for hpsId.

host TCS-x-y

qos_marking_id TOS byte of the ICMP packets that was used for the measurements
.

Field key Description Units

average_delay Average round trip time delay. ms

jitter Jitter value. ms

maximum_delay Maximum round trip time delay. ms

minimum_delay Minimum round trip time delay. ms

packet_loss Percentage of lost packets. %

Monitoring API Description v1 55/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

satellite_channel_id Unique identifier of the network.

vlan_tag Tag of the vlan for which the measurement was

performed.

4.3 Satnet Metrics

4.3.1 Forward Specific Metrics

The forward specific metrics are grouped in following measurements:
• forward.shaper
• forward.shaper.pools
• forward.shaper.multicast

4.3.1.1 forward.shaper

The measurements are done at CSE level.

Tag key Description

forward_link_id The ID can be retrieved via the REST API: GET /forward-link and
search for forwardLinkIds > systemId.

type The following values can be used:

• global; corresponds with all traffic on the forward link (= satnet).
• unicast; corresponds with unicast traffic on the forward link.
• multicast; corresponds with multicast traffic on the forward link.
• control; corresponds with forward signaling on the forward link.
• sw_upgrade; corresponds with SW download traffic on the
forward link.

hps ID of the hub processing segment. This ID can be retrieved via the
REST API: GET /hub-module and search for hpsId.

host PGICSE-x

Monitoring API Description v1 56/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

Field key Description Units

received_bytes Total number of bytes received at the CSE, bytes

including encapsulation overhead. The type of
traffic bytes that are counted depends on the value
of tag key 'type'.

received_packets Total number of packets received at the CSE, packets

including encapsulation overhead. The type of
traffic packets that are counted depends on the
value of tag key 'type'.

sent_bytes Total number of bytes transmitted by the CSE, bytes

including encapsulation overhead. The type of
traffic bytes that are counted depends on the value
of tag key 'type'.

sent_packets Total number of packets transmitted by the CSE, packets

including encapsulation overhead. The type of
traffic packets that are counted depends on the
value of tag key 'type'.

sent_symbols Total number of symbols transmitted by the CSE, symbols

including encapsulation overhead. The type of
traffic packets that are counted depends on the
value of tag key 'type'. It is possible that the node
does not exist.

sent_rate Bitrate transmitted by the CSE, including bits/sec

encapsulation overhead. The type of traffic bytes
that are counted depends on the value of tag key
'type'.

dropped_bytes Total number of bytes dropped at the CSE, bytes

including encapsulation overhead. The type of
traffic bytes that are counted depends on the value
of tag key 'type'.

dropped_packets Total number of packets dropped at the CSE, packets

including encapsulation overhead. The type of
traffic packets that are counted depends on the
value of tag key 'type'.

link_occupation Actual occupation of the forward link = 100 * actual %

symbol rate/configured symbol rate. This metric is
only available when type = global.

link_efficiency Actual efficiency of the forward link = sent bit rate / bits/baud
sent symbol rate. This metric is only available when
type = global.

Monitoring API Description v1 57/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

delay Average time that packets are queued in the CSE. milliseconds
This does not exist when using tag key value
'unicast'.

total_available_bitrate Corresponds to the link efficiency multiplied by the

peak rate.

symbol_rate Current symbol rate assigned for the shaper. baud

4.3.1.2 forward.shaper.pools

The measurements are done at forward pool level.

Available pools (if configured) are:
• Transport-based forward pool
• Class-based forward pool with QoS pools
Pools can be shared or dedicated to a VNO.

Tag key Description

forward_link_id The ID can be retrieved via the REST API: GET /forward-link and
search for forwardLinkId > systemId.

forward_pool_name • In case of a transport-based pool, the name is:

– forwardpool_[ID]
• In case of a class-based pool, the name is:
– forwardpool_[ID]
– forwardpool_[ID]-[QoSPool]
– forwardpool_[ID]_vno_[vnoID]-[QoSPool]
where:
– ID can be retrieved via the REST API: GET /forward-pool
and search for children > systemId
– QoSPool = BE, CD, RT1, RT2, or RT3

Monitoring API Description v1 58/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

– vnoID can be retrieved via the REST API: GET /domain

and search for the systemId of the VNO

hps ID of the hub processing segment. This ID can be retrieved via the
REST API: GET /hub-module and search for hpsId.

host PGICSE-x

Field key Description Units

received_bytes Total number of bytes received at the forward pool, bytes

including encapsulation overhead.

received_packets Total number of bytes received at the forward pool, packets

including encapsulation overhead.

sent_bytes Total number of bytes transmitted by the forward bytes

pool, including encapsulation overhead.

sent_packets Total number of packets transmitted by the forward packets

pool, including encapsulation overhead.

sent_symbols Total number of symbols transmitted by the forward symbols

pool, including encapsulation overhead. Symbols
are used when the forward pool is configured for
symbol rate based shaping.

dropped_bytes Total number of bytes dropped at the forward pool, bytes

including encapsulation overhead.

dropped_packets Total number of packets dropped at the forward packets

pool, including encapsulation overhead.

delay Average time that packets are queued in the milliseconds

forward pool.

eir_shaping_ratio Indicates the level of congestion in the forward

pool. The value can range from 0 to 1000, where
1000 means there is no congestion.

cir_overbooking Indicates if there is CIR congestion or not:

• 1 (yes): CIR congestion occurs; in this case a
child connected to the forward pool did not
receive its guaranteed CIR. This is an indication
of serious congestion.
• 0 (no): no CIR congestion occurs.

4.3.1.3 forward.shaper.multicast

The measurements are done at CSE level.

Monitoring API Description v1 59/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

Tag key Description

forward_link_id The ID can be retrieved via the REST API: GET /forward-link and
search for forwardLinkId > systemId.

multicast_address ID of the multicast stream. This ID can be retrieved via the REST
API: GET /multicast-circuit and search for id > systemId.

hps ID of the hub processing segment. This ID can be retrieved via the
REST API: GET /hub-module and search for hpsId.

host PGICSE-x

Field key Description Units

received_bytes Total number of bytes received at the multicast bytes

stream, including encapsulation overhead.

received_packets Total number of bytes received at the multicast packets

stream, including encapsulation overhead.

sent_bytes Total number of bytes transmitted by the multicast bytes

stream, including encapsulation overhead.

sent_packets Total number of packets transmitted by the packets

multicast stream, including encapsulation overhead.

sent_symbols Total number of symbols transmitted by the symbols

multicast stream, including encapsulation overhead.

dropped_bytes Total number of bytes dropped at the multicast bytes

stream, including encapsulation overhead.

dropped_packets Total number of packets dropped at the multicast packets

stream, including encapsulation overhead.

delay Average time that packets are queued in the milliseconds

multicast stream.

4.3.2 Return Specific Metrics

The retrun specific metrics are grouped in following measurements:

Monitoring API Description v1 60/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

• return.decapsulator
• return.decapsulator.return_capacity_group

4.3.2.1 return.decapsulator

The measurements are done at DCP level.

Tag key Description

return_link_id ID of the return link. This ID can be retrieved via the REST API:
GET /return-link and search for id > systemId.

type The following values can be used:

• global; corresponds with all traffic on the return link.
• unicast; corresponds with unicast data traffic on the return link.
• multicast; corresponds with multicast traffic on the return link.
• control; including e.g. ACM feedback and terminal management
traffic on the return link.

hps ID of the hub processing segment. This ID can be retrieved via the
REST API: GET /hub-module and search for hpsId.

host PGIDCP-x

Field key Description Units

received_bytes Total number of bytes received at the DCP, bytes

including GSE overhead. The type of traffic bytes
that are counted depends on the value of tag key
'type'.

received_packets Total number of packets received at the DCP, packets

including GSE overhead. The type of traffic packets
that are counted depends on the value of tag key
'type'.

4.3.2.2 return.decapsulator.return_capacity_group

The measurements are done at return capacity group level.

Monitoring API Description v1 61/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

For each return link technology, the return link is divided in one or more return capacity groups.

Tag key Description

return_capacity_group_id ID of the return capacity group. This ID can be retrieved via the
REST API: GET
• /hrc-mxdma-return-capacity-group
• /mrc-return-capacity-group
and search for id > systemId.

hps ID of the hub processing segment. This ID can be retrieved via the
REST API: GET /hub-module and search for hpsId.

host PGIDCP-x

Field key Description Units

received_bytes Total number of bytes received at the return bytes

capacity group, including GSE overhead.

received_packets Total number of packets received at the return packets

capacity group, including GSE overhead.

4.3.3 Return Technology Specific Metrics

The return R=technology specific metrics are grouped in following measurements:
• return.hrc.transponder
• return.hrc.return_capacity_group
• return.hrc.shaping
• return.hrc.mcd
• return.mrc
• return.mrc.return_capacity_group
• return.mrc.ulogon
• return.mrc.shaping

Monitoring API Description v1 62/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

4.3.3.1 return.hrc.transponder

Measurements are done at HRCCTL level.

Tag key Description

transponder_id Id of the transponder. This ID is retrieved via the REST API: GET
/transponder and search for id > systemId.

hps ID of the hub processing segment. This ID can be retrieved via the
REST API: GET /hub-module and search for hpsId.

host PGIHRCCTL-x

Field key Description Units

frequency_offset Offset from the configured transponder translation Hz

frequency.

4.3.3.2 return.hrc.return_capacity_group

Measurements are done at HRCCTL level.

Tag key Description

return_capacity_group_id ID of the return capacity group. This ID can be retrieved via the
REST API: GET
• /hrc-mxdma-return-capacity-group
and search for id > systemId.

hps ID of the hub processing segment. This ID can be retrieved via the
REST API: GET /hub-module and search for hpsId.

host PGIHRCCTL-x

type The following values can be used:

• mxdma
• scpc

Field key Description Units

assigned_volume Bit rate assigned to the return capacity group, bits/sec

including GSE overhead.

logged_on_terminals Total number of terminals logged on in the return

capacity group.

provisioned_terminals Total number of terminals provisioned in the return

capacity group.

Monitoring API Description v1 63/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

available_bandwidth Bandwidth available in the return capacity group. Hz

used_bandwidth Bandwidth that is used by operational terminals in Hz

the return capacity group.

logon_bandwidth Bandwidth that is used by terminals for logging on in Hz

the return capacity group.

physical_layer_efficiency Number of bits that are used per Hz. bits/Hz

best_modcod_efficiency Number of bits that are used per Hz for the best bits/Hz
MODCOD.

bbp_occupation Ratio of real data / total allocated bit rate, %

measured over the monitoring interval.

requested_ulogon_count Total number of ulogon requests from the HRC

controller. This is available when ulogon is
enabled.

received_ulogon_count Total number of received ulogons from the

terminals. This is available when ulogon is enabled.

4.3.3.3 return.hrc.shaping

Measurements are done at HRCCTL level.

Tag key Description

return_capacity_group_id ID of the return capacity group. This ID can be retrieved via the
REST API: GET
• /hrc-mxdma-return-capacity-group
and search for id > systemId.

return_pool_name Name of the return pool.

Mx-DMA return pools
• In case of a transport-based pool, the name is:

Monitoring API Description v1 64/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

– sh_node_tb_cg_[ID]
• In case of a class-based pool, the name is:
– sh_node_cb_cg_[QoSPool]_[ID]
– sh_node_cb_cg_[QoSPool]_vno_[vnoID]_[ID]
where:
– ID can be retrieved via the REST API: GET
/hrc-mxdma-return-capacity-group and search for
returnPoolIds > systemId
– QoSPool = BE, CD, RT1, RT2, RT3, MGMT or RTSIGN
– vnoID can be retrieved via the REST API: GET /domain
and search for the systemId of the VNO
Entire RCG
• hrc_mxdma_rcg_[ID]
• hrc_scpc_rcg_[ID]
where ID = return_capacity_group_id
The capacity that is left after shaping and distributed among the
operational Mx-DMA terminals (up until their PIR)
• sh_node_free_cap_root_[ID]
where ID = return_capacity_group_id

type The following values can be used:

• mxdma
• scpc

hps ID of the hub processing segment. This ID can be retrieved via the
REST API: GET /hub-module and search for hpsId.

host PGIHRCCTL-x

Field key Description Units

requested_rate Bit rate requested for the return pool, including GSE bits/sec
overhead.

allocated_rate Bit rate allocated to the return pool, including GSE bits/sec
overhead.

eir_shaping_ratio Indicates the level of congestion in the return pool.

The value can range from 0 to 1000, where 1000
means there is no congestion.

Monitoring API Description v1 65/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

cir_congestion Indicates if there is CIR congestion or not:

• true: CIR congestion occurs; in this case a child
connected to the forward pool did not receive its
guaranteed CIR. This is an indication of serious
congestion.
• false: no CIR congestion occurs.

4.3.3.4 return.hrc.mcd

Measurements are done at DEMOD level.

Tag key Description

demod_name Name of the demodulator. This name can be retrieved via the REST
API: GET /device-role/all and search for id > name.

hps ID of the hub processing segment. This ID can be retrieved via the
REST API: GET /hub-module and search for hpsId.

host PGIHRCCTL-x

Field key Description Units

clear_sky_N0 Clear-sky noise power density from the dBm/Hz

demodulator.

actual_N0 Actual noise power density from the demodulator. dBm/Hz

average_N0 Average value of noise power density dBm/Hz

measurements reported by the demodulator.

min_N0 Lowest value of noise power density dBm/Hz

measurements reported by the demodulator.

max_N0 Highest value of noise power density dBm/Hz

measurements reported by the demodulator.

frequency_max_N0 Frequency of the carrier at which noise, higher than Hz

or equal to 3dB above the average noise level, was
measured. The noise could indicate the presence
of interference. When there is no interference, the
value is NULL.

symbol_rate_N0 Symbol rate of the carrier at which noise higher baud

than or equal to 3dB above the average noise
level, was measured. The noise could indicate the
presence of interference. When there is no
interference, the value is NULL.

demod_not_responding_ Number of frames for which no response from the frames

count demodulator was received.

Monitoring API Description v1 66/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

protocol_errors_count Number of frames for which protocol errors were frames

reported for this demodulator.

4.3.3.5 return.mrc

Measurements are done at MRCCTL level.

Tag key Description

hps ID of the hub processing segment. This ID can be retrieved via the
REST API: GET /hub-module and search for hpsId.

host PGIMRCCTL-x

Field key Description Units

provisioned_terminals Total number of provisioned terminals which use

MRC return technology for the HPS.

logged_on_terminals Total number of operational terminals using

MRC.

transponder_frequency_off This is the measured and calculated transponder Hz

set frequency offset. This value can be positive or
negative.

transponder_uncertainty Represents the difference between what the Hz

transponder offset is and how much we are
compensating in the MCD receive frequency

4.3.3.6 return.mrc.return_capacity_group

Measurements are done at MRCCTL level.

Tag key Description

return_capacity_group_id ID of the return capacity group. This ID can be retrieved via the
REST API: GET /mrc-return-capacity-group and search for id >
systemId.

hps ID of the hub processing segment. This ID can be retrieved via the
REST API: GET /hub-module and search for hpsId.

host PGIMRCCTL-x

Field key Description Units

logged_on_terminals Number of terminals which are operational in the

MRC return capacity group.

Monitoring API Description v1 67/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

provisioned_terminals Number of terminals provisioned in the MRC return

capacity group.

logons_average Number of terminals per second that are logging on. 1/sec
This can be a value lower than 1 because it is
calculated over an interval. E.g. 10 terminals have
logged on during a period of 30 seconds => value =
0.33.

logoffs_average Number of terminals per second that are logging off. 1/sec
This can be a value lower than 1 because it is
calculated over an interval. E.g. 10 terminals have
logged off during a period of 30 seconds => value =
0.33.

configured_bandwidth Configured and available bandwidth in the MRC Hz

return capacity group.

bandwidth_filling_percent Indicates how much of the available bandwidth in %

age the MRC return capacity group is used.

allocated_rate Average bit rate assigned to the MRC return bits/sec

capacity group. The rate includes GSE overhead.

request_rate Average bit rate requested by the terminals for the bits/sec
MRC return capacity group. The rate includes GSE
overhead.

request_ratio Indicates how much of the requested rate is %

allocated. The value equals
request_rate/allocated_rate.

keep_alive_rate Average keep-alive bit rate assigned to the MRC bits/sec

return capacity group.

physical_layer_efficiency Indicates how efficiently the physical layer is used. bits/Hz

These are the number of bits that are used per Hz.
The value equals allocated_rate /
(configured_bandwidth * bandwidth_filling).

frame_error_ratio Indicates how many of the received bursts have %

errors.

schedule_duration Maximum number of time that the MRC controller ms

needs to schedule bursts.

allocated_carriers Number of carrier allocated to the MRC return

capacity group.

frame_occupation Indicate how the allocated frames are actually used %

by data.

Monitoring API Description v1 68/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

total_terminal_error_logof Number of terminal error logoffs.

fs

allocated_qos_carriers Estimated number of carriers that would be used if

free capacity is disabled.

4.3.3.7 return.mrc_ulogon

Measurements are done at MRCCTL level.

Tag key Description

mrc_controller_id ID of the MRC controller.

hps ID of the hub processing segment. This ID can be retrieved via the
REST API: GET /hub-module and search for hpsId.

host PGIMRCCTL-x

Field key Description Units

ulogon_requests Total number of ulogon requests sent by the MRC

controller to the terminal.

ulogon_responses Total number of ulogon messages received by the

MRC controller from the terminal.

4.3.3.8 return.mrc.shaping

Measurements are done at MRCCTL level.

Tag key Description

return_pool_name Name of the return pool.

• In case of a transport-based pool, the name is: pool_[ID]
• In case of a class-based pool, the name is: pool_[ID]_[QoSClass]
where:
– ID can be retrieved via the REST API: GET
/mrc-return-capacity-group and search for returnPoolIds
> systemId
– QoSClass = BE, CD, RT1, RT2, RT3

hps ID of the hub processing segment. This ID can be retrieved via the
REST API: GET /hub-module and search for hpsId.

host PGIMRCCTL-x

Monitoring API Description v1 69/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

Field key Description Units

requested_bitrate Average bit rate requested by the terminals for the bits/sec
MRC return pool. The rate includes GSE overhead.

assigned_bitrate Average bit rate assigned to the MRC return pool. bits/sec
The rate includes GSE overhead.

EIR_shaping_ratio Indicates the level of congestion in the pool. The

value can range from 0 to 1000, where 1000
means there is no congestion.

cir_congestion Indicates if there is CIR congestion or not:

• true: CIR congestion occurs; in this case a child
connected to the pool did not receive its
guaranteed CIR. This is an indication of serious
congestion.
• false: no CIR congestion occurs.

4.3.4 Network Specific Metrics

The network specific metrics are grouped in following measurements:
• l3.vrf
• network.l3
• ospf
• bgp
• bgpstatus (obsolete)

4.3.4.1 l3.vrf

The measurements are done at DEM level.

Forward

Return

Monitoring API Description v1 70/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

Monitoring API Description v1 71/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

Tag key Description

vrf ID of the VRF. A VRF corresponds with a virtual network.

The ID can be retrieved from DataMiner. Go to Newtec Dialog >
Hub Equipment > <Gateway> > <Hub Module> > Local
Monitoring and select the Satellite Monitoring Network >
Networking per VRF dashboard. The VRF IDs can be
selected/viewed in the vrf drop down list.

port The following values can be used:

• external; corresponds with the external interface towards the
customer network.
• internal; corresponds with the internal interface towards the
satellite.

hps ID of the hub processing segment. This ID can be retrieved via the
REST API: GET /hub-module and search for hpsId.

host cal-vrouter (software component running on DEM)

Field key Description Units

received_bytes Total number of bytes received in the virtual bytes

network. The interface at which the bytes are
counted depends on the value of tag key 'port'.

received_packets Total number of unicast and multicast packets packets

received in the virtual network. The interface at
which the packets are counted depends on the
value of tag key 'port'.

received_multicast_pack Total number of multicast packets received in the packets

ets virtual network. The interface at which the packets
are counted depends on the value of tag key 'port'.

sent_bytes Total number of bytes transmitted in the virtual bytes

network. The interface at which the bytes are
counted depends on the value of tag key 'port'.

sent_packets Total number of unicast and mutlicast packets packets

transmitted in the virtual network. The interface at
which the packets are counted depends on the
value of tag key 'port'.

sent_multicast_packets Total number of multicast packets transmitted in the packets

virtual network. The interface at which the packets
are counted depends on the value of tag key 'port'.

dropped_packets Total number of dropped packets in the virtual packets

network. The interface at which the packets are
counted depends on the value of tag key 'port'.

Monitoring API Description v1 72/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

erroneous_received_pac Not used.

kets

4.3.4.2 ospf

The measurements are done at DEM level and represent status information related to OSPF per
VRF.

Tag key Description

vrf_id ID of the VRF. A VRF corresponds with a virtual network.

The ID can be retrieved from DataMiner. Go to Newtec Dialog >
Hub Equipment > <Gateway> > <Hub Module> > Local
Monitoring and select the Satellite Monitoring Network >
Networking per VRF dashboard. The VRF IDs can be
selected/viewed in the vrf drop down list.

proto OSPF

instance The following values can be used:

• bird (info is coming from the IPv4 routing daemon)
• bird6 (info is coming from the IPv6 routing daemon)

table master

hps ID of the hub processing segment. This ID can be retrieved via the
REST API: GET /hub-module and search for hpsId.

host PGIDEM-x

Field key Description Units

router_id This is the IP address of the external OSPF router.

state Connectivity state of the external router. The

following states exist:
• up: the connectivity is operational.
• down: the connectivity with the external router is
down.
• start: the connectivity with the external router is
being set up but is not yet operational.

4.3.4.3 bgp

The measurements are done at DEM level and represent status information related to BGP per VRF.

Tag key Description

Monitoring API Description v1 73/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

vrf_id ID of the VRF. A VRF corresponds with a virtual network.

The ID can be retrieved from DataMiner. Go to Newtec Dialog >
Hub Equipment > <Gateway> > <Hub Module> > Local
Monitoring and select the Satellite Monitoring Network >
Networking per VRF dashboard. The VRF IDs can be
selected/viewed in the vrf drop down list.

proto BGP

instance The following values can be used:

• bird (the info is coming from the IPv4 routing daemon)
• bird6 (the info is coming from the IPv6 routing daemon)

table master

hps ID of the hub processing segment. This ID can be retrieved via the
REST API: GET /hub-module and search for hpsId.

host PGIDEM-x

Field key Description Units

neighbor_id IP address of the BGP neighbor to which the

statistics apply. This can be an external neighbor or
an internal neighbor (the modem).

bgp_state This is the status of the BGP connectivity for a

specific neighbor. The following statuses exist:
• Idle
• Active
• Connect
• OpenSent
• OpenConfirm
• Established

Monitoring API Description v1 74/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

last_error Descriptive text of the last error.

route_limit This is a string, which indicates the number of

learned routes versus the maximum number of
routes that can be learned for this association. For
example: 2/1000, where 2 is the number of learned
routes and 1000 the maximum number of routes
that can be learned.

4.3.5 Infrastructure Specific Metrics

The infrastructure specific metrics are grouped in following measurements:
• infra.l2.dem
• infra.l3.dem
• infra.vrouter_cpu
• tas

4.3.5.1 infra.l2.dem

The measurements are done at L2DEM level.

Forward

Monitoring API Description v1 75/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

Return

Tag key Description

port The following values can be used:

• external; corresponds with the external interface towards the
customer network.
• internal; corresponds with the internal interface towards the
satellite.

hps ID of the hub processing segment. This ID can be retrieved via the
REST API: GET /hub-module and search for hpsId.

host PGIL2DEM-x

Field key Description Units

received_bytes Total number of bytes received at the L2DEM. The bytes

interface at which the bytes are counted depends
on the value of tag key 'port'.

received_packets Total number of packets received at the L2DEM. packets

The interface at which the packets are counted
depends on the value of tag key 'port'.

sent_bytes Total number of bytes transmitted by the L2DEM. bytes

The interface at which the bytes are counted
depends on the value of tag key 'port'.

sent_packets Total number of packets transmitted by the L2DEM. packets

The interface at which the packets are counted
depends on the value of tag key 'port'.

Monitoring API Description v1 76/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

4.3.5.2 infra.l3.dem

The measurements are done at DEM level.

Forward

Return

Tag key Description

port Following values can be used:

• external; corresponds with the external interface towards the
customer network.
• internal; corresponds with the internal interface towards the
satellite.
• control_external; corresponds with the external interface towards
the customer network and control traffic.
• control_internal; corresponds with the internal interface towards
the satellite and control traffic.

portID Obsolete.

hps ID of the hub processing segment. This ID can be retrieved via the
REST API: GET /hub-module and search for hpsId.

host cal-vrouter (software component running on DEM)

Field key Description Units

received_bytes Total number of bytes received at the DEM. The bytes

interface at which the bytes are counted
depends on the value of tag key 'port'.

Monitoring API Description v1 77/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

received_packets Total number of packets received at the DEM. packets

The interface at which the packets are counted
depends on the value of tag key 'port'.

received_multicast_packets Total number of multicast packets received at

the DEM. The interface at which the packets are
counted depends on the value of tag key 'port'.

missed_packets_queue_full Total number of packets received but dropped packets

because the input queue is full.

sent_bytes Total number of bytes transmitted by the DEM. bytes

The interface at which the bytes are counted
depends on the value of tag key 'port'.

sent_packets Total number of packets transmitted by the packets

DEM. The interface at which the packets are
counted depends on the value of tag key 'port'.

dropped_packets_bad_crc Not used.

dropped_packets_bad_length Not used.

erroneous_received_packets Not used.

failed_sent_packets Not used.

receive_buffer_allocation_errors Not used.

4.3.5.3 infra.vrouter_cpu

The measurements are done at DEM level.

Tag key Description

cpuID This is the ID of the core type. The following values exits:
• 1 (worker core)
• 2 (sync core)

hps ID of the hub processing segment. This ID can be retrieved via the
REST API: GET /hub-module and search for hpsId.

host cal-vrouter (software component running on DEM)

Field key Description Units

ConsumedCpuCycles The number of CPU cycles that the DEM core

consumed over the measurement interval.

CpuCycles The number of cycles the DEM core can execute

per second.

Monitoring API Description v1 78/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

PrevConsumedCycles The number of CPU cycles that the DEM core

previously consumed.

4.3.5.4 tas

The measurements are done at TAS level.

Tag key Description

tn_instance_id ID of the Tellinet instance. This ID can be retrieved via the REST
API: GET /tellinet-instance and search for id > systemId.

type tellinet

hps ID of the hub processing segment. This ID can be retrieved via the
REST API: GET /hub-module and search for hpsId.

host PGITAS-x

tas_instance_id ID of the TAS instance.

Field key Description Units

associations.count The number of active ETCP connections for this

Tellinet instance. This number corresponds with
the number of terminals that have set up an ETCP
tunnel with the Tellinet instance.

etcp.connections.count The number of actual accelerated TCP connections

for this Tellinet instance.

used_memory The actual memory used by the Tellinet instance. If bytes

the number of accelerated TCP increases, the used
memory will also increase.

4.4 Element Metrics

The Element metrics are automatically collected every 10 seconds. They collect operating
information of all VMs, servers and switches in the Dialog platform.
Following measurements exist:
• System related:
– cpu
– disk
– diskio
– kernel
– mem
– net

Monitoring API Description v1 79/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

– netstat
– processes
– swap
– system
• Switch related:
– snmp
• Application related:
– app.rtm_collector
– jvm_memory
– procstat (only available on CMS)
– procstat_lookup
– internal_agent
– internal_gather
– internal_memstats
– internal_write
To show the field and tag keys of the measurements, execute following commands:

http://[hmgw-ip]:8086/query?pretty=true&db=telegraf&q=SHOW field keys FROM

"<measurement name>"
http://[hmgw-ip]:8086/query?pretty=true&db=telegraf&q=SHOW tag keys FROM
"<measurement name>"

For more information on how to explore the TSDB content, refer to InfluxDB Schema Exploration.

4.5 VerneMQ Metrics

MQTT is a publish-subscribe network protocol to transport messages between a message broker
and clients. An MQTT broker is a server that receives all messages from the publishing clients and
then routes the messages to the subscribed clients. An MQTT client is any device that runs an
MQTT library and connects to an MQTT broker over a network.
MQTT information is organized in a hierarchy of topics. When a publisher has a new item of data to
distribute, it sends a message with the data to the connected broker. The broker then distributes the
information to any clients that have subscribed to that topic.
In Dialog, MQTT bridging is used. The bridge is setup between an internal broker in Dialog and an
external broker at the customer side. Multiple internal clients can publish to the internal broker,
which forwards the messages to the external broker. Multiple external clients can connect to the
external broker in any way desired without having to adapt anything on the internal broker.
The internal MQTT broker used in Dialog is VerneMQ and is an application running on the BSC
virtual machine. The internal broker is configured in a 3-node clustered setup. All cluster components
are active in order to synchronize messages. Every internal client connects to the cluster via a virtual
IP address.

Monitoring API Description v1 80/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

For more information about the MQTT messages used in Dialog, refer to the Dialog
MQTT User Guide.

The following tables describes the metrics of the internal MQTT broker VerneMQ. These metrics are
automatically collected every 10 seconds.
The metrics are grouped in several measurements. The measurements have following tag keys.

Tag key Description

url http://localhost:8888/metrics All measurements.

node [email protected] (on BSC-0-1) All measurements.

[email protected] (on BSC-0-2)
[email protected] (on BSC-0-3)

host BSC-0-1, BSC-0-2, or BSC-0-3 All measurements.

mqtt_version Version of MQTT protocol. All 'mqtt_' measurements.

reason_code Short description tat indicates the result of mqtt_auth_received

an operation. mqtt_auth_sent
For more information about the reason mqtt_connack_sent
codes, refer to Reason Code.
mqtt_disconnect_received
mqtt_disconnect_sent
mqtt_puback_received
mqtt_puback_sent
mqtt_pubcomp_received
mqtt_pubcomp_sent
mqtt_pubrec_received
mqtt_pubrec_sent
mqtt_pubrel_received
mqtt_pubrel_sent

return_code If the server receives a well formed Only mqtt_connack_sent.

CONNECT packet but is unable to
complete the connection, the server MAY
send a CONNACK packet containing the
appropriate return code.
For more information about the return
codes, refer to Return Code.

The following tables list all measurements, their field keys and corresponding description.
'mqtt_' measurements

Monitoring API Description v1 81/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

Measurement Field key Description

mqtt_auth_received counter The number of AUTH packets

received.

mqtt_auth_sent counter The number of AUTH packets

sent.

mqtt_connack_accepted_sent counter The number of times a connection

has been accepted.

mqtt_connack_bad_credentials_sent counter The number of times a client sent

bad credentials.

mqtt_connack_identifier_rejected_sent counter The number of times a client was

rejected due to a unacceptable
identifier.

mqtt_connack_not_authorized_sent counter The number of times a client was

rejected due to insufficient
authorization.

mqtt_connack_sent counter The number of CONNACK packets

sent.

mqtt_connack_server_unavailable_sent counter The number of times a client was

rejected due the the broker being
unavailable.

mqtt_connack_unacceptable_protocol_sent counter The number of times the broker is

not able to support the requested
protocol.

mqtt_connect_received counter The number of CONNECT packets

received.

mqtt_disconnect_received counter The number of DISCONNECT

packets received.

mqtt_disconnect_sent counter The number of DISCONNECT

packets sent.

mqtt_invalid_msg_size_error counter The number of packages

exceeding the maximum allowed
size.

mqtt_pingreq_received counter The number of PINGREQ packets

received.

mqtt_pingresp_sent counter The number of PINGRESP

packets sent.

mqtt_puback_invalid_error counter The number of unexpected

PUBACK messages received.

Monitoring API Description v1 82/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

mqtt_puback_received counter The number of PUBACK packets

received.

mqtt_puback_sent counter The number of PUBACK packets

sent.

mqtt_pubcomp_invalid_error counter The number of unexpected

PUBCOMP messages received.

mqtt_pubcomp_received counter The number of PUBCOMP packets

received.

mqtt_pubcomp_sent counter The number of PUBCOMP packets

sent.

mqtt_publish_auth_error counter The number of unauthorized

publish attempts.

mqtt_publish_error counter The number of times a PUBLISH

operation failed due to a netsplit.

mqtt_publish_received counter The number of PUBLISH packets

received.

mqtt_publish_sent counter The number of PUBLISH packets

sent.

mqtt_pubrec_invalid_error counter The number of unexpected

PUBREC messages received.

mqtt_pubrec_received counter The number of PUBREC packets

received.

mqtt_pubrec_sent counter The number of PUBREC packets

sent.

mqtt_pubrel_received counter The number of PUBREL packets

received.

mqtt_pubrel_sent counter The number of PUBREL packets

sent.

mqtt_suback_sent counter The number of SUBACK packets

sent.

mqtt_subscribe_auth_error counter The number of unauthorized

subscription attempts.

mqtt_subscribe_error counter The number of times a

SUBSCRIBE operation failed due
to a netsplit.

mqtt_subscribe_received counter The number of SUBSCRIBE

packets received.

Monitoring API Description v1 83/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

mqtt_unsuback_sent counter The number of UNSUBACK

packets sent.

mqtt_unsubscribe_error counter The number of times an

UNSUBSCRIBE operation failed
due to a netsplit.

mqtt_unsubscribe_received counter The number of UNSUBSCRIBE

packets received.

'queue_' measurements

Measurement Field key Description

queue_initialized_from_storage counter The number of times a MQTT queue process

has been initialized from offline storage.

queue_message_drop counter The number of messages dropped due to full

queues.

queue_message_expired counter The number of messages which expired

before delivery.

queue_message_in counter The number of PUBLISH packets received

by MQTT queue processes.

queue_message_out counter The number of PUBLISH packets sent from

MQTT queue processes.

queue_message_unhandled counter The number of unhandled messages when

connecting with clean session=true.

queue_processes counter The number of MQTT queue processes.

queue_setup counter The number of times a MQTT queue process

has been started.

queue_teardown counter The number of times a MQTT queue process

has been terminated.

'retain_' measurements

Measurement Field key Description

retain_memory gauge The number of bytes used for storing retained messages.

retain_messages gauge The number of currently stored retained messages.

'system_' measurements

Measurement Field key Description

system_context_switches counter The total number of context switches.

Monitoring API Description v1 84/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

system_exact_reductions counter The exact number of reductions performed.

system_gc_count counter The number of garbage collections

performed.

system_io_in counter The total number of bytes received through

ports.

system_io_out counter The total number of bytes sent through

ports.

system_process_count counter The number of Erlang processes.

system_reductions counter The number of reductions performed in the

virtual machine since the node was started.

system_run_queue gauge The total number of processes and ports

ready to run on all run-queues.

system_runtime counter The sum of the runtime for all threads in the
Erlang runtime system.

system_utilization gauge The average scheduler utilization expressed

in %.

system_utilization_scheduler_1 gauge Utilization of scheduler 1 expressed in %.

system_utilization_scheduler_2 gauge Utilization of scheduler 2 expressed in %.

system_utilization_scheduler_3 gauge Utilization of scheduler 3 expressed in %.

system_utilization_scheduler_4 gauge Utilization of scheduler 4 expressed in %.

system_utilization_scheduler_5 gauge Utilization of scheduler 5 expressed in %.

system_utilization_scheduler_6 gauge Utilization of scheduler 6 expressed in %.

system_utilization_scheduler_7 gauge Utilization of scheduler 7 expressed in %.

system_utilization_scheduler_8 gauge Utilization of scheduler 8 expressed in %.

system_wallclock counter The number of milliseconds passed since the

node was started.

system_words_reclaimed_by_gc counter The number of words reclaimed by the

garbage collector.

'netsplit_' measurements

Measurement Field key Description

netsplit_detected counter The number of detected netsplits.

netsplit_resolved counter The number of resolved netsplits.

Monitoring API Description v1 85/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

'router_' measurements

Measurement Field key Description

router_matches_local counter The number of matched local subscriptions.

router_matches_remote counter The number of matched remote subscriptions.

router_memory gauge The number of bytes used by the routing table.

router_subscriptions gauge The number of subscriptions in the routing table.

'client_' measurements

Measurement Field key Description

client_expired Obsolete.

client_keepalive_expired counter The number of clients which failed to communicate

within the keepalive time period.

'socket_' measurements

Measurement Field key Description

socket_close counter The number of times an MQTT socket has been

closed.

socket_close_timeout counter The number of times VerneMQ closed an MQTT

socket due to no CONNECT frame has been received
on time.

socket_error counter The total number of socket errors that have occurred.

socket_open counter The number of times an MQTT socket has been

opened.

'bytes_' measurements

Measurement Field key Description

bytes_received counter The total number of bytes received.

bytes_sent counter The total number of bytes sent.

'cluster_' measurements

Measurement Field key Description

cluster_bytes_dropped counter The number of bytes dropped while sending data to

other cluster nodes.

cluster_bytes_received counter The number of bytes received from other cluster

nodes.

Monitoring API Description v1 86/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

cluster_bytes_sent counter The number of bytes sent to other cluster nodes.

'vm_memory_' measurements

Measurement Field key Description

vm_memory_atom gauge The amount of memory in bytes allocated for

atoms.

vm_memory_atom_used gauge The amount of memory in bytes used by

atoms.

vm_memory_binary gauge The amount of memory in bytes allocated for

binaries.

vm_memory_code gauge The amount of memory in bytes allocated for

code.

vm_memory_ets gauge The amount of memory in bytes allocated for

ETS tables.

vm_memory_processes gauge The amount of memory in bytes allocated for

processes.

vm_memory_processes_used gauge The amount of memory in bytes used by

processes.

vm_memory_system gauge The amount of memory in bytes allocated for

the emulator.

vm_memory_total gauge The total amount of memory in bytes

allocated.

Monitoring API Description v1 87/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

4.6 Annex 1 - List of HRC MODCODs

ModCod ID Modulation Coding

6 QPSK 3/10

7 7/20

8 4/10

9 9/20

10 1/2

11 11/20

12 6/10

13 13/20

14 7/10

15 3/4

16 4/5

17 8PSK 17/30

18 6/10

19 19/30

20 2/3

21 7/10

22 11/15

23 23/30

24 4/5

25 5/6

26 13/15

27 16 APSK 27/40

28 7/10

29 29/40

30 3/4

Monitoring API Description v1 88/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

ModCod ID Modulation Coding

31 31/40

32 4/5

33 33/40

34 17/20

35 7/8

36 32 APSK 18/25

37 37/50

38 38/50

39 39/50

40 4/5

41 41/50

42 21/25

43 43/50

44 22/25

45 9/10

4.7 Annex 2 - List of S2(X) MODCODs

DVB-S2

ID Modulation Coding Normal Frame Short Frame

1 QPSK 1/4 ✔ ✔

2 1/3 ✔ ✔

3 2/5 ✔ ✔

4 1/2 ✔ ✔

5 3/5 ✔ ✔

6 2/3 ✔ ✔

7 3/4 ✔ ✔

8 4/5 ✔ ✔

Monitoring API Description v1 89/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

ID Modulation Coding Normal Frame Short Frame

9 5/6 ✔ ✔

10 8/9 ✔ ✔

11 9/10 ✔ ✖

12 8PSK 3/5 ✔ ✔

13 2/3 ✔ ✔

14 3/4 ✔ ✔

15 5/6 ✔ ✔

16 8/9 ✔ ✔

17 9/10 ✔ ✖

18 16APSK 2/3 ✔ ✔

19 3/4 ✔ ✔

20 4/5 ✔ ✔

21 5/6 ✔ ✔

22 8/9 ✔ ✔

23 9/10 ✔ ✖

24 32APSK 3/4 ✔ ✔

25 4/5 ✔ ✔

26 5/6 ✔ ✔

27 8/9 ✔ ✔

28 9/10 ✔ ✖

DVB-S2X
Standard and VH-SNR MODCOD

ID Modulation Coding Normal Frame Short Frame

1 QPSK 1/4 ✔ ✔

2 1/3 ✔ ✔

3 2/5 ✔ ✔

4 1/2 ✔ ✔

Monitoring API Description v1 90/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

ID Modulation Coding Normal Frame Short Frame

5 3/5 ✔ ✔

6 2/3 ✔ ✔

7 3/4 ✔ ✔

8 4/5 ✔ ✔

9 5/6 ✔ ✔

10 8/9 ✔ ✔

11 9/10 ✔ ✖

12 8PSK 3/5 ✔ ✔

13 2/3 ✔ ✔

14 3/4 ✔ ✔

15 5/6 ✔ ✔

16 8/9 ✔ ✔

17 9/10 ✔ ✖

18 16APSK 2/3 ✔ ✔

19 3/4 ✔ ✔

20 4/5 ✔ ✔

21 5/6 ✔ ✔

22 8/9 ✔ ✔

23 9/10 ✔ ✖

24 32APSK 3/4 ✔ ✔

25 4/5 ✔ ✔

26 5/6 ✔ ✔

27 8/9 ✔ ✔

28 9/10 ✔ ✖

32 QPSK 11/45 ✖ ✔

33 4/15 ✖ ✔

34 13/45 ✔ ✖

Monitoring API Description v1 91/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

ID Modulation Coding Normal Frame Short Frame

35 14/45 ✖ ✔

36 9/20 ✔ ✖

37 7/15 ✖ ✔

38 8/15 ✖ ✔

39 11/20 ✔ ✖

40 32/45 ✖ ✔

41 8PSK 7/15 ✖ ✔

42 8/15 ✖ ✔

43 5/9_L ✔ ✖

44 26/45 ✖ ✔

45 26/45_L ✔ ✖

46 23/36 ✔ ✖

47 25/36 ✔ ✖

48 32/45 ✖ ✔

49 13/18 ✔ ✖

50 16APSK 7/15 ✖ ✔

51 1/2_L ✔ ✖

52 8/15 ✖ ✔

53 8/15_L ✔ ✖

54 5/9_L ✔ ✖

55 26/45 ✔ ✔

56 3/5 ✔ ✔

57 3/5_L ✔ ✖

58 28/45 ✔ ✖

59 23/36 ✔ ✖

60 2/3_L ✔ ✖

61 25/36 ✔ ✖

Monitoring API Description v1 92/95

ST Engineering iDirect Dialog R2.5.3
 TSDB

ID Modulation Coding Normal Frame Short Frame

62 32/45 ✖ ✔

63 13/18 ✔ ✖

64 7/9 ✔ ✖

65 77/90 ✔ ✖

66 32APSK 2/3 ✖ ✔

67 2/3_L ✔ ✖

69 32/45 ✔ ✔

70 11/15 ✔ ✖

71 7/9 ✔ ✖

72 64APSK 32/45_L ✔ ✖

73 11/15 ✔ ✖

74 7/9 ✔ ✖

76 4/5 ✔ ✖

78 5/6 ✔ ✖

80 128APSK 3/4 ✔ ✖

81 7/9 ✔ ✖

82 256APSK 29/45_L ✔ ✖

83 2/3_L ✔ ✖

84 31/45_L ✔ ✖

85 32/45 ✔ ✖

86 11/15_L ✔ ✖

87 3/4 ✔ ✖

Monitoring API Description v1 93/95

ST Engineering iDirect Dialog R2.5.3
 Abbreviations

5 Abbreviations

Abbreviation Definition

API Application Programming Interface

BE Best Effort

BUC Block Upconverter

CIDI Common iDirect Deployment Infrastructure

CMS Configuration Management Server

CPM Continuous Phase Modulation

CSE Controller Shaper Encapsulator

DM Device Manager

DMA Data Miner Application/Agent

FWD Forward

GUI Graphical User Interface

HMGW Hub Module Gateway

HMMS Hub Module Management Server

HRC High Resolution Coding

HTTP(S) Hypertext Transfer Protocol (Secure)

ID Identifier

IP Internet Protocol

KPI Key Performance Indicator

LNB Low Noise Block downconverter

MF-TDMA Multi Frequency Time Division Multiple Access

MRC Multi Resolution Coding

Mx-DMA™ Cross-Dimensional Multiple Access™

NMS Network Management System

NPCI Newtec Private Cloud Infrastructure

PC Personal Computer

PIR Peak Information Rate

Monitoring API Description v1 94/95

ST Engineering iDirect Dialog R2.5.3
 Abbreviations

Abbreviation Definition

NxtGen Mx-DMA Next Generation Cross-Dimensional Multiple Access™

QoS Quality of Service

REST Representational State Transfer

RTN Return

SCPC Single Channel Per Carrier

SNMP Simple Network Management Protocol

SOAP Simple Object Access Protocol

TAS Traffic Acceleration Service

TCS Terminal Configuration Server

TSDB Time Series DataBase

UI User Interface

URL Uniform Resource Locator

VNO Virtual Network Operator

VSAT Very Small Aperture Terminal

WSDL Web Services Description Language

XML Extensible Markup Language

Monitoring API Description v1 95/95

ST Engineering iDirect Dialog R2.5.3
ST Engineering iDirect
13861 Sunrise Valley Drive, Suite 300
Herndon, VA 20171-6126
+1 703.648.8000
+1 866.345.0983
wwww.idirect.net

ST Engineering iDirect (Europe)

Laarstraat 5
9100 Sint-Niklaas Belgium
+32 3 780 6500
wwww.idirect.net