Arquitectura SIP IPTV para Redes Heterogéneas

Arquitectura de Cliente

João Ricardo Dias Domingues

Dissertação para obtenção do Grau de Mestre em

Engenharia de Redes de Comunicações

Júri

Presidente: Professor Doutor Rui Jorge Morais Tomaz Valadas

Orientador: Professor Doutor Mário Serafim dos Santos Nunes

Co-Orientador: Professor Rui António dos Santos Cruz

Vogais: Professor Doutor Paulo Luís Serras Lobato Correia

Abril de 2009

ii

Agradecimentos

Gostaria de deixar uma palavra de apreço a todas as pessoas que me apoiaram no desenvolvimento

deste trabalho.

Agradeço aos meus orientadores, Professores Mário Serafim Nunes e Rui Santos Cruz por todo o

apoio e motivação desde o primeiro ao último dia, sem os quais este trabalho não teria sido possível.

Aos meus pais, Carlos e Anabela que me apoiaram em tudo ao longo de toda a minha vida.

Aos avós maternos, Alice e Augusto, agradeço o carinho e força interior que me transmitem em todos

os momentos, estão sempre no meu coração.

A todos os meus amigos e colegas, pela força para seguir em frente nos momentos mais difíceis. Um

obrigado especial ao Leandro pelo espírito de entreajuda e companheirismo que caracterizaram o

desenvolvimento deste projecto.

À Catarina, que está sempre ao meu lado, agradeço a ajuda incansável na revisão da Dissertação e a

compreensão que demonstrou em todos os momentos.

A todos, muito Obrigado.

iii

Resumo

Esta dissertação apresenta uma arquitectura para serviços Internet Protocol Television (IPTV) que

utiliza o Session Initiation Protocol (SIP) para o estabelecimento e controlo do serviço, sendo baseada

no conceito de IP Multimedia Subsystem (IMS). Esta arquitectura é escalável, e permite convergência

ao nível do acesso para o serviço streaming multimédia personalizado.

Propõe-se um novo método de adaptação e monitorização da Qualidade de Serviço (QoS), centrado

no sistema terminal, que tem como objectivo maximizar a Qualidade de Experiência (QoE). Este

método permite alterações dinâmicas dos parâmetros da sessão multimédia, adaptando-se às

características e condições da rede.

Os detalhes da implementação referem-se ao protótipo Cliente, que foi desenvolvido em paralelo com

um servidor SIP IPTV.

A solução foi avaliada através de um conjunto de testes funcionais e não-funcionais, em rede local e

numa rede móvel 3G, apresentando-se as principais conclusões em termos de desempenho e

escalabilidade.

Palavras-chave

IPTV, IMS, SIP, Streaming, QoS, QoE

iv

Abstract

This dissertation presents an Internet Protocol Television (IPTV) service architecture using Session

Initiation Protocol (SIP) for session and media control, based on the IP Multimedia Subsystem (IMS)

concept. The proposed IPTV architecture is suitable for scalable converged networks, and flexible

multimedia delivery of personalized streams over a variety of channels and networking infrastructures,

like High-Speed Local Area Network (LAN) or low-bandwidth mobile networks.

A new Quality of Service (QoS) adaptation method allows dynamic updates of session parameters,

such as bitrate and framerate, in order to maximize the Quality of Experience (QoE). This method is

based on end-system QoS monitoring, turning the solution suitable for live multimedia streaming

across multiple access networks and conditions.

The implementation details are centered on the IPTV Client prototype, and its functionalities are

closely related to the SIP IPTV AS that was implemented under the same research project. The

solution was tested on both a LAN and a 3G access network, and conclusions about client

performance and scalability are presented.

Keywords

IPTV, IMS, SIP, Streaming, QoS, QoE

v

Índice

Agradecimentos .................................................................................................................................. ii

Resumo ............................................................................................................................................. iii

Palavras-chave .................................................................................................................................. iii

Abstract ............................................................................................................................................. iv

Keywords ........................................................................................................................................... iv

Índice .................................................................................................................................................. v

Lista de Tabelas ................................................................................................................................ ix

Lista de Figuras .................................................................................................................................. x

Lista de Acrónimos ........................................................................................................................... xii

Capítulo 1 - Introdução ........................................................................................................................1

1.1 - Enquadramento .......................................................................................................................1

1.2 - Motivação e Objectivos ............................................................................................................2

1.3 - Contribuições e Resultados Alcançados ..................................................................................3

1.4 - Estrutura do Documento ..........................................................................................................4

Capítulo 2 - Estado da Arte .................................................................................................................5

2.1 - Vídeo sobre IP .........................................................................................................................5

2.1.1 - Streaming vs Downloading ................................................................................................6

2.1.2 - Progressive-Downloading ..................................................................................................6

2.1.3 - Video-on-Demand .............................................................................................................7

2.1.4 - Live Streaming ..................................................................................................................7

2.2 - IPTV ........................................................................................................................................7

2.2.1 - Características do IPTV ....................................................................................................8

2.2.2 - Arquitectura Genérica .......................................................................................................8

2.2.3 - Tecnologias de Acesso ................................................................................................... 10

2.2.4 - Funcionalidades e Serviços ............................................................................................. 12

2.3 - Codificação Áudio e Vídeo ..................................................................................................... 14

2.3.1 - Necessidade de Compressão .......................................................................................... 15

2.3.2 - Normas de Codificação e Compressão............................................................................ 15

2.4 - Protocolos de Rede ............................................................................................................... 20

vi

2.4.1 - SIP – Session Initiation Protocol ...................................................................................... 20

2.4.2 - RTSP – Real Time Streaming Protocol ............................................................................ 21

2.4.3 - RTP – Real Time Transport Protocol ............................................................................... 22

2.4.4 - IP Multicast ..................................................................................................................... 24

2.4.5 - SDP – Session Description Protocol ................................................................................ 25

2.5 - Garantias de Qualidade de Serviço em IPTV ......................................................................... 26

2.5.1 - Segurança e Garantias de Serviço .................................................................................. 26

2.5.2 - Qualidade de Serviço ...................................................................................................... 27

2.5.3 - Qualidade de Experiência ............................................................................................... 28

2.6 - Internet TV ............................................................................................................................ 29

2.6.1 - Comparação com IPTV ................................................................................................... 30

2.7 - Plataformas IPTV .................................................................................................................. 31

2.7.1 - Siemens Surpass Home Entertainment ........................................................................... 31

2.7.2 - Alcatel / Microsoft TV IPTV Edition .................................................................................. 32

2.8 - Clientes IPTV ........................................................................................................................ 33

2.8.1 - Sistemas Terminais ......................................................................................................... 33

2.8.2 - Arquitectura Funcional .................................................................................................... 33

2.9 - Resumo ................................................................................................................................. 34

Capítulo 3 - Integração do IPTV na Arquitectura IMS ........................................................................ 35

3.1 - Introdução ............................................................................................................................. 35

3.2 - Requisitos de Integração ....................................................................................................... 36

3.3 - Arquitectura IPTV de próxima geração baseada em IMS ....................................................... 37

3.3.1 - Controlo de Serviço e de Sessão em IPTV-IMS ............................................................... 38

3.3.2 - Sinalização para serviços IPTV Unicast baseada em IMS ............................................... 38

3.4 - Resumo ................................................................................................................................. 39

Capítulo 4 - Arquitectura da Solução ................................................................................................. 41

4.1 - O Projecto My eDirector 2012 ................................................................................................ 41

4.2 - Requisitos da Solução ........................................................................................................... 41

4.3 - Descrição do Sistema Desenvolvido ...................................................................................... 42

4.3.1 - Arquitectura Geral ........................................................................................................... 43

vii

4.3.2 - Módulos do Cliente IPTV ................................................................................................. 44

4.3.3 - Funcionalidades da Solução............................................................................................ 45

4.4 - Modelo de Sinalização Proposto para IPTV Unicast ............................................................... 45

4.4.1 - Motivação ....................................................................................................................... 45

4.4.2 - Modelo de Comunicação ................................................................................................. 46

4.5 - Integração da Solução na Arquitectura IMS ........................................................................... 50

4.6 - Resumo ................................................................................................................................. 51

Capítulo 5 - Implementação .............................................................................................................. 52

5.1 - Introdução ............................................................................................................................. 52

5.2 - Fases de Desenvolvimento .................................................................................................... 52

5.3 - Ferramentas e Bibliotecas Utilizadas ..................................................................................... 53

5.3.1 - GNU libosip ..................................................................................................................... 53

5.3.2 - libVLC ............................................................................................................................. 54

5.3.3 - GTK+ .............................................................................................................................. 55

5.3.4 - Glade .............................................................................................................................. 55

5.4 - Implementação dos Módulos ................................................................................................. 56

5.4.1 - Módulo de Sinalização .................................................................................................... 56

5.4.2 - RTP Extractor e Decoder ................................................................................................ 56

5.4.3 - Monitorização QoS .......................................................................................................... 57

5.4.4 - Interface Gráfica ............................................................................................................. 57

5.4.5 - Visualização .................................................................................................................... 58

5.4.6 - Gestão de Preferências ................................................................................................... 59

5.5 - Limitações da Implementação................................................................................................ 59

5.5.1 - Dificuldades na transição suave entre streams ................................................................ 59

5.5.2 - Monitorização de QoS ..................................................................................................... 60

5.5.3 - Segurança ...................................................................................................................... 60

5.5.4 - Recuperação de falhas ................................................................................................... 60

5.6 - Resumo ................................................................................................................................. 61

Capítulo 6 - Avaliação da Solução ..................................................................................................... 62

6.1 - Avaliação do Protótipo do cliente IPTV .................................................................................. 62

viii

6.2 - Ambiente e Metodologia de Teste .......................................................................................... 63

6.2.1 - Equipamentos ................................................................................................................. 65

6.2.2 - Ferramentas e tipos de Teste .......................................................................................... 65

6.2.3 - Procedimentos ................................................................................................................ 66

6.3 - Avaliação de Resultados ....................................................................................................... 68

6.3.1 - Testes de Desempenho da Rede de Acesso CDMA ........................................................ 68

6.3.2 - Testes Funcionais ........................................................................................................... 73

6.3.3 - Testes Não-Funcionais ................................................................................................... 75

6.4 - Resumo ................................................................................................................................. 78

Capítulo 7 - Conclusões e Trabalho Futuro ....................................................................................... 79

7.1 - Conclusões ........................................................................................................................... 79

7.2 - Trabalho Futuro ..................................................................................................................... 80

Referências Bibliográficas ................................................................................................................. 81

Anexo 1 – Formatos e normas suportados pela libVLC ..................................................................... 84

Anexo 2 – Exemplo de utilização da libVLC....................................................................................... 86

Anexo 3 – Captura de Mensagens de Sinalização ............................................................................. 87

ix

Lista de Tabelas

Tabela 2.1 – Comparação das tecnologias DSL [28] ......................................................................... 12

Tabela 2.2 – Comparação das normas de codificação [34] [14] ......................................................... 20

Tabela 2.3 – Comparação do IPTV com Internet TV [12] [64] ............................................................ 30

Tabela 6.1 – Avaliação de Funcionalidades do Protótipo ................................................................... 62

Tabela 6.2 – Comparação RTSP / SIP para serviços unicast............................................................. 63

Tabela 6.3 – Testes efectuados e ferramentas utilizadas .................................................................. 65

Tabela 6.4 – Medições do RTT na rede CDMA ................................................................................. 69

Tabela 6.5 – Taxa de Pacotes Perdidos ............................................................................................ 72

Tabela 6.6 – Tempos de execução das funcionalidades .................................................................... 73

Tabela 6.7 – Classificação MOS das streams – CDMA´ .................................................................... 75

Tabela 6.8 – Classificação MOS das streams – LAN ......................................................................... 75

x

Lista de Figuras

Figura 2.1 - Previsões de crescimento do IPTV [20] ............................................................................8

Figura 2.2 - Arquitectura Genérica IPTV ..............................................................................................9

Figura 2.3 - IPTV sobre rede ADSL [21] ............................................................................................ 12

Figura 2.4 – Elementos no processo de codificação de áudio e vídeo ............................................... 14

Figura 2.5 – Estrutura do GOP e dependências entre tramas [36] ..................................................... 16

Figura 2.6 – Evolução das normas de codificação e compressão [38] ............................................... 19

Figura 2.7 - Estabelecimento de sessão SIP [47] .............................................................................. 21

Figura 2.8 – Exemplo de utilização do RTSP em sessão de VoD ...................................................... 22

Figura 2.9 – Cabeçalho do Pacote RTP [37] ...................................................................................... 23

Figura 2.10 – Mecanismos de Encaminhamento IP [51] .................................................................... 24

Figura 2.11 – Implementação de Multicast [49].................................................................................. 24

Figura 2.12 – Descrição de SDP [5] .................................................................................................. 26

Figura 2.13 – Relação entre QoE e QoS (adaptado) [13] ................................................................... 28

Figura 2.14 – Impacto visual da perda de Tramas B e I ..................................................................... 29

Figura 2.15 - Arquitectura Genérica Internet TV [21] .......................................................................... 30

Figura 2.16 – Arquitectura IPTV da solução Siemens [65] ................................................................. 31

Figura 2.17 – Arquitectura da plataforma Microsoft TV IPTV Edition [66]. .......................................... 32

Figura 2.18 – Arquitectura Funcional de Cliente IPTV [70] ................................................................. 33

Figura 3.1 – Evolução das redes actuais ........................................................................................... 35

Figura 3.2 – Arquitectura IPTV baseada em IMS em redes de próxima geração [22]. ........................ 37

Figura 3.3 – VoD na Arquitectura IMS [22] ........................................................................................ 39

Figura 4.1 – Arquitectura da Rede ..................................................................................................... 43

Figura 4.2 – Módulos da Arquitectura do Cliente ............................................................................... 44

Figura 4.3 – Diagrama de mensagens cliente-servidor ...................................................................... 47

Figura 4.4 – Mensagem SIP/SDP para estabelecimento da sessão ................................................... 48

Figura 4.5 - Mensagem SIP/SDP para pausa de conteúdos .............................................................. 49

Figura 4.6 - Mensagem SIP/SDP para alteração de qualidade .......................................................... 49

Figura 4.7 - Mensagem SIP/SDP para terminar a sessão .................................................................. 50

Figura 4.8 – Integração da Solução na Arquitectura IMS ................................................................... 51

Figura 5.1 – Fases de Desenvolvimento ............................................................................................ 53

Figura 5.2 – Ferramentas e bibliotecas utilizadas .............................................................................. 53

Figura 5.3 – Solução Completa VideoLAN para streaming [74] .......................................................... 54

Figura 5.4 – Ferramenta GLADE utilizada no desenho da Interface Gráfica....................................... 55

Figura 5.5 – Máquina de estados do módulo de Sinalização.............................................................. 56

Figura 5.6 – Interface Gráfica ............................................................................................................ 58

Figura 5.7 - Janela de Visualização de Vídeo com Interface Gráfica .................................................. 58

Figura 6.1 – Ambiente de Testes CDMA/LAN .................................................................................... 64

Figura 6.2 – Escala contínua de classificação [63]............................................................................. 68

xi

Figura 6.3 – Atraso e jitter no modo de ligação EV-DO ...................................................................... 69

Figura 6.4 – Atraso e jitter no modo de ligação 1xRTT ...................................................................... 69

Figura 6.5 - Débito instantâneo no canal descendente (modo 1xRTT) ............................................... 70

Figura 6.6 - Débito instantâneo no canal descendente (modo EV-DO) – Período Manhã ................... 71

Figura 6.7 - Débito instantâneo no canal descendente (modo EV-DO) – Período Tarde .................... 71

Figura 6.8 – Débito efectivo no canal descendente nos modos 1xRTT e EV-DO ............................... 71

Figura 6.9 – Adaptação dinâmica do nível de qualidade .................................................................... 74

Figura 6.10 – Classificação MOS das streams .................................................................................. 76

Figura 6.11 – Utilização do CPU da máquina cliente ......................................................................... 77

Figura 6.12 – Carga média de sistema da máquina cliente ................................................................ 77

Figura 6.13 - Utilização de memória RAM da máquina cliente ........................................................... 78

xii

Lista de Acrónimos

3GPP

ARQ

ASM

AVC

BSS

CABAC

CAVLC

CDMA

CSCF

DCT

DRM

DSCP

DSL

DSLAM

DVB

DVMRP

EPG

FEC

FTTC

FTTH

GUI

HDTV

HTTP

IGMP

IMS

IP

IPTV

ITU

LAN

MDF

MMSH

MOSPF

MPLS

NACF

NGN

OSS

PC

PDA

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

Third Generation Partnership Project

Automatic Repeat Request

Any Source Multicast

Advanced Video Coding

Business Support System

Content Based Adaptive Binary Arithmetic Coding

Content Adaptive Variable Length Coding

Code Division Multiplex Access

Call Session Control Function

Discrete cosine transform

Digital Rights Management

Differentiated Services Code Points

Digital Subscriber Line

Digital Subscriber Line Access Multiplexer

Digital Video Broadcasting

Distance Vector Multicast Routing Protocol

Electronic Progam Guide

Forward Error Correction

Fiber to the Curb

Fiber to the Home

Graphical User Interface

High-Definition Television

Hypertext Transport Protocol

Internet Group Management Protocol

IP Multimedia Subsystem

Internet Protocol

Internet Protocol Television

International Telecommunication Union

Local Area Network

Media Distribution Functions

Microsoft Media Server over HTTP

Multicast Open Shortest Path First Protocol

Multi Protocol Label Switching

Network Access Control Function

Next Generation Network

Operational Support System

Personal Computer

Personal Digital Assistant

xiii

PIM

PLC

PSNR

PSTN

PVR

QoE

QoS

RACF

RDP

RF

RTCP

RTP

RTSP

RTT

SCF

SDI

SDP

SDTV

SIP

SMPTE

SSM

STB

TISPAN

ToS

TTL

UPSF

URI

VLAN

VoD

VoIP

WAN

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

Protocol Independent Multicast

Power Line Communications

Peak signal-to-noise Ratio

Public Switch Telephone Network

Personal Video Recording

Quality of Experience

Quality of Service

Resource Access Control Function

Remote Desktop Protocol

Radio Frequência

Real-Time Control Protocol

Real-Time Transport Protocol

Real-Time Streaming Protocol

Round-Trip-Time

Service Control Functions

Serial Digital Interface

Session Description Protocol

Standard-Definition Television

Session Initiation Protocol

Society of Motion Picture and Television Engineers

Single Source Multicast

Set-Top-Box

Telecommunications and Internet converged Services and Protocols for Advanced

Networking

Type of Service

Time-to-Live

User Profile Server Function

Universal Resource Identifier

Virtual Local Area Network

Video-on-Demand

Voice over Internet Protocol

Wide Area Network

1

Capítulo 1 - Introdução

Este capítulo aborda o enquadramento da dissertação, a motivação do trabalho desenvolvido, as

principais contribuições e a estrutura geral do documento.

1.1 - Enquadramento

A implementação do protocolo IP em diferentes tecnologias de acesso, como DSL, 3G e redes

DOCSIS [1], permitiu uma convergência de serviços de diversa natureza. Com a massificação da

tecnologia IP, os operadores de telecomunicações começaram a canalizar a sua oferta para pacotes

de serviços Triple-Play: serviço de voz (telefonia), vídeo (televisão) e serviços de dados (e.g.,

Internet), suportados numa única tecnologia.

A convergência de serviços totalmente baseados em IP, potenciou o aparecimento de uma nova

tecnologia de distribuição de televisão, que revolucionou o conceito de televisão como sempre o

conhecemos. Esta tecnologia surgiu em meados de 2002 no Japão, ficando conhecida como Internet

Protocol Television (IPTV) [2]. O IPTV suporta-se na tecnologia streaming para distribuir conteúdos

televisivos em formato digital sobre redes IP, que são geridas de forma a garantirem níveis

adequados de qualidade de serviço (QoS) e experiência (QoE), interactividade e disponibilidade.

Deste modo, o IPTV possui uma infra-estrutura de rede diferente dos serviços de TV tradicionais: os

conteúdos são requisitados pelos utilizadores, de acordo com as suas preferências e interesses. Isto

só é possível devido à utilização do protocolo IP, que através de um canal interactivo bidireccional

interliga utilizadores e operadores, num modelo semelhante ao da Internet. Por este motivo o IPTV é

considerado a killer application, das redes de próxima geração (NGN).

A implementação do IPTV constitui um conjunto de desafios: integração de diferentes operadores e

diferentes infra-estruturas, sistemas de provisão de recursos, estabilidade e disponibilidade da rede a

longo prazo, e níveis de QoS competitivos face às redes de Televisão concorrentes, como o cabo [2].

Em termos de convergência, o IP Multimedia Subsystem (IMS), é uma arquitectura de referência para

serviços All-IP, permitindo a convergência fixo-móvel através da independência no meio de acesso.

Constitui uma plataforma única de controlo, facilitando a implementação de serviços IP multimédia.

Foi inicialmente especificada pela Third Generation Partnership Project (3GPP), tendo sido

posteriormente adoptada e actualizada pelo 3GPP2 e pelo TISPAN [3].

A União Internacional das Telecomunicações – ITU, definiu o modelo e a arquitectura de referência

para a integração do IPTV nas redes NGN, nomeadamente na arquitectura IMS. Consideram-se

quatro papéis fundamentais, que podem ser desempenhados por entidades diferentes: Prestador de

conteúdos, que produz e vende conteúdos; Prestador do Serviço, que adquire os conteúdos e

disponibiliza-os aos clientes através da rede; O operador da rede, que assegura a ligação entre

clientes e prestadores de serviço; Clientes – consumidores finais dos conteúdos.

A disponibilização de uma plataforma única e interactiva para distribuição de serviços IP multimédia

permite que, no caso do IPTV, sejam oferecidos serviços inovadores no mundo da televisão:

2

Televisão Interactiva – Serviços tradicionais em formato padrão (SDTV) e em alta definição

(HDTV), serviços adicionais por subscrição (Jogos, Salas de conversa), Guia Electrónico de

Programação (EPG), Áudio 5.1 digital, múltiplas legendas e dobragens áudio, etc.

Serviços a Pedido – Vídeo (VoD) e Música (MoD) a pedido, mediante subscrição.

Publicidade – Interactiva e segmentada, baseada nas preferências do utilizador.

Serviços de Interesse Público – Avisos de emergência, comunicados oficiais, etc.

Para a disponibilização dos serviços, é fundamental que seja utilizado um protocolo de sinalização,

responsável por iniciar, controlar e terminar as sessões multimédia. No caso do IPTV existe a

necessidade de sinalizar funções associadas ao controlo do Vídeo: Play, Pause, Stop, Avançar e

Retroceder. Estas são vulgarmente designadas por Trick Functions.

O Session Initiation Protocol (SIP) [4], foi escolhido como protocolo de sinalização de referência na

arquitectura IMS, devido à sua simplicidade e fácil extensão, podendo as suas mensagens incorporar

descritores de qualquer tipo de aplicação multimédia através do protocolo SDP [5]. O SIP permite

controlar sessões de diversas aplicações, inclusive que utilizem os seus próprios protocolos de

controlo, estabelecendo uma interface comum entre todos os serviços na mesma arquitectura.

A utilização do protocolo SIP para controlo da sessão e do serviço IPTV é ainda um desafio, tendo

sido frequentemente considerada e rejeitada devido à não-existência de mensagens SIP que

implementem directamente as Trick-Functions [2, 6, 7, 8, 9].

1.2 - Motivação e Objectivos

No mercado actual das telecomunicações cada operador apresenta a sua própria solução para a

prestação do serviço de televisão.

No caso do IPTV, as soluções existentes são fechadas e caracterizam-se pelas funcionalidades

desenvolvidas pelos fornecedores. Cada solução é específica para um tipo de oferta e apresenta uma

plataforma própria, que está relacionada com o meio de acesso ao serviço. São exemplos os serviços

IPTV residencial com acesso DSL, ou serviços MobileTV para redes móveis de terceira geração.

A actual necessidade de existência de uma plataforma dedicada para cada solução está de certa

forma relacionada com a necessidade de fornecer níveis de qualidade de serviço adequados à

transmissão de sinais de vídeo sobre redes IP. Uma oferta de televisão residencial possui requisitos

diferentes de um serviço de televisão para dispositivos móveis, pois as expectativas dos utilizadores

face à qualidade de experiência são diferentes.

Em termos da rede IP, isto significa a existência de condições diferentes em termos de largura de

banda, perdas na rede, atrasos e sua variação. Os sistemas são dimensionados, de forma a que os

conteúdos sejam adaptados face à Qualidade de Serviço (QoS) e capacidade da rede. Esta opção

pode conduzir a situações de desperdício ou subaproveitamento de recursos na rede.

Com a convergência fixo-móvel [3], surge a necessidade da existência de uma plataforma IPTV

convergente, independente do meio de acesso. A arquitectura desta nova plataforma deverá adaptar-

3

se às condições da rede e necessidades de cada utilizador, oferecendo sempre a máxima qualidade

de experiência (QoE) possível.

Esta dissertação tem como objectivo desenhar uma arquitectura IPTV para redes de acesso

heterogéneas, com adaptação dos conteúdos às características do acesso e do terminal. Esta

arquitectura será baseada na arquitectura IMS, utilizando o protocolo SIP para estabelecimento e

controlo da sessão multimédia.

De acordo com esta arquitectura, será implementado um protótipo de cliente para o serviço IPTV, que

é responsável por analisar o estado e características da rede, negociando os requisitos da sessão

com o servidor.

A arquitectura desenvolvida incorpora um servidor de streaming para serviços IPTV – SIP IPTV

Server – a desenvolver paralelamente noutro trabalho de dissertação. Este servidor é responsável por

enviar os conteúdos aos clientes.

1.3 - Contribuições e Resultados Alcançados

