ATSC 3.0 - STLTP Monitoring and Traffic Analysis
Last Update: Jun 20, 2023

STLTP Monitoring and Traffic Analysis

Print

Web UI Icons (STLTP Group)

STLTP Monitoring and Traffic Analysis - Settings
STLTP Monitoring and Traffic Analysis - Traffic
STLTP Monitoring and Traffic Analysis - Services
STLTP Monitoring and Traffic Analysis - Signalling
STLTP Monitoring and Traffic Analysis - Capture

Supported Devices

Broadcast Standards

ATSC 3.0

Description

Introduction

ATSC3 STLTP is a transport protocol designed for delivering multiplexed media and signalling payload content over an IP network from the Scheduler to the broadcasting transmitter. Please refer to https://www.atsc.org/wp-content/uploads/2018/01/A324-2018-Scheduler-STL.pdf for the details on the STLTP design and operation.

Avateq implements the following stages of STLTP traffic processing:

  • Ingress multicast streams
    • IP/UDP multicast packet reception, for the main STLTP multiplex and up to two Forward Error Correction (FEC) streams
    • Monitoring gross data rate per multicast stream
    • RTP packet header fields validation
    • Monitoring invalid packet drop rate
    • RTP packet reordering and discarding duplicated packets, to compensate for potential delivery path issues
    • Monitoring packet reordering and duplication rate
    • Missing packet recovery by means of FEC stream(s), as per RFC2733 and SMPTE 2022-1-2007
    • Monitoring the current FEC scheme and successful packet recovery rate
    • Monitoring the packet loss rate - missing sequence numbers per unit time
  • Main STLTP multiplex
    • Monitoring stream continuity and counting parsing errors
    • Decapsulating the inner STLTP streams
    • Validating inner IP/UDP/RTP headers
    • Monitoring the inner stream continuity
    • Decapsulating inner stream payload
  • Preamble, Timing / Management, and PLP baseband streams
    • Monitoring stream continuity and counting parsing errors
    • Decapsulating and interpreting stream payload
    • Presenting the payload contents on UI
  • ATSC3 services monitoring
    • LLS signalling parsing and service discovery
    • Presenting the service list on UI, allowing the user to select a service
  • ALP / IP layer statistics monitoring
    • ALP packet types breakdown
    • Bad packet counters
    • List of inner IP streams available in the current multiplex
  • ATSC3 Low-Level Signaling (LLS) monitoring
    • Link mapping table (LMT) and LLS groups
    • Bad LLS packets
    • Allowing to download LLS components as files
    • Presenting LLS contents as formatted or raw XML
  • DASH / ROUTE services monitoring
    • Presenting DASH/ROUTE component location
    • Allowing to download DASH/ROUTE components as files
    • Monitoring DASH/ROUTE component statistics: data rate, number of objects processed and missing
  • Network packet capturing for diagnostic purposes and off-line examination.

Configuring the STLTP monitor

On the Dashboard web page, navigate to “STLTP” tab / “Settings and Traffic”:

Figure 1 - STLTP Tab - Settings and Traffic

Figure 1 - STLTP Tab - Settings and Traffic

In the “Listener settings” section, specify the STLTP stream settings as emitted by the scheduler:

Figure 2 - Settings and Traffic - Listener Settings

ParameterDescription
STL Source IPSTL multicast source IP address
STL Dest. IPSTL multicast destination group IP address
STL Dest. PortSTL multicast destination port
Listen to FEC stream(s)Enable FEC stream reception and STL packet recovery
Show L1D for: SubframeSpecify the subframe ID to decode and monitor L1D signaling
Show L1D for: PLPSpecify the PLP ID to decode and monitor L1D signaling

NOTE: click “Set” button next to each field after typing in the value NOTE: L1D parsing and analysis is supported for one PLP in one subframe

There is no need to explicitly specify multicast settings for the FEC stream(s). Once the FEC reception is enabled, the device will automatically listen for FEC1 on “STL Dest. Port” + 2, and for FEC2 on “STL Dest. Port” + 4, as per the SMPTE 2022-1-2007. Valid RTP multicast streams received on these ports are assumed to carry FEC packets for the main STLTP multiplex and will be used by the device to perform packet repairing.

STLTP multicast settings can be checked by capturing the network traffic and examining it in Wireshark:

Figure 3 - STLTP Settings Check with Wireshark

Click the “Start” button to run the STLTP listener and check its status in the corresponding field. In case of an error, the details will be shown in the Status message.

