Maintaining Quality of Service (QoS) of Video Over IP Services By Christopher Purdy Internet Protocal (IP) is now being widely deployed for internal distribution in broadcast and network operations facilities. Test and analysis for this can be distinctly different than IP delivery directly to the home (IPTV). Test strategies during IPTV initiation, establishment, and rollout will vary, but all will be targeted to ensuring quality of service.

L

ike all new technology deployments, the delivery of video over internet protocol (IP) presents its own, entirely new, set of challenges, of which many people are entirely unaware. Because the delivery of e-mail and other data is ensured, it is often presumed that video will also be delivered easily over an IP network. The reality is that video is reliant on constant rate lossless transmission and can display many different quality issues, including loss of video and, in extreme cases, decoder lockups, or failure to locate the correct channel. Both IPTV broadband delivery as well as video over IP distribution networks can suffer, each having its own characteristic fault behaviors, which are explored in this paper. The problems may even occur outside the operator’s own network, so it is vital to understand both the cause of the fault nature and its location. Provided these issues are well understood, detection and prevention are possible. Remedial action can then be performed to maintain good quality of service (QoS) at minimal cost overhead.

Why Video Over IP? Advantages of IPTV include two-way capability lacked by traditional TV distribution technologies, as well as point-to-point distribution, allowing each user to view individual broadcasts. This enables stream control (pause, wind, and rewind, etc.) and a free selection of programming much like its narrowband cousin, the Web. Triple play is an expression used by service operators describing a consumer package, including telephony, data, and video. Offering triple play on a broadband connection requires the use of IPTV and IP Telephony (VoIP). The triple play and IPTV market is expanding 406

SMPTE Motion Imaging Journal, October 2006 • www.smpte.org

MAINTAINING QUALITY OF SERVICE (QOS) OF VIDEO OVER IP SERVICES quickly. A “goldrush” of operators will try to monetize the possibilities that this new technology has to offer.

IPTV Market World and Asia The worldwide IPTV market will grow to just over 27 million households and $1 billion by the end of the decade (IMS Research).1 This growth will be primarily driven by Europe and Asia, with particular contributions from Western Europe and China. China is expected to account for up to a quarter of spending as operators develop new services. Users of IPTV in China could reach 13 to 16 million by 2009, compared to about 150,000, currently.

Europe As a region, Western Europe is expected to lead the worldwide IPTV market through the end of the decade, with approximately 12.9 million households by 2010 (Screen Digest).2 The region’s strong expected collective growth is due to continued success in existing IPTV markets such as France, Italy, Sweden, and the U.K., as well as anticipated deployment in newer markets such as Austria, Spain, Switzerland, and other countries.

The U.S. It is reported that the U.S. has a slower surge in IPTV growth, but will accelerate in 2007. The strongest test for IPTV will come from the market, because of high existing pay-TV penetration, and price and service competition that is likely to come from the entrenched operators in the cable and satellite sectors. Verizon expects to pass 3 million subscribers with 5 to 30 Mbit/sec fiber-to-the-home by the end of this year. By late 2007, SBC plans to pass 18 million subscribers with its 5 to 20 Mbit/sec fiber-to-the-neighborhood network (Fig. 1). The carriers are far behind cable providers, their main competition in television delivery, and it will cost a lot to catch up. The price tag on SBC’s network upgrade plan is $4 billion, and Verizon will add 3,000 to 5,000 outside plant engineers at a considerable cost, to upgrade 2 million copper lines to fiber by the end of 2006.

Maturity of the Technology Much of the technology on which the success of IPTV depends, like advanced set-top devices, is still in develSMPTE Motion Imaging Journal, October 2006 • www.smpte.org

Figure 1. IPTV households by region 2002 to 2010.

(Source

IMS Research)

opment. Microsoft TV started advanced trials only last year. IPTV can connect devices such as PCs, as well as televisions; therefore, carriers will have to implement copy protection within streams and set-top devices. Operators will need to be able to deliver on the technological benefits of an IP-based video service, as well as on the business fundamentals of successful pay-TV operation—factors such as price, product reliability, customer service, content protection, and others. Ensuring that the service is at least a good competitor offering is vital. Then IPTV operators can ultimately succeed in taking and, more importantly, retaining share from the cable and satellite operators. The adoption of IP into the broadcast world is largely dependent on customer confidence and consumer satisfaction. Low-cost and higher network speeds make IPTV seem a smart choice, but this new technology is still being developed.

