JP2004312380A - 帯域管理システム - Google Patents

Abstract

【課題】帯域資源の利用効率を高めるとともに、通信の信頼性を高める。
【解決手段】所定の通信ネットワーク上で所定の単位信号を用いたリアルタイム通信を実行するために帯域管理を行う帯域管理システムにおいて、予め搭載してある第１の経路表と、単位信号が有する第１の宛先識別子をもとに、単位信号の経路を決定して中継処理を行う複数の第１の中継装置と、予め搭載してある第２の経路表と、リアルタイム通信の最終的な宛先を指定するために単位信号が有する第２の宛先識別子をもとに、単位信号の経路を決定して中継処理を行う複数の第２の中継装置とを備え、第２の中継装置は、通信ネットワークの構造上、リアルタイム通信の最終的な宛先までの経路が複数存在する場合、第２の経路表をもとに、いずれか１つの経路を選択し、その選択結果に応じて第１の宛先識別子を書き換える。
【選択図】 図１

Description

【０００１】
【発明の所属する技術分野】
本発明は帯域管理システムに関し、例えば、ＩＴＵ−Ｔ勧告Ｈ．３２３に準拠した環境などでＶｏＩＰ（Ｖｏｉｃｅ ｏｖｒｅ ＩＰ）による音声通信を行う場合などに適用して好適なものである。
【０００２】
【従来の技術】
ＩＴＵ−Ｔ勧告Ｈ．３２３に準拠したＩＰネットワークでＶｏＩＰによる音声通信を行う場合、そのＩＰネットワークにゲートキーパを設置すれば、ゲートキーパが提供する帯域管理機能を利用することができる。
【０００３】
ゲートキーパが提供する帯域管理機能は、ゲートキーパが備える帯域管理テーブルのその時点の内容に基づいて実行される。すなわち、ＶｏＩＰ端末（ＩＰ電話機など）等のエンドポイントがＡＲＱメッセージを送信してゲートキーパにアドミッションを要求してきたとき、帯域管理テーブルの内容が十分な帯域の余裕があることを示す場合には、そのアドミッションを許可し、反対に、十分な帯域の余裕がないことを示す場合には、そのアドミッションを拒否する。
【０００４】
アドミッションが許可されると、ＶｏＩＰ端末間で呼設定が行われ、音声データを収容したＩＰパケットが送受されるようになる。
【０００５】
また、ＩＴＵ−Ｔ勧告Ｈ．３２３に準拠したゲートキーパを用いた技術として、下記の特許文献１があげられる。
【０００６】
特許文献１では、ＲＳＶＰプロトコルを利用して、ゲートウエイ装置相互間や、ゲートウエイ装置と音声中継ルータの間における帯域予約を最適化して、通信品質を維持する方法が記載されている。
【０００７】
この特許文献１にはまた、同じ宛先と通信するための経路が複数存在し、各経路に異なるゲートウエイ装置が配置されている場合、いずれかのゲートウエイ装置が輻輳状態や、装置障害状態となり、正常な通信を行うことができなくなったときには、ゲートキーパが、ゲートウエイ装置の選択を切り替えて、新たな経路で呼接続を行う方法が記載されている。
【０００８】
【非特許文献１】
ＩＴＵ−Ｔ勧告Ｈ．３２３
【０００９】
【特許文献１】
特開２０００−２２４２３９
【００１０】
【発明が解決しようとする課題】
ところが、上述したゲートキーパはＩＰネットワークの帯域資源を直接、監視する手段を持たないため、前記帯域管理テーブルの内容は不完全なものとなる可能性がある。これは、ＩＰネットワーク内の多数のルータが備えたルーティングテーブルの内容を、ゲートキーパが知ることができないためである。
【００１１】
ルーティングテーブルとは、基本的に、宛先ＩＰアドレスとネクストホップの対応関係を登録したテーブルである。
【００１２】
ＩＰ電話機のユーザがＶｏＩＰによる音声通話を行おうとする場合、ＩＰ電話機を操作して宛先のユーザの電話番号（着信先電話番号）を入力する。しかしながらＩＰネットワーク上で通信端末（ＩＰ電話機はその一例）を識別するたに使用できる唯一の識別子はＩＰアドレスであるため、この着信先電話番号はＩＰアドレスに変換され、変換後のＩＰアドレス（このＩＰアドレスはゲートキーパが提供するアドレス変換機能によって得られる）が前記ＩＰパケットの宛先ＩＰアドレスとされる。
【００１３】
ＩＰネットワーク上における経路は、前記ルータが行うルーティングに依存し、ゲートキーパによる制御や監視の及ばないところで決まってしまう。ルーティングとは、ルータが自身が搭載するルーティングテーブルと、受信したＩＰパケットの宛先ＩＰアドレスの対応を検査し、そのＩＰパケットの直後の転送先（すなわち、ネクストホップ）を特定した上で、特定したネクストホップへＩＰパケットの転送を行う処理である。ＩＰネットワーク上に存在する隣接するルータが次々にこのルーティングを実行することにより、前記経路が決まる。
【００１４】
ＩＰパケットの送信元から宛先にいたる経路が物理的に１つしか存在し得ない場合、ルータが行うルーティングをゲートキーパが制御、監視することができなくても問題は生じないが、例えば、図２に示すように物理的にメッシュ型のトポロジを有するＩＰネットワーク１０の場合などには、ＩＰパケットの送信元（例えば、電話機１９）から宛先（例えば、電話機２４）にいたる経路が物理的に複数存在するために問題が顕在化する。
【００１５】
例えば、局ノード１５の配下にある電話機１９のユーザＵ１が、局ノード１７の配下にある電話機２４のユーザＵ６に電話をかけようとする場合、取りうる経路は、ルータ１１（，リンクＬ１），ルータ１４（，リンクＬ６）、ルータ１３の経路のほか、ルータ１１，ルータ１２，ルータ１３の経路や、ルータ１１，ルータ１２，ルータ１４，ルータ１３の経路など、多様である。各ルータで行われるルーティングにより、この多様な経路のうち、いずれか１つが選択されることになるが、その選択結果を、ゲートキーパ２５が認識する方法はない。
【００１６】
したがって、図２に示すＩＰネットワーク１０で、点線で示すような経路ＳＮ１〜ＳＮ３でＩＰパケットが伝送されて音声通話が行われている状態では、ゲートキーパ２５が認識している帯域の消費量（トラヒック量）と実際の音声トラヒック量のあいだに図３に示すような大きなずれが生じる可能性がある。ゲートキーパ２５が認識している帯域の消費量は、その帯域管理テーブルＢＭ１の内容に対応したものである。
【００１７】
図３において、ゲートキーパ２５が認識しているトラヒック量（前記帯域管理テーブルＢＭ１の内容に相当）は、局ノード１５と１７のあいだが２通話分で、局ノード１６と１７のあいだが１通話分であるが、実際のトラヒックは、局ノード１５と１６のあいだが１通話分で、局ノード１５と１８のあいだが１通話分で、局ノード１６と１７のあいだが３通話分で、局ノード１６と１８のあいだが１通話分である。
【００１８】
前記ＡＲＱメッセージや呼制御メッセージを通じてゲートキーパ２５が認識し得るのは、音声通話のためのＩＰパケットの送信元（例えば、電話機１９）と、最終的な宛先（例えば、電話機２４）だけであり、途中の中継経路（前記ルーティングテーブルに相当）を認識することができないために、このようなずれが生じるものである。
【００１９】
このように、実際の帯域消費量とゲートキーパ２５の認識のあいだに大きなずれが存在する状態では、適切な帯域管理を行うことは不可能で、実際には十分な帯域の余裕があるのにアドミッション要求（ＡＲＱメッセージ）を拒否したり、反対に、十分な帯域の余裕がないのにアドミッション要求を許可したりする可能性がある。十分な帯域の余裕があるのにアドミッション要求を拒否することは、帯域資源の利用効率が低いことを意味し、十分な帯域の余裕がないのにアドミッション要求を許可することは、アドミッション要求の許可後、実際に呼制御や音声通話などを行う段階になって大量のパケット損失や大きな遅延が発生し、通信品質の低下などの不都合を招く可能性が高く、通信の信頼性が低いことを意味する。
【００２０】
また、前記特許文献１では、いずれかのゲートウエイ装置に輻輳状態などの問題が発生したとき、ゲートキーパが、ゲートウエイ装置の選択を切り替えて、新たな経路で呼接続を行うことができるが、特許文献１におけるゲートウエイ装置や音声中継ルータは、図２に示した局ノード（例えば、１５）に相当する構成要素である。そして、特許文献１のネットワーク構成は、エンド−エンドの経路がルータ（例えば、１１）のルーティングによって決まるものではなく、ゲートキーパの制御によって一意に決まる単純な構成である。したがって、例えば、図２に示すネットワーク構成などのように、より複雑な構成の場合、特許文献１の技術で対応することは困難であり、特許文献１の技術を用いたとしても、帯域資源の利用効率を高め、通信の信頼性を高めることは難しい。
【００２１】
【課題を解決するための手段】
かかる課題を解決するために、本発明では、所定の通信ネットワーク上で所定の単位信号を用いたリアルタイム通信を実行するために帯域管理を行う帯域管理システムにおいて、予め搭載してある第１の経路表と、前記単位信号が有する第１の宛先識別子をもとに、前記単位信号の経路を決定して中継処理を行う複数の第１の中継装置と、予め搭載してある第２の経路表と、前記リアルタイム通信の最終的な宛先を指定するために当該単位信号が有する第２の宛先識別子をもとに、当該単位信号の経路を決定して中継処理を行う複数の第２の中継装置とを備え、当該第２の中継装置は、前記通信ネットワークの構造上、前記リアルタイム通信の最終的な宛先までの経路が複数存在する場合、前記第２の経路表をもとに、いずれか１つの経路を選択し、その選択結果に応じて前記第１の宛先識別子を書き換えることを特徴とする。
【００２２】
【発明の実施の形態】
（Ａ）実施形態
以下、本発明にかかる帯域管理システムを、ＩＴＵ−Ｔ勧告Ｈ．３２３に準拠のＶｏＩＰネットワークに適用した場合を例に、実施形態について説明する。
【００２３】
（Ａ−１）実施形態の構成
本実施形態のＶｏＩＰネットワーク３０の全体構成例を、図９に示す。
【００２４】
図９において、当該ＶｏＩＰネットワーク３０は、ルータ３１〜３４と、局ノード３５〜３８と、電話機３９〜４４と、ゲートキーパ４５と、リンクＬ１０〜Ｌ１３とを備えている。
【００２５】
このうちリンクＬ１０〜Ｌ１３は、ＶｏＩＰサービスを提供する通信事業者のＩＰ−ＶＰＮ網などであってもかまわないが、ここでは、専用線伝送網を想定する。
【００２６】
したがって、リンクＬ１０〜Ｌ１３のそれぞれがディジタル専用線であり、各ルータ３１〜３４が当該ディジタル専用線Ｌ１０〜Ｌ１３を介して接続されている。なお、図示した各リンク（例えば、Ｌ１０）は物理的に双方向の伝送路を含んでいる。例えば、リンクＬ１０には、ルータ３１から３４への伝送路と、ルータ３４から３１への伝送路が含まれている。
【００２７】
また、ルータ３１〜３４は、当該ディジタル専用線サービスを提供する通信事業者側の構成要素であってもよいが、ここでは、当該ディジタル専用線サービスを利用するユーザ企業などの拠点の構成要素であるものとする。したがって、このユーザ企業は４つの拠点（ＬＡＮ（ローカルエリアネットワーク））ＳＴ１〜ＳＴ４を有しており、各拠点ＳＴ１〜ＳＴ４がディジタル専用線Ｌ１０〜Ｌ１３で接続されたネットワーク構成となる。
【００２８】
拠点（例えば、ＳＴ１）の内部には、図示したルータ３１、局ノード３５や電話機３９，４０のほかに、ネットワーク機器（ルータ（３１以外）、Ｌ２スイッチ、ハブなど）、サーバ類（ＤＮＳサーバなど）、データ通信用のホスト（パーソナルコンピュータなど）等が存在していてもよいことは当然である。
【００２９】
ここで、前記拠点ＳＴ１のネットワークアドレスをＡＤ１０とし、拠点ＳＴ２のネットワークアドレスをＡＤ２０とし、拠点ＳＴ３のネットワークアドレスをＡＤ３０とし、拠点ＳＴ４のネットワークアドレスをＡＤ４０とする。
【００３０】
全部で３２ビット長のＩＰｖ４アドレスの場合、３２ビットのうちどこまでをネットワーク部とするかは、通常、サブネットマスクを利用して決定されるが、例えば、左端の２４ビットをネットワーク部とした場合、右端の８ビットはホスト部となる。ネットワーク部はネットワークを一意に指定する部分で、ホスト部はそのネットワークに属する１または複数のホストのなかで１つのホストを指定する部分である。ホスト部の全ビットが０のＩＰアドレスは、そのネットワーク（ＬＡＮ）自身を指すＩＰアドレス（すなわち、ネットワークアドレス）である。
【００３１】
ネットワークアドレスからホスト部の連続する０を除いたものはネットワーク部にほかならないから、ここでは、前記ＡＤ１０からホスト部の０を除いたＡＤ１を当該ネットワークアドレスＡＤ１０のネットワーク部とする。
【００３２】
同様に、前記ＡＤ２０から右端の０を除いたＡＤ２を当該ネットワークアドレスＡＤ２０のネットワーク部とし、前記ＡＤ３０から右端の０を除いたＡＤ３を当該ネットワークアドレスＡＤ３０のネットワーク部とし、前記ＡＤ４０から右端の０を除いたＡＤ４を当該ネットワークアドレスＡＤ４０のネットワーク部とする。
【００３３】
各ネットワークアドレスＡＤ１０〜ＡＤ４０の拠点ＳＴ１〜ＳＴ４をＬＡＮポート側に接続したルータ３１〜３４は基本的に通常のルータであってよい。ただしリアルタイム性の高いＶｏＩＰ通信を行うのであるから、ルータ３１〜３４が、ＶｏＩＰパケット、すなわち音声データを収容したＩＰパケットを他のデータ（例えば、ＦＴＰプロトコルで転送されるデータなど）を収容したＩＰパケットより優先的に転送する優先制御機能などを搭載していることは望ましい。
【００３４】
ルータ３１の内部構成例を図１２に示す。ルータ３２〜３４の内部構成も実質的に図１２と同じであってよい。
【００３５】
（Ａ−１−１）ルータの内部構成例
図１２において、当該ルータ３１は、通信部５０と、制御部５１と、記憶部５２と、ルーティングテーブル５３とを備えている。
【００３６】
このうち通信部５０は、ＯＳＩ参照モデルのデータリンク層および物理層に対応する通信機能を有する部分で、拠点の外部に接続するＷＡＮポートや、拠点の内部に接続するＬＡＮポートなどを含む。
【００３７】
制御部５１はハードウエア的にはルータ３１のＣＰＵ（中央処理装置）に相当し、ソフトウエア的にはルータ３１のＯＳ（オペレーティングシステム）などに相当する部分である。ルータの本質的機能であるルーティングを実行するのは、このＯＳに含まれるＩＰモジュール（ＩＰプロトコル処理ソフト）である。
【００３８】
ルーティングテーブル部５３は、上述したルーティングテーブルに対応する部分である。ルータ３１のルーティングテーブルを他のルータのルーティングテーブルと区別するため、ＲＴ３１とする。
【００３９】
ルーティングテーブルＲＴ３１の内容は、一例として、図１３（Ａ）に示すようなものであってよい。図１３（Ａ）において、ルーティングテーブルＲＴ３１のデータ項目は、宛先ＩＰアドレスと、ネクストホップの２項目である。
【００４０】
宛先ＩＰアドレスの値としては、３２ビット長のＩＰｖ４アドレスのうち、上述したネットワーク部（例えば、ＡＤ２）だけを登録してある。また、ネクストホップは、各ルータ３２または３４をその符号で示してある。
【００４１】
ルーティングテーブルＲＴ３１中、最上位の行（エントリ）Ｅ１１の内容である「ＡＤ２，３２」は、宛先ＩＰアドレスとして、ネットワーク部がＡＤ２のＩＰアドレスを持つＩＰパケットが転送されてきたら、ルータ３２へ転送することを指定している。
【００４２】
同様に、２番目の行Ｅ１２の内容である「ＡＤ３，３２」は、宛先ＩＰアドレスとしてネットワーク部がＡＤ３のＩＰアドレスを持つＩＰパケットが転送されてきたら、ルータ３２へ転送することを指定し、最下位の行Ｅ１３の内容である「ＡＤ４，３４」は、宛先ＩＰアドレスとしてネットワーク部がＡＤ４のＩＰアドレスを持つＩＰパケットが転送されてきたら、ルータ３４へ転送することを指定している。
【００４３】
図１３（Ｂ）にもこれと同様なルーティングテーブルＲＴ３２を示している。ただし、ルーティングテーブルＲＴ３２は、ルータ３２に搭載されるルーティングテーブルであるから、各行の内容がＲＴ１と異なるのは当然である。
【００４４】
図１２に示す記憶部５２はハードウエア的には、ＲＡＭ（ランダムアクセスメモリ）や、ハードディスクなどによって構成される記憶資源であり、ソフトウエア的には、データベースや各種のファイルがこの部分に含まれ得る。前記ＯＳなどのプログラムファイルもこのようなファイルの一つであるから、ＯＳも、その物理的な実体は、この記憶部５２に位置する。同様に、ルーティングテーブルＲＴ３１も、その物理的な実体は記憶部５２に位置する。
【００４５】
一方、前記局ノード３５は、このようなルータ３１のＬＡＮポート側に接続されるノード装置であり、本実施形態の特徴的な構成要素である。
【００４６】
局ノードの機能をどのような形態で各拠点に実装するかに関しては様々な方法が考えられ、例えば、ルータ３１に局ノード３５の機能を搭載したり、ＰＢＸ（構内交換機）に局ノードの機能を搭載したり、独立した専用装置に局ノード３５の機能を搭載したり、ＶｏＩＰゲートウエイに局ノード３５の機能を搭載したりすることも可能であるが、ここでは、ＩＰ−ＰＢＸに局ノードの機能を搭載するものとする。局ノード３６〜３８についても同様である。
【００４７】
このＩＰ−ＰＢＸは、別個にＶｏＩＰゲートウエイを必要としないＩＰトランク形式のＩＰ−ＰＢＸである。
【００４８】
局ノード３５がＩＰ−ＰＢＸである場合、局ノード３５に収容されている電話機３９、４０は、ＶｏＩＰ対応の電話機（ＩＰ電話機）のこともあり、ＶｏＩＰ非対応の一般電話機のこともあるが、いずれにしてもアドミッションメッセージの送受や、呼制御メッセージの送受、および呼を確立したあとに転送される音声データを収容したＩＰパケットに関しては、ＩＰ−ＰＢＸが機能するものとする。
【００４９】
局ノード３５の内部構成例を図１１に示す。局ノード３６〜３８の内部構成も実質的に図１１と同じであってよい。
【００５０】
（Ａ−１−２）局ノードの内部構成例
図１１において、この局ノード３５は、通信部６０と、制御部６１と、記憶部６２と、アドレス変換部６３と、変換テーブル部６４と、ＩＰアドレス変換部６５と、帯域管理部６６とを備えている。
【００５１】
このうち通信部６０は前記通信部５０に対応し、制御部６１は前記制御部５１に対応し、記憶部６２は前記記憶部５２に対応する。
【００５２】
ただし本実施形態の場合、局ノード３５は拠点ＳＴ１の内部に存在するため、その通信部６０がＷＡＮポートを備える必要はない。
【００５３】
また、ＩＰ−ＰＢＸとしての局ノード３５は、収容している電話機（例えば、３９）に呼制御メッセージが着信したり、反対に収容している電話機３９から呼制御メッセージを発信したりするときには、電話機３９と協調しながらゲートキーパ４５と通信し、ゲートキーパ４５が提供するサービスの内容に応じて処理を実行する。
【００５４】
通常、ＩＰ−ＰＢＸはゲートキーパの機能を内蔵しているが、局ノード３５はゲートキーパ機能を内蔵していないか、内蔵していたとしてもその機能を無効化していて、外部のゲートキーパ４５のサービスを利用するものとする。
【００５５】
ここでは、図９に示したＶｏＩＰネットワーク３０全体が当該ゲートキーパ４５が管理するゾーンに属するものとする。
【００５６】
ゲートキーパを設けるか否かはオプションであるが、設けた場合、ゾーン内の各Ｈ．３２３構成要素（当該局ノード３５もその１つ）は、ゲートキーパが提供する各種のサービスを利用しなければならない。このため、本実施形態では、局ノード３５およびその他の局ノード３６〜３８も、ゲートキーパ４５が提供するサービスを利用する必要がある。なお、Ｈ．３２３構成要素とは、ＩＴＵ−Ｔ勧告Ｈ．３２３規格上の構成要素のことであり、ＩＰ−ＰＢＸやＩＰ電話機などが該当し、一般のＰＢＸや、一般電話機などは含まれない。
【００５７】
ゲートキーパの機能にはアドレス変換機能、アドミッション制御機能、上述した帯域管理機能などがあり、局ノード３５などのＨ．３２３構成要素に対し、これら各種機能に応じたサービスを提供する。
【００５８】
本実施形態において、ゲートキーパ４５は基本的にＩＴＵ−Ｔ勧告Ｈ．３２３に準拠した通常のゲートキーパであってよい。したがって、ゲートキーパ４５が備える各種機能も基本的に通常のものである。このゲートキーパ４５は、帯域管理機能を実現するために、図８に示すように、帯域管理部４６と、中央帯域管理テーブルＢＭ１１を備えている。
【００５９】
この中央帯域管理テーブルＢＭ１１には、少なくとも、隣接する局ノード間の回線に関する使用中の帯域幅が格納されており、必要に応じて、隣接していない局ノード間の使用中の帯域幅も格納される。
【００６０】
図８の例では、隣接する局ノード間で使用中の帯域幅は、３５−３６間がＶ１１、３８−３５間がＶ１２、３６−３７間がＶ１３，３７−３４間がＶ１４である。
【００６１】
隣接していない局ノード間で使用中の帯域幅には、例えば、図９のネットワーク構成の場合、局ノード３１と３３のあいだの使用中帯域幅が該当する。隣接していない局ノード間の使用中帯域幅をゲートキーパ４５の中央帯域管理テーブルＢＭ１１で管理する必要があるか否かは、ゲートキーパ４５が具体的にどのような形でアドミッション制御を行うかに依存する。また、このアドミッション制御がどのような形の制御になるかは、局ノード（例えば、３５）の機能などにも依存して決まる。
【００６２】
実質的にゲートキーパ４５の機能だけで一元的な帯域管理を行う場合には、ＶｏＩＰネットワーク３０上で起こり得るすべての組み合わせにつき、エンド−エンドで帯域管理を行う必要があるため、中央帯域管理テーブルＢＭ１１には、この組み合わせの数だけの行が必要となり、例えば、３１−３３間などの、隣接していない局ノード間で使用中の帯域幅も格納する必要がある。
【００６３】
隣接していない局ノード間で使用中の帯域幅を中央帯域管理テーブルＢＭ１１で管理し、その管理を適切なものとするためには、ゲートキーパ４５が、直接的または間接的に、ルーティングテーブル（例えば、ＲＴ３１）の内容を認識する必要がある。間接的な認識は、ゲートキーパ４５が後述する変換テーブル（例えば、ＴＴ３５Ａ、ＴＴ３５Ｂなど）の内容を認識することによって形成され得る。
【００６４】
ゲートキーパを介した制御信号のやり取り、すなわちシグナリングの方式としては、すべての制御信号をゲートキーパ経由でやり取りするＧＫＲＣＳ方式と、一部の制御信号（呼設定（ＳＥＴＵＰ）メッセージと応答（ＣＯＮＮＥＣＴ）メッセージ）だけはエンドポイント（本実施形態では局ノード（例えば、３５、３７））間で直接やり取りするＤＥＣＳ方式があり、本発明はいずれの方式にも適用可能であるが、ここでは、ＤＥＣＳ方式を用いるものとする。
【００６５】
この制御信号には、例えば、ＡＲＱメッセージなどのアドミッションメッセージおよび、呼設定メッセージなどの呼制御メッセージが含まれる。
【００６６】
局ノード３５のアドレス変換部６３は、発信時に、着信先電話番号の値から対応するＩＰアドレスを取得する部分で、取得したＩＰアドレスは、宛先ＩＰアドレスとして使用する。このＩＰアドレスは、着信先電話番号をもとにゲートキーパ４５に問い合わせを行うことによって取得されるものである。Ｈ．３２３構成要素である局ノード３５は、直接、このような問い合わせをゲートキーパ４５に対して行うことができる。
【００６７】
ゲートキーパ４５のアドレス変換機能は、ゾーン内におけるＩＰアドレスと電話番号の対応関係を登録したデータベースを装備しているため、この問い合わせに応えることができる。
【００６８】
例えば、電話機４０のユーザＵ４０が電話機４０を操作して電話機４３の電話番号ＮＢ３２を入力したものとすると、アドレス変換部６３が、当該電話番号ＮＢ３２に対応するＩＰアドレスをゲートキーパ４５に問い合わせ、電話機４３を指定するＩＰアドレス（ここでは、ＡＤ３２とする）を取得することができる。これにより、局ノード３５は、このＩＰアドレスＡＤ３２を、ＩＰヘッダ中に宛先ＩＰアドレスとして収容したＩＰパケットを送信することができる。
【００６９】
ただしこの宛先ＩＰアドレスとしてＡＤ３２を収容したＩＰパケットをそのまま送信したのでは、前記ルータ３１が備えるルーティングテーブルＲＴ３１の行Ｅ１２に応じてルータ３２に転送され、ルータ３２が備えるルーティングテーブルＲＴ３２の行Ｅ２１に応じてルータ３３へ転送されてしまい、図２に示したＶｏＩＰネットワーク１０と同様、帯域管理テーブルＢＭ１の内容と、ＶｏＩＰネットワーク３０上の実際の音声トラヒック量のあいだにずれが発生する可能性がある。ルーティングテーブル（例えば、ＲＴ３１，ＲＴ３２など）の内容を認識できないゲートキーパ４５は、実際の音声トラヒック量を直接、認識することはできないからである。
【００７０】
したがって、本実施形態の局ノード３５は、ゲートキーパ４５の問い合わせで得られたＩＰアドレス（例えば、ＡＤ３２）をそのまま使用するのではなく、そのＩＰアドレスＡＤ３２をさらに変換した上で使用する。
【００７１】
この変換の方法には様々なものがあり得るが、途中の局ノード（例えば、３６，３８）経由の転送が行えることと、最終的な宛先である電話機（ここでは、４３）へＩＰパケット（その内容である音声データ（音声データに対応するアナログ音声信号））を届けることできることが必要である。したがって、この変換によって、最終的な宛先である電話機４３を一意に指定する情報が失われてはならない。
【００７２】
ここでは一例として、この変換では、ＩＰアドレスのネットワーク部のみを変換し、ホスト部の値は変換せずに維持するものとする。
【００７３】
したがって例えばＡＤ３２の場合なら、ホスト部に対応する右端の「２」は維持し、ネットワーク部に対応する「ＡＤ３」だけを変換することになる。当該ＡＤ３を変換するとき、変換先のネットワーク部をどのように決定するかは、変換テーブル部６４が備える変換テーブルＴＴ３５の内容に応じて決まる。
【００７４】
ネットワーク部の値を変更し、ホスト部の値を維持した結果、偶然、中継処理を行う局ノードの配下の電話機と同じＩＰアドレスとなることを防止する必要がある場合には、予め、各拠点ＳＴ１〜ＳＴ４の電話機に付与するＩＰアドレスのホスト部が重複しないようにＩＰアドレスを付与しておくとよい。
【００７５】
なお、電話機を指定するＩＰアドレス（例えば、ＡＤ３２）は、ＩＰ−ＰＢＸである局ノード３７が搭載するＩＰトランクに付与されたＩＰアドレスであってよい。
【００７６】
局ノード３５が有する変換テーブルＴＴ３５は、発信用の変換テーブルＴＴ３５Ａと、中継用の変換テーブルＴＴ３５Ｂから構成される。発信用変換テーブルＴＴ３５Ａの内容は例えば図１５（Ａ）に示す通りであってよく、中継用変換テーブルＴＴ３５Ｂの内容は例えば図１５（Ｂ）に示す通りであってよい。
【００７７】
発信用変換テーブルＴＴ３５Ａは自拠点ＳＴ１から他の拠点（例えば、ＳＴ３）へ発信するときに適用し、中継用変換テーブルＴＴ３５Ｂは、他拠点（例えば、ＳＴ２）から送信されたＩＰパケットを他拠点（例えば、ＳＴ４）へ中継するときに適用する。本実施形態において、局ノード（例えば、３５）が行う中継（中継処理）は、形式的には、ＩＰ−ＰＢＸまたはゲートキーパの付加サービスとして着信呼を転送する際の動作に類似している。
【００７８】
処理しようとするＩＰパケットが、自拠点ＳＴ１から送信されたＩＰパケットであるか否かを判定する方法には、様々なものがあり得るが、例えば、受信したＩＰパケットのＩＰヘッダに含まれる送信元ＩＰアドレスに基づいて判定することもでき、そのＩＰパケット（または情報）を受信したポートをもとに判定することもできる。例えば、自拠点内の一般電話機の場合、接続されるのはアナログポートであるため、アナログポートから受信した情報（この場合、受信時点ではまだＩＰパケット化されていない）ならば、自拠点ＳＴ１から送信されたＩＰパケット（情報）であることが分かる。
【００７９】
この判定に送信元ＩＰアドレスを使用できるのは、本実施形態の構成上、局ノード（例えば、３５）は、ＩＰヘッダ中のアドレスのうち、宛先ＩＰアドレスは中継時には必ず（必要に応じて発信時にも）変換する必要があるが、送信元ＩＰアドレスは変換することなく、最初のものを維持することができるため、送信元ＩＰアドレスをもとにＩＰパケットの送信元の拠点を特定することが可能だからである。
【００８０】
また、後述する発信特番が入力されたことをもって、自拠点からの発信であると判定することができることは当然である。
【００８１】
自拠点ＳＴ１から他の拠点（例えば、ＳＴ３）へ発信するときに適用する前記発信用変換テーブルＴＴ３５Ａは、図１５（Ａ）の最上位の行Ｅ３１に示すように、ＡＤ３すなわち拠点ＳＴ３へ発信するときには、当該ＡＤ３をＡＤ２に変換する。拠点ＳＴ３はＳＴ１に隣接していないためにこのような変換が必要になる。拠点ＳＴ１に隣接している拠点（ＳＴ２，またはＳＴ４）へ発信する場合には、ネットワーク部は実質的に変換する必要はないが、ここでは、発信用変換テーブルＴＴ３５Ａ内に変換元と変換先の値が同じ行Ｅ３２，Ｅ３３を容易して、形式的に変換を行うものとしている。
【００８２】
なお、ＡＤ３を変換するとき、ＡＤ２ではなく、ＡＤ４へ変換するようにしてもよいことは当然である。例えば、リンクＬ１０側の帯域に比べてリンクＬ１１側の帯域が広い場合（Ｌ１１のほうが、より高速なディジタル専用線である場合）などに、当該ＡＤ３をＡＤ２へ変換することも望ましい。
【００８３】
また、Ｌ１０、Ｌ１１双方の経路の輻輳度などを検査し、輻輳度の変動に応じて、行Ｅ３１の内容を書き換えるようにしてもよい。輻輳していないほうの経路を利用すれば、高い通信品質が得られ、ＶｏＩＰネットワーク３０全体として帯域の利用効率が高まるからである。
【００８４】
あるいは、もっと単純にラウンドロビン方式を用いて、自拠点ＳＴ１内から他の拠点（例えば、ＳＴ３）へ発信するたびに、交互に、経路を変更するようにしてもよい。これは、例えば、最初の発信ではＡＤ３をＡＤ２に変換し、２回目の発信ではＡＤ３をＡＤ４に変換し、３回目の発信ではＡＤ３をＡＤ２に変換し、…という処理を繰り返すものである。発信のたびに行Ｅ３１の内容を書き換えることでこのような処理が可能となる。
【００８５】
宛先ＩＰアドレスのネットワーク部であるＡＤ３をＡＤ２に変換した上で当該ＩＰパケットをルータ３１に転送すれば、ルータ３１は前記ルーティングテーブルＲＴ３１にしたがって当該ＩＰパケットをルータ３２へ転送する。ネットワーク部としてＡＤ２を有する宛先ＩＰアドレスは拠点ＳＴ２自身の内部のホスト宛てであることを意味するから、ルータ３２は当該ＩＰパケットを他のルータ（ここでは、３３）へ中継することなく、ＬＡＮポート側から拠点ＳＴ２１内へ転送する。このＩＰパケットは局ノード３６で受信されるから、確実に局ノード３６による中継処理を受けることができる。
【００８６】
このような発信用または中継用変換テーブルによる宛先ＩＰアドレスの変換を繰り返せば、各ルータ３１〜３４のルーティングテーブルＲＴ３１〜ＲＴ３４の内容にかかわらず、所望の局ノードによる中継を行わせ、経路を制御することもであるが、発信用変換テーブル（例えば、ＴＴ３５Ａ）や中継用変換テーブル（例えば、ＴＴ３５Ｂ）の内容は、ルーティングテーブル（例えば、ＲＴ３１）の内容を反映したものであることが望ましい
ルーティングテーブルに合わせて変換テーブルの内容を変更しなければ、局ノード（例えば、３５）の動作とルータ（例えば、３１）の動作が複合された結果として、ＶｏＩＰのための１つのＩＰパケットが同じリンク（例えば、Ｌ１１）を２度伝送されること等が起こり得、伝送効率の低下や、実際の帯域消費量とゲートキーパ４５の認識の間のずれの発生などの問題が起きるからである。
【００８７】
局ノード３５も、前記局ノード３６と同様に他の拠点のために中継処理を行うことがあり、また、自拠点内の電話機（例えば、３９）宛てにＩＰパケットを転送することもあるのは当然である。
【００８８】
局ノード３５は、着信先電話番号を含むＩＰパケットを受信した場合、そのＩＰパケットを自拠点内の電話機（例えば、４０）へ転送するか、または、隣接する拠点（例えば、ＳＴ２）へ中継するかは、その着信先電話番号が自局の局番ＮＢ１と一致するか否かをもとに判定することができる。
【００８９】
呼制御メッセージのうち呼設定メッセージにより呼が確立されたあと、その呼の切断が行われるまでの間、同じ送信元ＩＰアドレスから送信されてくるＩＰパケット群は、自拠点内へ転送（または、中継）のいずれかに固定して処理するようにするとよい。これにより局ノード３６、ユーザ間の通話のために転送される音声データを収容したＩＰパケットに、着信先電話番号が収容されていなくても、中継を行うか、自拠点内へ転送するかを適切に判定することができる。
【００９０】
１つの呼が確立されたか否かや、切断されたか否かの情報を管理する機能は、呼管理機能に属するものと考えられる。ゲートキーパ４５もオプションの呼管理機能を有することがあるが、ゲートキーパ４５の呼管理機能が、呼設定を要求する側のＨ．３２３構成要素（例えば、３５）からその呼設定を最終的に受ける側のＨ．３２３構成要素（例えば、３７）までを単位とするエンド−エンドの呼管理しか行えないのに対し、ここで局ノード（例えば、３５）が行う呼管理はエンド−エンドの呼を複数の呼に分割し、分割した各呼を独立した呼として管理するものである。
【００９１】
本実施形態では、隣接していない局ノード間に呼を設定する場合、経路の途中にある局ノードごとに呼設定を終端し、ホップバイホップに呼設定を行うためである。ただしここでいうホップバイホップとは、必ずしもルータごとであることを意味せず、局ノードごとに呼設定を行うことを意味する。図９の例では、局ノードの数とルータの数が一致しているが、一般的には、これらの数は一致せず、隣接する局ノードのあいだに多数のルータが存在していても、隣接する局ノード間は１ホップとみなす。
【００９２】
この点は、経路上にルータ以外の図示しないネットワーク機器（例えば、Ｌ２スイッチなど）が存在していても同様である。一般的には、経路上の任意の場所にＬ２スイッチなどのネットワーク機器が存在し得る。
【００９３】
局ノードによる呼管理は、局ノード３５自身が、自局内に転送または中継する呼に関して実行するものである。このとき局ノードは、既存の空塞管理の機能を利用することができる。空塞管理機能は、例えば、図１０に示すように、局ノードが自身に対する入回線や出回線に対する空きや塞がりに関する情報（トランク制御情報）を管理するために搭載している機能である。局ノード３５は、呼制御メッセージの転送などに際してＩＰパケットに含まれ得る着信先電話番号などに基づいて、自局内の電話機へ転送するか、中継するかを判定することができる。
【００９４】
この着信先電話番号などの電話番号に関し、局番とその局番に属する電話機の電話番号（内線番号）に、上述したＩＰアドレスのネットワーク部とホスト部と同様な表記を適用すると、例えば、拠点ＳＴ１の局番がＮＢ１ならば、その局番に属する電話機（例えば、３９）の電話番号は、局番＋内線番号で、ＮＢ１１となる。
【００９５】
ただし、拠点ＳＴ１内のユーザ（例えば、Ｕ４０）が他の拠点へ電話をかける場合、所定の特殊な番号（発信特番）を当該電話番号の前に入力する必要がある。この発信特番は、リンク（例えば、Ｌ１１）などの中継線経由で遠隔地のＰＢＸ内線への発信であることを自拠点内のＩＰ−ＰＢＸである局ノード３５に伝えるための番号であるため、着信先電話番号として呼制御メッセージなどに含まれるものではない。
【００９６】
図１４に示すように、図９のＶｏＩＰネットワーク３０では、電話番号の局番はＩＰアドレスのネットワーク部に対応し、電話機の電話番号（例えば、内線番号）は、ＩＰアドレスのホスト部に対応する。
【００９７】
したがって、着信先電話番号を含むＩＰパケットを受信した場合、局ノード３５はその着信先電話番号の局番がＮＢ１ならば中継せず、ＮＢ１以外の番号（例えば、ＮＢ３）なら中継することになる。
【００９８】
局ノード３５の前記アドレス変換部６３は、この中継処理を行うときにも機能する。この中継処理を細分すると、着信（受信（例えば、呼設定の終端））と、中継と、発信（送信）に分けることができる。当該発信の際には拠点ＳＴ１の内部から発信する通常の発信と同様にアドレス変換のためにゲートキーパ４５へ問い合わせを行うことも可能であるが、ここでは、中継処理に際しては、ゲートキーパ４５に問い合わせを行うことなく、図１５（Ｂ）に示す中継用変換テーブルＴＴ３５Ｂを用いてアドレス変換を実行するものとする。
【００９９】
受信したＩＰパケットが呼設定メッセージに対応するものなど、着信先電話番号（着信先の局番があればよい）を含んでいる場合には、その着信先電話番号（着信局番）をもとに、受信時点の宛先ＩＰアドレスのネットワーク部（中継処理の場合、拠点ＳＴ１の局ノード３５が受信したのであるから、これは必ずＡＤ１）を該当するネットワーク部に変換することができる。
【０１００】
例えば、着信局番が拠点ＳＴ２を指すＮＢ２である場合には、図１５（Ｂ）の行Ｅ４１の内容に応じて、宛先ＩＰアドレスのネットワーク部をＡＤ１からＡＤ２に変換する。これにより、このＩＰパケットを受け取ったルータ３１は、前記ルーティングテーブルＲＴ３１にしたがって、当該ＩＰパケットをルータ３２へ転送する。また、ルータ３２はこのＩＰパケットを自拠点ＳＴ２内へ転送するから、局ノード３６が受信することができる。
【０１０１】
着信局番が拠点ＳＴ４を指すＮＢ４である場合には、図１５（Ｂ）の行Ｅ４２の内容に応じて、宛先ＩＰアドレスのネットワーク部をＡＤ１からＡＤ４に変換する。これにより、このＩＰパケットを受け取ったルータ３１は、前記ルーティングテーブルＲＴ３１にしたがって、当該ＩＰパケットをルータ３４へ転送する。また、ルータ３４はこのＩＰパケットを自拠点ＳＴ４内へ転送するから、局ノード３８が受信することができる。
【０１０２】
なお、図９のネットワーク構成では、例えば、拠点ＳＴ４から拠点ＳＴ３に属する宛先へＩＰパケットを送信する場合、ルータ３４からルータ３３へ転送するホップ数が最小となる経路以外に、ルータ３４から、３１，３２，３３の順番で転送するホップ数の大きな経路を選択することも可能であるが、図１５（Ｂ）では、ホップ数が最小となる経路が選択されるものと想定し、このようなホップ数の大きい経路が選択される場合の中継に対応する行は用意していない。
【０１０３】
中継処理において、当該アドレス変換部６３が行うアドレス変換は局ノード３５自身が実行するものであり、ゲートキーパ４５が提供するアドレス変換機能を利用する必要はないから、本実施形態により、ゲートキーパ４５の負荷が図２に示したゲートキーパ２５よりも大きくなることはない。
【０１０４】
ＩＰアドレス変換部６５は、受信したＩＰパケットが呼設定メッセージに対応するものなどのように着信先電話番号（着信局番）を含んでいるものでない場合に、宛先ＩＰアドレスの変換を行う部分で、前記呼管理機能を利用する。
【０１０５】
本実施形態の場合、転送するＩＰパケットの宛先ＩＰアドレスは各局ノード（例えば、３５）で本来の宛先を示すものから変換されるため、着信局番が含まれていなければ、そのＩＰパケットのみから宛先を特定することは困難である。ただし、１つの呼が設定されてから切断されるまでのあいだは、同じ送信元ＩＰアドレスから、同じ最終的な宛先に宛てたＩＰパケットの送信（または中継）が繰り返される点を利用して宛先ＩＰアドレスのネットワーク部を変換することができる。
【０１０６】
したがって、例えば、呼設定のとき宛先ＩＰアドレスのネットワーク部をＡＤ２へ変換したものと同じ送信元ＩＰアドレス（一例として、ＡＤ１２）を持つＩＰパケットの宛先ＩＰアドレスの変換では、そのネットワーク部を、当該ＡＤ２へ変換することになる。この処理は、送信の場合でも、中継の場合でも同じである。
【０１０７】
上述した局ノード（例えば、３５）による呼管理機能は、このＩＰアドレス変換部６５のためにも活用することができる。ただしＩＰアドレス変換部６５のために必要な呼管理機能は、局ノード３５自身が、発信（送信）または中継する呼に関するものでよい。
【０１０８】
前記制御部６１に接続された帯域管理部６６は、局ノード３５の内部において帯域管理を行う部分で、帯域管理テーブルＢＢ３５を備えている。
【０１０９】
当該帯域管理テーブルＢＢ３５には、当該局ノード３５が中継、発信、または着信する呼に関する帯域管理を行うためのテーブルで、例えば、図７に示すように回線ごと（リンクごと）に、局ノード３５が中継、発信、または着信する呼のトラヒック量を格納している。ＶｏＩＰネットワーク３０が運用されているとき、各トラヒック量は時々刻々と変動し得る。なお、システム構成によっては、１つの呼が維持されている途中で、その呼のための帯域が増加したり、減少したりすることもあり得る。
【０１１０】
図７の例で、３５−３６間の回線（リンクＬ１１）のトラヒック量はＶ１１であり、３８−３５間の回線（リンクＬ１０）のトラヒック量はＶ１２である。このようなトラヒック量を各局ノードが取得する方法としては様々なものが考えられるが、例えば、ＩＰトランクのチャネルの空塞を示す情報をもとに容易に取得することが可能である。
【０１１１】
図７は、当該局ノード３５を図１１とは別な観点から表現した構成例である。
【０１１２】
図７において、ＩＰ−ＰＢＸである局ノード３５は、ＶｏＩＰ処理部８０と、ＰＲＩ（Ｐｒｉｍａｒｙ Ｒａｔｅ Ｉｎｔｅｒｆａｃｅ）処理部８１と、Ｈ．３２３処理部８２と、Ｑ．９３１処理部８３と、呼処理部８４と、前記帯域管理部６６とを備えている。
【０１１３】
このうち構成要素８０〜８４は、主として、図１１の制御部６１に対応する機能である。
【０１１４】
以下、上記のような構成を有する本実施形態の動作について、図１のフローチャートを参照しながら説明する。図１のフローチャートは、Ｓ１０〜Ｓ１３の各ステップを備えている。
【０１１５】
（Ａ−２）実施形態の動作
ここでは、拠点ＳＴ１内のユーザＵ３９が電話機３９を用いて拠点ＳＴ３内の電話機４３へ電話をかける場合を例に説明する。
【０１１６】
ユーザＵ３９が電話機３９をオフフックして、前記発信特番と、それにつづく、電話機４３の電話番号（着信先電話番号）ＮＢ３３を指定する。
【０１１７】
局ノード３５は、発信特番および着信先電話番号を受け取ると（Ｓ１０）、この発信特番から遠隔地のＰＢＸ内線への発信であることが分かるため、ゲートキーパ４５へ問い合わせを行い、当該着信先電話番号（着電番号）に対応するＩＰアドレスであるＡＤ３２を取得する。
【０１１８】
当該ＡＤ３２の取得のまえに実際には、局ノード３５からＡＲＱメッセージが送信されてゲートキーパ４５によるアドミッション制御が行われるが、そのアドミッション制御の基礎となる中央帯域管理テーブルＢＭ１１の生成は、以降の動作と同様な動作によって各局ノードに蓄積された帯域管理テーブル（例えば、局ノード３５の帯域管理テーブルＢＢ３５）をもとに実行されるものである。ここではゲートキーパ４５によるアドミッション制御ではＡＣＦメッセージが返送され、当該局ノード３５からのアドミッション要求が承認されたものとする。
【０１１９】
この承認の後に行われる前記問い合わせによって得られたＩＰアドレスＡＤ３２のネットワーク部である「ＡＤ３」は、図１５（Ａ）に示す前記発信用変換テーブルＴＴ３５Ａの行Ｅ３１をもとにＡＤ２へ変換され（Ｓ１１）、ホスト部である「２」は維持されるため（Ｓ１２）、結局、当該ＡＤ３２は、ＡＤ２２（＝ＡＤ２＋２）に変換されてＩＰパケットの宛先ＩＰアドレスとされる（Ｓ１３）。
【０１２０】
前記局ノード３５から当該ＩＰパケットが送出されると、ルータ３１が図１３（Ａ）に示すルーティングテーブルＲＴ３１に基づいてルーティングした結果、リンクＬ１１を経てルータ３２に届けられる。
【０１２１】
ＡＤ２０は拠点ＳＴ２を示すネットワークアドレスであるから、当該ＩＰパケットはルータ３２におけるルーティングにより、拠点ＳＴ２の内部へ転送され、局ノード３６に受信される。
【０１２２】
本実施形態は前記シグナリング方式として前記ＤＥＣＳ方式を用いているため、呼を中継する１または複数の局ノード（ここでは、３６）は、その呼に関し、ユーザＵ３９などの会話音声を示す音声データを収容したＩＰパケットを受信する前に、呼設定（ＳＥＴＵＰ）メッセージを収容したＩＰパケットを受信することができる。呼設定メッセージには着電番号が含まれているため、例えば、局ノード３６は中継用変換テーブルＴＴ３６Ｂ（図１５（Ｂ）に示すＴＴ３５Ｂに対応）をもとに、中継処理を行うことが可能である。
【０１２３】
この中継処理は、上述したように、着信（受信）、中継、発信（送信）に分けることができるが、着信の部分では、最終的な宛先が電話機４１である場合と同様に、呼設定の受付が行われ得る。また、発信の部分では、基本的に当該ＩＰパケットの送信元である局ノード３５で行われたものと同様、図１のフローチャートに応じた処理が実行される。
【０１２４】
ただし、中継処理では、ステップＳ１０の着電番号の受付は、ＩＰパケット中に収容されている着電番号をもとに行うことになる。また、上述したように中継処理では、ゲートキーパ４５への問い合わせは省略し、中継用変換テーブルＴＴ３６Ｂに基づいたアドレス変換を実行する。
【０１２５】
局ノード３６による中継処理のあと、当該ＩＰパケットは、ルータ３２，３３を経由して最終的な宛先である電話機４３を収容した拠点ＳＴ３の局ノード３７に着信し、局ノード３７を介して電話機４３のベルを鳴らしユーザＵ４３を呼び出すことができる。
【０１２６】
ユーザＵ４３が電話機４３をオフフックすれば、応答（ＣＯＮＮＥＣＴ）メッセージが収容されたＩＰパケットが返送され、電話機３９と４３のあいだに呼が確立され、ユーザＵ３９とＵ４３の会話音声を収容したＩＰパケットがやり取りされる通話状態となる。
【０１２７】
応答メッセージは通常、呼設定メッセージと同じ経路（ここでは、３５，３１，３２，３６、３２，３３、３７の経路）を反対方向に転送されるが、本実施形態のネットワーク構成では、呼設定メッセージと異なる経路（例えば、３７，３３，３４，３８，３４，３１、３５の経路）を応答メッセージが転送されるようにすることも可能である。ただし応答メッセージは呼設定メッセージと同じ経路を反対方向に転送するようにしたほうが、経路上の局ノード（例えば、３２）における呼管理などは容易になるものと考えられる。
【０１２８】
応答メッセージの転送経路が呼設定メッセージと同じであってもなくても、応答メッセージに対して経路上のルータや局ノードで行われる処理の内容は、呼設定メッセージが転送された場合と同様であってよい。
【０１２９】
なお、前記通話状態において局ノード（ここでは、３６）が、音声データを収容したＩＰパケットを中継するとき、通常のＨ．３２３プロトコル体系にしたがった処理を行うと、Ｈ．３２３プロトコル体系中の各階層のプロトコルを処理するモジュールの機能によっては、ＶｏＩＰ処理部８０でＩＰパケットから音声データを取り出したり、取り出した音声データをアナログ信号に変換したりする処理が行われる可能性が高い。
【０１３０】
しかし局ノード３６が行うのは中継処理であるから、音声データを取り出すことも、アナログ信号に変換することも不要である。
【０１３１】
また、中継処理である以上、音声データを収容したＩＰパケットを送信することが必要であるため、音声データを取り出した場合には、再度、その音声データをＩＰパケットに収容する処理が必要になり、アナログ信号に変換した場合には、そのアナログ信号をＰＣＭにより再度ディジタル信号（音声データ）に変換した上でその音声データをＩＰパケットに収容する処理が必要になってしまう。
【０１３２】
中継時にこのような処理を実行すると、遅延時間の増大や、音質低下などの問題をまねく可能性が高く、また、局ノード３６の処理能力に対し、不必要に大きな負荷をかけることにもなる。
【０１３３】
そこで、本実施形態では、図５に示すように、中継処理を行う局ノード（ここでは、３６）は、ＩＰパケットから音声データを取り出すこと等の不必要な処理は実行せず、ＩＰパケットのまま中継するものとする。これにより、遅延時間の低減、音質維持、負荷軽減などの効果を得ることができる。
【０１３４】
また、各局ノードの内部では、自局ノードでステップＳ１０〜Ｓ１３が実行されるとき、またはその前後に上述した帯域管理テーブル（例えば、局ノード３５なら帯域管理テーブルＢＢ３５）の該当する行のトラヒック量の値（例えば、前記Ｖ１１）が更新される。どのタイミングでこの更新を行うかについては、様々な方法が考えられるが、例えば、ある呼設定メッセージに対応する応答メッセージが返送されてきたタイミングで、この更新を行うようにするとよい。
【０１３５】
なお、呼設定メッセージの転送方向が反対のケース、例えば、拠点ＳＴ３内のユーザＵ４３が電話機４３を用いて拠点ＳＴ１内の電話機３９へ電話をかける場合の動作も以上の動作と同様である。
【０１３６】
また、経路上にルータ以外のネットワーク機器、例えば、上述したＬ２スイッチなどが存在していても、以上の動作は同様である。
【０１３７】
この場合、以上の動作を例えば図４，図６を用いて表現することができる。
【０１３８】
図４および図６では、前記局番ＮＢ１〜ＮＢ３を、ＮＢ１＝３０，ＮＢ２＝２０，ＮＢ３＝３０とし、局ノード３５と３６のあいだには、２つのルータ８５，８６と、２つスイッチ８９，９０とが介在し、局ノード３６と３７のあいだには２つのルータ８７，８８と、２つのスイッチ９０，９１とが介在している。
【０１３９】
図４、図６の構成は、図９に示すＶｏＩＰネットワーク３０のように、任意の局ノード間に複数の経路があり得るネットワーク構成のなかから一部を抜き出して示したものである。図４，図６上で、図９と同じ符号を付与した構成要素３５，３６，３７，３９，４３の機能は、図９と対応する。
【０１４０】
図６には、局ノード３７に収容された電話機４３のユーザＵ４３が局ノード３５に収容された電話機３９へ電話をかけた場合に各構成要素で実行される動作（Ｓ２０〜Ｓ２３）が示されている。すなわち、前記呼設定メッセージを収容したＩＰパケットが局ノード３７から送信され、局ノード３６による中継処理を経て、局ノード３５に受信されている。
【０１４１】
これに対する応答メッセージが電話機３９，局ノード３５側から送信されると、応答メッセージを収容したＩＰパケットも、前記呼設定メッセージを収容したＩＰパケットと同様に各局ノード（例えば、３６）で処理され、呼設定メッセージと同じ経路を反対方向に転送されるから、局ノード３５，３６間および局ノード３６，３７間で呼が確立され、これらの呼を合成した転送経路を持つ呼として、局ノード３７、３５間の呼も確立される。
【０１４２】
これにより図４の点線で示すように、局ノード３７，３６，３５の経路で、ユーザＵ４３，Ｕ３９の会話音声に対応する音声データを収容したＩＰパケットがやり取りされる通話状態になる。
【０１４３】
一方、前記ゲートキーパ４５が持つ中央帯域管理テーブルＢＭ１１を生成するための動作は次のようになる。
【０１４４】
各局ノードが管理してる帯域管理テーブル（例えば、ＢＢ３５）の内容を各回線のトラヒック量が更新されるたびに制御用のＩＰパケットでゲートキーパ４５に送信するようにすれば、ゲートキーパ４５は、受信した複数の帯域管理テーブルの内容をマージすることにより前記中央帯域管理テーブルＢＭ１１を生成することができ、ＶｏＩＰネットワーク３０の各回線（各リンクＬ１０〜Ｌ１１）に関する使用中の帯域幅を正確に認識することも可能となる。
【０１４５】
これにより、実際の帯域消費量とゲートキーパ４５の認識のあいだのずれがなくなり、適切な帯域管理を行うことが可能となる。
【０１４６】
ただしゲートキーパ４５が実際に適切な帯域管理を行い、その効果をＶｏＩＰネットワーク３０上で発揮するには、実際の帯域消費量とゲートキーパ４５の認識のあいだのずれがないだけでは十分ではなく、上述したようにゲートキーパ４５が、直接的または間接的に、ルーティングテーブル（例えば、ＲＴ３１）の内容を認識している必要がある。
【０１４７】
例えば、図９に示す電話機４０のユーザＵ４０が電話機４４へ電話をかけようとして前記ＡＲＱメッセージがゲートキーパ４５まで届いたとしても、この電話のための呼制御メッセージや音声データを収容したＩＰパケットが、３５，３６，３７の経路（ルータで表現すると、３１，３２，３３の経路）で転送されるか、３５，３８，３７の経路（ルータで表現すると３１，３４，３３の経路）で転送されるかがゲートキーパ４５に判定できなければ、そのアドミッション要求を許可するべきか、拒否するべきか正確に判断できないからである。
【０１４８】
ただしこのような認識は、各帯域管理テーブルの内容を収容した制御用ＩＰパケットの送信元である個々の局ノード３５〜３８を、ゲートキーパ４５が識別するだけで比較的容易に形成することができる。
【０１４９】
この認識があることによって、前記マージを適切に実行して適切な中央帯域管理テーブルＢＭ１１を生成することができる。
【０１５０】
例えば、図８に示す状態の中央帯域管理テーブルＢＭ１１において、上から５つ目の行は回線３５−３７間に対応し、トラヒック量がＶ１１＋Ｖ１３であるが、この行のトラヒック量（およびこの行）は、最上の回線３５−３６間の行のトラヒック量であるＶ１１と、上から３つ目の回線３６−３７間の行のトラヒック量であるＶ１３を加算することによって得られたものである。このような加算は、ゲートキーパ４５が各局ノードを識別できてはじめて可能となるものである。
【０１５１】
一例として、各局ノードを示すＩＰアドレスを予め決めておけば、前記帯域管理テーブル（例えば、ＢＢ３５）の内容を収容した制御用のＩＰパケットが受信されたとき、ゲートキーパ４５は、その送信元ＩＰアドレスをもとに各局ノードを識別することができる。
【０１５２】
（Ａ−３）実施形態の効果
本実施形態によれば、実際の帯域消費量とゲートキーパ（４５）の認識のあいだのずれがなくなり、適切な帯域管理を行うことが可能となる。
【０１５３】
これにより、十分な帯域の余裕があるのにアドミッション要求を拒否することを防止できるので、帯域資源の利用効率が高まる。
【０１５４】
また、十分な帯域の余裕がないのにアドミッション要求を許可することも防止できるため、アドミッション要求の許可後、実際に呼制御や音声通話などを行う段階になって大量のパケット損失や大きな遅延が発生することがなく、通信品質が向上し、通信の信頼性が高まる。
【０１５５】
（Ｂ）他の実施形態
上記実施形態にかかわらず、局ノード（例えば、３５）の機能の一部を自拠点内の他の構成要素に配置してもかまわない。
【０１５６】
なお、上記実施形態では、拠点の数が全部で４つであり、拠点ＳＴ１とＳＴ３のあいだの拠点はＳＴ２（または、ＳＴ４）だけであったが、拠点数は４つより少なくてもよく、多くてもよい。拠点数がもっと多い場合でも、前記中継処理を実行する拠点が増加するだけのことで実質的な動作が変化するわけではない。
【０１５７】
すなわち、中継処理を行う拠点が１つの経路上に多数存在する場合、各拠点内の局ノードごとに同様な中継処理が実行され、局ノードごとに、当該ＩＰパケットの宛先ＩＰアドレスのネットワーク部が変更されることになる。
【０１５８】
また、本発明のネットワーク構成は、図９に示したものに限定する必要がないことは当然である。例えば、メッシュ構造のネットワーク構成にも適用することができる。任意の局ノードが他のすべての局ノードと隣接するフルメッシュ構造（例えば、図２に示したような構造）の場合にも本発明は適用することができる。
【０１５９】
フルメッシュ構造の場合、すべての局ノードが他のすべての局ノードに対し、１ホップでＩＰパケットを転送することが可能であるが、輻輳状態の変化、障害発生、リンクごとの帯域幅の相違などに配慮したＩＰパケットの転送を行うには、よりホップ数の大きい迂回路を取ることが必要となることが起こり得、迂回路を取る場合に、本発明を適用することができる。
【０１６０】
さらに、上記実施形態にかかわらず、各局ノード（例えば、３５）は、中継処理を行うたびに、ゲートキーパ４５のアドミッション制御機能やアドレス変換機能を利用するようにしてもよい。これは、中継処理のなかの前記発信（送信）のたびに、ＡＲＱメッセージの送信や呼設定メッセージの送信を行い、ゲートキーパ４５とシグナリングするものである。この構成によれば、シグナリングのための通信トラヒックの増大や、ゲートキーパ４５の処理負荷の増大などの不利があるものの、ゲートキーパ４５の帯域管理テーブルＢＭ１１に、上述した隣接していない局ノード間で使用中の帯域幅を格納する必要がなくなる等の利点がある。
【０１６１】
また、上記実施形態ではゲートキーパ４５を使用したが、本発明は、ゲートキーパを用いない場合にも適用可能である。
【０１６２】
例えば、各局ノード（例えば、３５）が自身が搭載している帯域管理テーブル（例えば、ＢＢ３５）に基づいて、各呼に関する許可や拒否を行う構成とすることができるからである。
【０１６３】
この構成では、経路上の１または複数の局ノード（例えば、３６）のうち、いずれか１つでも拒否した場合には、全体としてその呼でその経路を使用することはできなくなり、経路上のすべての局ノードが許可した場合にのみ、その呼でその経路を使用することが可能となる。
【０１６４】
なお、上記実施形態において、ゲートキーパ４５を省略し、各局ノードがゲートキーパの機能を搭載するようにしてもよい。その場合、複数ゾーンにまたがる呼設定などに際してはゲートキーパ間の通信が発生することになるが、基本的に、上記実施形態と同様な効果を得ることが可能である。各局ノードが自身が搭載している帯域管理テーブルに基づいて、各呼に関する許可や拒否を行う上述した構成も、各局ノードがゲートキーパの機能を搭載するケースに適用可能である。
【０１６５】
また、上記実施形態では、ＤＥＣＳ方式を用いたが、本発明は上述したように、ＧＫＲＣＳ方式にも適用可能である。
【０１６６】
前記ＧＫＲＣＳ方式の場合、呼が確立したあとにやり取りされるＩＰパケットに着信先電話番号が収容されていないものとすると、ある呼に関し、各局ノード（例えば、３５）が最初に受け取るＩＰパケットには、着信先電話番号が含まれていないことになるため、局ノードがどのようにしてそのＩＰパケットの最終的な宛先を識別し、適切な中継処理を行うかが問題となる。
【０１６７】
この問題を解決するには様々な方法があり得るが、一例として、ＩＰパケットのペイロード部（データ部）の所定の位置に、最終的な宛先を示す宛先ＩＰアドレスを収容するフィールドを用意しておき、中継処理に際しては、その宛先ＩＰアドレスを利用するようにしてもよい。ＩＰヘッダ中の宛先ＩＰアドレスは、各局ノードで隣接する拠点を指定するものに変更されるが、ペイロード部に対してはこのような変更が行われないからである。
【０１６８】
また、局ノードがＶｏＩＰネットワーク３０のネットワーク構成と各拠点のネットワークアドレスを認識していれば、送信元ＩＰアドレスをもとに適切な中継処理を行うことも可能である。
【０１６９】
例えば、局ノード３６が送信元ＩＰアドレスのネットワーク部が拠点ＳＴ１を示すＡＤ１のＩＰパケットを中継する場合、ネットワーク構成から、そのＩＰパケットの最終的な宛先は、拠点ＳＴ３の方向にあることが推測できるため、そのネットワーク部を拠点ＳＴ３のネットワーク部ＡＤ３に変換することで、中継処理を行うことが可能である。
【０１７０】
この場合、局ノード３６は最終的な宛先を特定しているわけではないが、ＶｏＩＰネットワークが図９に示すような比較的簡単な構成であれば、十分に対応可能である。
【０１７１】
なお、上記実施形態では、局ノードは、ユーザ企業などの拠点の構成要素であるものとしたが、必ずしもその必要はない。特に中継処理を行う局ノードは、ＰＢＸとしての機能のすべてを持つことが必須であるわけではないので、必ずしも配下に電話機（例えば、４１など）を収容している必要もない。例えば、通信事業者が、もっぱら中継処理だけを目的に、このようなＰＢＸとしての機能を持たない局ノードを設置することも可能である。
【０１７２】
また、上記実施形態では、主としてリンク（例えば、Ｌ１１）がディジタル専用線である場合を想定したが、リンクがディジタル専用線に限定されるものではないことは、すでに述べた通りである。本発明は、ＩＰ−ＶＰＮ網などにも適用可能である。
【０１７３】
なお、ルーティングテーブルに経路情報（前記宛先ＩＰアドレスとネクストホップの対応関係）を設定する方法には、ネットワーク管理者などが予め手作業で設定しておくスタティックルーティングと、ルーティングプロトコルを利用して動的に設定するダイナミックルーティングがあるが、そのいずれに対しても、本発明は適用可能である。
【０１７４】
ただしダイナミックルーティングの場合には、ＶｏＩＰネットワークの各経路における障害発生や輻輳状態の発生などに応じて、ルーティングテーブルの内容（すなわち、経路情報）が動的に変更され得るから、その変更に応じて、前記変換テーブル（例えば、ＴＴ３５Ａ、ＴＴ３５Ｂ）の内容を変更することが望ましい。
【０１７５】
もちろん、スタティックルーティングの場合でも、経路情報を変更した場合には、変換テーブルの内容を変更することが望ましいことは同じである。
【０１７６】
ルーティングテーブルの経路情報に合わせて変換テーブルの内容を変更しなければ、局ノード（例えば、３５）の動作とルータ（例えば、３１）の動作が複合された結果として、ＶｏＩＰのためのＩＰパケットが同じリンク（例えば、Ｌ１１）を２度伝送されること等が起こり得、伝送効率の低下や、実際の帯域消費量とゲートキーパ４５の認識の間のずれの発生などの問題が起きるからである。
【０１７７】
局ノードがルータとしてのインタフェースを隣接するルータ（例えば、図９の例では、局ノード３５の場合、ルータ３１が隣接するルータ）に対してルータとしてのインタフェースを提供し、ダイナミックルーティングに応じた経路情報の交換などを実行する構成とすれば、局ノードが経路情報の変更を自動的に認識することが可能である。
【０１７８】
また、局ノードがｔｒａｃｅｒｏｕｔｅコマンドを定期的に実行して前回の実行結果と比較解析すること等により、経路情報の変更を自動的に認識することも可能である。この方法は、ダイナミックルーティングだけでなく、スタティックルーティングに対しても有効である。また、ｔｒａｃｅｒｏｕｔｅコマンドの宛先を変更することにより、隣接するルータの経路情報だけでなく、ＶｏＩＰネットワーク上の全ルータの経路情報の変更を認識することも可能である。
【０１７９】
なお、上記実施形態では、ＶｏＩＰを例に説明したが、本発明は、音声データ以外の情報（例えば、動画像データなど）を収容したＩＰパケットを通信する場合などにも適用することが可能である。例えば、ビデオ会議などを行う場合には、動画像データを転送することが必要になる。
【０１８０】
また、本発明では、ＯＳＩ参照モデルのネットワーク層のプロトコルを、ＩＰプロトコルに限定する必要はない。
【０１８１】
以上の説明では主としてハードウエア的に本発明を実現したが、本発明はソフトウエア的に実現することも可能である。
【０１８２】
【発明の効果】
以上に説明したように、本発明によれば、リアルタイム通信に関し、帯域資源の利用効率を高めるとともに、通信の信頼性を高めることが可能になる。
【図面の簡単な説明】
【図１】実施形態に係るＶｏＩＰネットワークで使用する局ノードの動作例を示すフローチャートである。
【図２】発明が解決しようとする課題を説明するためのＶｏＩＰネットワークの全体構成例を示す概略図である。
【図３】図２に示したＶｏＩＰネットワークの動作説明図である。
【図４】実施形態の動作説明図である。
【図５】実施形態の動作説明図である。
【図６】実施形態の動作説明図である。
【図７】実施形態の動作説明図である。
【図８】実施形態の動作説明図である。
【図９】実施形態に係るＶｏＩＰネットワークの全体構成例を示す概略図である。
【図１０】実施形態の動作説明図である。
【図１１】実施形態に係るＶｏＩＰネットワークで使用する局ノードの内部構成例を示す概略図である。
【図１２】実施形態に係るＶｏＩＰネットワークで使用するルータの内部構成例を示す概略図である。
【図１３】実施形態に係るＶｏＩＰネットワークで使用するルータが搭載するルーティングテーブルの構成例を示す概略図である。
【図１４】実施形態の動作説明図である。
【図１５】実施形態に係るＶｏＩＰネットワークで使用する局ノードが搭載する変換テーブルの構成例を示す概略図である。
【符号の説明】
１０、３０…ＶｏＩＰネットワーク、１１〜１４，３１〜３４…ルータ、１５〜１８，３５〜３８…局ノード、１９〜２４、３９〜４４…電話機、２５，４５…ゲートキーパ、Ｌ１〜Ｌ６、Ｌ１０〜Ｌ１３…リンク、ＮＢ１〜ＮＢ４…局番、ＮＢ１１〜ＮＢ３３…電話番号、ＲＴ３１…ＲＴ３４…ルーティングテーブル、ＴＴ３５〜ＴＴ３８…変換テーブル、ＳＴ１〜ＳＴ４…拠点（ＬＡＮ）。