O trabalho descrito nesta dissertação foi desenvolvido no âmbito do projecto europeu My eDirector

2012 [10], para além doutros requisitos de um operador de rede móvel 3G CDMA2000 a operar em

Portugal.

As principais contribuições da dissertação são:

O estudo aprofundado das arquitecturas e plataformas existentes para entrega de serviços

IPTV ao cliente, através de diferentes meios de acesso.

O estudo da integração do serviço IPTV em arquitecturas baseadas em redes de próxima

geração, nomeadamente a arquitectura IMS.

O desenvolvimento de uma nova arquitectura para serviços IPTV baseada na arquitectura

IMS, para redes de acesso heterogéneas.

A implementação de um protótipo de cliente IPTV, como parte integrante da nova

arquitectura.

A avaliação da solução final em ambiente heterogéneo.

A elaboração e publicação de um artigo científico sobre o trabalho desenvolvido [11].

A arquitectura desenvolvida utiliza um modelo de sinalização inovador – o estabelecimento e controlo

da sessão efectuado através do protocolo SIP. O SIP é o protocolo determinado pelo 3GPP e 3GPP2

para as funções de controlo dos serviços na arquitectura IMS.

4

1.4 - Estrutura do Documento

Este documento encontra-se organizado em sete capítulos. Embora o seu encadeamento siga uma

ordem lógica, cada capítulo pode ser lido independentemente, encontrando-se estruturado em três

secções principais: Introdução, Desenvolvimento e Resumo do capítulo.

O segundo capítulo descreve o estado da arte na área desta dissertação, abordando os conceitos,

tecnologias, protocolos, arquitecturas e plataformas na área do IPTV.

O terceiro capítulo aborda a integração do IPTV em arquitecturas de redes de próxima geração,

nomeadamente na arquitectura IMS. Esta arquitectura é considerada a arquitectura referência para a

convergência de serviços IP.

O quarto capítulo descreve em detalhe a arquitectura proposta. Esta solução foca-se numa

arquitectura para um protótipo de cliente IPTV que utiliza um modelo de sinalização baseado no

protocolo SIP para estabelecimento e controlo da sessão vídeo streaming em modo unicast.

O quinto capítulo descreve o processo de implementação da solução, destacando-se as ferramentas

utilizadas no desenvolvimento dos módulos da arquitectura, as dificuldades encontradas e as

limitações da solução.

No sexto capítulo descreve-se o processo de avaliação da solução, considerando o ambiente e

metodologia de teste, os tipos de testes efectuados, e os principais resultados obtidos.

O capítulo final inclui uma análise crítica a todo o trabalho desenvolvido, as conclusões a reter, e

propostas para trabalho futuro.

5

Capítulo 2 - Estado da Arte

Este capítulo descreve o trabalho relacionado na área desta dissertação, nomeadamente os

principais conceitos, arquitecturas, protocolos e normas relacionadas com o IPTV.

2.1 - Vídeo sobre IP

O Vídeo sobre IP resulta da combinação da utilização de redes de comutação de pacotes com

tecnologias de Vídeo Digital, estando actualmente em forte expansão.

Na sua forma nativa as tecnologias de Vídeo Digital e transporte IP possuem requisitos próprios que

não combinam na perfeição. O Vídeo Digital é representado sob a forma de um fluxo de informação

constante, com requisitos de sincronismo e precisão temporal. O seu transporte é normalmente

efectuado em canal próprio. O IP funciona em modo de comutação de pacotes, sem garantia de

entrega, e transporta informação de diferentes tipos no mesmo canal.

Apesar desta aparente incompatibilidade, existem razões que tornaram o Vídeo sobre IP popular e

apelativo [12]:

As redes IP de banda larga estão acessíveis a um público-alvo cada vez mais vasto,

permitindo uma rápida expansão dos serviços de vídeo sem necessidade de construção de

nova infra-estruturas.

O IP permite a criação de serviços de vídeo interactivos, devido à sua bidirecionalidade

O custo reduzido das redes IP face a outras tecnologias

A facilidade de integração com outros serviços baseados na mesma rede.

A flexibilidade do IP, não se restringindo a uma tecnologia física de comunicação, e sendo

suportado por diferentes tipos de dispositivos.

A ubiquidade do IP, por ser o protocolo de acesso à Internet em todo o mundo.

A integração do Vídeo Digital com o IP, desperta questões relacionadas com a qualidade do vídeo ao

nível dos extremos. Existem diversos factores que afectam o nível de qualidade, relacionados com o

codificador, e com a rede de transporte. De entre esses factores salientam-se o nível de compressão

introduzido pelo codificador, as características do meio de transmissão, e a congestão da rede. O

codificador afecta directamente a qualidade pois pode provocar distorção no sinal e atrasos no

processamento. O meio de transmissão pode provocar a perda de dados e atraso na rede. A

congestão na rede pode provocar perdas, atrasos e variações de atraso – jitter. Deste modo, surge a

necessidade de garantir níveis de serviço adequados à transmissão de vídeo sobre IP.

A qualidade do vídeo sobre IP é afectada pelos seguintes parâmetros:

Atraso – tempo total que os pacotes transitam na rede até serem entregues no receptor.

Variação de Atraso (jitter) – variação entre o atraso de pacotes consecutivos de um dado

fluxo. Não deve exceder os 50 ms [13].

6

Atraso entre Streams – atraso relativo entre as streams de áudio e vídeo, baseia-se nos

diferentes valores de atraso das duas streams num dado instante. Este atraso provoca um

desfasamento temporal do áudio com o vídeo no momento da visualização.

Perdas de Pacotes – provocam a perda de informação. Embora o vídeo seja tolerante a

pequenas perdas, este factor é importante devido às elevadas taxas de compressão das

normas de codificação e compressão actualmente utilizadas.

2.1.1 - Streaming vs Downloading

O método de streaming multimédia, em particular de áudio e vídeo, é um processo em tempo real que

permite o envio e recepção de dados multimédia comprimidos – streams – de um servidor para um

cliente, de forma que o segundo inicie a experiência de visualização antes de toda a informação ser

transmitida [14]. O cliente dispõe de um buffer onde armazena temporariamente as streams

recebidas, descodifica-as, e apresenta-as de seguida ao utilizador. Toda a informação contida no

buffer de recepção é eliminada imediatamente após a sua visualização [15].

O streaming multimédia oferece uma experiência acrescida ao utilizador, permitindo a utilização de

Trick-functions que implementam comandos Personal Video Recorder (PVR) tais como Play, Pausa,

Fast-Forward, etc.

Este método pode ser utilizado para transmissão de conteúdos em directo (e.g., emissão TV) ou de

conteúdos pré-gravados, servidos a pedido do cliente.

Por contraste, no método de Downloading a visualização só é efectuada quando a totalidade do

conteúdo é transferida do servidor e armazenada no cliente - Download-and-Play [16]. Este método é

o utilizado tradicionalmente para a transferência de ficheiros pela Internet.

2.1.2 - Progressive-Downloading

O método de progressive-downloading, também denominado de super-streaming [17] é um híbrido

dos dois apresentados anteriormente, permitindo a visualização do conteúdo enquanto ocorre o

download entre o servidor e o cliente.

Existem duas diferenças fundamentais entre este método e o de streaming [16]. A primeira diferença

está relacionada com o facto de o cliente não ser servido em tempo-real, pelo que a visualização

pode ser interrompida se num dado instante não existirem mais dados na memória de entrada do

cliente. Isto acontece quando o débito binário da transferência é inferior ao débito da stream servida.

A segunda diferença está relacionada com o armazenamento das streams recebidas num buffer de

maior capacidade, normalmente em memória ou disco rígido, não sendo descartadas após a

visualização. Este método permite que o utilizador visualize o conteúdo transferido as vezes que

desejar até que encerre a aplicação. Este método é normalmente utilizado para a transmissão de

conteúdos que necessitem de uma largura de banda superior à ligação do cliente [18]. O fenómeno

Youtube [19] é um exemplo de utilização deste método no mundo da Internet.

7

2.1.3 - Video-on-Demand

O método de Video-on-Demand permite disponibilizar conteúdos a pedido aos seus utilizadores, isto

é, cada utilizador selecciona o programa exacto que pretende ver num dado momento. Normalmente,

os conteúdos a disponibilizar estão pré-gravados como ficheiros em servidores de streaming [14].

Após uma fase inicial de negociação da sessão, o utilizador é servido por uma ligação individual, que

entrega um fluxo de dados à aplicação cliente em tempo-real.

O vídeo streaming a pedido possui diversas vantagens: Os conteúdos disponibilizados só são

servidos na rede de transporte quando algum utilizador os pretender consumir, economizando

recursos. No que diz respeito a direitos de visualização, tratando-se de um pedido individual o

sistema pode facilmente identificar o cliente, e autorizar ou não o acesso ao conteúdo [16]. Permite

ainda a utilização de comandos PVR.

Tratando-se de uma transmissão de dados individualizada para cada utilizador, é normalmente

efectuada em unicast, o que facilita a personalização da sessão. Embora o custo do sistema aumente

consideravelmente com o número de utilizadores devido à replicação de streams para o mesmo

conteúdo, não se disponibiliza em modo multicast pois tornaria complexa a implementação de

comandos PVR [18].

2.1.4 - Live Streaming

O método streaming de conteúdos Live é utilizado normalmente para transmissão de emissões

televisivas, Vídeo-conferências, eventos, e destina-se a um grupo de utilizadores em massa.

O conteúdo é gravado e codificado em tempo-real. As streams áudio e vídeo são enviadas

directamente para um servidor de streaming, e injectadas na rede de transporte através de um canal

multicast com um valor de TTL (Time-to-live) elevado [15]. Com este método é possível atingir uma

audiência elevada, sem se aumentar consideravelmente o custo da infra-estrutura da rede.

2.2 - IPTV

Os sistemas de IPTV têm despertado o interesse a muitas operadoras de telecomunicações,

começando a ganhar uma importância significativa no mercado da televisão por subscrição. Estima-

se que o número de clientes IPTV a nível mundial ultrapasse os 50 milhões em 2010 [12] [20].

Este crescimento tem causado um efeito disruptivo nos modelos de negócio dos operadores de TV

tradicionais, com a entrada de novos concorrentes no mercado [21], nomeadamente operadores

anteriormente vocacionados para serviços de voz fixa e comunicação de dados.

O gráfico da Figura 2.1 ilustra as previsões de crescimento do IPTV até 2012:

8

Figura 2.1 - Previsões de crescimento do IPTV [20]

A oferta típica de um serviço de IPTV considera um pacote de serviços designado triple-play

(agregando os serviços de dados, vídeo e voz) em regime de subscrição, diferenciando-se das

ofertas de televisão por cabo ou satélite pela personalização e interactividade inerentes à utilização

de uma rede IP. A existência de um canal de retorno torna possível a implementação de um conjunto

de funcionalidades complementares que enriquecem a experiência de utilização. A TV aproxima-se

cada vez mais do computador, e da Internet.

2.2.1 - Características do IPTV

Segundo o IPTV Focus Group1 [22], IPTV é um acrónimo para Internet Protocol Television e é

definido como um serviço streaming multimédia de Televisão distribuído sobre uma rede IP gerida,

garantindo níveis adequados de QoS, segurança, interactividade e disponibilidade [21].

As principais características do IPTV são a distribuição dos conteúdos em Rede IP Privada, formato

do conteúdo uniformizado, múltiplos canais e streaming contínuo dos conteúdos.

Para ser possível entregar continuamente centenas de canais de televisão aos subscritores, uma

rede de distribuição de IPTV tem de ser cuidadosamente planeada e projectada. Isto só é possível

utilizando uma rede privada gerida pelo operador IPTV. Desta forma todo o tráfego pode ser

controlado, garantindo os níveis adequados de qualidade de serviço [12].

2.2.2 - Arquitectura Genérica

Uma plataforma de IPTV segue o modelo cliente-servidor e apresenta quatro áreas principais [23] :

Headend

Rede de Core e Transporte

Rede de Acesso

Rede Doméstica

1 ITU-T FG IPTV – Grupo do ITU-T que tem como objectivo coordenar e desenvolver standards globais para o

IPTV

9

A Figura 2.2 ilustra uma arquitectura genérica do serviço IPTV:

Figura 2.2 - Arquitectura Genérica IPTV

O Headend é responsável pela aquisição, codificação, cifra e ingestão dos sinais áudio e vídeo na

rede. É constituído por diversos componentes:

Receptor de sinal – podendo ser terrestre ou por satélite. No caso de ser por satélite,

transforma os sinais modelados em L-Band para formato Serial Digital Interface (SDI) a 270

Mbit/s.

Routers SDI, responsáveis por distribuir os vários canais em formato SDI pela bateria de

codificadores.

Codificadores, procedem à codificação dos sinais vídeo e áudio, encapsulando-os em

pacotes IP.

Servidor de Protecção de Conteúdos

Switch-Router IP, que introduz os canais na rede IP-MPLS

Os sinais são entregues no headend através de uma rede de contribuição satélite ou terrestre. A

contribuição via satélite é normalmente utilizado para os canais internacionais, enquanto a

contribuição via terrestre é utilizada para canais nacionais com ligações em fibra óptica até ao

Headend. Os sinais recebidos via satélite são desmodulados e convertidos para formato de vídeo não

comprimido SDI (270 Mbit/s). Posteriormente são encaminhados para a bateria de codificadores,

onde são comprimidos com uma determinada norma de codificação. Á saída do codificador, são

cifrados e encapsulados em datagramas IP, sendo finalmente encaminhados para a rede de

transporte.

10

A rede de transporte IP/MPLS é uma rede IP privada responsável pelo transporte dos conteúdos

comprimidos ao longo de toda a rede do operador, implementando o controlo de QoS, com garantia

de entrega eficiente dos datagramas IP. Os conteúdos são encaminhados para as centrais locais,

onde serão distribuídos para os subscritores do serviço através da rede de acesso.

A rede de acesso, que numa rede fixa se designa vulgarmente last-mile ou first-mile é o troço da rede

que interliga a rede doméstica do utilizador com a rede core. Um dos maiores desafios dos

operadores é garantir uma largura de banda suficiente neste troço, que permita a entrega do serviço

IPTV [21].

A rede doméstica está localizada dentro da casa do utilizador, e por essa razão gera grandes

dificuldades de operação e manutenção aos operadores, devido às diferentes condições encontradas

na habitação de cada cliente [12]. Genericamente a rede é constituída por uma Gateway residencial

que incorpora um modem de ligação à rede de acesso, filtros spliters para separação das bandas de

sinal, e por uma Set-Top-Box, responsável pela descodificação dos sinais de audio e vídeo, que

estabelece a interface entre o utilizador e o Middleware do serviço. A distribuição dos sinais dentro da

casa do utilizador pode ser feita através de diversas tecnologias, das quais se destacam a Ethernet,

Wireless 802.11x e Power Line Communications (PLC) por serem as mais utilizadas.

A plataforma de Middleware é responsável por efectuar a gestão dos serviços, controlar os servidores

de vídeo, o acesso condicionado dos subscritores e implementar o serviço EPG. Possui interfaces

com os sistemas Operational Support System e Business Support System (OSS/BSS), para efeitos

de taxação. O Middleware é integrado com o Headend, a STB e os servidores de VoD para permitir a

automatização das operações de activação e subscrição de serviços.

2.2.3 - Tecnologias de Acesso

Existem vários tipos de tecnologias de acesso com requisitos de largura de banda suficientes para o

IPTV, dos quais se destacam [21]:

Redes Fiber-to-the-Curb e Fiber-to-the-Home (FTTC/FFTH)

Redes DSL

Redes DOCSIS

Redes Satélite

Redes de Acesso Rádio

As redes FTTH e suas variantes têm sido promovidas desde a década de 90, mas as suas

implementações foram sucessivamente adiadas devido aos elevados custos de infra-estrutura e

relutância dos consumidores em pagar preços elevados por serviços novos [24]. O aumento da

procura de serviços de dados com requisitos elevados de largura de banda, associado à redução do

preço da fibra óptica, têm motivado o interesse pelo desenvolvimento de redes de fibra óptica de

larga escala, até à rede doméstica do cliente. A fibra apresenta diversas vantagens técnicas sobre as

tecnologias concorrentes, nomeadamente a imunidade a ruído electromagnético, redução de custos

11

operacionais e maior capacidade. Estima-se que o custo por canal de voz reduz-se com a raiz

quadrada da capacidade do sistema [24].

No que diz respeito a distribuição de sinais de vídeo, as redes DOCSIS [1] dos operadores de cabo

são normalmente utilizadas para sistemas Digital Video Broadcasting-Cable (DVB-C) [25], ou de

difusão analógica de canais de televisão em Rádio Frequência (RF). Estes são serviços concorrentes

do IPTV.

A Norma DOCSIS foi originalmente desenhada para transporte de dados, em particular Internet de

banda larga em redes Wide Area Network (WAN). As actuais evoluções da norma, nomeadamente a

DOCSIS 3.0, permitem um débito em downstream até 160 Mbit/s, endereçamento IPV6, IP

Multicasting e mecanismos de QoS e segurança associados, requisitos fundamentais para a

distribuição do serviço IPTV [21].

As redes satélite, devido ao seu elevado custo e elevada assimetria são tradicionalmente utilizadas

em sistemas DVB-S/S2 para distribuição de vídeo digital em broadcast. O IP começa a ganhar

terreno em distribuição de sinais de vídeo via ligações satélite [21], através de standards recentes

como a norma IPoS2, ou a DVB-RCS

3 [21], tirando partido da elevada escalabilidade da rede satélite

e da largura de banda do canal descendente. As principais limitações prendem-se com o custo,

débito baixo, a elevada latência (em média superior a 500ms), elevadas taxas de erro, e dificuldade

em estabelecer canais de retorno via satélite [26]. Este problema pode ser contornado, criando um

canal ascendente alternativo através de uma rede DSL ou 3G.

As redes de acesso rádio de última geração são mais uma alternativa disponível aos operadores para

distribuição de serviços de IPTV. As opções actualmente disponíveis são as redes WiMax [27] e 3G.

Os operadores de rede móvel de terceira geração disponibilizam canais com largura de banda

adequada à distribuição de IPTV e apresentam uma vantagem importante face às redes de acesso

fixas que é a possibilidade de distribuição do serviço a zonas remotas ou de difícil acesso não

cobertas por cobre ou fibra. As dificuldades inerentes à utilização destas tecnologias são as

condições de cobertura rádio, pois o meio de transmissão ar é muito susceptível às condições de

propagação dos sinais, tornando-se difícil garantir uma QoS adequada ao IPTV.

A tecnologia DSL é baseada em pares de cobre entrançados e está amplamente difundida, existindo

a nível mundial cerca de um bilião de linhas telefónicas e mais de 140 milhões de assinantes. É uma

tecnologia com elevada popularidade junto dos operadores, devido à facilidade e ao baixo custo da

instalação de serviços de banda larga, com reaproveitamento de toda a infra-estrutura de acesso

tradicionalmente utilizada pelo serviço telefónico público (PSTN4) [12].

A Figura 2.3 ilustra a utilização da tecnologia DSL para o serviço IPTV:

2 IPoS – IP over Satellite é uma norma TIA e ETSI. Utiliza a tecnologia DVB-S2 e suporta débitos no canal

descendente até 120 Mbit/s. 3 DVB-RCS está definida em ETSI EN 301 790, tendo sido desenvolvida pelo consórcio DVB. Define um canal

descendente com débitos na ordem dos 40 Mbit/s e canal ascendente de 2 Mbit/s. 4 PSTN – Public Switched Telephone Network, serviço de telefone fixo que funciona em comutação de circuitos.

12

Figura 2.3 - IPTV sobre rede ADSL [21]

O DSL possui diversas variantes, com requisitos e capacidades distintas. Em todos os sistemas

existe um compromisso técnico entre a distância do utilizador ao DSLAM e a velocidade da sua

ligação. Quanto maior for a distância, menor será o débito permitido, devido à atenuação na linha. Por

outro lado, as diferentes variantes operam a diferentes frequências, o que requer uma maior ou

menor distância ao DSLAM. De um modo geral as características são as apresentadas na Tabela 2.1:

Tecnologia DSL

Débito máximo

Downstream

Débito máximo

Upstream

Observações

ADSL 8 Mbit/s 512 Kbit/s Assimétrico ADSL2+ 24 Mbit/s 2 Mbit/s Assimétrico

HDSL 2 Mbit/s 2 Mbit/s Simétrico

SHDSL/SDSL 2.3 Mbit/s 2.3 Mbit/s Simétrico

VDSL 52 Mbit/s 13 Mbit/s Distâncias até 900m

Tabela 2.1 – Comparação das tecnologias DSL [28]

O aumento da largura de banda disponível no acesso, e os avanços nas tecnologias de compressão

de vídeo, motivaram o aparecimento de plataformas de entretenimento online, através de ofertas

livres de Internet TV e VoD, por exemplo o Joost [29]. O acesso a TV através da Internet é designado

Internet TV, possuindo algumas características comuns com o IPTV.

2.2.4 - Funcionalidades e Serviços

O IPTV permite a implementação de um conjunto de funcionalidades e serviços, destacando-se as

seguintes:

13

Time-shifted-TV

As emissões televisivas broadcast são armazenadas no buffer da STB, permitindo a utilização de

comandos PVR como a Pausa, repetição, ou retomar a emissão em directo.

Interactividade

A representação digital da informação, associada a uma rede bidireccional facilita a explosão das

capacidades interactivas associadas à experiência da televisão. Os utilizadores podem interagir com

serviços ou programas através da STB, acedendo a informação temática, serviços de televoto,

controlo da sequência de visualização, exprimir opiniões acerca de determinado conteúdo, entre

outros.

Personalização

Os serviços interactivos são um factor diferenciador do IPTV, possibilitando uma personalização do

serviço de televisão. Os utilizadores escolhem os programas desejados, no horário desejado.

Contrariamente à oferta tradicional que se revelava estática e dependente do pacote subscrito, com o

IPTV o utilizador pode construir a sua própria grelha personalizada de canais.

Mudança Instantânea de Canal

O tempo associado à troca de canal em IPTV é composto pela soma do tempo associado à chegada

da primeira âncora da stream, que dá início à descodificação do vídeo, com o tempo de construção

de um buffer de recepção. Esta memória do cliente é utilizada para compensar o jitter e perdas de

pacotes na rede [30].

Em termos da QoE torna-se indispensável que este tempo seja o mais curto possível, sendo que um

valor aceitável ronda os 500 ms [31]. Tipicamente o valor do Group of Pictures (GOP) é maior por

razões de optimização do valor do débito binário de vídeo, o que obriga à utilização de técnicas

especiais no instante da troca.

Uma técnica utilizada consiste no envio de uma rajada de pacotes de vídeo em unicast,

correspondente ao novo canal, com a última trama âncora seguida das tramas subsequentes. Deste

modo, a STB poderá dar início à descodificação do novo canal sem ter de esperar por uma nova

âncora, mostrando imediatamente a nova sequência. Esta rajada de pacotes terá de ser enviada a

uma taxa de transmissão superior ao fluxo anterior por duas razões: a trama âncora pode

corresponder a uma imagem que já foi transmitida há alguns instantes no fluxo multicast, e o buffer

tem de ser preenchido para se poder inicializar a visualização sem quebras de imagem. Assim que os

dois fluxos possam ser recebidos em simultâneo, é efectuado um join ao grupo associado, e

terminado o fluxo em rajada.

EPG – Guia Electrónico de Programação

Um EPG é um guia digital de programação, disponível no ecrã do televisor. É uma funcionalidade

única no mundo da televisão digital, equivalente a uma página de TV de uma revista. Permite

14

consultar a programação, agendar a gravação de conteúdos, ou adquirir direitos de visualização para

serviços VoD. É vital para um operador disponibilizar um serviço de EPG capaz de cativar os clientes

à compra de conteúdos multimédia, rentabilizando o investimento [32].

Serviços a Pedido

Os serviços a pedido disponibilizam conteúdos pagos aos utilizadores, através de uma aplicação

interactiva como o Electronic Program Guide - EPG. Os serviços mais comuns são Vídeoclubes ou

lojas virtuais de música. Dependendo dos sistemas, os conteúdos podem ser descarregados em

modo downloading ou streaming.

PVR – Personal Video Recording

Permite aos utilizadores gravar conteúdos em emissão num dado instante. As potencialidades do

PVR são muito vastas, o utilizador pode gravar um programa enquanto visualiza outro, agendar uma

gravação remotamente, ou definir preferências de gravação periódicas por conteúdo. De acordo com

a implementação, os conteúdos podem ser armazenados localmente numa unidade de disco rígido -

Local PVR, ou num servidor remoto – Network PVR (NPVR).

2.3 - Codificação Áudio e Vídeo

A codificação de áudio ou vídeo é um processo através do qual a informação produzida por uma dada

fonte (ex: câmara de vídeo, microfone), é representada digitalmente, tendo em conta um conjunto de

requisitos como a eficiência, qualidade, acesso aleatório, resilência a erros ou complexidade.

Os elementos básicos do processo de codificação são a fonte, o codificador, o canal de transmissão

o descodificador e o receptor, tal como representado na figura 2.4:

Figura 2.4 – Elementos no processo de codificação de áudio e vídeo

O codificador representa a informação produzida na fonte numa sequência de símbolos, segundo um

modelo pré-definido. Os símbolos são então codificados em bits, por um codificador entrópico que

utiliza as ferramentas de codificação que conhece, satisfazendo os requisitos da codificação. O

codificador é algorítmico, pois produz resultados diferentes consoante a natureza da informação. O

resultado é um fluxo de bits comprimidos que são injectados num canal de transmissão.

O descodificador é determinístico, isto é, obedece sempre à regra de descodificação presente no

fluxo de bits comprimidos, de acordo com a norma de codificação utilizada. Dependendo dos

