特許 5718977 要求応答並列ビデオサーバにおける負荷分散及び受付予定管理

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5718977

(24)【登録日】2015年3月27日

(45)【発行日】2015年5月13日

(54)【発明の名称】要求応答並列ビデオサーバにおける負荷分散及び受付予定管理

(51)【国際特許分類】

   H04N 21/262 20110101AFI20150423BHJP

   H04N 21/239 20110101ALI20150423BHJP

【ＦＩ】

   H04N21/262

   H04N21/239

【請求項の数】10

【全頁数】18

(21)【出願番号】特願2013-110606(P2013-110606)

(22)【出願日】2013年5月27日

(62)【分割の表示】特願2010-525182(P2010-525182)の分割

【原出願日】2008年9月19日

(65)【公開番号】特開2013-211897(P2013-211897A)

(43)【公開日】2013年10月10日

【審査請求日】2013年5月27日

(31)【優先権主張番号】11/857,755

(32)【優先日】2007年9月19日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】503275990

【氏名又は名称】ザ チャイニーズ ユニバーシティ オブ ホンコン

【氏名又は名称原語表記】ＴＨＥ ＣＨＩＮＥＳＥ ＵＮＩＶＥＲＳＩＴＹ ＯＦ ＨＯＮＧ ＫＯＮＧ

(74)【代理人】

【識別番号】100099759

【弁理士】

【氏名又は名称】青木 篤

(74)【代理人】

【識別番号】100092624

【弁理士】

【氏名又は名称】鶴田 準一

(74)【代理人】

【識別番号】100108383

【弁理士】

【氏名又は名称】下道 晶久

(74)【代理人】

【識別番号】100141162

【弁理士】

【氏名又は名称】森 啓

(72)【発明者】

【氏名】リー，イウ ブン

【審査官】 岩井 健二

(56)【参考文献】

【文献】 特開２００１−０４５０２３（ＪＰ，Ａ）

【文献】 特開平１０−０９１４６６（ＪＰ，Ａ）

【文献】 特開平０９−２０５６３４（ＪＰ，Ａ）

【文献】 特開平０９−１３８７５５（ＪＰ，Ａ）

【文献】 特開平０７−２７４１０７（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｎ ２１／００ − ２１／８５８

(57)【特許請求の範囲】

【請求項1】

第１受付スケジューラであって，該第１受付スケジューラをバックアップするように構成された少なくとも一つの第２受付スケジューラと並列に接続され，
複数の並列ビデオサーバにおける要求されたビデオセッションの開始時刻が変動するようにスケジュールし，
前記複数の並列ビデオサーバにおける，前記要求されたビデオセッションの開始のスケジュールを含む受付マップを，前記少なくとも一つの第２受付スケジューラに周期的に多対地送信する，ように構成された第１受付スケジューラを備え，
前記第１受付スケジューラ及び前記少なくとも一つの第２受付スケジューラは，主受付スケジューラのアドレスを要求する問合せメッセージをクライアントから受信し，前記問合せメッセージに応答して前記クライアントに前記主受付スケジューラのアドレスを送信するように構成される，システム。

【請求項2】

前記第１受付スケジューラは前記主受付スケジューラであり，前記少なくとも一つの第２受付スケジューラは少なくとも一つの従受付スケジューラである，請求項１に記載のシステム。

【請求項3】

前記少なくとも一つの第２受付スケジューラは，前記第１受付スケジューラが障害になったとき，新しい主受付スケジューラを動的に選出するように構成される，請求項２に記載のシステム。

【請求項4】

前記第１受付スケジューラは，前記受付マップの状態変化に応答して生成された監視パケットによって，前記受付マップを多対地送信するように構成される，請求項１に記載のシステム。

【請求項5】

前記監視パケットは，前記受付マップの現在の状態を表す少なくとも１ビットを含む，請求項４に記載のシステム。

【請求項6】

設定可能なタイムアウトパラメータ及び設定可能な再送信パラメータを有する高信頼データグラムプロトコル（ＲＤＰ）を用いるように構成された請求項１に記載のシステム。

【請求項7】

前記設定可能なタイムアウトパラメータ及び前記設定可能な再送信パラメータは，最大サービス遅延が所定の時間以上にならないように予め選択される，請求項６に記載のシステム。

【請求項8】

主受付スケジューラであって，該主受付スケジューラをバックアップする少なくとも一つの従受付スケジューラと並列に接続された主受付スケジューラにおいて，ビデオデータを受信するためのビデオセッションを開始する要求を受信するステップと，
前記主受付スケジューラを介して，複数の並列ビデオサーバにおける前記ビデオセッションの開始時刻が変動するようにスケジュールするステップと，
前記複数の並列ビデオサーバにおける，前記ビデオセッションの開始のスケジュールを含む受付マップを，前記主受付スケジューラから前記少なくとも一つの従受付スケジューラに周期的に多対地送信するステップと，を有し，
前記主受付スケジューラのアドレスを要求する問合せメッセージをクライアントから受信するステップと，
前記問合せメッセージに応答して前記クライアントに前記主受付スケジューラのアドレスを送信するステップと，を更に有する方法。

