Cisco uBR CMTS のアップストリーム スケジューラ モードの設定

概要

このドキュメントでは、Cable Modem Termination System（CMTS; ケーブル モデム ターミネーション システム）の Cisco Universal Broadband Router（uBR; ユニバーサル ブロードバンド ルータ）シリーズに対する、アップストリーム スケジューラ モードの設定について説明します。

このドキュメントは、Voice over IP や Video over IP など、遅延やジッタの影響を受けやすいアップストリーム サービスを活用する高速データオーバーケーブル ネットワークの設計とメンテナンス作業を行う担当者を対象にしています。

前提条件

要件

次の項目に関する知識があることが推奨されます。

• Data-over-Cable Service Interface Specification（DOCSIS; データオーバーケーブル サービス インターフェイス仕様）システム

• CMTS の Cisco uBR シリーズ

使用するコンポーネント

このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。

• Cisco uBR CMTS

• Cisco IOS® ソフトウェア リリース トレイン 12.3(13a)BC および 12.3(17a)BC

注：Cisco IOSソフトウェアの新しいリリースでの変更については、Cisco.com Webサイトで入手可能な該当するリリースノートを参照してください。

表記法

ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。

背景説明

Data-over-Cable Service Interface Specification（DOCSIS; データオーバーケーブル サービス インターフェイス仕様）ネットワークでは、ケーブル モデムが生成するすべてのアップストリーム送信のタイミングとレートを CTMS が制御します。さまざまな遅延、ジッタ、およびスループット要件のある多くのさまざまなサービスは、現在の DOCSIS ネットワーク アップストリームで同時に稼働しています。そのため、これらのさまざまなタイプのサービスに代わってケーブル モデムがいつアップストリーム送信を作成できるかを CMTS が決定するしくみを理解する必要があります。

このホワイト ペーパーは次の内容を説明しています。

• ベスト エフォート、Unsolicited Grant Service（UGS）、Real Time Polling Service（RTPS）など、DOCSIS におけるアップストリーム スケジューリング モードの概要

• Cisco uBR CMTS 用の DOCSIS 準拠スケジューラの操作と設定

• Cisco uBR CMTS 用の新しい低遅延キューイング スケジューラの操作と設定

DOCSIS でのアップストリーム スケジューリング

DOCSIS 準拠 CMTS は、サービス フローの概念によってさまざまなパケット ストリームやアプリケーションにさまざまなアップストリーム スケジューリング モードを提供できます。サービス フローは、データのアップストリーム フローまたはダウンストリーム フローのいずれかを表し、そのデータが Service Flow ID（SFID; サービス フロー ID）を一意に識別します。それぞれのサービス フローには、最大スループット、最小保証スループット、優先度など、独自の Quality of Srvice（QoS）パラメータを指定できます。アップストリーム サービス フローの場合は、スケジューリング モードも指定できます。

さまざまなタイプのアプリケーションに対応するために、1 つのケーブル モデムに複数のアップストリーム サービス フローを設定することができます。たとえば、Web と電子メールは 1 つのサービス フローを使用でき、Voice over IP（VoIP）は別のものを、そして、インターネット ゲームはまた別のサービス フローを使用することができます。これらのアプリケーションそれぞれに適切なタイプのサービスを提供できるようにするには、これらのサービス フローの特性を異なるものにする必要があります。

ケーブル モデムと CMTS は、正しいトラフィックのタイプを分類子を使用することで適切なサービス フローに向けることができます。分類子とは、アクセス リストのような特別なフィルタのことであり、UDP や TCP のポート番号などのパケット プロパティを照合して、パケットが通過するための適切なサービス フローを決定します。

図 1 で、ケーブル モデムは 3 つのアップストリーム サービス フローを使用しています。1 番目のサービス フローは音声トラフィックのために予約されています。このサービス フローは低い最大スループットですが、同時に、低遅延の保証も提供するように設定されています。2 番目のサービス フローは一般的な Web と電子メールのトラフィック用のものです。このサービス フローには高いスループットがあります。3 番目のサービス フローは peer-to-peer（P2P; ピアツーピア）トラフィック用に予約されています。このサービス フローの最大スループットには、このアプリケーションの速度を抑制するために、かなりの制限があります。

図 1：3 つのアップストリーム サービス フローがあるケーブル モデム

サービス フローは、ケーブル モデムが最初にオンラインになるときに確立され、アクティブになります。ケーブル モデムを設定するために使用する DOCSIS コンフィギュレーション ファイルにサービス フローの詳細をプロビジョニングします。DOCSIS コンフィギュレーション ファイルには、少なくとも、アップストリーム トラフィックに 1 つのサービス フローと、ダウンストリーム トラフィックに別の 1 つのサービス フローをプロビジョニングします。DOCSIS コンフィギュレーション ファイルに指定する最初のアップストリームおよびダウンストリーム サービス フローは、プライマリ サービス フローと呼ばれます。

また、サービス フローは、ケーブル モデムがオンラインになった後で動的に作成してアクティブにすることもできます。一般に、このシナリオは 1 つのサービス フローに適用され、そのサービス フローが VoIP 通話に属しているデータに対応します。そのようなサービス フローは電話の会話が始まると作成され、アクティブになります。その後、このサービス フローは通話が終了したときに非アクティブになり、削除されます。サービス フローが必要なときにだけ存在するのであれば、アップストリーム帯域幅リソースとシステムの CPU 負荷とメモリを節約できます。

ケーブル モデムは、任意のタイミングでアップストリーム送信を作成できるわけではありません。一度にアップストリーム チャネルのデータを送信できるのは 1 つのケーブル モデムだけであるため、ケーブル モデムは CMTS からの指示を必ず待ってからデータを送信します。そのようにしないと、送信がオーバーランして、互いを破損することになります。ケーブル モデムが送信を作成できるタイミングの指示は、帯域幅割り当て MAP メッセージの形式で CMTS から入ってきます。Cisco CMTS は、任意の種類の送信を作成できるタイミングをケーブル モデムに通知するために、2 ミリ秒ごとに MAP メッセージを送信します。各 MAP メッセージには、送信を作成するタイミング、送信が存在できる時間、および送信できるデータのタイプをモデムに正確に指示する情報が含まれています。つまり、ケーブル モデム データ送信は、互いに衝突することはなく、データの破損を回避します。このセクションでは、アップストリームで送信を作成するケーブル モデム権限を付与するタイミングを CMTS が判断できるいくつかの方法について説明します。

ベスト エフォート

ベスト エフォート スケジューリングは、遅延やジッタに対する厳格な要件のない従来型のインターネット アプリケーションに適しています。このタイプのアプリケーションの例としては、電子メール、Web ブラウジング、ピアツーピア ファイル転送などがあります。ベスト エフォート スケジューリングは、Voice over IP や Video over IP など、保証遅延やジッタを必要とするアプリケーションには適していません。その理由は、輻輳した状況でそのような保証のないものがベスト エフォート モードで作成されるからです。DOCSIS 1.0 システムは、このタイプのスケジューリングだけを許可します。

ベスト エフォート サービス フローは、通常は、ケーブル モデムに関連付けられた DOCSIS コンフィギュレーション ファイルにプロビジョニングされます。そのため、ベスト エフォート サービス フローは、一般に、ケーブル モデムがオンラインになるとすぐにアクティブになります。DOCSIS コンフィギュレーション ファイルでプロビジョニングされる予定の最初のアップストリーム サービス フローであるプライマリ アップストリーム サービス フローは、ベスト エフォート形式のサービス フローにする必要があります。

次に示すのは、DOCSIS 1.1/2.0 モードでベスト エフォート サービス フローを定義するパラメータで最もよく使用されるパラメータです。

• 最大持続トラフィック レート（R）

  最大持続トラフィック レートとは、このサービス フローでトラフィックが動作できる最大レートのことです。この値はビット/秒で表されます。

• 最大トラフィック バースト（B）

  最大トラフィック バーストとは、アップストリーム スループット制限を強化するトークン バケット レート リミッタに適用するバイト単位のバースト サイズのことです。値が何も指定されない場合は、デフォルト値の 3044 が適用され、それが 2 つのフル イーサネット フレームのサイズになります。大きな最大持続トラフィック レートに対しては、この値を、少なくとも最大持続トラフィック レートを 64 で除算した値に設定します。

• トラフィック優先度

  このパラメータは、0（最低）から 7（最大）までの範囲のサービス フローでのトラフィックの優先度のことです。 アップストリームでは、高優先度サービス フロー用のすべての保留中のトラフィックが、低優先度のサービス フロー用のトラフィックの前に、送信のためにスケジュールされます。

• 最小予約レート

  このパラメータは、サービス フロー用の最低保証スループット ビット/秒を示しており、Committed Information Rate（CIR; 認定情報レート）と似ています。 あるチャネルにおけるすべてのサービス フロー用の統合最小予約レートは、そのチャネルで利用可能な帯域幅を超過してはなりません。超過すると、約束された最小予約レートを保証することが不可能になります。

• 最大連結バースト

  最大連結バーストは、モデムがサービス フローの代わりに作成できる連結フレームの最大の送信をバイト単位のサイズにしたものです。このパラメータが示すように、モデムは 1 つの送信のバーストで複数のフレームを送信できます。この値が指定されていない場合、DOCSIS 1.0 ケーブル モデムと古い DOCSIS 1.1 モデムは、連結バースト サイズには明示的な制限は設定されていないと想定します。DOCSIS 1.1 以降の仕様の新しいリビジョンに準拠するモデムは、1522 バイトの値を使用します。

ケーブル モデムにアップストリーム ベスト エフォート サービス フローの代わりに送信するデータがある場合、そのモデムは遅延なしで DOCSIS ネットワークにデータを単に転送することはできません。モデムは、CMTS からの排他的なアップストリーム送信時間をモデムが要求するプロセスを経由する必要があります。この要求プロセスによって、データが、同一のアップストリーム チャネルに接続されている別のケーブル モデムの送信と衝突しなくなります。

ときには、CMTS は、帯域幅要求と呼ばれる特殊なメッセージを送信することを CMTS がケーブル モデムに許可する一定の期間をスケジュールすることがあります。帯域幅要求は、モデムが送信したいデータ量の詳細を含んでいる非常に小さなフレームと、データを送信する必要のあるアップストリーム サービス フローに対応する Service Identifier（SID; サービス識別子）で構成されます。CMTS は、アップストリーム サービス フローへの内部テーブル照合 SID 番号を維持します。

CMTS は、他のイベントがアップストリームに何もスケジュールされていないときに帯域幅要求機会をスケジュールします。つまり、スケジューラは、アップストリーム スケジューラがベスト エフォートの認可を計画していないとき、または UGS 認可または他のタイプの認可が特定の時点に配置されているときに帯域幅要求を提供します。そのため、アップストリーム チャネルが頻繁に使用されているときには、ケーブル モデムが帯域幅要求を送信する機会は少なくなります。

CMTS は、アップストリーム チャネルがどんなに輻輳するようになっても、少数の帯域幅要求機会が常に定期的に必ずスケジュールされるようにします。複数のケーブル モデムは、同時に帯域幅要求を送信し、互いの送信を破壊することができます。帯域幅要求を破壊できるコリジョンの可能性を減らすために、「バックオフおよびリトライ」アルゴリズムが実施されます。このドキュメントの残りのセクションでこのアルゴリズムについて説明します。

CMTS は、ケーブル モデムからの帯域幅要求を受け取ると、次のアクションを実行します。

1. CMTS は、帯域幅要求が関連付けられているサービス フローを調べるために、帯域幅要求で受信される SID 番号を使用します。

2. 次に、CMTS はトークン バケット アルゴリズムを使用します。このアルゴリズムによって、CMTS が要求された帯域幅を認可する場合に、サービス フローが指示された最大持続レートを超過するかどうかを CMTS は確認できます。次に示すのは、トークン バケット アルゴリズムの計算です。

   Max(T) = T * (R / 8) + B

   定義：

   • Max(T) は、時間 T を超えてサービス フローで送信できる最大バイト数を示しています。

   • T は、秒単位の時間を表しています。

   • R は、ビット/秒のサービス フローに対する最大持続トラフィック レートを示しています。

   • B は、バイト単位のサービス フロー用最大トラフィック バーストです。

3. 帯域幅要求がスループット制限内にあることを CMTS が突き止めると、CMTS は、アップストリーム スケジューラに帯域幅要求の詳細をキューイングします。アップストリーム スケジューラは、帯域幅要求をいつ認可するのかを決定します。

   Cisco uBR CMTS は、DOCSIS 準拠スケジューラと低遅延キューイング スケジューラという 2 つのアップストリーム スケジューラ アルゴリズムを実装しています。詳細については、本書の「DOCSIS 準拠スケジューラ」と「低遅延キューイング スケジューラ」を参照してください。

4. CMTS は、次回の定期帯域幅割り当て MAP メッセージに次の詳細を含めます。

   • ケーブル モデムが送信できるタイミング。

   • ケーブル モデムが送信できる期間。

帯域幅要求バックオフおよび再試行アルゴリズム

帯域幅要求メカニズムは、帯域幅要求を同時に送信する複数のケーブル モデム間のコリジョンの可能性を、完全に除去はしないものの低減するためのシンプルな「バックオフおよびリトライ」アルゴリズムを備えています。

帯域幅要求を送信すると決定するケーブル モデムは、まず帯域幅要求機会のランダム番号が渡されるのを待ってから、送信を作成します。この待機時間によって、帯域幅要求の同時送信によって発生するコリジョンの可能性が低くなります。

data backoff start と data backoff end という 2 つのパラメータによってランダム待機期間が決定されます。ケーブル モデムは、定期的な Upstream Channel Descriptor（UCD; アップストリーム チャネル ディスクリプタ）メッセージの内容の一部としてこれらのパラメータを習得します。CMTS は、アクティブな各アップストリーム チャネルの代わりに UCD メッセージを 2 秒ごとに送信します。

これらのバックオフ パラメータは、「2 の累乗」の値として表されます。モデムは、これらのパラメータを 2 の乗数として使用し、帯域幅要求を送信するまでに待機する時間の長さを計算します。どちらの値も範囲は 0 から 15 までであり、data backoff end は、data backoff start 以上の値にする必要があります。

ケーブルモデムが特定の帯域幅要求を初めて送信するときは、最初に0 ～ 2の範囲の乱数をdata backoff startから1の累乗にピックする必要があります。たとえば、data backoff startが3に設定されている場合、モデムは0 ～ (23 - 1) = (8 - 1) = 7。

その後、ケーブル モデムは、帯域幅要求伝送機会の選択済みのランダム番号が通過するのを待ってから、帯域幅要求を送信する必要があります。つまり、モデムがこの強制遅延のために次回の利用可能な機会に帯域幅要求を送信できないでいる間は、別のモデムの送信によるコリジョンの可能性は減少します。

data backoff start の値が大きくなればなるほど、帯域幅要求間のコリジョンの可能性が低くなるのは自然なことです。また、data backoff start 値が大きくなることは、モデムが帯域幅要求を送信するために待つ時間が長くなることになり、そのためにアップストリーム遅延が増えることも意味します。

CMTS には、次回の送信される帯域幅割り当て MAP メッセージでの確認応答が含まれます。この確認応答は、帯域幅要求の受信が成功したことをケーブル モデムに通知します。この確認応答で次のことができます。

• モデムがいつ送信を実行できるかを正確に示す

  または

• 帯域幅要求が受信されており、送信の時間は将来の MAP メッセージで決定されることだけを示す

CMTS が次回の MAP メッセージに帯域幅要求の確認応答を含まない場合、モデムは帯域幅要求が受信されなかったと結論づけることができます。この状況は、帯域幅要求が認可された場合、コリジョンやアップストリームのノイズのため、またはサービス フローが指示された最大スループット レートを超過するために発生する可能性があります。

どの場合でも、ケーブル モデムの次のステップはバックオフを行い、帯域幅要求をもう一度送信することです。モデムはランダム値が選択される範囲を拡大します。これを行うために、モデムは data backoff start 値に 1 を加算します。たとえば、data backoff start 値が 3 に設定され、CMTS が 1 つの帯域幅要求送信を受信できない場合、モデムは再送信の前に 0～ 15 の帯域幅要求機会内のランダム値を待機します。次に示すのがこの計算式です。23+1 - 1 = 24 - 1 = 16 - 1 = 15

さらに大きな値にすると、別のコリジョンの機会が減少します。モデムがさらに帯域幅要求を失った場合、モデムは各再送信のために 2 の累乗として値を増分することを、値が data backoff end と同じになるまで続行します。2 の累乗は data backoff end 値よりも大きくなることはできません。

モデムは、最大 16 回まで帯域幅要求を再送信し、その後、モデムは帯域幅要求を廃棄します。この状況は、輻輳が非常に発生しやすい状況だけで発生します。

次のケーブル インターフェイス コマンドを使用すると、data backoff start 値と data backoff end 値を Cisco uBR CMTS でケーブル アップストリームごとに設定できます。

cable upstream upstream-port-id data-backoff data-backoff-start data-backoff-end

Ciscoでは、data-backoff-startパラメータとdata-backoff-endパラメータのデフォルト値を3と5のままにすることを推奨しています。ベストエフォートスケジューリングシステムのコンテンションベースの特性は、ベストエフォートサービスフローでは、アップストリーム遅延またはジッタの確定的または保証レベルを提供できません。さらに、輻輳した状況では、ベスト エフォート サービス フロー用のスループットの特定レベルを保証することが不可能になります。ただし、優先度や最小予約レートなどのサービス フロー プロパティを使用できます。これらのプロパティがあると、サービス フローは輻輳した状況で希望のスループット レベルを達成することができます。

バックオフおよび再試行アルゴリズムの例

