JP7424498B2 - 通信システム、通信方法、コントローラ装置及びプログラム - Google Patents

Description

本開示は、アプリケーションサーバから端末へのトラヒックの遅延制御に関する。

ゲームの高度化に伴い、ＰＣ（ｐｅｒｓｏｎａｌ ｃｏｍｐｕｔｅｒ）に求められる性能要件が高まっていること、５Ｇ（５ｔｈ Ｇｅｎｅｒａｔｉｏｎ）の普及が始まり通信ネットワークの品質が高まっていることから、ゲームの動作機能をクラウドゲームサーバに置き、ユーザの使用する端末には操作と画面描画機能のみを配備するクラウドゲームの普及が進んでいる。

しかしながら、クラウドゲームは通常のオンラインゲームと異なり、映像トラヒックを送受信する必要があることから、安定した通信品質を提供しなければ操作性が低下してしまうという課題がある。特に、操作してから操作結果が映像に反映されるまでのフィードバック時間が大きくなると、ユーザの操作体感は極めて劣化してしまうことから、クラウドゲームサーバが映像トラヒックを送信し、ユーザ端末がそれを受信して画面に描画するまでの時間である映像送信遅延を小さくする必要がある。

一方で、クラウドゲームにおいて求められる操作性はゲームや状況によって異なっている。例えば、アクションゲームのように高い操作性が求められるゲームを個人で行う場合には、映像送信遅延を極力小さくする必要がある。一方で、カードゲームのように操作性があまり求められないゲームの場合には、映像送信遅延を大きくしても構わない。さらに、対戦ゲームの場合、操作性を高めるのみならず、映像送信遅延を制御してフィードバック時間を公平にする必要がある。

映像送信遅延を小さくするための方法として、非特許文献１では映像コーデックと輻輳制御に着目している。非特許文献１では、映像コーデックにおいて一般的に用いられている複数のフレームを組み合わせてエンコードすることによりデータ量を減らすＧＯＰ（Ｇｒｏｕｐ Ｏｆ Ｐｉｃｔｕｒｅ）機能を利用しないことにより、デコードにかかる時間を短縮し、映像送信遅延を小さくしている。また、非特許文献１では、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）の輻輳制御アルゴリズムとして、パケットロスに起因してレートを制御するＣＵＢＩＣを用いるのではなく、ジッタに起因してレートを制御するＢＢＲ（Ｂｏｔｔｌｅｎｅｃｋ Ｂａｎｄｗｉｄｔｈ ａｎｄ Ｒｏｕｎｄ－ｔｒｉｐ ｐｒｏｐａｇａｔｉｏｎ ｔｉｍｅ）を用いることで、スループットを安定化させることにより、映像送信遅延を小さくしている。

しかしながら、従来技術では映像送信遅延を極力小さくするように動くのみであって、それぞれのゲームの種類や状況に応じた制御が行われていない。このような場合、特に問題になるのが間の通信ネットワークである。通信ネットワークの帯域は有限であるため、ユーザ数が増えると帯域溢れが発生してしまう。その際、すべてのユーザがその影響を被り、操作体感が劣化してしまう。

Ｇｏｏｇｌｅ ＳＴＡＤＩＡ， ｈｔｔｐｓ：／／ｗｗｗ．ｐｃｇａｍｅｓｎ．ｃｏｍ／ｓｔａｄｉａ／ｇｏｏｇｌｅ－ｇａｍｅ－ｓｔｒｅａｍｉｎｇ－ｔｅｃｈｎｏｌｏｇｙ－ｌａｔｅｎｃｙ－ｑｕａｌｉｔｙ

本発明では、クラウドゲーム等のアプリケーションで求められる操作性を損なうことなく、輻輳制御を行うことを目的とする。

本開示の通信システムは、
アプリケーションのトラフィックを制御する通信システムであって、
アプリケーションの種類に応じた目標フィードバック遅延時間を設定し、該目標フィードバック遅延時間を満足するようにトラヒック制御を実行する。

本開示の通信方法は、
アプリケーションのトラフィックを制御するコントローラ装置が実行する通信方法であって、
コントローラ装置が、アプリケーションの種類に応じた目標フィードバック遅延時間を設定し、該目標フィードバック遅延時間を満足するようにトラヒック制御を実行する。

本開示のコントローラ装置は、
アプリケーションの種類に応じた目標フィードバック遅延時間を保持し、
トラヒック制御機能から目標フィードバック遅延時間の問い合わせを受けると、問い合わせのあったアプリケーションの種類に応じた目標フィードバック遅延時間を設定し、前記トラヒック制御機能に、該目標フィードバック遅延時間を満足するようにトラヒック制御を実行させる。

本開示のプログラムは、本開示に係る通信装置に備わる各機能部としてコンピュータを実現させるためのプログラムであり、本開示に係る通信装置が実行する通信方法に備わる各ステップをコンピュータに実行させるためのプログラムである。

本開示によれば、クラウドゲーム等のアプリケーションで求められる操作性を損なうことなく、輻輳制御を行うことができる。

本開示の概要を示す説明図である。 本開示のシステム構成の一例を示す。 端末の構成例を示す。 クラウドゲームサーバの構成例を示す。 往復遅延情報テーブルの一例を示す。 ゲーム属性情報テーブルの一例を示す。 コントローラ装置の構成例を示す。 往復遅延情報ＤＢの一例を示す。 ゲーム属性情報ＤＢの一例を示す。 クラウドゲーム品質制御ポリシーテーブルの一例を示す。 遅延制御シェーピング機能の構成例を示す。 トークン供給関数計算部が行うトークン供給関数更新処理フローを説明する図である。 トークン供給部が行う通信フロー毎トークン供給処理フローを説明する図である。 クラウドゲームサーバが往復遅延を取得するフローの一例を示す。 コントローラ装置がゲーム属性情報を収集するフローの一例を示す。 ラウドゲームサーバが往復遅延情報を収集するフローの一例を示す。 遅延制御シェーピング機能がシェーピング設定値を変更するフローの一例を示す。

以下、本開示の実施形態について、図面を参照しながら詳細に説明する。なお、本開示は、以下に示す実施形態に限定されるものではない。これらの実施の例は例示に過ぎず、本開示は当業者の知識に基づいて種々の変更、改良を施した形態で実施することができる。なお、本明細書及び図面において符号が同じ構成要素は、相互に同一のものを示すものとする。

（発明の概要）
図１に、本開示の概要を示す。本開示は、アプリケーションのトラフィックを制御する方法において、アプリケーションの種類に応じた目標フィードバック遅延時間を設定し、該目標フィードバック遅延時間を満足するようにトラヒック制御を実行する。例えば、クラウドゲームサーバ９４が端末９３にゲームアプリケーションを提供するための通信において、ゲームアプリケーションがアクションゲームであり、アクションゲームの目標フィードバック時間が１６ｍｓである場合、ＲＴＴ＝５ｍｓなら、１１ｍｓの遅延制御シェーピングを実行する。

トラヒック制御後のトラヒックの合計を上回るようネットワーク帯域を準備することで、パケットの衝突を回避するよう、目標フィードバック時間の範囲内で輻輳制御を行うことができる。このため、クラウドゲーム等のアプリケーションで求められる操作性を損なうことなく、輻輳制御を行うことができる。以下、本開示の一例として、トラヒック制御が遅延制御シェーピングである例について説明する。

（実施形態例１）
図２に、本実施形態に係るシステム構成の一例を示す。本開示に係るシステムは、クラウドゲームサーバ９４と端末９３がネットワーク９２で接続されている通信システムにおいて、ネットワーク９２とクラウドゲームサーバ９４との間に遅延制御シェーピング機能９１が接続されている。遅延制御シェーピング機能９１は、コントローラ装置９５に接続されている。遅延制御シェーピング機能９１は、コントローラ装置９５の設定に基づき、アプリケーションの種類や状況に基づくフィードバック遅延制御を行う。本開示では、アプリケーションを「アプリ」と表記する場合がある。以下、アプリケーションがクラウドゲームである場合について説明する。

図３に、端末の構成例を示す。端末９３は、通信ＩＦ（Ｉｎｔｅｒｆａｃｅ）３１、クライアントアプリ３２、往復遅延測定要求応答部３３を備える。
通信ＩＦ（Ｉｎｔｅｒｆａｃｅ）３１は、クラウドゲームサーバ９４と通信を行う。
クライアントアプリ３２は、クラウドゲームサーバ９４の提供するゲームコンテンツを実行する。
往復遅延測定要求応答部３３は、クラウドゲームサーバ９４から送信された往復遅延測定パケットをクラウドゲームサーバ９４に送り返す。

図４に、クラウドゲームサーバの構成例を示す。クラウドゲームサーバ９４は、通信ＩＦ４１、サーバアプリ４２、往復遅延測定要求部４３、往復遅延情報テーブル４４、往復遅延情報送信部４５、ゲーム属性情報テーブル４６、ゲーム属性情報送信部４７を備える。

通信ＩＦ４１は、端末９３及びコントローラ装置９５と通信を行う。
サーバアプリ４２は、端末９３にゲームコンテンツを提供する。
往復遅延測定要求部４３は、往復遅延測定パケットを端末９３に送信する。
往復遅延情報テーブル４４は、各端末９３との往復遅延時間を格納する。
往復遅延情報送信部４５は、往復遅延情報テーブル４４に記載の往復遅延情報を読み取り、往復遅延情報パケットとしてコントローラ装置９５に送信する。
ゲーム属性情報テーブル４６は、ゲームコンテンツの属性を示すゲーム属性情報を格納する。
ゲーム属性情報送信部４７は、ゲーム属性情報テーブル４６からゲーム属性情報を読み取り、ゲーム属性情報パケットとしてコントローラ装置９５に送信する。

図５に、往復遅延情報テーブルの一例を示す。往復遅延情報テーブルは、各クラウドゲームサーバ９４#１～９４＃３の測定した往復遅延時間を格納する。例えば、クラウドゲームサーバ９４#１には端末９３＃１との往復遅延時間ＴＲ＿１が格納され、クラウドゲームサーバ９４#２には端末９３＃２との往復遅延時間ＴＲ＿２が格納され、クラウドゲームサーバ９４#３には端末９３＃３，９３＃４との往復遅延時間ＴＲ＿３，ＴＲ＿４が格納される。

図６に、ゲーム属性情報テーブルの一例を示す。ゲーム属性情報テーブルは、各クラウドゲームサーバ９４#１～９４＃３の提供するゲームコンテンツの属性情報を格納する。例えば、クラウドゲームサーバ９４#１のゲーム属性はアクションゲームであり、クラウドゲームサーバ９４#２のゲーム属性はカードゲームであり、クラウドゲームサーバ９４#３のゲーム属性は対戦型のアクションゲームである。ゲーム属性は、これらに限定されず、シューティングゲーム、シュミレーションゲーム、レーシングゲーム、アドベンチャーゲーム、ロールプレイングゲーム、パズルゲーム、音楽ゲーム、又は対戦型のこれらのゲームが例示できる。

図７に、コントローラ装置の構成例を示す。コントローラ装置９５は、ゲーム属性情報受信部５２、ゲーム属性情報ＤＢ５３、往復遅延情報受信部５４、往復遅延情報ＤＢ５５、クラウドゲーム品質制御ポリシーテーブル５６、遅延制御シェーピング設定値変更部５７を備える。
ゲーム属性情報受信部５２は、ゲーム属性情報パケットに記載のゲーム属性情報をゲーム属性情報ＤＢ５３に登録する。
ゲーム属性情報ＤＢ５３は、各クラウドゲームサーバ９４の提供するゲームコンテンツの属性情報を格納する。
往復遅延情報受信部５４は、往復遅延情報パケットに記載の往復遅延情報を往復遅延情報ＤＢ５５に登録する。
往復遅延情報ＤＢ５５は、各クラウドゲームサーバ９４の往復遅延情報を格納する。
クラウドゲーム品質制御ポリシーテーブル５６は、ゲーム属性に対応する目標フィードバック遅延時間を格納する。
遅延制御シェーピング設定値変更部５７は、遅延制御シェーピング設定値を算出し、遅延制御シェーピング機能９１に遅延制御シェーピング設定値変更パケットを送信する。

図８に、往復遅延情報ＤＢの一例を示す。各端末９３＃１～９３＃４の往復遅延情報がクラウドゲームサーバ９４の識別情報（ＩＤＳ＿１～ＩＤＳ＿３）に紐づけて格納されている。

図９に、ゲーム属性情報ＤＢの一例を示す。例えば、クラウドゲームサーバ９４＃１の提供するゲームＩＤＧ＿１のゲーム属性はアクションゲームであり、クラウドゲームサーバ９４＃２の提供するゲームＩＤＧ＿２のゲーム属性はカードゲームであり、クラウドゲームサーバ９４＃３の提供するゲームＩＤＧ＿３のゲーム属性は対戦型アクションゲームである。

図１０に、クラウドゲーム品質制御ポリシーテーブルの一例を示す。クラウドゲーム品質制御ポリシーテーブルは、ゲーム属性ごとの目標フィードバック遅延時間を定める。例えば、アクションゲームの目標フィードバック遅延時間ＴＯ＿１はカードゲームの目標フィードバック遅延時間ＴＯ＿２よりも短い。また、対戦型アクションゲームの目標フィードバック遅延時間ＴＯ＿３は、対戦相手の端末９３＃３及び９３＃４で一定のＴＯ＿３である。

図１１に、遅延制御シェーピング機能の構成例を示す。遅延制御シェーピング機能９１は、通信ＩＦ１１、１２、メータリング部１３、入力パケット量記録メモリ１４、トークン供給関数計算部１５、遅延パラメータ設定部１６、遅延パラメータテーブル１７、トークン供給関数メモリ１８、トークン供給部１９、シェーピング部２０を備える。シェーピング部２０は、キュー２１、トークンバケツ２２、送信判定機能部２３を備える。
通信ＩＦ１１は、端末９３及びコントローラ装置９５と通信を行う。
メータリング部１３は、クラウドゲームサーバ９４から受信した入力パケットのデータ量を測定し、入力パケットをキュー２１に格納する。
入力パケット量記録メモリ１４は、入力パケットのデータ量を記録する。
トークン供給関数計算部１５は、入力パケットの最大遅延揺らぎがＪｍａｘになるよう、トークン供給関数を計算する。
遅延パラメータ設定部１６は、遅延制御シェーピング設定値変更パケットに記載の許容遅延揺らぎ値を遅延制御シェーピングの最大遅延揺らぎＪｍａｘを、遅延パラメータテーブル１７に設定する。
遅延パラメータテーブル１７は、端末９３ごとかつクラウドゲームサーバ９４ごとに、最大遅延揺らぎＪｍａｘを格納する。
トークン供給関数メモリ１８は、トークン供給関数計算部１５の計算したトークン供給関数を記憶する。
トークン供給部１９は、トークン供給関数メモリ１８に記憶されたトークン供給関数に従い、トークンをシェーピング部２０に供給する。
シェーピング部２０は、供給されたトークンに応じて、キュー２１に格納されている入力パケットを遅延させ、端末９３に送信する。

図１２は、トークン供給関数計算部１５が実行する通信フロー毎トークン供給関数Ｔｓ（ｔ）更新処理フロー（Ｓ１５０）を示したものである。トークン供給量制御機能は、１の所定期間における入力されたパケットの量で計算したトークンの１の供給期間と、１の所定期間の後の所定期間における入力されたパケットの量で計算したトークンの後の供給期間とが重複する場合、１の供給期間と後の供給期間が重複する期間において、１の所定期間における入力されたパケットの量で計算したトークンの量に後の所定期間における入力されたパケットの量で計算したトークンの量を加算する。

本更新処理は、トークン供給関数更新周期毎に実行する。今回処理実行時刻をｔ＿ｎｏｗ、現在のトークン供給関数をｎｏｗ＿Ｔｓ（ｔ）、前回処理実行時から今回処理実行時までにメータリング部１３から通知されたバイト量の合計をＢｍ、トークン供給周期をＴｃ、トークン供給関数更新周期をＴｕ、トークン供給関数反映周期をＴｒ、対象通信フローの要求遅延時間をＤｄ、遅延パラメータテーブル１７を用いて計算された対象通信フローの通信経路の遅延時間をＤｒとする（ステップＳ１５１）。

要求遅延を満足しながら追加できる遅延時間であるＤａを次の式で計算する（ステップＳ１５２）。
Ｄａ＝Ｄｄ－Ｄｒ－Ｔｕ－Ｔｒ

今回の処理実行で追加するトークン供給関数ａｄｄ＿Ｔｓ（ｔ）を次の式で計算する（ステップＳ１５３）。
（１）ｔがｔ＿ｎｏｗ＋Ｔｒ＜ｔ≦ｔ＿ｎｏｗ＋Ｔｒ＋Ｄａの場合
ａｄｄ＿Ｔｓ（ｔ）＝（Ｂｍ／Ｄａ）×Ｔｃ
（２）上記以外のｔの場合
ａｄｄ＿Ｔｓ（ｔ）＝０

ａｄｄ＿Ｔｓ（ｔ）が小数となっている場合には、ａｄｄ＿Ｔｓ（ｔ）の合計値がＢｍと等しくなるように切り上げ又は切り捨てなどの正規化を行う（ステップＳ１５４）。今回の処理実行でＴｓ（ｔ）として更新するトークン供給関数ｎｅｗ＿Ｔｓ（ｔ）を次の式で計算する（ステップＳ１５５）。
ｎｅｗ＿Ｔｓ（ｔ）＝ｎｏｗ＿Ｔｓ（ｔ）＋ａｄｄ＿Ｔｓ（ｔ）

ｎｅｗ＿Ｔｓ（ｔ）をｔ＝ｔ＿ｎｏｗ＋Ｔｒ以降の新たなＴｓ（ｔ）としてトークン供給関数メモリ１８を更新し、トークン供給部１９に設定する（ステップＳ１５６）。

図１３は、トークン供給部１９が実行する通信フロー毎トークン供給処理フロー（Ｓ１６０）を示したものである。本更新処理は、トークン供給周期毎に実行する。処理実行時刻をｔ＿ｎｏｗとする（ステップＳ１６１）。ｔ＝ｔ＿ｎｏｗにおけるＴｓ（ｔ）の値の量のトークンを当該通信フローのシェーピング部２０に供給する（ステップＳ１６２）。

図１４に、クラウドゲームサーバ９４が往復遅延を取得するフローの一例を示す。
クラウドゲームサーバ９４の往復遅延測定要求部４３は、往復遅延測定パケットを端末９３に送信する（Ｓ１１１）。ここで、往復遅延測定パケットは、Ｐｉｎｇのようなネットワークの疎通を確認するために使用されるコマンドを用いることができる。
端末９３は、往復遅延測定パケットを受信すると往復遅延測定要求応答部３３に転送する（Ｓ１１２）。往復遅延測定要求応答部３３は、往復遅延測定パケットを受信すると、即座に往復遅延測定パケットをクラウドゲームサーバ９４に送り返す（Ｓ１１３）。
クラウドゲームサーバ９４は、返送された往復遅延測定パケットを受信すると、送信してから受信するまでにかかった時間を往復遅延時間として計測し、往復遅延時間と端末ＩＤを往復遅延情報テーブル４４に記録する（Ｓ１１４）。
なお、フロー開始契機は、クラウドゲームを開始するときに一回実行してもいいし定期的に実行してもよい。

図１５に、コントローラ装置９５がゲーム属性情報を収集するフローの一例を示す。
ゲーム属性情報送信部４７は、ゲーム属性情報テーブル４６からゲーム属性情報を読み取り、ゲーム属性情報パケットとしてコントローラ装置９５に送信する（Ｓ１２１）。
コントローラ装置９５は、ゲーム属性情報パケットを受信すると、ゲーム属性情報受信部５２に転送する（Ｓ１２２）。ゲーム属性情報受信部５２は、ゲーム属性情報パケットに記載のゲーム属性情報をゲーム属性情報ＤＢ５３に登録する（Ｓ１２３）。
なお、フロー開始契機は、クラウドゲームを開始するときに一回実行してもいいし定期的に実行してもよい。

図１６に、クラウドゲームサーバ９４が往復遅延情報を収集するフローの一例を示す。
往復遅延情報送信部４５は、往復遅延情報テーブル４４に記載の往復遅延情報を読み取り、往復遅延情報パケットとしてコントローラ装置９５に送信する（Ｓ１３１）。
コントローラ装置９５は、往復遅延情報パケットを受信すると、往復遅延情報受信部５４に転送する（Ｓ１３２）。往復遅延情報受信部５４は、往復遅延情報パケットに記載の往復遅延情報を往復遅延情報ＤＢ５５に登録する（Ｓ１３３）。
フロー開始契機は、クラウドゲームを開始するときに一回実行してもいいし定期的に実行してもよい。

図１７に、遅延制御シェーピング機能９１がシェーピング設定値を変更するフローの一例を示す。コントローラ装置９５の遅延制御シェーピング設定値変更部５７は、ゲーム属性情報ＤＢ５３から、ゲーム属性情報を読み取る（Ｓ１４１）。遅延制御シェーピング設定値変更部５７は、ゲーム属性情報に記載のゲーム属性に関する目標フィードバック遅延時間を、クラウドゲーム品質制御ポリシーテーブル５６から読み取る（Ｓ１４２）。遅延制御シェーピング設定値変更部５７は、ゲーム属性情報に記載の端末ＩＤとクラウドゲームサーバＩＤに関する往復遅延情報を、往復遅延情報ＤＢから読み取る（Ｓ１４３）。遅延制御シェーピング設定値変更部５７は、目標フィードバック遅延時間から往復遅延情報を減算した値を許容遅延揺らぎ値として算出する（Ｓ１４４）。遅延制御シェーピング設定値変更部５７は、算出した許容遅延揺らぎ値を、当該クラウドゲームサーバＩＤに対応した遅延制御シェーピング機能９１に、遅延制御シェーピング設定値変更パケットとして送信する（Ｓ１４５）。
遅延制御シェーピング機能９１は、遅延制御シェーピング設定値変更パケットを受信すると、遅延パラメータ設定部１６に転送する（Ｓ１４６）。遅延パラメータ設定部１６は、遅延制御シェーピング設定値変更パケットに記載の許容遅延揺らぎ値を遅延制御シェーピングの最大遅延揺らぎＪｍａｘとして設定する（Ｓ１４７）。
なお、フロー開始契機は、クラウドゲームを開始するときに一回実行してもいいし定期的に実行してもいい。

遅延制御シェーピング機能９１は、クラウドゲームサーバ９４からパケットを受信すると、メータリング部１３に転送する。
トークン供給関数メモリ１８は、トークン供給関数計算部１５の計算したトークン供給関数を記憶する。
メータリング部１３は、パケットのデータ量を測定し、入力パケット量記録メモリに記録する。またメータリング部１３は、クラウドゲームサーバ９４から受信したパケットをキュー２１に蓄積する。
トークン供給関数計算部１５は、遅延パラメータテーブル１７を参照し、入力パケットの最大遅延揺らぎがＪｍａｘになるよう、トークン供給関数を計算する。
トークン供給部１９は、トークン供給関数メモリ１８に記憶されたトークン供給関数に従い、トークンをシェーピング部２０に供給する。
送信判定機能部２３は、供給されたトークンに応じて、キュー２１に格納されている入力パケットを遅延させ、端末９３に送信する。

以上説明したように、本実施形態は、ゲームコンテンツの属性に応じた目標フィードバック遅延時間を設定し、該目標フィードバック遅延時間を満足するように遅延制御シェーピング処理を実行する。上述の実施形態では、クラウドゲームサーバ９４がゲームコンテンツを端末９３に提供する例を示したが、ゲームコンテンツに限らず任意のアプリケーションに適用することができる。したがって、本開示は、クラウドゲーム等のアプリケーションで求められる操作性を損なうことなく、輻輳制御を行うことができる。

発明の装置はコンピュータとプログラムによっても実現でき、プログラムを記録媒体に記録することも、ネットワークを通して提供することも可能である。

本開示は情報通信産業に適用することができる。

１１、１２、３１、４１、５１：通信ＩＦ
１３：メータリング部
１４：入力パケット量記録メモリ
１５：トークン供給関数計算部
１６：遅延パラメータ設定部
１７：遅延パラメータテーブル
１８：トークン供給関数メモリ
１９：トークン供給部
２０：シェーピング部
２１：キュー
２２：トークンバケツ
２３：送信判定機能部
３２：クライアントアプリ
４２：サーバアプリ
４３：往復遅延測定要求部
４４：往復遅延情報テーブル
４５：往復遅延情報送信部
４６：ゲーム属性情報テーブル
４７：ゲーム属性情報送信部
５２：ゲーム属性情報受信部
５３：ゲーム属性情報ＤＢ
５４：往復遅延情報受信部
５５：往復遅延情報ＤＢ
５６：クラウドゲーム品質制御ポリシーテーブル
５７：遅延制御シェーピング設定値変更部
９１：遅延制御シェーピング機能
９２：ネットワーク
９３：端末
９４：クラウドゲームサーバ
９５：コントローラ装置

