JP7424465B2

JP7424465B2 - 制御装置、制御方法及びプログラム

Info

Publication number: JP7424465B2
Application number: JP2022501609A
Authority: JP
Inventors: 英朗金正; 拓人木村; 太一河野; 和久山岸
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2020-02-21
Filing date: 2020-08-27
Publication date: 2024-01-30
Anticipated expiration: 2040-08-27
Also published as: JPWO2021166288A1; US20230103218A1; WO2021166251A1; WO2021166288A1; US11805074B2

Description

特許法第３０条第２項適用２０２０年３月３日に電子情報通信学会２０２０年総合大会講演論文集にて発表

本発明は、制御装置、制御方法及びプログラムに関する。

映像配信サービスの高品質化・Ｗｅｂセッションの増加等の影響により、ネットワークを流れるトラヒック量が急激に増加している。現在のネットワークでは、有限の帯域を多くのユーザが共有しているため、こうしたトラヒック量の増加は、スループットの低下、パケットロス率の増加など、ネットワーク品質（ＱｏＳ：Quality of Service）の低下を引き起こす。さらに、このようなＱｏＳの低下は、ユーザ体感品質（ＱｏＥ：Quality of Experience）の低下をもたらす可能性がある。

また、現在のネットワークでは、ボトルネック機器とそのインタフェースが一箇所に特定されるケースが多い。各インタフェースでは、各セッションに帯域を割り当てることで品質の制御を行っている。したがって、各セッションに対して適切な割当帯域を決定し、それに基づいて帯域の割当を実施することが重要である。

多くのユーザがネットワークを介したサービスを快適に利用するためには、ＱｏＥの低いユーザ数（セッション数）を減少させたり、全ユーザ（セッション）のＱｏＥの平均値を増加させるなど、ＱｏＥを考慮することが重要である。既存の帯域制御方式として、ＲｏｕｎｄＲｏｂｉｎがある（非特許文献１）。この制御方式、は実ネットワークでも利用されており、ＱｏＳの観点で帯域を公平に割り当てる制御を実施する。また、ＱｏＥに基づいて割当帯域を制御する既存の帯域制御方式として、非特許文献２がある。

Remzi H. Arpaci-Dusseeau and Andrea C. Arpaci-Dusseau, "Operating Systems: Three Easy Pieces", Arpaci-Dusseau Books, 2018. T. Hori and T. Ohtsuki, "QoE and Throughput Aware Radio Resource Allocation Algorithm in LTE Network with Users using Different Applications", in Proc 27th Annual International Symposium on Personal, Indoor, Mobile Radio Communications (PIMRC), pp.1-6, Sep. 2016.

ＱｏＥの観点で制御を行うためには、ＭＯＳ（Mean Opinion Score）などの定量的なＱｏＥ指標に基づいた帯域制御を行う必要がある。また、ネットワークを利用するユーザ数は時々刻々と変化するため、こうしたネットワークの変化に対しても、動的に割当帯域を変更することで十分に帯域を活用する必要がある。

図１は、アプリケーションごとに異なるＱｏＳとＱｏＥの関係性の一例を示す図である。図１では、ＱｏＳとしてスループットを利用し、アプリケーションとして動画とＷｅｂを対象にした場合の、各アプリケーションに対するＱｏＳ（スループット）とＱｏＥの関係性がグラフによって示されている。

図１に示されるように、アプリケーションによってＱｏＳ（スループット）とＱｏＥの関係性が異なるため、同じＱｏＳであっても、アプリケーションによってＱｏＥが異なる。そのため、複数のアプリケーションそれぞれに対して適切に割当帯域の設定を行う必要がある。

しかし、既存の帯域制御方式には、これら全ての条件を満たすものはない。例えば、非特許文献１の帯域制御方式では、ＱｏＳが公平になるよう動的に割当帯域を変更することでネットワークの変化に対しても十分に帯域を活用できるが、定量的なＱｏＥには基づいておらず、かつ、アプリケーションごとに割当帯域を設定できない。

また、実ネットワークで利用されることがある５タプル（宛先ＩＰアドレス、宛先ポート番号、送信元ＩＰアドレス、送信元ポート番号、Ｌ４プロトコル）を用いた帯域制御方式は、５タプルからユーザ（セッション）ごとのアプリケーションを識別することで、アプリケーションごとに割当帯域を設定し、ネットワーク変化に対しても十分に帯域を活用できるが、定量的なＱｏＥ指標に基づいていない。

さらに、非特許文献２の帯域制御方式は、定量的なＱｏＥ指標に基づき、かつアプリケーションごとに割当帯域を設定することができるが、動的に割当帯域を変更することができないため、ネットワークの変化に対して十分に帯域を活用できない。

仮に、これら３つの既存方式を組み合わせた場合においても、定量的なＱｏＥ指標に基づき、かつ、アプリケーションごとに割当帯域を設定することはできるが、動的に割当帯域を変更することができず、ネットワークの変化に対して十分に帯域を活用できないため、上記の条件を全て満たすことはできない。これは、既存方式の組み合わせはアプリケーション状態を保持しておらず、通信途中のユーザ（セッション）に対するＱｏＥを適切に計算できないためである。

本発明は、上記の点に鑑みてなされたものであって、時間的に変化するネットワーク環境において複数種類のアプリケーションを制御対象とした場合におけるＱｏＥの低いセッションを削減可能とすることを目的とする。

そこで上記課題を解決するため、制御装置は、ネットワークにおいて通信中である、複数の種別のアプリケーションに係る複数のセッションのそれぞれについて、当該セッションに係るアプリケーションの種別に応じて異なるＱｏＥ予測値の計算方法において必要となる、前記種別に応じたアプリケーション情報を複数のタイミングで取得する取得部と、前記アプリケーションごとに当該アプリケーションの種別に応じた前記計算方法及び前記アプリケーション情報に基づいて計算することで得られる前記各セッションのＱｏＥ予測値と、前記ネットワークの帯域に対する条件とに基づいて、前記複数のセッションのそれぞれの割当帯域を前記複数のタイミングで探索する探索部と、前記探索部により探索された割当帯域に基づいて、前記各セッションに対する帯域の割当を前記複数のタイミングで制御する制御部と、を有する。

