JP2001285342A

JP2001285342A - 音声呼管理制御方法およびそのためのゲートウェイ装置

Info

Publication number: JP2001285342A
Application number: JP2000099665A
Authority: JP
Inventors: 雄二 ▲高▼橋; Yuji Takahashi
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2000-03-31
Filing date: 2000-03-31
Publication date: 2001-10-12
Anticipated expiration: 2020-03-31
Also published as: US6950425B2; JP4410907B2; US20010036190A1

Abstract

(57)【要約】【課題】音声系とデータ系を統合したＩＰネットワー
クにおいて、通話の開始から、リアルタイム性や一定の
通話品質が保てないような通話状態に陥ってしまうこと
を未燃に防止し、エンドユーザに快適な通話サービスを
提供する。【解決手段】入力されるパケットが音声呼パケットか
否かを識別するステップＳ１１と、音声呼パケットであ
ると識別されたとき、伝送パス１０が有する空き通信帯
域と当該音声呼パケットの所要帯域とに基づき、当該音
声呼パケットが伝送パス１０を通過可能か否かの判定を
行うステップＳ１２と、通過可能と判定されたときの
み、当該音声呼パケットを転送する第３ステップＳ１３
と、を有する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、音声呼管理制御方
法およびその方法に用いるゲートウェイ装置に関する。
従来の音声系ネットワークにおける通信においては、特
定の回線交換経路を介して音声情報のやりとりが行われ
ている。いわゆる電話交換網がその代表例である。

【０００２】このような通信は、音声のようにリアルタ
イム性が必要とされる用途には最適な方法であると共
に、通話品質ということが重要視される場合に有効な方
法である。一方、上記電話交換網のような音声系ネット
ワークとは別の形態のネットワークとして、インターネ
ットやイントラネット等に代表されるデータ系ネットワ
ークがある。このデータ系ネットワークにおける通信
は、上記音声系ネットワークとは反対に、いかに多量の
データを伝送するかということと、いかに伝送ルートの
最適化ならびに効率化を図るかということを重要視する
場合に有効な方法である。この方法に基づくネットワー
クとして最も広く利用されているのがＩｎｔｅｒｎｅｔ
Ｐｒｏｔｏｃｏｌ（ＩＰ）ネットワークである。

【０００３】これまで、上記音声系ネットワークとデー
タ系ネットワークとはそれぞれ独立の通信方式のもとで
運用されてきたが、近年これらの通信方式を融合させる
技術が次々と確立し始めてきている。例えば、Ｖｏｉｃ
ｅｏｖｅｒＦＲ（ＶｏＦＲ）、Ｖｏｉｃｅｏｖｅ
ｒＡＴＭ（ＶｏＡＴＭ）、ＶｏｉｃｅｏｖｅｒＩＰ
（ＶｏＩＰ）等が、その融合技術としてよく知られてい
る。そしてこの中でもとりわけＶｏＩＰ技術が注目を浴
びている。

【０００４】その理由は、第１に、パソコン（ＰＣ）と
アプリケーションソフトウェアが広く普及してきたこと
と、そのＰＣとアプリケーションソフトウェアを使った
インターネットが普及したことに起因してＩＰネットワ
ークの環境が充実してきたこと、第２に、そのＩＰネッ
トワークによるデータと音声の統合効果により、通信コ
ストが大幅に低減したこと、を挙げることができる。

【０００５】かくして、ＶｏＩＰ技術を基盤としたいわ
ゆる統合ネットワークの構築が一層加速しているのが現
状である。本発明はかかる状況のもとで、ＩＰネットワ
ークに応用して特に有効な、音声呼管理制御方法につい
て述べる。

【０００６】

【従来の技術】図１４の（ａ）は一般的な音声系ネット
ワークのシステム構成を、（ｂ）は一般的なデータ系ネ
ットワークのシステム構成をそれぞれ示す図である。本
図の、一般的な音声系ネットワーク（ａ）では、配下に
電話機１（＃１）を有するＰＢＸ２（＃１）と、同じく
配下に電話機１（＃２）を有するＰＢＸ２（＃２）と
が、公衆網３または専用線網４を介して、接続し、電話
機１（＃１）と電話機１（＃２）との間で音声通話を行
う。

【０００７】一方、本図の、一般的なデータ系ネットワ
ーク（ｂ）では、配下にパソコン（ＰＣ）５を有する伝
送装置６（＃１）と、配下にホスト８を有する伝送装置
６（＃２）とが、専用線網７を介して、接続し、パソコ
ン（ＰＣ）５とホスト８との間でデータ通信を行う。こ
のように、従来は、音声系ネットワーク（電話交換網）
と、データ系ネットワーク（ＩＰネットワーク）とが２
分化して別々に存在していた。

