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

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

La especificación de la interfaz de servicio de datos sobre cable (DOCSIS) describe los requisitos que debe cumplir cada operador de cable para transportar de forma fiable el tráfico de datos IP. Una característica importante de DOCSIS aborda la necesidad de proteger los datos IP frente a las deficiencias de ruido de 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).

Básicamente, la codificación FEC protege los datos IP y los mensajes de administración DOCSIS contra los errores de símbolo causados por el ruido y otras deficiencias. La única característica de FEC es que puede detectar errores de símbolos y corregirlos. Por lo tanto, DOCSIS especifica que todos los datos IP que se transmiten sobre una planta HFC deben pasar a través de un codificador Reed-Solomon, donde se agregan bytes de paridad adicionales a las tramas de datos para asegurarse de que estén protegidos contra errores  y sean menos propensos a las deficiencias.

Nota: FEC no funciona muy bien si los errores son creados por el ruido de impulso que crea muchos errores sucesivos. Los errores inducidos por el ruido de impulsos se abordan en el flujo descendente con el uso de entrelazado para hacer que los errores aparezcan dispersos, lo que FEC es efectivo a la hora de corregirlos. DOCSIS 2.0 ha agregado intercalación ascendente, lo que ayuda con este tipo de deterioro ascendente (US), pero no está disponible en los cablemódems 1.x (CM).

Sin duda, la trayectoria de retorno de la red de cable o ascendente es particularmente vulnerable al ruido y a las deficiencias 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 cableado no son la única medida de 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 de radiofrecuencia (RFI), supuestas características de transmisión de canal de radiofrecuencia ascendente, €  establece lo siguiente:

La relación portadora-interferencia más entrada (la suma de ruido, distorsión, distorsión de ruta común y modulación cruzada y la suma de las señales de ingreso discretas y de banda ancha, excluido el ruido de impulso) [no será] inferior a 25 dB.

En otras palabras, el mínimo recomendado de DOCSIS US CNR es de 25 dB. A los efectos de este documento, CNR se define como la relación portadora-ruido antes de que alcance el chip de demodulador (dominio RF), medido por un analizador de espectro. Por el contrario, SNR se define como la relación señal-ruido del chip receptor US del sistema de terminación de cablemódem (CMTS) después de que la portadora se haya demodulado para ofrecer una relación señal-ruido pura de banda base.

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. DOCSIS no especifica SNR, y la estimación SNR del CMTS no es lo mismo que la CNR que se mide con un analizador de espectro.

Este documento analiza el cálculo estimado de SNR ascendente del uBR y también los contadores FEC del uBR y muestra por qué estas dos variables deben evaluarse constantemente para asegurar la calidad de HSD en entornos HFC.

Relación señal-ruido

La estimación del SNR de uBR puede a veces ser engañosa, y debería considerarse solamente un punto de partida cuando se trata de verificar la integridad del espectro de RF ascendente. La lectura de SNR en la tarjeta de línea uBR MC16C es proporcionada por el chip de Estados Unidos, pero la lectura no es necesariamente un indicador confiable de € "real"  deficiencias de RF, como ruido de tipo impulsivo, ingreso discreto, etc. Eso no significa que la lectura de SNR de US no sea adecuada. En entornos con pocas deficiencias en el flujo ascendente (por ejemplo, ruido de impulso, ingreso, distorsión de trayectoria común, etc.), la estimación de SNR de EE. UU. realiza un seguimiento numérico de CNR en menos de un par de decibelios, cuando el CNR está en el rango de 15 a 25 dB. Es preciso con el ruido gaussiano blanco aditivo (AWGN) como único defecto; en el mundo real, sin embargo, la exactitud de estos números puede variar. Esto depende de la naturaleza de las deficiencias y refleja mejor la relación de error de modulación (MER) en lugar de la CNR.

Cómo obtener lecturas de SNR y CNR

Esta sección muestra algunos ejemplos de cómo obtener la estimación de SNR ascendente de Cisco uBR7200 y uBR10K (consulte también el Apéndice). Todos los comandos y resultados de comandos de la interfaz de línea de comandos (CLI) se obtienen de la versión 12.2(15)BC2a del software Cisco IOS®, a menos que se especifique lo contrario.

Tenga en cuenta que un  de € "tarjeta S" se refiere a una tarjeta de línea de cable con capacidades de análisis de espectro de hardware integradas, mientras que una € "tarjeta C" se refiere a una tarjeta de línea de 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.

