1) O documento discute a convergência de redes e serviços para IPTV através de redes de transporte de pacotes (PTN). 2) As redes PTN, baseadas em MPLS-TP, permitem a entrega confiável de serviços triple-play incluindo IPTV. 3) O documento revisa as tecnologias e padrões relacionados à implementação e entrega de serviços IPTV através de redes PTN.

1. Convergência de redes, serviço IPTV com núcleo PTN
Fabricia Nascimento Graça, Orientador Professor Antônio Hamilton Magalhães
IEC Instituto de Educação Continuada - Programa de Pós-Graduação em Sistemas de Telecomunicações
Pontifícia Universidade Católica de Minas Gerais
Av. Dom José Gaspar, 500 • Bairro Coração Eucarístico • Prédio 3 • sala 227
Belo Horizonte • MG • 30535-901 Telefone: (5531) 3319-4444 / (5531) 3269-3259, Brasil
1fgracang@gmail.com
Engenharia Eletrônica e de Telecomunicação - IPUC
Pontifícia Universidade Católica de Minas Gerais
Av. Dom José Gaspar, 500 • Bairro Coração Eucarístico • Prédio 3 • sala 227
Belo Horizonte • MG • 30535-901 Telefone: (5531) 3319-4444 / (5531) 3269-3259, Brasil
2ahmagalhaes@fitec.org.br
Abstract — This article post a view over the trend of convergence
of services and network to an all IP, focussing at IPTV services
among triple play services. Service providers are lying next
generation network architectures to meet up customer
expectation of always on and always available services. This is
happening by introducing technologies such as IP/MPLS-TP,
also named as PTN (Packet Transport Network), in the core, and
aggregation networks. This view study the applicable
implementations of IPTV services been provided through packet
transport networks.
Palavras Chave — Convergência de redes IP, PTN, Packet
Transport network, IPTV, Internet Protocol Television.
I. INTRODUÇÃO
Os serviços e as redes IP (Internet Protocol), estão
convergindo para a oferta de triple-play, (dados em banda
larga, voz e vídeo), para uma base de usuários que cresce
diariamente em todo o mundo, demandando serviços
confiáveis e sempre disponíveis. Os Provedores, e/ou
Operadoras de telecomunicações estão buscando adequar suas
redes de serviços e redes de núcleo para altas bandas, com a
garantia de qualidade de serviços QoS (Quality of Services).
Atualmente o uso de redes de núcleo de última geração do
tipo PTN, baseadas em tecnologia MPLS-TP (Multi-Protocol
Label Switching–Transport Profile) (e.g. [23], [24]), têm sido
a melhor forma de oferecer o triple-play. Pois oferecem
resiliência similar à das redes SDH (Synchronous Digital
Hierarchy) com proteção, em caso de falha física, de 50ms
[1].
As tecnologias que compõem as redes PTN provêm
mecanismos de garantia de qualidade de serviço QoS [39],
que incluem habilidades de reserva de trafego e engenharia de
trafego, no padrão Carrier Class, orientadas à conexão.
Também possui funcionalidades de OAM&P (Operations,
Administration, Maintenance and Provisioning), assim
possibilitando o provimento do triple-play de maneira
escalável. Este artigo foca no estudo das tecnologias
aplicáveis ao provimento dos serviços de IPTV sendo
prestados sobre redes de transporte de pacotes.
II. CONVERGÊNCIA
A convergência de redes e serviços digitalizados esta
misturando os setores, que possuíam distinção histórica, como
comunicações por rádio, comunicações empresariais,
broadcast de vídeo, acesso à Internet, para conjuntos de
serviços transportados por redes de próxima geração ou
tecnologias baseadas em IP.
Mídias anteriormente distintas como voz telefônica,
broadcast de imagens e áudio e aplicações de Internet, estão
convergindo para o mundo IP em interfaces comuns em um
mesmo aparelho do consumidor final.
A Error: Reference source not found apresenta um
esquema de como os serviços eram prestados no passado e
como o são nas redes modernas. No passado cada tipo de
conteúdo era fornecido por um tipo de rede/ tecnologia
diferente e era recebido através de um tipo específico de
terminal de usuário, sem o uso de uma base comum.
Atualmente, qualquer conteúdo como vídeo, rádio, áudio,
dados e a voz telefônica podem ser acessados em um mesmo
equipamento e com base em uma infra estrutura comum, com
funcionalidades agrupadas em camadas [2].
Fig. 1 Convergência de tipos de redes/ tecnologias para camadas de serviços
das redes NGN

2. Hoje é possível acessar a internet pela TV, ouvir rádio no
computador pessoal, assistir a vídeos em dispositivos móveis
como o celular, e acessar todos os conteúdos de um celular
com características semelhantes às de um computador, os
“smartphones”.
Isto é descrito como uma tendência de tecnologia neutra,
onde os tipos de redes não impactam no acesso aos dados. As
redes que transportam os serviços são transparentes para os
usuários. Isto é possível através de funções providas pelas
diferentes camadas das redes de próxima geração NGN (Next
Generation Networks), como pode ser visto na figura 1. A
camada 1 representa as redes físicas de cobre, fibra óptica,
sinais de rádio freqüência, satélite entre outras. A camada 2 é
representada pelas tecnologias de transporte dos dados. A
camada 3 representa as aplicações dos serviços e a camada 4
o conteúdo e apresentação ao usuário.
Esta convergência tem permitido aos Operadores de
telecomunicações a oferecerem os serviços triple-play aos
consumidores a um baixo custo [2].
III. REDES NGN
O conceito de redes NGN é teórico e tem como objetivo
uma visão genérica de redes capazes de prestar todo o tipo de
serviço de vídeo, voz e dados. Os requisitos funcionais e a
arquitetura de redes de próxima geração NGN é detalhada na
Recomendação ITU-T Y.2012 [8].
Seguem algumas transcrições dos pontos mais relevantes
da recomendação para os serviços de IPTV.
A. Características gerais
A arquitetura funcional NGN incorpora os princípios de:
1) Suporte para múltiplas tecnologias de acesso: A
arquitetura funcional NGN foi idealizada para oferecer a
flexibilidade de configuração necessária para suportar várias
tecnologias de acesso.
2) Controle distribuído: Permite adaptação ao processamento
e computação distribuídos de redes baseadas em pacotes.
3) Controle Aberto: O ambiente de controle da rede está
aberto para suportar a criação, atualização e incorporação de
provisionamento lógico, por terceiros.
4) Provisionamento de serviços independente: O processo de
provisionamento é separado da operação da rede de
transporte.
B. A conectividade com a NGN
As funcionalidades que suportam os serviços são separadas
das funcionalidades de transporte. A intenção de tal separação
é para permitir a criação rápida e flexível dos serviços
prestados pela NGN, permitindo conteúdos de vídeo, através
de qualquer rede baseada em transporte de pacotes. As
interfaces entre os serviços e as camadas de transporte se
destinam a serem abertas a qualquer tipo de tecnologia de
redes e aplicativos.
A figura 2 mostra as diferentes conectividades, diretas ou
indiretas (através de uma outra rede), que uma arquitetura
NGN pode suportar.
Fig. 2 Representação dos pontos de conectividade para as redes NGN.
Padronização da norma ITU-T Y.2012 (04/2010)[8]. PSTN (Public Switched
Telephone Network), ISDN (Integrated Services for Digital Network)
Do ponto de vista da IPTV, uma arquitetura aberta tem
vantagens distintas. Os componentes essenciais relacionados
com serviços de IPTV podem ser definidos de forma
independente da tecnologia de acesso de transporte, quer seja
de fibra óptica, cabo, acesso ADSL ou com base sem fios. A
padronização de funções e interfaces de IPTV pode ser
realizada independentemente dos padrões de tecnologia de
acesso que estão sendo desenvolvidos pelos Grupos de Estudo
relevantes e outros fóruns.
1) A UNI (User Network Interface): É utilizada para fornecer
conectividade para: Equipamentos terminais; Redes de
usuários e Redes corporativas. A UNI suporta os controles de
interação de nível e de interação de mídia.
2) O NNI (Network to Network Interface): É utilizado para
fornecer conectividade para outras NGNs, tanto no estrato de
serviço como no estrato de transporte.
3) A ANI (Application Network Interface): É a interface que
fornece um canal para interação e intercâmbio entre
aplicações e elementos NGN. A ANI oferece capacidades e
recursos necessários para o desenvolvimento de aplicações.

