内容

概要

信号対雑音比（SNR）

SNR および CNR 示数を得る方法

ノイズ フロアの表示方法

ゼロスパンでのアップストリーム搬送波

前方誤り訂正

SNMP を使用して FEC カウンタを取得する方法

モデムごとの FEC カウンタ

アップストリーム パケット カウンタ

結論

付録

アップストリームが修正可能なFECパーセント

アップストリームが修正不可能なFECパーセント

アップストリーム SNR

MC28U か5x20ラインカードで、モデム毎のFECカウンタのためのOIDを取り出す方法例

関連情報

概要

光ファイバ/同軸ハイブリッド（HFC）ケーブル設備で高速データ（HSD）ネットワークを運用するには、非常に高いレベルの品質管理を行い、データの整合性と最高レベルのデータ スループットを保証する必要があります。CATV 事業者がデータ品質を測定する一般的な方法としては、ビット エラー レート（BER）のモニタまたはパケット エラー レート（PER）のモニタという 2 種類の方法があります。

Data Over Cable Service Interface Specification（DOCSIS）には、IP データ トラフィックの信頼性の高い搬送のために CATV 事業者が維持する必要のある要件の概要が定められています。DOCSIS の重要な機能は無線周波数（RF）のノイズの障害から IP データを保護する必要性に対応します。HFC ケーブル設備上での IP データの整合性を維持しやすくするために DOCSIS で使用されている機能は、Reed-Solomon 前方誤り訂正（FEC）エンコーディングです。

基本的に、FEC エンコーディングは、ノイズや他の障害に起因するシンボル エラーから IP データおよび DOCSIS の管理メッセージを保護します。FEC 特有の機能は、シンボル エラーを検出して、これを訂正できることです。したがって、DOCSISでは、HFCプラントで送信されるすべてのIPデータはReed-Solomonエンコーダを通過するように規定されています。このエンコーダでは、余分なパリティバイトがデータフレームに追加され、エラーが発生しにくくなります。

注：インパルスノイズによってエラーが生成され、連続して多数のエラーが発生する場合、FECは正常に動作しません。インパルス ノイズによって生じるエラーはダウンストリームでの問題で、インターリービングを使用することでエラーが蔓延しているように見えます。この場合、修正には FEC が有効です。DOCSIS 2.0ではアップストリームインターリービングが追加されており、このタイプのアップストリーム(US)障害には役立ちますが、1.xケーブルモデム(CM)では使用できません。

問題なく、ケーブルネットワークのリターンパスまたはアップストリームは、特にノイズおよび関連する障害に対して脆弱です。このようなノイズには、インパルス、イングレス ノイズ、サーマル ノイズ、レーザー クリッピングなどがあります。FEC エンコーディングを行わないと、ビット エラーによってパケットのドロップが発生する回数が無視できないものになります。ケーブル設備の FEC エラーが唯一の品質尺度ではありません。carrier-to-noise ratio（CNR）など、他にも考慮する要素があります。

DOCSIS 標準には、ダウンストリームとアップストリームの両方の CATV RF のパフォーマンスについての推奨パラメータが含まれています。具体的には、『Assured Upstream RF Channel Transmission Characteristics』のRadio Frequency Interference（RFI；無線周波数干渉）仕様のセクション2.3.2で、次のように記されています。

搬送波対干渉と入力（ノイズ、歪み、共通パス歪み、混変調の総和、および、ディスクリートおよびブロードバンド入力信号の総和、インパルス ノイズは除外）の比は、25 dB 未満（にならない）。

つまり、推奨される DOCSIS の最小 US CNR 25 dB です。このドキュメントの目的として、CNR は復調チップ（RF ドメイン）に到達する前の搬送波対雑音比として定義します。また測定はスペクトル アナライザで行います。逆に、SNRは、キャリアが復調されて純粋なベースバンドの信号対雑音比が得られた後の、ケーブルモデム終端システム(CMTS)のUSレシーバチップからの信号対雑音比として定義されます。

したがって、Cisco uBR7246 での SNR の示数を調べ、30 dB などの数値がわかると、アップストリームが DOCSIS を満たしているか、超過しているか、さらに RF の環境が良好であるかが容易に想定できます。ところが、常にこれが当てはまるとは限りません。DOCSISではSNRが指定されておらず、CMTSのSNR予測値は、スペクトルアナライザで測定するCNRと同じではありません。

