Câble haut débit : Réseaux hybrides fibre-coaxial (HFC) en radiofréquence (RF)

Erreurs FEC ascendantes et SNR comme moyens d'assurer la qualité et le débit des données

18 juin 2016 - Traduction automatique
Autres versions: PDFpdf | Anglais (19 décembre 2015) | Commentaires


Contenu


Introduction

L'exécution d'un réseau de données à grande vitesse (HSD) sur un réseau de câblage hybride fibre optique-câble coaxial (HFC) exige un important niveau de contrôle de la qualité afin d'assurer l'intégrité des données et le plus haut niveau de débit de données. Les deux méthodes généralement reconnues par lesquelles les câblodistributeurs peuvent mesurer la qualité des données sont par la surveillance du taux d'erreur sur les bits (TEB) ou du taux d'erreur de paquet (TEP).

Le DOCSIS (DOCSIS) trace les grandes lignes des conditions requises que chaque câblo-opérateur doit mettre à jour afin de transporter sûrement le trafic de données IP. Une importante caractéristique de DOCSIS satisfait la nécessité de protéger des données IP contre des problèmes de bruit de Radiofréquence (RF). Les utilisations de la caractéristique DOCSIS d'aider à mettre à jour l'intégrité des données IP au-dessus des usines de câble HFC est codage de la correction d'erreurs de transfert de Reed-Solomon (FEC).

Essentiellement, le codage FEC protège des données IP et des messages de gestion DOCSIS contre des erreurs de symbole provoquées par bruit et d'autres problèmes. La fonctionnalité unique de la FEC est qu'elle peut détecter des erreurs de symbole et également les corriger. Ainsi, DOCSIS spécifie que toutes les données IP qui sont transmises au-dessus d'une usine HFC devraient traverser un encodeur de Reed-Solomon, où des octets supplémentaires de parité sont ajoutés aux trames de données pour s'assurer qu'ils « erreur-sont protégés » et des problèmes moins enclins.

Remarque: La FEC ne fonctionne pas très bien si les erreurs sont créées par le bruit impulsif qui crée beaucoup d'erreurs en succession. des erreurs impulsion Impulsion bruit sont adressées sur l'en aval avec l'utilisation de l'interfoliage de faire les erreurs apparaître étendent, qui la FEC est efficace à la fixation. Le DOCSIS 2.0 a ajouté l'interfoliage en amont — qui aide avec ce type de problème en amont (US) — mais il n'est pas disponible sur les Modems câble 1.x (CMS).

Sans aucun doute, le chemin de retour du réseau câblé ou l'en amont est particulièrement vulnérable pour ébruiter et des problèmes relatifs. Un tel bruit peut être impulsion, bruit d'entrée, bruit thermique, découpage laser, et ainsi de suite. Sans codage FEC, les possibilités d'un paquet étant abandonné en raison des erreurs de bit sont considérables. Les erreurs FEC sur une usine de câble ne sont pas la seule mesure de qualité. Il y a d'autres variables qui doivent être considérées, comme le rapport porteuse/bruit (le CNR).

La norme DOCSIS inclut des paramètres recommandés pour la représentation en aval et en amont de la télévision par câble rf. Spécifiquement, section 2.3.2 de la spécification de l'interférence de radio frequency (IFR), « a assumé des caractéristiques en amont de transmission de la Manche rf, » énonce ceci :

Transporteur-à-interférence plus le rapport d'entrée (la somme de bruit, déformation, déformation de commun-chemin et croix-modulation et la somme du d'entrée discret et large bande signale, bruit impulsif exclu) [ne soyez pas] moins de 25 dB.

En d'autres termes, le CNR recommandé par minimum DOCSIS USA est 25 dB. Afin de ce document, le CNR est défini comme rapport porteuse/bruit avant qu'il atteigne la puce de démodulateur (domaine rf), comme mesuré par un analyseur de spectre. Réciproquement, le SNR est défini comme rapport signal/bruit de la puce de récepteur des USA du système de terminaison par modem câble (CMTS) après que le transporteur ait été démodulé pour donner une bande de base pure, rapport signal/bruit.