【０００８】ところが既述したＶｏＩＰ技術の進展に伴
って、音声情報をＩＰパケットに乗せて伝送する技術が
発展し、ここに、２分化された上記の音声系およびデー
タ系のネットワークは、一つに統合され、広く統合ネッ
トワークが構築されるに至った。図１５はＶｏＩＰ技術
を基盤とした、一般的なＩＰネットワークの一構成例を
示す図である。なお全図を通じて、同様の構成要素には
同一の参照番号または記号を付して示す。

【０００９】本図において、１１＃１は一方の幹線系
（例えば東京地区本社）、１１＃２は他方の幹線系（例
えば大阪地区本社）であり、これらの幹線系１１＃１お
よび１１＃２はそれぞれのゲートウェイ装置（ＧＷ）１
２＃１および１２＃２を介して、大容量の専用線１４に
よって結ばれる。一方の幹線系１１＃１とその配下の各
支線系１６（＃１，＃２…）とは、それぞれのゲートウ
ェイ装置（ＧＷ）１２＃１および１７を介して、専用線
１５＃１によって結ばれる。

【００１０】同様に、他方の幹線系１１＃２とその配下
の各支線系１６（…＃９，＃１０）とは、それぞれのゲ
ートウェイ装置（ＧＷ）１２＃２および１７を介して、
専用線１５＃２によって結ばれる。幹線系１１＃１内
は、前述した、電話機１＃１を有するＰＢＸ２＃１と、
ＰＣ５＃１と、ゲートウェイ装置（ＧＷ）１２＃１と
が、ＬＡＮ１３＃１によって結ばれている。

【００１１】幹線系１１＃２内も同様に、前述した、電
話機１＃２を有するＰＢＸ２＃２と、ＰＣ５＃２と、ゲ
ートウェイ装置（ＧＷ）１２＃２とが、ＬＡＮ１３＃２
によって結ばれている。このような幹線系１１＃１，＃
２の構成は、基本的に各支線系１６（＃１，＃２…＃
９，＃１０）についても同様であり、各ゲートウェイ装
置（ＧＷ）１７と、ＰＢＸ１８と、ＰＣ１９とが、ＬＡ
Ｎ（点線で示す）によって結ばれる。

【００１２】図１５に一構成例を示す、音声系とデータ
系とをＶｏＩＰ技術により統合したＩＰネットワークに
おいて、本発明に係る音声呼管理制御方法と密接な関連
を有するのは、幹線系１１のゲートウェイ装置（ＧＷ）
１２であり、また、支線系１６のゲートウェイ装置（Ｇ
Ｗ）１７である。なお、以下の説明は、幹線系のゲート
ウェイ装置に主として着目して行うが、支線系のゲート
ウェイ装置も同様に考えることができる。

【００１３】図１６は一般的なゲートウェイ装置の一構
成例を示す図である。従来の一般的なゲートウェイ装置
２０は、ＬＡＮ（１３）を制御するためのＬＡＮ制御部
２１と、相手方のゲートウェイ装置との間で専用線１４
によるサービスを受けるための回線制御を行うＷＡＮ制
御部２３と、プログラムを含む所要の各種データを格納
するメモリ部２４と、種々のサービスメニューを提示し
たり各種障害情報を表示するディスプレイ／ＬＥＤ部２
５と、ゲートウェイ装置２０に対する各種パラメータ
（局データ等）が、例えばＲＳ２３２Ｃのポートを介し
て外部ＰＣより設定される外部Ｉ／Ｆ（インタフェー
ス）部２６と、共通バス２７を介して装置２０全体の制
御を司る、ＣＰＵを含む制御部２２とからなる。

【００１４】

【発明が解決しようとする課題】上記ゲートウェイ装置
２０の制御のもとで、専用線１４および相手方ゲートウ
ェイ装置を介して、例えば、電話機１＃１および電話機
１＃２の間で通話を行っている場合、音声呼パケットの
遅延やパケットロスに起因して、音声が遅れて到達した
り、会話が途切れ途切れになったりして、既述したリア
ルタイム性や一定の通話品質が保てなくなり、正常な会
話状態が成立しない、という問題が生じている。

【００１５】通常、統合ネットワークにおいては、伝送
路をいかに効率的に使用するかを主眼において技術革新
がなされてきており、一例としてはＲＳＶＰ（ＩｎｔＳ
ｅｒｖ）、ＤｉｆｆＳｅｒｖなる帯域確保技術により、
ＩＰネットワークにおける通信状態の確保を行ってい
る。ところが一方、実際にはネットワーク環境によって
は、上記の帯域確保技術が使えない場合も数多く存在す
る。これは、ＩＰネットワーク内にある全ての、ルータ
等を含むゲートウェイ装置間でその帯域確保機能を持っ
ていなくてはならず、インターネット等の場合において
は、どこでどのように音声パケットがルーティングされ
て行くかわからないため、結局は、上記の問題が発生し
てしまう。