The Real-World: So Where Will the Problems Show Themselves? The IP medium was not intended to transport video and audio when it was created. Before describing the problems this causes, it is necessary to understand the network topologies. The layout and structure of the new networks are unlike traditional closed, synchronous, cable, satellite, or terrestrial systems (Fig. 2), which can be easily monitored within a linear transmission and distribution chain. The next evolution (Fig. 3) contained some IP-based distribution, because this extended the limited reach of ASI network feeds, and these dedicated closed IP networks had rigidly controlled predictable traffic patterns 407

MAINTAINING QUALITY OF SERVICE (QOS) OF VIDEO OVER IP SERVICES with minimal interfaces and switches. Final delivery was usually to traditional broadcast head-end. Having proved itself in the “core” and contribution feed arena, the next step is to link to other IP networks, all the way to the subscriber, as in a typical system illustrated by Cisco (Fig. 4).3

What Do We Mean by Low BER (Bit Error Rates) in IPTV Networks? Figure 2. First-generation digital systems.

Figure 3. Modern broadcast systems with some IP infrastructure.

Figure 4. Next-generation broadband systems. (Graphic courtesy of Cisco Ltd.) 408

Before exploring protocol issues, consider basic network bit errors— the famous “dropped packet” scenario. Content servers and off-air and contribution feeds drive into the secure and low-error “core network,” where the broadcaster and provider have good control over traffic with very low error rates. How low? Good optical networks can be theoretically as good as a bit error rate (BER) of 10-14.3 The reality is that if bit errors are assumed to be distributed randomly, the resulting requirement for transport links is to have a BER of less than 10-10, to ensure final consumer BER of less than 10-6. The link-layer technologies in video networks employ cyclic redundancy check (CRC) algorithms to ensure that packets with errors are not delivered. So video packets may be dropped when a CRC fails. Ethernet also has CRC, known as FCS. From the core we drive into the edge network and then to the aggregation network. Aggregation points, by their nature, are traffic focus points and may suffer from queue drops by bursts from multiple sources. This also results in packet loss.

SMPTE Motion Imaging Journal, October 2006 • www.smpte.org

MAINTAINING QUALITY OF SERVICE (QOS) OF VIDEO OVER IP SERVICES

Packet Loss Particularly, with new compression systems such as H.2644 and SMPTE-VC-1,5 video is much more highlycompressed and fragile than audio, which can suffer dropping a VoIP voice packet inaudibly. Losing a video packet, however, may result in the loss of more valuable encoded video information. A single video packet drop can cause a visible degradation of quality, anywhere from a single frame up to a loss of 1-sec of video, depending on the kind of encoded information that is lost.6 From the aggregation network, nodes may drive the Telco’s access into digital subscriber lines (DSL) from their DSLAMS (multiplexers) and to the subscriber/viewer. The latter part is over DSL, where signal degradation can vary from many factors, including loop length, proximity to interference (noise), etc. In addition, the SNR may vary over time because of factors such as moisture and corrosion at connection points. The ideal error rate of 10-10 is hard to achieve over the service life; thus, a more realistic 10-6 may be attained, which is equivalent to one corrupted packet per 2 hr of video streaming. As a result, monitoring and test equipment threshold alarms need to be set accordingly, depending on location within the core, aggregation, or access networks. Also, a particular company may have full control of its core network, but the edge and aggregation networks may be another operator altogether. It may even be determined that the external operator fully understands the nature of data switching and routing, but little about video and its synchronous requirements. The next most important issues are out-of-order packets, packet delay, and jitter.

Ordering Errors Ordering errors, in which part of the IP stream is routed over asynchronous transfer mode (ATM), occur quite frequently. If the content is MPEG-2 transport, which may not necessarily be the case with some elementary video IP stream routing, then each MPEG-2 packet has a built-in 4-bit “continuity counter,” which sequences on a packet identifier (PID) (video or audio packet of the same type) basis. If the test equipment has dual test ability—IP and MPEG-2 decode—then it is easy to detect and alarm on mis-ordering. Some sophisticated set-tops can correct ordering in their buffers, but usually IP set-tops are not so clever and SMPTE Motion Imaging Journal, October 2006 • www.smpte.org