このドキュメントでは、uBRのアップストリームSNR予測計算とuBRのFECカウンタについて説明し、HFC環境でHSD品質を確保するために、これら2つの変数を常に評価する理由を示します。

信号対雑音比（SNR）

uBRのSNR予測値は誤解を招く可能性があり、アップストリームRFスペクトルの整合性をチェックする場合は、開始点としてのみ考慮する必要があります。uBR MC16CラインカードでのSNRの測定値はUSチップによって提供されますが、この測定値は、インパルシブタイプのノイズやディスクリート入力など、「実際の」RF障害の信頼性の高い指標とは必ずしもありません。これは、US SNR の示数が不正確であるという意味ではありません。アップストリーム側での障害（インパルス ノイズ、入力、共通パス歪みなど）がほとんどない環境では、US SNR の推定値は、CNR が 15 ～ 25 dB の範囲であれば、数字的には CNR と数デシベル未満の誤差に納まります。これは付加白色ガウス ノイズ（AWGN）障害単体としては正確です。ただし、実環境では、これらの数値の正確度は状況によってばらつきます。これは、障害の特性によって異なり、CNR よりも変調誤差比（MER）を正確に反映しています。

SNR および CNR 示数を得る方法

このセクションでは、Cisco uBR7200 および uBR10K からアップストリーム SNR の推定値を取得する方法の例について説明します（「付録」も参照してください）。 すべてのコマンドライン インターフェイス（CLI）コマンドとコマンド出力は、特に指定がない場合、Cisco IOS® ソフトウェア リリース 12.2(15)BC2a で採取されたものです。

「Sカード」はハードウェアスペクトル分析機能が組み込まれたケーブルラインカードを指します。「Cカード」は、この機能を持たないケーブルラインカードを指します。ある設定下では、S カードから SNR ではなく CNR が報告されます。これは、スペクトル解析機能を持つハードウェアが組み込まれているためです。

ヒント：トラブルシューティングまたはCiscoテクニカルサポートへの転送のためにCisco IOSソフトウェアCLIコマンドの出力を収集する際は、terminal exec prompt timestampを有効にして、CLIコマンドの出力の各行にタイムスタンプとCMTSの現在のCPU負荷を付付にします。

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

C カードまたはスペクトル グループが割り当てられていない 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

US レベルの設定はデフォルトの 0 dBmV のままにしておき、必要に応じて外付けの減衰器を使用して、必要な場合は、モデムが高いレベルで強制的に送信するようにすることを推奨します。

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

ヒント：phyコマンドを使用すると、show controllersコマンドでCNRが報告された場合でも、SNRを報告できましょう。これは、SNR は入力キャンセルが行われた後で報告されますが、CNR は入力キャンセルの前に報告されるため、非常に便利です。

注：SNRはECコードのモデムごとにshow cable modem detailで表示されます。

phy コマンドでも、remote-query が設定されていれば、他の物理層の属性が一覧されます。リモートクエリをアクティブにするためには、次の 3 行のコードを入力します。

snmp-server manager

snmp-server community public ro

cable modem remote-query 3 public

クイック レスポンスには 3 秒が使用されていましたが、負荷の高い CMTS では推奨しません。ほとんどのモデムでのデフォルトの読み取り専用コミュニティ ストリングは public です。

注：DS用であり、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

このコマンドでは、C カードが使用されている場合に SNR が一覧されます。S カードが使用されていて、スペクトル グループが割り当てられている場合には、CNR が報告されます。show cable modem mac-address verbose コマンドも同様に動作します。

ノイズ フロアの表示方法

S カードを使用すると、次のコマンドでもノイズ フロアを表示できます。

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

モデムの IP アドレスまたは MAC アドレスをコマンドに付加すると、モデムのバースト出力とチャネル幅が表示されます。

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

この出力では、この搬送波における他の周波数でのノイズが示されています。

CLI の他に、Cisco Broadband Troubleshooter（CBT）などの SNMP ベースのネットワーク管理ツールでも US スペクトルや他の属性を表示できます。また、CiscoWorks でも docsiIfSigQSignalNoise オブジェクトを使用して、ケーブル ラインカードから報告される SNR を監視できます。

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.

注：個々のCM SNR測定値は、MC5x20SおよびMC28Uラインカードでのみ使用できます。これらの新しいラインカードには、パフォーマンスを向上させる入力キャンセル機能が組み込まれていますが、このために SNR の示数が誤解を招きやすくなる場合があります。SNR の示数は入力キャンセルの後のものです。したがって、入力キャンセルによって入力が計算上削除されると、実際の搬送波対干渉比よりもはるかに良好な SNR が報告される可能性があります。

