Francisco Janiel de Oliveira · 2019. 10. 26. · Francisco Janiel de Oliveira AVALIAÇÃO DE DESEMPENHO DE VIDEOCONFERÊNCIA EM REDES SDN/OPENFLOW USANDO VÍDEO ESCALÁVEL Trabalho

Francisco Janiel de Oliveira

AVALIAÇÃO DE DESEMPENHO DE VIDEOCONFERÊNCIA EM

REDES SDN/OPENFLOW USANDO VÍDEO ESCALÁVEL

Universidade Federal de Pernambuco

[email protected]

RECIFE2017

www.cin.ufpe.br/~posgraduacao


AVALIAÇÃO DE DESEMPENHO DE VIDEOCONFERÊNCIA EMREDES SDN/OPENFLOW USANDO VÍDEO ESCALÁVEL

Trabalho apresentado ao Programa de Pós-graduação em

Ciência da Computação do Centro de Informática da Univer-

sidade Federal de Pernambuco como requisito parcial para

obtenção do grau de Mestre em Ciência da Computação.

Orientador: Prof. Dr. Eduardo Antônio Guimarães Tavares

RECIFE2017

Catalogação na fonte

Bibliotecária Monick Raquel Silvestre da S. Portes, CRB4-1217

O48a Oliviera, Francisco Janiel de

Avaliação de desempenho de videoconferência em redes SDN/Openflow usando vídeo escalável / Francisco Janiel de Oliveira. – 2017.

95 f.: il., fig., tab. Orientador: Eduardo Antônio Guimarães Tavares. Dissertação (Mestrado) – Universidade Federal de Pernambuco. CIn,

Ciência da Computação, Recife, 2017. Inclui referências.

1. Avaliação de desempenho. 2. Videoconferência. I. Tavares, Eduardo Antônio Guimarães (orientador). II. Título. 004.029 CDD (23. ed.) UFPE- MEI 2017-222


Avaliação de Desempenho de Videoconferência em redes

SDN/Openflow usando Vídeo Escalável

Dissertação apresentada ao Programa de Pós-

-Graduação em Ciência da Computação da Universidade Federal de Pernambuco, como

requisito parcial para a obtenção do título de Mestre em Ciência da Computação.

Aprovado em: 27/06/2017

BANCA EXAMINADORA

__________________________________________________ Prof. Dr. Stênio Flávio de Lacerda Fernandes

Centro de Informática/UFPE

___________________________________________________ Prof. Dr. Bruno Silva

IBM RESEARCH

___________________________________________________ Prof. Dr. Eduardo Antônio Guimarães Tavares

Centro de Informática/UFPE (Orientador)

Eu dedico essa dissertação à minha família, aos meus

amigos, aos professores e a todos aqueles me apoiaram

direta ou indiretamente, seja auxiliando nas horas difíceis

ou apoiando moralmente para eu nunca desistir.

Agradecimentos

Em primeiro lugar a Deus pela oportunidade de lutar e conquistar.À minha família pelo apoio.Ao IFPI por facilitar as viagens e a compreensão da necessidade de se investir na

capacitação dos seus servidores.À Diretora do IFPI Campus Teresina Zona Sul, Francisca Assunção de Almeida Félix

por me apoiar, mesmo ciente do acúmulo de serviços no campus devido à minha ausência.Ao coordenador de Tecnologia da Informação do Campus Teresina Zona Sul, Gláucio

Leite, pelo apoio nessa jornada, assim como pelas sugestões relevantes e dicas importantes. Suaexperiência por ter vivenciado essa vida de mestrando recente contribuiu positivamente nosmomentos de pesquisas e na escrita da dissertação.

Aos meus companheiros de lutas, viagens, trabalho e profissão Shalton Viana e JacksRenan, por terem contribuído desde o início desta jornada, dando-me força durante o mestrado eoportunizando discussões produtivas no período de pesquisa.

Ao meu orientador Eduardo Tavares por me encorajar e acreditar no meu potencial emconcluir essa jornada.

"Toda longa caminhada

Começa com o primeiro passo."

—DITADO POPULAR

Resumo

Os serviços de videoconferência estão em expansão. Existe uma migração em númerode usuários desses serviços baseado em uma sala dedicada em direção aos dispositivos pessoaise desktop. Essa tendência gera o desafio para o tratamento de clientes heterogêneos em umareunião virtual. O vídeo escalável H.264/SVC (Scalable Video Coding) se propõe a tratarrequisitos de usuários diferentes em uma mesma transmissão em grupo. As redes tradicionais IP(Internet Protocol) não dão o suporte necessário para explorar o potencial dessa tecnologia devídeo por oferecer somente o serviço do melhor esforço. Em contrapartida, o paradigma SDN(Software Defined Networking) mostra-se atraente pela possibilidade de se programar a redede maneira coordenada facilitando o fornecimento eficaz de QoS (Quality of Service), alémde ter conhecimento do tipo de vídeo em tráfego. As funcionalidades de flexibilidade e visãoglobal da rede promovida pelo SDN serviram de motivação para análise do comportamento dosserviços de videoconferência. Esse trabalho de pesquisa apresenta a avaliação de desempenhoconduzido pelas métricas de vazão, atraso e PSNR (Peak Signal-to-Noise Ratio) quanto ao tipode rede (rede tradicional IP e paradigma SDN) e o tipo de vídeo (Não-Escalável e Escalável) emum cliente de alta resolução de tela. A metodologia baseada DoE (Design of Experiment) foiutilizada para analisar dois experimentos construídos através do emulador de rede Mininet. Atécnica do vídeo baseado no trace foi utilizada para simular o conteúdo dos vídeos transmitidos.Os experimentos utilizaram um nível de congestionamento flutuante de 40% da capacidade dosenlaces aplicados nos ambientes de testes (Singlepath e Multipath). Os resultados mostraramque o paradigma SDN ofereceu melhor qualidade do vídeo entregue, menor atraso e maior vazão.O vídeo escalável H.264/SVC teve o melhor desempenho.

Palavras-chave: SDN. Videoconferência. H.264/SVC. PSNR. DoE. Mininet.

Abstract

The videoconferencing services are increasing. There is a migration in number of usersof these services based on a room dedicated to personal devices and desktop. This trend generatesthe challenge for the treatment of heterogeneous clients in a virtual meeting. The scalable videoH.264/SVC (Scalable Video Coding) proposes to treat requirements of different users in a sametransmission in-group. The traditional networks IP (Internet Protocol) do not provide the supportneeded to exploit the potential of this video technology, since it only offers the best effort service.On the other hand, the SDN paradigm (Software Defined Networking) is attractive for its abilityto program the network in a coordinated way facilitating the provision of QoS (Quality ofService), as well as being aware of the type of video on traffic. These flexibility features andthe network overview promoted by the SDN provided the motivation to analyze the behavior ofvideoconferencing services. This research work presents a performance evaluation driven bythe throughput metrics, delay and PSNR (Peak Signal-to-Noise Ratio) for the type of network(traditional network IP and SDN paradigm) and the type of video (not scalable and scalable) inhigh screen resolution a client. The methodology based on DoE (Design of Experiment) was usedfor analyzing two experiments built using the Mininet network emulator. The technique of videobased on the trace was used to represent the models of video transmissions in multi-versionsand multilayers. The experiments are based on a level of 40% capacity floating congestion oflinks and using different test environment (singlepath and multipath). The results showed thatthe SDN paradigm offered better video quality delivered, less delay and increased throughput.The scalable video H.264/SVC had the best performance.

Keywords: SDN. Videoconferencing. H.264/SVC. PSNR. DoE. Mininet.

Lista de Figuras

3.1 Sistema de videoconferência tradicional (ZHAO et al., 2014) . . . . . . . . . . 323.2 Definição de Group of Images (GoP) (APOSTOLOPOULOS; TAN; WEE, 2002) 343.3 Relação Simulcast versus SVC (HUSEMANN, 2011) . . . . . . . . . . . . . . 353.4 Visão simplificada da arquitetura SDN (KREUTZ et al., 2015) . . . . . . . . . 383.5 Visão da arquitetura do switch Openflow (MCKEOWN et al., 2008) . . . . . . 40

4.1 Ambiente Singlepath para rede tradicional IP . . . . . . . . . . . . . . . . . . 534.2 Ambiente Singlepath para rede SDN . . . . . . . . . . . . . . . . . . . . . . . 534.3 Ambiente Multipath para rede tradicional IP . . . . . . . . . . . . . . . . . . . 544.4 Ambiente Multipath para rede SDN . . . . . . . . . . . . . . . . . . . . . . . 554.5 Simplificação do tráfego de congestionamento . . . . . . . . . . . . . . . . . . 564.6 Etapas no processo de transporte de trace de vídeo (SEELING et al., 2012) . . 564.7 Pilha de protocolos usados na transmissão de traces . . . . . . . . . . . . . . . 574.8 Framework de avaliação do vídeo H.264/AVC . . . . . . . . . . . . . . . . . . 604.9 Framework de avaliação do vídeo H.264/SVC . . . . . . . . . . . . . . . . . . 664.10 Estrutura dos frames em H.264/SVC . . . . . . . . . . . . . . . . . . . . . . . 69

5.1 Vazão média em Singlepath . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745.2 Vazão média em Multipath . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745.3 Atraso médio em Singlepath . . . . . . . . . . . . . . . . . . . . . . . . . . . 755.4 Atraso médio em Multipath . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755.5 PSNR médio em Singlepath . . . . . . . . . . . . . . . . . . . . . . . . . . . 765.6 PSNR médio em Multipath . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Lista de Tabelas

3.1 Principais componentes de uma entrada em uma tabela de fluxo (FOUNDATION,2012a) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.2 Fatorial de dois fatores (MONTGOMERY; RUNGER, 2013) . . . . . . . . . . 433.3 Relação PSNR e MOS (KLAUE et al., 2003) . . . . . . . . . . . . . . . . . . 48