requisitos estabelecidos, o resultado final à saída do descodificador é igual ou semelhante à

informação original [33].

15

2.3.1 - Necessidade de Compressão

Na evolução actual das redes de telecomunicações verifica-se um constante aumento da largura de

banda disponível, com redução do custo por bit transmitido na rede. Atendendo a estes factos, não é

totalmente óbvia a utilidade de se codificar a fonte ou de evoluir constantemente as normas de

codificação, reduzindo constantemente os débitos [34].

No entanto, a compressão do áudio e do vídeo traz importantes benefícios, que tornam as técnicas

de compressão muito populares [33]:

Redução do espaço necessário em disco, permitindo um maior aproveitamento de recursos.

Aumento do tempo de visualização disponível para o mesmo hardware, particularmente

importante em dispositivos portáteis de baixa capacidade.

Redução da largura de banda necessária para transmissão em rede, particularmente

importante para transmissão de serviços multimédia.

Aumento dos débitos, pois para a mesma largura de banda, um sinal comprimido é

transmitido a um débito inferior ao mesmo sinal não comprimido.

Melhoria de qualidade, pois para a mesma largura de banda, permite o envio de um sinal

comprimido de qualidade superior a um não comprimido (eg. SDTV e HDTV).

Por estes motivos, a codificação do vídeo é um processo crítico num sistema de streaming, em

particular para o IPTV, dadas as limitações em termos de largura de banda ao nível da rede de

acesso.

Tomando como exemplo a Televisão Digital de definição padrão, seguindo a recomendação ITU-R

601 a 25 Hz, com 720x576 amostras de luminância e 360x576 amostras de crominância e 8

bits/amostra temos [35]:

[(720x576) + (360x576) x 2] x 8 x 25 = 166 Mbit/s (1)

As redes de acesso actuais não garantem débitos binários desta grandeza para todos os utilizadores,

pelo que sem recurso a codificação não seria possível a oferta de um serviço de IPTV. O débito

médio aceitável de uma stream em definição standard varia entre os 2 e os 4 Mbit/s [13], o que

corresponde a um factor de compressão de 40-80% face ao valor calculado em (1).

As normas de codificação actuais conseguem reduzir a largura de banda necessária aos conteúdos

audiovisuais, mantendo um elevado nível de qualidade visual. Na secção seguinte apresentam-se as

principais normas de codificação utilizadas em IPTV, com destaque para o MPEG4 Parte 10 - AVC,

também conhecido por H.264, e o seu rival VC-1 [34].

2.3.2 - Normas de Codificação e Compressão

Uma sequência de vídeo é constituída por diversas tramas de luminância e crominância. Os

codificadores utilizam técnicas matemáticas como a compressão das tramas e a quantização

16

adaptativa para reduzir a largura de banda necessária à transmissão e armazenamento dos

conteúdos.

A compressão das tramas, baseia-se na exploração da redundância espacial, temporal e estatística,

utilizando codificação entrópica e compensação de movimento.

A quantização é o processo de discretização do sinal analógico à entrada no codificador. O sinal

contínuo é dividido em valores discretos de acordo com uma escala de quantização. Este processo

aproveita o facto de a visão humana possuir uma sensibilidade diferente nas altas e baixas

frequências, explorando a irrelevância.

Geralmente os codificadores utilizam três tipos de tramas de vídeo:

Tramas I, ou tramas Intra representam a imagem original comprimida, explorando a redundância

espacial e estatística.

Tramas P utilizam as mesmas técnicas das tramas I, explorando ainda a redundância temporal

através da compensação de movimento. Utilizam como âncoras as trama I ou tramas P anteriores.

Possuem maior taxa de compressão que as tramas Intra.

Tramas B são as que possuem maior taxa de compressão, pois utilizam como âncora as tramas I e P

imediatamente antes ou depois.

O Group of Pictures (GOP) agupa o conjunto da trama I e das suas dependentes P e B, de acordo

com a figura 2.5:

Figura 2.5 – Estrutura do GOP e dependências entre tramas [36]

As normas de codificação e compressão utilizadas pelos sistemas de IPTV de última geração são o

MPEG4-Parte 10/AVC H.264 e o VC-1.

2.3.2.1 - MPEG4 Parte 10 – AVC/H.264

O H.264 foi desenhado para assegurar uma codificação eficiente de vídeo. O objectivo original da

norma foi assegurar funcionalidades semelhantes ao MPEG4-Visual [34] e outras normas anteriores,

com ganhos de compressão superiores e elevada eficiência, sem afectar a qualidade visual. As

aplicações alvo são o streaming de vídeo, as aplicações broadcast, e o vídeo de alta qualidade. A

17

norma facilita a implementação destes serviços num vasto conjunto de plataformas, e permite a

transmissão robusta sobre redes de pacotes [34].

A norma especifica duas camadas, a NAL (Network Abstraction Layer) e a VCL (Video Coding Layer).

A camada VCL representa eficientemente os conteúdos de vídeo, ou seja, o conteúdo à saída do

codificador. A VCL trabalha sobre macroblocos (MB) e considera imagens no espaço de cores YCbCr.

Os MB podem ser do tipo I (Intra), P (Predictive), B (bi-Predictive). Nesta camada, os MB são

agrupados em slices que são igualmente classificados em vários tipos: I (Intra), P (Predictive), B (Bi-

predictive), SP (Switching P) ou SI (Switching I).

A camada NAL é responsável pela formatação dos dados e fornecer um cabeçalho informativo,

permitindo adaptar a codificação ao meio de transmissão ou de armazenamento. Os conteúdos da

camada VCL são mapeados em unidades NAL que estão orientadas à camada de transporte. Estas

unidades podem ser transmitidas através de uma rede de pacotes, por exemplo através do protocolo

RTP (Real-Time Transport Protocol) [37], ou guardadas num ficheiro.

O H.264 utiliza um filtro adaptativo – de-Blocking Filter - que tem o objectivo de reduzir o efeito de

bloco na imagem, suavizando as fronteiras entre blocos adjacentes. Esta operação acontece no ciclo

de descodificação – In Loop deblocking – cada trama descodificada é utilizada na descodificação da

trama seguinte.

Estão definidos diversos perfis, sendo os principais: Baseline Main e Extended.

O perfil Baseline suporta codificação intra e inter, codificação entrópica com adaptação ao contexto,

utilizando Content Adaptive Variable Length Coding (CAVLC). As principais aplicações deste perfil

são Vídeo-telefonia e Vídeoconferência. O perfil Main fornece suporte a Vídeo entrelaçado,

codificação Intra e Inter e codificação entrópica utilizando codificação aritmética baseada no contexto

– Content Based Adaptive Binary Arithmetic Coding (CABAC). O CABAC aumenta entre 5 a 10% a

eficiência de compressão. As principais aplicações são broadcast e armazenamento de vídeo. O perfil

Extended não suporta Vídeo entrelaçado nem codificação CABAC, mas utiliza slices SP e SI e

melhoramentos na resilência a erros. As principais aplicações deste perfil são a transmissão móvel de

vídeo e streaming. Recentemente foram definidos mais quatro perfis avançados, para dar resposta a

necessidades profissionais de edição de vídeo. Estes novos perfis são designados High Profiles ou

FRExt (Fidelity Range Extensions). As suas principais aplicações são a transmissão e

armazenamento de vídeo de alta qualidade – HDTV, HD-DVD e Blue-Ray, e a edição profissional de

vídeo [38].

2.3.2.2 - AAC – Advanced Audio Coding

O MPEG4 utiliza um formato de compressão de áudio conhecido por AAC (Advanced Audio Coding).

Esta norma de codificação representa um aumento de eficiência face ao MPEG1- Layer2 de cerca de

50% em cada canal para a mesma qualidade áudio. Suporta múltiplos canais e configurações – Dolby

Digital 5.1 e 7.1, Mono e Stereo até 48 canais. A complexidade do codificador é baixa. As suas

18

aplicações são muito vastas, adaptando-se a todos os tipos de dispositivos, tornando-se ideal para

áudio de alta qualidade, inclusive em dispositivos com capacidades limitadas.

A norma foi recentemente ampliada com uma técnica denominada SBR - Spectral Bandwidth

Replication, que reduz a largura de banda necessária à transmissão, particularmente útil em

aplicações Internet, tais como Streaming e Broadcast digital [39].

2.3.2.3 - VC-1

O VC-1 é uma norma de codificação e compressão implementada pela Microsoft, na plataforma

Windows Media Video 9, normalizada pelo SMPTE5 [40].

Representa uma alternativa ao H.264, estando tal como este, ao nível de estado da arte em termos

de compressão de vídeo. Com o VC-1 os débitos binários variam entre valores muito baixos: desde

vídeo com resolução 160x120 a 10 kbps, até valores e resoluções elevados, de 2048x1536 e débitos

na ordem dos 135 Mbps para cinema digital. Desta forma, o VC-1 pode ser utilizado em quase todo o

tipo de aplicações, incluindo o streaming para IPTV.

As funcionalidades básicas do VC-1 [40] são a compensação de movimento baseada em MB e

transformação espacial, à semelhança de outras normas do MPEG. Adicionalmente, o VC-1

implementa um conjunto de optimizações, que aumentam a eficiência do codificador. O perfil

avançado possui independência entre a camada de codificação e a de transporte, o que garante uma

maior flexibilidade de fabricantes e dispositivos.

As principais inovações do VC-1 face aos antecessores são a adaptação do tamanho dos blocos da

transformada, a compensão de movimento a ¼ píxel, o filtro de de-blocking, as transformadas de 16

bits, e a optimização das tramas B, entre outros.

O VC-1 define três perfis de utilização, cada um com diferentes níveis. Cada nível tem associado um

débito binário e uma resolução espacial:

Simple – Níveis com baixo débito, e baixa resolução – QCIF a 15 Hz. Utilizado em redes de

baixo débito e aplicações de baixa complexidade como vídeo móvel.

Main – utilizado em ligações Internet com altos débitos, IPTV, VoD sobre IP.

Advanced – utilizado para HD-DVD, HDTV, Cinema Digital. Este perfil suporta conteúdos

entrelaçados e é independente ao nível do transporte, podendo ser encapsulado sobre

MPEG-2 TS ou PS.

2.3.2.4 - Evolução comparativa das normas de codificação

Actualmente, o MPEG2 é ainda a norma de codificação e compressão de vídeo mais utilizada. As

suas principais aplicações são: compressão de vídeo para DVD e sistemas de broadcast digital –

DVB-C, DVB-S, DVB-T.

5 SMPTE - Society of Motion Picture and Television Engineers

19

O MPEG-4 Parte 2 – Visual, norma antecessora do H.264, possui maior eficiência de compressão e

flexibilidade que o MPEG-2, devido à utilização algoritmos de compressão mais eficientes, e um vasto

conjunto de ferramentas de manipulação digital de vídeo [34]. No MPEG-4 Visual as formas podem

ser codificadas individualmente, permitindo compor e descompor as cenas por múltiplos objectos. Os

dados de vídeo suportados são vastos: Vídeo rectangular, objectos de vídeo de formas arbitrárias 2D

e 3D, texturas fixas, vídeo sintético e natural.

As normas de codificação mais recentes como o H.264 e o VC-1 começam a ganhar uma forte

expressão para codificação de vídeo rectangular, em particular devido à maior eficiência de

compressão, sendo o estado da arte para transmissão e armazenamento. Em termos de eficiência de

compressão, o H.264 é cerca de 40% mais eficiente que o MPEG-4 Visual [34]. Na prática, isto

significa que se obtém um nível de qualidade visual superior com um débito menor, o que possibilita

redução do espaço em disco necessário ao armazenamento, optimização dos tempos associados ao

download de vídeos, e um melhor aproveitamento da largura de banda disponível para transmissão

em rede, tal como ilustrado no gráfico da Figura 2.6:

Figura 2.6 – Evolução das normas de codificação e compressão [38]

Em termos de complexidade, o H.264 é a norma mais complexa, e por isso a mais pesada em termos

computacionais. O seu descodificador é cerca de 2 vezes mais complexo que o do MPEG-4 Visual, e

4 vezes mais que o de MPEG-2. O codificador é cerca de 10 vezes mais complexo que o de MPEG-4

Visual para o perfil Simple [41]. O VC-1, embora seja tecnicamente complexo quando comparado ao

MPEG-2, é bastante eficiente. No processo de descodificação, o VC-1 requer um número de ciclos

que é 25% menor relativamente a outros codificadores, para perfis idênticos [40].

As principais inovações do H.264 face às normas anteriores são:

Filtro de de-blocking

Codificação Entrópica - o CABAC permite ganhos de compressão na ordem dos 5-10%

Níveis de quantização – 52 níveis contra 31 do MPEG-4 e MPEG2.

Começam a surgir no mercado soluções de IPTV e broadcast digital baseadas em H.264:

Serviços MEO IPTV e MEO SAT da PT Comunicações [42].

Serviço TDT - Televisão Digital Terrestre actualmente em implementação em Portugal [43].

Alice Home TV da Telecom Italia [44].

20

A tabela 2.2 resume uma comparação entre as normas de codificação e compressão de vídeo mais

utilizadas actualmente:

Comparação MPEG-2 MPEG-4 Visual H.264 VC-1

Formato Cor 4:2:0, 4:2:2 4:2:0, 4:2:2, 4:4:4 4:2:0, 4:2:2, 4:4:4 4:2:0

Número de Perfis 4 19 3 + FRExt 3

Eficiência de compressão

Média Média Alta Alta Alta

Complexidade Baixa - Média Moderada Alta Moderada

Técnicas de Suporte a

Streaming de Vídeo

- Scalable Coding Switching slices n.d.

Débito médio para SDTV

4 - 8 Mbit/s 1.5 - 3 Mbit/s 1 - 2 Mbit/s 1 - 2 Mbit/s

Tamanho mínimo dos blocos para compensação de

movimento

16x8 ou 8x16 8x8 4x4 4x4

Vectores de estimação de movimento

A partir de ½ píxel

A partir de ¼ píxel A partir de ¼ píxel

A partir de ¼ píxel

Transformada 8x8 DCT 8x8 DCT 4x4 DCT Inteira 4x4 DCT Inteira

Níveis de Quantização

31 31 52 n.d.

Tipos de Tramas I, P, B I, P, B I, P, B, SP, SI I, P, B, BI

Filtro de de-blocking

Não Não Sim Sim

Codificação Entrópica

VLC VLC CAVLC / CABAC VLC Adaptativo

Requer Licença de utilização

Soluções Open-source

Sim. Existem Soluções Open-

source para alguns perfis

Soluções Open-source

Sim

Tabela 2.2 – Comparação das normas de codificação [34] [14]

2.4 - Protocolos de Rede

2.4.1 - SIP – Session Initiation Protocol

O SIP (Session Initiation Protocol) [4] é um protocolo da camada de aplicação, que utiliza o modelo

“pedido resposta”, semelhante ao HTTP, para gerir sessões de comunicação interactiva entre

utilizadores, garantindo serviço de tradução de nomes, localização, negociação dos atributos da

21

sessão e gestão dos participantes. Este protocolo obedece às especificações da Internet Engineering

Task Force (IETF).

O seu desenvolvimento teve origem em meados da década de 1990 com finalidades de adicionar ou

remover participantes dinamicamente numa sessão IP Multicast, e foi inspirado noutros protocolos de

Internet baseados em texto como o SMTP e o HTTP, de forma a ser facilmente extensível consoante

as necessidades da aplicação.

O protocolo define um conjunto de métodos: INVITE, UPDATE, BYE, OPTIONS, REGISTER,

STATUS, ACK [45].

Foi adoptado pelo 3GPP como protocolo de sinalização na arquitectura de controlo IMS [46]. As

aplicações alvo do protocolo nesta arquitectura são a sinalização e controlo de chamadas de Voz

sobre IP (VoIP) [45], com possibilidade de integração de outros serviços, como o IPTV [7] [47].

Um exemplo de sessão com o protocolo SIP pode ser observado na figura 2.7:

Figura 2.7 - Estabelecimento de sessão SIP [47]

2.4.2 - RTSP – Real Time Streaming Protocol

O RTSP (Real Time Streaming Protocol) é um protocolo de sinalização da cama de aplicação,

desenvolvido pelo IETF em 1998, descrito no RFC 2326 [48]. Foi concebido para utilização em

sistemas de streaming com arquitecturas cliente-servidor, permitindo o controlo remoto do servidor

por parte do cliente através de comandos PVR.

Possui diversas propriedades importantes [48]: Mantém estado das sessões através de Session ID

por sessão, é extensível aceitando novos comandos, possui sintaxe de fácil processamento

22

semelhante ao HTTP, reutiliza mecanismos de segurança como a autenticação, e é independente do

protocolo de transporte (TCP ou UDP).

O protocolo define diversos comandos: DESCRIBE, ANNOUNCE, GET_PARAMETER, OPTIONS,

PAUSE, PLAY, RECORD, REDIRECT, SETUP, SET_PARAMETER e TEARDOWN.

É um protocolo muito utilizado em VoD, assegurando o estabelecimento de uma ligação ponto-a-

ponto, entre o cliente e o servidor. As funcionalidades de Play, Stop, Pausa implementadas a nível do

cliente são asseguradas pelos comandos do protocolo.

Sendo um protocolo de sinalização, o RTSP não define métodos de compressão e encapsulamento

das streams multimédia a transmitir. O transporte dos dados multimédia a transmitir é assegurado,

por exemplo, pelo protocolo RTP [49].

Diversos clientes e servidores de streaming conhecidos no mundo da Internet implementam o

protocolo, tais como: Windows Media Player, Quicktime Player, Real Player, VLC Media Player,

Skype, MPlayer, Gstreamer, Xine, e servidores: VLC Streaming Server, Darwin Streaming Server,

Live555 ou Helix DNA Server da Real Networks.

A figura 2.8 ilustra a sequência de mensagens trocadas entre cliente e servidor para um pedido de

uma stream, com retorno de erro:

CS: OPTIONS rtsp://mcmreal.mediacapital.pt/encoder/itv1.rm

RTSP/1.0

CSeq: 1

User-Agent: VLC media player (LIVE555 Streaming Media

v2007.02.20)

SC: RTSP/1.0 200 OK

CSeq: 1

Date: Mon, 08 Dec 2008 22:15:37 GMT

Server: Helix Server Version 9.0.4.958 (win32) (RealServer

compatible)

Public: OPTIONS, DESCRIBE, ANNOUNCE, PLAY, SETUP,

GET_PARAMETER, SET_PARAMETER, TEARDOWN

RealChallenge1: c7706d243469b972d7d87b3838551d67

StatsMask: 3

CS: DESCRIBE rtsp://mcmreal.mediacapital.pt/encoder/itv1.rm

RTSP/1.0

CSeq: 2

Accept: application/sdp

User-Agent: VLC media player (LIVE555 Streaming Media

v2007.02.20)

SC: RTSP/1.0 404 Not Found

CSeq: 2

Date: Mon, 08 Dec 2008 22:15:37 GMT

Figura 2.8 – Exemplo de utilização do RTSP em sessão de VoD

2.4.3 - RTP – Real Time Transport Protocol

O Real-Time Transport Protocol (RTP) foi definido inicialmente no RFC 1889 [50] e revisto em 2003

no RFC 3550 [37]. O RTP assegura o transporte ponto-a-ponto de dados multimédia de tempo-real,

como áudio e vídeo, em redes IP unicast e multicast, podendo ser utilizado para transportar diversos

formatos de áudio e vídeo.

23

Os fragmentos de áudio e vídeo gerados do lado do servidor são encapsulados em pacotes RTP,

sendo de seguida encapsulados sobre UDP. Normalmente, o RTP é transportado sobre UDP, por

questões de desempenho e tolerância do vídeo a perdas. O protocolo define a utilização de números

de sequência, marcas temporais e tipo de dados a transportar em cada pacote, informação utilizada

pelas aplicações multimédia para detecção de perdas e cálculo do jitter. Desta forma, qualquer

aplicação que implemente o protocolo RTP, poderá reutilizar estes mecanismos em detrimento de

outros protocolos proprietários. Esta opção permite uma maior interoperabilidade com outras

aplicações multimédia que utilizem o mesmo protocolo [49].

O RTP não implementa reserva de recursos, e não garante QoS para serviços multimédia de tempo-

real [37]. Devido ao encapsulamento dos pacotes RTP em UDP, não é igualmente garantida a

entrega dos pacotes nos extremos. No entanto, foi definido um protocolo auxiliar, o Real Time Control

Protocol (RTCP) [37], que pode ser utilizado em conjunto com o RTP. Os pacotes RTCP são trocados

periodicamente entre todos os participantes durante a sessão unicast ou multicast, num porto

diferente do RTP. Estes pacotes não transportam qualquer informação multimédia, sendo utilizados

para transmitir relatórios com estatísticas do estado da rede. Estas estatísticas podem incluir perdas

de pacotes, número de pacotes enviados, jitter, etc, sendo muito úteis às aplicações multimédia.

Como exemplo, um servidor ao receber informação sobre elevados valores de perdas, poderá

modificar a sua taxa de transmissão.

O pacote RTP é formado por um cabeçalho e um payload. O cabeçalho tem no mínimo 12 bytes e

contém vários campos, entre os quais: número de sequência, marca temporal (informação de tempo,

usado para a sincronização dos streams), tipo de payload (para identificar o tipo de codificação do

conteúdo), marker bit (para detectar o final de um conjunto de pacotes relacionados), source

identifiers (sincronização e contribuição) e versão.

A Figura 2.9 ilustra o cabeçalho do pacote RTP:

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|V=2|P|X| CC |M| PT | sequence number |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| timestamp |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| synchronization source (SSRC) identifier |

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

| contributing source (CSRC) identifiers |

| .... |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figura 2.9 – Cabeçalho do Pacote RTP [37]

24

2.4.4 - IP Multicast

Um sistema de IPTV, requer a entrega de dados multimédia a um grupo de utilizadores em

simultâneo, por exemplo para a difusão dos canais de Televisão em formato digital para todos os

subscritores.

Tal como ilustrado na Figura 2.10, os mecanismos de encaminhamento em IP são [51]:

Unicast – um para um

Broadcast – um para todos

Multicast – um para um grupo

Anycast – um para alguém do grupo

Figura 2.10 – Mecanismos de Encaminhamento IP [51]

O multicast é um mecanismo de encaminhamento que permite o envio de dados de um emissor para

um grupo de receptores. É particularmente útil quando se pretende transferir a mesma informação

para múltiplos destinatários sem que isso implique um elevado congestionamento na rede. Do ponto

de vista da rede esta abstracção pode ser implementada de diversas formas. Uma das possibilidades

é a do emissor emular uma ligação multicast, criando ligações unicast individuais ponto-a-ponto para

cada receptor [49]. Cada ligação unicast é replicada no emissor quando um novo cliente é servido.

Esta emulação implementa a abstracção multicast através do esquema um emissor para vários

receptores, sem a necessidade de suporte a endereçamento multicast ao nível da camada de rede.

Outra alternativa é a de fornecer suporte a multicast ao nível do IP. Nesta abordagem, apenas uma

cópia de cada datagrama é enviada pelo emissor para a rede, que é recebida por um grupo de

receptores. Os encaminhadores são responsáveis por efectuar cópias dos datagramas e

reencaminhá-los para os clientes a servir. Esta abordagem traduz-se numa utilização mais eficiente

da largura de banda disponível, pois apenas uma cópia atravessa a ligação ponto-a-ponto.

Figura 2.11 – Implementação de Multicast [49]

25

O multicast utilizado ao nível do IP baseia-se na construção de árvores de encaminhamento, que

podem ser partilhadas pelo grupo ou baseadas no emissor. O objectivo do encaminhamento multicast

é encontrar uma árvore de ligações com todos os encaminhadores em que estão ligados membros do

grupo. Os pacotes multicast são encaminhados ao longo dos nós da árvore, sendo entregues a todos

os membros do grupo.

Os principais protocolos de “casting” são: DVMRP (Distance Vector Multicast Routing Protocol) [52],

PIM (Protocol Independent Multicast) [53], MOSPF (Multicast Open Shortest Path First Protocol) [54],

e o IGMP (Internet Group Management Protocol).

Os encaminhadores na rede utilizam o IGMP para conhecer os grupos multicast que lhe estão

directamente ligados. Como os elementos do grupo podem ser alterados dinamicamente, é

necessário um protocolo que permita efectuar a gestão dos elementos do grupo. São ainda utilizados

protocolos de encaminhamento (DVMRP, PIM) para definir os caminhos de distribuição dos pacotes.

O protocolo IGMP é utilizado nos sistemas IPTV como protocolo de gestão de grupos entre o cliente e

o encaminhador multicast. Permite que o cliente – tipicamente a STB – comunique directamente ao

encaminhador que pretende receber informação destinada a um dado grupo (e.g., canal 1 da grelha).

No IPTV o IGMP é utilizado na versão 2 [55] ou versão 3 [56]. Na versão 2, são utilizadas três

mensagens: Membership Query, Membership Report e Leave Group. A primeira é utilizada pelos

encaminhadores para determinar os grupos com utilizadores activos. A segunda é utilizada pelos

membros do grupo para responder às interrogações dos routers, e para efectuar o Join a um dado

grupo. A mensagem de Leave Group é enviada pelos membros para deixar um dado grupo. A versão

2 utiliza uma rede ASM (Any Source Multicast), onde qualquer dispositivo pode enviar mensagens

para a rede.

Na versão 3, as mensagens são reduzidas a duas: Membership Query, Membership Report. A

mensagem de Leave Group deixa de existir, sendo agrupada com a de Membership Report. É

utilizada uma rede SSM (Single Source Multicast), onde só membros específicos podem enviar

mensagens.

O encaminhamento multicast é efectuado entre o Headend e as centrais locais de rede, tornando-se

mais eficiente na largura de banda utilizada para distribuição dos programas televisivos em directo –

