OPEN STM Tips
DOCSIS 3.0 環境における、SNMP を利用した CMTS/CM の監視方法

1. 背景・目的
DOCSIS 3.0 で新たに導入されたチャンネルボンディングでは、上下両方向の伝送が複数チャンネルにより行われるため、送受信レベル・SNR・エラー率などの監視指標も、伝送方向単位ではなく、チャンネル数分必要となる。この構造を合理的に表現するた
めに、OSSI 3.0 でデータモデルの抜本的な見直し、IfIndex 構造の拡張・階層化、既存MIB テーブルの分割・正規化・項目追加が行われた結果、DOCSIS 3.0 以前との間で、一部の MIB が非互換となった。更に、DOCSIS 3.0 以後で新たに定義された M-CMTSにより、MIB や Interface 構造の非互換が拡大した。
本 Tips では、OPEN STM シリーズによる DOCSIS 3.0 対応上の観点から、MIB 構造上の留意事項、CM 動作モード混在時の判定方法と動作、CMTS/CM 上り状態情報の取得方法および、M-CMTS への対応方法について説明する。

2. 対象読者
OPEN STM シリーズのサーバー系プログラム開発者

3. 参考文献・関連文書
DOCSIS 3.0 OSSI CM-SP-OSSIv3.0-I06-080215 (以降、「OSSI3.0」)
OPEN ADMIN TIMS Net エンジニアリングガイド
OPEN STM AE エンジニアリングガイド

4. その他
本 Tips 中の図表番号につき、OSSI 3.0 からの抜粋には原文の番号をそのまま流用し、独自に作成した図表には”Tips-*”の形式で番号を付与した。
実機による検証環境の整備に際し、（株）大垣ケーブルテレビ 技術部技術課 豊田 正男氏より、多大なるご協力を頂いた。

5. 最終更新日
2010 年 8 月 9 日

文書番号: OSSBN-TIPS-10-07-002/05
All Rights Reserved, Copyright © OSS BroadNet 2010
1 / 12

OPEN STM Tips
DOCSIS 3.0 環境における、SNMP を利用した CMTS/CM の監視方法

6. 詳細
6.1 DOCSIS 3.0 の MIB 構造(1) DOCSIS 3.0 MIB オブジェクトの相関関係

CM 検知と動作モードの判定
MAC アドレス
IP アドレス
CM 状態(Value)
MdIfIndex
RccStatusId
RcsId/TcsId

各上りチャンネルの状態把握
RxPower
SignalNoise
Microreflections
Unerroreds
Correcteds
Uncorrectables
Timing offset

Figure N-2 は、CMTS における CM の上りチャンネル状態情報のデータ構造である。
説明の簡便の為に、DOCSIS 3.0 以前の状態情報が省略されているので注意されたい。
DOCS-IF3-MIB の CmtsCmRegStatus テーブルは、DOCSIS 2.0 以前における DOCS-IF-MIBの CmtsCmStatus テーブルに相当する。1 レコードが 1 台の CM を表現し、Value による CMの on/off 検知と、CM のアドレス＆構成情報の取得に使用できる。主キーの Id は、
CmtsCmStatus.CmtsCmStatusIndex と同じく、CMTS シャーシ内で一意となる。
CmtsCmUsStatus テーブルは、1 台の CM に紐付く複数の上りチャンネルの状態情報を格納する MIB テーブルである。1 レコードが CM の各上りチャンネルを表す。第一主キーの Id
により、CM 本体を表す CmtsCmRegStatus テーブルと関連付けられ、第二主キーの ChIfIndex
により、対象 CM を格納する CMTS の上り ChIfIndex と関連付けられる。格納内容は上図の通り、上り受信レベル、SNR、エラー率などの状態情報である。
文書番号: OSSBN-TIPS-10-07-002/05
All Rights Reserved, Copyright © OSS BroadNet 2010
2 / 12

