ネットワークシステム及び通信計画サーバ
【課題】ユーザが求めるＱｏＥを実現するために通信セッション開始時に最適な通信計画を求める。また、通信中にユーザが求めるＱｏＥの改善を実現し、そのために必要な動的な帯域変更をルータにおいて実現すること。
【解決手段】計算機と、ネットワークノードと、計算機に、アプリケーションサーバと、通信計画サーバと、管理サーバとを備えるネットワークシステムであって、通信計画サーバは、計算機から、品質条件を受信した場合、受信した品質条件を実現するための、通信条件を複数管理サーバに送信し、管理サーバは、受信した複数の通信条件の中から最適な通信条件を選択し、選択された通信条件を含む品質応答をアプリケーションサーバに送信し、アプリケーションサーバは、品質応答に含まれる通信条件にしたがって、計算機に、計算機上で実行されるアプリケーションに必要なデータを送信することを特徴とする。
【解決手段】計算機と、ネットワークノードと、計算機に、アプリケーションサーバと、通信計画サーバと、管理サーバとを備えるネットワークシステムであって、通信計画サーバは、計算機から、品質条件を受信した場合、受信した品質条件を実現するための、通信条件を複数管理サーバに送信し、管理サーバは、受信した複数の通信条件の中から最適な通信条件を選択し、選択された通信条件を含む品質応答をアプリケーションサーバに送信し、アプリケーションサーバは、品質応答に含まれる通信条件にしたがって、計算機に、計算機上で実行されるアプリケーションに必要なデータを送信することを特徴とする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はパケット交換ネットワークにおける通信品質の改善に関する。
【背景技術】
【０００２】
インターネット・プロトコル（ＩＰ）に基づく通信の品質、すなわち、ＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）を改善するための方法として、インターネットの標準化組織であるＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）の標準ドキュメントＲＦＣ２２１２、ＲＦＣ２２１５などにおいて規定されているＩｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅｓ（ＩｎｔＳｅｒｖ）、及びＩＥＴＦのドキュメントＲＦＣ２４７４、ＲＦＣ２４７５、ＲＦＣ２４３０などにおいて規定されているＤｉｆｆｅｒｅｎｔｉａｔｅｄ Ｓｅｒｖｉｃｅｓ（ＤｉｆｆＳｅｒｖ）がある。現在、大規模ネットワークに適しているＤｉｆｆＳｅｒｖが広く使用されている。
【０００３】
しかし、通信サービスにおけるユーザの体感品質、すなわち、ＱｏＥ（Ｑｕａｌｉｔｙ ｏｆ Ｅｘｐｅｒｉｅｎｃｅ）を向上させることが必要である。ＱｏＥを向上させることがユーザの満足度を高めることにつながる。
【０００４】
ＱｏＥを向上させるためには、端点間（ｅｎｄ−ｔｏ−ｅｎｄ）のＱｏＳを保証することが必要と考えられてきた。ＡＴＭ（Ａｓｙｎｃｈｒｏｎｏｕｓ Ｔｒａｎｓｆｅｒ Ｍｏｄｅ）は、通信フローごとの端点間のＱｏＳ保証のための機構を備えていたが、今日必要とされている大規模な通信サービスに適用できるものではなかった。ＩｎｔＳｅｒｖにおいては、ＩＥＴＦ標準ドキュメントＲＦＣ１６６３によって規定されたプロトコルであるＲＳＶＰ（ｒｅｓｏｕｒｃｅ ＲｅＳｅｒＶａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）を使用してフロー単位でルータ等の資源を確保することによってＱｏＳを保証する。ＩｎｔＳｅｒｖはインターネットにおいてこのようなフローごとの通信のＱｏＳを保証するための方法であったが、ＡＴＭと同様に大規模ネットワークには適用できなかった。
【０００５】
これに対してＤｉｆｆＳｅｒｖは、フロー単位ではなくフローをまとめたクラスを単位とすることによって大規模ネットワークへの適用を可能にした。しかし、その反面、端点間のＱｏＳが保証できる方法ではなかった。
【０００６】
そのため、ＤｉｆｆＳｅｒｖとＩｎｔＳｅｒｖとを組み合わせる、すなわち、フローごとにネットワーク・トラフィックを制御することが困難なコア・ネットワークにおいてはＤｉｆｆＳｅｒｖを使用し、ＬＡＮやアクセス・ネットワークのようなフローごとの制御が可能な末端のネットワークにおいてはＩｎｔＳｅｒｖ又はそれに準じる方法を使用する方法、例えば、ＲＦＣ２９９８に記述されている方法が開発されてきた。すでに一部のキャリアにおいてサービスが開始されているＮＧＮ（次世代ネットワーク（Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｎｅｔｗｏｒｋｓ））においては、前述したような方法の実現を可能にするプロトコルを採用することによって、端点間のＱｏＳ保証を可能にしている。
【０００７】
ＮＧＮの基本的な枠組みに関してはＩＴＵ−Ｔ（国際電気通信連合（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｕｎｉｏｎ）の電気通信標準化部門）、３ＧＰＰ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）、ＥＴＳＩ（欧州電気通信標準化機構（Ｅｕｒｏｐｅａｎ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｔａｎｄａｒｄｓ Ｉｎｓｔｉｔｕｔｅ））などにおいて議論され、標準化が進められてきた。音声、又は動画などの通信においてはＩＥＴＦ標準ドキュメントＲＦＣ３２６１によって規定されたセッション制御プロトコルＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）が使用されることが多い。そのため、ＮＧＮにおいてはＳＩＰを用いた通信を通じてＱｏＳ保証の実現するためのＩＭＳ（ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ）という機構が使用される。
【０００８】
ＳＩＰを使用したＱｏＳ保証のための機構としては、ＳＩＰメッセージに含まれるＳＤＰ（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）のメッセージと、ＳＩＰによるメッセージングと組み合わされたＲＳＶＰによるメッセージングとによって通信に使用する資源を確保する方法がある（例えば、非特許文献１参照）。端点間の通信のためのＳＤＰメッセージと、端点を結ぶパス上に存在するルータの資源を確保するためのＲＳＶＰメッセージとを使用することによって、通信帯域幅、及びパケット損失率等のＱｏＳパラメタが記述され、それらがネットワークに伝えられる、すなわち、目標とするべき１個のＱｏＳ条件を指定することができる。そして、それらをネットワークにおいて実現することができる。
【０００９】
ＳＤＰメッセージには通信に使用するメディア、すなわち、音声又は動画等の区別と、音声又は動画等において使用されるコーデックなどの情報とが含まれている。前述のメディア又はコーデックは、通信相手において実現可能であるとは限らない。そのため、前述の問題を解決するため、ＳＤＰによる通信において、実現可能なメディア又はコーデックの確立を交渉するためのｏｆｆｅｒ／ａｎｓｗｅｒ ｍｏｄｅｌをＳＤＰメッセージに記述する方法がある（例えば、非特許文献２参照）。すなわち、ＳＩＰのＩＮＶＩＴＥ要求を送信した送信者が、受信者から要求したとおりの内容を含むＳＤＰメッセージを受け取れば、メディア又はコーデックの確立の交渉が成立するが、他の条件を含むＳＤＰメッセージを受信したときには、メディア又はコーデックが変更される。
【００１０】
ＮＧＮにおいて、非特許文献１におけるＱｏＳ保証方式を拡張して、ＲＳＶＰ又はそれに準じるプロトコルをかならずしも使用しなくても、メッセージングを媒介するＳＩＰサーバが、本来は端点間の通信だけで使用されるＳＩＰ及びＳＤＰのメッセージを読み取ったり、書き換えたりすることによって、ネットワークにおける資源やアドミッションを制御することを可能にする方法がある（例えば、非特許文献３）。また、携帯電話の環境において、ＳＩＰ及びＳＤＰを使用したＱｏＳ保証の方法もある（例えば、特許文献１参照）。
【特許文献１】米国特許７１０６７１８Ｂ２号明細書
【非特許文献１】Camarillo, G., Marshall, W., and Rosenberg, J., “Integration of Resource Management and Session Initiation Protocol (SIP)”, RFC 3312, IETF, October 2002.
【非特許文献２】Rosenberg, J. and Schulzrinne, H., “An Offer/Answer Model with the Session Description Protocol (SDP)”, RFC 3264, IETF, June 2002.
【非特許文献３】3rdGenerationPartnershipProject(3GPP),“InternetProtocol(IP)multimediacallcontrolprotocolbasedonSessionInitiationProtocol(SIP)andSessionDescriptionProtocol(SDP);Stage3(Release7)”,3GPPTS24.229V7.3.0,March2006.
【発明の開示】
【発明が解決しようとする課題】
【００１１】
特定の通信セッションにおいて必要となる資源は、必ずしも通信の開始から終了までの間、一定であるとは限らない。例えば、ストリーミングのように、送信する内容が予め決定されている場合、必要となる資源の予測が可能であり、かつ通信のスケジュールも制御することができる。すなわち、通信の進行に伴ってＱｏＳ条件を変更することによって、より多くのユーザが満足できるようなスケジューリングができる。具体的には、ユーザが求めるＱｏＥを実現するためのスケジュールを複数個用意するか、又はパラメタを変えることによって連続的に変化するスケジュールを規定することができる。
【００１２】
しかし、前述のように計画にしたがって、通信中にＱｏＳ条件を変更するためには解決しなければならない課題が２つある。
【００１３】
第１に、従来のＮＧＮに用いられる方法では、ＱｏＳ条件を変更するたびにセッション制御メッセージング（ｒｅＩＮＶＩＴＥ要求）が必要になる。通信開始時にネットワーク・サーバが知ることができるのは、その時点におけるアプリケーションのＱｏＳ要求であり、アプリケーションがどのようなＱｏＥを要求し、要求されたＱｏＥをどのようなスケジュールによって実現されようとしているかはわからない。そのため、ネットワーク・サーバは、通信開始時、又は通信中のＱｏＳ条件変更時においても、当該のアプリケーションに最適なＱｏＥ又はＱｏＳを実現できない可能性があり、また、ユーザ全体、すなわち、ネットワーク全体としても最適な制御を行うことができないという問題がある。
【００１４】
つまり、第１の課題は、個々のユーザの通信について、当該ユーザのＱｏＥが最適になるような資源の割り当て計画を実現し、かつ、ネットワーク全体におけるユーザ全体のＱｏＥが最適になるような資源割り当て計画を実現することである。
【００１５】
第２に、前述のような通信を実現するためには、ＱｏＳ条件の変更に伴って、通信中にルータの設定を変更する必要が生じる。したがって、ルータの設定変更によって生じる通信障害をなくし、オーバヘッドを減少させる必要がある。具体的には、ルータのキュー構成を動的に変更することによってルータに負荷がかかるのを防止し、また、構成変更が完了するまでキューイングが停止してパケットが損失することを防止しなければならない。
【００１６】
つまり、第２の課題は、ルータに大きな負荷をかけることなく、かつ、パケット損失などの問題を起こすことなく、ルータの出力キューにおける帯域設定などのＱｏＳ条件を動的に変更できるようにすることである。
【００１７】
本発明の目的は、これらの問題を解決することにある。
【課題を解決するための手段】
【００１８】
本発明の代表的な一例を示せば以下の通りである。すなわち、計算機と、ネットワークノードと、前記計算機上で実行されるアプリケーションに必要なデータを前記計算機に送信するアプリケーションサーバと、前記計算機と前記アプリケーションサーバとの間の通信の計画を管理する通信計画サーバと、前記計算機、前記ネットワークノード及び前記アプリケーションサーバが接続されたネットワークを管理する管理サーバとを備えるネットワークシステムであって、前記アプリケーションサーバは、第１のプロセッサ、前記第１のプロセッサと接続されている第１のメモリ、前記第１のプロセッサと接続されている第１の不揮発性記憶媒体、前記ネットワークと接続される第１のネットワークインタフェースを備え、前記通信計画サーバは、第２のプロセッサ、前記第２のプロセッサと接続されている第２の記憶媒体、前記ネットワークと接続される第２のネットワークインタフェースを備え、前記管理サーバは、第３のプロセッサ、前記第３のプロセッサと接続されている第３のメモリ、前記第３のプロセッサと接続されている第３の不揮発性記憶媒体、前記ネットワークと接続される第３のネットワークインタフェースを備え、前記通信計画サーバは、前記アプリケーションサーバが格納するデータに対する、前記ネットワークにおいて提供されるサービスの品質を決定する通信条件を前記第２の記憶媒体に格納し、前記計算機から、前記計算機上で実行されるアプリケーションの品質に対する前記計算機のユーザによる要求である第１の品質条件を受信した場合、前記受信した第１の品質条件を実現するための、複数の前記通信条件を前記管理サーバに送信し、前記管理サーバは、前記通信計画案を受信した場合、前記受信した複数の通信条件の中から最適な前記通信条件を選択し、前記選択された通信条件を含む品質応答を前記アプリケーションサーバに送信し、前記アプリケーションサーバは、前記品質応答に含まれる前記通信条件にしたがって、前記計算機上で実行されるアプリケーションに必要なデータを前記計算機に送信することを特徴とする。
【発明の効果】
【００１９】
本発明によれば、ユーザが要求するアプリケーションの品質に対する品質条件を最適にするような通信条件を実現でき、また、ネットワーク全体の帯域を考慮した、該ネットワークにおけるユーザ全体の品質条件を最適にする通信条件を実現できる。また、パケット損失などの問題を起こすことなく、ネットワークノードの出力インタフェースにおけるキューの帯域設定を動的に変更できる。
【発明を実施するための最良の形態】
【００２０】
本発明の第１の実施形態について説明する。
【００２１】
本実施形態は、ユーザからの要求に基づいて、動画ストリーミングが再生されるときに、該ユーザに最適なＱｏＥを実現し、かつ、ネットワークにおけるユーザ全体に最適なＱｏＥを実現する。
【００２２】
動画ストリーミングにおけるＱｏＥの主要な要素としては、画像の品質、すなわち、解像度、画面の乱れの少なさ、及びスタートアップ時間の短さが考えられる。ここで、スタートアップ時間とは、動画再生の要求から、動画の再生が開始されるまでの時間である。
【００２３】
ストリーミングにおいて、通常、ジッターを減少させるために受信側のアプリケーションが数秒間データをバッファリングしてから動画を再生する。そのため、ＱｏＥを改善するには、コンテンツの画質を劣化させずにデータを転送し、再生開始までの時間（以下、スタートアップ時間と呼ぶ）を縮めることが重要である。特に、スタートアップ時間の短さは、ユーザが複数のコンテンツの中から興味のあるものを選択するとき、いわゆるザッピングを行うときに重要になる。
【００２４】
本実施形態において、解像度、及びスタートアップ時間の短さを確保することを、ＱｏＥを改善するための主要な目標とする。
【００２５】
図１は、本発明の第１の実施の形態における、ネットワークシステム構成を示すブロック図である。
【００２６】
コア・ネットワーク１５１には、エッジルータ１３１、及びエッジルータ１４１が接続されている。なお、各エッジルータ１３１、１４１は、スイッチであってもよい。
【００２７】
コア・ネットワーク１５１に１台又は複数台のコア・ノードが含まれる場合、エッジルータ１３１、１４１は、前記コア・ノードに接続されるか、又はエッジルータ同士で接続される。なお、コア・ネットワーク１５１に他の装置が含まれず、エッジルータ１３１とエッジルータ１４１とが互いに接続されていてもよい。
【００２８】
図１に示す例において、エッジルータ１３１のＩＰアドレスは、「１０．１０．１１．１」であり、インタフェース番号が「１」のネットワーク・インタフェース１３２に接続されたリンクを経由して、直接又は他のネットワーク装置を介して、エンドユーザのコンピュータ１０１及びコンピュータ１０２と接続されている。
【００２９】
コンピュータ１０１にはＩＰアドレスとして「１０．１０．２１．１０」が割り当てられ、コンピュータ１０２にはＩＰアドレスとして「１０．１０．２１．１５」が割り当てられている。また、コンピュータ１０１及びコンピュータ１０２は、ＣＰＵ（図示省略）、主記憶装置（図示省略）、二次記憶装置（図示省略）を備えている。
【００３０】
エッジルータ１４１のＩＰアドレスは、「１０．１０．１２．１」であり、インタフェース番号が「１」のネットワーク・インタフェース１４２に接続されたリンクを経由して、直接又は他のネットワーク装置を介して、通信計画サーバ１１１とストリーミング・サーバ１２１とが接続されている。
【００３１】
通信計画サーバ１１１にはＩＰアドレスとして「１０．１０．２２．１１」が割り当てられ、また、通信計画サーバ１１１は通信計画データベース１１２を備える。ストリーミング・サーバ１２１にはＩＰアドレスとして「１０．１０．２２．１２」が割り当てられ、また、ストリーミング・サーバ１２１はコンテンツ１２２を備える。
【００３２】
管理サーバ１５２にはＩＰアドレスとして「１０．１０．２３．３１」が割り当てられ、また、管理サーバ１５２はエッジルータ１３１、１４１又はコア・ネットワーク１５１に含まれる他のネットワーク装置と接続されている。
【００３３】
図２Ａは、本発明の第１の実施形態における通信計画サーバ１１１のハードウェア構成を説明するブロック図である。
【００３４】
通信計画サーバ１１１は、ＣＰＵ２００、主記憶装置２０１、二次記憶装置２０２、及びネットワーク・インタフェース２０３を備える。主記憶装置２０１は、例えばメモリである。二次記憶装置２０２は、例えばＨＤＤである。二次記憶装置２０２上又は外部の装置（図示省略）に通信計画データベースが備えられる。また、通信計画サーバ１１１は、ネットワーク・インタフェース２０３を介してエッジルータ１４１と接続されている。
【００３５】
図２Ｂは、本発明の第１の実施形態におけるストリーミング・サーバ１２１のハードウェア構成を説明するブロック図である。
【００３６】
ストリーミング・サーバ１２１は、ＣＰＵ２１０、主記憶装置２１１、二次記憶装置２１２、及びネットワーク・インタフェース２１３を備える。主記憶装置２１１は、例えばメモリである。二次記憶装置２１２は、例えばＨＤＤである。二次記憶装置２１２上又は外部の装置（図示省略）にコンテンツ１２２が備えられている。また、ストリーミング・サーバ１２１は、ネットワーク・インタフェース２１３を介してエッジルータ１４１と接続されている。
【００３７】
図２Ｃは、本発明の第１の実施形態における管理サーバ１５２のハードウェア構成を説明するブロック図である。
【００３８】
管理サーバ１５２は、ＣＰＵ２２０、主記憶装置２２１、二次記憶装置２２２、及びネットワーク・インタフェース２２３を備える。主記憶装置２２１は、例えばメモリである。二次記憶装置２２２は、例えばＨＤＤである。二次記憶装置２２２上又は外部の装置（図示省略）に帯域管理テーブル１５３が備えられる。また、管理サーバ１５２は、ネットワーク・インタフェース２２３を介して、エッジルータ１３１、１４１又はコア・ネットワーク１５１に含まれる他のネットワーク装置と接続されている。
【００３９】
次に、セッション開始時及びセッション継続中にユーザがアプリケーションに要求を入力するためのグラフィカル・ユーザ・インタフェース（ＧＵＩ）について説明する。
【００４０】
図３Ａは、本発明の第１の実施形態における、コンテンツ選択のためのグラフィカル・ユーザ・インタフェース（ＧＵＩ）を説明する図である。図３Ｂは、本発明の第１の実施形態における、初期品質を選択するためのグラフィカル・ユーザ・インタフェース（ＧＵＩ）を説明する図である。図３Ｃは、本発明の第１の実施形態における、低解像度を選択した場合のグラフィカル・ユーザ・インタフェース（ＧＵＩ）を説明する図である。図３Ｄは、本発明の第１の実施形態における、高解像度を選択した場合のグラフィカル・ユーザ・インタフェース（ＧＵＩ）を説明する図である。図３Ａ〜図３Ｄに示すＧＵＩは、Ｗｅｂによって実現されている。
【００４１】
図３Ａに示すコンテンツ選択画面３０１は、ユーザがコンテンツ選択画面３０１に表示されているコンテンツの中から特定のコンテンツを選択するためのメニュー画面である。コンテンツ選択画面３０１は、Ｗｅｂサイトにおける、ＨＴＭＬページとして実現される。ユーザが、コンテンツ選択画面３０１に表示されているコンテンツを選択すると、図３Ｂに示す初期品質選択画面３１１に遷移する。すなわち、コンテンツ選択画面３０１に表示されているコンテンツの項目は、ハイパー・リンクによって表現されており、いずれかのコンテンツが選択（クリック）されることによって、それぞれ異なるパラメタが指定されて、ＣＧＩ（Ｃｏｍｍｏｎ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ）プログラムが起動される。
【００４２】
初期品質選択画面３１１は、低解像度ボタン３１３、及び高解像度ボタン３１４が表示されている。すなわち、異なるＱｏＥ条件の選択肢が表示されている。なお、画質改善ボタン３１５、及び停止ボタン３１６は、初期品質設定においては、ユーザが選択できないようになっている。例えば、ボタン操作の無効又は表示しない等が考えられる。ユーザは、低解像度ボタン３１３、又は高解像度ボタン３１４のいずれかを選択（クリック）することができる。ユーザがどちらのボタンを選択するかは、当該選択によって、課金に差がでること、また、コンピュータ１０１の画面の解像度、若しくは処理性能によって、どちらがそのユーザにとって最適であるかに依存する。
【００４３】
ユーザが低解像度ボタン３１３を選択した場合、低解像度再生画面３２１が表示され、また、ユーザが高解像度ボタン３１４を選択した場合、高解像度再生画面３３１が表示される。すなわち、どちらのボタンを操作するかによって、異なるパラメタが指定されて、ＣＧＩプログラムが起動される。
【００４４】
図３Ｃに示す低解像度再生画面３２１における再生画面３２２は低解像度による動画再生画面であり、再生画面３２２はＷｅｂのプラグインとして実現される。再生画面３２２は、ストリーミング・サーバ１２１から送信される動画データを受信して再生される動画を表示する。低解像度再生画面３２１において、低解像度ボタン３１３はすでに選択されているため無効化されている。つまり、ユーザは、低解像度ボタン３１３を操作（クリック）できない。
【００４５】
ユーザは、低画質度で動画が再生されている途中に、高解像度ボタン３１４を操作（クリック）することによって、高解像度再生画面３３１に移行することができる。また、ユーザは、低解像度再生画面３２１に表示されている画質改善ボタン３１５を操作（クリック）することによって、再生されている画質を改善することができる。また、ユーザは、停止ボタン３１６を操作（クリック）することによって、動画の再生を停止することができる。
【００４６】
図３Ｄに示す高解像度再生画面３３１おける再生画面３３２は高解像度による動画再生画面であり、再生画面３３２はＷｅｂのプラグインとして実現される。再生画面３３２は、ストリーミング・サーバ１２１から送信される動画データを受信して再生される動画を表示する。高解像度再生画面３３１において、高解像度ボタン３１４はすでに選択されているため無効化されている。つまり、ユーザは、低解像度ボタン３１３を操作（クリック）できない。
【００４７】
ユーザは、高画質度で動画が再生されている途中に、低解像度ボタン３１３を操作（クリック）することによって、低解像度再生画面３２１に移行することができる。また、ユーザは、高解像度再生画面３３１に表示されている画質改善ボタン３１５を操作（クリック）することによって、再生されている画質を改善することができる。また、ユーザは、停止ボタン３１６を操作（クリック）することによって、動画の再生を停止することができる。
【００４８】
ＱｏＥ条件としては、解像度のほかにスタートアップ時間を指定することも可能である。例えば、課金が大きく、かつ、スタートアップが高速であるＱｏＥ条件を選択するためのボタンと、課金が小さく、かつ、スタートアップが低速であるＱｏＥ条件を選択するためのボタンとを、それぞれの初期品質選択画面３１１、低解像度再生画面３２１、及び高解像度再生画面３３１に表示することができる。
【００４９】
図３Ａ〜図３Ｄにおいて示したグラフィカル・ユーザ・インタフェースにおける操作によって発生する処理については、図４を用いて後述する。
【００５０】
なお、図３Ａ〜図３ＤにおいてＣＧＩを実現するための方法として、ＷｅｂサーバのＣＧＩを使用する場合を示したが、ウィンドウ・システムなど、他の方法を使用することもできる。
【００５１】
図４は、本発明の第１の実施形態において、ユーザがセッション開始時又はセッション継続中に、低解像度ボタン３１３又は高解像度ボタン３１４を操作したときのネットワークシステムにおける処理手順を示すシーケンス図である。
【００５２】
当該処理は、コンピュータ１０１上で動作するＷｅｂブラウザが、ユーザによる品質要求４０１を受信することによって開始される。なお、ユーザによる品質要求４０１は、低解像度ボタン３１３又は高解像度ボタン３１４のいずれかを操作（クリック）することによって発生する。
【００５３】
ユーザによる品質要求４０１を受信したコンピュータ１０１は、通信計画サーバ１１１に品質要求４０２を送信する。品質要求４０２には、ビデオ識別子とＱｏＥ情報とが含まれる。図４に示す例では、ビデオ識別子には、「ｌｉｆｅ ｉｎ ｖｅｎｉｃｅ」（初期品質選択画面３１１の「ベニスに生きる」に対応する）が含まれ、また、ＱｏＥ情報には、解像度として「８００×４５０」と、スタートアップ時間として「０．５秒」とが含まれる。なお、品質要求４０２は、他のＱｏＥ情報を含んでもよい。
【００５４】
品質要求４０２を受信した通信計画サーバ１１１は、図９Ａに示す手順にしたがって処理を実行する。具体的には、管理サーバ１５２に通信計画データベース１１２にアクセスして「ベニスに生きる」の３つの通信計画案（図８参照）を含む品質要求４０３を送信する。
【００５５】
図４に示す例では、通信計画案として、初期帯域、スタートアップ時間、定常帯域及び最大帯域が指定されている。具体的には、次のように指定されている。
通信計画案１：（４０Ｍ、０．５秒、５Ｍ、５Ｍ）
通信計画案２：（２０Ｍ、０．５秒、７Ｍ、７Ｍ）
通信計画案３：（０、０秒、５Ｍ、１０Ｍ）
管理サーバ１５２に送信された３つの通信計画案の詳細については、図６Ａ〜図６Ｃを用いて後述する。
【００５６】
品質要求４０３は、通信計画案の他に、品質要求４０２の送信者のＩＰアドレスと品質要求４０３の受信者のＩＰアドレスとを含む。具体的には、送信者のＩＰアドレスは、コンピュータ１０１のＩＰアドレス「１０．１０．２１．１０」であり、受信者のＩＰアドレスは、品質要求４０２において指定された「ｌｉｆｅ ｉｎ ｖｅｎｉｃｅ」の解像度が「８００×４５０」であるファイルを格納するストリーミング・サーバ１２１のＩＰアドレス「１０．１０．２２．１２」である。
【００５７】
品質要求４０３を受信した管理サーバ１５２は、図１０に示す手順にしたがって処理を実行する。これによって、帯域制限設定４０４、キューイング設定４０５及び品質応答４０６の３つのメッセージが各々送信される。具体的には、帯域制限設定４０４はエッジルータ１４１に送信され、キューイング設定４０５はエッジルータ１３１に送信され、品質応答４０６は管理サーバ１５２に送信される。
【００５８】
品質応答４０６は、エッジルータ１４１がキュー設定を完了した応答を管理サーバ１５２が受信した後に送信されてもよいし、エッジルータ１４１のキュー設定の処理が完了する時間に動画が再生されるようなタイミングで送信されてもよい。
【００５９】
品質応答４０６には、管理サーバ１５２が選択した通信計画案が含まれる。図４に示す例では、品質応答４０６に通信計画案１が含まれる。なお、送信された通信計画案のいずれもが実現可能でない場合、管理サーバ１５２は、通信計画サーバ１１１に品質応答４０６の代わりに拒否応答を送信する。
【００６０】
帯域制限設定４０４には、動画ストリーミングにおけるトラフィック（動画再生４０９）がエッジルータ１４１を通過するときに許容される最大帯域を超えないように制限するための設定が含まれる。
【００６１】
例えば、通信計画案１では最大帯域が「２０Ｍｂｐｓ」と指定され、通信計画案２では最大帯域が「４０Ｍｂｐｓ」と指定され、通信計画案３では最大帯域が「１０Ｍｂｐｓ」と指定されている。ただし、ストリーミング・サーバ１２１からの送信帯域が、指定された最大帯域以下になることが確実であれば、帯域制限設定４０４は不要である。
【００６２】
キューイング設定４０５には、動画再生４０９において、エッジルータ１３１のネットワーク・インタフェース１３２で確保されるべき最低保証帯域を持つキューが使用されるための設定が含まれる。例えば、通信計画案１では最低保証帯域が「５Ｍｂｐｓ」であるキューが選択され、通信計画案２では最低保証帯域が「７Ｍｂｐｓ」であるキューが選択され、通信計画案３では最低保証帯域が「５Ｍｂｐｓ」であるキューが選択される。
【００６３】
品質応答４０６を受信した通信計画サーバ１１１は、図９Ｂに示す手順にしたがってコンピュータ１０１に品質応答４０７を送信する。品質応答４０７には、選択された通信計画案と要求されたコンテンツを格納するストリーミング・サーバ１２１のＩＰアドレスが含まれる。また、品質応答４０７にはストリーミング・サーバ１２１以外の他のサーバ（図示省略）のアドレスが含まれてもよい。なお、送信された通信計画案のいずれもが実現可能でない場合、通信計画サーバ１１１は、コンピュータ１０１に品質応答４０７の代わりに拒否応答を送信する。
【００６４】
品質応答４０７を受信したコンピュータ１０１は、受信した品質応答４０７に含まれる通信計画案にしたがって、再生要求４０８をストリーミング・サーバ１２１に送信する。図４に示す例では、再生要求４０８には通信計画案１が含まれる。
【００６５】
再生要求４０８を受信したストリーミング・サーバ１２１は、受信した再生要求４０８に含まれる通信計画案に基づいて、図１１に示す手順にしたがって動画再生４０９を実行する。
【００６６】
図４に示したシーケンスにおいて、通信計画サーバ１１１は、すべての通信計画案を一度に管理サーバ１５２に送信する。前述の方法は、単純であり通信シーケンスが短いという利点がある。しかし、送信される通信計画案が多数ある場合、通信計画サーバ１１１が送信するデータ量が多くなる。そこで、通信計画サーバ１１１が管理サーバ１５２に通信計画案を送信する方法の５つの代案を以下に示す。なお、以下の説明において、図４における通信計画サーバ１１１が管理サーバ１５２に通信計画案を送信する方法を、原案と記載する。
【００６７】
第１の代案では、通信計画サーバ１１１は、通信計画サーバ１１１が最適なものを選択し、当該選択された通信計画案のみを含む品質要求４０３を管理サーバ１５２に送信する。
【００６８】
管理サーバ１５２は、送信された通信計画案が適切か否かを判定し、適切な通信計画案であると判定された場合、当該通信計画案を含む品質応答４０６又は、ＯＫメッセージを通信計画サーバ１１１に送信し、不適切な通信計画案であると判定された場合、品質応答４０６の代わりに拒否応答を通信計画サーバ１１１に送信する。
【００６９】
通信計画サーバ１１１は、管理サーバ１５２が通信計画案を受理する（通信計画サーバ１１１が品質応答４０６又は、ＯＫメッセージを受信する）まで代わりの通信計画案を送信し続ける。通信計画サーバ１１１は、送信する通信計画案が無い場合、品質応答４０７の代わりに拒否応答をコンピュータ１０１に送信する。
【００７０】
つまり、第１の代案は、通信計画サーバ１１１と管理サーバ１５２との間の交渉によって通信計画案が選択される。第１の代案は、平均の通信量が原案より減少するという利点がある。
【００７１】
第２の代案では、通信計画サーバ１１１は、パラメタが付与された１つの通信計画案を管理サーバ１５２に送信し、管理サーバ１５２は、付与されたパラメタの最適値を算出して通信計画サーバ１１１に送信する。
【００７２】
パラメタが付与された通信計画案としては、例えば、前記通信計画案１及び２をまとめて、（１０×（２＋α）、０．５秒、５＋αＭ、５＋αＭ）（α＝０、２）とすることが考えられる。ここで、αがパラメタである。より多くの通信計画案をまとめることができれば、送信データ量を減らすことができる。なお、当該パラメタ及び、パラメタが付与された通信計画案は、通信計画サーバ１１１によって決定されている。
【００７３】
つまり、第２の代案は、通信シーケンスは原案と同様に短く、かつ送信するデータ量も少ないという利点がある。
【００７４】
第３の代案では、図５に示すようなシーケンスにしたがって処理が実行される。
【００７５】
図５は、本発明の第１の実施形態において、ユーザがセッション開始時又はセッション継続中に、低解像度ボタン３１３又は高解像度ボタン３１４を操作したときのネットワークシステムにおける処理手順の変形例示すシーケンス図である。以下、図４との差異を中心に説明する。
【００７６】
図５に示すシーケンスでは、品質要求４０２、品質要求４０３、品質応答４０６、及び品質応答４０７の代わりに品質要求５０１、品質要求５０２、品質応答５０３、及び品質応答５０４が用いられる。他の処理手順は図４と同一である。
【００７７】
図５に示すシーケンスにおいて、コンピュータ１０１と通信計画サーバ１１１との間の通信にＳＩＰが使用される。ＮＧＮのＩＭＳでは資源確保のためにＳＩＰが使用されるが、図５に示すシーケンスはそれを拡張したものである。すなわち、ストリーミングのセッション開始時にＲＴＳＰによるセッション制御（再生要求４０９）の前にＳＩＰによるセッション制御が実行される。品質要求５０１は、ＳＩＰのＩＮＶＩＴＥメッセージであり、通信相手はセッション制御サーバである通信計画サーバ１１１である。
【００７８】
品質要求５０１は、拡張されたＳＤＰメッセージが含まれる。されに、拡張されたＳＤＰメッセージにはビデオ識別子、解像度、及びスタートアップ時間が含まれる。品質要求５０１は、ＳＩＰサーバである管理サーバ１５２を経由して通信計画サーバ１１１に到達する。具体的には、管理サーバ１５２は、受信した品質要求５０１を品質要求５０２として、通信計画サーバ１１１に転送する。
【００７９】
通信計画サーバ１１１から送信される品質応答５０３は、ＳＩＰのＯＫ応答であり、さらに、複数の通信計画案が含まれる。管理サーバ１５２は、品質応答５０３に含まれる複数の計画案を参照し、最適な通信計画案を選択し、選択された通信計画案を含む品質応答５０４をＳＩＰクライアントであるコンピュータ１０１に転送する。品質応答５０４は、通信計画案を１つのみ含む点が品質応答５０３と異なる。
【００８０】
第４の代案では、図５に示すシーケンスにおいて、第１の代案と同様に、品質応答５０３には通信計画サーバ１１１が最適のものとして選択した通信計画案が含まれる。管理サーバ１５２は、当該通信計画案を拒否する場合、品質応答５０４としてＯＫメッセージの代わりにＳＩＰの失敗応答をコンピュータ１０１に送信する。つまり、ｏｆｆｅｒ／ａｎｓｗｅｒモデルにしたがってコンピュータ１０１と通信計画サーバ１１１との間で通信計画案をやりとりすることによって、間接的に管理サーバ１５２と通信計画サーバ１１１との間で交渉することができる。
【００８１】
第５の代案においては、図５に示すシーケンスにおいて、第２の代案と同様に、品質応答５０３にパラメタつきの通信計画案が含まれる。管理サーバ１５２は、最適なパラメタ値を決定し、決定されたパラメタを品質応答５０４に含めるよって、コンピュータ１０１が決定されたパラメタ値によって指定された通信計画案を受け取ることができる。
【００８２】
以上が、通信計画サーバ１１１が管理サーバ１５２に通信計画案を送信する方法の代案の説明である。
【００８３】
なお，図４に示すシーケンスにおいて、品質要求４０２及び品質要求４０３が送信された後、当該品質要求４０２及び品質要求４０３を取り消す要求メッセージを送信しない限り、その効果が継続する。具体的には、帯域制限設定４０４及びキューイング設定４０５によるエッジルータ１３１、１４１の設定が解除されない。したがって、エッジルータ１３１、１４１の設定を解除のための要求メッセージが送信されないと、エッジルータ１３１、１４１の資源が解放されないという問題がある。
【００８４】
前述した問題を解決するに、品質要求４０２及び品質要求４０３にタイムアウト時間を含める方法が考えられる。例えば、品質要求４０２がタイムアウト時間として「６０分」を含む場合、品質要求４０３にもタイムアウト時間が含まれ、管理サーバ１５２が時間を計測し、６０分に達したときに帯域制限設定４０４およびキューイング設定４０５によるエッジルータ１３１、１４１の設定を無効化するように設定する。
【００８５】
また、タイムアウト時間が経過する前に、品質要求４０２と同一の内容の要求メッセージがコンピュータ１０１から通信計画サーバ１１１に送信された場合、タイマーはリセットされ、タイムアウトの時間が延長される。したがって、ユーザがボタンを操作（クリック）することによって、ユーザによる品質要求４０１が発行された後、指定されているタイムアウト時間が経過する前にユーザが同一のボタンを、再度操作（クリック）した場合、品質要求４０２と同一の内容の要求が発行されて、タイムアウトの時間が延長される。これによって、図１２に示す処理を必要としない。
【００８６】
図６Ａは、本発明の第１の実施形態における通信計画案１を説明する図である。図６Ｂは、本発明の第１の実施形態における通信計画案２を説明する図である。図６Ｃは、本発明の第１の実施形態における通信計画案３を説明する図である。
【００８７】
通信計画案１は、最初の０．５秒間だけ２０Ｍｂｐｓでデータを送信し、それ以降は７Ｍｂｐｓの一定レート（ＣＢＲ（Ｃｏｎｓｔａｎｔ Ｂｉｔ Ｒａｔｅ））でデータを送信する計画である。ただし、実際には、７Ｍｂｐｓよりレートが低くなる場合がある。
【００８８】
通信計画案２は、最初の０．５秒間だけ４０Ｍｂｐｓでデータを送信し、それ以降は５Ｍｂｐｓの一定レートでデータを送信する計画である。
【００８９】
通信計画案１と比較して通信計画案２における一定レートが低いのは、本実施形態において、通信計画案１では受信側アプリケーションのジッター・バッファを１０Ｍｂｉｔ（１．２５ＭＢ）と仮定しているのに対して、通信計画案２では受信側アプリケーションのジッター・バッファを２０Ｍｂｉｔ（２．５ＭＢ）と仮定しているため、実際のレートをならすことができるからである。すなわち、通信計画案２では、再生される予定の動画の動きが速くなるなどして再生レートが増加するときに、予め多くのデータを送信しておくことができるため、通信計画案１より一定レートを低くすることができる。
【００９０】
通信計画案３は、通信計画案１、２とは異なり、最初から５Ｍｂｐｓの一定レートでデータを送信し、また、１０Ｍｂｐｓまでのレートでデータが送信されることを許容している。すなわち、通信計画案３は、ＶＢＲ（Ｖａｒｉａｂｌｅ Ｂｉｔ Ｒａｔｅ）で送信する計画である。
【００９１】
通信計画案１、２において、最初の０．５秒間以外の部分では、それぞれ７Ｍｂｐｓ又は５Ｍｂｐｓの最低帯域が保証されることによって、遅延及びパケット損失を防ぐことができる。
【００９２】
通信計画案３において、１０Ｍｂｐｓの最低帯域が保証されることによって、遅延及びパケット損失を防ぐことができるが、それではネットワーク・トラフィックが実際には少ないにもかかわらず新規の要求を受け付けることができない、すなわち、ネットワークのアドミッション制御機能によって再生が拒否される事態が発生する。そのため、最低帯域は１０Ｍｂｐｓより低くする、すなわち、いわゆるオーバーブッキングを認めるスケジューリングを前提とする。
【００９３】
図７は、本発明の第１の実施形態における、スタートアップ時間及びジッター・バッファの量と、定常帯域との関係を説明する図である。
【００９４】
図７におけるグラフ７０１は、受信アプリケーションの時刻と再生済の動画のデータ量との関係を表している。グラフ７０１は、ＶＢＲコーディングを前提としているため、受信アプリケーションの時刻と再生済の動画のデータ量との関係を表すグラフは直線にはならない。
【００９５】
図７におけるグラフ７０２は、通信計画案２における受信アプリケーションの時刻と送信される動画のデータ量との関係を示し、グラフ７０３は、通信計画案１における受信アプリケーションの時刻と送受信される動画のデータ量との関係を示している。通信計画案１、２において、送受信されるデータは、ＣＢＲにしたがって送受信されるので、グラフ７０２、７０３は直線で表される。
【００９６】
グラフ７０２、７０３の直線がグラフ７０１の太線より右側にでるとデータが不足して再生が停止するので、必ずグラフ７０２、７０３の直線がグラフ７０１の太線より左側にあるか、又は接していなければならない。そのため、バッファ・サイズを減少させるとその傾斜を大きくする必要がある。すなわち、定常帯域を増加させる必要が生じる。
【００９７】
図８は、本発明の第１の実施形態の通信計画データベース１１２が格納する内容の一例を示す図である。
【００９８】
通信計画データベース１１２は、ストリーミング・サーバ１２１が格納するすべてのコンテンツに対する通信計画案の原データ８００を格納する。
【００９９】
原データ８００は、ビデオ識別子８０１、サーバ・アドレス８０２、解像度８０３、及び通信計画案８０４を含む。
【０１００】
ビデオ識別子８０１は、動画を識別するための識別子である。サーバ・アドレス８０２は、ビデオ識別子８０１に対応するコンテンツを格納するストリーミング・サーバ１２１のＩＰアドレスを格納する。なお、同一のコンテンツを格納するストリーミング・サーバ１２１が複数ある場合、サーバ・アドレス８０２には、複数のストリーミング・サーバ１２１のＩＰアドレスが格納される。
【０１０１】
解像度８０３は、再生される動画の解像度を示す。つまり、ＱｏＥの条件が格納されている。通信計画案８０４は、最小バッファ量、定常帯域、及び最大帯域の３つ組からなる通信計画案が格納されている。なお、通信計画案８０４に格納されている通信計画案は、条件のよいものから順に並べられた状態で格納されている。例えば、図８に示す例では、左から順に、条件のよい通信計画が格納されている。
【０１０２】
原データ８００には、１つのビデオ識別子８０１に対して、低解像度と高解像度の２つのレコードを含む。図８に示す例では、原データ８００は、レコード８１１〜レコード８１８が含まれる。
【０１０３】
レコード８１４は、「ベニスに生きる」に対応するレコードであり、当該レコードの通信計画案８０４は、図６Ａ〜図６Ｃに示した３つの通信計画案１〜３にそれぞれ対応している。ここで、最小バッファ量は、受信側アプリケーションが持つべきジッター・バッファの量の最小値である。最小バッファ量をスタートアップ時間で割って算出されたものが初期帯域となる。例えば、最小バッファ量が「２０Ｍｂｉｔ」であり、スタートアップ時間を「０．５秒」とすると、ジッター・バッファを０．５秒間で満たすためには、初期帯域を「４０Ｍｂｐｓ」として送信する必要がある。したがって、スタートアップ時間が「０．５秒」のとき、レコード８１４の通信計画案８０４に含まれる（２０Ｍ、５Ｍ、５Ｍ）から（４０Ｍ、０．５秒、５Ｍ、５Ｍ）という通信計画案２が生成される。
【０１０４】
図９Ａ及び図９Ｂは、本発明の第１の実施形態の通信計画サーバ１１１の処理を説明するフローチャートである。
【０１０５】
図９Ａは、通信計画サーバ１１１が品質要求４０２を受信したときの処理手順９０１を示し、図９Ｂは、通信計画サーバ１１１が品質応答４０６を受信したときの処理手順９０２を示している。以下、各処理手順９０１、９０２について説明する。
【０１０６】
処理手順９０１では、まずステップ９１１において、品質要求４０２を受信した通信計画サーバ１１１は、「Ｌｌｉｆｅ ｉｎ ｖｅｎｉｃｅ」、などのビデオ識別子８０１と解像度８０３を検索キーとして、通信計画データベース１１２から通信計画案８０４のリストとサーバ・アドレス８０２とを読み出す。
【０１０７】
次に、ステップ９１２において、通信計画サーバ１１１は、読み出された通信計画案８０４に含まれる含む最小バッファ量と、品質要求４０２に含まれるスタートアップ時間から初期帯域を算出する。具体的には、最小バッファ量をスタートアップ時間で割って初期帯域が算出される。これによって、通信計画案が生成される。ステップ９１１において、図８のレコード８１４が読み出された場合、通信計画サーバ１１１は、図６Ａ〜図６Ｃに示す通信計画案１〜３を生成する。
【０１０８】
ステップ９１３において、通信計画サーバ１１１は、初期帯域、スタートアップ時間、定常帯域及び最大帯域から構成される通信計画案を含む品質要求４０３を管理サーバ１５２に送信し、処理を終了する。
【０１０９】
処理手順９０２では、ステップ９２１において、品質応答４０６を受信した通信計画サーバ１１１は、品質応答４０７を品質要求元（この場合は、コンピュータ１０１）に送信し、処理を終了する。
【０１１０】
図１０は、本発明の第１の実施形態の管理サーバ１５２の処理を説明するフローチャートである。
【０１１１】
品質要求４０３を受信した管理サーバ１５２は、処理手順１００１にしたがって処理を実行する。ステップ１０１１において、管理サーバ１５２は、品質要求４０３に含まれる通信計画案の中から最適なものを選択する。ここで、品質要求４０３に含まれる通信計画案のリストは、通信計画サーバ１１１が条件のよいものから順に並べたものである。管理サーバ１５２が品質要求４０３に含まれる通信計画案の中から最適なものを選択する方法は、様々のものが考えられる。以下、２つの方法を示す。
【０１１２】
まず、ステップ１０１１において実行される処理の第１の方法を説明する。通信計画案１、２のように最初の０．５秒を除いた通信量が、指定された帯域値を超えないトラフィックによってネットワークが占められている場合、管理サーバ１５２は、通信中のすべてのフローに関する帯域の総和を算出することによって、通信量をほぼ正確に予測することができる。したがって、算出された帯域の総和と通信計画案に含まれる初期帯域との和が、ネットワーク・インタフェース１３２に接続されたリンクの帯域より十分に少ない場合、例えば、該通信計画案の初期帯域の１０倍以上ある場合、該通信計画案が選択される。なお、１０倍以外の数値を用いてもよい。
【０１１３】
例えば、リンクの帯域が１Ｇｂｐｓであり、算出された総和が８００Ｍｂｐｓ以下である場合、初期帯域が「２０Ｍｂｐｓ」である通信計画案１を選択することができる。
【０１１４】
算出された定常帯域の総和がリンクの帯域を超えているときは、管理サーバ１５２は、次善の通信計画案を検討する。いずれの通信計画案も実行不能である場合、管理サーバ１５２は、要求を拒否する。すなわち、アドミッション制御によって動画ストリーミングが拒否される。
【０１１５】
次に、ステップ１０１１において実行される処理の第２の方法を説明する。通信計画案３のように、通信量が定常帯域（通信計画案３の場合は５Ｍｂｐｓ）を超えることがあり、どのタイミングで通信量が定常帯域を超えるかを管理サーバ１５２が予測できないトラフィックが存在する場合、管理サーバ１５２は、通信量の実測値を用いた予測値にしたがって制御する。
【０１１６】
通信量の実測のために、ＩＥＴＦの標準プロトコルであるＩＰＦＩＸ、ＩＰＦＩＸの前身であるＣｉｓｃｏ社開発のプロトコルであるＮｅｔＦｌｏｗ、又はＩｎＭｏｎ社開発のプロトコルであるＳＦｌｏｗを使用することができる。これらのプロトコルによって管理サーバ１５２は、エッジルータ１３１のネットワーク・インタフェース１３２におけるトラフィック量の統計を取得し、取得されたトラフィックの統計に基づいて使用されている帯域を算出することができる。
【０１１７】
管理サーバ１５２は、算出された実測値に基づいて、予測される帯域を求める。すなわち、管理サーバ１５２は、算出された実測値をそのまま予測値とする。当該予測値と通信計画案に含まれる最大帯域との和が、ネットワーク・インタフェース１３２に接続されたリンクの帯域より十分に少ない場合、例えば、該予測値がある通信計画案の初期帯域の２０倍以上ある場合、該通信計画案を選択する。なお、２０倍以外の数値を用いてもよい。
【０１１８】
例えば、リンクの帯域が１Ｇｂｐｓであり、算出された総和が６００Ｍｂｐｓ以下であれば、初期帯域が「２０Ｍｂｐｓ」である通信計画案１を選択することができる。
【０１１９】
算出された総和がリンクの帯域を超えているときは、管理サーバ１５２は、次善の通信計画案を検討する。いずれの通信計画案も実行不能である場合、管理サーバ１５２は、要求を拒否する。すなわち、アドミッション制御によって動画ストリーミングが拒否される。
【０１２０】
以下の説明では、ＮｅｔＦｌｏｗを使用してトラフィックが計測されることを前提とする。ＮｅｔＦｌｏｗを使用することによって、ルータ（この場合は、エッジルータ１３１、１４１）は、定期的に（例えば、１分おきに）、該ルータの特定のインタフェース（この場合は、ネットワーク・インタフェース１３２、１４２）におけるトラフィック量をトラフィックの種類ごとに管理サーバ１５２へ通知できる。前述の機能を使用することによって、管理サーバ１５２は、定期的にエッジルータ１３１のネットワーク・インタフェース１３２から出力されるトラフィックの帯域を算出できる。
【０１２１】
時刻ｔにおける、クラスｃに割り当てられた帯域Ｂｕ（ｃ）は、直前の時刻ｔ−１までの収集結果に基づいて、下式によって推定される。ただし、第１の実施形態では、一つのクラス（ストリーミング）に着目するため、以下ではｃを省略する。
（式１）Ｂｕ＝γ（１＋β）Ｂａ＋（１−α）Ｂｒ
予め定数として設定された総帯域Ｂｍ（当該のクラスに割り当てられた帯域)と（式１）によって推定されるＢｕとの差が割り当て可能な帯域であり、それらが新たな要求帯域以下であれば、割り当て可能である。
【０１２２】
（式１）において、Ｂａはトラフィック計測によって取得された帯域を示し、Ｂｒは個々のトラフィックごとの定常帯域又は最大帯域の和を示す。すなわち、スタートアップ時間の経過後、定常帯域を超えないトラフィックに関しては定常帯域が選択され、可変ビットレートにしたがうトラフィックに関しては最大帯域が選択される。
【０１２３】
コア・ネットワーク１５１において、ＤｉｆｆＳｅｒｖによるＱｏＳ制御を行っている場合、ＮｅｔＦｌｏｗからはトラフィック・クラス単位で集約された情報を取得されるが、取得された値は、下式によって指数的移動平均を算出することによって、平滑化している。
（式２）Ｂａ（ｔ）＝αｂａ（ｔ）＋（１−α）Ｂａ（ｔ−１）
ここで、ｂａは、ＮｅｔＦｌｏｗから取得された帯域の値である。このアドミッション制御法においては、調節されたα、β、及びγの３つのパラメタを使用する必要がある。ここで、パラメタは、以下のとおりである。
【０１２４】
αは、計測値平滑化係数と呼ばれ、トラフィック計測値の移動平均のなめらかさを制御するパラメタである。βは、帯域余裕率と呼ばれ、トラフィック計測値 (移動平均) に対するアドミッション制御の限界値のマージンを制御するパラメタである。γは、計測値寄与率と呼ばれ、アドミッション制御の限界値に関する測定値の寄与率（（１−γ）が宣言値の寄与率）である。
【０１２５】
（式１）によって、管理サーバ１５２は、ユーザ又はアプリケーションの要求に基づく帯域とトラフィック計測から算出した帯域との両方を考慮したアドミッション制御を行うことができる。その結果、ユーザ又はアプリケーションの要求に基づく帯域だけによって行われるアドミッション制御に比べると、定常帯域を超えるトラフィックが多くなっている場合、新規のセッションの開始が抑制され、既存のセッションのパケット損失及び遅延増加が抑制されるので、指定されたＱｏＥをより高い確率で実現することが可能になる。
【０１２６】
また、トラフィック計測から算出された帯域だけに基づいて行われるアドミッション制御に比べると、定常帯域を超えるトラフィックの数が増加したり、定常帯域からより大きくはずれるトラフィックが急に出現したりしても、予め最大帯域を加味してアドミッション制御が行われているために、既存のセッションのパケット損失及び遅延増加が発生する確率が低く抑えられる。以上がステップ１０１１において実行される処理の説明である。
【０１２７】
処理手順１００１の説明に戻る。
【０１２８】
ステップ１０１２において、管理サーバ１５２は、ステップ１０１１で選択された通信計画案における初期帯域を最大帯域としてストリーミング・サーバ１２１側のルータ、すなわち、エッジルータ１４１のネットワーク・インタフェース１４２に設定する。具体的には、管理サーバ１５２が、エッジルータ１４１に帯域制限設定４０４を送信する。図４に示す例において、管理サーバ１５２が通信計画２を選択している場合、送信者が「１０．１０．２２．１２」であり、受信者が「１０．１０．２１．１０」であるフローに対して、「４０Ｍｂｐｓ」の帯域制限がエッジルータ１４１に設定される。
【０１２９】
ステップ１０１３において、管理サーバ１５２は、ステップ１０１１で選択された通信計画案における定常帯域を最低保証帯域とするキューを、ユーザ側のルータ、すなわち、エッジルータ１３１のネットワーク・インタフェース１３２において、動画再生４０９における動画ストリーミング・トラフィックが、選択されたキューにはいるようにする。前述の操作を実現するため、具体的には次の手順にしたがう。
【０１３０】
第１に、コア・ネットワーク１５１の初期化時に管理サーバ１５２は、ユーザ側の出口インタフェース（この場合は、ネットワーク・インタフェース１３２）において、キューの初期設定を実行する。例えば、ネットワーク・インタフェース１３２において、必要な最低保証帯域が５Ｍｂｐｓ、７Ｍｂｐｓ、及び１０Ｍｂｐｓの３種類であり、最大３０個のキューを設定することができる場合、管理サーバ１５２は、次のようなキューを初期設定によって確保する。すなわち、管理サーバ１５２は、５Ｍｂｐｓのキューを１０個確保し、７Ｍｂｐｓのキューを１０個確保し、１０Ｍｂｐｓのキューを１０個確保する。確保されたキューは、要求があるまで使用されない。
【０１３１】
第２に、管理サーバは、ステップ１０１３において、選択された通信計画案によって指定された最低保証帯域をもつキューを、初期設定で確保されたキューの中から選択する。例えば、最低保証帯域として「５Ｍｂｐｓ」が指定された場合、初期設定によって確保された５Ｍｂｐｓのキューのひとつが割り当てられる。なお、指定された最低保証帯域に一致するキューが存在しない場合、指定された最低保証帯域より大きい最低保証帯域をもつキューが選択される。
【０１３２】
前述のように、予めキューを確保する代わり、要求時にキューの構成を変更し、新たなキューを割り当てる方法も考えられる。しかし、要求があるたびにキューの構成を変更すると、キューの構成の変更時にキューイングされるべきパケットが廃棄される可能性、又は、再構成のためにエッジルータ１３１に大きな負荷がかかる可能性がある。前述のように、予めキューを確保する方法は、キューの割り当て時にパケットが失われることがなく、またオーバヘッドが小さいという利点がある。
【０１３３】
ステップ１０１４において、管理サーバ１５２は、選択された通信計画案を含む品質応答４０６を通信計画サーバ１１１に送信し、処理を終了する。
【０１３４】
図１１は、本発明の第１の実施形態のストリーミング・サーバ１２１の処理を説明するフローチャートである。
【０１３５】
再生要求４０８を受信したストリーミング・サーバ１２１は、処理手順１１０１にしたがって処理を実行する。
【０１３６】
ステップ１１１１において、再生要求４０８を受信したストリーミング・サーバ１２１は、再生要求４０８に含まれる通信計画案における初期帯域で指定された時間にしたがって、動画のデータを送信する。例えば、再生要求４０８に通信計画案２が含まれている場合、指定された初期帯域は「４０Ｍｂｐｓ」であり、指定されたスタートアップ時間が「０．５秒」であるので、ストリーミング・サーバ１２１は、０．５秒間だけ４０Ｍｂｐｓの通信速度で動画のデータをコンピュータ１０１に送信する。
【０１３７】
ステップ１１１２において、ストリーミング・サーバ１２１は、指定された定常帯域、及び最大帯域にしたがって残りの動画のデータを送信する。指定された定常帯域及び最大帯域がともに「５Ｍｂｐｓ」である場合、ストリーミング・サーバ１２１は、５Ｍｂｐｓを超えない範囲で、かつ受信側アプリケーションのジッター・バッファがあふれないように動画のデータを送信する。
【０１３８】
ストリーミング・サーバ１２１は、各ストリーミング・コンテンツの再生において、再生開始後どの時刻にどれだけのデータを消費するかがわかる（実際に再生してみればわかるが、再生することは必須ではない）ので、受信側アプリケーションのジッター・バッファにバッファリングされたデータ量を推定することができる。ストリーミング・サーバ１２１は、当該推定に基づいて、ジッター・バッファがあふれないように動画のデータの送信を制御する。
【０１３９】
また、受信側アプリケーションにおいて動画が停止したり、再生速度が変化したりすることがある。このような場合、再生要求４０８とその応答に使用されるプロトコル、例えば、ＩＥＴＦ標準のプロトコルＲＴＳＰ（Ｒｅａｌ−Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）を使用するか、又は、動画のデータとその制御のためのプロトコル、例えば、ＩＥＴＦ標準のプロトコルＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）及びＲＴＣＰ（Ｒｅａｌ−Ｔｉｍｅ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）を使用することによって、現在、再生がどこまですすんでいるかをコンピュータ１０１からストリーミング・サーバ１２１に通知され、ストリーミング・サーバ１２１は通知された情報をジッター・バッファの制御のために使用することができる。
【０１４０】
図１２は、本発明の第１の実施形態において、ユーザが停止ボタン３１６を操作（クリック）したときのネットワークシステムにおける処理手順を説明するシーケンス図である。
【０１４１】
停止ボタン３１６が操作（クリック）されることによって発生した、ユーザによる停止要求１２０１は、コンピュータ１０１上で動作するＷｅｂブラウザが受け取る。コンピュータ１０１は、まず、ストリーミング・サーバ１２１に停止要求１２０２を送信して、ストリーミング・サーバ１２１からの動画のデータの送信を停止する。
【０１４２】
コンピュータ１０１は、続いて、品質要求１２０３を通信計画サーバ１１１に送信する。品質要求１２０３には、対応する要求を識別するために必要なビデオ識別子８０１が含まれる。
【０１４３】
品質要求１２０３を受信した通信計画サーバ１１１は、品質要求１２０４を管理サーバ１５２に送信する。品質要求１２０４には、品質要求１２０３の送信者、すなわち、コンピュータ１０１のＩＰアドレス「１０．１０．２１．１０」が含まれる。
【０１４４】
品質要求１２０４を受信した管理サーバ１５２は、品質応答１２０７、帯域制限設定解除１２０５、及びキューイング設定解除１２０６の３つのメッセージをそれぞれ送信する。具体的には、品質応答１２０７は、通信計画サーバ１１１に送信され、帯域制限設定解除１２０５は、エッジルータ１４１に送信され、キューイング設定解除１２０６は、エッジルータ１３１に送信される。また、帯域制限設定解除１２０５によって帯域制限設定４０４における設定が無効にされ、キューイング設定解除１２０６によってキューイング設定４０５における設定が無効にされる。
【０１４５】
品質応答１２０７を受信した通信計画サーバ１１１は、コンピュータ１０１に品質応答１２０８を送信する。なお、品質要求４０２及び品質要求４０３にタイムアウト時間が含まれる場合は、帯域制限設定解除１２０５及びキューイング設定解除１２０６は送信されない。
【０１４６】
次に、再生中に高解像度ボタン３１４又は低解像度ボタン３１３を操作（クリック）することによって生じる処理について説明する。
【０１４７】
再生中に高解像度ボタン３１４又は低解像度ボタン３１３が操作（クリック）された場合、コンピュータ１０１は、まず、再生中の動画を停止させる。前述の処理の手順は図１２に示すシーケンス図とほぼ同一であるが、停止要求１２０２の代わりに一時停止要求が送信される。
【０１４８】
一時停止要求を受信したストリーミング・サーバ１２１は、動画の再生を開始してから停止まで経過時刻を記憶し、解像度の異なる動画の再生を開始する。動画を再生する場合のシーケンスは、図４と同様であるが、再生要求４０８の代わりに再開要求が送信される。再開要求を受信したストリーミング・サーバ１２１は、記憶されている動画の再生を開始してから停止までの経過時刻に基づいて、一時停止されたところから動画の再生を開始する。これによって、ちょうど再生を停止したところから、解像度が異なる動画が再生される。
【０１４９】
なお、画質改善ボタン３１５が操作（クリック）された場合の処理は、図４と同様のシーケンスにしたがって処理が実行される。ただし、ユーザによる品質要求４０１は画質改善要求であり、また、品質要求４０２は解像度及びスタートアップ時間の代わりに「画質改善」を表す内容が含まれる。また、品質要求４０３において、すでに選択されていた通信計画案がＶＢＲによる計画であれば、ＣＢＲによる計画に変更する。管理サーバ１５２は、キューイング設定４０５において、品質改善要求による新たな通信計画案に適したキューを選択する。
【０１５０】
また、本実施形態において、最低保証帯域が確保できない場合、動画の再生は拒否され、再生することができない。ネットワークが輻輳していて、予め再生できないことが分かる場合、高解像度ボタン３１４を無効化、すなわち、操作（クリック）できないようにすることによって、ユーザが無駄な操作をしないようにすることができる（初期品質選択画面３１１においては、画質改善ボタン３１５と停止ボタン３１６とが無効化されている）。
【０１５１】
具体的には、初期品質選択画面３１１及び低解像度再生画面３２１を生成するときに、これらのＷｅｂページを通信計画サーバ１１１がＣＧＩによって生成するようにし、通信計画サーバ１１１が管理サーバ１５２に予め通信計画案の実現可否を問い合わせることによって、実現できないメニュー項目（ボタン）を無効化できる。なお、管理サーバ１５２は、予めトラフィックを計測し、計測結果に基づいて通信計画サーバ１１１に通信計画案の実現可否を応答することができる。
【０１５２】
さらに、初期品質選択画面３１１、低解像度再生画面３２１、及び高解像度再生画面３３１が表示された後に、ネットワークの状態が変化して、各画面３１１、３２１、３３１が表示されたときには実現可能だったメニュー項目が実現不可能になったり、逆に各画面３１１、３２１、３３１が表示されたときには実現不可能だったメニュー項目が実現可能になったりすることがある。
【０１５３】
前述のような場合に対処するには、表示された画面３１１、３２１、３３１を定期的にリフレッシュする、すなわち、その時点におけるメニュー項目の実現の可否を管理サーバ１５２に問い合わせ、これによって表示を更新することができる。以上が本発明の第１の実施形態の説明である。
【０１５４】
以下、本発明の第２の実施形態について説明する。
【０１５５】
図１３は、本発明の第２の実施形態における、ネットワークシステム構成を示すブロック図である。以下、第１の実施形態との差異を中心に説明する。
【０１５６】
図１との相違点は、ネットワーク上でコンピュータ１０１、１０２とエッジルータ１３１との間を接続するＨＧＷ（ホーム・ゲートウェイ）１３０１が備えられ、また、通信計画サーバ１１１がない代わりに、ＨＧＷ１３０１には計測制御サーバ１３０２が含まれる。その他の構成については図１と同一である。
【０１５７】
図１４Ａ及び図１４Ｂは、本発明の第２の実施形態における、ネットワークへの品質要求を入力するためのグラフィカル・ユーザ・インタフェース（ＧＵＩ）を説明する図である。図１４Ａ及び図１４Ｂに示す例では、特定のアプリケーションに限定していない場合における品質要求を入力するためのＧＵＩである。
【０１５８】
図１４Ａに示す品質メニュー１４０１には、品質改善ボタン１４０２、及びキャンセル・ボタン１４０３が表示されている。使用中の任意のアプリケーションにおいて、品質の改善を希望する場合、ユーザは品質改善ボタン１４０２を操作（クリック）する。また、すでに要求された品質改善をキャンセルしたい場合、ユーザは、キャンセル・ボタン１４０３を操作（クリック）する。
【０１５９】
図１４Ｂに示す品質メニュー１４１１には音質改善ボタン１４１２、画質改善ボタン１４１３、Ｗｅｂ高速化ボタン１４１４、及びキャンセル・ボタン１４１５が表示されている。具体的には、再生中の任意のアプリケーションにおいて、音質の改善を希望する場合、ユーザは音質改善ボタン１４１２を操作（クリック）する。また、再生中の任意のアプリケーションにおいて、画質の改善を希望する場合、ユーザは画質改善ボタン１４１３を操作（クリック）する。また、ユーザがＷｅｂブラウザ又はＷｅｂサービスを使用し、これらの応答の改善を希望する場合、ユーザはＷｅｂ高速化ボタン１４１４を操作（クリック）する。また、すでに要求された品質改善をキャンセルしたい場合、ユーザは、キャンセル・ボタン１４１５を操作（クリック）する。
【０１６０】
本実施形態では、コア・ネットワーク１５１におけるＱｏＳ保証のためにＤｉｆｆＳｅｒｖを使用していることを前提とする。コア・ネットワーク１５１におけるトラフィックは、会話クラス、ストリーミング・クラス、Ｗｅｂクラス、及びベストエフォート・クラスにクラス分けされ、クラスごとにエッジルータ１３１、１４１のキューなどの資源が割り当てられる。
【０１６１】
例えば、エッジルータ１３１のネットワーク・インタフェース１３２において、会話クラスに高優先度キューが割り当てられ、他のトラフィックには複数の低優先度キュー同士で帯域が分割される。すなわち、いわゆるＬＬＱ（Ｌｏｗ Ｌａｔｅｎｃｙ Ｑｕｅｕｅｉｎｇ）が適用される。
【０１６２】
これによって、ストリーミング・クラス、Ｗｅｂクラス、及びベストエフォート・クラスには、それぞれ最低保証帯域が設定される。また、会話クラスが他のクラスを圧迫することがないように、会話クラスのトラフィックに対しては最大帯域が決定され、最大帯域を超えないようにアドミッション制御が行われる。なお、会話クラスのように優先的な処理を必要とするトラフィックが存在しない場合、ＬＬＱの代わりのＷＦＱだけからなるスケジューリングを指定すればよい。
【０１６３】
図１５は、本発明の第２の実施形態において、ユーザが任意のアプリケーションの使用中に、品質改善ボタン１４０２、音質改善ボタン１４１２、画質改善ボタン１４１３、Ｗｅｂ高速化ボタン１４１４、又はキャンセル・ボタン１４１５を操作したときのネットワークシステムにおける処理手順を示すシーケンス図である。
【０１６４】
ユーザによる品質要求１５０１は、各ボタン（品質改善ボタン１４０２、音質改善ボタン１４１２、画質改善ボタン１４１３、Ｗｅｂ高速化ボタン１４１４、及びキャンセル・ボタン１４１５）のいずれかを操作（クリック）することによって発生し、そのイベントをコンピュータ１０１上で動作するＷｅｂブラウザが受信する。
【０１６５】
ユーザによる品質要求１５０１を受信したコンピュータ１０１は、計測制御サーバ１３０２に品質要求１５０２を送信する。品質要求１５０２には、操作（クリック）されたボタンに対応するメディアの種類とＱｏＥ情報とが含まれる。
【０１６６】
品質要求１５０２に含まれるメディアの種類は、品質改善ボタン１４０２が操作（クリック）された場合、不明であることを示す値が含まれるか、又はメディアの種類が省略される。また、音質改善ボタン１４１２が操作（クリック）された場合、メディアの種類は「音声」である。画質改善ボタン１４１３が操作（クリック）された場合、メディアの種類は「動画」である。「画質」は、静止画を示す可能性もあるが、ここでは動画サービスを行っていることを前提とし、動画の画質であることを仮定する。Ｗｅｂ高速化ボタン１４１４が操作（クリック）された場合、メディアの種類は「Ｗｅｂ」である。
【０１６７】
品質改善ボタン１４０２、音質改善ボタン１４１２、又は画質改善ボタン１４１３が操作（クリック）された場合、品質要求１５０２に含まれるＱｏＥ情報は、「高品質」である。Ｗｅｂ高速化ボタン１４１４が操作（クリック）された場合、品質要求１５０２に含まれるＱｏＥ情報は、「高速応答」である。
【０１６８】
品質要求１５０２を受信した計測制御サーバ１３０２は、図１６に示す手順にしたがって処理を実行する。つまり、計測制御サーバ１３０２は、品質要求１５０２に含まれる内容に基づいて、品質要求１５０３を生成し、生成された品質要求１５０３を管理サーバ１５２に送信する。
【０１６９】
具体的には、計測制御サーバ１３０２は、ＨＧＷ１３０１が計測したトラフィック計測情報を用い、品質要求１５０２に含まれるメディアの種類から、対応するＤｉｆｆＳｅｒｖのトラフィック・クラスを特定し、特定されたトラフィック・クラスを品質要求１５０３に含める。また、品質要求１５０２に含まれるＱｏＥ情報とＨＧＷ１３０１が計測したトラフィック計測情報とに基づいて保証するべき帯域を算出し、算出された帯域を品質要求１５０３に含める。さらに、計測制御サーバ１３０２は、品質要求１５０２の送信者、すなわち、コンピュータ１０１のＩＰアドレス「１０．１０．２１．１０」も品質要求１５０３に含める。
【０１７０】
品質要求１５０３を受信した管理サーバ１５２は、図１７に示す手順にしたがって処理をする。具体的には、管理サーバ１５２は、エッジルータ１３１にキューイング設定１５０４を送信し、また、計測制御サーバ１３０２に品質応答１５０５を送信する。品質応答１５０５には、確保された帯域の値が含まれる。キューイング設定１５０４には、エッジルータ１３１においてキューを設定するための情報が含まれる。
【０１７１】
キューイング設定１５０４によって、コンピュータ１０１へ送信され、キューイング設定１５０４において指定されたクラスのトラフィックに関して、キューイング設定１５０４において指定された帯域を最低保証帯域として持つキューが使用されるように、エッジルータ１３１のネットワーク・インタフェース１３２が設定される。
【０１７２】
これによって、ユーザが音質改善を要求した場合、その時点で使用していた会話音声又はストリーミング音声に対して帯域が確保されることによって、音質が改善される。また、ユーザが画質改善を要求した場合、その時点で使用していた会話動画又はストリーミング動画に対して帯域が確保されることによって画質が改善される。
【０１７３】
また、ユーザがＷｅｂ高速化を要求した場合、Ｗｅｂトラフィックに対して帯域が確保されることによって、応答速度が改善される。
【０１７４】
品質応答１５０５を受信した計測制御サーバ１３０２は、コンピュータ１０１に品質応答１５０６を送信する。品質応答１５０６には、品質応答１５０５と同様に、確保された帯域の値が含まれる。
【０１７５】
次に、ＨＧＷ１３０１が実行するトラフィック計測について説明する。
【０１７６】
ＨＧＷ１３０１は、ＨＧＷ１３０１を通過するパケットを監視し、通過するパケットがＵＤＰパケットであれば、さらにＲＴＰパケットであるか否かを判定する。
【０１７７】
ＲＴＰパケットであると判定された場合、ＨＧＷ１３０１は、さらに、該パケットが、ＩＥＴＦ標準若しくはデファクト標準における音声コーデックを使用しているか、又は動画コーデックを使用しているかを判定し、音声コーデックを使用していると判定されたパケットを音声パケット分類し、動画コーデックを使用していると判定されたパケットを動画パケットに分類する。
【０１７８】
また、ＨＧＷ１３０１は、ＴＣＰパケットに関してはＨＴＴＰパケットであるか否かを判定し、ＨＴＴＰパケットと判定されたパケットをＷｅｂパケットに分類する。音声パケット、動画パケット、又はＷｅｂパケットのいずれでもないパケットは、それ以外のパケットに分類される。ＨＧＷ１３０１は、トラフィック計測によって、前述のような４種類のパケットに分類する。
【０１７９】
ＨＧＷ１３０１は、前述の各種類のパケットについて、さらに、ＩＰパケットに含まれルＤＳＣＰ（ＤｉｆｆＳｅｒｖ Ｃｏｄｅ Ｐｏｉｎｔ）ごとに、エッジルータ１３１からコンピュータ１０１に向かうパケットのデータ量をカウントし、トラフィック量を計測する。
【０１８０】
会話に関してはＤｉｆｆＳｅｒｖのＥＦＰＨＢ（ＥｘｐｅｄｉｔｅｄＦｏｒｗａｒｄｉｎｇＰｅｒ−Ｈｏｐ−Ｂｅｈａｖｉｏｒ）を使用し、ストリーミングに関してはＡＦ３ＰＨＢ（ＡｓｓｕｒｅｄＦｏｒｗａｒｄｉｎｇ３Ｐｅｒ−Ｈｏｐ−Ｂｅｈａｖｉｏｒ）を使用していると仮定する。すなわち、会話とストリーミングとをＤＳＣＰによって区別することができる。
【０１８１】
これによって、音声、動画、Ｗｅｂ及びその他のトラフィックのＨＧＷ１３０１におけるトラフィックの種類ごとの使用帯域を算出できる。ＨＧＷ１３０１において、パケット損失が発生していなければ、算出された使用帯域はネットワーク・インタフェース１３２における使用帯域と等しい。
【０１８２】
以上の説明したトラフィック計測法では、ＨＧＷ１３０１がトラフィックを計測することを前提としていたが、トラフィック計測をエッジルータ１３１が行うことも可能である。すなわち、計測制御サーバ１３０２は、エッジルータ１３１からＩＰＦＩＸ、ＮｅｔＦｌｏｗ、又はＳＦｌｏｗなどのプロトコルを使用してネットワーク・インタフェース１３２におけるトラフィック計測情報を受信し、受信したトラフィック計測情報に基づいて、ネットワーク・インタフェース１３２における出力トラフィックの帯域をトラフィックの種類ごとに算出する。
【０１８３】
ただし、ルータは、基本的にはＩＰ層において動作するので、ＲＴＰパケットの解析機能を備えていないことが多い。そのため、ルータは、会話かストリーミングか否かはＤＳＣＰによって区別することができるが、前述の方法では、音声か動画かを区別することができない。したがって、パケット・サイズから音声か動画かを推定する（音声パケットは比較的小さく、数１００バイト以下、プロトコルによってはほとんど１００バイト以下である）などの方法をとる必要がある。
【０１８４】
このように、エッジルータ１３１がトラフィック計測を行う場合、ＨＧＷ１３０１は、必ずしも必要ない。計測制御サーバ１３０２は、ＨＧＷ１３０１から独立に存在することも可能であり、例えば、管理サーバ１５２に含めることも可能である。計測制御サーバ１３０２が管理サーバ１５２に含まれる場合、品質要求１５０３及び品質応答１５０５は、プログラム内の関数呼び出しと、そこからの復帰によって実現することができる。
【０１８５】
図１６Ａ及び図１６Ｂは、本発明の第２の実施形態の計測制御サーバ１３０２の処理を説明するフローチャートである。
【０１８６】
図１６Ａは、品質要求１５０２を受信したときの処理手順１６０１を示し、図１６Ｂは、品質応答１５０６を受信したときの処理手順１６２１を示している。以下、処理手順１６０１、１６２１について説明する。
【０１８７】
処理手順１６０１では、まずステップ１６１１において、計測制御サーバ１３０２は、品質要求１５０２に含まれるメディアの種類からトラフィック・クラスの候補を求める。例えば、メディアの種類が「音声」又は「動画」である場合、トラフィック・クラスは、会話又はストリーミングである。
【０１８８】
ステップ１６１２において、計測制御サーバ１３０２は、メディアの種類とトラフィック・クラス候補とのすべての組について、トラフィック計測結果を求める。
【０１８９】
ステップ１６１３において、計測制御サーバ１３０２は、トラフィック計測結果に基づいて、品質劣化があるトラフィック・クラスを特定する。
【０１９０】
具体的には、メディアの種類が「音声」の場合、次のように判定される。計測制御サーバ１３０２は、音声と動画とをあわせた会話のトラフィックが、該トラフィックに対して割り当てられている帯域と比べて余裕があるか、又は、割り当て帯域が逼迫しているかを判定する。また、計測制御サーバ１３０２は、音声と動画とをあわせたストリーミングのトラフィックが、該トラフィックに対して割り当てられている帯域と比べて余裕があるか、又は、割り当て帯域が逼迫しているかを判定する。
【０１９１】
会話のトラフィックのほうがもっとも輻輳している場合、計測制御サーバ１３０２は、会話音声が品質劣化のあるトラフィック・クラスであると特定する。ストリーミングのトラフィックのほうがもっとも輻輳している場合、計測制御サーバ１３０２は、ストリーミング音声が品質劣化のあるトラフィック・クラスを特定する。
【０１９２】
また、メディアの種類が「動画」の場合においても、会話のトラフィックのほうがもっとも輻輳している場合、計測制御サーバ１３０２は、会話動画が品質劣化のあるトラフィック・クラスであると特定する。ストリーミングのトラフィックのほうがもっとも輻輳している場合、ストリーミング動画が品質劣化のあるトラフィック・クラスであると特定する。
【０１９３】
ここで、複数のクラスのうちのいずれがもっとも輻輳しているかは、次に示す３つの方法のいずれかを用いることによって判定することができる。
【０１９４】
第１の方法は、任意のクラスのすべてのトラフィックが使用する総帯域が、許容されている帯域に対して占める割合が大きいほうを、より輻輳していると判定する。
【０１９５】
第２の方法は、パケット損失を計測することによって、パケット損失が大きいクラスを、より輻輳していると判定する。ＲＴＰのフローのようにパケットがシーケンス番号を含むＵＤＰフローにおいては、パケット損失がある場合、シーケンス番号がとびとびになるため、これによってパケット損失率を求めることができる。
【０１９６】
第３の方法は、遅延を計測することによって、遅延が大きいクラスを、より輻輳していると判定する。ＲＴＰとＲＴＣＰによって構成される音声及び動画のフローのようにパケットにタイムスタンプが含まれる場合、送信側のコンピュータ１０１、すなわち、ストリーミングであれば、ストリーミング・サーバ１２１とＨＧＷ１３０１との時計をＩＥＴＦ標準のプロトコルであるＮＴＰ（Ｎｅｔｗｏｒｋ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）を用いて同期させることによって、遅延を計測することができる。
【０１９７】
ステップ１６１４において、計測制御サーバ１３０２は、品質保証のために必要な帯域を推定する。すなわち、計測制御サーバ１３０２は、品質劣化があると特定されたトラフィック・クラスに関して、現在使用されている帯域の２倍の帯域を保証帯域とする。例えば、品質劣化しているのが動画ストリーミングであり平均で「３Ｍｂｐｓ」の帯域を使用している場合、動画ストリーミングに対して「６Ｍｂｐｓ」を保証帯域として割り当てる。
【０１９８】
ステップ１６１５において、計測制御サーバ１３０２は、管理サーバ１５２に、前述の処理によって決定された内容が含まれる品質要求１５０３を送信し、処理を終了する。
【０１９９】
処理手順１６２１では、ステップ１６２２において、品質応答１５０５を受信した計測制御サーバ１３０２は、品質応答１５０６を品質要求元であるコンピュータ１０１に送信し、処理を終了する。
【０２００】
図１７は、本発明の第２の実施形態の管理サーバ１５２の処理を説明するフローチャートである。管理サーバ１５２は、処理手順１７０１にしたがって処理を実行する。
【０２０１】
ステップ１７０２において、品質要求１５０３を受信した管理サーバ１５２は、ユーザ側ルータ、つまり、エッジルータ１３１にキューイング設定１５０４を送信することによって、エッジルータ１３１の出口に、該キューイング設定１５０４において指定された帯域を最低保証帯域として設定する。
【０２０２】
ステップ１５０３において、管理サーバ１５２は、計測制御サーバ１３０２に品質応答１５０５を送信する。品質要求１５０３において指定された帯域が確保された場合、品質応答１５０５として許可を表すメッセージが計測制御サーバ１３０２に送信され、品質要求１５０３において指定された帯域が確保されない場合、品質応答１５０５として拒否を表すメッセージが計測制御サーバ１３０２に送信される。
【０２０３】
次に、キャンセル・ボタン１４０３、１４１５が操作（クリック）されたときの処理について説明する。キャンセル・ボタン１４０３、１４１５が操作（クリック）された場合における通信シーケンスは図１５と同様である。ただし、ユーザによる品質要求１５０１はキャンセル要求であり、キューイング設定１５０４はキューイング設定を解除する要求である。これによって、ネットワークの設定は、品質改善ボタン１４０２などの要求ボタンが操作（クリック）される前の状態に戻る。
【０２０４】
品質改善ボタン１４０２、音質改善ボタン１４１２、画質改善ボタン１４１３、又はＷｅｂ高速化ボタン１４１４は、各ボタンに対応する品質を改善するために必要なネットワーク資源が確保されないときには効果がない。前述のような場合に、ユーザの無駄な入力を避けるために、次のようにすればよい。
【０２０５】
計測制御サーバ１３０２は、ＣＧＩを使用してコンピュータ１０１に品質メニュー１４０１又は１４１１を表示する。そのときに、計測制御サーバ１３０２は、管理サーバ１５２に、品質メニュー１４０１又は１４１１上に表示された各品質改善のためのボタンを操作（クリック）することによって、品質改善が可能か否かを問い合わせる。管理サーバ１５２から品質の改善が不能であると応答があった場合、計測制御サーバ１３０２は、対応するボタンを無効化する。計測制御サーバ１３０２は、管理サーバ１５２に問い合わせてページをリフレッシュすることによって、最新の状況をコンピュータ１０１に表示することができる。
【０２０６】
また、品質メニュー１４０１又は１４１１に表示された各品質改善のためボタンを操作（クリック）することによって得られた効果は、ユーザに分かりにくいため、品質メニュー１４０１及び１４１１の下部にメッセージ表示欄を設けて、管理サーバ１５２からフィードバックされる結果を計測制御サーバ１３０２が解釈してコンピュータ１０１に表示することができる。管理サーバ１５２からの応答と計測制御サーバ１３０２の処理内容とに応じて、コンピュータ１０１に次のような内容を表示することができる。
【０２０７】
第１に、計測制御サーバ１３０２が品質劣化の原因として会話音声を特定した場合、管理サーバ１５２から許可の応答があれば、前述したメッセージ表示欄に「会話の音質改善に成功しました」と表示される。また、管理サーバ１５２から拒否の応答があれば、前述したメッセージ表示欄に「会話の音質改善に失敗しました」と表示される。
【０２０８】
第２に、計測制御サーバ１３０２が品質劣化の原因としてストリーミング音声を特定した場合、管理サーバ１５２から許可の応答があれば、前述したメッセージ表示欄に「ストリーミングの音質改善に成功しました」と表示される。管理サーバ１５２から拒否の応答があれば、前述したメッセージ表示欄に「ストリーミングの音質改善に失敗しました」と表示される。
【０２０９】
第３に、計測制御サーバ１３０２が品質劣化の原因として会話動画を特定した場合、管理サーバ１５２から許可の応答があれば、前述したメッセージ表示欄に「会話の画質改善に成功しました」と表示される。管理サーバ１５２から拒否の応答があれば、前述したメッセージ表示欄に「会話の画質改善に失敗しました」と表示される。
【０２１０】
第４に、計測制御サーバ１３０２が品質劣化の原因としてストリーミング動画を特定した場合、管理サーバ１５２から許可の応答があれば、前述したメッセージ表示欄に「ストリーミングの画質改善に成功しました」と表示される。管理サーバ１５２から拒否の応答があれば、前述したメッセージ表示欄に「ストリーミングの画質改善に失敗しました」と表示される。
【図面の簡単な説明】
【０２１１】
【図１】本発明の第１の実施の形態における、ネットワークシステム構成を示すブロック図である。
【図２Ａ】本発明の第１の実施形態における通信計画サーバのハードウェア構成を説明するブロック図である。
【図２Ｂ】本発明の第１の実施形態におけるストリーミング・サーバのハードウェア構成を説明するブロック図である。
【図２Ｃ】本発明の第１の実施形態における管理サーバのハードウェア構成を説明するブロック図である。
【図３Ａ】本発明の第１の実施形態における、コンテンツ選択のためのグラフィカル・ユーザ・インタフェース（ＧＵＩ）を説明する図である。
【図３Ｂ】本発明の第１の実施形態における、初期品質を選択するためのグラフィカル・ユーザ・インタフェース（ＧＵＩ）を説明する図である。
【図３Ｃ】本発明の第１の実施形態における、低解像度を選択した場合のグラフィカル・ユーザ・インタフェース（ＧＵＩ）を説明する図である。
【図３Ｄ】本発明の第１の実施形態における、高解像度を選択した場合のグラフィカル・ユーザ・インタフェース（ＧＵＩ）を説明する図である。
【図４】本発明の第１の実施形態において、ユーザがセッション開始時又はセッション継続中に、低解像度ボタン又は高解像度ボタンを操作したときのネットワークシステムにおける処理手順を示すシーケンス図である。
【図５】本発明の第１の実施形態において、ユーザがセッション開始時又はセッション継続中に、低解像度ボタン又は高解像度ボタンを操作したときのネットワークシステムにおける処理手順の変形例示すシーケンス図である。
【図６Ａ】本発明の第１の実施形態における通信計画案１を説明する図である。
【図６Ｂ】本発明の第１の実施形態における通信計画案２を説明する図である。
【図６Ｃ】本発明の第１の実施形態における通信計画案３を説明する図である。
【図７】本発明の第１の実施形態における、スタートアップ時間及びジッター・バッファの量と、定常帯域との関係を説明する図である。
【図８】本発明の第１の実施形態の通信計画データベースが格納する内容の一例を示す図である。
【図９Ａ】本発明の第１の実施形態の通信計画サーバの処理を説明するフローチャートである。
【図９Ｂ】本発明の第１の実施形態の通信計画サーバの処理を説明するフローチャートである。
【図１０】本発明の第１の実施形態の管理サーバの処理を説明するフローチャートである。
【図１１】本発明の第１の実施形態のストリーミング・サーバの処理を説明するフローチャートである。
【図１２】本発明の第１の実施形態において、ユーザが停止ボタンを操作（クリック）したときのネットワークシステムにおける処理手順を説明するシーケンス図である。
【図１３】本発明の第２の実施形態における、ネットワークシステム構成を示すブロック図である。
【図１４Ａ】本発明の第２の実施形態における、ネットワークへの品質要求を入力するためのグラフィカル・ユーザ・インタフェース（ＧＵＩ）を説明する図である。
【図１４Ｂ】本発明の第２の実施形態における、ネットワークへの品質要求を入力するためのグラフィカル・ユーザ・インタフェース（ＧＵＩ）を説明する図である。
【図１５】本発明の第２の実施形態において、ユーザが任意のアプリケーションの使用中に、品質改善ボタン、音質改善ボタン、画質改善ボタン、Ｗｅｂ高速化ボタン、又はキャンセル・ボタンを操作したときのネットワークシステムにおける処理手順を示すシーケンス図である。
【図１６Ａ】本発明の第２の実施形態の計測制御サーバの処理を説明するフローチャートである。
【図１６Ｂ】本発明の第２の実施形態の計測制御サーバの処理を説明するフローチャートである。
【図１７】本発明の第２の実施形態の管理サーバの処理を説明するフローチャートである。
【符号の説明】
【０２１２】
１０１、１０２ コンピュータ
１１１ 通信計画サーバ
１１２ 通信計画データベース
１２１ ストリーミング・サーバ
１２２ コンテンツ
１３１ エッジルータ
１３２ ネットワーク・インタフェース
１４１ エッジルータ
１４２ ネットワーク・インタフェース
１５１ コア・ネットワーク
１５２ 管理サーバ
１５３ 帯域管理テーブル
２００ ＣＰＵ
２０１ 主記憶装置
２０２ 二次記憶装置
２０３ ネットワーク・インタフェース
２１０ ＣＰＵ
２１１ 主記憶装置
２１２ 二次記憶装置
２１３ ネットワーク・インタフェース
２２０ ＣＰＵ
２２１ 主記憶装置
２２２ 二次記憶装置
２２３ ネットワーク・インタフェース
３０１ コンテンツ選択画面
３１１ 初期品質選択画面
３１３ 低解像度ボタン
３１４ 高解像度ボタン
３１５ 画質改善ボタン
３１６ 停止ボタン
３２１ 低解像度再生画面
３２２ 再生画面
３３１ 高解像度再生画面
３３２ 再生画面
７０１〜７０３ グラフ
８００ 原データ
８０１ ビデオ識別子
８０２ サーバ・アドレス
８０３ 解像度
８０４ 通信計画案
８１１〜８１８ レコード
１３０１ ＨＧＷ
１３０２ 計測制御サーバ
１４０１ 品質メニュー
１４０２ 品質改善ボタン
１４０３ キャンセル・ボタン
１４１１ 品質メニュー
１４１２ 音質改善ボタン
１４１３ 画質改善ボタン
１４１４ Ｗｅｂ高速化ボタン
１４１５ キャンセル・ボタン
【技術分野】
【０００１】
本発明はパケット交換ネットワークにおける通信品質の改善に関する。
【背景技術】
【０００２】
インターネット・プロトコル（ＩＰ）に基づく通信の品質、すなわち、ＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）を改善するための方法として、インターネットの標準化組織であるＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）の標準ドキュメントＲＦＣ２２１２、ＲＦＣ２２１５などにおいて規定されているＩｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅｓ（ＩｎｔＳｅｒｖ）、及びＩＥＴＦのドキュメントＲＦＣ２４７４、ＲＦＣ２４７５、ＲＦＣ２４３０などにおいて規定されているＤｉｆｆｅｒｅｎｔｉａｔｅｄ Ｓｅｒｖｉｃｅｓ（ＤｉｆｆＳｅｒｖ）がある。現在、大規模ネットワークに適しているＤｉｆｆＳｅｒｖが広く使用されている。
【０００３】
しかし、通信サービスにおけるユーザの体感品質、すなわち、ＱｏＥ（Ｑｕａｌｉｔｙ ｏｆ Ｅｘｐｅｒｉｅｎｃｅ）を向上させることが必要である。ＱｏＥを向上させることがユーザの満足度を高めることにつながる。
【０００４】
ＱｏＥを向上させるためには、端点間（ｅｎｄ−ｔｏ−ｅｎｄ）のＱｏＳを保証することが必要と考えられてきた。ＡＴＭ（Ａｓｙｎｃｈｒｏｎｏｕｓ Ｔｒａｎｓｆｅｒ Ｍｏｄｅ）は、通信フローごとの端点間のＱｏＳ保証のための機構を備えていたが、今日必要とされている大規模な通信サービスに適用できるものではなかった。ＩｎｔＳｅｒｖにおいては、ＩＥＴＦ標準ドキュメントＲＦＣ１６６３によって規定されたプロトコルであるＲＳＶＰ（ｒｅｓｏｕｒｃｅ ＲｅＳｅｒＶａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）を使用してフロー単位でルータ等の資源を確保することによってＱｏＳを保証する。ＩｎｔＳｅｒｖはインターネットにおいてこのようなフローごとの通信のＱｏＳを保証するための方法であったが、ＡＴＭと同様に大規模ネットワークには適用できなかった。
【０００５】
これに対してＤｉｆｆＳｅｒｖは、フロー単位ではなくフローをまとめたクラスを単位とすることによって大規模ネットワークへの適用を可能にした。しかし、その反面、端点間のＱｏＳが保証できる方法ではなかった。
【０００６】
そのため、ＤｉｆｆＳｅｒｖとＩｎｔＳｅｒｖとを組み合わせる、すなわち、フローごとにネットワーク・トラフィックを制御することが困難なコア・ネットワークにおいてはＤｉｆｆＳｅｒｖを使用し、ＬＡＮやアクセス・ネットワークのようなフローごとの制御が可能な末端のネットワークにおいてはＩｎｔＳｅｒｖ又はそれに準じる方法を使用する方法、例えば、ＲＦＣ２９９８に記述されている方法が開発されてきた。すでに一部のキャリアにおいてサービスが開始されているＮＧＮ（次世代ネットワーク（Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｎｅｔｗｏｒｋｓ））においては、前述したような方法の実現を可能にするプロトコルを採用することによって、端点間のＱｏＳ保証を可能にしている。
【０００７】
ＮＧＮの基本的な枠組みに関してはＩＴＵ−Ｔ（国際電気通信連合（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｕｎｉｏｎ）の電気通信標準化部門）、３ＧＰＰ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）、ＥＴＳＩ（欧州電気通信標準化機構（Ｅｕｒｏｐｅａｎ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｔａｎｄａｒｄｓ Ｉｎｓｔｉｔｕｔｅ））などにおいて議論され、標準化が進められてきた。音声、又は動画などの通信においてはＩＥＴＦ標準ドキュメントＲＦＣ３２６１によって規定されたセッション制御プロトコルＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）が使用されることが多い。そのため、ＮＧＮにおいてはＳＩＰを用いた通信を通じてＱｏＳ保証の実現するためのＩＭＳ（ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ）という機構が使用される。
【０００８】
ＳＩＰを使用したＱｏＳ保証のための機構としては、ＳＩＰメッセージに含まれるＳＤＰ（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）のメッセージと、ＳＩＰによるメッセージングと組み合わされたＲＳＶＰによるメッセージングとによって通信に使用する資源を確保する方法がある（例えば、非特許文献１参照）。端点間の通信のためのＳＤＰメッセージと、端点を結ぶパス上に存在するルータの資源を確保するためのＲＳＶＰメッセージとを使用することによって、通信帯域幅、及びパケット損失率等のＱｏＳパラメタが記述され、それらがネットワークに伝えられる、すなわち、目標とするべき１個のＱｏＳ条件を指定することができる。そして、それらをネットワークにおいて実現することができる。
【０００９】
ＳＤＰメッセージには通信に使用するメディア、すなわち、音声又は動画等の区別と、音声又は動画等において使用されるコーデックなどの情報とが含まれている。前述のメディア又はコーデックは、通信相手において実現可能であるとは限らない。そのため、前述の問題を解決するため、ＳＤＰによる通信において、実現可能なメディア又はコーデックの確立を交渉するためのｏｆｆｅｒ／ａｎｓｗｅｒ ｍｏｄｅｌをＳＤＰメッセージに記述する方法がある（例えば、非特許文献２参照）。すなわち、ＳＩＰのＩＮＶＩＴＥ要求を送信した送信者が、受信者から要求したとおりの内容を含むＳＤＰメッセージを受け取れば、メディア又はコーデックの確立の交渉が成立するが、他の条件を含むＳＤＰメッセージを受信したときには、メディア又はコーデックが変更される。
【００１０】
ＮＧＮにおいて、非特許文献１におけるＱｏＳ保証方式を拡張して、ＲＳＶＰ又はそれに準じるプロトコルをかならずしも使用しなくても、メッセージングを媒介するＳＩＰサーバが、本来は端点間の通信だけで使用されるＳＩＰ及びＳＤＰのメッセージを読み取ったり、書き換えたりすることによって、ネットワークにおける資源やアドミッションを制御することを可能にする方法がある（例えば、非特許文献３）。また、携帯電話の環境において、ＳＩＰ及びＳＤＰを使用したＱｏＳ保証の方法もある（例えば、特許文献１参照）。
【特許文献１】米国特許７１０６７１８Ｂ２号明細書
【非特許文献１】Camarillo, G., Marshall, W., and Rosenberg, J., “Integration of Resource Management and Session Initiation Protocol (SIP)”, RFC 3312, IETF, October 2002.
【非特許文献２】Rosenberg, J. and Schulzrinne, H., “An Offer/Answer Model with the Session Description Protocol (SDP)”, RFC 3264, IETF, June 2002.
【非特許文献３】3rdGenerationPartnershipProject(3GPP),“InternetProtocol(IP)multimediacallcontrolprotocolbasedonSessionInitiationProtocol(SIP)andSessionDescriptionProtocol(SDP);Stage3(Release7)”,3GPPTS24.229V7.3.0,March2006.
【発明の開示】
【発明が解決しようとする課題】
【００１１】
特定の通信セッションにおいて必要となる資源は、必ずしも通信の開始から終了までの間、一定であるとは限らない。例えば、ストリーミングのように、送信する内容が予め決定されている場合、必要となる資源の予測が可能であり、かつ通信のスケジュールも制御することができる。すなわち、通信の進行に伴ってＱｏＳ条件を変更することによって、より多くのユーザが満足できるようなスケジューリングができる。具体的には、ユーザが求めるＱｏＥを実現するためのスケジュールを複数個用意するか、又はパラメタを変えることによって連続的に変化するスケジュールを規定することができる。
【００１２】
しかし、前述のように計画にしたがって、通信中にＱｏＳ条件を変更するためには解決しなければならない課題が２つある。
【００１３】
第１に、従来のＮＧＮに用いられる方法では、ＱｏＳ条件を変更するたびにセッション制御メッセージング（ｒｅＩＮＶＩＴＥ要求）が必要になる。通信開始時にネットワーク・サーバが知ることができるのは、その時点におけるアプリケーションのＱｏＳ要求であり、アプリケーションがどのようなＱｏＥを要求し、要求されたＱｏＥをどのようなスケジュールによって実現されようとしているかはわからない。そのため、ネットワーク・サーバは、通信開始時、又は通信中のＱｏＳ条件変更時においても、当該のアプリケーションに最適なＱｏＥ又はＱｏＳを実現できない可能性があり、また、ユーザ全体、すなわち、ネットワーク全体としても最適な制御を行うことができないという問題がある。
【００１４】
つまり、第１の課題は、個々のユーザの通信について、当該ユーザのＱｏＥが最適になるような資源の割り当て計画を実現し、かつ、ネットワーク全体におけるユーザ全体のＱｏＥが最適になるような資源割り当て計画を実現することである。
【００１５】
第２に、前述のような通信を実現するためには、ＱｏＳ条件の変更に伴って、通信中にルータの設定を変更する必要が生じる。したがって、ルータの設定変更によって生じる通信障害をなくし、オーバヘッドを減少させる必要がある。具体的には、ルータのキュー構成を動的に変更することによってルータに負荷がかかるのを防止し、また、構成変更が完了するまでキューイングが停止してパケットが損失することを防止しなければならない。
【００１６】
つまり、第２の課題は、ルータに大きな負荷をかけることなく、かつ、パケット損失などの問題を起こすことなく、ルータの出力キューにおける帯域設定などのＱｏＳ条件を動的に変更できるようにすることである。
【００１７】
本発明の目的は、これらの問題を解決することにある。
【課題を解決するための手段】
【００１８】
本発明の代表的な一例を示せば以下の通りである。すなわち、計算機と、ネットワークノードと、前記計算機上で実行されるアプリケーションに必要なデータを前記計算機に送信するアプリケーションサーバと、前記計算機と前記アプリケーションサーバとの間の通信の計画を管理する通信計画サーバと、前記計算機、前記ネットワークノード及び前記アプリケーションサーバが接続されたネットワークを管理する管理サーバとを備えるネットワークシステムであって、前記アプリケーションサーバは、第１のプロセッサ、前記第１のプロセッサと接続されている第１のメモリ、前記第１のプロセッサと接続されている第１の不揮発性記憶媒体、前記ネットワークと接続される第１のネットワークインタフェースを備え、前記通信計画サーバは、第２のプロセッサ、前記第２のプロセッサと接続されている第２の記憶媒体、前記ネットワークと接続される第２のネットワークインタフェースを備え、前記管理サーバは、第３のプロセッサ、前記第３のプロセッサと接続されている第３のメモリ、前記第３のプロセッサと接続されている第３の不揮発性記憶媒体、前記ネットワークと接続される第３のネットワークインタフェースを備え、前記通信計画サーバは、前記アプリケーションサーバが格納するデータに対する、前記ネットワークにおいて提供されるサービスの品質を決定する通信条件を前記第２の記憶媒体に格納し、前記計算機から、前記計算機上で実行されるアプリケーションの品質に対する前記計算機のユーザによる要求である第１の品質条件を受信した場合、前記受信した第１の品質条件を実現するための、複数の前記通信条件を前記管理サーバに送信し、前記管理サーバは、前記通信計画案を受信した場合、前記受信した複数の通信条件の中から最適な前記通信条件を選択し、前記選択された通信条件を含む品質応答を前記アプリケーションサーバに送信し、前記アプリケーションサーバは、前記品質応答に含まれる前記通信条件にしたがって、前記計算機上で実行されるアプリケーションに必要なデータを前記計算機に送信することを特徴とする。
【発明の効果】
【００１９】
本発明によれば、ユーザが要求するアプリケーションの品質に対する品質条件を最適にするような通信条件を実現でき、また、ネットワーク全体の帯域を考慮した、該ネットワークにおけるユーザ全体の品質条件を最適にする通信条件を実現できる。また、パケット損失などの問題を起こすことなく、ネットワークノードの出力インタフェースにおけるキューの帯域設定を動的に変更できる。
【発明を実施するための最良の形態】
【００２０】
本発明の第１の実施形態について説明する。
【００２１】
本実施形態は、ユーザからの要求に基づいて、動画ストリーミングが再生されるときに、該ユーザに最適なＱｏＥを実現し、かつ、ネットワークにおけるユーザ全体に最適なＱｏＥを実現する。
【００２２】
動画ストリーミングにおけるＱｏＥの主要な要素としては、画像の品質、すなわち、解像度、画面の乱れの少なさ、及びスタートアップ時間の短さが考えられる。ここで、スタートアップ時間とは、動画再生の要求から、動画の再生が開始されるまでの時間である。
【００２３】
ストリーミングにおいて、通常、ジッターを減少させるために受信側のアプリケーションが数秒間データをバッファリングしてから動画を再生する。そのため、ＱｏＥを改善するには、コンテンツの画質を劣化させずにデータを転送し、再生開始までの時間（以下、スタートアップ時間と呼ぶ）を縮めることが重要である。特に、スタートアップ時間の短さは、ユーザが複数のコンテンツの中から興味のあるものを選択するとき、いわゆるザッピングを行うときに重要になる。
【００２４】
本実施形態において、解像度、及びスタートアップ時間の短さを確保することを、ＱｏＥを改善するための主要な目標とする。
【００２５】
図１は、本発明の第１の実施の形態における、ネットワークシステム構成を示すブロック図である。
【００２６】
コア・ネットワーク１５１には、エッジルータ１３１、及びエッジルータ１４１が接続されている。なお、各エッジルータ１３１、１４１は、スイッチであってもよい。
【００２７】
コア・ネットワーク１５１に１台又は複数台のコア・ノードが含まれる場合、エッジルータ１３１、１４１は、前記コア・ノードに接続されるか、又はエッジルータ同士で接続される。なお、コア・ネットワーク１５１に他の装置が含まれず、エッジルータ１３１とエッジルータ１４１とが互いに接続されていてもよい。
【００２８】
図１に示す例において、エッジルータ１３１のＩＰアドレスは、「１０．１０．１１．１」であり、インタフェース番号が「１」のネットワーク・インタフェース１３２に接続されたリンクを経由して、直接又は他のネットワーク装置を介して、エンドユーザのコンピュータ１０１及びコンピュータ１０２と接続されている。
【００２９】
コンピュータ１０１にはＩＰアドレスとして「１０．１０．２１．１０」が割り当てられ、コンピュータ１０２にはＩＰアドレスとして「１０．１０．２１．１５」が割り当てられている。また、コンピュータ１０１及びコンピュータ１０２は、ＣＰＵ（図示省略）、主記憶装置（図示省略）、二次記憶装置（図示省略）を備えている。
【００３０】
エッジルータ１４１のＩＰアドレスは、「１０．１０．１２．１」であり、インタフェース番号が「１」のネットワーク・インタフェース１４２に接続されたリンクを経由して、直接又は他のネットワーク装置を介して、通信計画サーバ１１１とストリーミング・サーバ１２１とが接続されている。
【００３１】
通信計画サーバ１１１にはＩＰアドレスとして「１０．１０．２２．１１」が割り当てられ、また、通信計画サーバ１１１は通信計画データベース１１２を備える。ストリーミング・サーバ１２１にはＩＰアドレスとして「１０．１０．２２．１２」が割り当てられ、また、ストリーミング・サーバ１２１はコンテンツ１２２を備える。
【００３２】
管理サーバ１５２にはＩＰアドレスとして「１０．１０．２３．３１」が割り当てられ、また、管理サーバ１５２はエッジルータ１３１、１４１又はコア・ネットワーク１５１に含まれる他のネットワーク装置と接続されている。
【００３３】
図２Ａは、本発明の第１の実施形態における通信計画サーバ１１１のハードウェア構成を説明するブロック図である。
【００３４】
通信計画サーバ１１１は、ＣＰＵ２００、主記憶装置２０１、二次記憶装置２０２、及びネットワーク・インタフェース２０３を備える。主記憶装置２０１は、例えばメモリである。二次記憶装置２０２は、例えばＨＤＤである。二次記憶装置２０２上又は外部の装置（図示省略）に通信計画データベースが備えられる。また、通信計画サーバ１１１は、ネットワーク・インタフェース２０３を介してエッジルータ１４１と接続されている。
【００３５】
図２Ｂは、本発明の第１の実施形態におけるストリーミング・サーバ１２１のハードウェア構成を説明するブロック図である。
【００３６】
ストリーミング・サーバ１２１は、ＣＰＵ２１０、主記憶装置２１１、二次記憶装置２１２、及びネットワーク・インタフェース２１３を備える。主記憶装置２１１は、例えばメモリである。二次記憶装置２１２は、例えばＨＤＤである。二次記憶装置２１２上又は外部の装置（図示省略）にコンテンツ１２２が備えられている。また、ストリーミング・サーバ１２１は、ネットワーク・インタフェース２１３を介してエッジルータ１４１と接続されている。
【００３７】
図２Ｃは、本発明の第１の実施形態における管理サーバ１５２のハードウェア構成を説明するブロック図である。
【００３８】
管理サーバ１５２は、ＣＰＵ２２０、主記憶装置２２１、二次記憶装置２２２、及びネットワーク・インタフェース２２３を備える。主記憶装置２２１は、例えばメモリである。二次記憶装置２２２は、例えばＨＤＤである。二次記憶装置２２２上又は外部の装置（図示省略）に帯域管理テーブル１５３が備えられる。また、管理サーバ１５２は、ネットワーク・インタフェース２２３を介して、エッジルータ１３１、１４１又はコア・ネットワーク１５１に含まれる他のネットワーク装置と接続されている。
【００３９】
次に、セッション開始時及びセッション継続中にユーザがアプリケーションに要求を入力するためのグラフィカル・ユーザ・インタフェース（ＧＵＩ）について説明する。
【００４０】
図３Ａは、本発明の第１の実施形態における、コンテンツ選択のためのグラフィカル・ユーザ・インタフェース（ＧＵＩ）を説明する図である。図３Ｂは、本発明の第１の実施形態における、初期品質を選択するためのグラフィカル・ユーザ・インタフェース（ＧＵＩ）を説明する図である。図３Ｃは、本発明の第１の実施形態における、低解像度を選択した場合のグラフィカル・ユーザ・インタフェース（ＧＵＩ）を説明する図である。図３Ｄは、本発明の第１の実施形態における、高解像度を選択した場合のグラフィカル・ユーザ・インタフェース（ＧＵＩ）を説明する図である。図３Ａ〜図３Ｄに示すＧＵＩは、Ｗｅｂによって実現されている。
【００４１】
図３Ａに示すコンテンツ選択画面３０１は、ユーザがコンテンツ選択画面３０１に表示されているコンテンツの中から特定のコンテンツを選択するためのメニュー画面である。コンテンツ選択画面３０１は、Ｗｅｂサイトにおける、ＨＴＭＬページとして実現される。ユーザが、コンテンツ選択画面３０１に表示されているコンテンツを選択すると、図３Ｂに示す初期品質選択画面３１１に遷移する。すなわち、コンテンツ選択画面３０１に表示されているコンテンツの項目は、ハイパー・リンクによって表現されており、いずれかのコンテンツが選択（クリック）されることによって、それぞれ異なるパラメタが指定されて、ＣＧＩ（Ｃｏｍｍｏｎ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ）プログラムが起動される。
【００４２】
初期品質選択画面３１１は、低解像度ボタン３１３、及び高解像度ボタン３１４が表示されている。すなわち、異なるＱｏＥ条件の選択肢が表示されている。なお、画質改善ボタン３１５、及び停止ボタン３１６は、初期品質設定においては、ユーザが選択できないようになっている。例えば、ボタン操作の無効又は表示しない等が考えられる。ユーザは、低解像度ボタン３１３、又は高解像度ボタン３１４のいずれかを選択（クリック）することができる。ユーザがどちらのボタンを選択するかは、当該選択によって、課金に差がでること、また、コンピュータ１０１の画面の解像度、若しくは処理性能によって、どちらがそのユーザにとって最適であるかに依存する。
【００４３】
ユーザが低解像度ボタン３１３を選択した場合、低解像度再生画面３２１が表示され、また、ユーザが高解像度ボタン３１４を選択した場合、高解像度再生画面３３１が表示される。すなわち、どちらのボタンを操作するかによって、異なるパラメタが指定されて、ＣＧＩプログラムが起動される。
【００４４】
図３Ｃに示す低解像度再生画面３２１における再生画面３２２は低解像度による動画再生画面であり、再生画面３２２はＷｅｂのプラグインとして実現される。再生画面３２２は、ストリーミング・サーバ１２１から送信される動画データを受信して再生される動画を表示する。低解像度再生画面３２１において、低解像度ボタン３１３はすでに選択されているため無効化されている。つまり、ユーザは、低解像度ボタン３１３を操作（クリック）できない。
【００４５】
ユーザは、低画質度で動画が再生されている途中に、高解像度ボタン３１４を操作（クリック）することによって、高解像度再生画面３３１に移行することができる。また、ユーザは、低解像度再生画面３２１に表示されている画質改善ボタン３１５を操作（クリック）することによって、再生されている画質を改善することができる。また、ユーザは、停止ボタン３１６を操作（クリック）することによって、動画の再生を停止することができる。
【００４６】
図３Ｄに示す高解像度再生画面３３１おける再生画面３３２は高解像度による動画再生画面であり、再生画面３３２はＷｅｂのプラグインとして実現される。再生画面３３２は、ストリーミング・サーバ１２１から送信される動画データを受信して再生される動画を表示する。高解像度再生画面３３１において、高解像度ボタン３１４はすでに選択されているため無効化されている。つまり、ユーザは、低解像度ボタン３１３を操作（クリック）できない。
【００４７】
ユーザは、高画質度で動画が再生されている途中に、低解像度ボタン３１３を操作（クリック）することによって、低解像度再生画面３２１に移行することができる。また、ユーザは、高解像度再生画面３３１に表示されている画質改善ボタン３１５を操作（クリック）することによって、再生されている画質を改善することができる。また、ユーザは、停止ボタン３１６を操作（クリック）することによって、動画の再生を停止することができる。
【００４８】
ＱｏＥ条件としては、解像度のほかにスタートアップ時間を指定することも可能である。例えば、課金が大きく、かつ、スタートアップが高速であるＱｏＥ条件を選択するためのボタンと、課金が小さく、かつ、スタートアップが低速であるＱｏＥ条件を選択するためのボタンとを、それぞれの初期品質選択画面３１１、低解像度再生画面３２１、及び高解像度再生画面３３１に表示することができる。
【００４９】
図３Ａ〜図３Ｄにおいて示したグラフィカル・ユーザ・インタフェースにおける操作によって発生する処理については、図４を用いて後述する。
【００５０】
なお、図３Ａ〜図３ＤにおいてＣＧＩを実現するための方法として、ＷｅｂサーバのＣＧＩを使用する場合を示したが、ウィンドウ・システムなど、他の方法を使用することもできる。
【００５１】
図４は、本発明の第１の実施形態において、ユーザがセッション開始時又はセッション継続中に、低解像度ボタン３１３又は高解像度ボタン３１４を操作したときのネットワークシステムにおける処理手順を示すシーケンス図である。
【００５２】
当該処理は、コンピュータ１０１上で動作するＷｅｂブラウザが、ユーザによる品質要求４０１を受信することによって開始される。なお、ユーザによる品質要求４０１は、低解像度ボタン３１３又は高解像度ボタン３１４のいずれかを操作（クリック）することによって発生する。
【００５３】
ユーザによる品質要求４０１を受信したコンピュータ１０１は、通信計画サーバ１１１に品質要求４０２を送信する。品質要求４０２には、ビデオ識別子とＱｏＥ情報とが含まれる。図４に示す例では、ビデオ識別子には、「ｌｉｆｅ ｉｎ ｖｅｎｉｃｅ」（初期品質選択画面３１１の「ベニスに生きる」に対応する）が含まれ、また、ＱｏＥ情報には、解像度として「８００×４５０」と、スタートアップ時間として「０．５秒」とが含まれる。なお、品質要求４０２は、他のＱｏＥ情報を含んでもよい。
【００５４】
品質要求４０２を受信した通信計画サーバ１１１は、図９Ａに示す手順にしたがって処理を実行する。具体的には、管理サーバ１５２に通信計画データベース１１２にアクセスして「ベニスに生きる」の３つの通信計画案（図８参照）を含む品質要求４０３を送信する。
【００５５】
図４に示す例では、通信計画案として、初期帯域、スタートアップ時間、定常帯域及び最大帯域が指定されている。具体的には、次のように指定されている。
通信計画案１：（４０Ｍ、０．５秒、５Ｍ、５Ｍ）
通信計画案２：（２０Ｍ、０．５秒、７Ｍ、７Ｍ）
通信計画案３：（０、０秒、５Ｍ、１０Ｍ）
管理サーバ１５２に送信された３つの通信計画案の詳細については、図６Ａ〜図６Ｃを用いて後述する。
【００５６】
品質要求４０３は、通信計画案の他に、品質要求４０２の送信者のＩＰアドレスと品質要求４０３の受信者のＩＰアドレスとを含む。具体的には、送信者のＩＰアドレスは、コンピュータ１０１のＩＰアドレス「１０．１０．２１．１０」であり、受信者のＩＰアドレスは、品質要求４０２において指定された「ｌｉｆｅ ｉｎ ｖｅｎｉｃｅ」の解像度が「８００×４５０」であるファイルを格納するストリーミング・サーバ１２１のＩＰアドレス「１０．１０．２２．１２」である。
【００５７】
品質要求４０３を受信した管理サーバ１５２は、図１０に示す手順にしたがって処理を実行する。これによって、帯域制限設定４０４、キューイング設定４０５及び品質応答４０６の３つのメッセージが各々送信される。具体的には、帯域制限設定４０４はエッジルータ１４１に送信され、キューイング設定４０５はエッジルータ１３１に送信され、品質応答４０６は管理サーバ１５２に送信される。
【００５８】
品質応答４０６は、エッジルータ１４１がキュー設定を完了した応答を管理サーバ１５２が受信した後に送信されてもよいし、エッジルータ１４１のキュー設定の処理が完了する時間に動画が再生されるようなタイミングで送信されてもよい。
【００５９】
品質応答４０６には、管理サーバ１５２が選択した通信計画案が含まれる。図４に示す例では、品質応答４０６に通信計画案１が含まれる。なお、送信された通信計画案のいずれもが実現可能でない場合、管理サーバ１５２は、通信計画サーバ１１１に品質応答４０６の代わりに拒否応答を送信する。
【００６０】
帯域制限設定４０４には、動画ストリーミングにおけるトラフィック（動画再生４０９）がエッジルータ１４１を通過するときに許容される最大帯域を超えないように制限するための設定が含まれる。
【００６１】
例えば、通信計画案１では最大帯域が「２０Ｍｂｐｓ」と指定され、通信計画案２では最大帯域が「４０Ｍｂｐｓ」と指定され、通信計画案３では最大帯域が「１０Ｍｂｐｓ」と指定されている。ただし、ストリーミング・サーバ１２１からの送信帯域が、指定された最大帯域以下になることが確実であれば、帯域制限設定４０４は不要である。
【００６２】
キューイング設定４０５には、動画再生４０９において、エッジルータ１３１のネットワーク・インタフェース１３２で確保されるべき最低保証帯域を持つキューが使用されるための設定が含まれる。例えば、通信計画案１では最低保証帯域が「５Ｍｂｐｓ」であるキューが選択され、通信計画案２では最低保証帯域が「７Ｍｂｐｓ」であるキューが選択され、通信計画案３では最低保証帯域が「５Ｍｂｐｓ」であるキューが選択される。
【００６３】
品質応答４０６を受信した通信計画サーバ１１１は、図９Ｂに示す手順にしたがってコンピュータ１０１に品質応答４０７を送信する。品質応答４０７には、選択された通信計画案と要求されたコンテンツを格納するストリーミング・サーバ１２１のＩＰアドレスが含まれる。また、品質応答４０７にはストリーミング・サーバ１２１以外の他のサーバ（図示省略）のアドレスが含まれてもよい。なお、送信された通信計画案のいずれもが実現可能でない場合、通信計画サーバ１１１は、コンピュータ１０１に品質応答４０７の代わりに拒否応答を送信する。
【００６４】
品質応答４０７を受信したコンピュータ１０１は、受信した品質応答４０７に含まれる通信計画案にしたがって、再生要求４０８をストリーミング・サーバ１２１に送信する。図４に示す例では、再生要求４０８には通信計画案１が含まれる。
【００６５】
再生要求４０８を受信したストリーミング・サーバ１２１は、受信した再生要求４０８に含まれる通信計画案に基づいて、図１１に示す手順にしたがって動画再生４０９を実行する。
【００６６】
図４に示したシーケンスにおいて、通信計画サーバ１１１は、すべての通信計画案を一度に管理サーバ１５２に送信する。前述の方法は、単純であり通信シーケンスが短いという利点がある。しかし、送信される通信計画案が多数ある場合、通信計画サーバ１１１が送信するデータ量が多くなる。そこで、通信計画サーバ１１１が管理サーバ１５２に通信計画案を送信する方法の５つの代案を以下に示す。なお、以下の説明において、図４における通信計画サーバ１１１が管理サーバ１５２に通信計画案を送信する方法を、原案と記載する。
【００６７】
第１の代案では、通信計画サーバ１１１は、通信計画サーバ１１１が最適なものを選択し、当該選択された通信計画案のみを含む品質要求４０３を管理サーバ１５２に送信する。
【００６８】
管理サーバ１５２は、送信された通信計画案が適切か否かを判定し、適切な通信計画案であると判定された場合、当該通信計画案を含む品質応答４０６又は、ＯＫメッセージを通信計画サーバ１１１に送信し、不適切な通信計画案であると判定された場合、品質応答４０６の代わりに拒否応答を通信計画サーバ１１１に送信する。
【００６９】
通信計画サーバ１１１は、管理サーバ１５２が通信計画案を受理する（通信計画サーバ１１１が品質応答４０６又は、ＯＫメッセージを受信する）まで代わりの通信計画案を送信し続ける。通信計画サーバ１１１は、送信する通信計画案が無い場合、品質応答４０７の代わりに拒否応答をコンピュータ１０１に送信する。
【００７０】
つまり、第１の代案は、通信計画サーバ１１１と管理サーバ１５２との間の交渉によって通信計画案が選択される。第１の代案は、平均の通信量が原案より減少するという利点がある。
【００７１】
第２の代案では、通信計画サーバ１１１は、パラメタが付与された１つの通信計画案を管理サーバ１５２に送信し、管理サーバ１５２は、付与されたパラメタの最適値を算出して通信計画サーバ１１１に送信する。
【００７２】
パラメタが付与された通信計画案としては、例えば、前記通信計画案１及び２をまとめて、（１０×（２＋α）、０．５秒、５＋αＭ、５＋αＭ）（α＝０、２）とすることが考えられる。ここで、αがパラメタである。より多くの通信計画案をまとめることができれば、送信データ量を減らすことができる。なお、当該パラメタ及び、パラメタが付与された通信計画案は、通信計画サーバ１１１によって決定されている。
【００７３】
つまり、第２の代案は、通信シーケンスは原案と同様に短く、かつ送信するデータ量も少ないという利点がある。
【００７４】
第３の代案では、図５に示すようなシーケンスにしたがって処理が実行される。
【００７５】
図５は、本発明の第１の実施形態において、ユーザがセッション開始時又はセッション継続中に、低解像度ボタン３１３又は高解像度ボタン３１４を操作したときのネットワークシステムにおける処理手順の変形例示すシーケンス図である。以下、図４との差異を中心に説明する。
【００７６】
図５に示すシーケンスでは、品質要求４０２、品質要求４０３、品質応答４０６、及び品質応答４０７の代わりに品質要求５０１、品質要求５０２、品質応答５０３、及び品質応答５０４が用いられる。他の処理手順は図４と同一である。
【００７７】
図５に示すシーケンスにおいて、コンピュータ１０１と通信計画サーバ１１１との間の通信にＳＩＰが使用される。ＮＧＮのＩＭＳでは資源確保のためにＳＩＰが使用されるが、図５に示すシーケンスはそれを拡張したものである。すなわち、ストリーミングのセッション開始時にＲＴＳＰによるセッション制御（再生要求４０９）の前にＳＩＰによるセッション制御が実行される。品質要求５０１は、ＳＩＰのＩＮＶＩＴＥメッセージであり、通信相手はセッション制御サーバである通信計画サーバ１１１である。
【００７８】
品質要求５０１は、拡張されたＳＤＰメッセージが含まれる。されに、拡張されたＳＤＰメッセージにはビデオ識別子、解像度、及びスタートアップ時間が含まれる。品質要求５０１は、ＳＩＰサーバである管理サーバ１５２を経由して通信計画サーバ１１１に到達する。具体的には、管理サーバ１５２は、受信した品質要求５０１を品質要求５０２として、通信計画サーバ１１１に転送する。
【００７９】
通信計画サーバ１１１から送信される品質応答５０３は、ＳＩＰのＯＫ応答であり、さらに、複数の通信計画案が含まれる。管理サーバ１５２は、品質応答５０３に含まれる複数の計画案を参照し、最適な通信計画案を選択し、選択された通信計画案を含む品質応答５０４をＳＩＰクライアントであるコンピュータ１０１に転送する。品質応答５０４は、通信計画案を１つのみ含む点が品質応答５０３と異なる。
【００８０】
第４の代案では、図５に示すシーケンスにおいて、第１の代案と同様に、品質応答５０３には通信計画サーバ１１１が最適のものとして選択した通信計画案が含まれる。管理サーバ１５２は、当該通信計画案を拒否する場合、品質応答５０４としてＯＫメッセージの代わりにＳＩＰの失敗応答をコンピュータ１０１に送信する。つまり、ｏｆｆｅｒ／ａｎｓｗｅｒモデルにしたがってコンピュータ１０１と通信計画サーバ１１１との間で通信計画案をやりとりすることによって、間接的に管理サーバ１５２と通信計画サーバ１１１との間で交渉することができる。
【００８１】
第５の代案においては、図５に示すシーケンスにおいて、第２の代案と同様に、品質応答５０３にパラメタつきの通信計画案が含まれる。管理サーバ１５２は、最適なパラメタ値を決定し、決定されたパラメタを品質応答５０４に含めるよって、コンピュータ１０１が決定されたパラメタ値によって指定された通信計画案を受け取ることができる。
【００８２】
以上が、通信計画サーバ１１１が管理サーバ１５２に通信計画案を送信する方法の代案の説明である。
【００８３】
なお，図４に示すシーケンスにおいて、品質要求４０２及び品質要求４０３が送信された後、当該品質要求４０２及び品質要求４０３を取り消す要求メッセージを送信しない限り、その効果が継続する。具体的には、帯域制限設定４０４及びキューイング設定４０５によるエッジルータ１３１、１４１の設定が解除されない。したがって、エッジルータ１３１、１４１の設定を解除のための要求メッセージが送信されないと、エッジルータ１３１、１４１の資源が解放されないという問題がある。
【００８４】
前述した問題を解決するに、品質要求４０２及び品質要求４０３にタイムアウト時間を含める方法が考えられる。例えば、品質要求４０２がタイムアウト時間として「６０分」を含む場合、品質要求４０３にもタイムアウト時間が含まれ、管理サーバ１５２が時間を計測し、６０分に達したときに帯域制限設定４０４およびキューイング設定４０５によるエッジルータ１３１、１４１の設定を無効化するように設定する。
【００８５】
また、タイムアウト時間が経過する前に、品質要求４０２と同一の内容の要求メッセージがコンピュータ１０１から通信計画サーバ１１１に送信された場合、タイマーはリセットされ、タイムアウトの時間が延長される。したがって、ユーザがボタンを操作（クリック）することによって、ユーザによる品質要求４０１が発行された後、指定されているタイムアウト時間が経過する前にユーザが同一のボタンを、再度操作（クリック）した場合、品質要求４０２と同一の内容の要求が発行されて、タイムアウトの時間が延長される。これによって、図１２に示す処理を必要としない。
【００８６】
図６Ａは、本発明の第１の実施形態における通信計画案１を説明する図である。図６Ｂは、本発明の第１の実施形態における通信計画案２を説明する図である。図６Ｃは、本発明の第１の実施形態における通信計画案３を説明する図である。
【００８７】
通信計画案１は、最初の０．５秒間だけ２０Ｍｂｐｓでデータを送信し、それ以降は７Ｍｂｐｓの一定レート（ＣＢＲ（Ｃｏｎｓｔａｎｔ Ｂｉｔ Ｒａｔｅ））でデータを送信する計画である。ただし、実際には、７Ｍｂｐｓよりレートが低くなる場合がある。
【００８８】
通信計画案２は、最初の０．５秒間だけ４０Ｍｂｐｓでデータを送信し、それ以降は５Ｍｂｐｓの一定レートでデータを送信する計画である。
【００８９】
通信計画案１と比較して通信計画案２における一定レートが低いのは、本実施形態において、通信計画案１では受信側アプリケーションのジッター・バッファを１０Ｍｂｉｔ（１．２５ＭＢ）と仮定しているのに対して、通信計画案２では受信側アプリケーションのジッター・バッファを２０Ｍｂｉｔ（２．５ＭＢ）と仮定しているため、実際のレートをならすことができるからである。すなわち、通信計画案２では、再生される予定の動画の動きが速くなるなどして再生レートが増加するときに、予め多くのデータを送信しておくことができるため、通信計画案１より一定レートを低くすることができる。
【００９０】
通信計画案３は、通信計画案１、２とは異なり、最初から５Ｍｂｐｓの一定レートでデータを送信し、また、１０Ｍｂｐｓまでのレートでデータが送信されることを許容している。すなわち、通信計画案３は、ＶＢＲ（Ｖａｒｉａｂｌｅ Ｂｉｔ Ｒａｔｅ）で送信する計画である。
【００９１】
通信計画案１、２において、最初の０．５秒間以外の部分では、それぞれ７Ｍｂｐｓ又は５Ｍｂｐｓの最低帯域が保証されることによって、遅延及びパケット損失を防ぐことができる。
【００９２】
通信計画案３において、１０Ｍｂｐｓの最低帯域が保証されることによって、遅延及びパケット損失を防ぐことができるが、それではネットワーク・トラフィックが実際には少ないにもかかわらず新規の要求を受け付けることができない、すなわち、ネットワークのアドミッション制御機能によって再生が拒否される事態が発生する。そのため、最低帯域は１０Ｍｂｐｓより低くする、すなわち、いわゆるオーバーブッキングを認めるスケジューリングを前提とする。
【００９３】
図７は、本発明の第１の実施形態における、スタートアップ時間及びジッター・バッファの量と、定常帯域との関係を説明する図である。
【００９４】
図７におけるグラフ７０１は、受信アプリケーションの時刻と再生済の動画のデータ量との関係を表している。グラフ７０１は、ＶＢＲコーディングを前提としているため、受信アプリケーションの時刻と再生済の動画のデータ量との関係を表すグラフは直線にはならない。
【００９５】
図７におけるグラフ７０２は、通信計画案２における受信アプリケーションの時刻と送信される動画のデータ量との関係を示し、グラフ７０３は、通信計画案１における受信アプリケーションの時刻と送受信される動画のデータ量との関係を示している。通信計画案１、２において、送受信されるデータは、ＣＢＲにしたがって送受信されるので、グラフ７０２、７０３は直線で表される。
【００９６】
グラフ７０２、７０３の直線がグラフ７０１の太線より右側にでるとデータが不足して再生が停止するので、必ずグラフ７０２、７０３の直線がグラフ７０１の太線より左側にあるか、又は接していなければならない。そのため、バッファ・サイズを減少させるとその傾斜を大きくする必要がある。すなわち、定常帯域を増加させる必要が生じる。
【００９７】
図８は、本発明の第１の実施形態の通信計画データベース１１２が格納する内容の一例を示す図である。
【００９８】
通信計画データベース１１２は、ストリーミング・サーバ１２１が格納するすべてのコンテンツに対する通信計画案の原データ８００を格納する。
【００９９】
原データ８００は、ビデオ識別子８０１、サーバ・アドレス８０２、解像度８０３、及び通信計画案８０４を含む。
【０１００】
ビデオ識別子８０１は、動画を識別するための識別子である。サーバ・アドレス８０２は、ビデオ識別子８０１に対応するコンテンツを格納するストリーミング・サーバ１２１のＩＰアドレスを格納する。なお、同一のコンテンツを格納するストリーミング・サーバ１２１が複数ある場合、サーバ・アドレス８０２には、複数のストリーミング・サーバ１２１のＩＰアドレスが格納される。
【０１０１】
解像度８０３は、再生される動画の解像度を示す。つまり、ＱｏＥの条件が格納されている。通信計画案８０４は、最小バッファ量、定常帯域、及び最大帯域の３つ組からなる通信計画案が格納されている。なお、通信計画案８０４に格納されている通信計画案は、条件のよいものから順に並べられた状態で格納されている。例えば、図８に示す例では、左から順に、条件のよい通信計画が格納されている。
【０１０２】
原データ８００には、１つのビデオ識別子８０１に対して、低解像度と高解像度の２つのレコードを含む。図８に示す例では、原データ８００は、レコード８１１〜レコード８１８が含まれる。
【０１０３】
レコード８１４は、「ベニスに生きる」に対応するレコードであり、当該レコードの通信計画案８０４は、図６Ａ〜図６Ｃに示した３つの通信計画案１〜３にそれぞれ対応している。ここで、最小バッファ量は、受信側アプリケーションが持つべきジッター・バッファの量の最小値である。最小バッファ量をスタートアップ時間で割って算出されたものが初期帯域となる。例えば、最小バッファ量が「２０Ｍｂｉｔ」であり、スタートアップ時間を「０．５秒」とすると、ジッター・バッファを０．５秒間で満たすためには、初期帯域を「４０Ｍｂｐｓ」として送信する必要がある。したがって、スタートアップ時間が「０．５秒」のとき、レコード８１４の通信計画案８０４に含まれる（２０Ｍ、５Ｍ、５Ｍ）から（４０Ｍ、０．５秒、５Ｍ、５Ｍ）という通信計画案２が生成される。
【０１０４】
図９Ａ及び図９Ｂは、本発明の第１の実施形態の通信計画サーバ１１１の処理を説明するフローチャートである。
【０１０５】
図９Ａは、通信計画サーバ１１１が品質要求４０２を受信したときの処理手順９０１を示し、図９Ｂは、通信計画サーバ１１１が品質応答４０６を受信したときの処理手順９０２を示している。以下、各処理手順９０１、９０２について説明する。
【０１０６】
処理手順９０１では、まずステップ９１１において、品質要求４０２を受信した通信計画サーバ１１１は、「Ｌｌｉｆｅ ｉｎ ｖｅｎｉｃｅ」、などのビデオ識別子８０１と解像度８０３を検索キーとして、通信計画データベース１１２から通信計画案８０４のリストとサーバ・アドレス８０２とを読み出す。
【０１０７】
次に、ステップ９１２において、通信計画サーバ１１１は、読み出された通信計画案８０４に含まれる含む最小バッファ量と、品質要求４０２に含まれるスタートアップ時間から初期帯域を算出する。具体的には、最小バッファ量をスタートアップ時間で割って初期帯域が算出される。これによって、通信計画案が生成される。ステップ９１１において、図８のレコード８１４が読み出された場合、通信計画サーバ１１１は、図６Ａ〜図６Ｃに示す通信計画案１〜３を生成する。
【０１０８】
ステップ９１３において、通信計画サーバ１１１は、初期帯域、スタートアップ時間、定常帯域及び最大帯域から構成される通信計画案を含む品質要求４０３を管理サーバ１５２に送信し、処理を終了する。
【０１０９】
処理手順９０２では、ステップ９２１において、品質応答４０６を受信した通信計画サーバ１１１は、品質応答４０７を品質要求元（この場合は、コンピュータ１０１）に送信し、処理を終了する。
【０１１０】
図１０は、本発明の第１の実施形態の管理サーバ１５２の処理を説明するフローチャートである。
【０１１１】
品質要求４０３を受信した管理サーバ１５２は、処理手順１００１にしたがって処理を実行する。ステップ１０１１において、管理サーバ１５２は、品質要求４０３に含まれる通信計画案の中から最適なものを選択する。ここで、品質要求４０３に含まれる通信計画案のリストは、通信計画サーバ１１１が条件のよいものから順に並べたものである。管理サーバ１５２が品質要求４０３に含まれる通信計画案の中から最適なものを選択する方法は、様々のものが考えられる。以下、２つの方法を示す。
【０１１２】
まず、ステップ１０１１において実行される処理の第１の方法を説明する。通信計画案１、２のように最初の０．５秒を除いた通信量が、指定された帯域値を超えないトラフィックによってネットワークが占められている場合、管理サーバ１５２は、通信中のすべてのフローに関する帯域の総和を算出することによって、通信量をほぼ正確に予測することができる。したがって、算出された帯域の総和と通信計画案に含まれる初期帯域との和が、ネットワーク・インタフェース１３２に接続されたリンクの帯域より十分に少ない場合、例えば、該通信計画案の初期帯域の１０倍以上ある場合、該通信計画案が選択される。なお、１０倍以外の数値を用いてもよい。
【０１１３】
例えば、リンクの帯域が１Ｇｂｐｓであり、算出された総和が８００Ｍｂｐｓ以下である場合、初期帯域が「２０Ｍｂｐｓ」である通信計画案１を選択することができる。
【０１１４】
算出された定常帯域の総和がリンクの帯域を超えているときは、管理サーバ１５２は、次善の通信計画案を検討する。いずれの通信計画案も実行不能である場合、管理サーバ１５２は、要求を拒否する。すなわち、アドミッション制御によって動画ストリーミングが拒否される。
【０１１５】
次に、ステップ１０１１において実行される処理の第２の方法を説明する。通信計画案３のように、通信量が定常帯域（通信計画案３の場合は５Ｍｂｐｓ）を超えることがあり、どのタイミングで通信量が定常帯域を超えるかを管理サーバ１５２が予測できないトラフィックが存在する場合、管理サーバ１５２は、通信量の実測値を用いた予測値にしたがって制御する。
【０１１６】
通信量の実測のために、ＩＥＴＦの標準プロトコルであるＩＰＦＩＸ、ＩＰＦＩＸの前身であるＣｉｓｃｏ社開発のプロトコルであるＮｅｔＦｌｏｗ、又はＩｎＭｏｎ社開発のプロトコルであるＳＦｌｏｗを使用することができる。これらのプロトコルによって管理サーバ１５２は、エッジルータ１３１のネットワーク・インタフェース１３２におけるトラフィック量の統計を取得し、取得されたトラフィックの統計に基づいて使用されている帯域を算出することができる。
【０１１７】
管理サーバ１５２は、算出された実測値に基づいて、予測される帯域を求める。すなわち、管理サーバ１５２は、算出された実測値をそのまま予測値とする。当該予測値と通信計画案に含まれる最大帯域との和が、ネットワーク・インタフェース１３２に接続されたリンクの帯域より十分に少ない場合、例えば、該予測値がある通信計画案の初期帯域の２０倍以上ある場合、該通信計画案を選択する。なお、２０倍以外の数値を用いてもよい。
【０１１８】
例えば、リンクの帯域が１Ｇｂｐｓであり、算出された総和が６００Ｍｂｐｓ以下であれば、初期帯域が「２０Ｍｂｐｓ」である通信計画案１を選択することができる。
【０１１９】
算出された総和がリンクの帯域を超えているときは、管理サーバ１５２は、次善の通信計画案を検討する。いずれの通信計画案も実行不能である場合、管理サーバ１５２は、要求を拒否する。すなわち、アドミッション制御によって動画ストリーミングが拒否される。
【０１２０】
以下の説明では、ＮｅｔＦｌｏｗを使用してトラフィックが計測されることを前提とする。ＮｅｔＦｌｏｗを使用することによって、ルータ（この場合は、エッジルータ１３１、１４１）は、定期的に（例えば、１分おきに）、該ルータの特定のインタフェース（この場合は、ネットワーク・インタフェース１３２、１４２）におけるトラフィック量をトラフィックの種類ごとに管理サーバ１５２へ通知できる。前述の機能を使用することによって、管理サーバ１５２は、定期的にエッジルータ１３１のネットワーク・インタフェース１３２から出力されるトラフィックの帯域を算出できる。
【０１２１】
時刻ｔにおける、クラスｃに割り当てられた帯域Ｂｕ（ｃ）は、直前の時刻ｔ−１までの収集結果に基づいて、下式によって推定される。ただし、第１の実施形態では、一つのクラス（ストリーミング）に着目するため、以下ではｃを省略する。
（式１）Ｂｕ＝γ（１＋β）Ｂａ＋（１−α）Ｂｒ
予め定数として設定された総帯域Ｂｍ（当該のクラスに割り当てられた帯域)と（式１）によって推定されるＢｕとの差が割り当て可能な帯域であり、それらが新たな要求帯域以下であれば、割り当て可能である。
【０１２２】
（式１）において、Ｂａはトラフィック計測によって取得された帯域を示し、Ｂｒは個々のトラフィックごとの定常帯域又は最大帯域の和を示す。すなわち、スタートアップ時間の経過後、定常帯域を超えないトラフィックに関しては定常帯域が選択され、可変ビットレートにしたがうトラフィックに関しては最大帯域が選択される。
【０１２３】
コア・ネットワーク１５１において、ＤｉｆｆＳｅｒｖによるＱｏＳ制御を行っている場合、ＮｅｔＦｌｏｗからはトラフィック・クラス単位で集約された情報を取得されるが、取得された値は、下式によって指数的移動平均を算出することによって、平滑化している。
（式２）Ｂａ（ｔ）＝αｂａ（ｔ）＋（１−α）Ｂａ（ｔ−１）
ここで、ｂａは、ＮｅｔＦｌｏｗから取得された帯域の値である。このアドミッション制御法においては、調節されたα、β、及びγの３つのパラメタを使用する必要がある。ここで、パラメタは、以下のとおりである。
【０１２４】
αは、計測値平滑化係数と呼ばれ、トラフィック計測値の移動平均のなめらかさを制御するパラメタである。βは、帯域余裕率と呼ばれ、トラフィック計測値 (移動平均) に対するアドミッション制御の限界値のマージンを制御するパラメタである。γは、計測値寄与率と呼ばれ、アドミッション制御の限界値に関する測定値の寄与率（（１−γ）が宣言値の寄与率）である。
【０１２５】
（式１）によって、管理サーバ１５２は、ユーザ又はアプリケーションの要求に基づく帯域とトラフィック計測から算出した帯域との両方を考慮したアドミッション制御を行うことができる。その結果、ユーザ又はアプリケーションの要求に基づく帯域だけによって行われるアドミッション制御に比べると、定常帯域を超えるトラフィックが多くなっている場合、新規のセッションの開始が抑制され、既存のセッションのパケット損失及び遅延増加が抑制されるので、指定されたＱｏＥをより高い確率で実現することが可能になる。
【０１２６】
また、トラフィック計測から算出された帯域だけに基づいて行われるアドミッション制御に比べると、定常帯域を超えるトラフィックの数が増加したり、定常帯域からより大きくはずれるトラフィックが急に出現したりしても、予め最大帯域を加味してアドミッション制御が行われているために、既存のセッションのパケット損失及び遅延増加が発生する確率が低く抑えられる。以上がステップ１０１１において実行される処理の説明である。
【０１２７】
処理手順１００１の説明に戻る。
【０１２８】
ステップ１０１２において、管理サーバ１５２は、ステップ１０１１で選択された通信計画案における初期帯域を最大帯域としてストリーミング・サーバ１２１側のルータ、すなわち、エッジルータ１４１のネットワーク・インタフェース１４２に設定する。具体的には、管理サーバ１５２が、エッジルータ１４１に帯域制限設定４０４を送信する。図４に示す例において、管理サーバ１５２が通信計画２を選択している場合、送信者が「１０．１０．２２．１２」であり、受信者が「１０．１０．２１．１０」であるフローに対して、「４０Ｍｂｐｓ」の帯域制限がエッジルータ１４１に設定される。
【０１２９】
ステップ１０１３において、管理サーバ１５２は、ステップ１０１１で選択された通信計画案における定常帯域を最低保証帯域とするキューを、ユーザ側のルータ、すなわち、エッジルータ１３１のネットワーク・インタフェース１３２において、動画再生４０９における動画ストリーミング・トラフィックが、選択されたキューにはいるようにする。前述の操作を実現するため、具体的には次の手順にしたがう。
【０１３０】
第１に、コア・ネットワーク１５１の初期化時に管理サーバ１５２は、ユーザ側の出口インタフェース（この場合は、ネットワーク・インタフェース１３２）において、キューの初期設定を実行する。例えば、ネットワーク・インタフェース１３２において、必要な最低保証帯域が５Ｍｂｐｓ、７Ｍｂｐｓ、及び１０Ｍｂｐｓの３種類であり、最大３０個のキューを設定することができる場合、管理サーバ１５２は、次のようなキューを初期設定によって確保する。すなわち、管理サーバ１５２は、５Ｍｂｐｓのキューを１０個確保し、７Ｍｂｐｓのキューを１０個確保し、１０Ｍｂｐｓのキューを１０個確保する。確保されたキューは、要求があるまで使用されない。
【０１３１】
第２に、管理サーバは、ステップ１０１３において、選択された通信計画案によって指定された最低保証帯域をもつキューを、初期設定で確保されたキューの中から選択する。例えば、最低保証帯域として「５Ｍｂｐｓ」が指定された場合、初期設定によって確保された５Ｍｂｐｓのキューのひとつが割り当てられる。なお、指定された最低保証帯域に一致するキューが存在しない場合、指定された最低保証帯域より大きい最低保証帯域をもつキューが選択される。
【０１３２】
前述のように、予めキューを確保する代わり、要求時にキューの構成を変更し、新たなキューを割り当てる方法も考えられる。しかし、要求があるたびにキューの構成を変更すると、キューの構成の変更時にキューイングされるべきパケットが廃棄される可能性、又は、再構成のためにエッジルータ１３１に大きな負荷がかかる可能性がある。前述のように、予めキューを確保する方法は、キューの割り当て時にパケットが失われることがなく、またオーバヘッドが小さいという利点がある。
【０１３３】
ステップ１０１４において、管理サーバ１５２は、選択された通信計画案を含む品質応答４０６を通信計画サーバ１１１に送信し、処理を終了する。
【０１３４】
図１１は、本発明の第１の実施形態のストリーミング・サーバ１２１の処理を説明するフローチャートである。
【０１３５】
再生要求４０８を受信したストリーミング・サーバ１２１は、処理手順１１０１にしたがって処理を実行する。
【０１３６】
ステップ１１１１において、再生要求４０８を受信したストリーミング・サーバ１２１は、再生要求４０８に含まれる通信計画案における初期帯域で指定された時間にしたがって、動画のデータを送信する。例えば、再生要求４０８に通信計画案２が含まれている場合、指定された初期帯域は「４０Ｍｂｐｓ」であり、指定されたスタートアップ時間が「０．５秒」であるので、ストリーミング・サーバ１２１は、０．５秒間だけ４０Ｍｂｐｓの通信速度で動画のデータをコンピュータ１０１に送信する。
【０１３７】
ステップ１１１２において、ストリーミング・サーバ１２１は、指定された定常帯域、及び最大帯域にしたがって残りの動画のデータを送信する。指定された定常帯域及び最大帯域がともに「５Ｍｂｐｓ」である場合、ストリーミング・サーバ１２１は、５Ｍｂｐｓを超えない範囲で、かつ受信側アプリケーションのジッター・バッファがあふれないように動画のデータを送信する。
【０１３８】
ストリーミング・サーバ１２１は、各ストリーミング・コンテンツの再生において、再生開始後どの時刻にどれだけのデータを消費するかがわかる（実際に再生してみればわかるが、再生することは必須ではない）ので、受信側アプリケーションのジッター・バッファにバッファリングされたデータ量を推定することができる。ストリーミング・サーバ１２１は、当該推定に基づいて、ジッター・バッファがあふれないように動画のデータの送信を制御する。
【０１３９】
また、受信側アプリケーションにおいて動画が停止したり、再生速度が変化したりすることがある。このような場合、再生要求４０８とその応答に使用されるプロトコル、例えば、ＩＥＴＦ標準のプロトコルＲＴＳＰ（Ｒｅａｌ−Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）を使用するか、又は、動画のデータとその制御のためのプロトコル、例えば、ＩＥＴＦ標準のプロトコルＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）及びＲＴＣＰ（Ｒｅａｌ−Ｔｉｍｅ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）を使用することによって、現在、再生がどこまですすんでいるかをコンピュータ１０１からストリーミング・サーバ１２１に通知され、ストリーミング・サーバ１２１は通知された情報をジッター・バッファの制御のために使用することができる。
【０１４０】
図１２は、本発明の第１の実施形態において、ユーザが停止ボタン３１６を操作（クリック）したときのネットワークシステムにおける処理手順を説明するシーケンス図である。
【０１４１】
停止ボタン３１６が操作（クリック）されることによって発生した、ユーザによる停止要求１２０１は、コンピュータ１０１上で動作するＷｅｂブラウザが受け取る。コンピュータ１０１は、まず、ストリーミング・サーバ１２１に停止要求１２０２を送信して、ストリーミング・サーバ１２１からの動画のデータの送信を停止する。
【０１４２】
コンピュータ１０１は、続いて、品質要求１２０３を通信計画サーバ１１１に送信する。品質要求１２０３には、対応する要求を識別するために必要なビデオ識別子８０１が含まれる。
【０１４３】
品質要求１２０３を受信した通信計画サーバ１１１は、品質要求１２０４を管理サーバ１５２に送信する。品質要求１２０４には、品質要求１２０３の送信者、すなわち、コンピュータ１０１のＩＰアドレス「１０．１０．２１．１０」が含まれる。
【０１４４】
品質要求１２０４を受信した管理サーバ１５２は、品質応答１２０７、帯域制限設定解除１２０５、及びキューイング設定解除１２０６の３つのメッセージをそれぞれ送信する。具体的には、品質応答１２０７は、通信計画サーバ１１１に送信され、帯域制限設定解除１２０５は、エッジルータ１４１に送信され、キューイング設定解除１２０６は、エッジルータ１３１に送信される。また、帯域制限設定解除１２０５によって帯域制限設定４０４における設定が無効にされ、キューイング設定解除１２０６によってキューイング設定４０５における設定が無効にされる。
【０１４５】
品質応答１２０７を受信した通信計画サーバ１１１は、コンピュータ１０１に品質応答１２０８を送信する。なお、品質要求４０２及び品質要求４０３にタイムアウト時間が含まれる場合は、帯域制限設定解除１２０５及びキューイング設定解除１２０６は送信されない。
【０１４６】
次に、再生中に高解像度ボタン３１４又は低解像度ボタン３１３を操作（クリック）することによって生じる処理について説明する。
【０１４７】
再生中に高解像度ボタン３１４又は低解像度ボタン３１３が操作（クリック）された場合、コンピュータ１０１は、まず、再生中の動画を停止させる。前述の処理の手順は図１２に示すシーケンス図とほぼ同一であるが、停止要求１２０２の代わりに一時停止要求が送信される。
【０１４８】
一時停止要求を受信したストリーミング・サーバ１２１は、動画の再生を開始してから停止まで経過時刻を記憶し、解像度の異なる動画の再生を開始する。動画を再生する場合のシーケンスは、図４と同様であるが、再生要求４０８の代わりに再開要求が送信される。再開要求を受信したストリーミング・サーバ１２１は、記憶されている動画の再生を開始してから停止までの経過時刻に基づいて、一時停止されたところから動画の再生を開始する。これによって、ちょうど再生を停止したところから、解像度が異なる動画が再生される。
【０１４９】
なお、画質改善ボタン３１５が操作（クリック）された場合の処理は、図４と同様のシーケンスにしたがって処理が実行される。ただし、ユーザによる品質要求４０１は画質改善要求であり、また、品質要求４０２は解像度及びスタートアップ時間の代わりに「画質改善」を表す内容が含まれる。また、品質要求４０３において、すでに選択されていた通信計画案がＶＢＲによる計画であれば、ＣＢＲによる計画に変更する。管理サーバ１５２は、キューイング設定４０５において、品質改善要求による新たな通信計画案に適したキューを選択する。
【０１５０】
また、本実施形態において、最低保証帯域が確保できない場合、動画の再生は拒否され、再生することができない。ネットワークが輻輳していて、予め再生できないことが分かる場合、高解像度ボタン３１４を無効化、すなわち、操作（クリック）できないようにすることによって、ユーザが無駄な操作をしないようにすることができる（初期品質選択画面３１１においては、画質改善ボタン３１５と停止ボタン３１６とが無効化されている）。
【０１５１】
具体的には、初期品質選択画面３１１及び低解像度再生画面３２１を生成するときに、これらのＷｅｂページを通信計画サーバ１１１がＣＧＩによって生成するようにし、通信計画サーバ１１１が管理サーバ１５２に予め通信計画案の実現可否を問い合わせることによって、実現できないメニュー項目（ボタン）を無効化できる。なお、管理サーバ１５２は、予めトラフィックを計測し、計測結果に基づいて通信計画サーバ１１１に通信計画案の実現可否を応答することができる。
【０１５２】
さらに、初期品質選択画面３１１、低解像度再生画面３２１、及び高解像度再生画面３３１が表示された後に、ネットワークの状態が変化して、各画面３１１、３２１、３３１が表示されたときには実現可能だったメニュー項目が実現不可能になったり、逆に各画面３１１、３２１、３３１が表示されたときには実現不可能だったメニュー項目が実現可能になったりすることがある。
【０１５３】
前述のような場合に対処するには、表示された画面３１１、３２１、３３１を定期的にリフレッシュする、すなわち、その時点におけるメニュー項目の実現の可否を管理サーバ１５２に問い合わせ、これによって表示を更新することができる。以上が本発明の第１の実施形態の説明である。
【０１５４】
以下、本発明の第２の実施形態について説明する。
【０１５５】
図１３は、本発明の第２の実施形態における、ネットワークシステム構成を示すブロック図である。以下、第１の実施形態との差異を中心に説明する。
【０１５６】
図１との相違点は、ネットワーク上でコンピュータ１０１、１０２とエッジルータ１３１との間を接続するＨＧＷ（ホーム・ゲートウェイ）１３０１が備えられ、また、通信計画サーバ１１１がない代わりに、ＨＧＷ１３０１には計測制御サーバ１３０２が含まれる。その他の構成については図１と同一である。
【０１５７】
図１４Ａ及び図１４Ｂは、本発明の第２の実施形態における、ネットワークへの品質要求を入力するためのグラフィカル・ユーザ・インタフェース（ＧＵＩ）を説明する図である。図１４Ａ及び図１４Ｂに示す例では、特定のアプリケーションに限定していない場合における品質要求を入力するためのＧＵＩである。
【０１５８】
図１４Ａに示す品質メニュー１４０１には、品質改善ボタン１４０２、及びキャンセル・ボタン１４０３が表示されている。使用中の任意のアプリケーションにおいて、品質の改善を希望する場合、ユーザは品質改善ボタン１４０２を操作（クリック）する。また、すでに要求された品質改善をキャンセルしたい場合、ユーザは、キャンセル・ボタン１４０３を操作（クリック）する。
【０１５９】
図１４Ｂに示す品質メニュー１４１１には音質改善ボタン１４１２、画質改善ボタン１４１３、Ｗｅｂ高速化ボタン１４１４、及びキャンセル・ボタン１４１５が表示されている。具体的には、再生中の任意のアプリケーションにおいて、音質の改善を希望する場合、ユーザは音質改善ボタン１４１２を操作（クリック）する。また、再生中の任意のアプリケーションにおいて、画質の改善を希望する場合、ユーザは画質改善ボタン１４１３を操作（クリック）する。また、ユーザがＷｅｂブラウザ又はＷｅｂサービスを使用し、これらの応答の改善を希望する場合、ユーザはＷｅｂ高速化ボタン１４１４を操作（クリック）する。また、すでに要求された品質改善をキャンセルしたい場合、ユーザは、キャンセル・ボタン１４１５を操作（クリック）する。
【０１６０】
本実施形態では、コア・ネットワーク１５１におけるＱｏＳ保証のためにＤｉｆｆＳｅｒｖを使用していることを前提とする。コア・ネットワーク１５１におけるトラフィックは、会話クラス、ストリーミング・クラス、Ｗｅｂクラス、及びベストエフォート・クラスにクラス分けされ、クラスごとにエッジルータ１３１、１４１のキューなどの資源が割り当てられる。
【０１６１】
例えば、エッジルータ１３１のネットワーク・インタフェース１３２において、会話クラスに高優先度キューが割り当てられ、他のトラフィックには複数の低優先度キュー同士で帯域が分割される。すなわち、いわゆるＬＬＱ（Ｌｏｗ Ｌａｔｅｎｃｙ Ｑｕｅｕｅｉｎｇ）が適用される。
【０１６２】
これによって、ストリーミング・クラス、Ｗｅｂクラス、及びベストエフォート・クラスには、それぞれ最低保証帯域が設定される。また、会話クラスが他のクラスを圧迫することがないように、会話クラスのトラフィックに対しては最大帯域が決定され、最大帯域を超えないようにアドミッション制御が行われる。なお、会話クラスのように優先的な処理を必要とするトラフィックが存在しない場合、ＬＬＱの代わりのＷＦＱだけからなるスケジューリングを指定すればよい。
【０１６３】
図１５は、本発明の第２の実施形態において、ユーザが任意のアプリケーションの使用中に、品質改善ボタン１４０２、音質改善ボタン１４１２、画質改善ボタン１４１３、Ｗｅｂ高速化ボタン１４１４、又はキャンセル・ボタン１４１５を操作したときのネットワークシステムにおける処理手順を示すシーケンス図である。
【０１６４】
ユーザによる品質要求１５０１は、各ボタン（品質改善ボタン１４０２、音質改善ボタン１４１２、画質改善ボタン１４１３、Ｗｅｂ高速化ボタン１４１４、及びキャンセル・ボタン１４１５）のいずれかを操作（クリック）することによって発生し、そのイベントをコンピュータ１０１上で動作するＷｅｂブラウザが受信する。
【０１６５】
ユーザによる品質要求１５０１を受信したコンピュータ１０１は、計測制御サーバ１３０２に品質要求１５０２を送信する。品質要求１５０２には、操作（クリック）されたボタンに対応するメディアの種類とＱｏＥ情報とが含まれる。
【０１６６】
品質要求１５０２に含まれるメディアの種類は、品質改善ボタン１４０２が操作（クリック）された場合、不明であることを示す値が含まれるか、又はメディアの種類が省略される。また、音質改善ボタン１４１２が操作（クリック）された場合、メディアの種類は「音声」である。画質改善ボタン１４１３が操作（クリック）された場合、メディアの種類は「動画」である。「画質」は、静止画を示す可能性もあるが、ここでは動画サービスを行っていることを前提とし、動画の画質であることを仮定する。Ｗｅｂ高速化ボタン１４１４が操作（クリック）された場合、メディアの種類は「Ｗｅｂ」である。
【０１６７】
品質改善ボタン１４０２、音質改善ボタン１４１２、又は画質改善ボタン１４１３が操作（クリック）された場合、品質要求１５０２に含まれるＱｏＥ情報は、「高品質」である。Ｗｅｂ高速化ボタン１４１４が操作（クリック）された場合、品質要求１５０２に含まれるＱｏＥ情報は、「高速応答」である。
【０１６８】
品質要求１５０２を受信した計測制御サーバ１３０２は、図１６に示す手順にしたがって処理を実行する。つまり、計測制御サーバ１３０２は、品質要求１５０２に含まれる内容に基づいて、品質要求１５０３を生成し、生成された品質要求１５０３を管理サーバ１５２に送信する。
【０１６９】
具体的には、計測制御サーバ１３０２は、ＨＧＷ１３０１が計測したトラフィック計測情報を用い、品質要求１５０２に含まれるメディアの種類から、対応するＤｉｆｆＳｅｒｖのトラフィック・クラスを特定し、特定されたトラフィック・クラスを品質要求１５０３に含める。また、品質要求１５０２に含まれるＱｏＥ情報とＨＧＷ１３０１が計測したトラフィック計測情報とに基づいて保証するべき帯域を算出し、算出された帯域を品質要求１５０３に含める。さらに、計測制御サーバ１３０２は、品質要求１５０２の送信者、すなわち、コンピュータ１０１のＩＰアドレス「１０．１０．２１．１０」も品質要求１５０３に含める。
【０１７０】
品質要求１５０３を受信した管理サーバ１５２は、図１７に示す手順にしたがって処理をする。具体的には、管理サーバ１５２は、エッジルータ１３１にキューイング設定１５０４を送信し、また、計測制御サーバ１３０２に品質応答１５０５を送信する。品質応答１５０５には、確保された帯域の値が含まれる。キューイング設定１５０４には、エッジルータ１３１においてキューを設定するための情報が含まれる。
【０１７１】
キューイング設定１５０４によって、コンピュータ１０１へ送信され、キューイング設定１５０４において指定されたクラスのトラフィックに関して、キューイング設定１５０４において指定された帯域を最低保証帯域として持つキューが使用されるように、エッジルータ１３１のネットワーク・インタフェース１３２が設定される。
【０１７２】
これによって、ユーザが音質改善を要求した場合、その時点で使用していた会話音声又はストリーミング音声に対して帯域が確保されることによって、音質が改善される。また、ユーザが画質改善を要求した場合、その時点で使用していた会話動画又はストリーミング動画に対して帯域が確保されることによって画質が改善される。
【０１７３】
また、ユーザがＷｅｂ高速化を要求した場合、Ｗｅｂトラフィックに対して帯域が確保されることによって、応答速度が改善される。
【０１７４】
品質応答１５０５を受信した計測制御サーバ１３０２は、コンピュータ１０１に品質応答１５０６を送信する。品質応答１５０６には、品質応答１５０５と同様に、確保された帯域の値が含まれる。
【０１７５】
次に、ＨＧＷ１３０１が実行するトラフィック計測について説明する。
【０１７６】
ＨＧＷ１３０１は、ＨＧＷ１３０１を通過するパケットを監視し、通過するパケットがＵＤＰパケットであれば、さらにＲＴＰパケットであるか否かを判定する。
【０１７７】
ＲＴＰパケットであると判定された場合、ＨＧＷ１３０１は、さらに、該パケットが、ＩＥＴＦ標準若しくはデファクト標準における音声コーデックを使用しているか、又は動画コーデックを使用しているかを判定し、音声コーデックを使用していると判定されたパケットを音声パケット分類し、動画コーデックを使用していると判定されたパケットを動画パケットに分類する。
【０１７８】
また、ＨＧＷ１３０１は、ＴＣＰパケットに関してはＨＴＴＰパケットであるか否かを判定し、ＨＴＴＰパケットと判定されたパケットをＷｅｂパケットに分類する。音声パケット、動画パケット、又はＷｅｂパケットのいずれでもないパケットは、それ以外のパケットに分類される。ＨＧＷ１３０１は、トラフィック計測によって、前述のような４種類のパケットに分類する。
【０１７９】
ＨＧＷ１３０１は、前述の各種類のパケットについて、さらに、ＩＰパケットに含まれルＤＳＣＰ（ＤｉｆｆＳｅｒｖ Ｃｏｄｅ Ｐｏｉｎｔ）ごとに、エッジルータ１３１からコンピュータ１０１に向かうパケットのデータ量をカウントし、トラフィック量を計測する。
【０１８０】
会話に関してはＤｉｆｆＳｅｒｖのＥＦＰＨＢ（ＥｘｐｅｄｉｔｅｄＦｏｒｗａｒｄｉｎｇＰｅｒ−Ｈｏｐ−Ｂｅｈａｖｉｏｒ）を使用し、ストリーミングに関してはＡＦ３ＰＨＢ（ＡｓｓｕｒｅｄＦｏｒｗａｒｄｉｎｇ３Ｐｅｒ−Ｈｏｐ−Ｂｅｈａｖｉｏｒ）を使用していると仮定する。すなわち、会話とストリーミングとをＤＳＣＰによって区別することができる。
【０１８１】
これによって、音声、動画、Ｗｅｂ及びその他のトラフィックのＨＧＷ１３０１におけるトラフィックの種類ごとの使用帯域を算出できる。ＨＧＷ１３０１において、パケット損失が発生していなければ、算出された使用帯域はネットワーク・インタフェース１３２における使用帯域と等しい。
【０１８２】
以上の説明したトラフィック計測法では、ＨＧＷ１３０１がトラフィックを計測することを前提としていたが、トラフィック計測をエッジルータ１３１が行うことも可能である。すなわち、計測制御サーバ１３０２は、エッジルータ１３１からＩＰＦＩＸ、ＮｅｔＦｌｏｗ、又はＳＦｌｏｗなどのプロトコルを使用してネットワーク・インタフェース１３２におけるトラフィック計測情報を受信し、受信したトラフィック計測情報に基づいて、ネットワーク・インタフェース１３２における出力トラフィックの帯域をトラフィックの種類ごとに算出する。
【０１８３】
ただし、ルータは、基本的にはＩＰ層において動作するので、ＲＴＰパケットの解析機能を備えていないことが多い。そのため、ルータは、会話かストリーミングか否かはＤＳＣＰによって区別することができるが、前述の方法では、音声か動画かを区別することができない。したがって、パケット・サイズから音声か動画かを推定する（音声パケットは比較的小さく、数１００バイト以下、プロトコルによってはほとんど１００バイト以下である）などの方法をとる必要がある。
【０１８４】
このように、エッジルータ１３１がトラフィック計測を行う場合、ＨＧＷ１３０１は、必ずしも必要ない。計測制御サーバ１３０２は、ＨＧＷ１３０１から独立に存在することも可能であり、例えば、管理サーバ１５２に含めることも可能である。計測制御サーバ１３０２が管理サーバ１５２に含まれる場合、品質要求１５０３及び品質応答１５０５は、プログラム内の関数呼び出しと、そこからの復帰によって実現することができる。
【０１８５】
図１６Ａ及び図１６Ｂは、本発明の第２の実施形態の計測制御サーバ１３０２の処理を説明するフローチャートである。
【０１８６】
図１６Ａは、品質要求１５０２を受信したときの処理手順１６０１を示し、図１６Ｂは、品質応答１５０６を受信したときの処理手順１６２１を示している。以下、処理手順１６０１、１６２１について説明する。
【０１８７】
処理手順１６０１では、まずステップ１６１１において、計測制御サーバ１３０２は、品質要求１５０２に含まれるメディアの種類からトラフィック・クラスの候補を求める。例えば、メディアの種類が「音声」又は「動画」である場合、トラフィック・クラスは、会話又はストリーミングである。
【０１８８】
ステップ１６１２において、計測制御サーバ１３０２は、メディアの種類とトラフィック・クラス候補とのすべての組について、トラフィック計測結果を求める。
【０１８９】
ステップ１６１３において、計測制御サーバ１３０２は、トラフィック計測結果に基づいて、品質劣化があるトラフィック・クラスを特定する。
【０１９０】
具体的には、メディアの種類が「音声」の場合、次のように判定される。計測制御サーバ１３０２は、音声と動画とをあわせた会話のトラフィックが、該トラフィックに対して割り当てられている帯域と比べて余裕があるか、又は、割り当て帯域が逼迫しているかを判定する。また、計測制御サーバ１３０２は、音声と動画とをあわせたストリーミングのトラフィックが、該トラフィックに対して割り当てられている帯域と比べて余裕があるか、又は、割り当て帯域が逼迫しているかを判定する。
【０１９１】
会話のトラフィックのほうがもっとも輻輳している場合、計測制御サーバ１３０２は、会話音声が品質劣化のあるトラフィック・クラスであると特定する。ストリーミングのトラフィックのほうがもっとも輻輳している場合、計測制御サーバ１３０２は、ストリーミング音声が品質劣化のあるトラフィック・クラスを特定する。
【０１９２】
また、メディアの種類が「動画」の場合においても、会話のトラフィックのほうがもっとも輻輳している場合、計測制御サーバ１３０２は、会話動画が品質劣化のあるトラフィック・クラスであると特定する。ストリーミングのトラフィックのほうがもっとも輻輳している場合、ストリーミング動画が品質劣化のあるトラフィック・クラスであると特定する。
【０１９３】
ここで、複数のクラスのうちのいずれがもっとも輻輳しているかは、次に示す３つの方法のいずれかを用いることによって判定することができる。
【０１９４】
第１の方法は、任意のクラスのすべてのトラフィックが使用する総帯域が、許容されている帯域に対して占める割合が大きいほうを、より輻輳していると判定する。
【０１９５】
第２の方法は、パケット損失を計測することによって、パケット損失が大きいクラスを、より輻輳していると判定する。ＲＴＰのフローのようにパケットがシーケンス番号を含むＵＤＰフローにおいては、パケット損失がある場合、シーケンス番号がとびとびになるため、これによってパケット損失率を求めることができる。
【０１９６】
第３の方法は、遅延を計測することによって、遅延が大きいクラスを、より輻輳していると判定する。ＲＴＰとＲＴＣＰによって構成される音声及び動画のフローのようにパケットにタイムスタンプが含まれる場合、送信側のコンピュータ１０１、すなわち、ストリーミングであれば、ストリーミング・サーバ１２１とＨＧＷ１３０１との時計をＩＥＴＦ標準のプロトコルであるＮＴＰ（Ｎｅｔｗｏｒｋ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）を用いて同期させることによって、遅延を計測することができる。
【０１９７】
ステップ１６１４において、計測制御サーバ１３０２は、品質保証のために必要な帯域を推定する。すなわち、計測制御サーバ１３０２は、品質劣化があると特定されたトラフィック・クラスに関して、現在使用されている帯域の２倍の帯域を保証帯域とする。例えば、品質劣化しているのが動画ストリーミングであり平均で「３Ｍｂｐｓ」の帯域を使用している場合、動画ストリーミングに対して「６Ｍｂｐｓ」を保証帯域として割り当てる。
【０１９８】
ステップ１６１５において、計測制御サーバ１３０２は、管理サーバ１５２に、前述の処理によって決定された内容が含まれる品質要求１５０３を送信し、処理を終了する。
【０１９９】
処理手順１６２１では、ステップ１６２２において、品質応答１５０５を受信した計測制御サーバ１３０２は、品質応答１５０６を品質要求元であるコンピュータ１０１に送信し、処理を終了する。
【０２００】
図１７は、本発明の第２の実施形態の管理サーバ１５２の処理を説明するフローチャートである。管理サーバ１５２は、処理手順１７０１にしたがって処理を実行する。
【０２０１】
ステップ１７０２において、品質要求１５０３を受信した管理サーバ１５２は、ユーザ側ルータ、つまり、エッジルータ１３１にキューイング設定１５０４を送信することによって、エッジルータ１３１の出口に、該キューイング設定１５０４において指定された帯域を最低保証帯域として設定する。
【０２０２】
ステップ１５０３において、管理サーバ１５２は、計測制御サーバ１３０２に品質応答１５０５を送信する。品質要求１５０３において指定された帯域が確保された場合、品質応答１５０５として許可を表すメッセージが計測制御サーバ１３０２に送信され、品質要求１５０３において指定された帯域が確保されない場合、品質応答１５０５として拒否を表すメッセージが計測制御サーバ１３０２に送信される。
【０２０３】
次に、キャンセル・ボタン１４０３、１４１５が操作（クリック）されたときの処理について説明する。キャンセル・ボタン１４０３、１４１５が操作（クリック）された場合における通信シーケンスは図１５と同様である。ただし、ユーザによる品質要求１５０１はキャンセル要求であり、キューイング設定１５０４はキューイング設定を解除する要求である。これによって、ネットワークの設定は、品質改善ボタン１４０２などの要求ボタンが操作（クリック）される前の状態に戻る。
【０２０４】
品質改善ボタン１４０２、音質改善ボタン１４１２、画質改善ボタン１４１３、又はＷｅｂ高速化ボタン１４１４は、各ボタンに対応する品質を改善するために必要なネットワーク資源が確保されないときには効果がない。前述のような場合に、ユーザの無駄な入力を避けるために、次のようにすればよい。
【０２０５】
計測制御サーバ１３０２は、ＣＧＩを使用してコンピュータ１０１に品質メニュー１４０１又は１４１１を表示する。そのときに、計測制御サーバ１３０２は、管理サーバ１５２に、品質メニュー１４０１又は１４１１上に表示された各品質改善のためのボタンを操作（クリック）することによって、品質改善が可能か否かを問い合わせる。管理サーバ１５２から品質の改善が不能であると応答があった場合、計測制御サーバ１３０２は、対応するボタンを無効化する。計測制御サーバ１３０２は、管理サーバ１５２に問い合わせてページをリフレッシュすることによって、最新の状況をコンピュータ１０１に表示することができる。
【０２０６】
また、品質メニュー１４０１又は１４１１に表示された各品質改善のためボタンを操作（クリック）することによって得られた効果は、ユーザに分かりにくいため、品質メニュー１４０１及び１４１１の下部にメッセージ表示欄を設けて、管理サーバ１５２からフィードバックされる結果を計測制御サーバ１３０２が解釈してコンピュータ１０１に表示することができる。管理サーバ１５２からの応答と計測制御サーバ１３０２の処理内容とに応じて、コンピュータ１０１に次のような内容を表示することができる。
【０２０７】
第１に、計測制御サーバ１３０２が品質劣化の原因として会話音声を特定した場合、管理サーバ１５２から許可の応答があれば、前述したメッセージ表示欄に「会話の音質改善に成功しました」と表示される。また、管理サーバ１５２から拒否の応答があれば、前述したメッセージ表示欄に「会話の音質改善に失敗しました」と表示される。
【０２０８】
第２に、計測制御サーバ１３０２が品質劣化の原因としてストリーミング音声を特定した場合、管理サーバ１５２から許可の応答があれば、前述したメッセージ表示欄に「ストリーミングの音質改善に成功しました」と表示される。管理サーバ１５２から拒否の応答があれば、前述したメッセージ表示欄に「ストリーミングの音質改善に失敗しました」と表示される。
【０２０９】
第３に、計測制御サーバ１３０２が品質劣化の原因として会話動画を特定した場合、管理サーバ１５２から許可の応答があれば、前述したメッセージ表示欄に「会話の画質改善に成功しました」と表示される。管理サーバ１５２から拒否の応答があれば、前述したメッセージ表示欄に「会話の画質改善に失敗しました」と表示される。
【０２１０】
第４に、計測制御サーバ１３０２が品質劣化の原因としてストリーミング動画を特定した場合、管理サーバ１５２から許可の応答があれば、前述したメッセージ表示欄に「ストリーミングの画質改善に成功しました」と表示される。管理サーバ１５２から拒否の応答があれば、前述したメッセージ表示欄に「ストリーミングの画質改善に失敗しました」と表示される。
【図面の簡単な説明】
【０２１１】
【図１】本発明の第１の実施の形態における、ネットワークシステム構成を示すブロック図である。
【図２Ａ】本発明の第１の実施形態における通信計画サーバのハードウェア構成を説明するブロック図である。
【図２Ｂ】本発明の第１の実施形態におけるストリーミング・サーバのハードウェア構成を説明するブロック図である。
【図２Ｃ】本発明の第１の実施形態における管理サーバのハードウェア構成を説明するブロック図である。
【図３Ａ】本発明の第１の実施形態における、コンテンツ選択のためのグラフィカル・ユーザ・インタフェース（ＧＵＩ）を説明する図である。
【図３Ｂ】本発明の第１の実施形態における、初期品質を選択するためのグラフィカル・ユーザ・インタフェース（ＧＵＩ）を説明する図である。
【図３Ｃ】本発明の第１の実施形態における、低解像度を選択した場合のグラフィカル・ユーザ・インタフェース（ＧＵＩ）を説明する図である。
【図３Ｄ】本発明の第１の実施形態における、高解像度を選択した場合のグラフィカル・ユーザ・インタフェース（ＧＵＩ）を説明する図である。
【図４】本発明の第１の実施形態において、ユーザがセッション開始時又はセッション継続中に、低解像度ボタン又は高解像度ボタンを操作したときのネットワークシステムにおける処理手順を示すシーケンス図である。
【図５】本発明の第１の実施形態において、ユーザがセッション開始時又はセッション継続中に、低解像度ボタン又は高解像度ボタンを操作したときのネットワークシステムにおける処理手順の変形例示すシーケンス図である。
【図６Ａ】本発明の第１の実施形態における通信計画案１を説明する図である。
【図６Ｂ】本発明の第１の実施形態における通信計画案２を説明する図である。
【図６Ｃ】本発明の第１の実施形態における通信計画案３を説明する図である。
【図７】本発明の第１の実施形態における、スタートアップ時間及びジッター・バッファの量と、定常帯域との関係を説明する図である。
【図８】本発明の第１の実施形態の通信計画データベースが格納する内容の一例を示す図である。
【図９Ａ】本発明の第１の実施形態の通信計画サーバの処理を説明するフローチャートである。
【図９Ｂ】本発明の第１の実施形態の通信計画サーバの処理を説明するフローチャートである。
【図１０】本発明の第１の実施形態の管理サーバの処理を説明するフローチャートである。
【図１１】本発明の第１の実施形態のストリーミング・サーバの処理を説明するフローチャートである。
【図１２】本発明の第１の実施形態において、ユーザが停止ボタンを操作（クリック）したときのネットワークシステムにおける処理手順を説明するシーケンス図である。
【図１３】本発明の第２の実施形態における、ネットワークシステム構成を示すブロック図である。
【図１４Ａ】本発明の第２の実施形態における、ネットワークへの品質要求を入力するためのグラフィカル・ユーザ・インタフェース（ＧＵＩ）を説明する図である。
【図１４Ｂ】本発明の第２の実施形態における、ネットワークへの品質要求を入力するためのグラフィカル・ユーザ・インタフェース（ＧＵＩ）を説明する図である。
【図１５】本発明の第２の実施形態において、ユーザが任意のアプリケーションの使用中に、品質改善ボタン、音質改善ボタン、画質改善ボタン、Ｗｅｂ高速化ボタン、又はキャンセル・ボタンを操作したときのネットワークシステムにおける処理手順を示すシーケンス図である。
【図１６Ａ】本発明の第２の実施形態の計測制御サーバの処理を説明するフローチャートである。
【図１６Ｂ】本発明の第２の実施形態の計測制御サーバの処理を説明するフローチャートである。
【図１７】本発明の第２の実施形態の管理サーバの処理を説明するフローチャートである。
【符号の説明】
【０２１２】
１０１、１０２ コンピュータ
１１１ 通信計画サーバ
１１２ 通信計画データベース
１２１ ストリーミング・サーバ
１２２ コンテンツ
１３１ エッジルータ
１３２ ネットワーク・インタフェース
１４１ エッジルータ
１４２ ネットワーク・インタフェース
１５１ コア・ネットワーク
１５２ 管理サーバ
１５３ 帯域管理テーブル
２００ ＣＰＵ
２０１ 主記憶装置
２０２ 二次記憶装置
２０３ ネットワーク・インタフェース
２１０ ＣＰＵ
２１１ 主記憶装置
２１２ 二次記憶装置
２１３ ネットワーク・インタフェース
２２０ ＣＰＵ
２２１ 主記憶装置
２２２ 二次記憶装置
２２３ ネットワーク・インタフェース
３０１ コンテンツ選択画面
３１１ 初期品質選択画面
３１３ 低解像度ボタン
３１４ 高解像度ボタン
３１５ 画質改善ボタン
３１６ 停止ボタン
３２１ 低解像度再生画面
３２２ 再生画面
３３１ 高解像度再生画面
３３２ 再生画面
７０１〜７０３ グラフ
８００ 原データ
８０１ ビデオ識別子
８０２ サーバ・アドレス
８０３ 解像度
８０４ 通信計画案
８１１〜８１８ レコード
１３０１ ＨＧＷ
１３０２ 計測制御サーバ
１４０１ 品質メニュー
１４０２ 品質改善ボタン
１４０３ キャンセル・ボタン
１４１１ 品質メニュー
１４１２ 音質改善ボタン
１４１３ 画質改善ボタン
１４１４ Ｗｅｂ高速化ボタン
１４１５ キャンセル・ボタン
【特許請求の範囲】
【請求項１】
計算機と、ネットワークノードと、前記計算機上で実行されるアプリケーションに必要なデータを前記計算機に送信するアプリケーションサーバと、前記計算機と前記アプリケーションサーバとの間の通信の計画を管理する通信計画サーバと、前記計算機、前記ネットワークノード及び前記アプリケーションサーバが接続されたネットワークを管理する管理サーバとを備えるネットワークシステムであって、
前記アプリケーションサーバは、第１のプロセッサ、前記第１のプロセッサと接続されている第１のメモリ、前記第１のプロセッサと接続されている第１の不揮発性記憶媒体、前記ネットワークと接続される第１のネットワークインタフェースを備え、
前記通信計画サーバは、第２のプロセッサ、前記第２のプロセッサと接続されている第２の記憶媒体、前記ネットワークと接続される第２のネットワークインタフェースを備え、
前記管理サーバは、第３のプロセッサ、前記第３のプロセッサと接続されている第３のメモリ、前記第３のプロセッサと接続されている第３の不揮発性記憶媒体、前記ネットワークと接続される第３のネットワークインタフェースを備え、
前記通信計画サーバは、
前記アプリケーションサーバが格納するデータに対する、前記ネットワークにおいて提供されるサービスの品質を決定する通信条件を前記第２の記憶媒体に格納し、
前記計算機から、前記計算機上で実行されるアプリケーションの品質に対する前記計算機のユーザによる要求である第１の品質条件を受信した場合、前記受信した第１の品質条件を実現するための、複数の前記通信条件を前記管理サーバに送信し、
前記管理サーバは、
前記通信計画案を受信した場合、前記受信した複数の通信条件の中から最適な前記通信条件を選択し、
前記選択された通信条件を含む品質応答を前記アプリケーションサーバに送信し、
前記アプリケーションサーバは、前記品質応答に含まれる前記通信条件にしたがって、前記計算機上で実行されるアプリケーションに必要なデータを前記計算機に送信することを特徴とするネットワークシステム。
【請求項２】
前記計算機上で実行されるアプリケーションに必要なデータは、ストリーミングデータであり、
前記通信条件は、
前記アプリケーションの実行中に送信される前記データの送信量を示す定常帯域と、
前記定常帯域より大きく、前記アプリケーションの開始時に送信される前記データの送信量を示す初期帯域と、
前記初期帯域によって示された送信量にしたがって前記計算機に前記データが送信される時間幅を示す初期時間とを含み、
前記複数の通信条件は、前記第１の品質条件を実現するために最適な順番に並べられており、
前記管理サーバは、
現在接続されている全ての通信の帯域の総和を算出し、
前記算出された帯域の総和及び前記通信条件に含まれる初期帯域の和と、前記ネットワークノードにおいて許容されている総帯域とを比較し、
前記算出された帯域の総和及び前記通信条件に含まれる初期帯域の和が、前記ネットワークノードにおいて許容されている総帯域より小さい場合、当該通信条件を最適な条件として選択することを特徴とする請求項１に記載のネットワークシステム。
【請求項３】
前記ストリーミングサーバは、
前記管理サーバによって決定された前記通信条件を受信し、
前記受信した通信条件に含まれる初期時間に示された時間幅で、前記受信した通信条件に含まれる初期帯域に示された送信量にしたがって前記データを送信し、
前記受信した通信条件に含まれる初期時間が経過した後、前記通信条件に含まれる定常帯域に示された送信量にしたがって前記データを送信することを特徴とする請求項２に記載のネットワークシステム。
【請求項４】
前記通信条件は、さらに、前記選択された通信条件によるネットワークシステムの設定の有効時間を示すタイムアウト時間を含むことを特徴とする請求項２に記載のネットワークシステム。
【請求項５】
前記タイムアウト時間が経過する前に、前記通信計画サーバが、前記計算機から前記第１の品質条件と同一の内容である第２の品質条件を受信した場合、前記タイムアウト時間のカウントは初期化され、前記第２の品質条件を受信した時刻から新たに前記タイムアウト時間のカウントが開始されることを特徴とする請求項４に記載のネットワークシステム。
【請求項６】
前記計算機上で実行されるアプリケーションに必要なデータは、ストリーミングデータであり、
前記通信条件は、
前記アプリケーションが実行されているときに送信される前記データの送信量を示す定常帯域と、
前記アプリケーションが実行されているときに送信される前記データの最大許容送信量を示す最大帯域とを含み、
前記管理サーバは、
現在接続されている全ての通信の帯域から予測帯域の総和を算出し、
前記算出された予測帯域の総和及び前記通信計画に含まれる前記最大帯域の和と、前記ネットワークノードにおいて許容されている総帯域とを比較し、
前記算出された予測帯域の総和及び前記通信計画に含まれる前記最大帯域の和が、前記ネットワークノードにおいて許容されている総帯域より小さい場合、当該通信条件を最適な条件として選択することを特徴とする請求項１に記載のネットワークシステム。
【請求項７】
前記ストリーミングサーバは、
前記管理サーバによって決定された前記通信条件を受信し、
前記受信した通信条件に含まれる定常帯域及び前記最大帯域によって指定された可変ビットレート通信によって、前記データを送信することを特徴とする請求項６に記載のネットワークシステム。
【請求項８】
前記計算機から送信される前記第１の品質要求は、前記管理サーバを経由して前記通信計画サーバに送信され、
前記通信計画サーバは、前記第１の品質要求に対する前記品質応答に前記複数の通信条件を含めて、前記計算機に送信し、
前記品質応答は、前記管理サーバを経由して前記通信計画サーバに送信され、
前記管理サーバは、前記品質応答を前記計算機に転送する場合に、
前記品質応答に含まれる前記複数の通信条件の中から最適な前記通信条件を選択し、
前記選択された通信条件が含まれた前記品質応答を前記計算機に転送することを特徴とする請求項１に記載のネットワークシステム。
【請求項９】
前記通信計画サーバは、前記管理サーバに前記複数の通信条件を送信する場合に、前記複数の通信条件の中から前記第１の品質条件を最適に実現することができる前記通信条件を選択し、
前記選択された通信条件を前記管理サーバに送信し、
前記管理サーバは、
受信した前記通信条件が最適か否かを判定し、
最適でないと判定された場合、前記通信計画サーバに前記受信した通信条件が最適でないことを示す拒否応答を送信し、
前記通信計画サーバは、前記拒否応答を受信した場合、次に最適に前記第１の品質条件を実現できる前記通信条件を選択し、該通信条件を前記管理サーバに送信することを特徴とする請求項２又は８に記載のネットワークシステム。
【請求項１０】
前記通信計画サーバは、前記管理サーバに前記複数の通信条件を送信する場合に、前記複数の通信条件を一括して送信することを特徴とする請求項１に記載のネットワークシステム。
【請求項１１】
前記通信計画サーバは、前記管理サーバに前記複数の通信条件を送信する場合に、前記通信計画サーバによって決定されたパラメタと条件式とによって決定される、前記複数の通信条件を送信することを特徴とする請求項１に記載のネットワークシステム。
【請求項１２】
前記ネットワークノードは、前記ネットワークノードの出力インタフェースにおいて、複数の異なる保証帯域を持つキューを割り当て、
前記管理サーバは、
前記選択された通信条件を実現するために必要な保証帯域を持つキューを、前記ネットワークノードの前記キューから選択し、
前記ネットワークノードから前記計算機に送信される前記データが、前記選択されたキューに入るように前記ネットワークノードのキューイング設定を実行することを特徴とする請求項１に記載のネットワークシステム。
【請求項１３】
前記複数の異なる保証帯域を持つキューは、第１のキューと第２のキューとを含み、
前記第１のキューは、前記第２のキューより大きい保証帯域を持ち、
前記選択された通信条件を実現するために必要な保証帯域を持つキューが、前記第１のキューが持つ保証帯域以下、かつ、前記第２のキューが持つ保証帯域より大きい場合、前記第１のキューから、前記選択された通信条件を実現するために必要な保証帯域を持つキューを選択し、
前記選択された通信条件を実現するために必要な保証帯域を持つキューが、前記第２のキューが持つ保証帯域以下の場合、前記第２のキューから、前記選択された通信条件を実現するために必要な保証帯域を持つキューを選択することを特徴とする請求項１２に記載
のネットワークシステム。
【請求項１４】
前記ネットワークシステムにおけるトラフィックは複数のクラスに分類され、
前記通信計画サーバは、特定のメディアを複数のトラフィックが、各々異なるクラスのトラフィックである場合に、前記複数のクラスの中から前記特定のメディアを含む第１のクラスを特定し、
前記管理サーバは、前記ネットワークノードのキューイング設定を実行する場合に、前記第１のクラスを含む前記データが前記選択されたキューに入るように前記ネットワークノードのキューイング設定を実行することを特徴とする請求項１２に記載のネットワークシステム。
【請求項１５】
前記通信計画サーバは、前記複数のクラスの中から前記特定のメディアを含む第１のクラスを特定する場合に、
任意の前記クラスにおける前記特定のメディアを含むトラフィックが、当該クラスに割り当てられた帯域を最も消費しているクラスを特定し、
前記特定されたクラスを前記特定のメディアを含む第１のクラスと特定することを特徴とする請求項１４に記載のネットワークシステム。
【請求項１６】
前記計算機は、表示部を備え、
前記表示部は、前記計算機のユーザが要求する品質の条件を設定するための項目を表示することを特徴とする請求項１に記載のネットワークシステム。
【請求項１７】
前記表示部は、前記送信された品質条件が実現されたか否かを示す情報を表示することを特徴とする請求項１６に記載のネットワークシステム。
【請求項１８】
前記表示部は、計測された帯域を表示することを特徴とする請求項１６に記載のネットワークシステム。
【請求項１９】
計算機と、ネットワークノードと、前記計算機上で実行されるアプリケーションに必要なデータを前記計算機に送信するアプリケーションサーバと、前記計算機と前記アプリケーションサーバとの間の通信の計画を管理する通信計画サーバと、前記計算機、前記ネットワークノード及び前記アプリケーションサーバが接続されたネットワークを管理する管理サーバとを備えるネットワークシステムにおける通信計画サーバであって、
前記通信計画サーバは、
プロセッサ、前記プロセッサと接続されているメモリ、前記プロセッサと接続されている不揮発性記憶媒体、及び前記ネットワークと接続されるネットワークインタフェースを備え、
前記アプリケーションサーバが格納するデータに対する、前記ネットワークにおいて提供されるサービスの品質を決定する通信条件を格納し、
前記計算機から、前記計算機上で実行されるアプリケーションの品質に対する前記計算機のユーザによる要求である品質条件を受信した場合、前記受信した品質条件を実現するための、前記通信条件を複数前記管理サーバに送信し、
前記送信された通信条件に対する品質応答を前記計算機に送信することを特徴とする通信計画サーバ。
【請求項２０】
前記計算機上で実行されるアプリケーションに必要なデータは、ストリーミングデータであり、
前記通信条件は、
前記アプリケーションが実行されているときに送信される前記データの送信量を示す定常帯域と、
前記定常帯域より大きく、前記アプリケーション開始時に送信される前記データの送信量を示す初期帯域と、
前記初期帯域で前記計算機に前記データが送信される時間幅を示す初期時間とを含み、
前記複数の通信条件は、前記品質条件を実現するために最適な順番に並べられていることを特徴とする請求項１９に記載の通信計画サーバ。
【請求項１】
計算機と、ネットワークノードと、前記計算機上で実行されるアプリケーションに必要なデータを前記計算機に送信するアプリケーションサーバと、前記計算機と前記アプリケーションサーバとの間の通信の計画を管理する通信計画サーバと、前記計算機、前記ネットワークノード及び前記アプリケーションサーバが接続されたネットワークを管理する管理サーバとを備えるネットワークシステムであって、
前記アプリケーションサーバは、第１のプロセッサ、前記第１のプロセッサと接続されている第１のメモリ、前記第１のプロセッサと接続されている第１の不揮発性記憶媒体、前記ネットワークと接続される第１のネットワークインタフェースを備え、
前記通信計画サーバは、第２のプロセッサ、前記第２のプロセッサと接続されている第２の記憶媒体、前記ネットワークと接続される第２のネットワークインタフェースを備え、
前記管理サーバは、第３のプロセッサ、前記第３のプロセッサと接続されている第３のメモリ、前記第３のプロセッサと接続されている第３の不揮発性記憶媒体、前記ネットワークと接続される第３のネットワークインタフェースを備え、
前記通信計画サーバは、
前記アプリケーションサーバが格納するデータに対する、前記ネットワークにおいて提供されるサービスの品質を決定する通信条件を前記第２の記憶媒体に格納し、
前記計算機から、前記計算機上で実行されるアプリケーションの品質に対する前記計算機のユーザによる要求である第１の品質条件を受信した場合、前記受信した第１の品質条件を実現するための、複数の前記通信条件を前記管理サーバに送信し、
前記管理サーバは、
前記通信計画案を受信した場合、前記受信した複数の通信条件の中から最適な前記通信条件を選択し、
前記選択された通信条件を含む品質応答を前記アプリケーションサーバに送信し、
前記アプリケーションサーバは、前記品質応答に含まれる前記通信条件にしたがって、前記計算機上で実行されるアプリケーションに必要なデータを前記計算機に送信することを特徴とするネットワークシステム。
【請求項２】
前記計算機上で実行されるアプリケーションに必要なデータは、ストリーミングデータであり、
前記通信条件は、
前記アプリケーションの実行中に送信される前記データの送信量を示す定常帯域と、
前記定常帯域より大きく、前記アプリケーションの開始時に送信される前記データの送信量を示す初期帯域と、
前記初期帯域によって示された送信量にしたがって前記計算機に前記データが送信される時間幅を示す初期時間とを含み、
前記複数の通信条件は、前記第１の品質条件を実現するために最適な順番に並べられており、
前記管理サーバは、
現在接続されている全ての通信の帯域の総和を算出し、
前記算出された帯域の総和及び前記通信条件に含まれる初期帯域の和と、前記ネットワークノードにおいて許容されている総帯域とを比較し、
前記算出された帯域の総和及び前記通信条件に含まれる初期帯域の和が、前記ネットワークノードにおいて許容されている総帯域より小さい場合、当該通信条件を最適な条件として選択することを特徴とする請求項１に記載のネットワークシステム。
【請求項３】
前記ストリーミングサーバは、
前記管理サーバによって決定された前記通信条件を受信し、
前記受信した通信条件に含まれる初期時間に示された時間幅で、前記受信した通信条件に含まれる初期帯域に示された送信量にしたがって前記データを送信し、
前記受信した通信条件に含まれる初期時間が経過した後、前記通信条件に含まれる定常帯域に示された送信量にしたがって前記データを送信することを特徴とする請求項２に記載のネットワークシステム。
【請求項４】
前記通信条件は、さらに、前記選択された通信条件によるネットワークシステムの設定の有効時間を示すタイムアウト時間を含むことを特徴とする請求項２に記載のネットワークシステム。
【請求項５】
前記タイムアウト時間が経過する前に、前記通信計画サーバが、前記計算機から前記第１の品質条件と同一の内容である第２の品質条件を受信した場合、前記タイムアウト時間のカウントは初期化され、前記第２の品質条件を受信した時刻から新たに前記タイムアウト時間のカウントが開始されることを特徴とする請求項４に記載のネットワークシステム。
【請求項６】
前記計算機上で実行されるアプリケーションに必要なデータは、ストリーミングデータであり、
前記通信条件は、
前記アプリケーションが実行されているときに送信される前記データの送信量を示す定常帯域と、
前記アプリケーションが実行されているときに送信される前記データの最大許容送信量を示す最大帯域とを含み、
前記管理サーバは、
現在接続されている全ての通信の帯域から予測帯域の総和を算出し、
前記算出された予測帯域の総和及び前記通信計画に含まれる前記最大帯域の和と、前記ネットワークノードにおいて許容されている総帯域とを比較し、
前記算出された予測帯域の総和及び前記通信計画に含まれる前記最大帯域の和が、前記ネットワークノードにおいて許容されている総帯域より小さい場合、当該通信条件を最適な条件として選択することを特徴とする請求項１に記載のネットワークシステム。
【請求項７】
前記ストリーミングサーバは、
前記管理サーバによって決定された前記通信条件を受信し、
前記受信した通信条件に含まれる定常帯域及び前記最大帯域によって指定された可変ビットレート通信によって、前記データを送信することを特徴とする請求項６に記載のネットワークシステム。
【請求項８】
前記計算機から送信される前記第１の品質要求は、前記管理サーバを経由して前記通信計画サーバに送信され、
前記通信計画サーバは、前記第１の品質要求に対する前記品質応答に前記複数の通信条件を含めて、前記計算機に送信し、
前記品質応答は、前記管理サーバを経由して前記通信計画サーバに送信され、
前記管理サーバは、前記品質応答を前記計算機に転送する場合に、
前記品質応答に含まれる前記複数の通信条件の中から最適な前記通信条件を選択し、
前記選択された通信条件が含まれた前記品質応答を前記計算機に転送することを特徴とする請求項１に記載のネットワークシステム。
【請求項９】
前記通信計画サーバは、前記管理サーバに前記複数の通信条件を送信する場合に、前記複数の通信条件の中から前記第１の品質条件を最適に実現することができる前記通信条件を選択し、
前記選択された通信条件を前記管理サーバに送信し、
前記管理サーバは、
受信した前記通信条件が最適か否かを判定し、
最適でないと判定された場合、前記通信計画サーバに前記受信した通信条件が最適でないことを示す拒否応答を送信し、
前記通信計画サーバは、前記拒否応答を受信した場合、次に最適に前記第１の品質条件を実現できる前記通信条件を選択し、該通信条件を前記管理サーバに送信することを特徴とする請求項２又は８に記載のネットワークシステム。
【請求項１０】
前記通信計画サーバは、前記管理サーバに前記複数の通信条件を送信する場合に、前記複数の通信条件を一括して送信することを特徴とする請求項１に記載のネットワークシステム。
【請求項１１】
前記通信計画サーバは、前記管理サーバに前記複数の通信条件を送信する場合に、前記通信計画サーバによって決定されたパラメタと条件式とによって決定される、前記複数の通信条件を送信することを特徴とする請求項１に記載のネットワークシステム。
【請求項１２】
前記ネットワークノードは、前記ネットワークノードの出力インタフェースにおいて、複数の異なる保証帯域を持つキューを割り当て、
前記管理サーバは、
前記選択された通信条件を実現するために必要な保証帯域を持つキューを、前記ネットワークノードの前記キューから選択し、
前記ネットワークノードから前記計算機に送信される前記データが、前記選択されたキューに入るように前記ネットワークノードのキューイング設定を実行することを特徴とする請求項１に記載のネットワークシステム。
【請求項１３】
前記複数の異なる保証帯域を持つキューは、第１のキューと第２のキューとを含み、
前記第１のキューは、前記第２のキューより大きい保証帯域を持ち、
前記選択された通信条件を実現するために必要な保証帯域を持つキューが、前記第１のキューが持つ保証帯域以下、かつ、前記第２のキューが持つ保証帯域より大きい場合、前記第１のキューから、前記選択された通信条件を実現するために必要な保証帯域を持つキューを選択し、
前記選択された通信条件を実現するために必要な保証帯域を持つキューが、前記第２のキューが持つ保証帯域以下の場合、前記第２のキューから、前記選択された通信条件を実現するために必要な保証帯域を持つキューを選択することを特徴とする請求項１２に記載
のネットワークシステム。
【請求項１４】
前記ネットワークシステムにおけるトラフィックは複数のクラスに分類され、
前記通信計画サーバは、特定のメディアを複数のトラフィックが、各々異なるクラスのトラフィックである場合に、前記複数のクラスの中から前記特定のメディアを含む第１のクラスを特定し、
前記管理サーバは、前記ネットワークノードのキューイング設定を実行する場合に、前記第１のクラスを含む前記データが前記選択されたキューに入るように前記ネットワークノードのキューイング設定を実行することを特徴とする請求項１２に記載のネットワークシステム。
【請求項１５】
前記通信計画サーバは、前記複数のクラスの中から前記特定のメディアを含む第１のクラスを特定する場合に、
任意の前記クラスにおける前記特定のメディアを含むトラフィックが、当該クラスに割り当てられた帯域を最も消費しているクラスを特定し、
前記特定されたクラスを前記特定のメディアを含む第１のクラスと特定することを特徴とする請求項１４に記載のネットワークシステム。
【請求項１６】
前記計算機は、表示部を備え、
前記表示部は、前記計算機のユーザが要求する品質の条件を設定するための項目を表示することを特徴とする請求項１に記載のネットワークシステム。
【請求項１７】
前記表示部は、前記送信された品質条件が実現されたか否かを示す情報を表示することを特徴とする請求項１６に記載のネットワークシステム。
【請求項１８】
前記表示部は、計測された帯域を表示することを特徴とする請求項１６に記載のネットワークシステム。
【請求項１９】
計算機と、ネットワークノードと、前記計算機上で実行されるアプリケーションに必要なデータを前記計算機に送信するアプリケーションサーバと、前記計算機と前記アプリケーションサーバとの間の通信の計画を管理する通信計画サーバと、前記計算機、前記ネットワークノード及び前記アプリケーションサーバが接続されたネットワークを管理する管理サーバとを備えるネットワークシステムにおける通信計画サーバであって、
前記通信計画サーバは、
プロセッサ、前記プロセッサと接続されているメモリ、前記プロセッサと接続されている不揮発性記憶媒体、及び前記ネットワークと接続されるネットワークインタフェースを備え、
前記アプリケーションサーバが格納するデータに対する、前記ネットワークにおいて提供されるサービスの品質を決定する通信条件を格納し、
前記計算機から、前記計算機上で実行されるアプリケーションの品質に対する前記計算機のユーザによる要求である品質条件を受信した場合、前記受信した品質条件を実現するための、前記通信条件を複数前記管理サーバに送信し、
前記送信された通信条件に対する品質応答を前記計算機に送信することを特徴とする通信計画サーバ。
【請求項２０】
前記計算機上で実行されるアプリケーションに必要なデータは、ストリーミングデータであり、
前記通信条件は、
前記アプリケーションが実行されているときに送信される前記データの送信量を示す定常帯域と、
前記定常帯域より大きく、前記アプリケーション開始時に送信される前記データの送信量を示す初期帯域と、
前記初期帯域で前記計算機に前記データが送信される時間幅を示す初期時間とを含み、
前記複数の通信条件は、前記品質条件を実現するために最適な順番に並べられていることを特徴とする請求項１９に記載の通信計画サーバ。
【図１】
【図２Ａ】
【図２Ｂ】
【図２Ｃ】
【図３Ｂ】
【図４】
【図５】
【図６Ａ】
【図６Ｂ】
【図６Ｃ】
【図７】
【図８】
【図９Ａ】
【図９Ｂ】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４Ａ】
【図１４Ｂ】
【図１５】
【図１６Ａ】
【図１６Ｂ】
【図１７】
【図３Ａ】
【図３Ｃ】
【図３Ｄ】
【図２Ａ】
【図２Ｂ】
【図２Ｃ】
【図３Ｂ】
【図４】
【図５】
【図６Ａ】
【図６Ｂ】
【図６Ｃ】
【図７】
【図８】
【図９Ａ】
【図９Ｂ】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４Ａ】
【図１４Ｂ】
【図１５】
【図１６Ａ】
【図１６Ｂ】
【図１７】
【図３Ａ】
【図３Ｃ】
【図３Ｄ】
【公開番号】特開２０１０−１３６２５７（Ｐ２０１０−１３６２５７Ａ）
【公開日】平成２２年６月１７日（２０１０．６．１７）
【国際特許分類】
【出願番号】特願２００８−３１２１５４（Ｐ２００８−３１２１５４）
【出願日】平成２０年１２月８日（２００８．１２．８）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
【公開日】平成２２年６月１７日（２０１０．６．１７）
【国際特許分類】
【出願日】平成２０年１２月８日（２００８．１２．８）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
[ Back to top ]