JP2007174708A - パケット電話システムにおける帯域幅動的利用割り当てのための方法及び装置 - Google Patents

Abstract

【課題】パケット電話システムにおける帯域幅動的利用割り当てのための方法及び装置
【解決手段】本発明においては、トラフィック量のようなネットワーク条件をモニターし、接続についての符号化スキームを動的に調整するタイミングを判断するネットワークモニタリングエージェントが開示されている。ネットワークモニタリングエージェントは、例えば、現在のネットワークトラフィック量、ネットワークエラー特性、日時あるいは曜日を元に符号化標準を選択できる。例示的実施例では、ネットワークトラフィックがより軽い場合、より低い程度の圧縮及び高い品質レベルを提供する符号化標準が選択される。ネットワークモニタリングエージェントは、各接続に関連した装置に符号化スキームにおける変化を通知する。
【選択図】図３

Description

本発明は、パケット電話システム一般、とりわけ、そのようなパケット電話システムにおける帯域幅利用を割り当てる方法及び装置に関するものである。

通信ネットワークは、ネットワークに接続された、パケット電話機、コンピュータ端末、マルチメディアワークステーション、ビデオ電話といった通信装置の中でデータ、音声、文書、映像情報といった情報の伝送に用いられている。ネットワークは典型的には、様々なリンクによって互いに、及び通信装置に接続されたノードを含んでいる。各リンクは、帯域幅あるいはリンクの能力によって特徴付けられる。通信装置からネットワークへの情報入力は、任意の形式を取り得るが、しばしば固定長のパケットあるいはセルの形式をとるように合わせられる。

パケット交換ネットワークアーキテクチャーは、例えば、イーサーネットのような一般的なローカルエリアネットワーク（ＬＡＮ）プロトコール及び非同期転送モード（ＡＴＭ）プロトコールにおいて幅広く用いられている。パケット交換ネットワークにおいては、データ伝送は、典型的には、ネットワークを通じての伝送のため、パケットと呼ばれるデータのブロックに分割される。パケットが正しい目的地へ到着するように、パケットは、ネットワーク交換機あるいは中間システムを通過しなくてはならない。典型的な場合、パケットは、ヘッダーを含んでいる。これは、ペイロード（実際のアプリケーションデータ）同様、送信元と目的地のアドレス情報を含んでいる。

図１は、従来型のマルチメディアパケット電話システム１００を示している。図１で示されたパケット電話システム１００は、私設構内交換機（ＰＢＸ）１１０のような複数の装置を接続するパケットネットワーク１０５、ワークステーション１２０、パケット電話機アダプター１２５、及びファクシミリ機１３０を含んでいる。ネットワーク環境１０５、私設構内交換機（ＰＢＸ）１１０、あるいは各装置自体は、音声情報をパケット伝送に適した形式へと変換する機構を備えている。

音声、映像、及びその他の重要なメディア形式は、基本的にはアナログ形式である。デジタルネットワークを介してアナログ情報を通すためには、送信側のノードでアナログ情報をデジタル情報へと符号化し、受信側のノードでデジタル情報からアナログ情報へと復号化することが必要である。符号器及び復号器の対は、「コーデック（ｃｏｄｅｃ）」と呼ばれている。符号化スキームに関連する基本的な変数は以下のようなものである。（１）アナログ−デジタルサンプリングの精度及び周波数（典型的な場合、音声については毎秒当たり８ビット８０００サンプル）、（２）パケット化、これはどれくらいのデータパケットが毎秒（典型的には２０，３０，４０ミリ秒）送られているのかを意味する、（３）波形符号化、複合符号化あるいは音声符号化といった符号化アルゴリズム。これらの基本的な変数は、符号器及び復号器を実施するのに必要な処理要件を決定するもので、エンドトゥエンドのメディアの可能性をもたらすものである。送信元のノードでは、コーデック（ｃｏｄｅｃ）は、データを符号化し、データ信号をパケットへと変換するのに符号化プロセスを用いている。

受信機においては、コーデック（ｃｏｄｅｃ）は、受信したパケットを復号化して、元の伝送された情報を再生する。現在では、呼設定プロセスの一部として適切なコーデック（ｃｏｄｅｃ）が選択され、その後選択されたコーデック（ｃｏｄｅｃ）が、全接続のついての両方の（単方向の）半回路に用いられる。

国際電信連合（ＩＴＵ）は、音声及びその他の情報を符号化するためのいくつもの標準を規定してきた。例えば、Ｇ．７１１標準はパルス符号化変調（ＰＣＭ）の音声サンプルを符号化し、６４キロビット毎秒でデジタルオーディオを生成する。各音声サンプルについて、コーデック（ｃｏｄｅｃ）は音声信号についての対応する振幅を保存してある。当該サンプルは、元のアナログ音声情報を再構成するのに、目的地ノードにおいてコーデック（ｃｏｄｅｃ）によって利用されることが可能である。

