Universidade Federal de Pernambuco Centro de Informática Pós-Graduação em Ciência da Computação

“Video Streaming Optimization in ADSL Architecture”

Gustavo Gentil Barreto Santos Advisor: Dr. Djamel Sadok Co-advisor: Dr. Stenio Fernandes

Recife, november 2007

UNIVERSIDADE FEDERAL DE PERNAMBUCO CENTRO DE INFORMÁTICA PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO

GUSTAVO GENTIL BARRETO SANTOS

“VIDEO STREAMING OPTIMIZATION IN ADSL ARCHITECTURE”

THIS DISSERTATION HAS BEEN SUBMITTED TO THE COMPUTER SCIENCE CENTER OF THE FEDERAL UNIVERSITY OF PERNAMBUCO AS A PARTIAL REQUIREMENT TO OBTAIN THE DEGREE OF MASTER IN COMPUTER SCIENCE.

ADVISOR: DR. DJAMEL SADOK CO- ADVISOR: DR. STENIO FERNANDES

RECIFE, NOVEMBER/2007 ii

To my beloved wife Aline and my parents Anderson and Marilu. iii

Acknowledgments Thanks to God, because without him neither my existence nor this work would be possible. Thanks to Professors Djamel and Judith for all support given in both personal and professional difficulties. I would like to thank Professor Stenio for the patience and efforts in advising this dissertation. Thanks to everybody from GPRT (Networks and Telecommunications Research Group), who have helped and contributed in this work. Special thanks to Anderson, Augusto, Glauco, Josy, Rafael, Ramide and Rodrigo. I would also like to thank my wife Aline for understanding my absence during the period of this work and for keeping me always focused in my goals. Finally, I would like to thank my parents, Anderson and Marilu for making me continue with my dreams and for all support given since the beginning of this work.

iv

Summary Abbreviations and Acronyms

x

Abstract

xiii

Resumo

xv

1

Introduction

1

1.1 Motivation............................................................................................................................................. 6 1.2 Objective ............................................................................................................................................... 6 1.3 Work Structure ..................................................................................................................................... 7 2

Theoretical Background

9

2.1 xDSL Technology ................................................................................................................................ 9 2.1.1 2.1.2 2.1.3

ADSL Fundamentals ................................................................................................................................. 11 Physical Layer Issues ................................................................................................................................. 15 Link Layer Issues ....................................................................................................................................... 22

2.2 Video Content Issues ........................................................................................................................ 24 2.2.1 2.2.2 2.2.3 2.2.4 2.2.5 2.2.6

Digital Television and IPTV .................................................................................................................... 24 MPEG Overview ....................................................................................................................................... 28 MPEG Video Structure ............................................................................................................................ 30 Profiles and Levels..................................................................................................................................... 31 MPEG Algorithm ...................................................................................................................................... 32 Packetization ............................................................................................................................................... 33

2.3 Noise Impairments ............................................................................................................................ 35 2.3.1 2.3.2 2.3.3 2.3.4

Additive White Gaussian Noise – AWGN ........................................................................................... 35 Crosstalk ...................................................................................................................................................... 36 Radio Noise ................................................................................................................................................ 37 Impulse Noise ............................................................................................................................................ 37

2.4 Video Quality Assessment................................................................................................................ 38 2.4.1 2.4.2

3

Subjective Video Quality Metrics ............................................................................................................ 38 Objective Video Quality Metrics ............................................................................................................. 39

Related Work

42

3.1 Video Streaming Impairments ......................................................................................................... 42 3.2 Overcoming Video Streaming Impairments.................................................................................. 44 3.3 Evaluating Video Impairments ........................................................................................................ 49 4

Performance Evaluation 4.1 4.2 4.3 4.4 4.5 4.6 4.7

51

Testbed Setup ..................................................................................................................................... 51 Analyzing ADSL Metrics and Parameters ..................................................................................... 53 Layer 3 and Application metrics ...................................................................................................... 59 Analyzing Video Traffic.................................................................................................................... 62 Analyzing video traffic with concurrent traffic with no QoS ..................................................... 70 Noise Modeling .................................................................................................................................. 76 REIN Impact on Video Traffic ....................................................................................................... 79 v

5

Video Streaming Optimization 5.1 5.2 5.3 5.4 5.5

6

83

SNR margin effectiveness against REIN ....................................................................................... 83 Interleaving Delay effectiveness against REIN ............................................................................. 85 INP effectiveness against REIN ..................................................................................................... 88 Analyzing video traffic with concurrent traffic with QoS ........................................................... 90 Advisable ADSL Line Configuration ............................................................................................. 94

Conclusions and Future Work

96

6.1 Contributions ..................................................................................................................................... 97 6.2 Future Work ....................................................................................................................................... 97 7

References

99

vi

List of Figures Figure 1 Copper wire frequency usage by ADSL and POTS [67]. ...................................................... 3 Figure 2 End to end video delivery scheme [4] ..................................................................................... 6 Figure 3 An End-to-End transmission through PSNT infra-structure [56]. ................................... 10 Figure 4 ADSL Access Network and its required equipments [56]. ................................................. 12 Figure 5 Spectrum utilization by CAP coding [56]. ............................................................................. 17 Figure 6 Spectrum utilization by DMT coding [56]............................................................................. 18 Figure 7 Different formats and scanning modes for HDTV and SDTV ......................................... 25 Figure 8 Different Layers for the Digital Video Transmission Architecture ................................... 26 Figure 9 Video Transmission using multicast ....................................................................................... 28 Figure 10 Video Transmission using unicast ........................................................................................ 28 Figure 11 Combination of YUV (YCbCr) Components ..................................................................... 29 Figure 12 Y Component (Y).................................................................................................................... 29 Figure 13 U Component (Cb) ................................................................................................................. 29 Figure 14 V Component (Cr) .................................................................................................................. 29 Figure 15 MPEG Compression stages for both spatial and temporal redundancies removal [61]33 Figure 16 PES packet structure [32] ....................................................................................................... 34 Figure 17 MPEG TS packet structure [32]............................................................................................ 35 Figure 18 NEXT and FEXT noise when coupled to the transmission [67] .................................... 36 Figure 19 Testbed Organization for running the experiments ........................................................... 53 Figure 20 Downstream rates for different loop length ....................................................................... 54 Figure 21 Upstream rates for different loop length ............................................................................. 54 Figure 22 Downstream Interleaving Delay for different loop length ............................................... 55 Figure 23 Upstream Interleaving Delay for different loop length ..................................................... 55 Figure 24 Downstream SNR margin for different loop length ......................................................... 56 Figure 25 Upstream SNR margin for different loop length ............................................................... 56 Figure 26 Downstream INP value for different loop length ............................................................. 57 Figure 27 Upstream INP value for different loop length ................................................................... 57 Figure 28 Downstream Interleaving Depth for different loop length .............................................. 58 Figure 29 Upstream Interleaving Depth for different loop length.................................................... 58 Figure 30 Downstream FEC Bytes for different loop length ............................................................ 58 Figure 31 Upstream FEC Bytes for different loop length .................................................................. 58 Figure 32 Downstream Bits per Symbol for different loop length ................................................... 59 Figure 33 Upstream Bits per Symbol for different loop length ......................................................... 59 Figure 34 Synchronization of the transmitted frames with their correspondent from the original video .................................................................................................................................................... 61 Figure 35 Synchronization algorithm and step by step example having the window size of 3 ..... 62 Figure 36 Received video rate at the multimedia client for different loop lengths ......................... 66 Figure 37 Different videos average delay for different loop lengths................................................. 67 Figure 38 Different videos jitter for different loop lengths ................................................................ 68 Figure 39 Packet Loss in percents for different loop lengths ............................................................ 69 Figure 40 PSNR calculation for video with different bitrates and loop lengths ............................. 70 Figure 41 Received video rate at the multimedia client for the 50% background traffic ............... 72 Figure 42 Received background traffic rate at the multimedia client for the 50% background traffic .............................................................................................................................................................. 72 Figure 43 Received video rate at the multimedia client for the 100% background traffic ............ 72 Figure 44 Received background traffic rate at the multimedia client for the 100% background traffic .............................................................................................................................................................. 72 Figure 45 Video traffic delay for the 50% background traffic scenario .......................................... 73 vii

Figure 46 Background traffic delay for the 50% background traffic scenario................................ 73 Figure 47 Video traffic delay for the 100% background traffic scenario ........................................ 73 Figure 48 Background traffic delay for the 100% background traffic scenario ............................. 73 Figure 49 Video traffic jitter for the 50% background traffic scenario ........................................... 74 Figure 50 Background traffic jitter for the 50% background traffic scenario ................................ 74 Figure 51 Video traffic jitter for the 100% background traffic scenario ......................................... 74 Figure 52 Background traffic jitter for the 100% background traffic scenario .............................. 74 Figure 53 Video traffic packet losses for the 50% background traffic scenario ............................ 75 Figure 54 Background traffic packet losses for the 50% background traffic scenario .................. 75 Figure 55 Video traffic packet losses for the 100% background traffic scenario .......................... 75 Figure 56 Background traffic packet losses for the 100% background traffic scenario................ 75 Figure 57 PSNR values for the 50% background traffic scenario ..................................................... 76 Figure 58 PSNR values for the 100% background traffic scenario ................................................... 76 Figure 59 REIN Signal Composition ..................................................................................................... 77 Figure 60 1A Noise Profile Modeling .................................................................................................... 78 Figure 61 1B Noise Profile Modeling .................................................................................................... 78 Figure 62 2B Noise Profile Modeling .................................................................................................... 79 Figure 63 Packet loss for noise profiles with different frequencies .................................................. 82 Figure 64 Packet loss for noise profiles with different burst length ................................................. 82 Figure 65 PSNR for noise profiles with different frequencies ........................................................... 82 Figure 66 PSNR for noise profiles with different burst length .......................................................... 82 Figure 67 Packet loss for 1A noise profile and different SNR margin configuration .................... 84 Figure 68 Packet loss for 2A noise profile and different SNR margin configuration .................... 84 Figure 69 Video PSNR for 1A noise profile and different SNR margin configuration ................. 85 Figure 70 Video PSNR for 2A noise profile and different SNR margin configuration ................. 85 Figure 71 Average packet delay for Noise 1A ...................................................................................... 87 Figure 72 Average packet delay for Noise 2A. ..................................................................................... 87 Figure 73 Packet Loss for Noise 1A and different INP values ......................................................... 89 Figure 74 Packet Loss for Noise 2A and different INP values ......................................................... 89 Figure 75 INP impact on the downstream rate .................................................................................... 90 Figure 76 Received video rate at the multimedia client for the 50% background traffic............... 92 Figure 77 Received background traffic rate at the multimedia client for the 50% background traffic .............................................................................................................................................................. 92 Figure 78 Video traffic delay at the multimedia client for the 50% background traffic................. 92 Figure 79 Background traffic delay at the multimedia client for the 50% background traffic ...... 92 Figure 80 Video traffic jitter at the multimedia client for the 50% background traffic ................. 93 Figure 81 Background traffic jitter at the multimedia client for the 50% background traffic ....... 93 Figure 82 Received video rate at the multimedia client for the 50% background traffic............... 94 Figure 83 Received background traffic rate at the multimedia client for the 50% background traffic .............................................................................................................................................................. 94

viii

List of Tables Table 1 Resistance for some wire gauges. .............................................................................................. 16 Table 2 Related problems and parameters to the ADSL Line. .......................................................... 22 Table 3 Some profiles defined by the MPEG standard ...................................................................... 32 Table 4 Some levels defined by the MPEG standard .......................................................................... 32 Table 5 Experiment Setup Parameters. ................................................................................................. 54 Table 6 Experiment Setup Parameters. ................................................................................................. 65 Table 7 Possible PSNR to MOS mapping ............................................................................................ 69 Table 8 Experiment Setup Parameters. ................................................................................................. 71 Table 9 REIN Noise Profiles. ................................................................................................................. 77 Table 10 REIN Noise Profiles. ............................................................................................................... 80 Table 11 Experiment Setup Parameters. ................................................................................................ 80 Table 12 Experiment Setup Parameters. ................................................................................................ 83 Table 13 Achieved downstream rate for different SNR margin values ............................................ 84 Table 14 Experiment Setup Parameters. ................................................................................................ 86 Table 15 Experiment Setup Parameters. ................................................................................................ 91

ix

Abbreviations and Acronyms CAP 3P Services AAC AAL ADSL ADSL2 ADSL2+ AM ANSI ATM ATSC ATU-C ATU-R AWG AWGN BER CATV CBR CD CLE CO CoS CPE CRC DCT DiBEG D-ITG DMT DSIS DSL DSLAM DTV DVB DVD EIA ES FDD FEC

Carrierless Amplitude and Phase Modulation Triple Play Services Advanced Audio Coding ATM Adaptation Layer Asymmetric Digital Subscriber Line Asymmetric Digital Subscriber Line - Version 2 Asymmetric Digital Subscriber Line - Version 2 Plus Amplitude Modulation American National Standards Institute Asynchronous Transfer Mode Advanced Television Systems Committee ADSL Termination Unit – Central ADSL Termination Unit – Remote American Wire Gauge Additive White Gaussian Noise Bit Error Ratio Cable TV Constant Bit Rate Compact Disc Cell Loss Error Central Office Class of Service Customer Premise Cyclic Redundancy Check Discrete Cosine Transform Digital Broadcasting Experts Group Distributed Internet Traffic Generator Discrete Multitone Double Stimulus Impairment Scale Digital Subscriber Line Digital Subscriber Line Access Multiplexer Digital Video Digital Video Broadcasting Digital Versatile Disc Electronic Industries Association Elementary Stream Frequency Division Duplex Forward Error Correction x

FEXT FR FTTC FTTH G-HDSL GOP HDSL HDTV HFC HSV IDCT IDSL IEC IEEE IGMP INP IP ISDB ISO ITU JCIC MBS MCR MIB MOS MPEG MPEG PS MPEG TS MPQM MSE NAB NCTA NEXT NR NS-2 NTP NTSC OFDM OID OSI P2P PAL PCR

Far-End Crosstalk Full Reference Fiber To The Curb Fiber To The Home G - Symmetric high-speed Digital Subscriber Line Group of Pictures High-bit-rate Digital Subscriber Line High Definition TV Hybrid Fiber-Coax Human Visual System Inverse Discrete Cosine Transform ISDN Digital Subscriber Line International Electrotechnical Commission Institute of Electrical and Electronic Engineers Internet Group Management Protocol Impulse Noise Protection Internet Protocol Integrated Services Digital Broadcasting International Organization for Standardization International Telecommunication Union Joint Committee on InterSociety Coordination Maximum Burst Size Minimum Cell Rate Management Information Base Mean Opinion Score Moving Picture Experts Group MPEG Program Stream MPEG Transport Stream Moving Pictures Quality Metric Mean Square Error National Association of Broadcasters National Cable Television Association Near-End Crosstalk Non Reference Network Simulator - Version 2 Network Time Protocol National Television Standards Committee Orthogonal Frequency Division Multiplexing Object ID Open Systems Interconnection Peer to Peer Phase Alternating Line Peak Cell Rate xi

PDU PES PIB POTS PSD PSNR PSTN PVC QAM QoE QoS REIN RF RLE RR RS RTP SCR SDSL SDTV SECAM SMPTE SNR SSCQE SSIM STB TCP TV UBR UDP UMTS VBR VC VDSL VLC VLC VOD VoIP VQEG VQM

Protocol Data Unit Packetized Elementary Stream General Purpose Interface Bus Plain Old Telephone Service Power Spectral Density Peak Signal-to-Noise Ratio Public Switched Telephone Network Permanent Virtual Circuit Quadrature Amplitude Modulation Quality of Experience Quality of Service Repetitive Electrical Impulse Noise Radio Frequency Run Length Coding Reduced Reference Reed-Solomon Real-Time Transport Protocol Sustainable Cell Rate Symmetric Digital Subscriber Line Standard Definition TV Séquentiel Couleur À Mémoire Society of Motion Picture and Television Engineers Signal-to-Noise Ratio Single Stimulus Continuous Quality Evaluation Structural Similarity Index Set-Top Box Transmission Control Protocol Television Unspecified Bit Rate User Datagram Protocol Universal Mobile Telecommunications System Variable Bit Rate Virtual Circuit Very high speed Digital Subscriber Line Variable Length Coding VideoLAN Client Video on Demand Voice over IP Video Quality Experts Group Video Quality Metric

xii

Abstract With the evolution of the broadband market and the decline of the traditional voice services, telecom service providers need to offer a larger combination of services to maintain competitiveness and gain market share. Video and audio content are now available like never before. With the seamless delivery of voice, video and data services, Triple Play Services (3P) are essential for operators and service providers to retain their customer base. The delivery of Internet Protocol TV (IPTV) using DSL connections is a technology that brings new business opportunities to service providers. DSL technologies such as ADSL2+, have data rates that make them possible to combine voice, video and data services over a single telephone line. Taking these technological enhancements into consideration, ADSL2+ has a theoretical bandwidth of 24 Mbps, which would be enough to deliver several SDTV (1.5~4 Mbps – depending on the codec used) and HDTV (8~12 Mbps – depending on the codec used) television channels to the residential user. However, factors such as noise and distance between user and service provider can make this scenario impractical. In addition, there are numerous factors involved in the delivery of IPTV across the core network and its transmission to the customer over ADSL2+ connections. In general, video service providers first code the video signal usually using MPEG-2 or MPEG-4. Video streaming applications require uninterrupted data transfer, but the smallest packet losses can result in a great quality degradation. Packet loss can be caused in two different ways. By noise, which can be found in any transmission environment and can be a real undesired effect that may introduce more errors than expected, or by buffer overflow in different elements of the network.

Moreover,

delay and jitter can have crucial impact on the video delivery. This work tackles the Video Streaming impairments in different scenarios, such as noisy environments, concurrent background traffic and different distances from the customer and service provider. Variables related to the ADSL infrastructure, e.g. noise protection and QoS mechanisms, are observed and their adjustments are made in order to give improvements to the video quality. Parameters related to Layer 1, 2, 3 and application level are studied and analyzed in this work. In addition, different sort of noises, such as REIN, are added to simulate transmission problems that might occur in a real streaming scenario. The experiments show that for different scenarios where different kind of impairments are coupled to the line, there are many factors, such as INP, SNR Margin, Interleaving Delay, that can be adjusted aiming to optimize the video quality. At the end of xiii

this work, a desirable configuration for a real video transmission over ADSL systems has been advised in order to mitigate the existing problems.

Keywords: Video Streaming, ADSL, Video Quality, Network Measurements

xiv

Resumo Com a evolução do mercado de banda larga e a diminuição dos serviços de telefonia tradicionais, os provedores de serviço de telefonia têm a necessidade de oferecer uma grande gama de serviços para se manter competitivo e obter novas fatias do mercado. Novos serviços de áudio e vídeo podem ser oferecidos como nunca antes. Com a junção de serviços de voz, dados e vídeo, serviços Triple Play (3P) são essenciais para que as operadoras e provedores de serviço mantenham sua base seus usuários atuais. O oferecimento de serviços IPTV usando conexões DSL é uma tecnologia emergente que traz novas oportunidades de negócios para os provedores de serviços. Tecnologias de banda larga como o ADSL2+ possuem taxas de dados que tornam possível combinar serviços de voz, vídeo e dados utilizando uma única linha telefônica. Levando em consideração essas melhorias tecnológicas, o padrão ADSL2+ consegue obter taxas de 24 Mbps na teoria, o que seria o suficiente para oferecer alguns canais SDTV (1.5~4 Mbps – dependendo do codec utilizado) e HDTV (8~12 Mbps – dependendo do codec utilizado) para o usuário residencial. Entretanto outros fatores como ruídos e a distancia entre o usuário e o provedor de serviços pode tornar esse cenário impraticável. Na maioria das vezes o provedor de serviços de vídeo codifica o sinal utilizando o MPEG-2 ou MPEG-4. Aplicações de vídeo em rede requerem transferência de dados ininterrupta, pois a perda de poucos pacotes pode resultar em uma grande perda de qualidade do vídeo. Perda de pacotes pode ser causada de duas maneiras distintas. Por ruídos, que podem ser encontrados em qualquer ambiente de transmissão e podem gerar um efeito indesejável, introduzindo mais erros que o esperado durante a transmissão, ou por estouro do buffer em diferentes elementos da rede. Além do mais, em determinados cenários, a influência do delay e do jitter pode ser crucial na entrega do vídeo para o usuário. Este trabalho aborda os problemas presentes na transmissão de vídeo numa infra-estrutura ADSL, ilustrando diferentes cenários, tais como ambientes com ruído, com tráfego concorrente e diferentes distancias entre o usuário e a provedora de serviço. Variáveis relacionadas à infra-estrutura ADSL, como, por exemplo, proteção a ruído e mecanismos de QoS são observados e ajustes são realizados na intenção de oferecer ao usuário final uma melhoria na qualidade do vídeo. Parâmetros relacionados as Camada 1, 2 e 3 e a nível de aplicação são estudados e analisados. Além disso, diferentes tipos de ruídos na transmissão, tal como REIN, serão inseridos no intuito de simular xv

problemas existentes em um cenário real. Os resultados gerados pelos experimentos mostram que para diferentes tipos de problemas agregados a linha, existem muitos fatores, tais como INP, SNR, Interleaving Delay, que podem ser ajustados visando a melhoria da qualidade do vídeo. No final deste trabalho é apresentada uma configuração desejável para sistemas ADSL no processo de transmissão de vídeo visando minimizar os problemas existentes na linha.

Palavras chave: Transmissão de vídeo, ADSL, Qualidade de vídeo, Medições de rede

xvi

1 Introduction “Beneath this mask there is more than flesh. Beneath this mask there is an idea, and ideas are bulletproof.”

Quote from the movie V for Vendetta

In recent years, many efforts have been made to stream multimedia content through the existing network infrastructure. In addition, a great deal of changes has appeared in the telecommunication industry. While the available bandwidth has been growing quickly, the operators and service providers realized that they could explore much more the actual Internet scenario. Furthermore, Triple Play Services (Voice, Video and Data) are being deployed more than ever before. Consequently, operators and service providers have initiated efforts to engineer their networks to provide commercial package services covering Voice over IP (VoIP), Standard Definition TV (SDTV) and/or High Definition TV (HDTV) in combination with the Internet accessibility. With this new growing market in mind, service providers find themselves having to change business strategies to continue their growth and supply costumers needs. Faced with fierce competition and regulatory uncertainty, service providers are looking at video delivery to increase revenues and deflect competition. However, profitable video delivery requires carriers to think carefully about how best to invest into their network infrastructure [1]. All of this coincides with increasing global deployment of broadband access technologies, many of which are being used to deliver IP-based services and applications to customers at increasingly faster speeds [14]. In the past, there have been attempts to bring faster access speed and to reduce the existing bottleneck to consumers, each with various degrees of success. Today, the most popular broadband access technologies today are cable modems and Digital Subscriber Lines (DSL), which are being deployed across the globe. Although each technology has its advantages and drawbacks, DSL seems to be promising because it is backed by virtually all phone companies, plus the technology has room to grow [56]. The DSL technology is widely used because it achieves broadband speeds provides a greater bandwidth comparing to the old dial-up connections that reached the maximum of 56Kbps, and utilizes the some ordinary copper wires medium as of the POTS (Plain Old Telephone Service). 1

While DSL technology offers dramatic speed improvements (up to 8+ Mbps downstream and 1+ Mbps upstream) compared to other network access methods, the real strength of DSL-based services lies in the opportunities driven by [67]: •

Multimedia applications required by today's network users

•

Performance and reliability

•

Economics The basic idea of the DSL system is to use frequencies that are not used by the POTS. Taking

into account that POTS utilizes only frequencies up to 4 KHz and the wire twisted pair is capable to transmit data in higher frequencies than 4 KHz. The properly usage of those frequencies higher than 4 KHz is made by employing different modulation techniques such as DMT (Discrete Multitone) and Carrierless Amplitude and Phase Modulation (CAP). There are also many existing flavors of the DSL technology, but the one mostly used is the Asymmetric Digital Subscriber Line (ADSL). In the ADSL technology, the asymmetric term is used because the downstream bandwidth differs from the upstream one. The picture in Figure 1 depicts how the frequencies are used by the ADSL and the POTS together. Although ADSL offers great rate1 enhancements comparing to 56 Kbps obtained in earlier dial-up connections, the obtained rate is dependent on many factors present in the content delivery process, as ADSL utilizes the copper pair circuit. Some of these factors are wire gauge, distribution point joints, crosstalk, radio frequency interference, line attenuation and impulse noise [25]. As we have seen above, many new technologies have emerged to allow broadband access to home users. As an attempt to make it possible many compression techniques were proposed to guarantee that even applications with large data rates could be used with low bandwidth connections. Since video and other multimedia data are usually too large for raw transmission or storage, most video streams are compressed before transmission over a packet–oriented network [8] [7].