【請求項9】

受付をスケジュールする第１手段であって，該受付をスケジュールする第１手段をバックアップする少なくとも一つの受付をスケジュールする第２手段と並列に接続された第１手段が，ビデオデータを受信するためのビデオセッションを開始する要求を受信する手段と，
前記受付をスケジュールする第１手段が，複数の並列ビデオ提供手段における前記ビデオセッションの開始時刻が変動するようにスケジュールする手段と，
前記複数の並列ビデオ提供手段における前記ビデオセッションの開始のスケジュールを示す受付マップを，前記受付をスケジュールする第１手段から前記少なくとも一つの受付をスケジュールする第２手段へ周期的に多対地送信する手段と，を備え，
前記第１手段及び前記少なくとも一つの第２手段は，受付をスケジュールする主手段のアドレスを要求する問合せメッセージをクライアントから受信し，前記問合せメッセージに応答して前記クライアントに前記受付をスケジュールする主手段のアドレスを送信するように構成される，装置。

【請求項10】

前記受付をスケジュールする第１手段が前記受付をスケジュールする主手段を含み，前記少なくとも一つの受付をスケジュールする第２手段が少なくとも一つの受付をスケジュールする従手段を含む，請求項９に記載の装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は，ビデオデータサーバ技術に関し，より詳細には並列サーバ構成を用いたビデオオンデマンドシステム及び関連する実現方法に関する。なかでも本発明は，要求応答型（pull-based）並列ビデオサーバにおける負荷分散（load balancing）及び受付予定管理（admission scheduling）に関する。

【背景技術】

【0002】

要求応答並列ビデオサーバ構成は，例えば，Jack Y. B. Lee, “Parallel Video Servers - A Tutorial”, IEEE Multimedia, Vol. 5, No. 2, 1998年6月, pp. 20-28及びJack Y, B. Lee, and P. C. Wong,”Performance Analysis of a Pull-Based Parallel Video Server”, IEEE Trans. on Parallel and Distributed Systems, Vol. 11, No. 12, 2000年12月, pp. 217-231において研究され，記載されている。これらの構成は，例えば，W. J. Bolosky, J. S. Barrera, III, R. P. Draves, R. P. Fitzgerald, G. A. Gibson, M. B. Jones, S. P. Levi, N. P. Myhrvold, R. F. Rashid, “The Tiger Video Fileserver”, Proc. of the sixth International Workshop on Network and Operating System Support for Digital Audio and Video, IEEE Computer Society, 1996年4月，日本・逗子と，M. M. Buddhikot, G. M. Parulkar, “Efficient Data Layout, Scheduling and Playout Control in MARS”, Proc. NOSSDAV '95, 1995年と，M. Wu, W. Shu, “Scheduling for large-Scale Parallel Video Servers”, Proc. Sixth Symposium on the Frontiers of Massively Parallel Computation, 1996年10月, pp. 126-133と，の文献に記載されたサーバ主導型（push）サービスモデルと混同してはならない。

【0003】

次に示す表１は，以降の評価に用いる記法及び典型数値の表である。

【表1】

【0004】

並列ビデオサーバは，クライアントホストと相互接続網で接続された複数の独立なサーバを備える。相互接続網は，Fast Ethernet（登録商標）又はATM交換機のようなパケット交換機を用いて実現することができる。いわゆる共有なし（share-nothing）法によって，資源争奪によってシステムの調整可能性（scalability）が制限されないことが確実になる。相互接続網（例えばパケット交換機）によって，クライアントは各サーバからビデオデータをブロックごとに取得し，再生のためにそのビデオデータを並び替える（re-sequence）。システム内のサーバ数はＮ_ｓによって表され，クライアント数はＮ_ｃによって表される。

【0005】

並列ビデオサーバ構成の背後にある原理は，システム内のすべてのサーバからビデオ番組を並列送信する（striping）ことである。サーバの記憶領域を，それぞれＱバイトの固定サイズストライプユニットに分割してもよい。各ビデオ番組は，Ｑバイトのブロックでストライプ化され，図２に示すように巡回的に（round-robin）各サーバへ記憶される。固定サイズブロック並列送信アルゴリズムは，「時間並列送信（time striping）」と呼ばれるビデオフレーム単位の並列送信に対して，上述のLeeの”Parallel Video Servers - A Tutorial”においては「空間並列送信（space striping）」と呼ばれる。空間並列送信におけるストライプ単位は，ビデオ番組と比べると非常に小さい（キロバイト対メガバイト）ので，サーバ間での細粒度共有が可能になる。以降，本発明を空間並列送信に関して説明する。

【0006】

サーバレベルでの並列性利用は，単一サーバの容量限界を打破できるだけでなく，冗長性を用いてサーバレベルでの障害許容性も達成できる。サーバ複製及びデータ区分と異なり，並列方式においては，利用されるビデオ番組は小ユニットに分割され，サーバ並列送信（server striping）と呼ばれる技術によって，並列ビデオサーバ内の各サーバに分散される。ビデオ番組のビデオデータユニットは，（空間及び／又は時間の）並列送信ポリシによって各サーバから取得され，通信網を介してクライアントへ配信される。

