JP2006503493A - データビットの送信を制御する方法および装置 - Google Patents

Abstract

本発明は、アプリケーションサーバ（２）からクライアント（１）へのデータ情報を送信するためのビット転送セッションにおいて、データビットの送信を制御する方法および装置に関する。当該ビット転送セッションは、フロー制御メカニズムを有するトランスポートプロトコルによって無線通信回線を介したビット転送を行うことに関連する。本発明によれば、無線リソース管理ユニット（６）は、現在のところ使用することが許可されているビット転送セッションの無線通信回線の帯域に関する情報を送信する。無線リソース管理ユニットからのフィードバック情報は、当該セッションの間、継続的にフロー制御パラメータを設定および更新するために使用される。これによって、フロー制御パラメータの最適化が容易になり、エンドユーザのＱｏＳを向上させることができ、無線リソースの効率的な活用が達成されよう。

Description

本発明は、通信システムおよび通信方法に係り、とりわけ、ビット転送セッションにおいてデータビットの送信を制御することに関連する。

データビット形式の情報についてパケットベースの通信を行う通信ネットワークが当業者には良く知られている。確かに、インターネットは、最も広く知られているデータ通信ネットワークであろう。これまで、非常にバラエティに富んだ種々の通信プロトコルが、データ通信のために開発されてきた。トランスポートプロトコルは、データを正しいセッションに転送するために使用される。インターネットでは、トランスポートプロトコルとして、であるＵＤＰ（ユーザーデータグラムプロトコル）やＴＣＰ（送信制御プロトコル）が使用されている。ＵＤＰは、フロー制御メカニズムを備えていないコネクションレス型のプロトコルであるが、一方のＴＣＰは、２つのホスト間で信頼性のあるデータ転送を行うためにフロー制御メカニズムを使用するコネクション型のプロトコルである。

移動通信の重要性は増しており、無線接続を介したデータを転送する需要も増えている。無線通信回線を介したデータの転送は、固定の有線通信回線であれば遭遇しないような数多くの問題と困難とに突き当たることがある。エアインタフェース上の帯域幅は、乏しく、限りのあるリソースである。したがって、利用可能な無線リソースを効率よく使用できれば、利点が多い。すなわち、移動通信ネットワークにおける無線接続で利用可能な帯域幅は、例えば、フェージングによる落ち込みやシャドーイングの発生によってエアインタフェースの特性が変化するため、非常に高速に変動する可能性がある。エアインタフェース上の帯域幅には限りがあること、およびこの帯域幅が変動することから、移動通信システムに加入しているエンドユーザに対して、許容可能な程度のサービス品質（ＱｏＳ）を提供することは、艱難となりうる。例えば、限りのある帯域幅によって、エンドユーザをイライラさせるほどの長い遅延が発生することがある。

移動通信システムに加入しているエンドユーザへのサービス品質を改善するための方法がいくつか提案されている。

Ｇ．Ｃｏｔｅ氏、Ｓ．Ｓｈｉｒａｎｉ氏およびＦ．Ｋｏｓｓｅｎｔｉｎｉ氏らによる「エラーの発生しやすいネットワークを介した強靱な映像通信のための最適モードの選択および同期獲得」、ＩＥＥＥＪｏｕｒｎａｌ ｏｎ Ｓｅｌｅｃｔｅｄ Ａｒｅａｓ ｉｎ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ， ｖｏｌ． １８， Ｎｏ． ６， Ｊｕｎｅ ２０００、および、Ｃ．Ｈｓｕ氏， Ａ．Ｏｒｔｅｇａ氏およびＭ． Ｋｈａｎｓａｒｉ氏らによる「バーストエラーの発生する無線チャネルを介した強靱な映像通信のためのレート制御」、ＩＥＥＥ Ｊｏｕｒｎａｌ ｏｎ Ｓｅｌｅｃｔｅｄ Ａｒｅａｓ ｉｎ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ， ｖｏｌ． １７， Ｎｏ． ５， Ｍａｙ １９９９によれば、サーバ制御によるビットレート制限のための判定を精度良く実行するために、チャネルの状態情報を利用する方法について記載されている。

Ｇ．Ｃｈｅｕｎｇ氏およびＴ．Ｙｏｓｈｉｍｕｒａ氏らによる「ストリーミングエージェント：３Ｇ無線ネットワークにおいてメディアストリーミングを行うためのネットワークプロキシー」、ＩＥＥＥ Ｐａｃｋｅｔ Ｖｉｄｅｏ Ｗｏｒｋｓｈｏｐ ２００２によれば、有線ネットワークおよび無線ネットワークとの間にストリーミングエージェント（ＳＡ）が導入されている。これは、無線通信回線をほとんどロスがないものと仮定した上で、有線通信回線における輻輳状況の影響を低下させるものである。ＳＡは、適当なタイミングで、サーバにフィードバックし、有線通信回線の状態を追跡できるようにしている。このようにして、サーバは、レート変更の決定をより適切に実行することができる。

Ａ．Ｓｃｈｉｅｄｅｒ氏ほかによる「ＧＥＲＡＮのためのリソース効率の優れたストリーミングベアラコンセプト」、ＷＰＭＣ Ｏｃｔｏｂｅｒ ２００２ ｉｎ Ｈｏｎｏｌｕｌｕによれば、メッセージをサーバにフィードバックするためのトリガーとして、クライアントにおけるバッファがフルになったことを使用する方法が開示されている。その目的は、ＧＳＭ／ＥＤＧＥの無線アクセスネットワークにおいて無線リソースを効率よく使用しつつ、エンドユーザに良いＱｏＳを提供することにある。

米国特許第６、１５１、３００号によれば、ＡＴＭネットワーク上で通信しているＬＡＮのホストに対して、ＡＴＭネットワークのフロー制御を拡張適用する方法が記述されている。トランスポートレイヤー上のフロー制御メカニズムとＡＴＭレイヤ上のフロー制御メカニズムとを組み合わせることで、過度なパケット損失と不安定な動作をもたらす状況を回避しうる。