時間的に変化するネットワーク環境において複数種類のアプリケーションを制御対象とした場合におけるＱｏＥの低いセッション数を削減可能とすることができる。

アプリケーションごとに異なるＱｏＳとＱｏＥの関係性の一例を示す図である。第１の実施の形態における制御装置１０のハードウェア構成例を示す図である。第１の実施の形態における制御装置１０の機能構成例を示す図である。第１の実施の形態の制御装置１０が実行する処理手順の一例を説明するためのフローチャートである。アプリケーション情報記憶部１４の構成例を示す図である。第１の実施の形態における最適割当帯域の探索処理の処理手順の一例を説明するためのフローチャートである。第２の実施の形態における最適割当帯域の探索処理の処理手順の一例を説明するためのフローチャートである。第３の実施の形態における最適割当帯域の探索処理の処理手順の一例を説明するためのフローチャートである。第４の実施の形態における最適割当帯域の探索処理の処理手順の一例を説明するためのフローチャートである。第５の実施の形態における最適割当帯域の探索処理の処理手順の一例を説明するためのフローチャートである。

以下、図面に基づいて本発明の実施の形態を説明する。図２は、第１の実施の形態における制御装置１０のハードウェア構成例を示す図である。図２の制御装置１０は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、及びインタフェース装置１０５等を有する。

制御装置１０での処理を実現するプログラムは、ＣＤ－ＲＯＭ等の記録媒体１０１によって提供される。プログラムを記憶した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従って制御装置１０に係る機能を実行する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。

図３は、第１の実施の形態における制御装置１０の機能構成例を示す図である。制御装置１０は、通信に利用されている各セッションの情報を入力として、各セッションに対する最適な割当帯域を探索し、制御する。セッション情報は、５タプルで表される、セッションの識別情報である。５タプルは、宛先ＩＰアドレス、宛先ポート番号、送信元ＩＰアドレス、送信元ポート番号、Ｌ４プロトコルで表される組のことをいう。

図３において、制御装置１０は、アプリケーション情報取得部１１、最適割当帯域探索部１２及び最適割当帯域制御部１３等を有する。これら各部は、制御装置１０にインストールされた１以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。制御装置１０は、また、アプリケーション情報記憶部１４を利用する。これらアプリケーション情報記憶部１４は、例えば、補助記憶装置１０２、又は制御装置１０にネットワークを介して接続可能な記憶装置等を用いて実現可能である。

以下、制御装置１０が実行する処理手順について説明する。図４は、第１の実施の形態の制御装置１０が実行する処理手順の一例を説明するためのフローチャートである。図４の処理手順は、複数のタイミングで（例えば、定期的（例えば、２秒周期等）に）繰り返し実行される。

ステップＳ１０において、アプリケーション情報取得部１１は、入力された１以上のセッション情報に係る各セッション（以下、当該各セッションのそれぞれを「対象セッション」という。）に対応するアプリケーション情報をアプリケーション情報記憶部１４から取得する。なお、アプリケーション情報取得部１１には、現在通信中の各セッションのセッション情報が入力される。例えば、ネットワークを流れるパケットのヘッダ情報を取得することでこのようなセッション情報が取得されてもよい。

図５は、アプリケーション情報記憶部１４の構成例を示す図である。図５に示されるように、アプリケーション情報記憶部１４には、現在通信中の各セッションのセッション情報に対応付けてアプリケーション情報が記憶されている。ここで、アプリケーション情報は通信中に時々刻々と更新されるものと仮定する。したがって、アプリケーション情報記憶部１４に記憶されている情報は、ユーザ等によって入力されてもよいし、ネットワークを監視する装置など、外部装置によって自動的に入力されてもよい。又はアプリケーション情報取得部１１が、ネットワークを流れるパケット情報を取得し、パケット情報からアプリケーション情報を推定することで、アプリケーション情報記憶部１４を更新してもよい。

図５に示されるように、アプリケーション情報は、アプリケーション種別、バッファ長、再生停止情報、ビットレート系列及び通信時間等のパラメータを含む。図５の例では、Ｗｅｂのセッション（アプリケーション種別が「Ｗｅｂ」であるセッション）が１つ有り、動画のセッション（アプリケーション種別が「動画」であるセッション）が２つ有る例が示されている。

アプリケーション情報を構成するパラメータのうち、Ｗｅｂのセッション（以下、「Ｗｅｂセッション」という。）のアプリケーション情報は、アプリケーション種別及び通信時間から構成される。アプリケーション種別とは、セッションに対応するアプリケーションの種別である。本実施の形態では、アプリケーションの種別は「Ｗｅｂ」又は「動画」に分類される。通信時間とは、セッションが通信を開始してからほぼ現時点までの経過時間を表す。

一方、動画のセッション（以下、「動画セッション」という。）のアプリケーション情報は、アプリケーション種別、バッファ長、再生停止情報及びビットレート系列を含む。バッファ長とは、動画セッションのクライアント（例えば、ＰＣ（Personal Computer）、スマートフォン又はタブレット端末等の視聴端末）において、現在バッファリングされており、さらに未再生の動画データの時間長である。ここで、バッファリングとは、端末で受信した動画データを再生する前に端末のメモリ上に蓄積しておくことを意味する。再生停止情報とは、再生停止の発生時刻及び終了時刻の組の配列である。例えば、［（０，２）］は、再生停止が一回発生しており、通信開始から２秒後まで再生が停止していたことを表す。ビットレート系列とは、任意のメディア時間ごとの平均ビットレートの配列である。例えば、［７００，１０００］は、メディア時間で０秒から１０秒までの平均ビットレートが７００ｋｂｐｓであり、１０秒から２０秒までの平均ビットレートが１０００ｋｂｐｓであることを表す。但し、これらは一例であり、ＱｏＥ予測時に必要となる変数に応じて保持されるパラメータは異なってよい。ＱｏＥ予測時に必要となる変数の例として、上記以外にはフレームレートや解像度等が挙げられる。