【0007】

ビデオ番組はシステム内のすべてのサーバに分散されているので，最初に各ビデオブロックを対応するサーバから取得し，単一ビデオ流に併合させてからクライアントへ送信し，再生する必要がある。一般にビデオデータの併合処理（プロキシと呼ばれる）は，サーバで実現してもよいし（在サーバプロキシ），別個の計算機で実現してもよいし（独立プロキシ），クライアント計算機で実現してもよい（在クライアントプロキシ）。以降説明するシステムでは，在クライアントプロキシ構成を用いている。この選択は次の二面性を持つ。（ａ）低コスト，すなわち（在サーバプロキシのような）サーバ間の付加的なデータ転送，又は（独立プロキシのような）付加的なハードウェアが不要。（ｂ）より良い障害許容性，すなわちプロキシの障害は，同一計算機上で動作するクライアントだけに影響する。

【0008】

「サービスモデル」という用語は，ビデオデータが予定管理（scheduled）され，クライアントへ配信される方法を指す。クライアント要求応答型（client pull）及びサーバ主導型（server push）という二つの普通のサービスモデルがある。クライアント要求応答型モデルでは，クライアントが周期的にビデオデータを取得するための要求をサーバへ送信する。このモデルでは，クライアントがデータフローを駆動する。サーバ主導型モデルでは，ビデオセッションが始まると，サーバがビデオデータを周期的に取得して送信する。

【0009】

クライアント要求応答型サービスモデルでは，クライアントから送信された要求は，それぞれほかのどの要求とも独立にサーバで処理される。したがって同期は各クライアント要求に暗に含まれ，各サーバはクロック同期する必要がない。以降，クライアント要求応答型サービスモデルが用いられることを仮定する。クライアントが要求ｉ（ｉ≧０）をサーバｍｏｄ（ｉ，Ｎ_Ｓ）へ送信すると仮定しても一般性を失うことはない。各要求は，サーバがＱバイトのビデオデータを取得して，送信するきっかけとなる。

【0010】

並列ビデオサーバ型ビデオオンデマンドシステムの問題であって従来の単一サーバ型ビデオオンデマンドシステムにはない問題は，負荷分散である。小ストライプサイズでビデオ番組を各サーバから並列送信することによって平均負荷を均衡させることはできるが，各サーバの瞬時負荷はシステム内の無作為性によって変化することがある。この瞬時負荷不均衡によってサーバの性能が一時的に劣化し，クライアントにおける再生中断を起こすことがある。

【0011】

本発明をより良く理解するために，要求応答型サービスシステムにおける要求発生過程の分析的モデルを考慮するとよい。このモデルの一部は，以前に本願発明者によって開発され，上述の”Performance Analysis of a Pull-Based Parallel Video Server”で報告されている。システムがクレジット基準フロー制御アルゴリズムを用いてサーバからクライアントへのデータフローを管理すると仮定すると，クライアントはシステムの遅延偏差を吸収するためにＬ_Ｃ個のビデオデータバッファ（各Ｑバイト）を維持する。再生が始まる前に，クライアントはまず最初の（Ｌ_Ｃ−１）個のバッファをプリフェッチし，そして先頭（head-of-line）ビデオブロックがビデオデコーダに送信されて再生されるごとに，もう１個のビデオブロックを要求する。

【0012】

ビデオクライアントがＴ_ａｖｇ秒間隔の平均要求間隔で要求を発生すると仮定し，要求発生過程における変動を説明するために，任意のｋ個の連続する要求間の時間が式（１）で制限されるようにＴ_ＤＶを上記過程の最大偏差とする。
ｍａｘ｛（（ｋ−１）Ｔ_ａｖｇ−Ｔ_ＤＶ），０）｝≦ｔ≦（（ｋ−１）Ｔ_ａｖｇ＋Ｔ_ＤＶ） （１）

【0013】

クライアントはＮ_Ｓ個のサーバに対して巡回型で要求を発生するので，同一のサーバに送信される任意のｋ個の連続する要求の間の対応する時間は式（２）で得られる。
ｍａｘ｛（（ｋ−１）Ｎ_ＳＴ_ａｖｇ−Ｔ_ＤＶ），０｝≦ｔ≦（（ｋ−１）Ｎ_ＳＴ_ａｖｇ＋Ｔ_ＤＶ） （２）

【0014】

この要求発生モデルを用いて次のことが示される。

【0015】

＜定理１＞ ｎ個のクライアントが独立に要求を発生し，各クライアントがシステム内のＮ_Ｓ個のサーバへ巡回型で要求を送信すると仮定する。すると１個のサーバがｋ個のビデオデータ要求を受信する最小時間は式（３）で与えられる。

【数1】

【0016】

システム内のサーバ数に関わらず，定理１は，複数のクライアントが偶然に同期したとき，サーバは最大ｎ個の要求を同時に受信することがある（Ｔ_{Ｒｅｑｕｅｓｔ}^ｍｉｎ（ｋ，ｎ）＝０）。このクライアント同期問題は，以前はシステムの調整可能性を著しく制限するとされていた。

【0017】

