Banda larga via cable modem - parte 2

Na primeira parte do artigo foram vistos os elementos ativos e passivos de uma rede DOCSIS/HFC, assim como algumas informações relativas ao seu funcionamento. Nesta parte, serão ampliadas as informações sobre os protocolos DOCSIS e PacketCable.

DOCSIS

O protocolo DOCSIS foi criado pela CableLabs - um consórcio de empresas (ou entidade) sem fins lucrativos cujo objetivo é fomentar a pesquisa e o desenvolvimento de tecnologias para redes à cabo, além de auxiliar seus membros a incorporarem estas tecnologias aos seus negócios. Da mesma forma, a versão do DOCSIS para o mercado europeu - o EuroDOCSIS - é de responsabilidade da Cable Europe, entidade com estrutura e fins semelhantes à CableLabs. O motivo para a existência de uma versão específica para o mercado europeu será visto adiante. Além da variante europeia, o Japão também possui uma versão modificada do DOCSIS (novas implementações e atualizações já utilizam a versão 3.0 do DOCSIS oficial).

Atualmente, o protocolo DOCSIS está em sua quarta versão. O histórico das versões e suas características são as seguintes:

1.0 - emitida em 1997, proporciona conectividade básica à Internet para um ou mais dispositivos do cliente, a possibilidade de limitar a taxa de transmissão por cliente, a interoperabilidade entre cable modems de vários fabricantes e recursos de segurança (BPI - Baseline Privacy Interface);

1.1 - emitida em 1999, aprimorou os aspectos de flexibilidade operacional e segurança (BPI+) e introduziu recursos de qualidade de serviço (QoS), possibilitando a definição de garantias para a taxa de transmissão e latência. Com isso, é possível oferecer serviços de voz utilizando o protocolo PacketCable;

2.0 - emitida em 2001, proporciona melhores taxas de transferência e confiabilidade no fluxo de upstream, para serviços simétricos - a taxa de transferência máxima praticável foi elevada para 27 Mbps. Também prevê a possibilidade de utilizar uma extensão ao protocolo para permitir o uso de IPv6;

3.0 - emitida em 2006, é a versão mais atual do protocolo (até a data presente). Proporciona o uso nativo de IPv6, suporte para IPTV e o recurso de channel bonding, que permite agregar vários canais para a transmissão tanto no fluxo de downstream quanto no de upstream. No mínimo quatro canais devem ser suportados pelos dispositivos. O número máximo de canais não é especificado.

Cada nova versão do DOCSIS adiciona recursos sobre a versão anterior, de modo que as mais recentes são compatíveis com as mais antigas. A atualização de versão de uma rede DOCSIS compreende os CMTSs e os cable modems, sendo que o CMTS é quem define a versão máxima utilizada na rede. Além disso, cable modems de diferentes versões podem ser utilizados na rede: o CMTS utiliza a maior versão suportada pelo dispositivo.

Conforme escrito na primeira parte deste artigo, o protocolo DOCSIS proporciona a transmissão de dados sobre uma rede física HFC. Sendo assim, o fator mais relevante para a definição das taxas de transmissão é o meio físico: é ele quem determina a largura de banda a ser utilizada dentro do espectro disponível, assim como os esquemas de modulação necessários para lidar com sua inerente interferência e atenuação.

A resposta em frequência (ou espectro utilizável) de um cabo coaxial é de 5 a 1000 Mhz. Sendo assim, esta é a faixa de frequências que pode ser utilizada no transporte de informações em uma rede HFC. Entretanto, nem todas as redes HFC foram atualizadas para utilizar o máximo de 1000 Mhz - algumas ainda operam com frequência máxima de 750 ou 860 Mhz (o processo de atualização abrange os amplificadores e as placas de RF do CMTS). É importante ter este fato em mente durante a leitura deste artigo: onde for especificada a frequência de 1000 Mhz, pode-se substituir por 750/860 Mhz.