この例は、同じアップストリーム チャネルに接続されている A、B、C、D という 4 つのケーブル モデムで構成されています。t₀ という同じ瞬間に、モデム A、B、および C が、アップストリームでのいくつかのデータの送信を決定します。

ここでは、data backoff startが2に設定され、data backoff endが4に設定されています。モデムが帯域幅要求を最初に送信する前に間隔を選択する間隔の範囲は、0 ～ 3です。計算は次のとおりです。

(22 - 1) = (4 - 1) = 3間隔

次に示すのは、3 つのモデムが時間 t₀ を待つために選ぶ帯域幅要求機会の番号です。

• モデム A：3

• モデム B：0

• モデム C：3

モデム A とモデム C が同じ番号の機会を選ぶために待機していることに注目してください。

モデム B は、t₀ の後に現れる 2 つの帯域幅要求機会を待ちます。 次に、モデム B は帯域幅要求を送信し、それを CMTS が受信します。モデム A とモデム C の両方が、t₀ の後に 3 つの帯域幅要求機会が通過するのを待ちます。 その後、モデム A と C は同時に帯域幅要求を送信します。これら 2 つの帯域幅要求は衝突し、破壊されます。その結果、どちらの要求も CMTS に正常に到達しません。図 2 に、このイベントのシーケンスを示します。

図 2：帯域幅要求の例、パート 1

図の上部にある灰色のバーは、時間t₀後にケーブルモデムが使用できる一連の帯域幅要求機会を表します。色付きの矢印は、ケーブルモデムが送信する帯域幅要求を表します。灰色の帯の中にある色付きの四角は、CMTS に正常に到達する 1 つの帯域幅要求を表しています。

CMTSからブロードキャストされる次のMAPメッセージには、モデムBの認可が含まれていますが、モデムAとモデムCの命令は含まれていません。これは、モデムAとモデムCに帯域幅要求を再送信する必要があることを示しています。

2 回目の試行時に、モデム A およびモデム C は、選択する間隔の範囲を計算するときに、使用する 2 の累乗を増分する必要があります。ここで、モデムAとモデムCは0 ～ 7の範囲のランダムな数を選択します。次に計算を示します。

(22+1 -1) = (23 - 1) = (8 - 1) = 7間隔

