(57)【要約】  特に、ＲＴＰリアルタイムプロトコルストリーミングのための、ハードウエア促進ストリーミング装置には、ネットワーク促進ストリーミングシステムを介して転送する１以上のデータパケットのポインタ、ヘッダ長、及びオフセットを決定する指示ファイルが使用される。この指示ファイルは、例えば、バックグラウンドで作動する形で、制御処理装置により設定され、格納されて、ＲＴＰペイロード及び、その他のデータに対して、ヘッダサイズやポインタ等の、ある情報を決定することが出来る情報を提供する。その際、該データのエグレス中に、関係するメディアやプロトコルのタイプに関連した分析をする必要がない。これにより、好ましくは、速度に関しては可能な限りにおいてハードウエア素子に頼り、より複雑だが、低頻度であり、及び／又は、リアルタイムでストリームする際には、時間に関して敏感ではない、制御機能の計算容量を、制御処理装置に残しておくことにより、むしろ注意を要求される制御処理装置の機能の負担を軽くし、また、エグレス処理を反復して進めることが出来る。
2009512280.tif 000002
【特許請求の範囲】
【請求項１】
データパケットの少なくとも１つのソースからのデータパケットを、該データパケットの少なくとも１つの目的地に向けて転送するストリーミング装置において、
前記データパケットのソースとのデータ通信、及び前記目的地とのデータ通信を行うネットワークアクセラレータと、
前記ソースから前記目的地へのデータパケットのストリーミングを制御するように作動する制御処理装置とを有し、
前記制御処理装置は、前記ソースから前記目的地へのデータパケットのストリーミングにおける、少なくとも所定のステップの間に、該制御処理装置から前記ネットワークアクセラレータへ伝達される１セットのパラメータ値を設定するようにプログラムされており、
前記ネットワークアクセラレータは、前記パラメータ値の機能として、また、実質的に制御処理装置とは独立する形で、前記所定のステップに続いて、データパケットを、前記ソースから前記目的地までストリームするように構成されている、ストリーミング装置。
【請求項２】
前記ソースと目的地の内少なくとも１つは、前記ソースと前記ネットワークアクセラレータが連結しているデータ通信ネットワークを介して、前記制御処理装置と通信するクライアントから構成されていることを特徴とする、請求項１記載のストリーミング装置。
【請求項３】
前記制御処理装置によって設定された前記パラメータ値には、通信ネットワーク上で、制御処理装置とネットワークアクセラレータとのデータ通信において、少なくとも二つのクライアントを識別するアドレッシング情報が含まれていることを特徴とする、請求項１記載のストリーミング装置。
【請求項４】
前記パラメータ値は、少なくとも前記ソースと目的地のアドレッシング情報を有する、ソースと目的地の内の１つによって開始される要求信号の機能として、前記制御処理装置によって設定されることを特徴とする、請求項３記載のストリーミング装置。
【請求項５】
前記制御処理装置によって生成された指示ファイル中に前記パラメータ値を設け、更に、複数の同時発生するストリーミング処理に関連した、複数の指示ファイルを有するメモリを、前記処理装置に連結する形で設けたことを特徴とする、請求項３記載のストリーミング装置。
【請求項６】
前記パラメータ値は、識別コード、パケットカウント、ヘッダブロックサイズ及び、ポジションポインタ及びカウント値の内１つから構成されていることを特徴とする、請求項４記載のストリーミング装置。
【請求項７】
前記パラメータ値は、要求信号の機能として、前記制御処理装置によって設定され、データパケット用の識別コードを有する一般化ヘッダとして、前記制御処理装置から、前記ネットワークアクセラレータに伝達されることを特徴とする、請求項３記載のストリーミング装置。
【請求項８】
前記ネットワークアクセラレータは、前記一般化ヘッダを前記目的地に転送するパケットに含むように動作し得ることを特徴とする、請求項７記載のストリーミング装置。
【請求項９】
前記ネットワークアクセラレータは、パケットのストリーミングが進むにつれて、前記目的地へ送信する一般化ヘッダの中に、制御情報を挿入するよう動作し得ることを特徴とする、請求項８記載のストリーミング装置。
【請求項１０】
前記ネットワークアクセラレータは、前記目的地が、受け取ったパケットを順序付けることが出来る、パケットデータカウント数を挿入するように動作し得ることを特徴とする、請求項９記載のストリーミング装置。
【請求項１１】
前記制御処理装置、前記ソース及び前記目的地の内、少なくとも１つ、前記ネットワークアクセラレータ、通信提示制御メッセージ、個別セッション制御メッセージ、及びリアルタイムストリーミングパケットを有し、該ネットワークアクセラレータは、該リアルタイムストリーミングパケットを処理するのに対して、該制御処理装置は該制御メッセージを処理することを特徴とする、請求項１記載のストリーミング装置。
【請求項１２】
前記制御処理装置は、次のステップ、即ち、
ストリーミング動作の為に、通信リソースを割り当てるＳＥＴＵＰ、
少なくとも１つの前記ソースと、少なくとも１つの前記目的地の間で、少なくとも１方向にストリーミング動作を始める、ＰＬＡＹとＲＥＣＯＲＤの内少なくとも１つ、及び、
以前に開始したストリーミング動作を一時停止するＰＡＵＳＥ及びＴＥＡＲＤＯＷＮの内少なくとも１つ、それぞれ、ＰＡＵＳＥでは前記リソースの割り当てを保持しておき、ＴＥＡＲＤＯＷＮでは該リソースを放棄する、
ステップを設定することにより、前記ネットワークアクセラレータによってストリーミングを制御することを特徴とする、請求項１１記載のストリーミング装置。
【請求項１３】
制御処理装置は、前記提示制御メッセージにはＲＴＳＰプロトコルに従って、また、前記個別セッション制御メッセージにはＲＴＣＰプロトコルに従って動作することが出来、前記リアルタイムストリーミングパケットは、ＴＣＰ及びＵＤＰプロトコルの内、少なくとも１つを使って、ＲＴＰプロトコルに従うことを特徴とする、請求項１２記載のストリーミング装置。
【請求項１４】
関連ヘッダ情報を有する、パケット化したデータコンテンツを設け、これにより、パケット化したデータコンテンツは、該コンテンツに関するソース及び目的地の内、少なくとも１つで処理され、
ストリーミング動作を開始し、該ストリーミング動作のために、ソース及び目的地の内、少なくとも１つをアドレスし、制御処理装置のプログラム動作の機能として、即ち、前記ソースと前記目的地の内、少なくとも１つとデータ通信する際に、ストリーミング動作の、ポーズとストップの内、少なくとも１つを実行し、
制御処理装置は、前記プログラム動作に従って、ストリーミング動作の進行中に、少なくとも一時的に維持する情報を含む指示ファイルを設定するように動作することが出来、
ストリーミング動作の開始後に、前記指示ファイルから提供され、そして、ストリーミング動作が進むにつれて、処理された情報を処理するネットワークアクセラレータの動作により、ストリーミング動作情報を実行する、
ことから構成する、コンテンツを実質的にリアルタイムでストリーミングする方法。
【請求項１５】
前記ネットワークアクセラレータは、前記ストリーミング動作中に伝達されるパケットヘッダ内に、指示ファイルからの情報を挿入することを特徴とする、請求項１４記載の方法。
【請求項１６】
前記ネットワークアクセラレータは、前記パケットヘッダ内に、アドレッシング情報及び、パケットデータ数及びパケットデータポインタの内、少なくとも１つを挿入することを特徴とする、請求項１５記載の方法。
【請求項１７】
前記ストリーミング動作の開始後に、前記制御処理装置のプログラム動作によりストリーミング動作を変更することを含むことを特徴とする、請求項１６記載の方法。
【請求項１８】
更に、前記制御処理装置を介して、複数の指示ファイルを設定し、維持することを含み、前記指示ファイルのそれぞれは、少なくとも１つの、同時に動作するストリーミング動作に関するものであることを特徴とする、請求項１４記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
［関連出願のクロスリファレンス］
本出願は、２００５年１０月７日出願の６０／７２４，４６２、２００５年１０月７日出願の６０／７２４，４６３、２００５年１０月７日出願の６０／７２４，４６４、２００５年１０月７日出願の６０／７２４，７２２、２００５年１０月７日出願の６０／７２５，０６０、２００５年１０月７日出願の６０／７２４，５７３の米国仮特許願の優先権を主張しており、これらの出願は、ここで、参照することで、全体が組み込まれることになる。
【０００２】
［発明の背景］
本発明は、例えば、デジタルビデオ処理センタ、娯楽システム、会議開催システム、及びＲＴＰストリーミングを使用したその他の適用における、リアルタイムデータ転送装置及び方法に関する。本発明はまた、パケット取り扱い中に情報を決定し、該情報を、例えば、パケットアドレス情報又はパケット処理情報として、出て行くデータパケットのヘッダ中に挿入する、パケットデータ転送に適用することが出来る。この操作は、ＲＴＰストリーミングのためのリアルタイムデータ速度と歩調を合わせる必要があり、好ましくは、限られた計算負荷で行う必要が有る。本発明によると、制御処理装置及び設備による挿入により、指示ファイルが、パケットが出て行く間にそうした情報により生成される。
【背景技術】
【０００３】
本発明の装置及び方法は、多様な記録、再生及び処理機能を提供することが出来、そこでは内容及び制御情報が、データを格納し、提示し、処理する機能的な要素との間でやり取りされる。データストリーミングコンテンツに関しては、制御情報に応答する際に、ある複数のステップが必要となる。例えば、接続を開始する際に、制御情報に応答するためには、データパケット処理装置及びデータパケットアドレス装置をセットアップする必要がある。格納媒体、通信パス、或いはソケットから転送させなければならないパケットを見つけ出し、又はこれにアクセスすることが必要になるかもしれない。転送装置は、制御入力に基づいて、また、パケット内で見つけた情報にも基づいて、転送をどの程度精密に進行させるかを決定する。必要なコード、フラッグ、アドレス、及び他の条件付きのインジケータを決める必要があるかもしれないし、また、シグナリングにおいては、これらをパケットヘッダ内に挿入することにより、また、最初のパケットを携えるデータブロックには、新たなヘッダを設けることによりこれらを使用する。これらのステップは、かなりの量の計算上の複雑さが必要となり、通常ソフトウェアに頼っている。
【０００４】
この接続がなされ、データ転送が始まると、必要となるものが幾分異なってくる。例えば、連続するストリーム中の、次のパケットの情報、制御及びアドレスは、前回のパケットに使用する情報に密接に関連している可能性がある。連続するパケットは、ストリームを介して、殆ど同一に扱うことになる。このパケットは、パケットシーケンス番号等の、インクリメンタル面に関して相違する。ある種の格納媒体から読み出した場合、ソースアドレスが先行する。しかしながら、計算上の複雑さのレベルはかなり低い。これらのステップは、スピード及び効率から利益を得ることになると共に、一般的にハードウェアに頼っている。
【０００５】
例えば、ネットワーク接続ストレージ素子から、又は該素子に対するデータパケットの繰り返されるルーティング等の、計算上は複雑とは言えない反復データ処理ステップは、計算上複雑ではあるものの、比較的に低頻度な制御処理やアドレッシングステップのような機能とは異なる形で扱われると都合が良い。必要なものは、最適な解決である。
【０００６】
一般的に、異なる可能性を有するデータフォーマットを用いて異なる可能性を有する装置で情報交換が可能となるとが都合がよい。異なる装置及びデータフォーマットを高いデータ転送速度で用いつつ、データ処理システム内での汎用性を持たせる必要性から設計的な挑戦が生じている。
【０００７】
産業規格が一定のデータ形式のフォーマットを決定している。規格は、アドレッシング及び信号技術、データ貯蔵及び復旧、通信、その他に関するものである。規格は、複合的なレベルで適用される。例えば、パケット送信規格又はプロトコルは、ビデオエンコード規格などに基づいてエンコードされたビデオデータをトランスポートする際に使用される。
【０００８】
ソースから目的地の間で伝達されたパケットデータは、よく、データフォーマット変換、演算、バッファリング及び同様な処理及び／又は格納ステップなどの中間処理ステップの対象となる。並列サーバ及び端末装置を有するデータ処理システムにおいては、演算負荷の一部はデータフォーマット及びリフォーマットに関連する動作に向けられる。負荷の一部はデータソースと目的地間のアドレッシング及び切り替えであり、ユーザの選択など状況に対応した変更処理でもあり得る。
【０００９】
データパケットをストリーミングする際に必要なことは、出て行くデータパケットの中に、パケット識別情報を設けることであり、この情報は、ストリームする信号パスに沿って配置される素子によって使用することが出来る。ストリームデータを分析するためにプログラムを実行中の制御プロセッサを用いることが出来るが、これは計算的な負荷となる。この機能を扱うために、ハードウェア装置を設けることが出来るかもしれないが、この種の装置は、必然的に複雑になり、プログラミングに関して汎用性に欠ける。これとは別の解決法が必要となる。
【００１０】
スピードに関して合理化し、単純化する目的は、計算的な複雑性をもたらすことに対して、勿論、矛盾した設計上の目標である。計算的なパワーの必要性に対して、速度及びデータ容量についての並行的な要請を最適化し、早くて多用途な装置を提供することは、重要である。本発明は、出て行くデータパケット、即ちパケットエグレスを管理するために必要とされるある機能を細分化することにより、必要なエグレス情報を作成する、複雑でかつ適応性のある計算的な機能を制御処理装置に割り当てることであり、これは、ソフトウェアによって実質的に具現化することが可能である。
【００１１】
好適な実施例では、本発明はリアルタイムプロトコル（ＲＴＰ）パケットストリーミングに関して説明される。パケットソースと目的地タイプの好適なグループは検討され、娯楽や遠隔会議に関するビデオデータ処理に適用することが出来るが、潜在的には警備上のモニタ、ゲームシステム及びその他の用途も含むものである。伝達経路は有線又は無線、及び企業又は公共ネットワークを含むことが出来る。再生用端末は、オーディオ及びビデオ娯楽システム、コンピュータワークステーション、固定又は携帯装置で構成することが出来る。データはネットワークサーバを使用しながら格納され、処理される。好適な通信システムはローカル及びワイドエリアネットワーク、ケーブル及び遠距離通信会社のネットワーク、その他を含むものである。
【００１２】
オーディオ及びビデオデータに関連して、リアルタイムプロトコル（“ＲＴＰ”、“リアルタイム伝送プロトコル”としても知られている）は、パケット化されたオーディオ及び／又は画像及び動画データをデータ通信ネットワーク上で、リアルタイムデータ速度で移動させるのに適している。オーディオ及びビデオデータのリアルタイム又はライブレートでの再生は、コンテンツの停止及び開始を避ける一方で、バッファに格納する必要性を最小限にすることが望ましい。遠隔会議や同様な通信の用途においては、パケット化されたデータの収集、処理、伝送及び読み出しは、顔を合わせた形のリアルタイム会議及び会話と矛盾しない、遅滞のないまた欠落のないものとすべきである。
【００１３】
ＲＴＰリアルタイムプロトコルは、オーディオ及びビデオを含むリアルタイムデータを能率的に取り扱うことを容易にするものである。それはインターネット電話などの相互サービスは勿論、メディアオンデマンドにも使用することができる。それは、オーディオ及びビデオを、多様なソース及び目的地に、また、多様なソース及び目的地から導くために使用して、同時処理を伴うプレゼンテーション及び／又は記録を可能とする。
【００１４】
データが取り扱われる方法は、制御及びアドレッシング機能を使用して、例えば特定のソース、目的地及び参加者を含んだ接続を開始し、また終了するなどにより、時々変更することが出来る。このように、ＲＴＰは内容を伝送するためのデータ内容部、及び、スタート、ストップ及びアドレッシングを含む、データを取り扱う方法を変えることに関する制御部分を含む。ＲＴＰの制御部分は、リアルタイムコントロール部ということで“ＲＴＣＰ”と呼ばれる。
【００１５】
ＲＴＰのデータ部分は薄い又はすっきりとしたプロトコルであり、連続的なメディア（例えば、オーディオ及びビデオ）の伝送などのリアルタイム特性を持った用途をサポートするために使用される。このサポートは、タイミングの生成、喪失の検出または回復、セキュリティ、内容の確認及び同様な機能を含むものであり、それらは繰り返しが多く、メディア内容の伝送に伴って実質的に連続して生じる。
【００１６】
ＲＴＣＰは、インターネットなどの通信ネットワーク内で、あらゆる大きさのグループのリアルタイム会議をサポートする。これにはソースの確認及びマルチキャストからユニキャスト翻訳及びオーディオ及びビデオブリッジのようなゲートウエイをサポートすることを含む。ＲＴＣＰは、異なるメディアのストリームを同期させるサポート及びマルチキャストグループへ受信者からのサービス品質のフィードバックを提供する。
【００１７】
ＲＴＰ及びＲＴＣＰは上記したタイプのデータ伝送を容易にするように特に作られたデータプロトコルであるが、与えられたネットワーク構成内では、ＲＴＰ及びＲＴＣＰプロトコルはより高位又は低位のプロトコル及び規格と関連するかもしれない。より高位の場合、例えば、ＲＴＰ及びＲＴＣＰプロトコルは、ビデオ会議システム又はビューアンドストア（view-and-store）又はデータを扱う他の技術で活用されるために使用されるかもしれない。より低位又はよりベーシックなレベルでは、ＲＴＰ及びＲＴＣＰデータ伝送に使用されるパケットは、実際には異なるパケット伝送メッセージプロトコルに基づいて伝送されるかもしれない。例としては、伝送制御プロトコル（ＴＣＰ又はインターネットでは、ＴＣＰ／ＩＰ）及びユーザデータグラムプロトコル（ＵＤＰ）である。
【００１８】
ＴＣＰ及びＵＤＰプロトコルは共にパケット伝送に関するものであるが、それらはパケットの基準及びエラーチェッキング、ロストパケットに対する感度及びその他の点に関して実質的に異なる特性を有する。伝送中に二通りの接続が維持され、また全ての関連するパケットが伝送され、受信側で組み立てられるまで、該接続は維持され、多分、失われた又は損傷を受けたパケットを再度得るようにリトライすることもある、そうしたことを保証するために、一般的にＴＣＰはそうしたプロトコルの性質を使用する。ＵＤＰは、一般的には、パケット伝送行為を扱うが、パケットを送り及び受取り、全ての必要なパケットが送られ及び受け取られることを保証するまでの運用である。テレビ会議画像のストリーミングのような、いくつかのアプリケーションでは、中間で脱落したパケットに対してそれほど神経質ではない。しかし、仮にパケットが脱落したとしても、ストリーミングが可能な限りとぎれることなく続くことが重要である。
【００１９】
より高位及びより低位のプロトコルの幅広い範囲を使用しリアルタイム伝送が可能な技術が開発され、その構成が、異なるプロトコルが異なる方向で十分利点を得ることが出来るようにすることが望ましい。通信に利用できる資源及び演算に利用できる資源及び状況に敏感な切替え及び決定することが、最適化されるように処理を構成することが、高いパフォーマンス又は高い要求システムにおいて特に有効である。
【発明の開示】
【００２０】
[要約]
本発明の観点は、明確で同時に運転される伝送データ経路と制御データ経路を有するデータ処理装置を用いて、ビデオ及び類似した連続的なストリームデータ処理を提供するものであり、そこでは、二つのデータ経路が、スループット力及び処理力がそれぞれに分離して構成された別個に協働するリソースを用いて、データスループットに集中した機能とデータ処理に集中した機能を別個に取り扱う。
【００２１】
特に、リアルタイムプロトコル（ＲＴＰ）に関連するリソースの集中した処理の一部を分割することで、メディアサーバにより行なわれる処理を容易化し、高速化し、割り当てられた一部の処理に関しては最適化された処理装置及びスイッチング装置によって取り扱う、方法及び装置を提供することである。速度に基づいて分割された機能は、データパイプラインの特性を持った装置に割り当てられる。計算型負荷は、ＲＴＰセッションを制御し、データ通信パイプライン内のストリーミングデータの移動に余り関わることのない計算側を取り扱う、一つ以上の中央処理装置に割り当てられる。
【００２２】
ある実施例は、ＲＴＰパケットストリーミングに関連した、出て行くデータブロックを定義するために提供された情報を、少なくとも部分的に作成するハードウエアインターフェイス素子を用いることに関する方法である。中央処理装置により、全体的に、又は部分的に生成することが出来る形で該指示ファイルが設けられ、また、該指示ファイルは、パケットエグレス（パケットが出てゆくこと）に関連して指示ファイルにアクセスする、アクセラレータ素子に連結される。指示ファイルは、パケットエグレス（パケットが出てゆくこと）に関連してハードウエアアクセラレータを案内する。処理装置は各パケットを分析する必要は無く、同時に発生する、異なる複数のストリーミング接続を潜在的に扱っている。その代わり、処理装置は、各接続のために、進行中である指示ファイルをセットアップし、アクセラレータは、パケットが送出されるにつれて該情報を適用する。
【００２３】
アクセラレータは、指示ファイルの内容に基づいた、必要なブロック及びヘッダ情報を提供しつつ、実質的な管理を受けることなく、高いデータ伝送速度で機能するハードウエアインターフェイス素子である。これにより、制御処理装置は、計算型に集中した機能に向けたものにその注意を向けることが出来る。ここで記述する好ましい実施例では、アクセラレータは、ハードウエア素子ではあるが、該アクセラレータ内の処理装置は除外されてはいない。
【００２４】
１実施例によると、連想メモリ（ＣＡＭ）ファイルが保持され、ハードウエアアクセラレータが、あるアドレスを持った多数の現在維持されているパケットキューと、該連想メモリ（ＣＡＭ）ファイルにより関連付けられている。ＣＡＭファイルは、ヘッダ情報、特に多数レベルのオフセットヘッダを含んでいるデータパケットと関連して、該情報を決定するために使用することが出来る。ＳＥＴＵＰ要求が受け取られ、新たなエンドポイントに向けた新しいストリーミング接続が開始される際には、ＣＡＭファイルには、適合する入力が無く、ハードウエアアクセラレータは、処理装置に信号を送り、入力を設立する。ハードウエアアクセラレータには、関連するヘッダ値が提供される、即ち、ＲＥＣＯＲＤ又はＳＥＮＤメッセージを予想して、連想メモリ（ＣＡＭ）内に項目（入り口）を生成する。新しいエンドポイントに関連したヘッダ値は、制御処理装置には既知のものであるが、該処理装置は連想メモリ（ＣＡＭ）内に新しいパケットキューをセットアップすることで、新しいエンドポイントへのルートを設立することだけが必要となる。これで、ハードウエアアクセラレータは、入ってくるパケットに関するパケットキューの項目（入り口）を見つけ、必要な値を差し替え、該パケットをその目的地に向けて通過させる自働機械として動作することが可能となる。
【００２５】
設立された待ち行列（キュー）の項目（entry）を持ったＲＴＳＰＲＥＣＯＲＤ又はＳＥＮＤメッセージが受け取られると、外に出されるヘッダ値を決定する責任は、トラフィックマネージャ及び中央処理装置とのデータ通信において、ハードウエアアクセラレータにある。接続は、高いデータ転送率と共に、運転中、完了するまで、又は中央処理装置が必要な新しい制御や動作、例えば、プログラムの何らかの機能に従ってストリームのエンドポイントを決定するようなこと、を開始するまで、維持することが出来る。機能は、多くの又は全ての機能を含んでおり、さもなければ、制御装置は各通過パケットをどのように取り扱うかをプログラムのソフトウエアルーチンを介して決定する必要がある。こうした機能は、ソースと目的地との間のパケットのルーティイング、中間処理ステップを挿入すること、同時に二つ以上の目的地にパケットをルーティイングすること、例えば、再生中の記録などを含む。
【００２６】
本発明では、指示ファイルを使用しており、該指示ファイルには、ＲＴＰヘッダに加えて設定され、パケットエグレス、即ち、出力に関連して使う、ジェネラルヘッダ及びヘッダブロックに関する情報が含まれており、パケット出力の管理を促進して、処理装置から向けられる反復的な進行中の注意を最小にする。   
【００２７】
ストリーミングデータ転送速度と、スループット要求は厳格である。処理装置を使用して歩調を合わせるためには、計算型負荷と、出て行くデータブロック内で情報を作成し、挿入する必要性の両方を実行するに必要な、極めて高速で、計算能力のある中央処理装置が必要であった。発明的側面は、中央処理装置に関して、計算型負荷を最小限にする指示ファイルを用いることである。指示ファイルが、ハードウエアアクセラレータとインターフェイスで連結されている限り、この計算型負荷は、実質的に、制御装置を介して指示ファイルをセットアップすることに限定され、制御装置の管理を受けることなく、データブロックを連続して伝送させる形で、ストリームが可能となる。
【００２８】
また、本発明は、制御パケット及びコンテンツパケットを、効果的な方法で処理することが出来る最適な解決法を提供している。ＲＴＳＰ／ＲＴＰの解決方法は、全てをハードウエアだけで、又は全てをソフトウエアだけで実行すべきではなく、大部分の処理をソフトウエアによって制御し、その処理によって、後で使用することが出来る登録値等を生成し、好ましくは、ハードウエアによって、ソフトウエアが生成したメディアオブジェクトやサポートファイルを使って、データ転送を促進させるというような、混合型の解決法を実行することが一番良い。
【００２９】
ＲＴＳＰやＲＴＣＰは、滅多に現れないので、比較的複雑だが滅多にない処理のために、ＲＴＳＰやＲＴＣＰ（即ち、殆どは、制御処理を管理するために使用するパケット）を、過大な負担をかけないで、中央処理装置で実行することが出来る。一方、ＲＴＰ処理は、メディアストリームの中で、各送出するパケットに注意を向ける処理が必要であり、処理を加速することで得をする。
【００３０】
パケットエグレスストリーミングは、リアルタイムでのサポートを厳格に要求している。即ち、データパケットのリアルタイム転送速度と歩調を合わせた形のサポートを要求している。本発明は、指示ファイルを用いており、該指示ファイルの実行においては、ヒント処理を使用し、必要とするＲＴＰパケット情報を有するハードウエアを用いることであり、また、必要なエグレス情報の生成により直接的につながるものである。指示ファイルの内容を決定する際は、制御処理装置が処理することが出来る。しかしながら、指示ファイルが接続に関してきちんと設定された後は、このヒント処理技術により、サーバや制御装置が、ストリームが進行中のメディアを分析する必要性を取り除くことで、サーバ上でＲＴＰストリーミングが促進される。
【００３１】
本発明の技術で、前記責任の全てを専用のハードウエアに移したわけではない。この技術では、例えば、ハードウエアがヒントデータを分解するのに必要な十分な複雑性を有する必要は無い。
【００３２】
好ましくは、指示ファイルのフォーマットは、将来的に拡張することが出来るように、柔軟に表示される。同時に、指示ファイルフォーマットの柔軟性が、反復的であり、計算的に単純なストリーミング機能をハードウエアにまかせる目的を複雑にするべきではない。
【００３３】
本発明の方法では、この問題を、メディア対象物自体ではなく、必要な情報を、ハードウエアによって使用することができる補完ファイル中に入れることで解決する。特定のＲＴＰパケットタイプ（即ち、ＦＲＳに従って定義されるパケットタイプ）を有するメディアファイルがストリーマにアクセス可能であれば、そして、それがストリーミングの候補であれば、指示ファイルが生成される。このファイルは、バックグラウンドで、中央処理装置上で作動しているソフトウエアによって生成され、即ち、リソースが利用可能なときに扱われる低優先機能として生成される。この指示ファイルは、ＲＴＰストリーミング用に、オブジェクトを如何にパケット化するかをストリーマに教えるという点で、ヒントデータに類似している。しかしながら、本発明の指示ファイルは、パケットのエグレスを如何に実施するかという点で、ヒントデータよりもずっと特殊である。このように、発明的な技術は、中央処理装置が本来のメディア対象物に関する知識が殆ど無い状態で機能し得る。
【００３４】
これらの及び他の目的及び観点は、好適な実施例の以下の議論により明らかとなる。
【００３５】
[図面の簡単な説明]
図面に本発明の好適で、例示的であり限定的ではない実施例を示す。しかし、排他的な権利が要求されている発明の範囲を決定するためには、添付したクレームを参照すべきである。図面は、以下のようなものである。
【００３６】
図１は、本発明による、ソースから目的地へのデータ伝送関係（例えば、サーバからクライアント）を示すブロック図であり、ＲＴＰデータコンテンツ成分は、ＲＴＳＰ及び／又はＲＴＣＰ制御信号を扱う中央処理装置などの制御ポイントの周囲を回って伝送される。
【００３７】
図２は、本発明によるストリーミング制御装置を示すブロック図である。
【００３８】
図３は、ＲＴＰヘッダの成分値を示す図表である。
【００３９】
図４は、例示実施例による指示ファイルを説明するデータ表を示す図である。
【００４０】
図５は、好ましくは、本発明のパケットデータ取り扱い規定を含むように構成された、ホームネットワーク接続娯楽システム「ＨＮＡＳ」の要素を示すブロック図である。
【発明を実施するための最良の形態】
【００４１】
「好ましい実施例の詳細な説明」
ＲＴＰはリソースリザベーションをアドレスしないし、ＲＴＰプロトコルレベルでの接続の維持及びパケットのロストなどの保証など、リアルタイムサービスにおけるサービスの質を保証することはない。データ伝送プロトコル、即ちＲＴＰは、セッション制御（即ち、ソースから目的地までのＲＴＰ伝送）及び全体のプレゼンテーション制御プロトコル（ＲＴＳＰ）などに使用することの出来る制御プロトコル（ＲＴＣＰ）により改良される。
【００４２】
ＲＴＣＰ及びＲＴＳＰ制御プロトコルは、伝送経路を構築し、又は分解する際、例えば一方向（再生）又は他の方向（記録）への伝送を開始するとき、一時停止などの時に伝達される信号パケットを含む。コンテンツデータパケットは、なんらかの同期基準を持ったリアルタイムで出来る限り連続的な流れである必要がある。コンテンツパケットはＲＴＣＰ及びＲＴＳＴパケットとして同時に伝送されるが、これら３つの各プロトコルのパケットは異なってアドレッシングされた論理接続又はソケットを使用する。
【００４３】
ＲＴＣＰ／ＲＴＳＰ制御及びＲＴＰデータストリーミングプロトコルは共に、大きなマルチキャストネットワークに対して大きさの変更が可能なツールを供給する。ＲＴＰ及びＲＴＣＰは基本的な伝送及びネットワーク層とは独立した形で設計されており、従って多様な互換可能なそうした層を使用することが出来る。該プロトコルは、望むならば、ＲＴＰレベルの受信中継器やミキサの使用をサポートする。
【００４４】
ＲＴＰ制御プロトコル（ＲＴＣＰ）は、サービスの質をモニタすることが出来、進行しているセッションにおいて、参加者についての情報を運ぶことが出来る。参加者の情報は、例えば、明確なメンバーシップ制御及び機構がない、“緩やかに制御された”セッションにとって十分であるが、使用されているアプリケーションが、通常ＲＴＳＰセッション制御プロトコルの領域である、認証やコミュニケーションを要求することがある。
【００４５】
ソースと目的地間を流れるＲＴＰデータ内容パケットは、リアルタイムで、目的地のアドレスに向けて実質的に単純に通過してゆく。パケットがリアルタイムで通過するので、受信装置ではメモリにバッファする必要はほとんどない。いくつかの理由から、通常、送出装置は一時ファイルを生成する必要がない。ＨＴＴＰオブジェクト伝送などの、いくつかの他のプロトコルとは異なり、ＲＴＰはメディア特定ヘッダを有するオブジェクトを分解する。ＲＴＰ受信機は、リトライ信号送出機能を持つよりもむしろパケットロスを回復するように構成されている。ＲＴＰ伝送は、ＴＣＰ／ＩＰの無接続プロトコルを使用することが出来る。通常、ＲＴＰ伝送は、ＲＴＰデータをユーザデータグラムプロトコル（ＵＤＰ）パケット伝送することで行なわれ、通常、各ＵＤＰパケットが一つのＲＴＰパケットを構成する必要はない。
【００４６】
一つのＲＴＰパケットは、該パケットがＲＴＰであることを示す固定ヘッダを有している。それは、パケット順序番号、タイムスタンプ、同期ソース（ＳＳＲＣ）識別子、コントリビューティング（寄与）ソース（ＣＳＲＣ）識別子の潜在的な空席リスト及びペイロードデータである。ペイロードデータは、オーディオサンプル又は圧縮されたビデオデータなどの、データの値に与えられた数を含む。
【００４７】
ＲＴＰストリーミングシステムは、別個の、リアルタイムデータコンテンツパケット（ＲＴＰ）、制御パケット（ＲＴＣＰ）及び／又はセッション制御パケット（ＲＴＳＰ）を使用している。管理パケット（ＲＴＣＰ、ＲＴＳＰ）は、１以上の接続に関して、ＲＴＰコンテンツパケットを運ぶことが出来る接続に関連している。ＲＴＣＰ、ＲＴＳＰ接続は、異なる接続「ソケット」を有しているが、ＲＴＰが、もっと重要なことに、パケットは、周波数と機能の点で相違している。
【００４８】
レシーバ内には、ネットワーク接続娯楽システム、ビデオ会議システム、ネットワーク接続ストレージ装置等の処理装置を設けることが出来、また、ＲＴＰパケットと、ＲＴＣＰ又はＲＴＳＰ制御パケット間で適宜識別するように、処理装置をプログラムすることも出来る。データパケットをその目的地に向けて通過させ、処理装置によって、制御パケットを使用して、別のプログラム機能を実行し、情報を転送する。歩調を合わせるにあたって、このようなシステムには、ＲＴＰコンテンツパケットをリアルタイムで取り扱うことが必要であり、パケットエグレス時に挿されたフィールドを含めて、パケットの詳細を処理装置が管理する場合には、該処理装置は、高いデータ処理速度で作動しなければならない。
【００４９】
ストリーミング状況における制御パケットは、１以上のデータの方向が無関係なフォーマットにおいて、複数のエンドポイントを含める形で、各種の接続に対応することが可能である。制御処理装置は、計算上の複雑性と、潜在的に含まれる制御処理を扱うために必要となるプログラミングを必要とする。実質的に複雑な計算が可能な所定の処理装置（例えば、複雑なプログラムを有している）を、単にＲＴＰコンテンツパケットを通過させるためにも使用すると、高いデータ処理速度と、複雑な計算容量の両方が必要となる。しかしながら、該処理装置は、操作上の容量の殆どを、簡単に区別がつく数個の接続上で、ＲＴＰパケットを次から次に転送することで消費してしまうと、頻度の低い、複雑な制御計算を扱う計算容量をむだにしてしまう。
【００５０】
本発明は、パケットを先に転送するために、即ち、パケットエグレスのために、制御処理装置がもたらした計算結果を、複雑ではないが、おそらく、より早いハードウエア装置に転送することが出来る方法を提供する。この方法は、本発明による指示ファイル技術を使うことで達成される。
【００５１】
図１は、サーバ（即ち、ストリーミングデータのソース）及びクライアント（目的地）間に配置された制御ポイントを有する簡単なネットワーク環境を示す。各相互接続はＲＴＰストリーミングをサポートする多様なパケットタイプでラベルが貼られている。主題となる発明は制御ポイントを含む構成に広汎に適用することが出来、メッセージヘッダのフィールドを、既に述べたハードウエアアクセラレータを用いてリプレースする技術を用いることで、少なくとも部分的に制御ポイントでの処理の必要性を回避する。
【００５２】
図２は、制御ポイントがネットワーク上でパケットソース（サーバと表示）に接続された中央処理装置で表された、例示的な状況を示す。この構成においては、中央処理装置は、従来通り、パケットを一つ以上の目的地、即ちトラフィックマネージャ／アービタへ、パケットソースからのパケットのストリーム中で確認されたパケットを、本実施例においてディスクメモリ及びその制御装置として表示された、ネットワークに接続された格納素子のような、一つ以上のアドレス可能な目的地、又は読み出し装置などに向けて方向付ける形で通過させなければならない。
【００５３】
本発明によると、パケットデータは、部分的に、ネットワークアクセラレータの形のインターフェイス装置により取り扱われる。パケットの取り扱い、更にはダウンストリーム処理を制御するために、ＲＴＰパケットから構成されるデータブロック内に値を挿入するように設定された、何らかの計算的な複雑性が有る場合には、ネットワークアクセラレータは、最小限高いスループットの装置として実現される。この目的のために、指示ファイルが作成される。この指示ファイルは、識別コード及びパケットカウント数を有するジェネラルヘッダ部、ヘッダブロックの大きさ、ポインタ、及び／又は処理すべきＲＴＰヘッダのデータ中で位置を識別する長さ値から構成されている。
【００５４】
この例における特定のソース及び目的地の存在は代表的な例である。本発明は、多かれ少なかれ基部又は末端となることが出来、また図に示すようにデータ通信で接続された、多様な潜在的なソース及び潜在的な目的地を有する状況に適用することが出来、その潜在的なソース及び潜在的な目的地は、そうした二つの存在間で、一方向、又は逆方向又は両方向に通過するパケットのソース又は目的地として、与えられた時間、機能することが出来る。この特別な例では、コンテンツ信号が再生装置で示されそして同時に記録される状況でパケットの通過が行なわれる。他の実施例では、データの流れは、データが記録されるが再生されない、又は再生されるが記録されない形で、セットアップされる。他の特定のソース及び目的地素子を用いることが出来る。同じ流入パケットは、一つのソースから二つ以上の目的地へ伝送することが出来る。また、二つ以上のソースからの内容が、例えば、ピクチャー・イン・ピクチャー図として調整された格納装置又は再生装置を指定したり、例えばテレビ会議時に、同時サイド・バイ・サイドディスプレイを指定したりすることが可能である。これらの及び他の同様な適用が本発明に基づいて簡単に行なうことが出来る。
【００５５】
データの流れは三つの主なタイプに分類される。即ち、全体の表示制御のためのＲＴＳＰパケット、個々のセッションを制御するＲＴＣＰパケットそしてデータ内容伝送のためのＲＴＰパケットである。
【００５６】
ＲＴＳＰは一つ以上の並行的表示又はデータ転送を制御するために使用されるアプリケーション層プロトコルである。単一のＲＴＳＰ接続はいくつかのＲＴＰオブジェクトの転送を、同時に及び／又は連続的に制御することが出来る。ビデオ会議装置においては、例えば多数の場所がある場合、双方向伝送が各場所の組間で発生する。ＲＴＳＰの文法は、ＨＴＴＰ／１．１のそれに似ているが、メディア伝送に特有の取り決めがある。セッションを規定する主要なＲＴＳＰコマンドは以下のようなものである。
・ＳＥＴＵＰ：サーバにストリームのリソースを割り当て、ＲＴＳＰセッションを開始する。
・ＰＬＡＹ及びＲＥＣＯＲＤ：ソースからのＳＥＴＵＰを介して割り当てられたストリーム上で目的地へのデータ伝送を開始する。
・ＰＡＵＳＥ：サーバリソースを解放することなくストリームを一時的に停止する。
・ＴＥＡＲＤＯＷＮ：ストリームに関連したリソースを解放する。ＲＴＳＰセッションはサーバ上で終了する。
【００５７】
制御ポイントがＲＴＳＰ  ＳＥＴＵＰ要求を使用してオブジェクトの伝送を要求した場合、それはサーバ及びクライアントに、オブジェクト識別、ソース及び目的地のＩＰアドレス、プロトコルポート及び使用すべき伝送レベルプロトコル（一般的に、ＲＴＰ及びＴＣＰ又はＵＤＰ）などのオブジェクト伝送の詳細を含む要求を送る。こうしてＲＴＳＰ要求はクライアントとサーバへのセッションを記述する。ある場合には、該要求は、特にオブジェクトのオーディオ又はビデオ成分のような、利用可能なオブジェクトの一部のためのものであり得る。
【００５８】
全ての必要なＳＥＴＵＰ要求が為され、認識されると、制御ポイントは、伝送の方向に応じてＰＬＡＹ又はＲＥＣＯＲＤ要求を出す。該要求は、配達されるべきオブジェクトの一定の範囲、オブジェクトの通常の再生時間及び再生を始める現地時間を指定することが出来る。
【００５９】
再生が完了すると、あたかもＰＡＵＳＥコマンドが出力されたかのように、表示は自動的に休止される。ＰＡＵＳＥコマンドが出力されると、ストリームが停止されるべきタイムスタンプが記録され、サーバ（クライアント）は、引き続いてＰＬＡＹ（ＲＥＣＯＲＤ）要求が出力されるまでデータの配達を止める。
【００６０】
ＴＥＡＲＤＯＷＮ要求が出力されると、特定のストリームに関するデータの配達が停止され、全ての関連するセッションリソースは解放される。
【００６１】
ＲＴＳＰコマンドは、ＲＴＰ／ＵＤＰ又はＲＴＰ／ＴＣＰが伝送に使用すべき帯域外伝送（転送）セッションを規定することが出来る。“帯域外”伝送とは、二つ以上の異なる伝送又は接続経路を意味する。この場合のＲＴＳＰトラフィックは一つ以上の接続であり、また、ＲＴＰデータの実際の転送を実行するために、異なる接続がＲＴＳＰにより規定される。
【００６２】
ＲＴＰパケットはＴＣＰ上を搬送することが出来る。これは、ＵＤＰ伝送は、維持された接続を要求せず、喪失パケットに鈍感であり及び／又は、ＴＣＰのように喪失パケットの検出及び復旧を試みないことから、一般的に言って非効率的である。ＵＤＰ伝送プロトコルは、オーディオ又はビデオデータサンプル値などのパケットのリアルタイム伝送に適している。そうした値は、それぞれはそれほど重要ではないが、大容量での伝送が必要となる。ＴＣＰはＵＤＰとは、接続が確立している点で異なり、例えば、再伝送を試みてパケット損失を回復することを試みるなど、該プロトコルは信頼性を重要視している。これらの点は、ＲＴＰを必要とするＵＤＰよりもより矛盾しないものである。この開示は、一般的にＵＤＰがＲＴＰ伝送に使用されると想定している。しかし、本開示は好ましいＵＤＰ伝送に限らず、そのかわりＴＣＰの他のプロトコルもまた含む。
【００６３】
サーバがＲＴＰを用いて配達すべきオブジェクトの要求を受けると、オブジェクトは一般的にその本体のフォーマットからパケット化が可能なフォーマットに変換される。多数の“コメント要求（ＲＦＣ）”のメッセージスレッドが、前述のパケット化可能なデータに関連した問題を解決するために産業界において展開され、例えば,多様なメディアタイプに関する関連ＲＦＣを含む、多数の“コメント要求（ＲＦＣ）”のメッセージスレッドが、インターネットエンジニアリングタスクフォース（Internet Engineering Task Force）(ietf.org)によってオンラインアクセス可能に維持されている。
【００６４】
各メディアオブジェクトタイプは、通常、関連するＲＦＣで示された標準仕様に基づいて、各オブジェクトタイプでヘッダーフォーマットを変える形で、幾分か異なった形でパケット化される。該相違は、異なる用途を持ったデータを取り扱う際に遭遇する問題と異なるオブジェクトに起因するものである。
【００６５】
図３は、共通のＲＴＰヘッダーのフォーマットを示すもので、例えば、ＲＦＣ３５５０／３５５１で定められたものである。ヘッダー部分の略語は、以下のようなものである。
【００６６】
“Ｖ”はバーションナンバーを示すもので、現在のバージョンは２である。ＲＴＰフォーマットであるパケットを独自に示す固有のものはヘッダー内には無いが、このヘッダー位置のバージョンナンバー“２”の表示は一つのインジケータである。
【００６７】
“Ｐ”は、ペイロードの最後に無視すべき何らかの付け足し（パディング）が有るか否かを示す値で、有る場合には、付け足しの長さ。付け足し値の最後のバイトは付け足しバイトの全長を示す。
【００６８】
“Ｘ”は、拡張ヘッダーが存在するか否かを示す値。
【００６９】
“ＣＣ”は、このヘッダー内で確認されたコントリビューティングソース（貢献ソース）の総数。
【００７０】
“Ｍ”は、マーカビットである。このビットの実行は、ペイロードタイプに独特のものである。
【００７１】
“ＰＴ”はペイロードタイプを示す。即ち、伝達されるべきオブジェクトのタイプを示す。とりわけ、ペイロードタイプ識別子は、受信器にどのようにしてＲＴＰストリームを終わらせるかを決定させることが出来る。
【００７２】
“シーケンスナンバ”は、伝送されるＲＴＰパケットの数のカウント。これは、伝送されたバイトの数を示すためにシーケンスナンバを使用する、ＴＣＰとは異なるものである。ＲＴＰシーケンスナンバは、伝送されたＲＴＰパケットの数、即ち、パケットインデックスである。
【００７３】
“タイムスタンプ”は、ペイロードタイプに依存するフィールド値である。通常、タイムスタンプは、送られたパケットの時間的な見出しであり、ある時には、受信機に、パケットの内容を記録又は再生する際のタイミング状態を適合させる参考となる。
【００７４】
“ＳＳＲＣ  ＩＤ”は、伝送されるべきデータのソースを示す。
【００７５】
“ＣＲＳＣ  ＩＤ”は、ミキサーやトランスレータなどの、伝送されるべきデータを処理した、何らかのコントリビューティング（貢献）ソース又はソースを示す。複数の貢献ソースが存在し得るし、また、ＳＳＲＣ  ＩＤで示されたオリジナルソース以外には無い場合もある。上記したように、ヘッダーのＣＣの値は貢献ソースの総数を示している。該数は、貢献ソースの識別子の確認された数、それ自体を処理し、該ヘッダに続く内容に先駆けたインデックスとすることができる。
【００７６】
もし、Ｘビットがセットされていると、ＲＴＰヘッダーの後に拡張ヘッダーが有る。拡張ヘッダーの仕様及び性質は、ペイロードタイプに従属する。ペイロード独特のサブヘッダーは通常、パケット損失が改善されるような方法で、規定され、ある程度の周期的な発生には耐えることが出来る。ＭＰＥＧ２などの、あるフォーマットにおいては、ビデオ及びオーディオエンコード情報を有する多数の複雑なサブヘッダーが、メインのＲＴＰヘッダーの後に続く。
【００７７】
ペイロードが図３に示したパケット最後のサブヘッダーの後に続く。本体のメディアオブジェクトに対するペイロードの関係も、対応するペイロードタイプを記述する基準により決定されている。本来のオブジェクトと一連のＲＴＰパケットのペイロードとの間にはしばしば、１対１の対応が無い。これに影響する多様な要素があるが、例えば、ＲＴＰパケットペイロードシーケンスと本来のオブジェクトに含まれるバイトのシーケンスの間の相違に関する状況のいくつかの例がある。
・与えられたフレームについて、オーディオ及びビデオ情報を同期させる必要
・ＲＴＰペイロード内のデータブロックのインターリービング
・重要なデータ素子に関するリピートパケット
・オーディオ／ビデオの多重分離
・又は１．１．３ＲＴＣＰ
【００７８】
与えられたＲＴＰセッションがアクティブな間、周期的に、該セッションに関する制御情報が、ＲＴＣＰを用いた別の接続で交換される（ＵＤＰの場合、ＲＴＰセッションは偶数番号の目的地ポートを使用するが、ＲＴＣＰ情報は、次のより高い奇数番号の目的地ポート上で伝送される）。ＲＴＣＰはデータ分配の品質に関するフィードバックを供給することを含む多様な機能を実行し、それはネットワークの問題がローカルなものか、グローバルなものかを決定するうえで、サーバにとって有益であり、特にＩＰマルチキャスト伝送の場合に有効である。ＲＴＣＰは、ＲＴＰソースに関する、永続的な伝送レベル識別子（a persistent transport-level identifier）である、ＣＮＡＭＥを運ぶ機能も有する。コンフリクト又はプログラムの再スタートはＳＳＲＣ  ＩＤＳの移動が生じるので、受信器は各参加者の軌跡を保持するためにＣＮＡＭＥを要求する。ＣＮＡＭＥは、多様なＲＴＰセッションから多数の関連するストリームを同期させるために使用することも出来る（例えば、オーディオとビデオを同期させる）。
【００７９】
伝送の全ての参加者はＲＴＣＰパケットを送るように要求される。セッションにおける参加者の数が増加すると、それぞれにより送られるパケットの数は、都合良く減少させられる。各参加者にそのＲＴＣＰパケットを他の全ての参加者へ送るようにすることで、各参加者は参加者の数を常に把握することが出来る。この数は、今度は制御パケットが送られる速度を演算するために使用される。ＲＴＣＰはユーザインタフェースで表示される参加者情報のような最小限のセッション制御情報を伝送するために使用することが出来る。
【００８０】
これらのタスクを達成するために、ＲＴＣＰパケットは以下のカテゴリー又はフォーマットのうちのひとつに分類される。
・ＳＲ：送信者レポート、アクティブな送信者である参加者からの伝送及び受信の統計用
・ＲＲ：受信者レポート：アクティブでない送信者である参加者からの受信の統計及び、ＳＲと組み合わせて、３１ソース以上について報告しているアクティブな送信者用
・ＳＤＥＳ：ＣＮＡＭＥを含む、送信元記述事項
・ＢＹＥ：参加の終了を示す
・ＰＰ：アプリケーションの特別な機能
【００８１】
ＲＴＰのように、ＲＴＣＰパケットのぞれぞれのフォームは共通ヘッダーで始まり、可変長のサブヘッダーが続く。多数のパケットは連結されて結合されたパケットとすることが出来、それはより下層のプロトコルの単一パケットで一緒に送ることが出来る。これにより、各種のカウンタやポインタは、ストリーム中で予期したフィールドの位置を識別することが必要となる。
【００８２】
本発明の目的は、ＲＴＰフォーマットにおけるデータストリーミングの取り扱いを最適化することであり、特に、ある種のカウンティング値及びインデックスポインタ値を有する指示ファイルを、ストリーミングパケットに含めることによって、エグレスストリーミングを促進させることである。
【００８３】
ＲＴＰパケットのエグレスストリーミングは、リアルタイムでサポートする必要がある。リアルタイムの取り扱いは、ストリームの出て行く性質のため、バッファの必要性を減らすＲＴＰプロトコルの重要な点である。本発明は、ハードウエアに直接、あるＲＴＰパケット情報を提供することが出来る各種のヒントを用いている。この方法におけるヒントにより、ＲＴＰストリーミングをサーバ上で促進することが出来るが、これは、サーバがストリーム進行中のメディアを分析する必要をなくしていることによる。
【００８４】
「ヒント」とは、ＭＰＥＧ−４等の、圧縮ビデオと一緒に符号化する情報を指すものとしてしばしば使われる言葉であり、この情報は、圧縮すべきデータから別個に送られ、一般的に、関連する圧縮ビデオデータを復元するにあたってアシストしてくれるヒントデータを分解することが出来る専用装置により使用される。
【００８５】
本発明によると、ジェネラルヘッダ及びヘッダブロックとして、補完情報ファイルを設ける。この場合、専用のハードウエアは、ヒントデータを分解して、フォワード及びバックワード関連イメージファイルの特定フォーマットを扱う必要が無い。その代わりに、指示ファイルは、ＲＴＰヘッダやパケット情報を配置するためのインデックスとして使用する一連のカウンティング値及びポイント値となる。
【００８６】
指示ファイルは、ポインタ情報が柔軟に表わされている、即ち、該ポインタ情報は、異なるパケットデータフォーマットを表わすことが出来るため、将来拡張することが出来るという点で、復元ヒントメカニズム等とは相違している。インターフェイシングファイルに柔軟性を持たせると、異なるフォーマットを識別するようにプログラムされている処理装置から、殆どのパラメータが固定されているハードウエアに対するストリーミング相関性の動的部分に問題が発生する。本発明では、この問題を、ハードウエアによって使用することが出来る補完指示ファイルに、（メディアオブジェクトそれ自体は除く）必要な情報を全て蓄積させることにより解決している。これは、指示ファイルは、公知のオフセットや他の期待値でフォーマットされた情報とは対立するインデキシングポインタを含んでいることにもよる。
【００８７】
メディアファイルが特定のＲＴＰパケットタイプ（通常、ＲＦＣ、又は、改良発言に繋がるコメントのスレッドによって記録されている）を有し、ストリーマにアクセス可能であり、或いは、ストリーミングの候補であれば、中央処理装置上で走っている（リソースが利用できるときには、おそらくバックグラウンドで走っている）ソフトウエアによって最初に指示ファイルが生成される。
【００８８】
指示ファイルは、ヒントデータとは、ＲＴＰストリーミングをするためにオブジェクトを如何にパケット化するかをストリーマに伝えるという点では類似していいるものの、如何にしてそうするかに関してはずっと独特であり、中央処理装置は、本来のメディア対象物に関して知識を殆ど持っていないと考えられる。例示的な指示ファイル４５（バイナリファイル）のフォーマットを、図４に示す。
【００８９】
図４に示すように、ジェネラルヘッダは、このファイルの最初にだけ特定されており、ブロックの全てに適用する。ジェネラルヘッダは次のものから構成されている。
・指示ファイルが正しいフォーマットであるとストリーマが立証することが出来る、バージョン／認証フィールド
・完全なファイルを使用した時、転送されるパケットの数を特定する、パケット総数フィールド
・指示ファイル内の各ヘッダブロックに割り当てるバイト数を特定する、指示ファイルヘッダブロックサイズ
【００９０】
ヘッダブロックは、指示ファイル４５により転送用に特定された各パケットに対して特定される。このヘッダブロックは、所定の指示ファイル４５用に固定の長さを有している。
ヘッダブロックは次のものから構成されている。
・ｐａｙｌｏａｄ．ｐｔｒ：メモリ内のオブジェクトの最初から、現在のパケットペイロードのオフセットを含んだフィールド。
・ｂｏｄｙｓｋｉｐ：現在のキューポジションから有効なＲＴＰペイロードの最初までの、スキップすべきバイトの数を示す。
・ｂｏｄｙ．ｌｅｎｇｔｈ：ＲＴＰペイロードの長さを示す。
・ｈｅａｄｅｒ．ｌｅｎｇｔｈ：現在のＲＴＰパケット用に使用するＲＴＰヘッダフィールドのバイト数を示す。
【００９１】
指示ファイルが生成されると、該指示ファイルは、特定のオブジェクトと関連付けられる形で格納される。オブジェクトをストリームする方法がたくさんある場合には、ヒントデータを使って、多数の指示ファイルを、１つのオブジェクトに関連付けることが出来る（異なるパケットタイプ、或いは同一のパケットタイプ用の異なるネットワークアトリビュート）。
【００９２】
この事実を拡張すると、Ｉフレームに対する点だけに、或いはＩフレームのＮ毎に対する点だけに指示ファイルを生成することにより、ストリーマはトリックプレイ機能を簡単に実行することが出来る。ここで、Ｎは指示ファイル４５によって特定されたファストフォワーディングスピードに関係している。
【００９３】
対応するＲＴＰセッションがまだ準備されておらず、設定されていない時は、コアプロセッサ上で走っているＲＴＳＰが、エンドポイントから受け取ったＳＥＴＵＰコマンドを提供するまで、装置は静止したままである。一旦ＲＴＳＰがＳＥＴＵＰメッセージを受け取ったら、該ＳＥＴＵＰメッセージから１セットのルックアップパラメータ（ソース及び目的地ＩＰアドレス及びポート、及び転送プロトコル）を決定し、ハードウエアアクセラレータに関連した、連想メモリＣＡＭ内に、このセッション用に接続テーブル項目を割り当てる。直ちに有効なビットが、ＲＴＰセッション用にＣＡＭ内に設定される。そこで、ＲＴＳＰは、関連する制御ポイントから、後続するＰＬＡＹ要求を待つ。ＰＬＡＹメッセージは、ストリームのプレイ（時間）帯を持っていることもある。
【００９４】
この時点で、セッションは設立されたと考えられ、ネットワークアクセラレータ及びトラフィックマネージャは、データを転送する準備が整う。トラフィックマネージャは、各ＲＴＰセッション用に利用できる２つの関連するキュー、本来のメディア対象物からデータを転送する際に使用するオブジェクトキュー、及び指示ファイルから読み出したＲＴＰヘッダを転送する際に使用するヘッダキューを有している。転送すべき各ＲＴＰパケットについて、トラフィックマネージャは、指示ファイルのフィールドを使用してＲＴＰヘッダ及びペイロードを抽出し、それらのパケットをスケジューリングする。その後、トラフィックマネージャは、ネットワークアクセラレータに該パケットを転送する。
【００９５】
ネットワークアクセラレータの操作は、次のステップから構成される。
・出て行くパケットのＲＴＰヘッダのシーケンスナンバーフィールドに、中央処理装置が決定し、関連する転送のために、ＣＡＭ接続テーブル項目内でフィールドとして格納したオフセットを加える。これは、ＲＦＣ３５５０で規定するように、ランダムＩＳＳを提供するために都合が良い。
・同様にして出て行くタイムスタンプを調整する。これは、ＲＦＣ３５５０で特定した、ランダムＩＴＳを提供するために都合が良い。
・層３ヘッダ及び層４ヘッダを出て行くパケットに対して構築し、適用する（例えば、プリペンド）
・出て行くパケットをＭＡＣ／ＰＨＴＹブロックに送る
【００９６】
この方法により、ネットワークアクセラレータが、本来のメディア対象物の知識を持たなくとも、メディアオブジェクトをストリームさせることが出来る。好ましくは、指示ファイルは中央処理装置上で走っているソフトウエアによって生成されているので、現れたパケットタイプを簡単にソフトウエアによって適応させることが出来る。この方法により、中央処理装置からよりハードウエア寄りのネットワークアクセラレータに、ストリーミング装置の反復データパイプライン機能を手渡すことが可能となる。この計算的には複雑ではない、反復データパイプライン機能でも、高度に時間が優先される。本発明は、ネットワークアクセラレータにおけるこれらの機能を最適な形で実行する。また、本発明は、計算的に複雑なため得をして、また、ストリーミング接続のデータパイプライン機能の時間要求とは幾分両立が難しい、低頻度である、制御寄りの要求のために、中央処理装置に容量及び処理時間を確保している。
【００９７】
指示ファイルを使うと、ネットワークアクセラレータが、データパケットを扱うためにはメディア対象物のフォーマットの知識を殆ど、或いは全然持つ必要がないという要求と合わせると、トラックの中ではなく、むしろファイルの中に指示情報を含めると好ましい。このようにして、サーバは、特定の出て行くパケット或いはバケットのブロックに関する指示情報を如何にして引き出すか知る必要は無い。
【００９８】
一旦指示ファイル４５が生成されると、今セットアップしたジェネラルヘッダとブロックヘッダのポインタとカウント値を使って、オブジェクトを何回でもストリーミングするための要求に応じられるようになる。ストリーマには、上記したポインタ及びカウントを持つファイルを使って、便利である指示情報にアクセスし、仕分ける方法が必要である。更に、エグレスストリーミング指示ファイル４５は、エンドポイントにまで送信する必要が無いという利点がある。また、該ファイル４５は、１つのパケット又は複数のパケットのブロックをエンドポイントまで送信するストリーミング装置から、エグレスに関連して使用する情報を必要としない。
【００９９】
本発明の観点は、ハードウエアのみの又はソフトウエアのみによる解決法を提供する代りに、ハイブリッドなハードウエア及びソフトウエアによる解決法を提供することで、総合的なＲＴＳＰ／ＲＴＰの解決法の改良である。全てをハードウエアで解決する手法は、全ての制御状況のシナリオを提供するために、極めて複雑化する。反対に、そうした複雑さを扱うことの出来る処理装置及びコーディングを備えたソフトウエアのみの解決法も、十分に開発されてはいない。与えられたストリームが処理中となった後の殆どの処理に関しては、与えられたストリームに続くパケットを、それまでのパケットと同じ方法で取り扱いを継続する処理の多くは、反復が多く、計算的なパワーが要求されない演算を用いて取り扱われる。
【０１００】
本発明は、潜在的に複雑で、有能なソフトウエアを走らせることが出来る制御装置が、制御処理を大部分セットアップするという点で一部ハイブリッド的な解決法であるが、接続が、該制御装置がセットアップしたストリーミング動作を実行するためにアクティブである間は、ネットワークアクセラレータ、また、必ずではないが好ましくは、ハードウエア装置が使用し続けることが出来る要素、値、及びポインタを簡単にセットアップする。    
【０１０１】
図５に、好適な実施例を示す。本発明は、ディスクアレイ制御装置を有するデータ処理システム内に導入されている。この制御装置は格納管理を行なうことが出来、消費者の電子デジタルメディア利用又は通信及びテレビ会議などの似たような特徴を持った利用に対して貢献することができる。娯楽の利用においては、本制御装置はホームネットワークと、デジタルメディア（オーディオ、ビデオ、イメージ）を格納するハードディスク装置（ＨＤＤｓ）によって一般的に例示される、データ貯蔵装置のアレイ間のインターフェースを提供する。
【０１０２】
装置は好ましくは、ホームネットワーク又は他のローカルエリアネットワーク（ＬＡＮ）に対するインターフェースとして、統合型１０／１００／１０００イーサネットＭＡＣポートを有している。ＵＳＢ周辺装置アタッチメントポートは、メディア入力装置（フラッシュカードなど）に又は外部ワイヤレスＬＡＮアダプタを追加することでホームネットワークに接続することが出来る。
【０１０３】
好ましいデータ取り扱いシステムは、より上層のプロトコルアクセラレーションエンジン（ＩＰ／ＴＣＰ、ＩＰ／ＵＤＰ用）及びセッションアゥエアトラフィクマネージャを介して、メディアアーカイブにハイパフォーマンスなシェアアクセスを行なう多数の層及び機能を有する。セッションアゥエアトラフィックマネージャは、中央処理装置として、ここで述べたＲＴＰストリーミングを管理することに加えて、実際のメディアセッションに基づいて、ネットワーク帯域、メモリ帯域及びディスクアレイ帯域などの共有資源を割り当てることが出来る。例えば、ビデオセッションは、イメージブラウジングセッションよりもより多くの資源が割り当てられる。更に、帯域は、時間に敏感なメディアセッションに関してはその帯域が保証される形で割り当てられ、また、メディアアーカイブの大量アップロードやマルチＰＣバックアップアプリケーションなどの、時間に敏感でないアプリケーションには、ベストエフォートとしての帯域が割り当てられる。
【０１０４】
データ取り扱いシステムは、関連するハードディスクの重複アレイ（ＲＡＩＤ）に対する高いパフォーマンスストリーミングを含む。ストリーミング−ＲＡＩＤブロックは、エラー防御に関する冗長性を持ち、単一ＨＤＤの欠点に対してアーカイブに格納されたメディアを保護する。ＨＤＤは、シリアルＡＴＡディスクとすることが出来る。例えば、８個のＳＡＴＡディスクを有し、６４までの同時双方向ストリーミングをトラフィックマネージャ／アービタブロックを介して取り扱うことの出来るシステムなどである。
【０１０５】
データ取り扱いシステムは本発明の多様で潜在的な態様の例であり、図５に示す全体のデータ取り扱いシステムは概要だけを述べたものである。装置内には、受信パスと伝送パスの、二つの別のデータパスが有ある。“受信パス”は、他の外部装置からシステムへ方向付けられたトラフィックフローと考えられ、“伝送”パスは、ソースから有る地点へのパス、及び与えられたストリームの文脈内での、それぞれの目的地へ向けたパスであり、データフローの反対の方向である。
【０１０６】
上層処理装置（ＵＬＰ）はギガビットイーサネット制御装置（ＧＥＣ）又は周辺トラフィック制御装置（ＰＴＣ）への又はからのデータ通信と接続されており、ＰＴＣはパケット化されていないデータ伝送のためにトラフィックマネージャ／アービタ（ＴＭＡ）に対し直接のインターフェースとなっている。パケット伝送は、ここで述べるように取り扱われる。
【０１０７】
受信データパスでは、通常、ＧＥＣ又はＰＴＣブロックが物理インターフェース、例えばより大きなネットワークへ／からのイーサネットパケットを受け取る。ＧＥＣは、パケットの完全性やマルチキャストアドレスフィルタリング等、多様なイーサネットプロトコルに関連するチェックを行なう。パケットは、更なる処理のためにＵＬＰのブロックへ通過させられる。
【０１０８】
ＵＬＰはアドレスを形成するために抽出された第２，３及び４層のヘッダーフィールドを解析する。接続探索は該アドレスに基づいて行なわれる。探索結果を用いて、ＵＬＰは受け取ったパケットをどこに送るか否かを決定する。既に確立された接続からの到着パケットは、ＴＭＡによって使用されるトラフィック待ち行列（キュー）目的の予め定義された待ち行列（キュー）ＩＤ（ＱＩＤ）が付される。未知の接続からのパケットはアプリケーション処理装置（ＡＡＰ）による更なる調査が要求される。パケットは特別なＱＩＤが付され、ＡＡＰに運ばれる。ＡＡＰ通過後の到着パケットの最終目的地は、パケットがメディアコンテンツを持っているときには、格納用ハードディスクとなり、パケットが制御メッセージを持っていた時、またＡＡＰにより認識出来ないパケットの時は、更なる調査のためにＡＡＰとなる。そこで、新しい待ち行列（キュー）ＩＤを設定することとなる。上記したどのような場合でも、パケットはＴＭＡブロックに送られる。
【０１０９】
ＴＭＡは到着したトラフィックを共用メモリに格納する。メディアオブジェクトの伝送の場合には、入ってくるオブジェクトデータはメモリに格納され、ディスク格納のためにＲＡＩＤデコーダ及びエンコーダ（ＲＤＥ）ブロックに伝送される。ＴＭＡは適当な制御情報をＲＤＥに送って格納処理を管理する。ＡＡＰ調査のために充てられた制御トラフィックも共用メモリに格納され、ＡＡＰはメモリ内のパケットを読むためにアクセスされる。ＡＡＰは、このメカニズムを順序が狂った形で受け取ったパケットを再配列する為にも使用する。共用メモリ及びディスクの一部に、ＡＡＰ用のプログラム指示及びデータが含まれている。ＴＭＡは、ディスクからメモリ及びメモリからディスクへの制御情報を伝送することでメモリとディスクへのアクセスを管理する。ＴＭＡはまた、ＡＡＰに、現在のパケットストリームからデータを引き出させたり、またパケットストリームへデータを挿入させたりすることも出来る。
【０１１０】
伝送データパスでは、ＴＭＡがディスクからのオブジェクト検索要求を管理するが、当該要求は、必要に応じて処理のためアプリケーション処理装置を経由して、又はそのままネットワークインターフェースに送られる。メディアプレイバック要求をアプリケーション処理装置から受け取ると、ＴＭＡはＭＤＣとＲＤＥブロックを介してディスクから伝送されたデータを受取り、メモリに格納する。そしてＴＭＡは該データを、要求された帯域及びメディアタイプに基いてＵＬＰブロックに登録する。ＵＬＰでは、外に出される各パケットについて、イーサネット及びＬ３／Ｌ４ヘッダーで該データをカプセル化する。パケットはそこで、指定された行く先ポートについてのＧＥＣ又はＰＴＣブロックに送られる。
【０１１１】
受信データパス上の入ってくるパケットについては、ネットワークアクセラレータの接続探索機能部が、アドレス生成、ＣＡＭテーブル探索及び接続テーブル探索機能ブロックを含むことが出来る。ＣＡＭの探索アドレスは、入ってくるパケットのヘッダから抽出した情報の結果として一部が形成される。抽出されるべきヘッダーフィールドの詳細は使用されるトラフィックプロトコルに依存する。形成されるべきアドレスは唯一の接続を表すものでなければならない。例えば、ＩＰ  Ｖ４及びＴＣＰ／ＵＤＰプロトコルで運ばれる最もポピュラーなインターネットトラフィックでは、ソースＩＰアドレス、目的地のＩＰアドレス、ＴＣＰ／ＵＤＰソースポート番号、ＴＣＰ／ＵＤＰ目的地ポート番号及びプロトコルタイプ（パケットのヘッダからの所謂“５組”）が唯一の接続を規定する。仮にパケットが異なるトラフィックプロトコル（ＩＰ  Ｖ６のような）の場合、他のフィールドが接続を決定するために使用されてもよい。多数のプロトコルが使用されるところでは、フラグ、識別コードなどの適当な制御を参照することが出来、それによりシステムを“プロトコルを知っている”階層とする。例えば、処理は３つのステージに分割することが出来、各ステージはサポートされたプロトコルのレベルに対応している。第１のステージは、ヘッダの構文解析処理中に抽出されたフィールドから、Ｌ３プロトコルのバーション番号をチェックし、アドレス生成処理内のステップとして到着パケットに関する情報バッファ項目に格納することが出来る。アドレス生成処理の第２及び第３のステージは、複合ハードウエアテーブルが用いられる。各段階のテーブル項目数は、該テーブルが入るステージ及び各ステージでサポートされる異なるプロトコルの数に依存する。各テーブルの項目は、常に連想メモリ項目及び位置ナンバーレジスタを構成する。各位置レジスタは常に一組のオフセットサイズのフィールドを構成する。各ＣＡＭ項目は、対応する位置レジスタについての特定のプロトコル値を格納している。オフセットは、パケットのヘッダの最初から抽出されるべきフィールドまでの、スキップすべきバイト数を規定している。サイズフィールドは、抽出すべきニブルの数を規定している。同じアドレスが、ＣＡＭフィールド及び位置レジスタへのアクセスに使用される。
【０１１２】
本発明では、出て行くパケットエグレスのために、指示ファイルを用いており、該指示ファイルは中央処理装置にアクセス可能なメモリ内に、構成中の何れにおいても設定することが出来る。
【０１１３】
発明は例示的な実施例に関連して開示されているが、独占権が要求されている発明の範囲を決定するには、実施例を議論するよりもむしろ添付されたクレームを参照すべきである。
【図面の簡単な説明】
【０１１４】
【図１】図１は、本発明による、ソースから目的地へのデータ伝送関係（例えば、サーバからクライアント）を示すブロック図であり、ＲＴＰデータコンテンツ成分は、ＲＴＳＰ及び／又はＲＴＣＰ制御信号を扱う中央処理装置などの制御ポイントの周囲を回って伝送される。
【図２】図２は、本発明によるストリーミング制御装置を示すブロック図である。
【図３】図３は、ＲＴＰヘッダの成分値を示す図表である。
【図４】図４は、例示実施例による指示ファイルを説明するデータ表である。
【図５】図５は、好ましくは、本発明のパケットデータ取り扱い規定を含むように構成された、ホームネットワーク接続娯楽システム「ＨＮＡＳ」の要素を示すブロック図である。
【図１】
2009512280.tif 000003
【図２】
2009512280.tif 000004
【図３】
2009512280.tif 000005
【図４】
2009512280.tif 000006
【図５】
2009512280.tif 000007
【国際調査報告】
2009512280.tif 000008
2009512280.tif 000009
2009512280.tif 000010