OPEN STM Tips
DOCSIS 3.0 環境における、SNMP を利用した CMTS/CM の監視方法
TIMS と AE の CMTS 状態問合せ機能を DOCSIS 3.0 向けに拡張するには、CmtsCmRegStatus
テーブルと CmtsCmUsStatus テーブルの全レコードを定期的にポーリングすれば良い。
しかしながら CmtsCmUsStatus テーブルは、レコード数基準で CmtsCmRegStatus テーブルの数倍規模と巨大なため、定期的なポーリングは、CMTS の負荷増大と収集時間の間延びを生じる。このため、AE の CMTS ポーリングに等価な CM 上り状態情報の取得処理の実装には、CmtsCmRegStatus テーブルと周辺テーブルで対象 CM を収容する CMTS の上り
ChIfIndex を一旦特定後、第一・第二主キーすなわち、対象 CM の Id と CMTS の収容上り
ChIfIndex 指定により、レコード単位で CmtsCmUsStatus テーブルから情報を取り出す方式の方が合理的である。
Figure N-2 は、CMTS における Index 周辺情報のデータ構造である。
説明の簡便の為に、DOCSIS 3.0 以前の状態情報が省略されているので注意されたい。
上記の目的に必要なテーブルは、Figure O-3 の MdChCfg テーブル、UsChSet テーブルの２つである。これらのテーブルを使用した具体的な第二キーの抽出方法については、6.3 で述べる。

文書番号: OSSBN-TIPS-10-07-002/05
All Rights Reserved, Copyright © OSS BroadNet 2010
3 / 12

OPEN STM Tips
DOCSIS 3.0 環境における、SNMP を利用した CMTS/CM の監視方法
Figure N-1 は、CM における CM の上り/下りチャンネル状態情報のデータ構造である。
説明の簡便の為に、DOCSIS 3.0 以前の状態情報が省略されているので注意されたい。

NMS による状態監視では、CMTS と CM の双方から収集した上りチャンネル状態情報の対応付けが必要となる。対応付けの具体的な方法については、6.3 で述べる。

文書番号: OSSBN-TIPS-10-07-002/05
All Rights Reserved, Copyright © OSS BroadNet 2010
4 / 12

OPEN STM Tips
DOCSIS 3.0 環境における、SNMP を利用した CMTS/CM の監視方法(2) DOCSIS3.0以前・以後のMIBオブジェクト対比
TIMS, AE の定常ポーリング対象となる MIB オブジェクトにつき、DOCSIS バージョンを基準とした対比表を Tips-001 に示す。

Process

DOCSIS 1.0/1.1/2.0
MIB Object
StatusIndex
StatusMacAddress
Value
docsIfIpAddress
CmtsCmInetAddress
StatusInetAddressType
DownChannelIfIndex
UpChannelIfIndex
Table

Poseidon(CMTS)

AE(CMTS)AE(CM)

docsIfCmtsCmStatusIndex
RxPower
SignalNoise
Unerroreds
Correcteds
Uncorrectables
MicroreflectionsIfIndex
docsIf
UpChannel Frequency
TxTimingOffset
IfIndex
TxPowerdocsIf
T3Timeouts
CmStatus
T4Timeouts
RangingAborteds
IfIndex
Value
docsIfCodeCmStatus
ResetsLostSyncs
docsIfIfIndex
DownChanne FrequencylPower
IfIndex
Unerroreds
docsIfCorrecteds
SignalUncorrectables
Quality
SignalNoise
Microreflections

DOCSIS 3.0
MIB Object
Id
MacAddrValue
IPv4Addr
docsIf3 IPv6Addr
CmtsCm RccStatusId
RegStatus MdIfIndex
RcsId
TcsId
MdCmSgId
LastRegTime
IfIndexdocsIf3
Id
UsChSetChList
IfIndexdocsIf3
Id
DsChSet
ChList
MdIfIndex
docsIf3
ChId
MdChCfg IsPrimaryCapableDs
ChIfIndex
ChIfIndex
RxPowerdocsIf3
SignalNoise
CmtsCm Unerroreds
UsStatus Correcteds
Uncorrectables
Microreflections
docsIfIfIndex
UpChannel Frequency
IfIndexdocsIfFrequency
UpChannel
TxTimingOffset
IfIndex
TxPowerdocsIf3
T3Timeouts
CmStatusUs
T4Timeouts
RangingAborteds
IfIndex
Value
docsIfCode
CmStatus
ResetsLostSyncs
docsIfIfIndex
DownChann Frequency
elPower
IfIndex
UnerroredsdocsIfCorrecteds
SignalUncorrectables
Quality
SignalNoise
Microreflections
Table

Tips-001 DOCSIS 3.0 以前・以後の MIB オブジェクト対比

文書番号: OSSBN-TIPS-10-07-002/05
All Rights Reserved, Copyright © OSS BroadNet 2010
5 / 12

OPEN STM Tips
DOCSIS 3.0 環境における、SNMP を利用した CMTS/CM の監視方法(3) OPEN STMの動作仕様
CMTS が DOCSIS 3.0 Silver 以降で動作中の場合、TIMS 中の Poseidon プロセス（以降、「 Poseidon 」） は Tips-001 の MIB テ ー ブ ル (docsIf3CmtsCmRegStatusTable 、
docsIf3DsChSetTable、docsIf3UsChSetTable、docsIf3MdChCfgTable)を定期的にポーリングし、取得値をキャッシュする。この時、MIB テーブル(docsIf3CmtsCmRegStatusTable)の Valueが operational の CM すなわち online CM のみを有効レコードとし、それ以外のレコードを無視する。Online 以外の状態にある CM の構成・設定情報が必要な場合、Poseidon や AEは、TIMS 内のデータベースキャッシュに基づき処理を実行する。
ターゲットCMTSがDOCSIS 3.0 Bronze以前で動作中の場合、PoseidonはTips-001のMIBテーブル(docsIfCmtsCmStatusTable)を定期的にポーリングし、取得値をキャッシュする。
以降の処理は、DOCSIS 3.0 Silverと同様である。

CMTSのDOCSISバージョンは、CMTSの属性として予め設定された情報に基づき、Poseidonが判断する。

文書番号: OSSBN-TIPS-10-07-002/05
All Rights Reserved, Copyright © OSS BroadNet 2010
6 / 12

OPEN STM Tips
DOCSIS 3.0 環境における、SNMP を利用した CMTS/CM の監視方法

6.2 CM動作モードの判定方法(1) CMのON/OFF検知
CmtsCmRegSatus.Valueは、CmtsCmStatus.Valueと等価である。
従って、CmtsCmStatus.ValueのregistrationCompleteやoperationalに等価な値に注目し、それ以外の状態についてはTIMSデータベース内のキャッシュ情報(CMIPMAC_TRANSACTION)と照合すれば、現行のTIMSと同様のCM状態検知機能を実現できる。

(2) CMのDOCSISモード
RccStatusId (Receive Channel Configuration Status Id)は、CMが登録シーケンス時にCMTSに自己申告するRcpId (Receive Channel Profile Id)に基づき、CMTSが対象CMに割り付ける実際の下りチャンネル構成を表す。RccStatusIdに基づき、CMのDOCSISモードの判断が可能である。すなわち、
RccStatusId=0の場合、対象CMはDOCSIS 2.0以前のモードで動作中である。
RccStatusId>0の場合、対象CMはDOCSIS 3.0以後のモードで動作中である。

(3) CMの上り/下りチャンネル構成
Channel Setは複数チャンネルの集合概念であり、値が1～255の場合、単一チャンネルのChIdを表し、MACドメイン内で一意となる。値が256以上の場合、２つ以上のチャンネルのChIdの集合を表し、CMTSシャーシ内で一意となる。
番号の付与ルールは、CMTSメーカーの実装依存であり、DOCSISによる規定は特にない。
TcsId (Transmit Channel Set Id)は、CMが使用中の上りChannel Setを表すIdであり、CMTSシャーシ内で一意となる。RcsId (Receive Channel Set Id)は、下りのTcsId相当の概念である。
TcsId / RcsIdにより、対象CMの上り/下りチャンネル構成を判断できる。
TcsId / RcsId に基づく CM 上り/下りチャンネル構成の判定方法を Tips-002 に示す。
TcsId
1~255
1~255256~

