Modelagem de requisitos de rede para uma plataforma hibrida IPTV e OTT rev018

RUTH ANGELINA MARTINS

REQUISITOS PARA PLATAFORMAS HÍBRIDAS IPTV e OTT

São Paulo

2015

2

RUTH ANGELINA MARTINS

REQUISITOS PARA PLATAFORMAS HÍBRIDAS IPTV e OTT

São Paulo

2015

3

RUTH ANGELINA MARTINS

REQUISITOS PARA PLATAFORMAS HÍBRIDA IPTV e OTT

Trabalho de conclusão de curso de Pós-Graduação do Laboratório de arquitetura de rede de computadores de Universidade de São Paulo para obtenção do título de MBA.

Área de Concentração:

Orientador: Reinaldo Matushima

São Paulo

2015

4

RESUMO

O trabalho a ser apresentado é uma proposta de definição de requisitos a serem

considerados para expansão implantação de uma plataforma IPTV para serviços

híbridos a de serviços IPTV e OTT. A motivação do trabalho é devido à grande

convergência de serviços multimídia que o mercado vem apresentando nos últimos

anos. Na década passada havia uma pequena demanda de serviços de vídeo.

Contudo, tem-se verificado um crescimento exponencial do trafego de serviços de

vídeo, voz e dados. Inicialmente será descrito a infraestrutura necessária para compor

os serviços de multimídia em questão, isto é, desde geradoras de conteúdo até a

recepção do sinal. Após o conhecimento das arquiteturas para os serviços IPTV e OTT,

serão apresentados os mecanismos e técnicas para garantir a melhor eficiência numa

plataforma híbrida de serviços multimídias. A verificação da importância dos requisitos

levantados será realizada através da apresentação de alguns casos de uso.

Palavras-chave: IPTV, OTT, plataformas híbridas, serviços multimídia, requisitos.

5

ABSTRACT

The work herein presented is a proposal for the establishment of requirements to be

considered for the expansion deployment of IPTV service to ana hybrid platform

includingfor IPTV and OTT services. The motivation of the work is due to the large

convergence of multimedia services that the market has shown in recent years. In the

past decade, there was a small demand for video services. However, there has been an

exponential growth of video traffic, voice and data. Initially, the necessary infrastructure

required to provide multimedia services will be described, that is, from content

generation to the reception. After that, the knowledge of architectures for IPTV and OTT

services, mechanisms and techniques will be presented to ensure the best efficiency in

a hybrid platform for multimedia services. The findings on the importance of the

requirements identified will be carried out by presenting use cases.

Keywords: IPTV, OTT, hybrid platforms, multimedia services, requirements.

6

LISTA DE FIGURAS