Ｐｒａｄｅｅｐ Ｓｕｄａｍｅ Ｂ． Ｒ． Ｂａｄｒｉｎａｔｈ氏による「移動無線ネットワークにおけるプロトコル適応のためのサポートの提供」、Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋｓ ａｎｄ Ａｐｐｌｉｃａｔｉｏｎｓ ０ （１９９９）によれば、ネットワーク環境の変化に応じて移動ホストで実行される適応メカニズムについて記述されている。例えば、ＴＣＰの初期ウインドウサイズを変更することが適応処理の１つであろう。

欧州特許出願ＥＰ１１２６７１６によれば、映像データサービスアプリケーションのビットレートをより正確に調整するために、移動通信ネットワークからの無線ネットワーク情報を使用するといったコンセプトが紹介されている。

上述の従来技術は、移動通信ネットワークにおけるエンドユーザに対するＱｏＳの最適化問題を解決することを試みている。これは、主に、ストリーミングや映像サービスなど、ＵＤＰベースのサービスをターゲットとしている。例えば、ＥＰ１１２６７１６では、ＵＤＰベースのサービスをターゲットとした解決方法が提案されている。しかしながら、これらは、ＴＣＰのように、フロー制御メカニズムを有するトランスポートプロトコルをベースとしたアプリケーションの問題を最適化することには着目していない。

また、上述の従来技術は、クライアント主導の解決方法である。すなわち、移動通信システムのエンドユーザからのフィードバックメッセージを使用して、エンドユーザのサービス品質を制御するものである。このクライアント主導による手法の欠点は、クライアントが、エアインタフェース上のコネクションで利用可能な帯域幅の変化を正確に検出するまでに、非常に長時間を要することである。無線環境が不安定であれば、クライアントは、信頼性のあるフィードバックメッセージを送るために、長時間にわたってフィルタリングや平均値計算を実行することを要求される。さらに、エンドユーザからのフィードバックメッセージは、無線接続を介して、制御システムへと送信されなければならないが、これは制御システムへの入力データに対してさらなる遅延を付与することになる。

本発明の目的は、エンドユーザのためのＱｏＳと、移動通信システムにおけるユーザとコンテンツサービスにおける無線リソースの使用とを制御する方法および装置を改善することである。

上述の目的は、請求項１に係る方法、請求項１４に係るコンピュータプログラム、請求項１５に記載の装置および請求項２８に記載のシステムとによって達成される。

移動通信システムのクライアントとアプリケーションサーバとの間で、フロー制御メカニズムを有するトランスポートプロトコルによって設定される転送セッションが、複数のフロー制御パラメータに関連付けられる。これらのフロー制御パラメータを設定する方法は、セッションのサービス品質と利用可能な無線リソースの使用とについて重要である。本発明は、無線リソース管理ユニットからのフィードバック情報を利用して、セッションの間、継続的にフロー制御パラメータを設定および更新する。本発明によると、無線リソース管理エンティティは、クライアントへのエアインタフェース上でのセッションについて利用可能な帯域幅の情報を、フロー制御パラメータを制御するネットワークエンティティに報告する。この帯域幅の情報により、フロー制御パラメータの最適化が容易になり、これにより、ＱｏＳの改善と、利用可能な無線リソースの効率的な使用とが達成される。

本発明の第１の観点によれば、アプリケーションサーバからクライアントへのデータ情報を送信するためのビット転送セッションにおいて、データビットの送信を制御する方法が提供される。当該ビット転送セッションは、フロー制御メカニズムを有するトランスポートプロトコルによって無線通信回線を介したビット転送を行うことに関与する。本方法は、当該セッションの間、継続的に無線リソース管理ユニットから、現在のところビット転送セッションを使用することを許可されている無線通信回線の帯域幅に関する情報をネットワークエンティティにおいて受信するステップと、受信した情報に応じて当該セッションの伝送速度を制御するために、受信した情報に基づいてトランスポートプロトコルのフロー制御パラメータに関連する少なくとも１つのパラメータをネットワークエンティティにおいて更新するステップとを含む。

本発明の第２の観点によれば、アプリケーションサーバからクライアントへとデータ情報を送信するためのビット転送セッションにおいてデータビットの送信を制御する装置が提供される。当該ビット転送セッションは、フロー制御メカニズムを有するトランスポートプロトコルによって無線通信回線を介したビット転送を行うことに関与する。本装置は、ネットワークエンティティに備えられる。当該装置は、当該セッションの間、継続的に無線リソース管理ユニットから、現在のところビット転送セッションを使用することを許可されている無線通信回線の帯域幅に関する情報を受信する受信手段を含む。さらに、本装置は、受信した情報に応じて当該セッションの伝送速度を制御するために、受信した情報に基づいてトランスポートプロトコルのフロー制御パラメータに関連する少なくとも１つのパラメータを更新するパラメータ設定手段を含む。

本発明の有利な点は、エアインタフェースを介して提案されたトラフィックと、パケット交換ドメインを介したユーザおよびコンテンツサービスのバックエンドとのバランスを最適化することをアシストすることで、乏しい無線リソースをより良く利用できることである。

本発明の他の利点は、フロー制御パラメータを制御するために使用されるフィードバック情報が、セッションの間、無線アクセスネットワークに配置されている無線リソース管理エンティティから継続的に提供されるため、現在の情報に基づいてフロー制御パラメータを更新できる。過去のセッションからの履歴データに基づいて、セッションの開始時に一度だけフロー制御パラメータを設定する従来の解決方法と比べ、より優れたパラメータ設定が可能となる。本発明において使用されるフィードバック情報は、無線アクセスネットワークからフロー制御パラメータを制御するネットワークエンティティへと通信されるので、フィードバック情報は、上述のクライアント主導的な解決方法と同程度の遅延にさらされることはない。無線アクセスネットワークは、クライアントが検出するよりも速く、利用可能な帯域幅の変化を検出できるため、エアインタフェースを介してフィードバック情報を伝送する必要はない。

本発明によるフロー制御パラメータを継続的にモニターおよび更新することで、セッションの開始当初だけでなく、セッションの全体にわたって良いＱｏＳを提供できる。セッション中にパラメータの設定が更新されることのない従来技術では、セッションの変化によって無線コンディションが変動すると、セッション中にＱｏＳが低下してしまう。無線コンディションは、非常に高速に変化するため、完全に有線接続のみを基礎としたセッションのパラメータ設定よりも、エアインタフェースに関連するセッションのパラメータ設定を更新するほうがより重要である。