Sugerencia: Cuando recopile la salida de los comandos CLI del software Cisco IOS con el propósito de resolver problemas o para reenviar al Soporte Técnico de Cisco, recuerde habilitar la indicación de fecha y hora del terminal exec, de modo que cada línea de salida del comando CLI esté acompañada de una indicación de fecha y hora y de la carga de CPU actual en el CMTS.

Para tarjetas 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 tarjetas C o tarjetas S sin grupos de 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 mantener el nivel de US establecido en el valor predeterminado de 0 dBmV y utilizar atenuadores externos para obligar a los módems a transmitir en niveles más altos, si es 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

Sugerencia: El comando phy se puede utilizar para informar SNR incluso si se informa CNR en el comando show controllers. Esto es especialmente útil porque SNR se informa luego de la cancelación de ingreso y CNR se informa antes de la cancelación de ingreso.

Nota: El SNR se enumera por módem en código EC con show cable modem detail.

El comando phy también enumera otros atributos de capa física si se configura remote-query. 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: No tenga en cuenta la entrada de microreflexión, porque esto es para DS y está limitado 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 de 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

Al agregar la dirección IP o MAC del módem al comando, se muestra la potencia de ráfaga del módem y el ancho del 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  *******

Esa salida muestra el ruido bajo la portadora y en otras frecuencias.

Además de la CLI, se pueden utilizar herramientas de administración de red basadas en SNMP, como Cisco Broadband Troudiagnooter (CBT), para mostrar el espectro de US y otros atributos. Además, CiscoWorks se puede utilizar para supervisar el SNR según lo informado por las tarjetas de línea de cable mediante el 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.

Nota: Las lecturas SNR de CM individuales sólo están disponibles en las tarjetas de línea MC5x20S y MC28U. Estas nuevas tarjetas de línea incorporan la cancelación de ingreso que puede mejorar el rendimiento pero puede dar lecturas SNR engañosas. Las lecturas SNR son posteriores a la cancelación de ingreso; por lo tanto, si la cancelación de ingreso elimina matemáticamente el ingreso, SNR podría informar mucho mejor que la relación portadora-interferencia real.

Nota: Cuando se utilizan grupos de espectro en una tarjeta S, el comando show controllers selecciona aleatoriamente las lecturas CNR de todos los CM de ese US, las cuales podrían ser ligeramente diferentes, dando la apariencia de un puerto US inestable o CNR.

Upstream Carriers (Portadoras ascendentes)

Un modo que vale la pena utilizar en un analizador de espectro es el modo de tramo cero. 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. La figura 1 muestra un analizador de espectro en cero span (dominio de tiempo) mientras se observa el tráfico ascendente de un CM.

Figura 1: Pantalla de extensión cero en un analizador de espectro

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

Figura 2: Medición de la amplitud ascendente de portadora modulada digitalmente

Zero-span también se puede utilizar para ver si los paquetes chocan entre sí por un mal tiempo o por un mal aislamiento del divisor de cabecera o del combinador. Un paquete destinado a un puerto ascendente CMTS está "filtrando" €  hacia otro flujo ascendente. Consulte los informes y documentos que aparecen en la sección 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 errores incorregibles de FEC (análogos a los errores de BER y PER deficientes) —aunque el SNR parezca estar por encima del estándar mínimo de DOCSIS— podría señalar otros problemas transitorios que deben abordarse. 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, la CNR medida en un analizador de espectro se vería bien, pero el CMTS informaría de otra manera.

Corrección de error de reenvío

Recuerde que la codificación FEC Reed-Solomon se utiliza para agregar bytes de paridad redundantes 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 medibles —ya sea corregibles o incorregibles errores FEC— rara vez deberían ocurrir. 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 recorte)

• reducción con láser

• ruido del impulso o interferencia de ingreso

• conexiones sueltas o intermitentes

• combinador ascendente escaso o aislación de divisor

• módems defectuosos

Existen dos métodos con los que se puede recopilar información 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 (tanto buenos como malos) recibidos por todos los puertos ascendentes asociados con un flujo descendente determinado.

• UnCorFECBlks: el número total de bloques FEC recibidos por todos los puertos ascendentes asociados con un flujo descendente determinado que estaban tan dañados por el ruido o el ingreso que no pudieron ser corregidos o recuperados por el algoritmo FEC.

• CorFECBlks: el número total de bloques FEC recibidos por todos los puertos ascendentes asociados con un flujo descendente determinado que fueron ligeramente dañados por el ruido o el ingreso y que podrían ser corregidos y recuperados por el algoritmo FEC.

