Banda ancha por cable : Radiofrecuencia (RF) de Cable híbrido de fibra óptica-coaxial (HFC)  

Errores FEC ascendentes y SNR como modos para garantizar la calidad de los datos y el rendimiento

18 Junio 2016 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (19 Diciembre 2015) | Comentarios


Contenido


Introducción

Para manejar una red de alta velocidad de datos (HSD) sobre una planta de cable coaxial/fibra híbrida (HFC) se requiere un gran nivel de control de calidad para asegurar la integridad de los datos y el más alto nivel del flujo de datos. Los dos medios generalmente aceptados a través de los cuales los operadores de cable pueden medir la calidad de los datos es controlando la velocidad de bits de error (BER) o la velocidad de bits de paquete (PER).

El Data Over Cable Service Interface Specification (DOCSIS) delinea los requisitos que cada operador de cable debe mantener para transportar confiablemente el tráfico de datos IP. Una característica importante del DOCSIS dirige la necesidad de proteger los datos IP contra las debilitaciones del ruido del Radiofrecuencia (RF). La función que DOCSIS utiliza para ayudar a preservar la integridad de los datos IP sobre plantas de cable es la codificación Reed-Solomon Forward Error Correction (FEC).

Esencialmente, la codificación FEC protege los datos IP y los mensajes de administración del DOCSIS contra los errores de símbolo causados por el ruido y otras debilitaciones. La única característica de FEC es que puede detectar errores de símbolos y corregirlos. Así, el DOCSIS especifica que todos los datos IP que se transmiten sobre una planta HFC deben pasar con codificador Reed-Solomon, donde los bytes de paridad adicionales se agregan a los marcos de datos para asegurarse de que “error-están protegidos” y las debilitaciones menos propensas.

Nota: El FEC no trabaja muy bien si los errores son creados por el ruido del impulso que crea muchos errores sucesivamente. los errores Impulso-ruido-inducidos se dirigen en el rio abajo con el uso de la interpolación de hacer que los errores aparecen separados hacia fuera, que el FEC es eficaz en la fijación. El DOCSIS 2.0 ha agregado el entrelazado ascendente — que ayuda con este tipo de la debilitación por aguas arriba (los E.E.U.U.) — pero no está disponible en el Cable módems 1.x (CMS).

Sin duda, el trayecto de retorno de la red de cable o la conexión en sentido ascendente es determinado vulnerable divulgar y las debilitaciones relacionadas. Puede tratarse de distintos tipos de ruido: de impulso, de ingreso, térmico, reducción con láser, etcétera. Sin codificación de FEC, son enormes las probabilidades de que se esté perdiendo un paquete debido a errores de bit. Los errores FEC en una planta de cable no son la única medida de la calidad. Hay otras variables que deben considerarse, como la Relación entre portadora y ruido (CNR).

La norma DOCSIS incluye parámetros recomendados para el rendimiento de RF de TV por cable descendente y ascendente. Específicamente, la sección 2.3.2 de la especificación de interferencia en radio frecuencia (RFI), “asumió las características de transmisión por aguas arriba del canal RF,” estado esto:

DB de 25 del [will not be] de la relación de transformación de Portador-a-interferencia más el ingreso (la suma de ruido, distorsión, distorsión de trayecto común y cruz-modulación y la suma de ingreso discreto y de banda ancha señala, ruido del impulso excluido) menos.

Es decir el mínimo de DOCSIS recomendó los E.E.U.U. CNR es DB 25. Con el fin de este documento, el CNR se define como el relación portadora-ruido antes de que alcance el chip del desmodulador (dominio RF), según lo medido por un analizador de espectro. Inversamente, el SNR se define como el relación señal-ruido del chip del receptor ascendente del sistema de la terminación del cablemódem (CMTS) después de que el portador se haya desmodulado para dar una banda base pura, relación señal-ruido.