本発明のさらなる利点は、ネットワークフィードバックを各セッションに対してそれぞれ個別に適用することで、各セッションのそれぞれのフロー制御パラメータを個別に更新することができる。したがって、各々のセッションのＱｏＳを最大限に利用しうるようにパラメータ設定を適応させることができる。いくつかの従来技術によれば、フロー制御はセッショングループを取り扱っているに過ぎなかった。本発明と比べ、従来技術の解決方法は、フロー制御についての決定を実行することがほとんどない。よって、従来技術の解決方法では、同一のグループ内で他のクライアントよりも局所的にずっと悪い無線コンディションにさらされている特定のユーザに対しては乏しいサービス品質しか提供できないだろう。

本発明のさらに他の利点は、エアインタフェース上で利用可能なビットレートに対する伝送速度の追従性を増大させることである。本発明によれば、無線リソース管理ユニットからのネットワークフィードバック情報に基づいて伝送速度を上昇させるよう切り替えたり、低下させるよう切り替えたりさせることできる。本発明による伝送速度の適応処理は、従来の解決方法よりも正確でかつスムーズになる。本発明は、伝送速度の劇的な低下をもたらすような切り替えを引き起こすような輻輳メカニズムの過度な適用を回避できる。一般に、本発明は、ネットワーク状態の誤って把握することに起因する極端な決定を削減することができる。

本発明のさらに他の利点は、概ね全てのタイプのアプリケーションに対して適用できることであろう。本発明の解決手段によれば、アプリケーションをネットワークに対して寛容にすることができる。すなわち、移動通信環境向けにアプリケーションを作成することに開発者が注目するようになり、しかも、ネットワークの伝送媒体を特別に考慮する必要はないのである。

本発明は、エアインタフェース上で現在利用可能な帯域幅に対して、スループットの適応処理をより正確かつより高速にできるため、ＲＮＣやＢＳＣなどの無線リソース管理ユニットにおけるオーバーフローのリスクを低減することができる。したがって、本発明のさらなる利点は、無線リソース管理ユニットに備えられるバッファのサイズを削減できることであろう。

本発明の実施形態に関するさらなる利点および目的は、図面を参照しつつ以下の詳細な説明を読むことにより、理解できよう。

以下では、本発明に係る実施形態を示した添付図面を参照しつつ、本発明についてより詳しく説明する。しかしながら、本発明は、以下で説明する実施形態に限定されるわけではなく、種々の具体的な形態として実現できることはいうまでもない。すなわち、以下での実施形態は、全体的にかつ完全に開示するために提供されるのであって、これにより、当業者であれば本発明の範囲を完全に理解できるであろう。図面においては、構成要素などを参照するために番号などを付している。

本発明は、移動通信システムにおけるユーザとコンテンツ間のパケット交換サービスに適用できるものであり、とりわけ、フロー制御メカニズムを備えるトランスポートプロトコルに基づいたサービスなどに適用できる。このようなサービスには、エンドユーザのユーザ装置とアプリケーションサーバとの間のパケット通信が含まれる。移動通信システムには、ＷＣＤＭＡ、ＣＤＭＡ２０００、ワイヤレスＬＡＮ、あるいはＧＰＲＳネットワークのような移動通信ネットワークが含まれる。フロー制御メカニズムを持つトランスポートプロトコルの一例はＴＣＰである。当業者に良く知られているように、ＴＣＰのフロー制御メカニズムには相当数のフロー制御パラメータが含まれている。ＴＣＰのフロー制御パラメータの一例は、ウインドウサイズとセグメントサイズである。ＴＣＰコネクション上でのデータビットの伝送は、ＴＣＰのフロー制御パラメータを変更する手段によって制御可能である。

移動ユーザ装置とアプリケーションサーバとの間に通信セッションが設定されるときに、エアインタフェース上で利用可能な帯域幅は、通常、セッションにおけるビットレートの制限要因となる。フェージングによる落ち込みやシャドーイングなど、エアインタフェースの特性は、エンドユーザにとって否定的な結果をもたらしうる。これは、トランスポートベアラとしてＴＣＰプロトコルを使用するアプリケーションにとっては、特に事実といえる。例えば、エアインタフェースを介した長い遅延が発生すると、ＴＣＰの輻輳回避メカニズムが起動されてしまうため、セッションの帯域幅がより狭くなり、エンドユーザにとっては、非常にひどい性能しか享受できなくなってしまう。一方で、エアインタフェース上での帯域幅をエンドユーザが一時的に増大させたとしても、大抵は、希望する程度までＴＣＰコネクションをスピードアップさせることはできない。すなわち、無線リソースは乏しいのである。エアインタフェース上の無線リソースは非常に乏しいものであり、できる限り効率よく使用することが望まれるため、利用可能な無線リソースを効率よく使用することで、エンドユーザへのサービス品質を改善することができるだろう。

図１は、従来技術に係るユーザ装置１に搭載されるクライアントとアプリケーションサーバ２との間に設定された通信セッションを示す図である。この例で、アプリケーションサーバ２はＷｅｂサーバである。ＴＣＰによって設定されると、クライアントとアプリケーションサーバ２との間にＴＣＰリンク３によって、セッションが設定される。クライアントが、アプリケーションサーバ２からの情報をブラウズまたはダウンロードするときに、クライアントは、受信品質を示すために、データを受信するとアクノレッジ（受信通知）を返す。アプリケーションサーバ２は、受信通知からの情報を使用して、例えば、ウインドウサイズやセグメントサイズなどのＴＣＰ伝送パラメータをＴＣＰリンク上の伝送条件に適応させる。

図１に示したアプローチの問題点は、伝送回線の一部に無線接続を含んでいると、多数の再送が実行されるような劣悪な無線コンディションを、アプリケーションサーバ２が輻輳であると誤解してしまい、それによって、ＴＣＰの輻輳回避メカニズムが起動されてしまうといったリスクがあることである。また、無線コンディションが非常に速い速度で変動するおそれがあるが、これによって、受信通知の形式で実行されるフィードバックも相対的に遅延するため、アプリケーションサーバ２が無線伝送条件の変動に対して適切に追従する能力が低下してしまう。これらの欠点は、ＴＣＰ伝送メカニズムが無線伝送用に設計されていないことが原因で発生する。