3. Transit Network
Firewall
Fig. 3 Redes NGN, exemplos de diferentes domínios. [8]
4) O SNI (service network interface): É uma interface que
fornece um canal para interação e intercâmbio entre a NGN e
outros prestadores de serviços (como um provedor de
conteúdo).
As redes NGN permitem o acesso a uma grande variedade
de serviços. A figura 3 ilustra vários domínios nos quais os
serviços podem ser acessados.
No exemplo da figura 3, o operador NGN A possui uma
tecnologia de rede de acesso que permite conexão a dois
domínios através da sua rede de núcleo.
Os operadores A e B estão interligados através de uma rede
de transito confiável. Em alguns casos, firewalls ou outros
elementos de gateway podem ser utilizados para proteger o
operador da rede NGN da rede de trânsito. A rede do operador
B pode ser outro tipo de rede externa, como um PSTN (Public
Switched Telephone Network).
Um segundo domínio de serviço neste exemplo é a área de
serviços não-SIP do operador A.. Os conteúdos podem ser
fornecidos diretamente por servidores conectados ao núcleo
da rede do operador NGN A, ou podem ser fornecidos por
terceiros através de arranjos de segurança confiáveis.
NOTA - Fluxos (streams) de vídeo podem ser considerados
como um exemplo dos serviços não-SIP. A transmissão de
vídeo pode ser fornecida como um serviço não-SIP ou como
serviços SIP (Session Initiation Protocol).
O segundo domínio de serviço mostrado é o acesso a
serviços baseados na Internet. Estes serviços não fazem parte
do domínio NGN do operador A.. Estes serviços são
acessados pelo operador A através de uma conexão de
transporte para a Internet que necessita utilizar Técnicas de
firewall.
Este exemplo mostra apenas um pequeno conjunto de
configurações que podem ser suportadas pelos operadores
NGN.
Os principais componentes de uma rede NGN são os
dispostos a seguir:
• Rede do cliente (Customer network): A rede do cliente
pode ser uma rede dentro de uma casa ou uma rede
corporativa. Ela é conectada à rede do provedor de
NGN através de uma UNI. A UNI é também o ponto de
demarcação entre o prestador NGN e o usuário.
• Rede de acesso (Access network): A rede de acesso
coleta o tráfego do usuário final desde a rede do usuário
até a rede núcleo. O provedor de acesso à rede é
responsável pela rede de acesso. A rede de acesso pode
ser ainda dividida em diferentes domínios, com a
interface intra domínio sendo denominada como INNI
(Internal Network to Network Interface) e a interface
entre os domínios a ser denominada como NNI. A rede
de acesso pertence à camada de transporte.
• Rede de Núcleo (Core network): A rede principal
pertence tanto ao estrato de transporte quanto a camada
de serviço. O provedor de transporte é responsável pela
rede de núcleo. A interface entre a rede de núcleo e a
rede de acesso ou entre redes de núcleo, pode ser uma
INNI (no caso de partições como um domínio único),
ou uma NNI.
IV. SERVIÇO DE IPTV
Segundo o grupo de trabalho em IPTV da União
Internacional de Telecomunicações (ITUTFG IPTV), pode-se
definir IPTV (ITU-T Y.1901) [3] como:
“IPTV é definido como sendo os serviços de multimídia,
tais como televisão, vídeo, áudio, texto e gráficos,

4. transportados em redes IP dedicadas de um provedor
qualquer, oferecendo garantia de qualidade, segurança,
interatividade e confiabilidade”.
São quatro subdivisões no papel IPTV:
• Content provider - Prestador de conteúdos, que produz
e vende conteúdos;
• Service provider - Prestador de serviço, que adquire os
conteúdos e os disponibilizam aos clientes através da
rede;
• Network provider - Operador da rede, que assegura a
ligação entre clientes e prestadores de serviço;
• Consumer (End User) - Clientes, que são os
consumidores finais dos conteúdos.
Fig. 4 Domínios IPTV [3]
V. PADRONIZAÇÃO IPTV
A. Visão geral da padronização IPTV
Um grande número de organizações têm trabalhado em
especificações para o Serviço de IPTV. O IETF (The Internet
Engineering Task Force), definiu os mecanismos
fundamentais para o suporte aos serviços de IPTV como os
protocolos para o controle do ‘streaming’ de video e os fluxos
de multicast. Estas especificações, por sua vez, foram
utilizadas por outras organizações como o Digital Video
Broadcasting Project (DVB Project), um consórcio de
indústrias com mais de 270 membros, para as especificações
dos Sistemas de IPTV.
Em adição ao uso de mecanismos básicos, definidos pelo
IETF, o DVB Project especificou um protocolo para o serviço
de descoberta e seleção (discovery and selection) dos
conteúdos [4].
C. Padronizações DVB(Digital Video Broadcast)
As especificações DVB são publicadas pelo ETSI.
• ETSI TR 102 033: “DVB; Architectural framework for
the delivery of DVB-services over IP-based networks”,
v1.1.1 publicada em 2002 [5].
• ETSI TS 102 034: “DVB; Transport of MPEG-2 TS
Based DVB Services over IP Based Networks”, v1.3.1
publicada em 2007 [6].
A especificação ETSI TR 102 033 descreve a arquitetura
da estrutura para a entrega do transporte DVB sobre redes
baseadas em IP e inclui descrições dos serviços de IPTV.
A ETSI 102 034 especifica o transporte DVB-2 baseado
em MPEG através de redes IP e define os perfis (profiles) do
protocolo RTSP (Real Time Streaming Protocol) para o LMB
(Live Media Broadcast), o MBwTM (Media Broadcast with
Trick Modes) e o conteúdos sob demanda CoD (e. g. [4],[6]).
• LMB (Live Media Broadcast) - O perfil é caracterizado
como o equivalente da transmissão tradicional ao vivo,
como TV e rádio. Os fluxos de mídia são entregues
apenas no modo multicast. A apresentação é linear e
não há suporte para o modo de operação ´Trick´, como
pausa, avanço e recuo. A apresentação está disponível
como parte de um fluxo contínuo de eventos.
• MBwTM (Media Broadcast with Trick Modes) - O
perfil é caracterizado como o equivalente a transmissão
ao vivo de uma mídia com a adição de suporte para
modo de operação ´Trick´ com possibilidade de pausa,
avanço e recuo. Os fluxos de mídia são entregues
somente no modo unicast. A apresentação é
disponibilizada como parte de um fluxo contínuo de
eventos. A diferença para o perfil CoD é que o usuário
não pode iniciá-lo.
• CoD (Content on Demand) - O Perfil CoD soma ao
perfil MBwTM a capacidade de iniciar o começo do
conteúdo, (e parar), de uma apresentação como um
evento isolado. Isto significa que o perfil suporta pausa,
avanço rápido e outros comandos similares, bem como
a possibilidade de acesso ao conteúdo no momento que
o usuário escolher. Portanto, os fluxos de mídia são
entregues apenas no modo unicast
Algumas das principais diretrizes em ETSI TS 102 034
incluem (e. g. [4], [6]):
• As informações de descoberta e seleção de serviços são
montadas de acordo com o protocolo SD&S (Service
Discovery and Selection), que para os conteúdos de
multicast (push) sejam transportados em pacotes IP de
acordo com o DVB SD&S (Transport Protocol
DVBSTP), os conteúdos unicast (pull) são
transportados via HTTP. Um ponto de entrada SD&S
pode ser implementado utilizando um mecanismo de
DNS (Domain Name System).
• O RTSP (Real Time Streaming Protocol) estabelece e
controla um único ou vários fluxos sincronizados de
mídias contínuas pertencentes a uma apresentação.
Utiliza os protocolos TCP e UDP na porta 554. É usado
para controlar a entrega de transmissões de Broadcast
TV, rádio e de vídeo sob demanda VoD (Video on-
Demand).
• Os serviços de informações e os fluxos (streams) de
áudio e de vídeo são multiplexados em um fluxo de
transporte MPEG-2. Os pacotes resultantes em MPEG2
TS são encapsulados utilizando o protocolo RTP (Real
Time Transport Protocol), com marcações de QoS nos
pacotes de DSCP (differentiated services code point).