Claims (2)

1. 所定の通信ネットワーク上で所定の単位信号を用いたリアルタイム通信を実行するために帯域管理を行う帯域管理システムにおいて、
   予め搭載してある第１の経路表と、前記単位信号が有する第１の宛先識別子をもとに、前記単位信号の経路を決定して中継処理を行う複数の第１の中継装置と、
   予め搭載してある第２の経路表と、前記リアルタイム通信の最終的な宛先を指定するために当該単位信号が有する第２の宛先識別子をもとに、当該単位信号の経路を決定して中継処理を行う複数の第２の中継装置とを備え、
   当該第２の中継装置は、
   前記通信ネットワークの構造上、前記リアルタイム通信の最終的な宛先までの経路が複数存在する場合、前記第２の経路表をもとに、いずれか１つの経路を選択し、その選択結果に応じて前記第１の宛先識別子を書き換えることを特徴とする帯域管理システム。
2. 請求項１の帯域管理システムにおいて、
   前記リアルタイム通信に関し、前記通信ネットワーク全体の帯域管理を一元的に行う帯域管理装置を備え、
   前記第２の中継装置は、
   前記通信ネットワークの帯域資源の利用を要求する前記単位信号を受け取ったとき、その要求に応じた帯域の割り当てを、前記帯域管理装置に対して提案する帯域管理部を有し、
   前記帯域管理装置が、当該提案を承認するか否かに応じて、前記通信ネットワーク全体の帯域管理を行うことを特徴とする帯域管理システム。

Images