ETS TR 101 290 has been a trusted MPEG-2 transport stream monitoring solution for the broadcast industry during the last 20 years. The specification is well known for its ability to detect issues in the Transport stream that point to problems like synchronization of packets, CC errors, PCR stability and synchronization and many more. An Industry veteran or skilled professional can read an incident report and understand what the impact of such event to video, audio and services without the need may be to decode the stream back to baseband.

When the specification was written and during its revisions of enhancements, the industry was still using well engineered and crafted ASI, Satellite, ATM or Dark Fiber networks. No one imagined the explosion of Video Over IP and the types of mediums we are using today.

Today’s networks are more challenging; with no bandwidth guaranty, multi-tenant, changing on a minute/hourly/daily basis and then there is the Cloud challenge. How can the ETS TR 101 290 keep up with these?

Yes, it is still a viable tool to alert us of a problem; lost packets can cause visual/audio effects like freezing, tiling and choppy video/audio. But the question is: how to detect the root cause of the issue? What do I need to do to fix the problem from happening?

Moreover, in the past we thought that bytes and small TS packets can get lost, so Priority 1 ETS TR 101 290 events could cover these events, but with IP one can lose 10-20 IP packets this can be 70 to 140 TS packets at once. How does ETS TR 101 290 show us this information?

Let take a look into some common network events:

Network Jitter, Jitter is a very common artifact of the IP network ( 5G, MPLS, Internet and Cloud ) and IP receiver may deplete its input buffer causing starvation, how will ETS TR 101 290 give us information on that? What was the magnitude of the jitter? Where was it formed and on which network? Is it a one-time event or continuous?

Network Congestion, network congestion is created in network elements when the incoming or outgoing queues start to overfill. This causes the network element to start dropping packets or chunks of packets in flight. This will result in the receiver trying to recover lost packets by some way of Forward error correction or ARQ, but how the ETS TR 101 290 comes to our assistance – it’s not.

Network route change can cause in-flight packet loss, jitter changes and latency increase. Route change is very common in cloud and open internet, but also may happen on a MPLS network (obscured from the user ). ETS TR 101 290 can only detect the outcome but not the reason behind.

What is needed?

In medicine we try to see the external signs, but we also do active measurements of the body, doing blood works, measuring temperature, blood pressure, X-Ray, Ultra-sound and CT. We do all these tests to better understand the problem and treat it directly. Why should the network issues be different?

Alvalinks CloudRider is trusted by many to perform precise network discovery, testing and alarming to find the network events which are short term or brewing in the dark. It was designed by broadcast and networking team with the task of shading flashlight into the network events that eludes the standard IT team and media alike. While it does not replace ETS TR 101 290, it gives more information and points to the causation.

See a capture example:

One can immediately recognize in the Hops chart that the network is changing its route, every route change causes RTT change, Packet loss and jitter (not seen in the capture ), all events are time correlated and can trigger an alarm or correlation to external alarm reported time.

Want to learn more?

Reach out to Alvalinks: [email protected]