Live TV, podendo atingir um elevado número de espectadores. Desta forma, um aumento

considerável de subscritores não implica um aumento directo de capacidade na rede core do

operador.

2.4.5 - SDP – Session Description Protocol

O Session Description Protocol (SDP) [5], especifica um formato para descrever sessões multimédia,

tendo como objectivo o anúncio e o convite de sessões, a descrição dos atributos da sessão, entre

outros. A sua sintaxe é baseada em texto. É utilizado conjuntamente com outros protocolos: SIP,

RTSP, HTTP.

26

O SDP inclui informações sobre as streams (tipo áudio ou vídeo), os formatos utilizados, os

endereços origem e destino (Unicast ou Multicast), os portos (para envio e recepção), os tempos de

início e fim da sessão, o originador, o nível de qualidade, o número de imagens de vídeo por

segundo, entre outros.

Na figura 2.12 exemplifica-se a utilização do protocolo SDP:

Figura 2.12 – Descrição de SDP [5]

2.5 - Garantias de Qualidade de Serviço em IPTV

2.5.1 - Segurança e Garantias de Serviço

O IPTV assume-se como um serviço de distribuição de TV alternativo às ofertas de cabo, satélite, ou

difusão terrestre. Como tal, deverá assegurar níveis de qualidade visual, disponibilidade e fiabilidade

idênticos ou superiores aos oferecidos por estes serviços, para poder estar à altura das expectativas

dos utilizadores.

O operador do serviço IPTV tem a necessidade de controlar e monitorizar toda a cadeia de rede do

IPTV, desde o Headend até à rede doméstica, garantindo níveis adequados de serviço e tempos

mínimos de reposição em caso de falhas.

Adicionalmente, o operador tem de garantir que os conteúdos disponibilizados são consumidos

respeitando os termos e licenças de visualização dos produtores. Para isso é necessário efectuar a

gestão dos subscritores e dos conteúdos, garantindo a autenticação e autorização de visualização,

assim como a gestão dos direitos de autor. A autorização no acesso é efectuada através de sistemas

de acesso condicional (CAS – Conditional Access System). A gestão dos direitos de autor é

conseguida através de um sistema DRM (Digital Rights Management). Este sistema aplica os

princípios e restrições de propriedade intelectual, cifrando os conteúdos transportados na rede e

impedindo a sua cópia não autorizada [12] [57].

Ambos os serviços VoD e LiveTV requerem protecção dos conteúdos e autorização no acesso. As

técnicas mais utilizadas são a cifra e a aplicação de marcas de água aos conteúdos. Para esse efeito

os sistemas de middleware interagem com o DRM e as STB para distribuição das credenciais de

v=0

o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5

s=SDP Seminar

i=A Seminar on the session description protocol

u=http://www.example.com/seminars/sdp.pdf

e=j.doe@example.com (Jane Doe)

c=IN IP4 224.2.17.12/127

t=2873397496 2873404696

a=recvonly

m=audio 49170 RTP/AVP 0

m=video 51372 RTP/AVP 99

a=rtpmap:99 h263-1998/90000

27

acesso e validação dos direitos. Normalmente, a STB interage exclusivamente com o middleware,

requisitando a chave respectiva [57].

São utilizados sistemas AAA (Authentication, Authorization, Accounting) que efectuam o controle do

acesso, validando as credenciais de cada subscritor, e verificando quais os conteúdos que podem ser

consumidos e contabilizando ainda a utilização dos serviços. A facturação é efectuada pelos sistemas

de OSS/BSS (Billing).

2.5.2 - Qualidade de Serviço

A Qualidade de Serviço – QoS é um requisito fundamental nas aplicações multimédia baseadas em

IP. O seu objectivo fundamental é garantir um comportamento previsível e elevado nível de

desempenho da rede IP. Consideram-se duas abordagens na implementação de QoS ponto-a-ponto:

Provisão de QoS centrada na rede, e Provisão de QoS centrada no sistema terminal [58].

Na primeira abordagem, a QoS satisfaz requisitos em diferentes camadas: aplicação, rede,

transporte. O IETF definiu dois modelos para implementação de QoS ponto-a-ponto em redes IP:

IntServ (Serviços integrados) e DiffServ (Serviços Diferenciados).

No IntServ, os extremos sinalizam à rede as suas necessidades de QoS, reservando recursos na

rede. O IntServ está sujeito a políticas de controlo de admissão em cada elemento de rede mantendo

um estado para cada reserva de recursos. São utilizados protocolos de reserva de recursos, como o

RSVP e outros [59]. A reserva de recursos é pouco escalável e de difícil implementação pois todos os

elementos da rede têm de saber aplicar o protocolo.

O DiffServ foi proposto como uma solução escalável com capacidade de diferenciação de tráfego, os

elementos da rede são pré-configurados para servir o tráfego com prioridades distintas. Os pacotes

IP são dividos por classes de tráfego. Cada classe possui requisitos de QoS diferentes, sendo que os

pacotes IP são marcados no cabeçalho no campo DSCP (Differentiated Services Code Points) do

byte ToS (Type of Service).

O IPTV-FG considera os seguintes requisitos na rede de acesso para o serviço de IPTV [60]:

Provisão de QoS por serviço e por subscritor, classificação do tráfego com marcação de cabeçalho,

garantia de um valor mínimo de largura de banda, policiamento de tráfego e esquemas avançados de

escalonamento. Como o IPTV é normalmente acompanhado de outros serviços, tais como dados e

voz, é necessário atribuir prioridades aos serviços. Na rede de acesso são normalmente utilizadas

VLAN’s por serviço e/ou por subscritor. Na rede core o IP/MPLS garante encaminhamento eficiente

dos pacotes do serviço de vídeo.

Na segunda abordagem, os sistemas terminais implementam técnicas que maximizam a qualidade do

vídeo ao nível da aplicação, sem ser necessário suporte de QoS a nível da rede [58]. As aplicações

analisam as variações do estado da rede num dado instante, podendo reagir e adaptar-se às

condições. São utilizados métodos de adaptação dos conteúdos e da rede. Os métodos de adaptação

ditam os recursos que a aplicação deve consumir, tais como largura de banda, energia, resolução,

nível de qualidade, etc. Para isso são avaliados diversos parâmetros da rede, como o Round-Trip-

28

Time (RTT), o jitter, as perdas de pacotes, e a largura de banda disponível. A adaptação é feita de

forma a minimizar as perdas e evitar variações nos atrasos, com o objectivo de manter intacta a

qualidade visual perceptível ao utilizador. Esta adaptação consiste na variação do débito das streams

em função dos parâmetros avaliados, em particular da largura de banda disponível. A variação pode

ser efectuada em tempo de visualização, através de processos de negociação dinâmica da qualidade

das streams, utilizando o protocolo SIP, tal como descrito em [9].

2.5.3 - Qualidade de Experiência

Para se assegurar que o IPTV está ao nível das expectativas dos utilizadores, não basta considerar

os aspectos relacionados com a QoS, pois o utilizador final não está explicitamente preocupado com

as prioridades atribuídas ao tráfego ou com a perda de pacotes. Os utilizadores pretendem boa

qualidade de imagem e som, serviço ininterrupto, mudanças instantâneas de canal, etc [61].

A QoE é definida como a aceitabilidade global de um serviço ou aplicação, percebida de forma

subjectiva pelos utilizadores. A recomendação do ITU Rec.G.1081 define os requisitos da QoE na

perspectiva do utilizador, de forma agnóstica à rede de transporte e aos protocolos utilizados [62].

O grupo de estudo 12 do ITU (ITU-T SG12) tem vindo a investigar requisitos e métodos de avaliação

da QoE para serviços multimédia, incluindo o IPTV. No ITU, o IPTV-FG está a desenvolver

documentos para normalização nesta área [61].

A QoE é um termo genericamente complexo, não se limitando a questões relacionadas com a

qualidade subjectiva da imagem, pois refere-se igualmente a aspectos de usabilidade, segurança,

receptividade e fidelidade da informação transmitida. Estes critérios são medidos na camada de

serviços, que está exposta directamente à camada de utilizador, avaliando se um dado serviço está

dentro das expectativas dos utilizadores.

Existe uma relação não linear entre a medição subjectiva da QoE, e o impacto perceptivo das várias

formas de degradação do serviço e parâmetros objectivos da QoS, por exemplo com perda de

pacotes, variações bruscas de atraso, etc. Esta relação está ilustrada na Figura 2.13:

Figura 2.13 – Relação entre QoE e QoS (adaptado) [13]

Do lado do cliente, as STB incorporam buffers que são utilizados para combater o efeito do jitter,

absorvendo o tempo de variação de chegada dos dados. O tamanho do buffer varia entre 100 e 500

29

ms, ou seja, o valor típico associado ao processamento de comandos PVR. Dimensões acima deste

valor têm impacto negativo no tempo associado à troca de canal e processamento de pedidos. A

perda de pacotes na rede pode ser combatida através de técnicas da camada de aplicação como o

Forward Error Correction (FEC) e o Automatic Repeat Request (ARQ), Realiable UDP ao nível do

transporte, ou técnicas de Resiliência de erros através de informação redundante introduzida pelo

codificador. Indirectamente todas estas técnicas contribuem para aumentar a QoE [30].

2.5.3.1 - Técnicas de Avaliação de QoE

A QoE pode ser avaliada de diversas formas. No caso particular do vídeo, a qualidade de imagem

pode ser avaliada de três formas distintas [13]:

Subjectivamente – utilizando um método de avaliação experimental, através do qual um

conjunto de participantes atribui uma classificação utilizando uma escala de valores.

Objectivamente – na camada de serviço, analisando parâmetros do sinal de vídeo (e.g.,

PSNR), através de equipamento de medida especializado.

Indirectamente – Efectuando medições de diversos parâmetros da rede (atraso, jitter, perdas

de pacotes), com o objectivo de estimar o impacto destes parâmetros na qualidade visual,

utilizando a relação existente entre QoE e QoS

A figura 2.14 ilustra o impacto visual da perda de tramas de vídeo:

Figura 2.14 – Impacto visual da perda de Tramas B e I

Existem diversos métodos de avaliação subjectiva, sendo a escolha feita de acordo com o objectivo e

as condições da avaliação. A ITU-R definiu alguns métodos, como por exemplo Double-Stimulus

Continuous-Quality-Scale (DSCQS), Double-Stimulus-Impairment-Scale (DSIS), entre outros [63].

Estes métodos utilizam a escala de classificação Mean Opinion Source (MOS).

2.6 - Internet TV

A arquitectura genérica da solução de Internet TV é apresentada na figura 2.15:

30

Figura 2.15 - Arquitectura Genérica Internet TV [21]

A Internet TV possui algumas características próprias. O conteúdo é entregue através da Internet, ou

seja, a rede não é gerida por quem presta o serviço, logo não existem garantias de QoS por parte do

operador. As soluções podem basear-se em streaming, downloading, ou peer-to-peer video sharing.

Os conteúdos são normalmente disponibilizados em diversos formatos e níveis de qualidade

associados à taxa de compressão utilizada, sendo escolhidos pelo cliente ao estabelecer a sessão de

acordo com as capacidades do seu dispositivo e da sua ligação à rede. A variedade de conteúdos é

virtualmente infinita. O cliente é tipicamente um computador pessoal ou PDA (Personal Digital

Assistant) com ligação à Internet e software próprio [12].

2.6.1 - Comparação com IPTV

A InternetTV possui diversas semelhanças com o IPTV. Podem ser utilizadas as mesmas normas de

codificação de áudio e vídeo e os mesmos protocolos de rede, com execepção do IP Multicasting,

normalmente bloqueado pelo prestador do serviço de Internet. O modelo de negócio é distinto nas

duas abordagens, o que dita um conjunto de diferenças que estão intimamente relacionadas com o

custo de instalação, operação e manutenção do serviço [64].

As diferenças principais entre o IPTV e Internet TV são resumidas na tabela 2.3:

IPTV Internet TV

Garantias de QoS Sim Não

Natureza do conteúdo Streaming contínuo de conteúdos

Streaming discreto de conteúdos

Selecção do conteúdo Canais TV do pacote adquirido Milhões de streams

Formato do conteúdo Formato único Diversos Formatos

Entrega do conteúdo Streaming Streaming, Downloading ou P2P

Rede de Transporte Privada Pública

Dispositivo do Cliente Set-Top-Box PC / PDA / Telemóvel 3G

Acesso ao serviço Por subscrição Livre

Mobilidade Reduzida Elevada

Segurança Conteúdo cifrado Conteúdo aberto

Tabela 2.3 – Comparação do IPTV com Internet TV [12] [64]

31

2.7 - Plataformas IPTV

As principais plataformas comerciais de IPTV à data, implementadas em operadores de

telecomunicações a nível europeu são: Siemens Surpass Home Entertainment [65] e Alcatel /

Microsoft TV - IPTV Edition [66].

2.7.1 - Siemens Surpass Home Entertainment

A figura 2.16 representa o modelo funcional da plataforma de IPTV da Siemens, designada Surpass

Home Entertainment. Esta plataforma representa uma solução completa de IPTV, que obedece à

arquitectura genérica apresentada na secção 2.2.2.

A plataforma apresenta três áreas principais: Headend, Service Control Backend Center, e a Rede

Doméstica. As principais entidades envolvidas na solução são o Tandberg TV Headend, Myrio

Middleware, Verimatrix Content Protection, C-COR Content Server, Siemens Content Management

System e as STB.

Figura 2.16 – Arquitectura IPTV da solução Siemens [65]

O serviço de VoD é distribuído aos clientes através de servidores de alta capacidade, C-COR

MediaHUBs, organizados em clusters geográficos. O middleware é baseado numa solução da Myrio

com o intuito de efectuar uma gestão global dos serviços, sendo responsável por proceder ao

controlo de acesso do utilizador aos conteúdos que tem direito, à gestão das aplicações e à

disponibilização do EPG. Este módulo possui interfaces com as plataformas OSS/BSS,

nomeadamente o Billing. A protecção dos conteúdos transmitidos na rede é efectuada pela solução

Verimatrix Content Authority System. Na rede doméstica é utilizada uma solução Universal Plug and

Play (UPnP) para serviço o Triple Play, através de um gateway residencial.

32

2.7.2 - Alcatel / Microsoft TV IPTV Edition

Esta plataforma resulta duma parceria ente a Alcatel e a Microsoft para implementação de soluções

completas Triple Play / IPTV, e é designada Microsoft TV - IPTV Edition [66, 67].

As funcionalidades da plataforma incluem a aquisição e codificação das fontes, a protecção de

conteúdos - Windows Media DRM [67], o transporte ao nível da rede core, a entrega ao nível da rede

de acesso, e a gestão de subscritores. A plataforma de Midleware é responsável pela gestão de

comunicações entre todos os servidores, e juntamente com a STB o carregamento de

funcionalidades tais como o EPG. São disponibilizadas API’s para inserção de aplicações fornecidas

por terceiros através do protocolo RDP (Remote Desktop Protocol) [68].

A Figura 2.17 ilustra a arquitectura da plataforma Microsoft TV IPTV Edition:

Figura 2.17 – Arquitectura da plataforma Microsoft TV IPTV Edition [66].

Os VoD servers são responsáveis pela distribuição em unicast dos conteúdos a pedido, estando

divididos em clusters regionais. Os Terminal Servers são responsáveis por disponibilizar o Portal EPG

aos clientes, que é carregado na STB através do protocolo RDP. Os D-Server garantem a entrega

fiável dos conteúdos e implementam funcionalidades de mudança instantânea de canal (Instant

Channel Change – ICC). Do lado do cliente, a plataforma disponibiliza diversas aplicações, como o

Amigo TV [69], My Own TV e Communications TV [66], que enriquecem a experiência de utilização.

33

2.8 - Clientes IPTV

O cliente IPTV está tipicamente situado na rede doméstica, sendo responsável pela entrega do

serviço ao utilizador final, e é constituído por um sistema terminal que realiza a interface com a rede,

e com o utilizador.

2.8.1 - Sistemas Terminais

O sistema terminal suporta o acesso aos serviços do IPTV. Possui funções de gestão do serviço,

gestão de aplicações e dos protocolos de rede utilizados. Pode assumir várias formas consoante a

implementação: STB, Televisor, PC, PDA, Cliente Streaming por software, etc.

É considerado um requisito importante que o sistema terminal suporte descodificação MPEG2 ou

H.264 e AAC, AC3 ou MP3 (pelo menos uma das normas para vídeo e áudio respectivamente).

Como requisito opcional, o terminal pode possuir um módulo de monitorização de qualidade,

utilizando um dos três métodos [70]:

Reduced-Reference (RR) – Utiliza informação parcial da imagem de referência.

No-Reference – Não utiliza informação da imagem de referência.

Monitorização de erros de transmissão – Baseado em informação relativa a perda de

pacotes, tramas descartadas ou atrasadas, jitter, etc.

2.8.2 - Arquitectura Funcional

A arquitectura funcional de um cliente IPTV é representada pela figura 2.18:

Figura 2.18 – Arquitectura Funcional de Cliente IPTV [70]

34

Os módulos funcionais do cliente são [70]:

Interface de rede – Ligação à rede do operador. Recepção e envio de sinais, processamento

das camadas 2-4 do modelo OSI

CAS/DRM – Trata os mecanismos de autenticação, e gestão dos direitos dos conteúdos.

DEMUX – Responsável pela desmultiplexagem das streams de áudio e vídeo contidas no

fluxo RTP.

Descodificadores – Descodificam os pacotes de áudio e vídeo.

Aplicações – Gestão de aplicações a correr no cliente, tais como o EPG, Portais de acesso

aos serviços, jogos, etc.

Display – Módulo de visualização

Dispositivo de Armazenamento (opcional) – Disco Rígido disponível no serviço PVR, para

gravação de conteúdos.

2.9 - Resumo

Neste capítulo foram apresentados os conceitos básicos de transmissão de vídeo sobre IP,

nomeadamente as diferentes formas de entrega de conteúdos a um cliente – streaming, downloading

e progressive-downloading, em regime de VoD e LiveTV. Introduziu-se ainda o serviço de IPTV, um

serviço streaming de televisão, capaz de oferecer uma experiência enriquecida ao utilizador,

descrevendo-se a sua arquitectura genérica e protocolos de rede utilizados, assim como as diferentes

redes de acesso em que pode ser disponibilizado: DSL; FTTH; Redes 3G; ou sobre a Internet numa

variante designada InternetTV.

Foram ainda apresentadas as normas de codificação e compressão que são o estado da arte actual

para vídeo e áudio, fundamentais neste tipo de serviço devido às restrições de largura de banda no

acesso.

A QoE é um aspecto fundamental a ter em conta no serviço IPTV, na medida em que pode

determinar o seu sucesso face a tecnologias concorrentes. Esta está dependente da QoS garantida

pela rede, entre outros factores.

35

Capítulo 3 - Integração do IPTV na Arquitectura IMS

Actualmente, as plataformas de IPTV disponibilizadas possuem uma arquitectura de controlo própria

que dificulta a integração com outros serviços (e.g., VoIP), aplicações, fornecedores de conteúdo, etc.

Na ITU-T, o IPTV-FG tem estado a trabalhar na normalização do IPTV, nomeadamente na definição

de uma arquitectura baseada em redes de próxima geração – NGN (Next Generation Networks) -

com integração da arquitectura IMS como referência para a arquitectura de controlo [22].

O IPTV pode ser integrado na arquitectura IMS, tal como definida pelo TISPAN, com vista à redução

da complexidade da rede e aumento da flexibilidade na integração de outros serviços, e permitindo

ainda a independência ao nível do transporte e do acesso à rede.

Neste capítulo são apresentados cenários e requisitos na integração do IPTV em IMS. São

abordadas as arquitecturas NGN da ITU-T, sendo analisados os modelos de IPTV baseados em IMS

propostos até à data.

3.1 - Introdução

Como ilustrado na figura 3.1, as redes de próxima geração permitem uma integração horizontal dos

serviços com independência no acesso. A arquitectura de rede NGN separa as funções de aplicação,

controlo e transporte em camadas horizontais, permitindo um acesso convergente multi-dispositivo

aos diversos serviços.

Figura 3.1 – Evolução das redes actuais

Tal como exposto no capítulo anterior, os sistemas de IPTV actuais possuem uma arquitectura

própria, que se integra na rede do operador utilizando a solução específica do fabricante. Esta opção

dificulta a integração horizontal dos serviços: cada serviço é suportado por uma rede e arquitectura

de controlo distinta.

Neste sentido, têm sido desenvolvidos cenários de integração do serviço de IPTV no modelo das

redes de próxima geração, em particular na arquitectura IMS do ETSI TISPAN. Nos trabalhos da

36

TIPSAN NGN Release 2, finalizada no início de 2008, foram definidas duas abordagens para a

inclusão do IPTV nas redes de próxima geração [3]:

Um subsistema IPTV dedicado focado na integração das soluções existentes no mercado

num ambiente NGN.

Uma solução IPTV completamente baseada em IMS, integrando os serviços oferecidos pelos

operadores de telecomunicações (voz, dados, presença, vídeo, etc).

3.2 - Requisitos de Integração

A integração do IPTV na arquitectura IMS, implica alterações da arquitectura a vários níveis [7]:

Controlo do IPTV em IMS - utilização do protocolo SIP para mensagens de controlo através

de esquemas de conversão e/ou proxy.

Gestão comum de subscritores – criação de repositórios centrais da informação relativa aos

utilizadores dos diferentes serviços.

Gestão comum dos recursos da rede – provisão de recursos, políticas de QoS e policiamento

Sinalização comum – utilização do protocolo SIP para estabelecimento de sessão em todos

os serviços

A gestão de comum de utilizadores pressupõe um acesso único a todos os serviços, através de uma

base de dados centralizada para todos os serviços. Desta forma, cada utilizador pode ligar-se uma

única vez à rede e utilizar todos os serviços a que tem acesso: IPTV, VoIP, VoD, etc.

Na arquitectura IMS, o RACF – Resource and Admission Control Function localiza-se na rede de

acesso e aplica políticas de tráfego diferenciadas, gerindo os recursos utilizados por cada serviço de

acordo com os seus requisitos. O RACF torna-se responsável por diferenciar o IPTV dos restantes

serviços, garantindo os níveis de serviço adequados.

O SIP foi escolhido como protocolo de sinalização no IMS devido à sua simplicidade e

extensibilidade.

O IPTV tradicional utiliza o IGMP para gestão de grupos multicast e o RTSP para sinalização VoD,

sendo necessários mecanismos de adaptação no sentido da utilização da sinalização SIP. Esta

adaptação pode ser efectuada a vários níveis: rede doméstica, rede de acesso, servidores de

aplicações [7].

Como o IMS pressupõe a utilização de um método de sinalização e controlo comum para todos os

serviços, implica que o SIP tenha que ser utilizado para o controlo multimédia. Esta é uma das

principais dificuldades na integração do IPTV na arquitectura IMS, pois o SIP não implementa

métodos para manipulação do fluxo de vídeo [71].

Outros requisitos incluem o provisionamento comum de serviços e conteúdos, a mobilidade

transparente entre dispositivos e tecnologias de acesso (que não impliquem a interrupção do serviço),

contabilização e taxação dos serviços numa plataforma única, entre outros [71].

37

3.3 - Arquitectura IPTV de próxima geração baseada em IMS

A arquitectura IPTV-NGN baseada em IMS permite a reutilização das capacidades de controlo e

gestão da sessão, gestão dos serviços e mecanismos de facturação e interacção com outros

serviços, como por exemplo o VoIP.

O modelo para a arquitectura IPTV baseada no IMS está ilustrado na figura 3.2:

IMS

Core

Streaming for

Broadcast & VoD

NGN

Access

Transport

NGN

Core

Transport

NGN

IP Control

Sub-Systems

NGN Service Orientated Sub-systems

Application Layer

IPTV Subscriber

Management

RACF Resource &

Admission Function

Streaming

Client

Access

IPTV

Application

NACF Network

Attachment Function

Edge Functions

Customer

Transport

User Profile

Network Gateway

Transaction Protocol

Streaming Protocol

Authentication Protocol

Session

Protocol

IPTV Terminal

Multicast Protocol

IPTV

Client

IMS

Application

IPTV / Session

Control

Session

Control

Figura 3.2 – Arquitectura IPTV baseada em IMS em redes de próxima geração [22].

Esta arquitectura está dividida em três camadas: aplicação, controlo e transporte. A camada de

aplicação é responsável pela provisão e gestão do serviço. Inclui funcionalidades como o controlo e

manutenção do estado dos utilizadores na rede, serviço de facturação, gestão de faltas, gestão de

configurações, gestão de segurança e de desempenho, e suporte das aplicações IPTV / IMS.

A camada de controlo implementa o núcleo IMS, que é responsável pelas funcionalidades de controlo

da sessão - registo, início, modificação, terminação, e encaminhamento das mensagens de

sinalização. Esta camada encontra-se entre a camada de serviços e de transporte. É também

responsável por gerar informação da utilização da rede para funções de contabilização (e posterior

facturação), e controlar a utilização de recursos na camada de transporte. Estas funções são

implementadas nos CSCF (Call Session Control Function), RACF (Resource and Admission Control

Function), e NACF (Network Attachment and Control Functions).

A camada de transporte é responsável pelos mecanismos de acesso à rede, e a gestão e agregação

do tráfego da rede Core. O acesso é conseguido através de gateways de periferia da rede, que

controlam os fluxos de tráfego entre o Core e o acesso. Esta camada implementa mecanismos de

reserva e controlo de QoS - no Core são utilizadas funções que garantem a classificação dos fluxos

de tráfego, gestão das filas e filtragem de pacotes.

38

O sistema terminal IPTV interage com os servidores CSCF garantindo o registo, autenticação e

gestão da sessão na utilização do serviço IPTV. Os servidores S-CSCF (Serving-CSCF) mantêm o