Ainsi, quand on regarde la lecture SNR sur Cisco uBR7246 et voit un nombre comme 30 dB, il est facile de supposer que l'en amont semble rencontrer ou même dépasser DOCSIS et que les choses dans le monde rf sont bien. Ce n'est pas toujours le cas, cependant. DOCSIS ne spécifie pas le SNR, et l'évaluation SNR du CMTS n'est pas la même chose que le CNR celui-là mesure avec un analyseur de spectre.

Ce document discute l'en amont SNR de l'ubr a estimé que le calcul et également la FEC de l'ubr pare et affiche pourquoi ces deux variables devraient être constamment évaluées pour assurer la qualité HSD au-dessus des environnements HFC.

Rapport signal/bruit

L'évaluation SNR de l'ubr peut parfois être fallacieuse, et devrait être considérée seulement un point commençant quand il s'agit de vérifier l'intégrité du spectre de l'en amont rf. La lecture SNR sur le linecard de l'ubr MC16C est fournie par la puce des USA, mais la lecture n'est pas nécessairement un indicateur fiable des problèmes « du monde réel » rf, tels que le bruit impulsif de type, d'entrée discret, et ainsi de suite. Ce n'est pas de dire que la lecture des USA SNR n'est pas précise. Dans les environnements avec peu de problèmes sur l'en amont (par exemple, bruit impulsif, d'entrée, déformation commune de chemin, et ainsi de suite), l'évaluation des USA SNR dépiste numériquement le CNR dans moins que quelques décibels, quand le CNR est dans la plage du dB 15 à 25. Il est précis avec le bruit gaussien blanc additif (AWGN) comme seul problème ; dans le monde réel, cependant, la précision de ces nombres peut varier. Ceci dépend de la nature des problèmes et reflète mieux le rapport d'erreur de modulation (MER) plutôt que le CNR.

Comment obtenir des lectures SNR et CNR

Cette section affiche quelques exemples de la façon obtenir l'évaluation de l'en amont SNR de l'uBR7200 de Cisco et uBR10K (voyez également l'annexe). Toutes les commandes et sorties de commande de l'interface de ligne de commande (CLI) sont prises de la version de logiciel 12.2(15)BC2a de ½ du ¿  de Cisco IOSïÂ, sauf indication contraire.

Notez qu'une « carte S » se rapporte à un linecard de câble avec des capacités intégrées d'analyse du spectre de matériel, tandis qu'une « carte de C » se rapporte à un linecard de câble sans cette capacité. Sous certaines configurations, la carte S signale le CNR au lieu du SNR, parce qu'elle a le matériel intégré pour remplir des fonctions d'analyse du spectre.

Conseil : En recueillant la sortie des commandes CLI de logiciel de Cisco IOS aux fins du dépannage ou pour expédier au support technique de Cisco, souvenez-vous pour activer l'horodateur prompt de terminal exec, de sorte que chaque ligne de sortie de commande CLI soit accompagnée d'un horodateur et du chargement CPU de courant sur le CMTS.

Pour des cartes 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

Pour des cartes de C ou des cartes S sans groupes de spectre assignés :

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

Il est recommandé que vous gardez le positionnement de niveau des USA au par défaut de 0 dBmV et utilisez les atténuateurs externes pour forcer des Modems pour transmettre aux niveaux supérieurs, s'il y a lieu.

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

Conseil : La commande phy peut être utilisée pour signaler le SNR même si le CNR est signalé dans la commande de shows controllers. C'est particulièrement utile parce que le SNR est signalé après que l'annulation d'entrée soit exécutée et le CNR est signalé avant l'annulation d'entrée.

Remarque: Le SNR est répertorié par code EC de modem in avec le détail de show cable modem.

La commande phy répertorie également d'autres attributs de couche physique si la distant-requête est configurée. Ces trois lignes de code peuvent être écrites pour lancer la distant-requête :

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

Trois secondes ont été utilisées pour une réponse rapide, qui ne peut être recommandée dans un CMTS fortement chargé. La chaîne de caractères de la communauté en lecture seule par défaut dans des la plupart des Modems est publique.