4.1 Relação entre os métodos de transmissão Multiversões e Multicamadas . . . . 584.2 Amostra do mininet-traffic-trace para o vídeo AVC-QCIF . . . . . . . . . . . . 614.3 Amostra do mininet-traffic-trace para o vídeo AVC-CIF . . . . . . . . . . . . . 624.4 Camadas H.264/SVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654.5 Amostra do mininet-traffic-trace para o vídeo SVC . . . . . . . . . . . . . . . 684.6 Relacionamento entre as camadas SVC e o ToS . . . . . . . . . . . . . . . . . 68

5.1 Vazão, Atraso e PSNR para redes tradicionais IP . . . . . . . . . . . . . . . . . 725.2 Vazão, Atraso e PSNR para redes SDN . . . . . . . . . . . . . . . . . . . . . . 735.3 ANOVA Vazão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775.4 ANOVA Atraso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775.5 ANOVA PSNR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775.6 Vazão Tukey em Singlepath quanto ao tipo de vídeo . . . . . . . . . . . . . . . 795.7 Vazão Tukey em Singlepath quanto ao tipo de rede . . . . . . . . . . . . . . . . 795.8 Vazão Tukey em Singlepath . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795.9 Vazão Tukey em Multipath quanto ao tipo de vídeo . . . . . . . . . . . . . . . 805.10 Vazão Tukey em Multipath quanto ao tipo de rede . . . . . . . . . . . . . . . . 805.11 Vazão Tukey em Multipath . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805.12 Atraso Tukey em Singlepath quanto ao tipo de vídeo . . . . . . . . . . . . . . . 815.13 Atraso Tukey em Singlepath quanto ao tipo de rede . . . . . . . . . . . . . . . 815.14 Atraso Tukey em Singlepath . . . . . . . . . . . . . . . . . . . . . . . . . . . 825.15 Atraso Tukey em Multipath quanto ao tipo de vídeo . . . . . . . . . . . . . . . 825.16 Atraso Tukey em Multipath quanto ao tipo de rede . . . . . . . . . . . . . . . . 835.17 Atraso em Multipath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835.18 PSNR Tukey em Singlepath quanto ao tipo de vídeo . . . . . . . . . . . . . . . 835.19 PSNR Tukey em Singlepath quanto ao tipo de rede . . . . . . . . . . . . . . . . 845.20 PSNR Tukey em Singlepath . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845.21 PSNR Tukey em Multipath quanto ao tipo de vídeo . . . . . . . . . . . . . . . 845.22 PSNR Tukey em Multipath quanto ao tipo de rede . . . . . . . . . . . . . . . . 855.23 PSNR Tukey em Multipath . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855.24 Multipath PSNR e MOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Lista de Acrônimos

JSVM Joint Scalable Video Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27

JVT Joint Video Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

VCEG Video Coding Experts Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

MPEG Moving Picture Experts Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

NS-2 Network Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

CBR Constant Bit Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

D-ITG Distributed Internet Traffic Generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

RLM Receiver-driven Layered Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

RGB Red Green Blue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

PSNR Peak Signal-to-Noise Ratio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

MOS Mean Opinion Score . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

H.264/AVC Advanced Video Coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

H.264/SVC Scalable Video Coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

SDN Software Defined Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

RTCP Real-Time Transport Control Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

FEC Forward Error Correction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46

H.265/HEVC High Efficiency Video Coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91

SVEF Scalable Video-streaming Evaluation Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 27

OSPF Open Shortest Path First . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

QoS Quality of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

VoIP Voice over Internet Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

DSCP Differentiated Services Code Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

DiffServ Differentiated Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

IntServ Integrated Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

MCU Multipoint Control Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

P2P Peer-to-peer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

ITU-T International Telecommunication Union Telecommunication Sector . . . . . . . . . 23

FIB Forwarding Information Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

API Application Programming Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

VM Virtual Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

ANOVA Analysis of Variance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

ISDN Integrated Service Digital Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

SSL Secure Socket Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

HTTP Hypertext Transfer Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

DASH Dynamic Adaptive Streaming over HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

DoE Design of Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

ISO International Organization for Standardization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

IEC International Electrotechnical Commission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

RTP Real-time Transport Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

CIF Common Interchange Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

TCP Transmission Control Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31

IP Internet Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

RGB Red Green Blue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

GoP Group of Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

QCIF Quarter Common Interchange Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

QP Quantization Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

UDP User Datagram Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

ONF Open Networking Foundation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

QoE Quality of Experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

ToS Type of Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

NAL Network Abstraction Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

NALU NAL Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

PC Personal Computer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

VCL Video Coding Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

IETF Internet Engineering Task Force . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

SIP Session Initiation Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

MGS Medium Grain Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

CGS Coarse Grain Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

REST Representational State Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38

Sumário

1 INTRODUÇÃO ........................................................................................................ 15

1.1 MOTIVAÇÃO ........................................................................................................... 17

1.2 OBJETIVOS ............................................................................................................. 18

1.2.1 Objetivo Geral .......................................................................................................... 19

1.2.2 Objetivos Específicos ................................................................................................ 19

1.3 ESTRUTURA DA DISSERTAÇÃO ....................................................................... 20

2 TRABALHOS RELACIONADOS ........................................................................ 21

2.1 HETEROGENEIDADE DOS USUÁRIOS DO SISTEMA .................................... 21

2.2 FERRAMENTAS DE AVALIAÇÃO DE VíDEO TRANSPORTADO EM REDE

DE PACOTE ............................................................................................................. 24

2.3 STREAMING DE VíDEO EM SDN ......................................................................... 27

3 REFERENCIAL TEÓRICO .................................................................................. 30

3.1 VIDEOCONFERÊNCIA ........................................................................................ 30

3.2 VíDEO ESCALÁVEL ........................................................................................... 32

3.2.1 Escalabilidade Temporal ........................................................................................ 35

3.2.2 Escalabilidade Espacial .......................................................................................... 35

3.2.3 Escalabilidade de Qualidade ................................................................................. 35

3.3 PARADIGMA SDN ............................................................................................... 36

3.3.1 Rede Openflow ......................................................................................................... 38

3.3.2 Controlador Ryu ...................................................................................................... 39

3.3.3 Open vSwitch ........................................................................................................... 40

3.3.4 Mininet ...................................................................................................................... 40

3.4 AVALIAÇÃO DE DESEMPENHO ...................................................................... 41

3.4.1 Projeto de Experimentos ......................................................................................... 41

3.4.2 Qualidade de Serviço ............................................................................................... 43

3.4.3 Qualidade de Experiência ....................................................................................... 45

4 METODOLOGIA E AMBIENTE DE EXPERIMENTAÇÃO ........................... 48

4.1 EMULADOR MININET ........................................................................................ 50

4.2.1 Ambiente de Teste Singlepath ................................................................................ 51

4.2.2 Ambiente de Teste Multipath ................................................................................. 51

4.2.3 O Nível de Congestionamento do Tráfego de Background ................................. 53

4.3 TRANSPORTE DOS TRACES DE VíDEO .......................................................... 54

4.3.1 A Seleção do Vídeo .................................................................................................. 56

4.4 FRAMEWORKS DE AVALIAÇÃO ........................................................................ 57

4.4.1 Framework de Avaliação do Vídeo Não-Escalável H.264/AVC .......................... 57

4.4.2 Framework de Avaliação do Vídeo Escalável H.264/SVC .................................. 63

5 RESULTADOS EXPERIMENTAIS ..................................................................... 71

5.1 RESULTADOS DOS TRATAMENTOS ................................................................ 72

5.1.1 Avaliando a Vazão ................................................................................................... 76

5.1.2 Avaliando o Atraso .................................................................................................. 79

5.1.3 Avaliando a Qualidade do Vídeo ........................................................................... 81

5.2 DISCUSSÕES ......................................................................................................... 84

6 CONCLUSÃO ........................................................................................................ 88

6.1 CONTRIBUIÇÕES ................................................................................................. 89

6.2 LIMITAÇÕES ........................................................................................................ 90

6.2 TRABALHOS FUTUROS ..................................................................................... 90

REFERÊNCIAS ..................................................................................................... 92

151515

1INTRODUÇÃO

A popularidade das aplicações de videoconferência está em crescimento quanto aonúmero de usuários. De acordo com o relatório anual da Cisco (CISCO, 2016), isso ocorre devidoao aumento da largura de banda na rede de acesso e da redução dos custos dos dispositivos queincluem câmeras em suas configurações. Outro fator importante é o barateamento dos serviços ea simplificação dos sistemas de videoconferência para facilitar o acesso do usuário.

Esse mesmo relatório aponta outra tendência que revela o crescimento do serviço devideoconferência em Personal Computer (PC) desktop, o qual será superior em 2020 aos serviçosde videoconferência baseados em sala com equipamentos caros e sofisticados. Essa mudança deambiente dominante vai criar novos desafios. Em um ambiente desktop, a garantia que todosos clientes tenham poder computacional e resolução de telas iguais deixam de ser obrigatórios.A heterogeneidade dos usuários, tanto em largura de banda quanto em relação à capacidade deprocessamento, passa a ser o principal fator a ser tratado nos novos sistemas de videoconferência.

Os sistemas de videoconferência baseados em sala dedicada normalmente requerem umlocal para a instalação de todos os equipamentos necessários para o funcionamento do serviço,como monitores, microfone, caixa de som e codec. Normalmente, o serviço é fornecido por umasolução proprietária e funcionam melhor quando estão livres das regras de um firewall. Por outrolado, as soluções baseadas em desktop necessitam que um mesmo programa esteja instalado noPC ou dispositivo móvel do grupo de usuários para o serviço ser operacional.

