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
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.

ii
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

iii
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

iv
Í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

v
 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

vi
 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

vii
 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

viii
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

ix
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

x
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

xi
Lista de Acrónimos
3GPP - Third Generation Partnership Project
ARQ - Automatic Repeat Request
ASM - Any Source Multicast
AVC - Advanced Video Coding
BSS - Business Support System
CABAC - Content Based Adaptive Binary Arithmetic Coding
CAVLC - Content Adaptive Variable Length Coding
CDMA - Code Division Multiplex Access
CSCF - Call Session Control Function
DCT - Discrete cosine transform
DRM - Digital Rights Management
DSCP - Differentiated Services Code Points
DSL - Digital Subscriber Line
DSLAM - Digital Subscriber Line Access Multiplexer
DVB - Digital Video Broadcasting
DVMRP - Distance Vector Multicast Routing Protocol
EPG - Electronic Progam Guide
FEC - Forward Error Correction
FTTC - Fiber to the Curb
FTTH - Fiber to the Home
GUI - Graphical User Interface
HDTV - High-Definition Television
HTTP - Hypertext Transport Protocol
IGMP - Internet Group Management Protocol
IMS - IP Multimedia Subsystem
IP - Internet Protocol
IPTV - Internet Protocol Television
ITU - International Telecommunication Union
LAN - Local Area Network
MDF - Media Distribution Functions
MMSH - Microsoft Media Server over HTTP
MOSPF - Multicast Open Shortest Path First Protocol
MPLS - Multi Protocol Label Switching
NACF - Network Access Control Function
NGN - Next Generation Network
OSS - Operational Support System
PC - Personal Computer
PDA - Personal Digital Assistant

xii
PIM - Protocol Independent Multicast
PLC - Power Line Communications
PSNR - Peak signal-to-noise Ratio
PSTN - Public Switch Telephone Network
PVR - Personal Video Recording
QoE - Quality of Experience
QoS - Quality of Service
RACF - Resource Access Control Function
RDP - Remote Desktop Protocol
RF - Radio Frequência
RTCP - Real-Time Control Protocol
RTP - Real-Time Transport Protocol
RTSP - Real-Time Streaming Protocol
RTT - Round-Trip-Time
SCF - Service Control Functions
SDI - Serial Digital Interface
SDP - Session Description Protocol
SDTV - Standard-Definition Television
SIP - Session Initiation Protocol
SMPTE - Society of Motion Picture and Television Engineers
SSM - Single Source Multicast
STB - Set-Top-Box
TISPAN - Telecommunications and Internet converged Services and Protocols for Advanced
Networking
ToS - Type of Service
TTL - Time-to-Live
UPSF - User Profile Server Function
URI - Universal Resource Identifier
VLAN - Virtual Local Area Network
VoD - Video-on-Demand
VoIP - Voice over Internet Protocol
WAN - Wide Area Network

xiii
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:

1
 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-

2
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.

3
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.

4
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].

5
 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.

6
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:

7
 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

8
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.

9
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

10
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-RCS3 [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
4
tradicionalmente utilizada pelo serviço telefónico público (PSTN ) [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.

11
 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 Débito máximo Débito máximo Observações

DSL Downstream Upstream
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:

12
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

13
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].

14
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

15
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

16
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

17
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

5
Windows Media Video 9, normalizada pelo SMPTE [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

18
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].

19
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 Média Média Alta Alta Alta
compressão
Complexidade Baixa - Média Moderada Alta Moderada
Técnicas de - Scalable Coding Switching slices n.d.
Suporte a
Streaming de
Vídeo
Débito médio 4 - 8 Mbit/s 1.5 - 3 Mbit/s 1 - 2 Mbit/s 1 - 2 Mbit/s
para SDTV
Tamanho mínimo 16x8 ou 8x16 8x8 4x4 4x4
dos blocos para
compensação de
movimento
Vectores de A partir de ½ A partir de ¼ píxel A partir de ¼ A partir de ¼
estimação de píxel píxel píxel
movimento
Transformada 8x8 DCT 8x8 DCT 4x4 DCT Inteira 4x4 DCT Inteira
Níveis de 31 31 52 n.d.
Quantização
Tipos de Tramas I, P, B I, P, B I, P, B, SP, SI I, P, B, BI
Filtro de de- Não Não Sim Sim
blocking
Codificação VLC VLC CAVLC / CABAC VLC Adaptativo
Entrópica
Requer Licença Soluções Sim. Existem Soluções Open- Sim
de utilização Open-source Soluções Open- source
source para
alguns perfis

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

20
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

21
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:

CS: OPTIONS rtsp://mcmreal.mediacapital.pt/encoder/itv1.rm

RTSP/1.0
CSeq: 1
User-Agent: VLC media player (LIVE555 Streaming Media
v2007.02.20)
SC: 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
CS: 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)
SC: 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.