図２は、本発明が使用される通信セッションの基本原理を説明するための図である。クライアント１とアプリケーションサーバ２との間に、プロキシー４を経由して、ＴＣＰコネクション３ａおよび３ｂが設定される。ＴＣＰコネクション３ｂは、移動通信ネットワーク５における無線通信回線を介した伝送に関与している。本発明によれば、移動通信ネットワークは、無線通信回線の伝送に係るサービス品質に関するネットワークフィードバックデータをプロキシーに報告する。プロキシーは、ネットワークフィードバックデータを使用して、ＴＣＰコネクション３ｂに係るＴＣＰウインドウサイズやセグメントサイズなどのＴＣＰパラメータの設定を変更する。ネットワークフィードバックは、同様に、ＴＣＰコネクション３ａを介して、アプリケーションサーバに対して、どのように受信通知を送信するかを決定するために使用されてもよい。

プロキシーへと報告されるネットワークフィードバックデータは、移動通信ネットワークの無線リソース管理ユニットにより、エアインタフェースを介したセッションが使用することを許可された帯域幅についての情報である。

図２は、プロキシーと２つのＴＣＰコネクション３ａ、３ｂを使用してセッションを設定するために本発明を使用することを説明しているが、プロキシーを使用することは、本発明にとって必須ではない。中間のプロキシーが使用されずに、アプリケーションサーバとクラインアントとの間で直接的にセッションが設定される場合、本発明は、ネットワークフィードバックがアプリケーションサーバに直接提供されるように実現されることになろう。アプリケーションサーバは、ネットワークフィードバックを使用して、セッションのＴＣＰパラメータを適切に適応させることになる。

図３は、図１に関する構成と図２に関する構成とをそれぞれ使用したときのスループットの比較を示す図である。矩形の実線１８は、移動通信ネットワークの無線リソース管理ユニットが、エアインタフェースを介したセッションに使用を許可した帯域幅を示している。実線１０は、図１に係る従来技術のスループットを示している。また、太い実線１１は、図２に示した本発明の構成によるスループットを示している。

実線１０は、最初、エアインタフェース上で利用可能な最大のビットレートに達するまで指数的に増加することを示している。これが発生すると、クライアントは、「未受信」であることの報告を開始する。図１に示すアプリケーションサーバ２は、これを輻輳であると判定し、伝送速度を実質的に低下させる輻輳回避メカニズムを適用してしまう。そして、アプリケーションサーバは、直線的に、非常にゆっくりと伝送速度の増加を開始する。アプリケーションサーバによるこの動作は、無線通信回線上の現実の状況と一致してはいない。

対照的に、図２では、プロキシー４（あるいは、ネットワークフィードバックが直接的にサーバ２へと提供される実施形態では、このサーバ２）は、より適切かつより速く実行できる。これは、無線伝送条件についてより正確に記述した無線通信回線情報を、より速く受信できるからである。これは、太い実線１１によって示されている。実線１１は、本発明に係るネットワークフィードバックが使用されるときに、スループットがより速く上昇することを示しており、よって、全体でのスループットもより上昇し、エンドユーザに対してより良いサービス品質を提供できることを意味している。図２の構成が使用されるときは、エアインタフェース上で利用可能な帯域幅の増加が速やかになるため、より大きなスループットが得られることになる。ＴＣＰフロー制御パラメータを正しく調整することによって、長期間にわたって安定するように、伝送速度を調整することも可能となりうる。

図４は、ＵＭＴＳシステム２０における本発明の実施形態を説明する図である。本システムには、無線アクセスネットワーク５が含まれる。この無線アクセスネットワーク５には、相当数の基地局通信装置（ＢＴＳ）１９と、少なくとも１つの無線ネットワーク制御装置（ＲＮＣ）６とが含まれる。本システムは、さらに、在圏ＧＰＲＳサポートノード（ＳＧＳＮ）９や、ゲートウェイ（関門）ＧＰＲＳサポートノード（ＧＧＳＮ）８が含まれてもよい。これらは、無線アクセスネットワーク５とサービスネットワーク（ＳＮ）との間の接続を提供するコアネットワーク（ＣＮ）１２のノードたちである。ＵＭＴＳシステムにおける上述したユニットの特性と機能とは、当業者に良く知られているところなので、ここでは詳細には説明しない。

サービスネットワークは、アプリケーションサーバ２と、プロキシー４と、サービスネットワーク・セッション・データベース（ＳＮＳＤ）７とを含む。ビット転送セッションは、ＳＮ内のアプリケーションサーバ２と、ユーザ装置（ＵＥ）１におけるクライアントとの間に、コネクション３ａ、３ｂとによって設定される。コネクション３ａ、３ｂは、プロキシー４、ＧＧＳＮ８、ＣＮ１２、ＳＧＳＮ９および無線アクセスネットワーク５を通過するように確立される。代替的に、セッションが、ＵＥ１と、プロキシー４と通信することになる外部ネットワーク１４のアプリケーションサーバ２との間に設定されてもよい。コネクション３ａ、３ｂは、例えば、ＴＣＰコネクションであってもよいし、あるいは、類似のフロー制御メカニズムを有する他のタイプのトランスポートプロトコルをベースとしたコネクションであってもよい。

上述したように、本発明は、エンドユーザのサービス品質を最適化するような、セッションの伝送速度を制御する改良された手段を提供するものである。図４に示す本発明の実施形態によると、セッションに使用されるエアインタフェース上の許可された帯域幅についての情報は、コネクション１５を介して、ＲＮＣ６からＳＮＳＤ７に送信される。ＳＮＳＤは、プロキシー４に接続され、ＲＮＣからプロキシーへと帯域幅情報を伝達する。プロキシーは、ＲＮＣとその内部アルゴリズムから得らた帯域幅情報を基礎として、エンドユーザのサービス品質を最適化する機能を備えている。