Os principais sistemas de videoconferência que englobam as soluções baseadas emsala dedicada e desktop utilizam a Internet ou a rede tradicional Internet Protocol (IP) comorede de entrega de conteúdo. Esses sistemas sofrem com a variação da largura de bandadisponível, o que provoca perdas de pacotes e atrasos. Isso implica diretamente na baixa Qualityof Experience (QoE) dos usuários. As redes tradicionais IP, de maneira geral, não garante Qualityof Service (QoS) a nenhuma aplicação. O serviço do melhor esforço é considerado o únicodisponível a todos os pacotes em trânsito, embora tentativas de soluções, tais como IntegratedServices (IntServ) e Differentiated Services (DiffServ), tenham falhado em sua implementaçãoglobal em razão da própria arquitetura distribuída da Internet (EGILMEZ et al., 2012). O IntServé uma técnica de QoS em que os recursos da rede são reservados antes de se transmitir os dados,objetivando dar garantias na entrega dos serviços. Por outro lado, o DiffServ está voltado para

16

a priorização de pacotes, tratando de forma diferenciada os grupos de tráfegos de aplicaçõesdiferentes.

Diante das limitações da rede tradicional IP, novas propostas de soluções para Internetdo futuro estão presentes na literatura, sendo a mais bem-sucedida o paradigma Software DefinedNetworking (SDN) (KREUTZ et al., 2015). Esse paradigma extrai o plano de controle dosswitches/roteadores e o coloca em uma entidade externa. Dessa forma, possibilita a criação daabstração de uma visão única de toda a rede. Esse modelo, que utiliza o mecanismo do fluxopara tratar o encaminhamento dos pacotes, possibilitou uma flexibilização sem precedentes nasredes, sendo foco de muitas pesquisas científicas e experimentações industriais (FOUNDATION,2012b).

O Openflow foi o primeiro experimento bem-sucedido para a comunicação entre os planosde dados e o plano de controle viabilizando um modelo de SDN (MCKEOWN et al., 2008). Oplano de controle trata da tomada de decisão quando um pacote chega a um switch, enquanto oplano de dados aplica essa decisão, como, por exemplo, encaminhar o pacote para um porta desaída, descartar o pacote, entre outras. Essa nova forma de gerenciamento criou uma base parase introduzir a inovação na rede, uma vez que as redes tradicionais IP são muito resistentes paraaceitarem a habilitação de novas propostas. O Openflow define a forma como o encaminhamentodos pacotes deve acontecer, além de consultar os estados dos switches/roteadores. Essas consultaspermitem as coletas de estatísticas que possibilitam à rede reagir flexivelmente conforme asmudanças que venham a ocorrer.

Essa flexibilização permitiu a execução com sucesso de soluções de QoS desenvolvidaspara redes tradicionais. Entre elas, as soluções semelhantes ao DiffServ passaram a ser utilizadas,porém, foram abordadas de forma diferente. O DiffServ se baseia no campo do cabeçalho IPType of Services (ToS) para a priorização de dados. O novo formato de se filtrar pacotes baseadono fluxo possibilita utilizar os cabeçalhos dos outros protocolos, onde se deduz que a rede podeter conhecimento sobre qual aplicação pertence os pacotes em trânsito. Nesse novo ambiente,tecnologias inviáveis ou complexas para redes tradicionais IP ganharam praticidades, tais comoa utilização do IP multicast e o roteamento em multicaminhos. O IP multicast é um processode transmissão em grupo onde a replicação dos dados ocorre nos roteadores. Esse mecanismoaplica-se bem às soluções de videoconferência, pois viabiliza a transmissão de vídeo para gruposde clientes a fim de economizar os recursos de largura de banda. O roteamento em multicaminhosé uma técnica de engenharia de tráfego onde é possível a existência de mais de uma rota entreuma fonte e um destino sendo usados simultaneamente. Dessa forma, habilita o balanceamentodo tráfego nos roteadores controlados pelo plano de controle externo.

Uma das soluções bem-sucedida para atender a heterogeneidade dos dispositivos trata-sedo Scalable Video Coding (H.264/SVC) (SCHWARZ et al., 2007). O H.264/SVC consiste emcodificar um vídeo em camadas possibilitando gerar diferentes versões do vídeo da mesma fonte.Essas camadas contêm características diferentes quanto à resolução espacial, taxa de frames equalidade. A primeira camada é denominada camada base, enquanto as demais são chamadas de

1.1. MOTIVAÇÃO 17

camadas de enriquecimentos. A camada base contém uma versão do vídeo com qualidade mínimae requer menos largura de banda. Existe uma relação de dependência entre as camadas, sendo acamada base a mais importante, visto que esta gera as outras de enriquecimento. O princípio dacodificação é hierárquico, onde cada camada de enriquecimento acrescenta informações sobre acamada imediatamente inferior. Diante disso, o Openflow poderia atuar priorizando a camadabase em situação de congestionamento no uso de sistemas de videoconferência. Dessa forma,esses sistemas seriam mais resilientes a perdas de pacotes, melhorando o QoE dos usuários.

Sendo assim, a relação das redes SDN/Openflow com o vídeo escalável H.264/SVCpossibilita um caso de sucesso. A migração das aplicações de videoconferência que atuam nasredes tradicionais IP para redes SDN pode acontecer de forma transparente sem alteração naarquitetura dos sistemas existentes. Porém, tendo conhecimento de que a rede de transporteutilizada é o SDN, novos recursos podem ser inseridos com o objetivo de gerar um melhordesempenho.

1.1 MOTIVAÇÃO

Aplicações de videoconferência são serviços que requerem alta largura de banda e baixoatraso para o seu bom funcionamento (ZHAO et al., 2014). Nos últimos anos, a utilização dossistemas de videoconferência vem se expandindo. As principais razões foram o aumento dalargura de banda na rede de acesso e o crescimento do número de dispositivos habilitados comcâmeras o que inseriu mais usuários ao serviço (CISCO, 2016). Existe uma migração dessesserviços baseados em sala dedicada para os dispositivos pessoais móveis e desktop PC. Essanova tendência aumentou a escala do problema para tratar a heterogeneidade dos dispositivos emuma reunião virtual.

Uma técnica bastante utilizada para resolver esse problema se baseia em transmissão dovídeo em versões independentes em conexões individuais, a qual é conhecida como simulcastou multiversões. Dessa forma, usuários de diferentes configurações, ou seja, diferente poderde processamento e largura de banda, receberão os vídeos de acordo com as suas requisições.A desvantagem desse método é o aumento do consumo de banda conforme se eleva o númerode versões (XU et al., 2012). Por outro lado, existe uma solução de transmissão de vídeoem multicamadas baseada no H.264/SVC (SCHWARZ et al., 2007) com os mesmos objetivos.Porém, essa solução possibilita transmitir diferentes versões do mesmo vídeo organizadas emcamadas em uma única conexão. Essa solução de transmissão é mais escalável para atenderdiferentes requisitos de usuários simultaneamente com menos recursos de banda. Uma outraalternativa atraente que trata bem o problema da heterogeneidade dos links, porém, mais focadona adaptação à flutuação da largura de banda, são as tecnologias Dynamic Adaptive Streamingover HTTP (DASH), as quais estão bem aplicadas às aplicações de Vídeo on Demand e livestre-aming (SEUFERT et al., 2015). Pelo fato dessas tecnologias estarem, atualmente, em processode estudo para os cenários de videoconferência não foram abordadas nesse trabalho de pesquisa.

1.2. OBJETIVOS 18

Arquitetura de videoconferência baseada em servidor refletor ou Multipoint ControlUnit (MCU) é uma técnica tradicional para habilitar videoconferência, afim de economizar alargura de banda no lado dos clientes (ZHAO et al., 2014). Essa arquitetura foi projetada paraas redes tradicionais IP baseadas no princípio cliente/servidor. O número de MCU que atuadurante uma reunião virtual pode variar de acordo com o número e a localização dos clientes.Nesses sistemas, o MCU cria um tipo de multicast em nível de aplicação, sendo este o ponto dereplicação dos dados, possibilitando desempenhar o processo de transcodificação para adaptaro vídeo à variação do congestionamento da rede, assim como mixar o conteúdo em uma únicaconexão. Dessa forma, todo o tráfego deve passar pelo MCU podendo gerar atrasos em razão doprocesso de transcodificação. A capacidade de processamento fornecido por uma MCU é o quedefine o número de usuários que o sistema pode suportar.

A arquitetura baseada em MCU está tão bem enraizada nas redes tradicionais quecontinua sendo a base para outros modelos de soluções desenvolvidas como Peer-to-peer (P2P)(XU et al., 2012) ou mesmo na computação em nuvens (RODRÍGUEZ et al., 2016). Os serviçosfuncionam a nível aceitáveis, porém, para alcançar um desempenho melhor, é preciso que hajauma mudança na infraestrutura da rede de transporte dos dados. A arquitetura alternativa ébaseada no uso do paradigma SDN (FEAMSTER; REXFORD; ZEGURA, 2014). Nas funçõesdo MCU de gerenciamento o tráfego fica por conta da rede. As funções de transcodificaçãodeixam de existir e, nessa situação, os clientes deverão transmitir diretamente para os grupos semalteração nos dados. Entretanto, novas características podem ser assimiladas, como IP multicaste priorização de dados.

Essas arquiteturas que abrangem diferentes tipos de rede e de vídeos para videoconferên-cia possuem poucos trabalhos existente na literatura que abordam uma avaliação que caracterizema influência desses fatores. Existem trabalhos em SDN que apontam resultados promissorescomo os de Zhao et al. (2014) que trabalham com vídeo não escalável e os de Yang et al. (2016)que utiliza o conceito de escalabilidade. Essa diferença de ambiente de rede, bem como aestrutura do vídeo utilizado serviu de motivação para se fazer uma avaliação comparativa dedesempenho desses sistemas.

1.2 OBJETIVOS

A presente dissertação faz uma avaliação de desempenho de sistemas de videoconferênciaem redes tradicionais IP e o paradigma SDN, assim como avalia o comportamento do vídeoquanto à escalabilidade, explorando o multicast e a priorização de fluxos. Os experimentos foramimplementados de modo a transmitirem os vídeos nas mesmas condições de congestionamentoflutuante.

Essa estrutura é montada no emulador de rede Mininet, usando a metodologia Design ofExperiments (DoE) para analisar a hipótese de que as aplicações de videoconferência podemoferecer um melhor desempenho quando aplicadas em redes programáveis SDN com vídeo

