Upstream-FEC-Fehler und SNR zur Gewährleistung von Datenqualität und -durchsatz

Einführung

Um ein Hochgeschwindigkeits-Datennetzwerk (HSD) über eine Hybrid Fiber/Koaxial (HFC)-Kabelanlage zu betreiben, ist ein hohes Maß an Qualitätskontrolle erforderlich, um Datenintegrität und höchsten Datendurchsatz sicherzustellen. Die beiden allgemein akzeptierten Methoden, mit denen Kabelnetzbetreiber die Datenqualität messen können, sind entweder die Bitfehlerrate (BER) oder die Paketfehlerrate (PER).

Die DOCSIS (Data Over Cable Service Interface Specification) beschreibt die Anforderungen, die jeder Kabelbetreiber erfüllen muss, um IP-Datenverkehr zuverlässig zu transportieren. Ein wichtiges Merkmal von DOCSIS ist der Schutz von IP-Daten vor Funkfrequenzrauschstörungen. Die DOCSIS-Funktion trägt zur Wahrung der IP-Datenintegrität über HFC-Kabelanlagen bei: Reed-Solomon Forward Error Correction (FEC)-Codierung.

Im Wesentlichen schützt die FEC-Codierung IP-Daten und DOCSIS-Management-Nachrichten vor Symbolfehlern, die durch Rauschen und andere Beeinträchtigungen verursacht werden. Die Besonderheit von FEC besteht darin, dass sie Symbolfehler erkennen und auch korrigieren kann. Daher legt DOCSIS fest, dass alle IP-Daten, die über eine HFC-Anlage übertragen werden, durch einen Reed-Solomon-Encoder geleitet werden sollen, bei dem Datenframes zusätzliche ParitätsBytes hinzugefügt werden, um sicherzustellen, dass sie fehlergeschützt  und weniger anfällig für Beeinträchtigungen sind.

Hinweis: FEC funktioniert nicht sehr gut, wenn die Fehler durch Impulsgeräusche verursacht werden, die viele Fehler in Folge. Impulsgeräuschbedingte Fehler werden im Downstream mithilfe von Verschachtelung behoben, um Fehler zu verbreiten, die der FEC wirksam beheben kann. DOCSIS 2.0 hat Upstream-Verschachtelung hinzugefügt, was bei dieser Art von Upstream-Beeinträchtigung (US) hilfreich ist, aber nicht auf 1.x-Kabelmodems (CMs) verfügbar ist.

Zweifellos ist der Rückweg des Kabelnetzes oder der vorgeschaltete Weg besonders lärmempfindlich und damit zusammenhängend beeinträchtigend. Ein solches Geräusch kann Impuls, Ingress-Geräusch, Temperaturgeräusch, Laser-Clipping usw. sein. Ohne FEC-Codierung ist die Wahrscheinlichkeit, dass ein Paket aufgrund von Bitfehlern verworfen wird, beträchtlich. FEC-Fehler in einer Kabelanlage sind nicht die einzige Qualitätsmaßnahme. Es gibt weitere Variablen, die berücksichtigt werden müssen, z. B. das Carrier-to-Noise-Verhältnis (CNR).

Der DOCSIS-Standard enthält empfohlene Parameter für die HF-Leistung beim Downstream- und Upstream-Kabel-TV. In Abschnitt 2.3.2 der Radio Frequency Interference (RFI)-Spezifikation "Assumed Upstream RF Channel Transmission Characistics" (Angenommene Upstream-RF-Channel-Übertragungsmerkmale) wird Folgendes :