RcsId
1~255
256~
256~

チャンネル構成
下り×１、上り×１
下り×２以上、上り×１
下り×２以上、上り×２以上

Tips-002 CM上り/下りチャンネル構成の判定(4) CM動作モードの判定
AE は、Poseidon が収集し、TIMS 内のデータベースにキャッシュした、CMTS 内の各 CMのアドレス・構成情報に基づき、CM 単位にポーリングを実行する。
この時、同一 CMTS チャンネルに収容された各 CM の DOCSIS 動作モードに注意が必要である。DOCSIS3.0 では、3.0 以後の CM と 2.0 以前の動作モードの CM が、同一シャーシ・カード・MAC・上り/下りチャンネル内に共存できる。
文書番号: OSSBN-TIPS-10-07-002/05
All Rights Reserved, Copyright © OSS BroadNet 2010
7 / 12

OPEN STM Tips
DOCSIS 3.0 環境における、SNMP を利用した CMTS/CM の監視方法
一方で、対象 CM の Chipset や Firmware version によっては、OSSI3.0 への対応が不完全な場合もある。特に、DOCSIS3.0 の標準化に先立ち市場に出荷された各社の Pre-3.0 仕様 CMには注意が必要である。というのは、存在を仮定して問い合わせた MIB オブジェクトにつき、エージェント内にインスタンスが存在せず、ポーリングエラーとなるケースがあり得る。このようなエラーを未然に防止するには、全 CM への SNMP ポーリングに先立ち、最初に DOCSIS version を問い合わせ、応答結果で通信シーケンスを切り替える方式が考えられる。しかしながら、処理時間への要求が厳しい CM へのポーリングで、負担の大きい前処理を組み込む方式は、通信シーケンスが複雑化し、余計なトラフィックも増える。
Poseidon が収集済みの情報で対象 CM の DOCSIS バージョンを特定後、AE が自動的に CMへの通信シーケンスを切り替える方式が、効率的かつ合理的である。
DOCSIS 3.0 Silver で動作中の CMTS 環境で、現実的に考えられる CM 構成や動作モードの分類と、Poseidon が収集済みの情報のみに基づく判定方法を Tips-003 に示す。
なお RccStatusId、TcsId 共、(1)に示す CM 状態が OFF だと、正しい値が返らない場合があるので注意されたい。
MIB 実装(Firm 依存)
IFIF3(DS) IF3(US)
○××
●
○×
●
○○

DS
Ch
1
11

USCh
1
11

判定方法
DOCSIS モード
Ch 構成
RccStatusId =0
RcsId=<255
TcsId=<255
RccStatusId >1

A
B
C

CM 構成
(Chip 依存)1.0/1.1/2.0
3.0B
3.0S

D

3.0B

●

○×n1

E

3.0S

●

○

○nm

分類

○: 実装

255<Rcsid
TcsId=<255
255<RcsId
255<TcsId●: 非推奨×: 非実装

Tips-003 CM 動作モードの判定方法(5) AE の動作
AE は、Tips-003 の各分類に従い、ポーリング対象とする MIB テーブルを切り替える。CMTSが DOCSIS 3.0 で動作時、AE の各ポーリングが対象とすべき MIB テーブルを Tips-004 に示す。
分類
A,B,C
D
E

CMTS ポーリング
DocsIfCmtsCmStatus
docsIfUpChannel
同上docsIf3CmtsCmUsStatus
docsIfUpChannel