Ｇ．７２６、Ｇ．７２８、Ｇ．７２９の各標準といった他の符号化標準は、様々なビットレートでデータのパケットを生成する様々な符号化技術を記述している。十分な質を維持する一方で全体のネットワーク利用を最大限とするために、望みの程度の圧縮、所望のサービス品質をもった符号化／復号化の複雑さ及び可能性についてのバランスをとることで、所与の接続について特定の符号化標準が選択される。例えば、Ｇ．７１１標準は、元の情報についての本質的に損失のない複製を行う低い程度の圧縮を提供している。一方、Ｇ．７２９Ａ標準は、より多くの処理リソースを要するが、元の情報についての損失の多い複製を行うより高い程度の圧縮を行っている。

従来のパケット電話システムは満足の行く圧縮を行うため、所与のメディア形式について適切なコーデック（ｃｏｄｅｃ）を効率的に選択する一方で、従来のパケット電話システムでは、ネットワークの条件をベースとして、所与の接続について動的にコーデック（ｃｏｄｅｃ）選択を調整することはしていない。従来のパケット電話システムについての上述のような欠点から明らかなように、リアルタイムなネットワーク条件に応じて、圧縮スキームが動的に調整されることが許されるパケット電話システムについての必要性が存在している。また、パケット電話システムの帯域幅をアクティブに管理する方法及び装置についての必要性も存しているのである。

一般的に、トラフィック量のようなネットワーク条件をモニターするネットワークモニタリングエージェントが開示されており、接続についての符号化スキームをいつ動的に調整するべきかについての判断を行い、それによって、望みの質のレベルを維持しつつ、考えられる接続の全数を最大化する。一つの実施例では、ネットワークモニタリングエージェントは、現在のネットワークトラフィク量を元にして符号化標準を選択する。ネットワークトラフィックがより軽いときには、より低い程度の圧縮とより高い質のレベルを提供する符号化標準が選択される。

同様に、ネットワークトラフィックが増加するにつれ、ネットワーク利用を低減させるため、質のレベルはより低くなるが、より高い程度の圧縮を提供する符号化標準が選択される。ネットワークトラフィックに加えて、ネットワークモニタリングエージェントは、ネットワークエラー特性や日時といったものを含めたその他のファクターを元にして符号化スキームを動的に調整するように構成されうる。

本発明の別の側面によると、ネットワークモニタリングエージェントは、符号化スキームにおける変化につき、各接続に関連した装置に通知を行う。一般的には、受信されたパケットを適切に復号化することを保証するため、両方の装置が同時に符号化アルゴリズムを変えなくてはならない。一つの実施例では、（送信を）開始する装置がパケットヘッダーの領域内に、次のパケットが異なる符号化アルゴリズムで符号化されることを知らせる通知を、さらなる通知があるまで挿入するのである。

その後、受信者側装置では、受信されたパケットを適切に（圧縮を）解凍し、復号化するべく適切なコーデック（ｃｏｄｅｃ）を起動可能である。さらなるヴァリエーションでは、コーデック（ｃｏｄｅｃ）変化（あるいは現在のコーデック（ｃｏｄｅｃ））についての通知は、受信者側装置が少なくとも一つの通知を得られる可能性を最大にするため、一定の間隔でパケットヘッダー内に繰り返し含まれるか、あるいは以降のパケットで所定の回数だけ繰り返されることが可能である。

さらに本発明の別の側面によると、アプリケーションにより実行される様々なタスクにとって適切な符号化スキームについてのアプリケーション従属の選択を行う方法及び装置が提供される。各アプリケーション（あるいはコーデック（ｃｏｄｅｃ）ポリシーエージェント）は、当該アプリケーションの要件を元に各（単方向の）半回路のための符号化スキームを動的に選択する。加えて、半回路のために選択された圧縮スキームは、当該アプリケーションにより実行される所与のやりとりに関して現時点での必要に応じて、動的に調整されうる。

例えば、発呼者の半回路に対してＩＶＲにとっては第一の圧縮スキームを用いて、ＩＶＲがあらかじめ記録されたあいさつを当該発呼者に送った後に、当該ＩＶＲが会話認識を実行する場合には、ＩＶＲの半回路に対して発呼者にとっては改良された質を持った異なる圧縮スキームが選択される。その後、当該発呼者が、メッセージを残すことを選んだ場合には、より高い圧縮（音声メールに適した）を伴った異なる圧縮スキームが、ＩＶＲの半回路に対する発呼者にとって選択される。本発明のより完全な理解は、本発明のさらなる特徴と利点と同様に、以下の詳細な説明及び図面を参照することによって得られることになるであろう。

図２は、本発明にしたがったマルチメディアパケット電話システム２００を例示している。本発明は、図３と結びつけて論じられる、ネットワークモニタリングエージェント３００を提供している。このネットワークモニタリングエージェントは、トラフィック量といったネットワーク条件をモニターし、所望の品質レベルを維持しつつ、考えられる接続の全数を最大化するように接続についての圧縮のレベルを動的に調整するタイミングを判断するものである。

