Determining IPTV QOS (Quality Of Service).
IPTV QOS is a topic that has actually ended up being a confusing problem for many organizations, so let’s clear it up.
Quality Of Service, being something new oftens makes individuals immediately think about using pre-existing measurement methods. This basic beginning point for QOS measurement is where many of the confusion is produced.
In the same method that when business began moving from Analogue to digital broadcast signals, the natural tendancy of the existing engineers was to wish to determine the new digital signal by transforming it back to analogue and then using their existing devices. IPTV QOS has caused a great deal of the same method, whereby engineers with a network background wish to measure network stats, and engineers with a video background wish to determine video stats. The previous (network engineers) can gladly take their measurements from the existing network facilities, but get no feeling for what packets on the network connect to what video signals. The video individuals want to convert the IPTV signal back into its digital video format (converting it from IP to Video), which truly misses out on the point that all you’re truly finding out is how well the transforming gadget works (a piece of test equipment won’t be similar to the method a STB (set top box) would decode the signal. Thus, you have 2 separate approaches to the same problem – neither of which is really ideal.
Now, there IS a place for existing test equipment (network test devices is excellent for data traffic as it always was, and Transport Stream (digital video) analysers are great at your Head-End (where the video material comes from) and other video aggregation points in order to verify that the video into your IP network was excellent), so it’s not time to throw it away, it’s simply not the ideal tool for IPTV Quality Of Service.
With those remarks out of the way we can progress (it’s hard to move when you still have one foot in your old state of mind).
Depending upon who you are, you could extremely well be worried about simply one part of an IPTV system or the whole system, so we’ll break it into the core problem and what that indicates at each location 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 worry you if you are responsible for developing, supplying, or receiving video from a Head End.
A Head End can consist of anything from expert video encoders to VOD Servers (Video As Needed), and might be in among lots of video formats, compression types, bitrates etc. They could be Unicast or Multicast, UDP, RTP or a proprietary mechanism (As when it comes to MSTV).
Whatever the scenario, it’s a good concept to take steps to ensure that the Head End is robust which the video encoding devices are reputable. An issue at the Head End impacts everybody down the line, right to the customer. (we’ll assume that different ‘redundant’ systems are in location to avoid this kind of issue where possible).
Having built the Head End system with a robust architecture, the last thing (and the important one for us) is to keep track of the Head End IP video circulation output to make sure that this first point where the video is IP encapsulated has actually been done effectively which the remainder of the IPTV facilities can rely on this input.
Keep in mind: One common error at this point (and somewhere else) is to have some sort of round-robin system in location where not all of the video streams are determined at the very same time – this ought to just be done if definitely necessary as one of the ‘concerns’ with the nature of IP shipment over a network is that impairments triggered 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 issues on some random variety of other flows which you wouldn’t see – unless you monitor ALL flows at the same time.
2) Core Network.
Ideally the steps above will have been done, so if you’re interested in the core network, your main work involves doing your own confirmation that the circulations entering into your network are ok (you can’t count on the Head End service provider to do this for you, and it’s much easier to be able to leave the spotlight when problems take place if you can easily verify your input), and ensuring that the passage throughout the network does not trigger any loss or extreme jitter (the only 2 parts that can stop the network getting your video to the end undamaged.
Now that we remain 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 place video packets into IP packets for delivery, some even include approximately 7 video packets in one IP package). However, with that stated, every network gadget (and ultimately the STB) have buffers which suggests that extreme jitter can trigger package loss. Given that we TRULY don’t want package loss, this implies jitter is simply as essential 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 quite delighted with what I have actually said so far – but there’s one thing which makes thing a little bit more ‘fascinating’. It is perfectly possible to lose ‘media’ packets but NOT IP packets. Whenever an infrastructure includes aspects like multiplexers which integrate the mpeg video and ‘MUX’ a number of streams into one, if you’re not doing some form of ‘deep package inspection’ (checking out the media headers to guarantee the continuity counters are correct) you might have no IP package loss, but still have video issues. This essentially implies that your solution can not originate from one technique or the other, however needs to do the tracking in the IP domain while still verifying that the media packages are intact.
This additional complication is among the things that many test equipment producers haven’t accounted for, normally due to the truth that this is still a relatively brand-new field and many equipment suppliers are focused on producing ‘functions’ instead of addressing the consumer issues to deliver advantages which in fact provide the robust services needed.
3) Network Edge.
As previously, our very first action is to verify our input is great by keeping an eye on all flows at the same time for jitter and package loss and then making sure that the ‘last mile’ system to the client house is as robust as possible.
Given that this action could easily involve conversion from IP to RF (cable television business us RF (Radio Frequency) signals rather of the copper or fibre cables that many network equipment uses, any test devices may require an appropriate interface for this (the most typical user interface here is QAM (Quadrature Amplitude Modulation) of which there are 3 primary type (they’re really called ‘Annex’s’) Annex A, B, and C for United States, Europe and Asia.
So depending on your infrastructure here, you might or might not have an IP network to the client home.
4) Customer Home.
The final, and some would say the most crucial part of the system.
As previously, we need to examine our input (the IP video flows that will go to the clients STB). Since we’re speaking about IP, once again this is everything about the jitter and packet loss that has struck those video flows on their journey to this house. Because we inspected the video quality as it was encoded at the head end, we understand that as long as the jitter isn’t too much for the STB to cope with, and there’s no package loss – the video will be exactly as it was when it was encoded.
If you’re wondering how to navigate this – there are devices suppliers with devices that go IN the client home and adstract the workload from the STB and even some that let the customer press a button to signify when THEY saw an issue (regardless of what your test equipment may or may not have actually suggested – who says you need to imitate a client experience).
There – Pretty simple really.
That’s true, however in genuine life most companies do not own, control or perhaps have access to the whole system. This makes presenting an IPTV release a little of a problem unless you comprehend the concerns and have the suitable test devices (remember, some individuals still have one foot in the network or video world of old).
When business do have access to large parts of the system or are dealing with friendly business that do, this headache can get an entire lot much easier when the equipment being utilized can have its data fed into a central video tracking system. This method, the 2 typical issues of 1) Where is the problem 2) Is it an IP problem, show up at a glance and much wasted time and effort simply specifying where you even know where the issue is can be prevented.
When it comes to wishing to measure the quality of the system, there are a number of standards for assessing IPTV, the most typical are 1) V-Factor 2) MOS 3) MDI.
1) V-Factor.
V-Factor is a system that uses Moving Photo Quality Metrics (MPQM) research to try and mimic what a human would have chosen the video quality was like.
This is an interesting technique and is one way to approach the issue, but needs a lot of processing, can not realistically be done across the majority of the network (considering that the processing work is heavy, this does not lend itself to ‘core’ or ‘head end’ tracking), so may work as a helpful measurement to integrate into STBs.
Because we’re taking a look at a holistic IPTV QOS ( Quality Of Service )method, just a monitoring option that provides us the huge photo aswell as the detail will do.
2) MOS (Mean Opinion Score).
Again, this metric is designed to try and provide an approximation of what a human would see.
As with the V-Factor, it’s a cool concept and technically excellent however does not inform us what is wrong with the system (it’s nice to have a quality ‘score’, however in truth we need to know what to DO about a ‘poor’ rating).
3) MDI (Media Delivery Index).
As the name suggests, we get a metric that inform us something about the shipment. (xx: yy where xx equates to the cumulative jitter and yy equates to package loss) This time, instead of trying to evaluate the video and ‘rating’ it, we get information about the jitter and package loss at the point being determined. While it may not study the translated video signal, it does inform us how well the video has been delivered – which if you remember is really the most crucial thing if it was encoded effectively.
MDI is an apporiate metric at any point in the system and would let us know right away if there was a shipment issue. Considering that the MDI values are based upon the bitrates of the video streams, this also offers us some actually helpful details about how various streams will be affected by our network (for example, if we’re currently running 50 SD (Basic Definition) Streams and we wish to change them with HD (High Meaning) streams, a V-Factor or MOS rating at some time in our network won’t inform us what to expect, whereas MDI metrics will let us understand how much distinction the network is likely to make. The jitter on the network will affect SD and HD stream differently (in fact, any streams with different bitrates will be in a different way impacted by the jitter – this causes numerous problems), so knowing about the method the jitter is impacting the IP shipment is REALLY beneficial information, that you just do not get with the other determining systems.
I hope you find this short article helpful and take the steps to ensure a trustworthy system, with great Quality Of Service, prior to you get ‘implementation headaches’. Another post will follow soon explaining how to construct a robust IPTV network.