続いて、最適割当帯域探索部１２は、各対象セッションに対するＱｏＥ予測値のうち、最小となるＱｏＥ予測値が増加するような、各対象セッションへの割当帯域（最適割当帯域）を探索する（Ｓ２０）。

ＱｏＥ予測値とは、各セッションに対して或る帯域を割り当てた後の少し先の時点において得られるＱｏＥの推定値をいう。少し先の時点とは、例えば、動画においては帯域割当時に受信中のチャンクを含めずに１チャンク先のチャンクを受信完了した時点等であり、Ｗｅｂにおいては、コンテンツに含まれる推定データ量（５００ＫＢなど）を受信完了した時点等である。但し、動画においては帯域割当時に受信中のチャンクを含めずにｈチャンク先のチャンクを受信完了した時点におけるＱｏＥの推定値がＱｏＥ予測値とされてもよい。Ｗｅｂにおいては、各セッションの通信開始から予め設定した時間分経過した時点におけるＱｏＥの推定値がＱｏＥ予測値とされてもよい。

続いて、最適割当帯域制御部１３は、最適割当帯域探索部１２によって探索された最適割当帯域に基づいて各セッションに対する割当帯域の制御を実施する（Ｓ３０）。例えば、ルータで制御を実施する場合、最適割当帯域制御部１３は、各セッションが単位時間当たりに送出することのできるデータ量を、最適割当帯域に基づく重み付けなどによって制御を実施する。例えば、全帯域が１０Ｍｂｐｓの帯域に３つのセッションがあり、（２Ｍｂｐｓ，２Ｍｂｐｓ，６Ｍｂｐｓ）と割当を実施する場合、各セッションに対する重みとして（０．２，０．２，０．６）を設定することで、最適割当帯域に基づく重み付けを行うことができる。

続いて、ステップＳ２０の詳細について説明する。図６は、第１の実施の形態における最適割当帯域の探索処理の処理手順の一例を説明するためのフローチャートである。

ステップＳ４００において、最適割当帯域探索部１２は、ｔａｒｇｅｔＱｏＥ、ｂｗ及びｂｗ'の各変数に初期値を設定する。ここで、ｔａｒｇｅｔＱｏＥ∈［１，５］は、対象となる全てのセッションｉ（ｉ＝１，２，…，Ｎ）が最低限満たすべきＱｏＥ予測値を表し、ｂｗ＝｛ｂｗ_ｉ｝∈Ｒ^Ｎは割当帯域候補ベクトル（但し、Ｒは実数の集合（以降についても同様））を表し、ｂｗ'＝｛ｂｗ_ｉ'｝∈Ｒ^Ｎは、最適割当を表し、割当帯域のＮ次元ベクトルで表される。

具体的には、最適割当帯域探索部１２は、ｔａｒｇｅｔＱｏＥに対して、初期値としてＱｏＥ_ｉｎｉｔを設定する。また、最適割当帯域探索部１２は、ｂｗ＝｛ｂｗ_ｉ｝∈Ｒ^Ｎにおける各要素ｂｗ_ｉ（ｉ＝１，２，…，Ｎ）に対して、初期値としてｂｗ_ｉｎｉｔを設定する。また、最適割当帯域探索部１２は、ｂｗ'に対して、初期値としてｂｗを設定（代入）する。ＱｏＥ_ｉｎｉｔには、例えば、１が設定され，ｂｗ_ｉｎｉｔには、例えば、１００ｋｂｐｓを設定されてもよい。

続くステップＳ４１０～Ｓ４９０において、最適割当帯域探索部１２は、帯域条件（閾値）が満たされなくなるまで、各対象セッションについて、品質条件を満たす割当帯域を探索する。品質条件は、各対象セッションのＱｏＥ予測値が満たすべき条件（閾値）を表しており、本実施の形態では、各対象セッションのＱｏＥ予測値がｔａｒｇｅｔＱｏＥ以上となることである。また、帯域条件は、割当帯域候補ベクトルｂｗの各要素ｂｗ_ｉの総和Σ_ｉ＝１ ^Ｎｂｗ_ｉが利用可能帯域ｂｗ_{ｔｏｔａｌ}以下となることである。

ステップＳ４１０において、最適割当帯域探索部１２は、変数ｉに１を代入する。変数ｉは、対象セッションのそれぞれを識別するための変数である。以下、ｉ番目の対象セッションを「セッションｉ」という。

ステップＳ４２０において、最適割当帯域探索部１２は、セッションｉのＱｏＥ予測値であるＱｏＥ_ｉ（ｉ＝１、２、…、Ｎ）をセッションｉのアプリケーション情報とｂｗ_ｉとに基づいて計算する。ＱｏＥ_ｉは、セッションｉに対してｂｗ_ｉを割り当てたときの少し先の時点におけるＱｏＥを表す。ＱｏＥ_ｉの予測は、ｂｗ_ｉからアプリケーション情報の予測値を計算するステップ、アプリケーション情報からＱｏＥ_ｉを計算するステップの２つに分かれる。

各ステップはセッションが動画かＷｅｂかによって異なるので、まずは動画に関して説明を行う。セッションｉに対応するアプリケーション種別が動画の場合、最適割当帯域探索部１２は、セッションｉにｂｗ_ｉを割り当てた場合の再生停止情報及びビットレート系列のそれぞれの予測値を計算する。再生停止情報およびビットレート系列は、チャンク長およびビットレート選択アルゴリズムを用いて推定する。