1

Rate is the obtained data rate in the Physical Layer

2

Figure 1 Copper wire frequency usage by ADSL and POTS [67].

There are two most commonly used compression schemes classes for data compression: lossy or lossless techniques. When a lossless compression technique is used, the original data can be reconstructed from the compressed data in its exact original form. In a simple manner, this is possible because the algorithm uses the intrinsic redundancy that is existent in the whole data. On the other hand, a lossy technique cannot obtain the exact original data from the compressed data. This technique is frequently used in cases that even with the loss in a particular case, the effect is not noticeable. These algorithms often have a compression level that measures how compressed the raw data becomes after the algorithm is applied. The compression level is sometimes called compression rate. Thus, there is a tradeoff between compression rate and quality of compressed data. When the compression rate increases then the quality of compressed data decreases and when the compression rate decreases then the quality of compressed data increases. It is worth emphasizing that a given compression algorithm is suitable to only a few specific types of application data. For instance, it is not certain that a good compression technique for audio will have the same results for video and vice versa. The main objective of video compression is to remove redundancy in the original source signal. Moreover, the objective is not restricted to reduce the space occupied by the original data, but also to guarantee a good quality of the compressed data, to minimize the compression complexity and to reduce the overall encoding/decoding delay. With all these requirements, choosing a compression scheme can be a tough task. Video compression is possible because of [59]: 3

•

Spatial redundancy among neighboring pixels in a given picture frame

•

Spectral redundancy among color images within frames

•

Temporal redundancy among pixels or blocks of pixels in different frames

•

Considerable irrelevant information from a perceptual viewpoint in the information contained in a video data.

A good compression scheme can exploit these four points to produce high compression rates and in the same time it maintains a good quality level. Considering the redundant information contained in the raw data, it is also known that human eyes are not so sensitive to some non redundant information contained in the raw data as well. So, taking this into consideration, it is possible to employ lossless encoding techniques (such as Huffman coding) and approximate the information which is not important for the sake of human perception of the quality. For example humans do not distinguish between two video sequences one of them encoded at 30 frames per second and the other at 60 frames per second. In addition we are more sensitive to luminance variation than chrominance information [59]. Many institutions including the International Telecommunication Union (ITU) and International

Organization

for

Standardization/International

Electrotechnical

Commission

(ISO/IEC) published some standards for video/audio compression in terms of storage, internet streaming and Digital Video (DTV). The most important video codec standards for streaming video are H.261, H.262, H.263, H.264, MPEG-1, MPEG-2 and MPEG-4. Although these standards have different names, they propose the same algorithm, as H.264 which is an implementation of the MPEG-4 part 10. The Moving Picture Experts Group (MPEG) was established in January 1988 with the mandate to develop standards for coded representation of moving pictures and audio. It operates in the framework of Joint ISO/IEC Technical Committee (JTC 1) on Information Technology. Starting from its first meeting in May 1988 when 25 experts participated, MPEG has grown to an unusually large committee. Usually some 350 experts from around 200 companies and organizations, from about 20 countries take part in MPEG meetings [60]. The MPEG committee has already standardized MPEG-1, MPEG-2 and MPEG-4 (versions 1 and 2) and in their last phases of development they are working on MPEG-4 (version 3, 4 and 5), MPEG-7 and MPEG-21. Despite the name MPEG, they also define other components than only 4

video compression algorithms. These standards are composed of different parts which define issues related to video, audio, systems, and conformance tests, among others. Both MPEG-1 and MPEG-2 standards are similar in basic concepts. They both are based on motion compensated block-based transform coding techniques similar to those employed in H.263. However, MPEG-4 employs more sophisticated approaches. Even with the existence of MPEG-4, MPEG-2 still has a crucial contribution in many applications and telecommunication systems. MPEG-2 is intended to be generic in the sense that it serves a wide range of applications, bitrates, resolutions, qualities and services. Applications should cover, among other things, digital storage and television broadcasting. The choice of the compression algorithm depends on the available bandwidth or storage capacity and the features required by the application. MPEG-2 standard is a truly integrated audio-visual standard and is capable of compressing National Television Standards Committee (NTSC) or Phase Alternating Line (PAL) video into an average bit-rate of 3Mbps to 6 Mbps with a quality comparable to analog Cable TV (CATV). It is a widely used standard in today’s visual multimedia applications [19]. In the new era of DTV, leaving the old PAL and NTSC behind, the DVB (Digital Video Broadcasting), ISDB (Integrated Services Digital Broadcasting) and ATSC (Advanced Television Systems Committee) makes use of MPEG-2 to send video signals to the customer’s home. This is possible because MPEG-2 defines how applications should behave for a lot of different scenarios requirements and restrictions. Figure 2 shows an end to end design of multimedia transmission in many different formats such as DVB and VoD (Video on Demand). In addition, it shows that the end user is capable of receiving different services as voice, video and data, as we have mentioned previously.

5

Figure 2 End to end video delivery scheme [4]

MPEG-2 video syntax defines three different types of pictures: I-frames (Intra Frames) are encoded without any temporal compression techniques. Lossy and lossless coding are employed on the current picture without reference to the adjacent frames. Inter frames (P or B) however, are encoded by taking into account motion prediction techniques (removing the temporal redundancy among frames) as well as those employed to encode I frames. Hence, the bit rate of I frames is very large compared to both P and B frames [59].

1.1 Motivation Since the beginning of digital data transmission, video transmission is a challenging task due to data rates achieved when using old dial-up connections. With the enhancements made using new broadband technologies, such as ADSL and Cable Modems, now video streaming has become part of our lives. However, there are many other factors involved in the multimedia content delivery. Impairments existence in the transmission medium can degrade video quality badly because of packet losses. Although packet loss represent a great impairment in the video transmission, other metrics like delay and jitter are also very important because they can have a considerable impact in video quality.

1.2 Objective The main objetive of this work is to propose an ADSL line configuration that brings enhancements to the video streaming process. This enhancement is obtained after a detailed analysis and investigation of the impact of the parameters related to the ADSL line, such as Impulse Noise Protecion, SNR (Signal to Noise Ratio) margin, Interleaving Delay among others. Moreover, we 6

present results for the equipments being used in our experiments and show whether they are in compliance with the standards implemented by their manufacturers. For more reliable results, an investigation was made to observe the impact of these metrics for different scenarios and diverse kind of videos. These scenarios includes impairments such as noises, concurrent background traffic being transmitted together with video traffic and the video traffic bahavior for different distances from the Central Office (CO) and the Customer Premise (CPE). With this investigation we are able to set parameters in the Layer 1 and Layer 2 that optimizes video traffic which is rolled out through an ADSL access network. At the end of this work we present a guideline for the ADSL line configuration that encloses different scenarios when video content is delivered to the end user’s home.

1.3 Work Structure This dissertation has been organized in the following way. Chapter 2 describes the xDSL technology and presents the advantages and disadvantages when this technology is deployed, such as noise protection techniques and the impact of different sort of noises over the system. In addition some details about video compression techniques and video quality assessment are given. Chapter 3 presents related works in the video streaming and ADSL area and several open research issues, as the lack of bandwidth, and jitter and delay problems when streaming video content. Moreover this chapter explains how researchers try to overcome these problems and what methodologies are used in order to support their approach. Chapter 4 shows details about how the testbed was set up and the methodology used in order to conduct the experiments. Moreover, it explains the structure of the equipments, third part tools used, and software/scripts developed to run the experiments and to extract the required information. In addition, it illustrates the first experiments, which familiarize readers to the ADSL metrics and parameters, and some results that demonstrate the existing problems when streaming video over a noisy environment and having concurrent background traffic. In the Chapter 5 the obtained insights, as the impact of long ranges from the CPE and CO on the video transmission, from the first experiments conducted in Chapter 4 are used, and based on the considerations made along the entire Chapter 4, we were able to make more focused experiments and utilize better parameters values so that the video streaming process can take benefit from the new line configuration. Here the new line configuration is a collection of parameters that 7

we are able to set within the ADSL line and equipments. The scenarios and considerations about the experiments are also shown in this chapter. Finally, conclusions, including a list of noticed contributions and some future work are shown in the Chapter 6.

8

2 Theoretical Background “If a man hasn't discovered something that he will die for, he isn't fit to live.”

Martin Luther King Jr.

This chapter has the goal of explaining the technologies involved in this work, allowing a better understanding of the objectives presented. Section 2.1 presents the xDSL technology, its flavor, its infra-structure and how the existing telephone copper wires were used to provide broadband access to the customer’s home. In Section 2.2 some fundamentals about the video transmission scenario and new trends about this technology are presented. Impairments that might exist in data transmission, such as noises characteristics are presented in Section 2.3. Finally, Section 2.4 presents methods and different approaches in order to assess video quality.

2.1 xDSL Technology When we go back in time, just to the 90’s, we consider those 300 and later 2400 baud modems that we used to think that data transfer speed could not get any faster. Then, when encoding algorithms became more efficient and telephone lines became cleaner of electrical interference, V.90 standard emerged and 56 kbps of data could be transferred through the telephone copper line. When modem was in use, the applications were based mainly in text data transfer. Corporations were the majority of the users who had a need for employees or vendors to access and use a corporate database. For that purpose, modem had to deal with digital bits and convert into analog signals. Those analog waves were then transmitted through a Public Switched Telephone Network (PSTN), also known as Plain Old Telephone Service (POTS). These waves were received by another modem, which converted these signals into digital bits again so that the receiver computer could understand.

9

Figure 3 An End-to-End transmission through PSNT infra-structure [56].

With new resources, in recent years what is called broadband connection has become reality to the home users. One possibility for this high-speed connection could be the use of technologies such as fiber, whether fiber to the curb (FTTC), fiber to the home (FTTH), or hybrid fiber-coax (HFC). A few years ago, telcos (Telephone Companies) became aware of the great possibilities when utilizing very high bandwidth of fiber to carry digital signals, though a new structure would be necessary to deliver data to the customer. This is where DSL (Digital Subscriber Line) takes place. DSL is a broadband connection invented by BellCore in the mid-1980s that utilizes existing telephone copper wire to deliver data through the last mile between network service providers and the users of those network services. In the beginning the goal of DSL was to deliver voice and video to the customer. Because the technology was not mature to efficiently achieve what had been invented for. DSL was forgotten for almost a decade. After this period phone companies realized that their voice network became overloaded with data. xDSL is used as a general term to identify a great variety of DSL standards. Some of the xDSL flavors are: • SDSL – It has a symmetric nature, which means that the same bandwidth is available both for upstream and downstream direction. It can achieve rates up to 2.3 Mbps and uses 2B1Q encoding. The typical distance from the CO and CPE using SDSL standard is approximately 4 km. • HDSL – Known as High-bit-rate Digital Subscriber Line, this standard made use of 2B1Q at higher speeds as an alternate way to provide T1 and E1 services, without repeaters. The technique consists of splitting the 1.544 Mbps service into two pairs (four wires), in which each pair ran at 788 Kbps. By splitting the service across two lines and increasing the bits per baud, the per-line speed and the need for frequency spectrum could be reduced to allow longer loop reach. • G.shdsl – It is considered to be the next generation of symmetric services. This standard encompasses all functions which are currently provided by the European SDSL standard and HDSL2. It uses copper wire pair circuit to deliver data to the customer. It may have different bitrates and it is able to negotiate the framing protocol. This multirate replacement for proprietary SDSL offers symmetric bandwidths between 192 Kbps to 2.3 Mbps, with a

10

30 percent longer loop reach than SDSL and improved spectral compatibility with other DSL variants within the network. G.shdsl is expected to be applicable worldwide. • IDSL – It is based in ISDN standard and uses 2B1Q encoding. Differently from ISDN that enables dynamically initiation/termination of the connection, the IDSL has a permanent connection. IDSL can achieve symmetric bandwidths up to 144 Kbps in both directions. • VDSL - VDSL (Very high speed Digital Subscriber Line) aims to deliver downstream data up to 52 Mbps. However, this high data rate decreases quickly when the distance increases. To achieve such high bitrates, VDSL uses bandwidth up to 12 MHz. VDSL is more complex than ADSL since there are several options for frequency band allocation and modulation techniques. While ADSL is designed only for asymmetric transmission only, the VDSL standard includes both asymmetric and symmetric profiles and it is targeted at both residential and business applications [13]. VDSL seems very promising in terms of offering services that deal with huge amount of data in the near future. • ADSL – ADSL (Asymmetric Digital Subscriber Line) is by far the most deployed xDSL flavor today. The reason is that ADSL is suitable for most today’s consumer due to the available bandwidth both in upstream and downstream directions. ADSL provides highspeed data transmissions over the twisted copper wire, the so-called local loop that connects the customer home or office to their local telephone company. Taking into consideration the fact that the nature of Internet is generally asymmetric, since users send a briefly page request and receive an entire web page download, ADSL seems to fit this scenario because the different upstream and downstream data rates.

2.1.1 ADSL Fundamentals The PSTN and supporting local access networks were designed following guidelines that limited transmissions to a 3,400 Hz analog voice channel. When observing that higher frequencies could be explored so that another type of data could be transmitted in these frequencies, ADSL systems begun to be deployed. ADSL is a broadband connection that uses the existing telephone line, which upstream and downstream data rates are different. ADSL provides high-speed data transmissions over the twisted copper wire, the so-called local loop that connects a customer home or office (Customer Premise – CPE) to their local telephone company (Central Office – CO).

11

The typical telephone cabling is capable of supporting a greater range of frequencies, around 2MHz. With ADSL modems, the digital signal is not limited to 3,400 Hz of voice frequencies. ADSL modems enable up to 2MHz of bandwidth to be used for transmission of digital data and analogue voice signals on the same wire by separating the signals in the frequency domain, preventing them from interfering with each other. ADSL modems establish a connection from one end of a copper wire to the other end of that copper wire.

Figure 4 ADSL Access Network and its required equipments [56].

Any DSL system has a DSL modem at the subscriber end, this can be seen in Figure 4 as an ATU-R (ADSL Termination Unit – Remote, user side) and more commonly called as customer premises equipment (CPE). At the Central Office (CO), a corresponding DSL modem demodulates the signals modulated by the subscriber modem. The CO is equipped with a Digital Subscriber Line Access Multiplexer (DSLAM), that is a platform for ADSL, which provides high-speed data transmission over traditional twisted-pair wiring. In addition, DSLAM is able to concentrate the data traffic from multiple DSL loops onto the backbone network for connection to the rest of the network. In other words, the DSLAM consists of banks of ATU-Cs (ADSL Termination Unit – Central Office). Depending on the region that Central Office is serving, the DSLAM should have a corresponding ATU-C for each ATU-R (ADSL Termination Unit – Remote) at the subscriber end. The splitters are small and simple devices that separate ADSL data from voice data. In other words, the splitter identifies whether the signal is below 4 kHz or higher. This is obtained using a simple low-pass filter technology. Therefore, the use of this splitter technology allows ADSL using the upper frequency spectrum in the same pair of copper for both voice and DSL data. If a single pair of copper is used for both voice traffic and DSL data, a splitter is used at both CPE and CO end. 12

Over the last few years, ADSL has been the most popular technology for providing broadband access to residential customers. Improved versions of ADSL, called ADSL2 and ADSL2+, which provides higher bit rates have now been developed and are gradually being introduced in many networks [13]. The difference between these standards and their particularities are shown below: • ADSL [37] is a local loop based transmission system that integrates voice and data services with higher data rates on the downstream than the upstream. It can reach speeds of up to 10Mbps downstream and 1Mbps upstream. ADSL allows customers to use simultaneously the normal telephone service and the high-speed digital transmissions on an existing telephone line and is ideally suited to home and small office users that require fast download rates for video on demand, Internet access, remote LAN access, multimedia access and other specialized PC services. • ADSL2 [38] has improved performance and interoperability over ADSL. It provides support for new applications, services and deployment scenarios, and can achieve higher data rates of approximately 12Mbps downstream, depending on loop length and other factors. Among the changes are improvements in data rate and reach performance, rate adaptation, diagnostics, and the use of a stand-by mode. ADSL2 has been designed to improve downstream data rate, distance between CO and CPE of ADSL, that means range, and achieve better performance on long lines in the presence of narrowband interference. ADSL2 achieves downstream and upstream transmission data rates of 12 Mbps and 1 Mbps respectively, depending on loop length and other factors. ADSL2 executes this through adopting better modulation efficiency, reducing framing overhead, reaching higher coding gain, improving the initialization state machine and providing enhanced signal processing algorithms. ADSL2 provides better modulation efficiency through the use of fourdimensional, 16-state trellis-coded and 1-bit quadrature amplitude modulation (QAM) constellations, which provide higher data rates on long lines where the signal-to-noise ratio (SNR) is low. ADSL2 achieves higher coding gain from the Reed-Solomon (RS) code on long lines where data rates are lower. This is due to improvements in the ADSL2 framers that improve flexibility and programmability in the construction of the RS codewords. ADSL2 systems decrease framing overhead through their support for a frame with a programmable number of overhead bits. Unlike the first-generation ADSL standards in which the overhead bits per frame are fixed and consume 32 kbps of actual payload data, in 13

the ADSL2 standard the overhead bits per frame can be programmed from 4 to 32 kbps. In first-generation ADSL systems, on long lines where the data rate is low (e.g. 128 kbps), a fixed 32 kbps (or 25% of the total data rate) is allocated as overhead information. In ADSL2 systems, the overhead data rate can be reduced to 4 kbps, which provides an additional 28 kbps for payload data. ADSL2 transceivers are responsible for the measurement of line noise, loop attenuation, and signal-to noise ratio (SNR) on both ends of the line. These measurements are collected using a special diagnostic testing mode even when line quality is too poor to actually complete the ADSL connection. Additionally, ADSL2 includes real-time performance monitoring capabilities which informs line quality and noise conditions at both ends of the line. This information is interpreted by software and then used by the service provider to monitor the quality of the ADSL connection which prevents future service failures. It can also be used to determine which data rate services a customer can subscribe for. • ADSL2+ [40] doubles the bandwidth used for downstream data transmission of the ADSL2 by increasing the downstream rate to around 20Mbps on phone lines as long as 1.5km. The ADSL2+ standard doubles the maximum frequency spectrum used for downstream data transmission from 1.1MHz to 2.2MHz. In other words, ADSL2+ extends downstream bandwidth to 2.2 MHz (512 subcarriers) for all operation modes (POTS/ISDN/All Digital Mode). ADSL2+ solutions interoperate with ADSL and ADSL2 chipsets. The members of the ADSL2 standards family specify a downstream frequency band up to 552 KHz and 1.1 MHz. ADSL2+ specifies a downstream frequency up to 2.2 MHz. The result is a significant increase in downstream data rates in shorter phone lines. ADSL2+ upstream data rate is 1 Mbps but it depends on loop conditions. ADSL2+ can also be used to reduce crosstalk. ADSL2+ provides the capacity to use only tones between 1.1 MHz and 2.2 MHz. Crosstalk of ADSL services from the remote terminal in the lines from the central office can significantly impair data rates in the line from the CO. ADSL2+ can correct this problem using frequencies under 1.1 MHz from the central office to the remote terminal, and frequencies between 1.1 MHz and 2.2 MHz from the remote terminal to the customer premise (a type of FDD scheme). This eliminates a large amount of crosstalk between the services and maintains data rates in the line from the central office. ADSL2+ enables service providers to change their networks to support advanced services such as video in a flexible way, with a singular solution for both short-loop and long-loop applications. It includes all the feature and performance benefits from ADSL2 while maintaining the capability to 14

interoperate with legacy equipment and allow the system a gradual transition to provide advanced services. One should notice that the ADSL technology is still being improved and better rates have been achieved. This occurs because different modulation techniques have been developed and more spectrum bandwidth is now utilized. However, in order to exploit what ADSL has to offer, there are a lot of factors involved in different layers that this technology covers. Therefore, all these factors have to be investigated and analyzed.

2.1.2 Physical Layer Issues When considering the POTS structure that ADSL takes advantage of, there are a lot of related issues about the adaptation of an old service running within the copper wires to a more sophisticated service as data transfer using higher frequencies. In this section we are going to present some of these issues and how they can affect the ADSL technology deployment.

Existing Copper Wire Structure Loop length has an important impact on ADSL deployments. For short loops scenarios great data rates are achieved while longer loops, which means greater ranges, will make the CO and CPE equipments synchronize at lower rates, thus advanced services (video, real-time data, etc.) may not be feasible depending on how far the customer is from the CO. Synchronization between CO and CPE equipments means an agreement of their capabilities during data transmission. In the old telephone systems, what we call bridge taps were frequently used to connect and disconnect portions of a loop cabling. Bridged taps are unused sections of twisted pair connected at some point along another pair. Their presence causes additional loop loss for frequencies of the quarter wavelength of the extension length. This would be caused by shared telephone copper wires, extension of the cable beyond the drop of the customer premises and any repairs made by just splicing the broke wired pairs. These bridge taps impact on data transfer in higher frequencies such as ADSL does. Therefore they must be removed Another existing element in the PSTN infra-structure is the loading coils. Loading coils are typically 88 millihenry (mH) chokes placed were used to reduce attenuation when transmitting voice signal in long loops to the customer premise. The loading coils technique was created to increase the telephony transmission quality, offering lower loss in the POTS band and great attenuation at frequencies above those used by POTS. This technique consists in placing a series of physical inductors at equally spaced intervals. The problem of using load coils is that it works for low 15

frequencies only and when ADSL is deployed in a loading coil environment, they act as a low-pass filter. Therefore, in order to successfully deliver ADSL services though the POTS infra-structure, the loading coils had to be removed, thus causing extra costs. Attenuation is the dissipation of a transmitted signal power as it travels through the copper wire line. The high-frequency signals transmitted through DSL loops attenuate power faster than the lower-frequency signals of the POTS band. One way to minimize attenuation is to use lower resistance wire. This is achieved by modification of the wire gauge. Resistance of some wire gauges can be seen in Table 5. Table 1 Resistance of some wire gauges [67].

AWG2 19 22 24 26

Diameter (mm) 0.9 0.63 0.5 0.4

Loop Resistance (Ω/Km) (20º C) 55.4 110.9 175.2 281.4

ADSL Modulation Techniques In order to offer high speed data transfer and makes a better utilization of what the copper pair has to offer, ADSL uses line coding techniques such as DMT (Discrete MultiTone) and CAP (Carrierless Amplitude and Phase Modulation). CAP modulation was used in the early deployment of ADSL systems and it is a variation of the QAM (Quadrature Amplitude Modulation) which was developed by AT&T. Moreover, it divides the entire spectrum in three different bands. The first ranges from 0 to 4 KHz and is allocated for the POTS. The second ranges from 25 KHz to 160 KHz and is allocated for upstream data transmission. The third ranges from 240 KHz to 1.5 MHz and is allocated for downstream transmission of the data. Figure 5 depicts how CAP acts when splitting the frequency spectrum for POTS, for upstream and downstream directions.

AWG (American Wire Gauge) is an indicator of the wire size. The heavier the gauge, the lower the AWG number and the lower the impedance.

2

16

Figure 5 Spectrum use by CAP coding [56].

Although CAP was used many years when ADSL systems were being deployed, a more sophisticated coding technique was introduced later as DMT. Though CAP is not standardized, DMT was initially standardized as ANSI (American National Standards Institute) T1.413 and was then forwarded to ITU as G.992.1. Differently from CAP, DMT also known as OFDM (Orthogonal Frequency Division Multiplexing) divides the available spectrum in 256 (ADSL/ADSL2) or 512 (ADSL2+) small channels of 4.3125 KHz each. Each channel is able to carry 60 Kbps of data. DMT defines two data paths: fast and interleaved. Fast offers low latency, while the purpose of interleaving is to avoid consecutive errors delivered to the Reed-Solomon (RS) forward error correction (FEC) algorithm at the receiving end of the circuit. RS is much more effective on single errors or errors that are not consecutive [56]. Looking at Figure 6, the 4.3125 KHz small channels can be seen for upstream and downstream bandwidth utilization. These 4.3125 KHz channels are each bin inside the upstream and downstream frequency division.

17

Figure 6 Spectrum use by DMT coding [56].