Remarque: Négligez l'entrée de microreflection, parce que c'est pour le DS et est limité par la précision de l'implémentation du constructeur 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

Listes de ces commandes SNR en utilisant la carte courant alternatif. Quand une carte S est utilisée et des groupes de spectre sont assignés, le CNR est signalé. La commande bavarde de mac-address de show cable modem fonctionne aussi bien.

Comment visualiser le plancher de bruit

Les cartes S te permettent également pour visualiser le plancher de bruit avec cette commande :

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

Ajouter l'IP de modem ou l'adresse MAC à la commande affiche l'alimentation de rafale de modem et la largeur de 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  *******

Cette sortie affiche le bruit sous le transporteur et à d'autres fréquences.

En plus du CLI, des outils de gestion de réseau basés sur SNMP tels que le Cisco Broadband Troubleshooter (CBT) peuvent être utilisés pour afficher le spectre et autre des USA des attributs. En outre, des CiscoWorks peuvent être utilisés pour surveiller le SNR comme signalés par des linecards de câble utilisant l'objet de 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.

Remarque: Les différentes lectures cm SNR sont seulement disponibles sur les linecards MC5x20S et MC28U. Ces nouveaux linecards incorporent l'annulation d'entrée qui peut améliorer la représentation mais peuvent donner les lectures trompeuses SNR. Les lectures SNR sont après l'annulation d'entrée ; ainsi, si l'annulation d'entrée retire mathématiquement le d'entrée, puis le SNR pourrait signaler bien mieux que le rapport porteuse/interférence réel.

Remarque: En utilisant des groupes de spectre sur une carte S, les shows controllers commandent sélectionne aléatoirement des lectures CNR de tout le CMS sur cela les USA, qui pourraient être légèrement différents, donnant l'apparence d'un port des USA ou d'un CNR instable.

Transporteurs en amont dans la Zéro-envergure

Une valeur de mode utilisant dans un analyseur de spectre est le mode de zéro-envergure. C'est le mode de domaine de temps où l'affichage est amplitude contre le temps plutôt que l'amplitude contre la fréquence. Ce mode est très salutaire en visualisant le trafic de données qui est bursty en nature. La figure 1 affiche un analyseur de spectre dans la zéro-envergure (domaine de temps) tout en regardant le trafic ascendant d'un cm.

Figure 1 ? Affichage de Zéro-envergure sur un analyseur de spectre

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

Des paquets de données peuvent être vus dans la figure 1, avec des demandes de modem et le bruit impulsif. C'est très utile pour mesurer les niveaux numériques moyens et observer le bruit et le d'entrée, comme vu dans la figure 2.

Figure 2 ? Mesure de Zéro-envergure d'amplitude de transporteur modulée par Digital d'en amont

return_path_monitor_2.gif

la Zéro-envergure peut également être utilisée pour voir si les paquets se heurtent les uns avec les autres de la mauvaise synchronisation ou du distributeur de headend ou de l'isolation pauvre de combinateur. Un paquet destiné à un port ascendant CMTS « coule » sur un autre en amont. Référez-vous aux livres blancs et aux documents répertoriés dans la section « de l'information relative » de ce document. Référez-vous à connecter le routeur de gamme Cisco uBR7200 à la tête de réseau câblé pour une description de la procédure de mesure de zéro-envergure.

Pratiquement tous les problèmes rf mentionnés jusqu'ici dans ce document peuvent dégrader la représentation en amont et se manifester comme débit de données pauvre sans nécessairement être reflété comme bas SNR. Observer des erreurs FEC incorrigibles (analogues aux JUJUBES pauvres et PAR) — quoique le SNR semble être au-dessus de la norme du minimum DOCSIS — pourrait indiquer d'autres questions passagères qui doivent être abordées. Il a pu également y a un escroc cm entraînant des erreurs et une lecture pauvre SNR pour tout l'autre CMS sur les mêmes USA. Dans ce cas, le CNR comme mesuré sur un analyseur de spectre regarderait bien, mais le CMTS signalerait autrement.

Correction d'erreurs de transfert