1.2. OBJETIVOS 19

escalável H.264/SVC. As métricas representativas que conduzem a avaliação do desempenhoforam a vazão, o atraso e o Peak Signal-to-Noise Ratio (PSNR).

Os resultados obtidos evidenciam a relevância da adoção do SDN/Openflow e o usodo vídeo escalável, os quais podem servir de guias para a construção dos novos sistemas devideoconferência no futuro.

1.2.1 Objetivo Geral

O trabalho de pesquisa objetivou avaliar o desempenho dos sistemas de videoconferênciaem redes tradicional IP e o paradigma SDN quanto à qualidade do vídeo entregue, à largura debanda consumida e ao atraso sofrido pelos pacotes. Um cenário do tráfego de congestionamentoflutuante foi implementado para concorrer com os fluxos de vídeos em estudo. Dois clientesrequisitando resoluções Quarter Common Interchange Format (QCIF) e Common InterchangeFormat (CIF) se diferem quanto à capacidade de resolução de vídeo, o que demanda os sistemasa atenderem a escalabilidade espacial. Os dados obtidos são observados no contexto de umcliente de maior capacidade, gerando esforços da rede para atender os requisitos desse cliente.

1.2.2 Objetivos Específicos

1. Avaliar a influência da rede tradicional IP e o paradigma SDN no contexto de video-conferência. Nessas circunstâncias, os sistemas de construção de rotas baseadas noprotocolo Open Shortest Path First (OSPF) são comparados com o Openflow. Duasarquiteturas também fazem parte dessa avaliação, que são as baseadas em MCU e nocontrolador SDN;

2. Verificar o comportamento da escalabilidade do vídeo quanto à transmissão dossistemas, seja em Advanced Video Coding (H.264/AVC) ou em H.264/SVC. Nessasituação, o meio de transmissão em simulcast faz a utilização de um conjunto devídeo independente que confronta com o método em multicamadas;

3. Checar a relevância do tipo de ambiente presente em uma rede tanto a nível Singlepathquanto Multipath. Nessa situação, são adotadas duas estratégias de QoS de acordocom o tipo de ambiente em teste, sendo a primeira baseada em priorização do fluxo ea segunda construída no desvio de rotas sem congestionamento;

4. Verificar a viabilidade do sistema em diferentes cenários quanto às métricas repre-sentativas, as quais são compostas pela vazão, que representa a largura de banda útil,o atraso, que demonstra o tempo de viagem da origem ao destino, e o PSNR, querepresenta a qualidade objetiva dos vídeos.

1.3. ESTRUTURA DA DISSERTAÇÃO 20

1.3 ESTRUTURA DA DISSERTAÇÃO

O restante dessa dissertação está organizado da seguinte forma:

� Capítulo 2 - Trabalhos Relacionados: os trabalhos relacionados que foram consul-tados para a elaboração desse trabalho estão inclusos.

� Capítulo 3 - Referencial Teórico: a revisão teórica é abordada, assim como sãoexplorados os principais conceitos de videoconferências, a escalabilidade do vídeo, oparadigma de redes e o método para se avaliar desempenho.

� Capítulo 4 - Metodologia: a metodologia e todo o processo de teste são construídos.As ferramentas implementadas são detalhadas bem como as justificativas para o usodo modelo de congestionamento adotado nos testes.

� Capítulo 5 - Resultados: os resultados são discutidos e as relações entre os tiposde redes e de vídeo mostram as suas relevâncias, de acordo com as métricas de vazão,atraso e PSNR.

� Capítulo 6 - Conclusão: as considerações finais são elaboradas baseadas nos resul-tados, assim como os trabalhos futuros.

212121

2TRABALHOS RELACIONADOS

Os principais trabalhos que abordam a temática em estudo são expostos a seguir. Osprincipais conceitos envolvidos em um sistema de videoconferência, como transmissão emgrupo e heterogeneidade são descritos com base em trabalho relevantes na literatura. Osmétodos de experimentação utilizados para avaliar os sistemas de vídeos em rede encontram-secorrelacionados, assim como os streamings de vídeo que utilizam o paradigma SDN.

2.1 HETEROGENEIDADE DOS USUÁRIOS DO SISTEMA

Um caso que se manifesta o problema da heterogeneidade ocorre quando usuários comcaracterísticas diferentes estão recebendo o mesmo conteúdo visual. Tratando-se de sistemas destreaming de mídia, a heterogeneidade dos clientes ganha mais complexidade. Essa complexi-dade é visível quando se trata a disponibilidade de largura de banda alinhada ao atendimentosimultâneo das requisições de diferentes usuários. A ausência de garantia dos serviços na In-ternet, tais como largura de banda, delay e loss, é desafiante, mas é preciso, ainda, averiguar aqualidade do conteúdo entregue, ou seja, as métricas da camada de aplicação que precisam sertratadas.

A heterogeneidade dos dispositivos está relacionada aos usuários de configuraçõesdiferentes que recebem fluxos de uma mesma fonte em tempo real. Essa situação se manifestaem aplicações de videoconferência e sistemas de streaming ao vivo.

Um dos primeiros trabalhos a tratar da heterogeneidade dos usuários foi realizado porMcCanne et al. (1996). O problema mencionado trata-se da transmissão de vídeo ao vivo deum seminário de uma universidade para diversos usuários com dispositivos de resolução de teladiferentes, assim como apresenta variação na largura de banda da rede. O algoritmo Receiver-driven Layered Multicast (RLM) é utilizado com sucesso nas simulações. O conceito de vídeoem camada e transmissão em grupo multicast começou a ser explorado nessa época. A escolhado tipo de vídeo é baseada nas características do receptor.

Para acompanhar as necessidades das novas aplicações era necessário que a estruturado vídeo estivesse favorável para isso. Wiegand et al. (2003) apresentam as especificidades dopadrão H.264/AVC. O impacto proporcionado pelo H.264/AVC possibilitou a codificação de

2.1. HETEROGENEIDADE DOS USUÁRIOS DO SISTEMA 22

perfis para atender as variadas aplicações de vídeo que se encontrava em crescimento na época.Seu diferencial está em reduzir em até 50% do bitrate e manter a mesma qualidade em relaçãoao padrão anterior, no caso MPEG-4 visual.

Schwarz et al. (2007) fazem um detalhamento da extensão escalável do H.264/AVC. Aproposta é aceita pelas entidades de padronizações internacionais: International Telecommuni-cation Union Telecommunication Sector (ITU-T), International Organization for Standardiza-tion (ISO) e International Electrotechnical Commission (IEC). O padrão de vídeo H.264/SVCimplementa com sucesso três tipos de escalabilidades com o objetivo de atender as redes hetero-gêneas e os dispositivos diferentes, a saber: escalabilidade temporal, escalabilidade espacial eescalabilidade de qualidade.

De acordo com Schwarz et al. (2007), o conceito de escalabilidade está relacionado aoatendimento de diversos usuários com características diferentes dentro de uma mesma trans-missão de vídeo. Sendo assim, a escalabilidade temporal está relacionada à redução da taxa deframes no intervalo de tempo, enquanto que a escalabilidade espacial à redução da resolução dovídeo transmitido. Por outro lado, a escalabilidade de qualidade está relacionada à redução debitrate para uma combinação tempo e espaço de um frame.

Wien et al. (2007) fazem uma avaliação mais aprofundada do H.264/SVC em relação aoH.264/AVC e outros padrões de vídeos e técnicas de adaptação para escalabilidade. Os estudosestão focados na relação de eficiência da codificação em nível de camada escalável, que é arelação bitrate versus PSNR. Os resultados mostraram que o padrão H.264/SVC exibiu umdesempenho similar ao H.264/AVC, porém superior ao padrão MPEG-4 visual.

Unanue et al. (2011) faz uma abordagem de avaliação da escalabilidade do H.264/SVCem relação à extensão escalável de padrões anteriores. Os resultados mostraram os avanços dasescalabilidades de vídeo no H.264/SVC quanto à flexibilidade e eficiência na codificação. Opadrão H.264/SVC tem o desempenho equivalente ao do H.264/AVC, mas com o diferencial deser flexível. Ao ser utilizado em transmissão, seu processo de adaptação é muito simples, vistoque é necessário apenas descartar as camadas superiores. Esse processo seletivo só é eficientepara a rede dotada de priorização de serviços, onde a camada base teria prioridade em relação àsdemais.

Uma das inovações introduzidas pelo codificador H.264/AVC foi a unidade NetworkAbstraction Layer (NAL) (SEELING et al., 2012). As unidades NAL, que fazem a interface dovídeo para diversas redes de transportes, desempenham uma função de pacote, onde o payload sealterna entre vídeo codificado propriamente dito dentro das camadas Video Coding Layer (VCL)ou metadados relacionados a transmissão, informações de sincronização, descrição de parâmetros,entre outras. Essas unidades foram essenciais para se introduzir a flexibilidade no transporte dovídeo.

Umas das desvantagens do H.264/SVC é a geração de overhead por camada de enrique-cimento. As unidades NAL do H.264/AVC contêm um byte de cabeçalho, enquanto as unidadesNAL do H.264/SVC possuem quatro bytes por camadas de enriquecimento (SEELING et al.,

2.1. HETEROGENEIDADE DOS USUÁRIOS DO SISTEMA 23

2012). Esse fator diferencial contribui no resultado do processo de codificação H.264/SVC, ondecada camada inserida no bitstream colabora com o aumento de overhead de, aproximadamente,10% no bitrate quando comparado ao mesmo bitstream não escalável.

Um vídeo no formato H.264, seja ele tradicional H.264/AVC ou na extensão escalávelH.264/SVC, tem diferentes perfis, visto que são projetados para atender a uma margem amplade aplicações. Ambos definiram perfis em suas especificações destinados às aplicações derequerimento de baixo atraso. Esse perfil, denominado baseline, é recomendável para aplicaçõesde videoconferência.

