パケット音声ネットワークでのジッタについて（Cisco IOS プラットフォーム）
内容
概要
このドキュメントでは、ジッターについて解説し、ジッターを測定して補正する方法を説明します。
前提条件
要件
このドキュメントの読者は次のトピックについての専門知識を有している必要があります。
-
基本的な Cisco IOS® 音声設定
-
Quality of Service（QoS）の基礎知識
使用するコンポーネント
このドキュメントの情報は、Cisco IOS 音声ゲートウェイおよびルータに適用されます。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。対象のネットワークが実稼働中である場合には、どのようなコマンドについても、その潜在的な影響について確実に理解しておく必要があります。
表記法
ドキュメント表記の詳細は、「シスコ テクニカル ティップスの表記法」を参照してください。
パケット音声ネットワークのジッタ
ジッタは、受信されるパケットでの遅延の変動として定義されます。送信側では、パケットはパケット間隔が均一な連続ストリームとして送信されます。ネットワークの輻輳、不適切なキューイング、または設定エラーが原因で、この安定したストリームにむらが生じたり、各パケットの遅延が一定ではなく、ばらつきが生じたりすることがあります。
以下の図は、パケット ストリームが安定している場合の処理方法を示しています。
ルータが Voice over IP（VoIP）の Real-Time Protocol（RTP）音声ストリームを受信する際にジッタがある場合は、それを補正する必要があります。この機能は、再生遅延バッファというメカニズムで処理されます。プレイアウト遅延バッファは、これらのパケットをバッファしてから、デジタル シグナル プロセッサ（DSP）への安定したストリームで再生し、アナログ オーディオ ストリームに変換しなおす必要があります。再生遅延バッファは、デジッタ バッファとも呼ばれます。
以下の図に、ジッタの処理方法を示します。
ジッタが大きすぎるために受信するパケットがこのバッファの範囲外になる場合、範囲外のパケットが廃棄され、聞こえる音声にドロップアウトが発生します。損失が 1 つのパケット程度で少ない場合、DSP は予測した音声を挿入し、音声の問題は認識されません。ジッタが大きすぎて損失パケットを DSP で補正できない場合は、音声の問題が発生します。
以下の図に、過剰なジッタの処理方法を示します。
ジッタの重大度の判別
過剰なジッタの存在は、Cisco IOS で以下の手順に従うことで確認できます。
-
コールが起動してアクティブになった後、ジッタが疑われる場合は、関連するいずれかのゲートウェイに Telnet で接続します。
-
Telnet セッションでコンソール メッセージを確認できるようにするために、[ターミナル モニタ（Terminal Monitor）] を有効にします。
注：コンソールポートに接続している場合、この手順は必要ありません。
-
show voice call summary コマンドを入力します。以下のような出力が表示されます。
PORT CODEC VAD VTSP STATE VPM STATE ============ ======== === ==================== ====================== 1/0/0 - - - FXSLS_ONHOOK 1/0/1 g729r8 y S_CONNECT FXSLS_CONNECT
ジッタが発生しているコールを選択します。この例では、1/0/1 です。
-
この特定のコールを調べるために、show voice call コマンドを入力します。
この例では、show voice call 1/0/1です。出力は、コールを処理するDSPから取得され、次のような出力になります。
1/0/1 vtsp level 0 state = S_CONNECT vpm level 1 state = FXSLS_CONNECT vpm level 0 state = S_UP MS-2621-3B# ***DSP VOICE VP_DELAY STATISTICS*** Clk Offset(ms): 0, Rx Delay Est(ms): 50 Rx Delay Lo Water Mark(ms): 50, Rx Delay Hi Water Mark(ms): 7 ***DSP VOICE VP_ERROR STATISTICS*** Predict Conceal(ms): 0, Interpolate Conceal(ms): 0 Silence Conceal(ms): 0, Retroact Mem Update(ms): 0 Buf Overflow Discard(ms): 0, Talkspurt Endpoint Detect Err: 0 ***DSP VOICE RX STATISTICS*** Rx Vox/Fax Pkts: 1187, Rx Signal Pkts: 0, Rx Comfort Pkts: 0 Rx Dur(ms): 150200, Rx Vox Dur(ms): 23740, Rx Fax Dur(ms): 0 Rx Non-seq Pkts: 0, Rx Bad Hdr Pkts: 0 Rx Early Pkts: 0, Rx Late Pkts: 0 ***DSP VOICE TX STATISTICS*** Tx Vox/Fax Pkts: 7129, Tx Sig Pkts: 0, Tx Comfort Pkts: 0 Tx Dur(ms): 150200, Tx Vox Dur(ms): 14259, Tx Fax Dur(ms): 0 ***DSP VOICE ERROR STATISTICS*** Rx Pkt Drops(Invalid Header): 0, Tx Pkt Drops(HPI SAM Overflow): 0 ***DSP LEVELS*** TDM Bus Levels(dBm0): Rx -54.5 from PBX/Phone, Tx -64.7 to PBX/Phone TDM ACOM Levels(dBm0): +2.0, TDM ERL Level(dBm0): +9.9 TDM Bgd Levels(dBm0): -49.4, with activity being voice -
出力の ***DSP VOICE VP_ERROR STATISTICS*** セクションを確認します。
このセクションに、調べる必要があるパラメータがいくつかあります。そのうち主なパラメータは、Buf Overflow Discard (ms) の数字です。このパラメータは、再生遅延バッファの範囲外の（ドロップされた）パケットをカウントします。 常に増加し続けていない限り、このパラメータには何らかの値が設定されます。コールを最初に開始する時点である程度のオーバーフローが発生するのは問題ありませんが、この値が show voice call X/X/X コマンドを実行するたびに増加するようであってはなりません。そのような値は、過剰ジッタを直接示すものです。
デフォルトでは、このバッファは適応モードで実行されるため、存在するジッタの量に応じて（ある程度までは）動的に調整を行います。 デジッタ バッファのこの動的動作のデフォルトを変更するには、playout-delay コマンドを設定します。このバッファは、固定モードに設定することもできます。固定モードに設定することで、いくつかの問題が解決される場合もあります。詳細については、Voice over IP での再生遅延の再生遅延機能拡張を参照してください。
ジッタの原因
通常、ジッタは IP ネットワーク内の輻輳が原因で発生します。回線が適切にプロビジョニングされていない場合、ルータ インターフェイスやプロバイダーまたはキャリア ネットワーク内で輻輳が発生する可能性があります。
カプセル化に関する考慮事項
ルータ インターフェイスは回線で直接制御できる部分であるため、ジッタを見つけるのに最も簡単かつ最適な出発点はルータ インターフェイスです。ジッタの原因を突き止める方法は、ジッタが発生しているリンクのカプセル化およびタイプによって大きく異なります。一般に、関連するセル レートが一定している ATM 回線では、設定が適切である限り、ジッタは発生しません。セル レートが一定していれば、かなり一貫した遅延になります。ATM 環境でジッタが発生した場合は、ATM 設定を調べる必要があります。ATM が正常に機能していれば（セルがドロップされなければ）、ジッタが問題になることはないはずです。Point-to-Point Protocol（PPP）カプセル化では、ほぼ必ずと言えるほど、ジッタの原因はシリアル化の遅延にあります。この問題は、PPP リンク上での Link Fragmentation and Interleaving（LFI）によって簡単に対処できます。PPP の特性は、PPP エンドポイントはネットワークやスイッチを介さずに互いに直接対話することを意味します。そのため、関連するすべてのインターフェイスはネットワーク管理者が制御します。
フレーム リレー環境でのジッタ
フレーム リレー環境でジッタを見つけるには、以下の 3 つのパラメータに対処する必要があります。
設定例とその設定方法に関連する情報については、Quality of Service（QoS）を確保するフレーム リレー経由の VoIP を参照してください。
トラフィック シェーピング
ルータから発信されるトラフィックに、キャリアが提供する実際の設定情報レート（CIR）に応じたトラフィック シェーピングが適用されていることを確認する必要があります。これを確認するには、フレーム リレー統計情報を調べて、キャリアに問い合わせます。最初に調べる場所は、フレーム リレー統計情報です。フレーム リレー統計情報を表示するには、show frame-relay pvc xx コマンドを使用します。ここで、xx はデータ リンク接続識別子（DLCI）番号です。次のような出力を受信するはずです。
PVC Statistics for interface Serial0/1 (Frame Relay DTE) DLCI = 16, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/1.1 input pkts 103611 output pkts 120054 in bytes 9909818 out bytes 10962348 dropped pkts 0 in FECN pkts 0 in BECN pkts 0 out FECN pkts 0 out BECN pkts 0 in DE pkts 0 out DE pkts 0 out bcast pkts 1366 out bcast bytes 448048 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec pvc create time 22:45:57, last time pvc status changed 22:45:57 Queueing strategy: weighted fair Current fair queue configuration: Discard Dynamic Reserved threshold queue count queue count 64 16 0 Output queue size 0/max total 600/drops 18303 fragment type end-to-end fragment size 1600 cir 20000 bc 1000 be 0 limit 125 interval 50 mincir 20000 byte increment 125 BECN response no IF_CONG no frags 103356 bytes 9807006 frags delayed 67241 bytes delayed 7127120 shaping active traffic shaping drops 18303
すべてのフィールドの詳細な説明については、show frame-relay pvc の説明を参照してください。
確認事項
このコマンド出力で確認する必要があるのは、フレーム ネットワークで輻輳が発生しているかどうかを示す値です。具体的には、順方向明示的輻輳通知（FECN）、逆方向明示的輻輳通知逆方向明示的輻輳通知（BECN）、および廃棄適性（DE）パラメータの値を確認する必要があります。これらのうち、シスコが送信するものは 1 つもないので、入力パケットだけに注目します。これらのパラメータのうち、1 つ以上の値が増加していることが観測される場合があります。これは、プロバイダーが使用しているフレーム スイッチのタイプと設定に依存します。大まかに言えば、フレーム リレー トラフィック シェーピングを回線と同じ CIR に対して設定していれば、これらのパラメータの値が増加することは決してありません。値が増加していて、回線の実際の CIR と一致しているとしたら、フレーム プロバイダーのネットワーク内で何かが適切に設定されていないということになります。
その好例は、ゼロ CIR 回線を購入しためのに、バースト値が設定されている場合です。一部のプロバイダーはゼロ CIR 相手先固定接続相手先固定接続（PVC）を販売しています。 これはデータには有効ですが、音声品質には問題を引き起こします。ゼロ CIR 回線からのコマンド出力を調べると、DE または FECN パケットの数が入力パケットの数と同じになっています。さらに一歩進めて、キャリアによって PVC が 128 kbs にプロビジョニングされている場合、ルータの CIR が 512 kbs に設定されていると、これらのカウンタが（ゆっくりと）増加するはずです。 ルータ インターフェイスからの入力パケットだけを調べているという点、そしてこのレートは PVC の反対側のルータ上に設定されるトラフィック シェーピング パラメータによって制御されるという点に注意してください。逆に、ローカル エンドのトラフィック シェーピング パラメータは、もう一方のルータに何を入力するかによって設定されます。
キャリアによってプロビジョニングされた PVC の CIR を超えないようにすることが非常に重要です。キャリアがプロビジョニングした CIR 未満の値に設定しても問題はありません。ただし、それを超えている場合には輻輳が発生します。
このようにして輻輳を確認できるわけは、フレーム スイッチ上で特定の PVC に設定された CIR によって、そのスイッチから (その PVC に) 渡されるトラフィックのレートが決まるからです。 実際のデータ受信レートがフレーム スイッチ上で設定されている CIR を超えると、CIR を超えるフレームがバッファされ、キャパシティが利用可能になるまでバッファされたパケットは転送されません。バッファされたパケットには、フレーム スイッチによって DE ビットまたは FECN ビットが設定されます。
いつものように、インターフェイス統計情報を徹底的に調査してドロップやエラーが発生しているかどうかを調べ、物理層ですべてが正しく機能していることを確認する必要があります。それには、show interface コマンドを使用します。
これがどのようにジッタに関連するかと言うと、ジッタが発生すると、一部のパケットをフレーム ネットワーク内でバッファしなければならないため、リモート ルータに到達するまでの遅延が長くなります。一方、輻輳が発生していない間は、通常期待される遅延時間でリモート ルータに到達します。これにより、リモート ルータで受信されるパケット間でデルタ タイムに変動が生じます。つまり、ジッタが発生するというわけです。
フラグメンテーション
フラグメンテーションは、ジッタというよりシリアル化遅延に関係します。ただし、特定の条件下では、ジッタの原因になることもあります。音声をパケット化する場合は、フレーム リレー マップ クラスに常にフラグメンテーションが設定されなくてはなりません。このパラメータの設定は、インターフェイスに 2 つの影響を与えます。その 1 つは、指定されたサイズを超えるすべてのパケットがフラグメント化されることです。もう 1 つの影響も同じく重要なものですが、それほど明らかではありません。フラグメンテーションが設定されているインターフェイスを調べると、このコマンドの影響がわかるはずです。フラグメンテーションが適用されていなければ、show interface x コマンドの出力には、FIFO キューイングがキューイング戦略として示されます。フラグメンテーションがフレーム リレー マップ クラスに適用されると、このコマンドの出力にはキューイング戦略としてデュアル FIFO が示されます。デュアル FIFO では、インターフェイス上の音声トラフィックに使用するプライオリティ キューが作成されます。フラグメンテーション値を設定する際は、Quality of Service（QoS）を確保するフレーム リレー経由の VoIP に関するドキュメントのフラグメンテーション セクションで勧められている値に設定することを強く推奨します。その値に設定してもジッタが発生する場合は、許容できる音声品質になるまで、フラグメンテーションの値を一度に 1 段階ごと下げてください。
キューイング
このタイプの環境で VoIP トラフィックに使用するのに一般的に認められているキューイング方法は 2 つあります。
いずれか一方の方法を使用する必要があります。この両方を同時に設定することはできません。ドキュメントのとおりにキューイングが正常に機能しているようであれば、キューイングではないところに問題があります。キューイングによって生じる遅延の変動は比較的わずかなので、通常はキューイングがジッタの原因になることはありません。ただし、VoIP パケットが正常にキューイングされず、同じ回線上にデータがある場合、ジッタが生じることができます。
結論
ジッタとは、音声パケットのパケット遅延の変動のことです。ルータ内の DSP の数でジッタを補正することはできますが、この方法では過剰なジッタには対処しきれません。これにより音声品質が低下します。ジッタの原因は音声以外のパケットでは遅延もキューイングも発生しない回線のどこかしらで、音声パケットがキューに入れられたり遅延したりすることにあります。それによって遅延に変動が生じるからです。ジッタはルータの不良構成によっても、キャリアやプロバイダーによる PVC の不良構成によっても発生する場合があります。
フィードバック