Rappelez-vous que le codage de Reed-Solomon FEC est utilisé pour ajouter les octets redondants de parité aux paquets de données, afin de permettre la détection et la correction des erreurs de rafale introduites par l'usine de câble.

Dans un monde idéal, les erreurs de bit mesurables — corrigible ou des erreurs FEC incorrigibles — devraient rarement jamais se produire. Quand les erreurs FEC incorrigibles existent, cependant, les effets peuvent être graves et peuvent sont provoqué par par un certain nombre de différents facteurs. C'est une liste d'événements connus qui pourraient introduire des erreurs FEC incorrigibles sur l'en amont et qui devraient être considérés des erreurs du pour le dépannage FEC :

  • interférence d'émetteur de champ

  • surcharge d'amplificateur (compactage, qui est une forme du découpage)

  • découpage laser

  • interférence impulsive de bruit ou d'entrée

  • connexions lâches ou intermittentes

  • isolation en amont pauvre de combinateur ou de distributeur

  • Modems défectueux

Il y a deux méthodes avec lesquels peut collecter des informations FEC :

  • CLI

  • Interrogation de l'identifiant d'objet SNMP (OID)

C'est un exemple de la façon collecter des informations FEC utilisant le CLI (voyez également l'annexe) :

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 — Le nombre total de blocs FEC (bon et mauvais) reçus par tous les ports ascendants a associé avec un en aval indiqué.

  • UnCorFECBlks — Le nombre total de blocs FEC reçus par tous les ports ascendants a associé avec un en aval indiqué qui ont été ainsi corrompus par bruit ou d'entrée qu'ils ne pourraient pas être corrigés ou récupérés par l'algorithme FEC.

  • CorFECBlks — Le nombre total de blocs FEC reçus par tous les ports ascendants a associé avec un en aval indiqué qui ont été légèrement corrompus par bruit ou d'entrée et qui pourraient être corrigés et récupérés par l'algorithme FEC.

Les rafales de maintenance de station incrémentent le FECBlks contre- par approximativement 2 par seconde x, où x est l'intervalle de sondage minimum (comme présenté dans la commande de saut de câble d'exposition) divisé par 1000. La requête distante incrémente également ce compteur, de même que fait maintenance initiale quand les Modems sont livré en ligne. Puisque la maintenance initiale se produit pendant le temps de conflit, il pourrait y avoir des collisions et des erreurs FEC incorrigibles ultérieures.

Conseil : Soyez sûr que les Modems sont ne s'étendant pas ou être livré en ligne avant d'assumer les USA est instable juste parce que les compteurs uncorrectable FEC incrémentent. En outre, la valeur de NoUwCollNoEngy pourrait augmenter s'il y a des Modems avec des questions de synchronisation. Seul Word est spécifique à BRCM, pas DOCSIS, et est les derniers octets du préambule.

Un pourcentage peut être estimé le ½ 100 en prenant d'UnCorrFECBlks/FECBlks ï ¿ Â. Le compteur de FECBlks est tous les blocs FEC envoyés, si bon ou mauvais. Cette sortie est pour le domaine entier de MAC (tout l'USs). Il est le meilleur de regarder les compteurs entre une période de set time voir le delta.

Remarque: Un inconvénient de collecter les informations FEC utilisant le CLI est que l'UnCorFECBlks, le CorFECBlks, et tout le FECBlks ne sont pas séparés par en amont.

Afin de regarder les informations du par-en amont FEC, vous devriez utiliser SNMP OID. Vous pouvez également utiliser la commande de saut de câble d'exposition de visualiser corrigible ou des erreurs FEC incorrigibles par port ascendant, mais pas tous les blocs 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

Remarque: Les compteurs clairs commandent seulement des espaces libres l'interface d'exposition et affichent des compteurs de saut de câble, mais pas les shows controllers contre-. Les compteurs de contrôleur peuvent seulement être effacés si le CMTS est rechargé ou l'interface alimentation-est faite un cycle avec cette commande :

ubr# cable power off slot/card

