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になります。

基本となる考え方

上りTraffic BurstならびにConcatenated Burst値は運用されているModulationとTime Ticksによって最大値が決定されます。


例えば、16QAM 3.2MHz 4ticksの場合ですと、
1ticks = 8Byte
4ticks = 32Byte
32Byte × 255 Slots = 8160Bps


となり、実際に使用できる値は8160Byteが上限となります。
QPSK 3.2MHz、4ticksの場合には1ticks当りのデータサイズが半分の4Byteになるので、上限値は半分の4080Byte。


次に、この考え方をベースにして下りQoS値を規定しようとすると、CPEへのRTTとRWIN値、許容できるPPSにもよるけれど、理論上、最適なTraffic/Concatenated Burst値が得られます。

DOCSIS3.0認定状況

久しぶりの更新です。すっかりサボり癖がついてしまいました・・・。
さて、U.S.のニューオーリンズで5月18日から20日までNCTAが開催されたのを皮切りに、あちこちでケーブルショーが開催される予定です。
そこで今回は、DOCSIS3.0の状況についてまとめてみました。
Cable Labs Cert/Qual Product List

DOCSIS3.0 Qualified CMTS
ARRIS

C4 CMTS （ブロンズ認定）

CASA Systems

C2200 CMTS （フル認定）
C2300 CMTS （フル認定）

Cisco Systems

uBR10012 （ブロンズ認定）

Motorola

BSR64000（ブロンズ認定）

DOCSIS3.0 Certified Modem
ARRIS

TM702G

Scientific Atlanta

1500
DPC3000

Motorola

SB6120
SBV6220


DOCSIS3.0の認定は、ブロンズ、シルバー、フル認定の３種類があり、ブロンズ認定は今回で最後となりました。次回CW59以降では、シルバーかフル認定のどちらかしか受け付けられません。
昨年末のCW56では少し出遅れていた感のあるMotorolaですが、今回のCW58でぎりぎりブロンズ認定を受けることができました。NCTAで展示機器の説明をしていたエンジニアの方いわく、一時期は撤退も考えていたということですが、何とか望みが繋がったというところなのでしょうか。


CASA Systemsはいきなりフル認定を取得してきました。
2001年にMotorolaに買収されたRiver Delta Networksという会社のCMTS開発チームが、Motorolaからスピンアウトして設立した新興ベンダーで、ヨーロッパの一部CATVオペレータでDOCSIS2.0 CMTSとして何台か採用されているようです。
6月19日から東京ビッグサイトで開催されるケーブルテレビショー2008では、どこかのベンダーが展示するとかしないとか。

DOCSIS3.0認定CMTS発表！

ようやくCable Labsから、DOCSIS3.0認定CMTSの発表がありました。
Cable Labs


これによると、
ARRIS ： Bronze（下りBondingおよびIPv6）
Cisco Systems ： Bronze（下りBondingおよびIPv6）
Casa Systems：Sliver（下りBonding、上りBonding、IPv6、AES暗号化）
という感じで、Submitしたベンダは一応すべて通った事になります。


DOCSIS3.0認定モデムの発表は来週あたりに予定されているようです。

モデムがなかなかオンラインにならないときには？

まったく別件なのですが、リブートしたケーブルモデムがオンラインになるまでに時間がかかる、という問い合わせに関連して調べものをしたので、以下、備忘録およびTipsとして。

モデムがRangingをする際に関連するCMTS側のパラメータ

Ranging Backoff

モデムがRangigパケットの送出を待つ回数。ある幅で設定した値に従って送出する。2の指数で表されており、2-7だと、2の2乗（4）から2の7乗（128）までの間という意味。

Insertion Interval

Ranging Backofの間隔。通常は1/100秒単位で設定する。40だったら0.4秒毎という意味。（メーカーによって入力単位は違うかも）

つまり、Ranging Backoff 2-7、Insertion Interval 40という値が設定されているとすると、モデムがInitial Ranging Requestを送信する際、コリジョンを避けるために1.6秒〜51.2秒の間で送信を待つということになります。
DOCSISでは下り信号にUCDと呼ばれる上りチャンネル情報が含まれており、モデムは、この情報に従って順番に16回づつ上りのRangingを試して行く事になります。では、1つのチャンネルでRangingを終えるのに、どれくらいの時間がかかるのでしょうか？
計算してみましょう。（注：いずれもTDMA/A-TDMA時の計算です）

Ranging Backoff = 2-7 = 4〜128
Insertion Interval = 40 = 0.4sec
送信待ち時間幅 = 1.6sec〜51.2sec
T3 Timeoutとなる時間 = 送信待ち時間幅 × 16回 = 25.6sec〜819.2sec
平均時間 = (25.6sec+819.2sec)/2 = 422.4sec

ということで、平均すると約7分かかる見込みになります。
USDに上りチャンネル情報が4つあったとすると、モデムによっては30分近くかかる計算になりますね。
VoIP用とInternet用というように、同一幹線上に複数のCMTSがある場合には、下手をするとオンラインになるまでに1時間近くかかることも考えられます。

そこで、この問題を解決するためにRangign Backoffの設定を変更するという方法があります。
先ほどの計算式に従って、こんどはRanging Backoffを2-5へ変更してみましょう。

Ranging Backoff = 2-5 = 4〜32
Insertion Interval = 40 = 0.4sec
送信待ち時間幅 = 1.6sec〜12.8sec
T3 Timeoutとなる時間 = 送信待ち時間幅 × 16回 = 25.6sec〜204.8sec
平均時間 = (25.6sec+204.8sec)/2 = 115.2sec

わずかな変更（いや、実際には大きな変更ですが）で、1チャンネルあたりのRanging時間が2分弱になりました。これなら4チャンネルあっても、8分ほどですべてのチャンネルのRangignを終える事ができるはずです。
しかし、Rangign Backoffを短くする＝送信待ち時間の幅を短くする、という事ですので、同時にInitial Ranging Requestを送信するモデムが増え、かえってコリジョンを招いてしまう結果になりかねません。具体的には、メンテナンスなどでいっせいにモデムをリブートした際、Ranging Backoffがボトルネックとなってしまうというものです。なお、すでにオンラインになっているモデムはRanging Intervalの値によってStation Maintenance Rangingを行うので、影響はありません。


どれくらいのモデム収容数なら影響がないかについては、また次回。