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

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

La spécification DOCSIS (Data Over Cable Service Interface Specification) décrit les exigences que chaque câblo-opérateur doit respecter pour assurer un transport fiable du trafic de données IP. Une caractéristique importante de DOCSIS concerne la nécessité de protéger les données IP contre les perturbations sonores des radiofréquences (RF). La fonctionnalité que DOCSIS utilise pour maintenir l'intégrité des données IP sur les installations de câblage HFC est le codage FEC (Reed-Solomon Forward Error Correction).

Essentiellement, le codage FEC protège les données IP et les messages de gestion DOCSIS contre les erreurs de symbole causées par le bruit et d'autres perturbations. La caractéristique unique de FEC est qu'il peut détecter les erreurs de symboles et les corriger. Ainsi, DOCSIS spécifie que toutes les données IP transmises sur une centrale HFC doivent passer par un encodeur Reed-Solomon, où des octets de parité supplémentaires sont ajoutés aux trames de données pour s'assurer qu'elles sont protégées par des erreurs et moins sujettes à des .

Note : FEC ne fonctionne pas très bien si les erreurs sont créées par le bruit d'impulsion qui crée de nombreuses erreurs successivement. Les erreurs induites par le bruit impulsif sont corrigées en aval par l'utilisation de l'entrelacement pour faire apparaître des erreurs étalées, ce que la FEC est efficace pour corriger. DOCSIS 2.0 a ajouté l'entrelacement en amont, ce qui aide à ce type de déficience en amont (US), mais il n'est pas disponible sur les modems câble 1.x (CM).

Sans aucun doute, le chemin de retour ou en amont du réseau câblé est particulièrement vulnérable au bruit et aux perturbations associées. Ce bruit peut être impulsif, bruit d'entrée, bruit thermique, coupure laser, etc. Sans codage FEC, les risques d’abandon d’un paquet en raison d’erreurs de bits sont considérables. Les erreurs FEC sur un câblage ne sont pas la seule mesure de qualité. D'autres variables doivent être prises en compte, comme le rapport porteuse/bruit (CNR).

La norme DOCSIS inclut les paramètres recommandés pour les performances RF de la télévision câblée en aval et en amont. Plus précisément, la section 2.3.2 de la spécification d'interférence de radiofréquence (RFI), Présumées caractéristiques de transmission de canal RF en amont, €  énonce ce qui suit :

Rapport porteuse/interférence plus entrée (somme du bruit, de la distorsion, de la distorsion du chemin commun et de la modulation croisée et somme des signaux d'entrée discrets et à large bande exclus du bruit d'impulsion) [ne sera pas] inférieur à 25 dB.

En d'autres termes, le CNR américain recommandé par DOCSIS est de 25 dB. Aux fins du présent document, le CNR est défini comme étant le rapport porteuse-bruit avant d'atteindre la puce de démodulateur (domaine RF), tel que mesuré par un analyseur de spectre. À l'inverse, le SNR est défini comme le rapport signal/bruit de la puce du récepteur US du système de terminaison de modem câble (CMTS) après la démodulation de l'opérateur pour obtenir un rapport signal/bruit pur de bande de base.

Ainsi, lorsqu'on regarde la lecture SNR d'un Cisco uBR7246 et qu'on voit un nombre de 30 dB, il est facile de supposer que l'amont semble rencontrer ou même dépasser DOCSIS et que les choses dans le monde RF sont bonnes. Mais ce n'est pas toujours le cas. DOCSIS ne spécifie pas le SNR, et l'estimation du SNR du CMTS n'est pas la même chose que le CNR que l'on mesure avec un analyseur de spectre.

Ce document discute du calcul estimé du SNR en amont de l'uBR ainsi que des compteurs FEC de l'uBR et montre pourquoi ces deux variables doivent être constamment évaluées pour garantir la qualité du HSD sur les environnements HFC.

Rapport signal/bruit