Error Correction Techniques FEC and interleaving technique have an important role in the ADSL systems. Since FEC is more effective against single error, an interleaving can be applied in order to make a better use of the FEC algorithm. ADSL employs Forward Error Correction (FEC) as a way to overcome transmission errors caused by line impairments. ADSL supports FEC in both upstream and downstream directions and the FEC coding algorithm adopted by the recommendation [37] [38] [40] is the Reed-Solomon coding. FEC is the technique that mathematically corrects data which somehow was corrupted during transmission (without any retransmission being used). The role of FEC is to deal with transmission errors caused by noise and other impairments on the wire line. FEC bytes are added to the user data stream to produce a means to calculate the presence of corrupted data and it also generates a corrected frame [56]. The best advantage of not retransmitting data is that for real time applications retransmission is sometimes not tolerated. In addition, it uses the available bandwidth to repeatedly send the same information, so the user perceives very slow throughput. FEC results in greater effective throughput of user data because valuable bandwidth is not being used to retransmit wrong data. For a message of K bytes, the RS coding append R redundancy bytes to form a RS codeword of N = K + R bytes. The R parameter defines the strength of the coding against line disturbance. The RS decoder at the receiver can recover R / 2 erred bytes per codeword. When more than R / 2 bytes errors occur in the same codeword, the receiver is unable to recover the original message, what is indicated by the CRC verification. Possible values of R are 0 (no protection), 2, 4, 8, 12 and 16 bytes per codeword with maximum size of 255 bytes. The greater the value of R is, the more protected the coding is against noise. However more bandwidth is used with non-user data (protection data). There is a trade-off between the rate loss generated by corrupted 18

frames and by the amount of redundancy bytes. Redundancy bytes must be kept as little as possible while still permitting the original message to be recovered. As a matter of name convention, when the corrupted data is corrected due to the use of FEC, they are reported as corrected errors. However, when these errors cannot be recovered or corrected, they are reported as uncorrected errors. Although FEC seems to be an excellent technique to correct corrupted data, its benefits does not come without a cost. For data being corrected, what we call FEC bytes have to be inserted in the user data. It is important to note that when FEC is being used, the user data has to share the available bandwidth with the redundant data, leading to a bandwidth loss. As a very basic and general rule is that the more FEC bytes used the more effective is the error correction. But in errorfree transmission paths, an unnecessary number of FEC bytes serve only to displace user data in the available bandwidth. Knowing how FEC acts and how it can lead to a misuse of the available bandwidth, its use must have some attention. Interleaving is the process of scrambling user data in a very precise sequence [56]. The interleaving process scrambles RS codewords in such way consecutive errors are spread over many codewords so RS decoding can be more successful. It is used to minimize the burst effect caused by the impulse noise and acts by spreading codewords over a longer time and giving more successful probability to the FEC technique. RS (Reed Solomon) FEC is much more effective on single errors or errors that are more spaced in time (not consecutive). So, when noise events occur during transmission, they can be a short and brief impulse or they can be great and lengthy. In cases that short period noises happens FEC can act in such a manner that correction can be made through the entire affected data, though when lengthy noises occur interleaving acts like a scrambler and mix the consecutive erred data with the corrected data, leaving the erred bits separated. Consecutive errors can be generated by bursty impulsive noise and affect long sequences of bits that may exceed the correction capacity of one RS codeword (8 × R / 2 bits) but less likely when more than one codeword is affected. For instance, for 2 interleaved codewords, the length of the maximum noise burst that can be corrected raises to 2 × 8 × R / 2 bits. Therefore, the erred bits are no longer consecutive and the RS FEC process is much more effective. The interleave depth indicates how many FEC frames are scrambled together, and assume values as 1, 2, 4, 8, 19, 32, and 64, but the Amendment 1 of ADSL2+ [39] extended it to 96, 128, 160, 192, 224, 256, 288, 320, 352, 384, 416, 448, 480 and 511. A greater value of interleave depth improves the noisy immunity but it can turn delay sensitive applications impracticable. 19

While providing greater protection against long consecutive erred bit sequences, the interleaving process has the drawback of increasing the transmission latency. The FEC frames are held in the interleaving buffer until the interleaving depth is reached at the transmitter. After that, the interleaved frames are sent through the line to the receiver, where they are buffered again to be de-interleaved. Greater values of D do not cause rate loss but impose larger delay to users and applications. Impulse Noise Protection (INP) is the maximum number of consecutive DMT symbols that can be recovered from an impulsive noise burst. The INP limits the size of the recoverable noise burst so that symbols affected by bursts lager than “INP” DMT symbols cannot be reconstructed properly. The impulse noise immunity is determined by FEC and interleaving parameters. The RS coding provides a recover capability of R / 2 erred bytes by data frame, where R is the number of redundant bytes. Applying interleaving depth D, the overall byte protection is D × R / 2 bytes. With DMT symbols of size L bits, the impulse noise protection obtained is given by

INP = D

R 1 2 L/8

where INP is the calculated impulse noise protection, D is the interleaving depth, R is the number of redundancy bytes and L is the size of the DMT symbols in bits.

Trellis Coding Trellis coding may be used by ADSL to avoid noise interference when transmitting data. The usage of trellis is an optional feature that ADSL provides. However, Trellis coding decreases bandwidth and increases the complexity of the decoder needed to recover the data. The decoder is more complex because it needs to take into account every subsequent symbol that would be affected by the transmitted data before it makes a decision. For example, for a simple 16 point QAM on the raw data, if Trellis coding is not used then 4 bits per symbol will be used to transmit the data. Using Trellis coding will take two out of every four raw bits, and convolutionally encodes them to 3. The symbol takes now 5 bits, and a 32 point QAM is needed to send the data. The raw error rate when decoding a 32 point QAM is much higher when compared when decoding a 16 point QAM. If a point decoded from the 32 point QAM is wrong, the likely correct choice should be one of the adjacent ones. The Trellis coding is able to spread symbol information in others symbols, this mean that, if the decoder is not able to decide whether the received symbol really fits in the QAM constellation, 20

knowing the previous received symbols will make the decoder able to do this task. This is done by not only considering single symbols in a symbol by symbol detection as it is done in uncoded modulation, but by taking into account whole sequences of received data. This is possible by only allowing certain sequences of signal points, while others are excluded. In order to get the freedom to exclude certain sequences without loss in data rate or increase in transmission bandwidth, the transmit constellation has to be increased.

Bit Swapping and SNR Bit Swapping is a mandatory ADSL feature that reallocates bit loading among the allowed sub carriers according to the SNR, however, after a bit swapping reconfiguration, the total data rate is unchanged [37]. Bit swap only works if the noise amplitude does not increase too rapidly, and the Power Spectral Density (PSD) of the noise is narrow enough such that not too many sub carriers are simultaneously affected by the noise. Despite this, the method provides good protection against narrow-band noise; against impulsive noise types bit swap provides little protection [38]. In practical terms, bit loading have a serious limitation: requires extensive synchronization, and the protocol implemented for this purpose is quite slow. The SNR margin represents the amount of increased received noise when compared to the noise power that the system can tolerate and still meet the target BER (Bit Error Ratio) of 10-7. The default configuration of an ADSL transceiver allows a SNR margin of 6 dB, in other words, the noise can increase by 6 dB, without causing BER to increase above 10-7 [38]. One possibility is to configure the transceivers to a high SNR margin to deal with sudden transients, but this approach has the drawback that the bit rate decreases with higher SNR margin as the modem needs to fall back to lower rate modulation schemes in an attempt to maintain the same BER. If the noise margin falls below this minimum level, the modem should attempt to increase its power output, if that is not possible the modem will attempt to re-initialize or shutdown [38]. It would be interesting to investigate how power control is beneficial for capacity optimization. Although it may be intuitive that for a single modem increasing its power may help it to recover from a low SNR, such benefits may be limited when a number of channels and wires apply the same policy. As discussed in this section, the ADSL technology and its structure have many factors from its physical organization to its parameters defined in the standards. Table 2 exposes these problems/parameters and shows the advantages and disadvantages of them.

21

Table 2 Related problems and parameters to the ADSL Line.

Problem/Parameter Loop Length Bridge Taps and Loading Coils Modulation Techniques Error Correction Techniques Trellis Coding

Bit Swapping

SNR

Explanations The greater the loop length is from the CO to the CPE, the lower the achieved rate will be. They had to be removed because they introduce data loss in the ADSL system. Thus, generating additional costs. More sophisticated modulation techniques have to be employed to take the maximum advantage of the available frequency bandwidth ADSL system implements different error correction techniques to prevent transmission errors, but this should be used with caution since they can impact on other parameters such as delay and rate. A good way to protect the ADSL line against noise interference, but it has the drawback of decreasing bandwidth and increasing the complexity of the decoder needed to recover the data. Reallocates bit loading among the allowed sub carriers according to the SNR. This makes the transmission protected against noises that amplitude does not grow too quickly. As a drawback, Bit Swapping requires extensive synchronization from the CO and CPE. Represents the amount of increased received noise when compared to the noise power that the system can tolerate and still meet the target BER of 10-7. The problem here is that higher SNR values decrease data rate and introduce Crosstalk

2.1.3 Link Layer Issues ATM (Asynchronous Transfer Mode) is the most common and widely deployed data link layer protocol for ADSL. Its choice as the Layer 2 protocol brings great benefits in the flexibility of how services are delivered to the subscriber. The right choice of the data link layer protocol that ensures QoS (Quality of Service) is important so service providers have different ways to differentiate or classify various services and charge their customers accordingly. Another reason to choose the right protocol is that ADSL provides Triple Play (3P) Services, and applications, such as video and voice, must reduce absolute delay from the source to the destination with very little variation in delay from packet to packet. ATM networks, by nature, are connection-oriented. This means that a VC (Virtual Circuit) needs to be set up across the ATM network prior to any data transfer. To guarantee the resources for each class, ATM implements techniques in the same way as the bandwidth management that, essentially, aims at to manage network resources efficiently and providing clients ensuring that it does not consume bandwidth that would affect other services.

22

Most ADSL deployments today use ATM as the data link layer. Moreover, ATM makes use of PVC (Permanent Virtual Circuit) to establish the connection. Each subscriber is typically allocated to one PVC, which is then switched by various ATM switches or DSLAMs before it reaches its final destination. ATM QoS have a PVC Class of Service (CoS) definition that is a form of priority queuing that provides the means to classify and prioritize packets by application (file transfer, voice call, video delivery, etc.). CoS classifies packets by examining packet parameters or CoS markings and places them in different priority queues based on predefined criteria. Each CoS has a different meaning regarding the type of application that is running over the PVC, such as CBR (Constant Bit Rate), UBR (Unspecified Bit Rate), and VBR (Variable Bit Rate). Depending on the selected ATM CoS, it is also possible to make a traffic description that is transmitted over each PVC. These parameters can be defined based on the specific bandwidth requirements of an individual PVC, as needed for a specific application. These configurable parameters are: Peak Cell Rate (PCR), Sustainable Cell Rate (SCR), Minimum Cell Rate (MCR) and Maximum Burst Size (MBS). The ATM reference model defines three main layers. The Physical layer, ATM layer, and ATM adaptation layer (AAL). The physical layer acts as the same manner as the physical layer in the OSI (Open Systems Interconnection) model. The ATM layer along with ATM adaptation layer is like the data link layer of OSI reference model. Finally, between the ATM layer and the upper layers, different types of ATM Adaptation Layers (AAL) have been defined to fulfill the needs of different types of applications. The AAL has to translate and adapt the application needs to the ATM service offered. It is also in charge of synchronization between destination and source, and error control mechanism if the application requires it. Taking into consideration the application packetization used in the upper layers, the AAL5 is able to segment packets into ATM cells. The ATM Forum specifies two MPEG TS (MPEG Transport Stream) packets (this will be showed in later sections), that are encapsulated into one AAL5 PDU (Protocol Data Unit). Since each MPEG TS has 188 bytes, the AAL5 PDU will have the total length of 376 bytes. The encapsulation process appends an 8-byte trailer containing a cyclic redundancy check (CRC) and length information to the end of the PDU payload. So, the 2 MPEGTS packets have become a 384 bytes length data, leading to an 8 ATM cells of 48 bytes each.

23

2.2 Video Content Issues With the increasing bandwidth availability, delivering video content using existing broadband network has attracted much attention from researchers and telecommunication operators around the globe. A new service category can be provided and customers can be charged to use these sorts of services. Following the same trend as the old analog television standards such as NTSC, PAL and SECAM (Séquentiel Couleur À Mémoire), the new era of digital television can now use the IP network infra-structure to offer SDTV or HDTV services using an ordinary internet connection. MPEG-2 audio and video standards are the most internationally accepted compression standards for digital video and audio [27]. MPEG-4 standard has been investigated to take MPEG-2 place because it achieves lower bit rates for the same video quality compared to MPEG-2. They also provide low-to-medium bit rate coding and high-quality video coding. However MPEG-2 is currently being deployed in digital video service rollouts worldwide and is the compression standard used in the majority of digital broadcast satellite systems. In addition, the MPEG-2 video standard has been adopted for high-definition television (HDTV) applications. The ATM Forum adopted specifications for transporting MPEG-2 compressed digital video over ATM networks.

2.2.1 Digital Television and IPTV The method of broadcasting and receiving digital video and audio signals is called Digital Television. These signals can be transported using different kinds of medium such as terrestrial, satellite, and cable. Differently from the old analog system, Digital Television introduced new formats and aspect ratios to the video screen. For HDTV signals, the formats that can be used are 1280x720 pixels in progressive scan mode and 1920x1080 pixels in both interlaced and progressive scan mode. As a matter of simplicity, the 1280x720 resolution is called 720p and the 1920x1080 resolution is called 1080i/p. This nomenclature can be used because in HDTV the aspect ratio is 16:9, which means the relationship between screen width and screen height. Thus, we have 16/9 is equal to 1.7777. When multiplying 720 or 1080 for 1.7777, we have the specific width for the given height. Although Digital Television was designed to be centered in HDTV, SDTV services that is already been deployed all over the world cannot be aside. Therefore, the NTSC, PAL and SECAM standard formats and aspect ratios were used in order to deliver Digital Television.

24

While in HDTV the aspect ratio is 16:9, in SDTV the used aspect ratio is 4:3. The screen format, which is the height and width in pixels, may vary depending on the standard being used. In a country where signal is broadcasted some adaptation has to be made to keep different standards working together. The scanning mode can be interlaced or progressive as well. Figure 7 depicts the format in terms of height and width in pixels and the scanning mode that SDTV and HDTV utilize when delivered to the customer. 1920

1280

720

0 0

NTSC 480i/p PAL 576i/p HDTV 720p

HDTV 1080i/p

480 576 720

1080

Figure 7 Different formats and scanning modes for HDTV and SDTV in pixels

There are different proposed standards been used in several countries around the globe. These standards define not only the format and aspect ratios, but also different compression algorithms for audio and video, different modulation techniques, and different transport protocols. These standards are: • DVB – Commonly known as the European Standard. DVB was initiated in 1993 and is maintained by the DVB project which is a consortium with more than 260 members. These members are broadcasters, manufacturers, network operators, software developers, and regulatory bodies in over 35 countries, committed to design global standards for the global delivery of digital television and data services. DVB’s main transmission standards, (DVB-S for Satellite, DVB-C for Cable and DVB-T for terrestrial) dominate the world and are the basis for most of the alternative standards [12]. Techniques such as FEC and Interleaving are

25

used in its transmission to provide error protection against eventual noises coupled into the delivering media. • ATSC - Commonly known as the American Standard. ATSC was created in 1982 by the member organizations of the Joint Committee on InterSociety Coordination (JCIC), the Electronic Industries Association (EIA), the Institute of Electrical and Electronic Engineers (IEEE), the National Association of Broadcasters (NAB), the National Cable Television Association (NCTA), and the Society of Motion Picture and Television Engineers (SMPTE). Currently, there are approximately 140 members representing the broadcast standard, broadcast equipment, motion picture, consumer electronics, computer, cable, satellite, and semiconductor industries [3]. In 1996 ATSC standard was adopted in United States and later in 1997 it was also adopted in Canada. In addition, it utilized Reed Solomon as the FEC algorithm and Trellis coding. • ISDB – Commonly known as the Japanese Standard. The Digital Broadcasting Experts Group (DiBEG) was founded in September 1997 to promote ISDB-T, the Japanese Digital Terrestrial Broadcasting System [9]. The ISDB standard looks like the DVB standard, but with some different coding standards for audio. Some standards may use more than one modulation technique or more than one audio coding for example. The modulation technique used depends on the medium that the video is being transported, i.e. terrestrial or satellite. Moreover, an architecture with some layers can be defined when theses standards are used. Figure 8 shows the modulation, transport, video coding, and audio coding layers. In each of these layers different standards and protocols are used.

Audio Coding

Dolby AC-3

MPEG2 Layer 2

MPEG-2 SDTV or HDTV Resolution

Video Coding

MPEG-2 Transport Protocol

Transport Modulation

MPEG2 AAC

VSB

COFDM

QAM

PSK

QPSK

PSK

Figure 8 Different Layers for the Digital Video Transmission Architecture

Since digital television has being deployed successfully, its use jointly with computer networks provided by broadband access was planned and explored. IPTV is the technology that offers 26

television services using the network infrastructure instead of using the regular coaxial cables. Adding this television service to voice and data, a service called Triple Play is provided. When IPTV service is provided to the end user, many factors are involved in upper layers belonging to the architecture shown in Figure 8. For instance, another protocols involved in the transmission such as UDP/RTP for the transport protocol had to be used. Therefore, some protocols as the IGMP (Internet Group Management Protocol) and some devices such as the STB (Set-Top Box) have to be used. With the IGMP protocol, multicast and unicast transmission are available, reducing bandwidth. The STBs are needed in order to decode the compressed digital video stream and make it available to the TV the uncompressed analog signals. This occurs because TVs are not able to reproduce the received signal in the form that is delivered today. There are several options for the end user when subscribing for the television services. Customers can exploit of Live TV broadcasting, the stored video or pay per view programs (Video on Demand – VoD) and also the teleconference with another subscriber of the same service. However, there are some drawbacks when this service is provided to the end user. When changing TV channel, the request signal meaning the willing of changing group and the exact time of the new channel reception may take more than 1s [11], which means a delay to receive the desired channel. This total time is called zap rate. The acceptable value of the zap rate is 700 ms [11], but it depends on many factors from the encoder performance to the network delay. Another important fact is that for the possibility of having 3 TVs at home, which is quite common for coaxial cables standards, the user would need a larger amount of bandwidth to make it possible to watch 3 different channels at the same time. Figure 9 depicts a video transmission using multicast transmission where three different channels are streamed to 7 different users, resulting in three flows. On the other hand, Figure 10 shows the same scenario but using unicast transmission. Supposing each video stream flow has 4 Mbps then the multicasting transmission would utilize 12 Mbps and the unicasting transmission would use 28 Mbps, leading to a 16 Mbps bandwidth waste.

27

ATM Network

Figure 9 Video Transmission using multicast

ATM Network

Figure 10 Video Transmission using unicast

2.2.2 MPEG Overview The MPEG standard has been a landmark since its creation by the ISO/IEC. MPEG is an abbreviation for Moving Picture Expert Group. There are several standards already defined by the ISO/IEC group, such as MPEG-1, MPEG-2, MPEG-4 and others that they are presently being developing, e.g. MPEG-7 and MPEG-21. The standard covers not only video compression but also associated audio. The MPEG group completed the first phase of its work in 1991 with the development of the MPEG-1 standard (ISO/IEC 11172). In response to a need for greater input format flexibility, higher data rates, and better error resilience, MPEG started to develop extensions to the MPEG- 1 specification, called MPEG-2 standard (ISO/IEC 13818) [27]. The MPEG standard defines not only how the compression algorithm should be designed, but also how the end-to-end transmission should occur and how the video and its associated audio are packetized when following the protocol definition for data transmission. Moreover, it does not prescribe the encoding process; instead, the standard specifies the data input format for the decoder as well as detailed specifications for interpreting this data. The data format is commonly referred to as syntax, while the rules for interpreting the data are called the decoding semantics [27]. The MPEG standard makes use of raw video sequences for the compression algorithm. Differently from RGB (Red, Green and Blue) color space, there are other patterns such as HSV, YIQ, and YUV. The YIQ and YUV are used by the NTSC and PAL/SECAM respectively. The 28

YIQ and YUV isolate the luminance (or brightness) from the chrominance (or hue). The YUV equivalent in digital form is YCbCr where Cb chrominance information refers to U analog component and Cr chrominance component refers to V analog component. The Y is still the luminance component but now the analog signal is digitalized. When combining these 3 components, we are able to see a colored picture. The YCbCr format concentrates most of the information of the image into the luminance and less in the chrominance components because the luminance component is more sensitive to the human eyes than the chrominance. Figure 11 shows the combination of each component which is shown separately in Figure 12, Figure 13, and Figure 14 that represents the Y, Cb and Cr components respectively. The chroma sampling indicates how many components of Y, Cb and Cr will characterize each pixel in the resulting image. If we have a 4:2:2 chroma sampling we will have 4 Y components, 2 Cb components and 2 Cr components. Thus, if we have a 4:2:0 chroma sampling, we will have 4 Y components, 1 Cb component and 1 Cr component.

Figure 11 Combination of YUV (YCbCr) Components

Figure 12 Y Component (Y)

Figure 13 U Component (Cb)

Figure 14 V Component (Cr)

The main objective of video compression techniques is to remove the redundancy in the original source signal. Since still images have a lot of redundant information, compression is possible in many different ways. The MPEG compression algorithm utilizes this redundancy in order to minimize the size of the resulting output. MPEG compression takes advantage of some image characteristics, such as the spatial redundancy among neighboring pixels in a given picture, the spectral redundancy among color images within frames, the temporal redundancy among pixels or 29

blocks of pixels in different frames, and the fact that some information in video data is considerable irrelevant from a perceptual viewpoint so that for the Human Visual System (HSV) it does not provide any benefit.

2.2.3 MPEG Video Structure An MPEG video stream is highly hierarchically structured. This structure can be defined in seven layers of different units: • Block – A block is the smallest unit in the MPEG video. It is composed of an 8x8 matrix of pixels which can be Y (luminance), Cb (blue chrominance) or Cr (red chrominance). The intra frame DCT (Discrete Cosine Transform) coded frames takes blocks as its basic unit. • Macroblock – A macroblock consists of a 16x16 matrix of pixels. When a 4:2:0 chroma sampling format is used, there will be 4 pixels representing the Y component, one the Cb component and one the Cr component. • Slice – Is defined as a horizontal part of the entire frame. The MPEG algorithm utilizes the slices as its main unit to compress data. In order to code the macroblocks and the blocks, the slice must be available. This occurs because a slice is an independent part of the frame, thus making it an independently unit. Therefore slices serve as resynchronization units. • Picture – Since slices are horizontal parts of the entire frame, picture can be defined as several slices together. Moreover, a picture is a single frame of a video sequence. • Group of Pictures – The Group of Pictures are known as GOP. GOP is a small sequence of pictures or frames within the video sequence. The GOP value may vary from video sequence to video sequence. In addition, this small sequence contains different sort of frames in the MPEG standard and it represents the number of frames between two I frames (discussed later). The GOP is not mandatory for the MPEG2 standard. • Sequence – Sequence is the combination of all frames or pictures that belong to the video. The MPEG standard defines headers for the sequence. We will discuss header formats and contents, in another section of this chapter.

30

In bitstream Sequences, GOPs, Pictures and Slices all have a header followed by the contents of the lower layer, including their headers. All other layers end at the beginning of a new header of the same layer or a higher layer [55]. As described previously, the MPEG standard also defines syntax of the compressed video. The MPEG video sequence has different types of frames. These frames are: • Intra Coded Frames – Commonly known as “I” frames, they are independent frames that contains all the information to be displayed to the end user, which means, they are coded without reference to preceding or upcoming pictures of the sequence. Since I frames are coded as stand-alone images, they exploit only the spatial redundancy contained within the pixels and not the temporal redundancy. Therefore, a moderate compression rate is achieved when coding I frames. An I frame is always an access point in the video sequence. • Predicted Frames – Commonly known as “P” frames, they are coded with respect to the previous I or P frames. The predictions of the best-matching macroblocks are indicated by motion vectors that describe the displacement between them and the target macroblocks. This coding process allows P frames to explore both spatial and temporal redundancies, thus P pictures can achieve a higher compression rate than I pictures. The disadvantage of P frames coding is that any errors that may have occurred in I frames will be propagated to them. • Bidirectional Frames – Commonly known as “B” frames, they use both past and future I or P pictures as reference. Motion compensation is also applied here. Because B frames need both I and P frames, the code/decoder has to organize pictures in such a way that B frames is produced after all its references are produced. They can achieve even higher compression rates than P frames and consequently I frames. Typically, there are two B frames separating I or P frames.

2.2.4 Profiles and Levels Some parameters referring to the coding process are chosen when compression is applied. For instance, the encoder can have different GOP size, different number of B frames. In addition MPEG standard defines profiles and levels in order to cover different applications, bitrates, resolutions, qualities and services that the compression method can offer. The profiles defined are related to the frames types used and the chroma sampling format. The levels specify the screen resolution and the frame rate, which represents the number of frames displayed per second. Table 3 31

shows some profiles defined by the MPEG standard along with their chroma sampling format and the types of frames used when video is compressed. Table 3 Some profiles defined by the MPEG standard

Name

Chroma Sampling

Frames

Simple Profile (SP)

4:2:0

I, P

Main Profile (MP)

4:2:0