そこで、まずはチャンク長とビットレート選択アルゴリズムについて説明する。チャンク長は、１つの動画コンテンツを複数の塊に分割した際の、１つの塊がもつ動画の長さを意味する。また、この１つの塊をチャンクという。例えば、６０秒の動画を３０個のチャンクに分割した場合、チャンク長は２秒となる。チャンク長は、動画配信サービス事業者の設定ごとに異なるため、各動画配信サービス事業者の動画をダウンロードする際に端末で測定してもよいし、一般的に利用されているチャンク長を代表値として利用してもよい。また、それぞれのチャンクは、複数のビットレートで再エンコードされて配信サーバに保存されている。動画プレイヤは、ビットレート選択アルゴリズムを用いて現在のネットワーク状況・バッファ状況に適したビットレートを選択し、そのビットレートでエンコードされたチャンクを要求する。動画プレイヤは、チャンクを受信しながら随時再生を行っていく。ビットレート選択アルゴリズムの例として、直近のチャンクを受信した際の平均スループットを超えない最大のビットレートを選択するアルゴリズムがある。ビットレート選択アルゴリズムもチャンク長と同様に、動画配信事業者の動画をダウンロードする際にアルゴリズムの挙動を測定して推定してもよいし、特定のアルゴリズムが使われているものと仮定してもよい。

これらを用いて再生停止情報およびビットレート系列の推定値が計算される。まず、ビットレート系列は、ビットレート選択アルゴリズムに従って推定することができる。例えば、現在のビットレート系列を［７００，１０００］、選択アルゴリズムに従って選択されたビットレートを５００ｋｂｐｓとすると、ビットレート系列は［７００，１０００，５００］のように計算される。再生停止情報は、バッファ長の推移を推定することにより推定することができる。例えば、バッファ長が実時間で２秒から４秒まで０であった場合、再生停止が１回発生し、再生停止時間が２秒であったと判断できる。バッファ長の推移は、ビットレート選択アルゴリズムとチャンク長およびｂｗ_ｉを用いて推定できる。例として、チャンク長を２秒、現在のバッファ長を１秒、ｂｗ_ｉを２５０ｋｂｐｓ、現在の再生停止情報を［（０，２）］、現在の時刻を４、次に要求するチャンクのビットレートを５００ｋｂｐｓとした場合を考える。ここで、５００ｋｂｐｓはビットレート選択アルゴリズムに従って決定したものとする。要求したチャンクを受信するためには５００ｋｂｐｓ×２秒＝１０００ｋｂｉｔｓのデータを受信する必要があるため、２５０ｋｂｐｓの帯域で受信すると、受信に４秒かかる。現在のバッファ長は１秒であるため、１秒後にバッファ長は０となり、再生停止状態が３秒経過した後にチャンクの受信が完了しバッファ長が２秒になると計算することができる。このとき、再生停止情報は［（０，２），（５，８）］と推定することができる。

一方、セッションｉに対応するアプリケーション種別がＷｅｂの場合、最適割当帯域探索部１２は、セッションｉにｂｗ_ｉを割り当てた場合の少し先の時点における通信時間の推定値を計算する。通信時間は、Ｗｅｂコンテンツサイズを用いて推定する。例えば、Ｗｅｂコンテンツサイズを５００ｋＢ、ｂｗ_ｉを１０００ｋｂｐｓとした場合、通信時間は５００×８／１０００＝４秒と計算することができる。ここで、バイトとビットの単位を変換するため、Ｗｅｂコンテンツサイズを８倍した。Ｗｅｂコンテンツサイズは、事前に代表的なＷｅｂサイトのコンテンツサイズを実際にダウンロードすることで取得し、それらの平均値を用いてもよい。次に、最適割当帯域探索部１２は、推定されたアプリケーション情報を公知のＱｏＥ推定モデルに入力することで、ＱｏＥ_ｉを計算する。例えば、セッションｉに対応するアプリケーション種別が動画の場合、再生停止情報及びビットレート系列のそれぞれの推定値が、公知のＱｏＥ推定モデル（例えば、「K. Yamagishi, and T. Hayashi, "Parametric Quality-Estimation Model for Adaptive-Bitrate-Streaming Services", IEEE Transactions on Multimedia, vol. 19, no. 7, pp. 1545-1557, Jul. 2017」参照）に入力されることで計算されてもよい。一方、セッションｉに対応するアプリケーション種別がＷｅｂの場合、通信時間の推定値が、公知のＱｏＥ推定モデル（例えば、「T. Tominaga, et al., "Web-Browsing QoE Estimation Model", IEICE Transactions on Communications, vol. E100-B, no. 10, pp. 1837-1845, Oct. 2017」参照）に入力されることで計算されてもよい。

なお、ｂｗ_ｉをセッションｉに割り当てた場合の少し先の時点における再生停止情報及びビットレート系列のそれぞれの推定値や、ｂｗ_ｉをセッションｉに割り当てた場合の少し先の時点における通信時間の推定値については、例えば、或るセッションに関して、割当帯域ごとに実験によって得られた値が予め補助記憶装置１０２等に記憶されており、当該値が推定値として利用されてもよい。

続いて、最適割当帯域探索部１２は、ＱｏＥ_ｉがｔａｒｇｅｔＱｏＥ以上であるか否かを判定する（Ｓ４３０）。すなわち、ＱｏＥ_ｉが品質条件を満たすか否かが判定される。

ＱｏＥ_ｉがｔａｒｇｅｔＱｏＥ未満である場合（Ｓ４４０でＮｏ）、最適割当帯域探索部１２は、ｂｗ_ｉをαだけ増加してステップＳ４２０に戻る。したがって、ＱｏＥ_ｉがｔａｒｇｅｔＱｏＥ以上になるまでＱｏＥ_ｉの計算が繰り返される。なお、αは予め設定されるパラメータである。但し、ＱｏＥ_ｉ≧ｔａｒｇｅｔＱｏＥとなった場合、セッションｉの割当帯域はその時点におけるｂｗ_ｉとしてステップＳ４５０以降に進む。

一方、ＱｏＥ_ｉがｔａｒｇｅｔＱｏＥ以上である場合（Ｓ４４０でＹｅｓ）、最適割当帯域探索部１２は、変数ｉに１を加算して（Ｓ４５０）、変数ｉの値とＮ（対象セッションの総数）とを比較する（Ｓ４６０）。変数ｉの値がＮ以下である場合（Ｓ４５０でＮｏ）、最適割当帯域探索部１２は、セッションｉについてステップＳ４２０以降を実行する。変数ｉの値がＮより大きい場合（Ｓ４６０でＹｅｓ）、ステップＳ４７０へ進む。したがって、ステップＳ４７０へ進む時点において、全ての対象セッションについて、品質条件を満たすｂｗ_ｉが特定される。