本発明の一つの特徴によると、ネットワークモニタリングエージェント３００は、現在のネットワークトラフィク量を元に圧縮標準を選択する。より軽いネットワークトラフィックであるときには、より低い程度の圧縮及びより高いレベルの品質を提供する圧縮標準が選択される。同様に、ネットワークトラフィックが増えるにつれて、ネットワーク利用を最大化するため、質のレベルはより低くなるが、より高い程度の圧縮を提供する圧縮標準が選択される。ネットワーク帯域利用がネットワーク容量に近付くにつれて、パケットが破棄されたり、遅延したりしうるリスクが存在する。このように、ネットワーク混雑が増えるにつれ、より高い程度の圧縮を提供する圧縮アルゴリズムが用いられるとすれば、同じ数の接続についてより狭い帯域しか利用されないことになる。

本発明のさらなるヴァリエーションにおいては、ネットワークモニタリングエージェント３００は、他のファクターにも同様に応答して圧縮スキームを動的に調整し得る。一つのヴァリエーションでは、ネットワークモニタリングエージェント３００は、現在生じているネットワーク損失やエラーの形式により寛容なコーデック（ｃｏｄｅｃ）を選択しうる。例えば、他のコーデック（ｃｏｄｅｃ）は、バーストエラーに対してより寛容である一方で、あるコーデック（ｃｏｄｅｃ）は、破棄されるｎ番目のすべてのパケットを許容しうる。

さらに別のヴァリエーションでは、繁忙する時間帯に圧縮されたコーデック（ｃｏｄｅｃ）へとスウイッチするように、日時を元にして新たなコーデック（ｃｏｄｅｃ）が選択されうる。例えば、ネットワーク遅延が増加すると、ネットワークモニタリングエージェント３００は、より低い遅延を伴った新たなコーデック（ｃｏｄｅｃ）を選択しうる。

上に示したように、図２は、本発明にしたがってマルチメディアパケット電話システム２００を例示している。図２に示されたパケット電話システム２００は、私設構内交換機（ＰＢＸ）２１０のような複数の装置を接続しているパケットネットワーク２０５、ワークステーション２２０、パケット電話アダプター２２５及びファックス機２３０を含んでいる。パケットネットワーク２０５及び、装置２１０，２２０，２２５，２３０といった、それに接続された装置は、本発明の特徴及び機能を導入するように修正されるべく、図１と結びつけて示され、記述された従来のパケット電話システム１００と同様の手法で実施され得る。

図３は、例示的なネットワークモニタリングエージェント３００のアーキテクチャーを示しているブロック線図である。ネットワークモニタリングエージェント３００は、例えば、本発明の特徴及び機能を実現するように修正されるべく、ワークステーションあるいはサーバーとして実施されうる。ネットワークモニタリングエージェント３００は、プロセッサー３１０及びデータ保存装置３２０のような関連メモリを含んでいる。プロセッサー３１０は、単一のプロセッサーとして、あるいは並列に動作する複数のプロセッサーとして実施されうる。データ保存装置３２０あるいは読み出し専用メモリ（ＲＯＭ）は、命令を保存するように動作可能であり、プロセッサー３１０は、当該命令を取り出し、解釈し、実行するように動作可能である。

図３で示されているように、データ保存装置３２０は、図５で示された、接続データベース５００を含んでいる。これは、パケット電話システム１００における各接続についての情報を維持しているものである。加えて、データ保存装置３２０は、図６で示された、動的圧縮調整プロセス６００を含んでいる。これは、ネットワークトラフィックをモニターし、いつ接続についての圧縮レベルを動的に調整すべきなのかを判断するものである。

通信ポート３３０は、ネットワークモニタリングエージェント３００をパケット電話システム１００へと接続し、それによってネットワークモニタリングエージェント３００を各接続ノードあるいは当事者へとリンクさせる。

ネットワークモニタリングエージェント３００は、ネットワークトラフィックをモニターし、いつ接続についての圧縮レベルを動的に調整すべきなのかを判断する。圧縮アルゴリズムが動的に調整されている場合には、ネットワークモニタリングエージェント３００は、装置２１０、２２０、２２５といったような接続された装置へとメッセージを送ることができる。また、これらの装置は、示されたコーデック（ｃｏｄｅｃ）を実装することで対応していなくてはならない。

ネットワークモニタリングエージェント３００から、圧縮アルゴリズムにおける変化についての通知を受信している装置２１０、２２０、２２５はイニシエーターと呼称される。以下で論じられるように、イニシエーターは、できれば、受信者と呼称される、接続のもう一方に、以降のすべてのパケットは新たな圧縮アルゴリズムで符号化されるであろうという内容の通知を行うことが望ましいといえる。