注：Sカードでスペクトルグループを使用する場合は、show controllersコマンドを使用して、そのUS上のすべてのCMからCNR測定値をランダムに選択します。これは若干異なる場合があり、不安定なUSポートまたはCNRになります。

ゼロスパンでのアップストリーム搬送波

スペクトル アナライザで使用する価値のあるモードはゼロスパン モードです。このモードは、振幅対周波数ではなく、振幅対時間で表示するタイム ドメイン モードです。このモードは、本質的にバースト状態であるデータ トラフィックを表示する際に非常に役に立ちます。図 1 は、CM からアップストリーム トラフィックを監視している状態での、ゼロスパン（タイム ドメイン）のスペクトル アナライザを示しています。

図1：スペクトルアナライザでのゼロスパンの表示

図 1 には、モデム リクエストとインパルス ノイズとともに、データ パケットが表示されています。これは、図 2 で示すように、平均的なデジタル レベルを計測し、ノイズと入力を観察する場合に非常に便利です。

図2 – アップストリームのデジタル変調された搬送波の振幅のゼロスパン測定

ゼロスパンは、タイミングが悪さや、ヘッドエンド スプリッタまたはコンバイナの切り分けが不十分であることが原因で、パケット同士のコリジョンが起きているかどうかを調べるためにも使用できます。1つのCMTSアップストリームポートを対象とするパケットが、別のアップストリームに「漏えいしている」。このドキュメントの「関連情報」のセクションに記載されている White Paper やドキュメントを参照してください。ゼロスパン測定の説明については、『Cisco uBR7200 シリーズ ルータのケーブル ヘッドエンドへの接続』を参照してください。

実質的には、このドキュメントでこれまでに説明した RF 障害は、すべてアップストリーム パフォーマンスを低下させ、データ スループットが低くなることで表面化しますが、必ずしも SNR の低下となって現れるわけではありません。SNR が DOCSIS 標準の最低値を超えるように見えるにもかかわらず、回復不可能な FEC エラー（BER および PER の低下に類似するもの）が発生する場合は、解決する必要のある別の一時的な問題を示している可能性があります。また、同じ US 上にある他のすべての CM に対してエラーを発生させたり、SNR の示数を低下させたりする不正な CM が存在する可能性もあります。この場合、スペクトル アナライザで測定された CNR は良好に見えますが、CMTS は異なった報告をします。

前方誤り訂正

データ パケットに冗長パリティ バイトを追加するために、リードソロモン FEC エンコーディングが使用されることを思い出してください。これは、ケーブル設備によって生じるバースト エラーの検出と修正を可能にするためのものです。

理想的な状況では、ビット エラー（修正可能または修正不可能な FEC エラー）発生の可能性は、まずありません。しかし、修正不可能な FEC エラーが存在する場合には、重大な影響がある可能性があり、さらに非常にさまざまな要因からの影響がある可能性があります。アップストリームで修正不可能な FEC エラーを引き起こし、FEC エラーのトラブルシューティングの際に考慮する必要のある既知の事象を次に一覧します。

- スイープ トランスミッタの干渉

- 増幅器の過負荷（クリッピングによる圧縮）

- レーザー クリッピング

- 瞬間的なノイズまたは入力の干渉

- 不確実、または途切れがちな接続

- 不十分なアップストリーム コンバイナまたはスプリッタでの切り分け

- 不良モデム

FEC 情報を収集する方法としては、次の 2 つがあります。

- CLI

- SNMP オブジェクト識別子（OID）ポーリング

次に示す例は、CLI を使用して FEC 情報を収集する方法です（「付録」も参照してください）。

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：あるダウンストリームに関連付けられたすべてのアップストリーム ポートで受信された FEC ブロックの総数（良好と不良の両方）。

- UnCorFECBlks：あるダウンストリームに関連付けられたすべてのアップストリーム ポートで受信された FEC ブロックで、ノイズまたは入力によって損傷を受け、FEC アルゴリズムで修正や回復ができなかったものの総数。

- CorFECBlks：あるダウンストリームに関連付けられたすべてのアップストリーム ポートで受信された FEC ブロックで、ノイズまたは入力による損傷がわずかで、FEC アルゴリズムで修正や回復ができたものの総数。

