JP2004508772A - Ｉｐ電話通信システムにおけるトポロジを認識したリソース・マネージャーおよびその方法 - Google Patents

Abstract

本発明は、通信ネットワークにおける方法および装置に関する。本発明の目的は、ＩＰ電話通信システム内のリソース管理問題および許可制御を処理する方法を提供することである。当該目的は、トポロジ認識リソース・マネージャーがＩＰネットワークに関するルーティング情報を収集すること、ＩＰネットワーク内のリソースに関するリソース情報を取得すること、前述のルーティング情報とリソース情報とを結合することによってリソース・マップを作成すること、および前述のリソース・マップとゲートキーパーとの相互作用とによってシステム内のリソース管理問題と許可制御とを実行することによって実現される。

Description

【０００１】
本発明は、独立クレームの序文に沿った通信ネットワークにおける方法および装置に関する。更に特定すれば、本発明は、ＩＰ電話通信システム内のＩＰ電話リソース管理問題、および許可制御に関する。
（発明の背景）
電話通信は、人類において最も重要な発明品の１つである。１８７６年３月１０日に電信電話が誕生して以来、通信機能を必要とする各人、且つ全ての人に銅配線を取り付けることによって、当該技術は世界中に広まった。発信者と受信者との間を銅線でつなぎ合わせることによってこれらの間は接続され、結果的に発信者と受信者は自分の回線を介して互いに通信を行うことが可能となった。この種の技術は、回線変換電話通信として知られている。古典的電話通信に通じているものであれば誰でも、例えば、エリクソン社（Ｅｒｉｃｓｓｏｎ　Ｃｏｒｐｏｒａｔｉｏｎ）が自社の交換ソリューションとして開発したＡＸＥプラットフォームを備えたこの回線交換型電話通信において大きな進展があったことを理解している。ネットワーク内での統計的多重化に関する知識によって、世界中をカバーするネットワークを、限られたコストで構築することが可能となった。
【０００２】
この１０年のうちに、古典的回線変換電話通信サービスは、インターネット・プロトコル・スイート・トランスポート・コントロール・プロトコル／インターネット・プロトコル（ＴＣＰ）／（ＩＰ）を基に構築された費用効率の更に高いパケット変換型電話通信において競合品に出会った。当該電話通信は、通常ＩＰ電話通信と呼ばれ、現在では標準化され、これまでの回線交換電話通信に代わって多く設置されている。
【０００３】
パケット交換ＩＰ電話通信ネットワークは、一般的には、ＯＳＰＦ（Ｍｏｙ　Ｊ．、ＯＳＰＦ　Ｖｅｒｓｉｏｎ　２、ＩＥＴＦ、ＲＦＣ２３２８）、ＩＳ−ＩＳ（Ｏｒａｎ　Ｄ、ＯＳＩ　ＩＳ−ＩＳ　Ｉｎｔｒａ−ｄｏｍａｉｎ　Ｒｏｕｔｉｎｇ　Ｐｒｏｔｃｏｌ、ＩＥＴＦ、ＲＦＣ１１４２）またはＲＩＰ（Ｍａｌｋｉｎ　Ｇ．、ＲＩＰ　Ｖｅｒｓｉｏｎ　２、ＩＥＴＦ、ＲＦＣ２４５３）のような周知のＩＰルーティング・プロトコルの１つを用いて経路設定される。これらのプロトコルはルート演算し、さらにルーティング情報を分布するためにこれらのプロトコルが用いるアルゴリズムに基づいて、リンク・ステートまたは距離ベクトル・プロトコルとして分類することができる。あるドメイン内のリンク・ステート・プロトコルを実行させる全てのルーターは、ネットワークを完璧に検分し、当該ドメイン内の全てのネットワークおよびルーターを理解する。距離ベクトル・ルータは（直接接続された）すぐまわりの環境におけるルーターとネットワークだけを理解する。
【０００４】
市販のＩＰ電話通信システムの殆どは、国際電気通信連合−電話通信（ＩＴＵ−Ｔ）勧告Ｈ．３２３に準拠する。この勧告は、大手のＩＰ電話通信メーカのシステム・ソリューションに早期に採り入れられた。図１において、Ｈ．３２３システムにおける主要構成成分の概要が示されている。
これらの主要構成成分は、端末Ｔ、ゲートウエイＧ、およびゲートキーパーＧｋである。これら三つの第１構成成分は、Ｈ．３２３システムのエンドポイントと呼ばれる。なぜなら、これらはメディア・ストリームを起動または終了させることができるからである。ゲートキーパーは、Ｈ．３２３システムのマネージャーである。管理ドメインはゾーンと呼ばれる。各領域において、１つの、１つだけのゲートキーパーが使用可能である。
【０００５】
端末
端末Ｔは、リアル・タイムの双方向通信を実現するエンドポイントである。即ち、端末は、ゲートウエイを介して別のＨ．３２３端末Ｔまたは別の通信システムとの間で話をし、聴くことができる。また、ＭＣＵを介してマルチポイント会議に参加することができる。ＭＣＵについては、以下で紹介する。Ｈ．３２３端末Ｔは音声サービスに対応することが必要である。音声サービスに加えて、端末Ｔもまたビデオ・サービスおよびデータ・サービスを提供できるが、これらはオプションである。また、チャネル使用に関して交渉し、エンドポイント間で機能交換を行うことができるためには、端末ＴはＨ．２４５にも対応することが必要である。その他の必須の構成成分には、呼設定、Ｑ．９３１を介したシグナリング、ゲートキーパー通信用のレジステトレーション／許可／ステータス（ＲＡＳ）、および例えば音声、ビデオのようなリアル・タイム・サービスの搬送用ＲＴＰ／ＲＴＣＰがある。
これらの必須の構成成分に加えて、端末ＴもＭＣＵ機能を有することができる。
【０００６】
ゲートウエイ
ゲートウエイＧはＨ．３２３システムと、別の電気通信システム、例えばＰＳＴＮ、との間のインターフェースである。ゲートウエイＧはオプションであり、エンドポイントが別の端末タイプ１０２、例えばＩＳＤＮ、ＰＳＴＮ等と通信を行う時にだけ必要とされる。ゲートウエイＧはＨ．３２３システムと非Ｈ．３２３システムとの間の呼制御、および呼搬送変換の双方を扱う。
【０００７】
マルチポイント制御装置
マルチポイント制御装置（ＭＣＵ）は、３つ以上のエンドポイント間での会議に対応する。ＭＣＵは強制的マルチポイント制御装置（ＭＣ）、および場合によっては１つ以上のマルチポイント・プロセッサ（ＭＰ）を備える。ＭＣは、別のエンドポイント、例えば端末と同じ場所に配置することができる。ＭＣは、オーディオとビデオとの機能交換中の端末間交渉にあたる。また、ＭＣは関連のメディア・ストリームのいずれかをマルチキャストと一緒に分散するか否かを判定する。メディア・ストリームを混合する必要がある場合には、ＭＰがこれにあたる。図２に示すように、マルチポイント通信は集中型、または分散型のいずれかの方法で行うことができる。集中マルチポイント会議では、エンドポイントＥ間の通信は全てＭＣを介して行う。ＭＣにおいては、メディア・ストリームは混ぜ合わされ、関与するエンドポイントＥに分散される。分散型マルチポイント会議においては、エンドポイントＥ自身がメディア・ストリームを分散している間にＭＣが交渉にあたる。この分散は、リソース効率の高い技術のマルチキャストと一緒に行うことができる。ユニキャスト・メディア分散のメッシュもまた使用できる。集中型および分散型分散方法の他に、これらの間のハイブリッドも可能である。
【０００８】
ゲートキーパー
ゲートキーパーＧｋはＨ．３２３対応のネットワークの最も重要な構成成分である。ゲートキーパーは、アドレス変換、および帯域幅管理という二つの重要な呼管理機能を果たす。アドレス変換とは、ゲートキーパーＧｋが、端末およびゲートウエイのエイリアスをＩＰアドレスに変換することを意味する。帯域幅管理の実施態様はメーカ固有のものである。一般的に使用される方法は、ゲートキーパーＧｋが管理するゾーン内で行われる同時の呼の数の閾値を特定することである。その他の方法が存在するが、それらはそのケースにおいてはメーカ固有のものである。呼は、エンドポイント間で直接に、またはゲートキーパーＧｋを介して行うことができる。後者はゲートキーパー経路設定呼と呼ばれる。
Ｈ．３２３は、主として無保証品質のサービス・ネットワーク用に開発されたが、勧告は拡大され、クオリティ・オブ・サービス（ＱｏＳ）問題も対象として含むようになった。例えば、ＲＳＶＰを用いたＨ．３２３に対するＱｏＳサポートは、１９９７年ジュネーブで発行されたＩＴＵ−Ｔ勧告Ｖ．２の補遺ＩＩ、「パケット使用のマルチメディア通信システム」の中で論じられている。
【０００９】
トポロジ認識、および経路反応許可制御の欠如はＨ．３２３ゲートキーパーの現在の実施態様の最も重大な難点である。Ｈ．３２３対応のネットワーク３００用のトポロジが図３に示されている。当該ネットワークにおいて、３つのエッジ・ルーターＥＲ、１つのゲートキーパーＧｋ、およびＰＳＴＮにつながる１つのゲートウエイＧがある。当該ネットワークでは、ＬＡＮセグメントを接続するルーターＲは、地理的に、例えば、ストックホルム（Ｓｔｏｃｋｈｏｌｍ）、イェーテボリー（Ｇｏｔｈｅｎｂｕｒｇ）、マルメー（Ｍａｌｍｏ）等に分散している。これらの地理的に分散したルーターＲ間では、帯域幅は制限される。ゲートキーパーＧｋは、そのときのゾーンを規定するネットワーク全体を管理する。ゲートキーパーＧｋとゲートウエイＧとは地理的にユーザの数が最大であるところに設置される。ゲートキーパーＧｋはどこにでも設置可能であるが、実際上の理由から同じ場所に設置する。ゲートウエイＧは、論理的には通話が最も多く行われるところに設置する。この結果、その他のネットワークを介した呼の経路設定は減少することになる。その他のネットワークとは、即ちゲートウエイＧが大多数のユーザから離れたＬＡＮセグメントに設置された場合である。
Ｘ同時呼がヒューリスティックに基づくようにゲートキーパーＧｋを構成することができる。知覚された品質が劣化した場合、同時呼の閾値を減少させることができる。ヒューリスティックな決定は問題を生ずる。あるユーザが、悪意あるなしに関係なく、低レベルながらサービス全てを使用し、他のユーザは利用できない場合がある。細いボトルネック・リンクを用いたセッションをスタートすることによって、ヒューリスティックスは調整され、ゾーン内で許可されるセッションは極めて少なくなる。その際、そのボトルネック・リンクがそれらのセッションにかかわっていない場合であっても、充分に供給されたリンク（ｗｅｌｌ−ｐｒｏｖｉｓｉｏｎｅｄ　ｌｉｎｋｓ）に接続されたその他のユーザはアクセスを拒絶される。利用形態に幾分かでも変化が生ずる、またはトポロジに変化が生ずると別の問題が発生する。ユーザの行動形態に変化が生ずると、細い、または負荷のかかったリンクを通じて呼を経路設定させるユーザが通常よりも多くなり、これによってパケットの欠落または遅延増大を招く恐れがある。リンク不具合の原因によって、トポロジに変化が生ずる恐れがある。このことは、パケット経路再設定の原因となり、パケットがネットワークを介して代替経路を選ぶ。また、トポロジの変化によって、リンク特性が幾分変化する。例えば、帯域幅、遅延の増大または減少等である。
【００１０】
別の問題は、直接呼が許可された場合、ゲートキーパー経路設定の呼に高いサービス品質が保証されないことである。ゲートキーパーＧｋが、あるゾーンでゲートキーパー経路設定呼に対する帯域幅管理を行っていて同時の直接呼を認識しない場合、トラフィックの全体量がリンクによっては使用可能な帯域幅を超えてしまう恐れがある。ここでの問題は、ゲートキーパー経路設定呼および直接呼がいずれも同一のリソースを用いることである。この原因は、ゲートキーパーＧｋが帯域幅管理を行い、ゲートキーパーが経路設定した呼の要求を許可する一方で、当該ネットワーク内の帯域幅を使用することをゲートキーパーに通知せずに、直接呼が発信されることである。ＩＰ電話通信ネットワークにおいて直接呼を用いる場合、サービスの差別化、即ち重要な呼に優先順位を付け、これを重要性のより低い呼よりも先に転送するネットワーク・エレメント内の機構が、何らかのサービス保証が必要とされる場合には直ちに必要となる。そこで、ゲートキーパーが許可した呼には重要印が付けられて転送され、一方直接呼は重要性のより低い印が付けられる。
【００１１】
進行中の呼に関して問題発生がする恐れがある。それは、セッションに加わりたいエンドポイントが更にあり、これらのエンドポイントがリソースを使用することができないネットワーク・セグメント上に位置するか、または使用可能なリソースが不十分なため予測可能なサービスを提供することができないところに位置する場合である。この問題が発生するのは、２つよりも多いエンドポイントに係る複数パート会議がある場合だけである。
【００１２】
更に別の問題は、異なるＨ．３２３ゾーンがＨ．３２３に不対応のネットワークによって分けられることである。現在このケースにおいて予測可能なサービスを提供する手段はない。なぜなら、非Ｈ．３２３ネットワークにおいては、リソースは制御されないからである。
【００１３】
現在ＲＳＶＰを用いたＨ．３２３用のＱｏＳサポートを開発中である。しかしながら、ＲＳＶＰを用いたＱｏＳサポートはスケーラブルではない。特に、Ｈ．３２３不対応のネットワークが存在する異なったゾーン内のエンドポイント間で通話される呼がある場合にはスケーラブルではない。ＲＳＶＰは呼毎にシグナリングおよび予約を行い、これによってネットワークは、有用なトラフィックの替わりにシグナリング、即ちメディア・ストリームで負荷され、呼毎にルーター内の状態がセットアップされる。
【００１４】
現在のＨ．３２３システムでは、前もって予約することはできないため、予測される品質のミーティングを計画することは困難である。
【００１５】
Ｈ．３２３標準における更に別の問題は、帯域幅要求は常に許可されるかまたは拒絶されることである。帯域幅管理機能性とエンド・ユーザとの間の更に柔軟な手法が望まれている。
【００１６】
欧州の特許文書第ＥＰ ０９４２５６０号は、適応パケット規模の音声搬送用装置および方法を開示している。当該装置および方法の目的は、ネットワーク・トラフィック、および２つのＩＰ電話通信装置間のネットワーク・トポロジにおける低能力のルーターが原因で生ずるエンド・ツー・エンド遅延を極力小さくすることである。この目的は音声搬送用にパケット規模を採用することによって達成される。しかしながら、当該文書は、音声搬送システムにおいて許可制御をいかに行うことができるかに関して、即ち、セッション開始前にネットワークに容量が充分にあるか否かを評価し、許可決定をシステムに伝えることについては取り組んでいない。
【００１７】
（発明の摘要）
本発明の目的は、ＩＰ電話通信システム内のリソース管理問題および許可制御を取り扱う方法を提供することである。
【００１８】
上記の目的は、独立クレームの特徴とする部分による方法、リソース・マネージャー、およびシステムによって達成される。
【００１９】
本発明によって提供されるトポロジを認識したリソース・マネージャーが、ＩＰネットワークに関するルーティング情報を収集する手段と、ＩＰネットワーク内のリソースに関するリソース情報を取得する手段と、前述のルーティング情報とリソース情報とを結合することによってリソース・マップを作成する手段と、ゲートキーパーと相互作用する手段とを備えることによって、リソース・マネージャーは、リソース管理問題、およびシステム内の許可制御を行うことが可能となる。
【００２０】
本発明が提供する方法は、
−ＩＰネットワークに関するルーティング・情報を収集するステップと、
−ＩＰネットワーク内のリソースに関するリソース情報を取得するステップと、
−前述のルーティング情報とリソース情報とを結合する手段によってリソース・マップを作成するステップと、
からなり、前述のリソース・マップによって、且つゲートキーパーと相互に作用することによって、システム内のリソース管理問題および許可制御を行うことが可能とする。
【００２１】
好適な実施形態は従属クレームに明記する。
【００２２】
本発明の利点の１つは、実現されるネットワーク使用率が高まることである。
【００２３】
本発明の別の利点は、あるトラフィックを優先することができ、さらに同じネットワークにおいてその他のトラフィックが可能となることである。これによって、柔軟なソリューションが得られる。
【００２４】
本発明の別の利点は、リソースを前もって予約することができ、ミーティングおよびイベントを計画することができることである。
【００２５】
本発明の更に別の利点は、非Ｈ．３２３ドメインにおいてＱｏＳがドメイン間通信リソース・マネージャーに対応する場合、非Ｈ．３２３ドメインを介して予測可能な品質の呼が得られることである。これらのゾーン間セグメントにおいては、リソースを前もって予約してトラフィックを集計し、これらのセグメント、即ちトランク帯域幅、における呼毎のシグナリングを回避することできる。これは、これまでに説明した技術の非常にリソース効率の高い機能である。事前の予約は、時間経過につれた変化が認められる。例えば、稼働時間中に予約する帯域幅はより広く、その他の時にはより狭い帯域幅を予約する。即ち、説明した技術のユーザは、時間経過に伴うリソースの必要度を予測することによってリソースを計画に組み込むことができる。
【００２６】
本発明の別の利点は、サービス・プロバイダとエンド・ユーザとの間の柔軟な相互作用である。それは、カスタマが必要とすれば、完全なリソース・マップによって提供可能である。
【００２７】
（好適な実施形態の詳細な説明）
図４は、本発明の第１実施形態によるＩＰ電話通信システム４００内のトポロジを認識したリソース・マネージャー・エンティティＲＭの一例を示すブロック図である。リソース・マネージャーＲＭはトポロジを認識したリソース・マネージャー機能を備える。それは、ＩＰ電話通信システム、例えば、Ｈ．３２３システムにおいて構成される。かかるシステムは、上記の図１において「本発明の背景」のもとに説明されている。したがって、ＩＰ電話通信システムは、通常の場合、リソース・マネージャーＲＭに加えて、１つまたは多数のゲートキーパーＧｋ、ゲートウエイＧ、および端末のようなＩＰ電話通信構成成分、ならびにルーターＲ、エッジ・ルーターＥＲ、およびその端末が通常の場合接続可能であるローカル・エリア・ネットワーク（ＬＡＮ）セグメントのようなＩＰネットワーク・エレメントを備える。ＩＰ電話通信システム（４００）を用いると、エンド・ユーザはマルチメディア用送信手段としてＩＰネットワークを使用することが可能となる。
【００２８】
リソース・マネージャーＲＭは、ゲートキーパーＧｋと相互に作用し、開始されて進行中の呼に対する全てのリソース管理問題、および呼設定要求に対する許可制御を取り扱う。ＲＭとＧｋとの間の相互作用は、例えば通信プロトコル、プロセス間通信、統合されたソフトウエア・モジュール間の機能呼等を介した多くの方法において実現可能である。
【００２９】
トポロジ認識によって正確なルーティングおよび正確なリソース情報が得られるが、これはリソース管理および許可制御を行うシステムにとっては必要不可欠である。リソース・マネージャーＲＭは、ＩＰネットワークに関するルーティング情報、即ちＩＰネットワークのトポロジを取得する。
【００３０】
ＩＰネットワークが、リンク・ステート・ルーティング・プロトコルを用いて経路設定される場合、リソース・マネージャーＲＭはルーティングに参加し、且つルーターとして作用する。即ちリソース・マネージャーＲＭは、他のルーターと同等（ｐｅｅｒ）であって、自身のルートはなんら通告することなく、ＩＰネットワークのルーティング情報を取得する。リンク・ステート・プロトコル構築の際基準とした基本動作原理によって、全てのルーターは完全なルーティング・情報を有することが確実と成る。リソース・マネージャーＲＭはルーティング・プロトコルに参加する場合、ルーティング・ドメイン内の他の全てのルーターと同等の速い速度でルーティング情報を受け取ることによりトポロジの変化を即座に検出することができる。
距離ベクトル・プロトコル、即ち静的ルーティング、を用いてＩＰネットワークを経路設定する場合、ピアリング（ｐｅｅｒｉｎｇ）方法は使用することができない。この場合、ルーティング情報は、トレース・ルート（Ｋｅｓｓｌｅｒ　Ｇ．による「インターネットおよびＴＣＰ／ＩＰツールに関する手引書」ＩＥＴＦ、ＲＦＣ１７３９を参照されたい）のような測定法、および／または簡単なネットワーク管理プロトコル（ＳＮＭＰ）オート・ディスカバリ（Ｋｅｓｈａｖその他による１９９８年７月発行の「インターネット・トポロジを発見すること（Ｄｉｓｃｏｖｅｒｉｎｇ　Ｉｎｔｅｒｎｅｔ　Ｔｏｐｏｌｏｇｙ）」ｈｔｔｐ：／／ｗｗｗ．ｃｓ．ｃｏｒｎｅｌｌ．ｅｄｕ／ｓｋｅｓｈａｖ／ｐａｐｅｒｓ／ｄｉｓｃｏｖｅｒｙ．ｐｄｆ を参照されたい）を使用することによって取得される。ＳＮＭＰは複雑なネットワークを管理するためのプロトコル集合である。リソース・マネージャーＲＭはルーティング情報を受け取ると、ＳＮＭＰ（Ｃａｓｅその他による「インターネット標準ネットワーク管理フレームワークのバージョン３の手引き」ＩＥＴＦ、ＲＦＣ２５７０を参照されたい）のようなネットワーク管理プロトコルを用いてルーターおよびそれらのインターフェース（例えばインターフェースのタイプおよびスピード）に関する情報を収集する。ＲＭはこの情報を用いて取得済みのルーティング情報を補完し、正確なルーティング・トポロジを確実に有するようにする。
リソース・マネージャーＲＭはルーティング情報、およびＧｋからの設定要求から入手するリソース情報を結合してリソース・マップを作成する。リソース・マップは、リンク毎に、時間が経過するにつれてどれだけのリソース（例えば帯域幅）が使用可能且つ予約されるかに関する情報を含む。ある人が始めようとしている呼のために使用可能なリソースがあるか否かの判定をゲートキーパーＧｋが行う際、リソース・マネージャーＲＭはリソース・マップを用いてこれを支援する。
ゲートキーパーが呼を経路設定した場合、端末から発信された呼を許可するか、または拒絶するかをゲートキーパーＧｋが担当する。ゲートキーパーＧｋは、リソース・マネージャーＲＭと相互に作用し、ソース・エンドポイントと宛先エンドポイントとの間に経路設定された経路を介したリソースで、予測可能な品質を与えるのに充分なリソースがあるか否かに関して、リソース・マネージャーＲＭに問う。リソース・マネージャーＲＭは当該質問に答えて、呼がどのネットワーク経路を使用するかを評価し、当該経路に沿ったリンク毎に、当該呼を許可するための充分なリソースがあるか否かを算出する。即ち、リソース・マネージャーＲＭは、リソース要求を基に経路反応性許可制御（Ｐａｔｈ−ｓｅｎｓｉｔｉｖｅ　ａｄｍｉｓｓｉｏｎ　ｃｏｎｔｏｒｏｌ）を行う。許可制御は、リソース・マップ内の情報に基づいて行われる。これによって、ユーザの行動変化として取り組んだ上記の問題は解決される。ヒューリスティック・モデルはユーザの行動変化に対応することはできないが、トポロジを認識したリソース・マネージャーは、リソース利用に関する最新情報を採り入れることによってこれに対応する。サービス拒絶問題についても同じことが当てはまる。
【００３１】
上記で取り組んだ別の問題はトポロジの変化である。リソース・マネージャーＲＭはＩＰ電話通信システムにおいて進行中の呼を監視し、どんな変化であれ変化が発生する度にリンク毎のリソース使用量を計算し直す。即ち、リソース・マップを更新する。更新したソース・マップが、リソースが不十分であるために進行中の呼を実現することができないことを示すと、リソース・マネージャーＲＭはこのことをゲートキーパーＧｋに報告する。今しがた説明したようにリソースが不十分な場合には、リソース・マネージャーＲＭまたはゲートキーパーＧｋに、どの呼を続行し、どの呼を終了させるべきかの優先順位を付けさせることができる。この優先順位付けを行うことによって、関与するものすべの品質が劣化するという事態は回避される。またこの優先順位付けによって、呼損は極力小さくする。トポロジ変化発生の都度サービスに優先順位付けを行う別の方法は、音声サービスと比較してビデオ・ストリームの方が低い優先順位となるようにすることである。
【００３２】
図５は、本発明の第２実施形態によるＩＰ電話通信システム５００内のトポロジを認識したリソース・マネージャー・エンティティＲＭの一例を示すブロック図である。当該第２の実施形態では、２つよりも多いエンドポイントを伴う複数パート会議シナリオにおいて、リソース・マネージャーＲＭが用いられている。複数パート会議には、マルチポイント制御装置ＭＣが通信に常に関わっている。図５に示すＩＰ電話通信システムは、通常の場合、図４に示すＩＰ電話通信システムと同一である。但し、図５に示すシステムは、マルチ−ポイント制御装置ＭＣを更に備える。当該システムは１個よりも多いマルチ−ポイント制御装置を備える場合がある。マルチ−ポイント制御装置ＭＣは複数パート会議にどのエンドポイントが参加するかに関する知識を有し、またＭＣはこれらのエンドポイントを制御する。リソース・マネージャーＲＭは、直接、またはゲートキーパーＧｋを介して間接的に、Ｇｋに対し行ったのと同じ方法で、マルチ−ポイント制御装置ＭＣに対し許可制御を行う。当該方法については上述した。この場合、リソース要求は２つよりも多いエンドポイントを含む場合もある。
【００３３】
複数パートの会議呼においては、参加者をできる限りリソース効率よく追加するというタスクが発生する。この場合、リソース・マネージャーＲＭは、リソース・マップによるマルチポイント制御装置ＭＣを推奨する。その分散方法（集中型／分散型またはこれらの間の適切な混成）を用いることによって、新たに加わったパートはセッションにリソース効率のよい方法で参加することが可能となる。分散方法の使用はリソース・マップに応ずる。したがって、リソース・マネージャーＲＭだけがこれに応える可能性を有している。
【００３４】
予測可能な品質のリソースを使用できない場合、これに対処する別の方法がある。ユーザは、優先順位なしにサービスを受けることができるか、またはリソース不足のために会議参加を拒絶される恐れがある。
異なる優先順位を用いる場合、一方が優先されもう一方は優先されない２つのマルチキャスト・セッションか、リソース不足影響を受けるパートに対する異なるユニキャスト・セッションのいずれかがなければならない。
−マルチキャストの場合、予測可能リソースのより少ないパートは、優先権のないセッションを聴くため、ネットワークの当該パートにトラフィックが配布されることは皆無である。
−ユニキャストの場合、セッションの１つのパートは、そのトラフィックを優先権のないユニキャストとして予測可能リソース無しのパートに取り次ぐことができる。
【００３５】
ユニキャスト、マルチキャストのいずれの場合でも帯域幅要求は許可されるかまたは拒絶される。エンド・ユーザの立場からすれば、条件付で拒絶されるほうがより好都合であり、本発明によるリソース・マネージャーＲＭを使用すればそれが可能となる。
例えば、エンド・ユーザは６４ｋｂｉｔ／秒の音声サービスと１２８ｋｂｉｔ／秒のビデオとを要求する。この要求を満たすために使用可能なリソースは充分ではないが、１２８ｋｂｉｔ／秒だけは使用可能である。リソース・マネージャーＲＭが、リソース・マップを利用して発見するからである。このときのリソース・マネージャーＲＭからの応答は、例えば、「あなたの要求を満たすことはできませんが、１２８ｋｂｉｔ／秒だけはあなたのために予約可能です。これらの１２８ｋｂｉｔ／秒を予約するためには、５分以内にこのメッセージに応答してください。」といったようなものである。事前のリソース予約は、リソース・マネージャーＲＭによって、ゲートキーパーＧｋまたはマルチ−ポイント制御装置ＭＣのからの元の要求に基づいて行われる。従って、この事前予約要求は、このメッセージに対する応答がリソース・マネージャーＲＭからゲートキーパーＧｋまたはＭＣに送られない場合には取り消される。エンド・ユーザとしてはその場合、もう一方のサービスを選んで優先順位をつけことができる。即ち、サービスの中からもう一方のものを選びたい場合である。同じことは、考慮されるサービスが１つしかない場合にも当てはまる。ユーザは例えば高品質の音声の実行を希望するが、リソース不足によって、品質予測不能の高品質音声ではなく予測可能品質の中程度の品質音声を甘受する。
【００３６】
最新技術がＨ．３２３を記述し、本発明によるソリューションがその勧告に適合しているとしても、その他の類似のＩＰ電話通信ソリューションも可能である。例えば、同じソリュ−ションが適用されるＩＥＴＦ標準ＳＩＰに基づいた競合のＩＰ電話通信ソリューションが存在する。
【００３７】
リソース・マネージャーＲＭは、上述の方法ステップを実行するための手段を備える。
【００３８】
リソース・マネージャーの機能は、機能を果たすためのソフトウエア・コード手段を備えたコンピュータ・プログラム製品によって実現される。当該コンピュータ・プログラムは、ゲートキーパーと相互に作用する独立型のサーバ上で実行されるか、またはゲートキーパーと同じ機能のハードウエア上で実行される。コンピュータ・プログラムは、ゲートキーパー機能を実行するソフトウエアと統合することができ、また、ルーターまたはその他のネットワーク・エンティティ上で走ることもできる。また、リソース・マネージャー機能を、分布させ多数のノード上で走らせ、および／またはネットワークを通じて地理的に分布させることもできる。上述のことはゲートキーパーと同じ機能を果たすその他のエンティティとの相互作用にも当てはまることである。コンピュータ・プログラムは直接ロードするか、またはフロッピ・ディスク、ＣＤ、インターネット等のようなコンピュータ使用可能媒体からロードする。
【００３９】
本発明は、上述の好適な実施形態に限定されるものではない。種々の代替物、変形、等価物が使用可能である。したがって、上述の実施形態は、本発明の範囲を制限するものとして看做してはならず、添付の特許請求の範囲によって規定されるものとする。
【００４０】
【図面の簡単な説明】
図１乃至図３は、最新技術に関し、上記に説明されている。
【図１】
図１は、最新技術によるＨ．３２３システムの主要構成成分の概略である。
【図２】
図２は、最新技術によるマルチポイント通信を描く図である。
【図３】
図３は、最新技術によるＨ．３２３対応ネットワーク用トポロジを示すブロック図である。
【図４】
図４は、本発明の第１実施形態によるＩＰ電話通信システム内のトポロジを認識したリソース・マネージャー・エンティティＲＭの一例を示すブロック図である。
【図５】
図５は、本発明の第２実施形態によるＩＰ電話通信システム５００内のトポロジを認識したリソース・マネージャー・エンティティＲＭの一例を示すブロック図である。