5. Fig. 5 Valores DSCP e correspondência com IEEE 802.1D [37] marcas de
prioridade para QoS [6]
• O RTCP (Real Time Transport Control Protocol) é
usado para enviar informações para os receptores sobre
as estatísticas de transmissão, e o IGMP (Internet
Group Management Protocol) para entrar e sair dos
fluxos de multicast.
• O DHCP (Dynamic Host Configuration Protocol) é
usado para configurar dispositivos finais do
cliente/usuário HNED (Home Network End Device)
com um endereço IP na rede doméstica. O sincronismo
é fornecido utilizando relógio de tempo real ou
`serviços de tempo de rede precisas`, que é
implementado utilizando o SNTP (Simple Network
Time Protocol) ou NTP (Network Time Protocol),
respectivamente (e.g. [35], [36]).
D. IPTV e as redes de Próxima Geração NGN
A ETSI TISPAN (Telecommunications and Internet
Converged Services and Protocols for Advanced
Networking), e a ATIS IIF (Alliance for Telecommunications
Industry Solutions IPTV Interoperability Forum), e o
ITUTFG IPTV (ITU-T Focus Group on IPTV), começaram a
trabalhar nas especificações da IPTV, incluindo a integração
da IPTV com arquiteturas de redes NGN. Duas abordagens
para a integração da IPTV com NGN estão sendo estudadas.
Uma é baseada no uso do IMS (IP Multimídia Subsystem), e a
outra abordagem utiliza subsistemas dedicados da IPTV sem
o uso dos procedimentos de controle de sessão do IMS (e.g.
[3] - [6]).
Como pode ser visto na figura 6, as arquiteturas de alto
nível, para IPTV, que estão sendo desenvolvidas no Grupo
Foco do ITU-T em IPTV (Documento de Trabalho FG IPTV-
DOC-0056), possuem abordagens baseadas em IMS e em
não-IMS. Estas abordagens apenas diferem, entre si, em
termos de inclusão das funções de controle de sessão IMS de
núcleo, (centrais na solução de IPTV baseada em IMS). Em
ambas as abordagens o perfil do usuário é comum e as
funções de cobrança (‘Charging’, mecanismos de interação
com sistemas de cobrança, ‘billing’, podem ser vistos com
mais detalhe em [10] e [11], OITF), podem ser utilizadas. As
funções de transporte NGN podem ser usadas, incluindo a
conexão à rede e aos recursos de controle de capacidade de
admissão de vídeo (Video Admission Control) e aplicações
NGN.
Consideraremos umas das arquiteturas da norma ITU-T
Y.1910 [3] que capacita a prestação do serviço IPTV não
baseada em IMS e que utiliza subsistemas dedicados da IPTV.
Fig. 6 Grupo Foco ITU-T em IPTV - Arquitetura convergente,
diagrama de blocos das camadas de software, controle de sessão e de
transporte da rede NGN [4]
VI. MODELO GERAL DO SERVIÇO DE IPTV
Os serviços de IPTV necessitam da integração de diversos
sistemas, como pode ser visto no diagrama de blocos da
figura 7, como o BSS (Business Support System) responsável
pelo negócio como um todo, e o OSS (Operations Support
System) Sistema de Operação e Manutenção, e o controle

6. entre o conteúdo que é recebido no Headend e o dos
servidores de VoD até a rede básica do assinante no ambiente
doméstico (Connected Home). Dentro da casa, há outras
considerações, a fim de permitir a interoperabilidade do STB
com o software de controle (ou middleware) e a integração do
middleware com outros componentes (como o headend,
servidores de VoD, portais Web, guia eletrônico de
programação EPG (Eletronic Program Guide) entre outros)
[4].
Fig. 7 A arquitetura High-Level IPTV [4]
A. Estrutura de Funções
O Serviço de IPTV usa um modelo geral de estrutura de
sistemas de funções, conforme ilustrado na figura 8 (e.g.
[7], [10], [11]), com:
1) Funções de Gerenciamento (Management) – Sistema
composto de capacidades sobre os aspectos de Operação e
Manutenção da rede, e dos terminais; autenticação dos
usuários; segurança dos conteúdos; interfaces e protocolos
para os sistemas de cobrança/faturamento e de
contabilidade; administração dos terminais dos usuários e
dos dados dos consumidores.
1.1) Segurança e autenticação com gerenciamento
de aspectos de Direitos Digitais DRM (Digital
Rights Management). O DRM, em conjunto
com o middleware, é responsável pelo
gerenciamento dos direitos autorais dos
conteúdos. Podem ser utilizados servidores do
Sistema de Acesso condicional ou CAS
(Conditional Access System).
2) Funções de sinalização (Control/ Signaling/) – Funçõe
de controle dos programas de vídeo; Controle dos STBs
acessando os canais disponíveis da programação; serviços
de informação sobre os conteúdos
3) Funções Middleware - Sistemas de middleware, como
EPG (Electronic Program Guide), seleção dos Codecs de
Vídeo e Áudio, API para Interface do DRM System, API para
Controle e funções de sinalização IPTV, e outras interfaces de
usuário.
4) Funções de transporte (Transport) – Faz a interface com
os controles das redes de núcleo MPLS-TP, com roteadores
de nível 3 (L3), e com as redes de acesso, com os switches e
roteadores de nível 2 (L2) que a compõem, admitindo várias
tecnologias desde cabos coaxiais, móveis, Ethernet e ópticas
como a GPON.
5) Funções de controle de recursos (Resource Control) –
Sistemas que controlam e fazem a interface com os
equipamentos do usuário (Home Network), como o STB, PC,
TV e etc; interfaces e softwares para os encapsulamentos,
codificação e decodificação dos conteúdos.
Fig. 8 Modelo de Estrutura dos Sistemas de Funções para IPTV [7]
5.1) Funções de serviço de borda (Quality of Service/
Experience Capabilities) – Sistema que controla
os requerimentos de performance do enlace, com
os requerimentos de banda necessária para os
fluxos de conteúdo
5.2) STB (Set Top Box) ou funcionalidade de gateway
para casa e as interfaces associadas (end user). O
STB IP trabalha com um gateway residencial ou
Management
Functions
AAA;DRM;SLA;Etc.
Control/Signalling
Functions
Access IP
Transport
Wireline
cable
Mobility
Ethernet/
Optico
Resource Control
Functions
Core IP
Transport
MPLS-TP/PTN
UNI
NNI
Middleware
domain
Home
Network
HGW
STB
PC
TV
Etc.
Service
Edge
QoS
PS
Etc.
Video
Content
Functions