Esses vídeos podem se agregar em modelos diferentes de transmissão objetivandoatender clientes heterogêneos. Na literatura, existem dois modelos de transmissão bem definidos:multiversões e multicamadas (XU et al., 2012). A transmissão de vídeo em multiversões podeser constituída de vídeos independentes em conexões separadas originados da mesma fonte parao atendimento de diferentes usuários. Cada uma dessas conexões transporta uma versão devídeo não escalável H.264/AVC, as quais se diferenciam entre si quanto a resolução espacial,taxa de frame e qualidade. Ao contrário disso, a transmissão em multicamadas só precisa deuma fonte de um vídeo escalável. Essa única conexão pode ser transmitida pelo vídeo escalávelH.264/SVC.

A definição do codificador do vídeo é um fator crítico para o projeto de um sistema devideoconferência. As soluções baseadas em sala dedicada asseguravam a garantia da homogenei-dade do ambiente de todos os usuários participantes das reuniões virtuais. Nesses ambientes,seriam instalados os mesmos modelos de equipamentos a fim de se manter a operacionalidadequanto aos protocolos e codecs. Uma característica fundamental do codificador estava em lidarcom a heterogeneidade dos links, além de tratar a flutuação da largura de banda disponível. Dessaforma, nesses ambientes, todos os clientes teriam capacidade de transmitir e receber os vídeosem qualidade similares.

Com o advento das videoconferências em aumentar o número de usuários para umambiente desktop (CISCO, 2016), o pré-requisito dos dispositivos dos usuários serem homogê-neos quanto aos recursos de resolução de telas e capacidade de processamento dos dispositivosdeixa de ser obrigatório. Os novos modelos de sistemas de videoconferência devem definirprotocolos para recuperar essas informações, pois são necessários para executar todo o processode adaptação. Uma solução comum é transmitir as distintas versões de vídeo em conexõesdiferentes da fonte para o MCU fazer o repasse. Cada versão se difere em algum critério dacaracterística do vídeo, sendo mais comum definir a resolução espacial distinta entre esses vídeos.Assim, um sistema de transmissão multiversões de vídeo é transmitido. A desvantagem é queas fontes necessitarão de mais largura de banda para a transmissão de mais redundância. Esseprocedimento é realizado por aplicações de videoconferência populares, tais como iChat e Skype(XU et al., 2012).

Por outro lado, executar a transmissão em multicamadas é muito mais vantajoso paraa economia de banda, porém, requer mais processamento. De certa forma, o sistema de vide-

2.2. FERRAMENTAS DE AVALIAÇÃO DE VÍDEO TRANSPORTADO EM REDE DEPACOTE 24oconferência deve se certificar de que todos os participantes tenham capacidade para executara codificação. Como exemplo de aplicações que utilizam esse modelo de codificação estão oHangout (XU et al., 2012) e as soluções de videoconferência Vydio (ELEFTHERIADIS, 2011).

Os serviços de videoconferência são sistemas que requisitam o baixo delay e o atendi-mento de todos os clientes entregando o vídeo em qualidade a níveis aceitáveis. Esses sistemasapresentam uma configuração de uma rede mesh, onde todos enviam tráfegos para todos, sendoimprescindível o uso do multicast. Por deficiência da Internet em fornecer o IP multicast demaneira global, o serviço de multicast baseado nas camadas de aplicação é amplamente adotado.Os desafios das redes multicast são os atendimentos a clientes heterogêneos, mas isso é resolvidopela entrega de grupos com bitrates diferentes. Dessa forma, os usuários assinam os gruposconforme suas necessidades (APOSTOLOPOULOS; TAN; WEE, 2002).

O trabalho de Xu et al. (2012) ao observar o comportamento dos principais sistemas devideoconferência populares para desktop, tais como Skype, iChat e Hangout, traz resultadosmuitos relevantes para a construção dessa pesquisa. Os dados coletados evidenciaram que oHangout trabalha com vídeo escalável e os demais com simulcast. É esclarecedor que todos ostrês sistemas são baseados em servidor um MCU. Porém, não fica claro como esses sistemasfuncionariam em uma rede SDN.

Os sistemas abordados no trabalho de Xu et al. (2012) são baseados em MCU, partindodo princípio de que uma arquitetura P2P descentralizada poderia não ser viável. Isso contradiz oteste comparativo realizado por Debbabi et al. (2014) ao concluir que sistemas na arquiteturaP2P são bastante eficientes, uma vez que os vídeos utilizados foram baseados em camadas. Essasinformações são oriundas de critérios de avaliação diferentes. Debbabi et al. (2014) se baseiammais no delay e na largura de banda que o sistema pode ofertar, enquanto Xu et al. (2012) estámais voltado para a escalabilidade e o processo de adaptação eficiente.

2.2 FERRAMENTAS DE AVALIAÇÃO DE VÍDEO TRANSPORTADO EM REDE DEPACOTE

O processo de avaliação do vídeo em rede IP se divide em três tipos de tráfego de vídeo:real, baseado em trace e baseado em modelo analítico. O tráfego de vídeo baseado em vídeoreal é constituído pelo bitstream do vídeo, sendo ideal para redes reais. O método baseadono trace, que são constituídos por arquivos gerados a partir da descrição do vídeo, tais comotamanho do frame, tipo do frame, identificador do frame, entre outras, pode ser utilizado emredes reais ou simuladas. O tipo de tráfego baseado em modelo analítico é construído atravésdas estatísticas do vídeo e tem a vantagem de obter os resultados mais rápidos em relação aosoutros dois (CASTELLANOS et al., 2017).

As experimentações em rede podem ser executadas em três modelos de ambientes, asaber: ambiente real, simulação e emulação. Os ambientes reais têm os resultados mais precisos,porém são mais caras as reconfigurações e a obtenção de equipamentos. A simulação é mais

2.2. FERRAMENTAS DE AVALIAÇÃO DE VÍDEO TRANSPORTADO EM REDE DEPACOTE 25flexível, pois tem o tempo virtual. A emulação tem o tempo real e acurácia aceitável em relaçãoaos ambientes reais. Dentre os simuladores de redes, o Network Simulator é bastante utilizadona literatura. Nos últimos anos, com o crescimento da virtualização, os emuladores, como oMininet passaram a ter grande utilização (LANTZ et al., 2010).

Um procedimento básico para identificar a qualidade de um vídeo é codificá-lo e, emseguida, decodificá-lo para avaliar o resultado final. Esse método foi um guia para determinaros avanços entre os padrões de vídeo. A métrica da taxa de distorção do vídeo correlaciona alargura de banda necessária para transportar certa qualidade do vídeo (SEELING et al., 2012).Essa taxa é interpretada para avaliar a eficiência em um codificador.

Ao longo da história dos codificadores, entre os objetivos a serem alcançados estavama redução da largura de banda ou bitrate em prol da melhor qualidade. Isso pode ser obser-vado pelos resultados dos codificadores padronizados pela ITU-T(H.261,H.263,H.264) e pelaISO(MPEG-1,MPEG-2,MPEG-4)(APOSTOLOPOULOS; TAN; WEE, 2002).

Esses codificadores possuíam algoritmos elaborados para atender as aplicações alvos.Com o crescimento da Internet, essa rede atraiu a atenção da indústria e da academia em utilizá-lacomo infraestrutura de entrega de conteúdo. Antes de definir o codificador a ser utilizado emuma aplicação, seria necessário avaliar a qualidade do vídeo recebido em clientes remotos.

A proposta de Klaue et al. (2003) cria o Evalvid, um dos primeiros frameworks utilizadospara a avaliação da qualidade do vídeo transportado em rede. Sua flexibilidade é notável porservir para teste, tanto para a rede real quanto para a simulada. Os padrões de vídeo que podemser utilizados são bem abrangentes tais como H.263, H.264 e MPEG-4, além de dar margempara testes de novos protocolos. Entre suas limitações encontra-se o fato de não atender ao vídeoescalável.

Kao et al. (2006), objetivando atender os dispositivos móveis, propõem um framework deavaliação, o qual procura simplificar em uma ferramenta o atendimento a profissionais de áreasdistintas que desejassem pesquisar o vídeo transportado em uma rede de computadores. Essesprofissionais abrangem tanto os especialistas em vídeo mais focados nas técnicas de codificaçãoe decodificação, quanto os espacialistas em rede que compreendem melhor as métricas de vazão,atraso e perdas de pacotes. Esse framework faz a integração da ferramenta Evalvid ao NetworkSimulator (NS-2). Esse novo framework, denominado myEvalvid-NT, emprega uma métricamais leve em termo de processamento para avaliar a qualidade do vídeo e propõe uma alternativaao PSNR pela taxa de frames decodificáveis para avaliar o vídeo recebido com possibilidade deperdas.

Lie et al. (2008) propõem o Evalvid-RA como um método de avaliação do vídeo, usandoo controle de congestionamento online para ajustar a taxa de transmissão do vídeo. O nível decongestionamento, reconhecido através de um canal de feedback, é motivado para aplicaçõesinterativas que devem reagir às condições da rede. Utiliza um modelo de vários traces deentrada com bitrates diferentes em função da taxa de quantização de vídeo, sendo isto necessáriopara executar o processo de adaptação da taxa de transmissão. Para avaliar a qualidade do

2.2. FERRAMENTAS DE AVALIAÇÃO DE VÍDEO TRANSPORTADO EM REDE DEPACOTE 26vídeo utiliza-se a métrica Mean Opinion Score (MOS) mapeada da métrica PSNR por herançadas ferramentas do Evalvid. Sua contribuição está em avaliar o streaming de mídia em redecongestionada e a adaptação da taxa durante a transmissão. Esse framework é gerado a partirdo Evalvid e o ambiente de simulação utilizado é o NS-2. Ele é bem aplicável para entregade multimídia em sistemas unicast. Em transmissões multicast, entretanto, é mais complexoexecutar isso com um canal de retorno. Demonstra-se, em experimento, que as métricas delargura de banda, as perdas de pacotes e o limite de atraso causam impacto relevante na qualidadedo vídeo para aplicações de videoconferência.

