(57)【特許請求の範囲】
【請求項１】
通信ネットワークのチャンネルを介して第１ノードから第２ノードへデータを送信する方法であって、
前記第１ノードにおいてデータを受信するステップと、
前記データの第１部分を第１ビットレートでエンコードして、第１エンコードデータストリームを生成するステップと、
前記チャンネルの容量に関する兆候をモニタリングするステップと、
前記チャンネルを介してパディングされたデータストリームを前記第２ノードへ送信するステップであって、前記チャンネルの前記容量に関する兆候に従って、前記第１エンコードデータストリームのデータ・パケット内にパディング・ビットを挿入することにより、パディング・ビットを前記第１エンコードデータストリームに追加し、前記パディングされたデータストリームを生成し、ただし、パディングされたデータ・パケットのペイロードが奇数バイトを有し、前記奇数バイトは、前記第２ノードがパディングされたデータ・パケットのペイロードのバイト数をモニタリングすることにより前記データがパディングされているかどうかを判断できるようにするためのものである、ステップと、
前記パディングされたデータストリームの送信が前記チャンネルの前記容量を超過するかどうかを判断するステップと、
前記パディングされたデータストリームの送信が前記チャンネルの前記容量を超過しないと判断した場合に、前記パディングされたデータストリームのビットレートが前記第１ビットレートよりも高いビットレートに実質的に等しいかどうかを判断するステップであって、前記チャンネルの前記容量を超過しないとする判断に応じて、前記パディングされたデータストリームの前記ビットレートが前記高いビットレートと実質同一になるまで前記第１エンコードデータストリームに追加するパディング・ビットの数を徐々に増大させることで前記パディング・ビットを前記第１エンコードデータストリームに追加することにより、前記送信されるパディングされたデータストリームの送信されるビットレートを徐々に増大させ、前記送信されるパディングされたデータストリームのビットレートを前記高いビットレートに徐々に近づける、ステップと、
前記パディングされたデータストリームのビットレートが前記高いビットレートと実質同一であると判断した場合に、前記データの第２部分を、前記高いビットレートでエンコードして第２エンコードデータストリームを生成するステップと、
前記チャンネルを介して前記第２エンコードデータストリームを前記第２ノードへ送信するステップと、を有する方法。
【請求項２】
前記パディングされたデータストリームの送信が前記チャンネルの前記容量を超過すると判断した場合、前記データの前記第２部分を、前記第１ビットレートでエンコードする、請求項１に記載の方法。
【請求項３】
前記チャンネルの前記容量に関する兆候をモニタリングするステップは、前記チャンネルの前記容量を超過しているかをモニタリングするステップを含む、請求項１または２に記載の方法。
【請求項４】
前記チャンネルの前記容量に関する兆候をモニタリングするステップは、ターゲット・ビットレートを決定するステップを含む、請求項１ないし３のいずれか１つに記載の方法。
【請求項５】
前記パディング・ビットの数は、前記ターゲット・ビットレートに応じた量ずつ、徐々に増大させる、請求項４に記載の方法。
【請求項６】
パディング・ビットを前記第１エンコードデータストリームに追加するステップは、前記第１エンコードデータストリームにパディング・ブロックを追加するステップを含み、
各パディング・ブロックは、複数のパディング・ビットを含む、請求項１ないし５のいずれか１つに記載の方法。
【請求項７】
前記パディング・ビットは、順方向誤り訂正データを含む、請求項１ないし６のいずれか１つに記載の方法。
【請求項８】
前記データの前記第１部分を前記第１ビットレートでエンコードするステップは、前記データの前記第１部分を、固定低ビットレートエンコード方式、または、適応型ビットレートエンコード方式の低レートモード、のいずれかを用いてエンコードするステップを含む、請求項１ないし７のいずれか１つに記載の方法。
【請求項９】
前記データの前記第２部分を前記高いビットレートでエンコードするステップは、前記データの前記第２部分を、固定高ビットレートエンコード方式、または、適応型ビットレートエンコード方式の高レートモード、のいずれかを用いてエンコードするステップを含む、請求項１ないし８のいずれか１つに記載の方法。
【請求項１０】
請求項１のステップにより送信されたデータ・パケットがパディングを含んでいるかどうかを、前記第２ノードにおいて、判断する方法であって、
前記第２ノードにおいて前記データ・パケットを受信するステップと、
前記データ・パケットの前記ペイロードに含まれるバイト数を求めるステップと、
前記データ・パケットの前記ペイロードに含まれるバイト数が奇数である場合に、前記データ・パケットがパディング・ビットを含んでいると判断するステップと、を有する方法。
【請求項１１】
前記第１エンコードデータストリームのデータ・パケットに追加されたパディング・ビットの数が、ＲＴＰ（リアルタイム・トランスポート・プロトコル）標準に基づいて、示される、請求項１ないし１０のいずれか１つに記載の方法。
【請求項１２】
通信ネットワークのチャンネルを介してノードへデータを送信する送信器であって、
送信すべきデータを受信するように構成される入力モジュールと、
第１ビットレートまたは第２ビットレートで、前記受信したデータをエンコードし、エンコードデータストリームを生成するように構成されるエンコードモジュールであって、前記第２ビットレートが前記第１ビットレートよりも高ビットレートである、エンコードモジュールと、
前記チャンネルを介して前記ノードへ前記エンコードデータストリームを送信するように構成される出力モジュールと、
前記チャンネルの容量に関する兆候をモニタリングするように構成される帯域幅管理モジュールと、
前記第１ビットレートでエンコードする際に、前記チャンネルの前記容量に関する前記兆候に応じて、前記エンコードデータストリームのデータ・パケット内にパディング・ビットを挿入することにより、前記エンコードデータストリームにパディング・ビットを追加し、パディングされたデータストリームを生成し、ただし、パディングされたデータ・パケットのペイロードが奇数バイトを有し、前記奇数バイトは、前記ノードがパディングされたデータ・パケットのペイロードのバイト数をモニタリングすることにより前記データがパディングされているかどうかを判断できるようにするためのものであるように構成されるパディングモジュールと、を有し、
前記帯域幅管理モジュールは、前記パディングされたデータストリームの送信が前記チャンネルの前記容量を超過しているか判断し、前記パディングされたデータストリームの送信が前記チャンネルの前記容量を超過しないと判断した場合には、前記パディングモジュールを制御して前記パディングされたデータストリームのビットレートが前記第２ビットレートと実質同一であるかどうかを判断させ、前記パディングされたデータストリームのビットレートが前記第２ビットレートと実質同一であると判断した場合、前記エンコードモジュールを制御して前記受信したデータを前記第２ビットレートでエンコードさせるように構成され、
前記パディングモジュールは、前記チャンネルの前記容量を超過しないとする判断に応じて、前記パディングされたデータストリームの前記ビットレートが前記第２ビットレートと実質同一になるまで第１エンコードデータストリームに追加するパディング・ビットの数を徐々に増大させることで前記パディング・ビットを前記第１エンコードデータストリームに追加することにより、前記送信されるパディングされたデータストリームの送信されるビットレートを徐々に増大させ、前記送信されるパディングされたデータストリームのビットレートを前記第２ビットレートに徐々に近づけるように構成される、送信器。
【請求項１３】
プロセッサによって実行されることによって、請求項１ないし１１のいずれか１つに記載のステップを実行するコードを有する、コンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信システムに関する。より具体的には、本発明は、通信システムにおけるデータのエンコード、送信、および、受信の方法および装置に関する。
【背景技術】
【０００２】
通信システムは、通信ネットワークを備える。通信ネットワークにより２つの通信端末は相互にリンクすることができる。これにより、当該端末は、電話またはその他の通信イベントにおいて、お互いにデータを送信可能となる。ここでのデータには、発話（スピーチ、speech）、文字（テキスト、text）、画像（イメージ、image）、映像（ビデオ、video）が含まれる。
【０００３】
現代の通信ステムは、デジタル信号伝送に基づく。デジタルデータの伝送に適した通信システムの１つに、インターネット（the Internet）がある。インターネットおよびその他のパケット交換方式ネットワークで音声信号の伝送に使用されるプロトコルは、一般に、ボイス・オーバー・インターネット・プロトコル（ＶｏＩＰ）と称される。
【０００４】
会話（speech）のようなデータは、端末の、マイクロフォンのようなアナログ入力デバイスに入力される。マイクロフォンから出力されるアナログ信号は、端末においてアナログ・デジタル変換器によってデジタル信号へ変換される。それから、デジタル信号はエンコードされて、通信ネットワークを介して他の端末へ送信するためのデータ・パケットに収納される。
【０００５】
データ・パケットは、通信ネットワークを介して伝送される。各データ・パケットは、ヘッダ部（header portion）とペイロード部（payload portion）を有する。データ・パケットのヘッダ部は、データ・パケットを送信し処理するための情報を備えている。この情報は、パケットをユニークに識別するための、識別番号（identification number）およびソースアドレス（source address）や、タイム・スタンプ、ならびに、宛先アドレス（destination address）を含んでよい。データ・パケットのペイロード部は、符号化入力信号を含む。例えば、入力信号がオーディオ信号であれば、データ・パケットのペイロード部は、符号化オーディオ・フレームを含んでよく、ここでの各フレームがアナログ信号の一部分を表している。
【０００６】
インターネットのようなパケット交換ネットワークを経て送信されたデータ・パケットは、ネットワークのリソースを共有する。データ・パケットは、ネットワーク内の異なる経路を通って同じ宛先へ送信可能である。それ故、データ・パケットは、回線交換ネットワークの場合のような専用の「チャンネル」を介して送信されることはない。しかしながら、当業者であれば容易に理解するように、語「チャンネル」は、パケット交換ネットワークにおける２つの端末間の接続を意味し、チャンネルの容量は、送信側端末からネットワークを介して受信側端末へ伝送可能な最大ビットレートで表現される。
【０００７】
エンコードの方法が異なれば、データは、異なるビットレートでエンコードされる。例えば、広帯域コーデック（サンプリング周波数１６ｋＨｚ）である、ＩＴＵ（国際電気通信連合）  Ｇ．７２２は、６４ｋビット／秒で固定された高ビットレートでデータをエンコードし、この高レートでビット伝送可能なチャンネルを介して会話（スピーチ）を伝送するためのエンコードに用いられる。チャンネルの容量は、チャンネルの帯域幅と関係がある。高レートでビット伝送することができるチャンネルは、高い帯域幅を有する。一般に、高ビットレートでデータをエンコードすることで、入力信号の細部にわたる表現をエンコードすることが可能となり、これにより、デコードした信号も高品質となる。逆に、狭帯域コーデック（サンプリング周波数８ｋＨｚ）である、ＩＴＵ  Ｇ．７２９は、８ｋビット／秒で固定された低ビットレートでデータをエンコードし、低ビットレートでの、つまり低い帯域幅を有するチャンネルでのデータ伝送のみが可能なチャンネルを介して会話を伝送するためのエンコードに用いられる。低ビットレートでエンコードされた信号は、入力信号にかかる疎な表現であり、これによれば、デコードされた信号に含まれる情報が限定的であるために、デコードされた信号の質は低くなる。たとえ低ビットレートで信号をエンコードする場合であっても、高度に複雑化したエンコード・スキームを用いれば、より高品質なデコード信号を得ることも可能である。しかしながら、高度に複雑化したエンコード・スキームは、複雑さの程度が比較的低いエンコード・スキームより、エンコーダおよび／またはデコーダにおいて、より多くの処理リソースを必要とする。
【０００８】
チャンネルの容量を超過した場合、遅延やパケット・ロスといった劣化が信号に生じる。それ故、可能な最高のビットレードで、チャンネルの容量に対するオーバーロードなしで、信号を伝送することが望まれる。しかしながら、パケット交換ネットワークのリソースは共有されており、かつネットワークのトポロジも可変である故、チャンネルの帯域幅は固定されない。そのため、通話の間、最適なビットレートでデータをエンコードすることは困難な事柄である。
【０００９】
この困難は、適応ビットレート・コーデック（adaptive bit rate codec）を使用することで幾分軽減される。適応ビットレート・コーデックは、あるビットレートの範囲を用いて、データのエンコードを行う。例えば、適応マルチレート（ＡＭＲ）・コーデックは、１２．２、１０．２、７．９５、７．４０、６．７０、５．９０、５．１５、および、４．７５ｋビット／秒でデータをエンコードする。
【００１０】
送信側端末の帯域幅管理モジュールは、チャンネルの容量を超過したかどうかをモニタする。これは、例えば、ネットワーク・バッファにキューされたパケットの数、または、端末間で送られるデータ・パケットの往復時間（roundtrip time）から、判断される。チャンネルの最大帯域幅が用いられていないと判断されると、適応ビットレート・コーデックは、通話の間、より高いビットレートでデータのエンコードを行う。
【００１１】
しかしながら、ある場合にあっては、適応ビットレート・コーデックは、データのエンコードに用いることができない。端末のデジタル・シグナル・プロセッサに適応ビットレート・コーデックを組み込むためには、過剰な開発期間を必要としたり、あるいは、プロセッサの制約により、適応ビットレート・コーデックを組み込むことができなかったりする。また、適応ビットレート・コーデックをプロセッサにおいて使用するためのライセンシングが、ひどく高価なこともある。
【００１２】
さらに、送信側端末が、適応ビットレート・コーデックを用いてデータをエンコード可能だとしても、受信側端末が、データのデコードに適応ビットレート・コーデックを使用できないかもしれない。このように、適応ビットレート・コーデックは、受信側端末へ送信されるデータのエンコードに用いることができないかもしれない。
【発明の概要】
【発明が解決しようとする課題】
【００１３】
よって、本発明の目的は、上述した従来技術の問題点を克服することにある。特に、本発明の目的は、データレベルのエンコードに限定的な数のビットレートしか利用できない場合において、チャンネルのオーバーロードまたは待ち時間（レイテンシ、latency）の増大なしで、最適な会話品質（スピーチ・クオリティ）でデータをエンコードする方法を提供することである。
【課題を解決するための手段】
【００１４】
本発明の実施形態により、限定的な数のエンコード・ビットレートが利用可能な場合であっても、チャンネルを介した伝送のビットレートを徐々に増大させることでチャンネルの容量を調べることができる。よって、本発明の実施形態は、チャンネルのオーバーロードまたは待ち時間（レイテンシ）の増大なしで、異なるエンコード・ビットレートの間を移行することを可能とする点で有利である。
【００１５】
本発明の第１の態様は、通信ネットワークのチャンネルを介して第１ノードから第２ノードへデータを伝送する方法である。該方法は、第１ノードにおいてデータを受信するステップと、該データの第１部分を第１ビットレートでエンコードして第１エンコードデータストリームを生成するステップと、チャンネルの容量にかかる兆候（インディケーション、indication）をモニタリングするステップと、該チャンネルを介してパディングされたデータストリームを第２ノードへ送信するステップであって、該チャンネルの兆候（インディケーション）に従うようにして埋め込みビット（パディング・ビット、padding bits）を第１エンコードデータストリームに追加してパディングされたデータストリームを生成する、ステップと、パディングされたデータストリームの送信がチャンネルの容量を超過するかどうかを判断し、パディングされたデータストリームの送信がチャンネルの容量を超過しないと判断した場合には、データの第２部分を、第１ビットレートよりも高いビットレートでエンコードして第２エンコードデータストリームを生成するステップと、該チャンネルを介して第２エンコードデータストリームを第２ノードへ送信するステップと、を有する。
【００１６】
チャンネルの容量が十分に足りている（sufficient）と判断した場合にのみ、データを、より高ビットレートのコーデックでエンコードすることが好ましい。
【００１７】
したがって、本発明の好適な実施形態においては、パディングされたデータストリームのビットレートが高ビットレートと実質的に等しい場合にのみ、データの第２部分が、該高ビットレートでエンコードされる。
【００１８】
ある実施形態においては、通話のセットアップ（call set up）の間に、パディングがデータ・パケットに追加されチャンネルの容量が調査される旨をコーデックの切り換えに先立って受信側端末に通知する必要がない。その代わりに、受信側端末は、ＲＴＰ（リアルタイム・トランスポート・プロトコル、Real-time Transport Protocol）標準のフォーマットに基づいて、パディングがデータ・パケットに追加されたことを確認（アイデンティファイ、identify）してよい。ＲＴＰは、標準化団体ＩＥＴＦ（インターネット・エンジニアリング・タスク・フォース、Internet Engineering Task Force）によって開発された、オーディオおよびビデオをインターネット経由で配信するための標準的なパケットのフォーマットである。
【００１９】
よって、本発明のさらに別の実施形態においては、第１エンコードデータストリームのデータ・パケットに追加されたパディング・ビットの数が、ＲＴＰ（リアルタイム・トランスポート・プロトコル）標準に基づいて示される。
【００２０】
本発明の態様は、通信ネットワークのチャンネルを介してノードへデータを送信する送信器（トランスミッタ）である。当該送信器（トランスミッタ）は、送信すべきデータを受信する入力モジュールと、第１ビットレートまたは第２ビットレートで受信したデータをエンコードしてエンコードデータストリームを生成するエンコードモジュールであって、第２ビットレートが第１ビットレートよりも高ビットレートである、エンコードモジュールと、チャンネルを介して第２ノードへエンコードデータストリームを送信する出力モジュールと、チャンネルの容量に関する兆候（インディケーション）をモニタリングする帯域幅管理モジュールと、第１ビットレートでエンコードする際に、チャンネルの容量に関する兆候（インディケーション）に応じてエンコードデータストリームにパディング・ビットを追加してパディングされたデータストリームを生成するパディングモジュールと、を有し、帯域幅管理モジュールは、パディングされたデータストリームがチャンネルの容量を超過しているかどうか判断し、パディングされたデータストリームの送信がチャンネルの容量を超過していないと判断した場合には、エンコードモジュールを制御して受信したデータを第２ビットレートでエンコードさせる。
【図面の簡単な説明】
【００２１】
【図１】通信システムの図
【図２】本発明の実施形態によるトランスミッタの図
【図３】本発明の実施形態によるデータ・パケット送信方法を例示するフローチャート
【図４】エンコーダモジュールの図
【図５Ａ】データ・パケットの模式図
【図５Ｂ】本発明の実施形態によるパディングされたデータ・パケットの模式図
【図６】レシーバの図
【図７】本発明の実施形態によるデータ・パケット受信方法を例示するフローチャート
【図８】本発明の代替的実施形態によるパディングされたデータ・パケットの模式図
【発明を実施するための形態】
【００２２】
本発明をより深く理解し、如何にして本発明が実施されるかを示すため、本発明の実施形態を、図面を参照して説明する。
【００２３】
図１を参照する。図１は、本発明の実施形態において用いられる通信システム１００の例図である。通信システムの第１ユーザ（「ユーザＡ」１０２として示される。）は、第１ユーザ端末１０４を操作する。端末１０４は、インターネットといったネットワーク１０６に接続されていることが図示されている。ユーザ端末１０４は、例えば、パーソナル・コンピュータ（「ＰＣ」）、携帯情報端末（「ＰＤＡ」 personal digital assistant）、携帯電話、ゲーム機、ネットワーク１０６に接続可能なその他の組み込み機器でよい。第１ユーザ端末は、ユーザＡから情報を受信しかつユーザＡに情報を出力するためのユーザインタフェース手段を有する。本発明の好適な実施形態においては、該ユーザ端末のインタフェース手段は、スピーカ、マイクロフォン、スクリーンといったディスプレイ手段、ならびに、キーボード、および／または、ポインティング・デバイスを有する。ユーザ端末１０４は、モデム、アクセス・ポイント、または、基地局（ベース・ステーション、base station）といったネットワーク・インタフェース１０８を介してネットワーク１０６と接続されており、ユーザ端末１０４とネットワーク・インタフェース１０８との間は、ケーブル（有線）接続、または、無線接続でよい。
【００２４】
ユーザＢ１１４は、第２ユーザ端末１１８を操作する。オーディオ・データといったデータのネットワーク１０６上での伝送は、発呼者（例えば、ユーザＡ１０２）と被呼者（つまり、宛先（デスティネーション、destination）−この場合においては、ユーザＢ１１４）との間の通話の間に、行われてよい。ある実施形態においては、通話は、ピア・ツー・ピア・プロトコルによってセット・アップされ、発呼者（calling party）と被呼者（called party）との間のネットワーク１０６上のルートは、セントラルサーバを使わずに決定される。しかし、当然のことながらこれは一例に過ぎず、ネットワーク１０６を介した通信のための他の手段も利用可能である。
【００２５】
発呼者と被呼者との間の通話の間、ユーザＡ１０２からの発話はユーザ端末１０４へ入力される。後で詳述する端末１０４に備わった送信システムは、発話（スピーチ）をエンコードし、エンコードされた信号を、通信チャンネルを介してユーザ端末１１８へ送信する。その後、ユーザ端末１１８へ送信されたエンコードされたスピーチの信号は、デコードされ、ユーザＢ１１４へ出力される。
【００２６】
上述のように、通信ネットワーク１０６は、インターネットでよく、通信は、ＶｏＩＰを用いて行われてよい。しかし、当然のことだが、ここで詳述する通信システムは、ＶｏＩＰネットワークの用語を用いて例示されるものの、本発明の実施形態は、帯域幅のリソースが固定されないような通信システムにおいても使用することができる。例えば、ＣＤＭＡ（符号分割多元接続、Code Division Multiple Access）、ＷＣＤＭＡ（広帯域符号分割多元接続、Wideband CDMA）通信ネットワークといった、限られた帯域幅のリソースを複数のユーザが共有するようなアクセス技術においても本発明を使用することができる。
【００２７】
図２は、ユーザ端末１０４からデータを送信するための第１ユーザ端末１０４の送信システム２００の図である。
【００２８】
送信システム２００は、マイクロフォン２０２、アナログ・デジタル変換器２０４、帯域幅管理モジュール２０６、エンコードモジュール２０８、パケット化モジュール２０９、パディングモジュール２１２、および、ネットワーク・バッファ２１０を有する。当然のことだが、第２ユーザ端末１１８もまた、同等の送信システムを有してよい。
【００２９】
送信システム２００の構成要素は、端末内のハードウェア、または、端末内のプロセッサ上で実行されるソフトウェアとして実装されてよい。これは実装上の選択事項である。
【００３０】
エンコードモジュール２０８は、１つのコーデックの異なるモードを使って、または、異なるコーデックを使って、限られた数のビットレートを用いてデータをエンコードする。本発明の実施形態例においては、エンコードモジュール２０８は、８ｋビットまたは６４ｋビットのいずれかのビットレートでデータをエンコードする。
【００３１】
通話中にデータのエンコードを低ビットレートと高ビットレートとで切り換えると、チャンネルがオーバーロードしていることが検出されるよりも前に、チャンネルが著しくオーバーロードするかもしれない。このような方法でチャンネルをオーバーロードさせると、ネットワーク・バッファが非常に短時間でいっぱいになる。エンコーダを切り換えて低ビットレートに戻そうとも、ネットワーク・バッファにキューされているデータ・パケットの処理に長時間を要し、このために、大きな待ち時間（レイテンシ）、または、パケットの破棄（ドロップ）（dropped packets）のため、質の低下が生じる。
【００３２】
本発明の実施形態は、通話中に、チャンネルをオーバーロードさせずに、データのエンコードに用いるビットレートをより高いビットレートに切り換えてよいかどうかを判断する方法を提供する。
【００３３】
本発明の実施形態によれば、パディングモジュール２１２は、パケット化モジュール２０９から出力されるデータ・パケットに対し、パディング・ビットを追加し、そうすることで、端末１０４から端末１１８への送信にかかるビットレートを徐々に増大させ、これにより、徐々に増大するビットレートの送信の効果をモニタリングすることが可能となる。このように、送信されるビットレートを徐々に増大させることでチャンネルの容量を調べることができ、よって、チャンネルの著しいオーバーロードのリスクを冒さずに、より高いビットレートを用いてデータをエンコードしてよいかどうかが判断される。
【００３４】
本発明の実施形態による送信システムの動作を、図３に示したフローチャートを参照して説明する。
【００３５】
ステップＳ１において、ユーザＢ１１４に対する通話がユーザＡ１０２によって開始される。端末１０４と端末１１８との間の呼接続は、呼設定プロトコル（call-set-up protocol）を用いて行われる。呼設定の間、端末１０４と端末１１８とは、通話におけるデータのエンコードおよびデコードにどのコーデックを用いるかを交渉する。本発明の実施形態例によれば、端末１０４および１１８は、８ｋビット／秒の固定ビットレートを有する第１コーデックおよび６４ｋビット／秒の固定ビットレートを有する第２コーデックを通話中に使用してよいことを確認し（confirm）、かつ、エンコードされたデータにパディング・ビットを追加してもよいことを確認する。
【００３６】
通話の開始に続いて、ユーザＡ１０２からの発話（スピーチ）が、マイクロフォン２０２を介して端末１０４の送信システム２００へ入力される。アナログ・デジタル変換器２０４は、入力されたスピーチの信号をデジタル信号へ変換する。
【００３７】
アナログ・デジタル変換器２０４から出力されるデジタル信号は、エンコードモジュール２０８へ入力される。
【００３８】
ステップＳ２において、エンコードモジュール２０８は、信号をエンコードする。本発明の好適な実施形態によれば、通話の開始において、エンコードのブロックは、８ｋビット／秒の固定ビットレートで信号をエンコードする。利用可能な最低のビットレートを用いて信号をエンコードすることにより、通話の開始においては、確実に、チャンネルをオーバーロードさせない。
【００３９】
エンコードモジュール２０８は、エンコードされたフレームをパケット化モジュール２０９へ出力する。パケット化モジュール２０９は、エンコードされたフレームを、データ・パケット中へ挿入する。データ・パケットは、ネットワーク・バッファ２１０において送信のためのキューにならべられ、ユーザ端末１０４からチャンネルを介してユーザ端末１１８へ送信される。
【００４０】
ステップＳ３において、帯域幅管理モジュール２０６は、チャンネルの容量が超過されているかどうかを監視し、かつ、チャンネルを介して送信してよいターゲット・ビットレート（target bit rate）を推定（estimate）する。チャンネルの容量を超過していなければ、推定されるターゲット・ビットレートは、パケット化モジュール２０９から出力されるパケットストリームの現在のビットレートよりも大きくなる。例えば、送信されたデータ・パケットが端末間を往復する時間（round trip time）のモニタリングや、ネットワーク・バッファにキューされたパケットの数のモニタリングや、チャンネルの推定帯域幅のモニタリングにより、ターゲット・ビットレートを推定してよい。当業者であれば容易に理解すると思われるが、帯域幅管理モジュールでターゲット・ビットレートを推定するのに用いることができる方法は、数多く知られている。これらについて、ここでは触れない。
【００４１】
本発明の実施形態によれば、パディングモジュールは、推定されたターゲット・ビットレートに基づいて、データ・パケットにパディング・ビットを追加することにより、チャンネルの容量を超過しないかぎり、チャンネルを介して送信されるビットレートを徐々に、第２コーデックのビットレートに近づける。
【００４２】
ステップＳ４において、パディングモジュールは、チャンネルを介して送信されるビットレートを徐々に調整するために、パケット化モジュール２０９から受信したデータ・パケットのペイロードに追加されるべきパディング・ビットの数を算出する。この漸増的ビットレート調整の値は、ターゲット・ビットレートに依存し、よって、ターゲット・ビットレートが高いなら、ビットレートに対して大きな調整がなされる。本発明のある実施形態においては、漸増的ビットレート調整は、次式で算出される。
ΔＢＲＰ＝（（ＢＲＴＣＨ−ＢＲＨ）−ＢＲＣ）−ＢＲＰＣｕｒｒｅｎｔ            式（１）
ここで、ΔＢＲＰは、漸増的ビットレート調整量であり、ＢＲＴＣＨは、チャンネルの推定されたターゲット・ビットレートであり、ＢＲＨは、ヘッダのビットレートであり、ＢＲＣは、コーデックのビットレートであり、ＢＲＰＣｕｒｒｅｎｔは、現在のパディングビットレートである。
【００４３】
本発明の代替的実施形態においては、ビットレート調整量（bit rate adjustment）は、ルックアップ・テーブルから決定される。
【００４４】
ステップＳ５において、パディングモジュール２１２は、ビットレートを増大させる。ここでは、パディング・ビットが、パケット化モジュール２０９から出力されたデータ・パケットのペイロードに、式（１）に基づいて、追加される。
【００４５】
パディングモジュール２１２は、パディングされたデータ・パケットを、ネットワーク・バッファ２１０へ出力する。ネットワーク・バッファ２１０は、ネットワーク・バッファ２１０から出力されるデータ・パケットを、通信ネットワーク１０６を介した送信のために、キューに格納する。
【００４６】
ステップＳ６において、パディングモジュールは、パディングモジュールから出力されるパディングされたパケットストリームのビットレートが所定の閾ビットレート値に等しいかまたはより大きいか（以上か）どうか判断する。本発明の好適な実施形態においては、閾ビットレート値は、実質的には、第２コーデックがデータをエンコードする際のビットレートに等しい。実施形態例においては、閾値は、６４ｋビット／秒（64 kbit/s）に等しい。
【００４７】
パディングされたパケットストリームのビットレートが閾ビットレート値よりも小さいと判断した場合、本方法は、ステップＳ９へ進む。
【００４８】
本発明の一実施形態によれば、低ビットレート・コーデックから高ビットレート・コーデックへ切り換える試みは、所定の適応期間（アダプション・ピリオド、adaption period）の後、終了する。ステップＳ９においては、適応期間が満了したかどうかを判断する。本発明の好適な実施形態においては、適応期間は、通話の開始から２分後に満了する。
【００４９】
適応期間（アダプテーション・ピリオド、adaptation period）が満了すれば、本方法は、ステップＳ１１へ移行する。パディングモジュール２１２は、パケット化モジュール２０９から出力されるデータ・パケットに対してパディング・ビットを追加することを止め、アナログ・デジタル変換器から出力されるデジタル信号を、引き続き、低ビットレート・コーデックを用いてエンコードする。
【００５０】
しかしながら、適応時間（アダプテーション・タイム、adaptation time）が満了していなければ、本方法は、ステップＳ３へ戻り、パディングされたデータ・パケットが送信される際に、帯域幅管理モジュールが、チャンネルのターゲット・ビットレートを推定する。チャンネルの容量を超過しているならば、ターゲット・ビットレートを低減し、ステップＳ５において決定したパディングの量を減少させる。逆に、チャンネルがオーバーロードになっていないならば、ステップＳ５において決定したパディングの量を増大させ、パディングモジュールから出力されるパディングされたパケットストリームのビットレートを、徐々に、第２コーデックのビットレートに近づける。
【００５１】
しかしながら、ステップＳ６においてパディングされたパケットストリームのビットレートが閾ビットレート値に等しいかまたはよりも大きい（以上である）と判断すると、本方法は、ステップＳ７へ進む。
【００５２】
ステップＳ７において、帯域幅管理モジュールが、所定時間にわたり、例えば、３０秒間にわたり、チャンネルの容量をモニタリングして、このとき、チャンネルがオーバーロード状態になっていないことを確かめる。
【００５３】
所定時間が満了する前にチャンネルの容量を超過しなければ、チャンネルの容量は安定的であると判断され、ステップＳ８において、パディングモジュールは、エンコードモジュールを制御して、アナログ・デジタル変換器から出力されるデジタル信号を、第２コーデックを用いてエンコードさせる。
【００５４】
しかしながら、所定時間の間にチャンネルがオーバーロードに達すれば、本方法は、ステップＳ９へ移行する。
【００５５】
本発明の一実施形態においては、帯域幅管理モジュールは、適応期間満了後も、継続してチャンネルの容量をモニタする。チャンネルの容量を著しく超過すると、例えば、ターゲット・ビットレートが４５ｋビット／秒であると推定されると、または、もう少し長い期間にわたり、例えば、ターゲット・ビットレートが、３０秒間にわたり５８ｋビット／秒であると推定されると、帯域幅管理モジュールは、パディングモジュールに対し、チャンネル容量の超過を報告する。応答として、パディングモジュールは、エンコードモジュールを制御してアナログ・デジタル変換器から出力されるデジタル信号を、第１コーデックを用いてエンコードさせる。本発明のこの実施形態によれば、ほんの短い期間にわたって、チャンネルの容量を超過するのみならば、デジタル信号は、第１コーデックでエンコードされない。これにより、小規模なネットワーク・コンディションの揺らぎを許容することが可能になる。
【００５６】
エンコードモジュール２０８の詳細を示す図４を参照する。エンコードモジュール２０８は、低ビットレート・エンコーダ４０２、および、高ビットレート・エンコーダ４０４を有する。
【００５７】
低ビットレート・エンコーダ４０２は、Ｇ．７２９といった、固定低ビットレートを用いるコーデックを用いてデータをエンコードする。あるいは、低レートエンコーダは、適応型低ビットレート（adaptive low bit rate）を用いてデータをエンコードしてもよい。
【００５８】
高ビットレート・エンコーダは、Ｇ．７２２といった、固定高ビットレートを用いるコーデックを用いてデータをエンコードする。あるいは、高レートエンコーダは、適応型高ビットレート（adaptive high bit rate）を用いてデータをエンコードしてもよい。
【００５９】
実施される間、デジタル信号が、アナログ・デジタル変換器２０４からエンコードモジュール２０８へ入力される。エンコードモジュールは、図３を参照して既に説明した本方法に従い、低ビットレートエンコーダまたは高ビットレートエンコーダのいずれかを用いてデジタル信号をエンコードする。
【００６０】
高ビットレートエンコーダまたは低ビットレートエンコーダのいずれかから出力された、エンコードされたデータフレームは、エンコードモジュールから出力され、図２に示すパケット化モジュール２０９へ入力される。
【００６１】
図５Ａは、パケット化モジュール２０９から出力されるデータ・パケットを示す図である。データ・パケットは、ヘッダ５０１およびペイロード５０２を有する。ペイロード５０２は、２つのエンコードされたフレーム５０３、５０４を含む。パケット化モジュール２０９から出力されたデータ・パケットは、パディングモジュール２１２へ入力される。
【００６２】
上述のように、パディングモジュール２１２は、データ・パケットのペイロードに対し、パディング・ビットを追加してデータ・パケットを修正し、端末１０４から出力されるパケットストリームのビットレートを増大させる。図５Ｂは、修正されたペイロード５０２’を含んだデータ・パケットを示す図である。
【００６３】
本発明の好適な実施形態によれば、パディング・ブロックを構成するデータ・パケットのペイロードに、パディング・ブロックが追加される。ここで、パディング・ブロックは、それぞれが２バイトを有する。
【００６４】
修正されたペイロード５０２’は、パディングモジュール２１２が挿入したパディング・ブロックを含んでいる。図５ｂには、４つのパディング・ブロック５０５、５０６、５０７、５０８が、データ・パケットの修正されたペイロード５０２’の中に示されている。
【００６５】
本発明の好適な実施形態によれば、１バイトのテーリング・ブロック（tailing block）５０８ａが、修正されたデータ・パケットに含まれるパディング・ブロックの数を示している。この場合、テーリング・ブロックは、ペイロード中に４つのパディング・ブロックが存在することを示す。
【００６６】
本発明の好適な実施形態によれば、パディング・ブロックは、偶数バイトに、テーリング・ブロックは、奇数バイトになるように構成される。そのような奇数バイトをデータ・パケットのペイロードに追加することにより、パディングされたデータ・パケットを生成する。本発明の実施形態によれば、エンコードモジュールは、偶数バイトを有するエンコードされたフレームを出力し、受信側端末は、データ・パケット中のバイト数をモニタすることによりパケットにパディングがなされているかどうかを判断してもよい。第２ユーザ端末の動作については、図６を参照して詳述する。
【００６７】
図６は、ネットワーク１０６からデータを受信する第２ユーザ端末１１４の受信システムを示す図である。
【００６８】
受信システム２２０は、パディング除去モジュール（デパディングモジュール、de-padding module）２２４、ジッタ・バッファ２２２、パケット化解除モジュール（デパケタイジングモジュール、de-packetizing module）２２５、デコードモジュール２２６、デジタル・アナログ変換器２２８、および、スピーカ２３０を有する。当然のことながら、第１ユーザ端末１０４は、ネットワークからデータを受信するため、同等の受信システムを有してよい。
【００６９】
受信システムの構成要素は、端末内のハードウェア、または、端末内のプロセッサ上で実行されるソフトウェアとして実装されてよい。これは実装上の選択事項である。
【００７０】
以下、図７のフローチャートを参照し、受信システム２２０においてパディングされたデータ・パケットを受信する方法を説明する。
【００７１】
ユーザ端末１０４との通話の開始の後、ステップＳ２１において、ユーザ端末１０４からデータ・パケットを受信する。
【００７２】
ステップＳ２２において、受信したデータ・パケットをパディング除去モジュール２２４へ入力する。パディング除去モジュールは、受信したパケットにパディングが含まれるかどうか判断する。
【００７３】
本発明の実施形態によれば、パディング除去モジュールは、パディングされていないデータ・パケット（アンパデッド・データ・パケット、unpadded data packet）およびパディングされたパケット（パデッド・パケット、padded packet）それぞれに含まれるバイト数に関する情報を用いて、パケットがパディングを含んでいるかどうか判断する。一般にＶｏＩＰシステムは、Ｎ×１０ｍｓのブロックからなるオーディオ・データを含んだデータ・パケットを使用する。ここで、Ｎは整数である。１６ｋＨｚの信号の２サンプルにつき１バイトを使用するＧ．７２２を用いてエンコードしたデータを含んだ、上述のようなデータ・パケットは、Ｎ×８０バイトを含んでいる。このため、Ｇ．７２２を用いてエンコードしたデータを含んだデータ・パケットは、偶数バイトを含んでいる。同様、Ｇ．７２９を用いてエンコードしたデータを含んだパケットは、Ｎ×１０バイトを含んでいる。このため、Ｇ．７２９を用いてエンコードしたデータを含んだデータ・パケットは、偶数バイトを含んでいる。既に述べたとおり、パディングモジュールは、パケットに対し、奇数のパディング・バイトを追加することができる。この実施形態例においては、パケットのペイロードのバイト数が偶数であれば、パディング除去ブロックは、当該データ・パケットはパディングされていないと判断し、逆に、データ・パケットのペイロードのバイト数が奇数であれば、パディング除去モジュールは、当該データ・パケットはパディング・ブロックを含んでいると判断する。この実施形態例においては、パディング・ブロックは、Ｇ．７２９を用いてエンコードされたデータ・パケットに対してのみ、付加される。
【００７４】
パケットがパディング・ブロックを含んでいる、と判断された場合、本方法は、ステップＳ２３へ進む。逆に、パケットがパディング・ブロックを含んでいない、と判断された場合、本方法は、ステップＳ２５へ直接的に移行する。
【００７５】
ステップＳ２３において、パディング除去モジュールは、テーリング・ブロックを解析して、当該パケットのペイロードに含まれるパディング・ブロックの数を求める。
【００７６】
ステップＳ２４において、パディング除去ブロックは、ステップＳ２３で求めた数のブロックを、当該パケットのペイロードから除去する。それから、本方法はステップＳ２５へ移行する。
【００７７】
ステップＳ２５において、パディング除去モジュールは、ユーザ端末１０４においてデータをエンコードするために使用するコーデックを決定する。本発明の好適な実施形態においては、パディング除去モジュールは、データ・パケットのペイロードのバイト数が、所定の閾値を上回っているかどうか判断する。データ・パケットのペイロードのバイト数が当該閾値に等しいかまたは上回っているならば（閾値以上ならば）、パディング除去モジュールは、当該パケットは高ビットレート・コーデックを用いてエンコードされている、と判断する。逆に、データ・パケットのペイロードのバイト数が、当該閾値を下回っていると、パディング除去モジュールは、当該パケットは低ビットレート・コーデックを用いてエンコードされている、と判断する。本発明の実施形態例においては、低ビットレート・コーデックを用いてエンコードされたデータ・パケットは、それぞれ、１０乃至７０ｍｓのオーディオ・データを含んでおり、パケットが低ビットレート・コーデックを用いてエンコードされているかどうかの判断に用いる閾値は、８０バイトである。
【００７８】
いずれのコーデックを用いてデータをエンコードしているかの判断に呼応して、パディング除去モジュールは、デコードモジュールを制御し、当該判断がなされたコーデックを用いてデータをデコードさせる。
【００７９】
ステップＳ２６において、データ・パケットは、ジッタ・バッファ２２２へ出力される。ジッタ・バッファにおいては、データ・パケットは、パケット化解除モジュール２２５へ出力される前に、キューに入る。パケット化解除モジュールは、データ・パケットのペイロードから、エンコードされたフレームを取り外す。そして、エンコードされたフレームは、パケット化解除モジュール２２５から出力され、デコードモジュール２２６へ入力される。デコードモジュールは、エンコードされたフレームをデコードし、デジタル信号を出力する。そして、デジタル信号は、デジタル・アナログ変換器２２８によりアナログ信号へ変換され、スピーカ２３０から出力される。
【００８０】
本発明の代替的実施形態においては、エンコードモジュールは、エンコードモジュールから出力するフレームに対して、パディング・ビットを追加してもよい。図８に示されるデータ・パケット８００は、エンコードモジュールから出力される各フレームに付加されるパディングを含む。この実施形態においては、パディング・ブロック５０５、５０６、５０７、および、５０８は、エンコードされたフレーム５０３および５０４の間に配置される。
【００８１】
本発明の好適な実施形態によれば、パディング・ブロックは、ゼロ（zeros）を含んでよい。
【００８２】
好適な実施形態を参照しながら本発明を具体的に示し、説明したが、当然のことながら、当業者であれば、添付の特許請求の範囲に規定される発明の範囲から逸脱することなしに、形態や細部に変更を加えることができる。
【００８３】
とりわけ、以下で議論するように、多くの代替的実施形態が可能である。
【００８４】
例えば、上述の実施形態においては、本発明は、ユーザ端末において実施される。代替的実施形態においては、本発明は、ユーザ端末の間にあるリレーピアのノード（repay peer node）といったネットワーク・ノードにおいて実施されてもよい。
【００８５】
本発明の一実施形態においては、パディング・ブロックを用いて順方向誤り訂正（forward error correction）を行ってよい。
【００８６】
上述した実施形態においては、受信システムは、データ・パケットの長さを解析することによって、データ・パケットがパディングを含んでいるかどうかを判断する。だが、本発明の代替的実施形態においては、データ・パケットがパディングを含んでいるかどうか、に関する情報は、周知の標準ＲＴＰ（リアルタイム・トランスポート・プロトコル、Real-time Transport Protocol）を用いるデータ・パケットに含まれるようにして提供されてよい。本発明のそのような実施形態により、パディングモジュールが、当該データ・パケットのヘッダ内にフラグを設定することにより、該データ・パケットにパディング・ブロックが含まれることを示す。パディングの最後のバイト（last byte）は、幾つのパディング・バイトがデータ・パケット内に存在するかを示す。そうすることで、ＲＴＰセッションをサポートする受信システムであれば、本発明の実施形態によりデータ・パケットに追加されたパディング・ビットを除去することが可能となる。この場合において端末に要求されることは、データのエンコードおよびデコードに用いられるコーデックをどれにするかについて、合意することのみである。
【００８７】
本発明の代替的実施形態により、パディング・ブロックは、エンコードされたデータのパケットとは独立して、別個のデータ・パケットに含まれてもよい。
【００８８】
本発明の一実施形態においては、帯域幅管理モジュールは、パディングモジュールに対し、チャンネルの容量を超過していない場合にビットレートを「増大」させる指示をし、また、チャンネルの容量を超過している場合にビットレートを「低減」させる指示を送る。応答として、パディングモジュールは、信号のビットレートを、所定量だけ調整する。
【００８９】
本発明の代替的実施形態においては、ステップＳ９に記載の適応期間は、通話の間継続してもよい。あるいは、適応期間は、所定時間の後、再開されてもよい。
【００９０】
本発明の代替的実施形態においては、データをエンコードするために用いたコーデックに関する情報は、データ・パケットのヘッダに含めてよい。よって、ステップＳ２５においては、パディング除去モジュールは、データのエンコードに用いられたコーデックを、データ・パケットのヘッダを解析することにより、決定してもよい。
【符号の説明】
【００９１】
１００    通信システム
１０４    第１ユーザ端末
１０６    ネットワーク
１０８    ネットワーク・インタフェース
１１８    第２ユーザ端末
２００    送信システム
２０２    マイクロフォン
２０４    アナログ・デジタル変換器
２０６    帯域幅管理モジュール
２０８    エンコードモジュール
２０９    パケット化モジュール
２１０    ネットワーク・バッファ
２１２    パディングモジュール
４０２    低ビットレート・エンコーダ
４０４    高ビットレート・エンコーダ
５０１    ヘッダ
５０２    ペイロード
５０２’  （修正された）ペイロード
５０３    （エンコードされた）フレーム
５０４    （エンコードされた）フレーム
５０５    パディング・ブロック
５０６    パディング・ブロック
５０７    パディング・ブロック
５０８    パディング・ブロック
５０８ａ  テーリング・ブロック
２２２    ジッタ・バッファ
２２４    パディング除去モジュール
２２５    パケット化解除モジュール
２２６    デコードモジュール
２２８    デジタル・アナログ変換器
２３０    スピーカ
８００    データ・パケット
【図１】
0005442771.tif 000002
【図２】
0005442771.tif 000003
【図３】
0005442771.tif 000004
【図４】
0005442771.tif 000005
【図５ａ】
0005442771.tif 000006
【図５ｂ】
0005442771.tif 000007
【図６】
0005442771.tif 000008
【図７】
0005442771.tif 000009
【図８】
0005442771.tif 000010