Claims (29)

1. ＩＰネットワークを通じてマルチメディアを送信するためのインターネットＩＰ電話通信システム（４００）内のトポロジを認識したリソース・マネージャー（ＲＭ）であって、前記システムは、ゲートキーパー（Ｇｋ）を備え、前記リソース・マネージャー（ＲＭ）は、
   前記ＩＰネットワークに関するルーティング情報を収集する手段と、
   前記ＩＰネットワーク内のリソースに関するリソース情報を取得する手段と、
   前記ルーティング情報とリソース情報とを結合することによってリソース・マップを作成する手段と、
   前記リソース・マップによって、且つ前記ゲートキーパー（Ｇｋ）と相互に作用することによって前記システム（４００）内のリソース管理問題および許可制御を行う手段と、
   を備えることを特徴とするリソース・マネージャー（ＲＭ）。
2. 請求項２記載のリソース・マネージャー（ＲＭ）であって、前記ゲートキーパー（Ｇｋ）による呼設定要求からリソース情報を取得する手段を備えるリソース・マネージャー（ＲＭ）。
3. 前記請求項１から２のいずれかに記載のリソース・マネージャー（ＲＭ）において、前記ＩＰシステムはリンク−ステート・ルーティング・プロトコルを用いて経路設定され、前記リソース・マネージャー（ＲＭ）は自身のいかなるルートも通知せずにルーティングに参加して前記システム（４００）内のルーターとして作用し、前記ＩＰネットワークのルーティング情報を取得するリソース・マネージャー（ＲＭ）。
4. 前記請求項１から２のいずれかに記載のリソース・マネージャー（ＲＭ）において、前記ＩＰネットワークは、距離ベクトル・プロトコル、即ち静的ルーティング、を用いて経路設定され、前記リソース・マネージャー（ＲＭ）はトレース・ルート、および／または簡単なネットワーク管理プロトコル（ＳＮＭＰ）オート・ディスカバリのような測定法を用いて前記ＩＰネットワークのルーティング情報を取得する手段を備えるリソース・マネージャー（ＲＭ）。
5. 前記請求項１から４のいずれかに記載のリソース・マネージャー（ＲＭ）であって、前記リソース・マップを用いて、前記システム（４００）内のソース・エンドポイントと宛先エンドポイントとの間で開始された呼がどのネットワーク経路を使用するかを評価する手段を備えるリソース・マネージャー（ＲＭ）。
6. 請求項５記載のリソース・マネージャー（ＲＭ）であって、前記呼を許可するため充分なリソースがあるか否かを、その経路に沿ったリンク毎に、推定する手段を備えるリソース・マネージャー（ＲＭ）。
7. 請求項６記載のリソース・マネージャー（ＲＭ）において、前記算定値が前記ゲートキーパー（Ｇｋ）に報告されるリソース・マネージャー（ＲＭ）。
8. 前記請求項１から７のいずれかに記載のリソース・マネージャー（ＲＭ）であって、前記ＩＰ電話通信システムにおいて進行中の呼を監視し、前記システム（４００）内でいかなる変化であれ変化が発生すればその都度リンク毎のリソース使用量を算出し直すことによって、リソース・マップを更新する手段を備えるリソース・マネージャー（ＲＭ）。
9. 請求項８記載のリソース・マネージャー（ＲＭ）において、前記リソースが不十分であるために進行中の呼を実現することができないことを前記リソース・マップが示し、前記リソース・マネージャー（ＲＭ）は、どの呼を継続しどの呼を終了させるかの優先順位をつける手段を備えるリソース・マネージャー（ＲＭ）。
10. 請求項８記載のリソース・マネージャー（ＲＭ）において、前記リソースが不十分であるために進行中の呼を実現することができないことを前記リソース・マップが示し、前記リソース・マネージャー（ＲＭ）はこれをゲートキーパー（Ｇｋ）に報告する手段を備え、どの呼を継続しどの呼を終了させるかの優先順位を該ゲートキーパー（Ｇｋ）が付けることを可能とするリソース・マネージャー（ＲＭ）。
11. 前記請求項１から１０のいずれかに記載のリソース・マネージャー（ＲＭ）であって、前記システム（５００）内の２つより多いエンド−ポイントに係る複数パート会議シナリオにおいて用いられ、前記システムは更にマルチ−ポイント制御装置（ＭＣ）を備え、前記リソース・マネージャー（ＲＭ）は、前記マルチ−ポイント制御装置（ＭＣ）と相互に作用し前記リソース管理問題および許可制御を実行する手段を備えるリソース・マネージャー（ＲＭ）。
12. 請求項１１記載のリソース・マネージャー（ＲＭ）において、前記マルチ−ポイント制御装置（ＭＣ）との前記相互作用は、前記ゲートキーパー（Ｇｋ）を介して行われるリソース・マネージャー（ＲＭ）。
13. 前記請求項１１から１２のいずれかに記載のリソース・マネージャー（ＲＭ）において、リソースは使用可能であるが、呼開始時に要求されたリソースの量を満たすには不十分であり、前記リソース・マネージャー（ＲＭ）は、前記呼を条件付で拒絶する、即ち、前記呼の開始者が使用できる前記リソースを相殺することによって拒絶する手段を備えるリソース・マネージャー（ＲＭ）。
14. ゲートキーパー（Ｇｋ）、１つ以上のルーター（Ｒ）、および多数のまたは複数のエンド−ポイントを備えたインターネット・プロトコル（ＩＰ）電話通信システムであって、更に、請求項１から１３のいずれかに記載のトポロジを認識したリソース・マネージャー（ＲＭ）を備えることを特徴とするインターネット・プロトコル電話通信システム。
15. ＩＰネットワークを通じてマルチメディアを送信するよう構成されたインターネットＩＰ電話通信システム（４００）内のリソース管理問題と許可制御との実行を取り扱う方法であって、前記システム（４００）は、トポロジを認識したリソース・マネージャー（ＲＭ）を備え、前記方法はリソース・マネージャー（ＲＭ）が行う、
    前記ＩＰネットワークに関するルーティング情報を収集するステップと、
    前記ＩＰネットワーク内のリソースに関するリソース情報を取得するステップと、
    前記ルーティング情報とリソース情報とを結合することによってリソース・マップを作成するステップと、
    前記リソース・マップ、およびゲートキーパー（Ｇｋ）との相互作用によって、前記システム（４００）内のリソース管理問題と許可制御とを行うステップと、
    からなることを特徴とする方法。
