OTT Monitoring: keeping it simple and useful

Bob Pank#

Author: Bob Pank#

Published 1st October 2012


Introduction
OTT is generally understood to mean a technique where the transmission of video to the subscriber is based on the same underlying methods as those currently being used to serve out web pages on the internet today.
The Over-the-Top name refers to the potential of this technology for bypassing existing traditional television distribution methods by piggybacking itself on top of existing broadband internet connections.
The key difference to traditional television delivery is the provision for a two-way IP pipe to the subscriber. The two-way pipe uses TCP to handle data loss through packet re-transmission. Further protocol layers allow for a seamless change of gears between different bandwidth profiles in order to adapt to the average bandwidth capacity of the broadband link. For this reason OTT is also often referred to as adaptive bitrate streaming.
Over-the-Top delivery promises television quality across un-managed internet infrastructure. Whether this matches the quality we have come to expect from our television depends on how well the service is implemented and monitored from studio to subscriber.
There is currently a large amount of activity in the OTT area. In many ways it is comparable to the way digital television and MPEG was prior to its standardization in the early 90s.
Four major flavours of OTT technology are being applied as of today:
Microsoft™ Smoothstream(tm)
Apple™ HLS
Adobe™ HDS/Flash
MPEG-DASH
The three first ones are vendor driven implementations whereas the fourth is an MPEG standardisation effort.
The OTT infrastructure
A typical OTT architecture consists of an ingress head-end, multi-profile encoders, segmentation servers, the content delivery networks (CDNs), local ISP's where the end-customers get their broadband connection from and finally the end user viewing the service from devices such as tablets, OTT-enabled set-top boxes or smart phones.
To uphold television delivery quality some form of monitoring throughout this chain is recommended. Natural monitoring points are where the areas of economic responsibility meet - the demarcation points.
Below is a list of suitable monitoring points in any OTT deployment:
*Output of Origin / segmentation server
*At strategic points throughout the CDN
*At ingress points to local ISP's subscribing to the OTT service
*Inside end client devices
Active OTT monitoring
The implementation below shows how OTT can be actively monitored at any point in the delivery chain.
The first content piece is called VoD and is stored content on a server. This could be recorded television or movies. The format is Apple HLS in this particular case.
The second service being monitored is a live OTT feed called Olympics LIVE. In this particular case the format is Adobe HDS. The stream has been expanded for more measurement details.
The only large difference between Live and Stored content is that in the live case the sequence numbers of the chunks are updating whereas for the stored material the sequence numbers are static.
The only configuration needed to enable monitoring is the URL of the OTT stream. In addition an alarm template is defined to say when to alarm in case of faults.
A chunk is downloaded for each available profile for the service. The download duration is checked against a configurable percentage value. For example - if the download duration is larger than 80% of the actual (real time) chunk duration of 10 seconds then an alarm is generated. The colour of the measurement is green, yellow or orange depending on the severity of the alarm. The last 120 minutes of measurements are logged as colour bars in order to easily visualise profile health over time.
We see from the picture that the largest profile of 3.66Mbps is currently experiencing download issues. We also see that in the last 2 hours only the two lowest bandwidth profiles are without errors (no red bars).
The sequence numbers on live streams are also checked up against a user definable maximum allowed sequence age. If the sequence numbers are older than the threshold setting then this usually indicates a problem with the Origin segmentation server having frozen up. If so an alarm is generated. This is a common issue in real deployments.
Currently up to 18 different alarms can be generated split into 3 main groups depending:
*Transport Errors (e.g insufficient bandwidth for profile)
*HTTP errors (e.g HTTP 404 - not found)
*XML structure errors (e.g static manifest file for longer than threshold)
Tying it together
The method described above of actively testing at one point in the OTT delivery chain can be expanded to a whole system by deploying multiple monitoring points.
The OTT monitoring devices report upwards to an overlying system that registers alarms and counts Errored Seconds at each monitoring point. Errored Second is well known from the telecommunications sector and is defined as an interval of one second during which any error whatsoever occurred.
By comparing counted Errored Seconds at each monitoring point in the OTT distribution architecture it is possible to quickly identify problem areas in the distribution chain.
Using this technique it is possible to easily identify whether issues arise at the Origin server, inside the CDN, at a particular local ISP or at the customer premises. Quickly identifying this translates directly into expenses saved in the form of less reported trouble tickets, less truck rolls, less churn and more customers.

Related Listings

Related Articles

Related News

Related Videos

© KitPlus (tv-bay limited). All trademarks recognised. Reproduction of this content is strictly prohibited without written consent.