Claims (10)

1. アプリケーションのトラフィックを制御する通信システムであって、
   前記アプリケーションは、ゲームであり、
   ゲームの属性に応じた目標フィードバック遅延時間を設定し、該目標フィードバック遅延時間を満足するようにトラヒック制御を実行する、
   通信システム。
2. アプリケーションのトラフィックを制御する通信システムであって、
   アプリケーションの種類に応じて目標フィードバック遅延時間が設定されており、
   アプリケーションを端末に提供するサーバと、
   目標フィードバック遅延時間を設定するコントローラと、
   前記サーバと前記端末の間に接続され、前記目標フィードバック遅延時間を満足するように遅延制御シェーピング処理を実行する遅延制御シェーピング機能と、
   を備える通信システム。
3. アプリケーションのトラフィックを制御する通信システムであって、
   アプリケーションの種類に応じて目標フィードバック遅延時間が設定されており、
   サーバと端末の間に接続されている遅延制御シェーピング機能が、前記目標フィードバック遅延時間を満足するように遅延制御シェーピング処理を実行する、
   通信システム。
4. 前記アプリケーションは、複数の端末に提供され、
   前記複数の端末に等しい前記目標フィードバック遅延時間が設定されている、
   請求項１から３のいずれかに記載の通信システム。
5. アプリケーションのトラフィックを制御するコントローラ装置が実行する通信方法であって、
   前記アプリケーションは、ゲームであり、
   コントローラ装置が、ゲームの属性に応じた目標フィードバック遅延時間を設定し、該目標フィードバック遅延時間を満足するようにトラヒック制御を実行する、
   通信方法。
6. アプリケーションのトラフィックを制御するコントローラ装置が実行する通信方法であって、
   コントローラ装置が、アプリケーションの種類に応じた目標フィードバック遅延時間を設定し、サーバと端末の間に接続されている遅延制御シェーピング機能に、該目標フィードバック遅延時間を満足するように遅延制御シェーピング処理を実行させる、
   通信方法。
7. ゲームの属性に応じた目標フィードバック遅延時間を保持し、
   トラヒック制御機能から目標フィードバック遅延時間の問い合わせを受けると、問い合わせのあったゲームの属性に応じた目標フィードバック遅延時間を設定し、前記トラヒック制御機能に、該目標フィードバック遅延時間を満足するようにトラヒック制御を実行させる、
   コントローラ装置。
8. アプリケーションの種類に応じた目標フィードバック遅延時間を保持し、
   サーバと端末の間に接続されている遅延制御シェーピング機能から目標フィードバック遅延時間の問い合わせを受けると、問い合わせのあったアプリケーションの種類に応じた目標フィードバック遅延時間を設定し、前記遅延制御シェーピング機能に、該目標フィードバック遅延時間を満足するように遅延制御シェーピング処理を実行させる、
   コントローラ装置。
9. コントローラ装置に、
   ゲームの属性に応じた目標フィードバック遅延時間を保持する機能と、
   トラヒック制御機能から目標フィードバック遅延時間の問い合わせを受けると、問い合わせのあったゲームの属性に応じた目標フィードバック遅延時間を設定し、前記トラヒック制御機能に、該目標フィードバック遅延時間を満足するようにトラヒック制御を実行させる機能と、
   を実現させるためのプログラム。
10. コントローラ装置に、
    アプリケーションの種類に応じた目標フィードバック遅延時間を保持する機能と、
    サーバと端末の間に接続されている遅延制御シェーピング機能から目標フィードバック遅延時間の問い合わせを受けると、問い合わせのあったアプリケーションの種類に応じた目標フィードバック遅延時間を設定し、前記遅延制御シェーピング機能に、該目標フィードバック遅延時間を満足するように遅延制御シェーピング処理を実行させる機能と、
    を実現させるためのプログラム。

Images