JP2006523980A - データ要求装置、データ送信装置、およびそのプロセスならびに対応する製品 - Google Patents

Abstract

本発明はデータ要求装置、データ送信装置およびそのプロセスに関するものである。
本発明は特に、決められたデータの要求（REQU）をサーバーに送信する手段（２２）と、そのサーバーからストリームデータ（DATA）を受信して該データを処理手段（２４）に入力する受信手段（２３）と、データストリーミングを一時停止させ、そのサーバーへの送信再開を引き起こすための一時停止制御信号（XOFF）を生成する手段（３０）とを有する、データサーバー（１０）に対するデータ要求装置（２）に関するものである。
要求装置は、該要求装置における正常動作をサーバーに示すための正常状態信号（NORMAL）を生成し、そしてそれらの信号のサーバーへの周期的送信を引き起こすための手段を有する。
ＶＯＤへの応用あり。

Description

本発明は、わけても、特にＶＯＤ（Video On Demand［ビデオ・オン・デマンド］の略）のためのデータを要求／送信する装置およびプロセスならびに対応する製品に関するものであるが、それに制限されるものではない。

パソコンＰＣ（パーソナル・コンピュータの略）に利用できる既存の技術によれば、ビデオもしくはオーディオまたはその両方のデータ（以下、「ＡＶデータ」と記す）をインターネットを通じてサーバーに注文することは、要求するパソコンをサーバーに接続し、該パソコンのＩＰ（Internet Protocol［インターネット・プロトコル］の略）アドレスを伝えることによって可能である。これはたとえば予告編や広告に適用される。こうした技術は、ストリーミングに依拠しており、ＡＶデータをのちの表示のための保存スペース内にダウンロードするのみならず、表示しながら同時にＡＶデータを取得することをも可能にする。

既存の技術の問題は、データが受信側によってちゃんと受信され、しかるべき時間内に正しく利用されるかどうかについての確証が得られないということである。特に、受信側のバッファにあまりに多くのデータが到着すると、オーバーフローが起こりうる。また、オーバーフローを避けるために一時的に送信を中断しなければならない場合、バッファが次のデータを受け取る用意ができたときに送信が中断された位置から送信を再開するというのはあまり実用的ではない。さらに、受信側で問題が起こる場合、ストリーミングが継続される危険があり、無用に帯域を費消してしまう。

既存の技術は、受信側からサーバーに、ストリーミングを中止、一時停止または再開するための特別な制御信号を送信するというものである。

特に、文書ＷＯ−９７０４５８５はＶＯＤサーバーから受信機へネットワークを介してＭＰＥＧでエンコードされたテレビ信号を送信することに関するものである。受信機は一時停止および再開のほかスローモーションや諸機能をサーバー側に指示できるようになっている。ネットワークにまつわるネットワーク遅延や再多重化といったことは、ビットストリーム中で中断後にサーバーが信号の送信を再開できる位置に位置ラベルを挿入しておくことによって配慮されている。一時停止要求があると、受信機はまずそのような位置ラベルが検出されるまで再生を継続する。再生再開の要求があったときには、受信機はサーバーに、前記検出された位置から始まる信号の再送信を要求する。

しかし、このような解決はサーバーと受信機との間の信頼できる通信を前提としており、何らかの理由で受信機がしかるべき時間内に指示を送信できなかったり、サーバーがそれをうまく受信できなかったりすると機能しない。そのような場合はもはや利用されないストリームデータの送信が続き、帯域の損失につながる。

本発明は、受信側で、あるいはデータサーバーと受信側との間の通信ネットワーク内で不具合があった場合に無駄なデータストリーミングの危険を合理的に軽減することのできる、データ、特にＡＶ（Audio/Video［オーディオ／ビデオ］）データの柔軟な取得を可能にする、データ要求装置に関するものである。本発明の該要求装置は特に、そのようなサーバーで再生される映画を一時停止させたり再取得したりすることをできるようにしうる。

本発明はまた、その前記装置に対応し、同様の利益をもたらすことのできる、データ要求プロセス、データ送信装置およびプロセスならびに製品に関するものでもある。

そのために、本発明は請求項１で定義されるデータ要求装置に関係している。

従前と異なり、本発明は二つの異なる相補的な機構の組み合わせに依拠している。一つは送信を一時停止させる特別な制御信号に基づくものであり、もう一つは受信側で問題が起こっていないことを示す、すなわちストリームデータの受信と利用が正しく行われていることを意味すると言える、周期的な信号（正常状態信号）に基づくものである。

この方法では、受信側で問題が生じてストリームデータの正常な利用が妨げられた場合、周期的信号がサーバーに送られなくなり、サーバーはその受信機に対するいっさいの送信を中止することになる。他方、サーバーによるデータ送信の一時停止を受信側が指示することもできる。

このように、サーバーは受信側の戻り経路情報に応じた状況に依存して異なる二通りの方法でデータのストリーミングを中止する（一時的であってもそうでなくても）ことができる。

前記データ要求装置で使われる第一および第二の通信ネットワークは、単一の双方向通信ネットワークであってもよい。さまざまな実施形態において、それはインターネットのようなＷＡＮネットワークであったり、あるいは家庭ネットワークまたは企業もしくは地理的に制限された領域（建物など）のために局所的に使われるネットワークのようなＬＡＮネットワーク（Local Area Network［ローカルエリアネットワーク］の略）であったりする。また、第一の通信ネットワークは、要求されたデータをストリーミングするための放送ネットワークおよび制御情報を送信するための双方向ネットワーク（たとえば電話線）であってもよい。

前記データ要求装置は好ましくは従属請求項２ないし７に準拠したものである。

特に、データ要求装置における一時停止制御信号の生成は、特に、ユーザーによって意図的にユーザーインターフェースを介して引き起こされてもよいし、中央メモリのオーバーフローを避けるために自動的に引き起こされてもよい。

また、サーバー側で一時停止したのちのデータストリーミングの再開は、特に、ある所与の時間（これは特に、ユーザーによって、５分の一時停止などという形で一時停止制御信号内で送信されてもよい）後に自動的に行われてもよいし、前記データ要求装置からの再開制御信号の送信によって引き起こされるのでもよい。

本発明はまた、本発明に基づくデータ要求装置を有するデコーダおよび請求項９で定義されるデータ要求プロセスに関するものでもある。

本発明はさらに、請求項１０で定義されるデータ送信装置に、好ましくは請求項１１ないし１３のいずれかにおいて言及されている実施形態の一つに、また請求項１４で定義されるデータ送信プロセスに関するものである。

本発明のさらなる目的は、コンピュータ上で実行されたときに、本発明に基づくデータ要求プロセスまたはデータ送信プロセスのステップを実行するプログラムコード命令を有しているコンピュータプログラムプロダクトである。「コンピュータプログラムプロダクト」とは、ディスケットまたはカセットのような当該プログラムを含んだ記憶スペースのみならず電気または光信号のような信号をも含みうるコンピュータプログラム基盤を意味している。

本発明は、付属の図面とともに限定的な意味のない以下の実施形態および実装の例によってよりよく理解され、説明されることであろう。

図２および図３では、表示されているブロックは純粋に機能的な実体であり、必ずしも物理的に別個の実体に対応するわけではない。すなわち、ソフトウェアの形で開発されることもあれば、一つまたは複数の集積回路に実装されることもある。