【００１６】また、上記のＶｏＩＰ技術をもとにした通
信においては、呼の管理を行うためのＧａｔｅＫｅｅｐ
ｅｒ（図１５のＧＫ参照）を経由して通信を行う場合が
あるが、音声呼のみの管理という観点からは、ＩＰネッ
トワーク状態を監視することができるが、データ呼の管
理まで管理しているものはあまりないし、また例えあっ
たとしても、上記Ｇａｔｅｋｅｅｐｅｒを用いて通信を
行うことが標準規格上必須とはなっていないため、結局
は、上記に示す問題が発生することになる。

【００１７】したがって本発明は上記問題点に鑑み、通
話のリアルタイム性と一定の通話品質とを常に保つこと
ができるようにした音声呼管理制御方法と、その方法を
実施するためのゲートウェイ装置とを提供することを目
的とするものである。

【００１８】

【課題を解決するための手段】ＶｏＩＰ技術を基盤とす
る音声系とデータ系の統合ネットワークにおいて、しば
しば音声呼パケットの遅延やパケットロスに起因して、
通話のリアルタイム性や一定の通話品質が保てなくなる
場合がしばしば発生し、その原因について分析したとこ
ろ次のような現象が明らかになった。

【００１９】統合ネットワーク内のあるゲートウェイ装
置１２＃１から他の対向ゲートウェイ装置１２＃２に音
声呼パケットを伝送する場合、連続する２つの手順を必
要とする。第１の手順はシグナリング情報をなす音声呼
パケットを送信する手順であり、通信確立のための手順
である。これにより伝送パスが張られると、次に第２の
手順が開始する。この手順は、その伝送パスを介して、
本来の音声情報をなす音声呼パケットを送信する手順で
あり、ここに会話状態が開始する。

【００２０】上記の第１および第２の手順は、上記伝送
パスが有する空き通信帯域に比べて上記音声呼パケット
の所要帯域が少ない場合には、共に成立し、問題なく上
記会話状態に達しその会話状態を正常に維持できる。逆
に、上記の第１および第２の手順は、上記の空き通信帯
域に比べて上記の音声呼パケットの所要帯域が多い場合
には、共に成立せず、上記伝送パスは張れず、上記会話
状態にも到達し得ない。

【００２１】問題は、上記第１の手順は成立しても、上
記第２の手順は成立しない場合がある、ということであ
る。この原因は、上記シグナリング情報をなす音声呼パ
ケットの所要帯域と上記音声情報をなす音声呼パケット
との間のアンバランスにある。すなわち、音声情報のパ
ケット伝送に要する所要帯域に比べてシグナリング情報
のパケット伝送に要する所要帯域は少ない。経験的に
は、これらの所要帯域の比は、１．５〜２対１である。

【００２２】そうすると、これらの所要帯域の差によ
り、上記第１の手順は成立しても上記第２の手順は不成
立ということが起こり得る。このような場合、通信確立
手順を通じて、相手先にシグナリング情報が届き、その
後の接続ネゴシエーションさえ完了してしまえば、通信
は確立し、通話状態にまで達する。この場合は、空き通
信帯域に余裕はないとは言え、所要帯域の少ないシグナ
リング情報によって通信状態にまでは達し得ただけであ
り、その後の、所要帯域の多い音声情報にとっては最早
通信帯域は不十分であり、結局、正常な会話状態は維持
できないことになる。この結果、上記のリアルタイム性
や一定の通話品質が失なわれてしまうことになる。本発
明は上述した分析結果に着眼してなされたものである。

【００２３】図１は本発明に係る方法の基本ステップを
示す図である。音声系とデータ系の統合ネットワークに
おける、本発明に基づく音声呼管理制御方法は、図１に
示す第１、第２および第３ステップ（Ｓ１１，Ｓ１２，
Ｓ１３）からなる。第１ステップＳ１１：前記統合ネットワーク内の第１ゲ
ートウェイ装置１２＃１に入力されるパケットが音声呼
パケットか否かを識別する。

【００２４】第２ステップＳ１２：第１ステップＳ１１
において、音声呼パケットであると識別されたとき、対
向する第２ゲートウェイ装置１２＃２との間の伝送パス
が有する空き通信帯域と当該音声呼パケットの所要帯域
とに基づき、当該音声呼パケットがその伝送パスを通過
可能か否かの判定を行う。第３ステップＳ１３：通過可能と判定されたときのみ、
当該音声呼パケットを前記第２ゲートウェイ装置に転送
する。

