Erros de FEC de upstream e SNR como meios para garantir a aualidade de dados e o ritmo de transferência.

Introduction

Para operar uma rede de dados de alta velocidade (HSD) em um plano de cabos de fibra híbrida/coaxial (HFC), exige-se um nível significativo de controle de qualidade garantir que a integridade de dados e o nível mais elevado de throughput de dados. Os dois métodos geralmente aceitos para que o operador de cabos meça a qualidade dos dados são o monitoramento por taxa de erro de bit (BER) ou por taxa de erro de pacote (PER).

O DOCSIS (Data Over Cable Service Interface Specification, Especificação de interface de serviço de cabo) descreve os requisitos que cada operador de cabo deve manter para transportar o tráfego de dados IP de forma confiável. Um recurso importante do DOCSIS trata da necessidade de proteger os dados IP contra danos de ruído de radiofrequência (RF). O recurso que o DOCSIS usa para ajudar a manter a integridade dos dados de IP nas plantas de cabo do HFC é o código Reed-Solomon FEC.

Essencialmente, a codificação FEC protege os dados IP e as mensagens de Gerenciamento DOCSIS contra erros de símbolos causados por ruídos e outros defeitos. O recurso exclusivo do FEC é que ele pode detectar erros de símbolos e corrigi-los. Assim, o DOCSIS especifica que todos os dados IP que são transmitidos por uma planta HFC devem passar por um codificador Reed-Solomon, onde bytes de paridade extra são adicionados aos quadros de dados para garantir que eles sejam  protegidos por erros e menos propensos a defeitos.

Observação: a FEC não funciona muito bem se os erros forem criados por ruído impulsivo, o que cria muitos erros sucessivos. Os erros induzidos por ruído de impulso são tratados no downstream com o uso de intercalação para fazer com que os erros apareçam espalhados, o que a FEC é eficaz na correção. O DOCSIS 2.0 adicionou intercalação upstream, o que ajuda com esse tipo de defeito upstream (US), mas não está disponível em modems a cabo 1.x (CMs).

Sem dúvida, o caminho de retorno da rede de cabo ou upstream é particularmente vulnerável a ruídos e danos relacionados. Esse ruído pode ser impulso, ruído de entrada, ruído térmico, corte de laser e assim por diante. Sem a codificação do FEC, são consideráveis as chances de um pacote ser descartado por erros de bit. Erros de FEC em uma planta de cabos não são a única medida de qualidade. Há outras variáveis que devem ser consideradas, como a razão portadora-ruído (CNR).

O padrão DOCSIS inclui parâmetros recomendados para desempenho de cabo TV RF downstream e upstream. Especificamente, a seção 2.3.2 da especificação de RFI (radio frequency interferência de radiofrequência), Assumidas Características de Transmissão do Canal RF Upstream, € afirma o seguinte:

Portadora-interferência mais ingresso (soma de ruído, distorção, distorção de caminho comum e modulação cruzada e soma de sinais de ingresso discretos e de banda larga, ruído impulsivo excluído) razão [não será] menor que 25 dB.

Em outras palavras, o mínimo recomendado de DOCSIS para CNR dos EUA é 25 dB. Para os fins deste documento, o CNR é definido como a relação entre portadora e ruído antes de alcançar o chip demodulador (domínio RF), conforme medido por um analisador de espectro. Por outro lado, o SNR é definido como a relação sinal-ruído do chip receptor US do CMTS (cable modem Termination System) depois que a portadora é demodulada para fornecer uma taxa de banda base pura, sinal-ruído.

Portanto, ao examinar a leitura de SNR em um Cisco uBR7246 e encontrar um número como 30 dB, é fácil inferior que o upstream parece atingir ou mesmo exceder o DOCSIS e que está tudo certo no universo de RF. Entretanto, esse nem sempre é o caso. O DOCSIS não especifica SNR, e a estimativa SNR do CMTS não é a mesma coisa que o CNR que se mede com um analisador de espectro.

Este documento discute o cálculo estimado de SNR upstream do uBR e também os contadores de FEC do uBR e mostra por que essas duas variáveis devem ser constantemente avaliadas para garantir a qualidade de HSD em ambientes HFC.

Taxa sinal para ruído.

A estimativa de SNR da uBR pode, às vezes, ser enganadora e deve ser considerada apenas um ponto de partida quando se trata de verificar a integridade do espectro de RF upstream. A leitura de SNR na placa de linha uBR MC16C é fornecida pelo chip dos EUA, mas a leitura não é necessariamente um indicador confiável de € "real" de defeitos de RF, como ruído de tipo impulsivo, entrada discreta e assim por diante. Isso não quer dizer que a leitura do US SNR não esteja precisa. Em ambientes com poucas deficiências no upstream (por exemplo, ruído de impulso, ingresso, distorção de caminho comum, etc.), a estimativa de SNR dos EUA rastreia numericamente o CNR em menos de dois decibéis, quando o CNR está no intervalo de 15 a 25 dB. É exata com o aditivo ruído gaussiano branco (AWGN) como única deficiência; no mundo real, no entanto, a precisão desses números pode variar. Isso depende da natureza dos defeitos e reflete melhor a taxa de erro de modulação (MER) em vez do CNR.

Como obter leituras de SNR e CNR