本発明のさらなる特徴によると、ネットワークモニタリングエージェント３００は、各接続に関連した装置に、圧縮スキームにおける変化を知らせる。一つの実施例では、（送信を）開始する装置がパケットヘッダーの領域内に、次のパケットが異なる符号化アルゴリズムで符号化されることを受信者に知らせる通知を、さらなる通知があるまで挿入するのである。その後、受信者側装置では、受信されたパケットを適切に（圧縮を）解凍し、復号化するべく適切なコーデック（ｃｏｄｅｃ）を起動可能である。

さらなるヴァリエーションでは、コーデック（ｃｏｄｅｃ）変化（あるいは現在のコーデック（ｃｏｄｅｃ））についての通知は、受信者側装置が少なくとも一つの通知を得られる可能性を最大にするため、一定の間隔でパケットヘッダー内に繰り返し含まれるか、あるいは以降のパケットで所定の回数だけ繰り返されることが可能である。このように、通知を含んでいるパケットが仮に失われても、受信者側装置は回復できるのである。パケットヘッダー内におけるインバンドシグナリングのこのような形式が、メディアストリームにおいては何らの中断ももたらさないという点は留意する事項である。

加えて、受信者側ノードは、所定数のパケットのパケットヘッダー内において、（送信を）開始するノードへの通知を送信することが可能である。パケット電話システムは一般的にパケットの順序を保証するものではないので、一旦、変化の通知を伴ったパケットのペイロードがデータストリームへ処理されてしまうと、変化の通知を伴っているパケットよりも前の配列番号をもっている任意のパケットは、受信者側装置により無視されることになる。

イニシエーターは、選択的には、変化の通知を伴うヘッダーと同じヘッダー内に、メディアをイニシエーターへ送り戻す際には交換されたコーデック（ｃｏｄｅｃ）を用いることを受信者側装置に要求するリクエストを含ませうる。このようにして、両方の半回路は同じ圧縮アルゴリズムで圧縮されるだろう。そこで、受信者側は、拡張されたヘッダー内に確認及びコーデック（ｃｏｄｅｃ）変化の通知の両方を伴っているパケットにおいて、交換されたコーデック（ｃｏｄｅｃ）にあるメディアを送信することで応答する。また、そのような情報は、所定数の連続するパケットにおいても繰り返されうる。

本発明の動的コーデック（ｃｏｄｅｃ）アーキテクチャーは、すべての接続を２つの半回路としてモデル化している。すなわち、一つは、発呼者から被呼者へという半回路、もう一つは、被呼者から発呼者へという半回路である。動的なコーデック（ｃｏｄｅｃ）スキームを信頼性のあるものとするために、本発明では、両方の半回路が（異なる圧縮及び品質レベルをもった）異なるコーデック（ｃｏｄｅｃ）を用いて、その結果、非同期的に構成されることができるようにしてある。

本発明にしたがって圧縮アルゴリズムを動的に調整する、代表的な動的圧縮装置４００が図４に示されている。一般に、動的圧縮装置４００は、圧縮の程度を変えられる複数の圧縮アルゴリズムを含んでいる。例示的な実施例では、動的圧縮装置４００は、低、中、高という圧縮の程度を提供する、３つの別個の圧縮アルゴリズムを備えている。

図４は、例示的な動的圧縮アルゴリズム４００のアーキテクチャーを示しているブロック線図である。図４に示されているように、動的圧縮装置４００は、プロセッサー４１０及びデータ保存装置４２０のような関連するメモリを含んでいる。プロセッサー４１０は、単一のプロセッサーとして、あるいは並立して動作する複数のプロセッサーとして実施されうる。データ保存装置４２０あるいは読みこみ専用メモリ（ＲＯＭ）は、命令を保存するように動作可能であり、プロセッサー４１０は、当該命令を取り出し、解釈し、実行するように動作可能である。

図４に示されているように、データ保存装置４２０は、Ｇ．７２２標準のような低レベル圧縮コーデック（ｃｏｄｅｃ）４５０、Ｇ．７１１標準のような中レベル圧縮コーデック（ｃｏｄｅｃ）４６０、Ｇ．７２９Ａのような高レベル圧縮圧縮コーデック（ｃｏｄｅｃ）４７０を含んでいる。加えて、データ保存装置４２０は、図７と結びつけて以下で論じられる動的圧縮調整プロセス７００を含んでいる。一般に、動的圧縮調整プロセス７００は、新たな圧縮スキームについての通知をネットワークモニタリングエージェント３００から受け取って、適切縮コーデック（ｃｏｄｅｃ）４５０、４６０、４７０を起動する。

このようにして、ネットワーク利用が低い際には、ネットワークモニタリングエージェント３００は、動的圧縮装置４００が低レベル圧縮コーデック（ｃｏｄｅｃ）４５０を用いて、考えられうるもっとも高品質の音声を提供する。ネットワーク利用及びトラフィクが増えていくにつれて、ネットワークモニタリングエージェント３００はネットワークトラフィックが所定の構成可能なしきい値以上に増加したことを検出する。