【００２５】図２は本発明に係るゲートウェイ装置の基
本構成図である。上述した図１のステップＳ１１〜Ｓ１
３は、図２のゲートウェイ装置３０によって、実施可能
である。図２を参照すると、音声系のデータ系の統合ネ
ットワーク内の、本発明に係るゲートウェイ装置３０
は、少なくとも、図示する識別手段３１と判定手段３２
とを有している。好ましくは、さらにメモリ手段３３を
有してなる。なお、図２のゲートウェイ装置３０は、図
１６のゲートウェイ装置２０に対応するが、図２では、
本発明に特徴的な手段（３１，３２，３３）のみを明示
する。これら識別手段３１および判定手段３２は、図１
６の制御部２２内にソフトウェアにより形成することが
できる。また、メモリ手段３３は、図１６のメモリ部２
４として形成することができる。

【００２６】具体的には、識別手段３１は、ゲートウェ
イ装置１２＃１に入力されるパケットが音声呼パケット
か否かを識別する。また、判定手段３２は、識別手段３
１において音声呼パケットであると識別されたとき、対
向する他のゲートウェイ装置１２＃２との間の伝送パス
が有する通信帯域と当該音声呼パケットの所要帯域とに
基づき、当該音声呼パケットが該伝送パスを通過可能か
否かの判定を行う。

【００２７】さらにまた上記のメモリ手段３３は、識別
手段３１による識別または判定手段３２による判定を行
うために参照される所定のパラメータを保持する。した
がって再び上記図１を参照すると、第１ゲートウェイ装
置１２＃１内のメモリ手段３３に保持された上記所定の
パラメータを参照して、第１または第２ステップ（Ｓ
１，Ｓ１２）を実行することになる。

【００２８】

【発明の実施の形態】図３は本発明が適用される統合ネ
ットワークの一構成例を示す図である。ただし図１５に
示したＩＰネットワークの構成とほぼ同じである。図１
５と相違するのは、第１ゲートウェイ装置（ＧＷ）１２
＃１と第２ゲートウェイ装置（ＧＷ）１２＃２との間の
専用線１４の部分を、図解的に描き改めたことである。

【００２９】すなわち、専用線１４上で形成される伝送
パスを参照番号１０としてパイプ（通信帯域）で表し、
このパイプを占有しているデータの部分（音声系とデー
タ系の双方を含む）をハッチングを付して表す。本図の
例では、最大許容通信帯域を全て使い切っておらず、空
き通信帯域ＡＢ（ＡｖａｉｌａｂｌｅＢａｎｄ）が存
在している。

【００３０】新たに音声呼パケットが幹線系１１＃１
（あるいは該幹線系１１＃１の配下にある支線系１６）
内において発生したとすると、ゲートウェイ装置（Ｇ
Ｗ）１１＃１は、まず、その入力されたパケットが音声
呼パケットであるか否か識別する。この場合該パケット
は音声呼パケットであるから、これを識別する。この識
別後、ゲートウェイ装置（ＧＷ）１１＃１は、最初に入
力されてくるシグナリング情報（図中の〈１〉）が、伝
送パス１０の空き通信帯域ＡＢを通過できるか否か判定
する。この判定により、通過可能と分かると、次に入力
されてくる音声情報が同様にその空き通信帯域ＡＢを通
過できるか否か判定する。この判定により通過可能と分
かると、両ゲートウェイ装置（１１＃１，１１＃２）間
に通話パスが確立され、会話状態に入る。

【００３１】図４はゲートウェイ装置３０の具体的構成
例を示す図である。本図に示すとおり、その基本ブロッ
ク構成は、図１６に示した構成と変わらないが、主とし
て制御部２２については、その内部構成が変更されてい
る。すなわち、識別部４１および解析部４２が、既述の
識別手段３１として、形成され、伝送パス帯域管理部４
３が、既述の判定手段３２として、形成される。また、
メモリ部２４にはさらにパラメータ情報ならびにルーテ
ィング情報が保持されて、既述のメモリ手段３３とな
る。

【００３２】図５は本発明のゲートウェイ装置により実
行される主要なステップとこれに関連するステップとを
示すフローチャートである。本図において、ステップＳ
１１，Ｓ１２およびＳ１３は、図１に示したＳ１１，Ｓ
１２およびＳ１３に対応する。ステップＳ２１：ユーザが幹線系内（あるいは支線系
内）の電話機１より、相手先の電話番号をダイヤルした
ものとする。

