「企業ネットワークの新構築技法」の読者から、次のような質問がE−MAIL(本の著者紹介欄に記載)で来ました。参考になるケースなのでご紹介します。FRADについて初めまして、私は東北のAと申します。(ご本人の了解の上、仮名にしました。)日経BP社の企業ネットワークの新構築技法を読ませてもらっています。最初は難しいと思いましたが、何人かのグループで読んでいると解ってきました。音声処理等はあまり他の本で書かれていないので非常に参考になりました。当社においてもFRADを導入してVOFRを実現したいと考えております。そこで、いくつか実験しましたが、うまくいかない部分がありましたので、教えていただければ幸いです。実験環境としては、下記の通りです。64kbpsQ)本社側からFTPをかけているときに、支店と通話しますと、支店側だけ音声が途切れます。(圧縮は8.3k)支店側からのFTPの場合は影響ありません。128kbpsから64kbpsに網内で速度変換する場合に問題になるのでしょうか。(回線はCIR=0)。DA64で実験したときは大丈夫でした。Q)また、通話状態が4回線になりますと、音声の途切れが発生します。用状況は45kbps程度です。−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−○Aさんの試験の良いところは専用線DA64K(デジタルアクセス64K)と公衆フレームリレー網という2つの環境を比較している点、FTP実行時の電話の音質チェックを下り(本社→支店)上り(支店→本社)の両方向でチェックしていることです。片方向のみチェックしても本ケースのように逆方向だけNGの場合があるため、両方向のチェックが不可欠なのです。○音声の途切れは音声フレームが破棄されて失われるために起こります。従って途切れの原因を知るためには何処で音声フレームが破棄されているか特定せねばなりません。フレームが回線の上で伝送されている最中に失われるのは伝送エラーが生じた場合ですが、これはデジタル回線を使っているため極めて少ないと言えます。フレームが破棄されるのはFRADやフレームリレー交換機の受信バッファ、送信バッファのオーバーフローが原因であることがほとんどです。○Aさんの試験環境をもう少し詳しくしたのが次の図です。○先ず、下のDA64Kでは問題なかったことから、このFRADが音声とファイル同時に伝送するとき音声を優先し、フレーム破棄や遅延を抑える基本的な機能は満たしていることが分かります。○ただし、LANの接続がFRADとは独立のルータで行われているのか、FRADに内蔵されているルータ機能で行われているのかはメールからは分かりません。内蔵ルータの場合は音声とTCP/IPのトラヒックは同一のPVCで扱われることが多く、外部ルータの場合は別々のPVCで扱われるのがふつうです。内蔵ルータを使って拠点数が10カ所を超える中大規模のネットワークを構築しようとすると、このケースでは触れられてない別の大きな問題が生じます。このページでは話が複雑になるので述べません。○さて、公衆フレームリレーを使ったとき本社から支店へFTPしていると支店側で音が途切れるのは何故か、という一つめの質問を考えましょう。公衆フレームリレーでは図のようにいくつかのフレームリレー交換機を経由してフレームが伝送されます。音声フレームが破棄されているバッファとしてはFRADやフレームリレー網内の交換機のバッファが候補になります。CIR=0の契約であり、網が輻輳していればかなり帯域は少なくなりますが、支店から本社へのFTP+電話は問題ないことからフレームリレー網は比較的すいている状態であると想定できます。○結論から言えば、音声フレームの破棄が起きている可能性が一番高いのは公衆フレームリレー網の支店を収容している交換機の64K回線への送信バッファです。本社FRADからFR網の支店収容交換機までは網がすいていれば、ほぼ128Kの速度でフレームが伝送されます。FTP+音声で目一杯128K流れていると想定できます。そこから先は64Kの回線しかありません。単位時間にバッファに流れ込むFTP+音声の半分しか回線に送出できないのです。このためバッファにためきれなくなったフレームが破棄されていると考えられます。○もし仮に公衆フレームリレー網の交換機が音声をデータに対して優先する機能を持っていれば音声フレームの破棄はかなり防げると思います。私が手がけた銀行等のプライベート・フレームリレー網ではきちんとした優先制御を行っているため、上記のような問題は起こっていません。○対策としては本社FRADから支店に流れ込むFTPの速度を64K以下に抑えること、つまりCIR=0とするとBe(エクセス・バースト)を64Kにし、帯域が空いていても128kまで許さないことが考えられます。公衆FR網でBeの指定ができるかどうか分かりません。○逆方向の支店から本社へのFTP+音声がOKな理由はもうおわかりですね?64Kの速度で流れてきたものが、128Kの回線に出ていくのですからバッファのオーバーフローは起こりようがないわけです。○次に64Kの回線でFTP+電話4チャネルを流すと音が途切れる、という現象です。これは送信側のFRADの送信バッファで音声フレームが落ちていると考えられます。FRADで優先制御をしてもチャネル数が増えて帯域が狭くなるとはけきれない音声フレームが出てきます。救急車は道路で優先されますが、渋滞したら救急車だって進めなくなるのと同じです。優先制御は万能ではないということです。○ただ、8.3k音声圧縮とすると64Kの回線で4チャネル程度で途切れが出るのではお使いのFRADの性能は良くありません。◎まとめこのケースから得られる教訓をまとめると次のようになります。�@専用線で問題なく使えても公衆フレームリレーでは音の途切れが生じることがある。�AVOFR+FTPのチェックは双方向で必要。�BFRADの性能によって良好な音質で伝送できる音声チャネル数は違う。�C音質を良くするには音声フレーム破棄の有無の確認、その量のモニターが必要。フレーム・ロスのモニターが出来るFRADと出来ないものがあるので要注意。出来ないものは使うべきではない。�D音声とデータを識別し、優先制御するFRADを使っても公衆フレームリレーでは音質が保てないことがある。音声とデータの区別も出来ず、優先制御もしないルータで出来上がっているインターネットでいい音質の電話が保てるでしょうか?このケースと同じ状況はインターネット電話でも当たり前に起こるのです。○VOFRに関するご意見・ご質問を歓迎します。明記してメールください。