estado da sessão, controlam todos os serviços do utilizador, e autenticam os utilizadores. Os

servidores P-CSCF (Proxy-CSCF) são o primeiro ponto de contacto do utilizador com o Core IMS em

termos da sinalização SIP, sendo responsável por redireccionar as mensagens SIP para os

elementos da rede correspondentes, garantindo o estabelecimento da sessão no Core IMS. O I-

CSCF (Interrogating-CSCF) é uma gateway que garante a interligação entre diferentes redes, de

acordo com o serviço, redireccionado a sinalização correspondente.

O Cliente comunica com o Core IMS através do protocolo de sinalização da sessão SIP, sendo

identificado pelo seu perfil criado no repositório central.

3.3.1 - Controlo de Serviço e de Sessão em IPTV-IMS

A integração do IPTV na NGN da ITU é um processo complexo que tem levantado diversas questões,

entre as quais o controlo dos serviços oferecidos, tais como o VoD e o LiveTV.

O controlo é fundamental para a disponibilização das funcionalidades interactivas do IPTV, tais como

pausa, gravação, retroceder a emissão, troca instantânea de canal, etc. Estas funcionalidades são

implementadas tendo em consideração as características dos servidores multimédia e dos terminais,

nomeadamente os esquemas de sinalização utilizados.

Para o controlo do IPTV em IMS, poderá ser utilizado o SIP através da adopção de comandos

idênticos aos do RTSP. Esta abordagem tem vindo a ser estudada, pois traduz uma evolução lógica

ao tornar o SIP o protocolo comum de controlo de serviços no IMS. A extensão do SIP é

relativamente simples, mas tem sido rejeitada para controlo do IPTV, devido à sobrecarga de novos

métodos que seria necessário implementar e às alterações que seriam necessárias nos elementos da

rede que interpretam as mensagens. Uma possível solução seria reutilizar os métodos já existentes,

estendendo apenas os seus atributos o que apenas implicaria alterações na interpretação das

mensagens nos extremos. Um exemplo deste tipo de utilização é a negociação de QoS em IPTV,

descrita em [9].

Têm sido estudadas e propostas outras abordagens: o MMUSIC propôs um modelo híbrido SIP/RTSP

num draft da Internet onde o RTSP é integrado no corpo do SDP para o controlo da sessão de vídeo,

sendo que o SDP é encapsulado na mensagem SIP, que por sua vez controla e inicia a sessão, como

descrito em [72]; ou a utilização de SIP no estabelecimento e modificação da sessão IMS e do RTSP

para controlo do streaming de vídeo [6].

3.3.2 - Sinalização para serviços IPTV Unicast baseada em IMS

A utilização conjunta do SIP e RTSP para sinalização de serviços IPTV unicast em IMS, pressupõe a

utilização do SIP como protocolo de iniciação e controlo da sessão e do RTSP para controlo do fluxo

de vídeo. A principal vantagem desta abordagem é a reutilização das capacidades de cada protocolo,

evitando-se a extensão e replicação de métodos existentes em cada um.

39

A arquitectura para serviços IPTV unicast baseada em IMS proposta pelo IPTV-FG está representada

na figura 3.3:

Figura 3.3 – VoD na Arquitectura IMS [22]

Com base nesta arquitectura, uma sessão completa de VoD em IMS seria composta pelos seguintes

procedimentos de sinalização [6]:

1. A STB contacta o servidor Web de selecção e descoberta dos serviços - SDS via HTTP, para

obter os endereços URL-RTSP e URL-SIP do servidor de VoD

2. Com base na resposta, a STB envia uma mensagem SIP de INVITE ao IMS

3. É reservada largura de banda entre a STB e o servidor de VoD

4. O Core IMS encaminha o pedido de INVITE para o servidor de VoD

5. O servidor de VOD responde com SIP 200 OK, a confirmar o pedido de INVITE

6. A largura de banda necessária entre a STB e o servidor de VoD é atribuída pelo RACF.

7. O IMS encaminha o 200 OK para a STB, e a sessão é iniciada.

8. A STB envia a mensagem RTSP DESCRIBE ao servidor de VoD.

9. O servidor de VoD envia uma mensagem de resposta que inclui os parâmetros solicitados.

10. A STB envia a mensagem RTSP PLAY para o servidor de VOD começar a enviar o fluxo de

vídeo

11. Após resposta ao RTSP PLAY, o servidor de VOD começa a enviar o fluxo de vídeo RTP

12. A STB pode enviar comandos de controlo, para controlar o fluxo de vídeo, e.g., RTSP

PAUSE, RTSP RECORD

13. A STB envia uma mensagem RTSP TEARDOWN ao servidor, que pára de enviar o fluxo de

vídeo RTP.

14. A STB envia uma mensagem SIP BYE ao IMS: esta mensagem é reencaminhada ao servidor

de VoD, que responde com um 200 OK.

15. A mensagem de OK é reencaminhada à STB e os recursos são libertados.

3.4 - Resumo

Neste capítulo foram abordadas as arquitecturas de próxima geração – NGN do ITU-T com

integração do serviço IPTV unicast, baseado em IMS.

ABG-FECoD

serverUE ABG-FE

RACF

SIPIMS

SIP

RTP stream

HTTP

RTSP

SD&S

server

40

A integração de serviços IPTV na arquitectura IMS possui determinados requisitos: gestão comum de

subscritores, gestão comum dos elementos da rede para reserva de recursos, sinalização e controlo

comuns. Destacam-se a gestão da sessão e o controlo do IPTV, que num cenário de integração total,

deverão ser comuns a todos os serviços oferecidos (e.g., VoIP, IPTV). Tem vindo a ser estudada a

possibilidade da adopção do SIP como protocolo único de sinalização e controlo, ou a utilização mista

de SIP e RTSP, reaproveitando as características dos dois protocolos.

A utilização exclusiva de SIP pode implicar a extensão do protocolo para suportar funções de controlo

do fluxo de vídeo e alterações nos elementos da rede que interpretam as mensagens, pelo que tem

sido frequentemente rejeitada. Por outro lado, o RTSP suporta na sua forma nativa o controlo do

vídeo, mas deverá ser utilizado em conjunto com o SIP para gestão da sessão IMS.

A última opção é actualmente a mais consensual, mas levanta problemas de replicação de

funcionalidades idênticas, sincronização entre os dois protocolos e elevado número de mensagens de

sinalização.

41

Capítulo 4 - Arquitectura da Solução

Neste capítulo é apresentada a arquitectura da solução desenvolvida para um sistema de IPTV com

base em SIP para ambiente IMS e redes heterogéneas. O capítulo inicia-se com um breve

enquadramento do trabalho no âmbito do projecto My eDirector 2012 [10], focando os seus objectivos

e características. De seguida, é descrito o sistema cliente IPTV desenvolvido, nomeadamente as

funcionalidades e os vários módulos da arquitectura. Por fim, descreve-se o modelo de sinalização

proposto para o serviço unicast de VoD, totalmente baseado em SIP para integração na arquitectura

IMS.

4.1 - O Projecto My eDirector 2012

O presente trabalho enquadrou-se no projecto de investigação europeu My eDirector 2012. O

objectivo deste projecto europeu consiste no desenvolvimento de um serviço de streaming de vídeo

interactivo e personalizado, onde os utilizadores são realizadores da sua própria emissão. Para tal,

deverão ser capazes de seleccionar múltiplas câmaras e ângulos de visualização de eventos de larga

escala, baseados nas suas preferências. O serviço deverá poder ser oferecido em ambiente

heterogéneo, através de múltiplos dispositivos e redes de acesso, em directo ou em VoD. O serviço a

disponibilizar pelo projecto será implementada para as Olimpíadas de 2012 em Londres.

Neste projecto consegue-se atingir um determinado nível de personalização da emissão tendo em

conta a escalabilidade, o custo de desenvolvimento, e a integração com as infra-estruturas de rede já

existentes para dar suporte ao streaming de vídeo. No cenário mais simples, o cliente é responsável

pelo processamento das suas preferências, isto é, pela escolha das câmaras e eventos a partir do

seu terminal – Terminal Centric Scenario. O cliente tem total controlo na escolha, sendo esta feita a

pedido. Este cenário apresenta como inconveniente a possibilidade de existir algum atraso na

mudança de canal ou câmara, correspondente ao tempo de troca da stream [73].

4.2 - Requisitos da Solução

O protótipo de cliente IPTV desenvolvido neste trabalho teve em conta os seguintes requisitos.

1. Utilização de Redes de Acesso Heterogéneas

O Cliente implementado pode utilizar diferentes tecnologias de acesso via rede Pública, e.g.,

Redes de Banda Larga Móvel 3G, DSL, ou em rede privada, e.g., Ethernet, WLAN.

2. Monitorização de QoS

O Cliente deverá fazer uma monitorização permanente ao estado da rede, por exemplo

através da recolha e análise periódica de estatísticas. Os dados analisados poderão incluir:

largura de banda disponível, taxa de perdas de pacotes, latência, jitter. Em função disso,

poderá implementar um módulo de gestão da QoS, com adaptação dinâmica às condições

verificadas.

42

3. Integração no modelo de Redes de Próxima Geração da ITU-T

O cliente deverá ter em conta as características das Redes de Próxima Geração

apresentadas pela ITU e seguir os requisitos de integração do IPTV na arquitectura IMS

apresentados na secção 3.2, com realce para o esquema de sinalização [7].

4.3 - Descrição do Sistema Desenvolvido

Este trabalho corresponde ao desenvolvimento da componente cliente IPTV personalizado para

serviços de VoD e LiveTV no âmbito do projecto de investigação europeu My eDirector.

O cliente IPTV foi desenhado em paralelo com o desenvolvimento da componente servidor IPTV, no

âmbito do mesmo projecto. Desta forma, o modelo de sinalização da solução cliente-servidor foi

desenhado e implementado de forma colaborativa. O objectivo deste sistema IPTV é distribuir

conteúdos em tempo-real ou pré-gravados aos clientes, em ambiente heterogéneo. As plataformas de

utilização da aplicação cliente são PC Desktop / Laptop, ou dispositivos móveis (e.g., PDA).

O protótipo segue a visão da ITU, na integração do serviço IPTV em arquitecturas NGN baseadas em

IMS. O terminal executa uma aplicação cliente IPTV composto por um cliente de streaming com

funções de controlo da sessão e do serviço de vídeo. Numa primeira fase, o cliente obtém os

endereços dos servidores VoD e das streams que pode consumir. Cada stream pode estar associada

a: um canal a transmitir em directo, um filme pré-gravado, uma câmara específica do evento

desportivo, etc. O cliente inicia a sessão no servidor IPTV escolhendo a stream pretendida. O servidor

responde, e, se o conteúdo estiver disponível, começa a emitir para o cliente.

Durante a visualização, os clientes podem personalizar a sua emissão. Podem ainda ser utilizadas

funções PVR tais como a Pausa, Play, re-Play e Stop. As opções disponíveis são: alteração da

câmara visualizada, alteração do nível de qualidade visual associada à codificação, e alteração de

canal televisivo. Relativamente aos cenários de personalização previstos no projecto My eDirector, foi

implementado o cenário Terminal Centric [73].

O cliente incorpora ao nível da aplicação um módulo de monitorização de QoS da rede. Com este

módulo são recolhidas periodicamente estatísticas acerca das perdas de pacotes e latência. Estes

dados permitem à aplicação monitorizar possíveis alterações nas condições da rede, e reagir com o

objectivo de minimizar o impacto negativo na experiência de visualização, aumentando a QoE.

Quando a aplicação detecta um aumento significativo na taxa de perda de pacotes ou valores

elevados de jitter, sinaliza essa condição ao servidor pedindo uma redução no débito da stream.

Como consequência, verifica-se uma redução do nível de qualidade visual do vídeo, sem interrupção

da visualização. Por essa razão, diz-se que as transições entre níveis de qualidade são suaves. O

mesmo mecanismo aplica-se para o processo inverso. Esta abordagem apresenta a vantagem de

não necessitar de provisão de QoS ao nível da rede.

43

4.3.1 - Arquitectura Geral

A arquitectura geral do sistema IPTV é apresentada na figura 4.1:

Figura 4.1 – Arquitectura da Rede

Nesta arquitectura podem ser utilizados diferentes tipos de terminais de acesso para a função de

cliente. Em rede de acesso móvel, o cliente utiliza uma rede de banda larga móvel 3G CDMA EV-DO.

A transmissão é efectuada via unicast entre o servidor e o cliente para serviços LiveTV e VoD - o

multicast ao nível do IP não está disponível pelo prestador do serviço à data de desenvolvimento

deste trabalho. Pode ainda ser utilizada uma rede Ethernet privada, e neste caso a transmissão é

efectuada em unicast ou multicast.

O Encoder Server entrega diferentes versões do mesmo conteúdo ao SIP IPTV Server, e a cada

versão corresponde um nível de qualidade. Esta entrega pode ser efectuada em unicast (caso exista

um único SIP IPTV Server) ou em multicast para distribuição por vários servidores. O servidor

selecciona e envia a stream correspondente ao nível de qualidade pedido pelo cliente.

Com esta solução permite-se que o cliente troque dinamicamente o nível de qualidade que está a

receber, bastando enviar um pedido ao servidor durante a sessão, com a indicação do nível

pretendido. Ao receber a mensagem, o servidor selecciona a nova versão e efectua a troca,

actualizando o fluxo de pacotes RTP à saída. Do lado do cliente, isto traduz-se numa transição suave

para a nova versão sem qualquer interrupção na emissão.

44

4.3.2 - Módulos do Cliente IPTV

O cliente IPTV possui uma arquitectura modular, correspondendo cada módulo a uma função

específica. O diagrama apresentado na figura 4.2 representa os módulos do cliente e a sua

interligação com os módulos do servidor.

Figura 4.2 – Módulos da Arquitectura do Cliente

Sinalização – Este módulo gera e interpreta todas as mensagens de sinalização enviadas e

recebidas pelo cliente na rede. O protocolo de sinalização utilizado é o SIP. Possui interfaces

com outros módulos, nomeadamente com o monitorizador de QoS para ajuste dos

parâmetros de negociação de sessão, e com a interface gráfica para mapeamento das

funções de controlo do vídeo (Play, Pause, Stop) em mensagens de sinalização.

Preferências – Armazena sob a forma de texto informação acerca de preferências de

visualização de determinadas streams.

RTP Extractor – Recebe da rede os pacotes RTP, e extrai do seu corpo as unidades NAL que

irão alimentar os descodificadores.

Monitorização de QoS – Este módulo analisa as perdas de pacotes, a latência e o jitter na

rede. Actua sobre o módulo de sinalização no sentido de adaptar a sessão às condições da

rede.

Descodificadores de áudio e vídeo – Descodificam os conteúdos recebidos.

45

Visualização – Módulo de visualização final do conteúdo, constituído por uma janela de

visualização.

Interface Gráfica (GUI) – Implementa a interface gráfica, através de um conjunto de menus e

botões.

4.3.3 - Funcionalidades da Solução

O cliente IPTV desenvolvido incorpora as seguintes funcionalidades:

Escolha do conteúdo a visualizar

Play – Estabelecimento da sessão e visualização dos conteúdos escolhidos.

Pausa – Pausa temporária na recepção dos conteúdos, retomando no mesmo ponto quando

desejado. Nesta função permite-se efectuar pausas rápidas recorrendo a buffering local –

TimeShifted TV, ou pausas mais prolongadas, com interrupção de envio do fluxo de pacotes

para o cliente.

Stop – Paragem de recepção dos conteúdos e terminação da sessão.

Avanço e Recuo do canal – Corresponde à troca do grupo multicast, ou stream unicast e

correspondente actualização da sessão.

Alteração Dinâmica da sessão – tendo em conta os resultados da monitorização das

condições na rede.

Alteração Manual do Nível de Qualidade - por intenção do utilizador, sem interrupção da

visualização.

Disponibilização de informação actualizada em tempo-real - Nível de qualidade da stream

actual, débito médio associado e codecs de áudio e vídeo.

4.4 - Modelo de Sinalização Proposto para IPTV Unicast

4.4.1 - Motivação

Historicamente, o RTSP tem sido o protocolo utilizado para o streaming de vídeo em transmissões

unicast. Como exemplo, considera-se o serviço de VoD do IPTV.

Os novos serviços disponíveis na Internet (e.g., VoIP, Vídeo P2P, etc) são cada vez mais exigentes

em termos da bidireccionalidade das comunicações, tornando-se necessária não apenas uma maior

largura de banda mas também a introdução de novos mecanismos nos protocolos de sinalização de

forma a gerir sessões multimédia bidireccionais.

O RTSP foi desenhado para suportar comunicações unidireccionais, um fluxo de dados do servidor

para o cliente, sendo o sentido estabelecido no inicio da sessão. A extensão deste protocolo para

funções necessárias ao serviço IPTV, tratando-se de uma possibilidade, deixa de fazer sentido se

existirem outros protocolos que já implementam alguns destes mecanismos.

46

O SIP tem vindo a ser utilizado com sucesso para serviços de Voz sobre IP, que são bidireccionais. O

SIP é um protocolo flexível, que tem vindo a adaptar-se às necessidades dos novos serviços, e tem

um papel fundamental na arquitectura IMS.

Os dois protocolos têm características complementares: o SIP tem como objectivo convidar

utilizadores para sessões e gerir sessões bidireccionais e o RTSP controlar os fluxos de áudio e

vídeo. No entanto, a sua utilização conjunta levanta questões de sincronização entre estes,

nomeadamente a replicação de funções idênticas. Nas fases de inicio, controlo e terminação da

sessão, é necessária a comutação entre o SIP e o RTSP, que devem estar sincronizados entre si na

interacção com o servidor. Este tem de ser capaz de identificar que as mensagens dos dois

protocolos estão relacionadas com a mesma sessão.

Neste sentido, no âmbito deste trabalho considerou-se vantajosa a utilização de um esquema de

sinalização totalmente baseado em SIP, em detrimento do RTSP ou da utilização mista dos dois

protocolos. Desta forma procura-se garantir a uniformização da sinalização para serviços unicast na

arquitectura. Por outro lado, com esta abordagem reduz-se o número de mensagens e tráfego

associado entre cliente e servidor nas diversas fases da sessão, com impacto positivo para a QoE.

Assim são propostas adaptações aos métodos já existentes ao nível do SIP que minimizam a

necessidade da sua extensão, para que o SIP implemente a execução de comandos PVR,

semelhantes aos do RTSP.

Com a utilização deste modelo, pretende-se demonstrar que é viável e vantajosa a utilização do SIP

em serviços IPTV – VoD, como forma de integração do serviço na arquitectura IMS.

4.4.2 - Modelo de Comunicação

A utilização exclusiva do protocolo SIP em detrimento de um modelo híbrido é vantajosa pois permite

eliminar as mensagens RTSP DESCRIBE, SETUP e TEARDOWN, o que reduz o número de

mensagens trocadas. Outra vantagem é a integração do serviço IPTV VoD com outros serviços

orientados à sessão que utilizam SIP, tal como o VoIP.

Evitando uma extensão exaustiva do protocolo SIP, que implicaria uma carga adicional nas interfaces

dos servidores que interpretam as mensagens, são reaproveitadas funções e atributos já existentes

no SIP e no SDP.

O modelo proposto, inclui o estabelecimento da sessão VoD, o controlo através da utilização de

comandos PLAY, PAUSE, rePLAY, STOP, e negociação/adaptação dinâmica dos parâmetros de

qualidade das streams recebidas, e a finalização da sessão.

O diagrama de mensagens é ilustrado na figura 4.3:

47

Figura 4.3 – Diagrama de mensagens cliente-servidor

O processo de negociação e estabelecimento da sessão apresenta diversas semelhanças com o

serviço VoIP [47], com a diferença fundamental da unidirecionalidade do fluxo de pacotes RTP, e a

adição de novos parâmetros ao SDP.

O Anexo 3 ilustra a captura das mensagens de sinalização representadas na Figura 4.3.

4.4.2.1 - Estabelecimento da sessão

O estabelecimento da sessão VoD inicia-se com o envio de uma mensagem SIP INVITE para o

servidor IPTV, que contém o URI (Uniform Resource Identifier) do vídeo e os parâmetros da sessão

presentes no SDP. O servidor responde com uma mensagem SIP 200 OK e aguarda pelo ACK do

cliente, e em caso de sucesso inicia o envio do fluxo de pacotes RTP. Em caso de indisponibilidade

do vídeo pedido, é retornada uma mensagem 404 NOT FOUND e a sessão é terminada.

A figura 4.4 ilustra a mensagem SIP INVITE enviada para o estabelecimento da sessão VoD.

48

INVITE sip:Lost.mp4@pipa.inov.pt SIP/2.0

From: <sip:cliente-iptv@84.39.2.82>

To: <sip:server-iptv@pipa.inov.pt>

CSeq: 1 INVITE

Content-Type: application/sdp

Content-Length: 415

v=0

o=SIP Server/Proxy 1234567890 1234567890 IN IP4 84.39.2.82

i=SIP IPTV Client session description

c=IN IP4 84.39.2.82

t=0 0

m=application 9 TCP/SIP sip

b=AS:300

a=connection:new

a=setup:active

a=quality:6

a=framerate:23

a=fmtp:media uri=sip:Lost.mp4@pipa.inov.pt

m=audio 1234 RTP/AVP 97

a=recvonly

a=rtcp:0

a=rtpmap:97 mpga/90000

m=video 1234 RTP/AVP 96

a=recvonly

a=rtcp:0

a=rtpmap:98 mp4v/90000

Figura 4.4 – Mensagem SIP/SDP para estabelecimento da sessão

4.4.2.2 - Controlo da Sessão

Durante a visualização o utilizador pode controlar a sessão, por exemplo fazendo um PAUSE. Este

comando é implementado em SIP através da mensagem SIP UPDATE que é enviada para o servidor.

Nesta mensagem é dada indicação ao servidor para parar o envio do fluxo RTP através do atributo

a=inactive, das streams de áudio e vídeo.

O servidor é responsável por guardar o estado da sessão, nomeadamente o instante onde o vídeo

deve retomar quando a sessão for retomada. Esta opção permite uma simplificação significativa do

lado do cliente.

Para retomar a visualização, o terminal envia uma mensagem SIP UPDATE com indicação para

retomar o envio do fluxo de pacotes RTP. Nesta mensagem é reposto o atributo a=recvonly nas

streams de áudio e vídeo. O servidor, que guardou o estado da sessão, retoma o envio do fluxo RTP

para o cliente tendo em conta o instante temporal em que ocorreu a pausa.

A figura 4.5 ilustra a mensagem SIP UPDATE enviada para o controlo da sessão, neste caso um

comando PAUSE.

49

UPDATE sip:Lost.mp4@pipa.inov.pt SIP/2.0

From: <sip:cliente-iptv@84.39.2.82>

To: <sip:server-iptv@pipa.inov.pt>

CSeq: 3 UPDATE

Content-Type: application/sdp

Content-Length: 415

v=0

o=SIP Server/Proxy 1234567890 1234567890 IN IP4 84.39.2.82

i=SIP IPTV Client session description

c=IN IP4 84.39.2.82

t=0 0

m=application 9 TCP/SIP sip

b=AS:300

a=connection:new

a=setup:active

a=quality:6

a=framerate:23

a=fmtp:media uri=sip:Lost.mp4@pipa.inov.pt

m=audio 1236 RTP/AVP 97

a=inactive

a=rtcp:0

a=rtpmap:97 mpga/90000

m=video 1236 RTP/AVP 96

a=inactive

a=rtcp:0

a=rtpmap:98 mp4v/90000

Figura 4.5 - Mensagem SIP/SDP para pausa de conteúdos

4.4.2.3 - Adaptação dinâmica da qualidade

A QoS da sessão é monitorizada exclusivamente pelo terminal, ou seja sem provisão ao nível da

rede. Quando o cliente detecta alterações na rede pode reajustar dinamicamente os parâmetros da

sessão, tentando minimizar o impacto na QoE.

Para isso, envia uma mensagem SIP UPDATE ao servidor, onde indica explicitamente no SDP que

pretende alterar o nível de qualidade da stream. Isto é conseguido através do campo a:quality,

presente no SDP, com um valor que varia entre 0 e 10. O servidor ao receber e interpretar a

mensagem adapta o ritmo de acordo com o valor do campo quality, sem terminar a sessão. Isto

implica um impacto na qualidade visual para o cliente, mas tem a vantagem de não comprometer a

sessão. Este processo foi baseado na negociação de QoS para IPTV utilizando SIP, descrita em [9].

A figura 4.6 ilustra um excerto da mensagem SIP UPDATE enviada para adaptação de qualidade:

(…)

v=0

o=SIP Server/Proxy 1234567890 1234567890 IN IP4 84.39.2.82

i=SIP IPTV Client session description

c=IN IP4 84.39.2.82

m=application 9 TCP/SIP sip

b=AS:300

a=connection:new

a=setup:active

a=quality:4

a=framerate:23

a=fmtp:media uri=sip:Lost.mp4@pipa.inov.pt

m=audio 1236 RTP/AVP 97

(…)

Figura 4.6 - Mensagem SIP/SDP para alteração de qualidade

50

4.4.2.4 - Terminação da sessão

O cliente ou o servidor podem enviar uma mensagem SIP BYE indicando a terminação da sessão e

libertando os recursos, tal como ilustrado na figura 4.7.

BYE sip:Lost.mp4@pipa.inov.pt SIP/2.0

From: <sip:cliente-iptv@84.39.2.82>

To: <sip:server-iptv@pipa.inov.pt>

CSeq: 3 BYE

Content-Length: 0

Figura 4.7 - Mensagem SIP/SDP para terminar a sessão

4.5 - Integração da Solução na Arquitectura IMS

Um dos requisitos da arquitectura cliente-servidor desenvolvida é a integração na arquitectura IMS.