瞬時負荷不均衡を防止するため，受付スケジューラを用いて新規ビデオセッションの開始時刻を明示的に予定管理し，同期を避ける。以前，本願発明者は第三者と共に，受付スケジューラに用いるために図３（先行技術）の第１の線（ａ）に示す食違い（staggering）方式を提案した。このスケジューラは長さＴ_{ｒｏｕｎｄ}秒の受付マップを維持し，該受付マップは長さ
Ｔ_ｓｌｏｔ＝Ｔ_{ｒｏｕｎｄ}／Ｎ_ｓｌｏｔ （秒) （４）
のｎ_ｓｌｏｔ個のスロットに分割される。

【0018】

各時間スロットは，空き又は使用中の二つの状態を有する。クライアントが新規ビデオセッションを開始しようとしたとき，最初にスケジューラに要求を送信する。処理遅延を無視し，その要求がスケジューラに時刻ｔに到着したと仮定すると，スケジューラは，時間スロットｎが空きであるときに限って新規セッションを受け付ける。ここでｎは式（５）で与えられる。

【数2】

これは図３（先行技術）の第２の線（ｂ）に示されている。

【0019】

新規セッションを受け付けるため，スケジューラは，スロットｎが始まったときクライアントへ応答を返信し，セッションが終了するまで対応する時間スロットに使用中の印を付ける。逆に，要求された時間スロットが既に使用中のときは，スケジューラは図３（先行技術）の第３の線（ｃ）に示すとおり，空き時間スロットが利用可能になるまで待機する（実効的にｔを増加させる）。Ｔ_{ｒｏｕｎｄ}＝Ｎ_ＳＴ_ａｖｇと設定し，次の定理２によって最悪ケースの負荷が得られる。

【0020】

＜定理２＞ 受付スケジューラがパラメータＴ_{ｒｏｕｎｄ}＝Ｎ_ＳＴ_ａｖｇを用いて使用され，かつｎ個のクライアントがあるとき，一つのサーバがｋ個のビデオデータ要求を受信する時間は式（６）で与えられる。

【数3】

【0021】

定理１と比較すると，上記の要求は受付スケジューラで拡散されて，最悪ケースの負荷は大幅に減少している。

【0022】

要求応答型ＶｏＤシステムの主要性能尺度は，ビデオサーバにおけるサービス遅延であり，Ｄ_ｍａｘで表される。サービス遅延は，サーバがクライアントからの要求を受信してから，要求されたビデオブロックが完全に送信されるまでの時間と定義される。サービス遅延は，ビデオ再生が確実に連続性を保つためクライアントに必要なバッファ量を決定する。サービス遅延は一般に，同時ビデオセッション数と共に増加するので，サービス遅延はシステムが対応できる最大同時ビデオセッション数に実効上の制限を与える。ディスクモデルと，網モデルと，定理２の限界値と，を仮定すると，サービス遅延の上限値が得られる。この最大サービス遅延を用いて，種々のパラメータ下でのシステム性能を評価することができる。

【0023】

受付スケジューラが実効的に瞬時負荷不均衡を防止し，システムを多数のサーバに拡張できることは前に示した。しかし，次の二つの仮定がある。すなわち，（ａ）網遅延がない，（ｂ）制御メッセージを配信する際にパケット損失がない，ことである。これまで説明してきたモデル，すなわち上述の"Performance Analysis of a Pull-Based Parallel Video Server"における本願発明者の先行技術から得られるモデルは，網遅延及び遅延ジッタの影響，並びにパケット損失を組み込んでいない。

【0024】

本願発明者が開発した先行モデルにおいて考慮されていない課題に，クライアント‐受付スケジューラ間リンク及びクライアント‐サーバ間リンクにおけるパケット損失がある。今日の高速網において，パケット損失は比較的まれであるが，依然無視することはできない。第１に，クライアントと受付スケジューラとの間で制御パケットが損失すると，システムの状態が不一致になる。例えば，受付スケジューラからクライアントへ送信された受付承認要求が損失すると，損失パケットが見付かるまで全予定期間Ｎ_ＳＴ_ａｖｇを待機しなければならないことがある。なぜならば，最悪ケースでは，受付スケジューラは実際，食違い要求条件によって，新規セッションの受付を遅延させる必要があるときがあるからである。一方，クライアントがビデオセッションを開始していなくても，指定された時間スロットが同じ期間だけ使用中になる。したがって，たとえシステムが能力以下で動作していても，新規受付要求が拒否されることがある。第２に，クライアント‐サーバ間リンクにおいて制御パケットが損失すると，サーバはクライアントの要求を受信したときだけビデオデータを送信するので，ビデオブロックが失われることになる。したがって，クライアント‐受付スケジューラ間リンク及びクライアント‐サーバ間リンク双方のための制御経路は，高信頼でなければならない。

【0025】