Esta seção mostra alguns exemplos de como obter a estimativa SNR upstream do Cisco uBR7200 e uBR10K (consulte também o Apêndice). Todos os comandos e saídas de comandos da interface de linha de comando (CLI) são extraídos do Cisco IOS® Software Release 12.2(15)BC2a, a menos que especificado de outra forma.

Observe que uma "placa S" € refere-se a uma placa de linha de cabo com recursos integrados de análise de espectro de hardware, enquanto uma "placa C" € refere-se a uma placa de linha de cabo sem esse recurso. Em algumas configurações, a placa S informa o CNR em vez do SNR, porque ele possui hardware embutido para executar funções de análise de espectro.

Dica: ao coletar a saída dos comandos CLI do software Cisco IOS para fins de solução de problemas ou para encaminhar para o Suporte Técnico da Cisco, lembre-se de ativar o timestamp do prompt exec terminal, de modo que cada linha da saída do comando CLI seja acompanhada por um timestamp e pela carga atual da CPU no CMTS.

Para placas S:

ubr7246# show controller cable6/0 upstream 0

Load for five secs: 5%/1%; one minute: 5%; five minutes: 5%
Time source is NTP, 00:17:13.552 UTC Sat Feb 7 2004
 Cable6/0 Upstream 0 is up
  Frequency 21.810 MHz, Channel Width 3.2 MHz, 16-QAM Symbol Rate 2.560 Msps
  This upstream is mapped to physical port 0
  Spectrum Group 1, Last Frequency Hop Data Error: NO(0)
  MC28U CNR measurement - 38 dB

Para placas C ou placas S sem grupos de espectro atribuídos:

ubr7246vxr# show controller cable3/0 upstream 0

Load for five secs: 10%/1%; one minute: 7%; five minutes: 5%
Time source is NTP, 00:17:13.552 UTC Sat Feb 7 2004
 Cable3/0 Upstream 0 is up
  Frequency 25.392 MHz, Channel Width 3.200 MHz, QPSK Symbol Rate 2.560 Msps
  Spectrum Group is overridden
  BroadCom SNR_estimate for good packets - 26.8480 dB
  Nominal Input Power Level 0 dBmV, Tx Timing Offset 2035

Recomenda-se que você mantenha o nível de US definido como padrão de 0 dBmV e use atenuadores externos para forçar os modems a transmitir em níveis mais altos, se necessário.

ubr7246# show cable modem phy

MAC Address    I/F     Sid USPwr  USSNR  Timing MicrReflec DSPwr DSSNR Mode
                          (dBmV)  (dB)   Offset (dBc)     (dBmV) (dB)
0002.8a8c.6462 C6/0/U0  9  46.07  35.42  2063   31        -1.05  39.05  tdma
000b.06a0.7116 C6/0/U0  10 48.07  36.12  2037   46         0.05  41.00  atdma

Dica: o comando phy pode ser usado para relatar SNR mesmo que CNR seja relatado no comando show controllers. Isso é especialmente útil porque o SNR é relatado depois que o cancelamento de ingresso é realizado e o CNR é relatado antes do cancelamento de ingresso.

Observação: o SNR está listado por modem no código EC com show cable modem detail.

O comando phy também lista outros atributos da camada física se remote-query estiver configurado. Essas três linhas de códigos podem ser inseridas para ativar uma consulta remota:

snmp-server manager
snmp-server community public ro
cable modem remote-query 3 public

Três segundos foram utilizados para uma resposta rápida o que não é recomendado em um CMTS muito carregado. A série de comunidade de somente-leitura padrão na maioria dos modems é pública.

Observação: desconsidere a entrada de microreflexão, pois ela é para DS e é limitada pela precisão da implementação do fornecedor do CM.

ubr7246# show cable modem 000b.06a0.7116 cnr

MAC Address    IP Address      I/F      MAC     Prim  snr/cnr
                                        State   Sid   (dB)
000b.06a0.7116 10.200.100.158  C6/0/U0  online  10     38

Esse comando lista os SNR quando for usar uma placa C. Quando uma placa S for usada e grupos de espectros forem atribuídos, o CNR será reportado. O comando show cable modem mac-address verbose também funciona.

Como visualizar o piso do ruído

As placas S também permitem exibir o ruído de fundo com este comando:

ubr7246-2# show controller cable6/0 upstream 0 spectrum ?

  <5-55>              start frequency in MHz
  <5000-55000>        start frequency in KHz
  <5000000-55000000>  start frequency in Hz
  A.B.C.D             IP address of the modem
  H.H.H               MAC address of the modem

Adicionar o endereço IP ou MAC do modem ao comando mostra a potência de intermitência do modem e a largura do canal.

ubr7246-2# show controller cable6/0 upstream 0 spectrum 5 55 ?

  <1-50>  resolution frequency in MHz

ubr7246-2# show controller cable6/0 upstream 0 spectrum 5 55 3

