通信装置および通信システム
【課題】システムスループット向上とシステムQoE(Quality of Experience)向上の両立を図るリソース制御が可能な通信装置およびシステムを提供する。
【解決手段】無線基地局2などの通信装置のスケジューラ23にて、上り又は下りの割当て無線リソースとユーザQoEとの関係を示すQoE関数情報40を管理し、割当てリソースから算出した予測QoEが一定値以上のユーザが保持する余剰リソースを、予測QoEが一定値以下のユーザに譲渡することを繰り返すことにより、システムQoE向上とシステムスループット向上の両立を図る。
【解決手段】無線基地局2などの通信装置のスケジューラ23にて、上り又は下りの割当て無線リソースとユーザQoEとの関係を示すQoE関数情報40を管理し、割当てリソースから算出した予測QoEが一定値以上のユーザが保持する余剰リソースを、予測QoEが一定値以下のユーザに譲渡することを繰り返すことにより、システムQoE向上とシステムスループット向上の両立を図る。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は通信装置のリソース制御方式に関し、特に資源が逼迫した状況において、システム全体でユーザの体感品質(Quality of Experience：QoE)の低下を抑止する技術に関する。
【背景技術】
【０００２】
近年、無線通信が高速化したことに伴い、モバイル端末からインターネット上の様々なサービスを利用できるようになった。これらサービスの中には、例えば映像配信のように広帯域を利用するものがある一方、地震速報のようにデータサイズは小さいが高信頼・低遅延を要求するものもある。また、Webのようにバースト的に通信を行うものもあれば、音声通話のように常に一定の帯域を使用するものもある。さらに将来的には無線を利用した遠隔医療やロボット制御など通常のデータ通信よりもミッションクリティカル性の高いアプリケーションの開発も見込まれており、今後は無線システム上で様々な特性のトラフィックを同時に伝送するようになる。このため、無線システムにおけるQoS(Quality of Service)やQoEの向上が重要な課題になる。
【０００３】
無線システムのQoSやQoEに関わる要素技術として、無線基地局におけるリソース制御方式がある。無線システムでは一般的に有線区間と無線区間の速度差が大きく、無線基地局におけるリソース制御方式がシステム性能に大きな影響を与えるため、これまでも様々なリソース制御方式が提案されてきた。例えば、従来の無線リソース制御技術において基礎的な機構と位置付けられるPF (Proportional Fairness)がある(非特許文献1参照)。このPFは、システムスループット向上とユーザ間の公平性という、相反する目的を両立させるための機構である。
【０００４】
一方、上記のPFのようにシステムスループット向上を目指すのではなく、ユーザの体感品質であるQoEに着目したソース制御方式として、特許文献1が知られている。特許文献1では、双方向映像通信サービスにおいて品質制御後のユーザ体感品質の予測値（予測品質値）を算出し、予測品質値と現在の品質推定値との差分を品質向上値とし、この品質向上値の高い順に優先して品質制御を行うことにより、効果的にサービス全体のQoE向上を図る構成が述べられている。なお、特許文献1には、帯域などのリソース割当てや無効パケット率等の通信品質と、ユーザ体感品質の関係(以下、QoE関数と呼ぶ)のグラフが示されている。このようなグラフは、専用の試験設備において多数のユーザが試験データを採点することにより取得される。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００７−２２１３１８号公報
【非特許文献】
【０００６】
【非特許文献１】F. Kelly, “Charging anｄ rate control for elastic traffic,” European Transactions on Telecommunications, vol. 8, no. 1, pp.33-37, January 1997.
【発明の概要】
【発明が解決しようとする課題】
【０００７】
無線環境では電波状況がよいほどスループットが大きくなるため、システムスループットを最大化するためには電波状況の良いユーザにリソースを割当てるのが得策である。しかし、それではユーザ間の公平性が保てないことから、PFでは次式（１）を用いて転送スロットnにおけるユーザmのリソース割当て優先度Mm(n)を計算する。
【０００８】
【数１】
【０００９】
ここでRm(n)はその転送スロットにおけるユーザmの最大スループットであり、Tm(n)は一定区間におけるユーザmの平均スループットである。本式に従うと、一時的に大量のリソースを使用したユーザは分母のTm(n)が大きくなるため、結果として次の瞬間の割当て優先度Mm(n)が小さくなる。一方、しばらくリソースを使わなかったユーザは、分母のTm(n)が小さくなり徐々に割当て優先度Mm(n)が大きくなる。このため、PFは平均スループットに対して瞬間的に無線リンク状態が良いユーザに転送スロットを割当てることにより、ユーザ公平性を損なわない範囲でシステムスループットの向上を図る方式といえる。
【００１０】
上述したPFによるスケジューリングでは、ユーザ公平性とシステムスループットの向上のために、瞬間的な電波状況と平均スループットを考慮した制御を行うが、このような制御では上述したユーザQoEを考慮したリソース配分を行っていないため、リソース状況がそれほど逼迫していなくてもユーザQoEが低下してしまう可能性がある。
【００１１】
例えば、PFを単純化したシミュレーションの例として、基地局スループットを各ユーザの受信信号強度(Receive Signal Strength Inｄicator：RSSI)で比例配分すると仮定した場合の結果を図10に示す。図10の横軸は基地局に接続するユーザを示し、縦軸はスループット充足率と平均QoEを示している。ここでQoEは各ユーザ毎に0(不満足)〜1.0(満足)の値を取り、後で説明するようにスループットとの関係はアプリケーションやコンテンツごとに異なるグラフになると仮定している。またスループット充足率は次式で計算している。
【００１２】
【数２】
【００１３】
図10から分かるように、PFのように電波状況に応じたスケジューリングを行うと、スループット充足率が100%以上であるにも関わらずユーザのQoEが低下し始めている。これは、リソース状況がそれほど逼迫していなくてもユーザQoEが低下してしまうという問題を示している。
【００１４】
一方で、特許文献1のようにQoEの品質向上値のみに着目した制御を行う場合、QoEの観点では最適化されるものの、その他の観点で不都合が起きる可能性がある。例えば特許文献1では、サービスの優先度について考慮していないため、動画像配信や電話等の複数のサービスが共存するマルチサービス環境において、優先度の高い電話サービスよりも優先度の低い動画像配信サービスに優先してリソースが与えられる可能性がある。また、特許文献1では、主に有線網への適用を想定しており、無線網における電波利用効率について考慮していないため、QoEに基づくリソース制御を行った結果としてシステムスループットが低下してしまう可能性がある。さらに、特許文献1ではQoE観点でのユーザ公平性について考慮されておらず、QoEの向上が見込める端末のみをリソース制御対象とするため、ユーザの不公平感が増大してしまう可能性もある。
【００１５】
本発明はこのような背景に鑑みなされたものであり、システムQoE向上とサービス優先度の両立を図る、QoE向上とシステムスループット向上の両立を図る、あるいはQoE観点でのユーザ間公平性を図るリソース制御が可能な通信装置および通信システムの提供を目的とする。
【課題を解決するための手段】
【００１６】
上記の目的を達成するため、本発明においては、端末及び他の装置との間でデータを送受信するための通信装置であって、端末及び他の装置と接続されるネットワークインタフェースと、ネットワークインタフェースから受信したパケットをフロー毎に蓄積する記憶部と、記憶部に蓄積された各フローに対するリソース割当てを決定するスケジューラを備え、このスケジューラは、リソース割当てとユーザQoEとの関連を示すQoE関数を管理し、リソース割当てを決定する際に、必要なリソースと通信装置のリソースから不足リソースを求め、不足リソースが零になるまで、QoE変化率とサービス優先度の和又は積が最も小さいフローへのリソース割当てを所定量だけ減少させ、所定量だけ減少させたフローのQoEが所定の閾値以下になるフローのリソースを零とする処理を繰り返す通信装置および通信システムを提供する。
【００１７】
また、上記の目的を達成するため、本発明においては、端末及び他の装置との間でデータを送受信するための通信装置であって、端末及び他の装置と接続されるネットワークインタフェースと、ネットワークインタフェースから受信したパケットをフロー毎に蓄積する記憶部と、記憶部に蓄積された各フローに対してリソース割当てを決定するスケジューラを備え、スケジューラは、リソース割当てとQoEとの関連を示すQoE関数を管理し、各フローに対するリソース割当てを決定する際に、電波利用効率にもとづくリソース割当てを行った後、割当てたリソースによって予測QoEを計算し、フロー各々を、予測QoEが一定値αを超える第一のフローと、一定値を超えない第二のフローとに分類し、第一のフローが保持する余剰リソースの総和を、割当てたリソースとQoEが一定値となるリソースとの差分として計算し、この余剰リソースの総和が閾値以下になるか、または第二のフローが無くなるまで、第二のフローの中で最も電波状況の良いものに対して、QoEが一定値となるまで余剰リソースを分け与える処理を繰り返す通信装置および通信システムを提供する。
【００１８】
さらに上記の目的を達成するため、本発明においては、端末及び他の装置との間でデータを送受信するための通信装置であって、端末及び他の装置と接続されるネットワークインタフェースと、ネットワークインタフェースから受信したパケットをフロー毎に蓄積する記憶部と、記憶部に蓄積された各フローに対してリソース割当てを決定するスケジューラを備え、スケジューラは、リソース割当てとQoEとの関連を示すQoE関数を管理し、フロー各々に対するリソース割当て量決定する際に、フロー全体を満足させるために必要なリソースの総和と通信装置のリソースから不足リソースを算出し、不足リソースが所定閾値以下になるまで、各フローのQoEを一定量だけ減少させるようリソース割当てを減らしていく通信装置および通信システムを提供する。
【発明の効果】
【００１９】
本発明によれば、システムQoE向上とサービス優先度の両立、システムQoE向上とシステムスループット向上の両立、あるいはQoE観点でのユーザ間公平性を実現する通信装置および通信システムを提供することが可能になる。
【図面の簡単な説明】
【００２０】
【図１】第１の実施例に係る、基地局の装置構成例を示す図である。
【図２】第１の実施例に係る、ネットワーク構成の一例を示す図である。
【図３Ａ】第１の実施例に係る、QoE関数管理部が備えるQoE関数情報を例示する図である。
【図３Ｂ】第１の実施例に係る、スケジューラが備えるベアラリソース管理テーブルの一例を示す図である。
【図４】第１の実施例に係る、システムQoE向上とサービス優先度の両立を図るスケジューリングアルゴリズムの一例を示すフロー図である。
【図５】第１の実施例に係る、QoE関数情報を設定するコールフローの例1。
【図６】第１の実施例に係る、QoE関数情報を設定するコールフローの例2。
【図７】第１の実施例に係る、QoE関数情報を設定するコールフローの例3。
【図８】第１の実施例に係る、システムQoE向上とシステムスループット向上の両立を図るスケジューリングアルゴリズムを示す図である。
【図９】第１の実施例に係る、QoE観点でのユーザ間公平性を図るスケジューリングアルゴリズムを示す図である。
【図１０】従来技術に基づくスケジューリングを行う場合のQoE平均値を示す図である。
【図１１】第１の実施例に係る、サービス優先度管理テーブルの構成例を示す図である。
【図１２】第１の実施例に係る、予測スループット換算テーブルの構成例を示す図である。
【発明を実施するための形態】
【００２１】
以下、図面を用いて本発明の種々の実施例を説明する。なお以下では、主に無線通信装置および無線通信システムとしての基地局の無線の下りスケジューリングについて説明するが、本発明はこれに限定されず、基地局の無線の上りスケジューリングや、スケジューリングを行う他の有線通信装置などについても適用可能である。
【実施例１】
【００２２】
実施例1では、システムQoE向上とサービス優先度の両立を図る無線基地局における制御装置及びシステムの例を示す。本実施例においては、QoE関数およびサービス優先度に基づいて、各フローに割当てるリソースを決定することを特徴とする。
【００２３】
すなわち、各フローに対して割当てるリソース量を決定する際に、まず全フローを満足させるのに必要なリソースの総和を計算し、次に不足リソースをリソース総和と通信装置リソースとの差分として計算し、次に不足リソースが零になるまで、QoE変化率とサービス優先度の和又は積が最も小さいフローへのリソース割当てを所定量だけ減少させ、またリソース割当てを所定量だけ減少させたときにQoEがある閾値以下になるフローへのリソース割当てを零まで減少させる処理を繰り返すことにより、各フローへのリソース割当てを決定する。
【００２４】
ここで、QoE変化率とは、リソース変化に対するQoE変化の割合を示すQoE関数の傾きである。また、サービス優先度とは各サービスに対する優先度を示し、基地局のオペレータにより数値化され、図11に示すサービス優先度管理テーブル600のような形式で管理されるとする。図11では、重要なサービスに対してより大きな数値を割当ており、例えばサービス優先度が3.0の電話サービス(Voice001)は、サービス優先度が2.0の動画像配信サービス(Streaming001)よりも1.5倍重要であることを示している。
【００２５】
図2は本実施例が適用されるネットワークの全体構成の一例を示す図である。図2において、1は無線インタフェースを備えた端末を示し、2は端末1と無線インタフェースにより通信を行う通信装置としての基地局を示し、3は基地局2から受信したデータを適切なサービス網に振り分けるゲートウェイを示し、4はIP（Internet Protocol）電話やWeb、映像配信等のサービス種別毎に設けられるサービス網を示し、5はサービス網4に接続され端末1と通信を行う他の通信装置であるサーバを示す。本実施例のリソー制御の機能は基地局2の制御機能に対応し、特に基地局2にて実施する無線区間のスケジューリングアルゴリズムに関する。サーバ5とは、通常のネットワークインタフェースを有するコンピュータで構成されている。
【００２６】
以下、図1を用いて本実施例の基地局2の構成とパケット転送処理について詳しく説明する。図1において、25はゲートウェイ3と通信するためのNIF (Network Interface)を示し、26は基地局2が送受信するパケット、および各種テーブル情報を記憶する記憶部であるメモリを示し、24はメモリ26に一次蓄積されたパケットに対して、無線アクセス網のプロトコル処理を施すプロトコル処理部を示す。また、23はメモリ26に蓄積されたパケットの送受信タイミングを計算するスケジューラを示す。22はパケットを符号化または復号化する符号化/復号化部を示し、21は端末に信号を送信するアンテナを示す。なお、スケジューラ23とプロトコル処理部24は、例えば、基地局2内で各種のプログラムが記憶されたメモリ26と協同し、これらのプログラムを実行する処理部として機能する。通常のコンピュータの中央処理部（Central Processing Unit：CPU）などで構成することができる。一方、符号化／復号化部22とNIF25は、通常ハードウェアで構成される。
【００２７】
基地局2は、ゲートウェイ3から受信した下りパケットを先ずメモリ26内のバッファエリアに蓄積し、プロトコル処理部24にてプロトコル処理を行った後、メモリ26にて管理されるベアラ単位、ユーザ単位、あるいはアプリケーション単位などのフロー各々に対応するキューにプロトコル処理後のパケットを登録する。なお、以下の説明においては、上記のフローとして、ベアラ単位を例示して説明することにする。スケジューラ23は、パケットキュー30からパケットを取りだして符号化/復号化部22へ書き込む。符号化/復号化部22は書き込まれたパケットを符号化してアンテナ21へ送出する。
【００２８】
逆に、端末1から基地局2へ向かう上りパケットは、基地局2のスケジューラ23が決定したタイミングで図１の端末1から送信される。基地局2は、端末1からのパケットをアンテナ21で受信するとまず符号化/復号化部22で復号化し、メモリ26のバッファエリアに書き込む。メモリ26上のパケットは、プロトコル処理部24にてプロトコル処理が施された後、NIF25を介してゲートウェイ3に送信される。
【００２９】
この中で本実施例のリソース制御に関わる処理は、スケジューラ23にて実施されるスケジューリング処理であり、より具体的にはメモリ26上にある各種テーブルを参照して上述した各ベアラに対して割当てるスロット数などの無線リソース量を決定する処理である。
【００３０】
次に、図3A、図3B、図11及び図12を用いてメモリ26にて管理される各種テーブルの一具体例について説明する。
【００３１】
図3Aは、メモリ26にて管理される種々のQoE関数情報40の一構成例を示す。図3Aに示すように、QoE関数情報40はサービス種別毎にリソースとユーザQoEの関係を示すグラフである。ここで、グラフ横軸のリソースとは例えばベアラに割当てるスロット数であってもよいし、このほかにもスループット、遅延、パケットロス率、ジッタ等の通信品質パラメータであってもよい。本実施例では先ず単純な例にてその動作原理を示すために、QoE関数情報40が帯域とQoEの関係を管理するものと仮定する。図３Aの各グラフにおいて、横軸がリソースである帯域、縦軸がQoEを示している。QoE関数情報40の各グラフの傾きはリソース変化に対するQoEの変化の割合、即ちQoE変化率を示しており、この傾きが急であるほど、ユーザの体感品質に対する要求が厳しいことを示していると言える。
【００３２】
図3Bは、メモリ26にて管理されるベアラ管理テーブル50の一構成例を示す。図3Bのテーブルにおいて、51はベアラ識別子(Iｄentifier：ID)を示し、52は該ベアラを利用するアプリケーションのサービス種別を示し、53は端末1から報告される該ベアラの信号強度を示し、54は該ベアラに対して瞬間的に割当てるリソース量(スロット数)を示している。なお、各ベアラID0001、0002、0003のサービス種別52は、図3Aの中央部、右側部、左側部に図示した、Voice001、Web001、Streaming001にそれぞれ対応している。
【００３３】
図11は、メモリ26にて管理されるサービス優先度管理テーブル600の一構成例である。図11のテーブルにおいて、601は上記のサービス種別を示し、602はサービス優先度を表わす数値を示す。なお、サービス優先度602は、先に述べたように値が大きいほど優先度が高いものとする。図11の例では、Voice001、Streaming001、Web001の順に優先度が設定されている。
【００３４】
図12は、メモリ27にて管理される予測スループット換算テーブル700の一構成例を示す。図12のテーブルにおいて、701は信号強度を示し、701は該信号強度における1スロットあたりの予測スループットである予測帯域(bps)を示す。
【００３５】
図１の基地局2におけるスケジューラ23は、上記で説明した各種テーブルを参照して各ベアラに割当てるスロット数を決定し、図3Bの割当てスロット数54に設定する。本実施例の基地局2においては、スケジューラ23におけるスケジューリング処理において、各ベアラのパケットに対して、図3AのQoE関数情報40を参照してリソースを割当てる点が特徴となる。
【００３６】
以下、図4を用いて本実施例におけるリソース制御を行うスケジューラ23のスケジューリングアルゴリズム100を説明する。なお、図4、図8、図9に示すスケジューリングアルゴリズムは上述したCPUで実行されるプログラムで実現できる。
【００３７】
はじめに、スケジューラ23はQoE=1.0とするのに必要なリソースを各ベアラに対して割当て、図3Bのリソース割当て54に設定する(ステップ101、以下括弧内ステップ省略)。ここでQoE=1.0とするのに必要なリソースとは、次式で計算する。
【００３８】
【数３】
【００３９】
ここで、右辺の(QoE=1.0とするのに必要な帯域)は、図3Bのサービス種別52および図3AのQoE関数情報40から取得する。また、右辺の(該信号強度におけるスロットあたりの予測帯域)は図3Bの信号強度53と、図12の予測スループット換算テーブル700から取得する。
【００４０】
次に、全ベアラのリソースの総和を計算した後(102)、次式を用いて不足リソースDを計算する(103)。
【００４１】
【数４】
【００４２】
ここで基地局リソースとは、1台の基地局が保持するリソースの総和、すなわち、単位時間当たりの総スロット数を示す。次に、不足リソースDが正の値である間、図4のループ104〜110の処理を繰り返す。ループ104〜110では先ず、リソースを所定量Δだけ減らした時の、リソース変化に対するQoE変化率であるQoE関数の傾きとサービス優先度の和または積が最も小さいベアラへのリソース割当てをΔだけ減少させた後(105)、不足リソースDをΔだけ減少させる(106)。ここで所定量Δは予めパラメータとして設定された値であり、サービス優先度は上述したように図11にて管理される値である。
【００４３】
次に、リソースをΔだけ減少させたときに該ベアラのQoEがある閾値(a)以下になるかどうかを判定する(107)。ある閾値(a)以下にならない場合はステップ108〜109をスキップして次のループに入る。QoEがある閾値(a)以下になる場合は該ベアラのリソースαを0まで減少させるとともに(108)、不足リソースをαだけ減少させてから(109)、次のループに入る。
【００４４】
なお、上記ステップ105の処理においてQoEの減少を見積もるためには、あるリソースが与えられた時の予測QoEを計算する必要がある。この見積もりは、まず次式を用いて予測帯域を計算した後、予測帯域を図3AのQoE関数に代入することにより行われる。
【００４５】
【数５】
【００４６】
以上でスケジューリングアルゴリズム100の処理を終了する。スケジューリングアルゴリズム100においてステップ105〜106の処理を行うことにより、本実施例の目的とするシステムQoE向上とサービス優先度の両立を達成することができる。また、ステップ108〜109の処理を行うことにより、不要なスループット割当てを無くして効率的なリソース配分を行うことができる。
【００４７】
次に、図5〜7の各動作例を用いて図3Bのベアラ管理テーブル50に各ベアラのサービス種別52を登録する処理を説明する。これらの処理を通して、図3Bベアラリソース管理テーブルのサービス種別52の項が設定される。
【００４８】
図5は、ベストエフォートトラフィックが使用するデフォルトベアラにて、HTTP (Hypertext Transfer Protocol)通信を行う場合の動作例を示す。初めに、端末1と基地局2、ゲートウェイ3の間にはデフォルトベアラが確立されている(201)。端末1は、サーバ5に対してコンテンツ要求(HTTP GET)を送信し(202)、サーバ5はこれに対してコンテンツ応答(HTTP 200 OK)を返信する。このとき、基地局2は転送パケットの内容をスヌープし、サーバ側のポート番号が80番であることなどから通信プロトコルがHTTPであると推測して、サービス種別が例えば図3Aの”Web001”であると判断する。ここでプロトコル種別よりもさらに細かな分類を行うために、転送パケット中の、サーバ側のIPアドレスやHTTPヘッダ情報、更にはHTML (Hyper Text Markup Language)の内容等を参照してもよい。そして基地局2は、判断したサービス種別に基づき転送パケットに対して図4で述べたスケジューリングを適用する。
【００４９】
本実施例においては、図5のコールフローのように、基地局2は、端末が送受信するアプリケーションデータをスヌープして自動的に図3Bのサービス種別52を推定することにより、既存のネットワーク設備に影響を与えることなくアプリケーションに適した高度なスケジューリングを行うことが可能になる。
【００５０】
図6は、個別のアプリケーション用に設定される専用ベアラにて、ストリーミングを視聴する場合の動作例を示す。初めに、端末1と基地局2、ゲートウェイ3の間にはデフォルトベアラが確立されている(211)。端末1は先ずデフォルトベアラを用いてサーバ5にコンテンツリスト要求を送信する(212)。これに対しサーバ5はコンテンツリストを含む応答を返信する(213)。端末1のユーザはコンテンツリストからコンテンツを選択し、ストリーミングファイルへのリンクを含むメタファイルをサーバ5に要求する(214)。サーバ5はメタファイルを返信するとともに、そのストリーミングの視聴に必要なQoSパラメータやコーデックを端末1に通知する(215)。端末１は、ストリーミングアプリケーションを起動し(216)、専用ベアラ確立指示をゲートウェイ3に送信する(217)。専用ベアラ確立指示217にはステップ215で端末1に通知されたQoSパラメータやコーデックの情報が設定される。
【００５１】
ここでコーデック情報を通知する理由は、コーデックによって図3Aで示したQoE関数が異なる可能性があるためである。ゲートウェイ3は、専用ベアラ確立指示217に含まれるQoSパラメータやコーデックの情報に基づき、専用ベアラ確立要求218を送信する。専用ベアラ確立要求218は基地局2を経由して端末1に到達する。このとき基地局2は、専用ベアラ確立要求218のQoSパラメータやコーデック情報からサービス種別を決定し、ベアラとの対応付けを図3Bのベアラ管理テーブルに設定する(219)。最後に、ステップ218に対する専用ベアラ確立応答220が返信され、アプリケーション通信(ストリーミング)が開始される(221)。
【００５２】
なお、上記コールフローにおいてベアラ確立指示217およびベアラ確立要求218にコーデック情報を設定することは本実施例のシステムの独自の仕様であり、メッセージ中に専用の拡張フィールドが必要になる。例えば、無線種別として3GPP(3rｄ Generation Partnership Project) LTE(Long Term Evolution)を想定する場合には、ベアラ確立指示217はTS 24.301に記載のBEARER RESOURCE ALLOCATION REQUESTに、ベアラ確立要求218はTS 36.413に記載のE-RAB SETUP REQUESTに相当し、これらのメッセージにコーデック情報を伝達するための拡張フィールドを設けることで対応する
。
【００５３】
図6のコールフローのように、他の通信装置であるサーバ5がそのコンテンツに必要なQoS情報を制御信号として提供することにより、基地局2は転送パケットのスヌープ等の高負荷な処理を行うことなくより正確なサービス種別を特定することが可能になる。
【００５４】
図7は、図6と同様に専用ベアラを用いてIP電話会議を行う場合の動作例を示す。はじめに、端末1と基地局2、ゲートウェイ3の間にはデフォルトベアラが確立されている状態にある(231)。次に、端末1はユーザの操作により電話会議アプリケーションを起動する(232)。そしてコーデック情報を含む通信要求を電話会議サーバに対して送信する(233)。電話会議サーバはこれに対して自身のサポートするコーデックを含む通信受付応答を制御信号として返信する(234)。このとき、基地局2は転送パケットの内容をスヌープし、コーデック等の情報からベアラのサービス種別を推定する(235)。そして、ステップ236と237、239にてベアラ確立指示/要求/応答を受信した際に、ベアラIDとサービス種別の対応付けを図3Bのベアラ管理テーブルに設定し(238)、以降のアプリケーション通信240で図4にて述べたスケジューリングアルゴリズムを適用する。
【００５５】
以上、図5〜図7を用いて説明した処理により、基地局2のスケジューラ23は動的に各ベアラのサービス種別を取得することができ、図4により説明した本実施例のスケジューリングアルゴリズムを実施することが可能になる。
【実施例２】
【００５６】
実施例2では、システムQoE向上とシステムスループット向上の両立を図るリソース制御の例を示す。実施例2におけるネットワーク構成、装置構成、テーブル構成は実施例1で説明した図2、図1、図3A、図3B、図11、図12と同じである。すなわち、スケジューリングアルゴリズムが図4に代わり、図8に示すフローチャートに従う点が、実施例1との相違点である。
【００５７】
本実施例のスケジューラは、リソース割当てとQoEとの関連を示すQoE関数を管理し、各ベアラに対するリソース割当てを決定する際に、電波利用効率にもとづくリソース割当てを行った後、割当てたリソースによって予測QoEを計算し、ベアラ各々を、予測QoEが一定値αを超える満足ベアラと、一定値αを超えない不満足ベアラとに分類し、満足ベアラが保持する余剰リソースの総和Dを、割当てたリソースとQoEが一定値αとなるリソースとの差分として計算し、この余剰リソースの総和が零などの所定の閾値になるか、または不満足ベアラが無くなるまで、不満足ベアラの中で最も電波状況の良いものに対して、QoEが一定値αとなるまで余剰リソースを分け与える処理を繰り返すことにより、システムQoE向上とシステムスループット向上の両立を図る。
【００５８】
実施例2におけるスケジューリングアルゴリズム500を図8のフローチャートを用いて説明する。
【００５９】
まず、本実施例の制御では、前述したRSSIのような電波状況に基づくリソース割当ての近傍に最適解があると考え、先ず電波利用効率にもとづくリソース割当てを行う(501)。次に、前記リソースにて予測QoEを計算し、予測QoEがある一定値αを超える満足ベアラとαを超えない不満足ベアラとに分類する(502)。そして満足ベアラが保持する余剰リソースの総和Dを、前記割当てられたリソースと予測QoEがαとなるリソースとの差分として計算し(503)、Dが0になるか又は不満足ベアラがなくなるまで(504)、ループ504〜508を繰り返す。
【００６０】
すなわち、不満足ベアラのなかで最も電波状況の良いベアラに対してQoEがαとなるまで余剰リソースΔを分け与え(505)、また満足ベアラから均等な割合で余剰リソースを差し引く処理(506)を繰り返す。ここで、ステップ506は例えば満足ベアラの余剰リソースをｄとすると、その満足ベアラからｄ×Δ/Dだけ差し引くようにしてもよい。
【００６１】
ここでステップ501の初期状態から開始し、かつステップ505の処理を実施することにより、システムスループット向上を図ることができる。また、ステップ505と506において満足ベアラの余剰リソースを不満足ベアラの余剰リソースに分け与えることにより、システムQoEの向上を図ることができ、結果としてシステムスループットとシステムQoEの両立を達成することが可能になる。
【実施例３】
【００６２】
実施例3では、システム全体でユーザQoEを均一化する制御の例を示す。実施例3におけるネットワーク構成、装置構成、テーブル構成は実施例1で説明した図2、図1、図3A、図3B、図11、図12と同じである。すなわち、スケジューリングアルゴリズムが図4、図8に代わり、図9に示すフローチャートに従う点が、実施例1、実施例2との相違点である。
【００６３】
本実施例におけるスケジューラ23も、リソース割当てとQoEとの関連を示すQoE関数をメモリ26に管理し、各ベアラに対するリソース割当てを決定する際に、全てのベアラを満足させるために必要なリソースの総和と基地局2のリソースから不足リソースDを算出し、この不足リソースDが零などの所定の閾値になるまで、各ベアラのQoEが一定量Δずつ小さくなるようリソース割当てを減少させていくことによりユーザQoEの公平性を図る。
【００６４】
実施例3におけるスケジューリングアルゴリズム300を図9のフローチャートを用いて説明する。はじめに、スケジューラ23はQoE=1.0とするのに必要なリソースを各ベアラに対して割当て、図3Bのリソース割当て54に設定する(301)。次に、全ベアラのリソースの総和を計算した後(302)、次式を用いて不足リソースDを計算する(303)。
【００６５】
【数６】
【００６６】
ここで基地局リソースとは、1基地局が保持するリソースの総和を示す。次に、不足リソースDが正の値である間(304)、各ベアラのQoEが一定量Δだけ小さくなるようにリソース割当てを減少させる(305)というループ304〜306を繰り返す。
【００６７】
以上で本実施例におけるスケジューリングアルゴリズム300の処理を終了する。スケジューリングアルゴリズム300においてループ304〜306を実施することにより、実施例3の目的であるシステム全体でのQoE均一化を達成することができる。
【産業上の利用可能性】
【００６８】
本発明は通信装置のリソース制御方式に関し、特に資源が逼迫した状況において、システム全体でQoEの低下を抑止する技術として有用である。
【符号の説明】
【００６９】
1…端末、2…基地局、3…ゲートウェイ、4…サービス網、5…サーバ、21…アンテナ、22…符号化／復号化部、23…スケジューラ、24…プロトコル処理部、25…NIF、26…メモリ、40…QoE関数情報、50…スケジューラ23が備えるベアラ管理テーブル、100…システムQoE向上とサービス優先度の両立を図るスケジューリングアルゴリズム、300…QoE観点でのユーザ間公平性を図るスケジューリングアルゴリズム、500…システムQoE向上とシステムスループット向上の両立を図るスケジューリングアルゴリズム、600…サービス優先度管理テーブル、700…予測スループット換算テーブル。
【技術分野】
【０００１】
本発明は通信装置のリソース制御方式に関し、特に資源が逼迫した状況において、システム全体でユーザの体感品質(Quality of Experience：QoE)の低下を抑止する技術に関する。
【背景技術】
【０００２】
近年、無線通信が高速化したことに伴い、モバイル端末からインターネット上の様々なサービスを利用できるようになった。これらサービスの中には、例えば映像配信のように広帯域を利用するものがある一方、地震速報のようにデータサイズは小さいが高信頼・低遅延を要求するものもある。また、Webのようにバースト的に通信を行うものもあれば、音声通話のように常に一定の帯域を使用するものもある。さらに将来的には無線を利用した遠隔医療やロボット制御など通常のデータ通信よりもミッションクリティカル性の高いアプリケーションの開発も見込まれており、今後は無線システム上で様々な特性のトラフィックを同時に伝送するようになる。このため、無線システムにおけるQoS(Quality of Service)やQoEの向上が重要な課題になる。
【０００３】
無線システムのQoSやQoEに関わる要素技術として、無線基地局におけるリソース制御方式がある。無線システムでは一般的に有線区間と無線区間の速度差が大きく、無線基地局におけるリソース制御方式がシステム性能に大きな影響を与えるため、これまでも様々なリソース制御方式が提案されてきた。例えば、従来の無線リソース制御技術において基礎的な機構と位置付けられるPF (Proportional Fairness)がある(非特許文献1参照)。このPFは、システムスループット向上とユーザ間の公平性という、相反する目的を両立させるための機構である。
【０００４】
一方、上記のPFのようにシステムスループット向上を目指すのではなく、ユーザの体感品質であるQoEに着目したソース制御方式として、特許文献1が知られている。特許文献1では、双方向映像通信サービスにおいて品質制御後のユーザ体感品質の予測値（予測品質値）を算出し、予測品質値と現在の品質推定値との差分を品質向上値とし、この品質向上値の高い順に優先して品質制御を行うことにより、効果的にサービス全体のQoE向上を図る構成が述べられている。なお、特許文献1には、帯域などのリソース割当てや無効パケット率等の通信品質と、ユーザ体感品質の関係(以下、QoE関数と呼ぶ)のグラフが示されている。このようなグラフは、専用の試験設備において多数のユーザが試験データを採点することにより取得される。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００７−２２１３１８号公報
【非特許文献】
【０００６】
【非特許文献１】F. Kelly, “Charging anｄ rate control for elastic traffic,” European Transactions on Telecommunications, vol. 8, no. 1, pp.33-37, January 1997.
【発明の概要】
【発明が解決しようとする課題】
【０００７】
無線環境では電波状況がよいほどスループットが大きくなるため、システムスループットを最大化するためには電波状況の良いユーザにリソースを割当てるのが得策である。しかし、それではユーザ間の公平性が保てないことから、PFでは次式（１）を用いて転送スロットnにおけるユーザmのリソース割当て優先度Mm(n)を計算する。
【０００８】
【数１】
【０００９】
ここでRm(n)はその転送スロットにおけるユーザmの最大スループットであり、Tm(n)は一定区間におけるユーザmの平均スループットである。本式に従うと、一時的に大量のリソースを使用したユーザは分母のTm(n)が大きくなるため、結果として次の瞬間の割当て優先度Mm(n)が小さくなる。一方、しばらくリソースを使わなかったユーザは、分母のTm(n)が小さくなり徐々に割当て優先度Mm(n)が大きくなる。このため、PFは平均スループットに対して瞬間的に無線リンク状態が良いユーザに転送スロットを割当てることにより、ユーザ公平性を損なわない範囲でシステムスループットの向上を図る方式といえる。
【００１０】
上述したPFによるスケジューリングでは、ユーザ公平性とシステムスループットの向上のために、瞬間的な電波状況と平均スループットを考慮した制御を行うが、このような制御では上述したユーザQoEを考慮したリソース配分を行っていないため、リソース状況がそれほど逼迫していなくてもユーザQoEが低下してしまう可能性がある。
【００１１】
例えば、PFを単純化したシミュレーションの例として、基地局スループットを各ユーザの受信信号強度(Receive Signal Strength Inｄicator：RSSI)で比例配分すると仮定した場合の結果を図10に示す。図10の横軸は基地局に接続するユーザを示し、縦軸はスループット充足率と平均QoEを示している。ここでQoEは各ユーザ毎に0(不満足)〜1.0(満足)の値を取り、後で説明するようにスループットとの関係はアプリケーションやコンテンツごとに異なるグラフになると仮定している。またスループット充足率は次式で計算している。
【００１２】
【数２】
【００１３】
図10から分かるように、PFのように電波状況に応じたスケジューリングを行うと、スループット充足率が100%以上であるにも関わらずユーザのQoEが低下し始めている。これは、リソース状況がそれほど逼迫していなくてもユーザQoEが低下してしまうという問題を示している。
【００１４】
一方で、特許文献1のようにQoEの品質向上値のみに着目した制御を行う場合、QoEの観点では最適化されるものの、その他の観点で不都合が起きる可能性がある。例えば特許文献1では、サービスの優先度について考慮していないため、動画像配信や電話等の複数のサービスが共存するマルチサービス環境において、優先度の高い電話サービスよりも優先度の低い動画像配信サービスに優先してリソースが与えられる可能性がある。また、特許文献1では、主に有線網への適用を想定しており、無線網における電波利用効率について考慮していないため、QoEに基づくリソース制御を行った結果としてシステムスループットが低下してしまう可能性がある。さらに、特許文献1ではQoE観点でのユーザ公平性について考慮されておらず、QoEの向上が見込める端末のみをリソース制御対象とするため、ユーザの不公平感が増大してしまう可能性もある。
【００１５】
本発明はこのような背景に鑑みなされたものであり、システムQoE向上とサービス優先度の両立を図る、QoE向上とシステムスループット向上の両立を図る、あるいはQoE観点でのユーザ間公平性を図るリソース制御が可能な通信装置および通信システムの提供を目的とする。
【課題を解決するための手段】
【００１６】
上記の目的を達成するため、本発明においては、端末及び他の装置との間でデータを送受信するための通信装置であって、端末及び他の装置と接続されるネットワークインタフェースと、ネットワークインタフェースから受信したパケットをフロー毎に蓄積する記憶部と、記憶部に蓄積された各フローに対するリソース割当てを決定するスケジューラを備え、このスケジューラは、リソース割当てとユーザQoEとの関連を示すQoE関数を管理し、リソース割当てを決定する際に、必要なリソースと通信装置のリソースから不足リソースを求め、不足リソースが零になるまで、QoE変化率とサービス優先度の和又は積が最も小さいフローへのリソース割当てを所定量だけ減少させ、所定量だけ減少させたフローのQoEが所定の閾値以下になるフローのリソースを零とする処理を繰り返す通信装置および通信システムを提供する。
【００１７】
また、上記の目的を達成するため、本発明においては、端末及び他の装置との間でデータを送受信するための通信装置であって、端末及び他の装置と接続されるネットワークインタフェースと、ネットワークインタフェースから受信したパケットをフロー毎に蓄積する記憶部と、記憶部に蓄積された各フローに対してリソース割当てを決定するスケジューラを備え、スケジューラは、リソース割当てとQoEとの関連を示すQoE関数を管理し、各フローに対するリソース割当てを決定する際に、電波利用効率にもとづくリソース割当てを行った後、割当てたリソースによって予測QoEを計算し、フロー各々を、予測QoEが一定値αを超える第一のフローと、一定値を超えない第二のフローとに分類し、第一のフローが保持する余剰リソースの総和を、割当てたリソースとQoEが一定値となるリソースとの差分として計算し、この余剰リソースの総和が閾値以下になるか、または第二のフローが無くなるまで、第二のフローの中で最も電波状況の良いものに対して、QoEが一定値となるまで余剰リソースを分け与える処理を繰り返す通信装置および通信システムを提供する。
【００１８】
さらに上記の目的を達成するため、本発明においては、端末及び他の装置との間でデータを送受信するための通信装置であって、端末及び他の装置と接続されるネットワークインタフェースと、ネットワークインタフェースから受信したパケットをフロー毎に蓄積する記憶部と、記憶部に蓄積された各フローに対してリソース割当てを決定するスケジューラを備え、スケジューラは、リソース割当てとQoEとの関連を示すQoE関数を管理し、フロー各々に対するリソース割当て量決定する際に、フロー全体を満足させるために必要なリソースの総和と通信装置のリソースから不足リソースを算出し、不足リソースが所定閾値以下になるまで、各フローのQoEを一定量だけ減少させるようリソース割当てを減らしていく通信装置および通信システムを提供する。
【発明の効果】
【００１９】
本発明によれば、システムQoE向上とサービス優先度の両立、システムQoE向上とシステムスループット向上の両立、あるいはQoE観点でのユーザ間公平性を実現する通信装置および通信システムを提供することが可能になる。
【図面の簡単な説明】
【００２０】
【図１】第１の実施例に係る、基地局の装置構成例を示す図である。
【図２】第１の実施例に係る、ネットワーク構成の一例を示す図である。
【図３Ａ】第１の実施例に係る、QoE関数管理部が備えるQoE関数情報を例示する図である。
【図３Ｂ】第１の実施例に係る、スケジューラが備えるベアラリソース管理テーブルの一例を示す図である。
【図４】第１の実施例に係る、システムQoE向上とサービス優先度の両立を図るスケジューリングアルゴリズムの一例を示すフロー図である。
【図５】第１の実施例に係る、QoE関数情報を設定するコールフローの例1。
【図６】第１の実施例に係る、QoE関数情報を設定するコールフローの例2。
【図７】第１の実施例に係る、QoE関数情報を設定するコールフローの例3。
【図８】第１の実施例に係る、システムQoE向上とシステムスループット向上の両立を図るスケジューリングアルゴリズムを示す図である。
【図９】第１の実施例に係る、QoE観点でのユーザ間公平性を図るスケジューリングアルゴリズムを示す図である。
【図１０】従来技術に基づくスケジューリングを行う場合のQoE平均値を示す図である。
【図１１】第１の実施例に係る、サービス優先度管理テーブルの構成例を示す図である。
【図１２】第１の実施例に係る、予測スループット換算テーブルの構成例を示す図である。
【発明を実施するための形態】
【００２１】
以下、図面を用いて本発明の種々の実施例を説明する。なお以下では、主に無線通信装置および無線通信システムとしての基地局の無線の下りスケジューリングについて説明するが、本発明はこれに限定されず、基地局の無線の上りスケジューリングや、スケジューリングを行う他の有線通信装置などについても適用可能である。
【実施例１】
【００２２】
実施例1では、システムQoE向上とサービス優先度の両立を図る無線基地局における制御装置及びシステムの例を示す。本実施例においては、QoE関数およびサービス優先度に基づいて、各フローに割当てるリソースを決定することを特徴とする。
【００２３】
すなわち、各フローに対して割当てるリソース量を決定する際に、まず全フローを満足させるのに必要なリソースの総和を計算し、次に不足リソースをリソース総和と通信装置リソースとの差分として計算し、次に不足リソースが零になるまで、QoE変化率とサービス優先度の和又は積が最も小さいフローへのリソース割当てを所定量だけ減少させ、またリソース割当てを所定量だけ減少させたときにQoEがある閾値以下になるフローへのリソース割当てを零まで減少させる処理を繰り返すことにより、各フローへのリソース割当てを決定する。
【００２４】
ここで、QoE変化率とは、リソース変化に対するQoE変化の割合を示すQoE関数の傾きである。また、サービス優先度とは各サービスに対する優先度を示し、基地局のオペレータにより数値化され、図11に示すサービス優先度管理テーブル600のような形式で管理されるとする。図11では、重要なサービスに対してより大きな数値を割当ており、例えばサービス優先度が3.0の電話サービス(Voice001)は、サービス優先度が2.0の動画像配信サービス(Streaming001)よりも1.5倍重要であることを示している。
【００２５】
図2は本実施例が適用されるネットワークの全体構成の一例を示す図である。図2において、1は無線インタフェースを備えた端末を示し、2は端末1と無線インタフェースにより通信を行う通信装置としての基地局を示し、3は基地局2から受信したデータを適切なサービス網に振り分けるゲートウェイを示し、4はIP（Internet Protocol）電話やWeb、映像配信等のサービス種別毎に設けられるサービス網を示し、5はサービス網4に接続され端末1と通信を行う他の通信装置であるサーバを示す。本実施例のリソー制御の機能は基地局2の制御機能に対応し、特に基地局2にて実施する無線区間のスケジューリングアルゴリズムに関する。サーバ5とは、通常のネットワークインタフェースを有するコンピュータで構成されている。
【００２６】
以下、図1を用いて本実施例の基地局2の構成とパケット転送処理について詳しく説明する。図1において、25はゲートウェイ3と通信するためのNIF (Network Interface)を示し、26は基地局2が送受信するパケット、および各種テーブル情報を記憶する記憶部であるメモリを示し、24はメモリ26に一次蓄積されたパケットに対して、無線アクセス網のプロトコル処理を施すプロトコル処理部を示す。また、23はメモリ26に蓄積されたパケットの送受信タイミングを計算するスケジューラを示す。22はパケットを符号化または復号化する符号化/復号化部を示し、21は端末に信号を送信するアンテナを示す。なお、スケジューラ23とプロトコル処理部24は、例えば、基地局2内で各種のプログラムが記憶されたメモリ26と協同し、これらのプログラムを実行する処理部として機能する。通常のコンピュータの中央処理部（Central Processing Unit：CPU）などで構成することができる。一方、符号化／復号化部22とNIF25は、通常ハードウェアで構成される。
【００２７】
基地局2は、ゲートウェイ3から受信した下りパケットを先ずメモリ26内のバッファエリアに蓄積し、プロトコル処理部24にてプロトコル処理を行った後、メモリ26にて管理されるベアラ単位、ユーザ単位、あるいはアプリケーション単位などのフロー各々に対応するキューにプロトコル処理後のパケットを登録する。なお、以下の説明においては、上記のフローとして、ベアラ単位を例示して説明することにする。スケジューラ23は、パケットキュー30からパケットを取りだして符号化/復号化部22へ書き込む。符号化/復号化部22は書き込まれたパケットを符号化してアンテナ21へ送出する。
【００２８】
逆に、端末1から基地局2へ向かう上りパケットは、基地局2のスケジューラ23が決定したタイミングで図１の端末1から送信される。基地局2は、端末1からのパケットをアンテナ21で受信するとまず符号化/復号化部22で復号化し、メモリ26のバッファエリアに書き込む。メモリ26上のパケットは、プロトコル処理部24にてプロトコル処理が施された後、NIF25を介してゲートウェイ3に送信される。
【００２９】
この中で本実施例のリソース制御に関わる処理は、スケジューラ23にて実施されるスケジューリング処理であり、より具体的にはメモリ26上にある各種テーブルを参照して上述した各ベアラに対して割当てるスロット数などの無線リソース量を決定する処理である。
【００３０】
次に、図3A、図3B、図11及び図12を用いてメモリ26にて管理される各種テーブルの一具体例について説明する。
【００３１】
図3Aは、メモリ26にて管理される種々のQoE関数情報40の一構成例を示す。図3Aに示すように、QoE関数情報40はサービス種別毎にリソースとユーザQoEの関係を示すグラフである。ここで、グラフ横軸のリソースとは例えばベアラに割当てるスロット数であってもよいし、このほかにもスループット、遅延、パケットロス率、ジッタ等の通信品質パラメータであってもよい。本実施例では先ず単純な例にてその動作原理を示すために、QoE関数情報40が帯域とQoEの関係を管理するものと仮定する。図３Aの各グラフにおいて、横軸がリソースである帯域、縦軸がQoEを示している。QoE関数情報40の各グラフの傾きはリソース変化に対するQoEの変化の割合、即ちQoE変化率を示しており、この傾きが急であるほど、ユーザの体感品質に対する要求が厳しいことを示していると言える。
【００３２】
図3Bは、メモリ26にて管理されるベアラ管理テーブル50の一構成例を示す。図3Bのテーブルにおいて、51はベアラ識別子(Iｄentifier：ID)を示し、52は該ベアラを利用するアプリケーションのサービス種別を示し、53は端末1から報告される該ベアラの信号強度を示し、54は該ベアラに対して瞬間的に割当てるリソース量(スロット数)を示している。なお、各ベアラID0001、0002、0003のサービス種別52は、図3Aの中央部、右側部、左側部に図示した、Voice001、Web001、Streaming001にそれぞれ対応している。
【００３３】
図11は、メモリ26にて管理されるサービス優先度管理テーブル600の一構成例である。図11のテーブルにおいて、601は上記のサービス種別を示し、602はサービス優先度を表わす数値を示す。なお、サービス優先度602は、先に述べたように値が大きいほど優先度が高いものとする。図11の例では、Voice001、Streaming001、Web001の順に優先度が設定されている。
【００３４】
図12は、メモリ27にて管理される予測スループット換算テーブル700の一構成例を示す。図12のテーブルにおいて、701は信号強度を示し、701は該信号強度における1スロットあたりの予測スループットである予測帯域(bps)を示す。
【００３５】
図１の基地局2におけるスケジューラ23は、上記で説明した各種テーブルを参照して各ベアラに割当てるスロット数を決定し、図3Bの割当てスロット数54に設定する。本実施例の基地局2においては、スケジューラ23におけるスケジューリング処理において、各ベアラのパケットに対して、図3AのQoE関数情報40を参照してリソースを割当てる点が特徴となる。
【００３６】
以下、図4を用いて本実施例におけるリソース制御を行うスケジューラ23のスケジューリングアルゴリズム100を説明する。なお、図4、図8、図9に示すスケジューリングアルゴリズムは上述したCPUで実行されるプログラムで実現できる。
【００３７】
はじめに、スケジューラ23はQoE=1.0とするのに必要なリソースを各ベアラに対して割当て、図3Bのリソース割当て54に設定する(ステップ101、以下括弧内ステップ省略)。ここでQoE=1.0とするのに必要なリソースとは、次式で計算する。
【００３８】
【数３】
【００３９】
ここで、右辺の(QoE=1.0とするのに必要な帯域)は、図3Bのサービス種別52および図3AのQoE関数情報40から取得する。また、右辺の(該信号強度におけるスロットあたりの予測帯域)は図3Bの信号強度53と、図12の予測スループット換算テーブル700から取得する。
【００４０】
次に、全ベアラのリソースの総和を計算した後(102)、次式を用いて不足リソースDを計算する(103)。
【００４１】
【数４】
【００４２】
ここで基地局リソースとは、1台の基地局が保持するリソースの総和、すなわち、単位時間当たりの総スロット数を示す。次に、不足リソースDが正の値である間、図4のループ104〜110の処理を繰り返す。ループ104〜110では先ず、リソースを所定量Δだけ減らした時の、リソース変化に対するQoE変化率であるQoE関数の傾きとサービス優先度の和または積が最も小さいベアラへのリソース割当てをΔだけ減少させた後(105)、不足リソースDをΔだけ減少させる(106)。ここで所定量Δは予めパラメータとして設定された値であり、サービス優先度は上述したように図11にて管理される値である。
【００４３】
次に、リソースをΔだけ減少させたときに該ベアラのQoEがある閾値(a)以下になるかどうかを判定する(107)。ある閾値(a)以下にならない場合はステップ108〜109をスキップして次のループに入る。QoEがある閾値(a)以下になる場合は該ベアラのリソースαを0まで減少させるとともに(108)、不足リソースをαだけ減少させてから(109)、次のループに入る。
【００４４】
なお、上記ステップ105の処理においてQoEの減少を見積もるためには、あるリソースが与えられた時の予測QoEを計算する必要がある。この見積もりは、まず次式を用いて予測帯域を計算した後、予測帯域を図3AのQoE関数に代入することにより行われる。
【００４５】
【数５】
【００４６】
以上でスケジューリングアルゴリズム100の処理を終了する。スケジューリングアルゴリズム100においてステップ105〜106の処理を行うことにより、本実施例の目的とするシステムQoE向上とサービス優先度の両立を達成することができる。また、ステップ108〜109の処理を行うことにより、不要なスループット割当てを無くして効率的なリソース配分を行うことができる。
【００４７】
次に、図5〜7の各動作例を用いて図3Bのベアラ管理テーブル50に各ベアラのサービス種別52を登録する処理を説明する。これらの処理を通して、図3Bベアラリソース管理テーブルのサービス種別52の項が設定される。
【００４８】
図5は、ベストエフォートトラフィックが使用するデフォルトベアラにて、HTTP (Hypertext Transfer Protocol)通信を行う場合の動作例を示す。初めに、端末1と基地局2、ゲートウェイ3の間にはデフォルトベアラが確立されている(201)。端末1は、サーバ5に対してコンテンツ要求(HTTP GET)を送信し(202)、サーバ5はこれに対してコンテンツ応答(HTTP 200 OK)を返信する。このとき、基地局2は転送パケットの内容をスヌープし、サーバ側のポート番号が80番であることなどから通信プロトコルがHTTPであると推測して、サービス種別が例えば図3Aの”Web001”であると判断する。ここでプロトコル種別よりもさらに細かな分類を行うために、転送パケット中の、サーバ側のIPアドレスやHTTPヘッダ情報、更にはHTML (Hyper Text Markup Language)の内容等を参照してもよい。そして基地局2は、判断したサービス種別に基づき転送パケットに対して図4で述べたスケジューリングを適用する。
【００４９】
本実施例においては、図5のコールフローのように、基地局2は、端末が送受信するアプリケーションデータをスヌープして自動的に図3Bのサービス種別52を推定することにより、既存のネットワーク設備に影響を与えることなくアプリケーションに適した高度なスケジューリングを行うことが可能になる。
【００５０】
図6は、個別のアプリケーション用に設定される専用ベアラにて、ストリーミングを視聴する場合の動作例を示す。初めに、端末1と基地局2、ゲートウェイ3の間にはデフォルトベアラが確立されている(211)。端末1は先ずデフォルトベアラを用いてサーバ5にコンテンツリスト要求を送信する(212)。これに対しサーバ5はコンテンツリストを含む応答を返信する(213)。端末1のユーザはコンテンツリストからコンテンツを選択し、ストリーミングファイルへのリンクを含むメタファイルをサーバ5に要求する(214)。サーバ5はメタファイルを返信するとともに、そのストリーミングの視聴に必要なQoSパラメータやコーデックを端末1に通知する(215)。端末１は、ストリーミングアプリケーションを起動し(216)、専用ベアラ確立指示をゲートウェイ3に送信する(217)。専用ベアラ確立指示217にはステップ215で端末1に通知されたQoSパラメータやコーデックの情報が設定される。
【００５１】
ここでコーデック情報を通知する理由は、コーデックによって図3Aで示したQoE関数が異なる可能性があるためである。ゲートウェイ3は、専用ベアラ確立指示217に含まれるQoSパラメータやコーデックの情報に基づき、専用ベアラ確立要求218を送信する。専用ベアラ確立要求218は基地局2を経由して端末1に到達する。このとき基地局2は、専用ベアラ確立要求218のQoSパラメータやコーデック情報からサービス種別を決定し、ベアラとの対応付けを図3Bのベアラ管理テーブルに設定する(219)。最後に、ステップ218に対する専用ベアラ確立応答220が返信され、アプリケーション通信(ストリーミング)が開始される(221)。
【００５２】
なお、上記コールフローにおいてベアラ確立指示217およびベアラ確立要求218にコーデック情報を設定することは本実施例のシステムの独自の仕様であり、メッセージ中に専用の拡張フィールドが必要になる。例えば、無線種別として3GPP(3rｄ Generation Partnership Project) LTE(Long Term Evolution)を想定する場合には、ベアラ確立指示217はTS 24.301に記載のBEARER RESOURCE ALLOCATION REQUESTに、ベアラ確立要求218はTS 36.413に記載のE-RAB SETUP REQUESTに相当し、これらのメッセージにコーデック情報を伝達するための拡張フィールドを設けることで対応する
。
【００５３】
図6のコールフローのように、他の通信装置であるサーバ5がそのコンテンツに必要なQoS情報を制御信号として提供することにより、基地局2は転送パケットのスヌープ等の高負荷な処理を行うことなくより正確なサービス種別を特定することが可能になる。
【００５４】
図7は、図6と同様に専用ベアラを用いてIP電話会議を行う場合の動作例を示す。はじめに、端末1と基地局2、ゲートウェイ3の間にはデフォルトベアラが確立されている状態にある(231)。次に、端末1はユーザの操作により電話会議アプリケーションを起動する(232)。そしてコーデック情報を含む通信要求を電話会議サーバに対して送信する(233)。電話会議サーバはこれに対して自身のサポートするコーデックを含む通信受付応答を制御信号として返信する(234)。このとき、基地局2は転送パケットの内容をスヌープし、コーデック等の情報からベアラのサービス種別を推定する(235)。そして、ステップ236と237、239にてベアラ確立指示/要求/応答を受信した際に、ベアラIDとサービス種別の対応付けを図3Bのベアラ管理テーブルに設定し(238)、以降のアプリケーション通信240で図4にて述べたスケジューリングアルゴリズムを適用する。
【００５５】
以上、図5〜図7を用いて説明した処理により、基地局2のスケジューラ23は動的に各ベアラのサービス種別を取得することができ、図4により説明した本実施例のスケジューリングアルゴリズムを実施することが可能になる。
【実施例２】
【００５６】
実施例2では、システムQoE向上とシステムスループット向上の両立を図るリソース制御の例を示す。実施例2におけるネットワーク構成、装置構成、テーブル構成は実施例1で説明した図2、図1、図3A、図3B、図11、図12と同じである。すなわち、スケジューリングアルゴリズムが図4に代わり、図8に示すフローチャートに従う点が、実施例1との相違点である。
【００５７】
本実施例のスケジューラは、リソース割当てとQoEとの関連を示すQoE関数を管理し、各ベアラに対するリソース割当てを決定する際に、電波利用効率にもとづくリソース割当てを行った後、割当てたリソースによって予測QoEを計算し、ベアラ各々を、予測QoEが一定値αを超える満足ベアラと、一定値αを超えない不満足ベアラとに分類し、満足ベアラが保持する余剰リソースの総和Dを、割当てたリソースとQoEが一定値αとなるリソースとの差分として計算し、この余剰リソースの総和が零などの所定の閾値になるか、または不満足ベアラが無くなるまで、不満足ベアラの中で最も電波状況の良いものに対して、QoEが一定値αとなるまで余剰リソースを分け与える処理を繰り返すことにより、システムQoE向上とシステムスループット向上の両立を図る。
【００５８】
実施例2におけるスケジューリングアルゴリズム500を図8のフローチャートを用いて説明する。
【００５９】
まず、本実施例の制御では、前述したRSSIのような電波状況に基づくリソース割当ての近傍に最適解があると考え、先ず電波利用効率にもとづくリソース割当てを行う(501)。次に、前記リソースにて予測QoEを計算し、予測QoEがある一定値αを超える満足ベアラとαを超えない不満足ベアラとに分類する(502)。そして満足ベアラが保持する余剰リソースの総和Dを、前記割当てられたリソースと予測QoEがαとなるリソースとの差分として計算し(503)、Dが0になるか又は不満足ベアラがなくなるまで(504)、ループ504〜508を繰り返す。
【００６０】
すなわち、不満足ベアラのなかで最も電波状況の良いベアラに対してQoEがαとなるまで余剰リソースΔを分け与え(505)、また満足ベアラから均等な割合で余剰リソースを差し引く処理(506)を繰り返す。ここで、ステップ506は例えば満足ベアラの余剰リソースをｄとすると、その満足ベアラからｄ×Δ/Dだけ差し引くようにしてもよい。
【００６１】
ここでステップ501の初期状態から開始し、かつステップ505の処理を実施することにより、システムスループット向上を図ることができる。また、ステップ505と506において満足ベアラの余剰リソースを不満足ベアラの余剰リソースに分け与えることにより、システムQoEの向上を図ることができ、結果としてシステムスループットとシステムQoEの両立を達成することが可能になる。
【実施例３】
【００６２】
実施例3では、システム全体でユーザQoEを均一化する制御の例を示す。実施例3におけるネットワーク構成、装置構成、テーブル構成は実施例1で説明した図2、図1、図3A、図3B、図11、図12と同じである。すなわち、スケジューリングアルゴリズムが図4、図8に代わり、図9に示すフローチャートに従う点が、実施例1、実施例2との相違点である。
【００６３】
本実施例におけるスケジューラ23も、リソース割当てとQoEとの関連を示すQoE関数をメモリ26に管理し、各ベアラに対するリソース割当てを決定する際に、全てのベアラを満足させるために必要なリソースの総和と基地局2のリソースから不足リソースDを算出し、この不足リソースDが零などの所定の閾値になるまで、各ベアラのQoEが一定量Δずつ小さくなるようリソース割当てを減少させていくことによりユーザQoEの公平性を図る。
【００６４】
実施例3におけるスケジューリングアルゴリズム300を図9のフローチャートを用いて説明する。はじめに、スケジューラ23はQoE=1.0とするのに必要なリソースを各ベアラに対して割当て、図3Bのリソース割当て54に設定する(301)。次に、全ベアラのリソースの総和を計算した後(302)、次式を用いて不足リソースDを計算する(303)。
【００６５】
【数６】
【００６６】
ここで基地局リソースとは、1基地局が保持するリソースの総和を示す。次に、不足リソースDが正の値である間(304)、各ベアラのQoEが一定量Δだけ小さくなるようにリソース割当てを減少させる(305)というループ304〜306を繰り返す。
【００６７】
以上で本実施例におけるスケジューリングアルゴリズム300の処理を終了する。スケジューリングアルゴリズム300においてループ304〜306を実施することにより、実施例3の目的であるシステム全体でのQoE均一化を達成することができる。
【産業上の利用可能性】
【００６８】
本発明は通信装置のリソース制御方式に関し、特に資源が逼迫した状況において、システム全体でQoEの低下を抑止する技術として有用である。
【符号の説明】
【００６９】
1…端末、2…基地局、3…ゲートウェイ、4…サービス網、5…サーバ、21…アンテナ、22…符号化／復号化部、23…スケジューラ、24…プロトコル処理部、25…NIF、26…メモリ、40…QoE関数情報、50…スケジューラ23が備えるベアラ管理テーブル、100…システムQoE向上とサービス優先度の両立を図るスケジューリングアルゴリズム、300…QoE観点でのユーザ間公平性を図るスケジューリングアルゴリズム、500…システムQoE向上とシステムスループット向上の両立を図るスケジューリングアルゴリズム、600…サービス優先度管理テーブル、700…予測スループット換算テーブル。
【特許請求の範囲】
【請求項１】
端末及び他の装置との間でデータを送受信するための通信装置であって、
前記端末及び前記他の装置と接続されるネットワークインタフェースと、前記ネットワークインタフェースから受信したパケットをフロー毎に蓄積する記憶部と、前記記憶部に蓄積された各フローに対するリソース割当てを決定するスケジューラを備え、
前記スケジューラは、リソース割当てとユーザQoEとの関連を示すQoE関数を管理し、
前記リソース割当てを決定する際に、前記通信装置の不足リソースが零になるまで、QoE変化率とサービス優先度の和或いは積が最も小さいフローのリソース割当てを所定量だけ減少させ、その結果、前記QoEが所定の閾値以下になる前記フローのリソース割当てを零とする処理を繰り返す、
ことを特徴とする通信装置。
【請求項２】
請求項１に記載の通信装置であって、
前記スケジューラは、前記不足リソースを、前記フロー全てを満足させるのに必要なリソースと前記通信装置のリソースの差分として算出する、
ことを特徴とする通信装置。
【請求項３】
請求項１に記載の通信装置であって、
前記記憶部は、前記QoE関数を記憶する、
ことを特徴とする通信装置。
【請求項４】
請求項３に記載の通信装置であって、
前記スケジューラは、受信した前記パケットに基づいて、前記QoE関数を特定する、
を特徴とする通信装置。
【請求項５】
請求項４に記載の通信装置であって、
受信した前記パケットは、通信路を設定するために前記他の通信装置が送信した制御信号のパケットであり、
前記スケジューラは、前記制御信号のパケットから対応する前記フローのサービス種別を推定し、前記サービス種別に基づき、前記記憶部に記憶された前記QoE関数を決定する、
ことを特徴とする通信装置。
【請求項６】
請求項４に記載の通信装置であって、
受信した前記パケットは、前記端末が送受信するアプリケーションデータのパケットである、
前記スケジューラは、前記アプリケーションデータから前記フローのサービス種別を推定し、前記サービス種別に基づき、前記記憶部に記憶された前記QoE関数を決定する、
ことを特徴とする通信装置。
【請求項７】
端末及び他の装置との間でデータを送受信するための通信装置であって、
前記端末及び前記他の装置と接続されるネットワークインタフェースと、前記ネットワークインタフェースから受信したパケットをフロー毎に蓄積する記憶部と、前記記憶部に蓄積された前記フローに対してリソース割当てを決定するスケジューラを備え、
前記スケジューラは、リソース割当てとQoEとの関連を示すQoE関数を管理し、前記リソース割当てを決定する際に、電波利用効率にもとづくリソース割当てを行った後、割当てた前記リソースに基づき予測QoEを計算し、
前記フロー各々を、前記予測QoEがある一定値を超える第一のフローと、前記一定値を超えない第二のフローとに分類し、前記第一のフローが保持する余剰リソースの総和が零になるか、または前記第二のフローが無くなるまで、前記第二のフローの中で最も電波状況の良いフローに対して、前記QoEが前記一定値となるまで余剰リソースを分け与える処理を繰り返す、
ことを特徴とする通信装置。
【請求項８】
請求項７に記載の通信装置であって、
前記スケジューラは、前記余剰リソースを、割当てられた前記リソースと前記予測QoEが前記所定値となるリソースとの差分として計算する、
ことを特徴とする通信装置。
【請求項９】
請求項７に記載の通信装置であって、
前記記憶部は、前記フローのサービス種別に対応する前記QoE関数を記憶する、
ことを特徴とする通信装置。
【請求項１０】
請求項９に記載の通信装置であって、
前記スケジューラは、受信した前記パケットに基づいて、前記QoE関数を特定する、
を特徴とする通信装置。
【請求項１１】
請求項１０に記載の通信装置であって、
受信した前記パケットは、通信路を設定するために前記他の通信装置が送信した制御信号のパケットであり、
前記スケジューラは、前記制御信号のパケットから対応する前記フローのサービス種別を推定し、前記サービス種別に基づき、前記記憶部に記憶された前記QoE関数を決定する、
ことを特徴とする通信装置。
【請求項１２】
請求項１０に記載の通信装置であって、
受信した前記パケットは、前記端末が送受信するアプリケーションデータのパケットであり、
前記スケジューラは、前記アプリケーションデータから前記フローのサービス種別を推定し、前記サービス種別に基づき、前記記憶部に記憶された前記QoE関数を決定する、
ことを特徴とする通信装置。
【請求項１３】
通信装置を介して端末と他の装置との間でデータを送受信する通信システムであって、
前記通信装置は、受信したパケットをフロー毎に蓄積する記憶部と、前記記憶部に蓄積された前記フローに対してリソース割当てを決定する処理部とを備え、
前記処理部は、前記記憶部に記憶された、リソース割当てとQoEとの関連を示すQoE関数を利用して、前記フロー各々に対する前記リソース割当てを決定する際に、
電波利用効率にもとづくリソース割当てを行った後、割当てた前記リソースに基づき予測QoEを計算し、
前記フロー各々を、前記予測QoEがある一定値を超える第一のフローと、前記一定値を超えない第二のフローとに分類し、
前記第一フローが保持する余剰リソースの総和が零になるか、または前記第二のフローが無くなるまで、前記第二のフローの中で最も電波状況の良いフローに対して、前記QoEが前記一定値となるまで余剰リソースを分け与える処理を繰り返すことを特徴とする通信システム。
【請求項１４】
請求項１３に記載の通信システムであって、
前記処理部は、前記余剰リソースを、割当てられた前記リソースと前記予測QoEが前記所定値となるリソースとの差分として計算する、
ことを特徴とする通信システム。
【請求項１５】
請求項１３に記載の通信システムであって、
前記処理部は、受信した前記パケットに基づいて、前記QoE関数を特定する、
を特徴とする通信システム。
【請求項１６】
請求項１５に記載の通信システムであって、
受信した前記パケットは、通信路を設定するために前記他の通信装置が送信した制御信号のパケットである、
ことを特徴とする通信システム。
【請求項１７】
請求項１５に記載の通信システムであって、
受信した前記パケットは、前記端末が送受信するアプリケーションデータのパケットである、
ことを特徴とする通信システム。
【請求項１８】
請求項１６に記載の通信システムであって、
前記処理部は、前記制御信号から対応する前記フローのサービス種別を推定し、前記サービス種別に基づき、前記QoE関数を決定する、
ことを特徴とする通信システム。
【請求項１９】
請求項１７に記載の通信システムであって、
前記処理部は、前記アプリケーションデータから前記フローのサービス種別を推定し、前記サービス種別に基づき、前記QoE関数を決定する、
ことを特徴とする通信システム。
【請求項２０】
請求項１８に記載の通信システムであって、
前記制御信号はQoSパラメータあるいはコーデックである、
ことを特徴とする通信システム。
【請求項１】
端末及び他の装置との間でデータを送受信するための通信装置であって、
前記端末及び前記他の装置と接続されるネットワークインタフェースと、前記ネットワークインタフェースから受信したパケットをフロー毎に蓄積する記憶部と、前記記憶部に蓄積された各フローに対するリソース割当てを決定するスケジューラを備え、
前記スケジューラは、リソース割当てとユーザQoEとの関連を示すQoE関数を管理し、
前記リソース割当てを決定する際に、前記通信装置の不足リソースが零になるまで、QoE変化率とサービス優先度の和或いは積が最も小さいフローのリソース割当てを所定量だけ減少させ、その結果、前記QoEが所定の閾値以下になる前記フローのリソース割当てを零とする処理を繰り返す、
ことを特徴とする通信装置。
【請求項２】
請求項１に記載の通信装置であって、
前記スケジューラは、前記不足リソースを、前記フロー全てを満足させるのに必要なリソースと前記通信装置のリソースの差分として算出する、
ことを特徴とする通信装置。
【請求項３】
請求項１に記載の通信装置であって、
前記記憶部は、前記QoE関数を記憶する、
ことを特徴とする通信装置。
【請求項４】
請求項３に記載の通信装置であって、
前記スケジューラは、受信した前記パケットに基づいて、前記QoE関数を特定する、
を特徴とする通信装置。
【請求項５】
請求項４に記載の通信装置であって、
受信した前記パケットは、通信路を設定するために前記他の通信装置が送信した制御信号のパケットであり、
前記スケジューラは、前記制御信号のパケットから対応する前記フローのサービス種別を推定し、前記サービス種別に基づき、前記記憶部に記憶された前記QoE関数を決定する、
ことを特徴とする通信装置。
【請求項６】
請求項４に記載の通信装置であって、
受信した前記パケットは、前記端末が送受信するアプリケーションデータのパケットである、
前記スケジューラは、前記アプリケーションデータから前記フローのサービス種別を推定し、前記サービス種別に基づき、前記記憶部に記憶された前記QoE関数を決定する、
ことを特徴とする通信装置。
【請求項７】
端末及び他の装置との間でデータを送受信するための通信装置であって、
前記端末及び前記他の装置と接続されるネットワークインタフェースと、前記ネットワークインタフェースから受信したパケットをフロー毎に蓄積する記憶部と、前記記憶部に蓄積された前記フローに対してリソース割当てを決定するスケジューラを備え、
前記スケジューラは、リソース割当てとQoEとの関連を示すQoE関数を管理し、前記リソース割当てを決定する際に、電波利用効率にもとづくリソース割当てを行った後、割当てた前記リソースに基づき予測QoEを計算し、
前記フロー各々を、前記予測QoEがある一定値を超える第一のフローと、前記一定値を超えない第二のフローとに分類し、前記第一のフローが保持する余剰リソースの総和が零になるか、または前記第二のフローが無くなるまで、前記第二のフローの中で最も電波状況の良いフローに対して、前記QoEが前記一定値となるまで余剰リソースを分け与える処理を繰り返す、
ことを特徴とする通信装置。
【請求項８】
請求項７に記載の通信装置であって、
前記スケジューラは、前記余剰リソースを、割当てられた前記リソースと前記予測QoEが前記所定値となるリソースとの差分として計算する、
ことを特徴とする通信装置。
【請求項９】
請求項７に記載の通信装置であって、
前記記憶部は、前記フローのサービス種別に対応する前記QoE関数を記憶する、
ことを特徴とする通信装置。
【請求項１０】
請求項９に記載の通信装置であって、
前記スケジューラは、受信した前記パケットに基づいて、前記QoE関数を特定する、
を特徴とする通信装置。
【請求項１１】
請求項１０に記載の通信装置であって、
受信した前記パケットは、通信路を設定するために前記他の通信装置が送信した制御信号のパケットであり、
前記スケジューラは、前記制御信号のパケットから対応する前記フローのサービス種別を推定し、前記サービス種別に基づき、前記記憶部に記憶された前記QoE関数を決定する、
ことを特徴とする通信装置。
【請求項１２】
請求項１０に記載の通信装置であって、
受信した前記パケットは、前記端末が送受信するアプリケーションデータのパケットであり、
前記スケジューラは、前記アプリケーションデータから前記フローのサービス種別を推定し、前記サービス種別に基づき、前記記憶部に記憶された前記QoE関数を決定する、
ことを特徴とする通信装置。
【請求項１３】
通信装置を介して端末と他の装置との間でデータを送受信する通信システムであって、
前記通信装置は、受信したパケットをフロー毎に蓄積する記憶部と、前記記憶部に蓄積された前記フローに対してリソース割当てを決定する処理部とを備え、
前記処理部は、前記記憶部に記憶された、リソース割当てとQoEとの関連を示すQoE関数を利用して、前記フロー各々に対する前記リソース割当てを決定する際に、
電波利用効率にもとづくリソース割当てを行った後、割当てた前記リソースに基づき予測QoEを計算し、
前記フロー各々を、前記予測QoEがある一定値を超える第一のフローと、前記一定値を超えない第二のフローとに分類し、
前記第一フローが保持する余剰リソースの総和が零になるか、または前記第二のフローが無くなるまで、前記第二のフローの中で最も電波状況の良いフローに対して、前記QoEが前記一定値となるまで余剰リソースを分け与える処理を繰り返すことを特徴とする通信システム。
【請求項１４】
請求項１３に記載の通信システムであって、
前記処理部は、前記余剰リソースを、割当てられた前記リソースと前記予測QoEが前記所定値となるリソースとの差分として計算する、
ことを特徴とする通信システム。
【請求項１５】
請求項１３に記載の通信システムであって、
前記処理部は、受信した前記パケットに基づいて、前記QoE関数を特定する、
を特徴とする通信システム。
【請求項１６】
請求項１５に記載の通信システムであって、
受信した前記パケットは、通信路を設定するために前記他の通信装置が送信した制御信号のパケットである、
ことを特徴とする通信システム。
【請求項１７】
請求項１５に記載の通信システムであって、
受信した前記パケットは、前記端末が送受信するアプリケーションデータのパケットである、
ことを特徴とする通信システム。
【請求項１８】
請求項１６に記載の通信システムであって、
前記処理部は、前記制御信号から対応する前記フローのサービス種別を推定し、前記サービス種別に基づき、前記QoE関数を決定する、
ことを特徴とする通信システム。
【請求項１９】
請求項１７に記載の通信システムであって、
前記処理部は、前記アプリケーションデータから前記フローのサービス種別を推定し、前記サービス種別に基づき、前記QoE関数を決定する、
ことを特徴とする通信システム。
【請求項２０】
請求項１８に記載の通信システムであって、
前記制御信号はQoSパラメータあるいはコーデックである、
ことを特徴とする通信システム。
【図１】
【図２】
【図３Ａ】
【図３Ｂ】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図２】
【図３Ａ】
【図３Ｂ】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【公開番号】特開２０１１−１７２１５０（Ｐ２０１１−１７２１５０Ａ）
【公開日】平成２３年９月１日（２０１１．９．１）
【国際特許分類】
【出願番号】特願２０１０−３６０５１（Ｐ２０１０−３６０５１）
【出願日】平成２２年２月２２日（２０１０．２．２２）
【国等の委託研究の成果に係る記載事項】（出願人による申告）平成２１年度、独立行政法人情報通信研究機構、ネットワーク仮想化を活用したデータサービスアプリケーション基盤技術に関する研究開発 委託事業、産業技術力強化法第１９条の適用を受ける特許出願
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
【公開日】平成２３年９月１日（２０１１．９．１）
【国際特許分類】
【出願日】平成２２年２月２２日（２０１０．２．２２）
【国等の委託研究の成果に係る記載事項】（出願人による申告）平成２１年度、独立行政法人情報通信研究機構、ネットワーク仮想化を活用したデータサービスアプリケーション基盤技術に関する研究開発 委託事業、産業技術力強化法第１９条の適用を受ける特許出願
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
[ Back to top ]