CM ポーリングdocsIfCmStatus,
docsIfUpChannel,
docsIfDownChannel, docsIfSignalQuaity
同上(下りのみ複数チャンネル)docsIfCmStatus,
docsIfUpChannel,
docsIf3UpChannel, docsIfDownChannel,
docsIfSignalQuaity(下り/上り共に複数チャンネル)Tips-004 AE ポーリングの対象 MIB テーブル

文書番号: OSSBN-TIPS-10-07-002/05
All Rights Reserved, Copyright © OSS BroadNet 2010
8 / 12

OPEN STM Tips
DOCSIS 3.0 環境における、SNMP を利用した CMTS/CM の監視方法

6.3 CMTS/CM上り状態情報の取得方法
上り方向の状態監視には、CMTS、CM双方へのポーリングが必要だが、両者のIfIndex概念が異なる為、収集した状態値を紐付ける操作が必要になる。この操作の具体的な手順を(1)～(5)に示す。

(1) UsChSetテーブルによるChListの抽出
CmtsCmRegStatus.TcsIdが255より大きい場合、docsIf3UsChSetテーブルを参照し、CmtsCmRegStatus.MdIfIndexをIfIndexに、CmtsCmRegStatus.TcsIdをIdに照合すれば、対象CMのChListを抽出できる。

ChListは8ビット値の配列なので、16進数表現で返るSNMPの問合せ結果を２桁ずつに区切り、それぞれ16進→10進変換すれば、ChIdの配列が得られる。

(2) MdChCfgテーブルによるChIfIndex配列への変換と上り状態情報の取得
次に、MdChCfgテーブルを参照し、CmtsCmRegStatus.MdIfIndexをIfIndexに、(1)で得られた各ChIdをChIdに照合し、各ChIdのChIfIndexを抽出すれば､ChIdをChIfIndexに変換できる。

ChIfIndexは、6.1(1)におけるCmtsCmUsStatusテーブル参照の第二キーとなるので、第一キーであるCmtsCmRegStatus.Idと組み合わせ、CmtsCmUsStatusテーブルを参照すれば、対象CMの各上りチャンネルの状態情報が得られる。
TcsIdが255以下の場合、(1)の操作を省略し、TcsId=ChIdとして同様の操作を行えば、TcsIdが255より大きい場合と同様の結果を得られる。

(3) CM上りチャンネルの中心周波数の特定
ChIfIndexはCMTSシャーシ内で一意となるため、DOCS-IF-MIB(RFC4546)のdocsIfUpstreamChannelテーブルを参照し、対象CMを収容するCMTSの上りChIfIndex配列をIfIndexに照合し､docsIfUpChannelFrequencyを抽出すれば、CMの各上りチャンネルの中心周
文書番号: OSSBN-TIPS-10-07-002/05
All Rights Reserved, Copyright © OSS BroadNet 2010
9 / 12

OPEN STM Tips
DOCSIS 3.0 環境における、SNMP を利用した CMTS/CM の監視方法
波数を特定できる。
この操作により、CmtsCmUsStatusテーブルから取得した対象CMの各上りチャンネルの状態情報に、中心周波数を付与できる。
TcsIdが255以下の場合、(1)の操作を省略し、TcsId=ChIdとして同様の操作を行えば、TcsIdが255より大きい場合と同様の結果を得られる。

(4) CMのIfIndex構造
CMへのポーリングでも、各上りチャンネルの状態情報に加え、中心周波数を合わせて取得するが、この具体的な方法について説明する。
まず、(1)でTable O-11から抽出したChList内のChId要素数から、対象CMが使用する上りチャンネル数を特定する。
次に、このチャンネル数をDOCSISのCMインタフェース採番規約に照合し、CM上りチャンネルのIfIndexを、上りチャンネルの数だけ抽出する。
DOCSISによるCM IfIndexの採番規約を下表に示す。