Detti et al. (2009) apresentam o Scalable Video-streaming Evaluation Framework(SVEF), que é voltado para a avaliação de vídeo H.264/SVC em redes IP. Embora estejamfocados em experimentações para rede sem fio, seus conceitos são bem aplicados em redecabeada. É motivado pelo fato do framework de codificação Joint Scalable Video Model (JSVM)ter dificuldade para recuperar o vídeo em redes que ofereçam perdas e entrega dos pacotes forade ordem ou, até mesmo, corrompidos. Dessa forma, ele insere um filtro que ocorre antes dadecodificação. Esse processo de filtragem permite a exclusão de frames dependentes do pacotebase ausente. É possível realizar a avaliação de desempenho com as métricas de PSNR e onúmero de frames perdidos.

Le et al. (2010) propõem o EvalSVC, que herda o modelo de transmissão do Evalvid,porém, apresenta limitações para a transmissão de alguns tipos de unidades NAL em razão danão padronização do processo de transmissão em pacotes Real-time Transport Protocol (RTP)pelo Internet Engineering Task Force (IETF). O framework pode ser utilizado em teste de redesreais tradicionais IP como a simulada no NS-2. A maior contribuição está na construção daferramenta Hinter, que acrescenta novas funcionalidade ao MP4Box, em aceitar o padrãoH.264/SVC, assim como o SVC-Re-builder, que reconstrói o bitstream SVC no nó receptor.O framework não explora a opção de trabalhar em nível de pacote IP manipulando o campo ToS.

Ke (2012) agrega o SVEF ao simulador NS-2. Esse novo framework, denominadomyEvalSVC, tem por objetivo a avaliar o vídeo H.264/SVC em redes sem fio. Esse frameworkprocura ser simples ao inserir o pesquisador iniciante em teste através da disponibilidade demáquina virtual com todas as ferramentas necessárias, assim como busca melhorar o frameworkEvalSVC ao tratar os problemas dos pacotes corrompidos agregando as funcionalidades do SVEF.Entretanto, é eficaz para a escalabilidade temporal em redes simuladas. As outras escalabilidades,ou seja, espacial e qualidade, não são tratada.

Por fim, Castellanos et al. (2017), ao implementarem o SVCEval-RA constroem umambiente adaptativo controlando a taxa de transmissão. Esse framework procura acrescentarmelhorias aos frameworks myEvalSVC e EvalSVC, assim como aborda a escalabilidade de tempoe qualidade. Ele foi testado no simulador de rede NS-2. O processo de adaptação da taxa é eficazde acordo com a flutuação do congestionamento. Dessa forma, foi expressivo o nível de reduçãode perda dos pacotes comparado à solução sem a mesma técnica de adaptação. Os experimentosnão abordam a escalabilidade espacial e é focada para transmissão ponto-a-ponto.

2.3. STREAMING DE VÍDEO EM SDN 27

Um novo ambiente de experimentação, denominado Mininet, surgiu, e assim, facilitou osexperimentos e a inovação. O Mininet proposto por Lantz et al. (2010) tem um forte propósito dehabilitar a implementação de ambiente de teste para SDN usando um notebook como laboratório.O emulador Mininet é simples e muito utilizado nos ambientes acadêmicos por oferecer rapidezna implementação dos testes. Sua estrutura é tão flexível que permite, ainda criar a própriaestrutura da Internet dando margem à criação de protótipo de migração entre a Internet tradicionalIP e as redes SDN.

De modo geral, as ferramentas estudadas estão mais focadas para os ambientes desimulação NS-2, embora algumas permitam alternar para o ambiente real. Nos testes escaláveisutilizando o vídeo H.264/SVC é mais abrangente a utilização das escalabilidades de tempo equalidade, sendo que a escalabilidade espacial não foi abordada. Isso indica um desafio trabalharcom essa escalabilidade.

A escolha do Mininet como ambiente de teste, de acordo com as orientações de Seelinget al. (2012), pode apresentar os resultados promissores nos testes de avaliação do vídeo baseadoem trace. Essa dissertação aborda o Evalvid para a avaliação do vídeo não escalável H.264/AVCagregando interfaces para o mininet, assim como aborda as ferramentas do SVEF e myEvalSVCpara o tratamento do vídeo escalável enfatizando a escalabilidade espacial.

2.3 STREAMING DE VÍDEO EM SDN

Uma das melhorias alcançada pelo SDN está o avanço do gerenciamento da rede ediferentes maneiras de se trabalhar com o QoS. As aplicações que podem ser beneficiadas comisso são inúmeras, entres elas se destacam as aplicações de streaming de vídeos, Voice overInternet Protocol (VoIP) e jogos online.

Egilmez et al. (2012) propõem um novo modelo QoS baseado nos conceitos trazidospelo Openflow e controladores distribuídos para rede de grande porte. As métricas utilizadaspara encontrar as melhores rotas são baseadas nos status da rede que envolvem delay, perdas depacotes e jitter junto com o nível de congestionamento que serve como entrada para o cálculodas melhores rotas. Nos experimentos em um testbed envolvendo três switches Openflow, estatécnica mostrou ser mais eficiente em relação às propostas de QoS tradicionais, como IntServe DiffServ. Utilizou-se um grupo de stream de vídeo single layer para transmissão em UserDatagram Protocol (UDP)/RTP, assim como o Hypertext Transfer Protocol (HTTP)-DASH. Obom funcionamento deste só se evidencia em redes multipath no caminho da origem ao destino,usando apenas as conexões em unicast.

Em outro trabalho, Egilmez et al. (2011) fazem uma abordagem da utilização do vídeoescalável H.264/SVC. A qualidade do vídeo é baseada na métrica objetiva PSNR. A técnica deroteamento adotada é sensível ao estado de congestionamento da rede. A solução SDN consegueobter essa informação a ponto de rerrotear a camada base em rotas livres desse problema porém,mais longas em número de saltos. As camadas superiores do vídeo escalável denominadas


camada de enriquecimento, seguem na rota de caminhos mais curtos e congestionados. Oobjetivo é entregar a qualidade mínima sem perdas da sequência do vídeo. Os resultadosmostraram que soluções de streaming com SDN e vídeo escalável H.264/SVC produziramresultados significativos.

Seguindo essa mesma linha de raciocínio, Yu et al. (2015) propõem uma solução QoSem SDN para vídeo escaláveis, possibilitando o rerroteamento para o fluxo das camadas deenriquecimento. Essa situação ocorre quando o caminho alternativo não tem largura de bandasuficiente para transportar a camada base. Nesse caso, a camada de enriquecimento irá pela rotamais longa. Por um lado, isso é vantajoso, uma vez que a camada base se mantém no caminho demenor custo. No caminho factível onde os outros pacotes serão enviados não há necessidade degarantia se os mesmos chegarão ao destino. As vantagens em relação ao OpenQos (EGILMEZ etal., 2012) só é vista a nível de baixas perdas de pacotes e melhorias no PSNR. Porém, esses testessão executados em ambientes simulados e não têm muita descrição sobre o tipo de escalabilidadeutilizada.

Por outro lado, Ongaro et al. (2015) procuram garantir o QoS/QoE através de umaproposta de orquestração da rede com SDN. Essa abordagem abrange a transmissão dos sistemasmultimídias usando o Openflow em redes cabeada e sem fio. O tráfego de concorrência éformado pelo Iperf que, estrategicamente, percorre caminhos que coincidem com os de tráfegodo vídeo em estudo. O algoritmo proposto executa cálculos de rotas, tendo como entrada osdados referentes no nível de perdas e atrasos dos pacotes de vídeos. Com base nesse critério,as melhores rotas são selecionadas. Utilizou-se, nesse caso, um vídeo em camada única doservidor de streamer. O fator comparativo é uma rede tradicional que não utiliza o QoS. Torna-seevidente, inclusive, que necessita de múltiplas rotas na rede para o bom desempenho da proposta.

Já Yang et al. (2014) propõem uma arquitetura Openflow, onde o vídeo escalávelH.264/SVC é transportado em multicast. Neste trabalho, o controlador POX foi utilizadopara a construção dos módulos dos experimentos. Cada camada SVC é transmitida em gruposmulticast separados. Os clientes assinam as camadas de acordo com as suas requisições. Noscenários foram utilizados os vídeos de escalabilidade espacial para atenderem os clientes comrequisição de capacidades diferentes. Os resultados mostraram a redução do tráfego em trânsitocom grande número de usuários. Porém, não foi abordada a questão do atraso visando umaaplicação interativa e, tampouco, um tráfego de congestionamento para averiguar a qualidade dovídeo entregue.

Zhao et al. (2014) propuseram um algoritmo de roteamento para o ambiente de video-conferência multiparty utilizando o multicast IP em redes SDN, fazendo um comparativo comos sistemas de videoconferência tradicionais baseados em MCU. A adaptação de bitrate ocorrenos transmissores fontes das árvores multicast, reduzindo a taxa de transmissão em ocorrênciade congestionamento ou rerroteando e alterando a taxa de transmissão. O ambiente proposto éaplicável a vídeo não escalável.

Yang et al. (2016) sugerem um sistema de videoconferência utilizando o vídeo escalável


H.264/SVC em um ambiente real. Sua estratégia relevante em caso de congestionamento é aremoção das camadas superiores de acordo com a disponibilidade de largura de banda, reduzindo,dessa forma, o número de perdas. Uma estrutura de sinalização e controladores de sessões devideoconferência é utilizada e um gerador de tráfego variável baseado na ferramenta Ostinato éaplicado.

