The interoperability of Broadcast and IP infrastructures for reliable delivery of television services DANNY WILSON Pixelmetrix Corporation Singapore, Singapore ABSTRACT More and more companies are using Internet Protocol (IP) to transmit video over the network. However, while there are many advantages to using IP, there are also significant problems. Video over IP is inherently unreliable and something as simple as channel surfing can become a problem on an IP network. Transmitting video over IP has serious quality of service challenges that companies ignore at their peril. Monitoring the network for problems has become more complicated as the number of channels have exploded. The programs themselves contain multiple language, subtitle and close caption options. Noticing there is a problem with the transmission is one issue, while locating the source of the problem is another. Companies planning to transmit video over IP need a preventive monitoring system that is vendor independent, can monitor remotely, and can check and compare at every stage of the transmission chain. Such a system needs to be able to spot problems before they impact the customer and locate the source of each problem quickly. Anything else means unsatisfied customers. BACKGROUND As digital video compression technology matures, Internet Protocol (IP) is gaining widespread acceptance as a means of sending digital video along the transmission chain. Sending digital video using MPEG-2 compression over an IP network has numerous advantages. For example, it allows companies to utilize expensive bandwidth very efficiently as compressed video uses far less bandwidth. In addition, those same IP networks can also carry digital audio, telephony, data and metadata. This is an advantage for cable companies and phone companies that want to engage in a triple play strategy using their existing infrastructure. However, while IP networks have many advantages, there are serious disadvantages as well. Companies that use IP to transmit video face significant Quality of Service challenges. If companies do not address these challenges, they will end up with customer churn as users experience poor service. WHAT THE CUSTOMER WANTS Consumers now have very high expectations. TV viewers expect to be able to turn on the TV, zap through channels in search of something interesting, and watch it all the way through without the transmission breaking down. They do not expect a simple thing like changing the channel to take two seconds. They do not expect to watch a TV program which stutters throughout its 30 minute transmission. Televisions are expected to just work. This does not bode well for companies that plan to use IP networks to transmit television programs. CHANGING CHANNELS Something as simple as channel surfing is a complex network engineering issue for companies that deliver video over IP. Channel surfing is a common activity that TV viewers do not even think about. The TV viewer sits back in his easy chair, pushes buttons on the remote control andeffortlessly changes from one channel to another in search of something interesting to watch. When the video is delivered by IP though, channel surfers can be in for an unpleasant shock. As he attempts to channel surf, the television blanks out for a few seconds before displaying the video from the next channel. Channel surfing becomes channel wading. The reason that a normal TV viewer can change from one channel to another so quickly is because his television is already receiving all the programs. These are just not being shown. In a free-to-air broadcasting system, television transmitters are already sending all the various television programs simultaneously over the radio waves. In a cable TV system, the cable company sends all the programs over the cable network to the set-top box. In both cases, changing a channel simply involves switching to programs that the TV already receives but does not display. On an IP-based network though, channel surfing can become an issue because only one stream of video is transmitted to the TV at any one time. When the TV viewer wants to change the channel, he punches a remote that sends the signal to the television set which, in turn, sends another signal on to a router on the network. The router then has to stop sending the original stream and then resend a new stream based on the requested channel. This creates a delay between the time the router stops sending over the old channel and when it starts sending over the new requested channel. How long this delay is depends on a number of factors such as how fast the network is, how it is designed, and how quickly the router can respond. It can result in a considerably longer response time than most people expect especially in comparison to the instant nature of the current channel surfing experience. The situation is worsened when the router is subjected to multiple change requests all at the same time. In a normal IP network, this might not happen very often. However, on an IP network transmitting a television program, this might happen quite often. LEAVE “Sports” JOIN “Movie”IP Multicast Point Sports Stream Arriving Movie Stream Arriving One comparable example is the World Cup finals. One of the most popular sporting events in the world, the World Cup draws millions of viewers. The finals itself are broadcast live all around the world. As such, in most markets, you can expect that many people will be tuning in to watch the finals of the World Cup at the same time. However, once the match breaks for halftiime people are suddenly able to do other things. During this time, many systems get stretched to their limits. For example, many people take bathroom breaks at this time stressing local sewage systems. In the UK, half-time during the World Cup finals means a sudden spike in electrical usage as millions of viewers put the kettle on to make themselves a pot of tea. On an IP network, the half-time break during the World Cup would mean that people watching the World Cup on the network might all be switching channels at the same time, in search of something else to watch before the match resumes. In a worse case scenario, this would overload routers everywhere, leading to network congestion. Worse still, people might successfully change channels but find themselves unable to change back in time for the match because of overloaded routers. JITTER BUGS Another problem that arises when IP networks handle video is due to the way the network handles data. In an IP network, data is broken up into small packets and then sent off separately. At its final destination, all the data packets are reassembled again. When video is put on an IP network, that video is also broken up into small packets and sent from the source, the broadcaster, through the network, to eventually be reassembled into video that TV viewer gets to watch.While this system is a good way of sending ordinary data files, when applied to video, it creates problems. Video files are extremely large and to send a complete file over might take several hours. The solution is to have the video play as the packets are downloaded. However, due to factors such as routing changes, network congestion or timing drift, the packets do not all arrive at the same rate or even in the correct order. This problem is known as jitter. The solution to this problem is a jitter buffer. The jitter buffer stores the packets as they come in. These packets are assembled in the buffer ahead of their use so that late packets can added. Unfortunately, the buffer solution is not flawless. Depending on the rate at which the packets of video data arrive, the buffer can be suffer from underflow or overflow. Underflow occurs when the data arrives too slowly. This causes the video to stutter as the packets eventually arrive. Overflow happens when the data arrives too fast for the buffer to handle and the packets are lost. In either case, the end result is the same, an unacceptable consumer experience as the video lurches from one frame to the next. THE CHALLENGES OF BUILDING AN IP NETWORK Building an IP network that supports video is a challenging job. Video is special because of the size of video files and its immediacy. Sending video on a data network puts a tremendous strain on the network so engineers have to find ways to transmit data in a more efficient way. When video is transmitted over an IP network to multiple users, it usually uses a technique known as multicasting. In multicasting, instead of the video server handling sending a separate video stream to each TV viewer (known as unicasting), the video stream is sent out to a router, which duplicates the data, splits it and sends it off to other routers at different parts of the network. The other routers, in turn, receive the data, duplicate it and then send them off. In this way, the data is distributed in a tree-like structure that puts minimal strain on the network. However, while this is very efficient, there are technical issues with the scalability of this structure. In addition, real-time video is usually sent using a different protocol from other data. Most data on an IP network is sent using TCP (Transmission Control Protocol). This is a way of sending packets of data so that if any packets get lost, the source is informed, and the missing packets are resent. This ensures that all files sent over are complete. However, TCP is not used to transmit real-time video. This is because the process of feedback takes too long. Instead, video is usually transmitted using a protocol called UDP (User Datagram Protocol). UDP is a very simple protocol that does not require any acknowledgement of success or failure of the transmission. It does not send feedback or call for retransmission if packets are lost. As such, UDP is inherently unreliable. If a packet of data goes missing, the source will never know and the recipient will never be able to retrieve dropped packets. Geography Time Protocol Level IP MPEG Transport TV & Data Services Signal Integrity Service Integrity Distributed Remote To make things worse, while UDP is supposed to be transmitted in an agreed upon fashion, not all UDP transmissions follow this standard. This further complicates the whole transmission process. The design of the IP network then is a wildcard that can have tremendous influence on the signal quality of the transmission, and hence the quality of the picture. KEEPING AN EYE ON THINGS Given that video delivery over IP is going full speed ahead despite these limitations, companies need a way to monitor their networks to ensure that they are able to deliver a high quality of service to their customers.Traditionally, operators are employed to eyeball a bank of monitors to look for problems with the video transmission. In a digital world, however, this is no longer viable. The explosion of channels means that it is not humanly possible to monitor hundreds of channels, which might include programs with options for soundtracks and subtitles in different languages. How can an operator know if the soundtrack and subtitles on any one channel are the right ones? ❏ Human Operator watching TV for errors and anomalies. ❏ What about 500 channels? In addition, given the complexity of today's networks, determining what causes a problem is a big challenge as well. The source of the problem could lie in any number of places, from the multicast router, to the way the video was compressed, or at the head-end receiving the satellite feed. Given all the potential problems associated with service delivery when using an IP network, it is critical that companies relying on IP have automated and costeffeectiv solutions that help them to monitor their network so they can deliver on their service level agreements. Ideally, such a system would monitor service and signal integrity throughout the entire chain of transmission across all media. The monitoring systems should be able to do a check and compare at each stage of the delivery chain. This system should also be able look for problems on the transmission chain that are occurring now as well as to spot problems that are likely to come up. Such a system should be able to check that the right subtitles and languages are being delivered on the right channel. That system should also be able to check the signal integrity to ensure that the data is being transmitted without problems. This means the ability to interface in a multi-vendor environment. Such a system needs to be able to monitor all of the equipment regardless of geography. It should not matter whether the equipment being checked is in the next room or the next city. And ideally, this system should also be able to plug into other information systems such as the billing platform or customer information database so that customer support issues can be dealt with quickly. WHAT’S THE FREQUENCY KENNETH? On an IP network, a problem with the TV transmission isn't a question of the wrong frequency being used. IP networks are very efficient at transmitting data in general, but transmitting a television program, which is larger and requires immediate delivery, is more challenging. Quality of Service is a business issue when transmitting video over the IP network. When even channel surfing becomes a problem, companies need to pay close attention to the customer experience that results from a move to IP. To ensure service and signal integrity, preventive monitoring across the entire transmission chain is not optional. The volume, complexity and rapidity of data flow requires automated, integrated solutions. In the era of digital video over IP networks, "golden eyes" alone are not enough.
sammyc2007 1/25/2008 |
377 |
9 |
1 |
technology
jpl7986 3/12/2008 |
130 |
15 |
0 |
creative
Tapisserie 3/24/2008 |
48 |
0 |
0 |
legal
sammyc2007 1/25/2008 |
100 |
3 |
0 |
technology
sammyc2007 1/25/2008 |
100 |
4 |
0 |
technology
sammyc2007 1/25/2008 |
112 |
3 |
0 |
technology
sammyc2007 1/25/2008 |
170 |
10 |
0 |
technology
sammyc2007 1/25/2008 |
159 |
3 |
0 |
technology
justia 4/15/2008 |
22 |
0 |
0 |
legal
FAA 6/24/2008 |
9 |
1 |
0 |
legal
usvoruganti 4/18/2008 |
95 |
3 |
0 |
technology
FAA 6/24/2008 |
4 |
0 |
0 |
legal
sammyc2007 6/13/2008 |
186 |
4 |
0 |
legal
sammyc2007 6/13/2008 |
168 |
0 |
0 |
legal
sammyc2007 6/13/2008 |
217 |
4 |
0 |
legal
sammyc2007 6/13/2008 |
201 |
2 |
0 |
legal
sammyc2007 6/13/2008 |
359 |
2 |
0 |
legal
sammyc2007 6/13/2008 |
274 |
0 |
0 |
legal
sammyc2007 6/13/2008 |
190 |
0 |
0 |
legal
sammyc2007 6/13/2008 |
156 |
0 |
0 |
legal
sammyc2007 6/13/2008 |
274 |
0 |
0 |
legal
sammyc2007 6/13/2008 |
224 |
0 |
0 |
legal