CMTSの上り信号レベル設定

なんと、2年10ヶ月ぶりの更新です。
すみませんすみません。

さて、今回はCMTSの上りレベル設定の基本についてです。
伝送路というのはCATV局ごとにポリシーも運用ノウハウも異なりますので、一概にこの方法ですべてOKとはいかないのですが、もしCMTSの運用で上りレベル設定方法に迷った場合は、この基本に立ち返って考えると、シンプルに考えられるのではないでしょうか。


「はじめに」
よくある誤解なのですが、CMTSの上り受信レベルを変更しても、加入者モデムの上りSNRを良くすることはできません。
見かけ上、SNRが良くなるように見えますが、E/O・O/E(光送受信機)への入力値がその分上昇しますので、上り信号のサチュレーションが発生し、かえってパケットロスや通信品質が低下する恐れが出てきます。
本来は、伝送路〜光送受信機〜CMTSまでの、全体のRF配線の中で調整した結果としてCMTSの上りチャネルへ到達した信号レベルを、CMTSに設定するのが正しい姿です。
つまるところ、H/E内配線の結果としてCMTS側でのレベル設定があるものですので、そのためには以下の内容を順番に確認しなければなりません。
 
1. 確保したいSNR値をいくつにするかを決める。
 CATV局にて、モデムの上りSNR値をいくつで運用したいと考えているのかを、まずは決めていただかなければなりません。
 これは伝送路の状態や設備の経過年数によっても変わってきますが、HFC化が済んでいる伝送路では、一般的には27dB〜30dB以上を目安とされている例が多いようです。
 まずは、運用におけるSNR値はいくつであるべきなのかを確認するか、自分で決めましょう。
 
2. 光送受信器の設定レベルを確認する。
 次に、伝送路とH/E内との境界線上にあるE/O・O/Eレベル設定を確認します。
 一般的には50dB〜60dBmVとなっているようですが、メーカーによって差があるかと思いますので、仕様書や納入時の設定値を見て値確する必要があります。
 
3. 光送受信器からCMTSの上りコネクタまでの配線のレベル減衰量を確認する。
 次に、光送受信器からCMTSまでの配線図を確認します。
 この配線図には、途中に使われている分配器や分岐器の位置、及び同軸ケーブルの長さなどが記載されている必要がありますので、もしそう言った情報が記入されていない場合には、同軸ケーブルを順繰りに辿って、確認しなければなりません。
 それらの情報が揃ったら、机上で減衰量を割り出します。
 分配器や分岐器での減衰量はメーカーや使用する周波数によって若干異なりますが、大まかには以下の通りです。
 2分波器:-4dB
 4分配器:-8dB
 6分配器:-12dB
 8分配器:-13dB
 1分岐器:-2dB
 2分岐器:-3dB
 4分岐器:-5dB
 
4. Signal Generator(SG)を使って実際のレベルを確認する。
 上記の値はあくまでも机上の計算となりますので、きちんと図面通りに配線されているのかを確認するため、各ノードごとにSGを使って上り信号を立ててその信号がCMTSの上りコネクタ直前までで、実際にどれくらい信号が減衰しているのかを確認します。
 途中にテストポートがあれば、そこにスペクトラムアナライザを入れて、SGからの信号レベルを確認しますが、もしテストポートがなければ、いったん同軸ケーブルをCMTSの上りコネクタから抜いて確認しなければなりません。
 したがって、ノードの株分け時や新規ノード設置時の配線時にしっかり信号レベルを計測しておくことをお勧めします。
 
ここまでの作業で、CMTSの上りコネクタに到達する信号レベルが割り出されますので、その数値をCMTSに設定します。
 