7. roteador de banda larga e pode pingar os
servidores middleware para atualizações do
sistema operacional e EPG.
6) Funções de conteúdo de vídeo (Video Content) – Sistemas
que controlam as funções dos codificadores de áudio e vídeo,
MPEG, seleção de conteúdos e entrada e saída dos grupos de
multicast, etc.
Fig. 9 Arquitetura de software do terminal IPTV - Visão geral [9]
B. Arquitetura do Software para o usuário final
As funções de usuário final (end user) estão dentro das
funções do terminal de IPTV, ou STB, cujo software possui a
arquitetura apresentada na figura 9 (e.g. [7], [10], [11]).
1) Camada de abstração de recursos RAL (Resource
abstraction layer).
O Sistema do terminal de middleware IPTV é
independente do tipo de hardware (hardware-agnostic). A
camada RAL existe para cada tipo de hardware e sistema
operacional. Fornecendo a necessária interface para as
camadas mais baixas (por exemplo, memória RAM, acesso à
rede, disco rígido, porta USB, etc.). A interface RAL é
projetada de modo que os drivers de dispositivo possam ser
escritos, independentemente da camada de adaptação lógica
de serviço.
2) Serviço de camada de adaptação lógica (Service
Logic Adaptation)
A camada de adaptação lógica de serviço é feita dos
componentes de serviço. Os componentes de serviços são
componentes nativos puros que oferecem funcionalidades
comuns a todas as implementações de middleware. Por
exemplo, a seleção de serviço e apresentação, gerenciamento
de informações de serviço, PVR (Personal Video Recorder),
sistema de segurança, etc. Eles são usados e enriquecidos
pelas aplicações, a fim de simplificar o desenvolvimento de
componentes e de aplicações que funcionam acima desta
camada.
A definição e o escopo dos serviços dependem das
funcionalidades concretamente implantadas no Sistema IPTV.
No entanto, alguns componentes podem ser definidos como
sendo de natureza genérica:
- Sistema e componente de gestão de recursos.
- Componente de gerenciamento de mídia.
- Componente de Comunicação.
- Componente de Segurança.
- Componente de acesso de metadados.
- Componente de interação do usuário.
Todos estes componentes podem opcionalmente utilizar as
funções disponíveis na rede.
3) Camada de máquina de apresentação (Presentation
engine layer).
A camada de apresentação pode incluir vários motores
(engines), juntamente com um conjunto de serviços de alto
nível. Esta camada é construída na parte superior da camada
de adaptação da lógica de serviço.
4) Experiência do usuário e a camada de aplicação.
As aplicações são residentes ou recebidas por download.
Em particular, uma aplicação é alimentada por um motor de
apresentação (por exemplo, um navegador HTML). Uma
aplicação pode ter acesso completo ou restrito às
características da camada de máquina de apresentação. Além
disso, alguns aplicativos podem acessar diretamente o serviço
de camada de adaptação lógica sem o uso de um motor de
apresentação (presentation engine).
VII. TOPOLOGIA GERAL COM HEADEND MASTER
A. Topologia do Serviço
Usualmente a topologia para o serviço IPTV é constituída
pelos provedores de conteúdo, o provedor do serviço e o
provedor de transporte.
O provedor de transporte pode prover apenas o transporte
de núcleo. No caso das operadoras de telecomunicações, tanto
a rede de núcleo quanto as redes de agregação e as redes de
acesso são da operadora que muitas vezes possui Headend
próprio, ou em alguns casos compra a programação inteira de
um provedor de conteúdo.
O provedor do serviço, operadora, é responsável pela
aquisição dos conteúdos gerais e os obrigatórios de Lei,
(canais locais que devem ser transmitidos e os canais da
União como TV Senado, entre outros), todos os sistemas de
bilhetagem, os sistemas de DRM, CAS (sistema de acesso
condicional), cadastro e atendimento aos clientes.

8. Fig. 10 Topologia de rede com Headends Master e remotos IPTV.
(provisioning), fornecimento dos equipamentos
necessários de ´end-user´, STBs, com o middleware, EPG,
entre outros. No caso do fornecimento do serviço de VoD,
aquisição do conteúdo VoD e da infraestrutura de servidores.
B. Headend
O Headend representa a extremidade principal onde os
serviços de vídeo são formados, onde os conteúdos de vídeo
são adequados para a transmissão pela rede, com conexões
diversas.
O ingresso de programas é feito através de programações
recebidas por satélite por meio de antenas parabólicas das
grandes redes de conteúdo internacional como ESPN, HBO,
Warner, etc. E das redes nacionais como Globo, Record entre
outras. A programação local pode ser recebida por link de
fibra ou por antenas off-air.
A aquisição do conteúdo pelo operador, pode ser feita pela
aquisição do conjunto de canais, como é o caso da HBO
Brasil. A HBO Brasil opera no País por meio dos canais HBO
HD, HBO 2, HBO Plus, Max, Max Prime, Max HD e
Cinemax, entre outros. O provedor de conteúdo usualmente
cobra do operador do serviço um valor mensal por número de
assinantes por pacote de canais. Ou pode optar pela aquisição
de uma grade completa de canais já montada com serviço de
CAS incluído, neste caso, toda a programação é recebida por
uma única antena parabólica e o conteúdo já vem adequado
para a transmissão pela rede de transporte IP.
Os canais são recebidos via satélite codificados em MPEG-
2 ou MPEG-4, por equipamentos decodificadores chamados
IRD (Decodificador Receptor Integrado).
Os canais decodificados, são multiplexados para ser
possível que o operador monte a sua grade de programação e
insira as tabelas e os metadados de controle do conteúdo, os
PIDs (Program ID), de áudio e vídeo, legendas, o EPG e
demais informações de segurança, entre outros. Os canais
locais recebidos de forma analógica necessitam ser
codificados em MPEG, utilizando equipamentos chamados
encoders. Os scramblers são equipamentos de codificação do
sistema de CAS que inserem uma chave de segurança e
criptografam o conteúdo para evitar o roubo de sinal e a
pirataria.
Para utilizar redes de acesso xDSL, o operador necessita
usar os transcodificadores (transrating), para adaptar as taxas
de fluxo (streaming) de vídeo e transformar todo o conteúdo
para o H.264 (MPEG-4 AVC) para conseguir trabalhar com a
mínima banda para o serviço IPTV.
O ´Grooming´ é uma multiplexação estatística que
compacta o conteúdo dos canais dinamicamente observando a
quantidade de movimento nas imagens dos canais.
A codificação H.264 utiliza algoritmos muito avançados
que retiram a maioria das informações dos quadros de

