IPTV QOS is a topic that has become a confusing issue for many businesses, let’s clear it up.
Quality Of Service, being something new oftens makes people automatically think of using pre-existing measurement techniques. This basic starting point for QOS measurement is where most of the confusion is generated.
In the same way that when companies began moving from Analogue to digital broadcast signals, the natural tendency of the existing engineers was to want to measure the new digital signal by converting it back to analogue and then using their existing equipment. IPTV QOS has caused a lot of the same methodology, whereby engineers with a network background want to measure network statistics, and engineers with a video background want to measure video statistics. The former (network engineers) can happily take their measurements from the existing network infrastructure, but get no feeling for what packets on the network relate to what video signals. The video people want to convert the IPTV signal back into its digital video format (converting it from IP to Video), which really misses the point that all you’re really finding out is how well the converting device works (a piece of test equipment won’t be comparable to the way a STB (set top box) would decode the signal. Thus, you have two separate approaches to the same problem – neither of which is really ideal.
Now, there IS a place for existing test equipment (network test equipment is great for data traffic as it always was, and Transport Stream (digital video) analysers are great at your Head-End (where the video content originates) in order to confirm that the video into your IP network was good), so it’s not time to throw it away, it’s just not the right tool for IPTV QOS.
With those comments out of the way we can move forward (it’s difficult to move when you still have one foot in your old mindset).
Depending on who you are, you could very well be concerned with just one part of an IPTV system or the entire system, so we’ll break it into the core problem and what that means at each place in the network (we’ll assign the network 4 test points: 1) Head End 2) Core Network 3) Network Edge 4) Customer Home).
1) Head End.
This might concern you if you are responsible for creating, providing, or receiving video from a Head End.
A Head End can consist of anything from professional video encoders to VOD Servers (Video On Demand), and could be in one of many video formats, compression types, bitrates etc. They could be Unicast or Multicast, UDP, RTP or a proprietary mechanism (As in the case of MSTV).
Whatever the situation, it’s a good idea to take steps to ensure that the Head End is robust and that the video encoding devices are reliable. A problem at the Head End affects everyone down the line, right to the customer. (we’ll assume that various ‘redundant’ systems are in place to avoid this type of problem where possible)
Having built the Head End system with a robust architecture, the last thing (and the important one for us) is to monitor the Head End IP video flow output to ensure that this first point where the video is IP encapsulated has been done adequately and that the rest of the IPTV infrastructure can rely on this input.
Note: One common mistake at this point (and elsewhere) is to have some sort of round-robin system in place where not all of the video streams are measured at the same time – this should only be done if absolutely necessary as one of the ‘issues’ with the nature of IP delivery over a network is that impairments caused to the signal in the IP domain have a non-deterministic affect on the video flows. This means that while you’re looking at 5 of 100 flows, you could be having problems on some random number of other flows which you wouldn’t see – unless you monitor ALL flows simultaneously.
2) Core Network.
Hopefully the steps above will have been done, so if you’re concerned with the core network, your main work involves doing your own verification that the flows coming into your network are OK (you can’t rely on the Head End provider to do this for you, and it’s much easier to be able to get out of the spotlight when problems occur if you can easily confirm your input), and ensuring that the passage across the network doesn’t cause any loss or excessive jitter (the only 2 components that can stop the network getting your video to the end intact.
Now that we’re in the IP domain, this issue of packet loss is ultimately the number 1 thing to look out for (any IP packets lost WILL mean video content loss since all mechanisms insert video packets into IP packets for delivery, some even contain up to 7 video packets in one IP packet). However, with that said, every network device (and ultimately the STB) have buffers which means that excessive jitter can cause packet loss. Since we REALLY don’t want packet loss, this means jitter is just as important to us when monitoring our system.
The real kicker here is that if you’re from the old school of IP monitoring you’ll be pretty happy with what I’ve said so far – but there’s one thing which makes thing a little more ‘interesting’. It is perfectly possible to lose ‘media’ packets but NOT IP packets. Whenever an infrastructure includes elements like multiplexers which combine the mpeg video and ‘MUX’ several streams into one, if you’re not doing some form of ‘deep packet inspection’ (looking into the media headers to ensure the continuity counters are correct) you could have no IP packet loss, but still have video problems. This basically means that your solution cannot come from one approach or the other, but needs to do the monitoring in the IP domain while still confirming that the media packets are intact. abonnement iptv