ステップＳ４７０において、最適割当帯域探索部１２は、ｂｗが帯域条件を満たしているか否かを判定する。すなわち、割当帯域候補ベクトルｂｗの各要素ｂｗ_ｉの総和Σ_ｉ＝１ ^Ｎｂｗ_ｉが利用可能帯域ｂｗ_{ｔｏｔａｌ}以下であるか否かが判定される。

ｂｗが帯域条件を満たしている場合（Ｓ４７０でＹｅｓ）、最適割当帯域探索部１２は、ｂｗ'をｂｗに更新し（Ｓ４８０）、ｔａｒｇｅｔＱｏＥをβだけ増加させて（Ｓ４９０）、ステップＳ４１０以降を繰り返す。一方、ｂｗが帯域条件を満たしていない場合（Ｓ４７０でＮｏ）、最適割当帯域探索部１２は、ｂｗ'を最適割当帯域として最適割当帯域制御部１３に出力する（Ｓ５００）。

以下、具体例に基づいて、最適割当帯域の探索処理の処理手順を説明する。当該具体例において、ＱｏＥ_ｉｎｉｔ＝１．０、ｂｗ_ｉｎｉｔ＝２５０、α＝２５０、β＝１．０、ｂｗ_{ｔｏｔａｌ}＝１５００、Ｎ＝３とし、セッション１をＷｅｂセッション、セッション２をバッファ長５秒の動画セッション、セッション３をバッファ長３秒の動画セッションとする。

ステップＳ４００において、各変数の初期値は以下のように設定される。
ｔａｒｇｅｔＱｏＥ＝１．０、ｂｗ'＝ｂｗ＝（２５０，２５０，２５０）^Ｔ
ステップＳ４１０以降（１回目）において、各セッションについて、例えば、品質条件を満たす割当帯域ｂｗ_ｉが次のように探索される。
ｂｗ_１＝２５０の時、ＱｏＥ_１＝１．０≧ｔａｒｇｅｔＱｏＥ＝１．０
ｂｗ_２＝２５０の時、ＱｏＥ_２＝３．５≧ｔａｒｇｅｔＱｏＥ＝１．０
ｂｗ_３＝２５０の時、ＱｏＥ_３＝２．５≧ｔａｒｇｅｔＱｏＥ＝１．０
この場合、全てのｂｗ_ｉが初期値の状態で品質条件を満たすためαによって更新することなくステップＳ４７０へ進む。

ステップＳ４７０（１回目）において、対象セッション全体について、帯域条件を満たすか否かが以下のように判定される。
ｂｗ_１＋ｂｗ_２＋ｂｗ_３＝２５０＋２５０＋２５０＝７５０≦ｂｗ_{ｔｏｔａｌ}＝１５００
この場合、帯域条件を満たすため、ｔａｒｇｅｔＱｏＥ及びｂｗ'のそれぞれが次のように更新されてステップＳ４１０に戻る。
ｔａｒｇｅｔＱｏＥ＝ｔａｒｇｅｔＱｏＥ＋β＝１．０＋１．０＝２．０
ｂｗ'＝ｂｗ＝（２５０，２５０，２５０）^Ｔ
ステップＳ４１０以降（２回目）において、ｂｗ_１＝２５０の時、ＱｏＥ_１＝１．０＜ｔａｒｇｅｔＱｏＥ＝２．０のため、ｂｗ_１が以下のように更新される。
ｂｗ_１＝ｂｗ_１＋α＝２５０＋２５０＝５００
その後、例えば、各セッションについて、品質条件を満たす割当帯域ｂｗ_ｉが次のように探索される。
ｂｗ_１＝５００の時、ＱｏＥ_１＝２．０≧ｔａｒｇｅｔＱｏＥ＝２．０
ｂｗ_２＝２５０の時、ＱｏＥ_２＝３．５≧ｔａｒｇｅｔＱｏＥ＝２．０
ｂｗ_３＝２５０の時、ＱｏＥ_３＝２．５≧ｔａｒｇｅｔＱｏＥ＝２．０
この状態で全てのｂｗ_ｉが品質条件を満たすためステップＳ４７０へ進む。

ステップＳ４７０（２回目）において、対象セッション全体について、帯域条件を満たすか否かが以下のように判定される。
ｂｗ_１＋ｂｗ_２＋ｂｗ_３＝５００＋２５０＋２５０＝１０００≦ｂｗ_{ｔｏｔａｌ}＝１５００
この場合、帯域条件を満たすため、ｔａｒｇｅｔＱｏＥ及びｂｗ'のそれぞれが次のように更新されてステップＳ４１０に戻る。
ｔａｒｇｅｔＱｏＥ＝ｔａｒｇｅｔＱｏＥ＋β＝２．０＋１．０＝３．０
ｂｗ'＝ｂｗ＝（５００，２５０，２５０）^Ｔ
ステップＳ４１０以降（３回目）において、ｂｗ_１＝５００の時、ＱｏＥ_１＝２．０＜ｔａｒｇｅｔＱｏＥ＝３．０のため、ｂｗ_１が以下のように更新される。
ｂｗ_１＝ｂｗ_１＋α＝５００＋２５０＝７５０
その後、各セッションについて、例えば、品質条件を満たす割当帯域ｂｗ_１及びｂｗ_２が次のように探索される。
ｂｗ_１＝７５０の時、ＱｏＥ_１＝３．０≧ｔａｒｇｅｔＱｏＥ＝３．０
ｂｗ_２＝２５０の時、ＱｏＥ_２＝３．５≧ｔａｒｇｅｔＱｏＥ＝３．０
一方、ｂｗ_３＝２５０の時、ＱｏＥ_３＝２．５＜ｔａｒｇｅｔＱｏＥ＝３．０のため、ｂｗ_３が以下のように更新される。
ｂｗ_３＝ｂｗ_３＋α＝２５０＋２５０＝５００
その結果、品質条件を満たす割当帯域ｂｗ_３が次のように探索される。
ｂｗ_３＝５００の時、ＱｏＥ_３＝３．０≧ｔａｒｇｅｔＱｏＥ＝３．０
この状態で全てのｂｗ_ｉが品質条件を満たすためステップＳ４７０へ進む。