9. imagens dos fluxos de vídeo que após o transporte pela rede,
serão reconstituídos pelos STBs no usuário final.
Fig. 11 O Headend recebe os vídeos dos provedores de conteúdo, processa e
empacota utilizando o protocolo IP, para o envio para a rede de núcleo IP.
No headend, o vídeo processado é transformado em
MPEG-TS (MPEG transport stream) que é encapsulado em
IP, usualmente a saídas dos multiplexers já entrega o
conteúdo em IP. Em muitos fornecedores um único
equipamento executa as funções de multiplex, grooming e
encapsulamento IP. O conteúdo é entregue ao backbone de
rede IP, e distribuído aos usuários.
A localização do headend é uma opção de implementação
da arquitetura, podendo ser centralizado ou distribuído.
Aplicações interativas como DVR IPTV e o VoD são
providos a partir de servidores de conteúdo em formato
MPEG-4 AVC que enviam uma cópia ao usuário, quando
requisitado.
O servidor de vídeo precisa estar dimensionado tanto para
o conteúdo total, que deve armazenar, como também para o
número de usuários ativos que estejam requisitando dados. A
distribuição do serviço IPTV e VoD oferecido pela operadora
faz parte da escolha da arquitetura de rede.
C. Novo Padrão de Codificação H.265
O novo padrão de codificação H.265, irá diminuir
consideravelmente a carga nas redes mundiais, onde, segundo
algumas estimativas, vai reduzir as bandas necessárias para o
transporte do vídeo para menos da metade da largura de banda
que hoje é necessária com o H.264. O novo padrão, conhecido
informalmente como "alta eficiência de codificação de Vídeo"
(HEVC) terá apenas metade da taxa de seu antecessor, o ITU-
T H.264 / MPEG-4 Part 10 AVC (Advanced Video Coding),
que atualmente é responsável por mais de 80 por cento de
todos os vídeos na web. O HEVC irá desencadear uma nova
fase de inovação na produção de vídeo.
O Grupo de Estudo da UIT-T 16 concordou com a
aprovação da primeira fase, (consentimento), deste padrão
muito aguardado e conhecido formalmente como
Recomendação ITU-T H.265 ou ISO/IEC 23008-2. É o
produto da colaboração entre o ITU VCEG (Video Coding
Experts Group) e da ISO / IEC MPEG (Moving Picture
Experts Group) [16].
VIII. SERVIÇO TRIPLE-PLAY
As tecnologias associadas com a entrega do triple-play
evolui continuamente, e os provedores de serviços investem
desde a captação do conteúdo até a entrega nos assinantes,
para conseguir atender às expectativas de qualidade dos
usuários finais, [12].
As redes de transporte de Núcleo e a transição das redes
legadas SONET/SDH estão evoluindo para o conceito de
redes de próxima geração NGN com tecnologia de pacotes IP
[57]. A rede de acesso, incluindo a "última milha", como a
conhecemos hoje, está sendo estendida até a casa e a empresa
do consumidor com uma infinidade de tecnologias de
distribuição e de instalações.
A entrega confiável de serviços triple-play por todo o
percurso das redes até a televisão do consumidor, PC, ou
outros equipamentos (devices), continua a ser essencial.
A rápida adoção e natureza evolutiva do triple-play está
resultando em uma infinidade de cenários para a entrega da
voz, vídeo e pacote de dados para o cliente, conforme
diagrama de blocos apresentado na figura 12. O triple-play
pode ser entregue através de redes de tecnologias de núcleo e
por múltiplos tipos de rede de acesso.
Fig. 12 Os blocos de construção triple-play e os tipos das redes de acesso
[12]
A. Requisitos triple-play
Requisitos de largura de banda (BW) variam com base em
vários fatores. Estes incluem o número de programas
simultâneos para serem entregues ao assinante, o sistema de
compressão usado no serviço de IPTV, MPEG-4 AVC, e o
tipo de programação do conteúdo de vídeo TV, com definição

10. normal SDTV (Standard Video Television) ou de alta
definição HDTV (High definition Television). Estes itens de
configuração impactam diretamente o projeto global de CoS
da rede. Mecanismos utilizados para o transporte do vídeo IP,
tais como a segregação VLAN tag [40], planejamento de
carga, e largura de banda resultante, têm que ser
determinados. Equipamentos de acesso DSLAM (Digital
subscriber line access multiplexer) devem. ser atualizados
para suportar a funcionalidade de IGMP snooping (Internet
Group Management Protocol) [51] e para multicast IP. A
topologia de acesso última milha deve ser planejada para
suportar as larguras de banda necessárias para o vídeo IP do
serviço de IPTV. Tipicamente, o fornecimento de três canais
de vídeo, com difusão simultânea, são requeridos.
Aplicações triple-play baseadas em pacotes utilizam as
camadas física (phisycal), camada de enlace (data link),
camada de rede (network), e camada de aplicação
(application), conforme mostrado na figura 13, que apresenta
os protocolos utilizados numa visão conjunta das camadas do
modelo teórico OSI e as camadas do TCP IP.
Fig. 13 Pilha de protocolos triple-play (e.g. [12], [45]- [51]).
B. Requisitos Carrier Class ou Carrier Grade
Serviços de qualidade Carrier Class são extremamente
confiáveis, bem testados e de comprovada capacidade. As
redes dos provedores de transporte ou operadora são testados
e projetados para atender ou exceder os "cinco noves"
confiabilidade de 99,999%, (menos de 6 minutos de
inatividade por ano), para os níveis de interconexão e de rede,
com padrões de alta disponibilidade e que fornecem a
capacidade de recuperação de falhas muito rápido, através de
redundâncias (normalmente menos de 50 milissegundos) (e.g.
[12], [39]).
Adequações técnicas e operacionais:
• Redes de agregação com suporte a serviços que têm
diferentes características e que possuem diferentes
pesos na rede devido aos tratamentos diferenciados de
CoS.
• A qualidade da experiência do cliente (QoE) e métricas
associadas de QoS são drasticamente diferentes
daquelas descritas para a voz tradicional.
• A Implantação dos serviços ocorre ao longo de uma
infinidade de redes existentes e novas, com topologias e
tecnologias de transporte distintas.
No serviço triple-play, por uma rede de agregação sobre a
qual converge voz, vídeo e dados de banda larga, é necessário
um desempenho “Carrier Grade”. Isto é particularmente
importante quando está relacionado as métricas do transporte
de rede, como a perda de pacotes e o jitter, mantendo ao
mesmo tempo os seguintes atributos:
• Rápida escalabilidade, resiliência e redundância.
• Cinco noves de confiabilidade (99,999%).
• Capacidade para atender aos requisitos chave de SLAs
(Service Level Agreement) da rede: conectividade,
Throughput, Perda de pacotes, Jitter, Packet Delay.
C. Conceito de Classe de Serviço CoS
Da necessidade de fornecer largura de banda suficiente
para o triple-play nas redes convergentes, QoS e
resiliência se tornaram o foco de redes bem construídas de
serviços “Carrier Grade”. Estas redes precisam ser
escaláveis, com adequado custo-benefício, e que tenham a
capacidade de priorizar e processar o tráfego com base na
sua importância para o usuário final. Para conseguir isso
efetivamente, a indústria tem se reunido para desenvolver
mapeamento de classes de serviço CoS para vários
serviços. Usualmente, consistem na marcação de um
determinado tipo de tráfego e na atribuição (tagging) de
uma prioridade a ele, a qual é utilizada por elementos de
rede na tomada de decisões de roteamento (e.g. [12], [39],
[40], [42]).