22
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]

23
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]

24
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.

25
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:

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

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

26
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-

27
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

28
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:

29
 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 Streaming discreto de
conteúdos 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]

30
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.

31
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.

32
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]

33
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.

34
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

35
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].

36
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:

IPTV Terminal Application Layer

IPTV IPTV IMS IPTV Subscriber

Transaction Protocol
Client Application Application Management

Session
IPTV
Session
/ Session Protocol
IMS User Profile
Control

Streaming Streaming Protocol Streaming for

Client Multicast Protocol Broadcast & VoD
NGN Service Orientated Sub-systems

Customer NGN
NACF Network RACF Resource &
Transport Authentication Protocol
Attachment Function Admission Function IP Control
Sub-Systems

NGN NGN
Network Gateway Access Access Edge Functions Core Core
Transport Transport

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.

37
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.

38
A arquitectura para serviços IPTV unicast baseada em IMS proposta pelo IPTV-FG está representada
na figura 3.3:

SIP SIP
IMS

RACF

RTSP
ABG-FE ABG-FE CoD
UE
server
RTP stream
HTTP SD&S
server

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.

39
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.

40
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.

41
 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.

42
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.

43
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.

44
 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.

45
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:

46
 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.

47
 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.

48
 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

49
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.

50
 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.

51
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.

52
 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,

53
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.

54
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

55
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.

56
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:

57
 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

58
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.

59
 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.

60
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.

61
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 VideoLAN Protótipo

Basic Cliente IPTV
(RTSP) (RTSP) (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

62
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 No. Mensagens Tamanho (KB)

do Cliente 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:

63
 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.

64
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

Captura e Análise do Wireshark Contagem de nºs de sequência
Tráfego na rede [80] em falta ou fora de ordem.
Medição do Atraso Ping / FPing Diversos valores de tamanho de
extremo-a-extremo pacote.
Desempenho da Estimação da largura de IPerf [81] Geração de tráfego UDP
Rede de Acesso banda disponível no servidorcliente com estimativa
CDMA sentido descendente do débito efectivo no sentido
descendente
Cálculo da taxa de perdas FPing / IPerf Estimação da taxa de perdas e
na rede possível impacto na QoE
Medição dos tempos de Protótipo + Conjunto de testes de serviço,
execução das Cronómetro com medição de tempos
funcionalidades (Play, Ubuntu associados às funcionalidades
Pause, etc) básicas.
Funcionais Teste às Funcionalidades Protótipo Verificação do correcto
do programa funcionamento.
Teste à adaptação / Trickle [82] O Trickle permite limitar a
alteração dinâmica da + Protótipo largura de banda a utilizar,
Qualidade simulando congestionamento
na rede.
Medição da QoE Protótipo Análise da QoE utilizando o
Não-Funcionais relativamente à qualidade método DSCQS.
visual do vídeo
Medição do Desempenho CACTI [83] Medição da ocupação em
do programa cliente memória e carga do sistema.
Tabela 6.3 – Testes efectuados e ferramentas utilizadas

65
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)

66
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.

67
 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.

68
 Modo de Payload RTT médio RTT mínimo RTT máximo Desvio Padrão
Ligação (bytes) (ms) (ms) (ms) (ms)
128 309.11 187 3228 132.32
EV-DO 256 394.64 235 2660 116.41
512 516.47 266 2822 130.70
1024 670.03 291 4124 205.65
128 552.10 318 4143 192.47
1xRTT 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

1.2 1.2
1 1
CDF P[X < x]

CDF P[X < x]