Como a quantidade de informações recebidas por um cliente é muito maior do que a quantidade de informações que ele possa vir a transmitir, é necessário alocar a maior parte deste espectro (5-1000 Mhz) para o fluxo de downstream, reservando apenas uma pequena parte para o fluxo de upstream. A figura 1 mostra a alocação típica de frequências em uma rede DOCSIS.

Figura 1 - alocação de espectro em uma rede DOCSIS

Nota: a expressão "típica" é utilizada neste artigo como sinônimo de "padrão". Aqueles que trabalham com eletrônica, TI ou qualquer outra área técnica/científica sabem que não vivemos em um mundo "ideal": existem inúmeros fatores que podem alterar as variáveis de um determinado "sistema fechado". 

No caso da alocação de espectro, o fim da faixa de upstream e o início da faixa de downstream podem ser alterados por necessidades de mercado ou mesmo da versão do protocolo utilizado. O DOCSIS foi originalmente concebido para a transmissão de canais no padrão americano NTSC (atualmente denominado ATSC), que ocupam uma faixa de 6 Mhz. Entretanto, no mercado europeu, utiliza-se o padrão PAL, que ocupa uma faixa de 8 Mhz por canal. Dessa forma, foi necessário criar uma especificação que atendesse ao mercado europeu, surgindo então o EuroDOCSIS.

Um fato interessante a ser notado é o seguinte: se no Brasil o padrão para transmissão de TV é o PAL, porque as operadoras de TV à cabo utilizam o DOCSIS e não o EuroDOCSIS? Porque a variante brasileira do PAL, o PAL-M, é praticamente igual ao padrão NTSC, ocupando inclusive a mesma faixa de 6 Mhz. Assim, faz mais sentido utilizar o DOCSIS.

No DOCSIS 1.x e 2.0, a faixa de upstream vai de 5 a 42 Mhz, enquanto a faixa downstream vai de 50 a 1000 Mhz. Já no DOCSIS 3.0, a faixa de upstream pode ir de 5 a 85 Mhz e a faixa de downstream de 108 a 1000 Mhz. Em comparação, no EuroDOCSIS a faixa de upstream vai de 5 a 65 Mhz e a faixa de downstream de 80.6 Mhz a 1000 Mhz.

Por utilizar canais de 8 Mhz, o EuroDOCSIS proporciona taxas de transferência mais altas do que o DOCSIS. A figura 2 ilustra a diferença, comparando as versões dos dois protocolos (a versão 3.0 exibe as taxas alcançadas através do uso de 4 e 8 canais agregados). Note que cada célula da tabela possui dois valores: o máximo teórico e o máximo praticável.

Figura 2 - taxas de transmissão máxima no DOCSIS e no EuroDOCSIS

Existe uma diferença entre a taxa de transmissão máxima teórica e a máxima praticável, devido ao overhead causado pelos vários protocolos utilizados na transferência das informações. A codificação Reed-Solomon (para correção de erros), o esquema de modulação Trellis e o protocolo MPEG acrescentam cerca de 14% de overhead. Além disso, os cabeçalhos DOCSIS e Ethernet adicionam um pouco mais de overhead.

Um fato muito importante a ser dito sobre as taxas de transmissão em uma rede DOCSIS (utilizando agregação de canais ou não) é que elas não são dedicadas a cada assinante, mas a cada nó óptico ou área de cobertura: isto significa que a taxa de transmissão é dividida por todos os assinantes atendidos por um determinado nó óptico. O marketing de algumas operadoras (senão todas) sugere que cada usuário poderá usufruir da taxa de transmissão (ou "velocidade") máxima, o que não é verdade. Embora seja tecnicamente possível atribuir a taxa de transferência máxima para apenas um determinado cliente, em prática a ideia não faz o menor sentido, uma vez que a arquitetura da rede HFC é projetada para atender um número "x" de clientes, que rateiam o custo da infra-estrutura (mais sobre este assunto em uma outra parte do artigo).

