スループットからCMTSの最適収容台数を算出するには
1年毎に更新されることで有名になりつつあるこのBlogですが、みなさまいかがお過ごしでしょうか。
さて、本日はCMTSへのモデムの収容台数は、どのように考えればいいのかという視点から考えてみました。
収容台数は、大きく2つの視点で捉えることができます。
- CMTSの性能
- 実効スループット
CMTSに収容できる最大限の台数については、各メーカーから数値が公表されているのでみなさんご存知かと思いますが、実際にどれくらい収容できるのかについては、様々な議論が残るところです。
しかし、DOCSISのCMTSでは、モデムの収容台数が増えたとしてもCMTSの性能としては上り・下りのトラフィック性能は変わりません。
そこで、モデム単体に期待する実効スループットをどれくらいに設定するかを考えることで、運用上耐えうる収容台数というものを算出できるのではないか、と考えました。
考えられるパラメータは次の通り・・・
ということで、それぞれのパラメータを入れると自動的に推奨最大収容数を計算するエクセルシートを作ってみました。
https://dl.dropbox.com/u/17081453/DOCSIS2.0CMTS%E5%8F%8E%E5%AE%B9%E5%8F%B0%E6%95%B0%E8%A8%88%E7%AE%97_rev1.0.xls
要望がありましたらDOCSIS3.0版も作ってみますので、お気軽にお知らせ下さい。
下りのスループットとMax Traffic Burstの関係
上りのスループットと、Max Traffic Burst、Max Concatenated Burstとの関連性については、これまでのエントリーでも書いてきましたが、下りに関してはあまり詳しく書いたことがありませんでした。
そこで、今回は下りのスループットとMax Traffic Burstとの関連性について考えてみたいと思います。
Max Traffic Burstは、トラフィックを集中的に送信する際のバッファ量である
遅延が大きなネットワークにおいては、ある程度のバッファを設けることで、効率的に大量のトラフィックを送受信することができるようになります。
一般的には遅延が大きければ大きいほど、バッファのサイズも大きくすることで効率性が高くなりますが、逆に、バッファサイズを大きくし過ぎると、遅延が大きくなってスループットが思うように伸びません。
では、DOCSISの下り方向のネットワークでは、どれくらいのバッファサイズが最適なのでしょうか。
下りのQoS設定によって最適なMax Traffic Burst値は異なる
DOCSIS RFIでは、1522Bytes（Ethernetフレームに、22BytesのVLANヘッダを加えた数字）の倍に当たる3044Bytesが、Max Traffic Burstの最小設定値として規定されています。
この値では、どれくらいのスループットに対応できるか、単純に計算してみましょう。
下り通信で発生する遅延を考慮してみると・・・
- QAM変調による固定遅延：256QAMの場合、1.5msの遅延
- Interleaver設定による固定遅延：Tapを8とした場合、256QAMで4.1usecのガードタイムと、150usecの遅延
従って、下り方向の通信には、1回のBurst通信は最短で1154.1usec毎に行われることになります。
このことから、1秒間でのBurst通信回数は以下のようになります。
- 1sec = 1,000,000usec÷1154.1 ≒ 866回
Max Traffic Burst値を3044Byteとした場合、866 × 3044Byte = 2,636,104Bytes、つまり、約21Mbpsが上限値となります。
ということは、DOCSISのオーバーヘッドを考慮しても、下りのQoSが20Mbps以下の場合には、下りのMax Traffic Burst値は3044Byteで十分なわけです。
では、下りのQoSを40Mbpsとしている場合には、いくつにするのが最適なのでしょうか。
単純に計算すると・・・
- 40Mbps = 5,000,000Bytes/sec
- 5,000,000Bytes ÷ 866 ≒ 5773Byte
となり、理論上は5773Byteに設定すれば、CMTSからCMへの、下り方向のスループットに対しては40Mbpsの通信を担保できるようになります。
実際には、Ethernetフレームサイズの倍数で設定することが望ましいとされているので、1522Bytesの4倍である、6088Bytesに設定することで、下り40Mbpsのスループットに対応できることとなりますね。
DOCSIS3.0モデムの場合も、考え方は同じ
160Mbpsのサービス展開に使用されている、DOCSIS3.0モデムの場合にも、同じ計算で最適な数値を算出することが可能です。
試しに、計算してみましょう。
- 160Mbps = 20,000,000Bytes/sec
- 20,000,000Bytes ÷ 866 ≒ 23,095Bytes ≒ 24,352Bytes（Ethernetフレーム16個分）
ということで、下りの通信速度を160Mbpsに設定してサービスを展開する場合には、下りのMax Traffic Burst値を最低でも24,352Bytesに設定しておかなければならないことが分かります。
以上、参考になったでしょうか。
念のため付け加えておくと、各社のDOCSISモデムでは、内部のソフトウェア処理やハードウェア処理においてさらに遅延が加わる可能性がありますので、設定値については念のため各社にご確認いただくことをおすすめします。
ではでは！
FECの仕組みとノイズ耐性
なんと、一年ぶりの更新ですみません。
本日は、お客様から寄せられたご質問への回答についてみなさんにもご覧いただこうと思いました。
問：Modulation ProfileにあるFECの仕組みと、ノイズ耐性との関連は？
答：
FECのパラメータの決め方は、DOCSIS RFI 第六章 PHYSICAL MEDIA DEPENDENT SYBLAYER SPECIFICATION
URL：http://www.cablelabs.com/specifications/CM-SP-RFIv2.0-C02-090422.pdf
に従って求めることができます。
基本的には、以下2点との関連性から決定するすることになります。
1. 耐ノイズ性能
2. スループット
FECはヘッダーであるTとデータペイロード部のKから成り立っており、合わせてCodewordという単位で送出されます。
データペイロードであるFEC Kを小さくして、ヘッダーのFEC KおよびPreambleを長くすると耐ノイズ性能が上がりますが、CPEから送信されてくるEthernet Frameを小さくFragmentすることになるので、Fragment：De-fragmentによる遅延、さらには一度に送信できるトラフィック量が小さくなることによって、スループットも遅くなってしまいます。
逆に言えば、スループットをどれくらいにするのかによって耐SNR値が決まり、また、耐SNR値をどれくらいにするのかによってスループットが決まることとなります。
さて、FECのヘッダーである、FEC Tをどのサイズにするかによって誤り訂正の強さが決まり、どれくらいのエラーまで耐えられるかが決まりますが、なぜなのでしょうか。
実は、それぞれのヘッダーFEC Tには自分の前にあるCodewordのデータが記録されており、万が一自分自身がノイズで破損してしまっても、その前後のCodewordのFEC Tから冗長化されたデータを取り出し、復元させることが可能になっているのです。
この方法を、一般的は「前方誤り訂正＝Forward Error Correction＝FEC」
と呼んでおり、MPEGなどでも使われています。
次に、ノイズ耐性との関連性ですが、Modulation Profileのパラメータの中には、ノイズ耐性に関連するもがいくつもあります。
・FEC T（設定値：0〜16、ただし、実際のModulation Profileへの設定は、T×2になります）
前述の通り、値を大きくすればするほど耐ノイズ性能が高くなります。ただし、FEC T×２＋FEC K＝18〜255Byteと、Codeword全体のサイズが決められているため、大きくした分、データのペイロードであるFEC Kのサイズを小さくしなければなりません。
ホワイトノイズやインパルスノイズ、CWノイズへの耐性を高めるのに有効ですが、FEC T=０とすると、前方誤り訂正は行われません。
・FEC K（設定値：16〜253）
データペイロード部にあたるので、サイズを大きくするとスループットが高くなり、小さくするとスループットは低くなります。
しかし、小さくすることでインパルスノイズへの耐性を高めることができます。
・Preamble Length
各FECブロックの先頭に付けることで、FECのCodewordフレーム全体の前方誤り訂正を行うことができるようになります。
サイズを大きくすればするほど耐ノイズ性能が高まりますが、その分、Codewordの前につくヘッダーが大きくなり、スループットが低下します。
一般的には、この値を大きくするとインパルスノイズへの耐性が高まると言われていますが、わたしが試験した結果では、ホワイトノイズへの耐性も同じように高まることが確認
できました。
・Interleaving Depth
FEC Tには自分のシーケンス番号の前の番号のCodewordのデータが載りますが、連続したシーケンス番号のまま流れていると、ちょっと長めのインパルスノイズが混入して複数のCodewordが破損した場合、自分のデータが冗長されているCodewordも一緒に破損してしまい、お互いを復元することができなくなってしまいます。
このため通常は、シーケンス毎に番号を連続して並べるのではなく、ランダムに配置して連続するCodewordがいっぺんに壊れることが少なくなるようにする方法が取られており、この方法をInterleavingと呼んでいます。
Interleavingの並べ替えを複雑にすればするほどインパルスノイズへの耐性が高まりますが、ランダム化する際と、復号化する際の遅延がより大きくなるため、その分スループットが低くなります。
・Ingress Noise Cancellation
これは、Broadcom社のBCM3140に搭載されている機能の一つで、上り信号に混入したノイズ成分に対して逆位相をかけ、ノイズを消去する機能です。
ちょうど、ノイズキャンセリングヘッドホンで使われている仕組みと同じでチップの性能に依存しますが、１００usec以上の長さのノイズが混入した場合に有効です。
この機能をEnableにしてもDisableにしても、スループットへの影響はありませんが、チップ上でデジタルフィルターを生成するまでの間、パケットロスが発生する可能性があります。
以上、参考になれば幸いです。
なお、Modulation Profileの調整についてご質問などがあれば、ぜひご遠慮なくお知らせ下さい。
8 channel Bonding仕様
2010年1月15日に発行された、最新版のDOCSIS MULPI3.0 I12において、下り8ch Bonding用のStandard RCP-IDが追加されました。
これまで各社とも独自のRCP-IDや独自技術を使って8ch Bondingを行っていましたが、この新しい追加によってようやく共通のRCP-IDを持つことができるようになり、8ch Bondingでの互換性を持てるようになりました。
ではここで、あらためてそれぞれのRCP-IDのおさらいです。
Annex E "Standard Receive Channel Profile Encodings"より抜粋
DOCSIS（下り6MHz）
0x0010000002 : 2ch Bonding (108 - 870MHz)
0x0010000003 : 3ch Bonding (108 - 870MHz)
0x0010000004 : 4ch Bonding (108 - 870MHz)
0x0010000005 : 4ch Bonding (110 - 999MHz)
0x0010000008 : 8ch Bonding (108 - 1002MHz)
EuroDOCSIS（下り8MHz）
0x0010001002 : 2ch Bonding (108 - 862MHz)
0x0010001003 : 3ch Bonding (108 - 862MHz)
0x0010001004 : 4ch Bonding (108 - 862MHz)
0x0010001005 : 4ch Bonding (108 - 1002MHz)
0x0010001008 : 8ch Bonding (108 - 1002MHz)
上記の標準RCP-IDは、各社ともMULPI I12に準拠したファームウェアにて順次サポートされていく予定です。
ところで、前々回のエントリで、Motorola社DOCSIS3.0モデムが96MHzまで下り周波数幅をサポートしたという話をお伝えしましたが、独自RCP-IDは実装されたのでしょうか。。。
某社CMTSとの接続において、0x0010000005の標準RCP-IDをStatic RCP-IDとしてCMTS上に設定し、そこで80MHz幅の設定で動くようにしたという噂を耳にしましたが、標準のRCP-IDをいじって無理やり周波数幅を拡張させると、そのRCP-IDを使って96MHz幅をサポートしていないモデムが接続しようとした場合、いつまでたってもオンラインになれないという問題が生じる可能性があるので、個人的にはおすすめ出来ません。
MULPIでは上記RCP-IDを使った接続では60MHz幅までしか規定しておらず、96MHz幅のサポートは各社独自の実装となりますので、やはり、各社独自のRCP-IDを実装した方が混乱を避けることができるのではないでしょうか。
以上、次回はModulation-Profileのチューニング方法について、簡単にご説明します。
DOCSIS3.0におけるユーザートラフィックとコントロールトラフィック
DOCSISでは上りチャネルの情報を常に更新してケーブルモデムからの上り通信を開始するタイミングを決めるため、下り信号にMAPと呼ばれる制御信号を常に流すように規定されています。
また、DOCSIS3.0ではこのMAPの中に、従来からある上り中心周波数、上りChannel ID、Modulation-Profileパラメータに加え、チャネルボンディング関連情報のMDDを追加して送信しています。
下りのトラフィックに占めるMAPの割合はMAPサイズ値の設定によって異なります。
4 ticks毎の場合には約400Kbps（256QAMの場合だと約0.5%）ですが、MAPサイズが1 ticksずつ小さくなる毎に約200Kbpsづつ増えていき、最小値であるMAPサイズ1の場合では約2.0%、1Mbps弱のトラフィックを占有することとなります。
Best Effort型のSerivce Flowでは、ケーブルモデムが上りの通信を行う際、1回目のMAPを受け取った後にBandwidth Request、次の2回目のMAPを受け取ってからデータ通信を行います。
この結果、MAPサイズを大きくすればするほど上り通信にタイムラグが生じて個々のケーブルモデムのスループットは低下し、MAPサイズを小さくすれば上り通信のタイミングが早まるので、個々のケーブルモデムのスループットは向上する傾向にあります。
ところで、DOCSIS1.x/2.0であれば、下りは1チャネルだけなので1Mbps程度のオーバーヘッドは無視できる範囲で済むのですが、DOCSIS3.0では下りチャネルボンディングがあり、さらにMAC Domain Service Group（MDSG）という概念で、4チャネルの場合、3チャネルの場合など、複数のチャネルボンディングのセットをモデム毎に使い分けることができるようになったため、設定によってはMAPトラフィックが大幅に増え、下りトラフィック圧迫の要因につながることもあります。
例えば、4波ある下りチャネルのすべてがPrimary Channelだった場合、MAPサイズが1だとそれぞれの下りチャネルには1MbpsづつのMAPが流れるので、下りのボンディングチャネル全体で見た場合には4MbpsのトラフィックがMAPによって占められてしまう計算となります。
さらに、MDSGによって4波から1波まで4種類のチャネルボンディングセットを用意した場合だと、それぞれのMDSG用のMAPが重複して流れますので、4Mbps×4、合計で16Mbpsものオーバーヘッドが！
この結果、下り160Mbpsサービスを謳っていても、純粋にトラフィックとして使用できるのは論理的には約144Mbps、実際のEthernetや他のDOCSISヘッダーを考慮すると、約130Mbps程度しかスループットが出ないことになってしまいます。
つまり、個々のケーブルモデムのスループットを上げるためにMAPサイズを小さくすると下りのオーバーヘッドが増え、MAPサイズを大きくするとオーバーヘッドが減る代わりに個々のケーブルモデムのスループットは低下します。
通常、各メーカーのCMTSでは、MAPサイズ値のデフォルトは4になっています。
この値を使う場合には、下り4波・4種類のチャネルボンディングセットを設定してもトータルでは4Mbpsのオーバーヘッドで済むようになりますので、下りのトラフィックが気になる方は、お試しいただいてはいかがでしょうか。
なお、詳細はCable Labs発行のDOCSIS3.0 MULPIに書かれていますので、ぜひご一読をおすすめします。
RCP-IDと下りチャンネル設定幅の関係
DOCSIS MULPI3.0には、Receive Channel Profileについてこう書かれています。
A Receive Channel Profile is defined for operation with either 6 MHz or 8 MHz center frequency spacing. The CMTS advertises in its periodic MAC Domain Descriptor (MDD) messages a Receive Channel Profile Reporting Control TLV Section 6.4.28.1.4, that controls how the CM reports RCPs in its REG-REQ message. One subtype of this TLV is the RCP Center Frequency subtype that controls whether the CM should report RCPs based on 6 MHz or 8 MHz center frequency spacing. When the CM registers with the CMTS, it sends only the Receive Channel Profiles defined for the requested spacing. The CM MUST communicate to the CMTS all of the Standard Receive Channel Profiles (see Annex E) that are defined for the requested spacing and that are supported by the CM.
（要約）
使用する周波数幅が6MHzか8MHzかを規定するため、Receive Channel Profileが使われる。
CMTSからはMDD（下りに流れているMACドメイン情報）内にRCPを埋め込み、現在使用できるチャネル帯域幅をCMに通知することになる。
このとき、CMはStandard RCP-IDのすべてをサポートしていなければならない。（注：ただし、独自のUnique RCP-IDも使用できる）
（要約終わり）
ところで、DOCSIS MULPI3.0には、上記のStandard RCP-IDについては、10チャンネル分、つまり60MHzの周波数帯域幅までしか規定されていません。
しかしTI社のPUMA5チップでは96MHzまで使えるのです・・・。
ということで、ARRIS社のC4ではRCPの機能を利用して、周波数帯域のEnd to endを80MHzで使用することが可能です。
具体的には、Dynamic RCCとStatic RCCを組み合わせて、静的に指定したRCP-IDを解釈できるモデムは80MHz幅、そうでないモデムはStandard RCP-IDである60MHz幅しか運用できないようにするというものです。
実際にこの方法を使って、下りの周波数帯域幅を80MHzまで拡張してご利用いただいているお客様もいらっしゃるようです。
この手法はARRIS社のモデムだけでなく、Unique RCP-IDを使用できる他社モデムでも適用できるかもしれません。
Motorola社からも、ARRIS社と同じく下り周波数帯域幅を拡張したファームウェアがリリースされたとのことなので、いちど試してみたいですね。
仮定条件（平均512Byteというのは、ちょっとサイズが小さすぎるかも）
Data Packet ： 平均512Byte
Ack ： 64Byte
1AckあたりのData Packet数 ： 平均90Packet
1. 30Mbpsサービスの場合
512Byte × 8bit = 4096bit
30,000,000Bps ÷ 4096bit ≒ 7324PPS
7324Packet ÷ 90Packet ≒ 82Ack
82Ack × 64Byte = 5248 ≒ 6088Byte（4×1522Byte）
Traffic Burst値とConcatenated Burst値は等しい事が推奨されているので、この場合にはいずれの値も6088Byteが理論上の最適値ですね。
2. 8Mbpsサービスの場合
512Byte × 8bit = 4096bit
8,000,000Bps ÷ 4096bit ≒ 1954PPS
1954Packet ÷ 90Packet ≒ 82Ack
22Ack × 64Byte = 1408 ≒ 1522Byte（DOCSIS上、設定可能な最低値）
注意点としては、DOCSIS2.0のI08以降では、DefaultのBurst値が1522から3044に変更となっていること。
値を入れないか、ゼロを設定すると、自動的に3044Byteが適用されるようになります。
ただし、モデムがDOCSIS2.0 RFI I08以降のSpecに対応している事が前提なので、それ以前の、古いRFIをベースとしている場合には1522Byteになります。