simply drop such packets. With user-defined protocol (UDP), out-of-order packets are impossible to detect. These errors can be infuriating to find, but time stamps and pre-trigger capture buffers in test equipment help to correlate ordering errors with sessions and IP probe points to determine the root cause of the fault. Better than UDP, which most of the industry currently uses, are realtime transport protocol (RTP) and its control protocol (RTCP). This has a payload-type field that can be used to identify what is being carried (i.e., there is a particular value for MPEG-2 TS).7 The sequence number overcomes the out-of-order arrival problems of straight UDP. The time stamp field is payload specific. For MPEG-2 TS, it is a 90-kHz time stamp (i.e., same resolution as PTS/DTS presentation time stamps) derived from programmable clock reference (PCR) (Fig. 5).

RTP Streaming Modes and VBR Most operators use UDP and suffer its inherent problems, such as packet ordering. The RTP standard (RFC 2250)8 does not solve all the problems, because it gives the transport layer without strictly specifying how data is organized within the transport. There are two solutions to this, one is the simple encapsulation of standard MPEG-2, RTP TypeMP2T. This eases conversion infrastructures from cable and satellite, in which operators have confidence. Also, test equipment can convert and run standard MPEG-2 test and monitoring toolsets. However, the penalty is bandwidth overhead, which gets worse as it gets closer to the customer. One solution is rate shaping, to remove the null stuffing packets and reduce bandwidth requirement. However, this makes the MPEG-2 transport stream variable bit rate (VBR), and currently most MPEG and test equipment assumes constant bit rate (CBR), so no current test equipment can measure PCR and MPEG jitter issues. Some possible solutions may be re-insertion of stuffing for MPEG-2 processors and test analyzers. Another new solution to bandwidth issues consists of putting video elementary data directly inside RTP packets without TS encapsulation. The internet standards body, Internet Engineering Taskforce (IETF) has many specifications for different payload types (RFC1890).8 For example, MPV (video) and MPA (audio). This helps the bandwidth problem, but the disadvantage is that 409

MAINTAINING QUALITY OF SERVICE (QOS) OF VIDEO OVER IP SERVICES Also, these conditions can be affected by traffic patterns in a system, another science in its own right, requiring statistical analysis and appropriate prioritizing strategies as systems get stressed.

IP Fragmentation Another problem occurs when the MPEG packets within the IP frame get separated by the network. How does equipment cope with this scenario? Some routers and switches can buffer and re-assemble the packets after fragmentation—but some cannot, resulting in packet dropping and out-of-order packets.

Forward Error Correction Figure 5. RTP protocol.

much broadcast and test equipment simply will not interoperate without considerable design changes.

Jitter and Delay Causes Packet delay variation and inter-packet gaps can stress both routers and set-top box buffers. This occurs because routers and other processing equipment become overwhelmed by traffic; the data then jumps between networks of different delay characteristics. Path re-routing due to congestion is another cause: ATM, IP, and MPEG packets have different sizes, so switches and routers may break up and re-assemble some packets along the way, causing inter-packet delay variation.

Symptoms Symptoms can include failure of the decoder buffers to keep up with the stream by underflow or overflow, causing picture blocking and freezing, as packets get lost. More subtle errors include PCR arrival jitter or drift, which causes color and video sync loss on some decoders. Ideally, test equipment with MPEG decode can display PCR inaccuracy, overall jitter, arrival time, jitter, and drift, to pin down the issues. Measurement of the media delivery index (MDI) can help here. It is the ratio of delay factor (buffer needed for arrival time variance) against media loss rate (IP packet loss). Most IP set-top boxes (STBs) can soak up jitter with 200-ms buffers, and some IP boxes have as much as 2sec of buffer. But packet loss is critical; it must be less than 10-6. 410

To fight low BER and dropped packets, forward error correction (FEC) technology can improve the video QoS. This uses special coding at both ends of the network to flag and restore dropped bits. Sometimes a separate IP session may be used for the FEC correction data, unlike inter-packet reed Solomon in DVB/MPEG streams. DVB-H uses MPE datagrams over IP, over MPEG, for FEC. Sometimes IP FEC solutions that work over small deployments are not robust enough to extend over larger networks. There are proprietary solutions such as Tut Systems, and digital video broadcast (DVB) may introduce the Digital Fountain’s RAPTOR system as standard when they can resolve sub-blocking issues, while SMPTE is trying to improve the looser Pro-MPEG forum’s COP-3 standard 9 and overcome its usage issues in VBR systems. If FEC packets are sent sequentially (on another UDP port), this minimizes set-top box latency; however, a bursty pattern results. The solution is to interleave the FEC parity packets with data packets. In COP-3, this is done by splitting FEC into rows and columns (Fig. 6).

