David Glidden /
11.01.2008 12:00 PM
Maintaining QoS
Providing high-quality video over IP is challenging.

Originally designed to be opportunistic rather than guaranteed data delivery channels, IP networks have been enhanced to deliver streaming or real-time video services with a high, reliable quality of service (QoS). With such enhancements in place, broadcasters can use IP services for many of their core transport requirements, including digital newsgathering, special event coverage and network distribution feeds.

Broadcasters seeking to improve the QoS of their video-over-IP delivery services should understand the differing approaches to provisioning video services within the IP-related protocols, potential network impairments and emerging methods of improving the QoS of video-over-IP services.

Video-over-IP provisions

In the IP stack established in Request for Comment (RFC) 1122, the Internet Engineering Task Force (IETF) defined a four-layer hierarchy. (See Table 1.) Protocols such as FTP and HTTP are in the application layer. The Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) exist in the transport layer. The IP sits in the Internet layer, and the physical Ethernet connection resides in the link layer.

IP is a connectionless or datagram networking service that, by itself, does not provide end-to-end delivery guarantees. IP is not concerned with whether IP datagrams arrive at their destination delayed, damaged, duplicated or at all. Delivery guarantees are the responsibility of the transport and application layers. The IP, however, does provide for addressing, type of service codes, fragmentation and reassembly of data as well as the provision of security information.

Two major methods of QoS when provisioning video-over-IP services are integrated services (IntServ), which allows for specific requests for priority service, and differentiated services (DiffServ), which classifies services by general type.

DiffServ facilitates QoS by providing instructions to routers using the information in the type of service (ToS) field in the IP datagram header. Information in this field, for example, can specify voice-over-IP services, streaming video or non-real-time video, as well as provide differing priorities to each.

Alternatively, the video-over-IP network can use the IntServ architecture to provide a specific QoS for each service flow. IntServ-based networks use the Resource ReSerVation Protocol (RSVP) to ensure that the required network resources are available for the video service.

Multi-Protocol Label Switching (MPLS) facilitates QoS in a packet-switched IP environment by adding a header that includes three bytes for the QoS. MPLS supports both the IntServ and DiffServ architectures.

At the transport layer, either UDP or TCP can be used. UDP is a unidirectional transport protocol that doesn't receive feedback about whether the packets have been successfully received and decoded. However, it can time packet transmission against an external clock, making it useful for real-time audio and video streaming applications. TCP requires feedback in the form of acknowledgment messages, so it enables the reliable transmission of video packets.

Classes of service

When contracting for video-over-IP service, broadcasters typically enter into service-level agreements with third-party providers. These agreements specify the minimum or guaranteed levels of network performance, including availability, packet delivery ratio, packet loss ratio, network delay, delay variation, service response time and the time to repair a faulty link.

The broadcaster will also be concerned about the video (or packet) transmission rate and the class of service. Desirable transmission rates, of course, vary depending on the type of video content being transported and the encoding scheme, with HD MPEG-2 content for network distribution requiring significantly higher transmission rates than SD H.264 content.

IP network providers use classes of service or priority queues to manage the flow of multiple services across their networks. Real-time video traffic should be given a high priority class of service. The IEEE 802.1p standard established eight priority levels for service. (See Table 2.)

Network impairments

Many of the attributes guaranteed in the service level agreement can be measured to demonstrate a specific QoS. These attributes include the network availability percentage and network impairment measures, such as packet loss, packet reordering, network delay, switching delay and jitter.

Packet loss occurs when IP routers receive packets faster than they can forward them onto the network. Packet reordering measures significant impairments in received video quality when packets take different paths and arrive at the receiver in a different order. Network delay measures or specifies the typical amount of time that it takes for packets to move across the network (in milliseconds). In a service level agreement, this average can be specified over a week or month.

Switching delay causes problems with real-time video when a large number of routers in the transmission path create a large traffic queue, while jitter is the variation in the timing of when packets arrive at the destination. While some jitter is inevitable, it must be minimized in a network design if video is to be successfully decoded and played out in real time. Receivers accommodate jitter by buffering the incoming traffic.

Media delivery index

To improve video-over-IP services, the IETF issued RFC 4445, which specifies a media delivery index (MDI) to determine the quality of the delivered video service. The MDI is calculated through two measurements: delay factor and media loss rate. These two measurements capture many of the network impairments encountered in video-over-IP services.

Delay factor measures the time difference between the arrival of media data and the drain (or playout) of media data, measured for each packet. The delay factor, measured in bytes per second, indicates the amount of jitter that must be accommodated in the receiver buffer. When designing a network, the delay factor will be used to indicate how much latency the network must accommodate to ensure that receive buffers don't underflow from running out of received packets.

Media loss rate counts the number of lost or out-of-order packets over a time interval. Typically, seven 188-byte MPEG transport stream (TS) packets are contained within a single IP packet, so the loss of one IP packet could result in seven lost MPEG TS packets. Because receivers may not be able to reorder packets in the correct order, it is also important to count the number of out-of-order packets as a measure of network performance.

To calculate media loss rate, subtract the actual number of packets received during the measurement interval from the number of packets that were expected, and then scale that calculation to one second. The MDI is the ratio of delay factor (DF) to media loss rate (MLR), displayed as: MDI = DF:MLR. If an MDI equals 90:10, the delay factor is 90ms, and the link lost an average of 10 packets per second.

Testing to ensure QoS

Broadcasters using video-over-IP services can ensure that their services deliver a consistent and effective QoS by capturing and analyzing QoS metrics. An increasing array of commercial test equipment can calculate and display measures like the media loss rate. In addition, broadcasters should ensure that their services are meeting desired QoS levels by using such metrics in the management of their services.

David Glidden is an industry consultant and former industry executive.

Post New Comment
If you are already a member, or would like to receive email alerts as new comments are
made, please login or register.

Enter the code shown above:

(Note: If you cannot read the numbers in the above
image, reload the page to generate a new one.)

No Comments Found

Friday 01:36 PM
Making a Scene in London
Holly Ashford of TVB Europe

Featured Articles
Discover TV Technology