【００３３】ステップＳ２２：そのダイヤル情報は、対
応するＰＢＸ２（もしくはゲートウェイ装置３０の入力
段）においてＩＰパケット化される。ステップＳ２３：他のユーザがパソコン（ＰＣ）５よ
り、ホスト８に向けてデータを転送しているものとす
る。このデータもＩＰパケット化されている。上記ステ
ップにより、ゲートウェイ装置３０に入力されたＩＰパ
ケットは、まず、ステップＳ２４に入る。

【００３４】ステップＳ２４：図４の識別部４１におい
て、その入力されたＩＰパケットが音声呼パケットか否
か判定する。このステップＳ２４においては、メモリ部
２４内に保持されたパラメータ情報を参照する。この
“パラメータ”は、入力されたパケットのヘッダ部分に
記述される情報要素であり、当該パケットの属性等を示
す。最も大事なのは、当該パケットが音声呼パケットか
否かを示す情報要素である。

【００３５】具体的には、上記パラメータは、ゲートウ
ェイ装置３０に入力されるパケットの、ＩＰソースアド
レス、ＴＣＰ／ＩＰ、ＲＴＰ、ＵＤＰの各ポート番号、
およびＴＯＳ値の少なくとも１つである。このパラメー
タに基づき、ステップＳ２４を実行する。メモリ部２４
は、好ましくは、これら全てのパラメータを保持する。
ここに、ＴＣＰ／ＩＰは、Ｔｒａｎｓｍｉｓｓｉｏｎ
ＣｏｎｔｒｏｌＰｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ
Ｐｒｏｔｏｃｏｌ、ＲＴＰは、Ｒｅａｌ−ｔｉｍｅ
ＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ、ＵＤＰは、Ｕｓ
ｅｒＤａｔａｇｒａｍＰｒｏｔｏｃｏｌ、ＴＯＳ
は、ＴｉｍｅＯｆＳｅｒｖｉｃｅであり、いずれも
周知である。

【００３６】メモリ部２４内のパラメータ情報として
は、音声呼パケットであることを表示する特定のＩＰソ
ースアドレスやＴＣＰ／ＩＰ、ＲＴＰ等が記述されてお
り、これらのパラメータのいずれかに一致する入力パケ
ットがあれば、これは音声呼パケットであると識別され
る。図５において、ステップＳ２５：ステップＳ２４により識別された、シ
グナリング情報をなす音声呼パケットの所要帯域に基づ
き、このシグナリング情報が伝送パス１０を通過可能か
否かの判定を行う。

【００３７】ステップＳ２６：通過可能と判定される
と、音声情報をなす音声呼パケットの所要帯域に基づ
き、この音声情報が伝送パス１０を通過可能か否かの判
定を行う。ステップＳ２７：上記ステップＳ２５とＳ２６の結果が
共にＹｅｓであると、通話状態となり、このときは、リ
アルタイム性と一定の通話品質とを保った会話が行え
る。

【００３８】再び上記ステップＳ２４（識別）について
もう少し詳しく考察すると、その識別を実行する際の上
述のパラメータを、メモリ部２４内に保持するために事
前入力するが、この入力は外部インタフェース部２６か
ら行うことができる。しかしながら、入力される音声呼
パケットの全てが、そのメモリ部２４内のパラメータの
いずれかと必ず一致するとは限らない。すなわち、メモ
リ部２４に未登録のパラメータもあり得る。このような
未登録のパラメータを有する音声呼パケットは、その次
に来るステップＳ２５およびＳ２６による判定が受けら
れず、本発明による効果を得ることができない。

【００３９】そこで、メモリ部２４に未登録のパラメー
タを有するパケットが出現したときは、これは解析部４
２にて解析し、音声呼パケットを表すものであることが
判明したらメモリ部２４にそのパラメータを登録し、パ
ラメータ情報を増やす。すなわち、識別手段３１をなす
その解析部４２は、上記の識別を実行する際のパラメー
タを、音声呼パケットがゲートウェイ装置３０を通過す
るときにその音声呼パケットの情報要素を解析すること
により割り出し、これをメモリ手段をなすメモリ部２４
内に蓄積して保持する。

【００４０】これにより当該音声呼パケットが次回ゲー
トウェイ装置３０に入力されるときには、ステップＳ２
４による識別で音声呼パケットであるものと認定され、
引き続く、ステップＳ２５およびＳ２６による判定を受
けることができる。解析部４２により解析される上記の
情報要素としては、例えば、当該音声呼パケットの「パ
ケット長」があり、所定のパケット長であることを検出
して、メモリ部２４に蓄積されるパラメータとしてさら
に加える。