モデムAとモデムCが再送の必要性を認識する時間がt₁であると仮定します。また、モデムDと呼ばれる別のモデムが同時にアップストリームデータを送信することを決定したと仮定します。モデムDは最初の帯域幅要求送信です。したがって、モデムDはdata backoff startとdata backoff endに元の値を使用します(0から3 [(22 - 1) = (4 - 1) = 3間隔)。

3 つのモデムは、これらの帯域幅要求機会のランダム番号を選び、時間 t1 から待機します。

• モデム A：5

• モデム C：0

• モデム D：0

モデムCとモデムDはどちらも、時間t₁の後に現れる2つの帯域幅要求機会を待ちます。モデムCとモデムDは、同時に帯域幅要求を送信します。これらの帯域幅要求は衝突し、そのため、CMTS には到達しません。モデム A は、5 つの帯域幅要求機会が通過するのを許します。次に、モデム A は帯域幅要求を送信し、CMTS はそれを受信します。図3は、モデムCとDの送信の間のコリジョンと、モデムAの送信の正常な受信を示しています。この図の開始時間基準はt_1です。

図 3：帯域幅要求の例、パート 2

CMTS からブロードキャストされる次の MAP メッセージには、モデム A の認可が含まれていますが、モデム C および D の指示は含まれません。モデム C と D は帯域幅要求の再送信の必要性を認識しています。現在、モデム D は、2 回目の帯域幅要求を送信しようとしています。そのため、モデム D は、2 の累乗として data backoff start + 1 を、待機する間隔の範囲の計算で使用します。モデムDは0 ～ 7の間隔を選択します。次に計算を示します。

(22+1 - 1) = (23 - 1) = (8 - 1) = 7間隔

モデム C は、3 回目の帯域幅要求を送信しようとしています。そのため、モデム C は、2 の累乗として data backoff start + 2 を、待機する間隔の範囲の計算で使用します。モデムCは0 ～ 15の間隔を選択します。計算は次のとおりです。

(22+2 - 1) = (24 - 1) = (16 - 1) = 15間隔

ここでの 2 の累乗は data backoff end 値と同じ 4 であることに注目してください。これは、2 の累乗の値がこのアップストリーム チャネルのモデムに対してできる最も高い値です。次の帯域幅要求送信サイクルでは、2 つのモデムが待機するために次の帯域幅要求機会の番号を選びます。

• モデム C：9 ミリ秒

• モデム D：4

モデム D は帯域幅要求を送信可能であり、これは、モデム D が 4 つの帯域幅要求機会が通過するのを待機するためです。さらに、モデム C も帯域幅要求を送信可能であり、これは、現在、モデム C が 9 つの帯域幅要求機会の送信を延期しているためです。

残念ながら、モデム C が送信を行おうとしたときに、入力ノイズの大量のバーストが送信を干渉し、CMTS が帯域幅要求を受信できなくなります（図 4 を参照）。 その結果、再度、モデム C は CMTS が送信する次回の MAP メッセージで認可を確認できなくなります。これによってモデム C は、帯域幅要求の 4 番目の送信を行おうとします。

図 4：帯域幅要求の例、パート 3

モデム C は、data backoff end の 4 の値にすでに到達しています。 モデム C は、間隔のランダム番号を選ぶために使用する範囲を増やして待機することはできません。そのため、モデム C は、ここでも 2 の累乗の 4 を使用してランダムな範囲を計算します。モデム C は、この計算によって 0 ～ 15 の範囲の間隔を引き続き使用します。

(24 - 1) = (16 - 1) = 15間隔

4 番目の試行時に、モデム C はコンテンションまたはノイズがない状態で正常な帯域幅要求送信を行うことができます。

この例におけるモデム C の複数の帯域幅要求再送信は、輻輳しているアップストリーム チャネルで発生する可能性のあることを具体的に示しています。また、この例は、発生する可能性のあるベスト エフォート スケジューリング モードに含まれる問題と、ベスト エフォート スケジューリングが、パケット遅延とジッタの厳密に制御されたレベルを必要とするサービスには適していない理由を具体的に示します。

トラフィック優先度

CMTS に複数のサービス フローからの複数の保留中の帯域幅要求がある場合、CMTS はどのサービス フローに最初に帯域幅を付与するかを決定するために、それぞれのサービス フローのトラフィック優先度を確認します。

CMTS は、より高い優先度のサービス フローからの保留中の要求すべてに送信時間を付与してから、より低い優先度のサービス フローからの帯域幅要求を認可します。輻輳したアップストリーム状況において、これは、一般に、低い優先度のサービス フローと比較して、高い優先度のサービス フローにより高いスループットが提供されます。

注目すべき重要な事実は、高優先度のベスト エフォート サービス フローが帯域幅を即座に受信する傾向にある一方で、そのサービス フローは引き続き帯域幅要求コリジョンの可能性にさらされるということです。このため、トラフィック優先度はサービス フローのスループットと遅延特性を強化できますが、それを必要とするアプリケーションに対してサービス保証を提供するための適切な方法ではありません。

最小予約レート

ベスト エフォート サービス フローは、準拠する最小の予約レートを受信できます。CMTS は、指定された最小予約レートのサービス フローが、優先度に関係なく、他のすべてのベスト エフォート サービス フローよりも先に帯域幅を必ず受け取るようにします。

この方法は、フレームリレー ネットワークに類似している一種の Committed Information Rate（CIR; 認定情報レート）形式のサービスを提供する試みです。CMTS には、特定のアップストリーム上で、接続されたすべてのサービス スローの連結最小予約レートがアップストリーム チャネルの利用可能な帯域幅、またはそのパーセンテージを超過できなくするアドミッション制御メカニズムがあります。これらのメカニズムは、次のアップストリーム ポートごとのコマンドでアクティブにできます。

[no] cable upstream upstream-port-id admission-control max-reservation-limit

max-reservation-limit パラメータには 10 ～ 1000% の範囲があり、これによって CIR 形式のサービスが消費できる未加工の利用可能なアップストリーム チャネル スループットと比較して、サブスクリプションのレベルを示すことができます。max-reservation-limit を 100 よりも上に設定した場合、アップストリームは、指定されたパーセンテージの制限によって CIR 形式のサービスをオーバーサブスクライブできます。

CMTS は、新しい最小予約レート サービス フローが、アップストリーム ポートが利用可能なアップストリーム チャネル帯域幅の設定済みの max-reservation-limit パーセンテージを超える原因となる場合、そのサービス フローを確立させません。最小予約レート サービス フローは、引き続き帯域幅要求のコリジョンの可能性にさらされます。そのように、最小予約レート サービス フローは、特に非常に輻輳している場合は、特定のスループットの真の保証は提供できません。いいかえると、ＣCMTS がケーブル モデムからの必要なすべての帯域幅要求を受信できる場合、CMTS は最小予約レート サービス フローが特定の保証アップストリーム スループットを達成できることを保証することだけができます。この要件は、サービス フローを、ベスト エフォート サービス フローではなく Real Time Polling Service（RTPS）サービス フローにする場合に達成できます。詳細については、「Real Time Polling Service（RTPS）」を参照してください。

ピギーバック帯域幅要求

アップストリーム ベスト エフォート サービス フローが高いレートでフレームを送信するとき、帯域幅要求の独立した送信をするのではなく、アップストリーム データ フレームに帯域幅要求をピギーバックすることができます。帯域幅の次の要求の詳細は、アップストリーム内で CMTS に送信されるデータ パケットのヘッダーに追加されるだけです。

これは、帯域幅要求がコンテンションにさらされず、そのため、要求が CMTS に到達するさらに高い機会があることを意味します。ピギーバック帯域幅要求の概念は、イーサネット フレームがアップストリーム送信で費やす時間が短縮されるので、イーサネット フレームがエンド ユーザの Customer Premise Equipment（CPE; 顧客宅内機器）に到達するためにかかる時間を短縮します。短縮できるのは、モデムが、遅延に陥りやすいバックオフおよびリトライ帯域幅要求送信プロセスを通過する必要がないためです。

帯域幅要求をピギーバックすることは、一般には次のようなシナリオで発生します。

ケーブル モデムはフレーム X の送信をアップストリームで待機しているときに、アップストリームに送信する別のフレーム Y を CPE から受信します。ケーブル モデムは新しいフレーム Y からのバイトを送信には追加できません。その理由は、それを行うと、モデムが付与されているアップストリーム時間よりも多くの時間を消費することになるためです。その代わりに、モデムはフレーム X の DOCSIS ヘッダーのフィールドに値を挿入して、フレーム Y に必要な送信時間の量を示します。

CMTS は Y の代わりにフレーム X と帯域幅要求の詳細を受信します。アベイラビリティを基準にして、CMTS は Y の代わりにモデムにさらなる送信時間を認可します。

非常に控えめに時間を計算すると、帯域幅要求の送信と帯域幅割り当ての受信の間と、データ送信に時間を割り当てる MAP 確認応答も含めると、最短でも 5 ミリ秒が経過します。これは、ピギーバックが発生するには、ケーブル モデムは互いに 5 ミリ秒未満で CPE からのフレームを受信する必要があるということになります。

これは、G.711 のような典型的な VoIP コーデックが、一般に 10 ミリ秒または 20 ミリ秒のフレーム間期間を使用するため、注目に値します。ベスト エフォート サービス フローで動作する典型的な VoIP ストリームは、ピギーバックのメリットを活用できません。

連結

アップストリーム ベスト エフォート サービス フローがフレームを高いレートで送信するとき、ケーブル モデムはいくつかのフレームを 1 つにまとめてそのフレームのまとまりをすべて一度に送信する権限を要求します。これを連結といいます。ケーブル モデムは連結されたフレームのグループですべてのフレームの代わりに 1 つだけの帯域幅要求を送信する必要があり、これによって効率が高まります。

連結は、ケーブル モデムが帯域幅要求を送信すると決定したときに、連結がケーブル モデム内部で複数のフレームをキューイングするように要求する場合を除き、ピギーバックに似た環境で発生する傾向があります。これは、連結がピギーバックよりも平均的に高いフレーム レートで発生する傾向にあることを示しています。また、両方のメカニズムは、通常、ベスト エフォート トラフィックの効率を向上させるために連携しています。

サービス フローのために設定できる最大連結バースト フィールドは、サービス フローが送信できる連結フレームの最大サイズを制限します。また、連結されたフレームのサイズとアップストリーム チャネル変調プロファイルの最大バースト サイズを限定するために cable default-phy-burst コマンドを使用することもできます。

連結は、CMTS の Cisco uBR シリーズのアップストリーム ポートではデフォルトで有効になっています。ただし、[no] cable upstream upstream-port-id concatenation [docsis10] ケーブル インターフェイス コマンドを使用して、アップストリーム ポートごとに連結を制御できます。

docsis10 パラメータを設定した場合、コマンドは DOCSIS 1.0 モードで動作するケーブル モデムだけに適用されます。

このコマンドに変更を加えると、ケーブル モデムはその変更を有効にするために CMTS 上で再登録する必要があります。影響を受けたアップストリーム上にあるモデムはリセットされる必要があります。ケーブル モデムは、モデムがオンラインになる処理の一部として登録を実行する場所で、連結が許可されるかどうかを習得します。

フラグメンテーション

大きなフレームは、アップストリームで送信するのに長い時間がかかります。この送信時間はシリアライゼーション遅延と呼ばれています。特に大きなアップストリーム フレームは送信に非常に長い時間がかかることがあるので、VoIP など、時間の影響を受けやすいサービスに属しているパケットでは害を及ぼすかたちで遅延を引き起こす可能性があります。これは長く連結されたフレームで特に当てはまります。このため、DOCSIS 1.1 にフラグメンテーションが導入されました。大きなフレームをより小さなフレームに分割し、分解バーストで送信することで、それぞれの送信にかかる時間を短縮します。

フラグメンテーションでは、大きなフレーム全体の送信を待機するのではなく、大きなフレームのフラグメントの間で、時間の影響を受ける小さなフレームがインターリーブすることが許可されています。複数のフラグメントとしてフレームを送信すると、各フラグメントに余分な DOCSIS ヘッダー セットが付随されるので、1 つのバーストで 1 つのフレームを送信することよりも少しだけ効率が落ちます。しかし、フラグメンテーションによりアップストリーム チャネルに柔軟性が追加されるので、余分なオーバーヘッドも妥当と考えることができます。

DOCSIS 1.0 モードで動作するケーブル モデムはフラグメンテーションを実行できません。

フラグメンテーションは、CMTS の Cisco uBR シリーズのアップストリーム ポートでデフォルトで有効になります。ただし、[no] cable upstream upstream-port-id fragmentation ケーブル インターフェイス コマンドを使用して、アップストリーム ポートごとにフラグメンテーションを有効または無効にできます。

このコマンドを有効にするためにケーブル モデムをリセットする必要はありません。Cisco は、フラグメンテーションを常に有効にしておくことをお勧めします。通常、フラグメンテーションは、大きなデータ フレームが時間の影響を受けやすい小さなフレームの送信または特定の定期的な DOCSIS 管理イベントの送信を干渉する可能性があると CMTS が認識しているときに発生します。

DOCSIS 1.1/2.0 ケーブル モデムに、すべての大きなフレームのフラグメント化を強制するには、[no] cable upstream upstream-port-id fragment-force [threshold number-of-fragments] ケーブル インターフェイス コマンドを使用します。

デフォルトで、この機能は無効になっています。構成でthresholdとnumber-of-fragmentsの値を指定しない場合、しきい値は2000バイトに設定され、フラグメントの数は3に設定されます。fragment-forceコマンドは、サービスフローが指定されたしきい値パラメータとの送信要求バイト数をを比較します。要求サイズがしきい値よりも大きな場合、CMTS は「number-of-fragments」と同じサイズのパートでサービス フローに帯域幅を付与します。

たとえば、特定のアップストリームの fragment-force が、threshold には 2000 バイト、number-of-fragments には 3 の値を有効にしているとします。次に、3000 バイトのバーストを送信する要求が入ってきたとします。3000 バイトは 2000 バイトの threshold よりも大きいので、フラグメント化する必要があります。number-of-fragments が 3 に設定されているので、送信時間は 1000 バイトずつ等分に分けられた 3 つになります。

個別のフラグメントのサイズが使用中のケーブル ラインカード タイプの容量を上回らないように注意します。MC5x20S ラインカードの場合、最も大きな個別フラグメントを 2000 バイト以内にする必要があり、MC28U、MC5x20U、MC5x20H などのその他のラインカードの場合は、最も大きな個別フラグメントを 4000 バイト以内にする必要があります。

Unsolicited Grant Service（UGS）

Unsolicited Grant Service（UGS）は、ケーブル モデムが帯域幅要求を送信することなく、アップストリーム サービス フローに定期的な認可を提供します。このタイプのサービスは、定期的な間隔で固定サイズのフレームを生成し、パケットの損失に対応しないアプリケーションに適しています。Voice over IP は、その典型的な例です。

UGS スケジューリング システムを、T1 や E1 回線などの Time Division Multiplexing（TDM; 時分割多重）システムでのタイムスロットと比較します。UGS は保証スループットと遅延を提供します。これが、次に固定長定期間隔の継続的なストリームを提供し、クライアントが帯域幅に対して定期的に要求したり、競合したりする必要なく送信できます。このシステムは、音声トラフィックが一般に固定長の定期的データの継続ストリームとして送信されるため、VoIP にとって最適です。

UGS は、遅延の保証がないために、ベスト エフォート スケジューリング モードでジッタとスループットを生み出していました。ベスト エフォート スケジューリング モードは、特定のフレームを特定の時間に送信できるという保証を提供せず、輻輳したシステムでは、特定のフレームがすべて送信できるという保証もありません。

UGS 形式のサービス フローが VoIP ベアラ トラフィックを運ぶには最も適切なサービス フローのタイプであるにもかかわらず、Web、電子メール、P2P などの従来からのインターネット アプリケーションには適切なものと見なされていないことに注意してください。その理由は、従来からのインターネット アプリケーションは、固定長定期間隔でデータを生成せず、事実、データをまったく送信しない時間にかなりの期間を費やす可能性があるためです。UGS サービス フローが従来からのインターネット トラフィックを運ぶために使用された場合、そのサービス フローは、アプリケーションが一時的に送信を停止するときにかなりの期間使用されない状態になる可能性があります。これは、アップストリーム帯域幅リソースの浪費を示す未使用の UGS 認可になる可能性があり、これは好ましくありません。

UGS サービス フローは、通常、DOCSIS コンフィギュレーション ファイルでプロビジョニングされるよりも、必要とされるときに動的に確立されます。統合された VoIP ポートのあるケーブル モデムは、通常、モデムがその VoIP 通話が進行中であることを検出したときに適切な UGS サービス フローを作成することを CMTS に尋ねます。

Cisco は、DOCSIS コンフィギュレーション ファイルで UGS サービス フローを設定しないことをお勧めします。その理由は、ケーブル モデムがオンラインである限り、いずれのサービスがそれを使用するかどうかに関係なく、この設定が UGS サービス フローをアクティブなままにするためです。この設定は、UGS サービス フローがケーブル モデムの代わりにアップストリーム送信時間を絶えず予約するため、アップストリーム帯域幅を浪費することになります。UGS サービス フローを動的に作成または削除することを許可する方が、必要なときに UGS がアクティブになるので、はるかに適切です。

次に、UGS サービス フローを定義する、最も一般的に使用されるパラメータを示します。

• 任意認可サイズ（G）：それぞれの定期的な認可のバイト単位のサイズ。

• 公称認可間隔（I）：認可間のマイクロ秒単位の間隔。

• 許容認可ジッター（J）：正確に定期的な認可から許可されたマイクロ秒単位の変動。つまり、これは、CMTS が UGS 認可を時間どおりにスケジュールしようとするときに CMTS が持っている余地です。

UGS サービス フローがアクティブのときに、すべての（I）ミリ秒で、CMTS は（G）バイト（任意認可サイズ）で送信するようにサービス フローに機会を提供します。理想的には CMTS が正確に毎（I）ミリ秒の認可を提供するのですが、最大（J）ミリ秒まで遅延する可能性があります。

図 5 は、提供された認可サイズ、認可間隔、および許容ジッタで UGS 認可がどのように割り当てられるかを具体的に示すタイムラインを示しています。

図 5：定期 UGS 認可を示すタイムライン

緑の模様の四角は、CMTS が UGS サービス フローにだけアップストリーム送信時間を提供する時間を表しています。

Real Time Polling Service（RTPS）

Real Time Polling Service（RTPS）は、サービス フローが帯域幅要求の送信に専用の時間を持つように、非コンテンション ベースの帯域幅要求機会を提供します。このユニキャスト帯域幅要求機会の使用を許可されるのは、RTPS サービス フローだけです。他のケーブル モデムは、帯域幅要求コリジョンを引き起こすことはできません。

RTPS は、効果的に動作するように、半定期的に可変長フレームを生成し、最小保証スループットを必要とするアプリケーションに適しています。IP 上のビデオ テレフォニーや複数プレーヤーのオンライン ゲームなどは典型的な例です。

RTPS は VoIP シグナリング トラフィックにも使用されます。VoIP シグナリング トラフィックは極端な低遅延またはジッタで送信される必要はありませんが、VoIP は相当の時間で CMTS に到達できる可能性が高い必要があります。ベスト エフォート スケジューリングでなく RTPS を使用する場合、音声シグナリングは繰り返す帯域幅要求コリジョンのために大幅に遅延されたり廃棄されたりはしないと確信できます。

一般に、RTPS サービス フローは次の属性を処理します。

• 公称ポーリング間隔：ユニキャスト帯域幅要求機会間のマイクロ秒単位の間隔。

• 許容ポーリング ジッター：正確に定期的なポーリングから許可されたマイクロ秒単位の変動。いいかえると、これは、CMTS が RTPS ユニキャスト帯域幅要求機会を時間どおりにスケジュールしようとするときに CMTS が持っている余地です。

図 6 は、RTPS ポールが、提供された公称ポーリング間隔と許容ポール ジッターでどのように割り当てられるかを具体的に示すタイムラインです。

図 6：定期 RTPS ポーリングを示すタイムライン

緑の模様の四角は、CMTS が RTPS サービス フローにユニキャスト帯域幅要求機会を提供する時間を表しています。

CMTS が RTPS サービス フローの代わりに帯域幅要求を受信すると、CMTS は「ベスト エフォート」サービス フローからの要求と同じように帯域幅要求を処理します。これは、前述のパラメータに加えて、最大持続トラフィック レートやトラフィック優先度などのプロパティが、RTPS サービス フロー定義に含まれる必要があることを意味します。RTPS サービス フローは、通常、サービス フローに関連付けられているトラフィックが認定帯域幅保証を確実に受信できるように、最小予約トラフィック レートも含んでいます。

Unsolicited Grant Service with Activity Detection（UGS-AD）

Unsolicited Grant Service with Activity Detection（UGS-AS）は、UGS-AS が実際にパケットを送信する必要があるときにだけ、サービス フローに UGS 形式の送信時間を割り当てます。CMTS は、ケーブル モデムが特定の期間フレームを送信していないことを検出したときに、UGS 形式の認可ではなく RTPS 形式の帯域幅要求機会を提供します。その後にサービス フローが帯域幅要求を作ることを CMTS が検出した場合、CMTS は UGS 形式の認可を提供するためにサービス フローを戻して、RTPS 形式の帯域幅要求機会の提供を停止します。

UGS-AD は、通常、Voice Activity Detection（VAD; 音声アクティビティ検出）を使った VoIP トラフィックが伝達された状況で使用されます。音声アクティビティ検出は、UGS-AD がユーザの音声で一時停止を検出した場合、VoIP エンド ポイントが VoIP フレームの送信を停止する原因になります。この動作は帯域幅を節約できますが、終端パーティが発話の再開を開始した少し後に、VAD または UGS-AD アクティビティ検出メカニズムがアクティブになる場合は特に、音声品質の問題を引き起こす可能性があります。これで、ユーザが静寂の後に発話を再開すると、ポンやカチッという音が鳴ることがあります。この理由があるため、UGS-AD は広く展開されていません。

CMTS が非アクティブな UGS-AD サービス フローを UGS モードから RTPS モードに切り替えた後の期間を設定するには、cable service flow inactivity-threshold threshold-in-seconds グローバル CMTS コンフィギュレーション コマンドを発行します。

threshold-in-seconds パラメータのデフォルト値は 10 秒です。UGS-AD サービス フローは、一般に、UGS サービス フローと公称ポーリング間隔の属性、RTPS サービス フローに関連付けられた許容ポール ジッタ属性を持っています。

Non Real Time Polling Service（nRTPS）

Non Real Time Polling Service（nRTPS）スケジューリング モードは、nRTPS がファイル転送などの非対話型サービスに一般に関連付けられること以外は、RTPS と基本的に同じです。非リアルタイム コンポーネントは、ユニキャスト帯域幅要求機会用の公称ポーリング間隔が正確に定期的ではないか、1 秒ごとよりも遅いレートで発生する可能性があると示すことがあります。

ケーブル ネットワークのオペレータの中には、音声シグナリング トラフィックを運ぶのに RTPS サービス フローではなく nRTPS を使用する傾向にあるものもあります。

スケジューリング アルゴリズム

DOCSIS 準拠スケジューラと低遅延キューイング スケジューラの詳細を説明する前に、アップストリーム スケジューラの特性を判断するために、必要なトレードオフを理解する必要があります。スケジューラ アルゴリズムの説明は、主に、UGS スケジューリング モードについてですが、この説明は RTPS 形式についても同じように当てはまります。

UGS サービス フローをスケジュールする方法を決定するときに、柔軟なオプションはそれほど多くは存在しません。スケジューラに対して認可サイズを変更することや、UGS サービス フローの認可間隔を変更することはできません。その理由は、そのような変更を行うと、VoIP コールが完全に失敗するからです。ただし、ジッタを変更した場合、コールで遅延が増加する可能性があるにもかかわらず、コールは動作します。さらに、アップストリームで許可されているコールの最大数の変更は、個別のコールの品質には影響を与えません。そのため、多数の UGS サービス フローをスケジュールするときには、次の 2 つの主な要因を考慮します。

• ジッター

• アップストリームあたりの UGS サービス フロー容量

ジッター

許容認可ジッタは、UGS または RTPS サービス フローの属性の 1 つとして指定されます。ただし、非常に低い許容ジッタを伴ういくつかのサービス フローと、非常に大量のジッタを伴うその他のサービス フローの同時サポートは、効率的ではない可能性があります。一般に、サービス フローがアップストリームで遭遇するジッタのタイプには、一貫した選択を行う必要があります。

低いレベルのジッタが必要とされる場合、スケジューラは、スケジュールが認可されたときには柔軟性のない、固定のものにする必要があります。結果として、スケジューラは、アップストリームでサポートされる UGS サービス フローの数に制限を設ける必要があります。

ジッタ レベルは通常のコンシューマ VoIP のために必ずしも極端に低くする必要はなく、その理由は、ジッタ バッファ テクノロジーが高いレベルのジッタに補正できるためです。現在の適応型 VoIP ジッタ バッファは、150 ミリ秒のジッタよりも多くを補正することができます。ただし、VoIP ネットワークは、パケットの遅延に対して発生するバッファリングの量を追加します。高いレベルの遅延は、VoIP の遭遇がより貧弱になる一因になります。

アップストリームあたりの UGS サービス フロー容量

チャネル幅、変調方式、誤り訂正強度などの物理層属性は、アップストリームの物理容量を決定します。ただし、アップストリームがサポートできる同時 UGS サービス フローの数は、スケジューラ アルゴリズムにも依存します。

非常に低いジッタ レベルが必須ではない場合は、スケジューラの厳密さを緩めて、アップストリームが同時にサポートできる UGS サービスフローの数を増やすように便宜を図ることができます。ジッタ要件を緩めた場合、アップストリームでの非音声トラフィックの効率性を高めることができます。

注：異なるスケジューリングアルゴリズムにより、特定のアップストリームチャネルで、さまざまな数のUGSおよびRTPSサービスフローをサポートできます。ただし、そのようなサービスは DOCSIS システムでは 100% のアップストリーム容量を利用できません。これは、ケーブル モデムが CMTS との最初のやり取りを行うときに使用する初期メンテナンス メッセージや、ケーブル モデムが CMTS への接続性を確実に維持できるために使用するステーション メンテナンス キープアライブ トラフィックなどの DOCSIS 管理トラフィックにある部分を専用に使用する必要があるためです。

DOCSIS 準拠スケジューラ

DOCSIS 準拠スケジューラは、Cisco uBR CMTS におけるスケジューリング アップストリーム サービス用のデフォルト システムです。このスケジューラは、UGS および RTPS サービス フローが遭遇するジッタを最小化するように設計されました。ただし、このスケジューラでは、アップストリームごとの同時 UGS コールの数を最適化するために、ある程度の柔軟性を引き続き維持できます。

DOCSIS 準拠スケジューラは、UGS サービス フローより先にアップストリーム時間を事前に割り当てます。他のいずれかの帯域幅割り当てがスケジュールされる前に、CMTS はアクティブな UGS サービス フローに属している認可に対する将来の時間を取りおいておき、他のタイプのサービス フローまたはトラフィックが UGS 認可を取り換えることのないように、また、大きなジッタの原因にならないようにします。

CMTS がベスト エフォート形式サービス フローの代わりに帯域幅要求を受信した場合、CMTS は各 UGS 認可のタイムリーなスケジューリングに影響を与えないように、事前に割り当てられた UGS 認可の周りにベスト エフォート サービス フローの送信時間をスケジュールする必要があります。

コンフィギュレーション

DOCSIS 準拠スケジューラは、Cisco IOS ソフトウェア リリース 12.3(9a)BCx およびそれ以前でだけ利用できるアップストリーム スケジューラ アルゴリズムです。そのため、このスケジューラには、アクティブにするために必要な設定コマンドがありません。

Cisco IOS ソフトウェア リリース 12.3(13a)BC およびそれ以降の場合、DOCSIS 準拠スケジューラは、2 つの代替スケジューラ アルゴリズムの 1 つですが、デフォルト スケジューラとして設定されます。DOCSIS 準拠スケジューラは、次のスケジューリング タイプのうち、1 つ、いくつか、すべてに対して有効にできます。

• UGS

• RTPS

• NRTPS

これらのスケジューリング タイプのそれぞれの DOCSIS 準拠スケジューラを明示的にイネーブルにするには、cable upstream upstream-port scheduling type [nrtps | rtps | ugs] mode docsisケーブルインターフェースのコマンド。

DOCSIS 準拠スケジューラの使用は、デフォルト設定の一部です。そのため、非デフォルト低遅延キューイング スケジューラ アルゴリズムから戻して変更する場合にだけ、このコマンドを実行する必要があります。詳細については、「低遅延キューイング スケジューラ」の項を参照してください。

アドミッション制御

DOCSIS 準拠スケジューラの大きなメリットは、このスケジューラにより UGS サービス フローがアップストリームをオーバーサブスクライブしないことです。新しい UGS サービス フローを確立する必要があり、余裕がないためにスケジューラが認可の事前スケジュールが不可能であることを発見した場合、CMTS は新しい UGS サービス フローを拒否します。VoIP トラフィックを運ぶ UGS サービス フローがアップストリーム チャネルをオーバーサブスクライブすることを許可された場合、すべての VoIP コールの品質は大きく低下します。

UGS サービス フローがアップストリームをオーバーサブスクライブすることはないと DOCSIS 準拠スケジューラが確約する方法を示すには、このセクションの図を参照してください。図 7、8、9 は、帯域幅割り当てタイムラインを示しています。

これらのすべての図で、色付きの模様の部分は、ケーブル モデムがその UGS サービス フローの代わりに認可を受信する場所の時間を示します。他のケーブル モデムからの他のアップストリーム送信はその時間には発生しません。タイムラインの灰色の部分は、まだ割り当てられていない帯域幅です。ケーブル モデムはこの時間を使用して帯域幅要求を送信します。CMTS は、この時間を後で使用して、他のタイプのサービスをスケジュールします。

図 7：DOCSIS 準拠スケジューラが 3 つの UGS サービス フローを事前にスケジュールする

同一の認可サイズと認可間隔でさらに 2 つの UGS サービス フローを追加します。ここでも、スケジューラは問題なくそれらを事前にスケジュールします。

図 8：DOCSIS 準拠スケジューラが 5 つの UGS サービス フローを事前にスケジュールする

先に進み、さらに 2 つの UGS サービス フローを追加すると、利用できるすべてのアップストリーム帯域幅を使い切ることになります。

図 9：UGS サービス フローは利用可能なすべてのアップストリーム帯域幅を消費する

明らかに、スケジューラは、ここでさらに UGS サービス フローを許可することはできません。そのため、別の UGS サービス フローがアクティブになろうとすると、DOCSIS 準拠スケジューラは、さらに認可を行う余裕がないことを認識し、そのサービス フローの確立を妨げます。

注：このシリーズの図に示すように、アップストリームをUGSサービスフローで完全に満たすことは不可能です。スケジューラは、ステーション メンテナンス キープアライブやベスト エフォート データ トラフィックなどの、他の重要なタイプのトラフィックに対応する必要があります。また、DOCSIS 準拠スケジューラでオーバーサブスクリプションを回避することの保証は、すべてのサービス フロー スケジューリング モード、主に UGS、RTPS、nRTPS が DOCSIS 準拠スケジューラを使用する場合にだけ当てはまります。

DOCSIS 準拠スケジューラを使用するときに明示的なアドミッション制御設定は必要ありませんが、Cisco はアップストリーム チャネル使用率がベスト エフォート トラフィックに悪い影響を与えるようなレベルまで確実に上がらないようにすることをお勧めします。また、Cisco は、アップストリーム チャネル使用率の合計が、重要な時間の 75% を上回らないようにすることをお勧めします。これは、ベスト エフォート サービスがより高い遅延とよりゆっくりとしたスループットに遭遇し始めるレベルのアップストリーム使用率です。UGS サービスは、アップストリーム使用率に関係なく引き続き動作します。

特定のアップストリームで許可されるトラフィックの量を制限する場合は、UGS、RTPS、NRTPS、UGS-AD、またはベスト エフォート サービス フローに対して、グローバルなケーブル インターフェイスごとまたはアップストリーム コマンドごとにアドミッション制御を設定します。最も重要なパラメータは、exclusive-threshold-percent フィールドです。

cable [upstream upstream-number] admission-control us-bandwidth
scheduling-type UGS|AD-UGS|RTPS|NRTPS|BE minor minor-threshold-percent 
major major-threshold-percent exclusive exclusive-threshold-percent
[non-exclusive non-excl-threshold-percent]

次にパラメータを説明します。

• [upstream <upstream-number>]：コマンドをケーブル インターフェイスやグローバルに適用するのではなく、特定のアップストリームに適用する場合、このパラメータを指定します。

• <UGS|AD-UGS|RTPS|NRTPS|BE>：このパラメータは、アドミッション制御を適用するサービス フローのスケジューリング モードを指定します。

• <minor-threshold-percent>：このパラメータは、マイナー アラームがネットワーク管理ステーションに送信される設定済みのスケジューリング タイプによってアップストリーム使用率のパーセンテージを示します。

• <major-threshold-percent>：このパラメータは、メジャー アラームがネットワーク管理ステーションに送信される設定済みのスケジューリング タイプによってアップストリーム使用率のパーセンテージを指定します。この値は <minor-threshold-percent> パラメータに設定する値よりも高くする必要があります。

• <exclusive-threshold-percent>：このパラメータは、指定された scheduling-type に排他的に予約されたアップストリーム使用率のパーセンテージを表します。<non-excl-threshold-percent> の値を指定しない場合、この値はこのタイプのサービス フローの使用率に対する最大の制限を表します。この値は <major-threshold-percent> 値よりも大きくする必要があります。

• <non-excl-threshold-percent>：このパラメータは、別のスケジューリング タイプがまた使用していない限り、このスケジューリング タイプが利用できる <exclusive-threshold-percent> よりも上のアップストリーム使用率のパーセンテージを表します。

たとえば、UGS サービス フローを利用可能なアップストリーム帯域幅合計の 60% に限定すると仮定します。また、UGS サービス フローによるアップストリーム使用率のパーセンテージが 40% を超えるとネットワーク管理ステーションが通知されると仮定すると、マイナー アラームは 50% を超えて送信する必要があり、メジャー アラームを送信する必要があります。次のコマンドを実行します。

cable admission-control us-bandwidth scheduling-type UGS minor 40 major 50 exclusive 60

フラグメンテーションを使用したベスト エフォート トラフィックのスケジューリング

DOCSIS 準拠スケジューラは、事前に割り当てられた UGS 認可や RTPS 認可の周りにベスト エフォート トラフィックを単にスケジュールします。このセクションの図で、この動作を具体的に示します。

図 10：保留中のベスト エフォート認可のスケジューリング

図 10 は、アップストリームに同じ認可サイズと認可間隔が事前にスケジュールされた 3 つの UGS サービス フローがあることを示しています。アップストリームは、3 つの異なるサービス フロー A、B、および C の代わりに帯域幅要求を受信します。サービス フロー A は中程度の長さの送信時間を、サービス フロー B は短めの送信時間を、サービス フロー C は長めの送信時間を要求します。

ベスト エフォート サービス フローそれぞれに同じ優先度を与えます。また、CMTSがこれらの各認可に対する帯域幅要求をA、B、Cの順で受信すると仮定します。CMTSは、最初に同じ順序で認可に送信時間を割り当てます。図 11 に、DOCSIS 準拠スケジューラが認可を割り当てる方法を示します。

図 11：固定 USG サービス フローの認可を中心としてスケジュールされたベスト エフォート認可

スケジューラは、UGS 認可の最初の 2 つのブロックの間のギャップで A および B のためにまとめて認可を押し込むことができます。ただし、C の認可は利用可能なギャップよりも大きいものです。したがって、DOCSIS準拠スケジューラは、UGS認可の3番目のブロックの周りのCの認可をC1とC2という2つの小さな認可にフラグメント化します。フラグメンテーションは、UGS認可の遅延を防止し、ベストエフォートトラフィックで発生するジッタののの影響を防止します。

フラグメンテーションは、データ送信に関連付けられた DOCSIS プロトコル オーバーヘッドを少しだけ増やします。余分なフラグメントがそれぞれ送信されると、DOCSIS ヘッダーの余分なセットも送信される必要があります。ただし、フラグメンテーションがないと、スケジューラは固定の UGS 認可との間にベスト エフォートの認可を効率的にインターリーブすることができません。フラグメンテーションは、DOCSIS 1.0 モードで動作するケーブル モデムに対しては発生できません。

優先順位

DOCSIS 準拠スケジューラは、認可が属しているサービス フローの優先度を基準にして割り当てを待っている認可をキューに配置します。DOCSIS の優先度は 8 つあり、0 が最低で、7 が最高です。これらの優先度は、それぞれに関連付けられたキューがあります。

DOCSIS 準拠スケジューラは、異なる優先度の認可が送信時間にいつ割り当てられるかを判断するために、厳格な優先度キューイング メカニズムを使用します。いいかえると、高優先度キューに格納されたすべての認可は、低い優先度のキューにある認可よりも前にサービスを受ける必要があります。

たとえば、DOCSIS準拠スケジューラがA、B、C、D、E、Fの順序で短時間で5つの認可を受信するとします。スケジューラは、認可のサービスフローの優先順位に対応するキューに各認可をキューイングします。

図 12：さまざまな優先度の認可

DOCSIS準拠スケジューラは、図12には、パターン化されたブロックとして表示される事前にスケジュールされたUGS認可の周りにベストエフォート認可をスケジュールします。DOCSIS準拠スケジューラが行う最初のアクションは、最も高高い優先キューです。この場合、優先度 7 のキューには、スケジュールを準備できる認可があります。スケジューラは先に進み、認可BとEの送信時間を割り当てます。認可Eは、事前に割り当てられたUGS認可のタイミングと干渉しないように、フラグメンテーションが必要であることに注意してください。

図 13：優先度 7 の認可のスケジューリング

スケジューラは、すべての優先度 7 の認可が送信時間を受信することを確認します。次に、スケジューラは優先度 6 のキューをチェックします。この場合、優先度 6 のキューは空なので、スケジューラは、認可 C を含む優先度 5 のキューに移行します。

図 14：優先度 5 の認可のスケジューリング

次に、スケジューラは、すべてのキューが空になるまで、より低い優先度のキューに移動して同じ形式で処理を進めていきます。スケジュールが必要な認可が多数ある場合、新しい帯域幅要求は CMTS に到達でき、その後で DOCSIS 準拠スケジューラが保留中の認可すべてへの送信時間の割り当てを終了します。例では、この時点で CMTS が優先度 6 の帯域幅要求 G を受信すると仮定します。

図 15：優先度 6 の認可がキューイングされる

認可 A、F、D が新しくキューイングされた認可 G よりも長く待機しているにもかかわらず、DOCSIS 準拠スケジューラは、G がより高い優先度であるため、G への送信時間を次に割り当てる必要があります。これは、DOCSIS 準拠スケジューラの次の帯域幅割り当てが、G、A、D の順になることを意味します（図 16 を参照）。

図 16：優先度 6 および優先度 2 の認可のスケジューリング

より高い優先度の認可が途中でキューイング システムには入らないと仮定すると、スケジュールされる予定の次の認可は F です。

DOCSIS 準拠スケジューラには、例で記述されていない 2 つ以上のキューがあります。最初のキューは、ケーブル モデムをオンラインのままにするために、定期的ステーション メンテナンス キープアライブ トラフィックをスケジュールするために使用するキューです。このキューは、CMTS 定期キープアライブ トラフィックを送信するために、ケーブル モデムに対する機会をスケジュールするために使用されます。DOCSIS 準拠スケジュールがアクティブになると、このキューは他のすべてのキューよりも前に最初に提供されます。2 番目は、指定された最小の予約レート（CIR）でサービス フローに割り当てられる認可に対するキューです。スケジューラは、認定レートを伴うサービス フローが必要な最小スループットを確実に受信するように、優先度 8 のキューとしてこの CIR キューを扱います。

フラグメント化不能 DOCSIS 1.0 認可

前のセクションの例から、ジッタが事前に割り当てられた UGS 認可で誘導されないことを確実にするために、認可は、複数の部分にフラグメント化する必要があることがあります。これは、UGS トラフィックの重要な部分でアップストリーム セグメントに DOCSIS 1.0 モードで動作するケーブル モデムの問題になることがあります。その理由は、DOCSIS 1.0 ケーブル モデムが次の利用可能な送信機会に収まるには大きすぎるフレームに送信することを依頼できるためです。

ここに次の例があります。スケジューラはその順序で新しい認可 A および B を受信すると仮定します。また、両方の認可が同じ優先度を持っているものの、認可 B が DOCSIS 1.0 モードで動作するケーブル モデム用であると仮定します。

図 17：保留中の DOCSIS 1.1 および DOCSIS 1.0 認可

スケジューラは、認可 A に最初に時間を割り当てようとします。次に、スケジューラは次の使用可能な伝送チャンスを認可Bに割り当てようとします。ただし、認可BがAとUGS認可の次のブロックの間でフラグメント化されずに残る余地はありません(図18を)。

図 18：延期された DOCSIS 1.0 認可 B

この理由で、認可 B が収まる余裕がある UGS 認可の 2 番目のブロックの後まで、認可 B が遅延されます。UGS 認可の 2 番目のブロックの前に未使用の領域ができたことに注目してください。ケーブル モデムは、今回は、CMTS に帯域幅要求を送信する時間を使用しますが、これは、帯域幅の非効率的な使用を表します。

この例を再考します。スケジューラに別の 2 つの UGS サービス フローを追加します。認可 A がフラグメント化できる一方で、認可 B は UGS 認可のブロック間に収まるには大きすぎるため、フラグメント化不能な認可 B をスケジュールする機会は存在しません。この状況によって、認可 B に関連付けられたケーブル モデムは、アップストリームで大きなフレームを送信できないままになります。

図 19：DOCSIS 1.0 認可 B をスケジュールできない

認可 B のための余地を作成するために、スケジューラに単にプッシュアウトを許可できたり、UGS 認可のブロックを少し遅延させることができますが、このアクションは、UGS サービス フローにジッタを引き起こします。当分の間、ジッタを最小限にすると仮定した場合、これは受け入れがたい解決策になります。

サイズが大きく、フラグメント化不能な DOCSIS 1.0 認可の問題を解決するために、DOCSIS 準拠スケジューラは、定期的にアップストリーム時間のブロックを、DOCSIS 1.0 ケーブル モデムが送信できる最も大きなフレームと同じだけの大きさになるよう事前にスケジュールします。スケジューラは、UGS サービス フローがスケジュールされる前にこれを行います。この時間は、通常、アップストリーム送信の約 2000 バイトと同等であり、「フラグメント化不能ブロック」または「UGS 空きブロック」とも呼ばれています。

DOCSIS 準拠スケジューラは、サイズの大きな DOCSIS 1.0 認可の機会が常に確実にスケジュールされるように、フラグメント化不能トラフィックに割り当てられる場合は UGS または RTPS 形式の認可を配置しません。このシステムで、フラグメント化不能 DOCSIS 1.0 トラフィック用の予約の時間は、アップストリームが同時にサポートできる UGS サービス フローの数を削減します。

図 20 は、フラグメント化不能ブロックを青い色で示し、同じ認可サイズと認可間隔の 4 つの UGS サービス フローを示しています。同じ認可サイズと認可間隔の別の UGS サービス フローをこのアップストリームに追加することはできません。その理由は、UGS 認可は、青色のフラグメント化不能ブロック領域にスケジュールすることが許可されていないためです。

図 20：フラグメント化不能ブロック：さらなる UGS 認可を許可できない

フラグメント化不能ブロックが UGS 認可の期間よりも少ない頻度でスケジュールされているとしても、このブロックは、UGS 認可のすべてのブロック間でそれ自体と同じ大きさの割り当てられていない帯域幅の領域を発生させる傾向にあります。これは、大きなフラグメント化されていない認可をスケジュールする十分な機会を提供します。

認可 A と DOCSIS 1.0 の認可 B の例に戻ると、フラグメント化不能ブロックを配置した状態で、DOCSIS 準拠スケジューラは、UGS 認可の最初のブロックの後で正常に認可 B をスケジュールできることがわかります。

図 21：フラグメント化不能ブロックを使用する認可のスケジューリング

DOCSIS 1.0 の認可 B は正常にスケジュールされているにもかかわらず、認可 A と UGS 認可の最初のブロックの間には未使用の領域の小さなギャップが引き続き存在します。このギャップは、帯域幅の次善の利用を表し、UGS サービスを展開するときに DOCSIS 1.1 モードのケーブル モデムを使用する必要がある理由を示します。

Cable default-phy-burst

Cisco uBR CMTS のデフォルトでは、ケーブル モデムが送信できる最大のバーストは 2000 バイトです。この値は最大のアップストリーム バースト サイズであり、DOCSIS 準拠スケジューラが使用するものとしてフラグメント化不能ブロックのサイズを計算するために使用されます。

最大バースト サイズを変更するには、cable default-phy-burst max-bytes-allowed-in-burst ケーブル単位インターフェイス コマンドを使用します。

<max-bytes-allowed-in-burst> パラメータの範囲は 0 ～ 4096 バイトで、デフォルト値は 2000 バイトです。デフォルト値を変更する場合、この値を設定する必要のある方法について、いくつかの重要な制限事項があります。

MC5x20S ラインカードのケーブル インターフェイスの場合、このパラメータをデフォルトの 2000 バイトより上には設定しないでください。MC28U、MC5x20U、MC5x20H などのラインカードを含め、他のすべてのラインカード タイプに対して、4000 バイトでこのパラメータを設定できます。

<max-bytes-allowed-in-burst> パラメータを、ケーブル モデムが DOCSIS や 802.1q オーバーヘッドなどを送信するために必要とする最大の単一イーサネット フレームのサイズよりも低くは設定しないでください。これは、この値を約 1540 バイトよりも低く設定してはならないことを意味しています。

<max-bytes-allowed-in-burst> を特殊な値 0 に設定した場合、CMTS はアップストリーム バーストのサイズを制限するためにはこのパラメータを使用しません。その場合、DOCSIS コンフィギュレーション ファイルまたは cable upstream fragment-force コマンドで、最大連結バースト設定などのアップストリーム バースト サイズを妥当な限度に制限するために、他の変数を設定する必要があります。

最大アップストリーム バースト サイズを変更するために cable default-phy-burst を変更すると、UGS 空きブロックのサイズもそれに従って変更されます。図 22 は、cable default-phy-burst 設定を低くした場合、UGS 空きブロックのサイズが減少し、それに従って DOCSIS 準拠スケジューラがアップストリームでより多くの UGS コールを許可できることを示しています。この例では、cable default-phy-burst をデフォルト設定の 2000 からより低い値の 1600 に設定し、1 つ以上の UGS サービス フローがアクティブになる余裕を生み出しています。

図 22：削減された Default-phy-burst がフラグメント化不能ブロック サイズを減らす

cable default-phy-burst コマンドによるバースト サイズの最大許容値の削減は、このコマンドにより 1 つのバースト内に連結できるフレームの数が減るため、ベスト エフォート トラフィックのアップストリームの効率を少し下げる可能性があります。また、この削減により、アップストリームでより多くの数の UGS サービス フローがアクティブになっているときに、フラグメンテーションの増大につながる可能性があります。

削減した連結バースト サイズは、ベスト エフォート サービス フローでアップロードしたデータの速度に影響を与える可能性があります。その理由は、複数のフレームの一度の送信が、各フレームに対する帯域幅要求の送信よりも速いためです。連結レベルを減らすことは、アップストリーム方向に運ばれる大量の TCP ACK パケットを連結するための減衰されたケーブル モデム能力のために、ダウンロードの速度に影響を与える可能性もあります。

ときには、アップストリームに適用される cable modulation-profile の「長い」IUC で設定される最大バースト サイズが、最大アップストリーム バースト サイズを決定する可能性があります。これは、変調プロファイル内の最大バースト サイズが cable default-phy-burst のバイト単位のサイズよりも少ないために発生することがあります。これは稀なシナリオです。ただし、cable default-phy-burst パラメータの値をデフォルトの 2000 バイトから増やした場合は、バーストを制限しないことを確認するために「長い」IUC の設定の最大バースト サイズを確認します。

アップストリーム バースト サイズのその他の制限事項は、最大の 255 ミニスロットが 1 回のバーストで送信できることです。ミニスロット サイズが最小の 8 バイトに設定された場合は、倍数になります。ミニスロットは、DOCSIS ネットワークにおけるアップストリーム送信の最も小さい単位であり、通常は 8 バイトまたは 16 バイトになります。

フラグメント化不能スロット ジッター

アップストリームでより多くの同時 UGS フローを許可するために、DOCSIS 準拠スケジューラを微調整するもう 1 つの方法は、スケジューラに対して、フラグメント化不能のベスト エフォート トラフィックの大量のバーストで少量のジッタを UGS サービス フローに導入できるようにすることです。これを行うには、cable upstream upstream-number unfrag-slot-jitter limit val ケーブル インターフェイス コマンドを使用します。

このコマンドで、<val> はマイクロ秒単位で指定され、デフォルトの値は 0 です。DOCSIS 準拠スケジューラのデフォルトの動作では、UGS および RTPS のサービス フローにジッタを引き起こす原因となるフラグメント化不能の認可を許可していません。正のフラグメント化不能スロット ジッタが指定されると、DOCSIS 準拠スケジューラは、UGS 認可が理想的にスケジュールされたときから最大 <val> マイクロ秒分 UGS 認可を遅延させることができ、それによってジッタが引き起こされます。

これは、指定されたマイクロ秒数と同じ長さだけ、フラグメント化不能ブロック サイズを削減するのと同じ効果を持ちます。たとえば、default-phy-burst（2000 バイト）のデフォルト値を維持する場合、また、フラグメント化不能スロット ジッターの値を 1000 マイクロ秒に指定する場合、フラグメント化不能ブロックは削減されます（図 23 を参照）。

図 23：ゼロではないフラグメント化不能スロット ジッターがフラグメント化不能ブロック サイズを減らす

注：1000マイクロ秒の時間が対応するバイト数は、アップストリームチャネルがチャネル幅と変調方式の設定を通じて動作するように設定される速度によって異なります。

注：ゼロ以外のフラグメント化不能スロットジッターを使用すると、DOCSIS準拠スケジューラは、アップストリームがサポートするUGS認可の数を、減少したdefault-phy-burstと同様に増やすことができます。

注：大きなDOCSIS 1.1認可Aに続いて、大きなフラグメント化不能なDOCSIS 1.0認可Bを使用して、アップストリームでスケジュールする例に戻ります。フラグメント化不能スロット ジッタを 1000 マイクロ秒に設定します。DOCSIS 準拠スケジューラは、このセクションの図に示すように動作します。

注：最初に、スケジューラは認可Aの送信時間を割り当てます。これを行うために、スケジューラは認可を認可A ₁とA ₂にフラグメント化し、UGS認可の最初のブロックの前後に収まるようにします。認可 B をスケジュールするために、スケジューラは、設定した 1000 マイクロ秒のフラグメント化不能スロット ジッターよりも大きくなり、UGS 認可の次のブロックへの遅延がないように、認可 A_{2 の後の空き領域にフラグメント化不能ブロックを収めることができるかどうかを判断する必要があります。}次の図は、スケジューラが認可 A₂ の次に認可 B を配置した場合、1500 マイクロ秒を越え、UGS トラフィックの次のブロックが遅延するか、プッシュバックされることを示しています。そのため、スケジューラは、認可 A₂ の直後には認可 B を配置できません。

図 24：認可 B は認可 A2 の次にはスケジュールできない

DOCSIS 準拠スケジューラの次のステップは、次に使用可能なギャップが認可 B に適合するかどうかを確認することです。図 25 は、UGS 認可の 2 番目のブロックの後に認可 B を配置する場合は、3 番目のブロックが、設定された 1000 マイクロ秒のフラグメント化不能スロット ジッターより遅れないことを示しています。

図 25：認可 B は UGS 認可の 2 番目のブロックの後にスケジュールされる

この位置に認可 B を挿入すると、UGS 認可で受け入れ不能なジッタが発生しないと認識されると、DOCSIS 準拠スケジューラは、認可 B を挿入し、UGS 認可の後に続くブロックで少しだけ遅延を発生させます。

図 26：フラグメント化不能の認可 B がスケジュールされ、UGS 認可で遅延が発生する

Show コマンドの出力

show interface cable interface-number mac-scheduler upstream-number コマンドを使用して、DOCSIS 準拠スケジューラの現在のステータスを評価できます。ここでは、MC28U ラインカード付きの Cisco uBR7200VXR で見られる、このコマンドの出力例を示します。

uBR7200VXR# show interface cable 3/0 mac-scheduler 0
     DOCSIS 1.1 MAC scheduler for Cable3/0/U0
     Queue[Rng Polls] 0/128, 0 drops, max 1
     Queue[CIR Grants] 0/64, 0 drops, max 0
     Queue[BE(7) Grants] 1/64, 0 drops, max 2
     Queue[BE(6) Grants] 0/64, 0 drops, max 0
     Queue[BE(5) Grants] 0/64, 0 drops, max 0
     Queue[BE(4) Grants] 0/64, 0 drops, max 0
     Queue[BE(3) Grants] 0/64, 0 drops, max 0
     Queue[BE(2) Grants] 0/64, 0 drops, max 0
     Queue[BE(1) Grants] 0/64, 0 drops, max 0
     Queue[BE(0) Grants] 1/64, 0 drops, max 1
     Req Slots 36356057, Req/Data Slots 185165
     Init Mtn Slots 514263, Stn Mtn Slots 314793
     Short Grant Slots 12256, Long Grant Slots 4691
     ATDMA Short Grant Slots 0, ATDMA Long Grant Slots 0
     ATDMA UGS Grant Slots 0
     Awacs Slots 277629
     Fragmentation count 41
     Fragmentation test disabled
     Avg upstream channel utilization : 26%
     Avg percent contention slots : 73%
     Avg percent initial ranging slots : 2%
     Avg percent minislots lost on late MAPs : 0%
     Sched Table Rsv-state: Grants 0, Reqpolls 0
     Sched Table Adm-State: Grants 6, Reqpolls 0, Util 27%
     UGS    : 6 SIDs, Reservation-level in bps 556800
     UGS-AD : 0 SIDs, Reservation-level in bps 0
     RTPS   : 0 SIDs, Reservation-level in bps 0
     NRTPS  : 0 SIDs, Reservation-level in bps 0
     BE     : 35 SIDs, Reservation-level in bps 0
     RTPS   : 0 SIDs, Reservation-level in bps 0
     NRTPS  : 0 SIDs, Reservation-level in bps 0
     BE     : 0 SIDs, Reservation-level in bps 0

このセクションでは、このコマンドの出力の各行について説明します。このセクションでは、読者が一般的な DOCSIS アップストリーム スケジューリングの概念にすでに精通していることを前提としています。

• DOCSIS 1.1 MAC scheduler for Cable3/0/U0

  コマンド出力の最初の行は、データに関連するアップストリーム ポートを示しています。

• Queue[Rng Polls] 0/128, 0 drops, max 1

  この行は、ステーション メンテナンス キープアライブまたは DOCSIS 準拠スケジューラへのレンジング機会に供給するキューの状態を示しています。0/128 は、キュー内の最大 128 個の保留中のレンジング機会のうち現在 0 個があることを示しています。

  ドロップ（drops）カウンタは、レンジング機会の回数がこれ以上キューイングされないことを示しており、これは、このキューがすでにいっぱいであった（つまり、保留中レンジング機会が 128 個）ためです。 ここでのドロップは、非常にたくさんの数のケーブル モデムがオンラインであるアップストリーム上でだけ、またはたくさんの数の UGS または RTPS サービス フローがアクティブであった場合、発生する可能性があります。このキューは、DOCSIS 準拠スケジューラが稼働するときに最も高い優先度でサービスを提供します。そのため、このキュー内でのドロップはほとんど起こりませんが、アップストリーム チャネルの深刻なオーバーサブスクリプションを示す可能性が高くなります。

  最大（max）カウンタは、show interface cable mac-scheduler コマンドが最後に実行されたときからこのキュー内にある要素の最大数を示します。これができるだけ 0 に近くなることが理想的です。

• Queue[CIR Grants] 0/64, 0 drops, max 0

  この行は、指定された最小予約トラフィック レートでサービス フローの認可を管理するキューの状態を示します。いいかえると、このキューは、Committed Information Rate（CIR; 認定情報レート）サービス フローの認可にサービスを提供します。0/64 は、キュー内の最大 64 個の保留中の認可のうち現在 0 個があることを示しています。

  ドロップ（drops）カウンタは、CIR 認可の回数がこれ以上キューイングされないことを示しており、これは、このキューがすでにいっぱいであった（つまり、キュー内に認可が 64 個）ためです。 ドロップは、UGS、RTPS、CIR 形式のサービス フローがアップストリームをオーバーサブスクライブした場合にここに累積する可能性があり、より厳密なアドミッション制御が必要であると示す可能性があります。

  最大（max）カウンタは、show interface cable mac-scheduler コマンドが最後に実行されたときからこのキュー内にある認可の最大数を示します。このキューには 2 番目に高い優先度が設定されているので、DOCSIS 準拠スケジューラは、スケジューラがベスト エフォート キューにサービスを提供する前にこのキューの要素に時間を割り当てます。

• Queue[BE(w) Grants] x/64, y drops, max z

  次の 8 つのエントリは、優先度 7 から 0 のサービス フローの認可を管理するキューの状態を示しています。これらのエントリのフィールドは CIR キュー エントリのフィールドと同じ意味を持ちます。このグループでサービスを受ける最初のキューは、BE (7) キューであり、最後にサービスを受けるキューは BE (0) キューです。

  ドロップは、より高い優先度レベルのトラフィックがアップストリーム帯域幅すべてを消費する場合、または UGS、RTPS、CIR 形式のサービス フローのあるアップストリームのオーバーサブスクリプションが発生する場合に、これらのキューで発生することがあります。これは、大量のサービス フローの DOCSIS 優先度を再評価する必要性、またはアップストリームにより厳密なアドミッション制御を行う必要性を示しています。

• Req Slots 36356057

  この行は、アップストリームがアクティブ化されてからアドバタイズされている帯域幅要求機会の数を示しています。この数は継続して増加する必要があります。

• Req/Data Slots 185165

  このフィールドがアップストリームでアドバタイズされた要求またはデータ機会の数を示すことをその名前が示唆しているにもかかわらず、実際には、このフィールドは、高度なスペクトル管理機能を促進するために CMTS がアドバタイズする期間の数を示しています。このカウンタは、MC28U および MC520 形式のラインカードでアップストリーム用に増分することが予想されています。

  要求/データ機会は、ケーブル モデムがこれらの期間にデータの小さなバーストも送信できること以外は、帯域幅要求機会と同じです。Cisco uBR シリーズ CMTS は、現在は実際の要求/データ機会をスケジュールしていません。

• Init Mtn Slots 514263

  この行は、アップストリームがアクティブ化されてからアドバタイズされている初期メンテナンス機会の数を表しています。この数は継続して上昇する必要があります。CMTS への接続を確立する初期試行を行うケーブル モデムは、初期メンテナンス機会を使用します。

• Stn Mtn Slots 314793

  この行は、ステーション メンテナンス キープアライブまたはアップストリームで提供されるレンジング機会の数を示しています。アップストリームにケーブル モデムがオンラインで存在する場合、この数は継続的に上昇する必要があります。

• Short Grant Slots 12256, Long Grant Slots 4691

  この行は、アップストリームで提供されるデータ認可の数を示しています。アップストリーム データを送信するケーブル モデムが存在する場合、これらの数は継続的に上昇する必要があります。

• ATDMA Short Grant Slots 0, ATDMA Long Grant Slots 0, ATDMA UGS Grant Slots 0

  この行は、アップストリームで Advanced Time Division Multiple Access（ATDMA）モードに提供されるデータ認可の数を表します。DOCSIS 2.0 モードで動作し、アップストリーム データを送信するケーブル モデムが存在する場合、これらの数は継続的に上昇する必要があります。ATDMA は個別に UGS トラフィックを説明しています。

• Awacs Slots 277629

  この行は、高度なスペクトル管理専用の期間数を表示します。高度なスペクトル管理が発生するためには、CMTS は、内部スペクトル分析機能が各ケーブル モデムからの信号品質を評価できるように、各ケーブル モデムが短い送信を作成する必要のある時間を定期的にスケジュールする必要があります。

• Fragmentation count 41

  この行は、アップストリーム ポートが受信するためにスケジュールされるフラグメントの合計数を示します。たとえば、3 つの部分にフラグメント化されたフレームは、このカウンタを 3 つ増分させます。

• Fragmentation test disabled

  この行は、test cable fragmentation コマンドが起動されていないことを示しています。このコマンドは本番ネットワークでは使用しないでください。

• Avg upstream channel utilization:26%

  この行は、アップストリーム送信による現在のアップストリーム チャネルの使用率を示しています。これは、ショート、ロング、ATDMA ショート、ATDMA ロング、ATDMA UGS 認可によって作成された送信を含んでいます。この値は、ローリング平均として毎秒計算されます。Cisco は、ピーク使用時間中の拡張基準に基づいて、この値が 75% を超えないようにすることを推奨します。それ以外の場合、エンド ユーザは、ベスト エフォート トラフィックでパフォーマンス問題の通知を開始できます。

• Avg percent contention slots:73%

  この行は、帯域幅要求専用のアップストリーム時間のパーセンテージを示します。これは、アップストリームの空き時間の量と同じであり、そのため、Avg upstream channel utilization のパーセンテージが増えると減ります。

• Avg percent initial ranging slots:2%

  この行は、ケーブル モデムが CMTS との初期接続を確立しようとするときに使用する初期レンジング機会専用に使用されるアップストリーム時間のパーセンテージを示します。この値は、常に合計使用率の低いパーセンテージのままである必要があります。

• Avg percent minislots lost on late MAPs:0%

  この行は、CMTS が帯域幅割り当て MAP メッセージを時間内にケーブル モデムに送信できなかったため、スケジュールされていなかったアップストリーム時間のパーセンテージを示しています。このパラメータは、常に 0 に近い値にする必要がありますが、過剰に高い CPU 負荷のあるシステムではより大きな値で始まる可能性があります。

• Sched Table Rsv-state:Grants 0, Reqpolls 0

  この行は、DOCSIS 準拠スケジューラ内でサービス フローに対して事前に割り当てられた認可を持っているものの、まだアクティブ化されていない UGS 形式のサービス フロー（Grants）または RTPS 形式のサービス フロー（Reqpolls）の数を示しています。これは、既存の UGS または RTPS サービス フローのあるケーブル モデムを、あるアップストリームから別のアップストリームへ、ロード バランシングによって移動するときに発生します。この値は、DOCSIS 準拠スケジューラを使用する認可に対してのみ当てはまり、LLQ スケジューラを使用するものには当てはまらないことに注目してください。

• Sched Table Adm-State:Grants 6, Reqpolls 0, Util 27%

  この行は、このアップストリームに対して DOCSIS 準拠スケジューラ内でサービス フローに対して事前に割り当てられた認可を持っている、UGS 形式のサービス フロー（Grants）または RTPS 形式のサービス フロー（Reqpolls）の数を示しています。Util は、これらのサービス フローによる利用可能な合計アップストリーム帯域幅の予想使用率です。この値は、DOCSIS 準拠スケジューラを使用する認可に対してのみ当てはまり、LLQ スケジューラを使用するものには当てはまらないことに注目してください。

• <Scheduling-type> :x SIDs, Reservation-level in bps y

  この行は、アップストリームに提示される <Scheduling-type> サービス フローまたは SID の数、およびこれらのサービス フローが予約されているビット/秒単位の帯域幅の量を示します。ベスト エフォートと RTPS 形式のサービス フローに対して、帯域幅は、サービス フローが設定されている最小の予約レートである場合にだけ予約されます。

DOCSIS 準拠スケジューラの長所と短所

DOCSIS 準拠スケジューラの目標は、UGS および RTPS 形式のサービス フローに対するジッタを最小化することであり、また、フラグメント化不能な DOCSIS 1.0 バーストに対応することです。DOCSIS 準拠スケジューラが、これらの目標を達成するために行うトレードオフは、アップストリームごとにサポートされる UGS サービス フローの最大数が、DOCSIS アップストリームが物理的にサポートでき、また、ベスト エフォート トラフィックがフラグメンテーションの程度に従うことのできる理論的な最大値よりも少ないことです。

DOCSIS 準拠スケジューラがアップストリーム上の同時 UGS サービス フローの理論的な最大数よりも少し少ない数をサポートし、また、他のいくつかのスケジューリング実装がアップストリームごとの UGS サービス フローよりも多くをサポートできる一方で、トレードオフには集中する必要があります。

たとえば、アップストリーム チャネルの 100% の帯域幅に近い値を消費し、同時に DOCSIS 1.0 モデムからのフラグメント不能な大量の連結フレームを同時にサポートする、ジッタのない UGS サービス フローをサポートできるスケジューラは存在しません。DOCSIS 準拠スケジューラの設計を考慮すれば、理解すべき重要な点が 2 つあります。

• 75% は、望ましい最大アップストリーム使用率です。

  Cisco は、UGS サービス フローによる使用率を含め、アップストリームが 75% の使用率を超えて動作すると、ベスト エフォート トラフィック パフォーマンスが著しく影響を受けることがわかりました。これは、UGS と VoIP のシグナリングが 75% より多くのアップストリームを消費している場合、ベスト エフォート サービス フローによって運ばれる通常の IP トラフィックが著しく低いスループットと応答時間を引き起こす付加遅延の影響を受け始めるということです。このより高い使用率レベルのパフォーマンスの低下は、イーサネットやワイヤレス LAN などの現在のほとんどのマルチアクセス ネットワーク システムが共有しているプロパティです。

• 3.2MHz の一般的に展開されたアップストリーム チャネルが使用された場合、DOCSIS 準拠スケジューラは、UGS サービス フローがアップストリーム チャネルの約 75% まで使用することを許可します。これらのサービス フローは G.711 VoIP コールを運びます。

これらの 2 つのポイントは、DOCSIS 準拠スケジューラが構築されたときの設計上の考慮事項の参考になります。DOCSIS 準拠スケジューラは、一般的な UGS サービス フロー（G.711）のためと、最も一般的に展開された 3.2MHz のチャネル幅で設計されており、アップストリーム制限ごとのコールは、75% の使用率マークで適用を開始します。これは、スケジューラがジッタを正常に最小化していることと、アップストリームに妥当な数の UGS サービス フローも許可していることを意味しています。

いいかえると、DOCSIS 準拠スケジューラは、実稼働 DOCSIS ネットワークで適切に動作するように設計されており、UGS サービス フローが非現実なほど高いアップストリーム帯域幅のパーセンテージを使用し尽くすことは許可しないように設計されています。このシナリオは、人為的な実験テスト シナリオで発生させることができます。

DOCSIS 準拠スケジューラを微調整すると、UGS ジッタとベスト エフォート トラフィック効率の損失にもかかわらず、アップストリームごとの UGS コールの増分する数に対応できます。このため、cable default-phy-burst パラメータを推奨最小設定の 1540 バイトに減らす必要があります。さらにコール密度が必要な場合は、cable upstream unfrag-slot-jitter を 2000 マイクロ秒などの値に設定します。ただし、Cisco は実稼働ネットワークにこのような設定を一般に行うことは推奨しません。

DOCSIS 準拠スケジューラの別のメリットは、CMTS オペレータが UGS や RTPS 形式のサービス フロー用にアドミッション制御を明示的に設定する強制的な要件が存在しないことです。これは、事前割り当てスケジュール方式によって、偶然のオーバーサブスクリプションの可能性が削減されるためです。これが当てはまる場合であっても、Cisco は、オペレータがアップストリーム使用率の合計がピーク時間の拡張期間に 75% を上回らないように注意するよう、引き続き提案します。そのため、Cisco はベスト プラクティスとしてアドミッション制御の設定を推奨します。

DOCSIS 準拠スケジューラの 1 つの障害は、UGS 認可の固定の位置は、UGS 使用率が高いときにベスト エフォートの認可のフラグメンテーションを要求できることです。一般に、フラグメンテーションは、著しいパフォーマンスの問題を発生させませんが、ベスト エフォート トラフィックへの遅延が少し上昇し、アップストリーム チャネルに提示されるプロトコル オーバーヘッドが増加します。

もう 1 つの障害は、DOCSIS 1.0 ケーブル モデムが大規模なフラグメント化不能なアップストリーム送信を作成する必要があるとき、事前にスケジュールされた UGS 認可のブロック間に適切なギャップが現れる前に遅延が存在する可能性があることです。また、これは、DOCSIS 1.0 アップストリーム トラフィックの遅延が増加することと、利用可能なアップストリーム送信時間が最適よりも下回って使用されることにもつながります。

最後に、DOCSIS 準拠スケジューラは、すべての UGS サービス フローが同一の認可サイズと認可間隔を共有する環境で最適に動作するように設計されます。つまり、すべての VoIP コールは、典型的な Packetcable 1.0 ベースのシステムで発生するような 10 ミリ秒または 20 ミリ秒のパケット化 G.711 など、同一のコーデックを共有します。まったく異なる認可間隔とサイズが提示されると、大量の UGS サービス フローをサポートする DOCSIS 準拠スケジューラの容量がアップストリームで減少します。さらに、スケジューラが異なる期間とサイズで UGS サービス フローをインターリーブしようとするときに非常に少ないジッタ（2 ミリ秒未満）がいくつかの認可で発生する可能性があります。

PacketCable MultiMedia（PCMM）ネットワークが広く普及し始めると、さまざまなパケット化間隔のあるさまざまな VoIP コーデックが同時操作に存在することがさらに一般的になる可能性があります。この種の環境は、それ自体が低遅延キューイング スケジューラに役立つ可能性があります。

低遅延キューイング スケジューラ

Low Latency Queueing（LLQ; 低遅延キューイング）スケジューラは、Cisco IOS ソフトウェア リリース 12.3(13a)BC で導入されました。LLQ は、Cisco uBR CMTS でアップストリーム サービスをスケジュールする代替方法です。このスケジューラは、アップストリームが同時にサポートでき、また、UGS サービス フローが存在するときにベスト エフォート トラフィックの効率を強化する UGS および RTPS 形式のサービス フローの数を最大化するように設計されました。トレードオフは、LLQ スケジューラが UGS および RTPS サービス フロー用のジッタを考慮した保証を行わないことです。

「DOCSIS 準拠スケジューラ」で説明したように、DOCSIS 準拠スケジューラは、UGS および RTPS 形式のサービス フローに対して事前に送信時間を割り当てます。これは、遅延 Time Division Multiplexing（TDM; 時分割多重）システムが、特定の遅延とジッタ レベルを保証するために帯域幅をサービスに割り当てる方式に似ています。

現在のパケット ベースのネットワークでは、低遅延キューイングは、高い優先度サービスに関連付けられたパケット、たとえば、音声やビデオなどが他のより低い優先度のパケットよりも前にネットワークに確実に配信できるようにルータが使用する方法です。また、これは、遅延とジッタが重要なトラフィック用に確実に最小化されるために現在のルータが使用する方法でもあります。

TDM ベースのシステムに対する「保証」という単語と LLQ ベースのシステムに対する「最小化する」という単語は、ジッタと遅延に関連して使用されます。ゼロ遅延とジッタの保証が望ましいことの一方で、そのトレードオフは、そのようなシステムが、通常は柔軟性がなく、再設定が難しく、ネットワーク状態の変更を簡単に適応することが一般にできないことです。

厳密な保証を提供することよりも、遅延とジッタを最小化するシステムは、ネットワーク状態の変更に直面すると、継続的にそれ自体を最適化するために柔軟性を発揮できます。低遅延キューイング スケジューラは、パケット/ルータ ベースの LLQ システムと類似した方式で動作します。UGS 認可に対し、事前に割り当てをスケジュールするシステムとは異なり、このシステムは、スケジュールされる必要のあるポイントで「できるだけすぐに」認可をスケジュールします。

UGS サービス フローに対して認可するアプローチはできるだけ早く割り当てる必要がありますが、完全な周期性を持つ必要はなく、このシステムは、増加した UGS 容量とより少ないベスト エフォート データ フラグメンテーションに対して厳密なジッタ保証のトレードオフになります。

コンフィギュレーション

Cisco IOS ソフトウェア リリース 12.3(13a)BC 以降では、LLQ スケジューラは 2 つの代替スケジューラ アルゴリズムの 1 つです。次のスケジューリング モードの 1 つ、すべて、またはいくつかに対して LLQ を有効にできます。

• UGS

• RTPS

• NRTPS

LLQ スケジューラはデフォルトでは有効にはされません。必要なアップストリーム スケジューリング タイプに対して LLQ スケジューラを明示的にオンにする必要があります。cable upstream upstream-port scheduling type [nrtps | rtps | ugs] mode llqケーブルインターフェイスコマンド。

一般に、これが希望するスケジューリング モードである場合、リストされているすべてのスケジューリング モードに対して LLQ スケジューラを有効にできます。次に示すのは、1 つのタイプのスケジューリング モードだけに LLQ スケジューリングを有効にし、他に対しては DOCSIS 準拠スケジューラを維持する状況の例です。

RTPS サービス フローには、ジッタ用の厳密な要件はありませんが、UGS サービス フローにはあります。この場合、RTPS サービス フローに LLQ スケジューラを有効にして、UGS に DOCSIS 準拠スケジューラを維持することができます。

LLQ スケジューラの動作

LLQ スケジューラは、他のすべてのキューよりも優先される特別な Low Latency Queue（LLQ; 低遅延キュー）に加えて、DOCSIS 準拠スケジューラの優先度キューイング機能と同じように動作します。

LLQ スケジューラは、アクティブなすべての UGS（および RTPS）形式のサービス フローの代わりにタイマーを開始します。タイマーは、すべての「認可間隔」がオフになるように設定されます。タイマーが時間切れになると、いつでも、UGS 認可が LLQ キューにキューイングされます。この認可が最高の優先度のある LLQ キューに配置されると、認可は、空き領域のある次の可能な瞬間にスケジュールされます。

このセクションの図では、同一の認可間隔のある 3 つのアクティブな UGS サービス フローのシステム例を示しています。図27は、UGS-1からUGS-3までのラベルの付いた左側のUGSサービスフローのタイマーを示しています。黄色の矢印は時計回りに移動します。黄色の針が赤の点に向かって上方に移動すると、UGS 認可が LLQ キューに追加されます。また、0 から 7 までの 8 つのおなじみの優先度キューと、これらすべてよりも優先される新しい LLQ キューがあります。最後に、右側にあるのは、認可がアップストリームでスケジュールされる方法を説明する帯域幅割り当てタイムラインです。追加した説明をわかりやすくするため、帯域幅割り当てタイムラインには、「現在の時間」ポインタが含まれます。このポインタは、例が進むにつれ、タイムラインに従って前に移動します。

図 27：低遅延キューイング システム

最初に発生するイベントは、左上にある UGS-1 タイマーが時間切れになることです。対応する認可は LLQ キューにキューイングされます。同時に、優先度 2 の A というベスト エフォートの認可がキューイングされます。

図 28：UGS-1 の認可と優先度 2 の認可 A がキューイングされる

LLQ スケジューラは、現在、優先度の順序で保留中の認可に送信時間を割り当てています。送信時間を受信する最初の認可は、LLQ キューで待機する UGS-1 の認可です。認可 A が続きます。

図 29：認可 UGS-1 および認可 A には送信時間が割り当てられる

次に発生するイベントは、UGS-2 タイマーが時間切れであり、UGS-2 サービス フローの認可が LLQ キューでキューングされるようになります。同時に、優先度 0 の認可 B がキューイングされ、優先度 6 の認可 C がキューイングされます。

図 30：UGS-2 タイマーが時間切れになり、認可 B と C がキューイングされる

LLQ スケジューラは、もう一度、優先度の順序に従って送信時間を割り当てます。ここでは、まず、UGS-2 認可、次に認可 C、最後に認可 B への順序で時間を割り当てます。

図 31：認可 UGS-2、C、および B は送信時間を割り当てられる

ベスト エフォートの認可が一時的にスケジューラに入らないと仮定します。UGS タイマーそれぞれはさらに 2、3 回時間切れになります。これで、スケジューラが UGS サービス フローに認可を割り当てる期間の種類を確認できます。これらは等間隔で現れます。認可が帯域幅割り当てタイムライン上で互いに関連してこのように表示されるときに、大きなジッタは発生しないと仮定します。

図 32：UGS-1、UGS-2、UGS-3 が多数の認可を受け取り、認可 D がキューイングされる

図 32 は、次の UGS-2 認可の理想的な位置を示しています。UGS-2 の認可がこの位置に配置された場合、UGS-2 のこの認可に対するジッタは発生しません。次の UGS-2 認可を LLQ キュー内にキューイングする時間がまだあることに注意してください。

図 32 は、非常に大きな優先度 0 の認可 D が優先度 0 のキューにちょうど入ったばかりであることも示しています。LLQ スケジューラが次に行うアクションは、認可 D の送信時間をスケジュールすることです。

図 33 はこのシナリオを表示しています。次の UGS-2 の認可がキューイングされる時点に少しだけ時計を進めます。

図 33：認可 D は送信時間を受け取り、UGS-2 の認可がキューイングされる

認可 D は、次の UGS-2 認可がゼロ ジッタ用にスケジュールされる必要があるときにスケジュールされるようです。ここで、問題になるのは、なぜ LLQ スケジューラは認可 D をその時点でスケジュールされるようにし、UGS-2 の認可の後まで認可 D を遅延しないのか、また、なぜ D がフラグメント化されないのかです。その答えは、LLQ スケジューラが UGS サービス フローの送信時間を事前に割り当てないからです。そのため、LLQ スケジューラは、UGS 認可が帯域幅割り当てタイムライン上に配置される場所を事前にはわかりません。LLQ スケジューラは、LLQ キューでキューイングされるまで、UGS 認可を認識しません。この例では、UGS-2 の認可がキューに入るときには、認可 D はすでにスケジュールされています。

LLQ スケジューラは、次の利用可能な機会で UGS-2 の認可をスケジュールしますが、この認可は理想的な位置からは少し遅れることになります。定義によると、この特定の認可でいくらかのジッタが発生したことになります。

図 34：UGS-2 の認可は遅延され、ジッターが発生する

DOCSIS 準拠スケジューラがこのジッタを回避できる一方で、LLQ スケジューラは、少量のジッタを犠牲にしただけで認可 D の遅延またはフラグメンテーションを回避します。VoIP エンドポイントのジッタ バッファは、このジッタを簡単に相殺できます。

複数のサービス フローの LLQ タイマーが同時に時間切れになり、UGS 認可が LLQ キュー内にキューイングされた他の UGS 認可の後ろで待機している場合にも、ジッタが発生する可能性があります。LLQ スケジューラは、この発生の可能性を最小にするために設計されてきました。スケジューラは、サービス フロー タイマーの有効期限を自動的に広げます。

DOCSIS 準拠スケジューラによると、LLQ スケジューラには、例で説明されていないさらに 2 つのキューがあります。次にキューを示します。

1. 最初のキューは、ケーブル モデムをオンラインに維持するために定期的なステーション メンテナンス キープアライブ トラフィックをスケジュールするために使用します。このキューは、LLQ キューのすぐ後にサービスされます。

2. 2 番目は、最小の予約レートを伴うサービス フロー（CIR サービス フロー）に割り当てられた認可のためのキューです。 この CIR キューは、認定レートを伴うサービス フローが必要な最小のスループットを確実に受信するために、「優先度 8」キューとして扱われます。

アドミッション制御

DOCSIS 準拠スケジューラとは異なり、LLQ スケジューラは UGS および RTPS サービス フローを伴うアップストリームの偶発的なオーバーサブスクリプションを停止する事前にスケジュールされるシステムを使用しません。このため、LLQ スケジューラを使用するアップストリームに対してアップストリーム アドミッション制御を明示的に設定する必要があります。この設定は、UGS サービス フローの合計アップストリーム帯域幅が制限を超過しないようにします。

一般に、Cisco はアップストリーム チャネルの使用率が、ピーク使用期間中に長期間 75% を超過することを許可しないように提案しています。たとえば、UGS トラフィックがアップストリーム帯域幅の 75% 以上を消費した場合、ベスト エフォート データは過剰な遅延とスループット パフォーマンスの問題にさらされ始めます。

CMTS オペレータがベスト エフォート トラフィックのマイナスの結果を受け付けられる場合、UGS サービス フローが利用可能なアップストリーム帯域幅の 75% よりも多く消費させることができます。ただし、アップストリーム チャネルでレイヤ 2 管理トラフィックへの影響も検討する必要もあります。初期およびステーション メンテナンス メッセージング（ケーブル モデム キープアライブ）の時間を考慮する必要があります。 これを考慮しない場合、また、UGS トラフィックが 100% に近い帯域幅を消費する場合、ケーブル モデムはオンラインになれないかオフラインになる可能性があります。

次に示すのはアドミッション制御の設定例です。この例は、アップストリームの利用可能な帯域幅の 50% に特定のアップストリームの UGS サービス フローを制限します。このコマンドの形式も、また、30% と 40% の使用率のマイナーとメジャーのしきい値に到達するときに、SNMP トラップを設定済みのネットワーク管理ステーションに送信します。コマンドは、次のとおりです。

cable upstream upstream-number admission-control us-bandwidth scheduling-type UGS minor 30 major 40 exclusive 50

アドミッション制御の設定方法について、このドキュメントの「DOCSIS 準拠スケジューラ」の「アドミッション制御」を参照してください。

Show コマンドの出力

LLQ スケジューラの現在のステータスを評価するには、show interface cable interface-number mac-scheduler upstream-number コマンドを発行します。

このコマンドの出力例を次に示します。DOCSIS 準拠スケジューラが動作しているときと異なる部分は太字で示します。

uBR7200VXR# show interface cable 5/0 mac-scheduler 0
     DOCSIS 1.1 MAC scheduler for Cable5/0/U0
     Queue[Rng Polls] 0/128, 0 drops, max 1
     Queue[CIR Grants] 0/64, 0 drops, max 2
     Queue[BE(7) Grants] 0/64, 0 drops, max 0
     Queue[BE(6) Grants] 0/64, 0 drops, max 0
     Queue[BE(5) Grants] 0/64, 0 drops, max 0
     Queue[BE(4) Grants] 0/64, 0 drops, max 0
     Queue[BE(3) Grants] 0/64, 0 drops, max 2
     Queue[BE(2) Grants] 0/64, 0 drops, max 0
     Queue[BE(1) Grants] 0/64, 0 drops, max 0
     Queue[BE(0) Grants] 0/64, 0 drops, max 5
     Queue[LLQ Grants] 0/64, 0 drops, max 3
     Req Slots 165488850, Req/Data Slots 871206
     Init Mtn Slots 1727283, Stn Mtn Slots 1478295
     Short Grant Slots 105668683, Long Grant Slots 52721
     ATDMA Short Grant Slots 0, ATDMA Long Grant Slots 0
     ATDMA UGS Grant Slots 0
     Awacs Slots 1303668
     Fragmentation count 11215
     Fragmentation test disabled
     Avg upstream channel utilization : 6%
     Avg percent contention slots : 91%
     Avg percent initial ranging slots : 3%
     Avg percent minislots lost on late MAPs : 0%
     Sched Table Rsv-state: Grants 0, Reqpolls 0
     Sched Table Adm-State: Grants 0, Reqpolls 0, Util 1%
     UGS    : 3 SIDs, Reservation-level in bps 278400
     UGS-AD : 0 SIDs, Reservation-level in bps 0
     RTPS   : 0 SIDs, Reservation-level in bps 0
     NRTPS  : 0 SIDs, Reservation-level in bps 0
     BE     : 14 SIDs, Reservation-level in bps 0
     r4k ticks in 1ms 600000
     Total scheduling events 5009
     No search was needed 5009
     Previous entry free 0
     Next entry free 0
     Could not schedule 0
     Recovery failed 0
Curr time 1341 entry 61
Entry 188, Bin 13
    SID: 416 IUC: 5, size_ms: 17 size_byte: 232 Frag: N Inval: 20
    type 8, perfect time ref 188, skew from ref 0, priority 10
    position 188, bin 13
Entry 188, Bin 14
    SID: 414 IUC: 5, size_ms: 17 size_byte: 232 Frag: N Inval: 20
    type 8, perfect time ref 188, skew from ref 0, priority 10
    position 188, bin 14
Entry 192, Bin 12
    SID: 415 IUC: 5, size_ms: 17 size_byte: 232 Frag: N Inval: 20
    type 8, perfect time ref 192, skew from ref 0, priority 10
    position 192, bin 12

この出力にある標準文字の行の説明については、DOCSIS 準拠スケジューラの「Show コマンドの出力」を参照してください。

show コマンドの出力の太字で示した行について説明します。

• Queue[LLQ Grants] 0/64, 0 drops, max 3

  この行は、cable upstream scheduling type [nrtps | rtps | ugs] mode llqコマンド。0/64 は、キュー内の最大 64 個の保留中の認可のうち現在 0 個があることを示しています。

  ドロップ（drops）カウンタは、このキューがすでにいっぱいであった（64 個の認可がキュー内にある）ため、UGS 認可または RTPS ポールをキューイングすることができなかったスケジューラの回数を示しています。 このキューでドロップが発生する場合、最も適切な説明として、アップストリームが UGS または RTPS のサービス フローでオーバーサブスクライブされており、より厳密なアドミッション制御を適用する必要があります。

  最大（max）カウンタは、show interface cable mac-scheduler コマンドが最後に実行されてからこのキュー内に存在する認可の最大数を示します。存在するときに、このキューにはリストされたすべてのキューの最も高い優先度があります。

• r4k ticks in 1ms 600000

  このフィールドは、認可が高い精度で LLQ キューに配置されるようにするために LLQ スケジューラが使用する内部タイミング変数を表します。

• Total scheduling events 5009

  この行は、show interface cable mac-scheduler コマンドがこのアップストリームで最後に実行されたときから、LLQ スケジューラが認可をキューイングしようとする回数を示します。このカウンタは、show コマンドが実行されるたびにリセットされます。

• No search was needed 5009

  LLQ スケジューラは、認可をキューイングした後、次回のキューイングを準備するためにサービス フロー タイマーをリセットしようとします。タイマーのリセットで問題がない場合、このカウンタは増分します。このカウンタは、理想的には Total scheduling events カウンタと同じ値を持つ必要があります。

• Previous entry free 0, Next entry free 0

  これらのカウンタはどちらも Cisco IOS ソフトウェアの現在のリリースで増分されます。これらのカウンタは常に 0 のままになります。

• Could not schedule 0, Recovery failed 0

  この行は、LLQ スケジューラが適切に設定されるサービス フローの認可タイマーの調整ができなかった回数を示します。これは、LLQ スケジューラが非常に短い認可間隔で極端に大きな認可を処理する場合にのみ発生する必要があります。これらのカウンタが実稼働ネットワークで増分されることはほとんどありません。これらのカウンタの増分は、UGS および RTPS サービス フローがアップストリームで物理的に利用可能な帯域幅を超えて消費することを示す可能性があります。その場合、適切なアドミッション制御コマンドを実行する必要があります。

• Curr time 1341 entry 61

  この行は、ミリ秒単位で計測された LLQ スケジューラの内部タイマーを示しています。この「entry」がサービス フロー統計における「Entry」フィールドと同じである場合、認可が LLQ キューにキューイングされています。

これらの統計は、LLQ スケジューラが処理するサービス フローそれぞれで繰り返されます。この例では、そのようなサービス フローが 3 つあります。

• Entry 188, Bin 13

  「Entry」値が前述の「entry」フィールドと同じであると、このサービス フローのタイマーは時間切れになり、認可は LLQ キューに移動します。このフィールドは、サービス フローが認可をキューイングするたびにリセットされます。

• SID:416

  LLQ スケジューラがスケジュールする認可のサービス フロー向けの Service Identifier（SID）です。

• IUC:5

  このサービス フローに属している認可の MAP メッセージ内でアドバタイズされる間隔用法コードです。UGS 形式のサービス フローが使用中であるとき、通常「Short data」に対しては 5、「Long Data」に対しては 6、「Advanced PHY UGS」に対しては 11 です。RTPS 形式のサービス フローの場合、この値は「Request」に対して常に 1 です。

• size_ms:17 size_byte:232

  ミニスロット単位の認可のサイズであり、その後ろにバイト単位の認可のサイズが続きます。ミニスロットは、DOCSIS ネットワークにおけるアップストリーム送信の最も小さい単位であり、通常は 8 バイトまたは 16 バイトになります。

• Frag:N

  認可がフラグメント化可能かどうかを示します。現在この値はいつも N に設定されています。

• Inval:20

  ミリ秒単位の認可またはポーリング間隔です。

• type 8

  8 は、このサービス フローが UGS であることを示し、10 は RTPS を示し、11 は NRTPS を示します。

• perfect time ref 188

  この認可がスケジュールされるにあたっての理想な時間です。これは、通常は先頭にある「Entry」と同じです。違う場合は、より厳密なアドミッション制御を必要とする非常に輻輳したアップストリームが示されます。

• skew from ref 0

  この認可がスケジュールされた時間と、この認可がスケジュールされるにあたっての理想の時間の差です。これは、「Entry」と「perfect time ref」の差です。そのため、この値は通常は 0 になる必要があります。

• priority 10

  Cisco IOS ソフトウェアの現在のリリースでは、この値は常に 10 に設定されますが、将来は変わる可能性があります。

• position 188, bin 13

  これらのフィールドは、このリストの最初にある「Entry, Bin」と同じである必要があります。

LLQ スケジューラの長所と短所

LLQ スケジューラの目標は、アップストリーム チャネルの UGS と RTPS の容量を増やすことと、ベスト エフォート トラフィックの効率を上げることです。LLQ スケジューラがこれらの目標を達成するために行うトレードオフは、このスケジューラが UGS および RTPS サービス フロー ジッタに保証を明示的に提供しないことです。それよりも、LLQ スケジューラは、ジッタを最小化するためにできるだけ表示付きで理想的な時間に近くするように UGS 認可と RTPS ポールをスケジュールします。

また、LLQ スケジューラは、OCSIS 準拠スケジューラよりも、異なる認可間隔と認可サイズの複数の UGS サービス フローをよりよく処理することもできます。この機能は、異なるタイプの VoIP コールが存在する PCMM 環境で役に立つ可能性があり、また、他のアプリケーションは、1 つのアップストリーム チャネルですべて同時にサービスを提供される可能性があります。

LLQ スケジューラは認可のフラグメンテーションの可能性を削減するので、LLQ スケジューラはより効率的にベスト エフォート トラフィックをスケジュールします。フラグメント化不能な DOCSIS 1.0 バーストがスケジュールされると、LLQ スケジューラは DOCSIS 準拠スケジューラがときおり行うような UGS 認可または RTPS ポールの前に未使用の帯域幅ギャップの作成は行いません。これは利用可能なアップストリーム時間のより良い使用法につながります。

典型的な DOCSIS または PacketCable ベースのネットワークにおいては、LLQ スケジューラを使用するときよりも DOCSIS 準拠スケジューラを使用するときの方が、UGS ジッタが一般に高いのですが、LLQ スケジューラのジッタ レベルは十分に VoIP エンドポイント ジッタ バッファ テクノロジーの容量内にあります。これは、適切に設計された VoIP ネットワーク内で LLQ スケジューラを使用するときに、VoIP コール品質への著しい影響は存在しないことを示しています。

大規模なアップストリーム バーストから発生するジッタには制限を設けることができます。このため、cable default-phy-burst パラメータは、デフォルト値の 2000 バイトかそれ以下に必ず維持する必要があります。システムが特別に低速なアップストリーム チャネルを使用する場合、たとえば、800 kHz やそれよりも低いチャネル幅である場合、大規模バーストを cable upstream fragment-force コマンドによって小さいバーストに強制的にフラグメント化すると、更なる削減を達成できます。

LLQ スケジューラが使用中であるとき、アップストリーム チャネルのオーバーサブスクリプションの可能性を防止するために、ケーブル アドミッション制御を設定する必要があります。アップストリームよりもアクティブな UGS サービス フローは、物理的に処理でき、アップストリーム上のすべての UGS サービス フローにわたって貧弱な音声品質をもたらします。極端な場合では、これも、ケーブル モデムがオフラインになり、新しいケーブル モデムがオンラインになれないことも意味します。Cisco は、アップストリーム ポート上の合計アップストリーム使用率が長期間 75% を上回らないなど、CMTS オペレータがアドミッション制御を設定することを推奨します。

まとめ

DOCSIS CMTS 製品の Cisco uBR シリーズは、2 つの代替アップストリーム スケジューリング アルゴリズムを提供するので、さまざまなネットワーク条件に応じることができます。

DOCSIS 準拠スケジューラは低ジッタ用に最適化されているものであり、一定の VoIP コーデックが適切に配置され、UGS サービス フローによってアップストリーム チャネル使用率の標準レベルが望まれる場所で典型的な Packetcable 1.x 音声システムに最も適しています。

低遅延キューイング スケジューラは、UGS サービス フローによるアップストリーム使用率の通常よりも高いレベル、増分されるベスト エフォート トラフィック効率、およびさまざまな認可間隔と認可サイズを備えた UGS および RTPS サービス フローを使用するシステムをサポートするために設計されています。

付録 A:ミニスロット

ミニスロットは、DOCSIS アップストリーム内で最小の伝送単位です。ケーブル モデムが CMTS にアップストリーム伝送時間を問い合わせるための帯域幅要求を送信するときは、バイト単位やミリ秒単位ではなく、ミニスロット単位で問い合わせます。加えて、帯域幅割り当て MAP メッセージでモデムに送信可能な時期と期間を通知する場合は、そのメッセージにミニスロット単位の情報が含まれます。

モデムが1回のバーストで送信を要求できるミニスロットの最大数は255です。ミニスロットサイズは、DOCSISチックと呼ばれる単位で指定されます。1 DOCSIS ティックは時間の 6.25 マイクロ秒に相当します。

アップストリーム ポートのミニスロット サイズをティック単位で設定するには、cable upstream <upstream-number> minislot-size [1 | 2 | 4 | 8 | 16 | 32 | 64 | 128]ケーブルインターフェースコマンドを使用します。

特定のミニスロット サイズでのみ、特定のアップストリーム チャネル幅が許可されます。次の表に、有効なミニスロット サイズと DOCSIS アップストリーム チャネル幅の対応と、設定が有効なミニスロットの変調方式シンボルの長さを示します。

注： Xマークは無効な組み合わせを示します。

	[無線帯域]	200 kHz	400 kHz	800 kHz	1.6 MHz	3.2 MHz	6.4 MHz
ティック単位のミニスロット サイズ
1		X	X	X	X	X	32
0		X	X	X	X	32	64
4		X	X	X	32	64	128
8		X	X	32	64	128	256
16		X	32	64	128	256	X
32		32	64	128	256	X	X
64		64	128	256	X	X	X
128		128	256	X	X	X	X

ミニスロット単位で送信されるバイト数を計算するには、設定された変調方式のシンボル単位のビット数にミニスロット単位の記号数を掛けます。次の表に示すように、変調方式が異なれば、送信される記号単位のビット数も異なります。

DOCSIS 1.1 TDMA 変調方式	シンボル単位のビット数
QPSK	0
16-QAM	4

DOCSIS 2.0 ATDMA 変調方式	シンボル単位のビット数
8-QAM	3
32-QAM	5
64-QAM	6

たとえば、チャネル幅が 1.6 MHz でミニスロット サイズが 4 ティックの場合は、最初の表を使用して、ミニスロット単位のシンボル数が 32 であることが分かります。2 つ目の表を使用してこの数字をバイトに変換します。これは、QPSK シンボルが 2 ビットで構成されるためです。この例の 1 ミニスロットは、ミニスロット単位の 32 シンボル * シンボル単位の 2 ビット = ミニスロット単位の 64 ビット = ミニスロット単位の 8 バイトと等価です。

ケーブルモデムが送信を要求できるミニスロットの最大数は255であることに注意してください。したがって、この例では、モデムが作成できる最大バーストは255ミニスロット* 8バイト/ミニスロット= 2040バイトです。

このバイト単位の数字は、前方誤り訂正後および物理層オーバーヘッド後の数字であることに注意してください。エラー訂正とその他の DOCSIS PHY 層オーバーヘッドによって、イーサネット フレームの長さがアップストリーム チャネルを通過時に 10 ～ 20％ 長くなります。正確な数字を導き出すには、アップストリーム ポートに適用される変調プロファイルを使用します。

この議論は重要です。なぜなら、前述したように、ケーブル モデムの最大バースト サイズの制限の 1 つが cable default-phy-burst コマンドで設定された値だからです。cable default-phy-burst コマンドがこの例のコンテキストで 4000 バイトに設定されている場合は、制限係数またはバースト サイズが cable default-phy-burst の値ではなく、255 のミニスロット制限（2040 バイト - オーバーヘッド）になります。

show controller cable interface-number upstream upstream-number コマンドで、アップストリームのミニスロット サイズの別の式を観察することができます。以下が一例です。

uBR7200VXR# show controller cable 5/0 upstream 0
 Cable5/0 Upstream 0 is up
  Frequency 20.600 MHz, Channel Width 1.600 MHz, QPSK Symbol Rate 1.280 Msps
  This upstream is mapped to physical port 0
  Spectrum Group 1, Last Frequency Hop Data Error: NO(0)
  MC28U CNR measurement : better than 40 dB
  US phy MER(SNR)_estimate for good packets - 36.1280 dB
  Nominal Input Power Level 0 dBmV, Tx Timing Offset 3100
  Ranging Backoff Start 3, Ranging Backoff End 6
  Ranging Insertion Interval automatic (60 ms)
  US throttling off
  Tx Backoff Start 3, Tx Backoff End 5
  Modulation Profile Group 41
  Concatenation is enabled
  Fragmentation is enabled
  part_id=0x3138, rev_id=0x03, rev2_id=0x00
  nb_agc_thr=0x0000, nb_agc_nom=0x0000
  Range Load Reg Size=0x58
  Request Load Reg Size=0x0E
  Minislot Size in number of Timebase Ticks is = 8
  Minislot Size in Symbols = 64
  Bandwidth Requests = 0x338C
  Piggyback Requests = 0x66D
  Invalid BW Requests= 0xD9
  Minislots Requested= 0x756C2
  Minislots Granted  = 0x4E09
  Minislot Size in Bytes = 16
  Map Advance (Dynamic) : 2482 usecs
  UCD Count = 8353

ミニスロットが 16 バイトまたは最も近い許容値に等しくなるようにミニスロット サイズを設定することをお勧めします。ミニスロット サイズが 16 バイトのケーブル モデムは、最大 255 * 16 = 4096 バイトの FEC 後バーストを生成できます。

付録 B：MAP アドバンス

CMTS は、定期的に、帯域幅割り当て MAP と呼ばれる特殊なメッセージを生成します。このメッセージは、ケーブル モデムにアップストリーム チャネル上で伝送を開始できる正確な時刻を通知します。MAP メッセージを伝送する電気信号は、限られた時間で、ハイブリッド ファイバ同軸（HFC）ネットワークを介して CMTS から接続先のすべてのケーブル モデムに物理的に伝播されます。そのため、MAP メッセージは、モデムで受信できるように早めに送信され、指定された時刻に CMTS に到達するようにアップストリーム伝送を開始できる必要があります。

MAP アドバンス時間と MAP ルックアヘッド時間は、CMTS が MAP メッセージを生成した時間と MAP から注文された最初の伝送が CMTS に到着しなければならない時間の差を表します。この時間は、DOCSIS システム内に存在する次の遅延の組み合わせを意味します。

• CMTS がソフトウェアで MAP メッセージを構築するまでの時間と、ダウンストリームの伝送回路でメッセージがキューイングされ、処理される時間。このコンポーネントの値は、プラットフォームやアーキテクチャによって異なり、そのほとんどが固定値です。

• ダウンストリーム インターリーブ機能によって追加される遅延。この遅延は前方誤り訂正の目的でインパルス ノイズから保護するために使用されます。この値を変更するには、ダウンストリーム インターリーバ パラメータを変更します。

• 電子信号が HFC ネットワークを介して CMTS からケーブル モデムに到達し、また戻ってくるまでの時間。DOCSIS では、CMTS とケーブル モデム間の最大片道遅延時間が 800 マイクロ秒に設定されています。この値は、ケーブル設備の物理的長さによって異なります。ダウンストリーム変調方式とアップストリーム チャネル幅および変調方式もこの値に影響します。

• ケーブル モデムで受信した MAP メッセージを処理して、アップストリーム伝送の準備ができるまでの時間。これは、DOCSIS 仕様のガイドラインに従って 200 マイクロ秒 + アップストリーム インターリーバ遅延以下にする必要があります。現実的には、この時間は、ケーブル モデムの型式、モデル、およびファームウェア リビジョンに応じて、100 マイクロ秒以上 300 マイクロ秒以下にすることができます。

図 35：MAP アドバンス時間の要素

MAP アドバンス時間はアップストリーム伝送の遅延に大きな影響を与える可能性があります。これは、この値が、CMTS がケーブル モデムでの伝送の開始を認識した時間と、そのモデムがその伝送の開始を許可された時間の最小遅延を表しているためです。したがって、アップストリーム遅延を削減するには MAP アドバンス時間を最小化します。

輻輳したアップストリームでは、他の要因もアップストリーム遅延に影響を及ぼすことに注意してください。たとえば、バックオフおよび再試行帯域幅要求アルゴリズムによる遅延や、連続する保留認可のキューイングなどが挙げられます。

図 36 は、CMTS が生成した MAP とアップストリームでの対応するデータの受信の関係を示しています。

図 36：MAP 生成とアップストリーム データの受信の関係

インターリーバ深度

MAP アドバンス時間が変化する最初の要因は、インパルス ノイズの保護に使用されるダウンストリーム インターリーバです。次の表に、さまざまなインターリーバ タップ設定とインターリーバ増分設定でダウンストリーム伝送に追加される遅延を示します。

注：タップのサイズが大きいほど、エラー訂正の強度は高くなりますが、遅延が発生します。

I（タップの数）	J（増分）	遅延 64-QAM	遅延 256-QAM
8	16	220 マイクロ秒	150 マイクロ秒
16	8	480 マイクロ秒	330 マイクロ秒
32	4	980 マイクロ秒	680 マイクロ秒
64	0	2000 マイクロ秒	1400 マイクロ秒
128	1	4000 マイクロ秒	2800 マイクロ秒
12（EuroDOCSIS）	17（EuroDOCSIS）	430 マイクロ秒	320 マイクロ秒

インターリーバ パラメータを設定するには、cable downstream interleave-depth [8 | 16 | 32 | 64 | 128]ケーブルインターフェイス設定コマンド

注：I（タップ数）の値が指定され、表に示すように、J（増分）に対応する固定値が自動的に適用されます。また、EuroDOCSIS(Annex A)モードの場合、インターリーバパラメータはI = 12およびJ = 17に固定されます。Iのデフォルト値は32で、Jのデフォルト値は4になります。

往復時間

MAP アドバンス時間を変化させる 2 つ目の要因は、CMTS とケーブル モデム間の電気的往復時間です。CMTS とケーブル モデム間の物理的な距離とケーブル モデムに固有の処理遅延がこの値に影響を与えます。

DOCSIS 仕様では、CMTS とシステム内で最も離れているケーブル モデム間の最大許容片道伝播時間を 800 マイクロ秒以下にするよう義務付けられています。これは、ケーブル モデムの処理遅延を除いて、約 1600 マイクロ秒の往復時間を意味します。

真空中の光の速度は約186,000マイル/秒（300,000キロメートル/秒）で、ファイバの伝播速度は通常0.67と見積もられます。したがって、CMTSとケーブルモデム間の最大許容一方向の距離は約です。

	Distance = Velocity * Time

       		 = (186,000 miles/sec * 0.67) * 800 microseconds

       		 = 100 miles or 161 kilometers.

DOCSIS 仕様に従って、ケーブル モデムの処理遅延は、200 ミリ秒 + アップストリーム インターリーブ遅延を超えないようにする必要があります。ただし、まれに、一部の古いブランドのケーブル モデムでは MAP メッセージの処理に 300 ミリ秒もかかる場合があります。より強力な CPU が搭載されたより新しいタイプのケーブル モデムでは MAP メッセージの処理に 100 マイクロ秒しかかかりません。

ケーブル モデムは、概して、DOCSIS 仕様に準拠しているものとします。したがって、最大往復時間は 1600 + 200 = 1800 ミリ秒にする必要があります。

大部分のケーブル システムは 100 マイルよりはるかに短いはずです。したがって、CMTS が、常に、最も遠いケーブル モデムとの間の電気的往復時間を最大値である 1800 マイクロ秒であると仮定するのは最適ではありません。

最大予想電気的往復時間の概算では、CMTS とケーブル モデム間の光ファイバの距離を加算して、16 マイクロ秒/マイル（10 マイクロ秒/km）を掛けます。 その後で、同軸の距離を加算して、その値に 12.4 マイクロ秒/マイル（7.6 マイクロ秒/km）を掛けます。 その後で、200 マイクロ秒の処理遅延を加算します。

たとえば、CMTS と最も遠いケーブル モデム間の、合計 20 マイルの光ファイバと 1 マイルの同軸からなる HFC セグメントの電気的往復遅延は次のように概算されます。

20 miles * 16 microseconds/mile + 1 mile * 12.4 microseconds/mile + 200 microseconds
 
= 320 microseconds + 12.4 microseconds + 200 microseconds

= 532.4 microseconds

この数字では、アップストリームとダウンストリームのチャネル特性やモデムの処理時間のばらつきによる追加の遅延が考慮されていません。そのため、この値を MAP アドバンス時間の計算に使用するのは適切ではありません。

システムのラウンドトリップ時間を正確に判断する方法としては、show cable modemコマンドの出力に示されているケーブルモデムの「タイミングオフセット」を確認します。ケーブルモデムがCMTSとの通信を維持するために使用するレンジング処理の一部として、CMTSががです。この往復時間は、タイミング オフセット単位または測距オフセット単位と呼ばれる 1/10.24MHz = 97.7 ナノ秒単位で show cable modem コマンドの出力に "Timing Offset" として表示されます。モデムのタイミング オフセットをマイクロ秒に変換するには、値に 25/256 を掛けるか、値を大ざっぱに 10 で割ります。

ここで、show cable modem コマンドの出力内のさまざまなモデムのタイミング オフセットがマイクロ秒値に変換される例を示します。

注：マイクロ秒の値は斜体で表示されます。

uBR7200VXR# show cable modem
MAC Address    IP Address   I/F       MAC         Prim RxPwr Timing  Num BPI
                                      State       Sid  (dB)  Offset  CPE Enb
00aa.bb99.0859 4.24.64.28   C5/1/U0   online(pt)  16   0.00  2027     0   Y  (198μs)
00aa.bb99.7459 4.24.64.11   C5/1/U0   online(pt)  17   1.00  3528     0   Y  (345μs)
00aa.bbf3.7258 4.24.64.31   C5/1/U0   online(pt)  18   0.00  2531     0   Y  (247μs)
00aa.bbf3.5658 4.24.64.39   C5/1/U0   online(pt)  19   0.00  6030     0   Y  (589μs)

この場合は、電気的に最も離れているモデムが、タイミング オフセットが 6030 の最後のモデムです。これは、6030 * 25/256 = 589 ミリ秒の往復時間に相当します。

スタティック MAP アドバンス

HFC ネットワークの長さが 100 マイルよりずっと短いことがわかっているシステムでは、MAP アドバンス時間を計算するときに標準の 1800 マイクロ秒より短い最大往復時間を使用するように CMTS を設定できます。

CMTS に MAP アドバンスの計算で往復時間のカスタム値を使用するように強制するには、cable map-advance static max-round-trip-time ケーブル インターフェイス コマンドを発行します。

max-round-trip-time の範囲は 100 ～ 2000 マイクロ秒です。max-round-trip-time の値が指定されなかった場合は、1800 マイクロ秒のデフォルトが適用されます。

注： staticキーワードをdynamicキーワードに置き換えることができます。次の項を参照してください。

指定された往復時間が、実際に、ダウンストリーム チャネル上の CMTS とケーブル モデム間の最大往復時間より長いことを確認します。ケーブル モデムの往復時間が max-round-trip-time で指定された往復時間より長い場合は、モデムがオンライン状態を維持するのは難しいと判断する可能性があります。これは、このようなモデムが MAP メッセージに応答する十分な時間がなく、CMTS と通信できないためです。

マイクロ秒に変換されたケーブル モデムの時間オフセットが指定された max-round-trip-time を超えると、そのモデムが不良タイミング オフセット フラグでマーキングされます。このオフセット フラグは、show cable modem コマンドの出力ではケーブル モデムのタイミング オフセットの隣の感嘆符（!）で表示されます。この現象は、max-round-trip-time パラメータが低すぎる場合またはケーブル モデムでタイミング オフセットが不安定になり、徐々に増えているという問題が発生している場合に起きる可能性があります。

以下が一例です。

uBR7200VXR# show cable modem
MAC Address    IP Address   I/F      MAC         Prim RxPwr  Timing  Num BPI
                                     State       Sid  (dB)   Offset  CPE Enb
00aa.bb99.0859 4.24.64.28   C5/1/U0  online(pt)  16   0.00  2027     0   Y  (198μs)
00aa.bb99.7459 4.24.64.11   C5/1/U0  online(pt)  17   1.00  3528     0   Y  (345μs)
00aa.bbf3.7258 4.24.64.31   C5/1/U0  online(pt)  18   0.00  2531     0   Y  (247μs)
00aa.bbf3.5658 4.24.64.39   C5/1/U0  online(pt)  19   0.00  !5120    0   Y  (500μs)

この例では、cable map-advance static 500 コマンドが指定されています。ただし、ケーブル インターフェイスに接続されたケーブル モデムのいずれかのタイミング オフセットは 500 マイクロ秒（500 * 256/25 = 5120 のタイミング オフセット単位と同等）を超えます。

最後のケーブル モデムのタイミング オフセットは不良タイミング オフセット フラグ（"!"）でマーキングされることに注意してください。これは、実際のタイミング オフセットが大幅に高くなる可能性がある場合でも、5120 単位の最大許容値に固定されます。このケーブル モデムは、オフラインになって、パフォーマンスが低下する可能性があります。

不良タイミング オフセット フラグは、タイミング オフセットが max-round-trip-time を下回った場合でもケーブル モデムに対してセットされたままです。このフラグをクリアする唯一の方法は、show cable modem リストからモデムを一時的に削除する方法です。このために、clear cable modem mac-address delete コマンドを使用できます。または、ケーブル インターフェイスまたはアップストリーム ポートをリセットできます。

アップストリームごとにスタティック MAP アドバンス アルゴリズムの動作を観察するには、show controller cable interface-number upstream upstream-number コマンドを発行します。以下が一例です。

uBR7200VXR# show controller cable 5/0 upstream 0
 Cable5/0 Upstream 0 is up
  Frequency 20.600 MHz, Channel Width 1.600 MHz, QPSK Symbol Rate 1.280 Msps
  This upstream is mapped to physical port 0
  Spectrum Group is overridden
  US phy MER(SNR)_estimate for good packets - 36.1280 dB
  Nominal Input Power Level 0 dBmV, Tx Timing Offset 2037
  Ranging Backoff automatic (Start 0, End 3)
  Ranging Insertion Interval automatic (60 ms)
  US throttling off
  Tx Backoff automatic (Start 0, End 3)
  Modulation Profile Group 43
  Concatenation is enabled
  Fragmentation is enabled
  part_id=0x3138, rev_id=0x03, rev2_id=0x00
  nb_agc_thr=0x0000, nb_agc_nom=0x0000
  Range Load Reg Size=0x58
  Request Load Reg Size=0x0E
  Minislot Size in number of Timebase Ticks is = 16
  Minislot Size in Symbols = 128
  Bandwidth Requests = 0x6ECEA
  Piggyback Requests = 0xDE79
  Invalid BW Requests= 0x63D
  Minislots Requested= 0x8DEE0E
  Minislots Granted  = 0x7CE03
  Minislot Size in Bytes = 32
  Map Advance (Static) : 3480 usecs
  UCD Count = 289392

Map Advance（Static）フィールドは 3480 マイクロ秒の MAP アドバンス時間を示しています。ダウンストリーム インターリーバの特性または max-round-trip-time パラメータを変更した場合は、その変更がスタティック MAP アドバンス値に反映されます。

Dynamic MAP Advance

スタティック MAP アドバンスの計算を使用して MAP アドバンス時間を最適化するには、CMTS オペレータがケーブル セグメントの最大往復時間を手動で決定する必要があります。ダウンストリームまたはアップストリーム チャネルの特性が変化した場合または工場出荷時の状態が変化した場合は、最大往復時間が大幅に変更される可能性があります。システム状態の変化に合わせて設定を継続的に更新することは困難です。

ダイナミック MAP アドバンス アルゴリズムがこの問題を解決します。ダイナミック MAP アドバンス アルゴリズムは、show cable modem リストを定期的にスキャンして、初期測距タイミング オフセットが最大のモデムを検索してから、自動的にその値を使用して MAP アドバンス時間を計算します。そのため、CMTS は常に最短の MAP アドバンス時間を使用することになります。

ケーブル モデムの初期測距タイミング オフセットは、モデムがオンラインになった時点で報告するタイミング オフセットです。ほとんどの場合、show cable modem コマンドの出力に表示される現在のタイミング オフセットに近い値になります。ただし、一部のタイプのケーブル モデムは、タイミング オフセットが徐々に上がって非常に大きな値になるという問題を抱えています。これは、MAP アドバンス時間の計算を狂わせる可能性があります。そのため、モデムがオンラインになったときにのみ更新される初期測距タイミング オフセットだけが使用されます。ケーブル モデムの初期測距タイミング オフセットと現在のタイミング オフセットを表示するには、show cable modem verbose コマンドを発行します。以下が一例です。

uBR7200VXR# show cable modem 00aa.bbf3.7858 verbose
MAC Address                         : 00aa.bbf3.7858
IP Address                          : 4.24.64.18
Prim Sid                            : 48
Interface                           : C5/1/U0
Upstream Power                      : 39.06 dBmV (SNR = 36.12 dB)
Downstream Power                    : 14.01 dBmV (SNR = 35.04 dB)
Timing Offset                       : 2566
Initial Timing Offset               : 2560
Received Power                      :  0.00 dBmV
MAC Version                         : DOC1.1
QoS Provisioned Mode                : DOC1.1
Enable DOCSIS2.0 Mode               : Y
Phy Operating Mode                  : tdma
Capabilities                        : {Frag=Y, Concat=Y, PHS=Y, Priv=BPI+}
Sid/Said Limit                      : {Max US Sids=16, Max DS Saids=15}
Optional Filtering Support          : {802.1P=N, 802.1Q=N}
Transmit Equalizer Support          : {Taps/Symbol= 1, Num of Taps= 8}
Number of CPE IPs                   : 0(Max CPE IPs = 16)
CFG Max-CPE                         : 32
Flaps                               : 4(Mar 13 21:13:50)
Errors                              : 0 CRCs, 0 HCSes
Stn Mtn Failures                    : 0 aborts, 1 exhausted
Total US Flows                      : 1(1 active)
Total DS Flows                      : 1(1 active)
Total US Data                       : 321 packets, 40199 bytes
Total US Throughput                 : 129 bits/sec, 0 packets/sec
Total DS Data                       : 28 packets, 2516 bytes
Total DS Throughput                 : 0 bits/sec, 0 packets/sec
Active Classifiers                  : 0 (Max = NO LIMIT)
DSA/DSX messages                    : permit all
Total Time Online                   : 1h00m

この例では、現在のタイミング オフセット（2566）が初期測距タイミング オフセット（2560）より少し高くなっています。 これらの値はわずかに異なる場合があります。ただし、これらの値が数百単位を超えて異なる場合は、ケーブル モデムのタイミング オフセット制御に問題がある可能性があります。

ダイナミック MAP アドバンスの計算をアクティブにするには、cable map-advance dynamic safety-factor max-round-trip-time ケーブル インターフェイス コマンドを発行します。

safety-factor パラメータの範囲は 100 ～ 2000 マイクロ秒です。このパラメータは、MAP アドバンス時間に加算することによって、信号伝播での予期せぬ余分な遅延からアカウントを保護することに若干役立ちます。デフォルト値は 1000 マイクロ秒です。ただし、ケーブル プラントあるいはアップストリームまたはダウンストリーム チャネルの特性が大きく変化しない安定したケーブル システムでは、500 マイクロ秒などのより低い値を使用します。

max-round-trip-time パラメータの範囲は 100 ～ 2000 マイクロ秒です。このパラメータは、ケーブル セグメントに接続されたケーブル モデムの時間オフセットに対する上限として使用されます。デフォルト値は 1800 マイクロ秒です。マイクロ秒に変換されたケーブル モデムの時間オフセットが指定された max-round-trip-time を超えると、そのモデムが不良タイミング オフセット フラグでマーキングされます。

ケーブル システムの長さが 100 マイルよりずっと短いことがわかっている場合またはセグメントに接続されたケーブル モデムの最大標準時間オフセットの適性値がわかっている場合は、max-round-trip time パラメータをデフォルト以外の値に設定します。

アップストリーム単位でダイナミック MAP アドバンス アルゴリズムの動作を観察するには、show controller cable interface-number upstream upstream-number コマンドを使用します。以下が一例です。

uBR7200VXR# show controller cable 5/0 upstream 0
 Cable5/0 Upstream 0 is up
  Frequency 20.600 MHz, Channel Width 1.600 MHz, QPSK Symbol Rate 1.280 Msps
  This upstream is mapped to physical port 0
  Spectrum Group 1, Last Frequency Hop Data Error: NO(0)
  MC28U CNR measurement : better than 40 dB
  US phy MER(SNR)_estimate for good packets - 36.1280 dB
  Nominal Input Power Level 0 dBmV, Tx Timing Offset 3100
  Ranging Backoff Start 3, Ranging Backoff End 6
  Ranging Insertion Interval automatic (60 ms)
  US throttling off
  Tx Backoff Start 3, Tx Backoff End 5
  Modulation Profile Group 41
  Concatenation is enabled
  Fragmentation is enabled
  part_id=0x3138, rev_id=0x03, rev2_id=0x00
  nb_agc_thr=0x0000, nb_agc_nom=0x0000
  Range Load Reg Size=0x58
  Request Load Reg Size=0x0E
  Minislot Size in number of Timebase Ticks is = 8
  Minislot Size in Symbols = 64
  Bandwidth Requests = 0x338C
  Piggyback Requests = 0x66D
  Invalid BW Requests= 0xD9
  Minislots Requested= 0x756C2
  Minislots Granted  = 0x4E09
  Minislot Size in Bytes = 16
  Map Advance (Dynamic) : 2482 usecs
  UCD Count = 8353

Tx Timing Offset 値は、タイミング オフセット単位でアップストリームに接続されたすべてのケーブル モデムの最大タイミング オフセットを表します。この値を使用して MAP アドバンス時間を計算します。Map Advance（Dynamic）フィールドは、結果の MAP アドバンス時間を表します。この値は、Tx Timing Offset が変化した場合、safety-value 値が変更された場合、またはダウンストリーム インターリーバの特性が変更された場合に変化する可能性があります。

ダイナミック MAP アドバンス アルゴリズムは、ケーブル モデムが CMTS に初期測距タイミング オフセットを正しく報告するかどうかによって異なります。残念ながら、一部のケーブル モデムの型式やモデルは、実際の値をはるかに下回る値として初期測距タイミング オフセットを報告します。この現象は、モデムが 0 または負の値に近いタイミング オフセットを示している場合に観察できます。

このようなケーブル モデムでは、%UBR7200-4-BADTXOFFSET:Bad timing offset -2 detected for cable modem 00ff.0bad.caf3 と同様のエラー メッセージが表示されます。このようなタイプのケーブル モデムは、DOCSIS に準拠した方法でタイミング オフセットを報告せず、ダイナミック MAP アドバンス アルゴリズムは、すべてのケーブル モデムが MAP メッセージを受け取るまたは MAP メッセージに応答するのに十分な時間となる MAP アドバンス時間を正しく計算できません。

このようなケーブル モデムがケーブル セグメント上に存在する場合は、ダイナミック MAP アドバンス アルゴリズムを無効にして、スタティック MAP アドバンス アルゴリズムに戻します。詳細については、「一部のケーブル モデムで負のタイム オフセットが表示される理由」参照してください。

関連情報

• テクニカル サポートとドキュメント – Cisco Systems

更新履歴