ＳＮＳＤ７は、ＲＮＣからの帯域幅情報を一時的に記憶するように構成されてもよいし、あるいは、プロキシーを介してアプリケーションサーバに直接的に情報を中継するように構成されてもよい。ＵＥは、パケットデータプロトコル（ＰＤＰ）コンテクストをすでに活性化させているときは、このＰＤＰには、アクセス・ポイントの名称（ＡＰＮ）などの他の情報が含まれている。ＡＰＮは、ＵＥとＳＮＳＤとの間の論理的なコネクションを付与するものである。ＳＮＳＤは、ＵＥごとに、例えば、以下の情報を記憶してもよい：
− ＵＥのＩＰアドレス
− ビットレート
− 他の情報（例えば、ユーザのＭＳＩＳＤＮなどであり、本発明のためというよりも、元々他の目的のための情報である。）。

ＳＮＳＤは、エアインタフェース上で現在許可されているビットレートをプロキシーに提供するため、プロキシーは、セグメントサイズやウインドウサイズなどのＴＣＰフロー制御パラメータを無線リソース状況に合うように設定する機能を備えている。

図５は、本発明によってダウンロードまたはウェブサーフィンなどのＴＣＰベースのサービスについて、エンドユーザのＱｏＳを最適化するための例を示すフローチャートである。

図５は、ＴＣＰの適応制御手順を示しており、ＵＥとアプリケーションサーバとの間のＴＣＰリンクを図４に示したＴＣＰコネクション３ａ、３ｂへと、２つの部分に分離している。

図５に示した例についての初期条件は次のとおりである。ステップＳ３１において、ＩＥＴＦによって規格化されたＴＣＰメカニズムにしたがって、アプリケーションサーバが、あるビットレートでペイロードを送信する。エアインタフェース上の限界を超えると、プロキシーは、ペイロードが到着するペースと同様のペースでは、到着したペイロードを中継することは禁止される。したがって、プロキシーは、到着したペイロードを一時的にキャッシュ（不図示）へと記憶し、受信通知（ＡＣＫ）を送信することで、アプリケーションサーバに受信したことを通知する。これは、あたかもペイロードがクライアントによって受信されたかのように行われる。そうすることによって、ＴＣＰの輻輳制御メカニズムが使用されるといったリスクを減少させることができる。同時に、要求されているオブジェクトやファイルについてのトータルでのダウンロード時間を最小限にすることができよう。

本発明によると、以下のステップが図５の例において実行される：
ステップ３２ ： 無線リソース管理ユニット（例えば、ＲＮＣ）は、システムのキャパシティに余裕があることを検出すると、より高速の新しいビットレートを特定のセッションが享受しうることをＳＮＳＤに報告する。
ステップ３３ ： プロキシーは、定期的に、所与のセッション対して現在許可されているトランスポートビットレートについてＳＮＳＤをチェックして取得してもよい。
ステップ３４ ： このケースで、より高いビットレートを所与のセッションに対してＲＮＣが許可することを意味するレスポンスを、プロキシーがＳＮＳＤから取得する。
ステップ３５ ： プロキシー内部の無線ＴＣＰ最適化アルゴリズムが、新しいコンディションに適応する。なお、プロキシーからの出力に関するビットレートは、一時的に到着のビットレートよりも増大されうる。なぜなら、プロキシーは、「古い」ペイロードをキャッシュ内に保持しているからである。
ステップ３６ ： エンドユーザは、新しいビットレートでコンテンツを受信する。

なお、図５は、本発明に係るネットワークフィードバックベースの伝送速度適応処理のスナップショットに過ぎない。図５に示されているプロシージャは、セッション中ずっと、エアインタフェース上で許可されたセッションのビットレートが変更されるたびに何度も適用されることになろう。

図４と図５は、本発明の実施形態を示している。すなわち、プロキシーが使用され、クライアントとアプリケーションサーバとの間のＴＣＰコネクションが２つの部分に分割され、その１つがクライアントとプロキシーとの間の部分であり、もう１つがプロキシーとアプリケーションサーバとの間の部分である。上述したように、プロキシーの使用は有効である。これは、ＴＣＰ輻輳回避メカニズムが使われるという危険を減少しうるからである。しかしながら、上述したように、プロキシーの使用は、本発明にとって必須条件ではない。本発明の代替的な実施形態によれば、図６に示すように、ＴＣＰコネクション３をダイレクトにＵＥからアプリケーションサーバへと張ってもよい。同様に、ＳＮＳＤのような中間のデータベースを使用せずに、帯域幅情報をダイレクトに無線リソース管理ユニットからアプリケーションサーバへと伝達してもよい。プロキシーが使用される場合、図４に示すように、プロキシーはサービスネットワーク１３内またはコアネットワーク１２内に配置されてもよい。

本発明の代替的な実施形態によると、無線リソース管理ユニットからのフィードバック情報は、ＵＥ１を経由して、アプリケーションサーバまたはプロキシーに送信される。より前に説明した実施形態と比較すると、この実施形態での欠点は、フィードバック情報がさらに遅延することは明らかなため、ＵＥからの追加の処理を必要とすることである。クライアントを経由してフィードバック情報をループ処理することの利点は、このような実施形態であれば、既存のプロトコルを多少変更するだけで実現できることである。

無線リソース管理ユニットからのネットワークフィードバックに基づいた伝送速度の適応処理は、エンドユーザに対してサービス品質を提供するための追加の手段として、コンテンツ変換が追加されてもよい。ユーザが大きな画像をダウンロード使用としているときに、当該ユーザが存在しているセルが輻輳していると仮定しよう。ユーザは、おそらく、ダウンロードにかかる時間が長くてイライラするようになって、このようなセッションを切断してしまうおそれがある。切断する代わりに、画像内の幾つかの情報を削減することによってダウンロード速度をスピードアップすることも可能であろう。なお、画像の全部の情報を送信する場合と比較すると、この場合の画像の品質は明らかに劣化するであろう。しかしながら、この待ち時間が与える印象は、エンドユーザが経験するサービス品質の中でも何よりもシビアである。よって、無線リソース管理ユニットからのネットワークフィードバックを用いることで、コンテンツ変換を適用すべきタイミングを正しく決定することができる。