ステーションのメンテナンスのバーストは、FECBlks のカウンタを x 秒あたり約 2 増加させます。ここで x は最小のポーリング間隔（show cable hop コマンドで表示されます）を 1000 で除算したものです。モデムがオンラインになった際の最初のメンテナンス同様、リモート クエリによってもこのカウンタは増加します。最初のメンテナンスはコンテンションの際に行われるため、コリジョンや、それに続く修正不可能な FEC エラーが発生する可能性があります。

ヒント：修正不可能なFECカウンタが増加しているだけで、USが不安定であると仮定する前に、モデムがレンジングを行っていないか、オンラインになるのを確認してください。NoUwCollNoEngy の値はタイミングの問題が発生しているモデムがある場合に増えることもあります。ユニーク ワードは BRCM に固有のものであり、DOCSIS のものではありません。これはプリアンブルの最後の数バイトになります。

パーセンテージは、UnCorrFECBlks / FECBlks × 100を使用して推定できます。FECBlksカウンタは、送信されたFECブロックの総数です。この出力は、MAC ドメイン全体のものです（全 US）。 差分を調べるには、設定されたタイム ピリオド間でのカウンタを調べるのが最善です。

注：CLIを使用してFEC情報を収集する欠点の1つは、UnCorFECBlks、CorFECBlks、およびFECBlksの合計がアップストリームごとに分離されていないことです。

アップストリームごとの FEC 情報を調べるには、SNMP OID を使用する必要があります。また、show cable hop コマンドを使用して、アップストリーム ポートごとの修正可能または修正不可能な FEC エラーを表示できますが、この場合、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

注：clear countersコマンドは、show interfaceとshow cable hopのカウンタをクリアするだけで、show controllersカウンタをクリアしません。このコマンドに関して、コントローラ カウンタがクリアされるのは、CMTS がリロードされた場合、またはインターフェイスの電源のオフ/オンが行われた場合だけです。

ubr# cable power off slot/card

念のため繰り返しますが、修正不可能な FEC エラーによってパケットのドロップが生じ、ほとんどの場合はアップストリーム データのスループットが低下します。一方、イベントがこの重大な状態に到達する前に、アップストリームのパフォーマンスが悪化しているという予測材料または兆候が現れます。修正可能な FEC エラーは、アップストリーム データのスループットが低下しているという指標となり、この先修正不可能な FEC エラーが生じる可能性があるという警告になります。

ヒント： UncorrカウンタがCorrカウンタよりも急激に増加すると、問題はインパルスノイズに関連している可能性があります。Corr カウンタが Uncorr カウンタと同程度に（あるいはさらに速く）増加している場合は、AWGN に関連しているか、市民バンド（CB）、短波放送、Common Path Distortion（CPD）などの定常状態の入力問題が考えられます。

SNMP を使用して FEC カウンタを取得する方法

DOCS-IF-MIB SNMP MIBファイルからのこれらの3つのSNMP OIDは、FECエラーの収集と分析に使用されます(エラー、修正、修正不可のFECも参照)。

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.

これら 3 つの MIB は絶対値であるため（CMTS が受信している FEC データ ブロックの総数に基づいたもの）、比率を計算することにより、実際のアップストリーム スループットをより適切に把握できます。次の式を使用します。

- Cx = x の時点の docsIfSigQUnerroreds

- Ecx = x の時点の docsIfSigQCorrecteds

- Eux = x の時点の docsIfSigQUncorrectables

%訂正可能= [(Ec1-Ec0)/ [(Eu1-Eu0) + (Ec1-Ec0) + (C1 - C_0)]] * 100

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