パケット損失問題に取り組むため，制御パケットを搬送するために高信頼転送プロトコルを使用してもよい。しかし，通常のデータ応用と異なり，転送プロトコルの選択はシステム性能に重大な影響がある。その理由を理解するために，クライアント‐受付スケジューラ間リンク用の転送プロトコルにＴＣＰを用いたとする。パケット損失が起こると，ＴＣＰプロトコルは期限切れ（time out）となり，パケットが正しく配信されるか，リンクが障害であるとみなされるまでパケットを再送信する。（ＴＣＰを含む）ほとんどの転送プロトコルは，適応アルゴリズムを用いて動的に期限しきい値を調整するので，複数の再送信が必要なときは，期限は大幅に増加する。

【0026】

実際上，このような転送プロトコルによってもたらされる最悪ケースの遅延は，何十秒にも上る。このような転送プロトコルを制御情報の搬送に用いると，（ミリ秒単位である）平均網遅延に比べて，サーバにおける最悪ケース負荷は大幅に増加する。

【0027】

瞬時負荷不均衡が発生することがあり，要求応答型並列ビデオシステムの性能を大幅に妨げることが分かった。受付スケジューラはシステム内の各サーバの瞬時負荷均衡を維持するのに重要であり，また全システムの単一障害点になることがある。したがって，要求応答型構成において障害点及び性能劣化を避けるための構成及び支援処理が必要である。このような条件下でビデオデータスループットを改善する転送プロトコルが提供される。

【発明の概要】

【課題を解決するための手段】

【0028】

本発明によれば，オンデマンド型ビデオシステムに有用な要求応答型並列ビデオサーバシステム及び実現方法は，主受付スケジューラと並列に動作する複数の従受付スケジューラを含み，それらはパケットのジッタ及び損失，並びに網遅延に対処するプロトコルによって，一群の要求応答型ビデオサーバへの接続を制御する主受付スケジューラを支援する。

【0029】

冗長受付スケジューラの構成及び機能要求条件を決定するために，動作モデルの形態による解析ツールが開発され，該ツールはクライアントと，受付スケジューラと，サーバとの間の通信リンクにおける網遅延と，遅延ジッタと，パケット損失と，を組み込んでいる。このモデルは，本願発明者が開発し，上述の"Performance Analysis of a Pull-Based Parallel Video Server"で報告した以前のモデルの拡張である。

【0030】

本発明は，以降の詳細な説明及び付属する図面を参照することによって，より良く理解することができる。

【図面の簡単な説明】

【0031】

【図1】本発明及び本発明の方法によるシステムのブロック図である。

【図2】一つの先行技術による５台のサーバ主導型並列ビデオサーバシステムのビデオ並列送信の図である。

【図3】先行技術によるビデオスケジューラの三つの動作，すなわち（ａ）期間Ｔ_{ｒｏｕｎｄ}及びＮ_ｓｌｏｔ個の受付スロットを有する受付スケジューラの構成，（ｂ）要求されたスロットが空きのとき，即時に新規ビデオセッションを許可する構成，（ｃ）空きスロットが利用可能になるまで新規ビデオセッションを遅延させる構成，を示す時間チャートである。

【図4】先行技術において，クロックジッタによるスロット割当ての不統一がどのように起きるかを示す二つの受付スケジューラの時間チャートである。

【図5】受付予定管理を行ったとき及び受付予定管理を行わないときの最大サービス遅延と平均網遅延を比較する時間軸上のグラフである。

【発明を実施するための形態】

【0032】

図１は，本発明によるビデオオンデマンドシステム１０であって，本発明の方法によって動作するシステムのブロック図であり，複製受付スケジューラを示す図である。通常多数のビデオクライアント１２，１４，１６が１又は複数の通信リンク１８を介して受付スケジューラ２２，２４，２６の集合２０に接続される。受付スケジューラのうち一つが主受付スケジューラ２０に指定され，残りが従受付スケジューラ２４，２６に指定される。主受付スケジューラ２０は，通信リンク３０を介して並列ビデオサーバ集合２８に接続され，通信チャネル３２，３４，３６を介して対応するビデオクライアント１２，１４，１６へのビデオ出力連続送信（streaming）を制御するために用いる受付マップを設定する（受付マップは，各従受付スケジューラ２４，２６で独立に複製される）。受付スケジューラは，以降説明するように，通信リンク３８，４０，４２を介して互いに多対地送信（multicast）を行う。

【0033】

図１に示した複製方式では，Ｎ_Ａ個の同じ受付スケジューラ２２，２４，２６が同時に運転される。各受付スケジューラ２２，２４，２６は，受付スケジューラ２２，２４，２６のうち少なくとも一つが機能している限り，システムが動作し続けるように別個の計算ノードで動作する。

【0034】

複数の受付スケジューラがあるので，クライアント‐スケジューラ間通信の調整が必要である。最初は，クライアントがＮ_Ａ個すべての受付スケジューラへ同時に要求を送信し，そのうち任意の一つから応答が返却されたとき，セッションを開始するように試みるかも知れない。しかしこの方法は，クライアント‐受付スケジューラ間リンク遅延が一定でないか，各受付スケジューラの時計が同期していないとき，受付スケジューラ間の不一致を招くことがある。図４は，二つの受付スケジューラ及び三つのクライアントを用いてこの問題を示す図である。各受付要求は互いに順不同の受付許可を発生するので，特定の順序での要求と，各受付スケジューラ間のクロックジッタと，によって，二つの受付スケジューラのスロット指定が不一致になる。