I, P, B

High Profile (HP)

4:2:2

I, P, B

Together with the profile definition, there is a level definition. So that when a service is offered for a defined video profile and level, the nomenclature used is ProfileNamexLevelName. Table 4 Some levels defined by the MPEG standard

Name

Screen Resolution

Framerate

Low Level (SL)

352x288

30

Main Level (ML)

720x576

30

High Level (HL)

1920x1152

30

Following the nomenclature used to define profiles and levels, we have MPxML when a video is compressed with a chroma sampling of 4:2:0, having frame types I, B and P, for a screen resolution of 720x576 with a frame rate of 30 fps.

2.2.5 MPEG Algorithm The MPEG compression explores the fact that there is redundant information in each frame and in sequence of frames. MPEG utilizes DCT and entropy coding to deal with spatial redundancies; and motion compensation and motion estimation to deal with temporal redundancies. The compression algorithm for spatial redundancies begins with DCT. DCT is used with the goal of producing a matrix of coefficients that concentrates the energy of the most important pixels in very few coefficients. This is done by taking each block of the frame and applying DCT. It is important to notice that DCT does not introduce any loss to the frame, thus to retrieve the image back to the way it was an IDCT (Inverse Discrete Cosine Transform) has to be performed. After DCT is applied, the second stage consists of quantizing the coefficients generated in the DCT stage. The main objective of the quantization stage is to reduce the coefficients related to higher frequencies to zero. At this stage video bit rate is reduced, causing information loss to the output 32

image. At the final stage of the compression algorithm, the coefficients generated by DCT go through a zigzag scanning. The zigzag scanning has the goal of organizing coefficients in a better way so that the Variable Length Coding (VLC), also known as Huffman coding and Run Length Coding (RLE) can take more advantage when compressing those coefficients. The compression algorithm for temporal redundancy makes use of motion estimation and inter-frame prediction to achieve lower video data rates. Differently from the spatial redundancies algorithm, the motion estimation and inter-frame prediction algorithms take macroblocks as input for compression. The algorithm takes the following frame of the current been looked at, and search the macroblocks that may appear in different places when comparing these two frames. So, the macroblock data does not need to be informed, but only its new location within the next frame. This new location values is known as motion vector. Of course there is a search window while doing this macroblock search. However the larger the window size is the better the motion estimation but higher is the computational cost, causing longer encoding delay. This process is used in P and B frames. In the case of P frames, I frames are used for the motion estimation and for the B frames I and P frames are used as references. With this technique high compression rates are achieved, but there is a drawback of propagating error until the next I frame is shown since all frames are dependent of each other. Figure 15 depicts all the stages that an image in its raw format has to go through in order to be compressed.

Figure 15 MPEG Compression stages for both spatial and temporal redundancies removal [61]

2.2.6 Packetization The MPEG standard defines how audio and video content is multiplexed and transmitted through a network. The basic unit of multimedia content is the bitstream sometimes called the Elementary 33

Stream (ES). The ES can be viewed as a sequence of bytes meaning the audio or video content plus some basic header information describing this video or audio. One important fact is that ES carry only one kind of data and depending on the data carried the header information changes. The first field in the ES is the sync word which has 12 bits of length. The sync word indicates which kind of data the ES is carrying. For instance, when video data is being carried the sync word defined is 0x1B3 and when audio data is being carried the sync word defined is 0xFFF. Thus, when video data is being carried some other fields are defined. Some of these fields are picture height, picture width, aspect ratio, video bitrate, among others. The Packetized Elementary Stream (PES) encapsulates the ES and adds more information by generating a more detailed header for the bitstream structure. Figure 16 depicts the PES packet structure. For instance, the payload field is the ES data.

Figure 16 PES packet structure [32]

An important fact about both de ES and PES is that these structures carry only one kind of data. In order to carry different sort of data together in a structure, the PES packet has to be multiplexed. For example, if audio and video data have to be arranged together, the video PES and the data PES should be multiplexed. This is done in two different ways. The first one is the MPEG Program Stream (PS). The MPEG PS is used in reliable medium such as CDs and DVDs which do not pass through any disturbance while a player is playing its content. The second one is the MPEG Transport Stream (TS). The MPEG TS is used when multimedia content utilized a non reliable medium, such as a network. TS packets have a fixed size length of 188 bytes. Figure 17 shows the structure of the MPEG TS packet.

34

Figure 17 MPEG TS packet structure [32]

In later sections we are going to describe the packetization method of Ethernet packets carrying MPEG TS packets converted to ATM cells by the AAL.

2.3 Noise Impairments Any interfering signal on the telecommunication channel is known as noise. Noise is present in various degrees and in almost all environments. Its sources are either man-made or natural. Almost any electrical or electronic equipment may be a noise source; power lines are perhaps the most pervasive of them. Natural noise comes from lightning and other atmospheric phenomena, random thermal motion of electrons as well as electrostatic discharges. These unwanted signals can cause transmission errors and may even disrupt the communication process. As expected, DSL suffers from noise problems because DSL uses the POTS copper pair to transmit its signal and these copper pairs pass through many different places and many kinds of environment, which can affect and degrade the quality of the transmission. Taking this into consideration, it is really important to predict and try to eliminate or avoid the different types of noises that may interfere in the data transmission. In a scenario where noise is present, there must be a noise source (generator), a coupling mechanism and a receptor. Radiation, induction and conduction are the most common coupling mechanisms. The receptor may be the loop itself (there are limits on the amounts of noise allowed on it), the terminal equipment or the network. There are many types or classes of noises that adds imperfect balance (or imperfect/insufficient twisting) into the phone line; some of the most common are crosstalk noise, additive white Gaussian noise, radio noise, and impulse noise, as explained in the following.

2.3.1 Additive White Gaussian Noise – AWGN AWGN is the thermal noise that is common to all communication systems. Thermal Noise is generated by the random movements of thermally energized particles inside an electric conductor. 35

Thermal Noise is intrinsic to all resistors and is not a sign of poor design or manufacture, although some resistors may also have excess noise. AWGN is a random high frequency signal with a flat power spectral density. Its power is equal in all frequencies. For example, for an audio system with bandwidth of 10 KHz, any flat-spectrum audio noise with a bandwidth of equal to or greater than 10 KHz seems to be a white noise [80]. In a digital system such as ADSL, AWGN can cause symbol errors to occur at the receiver when noise pushes the received sample beyond a decision boundary in the QAM constellation. Like many other digital communication systems, ADSL employs error-control coding to help to reduce the effect of AWGN. Coding adds redundancy to the transmitted signal and exploits the redundancy at the receiver to detect and correct errors.

2.3.2 Crosstalk Crosstalk is a type of noise that appears because bundled telephone cable contains many wires for many different users. Crosstalk noise in DSLs arises because wires in a cable of twisted pairs radiate electromagnetically. The electric and magnetic fields created induce currents in neighboring twisted pairs that are located in the same cable bundle, leading to an undesired crosstalk signal. It is also seen as a leakage from one channel of signal power to another channel. The Crosstalk name comes from the effect that occurs within multipair telephone cables. This effect makes other people's conversations to be heard on the line that another person is using. There are two basic types of crosstalk and they both appear at the receiver as additive noise. Near-end crosstalk (NEXT) occurs when a transmitter interferes with a receiver located on the same end of the cable. Far-end crosstalk (FEXT) occurs when the transmitter interferes with a receiver on the opposite end of the cable. The effect of NEXT is more severe than FEXT since the FEXT interference travels the entire length of the cable and is therefore attenuated by the time it reaches the receiver. Figure 18 depicts how FEC and NEXT acts within the line.

Figure 18 NEXT and FEXT noise when coupled to the transmission [67]

36

Crosstalk noise can be the largest noise impairment in a twisted pair and often reduced substantially DSL performance when it is not eliminated. Insufficient shielding, excessively large disparity between signals level in adjacent circuits, unbalanced lines or overloaded carrier systems can cause crosstalk noise. It is important to mention that crosstalk caused by a loop at voice frequencies is rare, except in extreme cases of poor maintenance or facility damage, which appears in the form of an unbalanced line.

2.3.3 Radio Noise Differently from crosstalk noise, this type of noise is generated by sources that are external to the bundle. A powerful external source may induce noise in a DSL line. Besides that, phone lines, being made of copper, make it a relatively good antenna with electromagnetic waves incident on them leading to an induced charge flux with respect to earth ground [72]. In urban areas where DSL is widely deployed, there are many Radio Frequency (RF) sources. These RF signals may couple to the DSL link. Amateur (Ham) radios, AM (Amplitude Modulation) broadcast stations, and RF heating systems are common sources of radio frequency. Ham radio signals are unpredictable and may appear and disappear at any frequency within the bands allocated to Hams at any time. The induced Ham radio and AM broadcast signals in the DSL line may be very strong when compared to DSL signals in the twisted pair wire. Amateur radio transmissions disturb mainly VDSL services, which is not the focus of this work. AM radio interference, however, affects VDSL and ADSL. It is generated by commercial radio stations that continuously occupy bandwidths of 10 kHz ranging from 560 kHz to 1.6 MHz.

2.3.4 Impulse Noise Impulse noise consists of random short duration 'on-off' noise pulses (less than one second) with a very fast rise time (peaks) and its level is at least 20 dB above the continuous noise level and has a large magnitude. The total duration is normally shorter than 0,2 sec. It occurs typically due to switching transients caused by a variety of sources such as the opening of a refrigerator door (the motor turns on/off), control voltage to elevators (phone lines in apartment buildings often run through the elevator shafts), and the ringing of phones on lines sharing the same binder. An impulse noise can appear at some point in time and space during any data transmission, and as the transmission continues, the noise propagates though the channel to the receiver. The received noise is time dispersed and shaped by the channel during its transmission. The noise can be considered as the channel impulse response. ADSL provides some techniques to avoid this kind of noise, such as FEC, Trellis Coding and Impulse Noise Protection. 37

2.4 Video Quality Assessment When evaluating a video streaming application, the received video quality is of crucial importance for the obtained results. Thus, many studies have been done in order to assess video quality in a proper way. Today there are two ways of evaluating video quality, objective video quality metrics and subjective video quality metrics. However subjective assessments seem to be rarely employed because of its cost. Objective video quality metrics make use of mathematical methods and are likely to be used when processing a lot of information. On the other hand, subjective video quality metrics make use of an audience that watches a received video and gives a score. Objective video quality metrics can be classified according to the availability of the original video, which is considered to be distortion-free or perfect quality, and may be used as a reference to compare a distorted image against. Most of the proposed objective quality metrics in the literature assume that the undistorted reference signal is fully available. This is known as Full Reference (FR) assessment, which is able to determine video quality when comparing the received video to the reference video. However, when the original video is not available it is not possible to use the FR method. Therefore, since Non Reference (NR) approach does not need any information regarding the original video, it uses only the received video to assess its quality. NR video quality assessment turns out to be a very difficult task, although human observers usually can effectively and reliably assess the quality of distorted image or video without previous knowledge as a reference. The other approach is the Reduced Reference (RR) approach, which utilizes some information that the original video contains, such as statistical variables, in order to measure and compare to the distorted video. Some of these metrics explore the Human Visual System (HVS) to be more precise when determining the video quality. However, lots of discussions have been made to choose the best video quality metric where the correlation to the HSV is strong.

2.4.1 Subjective Video Quality Metrics Any information that originates from users, experts or observers can be considered to be ‘subjective’ data. Subjective methods that are specifically unstructured in nature include open interviewing or participative observation. Subjective methods have the advantage of providing a wealth of information. The disadvantage is that all the information has then to be analyzed extensively. Structured subjective methods such as questionnaires and checklists can provide concise data and valuable results very efficiently [63].

38

The most used subjective metric is the MOS (Mean Opinion Score). MOS is the human impression of the video quality, which is given on a scale from 5 to 1 [35]. Score 5 corresponds to the best quality and score 1 to the worst. The MOS method subdivides in different categories which are also specified by ITU, the Single Stimulus Continuous Quality Evaluation (SSCQE) and the Double Stimulus Impairment Scale (DSIS). In the SSCQE method, viewers are presented a series of video sequences and then they evaluate the instantaneous quality, which means the video quality of that exact time when they are watching the video sequence. They evaluate the video sequences in a real time mode using a slider with a continuous scale. Yet, in the DSIS approach viewers are shown multiple sequence pairs consisting of a “reference” and a “test” sequence. They give a unique score to the video sequence depending on the whole impairment contained in it. This score follows a five-level scale ranging from “imperceptible” to “very annoying”. The SSCQE method yields quality ratings at regular time intervals and can thus capture the perceived time variations in quality. The ratings are absolute in the sense that viewers are not explicitly shown the reference sequences. This corresponds well to an actual home viewing situation, where the reference is not available to the viewer either. The DSIS method only yields one rating per clip, and viewers evaluate the relative degradation of the video with respect to the reference, which is considered an easier task [91].

2.4.2 Objective Video Quality Metrics Differently form subjective approach, any information which can be recorded without potential bias or which is stored in archives is considered ‘objective’. Objective methods of data collection often result in highly reliable information but are usually quite limited in the scope for interpretation. Certain system-based measures can be recorded objectively and relatively automatically via the system in question but complex processes, such as user interaction are difficult to record in this way. The analysis of objectively recorded data can often be time consuming [63]. The Peak Signal-to-Noise Ratio (PSNR) is a mathematical measure computed for each frame of the video sequence. It represents the objective video quality for each video frame by a single number in dB. Indeed, a recent study of the Video Quality Experts Group [84] found that PSNR is still a good measure comparing to other alternatives. The PSNR is based on the Mean Square Error (MSE), which calculates the difference between each pixel from the original frame and the distorted frame. PSNR is commonly calculated using the Y component (Luminance) and its maximum possible value. The MSE equation is given by 39

M

MSE =

N

∑∑ [ f (i, j ) − F (i, j )]

2

i =1 j =1

M ×N

Where f (i, j) represents the pixel positioning at (i, j) in the original frame and F (i, j) represents the same pixel but in the distorted frame. Using the MSE equation, the PSNR equation can be defined as follows

⎛ 2n ⎞ ⎟⎟ PSNR = 20 × log10 ⎜⎜ MSE ⎝ ⎠ Where 2n means the maximum possible value of the luminance component for each pixel within the video frame which for a typical 8 bit value is equals to 255. Despite the fact that several objective video quality models have been developed in the past two decades, PSNR continues to be the most popular method to evaluate the quality of different pictures [87]. The Video Quality Metric (VQM) [68] measures the perceptual effects of video impairments including blurring, jerky/unnatural motion, global noise, block distortion and color distortion, and combines them into a single metric. Some comparison results from [68] have shown that the VQM has a great correlation with other subjective quality metrics and has been adopted by the ANSI as an objective quality metric. It combines 7 parameters in order to have a VQM quality index that indicates the video quality. These seven parameters are 4 Y spatial gradients, 2 from CB, CR chrominance components and one parameter is based on contrast and absolute temporal information features, both extracted from the Y luminance component. Moving Pictures Quality Metric (MPQM) [49] exploits some HVS properties. There are two key human perception properties that have been intensively studied: contrast sensitivity and masking. Contrast sensitivity consider the fact that a signal is detected by the eye only if its contrast is greater that some threshold. The eye sensitivity varies as a function of spatial frequency, orientation and temporal frequency. Masking is related to the human vision response to a combination of several signals. A stimulus consists of two types of signals (foreground and background). The detection threshold of the foreground will be modified as a function of the contrast of the background [87]. MPQM value ranges from 0 to 5 where 0 means bad and 5 excellent. It is known to give good correlation with subjective tests for some cases but give bad results for other according to studies conducted by Mohamed [59]. 40

SSIM (Structural Similarity Index) [88] measures structural distortions in the video, instead of errors. The structural information in an image is considered those attributes that reflect the structure of the objects in the scene, which is independent of the average luminance and the contrast of the image. Human vision system is more accurate in extracting structural information and not so accurate in extracting the errors. Thus, a measurement on structural distortion should give a better correlation to the subjective impression. The SSIM value ranges from -1 to 1. The SSIM equation is defined as follows

SSIM =

(2 xy + C1 )(2σ xy + C2 ) [( x ) 2 + ( y ) 2 + C1 ](σ x2 + σ y2 + C2 )

Where x is the estimate of the mean of x, y is the estimate of the mean of y, σ x is the variance of x, σ y is the variance of y, σ xy the covariance of x and y. C1 and C 2 are constants.

41

3 Related Work “Two things are infinite: the universe and human stupidity; and I'm not sure about the universe.”

Albert Einstein

This chapter aims to explain what other authors have been doing in the video streaming scenario and the problems that they are facing. Furthermore, it presents the problems that may appear when video is being streamed over an unreliable network such as the Internet. In Section 2.1 we present the main problems related to the video streaming. The efforts that researchers have been making to overcome problems related to video transmission are exposed in Section 3.2. Yet, in Section 3.3 we present video quality assessment techniques commonly used in order to evaluate the user perception when watching a video.

3.1 Video Streaming Impairments The goal of transport protocols is to transmit signals from one point to another point. These points are connected by communication network employing specific protocols. Multimedia original signals are known for having a great data rate and they need to be encoded using some compression technique to reduce the bit rate. The transport protocols are responsible for arrange the data into packets at the sender side. At the receiver side the encoded multimedia stream is reconstructed from the stream of delivered packets and then decoded to produce a useful multimedia signal to be played back or stored for further use In this data transmission scenario, many problems may occur during the process that will lead to incorrectness of data at the receipt side. Data transmitted over a packet network such as the Internet can be affected by packet losses. But the loss process is strongly dependent on the application and also on the network type and transport protocols. The sources of errors are mainly bit errors and packet losses. The bit error comes from a bad interpretation of transmitted data at digital receivers, mainly because of noise appearance during transmission. Recently many telecommunication systems are supporting different types of real-time transmission, video

42

transmission being one of the most important applications. In real-time video applications if packets arrive after their frame decoding and display time, they are useless and discarded [19]. While multimedia applications can tolerate some data loss, excessive packet loss yields unacceptably low quality. Since video encoding relies upon frame dependencies to achieve high compression rates, the random dropping of packets by routers can seriously degrade video quality. For example, as little as 3% MPEG packet loss can cause 30% of the frames to be undecodable [93]. Although packet loss represent a great impairment in the video transmission, other metrics like delay and jitter are also very important because they can have a considerable impact under the video quality. Thus, in video transmission systems not only the actual loss is important for the perceived video quality, but also the delay of frames and the variation of the delay, usually referred to as frame jitter. Digital video always consists of frames that have to be displayed at a constant rate. Displaying a frame before or after the defined time results in “jerkiness” [46]. In fact, many researchers limit themselves to reduce the packet loss rate, packet delay or packet jitter considering those metrics enough to measure the quality of the resulting video transmission. It is, however, well known that the above mentioned parameters can not be easily, uniquely transformed into a quality of the video transmission: in fact such transformation could be different for every coding scheme, loss concealment scheme and delay/jitter handling [46]. In addition to some metrics that are direct related to the video transmission scenario, there are other know metrics that are direct related to the video degradation, then making video quality also dependent to the coding process. The coding process brings the problem of perceptual quality degradation either directly or indirectly. The first category of perceptual quality degradation like blocking edge artifacts, mosaic pattern effect, blurring, etc. is directly caused by the video compression process. The second category of perceptual video quality degradation is caused by the inevitable packet loss in today’s best effort IP network. Because the compression process removes both spatial and temporal redundancy of the original video, every packet is very important for the video reconstruction at the receiver side [71]. That is the reason why packet loss, even in a small number, can have a severe impact on the video quality. Therefore, some kind of extra protection has to be used when streaming video over these kinds of networks. Another important impairment related to the video streaming process is the noise that can be coupled together with the transmitted signal. Noise may be defined as an unwanted signal that interferes with communication, measurement and perception of a signal. Noise can be a real undesired effect in DSL transmissions. Taking this into consideration, it is really important to 43

predict and try to eliminate or avoid the different types of noises that may interfere in the data transmission. Noises can be classified in many sorts. However, evaluating the data errors caused by this noise is not trivial due to its complex statistical nature, which until recently had not been well understood, and the complicated error mitigation and framing techniques used in DSL systems. An analysis of some kind of noises presented in an ADSL environment is studied in [64]. In addition, the author presents results when streaming MPEG2 video under the impact of these kinds of noises, but he does not go deeper in some parameters related to the ADSL systems and lower network layers.

3.2 Overcoming Video Streaming Impairments Knowing that many factors are involved in the video streaming process and the existence of many problems, researchers have been making many efforts to optimize the video transmission and solve these problems. There are a lot of strategies when looking to the whole different layers involved. Some of them focus on application level details, network layer, link layer or physical layer. In [20] a new scene-complexity adaptive mechanism, namely the Adaptive MPEG-2 Information Structuring (AMIS) mechanism is presented. This scheme modulates the number of resynchronization points (i.e. the slice headers and intra-coded macroblocks) in order to maximize the perceived video quality assuming it is aware of the packet loss probability and the error concealment technique implemented in the decoder. Not knowing this probability could lead to a bandwidth misusage, since the technique is adding redundant information in order to achieve a better video quality. The distortion metric used to evaluate the video quality the luminance difference betweens macroblocks within a frame. This is a sort of PSNR, but used for each macroblock. In order to evaluate the probability of the packet loss a two state Markovian model was used. The author mentioned that an application level FEC scheme was under investigation. Although the era of digital communication on broadband connections is present in our present line, some transmission constraints have to be faced, e.g. available bandwidth. In [48] it is proposed a technique to dynamically monitor the available bandwidth and with this make an adaptation to stream the video content. In order to evaluate the available bandwidth a Nayve Bayes classifier is used. Metrics like jitter, delay, packet inter arrival time and packet loss are also used to predict the available bandwidth and to feed the classifier. Having the classifier working, three video with different bitrates are kept in the streaming server. The main problem of this approach is having to keep the same video file encoded with different bitrates in the streaming server. This could be 44

solve by coding the video in a real time mode and make any adjustment of the video bitrate depending of the results acquired from the classifier. The same problems that [48] had are cited by [52]. In this last one a framework is proposed to mitigate the problems related to the misusage of the available bandwidth. The sending rate is dynamically adjusted to obtain a maximal utilization of the client buffer and minimal bandwidth allocation. To guarantee a more reliable and better quality of delivery of the video frames, retransmission and selective drop of different frame packets are integrated into our framework. As the author is aware that I frames are more important than B frames for a better video perceptual quality, then when there is a high network congestion the B frames packets are randomly dropped to decrease the requirement of the bandwidth and there is any I frame packet loss a retransmission scheme is adopted to ameliorate the video quality. For the simulations the author used the NS-2 [66] with a 1.15 Mbps video and 5 different TCP based background flows. Furthermore, PSNR quality metric was utilized to show that his proposal was satisfactory. Sometimes in order to provide a good perceptual video quality different QoS schemes are used. A technique to deliver nearly constant perceptual quality of services when streaming video over Differentiated services IP networks is presented in [69]. The author describes an algorithm to mark packets that might be important, i.e., the packet does carry crucial information about the video, e.g., sequence headers and picture headers. The algorithm consists of predicting how the data that the packet is carrying would affect the distortion level in the received video. This prediction is done using the MSE that belongs to the PSNR calculation algorithm. These important packets are marked as “premium service packets” and the other ones as “regular service packets”. In addition, the PSNR metric was used to evaluate the video quality and certify that the proposal was adequate. Some tools have been developed to assist other works related to the video streaming scenario and video quality assessment. A complete framework for video transmission and quality evaluation is presented in [46]. This framework called Evalvid is able to evaluate video transmitted over a real or simulated communication network. Furthermore, lower layer metrics like loss rates, delays, and jitter are also calculate. In addition, for higher layers metrics the framework supports a subjective video quality evaluation of the received video based on the frame-by-frame PSNR calculation. The author mentions the jitter and delay effect on the video quality and explains how to tackle this problem. A technique called play-out buffer is introduced to compensate the amount of jitter that may exist in the video transmission over the network. For bigger buffers scenario the jitter would be reduced, though the delay would increase as the frames would remain in the buffer waiting to be displayed. On the other hand, a small buffer would not eliminate jitter, but frames would be 45