その後、ネットワークモニタリングエージェント３００は、動的圧縮装置４００に中レベルあるいは高レベル圧縮圧縮コーデック（ｃｏｄｅｃ）４６０、４７０をすべての新たな呼にとって適切なものであるとして用いるように命令する。ネットワークモニタリングエージェント３００は、新たな接続リクエストと同様に進行中の呼の圧縮を動的に調整する。ネットワークモニタリングエージェント３００は、ネットワークトラフィックのモニタリングを続け、ネットワークトラフィックが再度所定の構成可能なしきい値を下回ると、すべてのノードが高レベル品質のコーデック（ｃｏｄｅｃ）（より低いレベルの圧縮を伴った）を用いるように命令する。

通信ポート４３０は、動的圧縮装置４００をパケット電話環境１００へと接続し、それによって動的圧縮装置４００を各接続されたノードあるいは当事者へとリンクさせる。

図５は、パケット電話環境１００における各接続についての情報を保存している例示的な接続データベース５００を示している。接続データベース５００は、記録５０５−５２０といった複数の記録を維持しており、それぞれは異なる接続と関連している。領域５３０に挙げられた各接続識別子について、接続データベース５００は、領域５５０、５６０それぞれにおける接続に関連したノードについての識別子と同様に、領域５４０における接続と関連した現在の圧縮スキームを含んでいる。

一つの実施例では、接続データベース５００は、拡張領域（示されていない）における両ノードによりサポートされている様々な共通の圧縮スキームを示している。選択的な実施例では、ネットワークモニタリングエージェント３００は、新たな圧縮スキームの選択の一部として、自らの容量についてノードに問い合わせを行う。

ネットワークモニタリングエージェント３００は、ある呼における少なくとも一つ（あるいはそれ以上）の終端についてのコントロールを有している。ネットワークモニタリングエージェント３００が、コーデック（ｃｏｄｅｃ）変化を開始する際には、そのコントロール下にあるノードが、異なる特定のコーデック（ｃｏｄｅｃ）をもったメディアを送り始めるように命令する。

一つの実施例では、ネットワークモニタリングエージェント３００は、入力されるメディアデータを処理するため、どのコーデック（ｃｏｄｅｃ）に交換されるべきかを受信者側の終端（目的地ノード）に命令しない。ネットワーク遅延を変化させることは対応するパケットに適切なコーデック（ｃｏｄｅｃ）を適用する際に問題を生じさせるということは認められてきた。むしろ、そのような同期化は、上で論じたインバンドシグナリングによってよりよく実現されるのである。

ネットワークモニタリングエージェント３００は、どれが、送信端と受信端の両方が利用できる共通のコーデック（ｃｏｄｅｃ）であるかどうかを判断する必要がある。両終端が、ネットワークモニタリングエージェント３００のコントロール下にある場合には、ネットワークモニタリングエージェント３００は、終端データベース（図５）に記録された各終端によってどのコーデック（ｃｏｄｅｃ）がサポートされるべきであるのかについての情報を有している。それ以外の場合には、ネットワークモニタリングエージェント３００は、新たなコーデック（ｃｏｄｅｃ）についての交渉を行うため、自ら及び類似のシステムと別の外部のネットワークモニタリングエージェントが協調する必要がある。

ネットワークモニタリングエージェント３００が離れた終端の装置をコントロールしていないで、かつ離れた終端についてコーデック（ｃｏｄｅｃ）を交換する事を望んでいる場合には、ネットワークモニタリングエージェント３００は、当該離れた終端装置がコーデック（ｃｏｄｅｃ）を変える事を勧めるようにインバンドシグナリングを利用しうる。

プロセス
これまで示したように、ネットワークモニタリングエージェント３００は、図６で示された動的圧縮調整プロセス６００を実装している。これは、ネットワーク条件をモニターして、接続についての圧縮レベルを動的に調整するタイミングを判断し、圧縮スキームへの変化について関連する装置に通知するものである。例示的な実施例では、モニターされたネットワーク条件は、ネットワークトラフィックの量となっている。動的圧縮調整プロセス６００は、当該圧縮スキームを調整するために連続的にあるいは周期的に実行されうる。

図６に例示的に示されているように、ネットワークモニタリングエージェント３００は、ネットワークトラフィック量を明らかにするためにステップ６１０、６３０、６６０の間で複数の試験を実行する。それによって適切な圧縮スキームを選択するのである。換言すれば、例示的な実施例においては、動的圧縮調整プロセス６００は、現時点でのネットワークトラフィックがそれぞれ相対的に低いものであるか、中程度であるのか、高いものであるのか、判断するのである。例えば、動的圧縮調整プロセス６００は、ネットワークトラフィックを明らかにするためにステップ６１０、６３０、６６０の間で実行される各試験について、上限及び下限を利用しうる。