Spect DATA(@0x61359914) for u0: 5000-55000KHz(resolution 3000KHz, sid 0:
Freq(KHz) dBmV Chart
5000 :    -60
8000 :    -23  ****************
11000:    -45  *****
14000:    -46  *****
17000:    -55
20000:    -60
23000:    -60
26000:    -55
29000:    -18  *******************
32000:    -60
35000:    -60
38000:    -60
41000:    -55
44000:    -45  *****
47000:    -60
50000:    -60
53000:    -41  *******

Essa saída mostra o ruído sob a portadora e em outras frequências.

Além da CLI, ferramentas de gerenciamento de rede baseadas em SNMP, como o Cisco Broadband Troubleshooter (CBT), podem ser usadas para exibir o espectro dos EUA e outros atributos. Além disso, o CiscoWorks pode ser usado para monitorar o SNR conforme relatado por placas de linha de cabo usando o objeto docsiIfSigQSignalNoise:

DOCS-IF-MIB
docsIfSigQSignalNoise	.1.3.6.1.2.1.10.127.1.1.4.1.5
	Signal/Noise ratio as perceived for this channel.
 	At the CM, describes the Signal/Noise of the downstream
 	channel.  At the CMTS, describes the average Signal/Noise
 	of the upstream channel.

Observação: as leituras de SNR CM individuais estão disponíveis somente nas placas de linha MC5x20S e MC28U. Essas novas placas de linha incorporam o cancelamento de ingresso que pode melhorar o desempenho, mas pode oferecer leituras de SNR enganosas. As leituras do SNR são feitas após o cancelamento de ingresso; assim, se o cancelamento de ingresso remove matematicamente a entrada, o SNR poderia relatar muito melhor do que a taxa real de portadora-interferência.

Observação: ao usar grupos de espectro em uma placa S, o comando show controllers seleciona aleatoriamente as leituras de CNR de todos os CMs naquele US, o que pode ser ligeiramente diferente, dando a aparência de uma porta instável US ou CNR.

Portadores upstream em Zero-Span

Um modo que vale a pena usar em um analisador de espectro é o modo de span zero. Este é o modo de domínio de tempo, onde a exibição é amplitude versus tempo, em vez de amplitude versus freqüência. Esse modo é bastante útil ao exibir o tráfego de dados que é intermitente por natureza. A Figura 1 mostra um analisador de espectro em intervalo zero (domínio de tempo) ao examinar o tráfego upstream de um CM.

Figura 1: Tela de zero alcance em um analisador de espectro

Os pacotes de dados podem ser vistos na Figura 1, juntamente com solicitações de modem e ruído de impulso. Isso é muito útil para medir os níveis digitais médios e observar o ruído e a entrada, como visto na Figura 2.

Figura 2: Medição de alcance zero da amplitude da portadora digitalmente modulada upstream

Zero-span também pode ser usado para ver se os pacotes estão colidindo entre si devido a temporização incorreta ou divisor de headend ruim ou isolamento do combinador. Um pacote destinado a uma porta de upstream CMTS está "vazando" €  em outro upstream. Consulte as documentações e documentos relacionados na seção Informações relacionadas deste documento. Consulte Connecting the Cisco uBR7200 Series Router to the Cable Headend (&Conectando o roteador da série Cisco uBR7200 à extremidade do cabo) para obter uma descrição do procedimento de medição de span zero.

Praticamente todas as desvantagens de RF mencionadas até agora neste documento podem prejudicar o desempenho de upstream e se manifestam como baixa transferência de dados sem necessariamente serem refletidas como baixa SNR. A observação de erros incorrigíveis de FEC (análogos a BER e PER defeituosos)—mesmo que o SNR pareça estar acima do padrão DOCSIS mínimo—poderia apontar para outros problemas transitórios que precisam ser abordados. Também poderia haver um CM invasor causando erros e uma leitura SNR fraca para todos os outros CMs no mesmo US. Nesse caso, o CNR medido em um analisador de espectro pareceria bem, mas o CMTS reportaria de outra forma.

Encaminhar correção de erro

Lembre-se de que a codificação FEC Reed-Solomon é usada para adicionar bytes de paridade redundantes aos pacotes de dados, a fim de permitir a detecção e correção de erros de rajada introduzidos pela central de cabos.

Em um mundo ideal, erros de bit mensuráveis—ou corrigíveis ou incorrigíveis erros FEC—raramente devem ocorrer. Entretanto, quando existem erros incorrigíveis de FEC, os efeitos podem ser graves e causados por qualquer número de fatores diferentes. Essa é uma lista de eventos conhecidos que poderiam apresentar erros de FEC incorrigíveis no upstream e que devem ser levados em consideração durante o processo de Troubleshooting com erros FEC:

• interferência de transmissor de varredura

• sobrecarga do amplificador (compactação, que é uma forma de recorte)

• clipping de laser

• ruído impulsivo ou interferência de entrada

• conexões soltas ou intermitentes

• isolamento incorreto do combinador ou separador de saída upstream

• modems defeituosos

Há dois métodos com os quais se pode coletar informações de FEC:

• CLI

• Eleição do identificador de objetos (OID) de SNMP

Este é um exemplo de como coletar informações FEC, utilizando o CLI (consulte também o Apêndice):

ubr7246vxr# show controller cable3/0

Load for five secs: 5%/1%; one minute: 5%; five minutes: 5%
Time source is NTP, 00:17:13.552 UTC Sat Feb 7 2004
Interface Cable3/0
Hardware is MC16C

!--- Output suppressed.

 Slots 937882 NoUWCollNoEngy 82 FECorHCS 4 HCS 4
 Req 1160824263 ReqColl 350 ReqNoise 96 ReqNoEnergy 1160264889
 ReqData 0 ReqDataColl 0 ReqDataNoise 0 ReqDataNoEnergy 0
 Rng 609652 RngColl 0 RngNoise 76
 FECBlks 1638751 UnCorFECBlks 7 CorFECBlks 4
     

• FECBlks —O número total de blocos FEC (bons e ruins) recebidos por todas as portas upstream associadas a um dado downstream.

• UnCorFECBlks —O número total de blocos FEC recebidos por todas as portas upstream associadas a um dado downstream que foram tão corrompidos por ruído ou ingresso que não puderam ser corrigidos ou recuperados pelo algoritmo FEC.

• CorFECBlks —O número total de blocos FEC recebidos por todas as portas upstream associadas a um dado downstream que foram ligeiramente corrompidos por ruído ou ingresso e que podem ser corrigidos e recuperados pelo algoritmo FEC.

As rajadas de manutenção de estações aumentam o contador FECBlks em aproximadamente 2 por x segundos, onde x é o intervalo mínimo de polling (conforme exibido no comando show cable hop) dividido por 1000. A consulta remota também incrementa esse contador, assim como a manutenção inicial quando os modems ficam on-line. Como a manutenção inicial ocorre durante o tempo de contenção, pode haver colisões e subsequentes erros incorrigíveis de FEC.

Dica: certifique-se de que os modems não estejam variando ou entrando on-line antes de supor que os EUA estão instáveis apenas porque os contadores FEC incorrigíveis estão aumentando. Além disso, o valor NoCollNoEngy pode aumentar se houver modems com problemas de temporização. Unique Word (Palavra Exclusiva) é recurso específico para BRCM, e não para DOCSIS, e representa os últimos poucos bytes do preâmbulo.

Uma percentagem pode ser estimada utilizando UnCorrFECBlks / FECBlks × 100. O contador FECBlks é o total de blocos FEC enviados, sejam bons ou ruins. Esta saída é para o domínio MAC completo (todos os USs). É melhor observar os contadores entre um período de tempo definido para ver o delta.

Nota: Uma desvantagem da recolha de informação FEC utilizando o CLI é que os UnCorFECBlks, CorFECBlks, e o total FECBlks não são separados por upstream.

Para examinar as informações de FEC por upstream, você deve usar OIDs SNMP. Também é possível utilizar o comando show cable hop para exibir os erros FEC por porta upstream, que podem ou não ser corrigidos, mas não o total de blocos FEC.

ubr7246# show cable hop

Load for five secs: 5%/1%; one minute: 5%; five minutes: 5%
Time source is NTP, 00:17:13.552 UTC Sat Feb 7 2004
Upstream    Port       Poll Missed Min    Missed Hop   Hop    Corr    Uncorr
Port        Status     Rate Poll   Poll   Poll   Thres Period FEC     FEC
                       (ms) Count  Sample Pcnt   Pcnt  (sec)  Errors  Errors
Cable6/0/U0 21.810 MHz 1000 0      10     0%     75%   15     2664305 3404
Cable6/0/U1 admindown  1000 * * *   frequency not set   * * * 0       0
Cable6/0/U2 10.000 MHz 1000 * * *set to fixed frequency * * * 0       0
     

Observação: o comando clear counters só limpa os contadores show interface e show cable hop, mas não o show controllers. É possível que os contadores do controlador só sejam zerados se o CMTS for recarregado ou se a interface receber um ciclo de força com este comando:

ubr# cable power off slot/card

     

Para enfatizar, vale a pena repetir que erros incorrigíveis de FEC resultam em pacotes descartados e muito provavelmente causarão um mau throughput de dados upstream. Antes que os eventos atinjam esse estágio crítico, no entanto, há prediletos e indicações de que o desempenho upstream está deteriorando. Os erros FEC corrigíveis servem como um indicador de que o throughput de dados upstream está se degradando e servem como um sinal de aviso de que erros incorrigíveis de FEC futuros são possíveis.

Dica: se o contador Uncorr incrementa muito mais rápido que o contador Corr, o problema pode estar relacionado ao ruído de impulso. Se o contador Corr estiver aumentando tão rápido (ou mais rápido que) o contador Uncorr, então ele provavelmente está relacionado à AWGN ou é um problema de ingresso em estado estacionário, como banda cidadã (CB), rádio de ondas curtas, distorção de caminho comum (CPD), e assim por diante.

Como obter contadores FEC através do SNMP

Esses três OIDs SNMP do arquivo DOCS-IF-MIB SNMP MIB são usados para coletar e analisar erros FEC (inerrados, corrigidos e incorrigíveis FEC - também consulte o Apêndice):

DOCS-IF-MIB
docsIfSigQUnerroreds       .1.3.6.1.2.1.10.127.1.1.4.1.2
      Codewords received on this channel without error.
      This includes all codewords, whether or not they
      were part of frames destined for this device.

docsIfSigQCorrecteds       .1.3.6.1.2.1.10.127.1.1.4.1.3
      Codewords received on this channel with correctable
      errors. This includes all codewords, whether or not
      they were part of frames destined for this device.

docsIfSigQUncorrectables   .1.3.6.1.2.1.10.127.1.1.4.1.4
      Codewords received on this channel with uncorrectable
      errors. This includes all codewords, whether or not
      they were part of frames destined for this device.

Como esses três MIBs são valores absolutos (com base no número total de blocos de dados FEC que o CMTS está recebendo), calcular a porcentagem fornece uma imagem melhor do desempenho real de throughput upstream. Estas fórmulas devem ser utilizadas:

• _Cx = docsIfSigQUnerroreds no momento x

• _Ecx = docsIfSigQCorreteds no momento x

• _Eux = docsIfSigQUncorrigíveis no momento x

% Corretível = [(Ec1 - Ec0)/ [(Eu1 - Eu0) + (Ec1 - Ec0) + (C1 - C₀)] * 100

% Incorrigível = [(Eu1 - Eu0)/ [(Eu1 - Eu0) + (Ec1 - Ec0) + (C1 - C₀)] * 100

Nota: Incorrigíveis mais incorrigíveis mais incorretos mais corrigidos é igual ao número total de palavras de código (CWs; também conhecidos como blocos de dados FEC) recebidos neste EUA, incluindo todos os CWs, sejam ou não parte de quadros destinados ao CMTS. O tamanho de uma CW é determinado pelo perfil de modulação.

Contadores FEC por modem

Se um pacote US for descartado, ele incrementa um contador Uncorr FEC. Isso ocorre na camada física. Você pode perguntar como o CMTS distingue um pacote descartado, se ele não tiver a chance de ver o ID de serviço (SID) ou o endereço de origem (camada 2). No entanto, o SID do CM está incluído no cabeçalho DOCSIS.

Exemplo de uma intermitência US:

(preâmbulo) + {(docsis hdr = 6 bytes) + (BPI+, docsis estendido hdr = 4 a 7 bytes) + 1500 ethernet + 18 cabeçalho ethernet} + (guardband)

Tudo entre { e } é adicionado, cortado em CWs com base no perfil de modulação e, em seguida, 2×T é adicionado a cada CW. Portanto, tecnicamente, se o codeword específico que mantém o SID for interrompido, como o CMTS poderá distinguir de qual modem ele foi enviado? Uma forma de conseguir isso é usar o agendador do CMTS, que sabe a hora em que determinados pacotes estariam chegando de modems específicos.

Você pode exibir os valores de FEC listados por modem, utilizando o comando show interface cableport/slot sid sid-number counter verbose. Você também pode recuperá-los através do SNMP usando estes OIDs:

• Boas senhas de código recebidas (docsIfCmtsCmStatusUnerroreds)

• Palavras de código corrigidas recebidas (docsIfCmtsCmStatusCorrecteds)

• Erros de palavras código incorretas recebidas (docsIfCmtsCmStatusUncorrectables)

Observação: atualmente, isso só é relevante para as placas de linha MC28U e MC5x20.

ubr7246-2# show interface cable6/0 sid 10 counter verbose

Load for five secs: 5%/1%; one minute: 5%; five minutes: 5%
Time source is NTP, 00:17:13.552 UTC Sat Feb 7 2004
Sid                            : 10
Request polls issued           : 0
BWReqs {Cont,Pigg,RPoll,Other} : 1, 527835, 0, 0
No grant buf BW request drops  : 0
Rate exceeded BW request drops : 0
Grants issued                  : 1787705
Packets received               : 959478
Bytes received                 : 1308727992
Fragment reassembly completed  : 0
Fragment reassembly incomplete : 0
Concatenated packets received  : 0
Queue-indicator bit statistics : 0 set, 0 granted
Good Codewords rx              : 7412780
Corrected Codewords rx         : 186
Uncorrectable Codewords rx     : 11
Concatenated headers received  : 416309
Fragmentation headers received : 1670285
Fragmentation headers discarded: 17

Isso é específico para esse modem e os contadores são atualizados aproximadamente a cada 10 segundos.

ubr7246-2# show cable hop cable6/0

Load for five secs: 5%/1%; one minute: 5%; five minutes: 5%
Time source is NTP, 00:17:13.552 UTC Sat Feb 7 2004
Upstream      Port       Poll Missed Min    Missed Hop   Hop    Corr    Uncorr
Port          Status     Rate Poll   Poll  Poll   Thres Period  FEC     FEC
                         (ms) Count  Sample Pcnt   Pcnt  (sec)  Errors  Errors
Cable6/0/U0   23.870 MHz 1000 0      10     0%     75%   15     186     12
     

Observe que o comando show cable hop está relatando mais um erro Uncorr FEC. Isso provavelmente ocorre porque foi descartado um CW que pertencia a um outro modem.

Seria interessante ver um gráfico de erros de FEC por CM pesquisando os MIBs e usando o MRTG (Multi-Router Traffic Grapher, gráfico de tráfego de vários roteadores) ou outro software, como o Cisco BT. Isso pode ser usado para ver se determinados modems têm atraso de grupo ruim, microreflexões e assim por diante. Isso seria algo que afetaria apenas um modem específico.

Contadores de pacotes upstream

Outro comando que lista erros é o comando show interface cable5/1/0 upstream. Esses são pacotes, que são diferentes dos CWs FEC. Um pacote pode consistir em muitos CWs.

ubr10k# show interface cable5/1/0 upstream

Load for five secs: 4%/0%; one minute: 5%; five minutes: 5%
Time source is NTP, 03:53:43.488 UTC Mon Jan 26 2004
Cable5/1/0: Upstream 0 is up
     Received 48 broadcasts, 0 multicasts, 14923 unicasts
     0 discards, 32971 errors, 0 unknown protocol
     14971 packets input, 72 uncorrectable
     4 noise, 0 microreflections
     Total Modems On This Upstream Channel: 12 (12 active)

Essas são as definições de termos:

• broadcasts —Quadros de broadcast recebidos.

• multicasts — Quadros multicast recebidos.

• unicasts — quadros unicast recebidos.

• descartes — somente incrementos na placa de linha MC5x20S. Lista os pacotes descartados devido a várias condições de erro específicas da placa, e não do quadro real.

• Erros — O total de uma série de erros, muitos dos quais não importam. Os erros que este valor conta são para as placas baseadas em BCM3210 como MC16C e MC28C:

  • O número de slots upstream alocados em que o preâmbulo e o Word exclusivo não foram recebidos corretamente.

  • Número de quadros incorrigíveis recebidos.

  • Colisões nas oportunidades de "solicitação" de largura de banda.

  • Colisões em slots de "solicitação/dados" (esses tipos de slots não ocorrem em Cisco CMTSs).

  • Quadros danificados recebidos durante oportunidades de "solicitação" de largura de banda.

  • Quadros danificados recebidos durante slots de "solicitação/dados".

  • O número de requisições de variação danificadas detectadas.

  Para placas de linha baseadas em JIB, como MC5x20 e MC28U:

  • Quadros com erros de upstream que, por alguns motivos, não são classificados como seqüência de verificação de cabeçalho (HCS) ou verificação de redundância cíclica (CRC) com erros.

  • Quadros upstream com problemas de HCS.

  • Quadros upstream com erros de CRC.

  • CWs incorrigíveis recebidos.

  • Colisões na IUC de requisição de largura de banda.

• protocolo desconhecido —Número de quadros recebidos que não eram IP, Address Resolution Protocol (ARP) ou Point to Point Protocol over Ethernet (PPPoE). Esse contador também inclui quadros com cabeçalhos DOCSIS mal formados ou opções de cabeçalho inválidas.

• entrada de pacotes — Total de broadcasts, multicasts e unicasts.

• incorrigível — Número total de quadros que tinham pelo menos um CW FEC incorrigível dentro deles. Este campo exibe N/A (não disponível) para o MC5x20 e 28U. Em vez disso, use a coluna Uncorr FEC Errors na saída do comando show cable hop para ter uma idéia dos erros incorrigíveis.

• ruído —Para placas baseadas em BCM3210 como MC16C e MC28C, este é o número de quadros danificados recebidos em intervalos de "solicitação" ou "intervalo" de largura de banda. Isso torna esse número um subconjunto dos números em erros.

  • Quadros danificados recebidos durante oportunidades de "solicitação" de largura de banda

  • Quadros danificados recebidos durante slots de "solicitação/dados".

  • O número de requisições de variação danificadas detectadas.

  Para placas baseadas em JIB, como o MC5x20, esse contador não é incrementado.

• microreflecções—Número de microeflecções; sempre definido como 0.

Os erros e os contadores de ruído não contam apenas quadros corrompidos; eles também contam coisas como colisões de solicitações de alcance inicial e colisões de solicitações de largura de banda. Por isso, um contador de ruído que aumenta nem sempre significa que existe um problema. Isso pode significar apenas que o cliente tem muitos modems tentando se conectar ou tem modems tentando fazer mais transmissões (levando a mais colisões mencionadas). O contador de ruído é na verdade um subconjunto do contador de erro, pois o ruído inclui os últimos três componentes do contador de erros.

Conclusão

Por meio de testes de experiência e laboratório feitos pelo grupo de serviços avançados e resposta rápida da Cisco, estas são algumas observações sobre a FEC e o desempenho de upstream ruim:

• A presença de erros FEC incorrigíveis é uma boa medida quando o ruído chega a um nível intolerável ou quando há conflito entre os pacotes quanto a temporização inválida, separador de saída de headend ruim ou isolamento de combinador. No que diz respeito a esta última, um pacote destinado a uma porta de upstream CMTS está "vazando" para outra upstream devido ao isolamento ruim.

• Um grande aumento nos erros incorrigíveis de FEC resulta em problemas de qualidade de voz.

• Os erros de FEC corrigíveis são vistos como o nível de ruído aumentado. Os erros de FEC corrigíveis não resultam em quedas de pacotes ou má qualidade de voz, desde que não haja erros de FEC incorrigíveis que o acompanham.

• Aumentar os T-bytes FEC no perfil de modulação US pode ajudar até um certo ponto, mas depende da fonte de ruído. 7 a 10% de cobertura FEC parece ideal.

A partir das observações anteriores, é claro que a pesquisa do CMTS para os erros incorrigíveis do FEC é valiosa. Voz sobre IP (VoIP) por cabo é particularmente sensível a erros incorrigíveis de FEC. Se a porcentagem de erros incorrigíveis de FEC for alta o suficiente, ocorrerão problemas de qualidade de voz, enquanto os dados de IP podem ser afetados minimamente.

Por fim, se a leitura de SNR do chip dos EUA for enganosa quando defeitos de RF transientes rápidos forem introduzidos (como dito anteriormente), mas erros de FEC incorrigíveis ainda estiverem ocorrendo, a solução de problemas pode se tornar consideravelmente mais complexa.

A Figura 3 destaca um exemplo de um US que apresenta um SNR baixo ao mesmo tempo em que está passando por erros incorrigíveis e corrigíveis de FEC, enfatizando a relação próxima entre esses dois parâmetros ao medir o desempenho upstream.

Figura 3: Erros de SNR e FEC ao longo do tempo

 

O primeiro gráfico exibe a porcentagem de erro FEC incorrigível e corrigível, enquanto o gráfico inferior indica leituras SNR incorretas na mesma instância em tempo. Uma rápida verificação da portadora modulada digitalmente upstream em um analisador de espectro (como um Agilent HP8591C) provavelmente mostraria ruído no canal em níveis bastante altos. Problemas de RF upstream de natureza impulsiva podem ser confirmados usando um equipamento de teste de terceiros (como o Hukk CM1000—consulte o Site de Telecom da Sunrise—ou Acterna DSAM) que pode medir a taxa de erro de bloco upstream (semelhante a BER). Isso verificaria se um problema de RF provavelmente existe, mesmo quando a leitura de SNR dos EUA parece ser boa.

A conclusão é que, se a leitura do SNR dos EUA parecer boa, então não suponha automaticamente que o RF está correto. Uma pequena pesquisa com equipamento de teste apropriado pode ser necessária para determinar exatamente o que está acontecendo no domínio de RF. As chances são bastante boas de que o espectro de RF não seja tão limpo quanto se supunha.

Appendix

Esta seção detalha os parâmetros de upstream a serem monitorados.

Porcentagem de FEC corrigível de upstream

Descrição

Porcentagem de CWs com erros incorrigíveis recebidos neste canal . Inclui todos os CWs, independentemente de fazerem ou não parte de quadros destinados a esse dispositivo.

Fórmula

%Corrigível = [(Ec1 - Ec0)/ [(Eu1 - Eu0) + (Ec1 - Ec0) + (C1 - C₀)] * 100

• C = docsIfSigQUnerroreds

• _Ec = docsIfSigQCorreteds

• _Eu = docsIfSigQUncorrigtables

Regra de Rede

Valores >2,5% dos pacotes recebidos estão destacados em amarelo.

Valores >=5% dos pacotes recebidos estão em negrito vermelho.

Informações da Net

Porcentagem de CWs de entrada com erros de FEC corrigíveis, relativa ao número total de CWs recebidos naquela interface. Sugere-se que essa proporção seja inferior a 5% de todos os CWs de entrada.

Informações detalhadas

DOCS-IF-MIB
docsIfSigQUnerroreds       .1.3.6.1.2.1.10.127.1.1.4.1.2
      Codewords received on this channel without error.
      This includes all codewords, whether or not they
      were part of frames destined for this device.

docsIfSigQCorrecteds       .1.3.6.1.2.1.10.127.1.1.4.1.3
      Codewords received on this channel with correctable
      errors. This includes all codewords, whether or not
      they were part of frames destined for this device.

docsIfSigQUncorrectables   .1.3.6.1.2.1.10.127.1.1.4.1.4
      Codewords received on this channel with uncorrectable
      errors. This includes all codewords, whether or not
      they were part of frames destined for this device.

Porcentagem de FEC incorrigível de upstream

Descrição

Porcentagem de CWs com erros incorrigíveis recebidos neste canal . Inclui todos os CWs, independentemente de fazerem ou não parte de quadros destinados a esse dispositivo.

Fórmula

%Incorrigível = [(Eu1 - Eu0)/ [(Eu1 - Eu0) + (Ec1 - Ec0) + (C1 - C₀)] * 100

• C = docsIfSigQUnerroreds

• _Ec = docsIfSigQCorreteds

• _Eu = docsIfSigQUncorrigtables

Regra de Rede

Os valores >0,5% dos CWs recebidos estão destacados em amarelo.

Valores >=1% dos CWs recebidos estão em negrito vermelho.

Informações da Net

A porcentagem de quedas para CWs de entrada mostra a porcentagem de CWs descartados na entrada, em relação ao número total de CWs recebidos nessa interface. Sugere-se que esta proporção seja inferior a 0,5% de todos os CWs de entrada.

Observação: serviços "em tempo real" específicos, como VoIP, podem exigir monitoramento mais rigoroso. Um valor de FEC 1% incorrigível ainda pode ser perda suficiente de pacotes para causar problemas de qualidade de voz, dependendo se a perda for intermitente ou aleatória.

Informações detalhadas

DOCS-IF-MIB
docsIfSigQUnerroreds       .1.3.6.1.2.1.10.127.1.1.4.1.2
      Codewords received on this channel without error.
      This includes all codewords, whether or not they
      were part of frames destined for this device.

docsIfSigQCorrecteds       .1.3.6.1.2.1.10.127.1.1.4.1.3
      Codewords received on this channel with correctable
      errors. This includes all codewords, whether or not
      they were part of frames destined for this device.

docsIfSigQUncorrectables   .1.3.6.1.2.1.10.127.1.1.4.1.4
      Codewords received on this channel with uncorrectable
      errors. This includes all codewords, whether or not
      they were part of frames destined for this device.

SNR upstream

Descrição

O SNR percebido para este canal. No CMTS, descreve a média de sinal para ruído do canal upstream.

Fórmula

SNR = docsIfSigQSignalNoise / 10

Regra de Rede

Os valores <27 dB estão destacados em amarelo.

Valores <23 dB são em negrito vermelho.

Informações da Net

O DOCSIS especifica um CNR mínimo (digitalmente equivalente a SNR) de 25 dB. Dependendo do perfil de modulação upstream configurado (QPSK ou 16-QAM), o SNR mínimo de 25 dB pode precisar ser aumentado.

Informações detalhadas

ubr7246vxr# show controller cable3/0 upstream 0

 Cable3/0 Upstream 0 is up
  Frequency 25.392 MHz, Channel Width 3.200 MHz, QPSK Symbol Rate 2.560 Msps
  Spectrum Group is overridden
  BroadCom SNR_estimate for good packets - 26.8480 dB
  Nominal Input Power Level 0 dBmV, Tx Timing Offset 2035
  
DOCS-IF-MIB
docsIfSigQSignalNoise      .1.3.6.1.2.1.10.127.1.1.4.1.5
      Signal-to-Noise ratio as perceived for this channel.
      At the CM, describes the Signal-to-Noise of the downstream
      channel.  At the CMTS, describes the average Signal-to-Noise
      of the upstream channel.

Exemplo de como extrair OIDs para contadores de FEC por modem em uma placa de linha MC28U ou 5x20

ubr7246# show cable modem 10.200.100.115

MAC Address    IP Address    I/F        MAC    Prim  RxPwr   Timing  Num  BPI
                                        State  Sid   (dBmV)  Offset  CPE  Enb
0005.5e25.bdfd 10.200.100.115  C6/0/U0  online 50     0.50   2077    0    N

ubr7246# show interface cable 6/0 sid 50 counters verbose | incl Sid|Codeword

Sid                            : 50
Good Codewords rx              : 7580
Corrected Codewords rx         : 0
Uncorrectable Codewords rx     : 2

Para encontrar os contadores de palavra de código deste modem, primeiro é necessário obter duas informações:

• O Índice da Interface SNMP do cabo da interface 6/0.

• Os docsIfCmtsServiceNewCmStatusIndex do modem.

Encontre o ifIndex do cabo 6/0 com este comando:

% snmpwalk -cpublic 172.18.73.167 ifDescr | grep Cable6/0

RFC1213-MIB::ifDescr.10 = STRING: "Cable6/0"

!--- ifIndex of cable 6/0 is "10".

RFC1213-MIB::ifDescr.36 = STRING: "Cable6/0-upstream0"
RFC1213-MIB::ifDescr.37 = STRING: "Cable6/0-upstream1"
RFC1213-MIB::ifDescr.38 = STRING: "Cable6/0-upstream2"
RFC1213-MIB::ifDescr.39 = STRING: "Cable6/0-upstream3"
RFC1213-MIB::ifDescr.40 = STRING: "Cable6/0-downstream"

Localize o docsIfCmtsServiceNewCmStatusIndex do modem com SID 50 na interface com ifIndex 10 (cabo 6/0) com este comando:

% snmpwalk -cpublic 172.18.73.167 docsIfCmtsServiceNewCmStatusIndex.10.50

DOCS-IF-MIB::docsIfCmtsServiceNewCmStatusIndex.10.50 = INTEGER: 983090
     

Agora que você tem o docsIfCmtsServiceNewCmStatusIndex do modem (983090), você pode encontrar estes contadores FEC:

• Boas senhas de código recebidas (docsIfCmtsCmStatusUnerroreds)

  % snmpget -cpublic 172.18.73.167 docsIfCmtsCmStatusUnerroreds.983090
  
  DOCS-IF-MIB::docsIfCmtsCmStatusUnerroreds.983090 = Counter32: 8165
           

  Observação: o contador Unerroreds aumentou um pouco no tempo desde que você emitiu o comando show interface cable.

• Palavras de código corrigidas recebidas (docsIfCmtsCmStatusCorrecteds)

  % snmpget -cpublic 172.18.73.167 docsIfCmtsCmStatusCorrecteds.983090
  
  DOCS-IF-MIB::docsIfCmtsCmStatusCorrecteds.983090 = Counter32: 0
           

• Erros de palavras código incorretas recebidas (docsIfCmtsCmStatusUncorrectables)

  % snmpget -cpublic 172.18.73.167 docsIfCmtsCmStatusUncorrectables.983090
  
  DOCS-IF-MIB::docsIfCmtsCmStatusUncorrectables.983090 = Counter32: 2
           

Informações Relacionadas

• Entendendo o ritmo de transferência de dados em um mundo DOCSIS
• Perfis de modulação upstream para placas de linhas de cabo
• Especificação de Interface de Radiofreqüência DOCSIS
• Suporte para tecnologia de cabo de banda larga
• Suporte Técnico - Cisco Systems