displayed as soon as they arrive at the destination. When explaining the methods used to evaluate the video quality, the author presents some tools in order to do that task. The work implements a tool able to fix videos that an entire frame loss has occurred during transmission. In [24] a real ADSL/ATM access network testbed is set up to evaluate and manage QoS scenario when streaming MPEG-2 video streams in a constant bitrate. In the experiments the author was able to set the number of MPEG-2 Transport Stream packets that were used by the AAL5-SDU (Service Data Unit) and to discard ATM cells to simulate impairments during transmission. The experiments were conducted with four different video types encoded at three different bitrates varying cell discard levels and video GOP structure. In order to evaluate the quality of the video an objective metric known as ITS mean opinion score [77] or VQM was used. The QoS referred by the author is the degree of satisfaction subjectively defined by the user of the service. Sometimes that is also called QoE (Quality of Experience). In [22] a study of the end-user perception when streaming MPEG-2 video in a constant birate over an ATM/AAL5 network is made. One important fact in this work is that the author evaluates two different phenomena of the video transmission. The first one is how the video become after a constant bitrate enconding process and the second one is the effect of cell loss error (CLE) on the end-user perceptual quality. For the first evaluation, a video sample was coded in different bitrates and its quality was measured. Two different video quality metrics were used, one was the PSNR and the other one is the MPQM [49]. The results have shown that when video quality is high after encoding, the PSNR metric still have a rough gain even if the viewer is not able to notice any difference between the original video and the encoded video. When presenting the MPQM results, the author shows that even when increasing video quality, i.e. its bitrate, the MPQM value does have a smooth gain. Although this understanding obtained from his results, the PSNR metric value should not be interpreted as a single point in a scale. Therefore, PSNR values can be inserted in a value range that indicates how good the video quality is [46]. A segmentation scheme is shows when presenting the ATL Cell Loss impact on the video quality. This segmentation illustrates how the packetized stream is encapsulated since application level until is becomes ATM cells of 53 bytes each. Using different CLR values and different video birates give readers an idea about what would be worse to the end user, the CLR or the compression rate. Some of these authors develop an analytical model to expose their ideas, but these ideas have to be validated somehow. In order to verify the precision of a research result, evaluate the performance of algorithms or the reliability of a proposal, there are two different approaches. One of them is using software simulator, such as NS-2, which provides substantial support for simulation 46

of TCP, routing, and multicast protocols over wired and wireless network. The advantages of using software simulator are the low cost for large scale test and quick implementation of new protocol without considering other layer’s detail [50]. The disadvantages are there are always gaps between the real system and simulation models, since it is impossible to simulate all hardware and communication link situations with software simulator. The other approach is using physical computers to set up a testbed, and implementing the real system on it. It is a necessary way to complement software simulator. In [50] the authors described in details how the testbed was set up to measure the video streaming in a mesh network. Many tools were used, from tools to generate video and data traffic to specific decoders and video quality measurement tools. Looking at the results of [24] and [50], it is noticeable that the main contribution to this work is the testbed set up description made by their authors. In [82] the idea was basically the same as [22], though the MPEG-2 is encoded in a variable bitrate (VBR). In addition, a model-based data loss generator was used to simulate packet network losses was described in further details. Hence, a two-state Markovian model was used for that purpose, where states 0 and 1 respectively correspond to a correct and an incorrect packet reception. The transition rates between the states control the lengths of the bursts of errors. Looking at [6] proposal, it is possible to perceive that small packet loss rates translate into much higher frame error rate, e.g. 3% packet loss could translate in 30% frame error. This occurs due to the fact that packets can carry information about more than 1 frame. For instance, the methodology used was that each slice of the frame would be encapsulated in its own packet and an entire B frame was encapsulated into a single packet. In [51] a methodology to evaluate a MPEG-4 video streaming over a UMTS (Universal Mobile Telecommunications System) network is described. This is done by using a raw YUV format video file, a MPEG-4 encoder/decoder, a video sender which generates video trace files, a network simulation which is fed with the video traces to simulate the video traffic and a Peak Signal to Noise Ratio (PSNR) and Mean Opinion Score (MOS) programs to evaluate end-to-end video quality. A similar methodology is described in [28]. However, this work focuses on real experiments, using a network emulator instead of network simulator. With the network emulator, the author has more control when using tools that can’t be always incorporated in the network simulators. Thus, this utilized a streaming server and a streaming media client, an IP network emulator, a high-

47

performance packet capture device and a packet flow regenerator enabling repeatable performance measurements of streaming media applications. Following the same idea of [51], an evaluation of streaming video content in Mobile Wireless Network is made in [81]. Both subjective and objective video quality measurements were used. PSNR was used for the objective quality and SAMVIQ [47] for the subjective quality. In addition, two video sequences were used with a GOP of 12 and encoded with different bitrates. In order to setup the evaluation scenario, the NS-2 and the Evalvid tool was used to simulate the transmission environment and to collect all the necessary information needed for the objective video quality evaluation like PSNR values, frames lost, packet end to end delay and packet jitter. MPEG-2 video streaming impairments are discussed in [27]. The work presents the MPEG standard and how the transmission behaves when video data is packet into transport stream protocol. Moreover, some ATM Adaptation Layer and ATM encapsulation of MPEG are shown. In addition, the effects that an ATM cell loss rate can have when looking at the video quality. The authors conclude that the use of forward error correction coupled with error concealment techniques should improve video quality in error-prone networks (such as xDSL access networks). Error correction and concealment techniques embedded in end devices can reduce network requirements and ultimately network costs. Error control or error correction is necessary to reduce the impact of bandwidth constraints, packet loss and delays on the quality of the received video. In the absence of error control, it is virtually impossible to provide acceptable quality of play-out with real-time video data delivered over the Internet. The two major approaches used for error control are retransmission and forward error correction (FEC). However, retransmission may lead to intolerable delays for real-time video applications. Thus, one of the most used techniques to prevent problems during packet transmission is FEC. FEC means that redundancy is added to the data so that the receiver can recover from losses or errors without any further intervention from the sender [23]. As expected, although FEC seems really promising when used, the addition of FEC packets reduces the available rate for source coding. Forward Error Correction can be further divided into Media Independent FEC, which uses block, or algebraic code to produce additional repair packets for transmission, and Media Dependent FEC, which uses the knowledge of the contents of the transmitted packages [7]. Another used technique is the Interleaving. This technique acts by spreading the burst errors during transmission, so that video is not severely impacted. A combination of FEC and Interleave seems more appropriate since FEC is more efficient for isolated error than for sequenced errors. FEC and Interleaving have been studied and used with success by many authors ([21], [18], [29], [23], [44], [7], 48

[54], and [8]). Knowing that FEC can reduce the available bandwidth when used, some authors present an attempt to use this technique with caution. So that FEC redundant bytes are only used when some impairment at the transmission channel is detected. Therefore, a dynamic FEC mechanism works in a better way than a static FEC. In [92] a jointly FEC and the adjustment of the GOP structure scheme is used to mitigate the effects of packet loss in a TCP friendly scenario. In order to successfully achieve the proposed analytical model, the author analyzes and investigates parameters as round trip time and TCP retransmission time out interval. Additionally, some other parameters as the size of I, B and P frames are needed because the amount of FEC used depends on the frame type. The [93] proposal and the [92] proposal have similar approaches. The main difference is that in [93] the FEC was used in an adaptive manner taking into account not only the network conditions, but the video quality. In this case the VQM [68] model was used in order to assess the transmitted video quality. In this work the author is conscious that for small amounts of packet loss, video frames may suffer from high losses leading to a great amount of undecodable frames. This occurs because packets may carry crucial information in order to let the decoder able to decode the video frame.

3.3 Evaluating Video Impairments In all the works presented in the previous section, an attempt to provide a good technique to deal with the problems related to the video streaming was made. Therefore, a method to evaluate their proposed technique had to be evaluating the video quality when received by the end user. Different metrics to evaluate video quality were utilized; both of these were objective and subjective metrics, e.g. PSNR, VQM, MPQM, MOS and SAMVIQ. Although some authors ([22] and [82]) consider PSNR an unreliable metric because it does not correlate well with the human vision system (HSV), some authors still use it ([52], [51], and [81]). Despite these different approaches, the PSNR continues to be the most popular evaluation of the quality difference between pictures. Indeed, a recent study of the Video Quality Experts Group (VQEG) found that the PSNR still is a measure as good as the proposed alternatives [17]. Hence, PSNR metric plays an important role in the Video Streaming field, though there is a slightly problem when using it when frames are lost during video transmission. This occurs because PSNR takes into account the frame by frame difference. That means that its algorithm needs exactly the same quantity of transmitted frames as the original number of frames. Generally when this problem exists is because the decoder is not able to handle lost frames in the decoding process and the synchronization is lost. A mismatch would make quality assessment impossible. A decent decoder 49

can decode every frame, which was partly received. Some decoders refuse to decode parts of frames or to decode B frames, where one of the frames misses from which it was derived [46].

To solve this problem, a freeze file has to be provided to the VideoMeter tool [17]. This freeze file contains the frames that are to be frozen for the specified stream during the playback for the difference picture and PSNR calculation. So, the VideoMeter is able to freeze the current frame in the original video until is finds the according frame in the transmitted video. When freezing the frame number n then PSNR will be calculated with the last decoded frame in the transmitted video. On the other hand, Evalvid includes in its framework the Fix Video (FV) tool [46]. The FV tool is only needed if the codec used cannot provide lost frames. Following the same approach of VideoMeter, the FV inserts the last decoded frame instead of an empty frame in case of a decoder frame loss. This handling has the further advantage of matching the behavior of a real world video player.

50

4 Performance Evaluation “Tell our enemies that they may take our lives, but they'll never take our freedom!”

Quote from the movie Braveheart

This chapter shows the methodology used to conduct the experiments. Additionally, it shows how the testbed was setup in order to do such required tasks.

4.1 Testbed Setup Aiming at collecting the necessary metrics and analyze the experiments being conducted, we had the need to setup some software/hardware related equipments for that purpose. The experimental testbed utilizes two different networks, the first one for management traffic and the other is the DSL network which is going to be used when conducting real experiments.

For streaming multimedia content, two computers were used, one behaving as a multimedia client which would receive the streamed video and the other one as a multimedia server which would stream the video. These computers were configured running Linux operating system with Gentoo distribution. In order to stream the video, VLC (VideoLAN Client) [86] software was used in both server and client side. The video files were previously stored on the server so that they could be streamed over the DSL network line. The D-ITG (Distributed Internet Traffic Generator) tool [10] was used to generate background traffic in the experiments. For accuracy purposes in terms metrics such as delay and jitter, the client and the server machines used for sending/receiving the traffic had their internal clocks kept synchronized via NTP (Network Time Protocol). Clock synchronization occurs through the management network, not through the DSL line. The main scripts run in a separate computer which controls the multimedia client and multimedia server. These scripts are coded in Matlab® [53] and are responsible for controlling all the experiments, i.e. calling the Linux shell scripts, and controlling all devices required in the experiments, such as the line emulator and the noise generator. In addition, they collect some metrics that are stored in the user Modem (CPE) and in de IPDSLAM (CO). Nevertheless, some 51

scripts are also needed in the server and client side in order to manage the experiments. These are written in Shell script language. Some other devices are controlled by the Matlab scripts such as the line emulator and the noise generator. These devices are controlled either by the COM serial ports or by their GPIB (General Purpose Interface Bus) The line emulator is responsible to set the loop length between the customer premises (CPE) where the modem is located and the central office (CO) where the DSLAM is located. The line emulator can reach ranges from 0 up to 7000 meters with a granularity of 25 meters and emulates European ADSL lines with 26 AWG, or 0.44 mm. Moreover, its impedance is 50Ω. The noise generator is able to generate and inject arbitrary functions into the DSL line. These functions can be used to generate different noise profiles for our experiments as we are going to show in later sections. When running the experiments, some metrics are collected directly from the Modem and the DSLAM by their OID (Object ID) in their MIB (Management Information Base), they are Layer 1 and Layer 2 metrics such as the amount of FEC Bytes been used per codeword, INP set by the equipment, delay caused by the interleaving process and so on. However, some metrics are not available in these devices. Layer 3 metrics, such as delay and jitter, have to be extracted in a different manner. Hence, the data traffic running through the DSL connection has to be captured for further analysis when the experiment finishes. For this task, TCPDump [75] was used to capture and to save all traffic information regarding the conducted experiment. This captured traffic is then analyzed by a program designed by us which utilized the libpcap library [78] in order to extract such important metrics. This program was written in C/C++ language.

52

Figure 19 Testbed Organization for running the experiments

4.2 Analyzing ADSL Metrics and Parameters In order to analyze the ADSL parameters, we conducted some experiments varying the loop length and setting some important parameters such as the ADSL standard. After that, we synchronize the line and collect some metrics and observe their behavior. For this experiment we configured the line with a maximum acceptable interleaving delay of 32 ms, minimum INP value of 0, the target SNR margin of 6db, the maximum SNR margin of 31 db and the minimum SNR margin of 0 db. These parameters are set every time the loop length is changed and the loop length ranges from 50 to 7000 meters with a step of 50 meters. Table 5 summarizes all parameters used in this experiment and whether they are fixed or are changed in the experiment.

53

Table 5 Experiment Setup Parameters.

Parameter

Value(s)

Service Configuration

1 PVC, UBR with no QoS (fixed)

xDSL Standard

ADSL, ADSL2 and ADSL2+ with Annex A

Interleaving Delaymax

32 ms (fixed)

INPmin

0 (fixed)

Loop Length

50 to 7000, 50m step

Minimum SNR Margin

0 db (fixed)

Target SNR Margin

6 db (fixed)

Maximum SNR Margin

31 db (fixed)

Figure 20 depicts the downstream rate that the line can achieve using the parameters mentioned above for different loop length. The rates are shown for different ADSL standards. Nevertheless, Figure 21 shows the line attained rate for the upstream direction. Observe that the standards downstream rate differ severely from each other, having more than 3 times bandwidth when comparing the ADSL and ADSL2+ standard, almost 8Mbps and 24 Mbps respectively. On the other hand, for the upstream direction they are quite the same, achieving almost 1.2 Mbps. It is important to emphasize that there is a great difference between the downstream and upstream rate, independently of the standard being used. 26

1.4 ADSL ADSL2 ADSL2+

24 22

ADSL ADSL2 ADSL2+

1.2

18

Upstream Bitrate[Mbps]

Downstream Bitrate[Mbps]

20

16 14 12 10 8

1

0.8

0.6

0.4

6 4

0.2

2 0

0

1000

2000

3000 4000 LoopLength [m]

5000

6000

7000

Figure 20 Downstream rates for different loop length

0

0

1000

2000

3000 4000 LoopLength [m]

5000

6000

7000

Figure 21 Upstream rates for different loop length

54

When FEC bytes are inserted with the goal of correcting corrupted blocks, they are more efficient when errors are spread through all the data that is been sent. Hence, interleaving is applied in order to make the insertion of the FEC bytes more efficient. As said previously, this approach does not come with disadvantages. The interleaving can do some harm to a specific kind of traffic that does not tolerate large values of delay. Figure 22 shows the amount of interleaving delay for the downstream direction that will be the resulting of the data scrambling process. The results are presented for different ADSL standards. Looking at the picture we can see that for the ADSL2 and ADSL2+ standard a more intelligent mechanism is used due to the adaptation made when the loop length increases. This adaptation can be seen when looking at the abrupt change from the 4050 to the 4100 loop length, where the value goes down from 32 ms to 16 ms. This phenomenon occurs more than one time and is directly related to the INP value which will be presented and explained later in this same section. In Figure 23 the graph depicts the amount of interleaving delay for the upstream direction. The behavior of the curves shows that when the loop length increases, the interleaving delay increases in the same manner. One important fact that has to be noticed is that the equipment respected the maximum interleaving delay imposed by us when configuring the line. As said previously, we configured the maximum acceptable interleaving delay of 32 ms, for both

35

35

30

30

25

25 Interleaving Delay [ms]

Interleaving Delay [ms]

downstream and upstream direction.

20

15

10

15

10

ADSL ADSL2 ADSL2+

5

0

20

0

1000

2000

3000 4000 LoopLength [m]

5000

6000

ADSL ADSL2 ADSL2+

5

7000

Figure 22 Downstream Interleaving Delay for different loop length

0

0

1000

2000

3000 4000 LoopLength [m]

5000

6000

7000

Figure 23 Upstream Interleaving Delay for different loop length

SNR margin has an important role in the ADSL transmission. It can be considered a kind of noise protection since it is well related to the BER. Increasing SNR margin can avoid transmission errors, but increasing it without caution can decrease the line rate. Figure 24 depicts the configured SNR margin for the downstream direction. Acting in the same manner as the interleave delay, the 55

ADSL2 and ADSL2+ standard behaves in a quite same way, differently of the ADSL standard. Even though the ADSL standard has higher values for short loop lengths, it still respect the maximum configures SNR value of 31 db. Moreover, the ADSL2 and ADSL2+ standards kept the SNR margin close to the target SNR margin value of 6 db, which was configured in the beginning of the experiment, though ADSL2+ keeps the value even closer to 6 db, having the maximum value of 9 db. When looking at Figure 25 the configured SNR margin of the upstream direction can be seen. Differently from the downstream direction, the ADSL standard was able to keep the configured SNR margin close to the target SNR margin. The ADSL2+ was the best one, bounding the SNR margin between 5 db and 7 db. 24

10 ADSL ADSL2 ADSL2+

22 20

9 8

18

7 SNR Margin [db]

SNR Margin [db]

16 14 12 10 8

5 4 3

6

2

4

ADSL ADSL2 ADSL2+

1

2 0

6

0

1000

2000

3000 4000 LoopLength [m]

5000

6000

7000

Figure 24 Downstream SNR margin for different loop length

0

0

1000

2000

3000 4000 LoopLength [m]

5000

6000

7000

Figure 25 Upstream SNR margin for different loop length

INP value is calculated taking into consideration the interleave depth, the number of FEC bytes per codeword and the number of bits per symbol. It indicates maximum number of consecutive DMT symbols that can be recovered from a noise, which means that if a noise lasts more than the “INP” DMT symbols, these symbols will no be recovered by the INP mechanism. With the same idea of the SNR margin, INP has its drawbacks, including the line rate decrease due to the redundant data being inserted during transmission. Figure 26 shows the configured INP for the downstream direction. All the standards behave in the same manner, but ADSL2 and ADSL2+ seems to be likely than when comparing to the ADSL standard. Figure 27 depicts the configured INP value for the upstream direction. Moreover, the graph has the same behavior of the one showed for the downstream direction, but for the ADSL standard it shows that for almost all loop length values the INP value is 0. The minimum INP value imposed by us was respected, since we configured the minimum value to 0. 56

Comparing Figure 22 and Figure 26 , a pattern can be found, proving that there is a relation between the interleaving delay and the INP. This occurs because both of these metrics are related to the interleaving depth and the amount of FEC bytes using for correcting corrupted blocks. It is important to emphasize that even that the INP value is calculated using the interleaving depth, the number of FEC bytes per codeword and the number of bits per symbol, we can not set these values, so the equipment applies its own algorithm to set these 3 variables in order to respect or desired minimum INP. 18

18 ADSL ADSL2 ADSL2+

14

14

12

12

10 8 6

10 8 6

4

4

2

2

0

0

1000

2000

ADSL ADSL2 ADSL2+

16

INP [DMT Symbols]

INP [DMT Symbols]

16

3000 4000 LoopLength [m]

5000

6000

7000

Figure 26 Downstream INP value for different loop length

0

0

1000

2000

3000 4000 LoopLength [m]

5000

6000

7000

Figure 27 Upstream INP value for different loop length

Knowing that INP value is calculated using other parameters, these parameters behavior have to be analyzed. The interleaving delay (D in the INP equation) indicated the amount of FEC frames that is scrambled together. The higher this value is the higher the delay will be, since the scrambler has to wait until the buffer holds the number of FEC frames needed to begin the scrambling process. Figure 28 depicts the number of FEC frames used by the interleaving process in the downstream direction. All the standards behave equally, but the ADSL differs a little bit from the others. The maximum FEC frames used by the interleaving process in the downstream direction is 64. On the other hand, looking Figure 29, it can be seen that ADSL differs a lot from ADSL2 and ADSL2+ and the maximum FEC frames used by the interleaving process in the upstream direction is 8.

57

70

12 ADSL ADSL2 ADSL2+

50

40

30

20

8

6

4

2

10

0

ADSL ADSL2 ADSL2+

10 Interleaving Depth [FEC Frames]

Interleaving Depth [FEC Frames]

60

0

1000

2000

3000 4000 LoopLength [m]

5000

6000

0

7000

Figure 28 Downstream Interleaving Depth for different loop length

0

1000

2000

3000 4000 LoopLength [m]

5000

6000

7000

Figure 29 Upstream Interleaving Depth for different loop length

FEC Bytes (R in the INP equation) is the amount for redundant bytes inserted in a codeword with the goal of correct any corrupted data that may occur. When these redundant bytes are not able to correct the corrupted data, then a CRC event occurs. Figure 30 depicts how many FEC bytes is used per codeword for the downstream direction. The ADSL2+ differs from the ADSL and ADSL2+ when the loop length is shorter than 1500 meters. The effect of that difference can be seen when looking at Figure 26, where the ADSL2+ INP value for the same loop range is equal to 0, differently from ADSL and ADSL2. In contrast, when looking at Figure 31, ADSL differs from

18

18

16

16

14

14

12

12 FEC [Bytes]

FEC [Bytes]

ADSL2 and ADSL2+, where FEC bytes are always 0 for all loop lenghts.

10 8 6

8 6

4

ADSL ADSL2 ADSL2+

2 0

10

0

1000

2000

3000 4000 LoopLength [m]

5000

6000

7000

Figure 30 Downstream FEC Bytes for different loop length

ADSL ADSL2 ADSL2+

4 2 0

0

1000

2000

3000 4000 LoopLength [m]

5000

6000

7000

Figure 31 Upstream FEC Bytes for different loop length

58

Figure 32 shows the amount of bits in downstream direction that each DMT symbol is able to carry. It is important to observe that this is the crucial key when obtaining higher data rates. When comparing Figure 20 and Figure 32, it can be seen that the curves for each standard follows the same pattern. The pattern also occurs when comparing upstream bits per DMT symbol depicted in Figure 21 to Figure 33. 7000

350 ADSL ADSL2 ADSL2+

6000

250 Bits per Symbol

Bits per DMT Symbol

5000

4000

3000

200

150

2000

100

1000

50

0

ADSL ADSL2 ADSL2+

300

0

1000

2000

3000 4000 LoopLength [m]

5000

6000

0

7000

Figure 32 Downstream Bits per Symbol for different loop length

0

1000

2000

3000 4000 LoopLength [m]

5000

6000

7000

Figure 33 Upstream Bits per Symbol for different loop length

4.3 Layer 3 and Application metrics In the next sections we are going to present some metrics that are not captured from the CPE Modem and from the DSLAM. These metrics are calculated using packet data and are considered to be Layer 3 metrics. As Layer 3 metrics, in our experiments we used the throughput or rate, end-toend delay which is known as delay, delay jitter which is known as jitter. As said previously, the server and the client machine clocks had to be synchronized because some metrics such as delay and jitter make use of the packet timestamp when they are calculated. So, the packet delay is calculated using the equation below

∆T pkt = Ta pkt − Ts pkt Where Ta pkt is the time when the packet has arrived at the client and Ts pkt is the time when the packet was sent by the server. Logically this is a positive value, since the arrival time should be

59

greater than the sending time. This explains why the clocks had to be synchronized; otherwise the result could be faked. Knowing how to calculate a packet delay, we can calculate the average delay of all transmitted packets through our experiments. The calculation is given by

Delay =

1 P ∑ ∆Tn P n=1

Where ∆Tn is the delay of a certain packet index n and P is the total of packets transmitted through the network. In this work when delay is mentioned that means the average delay is being considered. Another Layer 3 metric such as delay that has to be mentioned is jitter. Jitter can be defined as the delay variation. The following equation shows how to calculate the jitter

Jitter =

1 P ∑ ∆Ti − ∆Ti−1 P − 1 i =2

Where ∆Ti is the packet index i delay and ∆Ti −1 is the packet index i-1 delay. Note that jitter depends on both past and present packet delay that is why jitter is sensitive of the delay variability. The application metrics have to do with what sort of application is being considered, in our case a video streaming application. Thus, a video metric has to be taken into consideration in order to assess the video quality. In previous sections we pointed some other metrics and we showed that PSNR still being a reliable metric when measuring video quality. When streaming video over a noisy channel, many errors can appear during transmission and these errors can cause bad experience to the end user watching the video. This bad experience means that some sort of degradation occurred in the received video and this degradation can be seen just in some slices of each frame or this can be so severe that the decoder are not able to decode the frame correctly. Although PSNR seems to be a fairly good metric to assess the video quality, some problems were found when implementing the algorithm to calculate it. During the analysis of preliminary results, very low PSNR values were obtained for videos that were not supposed to have a bad quality. By watching the video the problem was identified as a loss of synchronization between the source and transmitted video caused by the loss of an entire video 60

frame. This entire frame loss can occur either because the entire video frame was damaged or some important information in its header. In order to overcome this problem the basic PSNR algorithm was adapted to provide a more accurate measurement. Figure 34 shows how the adapted algorithm operates to synchronize the current frame from the transmitted video with its corresponding frame from the original video. In order to do that, for each frame from 1 to N - M of the transmitted video, the algorithm searches its correspondent in the original stream comparing it with N frames at the original side, where M represents the total of lost frames during transmission and N the total of frames in the original one. For instance, the frame received with number 1 will be looked up within the original video from frame 1 to frame 1 + wnd_size, where wnd_size represents the search window size.

