Framework for IPTV QoS

Framework for IPTV QoSGabriel LAZAR, Tudor Mihai BLAGA, Virgil DOBROTATechnical University of Cluj-Napoca, 400020 C-tin Daicoviciu 15, Cluj-Napoca, RomaniaE-mail: {zar; tudor.blaga;virgil.dobrota}@com.utcluj.roAbstract – The paper describes a framework for IPT V, with a practical implementation of the required QoS mechanisms. A cross-layer based solution enables QoS support for H.264 video streams at Network Layer. Selective dropping of packets based on their importance within the video stream is ensured by a new DiffServ per-hop behavior (PHB), suitable for real-time traffic (IPT V). T he third element is a tool for measuring QoS parameters like: bandwidth, one-way delay, inter-packet jitter, packet loss, number of duplicated packets, out-of-order packets and corrupted packets. The implementation of this program opens the possibility of measuring the transmission parameters that influence QoS, with the purpose of offering a way to evaluate and control the services delivered by open-standards IPTV providers.Keywords - IPTV, H.264, QoS, cross-layer1. INTRODUCTIONRecent years have seen a proliferation of real-time multimedia traffic over an increasingly heterogeneous Internet. A common case is that of IPTV over hybrid wireless-wired networks. This type of traffic has very stringent delay, jitter and bandwidth requirements. These parameters cannot be guaranteed when data is handled in a best effort manner. On top of that, users expect high service quality independent to the underlying network access technologies [1].Providing an IPTV service while maintaining a high level of perceived quality for the entire duration of the transmission becomes a challenging task. It requires cooperation of all involved “actors”: all network and end nodes and each layer of the protocols stack must collaborate and optimize functionality to achieve this goal [2].The IPTV concept includes both real time television and on demand television so called VoD (Video on Demand). Other services that IPTV can offer are Beyond TV, Time Shifted TV, on demand games and music, Electronic Program Guide, PVR functions, pay-per-view functions and parental control.In order to achieve a reliable end-to-end video communication system, the best-effort network should be replaced by a QoS-enabled core network, augmented where necessary with a cross-layer solution.In this article we propose a practical implementation for IPTV that includes an end-to-end H.264 video streaming solution using a cross-layer architecture (CLA) based on application and network layers. A new DiffServ per-hop behavior (PHB) is proposed, suitable for real-time traffic packets having different drop precedence values. We developed iptv_tool to measure IPTV QoS parameters during transmissions. 2. DIFFSERV – QoS ENABLED NETWORKInside the core network, Differentiated Services architecture (DiffServ [3]) can provide class-based QoS guarantees in a simple and scalable manner. Complex decisions are made in the edge routers, and useful edge-to-edge services are built from a set of PHBs in the core routers. A PHB defines the class of traffic to which a packet belongs, i.e. the treatmentof this datagram. This class is recognized by the core routers based on the DiffServ Code Point (DSCP) value, which is stored using the first 6 bits of the old Type-of-Service (TOS) IP header field. The DSCP value is usually set by the edge routers through multi-field (MF) classification and marking, but thebits can be also configured by the source client, e.g.at the application layer. Most common PHBs implemented in existing networks are Expedited Forwarding (EF) and Assured Forwarding (AF).EF PHB is used for low loss, low delay traffic, suitable for real-time multimedia services. AF defines four classes of traffic and three possible drop precedence values; the combination yields twelve separate DSCP encodings.3. REAL-TIME MULTIMEDIA STREAMINGH.264/AVC video standard offers significant improvement relative to existing standards through enhanced compression performance and provisionfor “network friendly” error resilience tools.To address the need for flexibility, H.264 specifies a video coding layer (VCL), designed foran efficient representation of the video content. Italso defines a network abstraction layer (NAL), which is responsible for the encapsulation of videodata into entities suitable for a variety of transport layers or storage media.161A NAL unit (NALU) consists of a one-byte header followed by a bit string that contains fixed sized picture partitions called macroblocks (MBs). An important field in the NALU header is the Nal_Ref_Idc (NRI) field. NRI consists of 2 bits that specify the priority of the payload: from 00 (lowest priority) to 11 (highest priority). The values are set by the encoder and they effectively specify the importance of the video information contained in each NALU payload. This is accomplished through an error resilience technique called data partitioning (DP) that groups video MBs into partitions with similar importance.Three partitions types are defined by H.264. Partition A contains important header information relevant for other partitions. Partition B contains intra coded block patterns (CBPs) and intra coefficients, and requires the A partition information. Partition C contains intra CBPs and intra coefficients, requires the A partition information and it is the least important partition type. In addition to these three partitions, VCL also generates a slice representing the instantaneous decoding refresh (IDR) pictures, which contains information that cannot be included into the A, B and C partitions. The parameter set concept (PSC) is the most important slice type created by VCL, where data is a combination of higher level parameters containing important information relevant for more than one slice (e.g. picture dimension) [4]. 4. QoS PARAMETERS FOR IPTVWhen referring to a communication channel, QoS handles a set of parameters, such as: bandwidth, one-way-delay, delay variation and packet loss [5]. Quality of Service means the capacity of a network to offer better services for a selected part of the traffic.Traffic rate: the total number of bytes sent divided by the duration of the transmission:>Bps durationon transmissi bytestotal rate Traffic ___@(1)One-way-delay is the time from the moment the first bit is sent to the moment the last bit is received. For measuring the one-way-delay parameter it is important to assure the synchronization between the server and the receiver.Jitter: the delay variation due to the fact that packets follow different paths from source to destination [6].Number of lost packets: The elimination of packets depends only on the current state of the network, and it cannot be anticipated. The algorithm used for determining this parameter identifies each packet sent by the server and searches for it in the received packet list.Number of reordered packets: Packets are sent in a certain order by an application, but at the receiver they may arrive out-of-order due to different paths in the network. A packet is considered reordered if the sequence number is smaller than the sequence number of the previous packet received.Number of duplicated packets: Counting the number of packets duplicated is a way of verifying the network configuration. Duplicated packets indicate that there are some configuration errors in the network or some devices are malfunctioning.Packet Error Rate (PER): is determined according to equation 2. To see if a packet is corrupted or not we compare the data field of every packet at the sender and at the receiver.%100____upacketsreceived number packetscorrupted number PER (2)START delay for VoD streaming is measured at the receiver and represents the duration between the moment the first TCP packet, containing signaling, is sent by the client until the moment the first RTP packet containing data is received. This parameter is relevant only for VoD transmissions.PAUSE/RESUME delay for the VoD server: VoD transmission uses RTSP that gives stream control to the receiver. This can suspend the stream and start it back later or it can move forward and backward within media stream. 5. IPTV QoS FRAMEWORKThe proposed framework includes a new PHB for multimedia traffic, a cross-layer streaming solution and a tool for monitoring IPTV QoS parameters. 5.1. A PHB for Multimedia TrafficVideo traffic has variable data rate due to the dynamic nature of the captured scene and the encoding process. Assigning an EF behavior to video streams in the DiffServ network can pose a policy design problem: because video streams have variable rates and due to the fact that multiple video streams are placed into the same flow aggregate (FA), it is hard to design a maximum limit for traffic policing at the ingress router of a DiffServ domain. If excessive EF traffic enters into the DiffServ domain, the EF PHBs from the core routers can cause starvation of other flow aggregates, by serving continuously EF packets at the highest priority. EF PHBs do not employ large queues, because EF traffic should be served at a rate equal or higher than the incoming rate, and also because waiting in a queue increases delay, which is not desired for real-time traffic. Excessive EF traffic in the core network will therefore lead very fast to full queues and large162packet drops. In this case, there is no protection against elimination of important packets. In a similar manner, excessive EF traffic at the border of the DiffServ domain will be policed regardless of the packet importance in the video stream.Using an AF DiffServ class for multimedia traffic raises a different problem. Drop priorities for AF PHBs are usually implemented with a form of RED [7]. Due to the mechanism’s statistical approach, in some cases important multimedia packets can be discarded (with lower probability) instead of less important ones - the priority dropping is not strict. In addition, AF traffic has lower priority than EF traffic.In order to overcome these limitations, we propose a different PHB for multimedia traffic with drop priorities, called Multimedia (MM) PHB. This class of traffic uses 3 DS code points in order to recognize packets with different importance in the stream. The MM PHB is defined for high-priority, low loss, latency and jitter traffic similar to EF, but additionally employs a strict drop precedence scheme: when resources become insufficient for the MM traffic, the DiffServ core router will always eliminate a packet with highest drop precedence from its queue. In this way, important packets have better chances to survive the end-to-end journey.A MM PHB can be implemented in a straightforward manner using a FIFO queue withstrict priority drop policy (Fig. 1).Fig. 1. MM PHB: 1=lowest, 3=highest drop priority Policing ingress MM traffic at the edge router can benefit of the 3 DSCP values to selectively drop less important packets first. The same DS code points can also be used at the data layer in each node to prioritize important traffic, if the MAC protocol offers QoS support. 5.2. Cross-Layer StreamingOur cross-layer solution takes into consideration the network layer in order to propagate the video related QoS information. NRI information extracted from the NALU header is mapped to DSCP field values at the IP network layer.The CLA at the source node was implemented using a combination of open source software:x Application Layer: a modified Linux build of VideoLan Client (VLC) [8], capable of H.264 video streaming, analyses each NALU and sets the socket’s SO_PRIORITY value for the current packet according to the NRI field.x Network Layer: Part of the Linux traffic control mechanisms, DSMARK is in charge of marking packets by setting their DSCP at the IP level. A DSMARK queuing discipline was configured at the source node to translate the SO_PRIORITY value to a DS code point. In this way, the NRI value is mapped to a DSCP through the SO_PRIORITY socket parameter sent between layers.5.3. IPTV ToolA minimal network architecture, that involves a media server, an IPTV client and a router, was used to develop iptv_tool . Both the client and the server were implemented using VLC. The VideoLAN Server sends data using protocols and codecs for IPTV streaming.The tool was implemented in C++ under Linux using gcc. The program uses as arguments the XML files containing the packets captured by Wireshark on the server interface and on the client interface. The capture files were exported in XML format because it can be parsed more easily than the original .pcap format.C++ functions from the libxml2 library (defined in xmlreader.h ) were used in order to read the values of the attributes contained in the XML file. This information, for example the total size of the packet or the timestamp, is saved and it is then used for packet identification and QoS parameter computation. Note that only the packets that belong to the IPTV stream are analyzed and included in the list. These packets are identified by the IP source and destination address and by the protocols and ports used for the transmission. The value of the attribute timestamp is read for every packet and saved into the list. The size of the packet is obtained from the attribute “frame size” field. The measurement of the one way delay parameter implies clock synchronization between the server and the receiver, because the delay is obtained by comparing the timestamps of the sent and received packet.6. TESTING AND RESULTSIn order to test the importance of policing based on drop priorities, a DiffServ edge router was configured using Linux QoS mechanisms to police traffic according to the DSCP value of each packet. Traffic conditioning was implemented with four policy filters combined with a DSMARK queue discipline. Out-of-profile traffic from a class is re-marked and sent to the lower priority class. The fourth filter is associated with best-effort traffic and out-of-profile packets are discarded.Preliminary tests were performed using the CLA-enabled client as traffic source, a DiffServ edge163router for traffic policing and a fast receiver. A H.264 encoded Foreman sequence was sent to the destination through the ingress router. The total rate was limited to 1.1 Mbps to enforce re-classification and dropping. The edge router discarded excess packets according to their DSCP set by the video source. A second experiment was performed with similar setup but, instead of priority dropping,packets were discarded randomly (Fig. 2).Fig. 2. Tesbed with CLA client and DiffServ ER Image quality was compared using peak SNR (PSNR) for each video frame, and the average PSNR (APSNR) was computed for both video sequences received at the destination node, relative to the source Foreman sequence (Fig. 3). The APSNR value obtained for the first experiment was 48.72 dB, higher than 31.13 dB obtained in the second (random drop) case, which shows the benefic effectsof DSCP based policing.Fig. 3. Priority Drop vs. Random Drop The validation of the iptv_tool was performed using a different scenario (Fig. 4). In order to avoid synchronisation issues the server and the client run on the same computer. The router redirects the packets received from the media server to the IPTV client, located on the same interface. This is performed by switching the source IP address with the destination IP address with the aid of iptables tool (in the PREROUTING and POSTROUTING chains). Wireshark filtering according to the ip.src and ip.dst parameters differentiates the sent and the received mediastreams, which are further saved in two files [9].Fig. 4. TestbedThe tc program, which is part of the iproute2toolkit was used to introduce delay and packet loss. We can specify the queuing discipline with qdisk and with the aid of netem we can configure the delay, packet loss, packet duplication and reordering.Several test scenarios were employed to validate the correct operation of iptv_tool . In the first one the packets were redirected, without any further delay or loss. Further scenarios with delay, loss, packet duplication, packet corruption and reordering were also considered (as in Table 1), either for realtime streaming or for VoD.Table 1. Realtime streaming/VoD test scenarios1234567delay [ms] 0100 0000100jitter [ms] 010000010loss 005%0005%error 00020%000duplication 0000010 % 5%reordering 025%010%7. CONCLUSIONIn this article we introduced the concept of areliable multimedia network, based on established or emerging technologies such as DiffServ or CL design that aims to ensure robust communication for real-time video traffic over heterogeneous network segments. In the core DiffServ network, a new multimedia PHB is presented together with a simple implementation. The framework includes a tool for QoS parameters measurement.Linux experiments show that ingress video traffic conditioning achieves better results when packets are discarded based on their priorities compared with the random drop case. The correct operation of iptv_tool was also proved.The proposed cross-layer solution will be extended to the Data Link layer with the aid of the MadWifi WLAN Linux driver for Atheros chipsets that allows the use of TOS or DSCP bits to select the required MAC access class. REFERENCES[1]J.Soldatos, et al “On the Building Blocks of Quality of Service in Heterogeneous IP Networks”, IEEE Communication Surveys & Tutorials, vol. 7, 2005.[2]S.Khan, et al. , “Application-Driven Cross-Layer Optimization for Video Streaming over WirelessNetworks”, IEEE Communication Magazine, vol. 44, no.1, pp. 122-130, January 2006[3]S.Blake, et al., “An Architecture for Differentiated Services”, RFC 2475, December 1998.[4]ITU-T Recommendation H.264, “Advanced Video Coding for Generic Audiovisual Services”, H.264 Standard, 2005.[5]G.Armitage, Quality of Service in IP Networks , New Riders Publishing, 2000[6] C.Demichelis, P.Chimento, “IP Packet Delay Variation Metric for IP Performance Metrics”, RFC3393, 2002 [7]S. Floyd and V. Jacobson, “Random Early Detection gateways for Congestion Avoidance” IEEE/ACMTransactions of Networking, vol. 1, no. 4, pp. 397-413, August 1993.[8][9]Wireshark, /164。