Channel Changing and I-frame Corruption MPEG-2 (and H.264) has intra-coded (I-frame) video frames, bidirectional frames, and predicted frames for visual temporal changes in its group of pictures (GOP) sequence. If an I-frame gets hit by a packet drop, with a typical MPEG-2 GOP size of 12, this could affect a 480 ms sequence of video. With H.264, this could be vastly longer, as some GOP lengths could be 300. This varies with the particular codec implementation. Because Iframe data is 20% of GOP data, this gives 20% probaSMPTE Motion Imaging Journal, October 2006 • www.smpte.org

MAINTAINING QUALITY OF SERVICE (QOS) OF VIDEO OVER IP SERVICES bility of packet drops affecting intra blocks or the whole GOP (Fig. 7).

I-Frame “blasting” Some proprietary strategies involve a server sending the required I-frame data rapidly to a set-top that changes channel, and then when ready, it switches over to the multicast protocol. This burst of unicast data may also be used to fill the set-top buffer at high speed. Once the I-frame has arrived, other frame data can be accurately interpreted. Thus, a saving of 500 ms could lower channel change to 150 ms. However, this has a drawback of scalability

Picture-Quality Degradation If RTP/UDP is being used, packet loss will directly affect image quality because the video stream has GOP gaps. This can be corrected in some video codecs, but it varies according to the vendor. If transmission control protocol (TCP) is used, retransmission of lost packets

Figure 6. FEC COP-3 scheme.

Figure 8. Picture artifacts due to dropped packets.

causes STB buffer underrun, and picture flow is paused or jerky. Inter-frame (I) corruption of discrete cosine transform (DCT) data causes picture slice stripes or blockiness. Intra-frame (B- and P-frames) data loss causes degraded, frozen, or blank video. Test equipment can be used to capture and record such episodes, to see the intermittent effect the viewer might see, and this can be done over different compression formats. It is advisable to see how each encoder/system might behave with different IP error scenarios. Test analyzers can also provide video performance metrics such as PSNR and quality scores. Figure 8 shows effects of dropped packets. Packet delay variation (jitter), delay, and dropped packets are not the only problems. All these issues assume a video stream going to a set-top box or test monitor/analyzer, but what if it not there?

Quote A local IP set-top box maker tells us 90% of the products delivered to new IPTV networks fail to decode video at all. These boxes are good, and are not faulty; the problems are IP network-related and are not dropped or delayed packet problems.

Tuning Problem

Figure 7. GOP susceptibility. SMPTE Motion Imaging Journal, October 2006 • www.smpte.org

Consider good old-fashioned analog (or even digital) television. Service discovery was digital. You either picked up the channel, or you didn’t! Tuners were relatively simple devices. Then came DTV, but the RF channels were still there, and could be tuned, 411

MAINTAINING QUALITY OF SERVICE (QOS) OF VIDEO OVER IP SERVICES

Figure 9. Tuning—old and new.

this time to transport streams, with many programs—so MPEG provided mapping and program tables to filter and route the video and audio content to decoder and display. However, with IP, it is not simple. There are multiple sessions and protocols; multilayer signals with handshakes; L2 and L3 service busses, control, and data planes; video on demand (VOD) policy servers; multicast and singlecast; RTP, RTSP, UDP, IGMP, DRM; and the list goes on (Fig. 9).

NDS, etc. It may also be vertically integrated (proprietary) by Microsoft TV or OPEN-TV, with special Digital Rights Management (DRM) gateways. The DVB is currently working on a broadband content guide (BCG), which is equivalent to the network information table (NIT) on DVB/MPEG. The DVB-IPI group also has phase 1.1 spec (ETSI TS 102 034),10 which specifies SD&S. This goes further, offering EPG-style program selection and DVBSTP for push mode and HTTP for pull-mode selection. BCG intends to get rid of transport layer and work directly over IP, using encapsulation defined in GBS spec (ETSI TS102 323).11 There are other entirely proprietary systems (Telephonica, Fastweb) that have their own homepages for service selection and may download custom software application programming interface (API) for the transactions.