上の表に従い、例えば上り１チャンネル構成時には[4]、2チャンネル構成時には[4, 80]、3チャンネル構成時には[4, 80, 81]のように、上記の採番規約に従う事で、対象CMのChIfIndex配列を作成できる。このChIfIndex配列をIfIndexに照合し､DOCS-IF-MIB(RFC4546)のdocsIfUpstreamChannel.docsIfUpChannelFrequencyを取り出せば、CMの各上りチャンネルの中心周波数を特定できる。

(5) CMTSとCMから取得した各上り状態情報の対応付け
CMTSからの取得情報とCMからの取得情報を、(3)(4)で得られた中心周波数で紐付ければ、両者の情報を一意に対応付ける事ができる。

文書番号: OSSBN-TIPS-10-07-002/05
All Rights Reserved, Copyright © OSS BroadNet 2010
10 / 12OPEN STM Tips
DOCSIS 3.0 環境における、SNMP を利用した CMTS/CM の監視方法

6.4 M-CMTS への対応
(1) M-CMTSとI-CMTSの構造差
下り系の MIB オブジェクトにつき、M-CMTS と I-CMTS の違いに注意する必要がある。
Figure 1-3 に、DOCSIS 3.0 のリファレンス構造を示す。

M-CMTS では、上りの構成は I-CMTS と同じだが、下りの構成が I-CMTS と異なり、チャンネル変調を行う EQAM と M-CMTS コアが、DEPI を介して構成される。
NMS などの SNMP マネージャから見た場合、下り伝送チャンネルの各論理インタフェースが、DEPI により M-CMTS コアから切り離される。
このため、NMS から M-CMTS コアの SNMP エージェントに対し、下り伝送チャンネルの各インタフェース情報（IfIndex 構成など）や、これに紐付く属性・状態情報（チャンネル構成、周波数など）を問い合わせても、正しい情報を得られない場合がある。

(2) CMポーリングにおける問題点
複数チャンネル構成 CM への SNMP Get Request で、上り/下りの使用チャンネル数を予めCMTS から取得し、6.3(4)の手法で IfIndex を特定すれば、CM ポーリングの SNMP Get のMultiVarBinds 数を極小化できるため、PDU サイズが小さくなり、通信効率が向上する。
上りについては I-CMTS・M-CMTS 共、6.3(1)の操作で使用チャンネル数を取得すれば、IfIndex を特定できる。
下りについても I-CMTS であれば、6.2(3)の CmtsCmRegStatus.RcsId に基づき、6.3(1)のdocsIf3UsChSet テーブルを docsIf3DsChSet テーブルに置換する事で、使用チャンネル数を取得できる。しかしながら M-CMTS の場合、docsIf3DsChSet テーブルが正しい情報を返さないため、使用チャンネル数を取得できず、この結果、IfIndex を特定できない。
文書番号: OSSBN-TIPS-10-07-002/05
All Rights Reserved, Copyright © OSS BroadNet 201011 / 12OPEN STM Tips
DOCSIS 3.0 環境における、SNMP を利用した CMTS/CM の監視方法(3) CMポーリングの処理フロー
OPEN STM では M-CMTS 配下 CM へのポーリング時、下り使用チャンネル数によるMultiVarBinds 数の最適化を行わず、CMTS の属性情報として予めデータベースに設定された最大下りチャンネル数により、MultiVarBinds を静的に生成する判断を実装する。
本方式では M-CMTS 時、下り MultiVarBinds 数の最適化が行われないため、SNMP の通信効率は若干低下するが、(2)の問題を回避でき、かつ I-CMTS と M-CMTS の混在構成でも動作する。
本方式の処理フローを Tips-005 に示す。
Start
CMTS から CM 上り
チャンネル情報を取得

No

I-CMTS?
Yes
CMTS から CM 下り
チャンネル情報を取得

データベースから最大下りチャンネル数を取得

Get Request PDU のMultiVarBinds 生成
CM への SNMP Get
Request 実行End
Tips-005 CM ポーリングの処理フロー
以上

文書番号: OSSBN-TIPS-10-07-002/05
All Rights Reserved, Copyright © OSS BroadNet 201012 / 12