図７は、コンテンツ変換に関連するステップを示す図である。これらのステップは、以下の通りである：
ステップ４１ ： ＵＥ１がアプリケーションサーバ２（例：ＭＭＳサーバ）からのコンテンツを要求する。当該要求は、直接的にまたは間接的にプロキシー４よってキャプチャされる。
ステップ４２ ： プロキシー４は、アプリケーションサーバからコンテンツを取って来る。
ステップ４３ ： ＵＥ１にコンテンツを送信する前に、プロキシー４は、エアインタフェース上でＵＥに対して現在許可しているビットレートがいくつであるかを、ＳＮＳＤ７の中から抽出する。ＵＥに関連付けられているＩＰアドレスは、ＳＮＳＤ内で、ＵＥについてのセッション情報を抽出するため使用される。
ステップ４４ ： 現在許可されているビットレートの情報がプロキシーにおいて受信される。
ステップ４５ ： プロキシー４は、いくつかのＱｏＳアルゴリズムを用い、現在許可されているビットレートの情報を入力として用いることによって、このケースにおいてＵＥ１へと転送するのに先立って、当該コンテンツについてコンテンツ変換が必要かどうかを判定する。上述したように、このようなコンテンツ変換の一例は、伝送時間を短縮するために、画像の情報ビットを削減することがあげられよう。
ステップ４６ ： 必要であれば、コンテンツが変換され、ＵＥ１へと転送される。

本発明に係る無線リソース管理ユニットからのネットワークフィードバック情報をいくつかのセッションについてだけ使用し、他のセッションについては使用しないことには利点があろう。よって、セッションがフィードバックサービスを必要とするかどうかについて、リソース管理エンティティ（例、無線リソース管理ユニット）に通知されるように、本発明を実現してもよい。この通知は、ｉ）コンフィギュレーション（構成）中、またはｉｉ）セッションの設定中に実行してもよい。

上述した本発明の実施形態は、ＵＭＴＳシステムにおいて実現した例である。しかしながら、本発明は、多数の異なるタイプのパケット交換ネットワークにおいて使用可能である。例えば、本発明は、同様に、ＧＳＭシステムのような２Ｇシステムにおいても適用できる。

本発明によれば、伝送速度の適応処理に使用されるネットワークフィードバックを提供する無線リソース管理ユニットは、エアインタフェース上の無線リソースを制御するエンティティである。ＵＭＴＳシステムにおいて、このエンティティは、ＲＮＣに相当し、ＧＳＭシステムにおいては、このユニットがＢＳＣに相当する。無線リソース管理ユニットは、他のタイプのネットワークにおいて他の名称を有していることもあろう。エアインタフェースにおける現在の物理的な限界についての情報や、セル内において無線リソースを奪い合っている継続中の異なるセッションらに関する負荷の情報、および特定のセッションがエアインタフェース上で使用を許可されている帯域に対して影響を及ぼすような他の要因に関する情報を有しているユニットであれば、それは無線リソース管理ユニットに相当しうる。この情報に基づいて、無線リソース管理ユニットは、フィードバックとして通信され帯域幅を決定する。フィードバックは、エアインタフェース上で使用することを許可された所与のセッションの帯域を示すものである。

無線リソース管理ユニットは、アプリケーションサーバまたはプロキシーへとネットワークフィードバックの形式の帯域幅情報をいつ送信するかについては、異なる実現方法の選択肢がある。しかしながら、本発明にとって重要なことは、最良の伝送速度への適応処理を可能とすべく、無線リソースマネージャーがエアインタフェースをモニター（監視）して、セッションの全体を通して継続的に現在許容される帯域幅を報告することである。ここで、継続的にとは、セッション中にエアインタフェース上の無線コンディションが変化したときに伝送速度を適応できるよう、当該セッションの伝送速度に影響を与えるフロー制御パラメータを設定するユニットへと、無線リソースマネージャーが、セッションに対して許可されている帯域幅を報告することを意味する。これは、エアインタフェース上で使用することを許可されたセッションの帯域幅が変更されるたびに、無線リソース管理ユニットがデータベースまたはパラメータ設定エンティティへとネットワークフィードバックを送信することを暗に意味しているといえよう。他の代替案は、無線リソース管理ユニットが、例えば１０秒など、予め定められた間隔で、現在許可されているセッションの帯域幅についての情報を送信することである。後者の代替案についての欠点は、本システムが、許容された帯域幅の変化に適応することに失敗するおそれがあることであろう。

セッションのビット伝送に影響するフロー制御パラメータの適応処理は、無線リソース管理ユニットからの帯域幅情報に基づいて実行される。この目的のために、無線リソース管理ユニットからの帯域幅情報が１つのパラメータとなるような、何らかの種類の最適化アルゴリズムが有効に使用される。最適化アルゴリズムがどのような特徴を有すべきかとか、これをどのように選択すべきかとかは、本発明の範囲外である。パラメータ設定エンティティ（例えば、アプリケーションサーバまたはプロキシー）は、無線リソース管理ユニット主導でネットワークフィードバックを受信してもよいし、ＳＮＳＤのような中間にあるデータベースや、無線リソース管理ユニット自身から当該情報を要求してもよい。パラメータ設定エンティティは、好ましくは、許可された帯域幅の変化を検出次第、エアインタフェース上の伝送速度に影響を及ぼすフロー制御パラメータらを更新することになろう。

本発明によると、フロー制御パラメータの適応処理は、無線リソース管理ユニットから受信した帯域幅情報に依存して、伝送速度を上昇させるように切り替えることもできるし、低下させるように切り替えることもできる。受信された帯域幅情報は、利用可能な帯域幅の観点から適切となるように、伝送速度を上昇させたり低下させたりできる。本発明によれば、従来の解決法よりも、伝送速度の適応処理をスムーズに実行できる。伝送速度をよりスムーズに低下させることで、輻輳回避メカニズムが多数にわたって適用されることを回避できる。上述したように、輻輳回避メカニズムは、サービス品質に対して有害な影響をもたらすおそれがある。このように本発明は、無線コンディションに打ち勝ち、より良く、かつより平等なサービス品質をエンドユーザに対して与えるように、伝送速度をより正確に適応させることを可能にする。

