(57)【特許請求の範囲】
【請求項１】
トラヒックのセッションに対する帯域割り当てを制御する帯域割り当て制御装置であって、
ユーザ端末におけるトラヒックのバッファ量に基づいて、ユーザ端末におけるトラヒックが再生開始前であるか、再生開始後であるか、という再生状態を推定する再生状態エミュレーションユニットと、
ユーザ体感品質（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の劣化が起きる直前である状態
のいずれかに分類するステップと、
分類されたセッション状態に基づいて、帯域の割り当て量を計算するステップと、
を有する帯域割り当て制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、帯域割り当て制御装置及び帯域割り当て制御方法に関する。特に、本発明は、セッションの状態の違いによるユーザ体感品質（QoE：Quality of Experience）の劣化特性の違いを利用し、セッションごとに所与のQoE目標値に対する達成率を最大化する帯域割り当て制御装置及び帯域割り当て制御方法に関する。
【背景技術】
【０００２】
近年、ネットワークを利用するサービス事業者は、自社サービスのエンゲージメント（ユーザ定着率、ページ滞在時間等）を向上させるため、様々な施策を行っている。一般にエンゲージメントはユーザ体感品質（QoE）と何らかの関係性があると考えられるため、サービス事業者は、サービス全体としてQoEをある水準以上に保つ必要がある。しかし、サービス事業者が制御可能な範囲はサーバ及びユーザが利用するアプリケーションに限られており、通信事業者のネットワークを流れるトラヒックを制御することはできない。そのため、通信事業者には、サービス事業者から求められるQoE基準を可能な限り満たすトラヒック制御を行う必要が求められる。
【０００３】
サービス事業者が求めるネットワーク品質（QoS：Quality of Service）基準を達成する方法として、帯域確保型サービスが存在する。しかし、帯域確保型サービスでは、ピーク利用量に合わせた帯域確保が必要であり、サービスの内容によっては過剰品質になってしまう場合がある。また、帯域確保型サービスは一般に高額であり、多くのサービス事業者にとってはコストメリットが薄いという問題点がある。
【０００４】
そのため、QoE特性に基づいた帯域制御法が提案されている（非特許文献１）。しかしこの方式は、QoEを算出する方法として、ネットワーク品質（QoS）と一対一に対応した簡易モデルを利用しており、実際のQoEを正確に反映した制御がされているとはいいがたい。また、動画トラヒックを対象として、できる限り途中の再生停止回数を抑制する帯域割当制御方式も提案されている（非特許文献２）。この方式は全体のQoEを向上させることには成功しているものの、QoEに影響を与える要因として、再生停止回数という一要素しか考慮していない。一般にQoEに影響を与える要因は複数あるため、必ずしも所与のQoE目標値を満たすユーザ数の最大化を目的とした制御とはなっていない。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】S. Khan, S. Duhovnikov, E. Steinbach, and W. Kellerer, "MOS-based multiuser multiapplication cross-layer optimization for mobile multimedia communication," Advances in Multimedia, 2007
【非特許文献２】Wamser, F.; Staehle, D.; Prokopec, J.; Maeder, A.; Tran-Gia, P., "Utilizing buffered YouTube（登録商標） playtime for QoE-oriented scheduling in OFDMA networks," Teletraffic Congress (ITC 24), 2012 24th International , vol., no., pp.1,8, 4-7 Sept. 2012
【非特許文献３】ITU-T, "P.1201 : Amendment 2: New appendix iii - use of ITU-T P.1201 for non-adaptive, progressive download type media streaming," 2014
【発明の概要】
【発明が解決しようとする課題】
【０００６】
例えば、駅やイベント会場等で、多くのユーザが同一の基地局収容エリアから通信をする場合、現在の携帯電話網では、携帯端末と基地局間の無線アクセス区間のリソースがユーザからの通信要求に対して不足することがあり、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の劣化が起きている状態、
状態４：再生開始後かつQoEの劣化が起きている状態、及び
状態５：再生開始後かつQoEの劣化が起きる直前である状態
のいずれかに分類するステップと、
分類されたセッション状態に基づいて、帯域の割り当て量を計算するステップと、
を有することを特徴とする。
【発明の効果】
【００１２】
本発明によれば、QoE目標値の達成率を向上させることが可能になる。
【図面の簡単な説明】
【００１３】
【図１】本発明の一実施の形態における帯域割り当て制御装置の機能ブロック図
【図２】本発明の一実施の形態における帯域割り当て制御装置により分類されるセッション状態の関係を示す状態遷移図（その１）
【図３】本発明の一実施の形態における帯域割り当て制御装置により分類されるセッション状態の関係を示す状態遷移図（その２）
【図４】本発明の一実施の形態における帯域割り当て制御方法のフローチャート
【図５】図４における処理Ａの詳細フローチャート
【図６】図４における処理Ｂの詳細フローチャート
【図７】図４における処理Ｃの詳細フローチャート
【図８】図４における処理Ｄの詳細フローチャート
【図９】図４における処理Ｅの詳細フローチャート
【発明を実施するための形態】
【００１４】
以下、図面を参照して本発明の実施例について説明する。
【００１５】
本発明の実施例では、QoE特性に基づき所与のQoE目標値の達成率を向上させるために、トラヒックのセッションに対する帯域割り当てを制御する帯域割り当て制御装置について説明する。将来トラヒックの約８割は動画トラヒックと予測されているため、本発明の実施例では特にPDL（progressive download）型動画トラヒックを対象とした帯域割り当て制御装置について説明する。ただし、以下に説明するように、本発明の実施例は、Web等のダウンロード型トラヒックにも適用可能である。
【００１６】
本発明の実施例に係る帯域割り当て制御装置は、ある一定時間ごとにリンク内に存在する動画セッションを再生状態及びQoEに基づいて下記の５種類のセッション状態に分類し、セッション状態ごとにそれぞれ異なるポリシーで帯域割り当てを行う。
【００１７】
状態１：再生開始前かつQoEの劣化が起きていない状態
状態２：再生開始後かつQoEの劣化が起きていない状態
状態３：再生開始前かつQoEの劣化が起きている状態
状態４：再生開始後かつQoEの劣化が起きている状態
状態５：再生開始後かつQoEの劣化が起きる直前である状態
各セッション状態への分類が終わった後、帯域割り当て制御装置は、各セッションに対して利用可能な帯域を割り当てる。
【００１８】
まず、状態１又は状態３に属するセッションのうち、次の制御タイミングにおけるQoEを予測する。そして、次の制御タイミングでQoE目標値を下回るセッションに対して、そのセッションが状態２に移行するために必要な帯域（再生が開始するために必要な帯域量）を割り当てることで、QoE目標値を下回ることを抑制する。
【００１９】
次に、状態５に属するセッションに対して、符号化ビットレート分の帯域を割り当てる。符号化ビットレート分の帯域を割り当てることで、状態５に属するセッションを状態４に遷移させることを防ぐことが可能となる。
【００２０】
次に、状態１又は状態３に属するセッションに対して、バッファ量が再生開始閾値に達しない範囲で、できる限り多くの帯域を割り当てることで、ある閾値までバッファがたまったセッション数を増加させる。その結果、状態１又は状態３に属するセッションがQoE目標値を下回ることを抑制するために帯域を割り当てる場合に、帯域が不足することを防ぐ。具体的には、状態１又は状態３に属するセッションのうち、トラヒックのバッファ量が閾値以下のセッションに対して、トラヒックのバッファ量が閾値となるために必要な帯域量を割り当てる。この時、再生開始までの余裕をどの程度持たせるかを、閾値を用いて調整することが可能であるものとする。
【００２１】
次に、状態２又は状態５に属するセッションに対して、トラヒックのバッファ量が最小のものから優先的に帯域量を割り当て、その結果、バッファ量が均一となるように帯域を割り当てる。このように割り当てを行うことで、PDL動画トラヒック以外のトラヒックが到着した際に状態４に遷移する確率を低減することが可能となる。
【００２２】
最後に、状態３かつQoEがQoE目標値を下回るセッション又は状態４のセッションに対して、残余帯域を均一に割り当てる。
【００２３】
このようなポリシーで制御タイミングごとに各セッションに対する帯域割当を動的に変更することで、QoE目標値の達成率を向上させる。
【００２４】
＜帯域割り当て制御装置の構成＞
図１に、本発明の一実施の形態における帯域割り当て制御装置の機能ブロック図を示す。帯域割り当て制御装置は、プロセッサ等のＣＰＵ（Central Processing Unit）、ＲＡＭ（Random Access Memory）やＲＯＭ（Read Only Memory）等のメモリ装置、ハードディスク等の記憶装置等から構成されたコンピュータでもよい。例えば、帯域割り当て制御装置の機能及び処理は、記憶装置又はメモリ装置に格納されているデータやプログラムをＣＰＵが実行することによって実現される。
【００２５】
図１に示す帯域割り当て制御装置は、トラヒックメタ情報管理部１００と、セッション状態分類部２００と、帯域割り当て量計算部３００とから構成される。トラヒックメタ情報管理部１００と、セッション状態分類部２００と、帯域割り当て量計算部３００は相互に接続されており、トラヒックメタ情報管理部１００はサービス事業者と接続されており、帯域割り当て量計算部３００はネットワークと接続されている。
【００２６】
トラヒックメタ情報管理部１００は、トラヒックメタ情報受信ユニット１０１と、トラヒックメタ情報管理DB（データベース）１０２と、実現QoE通知ユニット１０３とから構成され、セッション状態分類部２００は、再生状態エミュレーションユニット２０１と、セッション状態分類ユニット２０２と、セッション状態管理DB２０３とから構成され、帯域割り当て量計算部３００は、帯域割り当て量計算ユニット３０１と、QoE推定ユニット３０２とから構成される。
【００２７】
＜トラヒックメタ情報の取得＞
トラヒックメタ情報受信ユニット１０１は、通信要求が発生した際に、サービス事業者から動画の符号化ビットレート、フレームレート、再生が開始するバッファ量の閾値（再生開始閾値）及び目標とするQoEの値（QoE目標値）を取得し、トラヒックメタ情報管理DB１０２に格納する。
【００２８】
＜セッション状態の分類＞
PDL型動画トラヒックを制御対象とする場合、セッション状態分類ユニット２０２は、QoE特性及び動画の再生状態に応じて、PDL型動画トラヒックの通信要求を出してから、視聴完了するまでのユーザ端末におけるセッション状態を下記５つの状態に分類する。
【００２９】
状態１：再生開始前かつQoEの劣化が起きていない状態
状態２：再生開始後かつQoEの劣化が起きていない状態
状態３：再生開始前かつQoEの劣化が起きている状態
状態４：再生開始後かつQoEの劣化が起きている状態
状態５：再生開始後かつQoEの劣化が起きる直前である状態
上記５つの状態は、図２のような関係性になっている。各状態の関係については、以下で説明する。この分類を行うために、各セッションにおけるPDL型動画トラヒックの再生状態（動画トラヒックが再生開始前であるか、再生開始後であるか）を、再生状態エミュレーションユニット２０１で推定する。再生状態エミュレーションユニット２０１は、ユーザ端末におけるトラヒックのバッファ量に基づいて、既存の動画バッファ量推定法を用いることで再生状態を推定する。あるいは、再生状態エミュレーションユニット２０１は、サービス事業者側に用意された、バッファ量取得APIを叩くことでバッファ量を取得し、再生状態を推定できるものとする。
【００３０】
また、各セッションのQoEをQoE推定ユニット３０２で推定する。QoE推定ユニット３０２は、既存のQoE推定法を用いることでQoEを推定する。例えば、QoE推定ユニット３０２は、非特許文献３で提示されているモデルを利用してQoEを算出し、QoEの劣化が起きているか、QoEの劣化が起きていないか、QoEの劣化が起きる直前であるかを推定する。こうして分類された状態はセッション状態管理DB２０３に保存する。
【００３１】
図２は、本発明の一実施の形態における帯域割り当て制御装置により分類されるセッション状態の関係を示す状態遷移図である。まず、新たな通信要求のセッションが到着した際には、セッション状態分類ユニット２０２は、符号化品質推定に必要なパラメータ、再生が開始するバッファ量の閾値（再生開始閾値）を取得し、状態１と分類する。そして、送信量を記録しながら、再生状態エミュレーションユニット２０１においてプレイヤーの再生状態をエミュレートし、動画開始までの待ち時間が一定時間（4.29秒）を超えた場合には状態３に分類する。また、バッファ量が再生開始閾値（4秒分のバッファ量）以上貯まり、動画の視聴がスタートした時には状態２に分類し、バッファ量が枯渇する寸前になった場合（バッファ量がTh.b（例えば、Th.b=0.1秒分のバッファ量）未満になった場合）には状態５に分類する。バッファ量が完全に枯渇し、映像再生が停止した時には状態４に分類する。映像再生が停止した後に、再びバッファ量が再生開始閾値（4秒分のバッファ量）以上貯まり、動画の視聴がスタートした時には状態２に分類する。
【００３２】
更に、上記５つの状態は図３のような関係に表すこともできる。図３は、本発明の一実施の形態における帯域割り当て制御装置により分類されるセッション状態の関係を示す状態遷移図である。ここでは、図２の状態３が状態３と状態３'とに更に分類されている。上記と同様に、新たな通信要求のセッションが到着した際には、セッション状態分類ユニット２０２は、状態１と分類する。そして、送信量を記録しながら、再生状態エミュレーションユニット２０１においてプレイヤーの再生状態をエミュレートし、動画開始までの待ち時間が一定時間（Ti秒）を超えた場合には状態３に分類する。更に、動画開始までの待ち時間がTi秒+Tha秒を超えた場合には状態３'に分類する。Tiは、再生開始前に待たせることのできる最大の秒数を表し、次式に示す方法で算出できる（非特許文献３参照）。
Ti={x|DegT0(x+Tha)=Q-q}
ただし、ThaはQoE目標値を切るどの程度直前まで待たせるかを表す閾値であり、Qは符号化品質（NW起因のQoE劣化が一切ない場合のQoE）であり、qはこのセッションのQoE目標値であり、DegT0(x)=ifelse(T0>4.29,max(min(0.29*log(T0-3.29),4),0),0)で定義される関数である。以下、図２と同様に、バッファ量が再生開始閾値（4秒分のバッファ量）以上貯まり、動画の視聴がスタートした時には状態２に分類し、バッファ量が枯渇する寸前になった場合（バッファ量がTh.b（例えば、Th.b=0.1秒分のバッファ量）未満になった場合）には状態５に分類する。バッファ量が完全に枯渇し、映像再生が停止した時には状態４に分類する。映像再生が停止した後に、再びバッファ量が再生開始閾値（4秒分のバッファ量）以上貯まり、動画の視聴がスタートした時には状態２に分類する。
【００３３】
＜割り当て帯域の決定＞
実際に各セッションに割り当てる帯域の量は、帯域割り当て量計算ユニット３０１で計算される。例えば、割り当て帯域の変更は100msおきに行われる。帯域割り当て量計算ユニット３０１は、分類されたセッション状態に基づいて、帯域の割り当て量を計算する。帯域の割り当て量は、セッション状態ごとにそれぞれ異なるポリシーを用いて、利用可能な帯域（残余帯域）から割り当てられる。
【００３４】
帯域割り当て量計算ユニット３０１では、図４〜図９に示すフローにしたがって帯域割り当て量が判断され、利用可能な帯域の割当量が決定される。図４は、本発明の一実施の形態における帯域割り当て制御方法のフローチャートであり、図５〜９は、図４の中の処理の詳細フローチャートを示している。
【００３５】
まず、状態１又は状態３に属するセッションが存在する場合（図４のＳ１０）、図５に示すフローが実施される（Ｓ１１）。図５に示すように、利用可能な帯域（残余帯域）がない場合（Ｓ１１１：Ｎｏ）、処理は終了する。残余帯域がある場合（Ｓ１１１：Ｙｅｓ）、QoE推定ユニット３０２は、状態１又は状態３、かつバッファ量が閾値Th.cとなっているセッションについて（Ｓ１１２：Ｙｅｓ）、次の制御タイミングにおけるQoEの値を計算する。閾値Th.cは、状態１又は状態３で待たせておく際に貯めるバッファ量を示し、例えば、Th.c=3.99とする。帯域割り当て量計算ユニット３０１は、計算されたQoEがQoE目標値を下回っている場合には、そのセッションが再生を開始するために必要な帯域量を割り当てる（Ｓ１１３）。また、QoE目標値を下回っていない場合であっても（Ｓ１１２：Ｎｏ）、状態２のフローが存在しない場合には（Ｓ１１４：Ｙｅｓ）、状態１又は状態３のうちバッファがTh.cまでたまっているフローをランダムに一つ選択し、再生を開始するために必要な帯域量の割り当てを行う（Ｓ１１５）。これら帯域割り当てを行った後は残余帯域の更新を行う（Ｓ１１６）。この処理を行うことにより、QoE目標値を下回るフローを減らしつつ、状態２になるセッション数を減らすことができる。
【００３６】
次に、状態５に属するセッションが存在する場合（図４のＳ１２）、図６に示すフローが実施される（Ｓ１３）。図６に示すように、残余帯域がない場合（Ｓ１３１：Ｎｏ）、処理は終了する。残余帯域がある場合（Ｓ１３１：Ｙｅｓ）、帯域割り当て量計算ユニット３０１は、状態５に属するセッションに対して符号化ビットレート分の帯域を割り当てる。状態５のセッションの数*符号化ビットレートが残余帯域以下である場合（Ｓ１３２：Ｎｏ）、帯域割当量計算ユニット３０１は、状態５に属するセッションの全てに符号化ビットレート分の帯域を割り当てることができる（Ｓ１３３）。一方、状態５のセッションの数*符号化ビットレートが残余帯域より大きい場合（Ｓ１３２：Ｙｅｓ）、帯域割当量計算ユニット３０１は、状態５に属するセッションの全てに符号化ビットレート分の帯域を割り当てることができない。この時、floor(残余帯域/符号化ビットレート)個のフローをランダムに選択し、符号化ビットレート分の帯域を割り当てる（Ｓ１３４、Ｓ１３５）。帯域割り当てが終わった後に、残余帯域を更新する（Ｓ１３６）。このような割り当てを行うことで、QoEの劣化を抑えることができ、目標QoEを達成する確率が大きくなる。
【００３７】
次に、状態１又は状態３に属するセッションが存在する場合（図４のＳ１４）、図７に示すフローが実施される（Ｓ１５）。図７に示すように、残余帯域がない場合（Ｓ１５１：Ｎｏ）、処理は終了する。残余帯域がある場合（Ｓ１５１：Ｙｅｓ）、帯域割り当て量計算ユニット３０１は、状態１又は状態３かつバッファ量がTh.c以下のフローに対し（Ｓ１５２：Ｙｅｓ）、閾値Th.cまでバッファ量が貯まっているセッション数が最大となるように帯域を割り当てる（Ｓ１５３）。具体的には、該当フローのバッファ量が大きい順に、次の制御タイミングの時までにバッファ量がTh.cとなるように帯域を割り当てる。帯域割り当てが終わった後に、残余帯域を更新する（Ｓ１５４）。このような割り当てを行うことで、図５に示すフローにしたがって処理を行う際に、QoE目標値を下回ることなく、状態２に遷移させることが可能となる。また、この閾値Th.cを小さく設定することで、動画が再生状態に遷移した後に停止する確率を低減することができ、なるべく大きく設定することで、状態３において目標QoEを下回る確率を小さくすることができる。
【００３８】
次に、状態２又は状態５に属するセッションが存在する場合（図４のＳ１６）、図８に示すフローが実施される（Ｓ１７）。図８に示すように、残余帯域がない場合（Ｓ１７１：Ｎｏ）、処理は終了する。残余帯域がある場合（Ｓ１７１：Ｙｅｓ）、帯域割り当て量計算ユニット３０１は、状態２又は状態５のセッションに対して、トラヒックのバッファ量が最小のものから優先的に帯域量を割り当て、最低バッファ量が均一となるように割り当てを行う。帯域割り当てが終わった後に、残余帯域を更新する（Ｓ１７３）。このような割り当てを行うことで、現在制御しているリンク以外の部分に瞬間的にボトルネックが発生した場合でも、再生が停止する確率を低減することが可能となる。
【００３９】
最後に、状態３又は状態４に属するセッションが存在する場合（図４のＳ１８）、図９に示すフローが実施される（Ｓ１９）。図９に示すように、残余帯域がない場合（Ｓ１９１：Ｎｏ）、処理は終了する。残余帯域がある場合（Ｓ１９１：Ｙｅｓ）、帯域割り当て量計算ユニット３０１は、状態３かつQoEが目標値を下回ってしまったフロー（図３の状態３'）又は状態４のセッションに対して、帯域を均一に割り当てる（Ｓ１９２）。帯域割り当てが終わった後に、残余帯域を更新する（Ｓ１９３）。この処理を行うことで、全てのセッションを送信することが可能となる。
【００４０】
＜実現QoEの通知＞
上記割り当てを一定時間おきに行った後、送信が終了した際には、実現QoE通知ユニット１０３からサービス事業者に対して、実際にネットワークで実現したQoEの値を通知する。この機能を設けることでサ―ビス事業者は、自社のサービスがEnd-to-Endでどのような体感品質となっていたかを知ることが可能となる。
【００４１】
＜PDL型動画トラヒックとWeb等のダウンロード型トラヒックを制御対象とする場合＞
次に、PDL型動画トラヒックに加えて、ダウンロード型トラヒック（Webトラヒック）も制御対象とする実施例について説明する。まず、帯域割り当て量計算ユニット３０１は、動画トラヒック群、Webトラヒック群に割り当てる帯域の量を決定する。決定の際は、動画のセッション数とWebのセッション数の比で割り当ててもよく、もしくは動画トラヒックの平均符号化ビットレート*動画セッション数とWebトラヒックの平均bit数*Webセッション数の比で割り当ててもよい。
【００４２】
PDL型動画トラヒック全体で利用可能な帯域が決定した後は、図１〜図９を参照して説明した手順にしたがって割り当て帯域量の決定を行う。
【００４３】
Webトラヒックに対しては、次のように割り当て帯域量の決定を行う。WebトラヒックのQoE特性は、PDL型動画トラヒックの状態１及び状態３のみが存在する状態だと解釈することができる。そのため、図１〜図９の手順のうち、状態１及び状態３が関わる手順を順に適用することで、Web等のダウンロード型トラヒックに対しても本手法を適用することが可能となる。
【００４４】
＜本発明の実施例の効果＞
以上のように、本発明の実施例によれば、QoE特性に基づいてトラヒックのセッション状態を分類し、分類されたセッション状態ごとに帯域割り当てを制御することにより、QoE目標値の達成率を向上させることを目的とする。
【００４５】
具体的には、以下に示す二点の効果が見込まれる。
【００４６】
一点目の効果は、ネットワークを利用した適切なサービス体感品質の提供である。従来は、全てのトラヒックに対して公平に帯域を割り当てることで、公平なネットワーク品質を達成していたが、QoEの観点では、必ずしもQoE目標値が達成されているとは限らず、サービス事業者にとってはサービス体感品質の確保が難しかった。しかし、本発明の実施例に記載の手法を利用することで、QoE目標値の達成率を最大化することが可能となる。したがって、サービス事業者はより多くのユーザに対して、適切な体感品質となるサービスを提供することが可能となる。
【００４７】
二点目の効果は、ネットワーク事業者とサービス事業者の良好な関係性構築である。従来のベストエフォートな帯域割当方式では、全てのセッションがQoE目標値を下回るということも起こりうる。この時、サービスを利用するユーザは全員が不満を抱き、サービス事業者はユーザの不満によりエンゲージメントが低下し、ネットワーク事業者への不満が募る状況となっていた。しかし、本発明の実施例により、サービス事業者が目指すQoE目標値の達成率を最大化することが可能となる。そのため、同じネットワークリソースを利用してより多くの満足するユーザを生み出し、サービス事業者のエンゲージメント向上に貢献することが可能となる。
【００４８】
説明の便宜上、本発明の実施例に係る帯域割り当て制御装置は機能的なブロック図を用いて説明しているが、本発明の実施例に係る帯域割り当て制御装置は、ハードウェア、ソフトウェア又はそれらの組み合わせで実現されてもよい。例えば、本発明の実施例は、コンピュータに対して本発明の実施例に係る帯域割り当て制御装置の各機能を実現させるプログラム、コンピュータに対して本発明の実施例に係る方法の各手順を実行させるプログラム等により、実現されてもよい。また、各機能部が必要に応じて組み合わせて使用されてもよい。また、本発明の実施例に係る方法は、実施例に示す順序と異なる順序で実施されてもよい。
【００４９】
以上、QoE目標値の達成率を向上させるための手法について説明したが、本発明は、上記の実施例に限定されることなく、特許請求の範囲内において、種々の変更・応用が可能である。
【符号の説明】
【００５０】
１００  トラヒックメタ情報管理部
１０１  トラヒックメタ情報受信ユニット
１０２  トラヒックメタ情報管理DB
１０３  実現QoE通知ユニット
２００  セッション状態分類部
２０１  再生状態エミュレーションユニット
２０２  セッション状態分類ユニット
２０３  セッション状態管理DB
３００  帯域割り当て量計算部
３０１  帯域割り当て量計算ユニット
３０２  QoE推定ユニット
【図１】
0006276206.tif 000002
【図２】
0006276206.tif 000003
【図３】
0006276206.tif 000004
【図４】
0006276206.tif 000005
【図５】
0006276206.tif 000006
【図６】
0006276206.tif 000007
【図７】
0006276206.tif 000008
【図８】
0006276206.tif 000009
【図９】
0006276206.tif 000010