11. Fig. 14 Estrutura de marcação de CoS para serviços triple-play [12]
É importante notar que decisões de entrega e roteamento de
CoS têm efeitos imensos sobre a qualidade da experiência do
usuário final. Portanto, considerações para priorização de
tagging, e roteamento na rede de agregação e de núcleo,
devem ser bem compreendidas e analisadas [57].
Para fornecer mecanismos adequados de CoS para a rede,
várias métricas precisam ser verificadas por tipo de serviço: a
perda de pacotes, o jitter e o atraso nos pacotes. Cada serviço
tem sensibilidade diferente a estas métricas.
D. Modelos de Priorização de CoS [12]
Existem hoje, uma variedade de mecanismos e tecnologias
de tunelamento que permitem que os provedores possam
escolher as implementações de rede que melhor atendam às
suas necessidades para entregar, com segurança, os serviços
triple-play mantendo o QoS para os mesmos. Estas
tecnologias podem ser agrupadas em duas tendências
emergentes:
1) Extensões nativas do protocolo Ethernet que são
considerações da padronização IEEE:
• Técnicas body-VLAN (referida como 802.1Q / p).
O IEEE 802.1p [39] é uma extensão do IEEE
802.1Q [40], marcação (tagging) de VLANs. Estes
padrões trabalham em conjunto. O padrão 802.1Q
especifica uma marca (tag) que é acrescentada a
um quadro MAC Ethernet. A ‘tag’ de VLAN tem
duas partes: A VLAN ID (12 -bits) e a priorização
(3 bits).O 802.1p define este campo de priorização.
A Especificação IEEE 802.1p [39], permite que
switches de Camada (Layer) 2 realizem a filtragem
de multicast dinâmico para priorizar o tráfego [38].
• Técnicas de Q-in-Q (muitas vezes referida como a
VLAN Stacking ou 802.1ad)
• Técnicas de MAC-in-MAC. MAC (Medium
Access Control - IEEE 802)
Fig. 15 VLAN Tagging e Stacking (e.g. [12], [39]-[42])
2) Encapsulamento por redes MPLS (Multi Protocol
Label Switch), que incluem também o Layer 2 (VPLS)
e versões Layer 3 [20].
Fig. 16 Encapsulamento VPLS (e.g. [12], [20], [40])

12. Estes esquemas inserem tags/campos adicionais nos
quadros (frames) Ethernet dos clientes nos nós de ingresso
(atravessando o nó de borda para o domínio Metro) e tira-os
nos nós de egresso (cruzando o nó de borda para fora do
domínio Metro) antes dos quadros serem entregues ao
apropriado segmento de tráfego dos clientes. Questões como
compatibilidade com versões anteriores, desempenho
comparativo, e complexidade, são elementos chave que
influenciam na escolha de um esquema sobre os outros.
Fig. 17 Encapsulamento MPLS (e.g. [12], [19]-[25], [30])
Algumas redes implementam uma combinação destas
técnicas. Por exemplo, partes da rede básica podem utilizar
tecnologia MPLS-TP baseada em metodologias CoS (onde a
capacidade de recuperação do MPLS, inferior a 50 ms, é
aproveitado para melhorar os tempos de recuperação no caso
de ocorrer uma perda/falha de conexão nesta parte da rede),
que então são convertidos em uma malha VPLS (VPLS mesh)
de elementos (com o foco na melhoria de roteamento e em
lidar com explosões das tabelas MAC). Enquanto isso, na
rede de acesso, VLANs são utilizadas por sua simplicidade e
capacidade de priorizar o tráfego na granularidade adequada
(e.g. [12], [19]-[25], [30]).
E. Métricas de CoS [12]
O diagrama a seguir ilustra como métricas objetivas podem
ser mapeadas para questões subjetivas como o QoE dos
serviços, organizando a métricas em quatro categorias de
qualidade:
• Qualidade de Conteúdo: vídeo payload real.
• Qualidade de Stream de Video: o stream empacotado
flui.
• Qualidade de transporte: pacotes Ethernet IP fluem.
• Qualidade Transacional: a interação entre o usuário e o
serviço.

13. Fig. 18 Mapeamento dos serviços de vídeo IPTV QoS e QoE
(e.g. [12], [39])
Dependendo da arquitetura da rede a distribuição do vídeo
está relacionada com os pacotes IP,
Fig. 19 Estrutura de rede para o serviço triple-play com core IP MPLS-TP
(PTN Packet Transport network) [17]
isto inclui a necessidade de analisar o fluxo dos pacotes
com vários protocolos como o RTP e o TCP sobre IP. As
métricas mais críticas são a perda de pacotes e o jitter dos
pacotes, que têm impacto sobre a pixelização,
quadriculamento, quadro congelado (Freeze Frame), e o QoE
global. Além disso, as características do fluxo de vídeo tais
como a medição de referência do jitter pelo relógio do
programa, PCR (program clock reference) [5], dependendo de
onde for medido, pode ser afetado pelo jitter dos pacotes geral
da rede, que por sua vez podem vir à tona na porção de
agregação da rede.
Métricas residenciais de desempenho de rede, tais como
perda de pacotes, latência e jitter podem ter um impacto
significativo sobre a qualidade do serviço. É importante
considerar como corrigir estes efeitos nos fluxos de vídeo.
Uma opção é com o aumento dos buffers de jitter dos
equipamentos de recepção dos usuários, aumentando a
memória destes, esta ação irá aumentar a latência final do
serviço, assim como o custo dos equipamentos dos assinantes.
Fig. 20 Parâmetros de desempenho de transporte recomendados para redes
que transportam IPTV[12]
Fig. 21 Requerimentos de QoS e bandas necessárias por tipo de serviço e
característica de vídeo [12]
Além disso, se o buffer de jitter é muito pequeno, então a
perda de pacotes pode ser provocada pelo ruído no sistema ou
problemas de capacidade de serviço. Os protocolos de tempo
real (real time), como voz sobre IP (VoIP) ou IPTV não
retransmitem os pacotes perdidos [12].
Fig. 22 Configuração da rede interna da casa do usuário triple-play, coaxial,
par trançado, wireless, e Ethernet [12]