【0035】

この問題を解決するため，同時には唯一つの受付スケジューラを活性とする方式が用いられる。主受付スケジューラ２２は残りの従受付スケジューラ２４，２６の状態を更新するために，通信リンク３８，４０を介して更新された状態情報（受付マップ）を周期的に多対地送信する働きをする。この方式には次の三つの重要な要素がある。すなわち，（ａ）受付スケジューラの障害を検出する監視（heartbeat）プロトコル，（ｂ）現在の主受付スケジューラが障害になったとき，新規主受付スケジューラを動的に選出する選出手続，（ｃ）クライアント初期化の際にクライアントが主受付スケジューラを探索するための起動（bootstrap）プロトコル，である。これら要素をそれぞれ以降説明する。

【0036】

上述の定理に関連し，先行技術の図に示した受付スケジューラの方法の効用を高めるため，各定理に沿った次の拡張をここに開示する。

【0037】

網遅延の変動に対処するために，クライアントと受付スケジューラとの間の平均網遅延をＤ_Ａとし，遅延ジッタがＤ_Ａ^＋及びＤ_Ａ⁻で制限されるものとすると，ｄ_Ａで表される実際の遅延は式（７）で保証される。
（Ｄ_Ａ＋Ｄ_Ａ⁻） ≦ ｄ_Ａ ≦ （Ｄ_Ａ＋Ｄ_Ａ^＋） （７）

【0038】

受付スケジューラからの受付応答は，クライアントに到着する前にこの追加遅延を受けるので，この遅延がビデオセッションの開始時刻に影響する。特に，ビデオクライアントは，受付スケジューラが受付許可したｄ_Ａ秒後に最初のビデオ要求を送信開始する。

【0039】

同様に，クライアントとビデオサーバとの間の平均網遅延をＤ_Ｓとし，Ｄ_Ｓ^＋及びＤ_Ｓ⁻を対応する遅延ジッタとすると，ｄ_Ｓで表される実際の遅延は式（８）で保証される。
（Ｄ_Ｓ＋Ｄ_Ｓ⁻） ≦ ｄ_Ｓ ≦ （Ｄ_Ｓ＋Ｄ_Ｓ^＋） （８）

【0040】

この追加遅延が，各サーバに要求が到着する時刻に変動を与える。

【0041】

網（例えばＡＴＭ）がサービス品質を保証しているときは，実際上これらの遅延及び遅延ジッタは事前に決定することができる。又は，ベンチマークによって実験的に推定することもできる。

【0042】

クライアント‐サーバ間リンクの遅延及び遅延ジッタのために，要求発生時刻はその要求がサーバに到着する時刻と同じではない。クライアント‐サーバ間リンク遅延はジッタを有するので，同一のクライアントが送信したｋ個の要求が一つのサーバに到着するまでの時間は式（９）で制限されることが示される。
ｍａｘ｛（（ｋ−１）Ｎ_ｓＴ_ａｖｇ−Ｔ_ＤＶ−（Ｄ_Ｓ＋−Ｄ_Ｓ−）），０｝≦ｔ≦（（ｋ−１）Ｎ_ＳＴ_ａｖｇ＋Ｔ_ＤＶ＋（Ｄ_Ｓ＋−Ｄ_Ｓ−）） （９）

【0043】

この条件及びクライアント‐サーバリンク遅延ジッタによる開始時刻変動を組み込み，定理３は，定理２を拡張して，ｋ個の要求が一つのサーバに到着する時間幅の下限を定める。

【0044】

＜定理３＞ 網遅延ジッタをＤ_Ａ^＋，Ｄ_Ａ⁻，Ｄ_Ｓ^＋，Ｄ_Ｓ⁻とすると，一つのサーバがｎ個のクライアントからｋ個のビデオデータ要求を受信する最小時間は式（１０）で得られる。

【数4】

【0045】

サーバにおける最悪ケース負荷を知れば，サーバにおける最大サービス遅延及びクライアントにおけるクライアントバッファ要求を含む，種々の性能指標を得ることができる。

【0046】

パケット損失によって生じる不必要な遅延を避けるため，生じる遅延が過剰にならないように転送プロトコルを高信頼，かつ時間依存にする必要がある。遅延ジッタは制限されているので，期限は実際には適応可能である必要はない。

【0047】

複雑な期限及び再送信アルゴリズムを用いる代わりに，プログラム可能な期限及び再送信パラメータを有する単純で効率のよい高信頼データグラムプロトコル（ＲＤＰ）が用いられる。詳細には，このプロトコルは，システム初期化の際にアプリケーションによって設定される固定期限Ｔ_ＯＵＴ及び最大再送信数Ｎ_ｒｅｔｘ双方を用いる。クライアント‐受付スケジューラ間リンク及びクライアント‐サーバ間リンクの遅延及び遅延ジッタによって，期限しきい値は式（１１）のように選ぶことができる。

【数5】

ここで，Ｔ^Ａ_ｏｕｔ及びＴ^Ｓ_ｏｕｔはそれぞれ，クライアント‐受付スケジューラ間リンク及びクライアント‐サーバ間リンクの期限しきい値である。類似して，所望の最大損失確率βによって，最大再送信数を式（１２）のように選ぶことができる。