注：修正不可能、修正不可、修正不可はコードワード(CW;の合計に等しくなります。コードワードの合計には、CMTS 宛てのフレームの一部である場合も、一部でない場合も含め、すべての CW が含まれます。CW のサイズは変調のプロファイルによって決まります。

モデムごとの FEC カウンタ

US パケットがドロップされると、Uncorr FEC カウンタが増加します。これは物理層で発生します。サービス ID（SID）または発信元アドレス（レイヤ 2）を調べる機会がない場合、CMTS でドロップされたパケットを区別する方法について疑問に思う可能性があります。 しかし、CM SID が DOCSIS ヘッダーに含まれています。

US バーストの例：

(プリアンブル) + {(docsis hdr = 6 バイト) + (BPI+, docsis 拡張 hdr = 4 〜 7 バイト) + 1500 イーサネット + 18 イーサネット ヘッダー} + (ガード バンド)

{ と } の間の項はすべて加算され、変調プロファイルに基づいて CW に分けられ、その後 2xT が各 CW に加算されます。したがって、技術的には、SID を保持しているあるコードワードがドロップされた場合、CMTS はどのようにして送信したモデムを識別するのでしょうか。これを行う 1 つの方法は、CMTS のスケジューラを使用することです。このスケジューラでは、特定のモデムからあるパケットが到達する時刻がわかっています。

show interface cableport/slot sid sid-number counter verbose コマンドを使用すると、モデムごとに一覧された FEC 値を表示できます。また、OID を使用して SNMP から値を取得することもできます。

- 受信した良好なコードワード（docsIfCmtsCmStatusUnerroreds）

- 受信した修正済みコード ワード（docsIfCmtsCmStatusCorrecteds）

- 受信した修正されていないコードワード（docsIfCmtsCmStatusUncorrectables）

注：これは現在、MC28Uおよび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

これはこのモデムに特有のもので、カウンタは約 10 秒ごとに更新されます。

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

show cable hop コマンドでは、もう 1 個の修正不可能な FEC エラーが報告されることに注意してください。これはおそらく、たまたま他のモデムに属している CW がドロップされたためです。

MIB をポーリングし、Multi-Router Traffic Grapher（MRTG）や Cisco BT などの他のソフトウェアを使用して、CM ごとの FEC エラーのグラフを調べることは興味深いことです。この方法を使用して、特定のモデムで、グループ遅延、マイクロリフレクションなどの問題が発生していないかどうかを調べることもできます。これは特定のモデムにだけ影響を与える問題と考えられます。

アップストリーム パケット カウンタ

エラーを一覧するもう 1 つのコマンドは、show interface cable5/1/0 upstream コマンドです。FEC CW とは異なるパケットです。1 つのパケットが多数の 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)

用語の定義は次のとおりです。

- broadcasts：受信したブロードキャスト フレーム。

- multicasts：受信したマルチキャスト フレーム。

- unicasts：受信したユニキャスト フレーム。

- discards:MC5x20Sラインカードでのみ増分されます。フレームそのものではなく、カードに特有のさまざまなエラー条件によって廃棄されたパケットをリストします。

- errors：エラーの全体の合計。これらのうちの多くは重大なものではありません。この値にカウントされるエラーは、MC16C および MC28C などの BCM3210 ベースのカードに対するものです。

- プリアンブルやユニーク ワードが正しく受信されなかった、割り当てアップストリーム スロットの数。

- 受信した修正不可能なフレームの数。

- 帯域幅「要求」の際のコリジョン。

- 「要求/データ」スロットでのコリジョン（このタイプのスロットは Cisco CMTS にはありません）。

- 帯域幅「要求」の際に受信した破損フレーム。

- 「要求/データ」スロットの際に受信した破損フレーム。

- 受信した破損レンジ要求の数

MC5x20 および MC28U などの JIB ベースのラインカードの場合：

- 何らかの理由で、Header Check Sequence（HCS）または巡回冗長検査（CRC）によるエラーには分類されないアップストリーム側のエラーフレーム。

- HCS 問題が発生したアップストリーム フレーム。

- CRC エラーが発生したアップストリーム フレーム。

- 受信した修正不可能な CW。

- 帯域幅要求 IUC でのコリジョン。

- unknown protocol：受信されたフレームで、IP、Address Resolution Protocol（ARP）、Point to Point Protocol over Ethernet（PPPoE）のいずれでもないものの数。 このカウンタには、誤った形式の DOCSIS ヘッダーや、無効なヘッダー オプションを持つフレームも含まれています。

- packets input：broadcasts、multicasts、および unicasts の合計数。

- uncorrectable：修正不可能なFEC CWが1つ以上含まれるフレームの合計数。MC5x20 および 28U の場合は、このフィールドは N/A と表示されます。修正不可能なエラーに関する情報を得るには、この代わりに、show cable hop の出力の [Uncorr FEC Errors] カラムを使用します。

- noise:MC16CやMC28CなどのBCM3210ベースのカードでは、帯域幅「要求」または「レンジング」間隔で受信された破損フレームの数です。このため、この数値は errors の数値のサブセットになります。

- 帯域幅「要求」の際に受信した破損フレーム