14. IX.CARACTERÍSTICAS BÁSICAS DE REDE IPTV
Na IPTV o encaminhamento dos fluxos de vídeo e áudio
(streams) é feito utilizando o Multicast.
O multicast tem algumas opções principais de
implementação do protocolo, referidas como PIM (Protocol
Independent Multicast):
1) Modo Denso: utiliza o modelo de empurrar (push), o
tráfego inunda toda a rede e é cortado onde não é
necessário. A inundação (flood) e o corte
normalmente ocorrem a cada três minutos.
2) Modo esparso SM (Sparse Mode): utiliza o modelo de
puxar (pull), que envia o tráfego somente mediante
solicitação. Entradas explícitas no grupo multicast são
emitidas pelos clientes para solicitar um fluxo.
3) Modo esparso e denso: combinação dos dois modos
anteriores, que possibilita tanto empurrar (push) e
puxar (pull).
4) Modo Multicast específico de Fonte SSM (Source
Specific Multicast): o SSM requer que os clientes
multicast especifiquem a origem dos dados multicast
explicitamente.
5) Modo Bi-direcional: é usado para implementações em
que todos os clientes multicast são fontes multicast
simultaneamente.
Para distribuir e encaminhar grupos de multicast entre os
roteadores pode ser utilizado o protocolo PIM–SM (Protocol
Independent Multicast-Sparse Mode), o serviço faz uso de IP
e Ethernet multicast através da rede. O Multicast começa
como um único fluxo de vídeo (stream) que é transportado
através da rede para um ponto o mais próximo dos usuários
quanto possível. O fluxo é então duplicado para centenas ou
até milhares de usuários finais que recebem os mesmos dados,
ao mesmo tempo, sem sobrecarregar o servidor de rede ou de
vídeo.
Os nós de comutação na rede IPTV devem suportar o
protocolo IGMP (Internet Group Multicast Protocol) [51], os
equipamentos end-user como o STB (set-top boxes) usam o
IGMP para entrar ou sair dos fluxos de multicast (um fluxo
multicast é equivalente a um canal de TV). Para um
multicasting eficiente, o IGMP precisa ser implementado em
toda a rede de acesso e tão perto quanto possível para os
usuários finais pretendidos. Além disso, para suportar uma
variedade de modos de rede de transporte, cada nó da rede
IPTV deve ter uma implementação de multicast flexível e
escalável. Alguns provedores/operadoras podem escolher um
modelo que suprime os relatórios IGMP ou que utiliza um
proxy IGMP no nó de acesso para poder limitar o número de
relatórios IGMP processados na rede. Outras operadoras
podem escolher um modelo IGMP transparente que permite
que o roteador de borda IP possa ver todos os pedidos IGMP.
O serviço também deve suportar multicast de alta
disponibilidade na camada IP, principalmente da rede de
backbone IP para os roteadores de borda IP. Para gerenciar o
tráfego multicast de camada 3, o roteador de borda IP
emprega os protocolos de multicast PIM-SM (Protocol
Independent Multicast–Sparce Mode) ou PIM-SSM-GR
(Protocol Independent Multicast–Source Specific Multicast–
with graceful restart) [51]. Esta característica certifica que os
fluxos de multicast são entregues ao roteador de borda IP em
tempo hábil e de maneira confiável. (e.g. [14], [39] – [42],
[51]).
Fig. 23 Transporte Multicast IPTV por rede de core PTN [14]
Os roteadores transmitem os serviços de IPTV em forma de
IP nativa e passam pelas redes PTN / SDH.
O Protocolo PIM–SM é implantado em roteadores e pontos
de replicação do multicast nos roteadores/switches ou
DSLAM/OLT que suportam a função de multicast.
X. CARACTERÍSTICAS DAS REDES PTN
As redes de núcleo PTN (MPLS-TP Packet Tranport
Network) são orientadas à conexão, sendo uma tecnologia de
transporte unificado de multi-serviços.
A PTN tem sido aplicada em MANs (Metropolitan Area
Networks) devido aos requisitos de QoS.
A. Padronização PTN
A PTN, MPLS-TP começou como transporte de MPLS no
ITU-T (G.81xx série de recomendações UIT-T), depois
passou a T-MPLS e então foi renomeado para MPLS-TP com
base no acordo que foi alcançado entre o ITU-T e do IETF
para produzir um conjunto convergente de padrões para o
MPLS-TP.
O Grupo de Trabalho Conjunto JWT (Joint Working
Group) concentro-se nas seguintes categorias principais:
• Requisitos gerais.
• OAM.
• Sobrevivência .
• Gerenciamento de rede.
SDH
SR
PON
/
xDSL
L2
Multicast
Source
IPTV
L3L3 PTN L2VPN
PIM-SM/PIM-DMPIM-SM/PIM-DM
L3
IGMP Snooping
PTN

15. Fig. 24 Padronização MPLS-TP (e.g. [19]–[33]).
B. Principais funcionalidades oferecidas pelas redes PTN
• Multiplexação Estatística, de vários tipos diferentes de
tráfegos distintos.
• Agregação de Serviços com qualidade "carrier class".
• Serviço sensível ponto-a-ponto com garantia de QoS
[39].
• Sincronização de fase/sincronização de tempo (e.g. [35],
[36]).
• MPLS orientado a conexão e MPLS-TP,
interoperabilidade e compatibilidade com redes
puramente MPLS [22].
• Gerenciamento de aplicações conscientes (aplication-
aware) com garantia de tráfego para todos os serviços
(e.g. [29], [41], [43], [52]–[54]).
• Distribuição de IPTV por ponto-a-multiponto e
multiponto-a-multiponto.
• IGMP Snooping [51].
• VPLS para a distribuição eficiente de unicast (VOD,
VoIP, AISS) e multicast, IPTV [38].
• VPWS e VPLS – Virtual Private Wire Service e Virtual
Private LAN Service (e.g. [40], [42]) permitindo que
diferentes Sites Remotos possam se comunicar como se
estivessem conectados na mesma LAN possibilitando:
• MPLS Fast Reroute (FRR) ou Proteção MPLS-TP [28].
• Ethernet L2 VPN Ponto-a-Ponto (MEF E-Line)
• Ethernet L2 VPN Multiponto-a-Multiponto (MEF E-
LAN)
• Ethernet L2 VPN Ponto-a-Multiponto (MEF E-Tree)
• OAM – Operation, Administration and Maintenance,
Padrões para gerenciamento baseados no MPLS OAM
como LSP ´Ping´ e LSP ´Traceroute´ dentre outros.
Englobando as seguintes funcionalidades (e.g. [31], [32]):
• Verificação da checagem de continuidade CC-V
(Continuity Check and verification);
• Indicação de defeito remoto RDI (Remote Defect
Indication);
• Sinal de indicação de alarme AIS (Alarm Indication
Signal);
• Indicação de falha no cliente CFI (Client Failure
Indication);
• Medição de perda de pacote PLM (Packet Loss
Measurement);
C. TV broadcast / multicast para os assinantes residenciais
[17]
Para o serviço de VoD, os operadores armazenam e
gerenciam os canais de TV aberta em alguns grandes
servidores de conteúdo nos Headends principais ou em alguns
casos, em servidores menores distribuídos pela rede por
clusters de clientes, dependendo do número de clientes e
quantidade de conteúdo acessado. O fluxo de transmissão de
TV tem de ser entregue a um grande grupo de assinantes
através da rede de agregação metro. Pacotes multicast são
duplicados de acordo com sua participação no grupo multicast
e enviados a cada um dos membros desse grupo.
Protocolos que são usados ao longo das redes são
protocolos IP nativos PIM-SM (Independent Multicast -
sparse Mode) na rede básica, e IGMP no acesso e em redes
metropolitanas. O IGMP é executado nas redes de transporte e
o IGMP proxy é executado nas redes de acesso.
Fig. 25 Trafego VoD na PTN [17]
D. Transmissão de TV Broadcast [17]
A transmissão de TV Broadcast é entregue por multicast
VPLS [38].