Por lo tanto, si se observa la lectura SNR en un uBR7246 de Cisco y aparece un número como 30 dB, es fácil suponer que la transmisión ascendente parece cumplir con las DOCSIS o aun superarlas y que el mundo del RF funciona bien. Sin embargo, este no siempre es el caso. El DOCSIS no especifica el SNR, y la estimación del SNR CMTS no es la misma cosa que el CNR aquél mide con un analizador de espectro.

Este documento discute los uBR cálculo estimado del flujo ascendente SNR y también el FEC de los uBR contradice y muestra porqué estas dos variables se deben evaluar constantemente para asegurar la calidad HSD en entornos HFC.

Relación señal-ruido

La estimación del SNR de los uBR puede a veces ser engañosa, y se debe considerar solamente un punto de partida cuando se trata de marcar la integridad del espectro de la conexión en sentido ascendente RF. Lectura de SNR encendido el linecard del uBR MC16C es proporcionado por el chip E.E.U.U., pero la lectura no es necesariamente un indicador confiable de las debilitaciones “del mundo real” RF, tales como ruido impulsivo del tipo, ingreso discreto, y así sucesivamente. Eso no significa que la lectura de SNR de US no sea adecuada. En los entornos con pocas debilitaciones en la conexión en sentido ascendente (por ejemplo, ruido del impulso, ingreso, distorsión de trayecto común, y así sucesivamente), la estimación del SNR E.E.U.U. sigue numéricamente el CNR dentro menos que un par de decibelios, cuando el CNR está en el rango DB 15 a 25. Es exacta con el ruido gausiano blanco aditivo (AWGN) como la única debilitación; en el mundo real, sin embargo, la exactitud de estos números puede variar. Esto depende de la naturaleza de las debilitaciones y refleja mejor la proporción de error de la modulación (MER) bastante que el CNR.

Cómo obtener las lecturas del SNR y CNR

Esta sección muestra algunos ejemplos de cómo obtener la estimación por aguas arriba del SNR del Cisco uBR7200 y el uBR10K (también vea el apéndice). Toman todos los comandos y salidas de comando del comando line interface(cli) del Software Release 12.2(15)BC2a del ½ del ¿Â de Cisco IOSïÂ, salvo especificación de lo contrario.

Observe que un “indicador luminoso LED amarillo de la placa muestra gravedad menor S” refiere a una placa de línea del cable con las capacidades incorporadas de la análisis de espectro del hardware, mientras que un “indicador luminoso LED amarillo de la placa muestra gravedad menor del C” refiere a una placa de línea del cable sin esta capacidad. Bajo ciertas configuraciones, la tarjeta S reporta CNR en lugar de SNR, debido a que tiene un hardware incorporado para realizar funciones de análisis de espectro.

Consejo: Al recolectar la salida de los comandos CLI del Cisco IOS Software con el propósito de resolver problemas o para remitir a Cisco el Soporte técnico, recuerde habilitar el grupo fecha/hora terminal del prompt exec, de modo que cada línea de salida del comando CLI sea acompañada por un grupo fecha/hora y por la corriente carga de la CPU en el CMTS.

Para los indicadores luminosos LED amarillo de la placa muestra gravedad menor 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 los indicadores luminosos LED amarillo de la placa muestra gravedad menor del C o los indicadores luminosos LED amarillo de la placa muestra gravedad menor S sin los grupos del espectro asignados:

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

Se recomienda que usted guarda el conjunto del nivel E.E.U.U. en el valor por defecto de 0 dBmV y utiliza los atenuadores externos para forzar los módems para transmitir en niveles más altos, en caso necesario.

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

Consejo: El comando phy puede ser utilizado para señalar el SNR incluso si el CNR está señalado en el comando show controllers. Esto es especialmente útil porque el SNR está señalado después de que se realice la cancelación del ingreso y el CNR está señalado antes de la cancelación del ingreso.

Nota: La SNR se detalla por módem en el código EC con el comando show cable modem detail.

El comando phy también enumera otros atributos de la Capa física si se configura la telecontrol-interrogación. Estas tres líneas de código pueden ingresarse para activar la consulta remota:

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

