Home >> October 2010 Edition >> SatBroadcasting™... From The Satelllite To The STB
SatBroadcasting™... From The Satelllite To The STB
author: Simen Frostad, Bridge Technologies


I posed this question in a previous article I authored for SatMagazine...

Your content is downlinked from satellite, and your infrastructure is up and running, ready to deliver to an eager subscriber base — what could go wrong?

bridge_g1_intro_sm1010 The answer — then, as now — is there’s plenty to go wrong. My question also contained a tacit assumption, an assumption that most operators also make when they download content from satellite without monitoring the quality and integrity of the signal —­ things only start to go wrong once the content is downloaded and travelling through the delivery infrastructure. Few operators establish specific monitoring procedures for the incoming satellite signal. Why is that? The old IT maxim — garbage in, garbage out ­— should provide enough warning here.


Broadcasters and digital media operators increasingly understand the requirements for monitoring the delivery chain and there is a growing appreciation of the importance of an integrated monitoring approach. It’s simply not viable to operate separate monitoring ‘silos’ for the broadcast and IT links of the chain. More and more broadcasters are coming to understand that end-to-end monitoring technology that embraces the broadcast and IT domains is the way to ensure efficient fault identification, tracking, and resolution. It is really remarkable how many broadcasters and media operators simply take the satellite signal on trust, and ignore it in their ‘end-to-end’ monitoring.

idirect_ad_sm1010 To be really worthy of the description ‘end-to-end’, a monitoring solution should provide a transparent view of the data from the satellite to the set top box (STB), with the ability to focus in on any error, anywhere it occurs, and see it in the context of the entire chain. If a broadcaster leaves the satellite signal out of the monitoring solution, the engineers are handicapped when trying to trace the source of a problem because the signal from the satellite may be the cause of errors that manifest themselves much later in the delivery chain.

This signal has usually been through quite a lot already! The media will have been encoded and sent to a MUX system, and from there, via a microwave link to a satellite uplink center, where it’s probably decoded and re-encoded in a new MUX. The signal is then uplinked to the satellite, downlinked, and descrambled. It’s quite an act of faith for the broadcaster to leave the signal unmonitored after all of that technical activity. Without including the satellite signal in a system-wide overview, maintenance staff attempting to determine where the cause of a fault lies may be completely misled.

The redundancy strategy many headend operators have resorted to as a remedy — in order to maintain service on an alternative infrastructure in the event of failure — is not only expensive, but also fails to get to the root of the problem if the fault is at the transponder. Unless the satellite is monitored, even switching to an alternative path would not remedy the failure.

Critical service-affecting problems can be introduced from changes in the satellite signal which are not in themselves errors, but which will cause severe disruption unless identified by the monitoring system. Take as an example a sports network broadcasting in many different languages across Europe: If a new language is added, the changed PIDs (packet identifier) could result in complete loss of audio across all the channels received from the network. Without the ability to include the monitoring data from the incoming satellite content, engineers searching for the cause of the problem would be likely to spend a lot of time barking up the wrong tree.

The philosophy of end-to-end monitoring that takes in both broadcast and IT/IP technology would be flawed if it did not provide a solution for monitoring the signal from the satellite, and for monitoring the quality of service at the STB. When service-affecting problems occur, operators need to see the big picture across the entire delivery chain, in order to track and resolve issues quickly and to restore service levels to the subscriber.

bridge_g2_microvb_sm1010 The VideoBRIDGE monitoring system provides for both ends of the chain: at the satellite, with the VB270 probe, and at the STB, with the microVB. The key advantage of these two probes, despite the fact that they sit so far apart, is that they form part of a completely integrated system in which all of the component probes contribute to the overall view of the delivery chain and provide an all-embracing monitoring and analysis environment.

With the VB270, broadcasters and media operators can monitor the QPSK/8PSK signals found in DVB-S and DVB-S2 satellite transponders — a fully configured probe can provide real-time monitoring and alarming for two QPSK/8PSK RF inputs, 10 IP MPTS/SPTS multicasts, and one ASI TS input.

bridge_g3_IPprobe_sm1010

Analysis using the open industry standard ETSI TR 101 290 is performed in parallel for QPSK/8PSK inputs, the ASI input, and the IP input. If the VB220 is used as a master card, the IP monitoring capacity is increased to support 260 MPTS/SPTS multicasts. The built-in round-robin functionality allows sequential analysis of multiple QPSK/8PSK multiplexes, making it possible to monitor a complete satellite using a single VB270.

In addition to the TR 101 290 parameters monitored and analyzed, the VB270 also provides comprehensive RF parameter monitoring that allows the operator to see signal degradation over time — one of the causes could be drifting alignment of the antenna itself, or to offer a true customer example, the growing and thick foliage of nearby trees. Many of those problems can be hard to understand without continuous monitoring of the signals in question.

At the other extreme of the delivery chain, the microVB is the industry’s first viable solution for continuous, real-time monitoring at the STB. As the subscriber is often the first to flag up a problem, and service affecting problems can be generated anywhere in the delivery chain from satellite to the STB itself, any monitoring system that cannot provide comprehensive data on the subscriber experience is a system that limits the effectiveness of the support and maintenance operation.

The microVB is a miniaturized, remote monitoring and analysis probe — small enough in size at 75mm x 20mm, and light enough to be delivered to the customer via mail, and robust enough to arrive intact. After a simple, plug-and-play installation the subscriber can complete in a couple of minutes, the microVB automatically locates a server on the operator’s VideoBRIDGE monitoring network and begins sending data, enabling deep packet inspection without requiring a technician to visit the customer’s home to install the device or diagnose problems.

Data from both the STB and the satellite input (together with data from any other VideoBRIDGE probes installed elsewhere on the network) is collated and presented in advanced graphical displays that immediately highlight potential or actual problems and assist rapid resolution, by giving engineers the ability to trace the source of errors, wherever they occur in the chain.

bridge_g4_end_sm1010 Equipped with the ability to see from one end of the delivery chain to the other, operators have the tools to ensure a very high quality of service for their viewers. But even though the tools are now available, making effective use of them does require an understanding of the potential for service affecting problems to be introduced into the system from the earliest stages — in the content downloaded from satellite — or directly at the end of the chain, in the STB. Without that end-to-end integrated monitoring system, operators can’t be certain of accurately tracking down the source of a problem quickly and efficiently.

Further information at:
http://www.bridgetech.tv/