ステップＳ４７０（３回目）において、対象セッション全体について、帯域条件を満たすか否かが以下のように判定される。
ｂｗ_１＋ｂｗ_２＋ｂｗ_３＝７５０＋２５０＋５００＝１５００≦ｂｗ_{ｔｏｔａｌ}＝１５００
この場合、帯域条件を満たすため、ｔａｒｇｅｔＱｏＥ及びｂｗ'のそれぞれが次のように更新されてステップＳ４１０に戻る。
ｔａｒｇｅｔＱｏＥ＝ｔａｒｇｅｔＱｏＥ＋β＝３．０＋１．０＝４．０
ｂｗ'＝ｂｗ＝（７５０，２５０，５００）^Ｔ
ステップＳ４１０以降（４回目）において、ｂｗ_１＝７５０の時、ＱｏＥ_１＝３．０＜ｔａｒｇｅｔＱｏＥ＝４．０のため、ｂｗ_１が以下のように更新される。
ｂｗ_１＝ｂｗ_１＋α＝７５０＋２５０＝１０００
ｂｗ_１＝１０００の時、ＱｏＥ_１＝４．０≧ｔａｒｇｅｔＱｏＥ＝４．０
ｂｗ_２＝２５０の時、ＱｏＥ_２＝３．５＜ｔａｒｇｅｔＱｏＥ＝４．０のため、ｂｗ_２が以下のように更新される。
ｂｗ_２＝ｂｗ_２＋α＝２５０＋２５０＝５００
その結果、品質条件を満たす割当帯域ｂｗ_２が次のように探索される。

ｂｗ_２＝５００の時、ＱｏＥ_２＝４．０≧ｔａｒｇｅｔＱｏＥ＝４．０、
ｂｗ_３＝５００の時、ＱｏＥ_３＝３．０＜ｔａｒｇｅｔＱｏＥ＝４．０のため、ｂｗ_３が以下のように更新される。
ｂｗ_３＝ｂｗ_３＋α＝５００＋２５０＝７５０
また、ｂｗ_３＝７５０の時、ＱｏＥ_３＝３．５＜ｔａｒｇｅｔＱｏＥ＝４．０のため、ｂｗ_３が以下のように更新される。
ｂｗ_３＝ｂｗ_３＋α＝７５０＋２５０＝１０００
その結果、品質条件を満たす割当帯域ｂｗ_２が次のように探索される。
ｂｗ_３＝１０００の時、ＱｏＥ_３＝４．０≧ｔａｒｇｅｔＱｏＥ＝４．０、
この状態で全てのｂｗ_ｉが品質条件を満たすためステップＳ４７０へ進む。

ステップＳ４７０（４回目）。において、対象セッション全体について、帯域条件を満たすか否かが以下のように判定される。
ｂｗ_１＋ｂｗ_２＋ｂｗ_３＝１０００＋５００＋１０００＝２５００＞ｂｗ_{ｔｏｔａｌ}＝１５００
この場合、帯域条件が満たされないため、現時点のｂｗ'＝（７５０，２５０，５００）^Ｔが出力され、探索が終了する。

上述したように、第１の実施の形態によれば、複数のタイミングにおいて、複数の種別のアプリケーションに対応する複数のセッションのそれぞれＱｏＥ予測値に基づいて、各セッションの割当帯域が探索される。

したがって、時間的に変化するネットワーク環境において複数種類のアプリケーションを制御対象とした場合におけるＱｏＥの低いセッション数を削減可能とすることができる。その結果、既存のネットワーク設備を効率的に利用しつつＱｏＥの低いセッション数をより削減することが可能となる。更に、将来の設備投資やユーザ解約リスクの低減が可能となる。

次に，第２の実施の形態について説明する。第２の実施の形態では第１の実施の形態と異なる点について説明する。第２の実施の形態において特に言及されない点については，第１の実施の形態と同様でもよい。

第２の実施の形態では、図４のステップＳ２０の処理手順が第１の実施の形態と異なる。第１の実施の形態において、動画セッションの割当帯域は、バッファ長予測値が考慮されずに決定される。バッファ長予測値を考慮しない場合、再生停止の発生リスクが増加し、最終的なＱｏＥの低下を引き起こす可能性が高まる。そこで、第２の実施の形態のステップＳ２０では、第１の実施の形態における品質条件に加え、動画セッションのバッファ長予測値が満たすべき条件が設定される。このような品質条件下で最適な割当帯域を探索するためには、割当帯域とＱｏＥ予測値の関係に加え、割当帯域とバッファ長予測値の関係が必要となる。後者の関係は、例えば、「池上大介, 本多泰理, 山本浩司, 野尻秀樹, 高橋玲, "プログレッシブダウンロード系サービスの停止時間推定法", 信学技報, vol. 111, no. 278, CQ2011-59, pp. 91-96, 2011年11月」に記載された技術を利用すれば予測可能である。

図７は、第２の実施の形態における最適割当帯域の探索処理の処理手順の一例を説明するためのフローチャートである。図７中、図６と同一ステップには同一ステップ番号を付し、その説明は適宜省略する。

図７では、ステップＳ４２０がＳ４２０ａに置換されている。また、ステップＳ４４０とＳ４５０との間に、ステップＳ４４１及びＳ４４２が追加されている。

ステップＳ４２０ａにおいて、最適割当帯域探索部１２は、ＱｏＥ予測値に加え、セッションｉのバッファ長予測値ｂｕｆｆｅｒ_ｉを計算する。

ステップＳ４４１及びＳ４４２は、品質条件に対して、ＱｏＥ_ｉがｔａｒｇｅｔＱｏＥ以上であることに加え、動画セッションｉのバッファ長予測値ｂｕｆｆｅｒ_ｉがバッファ長閾値ｂｕｆｆｅｒ_ｔｈ以上であるという条件が追加されることを実現するためのステップである。