ステップ６１０においてネットワークトラフィックが「低い」と判断されるとしたら、低い程度の圧縮とそれに対応して高い品質レベルを提供する圧縮標準が選択されるであろう。そこで、プログラム制御は、圧縮スキームの選択のためステップ６７０へと進む。しかしながら、ステップ６１０において、ネットワークトラフィックが「低くない」と判断される場合には、プログラム制御はステップ６３０へと進む。

ステップ６３０においてネットワークトラフィックが「中程度である」と判断されるとしたら、適切な中程度の圧縮標準が同様に選択される。そこで、プログラム制御はステップ６７０へと進む。しかしながら、ステップ６３０において、ネットワークトラフィックが「中程度でない」と判断される場合には、プログラム制御はステップ６６０へと進む。

ステップ６６０においてネットワークトラフィックが「高い」と判断されるとしたら、適切な圧縮標準が同様に選択される。すなわち、品質レベルは低いが高い圧縮程度を提供するものである。そこで、プログラム制御はステップ６７０へと進む。しかしながら、ステップ６６０において、ネットワークトラフィックが「高くない」と判断される場合には、エラーが発生し、エラー操作がステップ６６５において実施される。

ステップ６７０においては、現在の圧縮スキームにおける変化が生じたか否かを判断する試験が実行される。ステップ６７０において、現在の圧縮スキームにおける変化が生じたと判断される場合には、動的圧縮調整プロセス６００は、ステップ６８０において、（１）各接続に対する両方の当事者によってサポートされ、かつ（２）現在の圧縮における変化を生じさせた条件にとって適切である、圧縮スキームを選択する。

その後、動的圧縮調整プロセス６００は、ステップ６９０において、新たな圧縮スキームについて、各接続に関連した装置に通知する。そこで、プログラム制御は、連続した処理のためステップ６１０へと戻る。

本発明のさらなるヴァリエーションにおいては、動的圧縮調整プロセス６００が、上で述べたようにネットワークエラー特性や日時に対応して、動的に圧縮スキームを調整するというものがある。

前に示したように、各動的圧縮装置４００は、図７で示された、動的圧縮調整プロセス７００を実装するものである。これは、ネットワークモニタリングエージェント３００からの新たな圧縮スキームに関する通知についてパケットヘッダーをモニターし、その後適切なコーデック（ｃｏｄｅｃ）を起動するものである。図７に示されているように、動的圧縮調整プロセス７００は、ステップ７１０において、新たな圧縮スキームについての通知をモニターする。ここで、各装置は、別の装置からのパケットヘッダーにおいて新たな圧縮スキームについての通知を受け取るのと同様に、ネットワークモニタリングエージェント３００によって新たな圧縮スキームについて直接に通知を受けうるということにも留意されたい。

ステップ７２０において、装置が新たな圧縮スキームについての通知を受け取ったか否かについて判断する試験が実行される。ステップ７２０において、装置が新たな圧縮ステップについての通知を受け取ったと判断される場合には、ステップ７３０において、動的圧縮調整プロセス７００は以降のパケットを処理するため適切なコーデック（ｃｏｄｅｃ）４５０、４６０、４７０を起動する。しかしながら、ステップ７２０において、装置が新たな圧縮スキームについての通知を受け取っていない場合には、プログラム制御はステップ７１０へと戻り、上で述べた手法で続けられる。プログラム制御はステップ７４０において終了する。

アプリケーションに依存した圧縮スキーム選択
異なる圧縮及び符号化スキームは、あるアプリケーションにとってよりよく適合し得る。ある符号器で符号化された情報を復号化し、それを異なる符号器で再符号化する（「トランスコーディング」と呼ばれるプロセス）ことは可能であるが、これはリソース集約的であり、音声品質を低減させ、接続において不安定さを増やすことになる。このような欠点が存在することから、トランスコーディングは、可能な限り避けられるものである。

例えば、ある音声メールへのアプリケーションでは、Ｇ．７２９Ａフォーマットのような、圧縮されたフォーマットでの音声を保存している。そこで、システム２００のどこかでトランスコーディングが行われることを要求するよりも、ネットワークモニタリングエージェント３００が、音声メールセグメントへの発呼者にとって適切なコーデック（ｃｏｄｅｃ）をもって既に符号化がなされている音声メールサーバーへ音声を送信するため、発呼者のコーデック（ｃｏｄｅｃ）を交換することが望ましい。

加えて、双方向音声応答（ＩＶＲ）ユニットは、圧縮されたコーデック（ｃｏｄｅｃ）を伴った音声プロンプトを保存しており、再生においてやはりトランスコーディングを避けることが望まれる。選択的には、音声認識要素（あるいはテレビ会議ブリッジ）では、音声は１６ビットＰＣＭのような超高品質線形コーデック（ｃｏｄｅｃ）で提供される事が望ましいといえよう。