Original Frames

Original Frame 1

Original Frame 2

Original Frame 3

Original Frame 4

Original Frame 5

Original Frame 6

Transmitted Frames

Transmitted Frame 1

Transmitted Frame 2

Transmitted Frame 3

Transmitted Frame 4

Transmitted Frame 5

Transmitted Frame 6

...

Original Frame N

...

Transmitted Frame N-M

Figure 34 Synchronization of the transmitted frames with their correspondent from the original video

The algorithm assumes that the corresponding frame will be the one with the best PSNR value for the received frame. Moreover, after finding that the frame number X does not correspond to frame X in the original video. That is, an entire frame loss has occurred, the algorithm counts the number of frames until its corresponding one and updates the offset which represents the current position of the frame within the original video sequence. The modified algorithm for the PSNR calculation can be seen in Figure 35. In addition, Figure 35 shows a step by step example of the algorithm when a windows size of 3 frames is defined. This example is illustrated taking Figure 34 as a reference.

61

Algorithm for frames resynchronization wnd_size := search window size; offset := 0; m := total of transmitted frames; FOREACH frame m search from (frame m + offset) to (frame m + offset + wnd_size) search the best PSNR offset := best PSNR original frame number – frame m number END FOREACH

Example wnd_size = 3 offset = 0 •

•

•

•

Finding best PSNR value for Transmitted Frame 1: o

Starts searching from (Transmitted frame Number + offset) to (Transmitted frame Number + offset + wnd_size) - 1 to 3

o

Best PSNR is Original Frame 2

o

Original Frame 2 minus Transmitted Frame 1 = 1 Frame offset

Finding best PSNR value for Transmitted Frame 2: o

Starts searching from (Transmitted frame Number + offset) to (Transmitted frame + offset + wnd_size) - 3 to 5

o

Best PSNR is Original Frame 3

o

Original Frame 3 minus Transmitted Frame 2 = 1 Frame offset

Finding best PSNR value for Transmitted Frame 3: o

Searches from (Transmitted frame Number + offset) to (Transmitted offset + wnd_size) - 4 to 6

o

Best PSNR is Original Frame 5

o

Original Frame 5 minus Transmitted Frame 3 = 2 Frame offset

frame +

Finding best PSNR value for Transmitted Frame 4: o

Starts searching from (Transmitted frame Number + offset) to (Transmitted frame + offset + wnd_size) - 6 to 8

o

Best PSNR is Original Frame 6

o

Original Frame 6 minus Transmitted Frame 4 = 2 Frame offset

Figure 35 Synchronization algorithm and step by step example having the window size of 3

4.4 Analyzing Video Traffic As shown in the above section, some ADSL parameters and metrics were analyzed. Aiming at analyzing how video would behave when streamed through the ADSL architecture, an experiment was conducted.

62

In this experiment we streamed videos with different bitrates. Hence, this experiment has a crucial relevance as we are able to choose which of the following video bitrates would be more appropriate depending on the distance from the CPE to the CO. Since we are able to use more sophisticated standards, we chose to use the ADSL2+, but in this time we are using the Annex M. The major difference between Annex A and Annex M is the upstream bandwidth. The theoretical upstream rate specified by the ADSL2+M standard is 3.2 Mbps while ADSL2+A is about 1 Mbps. However this upstream rate increase does not come without a cost. The ADSL2+M downstream rate decreases when comparing to ADSL2+A. The Annex M was used in this experiment because users tend to use more upstream bandwidth than what was initially though when the standard was defined. For instance, in a IPTV scenario, the user may interact with the CO in order to change TV channels, to forward pause and rewind movie scenes, to participate in a video conference. Moreover, many users are using P2P (Peer to Peer) programs that require a larger upstream bandwidth to offer their services properly. Even though the CPE and DSLAM had been configured to use Annex M, the upstream rate did not reach the 3.5 Mbps theoretical rate specified by such annex of ADSL2+ standard. The reason is probably due to limitations of CPE equipment. The maximum upstream bandwidth in our experiment was around 2 Mbps. We manage to use different bitrates because we are able to have an idea of which video quality is more reasonable for each scenario. It is important to know that the higher the video bitrate is the better quality it will have. Differently from the previous experiment, know we are increasing the loop length by 250 meters. The reason why we had increased the step size was that each iteration of the experiment takes a lot of time; therefore, we choose the 250 meters step to make the experiment shorter. This decision was made knowing that the information here obtained would be reliable enough

for

our

analysis.

63

Table 6 summarizes all parameters used in this specific experiment. As we are now streaming video content, it is feasible to analyze some Layer 3 metrics, such as throughput, jitter, and delay, among others.

64

Table 6 Experiment Setup Parameters.

Parameter

Value(s)

Service Configuration

1 PVC, UBR with no QoS (fixed)

xDSL Standard

ADSL2+ with Annex M (fixed)

Video Source

Stored Video with bitrates - 1.5 Mbps, 4.0 Mbps, 6 Mbps, 8 Mbps, 12 Mbps and 18 Mbps (GOP 12)

Interleaving Delaymax

32 ms (fixed)

INPmin

0 (fixed)

Loop Length

50 to 7000, 250m step

Minimum SNR Margin

0 db (fixed)

Target SNR Margin

6 db (fixed)

Maximum SNR Margin

31 db (fixed)

The total available bandwidth is one of the major concerning facts when transmitting any sort of data through a network. Moreover, when video content is being delivered, most of the times a great bandwidth is required in order to offer this kind of service successfully. Figure 36 shows the rate of all videos received by the multimedia client. Furthermore, it depicts the synchronized rate and how the curves behave when the loop length becomes greater and a lack of bandwidth occurs. In addition all curves are likely to behave in a constant rate, but when there is no bandwidth available for a certain video bitrate, they seem to follow the synchronized rate curve. Taking a look at the graph, we can notice that streaming a video with a rate of 18 Mbps is almost impossible, because its curves start to drop at really short loop lengths. On the other hand, a 1.5 Mbps video can be streamed for loop lengths up to 4000 meters. It is important to emphasize that the phenomenon occurs for all videos. For instance, the 4.0 Mbps, the 6.0 Mbps, the 8.0 Mbps and the 12.0 Mbps video have their curves invariable until they reach 3000 meters, 2500 meters, 2000 meters, and 1500 meters respectively. While the video bitrate requirements for a transmission with no packet loss are met, the graphs show that the curves seem to approximate a constant. So, the lower the bitrate is, the more 65

constant the curves will be because they will have enough available bandwidth to transmit all of their content for shorter loop lengths. 24 Syncrate 1.5Mbps 4.0Mbps 6.0Mbps 8.0Mbps 12.0Mbps 18.0Mbps

22 20 18

Rate (Mbps)

16 14 12 10 8 6 4 2 0 0

1000

2000

3000 4000 Loop length (m)

5000

6000

7000

Figure 36 Received video rate at the multimedia client for different loop lengths

Another important metric to analyze is the delay. Delay may be one of the most important issues related to the video perception quality when transmitted through a network environment. Figure 37 depicts how delay behaved for different video bitrates when different loop lengths were set. Looking at the result, it is noticed that when the video bitrate is higher the delay starts to increase for shorter loop lengths. For instance, the 18 Mbps video has started to increase its delay when the loop length was about 750 meters. On the other hand, the 4 Mbps video has a little delay increase when loop length reaches 3250 meters. However, a strange behavior occurs because when the delay for a specific video starts to increase, its value overtake other videos where the bitrate is greater than the one being considered. This can be noticed when using the 18 Mbps and 4 Mbps video previously compared. When the 4 Mbps video increase its delay in 3250 meters, its delay value is 0.27s which is greater than the 18 Mbps video delay for the same loop length where the value is 0.09s. In addition, we realize that the delay increased in such a way that it reached almost 1 second. There is a sudden great increase of the delay particularly when the loop length goes from 4000 meters to 4250 meters with the video bitrate is 1.5Mbps. Moreover, the 18Mbps video bitrate had a lower delay than the 1.5Mbps video bitrate, especially when the loop length was high. Having this strange results appeared only at the graphs with no background traffic, some other experiments were taken to understand what would be the causes of this unexpected misbehavior. We managed to run an experiment with just a little background traffic, near 1%. This experiment showed that even with this little background traffic, delay significantly was reduced considerably. The real cause of this 66

strange delay is might be an application problem. Another interesting fact is that this delay increase occurs exactly when loss begins to occur when transmitting the video. Both experiments using different amounts of background traffic and graphs showing packet losses will be discussed in later sections. 1 1.5Mbps 4.0Mbps 6.0Mbps 8.0Mbps 12.0Mbps 18.0Mbps

0.9 0.8 0.7

Delay (s)

0.6 0.5 0.4 0.3 0.2 0.1 0 0

1000

2000

3000 4000 Loop length (m)

5000

6000

7000

Figure 37 Different videos average delay for different loop lengths

Jitter can have an important role in a video streaming scenario because buffers sizes are set based on its value. The higher jitter value is the greater the buffer has to be in order to ensure a continuous playback of the video content. The jitter results are presented in the graphs of Figure 38. Jitter was smoothly affected by different video bitrates for loop length lower than 4000m. The similar behavior happened for all scenarios, where, as the loop length increased the video bitrates followed the same trend. However, when the loop length is higher than 4000m a sudden leap arises. It must be noticed that the values referring to the amount of jitter are quite low, having a maximum of 0.011 seconds or 11 ms. Packet loss is an important metric because it causes a bad video quality in our video streaming scenario and in other scenarios where there is no packet retransmission. Hence, packet loss is a undesirable event in every data transmission.

67

0.012 1.5Mbps 4.0Mbps 6.0Mbps 8.0Mbps 12.0Mbps 18.0Mbps

0.01

Jitter (s)

0.008

0.006

0.004

0.002

0 0

1000

2000

3000 4000 Loop length (m)

5000

6000

7000

Figure 38 Different videos jitter for different loop lengths

It is well related to other metrics, especially when compared and analyzing to the rate metric. Looking at Figure 39, we can see that they are a complement of each other, that is, when the rate is decaying the loss is increasing and vice versa. Therefore, the higher the video bitrate is the higher is the packet loss will be for it. When 1.5 Mbps video is being transmitted losses rise abruptly going from 0% to more than 20% when loop length changes from 4000 to 4250 meters. Another interesting fact is that the lower the video bitrate is packet loss seems to increase even more abruptly. Moreover, when the 18Mbps video bitrate is transmitted a lot of packet loss occurs even when the loop length is 0. Thus, analyzing this scenario, we might know that there is no bandwidth available to transmit video with higher bitrates as 18 Mbps and so on. However, we must know what percentage of packet loss would be acceptable for a video perceptual quality of the user watching a given video that is why we need to evaluate an application level metric to have a further investigation of this scenario. PSNR is one of the most commonly used metrics to measure video quality. This mathematical measure is computed for each frame of the video sequence. The PSNR represents the objective video quality for each video frame by a single number in dB.

68

100 1.5Mbps 4.0Mbps 6.0Mbps 8.0Mbps 12.0Mbps 18.0Mbps

90 80 70

Loss (%)

60 50 40 30 20 10 0 0

1000

2000

3000 4000 Loop length (m)

5000

6000

7000

Figure 39 Packet Loss in percents for different loop lengths

Table 7 shows the possible relation between PSNR and MOS. MOS is the human impression of the video quality, which is given on a scale from 5 to 1, where scale 5 corresponds to the best quality and scale 1 to the worst one. The conversion is interesting for helping the interpretation of the PSNR metric. Generically, we can say that PSNR values lower than 25 dB estimates that a video stream has a poor quality and below 20 the video has a real bad quality. Values higher than 31 dB represent a good video quality signal. The main measure and focus of this discussion concerns YPSNR, because the Y frames carry more information about video and the human eye is more sensible to the change in luminance. PSNR values of 100 are used here in our examples to express that the video has not suffered any degradation or loss. This is due to the fact that PSNR is based on the MSE and when there is no difference between the original pixels and the transmitted ones, MSE becomes 0 and PSNR tends to infinite. Table 7 Possible PSNR to MOS mapping [46]

PSNR (dB) > 37 37 – 31 31 – 25 25 – 20 < 20

MOS 5 (Excellent) 4 (Good) 3 (Fair) 2 (Poor) 1 (Bad)

Figure 40 shows the PSNR considering different video birates. Note that, PSNR decreases when a loop length has increased, indicating that the video quality depends on the loop length. As it would be expected, the videos with lower bitrates have their PSNR affected in a larger loop length than the other videos (for example, 12 Mbps and 18 Mbps). The video quality, as this is reflected 69

through PSNR values, depends on the percentage of lost frames as well as the end-to-end delay. The higher the percentage of lost frames the lower the PSNR values and hence the video objective quality. Another interesting fact is that even little losses, e.g. 3% for the 18 Mbps, affect the PSNR value, making the video with a real poor quality. All PSNR values were calculated using our modified algorithm due to entire frame loss occurrences. 100 1.5Mbps 4.0Mbps 6.0Mbps 8.0Mbps 12.0Mbps 18.0Mbps

90 80

Y - PSNR

70 60 50 40 30 20 10 0 0

1000

2000

3000 4000 Loop length (m)

5000

6000

7000

Figure 40 PSNR calculation for video with different bitrates and loop lengths

Analyzing this experiment we noticed that for low bitrate videos losses occur only after 2000m. This is useful because a video with 4 Mbps bitrate, for example, is a video that could be transmitted as a SDTV quality when using MPEG2 codec. Furthermore, depending on the distance from the CO to the CPE a HDTV quality video could be streamed without any degradation of the video quality.

4.5 Analyzing video traffic with concurrent traffic with no QoS In this section we are going to present experiments results which had the goal of determining the behavior of the video stream traffic when a concurrent UDP traffic is being transmitted under different line configurations (loop length) and 1 PVC configuration (UBR). Here we will be presenting what happens to both traffics when there is no QoS being used to prioritize any of them. The main experiment script runs under Matlab and controls the loop length, minimum INP (0), ATM service category (UBR), and calls the traffic generation script in the Linux machines. The script designed for this experiment generates a UDP background traffic with 20 sources following a Pareto distribution with shape 1.3 and scale varying accordingly to the amount of background traffic we want to generate. After that, we stream all the videos one by one. When all 70

this process is finished we have available all the metrics for the background traffic and the traffic related to the videos saved. Once the experiments are finished, we run the program that we designed passing the client and server dumps as parameters in order to calculate and generate all the metrics that we need. Table 8 summarizes all parameters used in this specific experiment. For both traffics the throughput, jitter, and delay, among others will be analyzed. Table 8 Experiment Setup Parameters.

Parameter

Value(s)

Service Configuration

1 PVC, UBR with no QoS (fixed)

xDSL Standard

ADSL2+ with Annex M (fixed)

Transport Protocol for

UDP

the Background Traffic Video Source

Stored Video with bitrates – 1.5 Mbps, 4.0 Mbps, 6 Mbps, 8 Mbps, 12 Mbps and 18 Mbps

Interleaving Delaymax

32 ms (fixed)

Background Traffic

50% and 100% of available bandwidth

INPmin

0 (fixed)

Loop Length

50 to 7000, 250m step

Minimum SNR Margin

0 db (fixed)

Target SNR Margin

6 db (fixed)

Maximum SNR Margin

31 db (fixed)

When sharing the same transmission channel with background traffic, video traffic is going to have its rate decreased since there is no prioritization scheme to none of these traffics. Looking at Figure 41 we are able to see how the video traffic rate behaves in presence of a background traffic that occupies about 50% of the available bandwidth. Nevertheless, Figure 42 depicts how the background traffic behaves when there is a video traffic sharing the same the same channel. Note that, differently from Figure 36, the video rates depicted in Figure 41 begin to decrease in earlier loop lengths, since the background traffic is present. When traffic background is present, videos with bitrates of 1.5 Mbps are able to maintain their rate until they are transmitted to loop lengths up to 2500 meters. However, there are significant rate decreases for video with higher bitrates. 71

24

24 Syncrate 1.5Mbps 4.0Mbps 6.0Mbps 8.0Mbps 12.0Mbps 18.0Mbps

22 20 18

Syncrate 1.5Mbps 4.0Mbps 6.0Mbps 8.0Mbps 12.0Mbps 18.0Mbps

20 18 16 Rate (Mbps)

Rate (Mbps)

16

22

14 12 10

14 12 10

8

8

6

6

4

4

2

2

0

0 0

1000

2000

3000 4000 Loop length (m)

5000

6000

7000

0

Figure 41 Received video rate at the multimedia client for the 50% background traffic

1000

2000

3000 4000 Loop length (m)

5000

6000

7000

Figure 42 Received background traffic rate at the multimedia client for the 50% background traffic

Figure 43 shows how video traffic behaves when there is a concurrent background traffic that occupies about 100% of the available bandwidth. As expected, this amount of background traffic makes even the lower bitrate video decreases its rate in the beginning of the experiment, that means a 0 meters loop length. Figure 43 depicts how the background traffic behave in presence of different videos. Although it seems that the background traffic showed in Figure 43 have higher rates when comparing to Figure 42, this is normal, since its rate is twice the 50% value used previously and losses will be higher as well, as we are going to present later in this section. 24

24 Syncrate 1.5Mbps 4.0Mbps 6.0Mbps 8.0Mbps 12.0Mbps 18.0Mbps

22 20 18

20 18 16 Rate (Mbps)

16 Rate (Mbps)

Syncrate 1.5Mbps 4.0Mbps 6.0Mbps 8.0Mbps 12.0Mbps 18.0Mbps

22

14 12 10

14 12 10

8

8

6

6

4

4

2

2

0

0 0

1000

2000

3000 4000 Loop length (m)

5000

6000

7000

Figure 43 Received video rate at the multimedia client for the 100% background traffic

0

1000

2000

3000 4000 Loop length (m)

5000

6000

7000

Figure 44 Received background traffic rate at the multimedia client for the 100% background traffic

When analyzing delay, some different results were obtained comparing to results when no background traffic existed. Figure 45 present delay results for the video traffic when 50% of background traffic was used. The graph shows that the 18 Mbps and 12 Mbps video starts with almost the same delay and the other video with different bitrates start with less delay than them. As loop length increases, the other video bitrates follows the same trend and when the loop is about 3000 meters, all the video delays are almost the same. The same occurs for the background traffic 72

delay depicted in Figure 46. As it can be seen, both delays for video traffic and background traffic have their delays bounded in 0.13 s and they follow the same trend for all videos used. The important fact here is that when comparing the strange delay behavior shows in Figure 37, the problem does not occur in the background traffic scenario. 0.12

0.14 1.5Mbps 4.0Mbps 6.0Mbps 8.0Mbps 12.0Mbps 18.0Mbps

0.12

0.1

1.5Mbps 4.0Mbps 6.0Mbps 8.0Mbps 12.0Mbps 18.0Mbps

0.1

Delay (s)

Delay (s)

0.08 0.08

0.06

0.06

0.04 0.04 0.02

0.02

0

0 0

1000

2000

3000 4000 Loop length (m)

5000

6000

0

7000

Figure 45 Video traffic delay for the 50% background traffic scenario

1000

2000

3000 4000 Loop length (m)

5000

6000

7000

Figure 46 Background traffic delay for the 50% background traffic scenario

Looking at all graphs from Figure 47 and Figure 48 we can see that the higher the amount of background traffic is, the higher the delays are. This will be the case until they stabilize, in our case the 100% of background traffic scenario. All videos with different bitrates started almost with the same values and following a tendency as the loop length became longer. Delay values are quite the same if we compare with results showed in Figure 45 and Figure 46. Here, differently from results showed in Figure 37, when packet losses have appeared, delay has not increased that much. 0.1

0.14 1.5Mbps 4.0Mbps 6.0Mbps 8.0Mbps 12.0Mbps 18.0Mbps

0.12

0.08 0.07 0.06

0.08

Delay (s)

Delay (s)

0.1

1.5Mbps 4.0Mbps 6.0Mbps 8.0Mbps 12.0Mbps 18.0Mbps

0.09

0.06

0.05 0.04 0.03

0.04

0.02 0.02 0.01 0

0 0

1000

2000

3000 4000 Loop length (m)

5000

6000

7000

Figure 47 Video traffic delay for the 100% background traffic scenario

0

1000

2000

3000 4000 Loop length (m)

5000

6000

7000

Figure 48 Background traffic delay for the 100% background traffic scenario

73

Comparing jitter values, a similar behavior happened for all background scenarios, where, as the loop length increased the video bitrates followed the same trend. Figure 49 shows jitter results for the video traffic when 50% background was used and Figure 51 shows jitter result for the video traffic when 100% background was used. Their behaviors are approximately the same, having values up to 0.21 ms. 0.025

0.009

1.5Mbps 4.0Mbps 6.0Mbps 8.0Mbps 12.0Mbps 18.0Mbps

0.02

1.5Mbps 4.0Mbps 6.0Mbps 8.0Mbps 12.0Mbps 18.0Mbps

0.008 0.007 0.006 Jitter (s)

Jitter (s)

0.015 0.005 0.004

0.01 0.003 0.002

0.005

0.001 0

0 0

1000

2000

3000 4000 Loop length (m)

5000

6000

0

7000

Figure 49 Video traffic jitter for the 50% background traffic scenario

1000

2000

3000 4000 Loop length (m)

5000

6000

7000

Figure 50 Background traffic jitter for the 50% background traffic scenario

When looking to results depicted in Figure 50 and Figure 52, little variation has occurred when the traffic is 50% and 100%, being almost the same graph plotted for these two different scenarios. However, when the loop length is higher than 4000m a sudden leap arises in all scenarios. Thus, this leap may be different as the background traffic has some influence on the inclination degree of the curves. It must be noticed that the values referring to the amount of jitter are quite low, having a maximum of 0.021 seconds or 21 ms. 0.018

0.008

1.5Mbps 4.0Mbps 6.0Mbps 8.0Mbps 12.0Mbps 18.0Mbps

0.016 0.014

1.5Mbps 0.007

4.0Mbps 6.0Mbps

0.006

8.0Mbps 12.0Mbps

0.012

18.0Mbps

Jitter (s)

Jitter (s)

0.005 0.01 0.008

0.004 0.003

0.006 0.004

0.002

0.002

0.001

0

0 0

1000

2000

3000 4000 Loop length (m)

5000

6000

7000

Figure 51 Video traffic jitter for the 100% background traffic scenario

0

1000

2000

3000 4000 Loop length (m)

5000

6000

7000

Figure 52 Background traffic jitter for the 100% background traffic scenario

74

Losses are very important because they can severely impact the video quality for the end user. When analyzing the packet losses for different background traffic levels, they seemed to act in the same way, as all curves follow the same pattern, changing only the amount of packet loss depending on the quantity of background traffic. Figure 53 depicts the packet loss percentage related to the video traffic when 50% background traffic was used and Figure 54 shows the background traffic losses. Comparing Figure 53 and Figure 54, we can see that the graphs behavior is quite the same, though the amount of losses is different. 100

100 1.5Mbps 4.0Mbps 6.0Mbps 8.0Mbps 12.0Mbps 18.0Mbps

90 80 70

80 70 60 Loss (%)

60 Loss (%)

1.5Mbps 4.0Mbps 6.0Mbps 8.0Mbps 12.0Mbps 18.0Mbps

90

50

50

40

40

30

30

20

20

10

10 0

0 0

1000

2000

3000 4000 Loop length (m)

5000

6000

0

7000

Figure 53 Video traffic packet losses for the 50% background traffic scenario

1000

2000

3000 4000 Loop length (m)

5000

6000

7000

Figure 54 Background traffic packet losses for the 50% background traffic scenario

Figure 55 shows different videos packet loss when subjected to 100% background traffic and Figure 56 shows losses for the background traffic itself. Note that even the lowest bitrate video, which is the 1.5 Mbps, has about 5% of losses for the loop length of 0 meters. With these values, it is unacceptable that amount of background traffic in concurrence with the video traffic. 100

100 1.5Mbps 4.0Mbps 6.0Mbps 8.0Mbps 12.0Mbps 18.0Mbps

90 80 70

80 70 60 Loss (%)

60 Loss (%)

1.5Mbps 4.0Mbps 6.0Mbps 8.0Mbps 12.0Mbps 18.0Mbps

90

50

50

40

40

30

30

20

20

10

10

0

0 0

1000

2000

3000 4000 Loop length (m)

5000

6000

Figure 55 Video traffic packet losses for the 100% background traffic scenario

7000

0

1000

2000

3000 4000 Loop length (m)

5000

6000

7000

Figure 56 Background traffic packet losses for the 100% background traffic scenario

75