Las ráfagas de mantenimiento de la estación aumentan el contador FECBlks aproximadamente 2 por x segundos, donde x es el intervalo de sondeo 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 el mantenimiento inicial cuando los módems se conectan. Debido a que el mantenimiento inicial ocurre durante el tiempo de contención, puede haber colisiones y subsiguientes errores FEC incorregibles.

Sugerencia: Asegúrese de que los módems no estén en la escala o que estén en línea antes de asumir que EE.UU. es inestable solo porque los contadores FEC incorregibles están aumentando. Además, el valor NoUwCollNoEngy podría aumentar si hay módems con problemas de temporizació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 estimarse tomando UnCorrFECBlks / FECBlks × 100. El contador FECBlks es el total de bloques FEC enviados, ya sean buenos o malos. Este resultado es para todo el dominio MAC (todo US). Es mejor observar los contadores entre un período de tiempo determinado para ver el delta.

Nota: Una de las desventajas de recopilar información de FEC mediante la CLI es que los enlaces UnCorFECBlks, CorFECBlks y el total de los enlaces FECB no se separan por flujo ascendente.

Para ver la información de FEC por flujo ascendente, debe utilizar OID SNMP. 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 borra los contadores show interface y show cable hop, pero no el contador 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 enfatizar, vale la pena repetir que los errores incorregibles de FEC resultan en paquetes descartados y muy probablemente causen un rendimiento de datos ascendente deficiente. Sin embargo, antes de que los acontecimientos lleguen a esta etapa crítica, hay predictores e indicaciones de que el rendimiento ascendente se está deteriorando. Los errores corregibles de FEC sirven como indicador de que el rendimiento de los datos ascendentes se está degradando y sirven como señal de advertencia de que los errores FEC incorregibles futuros son posibles.

Consejo: Si el contador Uncorr aumenta mucho más rápido que el contador Corr, el problema podría estar relacionado con el ruido de impulso. Si el contador Corr aumenta tan rápido (o más rápido que) el contador Uncorr, probablemente se relacione con AWGN o se trata de un problema de ingreso en estado estacionario como la banda ciudadana (CB), la radio de onda corta, la distorsión de ruta común (CPD), etc.

Cómo obtener contadores FEC a través de SNMP