Devido à inexistência desta plataforma no ambiente de desenvolvimento, os protótipos cliente IPTV e

servidor IPTV não foram implementados numa arquitectura IMS, no entanto a arquitectura

desenvolvida neste capítulo pode ser integrada em IMS, pois os módulos e as funções constituintes

estão de acordo com as funcionalidades das diversas entidades no Core IMS.

A figura 4.8 ilustra a integração da arquitectura cliente-servidor desenvolvida, na Arquitectura IMS.

Esta integração segue o modelo e requisitos de integração do IPTV em arquitecturas NGN baseadas

em IMS, como descrito pelo IPTV-FG em [22].

Do lado do servidor, o módulo Admission Control corresponde às funções Service Control Function

(SCF) para o controlo e lógica do serviço IPTV ao utilizador. O módulo de Configurações implementa

as funcionalidades de Service Selection Function e User Preference Server Function, disponibilizando

a lista de serviços disponibilizados ao utilizador, baseada nas suas preferências e perfil. O módulo

Signalling implementa as funções de sinalização, tratadas pelas Call Session Control Functions no

Core IMS, interpretando e redireccionando toda a sinalização SIP. O módulo Streaming implementa

as funções Media Delivery Functions (MDF), sendo responsáveis pela entrega do serviço aos

clientes.

Do lado do Cliente, o módulo de preferências do cliente implementa as funções UPSF, registando as

preferências do cliente. O módulo de sinalização interage com o Core IMS através das funções

CSCF, para registo, estabelecimento e controlo do serviço. O módulo RTP Extractor recebe as

streams enviadas pelas funções MDF. O módulo Monitorizador de QoS implementa as funções de

controlo do serviço (SCF), pois é responsável por decidir e gerir todo o processo de alteração e

adaptação de qualidade das streams enviadas pelo servidor.

51

Figura 4.8 – Integração da Solução na Arquitectura IMS

4.6 - Resumo

Neste capítulo foi apresentada a arquitectura de cliente IPTV desenvolvida. Definiram-se os módulos

da arquitectura, e respectivas interfaces. Cada módulo implementa um conjunto de funções, e na sua

totalidade permitem disponibilizar as funcionalidades de cliente IPTV.

Foi ainda apresentado o modelo de sinalização SIP IPTV proposto para esta arquitectura.

A arquitectura implementa funções presentes no Core do IMS. Embora esta arquitectura não tenha

sido testada numa plataforma IMS (por questões de indisponibilidade), foi apresentada a sua

integração em IMS, através do mapeamento das funções desenvolvidas com as funções presentes

no Core IMS.

52

Capítulo 5 - Implementação

Neste capítulo é descrita a implementação do protótipo de cliente IPTV desenvolvido, tendo em conta

a arquitectura apresentada no capítulo anterior. Descreve-se a metodologia de desenvolvimento do

software, as bibliotecas utilizadas, a linguagem de programação e o mapeamento destas ferramentas

nos módulos do cliente. O capítulo termina com uma breve descrição das limitações da

implementação.

5.1 - Introdução

A implementação do protótipo consistiu na criação de uma aplicação de software de visualização de

streaming de vídeo com algumas características particulares, entre as quais, a implementação de um

módulo de sinalização SIP para serviços de vídeo a pedido e a possibilidade de o cliente IPTV

efectuar uma comutação suave (sem rupturas) entre streams com débitos diferentes, como resposta

à variação das condições da rede.

Todo o desenvolvimento teve por base bibliotecas de software open-source disponíveis para sistemas

operativos Linux, que não implicam a utilização de licenças. Embora o ambiente de desenvolvimento

e execução utilizado tenha sido Linux, a maioria das bibliotecas utilizadas é portável para outros

sistemas operativos como o Microsoft Windows ou ambientes embebidos, podendo a aplicação vir a

ser adaptada futuramente para um sistema multi-plataforma.

A arquitectura do cliente IPTV foi divida em módulos, segundo as características de um cliente IPTV

genérico apresentado pelo IPTV-FG [70]. Cada módulo, ou subgrupo de módulos foi implementado

com suporte em bibliotecas específicas.

Foi utilizada a linguagem de programação C para todo o desenvolvimento. Pelo facto de esta

linguagem apresentar um suporte muito elevado ao desenvolvimento de aplicações de rede, e pela

sua comprovada eficiência e fiabilidade neste âmbito. Adicionalmente, a maioria das bibliotecas

geradoras de tráfego de sinalização, codificadores, descodificadores e tratamento de pacotes RTP

são implementadas na linguagem C.

5.2 - Fases de Desenvolvimento

A figura 5.1 descreve as fases de desenvolvimento do trabalho, que foi iniciado em Março de 2008,

com uma apresentação do projecto My eDirector, e definição dos objectivos. Na fase seguinte, que

durou aproximadamente 3 meses, foram testadas diversas plataformas de streaming, entre as quais

VideoLAN [74] e Darwin Streaming Server com cliente Quicktime [75]. Foram igualmente estudadas

ferramentas de codificação e descodificação de vídeo. Com base neste estudo foi possível efectuar

uma avaliação das funcionalidades e limitações face aos objectivos pretendidos.

53

Figura 5.1 – Fases de Desenvolvimento

A Arquitectura final da Solução foi definida em Julho de 2008, tendo sido escolhidas as ferramentas,

plataformas e bibliotecas a utilizar. A fase de implementação iniciou-se com a escrita do módulo de

sinalização, que constitui a funcionalidade inovadora neste trabalho. Este módulo foi elaborado em

regime colaborativo com os desenvolvimentos nas áreas complementares do mesmo projecto. Numa

segunda fase, este módulo foi integrado na arquitectura do cliente IPTV, com a implementação dos

restantes módulos e as interfaces entre estes.

A primeira versão completa do protótipo foi finalizada em Setembro de 2008, já incorporando as

principais funcionalidades descritas na arquitectura da solução. Procedeu-se à avaliação da solução,

tendo sido efectuados testes e correcção de bugs.

5.3 - Ferramentas e Bibliotecas Utilizadas

O protótipo foi implementado com o auxílio de ferramentas e bibliotecas de software, como ilustrado

na figura 5.2:

Figura 5.2 – Ferramentas e bibliotecas utilizadas

Segue-se uma breve descrição das características que motivaram a sua escolha, e a forma como

contribuíram para a implementação do protótipo.

5.3.1 - GNU libosip

O módulo de sinalização foi desenvolvido utilizando a biblioteca GNU libosip [76]. Esta biblioteca

implementa o protocolo SIP, descrito no RFC3261. A biblioteca está escrita na linguagem C,

54

apresenta um tamanho reduzido em termos de código e possui uma API bem documentada. A

biblioteca está dividida em vários módulos, e o mais utilizado foi o parser, responsável pela criação e

interpretação das mensagens. As funções disponibilizadas permitiram a criação das mensagens SIP

INVITE, SIP UPDATE, SIP ACK e SIP BYE, utilizadas pelo cliente.

O módulo disponibiliza ainda funções específicas para a criação das mensagens SDP que compõem

o corpo das mensagens SIP. Esta funcionalidade revelou-se importante para a adição dos campos

utilizados na descrição da sessão multimédia.

5.3.2 - libVLC

A libVLC [77] é uma biblioteca de suporte a desenvolvimento de aplicações de vídeo baseada na

solução VideoLAN que implementa o VLC Media Player [74]. Esta solução implementa

funcionalidades de visualização de múltiplas fontes e formatos, incluindo streaming, tal como ilustrado

na figura 5.3:

Figura 5.3 – Solução Completa VideoLAN para streaming [74]

A solução de streaming VideoLAN é bastante completa, incorporando funcionalidades de servidor e

cliente no mesmo software. Na perspectiva do servidor, estão disponíveis funcionalidades de

transcoding e transrating, que são bastante úteis para codificar diversas vezes a mesma fonte, com

parâmetros diferentes. Os parâmetros de codificação disponíveis são os débitos das stream de áudio

e de vídeo, os codecs, e a resolução espacial. As streams codificadas podem ser encapsuladas em

diversos formatos: MPEG TS, MPEG PS, Raw, entre outros. Como formato de saída estão

disponíveis as seguintes opções: fluxo de pacotes RTP/UDP, gravação para ficheiro, MMSH e HTTP.

Na perspectiva do cliente, a visualização pode ter como fonte ficheiros locais, CD/DVD, dispositivos

de captura de vídeo ou streaming da rede. O cliente pode iniciar a visualização em streaming através

dos protocolos RTSP, HTTP, MMS, ou directamente a partir de um fluxo RTP/UDP Unicast/Multicast

num determinado porto.

55

Devido ao elevado número de funcionalidades disponíveis, em particular a diversidade de formatos

de entrada e saída, codificadores e descodificadores, a solução VideoLAN (através da libVLC) foi

escolhida para implementação dos módulos RTP Extractor e Descodificador do cliente.

No Anexo 1 inclui-se a descrição detalhada de todos os formatos de entrada e saída, assim como as

normas de codificação suportadas pela versão da libVLC utilizada.

No Anexo 2, demonstra-se a utilização desta biblioteca na implementação de um cliente simplificado.

5.3.3 - GTK+

O GTK+ [78] é uma biblioteca open-source para implementação de Interfaces Gráficas, criada

originalmente para o X Window, sendo actualmente multi-plataforma. Está escrita em linguagem C e

permite o desenvolvimento de aplicações sem quaisquer custos de licenças – GNU LGPL 2.1. Possui

uma API de fácil utilização que está bem documentada [78], com diversas referências e exemplos

práticos. A sua eficácia é comprovada pelo longo portfólio de ferramentas que a utilizam [78].

5.3.4 - Glade

A Interface Gráfica do protótipo em Linux foi desenhada através da ferramenta GLADE 2 [79].

O GLADE é uma ferramenta de desenvolvimento de interfaces gráficas para o Linux em ambiente

GNOME que se baseia na utilização da biblioteca GTK+. Esta ferramenta permite desenhar a GUI em

método de drag-and-drop, podendo ser exportada em formato XML ou, alternativamente, gerar o

código fonte correspondente. As interfaces criadas podem ser utilizadas em aplicações escritas em

diversas linguagens, incluindo linguagem C.

A figura 5.4 ilustra o desenvolvimento da Interface Gráfica na ferramenta GLADE:

Figura 5.4 – Ferramenta GLADE utilizada no desenho da Interface Gráfica

56

Esta ferramenta é de distribuição livre, e apresenta uma documentação completa, incluindo diversos

Tutoriais e exemplos ilustrativos da sua utilização.

5.4 - Implementação dos Módulos

5.4.1 - Módulo de Sinalização

O módulo de sinalização é iniciado quando o utilizador prime a tecla PLAY pela primeira vez,

estabelecendo-se a sessão com o servidor. Foi implementada uma função init_signalling() que inicia a

máquina de estados apresentada na figura 5.5:

Figura 5.5 – Máquina de estados do módulo de Sinalização

Um exemplo de interacção do cliente com o servidor, é o seguinte:

1. O utilizador introduz um SIP URI, por exemplo sip:futebol.mp4@pipa.inov.pt e prime PLAY

2. Enviado um SIP INVITE para o servidor.

3. Em caso de sucesso o servidor responde com SIP 200 OK e estabelece-se a sessão com a

recepção de um fluxo de pacotes RTP no porto especificado pelo cliente.

4. Utilizador efectua uma Pausa, ou ocorre uma actualização dos parâmetros da sessão

multimédia (e.g., nível de qualidade), com envio de SIP UPDATE para o servidor.

5. Utilizador prime STOP, enviando um SIP BYE ao servidor.

Foram implementadas funções para cada estado e respectivas transições utilizando a API da libosip.

5.4.2 - RTP Extractor e Decoder

Estes módulos foram implementados através das funções de alto nível disponíveis na libVLC. A

biblioteca permite abstracção ao nível da extracção dos pacotes RTP recebidos da rede e da

descodificação do seu payload pelos codecs de áudio e vídeo. Como consequência, não é efectuado

controlo directo ao nível das tramas de áudio e vídeo recebidas da rede, sendo essa função delegada

para a biblioteca.

57

O código simplificado do conjunto de instruções utilizado, é o seguinte:

libvlc_exception_init (&excp);

char *vector = “player –I dummy rtp://@ :1234 :access-filter=timeshift”;

libvlc_instance_t *inst = libvlc_new (5, vector, &excp);

libvlc_playlist_play (inst, -1, 0, NULL, &excp);

Na sequência, iniciam-se as excepções a lançar em caso de erro, e cria-se um vector de caracteres

que contém o conjunto de instruções dadas à biblioteca. Neste caso, as instruções são para a criação

de um cliente IPTV que recebe uma stream de pacotes RTP no porto 1234 com a opção extra

timeshift para permitir desfasamento temporal. Para tal, é criada uma nova instância libvlc que recebe

como argumento o vector de instruções. Esta instância é passada de seguida como argumento da

função play que inicia a visualização com o lançamento de uma janela simples de vídeo.

Este módulo implementa uma memória de recepção – buffer – de tamanho configurável através da

opção caching. Foi utilizado o valor por defeito, de 300 ms. Esta funcionalidade é fundamental para

compensar as variações de atraso de chegada dos pacotes, impedindo que os descodificadores

deixem de ser alimentados em tempo real, o que causaria interrupção na visualização.

5.4.3 - Monitorização QoS

O módulo de monitorização de QoS mete o RTT, a sua variação, e as perdas de pacotes na rede.

Para medição do RTT foi utilizado o código fonte da aplicação ping integrado na implementação como

wrapper. Periodicamente, o módulo invoca esta ferramenta e efectua um conjunto de ICMP Echo

Requests ao servidor, tratando os Echo Reply para obter os valores de RTT mínimo, máximo e médio

da amostra, que são guardados numa estrutura de dados que é analisada pelo módulo. Este

processo é importante pois além de analisar a latência, permite testar a ligação ao servidor,

despistando possíveis falhas. As perdas de pacotes são monitorizadas através de uma variável que é

incrementada sempre que há um salto no número de sequência de um pacote recebido. Em cada

iteração os novos dados são comparados com os obtidos anteriormente.

A estrutura de dados contém ainda informação relativa ao número e taxa de perdas de pacotes RTP,

largura de banda disponível e tramas de áudio e vídeo descartadas ou perdidas. Estas estatísticas

serão desenvolvidas e utilizadas numa fase posterior através introdução de métodos avançados de

adaptação de conteúdos, e por essa razão não foram utilizados nesta fase do trabalho.

5.4.4 - Interface Gráfica

A interface gráfica é composta pelas funções PVR de controlo do vídeo (Play, Pausa e Stop), e um

painel informativo da sessão multimédia (codecs utilizados, nível de qualidade e débitos associados).

A figura 5.6 ilustra o aspecto da Interface Gráfica:

58

Figura 5.6 – Interface Gráfica

Os botões e menus da interface gráfica estão associados a rotinas assíncronas, que constituem

eventos e são invocadas quando o botão é premido.

void on_stop_button_clicked (GtkButton *button, gpointer user_data);

void on_play_button_clicked (GtkButton *button, gpointer user_data);

void on_pause_button_clicked (GtkButton *button, gpointer user_data);

Por sua vez, cada uma destas rotinas está associada a uma função da interface com o módulo de

sinalização. Por exemplo, a rotina do botão Play é responsável por invocar a função init_signaling()

que envia o primeiro SIP INVITE ao servidor, e a rotina de eventos do botão Stop invoca a função

stream_close(), responsável por enviar a mensagem SIP BYE ao servidor.

5.4.5 - Visualização

Este módulo está incluído na biblioteca libVLC, sendo iniciado após a chamada da função

libvlc_playlist_play() pelo módulo RTP Extractor. É constituído pela janela de visualização de vídeo e

pela saída de áudio. A janela de visualização mantém-se aberta enquanto existirem dados no buffer

de recepção.

Figura 5.7 - Janela de Visualização de Vídeo com Interface Gráfica

59

Na figura 5.7 ilustra-se o efeito gráfico da janela de visualização. As duas janelas são independentes,

pois são controladas por bibliotecas diferentes. Quando é premido o botão de Stop, a visualização é

fechada, mantendo-se apenas a janela controladora.

5.4.6 - Gestão de Preferências

O módulo de gestão de preferências é composto por um conjunto de funções que recebem como

entrada um ficheiro de texto – config.conf.

Este ficheiro está localizado na directoria de execução do cliente IPTV e agrega configurações tais

como os codecs de áudio e vídeo suportados, as normas de compressão em que o conteúdo deve

ser recebido na próxima sessão, endereços IP do servidor e do cliente e o valor de tempo limite

associado à pausa local. (em segundos)

/*

** config.conf

** Ficheiro de configuração de cliente

*/

SERVER_IP 84.39.2.82

CLIENT_IP 84.39.4.201

START_QUALITY 6

AUDIO_CODEC mpga

VIDEO_CODEC h264

PAUSE_TIMEOUT 10

As configurações são carregadas no arranque do programa cliente, sendo necessário reiniciar em

caso de alteração.

5.5 - Limitações da Implementação

Nesta secção são descritas as principais limitações da implementação, assim como as dificuldades

encontradas durante a fase de desenvolvimento. Apresentam-se as soluções encontradas para

minimizar essas limitações, e as opções que foram tomadas relativamente a funcionalidades não

consideradas para implementação nesta fase.

5.5.1 - Dificuldades na transição suave entre streams

A libVLC apresenta limitações na troca de faixas. Do lado do servidor, o processo associado à troca

de stream começa por parar o conteúdo multimédia actual, abrir o conteúdo seguinte e avançá-lo

para a posição pretendida. Do lado do cliente este processo tem algumas consequências, como a

possibilidade da janela de visualização fechar e voltar a abrir, ou os conteúdos serem afectados pela

presença de artefactos visuais durante alguns segundos. Deste modo foram implementados alguns

métodos para contornar este tipo de problema:

A opção –sout-keep mantém a janela aberta quando é trocada a entrada. Esta opção permite

que a leitura não pare quando se troca a stream.

60

Delegar totalmente a responsabilidade das trocas para o lado do servidor. Desta forma o

cliente não tem de alterar nenhuma opção em tempo de visualização, não se apercebendo

que na realidade existiu uma troca.

Implementar no servidor a técnica que consiste seguinte: quando é sinalizada a alteração, é

criada uma nova instância que envia a nova versão imediatamente para o cliente. Durante um

breve instante, que corresponde ao tempo médio de atraso entre os dois extremos (medido

pelo cliente) as duas instâncias estão a enviar em paralelo. Após esse tempo, a primeira

instância é fechada, conseguindo desta forma que do lado do cliente o buffer de recepção

nunca fique vazio e o cliente inicie a visualização da nova versão instantaneamente.

A viabilidade da última solução está fortemente dependente do tamanho do GOP (devido ao

espaçamento entre tramas âncora) e do valor de jitter na rede.

5.5.2 - Monitorização de QoS

A libVLC não permite tratamento ao nível da trama de vídeo, nem o controle do tráfego RTP recebido.

Como tal não foi possível medir a taxa de pacotes RTP perdidos através desta biblioteca. As perdas

são monitorizadas por aplicações incorporadas – wrappers - que podem levar a conclusões erradas.

Esta limitação poderia ser contornada com a implementação de um módulo extra no cliente que

escutasse a rede à entrada, analisando a estrutura e conteúdo dos pacotes RTP recebidos,

nomeadamente os números de sequência, tipo de tramas de vídeo transportadas, número de tramas

de vídeo perdidas, etc. Esta solução não foi implementada devido à complexidade adicional que iria

introduzir também por só se ter chegado a esta conclusão numa fase tardia do projecto.

5.5.3 - Segurança

O protótipo cliente não contempla funcionalidades de segurança, tais como o controlo de acesso,

registo de utilizadores, autenticação do servidor ou cifra/decifra de conteúdos. Esta opção justifica-se

com o facto de os aspectos de segurança não serem uma prioridade no tema central deste trabalho.

No entanto, a arquitectura modular permite que estas funcionalidades sejam adicionadas em futuras

extensões à arquitectura apresentada.

5.5.4 - Recuperação de falhas

Outra limitação do cliente é a sua dependência da disponibilidade do servidor, isto é o programa

funciona correctamente enquanto o servidor estiver disponível. Em caso de falha durante a sessão o

cliente detecta a perda de ligação com o servidor, mas não efectua a comutação automática para um

servidor secundário. Neste caso, o utilizador é responsável por iniciar nova sessão num servidor

alternativo.

61

5.6 - Resumo

Neste capítulo foi apresentada a implementação da solução, nomeadamente o resultado final e as

ferramentas utilizadas durante o desenvolvimento do protótipo. Fez-se uma breve descrição da forma

como estas foram utilizadas para desenvolver cada módulo da arquitectura do cliente, e as principais

dificuldades e limitações.

62

Capítulo 6 - Avaliação da Solução

Neste capítulo descreve-se o processo de avaliação da solução implementada para o cliente IPTV.

Na primeira secção é efectuada uma apreciação global da implementação, comparando as

funcionalidades deste cliente IPTV com outras soluções streaming por software, sendo realçadas as

características inovadoras desta solução, e os seus principais benefícios.

Com o objectivo de testar o comportamento do sistema em condições heterogéneas, foram

efectuados testes em duas condições distintas: em rede local e em rede de banda larga móvel

CDMA2000.

Descrevem-se os testes funcionais e não funcionais efectuados, indicando-se ainda a metodologia, o

ambiente de teste e os procedimentos seguidos.

6.1 - Avaliação do Protótipo do cliente IPTV

A implementação do protótipo de cliente IPTV permitiu adicionar um conjunto de qualidades e

funcionalidades não disponíveis noutros pacotes de software cliente que utilizam o protocolo RTSP

para serviços de VoD. Na tabela 6.1 comparam-se as funcionalidades efectivamente implementadas,

face a outras aplicações cliente:

Funcionalidades do Cliente

QuickTime

Basic (RTSP)

VideoLAN

(RTSP)

Protótipo

Cliente IPTV (SIP)

Controlo – Play, Pause, Stop, etc

Identificação de Sessão

Actualização de Sessão

SDP

Suporte a VoD

Interface Gráfica

Suporte a LiveTV

Transições suaves de Canal

Transições suaves de Qualidade

Monitorização de QoS / QoE

Adaptação de conteúdos em função das condições da rede

Integração com outros Serviços (e.g., VoIP)

Integração na Arquitectura IMS

Tabela 6.1 – Avaliação de Funcionalidades do Protótipo

63

O carácter inovador do cliente IPTV implementado neste trabalho reside no modelo de sinalização

totalmente baseado em SIP, para os serviços VoD e LiveTV, unicast ou multicast. Até a data foram

propostos alguns trabalhos que se baseiam numa utilização híbrida do SIP com o RTSP, para

integração na arquitectura IMS, e considerava-se que o SIP não seria adequado para controlo de

sessões de vídeo [7]. Neste trabalho, a utilização do SIP revelou-se fundamental na implementação

de todas as funcionalidades cliente descritas na tabela 6.2, o que comprova que é possível utilizar

este protocolo para controlo de streaming multimédia, em detrimento de protocolos tradicionais como

o RTSP para serviços unicast.

Na tabela 6.2, efectua-se uma análise comparativa do modelo de sinalização SIP do cliente IPTV

desenvolvido, face à utilização protocolo RTSP para serviços unicast:

Funcionalidade do Cliente

No. Mensagens Tamanho (KB)

RTSP SIP RTSP SIP

ES 10 4 3 1.7 MC 12 3 3.6 1.3 AQ 12 3 3.6 1.3 TP 2 3 0.4 1.2 TS 2 2 0.5 0.8

ES – Estabelecimento da Sessão MC – Mudar de Canal AQ – Alteração de Qualidade TP – Pausa da Emissão TS – Terminação da Sessão

Tabela 6.2 – Comparação RTSP / SIP para serviços unicast

A utilização do SIP permite reduzir substancialmente o número de mensagens e o tráfego de

sinalização necessário em todas as funcionalidades. Consequentemente, o tempo de processamento

nos extremos, o tráfego na rede, e o atraso de transmissão são menores relativamente à utilização da

mesma funcionalidade com recurso ao RTSP.

Outra funcionalidade inovadora é a adaptação dinâmica da sessão face às condições da rede, com o

objectivo de maximizar a QoE em cada instante para todos os utilizadores. Esta adaptação é feita de

forma suave, sem intervenção do utilizador.

6.2 - Ambiente e Metodologia de Teste

Para a avaliação do protótipo foram executados testes em dois tipos de ambiente de acesso:

Clientes numa rede local (GbE universitária)

Clientes em rede de acesso rádio 3G CDMA em banda larga.

Em cada uma das redes de acesso foram testadas todas as funcionalidades implementadas, assim

como medições de desempenho do serviço.

Para a avaliação do desempenho e da adaptabilidade do cliente IPTV às condições do canal foram

adoptados os seguintes métodos:

64

Em rede local, limitando antecipadamente a largura de banda entre o servidor IPTV e o

cliente em tempo de execução.

Em rede WAN 3G variando os locais e os períodos de medição (considerando os períodos de

ponta ou de vazio, segundo indicações do operador).

No caso particular do acesso 3G, foram ainda efectuados testes de desempenho da rede de acesso,

que resultaram na sua caracterização em termos de débito, perdas de pacotes, latência e variação de

atraso (no sentido descendente). Utilizaram-se equipamentos CDMA450 Zapp Z010 com interface

USB com os computadores cliente. As medições foram efectuadas em ambiente interior, no campus

do IST-TagusPark e em habitações na área da Grande Lisboa em diversos períodos do dia. Estes

testes foram determinantes para caracterizar as limitações deste tipo de acesso, e poder assim

decidir sobre as normas de codificação e compressão, e os níveis de qualidade e débitos adequados,

a cada caso.

O ambiente de testes simplificado está ilustrado na figura 6.1:

Figura 6.1 – Ambiente de Testes CDMA/LAN

