| 機械翻訳のご利用について |
| 機械翻訳版 - February 2, 2006 |
| ライター翻訳版 - February 2, 2006 |
| 英語版 - February 2, 2006 |
| Document ID: 5125 |
目次
概要
基本的な音声フロー
ボイス圧縮の動作
遅延制限に関する標準
遅延の要素
コーダ(処理)の遅延
パケット化の遅延
シリアル化遅延
キューイングかバッファリングの遅延
ネットワーク スイッチングの遅延
デジッタ バッファの遅延
遅延バジェットを構築して下さい
単一ホップ接続
C7200を使用したパブリックネットワークの2つのホップタンデムスイッチとして機能する
PBX タンデム スイッチを設置した公衆ネットワーク上の 2 つのホップ接続
PBX タンデム スイッチを設置した私設ネットワーク上の 2 つのホップ接続
複数の圧縮サイクルの影響
高遅延接続に関する問題
NetPro ディスカッション フォーラム - 特集対話
関連情報
概要
パケット、フレーム、またはセルインフラストラクチャ上の音声を転送するネットワークを設計するとき、ネットワークの遅延コンポーネントを理解し、説明することは重要です。 すべての潜在的な遅延を正しく説明する場合、全面的なネットワークパフォーマンスが受諾可能であることを確認します。 全面的な音声クオリティは圧縮アルゴリズム、エラーおよびフレーム損失、エコー消去および遅延含む多くのファクタの機能です。 このペーパーはパケットネットワーク上のCiscoルータ/ゲートウェイを使用するとき遅延の原因を説明します。 ここでは、フレームリレー向けの例を示しますが、そのコンセプトは、Voice over IP(VoIP)および Voice over ATM(VoATM)ネットワークにも該当します。
基本的な音声フロー
圧縮音声回線のフローはこのダイアグラムで示されています。 電話機からのアナログ信号は、ボイス 符号/復号化(コーデック)により、Pulse Code Modulation(PCM; パルス符号変調)としてデジタル化されます。 次に、PCM サンプルは、圧縮アルゴリズムに渡され、そこでボイスはパケット形式に圧縮されてから、WAN 上に送信されます。 IP クラウドの先にある相手側機器では、まったく同様の処理が逆の順序で実行されます。 全体のフローを図 2-1 に示します。
図 2-1 エンドツーエンドボイスフロー
基づいてネットワークがどのようにに設定されるか、ルータ/ゲートウェイはそれらのコーデックおよび圧縮機能または1両方だけ行うことができます。 たとえば、アナログボイスシステムを使用している場合は、ルータ/ゲートウェイは図 2-2 に示すように、コーデックおよび圧縮の両方の機能を実行します。
図 2-2 ルータ/ゲートウェイでのコーデック機能
デジタルPBXが使用される場合、PBXはコーデック機能およびルータプロセスをPBXをそれに通じるPCMのサンプル行います。 例は図2-3で示されています。
PBXの図2-3のコーデック機能
ボイス圧縮の動作
Ciscoルータ/ゲートウェイで使用される高密度の圧縮アルゴリズムは音声コーデックによって渡されるPCMのサンプルのブロックを分析します。 これらのブロックはコーダに基づいて長さが異なります。 たとえば、G.729 アルゴリズムが使用する基本ブロック サイズは 10 ms で、G 723.1 が使用する基本ブロック サイズは 30 ms です。 G.729 圧縮システムの動作の例を図 3-1 に示します。
図 3-1 ボイスの圧縮
アナログボイスストリームは、10 ms 単位で PCM サンプルとしてデジタル化されて、圧縮アルゴリズムに送られます。 ルック アヘッドについては、5.1.1 項のアルゴリズム遅延で説明します。
遅延制限に関する標準
International Telecommunication Union(ITU)は、勧告 G.114 でボイスアプリケーションのネットワーク遅延を取り上げています。 この勧告は表4.1に示すように一方向遅延の3つの帯域を定義します。
表 4.1 遅延に関する仕様
|
範囲(ミリ秒) |
説明 |
|---|---|
|
0-150 |
ほとんどのユーザ アプリケーションにとって許容範囲である。 |
|
150-400 |
管理者が送信時間および影響に気づいていれば受諾可能それはユーザアプリケ−ションの伝送品質で持っています。 |
|
400 を超える値 |
一般的なネットワークの計画の目的で受け入れられない。 ただし例外的にこの限界が超過することが、認識されます。 |
注: これらの推奨事項は十分に制御されるエコーの接続のためです。 これはエコーキャンセラが使用されることを意味します。 エコー キャンセラが必要なのは、一方向遅延が 25 ms を超える場合です(G.131)。
National電気通信の管理に関するこれらの推奨事項は方向づけられます。 従って、これらはプライベート音声ネットワークで普通適用されたとき厳しいですより。 エンドユーザの位置およびビジネス上の必要がネットワーク設計者によく知られっているとき、より多くの遅延は受諾可能証明できます。 プライベートネットワークに関しては遅延の200 msは適度な目的および250 ms限界です。 すべてのネットワークは音声接続が遅延知られ、最小になることを最大が期待したことそのような物設計される必要があります。
遅延の要素
修復されて呼出される遅延には2つの別々の種類が可変のあり。
-
固定遅延の要素は、接続上の全体的な遅延に直接関わります。
-
可変遅延は、WAN に接続しているシリアル ポート上の出力トランクで、バッファによるキューイング遅延から発生します。 これらのバッファによって、ジッタと呼ばれる可変遅延がネットワークに発生します。 可変遅延は受信ルータ/ゲートウェイのデジッタバッファによって処理されます。 デジッタバッファはこの資料のデジッタ遅延(Δn)のセクションに説明があります。
図 5-1 では、ネットワーク内に存在するすべての固定および可変の遅延要素を示します。 各ソースはこの資料に詳しく説明があります。
図5-1: 遅延ソース
コーダ(処理)の遅延
コーダ遅延はPCMのサンプルのブロックを圧縮するためにデジタル信号プロセッサ(DSP)にかかった時間です。 これはまた処理遅延(χ)とn呼ばれます。 この遅延は使用される音声コーダおよびプロセッサスピードと異なります。 たとえば、Algebraic Code Excited Linear Prediction (ACELP)のアルゴリズムはPCMのサンプルの10 msブロックを分析し、次にそれらを圧縮します。
Conjugate Structure Algebraic Code Excited Linear Prediction (CS-ACELP)のプロセスのための圧縮時間は2.5 msからDSPのプロセッサのロードに基づいて10 msまで及びます。 DSPに4つの音声チャネルが十分にロードされる場合、コーダ遅延は10 msです。 DSPに1つの音声チャネルだけがロードされればコーダ遅延は2.5氏設計目的で使用します10 msの最悪の場合の時をです。
復元時間は各ブロックのための圧縮時間の大体10%です。 ただし、復元時間は複数のサンプルの存在が理由でフレームごとのサンプルの数に比例しています。 その結果、3つのサンプルとのフレームのための最悪の場合の復元時間は3のx 1 msまたは3 msです。 通常、圧縮されたG.729出力の2つか3つのブロックは1フレームに圧縮されたG.723.1出力の1のサンプルが単一のフレームで送られる間、置かれます。
最良および最悪のケースのコーダ遅延は表5.1で示されています。
表 5.1 最良および最悪のケースの処理遅延
|
コーダ |
速度 |
必要なサンプルブロック |
最良のケースのコーダ遅延 |
最悪のケースのコーダ遅延 |
|---|---|---|---|---|
|
ADPCM、G.726 |
32キロビット/秒 |
10 ミリ秒 |
2.5 ms |
10 ミリ秒 |
|
CS-ACELP、G.729A |
8.0キロビット/秒 |
10 ミリ秒 |
2.5 ms |
10 ミリ秒 |
|
MP-MLQ、G.723.1 |
6.3キロビット/秒 |
30 ミリ秒 |
5 ミリ秒 |
20 ミリ秒 |
|
MP-ACELP、G.723.1 |
5.3キロビット/秒 |
30 ミリ秒 |
5 ミリ秒 |
20 ミリ秒 |
アルゴリズム遅延
圧縮アルゴリズムは既知音声特性に正しくサンプルブロックN.を処理するために頼ります。 なければある正確にサンプルブロックN.を再生するべきをものがのブロックN+1にアルゴリズムに知識がなりません。 実際に追加遅延であるこのルックアヘッドはアルゴリズム遅延と呼ばれます。 これは効果的に圧縮ブロックの長さを増加します。
これはブロックN+1がブロックN+2調べること、そのような物、等等繰り返し起こります。 リンク上の全体的な遅延への実質的な影響として、5 ms が追加されます。 つまり、情報ブロックの処理には、10 m と固定オーバーヘッドの 5 ms を合計した時間が必要です。 図3-1を参照して下さい: 音声圧縮。
-
G.726 コーダのアルゴリズム遅延は 0 ms です。
-
G.729 コーダのアルゴリズム遅延は 5 ms です。
-
G.723.1 コーダのアルゴリズム遅延は 7.5 ms です。
この文書の残りの例に関しては、30 ms/30バイトのペイロードとのG.729圧縮を仮定して下さい。 設計を促進し、保守的なアプローチを行うために、この文書の残りで与えられる表は最悪のケースコーダの遅延を仮定します。 コーダ遅延、伸長遅延およびアルゴリズム遅延はコーダ遅延と呼ばれる1つの要因としてひとまとめにされます。
次に、統括したコーダ遅延パラメータを生成する式を示します。
式 1: 統括したコーダ遅延パラメータ
この文書の残りのために使用するG.729のためのひとまとめにされたコーダ遅延は次のとおりです:
最悪のケースのブロック単位の圧縮時間: 10 ミリ秒
ブロック単位の伸長時間 X 3 ブロック3 ms
アルゴリズム遅延5 ms ---------------------------
合計時間(<FONT style="FONT-WEIGHT: normal; FONT-STYLE: normal; FONT-FAMILY: Symbol">c)18 ms
パケット化の遅延
パケット化遅延(πn)は符号化されたか、または圧縮されたスピーチでパケットのペイロードを一杯にするためにかけられる時間です。 この遅延は、ボコーダや 1 つのフレームに配置されたブロック数に必要なサンプル ブロック サイズにより決まります。 パケット化遅延はまたリリースされる前に音声サンプルがバッファで集まるのでAccumulationの遅延と呼ぶことができます。
一般に30 ms以下のパケット化遅延のために努力する必要がありません。 Ciscoルータ/ゲートウェイで設定されたペイロードサイズに基づいて表5.2からのこれらの図を使用する必要があります:
表5 .2: 代表的なパケット化 遅延
|
コーダ |
ペイロード サイズ(バイト) |
パケット化遅延(ms) |
ペイロード サイズ(バイト) |
パケット化遅延(ms) |
|
|---|---|---|---|---|---|
|
PCM、G.711 |
64 kbps |
160 |
20 |
240 |
30 |
|
ADPCM、G.726 |
32キロビット/秒 |
80 |
20 |
120 |
30 |
|
CS-ACELP、G.729 |
8.0キロビット/秒 |
20 |
20 |
30 |
30 |
|
MP-MLQ、G.723.1 |
6.3キロビット/秒 |
24 |
24 |
60 |
48 |
|
MP-ACELP、G.723.1 |
5.3キロビット/秒 |
20 |
30 |
60 |
60 |
パケット化遅延をはCPU の負荷に対して調整する必要があります。 遅延 を小さくする場合、フレーム サイズのレートも大きくなり、CPU の負荷も高くなります。 一部の古いプラットフォームで、20のmsのペイロードは可能性としてはメインCPUをろ過できます。
パケット化プロセスのパイプラインの遅延
各ボイスサンプルでは、アルゴリズム遅延とパケット化遅延の両方が発生していますが、実際には、これらのプロセスは重複することがあり、このパイプライニングから実質的に有利な効果があります。 図2-1で示されている例を参照して下さい。
図 5-2: パイプライニングとパケット化
図の上ラインはサンプル音声波形を描写します。 第2ラインは10のmsの増分の時間目盛です。 Tで0、CS-ACELPのアルゴリズムはコーデックからPCMのサンプルを収集し始めます。 Tで1、アルゴリズムはサンプルの最初10 msブロックを集め、それを圧縮し始めます。 Tで2、サンプルの最初のブロックは圧縮されました。 この例では圧縮時間はTTによって示されるように2.5 ms、です21。
第2および第3ブロックはTおよびT.で3 集められます。4 第3ブロックはT.で圧縮されています。5 パケットはT.で(即時があると仮定される)アセンブルされ、送られます。6 音声フレームが送られるときプロセスがに開始されるとき圧縮およびパケット化プロセスの導管で送られた性質が原因で、遅延はからのTT、60またはおよそ32.5 msです。
実例として、この例は最もよいケースの遅延に基づいています。 最悪の場合の遅延が使用される場合、図はコーダ遅延のための40 ms、10 msおよびパケット化遅延のための30 msです。
これらの例がアルゴリズム遅延を含むことを無視することに注目して下さい。
シリアル化遅延
シリアライゼーションの遅延(σn)がネットワーク・インターフェイスに音声またはデータフレームの時間を記録するために必要な固定遅延です。 それはトランクのクロック・レートと直接関連しています。 低いクロック速度および小さいフレームサイズで、フレームを分けるのに必要とされる余分フラグは重要です。
表 5.3 では、フレーム サイズごとに必要なシリアライゼーション遅延を回線速度別に表示しています。 この表では、ペイロードのサイズではなく、総フレーム サイズを計算に使用しています。
表5.3: 異なるフレームサイズのためのミリ秒のシリアライゼーションの遅延
|
フレーム サイズ(バイト) |
回線速度(Kbps) |
||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
|
19.2 |
56 |
64 |
128 |
256 |
384 |
512 |
768 |
1024年 |
1544年 |
2048年 |
|
|
38 |
15.83 |
5.43 |
4.75 |
2.38 |
1.19 |
0.79 |
0.59 |
0.40 |
0.30 |
0.20 |
0.15 |
|
48 |
20.00 |
6.86 |
6.00 |
3.00 |
1.50 |
1.00 |
0.75 |
0.50 |
0.38 |
0.25 |
0.19 |
|
64 |
26.67 |
9.14 |
8.00 |
4.00 |
2.00 |
1.33 |
1.00 |
0.67 |
0.50 |
0.33 |
0.25 |
|
128 |
53.33 |
18.29 |
16.00 |
8.00 |
4.00 |
2.67 |
2.00 |
1.33 |
1.00 |
0.66 |
0.50 |
|
256 |
106.67 |
36.57 |
32.00 |
16.00 |
8.00 |
5.33 |
4.00 |
2.67 |
2.00 |
1.33 |
1.00 |
|
512 |
213.33 |
73.14 |
64.00 |
32.00 |
16.00 |
10.67 |
8.00 |
5.33 |
4.00 |
2.65 |
2.00 |
|
1024年 |
426.67 |
149.29 |
128.00 |
64.00 |
32.00 |
21.33 |
16.00 |
10.67 |
8.00 |
5.31 |
4.00 |
|
1500年 |
625.00 |
214.29 |
187.50 |
93.75 |
46.88 |
31.25 |
23.44 |
15.63 |
11.72 |
7.77 |
5.86 |
|
2048年 |
853.33 |
292.57 |
256.00 |
128.00 |
64.00 |
42.67 |
32.00 |
21.33 |
16.00 |
10.61 |
8.00 |
表では、38バイト(37+1フラグ)の長さの64キロビット毎秒の回線で、CS-ACELPの音声フレームに4.75 msのシリアライゼーションの遅延があります。
注: 53バイトのATMセル(T1のためのシリアライゼーションの遅延: 0.275ms、E1: 0.207msは)高圧線の速度および小さいセルのサイズが僅かな原因です。
キューイング/バッファリングの遅延
圧縮されたボイスペイロードが作成されてから、ヘッダーが付加され、そのフレームはネットワーク 上に送信されるためにキューイングされます。 音声にルータ/ゲートウェイの絶対的な優先度がある必要があります。 従って、音声フレームはそれに先んじる他の音声フレームどちらか既に展開している、またはのためにだけ必要がありますデータフレームを待つ。 基本的に音声フレームは出力キューのあらゆる先行するフレームのシリアライゼーションの遅延を待っています。 キューイング遅延は(か。n)可変遅延、キューのトランク速度および状態に依存しています。 キューイング遅延と関連付けられるランダムの要素があります。
たとえば64キロビット毎秒の回線にあると、そして1つのデータフレーム(48バイト)および1の音声フレーム(42バイト)の後ろで並べられると、仮定して下さい。 展開したか48バイト・フレームのどの位に関してランダムの性質があるので、データフレーム半分が展開されたこと、安全に、平均すると仮定できます。 シリアライゼーションの表からのデータに基づいて、データフレームのコンポーネントは6 ms * 0.5の= 3 msです。 キュー(5.25 ms)の別の音声フレームの時間を前方に追加する時、8.25 msのキューイング遅延の合計時間を与えます。
キューイング遅延の特性をどのように考慮するかは、ネットワーク技術者に任せられます。 通常、1つはネットワークがインストールされていた後最悪の場合のために設計し、次にパフォーマンスを調整する必要があります。 ユーザにより高い、利用可能なより多くの音声回線確率平均音声パケット待っていますキューで。 音声フレームは、優先順位の構造が理由で複数のデータフレームの後ろで、決して待っていません。
ネットワーク スイッチングの遅延
エンドポイント・ロケーションを相互接続するATMネットワークかパブリックフレームリレーは音声接続のための最も大きい遅延のソースです。 ネットワークスイッチングの遅延(ωn)はまた最も量を示しにくいです。
Cisco の機器またはその他の私設ネットワークにより広範囲の接続が提供されている場合、それぞれの遅延要素をある程度予測できます。 一般的に、固定遅延要素は、ネットワーク内のトランク上の伝搬遅延によって、また可変遅延は、クロッキング フレームが中継スイッチに入出力することによるキューイング遅延によって発生します。 伝搬遅延を推定するため、10のマイクロ秒またはマイルの普及した推定値または6 microseconds/km (G.114)は広く利用されている。 ただし、中間多重化装置、バックホーリング、マイクロウェーブアクセスおよび搬送ネットワークで見つけられる他のファクタは多くの例外を作成します。
その他の重要な遅延要素は、広域ネットワーク内のキューイングが原因となります。 プライベートネットワークでは、既存のキューイング遅延を測定するか、またはワイドエリア・ネットワーク内のホップごとの予算を推定することは可能である場合もあります。
米国のフレームリレー接続のための典型的なキャリアの遅延は例の65氏の総最悪の場合の遅延のための40 msの簡単にするために固定および25 msの可変の、6-1、6-2であり、6-3は、40 msの固定遅延のあらゆる低速シリアライゼーションの遅延含まれています。
これらは米国内のどこでもカバレッジにどこでもカバーするために米国のフレームリレー通信業者によって送達される図です。 それは最悪の場合より地理的に密接の2つの位置によりよい遅延パフォーマンスがあるが、キャリアは普通ちょうど最悪の場合を文書化しますこと期待されるべきです。
時々フレームリレー通信業者の提供のプレミアムサービス。 これらのサービスは音声かネットワーク遅延が標準サービスのレベル以下および保証されるシステム・ネットワーク・アーキテクチャ(SNA)のトラフィックのため通常です。 たとえば、ある米国の通信事業者は最近、全体的な遅延制限値が、標準サービスの 65 ms よりもさらに低い 50 ms サービスの提供を発表しました。
デジッタ バッファの遅延
ボイスは固定ビット レート サービスなので、可変遅延であるすべてのジッタは、信号がネットワークから出る前に除去される必要があります。 Ciscoルータ/ゲートウェイでこれは遠端(受信の)ルータ/ゲートウェイのnデジッタ(Δ)のバッファと達成されます。 デジッタバッファは固定遅延に可変遅延をトランスフォームします。 それはそれを展開する前に最初のサンプルをしばらく受け取られて保持します。 この保持期間は、 初期再生遅延(Initial Playout Delay))として知られています。
図 5-3: ジッタ解消バッファの動作
デジッタバッファをきちんと処理することは必要です。 サンプルが余りにも短い時間の間保持される場合可能性としてはバッファをアンダーランに引き起こしには、スピーチのギャップを引き起こす、遅延の変化によりできます。 また、サンプルの保持時間が長すぎると、バッファはオーバーランし、ドロップされたパケットが原因で、ここでもボイスに途切れが発生する場合があります。 最後にパケットが余りにも長い時間の間保持されれば、接続の全体の遅延は受け入れられないレベルに上がるにはできます。
最適の最初の再生はデジッタバッファのために接続に沿う総可変遅延と等しいです遅れます。 これは図5-4で示されています。
注: デジッタバッファは適応性がありますが最大遅延は固定です。 適応性があるバッファが設定されるとき、遅延は可変図になります。 ただし、最大遅延は最悪の場合として設計目的で使用することができます。
適応性があるバッファに関する詳細については、Voice over IPのためのプレイアウト遅延の機能拡張を参照して下さい。
図5 -4: 可変遅延およびデジッタバッファ
最初のプレイアウト遅延は設定可能です。 オーバーフローする前にバッファの最大深さは普通1.5か2.0倍に一定この値です。
40 msの公称遅延設定が使用される場合、最初の音声サンプルは展開される前にデジッタバッファが40 msのために空の保持されるとき受け取りました。 これは40 msが(最初のパケットに関して)遅れる音声継続の損失なしでとネットワークから受信される後続パケットが多くである場合もあることを意味します。 それが40 ms以上遅れる場合、デジッタバッファは空になり、バッファをリセットするために受信される次のパケットは演劇の前の40 msのために保持されます。 これは約40 msのために展開される音声のギャップという結果に終ります。
遅れるべきデジッタバッファの実際の貢献は最初のパケットがネットワークでバッファリングされた実際の量とデジッタバッファの最初の再生の遅延です。 最悪の場合はデジッタバッファの最初の遅延の二倍になります(仮定はネットワークから受信した最初のパケットに最小限のバッファリング遅延だけ生じたこと)です。 実際には、いくつかのネットワークスイッチホップに、おそらく最悪の場合を仮定することは必要ではないです。 この文書の残りの例の計算は1.5のファクタによってこの効果を可能にするために最初の再生を遅れます高めます。
注: 受信ルータ/ゲートウェイでは圧縮解除の機能によって遅延があります。 ただし、これは前に説明されている通り圧縮の処理遅延とともにそれをひとまとめにすることによって考慮に入れられます。
遅延バジェットを構築して下さい
高品質ボイス接続の遅延の一般的な許容値は、一方向で 200 ms(または 限界値は 250 ms)です。 遅延がこの値を超えると、話し手と聞き手の間で会話のタイミングが取れないため、お互いに同時に話したり、または相手が話すのを待ったりします。 この条件は一般に送話者のオーバーラップと呼ばれます。 全面的な音声クオリティが受諾可能な間、ユーザは時々受け入れがたいほど悩む会話の大げさな性質を見つけます。 送話者のオーバーラップは衛星接続に移動する国際的な電話で観察することができます(衛星遅延は500 ms、250 msおよび250 msの順序でアップします)。
これらの例はさまざまなネットワークコンフィギュレーションをおよび考慮に入れるネットワーク設計者が必要がある遅延を説明します。
単一ホップ接続
図6 - 1: 単一ホップの接続例
この図から、パブリックフレームリレーの接続上の典型的なワンホップの接続は表6.1を示されている遅延バジェットを有する場合があります。
表6 .1: 単一ホップ遅延の計算
|
遅延のタイプ |
固定(ms) |
可変(ms) |
|---|---|---|
|
コーダ遅延、χ1 |
18 |
|
|
パケット化遅延、π1 |
30 |
|
|
キューイングかバッファリング、か。1 |
8 |
|
|
シリアライゼーションの遅延(64キロビット/秒)、σ1 |
5 |
|
|
ネットワーク遅延(パブリックフレーム)、ω1 |
40 |
25 |
|
デジッタバッファ遅延、Δ1 |
45 |
|
|
合計 |
138 |
33 |
注: ネットワーク遅延のキューイング遅延および可変コンポーネントがデジッタバッファの計算の内で既に説明されているので、全体の遅延は効果的にすべての固定遅延の合計だけです。 この場合全体の遅延は138 msです。
C7200を使用したパブリックネットワークの2つのホップタンデムスイッチとして機能する
図6 - 2: ルータおよびゲートウェイ タンデムを配置した 2 つのホップからなる公衆ネットワーク例
ここで、本社の C7200 がコールを支店にタンデムするスター型トポロジ ネットワークの、支店間接続を考えます。 この場合シグナルは中央C7200によって圧縮されたフォーマットにとどまります。 これは次の例、PBXタンデムスイッチのパブリックネットワーク上のTwo-Hop接続に関して遅延バジェットのかなりの節約という結果に終ります。
表6.2: ルータ/ゲートウェイタンデムとの2ホップのパブリックネットワーク遅延計算
|
遅延のタイプ |
固定(ms) |
可変(ms) |
|---|---|---|
|
コーダ遅延、χ1 |
18 |
|
|
パケット化遅延、π1 |
30 |
|
|
キューイングかバッファリング、か。1 |
8 |
|
|
シリアライゼーションの遅延(64キロビット/秒)、σ1 |
5 |
|
|
ネットワーク遅延(パブリックフレーム)、ω1 |
40 |
25 |
|
MC3810のタンデム遅延、τ1 |
1 |
|
|
キューイングかバッファリング、か。2 |
0.2 |
|
|
シリアライゼーションの遅延(2 Mbps)、σ2 |
0.1 |
|
|
ネットワーク遅延(パブリックフレーム)、ω2 |
40 |
25 |
|
デジッタバッファ遅延、Δ1 |
75 |
|
|
合計 |
209.1 |
58.2 |
注: ネットワーク遅延のキューイング遅延および可変コンポーネントがデジッタバッファの計算の内で既に説明されているので、全体の遅延は効果的にすべての固定遅延の合計だけです。 この場合全体の遅延は209.1 msです。
PBX タンデム スイッチを設置した公衆ネットワーク上の 2 つのホップ接続
図6-3: PBXのタンデムとの2ホップのパブリックネットワークの例
本社の C7200 が PBX を通じて接続をスイッチングする、支店間接続を考えます。 次にここに音声信号は復元され、ジッタ修正され、再圧縮されす、二回目ジッタ修正されなければなりません。 これは前例に関連して余分遅延という結果に終ります。 他にも、2 つの CS-ACELP 圧縮サイクルによってボイス品質が劣化します(7 項の複数の圧縮サイクルの影響を参照してください)。
表6.3: PBXのタンデムとの2ホップのパブリックネットワーク遅延計算
|
遅延のタイプ |
固定(ms) |
可変(ms) |
|---|---|---|
|
コーダ遅延、χ1 |
18 |
|
|
パケット化遅延、π1 |
30 |
|
|
キューイングかバッファリング、か。1 |
8 |
|
|
シリアライゼーションの遅延(64キロビット/秒)、σ1 |
5 |
|
|
ネットワーク遅延(パブリックフレーム)、ω1 |
40 |
25 |
|
デジッタバッファ遅延、Δ1 |
40 |
|
|
コーダ遅延、χ2 |
15 |
|
|
パケット化遅延、π2 |
30 |
|
|
キューイングかバッファリング、か。2 |
0.1 |
|
|
シリアライゼーションの遅延(2 Mbps)、σ2 |
0.1 |
|
|
ネットワーク遅延(パブリックフレーム)、ω2 |
40 |
25 |
|
デジッタバッファ遅延、Δ2 |
40 |
|
|
合計 |
258.1 |
58.1 |
注: ネットワーク遅延のキューイング遅延および可変コンポーネントがデジッタバッファの計算の内で既に説明されているので、全体の遅延は効果的にデジッタバッファ遅延とすべての固定遅延の合計だけです。 この場合全体の遅延は258.1 msです。
スイッチとしてセントラルサイトでPBXを使用する場合、206 msから255 ms一方向接続の遅延を高めますから。 これは一方向遅延のためのITUの限界に密接です。 このようなネットワーク構成の場合、技術者は遅延を最小限に抑えるように設計する必要があります。
最悪の場合は可変遅延のために(パブリックネットワークのレグが両方とも最大遅延を同時に見ないが)仮定されます。 可変遅延のためのより楽観的な仮定をする場合、それは最小限に状況だけを改善します。 ただし、キャリアのフレームリレーネットワークの固定および可変遅延についてのよりよい情報と、計算された遅延は減らすことができます。 アメリカでは、州内などのローカル接続の場合、遅延特性が改善されることも期待できますが、通常、通信事業者からは遅延の限界値は提示されません。
PBX タンデム スイッチを設置した私設ネットワーク上の 2 つのホップ接続
図6-4: PBX タンデムを配置した 2 つのホップからなる私設ネットワーク例
、最悪の場合の遅延を考慮して、ブランチ・ツー・ブランチ接続がパブリックフレームリレーネットワークの接続とのセントラルサイトでPBXのタンデムホップがどちら側でも含まれている200 ms以下計算された遅延を保存することは非常に困難であることをExample 4.3:示します。 しかし、ネットワーク トポロジとトラフィックがわかっていれば、実質的に計算結果の値を抑えることができます。 これは一般にキャリアによって与えられる図が最悪の場合の伝達およびキューイング遅延によってワイドエリア制限されるという理由によります。 プライベートネットワークでより適度な限界を確立することはもっと簡単です。
スイッチ間の伝送遅延について一般的な許容値は、およそ 10 マイクロ秒/マイルです。 機器に基づいて、フレームリレーネットワークのトランス・スイッチの遅延はキューイングのための1 msの固定および5 msの可変のの順序である必要があります。 これらの図は機器およびトラフィック依存です。 Cisco MGX WANスイッチ用の遅延の合計はスイッチの合計毎に1 ms以下E1/T1トランクが使用される場合です。 500マイルの各ホップのための1 msの固定および5 msの可変のの距離を考慮して、遅延計算はなります:
表6 .4: PBX タンデムを配置した 2 つのホップからなる私設ネットワークの遅延計算
|
遅延のタイプ |
固定(ms) |
可変(ms) |
|---|---|---|
|
コーダ遅延、χ1 |
18 |
|
|
パケット化遅延、π1 |
30 |
|
|
キューイングかバッファリング、か。1 |
8 |
|
|
シリアライゼーションの遅延(64キロビット/秒)、σ1 |
5 |
|
|
ネットワーク遅延(プライベートフレーム)、ωS1 +か。S1+ ωS2 +か。S2 |
2 |
10 |
|
デジッタバッファ遅延、Δ1 |
40 |
|
|
コーダ遅延、χ2 |
15 |
|
|
パケット化遅延、π2 |
30 |
|
|
キューイングかバッファリング、か。2 |
0.1 |
|
|
シリアライゼーションの遅延(2 Mbps)、σ2 |
0.1 |
|
|
ネットワーク遅延(プライベートフレーム)、ωS3 +か。S3 |
1 |
8 |
|
シリアライゼーションの遅延(64キロビット/秒)、σS3 |
5 |
|
|
デジッタバッファ遅延、Δ2 |
40 |
|
|
伝送/距離遅延(非切断) |
5 |
|
|
合計 |
191.1 |
26.1 |
注: ネットワーク遅延のキューイング遅延および可変コンポーネントがデジッタバッファの計算の内で既に説明されているので、全体の遅延はすべての固定遅延の合計だけです。 この場合全体の遅延は191.1 msです。
プライベートフレームリレーネットワークを実行するとき、ハブサイトのスポーク間の接続をPBXによってし、200 msの図の内にとどまることは可能です。
複数の圧縮サイクルの影響
CS-ACELP圧縮のアルゴリズムは決定論ではないです。 これは入力データストリームが出力データ・ストリームとして全く同じではないことを意味します。 図 7-1 に示すように、圧縮サイクルごとに少量の歪みが生じます。
図7-1: 圧縮の効果
したがって、複数の CS-ACELP 圧縮サイクルでは、すぐに高レベルの歪みが生じます。 この付加的な歪みの影響は、Adaptive Differential Pulse Code Modulation(ADPCM; 適応差分パルス符号変調)アルゴリズムでは報告されていません。
この特性の影響は遅延の効果に加えてそれ、ネットワーク設計者パスのCS-ACELP圧縮のサイクルの番号を考慮する必要がありますです。
音声クオリティは主観的です。 ほとんどのユーザは2つの圧縮サイクルがそれにもかかわらず十分な音声クオリティを提供することが分ります。 第3圧縮サイクルは通常何人かのユーザに受け入れられない場合もある顕著な劣化という結果に終ります。 一般に、ネットワーク設計者は2にパスのCS-ACELP圧縮のサイクルの番号を制限する必要があります。 2 度よりも多いサイクルを使用する必要が生じた場合には、まずはカスタマーに確認してください。
前例では、ブランチ・ツー・ブランチ接続がタンデムのときことが本部C7200でタンデム交換されしていた場合本部のサイトでPBXによって(PCMの形式で)切り替えました、それ生じますかなり多くの遅延がより示されています。 フレーム化された音声が中央C7200によって切り替えたあるときPBXが切り替えるのに使用されているときパスに2 CS-ACELP圧縮のサイクルがあることは1つのサイクルの代りに明らか、です。 音声クオリティはPBXがパスに含まれているように要求できる計画管理に問い合わせることのような他の理由が、ある場合もあるがC7200スイッチドの例とよりよいです(4.2)。
ブランチ・ツー・ブランチ接続がセントラルPBXによってなされ、第2ブランチからコールが公共の音声ネットワークに拡張、次に携帯電話ネットワークで終われば場合、パスに3 CS-ACELP圧縮のサイクル、またかなりより高い遅延があります。 このシナリオでは、品質は著しく影響を受けています。 再度、ネットワーク設計者はワースト・ケースのコール・パスを考慮し、ユーザにネットワーク、予想およびビジネスの要求があるそれが受諾可能であるかどうか決定する必要があります。
高遅延接続に関する問題
ITU一般に認められた150 msの一方向遅延の限界を超過するパケット音声ネットワークを設計することは比較的容易です。
パケット音声ネットワークを設計するとき、エンジニアはユーザが要求しこと、経済活動が複雑であるどのようなどの位の割りでそのような接続が使用されるか考慮する必要があります。 特定の環境に限って、このような接続が許容されることは珍しくありません。
フレームリレー接続が大きい距離を横断しない場合、ネットワークの遅延パフォーマンスが例で示されているそれよりよいことはかなり本当らしいです。
タンデム ルータおよびゲートウェイ接続の総遅延値が大きくなりすぎた場合、エンドポイントの MC3810 間に直接追加の PVC を設定する、別の方法があります。 これはネットワークにキャリアが通常PVCごとに満たす、それは場合によっては必要である場合もありますと同時に再発コストを追加します。
NetPro ディスカッション フォーラム - 特集対話
| NetPro ディスカッション フォーラム - ボイスに関する特集対話 |
| サービス プロバイダー: Voice over IP |
| ボイスとビデオ: Voice over IP |
| ボイスとビデオ: IP テレフォニー |
| ボイスとビデオ: エンド ユーザ向けの IP 電話サービス |
| ボイスとビデオ: 統合された通信 |
| ボイスとビデオ: 開発者向けの IP 電話サービス |
| ボイスとビデオ: 一般 |
関連情報
-
International Telecommunication Union
- ボイス テクノロジー サポート
- ボイスと統合通信製品サポート(英語)
-
推奨書籍: Troubleshooting Cisco IP Telephony
- テクニカル サポート - シスコシステムズ