Estos tres OID SNMP del archivo MIB SNMP de DOCS-IF-MIB se utilizan para recopilar y analizar los errores FEC (no se ha realizado ningún error, se ha corregido y no se puede corregir; consulte también 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.

Debido a que estas tres MIB son valores absolutos (en función del número total de bloques de datos FEC que recibe el CMTS), el cálculo del porcentaje proporciona una mejor imagen del rendimiento real del flujo ascendente. Estas fórmulas deben utilizarse:

• _Cx = docsIfSigQUnerroreds en tiempo x

• _Ecx = docsIfSigQCorrecteds en el tiempo x

• _Eux = docsIfSigQUncorrectables a la vez x

% Correcto = [(Ec1 - Ec0)/ [(Eu1 - Eu0) + (Ec1 - Ec0) + (C1 - C 0)] * 100

% Incorregible = [(Eu1 - Eu0)/ [(Eu1 - Eu0) + (Ec1 - Ec0) + (C1 - C 0)]] * 100

Nota: Los caracteres no corregibles más los errores y las correcciones son iguales al número total de palabras clave (CW; también conocidos como bloques de datos FEC) recibidos en este US, incluidos todos los CW, independientemente de si formaban parte o no de tramas destinadas al CMTS. El tamaño de una CW es determinado por el perfil de modulación.

Contadores FEC por módem

Si se descarta un paquete US, aumenta un contador Uncorr FEC. Esto ocurre en la capa física. Puede preguntar cómo el CMTS distingue un paquete descartado, si no tiene la oportunidad de ver la ID de servicio (SID) o la dirección de origen (capa 2). Sin embargo, el SID CM se incluye en el encabezado DOCSIS.

Ejemplo de una ráfaga de Estados Unidos:

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

Se agrega todo entre { y }, se corta en CW según el perfil de modulación y, a continuación, se agrega 2×T 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 lograrlo es utilizar el planificador del CMTS, que sabe el tiempo en que ciertos paquetes llegarían de 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. También puede recuperarlos a través de SNMP usando estos OID:

• Buenas palabras de código recibidas (docsIfCmtsCmStatusUnerroreds)

• Palabras de código corregidas recibidas (docsIfCmtsCmStatusCorrecteds)

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

Nota: Actualmente, esto solo es relevante para 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 de este módem y los contadores se actualizan 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
     

Observe que el comando show cable hop está informando de otros errores FEC Uncorr. 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 por CM mediante el sondeo de las MIB y el uso del fotógrafo de tráfico de router múltiple (MRTG) u otro software como Cisco BT. Esto se podría utilizar para ver si determinados módems tienen un retraso de grupo deficiente, microreflexiones, etc. Esto sería algo que sólo afecta 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. Estos son paquetes, que son diferentes de los CW FEC. Un paquete podría constar de muchos CW.

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:

• broadcasts: tramas de difusión recibidas.

• multidifusión: tramas multicast recibidas.

• unicasts: tramas de unidifusión recibidas.

• descartes: solo aumenta en la tarjeta de línea MC5x20S. Enumera los paquetes descartados debido a varias condiciones de error que son específicas de la tarjeta, no a la trama real.

• errores: el total de un rango completo de errores, muchos de los cuales no importan. Los errores que este valor cuenta corresponden a las tarjetas basadas en BCM3210, como MC16C y MC28C:

  • El número de ranuras ascendentes asignadas donde el preámbulo y la palabra única no se recibieron correctamente.

  • El número recibido de tramas incorregibles.

  • Colisiones en las oportunidades de "solicitud" de ancho de banda.

  • Colisiones en las ranuras de "solicitud/datos" (estos tipos de ranuras no se producen en los CMTS de Cisco).

  • Tramas dañadas recibidas durante las oportunidades de "solicitud" de ancho de banda.

  • Tramas dañadas recibidas durante las ranuras de "solicitud/datos".

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

  Para tarjetas de línea basadas en JIB como MC5x20 y 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 ascendentes con problemas de HCS.

  • Tramas de flujo ascendente con errores CRC.

  • CW recibidos incorregibles.

  • Colisiones en la solicitud de ancho de banda IUC.

• protocolo desconocido: número de tramas recibidas que no eran IP, protocolo de resolución de direcciones (ARP) o protocolo de punto a punto sobre Ethernet (PPPoE). Este contador también incluye tramas con encabezados DOCSIS mal formados u opciones de encabezado inválidas.

• entrada de paquetes: total de difusiones, multidifusión y unidifusión.

• incorregible: número total de tramas que tenían al menos una CW FEC incorregible dentro de ellas. 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 las tarjetas basadas en BCM3210 como MC16C y MC28C, este es el número de tramas dañadas recibidas en intervalos de "solicitud" o "medición" de ancho de banda. Esto convierte a este número en un subconjunto de los números en errores.

  • Tramas dañadas recibidas durante las oportunidades de "solicitud" de ancho de banda

  • Tramas dañadas recibidas durante las ranuras de "solicitud/datos".

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

  Para las tarjetas basadas en JIB como MC5x20, este contador no aumenta en absoluto.

• microreflexiones: número de microreflexiones; siempre se establece en 0.

Los errores y los contadores de ruido no cuentan solamente las tramas dañadas; también cuentan cosas como las colisiones iniciales de solicitudes de medición de distancias y las colisiones de solicitudes de ancho de banda. Por lo tanto, un contador de ruido en aumento no siempre significa que existe un problema. Esto podría significar que el cliente tiene muchos módems tratando de conectarse o tiene módems tratando de hacer más transmisiones (lo que lleva a más 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

A través de la experiencia y las pruebas de laboratorio realizadas por el grupo de servicios avanzados y respuesta rápida de Cisco, estas son algunas observaciones sobre FEC y el 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 esto último, un paquete destinado a un puerto ascendente CMTS está "filtrando" a otro flujo ascendente debido al aislamiento deficiente.

• Un gran aumento de errores incorregibles FEC da lugar a problemas de calidad de voz.

• Los errores FEC corregibles se ven a medida que aumenta el nivel de ruido. Los errores FEC corregibles no dan lugar a caídas de paquetes o a una calidad de voz deficiente, siempre y cuando no haya errores FEC incorregibles que los acompañen.

• El aumento de los T-bytes FEC en el perfil de modulación US puede ayudar hasta un punto determinado, pero depende de la fuente de ruido. La cobertura FEC del 7 al 10% parece óptima.

De las observaciones anteriores se desprende claramente que resulta útil sondear el CMTS para detectar los errores FEC incorregibles. El cable de Voz sobre IP (VoIP) es particularmente sensible a los errores FEC incorregibles. Si el porcentaje de errores FEC incorregibles es lo suficientemente alto, se experimentan problemas de calidad de voz, mientras que los datos IP pueden verse mínimamente afectados.

Por último, si la lectura del SNR del chip de EE. UU. es engañosa cuando se introducen deficiencias RF transitorias rápidas (como se ha dicho anteriormente), pero todavía se producen errores FEC incorregibles, solucionar el problema puede resultar considerablemente más complejo.

La figura 3 resalta un ejemplo de un US que experimenta un SNR bajo al mismo tiempo que está experimentando errores FEC incorregibles y corregibles, enfatizando la estrecha relación entre estos dos parámetros al medir el rendimiento ascendente.

Figura 3: Errores SNR y FEC con el tiempo

 

El primer gráfico muestra el porcentaje de error FEC incorregible y corregible, mientras que el gráfico inferior indica lecturas SNR deficientes en la misma instancia en el tiempo. Una rápida verificación de la portadora modulada digitalmente ascendente en un analizador de espectro (como el HP8591C de Agilent) probablemente mostraría ruido en el canal a niveles bastante altos. Los problemas de RF ascendentes de naturaleza impulsiva se pueden confirmar utilizando equipos de prueba de terceros (como Hukk CM1000—consulte el sitio web de telecomunicaciones Sunrise—o Acterna DSAM) que pueden medir la tasa de error de bloque ascendente (similar a BER). Esto verificaría que probablemente exista un problema de RF, incluso cuando la lectura del SNR estadounidense parece ser buena.

La conclusión es que si la lectura del SNR estadounidense parece ser buena, entonces no asuma automáticamente que el RF está bien. Podría ser necesaria una pequeña investigación con el equipo de prueba adecuado para determinar exactamente qué está pasando en el dominio de RF. Las probabilidades son bastante buenas de que el espectro de RF no sea tan limpio como se supuso primero.

Appendix

Esta sección detalla los parámetros ascendentes a 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 = [(Ec1 - Ec0)/ [(Eu1 - Eu0) + (Ec1 - Ec0) + (C1 - C 0)] * 100

• C = docsIfSigQUnerroreds

• _Ec = docsIfSigQCorrecteds

• _Eu = docsIfSigQUncorrectables

Regla de red

Los valores >2,5% de los paquetes recibidos se resaltan en amarillo.

Valores >=5% de los paquetes recibidos están negrita roja.

Información de red

Porcentaje de CW de entrada con errores FEC corregibles, relativos al número total de CW recibidos en esa interfaz. Se sugiere que esta proporción sea inferior al 5% de todos los CW de 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

%Incorregible = [(Eu1 - Eu0)/ [(Eu1 - Eu0) + (Ec1 - Ec0) + (C1 - C 0)]] * 100

• C = docsIfSigQUnerroreds

• _Ec = docsIfSigQCorrecteds

• _Eu = docsIfSigQUncorrectables

Regla de red

Los valores >0,5% de los CW recibidos se resaltan en amarillo.

Los valores >=1% de los CW recibidos están negrita en rojo.

Información de red

El porcentaje de caídas para los CW de entrada muestra el porcentaje de CW caídos en la entrada, en relación con el número total de CW recibidos en esa interfaz. Se sugiere que esta proporción sea inferior al 0,5% de todos los CW de entrada.

Nota: Los servicios "en tiempo real" específicos, como VoIP, pueden requerir una supervisión más estricta. Un valor FEC 1% incorregible podría ser aún suficiente pérdida de paquetes para causar problemas de calidad de voz, dependiendo de si la pérdida es ráfaga o aleatoria.

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 el promedio señal-ruido del canal ascendente.

Fórmula

SNR = docsIfSigQSignalNoise / 10

Regla de red

Los valores <27 dB se resaltan en amarillo.

Los valores <23 dB son negrita roja.

Información de red

DOCSIS especifica un CNR mínimo (equivalente digital a SNR) de 25 dB. Según el perfil de modulación ascendente configurado (QPSK o 16-QAM), es posible que deba aumentarse el SNR mínimo de 25 dB.

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 de palabras de código de este módem, primero debe obtener dos datos:

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

• El docsIfCmtsServiceNewCmStatusIndex del módem.

Busque 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"

Busque el docsIfCmtsServiceNewCmStatusIndex del módem con SID 50 en la interfaz con 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 tiene el docsIfCmtsServiceNewCmStatusIndex del módem (983090), puede encontrar estos contadores FEC:

• Buenas palabras de código recibidas (docsIfCmtsCmStatusUnerroreds)

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

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

• Palabras de código corregidas recibidas (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
           

Información Relacionada

• Introducción al caudal de datos en un mundo DOCSIS
• Perfiles de modulación ascendentes para las tarjetas de línea para cable
• Especificación de interfaz de frecuencia de radio DOCSIS
• Compatibilidad con tecnología de cable de banda ancha
• Soporte Técnico - Cisco Systems