- 「要求/データ」スロットの際に受信した破損フレーム。

- 受信した破損レンジ要求の数

MC5x20 などの JIB ベースのカードの場合、このカウンタの値はまったく増加しません。

- [microreflections]：マイクロリフレクションの数。必ず 0 に設定します。

errors カウンタと noise カウンタでは、破損フレームだけではなく、初期レンジング要求のコリジョンや帯域幅要求のコリジョンなどの事象もカウントされています。そのため、noise カウンタの増加は、必ずしも問題があることを意味しているわけではありません。単に、お客様の環境でオンラインになろうとしているモデムが多数あるか、より多くの伝送を行おうとしているモデムがある（上記のコリジョンがさらに発生する）ことを意味しているだけの可能性があります。 noise カウンタは実際には errors カウンタのサブセットになります。これは noise には errors カウンタの最新の 3 つのコンポーネントが含まれているためです。

結論

シスコの Advance Services および Rapid Response グループの経験とラボでのテストによると、これらは、FEC とアップストリーム パフォーマンスの低下に関する観察事例のいくつかです。

- 修正不可能な FEC エラーがあることは、ノイズが容認できないレベルに達した場合や、タイミングの問題やヘッドエンド スプリッタやコンバイナでの切り分けが不十分であることが原因でパケット同士のコリジョンが起きている場合の、よい指標となります。後者の場合、ある CMTS アップストリーム ポート宛てのパケットが、切り分けの不十分さによって、他のアップストリームへ「リーク」します。

- 修正不可能な FEC エラーが大きく増加すると、音声品質に問題が生じます。

- 修正可能な FEC エラーは、ノイズのレベルの増大となって現れます。修正可能な FEC エラーの場合は、修正不可能な FEC エラーが伴っていない限りは、パケットのドロップや音声品質の低下は生じません。

- US 変調プロファイルでの FEC T バイトを増やすと、ある程度までは有効ですが、これはノイズの発生源によって変わります。7 ～ 10 % の FEC カバレッジが最適と思われます。

以前の調査例からは、修正可能な FEC エラーでは CMTS をポーリングすることが有効です。Voice over IP（VoIP）over cable は、修正不可能な FEC エラーの影響を受けやすい特性があります。修正不可能な FEC エラーの比率がかなり高い場合、音声品質に関する問題が発生しますが、その一方、IP データは最小限の影響を受けるだけです。

結論として、ファスト トランジェント（高速過渡現象）RF 障害が発生（前述）し、修正不可能な FEC エラーが依然として発生している場合に、US チップの SNR 示数が誤解を生じやすいようなものであると、問題のトラブルシューティングはかなり複雑になることがあります。

図 3 では、SNR が低下し、同時に修正不可能な FEC エラーと修正可能な FEC エラーが発生している US の例が示されており、アップストリーム パフォーマンスを計測する際に、これら 2 個のパラメータの関係が密接であることを強調されています。

図 3：SNR と FEC エラーの時間経過

最初のグラフでは、修正不可能な FEC エラーと修正可能な FEC エラーの比率を表しています。また、下のグラフは同じ時間帯での SNR の示数の低下を示しています。スペクトル アナライザ（Agilent HP8591C など）でアップストリームのデジタル変調された搬送波をチェックしてみると、おそらくインチャネル ノイズが非常に高いレベルで表示されます。インパルシブな性質のアップストリームRFの問題は、アップストリームブロックのエラー率（BERに類似）を測定できるサードパーティのテスト機器(Hukk CM1000 - Sunrise Telecom Web Site - Acterna DSAMを参照)を)を使用して確認できます。 この装置を使用すると、US SNR の示数が良好に見える場合にも、RF 問題が存在していることが検証できます。

US SNR の示数が良好に見えても、そのまま RF に問題がないとは想定できないということが、重要な点です。RF ドメインで生じていることを確実に判断するには、適切なテスト機器を使用した簡単な調査が必要な場合があります。RF スペクトルは、初めに想定されたものほどクリーンではない可能性はかなりあります。

付録

このセクションでは、監視するアップストリーム パラメータについて詳しく説明します。

アップストリームが修正可能なFECパーセント

説明

このチャネルで受信された CW で修正不可能なエラーがあるものの割合です。これには、このデバイス宛てのフレームの一部である場合、ない場合にかかわらず、すべての CW が含まれます。

数式

%訂正可能= [(Ec1 - Ec0)/ [(Eu1 - Eu0) + (Ec1 - Ec0) + (C1 - C_0)]] * 100