Como foi visto anteriormente, a versão 3.0 do DOCSIS permite a utilização de 4 ou mais canais agregados para a transferência de dados. Embora a especificação não determine um número máximo de canais que podem ser agregados, existe um limite prático: a figura 1 mostra que além do fluxo de downstream, o meio físico também necessita transportar os canais analógicos e os digitais, além do serviço de VoD (Video on Demand). Como o espectro é limitado, não sobram muitos canais que possam ser agregados para a transmissão de dados. O ideal seria abandonar de vez os canais analógicos, mas muitas operadoras de TV à cabo ainda possuem assinantes com receptores analógicos: no Brasil, muitos clientes da NET ainda possuem os "planos básicos" ou promocionais que oferecem apenas os canais analógicos. A esmagadora maioria das operadoras de TV à cabo dos Estados Unidos oferece todos os canais legalmente possíveis na forma digital, restando apenas os canais locais que devem obrigatoriamente ser mantidos na forma analógica em virtude do "período de transição" entre a TV analógica e a digital (TV aberta, em VHF ou UHF). Lá, a lei determina que as empresas de TV à cabo devem continuar transmitindo os canais locais até Fevereiro de 2012. Após este período (se não for renovado pelos órgãos competentes), os canais analógicos serão completamente removidos da TV à cabo. Mais informações sobre este período de transição podem ser encontradas aqui e aqui.

Cada canal analógico de 6 Mhz liberado pode ser utilizado para transportar de 6 a 10 canais digitais em SD (Standard Definition) ou de 3 a 5 em HD (High Definition), dependendo do algoritmo de compressão utilizado. Com estes dados em mente, pode-se facilmente perceber que 200 canais digitais ocupam menos espectro (ou largura de banda em Mhz) do que 200 canais analógicos. A eliminação completa dos canais analógicos liberaria espectro suficiente para agregar 32 canais (por exemplo) para a transmissão de dados, proporcionando uma taxa de transferência de 32 x 38 Mbps (máxima praticável por canal no DOCSIS 3.0) = 1.2 Gbps. Recentemente a Cisco realizou um teste onde alcançou quase 1.6 Gbps, utilizando seu novo CMTS, que suporta agregar até 72 canais no fluxo de downstream e 60 canais no de upstream.

Além da falta de espectro disponível na rede HFC, outro fator que limita o número de canais que podem ser agregados pelas operadoras é a falta de cable modems que suportem mais de 8 canais agregados (até a presente data). No teste da Cisco, referido acima, foram utilizados protótipos de cable modems que suportam 16 canais agregados no fluxo de downstream e 4 canais no de upstream. Mesmo assim, foram utilizados três destes protótipos para realizar o teste com 48 canais agregados. É tecnologicamente possível produzir cable modems que agreguem 72 canais ou mais, mas o custo é alto. Então, até que esta situação mude, não devem ser esperadas taxas de transmissão maiores que 300 Mbps (8 canais agregados) tão cedo.

No final de 2008, a NET começou a oferecer acessos de 60 Mbps (megabits por segundo) no Rio de Janeiro e em São Paulo, em caráter experimental. Já na metade de 2010, a empresa passou a oferecer formalmente planos de acesso de até 100 Mbps. A oferta destes serviços só foi possível através da utilização do DOCSIS 3.0 tanto nos CMTSs da NET quanto nos novos cable modems fornecidos. Segundo este documento da assessoria de imprensa da NET, os CMTSs são Cisco uBR 10012 e os cable modems são Cisco DPC3000. De acordo com o referido documento, a NET afirma que esta nova infra-estrutura pode oferecer taxas de transmissão de até 300 Mbps. Conforme ilustrado na figura 2, a taxa de transmissão de 300 Mbps (praticável) só pode ser alcançada através da utilização de 8 canais agregados. Entretanto, o modelo de cable modem fornecido pela NET (DPC3000) suporta apenas 4 canais agregados (dowstream e upstream), o que fornece uma taxa de transferência máxima praticável de 152 Mbps (o modelo DPC3010 suporta 8 canais agregados para downstream e 4 canais para upstream). Embora pareça contraditório, este parece ser o procedimento mais sensato, uma vez que não existe a necessidade de oferecer cable modems que suportem 8 canais agregados e forneçam 300 Mbps (e que possuem um custo mais elevado) se o melhor plano de banda larga da empresa proporciona "apenas" 100 Mbps. Conforme a necessidade por novas "velocidades" for surgindo, os equipamentos serão atualizados.

