データ品質とスループットを保証する手段としてのアップストリーム FEC エラーと SNR

ダウンロードオプション

PDF (441.5 KB)
Adobe Reader を使ってさまざまなデバイスで表示
ePub (189.1 KB)
iPhone、iPad、Android、ソニーの Reader、または Windows Phone 上で、さまざまなアプリを使って表示
Mobi (Kindle) (237.4 KB)
Kindle デバイスで、または Kindle アプリを使って複数のデバイスで表示

Updated: 2005 年 10 月 4 日

Document ID:49780

偏向のない言語

この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。

翻訳について

シスコは世界中のユーザにそれぞれの言語でサポートコンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版（リンクからアクセス可能）もあわせて参照することを推奨します。

内容

概要

信号対雑音比（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 データブロックの総数に基づいたもの）、比率を計算することにより、実際のアップストリームスループットをより適切に把握できます。次の式を使用します。

C_{x =} x の時点の docsIfSigQUnerroreds
E_{cx =} x の時点の docsIfSigQCorrecteds
E_{ux =} x の時点の docsIfSigQUncorrectables

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

% Uncorrectable = [(Eu1 - Eu0)/ [(Eu1 - Eu0) + (Ec1 - Ec0) + (C1 - C₀)]]] * 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₀)]] * 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パーセント

説明

数式

%Uncorrectable = [(Eu1 - Eu0)/ [(Eu1 - Eu0) + (Ec1 - Ec0) + (C1 - C₀)]]] * 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.

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

データ品質とスループットを保証する手段としてのアップストリーム FEC エラーと SNR

ダウンロードオプション

偏向のない言語

翻訳について

内容

概要

信号対雑音比（SNR）

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

ノイズフロアの表示方法

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

前方誤り訂正

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

モデムごとの FEC カウンタ

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

結論

付録

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

説明

数式

ネットルール

ネット情報

詳しい情報

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

説明

数式

ネットルール

ネット情報

詳しい情報

アップストリーム SNR

説明

数式

ネットルール

ネット情報

詳しい情報

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

関連情報

このドキュメントは役に立ちましたか?

シスコに問い合わせ

データ品質とスループットを保証する手段としてのアップストリーム FEC エラーと SNR

ダウンロード オプション

偏向のない言語

翻訳について

内容

このドキュメントは役に立ちましたか?

シスコに問い合わせ

ダウンロードオプション