For the 50% background traffic, losses happened more often, making all the PSNR related to the videos lower than when no background traffic was used. The 1.5Mbps bitrate video again obtained the best results, because its bitrate does not occupy the available bandwidth, at least, at the first two thousand meters. After 2000 meters all videos have their PSNR decreased, implicating in losses of the video quality. Nevertheless, many losses occurred in this situation. As it would be expected, for the 100% background traffic, all videos have low PSNR values, indicating poor video quality. The major problem is that there is a lack of bandwidth since short loops as the background traffic is occupying the available bandwidth. 100

100 1.5Mbps 4.0Mbps 6.0Mbps 8.0Mbps 12.0Mbps 18.0Mbps

90 80

60

80 70 Y - PSNR

Y - PSNR

70

50

60 50

40

40

30

30

20

20

10

10

0

1.5Mbps 4.0Mbps 6.0Mbps 8.0Mbps 12.0Mbps 18.0Mbps

90

0 0

1000

2000

3000 4000 Loop length (m)

5000

6000

7000

Figure 57 PSNR values for the 50% background traffic scenario

0

1000

2000

3000 4000 Loop length (m)

5000

6000

7000

Figure 58 PSNR values for the 100% background traffic scenario

These results showed that background traffic can influence negatively the video traffic when there is no QoS mechanism being used to prioritize the video. In order to ensure a good video quality, QoS must be employed since 3P services should take into account that different sort of traffics will be transmitted together to the end user, thus some services are more important than other, e.g. video and voice are more important that ordinary traffic such as the internet data. In next sections, results where QoS mechanism is used will be presented and discussed.

4.6 Noise Modeling REIN stands for repetitive electrical impulse noise and is one of the most severe noise forms affecting xDSL systems [64]. It is a periodic noise, composed of small bursts of energy, and is typically found at the customer premise side of the ADSL line. Badly shielded household appliances, illumination devices and switching power supplies commonly used in PCs, mainly cause this type of noise. As it is seen in its name, REIN is a kind of impulse noise that repeats itself through the time.

76

A REIN signal x(t ) is composed of a periodic sequence of bursts as shown in Figure 59. The temporal spacing of the bursts is denoted by T and describes the periodicity of the noise signal. A burst x B (t ) itself consists of a sequence of N B base signals x S (t ) of length TR . The length of a burst is denoted by TB and clearly given by TB = N BTR . The REIN signal is offset in time by T0 .

Figure 59 REIN Signal Composition

The noise generation is driven by four essential parameters: the periodicity of the bursts, defined by a frequency f [Hz] which is f = 1 / T , the periodicity of the impulses inside each burst, defined by a frequency f R [kHz] which is f R = 1 / TR , the burst size N B , which represents the number of impulses inside a burst, and the power of the noise.

From now on, we are going to deal with the REIN profiles, characterized by their parameters, showed in Table 9. Table 9 REIN Noise Profiles.

NS-ID

f , [Hz]

f R , [kHz]

1A

1

250

1

1B

1

250

32

1C

1

250

64

2A

50

250

1

2B

50

250

32

2C

50

250

64

3A

100

250

1

3B

100

250

32

3C

100

250

64

N B , [1]

77

Each row in Table 9 lists the REIN parameter set for a noise configuration named by a noise shape identifier (NS-ID) consisting of two parts. The first part, a number between 1 and 3, denotes the burst periodicity (1 for 1 Hz, 2 for 50 Hz, and 3 for 100 Hz). The second part describes the burst length (A for 1 burst, B for 32 bursts and C for 64 bursts). Note that all noise shapes from 1A to 3C have f R = 250 kHz, which means the length of each impulse inside a burst is TR = 4 µs. For example, the noise profile 1A has burst frequency f = 1 Hz,

T = 1 s and N B = 1, thus this profile has one burst that consists of one impulse with a length of 4 µs at each second. The 1A noise profile is depicted in Figure 60.

Figure 60 1A Noise Profile Modeling

Differently from the 1A noise showed in Figure 60, Figure 61 shows the 1B noise, which as the same frequency f = 1 Hz but having a different number of impulses. The profile 1B has 32 impulses each with length 4 µs at each second.

Figure 61 1B Noise Profile Modeling

78

Now looking at the picture depicted in Figure 62, we can see the 2B noise which has the same number of impulses N B = 32, but now having f = 50 Hz instead of f = 1 Hz. Note that 0.02 s is calculated based on the 50 value in the Table 9 ( f = 1/50 = 0.02 s).

Figure 62 2B Noise Profile Modeling

As said previously, the forth parameter which describes the REIN is the power level. The most common amplitude range for REIN is between 5mV to 40mV [90]. Using equipment and cabling with impedance of 50Ω, this amplitude range becomes a -33.01dBm to -14.94dBm power range.

4.7 REIN Impact on Video Traffic Aiming at investigating the impact of different noise profiles on video traffic, some experiments were conducted. As previously explained, our videos had different bitrates and the loop length was modified for each step of the experiment. Now we are going to focus on SDTV videos coded in MPEG2 format, which are coded approximately in 4 Mbps bitrate. Moreover, we chose a fixed loop length of 2550 meters [101]. All this decision was made because time constraints since we had to investigate the impact of other parameters in this evaluation. We used different noise profiles with different powers to analyze their impact when the line had minimum protection. With this experiment we are able to understand how different noise profiles can degrade our video transmission. In Table 10 we show the chosen noise profiles. This decision was made because we want to see the noise frequency and the noise burst length impact on the video.

79

Table 10 REIN Noise Profiles.

NS-ID

f , [Hz]

f R , [kHz]

1A

1

250

1

1C

1

250

64

2A

50

250

1

2C

50

250

64

3A

100

250

1

3C

100

250

64

N B , [1]

In addition, for all these different noises we used different powers in our experiments. The chosen powers for this experiment were -33.01dBm, -23.46dBm, -19.03dBm, and 14.94dBm which have their power values respectively 5mV, 15 mV, 25 mV, and 40mV. Since we want the basic configuration of the line, we configured the line with a maximum acceptable interleaving delay of 1 ms, minimum INP value of 0. In addition to the noise power level value, we chose the target SNR margin value of 6 dB, and the maximum SNR margin of 6.6 dB and, that is, 10% above the target SNR. This configuration guarantees that the line rate will have no protection against the noises being used. Table 11 summarized all parameters used in this experiment. Table 11 Experiment Setup Parameters.

Parameter

Value(s)

Service Configuration

1 PVC, UBR with no QoS (fixed)

xDSL Standard

ADSL2+ with Annex M (fixed)

Video Source

Stored Video with bitrate – 4.0 Mbps (fixed)

Interleaving Delaymax

1 ms (fixed)

INPmin

0 (fixed)

Loop Length

2550 m (fixed)

Minimum SNR Margin

0 dB (fixed)

Target SNR Margin

6 dB (fixed)

Maximum SNR Margin

6.6 dB (fixed)

Noise Profiles

1A, 1C, 2A, 2C, 3A, and 3C

Noise Powers

-33.01dBm, -23.46dBm, -19.03dBm, and 14.94dBm 80

At the beginning of the experiments we noticed high variability in the collected data, which made some results quite unpredictable; hence we decided to make a number of replications for each experiment. When we gathered our results we found that 10 replications would be enough to make the results more reliable, despite the extreme outliers found in some of these experiments. Thus, all results showed in next sections were calculated based on the median of these replications since it is a more robust metric to evaluate this kind of scenarios. When investigating this variability we manage to analyze the dumps content and try to understand what was happening when the received video had 0 bytes size. We discovered that the noise was affecting some important packets that carry video crucial information such as compression format, video height and width, so the player was not able to store the transmitted video to a later further analysis. The downstream rate achieved when using these parameters were approximately 7.33Mbps and the synchronized INP value was 0, as we configured the line. The target SNR margin was also respected when looking to our results. Figure 63 depicts how packet loss behaves for noises with different frequencies. When the video was subjected to the 3A noise profile, losses started around 100% even when the noise power was the lower one. Moreover, the 3A noise profile made the video traffic have a 100% packet loss for all other noise powers. Similarly to the 3A noise profile, 2A presented the same behavior, although for the lower power value of -33.01dBm losses were lower, having the value of 0.34%. When looking to the 1A results, we can clearly see that for powers lower than -14.94dBm losses were around 0%, but the higher power value if -14.94dBm made losses raise to a 100% value. So, we can point how frequency can affect the video traffic and note that both noise frequency and noise power might have a crucial role when coupled to the transmission. Figure 64 shows how packet loss behaves for noises with different burst lengths. In this case we are comparing noise 1A and 1C. The graph shows that 1C noise makes losses start around 5% while losses in 1A start having values around 0.5%. When increasing the noise power, losses have a slight increase for both 1A and 1C noise, but for noise power -14.94dBm they both raises to a 100% packet loss. Comparing the Figure 63 and Figure 64 we realize that noises with greater frequencies are more harmful to the line than noises with greater burst lengths. This can be seen when comparing

81

losses from 2A and 1C noise profiles. This also occurs when comparing other noise profiles used in this experiment. 100.000

100,000 1A: SNR=6dB

90.000 80.000

1A: SNR=6dB 90,000

2A: SNR=6dB 3A: SNR=6dB

70,000 Loss (%)

70.000 Loss (%)

1C: SNR=6dB

80,000

60.000 50.000

60,000 50,000

40.000

40,000

30.000

30,000

20.000

20,000

10.000

10,000

0.000 -34

-29

-24 Pow er (dBm)

-19

0,000 -34

-14

Figure 63 Packet loss for noise profiles with different frequencies

-29

-24 Pow er (dBm)

-19

-14

Figure 64 Packet loss for noise profiles with different burst length

In respect of delay, for all noise profiles used it behaved in a same way, having values around 0.06s. Moreover, the same occurred with jitter, having values around 0.0013s. Now, looking at Figure 65 and Figure 66, we can see the PSNR values for different noise profiles. In the same way as Figure 63, Figure 65 depicts the PSNR values for noises with different frequency and same burst length. Moreover, Figure 66 shows PSNR values for noises with same frequency and different burst lengths. Note that PSNR is direct related to frames loss, so the more frame losses occur the lower the PSNR will be. 100

100 1A: SNR=6dB

90 80

1A: SNR=6dB 90

2A: SNR=6dB 3A: SNR=6dB

70 PSNR (dB)

PSNR(dB)

70 60 50

60 50

40

40

30

30

20

20

10

10

0 -34

1C: SNR=6dB

80

-29

-24 Pow er (dBm)

-19

-14

Figure 65 PSNR for noise profiles with different frequencies

0 -34

-29

-24 Pow er (dBm)

-19

-14

Figure 66 PSNR for noise profiles with different burst length

82

5 Video Streaming Optimization “Something as small as the flutter of a butterfly's wing can ultimately cause a typhoon halfway around the world.”

Chaos Theory

This chapter presents results obtained using the chosen parameters exposed in the previous section.

5.1 SNR margin effectiveness against REIN In this section we want to investigate how SNR margin acts in the line when REIN is present in the video transmission. In order to evaluate how effective the SNR margin is against different noise profiles we conducted this experiment varying only SNR margin parameter, noise profiles and different noise powers. Table 12 summarizes other parameters and the ones mentioned earlier. Table 12 Experiment Setup Parameters.

Parameter

Value(s)

Service Configuration

1 PVC, UBR with no QoS (fixed)

xDSL Standard

ADSL2+ with Annex M (fixed)

Video Source

Stored Video with bitrate – 4.0 Mbps (fixed)

Interleaving Delaymax

1 ms (fixed)

INPmin

0 (fixed)

Loop Length

2550 m (fixed)

Minimum SNR Margin

0 dB (fixed)

Target SNR Margin

6 dB, 10 dB, 14 dB and 18 dB

Maximum SNR Margin

10% above the current Target SNR

Noise Profiles

1A, 1C, 2A, 2C, 3A, and 3C

Noise Powers

-33.01dBm, -23.46dBm, -19.03dBm, and -14.94dBm 83

As being said previously, the achieved synchronized rate is very important when investigating any ADSL performance. In earlier sections we introduced the SNR margin and its collateral effects when increased. The protection that SNR margin gives does not come without a cost. Table 13 shows how SNR margin decreases the synchronized rate when its value is increased. Table 13 Achieved downstream rate for different SNR margin values

SNR Margin

Rate

6 dB

7.33 Mbps

10 dB

6.12 Mbps

14 dB

5.10 Mbps

18 dB

4.05 Mbps

Figure 67 shows packet losses when different SNR values are used to configure the line and 1A noise profile is used. As it can be seen, the higher the SNR margin is the lower packet losses will occur. However, when SNR of 18 dB is used losses are even higher then 6 dB SNR scenario. This phenomenon happens due to the lack of bandwidth to transmit the video content, since the achieved downstream rate for SNR of 18 dB is 4.05 Mbps. When looking at Figure 68, the same trend has occurred. For instance, only the 14 dB SNR made a substantial contribution for the packet losses when comparing the amount of packet losses of SNR 6dB and SNR 10 dB which increase to around 100% since the -23.46dBm noise power value. Again, the 18 dB SNR value has packet losses since the lower noise power value of 33.01dBm.

100.000

100.000 1A: SNR=6dB

90.000 80.000

2A: SNR=6dB 90.000

1A: SNR=10dB 1A: SNR=14dB

80.000

1A: SNR=18dB 70.000 Loss (%)

Loss (%)

70.000 60.000 50.000

40.000 30.000

20.000

20.000

10.000

10.000

-24 Pow er (dBm)

-19

-14

Figure 67 Packet loss for 1A noise profile and different SNR margin configuration

2A: SNR=18dB

50.000

30.000

-29

2A: SNR=14dB

60.000

40.000

0.000 -34

2A: SNR=10dB

0.000 -34

-29

-24 Pow er (dBm)

-19

-14

Figure 68 Packet loss for 2A noise profile and different SNR margin configuration

84

100

100 1A: SNR=6dB

90

2A: SNR=6dB

90

70

2A: SNR=10dB

1A: SNR=14dB

80

2A: SNR=14dB

1A: SNR=18dB

70

2A: SNR=18dB

PSNR(dB)

PSNR(dB)

1A: SNR=10dB 80

60 50

60 50

40

40

30

30

20

20

10

10

0 -34

-29

-24 Pow er (dBm)

-19

-14

Figure 69 Video PSNR for 1A noise profile and different SNR margin configuration

0 -34

-29

-24 Pow er (dBm)

-19

-14

Figure 70 Video PSNR for 2A noise profile and different SNR margin configuration

In our results we noticed that for the 2C and 3C noise profiles SNR margin did not reduce losses, making losses around 100% for all SNR margin configurations as the results show when SNR margin was 6 dB. We conclude that for more aggressive noises SNR is not so effective and other approaches have to be considered such as interleaving delay and INP.

5.2 Interleaving Delay effectiveness against REIN In this section we are going to present the impact of interleaving delay when streaming video content through the ADSL network. In this experiment, for different INP values and noise profiles we varied our maximum acceptable delay. For this experiment we decided to utilize one noise power only. The decision was made based on the results obtained from the SNR margin experiment. The noise power we chose was 23.46dBm which represents 15 mV. In addition, we chose to use a target SNR margin of 6 dB. All these parameters had to be chosen because each experiment takes a long time to finish their execution. Hence, the noise profiles were also reduced.

Note that for all results presented in

this section there is no dots representing the 8 ms interleaving delay configuration. This occurred due to the fact that the modem and the DSLAM were not able to synchronize the line with this configuration. Perhaps this is a limitation of the equipment that requires more delay in order to utilize the minimum INP value imposed by us.

85

Table 14 summarizes all parameters used in this experiment. Note that for all results presented in this section there is no dots representing the 8 ms interleaving delay configuration. This occurred due to the fact that the modem and the DSLAM were not able to synchronize the line with this configuration. Perhaps this is a limitation of the equipment that requires more delay in order to utilize the minimum INP value imposed by us.

86

Table 14 Experiment Setup Parameters.

Parameter

Value(s)

Service Configuration

1 PVC, UBR with no QoS (fixed)

xDSL Standard

ADSL2+ with Annex M (fixed)

Video Source

Stored Video with bitrate – 4.0 Mbps (fixed)

Interleaving Delaymax

8 ms, 16 ms, 32 ms, 64 ms, 128 ms

INPmin

1, 2, 4, 8 and 16 DMT Symbols

Loop Length

2550 m (fixed)

Minimum SNR Margin

0 dB (fixed)

Target SNR Margin

6 dB (fixed)

Maximum SNR Margin

10% above the current Target SNR

Noise Profiles

1A, 1C, 2A and 2C

Noise Powers

-23.46dBm (fixed)

Figure 82 shows the average packet delay calculated for different INP values. It is important to emphasize that the maximum delay imposed at the beginning of the experiment was always respected no matter the minimum INP value we configured. Although the maximum SNR margin was not respected, the obtained value was really close to the one requested on synchronization phase. Packet delay for the 2A noise profile can be seen in Figure 72. If we compare the packet delay from Figure 71 to Figure 72, we realize that there is a little difference between them. So,

0.030

0.030

0.025

0.025

0.020

0.020 Delay (s)

Delay (s)

independently from the noise being present in the transmission, delay trends to be almost the same.

0.015

0.015 2A: INP=1 2A: INP=2

1A: INP=1

0.010

0.010

2A: INP=4

1A: INP=2

2A: INP=8

1A: INP=4 0.005

2A: INP=16

0.005

1A: INP=8 1A: INP=16

0.000

0.000 16

32

48

64

80

96

112

Delay (ms)

Figure 71 Average packet delay for Noise 1A

128

16

32

48

64

80

96

112

128

Delay (ms)

Figure 72 Average packet delay for Noise 2A.

87

Another interesting fact is that for all maximum delays varying in this experiment, the configured delay kept its value around 16 ms. The configured delay in this case is the value negotiated between the user modem and the DSLAM. This explains why packet delay had its value around 20 ms. Knowing that 16 ms was the delay added by the interleaving process, the other 4 ms delay is resultant of other factors during transmission, such as medium propagation, sending queue, among others. Moreover, when maximum delay was set to 16 and minimum INP to 16, the line did not synchronize and values became 0. This might be a restriction of the equipment’s algorithm. When making other experiments to investigate this phenomenon, we noticed that the delay is always respected and SNR margin trends to be kept approximated to the target SNR margin. The only case where delay has increased above 16 ms was when we tried very high target SNR margin values, e.g. from 180 dB to 280 dB, but the maximum acceptable delay still being respected. This relationship between SNR and Interleaving delay becomes more obvious as we are investigating their behavior and influence in each other. In the next section we are going to investigate INP behavior and try to find out if there is any relationship between these parameters mentioned so far.

5.3 INP effectiveness against REIN In this section we are going to analyze INP influence over video traffic when subjected to different sort of noises. This experiment took all parameters used in the Interleaving delay experiment discussed previously. When using INP we expect that the total available bandwidth decreases since redundant information is sent. In addition, in a noisy scenario these redundant bytes would be able to correct the damaged block so that information could be recovered and interpreted. Figure 73 depicts how packet losses occur when different INP and Interleaving delay are used. It shows the results obtained when 1A noise profile were introduced. As it can be seen, interleaving delay of 32 ms provides good protection for all values of INP used in the experiment. In Figure 74 the same occurs for the noise profile 2A.

88

120.00000

120.00000 1A: INP=1

2A: INP=1

1A: INP=2 100.00000

2A: INP=2

100.00000

1A: INP=4

2A: INP=4

1A: INP=8 80.00000 Loss (%)

Loss (%)

2A: INP=8

1A: INP=16

80.00000

60.00000

60.00000

40.00000

40.00000

20.00000

20.00000

0.00000

2A: INP=16

0.00000 16

32

48

64 80 Delay (ms)

96

112

128

Figure 73 Packet Loss for Noise 1A and different INP values

16

32

48

64 80 Delay (ms)

96

112

128

Figure 74 Packet Loss for Noise 2A and different INP values

When analyzing the results we discovered that the same behavior happened to the 1A, 1C and 2A noise profile, but when 2C noise profile was used we noticed that not even a minimum INP value of 16 DMT symbols would prevent a 100% packet loss for this experiment. Thus, we managed to look at the negotiated INP value between the modem and the DSLAM and realized that the configured INP value was always 2. Differently from the target SNR margin, which is always respected in the negotiation phase, the minimum INP value is not respected. After taking some new experiments we observed that in order to increase the INP value, we should utilize higher values of target SNR margin, so that INP would increase to higher values. The same occurs for the maximum delay. If we set higher SNR margin values, the equipment trends to reach higher configured delay values, however, this maximum acceptable delay is still being respected. It is important to emphasize that the higher the SNR margin is the lower the downstream rate will be, so if we are required to have a great line protection our downstream rate will decrease as showed in previously sections. Figure 75 depicts this behavior. When the minimum INP value configured is greater or equal to 2 the rate is the same for all these values.

89

24 INP=0

20

INP=1 INP=2

16

INP=4 INP=8

12

INP=16

8 4

0 50 0 10 00 15 00 20 00 25 00 30 00 35 00 40 00 45 00 50 00 55 00 60 00 65 00 70 00

0

Figure 75 INP impact on the downstream rate

Knowing that the configured INP does not respect the required INP value, we find ourselves trying to find an efficient manner to choose a more intuitive way to protect line from impairments such as REIN.

5.4 Analyzing video traffic with concurrent traffic with QoS In an earlier section we presented what problems would appear when video traffic was transmitted in a concurrent way with different levels of background traffic. The major problem of the earlier experiment was that none of the traffic had any prioritization scheme over each other. In this section we are going to present experiments results which had the goal of determining the behavior of the video stream traffic when a concurrent UDP traffic is being transmitted under different line configurations (loop length) and 2 PVC configuration (UBR – VBR). Here we will be presenting what happens to both traffics when a QoS mechanism is being used to prioritize the video traffic. The main experiment script runs under Matlab and controls the loop length, minimum INP (0), ATM service category, UBR for the background traffic and CBR for the video traffic, and calls the traffic generation script in the Linux machines. The script designed for this experiment generates a UDP background traffic with 20 sources following a Pareto distribution with shape 1.3 and scale varying accordingly to the amount of background traffic we want to generate. After that, we stream all the videos one by one. When all this process is finished we have available all the metrics for the background traffic and the traffic related to the videos saved. Once the experiments are finished, we run the program that we designed 90

passing the client and server dumps as parameters in order to calculate and generate all the metrics that we need. Table 15 summarizes all parameters used in this specific experiment. For both traffics the throughput, jitter, and delay, among others will be analyzed. Table 15 Experiment Setup Parameters.

Parameter

Value(s)

Service Configuration

2 PVC, UBR and CBR (fixed)

xDSL Standard

ADSL2+ with Annex M (fixed)

Transport Protocol for

UDP

the Background Traffic Video Source

Stored Video with bitrates – 1.5 Mbps, 4.0 Mbps, 6 Mbps, 8 Mbps, 12 Mbps and 18 Mbps (GOP 12)

Interleaving Delaymax

32 ms (fixed)

Background Traffic

50% of available bandwidth (fixed)

INPmin

0 (fixed)

Loop Length

50 to 7000, 250m step

Minimum SNR Margin

0 db (fixed)

Target SNR Margin

6 db (fixed)

Maximum SNR Margin

31 db (fixed)

Analyzing the achieved rate depicted in Figure 76 and Figure 77, we can clearly notice that the QoS mechanism has prioritized the video traffic when comparing to the background traffic. Moreover, the video rate has acted in the same manner as showed in Figure 36 where there was no background sharing the transmission channel. If we compare Figure 76 and Figure 77 to Figure 41 and Figure 42, we are able to see that the video traffic has obtained better rates than when QoS mechanism was not used and the background traffic was compromised a little bit, loosing about 2 Mbps for each transmitted video.

91

24

24 Syncrate 1.5Mbps 4.0Mbps 6.0Mbps 8.0Mbps 12.0Mbps 18.0Mbps

22 20 18

20 18 16 Rate (Mbps)

Rate (Mbps)

16 14 12 10

Syncrate 1.5Mbps 4.0Mbps 6.0Mbps 8.0Mbps 12.0Mbps 18.0Mbps

22

14 12 10

8

8

6

6

4

4

2

2

0

0 0

1000

2000

3000 4000 Loop length (m)

5000

6000

7000

0

Figure 76 Received video rate at the multimedia client for the 50% background traffic

1000

2000

3000 4000 Loop length (m)

5000

6000

7000

Figure 77 Received background traffic rate at the multimedia client for the 50% background traffic

As we have presented in previous section and showed in Figure 37, video traffic delay had a strange behavior when there was no background traffic presented during transmission. Yet, in Figure 45 and Figure 47 where background traffic was present, video traffic delay had normal values, not going greater than 0.14 seconds. Now when looking for both video and background traffic delay, depicted in Figure 78 and Figure 79 respectively, video traffic delay behaved strangely again, having values up to 1 second while the background traffic has not suffered such strange phenomenon. The only observed fact is that delay would be related to losses, since when there is a leap in some video losses the delay has this suddenly increase. This problem is not observed in the background traffic and in the video traffic when no QoS is applied because the loss curves seem to increase gradually. 1