【００４１】また上記ステップＳ２６について考察する
と、音声情報が伝送パスを通過可能か否かの判定に用い
るパラメータとして、例えば、当該音声呼パケットの通
信スループット情報を用いることができ、このパラメー
タに基づき該ステップＳ２６を実行することができる。
図６は図５のステップＳ２６の変形態様を示す図であ
る。

【００４２】本図に示すとおり、ステップＳ２６での判
定は、ステップＳ３１：音声呼パケットの伝送パス１０への通
過を許可するか、ステップＳ３２：その通過を制限するか、または、ステップＳ３３：その通過許可の待ち受けとするか、の
いずれかの判定である。

【００４３】上記ステップＳ３１とＳ３２はそれぞれ、
図５のステップＳ２７とＳ２８に相当するので、ステッ
プＳ３３が新たなステップである。このステップＳ３３
を利用して新たなサービスをユーザに提供することがで
きる。これを図７に示す。図７は図６のステップＳ３３
の応用例を示す図である。図７によれば、通信予約のス
テップＳ４１をさらに含み、ステップＳ２６での判定
が、伝送パス１０への通過許可の待ち受けとする判定で
あるとき（ステップＳ３３）、その通信予約を行い、該
通過許可の発行（ステップＳ２６とＹｅｓ）と同時に当
該音声呼パケットの送信を行う（ステップＳ４２）。

【００４４】ユーザはトラヒックの輻輳が終了したら即
座に発呼したい場合がある。このような要求に応えるた
めに通信予約を可能とし、この予約があったときは、ス
テップＳ２６で通過許可が出次第、待ちとなっていた音
声呼パケットを送信開始することができる。なおこの予
約は、ユーザからの操作によりゲートウェイ装置３０に
対して行うことができる。予約の有無は、メモリ部２４
に一時的に記録しておけばよい。

【００４５】以上、本発明に係る音声呼管理制御方法と
ゲートウェイ装置について述べてきたが、最後に、上述
の説明に関連する詳細例について述べておく。図８はシ
グナリング情報についてその詳細例を示す図である。す
なわちシグナリング情報伝送時のＩＰパケット（音声呼
パケット）のフィールドを一例として示す図である。

【００４６】図中のＩＰは最下位のレイヤ、ＴＣＰはそ
の上のレイヤ、ＵＤＰはさらにその上のレイヤにそれぞ
れ対応する。これをさらに詳しく図９〜１１において示
す。図９はＩＰヘッダフィールドの詳細例を示す図であ
り、図１０はＴＣＰヘッダフィールドの詳細例を示す図
であり、図１１はＵＤＰヘッダフィールドの詳細例を示
す図である。

【００４７】これら図９〜１１において、左下がりハッ
チングの部分は、既述のパラメータのうち、識別部４１
（図４）による識別（図５のステップＳ２４参照）のた
めに特に有用な情報要素であり、これを見ることにより
入力されたパケットが音声呼パケットか否かを識別でき
る。一方、右下がりハッチングの部分は、既述のパラメ
ータのうち、解析部４２（図４）による解析に用いるこ
とのできるパラメータであり、そのパケット長（“トー
タル長”）を見て、音声呼パケットであると解析でき
る。そして当該音声呼パケットのヘッダから得た情報要
素、ＩＰソースアドレス、ＴＣＰ／ＩＰ…等をメモリ部
２４に登録することができる。このトータル長は例えば
音声呼パケットの場合８０byteである。

【００４８】図１２は図４内でのパケットの動きと処理
を図解的に表す図である。本図において、（１）〜
（５）は処理の流れを示す。また簡単のため３つのパケ
ットＡ，Ｂ，Ｃのみを示す。先ずは、ＬＡＮ制御部２１
へ入力されＩＰパケットのＩＰソースアドレス／ポート
番号／ＴＯＳ値等を識別部４１で見て、音声呼パケット
かどうか識別を行う。

【００４９】例えば、メモリ部２４からそれらのパラメ
ータを参照し、その比較を行い、音声呼パケットと判断
する。このとき、既にメモリ部２４にパラメータが登録
済の場合は何も処理しないが、新規の音声呼パケットで
あれば解析部４２により、既述のパケット長を調べて、
そのＩＰソースアドレス／ポート番号／ＴＯＳ値をメモ
リ部２４に登録し、累積する。