【数6】

ここでρ_Ａ及びρ_Ｓはそれぞれ，クライアント‐受付スケジューラ間リンク及びクライアント‐サーバ間リンクのパケット損失確率である。式（１２）を再整理し，式（１３）によって必要なパラメータを得ることができる。

【数7】

【0048】

ＲＤＰ配下では，該プロトコルに起因する最大遅延（すなわち網遅延を除く遅延）は，Ｔ_ｏｕｔ（Ｎ_ｒｅｔｘ−１）で制限される。再送信が起こらないときＲＤＰはどんな追加遅延も生じさせないので，生じる遅延は，Ｄ_Ａ^＋及びＤ_Ａ⁻に加えて式（１４）の追加遅延ジッタとして組み込むことができる。

【数8】

したがって，定理３を拡張してこの新規遅延ジッタを組み込むことができる。

【0049】

＜定理４＞ パケット損失による遅延ジッタが式（１４）で与えられるとすると，サーバがｎ個のクライアントからｋ個のビデオデータ要求を受信する最小時間は式（１５）で与えられる。

【数9】

【0050】

本発明によって監視プロトコルが実現される。各複製受付スケジューラは，通信リンク３８，４０，４２を介してＴ_ｈｂ秒ごとにすべてのほかの受付スケジューラへ監視パケットを多対地送信する。ある受付スケジューラ２２からＮ_ｈｂ個の監視パケットが連続して受信されなかったとき，当該受付スケジューラは障害になったとみなされる。網遅延を無視すれば，すべてのほかの受付スケジューラ２４，２６は式（１６）で与えられる最大遅延後に受付スケジューラの障害を発見する。
Ｄ_Ｆ＝Ｔ_ｈｂＮ_ｈｂ （１６）

【0051】

主受付スケジューラの監視パケットは，二つの点で従受付スケジューラの監視パケットと異なる。第一に前者は受付マップの現在の状態を記録したビットベクトルを含む。従受付スケジューラ２４，２６はこのビットベクトルを受信すると，自己の受付マップを更新して主受付スケジューラ２２と同期させる。第２に，監視パケットは受付マップに状態変化があったときいつでも発生される。したがって，監視間隔はＴ_ｈｂより短いことがある。

【0052】

各スケジューラ２２，２４，２６は，正常な受付スケジューラのリストを維持する。各受付スケジューラが一意なＩＰアドレスを有する別個の計算機上で動作すると仮定すると，上記のリストは受付スケジューラのＩＰアドレスを用いて構成され，４バイトのＩＰアドレスを符号なし整数とみなしてソートされる。監視プロトコルを用いて障害になった受付スケジューラはリストから除かれ，新規の（回復した）受付スケジューラがリストに挿入される。このリストは，次に説明するように新規の主受付スケジューラを選出するために用いられる。次に監視プロトコルの擬似コードを示す。

【0053】

＜監視プロトコルの擬似コード＞
State Variables:
AdmissionMap 受付マップの状態を示すビットベクトル
FunctionalScheduler 正常受付スケジューラのリスト

Procedure_Generate_Heartbeats(Thb)
{
while (system running) {
if admission scheduler is Master then
Multicasts a heartbeat packet containing AdmissionMap;
else
Multicasts a heartbeat packet w/o AdmissionMap
Sleep(Thb);
}
}

Procedure_Receive_Heartbeat(scheduler i)
{
if scheduler i is not in FunctionalSchedulers then
add scheduler i to FunctionalSchedulers;
if scheduler i is Master then
Update AdmissionMap;
}

Procedure_Detect_Scheduler_Failure()
{
while (system running) {
for each scheduler in FunctionalSchedulers {
if no heartbeats received for DF seconds then
{
remove scheduler from FunctionalSchedulers;
if scheduler is Master then run Procedure_Election()
}
}
}
}

【0054】

従受付スケジューラが障害のときは，主受付スケジューラ２２だけが受付に用いられるので何の操作も行う必要はない。すべての正常な受付スケジューラは，障害になった受付スケジューラから連続してＮ_ｈｂ個の監視パケットを受信しなかったとき，単にその障害を記録する。

【0055】

逆に主受付スケジューラ２２が障害になったときは，選出手続を開始する必要がある。各従受付スケジューラは正常受付スケジューラのリストを維持しているので，リストの先頭にあるものを新規自主受付スケジューラに選出する。この選出手続は，受付スケジューラ間でデータ交換を必要としない。そして新規主受付スケジューラは，すべてのクライアントと同様にすべての受付スケジューラへもメッセージを同報し，選出結果を通知する。この選出手続は主受付スケジューラの障害が検出されたときだけ行われる。したがって，障害になった受付スケジューラがオンラインに復帰しても，現用の主受付スケジューラが障害にならない限り，主受付スケジューラに再度選出されることはない。選出手続の擬似コードを次に示す。

【0056】

＜選出手続の擬似コード＞
State Variables:
AdmissionMap 受付マップの状態を示すビットベクトル
FunctionalScheduler 正常受付スケジューラのリスト