5. モデムの上り出力レベルを確認する。
 上記までの作業が完了し、CMTSの上りレベルが設定された状態において、伝送路上のモデムの上り出力レベルとSNR値を確認します。この数値はCMTS上では確認できませんので、各モデムのWeb GUIMRTG等によるデータで確認する必要があります。
 なお、モデムが出力できるレベルは、上りの変調方式によって異なりますので、その範囲内に収まっており、かつ、SNR値が一番最初に決めた運用方針と同じぐらいか、それよりも良い状態になっていれば、CMTSの設定値が正しいこととなり、そのまま運用に入ります。
 各変調方式ごとの上り出力レベル範囲はこちら(http://d.hatena.ne.jp/akrsakai/20060809)。

DOCSIS3.1概要

さて、今年のSCTEで発表されたDOCSIS3.1規格について、あちこちで話題になりつつあるようですので、備忘録として概要を載せておきます。


DOCSIS3.1機能概要
2012年12月15日現在で、DOCSIS3.1としての規格化が提唱されている機能のうち、大きなものは以下の3つです。

1. OFDM/OFDMAと4096QAM
1波あたり12.5KHzの波を複数波立てて、上り下りの1波あたりの変調方式を最大4096QAM(12bits/Symbol)まで拡張しようというのが最大の特徴です。
6MHzあたり480のOFDM波ということなので、6MHz換算では約60Mbpsぐらいのスループットになる見込みです。
で、最終的には最大スループット約10Gbpsを目指すとのこと。
しかし、高い周波数帯では信号レベルが落ちてSNRを確保できなくなる可能性が高いので、低い周波数では高い変調方式を用い、周波数が高くなるに従って変調方式を落としていくという運用方法になるのではないでしょうか。
上りについても下りと同じ1波あたり12.5KHzの帯域幅で、最終的には2.5Gbpsまで可能にしたいとのことですが、使用する帯域が5〜400MHzとなっているので、かなり限られた使い方になるような気が・・・。
なお、5〜55で6チャネル分立てることができれば、250Mbpsの上りスループットになります。

2. DOCSIS3.0/2.0との下位互換性
発表された資料では、DOCSIS1.1/1.0については触れられていませんでしたが、DOCSIS3.0がBackward Compatibilityを持っており、DOCSIS3.1も同じ形式になる模様です。

3. 上り帯域の拡張
DOCSIS3.1では上りの使用帯域を5〜400MHzまで拡張するとのこと。
日本では実現可能性は低いのですが、棟内で完結した環境であれば、アリかも知れません。


スケジュール
現在のところ、まだ正式な規格化は終わっていないようで、各メーカーともDOCSIS3.1機能の実装は2014年〜2015年頃を見込んでいるようです。
いずれにせよOFDMをサポートしているチップがなければCMTSもCMも作れないので、チップベンダーの開発待ちというとことでしょうか。
北米MSOとしては、新しい通信方式を採用することでBroadcom/Intelで寡占状態となっている状態を打破したいという思いもあるようですが、はてさて。

スループットからCMTSの最適収容台数を算出するには

 1年毎に更新されることで有名になりつつあるこのBlogですが、みなさまいかがお過ごしでしょうか。
 さて、本日はCMTSへのモデムの収容台数は、どのように考えればいいのかという視点から考えてみました。
 
 収容台数は、大きく2つの視点で捉えることができます。

  1. CMTSの性能
  2. 実効スループット

 
 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×2+FEC K=18〜255Byteと、Codeword全体のサイズが決められているため、大きくした分、データのペイロードであるFEC Kのサイズを小さくしなければなりません。
 ホワイトノイズやインパルスノイズ、CWノイズへの耐性を高めるのに有効ですが、FEC T=0とすると、前方誤り訂正は行われません。

・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に搭載されている機能の一つで、上り信号に混入したノイズ成分に対して逆位相をかけ、ノイズを消去する機能です。
 ちょうど、ノイズキャンセリングヘッドホンで使われている仕組みと同じでチップの性能に依存しますが、100usec以上の長さのノイズが混入した場合に有効です。
 この機能を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に書かれていますので、ぜひご一読をおすすめします。