JP2004048565A5 - - Google Patents

Description

【発明の名称】ネットワーク品質推定制御方式
【特許請求の範囲】
【請求項１】ネットワーク、コンテンツサーバ、エンドユーザ端末、コンテンツサーバ管理機能、ネットワーク管理機能、ユーザ管理機能、および品質推定制御機能からなるコンテンツ配送ネットワークについて、ネットワーク各部の輻輳ボトルネック状況を把握し、必要に応じて様々な品質制御を行って全体の配送品質を維持向上させるネットワーク品質推定制御方式において、
前記品質推定制御機能は、ユーザ状態管理テーブルとネットワーク状態管理テーブルを有し、ユーザ状態管理テーブルはユーザＩＤ、ユーザが接続された局またはネットワークシステムを識別するユーザ局／システムＩＤ、ユーザアドレス、及び品質状態を保持する領域を有し、これらの情報のうちユーザＩＤとユーザ局／システムＩＤは、各ユーザが当該コンテンツ配送ネットワークサービスに加入する際にサービス管理者が入力するか、または、前記品質推定制御機能が自動で入力し、
前記ユーザ管理機能はユーザＩＤとユーザアドレスの対応関係を示すユーザ管理テーブルを具備し、各ユーザがユーザ管理機能にアクセスした際に該ユーザ管理テーブルのユーザアドレスを更新するとともに、該ユーザアドレスを前記ユーザ状態管理テーブルのユーザアドレス領域に入力し、
前記品質推定制御機能は、コンテンツサーバが各ユーザにコンテンツを配送する場合、当該配送セッションのトランスポートレイヤ品質、アプリケーションレイヤ品質、またはその両方をモニタして良好・要注意・異常等の品質状態を判定し、該品質状態を前記ユーザ状態管理テーブルの品質状態領域にユーザ毎に記述し、
前記品質推定制御機能は、ユーザ局／システムＩＤが同一となるユーザ毎に該品質状態領域のデータを集計して良好・要注意・異常等のユーザ局／システムとしての状態を推定し、ネットワーク状態管理テーブルに記述し保持することを特徴とするネットワーク品質推定制御方式。
【請求項２】前記品質推定制御機能は、コンテンツサーバが各ユーザにストリーミングコンテンツを配送するとき、
ユーザ端末のプレイヤソフトウェアがモニタする映像フレームレート、損失パケット数、修復パケット数、受信バッファ状態等の情報を前記アプリケーションレイヤ品質として収集し、
品質情報の一部または全部があらかじめ指定する閾値を超過した場合に、当該ユーザの品質状態を異常と判定することを特徴とする請求項１に記載のネットワーク品質推定制御方式。
【請求項３】前記品質推定制御機能は、コンテンツサーバが各ユーザにストリーミングコンテンツを配送するとき、
当該配送セッションのＴＣＰ（Transport Control Protocol）、ＲＴＣＰ（Real Time Control Protocol）をモニタしてパケット損失、エンドエンド遅延、遅延変動量等を前記トランスポートレイヤ品質として収集し、
品質情報の一部または全部があらかじめ指定する閾値を超過した場合に、当該ユーザの品質状態を異常と判定することを特徴とする請求項１または２に記載のネットワーク品質推定制御方式。
【請求項４】あるユーザからの新規にコンテンツ配送要求がある場合、
前記品質推定制御機能は前記配送要求パケットが含むユーザアドレスから該エンドユーザのユーザ局／システムｌＤを特定してネットワーク状態管理テーブルを参照し、
該特定したユーザ局／システムＩＤの品質状態が要注意・異常等の場合には該新規コンテンツ配送要求に対し配送不可能を通知し、状態が正常な場合には、該コンテンツが収容されたコンテンツサーバのアドレス、コンテンツ識別子等を通知することを特徴とする、請求項１〜３の何れかに記載のネットワーク品質推定制御方式。
【請求項５】あるユーザからの新規にコンテンツ配送要求がある場合、
前記品質推定制御機能は、該特定したユーザ局／システムＩＤの状態が要注意・異常等の場合にはユーザに要注意・異常状態であることと、該コンテンツが収容されたコンテンツサーバのアドレス、コンテンツ識別子を通知し、
ユーザ端末内のソフトウェアは試験的に該コンテンツサーバに接続して受信を開始し、一定時間経過後に受信状態が異常であれば接続を断とすることを特徴とする、請求項４に記載のネットワーク品質推定制御方式。
【請求項６】該ネットワークのアクセスネットワーク部分が、各ユーザ局／システムに対しその上位局が一意に定まるスター型トポロジである場合、
前記品質推定制御機能は、ユーザ状態管理テーブルに上位局／システムＩＤも保持し、
前記品質推定接続機能は、上位局／システムＩＤが同一となるユーザ毎にユーザ状態管理テーブルの品質状態領域のデータを集計し、良好・要注意・異常等の上位局／システムとしての状態を判定してネットワーク状態管理テーブルに記述し、
ある上位局／システムが要注意・異常等の状態の場合、それを通過するエンドユーザからの新規コンテンツ配送要求に対し配送規制処理を行うことを特徴とする請求項１〜５の何れかに記載のネットワーク品質推定制御方式。
【請求項７】前記コンテンツサーバ管理機能は各コンテンツサーバのアドレスとそれが接続された局やシステムを識別するサーバ局／システムＩＤの対応情報を保持し、
前記品質推定制御機能は、ユーザ状態管理テーブルに、ユーザがアクセスするサーバアドレスとサーバ局／システムＩＤも保持し、
前記品質推定制御機能は、配送セッションのトランスポートレイヤ品質、アプリケーションレイヤ品質に加え、サーバアドレスを収集してこれもユーザ状態管理テーブルに書き込み、
前記品質推定制御機能は、前記コンテンツサーバ管理機能に当該サーバアドレスに対応するサーバ局／システムＩＤを参照し、該サーバ局／システムＩＤもユーザ状態管理テーブルに書き込み、
前記品質推定制御機能は、ユーザ状態管理テーブル上でサーバ局／システムＩＤが同一となるユーザ毎に品質状態領域のデータを集計して良好・要注意・異常等の状態を推定し、サーバ局／システムＩＤ毎の品質状態もネットワーク状態管理テーブルに記述し保持することを特徴とする、請求項１〜６の何れかに記載のネットワーク品質推定制御方式。
【請求項８】前記サーバ管理機能は、複数のサーバに分散配置された各コンテンツの配置状況を管理し、
前記品質推定制御機能は、ユーザからの新規にコンテンツ配送要求がある場合、前記サーバ管理機能に当該コンテンツが配置されたサーバ局／システムＩＤおよびサーバアドレスを問い合わせ、
前記品質推定機能は、ネットワーク管理テーブルを参照し、問い合わせたサーバ局／システムＩＤの全ての品質状態が要注意・異常等の場合には該新規コンテンツ配送要求に対し配送不可をユーザに通知し、一つ以上の品質状態が良好な該サーバ局／システムＩＤがある場合、良好なサーバアドレスをユーザに通知することを特徴とする請求項７に記載のネットワーク品質推定制御方式。
【請求項９】前記ネットワーク状態管理テーブルはサーバ局／システムＩＤとユーザ局／システムＩＤが同一となる仮想リソース毎の品質状態を保持し、
前記品質推定制御機能は、前記ユーザ状態管理テーブルの品質状態をサーバ局／システムＩＤおよびユーザ局／システムＩＤが同一となるユーザ毎に集計し、良好・要注意・異常等の状態を判定して該ネットワーク状態管理テーブルに書き込み、
前記品質推定制御機能は、ユーザからの新規にコンテンツ配送要求がある場合、前記サーバ管理機能に当該コンテンツが配置されたサーバ局／システムＩＤおよびサーバアドレスを問い合わせ、
前記品質推定制御機能はネットワーク管理テーブルを参照し、品質状態が最良となるサーバ局／システムＩＤとユーザ局／システムＩＤを決定し、該当するサーバアドレスをユーザに通知することを特徴とする請求項８に記載のネットワーク品質推定制御方式。
【請求項１０】前記ユーザアドレス、サーバアドレスとして、ＩＰ（Internet Protocol）アドレスを用いることを特徴とする請求項１〜９の何れかに記載のネットワーク品質推定制御方式。
【請求項１１】前記ユーザアドレス、サーバアドレスとして、ＵＲＬ（Uniform Resource Locator）やCookie情報等を含むアプリケーションレイヤ識別子を用いることを特徴とする請求項１〜９の何れかに記載のネットワーク品質推定制御方式。
【請求項１２】前記ユーザ管理機能としてＲＡＤＩＵＳ認証サーバを用いることを特徴とする請求項１〜１１の何れかに記載のネットワーク品質推定制御方式。
【請求項１３】前記ユーザ管理機能としてコンテンツ配送サービス認証サーバを用いることを特徴とする請求項１〜１１の何れかに記載のネットワーク品質推定制御方式。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明はインタネット上のコンテンツ配信・配送サービスにおいて、コンテンツサーバ間、コンテンツサーバ・ユーザ端末間の配送品質を維持・向上させる品質制御技術に関する。
【０００２】
【従来の技術】
インタネット利用者は、サービス開始以来飛躍的な増加を続け、２０００年の国内利用者数は固定端末系のみで二千万人を超え、ＯＣＮ、ＩＩＪ等の国内大手ＩＳＰ（Internet Service Provider）はそれぞれ数百万人規模のエンドユーザを獲得している[1]。インタネット上で送受信されるコンテンツ、実行されるアプリケーションについては、当初はＷｅｂページ／ファイル／メール等のダウンロードがメインであった。ダウンロード型アプリケーションの場合、ネットワークで輻輳が発生した場合にダウンロード時間の長延化によりユーザの不満が増大するという問題はあるものの、ＴＣＰ等の高信頼トランスポートを用いることにより、コンテンツ自体の品質を損なうことはない。したがってコンテンツが有料の場合であってもネットワークの輻輳が有料性に深刻な影響を及ぼすことはない。一方近年では、メジャーアーティストのコンサートライブ映像や著名な映画等を多数のユーザ向けに配送する、企業が映像を用いて自社の商品プロモーションを実施する等、映像や音声のストリーミング技術を用いたビジネスが活性化しつつある。ストリーミングアプリケーションでは、ユーザ端末は映像信号を数秒バッファリングした後、全てのファイルを受信しきる前に再生を開始し、ネットワーク上での各パケット到着時間のばらつきを吸収し、またバッファリング時間を利用して損失パケットの再送等を行って品質を維持しようとする。ストリーミングアプリケーションの場合、ネットワークが再送により品質が維持できる程度の軽度の輻輳状態であればコンテンツ自体の品質は損なわれないが、重度の輻輳状態では、コンテンツ自体の受信品質を維持することができず、アプリケーションレイヤでのレート制御により配送帯域を抑制して配送を続けようとする。これは、例えば映像符号化則として映像フレーム間の差分符号化則を適用する場合、フレーム間差分符号化データを間引き、フレーム内符号化データのみを配送する等の方法により実現される[2]。それでも輻輳状態が回避できなければ、音声データのみを配送する等さらに配送帯域を抑制する。その結果、ユーザが受信するコンテンツ自体の品質が著しく損なわれ、特にコンテンツが有料の場合にはそのビジネス自体に深刻な影響を及ばす可能性がある。
図１に上述したダウンロードアプリケーションの場合とストリーミングアプリケーションの場合におけるネットワーク輻輳の影響を示す。
【０００３】
図２に現在のインタネット接続サービスにおける代表的なネットワーク構成例を示す。インタネット接続サービスネットワークは一般にバックボーンネットワークとアクセスネットワークとで構成され、バックボーンネットワークはＯＣＮ，ＩＩＪ等のＩＳＰが保有する広域ＩＰネットワーク、アクセスネットワークはＩＳＰ自身が保有する場合、ＮＴＴ東西地域会社が提供するフレッツＩＳＤＮ／ＡＤＳＬサービス等、ＩＳＰと別事業者が保有する場合等がある。ＩＳＰは
・ユーザＩＤ、ユーザに割り当てたＩＰアドレスを管理するユーザ管理機能、
・自ら保有するネットワークシステム、伝送路等のトポロジ情報、各システム・伝送路の故障・性能状態等を管理するネットワーク管理機能、
・自ら保有するコンテンツサーバＩＤ、サーバＩＰアドレス、各サーバの故障・性能状態等を保持するサーバ管理機能、
等を具備し、自らが持つリソースの管理を行う。
【０００４】
【発明が解決しようとする課題】
以下映像ストリーミング等のリアルタイム性の高いコンテンツを図２の広域ＩＰネットワークを介してエンドユーザに転送する場合の第一の問題を示す。ネットワークは、ＩＳＰ自らが管理するコンテンツサーバや他ＩＳＰのコンテンツサーバや他サーバ事業者が発生する様々なアプリケーショントラヒック、制御トラヒックを、ＯＳＰＦ（Open Shortest Path First）等の自律ルーチングプロトコルにより転送する。ＩＳＰは自網を通過する全てのアプリケーションの開始・終了、生成されるトラヒックパタン等を管理することはできないため、ネットワーク各部では潜在的に輻輳が発生する可能性がある。また東京２３区内、東京大阪間等のバックボーン部分は、各システム間はＧbit/ｓ以上の高速リンクで接続されているが、各県／各都市にトラヒック分岐する支線部分については、広範囲に広がる支線部分の設備コストが全体に占める割合が非常に大きくなることから、極力低速リンクで接続しようとする。ファイル転送、映像ストリーミングの別を問わずコンテンツサーバが発生するトラヒックはバースト性が強いため、入出力リンク速度差が大きなシステムでは、システムが持つパケットバッファ量、書込・読出性能によっては容易にパケット損失が発生する可能性がある。すなわち大きくリンク速度が減速するアクセスネットワークでは、トラヒックのバースト性によりパケット損失・輻輳が発生する可能性が高い。
【０００５】
また輻輳が発生した場合、ストリーミングアプリケーションは上述のレート制御を実施するが、レート制御により輻輳が回避された場合、ＩＳＰのネットワーク管理機能では輻輳の発生を認識することができない。すなわち映像コンテンツとしての品質は著しく劣化しているにもかかわらず、その原因であるネットワーク上の輻輳発生点を評定できないという第二の問題がある。
【０００６】
また、バックボーンネットワークとアクセスネットワークを一事業者がエンドエンドで保有する事例もあるが、現状ではバックボーンネットワークはＩＳＰ事業者等が保有し、アクセスネットワークはＤＳＬ事業者等が保有する場合がある。コンテンツ配信・配送サービス事業者の場合、広域に分散する多数のエンドユーザに配送できる広域性によりコンテンツホルダ等を囲い込むため、図３に示すように複数のアクセス網（ＤＳＬ）事業者と相互接続してサービスを提供するのが一般的と思われる。このとき、ＩＳＰから見ると、他事業者となる各アクセスネットワークのリソース全体が把握できない、さらに他ＩＳＰとアクセスネットワークを共有するため、その輻輳状況を把握できないという第三の問題がある。このため、アクセスネットワークで輻輳が発生しているにもかかわらず、当該輻輳点の配下となるエンドユーザからの新規配送要求を受付け、さらに重度の輻輳状態に陥る場合がある。
【０００７】
特に映像ストリーミング等のリアルタイム系コンテンツの場合、上述のようにネットワークの輻輳がコンテンツ自体の品質劣化に直結するため、このように輻輳が発生しやすいネットワーク環境は、リアルタイム系コンテンツを用いたビジネスの本格化に向けて大きな障壁となる可能性がある。
【０００８】
【課題を解決するための手段】
本発明は、他事業者が保有するアクセスネットワークを含め、アプリケーションレイヤ品質を含めた真のネットワーク品質状態を推定する方式、および品質状態に応じて新規配送要求に対する配送規制を行う、最高の配送品質を得られるコンテンツサーバを選択してユーザをナビゲートする、等の高度なサーバアクセス制御方式を提案する。
【０００９】
本発明によるネットワーク品質推定方式の概要を図４を用いて説明する。バックボーンネットワークは、図２の各機能、すなわちユーザ管理機能、ネットワーク管理機能及びサーバ管理機能に加え、ネットワーク（ＮＷ）品質推定制御機能を具備する。
ＮＷ品質推定制御機能は大きくはユーザ状態管理テーブルと、ＮＷ状態管理テーブルの２つのデータベースを保持する。ユーザ状態管理テーブルは、エンドユーザ毎にユーザＩＤ、ユーザが接続された局またはシステムを識別するユーザ局／システムＩＤ、ユーザのアドレス、品質状態の４種類のデータを保持する。これらのデータのうちユーザＩＤとユーザ局／システムＩＤは、ユーザがサービスに加入する時、すなわちユーザ管理機能への登録時に、サービス管理者が同時に入力するか、または、前記品質推定制御機能が自動で入力する。ユーザアドレスは、ユーザがユーザ管理機能にアクセスし、ユーザ管理機能がアドレスを割り付け、そのデータベースにコンテンツの配送サービスを受けるユーザのアドレスを登録した際に、ユーザ管理機能がその結果を自動的に入力する（フロー（1））。ここでユーザ管理機能とは、コンテンツ配送サービスを受けるユーザを一意に識別できるユーザＩＤと割り当てるアドレスの対応関係を保持するものであれば種別は問わない。例えば、ユーザに割り当てるＩＰアドレスを管理するＲＡＤＩＵＳ（Remote Authentication Dial In User Service）認証サーバ[3]、コンテンツ配送サービスを提供する際にサービスとしての認証を行うサービス認証サーバ等をユーザ管理機能として利用することができる。
【００１０】
ＮＷ品質推定制御機能は、コンテンツサーバが各ユーザにコンテンツを配送する場合、当該配送セッションのトランスポートレイヤ品質、アプリケーションレイヤ品質、またはその両方を収集して良好、要注意、異常等の品質状態を判定し、ユーザ状態管理テーブルの品質状態領域に記述する（フロー（2））。
ＮＷ品質推定制御機能は、さらに、ユーザ局／システムＩＤが同一となるユーザ毎に品質状態領域のデータを集計して良好・要注意・異常等のユーザ局／システムとしての状態を推定し、その結果をネットワーク状態管理テーブルに記述し保持する（フロー（3））。
【００１１】
上述の品質情報の収集において、収集対象ユーザについては、サービスに加入する全ユーザの情報を収集する、ユーザ局／システムＩＤ毎にサンプルユーザを選んで収集する、ユーザ局／システムＩＤ毎に擬似ユーザ端末を配置して収集する、のいずれの方法でもよく、またこれらの組合せでもよい。トランスポートレイヤ品質の収集位置については、データセンタ出口でのトラヒックモニタにより収集する、ネットワーク内でのトラヒックモニタにより収集する等いずれの方法でもよい。また、トランスポート品質としては、パケット損失、エンドエンド遅延，遅延変動量等を収集する。
【００１２】
アプリケーションレイヤ品質は、映像ストリーミング等の品質状態を把握する上で重要なパラメータであるが、その収集にはサーバソフトウェア、ユーザ端末内のプレイヤソフトウェアでモニタしている品質情報を抽出する必要がある。Windows Media Technology社，Real Networks社等の市販のプレイヤソフトウェアの多くは、プレイヤの様々な形態でのカスタマイズを可能とするためＳＤＫを公開しており、これを用いることでアプリケーションレイヤ品質を抽出できる[4]。例えばWindows Media Technology社のプレイヤの場合、再生中に画面上で確認可能な、映像フレームレート、受信帯域、損失・修復パケット数、プレイヤの受信バッファ状態 等様々な情報が取得可能である．品質状態の判定方法も任意であるが、例えばトランスポートレイヤの損失パケット量、エンドエンド遅延、遅延変動量等の性能情報、アプリケーションレイヤのフレームレート、受信バッファ状態等の性能情報に一定の閾値を設定し、ひとつまたは複数の性能情報が閾値より劣化した場合に、当該ユーザの品質状態を異常と判定する等の方法がある。
【００１３】
ＮＷ状態管理テーブルは、ユーザ局／システムＩＤと該局／システムの品質状態データを保持する。この品質状態については、ユーザ状態管理テーブル上のユーザ局／システムＩＤが同一となるユーザ、即ち同一のユーザ局／システムに収容されるユーザの品質状態を集計し、一定の人数または割合以上のユーザが異常である場合に、当該ユーザ局／システムＩＤが異常と判定する。閾値を複数設けることにより、当該局／ユーザＩＤの品質状態を、異常・要注意・正常等きめ細かく管理することも可能である。
【００１４】
図５はネットワーク状態のきめ細かな判定方法の一例として、ユーザ毎の受信品質をトランスポートレイヤとアプリケーションレイヤの二次元で集計し、ネットワーク品質状態を推定する方法を示す。ある映像ストリーミングアプリケーションが実行された状態で、ネットワーク負荷を少しずつ大きくした場合、図中の二次元グラフ上の点線曲線のように品質状態が変化すると考えられる。ここでは、例えばアプリケーションレイヤでのレート制御が実行される場合を想定し、フレーム間差分データの間引き配送状態、音声のみ配送状態等を指標とした。これは、フレーム間差分データ等が間引かれる場合にはフレームレートが大きく変動することから、フレームレートをモニタすることでレート制御状態を把握することができるからである。例えばトランスポートレイヤのみの品質情報を参照する場合、正常状態なのか音声のみの末期状態となっているのかが判別できない。またアプリケーションレイヤのみの参照では、劣化のわずかな予兆を見逃す可能性があり、タイムリな品質制御が行えない可能性がある。
【００１５】
以上から、本例では、アプリケーションレイヤ、トランスポートレイヤ両方の品質により収容局／システム毎の品質状態を推定しており、図５では、多数のユーザに対しアプリケーションレイヤ品質(フレームレート)もトランスポートレイヤ品質も正常であるエリアＡは正常とし、多数のユーザに対しフレームレートが正常であるがパケット損失が発生するエリアＢは経過観察とし、多数のユーザに対しフレームレート変動が発生するとともにパケット損失を発生するエリアＣは要注意状態とし、多数のユーザに対しトランスポートレイヤ品質が正常であるが音声のみの配送が発生するエリアＤは末期状態（異常）とする。
以上によりアクセスネットワークの収容局／システムを単位とし、アプリケーションレイヤの品質を考慮した真のネットワーク状態を把握することが可能となる。
【００１６】
図６に、上記ネットワーク品質推定結果に基づくサーバアクセス制御の実現例を示す。ユーザ１等既に配送中のユーザがあり、品質推定制御機能は各収容局／システムn1,n2,n3毎のネットワーク状態を推定できているものとする(フロー（1）)。ユーザ２がユーザ管理機能にアクセスしアドレスを取得した時(フロー（2）)、当該アドレスはネットワーク品質推定制御機能のユーザ状態管理テーブルに入力される(フロー（3）)。このユーザアドレスは、一般に、アクセス時に実行されるユーザ認証またはサービス認証により割り付けられる。ユーザ２は番組表からあるコンテンツを選択すると(フロー（4）)、番組表からＮＷ品質推定制御サーバのアドレスが通知される(フロー（5）)。これに応答して、ユーザ２は品質推定制御機能にネットワーク状態の問合わせを行い(フロー（6）)、品質推定制御機能は、当該問合わせが含むソースアドレス情報(ユーザアドレスｃ2)から該ユーザを収容するユーザ局／システムｎ2を特定してその品質状態を参照し、その品質状態から配送可否を判定し、その結果をユーザ２に通知する（フロー（7））。例えば、当該ユーザ局／システムが要注意・異常等の状態である場合、ユーザ２に対し、現在ネットワークが輻輳状態にあるため配送できないことを通知する。また、正常な場合には、当該コンテンツが収容されたコンテンツサーバのアドレス、コンテンツ識別子等を通知し、ユーザ２は受け取ったコンテンツサーバアドレス、コンテンツ識別子を用いて番組視聴要求をコンテンツサーバに送り(フロー（8）)、コンテンツの配送を受ける(フロー（9）)。
【００１７】
以下サーバアクセス制御に関するいくつかの代替例を説明する。
ユーザ２が番組表からコンテンツ選択した際に、番組表が品質推定制御機能に直接ネットワーク状態の問合わせを行い、品質推定制御機能が番組表に推定結果を応答し、番組表からユーザ２に、ネットワーク状態を含め配送の可否を応答する構成も可能である。これによりユーザからのサーバアクセス回数を低減できる。
【００１８】
また、品質推定制御機能からユーザヘの応答シーケンスにおいて、品質推定制御機能はユーザ局／システムが要注意・異常等の状態である場合、ユーザに対し、要注意・異常であることに加え、要求されたコンテンツが収容されたコンテンツサーバのアドレス、コンテンツ識別子を応答する。それを受信したユーザ端末内のソフトウェアは試験的に該コンテンツサーバに接続して受信を開始し、受信バッファの蓄積状態等、再生状態を監視して一定時間経過後に閾値に達しない場合コンテンツサーバアクセスを停止する等の方法も可能である。また、ユーザ端末のソフトウェアが試験的配送を起動する代わりに、コンテンツサーバが当該ユーザに対して試験的配送を実施し、再生状態が悪い場合、ユーザに配送不能を応答する構成も可能である。この方法により、試験配送結果を含めたより確度の高いサーバアクセス制御が可能となる。
【００１９】
図７に、アクセスネットワーク内のより広範囲なエリアの品質推定を行う方法を示す。アクセスネットワークの一部が冗長経路化されず、ユーザ局／システムに対し上位の幹線局、地域代表局等が一意に定まるスター型トポロジである場合に適用できる。この場合には、ユーザのサービス加入時に、ユーザＩＤ、ユーザ局／システムＩＤに加えて、一意に定まる幹線局、代表局等のＩＤも合わせてユーザ状態管理テーブルに入力する。ＮＷ状態管理テーブルは、ユーザ局単位、幹線局単位、代表局単位に状態を管理できる構成とし、品質推定制御機能は、ユーザ状態管理テーブルにおいて、ユーザ局毎、幹線局毎、代表局毎にユーザの品質状態を集計し、閾値処理を実施して正常・要注意・異常等の別を判定し、ＮＷ状態管理テーブルに記述し保存する。これにより、急激なリンク速度の減速によりパケット損失・輻輳が発生しやすいアクセスネットワークについて、より広範囲にネットワーク状態の推定が可能となり、ある上位局／システムが要注意・異常状態の場合には、それを通過するエンドユーザからの新規コンテンツ配送要求に対し配送規制を行うことができる。
【００２０】
図８に、コンテンツサーバが配置されたデータセンタ近傍におけるネットワーク状態推定、及びそれに基づくアクセス制御の実現例を示す。まずサーバ管理機能は、各コンテンツサーバのアドレスと、当該サーバが接続されたサーバ局／システムＩＤの対応情報を保持する。これは自らコンテンツサーバを運用する場合には当然管理すべき情報である。一人のユーザが複数のサーバに同時にアクセスする可能性があるため、複数サーバアドレス、複数サーバ局／システムＩＤを保持できることとする。
本例でも、図４の実現例と同様に、ＮＷ品質推定制御機能のユーザ状態管理テーブルに、ユーザ管理機能から与えられるユーザＩＤ、ユーザ局／システムＩＤ、ユーザアドレスを記述し保持するとともに(フロー（1）)、エンドユーザ毎に収集するトランスポートレイヤ品質、アプリケーションレイヤ品質を記述し保持する(フロー（2）)。本例では、これと同時にユーザがアクセスするサーバアドレスも収集してユーザ状態管理テーブルに書き込むとともに、サーバ管理機能から当該サーバアドレスに対応するサーバ局／システムＩＤを検索してこれもユーザ状態管理テーブルに書き込む(フロー（3）)。ネットワーク状態管理テーブルは、サーバ局／システムＩＤ毎に品質状態を管理できる構成とし、ＮＷ品質推定制御機能は、ユーザ状態管理テーブルにおいて、サーバ局／システムＩＤ毎にユーザの品質状態を集計し、閾値超過判定処理を行って、正常・要注意・異常等の状態判定を行い、その結果をネットワーク状態管理テーブルに記述する(フロー（4）)。これによりバックボーンネットワークのコンテンツサーバが配置されたデータセンタ出口近傍のネットワークについて、アプリケーションレイヤ品質を考慮した真の品質状態の推定が可能となる。
【００２１】
図９に、本発明によるデータセンタ出口近傍ネットワークの品質推定技術を用いたサーバアクセス制御の実現例を示す。コンテンツサーバがデータセンタ１、２に分散配置された広域サーバネットワークにおいて、品質制推定制御は既にコンテンツ配送中のユーザ状態から、データセンタ１出口近傍が、要注意または異常状態にあると推定している場合を考える(フロー（1）)。ユーザ２がユーザ管理機能にアクセスしアドレスを取得した時(フロー（2）)、当該アドレス情報はネットワーク品質推定制御機能のユーザ状態管理テーブルに記述される(フロー（3）)。このユーザアドレスは、一般に、アクセス時に実行されるネットワーク認証またはサービス認証により与えられる。ユーザ２は番組表に対しあるコンテンツを要求すると(フロー（4）)、番組表からＮＷ品質推定制御サーバのアドレスが通知される(フロー（ 5 ）)。これに応答して、ユーザ２は品質推定制御機能にネットワーク状態の問合わせを行う(フロー（6）)。ネットワーク状態問合せ要求を受信した品質推定制御機能は、サーバ管理機能にコンテンツ位置を問合わせ、サーバ管理機能は最適サーバ侯補としてコンテンツサーバ１，２を通知する(フロー（7）)。品質推定制御機能は、ネットワーク状態管理テーブルを参照し、ここではデータセンタ１の出口近傍が輻輳しているという推定に基づき、ユーザ２にコンテンツサーバ２のアドレスを通知する(フロー（8）)。ユーザ２はこの通知に基づいて番組視聴要求をコンテンツサーバ２に送り(フロー（9）)、コンテンツの配送を受ける(フロー（10）)。これにより、アプリケーションレイヤを含めたネットワーク状態推定に基づく、広域サーバ負荷分散を実現することができる。
【００２２】
図１０は、複雑なトポロジのネットワークにおいて、本発明によるネットワーク品質推定、サーバアクセス制御の実現例を示す。冗長経路を有する広域ＩＰネットワークにおいて、自律ルーチングで経路制御され、さらにネットワーク内経路負荷分散等が適用される場合、フロー毎に通過経路を完全に把握して輻輳の発生位置を特定するのは難しい。図１０では、ネットワーク状態管理テーブル構成を、サーバ局／システムＩＤ、およびユーザ局／システムＩＤによる２次元マトリクスとし、ユーザ状態管理テーブル上のユーザ毎の品質状態を、サーバ局／システムＩＤとユーザ局／システムＩＤが同一となるグループ毎に集計し、閾値超過判定処理等を行って、その結果をネットワーク状態管理テーブルに記述し保持する。品質推定制御機能は、ユーザから新規コンテンツ配送要求を受信した際に、ユーザ局／システムＩＤを判定し、またサーバ管理機能に問い合わせて侯補サーバのサーバ局／システムＩＤを複数取得する。次にネットワーク状態管理テーブルを参照して、どのサーバ局／システムＩＤからの配送状態が最もよいか判定し、ユーザを当該サーバ局／システムＩＤに接続されたコンテンツサーバにナビゲートする。複雑なトポロジの場合、完全なボトルネック位置把握は難しいが、始点局、終点局を同一とするフローを仮想的なバンドルコネクションとして状態管理することで、バックボーンを含めた大まかな状態推定、サーバアクセス制御が可能となる。
【００２３】
なお、本発明で用いるサーバ、ユーザに付与されるアドレスについては、サーバ、ユーザを一意に識別できるものであれば他に制約条件はない。レイヤ３のＩＰ（Internet Protocol）アドレスも適用可能であるし、ＵＲＬ（Uniform Resource Locator）、Cookie 等の高位レイヤ情報もアドレスとして利用可能である。Cookieのようにユーザ端末に定常的に保存できる情報の場合、ユーザ管理テーブル上のユーザアドレスを同時に保存しておくことにより、ユーザ管理機能でのアドレスの割当て、ユーザ状態管理テーブルへの自動入力等、図４のフロー（1）に関する部分が、初回のユーザ管理機能への登録以降省略できるメリットがある。さらに、高位レイヤ情報を用いることにより、例えば１ＳＰの加入者がＮＡＴ（Network Address Translator）等を介して複数ユーザ端末を接続した場合に、ユーザ端末毎等の細かい単位でのユーザ受信品質管理が可能となる。
【００２４】
【発明の実施の形態】
【実施例】
〔実施例１〕
図１１に、ＩＳＰ事業者が、ＮＴＴ東西地域会社の地域ＩＰネットワーク[5]やアツカ・ネットワークス社[6]等のＤＳＬ網をアクセスネットワークとして利用して、エンドユーザにコンテンツ配送サービスを実施する場合の本発明の適用例を示す。本実施例ではユーザ管理機能として、ＩＳＰがユーザ認証・ＩＰアドレス割付を行うためのＲＡＤＩＵＳ認証サーバを利用する。
ＮＷ品質推定制御機能のユーザ状態管理テーブル上の情報について、ユーザＩＤ、アクセス事業者ＩＤ情報は、ＩＳＰ加入時に取得して入力する。ＩＳＰは、他事業者となる地域ＩＰネットワークのトポロジ情報は直接把握することはできないが、一方でＮＴＴ東西地域会社はユーザ住所／電話番号とユーザ収容局の対応関係を開示情報として提供している。ユーザ局／システムＩＤ情報については、本開示情報を元にＩＳＰ加入時に入力することができる。また他のＤＳＬ事業者もＮＴＴ東西地域会社のアクセスライン・局舎スペースを利用してサービスする場合がほとんどであるため[7]、同様に本開示情報からユーザＩＤとユーザ局／システムＩＤを対応づけることができる。
【００２５】
本例では、各ユーザがＩＳＰに接続する際にＲＡＤＩＵＳサーバにより認証を受け、このとき該サーバによりユーザに割り付けたＩＰアドレスをユーザ状態管理テーブルのユーザＩＰアクセス情報として自動的に入力する(フロー（1）)。
ＮＷ品質推定制御機能は、コンテンツサーバが各ユーザにコンテンツを配送するとき、当該配送セッションのトランスポートレイヤ品質、アプリケーションレイヤ品質、またはその両方を収集して良好、要注意、異常等の品質状態を判定し、ユーザ状態管理テーブルの品質状態領域に記述し（フロー（2））、さらに、ユーザ局／システムＩＤが同一となるユーザ毎に品質状態領域のデータを集計して良好・要注意・異常等のユーザ局／システムとしての状態を推定し、その結果をネットワーク状態管理テーブルに記述し保持する（フロー（3））。これにより、ユーザ局／システムを単位として、真のネットワーク品質状態を把握することができる。
【００２６】
〔実施例２〕
図１２は、ユーザ管理機能としてコンテンツ配送サービスのサービス認証機能を利用する場合の本発明の実施例を示す。
本実施例ではユーザはＲＡＤＩＵＳ認証を経てＯＣＮに接続した後、サービス認証サーバにアクセスして、サービスとしての認証を受ける。このときサービス認証サーバはユーザＩＤとＩＰアドレスの対応関係を把握することができ、結果をユーザ状態管理テーブルに入力する(フロー（1）)。以後のユーザ毎のネットワーク品質状態を推定(フロー（2）)、ユーザ局／システム毎の品質状態の推定(フロー（3）)は上記の実施例と同一である。
コンテンツ配送サービス事業者がＩＳＰと別の事業体である場合、ＲＡＤＩＵＳ等のＩＳＰ内部情報が開示される可能性は低いが、このようにサービス認証機能と連携することで、実施例１と同様のネットワーク品質推定制御が可能となる。ただしＩＳＰと別事業体の場合、コンテンツ配送サービス事業者がユーザのアクセスネットワーク事業者情報を入手するのは難しいと考えられるため、ユーザ状態管理テーブルの事業者ＩＤ領域への入力にあたっては、ユーザとサービス契約する際に利用するアクセスネットワーク事業者情報を取得する必要がある。
【００２７】
【発明の効果】
本発明により、特にパケット損失や輻輳が発生しやすいアクセスネットワークについて、アプリケーションレイヤ品質を含めた真のネットワーク品質の推定、および推定に基づくサーバアクセス制御が可能となる。また他事業者がアクセスネットワークを保有する場合であっても、例えば他事業者がユーザが接続されたユーザ局の情報を開示している場合であれば、ユーザ局を単位とした真のネットワーク品質推定、および推定に基づく制御が可能となる。
【００２８】
本方式のユーザ毎の品質状態管理において、ユーザがアクセスするコンテンツサーバのネットワーク上の位置を併せて管理し、サーバ局・ユーザ局が同一となる仮想リソース毎の品質指定を行うことで、ネットワークの状態を考慮した最適なコンテンツサーバの選択制御が可能となる。
また例えば同一ユーザ局に接続されたユーザのうち、異常状態にあるユーザが１名のみという場合、ネットワーク輻輳である可能性は低く、アクセスライン、ユーザ端末等に異常の原因があると推定される。このように本方式は、ネットワーク側、アクセスライン・ユーザ端末側のいずれに問題があるかの切り分けにも適用することができる。
【００２９】
以上により、広域バックボーンネットワークにおいて、映像ストリーミング等ネットワークの品質劣化が直接それ自体の品質に影響を及ぼすコンテンツを、高い品質・信頼性を維持してエンドユーザに配送することができる。広域に分散する多数のエンドユーザに配送できる広域性と配送の高品質化・高信頼化の両立により、コンテンツ配信・配送事業者はコンテンツホルダ、ＣＭスポンサ等の囲い込み、および収益性の向上が可能となる。
【００３０】
参考文献：
[1] 情報通信総合研究所「情報通信ハンドブック」ISBN4-915724-61-1
[2] 安田浩監修 未来ねっとシリーズ「ディジタルビジュアル技術」電気通信協会 ISBN4-88549-907-0
[3] 西郷，荒野，岡田，川口 「やさしいＯＣＮ」 ISBN4-88549-410-9
[4]www.microsoft.com/japan/sindows/windowsmedia/developers/wmpsdk/default.asp
[5] 「フレッツＡＤＳＬ vs Yahoo BB」日経コミュニケーション5-20, pp.104-111，2002
[6] www.acca.ne.jp
[7] 「ＤＳＬ普及状況公開ページ」,
www.soumu.go.jp/joho_tsusin/watsnew/dsl/index.html
【図面の簡単な説明】
【図１】ダウンロードアプリケーションの場合とストリーミングアプリケーションの場合におけるネットワーク輻輳の影響を示す図である。
【図２】代表的なインタネット接続サービスネットワークの構成例を示す図である。
【図３】代表的なインタネット接続サービスネットワークの他の構成例を示す図である。
【図４】本発明によるネットワーク品質推定方式の実現例を示す図である。
【図５】本発明によるアプリケーションレイヤ品質とトランスポートレイヤ品質によるネットワーク品質推定方法を示す図である。
【図６】本発明によるネットワーク品質推定に基づくサーバアクセス制御の実現例を示す図である。
【図７】本発明によるネットワーク内のより広範囲のエリアの品質推定を行う方法を示す図である。
【図８】本発明によるデータセンタ出口近傍におけるネットワーク品質推定方法を示す図である。
【図９】本発明によるデータセンタ出口近傍におけるネットワーク品質推定に基づくサーバアクセス制御の実現例を示す図である。
【図１０】本発明による複雑なトポロジのネットワークの品質推定及びサーバアクセス制御の実現例を示す図である。
【図１１】ユーザ管理サーバとしてＲＡＤＩＵＳ認証サーバを利用する本発明の実施例を示す図である。
【図１２】ユーザ管理サーバとしてサービス認証サーバを利用する本発明の他の実施例を示す図である。

Images