Per far funzionare una rete dati ad alta velocità (HSD) su un impianto di cavi coassiali/in fibra ibrida è necessario un livello significativo di controllo della qualità per garantire l'integrità dei dati e il massimo livello di trasmissione dei dati. I due metodi generalmente accettati con cui i provider di servizi via cavo possono misurare la qualità dei dati sono il monitoraggio del bit error rate (BER) o il packet error rate (PER).
Lo standard DOCSIS (Data Over Cable Service Interface Specification) definisce i requisiti che ogni provider di servizi via cavo deve mantenere per trasportare in modo affidabile il traffico dati IP. Una funzionalità importante di DOCSIS soddisfa la necessità di proteggere i dati IP da interferenze della radiofrequenza (RF). La funzionalità DOCSIS utilizza per mantenere l'integrità dei dati IP sugli impianti di cablaggio HFC con la codifica Reed-Solomon Forward Error Correction (FEC).
Fondamentalmente, la codifica FEC protegge i dati IP e i messaggi di gestione DOCSIS dagli errori di simbolo causati da rumore e altre limitazioni. La caratteristica unica di FEC è la capacità di rilevare gli errori dei simboli e correggerli. Pertanto, DOCSIS specifica che tutti i dati IP trasmessi su un impianto HFC devono passare attraverso un codificatore Reed-Solomon, in cui i byte di parità aggiuntivi vengono aggiunti ai frame di dati per garantire che siano protetti da errori e meno soggetti a compromessi.
Nota: la funzione FEC non funziona correttamente se gli errori vengono generati da un rumore d'impulso che crea molti errori in successione. Gli errori causati dal rumore impulsivo vengono affrontati a valle con l'uso dell'interfoliazione per far apparire gli errori sparsi, che FEC è in grado di correggere efficacemente. DOCSIS 2.0 ha aggiunto l'interfoliazione a monte, che aiuta a risolvere questo tipo di danno a monte (Stati Uniti), ma non è disponibile sui modem via cavo 1.x (CM).
Indubbiamente, il percorso di ritorno della rete via cavo o la rete a monte è particolarmente vulnerabile al rumore e ai problemi correlati. Tali disturbi possono essere impulsi, disturbi in entrata, disturbi termici, ritagli laser e così via. Senza la codifica FEC, la probabilità che un pacchetto venga scartato a causa di errori di bit è molto elevata. Gli errori FEC su un impianto cablato non sono l'unica misura di qualità. È necessario considerare altre variabili, ad esempio il rapporto vettore/rumore (CNR).
Lo standard DOCSIS include i parametri consigliati per le prestazioni RF TV via cavo downstream e upstream. In particolare, la sezione 2.3.2 della specifica RFI (Radio Frequency Interference), Presuned Upstream RF Channel Transmission Characteristics afferma quanto segue:
Il rapporto portante-interferenza più l'ingresso (la somma di rumore, distorsione, distorsione del percorso comune e modulazione incrociata e la somma dei segnali in entrata discreti e a banda larga, escluso il rumore d'impulso) non sarà inferiore a 25 dB. |
In altre parole, il CNR US DOCSIS minimo raccomandato è 25 dB. Ai fini del presente documento, il CNR è definito come il rapporto vettore/rumore prima che raggiunga il chip del demodulatore (dominio RF), misurato da un analizzatore di spettro. Al contrario, SNR è definito come il rapporto segnale-rumore del chip del ricevitore US (CMTS) del modem via cavo dopo che la portante è stata demodulata per fornire un rapporto segnale-rumore puro a banda base.
Pertanto, se si guarda la lettura dell'SNR su un Cisco uBR7246 e si vede un numero come 30 dB, è facile supporre che la parte a monte sembri incontrare o addirittura superare la DOCSIS e che le cose nel mondo RF vadano bene. Tuttavia, non sempre è così. DOCSIS non specifica l'SNR e la stima dell'SNR del CMTS non è la stessa cosa del CNR che si misura con un analizzatore di spettro.
In questo documento vengono illustrati i calcoli stimati dell'SNR upstream dell'uBR e i contatori FEC dell'uBR e viene illustrato il motivo per cui queste due variabili devono essere costantemente valutate per garantire la qualità dell'HSD negli ambienti HFC.
La stima SNR dell'uBR può a volte essere fuorviante, e dovrebbe essere considerata solo un punto di partenza quando si tratta di controllare l'integrità dello spettro RF a monte. La lettura SNR sulla scheda di linea uBR MC16C è fornita dal chip US, ma la lettura non è necessariamente un indicatore affidabile di "mondo reale" di alterazioni della RF, come rumore impulsivo di tipo, entrata discreta e così via. Ciò non significa che la lettura SNR degli Stati Uniti non sia accurata. In ambienti con poche alterazioni a monte (ad esempio, rumore d'impulso, ingresso, distorsione del percorso comune e così via), la stima SNR degli Stati Uniti tiene traccia numericamente del CNR in meno di un paio di decibel, quando il CNR è compreso nell'intervallo tra 15 e 25 dB. È accurato con il rumore bianco di gaussian additivo (AWGN) come unico deterioramento; nel mondo reale, tuttavia, la precisione di questi numeri può variare. Ciò dipende dalla natura delle riduzioni di valore e riflette meglio il tasso di errore di modulazione (MER) piuttosto che il CNR.
Questa sezione mostra alcuni esempi di come ottenere la stima SNR a monte da Cisco uBR7200 e uBR10K (vedere anche l'Appendice). Tutti i comandi e gli output dei comandi dell'interfaccia della riga di comando (CLI) sono tratti dal software Cisco IOS® versione 12.2(15)BC2a, a meno che non sia specificato diversamente.
Si noti che per "scheda S" si intende una scheda di linea per cavi con funzionalità di analisi dello spettro hardware incorporate, mentre per "scheda C" si intende una scheda di linea per cavi priva di tale funzionalità. In alcune impostazioni, la scheda S riporta CNR invece di SNR, perché dispone di hardware integrato per eseguire le funzioni di analisi dello spettro.
Suggerimento: quando si raccoglie l'output dei comandi CLI del software Cisco IOS a scopo di risoluzione dei problemi o per l'inoltro al supporto tecnico Cisco, ricordarsi di abilitare il timestamp del prompt di esecuzione del terminale, in modo che ogni riga dell'output del comando CLI sia accompagnata da un timestamp e dal carico corrente della CPU sul CMTS.
Per schede 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
Per le schede C o S a cui non sono assegnati gruppi di spettro:
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
Si consiglia di mantenere il livello USA impostato sul valore predefinito di 0 dBmV e utilizzare attenuatori esterni per forzare i modem a trasmettere a livelli più elevati, se necessario.
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
Suggerimento: il comando phy può essere usato per segnalare l'SNR anche se CNR è riportato nel comando show controller. Questa funzione è particolarmente utile perché l'SNR viene segnalato dopo l'annullamento dell'ingresso e il CNR prima dell'annullamento dell'ingresso.
Nota: l'SNR è elencato per modem nel codice EC con i dettagli del modem via cavo visualizzati.
Il comando phy elenca anche altri attributi del livello fisico se remote-query è configurato. È possibile immettere le tre righe di codice seguenti per attivare la query remota:
snmp-server manager snmp-server community public ro cable modem remote-query 3 public
Sono stati usati tre secondi per una risposta rapida, che potrebbe non essere consigliata in un CMTS con carico elevato. La stringa della community di sola lettura predefinita nella maggior parte dei modem è pubblica.
Nota: ignorare la voce di microriflessione, in quanto è per DS ed è limitata dall'accuratezza dell'implementazione del produttore 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
Con questo comando viene elencato SNR quando si utilizza una scheda C. Quando si utilizza una scheda S e si assegnano gruppi di spettro, viene indicato il CNR. Il comando show cable modem mac-address verbose funziona correttamente.
Le schede S consentono inoltre di visualizzare la soglia del rumore con questo comando:
ubr7246-2# show controller cable6/0 upstream 0 spectrum ? <5-55> start frequency in MHz <5000-55000> start frequency in KHz <5000000-55000000> start frequency in Hz A.B.C.D IP address of the modem H.H.H MAC address of the modem
L'aggiunta dell'indirizzo IP o MAC del modem al comando mostra la potenza e la larghezza del canale burst del modem.
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 *******
L'output mostra il rumore sotto la portante e ad altre frequenze.
Oltre alla CLI, è possibile utilizzare strumenti di gestione della rete basati su SNMP, ad esempio Cisco Broadband Troubleshooter (CBT), per visualizzare lo spettro US e altri attributi. Inoltre, CiscoWorks può essere utilizzato per monitorare l'SNR come riportato dalle schede di linea dei cavi tramite l'oggetto docsiIfSigQSignalNoise:
DOCS-IF-MIB docsIfSigQSignalNoise .1.3.6.1.2.1.10.127.1.1.4.1.5 Signal/Noise ratio as perceived for this channel. At the CM, describes the Signal/Noise of the downstream channel. At the CMTS, describes the average Signal/Noise of the upstream channel.
Nota: le letture individuali di CM SNR sono disponibili solo sulle schede di linea MC5x20S e MC28U. Queste nuove schede di linea incorporano la funzione di cancellazione dell'ingresso che può migliorare le prestazioni ma può fornire letture SNR fuorvianti. Le letture SNR sono dopo la cancellazione in ingresso; quindi, se la cancellazione dell'ingresso rimuove matematicamente l'ingresso, l'SNR potrebbe riportare un rapporto molto migliore rispetto all'effettivo rapporto portante-interferenza.
Nota: quando si utilizzano i gruppi di spettro su una scheda S, il comando show controllers seleziona in modo casuale le letture CNR da tutti i CM di tale scheda, il che potrebbe essere leggermente diverso, dando l'impressione di una porta USA o CNR instabile.
La modalità da utilizzare in un analizzatore di spettro è la modalità di azzeramento dell'estensione. Questa è la modalità dominio temporale in cui la visualizzazione è ampiezza rispetto al tempo piuttosto che ampiezza rispetto alla frequenza. Questa modalità è molto utile quando si visualizza il traffico di dati bursty in natura. La Figura 1 mostra un analizzatore di spettro in zero-span (dominio temporale) mentre osserva il traffico a monte da un CM.
Figura 1 - Visualizzazione dell'estensione zero su un analizzatore di spettro
I pacchetti di dati possono essere visualizzati nella Figura 1, insieme alle richieste del modem e al rumore d'impulso. Questa funzione è molto utile per misurare i livelli digitali medi e osservare i rumori e l'ingresso, come mostrato nella Figura 2.
Figura 2 - Misurazione dell'estensione zero dell'ampiezza portante digitalmente modulata a monte
Lo zero-span può essere usato anche per verificare se i pacchetti si scontrano tra loro a causa di intervalli errati, splitter dell'headend scadente o isolamento del combinatore. Un pacchetto destinato a una porta a monte CMTS è "con perdite" su un'altra porta a monte. Fare riferimento ai white paper e ai documenti elencati nella sezione Informazioni correlate di questo documento. Per una descrizione della procedura di misurazione dell'intervallo zero, fare riferimento a Collegamento del router Cisco serie uBR7200 all'headend del cavo.
Praticamente tutti i problemi di RF citati finora in questo documento possono peggiorare le prestazioni a monte e manifestarsi come una scarsa velocità di trasmissione dei dati senza essere necessariamente riflessi come un basso livello di SNR. L'osservazione di errori FEC non correggibili (analoghi ai valori di BER e PER insufficienti), anche se l'SNR sembra essere al di sopra dello standard DOCSIS minimo, potrebbe indicare altri problemi temporanei che devono essere risolti. Ci potrebbe anche essere un CM canaglia che causa errori e una scarsa lettura SNR per tutti gli altri CM sullo stesso USA. In questo caso, il CNR misurato su un analizzatore di spettro sarebbe corretto, ma il CMTS segnalerebbe il contrario.
Tenere presente che la codifica FEC Reed-Solomon viene usata per aggiungere byte di parità ridondanti ai pacchetti di dati, in modo da consentire il rilevamento e la correzione degli errori di burst introdotti dall'impianto cablato.
In un ambiente ideale, gli errori misurabili dei bit (correggibili o non correggibili con la funzione FEC) dovrebbero verificarsi raramente. Tuttavia, quando si verificano errori FEC non correggibili, gli effetti possono essere gravi e possono essere causati da una serie di fattori diversi. Questo è un elenco di eventi noti che potrebbero introdurre errori FEC non correggibili a monte e che devono essere presi in considerazione per la risoluzione dei problemi relativi agli errori FEC:
interferenza del trasmettitore di sweep
sovraccarico amplificatore (compressione, che è una forma di clipping)
ritaglio laser
rumore impulsivo o interferenza in entrata
connessioni libere o intermittenti
isolamento del combinatore o dello splitter a monte insufficiente
modem difettosi
Esistono due metodi per raccogliere le informazioni FEC:
CLI
Polling SNMP object identifier (OID)
Questo è un esempio di come raccogliere le informazioni FEC usando la CLI (vedere anche l'Appendice):
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: il numero totale di blocchi FEC (buoni e cattivi) ricevuti da tutte le porte a monte associate a un determinato downstream.
UnCorFECBlks: il numero totale di blocchi FEC ricevuti da tutte le porte a monte associate a un determinato flusso a valle, che erano così danneggiati dal rumore o in entrata da non poter essere corretti o recuperati dall'algoritmo FEC.
CorFECBlks: il numero totale di blocchi FEC ricevuti da tutte le porte a monte associate a un determinato flusso, leggermente danneggiati dal rumore o dall'ingresso e che possono essere corretti e recuperati dall'algoritmo FEC.
I burst di manutenzione della stazione incrementano il contatore FECBlks di circa 2 per x secondi, dove x è l'intervallo di polling minimo (come mostrato nel comando show cable hop) diviso per 1000. Anche la query remota incrementa questo contatore, così come la manutenzione iniziale quando i modem sono in linea. Poiché la manutenzione iniziale avviene durante il tempo di contesa, potrebbero verificarsi collisioni e successivi errori FEC non correggibili.
Suggerimento: prima di presumere che gli Stati Uniti siano instabili perché i contatori FEC non correggibili sono in aumento, accertarsi che i modem non stiano variando o non stiano online. Inoltre, il valore NoUwCollNoEngy potrebbe aumentare in presenza di modem con problemi di temporizzazione. Unique Word è specifico di BRCM, non di DOCSIS, ed è l'ultimo byte del preambolo.
È possibile stimare una percentuale prendendo UnCorrFECBlks / FECBlks × 100. Il contatore FECBlks è il totale dei blocchi FEC inviati, buoni o cattivi. Questo output viene generato per l'intero dominio MAC (tutti gli Stati Uniti). È meglio guardare i contatori tra un periodo di tempo impostato per vedere il delta.
Nota: uno svantaggio della raccolta di informazioni FEC mediante la CLI è che i UnCorFECBlks, CorFECBlks, e i FECBlks totali non sono separati per upstream.
Per esaminare le informazioni FEC per upstream, è necessario utilizzare gli OID SNMP. È possibile usare il comando show cable hop anche per visualizzare gli errori FEC correggibili o non correggibili per ciascuna porta a monte, ma non per visualizzare il totale dei blocchi FEC.
ubr7246# show cable hop Load for five secs: 5%/1%; one minute: 5%; five minutes: 5% Time source is NTP, 00:17:13.552 UTC Sat Feb 7 2004 Upstream Port Poll Missed Min Missed Hop Hop Corr Uncorr Port Status Rate Poll Poll Poll Thres Period FEC FEC (ms) Count Sample Pcnt Pcnt (sec) Errors Errors Cable6/0/U0 21.810 MHz 1000 0 10 0% 75% 15 2664305 3404 Cable6/0/U1 admindown 1000 * * * frequency not set * * * 0 0 Cable6/0/U2 10.000 MHz 1000 * * *set to fixed frequency * * * 0 0
Nota: il comando clear counters elimina solo i contatori show interface e show cable hop, ma non il contatore show controller. I contatori del controller possono essere cancellati solo se il CMTS viene ricaricato o se l'interfaccia viene riaccesa con questo comando:
ubr# cable power off slot/card
Per enfatizzare, è utile ripetere che gli errori FEC non correggibili si traducono in pacchetti ignorati e molto probabilmente causano una scarsa velocità di trasmissione dei dati a monte. Prima che gli eventi raggiungano questa fase critica, tuttavia, ci sono dei predittori e delle indicazioni che le prestazioni a monte stiano peggiorando. Gli errori FEC correggibili indicano che la velocità di trasmissione dei dati a monte è in diminuzione e segnalano la possibilità di futuri errori FEC non correggibili.
Suggerimento: se il contatore Uncorr aumenta molto più rapidamente del contatore Corr, allora il problema potrebbe essere dovuto al rumore impulso. Se il contatore Corr aumenta tanto velocemente (o più rapidamente) del contatore Uncorr, allora è probabilmente correlato ad AWGN o è un problema di entrata allo stato stazionario come la Citizen Band (CB), la radio a onde corte, la distorsione del percorso comune (CPD), e così via.
I tre OID SNMP del file MIB SNMP DOCS-IF-MIB vengono utilizzati per raccogliere e analizzare gli errori FEC (FEC non errati, corretti e non correggibili - vedere anche l'Appendice):
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.
Poiché questi tre MIB sono valori assoluti (basati sul numero totale di blocchi di dati FEC che il CMTS sta ricevendo), il calcolo della percentuale offre un quadro migliore delle prestazioni effettive di throughput a monte. Utilizzare le seguenti formule:
Cx = docsIfSigQUnerroreds all'ora x
Ecx = docsIfSigQCorrected al tempo x
Eux = docsIfSigQUncorrectables al momento x
% Correttibile = [(Ec1 - Ec0)/ [(Eu1 - Eu0) + (Ec1 - Ec0) + (C1 - C0)] * 100
% Irreversibile = [(Eu1 - Eu0)/ [(Eu1 - Eu0) + (Ec1 - Ec0) + (C1 - C0)] * 100
Nota: gli importi non correggibili più gli errori più le correzioni corrispondono al numero totale di parole di codice (CW; noti anche come blocchi di dati FEC) ricevuti su questo US, comprese tutte le CW, che facessero o meno parte di frame destinati al CMTS. Le dimensioni di un peso variabile sono determinate dal profilo di modulazione.
Se un pacchetto US viene scartato, incrementa un contatore Uncorr FEC. Questo avviene nel livello fisico. Se non è possibile visualizzare l'ID servizio (SID) o l'indirizzo di origine (livello 2), è possibile che venga chiesto in che modo il CMTS distingue il pacchetto che viene scartato. Tuttavia, il SID CM è incluso nell'intestazione DOCSIS.
Esempio di esplosione negli Stati Uniti:
(preambolo) + {(docsis hdr = 6 byte) + (BPI+, docsis extended hdr = da 4 a 7 byte) + 1500 ethernet + 18 ethernet header} + (guardband)
Tutto il contenuto compreso tra { e } viene sommato, tagliato in CW in base al profilo di modulazione, quindi 2×T viene aggiunto a ciascun CW. Quindi, tecnicamente, se il codice specifico che contiene il SID viene scartato, come può il CMTS distinguere da quale modem è stato inviato? Un modo per ottenere questo risultato è usare lo scheduler del CMTS, che conosce l'ora in cui determinati pacchetti arriverebbero da modem specifici.
Per visualizzare i valori FEC per modem, usare il comando show interface cableport/slot sid sid-number contatore verbose. È inoltre possibile recuperarli tramite SNMP utilizzando gli OID seguenti:
Parole codice valide ricevute (docsIfCmtsCmStatusUnerroreds)
Parole codice corrette ricevute (docsIfCmtsCmStatusCorrecteds)
Parole codice non corrette ricevute (docsIfCmtsCmStatusUncorrectables)
Nota: attualmente è rilevante solo per le schede di linea MC28U e 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
Questa operazione è specifica per questo modem e i contatori vengono aggiornati ogni 10 secondi circa.
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
Il comando show cable hop restituisce uno o più errori Uncorr FEC. Ciò è probabilmente dovuto al fatto che è stato eliminato un cavo CW che apparteneva a un altro modem.
Sarebbe interessante visualizzare un grafico di errori FEC per CM eseguendo il polling dei MIB e utilizzando il grafico del traffico multi-router (MRTG) o altri software, ad esempio Cisco BT. Questa opzione può essere utilizzata per verificare se determinati modem hanno un ritardo del gruppo insufficiente, microriflessioni e così via. Questo problema riguarda solo un modem specifico.
Un altro comando che elenca gli errori è il comando show interface cable5/1/0 upstream. Si tratta di pacchetti, che sono diversi dalle licenze FEC. Un pacchetto può essere costituito da diversi tipi di peso variabile.
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)
Queste sono le definizioni dei termini:
trasmissioni: frame di trasmissione ricevuti.
multicast - Frame multicast ricevuti.
unicast - Frame unicast ricevuti.
scarti - Solo incrementi sulla scheda di linea MC5x20S. Elenca i pacchetti scartati a causa di diverse condizioni di errore specifiche della scheda, non del frame effettivo.
errors - Il totale di un intero intervallo di errori, molti dei quali non sono rilevanti. Gli errori conteggiati da questo valore sono relativi alle schede basate su BCM3210 come MC16C e MC28C:
Numero di slot a monte allocati in cui il preambolo e la parola univoca non sono stati ricevuti correttamente.
Numero di frame non correggibili ricevuti.
Collisioni nelle opportunità di "richiesta" della larghezza di banda.
Collisioni negli slot "richiesta/dati" (questi tipi di slot non si verificano sui Cisco CMTS).
Frame danneggiati ricevuti durante le opportunità di "richiesta" della larghezza di banda.
Frame danneggiati ricevuti durante gli slot "richiesta/dati".
Numero di richieste Range danneggiate ascoltate.
Per le schede di linea basate su JIB come MC5x20 e MC28U:
Frame errati a monte che, per qualche motivo, non sono classificati come HCS (Header Check Sequence) o CRC (Cyclic Redundancy Check) errati.
Frame upstream con problemi HCS.
Frame upstream con errori CRC.
Peso variabile non correggibile ricevuto.
Collisioni nella richiesta di larghezza di banda IUC.
protocollo sconosciuto - Numero di frame ricevuti non IP, ARP (Address Resolution Protocol) o PPPoE (Point to Point Protocol over Ethernet). Questo contatore include anche frame con intestazioni DOCSIS non valide o opzioni di intestazione non valide.
input pacchetti: totale di trasmissioni, multicast e unicast.
non correggibile - Numero totale di fotogrammi contenenti almeno un peso variabile FEC non correggibile. In questo campo viene visualizzato N/D per MC5x20 e 28U. Utilizzare la colonna Annulla errori FEC in show cable hop per avere un'idea degli errori non correggibili.
rumore: per le schede basate su BCM3210 come MC16C e MC28C, si tratta del numero di frame danneggiati ricevuti in intervalli di "richiesta" o "di variazione" della larghezza di banda. In questo modo il numero diventa un sottoinsieme dei numeri errati.
Frame danneggiati ricevuti durante le opportunità di "richiesta" della larghezza di banda
Frame danneggiati ricevuti durante gli slot "richiesta/dati".
Numero di richieste Range danneggiate ascoltate.
Per le schede basate su JIB come MC5x20 questo contatore non aumenta affatto.
microriflessioni - Numero di microriflessioni; sempre impostato su 0.
Gli errori e i contatori del rumore non contano solo i frame danneggiati, contano anche elementi come le collisioni di richieste ad intervallo iniziale e le collisioni di richieste di larghezza di banda. Quindi, un contatore del rumore in aumento non sempre indica che c'è un problema. Il fatto che il cliente disponga di molti modem che tentano di connettersi o di modem che eseguono altre trasmissioni potrebbe causare un numero maggiore di collisioni. Il contatore disturbo è in realtà un sottoinsieme del contatore errori perché il disturbo include gli ultimi tre componenti del contatore errori.
Sulla base dell'esperienza e dei test di laboratorio eseguiti dal gruppo Advance Services e Rapid Response di Cisco, ecco alcune osservazioni relative a FEC e alle scarse prestazioni a monte:
La presenza di errori FEC non correggibili è un'ottima misura quando il rumore raggiunge un livello intollerabile o quando i pacchetti si scontrano tra loro a causa di tempi errati, uno splitter dell'headend scadente o l'isolamento del combinatore. Per quanto riguarda quest'ultimo, un pacchetto destinato a una porta CMTS a monte "perde" su un'altra porta a monte a causa del cattivo isolamento.
Un grande aumento degli errori FEC non correggibili causa problemi di qualità della voce.
L'aumento del livello di rumore causato da errori FEC correggibili. Gli errori FEC correggibili non causano perdite di pacchetti o una scarsa qualità della voce, purché non vi siano errori FEC non correggibili associati.
Aumentare i byte FEC T nel profilo di modulazione statunitense può aiutare fino a un certo punto, ma dipende dalla fonte di rumore. Una copertura FEC del 7-10% sembra ottimale.
Dalle osservazioni precedenti risulta chiaramente che il sondaggio dei CMTS per individuare gli errori FEC non correggibili è valido. Il VoIP (Voice over IP) sui cavi è particolarmente sensibile agli errori FEC non correggibili. Se la percentuale di errori FEC non correggibili è abbastanza alta, si verificano problemi di qualità della voce, mentre i dati IP potrebbero risentirne solo in minima parte.
Infine, se la lettura SNR del chip USA è fuorviante quando vengono introdotti problemi transitori rapidi di RF (come accennato in precedenza) ma gli errori FEC non correggibili si verificano ancora, la risoluzione del problema può diventare notevolmente più complessa.
La Figura 3 evidenzia un esempio di Stati Uniti con un livello basso di SNR e al tempo stesso di errori FEC non correggibili e correggibili, evidenziando la stretta relazione tra questi due parametri nella misurazione delle prestazioni a monte.
Figura 3 - Errori SNR e FEC nel tempo
Nel primo grafico viene visualizzata la percentuale di errore FEC non correggibile e correggibile, mentre nel grafico inferiore vengono indicate le letture SNR insufficienti nella stessa istanza nel tempo. Un controllo rapido della portante a monte modulata digitalmente su un analizzatore di spettro (come ad esempio un Agilent HP8591C) mostrerebbe probabilmente il rumore in-channel a livelli abbastanza elevati. Problemi di RF a monte di natura impulsiva possono essere confermati utilizzando apparecchiature di test di terze parti (come Huk CM1000 - fare riferimento al sito Web Sunrise Telecom - o Acterna DSAM) che possono misurare la frequenza di errore dei blocchi a monte (simile a BER). Ciò consentirebbe di verificare l'esistenza di un probabile problema di radiofrequenza, anche quando la lettura SNR negli Stati Uniti sembra essere buona.
Il punto è che se la lettura SNR degli Stati Uniti sembra essere buona, non presumere automaticamente che la radiofrequenza sia buona. Potrebbe essere necessaria una piccola ricerca con apparecchiature di test adeguate per determinare esattamente cosa sta succedendo nel dominio RF. Le probabilità sono abbastanza buone che lo spettro RF non sia così pulito come si pensava all'inizio.
In questa sezione vengono descritti in dettaglio i parametri a monte da monitorare.
Percentuale di peso variabile ricevuti su questo canale con errori non correggibili. Ciò include tutti i Peso variabile, anche se non facevano parte di frame destinati a questo dispositivo.
%Rettificabile = [(Ec1 - Ec0)/ [(Eu1 - Eu0) + (Ec1 - Ec0) + (C1 - C0)] * 100
C = docsIfSigQUnerroreds
Ec = docsIfSigQCorrected
Ue = docsIfSigQUncorrectables
I valori >2,5% dei pacchetti ricevuti sono evidenziati in giallo.
I valori >=5% dei pacchetti ricevuti sono in grassetto rosso.
Percentuale di peso variabile di input con errori FEC correggibili, in relazione al numero totale di peso variabile ricevuti su quell'interfaccia. Si consiglia che tale rapporto sia inferiore al 5% di tutte le Peso variabile in entrata.
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.
Percentuale di peso variabile ricevuti su questo canale con errori non correggibili. Ciò include tutti i Peso variabile, anche se non facevano parte di frame destinati a questo dispositivo.
%Irreversibile = [(Eu1 - Eu0)/ [(Eu1 - Eu0) + (Ec1 - Ec0) + (C1 - C0)] * 100
C = docsIfSigQUnerroreds
Ec = docsIfSigQCorrected
Ue = docsIfSigQUncorrectables
I valori >0,5% dei peso variabile ricevuti sono evidenziati in giallo.
I valori >=1% dei peso variabile ricevuti sono in grassetto rosso.
Percentuale rilasci per peso variabile di input indica la percentuale di peso variabile scartato in input rispetto al numero totale di peso variabile ricevuti su tale interfaccia. Si consiglia che tale rapporto sia inferiore allo 0,5% di tutte le Peso variabile in entrata.
Nota: servizi "in tempo reale" specifici, come il VoIP, potrebbero richiedere un monitoraggio più rigoroso. Un valore FEC non correggibile all'1% potrebbe comunque essere una perdita di pacchetto sufficiente a causare problemi di qualità della voce, a seconda che la perdita sia burst o casuale.
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 percepito per questo canale. Nel CMTS, descrive il rapporto segnale-rumore medio del canale a monte.
SNR = docsIfSigQSignalNoise / 10
I valori <27 dB sono evidenziati in giallo.
I valori <23 dB sono in grassetto rosso.
DOCSIS specifica un CNR minimo (digitalmente equivalente a SNR) di 25 dB. A seconda del profilo di modulazione upstream configurato (QPSK o 16-QAM), potrebbe essere necessario aumentare il valore SNR minimo di 25 dB.
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.
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
Per trovare i contatori di Codeword di questo modem, è necessario innanzitutto ottenere due informazioni:
Indice dell'interfaccia SNMP del cavo 6/0.
DocIfCmtsServiceNewCmStatusIndex del modem.
Individuare l'ifIndex del cavo 6/0 con questo comando:
% snmpwalk -cpublic 172.18.73.167 ifDescr | grep Cable6/0 RFC1213-MIB::ifDescr.10 = STRING: "Cable6/0" !--- ifIndex of cable 6/0 is "10". RFC1213-MIB::ifDescr.36 = STRING: "Cable6/0-upstream0" RFC1213-MIB::ifDescr.37 = STRING: "Cable6/0-upstream1" RFC1213-MIB::ifDescr.38 = STRING: "Cable6/0-upstream2" RFC1213-MIB::ifDescr.39 = STRING: "Cable6/0-upstream3" RFC1213-MIB::ifDescr.40 = STRING: "Cable6/0-downstream"
Individuare docsIfCmtsServiceNewCmStatusIndex del modem con SID 50 sull'interfaccia con ifIndex 10 (cavo 6/0) con questo comando:
% snmpwalk -cpublic 172.18.73.167 docsIfCmtsServiceNewCmStatusIndex.10.50 DOCS-IF-MIB::docsIfCmtsServiceNewCmStatusIndex.10.50 = INTEGER: 983090
Ora che si dispone di docsIfCmtsServiceNewCmStatusIndex del modem (983090), è possibile trovare i seguenti contatori FEC:
Parole codice valide ricevute (docsIfCmtsCmStatusUnerroreds)
% snmpget -cpublic 172.18.73.167 docsIfCmtsCmStatusUnerroreds.983090 DOCS-IF-MIB::docsIfCmtsCmStatusUnerroreds.983090 = Counter32: 8165
Nota: il contatore Unerroreds è aumentato leggermente nel tempo dopo l'esecuzione del comando show interface cable.
Parole codice corrette ricevute (docsIfCmtsCmStatusCorrecteds)
% snmpget -cpublic 172.18.73.167 docsIfCmtsCmStatusCorrecteds.983090 DOCS-IF-MIB::docsIfCmtsCmStatusCorrecteds.983090 = Counter32: 0
Parole codice non corrette ricevute (docsIfCmtsCmStatusUncorrectables)
% snmpget -cpublic 172.18.73.167 docsIfCmtsCmStatusUncorrectables.983090 DOCS-IF-MIB::docsIfCmtsCmStatusUncorrectables.983090 = Counter32: 2