Das Verhältnis zwischen Interferenz und Interferenz plus Ingress (Summe aus Rauschen, Verzerrung, Verzerrung im gemeinsamen Pfad und Quermodulation und der Summe der diskreten und breitbandigen Ingress-Signale, Impulsgeräusche ausgeschlossen) [wird nicht unter 25 dB liegen.

Das heißt, der DOCSIS-Mindestwert für den US-CNR beträgt 25 dB. Im Sinne dieses Dokuments ist CNR definiert als das Carrier-to-Noise-Verhältnis, bevor es den Demulator-Chip (RF-Domäne) erreicht, gemessen durch einen Spektrumanalysator. SNR hingegen ist definiert als das Signal-Rausch-Verhältnis des US-Receiver-Chips des CMTS (Kabelmodem Termination System), nachdem der Carrier demoduliert wurde, um ein reines Baseband-Signal-Rausch-Verhältnis zu erzielen.

Wenn man sich also die SNR-Lektüre eines Cisco uBR7246 anschaut und eine Zahl wie 30 dB anschaut, kann man leicht davon ausgehen, dass die Upstream DOCSIS erfüllen oder sogar übertreffen und dass es in der RF-Welt gut geht. Das ist jedoch nicht immer der Fall. DOCSIS gibt keine SNR-Angabe an, und die SNR-Schätzung des CMTS entspricht nicht der CNR-Schätzung, die mit einem Spektrumanalyse gemessen wird.

In diesem Dokument wird die geschätzte Berechnung der SNR-Upstream-Rate des uBR sowie die FEC-Zähler des uBR erläutert. Außerdem wird aufgezeigt, warum diese beiden Variablen kontinuierlich ausgewertet werden sollten, um die HSD-Qualität gegenüber HFC-Umgebungen sicherzustellen.

Signal-Rausch-Verhältnis

Die SNR-Schätzung des uBR kann manchmal irreführend sein und sollte nur als Ausgangspunkt für die Überprüfung der Integrität des Upstream-Funkspektrums dienen. Die SNR-Messung auf der uBR MC16C-Linecard wird vom US-Chip bereitgestellt, aber die Messung ist nicht notwendigerweise ein zuverlässiger Indikator für "reale" €  Funkstörungen, wie z. B. Impulsgeräusch, diskreter Eintritt usw. Das heißt nicht, dass die SNR-Lektüre der USA nicht korrekt ist. In Umgebungen mit wenigen Beeinträchtigungen des Upstream (z. B. Impulsgeräusche, Eingangsgeräusche, allgemeine Pfadverzerrungen usw.) wird CNR nach US SNR-Schätzung numerisch innerhalb von weniger als ein paar Dezibel nachverfolgt, wenn die CNR im Bereich von 15 bis 25 dB liegt. Es ist genau mit additivem weißem Gaussergeräusch (AWGN) als einzige Beeinträchtigung; in der realen Welt, aber die Genauigkeit dieser Zahlen kann variieren. Dies hängt von der Art der Wertminderungen ab und spiegelt besser das Modulationsfehlerverhältnis (MER) als CNR wider.

Erhalten von SNR- und CNR-Lesungen

Dieser Abschnitt zeigt einige Beispiele, wie Sie die SNR-Upstream-Schätzung von Cisco uBR7200 und uBR10K erhalten (siehe auch Anhang). Alle Befehle und Befehlszeilenbefehle (CLI) und Befehlsausgaben stammen aus der Cisco IOS® Software, Version 12.2(15)BC2a, sofern nicht anders angegeben.

Beachten Sie, dass ein "S-Card"-€  eine Kabel-Linecard mit integrierten Funktionen für die Hardwarespektrumanalyse bezeichnet, während ein "C-Card"-€ eine Kabelverbindung ohne diese Funktion . Unter bestimmten Einstellungen meldet die S-Karte CNR anstelle von SNR, da sie über eine integrierte Hardware zur Durchführung von Spektrumanalysefunktionen verfügt.

Tipp: Denken Sie beim Erfassen der Ausgabe von CLI-Befehlen der Cisco IOS-Software für die Fehlerbehebung oder für die Weiterleitung an den technischen Support von Cisco daran, den Zeitstempel der Terminalexec-Eingabeaufforderung zu aktivieren, sodass jede Befehlszeile mit einem Zeitstempel und der aktuellen CPU-Last im CMTS versehen ist.

Für S-Karten:

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

Für C-Karten oder S-Karten ohne zugewiesene Spektrumgruppen:

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

Es wird empfohlen, den US-Wert auf den Standardwert 0 dBmV zu belassen und externe Dämpfungsglieder zu verwenden, um ggf. die Übertragung von Modems auf höheren Ebenen zu erzwingen.

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

Tipp: Mit dem Befehl phy kann SNR gemeldet werden, selbst wenn CNR im Befehl show controller angezeigt wird. Dies ist besonders nützlich, da SNR nach einer Stornierung des Eingangs angezeigt wird und CNR vor einer Stornierung des Eingangs gemeldet wird.

Hinweis: Die SNR-Funktion wird pro Modem im EC-Code mit Details zum Kabelmodem aufgeführt.

Der Befehl phy listet auch andere Attribute der physischen Ebene auf, wenn eine Remoteabfrage konfiguriert wurde. Diese drei Codezeilen können eingegeben werden, um die Remoteabfrage zu aktivieren:

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

Für eine schnelle Antwort wurden drei Sekunden verwendet, was in einem stark ausgelasteten CMTS möglicherweise nicht empfohlen wird. Der standardmäßige schreibgeschützte Community-String in den meisten Modems ist öffentlich.

Hinweis: Beachten Sie den Eintrag zur Mikroreflexion, da dies für DS gilt und durch die Genauigkeit der Implementierung des CM-Anbieters begrenzt ist.

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

Dieser Befehl listet SNR auf, wenn eine C-Karte verwendet wird. Wenn eine S-Karte verwendet und Spektrumgruppen zugewiesen werden, wird CNR gemeldet. Der Befehl show cable modem mac-address verbose funktioniert ebenfalls.

Anzeigen der Geräuschkulisse

Mit dem folgenden Befehl können Sie die Geräuschkulisse auch anzeigen:

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

Wenn dem Befehl die Modem-IP- oder MAC-Adresse hinzugefügt wird, wird die Modem-Burst-Leistung und die Kanalbreite angezeigt.

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

Diese Ausgabe zeigt das Geräusch unter dem Träger und auf anderen Frequenzen.

Neben der CLI können SNMP-basierte Netzwerkverwaltungstools wie der Cisco Broadband Troubleshooter (CBT) verwendet werden, um das US-Spektrum und andere Attribute anzuzeigen. CiscoWorks kann auch verwendet werden, um die SNR-Funktion zu überwachen, die von Kabelnetzkarten mithilfe des docsiIfSigQSignalNoise-Objekts gemeldet wird:

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.

Hinweis: Einzelne CM SNR-Messwerte sind nur auf den Linecards MC5x20S und MC28U verfügbar. Diese neuen Linecards enthalten eine Eingangsabsage, die zwar die Leistung verbessern kann, aber zu irreführenden SNR-Messwerten führen kann. Die SNR-Werte werden nach der Stornierung des Eingangs angezeigt. Wenn also bei einer eingehenden Absage der Eingang mathematisch entfernt wird, könnte SNR viel besser berichten als das tatsächliche Carrier-to-Interference-Verhältnis.

Hinweis: Bei Verwendung von Spektrumgruppen auf einer S-Karte wählt der Befehl show controller zufällig CNR-Messwerte von allen CMs in diesen USA aus, die etwas anders sein könnten, was das Aussehen eines instabilen US-Ports oder CNRs widerspiegelt.

Upstream-Carrier in Zero-Span

Ein in einem Spektrumanalysator nutzbarer Modus ist der Zero-Span-Modus. Dies ist der Zeitdomänenmodus, bei dem das Display Amplitude gegen Zeit statt Amplitude gegen Frequenz darstellt. Dieser Modus ist sehr nützlich, wenn Datenverkehr angezeigt wird, der sprunghaft ansteigt. Abbildung 1 zeigt einen Spektrumanalysator in einer Zero-Span-Domäne (Zeitdomäne) bei gleichzeitiger Betrachtung des Upstream-Datenverkehrs von einem CM.

Abbildung 1: Zero-Span-Anzeige in einem Spektrumanalysator

Datenpakete sind in Abbildung 1 zusammen mit Modemanforderungen und Impulsgeräuschen zu sehen. Dies ist, wie in Abbildung 2 dargestellt, sehr nützlich für die Messung der durchschnittlichen digitalen Werte und die Überwachung von Rauschen und Eintritt.

Abbildung 2: Zero-Span-Messung des Upstream-Digitalmodulierten Carrier-Verstärkers

Zero-span kann auch verwendet werden, um festzustellen, ob Pakete aufgrund schlechter Zeitmessung oder fehlender Headend-Splitter- oder Combiner-Isolation miteinander kollidieren. Ein Paket, das für einen CMTS-Upstream-Port vorgesehen ist, "sickert" € einem anderen Upstream. Weitere Informationen finden Sie in den Whitepapern und Dokumenten, die im Abschnitt Zugehörige Informationen dieses Dokuments aufgeführt sind. Unter Verbinden des Cisco Routers der Serie uBR7200 mit dem Kabel-Headend finden Sie eine Beschreibung des Nullspan-Messverfahrens.

Nahezu alle in diesem Dokument erwähnten Funkstörungen können die Upstream-Leistung beeinträchtigen und sich als schlechter Datendurchsatz manifestieren, ohne dass sie notwendigerweise als niedrige SNR-Leistung reflektiert werden. Die Beobachtung nicht korrigierbarer FEC-Fehler (analog zu schlechten BER- und PER-Werten) - obwohl die SNR offenbar über dem DOCSIS-Mindeststandard liegt - könnte auf andere vorübergehende Probleme hinweisen, die behoben werden müssen. Es könnte auch einen nicht autorisierten CM geben, der Fehler verursacht und eine schlechte SNR-Lektüre für alle anderen CMs auf dem gleichen US-amerikanischen. In diesem Fall würde CNR, gemessen an einem Spektrumanalysator, gut aussehen, aber das CMTS würde etwas Anderes melden.

Korrektur von Weiterleitungsfehlern

Denken Sie daran, dass die Reed-Solomon-FEC-Codierung verwendet wird, um Datenpaketen redundante Paritätsbyte hinzuzufügen, um die Erkennung und Korrektur von Burst-Fehlern zu ermöglichen, die von der Kabelanlage eingeführt wurden.

In einer idealen Welt sollten messbare Bitfehler - korrigierbare oder nicht korrigierbare FEC-Fehler - selten auftreten. Wenn FEC-Fehler vorliegen, können diese schwerwiegend sein und durch eine Vielzahl unterschiedlicher Faktoren verursacht werden. Dies ist eine Liste bekannter Ereignisse, die zu unkorrigierbaren FEC-Fehlern im Upstream führen können und die bei der Behebung von FEC-Fehlern berücksichtigt werden sollten:

• Sweep-Transmitter-Interferenz

• Verstärkerüberladung (Komprimierung, eine Form des Clipping)

• Laserschneiden

• Impulsstörung oder Eingangsstörung

• lose oder temporäre Verbindungen

• schlechte Upstream-Kombination oder Splitter-Isolierung

• fehlerhafte Modems

Es gibt zwei Methoden, mit denen man FEC-Informationen sammeln kann:

• CLI

• Polling von SNMP Object Identifier (OID)

Dies ist ein Beispiel dafür, wie FEC-Informationen mithilfe der CLI erfasst werden (siehe auch Anhang):

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: Die Gesamtzahl der FEC-Blöcke (sowohl gute als auch schlechte), die von allen Upstream-Ports empfangen werden, die einem bestimmten Downstream zugeordnet sind.

• UnCorFECBlks: Die Gesamtzahl der FEC-Blöcke, die von allen Upstream-Ports empfangen wurden, die einem bestimmten Downstream zugeordnet sind und die so durch Rauschen oder Eindringen beschädigt wurden, dass sie vom FEC-Algorithmus nicht korrigiert oder wiederhergestellt werden konnten.

• CorFECBlks: Die Gesamtzahl der FEC-Blöcke, die von allen Upstream-Ports empfangen wurden, die einem bestimmten Downstream zugeordnet sind und die durch Rauschen oder Eindringen leicht beschädigt wurden und durch den FEC-Algorithmus korrigiert und wiederhergestellt werden konnten.

Station-Wartungs-Bursts erhöhen den FECBlks-Zähler um ca. 2 pro x Sekunden, wobei x das minimale Abfrageintervall (wie im Befehl show cable hop angezeigt) geteilt durch 1000 ist. Bei der Remoteabfrage wird dieser Zähler ebenso erhöht wie bei der Erstwartung, wenn Modems online sind. Da die Erstwartung während der Konfliktzeit erfolgt, können Kollisionen und nachfolgende nicht korrigierbare FEC-Fehler auftreten.

Tipp: Stellen Sie sicher, dass Modems nicht reichen oder online gehen, bevor Sie davon ausgehen, dass die USA instabil sind, nur weil die nicht korrigierbaren FEC-Zähler steigen. Außerdem kann der Wert NoUwCollNoEngy erhöht werden, wenn Modems mit Timing-Problemen auftreten. Eindeutiges Wort ist spezifisch für BRCM, nicht für DOCSIS, und ist die letzten paar Bytes der Präambel.

Ein Prozentsatz kann geschätzt werden, indem man UnCorrFECBlks / FECBlks × 100 verwendet. Der FECBlks-Zähler ist die Summe der gesendeten FEC-Blöcke, ob gut oder schlecht. Diese Ausgabe gilt für die gesamte MAC-Domäne (alle USA). Am besten schauen Sie sich die Zähler zwischen einem festgelegten Zeitraum an, um das Delta zu sehen.

Hinweis: Ein Nachteil bei der Erfassung von FEC-Informationen über die CLI besteht darin, dass die UnCorFECBlks, CorFECBLks und die gesamten FECBlks nicht pro Upstream getrennt sind.

Um die Upstream-FEC-Informationen anzuzeigen, sollten Sie SNMP OIDs verwenden. Sie können auch den Befehl show cable hop verwenden, um korrigierbare oder nicht korrigierbare FEC-Fehler pro Upstream-Port anzuzeigen, jedoch nicht die gesamten FEC-Blöcke.

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
     

Hinweis: Der Befehl clear counter löscht nur die show-Schnittstelle und die show cable hop-Zähler, nicht aber den show controller-Zähler. Die Controller-Zähler dürfen nur gelöscht werden, wenn der CMTS neu geladen oder die Schnittstelle mit dem folgenden Befehl aus- und wieder eingeschaltet wird:

ubr# cable power off slot/card

     

Es lohnt sich zu betonen, dass nicht korrigierbare FEC-Fehler zu Paketverlusten führen und höchstwahrscheinlich einen schlechten Upstream-Datendurchsatz verursachen. Bevor die Ereignisse in diese kritische Phase eintreten, gibt es jedoch Vorhersagen und Hinweise darauf, dass sich die Upstream-Leistung verschlechtert. Berichtigbare FEC-Fehler dienen als Indikator dafür, dass der Upstream-Datendurchsatz abnimmt und als Warnzeichen dafür dienen kann, dass zukünftige nicht korrigierbare FEC-Fehler möglich sind.

Tipp: Wenn der Uncorr-Zähler viel schneller als der Corr-Zähler steigt, könnte das Problem mit Impuls-Geräusch zusammenhängen. Wenn der Corr-Zähler so schnell (oder schneller als der Uncorr-Zähler steigt, dann ist er wahrscheinlich mit dem AWGN verbunden oder es ist ein stetiges Eingangsproblem wie Bürgerband (CB), Kurzwellen-Radio, Common Path Verzeichnisses (CPD) usw.

So erhalten Sie FEC-Zähler über SNMP

Diese drei SNMP-OIDs aus der DOCS-IF-MIB-SNMP-MIB-Datei werden zum Erfassen und Analysieren von FEC-Fehlern (unbearbeitet, korrigiert und nicht korrigierbarer FEC, siehe Anhang) verwendet:

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.

Da es sich bei diesen drei MIBs um absolute Werte handelt (basierend auf der Gesamtzahl der FEC-Datenblöcke, die das CMTS empfängt), bietet die Berechnung des Prozentsatzes ein besseres Bild der tatsächlichen Upstream-Durchsatzleistung. Diese Formeln sollten verwendet werden:

• _Cx = docsIfSigQUnerrored at time x

• _Ecx = docsIfSigQCorrected at time x

• _Eux = docsIfSigQUnCorrectables at time x

% korrigierbar = [(EC1 - EC0)/ [(EU1 - EU0) + (EC1 - EC0) + (C₁ - C_{0)] * 100}

% nicht korrigierbar = [(EU1 - EU0)/ [(EU1 - EU0) + (EC1 - EC0) + (C₁ - C_{0)] * 100}

Hinweis: Unkorrigierbare Tabellen plus Unrichtigkeiten plus Korrekturen entsprechen der Gesamtzahl der Codewörter (CWs). auch bekannt als FEC-Datenblöcke), die in diesen USA empfangen wurden, einschließlich aller CWs, unabhängig davon, ob sie Teil von Frames waren, die für das CMTS bestimmt waren oder nicht. Die Größe eines CW wird durch das Modulationsprofil bestimmt.

FEC-Zähler pro Modem

Wenn ein US-Paket verworfen wird, erhöht es einen Uncorr FEC-Zähler. Dies geschieht in der physischen Schicht. Sie können fragen, wie das CMTS ein verworfenes Paket unterscheidet, wenn es keine Chance hat, die Service-ID (SID) oder die Quelladresse (Layer 2) anzuzeigen. Die CM-SID ist jedoch im DOCSIS-Header enthalten.

Beispiel für einen US-Burst:

(Präambel) + {(docsis hdr = 6 Byte) + (BPI+, docsis extended hdr = 4 bis 7 Byte) + 1500 Ethernet + 18 Ethernet-Header} + (Guardband)

Alles zwischen { und } wird addiert, auf Grundlage des Modulationsprofils in CWs geschnitten und dann jedem CW 2×T hinzugefügt. Wenn also technisch das spezifische Codewort, das die SID enthält, verworfen wird, wie kann das CMTS von dem Modem unterscheiden, von dem es gesendet wurde? Dies lässt sich beispielsweise mit dem CMTS-Scheduler erreichen, der die Zeit kennt, zu der bestimmte Pakete von bestimmten Modems aus ankommen.

Sie können die FEC-Werte, die pro Modem aufgelistet sind, mit dem Befehl show interface cableport/slot Sid Sid-Number counter Ausführse anzeigen. Sie können sie auch mithilfe der folgenden OIDs über SNMP abrufen:

• Empfangene gute Codewörter (docsIfCmtsCmStatusUnerrored)

• Empfangene korrigierte Codewörter (docsIfCmtsCmStatusCorrecteds)

• Empfangene unkorrigierte Codewörter (docsIfCmtsCmStatusUnCorrectables)

Hinweis: Dies ist derzeit nur für die Linecards MC28U und MC5x20 relevant.

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

Dies ist spezifisch für dieses Modem, und die Zähler werden etwa alle 10 Sekunden aktualisiert.

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
     

Beachten Sie, dass der Befehl show cable hop einen weiteren Uncorr FEC-Fehler meldet. Dies liegt vermutlich daran, dass ein CW verworfen wurde, der zufällig zu einem anderen Modem gehört.

Es wäre interessant, eine Grafik von FEC-Fehlern pro CM anzuzeigen, indem die MIBs abgefragt und der Multi-Router Traffic Grapher (MRTG) oder andere Software wie Cisco BT verwendet wird. Anhand dieser Daten kann ermittelt werden, ob bestimmte Modems eine geringe Verzögerung der Gruppe, Mikroreflektionen usw. aufweisen. Dies betrifft nur ein bestimmtes Modem.

Upstream-Paketzähler

Ein weiterer Befehl, der Fehler auflistet, ist der Upstream-Befehl show interface cable5/1/0. Dies sind Pakete, die sich von FEC CWs unterscheiden. Ein Paket kann aus mehreren CWs bestehen.

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)

Dies sind die Begriffsdefinitionen:

• Broadcasts - Empfangene Broadcast-Frames.

• Multicasts - Empfangene Multicast-Frames.

• Unicasts - Empfangene Unicast-Frames.

• Discards - Nur inkrementelle Karten auf der MC5x20S-Linecard. Listet Pakete auf, die aufgrund verschiedener Fehlerzustände verworfen wurden, die für die Karte spezifisch und nicht für den tatsächlichen Frame sind.

• errors (Fehler): Die Gesamtzahl der Fehler, von denen viele nicht von Bedeutung sind. Die Fehler, die bei diesem Wert berücksichtigt werden, gelten für BCM3210-basierte Karten wie MC16C und MC28C:

  • Die Anzahl der zugewiesenen Upstream-Steckplätze, in denen die Präambel und das eindeutige Wort nicht ordnungsgemäß empfangen wurden.

  • Die Anzahl der empfangenen unkorrigierbaren Frames.

  • Kollisionen bei den Bandbreitenanforderungen

  • Kollisionen in "Anforderungs-/Daten"-Steckplätzen (diese Steckplatztypen treten bei Cisco CMTS nicht auf).

  • Beschädigte Frames, die bei Bandbreitenanfragen empfangen werden.

  • Beschädigte Frames, die während "Anfrage/Daten"-Steckplätzen empfangen wurden.

  • Die Anzahl der beschädigten Bereichsanforderungen, die gehört wurden.

  Für JIB-basierte Linecards wie MC5x20 und MC28U:

  • Upstream-fehlerhafte Frames, die aus irgendeinem Grund nicht als Header Check Sequence (HCS)- oder CRC-Fehler klassifiziert sind.

  • Upstream-Frames mit HCS-Problemen.

  • Upstream-Frames mit CRC-Fehlern.

  • Empfangene nicht korrigierbare CWs.

  • Kollisionen in der Bandbreite fordern IUC.

• Unbekanntes Protokoll - Anzahl der empfangenen Frames, die nicht IP, Address Resolution Protocol (ARP) oder Point-to-Point Protocol over Ethernet (PPPoE) waren Dieser Zähler enthält auch Frames mit fehlerhaften DOCSIS-Headern oder ungültigen Headeroptionen.

• Paketeingang - Gesamtanzahl an Broadcasts, Multicasts und Unicasts.

• nicht korrigierbar - Gesamtzahl der Frames, bei denen mindestens ein nicht korrigierbarer FEC-CW vorhanden war. Dieses Feld zeigt N/A für die MC5x20 und 28U. Verwenden Sie die Spalte Uncorr FEC Errors (Uncorr FEC-Fehler) in show cable hop output, um eine Vorstellung von nicht korrigierbaren Fehlern zu erhalten.

• Rauschen - Bei BCM3210-basierten Karten wie MC16C und MC28C ist dies die Anzahl der beschädigten Frames, die in Bandbreitenanforderungs- oder -Rangierintervallen empfangen werden. Damit ist diese Zahl eine Teilmenge der Fehlernummern.

  • Beschädigte Frames, die bei Bandbreitenanfragen empfangen werden

  • Beschädigte Frames, die während "Anfrage/Daten"-Steckplätzen empfangen wurden.

  • Die Anzahl der beschädigten Bereichsanforderungen, die gehört wurden.

  Bei JIB-basierten Karten wie dem MC5x20 erhöht sich dieser Zähler überhaupt nicht.

• Mikroreflektionen - Anzahl der Mikroreflektionen; immer auf 0 gesetzt.

Die Fehler- und Rauschzähler zählen nicht nur beschädigte Frames. Sie zählen auch Dinge wie anfängliche Anforderungskollisionen und Kollisionen mit Bandbreitenanforderungen. Ein steigender Rauschzähler bedeutet also nicht immer, dass ein Problem besteht. Es kann einfach bedeuten, dass der Kunde eine Menge Modems hat, die versuchen, online zu gehen, oder dass Modems versuchen, mehr Übertragungen zu machen (führt zu mehr der erwähnten Kollisionen). Der Rauschzähler ist tatsächlich eine Teilmenge des Fehlerzählers, da Rauschen die letzten drei Komponenten des Fehlerzählers umfasst.

Schlussfolgerung

Die Erfahrungen und Labortests der Cisco Advanced Services and Rapid Response Group zeigen, dass FEC und die Upstream-Leistung schlecht sind:

• Das Vorhandensein von nicht korrigierbaren FEC-Fehlern ist eine gute Messgröße, wenn das Rauschen auf ein unerträgliches Niveau gelangt oder wenn Pakete aufgrund schlechter Zeitmessung oder schlechter Headend-Splitter- oder Combiner-Isolation miteinander kollidieren. Im letzteren Fall "sickert" ein Paket, das für einen CMTS-Upstream-Port bestimmt ist, aufgrund der schlechten Isolierung an einen anderen Upstream.

• Eine große Zunahme an nicht korrigierbaren FEC-Fehlern führt zu Problemen bei der Sprachqualität.

• Korrekturbare FEC-Fehler werden angezeigt, wenn der Rauschpegel erhöht wird. Korrekturbare FEC-Fehler führen nicht zu Paketverlusten oder einer schlechten Sprachqualität, solange keine entsprechenden FEC-Fehler vorliegen.

• Eine Erhöhung der FEC T-Byte im US-Modulationsprofil kann bis zu einem bestimmten Punkt hilfreich sein, aber sie hängt von der Geräuschquelle ab. 7 bis 10 % FEC-Abdeckung scheint optimal zu sein.

Aus den vorherigen Beobachtungen geht eindeutig hervor, dass die Abfrage des CMTS auf nicht korrigierbare FEC-Fehler nützlich ist. VoIP-over-Kabel (Voice over IP) sind besonders empfindlich gegenüber nicht korrigierbaren FEC-Fehlern. Wenn der Anteil der nicht korrigierbaren FEC-Fehler hoch genug ist, treten Probleme mit der Sprachqualität auf, während IP-Daten nur geringfügig betroffen sein können.

Wenn die SNR-Auswertung des US-Chips irreführend ist, wenn schnelle transiente Funkstörungen (wie bereits erwähnt) eingeführt werden, aber immer noch unkorrektable FEC-Fehler auftreten, kann die Fehlerbehebung erheblich komplexer werden.

Abbildung 3 zeigt ein Beispiel dafür, dass in den USA eine niedrige SNR-Rate auftritt, während gleichzeitig nicht korrigierbare und korrigierbare FEC-Fehler auftreten. Dies unterstreicht die enge Beziehung zwischen diesen beiden Parametern bei der Messung der Upstream-Leistung.

Abbildung 3: SNR- und FEC-Fehler im Laufe der Zeit

 

Das erste Diagramm zeigt den fehlerhaft korrigierbaren und korrigierbaren FEC-Fehlerprozentsatz, während das untere Diagramm gleichzeitig schlechte SNR-Messwerte anzeigt. Eine schnelle Prüfung des digital modulierten Upstream-Carriers in einem Spektrumanalysator (z. B. einem Agilent HP8591C) würde wahrscheinlich ein relativ hohes In-Channel-Geräusch aufweisen. Upstream-RF-Probleme impulsiver Art können mithilfe von Drittanbieter-Testgeräten (z. B. Hukk CM1000 - siehe Sunrise Telecom Website - oder Acterna DSAM) bestätigt werden, die die Upstream-Blockfehlerrate (ähnlich wie bei BER) messen können. So wird geprüft, ob ein HF-Problem wahrscheinlich auftritt, selbst wenn die SNR-Lektüre in den USA gut zu sein scheint.

Unterm Strich geht man davon aus, dass die Funkfrequenz in Ordnung ist, wenn die SNR-Lektüre in den USA gut zu sein scheint. Es kann eine kleine Recherche mit geeigneten Testgeräten erforderlich sein, um genau zu bestimmen, was in der RF-Domäne vor sich geht. Die Chancen sind ziemlich gut, dass das Funkspektrum nicht so sauber ist, wie ursprünglich angenommen.

Anhang

In diesem Abschnitt werden die zu überwachenden Upstream-Parameter beschrieben.

Upstream-korrigierbarer FEC-Prozentsatz

Beschreibung

Prozentsatz der auf diesem Kanal empfangenen CWs mit nicht korrigierbaren Fehlern Dies schließt alle CWs ein, unabhängig davon, ob sie Teil von Frames waren, die für dieses Gerät bestimmt sind.

Formel

%korrigierbar = [(EC1 - EC0)/ [(EU1 - EU0) + (EC1 - EC0) + (C₁ - C_{0)] * 100}

• C = docsIfSigQUnerrored

• _Ec = docsIfSigQCorrecteds

• _Eu = docsIfSigQUnCorrectables

Net-Regel

Werte >2,5 % der empfangenen Pakete sind gelb hervorgehoben.

Werte >=5% der empfangenen Pakete sind fett rot.

Net-Info

Prozentsatz der Eingabe-CWs mit korrigierbaren FEC-Fehlern, bezogen auf die Gesamtzahl der CWs, die auf dieser Schnittstelle empfangen wurden. Es wird empfohlen, dass dieses Verhältnis weniger als 5 % aller Eingabe-CWs beträgt.

Detaillierte Informationen

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.

Nicht korrigierbarer FEC-Prozentsatz für Upstream

Beschreibung

Prozentsatz der auf diesem Kanal empfangenen CWs mit nicht korrigierbaren Fehlern Dies schließt alle CWs ein, unabhängig davon, ob sie Teil von Frames waren, die für dieses Gerät bestimmt sind.

Formel

%Nicht korrigierbar = [(EU1 - EU0)/ [(EU1 - EU0) + (EC1 - EC0) + (C₁ - C_{0)] * 100}

• C = docsIfSigQUnerrored

• _Ec = docsIfSigQCorrecteds

• _Eu = docsIfSigQUnCorrectables

Net-Regel

Werte >0,5 % der empfangenen CWs sind gelb hervorgehoben.

Werte >=1% der empfangenen CWs sind fett rot.

Net-Info

Drops percentage for input CWs (Prozentanteil verlorener CWs für Eingabe) zeigt den Prozentsatz der CWs, die für Eingabe verworfen wurden, bezogen auf die Gesamtzahl der CWs, die auf dieser Schnittstelle empfangen wurden. Es wird empfohlen, dass dieser Quotient weniger als 0,5 % aller Input-CWs beträgt.

Hinweis: Bestimmte "Echtzeit"-Services wie VoIP erfordern u. U. eine strengere Überwachung. Ein nicht korrigierbarer FEC-Wert von 1 % kann immer noch ausreichen, um Paketverluste zu verursachen, abhängig davon, ob der Verlust ausbricht oder zufällig auftritt.

Detaillierte Informationen

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.

Upstream-SNR

Beschreibung

SNR wie für diesen Kanal wahrgenommen. In CMTS beschreibt das durchschnittliche Signal-Rausch-Signal des Upstream-Kanals.

Formel

SNR = docsIfSigQSignalNoise / 10

Net-Regel

Werte <27 dB sind gelb hervorgehoben.

Werte <23 dB sind fett rot.

Net-Info

DOCSIS gibt eine CNR-Mindestleistung (digital gleichwertig mit SNR) von 25 dB an. Je nach konfiguriertem Upstream-Modulationsprofil (QPSK oder 16-QAM) muss die SNR-Mindestgröße von 25 dB möglicherweise erhöht werden.

Detaillierte Informationen

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.

Beispiel zum Ziehen von OIDs für FEC-Zähler pro Modem auf einer MC28U- oder 5x20-Linecard

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

Um die Codeword-Zähler dieses Modems zu finden, benötigen Sie zunächst zwei Informationen:

• Der SNMP Interface Index der Kabel 6/0-Schnittstelle.

• Das Modem ist docsIfCmtsServiceNewCmStatusIndex.

Suchen Sie mit dem folgenden Befehl den ifIndex des Kabels 6/0:

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

Suchen Sie die docsIfCmtsServiceNewCmStatusIndex des Modems mit SID 50 auf der Schnittstelle mit ifIndex 10 (Kabel 6/0) mit dem folgenden Befehl:

% snmpwalk -cpublic 172.18.73.167 docsIfCmtsServiceNewCmStatusIndex.10.50

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

Nachdem Sie jetzt das docsIfCmtsServiceNewCmStatusIndex des Modems (983090) haben, können Sie die folgenden FEC-Zähler finden:

• Empfangene gute Codewörter (docsIfCmtsCmStatusUnerrored)

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

  Hinweis: Der Zähler "Unerrored" ist seit der Ausgabe des Befehls show interface cable etwas gestiegen.

• Empfangene korrigierte Codewörter (docsIfCmtsCmStatusCorrecteds)

  % snmpget -cpublic 172.18.73.167 docsIfCmtsCmStatusCorrecteds.983090
  
  DOCS-IF-MIB::docsIfCmtsCmStatusCorrecteds.983090 = Counter32: 0
           

• Empfangene unkorrigierte Codewörter (docsIfCmtsCmStatusUnCorrectables)

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

Zugehörige Informationen

• Verständnis des Datendurchsatzes in einer DOCSIS-Welt
• Upstream-Modulationsprofile für Kabel-Linecards
• DOCSIS-Funkfrequenzschnittstelle - Spezifikation
• Unterstützung von Breitbandkabeltechnologie
• Technischer Support - Cisco Systems