Se utilizaron tres segundos para una respuesta rápida, no recomendada en un CMTS muy cargado. La identificación de comunidad sólo de lectura predeterminada en la mayoría de los módems es pública.

Nota: Desatienda la entrada de microreflexión, porque esto está para el DS y es limitada por la exactitud de la implementación del proveedor de 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

Este comando enumera SNR cuando utiliza una tarjeta C. Cuando se usa una tarjeta S y se asignan los grupos de espectro, se informa CNR. El comando show cable modem mac-address verbose también funciona.

Cómo ver el suelo del ruido

Las tarjetas S le permiten ver el piso de ruido con 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

Agregar el IP del módem o la dirección MAC al comando muestra el poder y el ancho del canal de la explosión del módem.

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  *******

Esa salida muestra el ruido bajo el portador y en otras frecuencias.

Además del CLI, las herramientas de administración de red SNMP basadas tales como Cisco Broadband Troubleshooter (CBT) se pueden utilizar para visualizar el espectro ascendente y otro los atributos. También, los CiscoWorks se pueden utilizar para monitorear el SNR según lo señalado por las placas de línea del cable usando el objeto del 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: Las lecturas individuales del SNR CM están solamente disponibles en el MC5x20S y el linecards MC28U. Estas nuevas placas de línea incorporan la cancelación del ingreso que puede mejorar el funcionamiento pero pueden dar las lecturas engañosas del SNR. Las lecturas del SNR están después de cancelación del ingreso; Así pues, si la cancelación del ingreso quita matemáticamente el ingreso, después el SNR podría señalar mucho mejor que la relación de portadora-interferencia real.

Nota: Al usar a los grupos del espectro en un indicador luminoso LED amarillo de la placa muestra gravedad menor S, el comando show controllers selecciona aleatoriamente las lecturas CNR de todo el CMS en eso los E.E.U.U., que podrían ser levemente diferente, dando el aspecto de un puerto E.E.U.U. o de un CNR inestable.

Upstream Carriers (Portadoras ascendentes)

A modo que vale la pena que usa en un analizador de espectro es el modo del cero-span. Este es el modo de dominio temporal donde se muestra la amplitud comparada con el tiempo en lugar de la amplitud comparada con la frecuencia. Este modo es muy conveniente cuando se visualiza el tráfico de datos que está congestionado por naturaleza. El cuadro 1 muestra un analizador de espectro en el cero-span (dominio temporal) mientras que mira el tráfico por aguas arriba de un CM.

Cuadro 1 – Visualización del cero-span en un analizador 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

Los paquetes de datos se pueden ver en el cuadro 1, junto con las peticiones del módem y el ruido del impulso. Esto es muy útil para medir los niveles digitales medios y observar el ruido y el ingreso, como se ve en el cuadro 2.

Cuadro 2 – Medida del cero-span de la amplitud modulada Digital del portador de la conexión en sentido ascendente

return_path_monitor_2.gif

El cero-span se puede también utilizar para considerar si los paquetes están chocando con uno a de la mala sincronización o poor headend splitter o aislamiento del combinador. Un paquete previsto para un puerto ascendente CMTS “se está escapando” sobre otra conexión en sentido ascendente. Refiera a los White Paper y a los documentos enumerados en la sección de la “información relacionada” de este documento. Para obtener una descripción del procedimiento de cero-span, consulte Conexión del router serie Cisco uBR7200 para la cabecera del cable.

Prácticamente todos los desperfectos de RF hasta aquí mencionados en este documento, pueden degradar el rendimiento ascendente y se manifiestan como bajo caudal de datos sin reflejarse necesariamente como baja SNR. La observación de los errores FEC imposibles de corregir (análogos al BER pobre y POR) — aunque el SNR aparece estar sobre el estándar mínimo de DOCSIS — podría señalar a otros problemas transitorios que necesitan ser abordados. También, puede haber un CM no autorizado que genere errores y una lectura pobre de SNR para el resto de los CM en el mismo flujo ascendente. En este caso, el CNR según lo medido en un analizador de espectro miraría muy bien, pero el CMTS señalaría de otra manera.