16. A premissa de que qualquer canal solicitado é enviado para
todas as portas, pode ser considerada como um padrão, assim
todos os DSLAM podem receber todos os canais possíveis. O
IGMP snooping [51] filtra os canais do multicast e cada
DSLAM recebe os canais ordenados, juntamente com outros
recursos, como:
• Capacidade de suportar milhares de mensagens no
padrão IGMP por segundo.
• Rápido ‘leave and CAC´(Call Admission Control) por
números de fluxos (streams) por porta.
• Reaprendizagem do banco de dados (Database re-
learning), mudança nas tabelas de roteamento, para as
mudanças de topologia ou eventos de proteção.
Nas topologias em anel pode ser usada a característica de
entregar um pacote e continuar (drop-and-continue), que
permite a economia de banda e maior velocidade, ´drop-and-
continue´ é usado para os pacotes multicast, que são passados
por todo o anel, duplicados em cada nó que tem um membro
do grupo multicast. Em seguida são duplicados e enviados em
cada nó para todos os membros de multicast que pertencem a
mesma VPLS.
Fig. 26 IGMP/PIM broadcast de TV na PTN (e.g. [17], [51])
CONCLUSÕES
Este trabalho procurou avaliar alguns aspectos do serviço de
IPTV sendo prestado através de redes NGN de núcleo PTN.
Tanto o serviço de IPTV quanto as tecnologias des redes PTN
ainda estão em processo de normatização e muitas são as
variantes de serviços de vídeo e de níveis de interatividade.
As tecnologias de redes de acesso impõem os maiores
limitadores de desempenho, sendo as redes GPON as que
atualmente oferecem o melhor desempenho para os serviços
triple-play e a IPTV. Mas o tipo de equipamento STB
utilizado no cliente também é muito importante.
As redes de núcleo PTN continuam a evoluir. Muitos
fabricantes já oferecem soluções onde os equipamentos com
capacidades PTN podem ser interligados a redes ópticas
ativas. Futuras pesquisas poderão detalhar outros aspectos e
escopos da prestação do serviço multimídia de IPTV sobre
redes NGN e núcleo PTN.
RECONHECIMENTO
Artigo apresentado ao IEC - Instituto de Educação
Continuada, referente ao curso de Especialização em Sistemas
de Telecomunicações da Pontifícia Universidade Católica de
Minas Gerais, como requisito parcial para obtenção do título
de Especialista em Sistemas de Telecomunicações.
REFERENCIAS
Disponível: ,12 de Novembro, 2013.
[1] (2013) Broadcast and cablesat website [Online]. Disponivel:
http://www.broadcastandcablesat.co.in/extending-iptv-services-
beyond-traditional-t.v.html.
[2] (2013) Competition and Price,.ICT regulation toolkit website [Online].
Disponivel: http://www.ictregulationtoolkit.org/sectionexport/pdf/2
[3] IPTV functional architecture, ITU-T Y.1910, 2008.
[4] (2013) Cisco website [Online]. The Evolving IPTV Service
Architecture, Disponivel:
http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/n
s549/ns746/net_implementation_white_paper0900aecd806530a4.pdf.
[5] Architectural framework for the delivery of DVB-services over IP-
based networks, ETSI TS 102 033 V1.1.1, 2002.
[6] Transport of MPEG-2 TS Based DVB Services over IP Based
Networks, ETSI TS 102 034 V1.4.1, 2009.
[7] ITU-T FG IPTV-ID-0085
[8] Functional requirements and architecture of next generation networks,
ITU-T Y.2012, 2010.
[9] Overview of IPTV terminal devices and end systems, ITU-T H.720,
2008.
[10] (2013) Volume 1 – Overview, OIPF website [Online]. Disponivel:
http://www.oipf.tv/specifications
[11] (2013) Services and Functions for Release 1, OIPF website [Online].
Disponivel: http://www.oipf.tv/specifications.
[12] JDSU, Triple-Play Service Deployment, A Comprehensive Guide to
Test, Measurement, and Service Assurance, JDS Uniphase
Corporation, 2007.
[13] Peter Arberg, Torbjörn Cagenius, Olle V. Tidblad, Mats Ullerstig and
Phil Winterbottom, ”Network infrastructure for IPTV”,2007.
[14] (2013) ZTE Magazine 2010 Issue 03, , ZTE website [Online].
Disponivel:
http://wwwen.zte.com.cn/endata/magazine/ztecommunications/2010Y
ear/no3/#prev
[15] (2013) Faptech website [Online]. Disponivel:
http://faptech.wordpress.com/iptv/hardware-iptv/

17. [16] (2013) H.265 or ISO/IEC 23008-2, ITU website [Online]. Disponivel:
http://www.itu.int/net/pressoffice/press_releases/2013/01.aspx#.UbHP
ydKLB8E
[17] (2013) Orckit website [Online]. PTN solutions, Disponivel:
http://www.orckit.com/ptn_solutions/86.htm
[18] (2013) Cisco website [Online]. Delivering Video Quality in Your
IPTV Deployment, Disponivel:
http://www.cisco.com/en/US/solutions/collateral/ns341/ns524/ns610/n
et_implementation_white_paper0900aecd8057f290.pdf
[19] MPLS architecture, IETF RFC 3031, 2001.
[20] MPLS Label Stack Encoding, IETF RFC 3032, 2001.
[21] Framework for MPLS in Transport Networks, IETF RFC 5921, 2010.
[22] MPLS Transport Profile User-to-Network and Network-to-Network
Interfaces, IETF RFC 6215, 2011.
[23] Terms and definition for MPLS-TP, ITU-T G.8101, 2010.
[24] Architecture of MPLS-TP Layer Network, ITU-T G.8110.1, 2011.
[25] Interfaces for the MPLS-TP Hierarchy, ITU-T G.8112, 2012.
[26] MPLS-TP linear Protection, ITU-T G.8131/Y.1382, 2007, revision
2013.
[27] MPLS-TP Ring Protection, ITU-T G.8132.
[28] RSVP-TE Fast Reroute, RFC 4090.
[29] Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture, RFC
3985.
[30] Encapsulation Methods for Transport of Ethernet over MPLS
Networks, RFC 4448.
[31] Bidirectional Forwarding Detection (BFD), RFC 5880.
[32] Draft MPLS-TP OAM, IETF Y.1731.
[33] Bidirectional Forwarding Detection (BFD) for MPLS Label Switched
Paths (LSPs),RFC 5884.
[34] Time Division Multiplexing over IP (TDMoIP), RFC 5087.
[35] Precision Time Protocol(PTP), IEEE 1588v2.
[36] Synchronous Ethernet,ITU-T G.8261.
[37] Spanning Tree Protoco,l IEEE 802.1D.
[38] Priority and Dynamic Multicast Filtering, IEEE 802.1D,1998.
[39] LAN Layer 2 QoS/CoS Protocol for Traffic Prioritization, IEEE
802.1,p, 2007.
[40] VLAN Tagging, IEEE 802.1Q.
[41] Rapid Reconfiguration (Fast Spanning Tree), IEEE 802.1w.
[42] Vlan classification by protocol e port, IEEE 802.1v.
[43] Dynamic link aggregates, IEEE 802.3ad.
[44] Remote Authentication Dial In User Service (RADIUS), RFC 2138 e
2139.
[45] UDP, RFC 768.
[46] IP, RFC 791.
[47] ICMP, RFC 792.
[48] TCP, RFC 793.
[49] ARP, RFC 826.
[50] Telnet, RFC 854.
[51] IGMP & IGMPv2,RFC 2236.
[52] Path MTU Discovery RFC 1191.
[53] Bridge MIB, RFC 1493.
[54] Classless Inter-Domain Routing (CIDR),RFC 1519.
[55] BOOTP, RFC 1542.
[56] OSPF Database Overflow RFC 1765.
[57] IP router requirements RFC 1812.