すなわち、ステップＳ４４１において、最適割当帯域探索部１２は、セッションｉのアプリケーション種別が「動画」であるか否かを判定する。セッションｉのアプリケーション種別が「動画」である場合（Ｓ４４１でＹｅｓ）、最適割当帯域探索部１２は、セッションｉのバッファ長予測値ｂｕｆｆｅｒ_ｉがバッファ長閾値ｂｕｆｆｅｒ_ｔｈ以上であるか否かを判定する（Ｓ４４２）。バッファ長予測値ｂｕｆｆｅｒ_ｉがバッファ長閾値ｂｕｆｆｅｒ_ｔｈ未満である場合（Ｓ４４２でＮｏ）、ステップＳ４３０に進む。バッファ長予測値ｂｕｆｆｅｒ_ｉがバッファ長閾値ｂｕｆｆｅｒ_ｔｈ以上である場合（Ｓ４４２でＹｅｓ）、ステップＳ４５０へ進む。

次に、第３の実施の形態について説明する。第３の実施の形態では第１の実施の形態と異なる点について説明する。第３の実施の形態において特に言及されない点については、第１の実施の形態と同様でもよい。

第３の実施の形態では、図４のステップＳ２０の処理手順が第１の実施の形態と異なる。第３の実施の形態のステップＳ２０では、ＱｏＥ予測値があらかじめ与えられた閾値ｔａｒｇｅｔＱｏＥ以上となるセッション数が増加するように割当帯域が探索される。

図８は、第３の実施の形態における最適割当帯域の探索処理の処理手順の一例を説明するためのフローチャートである。図８中、図６と同一ステップには同一ステップ番号を付し、その説明は適宜省略する。

図８では、ステップＳ４００がＳ４００ａに置換されている。また、ステップＳ４１０～Ｓ４６０の代わりにステップＳ５１０及びＳ５２０が実行される。更に、ステップＳ４９０の代わりにステップＳ５３０が実行される。

ステップＳ４００ａにおいて、最適割当帯域探索部１２は、更に、変数Ｕを初期化（Ｕ＝｛１，２，…Ｎ｝）する。Ｕ＝｛１，２，…Ｎ｝は、セッション番号の集合を示す変数である。

ステップＳ５１０において、最適割当帯域探索部１２は、集合Ｕに係るセッションの中で、ＱｏＥ予測値ＱｏＥ_ｉがｔａｒｇｅｔＱｏＥ以上となるために必要な割当帯域が最も少ないセッションｉ'を計算（特定）する。なお、ステップＳ５１０において、ｆ_ｉ（ｂｗ）は、割当帯域ｂｗを入力としてＱｏＥ予測値ＱｏＥ_ｉを出力する関数を表す。

続くステップＳ５２０において、最適割当帯域探索部１２は、ｂｗ_ｉ'をＱｏＥ_ｉ'がｔａｒｇｅｔＱｏＥ以上となる最小の割当帯域とする。

また、ステップＳ５３０において、最適割当帯域探索部１２は、集合Ｕからｉ'を除いた差集合を集合Ｕに代入する。

最適割当帯域探索部１２は、上記の処理を帯域条件が満たされなくなるまで繰り返す（Ｓ４７０）。なお、第３の実施形態は、第２の実施の形態に記載した動画セッションのバッファ長に関する条件と組み合わせてもよい。この場合、ステップＳ５１０及びＳ５２０における条件の部分を「ｆ_ｉ（ｂｗ）≧ ｔａｒｇｅｔＱｏＥ＆＆ｂｕｆｆｅｒ_ｉ ≧ ｂｕｆｆｅｒ_ｔｈ」とすればよい。但し、アプリケーション種別が動画であるセッションにのみ「ｂｕｆｆｅｒ_ｉ ≧ ｂｕｆｆｅｒ_ｔｈ」の条件が適用されるようにする。

次に，第４の実施の形態について説明する。第４の実施の形態では第１の実施の形態と異なる点について説明する。第４の実施の形態において特に言及されない点については，第１の実施の形態と同様でもよい。

第４の実施の形態では、図４のステップＳ２０の処理手順が第１の実施の形態と異なる。第４の実施の形態のステップＳ２０では、ＱｏＥ予測値の平均が増加するように割当帯域が探索される。

図９は、第４の実施の形態における最適割当帯域の探索処理の処理手順の一例を説明するためのフローチャートである。図９中、図６と同一ステップには同一ステップ番号を付し、その説明は適宜省略する。

図９では、ステップＳ４００がＳ４００ｂに置換されている。また、ステップＳ４１０～Ｓ４６０の代わりにステップＳ６１０及びＳ６２０が実行され、ステップＳ４９０は実行されない。

ステップＳ４１０ｂでは、ｔａｒｇｅｔＱｏＥの初期化は行われない。図９の処理手順では、ｔａｒｇｅｔＱｏＥは使用されないからである。

ステップＳ６１０において、最適割当帯域探索部１２は、割当帯域をαだけ増加させた場合のＱｏＥ予測値の増加量が最大となるセッションｉ'を計算（特定）する。なお、ステップＳ６１０において、ｆ_ｉ（ｂｗ）は、割当帯域ｂｗを入力としてＱｏＥ予測値ＱｏＥ_ｉを出力する関数を表す。

続くステップＳ６２０において、最適割当帯域探索部１２は、ｂｗ_ｉ'をαだけ増加させる。

最適割当帯域探索部１２は、上記の処理を帯域条件が満たされなくなるまで繰り返す。なお、第４の実施形態は、第２の実施の形態に記載した動画セッションのバッファ長に関する条件と組み合わせてもよい。この場合、ステップＳ６１０において、アプリケーション種別が動画であるセッションについては、「ｂｕｆｆｅｒ_ｉ ≧ ｂｕｆｆｅｒ_ｔｈ」を満たすセッションのみが、セッションｉ'の候補とされるようにすればよい。