0,1

1.5Mbps 4.0Mbps 6.0Mbps 8.0Mbps 12.0Mbps 18.0Mbps

0,9 0,8 0,7

0,08 0,07 0,06 Delay (s)

0,6 Delay (s)

1.5Mbps 4.0Mbps 6.0Mbps 8.0Mbps 12.0Mbps 18.0Mbps

0,09

0,5

0,05

0,4

0,04

0,3

0,03

0,2

0,02

0,1

0,01 0

0 0

1000

2000

3000 4000 Loop length (m)

5000

6000

7000

Figure 78 Video traffic delay at the multimedia client for the 50% background traffic

0

1000

2000

3000 4000 Loop length (m)

5000

6000

7000

Figure 79 Background traffic delay at the multimedia client for the 50% background traffic

As for other experiments, jitter was not influenced and kept low values even for the video traffic. Figure 80 depicts how the video traffic jitter acted when increasing the loop length. Figure 81 shows jitter values for the background traffic. Although video traffic jitter does not represent high 92

values, the same leap behavior has appeared when losses started to appear for all video bitrates. Note that for the background traffic jitter, the values started in 0.035 s, increasing up to 0.075. However, video background traffic started in almost 0.01 s, but when losses began to occur these values increased to about 0.014 s. 0,009

0,016 1.5Mbps 4.0Mbps 6.0Mbps 8.0Mbps 12.0Mbps 18.0Mbps

0,014 0,012

1.5Mbps 4.0Mbps 6.0Mbps 8.0Mbps 12.0Mbps 18.0Mbps

0,008 0,007 0,006 Jitter (s)

Jitter (s)

0,01 0,008

0,005 0,004

0,006 0,003 0,004

0,002

0,002

0,001

0

0 0

1000

2000

3000 4000 Loop length (m)

5000

6000

7000

Figure 80 Video traffic jitter at the multimedia client for the 50% background traffic

0

1000

2000

3000 4000 Loop length (m)

5000

6000

7000

Figure 81 Background traffic jitter at the multimedia client for the 50% background traffic

As said previously, the QoS mechanism has showed itself useful and trustful. Results have shown that if there is any concurrent traffic when any kind of traffic is prioritized, the non prioritized traffic will have discards and the prioritized traffic will prevail, using the available bandwidth. This can be seen when looking to Figure 82 and Figure 83, where background traffic start with losses while video traffic will have their first losses only when there is no available bandwidth. In addition, if we compare Figure 39 to Figure 82 we can notice that they have almost no difference in theirs curves. As we have discussed previously, packet loss are direct related to the PSNR. So, PSNR values for this experiment where QoS has being applied, is the same as depicted in Figure 40 where there was no background traffic being transmitted.

93

100

100 1.5Mbps 4.0Mbps 6.0Mbps 8.0Mbps 12.0Mbps 18.0Mbps

90 80 70

80 70 60 Loss (%)

60 Loss (%)

1.5Mbps 4.0Mbps 6.0Mbps 8.0Mbps 12.0Mbps 18.0Mbps

90

50

50

40

40

30

30

20

20

10

10

0

0 0

1000

2000

3000 4000 Loop length (m)

5000

6000

7000

Figure 82 Received video rate at the multimedia client for the 50% background traffic

0

1000

2000

3000 4000 Loop length (m)

5000

6000

7000

Figure 83 Received background traffic rate at the multimedia client for the 50% background traffic

Taking into consideration results showed in this section, we are able to state that QoS mechanism can be really desired when video content is being delivered to a customer that has some kind of different traffic, which relies in some protocols that has congestion control mechanisms and retransmission techniques, such as TCP does.

5.5 Advisable ADSL Line Configuration Analyzing the obtained results we were able to obtain some insights of how the equipments implement their noise protection techniques and which parameters influence this protection. The first parameter analyzed was the SNR margin. We noticed that higher SNR margin values give line protection, but decreases line rate and introduce cross talk. So it is advised to utilize this parameter with caution, in our experiment where the loop length was around 2500 meter, which is a distance not so near from the CO, we observed that a 180 dB SNR margin decreases our rate so much that it becomes impracticable to stream a SDTV channel to the user home. A value between 10 dB and 14 dB would be enough to give some protection and to ensure enough bandwidth for receiving the video content. Thus, it is advisable to utilize a SNR margin of 10 dB or 12 dB when configuring an ADSL line prepared to receive a SDTV channel. The second parameter analyzed was the Interleaving delay. Looking at the results we realized that the configured Interleaving delay was around 16 ms, even when we let the maximum interleaving delay be of 128 ms. Taking that into consideration we would configure the line with maximum interleaving delay of 16 ms, but we discovered that when 94

INP was equal to 16 and the maximum interleaving delay was also 16, the line was not able to synchronize. Therefore, it is advisable that we utilize the interleaving delay of 32 because this reason and due to the fact that when we raise our target SNR margin value the interleaving delay has a tendency of being greater also. The third parameter analyzed was the INP. INP did not work as we expected, because this parameter would be the most important when configuring a desirable line protection. On the other hand, the target SNR margin plays a more important role than INP in our experiments. Dictating the Interleaving delay and INP behavior when set. The equipment seems to prioritize SNR margin better than interleaving delay and INP. This can be seen clearly due to the fact that minimum INP is never respected when SNR margin is fixed or when having low values. From the observed results, the configured INP value was always 2 DMT symbols, but the only noise that this would not be sufficient was the 2C. Hence, we would advise that the configured INP of 2 or should be used in order to mitigate problems related to noisy. So, a configured INP of 2 for less aggressive noises scenarios should be used and an INP of 4 for more aggressive noises scenarios. At last, the fourth parameter investigated was the QoS mechanism implementation of the equipments. Results showed that the QoS mechanism worked really fine, leaving packet losses to the background traffic whenever buffers were full. The prioritization mechanism brought real improvements for the video traffic when comparing to the results when no prioritization was used for both of the traffic. Therefore, when video traffic is being delivered in any conditions, QoS mechanism should always be used. Gathering all results and the whole analysis made, we advised an ADSL line configuration that would bring enhancements to the video transmission. It is important to emphasize that each device implements its own algorithm, so this evaluation sometimes can be considered just for a set of equipments. For instance, perhaps some other device would respect the minimum INP value and would not respect the imposed SNR margin.

95

6 Conclusions and Future Work “After some time you learn to accept your defeats ahead with the erect head and eyes, with an adult's grace and not with a child's sadness.” William Shakespeare

This work presented results in many different scenarios using the DSL technology. Each of these results were analyzed and investigated with the goal of obtaining insights and specific knowledge to make possible to advise a DSL line configuration which would benefit video content transmission. In addition, impairments that might appear during transmission were considered and their impact on the video streaming process was studied. Aiming at analyzing all the conducted experiments some supporting tools had to be implemented to a better understanding of all related metrics related to different layers of the DSL technology. These metrics go from physical layer, such as SNR margin and INP metrics to application metrics such as PSNR. All the experiments required a testbed setup using different softwares for the evaluation scenario. We also described what methodology was used and the meaning of each metric analyzed. We noticed that parameters such as INP, SNR Margin and Interleaving delay play an important role when configuring an ADSL line and that if they are not adjusted carefully they can bring problems in a video transmission. In addition, QoS mechanism was tested and analyzed. So we concluded that traffic isolation using a 2 PVC configuration would improve important traffic, such as video traffic and put less important traffic aside, such as data traffic. From our results we found that SDTV can be delivered when there is a considerable distance from the CO and CPE and when the line is subjected to some kind of impairments. With better noise protection techniques and shorter distances from the CO and CPE we might be able to stream a HDTV or a couple of SDTV channels to the customer.

96

6.1 Contributions This work presented analysis and investigations of video transmission under an ADSL architecture. The main contributions of this work can be resumed as follows: •

Comparison of 3 sorts of DSL standards, ADSL, ADSL2 and ADSL2+. The results showed metrics related to this technology and how these metrics act when different distances from the CO and CPE are imposed. Moreover, it showed that these metrics are negotiated upon line synchronization between the user Modem and the DSLAM, so there was no need to send any kind of traffic from one side to the other.

•

Investigation of how videos with different bitrates would behave for different distances from the CO and CPE. This investigation was made using different layers metrics.

•

Concurrent background traffic impact on video traffic for scenarios. These scenarios include where no QoS was used and where QoS was used.

•

Impact of different noises on video traffic when there was no line protection during transmission.

•

Evaluation of the impact of metrics such as INP, Interleaving Delay and SNR margin in the video when noises are present during transmission.

•

Implementation of a modified PSNR algorithm that takes into account video where entire frames losses occurred during transmission.

•

Proposal of an ADSL line configuration that would bring enhancements to the video transmission process, resulting in a better video quality when this video reaches the customer home.

6.2 Future Work As a future work, a sort of cross layer architecture could be investigated, where upper layers could give some kind of feedback to lower layers so that these parameters could be adjusted in a real time in order to provide a better video quality.

97

Another interesting approach is considering a further analysis of the video quality, but at this time adjusting parameters related to the video itself, such as GOP length, coding parameters, video size, among others. As presented in [23] a FEC scheme could also be used regarding the video content. Thus, there would be another kind of protection in this upper layer combining with the protection in lower layers as presented in this work. This application FEC could be dynamic, that means, since video I frames are more important to the video, more FEC bytes would be used in their transmission. Another kind of investigation could be done using a different codec, such as MPEG-4 part 2 or MPEG-4/AVC. This investigation could be done by studying only these codecs parameters or making a comparison between different coding algorithms. This comparison could be, for example, a further investigation of packet loss impact on different codecs being used during transmission.

98

7 References [1] [2]

[3] [4] [5] [6] [7] [8]

[9] [10] [11] [12] [13]

[14] [15] [16] [17] [18] [19] [20]

ALLIED TELESYN. Architectures for Video over ADSL: IP and ATM. Allied Telesyn Inc. Whitepaper. 2003. ASANO, T., TSUNO, A., NISHIZONO, T. Quality Measuring System for Network Provisioning and Customer Service in Content Delivery. Network Operations and Management Symposium. April, 2004. ATSC – Advanced Television Systems Committee. Available at http://www.atsc.org/. BETHLEHEM, D. Implementing TV over IP on DSL and Fiber Networks. Optibase Video Innovations White Paper. BINGHAM, J. ADSL, VDSL, and Multicarrier Modulation. John Wiley & Sons, 2000. BOYCE, J., GAGLIANELLO, R. Packet Loss Effects on MPEG Video Sent Over The Public Internet. ACM Multimedia, Bristol, UK, 1998. CLAYPOOL, M., LIU, Y. Using Redundancy to Repair Video Damaged by Network Data Loss. ACM/SPIE Multimedia Computing and Networking (MMCN). January, 2000. CLAYPOOL, M., ZHU, Y. Using Interleaving to Ameliorate the Effects of Packet Loss in a Video Stream. Proceedings of the International Workshop on Multimedia Network Systems and Applications (MNSA). May, 2003. DiBEG - Digital Broadcasting Experts Group. Available at http://www.dibeg.org/ D-ITG Tool – Distributed Internet Traffic Generator. Available at http://www.grid. unina.it/software/ ITG/ DSL Forum Technical Report 12 - TR 126. December, 2006. DVB – Digital Video Broadcasting Project. Available at http://www.dvb.org/. Electronic Communications Committee (ECC) within the European Conference of Postal and Telecommunications Administrations (CEPT) High Capacity DSL-Systems. Report number 79. March, 2006. ENRICO, M., BILLINGTON, N., KELLY, J., and YOUNG, G. Delivery of IP over Broadband Access Technologies. BT Technology Journal, v. 18, n. 3. July, 2000. ERICSSON PRESS. Triple Play – Innovative Service Bundling for Profitable Broadband Business. Press information. February 2006. FEAMSTER, N., BALAKRISHNAN, H. Packet Loss Recovery for Streaming Video. 12th International Packet Video Workshop, Pittsburgh, 2002. FITZEK, F., SEELING, P., REISSLEIN, M. VideoMeter Tool for YUV bitstreams. Technical Report acticom-02-001. Germany, October, 2002. FROSSARD, P. FEC Performance in Multimedia Streaming. IEEE Communications Letters, vol. 5, no. 3. March, 2001. FROSSARD, P. MPEG-2 over Lossy Packet Networks QoS Analysis and Improvement. Swiss Federal Institute of Technology Lausanne. July, 1998. FROSSARD, P., VERSCHEURE, O. Adaptive MPEG-2 Information Structuring. SPIE vol.3528, pp.113-123, Boston, November 1998.

99

[21] FROSSARD, P., VERSCHEURE, O. Content-Based MPEG-2 Structuring and Protection. Proceedings of the SPIE, vol. 3845, Photonics East Symposium, Boston, September 1999. [22] FROSSARD, P., VERSCHEURE, O. Joint Impact of MPEG-2 Video Encoding Rate and ATM Cell Losses on Video Quality. In GLOBECOM, November, 1998. [23] FROSSARD, P., VERSCHEURE, O. Joint Source/FEC Rate Selection for QualityOptimal MPEG-2 Video Delivery. IEEE Transactions on Image Processing, 2001. [24] GREEN, R., WOOLEY, S., GARNHAM, N., JONES, K. Experimental Testbed Results for Broadband Residential Video Service QoS Management. IEEE International Conference on Communication (ICC), 2002. [25] GREEN, R., WOOLEY, S., GARNHAM, N., JONES, K. Quality-of-Service Management for Broadband Residential Video Services. Electronics & Communication Engineering Journal. December, 2001. [26] GREGGAINS, D. ADSL and High Bandwidth over Copper Lines. International Journal of Network Management, vol. 7, 277–287. John Wiley & Sons, 1997. [27] GRINGERI, S., KHASNABISH, B., LEWIS, A., SHUAIB, L., EGOROV, R., BASCH, B. Transmission of MPEG-2 Video Streams over ATM. IEEE Multimedia, vol. 05, no. 1, pp. 58-71, 1998. [28] HILLESTAD, O., LIBAK, B., PERKINS, A. Performance Evaluation of Multimedia Services over IP Networks. IEEE International Conference on Multimedia & Expo (ICME), July, 2005. [29] HO, C., TSAI, C. Content-Adaptive Packetization and Streaming of Wavelet Video over IPNetworks. EURASIP Journal on Image and Video Processing, January, 2007. [30] HO, C., TSAI, C. Content-Adaptive Packetization and Streaming of Wavelet Video over IP Networks. EURASIP Journal on Image and Video Processing, 2007. [31] HONG, G., FONG, B., FONG, A. QoS Control for Internet Delivery of Video Data. International Conference on Information Technology: Coding and Computing (ITCC), 2002. http://compression.ru/video/quality_measure/perceptual_video_quality_ tool_en.html [32] ISNARDI, M. MPEG-2 Systems. Sarnoff Corporation. August, 1999. [33] ISO/IEC 11172-2 MPEG-1 Video Coding Standard, ISO/IEC 11172-2, Information Technology - Coding of Moving Pictures and Associated Audio for Digital Storage Media at up to about 1.5 Mbits/s - Part2: Video. ISO, 1993. [34] ISO/IEC 13818-2 MPEG-2 Video Coding Standard, ISO/IEC 13818-2, Generic Coding of Moving Pictures and Associated Audio Information - Part2: Video. ISO, 1995. [35] ITU – Methodology for the Subjective Assessment of the Quality of Television Pictures. ITU-R Recommendation BT.500-10, 2000. [36] ITU-500-R Methodology for the Subjective Assessment of the Quality of Television Pictures. ITU-R Recommendation BT.500-10, 2000. [37] ITU-T G992.1 Asymmetric Digital Subscriber Line (ADSL) Transceivers. July 1999. [38] ITU-T G992.3 Asymmetric Digital Subscriber Line Transceiver 2 (ADSL2). January 2002. [39] ITU-T G992.5 Amendment 1, ADSL2+. July, 2005.

100

[40] ITU-T G992.5 Asymmetric Digital Subscriber Line Transceiver (ADSL) – Extended Bandwidth ADSL2 (ADSL2+). January 2005. [41] ITU-T G996.1 Test procedures for Digital Subscriber Line (DSL) Transceivers. March, 1999. [42] ITU-T, CCIR Recommendation H.261: Codec for audiovisual services at px64kbits/sec. 1990. [43] ITU-T, Draft ITU-T Recommendation H.263 Version 2: Video Coding for Low Bitrate Communication. September, 1997. [44] JURCA, D., FROSSARD, P. Optimal FEC Rate for Media Streaming in Active Networks. IEEE International Conference on Multimedia & Expo (ICME), June, 2004. [45] KANG, S., LOGUINOV, D. Impact of FEC Overhead on Scalable Video Streaming. 15th International Workshop on Network and Operating Systems Support for Digital Audio and Video (NOSSDAV), Skamania, Washington. June, 2005. [46] KLAUE, J., RATHKE, B., WOLISZ, A. EvalVid - A Framework for Video Transmission and Quality Evaluation. 13th International Conference on Modelling Techniques and Tools for Computer Performance Evaluation, pp. 255-272. Urbana, Illinois. September, 2003. [47] KOZAMERNIK, F., STEINMANN, V., SUNNA, P., WYCKENS, E., SAMVIQ: A New EBU Methodology for Video Quality Evaluations in Multimedia. SMPTE Motion Imaging Journal, April 2005, pp. 152-160. [48] LAI, M., KUO, C., SUNG, L. An Adaptation Scheme for Real-Time Video Streaming. IEEE International Symposium, Circuits and Systems, May, 2002. [49] LAMBRECHT, C., VERSCHEURE, O. Perceptual Quality Measure using a SpatioTemporal Model of the Human Visual System. SPIE Proceedings Vol. 2668, p. 450-461, March, 1996. [50] LI, N. Mesh Network Testbed and Video Stream Measurement. Course project report, CS 91.564, December 2006. [51] LO, A., HEIJENK, G., NIEMEGEERS, I. Performance Evaluation of MPEG-4 Video Streaming over UMTS Networks Using an Integrated Tool Environment. 12th International Packet Video Workshop, Pittsburgh, 2002. [52] LUO, H., SHYU, M., CHEN, S. An End-To-End Video Transmission Framework with Efficient Bandwidth Utilization. IEEE International Conference on Multimedia & Expo (ICME), June, 2004. [53] Matlab – The Language of Technical Computing. Available at http://www.mathworks.com/ [54] MEI, Y., LYNCH, W., NGOC, T. Joint Forward Error Correction and Error Concealment for Compressed Video. ITCC: Proceedings of the International Conference on Information Technology: Coding and Computing. Washington, 2002. [55] MEIJER, R. A Research Vehicle for Networked Video Streaming. Master Thesis. Eindhoven, March, 2004. [56] MERVANA, S., LE, C. Design and Implementation of DSL based Access Solutions. 1st Edition, Cisco Press, 2001. [57] MING-YI, L., CHIN-HWA, K., LI-CHUN, S. An adaptation scheme for real-time video streaming. IEEE International Symposium, Circuits and Systems. May, 2002. [58] MIRAS, D. A Survey of Network QoS Needs of Advanced Internet Applications. November, 2002.

101

[59] MOHAMED, S. Automatic Evaluation of Real Time Multimedia Quality a Neural Network Approach. Institut de Formation Supérieur en Informatique et Communication (IFSIC), Devant L'Université De Rennes I. January, 2003. [60] MPEG Official Website. http://www.chiariglione.org/mpeg/index.htm. Last access on April, 2007. [61] MPEG-2 Tutorial. MPEG 2: The Basics of How It Works. Hewlett Packard, Date Unknown. [62] MSU Perceptual Video Quality tool [63] MULLIN, J., JACKSON, M., ANDERSON, A., SMALLWOOD, L., SASSE, M., WATSON, A., WILSON, G. Assessment methods for assessing audio and video quality in real-time interactive communications. February, 2002. [64] NEDEV, N. Analysis of the Impact of Impulse Noise Digital Subscriber Line Systems. The University of Edinburgh, March, 2003. [65] NJ, J., LEUNG, K., HUI, C. A QoS-Enabled Transmission Scheme for MPEG Video Streaming. Real-Time Systems. July, 2005. [66] NS-2 Network Simulator (ver.2.) LBL, URL: http://www.mash.cs.berkley.edu/ns/. [67] PARADYNE. The DSL Sourcebook. Version 3.1, Paradyne Corporation, 2000. [68] PINSON, M., WOLF, S. A New Standardized Method for Objectively Measuring Video Quality. IEEE Transactions on Broadcasting, Vol. 50, No. 3, pp. 312-322, Sept. 2004. [69] QUAGLIA, D., MARTIN, J. Delivery of MPEG Video Streams with Constant Perceptual Quality of Service. IEEE International Conference on Multimedia & Expo (ICME), 2002. [70] RIVERSTONE NETWORKS. The Promise of the Triple-Play. Whitepaper. 2004. [71] RUI, H., LI, C., QIU, C. Evaluation of Packet Loss Impairment on Streaming Video. 15th International Packet Video Workshop, Hangzhou, China. April, 2006. [72] STARR, T., CIOFFI, J., SILVERMAN, P., Understanding Digital Subscriber Line Technology. Prentice Hall, NJ, 1999. [73] TANENBAUM, A. Computer Networks. 4th Edition, Prentice-Hall International Inc, 2002. [74] TAO, S., APOSTOLOPOULOS, J., GUÉRIN, R. RealTime Monitoring of Video Quality in IP Networks. 15th International Workshop on Network and Operating Systems Support for Digital Audio and Video (NOSSDAV), Skamania, Washington. June, 2005. [75] TCPDump Tool – Available at http://www.tcpdump.org/ [76] The ATM Forum Technical Committee. Audiovisual Multimedia Services: Video on Demand Specification 1.1. Technical Report af-saa-0049.001, ATM Forum. March, 1997. [77] The Institute for Telecommunication Science (ITS) - Video Quality Research URL: http://www.its.bldrdoc.gov/n3/video/index.php [78] The libpcap Project – Available at http://sourceforge.net/projects/libpcap/ [79] TRYFONAS, C. MPEG-2 Transport over ATM Networks. Master of Science degree in Computer Engineering. University of Santa Cruz, California. September, 1997. [80] VASEGHI, S. Advanced Signal Processing and Noise Reduction. 3rd Edition, Jon Wiley and Sons, 2006.

102

[81] VASSILIOU, V., ANTONIOU, P., GIANNAKOU, I., PITSILLIDES, A. Requirements for the Transmission of Streaming Video in Mobile Wireless Networks. International Conference on Artificial Neural Networks (ICANN), Athens, September, 2006. [82] VERSCHEURE, O., FROSSARD, P., HAMDI, M. MPEG-2 Video Services over Packet Networks: Joint Effect of Encoding Rate and Data Loss on User-Oriented QoS. 8th International Workshop on Network and Operating System Support for Digital Audio and Video (NOSSDAV), Cambridge, England, July 1998. [83] VERSCHEURE, O., FROSSARD, P., HAMDI, M. User-Oriented QoS Analysis in MPEG-2 Video Delivery. Real-Time Imaging 5, 305-314, 1999. [84] Video Quality Expert Group (VQEG) Web Site: http://www.its.bldrdoc.gov/vqeg/ [85] Video Quality Expert Group (VQEG). Final Report from the Video Quality Experts Group on the Validation of Objective Models of Video Quality Assessment. 2000. [86] VideoLAN - VLC Media Player. Available at http://www.videolan.org/ [87] WANG, Y. Survey of Objective Video Quality Measurements. 2006. [88] WANG, Z., BOVIK, A., SHEIKH, H., SIMONCELLI, E. Image Quality Assessment: From Error Visibility to Structural Similarity. IEEE Transactions on Image Processing, vol. 13, no. 4, pp. 600-612, Apr. 2004. [89] WANG, Z., SHEIKH, R., BOVIQ, B. Objective Video Quality Assessment. Chapter 41 in “The Handbook of Video Databases: Design and Applications.” B. FURHT and O. MARQURE, ed., CRC Press, pp. 1041-1078, September 2003. [90] WERNER, J. Impulse Noise in the Loop Plant. Communications - ICC, 1990. [91] WINKLER, S., CAMPOS, R. Video Quality Evaluation for Internet Streaming Applications. Proc. SPIE Human Vision and Electronic Imaging Conference. Santa Clara, 2003. [92] WU, H., CLAYPOOL, M., KINICKI, R. A Model for MPEG with Forward Error Correction and TCPFriendly Bandwidth. 13th International Workshop on Network and Operating Systems Support for Digital Audio and Video (NOSSDAV), Monterey, California. June, 2003. [93] WU, H., CLAYPOOL, M., KINICKI, R. Adjusting Forward Error Correction with Quality Scaling for Streaming MPEG. 15th International Workshop on Network and Operating Systems Support for Digital Audio and Video (NOSSDAV), Skamania, Washington. June, 2005.

103