【００５０】図１２の伝送パス帯域管理部４３について
見ると、メモリ部２４に対しては事前にＩＰアドレス等
と送付先との関係等を示すルーティング情報を格納して
おく必要がある（図４の“ルーティング情報”）。ま
た、音声呼パケットのフィールド帯域は予め、圧縮方式
等から一義的にその容量が決まっているので、このこと
を利用して、予めルーティングテーブルを作るとき、音
声呼という観点から所要帯域はこれだけ必要になるとい
う情報も入れておくことにより、１つの音声呼の所要帯
域は決まってくる。音声呼の通信であれば、そのパケッ
ト個数により伝送パス使用帯域は決定できる。また、デ
ータ呼の場合は、通信中のスループットを測定すること
により、伝送パス使用帯域は分かる。

【００５１】以上の構成のもとで、図３に示す統合ネッ
トワーク内で実現される通信シーケンスは図１３のよう
になる。図１３は図３において実現される通信シーケン
スを表す図である。本図では、上半分に「通信可」の場
合のシーケンスを、下半分に「通信不可」の場合のシー
ケンスをそれぞれ示す。

【００５２】支線系１６よりＰＢＸ＃ａ１を通してシグ
ナリング（発呼）が発生すると、ＧＷ＃１内で、音声呼
パケットの識別や伝送パスを通過可能か否かの判定が行
われ、その判定の結果、通過可能ということであれば
（帯域ＯＫ）、その旨のシグナリングをＰＢＸ＃ａ１
（応答）に返す。これと共に、相手方ＰＢＸ＃ｂ１０へ
シグナリング（発呼）を送り込む。相手方が着呼する
と、その旨のシグナリング（応答）を、ＲＢＴ（Ｒｉｎ
ｇＢａｃｋＴｏｎｅ）として、ＰＢＸ＃ａ１に返
す。ここで音声通話が開始する。このときの会話におい
ては、リアルタイム性と一定の通話品質が確保される。

【００５３】本図の後半では、伝送パスを通過すること
が可能でないとの判定が出され、シグナリング（応答）
として、帯域ＮＧを伝えるＢＴ（ＢｕｓｙＴｏｎｅ）
が当該ユーザに与えられる。ユーザはトラヒックの輻輳
が回避された後、再発呼する。

【００５４】

【発明の効果】以上説明したように本発明によれば、ト
ラヒックの輻輳時において、通話を開始するときから、
リアルタイム性や一定の通話品質を失うような劣悪な通
話状態に陥ってしまうようなことが未燃に防止され、Ｉ
Ｐネットワークのエンドユーザに快適な通話サービスを
提供することができる。また必要であれば、そのような
劣悪な通話状態から脱したことをゲートウェイ装置で検
出して、保留していた発呼動作を自動的に再スタートさ
せることもできる。

【図面の簡単な説明】

【図１】本発明に係る方法の基本ステップを示す図であ
る。

【図２】本発明に係るゲートウェイ装置の基本構成図で
ある。

【図３】本発明が適用される統合ネットワークの一構成
例を示す図である。

【図４】ゲートウェイ装置３０の具体的構成例を示す図
である。

【図５】本発明のゲートウェイ装置により実行される主
要なステップとこれに関連するステップとを示すフロー
チャートである。

【図６】図５のステップＳ２６の変形態様を示す図であ
る。

【図７】図６のステップＳ３３の応用例を示す図であ
る。

【図８】シグナリング情報についてその詳細例を示す図
である。

【図９】ＩＰヘッダフィールドの詳細例を示す図であ
る。

【図１０】ＴＣＰヘッダフィールドの詳細例を示す図で
ある。

【図１１】ＵＤＰヘッダフィールドの詳細例を示す図で
ある。

【図１２】図４内でのパケットの動きと処理を図解的に
表す図である。

【図１３】図３において実現される通信シーケンスを表
す図である。

【図１４】（ａ）は一般的な音声系ネットワークのシス
テム構成を、（ｂ）は一般的なデータ系ネットワークの
システム構成をそれぞれ示す図である。

【図１５】ＶｏＩＰ技術を基盤とした、一般的なＩＰネ
ットワークの一構成例を示す図である。

【図１６】一般的なゲートウェイ装置の一構成例を示す
図である。

【符号の説明】

１…電話機５…パソコン（ＰＣ）６…伝送装置７…専用線網８…ホスト１０…伝送パス１１…幹線系１２…ゲートウェイ装置（ＧＷ）１３…ＬＡＮ１４…専用線１５…専用線１６…支線系（＃１，＃２，＃９，＃１０）１７…ゲートウェイ装置（ＧＷ）１８…ＰＢＸ１９…ＰＣ２０…ゲートウェイ装置２１…ＬＡＮ制御部２２…制御部２３…ＷＡＮ制御部２４…メモリ部２６…外部インタフェース部３０…ゲートウェイ装置３１…識別手段３２…判定手段３３…メモリ手段４１…識別部４２…解析部４３…伝送パス帯域管理部ＡＢ…空き通信帯域