O trabalho de Yang et al. (2016) é uma extensão do de Zhao et al. (2014), porém, em umambiente de aplicação mais realístico. Zhao et al. (2014) são uma patente e sua contribuiçãoestá no algoritmo de gerenciamento de conflitos de rotas em enlaces congestionados, vistoque possuem restrições de largura de banda e atraso. Essas informações são relevantes paraa construção do custo da rota dinamicamente. Yang et al. (2016) já utilizam um testbed maissimples de replicar, pois usa 16 switches comuns baseados em OpenWRT e executados em umambiente escolar, além de apresentarem uma solução SDN customizada. Ressalta-se que oscustos de rotas não foram levados em consideração.

As avaliações de desempenho dos sistemas de videoconferência das propostas de Yanget al. (2016) e Zhao et al. (2014) mostram-se eficientes em redes com muita densidade de rotas.Porém, deixam em aberto, a caracterização do comportamento em redes SDN em ambientes derotas únicas ou com poucos caminhos.

303030

3REFERENCIAL TEÓRICO

Os conceitos os quais se baseiam esta dissertação são descritos neste capítulo. A compre-ensão de um sistema de videoconferência, bem como as tecnologias envolvidas em sua utilizaçãoforam abordados. As vantagens proporcionadas pelo uso do vídeo escalável são detalhados.O paradigma SDN e o funcionamento das redes Openflow ganham destaque. O processo paraexecução de avaliação de desempenho e as principais métricas envolvidas são relacionadas.

3.1 VIDEOCONFERÊNCIA

Em 1960, os primeiros sistemas de videoconferência já eram realidade, porém, o altocusto envolvido na operação restringia o número de acesso de usuários (VOLFIN; COHEN,2013). Com o passar do tempo, a evolução tecnológica reduziu o custos, tanto a nível de rede,quanto em poder de processamento de vídeo, tornando-a acessível a todos os usuários comrecursos mínimos em seus dispositivos.

A ITU-T foi o primeiro órgão que padronizou o processo de comunicação de videocon-ferência através do protocolo H.320. Esse protocolo é um conjunto de recomendações paraoperações de videoconferência na redes de telefonia e Integrated Service Digital Network (ISDN).Nessas redes, o QoS era garantido e a largura de banda variava de 64Kbps a 1,92Mbps. Nessaépoca, também, começou a ser utilizado o primeiro padrão de vídeo H.261 (SUN; VETRO; XIN,2007).

Com a popularização da Internet, a ITU-T percebeu a necessidade de integrar os sistemasde videoconferência às redes Transmission Control Protocol (TCP)/IP. Dessa forma, surgiu oframework H.323 para atender a essa demanda sem perder a compatibilidade com as redes jásupridas pelo protocolo H.320. Como a Internet não oferece QoS, um novo padrão de vídeoH.263 (um H.261 melhorado) foi implementado para suportar a largura de banda menor que64Kbps assim como maiores que 2Mbps.

Por outro lado, o IETF montou um grupo de trabalho que se dedicou à construção deum padrão para comunicação multimídia focado em voz e vídeo sobre o IP, criando, assim, oprotocolo Session Initiation Protocol (SIP), o qual foi fundado para funcionar exclusivamente naredes de pacotes. Assim, os sistemas atuais de videoconferência trabalham tanto com o protocolo

3.1. VIDEOCONFERÊNCIA 31

H.323, quanto com SIP. Porém, esse protocolos não conversam diretamente entre si, precisamde um gateway para intermediar o processo.

Em sua essência, videoconferência é um sistema de comunicação interativa com afinalidade de viabilizar reuniões em tempo real entre três ou mais usuários remotos, geralmenteenvolvendo áudio, vídeo e, até mesmo, texto. É um serviço que requer alta largura de bandae baixo atraso (ZHAO et al., 2014). Compõem-se de três funções bem definidas: sinalização,mídia e controle. O fluxo de sinalização é necessário para estabelecer a comunicação, negociaros codecs, coletar as características dos participantes, entre outros. O fluxo de mídia habilitao tráfego de áudio e vídeo. A função de controle é necessária para se fazer os controles deacesso, reconhecer a presença de congestionamento na rede, tomar a decisão de repasse, além dapossibilidade de executar a transcodificação.

Entre os recursos de mídia, o áudio é um recurso de baixa largura de banda que conduz asreuniões, visto que define quem está desempenhando o papel de palestrante. Existem algoritmosque cumprem esse papel em descobrir o palestrante automaticamente (VOLFIN; COHEN, 2013).

O nível satisfatório de qualidade do vídeo entregue é o requisito crítico que os sistemasde videoconferência buscam atender. O vídeo é um fator muito importante, pois apresenta umconsumo de largura de banda muito superior em relação aos outros fluxos, como por exemplo, ode áudio. Essas mídias são transmitidas em conexões independentes com o protocolo RTP.

Figura 3.1: Sistema de videoconferência tradicional (ZHAO et al., 2014)

Controlador de Mídia MCU

Usuário_1

Usuário_2

Usuário_3

Sinalização entre Usuário e o Controlador de Mídia

Sinalização entre a MCU e o Controlador de Mídia

Enlaces entres Switches e Usuários

Fluxo de tráfego originado do Usuário_1 transmitido para os outros usuários na sessão

Switch

A Figura 3.1 mostra um modelo clássico desse sistema baseado em arquitetura centrali-zada. Todos os usuários antes de transmitir o vídeo precisam se autenticar e ter acesso a uma salavirtual onde todos possam se comunicar. Quando processo de transmissão de mídia se inicia,todos os usuários transmitem para o nó servidor que é representado pelo MCU que, por sua vez,repassam aos demais clientes.

Os usuários executam a transmissão em um modelo conhecido publish/subscribe, ondecada participante publica seus conteúdo na rede e os demais assinam quais stream de vídeo desejareceber. O servidor MCU trata essa função de repasse além de poder executar outras atividadescomo transcodificação e mixagem. A transcodificação acontece quando o vídeo necessita ser

3.2. VÍDEO ESCALÁVEL 32

modificado em outro formato para atender os requisitos do usuário. No caso da mixagem, váriasconexões de saída para um usuário pode ser reduzida a uma. Dessa forma, o MCU é o elementocrítico desse sistema. Ele é utilizado para aliviar a carga nos usuários. Em função disso, onúmero de conexões que são estabelecidas crescem quadraticamente a cada usuário de se juntaao serviço. Nessa situação, as demandas por recursos de processamento, memória e largurade banda cresce proporcionalmente. Em consequência disso, o tipo de MCU utilizado pelosistemas de videoconferência é quem limita o número de usuário que o sistema pode suportar(RODRÍGUEZ et al., 2016).

Esse problema de escalabilidade é mais observável em sistemas que utilizam uma únicaMCU. O fato da MCU ser o elemento da rede mais importante é também o único ponto defalha. Se ele falhar todo o sistema cai. Além desse problema de escalabilidade, o excessode transcodificação é um dos principais responsáveis pela aumento do atraso nesses sistemas.Como os sistemas de videoconferências tem restrição de atraso, uma saída para o problema é autilização do serviço na computação em nuvens. Os requisitos de robustez e o número de MCUsobe demanda é uma característica que pode ser bem atendida. A grande desvantagens pode sero custo a ser pago por esse benefício.

Por outro lado, existe a proposta de arquitetura descentralizada através das soluçõesP2P que oferecem mais recursos quanto mais usuários estiverem presente. Acontece que umprotocolo de gerenciamento desses sistemas é muito complexo. Por outro lado, a abordagemdo sistemas P2P em arquitetura mista onde o papel do MCU volta a ser necessário, explica osucesso das principais aplicações de videoconferência atualmente como iChat, Skype e Hangout(XU et al., 2012).

A maioria das sistemas de videoconferência transmitem os vídeos em modo não escalável.A migração para o uso do vídeo escalável é uma ótima vantagem para aliviar a carga nas MCUe melhora o desempenho do sistemas. A grande vantagem disso é o fato da MCU somenterepassar as camadas conforme as demandas do clientes. Dessa forma, é possível melhorar aescalabilidade dos modelos já existente.

3.2 VÍDEO ESCALÁVEL

No processo de coleta de imagens coloridas, ela são capturadas no sistema Red GreenBlue (RGB) e, posteriormente, convertidas para o sistema de cores YCbCr ou YUV (APOS-TOLOPOULOS; TAN; WEE, 2002). Dentre as componentes de cores, a Y, que representa aluminosidade, é mais sensível ao olho humano do que as demais (Cb e Cr). Baseado nessacaracterística, construiu-se a métrica objetiva de qualidade de vídeo PSNR.

Uma vez que as imagens ou frames foram convertidas para o sistema de cores YUV, elasjá se encontram habilitadas para o processo de codificação. Um frame pode ser codificado emum dos três tipos de formatos: I (Intracodificado) , P (Preditivo) e B (Bipreditivo). Os formatosIntracodificado ou do tipo I são codificado independentemente dos outro frames. Já os Preditivos


ou do tipo P são gerados da diferença da cena anterior, ou seja, coleta os vetores de movimento.Por fim, os Bipreditivos ou do tipo B são originados da diferença das informações coletadasde uma imagem anterior à sua exibição e de uma imagem futura. A Figura 3.2 esclarece essesconceitos através das direções das setas.

A sequência desses tipos de frames gera um vídeo codificado, conhecido como bitstream,que, por sua vez, é muito relevante para a definição da performance do streaming do vídeo.Normalmente, os frames se organizam em uma estrutura denominada Group of Images (GoP),que caracteriza-se por ser uma sequência cíclica de um conjunto de frames iniciado pelos framesdo tipo I dentro de um vídeo (AUWERA; DAVID; REISSLEIN, 2008). Isso significa que osframes do tipo I são os mais importantes em relação aos tipos P e B. A Figura 3.2 mostra umexemplo de GoP que, de acordo com os conceitos dessa estrutura, encontra-se no formato G8B2.Isso quer dizer que um frame do tipo I se repete a cada sequência de 8 frames. Desses 8 frames,encontram-se blocos de sequência de 2 frames do tipo B seguidos que serão intercalados pelosframes do tipo P ou I. Os frames tipos P, implicitamente não manifestados na descrição do GoP,entram quando o ciclo de frames B se completa e o frame seguinte não é do tipo I.