Procedure_Election()
{
New_master = scheduler at the top of FunctionalSchedulers;
if myself is New_master then
Multicast election result and AdmissionMap to all schedulers
}

【0057】

活性なクライアント１２，１４，１６は，現用主受付スケジューラからの同報メッセージを監視することによって，どれが現用主受付スケジューラか常に分かっているが，（例えば電源投入又はリセット後の）新規に初期化されたクライアントは，どの受付スケジューラが主受付スケジューラか分からない。この場合，そのクライアントは起動プロトコルを用いて主受付スケジューラを探索する。詳細には，新規に活性化されたクライアントは最初に，ドメイン名システム（ＤＮＳ）を用いてすべての受付スケジューラ２２，２４，２６のＩＰアドレスリストを取得する。これは，すべての受付スケジューラのＩＰアドレスと一つのホスト名（例えば，admission.xxx.com）とを関係付けることによって行うことができる。そしてクライアントはこのリストを用いてリストの先頭にある受付スケジューラへ問合せメッセージを送信して，現用主受付スケジューラのアドレスを要求する。応答がクライアントへ返却されたとき，この手続は終了する。そうでなければ，クライアントはリストの２番目にある受付スケジューラを試し，応答が返却されるまで同様に続ける。少なくとも１つの受付スケジューラが正常であれば，クライアントは現用主受付スケジューラを探索して新規ビデオセッションを開始することができる。この起動プロトコルの擬似コードを次に示す。

【0058】

State Variables:
AdmissionMap 受付マップの状態を示すビットベクトル
FunctionalScheduler 正常受付スケジューラのリスト
ListOfAllSchedulers 運用中かどうかを問わないすべての受付スケジューラのリスト

Procedure_Bootstrap_Request()
{
Obtain ListOfAllSchedulers from DNS;
For each scheduler in ListOfAllSchedulers
{
Send query to scheduler to request address of current Master;
if no reply from scheduler after a time Tout then next scheduler;
if received reply from scheduler then
{
update AdmissionMap and FunctionalSchedulers;
exit;
}
}
}

Procedure_Bootstrap_Reply()
{
While (system running)
{
Wait for bootstrap request message;
Reply address of Master, AdmissionMap, and FunctionalSchedulers;
}
}

【0059】

本発明による複製方式は，二つの点で負荷分散に影響を与える。第１に，各受付スケジューラは別個の計算機上で動作しているので，それらの内部クロックは正確には同期していない。クロック同期プロトコルを用いて任意の二つの受付スケジューラ間のクロックジッタが最大Ｄ_Ｃ秒以下に維持されていると仮定すると，主受付スケジューラが障害になり，新規選出された主受付スケジューラが引き継いだとき，既存のクライアントの開始時刻は，新規主受付スケジューラの時計に対して最大Ｄ_Ｃ秒のオフセットを有する。このジッタは，次のように本願システムに組み込むことができる。

【0060】

＜定理５＞ 受付スケジューラの最大クロックジッタをＤ_Ｃとすると，サーバがｎ個のクライアントからｋ個のビデオデータ要求を受信する最小時間は，式（１７）で与えられる。

【数10】

【0061】

主受付スケジューラは受付マップが更新されるごとに監視パケットを多対地送信するが，パケットは依然失われることがある。主受付スケジューラが障害になったとき，更新はいくつかの従受付スケジューラには伝わらない。受付スケジューラが正常なとき，監視パケットが（Ｎ_ｈｂ−１）を超えて連続して失われることはないと仮定すると，主受付スケジューラの受付マップと各従受付スケジューラの受付マップとは，高々（Ｎ_ｈｂ−１）スロットしか違わない。主受付スケジューラが障害のとき，これらのスロットは二つのクライアントに指定されることがある。式（１７）は，この状態不一致に対処するため，式（１８）のように拡張することができる。

【数11】

【0062】

式（１８）は一つの受付スケジューラの障害だけに対処するが，ほとんどの場合，実用には十分である。そのような確率が無視できないときは，類似の導出によって複数受付スケジューラの障害に対処するように拡張することもできる。

【0063】

実際上，本願発明に関係するシステム及び技法は，システムが最終利用者，すなわちビデオクライアントに実効的に応答できないほどの最大サービス遅延を有することはない。最大許容サービス遅延は３秒と考えられる。基本的なパラメータは，上記表１に列挙されている。図５は最大サービス遅延と，±１０％のジッタを有する網遅延との比較を示す評価結果例である。比較のために，受付スケジューラがないときの最大サービス遅延も示されている。更に種々の最大サービス遅延対パケット損失，最大サービス遅延対最大受付スケジューラクロックジッタ，最大サービス遅延及び対受付スケジューラ障害クロックジッタのシナリオでの評価によって，表１のパラメータによれば最大サービス遅延は１．２秒を超えないことが示された。

【0064】

特定の実施例を参照して本願発明を説明した。当業者にはほかの実施例も明白であろう。したがって，本願発明は本願の特許請求の範囲の文言を除いては制限されないものとする。

【図1】

【図2】

【図3】

【図4】

【図5】