データ送信装置１を備えたサーバー１０（図１）は、データ要求装置２を備えた少なくとも一つの受信機２０に対して、第一のネットワーク５を通じてデータをストリーミングすることができる。受信機２０のほうは、サーバー１０に対して、第二のネットワーク６を通じた戻り経路によって情報を送信することができる。たとえば、第一のネットワーク５は、特に衛星、電波放送、ケーブルに依拠したものでありうる放送ネットワークであり、第二のネットワーク６は電話線ネットワークである。両ネットワーク５および６は、たとえばＤＳＬ（Digital Subscriber Loop［デジタル加入者線］）通信に基づく単一の双方向ネットワークによって構成されていてもよい。

サーバー１０のデータ送信装置１（図２）は：
・受信機２０からのメッセージを受信するための受信モジュールであって、該メッセージが特にデータ要求（data request）REQU、受信機２０の機能に関する情報（information）INFO、受信側が正しく動作していることを確認するためにサーバー１０に周期的に送信される正常状態信号（normal state signal）NORMAL、データストリーミング様式を修正するための（特に送信を一時停止したり再開したりするため、スローモーションや早回し、逆回しのためなどの）制御（control）信号CTRLを含みうるような受信モジュール１１と、
・受信機２０に向けて提供されるべきデータの一連の区画のサイズおよびそれらの区画の一つの送信から次の送信までの遅延を、ある最大バンド幅のレートまで対応でき入力バッファ（またはいくつかの入力バッファ）を有する受信機２０についての前記最大バンド幅のレートおよび前記入力バッファの大きさに関する情報INFOに応じて決定するための指定モジュール１２と、
・要求されたデータのデータ区画の形でのストリーミングを制御信号STRMによって引き起こし、前記区画のストリーミングの周期性がクロック４１によって保証されるような、ストリーミングモジュール１３と、
・正常状態信号NORMALの一つでもしかるべき時間内に受信されなかったときに受信機２０に警告（warning）メッセージWARNを送信する転送モジュール１４と、
・警告メッセージWARNが送信されたあとでも前記正常状態信号NORMALがしかるべき時間内に受信されなかったときに警報を引き起こす警報モジュール１５と、
・早回しおよび逆回しに指定モジュール１２と対話しながら使われ、所望される動作に対して要求されているデータ中での一連の関連位置を同定することができ、それらの位置の一連の呼び出しは指定モジュール１２が行うような、解釈モジュール１６、とを有する。

受信機２０のデータ要求装置２（図３）は：
・サーバー１０に要求メッセージREQU、情報INFO、正常状態信号NORMAL、制御信号CTRLを送信する送信モジュール２２と、
・サーバー１０から特にストリームデータDATAを受信してそれを入力バッファ２１（またはいくつかのそのような入力バッファ）に転送するために設計されており、また特にサーバー１０から警告信号WARNを受信するための備えもされている受信モジュール２３と、
・受信したデータDATAをたとえばビデオおよびオーディオストリームを復号することによって処理する処理モジュール２４と、
・情報INFOを取得し、それをサーバー１０に送信するために送信モジュール２２に提供することのできる情報取得モジュール２５と、
・入力バッファ２１から転送されたデータDATAを処理モジュール２４に送信する前に一時的に保存するための中央メモリ２６と、
・入力バッファ２１内で利用できるデータを引き出して中央メモリ２６に転送するためのデータポンプ２７と、
・中央メモリ２６内のデータが該中央メモリ２６のある所定の中間閾値レベルまで達したときに、該中央メモリ２６からデータを処理モジュール２４に転送するための注入部２８と、
・制御信号CTRLを生成し、それをサーバー１０に送信するために送信モジュール２２に提供することのできる制御モジュール３０と、
・正常状態信号NORMALを生成し、送信モジュール２２によるサーバー１０へのその周期的な送信を引き起こし、正常状態信号NORMALの送信の周期性がクロック４２によって保証されるような、保持モジュール３１と、
・データポンプ２７と結合した調整モジュールであって、制御モジュール３０をして、中央メモリ２６内のデータがある所定の高閾値レベルを超えたときに一時停止制御信号を発生させ、データストリーミングが先に当該調整モジュール３２によって一時停止されているときに前記データがある所定の低閾値レベルまで下がったときに再開制御信号を発生させるための調整モジュール３２と、
・ユーザーが制御モジュール３０および送信モジュール２２を操作してサーバー１０に制御信号CTRLを与えることができるようにするユーザーインターフェース３５、とを有する。

図４から図９を参照した詳細な特定の実施形態によって、上述したデータ送信装置１およびデータ要求装置２の機能がよりよく理解できるようになるだろう。

サーバー１０およびそれぞれ符号２０−１…２０−ｎで示すＩＲＤ（Integrated Receivers Decoders［組み込み受信機デコーダ］の略）（ＩＲＤ１…ＩＲＤｎ）（そのそれぞれが上述した受信機２０と同様のもので、以下では一般的な表記として参照符号「２０」を用いる）を有する通信環境（図４）が、ＰＳＴＮ回線（Public Switch Telephone Network［公衆電話交換網］）を通じて通信している。ＰＳＴＮ回線はＰＳＴＮネットワーク７としてネットワーク５および６の両方（同一のネットワーク）をなしている。その環境は、インターネットの世界で好適の真のビデオストリーミングシステムを提供する。サーバー１０は第一のＶＤＳＬ（Very high speed Digital Subscriber Loop［超高速デジタル加入者線］の略）モデム４３にイーサネット（登録商標）接続によって接続されており、一方、ＩＲＤはたとえばそれぞれテレビが付随しており、第二のＶＤＳＬモデム４４にスイッチ４５を介してイーサネット（登録商標）接続により接続されている。

ＶＤＳＬモデム４３および４４は６０Ｍｂｐｓにも及ぶ高ビットレートを可能にする。よって、前記の通信環境は、エンドユーザーが自分専用の番組をカタログから選んで再生や一時停止を無用に帯域を使うことなく注文することができる真のビデオ・オン・デマンドシステムを提供する。

例として、前記通信環境は、ＩＲＤをなすものとしてＬＡＮ（Local Area Network［ローカルエリアネットワーク］）接続機能のあるセットトップボックス（set-top-box）（以下ＳＴＢ）２０−１から２０−ｎと、ＶＤＳＬモデム４３および４４と、リナックス技術に基づくＰＣサーバー１０とを有している。もちろん、リナックス以外のＯＳを使うこともできる。

各ＩＲＤは要求装置２を有しており、一方、サーバー１０は対応する送信装置１を有している。

変形としては次の一部または全部を採用することができる。
・ＡＤＳＬ（Asymmetric Digital Subscriber Loop［非対称デジタル加入者線］）モデム技術およびマルチキャストを今の実施形態のＶＤＳＬモデムの代わりに使う。一般にはｘＤＳＬ（ＨＤＳＬ―High-data-rate DSL―や10Mbps DSLやＡＤＳＬ２…）が他の可能性を与える。
・ユーザー側でのイーサネット（登録商標）接続の代わりにＵＳＢ（Universal Serial Bus［ユニバーサルシリアルバス］）コネクタを使う。バスに直接接続などといったその他の接続手段も可能である。
・ユーザー側にＩＲＤが一つしか存在せず、第二のＶＤＳＬモデム４４に直接接続されている。

Ａ：システムの説明 概要

主たる要求事項はユーザーに対して要求に基づいてビデオ／オーディオストリームを供することである。今の実施形態では同時に５ストリームまでに限定されるが、他の実施形態では制限が異なっていたり、制限が全くなかったりすることもある。

テレビのエンドユーザーは特に、カタログから一つの番組を選び、それを再生し、中止し、一時停止／再開することができる。

Ａ１：ネットワーク
ＶＤＳＬモデム４３および４４は、ＡＤＳＬでも同様だが、既存のユーザーの現地の電話線を使う。そうしたモデムにはイーサネット（登録商標）またはＵＳＢコネクタがある。

転送フォーマットはＭＰＥＧ２（Moving Picture Experts Group［動画像専門化委員会］の略）ＳＰＴＳ（Simple Program Transport Stream［単一プログラムトランスポートストリーム］の略）であり、言葉の問題のため音声情報は何組か送られてもよい。ここで、ＳＴＢはこの種のストリームを容易に再生する機能をもともと備えている。

サーバー側では、ＰＣ１０がイーサネット（登録商標）１００ＢＴ（100Base-Tの略）接続を通じてモデム４３に接続されている。

ユーザー側では、ＳＴＢ（４つまで）がイーサネット（登録商標）１０ＢＴ接続を通じてスイッチ４５に接続されており、該スイッチは１００ＢＴ／１０ＢＴスイッチである。ここで、どのユーザーも共有ＶＤＳＬ回線を、家庭用パソコン、他の部屋のＳＴＢなど異なる用途に使用することができる。また、前記スイッチを使うことによって衝突ドメインが分離されるので、衝突の伝搬が起こらなくなる。

図示した例では、ＵＤＰ（User Datagram Protocol［ユーザーデータグラムプロトコル］）プロトコルスタックより上では固有のプロトコルが使われる。その解決法の利点は（接続がきちんとできる限りにおいて）、モデムによって導入される帯域幅遅延積に、そして現在手にはいるＳＴＢのイーサネット（登録商標）インターフェースが半二重機能しかもたないことによっている。そのため、より複雑でより非効率なプロトコルの必要性はないのである。実験によると、ＴＣＰ（Transmission Control Protocol［転送制御プロトコル］）プロトコルスタックはこのネットワーク環境では、たとえいわゆる「ウィンドウスケールオプション」を使っても深刻な制約があることが示されている。

Ａ２：サーバー１０
リナックスをベースとし、
・エンドユーザーのＩＰアドレスを設定するためのＤＨＣＰサーバー（Dynamic Host Configuration Protocol［動的ホスト構成プロトコル］）を含み、
・当該アプリケーションをデーモンとして走らせ、
・それぞれがサーバーのハードディスクドライブ上にあるファイルからなる番組のカタログへのアクセスを提供し、
・開発されたプロトコルに基づいてファイルをストリーミングし
・ユーザーの接続／切断状態ならびにユーザーの無効状態を管理し、既知のポートが使われる。

サーバー１０は、有利にはＤＳＬＡＭ（Digital Subscriber Line Access Multiplexer［デジタル加入者線アクセス多重化器］）に直接接続された中心局にある。そこでそのカタログは扱い者によって効率的に（更新法、キャッシュアルゴリズム…）管理されている。

Ａ３：セットトップボックス２０−１…２０−ｎ
これらは：
・一覧から一つの番組を選び、
・「番組の再生」ボタンを押して番組を開始させ、
・「番組の一時停止／再開」ボタンを押して番組を一時停止／再開させ、
・別の番組に切り換え、
・音声と画像を正しく復号して同期させ、
・ストリームサーバーから５Ｍｂｐｓまでの固有ビデオビットレートを受け入れる、
ことができる。

Ｂ：プロトコル

Ｂ１：概要
サーバー１０およびＳＴＢ２０−１…２０−ｎは互いにＴＣＰ／ＩＰ ＬＡＮで接続されている。実際には（図５）、ＳＴＢ２０の一つがソケットをサーバー１０に接続してオーディオ／ビデオファイルを要求する。するとサーバー１０はそのファイルをハードディスクドライバ１７からバッファソケット１８を通じてループ処理に載せ、それはのちにＳＴＢからの要求があったときにのみ終了する。

ファイルはネットワーク７を通じてＳＴＢ２０のソケットバッファ２１に送信される。そこから中央メモリ２６に転送される。該中央メモリはここではたとえば１メガバイトの大きさをもつＦＩＦＯ（First In, First Out［先入れ先出し］の略）によって構成されている。次いでＭＰＥＧ ＭＬＭＰ（Main Level Main Profile［メインレベルメインプロファイル］の略）５０に転送される。

特別に設計されているファイル転送プロトコルは：
・利用可能なカタログを要求し、
・ストリーム転送パラメータ設定のために接続し、
・ファイルをオープン／クローズし、
・クライアントのデータ消費に配慮しつつＭＰＥＧ２−ＳＰＴＳファイルをストリーミングし、
・場合によって当該ファイルをインデックス化し、
・クライアントの無効状態を検査する、
ことを可能にする。

前記プロトコルは：
・ストリームデータを転送し（このためデータ回復は必要ない）、
・きちんとしたネットワーク上で動作し（すなわち、データ損失がないということだが、今のシステムではモデムやスイッチを使用することにより衝突が起こらないのでこれがあてはまる）、
・遅延が長く幅が太い通信路で動作する（すなわち、ネットワーク上またはクライアントのバッファのいずれかに多くのデータがたまる）、
よう構築されている。

このためＵＤＰが下位のプロトコルとして全く適切なことになる。

このシステムは、クライアント（すなわちＩＲＤの一つにおけるもの）が、ここではネットワークにあるデータをあたかも記憶媒体に要求するようなものとして見ることができる。そこでは、当該クライアントが、ＭＰＥＧ復号処理に従ってデータストリーミングを調整する。

サーバーでの計算
プロトコルがＵＤＰベースであり、サーバー１０がバンド幅容量が大きいことから、サーバーはクライアントにオーバーフローを起こさせないよう配慮する必要がある。このことを保証するために設定時にクライアントによってパラメータが与えられている。そのパラメータは次の通り。

・クライアント（client）が対応可能な最大バンド幅（bandwidth）のレート ＣＢＷ：受信側のＳＴＢ２０の全体としての容量に関わるレートであり、特に受信データを入力ソケットバッファ（またはいくつかの入力ソケットバッファでもよい）から引き出す速度に関係している。

・クライアントの入力ソケットバッファサイズ（client input socket buffer size） CSOCKBUFSZ：複数の入力ソケットバッファがあってその間で到着データが分配される場合には、パラメータCSOCKBUFSZはそれらのバッファをまとめた大きさによって与えられる。

・クライアント保持メッセージ繰返し周期：そのようなメッセージはＳＴＢ２０からサーバー１０に周期的に―たとえば５秒ごとなど―送信されることが意図されている。これは、サーバーにＳＴＢ２０が正しく動作し、ストリームデータを利用していることを伝えるためである。これが受信されないとＳＴＢの不具合または無効と解釈される。

サーバー１０はデータのストリーミングをこれらのパラメータに基づいて行う。前記ソケットバッファサイズから、要求を発しているＳＴＢに逐次送信される区画の大きさを与える値UINIT_SIZEを計算する。ある有利な例では、その値は次式で与えられる。

UNIT_SIZE＝CSOCKBUFSZ/8
因子８によってサーバー側で区画を小さなサイズにすることができ、これはストリームデータを効率的に分割することがわかった。すなわち、受信側でのオーバーフローの確率が非常に小さくなり、高度の分割により他のストリームとの帯域の共有を改善することもできる。しかし、もっと小さな因子（たとえば２まで）も可能であり、またサーバーが許せばもっと大きな因子も可能である。

サーバー１０は、前記の値に対応した上限を設定してデータ送信をループし（UNIT_SIZEごとにループする）、ＣＢＷビットレートを超えないよう遅延を挿入する。一連のデータ区画を送信する周期PERIODは次式で定義される。

PERIOD＝UNIT_SIZE/CBW
この周期は典型的には保持送信周期よりもはるかに短い。

クライアントでの計算
クライアント側では二つのパラメータが計算される。それはファイルのストリーミングに必要なバンド幅を無駄にすることなくデータ送信を一時中止／再開するためのものである。こうしたパラメータは、ＳＴＢ２０において、入力バッファ２１からはいってくるデータを処理の前に一時的に保存しておくために設けられている、大きさFIFO-SIZEの中央ＦＩＦＯメモリ２６の埋まり具合の閾値を与えるものである。まず、低ＦＩＦＯ閾値LFIFOは、データのストリーミングが一時停止されているときに、そこまで下がったらデータのストリーミングの再開をXONと呼ばれる特定のメッセージによって指示する下の限界を与える。一方、高ＦＩＦＯ閾値HFIFOは、データ処理が追いつかなくなってその閾値を超えたらサーバー１０からのデータストリーミングをXOFFと呼ばれる特定のメッセージによって一時停止させるという上の限界を与える。

両閾値LFIFOおよびHFIFOは次の関係式を満たすように選ぶ。

LFIFO≦HFIFO
FIFO-SIZE−HFIFO≧CBW×RTT/2
LFIFO≧CBW×RTT/2
ここで、RTTは往復遅延時間（Round-Trip-Time）、すなわちパケットを送出してその受信確認を得るまでの時間差である（FIFOは十分な大きさがあり、FIFO-SIZE＞CBW×RTTである）。この時間は設定時にクライアントが測定するもので、周期的に再評価してもよい。これは、サーバーからの通信が中断されたときにまだネットワークに残っていて受信されるべきである可能性のあるデータ量のめやすとなる。

入力ソケットバッファ２１
これらの入力バッファはＵＤＰ／ＩＰスタックとともに埋め込まれている。これらはＳＴＢ２０をあふれさせないのに十分な大きさである。サーバー１０はストリーミングする区画をクライアントのソケットバッファの大きさに従って計算する。

中央ＦＩＦＯ２６
この中央バッファ２６はバースト副作用に対処するために使われる。クライアントはこのＦＩＦＯに十分なデータがあるときにのみ復号を開始する。十分なデータがあるかどうかは、第三のＦＩＦＯ閾値によって決定される。それは低閾値LFIFOと高閾値HFIFOの間にある値をもつ中間閾値MFIFOである。データ処理（処理ユニットへの転送）を引き起こすこの閾値MFIFOは、ある効率的な実施形態では、低閾値LFIFOに等しい。上述のように、クライアントはまた、FIFOがいっぱいになったとき（閾値HFIFO）にはサーバーストリーミングを一時停止させ、FIFOが少なくなったとき（閾値LFIFO）にはサーバーストリーミングを再開する。

上記の一時停止と再開はそれぞれＳＴＢ２０からサーバー１０に送られるXOFFおよびXONメッセージによって行われる。どの時点でもストリーミングを一時停止し、あとで再開するのをクライアントが決めるのに、同じ信号を使うことができる。

さらに、ここで記載される有利な成果では、前記保持メッセージが周期的に送信され、サーバーによって検査されることが一時停止状態においてでも続けられる。

第一の具体的な実施例では、閾値は次のような値に選ばれる：
LFIFO＝MFIFO＝(1/4)FIFO-SIZE
HFIFO＝(3/4)FIFO-SIZE
FIFO-SIZEを１メガバイトとすると、これは次の値を与える：
LFIFO＝MFIFO＝250KB
HFIFO＝750KB
ここで、データが受信されるストリーミング速度がCBW＝6Mbpsで、データ処理速度が復号速度であり、4Mbpsに等しいエンコードビットレート（encoding bit rate）EBRに対応するとすると、２秒のストリーミング期間（XON）が１秒の一時停止期間（XOFF）と交互に現れる。実際、ストリーミングがオンであるときのＦＩＦＯが埋まっていく有効速度はCBW−EBR（今の場合2Mbps）であり、一方、ストリーミングがオフであるときの減っていく速度はEBR（今の場合4Mbps）なのである。

第二の具体的な実施例では、閾値は次のような値に選ばれる。

LFIFO＝MFIFO＝CBW×RTT/2
HFIFO＝FIFO-SIZE−CBW×RTT/2
FIFO-SIZEを１メガバイト、RTTを100msecとすると、これは次の値を与える。

LFIFO＝MFIFO＝39321バイト
HFIFO＝960679バイト
今、ストリーミング速度がCWB＝6Mbpsで、データ処理速度が4Mbpsに等しいEBRであるとすると、7.4秒のストリーミング期間が1.85秒の一時停止期間と交互に現れる。

ＭＬＭＰ ＭＰＥＧバッファ５０
これらはＭＰＥＧ２のＰＥＳ（Packet Elementary Stream［パケット基本ストリーム］の略）ストリームを正しく復号するために用意されている。ＳＴＢに埋め込まれたオーディオ／ビデオデコーダスタックが用いられる。メインレベル／メインプロファイル（Main-Level/Main-Profile）が実装されている。

サーバー側ではエンコード処理はないので、ＰＣＲ（Program Clock References［番組クロック参照］の略）は運用されていないが、ローカルなＶＣＸＯ（Voltage Control Crystal Oscillator［電圧制御水晶発信器］）は２７ＭＨｚに設定されている。いずれにせよ、ビデオおよびオーディオＰＴＳ（Program Time Stamps［番組タイムスタンプ］）を使ってオーディオはビデオに同期されている。復号処理はバッファアンダーフローは許容し、エラーがあってもＭＬＭＰバッファ５０をリセットしたりフラッシュしたりすることはない。

Ｂ２：プロトコルスタック
プロトコルおよびストリーミングのサーバー側からの状態遷移図は図６および図７に示されている。

使用されているプロトコルスタックは次の通りである。

ソケットはＵＤＰプロトコルの上でオープンである。

Ｂ３：アプリケーションプロトコル
処理は以下のステップに分割される：
・ソケット生成、
・アプリケーション層による：
・交換を開始するOpen Stream
・交換Write/read Stream
・交換を終了するClose Stream
を有する処理、
・ソケットクローズ。

アプリケーション層で構築されるパケットはメッセージである。すべてのメッセージは一般的なフォーマットを有する：
・ヘッダ：
・メッセージタイプ（１単位長）
・４つまでの任意的なパラメータ（４単位長）
・データ：当該ストリームの一部。また信号メッセージについては空。

すべてのデータ型はネットワーク式のデータ配列である。すなわち最上位ビット（MSB―Most Significant Bit［最上位ビット］―の略）が先にくる。

サーバー側からのプロトコルの主な動作は次のようなものである（図６；ここで、recvはreceive［受信］の略である）：
・ＳＴＢの一つからメッセージを受信するのを待ち（ステップＳ１）、
・ＳＴＢの一つから接続（connection）メッセージCONNECTを受信し（ステップＳ２）、
・クライアントサーバープロセスをフォークし（ステップＳ３）、
・接続確認（connection acknowledgement）CONNECT_ACKを送信し（ステップＳ４）、
・要求を発しているＳＴＢに接続し（ステップＳ５）、該ＳＴＢから接続パラメータを受信する（ステップＳ６）ことによってパラメータを取得して対応する計算を行い（ステップＳ７）、接続メッセージを送信し（ステップＳ８）、
・要求しているＳＴＢが正しくサーバーと連絡し続けていることを検査するためのクライアント無効状態警戒を開始し（ステップＳ９）、それは所定の送信周期（たとえば５秒）をもつ保持（keep alive）メッセージKEEPALIVEの周期的な受信によって検査されるものであり、
・ＳＴＢクライアントが目標とするファイルをオープンし（ステップＳ１０）、関係するファイルを指示するオープンメッセージOPEN(file)を受信する（ステップＳ１１）ことによって、対応するファイル識別子File_idを取得してそれをオープンし（ステップＳ１２）、
・該ファイルを要求を発しているＳＴＢクライアントにストリームし（ステップＳ１３）つつ、周期的に保持メッセージを受信して（ステップＳ１４）しかるべく警戒を再開し（ステップＳ１５）、ファイル送信の終わりまで続け、
・クローズメッセージCLOSEを受信したときにはファイル送信を停止し（ステップＳ１６）、
・保持メッセージが受信されないために警報が発された場合には（ステップＳ１７）、クライアントサーバープロセスを終了する（ステップＳ１８）。

サーバー側からのストリーミング動作は次のようなものである（図７）：
・保持メッセージが受信されて（ステップＳ１４）警戒が再開される（ステップＳ１５）限り、そして当該ファイルの送信が完了していない限り、データファイルのストリーミングを進め（ステップＳ１３）、上で見たように保持メッセージがしかるべき時間内に受信されないと警報が発され（ステップＳ１７）、
・特別な中断メッセージXOFFを受信したときには（ステップＳ１９）、ストリーミングを一時停止し（ステップＳ２０）つつ、保持メッセージ受信の検査を続け（ステップＳ１４）その結果により警戒を再開し（ステップＳ１５）、
・のちに特別な再開メッセージXONを受信したときには（ステップＳ２１）、先に中断された点でファイル送信を再開し（ステップＳ１３）、
・ストリーミングが現在行われていようと一時停止中であろうと、保持メッセージがしかるべき時間内に受信されない場合にはクライアントサーバープロセスを終了する。

前記プロセスのおかげで、サーバー１０は受信機２０のビデオストリーミングに関してのスペックに完全に適応させることができる。さらに、前記プロセスでは、クライアントが実際にストリーミングされたデータを利用するために有効に必要とする帯域しか使用しないことが可能となりうる。

ある有利な実施形態では、警報を発するタイムリミットは、予期される期間に往復遅延時間ＲＴＴに基づく長さ、たとえば３〜４ＲＴＴを上乗せしたもので与えられる。

クライアント側でストリーミングされたデータを正しく受信しているかどうかをサーバー側で検査する点についてのある改良版では、警報が発されるのは、保持メッセージが受信されない期間が保持メッセージの周期より十分長い期間、たとえばその期間の３倍に達したときのみとされる。これによりＳＴＢとサーバーとの間の送信において生じうる遅延に配慮することができる。

検査方法についてのあるさらなる改良によると、サーバー側で保持メッセージを受信すると期待されていた時間が過ぎてもそのようなメッセージが届かなかった場合には、サーバーはクライアントＳＴＢに警告を送り、するとクライアントはもしまだ有効な受信状態にあるのであればすぐに再び保持メッセージを送り返す。これは、ネットワークにおける送信問題、特にパケット損失などに起因してストリーミング処理が誤って中断される危険を著しく低下させ、それによりシステムの信頼性を向上させる。

上記の両特徴（タイムリミットの決め方や警告メッセージ）は有利に組み合わせることができる。

ａ：ソケット接続

ＩＰアドレスは定数。

ｂ：接続初期化

ｃ：ストリームのオープン／クローズ

ｄ：ストリーミング

ｅ：交換終了とソケットクローズ

Ｃ：セットトップボックス２０
ＳＴＢ２０の一つがAL_OPENメッセージを送信したら、それはサーバー１０がストリームデータパケットを送信するまで待つ（受信はノンブロッキングである）。ＳＴＢ２０はソケットからできるだけ多くのデータを読み込んで、ＣＰＵ（Central Processing Unit［中央処理装置］の略）を注入および復号プロセスのスケジューリングが行えるように解放する。ある好適なアルゴリズムは、データポンプ２７の各スケジュールにおいてソケットバッファサイズの半分を読み込むことを含む。このデータポンプというのは、ＳＴＢ２０内に組み込まれた要求を発する装置２の一部である。

現在手にはいるＳＴＢの設計では、持続的なビットレートの測定された最大値は６Ｍｂｐｓ程度であり、良好なＭＰＥＧ２ビデオおよびオーディオ品質に十分な高率である。

データポンプ２７は入力ソケットバッファ２１に直接、中央ＦＩＦＯ２６の「書き込み」ポインタおよび前記ＦＩＦＯの連続的に利用可能なスペースを与える（これにより、ソケットバッファからＦＩＦＯバッファへの中間コピーが回避できる）。

処理のために中央ＦＩＦＯ２６からの各転送の間に扱われるデータの大きさは、LenAsked値で与えられるが、これはＦＩＦＯサイズの半分であり、スケジューリングの仕事が重くなるのを避けている。そのようなＦＩＦＯ転送が完遂したら、LenAskedは消費者ポインタに従って連続的に利用可能なサイズである。前記要求装置２の一部である注入部２８がそれを管理することが意図されている。

ユーザーがあるストリームから別のストリームに切り換えた場合、ＦＩＦＯ２６およびビットバッファ２１はフラッシュされてもよい。

サーバー１０は読み込みファイルの予期はしない。読み込み長さと送信長さは定数で、バースト転送を避けるために内部入力ソケットバッファ２１（CSOCKBUFSZ）よりも小さい。プロトコルはまた送信速度の制御を行う際に消費者速度（ＣＢＷパラメータ：ＳＴＢ２０上でデータポンプ２７によって管理されている中央ＦＩＦＯ２６）も参照する。

ＩＲＤ処理の概要について以下に説明する（図８参照）。記載されるさまざまな要素は要求装置ＩＲＤの部分である。

・ザッパー（「アプリ」）５４：ユーザーの選択（番組識別子）を取得し、データポンプ２７および注入器２８を走らせ、ＡＶデコーダを始動させる。ユーザーが番組を変更したら、ザッパーはデータポンプ２７および注入器２８を再び走らせるまで停止させる。ビデオデコーダは停止する必要はない。

・イーサネット（登録商標）ドライバ５２：ＴＣＰ／ＩＰスタック５３を物理的なイーサネット（登録商標）コントローラ５１につなぐインターフェースとなる。該５１はたとえばＣＳ８９００Ａとしてシラスロジック社により市販されているものである。速度は３Ｍｂｐｓから６Ｍｂｐｓの間である。よって、４Ｍｂｐｓの速度なら、１フレーム（１４６０バイト）は２．８６ｍｓで処理される。ドライバ５２に制御データ送信を警告するために割り込み（interruptions）プロセス（「ＩＴ」）が設けられている。

・ＴＣＰ／ＩＰスタック５３：イーサネット（登録商標）上のＴＣＰ／ＵＤＰ／ＩＰスタック５３はソケット・ノンブロッキングＡＰＩ（Application Programming Interface［アプリケーションプログラミングインターフェース］）を備えている。ＩＰアドレスを動的に取得するためにＤＨＣＰ（Dynamic Host Configuration Protocol［動的ホスト構成プロトコル］の略）クライアントが埋め込まれている。ＴＣＰ／ＩＰスタック５３は最大６４キロバイトのソケットバッファ２１およびタイマー４２を利用する。

・データポンプ２７：サーバー１０からＭＰＥＧ２−ＴＳ（Transport Stream［トランスポートストリーム］の略）のデータを取得するためにＵＤＰポートを使う。動作においては、ユーザーによってファイル識別子が指定され、接続の間にサーバー１０に直接送信される。ひとたびサーバー１０に接続されたら、データポンプ２７は利用可能なＦＩＦＯ長を読み取り、ＦＩＦＯ２６がいっぱいに近づいていたら（ＨＦＩＦＯ閾値）データストリーミングを一時停止するよう要求し（ＸＯＦＦメッセージ）、ＦＩＦＯ２６が空に近づいたら（ＬＦＩＦＯ閾値）再開するよう要求する。これはまた、ユーザーがザッピングすることを可能にし、その際にはＦＩＦＯ２６をフラッシュする。フラッシュ工程は次いで注入部２８にも伝搬される。

・中央ＦＩＦＯ２６：復号処理およびストリーミング処理を調整し、ネットワークバーストに対処するためのＸメガバイト（たとえば１メガバイト）のＦＩＦＯ。ＦＩＦＯマネージャは３つの閾値を管理する。低閾値ＬＦＩＦＯおよび高閾値ＨＦＩＦＯはそれぞれ注入プロセスの再開と一時停止を引き起こし、中間閾値ＭＦＩＦＯはデータポンププロセスを引き起こす。

送信のためには、たとえば単位の大きさとして３２キロバイトが選ばれる（単位の大きさが５０キロバイトなら送信は２０ｍｓを要する）。すなわち、４Ｍｂｐｓの速度を考えると、中央ＦＩＦＯ２６をいっぱいにするのに２秒かかる。一方、いっぱいになったＦＩＦＯの復号も２秒に相当する。

サーバーファイルの８キロバイトのデータを取ると、それはクライアントのソケットバッファに到達するのに１６ｍｓｅｃかかる。同じデータはＳＴＢ埋め込みのＣＰＵに応じて約２〜４ｋｂｙｔｅｓ／ｍｓｅｃの速度でＦＩＦＯ２６に転送される。よって、ＳＴＢ転送プロセスは無視できる。

中央ＦＩＦＯ２６はサーバー１０およびネットワークで生じうるジッターを吸収する。好ましくは、クライアントのバンド幅のレートＣＢＷはエンコード速度ＥＢＲより大きい。ＥＢＲとＣＢＷの値が近い場合には、ＦＩＦＯ２６はより小さくてもよい。

・注入部２８：ＰＣサーバー１０（生産者）と復号処理（消費者）との間の流れ制御の考えがここで語られる。ひとたび開始されると、注入部２８はビデオビットバッファのレベルを監視し、ＤＭＡ（Direct Memory Access［直接メモリアクセス］の略）を通じて所与の量のＦＩＦＯデータをＴＳＭＵＸ（Transport Stream Multiplexer［トランスポートストリームマルチプレクサ］の意）５５に注入する。その際、ＳＷＴＳ入力（Software Transport Stream［ソフトウェアトランスポートストリーム］の略）５６を使う。

・ＴＳＭＵＸ５５：このインターフェースは、ＳＴマイクロエレクトロニクス社によるＳＴ５５１６として市販されているようなレジスタ６１（図９）に基づいて、メモリからＰＴＩ（Programmable Transport Interface［プログラム可能な転送インターフェース］の略）５７にＳＷＴＳ方式で（構成レジスタ６３を使って）データの注入ができるようにする。バイト転送速度は調整でき、レートはたとえば４０Ｍｂｐｓである。

・ＡＶスタック５８：オーディオおよびビデオ復号過程。復号のための目標とされるＰＩＤ（Packet IDentifier［パケット識別子］の略）に向けられた復号処理を設定する。復号処理を開始し、ビデオビットバッファレベル（video bit buffer level―VBBLと記す）を指示することを可能にする。ビットバッファはアンダーフローは許容する。

・ＡＶ同期：ビデオおよびオーディオのＰＴＳ値（Program Time Stamp［番組タイムスタンプ］の略）に基づいている。ＰＣＲは運用されていないので、２７ＭＨｚＶＣＸＯは固定した義務的な値を有している。ビデオ復号処理が開始され、ＳＴＣ値（System Time Clock［システム時間クロック］の略）を最初のビデオＰＴＳで初期化する。オーディオはそのＰＴＳ値がＳＴＣ値に近くなるまでフレームをスキップする。

Ｃ１：注入部２８
注入部２８とその機能についてこれから詳述する（図９を参照）。

ＳＷＴＳ入力５６へのデータの注入は、ＰＴＩのＤＭＡ３チャネルを通るよう経路制御されるSWTS_REQ信号を使ってペース調整される。前記SWTS_REQ信号は、内部ＳＷＴＳ ＦＩＦＯ６２に少なくとも１６バイトの余裕があるときに発される。SWTS_REQが低で、ＸメガバイトのＦＩＦＯ２６から読み込むべきデータがあるたびに、プログラム可能なバイト数がＳＷＴＳ入力５６に転送される。転送完了の時点において、注入部にデータが転送されたとの信号を送るよう割り込みがセットされる。

ＳＷＴＳ入力の場合、ビデオおよびオーディオの圧縮データ（compressed data）ＦＩＦＯ（それぞれ６４、６５と記される）中で目的ポインタが固定される。それは注入が処理される場所でCD_FIFOなどである。ＳＷＴＳアドレスがCD_FIFOアドレスを置き換え、PTI_DMA3SETUPレジスタによって直接インクリメントがプログラムされることはない（よって、DMA3BLOCKMOVE＝0）。
ＰＴＩ５７バージョンドライバ
ＰＴＩドライバはＤＭＡ注入のためのソフトウェアサポートを提供する。それはＰＴＩ１に対する上位互換モードで使われるＰＴＩ３ハードウェアにおいて走る。提示される実施形態においては、唯一の制限は、割り込みモードがＤＭＡ転送終了の信号を送るためには許容されていないという点である。pti_data_dma_synchronize関数への呼び出しはＤＭＡ転送の終了まで封じられる。
ＰＴＩ ＤＭＡ３とＴＳＭＵＸ５５の相互接続
SWTS_REQ信号は、CONFIG_CONTROL_Aレジスタを設定することによってPTINOT_CDREQ3信号に多重化される（すなわち、PTIA_CDREQ3_MUXSEL[3:0]＝TSSUB_SWTS_REQ）。

注入部は、ＰＴＩ５７にデータを注入する前に、ビデオおよびオーディオビットバッファ（それぞれ６６、６７と記される）の占有レベルを知る必要がある。各ストリームがビデオおよびオーディオ成分を含み、オーディオビットバッファ６７の容量がオーバーフローやアンダーフローを避けるのに十分であるとすると、ビデオビットバッファのレベルだけを監視することも許容できうる。

これを行うには、VID_VBLレジスタが読み込まれる。これがビデオビットバッファ６６の現在のレベルを２キロビット（２５６バイト）単位で与える。このバッファ内の空きスペースの大きさが次いですぐに導出される。注入部はユーザー中央ＦＩＦＯ２６からＰＴＩ５７へのＴＳＭＵＸ５５を通じたＤＭＡ転送を開始する。転送の大きさは、
min(RVBB，中央ＦＩＦＯ利用可能データ)
で、RVBB（Remaining space in Video Bit Buffer［ビデオビットバッファ内の残りスペース］）はＶＢＢ（Video Bit Buffer［ビデオビットバッファ］）６６内で残っている空きスペースを表している。

ここでは、ＶＢＢ６６のみを考慮に入れて転送について語った。このことは、ＡＢＢ（Audio Bit Buffer［オーディオビットバッファ］）６７がオーバーフローを起こさない十分な大きさがあることを示唆している。

４Ｍｂｐｓ（５００ｋｂｙｔｅｓ／ｓ）のストリームに対しては、１００ｍｓごとに５０キロバイトのデータ転送が加わっていく。ＳＷＴＳレートが４０Ｍｂｐｓ（５Ｍｂｙｔｅｓ／ｓ）に固定されているとすると、その転送時間は少なくとも１０ｍｓである。よって、対応するスレッドは各転送の間の９０ｍｓは空いていることになる。

Ｃ２：オーディオビデオスタック５８
オーディオビデオスタック５８には三つの主要な機能がある：
・多重化解除を処理してオーディオおよびビデオデコーダを開始し、
・オーディオとビデオの間の同期を管理し、
・ビデオビットバッファレベルを取得し、それを注入部クライアントに供給することでデータストリーミングを調整する。

ビデオを一時停止したり画面をフリーズさせたり、音声を消したり、あるいは静止画像を表示したりすることは必要ではない。

オーディオおよびビデオデコーダの同期は、オーディオＰＴＳおよびビデオＰＴＳの助けによりなされる。ストリームからのＰＣＲは運用されておらず、ＶＣＸＯは２７ＭＨｚに設定されている。

ＳＴＣ値は最初ビデオＰＴＳに設定される。同期アルゴリズムはすでにオーディオドライバ内に存在している。必要なのは、ＳＴＣ値をビデオＰＴＳに設定するために関数を修正することだけである。これは次のように処理される。

ビデオＰＴＳの監視はストリーム中にエラーが起こったときでもアボートされない（ＳＴＣ／ビデオＰＴＳの距離はＰＴＳが発生するたびに更新される）。

当該スタックはまた、ビットバッファアンダーフローに関しても許容できる。すなわち、復号処理のリセットもビットバッファのリセットも行われない。

ビットバッファ（ＶＢＢ６６およびＡＢＢ６７）はＰＵＬＬモデルのための適正な大きさになっている。すなわち、デコーダ処理のほうがデータストリーミングを調整する。ＶＢＢ６６については、ＭＬＭＰ仕様として大きさが決まっており、３５６キロバイト程度である。ＡＢＢ６７の大きさを決めるには、最低ビデオビットレートと最高オーディオビットレートとの比が計算される。ＡＢＢ６７の大きさは、この比を利用して、mVBRを最小ビデオビットレート（minimum video bit rate）、MABRを最大オーディオビットレート（maximum audio bit rate）として、次式によって決める。

ABBの大きさ＝MABR/mVBR×（MLMP VBBの大きさ）
たとえば、mVBRおよびMABRはそれぞれ１Ｍｂｐｓおよび４４８ｋｂｐｓである。

追加的な仕様として、クライアントはスローモーションや早回しのための制御メッセージをサーバー１０に送ってもよい。

スローモーションの場合のある具体的な実施形態では、各データ区画を送信する間隔PERIODの値を大きくする（周期の修正はクライアントから要求されるスローモーションの度合いによる）。ただし、保持メッセージの周期は不変に保たれる。

早回しや逆回しのある特定の変形実施形態においては、クライアントはサーバー１０に対してさらに、ストリーミングされるべきデータファイル中の位置を順番づけるための特定の制御メッセージSEEKを送ることができる。これは、当該ファイルの始点または終点を基準としたバイト数などである。SEEKメッセージはその際、再生方向とオフセットの両方を含んでいてもよい。その際、クライアントはSEEKメッセージをＸＯＦＦとＸＯＮメッセージの間で使用する。選択されるデータ量ならびに再生スピードを支配し、早回しの場合にはアンダーフローを補償するためである。この場合、送信される命令の順番は、ＸＯＦＦ／ＳＥＥＫ（方向、オフセット）／ＸＯＮ／ＸＯＦＦ…となる。

さらに、前記の特定の実施形態では、クライアントはサーバー１０に早回しのために選択された復号アルゴリズムに関する情報を送信することが意図されている。たとえば、ＧＯＰ（Group of Pictures［ピクチャーグループ］）において「Ｉ」タイプの画像のみを取るなどである。

その際、クライアントのほうが位置の選択を適切に行うことによって定常的な再生には責任をもつ。

また、スローモーションの場合と同様に、保持メッセージの周期は不変に保たれる。

本発明に基づくデータ送信装置を有するサーバーと本発明に基づくデータ要求装置を有する受信機とに関わる通信環境を示す図である。 図１のデータ送信装置のブロック図である。 図１のデータ要求装置のブロック図である。 要求装置がＩＲＤ内に組み込まれ、送信装置がＰＣサーバー内に組み込まれている、図１の通信環境の特定の実施形態を示す図である。 図４の通信環境におけるストリーミングに関わる通信路とバッファを示す図である。 図４の通信環境におけるプロトコルの状態遷移図をサーバー側から示す図である。 図４の通信環境におけるストリーミングの状態遷移図をサーバー側から示す図である。 図４のＩＲＤ内の処理の概要を示す図である。 図４のＩＲＤの一つにおける注入部の機能を図解する図である。

符号の説明

１ データ送信装置
２ データ要求装置
７ ＰＳＴＮネットワーク
１０ サーバー
１１ 受信
１２ 指定
１３ ストリーミング
１４ 転送
１５ 警報
１６ 解釈
１７ ハードディスク上のファイル
１８ バッファソケット
２０ 受信機
２１ バッファ
２２ 送信
２３ 受信
２４ 処理
２５ 情報取得
２６ メモリ
２７ データポンプ
２８ 注入部
３０ 制御
３１ 保持
３２ 調整
３５ ユーザーインターフェース
４３ ＶＤＳＬモデム
４４ ＶＤＳＬモデム
４５ スイッチ
５０ ＭＬＭＰ ＭＰＥＧ

Claims (15)

1. 少なくとも一つのデータサーバー（１０）に少なくとも一つの第一の通信ネットワーク（５）を通じてのデータを要求する装置（２）であって、
   ・サーバー（１０）に決められたデータの要求（REQU）を少なくとも一つの第二の通信ネットワーク（６）を通じて送信する送信手段（２２）と、
   ・前記サーバー（１０）から前記第一の通信ネットワーク（５）を通じてストリームデータ（DATA）を受信するための、そして該データをそれが利用されるよう処理手段（２４）に提供するための受信手段（２３）と、
   ・前記サーバー（１０）からのデータストリーミングを一時停止させるよう意図された一時停止制御信号（XOFF）を生成するための、そして前記一時停止制御信号（XOFF）の前記サーバー（１０）への前記第二のネットワーク（６）を通じた前記送信手段（２２）を介しての送信を引き起こすための、制御手段（３０）とを有しており、
   当該データ要求装置（２）が、当該データ要求装置（２）における正常動作を前記サーバー（１０）に示すよう意図された正常状態信号（NORMAL、KEEPALIVE）を生成するための、そして該正常状態信号（NORMAL，KEEPALIVE）の前記サーバー（１０）への前記第二のネットワーク（６）を通じた前記送信手段（２２）を介しての周期的送信を引き起こすための、保持手段（３１）を有することを特徴とする、データ要求装置。
2. 前記制御手段（３０）が前記サーバー（１０）からのデータストリーミングを一時停止のあとで再開させるよう意図された再開制御信号（XON）をも生成するよう意図されており、前記送信手段（２２）が前記サーバー（１０）に前記第二のネットワーク（６）を介して前記再開制御信号（XON）を送信するよう意図されていることを特徴とする、請求項１記載のデータ要求装置（２）。
3. 前記要求装置（２）が、ユーザーが前記制御手段（３０）および前記送信手段（２２）を作動させて前記制御信号（XOFF、XON）が前記サーバー（１０）に前記第二のネットワーク（６）を介して与えられるようにするユーザーインターフェース（３５）を有していることを特徴とする、請求項１または２のうちいずれか一項記載のデータ要求装置（２）。
4. 前記受信されたデータ（DATA）が利用される前に中央メモリ（２６）内に保存され、前記データ要求装置（２）が前記中央メモリ（２６）内の前記データが該中央メモリ（２６）の所定の高閾値レベル（HFIFO）を超えたときに前記制御手段（３０）を作動させて一時停止制御信号（XOFF）を生成するよう意図されている調整手段（３２）を有することを特徴とする、請求項１ないし３のうちいずれか一項記載のデータ要求装置（２）。
5. 前記調整手段（３２）が、前記ストリーミングが当該調整手段（３２）によって一時停止されており前記中央メモリ（２６）内の前記データが前記中央メモリ（２６）の所定の低閾値レベル（LFIFO）まで減少したときに前記制御手段（３０）を作動させて再開制御信号（XON）を生成するよう意図されていることを特徴とする、請求項４記載のデータ要求装置（２）。
6. 前記中央メモリ（２６）の前記閾値レベル（HFIFO、LFIFO）のうち少なくとも一つが前記データ要求装置（２）と前記サーバー（１０）との間の往復遅延時間（RTT）に依存することを特徴とする、請求項４または５のうちいずれか一項記載のデータ要求装置（２）。
7. ・前記受信手段（２３）が、前記サーバー（１０）が前記正常状態信号（NORMAL、KEEPALIVE）をしかるべき時間内に受信しなかった場合に、前記サーバー（１０）から前記第一のネットワーク（５）を通じて特別な警告メッセージ（WARN）を受信するよう意図されており、
   ・前記保持手段が、前記特別な警告メッセージ（WARN）が受信され次第、前記第二のネットワーク（６）を通じた前記サーバー（１０）への正常状態信号（NORMAL、KEEPALIVE）の送信を引きこすよう意図されていることを特徴とする、
   請求項１ないし６のうちいずれか一項記載のデータ要求装置（２）。
8. 請求項１ないし７のうちいずれか一項記載のデータ要求装置（２）を有することを特徴とする、デコーダ。
9. 少なくとも一つのデータサーバー（１０）に少なくとも一つの第一の通信ネットワーク（５）を通じてのデータを要求するプロセスであって、
   ・サーバー（１０）に決められたデータの要求（REQU）を少なくとも一つの第二の通信ネットワーク（６）を通じて送信し、
   ・前記サーバー（１０）から前記第一の通信ネットワーク（５）を通じてストリームデータ（DATA）を該データが利用できるよう受信し、
   ・前記サーバー（１０）からのデータストリーミングを一時停止させるよう意図された一時停止制御信号（XOFF）を生成し、前記第二のネットワーク（６）を通じて前記サーバー（１０）に送信するステップを有しており、
   当該データ要求プロセスが、当該データ要求装置（２）における正常動作を前記サーバー（１０）に示すよう意図された正常状態信号（NORMAL、KEEPALIVE）を生成し、前記サーバー（１０）に前記第二のネットワーク（６）を通じて周期的に送信することを含むことを特徴とする、データ要求プロセス。
10. 少なくとも一つの第一の通信ネットワーク（５）を通じてデータを送信する装置（１）であって、
    ・少なくとも一つのデータ要求装置（２）から少なくとも一つの第二の通信ネットワーク（６）を通じて決められたデータの要求（REQU）を受信する受信手段（１１）と、
    ・前記データ（DATA）の前記データ要求装置（２）への前記第一のネットワーク（５）を通じたストリーミングを引き起こすストリーミング手段とを有し、
    前記受信手段（１１）は前記データ要求装置（２）から一時停止制御メッセージ（XOFF）を受信するよう意図されており、前記ストリーミング手段（１３）は前記一時停止制御メッセージ（XOFF）が受信されたときには前記データストリーミングを一時停止するよう意図されており、
    ・前記受信手段（１１）が、前記データ要求装置（２）から周期的に正常状態信号（NORMAL、KEEPALIVE）を受信するよう意図されており、
    ・前記データ要求装置（２）が、前記正常状態信号（NORMAL、KEEPALIVE）がしかるべき時間内に受信されなかったときに警報状態を引き起こすよう意図されている警報手段（１５）を有し、
    当該データ送信装置（１）が好ましくは請求項１ないし７のうちいずれか一項記載のデータ要求装置（２）のために備えがされていることを特徴とする、データ送信装置。
11. 前記警報手段（１５）が、前記正常状態信号（NORMAL、KEEPALIVE）が該正常状態信号を受信するのに期待される時間周期のあとある安全期間を経過したのちにも全く受信されない場合に前記警報状態を引き起こすよう意図されており、前記安全期間が前記データ要求装置（２）と前記データ送信装置（１）との間の往復遅延時間（ＲＴＴ）に依存するものであることを特徴とする、請求項１０記載のデータ送信装置（１）。
12. ・前記警報手段（１５）が、前記正常状態信号（NORMAL、KEEPALIVE）がしかるべき時間内に全く受信されない場合に警告メッセージ（WARN）を生成するよう意図されており、
    ・当該データ送信装置（１）が、前記警告メッセージ（WARN）を前記データ要求装置（２）に前記第一のネットワーク（５）を通じて送信するよう意図されている転送手段（１４）を有し、
    ・前記警報手段（１５）が、前記警告メッセージ（WARN）の送信後ある猶予期間が経過したのちにのみ前記警報状態を引き起こすよう意図されていることを特徴とする、
    請求項１０または１１のうちいずれか一項記載のデータ送信装置（１）。
13. 前記受信手段（１１）が前記データ要求装置（２）から再開制御メッセージ（XON）を受信するよう意図されており、前記ストリーミング手段（１３）が、前記ストリーミングが一時停止されており前記再開制御メッセージ（XON）の一つが受信されたときに前記データストリーミングを再開するよう意図されていることを特徴とする、請求項１０ないし１２のうちいずれか一項記載のデータ送信装置（１）。
14. 少なくとも一つの第一の通信ネットワーク（５）を通じてデータを送信するプロセスであって、
    ・少なくとも一つのデータ要求装置（２）から少なくとも一つの第二の通信ネットワーク（６）を通じて決められたデータの要求（REQU）を受信し、
    ・前記データ（DATA）を前記データ要求装置（２）に前記第一のネットワーク（５）を通じてストリーミングし、
    ・前記データ要求装置（２）から一時停止制御メッセージ（XOFF）を受信し、前記一時停止制御メッセージ（XOFF）が受信されたときには前記データストリーミングを一時停止するステップを有しており、また、
    ・前記データ要求装置（２）から周期的に正常状態信号（NORMAL、KEEPALIVE）を受信し、
    ・前記正常状態信号（NORMAL、KEEPALIVE）がしかるべき時間内に受信されなかったときに警報状態を引き起こすステップを有し、
    当該データ送信プロセスが好ましくは請求項１０ないし１３のうちいずれか一項に準拠したデータ送信装置（１）によって実行されることを意図されていることを特徴とする、データ送信プロセス。
15. 当該プログラムがコンピュータ上で実行されたときに請求項９および１４のプロセスのうちの一方のステップを実行するプログラムコード命令を含んでいることを特徴とする、コンピュータプログラムプロダクト。

Images