- C = docsIfSigQUnerroreds

- Ec = docsIfSigQCorrecteds

- Eu = docsIfSigQUncorrectables

ネット ルール

受信されたパケットの >2.5 % の値は黄色で強調表示されます。

受信されたパケットの >=5 % の値は太字の赤色で表示されます。

ネット情報

そのインターフェイスで受信された CW の総数に対する、修正可能な FEC エラーのある入力 CW の比率です。この比率は入力 CW 全体の 5 % 未満であることが推奨されます。

詳しい情報

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.

アップストリームが修正不可能なFECパーセント

説明

このチャネルで受信された CW で修正不可能なエラーがあるものの割合です。これには、このデバイス宛てのフレームの一部である場合、ない場合にかかわらず、すべての CW が含まれます。

数式

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

- C = docsIfSigQUnerroreds

- Ec = docsIfSigQCorrecteds

- Eu = docsIfSigQUncorrectables

ネット ルール

受信された CW の >0.5 % の値は黄色で強調表示されます。

受信された CW の >=1 % の値は太字の赤色で表示されます。

ネット情報

入力 CW でのドロップの比率は、そのインターフェイスで受信された CW の総数に対する、入力時にドロップされた CW の比率を示しています。この比率は入力 CW 全体の 0.5 % 未満であることが推奨されます。

注：VoIPなどの特定の「リアルタイム」サービスでは、より厳しい監視が必要になる場合があります。修正不可能な FEC 値が 1 % でも、損失がバースト的かランダムかによっては、音声品質の問題が発生するのに十分なパケット損失である場合があります。

詳しい情報

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

説明

このチャネルで認識された SNR です。CMTS は、アップストリーム チャネルの平均的な信号対雑音を示します。

数式

SNR = docsIfSigQSignalNoise / 10

ネット ルール

<27 dB の値は黄色で強調表示されます。

<23 dB の値は太字の赤色で表示されます。

ネット情報

DOCSIS では、最低限の CNR（デジタルにおける SNR に相当）を 25 dB と指定しています。設定されているアップストリーム変調プロファイルによっては（QPSK または 16-QAM）、最低限の SNR の 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.

MC28U か5x20ラインカードで、モデム毎のFECカウンタのためのOIDを取り出す方法例

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

このモデムのコードワード カウンタを調べるには、まず次の 2 種類の情報を入手する必要があります。

- ケーブル 6/0 インターフェイスの SNMP インターフェイス インデックス。

- モデムの docsIfCmtsServiceNewCmStatusIndex。

次のコマンドを使用して、ケーブル 6/0 の ifIndex を調べます。

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

次のコマンドを使用して、ifIndex が 10（ケーブル 6/0）のインターフェイスで、SID 50 のモデムの docsIfCmtsServiceNewCmStatusIndex を調べます。

% snmpwalk -cpublic 172.18.73.167 docsIfCmtsServiceNewCmStatusIndex.10.50

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

モデム（983090）の docsIfCmtsServiceNewCmStatusIndex が得られたため、次の FEC カウンタを調べることができます。

- 受信した良好なコードワード（docsIfCmtsCmStatusUnerroreds）

% snmpget -cpublic 172.18.73.167 docsIfCmtsCmStatusUnerroreds.983090

DOCS-IF-MIB::docsIfCmtsCmStatusUnerroreds.983090 = Counter32: 8165

注：show interface cableコマンドを発行してから、Unerroredsカウンタが若干増加しています。

- 受信した修正済みコード ワード（docsIfCmtsCmStatusCorrecteds）

% snmpget -cpublic 172.18.73.167 docsIfCmtsCmStatusCorrecteds.983090

DOCS-IF-MIB::docsIfCmtsCmStatusCorrecteds.983090 = Counter32: 0

- 受信した修正されていないコードワード（docsIfCmtsCmStatusUncorrectables）

% snmpget -cpublic 172.18.73.167 docsIfCmtsCmStatusUncorrectables.983090

DOCS-IF-MIB::docsIfCmtsCmStatusUncorrectables.983090 = Counter32: 2

関連情報

- DOCSIS におけるデータのスループットについて

- ケーブルラインカードのためのアップストリーム変調プロファイル

- DOCSIS Radio Frequency Interface Specification

- ブロードバンド ケーブルに関するサポート ページ

- テクニカルサポート - Cisco Systems