O servidor IPTV (SIP IPTV AS) esteve localizado numa rede do INESC em Lisboa, integrada com o

prestador do serviço de Internet móvel 3G. No Core do ISP foi instalado um simulador de tráfego. Os

clientes 3G utilizam os modems USB para acesso ao serviço e os clientes LAN utilizam a rede do

campus do IST.

65

6.2.1 - Equipamentos

Os equipamentos utilizados no ambiente de testes foram os seguintes:

Ambiente Cliente IPTV:

PC Laptop CPU Centrino 1.73 GHz, 2MB Cache L2, 1GB Memória

RAM, Sistema Operativo Ubuntu 8.04 LTS e Modem Zapp.

Ambiente Servidor IPTV:

IPTV AS – PC Desktop CPU Pentium 4 3.0 GHz, 1MB Cache L2,

Memória RAM 512 MB, Sistema Operativo Ubuntu 8.04 LTS

MEDIA ENCODER – PC Desktop Intel Core2Duo 6420 2.6 GHz, 4

MB Cache L2, 2 GB Memória RAM, Sistema Operativo Windows XP

6.2.2 - Ferramentas e tipos de Teste

A tabela 6.3 resume os testes e medições efectuados e as respectivas ferramentas utilizadas:

Tipo de Teste Objectivos e Acções Ferramenta Observações

Desempenho da Rede de Acesso

CDMA

Captura e Análise do Tráfego na rede

Wireshark [80]

Contagem de nºs de sequência em falta ou fora de ordem.

Medição do Atraso extremo-a-extremo

Ping / FPing Diversos valores de tamanho de pacote.

Estimação da largura de banda disponível no sentido descendente

IPerf [81] Geração de tráfego UDP servidorcliente com estimativa

do débito efectivo no sentido descendente

Cálculo da taxa de perdas na rede

FPing / IPerf Estimação da taxa de perdas e possível impacto na QoE

Funcionais

Medição dos tempos de execução das

funcionalidades (Play, Pause, etc)

Protótipo + Cronómetro

Ubuntu

Conjunto de testes de serviço, com medição de tempos

associados às funcionalidades básicas.

Teste às Funcionalidades do programa

Protótipo Verificação do correcto funcionamento.

Teste à adaptação / alteração dinâmica da

Qualidade

Trickle [82] + Protótipo

O Trickle permite limitar a largura de banda a utilizar,

simulando congestionamento na rede.

Não-Funcionais

Medição da QoE relativamente à qualidade

visual do vídeo

Protótipo Análise da QoE utilizando o método DSCQS.

Medição do Desempenho do programa cliente

CACTI [83] Medição da ocupação em memória e carga do sistema.

Tabela 6.3 – Testes efectuados e ferramentas utilizadas

66

6.2.3 - Procedimentos

A metodologia de execução dos testes considerou os seguintes procedimentos:

Avaliação de desempenho da rede de acesso 3G

Funcionalidade do cliente IPTV (Testes Funcionais)

Avaliação da Qualidade no cliente IPTV (Testes Não-Funcionais)

6.2.3.1 - Desempenho da Rede de Acesso CDMA

Para os testes de desempenho da rede de acesso CDMA, foi disponibilizado um sistema no Core da

rede do operador, tendo sido instalada a ferramenta IPerf. Esta ferramenta é responsável por gerar

tráfego UDP em pacotes de 1470 bytes, para o endereço do cliente equipado com o equipamento

móvel, estimando-se o débito efectivo no sentido descendente.

O teste foi efectuado durante cerca de 10 minutos, com intervalo de envio de pacotes de 1 segundo,

com cliente estacionário:

Sistema Core: iperf –c 84.39.4.201 –u –i 1 –b 2.4M –p 6970

Cliente CDMA: iperf –p 6970 –s –u –i 1

Foram também efectuados testes com as ferramentas Ping/FPing de forma a obter valores de RTT,

perda de pacotes, atraso e variação de atraso. Utilizaram-se diversos parâmetros, como o – i

(intervalo de emissão) e o – s (tamanho dos dados):

Sistema Core: ping –s 512 –i 1 84.39.2.201

Os resultados foram analisados através do analisador de tráfego Wireshark e dos ficheiros de texto

gerado pelas aplicações, com tratamento numérico posterior em folhas de cálculo.

6.2.3.2 - Testes Funcionais

O servidor de codificação utilizado encontra-se configurado com os canais livetv-1 e livetv-2, e o filme

ET.mp4, estando disponível via URI em pipa.inov.pt. O servidor pode entregar 10 versões de cada

conteúdo, que variam entre si ao nível da qualidade. A cada versão corresponde um valor numérico

de 0 a 10, sendo 0 a qualidade mínima e 10 a máxima.

Inicialmente, o cliente IPTV foi configurado (ficheiro config.conf) com o endereço do servidor, os

codecs de áudio e vídeo suportados, e o valor inicial de qualidade. As normas de codificação

utilizadas são a família MPEG4 para vídeo e MPEG Layer 2 para áudio.

Nos testes de adaptação dinâmica, optou-se exclusivamente pelo MPEG4 Visual em detrimento do

seu sucessor AVC - H.264 devido a razões de desempenho do sistema do codificador. Os débitos

médios à saída do codificador variam entre 16 Kbit/s - nível 0 - e 292 Kbit/s - nível 10. Após a

configuração inicial, efectuaram-se pedidos ao servidor, introduzindo o sip uri correspondente (e.g.,

sip:livetv-1@pipa.inov.pt)

67

Foram testadas todas as funcionalidades do protótipo, tendo sido medidos os tempos de execução

associados.

6.2.3.3 - Testes Não-Funcionais

Realizaram-se dois tipos de avaliação da Qualidade: Avaliação subjectiva da qualidade visual;

Desempenho do cliente IPTV ao nível do terminal.

Avaliação subjectiva da Qualidade Visual

Foi avaliada a qualidade subjectiva do vídeo, através do indicador MOS.

Utilizou-se o método Double-Stimulus Continuous Quality-Scale (DSCQS), seguindo a recomendação

BT.500-11 da ITU-R [63]. Este método tem como objectivo medir o factor qualidade oferecido pelo

sistema relativamente a uma referência, avaliando o impacto da transmissão. Este método é

particularmente útil quando o sistema não pode exibir o nível de qualidade de referência.

O método é cíclico, sendo que o avaliador observa um par de imagens da mesma origem, atribuindo

uma nota a cada uma delas: Uma das imagens corresponde à referência, ou seja, directamente da

fonte original; A outra corresponde à imagem sujeita ao processo em análise, neste caso à

codificação a um ritmo inferior e à sua transmissão na rede.

A classificação é atribuída numa escala vertical de 0-5 valores, de acordo com a escala de qualidade

do ITU-R. O valor 1 corresponde à classificação “Mau” e o valor 5 corresponde à classificação

“Excelente”.

As imagens são mostradas aleatoriamente, cobrindo todas as combinações possíveis. Os utilizadores

não sabem qual é a imagem de referência. No final, são calculadas as médias para cada condição de

teste.

Em termos práticos, na utilização do método DSCQS especificado pela ITU-R, considera-se que foi

efectuada uma aproximação à utilização da Variante II, face às condições disponíveis para a

avaliação de um sistema em fase de protótipo. Nomeadamente, foi efectuada uma aproximação de

condições em termos do tamanho da amostra e do hardware utilizado para a visualização.

Na avaliação da solução foram realizados 4 testes por utilizador, com o objectivo de avaliar a

qualidade visual subjectiva em transmissão streaming em LAN e CDMA, para as normas MPEG4 –

Visual e H.264.

Os testes foram realizados em ambiente doméstico com iluminação natural, com um universo

reduzido de 5 utilizadores com idades correspondidas entre os 18 e os 70 anos. A cada utilizador foi

fornecido um computador e a escala vertical de classificação, representada na figura 6.2. A duração

da sequência é aproximadamente 60 segundos. O intervalo entre cada teste é de 5 minutos.

68

Figura 6.2 – Escala contínua de classificação [63]

Foram exibidas aleatoriamente 6 sequências de vídeo iguais, que incluem a sequência original e 5

sequências sujeitas à transmissão na rede, codificadas com débitos entre os 32 e os 292 Kbit/s.

Pediu-se aos utilizadores que atribuíssem a classificação correspondente a cada sequência.

Desempenho do Terminal

Para o teste de desempenho do serviço, foram efectuadas medições da utilização da memória RAM,

utilização mantêm de CPU e carga média do sistema. Foi utilizada a ferramenta CACTI, que permite

exportar os resultados sobre a forma de gráficos pré-formatados [83].

6.3 - Avaliação de Resultados

Nesta secção são apresentados os resultados obtidos com os testes efectuados, e a respectiva

análise crítica face às expectativas e objectivos da arquitectura e implementação.

6.3.1 - Testes de Desempenho da Rede de Acesso CDMA

Os resultados dos testes de desempenho da rede de acesso CDMA, incluem os valores medidos de

RTT, jitter, débito efectivo no canal descendente e taxas de perdas de pacotes. São tratados como

resultados intermédios, que permitem uma melhor avaliação e interpretação do desempenho do

cliente neste tipo de rede.

6.3.1.1 - Atraso e variação de atraso (jitter)

A tabela 6.4 resume os valores de atraso medidos, para ambos os modos de ligação no sistema

CDMA 2000, usando pacotes IP com dimensão 128, 256, 512 e 1024 bytes.

69

Modo de Ligação

Payload (bytes)

RTT médio (ms)

RTT mínimo (ms)

RTT máximo (ms)

Desvio Padrão (ms)

EV-DO

128 309.11 187 3228 132.32

256 394.64 235 2660 116.41

512 516.47 266 2822 130.70

1024 670.03 291 4124 205.65

1xRTT 128 552.10 318 4143 192.47

256 798.28 471 3822 164.36

512 927.45 214 4911 406.08

1024 534.30 270 3854 242.00

Tabela 6.4 – Medições do RTT na rede CDMA

Figura 6.3 – Atraso e jitter no modo de ligação EV-DO

Figura 6.4 – Atraso e jitter no modo de ligação 1xRTT

Pela análise da distribuição dos valores medidos (com recurso à função cumulativa de distribuição –

CDF – ilustradas nas figuras 6.3 e 6.4) constata-se que os valores de atraso são bastante elevados

para aplicações sensíveis ao atraso (e.g., VoIP), ou seja mais de 90% dos casos acima de 100 ms.

Em modo EV-DO, a tendência é para um crescimento proporcional ao aumento do tamanho dos

pacotes. No caso do modo 1xRTT, constatou-se um aumento significativo do atraso para o payload

de 512 bytes, sendo que este valor é menor para um payload de 1024 bytes. Neste sistema, este

0

0.2

0.4

0.6

0.8

1

1.2

1 225 449 673 897 1121

RTT (ms)

CD

F P

[X <

x]

Payload 128B Payload 256B

Payload 512B Payload 1024B

0

0.2

0.4

0.6

0.8

1

1.2

0 5

10

15

20

25

30

35

40

Jitter (ms)

CD

F P

[X <

x]

0

0.2

0.4

0.6

0.8

1

1.2

1 300 599 898 1197 1496 1795

RTT (ms)

CD

F P

[X <

x]

Payload 128B Payload 256B

Payload 512B Payload 1024B

0

0.2

0.4

0.6

0.8

1

1.2

0

25

50

75

Jitter (ms)

CD

F P

[X <

x]

70

fenómeno está relacionado com a estruturação dos canais de tráfego, dependendo da quantidade de

dados a transmitir e das condições do canal.

Para o streaming de vídeo, estes valores, condicionam negativamente o tempo de disponibilização e

reacção do serviço às acções do utilizador, como por exemplo o tempo de estabelecimento de sessão

ou troca de canal, sendo o valor máximo recomendado de 200 ms [13].

Tal como visto no capítulo 2, o vídeo sobre IP é moderadamente tolerante ao atraso, mas bastante

sensível à sua variação. Os resultados medidos indicam que em 90% do tempo o valor é inferior a 40

ms para o modo 1xRTT e 25 ms para o modo EV-DO. Estes valores são inferiores ao limite máximo

recomendado – 50 ms [13], e ao tamanho do buffer de recepção do cliente – 300 ms.

6.3.1.2 - Débito efectivo no canal descendente

Os resultados obtidos variam com o modo de ligação utilizado. O débito instantâneo para o modo

1xRTT é apresentado no gráfico da figura 6.5.

Figura 6.5 - Débito instantâneo no canal descendente (modo 1xRTT)

Neste sistema observou-se um comportamento bastante estável em termos de débito médio, com um

valor interessante de 132 Kbit/s. Ocasionalmente observaram-se valores próximos dos 50 Kbit/s, e

picos máximos na ordem dos 162 Kbit/s que atingindo o limite máximo combinado dos canais de

tráfego deste sistema (canal fundamental e canal suplementar).

Para o modo EV-DO, o resultado dos testes efectuados denunciaram comportamento diferenciado de

tráfego na rede consoante a localização e hora do dia. Esta dedução é baseada nos débitos

conseguidos durante dois períodos distintos, o período da manhã e o período da tarde (ponta de

rede).

Os gráficos das Figuras 6.6 e 6.7 ilustram o débito efectivo medido no canal descendente nos

períodos da manhã e da tarde, respectivamente:

0

50

100

150

200

0 30 60 90 120 150 180 210 240 270 300 330 360 390 420 450 480 510 540 570

Déb

ito

(Kb

it/s

)

Tempo (s)

71

Figura 6.6 - Débito instantâneo no canal descendente (modo EV-DO) – Período Manhã

Figura 6.7 - Débito instantâneo no canal descendente (modo EV-DO) – Período Tarde

No período da manhã alcançou-se um débito médio interessante de 1,3 Mbit/s. Neste período

verificou-se um comportamento muito estável, com quebras pontuais abruptas do débito para valores

na ordem dos 30 Kbit/s. Este fenómeno ocorreu diversas vezes, com um padrão que aparenta ser

repetitivo, devido à acção do escalonador dos canais de tráfego da rede CDMA.

Na segunda situação, o teste foi efectuado no período da tarde, numa localização coberta por um

sector da BTS com elevado número de utilizadores activos, no interior das instalações do operador.

Neste caso o débito médio foi de 246,5 Kbit/s. Neste período, o comportamento é bastante irregular.

Figura 6.8 – Débito efectivo no canal descendente nos modos 1xRTT e EV-DO

0

0,5

1

1,5

2

0 30 60 90 120 150 180 210 240 270 300 330 360 390 420 450 480 510 540

Dé

bit

o (M

bit

/s)

Tempo (s)

0

200

400

600

800

1000

0 30 60 90 120 150 180 210 240 270 300 330 360 390 420 450 480 510 540

Déb

ito

(Kb

it/s

)

Tempo (s)

0

0.2

0.4

0.6

0.8

1

1.2

60 110 160

Débito (Kbit/s)

CD

F P

[X <

x]

0

0.2

0.4

0.6

0.8

1

1.2

0

0.2

5

0.5

0.7

5 1

1.2

5

1.5

1.7

5 2

2.2

5

2.5

Débito (Mbit/s)

CD

F P

[X <

x]

72

Pela análise do CDF (gráfico da Figura 6.8) constata-se que apenas em 20% dos casos o débito

esteve abaixo dos 110 kbit/s para o modo 1xRTT, e abaixo de 1 Mbit/s para o modo EV-DO.

Estes resultados demonstram que a utilização do modo EV-DO em períodos de baixo

congestionamento apresenta um desempenho muito bom, com comportamento estável e bons

valores de débito médio. No entanto durante alguns períodos do dia podem ocorrer grandes

oscilações de largura de banda, possivelmente devido ao maior número de utilizadores activos.

Ainda que os valores medidos estejam abaixo dos valores teóricos alcançáveis, as medições

efectuadas demonstraram que são possíveis ritmos de transferência bastante interessantes,

oferecendo uma óptima margem de conforto para a configuração dos débitos de codificação

associados às diferentes qualidades.

6.3.1.3 - Perdas de Pacotes

Na perspectiva do utilizador, a perda de pacotes contribui para diminuir a QoE, podendo introduzir

diversos artefactos visuais na imagem e no som. O impacto negativo da perda de tramas de vídeo

está directamente relacionado com o tipo de trama perdida, como tal, valores elevados de perdas

podem ter efeitos bastante negativos [13].

Na tabela 6.5 apresentam-se os valores para a taxa de perdas de pacotes na transmissão de três

streams de áudio e vídeo com débitos diferentes, e para ambos os modos da ligação.

Modo de Ligação Débito (kbit/s)

Pacotes Enviados

Pacotes Perdidos

Pacotes Perdidos (%)

1xRTT

50 2859 0 0.00

100 6532 0 0.00

150 4051 6 0.15

EV-DO 50 3828 8 0.21

100 5103 12 0.24

300 22961 140 0.61 Referência [13] 1800 - 4 pacotes IP/h <= 6.68x10

-6

Tabela 6.5 – Taxa de Pacotes Perdidos

A análise dos resultados revela que os valores de perdas de pacotes são superiores aos limites

recomendados pelo BroadBand Forum para transmissão de serviços de vídeo em definição standard

a 1.75 Mbit/s [13].

No entanto, esta recomendação considera apenas serviços IPTV oferecidos sobre redes de acesso

DSL, com provisão de QoS na rede, onde se garantem níveis de qualidade de serviço, tais como

baixos valores de atraso e jitter e taxas de perdas muito reduzidas.

Em comparação, o canal de acesso rádio CDMA é um meio propício a interferências e erros, devido

às características particulares de propagação, e não considera mecanismos de provisão de QoS ao

nível da rede para o serviço streaming. Considera-se que os valores de perdas de pacotes medidos

são, em termos relativos razoavelmente bons, e não comprometem a QoE face às expectativas dos

utilizadores.

73

6.3.2 - Testes Funcionais

6.3.2.1 - Testes de Funcionalidades do cliente IPTV

Os testes de serviço efectuados pretendem medir o desempenho do software cliente a reagir aos

pedidos dinâmicos e/ou do utilizador, utilizando o modelo de sinalização implementado. Os valores

medidos são comparados com valores de sinalização de referência do BroadBand Forum para

serviços IPTV Triple-Play.

Os tempos considerados foram:

Estabelecimento da sessão – Tempo total decorrido entre premir o botão Play e o canal estar

visível no ecrã.

Pausa de emissão – Tempo total decorrido entre premir o botão Pause e a imagem parar.

Mudança de canal – Tempo total decorrido entre premir o botão avançar e o novo canal estar

visível no ecrã.

Troca do nível de Qualidade - Tempo total decorrido entre o pedido de alteração originado

pelo Monitorizador de QoS, e a alteração visível no ecrã.

Terminação da sessão – Tempo total decorrido entre premir o botão Stop e sessão ser

terminada.

Acesso Medidas ES (ms) MC (ms) AQ (ms) TP (ms) TS (ms)

LAN

Média 2977 2641 1550 318 672 Mínimo 2220 1890 940 112 280 Máximo 4060 3220 2070 610 1710 Desvio Padrão

504 460 410 168 395

CDMA

Média 3749 3790 3381 367 1090 Mínimo 3110 3060 2110 110 410 Máximo 6010 5240 5080 740 3020 Desvio Padrão

772 598 840 215 814

Referência (ms) [13] 10000 2000 - 200 2000 ES – Estabelecimento da Sessão

MC – Mudar de Canal AQ – Alteração de Qualidade TP – Tempo para Pausa TS – Terminação da Sessão

Tabela 6.6 – Tempos de execução das funcionalidades

Pela análise da tabela 6.6, verifica-se:

Na LAN os valores são muito próximos, ou mesmo inferiores aos limites definidos pelo

Broadband Forum. Considera-se assim que estes resultados são muito satisfatórios.

Na rede CDMA os valores obtidos são satisfatórios se se considerar a natureza do canal

rádio e o atraso típico da rede, estando próximos dos valores de referência para serviços

IPTV.

74

De uma forma genérica os resultados obtidos são bastante bons. Os valores mais penalizados são o

tempo de estabelecimento de sessão e troca de canal, em especial na rede CDMA, facto que é

explicado pela maior carga computacional necessário para os processos de codificação e

descodificação nos extremos e pelo valor de atraso da rede.

Todos os valores poderiam ser optimizados se o servidor IPTV estivesse localizado na rede do

prestador de serviço, ou seja, no Core da rede CDMA. Salientando-se ainda que não foram utilizados

quaisquer mecanismos de provisão de QoS ao nível da rede (ou seja, diferenciação do tipo de

tráfego), que o sistema IPTV desenvolvido encontra-se em fase de protótipo, e finalmente que o

processo de codificação e descodificação dos conteúdos é efectuado através de ferramentas de

software com desempenho inferior a equipamento hardware dedicado a essa finalidade.

6.3.2.2 - Testes de Adaptação Dinâmica

Este teste tem como objectivo avaliar o comportamento do sistema ao longo do tempo, e a sua

adaptação face à variação das condições na rede. O gráfico da Figura 6.9 ilustra a adaptação do

nível de qualidade de 2 clientes, ao longo da sessão.

Ambos os clientes iniciam a sessão com o valor de qualidade 6 (128 kbps). Observa-se que 120

segundos após o início da sessão, o cliente CDMA efectua um pedido de diminuição para nível de

qualidade 4, que resulta na diminuição do ritmo da stream para 64 kbit/s. Posteriormente, o sistema

reage requisitando um aumento do valor da qualidade, e o ritmo da stream sobe progressivamente

até estabilizar no nível 8.

Figura 6.9 – Adaptação dinâmica do nível de qualidade

O cliente IPTV em ambiente LAN, dado que dispõe de condições de rede mais favoráveis, requisita

progressivamente aumentos do nível de qualidade até atingir o nível 10 (292 kbit/s), nível onde

estabiliza durante toda a sessão.

Destes resultados considera-se que os clientes reagem de facto, adaptando o nível de qualidade ao

longo da sessão através do envio de mensagens SIP UPDATE. Este processo envolve um pedido de

75

alteração no débito das streams, contribuindo para aumentar a QoE, uma vez que do ponto de vista

do utilizador as transições são suaves e não envolvem interrupção da emissão.

6.3.3 - Testes Não-Funcionais

6.3.3.1 - Testes de QoE de Vídeo

Os resultados de classificação das streams de vídeo utilizando o método DSCQS podem ser

observados nas tabelas 6.7 e 6.8, onde se apresenta os resultados para os codecs MPEG4 Visual e

H.264, com transmissão em LAN e na rede CDMA. O valor MOS – Mean Opinion Source –

corresponde à média de classificação atribuída pelos utilizadores.

Norma de compressão

Débito (Kbit/s)

MOS Classif. Mínima

Classif. Máxima

Desvio Padrão

Intervalo de Confiança a 95%

MPEG4 Visual