PacketCable

Além do DOCSIS, existe ainda outro protocolo utilizado em uma rede HFC: o PacketCable. Também criado pela CableLabs, seu propósito é habilitar a transmissão baseada em IP de voz e outros serviços multimídia sobre a rede DOCSIS (no mínimo versão 1.1). Assim como o DOCSIS, o PacketCable também possui uma variante europeia - o EuroPacketCable. Entretanto, não existem diferenças técnicas em relação ao PacketCable: trata-se apenas de uma versão adaptada ao protocolo EuroDOCSIS que recebeu uma nomenclatura consistente com o protocolo de base e o mercado.

O PacketCable possui três versões, sendo que a última ainda não foi emitida. Suas características são:

1.0 - estabelece uma arquitetura para fornecimento de serviço residencial de telefonia digital sobre redes DOCSIS;

1.5 - proporciona suporte à fax, modem, entroncamento analógico para PBX e SIP (Session Initiation Protocol);

2.0 - estabelece uma nova arquitetura, que visa proporcionar serviços residenciais e empresariais (pequeno e médio porte) de telefonia digital, incluindo videotelefonia e recursos de mobilidade. Está em processo de homologação.

Existem muitas fontes de informação afirmando que o PacketCable é um serviço de VoIP, como se fosse uma "marca" ou "tipo" de VoIP. Entretanto essa é uma afirmação equivocada, uma vez que o serviço de VoIP é apenas um dos serviços que podem ser oferecidos sobre o protocolo PacketCable. Serviços como suporte à jogos multiplayer, videoconferência e mensagens unificadas podem ser oferecidos no futuro, se houver demanda. É importante entender que todo o tráfego transportado pelo PacketCable é baseado em IP, ou seja: todo serviço multimídia que vier a ser oferecido, será convertido para IP (pelo EMTA) e então transportado pela rede HFC através do PacketCable.

Em se tratando de VoIP, é muito comum pensar em serviços oferecidos através da Internet, por aplicações como Skype, Google Talk e outros. Este estigma de "amadorismo" não reflete a maturidade da tecnologia de voz sobre IP. Empresas como a GVT oferecem serviços de VoIP comercialmente e com qualidade superior aos serviços gratuitos. O serviço de VoIP da GVT, o Vono, utiliza a mesma tecnologia do Skype e do Google Talk, fornecida pela Global IP Solutions (adquirida pelo Google em 2010). A grande diferença entre os dois tipos de serviços é que a GVT consegue controlar o QoS em sua rede. Note-se que para haver controle de QoS, todas as reservas e/ou garantias devem ser proporcionadas de ponta a ponta em uma rede. Se este controle for possível apenas em uma parte da rede, então não podemos chamar de "QoS", já que a "qualidade de serviço" deve ser oferecida em sua totalidade.