L'estimation SNR de l'uBR peut parfois être trompeuse et ne devrait être considérée qu'un point de départ lorsqu'il s'agit de vérifier l'intégrité du spectre RF en amont. La lecture SNR sur la carte de ligne uBR MC16C est fournie par la puce US, mais la lecture n'est pas nécessairement un indicateur fiable de la « réalité » € des défaillances RF, telles que le bruit de type impulsif, l'entrée discrète, etc. Cela ne veut pas dire que la lecture du SNR américain n'est pas exacte. Dans les environnements avec peu de perturbations en amont (par exemple, bruit d'impulsion, entrée, distorsion de la voie commune, etc.), le SNR américain estime que le CNR suit numériquement le CNR dans moins de deux décibels, lorsque le CNR se situe dans la plage de 15 à 25 dB. Elle est exacte avec le bruit de gaussien blanc (AWGN) comme seule altération ; dans le monde réel, cependant, l'exactitude de ces chiffres peut varier. Cela dépend de la nature des déficiences et reflète mieux le ratio d'erreur de modulation (TCM) plutôt que le RCN.

Comment obtenir des lectures SNR et CNR

Cette section présente quelques exemples d'obtention de l'estimation SNR en amont à partir des modèles Cisco uBR7200 et uBR10K (voir également l'annexe). Toutes les commandes et sorties de commande de l'interface de ligne de commande (CLI) proviennent du logiciel Cisco IOS® Version 12.2(15)BC2a, sauf indication contraire.

Notez qu'une € « carte S » fait référence à une carte de ligne de câble dotée de fonctionnalités d'analyse du spectre matériel intégrées, alors qu'une  « carte C » fait référence à une carte de ligne de câble sans cette fonctionnalité. Sous certains paramètres, la carte S signale CNR au lieu de SNR, car elle dispose d'un matériel intégré pour effectuer des fonctions d'analyse spectrale.

Conseil : Lors de la collecte des résultats des commandes CLI du logiciel Cisco IOS à des fins de dépannage ou de transmission au support technique Cisco, n'oubliez pas d'activer l'horodatage de l'invite exec du terminal, de sorte que chaque ligne de sortie de commande CLI soit accompagnée d'un horodatage et de la charge CPU actuelle sur le CMTS.

Pour les 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 les cartes C ou S sans groupes de fréquences attribué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é de conserver le niveau US défini par défaut à 0 dBmV et d'utiliser des atténuateurs externes pour forcer les modems à transmettre à des niveaux plus élevés, si nécessaire.

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 SNR même si CNR est signalé dans la commande show controllers. Ceci est particulièrement utile car le SNR est signalé après l'annulation de l'entrée et le CNR est signalé avant l'annulation de l'entrée.

Remarque : Le numéro de série est indiqué par modem dans le code EC avec show cable modem detail.

La commande phy répertorie également d'autres attributs de couche physique si remote-query est configurée. Ces trois lignes de code peuvent être entrées pour activer la requête distante :

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, ce qui peut ne pas être recommandé dans un CMTS très chargé. La chaîne de communauté en lecture seule par défaut dans la plupart des modems est publique.

Remarque : Ne tenez pas compte de l'entrée de microréflexion, car il s'agit de DS et est limité par la précision de l'implémentation du fournisseur 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

Cette commande répertorie le NUJ lors de l'utilisation d'une carte C. Lorsqu'une carte S est utilisée et que des groupes de fréquences sont attribués, le CN est signalé. La commande show cable modem mac-address verbose fonctionne également.

Comment afficher le niveau sonore

Les cartes S vous permettent également d'afficher le niveau sonore à l'aide de 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

L'ajout de l'adresse IP ou MAC du modem à la commande indique la puissance de rafale du modem et la largeur du 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  *******

Ce résultat montre le bruit sous le porteur et à d'autres fréquences.

En plus de l'interface de ligne de commande, des outils de gestion de réseau SNMP tels que Cisco Broadband Troubleshooter (CBT) peuvent être utilisés pour afficher le spectre américain et d'autres attributs. CiscoWorks peut également être utilisé pour surveiller le SNR tel qu'indiqué par les cartes de ligne de câble à l'aide de l'objet 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 relevés SNR de chaque CM sont uniquement disponibles sur les cartes de ligne MC5x20S et MC28U. Ces nouvelles cartes de ligne intègrent l'annulation d'entrée qui peut améliorer les performances mais peut donner des lectures SNR trompeuses. Les relevés SNR sont effectués après l'annulation d'entrée ; ainsi, si l'annulation d'entrée supprime mathématiquement l'entrée, le SNR peut alors rapporter beaucoup mieux que le rapport porteuse/interférence réel.

Note : Lors de l'utilisation de groupes de spectre sur une carte S, la commande show controllers sélectionne aléatoirement les lectures CNR de tous les CM de cet US, ce qui pourrait être légèrement différent, donnant l'apparence d'un port américain instable ou CNR.

Transporteurs en amont dans une portée nulle

Un mode qui vaut la peine d'être utilisé dans un analyseur de spectre est le mode de portée nulle. Il s'agit du mode de domaine temporel dans lequel l'affichage est de l'amplitude par rapport au temps plutôt que de l'amplitude par rapport à la fréquence. Ce mode est très utile lorsque vous visualisez le trafic de données qui est par nature en rafale. La Figure 1 montre un analyseur de spectre à portée nulle (domaine temporel) tout en examinant le trafic en amont d'un CM.

Figure 1 : affichage à portée nulle sur un analyseur de spectre

Les paquets de données peuvent être vus à la Figure 1, ainsi que les requêtes de modem et le bruit d'impulsion. Cela est très utile pour mesurer les niveaux numériques moyens et pour observer le bruit et l'entrée, comme le montre la figure 2.

Figure 2 - Mesure de la portée zéro de l'amplitude de porteuse numérique en amont

Zero-span peut également être utilisé pour voir si les paquets entrent en collision entre eux à cause d’un mauvais timing ou d’un séparateur de tête de réseau ou d’un isolement de combinaison médiocre. Un paquet destiné à un port en amont CMTS fuit €  sur un autre port en amont. Reportez-vous aux livres blancs et aux documents répertoriés dans la section Informations connexes de ce document. Reportez-vous à Connexion du routeur de la gamme Cisco uBR7200 à la tête de réseau du câble pour obtenir une description de la procédure de mesure de portée nulle.

Pratiquement toutes les défaillances RF mentionnées jusqu'à présent dans ce document peuvent dégrader les performances en amont et se manifester comme un débit de données médiocre sans nécessairement être reflétées comme un SNR faible. L'observation d'erreurs incorrectes de FEC (analogues à un mauvais BER et PER)—même si le SNR semble être supérieur à la norme DOCSIS minimale—pourrait indiquer d'autres problèmes transitoires qui doivent être résolus. Il peut également y avoir un CM non autorisé qui cause des erreurs et une mauvaise lecture du SNR pour tous les autres CM sur le même US. Dans ce cas, le GNC mesuré sur un analyseur de spectre aurait l'air parfait, mais le SMTS en ferait état autrement.

Correction des erreurs de transfert

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

Dans un monde idéal, les erreurs de bits mesurables (erreurs FEC correctes ou non correctes) devraient rarement se produire. Toutefois, lorsqu'il existe des erreurs incorrectes de FEC, les effets peuvent être graves et peuvent être causés par un certain nombre de facteurs différents. Il s'agit d'une liste d'événements connus qui pourraient introduire des erreurs FEC incorrectes en amont et qui doivent être prises en compte lors du dépannage des erreurs FEC :

• interférence du transmetteur de balayage

• surcharge de l'amplificateur (compression, qui est une forme de découpage)

• découpage laser

• bruit impulsif ou interférence d'entrée

• connexions lentes ou intermittentes

• Mauvaise isolation du séparateur ou de la combinaison en amont

• modems défectueux

Il existe deux méthodes permettant de recueillir des informations FEC :

• CLI 

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

Voici un exemple de la façon de recueillir des renseignements FEC à l'aide de l'interface de ligne de commande (voir aussi 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 : nombre total de blocs FEC (bons et mauvais) reçus par tous les ports en amont associés à un aval donné.

• UnCorFECBlks : nombre total de blocs FEC reçus par tous les ports en amont associés à un aval donné qui ont été si endommagés par le bruit ou l'entrée qu'ils n'ont pu être corrigés ou récupérés par l'algorithme FEC.

• CorFECBlks : nombre total de blocs FEC reçus par tous les ports en amont associés à un aval donné qui ont été légèrement endommagés par le bruit ou l'entrée et qui ont pu être corrigés et récupérés par l'algorithme FEC.

Les rafales de maintenance de station incrémentent le compteur FECBlks d'environ 2 par x secondes, où x est l'intervalle d'interrogation minimal (comme indiqué dans la commande show cable hop) divisé par 1000. La requête distante incrémente également ce compteur, tout comme la maintenance initiale lorsque les modems sont mis en ligne. Comme la maintenance initiale se produit pendant le temps de conflit, il peut y avoir des collisions et des erreurs FEC incorrectes subséquentes.

Conseil : Assurez-vous que les modems ne se mettent pas en ligne ou ne se mettent pas en ligne avant de présumer que les États-Unis sont instables simplement parce que les compteurs FEC incorrects augmentent. En outre, la valeur NoUwCollNoEngy peut augmenter si des modems présentent des problèmes de synchronisation. Unique Word est spécifique à BRCM, et non à DOCSIS, et est les derniers octets du préambule.

Un pourcentage peut être estimé en prenant UnCorrFECBlks / FECBlks × 100. Le compteur FBCElks est le nombre total de blocs FEC envoyés, qu'ils soient bons ou mauvais. Cette sortie concerne l'ensemble du domaine MAC (tous les États-Unis). Il est préférable de regarder les compteurs entre une période donnée pour voir le delta.

Note : L'un des inconvénients de la collecte d'informations FEC à l'aide de l'interface CLI est que les UncorFECBlks, CorFECBlks et le total FECBlks ne sont pas séparés par amont.

Pour consulter les informations FEC par amont, vous devez utiliser les OID SNMP. Vous pouvez également utiliser la commande show cable hop pour afficher les erreurs FEC correctables ou non correctables par port en amont, mais pas le nombre total de 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 : La commande clear counters efface uniquement les compteurs show interface et show cable hop, mais pas le compteur show controllers. Les compteurs du contrôleur ne peuvent être effacés que si le CMTS est rechargé ou si l'interface est mise sous tension et mise sous tension à l'aide de la commande suivante :

ubr# cable power off slot/card

     

Par conséquent, il est utile de répéter que les erreurs FEC incorrectes entraînent des paquets abandonnés et risquent fort d'entraîner un débit de données en amont médiocre. Toutefois, avant que les événements n'atteignent ce stade critique, il existe des prédicteurs et des indications selon lesquelles les performances en amont se détériorent. Les erreurs FEC correctes servent d'indicateur de dégradation du débit des données en amont et servent de signal d'avertissement pour que les erreurs FEC futures non corrigables soient possibles.

Conseil : Si le compteur Uncorr s'incrémente beaucoup plus rapidement que le compteur Corr, alors le problème pourrait être lié au bruit d'impulsion. Si le compteur Corr augmente aussi vite (ou plus vite que le compteur Uncorr, alors il est probablement lié à AWGN ou il s'agit d'un problème d'entrée en état d'équilibre comme la bande de citoyens (CB), la radio à ondes courtes, la distorsion du chemin commun (CPD), et ainsi de suite.

Comment obtenir des compteurs FEC via SNMP

Ces trois OID SNMP du fichier MIB SNMP DOCS-IF-MIB sont utilisés pour collecter et analyser les erreurs FEC (sans erreur, corrigées et incorrectes FEC - voir é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.

Comme 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 des performances réelles du débit en amont. Ces formules doivent être utilisées :

• _Cx = docsIfSigQUerroreds à la fois x

• _Ecx = docsIfSigQCorrecteds à la fois x

• _Eux = docsIfSigQUnrectitables à la fois x

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

% Non Correctable = [(Eu1 - Eu0)/ [(Eu1 - Eu0) + (Ec1 - Ec0) + (C1 - C₀)] * 100

Note : Non corrigeables plus les erreurs plus les corrections égal au nombre total de mots de passe (CW); également connus sous le nom de blocs de données FEC) reçus sur ce US, y compris tous les CW, qu'ils fassent ou non partie de trames destinées au CMTS. La taille d'un CW est déterminée par le profil de modulation.

Compteurs FEC par modem

Si un paquet US est abandonné, il incrémente un compteur FEC Uncorr. Cela se produit dans la couche physique. Vous pouvez demander comment le CMTS distingue un paquet abandonné, s'il n'a pas la possibilité de voir l'ID de service (SID) ou l'adresse source (couche 2). Cependant, le SID CM est inclus dans l'en-tête DOCSIS.

Exemple d'éclatement de l'Amérique :

(préambule) + {(docsis hdr = 6 octets) + (BPI+, docsis extended hdr = 4 à 7 octets) + 1 500 ethernet + 18 en-tête ethernet} + (bande surveillée)

Tout entre { et } est additionné, coupé en CW en fonction du profil de modulation, puis 2×T est ajouté à chaque CW. Donc techniquement, si le mot de passe spécifique qui contient le SID est supprimé, comment le CMTS peut-il distinguer le modem à partir duquel il a été envoyé ? Pour ce faire, vous pouvez utiliser le planificateur CMTS, qui connaît l'heure à laquelle certains paquets arriveraient de modems spécifiques.

Vous pouvez afficher les valeurs FEC répertoriées par modem à l'aide de la commande show interface cableport/slot sid sid-number counter verbose. Vous pouvez également les récupérer via SNMP à l'aide des OID suivants :

• Mots de passe corrects reçus (docsIfCmtsCmStatusUnerroreds)

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

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

Remarque : cette option n'est actuellement pertinente que pour les cartes de ligne 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

Ceci est spécifique à ce modem et les compteurs se mettent à jour environ 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 show cable hop signale une erreur FEC Uncorr supplémentaire. Ceci est probablement dû au fait qu'un CW a été abandonné qui appartenait à un autre modem.

Il serait intéressant de voir un graphique des erreurs FEC par CM en interrogeant les MIB et en utilisant le MRTG (Multirouter Traffic Grapher) ou d'autres logiciels tels que Cisco BT. Ceci peut être utilisé pour voir si certains modems ont un retard de groupe faible, des microréflexions, etc. Il s'agirait d'un élément qui affecte uniquement un modem spécifique.

Compteurs de paquets en amont

Une autre commande qui répertorie les erreurs est la commande show interface cable5/1/0 en amont. Il s'agit de paquets, qui sont différents des CW FEC. Un paquet peut être composé de plusieurs 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)

Voici les définitions des termes :

• broadcast : trames de diffusion reçues.

• multicasts : trames de multidiffusion reçues.

• unicasts : trames de monodiffusion reçues.

• disCARTS : incréments uniquement sur la carte de ligne MC5x20S. Répertorie les paquets rejetés en raison de diverses conditions d'erreur spécifiques à la carte et non à la trame réelle.

• errors : nombre total d'erreurs, dont beaucoup n'ont pas d'importance. Les erreurs que cette valeur compte sont pour les cartes BCM3210 telles que MC16C et MC28C :

  • Nombre de logements en amont alloués où le préambule et le mot unique n'ont pas été reçus correctement.

  • Nombre de trames incorrectes reçues.

  • Les collisions dans la bande passante “ demander des opportunités ”.

  • Collisions dans “ logements de ” de requête/données (ces types de logements ne se produisent pas sur les CMTS Cisco).

  • Les trames endommagées reçues pendant la bande passante “ demander ” opportunités.

  • Trames endommagées reçues lors de la réception de “ demandes/” de données.

  • Nombre de demandes de portée endommagées entendues.

  Pour les cartes de ligne JIB telles que MC5x20 et MC28U :

  • Trames en amont en erreur qui, pour une raison quelconque, ne sont pas classées comme séquence de contrôle d'en-tête (HCS) ou contrôle de redondance cyclique (CRC) en erreur.

  • Trames en amont avec des problèmes HCS.

  • Trames en amont avec erreurs CRC.

  • Réception de PV non corrigibles.

  • Collisions dans la demande de bande passante IUC.

• protocole inconnu : nombre de trames reçues qui n'étaient pas IP, ARP (Address Resolution Protocol) ou PPPoE (Point to Point Protocol over Ethernet). Ce compteur inclut également des trames avec des en-têtes DOCSIS mal formés ou des options d'en-tête non valides.

• packet input - Total des diffusions, multidiffusions et monodiffusions.

• incorrigible : nombre total de trames comportant au moins un CW FEC incorrigible. Ce champ affiche N/A pour les MC5x20 et 28U. Utilisez la colonne Uncorr FEC Errors dans show cable hop output à la place, pour obtenir une idée des erreurs incorrectes.

• noise - Pour les cartes BCM3210 telles que les MC16C et MC28C, il s’agit du nombre de trames endommagées reçues dans la bande passante “ les ” de demande ou “ intervalles ” de plage. Cela fait de ce nombre un sous-ensemble des nombres dans les erreurs.

  • Les trames endommagées reçues lors de la demande de bande passante “ les opportunités ”

  • Trames endommagées reçues lors de la réception de “ demandes/” de données.

  • Nombre de demandes de portée endommagées entendues.

  Pour les cartes JIB comme le MC5x20, ce compteur ne s'incrémente pas du tout.

• microréflexions : nombre de microréflexions ; toujours défini sur 0.

Les compteurs d'erreurs et de bruit ne comptent pas uniquement les trames endommagées ; ils comptent également des éléments tels que les collisions de requêtes de portée initiale et les collisions de requêtes de bande passante. Ainsi, un compteur de bruit incrémentant ne signifie pas toujours qu'il y a un problème. Cela peut simplement signifier que le client a beaucoup de modems qui essaient de se connecter ou que les modems tentent d'effectuer plus de transmissions (ce qui conduit à plus de collisions mentionnées). Le compteur de bruit est en fait un sous-ensemble du compteur d'erreurs car le bruit inclut les trois derniers composants du compteur d'erreurs.

Conclusion

Grâce à l'expérience et aux tests en laboratoire effectués par le groupe Advance Services et Rapid Response de Cisco, voici quelques observations concernant FEC et les faibles performances en amont :

• La présence d'erreurs FEC incorrectes est une bonne mesure lorsque le bruit atteint un niveau intolérable ou lorsque des paquets entrent en collision les uns avec les autres en raison d'un mauvais timing ou d'un mauvais séparateur de tête de réseau ou d'un isolement de combinaison. En ce qui concerne ce dernier, un paquet destiné à un port en amont CMTS fuit “ ” sur un autre en amont en raison de la mauvaise isolation.

• Une forte augmentation des erreurs de FEC incorrectes entraîne des problèmes de qualité vocale.

• Les erreurs FEC corrigables sont perçues à mesure que le niveau de bruit augmente. Les erreurs FEC corrigables n'entraînent pas de pertes de paquets ou une mauvaise qualité de la voix, à condition qu'il n'y ait pas d'erreurs FEC non corrigables.

• L'augmentation des T-octets FEC dans le profil de modulation des États-Unis peut aider jusqu'à un certain point, mais cela dépend de la source de bruit. La couverture FEC de 7 à 10 % semble optimale.

D'après les observations précédentes, il est clair que l'interrogation du CMTS pour les erreurs FEC incorrectes est utile. La voix sur IP (VoIP) sur câble est particulièrement sensible aux erreurs FEC incorrectes. Si le pourcentage d'erreurs FEC incorrectes est assez élevé, des problèmes de qualité vocale sont alors rencontrés, alors que les données IP ne peuvent être affectées que de manière minime.

Enfin, si la lecture du SNR de la puce américaine est trompeuse lorsque des défaillances RF transitoires rapides sont introduites (comme indiqué précédemment) mais que des erreurs FEC incorrectes se produisent toujours, le dépannage du problème peut devenir considérablement plus complexe.

La figure 3 illustre un exemple d'un États-Unis qui connaît un SNR faible en même temps qu'il rencontre des erreurs FEC incorrectes et corrigables, soulignant la relation étroite entre ces deux paramètres lors de la mesure des performances en amont.

Figure 3 - Erreurs SNR et FEC dans le temps

 

Le premier graphique affiche le pourcentage d'erreur FEC incorrigible et corrigible, tandis que le graphique du bas indique de mauvaises lectures SNR au même moment dans le temps. Une vérification rapide de l'opérateur modulé numériquement en amont sur un analyseur de spectre (tel qu'un Agilent HP8591C) montrerait probablement un bruit dans le canal à des niveaux relativement élevés. Les problèmes de RF en amont de nature impulsive peuvent être confirmés à l'aide d'équipements de test tiers (tels que Hukk CM1000, reportez-vous au site Web de Sunrise Telecom—ou Acterna DSAM) qui peuvent mesurer le taux d'erreur de bloc en amont (similaire au BER). Cela permettrait de vérifier qu'un problème RF existe probablement, même lorsque la lecture du SNR américain semble être bonne.

En fin de compte, si la lecture du SNR américain semble être bonne, alors ne supposez pas automatiquement que la RF est correcte. Il peut être nécessaire d’effectuer une petite recherche avec l’équipement de test approprié pour déterminer exactement ce qui se passe dans le domaine RF. Les chances sont bonnes que le spectre RF ne soit pas aussi propre que ce qui avait été supposé au départ.

Annexe

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

Pourcentage FEC corrigé en amont

Description

Pourcentage de PV reçus sur ce canal avec des erreurs incorrectes. Cela inclut tous les CW, qu'ils fassent ou non partie de trames destinées à ce périphérique.

Formule

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

• C = docsIfSigQUerrores

• _Ec = docsIfSigQCorrecteds

• _Eu = docsIfSigQUnrectitables

Règle nette

Les valeurs >2,5% des paquets reçus sont mises en surbrillance jaune.

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

Info Net

Pourcentage de PV d'entrée avec des erreurs FEC correctables, par rapport au nombre total de PV reçus sur cette interface. Il est suggéré que ce ratio soit inférieur à 5 % de tous les CW d'entrée.

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 FEC non corrigible en amont

Description

Pourcentage de PV reçus sur ce canal avec des erreurs incorrectes. Cela inclut tous les CW, qu'ils fassent ou non partie de trames destinées à ce périphérique.

Formule

%Non Correctable = [(Eu1 - Eu0)/ [(Eu1 - Eu0) + (Ec1 - Ec0) + (C1 - C₀)] * 100

• C = docsIfSigQUerrores

• _Ec = docsIfSigQCorrecteds

• _Eu = docsIfSigQUnrectitables

Règle nette

Les valeurs >0,5% des PV reçues sont mises en surbrillance jaune.

Les valeurs >=1% des PV reçues sont en gras rouge.

Info Net

Le pourcentage de pertes pour les CW d'entrée indique le pourcentage de CW abandonnés en entrée, par rapport au nombre total de CW reçus sur cette interface. Il est suggéré que ce ratio soit inférieur à 0,5 % de tous les CW d'entrée.

Remarque : Des services ” en temps réel “ spécifiques, tels que la VoIP, peuvent nécessiter une surveillance plus stricte. Une valeur FEC non corrigible de 1 % peut toujours être une perte de paquets suffisante pour causer des problèmes de qualité de la voix, selon que la perte est en rafale ou aléatoire.

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.

SNR en amont

Description

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

Formule

SNR = docsIfSigQSignalNoise / 10

Règle nette

Les valeurs <27 dB sont surlignées en jaune.

Les valeurs <23 dB sont en gras rouge.

Info Net

DOCSIS spécifie un CNR minimum (équivalent numérique à SNR) de 25 dB. En fonction du profil de modulation en amont configuré (QPSK ou 16-QAM), le SNR minimum de 25 dB peut devoir être augmenté.

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.

Exemple d'extraction d'OID pour les compteurs FEC par modem sur une carte de ligne 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

Pour trouver les compteurs Codeword de ce modem, vous devez d'abord obtenir deux informations :

• Index d'interface SNMP de l'interface câble 6/0.

• docsIfCmtsServiceNewCmStatusIndex du modem.

Recherchez ifIndex du câble 6/0 à l'aide de la commande suivante :

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

Recherchez le docsIfCmtsServiceNewCmStatusIndex du modem avec SID 50 sur l'interface avec 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 les compteurs FEC suivants :

• Mots de passe corrects reçus (docsIfCmtsCmStatusUnerroreds)

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

  Remarque : Le compteur Unerroreds s'est quelque peu incrémenté depuis que vous avez émis la commande 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
           

Informations connexes

• Présentation du débit de données dans un monde DOCSIS
• Profils de modulation ascendants pour les cartes de ligne câble
• Spécification de l'interface radio DOCSIS
• Support pour la technologie de câble haut débit
• Support technique - Cisco Systems