Ingress streams statistics

“Ingress multicast streams” section provides run-time statistics for the incoming multicast streams received by the device.

Figure 4 - Settings and Traffic - Ingress Multicast Streams

ParameterDescription
FEC columns (L)L parameter of the FEC scheme
FEC rows (D)D parameter of the FEC scheme
FEC recovery rate, pkt/sNumber of network packets per second that were lost but successfully recovered by applying FEC.
A non-zero value suggests that packet loss in the main STLTP multiplex is compensated by the FEC recovery.

“Ingress stream statistics” table provides a per-stream breakdown of monitored quality parameters:

ParameterDescription
StreamDestination multicast group and port
Data rate, kB/sGross stream data rate, kB/s, calculated on the UDP payload of a given stream.
Normally the values should remain steady, and FEC stream data rates should correspond to the selected scheme.
Spikes or fluctuations suggest packet delivery issues
Drop rate, pkt/sPackets dropped by the device due to invalid RTP header fields or unexpected RTP payload type.
A non-zero value suggests UDP payload issues in the corresponding stream
Reordering rate, pkt/sPackets are reordered by the device according to their sequence numbers.
A non-zero value suggests network issues that result in packet reordering
Duplication rate, pkt/sPackets discarded by the device due to duplicated sequence numbers.
A non-zero value suggests network issues that result in packet duplication
Loss rate, pkt/sMissing packet sequence numbers per unit time.
A non-zero value points at packet loss in the given stream
NOTE: for the main STLTP multiplex, the packet loss rate is calculated after applying FEC recovery

Monitoring outer STLTP stream

The Outer layer refers to the main STLTP multicast stream with the given SSM settings: source IP address and destination multicast group and port. The validity and continuity of the outer stream are monitored constantly, and RTP packets that belong to the inner streams are extracted and re-assembled on-the-fly.

Outer RTP stream statistics are shown below:

Figure 5 - Settings and Traffic - Outer Stream

ParameterDescription
Locked to streamSet to “Yes” when stream packet continuity is sustained, and the packets keep arriving within a predefined timeout (10 seconds).
Total dropped (errors)Number of packets discarded since the STLTP monitor was started, due to errors in the packet format, payload integrity or invalid header field values.
Stream interruptionsNumber of times the stream lock was lost due to the discovered errors
Internal errorsNumber of packets not processed by the device due to internal resource outage
Sequence num. gapsNumber of RTP packets that exhibited sequence number discontinuity
Payload reassembling errorsNumber of encountered payload boundary discrepancies caused by packet loss or parsing errors
Total dropped inner (errors)Number of decapsulated inner stream packets discarded due to errors in the packet format, payload integrity or an invalid header field values
Bad IP innerNumber of inner stream packets with an invalid IP header
Bad UDP innerNumber of inner stream packets with an invalid UDP header
Bad RTP innerNumber of inner stream packets with an invalid RTP header

NOTE: outer stream unlock causes unlock in all inner streams.

Monitoring inner STLTP streams

The “Inner layers” section presents statistics for the decapsulated inner streams:

  • Preamble
  • Timing and Management, and
  • Available PLP streams

The RTP-related statistics are the same for all RTP streams throughout the STLTP stack - please refer to the above description for details.

Additional fields, applicable to certain streams, are described below:

ParameterDescription
Bad payload CRCNumber of packets with payload checksum mismatch (corrupted payload)
Bad payload lengthNumber of packets with incorrect payload length
Bad payload structureNumber of packets with malformed payload (in cases where payload format can be validated)

ATSC3 Signaling and Timing streams

STLTP / “Signaling and Timing” provides information extracted by the device from the Preamble and Timing and Management streams of the current STLTP multiplex.

Figure 6 - STLTP Tab - Signaling and Timing

The following signaling stream content is presented on the UI:

  • Preamble
    • L1 Basic signaling: L1B for L1D, L1B for the first frame
    • L1 Detailed signaling: L1D channel bonding, L1D for the selected Subframe, and L1D for the selected PLP
  • Timing and Management
    • Timing and Management payload fields
    • Bootstrap timing
    • Per-transmitter timing

The corresponding UI sections are presented for your reference.Figure 8 - Signaling and Timing - Timing and Management.

Figure 7 - Signaling and Timing - Preamble

Figure 8 - Signaling and Timing - Timing and Management

ATSC 3.0 Services