O propósito desta segunda parte do artigo não é fornecer informações detalhadas sobre a transmissão de voz sobre IP; entretanto, de forma simplificada será descrito como este processo ocorre. O EMTA possui um CODEC (Coder-Decoder) embutido, para converter a voz em pacotes IP. Um CODEC (de áudio, neste caso) é um dispositivo ou software que converte sinais de áudio analógicos em sinais digitais, comprimindo-os (dependendo do CODEC) para ocuparem menos largura de banda. Depois de codificados, os pacotes são enviados pela rede DOCSIS até o CMTS, que irá direcioná-lo até o destino desejado - um outro EMTA na mesma rede, um telefone do STFC (rede de telefonia convencional) ou mesmo um outro EMTA de outra operadora de TV à cabo. No DOCSIS todos os fluxos de dados são considerados como unidirecionais. Logo, uma conversação telefônica via PacketCable (que opera sobre o DOCSIS) utiliza dois fluxos de dados: o que entra na rede DOCSIS através do EMTA e vai até o CMTS e o que faz o caminho inverso. A figura 3 mostra um diagrama simplificado do percurso pelo qual os fluxos de dados devem transitar (setas vermelha e azul) se a conversação acontecer entre dois clientes de uma mesma operadora.

Figura 3 - percurso dos fluxos de dados na rede DOCSIS

Os fatores de maior importância na definição da qualidade da voz quando transportada sobre IP são os seguintes: perda de pacotes, latência e jitter (variação no intervalo entre os pacotes). Destes fatores, o único sobre o qual o protocolo DOCSIS tem controle direto é a latência. Além da latência, o DOCSIS também pode efetuar reserva de largura de banda (em bits por segundo), a fim de evitar congestionamento de pacotes IP. Estas duas técnicas - reserva de largura de banda e garantia de latência máxima - podem exercer controle sobre os três fatores descritos, de forma a mantê-los em um nível aceitável. Mas quais são os níveis aceitáveis? Segundo testes realizados com CODECs de áudio, um nível de 3% de perda de pacotes proporciona uma qualidade de conversação inferior à da telefonia convencional. Acima de 3% a codificação da voz fica tão degradada que a qualidade da conversação torna-se inaceitável. Alguns CODECs exigem menos de 1% de perda para evitar erros perceptíveis ao ouvido humano. Quanto à latência, o padrão G.114 especificado pelo ITU (International Telecommunication Union) define como sendo, no máximo, 150 ms (milisegundos) de uma ponta à outra (do emissor até o receptor) e em um único sentido. Segundo a Cisco, este padrão do ITU está sob revisão, possivelmente porque o valor de 150 ms é muito alto de acordo com algumas fontes. Em uma rede de telefonia convencional, a latência situa-se em torno de 45 ms. Estima-se então que para a transmissão de voz sobre IP seriam aceitáveis 75 ms, uma vez que acima de 100 ms já há degradação na qualidade da conversação.

A grande complexidade em garantir latência mínima e reservar um percentual de largura de banda para o tráfego de voz via PacketCable, é que a rede de uma operadora de TV à cabo não é composta apenas pela rede física HFC. Conforme ilustrado na figura 3, a rede HFC compõe apenas a rede de acesso da operadora, que por sua vez comunica-se com a rede IP gerenciada, composta por roteadores e demais equipamentos típicos de um backbone IP. O DOCSIS consegue efetuar controle de QoS apenas na parte HFC da rede. Como foi escrito anteriormente, QoS implica garantias e reservas de ponta a ponta; com isso, é necessário haver uma integração entre as duas redes - HFC e IP - de modo a conservar as garantias e reservas por toda a rede da operadora.

Esta integração é realizada pelo CMTS, que realiza um processo de alocação de recursos consideravelmente complexo. Para simplificar este processo, podemos descrevê-lo da seguinte forma: o EMTA solicita a reserva de recursos ao CMTS, que por sua vez verifica a possibilidade de atender à solicitação (a rede pode estar congestionada; pode haver falha em algum equipamento da rede; se o receptor for outro EMTA na mesma rede pode haver falta de energia elétrica em seu segmento; etc). Se for possível, o CMTS alocará os recursos necessários na rede DOCSIS - largura de banda e minislots suficientes para garantir a latência solicitada - e também na rede IP - utilizando protocolos de sinalização para reserva de recursos no backbone. Caso tenha sido possível alocar todos os recursos solicitados, o CMTS efetivamente criou dois fluxos de dados para o EMTA - um fluxo partindo deste até o receptor e outro no caminho inverso; então o CMTS envia uma mensagem ao EMTA informando sobre os dois fluxos criados. Com estas informações, o EMTA envia os pacotes IP através do fluxo de ida e recebe-os através do fluxo de retorno. A partir deste momento, tanto o EMTA quanto o CMTS tem sua responsabilidade em garantir a qualidade de serviço - cada um deles agindo sobre ambos os fluxos de dados. As tarefas de cada um podem ser descritas da seguinte forma:

EMTA:

• Buscar, no CMTS, as políticas de QoS para os pacotes IP que serão enviados (pelo EMTA);
• Aplicar as configurações definidas nestas políticas sobre os pacotes IP;
• Classificar os pacotes IP e direcioná-los ao fluxo correspondente (pode haver mais de um telefone conectado ao EMTA, e com isso o tráfego de cada um deles é direcionado para um fluxo diferente);
• Efetuar traffic shaping e policiamento de acordo com as políticas de QoS;
• Alterar o campo ToS (Type of Service) dos pacotes IP de acordo com as políticas de QoS;
• Manter o estado para os fluxos ativos.

CMTS:

• Fornecer ao EMTA as políticas de QoS necessárias;
• Alocar largura de banda de acordo com as requisições do EMTA e das políticas de QoS;
• Classificar cada pacote recebido da rede DOCSIS e atribuí-lo à um determinado nível de QoS baseado em filtros previamente configurados;
• Policiar (analisar) o campo ToS dos pacotes IP recebidos da rede DOCSIS e definir as configurações no ToS de acordo com as políticas da rede IP;
• Alterar o ToS dos pacotes IP sendo enviados ao EMTA, de acordo com as políticas de QoS;
• Efetuar traffic shaping e policiamento de acordo com as políticas de QoS;
• Direcionar os pacotes enviados ao EMTA utilizando as devidas políticas de QoS ;
• Direcionar os pacotes recebidos do EMTA para a rede IP utilizando as devidas políticas de QoS;
• Manter o estado para os fluxos ativos.

Nota: as operações de traffic shaping e policiamento aqui descritas são as que agem apenas sobre o tráfego de voz. O EMTA e o CMTS podem realizar estas operações (e efetivamente o fazem, por "n" motivos) em todos os pacotes que trafegam por eles, mas este procedimento será explicado em outra parte deste artigo.

É importante ressaltar que o PacketCable é responsável pelo que podemos chamar de "gerência" de QoS apenas: ele define quais são os parâmetros de QoS mas não tem capacidade de alocar os devidos recursos - esta tarefa é de responsabilidade do DOCSIS, que opera nos protocolos de sinalização (camadas mais baixas da rede) e efetivamente aloca os recursos. É por este motivo que o PacketCable necessita, no mínimo, da versão 1.1 do DOCSIS, já que esta versão foi a primeira a implementar mecanismos de QoS.

Com isso conclui-se a segunda parte deste artigo. Espero em breve estar publicando a terceira parte, possivelmente descrevendo os esquemas de modulação utilizados e sua interação com os elementos de rede.

Referências

http://broadbandgear.net/2011/03/tackling-today%E2%80%99s-upstream-challenges/
http://arstechnica.com/business/news/2011/05/docsis-the-unsung-hero-of-high-speed-cable-internet-access.ars/2
http://www.ciscopress.com/articles/article.asp?p=357102
http://www.voip-info.org/wiki/view/QoS
http://bandwidth.com/wiki/articl/What_is_Considered_Acceptable_Latency_for_a_VoIP_Network%3F
http://www.cablelabs.com/specifications/CM-SP-PHYv3.0-I09-101008.pdf
http://www.cablelabs.com/specifications/PKT-SP-DQOS-C01-071129.pdf
http://www.cablelabs.com/packetcable/downloads/NCTA02_VOIP_Services.pdf