本発明によって、ＲＮＣやＢＳＣなどの無線リソース管理ユニットのバッファーサイズを削減することができる。伝送速度がより素早くかつより正確に利用可能な帯域幅へと適応されるとき、無線リソース管理ユニット内のオーバーフローのリスクが低減されるので、これが可能となる。例えば、ＲＮＣが利用可能な帯域幅を６４Ｋｂ／ｓから３２Ｋｂ／ｓへと削減することを指示されたと仮定する。ネットワークフィードバックを用いない場合、ＲＮＣがエアインタフェースに対して３２Ｋｂ／ｓで信号を供給しているにもかかわらず、アプリケーションサーバまたはプロキシーがしばらくの時間は６４Ｋｂ／ｓで信号を送信し続けるというリスクが存在する。これによって、アプリケーションサーバまたはプロキシーが伝送速度を調整するようになるまで、ＲＮＣのバッファにはデータが蓄積されていく。もしバッファが満杯になれば、ＲＮＣはデータの廃棄を強制されることになり、また、廃棄されたデータについては再送しなければならなくなる。ネットワークフィードバックを用いれば、アプリケーションサーバまたはプロキシーは、利用可能な帯域幅を削減しなければならないことをより速く認識し、速やかに伝送速度を低下させることができる。このように本発明によるネットワークフィードバックが使用されるときは、ＲＮＣが、より小さいバッファを備えるだけでよいことになる。

上述したように本発明は、輻輳回避メカニズムが使われるリスクを削減しうるものである。輻輳回避メカニズムは、ＩＦＴＦによって規定されているように、ＴＣＰの必要条件である。オペレーターのドメイン内のコネクションについて、オペレーターは、インターネットに関するＩＦＴＦの必要条件のいくつかを無効化（ディスエイブル）することを選択してもよいことになっている。従って、本発明が使用されるときは、オペレーターが、輻輳回避メカニズムを完全に無効化し、プロキシーとＵＥとの間に改良されたＴＣＰコネクションを採用することを選択しうる。これによって、改良されたＴＣＰコネクションについてのパラメータの設定をより大胆に実行できるようになる。

既存のシステムに対して本発明を適用するときは、当業者であれば理解できるように、既存のソフトウエアまたは既存のハードウエアの少なくとも一方を修正しなければならないだろう。大抵の場合、主にソフトウエアを中心とした修正になるであろう。無線リソース管理ユニットは、本発明にかかるネットワークフィードバックを、ＳＮＳＤなどの他のユニット、プロキシーまたはアプリケーションサーバと通信できるように適合させなければならない。図４に示した実施形態によれば、レートの情報をＳＮＳＤに伝送する方法の１つは、ＲＮＣとＧＧＳＮとの間に確立されたＧＴＰ−Ｕトンネルを使用することである。しかしながら、これは、ＧＧＳＮに機能を追加することが必要となる。もう１つのアプローチは、ｉ）コンフィギュレーション、またはｉｉ）セッションの設定の際に、ＳＮＳＤのＩＰアドレスを直接的にＲＮＣへと報告してもよい。そうすることによって、ＲＮＣは、中間のノードからの問い合せを受信することなく、有効なビットレートについてＳＮＳＤを更新することができる。さらに、本発明に従ってネットワークフィードバックに基づきセッションパラメータを更新する、パラメータ設定ユニットは、ネットワークフィードバックを受信して解釈し、かつ、受信したネットワークフィードバックに基づいて当該パラメータを適合させることができるように構成されなければならない。既知のハードウエアやソフトウエアなどの手段を用いて本発明をどのようにして実現するかについては当業者であれば理解できよう。本発明によるネットワークフィードバックメカニズムは、この目的のために作成された他の個別のプロトコルを使って実行されてもよい。

明細書および図面において、本発明の典型的かつ好適な実施形態について開示してきたが、そこで使用した特定の用語は、一般的に使用されているものであり、限定の目的で使用しているわけではない。本発明の範囲は、添付の特許請求の範囲によって確定されることに他ならない。

図１は、従来技術に係るクライアントとアプリケーションサーバとの間に確立された通信セッションを示す図である。 図２は、本発明に係るクライアントとアプリケーションサーバとの間に確立された通信セッションを示す図である。 図３は、図１および図２に示したセッションのスループットを比較した図である。 図４は、本発明に係るＵＭＴＳシステムの実施形態を示す図である。 図５は、本発明に係るネットワークフィードバックに基づいた伝送速度の適応処理を示すフローチャートである。 図６は、本発明に係るＵＭＴＳシステムの他の実施形態を示す図である。 図７は、本発明に係るネットワークフィードバックに基づいたコンテンツ変換処理を示すフローチャートである。

Claims (29)

1. アプリケーションサーバ（２）からクライアント（１）へとデータ情報を送信するためのビット転送セッションにおいてデータビットの送信を制御する方法であって、前記ビット転送セッションはフロー制御メカニズムを有するトランスポートプロトコルによって無線通信回線を介してビットを転送することに関与するものであり、
   前記方法は、
   ネットワークエンティティ（２，４）において、前記ビット転送セッションを通して継続的に、前記ビット転送セッションが現在のところ使用することを許可されている無線通信回線についての帯域幅に関する情報を無線リソース管理ユニット（６）から受信するステップ（３２，３４）と、
   前記ネットワークエンティティにおいて、前記受信した情報にしたがって前記ビット転送セッションの伝送速度を制御するために、前記受信した情報に応じて前記トランスポートプロトコルの前記フロー制御メカニズムに関連する少なくとも１つのパラメータを更新するステップ（３５）と
   を含むことを特徴とする方法。
