JP5284355B2 - 通信システムにおける適応レート制御 - Google Patents

通信システムにおける適応レート制御 Download PDF

Info

Publication number
JP5284355B2
JP5284355B2 JP2010516007A JP2010516007A JP5284355B2 JP 5284355 B2 JP5284355 B2 JP 5284355B2 JP 2010516007 A JP2010516007 A JP 2010516007A JP 2010516007 A JP2010516007 A JP 2010516007A JP 5284355 B2 JP5284355 B2 JP 5284355B2
Authority
JP
Japan
Prior art keywords
bit rate
current
session
rate
range
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2010516007A
Other languages
English (en)
Other versions
JP2010533419A (ja
Inventor
ステファン ウェンステッド，
ダニエル エンストレム，
ギスラン ペレティエル，
Original Assignee
テレフオンアクチーボラゲット エル エム エリクソン（パブル）
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by テレフオンアクチーボラゲット エル エム エリクソン（パブル） filed Critical テレフオンアクチーボラゲット エル エム エリクソン（パブル）
Publication of JP2010533419A publication Critical patent/JP2010533419A/ja
Application granted granted Critical
Publication of JP5284355B2 publication Critical patent/JP5284355B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/22—Traffic shaping
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/25—Flow control; Congestion control with rate being modified by the source upon detecting a change of network conditions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/26—Flow control; Congestion control using explicit feedback to the source, e.g. choke packets
    • H04L47/263—Rate modification at the source after receiving feedback
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/29—Flow control; Congestion control using a combination of thresholds
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/04—Registration at HLR or HSS [Home Subscriber Server]
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/50—Reducing energy consumption in communication networks in wire-line communication networks, e.g. low power modes or reduced link rate

Description

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

Claims (26)

  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. 前記第１のレート適応制御ユニットと前記第２のレート適応制御ユニットは、レート適応リクエストメッセージの受信によって起動される
    ことを特徴とする請求項２５に記載のパケット交換通信システム。
JP2010516007A 2007-07-09 2008-07-09 通信システムにおける適応レート制御 Expired - Fee Related JP5284355B2 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US94851407P 2007-07-09 2007-07-09
US60/948,514 2007-07-09
US95624107P 2007-08-16 2007-08-16
US60/956,241 2007-08-16
PCT/SE2008/050853 WO2009008829A1 (en) 2007-07-09 2008-07-09 Adaptive rate control in a communications system

Publications (2)

Publication Number Publication Date
JP2010533419A JP2010533419A (ja) 2010-10-21
JP5284355B2 true JP5284355B2 (ja) 2013-09-11

Family

ID=40228846

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2010516007A Expired - Fee Related JP5284355B2 (ja) 2007-07-09 2008-07-09 通信システムにおける適応レート制御

Country Status (11)

Country Link
US (2) US8625608B2 (ja)
EP (1) EP2165481B1 (ja)
JP (1) JP5284355B2 (ja)
CN (1) CN101743725B (ja)
AT (1) ATE539528T1 (ja)
BR (1) BRPI0813927B1 (ja)
CA (1) CA2698344C (ja)
DK (1) DK2165481T3 (ja)
ES (1) ES2378592T3 (ja)
PL (1) PL2165481T3 (ja)
WO (1) WO2009008829A1 (ja)

Families Citing this family (50)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DK2165481T3 (da) * 2007-07-09 2012-04-02 Ericsson Telefon Ab L M Adaptiv rate-styring i et kommunikationssystem
ES2385749T3 (es) * 2007-08-22 2012-07-31 Telefonaktiebolaget L M Ericsson (Publ) Métodos y dispositivos para el control de la transmisión de datos
WO2009090160A1 (en) * 2008-01-14 2009-07-23 Telefonaktiebolaget Lm Ericsson (Publ) Method and nodes for congestion notification
WO2010138913A1 (en) * 2009-05-29 2010-12-02 Harmonic, Inc. Systems and methods for video statistical multiplexing adapting to internet protocol networks
US8537699B2 (en) * 2009-06-16 2013-09-17 Qualcomm Incorporated Managing video adaptation algorithms
US9007914B2 (en) * 2009-09-30 2015-04-14 Qualcomm Incorporated Methods and apparatus for enabling rate adaptation across network configurations
WO2011052590A1 (ja) * 2009-10-28 2011-05-05 日本電気株式会社 リモート型携帯通信システム、方法及びプログラム
US8416690B2 (en) * 2010-01-11 2013-04-09 Research In Motion Limited Explicit congestion notification based rate adaptation using binary marking in communication systems
EP2564553A1 (en) 2010-04-28 2013-03-06 Telefonaktiebolaget LM Ericsson (publ) Monitoring broadcast and multicast streaming service
US20120087245A1 (en) 2010-10-06 2012-04-12 Qualcomm Incorporated Methods and apparatus for ecn receiver driven congestion control
KR101710400B1 (ko) * 2010-10-29 2017-02-28 엘지전자 주식회사 무선 통신 시스템에서 최저 보장 비트 레이트 설정 방법 및 이를 위한 장치
WO2012140862A1 (ja) * 2011-04-14 2012-10-18 パナソニック株式会社 コンテンツ記録装置、コンテンツ記録方法、及びコンテンツ伝送システム
EP3684104A1 (en) 2011-06-09 2020-07-22 Panasonic Intellectual Property Corporation of America Communication terminal and communication method
CN102833219B (zh) * 2011-06-16 2015-06-03 华为技术有限公司 向客户端传输数据文件的方法和装置
US10320869B2 (en) * 2011-07-07 2019-06-11 Telefonaktiebolaget Lm Ericsson (Publ) Network-capacity optimized adaptive HTTP streaming
CN103959882B (zh) * 2011-10-04 2018-02-02 瑞典爱立信有限公司 移动网络的基站中的拥塞处置
US8984124B2 (en) 2011-11-30 2015-03-17 Microsoft Technology Licensing, Llc System and method for adaptive data monitoring
US8755344B2 (en) * 2011-12-20 2014-06-17 Motorola Solutions, Inc. Method and apparatus for granting wireless connection resources to a wireless communications device within a communication system
US9495227B2 (en) * 2012-02-10 2016-11-15 Twilio, Inc. System and method for managing concurrent events
JP6045608B2 (ja) * 2012-02-13 2016-12-14 アファームド ネットワークス，インク． モバイルビデオ配信
KR102078893B1 (ko) * 2012-06-29 2020-02-19 인터디지털 씨이 페이튼트 홀딩스 Wlan 액세스 포인트를 위한 저전력 소비 모드
TWI505672B (zh) 2012-07-24 2015-10-21 Nec Corp Communication systems and methods and programs
US9591513B2 (en) * 2012-08-06 2017-03-07 Vid Scale, Inc. Rate adaptation using network signaling
EP2890096A4 (en) 2012-08-24 2016-06-08 Nec Corp REMOTE COMMUNICATION SYSTEM, SERVER DEVICE, REMOTE COMMUNICATION METHOD AND PROGRAM
US10404562B2 (en) * 2012-10-22 2019-09-03 Texas State University Optimization of retransmission timeout boundary
CN104756539A (zh) 2012-10-29 2015-07-01 阿尔卡特朗讯公司 用于在具有移动http自适应流的无线网络中的拥塞管理的方法与装置
WO2014087764A1 (ja) * 2012-12-03 2014-06-12 日本電気株式会社 端末および通信システム
US10380077B2 (en) * 2013-04-08 2019-08-13 Ittiam Systems Pte. Ltd. System and method for upload and synchronization of media content to cloud based media services
US9356869B2 (en) 2013-04-10 2016-05-31 Viber Media Inc. VoIP bandwidth management
US10057014B2 (en) * 2013-05-22 2018-08-21 Google Llc System and method for streaming data
US20150106526A1 (en) * 2013-10-11 2015-04-16 Hewlett-Packard Development Company, L.P Provisioning a network for network traffic
CN104753810A (zh) * 2013-12-30 2015-07-01 腾讯数码（天津）有限公司 一种网络入流量限速方法及装置
EP3113468B1 (en) 2014-02-28 2020-04-08 Panasonic Intellectual Property Corporation of America Voice communication terminal, intermediate node, processing device, connection method, and program
KR102244612B1 (ko) 2014-04-21 2021-04-26 삼성전자주식회사 무선 통신 시스템에서 음성 데이터를 송신 및 수신하기 위한 장치 및 방법
US9860791B1 (en) * 2014-07-02 2018-01-02 Sprint Communications Company L.P. Long term evolution communication policies based on explicit congestion notification
US20170230252A1 (en) * 2014-10-24 2017-08-10 ZTE CORPORATION (CHINA) ZTE Plaza Method and system for deep stats inspection (dsi) based smart analytics for network/service function chaining
CN113259058A (zh) * 2014-11-05 2021-08-13 三星电子株式会社 用于在无线通信系统中发射和接收语音数据的装置和方法
CN105792381A (zh) * 2014-12-23 2016-07-20 华为技术有限公司 无线局域网中的竞争调节方法、装置以及系统
JP6222190B2 (ja) * 2015-09-03 2017-11-01 コニカミノルタ株式会社 文書処理装置およびその通信制御方法
CN108292970B (zh) * 2015-12-07 2021-07-30 直播瑞典有限公司 通过互联网直播分发的自适应比特率调整方法和装置
CN108702332B (zh) * 2016-02-25 2022-03-18 瑞典爱立信有限公司 电信网络中的拥塞控制
US10708819B2 (en) * 2016-02-25 2020-07-07 Telefonaktiebolaget Lm Ericsson (Publ) Back-pressure control in a telecommunications network
WO2018031614A1 (en) 2016-08-11 2018-02-15 Kyocera Corporation Ran-assisted rate adaptation
WO2019148041A1 (en) * 2018-01-26 2019-08-01 Opanga Networks, Inc. Systems and methods for identifying candidate flows in data packet networks
US20190215729A1 (en) * 2018-03-15 2019-07-11 Intel Corporation Session description protocol mechanisms for signaling radio access network capabilities in multimedia telephony sessions
US11350268B2 (en) * 2018-05-18 2022-05-31 Qualcomm Incorporated End-to-end rate adaptation using RAN assisted rate adaptation
EP3827535A4 (en) 2018-07-24 2022-06-22 QUALCOMM Incorporated PROCEDURE FOR RATE ADJUSTMENT UNDER CONGESTION AND LATITUDE RESTRICTIONS
US20200120211A1 (en) * 2018-10-10 2020-04-16 Avaya Inc. Dynamic agent media type selection based on communication session quality of service parameters
US10911798B2 (en) * 2018-10-26 2021-02-02 Citrix Systems, Inc. Providing files of variable sizes based on device and network conditions
US11470005B2 (en) * 2020-12-15 2022-10-11 Cisco Technology, Inc. Congestion detection using machine learning on arbitrary end-to-end paths

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10247944A (ja) * 1997-03-05 1998-09-14 Kokusai Denshin Denwa Co Ltd <Kdd> 中継制御装置および方法
WO1999038333A1 (en) * 1998-01-26 1999-07-29 Sgs-Thomson Microelectronics Asia Pacific (Pte) Ltd. One-pass variable bit rate moving pictures encoding
US6597699B1 (en) * 1999-09-28 2003-07-22 Telefonaktiebolaget Lm Ericsson (Publ) Quality of service management in a packet data router system having multiple virtual router instances
FI113140B (fi) * 2001-05-25 2004-02-27 Nokia Corp Kanavanvaihto solukkojärjestelmässä
US20030198184A1 (en) * 2001-08-31 2003-10-23 Joe Huang Method of dynamically determining real-time multimedia streaming rate over a communications networks
GB0216728D0 (en) * 2002-07-18 2002-08-28 British Telecomm Network resource control
US20040071145A1 (en) 2002-07-27 2004-04-15 Lg Electronics Inc. Apparatus and method for UBR traffic control
US9414255B2 (en) * 2002-09-13 2016-08-09 Alcatel Lucent Packet flow control in a wireless communications network based on an indication contained in a packet
US7573856B2 (en) * 2003-11-25 2009-08-11 Telefonaktiebolaget Lm Ericsson (Publ) Power-based rate adaptation of wireless communication channels
JP2005167414A (ja) * 2003-11-28 2005-06-23 Toshiba Corp データ受信装置およびデータ受信方法
CN100423510C (zh) * 2004-09-17 2008-10-01 大唐高鸿数据网络技术股份有限公司 监控rtp/rtcp流以提高多媒体通信质量的方法
FR2878396A1 (fr) * 2004-11-19 2006-05-26 France Telecom Procede de codage d'images codees par ondelettes a controle du debit, dispositif de codage et programme d'ordinateur corespondants
CN101218774B (zh) * 2005-06-15 2012-10-10 艾利森电话股份有限公司 通过因特网协议网络的自适应移动电话语音传输
US20070214247A1 (en) * 2006-03-13 2007-09-13 Xue Yang System for spatial backoff contention resolution for wireless networks
DK2165481T3 (da) * 2007-07-09 2012-04-02 Ericsson Telefon Ab L M Adaptiv rate-styring i et kommunikationssystem

Also Published As

Publication number Publication date
BRPI0813927A2 (pt) 2014-12-30
CN101743725B (zh) 2015-09-02
BRPI0813927B1 (pt) 2020-10-20
CN101743725A (zh) 2010-06-16
ES2378592T3 (es) 2012-04-16
EP2165481A1 (en) 2010-03-24
US8625608B2 (en) 2014-01-07
CA2698344A1 (en) 2009-01-15
US8942243B2 (en) 2015-01-27
EP2165481A4 (en) 2010-07-28
CA2698344C (en) 2016-08-30
PL2165481T3 (pl) 2012-05-31
US20100195521A1 (en) 2010-08-05
DK2165481T3 (da) 2012-04-02
US20140105026A1 (en) 2014-04-17
WO2009008829A1 (en) 2009-01-15
ATE539528T1 (de) 2012-01-15
EP2165481B1 (en) 2011-12-28
JP2010533419A (ja) 2010-10-21

Similar Documents

Publication Publication Date Title
JP5284355B2 (ja) 通信システムにおける適応レート制御
KR102013729B1 (ko) 통신 네트워크에서 애플리케이션-인식 수락 제어를 위한 방법 및 시스템
US9203886B2 (en) Content rate control for streaming media servers
KR101259689B1 (ko) 소스 노드와 목적지 노드 사이의 접속을 위한 ＱｏＳ 구현 시스템 및 방법
EP2122940B1 (en) Proxy-based signaling architecture for streaming media services in a wireless communication system
JP4520705B2 (ja) 通信システム及び通信方法
EP3522591B1 (en) Access node for cooperative applications
JP2016527579A (ja) データ通信システム及び方法
JP2010136257A (ja) ネットワークシステム及び通信計画サーバ
US7788348B2 (en) Context profile for data communications
JP2009105949A (ja) ＱｏＳ制御を実行することが可能な端末
Ruiz et al. Adaptive multimedia applications to improve user-perceived qos in multihop wireless ad-hoc networks
Rakocevic Congestion Control for multimedia applications in the wireless Internet
Zhao et al. Cross-layer adaptive rate control for video transport over wireless ad hoc networks
KR101384125B1 (ko) 통신 시스템에서 맥 계층의 서비스 품질 파라미터 생성장치 및 방법
Tschofenig et al. Report from the IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication
Ogawa et al. Distributed QoS control based on fairness of quality for video streaming
Viamonte et al. Requirements for the optimization of session setup delay and service interactivity in streaming services over 3G
Sarker A study on adaptive real time video over LTE
Lee et al. Adaptive rate control scheme for streaming-based content sharing service
Tschofenig et al. RFC 7295: Report from the IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20110609

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20130116

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20130118

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20130417

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20130513

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20130529

R150 Certificate of patent or registration of utility model

Ref document number: 5284355

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees