(57)【要約】  本発明は、リアルタイムコンテンツ配信に関するクライアント入力バッファの欠乏及びオーバーフローの状態を検出するための解決策に関する。前記装置は、前記クライアントの入力バッファの充填要素の動的な測定を通じてクライアントの上流で機能する。従って、欠乏又はオーバーフローの状況の発生を予測し、記憶されたビデオシーケンスの挿入又は待ち行列のパケットの記憶などの動作を取ることができる。
2009500975.tif 000002
【特許請求の範囲】
【請求項１】
パケットによるコンテンツ配信ネットワーク（１．２）に接続可能な装置（２．３）であって、前記コンテンツは、少なくとも１つのクライアント（２．４）に対して意図されたデジタルデータのストリームの形式で送信され、前記少なくとも１つのクライアントは、コンテンツを再生するためにデータをデコードする前に、受信した当該データを記憶する入力バッファ（２．９、２．１０）を有し、前記装置は、前記配信ネットワーク（１．２）及び当該配信ネットワーク（１．２）に接続された前記少なくとも１つのクライアント（２．４）間において、前記データパケットを通過させる手段（３．２７）を有し、前記手段は、前記クライアントのバッファに対して意図された全てのパケットを通過させるデータパケットを通過させる手段であって、前記装置は、
前記クライアントの少なくとも１つのパラメータに従って、前記少なくとも１つのクライアントの前記入力バッファの使用率を測定する演算手段（３．２１）であって、前記パラメータは、
前記配信ネットワークに接続された前記少なくとも１つのクライアントの入力バッファのサイズ、
データストリームを受信したときにデコードを開始する前に、前記少なくとも１つのクライアントが記憶するデータの量、
前記少なくとも１つのクライアントが前記入力バッファを空にするために使用する再生ビットレート
の中から得られる演算手段と、
前記クライアントの入力バッファの前記測定された使用率が閾値を下回ったときにクライアントへコンテンツ置換シーケンスを送信するための手段と
を備えることを特徴とする装置。
【請求項２】
リアルタイムコンテンツ置換シーケンスのための記憶手段を備えることを特徴とする請求項１に記載の装置。
【請求項３】
前記入力バッファの使用率の測定が第二の閾値を上回るクライアントに対して意図された前記データパケットを一時的に記憶するのに適していることを特徴とする請求項１又は２に記載の装置。
【請求項４】
クライアントの使用率の測定が第三の閾値を下回るとき、警告メッセージを送信するのに適していることを特徴とする請求項１から３のいずれか１項に記載の装置。
【請求項５】
クライアントの使用率の測定が第四の閾値を上回っているとき、警告メッセージを送信するのに適していることを特徴とする請求項１から４のいずれか１項に記載の装置。
【請求項６】
ＤＳＬＡＭ（Ｄｉｇｉｔａｌ  Ｓｕｂｓｃｒｉｂｅｒ  Ｌｉｎｅ  Ａｃｃｅｓｓ  Ｍｕｌｔｉｐｌｅｘｅｒ）であることを特徴とする請求項１から５のいずれか１項に記載の装置。
【請求項７】
デジタルデータのストリームの形式で送信されるコンテンツのデコード装置の入力バッファの使用率を測定するための方法であって、前記デコード装置は、クライアントと呼ばれ、前記方法は、パケット交換によるコンテンツ配信ネットワークに接続可能な監視装置による方法であり、前記監視装置は、前記配信ネットワーク及び当該配信ネットワークに接続されたクライアント間において、前記データパケットを通過させる手段を有し、前記手段は、前記クライアント及び前記配信ネットワーク間において、全ての前記データパケットを通過させるデータパケットを通過させ、前記方法は、
前記入力バッファのサイズ、デコードを開始する前に記憶するデータの量、及び前記少なくとも１つのクライアントに対して意図された前記監視装置を通過したデータパケットに従って、前記少なくとも１つのクライアントの入力バッファの使用率を測定する算定ステップと、
前記クライアントの入力バッファの前記測定された使用率が閾値を下回ったときにクライアントへコンテンツ置換シーケンスを送信するステップと
を備えることを特徴とする方法。
【請求項８】
前記使用率の測定の算定は、定期的な方法で実行されることを特徴とする請求項７に記載の方法。
【請求項９】
前記使用率の測定の算定は、データパケットがクライアントへ送信される毎に実行されることを特徴とする請求項７又は８に記載の方法。
【請求項１０】
前記入力バッファの使用率の測定が第二の閾値を上回るクライアントに対して意図された前記データパケットを一時的に記憶するステップを更に備えることを特徴とする請求項７から９のいずれか１項に記載の方法。
【請求項１１】
前記使用率の測定が第三の閾値を下回るとき、警告メッセージを送信するステップを更に備えることを特徴とする請求項７から１０のいずれか１項に記載の方法。
【請求項１２】
クライアントの前記使用率の測定が第四の閾値を下回っているとき、警告メッセージを送信するステップを更に備えることを特徴とする請求項７から１１のいずれか１項に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サーバからクライアントへのデジタルコンテンツ配信（ｄｉｓｔｒｉｂｕｔｉｏｎ）の分野に関する。より詳細には、ＩＰネットワークなどの配信ネットワークにおけるビデオ配信の文脈に関する。
【背景技術】
【０００２】
現在、ＩＰネットワークなどのパケット交換配信ネットワークを介した音楽やビデオなどのデジタルコンテンツの配信が普及している。実際、インターネットネットワークの発展は、これらの技術を発展へと導いた。
【０００３】
サーバによるＩＰネットワークを介したカスタマ（クライアント）へのデジタルコンテンツの配信。これらのネットワークは、この技術分野における当業者の用語で、通常「ジッタ（ｊｉｔｔｅｒ）」と呼ばれるパケットのルーティングにおける時間の偏差（ｄｉｓｔｏｒｔｉｏｎ）が生じることが特徴である。また、これらのネットワークは、例えば、サーバ及びクライアント間のデータを転送する中間ゲートウェイの輻輳によってパケット損失が生じやすい。配信されたコンテンツの再生は、最大許容偏差（ｍａｘｉｍｕｍ  ａｕｔｈｏｒｉｓｅｄ  ｄｉｓｔｏｒｔｉｏｎｓ）に制約を与える。
【０００４】
これらの偏差及び損失と戦うために、クライアントは通常、受信したパケットを記憶する入力バッファを統合する。これらのバッファはその後、ネットワークを介してサーバから届くパケットによって充填され、一方で、データがコンテンツ再生によって消費されたときに、クライアントはバッファを空にする。正しいコンテンツ再生のために、これらの入力バッファは、アンダーフローを引き起こすほどバッファを完全に空にしてはならず、また、オーバーフローを引き起こすほどバッファを完全に充填してはならない。実際、アンダーフローで、再生はデータ不足となり、中断される。一方、オーバーフローで、バッファは到着するパケットを記憶できなくなり、従って、ここで再び、コンテンツの再生を中断へと導くデータ損失を引き起こす。
【０００５】
非特許文献１によれば、ストリーム円滑化技術が、装置のバッファメモリのアンダーフロー又はオーバーフローを防ぐために実装されている。それでもなお、この技術は、ストリーム転送時間の制御が不十分であるネットワークのデータ転送に関して、最適化されていない（特に、ベストエフォート型（ｂｅｓｔ  ｅｆｆｏｒｔ）技術が用いられているネットワークの場合）。
【０００６】
待ち時間やパケット損失の点で何の保証も提供しないＩＰネットワークにおける送信は、前述のアンダーフローやオーバーフローの状況が発生し得ないということのみ確実にすることができる。この場合、興味深いのは、これらの問題の被害を排除し、又は少なくともユーザを限定することを可能とする対策をとりえる方法等で、これらの状況の発生を検出できるということである。
【０００７】
装置の入力バッファ使用率（ｆｉｌｌｉｎｇ  ｒａｔｅ）の監視をその装置自体のレベルで実行することが、例えば、特許文献１で知られている。アンダーフロー又はオーバーフローのイベントで、装置は警告をサーバに送る。サーバは従って、発生する問題に対処する方法をとる。
【０００８】
【非特許文献１】Ｓｕｂｈａｂｒａｔａ  ＆  ＡＩ著、「Ｏｎｌｉｎｅ  ｓｍｏｏｔｈｉｎｇ  ｏｆ  ＶＢＲ  ｓｔｒｅａｍｉｎｇ  ｖｉｄｅｏ」、ＩＥＥＥ  ｔｒａｎｓａｃｔｉｏｎｓ  ｍｕｌｔｉｍｅｄｉａ、２０００年３月
【特許文献１】特許０９２９８７３４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
最初の処理としてこの方法には、クライアントとサーバ間の対話が含まれる。この対話は、問題の検出と認識の間に待ち時間を生じさせる。また、この認識は通常、コンテンツの配信がサーバから単一のクライアントに対して実行されるユニキャスト配信の場合のみ可能である。サーバが同じコンテンツを多数のクライアントに配信するマルチキャスト配信の場合、サーバが全てのクライアントと自動的に関係を持つ方法をとって、単一のクライアントに対して発生する問題を解決することはもはやできない。
【課題を解決するための手段】
【００１０】
本発明は、コンテンツのリアルタイム配信において、クライアントの入力バッファのアンダーフロー及びオーバーフローを検出する解決策を提案する。この検出は、前記クライアントの入力バッファの使用率の動的な測定によってクライアントの上流で実行される。この方法で、アンダーフロー及びオーバーフローの状況の発生の予測、及び記憶されたビデオシーケンスの挿入又は待機しているパケットの記憶などの方法をとることが可能である。
【００１１】
本発明は、パケットによるコンテンツ配信ネットワークに接続可能な装置に関する。前記コンテンツは、少なくとも１つのクライアントに対して意図されたデジタルデータのストリームの形式で送信される。前記少なくとも１つのクライアントは、コンテンツを再生するためにデータをデコードする前に、受信した当該データを記憶する入力バッファを有する。前記装置は、前記配信ネットワーク及び当該配信ネットワークに接続された前記少なくとも１つのクライアント間のデータパケットを通過させるための手段を有する。前記手段は、前記クライアントの前記バッファに対して意図された全てのパケットを通過させるデータパケットを通過させる。前記装置は、前記クライアントの少なくとも１つのパラメータに従って、前記少なくとも１つのクライアントの入力バッファの使用率の測定の算定手段を備える。前記クライアントの前記少なくとも１つのパラメータは、例えば、次のパラメータから得られる。
【００１２】
・前記配信ネットワークへ接続された前記少なくとも一つのクライアントの前記入力バッファのサイズ
・データストリームを再生するときにデコードを開始する前に、前記少なくとも１つのクライアントが記憶するデータの量
・前記少なくとも１つのクライアントが前記入力バッファを空にするために使用する再生ビットレート
前記装置が望まないコンテンツ（例えば、ブラックスクリーンや固まった画像）を表示することを防ぐために、本発明によれば、前記装置は、前記入力バッファの測定された使用率が閾値を下回ったときに、コンテンツ置換シーケンスをクライアントに送信することに適している。
【００１３】
特定の一実施形態によれば、前記装置は、リアルタイムコンテンツ置換シーケンス記憶手段も備える。
【００１４】
特定の一実施形態によれば、前記装置は、前記入力バッファの使用率の測定が閾値を上回ったクライアントに対して意図された前記データパケットを一時的に記憶するのに適している。
【００１５】
特定の一実施形態によれば、前記装置は、クライアントの前記使用率の測定が閾値を下回ったとき、警告メッセージを送信するのに適している。
【００１６】
特定の一実施形態によれば、前記装置は、クライアントの前記使用率の測定が閾値を上回ったとき、警告メッセージを送信するのに適している。
【００１７】
本発明は、デジタルデータのストリームの形式で送信されたコンテンツのデコード装置の入力バッファの使用率を測定するための方法にも関係する。デコード装置は、クライアントと呼ばれる。前記方法は、パケット交換によってコンテンツ配信ネットワークに接続可能な監視装置による方法である。前記監視装置は、前記配信ネットワーク及び当該配信ネットワークに接続されたクライアント間において、前記データパケットを通過させるための手段を有する。前記手段は、前記クライアント及び前記配信ネットワーク間において、全ての前記データパケットを通過させるデータパケットを通過させる。この方法は、前記入力バッファのサイズ、デコードを開始する前に記憶するデータの量、及び前記少なくとも１つのクライアントに対して意図された前記監視装置を通過した前記データパケットに従って、前記少なくとも１つのクライアントの入力バッファの使用率の測定を算定するステップを備える。
【００１８】
前記装置が望まないコンテンツを表示することを避けるために、本発明によれば、前記方法は、前記クライアントの入力バッファの測定された使用率が閾値を下回ったとき、クライアントへのコンテンツ置換シーケンスを送信する動作を備える。
【００１９】
特定の一実施形態によれば、前記使用率の測定の算定は定期的な方法で実行される。
【００２０】
特定の一実施形態によれば、前記使用率の測定の算定はデータパケットがクライアントに送信される毎に実行される。
【００２１】
特定の一実施形態によれば、前記方法は更に、前記使用率の測定が閾値を下回ったときに記憶されたシーケンスを送信するステップを備える。
【００２２】
特定の一実施形態によれば、前記方法は更に、前記入力バッファの使用率の測定が閾値を上回ったクライアントに対して意図された前記データパケットを一時的に記憶するステップを備える。
【００２３】
特定の一実施形態によれば、前記方法は更に、クライアントの前記使用率の測定が閾値を下回ったときに警告メッセージを送信するステップを備える。
【００２４】
特定の一実施形態によれば、前記方法は、クライアントの前記使用率の測定が閾値を上回ったときに警告メッセージを送信するステップも備える。
【発明を実施するための最良の形態】
【００２５】
図面を参照して以下の詳細な説明を読むことで、本発明はより良く理解され、他の詳細な特徴及び利点が明らかになる。
【００２６】
本発明は、パケット交換ネットワークにおける全ての種類のリアルタイムデジタルコンテンツ配信に関する。本実施形態は、例えばインターネットや専用配信ネットワークなどのＩＰネットワークにおいて、ビデオ配信のより詳細なフレームワークに位置づけられる。
【００２７】
実施形態のフレームワークを表すアーキテクチャの例を図１に示す。この図において、リアルタイムデジタルコンテンツ配信のサーバ１．１を確認できる。これらのサーバは、配信ネットワーク１．２に接続されている。本実施形態は、最終クライアント１．４がＡＤＳＬ（Ａｓｙｎｃｈｒｏｎｏｕｓ  Ｄｉｇｉｔａｌ  Ｓｕｂｓｃｒｉｂｅｒ  Ｌｉｎｅ）技術を介して配信ネットワークに接続されているフレームワークに位置付けられる。この技術は、電話回線を介した配信ネットワークに対して、クライアントの高ビットレート接続を可能にする。このようにするため、電話交換局は、接続機器の品目としてＤＳＬＡＭ１．３（Ｄｉｇｉｔａｌ  Ｓｕｂｓｃｒｉｂｅｒ  Ｌｉｎｅ  Ａｃｃｅｓｓ  Ｍｕｌｔｉｐｌｅｘｅｒ）を備えている。配信ネットワークに接続されているこれらのＤＳＬＡＭは連帯して、クライアントのＡＤＳＬモデムがデジタル接続及び音声アクセスを電話回線上で多重化することを可能にする。この方法で、各クライアントは、ＤＳＬＡＭを介して、コンテンツ配信ネットワークに接続されている。本発明の実施形態は、配信ネットワークに対するクライアントのＡＤＳＬアクセスのフレームワークに位置するが、本発明は、このフレームワークに限定されず、クライアントと配信ネットワーク間のいずれの種類の接続においても同じ方法で動作する。また、本発明は、必ずしもＤＳＬＡＭ上で実装されるとは限らないが、反対に、配信ネットワーク（例えば、インターネットネットワークやＡＤＳＬネットワーク）と当該配信ネットワークに接続された少なくとも１つのクライアントのバッファメモリとの間において、データパケットを通過させるいずれの装置でも実装されうる。装置とクライアントのバッファメモリとの間のリンクは、このバッファメモリの使用率に影響を与えるような干渉をしないことが有利である（特に、ジッタやパケット損失の類の干渉）。これは例えば、クライアントへのポイントツーポイントリンクや、クライアントが属するローカルエリアネットワークのエントリポイント（例えば、ドメスティックネットワーク（ｄｏｍｅｓｔｉｃ  ｎｅｔｗｏｒｋ））である。
【００２８】
サーバは、デジタルデータのファイル、典型的にはオーディオ及びビデオサービスのファイルを含み、又は生成することができる。これらのファイルは、ＭＰＥＧ（Ｍｏｖｉｎｇ  Ｐｉｃｔｕｒｅ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｇｒｏｕｐ）標準に従ってエンコードされたリアルタイムデータストリームの形式で配信される。この標準によれば、データはパケットに分割され、これらのパケットはその後、ネットワークを介してクライアントに配信される。マルチキャスト放送の形態は、マルチキャスト送信の形態におけるクライアントのグループに対するパケットの送信において、トランスミッタ又はトランスミッタのグループからなる。この形態において、パケットはマルチキャスト放送アドレスとして知られるアドレスに送信され、放送グループに属する全ての受信者に送られる。放送グループに参加するクライアントは、グループに登録すると言われ、グループを去るクライアントは、グループから登録を解除するといわれる。
【００２９】
情報源が受信者のグループにデータを送信したとき、マルチキャスト放送は、実際には、ネットワークの中間帯域幅（ｉｎｔｅｒｍｅｄｉａｔｅ  ｂａｎｄｗｉｄｔｈ）で確保するように使用される。生放送のＴＶサービスが放送されるときがそのような場合である。実際この場合、ポイントツーポイント送信の形態の使用は、受信者がいるのと同じ回数だけデータが送信されることを意味する。この形態は、情報源及び異なる受信者間の経路の共通ネットワークの一部において、パケットの多重化を実現する。反対に、マルチキャスト放送は、データが１回だけ送信されることを可能にする。このデータは、放送グループに属する受信者へ通じる経路に準じて、ネットワークのルータで複製される。
【００３０】
図２は、より正確に、本発明の実施形態において、配信ネットワークを介してサーバからクライアントへ届くビデオストリームの配信の動作を示す。この図は、クライアント及びＤＳＬＡＭのレベルで何が発生するかに焦点を合わせる。１から５の番号が付されたクライアント２．４は、同じＤＳＬＡＭ２．３に接続されている。図は、クライアント３及び４の入力バッファ２．９及び２．１０も示している。配信ネットワークを介してサーバからＤＳＬＡＭに到着するデータ２．５は、２つのデータストリームを有する。第一のデータストリームである黒のパケット２．６は、クライアント３へ向けたものであり、一方、第二のストリームのパケット２．７は、クライアント５へ向けたものである。従って、黒いデータパケットをクライアント３のバッファ２．９に、白いパケットをクライアント５のバッファ２．１０に必然的に発見する。ＤＳＬＡＭ２．３は、クライアントとネットワーク間のＡＤＳＬ接続の管理の役割に加え、クライアント及びネットワーク間の第一レベルのルータとしての役割を担う。配信ネットワーク及びＤＳＬＡＭ２．３が接続するクライアント間の全てのトラフィックは従って、ＤＳＬＡＭ２．３を通過する。下り方向において、ＤＳＬＡＭ２．３は、リアルタイム又は他の方法で、ネットワークのデータパケットをネットワークに備えるインタフェースを介して受信し、それらを受信者クライアントへ配信する。上り方向において、ＤＳＬＡＭ２．３は、クライアントによって送られた全てのパケットを受信し、ネットワークを介してそれらを再送信する。本発明の実施形態のフレームワークにおいて、ＤＳＬＡＭ２．３は、テーブル２．８を含み、その機能は更に説明される。
【００３１】
クライアントは、本実施形態において、典型的にはデジタルテレビジョンデコーダであるが、デジタルテレビジョン、デジタルｈｉ−ｆｉシステム又は他の装置などのリアルタイムコンテンツを再生可能な任意の装置であってもよい。クライアントは従って、コンテンツデータパケットをコンテンツ再生のためにバッファに取り込む。取り込み率は、再生速度によって設定される。ＭＰＥＧ標準は、例えば、ＰＴＳ（Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｔｉｍｅ  Ｓｔａｍｐ）として知られるタイムスタンプの存在を規定する。ＰＴＳは、一部のデータパケットに定期的に挿入され、クライアントによって関連データが提供されて再生されなければならない時期を定義する。この関連データは、典型的にはビデオのための画像及び音声のための音声サンプルである。リアルタイムで正確なコンテンツ再生は、これらのＰＴＳを考慮すること及びスケジュールされた時期にデータを表示することを要求する。
【００３２】
ネットワークから届くデータパケットが十分な速度でクライアントの入力バッファに到着しない場合、前記クライアントは空になり、アンダーフローの状況に達し得る。この場合、クライアントは、もはやリアルタイムの制約を考慮し、スケジュールされた時間にデータを再生することができず、サービスの中断が発生する。コンテンツがビデオの場合、画像が不足し、クライアントが情報の不足に反応する方法に従って、ブラックスクリーン又は画像がフリーズしていることにユーザは気づく。そのような状況の原因は多数存在し得る。それは、もはやデータを提供できないほど膨大な要求を受けたサーバが含まれ得る。それは、減速又は一部のデータパケットを失うようなネットワークの輻輳も含まれ得る。一方、入力バッファのオーバーフローも発生し得る。この場合、データパケットは、クライアントによって受信され、前記クライアントは保存することができない。これらのパケットは失われる。これらの失ったパケットはその後、データの欠落によってサービスに障害を引き起こす。これらのオーバーフローは、例えば、群をなした膨大な数のパケットの受信、又はサーバ及びクライアント間の同期化の欠乏に起因する。
【００３３】
従って、ユーザが感じるサービスの品質に関して、できる限りこれらのアンダーフロー及びオーバーフローの状況を避けることが重要である。既知の解決策は、容量超過時に輻輳を回避するように配信ネットワークを構成し、データパケットが循環可能な流動性及び最小限の不安定性を可能にする。この解決策は当然、コストの問題を上昇させ、全ての場合において用いることはできない。より適正な容量のネットワークにおいて、アンダーフロー又はオーバーフローの状況が発生し得ないことを保証することはできない。この場合、これらの状況の予測検出が警告を始動させることができる。この警告を認識して、サービスの障害にリンクした問題を限定して活動を開始することができる。
【００３４】
特許文献１に説明されているように、バッファの使用率の監視装置がクライアント上に実装されるシステムがある。アンダーフロー又はオーバーフローが発生しそうであるとき、その時クライアントは、サーバに警告メッセージを送ることができる。サーバはその後、アンダーフロー又はオーバーフローの発生を防ぐようにデータ送信速度を適合させる。この解決策は、主に二つの問題を引き起こす。一つは、クライアント及びサーバ間のネットワークにおいて、メッセージ交換を必要とする。メッセージ交換は、サーバの反応において待ち時間を生じさせ、従って修正において待ち時間を生じさせる。もう一つは、データの配信が単一のクライアントである排他的な宛先に対してサーバによって実行される場合のみ、サーバを適合することに起因する修正が動作できる。実際、同じコンテンツのクライアントは、入力バッファの利用率が同じではなく、全てのクライアントが適合するように送信を制御することは不可能である。
【００３５】
本発明の実施形態において提案される解決策は、クライアントの入力バッファの使用率の監視からなる。この監視は、ネットワークにおいてクライアントの上流に対して行われる。監視は、例えば、ＤＳＬＡＭのレベルで実行される。この監視を初期化できるような方法で、ＤＳＬＡＭは、接続されてバッファを調査されるクライアント、その入力バッファのサイズ、及びデコーダが記憶するデータ量をデコードの開始前に知らなければならない。最初の記憶量と同様に、ＤＳＬＡＭに対するバッファサイズのクライアントによる通信を設計することができる。この通信を実行するいくつかの方法がある。ＤＳＬＡＭで本発明を実装する場合、最も簡易な方法は、この送信を接続の初期化時のメッセージ交換に統合することである。実際、接続は、ＰＰＰｏＥ（Ｐｏｉｎｔ  ｔｏ  Ｐｏｉｎｔ  Ｐｒｏｔｏｃｏｌ  ｏｖｅｒ  Ｅｔｈｅｒｎｅｔ）、ＰＴＰ（Ｐｏｉｎｔ  ｔｏ  Ｐｏｉｎｔ  Ｔｕｎｎｅｌｉｎｇ  Ｐｒｏｔｏｃｏｌ）又はＰＰＰｏＡ（Ｐｏｉｎｔ  ｔｏ  Ｐｏｉｎｔ  Ｐｒｏｔｏｃｏｌ  ｏｖｅｒ  ＡＴＭ）のようなポイントツーポイントリンクプロトコルを使用することによって、クライアントとＤＳＬＡＭ間で設定される。これら全てのプロトコルは、事前パラメータをネゴシエーションフェーズで統合し、入力バッファのサイズ及び初期記憶の量をこのフェーズで変換されたパラメータに付加することができる。
【００３６】
クライアントから情報を要求するためのＤＳＬＡＭによるリクエスト、又は配信ネットワークの（ひいてはＤＳＬＡＭの）管理者によるこのパラメータのＤＳＬＡＭへの入力、又はＤＳＬＡＭがこの情報を取得可能な他の方法を提供することも可能である。
【００３７】
ＤＳＬＡＭは、デコードを開始する前にクライアントのバッファのサイズ及び記憶されたデータの量に関する情報を一度持つと、デコーダの入力バッファの使用率を測定することが可能である。実際、ＤＳＬＡＭは、ネットワークとクライアント間の最終リンクに配置されているために、クライアントによって受信される全てのデータについての認識を持つ。ＤＳＬＡＭは、クライアントによるデコードのスピード、ひいてはデータの取り込みのスピードを知っている。この情報は、ストリームから推測可能であり、クライアントがＤＳＬＡＭに送信するパラメータの一部になり得る。この情報は、送信されたリアルタイムデータストリームの種類、その圧縮率及びそのエンコードに依存する。測定は２つのフェーズで行われ、デコードは最初に、クライアントでは開始しない。バッファは従って、ＤＳＬＡＭによって送信されたデータで満たされ、消費しない。送信されたデータの量が初期記憶量に達するとすぐに、デコード、ひいてはデータの消費がクライアント上で開始する。その後、第二フェーズに入る。この第二フェーズで、ＤＳＬＡＭは、クライアントへ送信されたデータから消費されるデータを差し引く演算によって、バッファの使用率を測定する。ＤＳＬＡＭはこの方法で、図２に示すような、全てのクライアントについての入力バッファの使用率を提供する表２．８を保持することができる。従って、図２において、表２．８を用いて、クライアント３の入力バッファの使用率は６０％であり、一方、クライアント５のバッファの使用率は２０％であることが分かる。クライアント１、２、及び４は、リアルタイムコンテンツフローを受信しない。ＤＳＬＡＭは従って、いずれの時点においても、リアルタイムコンテンツのフローを受信するクライアントの入力バッファの使用率を測定することができ、これをＤＳＬＡＭとクライアント間のメッセージ交換を必要とせずに測定することができる。バッファの使用率の測定の演算は、定期的に行われなければならない。クライアントに送信される各パケットに対して、又は一定の間隔で行われ得る。第一フェーズの間、バッファの使用率は、クライアントへ送信されたデータの量に対応する。第二フェーズの間、この率は、送信される全てのデータから消費されるデータを差し引いたデータに対応する。
【００３８】
この認識が得られ、ＤＳＬＡＭは、クライアントの一つがいつオーバーフロー又はアンダーフローになるかを知ることが可能である。例えば、警告を始動させる閾値を設定することができる。例えば、５％と９５％に閾値を設定し、使用率が５％以下又は９５％以上になったときに警告を発生させることができる。この認識は、警告又は修正措置を発生させることができる。本発明の一実施形態には、例えば、事前に記録された、又はオンザフライで生成されたビデオシーケンスが含まれる。これらのシーケンスは、図３のＤＳＬＡＭ内のメモリ又はディスク３．２３に記憶される。アンダーフローの場合、受信しているプログラムについての失ったパケットの代わりに事前記録されたシーケンスなどのクライアントパケットデータを送信することが可能である。ユーザは従って、プログラムの中断を理解し、ユーザは可能な置き換え又は代用するシーケンス、例えば、プログラムアナウンスメント、送信されたコンテンツの送信状況に関する詳細メッセージ、広告シーケンス、又は利用を望む任意の種類のシーケンスを考える。その効果は、「ブラックスクリーン」又は画像のフリーズよりも否定的な面がより少なくなる。
【００３９】
本発明によるそのようなＤＳＬＡＭのアーキテクチャを図３に示す。監視装置３．２０は、処理動作の実行を可能にするプロセッサ３．２１、表２．８のようなデータの記憶のためのワークメモリ３．２２、ディスクとなりうる、例えば本発明の特定の実施形態に従って記憶されるシーケンスに置換が可能な記憶メモリ３．２３が含まれる。装置は、リンク３．２５の手段によってコンテンツ配信ネットワークにリンクしているインタフェース３．２４を有する。本実施形態において、このリンク及びこのインタフェースは、ＡＴＭ（Ａｓｙｎｃｈｒｏｎｏｕｓ  Ｔｒａｎｓｆｅｒ  Ｍｏｄｅ）リンクであるが、例えば、イーサネットギガビットにすることもできる。一方で、一連の回線インタフェースモジュール３．２７はそれぞれ、ＡＤＳＬ接続３．２８を通常１６のクライアントに電話回線によって設定可能である。これらのモジュール、プロセッサ、メモリ、ディスク及び配信ネットワークとのインタフェースは、内部バス３．２６によって通信する。配信ネットワークとクライアント間の通信は従って、リンク３．２５で結合され、関連するクライアントによってリンク３．２８で配信される。
【００４０】
オーバーフローの場合、ＤＳＬＡＭがそのＤＳＬＡＭに特有のバッファに、クライアントがもはや受信できないデータを記憶することを提供できる。このデータは、使用率が減少したときに、遅れて送信される。
【００４１】
クライアントへ説明メッセージの送信を提供することも可能である。配信ネットワークの管理者へ送信される警告メッセージを提供することも可能である。この方法で、配信ネットワークの管理者は、提供されるサービスの量を評価し、サービスの配信に現れる問題を解決することができる。サービス配信インシデントの統計値を維持して、より良い方法で配信ネットワークをディメンション（ｄｉｍｅｎｓｉｏｎ）することができる。
【００４２】
本発明の実施形態は、本発明のＤＳＬＡＭ内の実装を説明するが、前記発明を他の装置で実装することができ、又はＤＳＬＡＭに到着するリンク又はＤＳＬＡＭとクライアント間のリンクに接続された装置上で実装することもできる。ネットワーク内で本発明を実装するために唯一必要な条件は、クライアントである送信先に対して意図する全てのデータの通過を理解して、前記クライアントが受信するデータの確実な測定を可能とするという点である。本発明を例えば、ＤＳＬＡＭのリンクの上流に接続され、リンクのトラフィックを分析するセンサとして動作する装置上に実装することができる。同様に、本実施形態は、クライアントのＡＤＳＬによる接続の場合に位置付けられるが、接続方法に関係なく動作可能であることが適当であり、例えば、ケーブル接続の場合はケーブル中継局で、又はクライアントと配信ネットワーク間が無線接続の場合は無線アクセスポイントで実装され得る。
【図面の簡単な説明】
【００４３】
【図１】本発明の実施形態によるコンテンツ配信アーキテクチャを示す図である。
【図２】本実施形態のバッファの使用率の予測を強調したこのアーキテクチャの詳細を示す図である。
【図３】本発明の実施形態を実装する装置のハードウェアアーキテクチャを示す図である。
【図１】
2009500975.tif 000003
【図２】
2009500975.tif 000004
【図３】
2009500975.tif 000005
【国際調査報告】
2009500975.tif 000006
2009500975.tif 000007
2009500975.tif 000008
2009500975.tif 000009
2009500975.tif 000010
2009500975.tif 000011