32 2,44 1,8 3,2 0,478 ]2,143 ; 2,736[ 64 2,58 1,8 3,3 0,514 ]2,261 ; 2,898[ 128 2,95 2,1 3,5 0,414 ]2,693 ; 3,206[ 196 3,38 2,9 3,7 0,253 ]3,223 ; 3,536[ 292 3,93 3,7 4,2 0,149 ]3,837 ; 4,022[

MPEG4 Parte

10 AVC / H.264

32 2,55 2,0 3,1 0,380 ]2,313 ; 2,716[ 64 2,80 2,2 3,4 0,368 ]2,571 ; 3,028[ 128 3,15 2,6 3,6 0,356 ]2,928 ; 3,371[ 196 3,61 3,3 4,0 0,213 ]3,477 ; 3,742[ 292 4,11 3,9 4,5 0,185 ]3,995 ; 4,224[

Tabela 6.7 – Classificação MOS das streams – CDMA´

Norma de compressão

Débito (Kbit/s)

MOS Classif. Mínima

Classif. Máxima

Desvio Padrão

Intervalo de Confiança a 95%

MPEG4 Visual

32 2,47 1,8 3,0 0,416 ]2,211 ; 2,728[ 64 2,63 1,9 3,4 0,501 ]2,319 ; 2,940[ 128 3,04 2,4 3,6 0,406 ]2,788 ; 3,291[ 196 3,48 2,9 3,9 0,278 ]3,307 ; 3,652[ 292 4,02 3,9 4,2 0,139 ]3,933 ; 4,106[

MPEG4 Parte

10 AVC / H.264

32 2,56 2,1 3,0 0,353 ]2,340 ; 2,779[ 64 2,81 2,3 3,3 0,324 ]2,608; 3,011[ 128 3,25 2,6 4,0 0,417 ]2,991; 3,508[ 196 3,68 3,4 4,2 0,214 ]3,546 ; 3,813[ 292 4,16 3,8 4,5 0,222 ]4,022 ; 4,297[

Tabela 6.8 – Classificação MOS das streams – LAN

76

Figura 6.10 – Classificação MOS das streams

Verifica-se pela observação da figura 6.10 que o acesso via LAN oferece uma maior QoE ao nível do

vídeo, para todos os níveis de qualidade.

O indicador MOS sugere que para se obter uma classificação positiva (acima de 3), o débito do vídeo

deverá ser superior a 128 Kbit/s, utilizando a norma MPEG4 Visual. Utilizando o codec H.264

obtiveram-se classificações positiva para valores de débito ligeiramente inferiores, devido à maior

eficiência de compressão desta norma.

Contudo, a utilização do codec MPEG4 Visual produz resultados visuais bastante satisfatórios,

mesmo com elevadas taxas de compressão. Como indicado no capítulo 2, o H.264 é o estado da arte

em termos de codificação e compressão de vídeo, e de facto verificou-se que utilizando este codec os

resultados de qualidade visual são melhores em todas as situações.

Conclui-se que ambas as normas de codificação são adequadas para o tipo de utilização pretendido.

A escolha entre ambas deve ser efectuada em função das características do terminal - memória

RAM, nível de bateria disponível, etc.

6.3.3.2 - Desempenho do Terminal

Os resultados obtidos através do CACTI demonstram uma utilização moderada dos recursos do

sistema por parte do software cliente.

O gráfico da figura 6.11 ilustra a utilização do CPU pelo programa cliente:

0

0,5

1

1,5

2

2,5

3

3,5

4

4,5

5M

OS

CDMA MPEG4 - Visual LAN MPEG4 - Visual CDMA H.264 LAN H.264

128 196 2926432

Kbit/s

77

Figura 6.11 – Utilização do CPU da máquina cliente

Figura 6.12 – Carga média de sistema da máquina cliente

Em termos instantâneos, observou-se um pico de utilização do processador na fase de arranque,

estabilizando progressivamente ao longo da sessão. Conclui-se que a utilização do CPU aumenta

consideravelmente quando se verificam pedidos constantes de alteração do nível de qualidade. Caso

contrário, a utilização é bastante reduzida.

Verificou-se ainda (figura 6.12) uma utilização média do CPU de 12,58% a nível utilizador, e um valor

total médio de 17,07%. Este valor é muito bom, indicando baixo custo em termos da capacidade de

processamento necessária.

78

Figura 6.13 - Utilização de memória RAM da máquina cliente

À semelhança do resultado anterior, o pico de utilização de memória ocorre na fase inicial, como se

pode observar no gráfico da figura 6.13, devido à ocorrência de transições de qualidade na sessão.

Quando a sessão estabiliza, verifica-se uma ocupação de memória aproximadamente constante. A

utilização média foi de 239,44 Megabytes para um valor total de 1GB, na máquina utilizada.

6.4 - Resumo

Os testes de desempenho da rede de acesso CDMA2000 permitiram efectuar a sua caracterização

em termos de débito efectivo no canal descendente, valores de atraso e jitter e taxas de perdas de

pacotes. Estes testes foram muito importantes, pois permitiram ajustar os débitos de codificação para

os níveis de qualidade, dimensionar o buffer de recepção no cliente, e correlacionar os tempos de

execução das funcionalidades (tempo de resposta a comandos de pausa, troca de canal) com o valor

do atraso na rede.

Foram testadas todas as funcionalidades do protótipo, comprovando-se o seu funcionamento

correcto. Os tempos de execução das funcionalidades sugerem um bom desempenho no tempo de

resposta, embora condicionados pelo atraso da rede, podendo sofrer variações consideráveis

consoante a condição de teste.

Em termos de QoE do vídeo, conclui-se ambas as normas MPEG4 Visual e AVC/H.264 são

adequadas à transmissão streaming de conteúdos em tempo-real ou pré-gravados, oferecendo uma

boa qualidade visual com débitos relativamente reduzidos. Foram obtidos valores de MOS acima de 3

para débitos acima dos 128 Kbit/s.

Em termos de desempenho do terminal, os resultados obtidos indicam não ser necessários uma

capacidade de processamento elevada, e que a utilização de memória RAM é moderada. Verificou-se

que o consumo destes recursos aumenta consideravelmente quando o sistema está em fase de

adaptação, mantendo-se a nível mais baixo em regime estabilizado.

79

Capítulo 7 - Conclusões e Trabalho Futuro

7.1 - Conclusões

Esta dissertação enquadrou-se na temática do streaming personalizado de conteúdos áudio e vídeo,

concretamente no serviço IPTV.

Foram estudados os conceitos e tecnologias inerentes ao IPTV, nomeadamente as arquitecturas, os

protocolos de rede, as normas de codificação e compressão dos conteúdos, e os aspectos

relacionados com a QoS e QoE. Foram ainda estudados cenários de integração do IPTV nas

arquitecturas de rede de próxima geração, nomeadamente na arquitectura IMS.

Foi desenvolvida uma arquitectura IPTV cliente-servidor para distribuição de conteúdos Live e VoD, a

diferentes tipos de clientes. A arquitectura desenhada é adequada para redes de acesso

heterogéneas, tendo em conta as características do acesso e do terminal dos clientes.

A sinalização utilizada nesta arquitectura para o estabelecimento e controlo do serviço IPTV baseia-

se exclusivamente na utilização do protocolo SIP, em serviços unicast. Este protocolo foi escolhido

como protocolo de sinalização da arquitectura IMS, e é muito utilizado em aplicações de voz sobre IP.

Numa perspectiva de integração futura em arquitecturas de próxima geração, o SIP pode ser utilizado

como protocolo de sinalização e controlo de diversos serviços IP (Voz, Vídeo, etc), pelo que a

arquitectura IPTV desenvolvida poderá ser integrada numa arquitectura IMS.

De acordo com esta nova arquitectura, foi implementado um protótipo de cliente IPTV com as

seguintes funcionalidades: escolha dos conteúdos a visualizar, funcionalidades de controlo: Play,

Pause e Stop, alteração manual e dinâmica da qualidade subjectiva do conteúdo, e informação em

tempo-real do conteúdo recebido. A adaptação dos conteúdos é efectuada em tempo de visualização

e é conseguida através de pedidos de alteração do débito da stream por parte do cliente. O pedido é

efectuado com base na monitorização do estado e características da rede, o que permite que esta

solução possa escalar para diferentes tipos de redes de acesso.

A avaliação da solução foi efectuada através de testes funcionais e não-funcionais. Os testes

funcionais permitiram testar o correcto funcionamento das funcionalidades do protótipo, em

ambientes de rede distintos: LAN e 3G CDMA. Os testes não-funcionais permitiram analisar a

qualidade do protótipo cliente IPTV em termos da qualidade visual subjectiva, e do desempenho

computacional ao nível do terminal.

Concluiu-se que a utilização do protocolo SIP para o controlo do serviço IPTV em unicast é vantajosa,

pois permite implementar correctamente as funcionalidades de controlo do serviço, e necessita de

menos mensagens de sinalização que o RTSP. Os resultados dos testes funcionais demonstraram

que os tempos de execução das funcionalidades estão dentro dos limites recomendados pelo

BroadBand Forum. Em média, necessita de 3 segundos para arranque do sistema, 2 - 3 segundos

para mudar de canal, 2 segundos para alteração de qualidade, 300 ms para Pausa e 0,5 - 1 segundo

para terminar a sessão.

80

Na arquitectura desenvolvida, a adaptação de qualidade ocorre durante a sessão de forma

transparente para o utilizador (i.e., sem interrupção na emissão), revelando-se fundamental em

situações de mobilidade ou congestionamento na rede. Desta forma, o utilizador deverá ser servido

sempre com o nível de qualidade máximo possível, tendo em conta as características do seu terminal

e do estado da rede, aumentado a QoE.

Em termos de recursos computacionais, observou-se que o terminal cliente necessita em média de

12,5% da capacidade total de processamento, e cerca de 200 MB de memória RAM, sugerindo que a

solução pode escalar facilmente em qualquer tipo de plataforma.

7.2 - Trabalho Futuro

O trabalho desenvolvido pode ser estendido, adicionando-se novas funcionalidades que nesta fase

não foram consideradas essenciais. Nesta linha de pensamento, deixo algumas sugestões para

trabalho futuro, e que são compatíveis com a arquitectura implementada.

A principal funcionalidade a melhorar será a monitorização de QoS na rede por parte do terminal

cliente. Sugere-se a implementação de um sub-módulo do Monitorizador de QoS que analise os

pacotes RTP recebidos, nomeadamente, números de sequência em falta, tipo de tramas de vídeo

transportadas, tramas de vídeo perdidas ou corrompidas, etc. Esta análise permitirá ao monitorizador

de QoS actuar com mais precisão no processo dinâmico de escolha do nível de qualidade mais

adequado ao estado da rede, aumentando a QoE.

O processo de adaptação dos conteúdos baseado na informação que o cliente envia para o servidor

também poderá ser alvo de melhorias, através da utilização de técnicas de adaptação on-the-fly. Esta

adaptação poderia ser efectuada através de um novo elemento dedicado, denominado “Nó de

adaptação”. Este elemento requer elevada capacidade de processamento e deverá ser inserido entre

servidor e cliente, sendo responsável por adaptar o conteúdo individualmente a cada cliente.

Os aspectos relacionados com a segurança são outro ponto a desenvolver. Nesta área, poderia ser

implementado um servidor AAA (Authentication, Authorization and Accounting), que seria responsável

por guardar e gerir todos os perfis e credenciais de autenticação dos clientes. A autenticação do

servidor e dos conteúdos é igualmente importante para o cliente, pois garante que este recebe os

conteúdos pretendidos. Para isso, poderá implementar-se um sistema de cifra de conteúdos, através

da troca de chaves e certificados digitais. Este mecanismo seria igualmente importante para garantir

os direitos de propriedade intelectual dos conteúdos que circulam na rede.

Em termos de sinalização propõe-se a extensão do modelo SIP proposto para distribuição em IP

multicast. A extensão para multicast revela-se mais complexa devido à utilização do protocolo IGMP,

e numa fase inicial poderia passar pela utilização conjunta dos dois protocolos.

Por fim, destaca-se a importância de testar esta solução em terminais com baixo poder de

processamento, como PDA’s e smartphones, em condições estacionárias e de mobilidade, para

comprovar ou melhorar a eficácia da adaptação dinâmica a condições heterogéneas.

81

Referências Bibliográficas

[1] CableLabs, "DOCSIS," CableLabs 2009. Available: www.cablelabs.com. [2] X. Yang, D. Xiaojiang, Z. Jingyuan, H. Fei, and S. Guizani, "Internet Protocol Television

(IPTV): The Killer Application for the Next-Generation Internet," Communications Magazine, IEEE, vol. 45, pp. 126-134, 2007.

[3] TISPAN - Telecoms and Internet converged Services and Protocols for Advanced Networks. [Online]. Available: http://www.etsi.org/tispan/

[4] H. S. J. Rosenberg, "RFC 3261 - SIP: Session Initiation Protocol," IETF 2002. [5] V. J. M. Handley, "RFC 4566 - SDP: Session Description Protocol," IETF 2006. [6] A. Al-Hezmi, C. Riede, O. Friedrich, S. Arbanowski, and T. Magedanz, "Cross-fertilization of

IMS and IPTV services over NGN," in Innovations in NGN: Future Network and Services, 2008. K-INGN 2008. First ITU-T Kaleidoscope Academic Conference, 2008, pp. 153-160.

[7] B. Anne and W. Susan, "Interworking IPTV Services with IMS," in Telecommunications Network Strategy and Planning Symposium, 2006. NETWORKS 2006. 12th International, 2006, pp. 1-5.

[8] M. M. S. Whitehead, X. Marjou, S. Ganesan, and J.Lindiquist., "Evalutation of Session Initiation Protocol (SIP) for use in Streaming Media Applications," IETF 2006.

[9] H. J. Park, J. H. Yang, J. K. Choi, and H. S. Kim, "QoS negotiation for IPTV service using SIP," in Advanced Communication Technology, The 9th International Conference on, 2007, vol. 2, pp. 945-948.

[10] My eDirector 2012 Website. [Online]. Available: http://www.myedirector2012.eu. [11] R. S. Cruz, M. S. Nunes, L. Menezes, and J. Domingues, "SIP Based IPTV Architecture for

Heterogeneous Networks," in The 10th International Conference on Telecommunications, Zagreb, Croatia, 2009.

[12] W. Simpson and H. Greenfield, IPTV and Internet video : new markets in television broadcasting. Amsterdam ; Boston ; Washington, D.C.: Focal Press ; National Association of Broadcasters, 2007.

[13] "Triple-play Services Quality of Experience (QoE) Requirements," Broadband Forum (former DSL Forum), Tech. Rep. TR-126, 2006.

[14] M. Topic, Streaming media demystified. New York: McGraw-Hill, 2002. [15] S. Mack, Streaming media bible. New York, NY: Hungry Minds, 2002. [16] D. Austerberry, The technology of video and audio streaming, 2nd ed. Burlington, MA: Focal

Press, 2004. [17] A. E. Dashti, Streaming media server design. Upper Saddle River, N.J.: Prentice Hall PTR,

2003. [18] R. Tusch, "Design and Implementation of an Adaptative Distributed Multimedia Streaming

Server," MsC thesis, 2004. [19] YouTube. (2008). YouTube Broadcast Yourself. [Online]. Available: www.youtube.com. [20] M. Inc, "IPTV Global Forecast - 2008 to 2012," MRG Inc, 2008. Available:

http://www.mrgco.com/TOC_IPTV_GF0408.html. [21] G. O'Driscoll, Next generation IPTV services and technologies. Hoboken, N.J.: Wiley, 2008. [22] IPTV-FG, "FG IPTV-C-0261 Working Document: IPTV Architecture," ITU-T 2008. [23] B. S. Forum, "IPTV Explained - Part 1 in a BSF Series," BSF. Available:

http://www.broadbandservicesforum.org. [24] A. Cartaxo, "Tecnologias de Fibra Óptica: Que limites e que futuro?," Instituto de

Telecomunicações Pólo de Lisboa 2006. [25] DVB, "DVB - Digital Video Broadcasting Project," DVB 2009. Available: http://www.dvb.org. [26] J. Viinamäki, "IP Over Satellite," Department of Electrical Engineering, Helsinki University of

Technology, Helsinki 2004. [27] W. Forum, "WiMAX End-to-End Network Systems Architecture Stage 2-3," WiMAX Forum

2007. Available: http://www.wimaxforum.org/technology/documents/ [28] M. S. Nunes, "Tecnologias de Acesso DSL," IST 2006. [29] Joost. (2008). Joost. [Online]. Available: http://www.joost.com/. [30] N. Degrande, K. Laevens, D. De Vleeschauwer, and R. Sharpe, "Increasing the user

perceived quality for IPTV services," Communications Magazine, IEEE, vol. 46, pp. 94-100, 2008.

82

[31] K. A. Kooij, K. Brunnstrum, "Perceived Quality of Channel Zapping," Proc. 5th Int. Conf.

Systems and Networks, Palma de Mallorca, Spain 2006. [32] Hewlett-Packard. Using SI Tables to Create Electronic Program Guides. [Online]. Available:

http://www.home.agilent.com/upload/cmc_upload/All/6C06MPEGPAPER1.pdf. [33] J. Watkinson, The MPEG handbook : MPEG-1, MPEG-2, MPEG-4. Oxford [England] ; Boston:

Focal Press, 2001. [34] I. E. G. Richardson, H.264 and MPEG-4 video compression : video coding for next generation

multimedia. Chichester ; Hoboken, NJ: Wiley, 2003. [35] ITU-T, "ITU-R BT.601 Recommendation: Encoding Parameters of Digital Television for

Studios," ITU-T 2007. [36] J. Greengrass, J. Evans, and A. C. Begen, "Not All Packets Are Equal, Part I: Streaming

Video Coding and SLA Requirements," Internet Computing, IEEE, vol. 13, pp. 70-75, 2009. [37] S. C. H. Schulzrinne, "RFC 3550 - RTP: A Transport Protocol for Real-Time Applications,"

IETF 2003. [38] ATI, "Introduction to H.264," ATI 2005. Available:

http://ati.amd.com/products/pdf/h264_whitepaper.pdf. [39] D. Bethlehem, "H.264: The New MPEG Standard," Optibase 2007. [40] M. W. Jay Loomis (2008). VC-1 Technical Overview. [Online]. Available:

http://www.microsoft.com/windows/windowsmedia/howto/articles/vc1techoverview.aspx. [41] Y. Wang, "Video Coding Standards " Multimedia Communication Systems II - Polytechnic

University, Brooklyn, NY11201 2005. [42] PT-Comunicações, "Meo supera 100 mil clientes," Portugal Telecom 2008. Available:

http://www.portugaltelecom.pt/NR/rdonlyres/75779B74-022E-4BB5-B1D5-3286A1CF1C6E/1413476/Meo100k_new_p.pdf.

[43] ANACOM, "Concursos TDT - Caderno de Encargos Multiplexer A," ICP ANACOM 2008. Available: http://www.anacom.pt/template15.jsp?categoryId=268822.

[44] IPTV-Industry. (2007). Anevia Puts Alice In Wonderland With New Video On Demand Service. [Online]. Available: http://www.iptv-industry.com/ar/13e.htm.

[45] A. B. Johnston, SIP : understanding the Session Initiation Protocol, 2nd ed. Boston: Artech House, 2004.

[46] T. Russell, The IP multimedia subsystem (IMS) : session control and other network operations. New York: McGraw-Hill, 2008.

[47] VoipForo. SIP Example: SIP Call flow. [Online]. Available: http://www.en.voipforo.com/SIP/SIP_example.php.

[48] A. R. H. Schulzrinne, "RFC 2326 - Real Time Streaming Protocol (RTSP)," IETF 1998. [49] J. F. Kurose and K. W. Ross, Computer networking : a top-down approach featuring the

Internet, 3rd ed. Boston: Pearson/Addison Wesley, 2005. [50] IETF, "RFC 1889 - RTP: A Transport Protocol for Real-Time Applications," IETF 1996. [51] J. Paananen. Multicast Routing. [Online]. Available: http://www.tml.tkk.fi/Opinnot/Tik-

110.551/1996/mcast.html. [52] D. Waitzman, "RFC 1075 - Distance Vector Multicast Routing Protocol," IETF 1988. [53] D. F. D. Estrin , A. Helmi , D. Thaler , S. Deering , M. Handley , V. Jacobson , C. Liu , P.

Sharma , L. Wei, "RFC2362 - Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification," IETF2008-12-20 1998.

[54] J. Moy, "RFC 1584 - Multicast Extensions to OSPF," IETF 1994. [55] W. Fenner, "RFC 2236 - Internet Group Management Protocol, Version 2," IETF 1997. [56] W. Fenner, "RFC3376 - Internet Group Management Protocol, Version 3," IETF 2002. [57] D. Ramirez, IPTV security : protecting high value digital contents. Chichester, England: John

Wiley, 2008. [58] Q. Zhang, W. Zhu, and Y. Zhang, "End-to-End QoS for Video Delivery Over Wireless

Internet," Proceedings of the IEEE, vol. 93, pp. 123-134, 2005. [59] V. Sarangan and C. Jyh-Cheng, "Comparative study of protocols for dynamic service

negotiation in the next-generation Internet," Communications Magazine, IEEE, vol. 44, pp. 151-156, 2006.

[60] IPTV-FG, "FG IPTV-C-1108 - Traffic management mechanisms for the support of IPTV Services," ITU-T 2007.

[61] A. Takahashi, D. Hands, and V. Barriac, "Standardization activities in the ITU for a QoE assessment of IPTV," Communications Magazine, IEEE, vol. 46, pp. 78-84, 2008.

[62] ITU-T, "Definition of QoE, ITU-T Recommendation P.10/G.100 Appendix I," ITU-T 2007.

83

[63] ITU-R, "Recommendation ITU-R BT.500-11: Methodology for the subjective assessment of the quality of television pictures," ITU-R, 2002.

[64] R. Good. (2005). IPTV vs Internet Television: Key Differences. [Online]. Available: http://www.masternewmedia.org.

[65] Siemens, "SURPASS Home Entertainment," Siemens 2005. [66] Alcatel, "Alcatel IPTV Solution: Beyond First-generation IPTV to simply better TV.," Alcatel

2006. [67] Microsoft. (2008). Windows Media DRM. [Online]. Available:

http://www.microsoft.com/windows/windowsmedia/forpros/drm/default.mspx. [68] Microsoft. (2008). RDP: Remote Desktop Protocol. [Online]. Available:

http://msdn.microsoft.com/en-us/library/aa383015.aspx. [69] K. H. Toon Coppens, Frie Vanparijs, "AlcatelAmigoTV: A Social TV Experience Through

Triple-Play Convergence," Alcatel 2005. [70] IPTV-FG, "FG IPTC-DOC-0093 Working Document: Aspects of IPTV End System - Terminal

Device," ITU-T 2007. [71] O. Friedrich, A. Al-Hezmi, S. Arbanowski, and T. Magedanz, "Next Generation IPTV services

for an extended IMS architecture," in Autonomous Decentralized Systems, 2007. ISADS '07. Eighth International Symposium on, 2007, pp. 429-436.

[72] M. M. S. Whitehead-, X. Marjou, and S. Ganesan, "Media Playback Control Protocol Requirements," IETF 2008.

[73] M. S. Nunes, C. Z. Patrikakis, and N. Papaoulakis, "A Network Oriented Perspective on the Personalization of Media Streaming," in GLOBECOM Workshops, 2008 IEEE, 2008, pp. 1-6.

[74] VideoLAN. (2008). VideoLAN - Free and Open Source software and video streaming solutions for every OS! [Online]. Available: http://www.videolan.org.

[75] Apple. (2009). Darwin Streaming Server. [Online]. Available: http://developer.apple.com/opensource/server/streaming/index.html.

[76] The GNU oSIP library. [Online]. Available: http://www.gnu.org/software/osip/. [77] libVLC Website. [Online]. Available: http://wiki.videolan.org/Libvlc. [78] GTK+ Project. [Online]. Available: http://www.gtk.org/. [79] Glade User Interface Builder. [Online]. Available: http://glade.gnome.org/. [80] WIRESHARK. (2009). Wireshark: Go deep. [Online]. Available: http://www.wireshark.org/. [81] IPerf. (2008). University of Central Florida - IPerf. [Online]. Available:

http://www.noc.ucf.edu/Tools/Iperf/. [82] Trickle. (2008). Trickle - bandwidth shaper. [Online]. Available:

http://monkey.org/~marius/pages/?page=trickle. [83] CACTI. (2008). The Complete RRDTool-based Graphing Solution. [Online]. Available:

http://www.cacti.net.

84

Anexo 1 – Formatos e normas suportados pela libVLC

A lista de normas e formatos suportados pela libVLC pode ser consultada nas tabelas do Anexo 1:

85

Anexo 1 – Normas e formatos suportados pela libVLC

86

Anexo 2 – Exemplo de utilização da libVLC

O código representado no Anexo 2 demonstra a utilização da libVLC:

Anexo 2 - Exemplo de utilização da libvlc em Linux

#include <stdio.h>

#include <stdlib.h>

#include <vlc/libvlc.h>

int main(int argc, char **argv) {

libvlc_exception_t excp;

libvlc_instance_t *inst;

int item;

char *filename = "/tmp/WorldOfPadman_Intro.avi";

libvlc_exception_init (&excp);

inst = libvlc_new (argc, argv, &excp);

quit_on_exception (&excp);

item = libvlc_playlist_add (inst, filename, NULL, &excp);

quit_on_exception (&excp);

libvlc_playlist_play (inst, item, 0, NULL, &excp);

quit_on_exception (&excp);

usleep (10000000);

libvlc_destroy (inst);

return 0;

}

87

Anexo 3 – Captura de Mensagens de Sinalização

O Anexo 3 ilustra um exemplo de captura das mensagens de sinalização SIP do cliente:

INVITE sip:livetv:%2F%2Fjoao@89.181.1.148 SIP/2.0

From: <sip:cliente-iptv@84.39.4.201>

To: <sip:server-iptv@89.181.1.148>

CSeq: 1 INVITE

Content-Type: application/sdp

Content-Length: 427

v=0

o=SIP Server/Proxy 1234567890 1234567890 IN IP4 84.39.4.201

i=SIP IPTV Client session description

c=IN IP4 84.39.4.201

t=0 0

m=application 9 TCP/SIP sip

b=AS:300

a=connection:new

a=setup:active

a=quality:0

a=framerate:23

a=fmtp:media uri=sip:livetv://joao@89.181.1.148

m=audio 1234 RTP/AVP 97

a=recvonly

a=rtcp:0

a=rtpmap:97 mpga/90000

m=video 1234 RTP/AVP 96

a=recvonly

a=rtcp:0

a=rtpmap:98 mp4v/90000

SIP/2.0 100 Trying

From: <sip:cliente-iptv@84.39.4.201>

To: <sip:server-iptv@89.181.1.148>

CSeq: 1 INVITE

Max-Forwards: 70

Content-Length: 0

SIP/2.0 200 OK

From: <sip:cliente-iptv@84.39.4.201>

To: <sip:server-iptv@89.181.1.148>

CSeq: 1 INVITE

Content-Type: application/sdp

Max-Forwards: 70

Content-Length: 368

v=0

o=SIP Server 1234567890 1234567890 IN IP4 192.168.0.10

i=SIP IPTV Client session description

c=IN IP4 192.168.0.10

t=0 0

m=application 1234 TCP/SIP sip

b=AS:300.000

a=connection:new

a=setup:active

a=quality:0

a=framerate:23.00

a=fmtp:media url=livetv://joao

m=audio 1234 RTP/AVP 97

a=recvonly

a=rtcp:0

m=video 1234 RTP/AVP 96

a=recvonly

a=rtcp:0

ACK sip:livetv:%2F%2Fjoao@89.181.1.148 SIP/2.0

From: <sip:cliente-iptv@84.39.4.201>

To: <sip:server-iptv@89.181.1.148>

CSeq: 2 ACK

Content-Length: 0

88

UPDATE sip:livetv:%2F%2Fjoao@89.181.1.148 SIP/2.0

From: <sip:cliente-iptv@84.39.4.201>

To: <sip:server-iptv@89.181.1.148>

CSeq: 3 UPDATE

Content-Type: application/sdp

Content-Length: 427

v=0

o=SIP Server/Proxy 1234567890 1234567890 IN IP4 84.39.4.201

i=SIP IPTV Client session description

c=IN IP4 84.39.4.201

t=0 0

m=application 9 TCP/SIP sip

b=AS:300

a=connection:new

a=setup:active

a=quality:4

a=framerate:23

a=fmtp:media uri=sip:livetv://joao@89.181.1.148

m=audio 1236 RTP/AVP 97

a=recvonly

a=rtcp:0

a=rtpmap:97 mpga/90000

m=video 1236 RTP/AVP 96

a=recvonly

a=rtcp:0

a=rtpmap:98 mp4v/90000

Anexo 3 – Exemplo de Captura de mensagens de sinalização SIP