2. 前記ネットワークエンティティ（２，４）において、前記ビット転送セッションが使用することを許可された帯域幅が変更されるたびに、前記無線リソース管理ユニット（６）から前記情報を受信することを特徴とする請求項１に記載の方法。
3. 前記ネットワークエンティティ（２，４）において、予め定められた時間間隔ごとに、前記無線リソース管理ユニット（６）から前記情報を受信することを特徴とする請求項１に記載の方法。
4. 前記ネットワークエンティティが前記アプリケーションサーバ（２）であることを特徴とする請求項１ないし３の何れかに記載の方法。
5. 前記ネットワークエンティティがプロキシー（４）として動作することで、該プロキシー（４）を経由して、前記アプリケーションサーバ（２）と前記クライアント（１）との間で前記ビット転送セッションを設定することを特徴とする請求項１ないし３の何れかに記載の方法。
6. 前記プロキシー（４）において、前記ビット転送セッション中に前記アプリケーションサーバ（２）から受信したパケットについての受信通知を送信するステップを含み、前記受信通知は、前記無線リソース管理ユニットから受信した前記情報とは独立していることを特徴とする請求項５に記載の方法。
7. 前記ネットワークエンティティ（２，４）において、前記無線リソース管理ユニットからの前記情報を、前記クライアント（１）を経由して、受信することを特徴とする請求項１ないし６の何れかに記載の方法。
8. 前記トランスポートプロトコルは、ＴＣＰであることを特徴とする請求項１ないし７の何れかに記載の方法。
9. 前記少なくとも１つのパラメータは、ＴＣＰのウインドウサイズまたはＴＣＰのセグメントサイズの少なくとも一方であることを特徴とする請求項８に記載の方法。
10. 前記無線リソース管理ユニット（６）から受信した前記情報に応じて、前記ビット転送セッション中に、送信対象のデータを変換するステップをさらに含むことを特徴とする請求項１ないし９の何れかに記載の方法。
11. 前記ビット転送セッションによって利用される前記無線通信回線についての前記帯域幅を増加または減少させるように前記少なくとも１つのパラメータを更新することを特徴とする請求項１ないし１０の何れかに記載の方法。
12. 前記無線リソース管理ユニットは、無線ネットワーク制御装置（６）であることを特徴とする請求項１ないし１１のいずれかに記載の方法。
13. 前記無線リソース管理ユニットは、基地局制御装置であることを特徴とする請求項１ないし１１のいずれかに記載の方法。
14. デジタルコンピュータ装置のメモリにロード可能なコンピュータプログラムであって、
    前記コンピュータプログラムが前記デジタルコンピュータ装置において実行されると、請求項１ないし１３の何れかに記載の方法を実行するソフトウエアコード部を含むことを特徴とするコンピュータプログラム。
15. アプリケーションサーバ（２）からクライアント（１）へとデータ情報を送信するためのビット転送セッションにおいてデータビットの送信を制御する装置であって、前記ビット転送セッションはフロー制御メカニズムを有するトランスポートプロトコルによって無線通信回線を介してビットを転送することに関与するものであり、
    ネットワークエンティティ（２，４）に含まれる前記装置は、
    前記ビット転送セッションを通して継続的に、該ビット転送セッションが現在のところ使用することを許可されている無線通信回線についての帯域幅に関する情報を無線リソース管理ユニット（６）から受信する受信手段と、
    前記受信した情報にしたがって前記ビット転送セッションの伝送速度を制御するために、前記受信した情報に応じて前記トランスポートプロトコルの前記フロー制御メカニズムに関連する少なくとも１つのパラメータを更新するパラメータ設定手段と
    を含むことを特徴とする装置。
16. 前記受信手段は、前記ビット転送セッションが使用することを許可された帯域幅が変更されるたびに、前記無線リソース管理ユニットから前記情報を受信することを特徴とする請求項１５に記載の装置。
17. 前記受信手段は、予め定められた時間間隔ごとに、前記無線リソース管理ユニット（６）から前記情報を受信することを特徴とする請求項１５に記載の装置。
18. 前記受信手段と前記パラメータ設定手段とが前記アプリケーションサーバ（２）に含まれていることを特徴とする請求項１５ないし１７の何れかに記載の装置。
19. 前記受信手段と前記パラメータ設定手段とを含むプロキシー（４）を経由して、前記アプリケーションサーバ（２）と前記クライアント（１）との間に前記ビット転送セッションが設定されることを特徴とする請求項１５ないし１７の何れかに記載の装置。
20. 前記プロキシー（４）は、前記ビット転送セッション中に前記アプリケーションサーバ（２）から受信したパケットについての受信通知を送信するように構成されており、前記受信通知は、前記無線リソース管理ユニットから受信した前記情報とは独立していることを特徴とする請求項１９に記載の装置。
21. 前記受信手段は、前記無線リソース管理ユニット（６）からの前記情報を、前記クライアント（１）を経由して、受信することを特徴とする請求項１５ないし２０の何れかに記載の装置。
22. 前記トランスポートプロトコルは、ＴＣＰであることを特徴とする請求項１５ないし２１の何れかに記載の装置。
23. 前記少なくとも１つのパラメータは、ＴＣＰのウインドウサイズまたはＴＣＰのセグメントサイズの少なくとも一方であることを特徴とする請求項２２に記載の装置。
24. 前記無線リソース管理ユニットから受信した前記情報に応じて、前記ビット転送セッション中に、送信対象のデータを変換する変換手段をさらに含むことを特徴とする請求項１５ないし２３の何れかに記載の装置。
25. 前記パラメータ設定手段は、前記ビット転送セッションによって利用される前記無線通信回線についての前記帯域幅を増加または減少させるように前記少なくとも１つのパラメータを更新することを特徴とする請求項１５ないし２４の何れかに記載の装置。
26. 前記無線リソース管理ユニットは、無線ネットワーク制御装置（６）であることを特徴とする請求項１５ないし２５のいずれかに記載の装置。
27. 前記無線リソース管理ユニットは、基地局制御装置であることを特徴とする請求項１５ないし２５のいずれかに記載の装置。
28. フロー制御メカニズムを有するトランスポートプロトコルによって無線通信回線を介してビットを転送することに関与するビット転送セッションにおいてデータビットの送信を制御するシステムであって、
    請求項１５ないし２５の何れかに記載の装置を含み、
    前記無線リソース管理ユニット（６）は、前記ビット転送セッションを通して継続的に、該ビット転送セッションが現在のところ使用することを許可されている無線通信回線についての帯域幅に関する情報を送信することを特徴とするシステム。
29. 記憶ユニット（７）をさらに含み、
    前記無線リソース管理ユニット（６）は、前記記憶ユニットを経由して前記装置へと前記情報を送信するように構成されており、前記記憶ユニットは、前記無線リソース管理ユニットからの前記情報を前記装置へと中継するように構成されていることを特徴とする請求項２８に記載のシステム。

Images