本発明の第1の実施形態について説明する。
本実施形態は、ユーザからの要求に基づいて、動画ストリーミングが再生されるときに、該ユーザに最適なQoEを実現し、かつ、ネットワークにおけるユーザ全体に最適なQoEを実現する。
動画ストリーミングにおけるQoEの主要な要素としては、画像の品質、すなわち、解像度、画面の乱れの少なさ、及びスタートアップ時間の短さが考えられる。ここで、スタートアップ時間とは、動画再生の要求から、動画の再生が開始されるまでの時間である。
ストリーミングにおいて、通常、ジッターを減少させるために受信側のアプリケーションが数秒間データをバッファリングしてから動画を再生する。そのため、QoEを改善するには、コンテンツの画質を劣化させずにデータを転送し、再生開始までの時間(以下、スタートアップ時間と呼ぶ)を縮めることが重要である。特に、スタートアップ時間の短さは、ユーザが複数のコンテンツの中から興味のあるものを選択するとき、いわゆるザッピングを行うときに重要になる。
本実施形態において、解像度、及びスタートアップ時間の短さを確保することを、QoEを改善するための主要な目標とする。
図1は、本発明の第1の実施の形態における、ネットワークシステム構成を示すブロック図である。
コア・ネットワーク151には、エッジルータ131、及びエッジルータ141が接続されている。なお、各エッジルータ131、141は、スイッチであってもよい。
コア・ネットワーク151に1台又は複数台のコア・ノードが含まれる場合、エッジルータ131、141は、前記コア・ノードに接続されるか、又はエッジルータ同士で接続される。なお、コア・ネットワーク151に他の装置が含まれず、エッジルータ131とエッジルータ141とが互いに接続されていてもよい。
図1に示す例において、エッジルータ131のIPアドレスは、「10.10.11.1」であり、インタフェース番号が「1」のネットワーク・インタフェース132に接続されたリンクを経由して、直接又は他のネットワーク装置を介して、エンドユーザのコンピュータ101及びコンピュータ102と接続されている。
コンピュータ101にはIPアドレスとして「10.10.21.10」が割り当てられ、コンピュータ102にはIPアドレスとして「10.10.21.15」が割り当てられている。また、コンピュータ101及びコンピュータ102は、CPU(図示省略)、主記憶装置(図示省略)、二次記憶装置(図示省略)を備えている。
エッジルータ141のIPアドレスは、「10.10.12.1」であり、インタフェース番号が「1」のネットワーク・インタフェース142に接続されたリンクを経由して、直接又は他のネットワーク装置を介して、通信計画サーバ111とストリーミング・サーバ121とが接続されている。
通信計画サーバ111にはIPアドレスとして「10.10.22.11」が割り当てられ、また、通信計画サーバ111は通信計画データベース112を備える。ストリーミング・サーバ121にはIPアドレスとして「10.10.22.12」が割り当てられ、また、ストリーミング・サーバ121はコンテンツ122を備える。
管理サーバ152にはIPアドレスとして「10.10.23.31」が割り当てられ、また、管理サーバ152はエッジルータ131、141又はコア・ネットワーク151に含まれる他のネットワーク装置と接続されている。
図2Aは、本発明の第1の実施形態における通信計画サーバ111のハードウェア構成を説明するブロック図である。
通信計画サーバ111は、CPU200、主記憶装置201、二次記憶装置202、及びネットワーク・インタフェース203を備える。主記憶装置201は、例えばメモリである。二次記憶装置202は、例えばHDDである。二次記憶装置202上又は外部の装置(図示省略)に通信計画データベースが備えられる。また、通信計画サーバ111は、ネットワーク・インタフェース203を介してエッジルータ141と接続されている。
図2Bは、本発明の第1の実施形態におけるストリーミング・サーバ121のハードウェア構成を説明するブロック図である。
ストリーミング・サーバ121は、CPU210、主記憶装置211、二次記憶装置212、及びネットワーク・インタフェース213を備える。主記憶装置211は、例えばメモリである。二次記憶装置212は、例えばHDDである。二次記憶装置212上又は外部の装置(図示省略)にコンテンツ122が備えられている。また、ストリーミング・サーバ121は、ネットワーク・インタフェース213を介してエッジルータ141と接続されている。
図2Cは、本発明の第1の実施形態における管理サーバ152のハードウェア構成を説明するブロック図である。
管理サーバ152は、CPU220、主記憶装置221、二次記憶装置222、及びネットワーク・インタフェース223を備える。主記憶装置221は、例えばメモリである。二次記憶装置222は、例えばHDDである。二次記憶装置222上又は外部の装置(図示省略)に帯域管理テーブル153が備えられる。また、管理サーバ152は、ネットワーク・インタフェース223を介して、エッジルータ131、141又はコア・ネットワーク151に含まれる他のネットワーク装置と接続されている。
次に、セッション開始時及びセッション継続中にユーザがアプリケーションに要求を入力するためのグラフィカル・ユーザ・インタフェース(GUI)について説明する。
図3Aは、本発明の第1の実施形態における、コンテンツ選択のためのグラフィカル・ユーザ・インタフェース(GUI)を説明する図である。図3Bは、本発明の第1の実施形態における、初期品質を選択するためのグラフィカル・ユーザ・インタフェース(GUI)を説明する図である。図3Cは、本発明の第1の実施形態における、低解像度を選択した場合のグラフィカル・ユーザ・インタフェース(GUI)を説明する図である。図3Dは、本発明の第1の実施形態における、高解像度を選択した場合のグラフィカル・ユーザ・インタフェース(GUI)を説明する図である。図3A〜図3Dに示すGUIは、Webによって実現されている。
図3Aに示すコンテンツ選択画面301は、ユーザがコンテンツ選択画面301に表示されているコンテンツの中から特定のコンテンツを選択するためのメニュー画面である。コンテンツ選択画面301は、Webサイトにおける、HTMLページとして実現される。ユーザが、コンテンツ選択画面301に表示されているコンテンツを選択すると、図3Bに示す初期品質選択画面311に遷移する。すなわち、コンテンツ選択画面301に表示されているコンテンツの項目は、ハイパー・リンクによって表現されており、いずれかのコンテンツが選択(クリック)されることによって、それぞれ異なるパラメタが指定されて、CGI(Common Gateway Interface)プログラムが起動される。
初期品質選択画面311は、低解像度ボタン313、及び高解像度ボタン314が表示されている。すなわち、異なるQoE条件の選択肢が表示されている。なお、画質改善ボタン315、及び停止ボタン316は、初期品質設定においては、ユーザが選択できないようになっている。例えば、ボタン操作の無効又は表示しない等が考えられる。ユーザは、低解像度ボタン313、又は高解像度ボタン314のいずれかを選択(クリック)することができる。ユーザがどちらのボタンを選択するかは、当該選択によって、課金に差がでること、また、コンピュータ101の画面の解像度、若しくは処理性能によって、どちらがそのユーザにとって最適であるかに依存する。
ユーザが低解像度ボタン313を選択した場合、低解像度再生画面321が表示され、また、ユーザが高解像度ボタン314を選択した場合、高解像度再生画面331が表示される。すなわち、どちらのボタンを操作するかによって、異なるパラメタが指定されて、CGIプログラムが起動される。
図3Cに示す低解像度再生画面321における再生画面322は低解像度による動画再生画面であり、再生画面322はWebのプラグインとして実現される。再生画面322は、ストリーミング・サーバ121から送信される動画データを受信して再生される動画を表示する。低解像度再生画面321において、低解像度ボタン313はすでに選択されているため無効化されている。つまり、ユーザは、低解像度ボタン313を操作(クリック)できない。
ユーザは、低画質度で動画が再生されている途中に、高解像度ボタン314を操作(クリック)することによって、高解像度再生画面331に移行することができる。また、ユーザは、低解像度再生画面321に表示されている画質改善ボタン315を操作(クリック)することによって、再生されている画質を改善することができる。また、ユーザは、停止ボタン316を操作(クリック)することによって、動画の再生を停止することができる。
図3Dに示す高解像度再生画面331おける再生画面332は高解像度による動画再生画面であり、再生画面332はWebのプラグインとして実現される。再生画面332は、ストリーミング・サーバ121から送信される動画データを受信して再生される動画を表示する。高解像度再生画面331において、高解像度ボタン314はすでに選択されているため無効化されている。つまり、ユーザは、低解像度ボタン313を操作(クリック)できない。
ユーザは、高画質度で動画が再生されている途中に、低解像度ボタン313を操作(クリック)することによって、低解像度再生画面321に移行することができる。また、ユーザは、高解像度再生画面331に表示されている画質改善ボタン315を操作(クリック)することによって、再生されている画質を改善することができる。また、ユーザは、停止ボタン316を操作(クリック)することによって、動画の再生を停止することができる。
QoE条件としては、解像度のほかにスタートアップ時間を指定することも可能である。例えば、課金が大きく、かつ、スタートアップが高速であるQoE条件を選択するためのボタンと、課金が小さく、かつ、スタートアップが低速であるQoE条件を選択するためのボタンとを、それぞれの初期品質選択画面311、低解像度再生画面321、及び高解像度再生画面331に表示することができる。
図3A〜図3Dにおいて示したグラフィカル・ユーザ・インタフェースにおける操作によって発生する処理については、図4を用いて後述する。
なお、図3A〜図3DにおいてCGIを実現するための方法として、WebサーバのCGIを使用する場合を示したが、ウィンドウ・システムなど、他の方法を使用することもできる。
図4は、本発明の第1の実施形態において、ユーザがセッション開始時又はセッション継続中に、低解像度ボタン313又は高解像度ボタン314を操作したときのネットワークシステムにおける処理手順を示すシーケンス図である。
当該処理は、コンピュータ101上で動作するWebブラウザが、ユーザによる品質要求401を受信することによって開始される。なお、ユーザによる品質要求401は、低解像度ボタン313又は高解像度ボタン314のいずれかを操作(クリック)することによって発生する。
ユーザによる品質要求401を受信したコンピュータ101は、通信計画サーバ111に品質要求402を送信する。品質要求402には、ビデオ識別子とQoE情報とが含まれる。図4に示す例では、ビデオ識別子には、「life in venice」(初期品質選択画面311の「ベニスに生きる」に対応する)が含まれ、また、QoE情報には、解像度として「800×450」と、スタートアップ時間として「0.5秒」とが含まれる。なお、品質要求402は、他のQoE情報を含んでもよい。
品質要求402を受信した通信計画サーバ111は、図9Aに示す手順にしたがって処理を実行する。具体的には、管理サーバ152に通信計画データベース112にアクセスして「ベニスに生きる」の3つの通信計画案(図8参照)を含む品質要求403を送信する。
図4に示す例では、通信計画案として、初期帯域、スタートアップ時間、定常帯域及び最大帯域が指定されている。具体的には、次のように指定されている。
通信計画案1:(40M、0.5秒、5M、5M)
通信計画案2:(20M、0.5秒、7M、7M)
通信計画案3:(0、0秒、5M、10M)
管理サーバ152に送信された3つの通信計画案の詳細については、図6A〜図6Cを用いて後述する。
品質要求403は、通信計画案の他に、品質要求402の送信者のIPアドレスと品質要求403の受信者のIPアドレスとを含む。具体的には、送信者のIPアドレスは、コンピュータ101のIPアドレス「10.10.21.10」であり、受信者のIPアドレスは、品質要求402において指定された「life in venice」の解像度が「800×450」であるファイルを格納するストリーミング・サーバ121のIPアドレス「10.10.22.12」である。
品質要求403を受信した管理サーバ152は、図10に示す手順にしたがって処理を実行する。これによって、帯域制限設定404、キューイング設定405及び品質応答406の3つのメッセージが各々送信される。具体的には、帯域制限設定404はエッジルータ141に送信され、キューイング設定405はエッジルータ131に送信され、品質応答406は管理サーバ152に送信される。
品質応答406は、エッジルータ141がキュー設定を完了した応答を管理サーバ152が受信した後に送信されてもよいし、エッジルータ141のキュー設定の処理が完了する時間に動画が再生されるようなタイミングで送信されてもよい。
品質応答406には、管理サーバ152が選択した通信計画案が含まれる。図4に示す例では、品質応答406に通信計画案1が含まれる。なお、送信された通信計画案のいずれもが実現可能でない場合、管理サーバ152は、通信計画サーバ111に品質応答406の代わりに拒否応答を送信する。
帯域制限設定404には、動画ストリーミングにおけるトラフィック(動画再生409)がエッジルータ141を通過するときに許容される最大帯域を超えないように制限するための設定が含まれる。
例えば、通信計画案1では最大帯域が「20Mbps」と指定され、通信計画案2では最大帯域が「40Mbps」と指定され、通信計画案3では最大帯域が「10Mbps」と指定されている。ただし、ストリーミング・サーバ121からの送信帯域が、指定された最大帯域以下になることが確実であれば、帯域制限設定404は不要である。
キューイング設定405には、動画再生409において、エッジルータ131のネットワーク・インタフェース132で確保されるべき最低保証帯域を持つキューが使用されるための設定が含まれる。例えば、通信計画案1では最低保証帯域が「5Mbps」であるキューが選択され、通信計画案2では最低保証帯域が「7Mbps」であるキューが選択され、通信計画案3では最低保証帯域が「5Mbps」であるキューが選択される。
品質応答406を受信した通信計画サーバ111は、図9Bに示す手順にしたがってコンピュータ101に品質応答407を送信する。品質応答407には、選択された通信計画案と要求されたコンテンツを格納するストリーミング・サーバ121のIPアドレスが含まれる。また、品質応答407にはストリーミング・サーバ121以外の他のサーバ(図示省略)のアドレスが含まれてもよい。なお、送信された通信計画案のいずれもが実現可能でない場合、通信計画サーバ111は、コンピュータ101に品質応答407の代わりに拒否応答を送信する。
品質応答407を受信したコンピュータ101は、受信した品質応答407に含まれる通信計画案にしたがって、再生要求408をストリーミング・サーバ121に送信する。図4に示す例では、再生要求408には通信計画案1が含まれる。
再生要求408を受信したストリーミング・サーバ121は、受信した再生要求408に含まれる通信計画案に基づいて、図11に示す手順にしたがって動画再生409を実行する。
図4に示したシーケンスにおいて、通信計画サーバ111は、すべての通信計画案を一度に管理サーバ152に送信する。前述の方法は、単純であり通信シーケンスが短いという利点がある。しかし、送信される通信計画案が多数ある場合、通信計画サーバ111が送信するデータ量が多くなる。そこで、通信計画サーバ111が管理サーバ152に通信計画案を送信する方法の5つの代案を以下に示す。なお、以下の説明において、図4における通信計画サーバ111が管理サーバ152に通信計画案を送信する方法を、原案と記載する。
第1の代案では、通信計画サーバ111は、通信計画サーバ111が最適なものを選択し、当該選択された通信計画案のみを含む品質要求403を管理サーバ152に送信する。
管理サーバ152は、送信された通信計画案が適切か否かを判定し、適切な通信計画案であると判定された場合、当該通信計画案を含む品質応答406又は、OKメッセージを通信計画サーバ111に送信し、不適切な通信計画案であると判定された場合、品質応答406の代わりに拒否応答を通信計画サーバ111に送信する。
通信計画サーバ111は、管理サーバ152が通信計画案を受理する(通信計画サーバ111が品質応答406又は、OKメッセージを受信する)まで代わりの通信計画案を送信し続ける。通信計画サーバ111は、送信する通信計画案が無い場合、品質応答407の代わりに拒否応答をコンピュータ101に送信する。
つまり、第1の代案は、通信計画サーバ111と管理サーバ152との間の交渉によって通信計画案が選択される。第1の代案は、平均の通信量が原案より減少するという利点がある。
第2の代案では、通信計画サーバ111は、パラメタが付与された1つの通信計画案を管理サーバ152に送信し、管理サーバ152は、付与されたパラメタの最適値を算出して通信計画サーバ111に送信する。
パラメタが付与された通信計画案としては、例えば、前記通信計画案1及び2をまとめて、(10×(2+α)、0.5秒、5+αM、5+αM)(α=0、2)とすることが考えられる。ここで、αがパラメタである。より多くの通信計画案をまとめることができれば、送信データ量を減らすことができる。なお、当該パラメタ及び、パラメタが付与された通信計画案は、通信計画サーバ111によって決定されている。
つまり、第2の代案は、通信シーケンスは原案と同様に短く、かつ送信するデータ量も少ないという利点がある。
第3の代案では、図5に示すようなシーケンスにしたがって処理が実行される。
図5は、本発明の第1の実施形態において、ユーザがセッション開始時又はセッション継続中に、低解像度ボタン313又は高解像度ボタン314を操作したときのネットワークシステムにおける処理手順の変形例示すシーケンス図である。以下、図4との差異を中心に説明する。
図5に示すシーケンスでは、品質要求402、品質要求403、品質応答406、及び品質応答407の代わりに品質要求501、品質要求502、品質応答503、及び品質応答504が用いられる。他の処理手順は図4と同一である。
図5に示すシーケンスにおいて、コンピュータ101と通信計画サーバ111との間の通信にSIPが使用される。NGNのIMSでは資源確保のためにSIPが使用されるが、図5に示すシーケンスはそれを拡張したものである。すなわち、ストリーミングのセッション開始時にRTSPによるセッション制御(再生要求409)の前にSIPによるセッション制御が実行される。品質要求501は、SIPのINVITEメッセージであり、通信相手はセッション制御サーバである通信計画サーバ111である。
品質要求501は、拡張されたSDPメッセージが含まれる。されに、拡張されたSDPメッセージにはビデオ識別子、解像度、及びスタートアップ時間が含まれる。品質要求501は、SIPサーバである管理サーバ152を経由して通信計画サーバ111に到達する。具体的には、管理サーバ152は、受信した品質要求501を品質要求502として、通信計画サーバ111に転送する。
通信計画サーバ111から送信される品質応答503は、SIPのOK応答であり、さらに、複数の通信計画案が含まれる。管理サーバ152は、品質応答503に含まれる複数の計画案を参照し、最適な通信計画案を選択し、選択された通信計画案を含む品質応答504をSIPクライアントであるコンピュータ101に転送する。品質応答504は、通信計画案を1つのみ含む点が品質応答503と異なる。
第4の代案では、図5に示すシーケンスにおいて、第1の代案と同様に、品質応答503には通信計画サーバ111が最適のものとして選択した通信計画案が含まれる。管理サーバ152は、当該通信計画案を拒否する場合、品質応答504としてOKメッセージの代わりにSIPの失敗応答をコンピュータ101に送信する。つまり、offer/answerモデルにしたがってコンピュータ101と通信計画サーバ111との間で通信計画案をやりとりすることによって、間接的に管理サーバ152と通信計画サーバ111との間で交渉することができる。
第5の代案においては、図5に示すシーケンスにおいて、第2の代案と同様に、品質応答503にパラメタつきの通信計画案が含まれる。管理サーバ152は、最適なパラメタ値を決定し、決定されたパラメタを品質応答504に含めるよって、コンピュータ101が決定されたパラメタ値によって指定された通信計画案を受け取ることができる。
以上が、通信計画サーバ111が管理サーバ152に通信計画案を送信する方法の代案の説明である。
なお,図4に示すシーケンスにおいて、品質要求402及び品質要求403が送信された後、当該品質要求402及び品質要求403を取り消す要求メッセージを送信しない限り、その効果が継続する。具体的には、帯域制限設定404及びキューイング設定405によるエッジルータ131、141の設定が解除されない。したがって、エッジルータ131、141の設定を解除のための要求メッセージが送信されないと、エッジルータ131、141の資源が解放されないという問題がある。
前述した問題を解決するに、品質要求402及び品質要求403にタイムアウト時間を含める方法が考えられる。例えば、品質要求402がタイムアウト時間として「60分」を含む場合、品質要求403にもタイムアウト時間が含まれ、管理サーバ152が時間を計測し、60分に達したときに帯域制限設定404およびキューイング設定405によるエッジルータ131、141の設定を無効化するように設定する。
また、タイムアウト時間が経過する前に、品質要求402と同一の内容の要求メッセージがコンピュータ101から通信計画サーバ111に送信された場合、タイマーはリセットされ、タイムアウトの時間が延長される。したがって、ユーザがボタンを操作(クリック)することによって、ユーザによる品質要求401が発行された後、指定されているタイムアウト時間が経過する前にユーザが同一のボタンを、再度操作(クリック)した場合、品質要求402と同一の内容の要求が発行されて、タイムアウトの時間が延長される。これによって、図12に示す処理を必要としない。
図6Aは、本発明の第1の実施形態における通信計画案1を説明する図である。図6Bは、本発明の第1の実施形態における通信計画案2を説明する図である。図6Cは、本発明の第1の実施形態における通信計画案3を説明する図である。
通信計画案1は、最初の0.5秒間だけ20Mbpsでデータを送信し、それ以降は7Mbpsの一定レート(CBR(Constant Bit Rate))でデータを送信する計画である。ただし、実際には、7Mbpsよりレートが低くなる場合がある。
通信計画案2は、最初の0.5秒間だけ40Mbpsでデータを送信し、それ以降は5Mbpsの一定レートでデータを送信する計画である。
通信計画案1と比較して通信計画案2における一定レートが低いのは、本実施形態において、通信計画案1では受信側アプリケーションのジッター・バッファを10Mbit(1.25MB)と仮定しているのに対して、通信計画案2では受信側アプリケーションのジッター・バッファを20Mbit(2.5MB)と仮定しているため、実際のレートをならすことができるからである。すなわち、通信計画案2では、再生される予定の動画の動きが速くなるなどして再生レートが増加するときに、予め多くのデータを送信しておくことができるため、通信計画案1より一定レートを低くすることができる。
通信計画案3は、通信計画案1、2とは異なり、最初から5Mbpsの一定レートでデータを送信し、また、10Mbpsまでのレートでデータが送信されることを許容している。すなわち、通信計画案3は、VBR(Variable Bit Rate)で送信する計画である。
通信計画案1、2において、最初の0.5秒間以外の部分では、それぞれ7Mbps又は5Mbpsの最低帯域が保証されることによって、遅延及びパケット損失を防ぐことができる。
通信計画案3において、10Mbpsの最低帯域が保証されることによって、遅延及びパケット損失を防ぐことができるが、それではネットワーク・トラフィックが実際には少ないにもかかわらず新規の要求を受け付けることができない、すなわち、ネットワークのアドミッション制御機能によって再生が拒否される事態が発生する。そのため、最低帯域は10Mbpsより低くする、すなわち、いわゆるオーバーブッキングを認めるスケジューリングを前提とする。
図7は、本発明の第1の実施形態における、スタートアップ時間及びジッター・バッファの量と、定常帯域との関係を説明する図である。
図7におけるグラフ701は、受信アプリケーションの時刻と再生済の動画のデータ量との関係を表している。グラフ701は、VBRコーディングを前提としているため、受信アプリケーションの時刻と再生済の動画のデータ量との関係を表すグラフは直線にはならない。
図7におけるグラフ702は、通信計画案2における受信アプリケーションの時刻と送信される動画のデータ量との関係を示し、グラフ703は、通信計画案1における受信アプリケーションの時刻と送受信される動画のデータ量との関係を示している。通信計画案1、2において、送受信されるデータは、CBRにしたがって送受信されるので、グラフ702、703は直線で表される。
グラフ702、703の直線がグラフ701の太線より右側にでるとデータが不足して再生が停止するので、必ずグラフ702、703の直線がグラフ701の太線より左側にあるか、又は接していなければならない。そのため、バッファ・サイズを減少させるとその傾斜を大きくする必要がある。すなわち、定常帯域を増加させる必要が生じる。
図8は、本発明の第1の実施形態の通信計画データベース112が格納する内容の一例を示す図である。
通信計画データベース112は、ストリーミング・サーバ121が格納するすべてのコンテンツに対する通信計画案の原データ800を格納する。
原データ800は、ビデオ識別子801、サーバ・アドレス802、解像度803、及び通信計画案804を含む。
ビデオ識別子801は、動画を識別するための識別子である。サーバ・アドレス802は、ビデオ識別子801に対応するコンテンツを格納するストリーミング・サーバ121のIPアドレスを格納する。なお、同一のコンテンツを格納するストリーミング・サーバ121が複数ある場合、サーバ・アドレス802には、複数のストリーミング・サーバ121のIPアドレスが格納される。
解像度803は、再生される動画の解像度を示す。つまり、QoEの条件が格納されている。通信計画案804は、最小バッファ量、定常帯域、及び最大帯域の3つ組からなる通信計画案が格納されている。なお、通信計画案804に格納されている通信計画案は、条件のよいものから順に並べられた状態で格納されている。例えば、図8に示す例では、左から順に、条件のよい通信計画が格納されている。
原データ800には、1つのビデオ識別子801に対して、低解像度と高解像度の2つのレコードを含む。図8に示す例では、原データ800は、レコード811〜レコード818が含まれる。
レコード814は、「ベニスに生きる」に対応するレコードであり、当該レコードの通信計画案804は、図6A〜図6Cに示した3つの通信計画案1〜3にそれぞれ対応している。ここで、最小バッファ量は、受信側アプリケーションが持つべきジッター・バッファの量の最小値である。最小バッファ量をスタートアップ時間で割って算出されたものが初期帯域となる。例えば、最小バッファ量が「20Mbit」であり、スタートアップ時間を「0.5秒」とすると、ジッター・バッファを0.5秒間で満たすためには、初期帯域を「40Mbps」として送信する必要がある。したがって、スタートアップ時間が「0.5秒」のとき、レコード814の通信計画案804に含まれる(20M、5M、5M)から(40M、0.5秒、5M、5M)という通信計画案2が生成される。
図9A及び図9Bは、本発明の第1の実施形態の通信計画サーバ111の処理を説明するフローチャートである。
図9Aは、通信計画サーバ111が品質要求402を受信したときの処理手順901を示し、図9Bは、通信計画サーバ111が品質応答406を受信したときの処理手順902を示している。以下、各処理手順901、902について説明する。
処理手順901では、まずステップ911において、品質要求402を受信した通信計画サーバ111は、「Llife in venice」、などのビデオ識別子801と解像度803を検索キーとして、通信計画データベース112から通信計画案804のリストとサーバ・アドレス802とを読み出す。
次に、ステップ912において、通信計画サーバ111は、読み出された通信計画案804に含まれる含む最小バッファ量と、品質要求402に含まれるスタートアップ時間から初期帯域を算出する。具体的には、最小バッファ量をスタートアップ時間で割って初期帯域が算出される。これによって、通信計画案が生成される。ステップ911において、図8のレコード814が読み出された場合、通信計画サーバ111は、図6A〜図6Cに示す通信計画案1〜3を生成する。
ステップ913において、通信計画サーバ111は、初期帯域、スタートアップ時間、定常帯域及び最大帯域から構成される通信計画案を含む品質要求403を管理サーバ152に送信し、処理を終了する。
処理手順902では、ステップ921において、品質応答406を受信した通信計画サーバ111は、品質応答407を品質要求元(この場合は、コンピュータ101)に送信し、処理を終了する。
図10は、本発明の第1の実施形態の管理サーバ152の処理を説明するフローチャートである。
品質要求403を受信した管理サーバ152は、処理手順1001にしたがって処理を実行する。ステップ1011において、管理サーバ152は、品質要求403に含まれる通信計画案の中から最適なものを選択する。ここで、品質要求403に含まれる通信計画案のリストは、通信計画サーバ111が条件のよいものから順に並べたものである。管理サーバ152が品質要求403に含まれる通信計画案の中から最適なものを選択する方法は、様々のものが考えられる。以下、2つの方法を示す。
まず、ステップ1011において実行される処理の第1の方法を説明する。通信計画案1、2のように最初の0.5秒を除いた通信量が、指定された帯域値を超えないトラフィックによってネットワークが占められている場合、管理サーバ152は、通信中のすべてのフローに関する帯域の総和を算出することによって、通信量をほぼ正確に予測することができる。したがって、算出された帯域の総和と通信計画案に含まれる初期帯域との和が、ネットワーク・インタフェース132に接続されたリンクの帯域より十分に少ない場合、例えば、該通信計画案の初期帯域の10倍以上ある場合、該通信計画案が選択される。なお、10倍以外の数値を用いてもよい。
例えば、リンクの帯域が1Gbpsであり、算出された総和が800Mbps以下である場合、初期帯域が「20Mbps」である通信計画案1を選択することができる。
算出された定常帯域の総和がリンクの帯域を超えているときは、管理サーバ152は、次善の通信計画案を検討する。いずれの通信計画案も実行不能である場合、管理サーバ152は、要求を拒否する。すなわち、アドミッション制御によって動画ストリーミングが拒否される。
次に、ステップ1011において実行される処理の第2の方法を説明する。通信計画案3のように、通信量が定常帯域(通信計画案3の場合は5Mbps)を超えることがあり、どのタイミングで通信量が定常帯域を超えるかを管理サーバ152が予測できないトラフィックが存在する場合、管理サーバ152は、通信量の実測値を用いた予測値にしたがって制御する。
通信量の実測のために、IETFの標準プロトコルであるIPFIX、IPFIXの前身であるCisco社開発のプロトコルであるNetFlow、又はInMon社開発のプロトコルであるSFlowを使用することができる。これらのプロトコルによって管理サーバ152は、エッジルータ131のネットワーク・インタフェース132におけるトラフィック量の統計を取得し、取得されたトラフィックの統計に基づいて使用されている帯域を算出することができる。
管理サーバ152は、算出された実測値に基づいて、予測される帯域を求める。すなわち、管理サーバ152は、算出された実測値をそのまま予測値とする。当該予測値と通信計画案に含まれる最大帯域との和が、ネットワーク・インタフェース132に接続されたリンクの帯域より十分に少ない場合、例えば、該予測値がある通信計画案の初期帯域の20倍以上ある場合、該通信計画案を選択する。なお、20倍以外の数値を用いてもよい。
例えば、リンクの帯域が1Gbpsであり、算出された総和が600Mbps以下であれば、初期帯域が「20Mbps」である通信計画案1を選択することができる。
算出された総和がリンクの帯域を超えているときは、管理サーバ152は、次善の通信計画案を検討する。いずれの通信計画案も実行不能である場合、管理サーバ152は、要求を拒否する。すなわち、アドミッション制御によって動画ストリーミングが拒否される。
以下の説明では、NetFlowを使用してトラフィックが計測されることを前提とする。NetFlowを使用することによって、ルータ(この場合は、エッジルータ131、141)は、定期的に(例えば、1分おきに)、該ルータの特定のインタフェース(この場合は、ネットワーク・インタフェース132、142)におけるトラフィック量をトラフィックの種類ごとに管理サーバ152へ通知できる。前述の機能を使用することによって、管理サーバ152は、定期的にエッジルータ131のネットワーク・インタフェース132から出力されるトラフィックの帯域を算出できる。
時刻tにおける、クラスcに割り当てられた帯域Bu(c)は、直前の時刻t−1までの収集結果に基づいて、下式によって推定される。ただし、第1の実施形態では、一つのクラス(ストリーミング)に着目するため、以下ではcを省略する。
(式1)Bu=γ(1+β)Ba+(1−α)Br
予め定数として設定された総帯域Bm(当該のクラスに割り当てられた帯域)と(式1)によって推定されるBuとの差が割り当て可能な帯域であり、それらが新たな要求帯域以下であれば、割り当て可能である。
(式1)において、Baはトラフィック計測によって取得された帯域を示し、Brは個々のトラフィックごとの定常帯域又は最大帯域の和を示す。すなわち、スタートアップ時間の経過後、定常帯域を超えないトラフィックに関しては定常帯域が選択され、可変ビットレートにしたがうトラフィックに関しては最大帯域が選択される。
コア・ネットワーク151において、DiffServによるQoS制御を行っている場合、NetFlowからはトラフィック・クラス単位で集約された情報を取得されるが、取得された値は、下式によって指数的移動平均を算出することによって、平滑化している。
(式2)Ba(t)=αba(t)+(1−α)Ba(t−1)
ここで、baは、NetFlowから取得された帯域の値である。このアドミッション制御法においては、調節されたα、β、及びγの3つのパラメタを使用する必要がある。ここで、パラメタは、以下のとおりである。
αは、計測値平滑化係数と呼ばれ、トラフィック計測値の移動平均のなめらかさを制御するパラメタである。βは、帯域余裕率と呼ばれ、トラフィック計測値 (移動平均) に対するアドミッション制御の限界値のマージンを制御するパラメタである。γは、計測値寄与率と呼ばれ、アドミッション制御の限界値に関する測定値の寄与率((1−γ)が宣言値の寄与率)である。
(式1)によって、管理サーバ152は、ユーザ又はアプリケーションの要求に基づく帯域とトラフィック計測から算出した帯域との両方を考慮したアドミッション制御を行うことができる。その結果、ユーザ又はアプリケーションの要求に基づく帯域だけによって行われるアドミッション制御に比べると、定常帯域を超えるトラフィックが多くなっている場合、新規のセッションの開始が抑制され、既存のセッションのパケット損失及び遅延増加が抑制されるので、指定されたQoEをより高い確率で実現することが可能になる。
また、トラフィック計測から算出された帯域だけに基づいて行われるアドミッション制御に比べると、定常帯域を超えるトラフィックの数が増加したり、定常帯域からより大きくはずれるトラフィックが急に出現したりしても、予め最大帯域を加味してアドミッション制御が行われているために、既存のセッションのパケット損失及び遅延増加が発生する確率が低く抑えられる。以上がステップ1011において実行される処理の説明である。
処理手順1001の説明に戻る。
ステップ1012において、管理サーバ152は、ステップ1011で選択された通信計画案における初期帯域を最大帯域としてストリーミング・サーバ121側のルータ、すなわち、エッジルータ141のネットワーク・インタフェース142に設定する。具体的には、管理サーバ152が、エッジルータ141に帯域制限設定404を送信する。図4に示す例において、管理サーバ152が通信計画2を選択している場合、送信者が「10.10.22.12」であり、受信者が「10.10.21.10」であるフローに対して、「40Mbps」の帯域制限がエッジルータ141に設定される。
ステップ1013において、管理サーバ152は、ステップ1011で選択された通信計画案における定常帯域を最低保証帯域とするキューを、ユーザ側のルータ、すなわち、エッジルータ131のネットワーク・インタフェース132において、動画再生409における動画ストリーミング・トラフィックが、選択されたキューにはいるようにする。前述の操作を実現するため、具体的には次の手順にしたがう。
第1に、コア・ネットワーク151の初期化時に管理サーバ152は、ユーザ側の出口インタフェース(この場合は、ネットワーク・インタフェース132)において、キューの初期設定を実行する。例えば、ネットワーク・インタフェース132において、必要な最低保証帯域が5Mbps、7Mbps、及び10Mbpsの3種類であり、最大30個のキューを設定することができる場合、管理サーバ152は、次のようなキューを初期設定によって確保する。すなわち、管理サーバ152は、5Mbpsのキューを10個確保し、7Mbpsのキューを10個確保し、10Mbpsのキューを10個確保する。確保されたキューは、要求があるまで使用されない。
第2に、管理サーバは、ステップ1013において、選択された通信計画案によって指定された最低保証帯域をもつキューを、初期設定で確保されたキューの中から選択する。例えば、最低保証帯域として「5Mbps」が指定された場合、初期設定によって確保された5Mbpsのキューのひとつが割り当てられる。なお、指定された最低保証帯域に一致するキューが存在しない場合、指定された最低保証帯域より大きい最低保証帯域をもつキューが選択される。
前述のように、予めキューを確保する代わり、要求時にキューの構成を変更し、新たなキューを割り当てる方法も考えられる。しかし、要求があるたびにキューの構成を変更すると、キューの構成の変更時にキューイングされるべきパケットが廃棄される可能性、又は、再構成のためにエッジルータ131に大きな負荷がかかる可能性がある。前述のように、予めキューを確保する方法は、キューの割り当て時にパケットが失われることがなく、またオーバヘッドが小さいという利点がある。
ステップ1014において、管理サーバ152は、選択された通信計画案を含む品質応答406を通信計画サーバ111に送信し、処理を終了する。
図11は、本発明の第1の実施形態のストリーミング・サーバ121の処理を説明するフローチャートである。
再生要求408を受信したストリーミング・サーバ121は、処理手順1101にしたがって処理を実行する。
ステップ1111において、再生要求408を受信したストリーミング・サーバ121は、再生要求408に含まれる通信計画案における初期帯域で指定された時間にしたがって、動画のデータを送信する。例えば、再生要求408に通信計画案2が含まれている場合、指定された初期帯域は「40Mbps」であり、指定されたスタートアップ時間が「0.5秒」であるので、ストリーミング・サーバ121は、0.5秒間だけ40Mbpsの通信速度で動画のデータをコンピュータ101に送信する。
ステップ1112において、ストリーミング・サーバ121は、指定された定常帯域、及び最大帯域にしたがって残りの動画のデータを送信する。指定された定常帯域及び最大帯域がともに「5Mbps」である場合、ストリーミング・サーバ121は、5Mbpsを超えない範囲で、かつ受信側アプリケーションのジッター・バッファがあふれないように動画のデータを送信する。
ストリーミング・サーバ121は、各ストリーミング・コンテンツの再生において、再生開始後どの時刻にどれだけのデータを消費するかがわかる(実際に再生してみればわかるが、再生することは必須ではない)ので、受信側アプリケーションのジッター・バッファにバッファリングされたデータ量を推定することができる。ストリーミング・サーバ121は、当該推定に基づいて、ジッター・バッファがあふれないように動画のデータの送信を制御する。
また、受信側アプリケーションにおいて動画が停止したり、再生速度が変化したりすることがある。このような場合、再生要求408とその応答に使用されるプロトコル、例えば、IETF標準のプロトコルRTSP(Real−Time Streaming Protocol)を使用するか、又は、動画のデータとその制御のためのプロトコル、例えば、IETF標準のプロトコルRTP(Real−time Transport Protocol)及びRTCP(Real−Time Control Protocol)を使用することによって、現在、再生がどこまですすんでいるかをコンピュータ101からストリーミング・サーバ121に通知され、ストリーミング・サーバ121は通知された情報をジッター・バッファの制御のために使用することができる。
図12は、本発明の第1の実施形態において、ユーザが停止ボタン316を操作(クリック)したときのネットワークシステムにおける処理手順を説明するシーケンス図である。
停止ボタン316が操作(クリック)されることによって発生した、ユーザによる停止要求1201は、コンピュータ101上で動作するWebブラウザが受け取る。コンピュータ101は、まず、ストリーミング・サーバ121に停止要求1202を送信して、ストリーミング・サーバ121からの動画のデータの送信を停止する。
コンピュータ101は、続いて、品質要求1203を通信計画サーバ111に送信する。品質要求1203には、対応する要求を識別するために必要なビデオ識別子801が含まれる。
品質要求1203を受信した通信計画サーバ111は、品質要求1204を管理サーバ152に送信する。品質要求1204には、品質要求1203の送信者、すなわち、コンピュータ101のIPアドレス「10.10.21.10」が含まれる。
品質要求1204を受信した管理サーバ152は、品質応答1207、帯域制限設定解除1205、及びキューイング設定解除1206の3つのメッセージをそれぞれ送信する。具体的には、品質応答1207は、通信計画サーバ111に送信され、帯域制限設定解除1205は、エッジルータ141に送信され、キューイング設定解除1206は、エッジルータ131に送信される。また、帯域制限設定解除1205によって帯域制限設定404における設定が無効にされ、キューイング設定解除1206によってキューイング設定405における設定が無効にされる。
品質応答1207を受信した通信計画サーバ111は、コンピュータ101に品質応答1208を送信する。なお、品質要求402及び品質要求403にタイムアウト時間が含まれる場合は、帯域制限設定解除1205及びキューイング設定解除1206は送信されない。
次に、再生中に高解像度ボタン314又は低解像度ボタン313を操作(クリック)することによって生じる処理について説明する。
再生中に高解像度ボタン314又は低解像度ボタン313が操作(クリック)された場合、コンピュータ101は、まず、再生中の動画を停止させる。前述の処理の手順は図12に示すシーケンス図とほぼ同一であるが、停止要求1202の代わりに一時停止要求が送信される。
一時停止要求を受信したストリーミング・サーバ121は、動画の再生を開始してから停止まで経過時刻を記憶し、解像度の異なる動画の再生を開始する。動画を再生する場合のシーケンスは、図4と同様であるが、再生要求408の代わりに再開要求が送信される。再開要求を受信したストリーミング・サーバ121は、記憶されている動画の再生を開始してから停止までの経過時刻に基づいて、一時停止されたところから動画の再生を開始する。これによって、ちょうど再生を停止したところから、解像度が異なる動画が再生される。
なお、画質改善ボタン315が操作(クリック)された場合の処理は、図4と同様のシーケンスにしたがって処理が実行される。ただし、ユーザによる品質要求401は画質改善要求であり、また、品質要求402は解像度及びスタートアップ時間の代わりに「画質改善」を表す内容が含まれる。また、品質要求403において、すでに選択されていた通信計画案がVBRによる計画であれば、CBRによる計画に変更する。管理サーバ152は、キューイング設定405において、品質改善要求による新たな通信計画案に適したキューを選択する。
また、本実施形態において、最低保証帯域が確保できない場合、動画の再生は拒否され、再生することができない。ネットワークが輻輳していて、予め再生できないことが分かる場合、高解像度ボタン314を無効化、すなわち、操作(クリック)できないようにすることによって、ユーザが無駄な操作をしないようにすることができる(初期品質選択画面311においては、画質改善ボタン315と停止ボタン316とが無効化されている)。
具体的には、初期品質選択画面311及び低解像度再生画面321を生成するときに、これらのWebページを通信計画サーバ111がCGIによって生成するようにし、通信計画サーバ111が管理サーバ152に予め通信計画案の実現可否を問い合わせることによって、実現できないメニュー項目(ボタン)を無効化できる。なお、管理サーバ152は、予めトラフィックを計測し、計測結果に基づいて通信計画サーバ111に通信計画案の実現可否を応答することができる。
さらに、初期品質選択画面311、低解像度再生画面321、及び高解像度再生画面331が表示された後に、ネットワークの状態が変化して、各画面311、321、331が表示されたときには実現可能だったメニュー項目が実現不可能になったり、逆に各画面311、321、331が表示されたときには実現不可能だったメニュー項目が実現可能になったりすることがある。
前述のような場合に対処するには、表示された画面311、321、331を定期的にリフレッシュする、すなわち、その時点におけるメニュー項目の実現の可否を管理サーバ152に問い合わせ、これによって表示を更新することができる。以上が本発明の第1の実施形態の説明である。
以下、本発明の第2の実施形態について説明する。
図13は、本発明の第2の実施形態における、ネットワークシステム構成を示すブロック図である。以下、第1の実施形態との差異を中心に説明する。
図1との相違点は、ネットワーク上でコンピュータ101、102とエッジルータ131との間を接続するHGW(ホーム・ゲートウェイ)1301が備えられ、また、通信計画サーバ111がない代わりに、HGW1301には計測制御サーバ1302が含まれる。その他の構成については図1と同一である。
図14A及び図14Bは、本発明の第2の実施形態における、ネットワークへの品質要求を入力するためのグラフィカル・ユーザ・インタフェース(GUI)を説明する図である。図14A及び図14Bに示す例では、特定のアプリケーションに限定していない場合における品質要求を入力するためのGUIである。
図14Aに示す品質メニュー1401には、品質改善ボタン1402、及びキャンセル・ボタン1403が表示されている。使用中の任意のアプリケーションにおいて、品質の改善を希望する場合、ユーザは品質改善ボタン1402を操作(クリック)する。また、すでに要求された品質改善をキャンセルしたい場合、ユーザは、キャンセル・ボタン1403を操作(クリック)する。
図14Bに示す品質メニュー1411には音質改善ボタン1412、画質改善ボタン1413、Web高速化ボタン1414、及びキャンセル・ボタン1415が表示されている。具体的には、再生中の任意のアプリケーションにおいて、音質の改善を希望する場合、ユーザは音質改善ボタン1412を操作(クリック)する。また、再生中の任意のアプリケーションにおいて、画質の改善を希望する場合、ユーザは画質改善ボタン1413を操作(クリック)する。また、ユーザがWebブラウザ又はWebサービスを使用し、これらの応答の改善を希望する場合、ユーザはWeb高速化ボタン1414を操作(クリック)する。また、すでに要求された品質改善をキャンセルしたい場合、ユーザは、キャンセル・ボタン1415を操作(クリック)する。
本実施形態では、コア・ネットワーク151におけるQoS保証のためにDiffServを使用していることを前提とする。コア・ネットワーク151におけるトラフィックは、会話クラス、ストリーミング・クラス、Webクラス、及びベストエフォート・クラスにクラス分けされ、クラスごとにエッジルータ131、141のキューなどの資源が割り当てられる。
例えば、エッジルータ131のネットワーク・インタフェース132において、会話クラスに高優先度キューが割り当てられ、他のトラフィックには複数の低優先度キュー同士で帯域が分割される。すなわち、いわゆるLLQ(Low Latency Queueing)が適用される。
これによって、ストリーミング・クラス、Webクラス、及びベストエフォート・クラスには、それぞれ最低保証帯域が設定される。また、会話クラスが他のクラスを圧迫することがないように、会話クラスのトラフィックに対しては最大帯域が決定され、最大帯域を超えないようにアドミッション制御が行われる。なお、会話クラスのように優先的な処理を必要とするトラフィックが存在しない場合、LLQの代わりのWFQだけからなるスケジューリングを指定すればよい。
図15は、本発明の第2の実施形態において、ユーザが任意のアプリケーションの使用中に、品質改善ボタン1402、音質改善ボタン1412、画質改善ボタン1413、Web高速化ボタン1414、又はキャンセル・ボタン1415を操作したときのネットワークシステムにおける処理手順を示すシーケンス図である。
ユーザによる品質要求1501は、各ボタン(品質改善ボタン1402、音質改善ボタン1412、画質改善ボタン1413、Web高速化ボタン1414、及びキャンセル・ボタン1415)のいずれかを操作(クリック)することによって発生し、そのイベントをコンピュータ101上で動作するWebブラウザが受信する。
ユーザによる品質要求1501を受信したコンピュータ101は、計測制御サーバ1302に品質要求1502を送信する。品質要求1502には、操作(クリック)されたボタンに対応するメディアの種類とQoE情報とが含まれる。
品質要求1502に含まれるメディアの種類は、品質改善ボタン1402が操作(クリック)された場合、不明であることを示す値が含まれるか、又はメディアの種類が省略される。また、音質改善ボタン1412が操作(クリック)された場合、メディアの種類は「音声」である。画質改善ボタン1413が操作(クリック)された場合、メディアの種類は「動画」である。「画質」は、静止画を示す可能性もあるが、ここでは動画サービスを行っていることを前提とし、動画の画質であることを仮定する。Web高速化ボタン1414が操作(クリック)された場合、メディアの種類は「Web」である。
品質改善ボタン1402、音質改善ボタン1412、又は画質改善ボタン1413が操作(クリック)された場合、品質要求1502に含まれるQoE情報は、「高品質」である。Web高速化ボタン1414が操作(クリック)された場合、品質要求1502に含まれるQoE情報は、「高速応答」である。
品質要求1502を受信した計測制御サーバ1302は、図16に示す手順にしたがって処理を実行する。つまり、計測制御サーバ1302は、品質要求1502に含まれる内容に基づいて、品質要求1503を生成し、生成された品質要求1503を管理サーバ152に送信する。
具体的には、計測制御サーバ1302は、HGW1301が計測したトラフィック計測情報を用い、品質要求1502に含まれるメディアの種類から、対応するDiffServのトラフィック・クラスを特定し、特定されたトラフィック・クラスを品質要求1503に含める。また、品質要求1502に含まれるQoE情報とHGW1301が計測したトラフィック計測情報とに基づいて保証するべき帯域を算出し、算出された帯域を品質要求1503に含める。さらに、計測制御サーバ1302は、品質要求1502の送信者、すなわち、コンピュータ101のIPアドレス「10.10.21.10」も品質要求1503に含める。
品質要求1503を受信した管理サーバ152は、図17に示す手順にしたがって処理をする。具体的には、管理サーバ152は、エッジルータ131にキューイング設定1504を送信し、また、計測制御サーバ1302に品質応答1505を送信する。品質応答1505には、確保された帯域の値が含まれる。キューイング設定1504には、エッジルータ131においてキューを設定するための情報が含まれる。
キューイング設定1504によって、コンピュータ101へ送信され、キューイング設定1504において指定されたクラスのトラフィックに関して、キューイング設定1504において指定された帯域を最低保証帯域として持つキューが使用されるように、エッジルータ131のネットワーク・インタフェース132が設定される。
これによって、ユーザが音質改善を要求した場合、その時点で使用していた会話音声又はストリーミング音声に対して帯域が確保されることによって、音質が改善される。また、ユーザが画質改善を要求した場合、その時点で使用していた会話動画又はストリーミング動画に対して帯域が確保されることによって画質が改善される。
また、ユーザがWeb高速化を要求した場合、Webトラフィックに対して帯域が確保されることによって、応答速度が改善される。
品質応答1505を受信した計測制御サーバ1302は、コンピュータ101に品質応答1506を送信する。品質応答1506には、品質応答1505と同様に、確保された帯域の値が含まれる。
次に、HGW1301が実行するトラフィック計測について説明する。
HGW1301は、HGW1301を通過するパケットを監視し、通過するパケットがUDPパケットであれば、さらにRTPパケットであるか否かを判定する。
RTPパケットであると判定された場合、HGW1301は、さらに、該パケットが、IETF標準若しくはデファクト標準における音声コーデックを使用しているか、又は動画コーデックを使用しているかを判定し、音声コーデックを使用していると判定されたパケットを音声パケット分類し、動画コーデックを使用していると判定されたパケットを動画パケットに分類する。
また、HGW1301は、TCPパケットに関してはHTTPパケットであるか否かを判定し、HTTPパケットと判定されたパケットをWebパケットに分類する。音声パケット、動画パケット、又はWebパケットのいずれでもないパケットは、それ以外のパケットに分類される。HGW1301は、トラフィック計測によって、前述のような4種類のパケットに分類する。
HGW1301は、前述の各種類のパケットについて、さらに、IPパケットに含まれルDSCP(DiffServ Code Point)ごとに、エッジルータ131からコンピュータ101に向かうパケットのデータ量をカウントし、トラフィック量を計測する。
会話に関してはDiffServのEFPHB(ExpeditedForwardingPer−Hop−Behavior)を使用し、ストリーミングに関してはAF3PHB(AssuredForwarding3Per−Hop−Behavior)を使用していると仮定する。すなわち、会話とストリーミングとをDSCPによって区別することができる。
これによって、音声、動画、Web及びその他のトラフィックのHGW1301におけるトラフィックの種類ごとの使用帯域を算出できる。HGW1301において、パケット損失が発生していなければ、算出された使用帯域はネットワーク・インタフェース132における使用帯域と等しい。
以上の説明したトラフィック計測法では、HGW1301がトラフィックを計測することを前提としていたが、トラフィック計測をエッジルータ131が行うことも可能である。すなわち、計測制御サーバ1302は、エッジルータ131からIPFIX、NetFlow、又はSFlowなどのプロトコルを使用してネットワーク・インタフェース132におけるトラフィック計測情報を受信し、受信したトラフィック計測情報に基づいて、ネットワーク・インタフェース132における出力トラフィックの帯域をトラフィックの種類ごとに算出する。
ただし、ルータは、基本的にはIP層において動作するので、RTPパケットの解析機能を備えていないことが多い。そのため、ルータは、会話かストリーミングか否かはDSCPによって区別することができるが、前述の方法では、音声か動画かを区別することができない。したがって、パケット・サイズから音声か動画かを推定する(音声パケットは比較的小さく、数100バイト以下、プロトコルによってはほとんど100バイト以下である)などの方法をとる必要がある。
このように、エッジルータ131がトラフィック計測を行う場合、HGW1301は、必ずしも必要ない。計測制御サーバ1302は、HGW1301から独立に存在することも可能であり、例えば、管理サーバ152に含めることも可能である。計測制御サーバ1302が管理サーバ152に含まれる場合、品質要求1503及び品質応答1505は、プログラム内の関数呼び出しと、そこからの復帰によって実現することができる。
図16A及び図16Bは、本発明の第2の実施形態の計測制御サーバ1302の処理を説明するフローチャートである。
図16Aは、品質要求1502を受信したときの処理手順1601を示し、図16Bは、品質応答1506を受信したときの処理手順1621を示している。以下、処理手順1601、1621について説明する。
処理手順1601では、まずステップ1611において、計測制御サーバ1302は、品質要求1502に含まれるメディアの種類からトラフィック・クラスの候補を求める。例えば、メディアの種類が「音声」又は「動画」である場合、トラフィック・クラスは、会話又はストリーミングである。
ステップ1612において、計測制御サーバ1302は、メディアの種類とトラフィック・クラス候補とのすべての組について、トラフィック計測結果を求める。
ステップ1613において、計測制御サーバ1302は、トラフィック計測結果に基づいて、品質劣化があるトラフィック・クラスを特定する。
具体的には、メディアの種類が「音声」の場合、次のように判定される。計測制御サーバ1302は、音声と動画とをあわせた会話のトラフィックが、該トラフィックに対して割り当てられている帯域と比べて余裕があるか、又は、割り当て帯域が逼迫しているかを判定する。また、計測制御サーバ1302は、音声と動画とをあわせたストリーミングのトラフィックが、該トラフィックに対して割り当てられている帯域と比べて余裕があるか、又は、割り当て帯域が逼迫しているかを判定する。
会話のトラフィックのほうがもっとも輻輳している場合、計測制御サーバ1302は、会話音声が品質劣化のあるトラフィック・クラスであると特定する。ストリーミングのトラフィックのほうがもっとも輻輳している場合、計測制御サーバ1302は、ストリーミング音声が品質劣化のあるトラフィック・クラスを特定する。
また、メディアの種類が「動画」の場合においても、会話のトラフィックのほうがもっとも輻輳している場合、計測制御サーバ1302は、会話動画が品質劣化のあるトラフィック・クラスであると特定する。ストリーミングのトラフィックのほうがもっとも輻輳している場合、ストリーミング動画が品質劣化のあるトラフィック・クラスであると特定する。
ここで、複数のクラスのうちのいずれがもっとも輻輳しているかは、次に示す3つの方法のいずれかを用いることによって判定することができる。
第1の方法は、任意のクラスのすべてのトラフィックが使用する総帯域が、許容されている帯域に対して占める割合が大きいほうを、より輻輳していると判定する。
第2の方法は、パケット損失を計測することによって、パケット損失が大きいクラスを、より輻輳していると判定する。RTPのフローのようにパケットがシーケンス番号を含むUDPフローにおいては、パケット損失がある場合、シーケンス番号がとびとびになるため、これによってパケット損失率を求めることができる。
第3の方法は、遅延を計測することによって、遅延が大きいクラスを、より輻輳していると判定する。RTPとRTCPによって構成される音声及び動画のフローのようにパケットにタイムスタンプが含まれる場合、送信側のコンピュータ101、すなわち、ストリーミングであれば、ストリーミング・サーバ121とHGW1301との時計をIETF標準のプロトコルであるNTP(Network Time Protocol)を用いて同期させることによって、遅延を計測することができる。
ステップ1614において、計測制御サーバ1302は、品質保証のために必要な帯域を推定する。すなわち、計測制御サーバ1302は、品質劣化があると特定されたトラフィック・クラスに関して、現在使用されている帯域の2倍の帯域を保証帯域とする。例えば、品質劣化しているのが動画ストリーミングであり平均で「3Mbps」の帯域を使用している場合、動画ストリーミングに対して「6Mbps」を保証帯域として割り当てる。
ステップ1615において、計測制御サーバ1302は、管理サーバ152に、前述の処理によって決定された内容が含まれる品質要求1503を送信し、処理を終了する。
処理手順1621では、ステップ1622において、品質応答1505を受信した計測制御サーバ1302は、品質応答1506を品質要求元であるコンピュータ101に送信し、処理を終了する。
図17は、本発明の第2の実施形態の管理サーバ152の処理を説明するフローチャートである。管理サーバ152は、処理手順1701にしたがって処理を実行する。
ステップ1702において、品質要求1503を受信した管理サーバ152は、ユーザ側ルータ、つまり、エッジルータ131にキューイング設定1504を送信することによって、エッジルータ131の出口に、該キューイング設定1504において指定された帯域を最低保証帯域として設定する。
ステップ1503において、管理サーバ152は、計測制御サーバ1302に品質応答1505を送信する。品質要求1503において指定された帯域が確保された場合、品質応答1505として許可を表すメッセージが計測制御サーバ1302に送信され、品質要求1503において指定された帯域が確保されない場合、品質応答1505として拒否を表すメッセージが計測制御サーバ1302に送信される。
次に、キャンセル・ボタン1403、1415が操作(クリック)されたときの処理について説明する。キャンセル・ボタン1403、1415が操作(クリック)された場合における通信シーケンスは図15と同様である。ただし、ユーザによる品質要求1501はキャンセル要求であり、キューイング設定1504はキューイング設定を解除する要求である。これによって、ネットワークの設定は、品質改善ボタン1402などの要求ボタンが操作(クリック)される前の状態に戻る。
品質改善ボタン1402、音質改善ボタン1412、画質改善ボタン1413、又はWeb高速化ボタン1414は、各ボタンに対応する品質を改善するために必要なネットワーク資源が確保されないときには効果がない。前述のような場合に、ユーザの無駄な入力を避けるために、次のようにすればよい。
計測制御サーバ1302は、CGIを使用してコンピュータ101に品質メニュー1401又は1411を表示する。そのときに、計測制御サーバ1302は、管理サーバ152に、品質メニュー1401又は1411上に表示された各品質改善のためのボタンを操作(クリック)することによって、品質改善が可能か否かを問い合わせる。管理サーバ152から品質の改善が不能であると応答があった場合、計測制御サーバ1302は、対応するボタンを無効化する。計測制御サーバ1302は、管理サーバ152に問い合わせてページをリフレッシュすることによって、最新の状況をコンピュータ101に表示することができる。
また、品質メニュー1401又は1411に表示された各品質改善のためボタンを操作(クリック)することによって得られた効果は、ユーザに分かりにくいため、品質メニュー1401及び1411の下部にメッセージ表示欄を設けて、管理サーバ152からフィードバックされる結果を計測制御サーバ1302が解釈してコンピュータ101に表示することができる。管理サーバ152からの応答と計測制御サーバ1302の処理内容とに応じて、コンピュータ101に次のような内容を表示することができる。
第1に、計測制御サーバ1302が品質劣化の原因として会話音声を特定した場合、管理サーバ152から許可の応答があれば、前述したメッセージ表示欄に「会話の音質改善に成功しました」と表示される。また、管理サーバ152から拒否の応答があれば、前述したメッセージ表示欄に「会話の音質改善に失敗しました」と表示される。
第2に、計測制御サーバ1302が品質劣化の原因としてストリーミング音声を特定した場合、管理サーバ152から許可の応答があれば、前述したメッセージ表示欄に「ストリーミングの音質改善に成功しました」と表示される。管理サーバ152から拒否の応答があれば、前述したメッセージ表示欄に「ストリーミングの音質改善に失敗しました」と表示される。
第3に、計測制御サーバ1302が品質劣化の原因として会話動画を特定した場合、管理サーバ152から許可の応答があれば、前述したメッセージ表示欄に「会話の画質改善に成功しました」と表示される。管理サーバ152から拒否の応答があれば、前述したメッセージ表示欄に「会話の画質改善に失敗しました」と表示される。
第4に、計測制御サーバ1302が品質劣化の原因としてストリーミング動画を特定した場合、管理サーバ152から許可の応答があれば、前述したメッセージ表示欄に「ストリーミングの画質改善に成功しました」と表示される。管理サーバ152から拒否の応答があれば、前述したメッセージ表示欄に「ストリーミングの画質改善に失敗しました」と表示される。