Figura 1 - Diagrama IPTV (http://www.bogotobogo.com/WebTechnologies/ipTV.php)

........................................................................................................................ 1413

Figura 2 - Arquitetura IPTV convergente ................................................................. 1615

Figura 3 - Arquitetura STB (http://www.knowcrazy.com/2011/05/set-top-

box.html#.VDMt3Gdhd1Z) ................................................................................ 2019

Figura 4 - Arquitetura CDN [7] ................................................................................ 2322

Figura 5 - CDN Peering - (Vitor M.J Silva, 2013 – Service Building in dense Service

Provider Environments) .................................................................................... 2524

Figura 6 - CDN híbrida combinação CDN + P2P

(http://www.forcetech.net/en/product/server_p2p.html)...................................... 2625

Figura 7 - Arquitetura Híbrida com CDN em Nuvem e Provedores de Conteúdo [11] 2726

Figura 8 - CDN peering Akamai – (http://pt.slideshare.net/suerudd/cdn-ws-

operatorspperspectives1630june-27th2013suerudd, acesso 06, fev.2015) ........ 3231

Field Code Changed

Field Code Changed

7

LISTA DE ABREVIATURAS E SIGLAS

API Application Program Interface

AWS Amazon Web Services

BRAS Broadband Remote Access Server

CAS Content Authority System

CC Close Caption

CDN Content Distribution Networking

DASH Dynamic Adaptive Streaming over HTTP

DRM Digital Rights Management

DVB-S/S2 Digital Video Broadcasting over Satellite

DVR Digital Video Recorder

EPG Electronic Program Guide

FTTH Fiber To The Home

HD High Definition

HDD Hard Disk Drive

HDS HTTP Dynamic Streaming

HEVC High Efficiency Video Coding

HFC Hybrid Fiber Coax

HLS HTTP Live Streaming

HTTP Hypertext Transfer Protocol

IP Internet Protocol

IPTV Internet Protocol Television

ISDB-Tb Integrated Services Digital Broadcasting Terrestrial Brazil

ISP Internet Service Provider

MOS Mean Opinion Score

MPEG Moving Pictures Expert Group

MSAN Multi-Service Access Node

NDVR Network Digital Video Recorder

Comment [RM1]: Revisar todas as sglas para ver se estão na lista e depois acertar a ordem alfabética!!

Formatted: Portuguese (Brazil)

8

ONT Optical Network Terminal

OTT Over The Top

PPV Pay-Per-View

PSNR Peak Signal to Noise Ratio

RTMP Real Time Messaging Protocol

RTOS Real Time Operation System

RTSP Real Time Streaming Protocol

P2P Peer-to-Peer

QoE Quality of Experience

QoS Quality of Service

SDI Serial Digital Interface

STB Set-Top-Box

TCP Transmission Control Protocol

TIC Transparent Internet Caching

UDP User Datagram Protocol

UHF Ultra High Frequency

UI User Interface

VCAS Video Content Authority System

VoD Video on Demand

VHF Very High Frequency

9

SUMÁRIO

LISTA DE FIGURAS .......................................................................................... 6

LISTA DE ABREVIATURAS E SIGLAS ............................................................. 7

INTRODUÇÃO ....................................................................................... 1012 1

1.1 ORGANIZAÇÃO DO DOCUMENTO .................................................... 1113

ELEMENTOS CHAVES DE ARQUITETURAS IPTV E OTT .................... 1315 2

2.1 IPTV .................................................................................................... 1315

2.2 OTT ..................................................................................................... 1416

2.3 PLATAFORMA HÍBRIDA .................................................................... 1517

2.3.1 Headend ......................................................................................... 1517

2.3.2 Recepção ........................................................................................ 1921

MODELAGEM DE REQUISITOS DE UMA ARQUITETURA HÍBRIDA.... 2224 3

3.1 CDN .................................................................................................... 2224

3.2 SERVIÇO DE CACHE DE INTERNET ................................................. 2729

3.3 QoE e QoS .......................................................................................... 2830

3.4 HLS ..................................................................................................... 3032

3.5 OUTROS REQUISITOS ....................................................................... 3133

AVALIAÇÃO .......................................................................................... 3234 4

4.1 AKAMAI E AMAZON ........................................................................... 3234

4.2 ANÁLISE ............................................................................................. 3335

CONSIDERAÇÕES FINAIS.................................................................... 3638 5

5.1 TRABALHOS FUTUROS ..................................................................... 3638

REFERÊNCIAS ........................................................................................... 3739

Formatted: English (U.S.)

Formatted: Justified, Space After: 9pt, Line spacing: single

10

INTRODUÇÃO 1

Este trabalho contempla o processo de expansão para transmissão e distribuição de

sinais multimídia de um ambiente controlado e gerenciado IPTV, para uma

implementação de serviços OTT. O objetivo é aproveitar toda a infraestrutura e

equipamentos previamente utilizados para o serviço IPTV. Ou seja, fazer uso o máximo

possível do grande investimento realizado no legado IPTV existente.

A grande motivação das operadoras de telecomunicações e TV para iniciarem a

preparação de suas plataformas com o objetivo de suportar serviços coexistentes IPTV

e OTT é aumentar a participação de mercado, isto é, aumento da base de clientes

somando legado IPTV e novos clientes OTT. Ou sobre um outro viés, minimizar a perda

de mercado decorrente do grande avanço dos serviços OTT.

Para este cenário de ampliação de escopo, considera-se um processo de incorporação

ao legado IPTV de novos equipamentos que viabilizem o suporte a serviços OTT,

compondo assim uma solução híbrida que atenda assim tanto IPTV como OTT.

Os serviços IPTV e OTT necessitam de tratamentos distintos para geração ,

transmissão e distribuição de sinais multimídia. Neste cenário de migraçãoexpansão, é

necessário consideraremos uma Este trabalho considera o cenário de transmissão e

distribuição de sinal de vídeo sobre IP com uma visão futura de redes de comunicação

de dados que agregam serviços de IPTV e OTT, ou seja, uuma rede híbrida para

tráfegos multimídia que possam apresentar tratamentos diferenciados para cada fluxo..

Neste contexto, o trabalho se propõe a apresentar um projeto de requisitos de rede e

componentes adicionais para o legado IPTV visando compor uma arquitetura que

atenda adequadamente a um cenário híbrido.

Formatted: Highlight

Comment [RM2]: Visao futura? Por que o mesmo provedor iria oferecer os dois serviços?

11

1.1 ORGANIZAÇÃO DO DOCUMENTO

O capítulo corrente apresenta a justificativa para a realização do trabalho, isto é, com a

grande demanda de conteúdos de vídeo sob demanda, o cenário atual é caracterizado

por operadoras de IPTV, que não estão conseguindo responder a esta mudança de

comportamento de consumo. O mercado está passando por uma fase de necessidade

de mudanças.

Este trabalho foca em requisitos que as operadoras de IPTV precisam estar atentas

para se posicionar diante deste novo cenário, no entanto, não é possível fazer esta

análise sem deixar de explorar questões mais amplas.

Desta forma, é feita uma análise sob diversos aspectos, desde o processamento de

sinais no headend, até a recepção do sinal para o usuário. Neste sentido, o capítulo 2

apresenta inicialmente de forma sucinta os componentes principais de serviços IPTV e

OTT, para em seguida apresentar o que seriam requisitos de componentes para uma

plataforma híbrida.

Dando continuidade, o capítulo 3 passa da visão de componentes, para uma análise

focada sob o viés da rede. São apresentadas, entre outras coisas, tecnologias de

distribuição de conteúdos que se mostram mais adequadas para cenários híbridos.

O capítulo 4 em seguida apresenta exemplos de serviços que são oferecidos pelo

mercado e que podem ser exploradas pelas empresas de forma a viabilizar a

composição de uma plataforma híbrida. Finalizando, o capítulo 5 apresenta as

considerações finais e possíveis evoluções do trabalho realizado.

12

.

13

ELEMENTOS CHAVES DE ARQUITETURAS IPTV E OTT 2

O consumo de vídeos via IP (Internet Protocol) vem aumentando consideravelmente na

forma de vídeo sob demanda. Um dos fatores que favoreceu este crescimento foi a

popularização das aplicações de redes sociais, que impulsionaram o comportamento

das pessoas de compartilharem e recomendarem suas experiências.

Isso alavancou o consumo de vídeo, que é o tipo de mídia mais compartilhado nas

redes sociais. Como resultado deste processo e outros fatores tal como a melhoria na

velocidade das redes de computadores, verifica-se o grande crescimento de aplicações

de vídeo como YouTube, Netflix, Time Warner, Comcast, Amazon, e Hulu. Para

referência do nível de relevância destas aplicações, atualmente elas são responsáveis

por mais de 30% do tráfego de rede nos Estados Unidos[1].

A seguir são apresentados os principais conceitos e componentes associados às

arquiteturas de soluções de IPTV (Internet Protocol Television) e OTT (Over The Top).

São questões relevantes quando se fala de uma arquitetura híbrida, sendo base para o

entendimento do trabalho de modelagem dos requisitos.

2.1 IPTV

IPTV consiste na entrega de conteúdo audiovisual, compreendendo vídeo, áudio e

dados sobre uma rede IP. Para Simpson IPTV é conceituado como uma maneira

simples de entregar conteúdos de canais com compartilhamento em grande escala,

para consumidores sobre uma rede IP, independente se o serviço for através de redes

terrestre, cabeada ou satélite [2].

A infraestrutura IPTV pode ser dividida em blocos, cada qual com um conjunto amplo de

componentes: servidores VoD (Video on Demand), gerador de fluxos de vídeo

(streamer), servidor VCAS (Video Content Authority Syste1m), codificadores, solução

de armazenamento, servidores de middleware, servidores de monitoração, servidores

DRM (Digital Rights Management), equipamentos de recepção de sinal aos usuários,

14

entre outros elementos. A Figura 1Figura 1 ilustra alguns blocos e elementos que

compõem a infraestrutura de uma solução de IPTV.

Figura 1 - Diagrama IPTV (http://www.bogotobogo.com/WebTechnologies/ipTV.php)

2.2 OTT

Over The Top (OTT) consiste em um serviço multimídia que trafega por uma rede cujo

operador não é o fornecedor do serviço, ou seja, o fornecedor do serviço OTT não tem

responsabilidade sobre o meio de acesso ao serviço prestado. O OTT disponibiliza

serviços como vídeo sob demanda através do acesso à Internet que o cliente possui.

O OTT pode propiciar ao consumidor final acesso a serviços como telefonia e conteúdo

áudio visual através de aplicativos desenvolvidos para computadores, tablets,

smartphones e aplicativos para televisão conectada.

Embora prover conteúdo áudio visual através da Internet possa fornecer a impressão

de que o serviço seja de IPTV, já que ambos serviços trafegam através de uma rede IP,

esta percepção é erradaesta visão é superficial e errônea. Ao fazer uma análise das

características técnicas do OTT, pode-se notar que este serviço é distinto do serviço de

IPTV em vários aspectos.

Formatted: Highlight

Comment [RM3]: Quem garante?

15

O serviço OTT trafega pela Internet, através da qual o cliente tem acesso ao serviço

usando a rede de acesso que já tem contratada, portanto o provedor de serviço OTT

não administra a rede de acesso, não podendo garantir a qualidade de experiência ao

usuário.

2.3 PLATAFORMA HÍBRIDA

Esta seção apresenta os elementos necessários para compor uma plataforma híbrida,

ou seja uma plataforma convergente que suporte os serviços de IPTV e OTT.

Fundamenta-se em integrar às arquiteturas IPTV, elementos de uma arquitetura OTT.

Componentes da arquitetura IPTV tem seu escopo ampliado e elementos de uma

arquitetura OTT são adicionados.

2.3.1 Headend

O Headend neste cenário é ponto inicial da migração de serviços IPTV para OTT, e

neste contexto a implementação de equipamentos para suporte do OTT, onde os sinais

multimídia serão recebidos, sejam eles das fontes terrestres, satélite, fibra e ou cabo.

Estes sinais podem estar em diversos padrões de transmissão: ISDB-Tb (Integrated

Services Digital Broadcasting Terrestrial Brazil), UHF (Ultra High Frequency), VHF (Very

High Frequency), DVB-S /S2 (Digital Video Broadcasting over Satellite) e banda base

SDI (Serial Digital Interface).

O headend é um elemento chave das infraestruturas IPTV e OTT. No headend

acontecem todas as etapas de constituição, processamento e controle do conteúdo [3].

A Figura 2Figura 2 ilustra o headend convergente, mostrando as implementações dos

equipamentos para suporte do serviço OTT e os processos que ocorrem nele.

16

Figura 2 - Arquitetura IPTV convergente

2.3.1.1 Transcodificação

O primeiro processo no headend é a transcodificação dos sinais. Consiste na

transformação de sinais de diversas fontes em um único padrão. O objetivo é que os

sinais recebam a partir deste processo tratamento de forma homogênea.

2.3.1.2 Codificação

O processo de codificação é responsável por manter a qualidade do sinal produzido

pelas programadoras de conteúdo com uma taxa de bits suportável pelos sistemas

IPTV. Esta necessidade de comprimir o vídeo existe devido limitação das redes para

transportar vídeos em seu formato original, por exemplo, um vídeo HD (High Definition)

em sua origem apresenta uma taxa de 1.5 Gbps. Para que haja uma eficiência de taxa

de sinal e qualidade são aplicados algoritmos de compressão.

Comment [RM4]:

17

Ambas arquiteturas, IPTV e OTT realizam a segmentação de pacotes para transporte

do conteúdo, com isto, quanto maior a eficiência da compressão menor as

segmentações e possíveis atrasos de distribuição.

A maior referência na área de compressão de vídeo é o grupo MPEG (Moving Pictures

Expert Group), o qual desenvolveu diversos padrões, entre eles o MPEG-1, MPEG-2,

MPEG-4, MPEG-1. Estes padrões de compressão tem evolução constate. Para termos

de termos de referência da evolução, o padrão HEVC (High Efficiency Video Coding),

sucessor do MPEG-4, possui), possui eficiência de 40% sobre o padrão que o precede

[4].

2.3.1.3 Gerador de fluxos de vídeo (Streamer)

Para que o conteúdo tratado no headend possa ser visualizado em diversos

dispositivos, é necessário que haja uma etapa de criação de perfis de conversão dos

vídeos para diferentes taxas de bits e resolução. No gerador de fluxos de vídeo, original

do inglês, Streamer, os conteúdos VoD (Video on Demand) e ao vivo, são processados

para serem disponibilizados em diversos formatos.

Além da conversão, alguns protocolos de streaming de vídeo são aplicados no

Streamer, como: Apple HLS (HTTP Live Streaming), Microsoft S Smooth Streaming,

Adobe HDS (HTTP Dynamic Streaming), MPEG-DASH (Dynamic Adaptive Streaming

over HTTP). Estes protocolos atendem a um requisito importante no universo de IPTV e

OTT, que é a taxa de bits adaptativa, onde cada dispositivo requisitante recebe um

perfil diferente de sinal multimídia, com isto, a distribuição do sinal pode ser

decodificada por dispositivos móveis, portáteis e televisores com diferentes

características.

É no Streamer que se inicia a aplicação VCAS (vide seção 2.3.1.6), quando um link

dedicado entre repositório, Servidor VCAS e Streamer se conectam ao conteúdo

criptografado. Ao final deste processo o conteúdo está adequado para ser entregue a

uma rede de distribuição de conteúdo.

Comment [RM5]: Colocar na ordem

Comment [RM6]: Colocar na ordem

Formatted: Highlight

Comment [RM7]: VAC > HEVC > Ambos MPEG4

Formatted: Not Superscript/ Subscript

Formatted: Not Highlight

18

2.3.1.4 Repositório

Quando se aborda uma rede híbrida, o repositório é um elemento de conexão das

redes IPTV e OTT, pois é neste elemento que serão armazenados os conteúdos VoD.

Isto é, todas as solicitações de conteúdo do usuário serão orientadas para busca no

servidor VoD. O repositório é uma base de dados com grande capacidade de

armazenamento de conteúdos multimídia.

Além de busca de conteúdos gravados, o usuário tem possibilidade também de gravar

seus conteúdos de maior interesse em nuvem, minimizando os custos de hardwares

nos STBs (Set top boxes).

2.3.1.5 Servidor VoD

O servidor de Vídeo sob Demanda deve suportar diversos padrões de codificação,

gerenciamento para milhares de acessos que requisitam fluxos simultâneos ao servidor,

o qual necessita de alto poder de processamento. O servidor VoD também faz

administração dos acessos do servidor de DRM e o Middleware. Este servidor gerencia

e busca os conteúdos armazenados no repositório.

2.3.1.6 CAS (Content Authority System)

O servidor Video Content Authority System (VCAS), trata-se de um gerador de chaves

de criptografia para os conteúdos entregues ao Streamer. Ele integra técnicas de

proteção para redes gerenciadas com segurança baseada em padrões de conteúdo, e

protocolos de fluxos de vídeo com taxa de bits adaptativo, garantindo que as chaves de

decodificação sejam mantidas seguras e distribuídas somente a dispositivos

autorizados.

O CAS é baseado em software e construído sobre conceitos de transações eletrônicas

de criptografia segura compatível para todos os tipos de dispositivos de recepção de

sinal. Existem também soluções que integram software e hardware para integração de

criptografia.

Comment [RM8]: Onde pegou esta iformacao?

Formatted: Highlight

19

O servidor VCAS e servidor de DRM são necessários para garantia de que os

conteúdos distribuídos nas redes, independente se IPTV ou OTT não sejam

manipulados pelos usuários de forma ilícita.

2.3.1.7 Servidor de Gerenciamento e Provisionamento de Usuários

O servidor de gerenciamento e provisionamento de usuários, é um componente chave.

Ele trata a gestão de assinantes, sendo responsável por funcionalidades como:

provisionamento de usuários, serviços de dados EPG (Electronic Program Guide),

serviços remotos, gerenciamento e suporte das requisições de gravação. Outra

importante função do servidor é o gerenciamento das aplicações para uso do servidor

de tarifação, realizando interface com o Servidor DRM e o servidor VoD.

Este servidor é aplicado em plataformas IPTV e OTT, dado que ambas fazem

gerenciamento de usuários e aplicações.

2.3.1.8 Servidor de Tarifação

O servidor de Tarifação é responsável pela gestão da base de dados dos assinantes,

tarifação dos serviços oferecidos, criação e manutenção dos serviços ofertados,

geração de faturas, além de prover o relatório financeiro relativo ao sistema de IPTV.

Este servidor necessita de interconexão com os servidores de acesso condicional e de

middleware, já que o sistema de tarifação requer informações de compras efetuadas

pelo cliente como VoD e PPV (Pay-Per-View), além de prover informação ao sistema de

CAS, baseando-se no pacote contratado, de quais serviços o cliente deve ter acesso.

2.3.2 Recepção

O dispositivo responsável pela interação do usuário final com o sistema de IPTV é

denominado set-top box. Este equipamento executa a recepção, a decriptografia e a

decodificação dos sinais de IPTV a fim de que estes sejam preparados para serem

exibidos na televisão do telespectador.

20

O set-top box pode ter componentes integrados para interconexão com a rede de

acesso, como cable modem no caso de rede HFC (Hybrid Fiber Coax) ou ONT (Optical

Network Terminal), quando é utilizado arquitetura FTTH (Fiber To The Home). Não

havendo a integração do terminal de conexão à rede de acesso com o set-top box, este

é interligado a rede de distribuição residencial através de uma interface Ethernet.

O set-top box é composto por vários módulos de software sendo eles, drivers, boot

loader, middleware, módulo de acesso condicional e interface gráfica, como

apresentado na Figura 3Figura 3 mostra a figura 3.

Figura 3 - Arquitetura STB (http://www.knowcrazy.com/2011/05/set-top-box.html#.VDMt3Gdhd1Z)

Os drivers são responsáveis pela comunicação com o hardware onde são programadas

funções de baixo nível como, de sintonia e decodificação de áudio e vídeo.

O RTOS (Real -Time Operating System), também conhecido como boot loader, consiste

em uma camada de software responsável pela inicialização do set-top box, além do

download e instalação de novas versões de software que eventualmente serão

transmitidas pela rede de IPTV.

O middleware é responsável pelas funcionalidades implementadas ao produto como a

interpretação dos comandos do controle remoto e transmissão destes comandos à rede

Field Code Changed

Comment [RM9]: Na versão impresssa sumiu a referencia

21

IPTV. O middleware também é responsável pela comunicação entre os módulos de

software como, por exemplo, os drivers para realizar a decodificação de áudio e vídeo,

o modulo de acesso condicional para a decriptação do sinal e, a interface gráfica para

interação com o usuário. Funções de gravação (DVR - Digital Video Recorder) também

podem ser adicionadas ao middleware do set-top box utilizando-se dispositivos de

armazenamento local, como um HDD (Hard Disk Drive).

O módulo de acesso condicional é responsável pela decriptação do sinal recebido, bem

como a liberação do acesso somente aos canais que pertencem ao plano pacote

contratado pelo assinante.

A interface gráfica ou interface do usuário (UI – User Interface) é a camada de software,

ou melhor, a aplicação responsável pela interação com o usuário, já que ela é

responsável pela exibição das informações de maneira que o usuário possa interagir

com o produto. Diferentemente dos serviços IPTV, os serviços OTT podem ser

decodificados por qualquer equipamento, como computadores, tablets e smartphones.

22

MODELAGEM DE REQUISITOS DE UMA ARQUITETURA HÍBRIDA 3

Ao prover IPTV, o operador é responsável pelo gerenciamento da rede pela qual o

serviço será disponibilizado. O provedor adota métricas de rede e aplica técnicas de

QoS (Quality of Service) a fim de garantir a qualidade de experiência ao usuário de seu

serviço.

Já no serviço OTT, os dados provenientes deste serviço são tratados como qualquer

outro pacote de dados da Internet, ficando a encargo somente do melhor esforço para a

sua entrega. Desta forma, o OTT pode ter sua qualidade reduzida por atrasos na rede,

jitter, perda de pacotes, entre outros fatores.

Este capítulo visa apresentar requisitos chaves a serem considerados em soluções

híbridas, atendendo tanto à provisão de uma solução IPTV como de serviços OTT.

3.1 CDN

CDN consiste de uma arquitetura (Figura 4Figura 4) formada por um conjunto de

servidores com a função de distribuição de conteúdos de um servidor a múltiplos

consumidores. Ela visa prover, entre outras coisas, qualidade de experiência ao usuário

(QoE – Quality of Experience). Para ter uma visão da sua importância, mais da metade

do consumo de tráfego da Internet compreende vídeo e grande parte deste conteúdo, é

distribuído através de CDNs [6].

As CDNs tem altíssimo desempenho e são extremamente flexíveis em relação a

escalabilidade, sendo apropriadas para suportar exigências massivas de usuários. Elas

fornecem alta qualidade de conteúdo para múltiplas telas, tanto para Live como para

VoD Streaming. Em contrapartida, envolve alto custo de gerenciamento[5].

Elas suportam diversos formatos de streaming, além de possibilitar aplicações de

Catch-up e NDVR (Network Digital Video Recorder) e funcionalidades como Pause,

Rewind e Start-over. As CDNs também suportam mecanismos de filtragem de

conteúdos, empacotamento de vídeo, áudio e legendas, incluindo legenda oculta (CC –

Close Caption).

23

Figura 4 - Arquitetura CDN [7]

Um dos elementos relevantes para a construção de requisitos de uma plataforma

híbrida IPTV e OTT é a CDN.

Para a tomada de decisão sobre a escolha da tecnologia a ser aplicada na CDN, é

necessário entender como os conteúdos são distribuídos pela rede. Conteúdos OTT,

tais quais, Netflix e YouTube trafegam nas CDNs de forma não gerenciada, onde

existem apenas alguns contratos com SLAs (Service Level Agreement) mínimos

requeridos pelos provedores de conteúdo e obedecidos pelos administradores das

CDNs.

A CDN é um serviço chave para a qualidade na distribuição de sinais de vídeo. Mas

para alcançar os benefícios oferecidos pelas CDNs, muitos pontos precisam ser

avaliados, como o tipo de CDN. Em um cenário híbrido, é relevante pensar na

globalização dos serviços. Isto é, provedores de conteúdo em todo mundo e a

capacidade do serviço a ser oferecidos pelos ISPs (Internet Service Provider). Nesta

visão de globalização, se destacam as CDNs peering e a CDN híbrida.

Formatted: Font: 10 pt

24

A CDN peering ou interconectada, tem como conceito a cooperação e interoperação

entre uma ou mais CDNs, com intuito de aumentar a cobertura do serviço e reduzir as

despesas de investimento com infraestrutura. No entanto, para esta arquitetura

funcionar, é necessário que haja uma entidade gerenciando a interação colaborativa

entre as diversas CDNs de forma transparente, isto é, um órgão de supremacia sob

todas as entidades[10].

A CDN peering tem como vantagens para este projeto os seguintes pontos:

Visão de arquitetura global para distribuição de vídeo;

Padronização das políticas aplicadas pelas CDNs aos conteúdos de forma a

garantir a qualidade fim a fim do serviço;

Modelo de negociação, onde o usuário faz uma solicitação do conteúdo ao

servidor mais próximo e para obtenção do mesmo ocorre a interação entre os

servidores de distribuição das CDNs para aquisição do conteúdo. Com isto, o

serviço de distribuição de vídeo ganha escalabilidade (figura 5);

O provedor de conteúdo ao contratar um serviço de distribuição de uma CDN

pode ampliar seu contrato globalmente com diversas CDNs devido a

transparência e relacionamento entre as mesmas;

ISPs podem potencializar seus serviços com suas CDNs formando uma rede

colaborativa.

25

Figura 5 - CDN Peering - (Vitor M.J Silva, 2013 – Service Building in dense Service Provider

Environments)

A CDN híbrida (ver figura 6) combina técnicas P2P (Peer-to-Peer), ou seja, existe uma

intercooperação entre todos os elementos do sistema. Quando há alta demanda de

conteúdos, os servidores de borda requisitam os conteúdos de seus vizinhos, e no

momento em que ocorre uma baixa demanda de conteúdo, o usuário receberá o

conteúdo do servidor de origem da CDN.

Para gerenciamento das requisições aos servidores e/ou peer, existe um mecanismo de

roteamento e entidade lógica de controle. Pesquisas mostram CDNs híbridas como

sistema com melhor performance para entrega de conteúdo, apresentando resposta

rápidas de requisições e entrega eficiente de vídeo[10].

26

Figura 6 - CDN híbrida combinação CDN + P2P

(http://www.forcetech.net/en/product/server_p2p.html)

Outro tipo de CDN que se destaca em um cenário de distribuição de vídeos, são as

baseadas em nuvem. Elas são uma estrutura promissora para aplicações de multimídia,

pois permitem escalabilidade proporcionada pela infraestrutura elástica, com

provisionamento de recursos e banda baseado na demanda de usuários. Com a técnica

de aplicar armazenamento em nuvem, pode oferecer serviços sem a necessidade de

investimento em rede física. Como resultante tem redução de custo e possibilidade

maior receita de serviços[11].

Esta infraestrutura de CDN é vantajosa para pequenos ISPs, que podem construir com

baixo custo suas próprias CDNs e oferecer seu serviço globalmente, utilizando

servidores em diferentes países[11]. Na figura 7 é ilustrada a arquitetura de uma CDN

na nuvem, mostrando provedores de conteúdo num ecossistema de distribuição de

conteúdo.

Outras arquiteturas de CDN são encontradas. O objetivo foi apresentar de forma sucinta

a informação de alguns tipos de CDNs que podem ser de grande valor para empresas

que buscam atingir um cenário híbrido. É um tipo de conhecimento que as operadoras

27

de IPTV precisam atentar e passar a fazer uso em sua estratégia de sair do escopo da

sua rede e conseguir atingir os usuários, onde quer que eles estejam.

Figura 7 - Arquitetura Híbrida com CDN em Nuvem e Provedores de Conteúdo [11]

3.2 SERVIÇO DE CACHE DE INTERNET

Além da CDN outro elemento a ser considerado num projeto de plataforma híbrida IPTV

e OTT é o Transparent Internet Caching (TIC), o qual auxilia na redução da latência na

distribuição de conteúdos. No TIC, os servidores de borda armazenam os conteúdos

prioritariamente requisitados, facilitando o envio ao usuário final, sua aplicação é

transparente tanto para os provedores de conteúdo, como para os usuários finais.

Os ganhos para aplicação de TIC são:

Garantir a entrega de conteúdos recentemente requisitados;

Integridade dos serviços;

Preservar o link lógico fim a fim e garantir todas as aplicações de segurança de

conteúdo.

O TIC apresenta maior aproveitamento nos conteúdos OTT e VOD, armazenando

conteúdos mais demandados próximos aos usuários diminuindo o tráfego destes

conteúdos na rede.

28

O TIC captura as requisições de conteúdo interceptando a comunicação entre usuário e

provedor de conteúdo, armazenando o conteúdo e preservando o sincronismo e link

com a URL.

O TIC permite um grande ganho de eficiência nas redes das operadoras, no entanto

provedores de conteúdo não aprovam o caching de alguns conteúdos. Alguns

conteúdos em HTTP (Hypertext Transfer Protocol) são marcados como “no-cache”,

porém esta marcação pouco vale para as operadoras que praticam o TIC da mesma

maneira.

Como medida de impedir a prática do TIC, alguns provedores de conteúdo aplicam os

protocolos de aplicação RTMP (Real Time Messaging Protocol) e RTSP (Real Time

Streaming Protocol).

O transporte do serviço multimídia também é um requisito para análise num projeto de

plataforma híbrida. Serviços de tempo real aplicam protocolos como o RTSP. Este

protocolo controla a sessão de stream de vídeo, seja Live, ou por demanda. Além do

controle da sessão, o RTSP é responsável pela seleção do modo de transporte do

stream, isto é, unicast ou multicast, UDP (User Datagram Protocol) ou TCP

(Transmission Control Protocol) e pelas funções de controle do vídeo, tais quais, para

pausar, exibir, avançar e retroceder. Todo o controle entre a conexão cliente servidor

durante a transmissão do stream é a cargo do RTSP.

3.3 QoE e QoS

Quando se fala de pontos de atenção na distribuição de conteúdos multimídia, não se

pode deixar de dar atenção a QoS e QoE. Parâmetros de medidas de qualidade de

sinal de vídeo podem apresentar requisitos de QoS e QoE, além de classificações das

métricas com resultantes objetivos e subjetivas de qualidade.

Os parâmetros subjetivos podem ser orientados a percepção do usuário como a escala

de qualidade MOS (Mean Opinion Score), uma evolução da BT-500 da recomendação

ITU-T E. [8].

29

O conceito de QoE é a garantia de qualidade da experiência entre o usuário e a

aplicação. Os parâmetros QoS podem ser definidos como a ligação entre os níveis de

aplicação e rede, onde os parâmetros objetivos são medidos como perda de pacotes,

atraso, largura de banda e relação sinal ruído (do inglês, PSNR - Peak Signal to Noise

Ratio).

A perda de pacote pode ser medida entre os componentes de saída do headend, como

o servidor de origem de vídeo e a chegada ao STB. Os pacotes devem ser marcados

com um identificador único e sequencial no servidor de origem para tal procedimento. O

tráfego percorrerá toda a rede, passando pelos servidores de borda, até a chegada no

STB, finalizando o processo fim a fim do vídeo.

Existem fatores importantes que devem ser avaliados no parâmetro perda de pacotes,

não somente a quantidade de pacotes perdidos, mais sim a importância dos quadros

que foram perdidos com os pacotes. No headend o codificador aplica a compressão

MPEG isto é, realiza a compressão da imagem em frames, sejam eles, I, P, B. Estes

frames são distribuídos em diversos pacotes do protocolo de transporte IP, os quais

podem sofrer perdas ao longo do percurso da rede[16][15].

No entanto como medida de suavizar a percepção da perda ao usuário, como

prevenção ocorre a marcação de pacotes, onde os pacotes devem ser marcados por

prioridade nos servidores de origem dos ISPs para um tratamento prioritário em nível de

camada de rede e transporte, e para tanto os cabeçalhos dos quadros devem ter graus

diferentes de importância, ou seja, o quadro I que carrega maior informações de

imagem tem maior prioridade, os quadros P e B que carregam menor tamanho de

informação e informações de menor relevância devem ter prioridades menores na

escala de importância.

O fator de Jitter é um parâmetro de QoS, que mede a variação do atraso em um

sistema de transmissão de vídeo, e o impacto deste parâmetro é visivelmente notável

pelo usuário, numa percepção de QoE. O vídeo ideal deve ser amostrado ao usuário

numa frequência constante e numa sequência determinada, porém quando ocorre o

30

jitter, estes quadros chegam ao receptor em tempos diferentes e causam o efeito

jerkiness, onde o frame amostrado pode estar adiantado ou atrasado do tempo ideal[9].

Como contrapartida do efeito do jitter pode ser inserido no sistema buffers de

compensação, conhecidos como playout buffers, o qual armazena as informações

numa fila em uma etapa anterior a amostragem do sinal ao usuário, ou melhor, da

decodificação. Como resultante, os pacotes só serão amostrados após reordenação

sequencial dos mesmos, e com frequência constante, evitando a experiência negativa

de percepção do usuário. Contudo como desvantagem da aplicação destes filtros no

sistema existe o aumento no atraso do sistema fim a fim.

3.4 HLS

Um dos maiores pontos chaves da arquitetura híbrida IPTV e OTT é o uso do protocolo

HLS, isto porque se trata de um protocolo com taxa de bits adaptativo e pode ser

suportado por diversos dispositivos receptores. O HLS é um protocolo desenvolvido

pela Apple para transporte de stream multimídia para comunicação com dispositivos

portáteis.

O HLS é divido em três camadas; codificação, distribuição e cliente. Este protocolo

pode ser utilizado para conteúdos Live e sob demanda.

No HLS os arquivos são gerados com diversos perfis de configuração, com compressão

e multiplexação diversas. Em seguida, cada conteúdo é divido em chunks, e estes são

entregues para o servidor para distribuição dos streams segmentados e acoplados com

um arquivo de lista de reprodução (.M3U8). Dependendo da qualidade da experiência

fim a fim, os perfis podem ser ativados, apresentando uma qualidade superior ou

inferior do serviço multimídia.

Outra evolução do HTTP para transmissão de vídeo na rede é o Dynamic Adaptive

Streaming (DASH) aplicado sobre o HTTP. Esta solução ainda não está totalmente

difundida no mercado, e muitos dispositivos ainda não suportam, porem quando houver

a capilarização do DASH em grande escala esta se tornará tão eficiente ao HLS

convencional.

31

Nesta técnica, os streams de vídeos codificados em diferentes perfis e divididos por

chunks, estes são segmentados em divisões de alguns segundos, geralmente de 4 a

10.

O usuário faz uma requisição de conteúdo para o servidor, para início da transferência

um algoritmo é ativado realizando medidas de largura de banda para determinar a

qualidade devida para os chunks prosseguirem com a transferência.

3.5 OUTROS REQUISITOS

O gerenciamento das redes de acesso (entenda-se por rede de acesso, os switches

agregadores, BRAS (Broadband Remote Access Server) e MSANs (Multi-Service

Access Node), é um requisito relevante para as arquiteturas híbridas, ao considerarmos

que a arquitetura IPTV convergente estará encapsulado em HLS, e os provedores de

conteúdo nativo OTT já enviam seus fluxos em HLS. A priorização dos pacotes HLS

nos roteadores de borda é uma técnica que aumentaria o QoE do usuário, diminuindo a

latência da entrega, buscando sempre o melhor percurso dos pacotes na rede.

Outro requisito seria a exploração dos dispositivos decodificadores e suas técnicas de

comutar de maneira eficiente entre os diversos perfis oferecidos pela codificação HLS,

isto é, o gerenciamento automático do sistema de decodificação ao identificar que os

requisitos de QoS estão se degradando, por exemplo, realizar antecipadamente a

requisição de chunks com perfis diferenciados que atendam a demanda da rede de

transporte e distribuição, desta maneira não afetaria a QoE do usuário.

Como resultante os mecanismos de analises dos dispositivos, geralmente aplicações

clientes embarcadas nos hardwares, trabalhariam de forma inteligente, eficiente e

colaborativa na decodificação do HLS.

32

AVALIAÇÃO 4

4.1 AKAMAI E AMAZON

Os serviços de distribuição de conteúdo oferecidos pela Akamai são um exemplo onde

os requisitos de qualidade, protocolos da camada de encapsulamento de serviços e na

camada de aplicação são tratados conforme abordados no trabalho. A Akamai oferece

seus serviços de distribuição de conteúdos através de CDNs licenciadas e peering.

No modelo de peering, quando o ISP contrata a Akamai, a distribuição na rede desde o

provedor de conteúdo até o usuário é realizada de forma transparente por uma única

administração e políticas de rede de maneira globalizada, como mostrado na Figura 8.

Figura 8 - CDN peering Akamai – (http://pt.slideshare.net/suerudd/cdn-ws-

operatorspperspectives1630june-27th2013suerudd, acesso 06, fev.2015)

Na opção de contratação de CDN licenciada, o operador, o qual pode ser um ISP,

contrata o serviço de CDN, mas fica a cargo da CDN a administração dos serviços na

rede. A responsabilidade do ISP é somente na distribuição para última milha, isto é,

dentro do domínio do ISP[13][14].

Formatted: Keep with next

33

A opção licenciada seria aderente para os pequenos ISPs que já possuem redes de

legado IPTV e aplicariam os serviços OTT que já são disponibilizadas nas CDNs,

evoluindo assim para plataformas híbridas.

Ambas as arquiteturas aplicam em sua rede o serviço de Hipercahe (HPC), o qual tem

maior eficiência para serviços OTT. O Hipercahe opera em cluster e faz fragmentação e

distribuição de objetos através dos servidores e maquinas virtuais, além de aplicar

também algoritmos de hash e suportar protocolos de entrega de vídeo HTTP e políticas

de QoE.

AWS (Amazon Web Services) da Amazon é outro exemplo interessante de um serviço

que suporta requisitos levantados no trabalho, podendo ser utilizado na estratégia de

uma operadora de viabilizar sua plataforma híbrida. O AWS suporta plataformas que

integram deste o headend IPTV convergente, servidores de DRM, até a gerência de

distribuição de sinal. Esta arquitetura comporta múltiplos serviços na nuvem, pode

hospedar aplicações como Netflix entre outras, que demandam escalabilidade de

serviços. Os serviços são gerenciados por HTTP e APIs (Application Program Interface)

diversas.

A solução AWS é a mais indicada para provedores iniciantes em plataforma multimídia,

pois as operadoras que já possuem hoje o legado das redes e infraestruturas IPTV

precisarão de um investimento massivo para integrarem suas soluções.

Atualmente o Netflix utiliza a plataforma AWS para seus serviços de vídeo. A utilização

do AWS para o Netflix resultou em grande potencial de escalabilidade de novos

serviços aos usuários.

4.2 ANÁLISE

A necessidade e importância de se entender os requisitos de uma plataforma híbrida de

serviços multimídia ficam ainda mais evidente quando se enxerga o cenário futuro. [12]

descreve a projeção de crescimento do trafego de vídeo sobre IP. Através do estudo,

34

em 2018, a ocupação destes serviços representará 79% sobre todo o tráfego de rede, e

os dispositivos conectados à Internet serão aproximadamente 21 bilhões.

Com estes dados é fácil compreender a necessidade de desenvolver projetos de

plataforma que atendam todas as demandas de serviços multimídia, sejam eles OTT e

IPTV[13].

Na seção 3.2 foram apresentados os requisitos de CDN para atender uma rede híbrida.

Como exemplo para ilustrar a importância das CDNs, foi apresentado o exemplo da

Netflix, que inicialmente utilizava as redes de distribuição de conteúdo de terceiros, mas

que ultimamente, anos após anos, tem investido milhões para desenvolver sua própria

distribuição para remodelar e expandir sua rede. Isso ressalta a importância no

investimento em CDNs.

Esta ação demonstra a tendência de universalização das distribuições de conteúdo e

serviços, onde um provedor de conteúdo se torna um distribuidor de conteúdo também

e se conecta globalmente com outras redes de distribuição. Ressalta também a

importância de se olhar de forma mais sistêmica, olhando forte para os requisitos de

rede e roteamento de forma a prover melhor QoE.

A Netflix se iniciou como um provedor de conteúdo, porém a alta demanda de seus

serviços e a visibilidade de um modelo de negócio eficiente ao se expandir aplicações

resultou na ampliação do número de servidores em distribuição geográfica mais

adequada para atender todas as ISP, com o conceito de manter o conteúdo o mais

próximo dos usuários, não sobrecarregar as redes e não acarretar em falhas de

qualidade[17].

Outra tendência que se apresenta com grande vantagem para os provedores e

distribuidores, como para aos usuários de conteúdo, são as CDN na nuvem, conforme

seção 3.2. Atualmente existem algumas empresas, tais como Netflix, Amazon e Verizon

aplicando esta técnica para oferecerem seus serviços.

Nesta arquitetura o custo de implantação é baixo e qualidade é dimensionada conforme

a demanda dos serviços. Para utilização de uma CDN na nuvem é um importante que

35

aja um planejamento de uso, pois se a demanda crescer de forma não gerenciada pode

acarretar em grandes custos ao operador.

Os exemplos apresentados na seção 4.1 ilustram as facilidades (e desafios) que os

provedores de serviço multimídia e os ISPs terão para construírem ou adequarem as

plataformas híbridas IPTV e OTT. A Akamai, por exemplo, é uma solução para

expansão da rede, onde os ISP podem adequar suas demandas de conteúdos OTT, e

os provedores de conteúdo IPTV convergente podem inserir suas políticas de

distribuição gerenciada.

O AWS da Amazon é vislumbrado como a plataforma mais aderente a suportar

os serviços IPTV e OTT, pois aplica técnicas de encapsulamento HLS, serviço de

cache, suporta aplicações de headend IPTV, além de integração com diversos DRMs e

CAS. No entanto, o melhor custo benefício para contratar esta solução seria para os

ISPs que estiverem iniciando operação, pois não teriam o grande custo de integração

com plataforma legada, geralmente plataformas IPTV[18].

36

CONSIDERAÇÕES FINAIS 5

Este trabalho se propôs a apresentar requisitos relevantes baseados em tendência de

mercado e evolução tecnológica para plataformas de serviços multimídia visando uma

migração de serviços IPTV para OTT, compondo uma plataforma híbrida.

A peculiaridade dos cenários IPTV e OTT foram demonstradas para ambientar e

sinalizar os requisitos principais que tangem estas tecnologias, desde a formação dos

conteúdos, distribuição à recepção dos sinais.

Os requisitos levantados neste trabalho trataram de questões chaves para entender os

conceitos e diferenças a serem consideradas em projetos que envolvam soluções

híbridas. Por exemplo, os protocolos de transporte das aplicações, foram mostrados

como requisitos chaves para a aderência para serviços híbridos, isto é, a possibilidade

de atender ambos os serviços encapsulados na camada de aplicação com os mesmos

protocolos.

Netflix, Akamai e Amazon e AT&T foram exemplos apresentados com intuito de mostrar

a relevância dos pontos levantados no trabalho. As empresas estão se modelando para

atender um mercado que converge para plataformas híbridas de serviços multimídia.

A convergência dos serviços IPTV e OTT será inevitável para atender a demanda dos

consumidores. O mercado de IPTV será o mais afetado se não aderir a mudança no

comportamento de consumo dos usuários ao longo dos anos, onde o conteúdo linear

do IPTV não agrada tanto. O usuário quer escolher o que assistir, onde e quando.

5.1 TRABALHOS FUTUROS

Neste trabalho não foram tratados requisitos e técnicas aplicados em partes das redes

de distribuição, como rede de acesso, ou seja, switch de agregação, MSANs, e

equipamento de usuários, como decodificadores. Como trabalho futuro estes seriam

temas interessantes, pois possibilita aplicação de técnicas de priorização de pacotes e

tratamento de fluxos HLS nos decodificadores.

37

REFERÊNCIAS

[1] Tim Lee, Comcast’s Deal with Netflix Makes Network Neutrality Obsolete, Washington Post, February 23, 2014.

[2] Wes Simpson, Video Over IP: IPTV, Internet Video, H.264, P2P, Web TV, and Streaming:

A complete guide to understanding the technology, pg 999 -2008).

[3] (D. Ramirez, “IPTV Security”, John Wiley & Sons, Ltd, 2008, pp. 1-62).

[4] SMPTE,“The New High-Efficiency Video Coding Standard, B. Bross, H. Schwarz

,D. Marpe. [5]. O. Yevsyeyeva, Mohammed B. Khader, Hierarchical Control Method for Hybrid Content Delivery Network,2014

[6] V. Burger, M. Hirth,C. Schwartz, T. Hoßfeld, and P. Tran-Gia, Increasing the Coverage of Vantage Points in Distributed Active Network Measurements by Crowdsourcing,2014

[7] Buyya, Rajkumar, Pathan , Mukaddim; VAKAli ,Athena (Ed.). Content delivery networks, Springer 2008

[8] H. J. Kim, Ki S. Cho, H. S. Kim, S. G. Choi, A Study on a QoS/QoE Correlation Model for QoE Evaluation on IPTV Service, Electronics and Telecommunications

Research Institute (ETRI),2008. [9] Quan Huynh-Thu and Mohammed Ghanbar, Impact of Jitter and Jerkiness on perceived

video quality,2008). [10] P2P, CDNs, and Hybrid Networks: The Economics of Internet Video Distribution,

Imsook Ha Korea Electrotechnology Research Institute, 2010.

Formatted: Font:

Formatted: Font: (Default)Arial,Calibri

Formatted: Font: (Default)Arial,Calibri, Not Bold

Formatted: Font: (Default)Arial,Calibri

Formatted: Font:

Formatted: Font: (Default)Arial,Calibri

Formatted: Font:

Formatted: Font:

Formatted: Font:

Formatted: Font: Bold

Formatted: Font:

Formatted: Font:

Formatted: Font: (Default)Arial,Calibri

Formatted: Font: Bold

Field Code Changed

Formatted: Font:

Formatted: Font:

Field Code Changed

Formatted: Font:

Formatted: Font:

Field Code Changed

Formatted: Font:

Formatted: Font:

Field Code Changed

Field Code Changed

Field Code Changed

Field Code Changed

Field Code Changed

Formatted: Font:

Formatted: Font: Bold

Formatted: Font:

Formatted: Font: (Default) Arial,TimesNew Roman

Formatted: Font: (Default) Arial,TimesNew Roman, Not Bold

Formatted: Font: (Default) Arial,TimesNew Roman, Not Bold

38

[11] Haitao Li, Lili Zhong, Jiangchuan Liu Bo Li, Ke Xu, , Cost-effective Partial Migration of VoD Services to Content Clouds, IEEE 4th International Conference on Cloud Computing, 2011,) [12] Yago Sánchez et al, iDASH: Improved Dynamic Adaptive Streaming over HTTP using Scalable Video Coding, Bell Labs - Alcatel Lucent, Belgium, 2013. [13] http://www.citrix.com/content/dam/citrix/en_us/documents/products-solutions/how-telcos-and-isps-can-learn-to-love-ott.pdf). Acesso em 10 de jan.2015 [14] http://www.businessweek.com/articles/2014-07-24/netflixs-content-delivery-chief-endures-isp-streaming-fees. Acesso em 20 de dez., 2014 [15] http://blog.streamingmedia.com/2014/01/google-launches-video-quality-report-rates-isps-delivery-youtube-content.html. Acesso em 16 de dez., 2014 [16] http://www.bogotobogo.com/WebTechnologies/ipTV.php. Acesso dia 24 de jan.2015 [17] http://www.policychargingcontrol.com/2939-volte-interoperability-between-verizon-and-at-t-marks-mnos-comeback-intensifies-competition-against-ott-services, Aacesso em 01 de fev.2015. [18] ([18] Broadband as a Video Platform The Economics of Information, Communication, and Entertainment ,2014, pp 81-93.

[19] (Vijay Kumar Adhikari, Unreeling Netflix: Understanding and Improving Multi-CDN

Movie Delivery, Vijay Kumar Adhikari, University of Minnesota, Bell-Labs/Alcatel-

Lucent,2011).

Formatted: Font:

Formatted: Font: (Default)Arial,CMSY8

Formatted: Font:

Formatted: Font:

Formatted: Font:

Formatted: Font:

Formatted: Font:

Formatted: Font:

Formatted: Font:

Formatted: Font:

Formatted: Font:

Formatted: Font:

Formatted: Font:

Formatted: Font:

Formatted: Font:

Formatted: Font:

Formatted: Hyperlink, English (U.S.)

Field Code Changed

Formatted: Font: Bold, No underline

Formatted: Font: Bold, No underline

Field Code Changed

Formatted: Font: Bold, No underline

Formatted: Space After: 0 pt, Linespacing: single

Formatted: Font:

Formatted: Font: (Default) Arial,TimesNew Roman, English (U.S.)

Formatted: Font: (Default) Arial,TimesNew Roman