(57)【要約】  本発明は、複数のセッションを共有リソースにより設定するパケット交換通信システムにおけるセッションのビットレートを制御する方法に関する。セッションの現行ビットレートをセッションに有効なビットレート範囲と比較し、現行ビットレートの位置からビットレート範囲の１つの終端点への距離を判定する。選択する終端点への距離に応じて種々に、現行ビットレートを次いで適応させる。このようにユーザに遅延に敏感なサービスを提供するアプリケーションに対し共有リソースにより設定する各セッションのビットレートを制御することにより、本方法および対応するシステム並びに送信機―受信機装置はレート適応をアプリケーション間に分散させることができ、従ってユーザがレート適応の責任を分担する効果を持つ。【選択図】  なし
2010533419.tif 000002
【特許請求の範囲】
【請求項１】
共有リソースを介して複数のセッションがセットアップされるパケット交換通信システムにおけるセッションのビットレートを制御する方法であって、
前記セッションに対して有効なビットレート範囲であって、上限及び下限を有するビットレート範囲を判定するステップと、
前記セッションの現行ビットレートと前記ビットレート範囲とを比較して、前記ビットレート範囲の前記上限への距離あるいは前記下限への距離を判定するステップと、
前記距離に応じて前記現行ビットレートを適応させるステップと
を備えることを特徴とする方法。
【請求項２】
前記距離が短い場合、前記距離が長い場合に比べて、前記距離に依存する量が大きくなるように、前記現行ビットレートは前記量によって適応される
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記現行ビットレートが前記ビットレート範囲の前記上限に近い場合、前記現行ビットレートが前記ビットレート範囲の前記下限に近い場合に比べて、前記現行ビットレートがより引き下げられるように、前記現行ビットレートを適応させるステップが実行される
ことを特徴とする請求項１に記載の方法。
【請求項４】
前記現行ビットレートが前記ビットレート範囲の前記下限に近い場合、前記現行ビットレートが前記ビットレート範囲の前記上限に近い場合に比べて、前記現行ビットレート範囲がより引き上げられるように、前記現行ビットレートを適応させるステップが実行される
ことを特徴とする請求項１に記載の方法。
【請求項５】
前記ビットレートを判定するステップは、更に、前記セッションに対するセットアップ処理において前記ビットレート範囲を信号通知することを含む
ことを特徴とする請求項１に記載の方法。
【請求項６】
前記セッションにおける通信のために、明示的な輻輳通知付きユーザ・データグラム・プロトコルが使用される
ことを特徴とする請求項１に記載の方法。
【請求項７】
前記ビットレート範囲に対する前記上限及び前記下限は、前記セッションに対して許容される特定のサービス品質に関連している
ことを特徴とする請求項１に記載の方法。
【請求項８】
前記現行ビットレートを適応させるステップは、更に、加入者プロパティに応じて前記現行ビットレートを適応させることを含む
ことを特徴とする請求項１に記載の方法。
【請求項９】
前記現行ビットレートを適応させるステップは、更に、前記現行ビットレートを絶対量まで適応させる、あるいは前記現行ビットレートが特定ビットレート値を上回る場合には前記現行ビットレートを前記特定ビットレート値に適応させることを含む
ことを特徴とする請求項１に記載の方法。
【請求項１０】
共有リソースを介するセッションにおいて送信機によって送信されるパケット交換符号化メディアを受信する受信機であって、
前記セッションに対して有効なビットレート範囲であって、上限及び下限を有するビットレート範囲を判定するためのビットレート判定手段と、
前記現行受信ビットレートと前記ビットレート範囲とを比較して、前記ビットレート範囲の前記上限への距離あるいは前記下限への距離を判定し、前記距離に応じてビットレート適応量を推定することによって、前記ビットレート適応量を推定するビットレートリクエスト推定手段と、
前記セッションにおける現行送信ビットレートに適応させることを、前記送信機にリクエストするレートリクエスト手段と
を備えることを特徴とする受信機。
【請求項１１】
前記距離が短い場合、前記距離が長い場合に比べて、前記ビットレート適応量が大きくなるように、前記ビットレート適応量は前記距離に依存する
ことを特徴とする請求項１０に記載の受信機。
【請求項１２】
前記ビットレートリクエスト推定手段は、前記現行受信ビットレートが前記ビットレート範囲の前記上限に近い場合、前記現行受信ビットレートが前記ビットレート範囲の前記下限に近い場合に比べて、前記現行受信ビットレートがより引き下げられるように、前記現行ビットレート適応量を推定するように構成されている
ことを特徴とする請求項１０に記載の受信機。
【請求項１３】
前記ビットレートリクエスト推定手段は、前記現行受信ビットレートが前記ビットレート範囲の前記下限に近い場合、前記現行受信ビットレートが前記ビットレート範囲の前記上限に近い場合に比べて、前記現行受信ビットレートがより引き上げられるように、前記現行ビットレート適応量を推定するように構成されている
ことを特徴とする請求項１０に記載の受信機。
【請求項１４】
前記ビットレートリクエスト推定手段は、前記ビットレート適応量を推定するために、パケット損失レート、ジッタ、ネットワークフィードバックメッセージ及びアプリケーション設定の内の少なくとも１つの情報タイプを考慮するように構成されている
ことを特徴とする請求項１０に記載の受信機。
【請求項１５】
前記受信機は、
前記共有リソースから輻輳通知メッセージを検出するための検出手段を更に備え、
前記ビットレートリクエスト推定手段は、前記輻輳通知メッセージの検出時に、前記ビットレート適応量を推定する
ことを特徴とする請求項１０に記載の受信機。
【請求項１６】
前記レートリクエスト手段は、前記セッションにおける現行送信ビットレートに適応させることを前記送信機にリクエストする場合に、前記ビットレート適応量を含めるように構成されている
ことを特徴とする請求項１０に記載の受信機。
【請求項１７】
前記セッションで受信される前記パケット符号化メディアを復号するための少なくとも１つのメディアデコーダを更に備える
ことを特徴とする請求項１０に記載の受信機。
【請求項１８】
共有リソースを介するセッションにおいて、パケット交換符号化メディアを受信機に送信する送信機であって、
前記セッションに対して有効なビットレート範囲であって、上限及び下限を有するビットレート範囲を判定するためのビットレート判定手段と、
前記セッションの現行送信ビットレートに適応させるためのリクエストを、前記受信機から受信するためのレートリクエスト受信手段と、
前記受信機からのリクエストに応じて、前記現行送信ビットレートが、前記ビットレート範囲の前記上限への距離あるいは前記下限への距離に応じて適応されるように、前記セッションの前記現行送信ビットレートのレート適応を制御するためのレート適応制御ユニットと
を備えることを特徴とする送信機。
【請求項１９】
前記距離が短い場合、前記距離が長い場合に比べて、前記距離に依存する量が大きくなるように、前記現行送信ビットレートは前記量によって適応される
ことを特徴とする請求項１８に記載の送信機。
【請求項２０】
前記レート適応制御ユニットは、前記現行送信ビットレートが前記ビットレート範囲の前記上限に近い場合、前記現行送信ビットレートが前記ビットレート範囲の前記下限に近い場合に比べて、前記現行送信ビットレートがより引き下げられるように、前記現行送信ビットレートの前記レート適応量を制御するように構成されている
ことを特徴とする請求項１８に記載の送信機。
【請求項２１】
前記レート適応制御ユニットは、前記現行送信ビットレートが前記ビットレート範囲の前記下限に近い場合、前記現行送信ビットレートが前記ビットレート範囲の前記上限に近い場合に比べて、前記現行送信ビットレート範囲がより引き上げられるように、前記現行送信ビットレートの前記レート適応量を制御するように構成されている
ことを特徴とする請求項１８に記載の送信機。
【請求項２２】
前記レート適応制御ユニットは、前記現行送信ビットレートと前記ビットレート範囲とを比較することによって、前記ビットレート範囲の前記上限への距離あるいは前記下限への距離を判定するように構成されている
ことを特徴とする請求項１８に記載の送信機。
【請求項２３】
推定ビットレート適応量が、前記現行送信ビットレートに適応させるために、前記受信機の前記リクエストに含められ、
前記レート適応制御ユニットは、前記セッションの前記現行送信ビットレートのレート適応量を判定するための入力として、前記推定ビットレート適応量を使用するように構成されている
ことを特徴とする請求項１８に記載の送信機。
【請求項２４】
前記レート適応制御ユニットは、前記ビットレート適応量を推定するために、パケット損失レート、ジッタ、ネットワークフィードバックメッセージ及びアプリケーション設定の内の少なくとも１つの情報タイプを考慮するように構成されている
ことを特徴とする請求項１８に記載の送信機。
【請求項２５】
前記セッションで送信される前記パケット符号化メディアを出力するための少なくとも１つのメディアエンコーダを更に備える
ことを特徴とする請求項１８に記載の送信機。
【請求項２６】
少なくとも第１のセッションと第２のセッションとのビットレートを制御するためのパケット交換通信システムであって、
前記第１のセッションにおいて共有リソースを介して、第１の受信機と通信するために動作可能な少なくとも１つの第１の送信機と、
前記第２のセッションにおいて前記共有リソースを介して、第２の受信機と通信するために動作可能な少なくとも１つの第２の送信機と、
前記第１のセッションに対して有効な第１のビットレート範囲であって、上限及び下限を有する第１のビットレート範囲を判定する第１のビットレート範囲判定手段と、
前記第２のセッションに対して有効な第２のビットレート範囲であって、上限及び下限を有する第２のビットレート範囲を判定する第２のビットレート範囲判定手段と、
第１の現行ビットレートが、前記第１のビットレート範囲の前記上限への第１の距離あるいは前記下限への第１の距離に応じて適応されるように、前記第１のセッションの前記第１の現行ビットレートのレート適応を制御するための第１のレート適応制御ユニットと、
第２の現行ビットレートが、前記第２のビットレート範囲の前記上限への第２の距離あるいは前記下限への第２の距離に応じて適応されるように、前記第２のセッションの前記第２の現行ビットレートのレート適応を制御するための第２のレート適応制御ユニットと
を備えることを特徴とするパケット交換通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、デジタル通信システムにおけるレート制御方法および装置に関する。
【背景技術】
【０００２】
デジタルパケット交換通信システムでは、様々なタイプのトラフィック、例えば、音声、データ、オーディオおよびビデオを、複数パーティ間で共有リソース、例えば、ルータまたは伝送チャネルを介して搬送することができる。多くのオーディオおよびビデオアプリケーションのようなあるトラフィックは、典型的には、リアルタイムで発生するが、多くのデータアプリケーションのようなその他のトラフィックは、典型的には、非リアルタイムトラフィックである。
【０００３】
このようなシステムでは、送信機は、送信パーティから受信しているメディアを符号化し、受信機に送信するアプリケーションまたはエンティティである。受信機は、メディアを受信し、復号し、そして、受信パーティに提示するアプリケーションまたはエンティティである。送信機もしくは受信機または両者として動作するアプリケーションは、クライアントまたはサーバ、例えば、ユーザ装置、もしくは送信パーティまたは受信パーティのその他のハードウェアに実装することができる。アプリケーションは、クライアントもしくはサーバにおいて動作し、サービスを、例えば、ユーザまたはその他のパーティに提供もしくは配信することができる。より詳細には、アプリケーションは、サーバにおいて動作し、メディアを符号化して、クライアントに送信することできる。クライアントでは、アプリケーションは、メディアを受信し、復号して、ユーザに提示するように動作しようとし、これによって、サーバおよびクライアントにおいて動作するアプリケーションはユーザにサービスを提供するように機能する。サービスは、１つまたはいくつかのメディアタイプ、例えば、音声およびデータもしくはビデオ並びにオーディオを含むことができる。
【０００４】
非リアルタイムトラフィックと比べて、リアルタイムトラフィックに対しては、様々な伝送要件が求められている。例えば、ファイル伝送のような非リアルタイムトラフィックは、パケット損失、即ち、データパケットが受信端において正常に受信されないことを許容しないが、伝送遅延にはリアルタイムトラフィックほど敏感ではない。一方、リアルタイムトラフィックは、いくつかのパケット損失に耐えうるが、非リアルタイムトラフィックより伝送遅延に敏感である。それゆえ、リアルタイムトラフィックおよび非リアルタイムトラフィックそれぞれの必要性に応じるために、様々なタイプの伝送プロトコルが設計されてきている。非リアルタイムトラフィックの要件を満足するように適合されているプロトコルの一例には、伝送制御プロトコル（ＴＣＰ：Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）があり、リアルタイムトラフィックの要件を満足するように適合されているプロトコルの一例には、ユーザ・データグラム・プロトコル（ＵＤＰ：Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）がある。ＵＤＰの典型的な用途は、ボイスオーバＩＰ（ＶｏＩＰ：Ｖｏｉｃｅ  ｏｖｅｒ  ＩＰ）およびメディアストリーミングのようなリアルタイム性を厳格に要求するデータに対するものである。ＵＤＰの別の用途には、オンラインゲーム用の制御データのシグナリングに対するものである。
【０００５】
図１は、１つの入口ノード（ingress node）１１０および複数の出口ノード（egress node）１００を有する共有リソース１２０の例を示している。ここで、ユーザ間で共有リソースを利用するパケット交換ネットワークは、輻輳を経験することがあることは周知の事実である。共有リソースの入口ノード、即ち、入口点のトラフィックの合計が同一の共有リソースの出口ノード、即ち、出口点のトラフィックの合計を超える場合、輻輳が生じることになる。最も典型的な例は、特定数の接続を有するルータである。リンクスループットに従って、トラフィックを再ルーティングするために十分な処理能力をルータが有しているとしても、現行で利用可能なリンクスループットは、ルータから発信リンクが対応することができるトラフィック量を制限する可能性がある。このため、ルータのバッファ量が増大し、最終的には、オーバフローすることになろう。ネットワークは、次いで、輻輳を経験し、そして、ルータは、パケットの廃棄を強いられることになる。
【０００６】
輻輳の別の例を見ることができるのは、ＩＥＥＥ８０２．１１ａ／ｂ／ｇにおいて仕様が定められている無線ローカル・エリア・ネットワーク（ＷＬＡＮ：Ｗｉｒｅｌｅｓｓ  Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）のような共有チャネルを有する無線ネットワーク、または高速パケットアクセス（ＨＳＰＡ：Ｈｉｇｈ−Ｓｐｅｅｄ  Ｐａｃｋｅｔ  Ａｃｃｅｓｓ）、ロング・ターム・エボリューション（ＬＴＥ：Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）および世界的マイクロ波アクセス相互運用（ＷｉＭＡＸ：Ｗｏｒｌｄｗｉｄｅ  Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ  ｆｏｒ  Ｍｉｃｒｏｗａｖｅ  Ａｃｃｅｓｓ）のような移動ネットワークを調べる場合である。これらのネットワークでは、少なくともダウンリンクがユーザ間で共有され、それゆえ、輻輳を経験する可能性のある候補である。例えば、図２に示されるＬＴＥの場合では、ｅＮＢ基地局２２０は伝送チャネル２１０を経て移動端末、即ち、ユーザ機器（ＵＥ：Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ）２００へのメディアアクセス制御（ＭＡＣ：Ｍｅｄｅｉｕｍ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）における再送信を管理するが、これは、ｅＮＢ基地局が任意の所与の瞬間にスループットを提供することができるトラフィック量に影響を与えることになる。ＵＥにおいて受信を成功するために要求される再送信が多いと、それだけ他のユーザにスループットを提供するために利用可能な能力が少なくなり、それにより、共有リソースの伝送容量の使用がより非効率的になる。
【０００７】
ルーティングノードの正常動作は、入力／出力リンク容量の一定の変動量を管理することで、小さな輻輳の発生を吸収することができるバッファ量を提供することである。しかしながら、輻輳が深刻し過ぎる場合、ルーティングノードは、最終的には、パケットを廃棄することになる。
【０００８】
ＴＣＰトラフィックの場合、廃棄パケットは、送信機によって検出されることになるが、これは、特定のパケットに対して確認応答（ＡＣＫ：Ａｃｋｎｏｗｌｅｄｇｅ）が受信されず、また、再送信が発生することになるからである。さらに、ＴＣＰプロトコルは、組み込みレート適応メカニズムを有し、このメカニズムは、パケット損失が生じ、かつインターネットプロトコル（ＩＰ：Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）レイヤにおいて再送信が生じる場合、送信ビットレートを引き下げることになる。再送信タイムアウト値によって設定される特定の時間間隔内にＡＣＫが受信されない場合、データが再送信される。ＴＣＰ再送信タイムアウト値は、往復（ラウンドトリップ）時間に基づいて、各接続に対して動的に判定される。受信機では、順不同で受信される可能性があるセグメントを正しく順序付けし、かつ重複を解消するために、シーケンス番号が使用される。受信に成功した最終セグメントの後に受信可能なシーケンス番号範囲を示すためのウィンドウを、各応答確認で返信することによって、ＴＣＰは送信データ量を管理する。このウィンドウは、更なる許可を受信する前に送信機が送信することができる許容オクテット数を示す。このフロー制御はプロトコル自体に組み込まれているので、ＴＣＰは、使用するアプリケーションに関わらず、ＴＣＰはレート適応メカニズムを提供する。このメカニズムは、輻輳が発生する場合、送信ビットレートを段階的に引き下げることができ、また、輻輳が止まる場合に送信ビットレートを段階的に引き上げることができる効果を有している。
【０００９】
ルーティングノードの性能をさらに高めるために、「ＩＰ用の明示的な輻輳通知（ＥＣＮ：Ｅｘｐｌｉｃｉｔ  Ｃｏｎｇｅｓｔｉｏｎ  Ｎｏｔｉｆｉｃａｔｉｏｎ）」と呼ばれる方式が開発され、ＩＥＴＦ仕様書ＲＦＣ３１６８にその仕様が定められている。この内容は、参照するによって、その仕様書の全てが本明細書に組み込まれる。図３に示されるように、この方式は、ＩＰヘッダ３２０におけるサービスタイプ（ＴＯＳ：Ｔｙｐｅ  Ｏｆ  Ｓｅｒｖｉｃｅ）フィールド３１０の２ビット、ＥＣＮビット３００を利用し、輻輳に関係する損失の危険を信号通知する。本フィールドは、４つの符号点を有し、そのうちの２点はＥＣＮ能力を信号通知するために使用され、他の２点は輻輳を信号通知するために使用される。輻輳用の符号点は、例えば、ルータにおいて設定され、受信機が輻輳通知に遭遇した場合、その受信機は、送信機にこの情報のストリームを伝搬させ、その送信機は、次いで、その送信ビットレートを適応させることができる。ＴＣＰの場合、予め予約されているＴＣＰヘッダの２ビットを使用することによってこれを行う。この情報が受信される場合、これらのビットは、その送信ビットレートを引き下げるために、送信機を起動する。
【００１０】
ＵＤＰトラフィックは、信頼性のある伝送およびフロー制御のための同様の一般的なメカニズムを有していない。ＵＤＰトラフィックは、定義により配信が保証されないという意味で信頼性はない。これを許容するある特定の特徴をアプリケーションが有さない限り、損失ＵＤＰパケットは再送信されないことになる。ＵＤＰ自体は、何れにしろネットワークの輻輳に対応せず、また、伝送レートはＵＤＰ自体ではなく、アプリケーションによって判定される。
【００１１】
任意の伝送プロトコルとともにＩＰの使用に対してＥＣＮが定義される。ここで、ＴＣＰトラフィックの使用に関して、ＥＣＮの仕様書ＩＥＴＦ  ＲＦＣ３１６８では、ＵＤＰ用のＥＣＮの仕様を定めているに過ぎないが、ＵＤＰのＥＣＮを除外しているわけではない。ＵＤＰ自体は、輻輳通知メッセージの受信に基づいて、その伝送動作を変更するためのメカニズムを有していない。このメカニズムがなしでは、ＩＰヘッダにＥＣＮビットを設定する効果を予測できないので、ＵＤＰ用のＥＣＮは極めて信頼できなくなる。ＵＤＰ用のＥＣＮは、ＴＣＰ用のＥＣＮと同一の汎用メカニズム；受信する送信に関する受信機から送信機へのフィードバックを信号通知（シグナリング）するための高速バックチャネルおよび送信ビットレートを動的に変更するためのレート制御アルゴリズムを必要とする。
【００１２】
ＵＤＰに基づくリアルタイム通信サービスのような遅延に敏感な通信サービスもまたパケット損失に極めて敏感であるので、このようなサービスのための共有リソースによる伝送を管理し、輻輳を緩和するまたは回避することができ、および／または、例えば、その輻輳が止んだ後にトラフィックを増加させる場合、共有リソースの伝送容量を効率的な使用を行う必要がある。共有リソースによりサービスを提供するアプリケーションの送信ビットレートの制御によって、共有リソースによる伝送を管理することができる。しかしながら、アプリケーションの送信ビットレート制御は、伝送遅延に影響を与えることになる。送信ビットレートを引き下げる場合、比較的遅いペースで配信しても遅延に比較的敏感でないサービスは依然として動作するであろうが、送信ビットレートのドラスティックな引下を実行すれば遅延に敏感なサービスに対する結果は、サービスが動作するようには見ることができないということでありえよう。
【先行技術文献】
【非特許文献】
【００１３】
【非特許文献１】ＩＥＥＥ８０２．１１ａ／ｂ／ｇ、無線ローカル・エリア・ネットワーク
【非特許文献２】ＩＥＴＦ仕様書ＲＦＣ３１６８、ＩＰに対する明確な輻輳通知
【発明の概要】
【発明が解決しようとする課題】
【００１４】
本発明に従う少なくともいくつかの実施形態の目的は、共有リソースの伝送容量を使用する一方、また共有リソースを適切かつバランスのとれた方法で使用する、遅延に敏感なサービスに関する様々の必要性を受け入れるように機能することができるレート制御メカニズムを提供することである。
【課題を解決するための手段】
【００１５】
第１の態様に従えば、共有リソースを介して複数のセッションがセットアップされるパケット交換通信システムにおけるセッションのビットレートを制御する方法を提供することによって、目的が達成される。まず、セッションに対して有効なビットレート範囲が判定される。このビットレート範囲は、上限あるいは終端点および下限即あるいは終端点によって制限される、または制限することができる。セッションの現行ビットレートとビットレート範囲との比較によって、ビットレート範囲の選択される限界への距離、即ち、上限への距離または下限への距離が判定される。次に、現行ビットレートを、選択される限界への距離に応じて様々に適応させる。一実施形態では、距離が短い場合には比較的大きい量によって現行ビットレートを適応させることができ、また、距離が長い場合には比較的小さい量によって現行ビットレートを適応させることができる。例えば、選択される限界がビットレート範囲の上限である場合、選択される限界への距離が短い場合には比較的大きな引下または比較的小さな引上によって現行ビットレートが適応され、選択される限界への距離が長い場合には比較的小さな引下または比較的大きな引上によって現行ビットレートを適応させる。一方、選択される限界がビットレート範囲の下限である場合、選択される限界への距離が長い場合には比較的大きな引下または比較的小さな引上によって現行ビットレートが適応され、選択される限界への距離が短い場合には比較的小さな引下または比較的大きな引上によって現行ビットレートが適応される。
【００１６】
第２の態様に従えば、少なくとも第１のセッションおよび第２のセッションのビットレートを制御するためのパケット交換通信システムを提供することによって目的が達成される。このシステムは、第１のセッションにおいて共有リソースを介して第１の受信機と通信するために動作可能な少なくとも第１の送信機、および第２のセッションにおいて共有リソースを介して第２の受信機と通信するために動作可能な第２の送信機を備えている。さらに、本システムは、第１のセッションに有効な第１のビットレート範囲を判定するための第１のビットレート範囲判定手段、および第２のセッションに有効な第２のビットレート範囲を判定するための第２のビットレート範囲判定手段を備えている。第１のビットレート範囲および第２のビットレート範囲は、それぞれの上限あるいは終端点およびそれぞれの下限あるいは終端点によって制限される、または制限することができる。本システムは、また、第１のセッションの第１の現行ビットレートに関するレート適応量を制御し、第１のビットレート範囲に関して選択される限界への第１の距離、即ち、上限への第１の距離または下限への第１の距離に応じて、第１の現行ビットレートを様々に適応させる第１のレート適応制御ユニット、および前記第２のセッションの第２の現行ビットレートに関するレート適応量を制御し、第２のビットレート範囲に関して選択される限界へ第２の距離の、即ち、上限への第２の距離または下限への第２の距離に応じて、第２の現行ビットレートを様々に適応させる第２のレート適応制御ユニットをも備える。一実施形態では、それぞれの距離が短い場合には比較的大きい第１の量および第２の量によって第１の現行ビットレートおよび第２の現行ビットレートを適応させることができ、およびそれぞれの距離が長い場合には比較的小さい第１の量および第２の量によって第１の現行ビットレートおよび第２の現行ビットレートを適応させることができる。
【００１７】
第３の態様に従えば、共有リソースを介してセッションにおいて送信機が送信するパケット交換符号化メディアを受信するための受信機を提供することによって目的が達成される。受信機は、セッションに有効なビットレート範囲を判定するビットレート範囲判定手段を備えている。ビットレート範囲は、上限あるいは終端点および下限あるいは終端点によって制限される、または制限することができる。受信機は、ビットレートリクエスト推定手段およびレートリクエスト手段をさらに備える。現行受信ビットレートとビットレート範囲とを比較して、ビットレート範囲に関して選択される限界への距離、即ち、上限への距離または下限への距離を判定し、および距離に応じるビットレート適応量を様々に推定することによって、ビットレートリクエスト推定手段はビットレート適応量を推定するために動作する。一実施形態では、従って、推定ビットレート適応量は、距離が短い場合には比較的大きくなり、距離が長い場合には比較的小さくなる。レート適応リクエストメッセージの送信によって、レートリクエスト手段は、セッションにおける現行送信ビットレートに適応させるように送信機にリクエストするために動作する。さらなる実施形態では、共有リソースから輻輳通知メッセージを受信すると、レート適応リクエストメッセージを送信することができる。
【００１８】
第４の態様に従えば、共有リソースを介するセッションにおいてパケット交換符号化メディアを受信機に送信するための送信機を提供することによって目的が達成される。送信機は、セッションに有効なビットレート範囲を判定するビットレート範囲判定手段を備えている。ビットレート範囲は、上限あるいは終端点および下限あるいは終端点によって制限される、または制限することができる。送信機は、レートリクエスト受信手段およびレート適応制御ユニットをさらに備えている。レートリクエスト受信手段は、受信機からリクエストを受信し、セッションにおける現行送信ビットレートを適応させるために動作する。レート適応制御ユニットは、セッションにおける現行送信ビットレートの適応を制御し、ビットレート範囲に関して選択される限界への距離、即ち、上限への距離または下限への距離に応じて現行送信ビットレートを様々に適応させるために動作する。一実施形態では、距離が短い場合には比較的大きい量によって現行送信ビットレートを適応させることができ、距離が長い場合には比較的小さい量によって、現行送信ビットレートを適応させることができる。受信機からレート適応リクエストメッセージ形式のリクエストを受信すると、レート適応を行うことができる。
【００１９】
クライアントにおいて動作するアプリケーションのために共有リソースを介してセットアップされる各セッションのビットレートを制御して、遅延に敏感なサービスをユーザにこのように提供することによって、レート適応をアプリケーション間に分散させることができ、本方法、システムおよび送信機−受信機装置は、ユーザがレート適応に対する責任を分担する効果を有する。
【００２０】
さらに、各サービスに対して定義されるビットレート範囲内においてレート適応を実行することによって、本方法、システムおよび送信機−受信機装置は、サービス内容を維持することができ、一方で、それぞれのサービスレートを適応させることを可能にする効果を有する。
【００２１】
本発明の少なくともいくつかの実施形態の一利点は、輻輳がネットワークノードにおいて生じる場合、輻輳を緩和する動作を取らなかった新規ユーザと、従前の輻輳通知メッセージによりそのビットレートを既に引き下げているユーザとの間で伝送レートの適応責任をより公平に分担されることである。
【００２２】
別の利点は、クライアントへのレート適応機能の分散により、輻輳が生じているネットワークノードにおけるユーザ追跡およびサービス認識の必要性またはリクエストを排除することである。
【００２３】
添付する図面と共に以下の説明を参照することにより、本発明をそのさらなる目的および利点と共により容易に理解できよう。
【図面の簡単な説明】
【００２４】
【図１】輻輳になりうる共有リソースの例を示す図である。
【図２】輻輳になりうる共有リソースのさらなる例を示す図である。
【図３】ＩＥＴＦ仕様書ＲＦＣ３１６８に従うＥＣＮビットを有するＩＰヘッダの例図である。
【図４】本発明に従うレート適応メカニズムの実施形態の概要例図である。
【図５】本発明に従うシステムの実施形態の概要例図である。
【図６】本発明に従うビットレート範囲の指示の実施形態例図である。
【図７】本発明に従う受信機の実施形態の概要機能ブロック例図である。
【図８】は本発明に従う送信機の実施形態の概要機能ブロック例図である。
【図９】本発明に従う送信機の代替実施形態の概要機能ブロック例図である。
【図１０】本発明に従うレート制御アルゴリズムの実施形態のフローチャートである。
【図１１】本発明に従うレート制御アルゴリズムのビットレート推定部の実施形態のフローチャートである。
【図１２】本発明に従う２人のユーザ間のセッションフローの実施形態のフロー図である。
【図１３】本発明に従うビットレート適応加重の実施形態例図である。
【図１４】本発明に従うシステムの実施形態における共有リソースの負荷レベルの例図である。
【発明を実施するための形態】
【００２５】
ユーザアプリケーションの初期セッション設定ビットレートに対する関係を含むユーザアプリケーションの現行セッションビットレートをレート適応において考慮することによって、本発明に従う少なくともいくつかの実施形態は、特定ルーティング機能に関するレート適応のユーザ間におけるより公平な、即ち、均等な機能的な分配を提供する。輻輳通知メッセージに対する応答を案内するためのメカニズムを提供することで、同一ネットワーク優先クラスのユーザが同様の品質劣化を経験するようにする。これは、言うなれば、例えば、１００ｋｂｐｓでそのセッションを開始している新規ユーザには、いくつかの従前の輻輳通知メッセージを受信して、例えば、１００ｋｂｐｓから５０ｋｂｐｓへそのビットレートを既に引き下げているユーザとは異なる方法で、そのビットレートを引き下げることが要求されるであろうことである。
【００２６】
現代のメディアコーデックは、個別のビットレートのセット、いくつかの場合では、任意の所与のビットレートにも同調する可能性を有するので、サービスの意図を維持することができることを保証するために、サービスが機能しているか、または動作していると見なせる所定範囲のビットレートが必要であることを、発明者は認識しているが、サービスの意図を任意の所与のビットレートにおいて維持できるかは確かではない。例えば、リアルタイムビデオセッションは、１００ｋｂｐｓのオーダのビットレートを必要とする。このようなセッションで使用されるビデオコーデックはビットレートを１０ｋｂｐｓまで引き下げる可能性を有しているが、１０ｋｂｐｓではサービスは明らかに会話ビデオセッションにならない。このビットレートでは、サービスはゆっくりとしたスライドショーとして感じられるであろうし；サービスリクエストによって示されるリアルタイム会話サービスとならない。この場合では、サービスに有効なビットレートは、約４０乃至１００ｋｂｐｓの間であるといえよう。その他のメディアタイプの場合、有効なビットレート範囲は異なって見える可能性があるかもしれないが、基本とする原則は同一であり；サービスが有効であると判定することができるある区間または範囲のビットレートの必要性がある。
【００２７】
発明者がさらに認識していることは、アプリケーションがＩＰヘッダのＥＣＮビットの設定にどのように応答すべきかを指定することによって、受信機から送信機への高速バックチャネルおよび送信ビットレートを動的に変更する可能性を提供するＩＭＳマルチメディアテレフォニー（ＭＴＳＩ：ＩＭＳ  Ｍｕｌｔｉｍｅｄｉａ  Ｔｅｌｅｐｈｏｎｙ）のようなリアルタイム通信サービスに対して、ＵＤＰによるＥＣＮの信頼性のある使用が可能になることである。
【００２８】
図４はＵＤＰトラフィックでＥＣＮを使用するために必要とされるアプリケーションの動作を示している。本明細書では、ルータの形式の共有リソース４００により通信する送信クライアント４７０および受信クライアント４２０のプロトコルスタックが示されている。ＩＰに対するＥＣＮ方式に従い、共有リソース４００は、ＵＤＰパケットのＩＰヘッダにＥＣＮビット３００を設定する。また、このＵＤＰパケットは、接続４１０を介して受信クライアント４２０に転送される。輻輳通知メッセージ、即ち、ＥＣＮビットの設定がＩＰレイヤ４３０で検出されると、接続４５０Ｄｅ示されるように、輻輳通知メッセージは、受信クライアント４２０の受信機７００のアプリケーションレイヤ４４０に転送されなければならない。輻輳通知メッセージを受信すると、受信クライアント４２０の受信機７００は、その送信機にそのビットレートの引下を要求する、矢印４８０によって示されるリクエストを送信クライアント４７０の送信機８００に送信する必要がある。そのリクエストが送信機８００に到達すると、送信機は、矢印４９０によって示されるように受信機７００への送信ビットレートを直ちに引き下げるべきである。引下量は送信機８００によって判定することができるが、その場合、送信機８００はその決定の基礎をいくつかのパラメータに基づくことができる。
【００２９】
ＵＤＰベースのサービスに対し、発明者が提案することは、サービスが使用できるように見えなくなる下限を判定するパラメータを追加することによって、セッションに対して適切なビットレートのガイダンスを提供することができることである。これは、セッション設定手順において行うことができ、このセッション設定手順では、例えば、リアルタイムストリーミングプロトコル（ＲＴＳＰ：Ｒｅａｌ  Ｔｉｍｅ  Ｓｔｒｅａｍｉｎｇ  Ｐｒｏｔｏｃｏｌ）またはセッション開始プロトコル（ＳＩＰ：Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）を使用し、これらのプロトコルでは、埋込セッション記述プロトコル（ＳＤＰ：Ｓｅｓｓｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）が、既に、セッションビットレートの上限を指定するビットレートパラメータであるｂ−パラメータを搬送する。
【００３０】
発明者がさらに提案することは、輻輳通知メッセージの受信への送信機の応答は、拡張セッション設定手順に基づくことができることである。この手順は、輻輳通知メッセージに関する従前の動作を考慮するように輻輳通知メッセージへの送信機の応答を制御し、また一般的なサービス要件が送信機の動作の選択に影響を与えることを可能にするために使用することができる。
【００３１】
従って、本発明の実施形態に従えば、２つの特徴が、リアルタイム通信サービスに導入される：
１．セッションのビットレート範囲、即ち、サービスに有効であるレート範囲およびメディア送信機にセッション中に適応することを許容するレート範囲の信号通知（シグナリング）。
【００３２】
２．現行メディア送信ビットレート、あるいは、現行セッションビットレートと、セッションセットアップにおいて信号通知（シグナリング）されるビットレート範囲間の関係に基づき、その動作を変更する適応メカニズム。
【００３３】
この結果は、送信機が、現在送信するビットレートが何であり、およびセッションのビットレート範囲において送信機がどこに所在しているかに基づいて、輻輳通知メッセージに対し、送信機がその動作を判定するということになる：下限に近いほど、輻輳メッセージに対する応答は少なく、上限に近いほど、輻輳メッセージに対する応答はよりドラスティックである。このように、同一ネットワーク優先クラスにおいてより多くのリソースを消費するユーザは、セッション継続のためにその最低限界の近くで既に送信しているユーザよりより大きなビットレートの引下で応答することになるであろう。
【００３４】
図５は本発明の１つまたは複数の実施形態に従うシステムである。簡単のため、ＬＴＥ環境を説明のために選択するが、本発明はフロー制御を組み込んでいないプロトコルを経る通信サービスを採用する任意のパケット交換通信システムに等しく適用可能である。第１のクライアント５００を使用する第１のパーティ、ユーザＡは、第２のクライアント５３０を使用する第２のパーティ、ユーザＤと第１のセッションで通信している。第１のクライアント５００は、この例では、ファイアウォール５７０を通じて共有リソース５６０に接続されている。共有リソース５６０は、次いで、コアネットワーク５８０を介してｅＮＢ基地局５４０に接続され、ｅＮＢ基地局には第２のクライアント５３０が共有送信チャネル５５０を介して接続されている。同様に、第３のクライアント５２０を使用する第３のパーティ、ユーザＢは、第４のクライアント５１０を使用する第４のパーティ、ユーザＣと第２のセッションで通信している。第３のクライアント５２０はまた共有リソース５６０に接続され、第４のクライアント５１０はまた共有送信チャネル５５０を介してｅＮＢ基地局５４０に接続されている。クライアントは、例えば、移動端末、パーソナルコンピュータまたはサーバに常駐するバーチャルクライアントであり得る。
【００３５】
第１のクライアント５００および第２のクライアント５３０では、第１のアプリケーションが動作していて、関係するパーティであるユーザＡおよびユーザＤに第１のサービスを提供している。第３のクライアント５２０および第４のクライアント５１０では、第２のアプリケーションが動作していて、関係するパーティであるユーザＢおよびユーザＣに第２のサービスを提供している。図４に示されるように、通信方向に応じて、クライアントのそれぞれ１つにおいて動作しているアプリケーションは、送信機８００としてまたは受信７００として動作することができる。例えば、ユーザＡからユーザＤへの通信に対しては、第１のクライアント５００で動作している第１のアプリケーションは送信機８００として動作し、第２のクライアント５３０で動作している第１のアプリケーションは受信７００として動作するが、ユーザＤからユーザＡへの通信に対しては、第２のクライアント５３０で動作している第１のアプリケーションは送信機８００として動作し、第１のクライアント５００で動作している第１のアプリケーションは受信機７００として動作する。
【００３６】
第１のセッションおよび第１のアプリケーションに対して有効とされる第１のビットレート範囲が判定される、即ち、第１のセッション中に意図されるように機能するために、第１のアプリケーションによって提供されるサービスに対して必要とされる第１のビットレート範囲が判定され、また、第２のセッションおよび第２のアプリケーションに対して有効とされるための第２のビットレート範囲が判定される、即ち、第２のセッション中に意図されるように機能するために、第２のアプリケーションによって提供されるサービスに対して必要とされる第２のビットレート範囲が判定される。最大ビットレートを示す上限あるいは終端点、およびアプリケーションが使用可能なサービスを提供するために動作できる最小ビットレートを示す下限あるいは終端点によって、ビットレート範囲が指定される、または指定することができる。
【００３７】
このビット範囲区間またはビットレート範囲を指示する方法の１つが、図６に示される。この例では、セッションネゴ−シエィション手順において有効なビットレート範囲を伝達するために、ＳＤＰが使用される。これは、セッションビットレートに対する既存の上限ｂｍａｘに加えて、また、セッションビットレートの下限ｂｍｉｎを導入することによって実行される。この例では、ＳＤＰ  ａｎｓｅｒ（アンサー）６１０のｂｍａｘによって示される、受信機の最大ビットレートより速いＳＤＰ  ｏｆｆｅｒ（オファー）６００のｂｍａｘによって指される最大ビットレートを、提供者、即ち、送信機がサポートするが、両者は、ＳＤＰ  ｏｆｆｅｒ（オファー）６００およびＳＤＰ  ａｎｓｅｒ（アンサー）６１０のｂｍｉｎによって示される４８ｋｂｐｓを、このセッションにおけるビデオに対する下限として特定することを示している。このセッションは、ビデオに対する６０ｋｂｐｓの最大ビットレートあるいは上限、および４８ｋｂｐｓの最小ビットレートあるいは下限で動作するであろう。
【００３８】
その他の手段を、ビットレート範囲の情報を伝達するために使用することもできる。１つの可能な代替手段は、アプリケーションの設定において指定されるビットレート範囲、またはアプリケーションにおいてハード符号化されるビットレート範囲を有することができる。
【００３９】
サービス品質（ＱｏＳ：ｑｕａｌｉｔｙ  ｏｆ  ｓｅｒｖｉｃｅ）メカニズムがトラフィックに対して利用可能な環境では、ビットレート範囲の下限および上限は特定ＱｏＳの保証に関係し得る。特定ＱｏＳ方式は、ネットワークへの入場に影響を与え、また、おそらくはセッション中のネットワークリソース予約にも影響を与える。３ＧＰＰネットワークでは、下限および上限はそれぞれＱｏＳ属性保証ビットレート（ＱＢＲ：ｇｕａｒａｎｔｅｅｄ  ｂｉｔ−ｒａｔｅ）および最大ビットレート（ＭＢＲ：ｍａｘｉｍｕｍ  ｂｉｔ−ｒａｔｅ）に関係し得る。しかしながら、これは必要とされるものではなく、また、下限がＧＢＲより低いことがあり得る場合が存在する可能性もある。
【００４０】
図７及び図８に示されるように、これらの図では、アプリケーションの受信機７００および送信機８００の部分が示され、第１のアプリケーションは少なくとも１つの第１のメディアエンコーダ８３０および／または少なくとも１つの第１のメディアデコーダ７３０を含んでいる。同様に、第２のアプリケーションは、少なくとも１つの第２のメディアエンコーダ８３０および／または少なくとも１つの第２のメディアデコーダ７３０を含んでいる。サーバに常駐するアプリケーションは、メディアエンコーダを有していても良いが、このようなアプリケーションのメディアデコーダは、典型的には、送信機として動作しない。
【００４１】
第１のアプリケーションは、更に、第１のレート適応制御ユニット８７０を含み、これは、少なくとも１つの第１のメディアエンコーダ８３０に接続され、また、少なくとも１つの第１のメディアエンコーダ８３０のレート、例えば、ビットレートを制御するように動作する。同様に、第２のアプリケーションは、更に、第２のレート適応制御ユニット８７０を含み、これは、少なくとも１つの第２のメディアエンコーダ８３０に接続され、また、少なくとも１つの第２のメディアエンコーダ８３０のレート、例えば、ビットレートを制御するように動作する。これによって、第１のレート適応制御ユニット８７０は、更に、第１のセッションのレート、例えば、ビットレートを制御するように動作し、また、第２のレート適応制御ユニット８７０は、第２のセッションのレート、例えば、ビットレートを制御するように動作する。これは、パケットのメディアフローが、少なくとも１つのメディアエンコーダ８３０から出力されるレートによって、セッションのレート、即ち、ビットレートが判定されるからである。
【００４２】
第１のレート適応制御ユニット８７０は、第１のセッションにおいてまたは少なくとも１つの第１のメディアエンコーダ８３０によって、現在使用される第１の現行ビットレートを、第１のビットレート範囲と比較して、第１のビットレート範囲の限界あるいは終端点への第１の距離、即ち、第１のビットレート範囲の上限へのまたは下限への第１の距離を判定するように構成され、また、第２のレート適応制御ユニット８７０は、第２のセッションにおいてまたは少なくとも１つの第２のメディアエンコーダ８３０によって、現在使用される第２の現行ビットレートを第２のビットレート範囲と比較して、第２のビットレート範囲の限界あるいは終端点への第２の距離、即ち、第２のビットレート範囲の上限へのまたは下限への第２の距離を判定するように構成されている。第１のおよび第２のレート適応制御ユニット８７０は、第１の現行ビットレートおよび第２の現行ビットレートを第１の距離および第２の距離に応じて異ならせて適応させるように、即ち、それぞれの距離の長さに依存する量によってそれぞれのビットレートを適応させるように構成されている。共有リソース５６０および／または共有送信チャネル５５０の輻輳を緩和または削減するために、レート適応が実行されても良い。
【００４３】
第１のおよび第２のレート適応制御ユニット８７０は、レート適応制御を実行し、また、それぞれ少なくとも１つの第１のおよび少なくとも１つの第２のメディアエンコーダ８３０にレート制御コマンド８８０を発行するために、レート適応リクエストメッセージ４８０によって起動される、あるいは起動されても良い。例えば、受信機７００によって、即ち、それぞれ少なくとも１つの第１のおよび少なくとも１つの第２のメディアエンコーダ８３０によって符号化されているメディアを受信するアプリケーションによって、レート適応リクエストメッセージは送信されても良い。それぞれのセッションにおける伝送に対して使用するために、例えば、現行ビットレートに対する相対変化または差分として表現されるまたは新規のビットレートまたは適応されたビットレートとして表現される、リクエストされたまたは提案されたレートあるいはビットレート適応を、レート適応リクエストメッセージ４８０がさらに指定することもできる。ビットレート適応量は、受信機７００によって推定することで、現行受信ビットレートがそれぞれのセッションに対して有効なビットレート範囲の下限に比較的近い場合より、現行受信ビットレートがビットレート範囲の上限に比較的近い場合には、現行受信ビットレートが比較的多く引き下げられることになる。
【００４４】
レート制御メカニズムは、メディアタイプに対する有効ビットレート範囲の知識並びに送信ビットレートの現行値の知識を利用する。このメカニズムを、図４および図７乃至図９を参照してより詳細に説明する。図７および図８は、レート制御メカニズムが実装されるアプリケーションの送信機−受信機の対のいくつかの部分を示している。レート適応制御ユニット８７０およびレート適応制御ユニット９７０、ビットレートリクエスト推定手段７７０、レートリクエスト手段７９０、レートリクエスト受信手段８５０、検出手段７５０、ビットレート範囲判定手段７２０およびビットレート範囲判定手段８２０、ビットレート判定手段７４０およびビットレート範囲判定手段８４０、パケット損失率（ＰＬＲ：Ｐａｃｋｅｔ  Ｌｏｓｓ  Ｒａｔｅ）判定手段９０５、ジッタ判定手段９１５、アプリケーション設定判定手段９２０およびネットワークフィードバック（ＮＦ：Ｎｅｔｗｏｒｋ  Ｆｅｅｄｂａｃｋ）判定手段９４０のようなこれらの部分の少なくともいくつかは、例えば、情報を読み出すことができるメモリ群および／または情報の処理を実行し、レート適応において使用することができる結果を生成するプロセッサの形式で実装することができる。
【００４５】
図７は、セッションにおいて共有リソース４００を介して送信機８００によって送信されるパケット交換符号化メディア７１０を受信することによってサービスを提供するように構成されている受信機７００のブロック概要図を示している。受信機７００はビットレート範囲判定手段７２０を含んでいて、これは、サービスが意図するように動作しようとするために、例えば、サービスが十分なメディア品質を提供することにおいて、符号化メディアの送信に適用されるビットレートが収まらなければならない、有効セッションビットレート範囲を判定するためのものである。有効セッションビットレート範囲は、上限あるいは終端点および下限あるいは終端点によって指定することができる。さらに、受信機７００は、符号化メディアを現行受信ビットレートで復号化して、復号化メディア７４５、例えば、オーディオまたはビデオを出力するための少なくとも１つのメディアデコーダ７３０と、共有リソースから輻輳通知メッセージを検出するための検出手段７５０と、及び現行受信ビットレートを判定するためのビットレート判定手段７４０を含んでいる。例えば、ＩＰフローを監視し、現行受信ビットレートの平均値を推定することによって、破線矢印７５５で示されるようにメディアデコーダ７３０に入力される符号化メディアのＩＰフロー７１０から、現行受信ビットレートを判定することができる。受信機７００が存在しているクライアントで利用可能なその他の手段から現行受信ビットレートを判定することもできる。有効セッションビットレート範囲、現行受信ビットレートおよび輻輳通知メッセージに関する情報は、ビットレートリクエスト推定手段７７０への入力７６０に供給される。このビットレートリクエスト推定手段７７０は、現行受信ビットレートを有効セッションビットレート範囲と比較して、有効セッションビットレート範囲の限界への距離、即ち、上限へのまたは下限への距離を判定することによって、ビットレート適応量を推定し、また、距離に応じて様々なビットレート適応量を推定する。ビットレート適応量は距離に依存するので、ビットレート適応量は距離が短ければ比較的大きく、距離長ければ比較的小さくなる。ビットレート適応量の推定は、輻輳通知メッセージに応じて行うことができるが、その他のメッセージまたは状態により起動することもできる。相対変化または現行受信ビットレートに対する差分として、またはリクエスト送信ビットレートとして表現することができる推定ビットレート適応量は、次に、レートリクエスト手段７９０への回線７８０に出力される。第１の実施形態で、レート適応リクエスト４８０を送信機８００に送信することによって、送信レートリクエスト手段７９０は、次に、符号化メディアのその現行送信ビットレートを適応させることを送信機８００にリクエストする。レート適応リクエスト４８０は、符号化メディア４９０、８１０の新規送信ビットレート、即ち、適応化ビットレートを判定するために送信機８００によって入力として使用される推定ビットレート適応量を含むことができる。
【００４６】
しかしながら、第２の実施形態では、レート適応リクエスト４８０に含まれる推定ビットレート適応量によって指定される、現行送信ビットレートを調整するための指令または命令として、レート適応リクエスト４８０は、送信機８００によって解釈されても良い。
【００４７】
さらに別の、第３の実施形態では、受信機７００によって送信されるレート適応リクエスト４８０は、推定ビットレート適応量を含んでいない。この第３の実施形態は、送信機８００がビットレート適応量を推定するためのビットレート推定手段を含むことを必要とする。また、受信機７００がビットレート推定手段７７０を含み、ビットレート適応量を推定することは第３の実施形態では可能であるが、必須ではない。
【００４８】
図８は、セッションにおいて共有リソース４００を介して受信機７００にパケット交換符号化メディア８１０を送信することによって、サービスを提供するように構成されている送信機８００のブロック図を示している。送信機８００は、サービスが意図するように動作しようとするために、例えば、サービスが十分なメディア品質を提供することにおいて、符号化メディア８１０の送信に対して適用されるビットレートに収まらなければならない、有効セッションビットレート範囲を判定するためのビットレート範囲判定手段８２０、およびメディアエンコーダに入力されるメディア８３５、例えば、キャプチャされるオーディオまたはビデオを受信し、そのメディアを現行送信ビットレートで符号化するための少なくとも１つのメディアエンコーダ８３０を含んでいる。さらに、送信機８００は、受信機７００から、符号化メディアの現行送信ビットレートを適応させるためのリクエストを受信するレートリクエスト受信手段８５０、および現行送信ビットレートを判定するためのビットレート判定手段８４０を含んでいる。現行送信ビットレートは、メディアエンコーダ８３０における設定から、または破線矢印８５５によって示されるように、メディアエンコーダ８３０から出力される符号化メディア８１０のＩＰフローから判定することができるが、送信機８００が存在するクライアントで利用可能なその他の手段からも判定することができる。有効セッションビットレート範囲、現行送信ビットレートおよび受信機からのリクエスト４８０に関する情報は、レート適応制御ユニット８７０への入力８６０に提供される。リクエスト４８０は、受信機７００によって作成される推定ビットレート適応量をさらに含むことができ、推定ビットレート適応量は、符号化メディア８１０の新規送信ビットレート、即ち、適応化ビットレートを判定するために送信機８００による入力として使用される。レート適応制御ユニット８７０は、入力８６０に提供される情報に基づき作成されるレート適応量を判定し、有効セッションビットレート範囲内の適応化ビットレートに現行送信ビットレートを変更することを、メディアエンコーダ８３０に指令するレート制御コマンドを出力８８０に出力する。メディアエンコーダ８３０は、次に、その送信あるいは符号化メディア８１０の出力を、現行送信ビットレートから適応化ビットレートに変更する。レート適応制御ユニット８７０は、作成すべきレート適応量を判定し、および／または受信機７００からのリクエスト４８０に応じてレート制御コマンドをメディアエンコーダに出力することができるが、レート制御コマンドの出力は、その他のメッセージまたは状態によって起動することもできる。
【００４９】
再度、本発明の第３の実施形態を参照すると、受信機７００によって送信されるレート適応リクエスト４８０にこのような情報は含まれないので、この実施形態では、ビットレート適応量を推定するために送信機８００に、ビットレート推定手段７７０が必要とされる。ビットレート推定手段は、この場合、好ましくは、送信機８００のレート適応制御ユニット８７０に含めることができる。
【００５０】
現行の最適送信ビットレート、即ち、適応化ビットレートを判定する場合、メディアコーデック、即ち、メディアエンコーダ−デコーダ対に対するレート適応メカニズムは、いくつかの異なる測定結果レポートまたはセッション情報パラメータを考慮することができる。この構成は、本発明の第４の実施形態に従う送信機９００を示す図９で示される。この実施形態における送信機９００の全体的機能は、図８を参照して説明される第１の実施形態における送信機８００の全体的機能と同一である。説明が図８の説明と同一である構成要素については、参照番号は図８の参照番号と同一であり、また、説明を本明細書では繰り返さない。この第４の実施形態における相違は、作成すべきレート適応量を判定する場合に、パケット損失レート（ＰＬＲ）判定手段９０５によって判定されるパケット損失レート（ＰＬＲ）、ジッタ判定手段９１５によって判定されるジッタ、ネットワークフィードバック（ＮＦ）判定手段９４０によって判定されるネットワークフィードバック（ＮＦ）メッセージ、およびアプリケーション設定判定手段９２０によって判定されるアプリケーション設定のような、様々な情報タイプまたはパラメータを、レート適応制御ユニット９７０が考慮することができることである。ネットワークフィードバック情報は、サービス品質パラメータにおける変化を考慮することができ、アプリケーション設定情報は移動能力に依存するサービスプリファレンスであっても良い。パケット損失率（ＰＬＲ）、ジッタ、ネットワークフィードバックメッセージおよびアプリケーション設定に関する情報は、様々な測定結果レポートまたはセッション情報パラメータにより判定されるまたは利用可能にすることができ、また、ビットレート範囲の判定手段８２０によって判定される有効セッションビットレート範囲、ビットレート判定手段８４０によって判定される現行送信ビットレート、およびレートリクエスト受信手段８５０によって受信機７００から受信するリクエストであって、推定ビットレート適応量をさらに含むことができるリクエストと共に、上述の情報が、レート適応制御ユニット９７０への入力８６０に提供される。レート適応制御ユニット９７０は、次に、作成すべきレート適応量を判定するために、様々な異なる情報タイプまたはパラメータ、および受信機７００からの推定ビットレート適応量を考慮する。このように、より多くの情報を考慮することの結果として、送信機９００によって設定される適応化ビットレートに対する受信機７００によって推定されるビットレート適応量の影響は、比較的小さくなることが予測できる。
【００５１】
再度、第２の実施形態を参照すると、レート適応リクエストに含まれる推定ビットレート適応量によって指定される現行送信ビットレートを調整するための指令または命令として、この実施形態では、レート適応リクエストを送信機によって解釈することができる。この実施形態の変形では、作成すべき推定レート適応量を判定する場合に、パケット損失率（ＰＬＲ）、ジッタ、ネットワーク・フィードバック・メッセージおよびアプリケーション設定のような、様々な情報タイプまたはパラメータを考慮するために、ビットレートリクエスト推定手段７７０を一般化することができる。
【００５２】
まとめると、レート適応制御メカニズムに関する４つの実施形態では、以下の点について検討している：
１．第１の実施形態：受信機７００は、現行受信ビットレート７４０および有効セッションビットレート範囲７２０に基づいて、ビットレート適応量を推定し、そして、その推定ビットレート適応量を含めることができるレート適応リクエスト４８０を送信機８００に送信する。送信機は、受信機への送信のための新規の適応化ビットレートを判定する。受信機からのレート適応リクエストに推定ビットレート適応量が含められる場合のバージョンに対しては、送信機は、受信機によってリクエストされるビットレート適応量に従うかどうかを選択することができる。
【００５３】
２．第２の実施形態：受信機７００は、少なくとも現行受信ビットレート７４０および有効セッションビットレート範囲７２０に基づいて、ビットレート適応量を推定し、そして、実行すべきビットレート適応量を判定する。行うべき推定レート適応を判定する場合、様々な情報タイプまたはパラメータを考慮するために、受信機を一般化することができる。受信機は、ビットレート適応量を指定するレート適応リクエスト４８０を送信機８００に送信する。送信機は、受信機によって指令されるビットレート適応を実行する。
【００５４】
３．第３の実施形態：受信機７００は、レート適応リクエスト４８０を送信機８００に送信する。送信機は、現行送信ビットレート８４０および有効セッションビットレート範囲８２０に基づいて、ビットレート適応量を推定し、そして、受信機７００への送信のための新規の適応化ビットレートを判定する。受信機は、おそらく、送信機に入力を与える以外の目的のために、ビットレート適応量を推定している場合もあるが、ビットレート適応量は、送信機へのレート適応リクエストには含まれない。
【００５５】
４．第４の実施形態：受信機７００は、現行受信ビットレート７４０および有効セッションビットレート範囲７２０に基づいて受信機７００によって実行される推定ビットレート適応に基づいて示唆される推定ビットレート適応量を含むことができるレート適応リクエスト４８０を送信機９００に送信する。送信機は、様々な測定結果レポートまたはセッション情報パラメータにより判定されるまたは利用可能にする、様々な情報タイプまたはパラメータに加えて、現行送信ビットレート８４０および有効セッションビットレート範囲８２０に基づいて、ビットレート適応量を推定する。示唆される推定ビットレート適応量がレート適応リクエスト４８０に含められる場合、実行すべきビットレート適応量を判定する場合に、示唆される推定ビットレート適応量を入力として使用するか、または示唆される推定ビットレート適応量を、情報の一部、例えば、送信機９００によって考慮される現行送信ビットレート８４０および有効なセッションのビットレート範囲８２０に置換することができる。
【００５６】
図１０は、受信機としておよび送信機として動作することができるアプリケーションを有する例示クライアントにおいて動作するレート制御アルゴリズムの一例のフローチャートを示している。この処理は、ステップ１０００のセッションのセットアップにおいて開始する。まず、ステップ１０１０において、最大セッションビットレートｂｍａｘおよび最小セッションビットレートｂｍｉｎを判定するために、セッション帯域幅パラメータがネゴシエートされる。次いで、ステップ１０２０において、現行送信ビットレートｂｃｕｒｒが、ｂｍａｘに設定されるまたはｂｍａｘより小さな値に設定される。その後、ステップ１０３０において、現行受信ビットレートｂｒｅｃｖが、ｂｍａｘに設定されるまたはｂｍａｘより小さな値に設定される。データ、例えば、符号化メディアが、この場合、ステップ１０４０において、現行送信ビットレートｂｃｕｒｒで送信される。ステップ１０５０で、アルゴリズムは、輻輳通知メッセージの受信をチェックする。このようなメッセージを受信していない場合、アルゴリズムは、ステップ１０９０に進む。しかしながら、輻輳通知メッセージを受信していると判定される場合、ビットレートリクエスト値、即ち、ビットレート適応値が、ステップ１０６０で推定される。次いで、ステップ１０７０で、レートリクエスト、即ち、レート適応リクエストが、別のクライアントの送信機に送信される。レート適応リクエストは、ビットレート適応値を指定するまたは示唆することができる。この例では、ビットレート適応値は、送信ビットレートリクエストｂｒｅｑｓｅｎｄとして表わされる。次いで、ステップ１０８０で、別のクライアントの送信機が送信ビットレートを適応させていることを、例えば、受信ビットレートを分析することによって確認される場合、現行受信ビットレートｂｒｅｃｖがｂｒｅｑｓｅｎｄに設定される。この例では、別のクライアントの送信機は、例示クライアントの受信機によるリクエストに従って送信ビットレートを適応させる。処理は、次いで、ステップ１０９０に進み、ここでは、アルゴリズムが、レートリクエスト、即ち、レート適応リクエストを、別のクライアントの受信機から受信しているかをチェックする。そのようなリクエストを受信していない場合、処理は、ステップ１０９８に進む。しかしながら、レートリクエスト、即ち、レート適応リクエストを受信していると判定される場合、ステップ１０９４で、この例では、別のクライアントの受信機からのレートリクエストにおいて受信している受信ビットレートリクエストｂｒｅｑｒｅｃｖに、現行送信ビットレートｂｃｕｒｒが設定されるまたは適応させる。処理は、次いでステップ１０９８で、継続し、そこで、セッションを終了するかに関してチェックを行う。終了でない場合、処理は、ステップ１０４０において、現行送信ビットレートｂｃｕｒｒでデータの送信を継続する。一方、セッションを終了する場合、処理は、ステップ１０９９で停止する。
【００５７】
図１１は、図１０に示される処理のステップ１０６０で行うビットレート推定部のフローチャートをより詳細に示している。処理は、ステップ１１００で開始する。ステップ１１１０で、ＥＣＮメッセージとも呼ばれる輻輳通知メッセージが、例えば、共有リソースから受信される。このメッセージは、送信パケットのＩＰヘッダにＥＣＮビットを設定することによって伝達される。次いで、ステップ１１２０で、現行受信ビットレートｂｒｅｃｖが、セッション上限あるいは最大セッションビットレートｂｍａｘ、およびセッション下限あるいは最小セッションビットレートｂｍｉｎと比較される。次いで、ステップ１１３０で、現行受信ビットレートｂｒｅｃｖがセッション下限あるいは最小セッションビットレートｂｍｉｎより速いと判定される場合、ステップ１１４０で、新規リクエスト受信ビットレート、即ち、送信ビットレートリクエストｂｒｅｑｓｅｎｄとして表わされるビットレート適応値が計算される。処理は、次いで、ステップ１１５０で停止する。一方、ステップ１１３０で、現行受信ビットレートｂｒｅｃｖが既にセッション下限あるいは最小セッションビットレートｂｍｉｎにあると判定される場合、処理はステップ１１５０で停止し、さらなるレート適応を実行されない。
【００５８】
図１２は共有リソース１２２０であるＥＣＮの可能なネットワークノードを介して通信するユーザＡ１２００およびユーザＢ１２１０のセッションフロー図を示している。最初のステップ１２２５で、セッション上限あるいは最大セッションビットレートｂｍａｘキロビット／毎秒（ｋｂｐｓ：ｋｉｌｏｂｉｔｓ  ｐｅｒ  ｓｅｃｏｎｄ）およびセッション下限あるいは最小セッションビットレートｂｍｉｎ  ｋｂｐｓによって指定されるセッションビットレート範囲を判定するために、例えば、ＳＩＰ／ＳＤＰによりセッションネゴシエーション手順において、ユーザＡとユーザＢ間で信号メッセージが交換される。次いで、ステップ１２３０で、両方向、即ち、ユーザＡからユーザＢへおよびユーザＢからユーザＡへの送信に対する最大セッションビットレートｂｍａｘに設定される現行送信ビットレートｂｃｕｒｒを使用して、全二重メディアフローが交換される。次のステップ１２４０で、送信パケットのＩＰヘッダに、ＥＣＮビットを設定することによって、共有リソース１２２０は、ＥＣＮメッセージをユーザＢ１２１０に送信する。ステップ１２５０で、ユーザＢに対する送信用の送信ビットレートを下げるために、リクエスト、即ち、レート適応リクエストをユーザＡに送信することによって、ユーザＢは、ＥＣＮメッセージに応答する。ユーザＡからユーザＢへの送信に対する送信ビットレートを適応させることによって、ステップ１２６０で、ユーザＢからユーザＡへの最大セッションビットレートｂｍａｘ内の現行送信ビットレートｂｃｕｒｒで、およびユーザＡからユーザＢへのセッション下限あるいは最小セッションビットレートｂｍｉｎとセッション上限あるいは最大セッションビットレートｂｍａｘとの間にある現行送信ビットレートｂｃｕｒｒで、全二重メディアフローがユーザＡとユーザＢ間で交換することにより、ユーザＡはこの場合応答する。次のステップ１２７０で、送信パケットのＩＰヘッダにＥＣＮビットを設定することによって、共有リソース１２２０は、ＥＣＮメッセージをユーザＡ１２００に送信する。ステップ１２８０で、ユーザＡへの送信に対する、ユーザＢの送信ビットレートを下げるリクエスト、即ち、レート適応リクエストをユーザＢに送信することによって、ユーザＡはＥＣＮメッセージに応答する。ユーザＢは、次いで、ユーザＢからユーザＡへの送信に対する送信ビットレートを適応させることによって応答し、そうすることで、ステップ１２９０で、両方向、即ち、ユーザＡからユーザＢへおよびユーザＢからユーザＡへの送信に対する、セッション下限あるいは最小セッションビットレートｂｍｉｎとセッション上限あるいは最大セッションビットレートｂｍａｘとの間にある現行送信ビットレートｂｃｕｒｒを使用して、全二重メディアフローが交換される。最後に、ステップ１２９５で、例えば、ＳＩＰプロトコルを使用して、セッションを終了するために、信号メッセージがユーザＡとユーザＢ間で交換される。この例で、ユーザＡおよびユーザＢは、そのそれぞれのユーザ機器に同一のレート適応アルゴリズムを有し、このことは、ＡからＢへの方向で輻輳が生じる場合に、ビットレート適応量がＢからＡへの方向で輻輳が生じる場合と同じであることであることを意味する。ユーザＡのＵＥにおけるアプリケーション設定またはＵＥの能力が、ユーザＢのＵＥにおけるアプリケーション設定またはＵＥの能力と異なる場合、これは必要とされない。
【００５９】
メディアエンコーダのビットレートを制御するために並びにセッションレベルのメディアフローのビットレートを制御するために、レート制御メカニズムを適用することができる。２つ以上のメディアタイプ、例えば、オーディオおよびビデオを使用するいくつかのアプリケーションでは、異なるメディアタイプのメディアフローが、セッションにおいて送信機から受信機へ送信される、１つのセッション・メディア・フローまたはＩＰ伝送フローに多重化または結合することができる。このようなアプリケーションでは、それぞれ異なるタイプのメディアエンコーダから出力される符号化メディアフローを入力として受信する、例えば、マルチプレクサから、またはマルチプレクサを介して送信するために出力されるセッション・メディア・フローのビットレートを制御するように、レート適応制御ユニットを。セッションレベルに適用するように構成することができる。同様に、構成上、異なるメディアタイプのメディアフローを含むセッション・メディア用のビットレート適応量を推定するように、ビットレート推定手段を構成することができる。
【００６０】
以下の例は、それぞれが２つの異なるメディアタイプのメディアを使用する少なくとも２つのアプリケーションに対する、セッションレベルにおけるメディアフローのビットレートの制御を示している。しかしながら、本方法および本装置は、３つ以上の異なるメディアタイプのメディアを使用するアプリケーションにも適応する。この例では、アプリケーションを動作させる複数のパーティに対する複数のセッションが共有リソースを介してセットアップすることができる、パケット交換通信システムにおける通信のために、第１のアプリケーションに対する少なくとも第１のセッションおよび第２のアプリケーションに対する第２のセッションをセットアップしている。第１のメディアエンコーダからの第１のメディアタイプ、例えば、オーディオの第１の符号化メディアフロー、および第２のメディアエンコーダからの第２のメディアタイプ、例えば、ビデオの第２の符号化メディアフローが、第１のセッションにおいて第１の送信機から第１の受信機に送信される１つの第１のセッション・メディア・フローに第１のマルチプレクサによって多重化される。さらに、第３のメディアエンコーダからの第３のメディアタイプ、例えば、音声の第３の符号化メディアフローおよび第４のメディアエンコーダからの第４のメディアタイプ、例えば、データの第４の符号化メディアフローが、第２のセッションにおいて第２の送信機から第２の受信機に送信される１つの第２のセッション・メディア・フローに第２のマルチプレクサによって多重化される。第１のメディアエンコーダおよび第２のメディアエンコーダ並びに第１のマルチプレクサは第１のアプリケーションに含まれる、または含まれることができ、第３のメディアエンコーダおよび第４のメディアエンコーダ並びに第２のマルチプレクサは第２のアプリケーションに含まれる、または含まれることができる。第１のアプリケーションは、更に、第１のレート適応制御ユニットを含んでいて、これは、第１のメディアエンコーダおよび第２のメディアエンコーダに並びに第１のマルチプレクサに接続され、また、第１のセッション・メディア・フローのレート、例えば、ビットレートの制御を行う。同様に、第２のアプリケーションは、更に、第２のレート適応制御ユニットを含み、これは、第３のメディアエンコーダおよび第４のメディアエンコーダに接続され、また、第２のセッション・メディア・フローのレート、例えば、ビットレートの制御を行う。
【００６１】
第１のビットレート範囲は第１のセッションに対して有効となるように判定され、第２のビットレート範囲は第２のセッションに有効となるように判定される。第１のビットレート範囲の限界あるいは終端点、即ち、第１のビットレート範囲の上限へまたは下限への第１の距離を判定するために、第１のレート適応制御ユニットは、第１のセッションで現在使用されている第１の現行ビットレートを第１のビットレート範囲と比較するように構成され、また、第２のビットレート範囲の限界あるいは終端点、即ち、第２のビットレート範囲の上限へまたは下限への第２の距離を判定するために、第２のレート適応制御ユニットは、第２のセッションで現在使用されている第２の現行ビットレートを第２のビットレート範囲と比較するように構成されている。第１の距離および第２の距離に応じて異なる第１の現行ビットレートおよび第２の現行ビットレートを適応させるように、即ち、それぞれの距離の長さに応じる量によってそれぞれのビットレートを適応させるように、第１のレート適応制御ユニットおよび第２のレート適応制御ユニットが構成される。
【００６２】
上述のように、輻輳通知メッセージを受信する場合に取る処置は、輻輳通知メッセージの現行送信ビットレートとの関係付けに基づいている。輻輳通知の重み付け、即ち、輻輳通知に対する応答として送信機から必要とされるビットレート適応量は、現行ビットレートとセッションに対して有効なビットレート範囲間の関係を調査することによって行われる。図１３は、現行ビットレートとセッションビットレート範囲に基づいて、ＥＣＮによって起動される適応動作の重み付けの例を示している。この例では、現行受信ビットレートがｂｍａｘに等しい場合、重み付けは４０％のビットレートの引下をもたらすであろうし、現行受信ビットレートをｂｍｉｎに引き下げる場合、もたらす引下は零であろう。
【００６３】
ビットレート引下の推定は、いくつかの異なる方法で行うことができる。ビットレート範囲の実値（即ち、幅）に応じて、異なる重み付けが適するであろう。指数重み付け公式の例を、指数重み付け式を示す式１で示される。
【００６４】
【数１】
2010533419.tif 000003
【００６５】
現行受信ビットレートがｂｍａｘに等しい場合、この重み付けは５０％のビットレートの引下をもたらすであろうし、セッションが既にｂｍｉｎにある場合、もたらす引下は零であろう。
【００６６】
図１４は、図５に示されるシステムのようなＬＴＥ配備における、ＥＣＮビットを設定することができる、共有リソースのような、即ち、共有伝送チャネルを提供する拡張ノードＢ（ｅＮＢ）の負荷レベルを示している。この例では、ｂｃｕｒｒ＝ｂｍａｘで動作する場合、重み付け方式は５０％の引下をもたらし、ｂｃｕｒｒ＝０．５＊ｂｍａｘでの動作が使用される場合は１０％の引下をもたらす。以下の表に示されるイベントが発生する。
【００６７】
【表１】
2010533419.tif 000004
【００６８】
適応動作を判定する場合に現行ビットレートを考慮することによって、クライアントの現行ビットレートがセッションビットレート範囲の上限に近い場合、クライアントはネットワークの輻輳状態を緩和するための比較的大きな責任を担うことになる。このように、ネットワークの輻輳を緩和するための比較的大きな責任を既に担っているクライアンに負担を負わせることなく、クライアントは、公平にクライアント自体間で適応動作を分散させることになる。さらに、輻輳に遭遇しているネットワークノード、例えば、ｅＮＢあるいはルータにおけるユーザ追跡およびサービス認識の要件を除去することは、クライアントに機能を分散する利益をも有する。この方式は、様々な加入者プロパティ、例えば、「エコノミー加入者」および「ゴールド加入者」に対処するために拡張することができる。例えば、「エコノミー加入者」、例えば、サービスに対する支払が比較的少ない加入者からよりも、「ゴールド加入者」、例えば、サービスに対する支払が比較的多い加入者から、より少ないビットレート適応量を要求するために拡張することができる。また、より絶対的な重み付け、即ち、絶対ビットレート量で表されるビットレート適応量にも対処することができ、またはセッションのビットレート範囲に対する相対値のみならず現行ビットレートの絶対値に基づき、現行ビットレートが特定ビットレート値を上回る場合の特定ビットレート値に対するビットレート適応量で表わされるビットレート適応量にも対処することができる。絶対的な重み付けおよび相対的重み付けの組み合わせもまた考えられ、例えば、現行ビットレートが特定ビットレート値を上回る場合、絶対ビットレート値に常に引き下げ、次いで、現行ビットレートをビットレート範囲の限界に関係づける量だけ引き下げる。
【００６９】
本発明の少なくともいくつかの実施形態の１つの利点は、実施形態が輻輳に遭遇しているネットワークノードにおいて輻輳を緩和するために、クライアント間の不公平な責任の問題を解決することである。この機能がなければ、ネットワークの輻輳に既に適応しているユーザ並びに帯域幅の消費を削減していない新規ユーザが共に等しくその送信ビットレートを引き下げることが要求されることになる。輻輳緩和動作を取っていない新規に確立されるセッションの場合では、従前の輻輳通知メッセージにより、そのビットレートを既に引き下げているクライアントと比較して、ユーザは、遙かに少ないメディア品質の削減を被ることになる。
【００７０】
一方、この機能により、ユーザが、セッションビットレートの上限に近いほど、輻輳を緩和するための発展的な動作の一般的な方法により、より公平に責任が分担される。
【００７１】
共有リソースを介して送信されるパケット交換メディアストリームの受信機に対して、共有リソースによって発行される輻輳通知メッセージに対する応答として、本発明のレート適応メカニズムを説明しているが、リアルタイム伝送要件に従うソースデータあるいはメディアがパケット交換ネットワークを介して送信機から受信機へ伝送される状況、また、ソースデータまたはメディアの受信機が、ソースデータあるいはメディアの送信機からの送信レートの適応をリクエストする必要がある状況等のその他の状況においても、本発明のレート適応メカニズムは等しく適用可能である。例えば、別のレイヤの輻輳通知メッセージによって、または共有リソースから受信される輻輳通知メッセージとは別のメッセージによって、レート適応メカニズムを呼び出すことができる。１つのこのようなメッセージは「輻輳緩和」メッセージであり得り、この場合では、均衡のとれた方法で送信レートを引き上げるために、レート適応メカニズムを使用することができる。例えば、ビットレートの最大の引下を経験しているパーティが比較的少ないビットレートの引下を行っているパーティより、より大きな引上を得るように、これを行うことができる。このことは、現行送信ビットレートがビットレート範囲の上限に近い場合より、現行送信ビットレートがビットレート範囲の下限に近い場合に、現行ビットレートあるいは現行送信ビットレートは比較的多く引き上がるであろうということを意味している。さらに、現行受信ビットレートがビットレート範囲の上限に近い場合より、現行受信ビットレートがビットレート範囲の下限に近い場合に、現行受信ビットレートは比較的多く引き上がるように、ビットレート適応量の推定が行われることになる。
【００７２】
例えば、別のノードがＥＣＮビットを設定することを意味する、ネットワーク状態に関する良い知識を有する別のネットワークリソースからも、このメッセージを受信することができる。
【図１】
2010533419.tif 000005
【図２】
2010533419.tif 000006
【図３】
2010533419.tif 000007
【図４】
2010533419.tif 000008
【図６】
2010533419.tif 000009
【図７】
2010533419.tif 000010
【図８】
2010533419.tif 000011
【図９】
2010533419.tif 000012
【図１０】
2010533419.tif 000013
【図１１】
2010533419.tif 000014
【図１２】
2010533419.tif 000015
【図１３】
2010533419.tif 000016
【図１４】
2010533419.tif 000017
【図５】
2010533419.tif 000018
【手続補正書】
【提出日】平成21年5月19日(2009.5.19)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
共有リソースを介して複数のセッションがセットアップされるパケット交換通信システムにおける、送信機と受信機との間でのセッションのビットレートを制御する方法であって、
前記セッションに対して有効なビットレート範囲であって、上限及び下限を有するビットレート範囲を判定するステップと、
前記受信機からレート適応リクエストメッセージを受信するステップと、
前記セッションの現行ビットレートと前記ビットレート範囲とを比較するステップと、
前記現行ビットレートが前記ビットレート範囲の前記上限に近い場合、前記現行ビットレートが前記ビットレート範囲の前記下限に近い場合に比べて、前記現行ビットレートがより引き下げられるように、また、前記現行ビットレートが前記ビットレート範囲の前記下限に近い場合、前記現行ビットレートが前記ビットレート範囲の前記上限に近い場合に比べて、前記現行ビットレート範囲がより引き上げられるように、前記現行ビットレートを適応させるステップと
を備えることを特徴とする方法。
【請求項２】
前記受信機は、ネットワークリソースからのメッセージの受信に応じて、前記レート適応リクエストメッセージを送信する
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記ネットワークリソースからの前記メッセージは、輻輳通知メッセージである
ことを特徴とする請求項２に記載の方法。
【請求項４】
前記ネットワークリースは、前記共有リソースである
ことを特徴とする請求項２に記載の方法。
【請求項５】
前記ビットレートを判定するステップは、更に、前記セッションに対するセットアップ処理において前記ビットレート範囲を信号通知することを含む
ことを特徴とする請求項１に記載の方法。
【請求項６】
前記セッションにおける通信のために、明示的な輻輳通知付きユーザ・データグラム・プロトコルが使用される
ことを特徴とする請求項１に記載の方法。
【請求項７】
前記ビットレート範囲に対する前記上限及び前記下限は、前記セッションに対して許容される特定のサービス品質に関連している
ことを特徴とする請求項１に記載の方法。
【請求項８】
前記現行ビットレートを適応させるステップは、更に、加入者プロパティに依存する量によって前記現行ビットレートを適応させることを含む
ことを特徴とする請求項１に記載の方法。
【請求項９】
前記現行ビットレートを適応させるステップは、更に、前記現行ビットレートを絶対量まで適応させる、あるいは前記現行ビットレートが特定ビットレート値を上回る場合には前記現行ビットレートを前記特定ビットレート値に適応させることを含む
ことを特徴とする請求項１に記載の方法。
【請求項１０】
共有リソースを介するセッションにおいて送信機によって送信されるパケット交換符号化メディアを受信する受信機であって、
前記セッションに対して有効なビットレート範囲であって、上限及び下限を有するビットレート範囲を判定するためのビットレート判定手段と、
前記現行受信ビットレートと前記ビットレート範囲とを比較して、前記現行受信ビットレートが前記ビットレート範囲の前記上限に近い場合、前記現行受信ビットレートが前記ビットレート範囲の前記下限に近い場合に比べて、前記現行受信ビットレートがより引き下げられるように、また、前記現行受信ビットレートが前記ビットレート範囲の前記下限に近い場合、前記現行受信ビットレートが前記ビットレート範囲の前記上限に近い場合に比べて、前記現行受信ビットレート範囲がより引き上げられるように、ビットレート適応量を推定することによって、前記ビットレート適応量を推定するビットレートリクエスト推定手段と、
前記セッションにおける現行送信ビットレートに適応させることを、前記送信機にリクエストするレートリクエスト手段と
を備えることを特徴とする受信機。
【請求項１１】
前記ビットレートリクエスト推定手段は、前記ビットレート適応量を推定するために、パケット損失レート、ジッタ、ネットワークフィードバックメッセージ及びアプリケーション設定の内の少なくとも１つの情報タイプを考慮するように構成されている
ことを特徴とする請求項１０に記載の受信機。
【請求項１２】
前記受信機は、
ネットワークリソースからメッセージを検出するための検出手段を更に備え、
前記ビットレートリクエスト推定手段は、前記ネットワークリソースからの前記メッセージの検出時に、前記ビットレート適応量を推定する
ことを特徴とする請求項１０に記載の受信機。
【請求項１３】
前記ネットワークリソースからの前記メッセージは、輻輳通知メッセージである
ことを特徴とする請求項１２に記載の受信機。
【請求項１４】
前記ネットワークリースは、前記共有リソースである
ことを特徴とする請求項１２に記載の受信機。
【請求項１５】
前記レートリクエスト手段は、前記セッションにおける現行送信ビットレートに適応させることを前記送信機にリクエストする場合に、前記ビットレート適応量を含めるように構成されている
ことを特徴とする請求項１０に記載の受信機。
【請求項１６】
前記セッションで受信される前記パケット符号化メディアを復号するための少なくとも１つのメディアデコーダを更に備える
ことを特徴とする請求項１０に記載の受信機。
【請求項１７】
共有リソースを介するセッションにおいて、パケット交換符号化メディアを受信機に送信する送信機であって、
前記セッションに対して有効なビットレート範囲であって、上限及び下限を有するビットレート範囲を判定するためのビットレート判定手段と、
前記セッションの現行送信ビットレートに適応させるためのリクエストを、前記受信機から受信するためのレートリクエスト受信手段と、
前記受信機からのリクエストに応じて、前記現行送信ビットレートが前記ビットレート範囲の前記上限に近い場合、前記現行送信ビットレートが前記ビットレート範囲の前記下限に近い場合に比べて、前記現行送信ビットレートがより引き下げられるように、また、前記現行送信ビットレートが前記ビットレート範囲の前記下限に近い場合、前記現行送信ビットレートが前記ビットレート範囲の前記上限に近い場合に比べて、前記現行送信ビットレート範囲がより引き上げられるように、前記セッションの前記現行送信ビットレートのレート適応を制御するためのレート適応制御ユニットと
を備えることを特徴とする送信機。
【請求項１８】
ネットワークリソースからのメッセージの受信に応じて、前記現行送信ビットレートに適応させるためのリクエストは前記受信機によって送信される
ことを特徴とする請求項１７に記載の送信機。
【請求項１９】
前記ネットワークリソースからの前記メッセージは、輻輳通知メッセージである
ことを特徴とする請求項１８に記載の送信機。
【請求項２０】
前記ネットワークリースは、前記共有リソースである
ことを特徴とする請求項１８に記載の送信機。
【請求項２１】
前記レート適応制御ユニットは、前記現行送信ビットレートと前記ビットレート範囲とを比較することによって、前記セッションの前記現行送信ビットレートの前記レート適応を判定するように構成されている
ことを特徴とする請求項１７に記載の送信機。
【請求項２２】
推定ビットレート適応量が、前記現行送信ビットレートに適応させるために、前記受信機の前記リクエストに含められ、
前記レート適応制御ユニットは、前記セッションの前記現行送信ビットレートのレート適応量を判定するための入力として、前記推定ビットレート適応量を使用するように構成されている
ことを特徴とする請求項１７に記載の送信機。
【請求項２３】
前記レート適応制御ユニットは、前記ビットレート適応量を推定するために、パケット損失レート、ジッタ、ネットワークフィードバックメッセージ及びアプリケーション設定の内の少なくとも１つの情報タイプを考慮するように構成されている
ことを特徴とする請求項１７に記載の送信機。
【請求項２４】
前記セッションで送信される前記パケット符号化メディアを出力するための少なくとも１つのメディアエンコーダを更に備える
ことを特徴とする請求項１７に記載の送信機。
【請求項２５】
少なくとも第１のセッションと第２のセッションとのビットレートを制御するためのパケット交換通信システムであって、
前記第１のセッションにおいて共有リソースを介して、第１の受信機と通信するために動作可能な少なくとも１つの第１の送信機と、
前記第２のセッションにおいて前記共有リソースを介して、第２の受信機と通信するために動作可能な少なくとも１つの第２の送信機と、
前記第１のセッションに対して有効な第１のビットレート範囲であって、上限及び下限を有する第１のビットレート範囲を判定する第１のビットレート範囲判定手段と、
前記第２のセッションに対して有効な第２のビットレート範囲であって、上限及び下限を有する第２のビットレート範囲を判定する第２のビットレート範囲判定手段と、
第１の現行ビットレートが前記第１のビットレート範囲の前記上限に近い場合、前記第１の現行ビットレートが前記第１のビットレート範囲の前記下限に近い場合に比べて、前記第１の現行ビットレートがより引き下げられるように、また、前記第１の現行ビットレートが前記第１のビットレート範囲の前記下限に近い場合、前記第１の現行ビットレートが前記第１のビットレート範囲の前記上限に近い場合に比べて、前記第１の現行ビットレート範囲がより引き上げられるように、前記第１のセッションの前記第１の現行ビットレートのレート適応を制御するための第１のレート適応制御ユニットと、
第２の現行ビットレートが前記第２のビットレート範囲の前記上限に近い場合、前記第２の現行ビットレートが前記第２のビットレート範囲の前記下限に近い場合に比べて、前記第２の現行ビットレートがより引き下げられるように、また、前記第２の現行ビットレートが前記第２のビットレート範囲の前記下限に近い場合、前記第２の現行ビットレートが前記第２のビットレート範囲の前記上限に近い場合に比べて、前記第２の現行ビットレート範囲がより引き上げられるように、前記第２のセッションの前記第２の現行ビットレートのレート適応を制御するための第２のレート適応制御ユニットと
を備えることを特徴とするパケット交換通信システム。
【請求項２６】
前記第１のレート適応制御ユニットと前記第２のレート適応制御ユニットは、レート適応リクエストメッセージの受信によって起動される
ことを特徴とする請求項２５に記載のパケット交換通信システム。
【国際調査報告】
2010533419.tif 000019
2010533419.tif 000020
2010533419.tif 000021
2010533419.tif 000022