Tuning Itself Tuning is achieved by first finding the sessions that carry video on the broadband network. For example, a test equipment IP viewer (Fig. 10). In some cases, none are visible on the network, and the STB has to be requested by call-flow signaling—the stream path to be set up from the multicast or VOD server, for active streams to be fed to the target STB.

Figure 10. IP sessions view on test equipment.

Service Detection, Service Discovery, and Service Selection Pure IPTV set-top boxes need service discovery and selection (SD&S), because they cannot boot themselves. The order is, service selection (IGMP and RTSP), service discovery (PSI/SI and DNS), then service delivery (using RTP, UDP, or RTSP for VOD). Also, the STB may need to be authorized (DHCP) by the network or billing authorities.

Portal Browsers Service discovery may occur in different ways by portals such as Tandberg, Minerva, CSDs Interactive portal “OK Plus” (Fig. 11), or HTTP for ORCA, and

Figure 11. IP portal program selection.

412

SMPTE Motion Imaging Journal, October 2006 • www.smpte.org

MAINTAINING QUALITY OF SERVICE (QOS) OF VIDEO OVER IP SERVICES

Figure 13. HTTP program lists.

Figure 12. IGMP sessions allocation on STB.

Basic Service Selection and Interactive Program Guides A basic set-top box may provide test menus that allow internet group multicast protocol (IGMP) sessions to be joined (so can Figure 14. Graphic film browser/selectors. test equipment), as illustrated in Fig. 12. Note that the 11111 (arbitrary) denotes a multicast simply based on the destination address, or they may port. look at some descriptive information about the packet. The next level up could be HTTP program lists, as This information may include special handling instrucshown in Fig. 8, or Picture Mosaics in native API code tions, called a label or tag, or priority status such as or Web page format (Fig. 13). high-priority for realtime voice or video signals. The most advanced program guides include the Routers review the destination address in their routing Spanish Cartelera Pay Per View on CSD tables and determine the paths to which they can send (Mediahighway) or Canal Digital widescreen service. forward packets. If a current path is busy or unavailable, (Fig. 14). the router can forward the packets to other routers that Using these services, viewers are able to browse forward the packet towards its destination. Thus, some films in a far more ideal environment, with the posters of packets will travel through different paths and can arrive each film providing access points for further information out of sequence at their destination. When the packets and selection for movie download. arrive at their destination, they can be reassembled into These applications and browsers not only select the proper order, using the packet sequence number, if the source, but in the process of doing so, select the mode protocol allows. of transmission, basically in Telco terms, “call setup.”

Switches

Routing, Switching, and MPLS Routers learn from each other about the best routes to select when forwarding packets toward their destination (usually paths to other routers). Routers regularly broadcast their connection information to nearby routers and listen for connection information from connected routers. From this information, they build information tables (routing tables) that help them to determine the best path to forward each packet. Routers may forward packets toward their destination, SMPTE Motion Imaging Journal, October 2006 • www.smpte.org

High-speed technologies like Gigabit Ethernet put additional pressure on the forwarding requirements of the core and surrounding devices, therefore, it is important to know if traditional routers will be able to keep pace. Typically, general-purpose routers were adopted in systems, but in recent years local area network (LAN) switches have replaced such routers, providing significant advantages in price, performance, and density. Routers operate at Layer 3 with source and destination addresses, whereas switches have media access 413

MAINTAINING QUALITY OF SERVICE (QOS) OF VIDEO OVER IP SERVICES control (MAC) addresses in their routing tables and operate at Layer 2 (bridging). There are also combined router and switchers. Routers are being replaced by Ethernet switches due to higher speeds, broadcast containment, security, and support for complex topologies.