16. 請求項１５記載の方法であって、更に、リソース・マネージャー（ＲＭ）が、前記ゲートキーパー（Ｇｋ）による呼設定要求からリソース情報を取得するステップを含む方法。
17. 前記請求項１５から１６のいずれかに記載の方法において、前記ＩＰネットシステムはリンク・ステート・ルーティング・プロトコルを用いて経路設定され、前記方法は、更に、前記リソース・マネージャー（ＲＭ）が自身のいずれのルートも通告せずに前記ルーティングに参加し、ルーターとして作用し前記ＩＰネットワークのルーティング情報を取得するステップを含む方法。
18. 前記請求項１５から１６のいずれかに記載の方法において、前記ＩＰネットワークは距離ベクトル・プロトコルを用いて経路設定され、前記方法は、更に、リソース・マネージャー（ＲＭ）がトレース・ルート、および／または簡単なネットワーク管理プロトコル（ＳＮＭＰ）オート・ディスカバリのような測定法を用いてＩＰネットワークのルーティング情報を取得するステップを含む方法。
19. 前記請求項１５から１８のいずれかに記載の方法において、前記リソース・マップを用いて、前記システム（４００）内のソース・エンドポイントと宛先エンドポイントとの間で開始された呼がどの経路を使用するかを評価するステップを含む方法。
20. 前記請求項１５から１９のいずれかに記載の方法であって、更に、前記呼を許可するための充分なリソースがあるか否かを前記経路に沿ったリンク毎に算定するステップを含む方法。
21. 請求項２０に記載の方法であって、更に、前記算定値を前記ゲートキーパー（Ｇｋ）に報告するステップを含む方法。
22. 前記請求項１５から２１のいずれかに記載の方法であって、更に、リソース・マネージャー（ＲＭ）が、前記ＩＰ電話通信システムにおいて進行中の呼を監視し、前記システム（４００）内で何らかの変化が発生する度にリンク毎のリソース使用量を計算し直すことによって前記リソースを更新するステップを含む方法。
23. 請求項２２に記載の方法において、前記リソースが充分ではないために進行中の呼を実現させることができないことを前記リソース・マップが示し、前記方法が、更に、前記リソース・マネージャー（ＲＭ）がどの呼を継続させ、どの呼を終了させるかの優先順位をつけるステップを含む方法。
24. 請求項２２に記載の方法において、前記リソースが充分ではないために進行中の呼を実現させることができないことを前記リソース・マップが示し、前記方法は更に、前記リソース・マネージャー（ＲＭ）が前記ゲートキーパー（Ｇｋ）にこのことを報告するステップを含み、これによって前記ゲートキーパー（Ｇｋ）は、継続させる呼、終了させる呼の優先順位をつけることが可能となる方法。
25. 前記請求項１５から２４のいずれかに記載の方法であって、前記システム（５００）内の２つよりも多いエンドポイントに係る複数パートの会議シナリオにおいて用いられ、前記システムは更に、マルチ−ポイント制御装置（ＭＣ）を備え、前記方法は更に、リソース・マネージャー（ＲＭ）が前記マルチ−ポイント制御装置（ＭＣ）と相互に作用し、前記リソース管理問題と許可制御とを行うステップを含む方法。
26. 請求項２５に記載の方法において、前記マルチ−ポイント制御装置（ＭＣ）との前記相互作用が前記ゲートキーパー（Ｇｋ）を介して行われる方法。
27. 前記請求項２５から２６のいずれかに記載の方法において、リソースは使用可能であるが呼開始時に要求されたリソースを実現するには不十分であり、前記方法は、更に、前記リソース・マネージャー（ＲＭ）が条件付で、即ち前記呼の前記開始者に対し前記使用可能なリソースを提供することによって、前記呼を拒絶するステップを含む方法。
28. ＩＰ電話通信システム（４００）内のトポロジ認識リソース・マネージャー（ＲＭ）および／またはゲートキーパー（Ｇｋ）の中の処理手段の内部メモリに直接ロード可能なコンピュータ・プログラム製品であって、請求項１５から２７のいずれかに記載のステップを行うためのソフトウエア・コード手段を備えるコンピュータ・プログラム製品。
29. コンピュータ使用可能媒体上に格納されたコンピュータ・プログラム製品であって、ＩＰ電話通信システム（４００）内のトポロジ認識リソース・マネージャー（ＲＭ）および／またはゲートキーパー（Ｇｋ）の中の処理手段に、前記請求項１５から２７にいずれかに記載のステップの実行を制御させる読み込み可能プログラムを備えるコンピュータ・プログラム製品。

Images