例えば、ＩＶＲのアプリケーションについて、ネットワークモニタリングエージェント３００（あるいはアプリケーションそのもの）は、双方向音声応答ユニット（ＩＶＲ）のセグメントへの発呼者のコーデック（ｃｏｄｅｃ）をＧ．７１１符号化スキームに設定する。最初は、先進インテリジェントエージェントが、あらかじめ記録されたあいさつを発呼者へ送らなくてはならない。これはＧ．７２９Ａ圧縮スキームで符号化されている。

そこで、当該インテリジェントエージェントは、ＩＶＲから発呼者への半回路セグメントにとってのコーデック（ｃｏｄｅｃ）が、Ｇ．７２９Ａコーデック（ｃｏｄｅｃ）を用いるようにしなくてはならない。これは、あらかじめ記録されたプロンプトをトランスコーディングしなくてはならなくなることを避けるためである。当該プロンプトが送られた後には、発呼者からＩＶＲへの当該半回路セグメントはＰＣＭ１６を用いるようにしなくてはならない。これは、会話認識エンジンの性能を改善するためである。

もし発呼者がメッセージを残すことを求めた場合には、インテリジェントエージェントは、音声メールに本来用いられている、Ｇ．７２９Ａのようなコーデック（ｃｏｄｅｃ）を、エージェントの半回路セグメントへの発呼者が用いることを勧めつつ、当該発呼者との間で交渉を行うことが可能である。メッセージが記録された後には、エージェントは、会話認識を再びサポートするべく、エージェントの半回路への発呼者をＰＣＭ１６へと戻すよう交換できる。

このように、本発明のさらなる特徴によれば、各アプリケーション（あるいはネットワークモニタリングエージェント３００）は、アプリケーションの要件を元にして、動的に各（単方向の）半回路についての圧縮スキームを選択する。加えて、半回路について選択された圧縮スキームは、アプリケーションにより実行される所与のやりとりについての現状での必要に応じて動的に調整されうる。

例えば、上で論じたＩＶＲのアプリケーションについては、ＩＶＲは、発呼者の半回路へのＩＶＲの第一の圧縮スキームを用いて、発呼者へのあらかじめ記録されたあいさつを送信し、その後にＩＶＲが会話認識を実行する際に、ＩＶＲの半回路への発呼者の、改良された品質を有する異なる圧縮スキームが選択される。その後、発呼者がメッセージを残すことを選んだ場合には、ＩＶＲの半回路への発呼者の、より高い圧縮（音声メールに適した）を伴った異なる圧縮スキームが選択される。

加えて、複数の信号処理アプリケーションは、接続に関連した条件を元に様々な符号化スキームを実施しうる。例えば、接続に関連した量や会話設定についてのユーザーによる修正に応じて、アプリケーションは新たな符号化スキームを選択しうるのである。

ここで示され及び記述された実施例やヴァリエーションは、本発明の原理を単に例示するものに過ぎず、本発明の技術思想や保護の範囲から逸脱することなく、様々な修正が当業者によって実施されうる。

例えば、コーデック（ｃｏｄｅｃ）そのものを変えるよりもむしろ、ネットワークモニタリングエージェント３００は、現在選択されているコーデック（ｃｏｄｅｃ）の特定のパラメータを調整しうる。パケット化は、動的なコーデック（ｃｏｄｅｃ）交渉の範囲でカバーされるため、ネットワークモニタリングエージェント３００は、パケット化時間やサイレンスサプレッションポリシーについても同様に変えられうることにも留意されたい。

加えて、動的圧縮装置４００に利用される特定の圧縮スキームを通知するよりもむしろ、ネットワークモニタリングエージェント３００は、単に現在のネットワーク条件について動的圧縮装置４００に通知するに過ぎない場合もありうる。このネットワーク条件とは、適切な共通の圧縮スキームを選択するため、接続への当事者となっている動的圧縮装置４００によって用いられるものである。

［発明の効果］
本発明により、トラフィック量のようなネットワーク条件をモニターし、接続についての符号化スキームを動的に調整するタイミングを判断するネットワークモニタリングエージェントが開示されている。これにより、リアルタイムなネットワーク条件に応じて、圧縮スキームが動的に調整されることが許されるパケット電話システムを実現することが可能となった。また、これに伴って、パケット電話システムの帯域幅をアクティブに管理する方法及び装置についても提供されている。

図１は、従来型のマルチメディアパケット電話システムを示している。 図２は、本発明にしたがったマルチメディアパケット電話システム２００を示している。 図３は、本発明にしたがった、図２のネットワークモニタリングエージェントを例示しているブロック線図である。 図４は、図２の私設構内交換機（ＰＢＸ）に接続された電話ユニットのような、本発明にしたがった、代表的な動的圧縮装置を例示しているブロック線図である。 図５は、図３の接続データベースからのサンプル表を示している。 図６は、図３のネットワークモニタリングエージェントによって実施された例示的な動的圧縮調整プロセスを記述している流れ図である。 図７は、図４の動的圧縮装置によって実施された例示的な動的圧縮調整プロセスを記述している流れ図である。

