間違いだらけのネットワーク作り(35)  98/07/18
「FRADによる無理な設計(その2)」
 

前回に続き、小型のFRADやルータを使ったデータ・音声統合ネットワークにおける「無理な設計」のチェックポイントについて説明します。

C本社の内線電話チャネル数、インタフェースは適正か?
私がコンペで実際に眼にしたM社製FRAD(メーカーはルータと呼んでいる)の提案を例にしましょう。そのネットワークは拠点数が約40、本社を中心としたスター状の構成で上図と似ています。ただし、30km以内の拠点が10カ所以上あるのにすべて公衆フレームリレー回線を使っていました。これはFRADの物理ポート数が少ないためデジタルアクセスを使ったのでは収容し難いのです。通信費用を安くするより、自社のFRADの都合の方が優先ということでしょうか?

本題に入ります。その提案において本社以外の各拠点には平均2チャネルの内線電話が収容されているのですが、本社側の内線チャネルは8本しかないのです。内線電話は本社と各拠点間で多く、独立した営業をしている拠点間は少ないのです。拠点側が合計80チャネルもの内線数があるのに、受けて立つ本社側が8本とは。内線電話のトラヒックの流れと量に適合したチャネル数になっていないのです。

仮に上図のとおり本社側20チャネルが適正だとします。PBXとFRAD間を接続するインタフェースがアナログだと図のように20本のケーブルで接続せねばならず、PBX側もFRAD側も物理ポート数が増えて機器費用が増大します。また、1台のFRADで収容できないと複数のFRADに分散されます。支店から本社の内線番号をダイアルすると、その時々において電話を中継する本社側FRADが変わることになります。どういう仕組みでFRADがそれを実現するのか確認する必要があります。

内線チャネル数が10チャネルを超えるような拠点ではアナログ・インタフェースは使うべきではありません。TTC2M(2メガビット/秒のデジタル・インタフェース)を使うべきです。これですと1本で30チャネルまで収容できます。

D内線電話の中継の仕組みは?
VOFRやVOATMでは内線電話の中継交換はフレームリレー/ATM交換機やFRADで行うのが原則です。
電話機→PBX→FRAD(音声を圧縮デジタル化)→FRAD、交換機で中継交換→受信側FRAD(音声をアナログ、または64Kデジタルに変換)→PBX→電話機、という流れです。受信側でアナログにするか、64KデジタルにするかはFRADとPBX間のインタフェースがアナログかTTC2Mかによります。

音声はデジタル/アナログ変換や圧縮/伸長を繰り返すと音質が劣化します。上記のように一度デジタル圧縮した音声をそのまま受信側に中継することで音質の劣化が防げるのです。最近のVOFR/VOATM製品ではSVC(通話の都度ダイアル番号に対応したフレームリレー/ATMのアドレスによってフレームリレー/ATMネットワーク内に通信チャネルを設定する)で中継するのが主流です。1本のSVCで内線電話が接続されます。

さて、先ほどのM社製FRADの提案の話にもどりましょう。その提案ではあきれたことに内線電話の交換をFRADではなく本社のPBXが行っていました。支店から支店に電話をかける場合、支店電話機→PBX→FRAD(音声圧縮デジタル化)→本社FRAD(音声をアナログに変換)→本社PBX(中継交換)→本社FRAD(音声を圧縮デジタル化)→相手支店FRAD(音声をアナログ変換)→PBX→電話機という流れになります。音声のデジタル/アナログ変換が2回行われるため音質が劣化します。

FRADの電話中継交換の能力が小さいと、多くの内線電話がある場合さばき切れません。PBXでの中継交換を使わざるを得なくなるのです。前回FRADの転送能力について述べましたが、電話の中継能力も大事なチェックポイントです。

E公衆フレームリレーのアクセス速度のギャップと音声のトギレ
前回述べたように公衆フレームリレーを使う場合、本社と公衆フレームリレー網間のアクセス速度は速くせざるを得ません。例えば上図で1Mとしましょう。支店側のアクセス速度は64kです。1Mと64Kの速度ギャップが音声のトギレの大きな要因になります。

本社と支店で電話をしている最中に、本社から支店にファイル転送をします。本社のアクセス回線がすいていると、音声とデータは1M近いスピードで公衆フレームリレー網内に送出されます。フレームリレー網内でふくそうが起こっていなければ支店のFRADが収容されている受信側のフレームリレー交換機まで高速で転送されます。

さて、受信側の交換機までは高速で転送されましたが、その先は64kの回線しかありません。高速道路の出口で渋滞が起こるのと同じ現象になります。高速道路ではクルマが止まるだけで道路から落っこちることはありませんが、交換機は渋滞してバッファが満杯になると容赦なくフレームを捨てます。データも音声も区別なく捨てられますから、音声はトギレます。

音声とデータのPVCを分けて、音声の帯域をCIRで確保する、といった対策が考えられます。しかし、気をつけてください。M社製FRADのように異なるPVC間での優先制御ができない製品があります。そうなると本社FRADから送出されるとき、音声がデータに対して優先されないため、送信側でトギレの原因が生じることになります。

公衆フレームリレーでの本社側と支店側のアクセス速度のギャップは、網内の転送遅延の並んで公衆フレームリレーでの音声のトギレの主因になります。公衆フレームリレーを使った電話とファイル転送を同時に行うデモがよくされていますが、アクセス速度が送信側と受信側で同じだったり、ギャップがごく小さい、ということはありませんか?そんな環境だとトギレが起きにくいのは当然です。
 
 
 
 

次回に続く

ホームページへ