ArtigoConvergenciadeRedesIPTV_PTN_04_12_2013

256 visualizações

Publicada em

0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
256
No SlideShare
0
A partir de incorporações
0
Número de incorporações
6
Ações
Compartilhamentos
0
Downloads
3
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

ArtigoConvergenciadeRedesIPTV_PTN_04_12_2013

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

×