Claims

【特許請求の範囲】

【請求項１】音声系とデータ系の統合ネットワークに
おける音声呼管理制御方法であって、前記統合ネットワーク内の第１ゲートウェイ装置に入力
されるパケットが音声呼パケットか否かを識別する第１
ステップと、前記第１ステップにおいて、音声呼パケットであると識
別されたとき、対向する第２ゲートウェイ装置との間の
伝送パスが有する空き通信帯域と当該音声呼パケットの
所要帯域とに基づき、当該音声呼パケットが該伝送パス
を通過可能か否かの判定を行う第２ステップと、通過可能と判定されたときのみ、当該音声呼パケットを
前記第２ゲートウェイ装置に転送する第３ステップと、
を有することを特徴とする音声呼管理制御方法。
【請求項２】前記第１ゲートウェイ装置内に保持され
た所定のパラメータを参照して、前記第１または第２ス
テップを実行する請求項１に記載の音声呼管理制御方
法。
【請求項３】前記パラメータが、前記第１ゲートウェイ装置に入力されるパケットの、Ｉ
Ｐソースアドレス、ＴＣＰ／ＩＰ、ＲＴＰ、ＵＤＰの各
ポート番号、およびＴＯＳ値の少なくとも１つであっ
て、当該パラメータに基づき、前記第１ステップを実行
する請求項２に記載の音声呼管理制御方法。
【請求項４】前記パラメータが、当該音声呼パケット
の通信スループット情報であり、該パラメータに基づき
前記第２ステップを実行する請求項２に記載の音声呼管
理制御方法。
【請求項５】前記第１ステップを実行する際の前記パ
ラメータを、前記第１ゲートウェイ装置内に事前入力し
て保持する請求項２に記載の音声呼管理制御方法。
【請求項６】前記第１ステップを実行する際の前記パ
ラメータを、前記音声呼パケットが前記第１ゲートウェ
イ装置を通過するときにその音声呼パケットの情報要素
を解析することにより割り出し、これを前記第１ゲート
ウェイ装置内に蓄積して保持する請求項２に記載の音声
呼管理制御方法。
【請求項７】前記情報要素が、当該音声呼パケットの
パケット長であり、所定のパケット長であることを検出
して、蓄積される前記パラメータに加える請求項６に記
載の音声呼管理制御方法。
【請求項８】前記第２ステップは、前記第１ステップ
により識別された、シグナリング情報をなす音声呼パケ
ットの所要帯域に基づき、該シグナリング情報が前記伝
送パスを通過可能か否かの判定をまず行うステップと、
通過可能と判定されると、音声情報をなす該音声呼パケ
ットの所要帯域に基づき、該音声情報が前記伝送パスを
通過可能か否かの判定を引き続き行うステップとからな
る請求項１に記載の音声呼管理制御方法。
【請求項９】前記第２ステップでの判定は、前記音声
呼パケットの前記伝送パスへの通過を許可するか、その
通過を制限するか、またはその通過許可の待ち受けとす
るか、のいずれかの判定である請求項１に記載の音声呼
管理制御方法。
【請求項１０】通信予約のステップをさらに含み、前
記第２ステップでの判定が、前記伝送パスへの通過許可
の待ち受けとする判定であるとき、その通信予約を行
い、該通過許可の発行と同時に当該音声呼パケットの送
信を行う請求項９に記載の音声呼管理制御方法。
【請求項１１】音声系とデータ系の統合ネットワーク
内のゲートウェイ装置において、前記ゲートウェイ装置に入力されるパケットが音声呼パ
ケットか否かを識別する識別手段と、前記識別手段において音声呼パケットであると識別され
たとき、対向する他のゲートウェイ装置との間の伝送パ
スが有する通信帯域と当該音声呼パケットの所要帯域と
に基づき、当該音声呼パケットが該伝送パスを通過可能
か否かの判定を行う判定手段と、を有することを特徴と
するゲートウェイ装置。
【請求項１２】前記識別手段による識別または前記判
定手段による判定を行うために参照される所定のパラメ
ータを保持するメモリ手段を有する請求項１１に記載の
ゲートウェイ装置。
【請求項１３】前記識別手段は、前記識別を実行する
際の前記パラメータを、前記音声呼パケットが該ゲート
ウェイ装置を通過するときにその音声呼パケットの情報
要素を解析することにより割り出し、これを前記メモリ
手段内に蓄積して保持する解析部を含む請求項１２に記
載のゲートウェイ装置。
【請求項１４】前記識別を実行する際の前記パラメー
タを、前記メモリ手段内に保持するために事前入力する
外部インタフェース部を備える請求項１２に記載のゲー
トウェイ装置。