符号の説明

１００ パケット電話システム
１０５ パケットネットワーク
１１０ 私設構内交換機（ＰＢＸ）
１２０ ワークステーション
１２５ パケット電話機アダプター
１３０ ファクシミリ機
２００ マルチメディアパケット電話システム
２０５ パケットネットワーク
２１０ 私設構内交換機（ＰＢＸ）
２２０ ワークステーション
２２５ パケット電話アダプター
２３０ ファックス機
３００ ネットワークモニタリングエージェント
３１０ プロセッサー
３２０ データ保存装置
３３０ 通信ポート
４００ 動的圧縮装置
４１０ プロセッサー
４２０ データ保存装置
４３０ 通信ポート
４５０ 低レベル圧縮コーデック（ｃｏｄｅｃ）
４６０ 中レベル圧縮コーデック（ｃｏｄｅｃ）
４７０ 高レベル圧縮コーデック（ｃｏｄｅｃ）
５００ 接続データベース
５０５ 記録
５１０ 記録
５１５ 記録
５２０ 記録
５３０ 接続識別子
５４０ 現在の圧縮スキーム
５５０ 終端データベース
５５５ ノード１
５６０ ノード２
６００ 動的圧縮調整プロセス
６１０ 現在のネットワークトラフィック量は相対的に低いか？
現在のネットワークトラフィック量は相対的に中程度か？
現在のネットワークトラフィック量は相対的に高いか？
６６５ エラー操作
６７０ 現在の圧縮スキームに変化が生じたか？
６８０ 各接続に対する両当事者によりサポートされ、圧縮スキームの変化を生じさせる条件に適合している圧縮スキームを選択する。
６９０ 各接続に関連した装置に新たな圧縮スキームを通知する。
６９５ 終了
７００ 動的圧縮調整プロセス
７１０ 新たな圧縮スキームについての通知についてのデータストリームをモニターする。
７２０ 装置は新たな圧縮スキームについての通知を受け取っているか？
７３０ 適切なコーデック４５０、４６０、４７０を起動する。

Claims (41)

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. ネットワークトラフィックがより軽い際には、より圧縮の程度の低い符号化標準が選択されることを特徴とする請求項２８のシステム。
30. ネットワークトラフィックが増加するにつれてより圧縮の程度の高い符号化標準が選択されることを特徴とする請求項２８のシステム。
31. 所定のネットワークエラー特性が検出される場合に、前記表示が受信されることを特徴とする請求項２７のシステム。
32. 前記表示が所定の時間間隔の間、受信されることを特徴とする請求項２７のシステム。
33. 前記接続に関連した各半回路について符号化スキームが独立に選択されることを特徴とする請求項２７のシステム。
34. 以降のパケットが異なる特定の符号化アルゴリズムをもって符号化されることを示す通知について、前記モニターするステップがパケットヘッダーを評価することを特徴とする請求項２７のシステム。
35. 発呼者側とネットワークにおけるアプリケーション間での接続を符号化する方法で、
    前記接続を設定するステップ、ここで、前記接続とは前記発呼者および前記アプリケーションの間の複数の呼セグメントを有しており、前記各呼セグメントは異なる符号化要件を有しており、
    前記対応する符号化要件を元に前記各呼セグメントのための符号化スキームを選択するステップとを、有することを特徴とする方法。
36. 発呼者側とネットワークにおけるアプリケーション間での接続を符号化する方法で、
    前記呼セグメントのために選択された符号化スキームを、前記アプリケーションによって実行される所与のやりとりに関する現状での必要性に応じて経時的に調整するステップを、さらに有することを特徴とする請求項３５の方法。
37. 前記アプリケーションとは、音声メールアプリケーションであり、前記選択された符号化スキームとは、圧縮された形式でメッセージを記録するように選ばれるものであることを特徴とする請求項３５の方法。
38. 前記アプリケーションとは、双方向音声応答（ＩＶＲ）アプリケーションであり、前記選択された符号化スキームは、ＩＶＲが会話認識を実行している際に、ＩＶＲの半回路への発呼者側にとって改良された品質を提供するものであることを特徴とする請求項３５の方法。
39. 前記アプリケーションとは、双方向音声応答（ＩＶＲ）アプリケーションであり、前記選択された符号化スキームは、ＩＶＲがメッセージを記録している際に、ＩＶＲの半回路への発呼者側にとってより高い圧縮を提供するものであることを特徴とする請求項３５の方法。
40. 前記アプリケーションとは、信号処理アプリケーションであり、新たな符号化スキームは、前記接続の量に対する調整のため選択されることを特徴とする請求項３５の方法。
41. 前記アプリケーションとは、信号処理アプリケーションであり、新たな符号化スキームは、前記接続の速さに対する調整のため選択されることを特徴とする請求項３５の方法。

Images