間違いだらけのネットワーク作り(20) 98/04/04
「VoFRにおけるデータ・フラグメンテーション」


このページの読者の方からVoFRでのデータ・フレームのフラグメンテーションについて質問が来ました。難しい質問で的確な回答とは言えないかもしれませんが、参考になるところもあると思いますので質問と回答を掲載します。なお、質問を頂いた方が特定される固有名詞等の情報は削除しました。

(質問1)=頂いたメールの前半
次のような流れの場合、音質は揺らぎや遅延が大きくなり使えなくなるのではないでしょうか。
(Point To Pointのネットワークではなく、メッシュのネットワークの場合)
1、A支店とB支店で通話中。(A支店とB支店間は音声以外のデータも音質重視のためショートパケットにセグメンテーションされ低遅延、高音質で通話。)
2、C支店からA支店にレガシーデータが送信。(C支店は通話していないのでセグメンテーションされず、ロングパケットでA支店に送信される。)
3、A支店では音声パケットの到着時間がロングパケットにより不安定になり揺らぎや途切れが発生する。 公衆フレームリレーを使用した場合は優先制御がないので以上のような結果になり、音質の悪化がさけられないのではないでしょうか。当社でも公衆フレームリレーを使用していますが、このような場合はどうしても音質を改善できないものでしょうか。

(回答1)
音声の途切れが発生するようですが、これだけの情報で原因を特定することは出来ません。レガシー・データの速度が9.6kb/s程度、通話中のチャネル数は1チャネル(8K圧縮か16K圧縮)、A支店〜B支店間のPVCのCIRは32K以上で充分ある、といった仮定をすると一般的な音声FRADで音声の途切れがでることはあまりないと思います。

ロングパケットが公衆フレームリレー網の交換機からA支店のFRADに送信されている間、音声は送信されません。しかし、レガシー・データのフレーム長はそんなに長くはないんじゃないでしょうか?仮に500バイト、A支店の回線の物理速度が64Kとすると62.5ミリ秒、128Kとすると33ミリ秒の伝送時間がかかり、その間音声は途切れます。しかし、この程度の遅延時間はFRADの受信バッファ(音声フレームの伝送遅延時間のゆらぎを吸収するためのバッファ。スムージング・バッファとも呼ぶ)で吸収できるハズです。「ハズ」というのはFRADのスペックに依存するためですが、一般的に音声FRADは最大150ミリ秒程度までの受信バッファサイズを指定できます。

対症療法として考えられるのは、
@A支店の回線速度やCIRが複数の支店と音声やレガシーデータを通信するために充分な回線速度やCIRを契約しているのかチェックする。そもそも契約されている帯域が必要を満たしてなければ音声フレームの伝送に支障をきたすのはしようがありません。
Aもし可能なら、A支店の受信バッファサイズを大きくする。
Bもし可能なら、音声の有無にかかわらずレガシー・データのフラグメンテーションをするように指定する。

(参考)
○間違いだらけのネットワーク作り(3)「 公衆フレームリレーでの音声の途切れ」

(質問2)=頂いたメールの後半
レガシーデータのセグメンテーションサイズについて教えてください。 私は、セグメンテーションサイズを算出する場合、下記のように算出しましたが 如何なものでしょうか。
前提条件  音声パケットは40バイトを20ms間隔で送信するFRADで回 線速度は64kbps、Voiceチャネルは2chの場合。
パケット処理能力をも考慮しレガシーデータは可能な限りロングパケットとして FRADの負荷を軽減するため下記のように計算。
音声がきれいに並んだとして、
40byte×8bit×2ch=640bit ・・・・・・ 20ms のなかに2ch並んだ場合の必要帯域
64000bps×0.02s=1280bit ・・・・・ 20ms で必要な帯域(64kbps×20ms)
1280bit−640bit=640bit ・・・・・・・ 音 声を2ch使用した場合の空き帯域
640bit÷8bit=80byte ・・・・・・・・・・・ セグメンテーションサイズを80byteとする。以上のような計算の方法はどうでしょうか。他に計算方法がありましたら教えてください。 よろしくお願いします。

(回答2)
私の使った経験のあるFRADではレガシー・データのフラグメンテーションはリンクの速度に応じて、FRADが自動的に行うため自分でフラグメンテーション・サイズを算出したことがありません。したがって、的確なことは言えませんが、フラグメント・サイズをデータに残された帯域から決めるというのは一つのアイデアかと思います。

ただ、残された帯域でサイズを決めてもデータが2つ以上続けて送出されると音声パケットの間隔は20ミリ秒を超えてしまいます。たぶんFRADで適切な優先制御がされているので大丈夫なのでしょう。

レガシー・データや音声はFRADによってフレームへのパッキングの仕方や取り出し方が独自のため、送信側のFRADと受信側のFRADは同一機種になります。また、公衆フレームリレーではPVC単位で課金されるため、音声とレガシー・データは1本のPVCで扱えるようになっているのが一般的です。送受信とも同一のFRADなんですから、リンクの速度に応じてフラグメント長を変えるのも自動的にやってくれるのがあたり前と思っていましたが、ユーザ指定が必要なものもあるのですね。
どうしてもユーザがフラグメントを意識せねばならないのは、図のようにA支店のルータのデータがフレームリレー網を通じてFRAD配下のルータと通信する場合です。ここではルータのデータに対してFRADはフラグメント出来ません。長いIPデータが音声に影響を与えないようにするにはルータでフラグメントする必要があります。

経験的に10ミリ秒程度で伝送できるフラグメント長にすれば問題ありません。64Kの回線なら、64000ビット×0.01=640ビット=80バイトです。ただし、フレームリレー網が音声を優先制御できなければNGです。したがって公衆フレームリレーで図のようなネットワークを構成するのは無理があります。



ホームページへ