MPLS Routing Label switch paths (LSPs) are established by network operators for a variety of purposes such as to guarantee a certain level of performance, to route around network congestion, or to create IP tunnels for network-based virtual private networks. In many ways, LSPs are no different from circuit-switched paths in ATM, or frame relay networks, except that they are not dependent on a particular Layer 2 technology. A LSP that crosses multiple Layer 2 transports such as ATM, frame relay, or Ethernet can be established. Thus, one of the true promises of multiprotocol label switching (MPLS) is the ability to create end-to-end circuits, with specific performance characteristics, across any type of transport medium, eliminating the need for overlay networks or Layer 2-only control mechanisms. The initial goal of label-based switching was to bring the speed of Layer 2 switching to Layer 3. Label-based switching methods allow routers to make forwarding decisions based on the contents of a simple label, rather than by performing a complex route lookup, based on the destination IP address. This initial justification for technologies such as MPLS is no longer perceived as the main benefit, since Layer 3 switches (ASIC-based routers) are able to perform route lookups at sufficient speeds to support most interface types. However, for IPTV, the ability to specify a guaranteed path bandwidth for certain subscribers is useful. MPLS brings many other benefits to IP-based networks, such as the following: Traffic engineering: The ability to set the path that traffic will take through the network and the ability to set performance characteristics for a class of traffic. VPNs: Using MPLS, service providers can create IP tunnels throughout their network, without the need for encryption or end-user applications. Layer 2 transport: New standards being defined by the IETF’s PWE3 and PPVPN working groups allow service providers to carry Layer 2 services including 414

Ethernet, frame relay, and ATM over an IP/MPLS core.

Modes of Transmission Over Routers Video broadcast can be either unicast or multicast from the server. Unicasting is the traditional method of data transport between one specific source and one specific receiver; the transmission is replicated by the server for each end-point viewer. The vast majority of all data transmissions on the internet today, including all TCP, FTP, and HTTP traffic, are unicast. Two nodes communicate by setting up a “session” or source and destination IP address, with port number. The fundamental difference from traditional broadcast networks is that communication is bidirectional. With the following multicast system, even a “passive” STB sends continuous “keep alive” packets back to the router during subscriber viewing. IP multicast is a method in which a message can be sent simultaneously to several IP devices (STBs) instead of singly to one computer. This is done by sending the message to a range of addresses reserved for multicast groups (224.x.x.x-240.x.x.x)— each computer must also decide whether or not it wants to be part of a specific group (Fig. 15). A device can subscribe to the same group more than once—in such cases, each subscribing application receives a separate copy of each message received on the group IP address. To prevent conflicts, where two groups have the same group IP, most routers will not forward multicast messages to other network segments. This behavior is, however, sometimes configurable on a case-bycase basis, depending on the router software. In a multicast configuration, the same signal is sent over the network as one transmission, but to multiple endpoints or, simply, a group of users. Multicasting is not the same as broadcasting; broadcast data is sent to every possible receiver, while multicast packets are sent only to receivers that want them. Multicast is defined by IETF RFC 1112,12 where a Class D address is the group identifier. Members of the group could be present anywhere on the network, and members join and leave the group and indicate this to the routers. Senders and receivers are distinct. For instance, a sender does not need to be a member, and routers will SMPTE Motion Imaging Journal, October 2006 • www.smpte.org

MAINTAINING QUALITY OF SERVICE (QOS) OF VIDEO OVER IP SERVICES listen to all multicast addresses and use multicast routing protocols to manage groups.

