Banda larga a cabo : Radio Frequency (RF) Hybrid Fiber-Coaxial (HFC)

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

14 Outubro 2016 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (19 Dezembro 2015) | Feedback


Índice


Introdução

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 Data Over Cable Service Interface Specification (DOCSIS) esboça as exigências que cada operador de cabo deve manter a fim transportar confiantemente o tráfego de dados IP. Uma característica importante do DOCSIS endereça a necessidade de proteger dados IP contra prejuízos do ruído do Radio Frequency (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 dados IP e mensagens de gerenciamento DOCSIS contra os erros de símbolo causados pelo ruído e pelos outros prejuízos. 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 sobre uma fábrica HFC devem passar através de um codificador reed-solomon, onde os bytes de paridade extra sejam adicionados aos frames de dados para se assegurar de que “erro-estejam protegidos” e prejuízos menos inclinados.

Nota: O FEC não trabalha muito bem se os erros são criados pelo ruído de impulsos que cria muitos erros sucessivamente. os erros Impulso-ruído-induzidos são endereçados no a jusante com o uso da intercalação fazer os erros parecer espalhados para fora, que o FEC é eficaz na fixação. O DOCSIS 2.0 adicionou a intercalação de upstream — que ajuda com este tipo do prejuízo (E.U.) ascendente — mas não está disponível no Modems a cabo 1.x (CM).

Sem dúvida, o caminho de retorno da rede de cabo ou é rio acima particularmente vulnerável propalar e prejuízos 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. Os erros de FEC em uma planta de cabos não são a única medida da 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, seção 2.3.2 da especificação das interferências de radiofreqüência (RFI), “supôs características de transmissão ascendentes do canal RF,” indica isto:

Portador-à-interferência mais DB de 25 do [will not be] da relação do ingresso (a soma do ruído, a distorção, a distorção comum-PATH e a cruz-modulação e a soma do ingresso discreto e de faixa larga sinaliza, ruído de impulsos excluído) menos.

Ou seja os E.U. recomendados DOCSIS mínimos CNR são DB 25. Com a finalidade deste documento, o CNR está definido como a razão portadora-ruído antes que alcance a microplaqueta do demodulador (domínio RF), como medido por um analisador de espectro. Inversamente, o SNR é definido como a razão sinal-ruído da microplaqueta do receptor de US do sistema da extremidade do cable modem (CMTS) depois que o portador foi demodulado para dar uma banda de base pura, razão 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 o SNR, e a avaliação SNR do CMTS não é a mesma coisa que o CNR esse mede com um analisador de espectro.

Este documento discute o cálculo estimado de SNR de upstream dos uBR e igualmente o FEC dos uBR opõe-se e mostra-se porque estas duas variáveis devem constantemente ser avaliadas para assegurar a qualidade HSD em ambientes HFC.

Taxa sinal para ruído.

A avaliação SNR dos uBR pode às vezes ser enganadora, e deve ser considerada somente um ponto de início quando se trata de verificar a integridade do espectro ascendente RF. A leitura SNR na placa de linha do uBR MC16C é fornecida pela microplaqueta E.U., mas a leitura não é necessariamente um indicador confiável de prejuízos RF do “mundo real”, tais como o tipo impulsivo ruído, entrada discreta, e assim por diante. Isso não quer dizer que a leitura do US SNR não esteja precisa. Nos ambientes com poucos prejuízos no ascendente (por exemplo, ruído de impulsos, ingresso, distorção comum do trajeto, e assim por diante), a avaliação E.U. SNR segue numericamente o CNR dentro de menos do que um par decibéis, quando o CNR está na escala DB 15 a 25. É exata com ruído gaussian branco aditivo (AWGN) como o único prejuízo; no mundo real, contudo, a precisão destes números pode variar. Isto depende da natureza dos prejuízos e reflete melhor a proporção de erro da modulação (MER) um pouco do que o CNR.

Como obter leituras SNR e CNR

Esta seção mostra alguns exemplos de como obter a avaliação ascendente SNR de Cisco uBR7200 e uBR10K (igualmente veja o apêndice). Todos os comandos do comando line interface(cli) e saídas do comando são tomados do Software Release 12.2(15)BC2a do ½ do ¿  de Cisco IOSïÂ, salvo disposição em contrário.

Note que “um cartão S” refere uma placa de linha de cabo com capacidades incorporados da análise de espectro do hardware, visto que do “um cartão C” refere uma placa de linha de cabo sem esta capacidade. 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 recolher a saída de comandos CLI do Cisco IOS Software para fins da pesquisa de defeitos ou para enviar a Cisco o Suporte técnico, recorde permitir o timestamp terminal do prompt de exec, de modo que cada linha de saída do comando CLI seja acompanhada por um timestamp e da carga de CPU atual no CMTS.

Para cartões 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 cartões do C ou cartões S sem grupos do 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ê mantém o grupo do nível E.U. no padrão de 0 dBmVs e usa atenuadores externos para forçar o Modems para transmitir a níveis mais altos, caso 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 o SNR mesmo se o CNR é relatado no comando show controllers. Isto é especialmente útil porque o SNR está relatado depois que o cancelamento de ingresso é executado e o CNR está relatado antes do cancelamento de ingresso.

Nota: O SNR é listado por modem em código EC com o comando show cable modem detail.

O comando phy igualmente alista outros atributos da camada física se a remoto-pergunta é configurada. 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.

Nota: Negligencie a entrada de microrreflexão, porque isto é para o DS e é limitado pela precisão da aplicação do fornecedor 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 ver o assoalho 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 IP do modem ou o MAC address ao comando mostra a potência e a largura do canal da explosão do modem.

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 o portador e em outras frequências.

Além do que o CLI, as ferramentas de gerenciamento da rede com base em SNMP tais como o Cisco Broadband Troubleshooter (CBT) podem ser usadas para indicar o espectro de US e outro atributos. Também, os CiscoWorks podem ser usados para monitorar o SNR como relatado por placas de linha de cabo usando o objeto do 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.

Nota: As leituras SNR individuais CM estão somente disponíveis no MC5x20S e em placas de linha MC28U. Estas novas placas de linha incorporam o cancelamento de ingresso que pode melhorar o desempenho mas podem dar leituras SNR enganadoras. As leituras SNR são após o cancelamento de ingresso; Assim, se o cancelamento de ingresso remove matematicamente o ingresso, a seguir o SNR poderia relatar muito melhor do que a razão portadora-interferência real.

Nota: Ao usar grupos do espectro em um cartão S, o comando show controllers seleciona aleatoriamente leituras CNR de todos os CM naquela os E.U., que poderiam ser levemente diferentes, dando a aparência de uma porta E.U. ou de um CNR instável.

Portadores upstream em Zero-Span

Um valor de modo que usa-se em um analisador de espectro é o modo do 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. Figura 1 mostra um analisador de espectro no span zero (domínio de tempo) ao olhar o tráfego ascendente de um CM.

Figura 1 – Indicador do span zero em um analisador de espectro

http://www.cisco.com/c/dam/en/us/support/docs/broadband-cable/radio-frequency-rf-hybrid-fiber-coaxial-hfc/49780-return-path-monitor-1.jpg

Os pacotes de dados podem ser vistos em figura 1, junto com pedidos do modem e ruído de impulsos. Isto é muito útil para medir os níveis digitais médios e observar o ruído e o ingresso, como visto em figura 2.

Figura 2 – Medida do span zero da amplitude modulada Digital ascendente do portador

return_path_monitor_2.gif

O span zero pode igualmente ser usado para considerar se os pacotes estão colidindo um com o otro do sincronismo ruim ou o separador de fim de cabeçalho inadequado ou o isolamento do combinador. Um pacote pretendido para uma porta upstream CMTS “está escapando” em outra rio acima. Refira os White Paper e os documentos alistados na seção da “informação relacionada” 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. Observar os erros incorrigível de FEC (análogos ao BER deficiente e POR) — mesmo que o SNR parece estar acima do padrão mínimo de DOCSIS — poderia apontar a outras edições transientes que precisam de ser endereçadas. Também poderia haver um CM invasor causando erros e uma leitura SNR fraca para todos os outros CMs no mesmo US. Neste caso, o CNR como medido em um analisador de espectro olharia muito bem, mas o CMTS relataria de outra maneira.

Correção de erros de encaminhamento

Recorde que a codificação de Reed-Solomon FEC está usada para adicionar bytes de paridade redundantes aos pacotes de dados, a fim permitir a detecção e correção dos erros de intermitência introduzidos pela planta de cabos.

Em um mundo ideal, os erros de bit mensuráveis — corrigível ou erros incorrigível de FEC — devem raramente nunca 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 (compressão, que é um formulário do grampeamento)

  • clipping de laser

  • ruído impulsivo ou interferência de entrada

  • afrouxe ou conexões intermitentes

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

  • modems defeituosos

Há dois métodos com qual pode recolher a informação 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 (bom e ruim) recebidos por todas as portas upstream associadas com dado rio abaixo.

  • UnCorFECBlks — O número total de blocos FEC recebidos por todas as portas upstream associadas com dado rio abaixo que foram corrompidas assim pelo ruído ou pelo ingresso que não poderiam ser corrigidos ou recuperado pelo algoritmo de FEC.

  • CorFECBlks — O número total de blocos FEC recebidos por todas as portas upstream associadas com dado rio abaixo que foram corrompidas levemente pelo ruído ou pelo ingresso e que poderiam ser corrigidas e recuperado pelo algoritmo de FEC.

A manutenção de estação estoura o incremento os FECBlks contra por aproximadamente 2 pelos segundos x, onde x é o intervalo de polling mínimo (como mostrado no comando show cable hop) dividido por 1000. A consulta remota igualmente incrementa este contador, como faz manutenção inicial quando o Modems vem em linha. Porque a manutenção inicial ocorre durante o tempo da disputa, poderia haver umas colisões e uns erros incorrigível de FEC subsequentes.

Dica: Seja certo que o Modems é de agrupamento ou vir em linha antes de supor os E.U. é instável apenas porque os contadores do incorrigível FEC estão incrementando. Também, o valor de NoUwCollNoEngy pôde aumentar se há Modems com questões de cronometragem. Unique Word (Palavra Exclusiva) é recurso específico para BRCM, e não para DOCSIS, e representa os últimos poucos bytes do preâmbulo.

Uma porcentagem pode ser calculada tomando o ½ 100 do ¿  de UnCorrFECBlks/FECBlks ïÂ. Os FECBlks contrários são os blocos totais FEC enviados, se bom ou ruim. Esta saída é para o domínio MAC completo (todos os USs). É o melhor olhar os contadores entre um período de tempo do grupo para ver o delta.

Nota: Uma desvantagem de recolher a informação de FEC que usa o CLI é que o UnCorFECBlks, o CorFECBlks, e os FECBlks totais não estão separados para fora por rio acima.

A fim olhar por-rio acima a informação de FEC, você deve usar SNMP OID. 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

Nota: O comando clear counters apaga apenas os contadores de show interface e show cable hop, mas não o contador de 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 a ênfase, vale repetindo que os erros incorrigível de FEC conduzem aos pacotes descartado e causarão muito provavelmente a pobres o ritmo de transferência de dados ascendente. Antes que os eventos obtenham a esta fase crítica, contudo, há predictors e indicações que o desempenho de upstream está deteriorando. Os erros de FEC corrigíveis servem como um indicador que o ritmo de transferência de dados ascendente esteja degradando e saque como uma sinalização de advertência que os erros incorrigível de FEC futuros são possíveis.

Dica: Se o contador de Uncorr incrementa muito mais rapidamente do que o contador de Corr, a seguir o problema poderia ser relacionado ao ruído de impulsos. Se o contador de Corr está incrementando como rapidamente (ou mais rapidamente do que) o contador de Uncorr, a seguir relaciona-se provavelmente ao AWGN ou é um problema de ingresso de estado estacionário como a faixa de cidadão (CB), rádio da onda curta, a distorção comum do trajeto (CPD), e assim por diante.

Como obter contadores FEC com o SNMP

Estes três SNMP OID do arquivo do SNMP MIB DOCS-IF-MIB são usados para recolher e analisar erros de FEC (unerrored, corrigido, e incorrigível FEC — igualmente veja 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.

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

  • Cx = docsIfSigQUnerroreds no tempo x

  • ECX = docsIfSigQCorrecteds no tempo x

  • Ux = docsIfSigQUncorrectables E no tempo x

% corrigíveis = [(C1 E – Ec0)/ [(Eu1 – Eu0) + (C1 E – Ec0) + (C1 – C0)]] * 100

% do incorrigível = [(Eu1 – Eu0)/ [(Eu1 – Eu0) + (C1 E – Ec0) + (C1 – C0)]] * 100

Nota: O Sem correção e sem erro mais correcteds iguala o número total das palavras de código (CWs; igualmente sabido como os blocos de dados FEC) recebidos nestes E.U., incluindo todo o CWs, mesmo se eram parte de quadros destinados para o CMTS. O tamanho de uma CW é determinado pelo perfil de modulação.

Contadores FEC por modem

Se um pacote de US é deixado cair, incrementa um contador de Uncorr FEC. Isso ocorre na camada física. Você pôde perguntar como o CMTS distingue um pacote descartado, se não tem uma possibilidade ver o identificador de serviço (SID) ou o endereço de origem (camada 2). Contudo, o CM SID é incluído no cabeçalho de DOCSIS.

Exemplo de uns E.U. estourados:

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

Tudo no meio {e} é adicionado acima, corte no CWs baseado no perfil de modulação, a seguir 2ï ½ T do ¿  é 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 maneira de conseguir isto é usar o planificador do CMTS, que conhece o tempo em que determinados pacotes estariam chegando do Modems específico.

Você pode exibir os valores de FEC listados por modem, utilizando o comando show interface cableport/slot sid sid-number counter verbose. Você pode igualmente recuperá-los com o SNMP usando estes OID:

  • Boas palavras de código recebidas (docsIfCmtsCmStatusUnerroreds)

  • Palavras de código corrigidas recebidas (docsIfCmtsCmStatusCorrecteds)

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

Nota: Atualmente, isso é relevante apenas 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

Isto é específico a este modem e os contadores atualizam aproximadamente os segundos cada 10.

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 a um mais erros incorrigível de FEC. Isso provavelmente ocorre porque foi descartado um CW que pertencia a um outro modem.

Seria interessante ver por CM um gráfico de erros de FEC votando o MIBs e usando o Multi-Router Traffic Grapher (MRTG) ou de outro software tal como Cisco BT. Isto poderia ser usado para ver se os modens particulares têm o retardo de grupo deficiente, microrreflexões, e assim por diante. Este seria algo que afeta somente um modem específico.

Contadores de pacotes upstream

Um outro comando que aliste erros é o comando show interface cable5/1/0 upstream. Este é os pacotes, que são diferentes de FEC CWs. Um pacote podia consistir muito no 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:

  • transmite — Frames de transmissão recebidos.

  • Multicast — Frames de transmissão múltipla recebidos.

  • unicasts — Frames de unicast recebidos.

  • rejeita — Somente incrementos na placa de linha do MC5x20S. Alista os pacotes rejeitados devido às várias condições de erro que são específicas ao cartão, não ao quadro real.

  • erros — O total de uma escala inteira dos erros, muitos de que não importe. Os erros que este valor conta são para as placas baseadas em BCM3210 como MC16C e MC28C:

    • O número de entalhes ascendentes atribuídos onde o preâmbulo e a palavra original não foram recebidos corretamente.

    • Número de quadros incorrigíveis recebidos.

    • Colisões nas oportunidades do “pedido” da largura de banda.

    • Colisões do “em entalhes pedido/dados” (estes tipos de entalhes não ocorrem em Cisco CMTS).

    • Frames danificados recebidos durante oportunidades do “pedido” da largura de banda.

    • Frames danificados recebidos durante do “entalhes pedido/dados”.

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

    Para placas de linha Patíbulo-baseadas como o MC5x20 e o 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 ascendentes com problemas HCS.

    • Quadros upstream com erros de CRC.

    • CWs incorrigíveis recebidos.

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

  • protocolo desconhecido — O número de quadros recebeu que não eram IP, Address Resolution Protocol (ARP), ou protocolo ponto-a-ponto sobre os Ethernet (PPPoE). Esse contador também inclui quadros com cabeçalhos DOCSIS mal formados ou opções de cabeçalho inválidas.

  • pacotes entrados — Total de transmissões, de Multicast, e de unicasts.

  • incorrigível — Número total de quadros que tiveram pelo menos um incorrigível FEC CW 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 cartões BCM3210-based como o MC16C e o MC28C, este é o número de frames danificados recebidos na largura de banda “pedido” ou intervalos “de agrupamento”. Isso torna esse número um subconjunto dos números em erros.

    • Frames danificados recebidos durante oportunidades do “pedido” da largura de banda

    • Frames danificados recebidos durante do “entalhes pedido/dados”.

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

    Para cartões Patíbulo-baseados como o MC5x20 este contador não incrementa de todo.

  • microrreflexões — Número de microrreflexões; ajuste sempre a 0.

Os erros e os contadores do ruído apenas não contam quadros corrompidos; igualmente contam coisas como colisões da solicitação de alcance inicial e colisões da requisição de largura de banda. Por isso, um contador de ruído que aumenta nem sempre significa que existe um problema. Pôde-se apenas significar que o cliente tem muito Modems que tenta vir em linha ou tem o Modems que tenta fazer mais transmissões (que conduzem a mais das 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

Com a experiência e os testes de laboratório feitos pelo grupo avançado dos serviços e da resposta rápida de Cisco, estas são algumas observações em relação ao FEC e ao mau desempenho upstream:

  • 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 aos últimos, um pacote pretendido para uma porta upstream CMTS “está escapando” em outra rio acima devido ao isolamento ruim.

  • Um grande aumento nos erros incorrigível de FEC conduz às questões de qualidade de voz.

  • Os erros de FEC corrigíveis são considerados enquanto o nível do ruído é aumentado. Os erros de FEC corrigíveis não conduzem às quedas de pacote de informação ou à qualidade de voz deficiente, enquanto não há nenhum erro incorrigível de FEC de acompanhamento.

  • Aumentar os T-bytes FEC no perfil da modulação de US pode ajudar até algum ponto, mas depende do origem de ruído. Sete a dez por cento de cobertura de FEC parecem ótimos.

Das observações anterior, é claro que votar o CMTS para os erros incorrigível de FEC é valiosa. Voz sobre IP (VoIP) por cabo é particularmente sensível a erros incorrigíveis de FEC. Se a porcentagem dos erros incorrigível de FEC é altamente bastante, a seguir as questões de qualidade de voz são experientes, visto que os dados IP puderam somente ser minimamente afetados.

Finalmente, se a leitura SNR da microplaqueta E.U. é enganadora quando os prejuízos rápidos do transeunte RF estão introduzidos (como indicado mais cedo) mas os erros incorrigível de FEC ainda estão ocorrendo, pesquisar defeitos o problema pode obter consideravelmente mais complexa.

Figura 3 destaca um exemplo de uns E.U. que experimentam o baixo SNR ao mesmo tempo que está experimentando o incorrigível e erros de FEC corrigíveis, sublinhando o relacionamento próximo entre estes dois parâmetros ao medir o desempenho de upstream.

Figura 3 – SNR e erros de FEC ao longo do tempo

http://www.cisco.com/c/dam/en/us/support/docs/broadband-cable/radio-frequency-rf-hybrid-fiber-coaxial-hfc/49780-return-path-monitor-3.gif

O primeiro gráfico indica o incorrigível e o percentual de erros FEC corrigíveis, quando o gráfico inferior indicar leituras SNR deficientes na mesma instância a tempo. Uma verificação rápida do portador digitalmente modulado ascendente em um analisador de espectro (tal como um Agilent HP8591C) mostraria provavelmente o ruído em canal razoavelmente em níveis altos. Os problemas ascendentes RF de uma natureza impulsiva podem ser confirmados usando o equipamento de teste da terceira (tal como Hukk CM1000 — refira o site do Sunrise Telecomleavingcisco.com — ou Acterna DSAM) que pode medir a taxa de erro de bloqueio ascendente (similar ao BER). Isto verificaria que um problema RF existe provavelmente, mesmo quando a leitura SNR E.U. parece ser boa.

A linha inferior é que se a leitura SNR E.U. parece ser boa então não supõe automaticamente que o RF é bem. Pouca pesquisa com equipamento de teste apropriado pôde ser exigida determinar exatamente o que está indo sobre no domínio RF. As probabilidades são relativamente bons que o espectro RF não está tão limpo quanto foi suposto primeiramente.

Apêndice

Esta seção detalha os parâmetros de upstream para monitorar.

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

%Correctable = [(C1 E – Ec0)/ [(Eu1 – Eu0) + (C1 E – Ec0) + (C1 – C0)]] * 100

  • C = docsIfSigQUnerroreds

  • E.C. = docsIfSigQCorrecteds

  • UE = docsIfSigQUncorrectables

Regra líquida

Os valores >2.5% dos pacotes recebidos são amarelo destacado.

Os valores >=5% dos pacotes recebidos são vermelho corajoso.

Informação líquida

Porcentagem de CWs de entrada com erros de FEC corrigíveis, relativa ao número total de CWs recebidos naquela interface. Sugere-se que esta relação esteja abaixo de 5% de toda a entrada CWs.

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

%Uncorrectable = [(Eu1 – Eu0)/ [(Eu1 – Eu0) + (C1 E – Ec0) + (C1 – C0)]] * 100

  • C = docsIfSigQUnerroreds

  • E.C. = docsIfSigQCorrecteds

  • UE = docsIfSigQUncorrectables

Regra líquida

Os valores >0.5% do CWs recebido são amarelo destacado.

Os valores >=1% do CWs recebido são vermelho corajoso.

Informação líquida

A porcentagem das gotas para a entrada CWs mostra a porcentagem do CWs deixada cair na entrada, relativo ao número total de CWs recebido nessa relação. Sugere-se que esta relação esteja abaixo de 0.5% de toda a entrada CWs.

Nota: Os serviços específicos do “tempo real”, tais como VoIP, podem exigir uma monitoração mais estrita. Um valor do incorrigível FEC de 1% pôde ainda ser suficiente perda de pacotes para causar questões de qualidade de voz, segundo se a perda é estourada 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 relação sinal-ruído do canal upstream.

Fórmula

SNR = docsIfSigQSignalNoise / 10

Regra líquida

O DB dos valores <27 é amarelo destacado.

O DB dos valores <23 é vermelho corajoso.

Informação líquida

O DOCSIS especifica um mínimo CNR (digitalmente equivalente ao SNR) de DB 25. Segundo o perfil de modulação ascendente configurado (QPSK ou 16-QAM), o mínimo SNR de DB 25 pode precisar de 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

A fim encontrar contadores das palavras de código deste modem, você precisa primeiramente de obter duas partes de informação:

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

  • O 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"

Encontre o docsIfCmtsServiceNewCmStatusIndex do modem com os 50 pés de SID na relação 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 palavras de código recebidas (docsIfCmtsCmStatusUnerroreds)

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

    Nota: O contador Unerroreds incrementou o 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


Document ID: 49780