Corrección de errores de reenvío

Recuerde que la codificación de Solomon De Lámina FEC está utilizada para agregar los bytes de paridad redundante a los paquetes de datos, para permitir la detección y corrección de Errores de ráfaga introducidos por la planta de cable.

En un mundo ideal, los errores de bit mensurables — corregible o los errores FEC imposibles de corregir — deben ocurrir raramente nunca. Sin embargo, cuando existen errores FEC incorregibles, los efectos pueden ser severos y pueden estar provocados por una cantidad indeterminada de distintos factores. Esta es una lista de eventos conocidos que pueden provocar errores FEC imposibles de corregir en el sentido ascendente y que debe tenerse en cuenta cuando se solucionan errores FEC:

  • interferencia del transmisor de barrido

  • sobrecarga del amplificador (compresión, que es una forma de recortes)

  • reducción con láser

  • ruido del impulso o interferencia de ingreso

  • suelte o las conexiones intermitentes

  • combinador ascendente escaso o aislación de divisor

  • módems defectuosos

Hay dos métodos con cuál puede recoger la información de FEC:

  • CLI

  • Sondeo del Identificador del objeto (OID) de SNMP

A continuación se presenta un ejemplo de cómo recopilar información de FEC mediante el uso de CLI (consulte también el 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 — El número total de bloques FEC (bueno y malo) recibidos por todos los puertos ascendentes asociados al dado rio abajo.

  • UnCorFECBlks — El número total de bloques FEC recibidos por todos los puertos ascendentes asociados al dado rio abajo que fueron corrompidos tan por el ruido o el ingreso que no podrían ser corregidos o ser recuperados por el algoritmo FEC.

  • CorFECBlks — El número total de bloques FEC recibidos por todos los puertos ascendentes asociados al dado rio abajo que fueron corrompidos levemente por el ruido o el ingreso y que se podrían corregir y recuperar por el algoritmo FEC.

Las explosiones del mantenimiento de la estación incrementan el contador del FECBlks por aproximadamente 2 por los segundos x, donde está el intervalo de sondeo x mínimo (como se muestra en el comando show cable hop) dividido por 1000. La consulta remota también incrementa este contador, al igual que mantenimiento inicial cuando vienen los módems en línea. Porque el mantenimiento inicial ocurre durante el tiempo de la contención, podría haber colisiones y errores FEC imposibles de corregir subsiguientes.

Consejo: Esté seguro que los módems son de alcance o el venir en línea antes de si se asume que los E.E.U.U. es inestable apenas porque los contadores incorregibles FEC están incrementando. También, el valor de NoUwCollNoEngy pudo aumentar si hay módems con los problemas de sincronización. La palabra única es específica para BRCM, no para DOCSIS y está formada por los últimos bytes del preámbulo.

Un porcentaje puede ser estimado tomando el ½ 100 del ¿Â de UnCorrFECBlks/del FECBlks ïÂ. El contador del FECBlks es los bloques totales FEC enviados, es bueno o malo. Este resultado es para todo el dominio MAC (todo US). Es el mejor mirar los contadores entre un período de tiempo del conjunto para ver el delta.

Nota: Una desventaja de recoger la información de FEC usando el CLI es que el UnCorFECBlks, el CorFECBlks, y el FECBlks total no están separados hacia fuera por la conexión en sentido ascendente.

Para mirar la información de FEC de la por-conexión en sentido ascendente, usted debe utilizar SNMP OID. También puede utilizar el comando show cable hop para ver errores FEC que pueden o no corregirse por puerto ascendente, pero no el total de bloques 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: El comando clear counters sólo elimina los contadores de show interface y de show cable hop, pero no el contador de show controllers. Los contadores del controlador sólo se pueden borrar si se recarga CMTS o si se cierra y se vuelve a abrir la interfaz mediante este comando:

ubr# cable power off slot/card

Para el énfasis, vale el relanzar de que los errores FEC imposibles de corregir dan lugar a los paquetes perdidos y causarán muy probablemente la producción de datos ascendentes pobre. Antes de que los eventos consigan a esta etapa crítica, sin embargo, hay calculadores y las indicaciones que el rendimiento de flujo ascendente está deteriorando. Los errores FEC corregibles sirven como indicador que la producción de datos ascendentes esté degradando y servicio como señal de advertencia que los errores FEC imposibles de corregir futuros son posibles.

Consejo: Si el contador de Uncorr incrementa mucho más rápidamente que el contador de Corr, después el problema se podría relacionar con el ruido del impulso. Si el contador de Corr está incrementando como rápidamente (o más rápidamente que) el contador de Uncorr, después se relaciona probablemente con el AWGN o es un problema de ingreso de estado estacionario como la banda de ciudadano (CB), radio de la onda corta, la distorsión de trayecto común (CPD), y así sucesivamente.

Cómo obtener los contadores FEC con el SNMP

Estos tres SNMP OID del archivo del SNMP MIB DOCS-IF-MIB se utilizan para recoger y para analizar los errores FEC (FEC unerrored, corregido, y incorregible — también vea el 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 eso tres MIB es valores absolutos (basados en el número total de bloques de datos FEC que el CMTS está recibiendo), el cálculo del porcentaje proporciona una mejor imagen del funcionamiento real del rendimiento de procesamiento ascendente. Estas fórmulas deben ser utilizadas:

  • Cx = docsIfSigQUnerroreds en el tiempo x

  • ECX = docsIfSigQCorrecteds en el tiempo x

  • Ux = docsIfSigQUncorrectables E en el tiempo x

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

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

Nota: Incorregible más los unerroreds más los correcteds iguale el número total de codewords (CWs; también conocido como bloques de datos FEC) recibidos en los estos E.E.U.U., incluyendo todo el CWs, independientemente de si eran tramas de la parte de destinadas para el CMTS. El tamaño de una CW es determinado por el perfil de modulación.

Contadores FEC por módem

Si se cae un paquete US, incrementa un contador de Uncorr FEC. Esto ocurre en la capa física. Usted puede ser que pregunte cómo el CMTS distingue un paquete perdidos, si no tiene una ocasión de ver el ID del servicio (SID) o a la dirección de origen (capa 2). Sin embargo, el CM SID se incluye en el encabezamiento DOCSIS.

Ejemplo de un E.E.U.U. repartidos:

(preamble) + {(docsis hdr = 6 bytes) + (BPI+, docsis extended hdr = 4 to 7 bytes) + 1500 ethernet + 18 ethernet header} + (guardband)

Todo en medio {y} se agrega para arriba, corte en el CWs basado en el perfil de modulación, después 2ï el ½ T del ¿Â se agrega a cada CW. Por lo que, técnicamente, si el código de palabras específico que utiliza el SID se desconecta, ¿cómo puede distinguir el CMTS desde qué modem se envió? Una manera de alcanzar esto es utilizar el planificador de trabajos CMTS, que conoce el tiempo en que ciertos paquetes estarían llegando de los módems específicos.

Puede visualizar los valores FEC listados por cada módem mediante el comando show interface cableport/slot sid sid-number counter verbose. Usted puede también extraerlos con el SNMP usando estos OID:

  • Buen codewords recibido (docsIfCmtsCmStatusUnerroreds)

  • Codewords corregido recibido (docsIfCmtsCmStatusCorrecteds)

  • Palabras de código recibidas no corregidas (docsIfCmtsCmStatusUncorrectables)

Nota: Actualmente, esto sólo tiene relevancia respecto de las tarjetas de línea MC28U y 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

Esto es específico a este módem y los contadores ponen al día aproximadamente 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

Note que el comando show cable hop está señalando a uno más errores Uncorr FEC. Esto se debe probablemente a que se suprimió una CW que resultó pertenecer a otro módem.

Sería interesante ver un gráfico de los errores FEC del por CM sondeando el MIB y usando el Multi-Router Traffic Grapher (MRTG) o del otro software tal como Cisco BT. Esto se podría utilizar para ver si los módems particulares tienen Retraso del grupo pobre, microreflections, y así sucesivamente. Éste sería algo que afecta solamente a un módem específico.

Contadores de paquetes ascendentes

Otro comando que enumera los errores es el comando show interface cable5/1/0 upstream. Éste es los paquetes, que son diferentes del CWs FEC. Un paquete podía consistir en mucho 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)

Éstas son las definiciones de los términos:

  • transmite — Tramas de broadcast recibidas.

  • Multicast — Tramas de multidifusión recibidas.

  • unicasts — Tramas de unidifusión recibidas.

  • desecha — Solamente incrementos en el linecard del MC5x20S. Enumera los paquetes desechados debido a las diversas condiciones de error que son específicas al indicador luminoso LED amarillo de la placa muestra gravedad menor, no a la trama real.

  • errores — El total de una amplia gama de errores, muchos cuyo no importe. Los errores que este valor cuenta corresponden a las tarjetas basadas en BCM3210, como MC16C y MC28C:

    • El número de slots por aguas arriba afectados un aparato donde el preámbulo y la palabra única no fueron recibidos correctamente.

    • El número recibido de tramas incorregibles.

    • Colisiones en las oportunidades de la “petición” del ancho de banda.

    • Colisiones en los slots de la “petición/de los datos” (estos tipos de slots no ocurren en Cisco CMTS).

    • Tramas dañadas recibidas durante las oportunidades de la “petición” del ancho de banda.

    • Tramas dañadas recibidas durante los slots de la “petición/de los datos”.

    • La cantidad de pedidos de definición de rangos escuchados que están dañados.

    Para el linecards Horca-basado como el MC5x20 y el MC28U:

    • Tramas ascendentes con errores que, por alguna razón, no están clasificadas como con errores de Secuencia de verificación de encabezado (HCS) o Verificación de redundancia cíclica (CRC).

    • Tramas por aguas arriba con los problemas HCS.

    • Tramas de flujo ascendente con errores CRC.

    • CW recibidos incorregibles.

    • Colisiones en el pedido de ancho de banda IUC.

  • protocolo desconocido — El número de bastidores recibió que no eran IP, Address Resolution Protocol (ARP), o protocolo punto a punto sobre los Ethernetes (PPPoE). Este contador también incluye tramas con encabezados DOCSIS mal formados u opciones de encabezado inválidas.

  • paquetes entrados — Total de broadcasts, de Multicast, y de unicasts.

  • incorregible — Número total de bastidores que tenían por lo menos un FEC incorregible CW dentro de ellos. Este campo muestra N/A para el MC5x20 y 28U. En cambio, utilice la columna Uncorr FEC Errors en la salida de show cable hop, para obtener una idea sobre los errores incorregibles.

  • ruido — Para los indicadores luminosos LED amarillo de la placa muestra gravedad menor BCM3210-based como el MC16C y el MC28C, éste es el número de Tramas dañadas recibidas en el ancho de banda “petición” o intervalos de “alcance”. Esto convierte a este número en un subconjunto de los números en errores.

    • Tramas dañadas recibidas durante las oportunidades de la “petición” del ancho de banda

    • Tramas dañadas recibidas durante los slots de la “petición/de los datos”.

    • La cantidad de pedidos de definición de rangos escuchados que están dañados.

    Para los indicadores luminosos LED amarillo de la placa muestra gravedad menor Horca-basados como el MC5x20 este contador no incrementa en absoluto.

  • microreflections — Número de microreflections; fije siempre a 0.

Los errores y los contadores del ruido apenas no cuentan las tramas corrompidas; también cuentan las cosas como las colisiones del pedido de determinación de la distancia inicial y las colisiones del pedido de ancho de banda. Por lo tanto, un contador de ruido en aumento no siempre significa que existe un problema. Puede ser que apenas signifique que el cliente tiene muchos módems que intentan venir en línea o tiene módems que intentan hacer más transmisiones (que llevan más de las colisiones mencionadas). En realidad, el contador de ruido es un subconjunto del contador de errores ya que el ruido incluye los tres últimos componentes de éste.

Conclusión

Con la prueba de la experiencia y de laboratorio hecha por el grupo anticipado de los servicios y de la respuesta rápida de Cisco, éstas son algunas observaciones con respecto el FEC y al bajo rendimiento ascendente:

  • La presencia de errores FEC incorregibles es un buen indicador cuando el ruido llega a un nivel intolerable o cuando los paquetes están colisionando entre sí debido a una sincronización incorrecta, a un divisor de cabecera de baja calidad o a un aislamiento del combinador. Con respecto a estos últimos, un paquete previsto para un puerto ascendente CMTS “se está escapando” sobre otra conexión en sentido ascendente debido al aislamiento de baja calidad.

  • Un aumento grande en los errores FEC imposibles de corregir da lugar a los problemas de calidad de voz.

  • Se consideran los errores FEC corregibles mientras que el nivel de ruido se aumenta. Los errores FEC corregibles no dan lugar a las caídas de paquetes o a la calidad de voz deficiente, mientras no haya errores FEC imposibles de corregir de acompañamiento.

  • El aumento de los T-bytes FEC en modulación US (ascendente) el perfil puede ayudar hasta cierta punta, pero depende de la fuente de interferencia. El siete a diez por ciento de cobertura FEC parece óptimo.

De las observaciones anteriores, está claro que sondear el CMTS para los errores FEC imposibles de corregir tiene valor. El cable de Voz sobre IP (VoIP) es particularmente sensible a los errores FEC incorregibles. Si es el porcentaje de los errores FEC imposibles de corregir arriba bastante, después se experimentan los problemas de calidad de voz, mientras que los datos IP pudieron ser afectados solamente como mínimo.

Finalmente, si el chip E.E.U.U. lectura de SNR es engañoso cuando las debilitaciones rápidas del transeúnte RF se introducen (según lo expuesto anterior) pero los errores FEC imposibles de corregir todavía están ocurriendo, resolver problemas el problema puede conseguir considerablemente más complejo.

El cuadro 3 resalta un ejemplo de un E.E.U.U. que experimentan el SNR bajo a la vez que está experimentando los errores FEC incorregibles y corregibles, acentuando la relación cercana entre estos dos parámetros al medir el rendimiento de flujo ascendente.

Cuadro 3 – SNR y errores FEC en un cierto plazo

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

El primer gráfico visualiza el incorregible y el porcentaje de error FEC corregible, mientras que el gráfico inferior indica las lecturas pobres del SNR en la misma instancia a tiempo. Una verificación rápida del portador digital modulado de la conexión en sentido ascendente en un analizador de espectro (tal como un Agilent HP8591C) mostraría probablemente el ruido en canal en bastante los niveles elevados. Los problemas por aguas arriba RF de una naturaleza impulsiva se pueden confirmar usando el equipo de prueba de tercera persona (tal como Hukk CM1000 — refiera Sunrise Telecom al sitio webleavingcisco.com — o Acterna DSAM) que puede medir la tarifa de error de bloqueo por aguas arriba (similar al BER). Esto verificaría que exista un problema RF probablemente, incluso cuando los E.E.U.U. lectura de SNR aparecen ser buenos.

Lo importante es que si los E.E.U.U. lectura de SNR aparecen ser buenos entonces no asuma automáticamente que el RF está bien. Una poca investigación con el equipo de prueba apropiado se pudo requerir para determinar exactamente qué está entrando encendido en el dominio RF. Las probabilidades son bastante probable que el espectro RF no es tan limpio como primero fue asumido.

Apéndice

Esta sección detalla los parámetros ascendentes para monitorear.

Porcentaje ascendente corregible FEC

Descripción

Porcentaje de CW recibidos en este canal con errores incorregibles. Esto incluye todas las palabras de código, independientemente de que hayan formado parte de tramas destinadas a este dispositivo.

Fórmula

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

  • C = docsIfSigQUnerroreds

  • Comunidad Europea = docsIfSigQCorrecteds

  • UE = docsIfSigQUncorrectables

Regla neta

Los valores el >2.5% de los paquetes recibidos son amarillo resaltado.

Los valores el >=5% de los paquetes recibidos son con negrita y en color rojo.

Información neta

Porcentaje de CW de entrada con errores FEC corregibles, relativos al número total de CW recibidos en esa interfaz. Se sugiere que esta relación de transformación esté debajo del 5% de todo el CWs de la entrada.

Información detallada

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.

Porcentaje de FEC ascendente incorregible

Descripción

Porcentaje de CW recibidos en este canal con errores incorregibles. Esto incluye todas las palabras de código, independientemente de que hayan formado parte de tramas destinadas a este dispositivo.

Fórmula

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

  • C = docsIfSigQUnerroreds

  • Comunidad Europea = docsIfSigQCorrecteds

  • UE = docsIfSigQUncorrectables

Regla neta

Los valores el >0.5% de CWs recibido son amarillo resaltado.

Los valores el >=1% de CWs recibido son con negrita y en color rojo.

Información neta

El porcentaje de los descensos para el CWs de la entrada muestra el porcentaje del CWs caído en la entrada, en relación con el número total de CWs recibido en esa interfaz. Se sugiere que esta relación de transformación esté debajo de 0.5% de todo el CWs de la entrada.

Nota: Los servicios “en tiempo real” específicos, tales como VoIP, pueden requerir una supervisión más rigurosa. Un valor el 1% incorregible FEC pudo todavía ser suficiente pérdida del paquete para causar los problemas de calidad de voz, dependiendo de si la pérdida es repartida o al azar.

Información detallada

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 hacia el procesador

Descripción

SNR según se lo percibe en este canal. En el CMTS, describe la media de relación señal/ruído del canal ascendente.

Fórmula

SNR = docsIfSigQSignalNoise / 10

Regla neta

El DB de los valores <27 es amarillo resaltado.

El DB de los valores <23 es con negrita y en color rojo.

Información neta

El DOCSIS especifica un mínimo CNR (digital equivalente al SNR) de DB 25. Dependiendo del perfil de modulación de la conexión en sentido ascendente configurado (QPSK o 16-QAM), el SNR mínimo de DB 25 puede necesitar ser aumentado.

Información detallada

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.

Ejemplo de cómo retirar un OID para contadores de módem FEC en una tarjeta de línea MC28U o 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 los contadores del codeword de este módem, usted primero necesita conseguir dos informaciones:

  • El índice de interfaz de SNMP de la interfaz de cable 6/0.

  • El docsIfCmtsServiceNewCmStatusIndex del módem.

Encuentre el ifIndex del cable 6/0 con 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"

Encuentre el docsIfCmtsServiceNewCmStatusIndex del módem con SID 50 en la interfaz con el ifIndex 10 (cable 6/0) con este comando:

% snmpwalk -cpublic 172.18.73.167 docsIfCmtsServiceNewCmStatusIndex.10.50

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

Ahora que usted tiene el docsIfCmtsServiceNewCmStatusIndex del módem (983090), usted puede encontrar estos contadores FEC:

  • Buen codewords recibido (docsIfCmtsCmStatusUnerroreds)

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

    Nota: El contador de Unerroreds ha aumentado algo en el tiempo desde que ejecutó el comando show interface cable.

  • Codewords corregido recibido (docsIfCmtsCmStatusCorrecteds)

    % snmpget -cpublic 172.18.73.167 docsIfCmtsCmStatusCorrecteds.983090
    
    DOCS-IF-MIB::docsIfCmtsCmStatusCorrecteds.983090 = Counter32: 0
    
  • Palabras de código recibidas no corregidas (docsIfCmtsCmStatusUncorrectables)

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

Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Información Relacionada


Document ID: 49780