Internet Group Management Protocol (IGMP) IGMP is used by IP hosts to report their multicast group memberships to multicast routers. Three versions are currently in use—v1, v2, and v3. Version 2 is most commonly used today. Figure 15. IP multicast. IETF RFC 1112 defines the specification for referencing. It is still early, but the components are in IGMP Version 1, it only has two different types of IGMP place for highly intelligent super-EPG program guides. messages: Membership query and Membership report. Standards In Version 2 ( IETF RFC 2236)12, there are four types of IGMP messages: Many standards have already been mentioned, but Membership query (Type 0x11) the following sections give a breakdown of the stanVersion 1 membership report (Type 0x12) dards bodies themselves.14 Many are aware of the othVersion 2 membership report (Type 0x13 ers, and much liaison and cross-referencing happens Leave Group (Type 0x17) between the bodies, but not necessarily agreement (Fig. Version 3 of IGMP (IETF RFC 3376) adds support for 16). source filtering. This is the ability for a system to report IETF interest in receiving packets only from specific source For IPTV, the main core standards come from the addresses, or from all but specific source addresses, Internet Engineering Task Force (IETF), where stansent to a particular multicast address. dards activities are organized into working groups In Version 3, there are five types of IGMP messages: (WGs) that collect request for comments (RFCs), make Membership query (Type 0x11) draft internet standards, and decide and vote accordingVersion 1 membership report (Type 0x12) ly, before adoption. This is where DNS (RFC 1035), Version 2 membership report (Type 0x16) RTP, IGMPv2 (RFC 2236), and MDI originate.12 Version 2 Leave group (Type 0x17) Version 3 membership report (Type 0x22)

Interactivity and Metadata Interactivity is alive and well, but slow with IPTV, because standards activities have not quite caught up. DVB is working on multimedia home platform (MHP) extensions to Version 1.1, but there are java issues to be resolved. The MHP has an “IP tuner” specification ongoing under the DVB-IPI group. The U.S. standards group OCAP is slower in producing IPTV-related standards. The TV-Anytime specifications13 now offer tools that allow consumers to search, find, select, and enjoy the widest possible range of content, from the broadcast, VOD, mobile, and IPTV world. Amino has launched a PVR (disk-based STB) IPTV receiver, and these PVR technologies are ideally suited to TV-anytime-type genre and IP/Web-based content SMPTE Motion Imaging Journal, October 2006 • www.smpte.org

ITU The International Telecommunications Union (ITU)4 is not only involved in the videoconferencing standards such as H.262 and H.264, but also in standards used in service level agreement (SLA) metrics such as delay, loss, and jitter, based on ITU standard Y1540/1.15

ISO/IEC Higher level compression such as MPEG-4, H.264AVC come from joint ISO/IEC, as well as MPEG-2.

DVB/ETSI DVB standards such as TR101-29016 test standard, and DVB-H for IP over MPEG to mobiles are routed through the ETSI standards body. The DVB IP-centric group, DVB-IPI, has ETSI TS 102 034 for SD&S. Also of importance, is the specification for critical transport stream errors, TR101-290.16 415

MAINTAINING QUALITY OF SERVICE (QOS) OF VIDEO OVER IP SERVICES

Content on Demand: Conditional Access Standards and DRM

Figure 16. IPTV standards.

ATSC ATSC has A64A for testing, monitoring, and measurement of the transmission sub-systems and the A54 usage guide.17

ISMA The Internet Streaming Media Alliance (ISMA) is a global alliance of industry leaders dedicated to the adoption and deployment of open standards for streaming rich media such as video, audio, and associated data over internet protocols. ISMA recommends ISO formats for content storage.

Pro-MPEG Pro-MPEG is a professional standards body, with transport of MPEG-2 (COP-3) and uses RTP. This is more strict on packet loss, but less so with jitter < =/- 60 ms.

SMPTE The SMPTE body deals with the new VC-1 compression format, often carried over VOD IP streams, and is currently working on FEC schemes such as COP-3 R2. There is also an ETF draft for VC-1 over RTP payload (non-TS), which includes security under RTSP. IPTV standards are far from stable, and are continually evolving. New unrecognizable IP streams are received almost daily, with new formats to be revised, as well as proprietary standards and new encryption schemes. 416

Realtime Streaming Protocol (RTSP) is used by many to control content servers, but it can be used in many ways, so there are many interoperability problems. IETF has developed open solutions for authentication, authorization, and accounting (AAA) that are already used on networks but are not specifically designed for IPTV. The broadcast world has conditional access (CA) such as DVB-Simulcrypt, which are being used for IPTV, but these EMM/ECM key systems are designed for unidirectional application systems, of which IP is not. ISMA has proposed ISMA Crypt which is IPcentric, but lacking in the full key management definitions. DRM systems manage secret information (keys) that is used to identify and modify (decode) media. Key management is the creation, storage, delivery/transfer and use of keys to allow decryption of the media. DRM selects and codes media in different formats. Different types of devices require different media formats, and the control protocols and their various versions, such as SIP-session initiation protocol, that access these media files may vary. Users are assigned rights to access, store, and view media by the DRM. User rights management (URM) is in the process of selecting, assigning, and terminating the authorization and user privileges. The types of user rights that may be assigned may include length of time, number of users, and the ability to copy or modify the product or service.

The Future A large part of the real-world problems described above, especially traffic-related problems like burstiness and data drops, are due to mixed voice, multimedia, and data traffic running simultaneously over converged networks. Future systems such as BT’s Differentiated Services Code Point (6 CoS DSCP) service might guarantee the performance of applications by prioritizing communications into six distinct classes of service, SMPTE Motion Imaging Journal, October 2006 • www.smpte.org

MAINTAINING QUALITY OF SERVICE (QOS) OF VIDEO OVER IP SERVICES thereby future-proofing corporate networks. This is done by enabling customers to choose the performance level needed on a per packet basis by marking the DSCP field within the packet IP header to a specific value. Other improvement might be provision in networks for QoS monitoring ports for test equipment to measure the traffic and error conditions. Many current IPTV networks have no such ports on their router nodes, so they cannot know loading, delay, jitter, or packet loss, which is storing up future trouble. If servers are not provisioned to support the maximum number of expected users, then server congestion occurs. Multicast can help, but it relies on large numbers of users simultaneously watching the same content at the same time, which is unlikely! Set-top boxes can have built-in QOS monitoring, but that only highlights problems in the “last mile,” and cannot diagnose causes of data loss or jitter.

Conclusion The main problem holding back mass deployments of lucrative IPTV is the issue of scalability—protocols, FEC, DRM, SD&S systems, and multicast architectures, along with variations and immaturity in standards. Only operators brave enough to try, will get the experience and can pressure not only the standards bodies, but equipment vendors to produce reliable and interoperable systems. In the early rollout phases, test equipment is key in determining what the problems are and where they lie. Nevertheless, the future is promising, as the systems scale up. Evolution, market forces, and the standards workgroups will hopefully ensure that the best systems and solutions survive. High QoS, with certain reliability should then deliver the required high-revenue return to guarantee a vastly satisfied customer base.

References 1. IMS Research, Digital TV News, Dec. 10, 2005, imsresearch.com. 2. Screen Digest, European TV Forecasts, Nov. 2005, www.screendigest.com. 3. Cisco Gigabit-Ethernet Optimized IPTV/Video over Broadband Solution Design and Implementation Guide, Release 1.0. 4. ITU-T Rec. H.264/ISO/IEC 11496-10, “Advanced Video Coding,” Final Committee Draft, Document JVT-E022, Sept. 2002.

SMPTE Motion Imaging Journal, October 2006 • www.smpte.org

5. SMPTE 421M—”Advanced Video Coding,” VC-1, www.smpte.org. 6. MPEG-2 (2000-12-01) Standard: ISO 13818-1 (1), www.ansi.com. 7. J. M. Boyce and R. D. Gaglianello, “Packet Loss Effects on MPEG Video Sent over the Public Internet,” Proc. of ACM Multimedia, pp.181-90, 1998. 8. RTP—IETF RFC 2250 and RFC1890 (Table 2, p. 14, payload types, AT&T, Jan. 1998, www.ietf.org. 9. RFC2733 (COP-3—Pro-MPEG), Rec. Columbia University, 1999. 10. DVB Specification for IP Encapsulation ETSI TS 102 034. 11. TS102 323 DVB GBS Encapsulation of Service Information (SI), 2006 Standard, www.dvb.org CD Version 8.0. 12. IETF RFC 1035 (DNS) 2236 (IGMPV2) Xerox, Nov. 1997, RFC 1112, RFC 3376, AT&T, Oct. 2002, and more. 13. Vs 1.1.1 TV-Anytime Phase-1 Spec etsi TS 102 822. 14. Websites:www.isma.tv,www.dvb.org, www.ietf.org, www.pro-mpeg.org, www.dsl.org, www.atsc.org, www.smpte.org, www.ETSI.org. 15. ITU Standard Y1540/1 Delay, Loss, and Jitter Base, www.isourcecentre.com. 16. ETSI Technical Report, (2001-05) TR101-290 v.1.2.1 Measurement Guidelines for DVB Systems. 17. ATSC Standard A/53:A64A Monitoring: Digital Television Standards.

Acknowledgments Sincere thanks to Keith Bradbury and Paul Rae of Amino Systems; Rick Young of Comcast Sacramento; and Ignacio Martinez of Cisco systems for sharing their experiences and for illustrating real-world problems and systems. Presented at SMPTE and VidTrans Joint Conference, Hollywood, CA, Jan. 29-Feb. 1, 2006. Copyright © 2006 by SMPTE.

THE AUTHOR Chris Purdy works on test solutions for the new advanced video compression formats and file-based video, at Tektronix Inc. in the U.K. His more than 30 years experience in the broadcast industry covers design of test equipment, routing matrices, TV standards converters, digital framestores, special effects systems, and post-production editing equipment. Purdy is a member of SMPTE, DVB commercial module, DVB technical module, and the MHP group of the DVB. He is a chartered engineer and a member of the Institution of Electrical Engineers. Purdy is also the director of an educational TV studio.

417