Pour l'accent, il vaut répéter ce des erreurs FEC incorrigibles ont comme conséquence les paquets relâchés et entraîneront très probablement le débit de données en amont pauvre. Avant que les événements obtiennent à cette étape essentielle, cependant, il y a des predictors et des indications que la représentation en amont détériore. Les erreurs corrigibles FEC servent d'indicateur que le débit de données en amont dégrade et servir de signal d'avertissement que les futures erreurs FEC incorrigibles sont possibles.

Conseil : Si le compteur d'Uncorr incrémente beaucoup plus rapide que le compteur de Corr, alors le problème pourrait être lié au bruit impulsif. Si le compteur de Corr incrémente comme rapide (ou plus rapide que) le compteur d'Uncorr, alors on le lie probablement à AWGN ou c'est un problème équilibré d'entrée comme la bande de citoyen (CB), radio d'onde courte, la déformation commune de chemin (DPC), et ainsi de suite.

Comment obtenir des compteurs FEC par le SNMP

Ces trois SNMP OID à partir du fichier MIB SNMP DOCS-IF-MIB sont utilisés pour collecter et analyser des erreurs FEC (FEC unerrored, corrigée, et uncorrectable — voyez également l'annexe) :

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.

Puisque ces trois MIB sont des valeurs absolues (basées sur le nombre total de blocs de données FEC que le CMTS reçoit), le calcul du pourcentage fournit une meilleure image de représentation en amont réelle de débit. Ces formules devraient être utilisées :

  • CX = docsIfSigQUnerroreds au temps X

  • E laCX = les docsIfSigQCorrecteds au temps X

  • Ux = docsIfSigQUncorrectables E au temps X

% corrigibles = [(Ec1 ? Ec0)/ [(Eu1 ? Eu0) + (Ec1 ? Ec0) + (C1 ? C0)]] * 100

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

Remarque: Uncorrectable plus des unerroreds plus des correcteds égalez le nombre total de mots de passe (CWs ; également connu en tant que blocs de données FEC) reçus sur les ces USA, y compris tout le CWs, s'ils faisaient partie de trames destinées pour le CMTS. La taille d'une onde entretenue est déterminée par le profil de modulation.

Compteurs du Par-modem FEC

Si un paquet des USA est lâché, il incrémente un compteur d'Uncorr FEC. Ceci se produit dans la couche physique. Vous pourriez demander comment le CMTS distingue un paquet relâché, s'il n'a pas une occasion de voir l'ID de service (SID) ou l'adresse source (couche 2). Cependant, le cm SID est inclus dans l'en-tête DOCSIS.

Exemple des USA éclatés :

(préambule) + {(hdr de docsis = 6 octets) + (BPI+, hdr étendu de docsis = 4 à 7 octets) + 1500 Ethernets + en-tête Ethernet 18} + (guardband)

Tout entre {et} est ajouté, coupe dans CWs a basé sur le profil de modulation, puis 2ï le ½ T du ¿  est ajouté à chaque onde entretenue. Tellement techniquement, si le mot de passe spécifique qui tient le SID est relâché, comment le CMTS peut-il distinguer de quel modem il a été envoyé ? Une manière de réaliser ceci est d'utiliser le programmateur du CMTS, qui connaît le moment où certains paquets arriveraient des Modems spécifiques.

Vous pouvez afficher les valeurs FEC répertoriées par modem utilisant la commande bavarde de compteur de SID-nombre de cableport/emplacement Sid d'interface d'exposition. Vous pouvez également les récupérer par le SNMP utilisant ces OID :

  • Bons mots de passe reçus (docsIfCmtsCmStatusUnerroreds)

  • Mots de passe corrigés reçus (docsIfCmtsCmStatusCorrecteds)

  • Mots de passe non corrigés reçus (docsIfCmtsCmStatusUncorrectables)

Remarque: C'est actuellement seulement approprié pour les linecards MC28U et 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

C'est spécifique à ce modem et les compteurs mettent à jour approximativement toutes les 10 secondes.

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

Notez que la commande de saut de câble d'exposition signale une erreurs supplémentaires d'Uncorr FEC. C'est probablement parce qu'on a abandonné une onde entretenue qui s'est avérée justement appartenir à un autre modem.

Il serait intéressant de voir un graphique des erreurs par-cm FEC en votant le MIB et en utilisant le grapher du trafic de multi-routeur (MRTG) ou de tout autre logiciel tel que Cisco BT. Ceci pourrait être utilisé pour voir si les Modems particuliers ont le délai de groupe pauvre, des microreflections, et ainsi de suite. Ce serait quelque chose qui affecte seulement un modem spécifique.

Compteurs en amont de paquet

Une autre commande qui répertorie des erreurs est la commande d'en amont de l'interface cable5/1/0 d'exposition. C'est des paquets, qui sont différents de FEC CWs. Un paquet a pu se composer beaucoup de 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)