A escalabilidade está fortemente relacionado a estruturação hierárquicas desses tipos deframes. A principal mudança foi a definição da nova funcionalidade inserida ao frames do tipo Bque podem gerar outros do mesmo tipo (SCHWARZ et al., 2007).

Figura 3.2: Definição de Group of Images (GoP) (APOSTOLOPOULOS; TAN; WEE, 2002)

Os padrões internacionais anteriores ao H.264, que compreendem o H.262 (MPEG-2),H.263 e MPEG-4, já possuíam as ferramentas para implementar a escalabilidade. Porém, osperfis escaláveis desses padrões acrescentavam significantes perdas na eficiência da codificação,bem como o aumento na complexidade do decodificador quando comparado aos perfis nãoescaláveis. Para tratar esse problema, o grupo Video Coding Experts Groups (VCEG) da ITU-Tuniu-se com o grupo Moving Picture Experts Group (MPEG) da ISO/IEC e formaram a JointVideo Team (JVT) (SCHWARZ et al., 2007) produzindo a extensão escalável do H.264/AVC.

O objetivo da junta era unir os maiores especialistas para implementar e/ou melhorara proposta escolhida de escalabilidade para o padrão H.264/AVC. O resultado foi um codecpromissor, que obteve um desempenho a níveis aceitáveis. Para fins de divulgação, o ITU-T


chamou essa extensão de H.264/SVC, enquanto que ISO/IEC divulgou com o nome de MPEG-4parte-10.

O H.264/SVC é um codec de vídeo em camadas que codifica o vídeo em uma camadabase e uma ou mais camadas de enriquecimento de modo hierárquico. Ao receber a camada base,o cliente pode decodificá-la com baixa qualidade, porém, caso receba as camadas superiores, ovídeo terá uma qualidade ainda maior. Além disso, a eficiência de codificação e a complexidadena decodificação é similar ao H.264/AVC (WIEN et al., 2007).

Um dos objetivos do H.264/SVC é o atendimento de dispositivos heterogêneos em umarede de capacidade de links diferentes para o recebimento do vídeo em uma mesma sessãoonline das aplicações. Aplicações consumidoras desse tipo de vídeo, como a videoconferência,poderiam tirar bom proveito disso diante da heterogeneidade. Isso mudaria a forma tradicionalde tratar esse problema sem o método simulcast, o qual consiste em transmitir diferentes versõesindependentes do mesmo vídeo para usuários diferentes. Ao contrário disso, as vantagens comH.264/SVC reduziria a uma conexão para transportar diferentes versões do mesmo vídeo.

Pela melhoria evolucionária em trazer dentro de um bitsream várias versões de um mesmovídeo, torna-se uma economia para o armazenamento e largura de banda quando comparado aosimulcast. A Figura 3.3 mostra um exemplos representativo, onde, em uma transmissão paraatender três clientes com diferentes resoluções de vídeo, o H.264/SVC consumiria menos largurade banda para atender esses usuários. Nas soluções em simulcast cada camada H.264/SVCcorresponde a uma versão independente, ou seja, completa de cada vídeo. Nessas circunstância,a fonte necessitaria mais do 1,5Mbps do necessário para solução em H.264/SVC.

Figura 3.3: Relação Simulcast versus SVC (HUSEMANN, 2011)

500 kbps

Fluxo 3

Fluxo 2

Fluxo 1

Video 1

Video 2

Video 3

500 kbps

500 kbpsCamada 1

Camada 2

Camada 3

Video 1

Vídeo 3Vídeo 2 + Camada 3

Video 2Vídeo 1 + Camada 2

Vídeo 3800x600

Vídeo 2640x480

Vídeo 1320x240

Banda total500k + 1M + 2M = 3,5Mbps

Banda total500k + 500k + 1M = 2Mbps

(a) Simulcast (b) SVC

Por ser uma codificação estendida do H.264/AVC, somente a camada base do vídeoH.264/SVC encontra-se no formato não escalável H.264/AVC. Esse mecanismo possibilita ao


vídeo escalável ser compatível com os decodificadores não escaláveis. Isso permite que disposi-tivos não escaláveis decodifiquem somente a camada base quando receberem o vídeo escalável.Além disso, o conceito de escalabilidade é operável. Ser escalável, nessas circunstâncias, estárelacionado com a possibilidade de se descartar as camadas superiores para se adequar a largurade banda ou a capacidade de processamento do cliente. Esse processo adaptativo tem o potencialpara ocorrer de maneira suave gerando a percepção de boa qualidade de vídeo.

O vídeo escalável H.264/SVC é ideal para redes inteligentes que utilizam o mecanismode priorização. O vídeo H.264/SVC é construído em camadas, onde a camada base é a maisimportante, pois é responsável gerar as demais. A priorização aplicada, preferencialmente, àcamada base, daria uma melhor resiliência a perdas. Para construir as camadas escaláveis noH.264/SVC, os cabeçalhos das unidades NAL H.264/AVC sofreram um acréscimo de três bytes.Isso foi necessário para se inserir nos cabeçalhos das novas unidades NAL as referências deescalabilidade temporal, espacial e de qualidade ao qual o pacote pertence.

3.2.1 Escalabilidade Temporal

A escalabilidade temporal representa o bitstream do vídeo original em diferentes taxas.A organização dessas taxas cria camadas que estão relacionada a adaptação da frequência deframes de um vídeo na escala de tempo. Essa métrica é expressa em frames por segundo (fps).Um exemplo representativo seria um vídeo convencional contendo uma taxa de 30fps codificadocom H.264/SVC em três camadas temporais. O resultado seria um bitstream de vídeo escalávelcom as taxas de 30fps, 15fps e 7.5fps. Cada uma dessas camadas estaria disponíveis para atenderum tipo de cliente diferente simultaneamente.

3.2.2 Escalabilidade Espacial

As camadas espaciais estão relacionados com a resolução do visor dos dispositivos querecebem um vídeo. Desse modo, um mesmo bitstream, que é um vídeo codificado, pode estarestruturado de forma a portar frames de diferentes resoluções de tela. Por exemplo, uma camadabase pode conter um vídeo com resolução QCIF de 176x144 pixels e a camada de enriquecimentoter uma CIF de 352x288 pixels de resolução. No conceito de escalabilidade, o vídeo de resoluçãomaior é dependente da resolução menor.

3.2.3 Escalabilidade de Qualidade

A escalabilidade de qualidade está relacionada com a fidelidade de uma imagem paracada combinação espaço-tempo de um vídeo. O bitrate é a métrica que expressa seu nível defidelidade, que varia de acordo com o valor da quantização Quantization Parameter (QP) paracada frame.

Os algoritmos que manipulam a escalabilidade de qualidade utilizado no H.264/SVC sãoCoarse Grain Scalability (CGS) e o Medium Grain Scalability (MGS) (SEELING et al., 2012).

3.3. PARADIGMA SDN 36

Embora muito semelhantes aos algoritmos para escalabilidade espacial, há a diferença de quenão existe a ampliação ou redução da resolução entre as camadas. O CGS possibilita construiraté oito camadas de qualidade, enquanto o MGS dobra esse número de camadas.

3.3 PARADIGMA SDN

As redes tradicionais IP são amplamente adotadas. A arquitetura distribuída foi essencialpara o seu crescimento. Porém, com o passar do tempo, novas aplicações/serviços provocarammudanças no domínio da arquitetura cliente/servidor. Serviços como virtualização de datacen-ters, provedores de cloud e aplicações para celulares mudaram o padrão de tráfego inserindonecessidades dinâmicas às redes (FOUNDATION, 2012b). As dificuldades para atender as novasdemandas fizeram com que as redes tradicionais IP oferecessem resistência para a inovação. Umfator impactante é o fato de que as redes tradicionais IP têm os planos de controle e de dadosacoplados ao mesmo dispositivo, seja um switch ou roteador.

A infraestrutura SDN é similar às redes tradicionais. Os switches SDN podem estar nomesmo ambiente dos switches das redes tradicionais. A adoção de maneira gradativa sem rupturanas redes tradicionais IP foi uma das características que impulsionaram o sucesso do Openflow.

Uma das mudanças introduzidas pelo SDN foi que a decisão de encaminhamento ébaseada no fluxo e não no endereço de destino, como acontece nas redes tradicionais IP. Oconceito de fluxo está relacionado com os campos pertencentes aos pacotes que servem de filtropara receber ações. O tratamento do fluxo possibilita a programação sem precedentes do tráfego,e estando limitado a capacidade das tabelas implementadas nos switches/roteadores (KREUTZet al., 2015).

SDN é um paradigma de rede emergente que traz esperança de mudanças para aslimitações das redes tradicionais IP (KREUTZ et al., 2015). Uma visão simplificada dessaarquitetura é mostrada na Figura 3.4. Sua essência principal está na separação do plano decontrole dos planos de dados dos dispositivos de encaminhamento dos dados.

Como demonstrado na Figura 3.4, a arquitetura SDN contém cinco elementos funda-mentais: a infraestrutura da rede composta pelos elementos de encaminhamento, interfaceSouthbound, plataforma de controle, interface Northbound e aplicações de rede. Os elementosde encaminhamento compreendem os switches, roteadores e access points. A remoção do planode controle desses elementos, os tornaram simples encaminhadores de pacotes. A vantagem, éque esses elementos executam os mesmos trabalhos, porém, com menos processamento, o queprovocou uma redução no seu custo.

A interface Southbound Application Programming Interface (API) define o conjunto deinstruções a ser instalada nos dispositivos de encaminhamento. Além disso, também define oprotocolo de comunicação entre o plano de controle e o plano de dado

Documents

Francisco Janiel de Oliveira · 2019. 10. 26. · Francisco Janiel de Oliveira AVALIAÇÃO DE DESEMPENHO DE VIDEOCONFERÊNCIA EM REDES SDN/OPENFLOW USANDO VÍDEO ESCALÁVEL Trabalho