ブロードバンド ケーブル : 無線周波数(RF)光ファイバ / 同軸ハイブリッド(HFC)

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

2016 年 10 月 27 日 - 機械翻訳について
その他のバージョン: PDFpdf | ライター翻訳版 (2005 年 10 月 4 日) | 英語版 (2015 年 12 月 19 日) | フィードバック


目次


概要

Hybrid Fiber/Coaxial(HFC)ケーブル設備上で High Speed Data(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 データがリードソロモン エンコーダを通過するように指定されています。この場合、データ フレームに追加のパリティ バイトが付加されて、確実に「エラーから保護」され、障害が生じ難くなります。

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

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

DOCSIS 標準には、ダウンストリームとアップストリームの両方の CATV RF のパフォーマンスについての推奨パラメータが含まれています。 特に無線周波数干渉(RFI)仕様のセクション 2.3.2、「想定アップストリーム RF チャネル伝送特性」では、次のように述べています。

搬送波対干渉と入力(ノイズ、歪み、共通パス歪み、混変調の総和、および、ディスクリートおよびブロードバンド入力信号の総和、インパルス ノイズは除外)の比は、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 の推定値を取得する方法の例について説明します(「付録」も参照してください)。 すべての Command Line Interface (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

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

: show cable modem detail を実行すると、SNR がモデムごとに EC コードで一覧されます。

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:スペクトル アナライザでのゼロスパンの表示

http://www.cisco.com/c/dam/en/us/support/docs/broadband-cable/radio-frequency-rf-hybrid-fiber-coaxial-hfc/49780-return-path-monitor-1.jpg

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

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

return_path_monitor_2.gif

ゼロスパンは、タイミングが悪さや、ヘッドエンド スプリッタまたはコンバイナの切り分けが不十分であることが原因で、パケット同士のコリジョンが起きているかどうかを調べるためにも使用できます。 ある CMTS アップストリーム ポート宛てのパケットが、他のアップストリームに「リーク」しています。 この資料の「関連情報」セクションにリストされている白書および文書を参照して下さい。 ゼロスパン測定の説明については、『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

  • 時間 X の Eux = docsIfSigQUncorrectables

修正可能な% = [(Ec1 – Ec0)/ [(Eu1 – Eu0) + (Ec1 – Ec0) + (C1 – C0)]] * 100

修正不可能 な% = [(Eu1 – Eu0)/ [(Eu1 – Eu0) + (Ec1 – Ec0) + (C1 – C0)]] * 100

修正不可能、非エラー、修正済の合計は、この US で受信されたコードワード(CW、FEC データ ブロックとも呼ばれる) の合計に等しくなります。コードワードの合計には、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 イーサネット ヘッダー} + (ガード バンド)

{および}の間のすべては変調 プロファイルに CWs に、切り取り基づいていました集計されます、そして 2?T は各 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 エラーの時間経過

http://www.cisco.com/c/dam/en/us/support/docs/broadband-cable/radio-frequency-rf-hybrid-fiber-coaxial-hfc/49780-return-path-monitor-3.gif

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

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

付録

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

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

説明

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

数式

%Correctable = [(Ec1 – Ec0)/ [(Eu1 – Eu0) + (Ec1 – Ec0) + (C1 – C0)]] * 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 – C0)]] * 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
    

関連情報


Document ID: 49780