STLTP / “ATSC 3.0 Services” provides list of the discovered Services, allows selecting a Service and presents detailed information on the selected Service.

Figure 9 - STLTP Tab - ATSC 3.0 Services

Available PLPs
The “PLPs” section shows the PLPs available in the current multiplex, the LLS and Channel bonding information, and indicates whether the PLP is currently selected for content processing.

Figure 10 - ASTC 3.0 Services - PLPs

The PLP selection is performed automatically by the device, as required by the Service discovery procedure, or to enable the payload processing for a Service selected by user.

Service discovery
The Service discovery is performed by the device automatically, as soon as the PLP baseband payload is successfully extracted by the ATSC3 listener, and the ALP transport stream is encapsulated.

Figure 11 - ASTC 3.0 Services - Services

During the Service discovery, the device performs round-robin PLP switching and analyzes the LLS signaling available in PLPs with LLS presence. The extracted information is populated in the “Available Services” table.

Click “Scan” button in order to manually re-initiate the Service discovery, or one of “Select” buttons, to select the corresponding Service for further processing.

NOTE: the current implementation allows only DASH/ROUTE services to be selected.

Monitoring the selected Service
Once a Service is selected, the device performs further payload decapsulation and presents detailed low-level statistics for the Service components:

  • Service Layer Signaling (SLS) information
  • DASH/ROUTE delivery details: TSI, component-to-IP stream mapping, PLP ID
  • Service elements, available as file downloads: FDT, SLS, TSID, MPD, and media segments as delivered by ROUTE/DASH

Figure 12 - ASTC 3.0 Services - SLS, Components, Service Elements

The DASH/ROUTE objects are constantly monitored for integrity and continuity. The device reports per-object statistics in the “ROUTE Object” table:

Figure 13 - ASTC 3.0 Services - ROUTE Objects

Streaming the selected Service
A client-side DASH/ROUTE player can be used to connect to the Avateq device and play the media content from the selected Stream. The device runs an additional web server on a separate port, which replicates a DASH/ROUTE media server behavior.

Follow the below steps to stream the selected Service:

  • In the Service Elements section, locate a link to the *.mpd file, which is the Media Presentation Description for the DASH player
  • On the host computer, provide this MPD link as a network resource for the media player