Ce sont les définitions des termes :

  • annonce — Trames reçues d'émission.

  • Multidiffusions — Trames reçues de Multidiffusion.

  • unicasts — Trames de monodiffusion reçues.

  • jette — Seulement incréments sur le linecard MC5x20S. Répertorie des paquets jetés en raison des diverses conditions d'erreurs qui sont spécifiques à la carte, pas à la trame réelle.

  • erreurs — Le total de toute une gamme d'erreurs, beaucoup dont n'importez pas. Les erreurs que cette valeur compte sont pour des cartes BCM3210-based comme le MC16C et le MC28C :

    • Le nombre d'emplacements en amont alloués où le préambule et le seul Word n'ont pas été reçus correctement.

    • Le nombre de trames uncorrectable reçues.

    • Collisions dans les occasions de « demande » de bande passante.

    • Collisions dans des emplacements de « demande/données » (ces types d'emplacements ne se produisent pas sur Cisco CMTSs).

    • Trames endommagées reçues pendant les occasions de « demande » de bande passante.

    • Trames endommagées reçues pendant les emplacements de « demande/données ».

    • Le nombre de demandes de télémétrie endommagées entendues.

    Pour les linecards basés sur potence comme le MC5x20 et le MC28U :

    • Trames en erreur en amont qui, pour quelque raison, ne sont pas classifiées en tant qu'ordre de contrôle d'en-tête (HCS) ou le contrôle de redondance cyclique (CRC) errored.

    • Trames en amont avec des problèmes HCS.

    • Trames en amont avec des erreurs de CRC.

    • CWs Uncorrectable a reçu.

    • Collisions dans la demande de bande passante IUC.

  • protocole inconnu — Le nombre de trames a reçu qui n'étaient pas IP, Protocole ARP (Address Resolution Protocol), ou protocole de point-à-point au-dessus des Ethernets (PPPoE). Ce compteur inclut également des trames avec les en-têtes mal formées DOCSIS ou les options non valides d'en-tête.

  • paquets entrés — Total d'émissions, de Multidiffusions, et d'unicasts.

  • uncorrectable — Nombre total de trames qui ont eu au moins une onde entretenue FEC uncorrectable dans elles. Ce champ affiche le NON APPLICABLE pour le MC5x20 et le 28U. Utilisez la colonne d'erreurs d'Uncorr FEC en saut de câble d'exposition sorti à la place, pour avoir une idée au sujet des erreurs non corrigibles.

  • bruit — Pour des cartes BCM3210-based comme le MC16C et le MC28C, c'est le nombre de trames endommagées reçues dans la bande passante « demande » ou intervalles « de rangement ». Ceci fait à ce nombre un sous-ensemble des nombres dans les erreurs.

    • Trames endommagées reçues pendant les occasions de « demande » de bande passante

    • Trames endommagées reçues pendant les emplacements de « demande/données ».

    • Le nombre de demandes de télémétrie endommagées entendues.

    Pour les cartes basées sur potence comme le MC5x20 ce compteur n'incrémente pas du tout.

  • microreflections — Nombre de microreflections ; placez toujours à 0.

Les erreurs et les compteurs de bruit ne comptent pas simplement les trames corrompues ; ils comptent également des choses comme des collisions de demande de négociation du débit initiale et des collisions de demande de bande passante. Ainsi, un bruit de incrémentation contre- ne signifie pas toujours qu'il y a un problème. Il pourrait juste signifier que le client a beaucoup de Modems essayant d'être livré en ligne ou a des Modems essayant de faire plus de transmissions (menant à plus des collisions mentionnées). Le compteur de bruit est réellement un sous-ensemble du compteur d'erreurs parce que le bruit inclut les trois derniers composants du compteur d'erreurs.

Conclusion

Par une expérience et l'essai en laboratoire faits par le groupe anticipé des services et du Rapid Response de Cisco, ce sont quelques observations concernant la FEC et la représentation en amont pauvre :

  • La présence des erreurs FEC incorrigibles est une bonne mesure quand le bruit obtient à un de niveau intolérable ou quand les paquets se heurtent les uns avec les autres de la mauvaise synchronisation ou du distributeur de headend ou de l'isolation pauvre de combinateur. En ce qui concerne ce dernier, un paquet destiné à un port ascendant CMTS « coule » sur un autre en amont en raison de l'isolation pauvre.

  • Une grande augmentation des erreurs FEC incorrigibles a comme conséquence les problèmes de qualité voix.

  • Des erreurs corrigibles FEC sont vues à mesure que le niveau du bruit est augmenté. Les erreurs corrigibles FEC n'ont pas comme conséquence les pertes de paquets ou la médiocre qualité de voix, tant que il n'y a aucune erreur FEC incorrigible de accompagnement.

  • L'augmentation des T-octets FEC dans le profil de modulation des USA peut aider jusqu'à un certain point, mais elle dépend de la source de bruit. Sept à dix pour cent de couverture FEC semblent optimaux.

Des observations précédentes, il est clair que le vote du CMTS pour les erreurs FEC incorrigibles soit valeur. La voix sur ip (VoIP) au-dessus du câble est particulièrement sensible aux erreurs FEC incorrigibles. Si le pourcentage des erreurs FEC incorrigibles est assez élevé, alors les problèmes de qualité voix sont expérimentés, tandis que des données IP pourraient seulement être d'une façon minimum affectées.

En conclusion, si la lecture SNR de la puce des USA est fallacieuse quand des problèmes rapides de la coupure rf sont introduits (comme indiqué plus tôt) mais les erreurs FEC incorrigibles se produisent toujours, le dépannage du problème peut obtenir considérablement plus complexe.

La figure 3 met en valeur un exemple des USA éprouvant le bas SNR pendant qu'elle éprouve des erreurs uncorrectable et corrigibles FEC, soulignant le rapport étroit entre ces deux paramètres en mesurant la représentation ascendante.

Figure 3 ? Erreurs SNR et FEC avec le temps

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

Le premier graphique affiche le pourcentage uncorrectable et corrigible d'erreur FEC, alors que le graphique inférieur indique les lectures pauvres SNR au même exemple à temps. Un contrôle rapide du transporteur digitalement modulé d'en amont sur un analyseur de spectre (tel qu'un Agilent HP8591C) afficherait probablement le bruit de dans-canal assez aux hauts niveaux. Des problèmes en amont rf d'une nature impulsive peuvent être confirmés utilisant le tiers équipement de test (tel que Hukk CM1000 — référez-vous au site Web de télécommunication de lever de soleilleavingcisco.com — ou Acterna DSAM) qui peut mesurer le débit de bloc erroné en amont (semblable aux JUJUBES). Ceci vérifierait qu'un problème rf existe vraisemblablement, même lorsque la lecture des USA SNR semble être bonne.

La ligne inférieure est que si la lecture des USA SNR semble être bonne puis ne supposez pas automatiquement que le rf est bien. Une peu de recherche avec l'équipement de test approprié pourrait être exigée pour déterminer exactement ce qui va en fonction dans le domaine rf. La chance est assez bonne qui le spectre rf n'est pas aussi propre qu'a été supposé la première fois.

Annexe

Cette section détaille les paramètres en amont pour surveiller.

Pourcentage corrigible en amont FEC

Description

Le pourcentage de CWs a reçu sur ce canal avec des erreurs non corrigibles. Ceci inclut tout le CWs, s'ils faisaient partie de trames destinées pour ce périphérique.

Formule

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

  • C = docsIfSigQUnerroreds

  • La Communauté européenne = docsIfSigQCorrecteds

  • UE = docsIfSigQUncorrectables

Règle nette

Les valeurs >2.5% de paquets reçus sont jaune mis en valeur.

Les valeurs >=5% de paquets reçus sont rouge gras.

Les informations nettes

Le pourcentage de l'entrée CWs avec des erreurs corrigibles FEC, relativement au nombre total de CWs a reçu sur cette interface. On lui suggère que ce rapport soit en-dessous de 5% de toute l'entrée CWs.

Les informations détaillées

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.

Pourcentage Uncorrectable en amont FEC

Description

Le pourcentage de CWs a reçu sur ce canal avec des erreurs non corrigibles. Ceci inclut tout le CWs, s'ils faisaient partie de trames destinées pour ce périphérique.

Formule

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

  • C = docsIfSigQUnerroreds

  • La Communauté européenne = docsIfSigQCorrecteds

  • UE = docsIfSigQUncorrectables

Règle nette

Les valeurs >0.5% de CWs reçu sont jaune mis en valeur.

Les valeurs >=1% de CWs reçu sont rouge gras.

Les informations nettes

Le pourcentage de baisses pour l'entrée CWs affiche que le pourcentage de CWs a chuté sur l'entrée, relativement au nombre total de CWs a reçu sur cette interface. On lui suggère que ce rapport soit en-dessous de 0.5% de toute l'entrée CWs.

Remarque: Les services « en temps réel » spécifiques, tels que le VoIP, peuvent exiger une surveillance plus rigoureuse. Une valeur 1% uncorrectable FEC pourrait encore être perte de paquets suffisante pour entraîner des problèmes de qualité voix, selon si la perte est éclatée ou aléatoire.

Les informations détaillées

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.

En amont SNR

Description

SNR comme perçu pour ce canal. Au CMTS, décrit la moyenne signal/bruit du canal ascendant.

Formule

SNR = docsIfSigQSignalNoise/10

Règle nette

Le dB des valeurs <27 sont jaune mis en valeur.

Le dB des valeurs <23 sont rouge gras.

Les informations nettes

DOCSIS spécifie un CNR de minimum (digitalement équivalent au SNR) de 25 dB. Selon le profil de modulation d'en amont configuré (QPSK ou 16-QAM), le minimum SNR de 25 dB peut devoir être augmenté.

Les informations détaillées

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.

L'exemple de la façon tirer des OID pour le Par-modem FEC pare sur un Linecard 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

Afin de trouver les compteurs du mot de passe de ce modem, vous le premier besoin d'obtenir deux informations :

  • L'index d'interface SNMP de l'interface du câble 6/0.

  • Le docsIfCmtsServiceNewCmStatusIndex du modem.

Trouvez l'ifIndex du câble 6/0 avec cette commande :

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

Trouvez le docsIfCmtsServiceNewCmStatusIndex du modem avec SID 50 sur l'interface avec l'ifIndex 10 (câble 6/0) avec cette commande :

% snmpwalk -cpublic 172.18.73.167 docsIfCmtsServiceNewCmStatusIndex.10.50

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

Maintenant que vous avez le docsIfCmtsServiceNewCmStatusIndex du modem (983090), vous pouvez trouver ces compteurs FEC :

  • Bons mots de passe reçus (docsIfCmtsCmStatusUnerroreds)

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

    Remarque: Le compteur d'Unerroreds a incrémenté en quelque sorte dans le temps depuis que vous avez émis la commande de show interface cable.

  • Mots de passe corrigés reçus (docsIfCmtsCmStatusCorrecteds)

    % snmpget -cpublic 172.18.73.167 docsIfCmtsCmStatusCorrecteds.983090
    
    DOCS-IF-MIB::docsIfCmtsCmStatusCorrecteds.983090 = Counter32: 0
    
  • Mots de passe non corrigés reçus (docsIfCmtsCmStatusUncorrectables)

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

Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Informations connexes


Document ID: 49780