Alan Robinson explains the technical concept of IPTV and why testing a service properly could mean the difference between happy or disgruntled viewers
By now, if you haven't heard of Triple Play or IPTV, there's a fair chance you've been living under a rock. Every major and almost every minor service provider seems to have either announced plans for IPTV deployments or is in the process of drawing them up.
With an average subscriber to a digital satellite service spending over â‚-500 a year, it's easy to see why the traditional wireline operators are anxious to get revenue figures like these from their existing subscriber base. In addition, video-on-demand and pay-per-view services can as much as double these average revenue figures. So the financial rewards are obviously there. Also, high-speed Internet connections have an appeal that is limited to the technically literate in society so there's a limit as to how much broadband Internet products they can sell. On the other hand, television has a far wider or almost universal appeal so the market is so much larger.
But before service providers' eyes glaze over and they start drooling thinking about the revenue, there are quite a number of technical difficulties to resolve before the money starts rolling in. And to underline that, there have been a number of widely publicised trials that failed to turn into deployments, including a number of delays in deployment of over twelve months. These have been very costly, not only in terms of loss of face but also in crude financial terms, too.
So what can go wrong? Well, put simply, lots of things. Firstly, the DSL model used by operators is one of high-bandwidth, which is good for IPTV but with the downside of contention (ie, lots of users all using the same bandwidth). Additionally, very little about Quality of Service is mentioned in terms of broadband products and for a good reason; usually, there isn't any. IP is inherently unreliable but TCP helpfully handles problems like mis-ordered or missing packets, while latency and jitter aren't usually obvious to a web, e-mail or P2P user. But for an IPTV user, the result can be detrimental to their viewing enjoyment.
We're also a pretty tolerant bunch when it comes to IP over DSL. If our web page is a little sluggish, we don't really get worked up about it but we have zero tolerance when we're watching TV. With the advent of cable TV systems, digital satellites, DVDs, etc, we expect our viewing to be, well, picture perfect. Small artefacts or frozen frames are simply taboo.
Because MPEG frames (the encoding scheme for most IPTV solutions) are larger than Ethernet frames, losing a single Ethernet packet may mean that none of the MPEG frame can be displayed. It may be part of an advert that isn't displayed but what if it's the split second that decides if the winning goal was onside or offside? You can wear out your viewers' patience pretty quickly in those cases.
And just in case you thought things couldn't get worse, research has shown that most people don't report technical problems with their viewing enjoyment; they simply lose patience and churn to another provider and that's a very expensive event for the operators. They've spent considerable money getting the subscriber added to their service in the first place and now that investment's wasted.
Most analysts would agree that the key thing for operators to do in order to keep revenue high is to keep the churn rates down. There always will be a residual number of users that churn, but outside of this group, the quality of experience that a user receives is a key deciding factor in staying with the service or migrating to another supplier. One point that absolutely can't be stressed too much is to ensure that the test methodology is correct. Up to now, telecommunications equipment has typically been tested on the blast basis. Fire in wire-rate 64 byte packets and if they all get through the far side, then you're good to go. This is far too simplistic for the modern network where users are only interested in how their real-world applications (web, e-mail, IPTV, VoIP) run on the network and don't care how good contrived data sets that only ever occur in labs, function on the network. So make sure you're running real-world data. Don't simulate the traffic;emulate the traffic and there's a key difference here.
Another drawback to earlier testing methodologies has been the generalisation problem. Because it's difficult to measure simultaneously large numbers of statistics from different endpoints -- and also visually represent these figures in such a way that it's easy to see where problems lie -- the temptation has been to take one large set of measurements and report an average. Other than not testing at all, nothing could have greater risk of encouraging churn. The problem is that if there are relatively few data points that indicate poor service, then these get lost in the overall noise of the good service. The danger is, and we've seen this in 'real' deployments, that there is always a group of users that get poor service. In other words, the lowest ten per cent of users get blocky video, frozen frames or have too lengthy a delay when changing channels. These users churn and are replaced by other users formerly from the 'good' group. The operators monthly churn rate is high and no one knows why.
In the remainder of this article, we'll take a look at the types of things that can go wrong and how testing can make sure that they stay in the lab and not in the network. But first it's probably worthwhile familiarising ourselves with the type of traffic that we can expect on IPTV-enabled networks.
IPTV is sent over IGMP in most networks. IGMP (Internet Group Management Protocol) allows for multicasting (point to multi-point). Put very simply, a server (in this case a Video Server) transmits each separate TV channel as a single multi-cast stream with a special type of destination IP address. If a viewer wants to receive this stream, it sends an IGMP 'Join' message containing this special destination IP address. The network infrastructure then directs a copy of this stream to the user's Set-Top Box (STB). This is a very efficient use of bandwidth, because it doesn't matter how many 'viewers' of this stream there are; a single copy is sent through the infrastructure and this is split only where it needs to be split into multiple copies. The network infrastructure effectively also keeps a count of the number of viewers. As viewers issue IGMP 'leave' messages (ie, they change channels and no longer view this one), the count is decremented. If it reaches zero, then this portion of the IPTV network can elect not to split and transfer the packets, thereby further reducing bandwidth requirements. Compare this with a unicast (point to point) mechanism. For each viewer, there would be a separate connection to the Video Server. This simply wouldn't scale.
When a viewer wants to change TV channel, their STB issues an IGMP 'Leave' message for the TV channel it no longer wants to receive and a 'Join' message for the TV channel it has now switched to.
Usually, video is transmitted as an MPEG-2 stream. (More recent advances in compression have resulted in MPEG-4 being more widely deployed and this trend will likely continue.) An MPEG-2 stream consists of a number of different types of frames. Greatly simplifying, in order to provide compression, each frame is effectively a compressed difference to, or delta of, the previous frame. However, if the initial frame or one of the deltas was lost for any reason, it would be impossible to decode the picture. In order to overcome this, MPEG-2 calls for an 'I-frame' to be inserted at regular intervals (usually about 15 frames or less apart). This is a full picture with no dependencies on any previously received (and potentially lost) frames. If a user 'joins' the stream, then he has to wait for the next I-frame before a picture can be rendered on the television. MPEG usually is encoded at between 25 and 30 frames per second, so it could take up to half a second before the TV can display an image. Using a larger number of incremental frames between I-frames reduces the bandwidth required to send a video stream, but this has the disadvantage that it also implies the potentially longer time it can take to change channels or more generally, for the stream to recover its integrity (ie, display a perfect picture) when an error has occurred.
Because the size of the MPEG frames is much larger than Ethernet packets, a single MPEG frame has to be carried in multiple Ethernet packets. If one of these is lost, then the MPEG frame may not decompress correctly or fully. Subsequent frames depend on this frame until the next I-frame is received, so it's clear that a missing, corrupt or mis-ordered frame can have far-reaching consequences.
Traditional testing involves 'blasting' the system with packets. This isn't sufficient for testing IPTV systems. Packet loss can be measured by these techniques but not the effect of the packet loss, as some packets' loss may be more acutely felt than others. One of the most common reasons for loss in these types of networks is 'interference' from other IP traffic. If the kids are upstairs gaming or downloading MP3s, the detrimental effect on the quality that can be obtained on the television downstairs is difficult to overestimate. Modern test solutions give access to real live traffic (like web, P2P or e-mail) that can be mixed with IPTV to see if any losses occur as the traditional IP traffic's volume is increased.
We've already seen that it takes some time for a valid picture to be seen on the television when an IGMP stream is 'joined'. In addition to this, we've talked about the network infrastructure only having to split and send streams that one or more STBs are watching. So, if there are no current viewers for that stream, then potentially the network may have to go a number of hops before it can find a place where the split can take place. The zap rate measures how long it takes to change channels on the TV and have a valid picture to watch. It's surprising how critical a measure it is for the viewing public. With the growth in the number of channels that are provided in even the most basic of packaged offerings, perhaps it's not too difficult to understand why. Zapping through the channels looking for something worth watching is a common enough occurrence in most homes, and the longer it takes for each channel to change dictates how long it takes for us to find something more interesting to watch.
Modern test systems allow the user to measure the zap rate by joining and leaving channels in a controlled manner and collating the statistics for each individual viewer over long periods of time. Analysing all of this data will allow the tester to determine if any viewer's 'zap rate' went outside of acceptable bounds.
Suppose there's a big match on. The half-time whistle blows -- what do we do? Lots of people start changing channel. They may want to see something more nteresting than the usual collection of talking heads offering half-time punditry or catch the scores from another match on another channel. Whatever the reason, the numbers who switch channels at this point equates to a huge spike. This can stress an IPTV network terribly as it goes from a steady state of long-term viewing to a huge series of changes. A modern test system can allow the operator to generate these half-time scenarios, where a steady state is interrupted with large numbers of channel request changes to stress the infrastructure. Again, it's vital to measure the effect on a per-user basis or the bad service effects can be averaged out and lost.
These are just a few of the major 'must-check' problems that should appear on any operator's checklist before deploying. Unfortunately, there are quite a few more and we haven't even touched on perceptual video quality or more worryingly, the whole new raft of security issues and problems that have been created by IPTV. It's probably fair to say that IGMP was built with little or no thought put into security issues, the potential for fraud or Denial of Service threats. That's a whole other area of testing that only now is beginning to take place, so get testing and don't leave it to the viewers! n
Alan Robinson is Chief Executive and co-founder of Shenick Network Systems. He can be contacted via tel: +353-1-236 7002