For example, the open-source VLC player (https://www.videolan.org/) provides DASH streaming capability. Click Media → Open Network Stream.. and specify the MPD link as the Network URL in the Network tab.

NOTE: at the time of writing, VLC did not provide support for AC-4 audio decoding.

Streaming one media component of the selected Service
The device provides an option to stream one of the available DASH/ROUTE media components (e.g. an audio or video track, subtitles, etc) via a dedicated HTTP session, for external monitoring or analyzing purposes. This is an engineering functionality, which does not aim to substitute the usual content playing with a full-featured DASH/ROUTE client.

The Media components available in the currently selected Service are listed in the “Media components” table, with their TSI and TOI of the corresponding Init object.

Figure 14 - ASTC 3.0 Services - Media Components

NOTE: please refer to the “ROUTE Objects” table for more details on the objects that correspond to a Media component.

Click the “Select” button, to enable streaming of the corresponding Media component, and access it via the HTTP link under the “Selected media component” section.

Only one component can be selected for streaming at a time.

Once the client HTTP session is established, the device will concatenate its Init and stream ROUTE objects, to form a playable stream. The content can be consumed by a media player (e.g. VLC) or downloaded as a file via a web browser.

NOTE: in order to terminate the file download, select another Media component, or another Service

Signaling and mapping statistics

STLTP / “Signaling and Mapping” provides ALP packet-level statistics and Low Level Signaling (LLS) information for the current STLTP multiplex.

Figure 15 - STLTP Tab - Signaling and Mapping Statistics

The “Packet statistics” section (Figure 16 - Signaling and Mapping - Packet Statistics) provides a breakdown of packet ALP types processed by the device since the monitoring was started, and the IP streams decapsulated from the ALP layer.

Figure 16 - Signaling and Mapping - Packet Statistics

The “Signaling” section presents the extracted Link Mapping Table (LMT), Low-Level Signaling (LLS) groups and elements extracted by the device.

Figure 17 - Signaling and Mapping - Signaling

The LLS elements can be downloaded as files (archived and plain), for offline examining. An element may also be selected for Showing as raw or formatted XML (Figure 18 - Signaling and Mapping - LLS Table).

Figure 18 - Signaling and Mapping - LLS Table

Packet capturing

STLTP / “Packet Capturing” allows capturing all IP packets decapsulated from ALP transport into a local *.pcap file on the device, and downloading the file for offline examining (for example, with Wireshark).

Figure 19 - STLTP Tab - Packet Capturing

The file is stored in the device's persistent memory and can be downloaded after a reboot. A series of network captures can be made, and the capture start timestamp is included in the file name, to simplify the further processing.

The “Capturing” section allows specifying the maximum file size and checking the current Capturing status.

Figure 20 - Packet Capturing - Capturing

The “Persistent file storage” section presents a list of files currently stored on the device and allows downloading and removing the files.

Figure 21 - Packet Capturing - Storage

STLTP alarms

Avateq devices support monitoring the deviations in the measured parameters and generating alarm notifications on registering an event occurrence, or in case the measured value is found beyond the set thresholds.

Several conditions and events specific to the STLTP monitoring are supported by the device as outlined in the following sections.

Configuring alarm properties
Alarm configuration is accessible through the Control panel page of the device web interface. Access the Control panel by clicking the gears in the icon bar on the device Dashboard.

Figure 22 - Control Panel Icon

Type your password into the Login prompt presented on a new page.

Figure 23 - Control Panel - Login Page

Access “Alarm Properties” page in the “Alarms” section of the navigation panel (Figure 24 - Control Panel - Alarms Menu).

Figure 24 - Control Panel - Alarms Menu

The Alarm Properties (Figure 25 - Control Panel - Alarm Properties) page allows selecting an alarm from a drop-down list and configuring its settings.

Figure 25 - Control Panel - Alarm Properties

The following settings can be configured for each alarm:

  • Alarm Enabled: enable or disable alarm detection
  • Trap Notification on Alarm: enable or disable SNMP trap/inform
  • Email Notification on Alarm: enable or disable email delivery
  • Shop Pop-up Window: enable or disable pop-up window on device Dashboard
  • Integration time: specify a period of time in seconds, after which the alarm condition is deemed Set or Cleared, respectively. This is helpful for debouncing intermittent alarm conditions and avoiding excessive notifying on fluctuating readings
  • Alarm Severity Level: select the severity level attached to the notification message

NOTE: click “Update” button to save your changes, before switching to another alarm from the drop-down list.

Alarm notifications can be delivered by the device as:

  • Emails to a list of recipients
  • SNMP trap or inform messages
  • Publishings to MQTT topic

NOTE: each notification delivery subsystem needs to be enabled and configured in the corresponding section of the device Control panel.

Alarms specific to STLTP
The following alarm conditions are implemented by the STLTP monitor:

  • STL packet loss (outer, FEC1, FEC2): raised when the rate of missing sequence numbers per second in the corresponding stream exceeds the configured threshold
    • NOTE: refer to the “Loss rate, pkt/s” in “Ingress stream statistics” table
  • STL data rate below (outer, FEC1, FEC2): raised when corresponding stream gross data rate in kB/s is measured below the configured threshold
    • NOTE: refer to the “Data rate, kB/s” in “Ingress stream statistics” table
  • STL preamble stream unlock: raised when STL Preamble stream inconsistency or discontinuity is detected by the monitor
    • NOTE: refer to “Monitoring inner STLTP streams”, “Stream interruptions” counter
  • STL timing / management stream unlock: raised when STL Timing / Management stream inconsistency or discontinuity is detected by the monitor
    • NOTE: refer to “Monitoring inner STLTP streams”, “Stream interruptions” counter

NOTE: in devices with RF monitoring capabilities, STLTP alarms are available only when the device operates in ATSC 3.0 Standard.

Configuring thresholds
Some alarms have associated Threshold settings, which represent an upper and/or lower limit for the measured parameters.

Configure alarm thresholds by navigating to the “Thresholds” page in the “Alarms” section of the navigation panel.

Figure 26 - Control Panel - Thresholds Menu

Thresholds specific to the STLTP alarms are outlined in Figure 27 - Control Panel - Alarm Thresholds.

Figure 27 - Control Panel - Alarm Thresholds

  • STL packet loss rate High (Outer, FEC1, FEC2): specifies the maximum allowed packet loss for the corresponding stream, by exceeding which the alarm is raised
    • NOTE: set to 0, in order to raise an alarm on any packet loss
  • STL data rate Low (Outer, FEC1, FEC2): specifies the minimum gross data rate in kB/s for the corresponding stream, below which the alarm is raised