0.8
0.8
0.6
0.4 0.6
0.2 0.4
0
0.2
1 225 449 673 897 1121
RTT (ms) 0
0
5
10
15
20
25
30
35
40
Payload 128B Payload 256B
Jitter (ms)
Payload 512B Payload 1024B

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

1.2 1.2
1
1
CDF P[X < x]

CDF P[X < x]

0.8
0.6 0.8
0.4 0.6
0.2
0.4
0
1 300 599 898 1197 1496 1795 0.2
RTT (ms) 0
0

25

50

75

Payload 128B Payload 256B

Payload 512B Payload 1024B Jitter (ms)

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

69
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.

200
Débito (Kbit/s)

150

100

50

0
0 30 60 90 120 150 180 210 240 270 300 330 360 390 420 450 480 510 540 570
Tempo (s)

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:

70
 2
Débito (Mbit/s)
1,5

0,5

0
0 30 60 90 120 150 180 210 240 270 300 330 360 390 420 450 480 510 540
Tempo (s)

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

1000
800
Débito (Kbit/s)

600
400
200
0
0 30 60 90 120 150 180 210 240 270 300 330 360 390 420 450 480 510 540
Tempo (s)

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.

1.2 1.2
1 1
CDF P[X < x]

CDF P[X < x]

0.8 0.8
0.6 0.6
0.4 0.4
0.2 0.2
0 0
0

2
0.5

1.5

2.5
0.25

0.75

1.25

1.75

2.25

60 110 160

Débito (Kbit/s) Débito (Mbit/s)

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

71
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 Pacotes Pacotes Pacotes

(kbit/s) Enviados Perdidos Perdidos (%)
50 2859 0 0.00
1xRTT 100 6532 0 0.00
150 4051 6 0.15
50 3828 8 0.21
EV-DO 100 5103 12 0.24
300 22961 140 0.61
-6
Referência [13] 1800 - 4 pacotes IP/h <= 6.68x10

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.

72
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)

Média 2977 2641 1550 318 672
Mínimo 2220 1890 940 112 280
LAN Máximo 4060 3220 2070 610 1710
Desvio 504 460 410 168 395
Padrão
Média 3749 3790 3381 367 1090
Mínimo 3110 3060 2110 110 410
CDMA Máximo 6010 5240 5080 740 3020
Desvio 772 598 840 215 814
Padrão
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.

73
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

74
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 Débito MOS Classif. Classif. Desvio Intervalo de

compressão (Kbit/s) Mínima Máxima Padrão Confiança a 95%
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[
MPEG4 128 2,95 2,1 3,5 0,414 ]2,693 ; 3,206[
Visual 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[
32 2,55 2,0 3,1 0,380 ]2,313 ; 2,716[
MPEG4 Parte 64 2,80 2,2 3,4 0,368 ]2,571 ; 3,028[
10 AVC / 128 3,15 2,6 3,6 0,356 ]2,928 ; 3,371[
H.264 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 Débito MOS Classif. Classif. Desvio Intervalo de

compressão (Kbit/s) Mínima Máxima Padrão Confiança a 95%
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[
MPEG4 128 3,04 2,4 3,6 0,406 ]2,788 ; 3,291[
Visual 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[
32 2,56 2,1 3,0 0,353 ]2,340 ; 2,779[
MPEG4 Parte 64 2,81 2,3 3,3 0,324 ]2,608; 3,011[
10 AVC / 128 3,25 2,6 4,0 0,417 ]2,991; 3,508[
H.264 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

75
 5

4,5

3,5

3
MOS

2,5

1,5

0,5

0
32 64 128 196 292
Kbit/s
CDMA MPEG4 - Visual LAN MPEG4 - Visual CDMA H.264 LAN H.264

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:

76
 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.

77
 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.

78
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.

79
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.

80
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.

81
 th
[31] K. A. Kooij, K. Brunnstrum, "Perceived Quality of Channel Zapping," Proc. 5 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.

82
[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.

83
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:

84
Anexo 1 – Normas e formatos suportados pela libVLC

85
Anexo 2 – Exemplo de utilização da libVLC
O código representado no Anexo 2 demonstra a utilização da libVLC:

#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;
}

Anexo 2 - Exemplo de utilização da libvlc em Linux

86
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

87
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

88