次に、第５の実施の形態について説明する。第５の実施の形態では第１の実施の形態と異なる点について説明する。第５の実施の形態において特に言及されない点については、第１の実施の形態と同様でもよい。

第５の実施の形態では、図４のステップＳ２０の処理手順が第１の実施の形態と異なる。第５の実施の形態のステップＳ２０では、ＱｏＥ予測値の最小値が増加するように割当帯域が探索される。

図１０は、第５の実施の形態における最適割当帯域の探索処理の処理手順の一例を説明するためのフローチャートである。図１０中、図９と同一ステップには同一ステップ番号を付し、その説明は適宜省略する。

図１０では、ステップＳ６１０の代わりにステップＳ６１０ａが実行される。ステップＳ６１０ａにおいて、最適割当帯域探索部１２は、現在の割当帯域ｂｗにおけるＱｏＥ予測値が最小となるセッションｉ'を計算（特定）する。なお、ステップＳ６１０ａにおいて、ｆ_ｉ（ｂｗ_ｉ）は、割当帯域ｂｗ_ｉを入力としてＱｏＥ予測値ＱｏＥ_ｉを出力する関数を表す。

なお、第５の実施形態は、第２の実施の形態に記載した動画セッションのバッファ長に関する条件と組み合わせてもよい。この場合、ステップＳ６１０ａにおいて、セッションｉ'のアプリケーション種別が動画であった場合、ステップＳ６２０において、セッションｉ'のバッファ予測値が「ｂｕｆｆｅｒ_ｉ' ≧ ｂｕｆｆｅｒ_ｔｈ」を満たすまで、ｂｗ_ｉ'にαを加え続けるようにすればよい。

なお、上記各実施の形態において、アプリケーション情報取得部１１は、取得部の一例である。最適割当帯域探索部１２は、探索部の一例である。最適割当帯域制御部１３は、制御部の一例である。

以上，本発明の実施の形態について詳述したが，本発明は斯かる特定の実施形態に限定されるものではなく，請求の範囲に記載された本発明の要旨の範囲内において，種々の変形・変更が可能である。

本出願は、２０２０年２月２１日に出願された国際特許出願第ＰＣＴ／ＪＰ２０２０／００７２２７号に基づきその優先権を主張するものであり、同国際特許出願の全内容を参照することにより本願に援用する。

１０制御装置
１１アプリケーション情報取得部
１２最適割当帯域探索部
１３最適割当帯域制御部
１４アプリケーション情報記憶部
１００ドライブ装置
１０１記録媒体
１０２補助記憶装置
１０３メモリ装置
１０４ＣＰＵ
１０５インタフェース装置
Ｂバス

Claims

ネットワークにおいて通信中である、複数の種別のアプリケーションに係る複数のセッションのそれぞれについて、当該セッションに係るアプリケーションの種別に応じて異なるＱｏＥ予測値の計算方法において必要となる、前記種別に応じたアプリケーション情報を複数のタイミングで取得する取得部と、
前記アプリケーションごとに当該アプリケーションの種別に応じた前記計算方法及び前記アプリケーション情報に基づいて計算することで得られる前記各セッションのＱｏＥ予測値と、前記ネットワークの帯域に対する条件とに基づいて、前記複数のセッションのそれぞれの割当帯域を前記複数のタイミングで探索する探索部と、
前記探索部により探索された割当帯域に基づいて、前記各セッションに対する帯域の割当を前記複数のタイミングで制御する制御部と、
を有することを特徴とする制御装置。
前記探索部は，前記ＱｏＥ予測値が最小であるセッションのＱｏＥ予測値が増加するように、前記割当帯域を探索する、
ことを特徴とする請求項１記載の制御装置。
前記探索部は，前記各セッションのＱｏＥ予測値が閾値以上となるセッション数が増加するように、前記割当帯域を探索する、
ことを特徴とする請求項１記載の制御装置。
前記探索部は，前記各セッションのＱｏＥ予測値の平均が増加するように、前記割当帯域を探索する、
ことを特徴とする請求項１記載の制御装置。
前記探索部は，動画のセッションに関する端末におけるバッファ長予測値が閾値以上となるように、前記割当帯域を探索する、
ことを特徴とする請求項１乃至４いずれか一項記載の制御装置。
前記探索部は、前記ＱｏＥ予測値の最小値が増加するように、前記割当帯域を探索する、
ことを特徴とする請求項１記載の制御装置。
ネットワークにおいて通信中である、複数の種別のアプリケーションに係る複数のセッションのそれぞれについて、当該セッションに係るアプリケーションの種別に応じて異なるＱｏＥ予測値の計算方法において必要となる、前記種別に応じたアプリケーション情報を複数のタイミングで取得する取得手順と、
前記アプリケーションごとに当該アプリケーションの種別に応じた前記計算方法及び前記アプリケーション情報に基づいて計算することで得られる前記各セッションのＱｏＥ予測値と、前記ネットワークの帯域に対する条件とに基づいて、前記複数のセッションのそれぞれの割当帯域を前記複数のタイミングで探索する探索手順と、
前記探索手順において探索された割当帯域に基づいて、前記各セッションに対する帯域の割当を前記複数のタイミングで制御する制御手順と、
をコンピュータが実行することを特徴とする制御方法。
ネットワークにおいて通信中である、複数の種別のアプリケーションに係る複数のセッションのそれぞれについて、当該セッションに係るアプリケーションの種別に応じて異なるＱｏＥ予測値の計算方法において必要となる、前記種別に応じたアプリケーション情報を複数のタイミングで取得する取得手順と、
前記アプリケーションごとに当該アプリケーションの種別に応じた前記計算方法及び前記アプリケーション情報に基づいて計算することで得られる前記各セッションのＱｏＥ予測値と、前記ネットワークの帯域に対する条件とに基づいて、前記複数のセッションのそれぞれの割当帯域を前記複数のタイミングで探索する探索手順と、
前記探索手順において探索された割当帯域に基づいて、前記各セッションに対する帯域の割当を前記複数のタイミングで制御する制御手順と、
をコンピュータに実行させることを特徴とするプログラム。