JP2006211681A - 優先待ち行列を伴うフィルタベースのイーサネット・パケット・ルータを備えた高速イーサネットｍａｃとｐｈｙ装置および単一もしくは多数のトランスポート・ストリーム・インターフェース - Google Patents

Abstract

【課題】高い品質と解像度のＡ／Ｖプログラミング・コンテンツの配信に要求される性能レベルを維持できるイーサネット・プロトコルを中心に構築されるオープン・ネットワークのソリューションを提供する。
【解決手段】セットトップボックスなどのような音声映像コンテンツ配信システムがＬＡＮとインターフェースする。このシステムのパケット処理回路はＬＡＮから特定のポートや待ち行列へ受信されるイーサネット・パケット・データをホスト・プロセッサの介入なしでフィルタ処理し、経路指定する。パケット処理回路は様々なインターネットＩＥＴＦのネットワーク化トランスポート・プロトコルを解釈するためにハードウェアによるフィルタ処理と経路指定用メカニズムのセットを利用し、各々がデコーダへと連結される多様な民生用サブシステムによって識別されるフォーマットでパケット・データを転送する。
【選択図】図４

Description

本発明は概してデジタル・インターフェース設計の分野に関し、さらに特定すると通信用インターフェースの設計に関する。

過去２０年間のうちにパーソナル・コンピュータ（ＰＣ）は職場と家庭の両方で広く使用されている、あらゆる電子デバイスの一部としてテレビ受像機、高忠実ステレオ機器、コンパクトディスク・プレーヤなどに連結されるようになった。近年、エレクトロニクス市場は汎用記憶媒体を使用するデバイスに加えてソリッドステート・メモリを使用する電気製品や個人向け電子デバイスも急増している。いくつかのさらによく知られているデバイスはビデオ・カメラ、写真カメラ、パーソナル・デジタル・アシスタント、携帯型音楽デバイス、家庭用電化製品を含む。家庭用電化製品には、セットトップボックス、高解像度（ＨＤ）テレビジョン・システム、デジタル・レコーダといったモノを含む。そのようなデバイスの急増への対応は、個人向け電子デバイス、パーソナル・コンピュータ、および／またはセットトップボックスの間の接続性やネットワーク化に重点を置いてきた。

Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）のような内部バスに関する仕様に加えて、コンピュータと外部周辺機器を接続するための様々なインターフェース規格もやはり実装されてきており、各々が高速での単純な接続性を与えることを目的にしている。そのような規格の例はファイアワイヤとも称されるＩＥＥＥ １３９４規格とＵｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ（ＵＳＢ）を含む。両方共に高速のシリアル・バス・プロトコルである。ローカルエリア・ネットワーク（ＬＡＮ）と広域ネットワーク（ＷＡＮ）の両方で複数のコンピュータを接続するために最も広く使用されるネットワーク化の規格はイーサネット（登録商標）・プロトコルであった。さらに特定すると、イーサネットはＩＥＥＥ ８０２．３シリーズの規格であり、元来、２つ以上のコンピュータ・ステーションが共通のケーブル・システムを共有するための手段を備えたキャリア検知多重アクセス／衝突検出（ＣＳＭＡ／ＣＤ）に基づいている。ＣＳＭＡ／ＣＤはメガビットの範囲、すなわちＭｂｉｔ／ｓｅｃの範囲の転送速度に達したイーサネット・システムの基礎を形成してきた。最近の交換機ベースおよび／またはルータ・ベースのイーサネット・システムはＧｂｉｔ／ｓｅｃの範囲の転送速度をサポートすることが可能である。概して共有リソースを効率的に利用するイーサネットは通常では再構成と保守管理することが容易であり、コストを低く保ちながら多くの製造業者やシステムに互換性を提供する。

しかしながら、ＨＤテレビジョン、セットトップボックス、パーソナル・ビデオ・レコーダ（ＰＶＲ）といったオーディオ／ビデオ（Ａ／Ｖ）民生用娯楽システムは、規格に基づいたイーサネット・ネットワークを通じて高品質高解像度のプログラミング内容を分配／受信するために最適化されていない。これは通常では広帯域イーサネット接続も同様である。娯楽システムの開発の中で問題を呈した１つの課題はさらに高い品質／解像度のＡ／Ｖプログラミング内容の分配に要求される性能を維持しながらクローズド・ネットワークからオープン・ネットワークへと移行することである。標準のイーサネット制御装置を利用し、限られた帯域幅のローカル・バス上でリアルタイムのストリーミング・データを動かす一方で所望の性能レベルを得ることもやはり、たとえ可能であるとしてもますます困難になってきた。付け加えると、イーサネット・ネットワーク構成要素を特色とする民生用エレクトロニクス製品の高い価格が妥当な費用でシステムを組み立てることを困難にしてきた。

デジタル衛星送信、ケーブル送信、地上の独自仕様の送信システムといったデータ・トランスポート・モデルおよび／または手法を使用するときにリアルタイムおよび非リアルタイムのオーディオ／ビデオ・データの伝送に特有の複雑さの問題はない。デジタル衛星送信、ケーブル送信、その他の独自仕様の送信システムは通常では「クローズド・ネットワーク」である。通常、このコンテキストでの「クローズド・ネットワーク」は一般市民が利用することが不可能な標準的または非標準的な（独自仕様の）ソリューションに関する。独自仕様のソリューションは通常では、所望の性能目標を達成することが可能な一意のソリューションを開発する時間とリソースを個々の製造業者もしくは製造業者のグループに与える。しかし、そのようなソリューションは普通では競合製品と相互作用しないであろう。独自仕様のソリューションの例は通常では、ケーブル・テレビ（ＣＡＴＶ）ネットワークを通じて放送するデジタル映像、公衆交換電話網（ＰＳＴＮ）および／または総合デジタル通信網（ＩＳＤＮ）上で放送するデジタル映像、サテライト・マスター・アンテナ・テレビジョン（ＳＭＡＴＶ）配信システム・ネットワークを通じて放送するデジタル映像を含む。様々な物理的モデルやトランスポート・モデルに対して、例えばＤＶＢ−ＥＴＳＩ（Ｅｕｒｏｐｅａｎ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｔａｎｄａｒｄｓ Ｉｎｓｔｉｔｕｔｅ）のような規格化団体の下で多様なネットワーク規格が規定され、実装されてきた。コンテンツ配信システム全体は、通常ではＣａｂｌｅ Ｖｉｓｉｏｎ、Ｃｏｍｃａｓｔ、Ｄｉｒｅｃｔ ＴＶのような放送ネットワーク・プロバイダによって管理される。通常では広帯域ネットワーク・プロバイダがそのようなシステムに使用されるハードウェア、ソフトウェア、プロトコルを指示する。

図１は双方向型ペイ・パー・ビュー・システムの基準モデルを実装するクローズド・ネットワークの例を具体的に示している。放送チャネル１０２は普通、顧客側１０４に映像、音声、可能なデータを配信する一方向の放送ネットワークである。対話チャネル１０６は通常では、対話目的のためにユーザ１０４とサービス・プロバイダ１０８との間に確立される双方向チャネルである。対話チャネル１０６は通常、一般的に戻りチャネルとして知られている狭帯域チャネルを有し、これはサービス・プロバイダに要求を出すため、または質問に答えるために使用される。放送ヘッドエンド１１０と双方向ヘッドエンド１１２は、通常独自仕様のネットワーク上で、映像と音声の放送チャネル１０２を放送サービス・プロバイダや対話型のサービス・プロバイダ１０８へとブリッジする。顧客の家屋１０４側では、通常ではセットトップボックス１２２から同軸ケーブルを通じてディスプレイ・デバイス１２０（例えばテレビ受像機）へ接続される。図１は１つの家庭の中に多数のセットトップボックスを示している。１本の同軸ケーブルを通って家庭に入る信号はスプリッタ、あるいはリピータを使用して配信される。エンドツーエンド接続は通常では単一のサービス・プロバイダによって管理され、維持されるので、クローズド・システムまたはクローズド・ネットワークが厳格なリソース・プロビジョニングを有することに気付くことが重要である。

対照的に「オープン」ネットワークでは、ハードウェア、ソフトウェア、対応するプロトコルは、異なる製造業者から容易に入手可能なソリューションで、よく知られている規格によってすべて規定され、そのようなソリューションは互いに相互運用可能である。付け加えると、オープン・ネットワークは共有ネットワークであり、場合によっては数多くのサービス・プロバイダやコンテンツ・プロバイダがコンテンツを配信するためにこの共有ネットワークを使用する。オープン・ネットワークの例はインターネット技術標準化委員会（ＩＥＴＦ）によって規定されるようなインターネットである。ＩＥＴＦはインターネットの運用、管理、展開を調整すること、および短期と中期のプロトコルとアーキテクチャの課題を解決することを目的とするネットワーク設計者、オペレータ、ベンダー、研究者の大規模な開放された団体である。オープン・ネットワークのプロトコルは国際標準化機構（ＩＳＯ）のネットワーク化モデルに基づいて階層化される。いずれの所定のオープン・ネットワークも、オープン・ネットワークを通じて通信している間に使用されるネットワーク・プロトコルに応じた付加的なオーバヘッドを有している。全部ではないが多くの現在のソリューションは、より高い品質と解像度のＡ／Ｖプログラミング・コンテンツを処理中にオープン・ネットワーク・モデルをサポートするためのシステム・リソースを有さない。付け加えると、リソース・プロビジョニングは通常ではそのようなオープン・ネットワーク上で管理することがさらに困難である。

歴史的には、広帯域のＡ／Ｖの配信は、セットトップボックス（ＳＴＢ）やＰＶＲデバイスを使用して衛星とケーブル・サービスによって遂行されてきた。そのようなシステムの例が図２に示されている。図３は、衛星放送、ケーブル放送、または地上放送から高解像度テレビ受像機（ＨＤＴＶ）またはビデオ・プロジェクタであることが可能なレンダリング・デバイスへのＡ／Ｖチャネルの（図２に示されるシステム・アーキテクチャに関連するような）広帯域配信のフローを述べている。例えば図２の構成要素と図３に例示されたフローを参照すると、衛星放送受信アンテナは様々な放送チャネルを衛星放送信号として受信する（３０１）。受信器（フロントエンド・デバイス）は、順方向エラー修正（ＦＥＣ）と共に４位相偏移変調（ＱＰＳＫ）または位相シフトキーイング（ＰＳＫ）復調を実装する（３０２）ゼロＩＦチューナー２０２である。通常、デジタル映像放送用サーバ（ＤＶＢＳ）またはＤｉｒｅｃＴＶの仕様のような標準インターフェースに準拠するシリアルまたはパラレルのデジタル出力の形で表される放送の映像はトランスポート・ストリーム・インターフェース（ＴＳＩ）２０４を通して伝達される（３０４）。ＴＳＩ２０４は通常ではデジタルの音声および／または映像データ・パケットをリアルタイムで伝達するように構成される専用のバスを有する。用途の別のセットでは、ＴＳＩ２０４は概してリアルタイムのアプリケーション・データを伝達するように構成される専用のバスである。

標準ＴＳＩの詳細はＣＥＮＥＬＥＣ（Ｅｕｒｏｐｅａｎ Ｃｏｍｍｉｔｔｅｅ ｆｏｒ Ｅｌｅｃｔｒｏ−Ｔｅｃｈｎｉｃａｌ Ｓｔａｎｄａｒｄｉｚａｔｉｏｎ）規格機構の仕様ＥＮ ５００８３−９に文書化されている。さらに特定すると、前述の標準ＴＳＩに関連する参考情報はＥＮ ５００８３−９：１９９８「Ｃａｂｌｅ ｎｅｔｗｏｒｋｓ ｆｏｒ ｔｅｌｅｖｉｓｉｏｎ ｓｉｇｎａｌｓ，ｓｏｕｎｄ ｓｉｇｎａｌｓ ａｎｄ ｉｎｔｅｒａｃｔｉｖｅ ｓｅｒｖｉｃｅｓ――Ｐａｒｔ９：Ｉｎｔｅｒｆａｃｅｓ ｆｏｒ ＣＡＴＶ／ＳＭＡＴＶ ｈｅａｄ ｅｎｄｓ ａｎｄ ｓｉｍｉｌａｒ ｐｒｏｆｅｓｓｉｏｎａｌ ｅｑｕｉｐｍｅｎｔ ｆｏｒ ＤＶＢ／ＭＰＥＧ−２ ｔｒａｎｓｐｏｒｔ ｓｔｒｅａｍｓ」、ＥＮ ５００８３−９：２００２「Ｃａｂｌｅ ｎｅｔｗｏｒｋｓ ｆｏｒ ｔｅｌｅｖｉｓｉｏｎ ｓｉｇｎａｌｓ，ｓｏｕｎｄ ｓｉｇｎａｌｓ ａｎｄ ｉｎｔｅｒａｃｔｉｖｅ ｓｅｒｖｉｃｅｓ――Ｐａｒｔ９：Ｉｎｔｅｒｆａｃｅｓ ｆｏｒ ＣＡＴＶ／ＳＭＡＴＶ ｈｅａｄ ｅｎｄｓ ａｎｄ ｓｉｍｉｌａｒ ｐｒｏｆｅｓｓｉｏｎａｌ ｅｑｕｉｐｍｅｎｔ ｆｏｒ ＤＶＢ／ＭＰＥＧ−２ ｔｒａｎｓｐｏｒｔ ｓｔｒｅａｍｓ」に含まれる。この仕様は次のウェブ・ページ、すなわちｈｔｔｐ：／／ｗｗｗ．ｃｅｎｅｌｅｃ．ｏｒｇ／Ｃｅｎｅｌｅｃ／Ｈｏｍｅｐａｇｅ．ｈｔｍから入手することが可能である。

再び図２と関連させて図３を参照すると、その後、データは構文解析され（３０６）、スクランブル解析され（３０８）、実装された限定受信方法と圧縮規格に応じてさらに逆多重化される（３１０）。その後、データは別のシステムで使用するため、または後に再生するために保存され（３１２）、あるいは解読され（３１４）てレンダリング・デバイス上で再生される（３１６）。図３に概説されるの多くが通常ではハードウェアとソフトウェアの両方で実装されることは気付かれるはずである。解読（３１４）と逆多重化（３１０）はハードウェアとソフトウェアによって遂行される機能の例である。絶えず変化する規格と方法は或る一定の機能をソフトウェアとして実現することを余儀なくさせる。ソフトウェア内へのこれらアルゴリズムの実装は、陳腐化を最小限にする一方で、最も高い柔軟性の程度を与える。

上述の配信モデルは衛星放送、ケーブル放送、または地上放送については良好にはたらく。しかしながら、配信の主要な方法としてイーサネットを使用するＡ／Ｖコンテンツの配信は付加的な課題を作り出す。図２に示されるように、イーサネット制御装置２１０は通常ではチップ（ＳＯＣ）２０８上のＳＴＢ／ＰＶＲシステムのローカル（もしくはメモリ）バス２１２へと連結される。このネットワーク接続はケーブル・モデムまたはデジタル加入者回線（ＤＳＬ）の広帯域接続を通じてインターネット・アクセスのために伝統的に使用されてきた。ローカル・バス上で標準的なイーサネット制御装置を使用することは概して、リアルタイムのＡ／Ｖ配信のために必要とされる性能を供給しないであろう。イーサネット制御装置２１０は概して他の周辺機器とローカル・バス２１２を共有するので、ネットワーク・データの処理は大幅に低速化され、かつ／または遅らされる可能性が高い。ＴＣＰ／ＩＰやその他のような追加的なネットワーク・プロトコルを処理することはシステムをさらに低速化させる可能性が高い。

既存のＡ／Ｖソリューションは概して、家庭でのインターネット・ウェブ・サーフィンに対して、さらにはビデオ・オン・デマンド（ＶＯＤ）、課金システム、限られたＡ／Ｖ配信用途のためのリターンパスといった活動に対して毎秒１から６Ｍｂｉｔｓの通常のデータ速度でイーサネット接続を使用する。さらに高い品質の映像コンテンスおよび／または音声コンテンツをストリーミングするための帯域幅の必要条件は大幅に高い。例えば、高解像度（ＨＤ）映像ストリームをサポートするために、ＱＯＳ（サービスの品質）を含めて、いくつかの形の優先帯域幅のプロビジョニングを伴って毎秒１２から６０Ｍｂｉｔｓの処理能力が要求される可能性が高い。ＱＯＳに関するニーズは普通ではバッファ処理と待ち時間によって決定される。例えば、増加した帯域幅必要条件は、映像コンテンツのチャネルの切り換えの間の時間的遅延がバッファ処理による遅延のせいで「チャネル・サーフィン中」にユーザによって為されるチャネル選択の間に経過する平均的受容可能時間を超える場合に増加したＱＯＳを必要とする可能性が高い。Ａ／Ｖデータの分配は好ましくは最小限の遅延で安定して留まるべきである。図２のイーサネット制御装置２１０と同様に、既存のイーサネットソリューションでは必要とされる性能レベルを達成することはたとえ可能であっても通常では極めて困難である。

付け加えると、ＳＴＢやその他の民生用エレクトロニクス・デバイスは極めてコストに敏感である。民生用エレクトロニクス・デバイスの大半に含まれるほとんどの内蔵型プロセッサやハードウェア構築ブロックは普通では低コストであり、限られた性能（通常では毎秒何百万命令（ＭＩＰＳ）で参照される）を特色とする。メモリ・アクセス・スピード、ＣＰＵのスピード、電力消費の間のトレードオフは全く普通である。ほとんどのシステム設計者に対して、ＣＰＵの帯域幅がコア・アプリケーションのために充分であるとき、追加のネットワーク処理用オーバヘッドを伴うオープン・ネットワークへの移行は一層高額のシステムによるソリューションへと移行することを余儀なくされる。付け加えると、この追加的なネットワーク・オーバヘッドにより、標準的なイーサネット制御装置を使用することは、特に低コストの民生用エレクトロニクス製品を目標にするときにはオープン・ネットワークによるソリューションを可能にするために必要とされる性能を与えることは通常ではないであろう。

共有のオープン・ネットワーク上でリアルタイムと非リアルタイムの映像コンテンツと音声コンテンツを伝達する概念は多様な方式で対処されてきた。例えば、８０１．１１ａ、ｂ、ｇのような無線変調によるソリューションが共有アクセスのローカルエリア・ネットワークに関して検討されてきた。８０２．３ １０／１００／１０００Ｂａｓｅ−Ｔツイストペア回線の符号化ソリューションもやはり検討されてきた。媒体アクセスとトランスポート・レベルでの数多くのソリューションもやはり述べられてきた。これらのソリューションのいくつかはイーサネット８０２．３、無線、８０２．１１ａ、ｂ、ｇ、および非同期転送モード（ＡＴＭ）、Ｓｙｎｃｈｒｏｎｏｕｓ Ｏｐｔｉｃａｌ Ｎｅｔｗｏｒｋｉｎｇ（ＳＯＮＥＴ）などといったその他のソリューションを使用する媒体アクセスの方法を含む。付け加えると、さらに高いＱＯＳを達成するための様々な方法が或る独自仕様のソリューションによって取り組まれてきた。

１つの取り組み方は「送信プロファイル」の概念を含み、そこではネットワーク・システムや集積装置がイーサネット・パケット内でのようにネットワーク・パケット内で追加的な情報を検出することによって経路を選択する。他のケースでは、仮想ローカルエリア・ネットワーク（ＶＬＡＮ）タグが利用され、あるいは（仮想）経路識別子を利用するＡＴＭが実装される。いくつかのソリューションはデータ帯域幅割当てを実装し、そこではネットワーク・システムは、周波数分割多重処理（ＦＤＭ）された複数のチャネルにわたって高速アクセスが提供され、ケーブルの伝送ネットワーク全域へのイーサネット・フレームおよび／または他のデータの伝送、あるいはＦＤＭトランスポートの他の形式を可能にするように設計されることが可能である。デバイスは、通常では、予め規定された複数の周波数チャネル上で様々なネットワーク・パケットのためのタイムスロット割当て量に基づいてダウンストリームとアップストリームの帯域幅を割り当てる。トランスポートの観点で見ると、多くの現在のソリューションはインターネット・プロトコル（ＩＰ）を利用する。いくつかのケースでは、伝送制御プロトコル（ＴＣＰ）のような様々なコネクション型プロトコルが使用される。

製品化されたソリューションの１つの例はＴａｉｆａｔｅｃｈ Ｉｎｃ．によるＴＦ−５３０「Ｄｉｇｉｔａｌ Ｓｔｒｅａｍｉｎｇ Ｃｏｎｔｒｏｌｌｅｒ」である。ＴＦ−５３０はブリッジ用エンジンであってＴＣＰ／ＩＰプロトコルで束ねられ、ＴＣＰ／ＩＰプロトコル・スタックとＨＴＴＰサーバ・アプリケーションを含む様々なソフトウェア成分を備えた集積型ＲＩＳＣ ＣＰＵを特色とする。このソフトウェアはＩＰ、Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ（ＵＤＰ）、ＴＣＰ、Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ Ｐｒｏｔｏｃｏｌ（ＩＣＭＰ）、Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ（ＲＴＰ）アクセラレータ・サポートもやはり含む。ＴＦ−５３０はまた、専用のストリーミング映像インターフェースを特色とする。
ＥＮ ５００８３−９：１９９８「Ｃａｂｌｅ ｎｅｔｗｏｒｋｓ ｆｏｒ ｔｅｌｅｖｉｓｉｏｎ ｓｉｇｎａｌｓ，ｓｏｕｎｄ ｓｉｇｎａｌｓ ａｎｄ ｉｎｔｅｒａｃｔｉｖｅ ｓｅｒｖｉｃｅｓ――Ｐａｒｔ９：Ｉｎｔｅｒｆａｃｅｓ ｆｏｒ ＣＡＴＶ／ＳＭＡＴＶ ｈｅａｄ ｅｎｄｓ ａｎｄ ｓｉｍｉｌａｒ ｐｒｏｆｅｓｓｉｏｎａｌ ｅｑｕｉｐｍｅｎｔ ｆｏｒ ＤＶＢ／ＭＰＥＧ−２ ｔｒａｎｓｐｏｒｔ ｓｔｒｅａｍ」 ＥＮ ５００８３−９：２００２「Ｃａｂｌｅ ｎｅｔｗｏｒｋｓ ｆｏｒ ｔｅｌｅｖｉｓｉｏｎ ｓｉｇｎａｌｓ，ｓｏｕｎｄ ｓｉｇｎａｌｓ ａｎｄ ｉｎｔｅｒａｃｔｉｖｅ ｓｅｒｖｉｃｅｓ――Ｐａｒｔ９：Ｉｎｔｅｒｆａｃｅｓ ｆｏｒ ＣＡＴＶ／ＳＭＡＴＶ ｈｅａｄ ｅｎｄｓ ａｎｄ ｓｉｍｉｌａｒ ｐｒｏｆｅｓｓｉｏｎａｌ ｅｑｕｉｐｍｅｎｔ ｆｏｒ ＤＶＢ／ＭＰＥＧ−２ ｔｒａｎｓｐｏｒｔ ｓｔｒｅａｍ」

しかしながら、ほとんどの既存のシステムは通常では、より高い品質と解像度のＡ／Ｖプログラミング・コンテンツの配信に要求される性能レベルを維持することが可能なイーサネット・プロトコルを中心に構築されるオープン・ネットワークのソリューションを提供しない。標準的なイーサネット制御装置を利用する現在のシステムは、限られた帯域幅のローカル・バス上でリアルタイムのストリーミング・データの動きを可能にすることはなく、したがって所望の性能レベルを達成しない。

先行技術に関するその他の課題は、そのような先行技術を本願明細書に述べられる本発明と比較した後に当業者に明らかになるであろう。

或るセットの実施態様では、セットトップボックス／パーソナル・ビデオ・レコーダ・システムのような音声映像コンテンツ配信システムが、ローカルエリア・ネットワーク（ＬＡＮ）とインターフェースするように構成される。このシステムに含まれるパケット処理回路は、ＬＡＮから特定のポートおよび／または待ち行列へと入来するイーサネット・パケットなどであるデータ・パケットをホスト・プロセッサの介入を伴わずに途中で割込みし、フィルタ処理し、経路指定するように構成される。このパケット処理回路は、様々なプロトコル、例えばインターネット技術標準化委員会（ＩＥＴＦ）のネットワーク化プロトコルを解釈するためにフィルタと経路指定用メカニズムのセットを利用し、各々がパケット処理回路へと連結される多様な民生用サブシステムによって認識されるフォーマットでパケット・データを転送する。このパケット処理回路は、半導体デバイスとして実装されることが可能であり、カプセル化されたアプリケーション・データ（標準的なカプセル化技術を使用してカプセル化される）が複数の異なるタイプのアプリケーション・シンクまたはプロセッサへと送られ、ＩＳＯデータ通信スタックの数多くのレベルを網羅する標準的トランスポート上でポイントツーポイントまたはマルチポイントのシリアルもしくはパラレルのデータ・ストリームを形成する。

一実施態様では、パケット処理回路は、外部プロセッサ（または同等のシステム・レベル制御装置）の補助でネットワーク接続をセットアップし、作り出し、ネットワーク接続を通じてアプリケーション・データを特定のハードウェア・インターフェースへ送るように構成される。このようにしてパケット処理回路は、通常ではネットワーク・データ通信制御装置とホスト・プロセッサとの間に設置される通常のデータ・インターフェースとは分離していて異なるハードウェア・インターフェースとして動作することが可能であり、通常のデータ・インターフェースはＰＣＩ（Ｉｎｔｅｌ社のＰｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｆａｃｅ）、ＳＲＡＭ類、ＳＤＲＡＭインターフェース、その他の同様のタイプのインターフェースのような様々なパラレル・バス・アーキテクチャを含む。したがって、或るセットの実施態様では、パケット処理回路は追加的なハードウェア加速特性を組み入れる能力を備えて構成される単一ポートのイーサネット・フィルタやルータとして運転されることが可能である。

一実施態様では、パケット処理回路は、既にあって公表され、良好に規定され、かつ独自仕様ではない、ハードウェアに実装されるカプセル化方法を使用してパケットをフィルタ処理する能力を備えた独特のデータ・ストリーム・インターフェースを特色とする。ハードウェア補助によるフィルタ処理を通じて、通常ではソフトウェアで達成されない性能レベルが到達されることが可能であり、リアルタイムの映像と音声のストリーミングといった用途のネットワーク・トランスポートのカプセル化とフィルタ処理の必要条件に対する高度に効率的で費用効果の高いソリューションを提供する。ＬＡＮ（或る実施態様ではイーサネット）からストリーミング用の「民生用」サブシステムへとデータを転送する性能と柔軟性はハードウェア内のフィルタ処理作業の効率的な性能を通じて増大することが可能である。本発明の原理に従ってハードウェア補助によるフィルタ処理を遂行する利点と利益はオープン・システム・ネットワークの前処理機能の作成、ホストＣＰＵの処理を取り除くための能力、専用のストリーミング・パイプ・インターフェースの作成、映像コンテンツと音声コンテンツの配信に関して特定のニーズに対処する能力を含む。

好ましい実施態様は、ネットワークの映像コンテンツと音声コンテンツを前処理することが可能な高級な帯域幅用途に焦点を絞る能力を備えた特化されたハードウェアを特色とする。特化されたハードウェアは、ネットワーク化の複雑さを処理し、高い解像度の映像と音声のストリーミングを可能にする主ＣＰＵの必要条件を削減することが可能である。

このようにして、本発明の様々な実施態様はネットワーク接続を確立し、かつハードウェア加速の手法を利用して高性能のリアルタイム・コンテンツの配信を達成するためのシステムと方法を提供することが可能である。

本発明の前述ならびにその他の目的、特徴、利点は添付の図面と一緒に読むときに下記の詳細な説明を参照することによってさらに完全に理解できるであろう。

本発明は様々な改良や代替の余地があるが、特定の実施形態が図中で例として示され、本願明細書に詳しく述べられるであろう。しかしながら、これらの図面とそれに対する詳細な説明が本発明を開示された特定の形に限定するように意図されておらず、逆に本発明が添付の特許請求項によって規定される本発明の精神と範囲の中に入るすべての改造例、同等例、代替例を網羅することは理解されるべきである。見出しが単に組織化を目的とするものであって本説明または特許請求項を限定または解釈するために使用されることを意図されていないことに留意すべきである。さらに、「可能である」という語句は本願明細書全体を通して許容的な意味（すなわち、する能力を有する、することができる）で使用され、義務的な意味（すなわち、しなければならない）ではないことに留意すべきである。「含む」という語句とそれから派生する語句は「含むがそれに限定されない」ことを意味する。「連結される」という語句は「直接的または間接的に接続される」ことを意味する。

本願明細書で使用される「ＤＷＯＲＤ」または「Ｄｏｕｂｌｅ Ｗｏｒｄ」は３２ビット・サイズのデータ・ワードに言及するために使用される。「ローカル・システム・メモリ」または「ローカル・メモリ」はホスト・システム内に含まれるメモリに関し、通常では中央演算処理装置および／またはセントラル・コントローラの中に内蔵されるかまたは直接インターフェースする。「遠隔システム・メモリ」または「遠隔メモリ」は、ホスト・システム内に含まれるが中央演算処理装置および／またはセントラル・コントローラの中に内蔵されず、または直接インターフェースしないメモリ、あるいはホスト・システムとは異なる遠隔システム内に含まれるメモリに関する。ホスト・システム内に含まれるとき、遠隔メモリはホスト・システムの専用メモリ・バスに直接インターフェースしない周辺デバイス内のメモリおよび／または追加的なメモリを表すことが可能である。

やはり本願明細書で使用され、かつシステムに適用される「リアルタイム」、「リアルタイム配信」、「リアルタイム・オペレーション」、および／または「リアルタイム・ストリーミング」は、システムへの入力信号（または複数の入力信号のセット）および／またはそれに対応する出力信号（または複数の出力信号）がシステムに同じ信号セットを入力および／または出力するためにかかる時間の中でシステムによって連続的に処理される（または生成される）ことが可能であって、それがシステムの中で負わされる遅延と無関係であることを示す。言い換えると、入力信号と対応する出力信号は、システムによって入力信号が受信されている速度と平均して釣り合った速度でシステムによってそれぞれ処理され、出力されている。「ポート」という用語が使用されるとき、それはネットワーク、例えばＴＣＰ／ＩＰおよび／またはＵＤＰネットワーク内の論理的接続のエンドポイントに関すると意図されている。或るセットの実施形態では、「ポート番号」はいずれのタイプのポートが参照されているかを識別するために使用される。例えばＴＣＰ／ＩＰおよび／またはＵＤＰネットワークではポート番号８０はＨＴＴＰトラフィックのために使用される。別のセットの実施形態では、「ポート」は単一のインターフェース整合が得られるカプセル化ヘッダ領域の値の組み合わせを表すこともある。

やはり本願明細書で使用される「トランスポート・ストリーム・インターフェース」（ＴＳＩ）は、とりわけ基本ストリーム、サービス情報、個人的データ、条件付きアクセス制御から由来したデータ・パケット・ストリームの伝送のために構成される専用のインターフェースを参照するように一般的な意味で使用される。映像と音声のストリームを含むであろうこれらデータ・パケット・ストリームは、「トランスポート・ストリーム・インターフェース」上で伝送するために多重化されて「トランスポート・パケット」へ変換される。前述したように、ＴＳＩの１つの例は以下のウェブ・ページ、すなわちｈｔｔｐ：／／ｗｗｗ．ｃｅｎｅｌｅｃ．ｏｒｇ／Ｃｅｎｅｌｅｃ／Ｈｏｍｅｐａｇｅ．ｈｔｍに述べられている。

前に検討したように、図２に示されたシステムは最適化されていないネットワーク（このケースではイーサネット）接続を特色とするＳＴＢソリューションを表している。映像または音声のデータが最終のレンダリング・デバイス（例えば図２のテレビジョン）へと転送されるように、データは、通常ではＣＰＵ（図２のＳＴＢ／ＰＶＲ ＳＯＣ２０８）のローカル・バス、メモリ・バスもしくはＩ／Ｏバス（図２のローカル・バス２１２）上で転送される。同じバス上のデバイスと、帯域幅に関してコンテンションが生じるであろう。図２のシステムについては、ＳＴＢ／ＰＶＲ ＳＯＣ２０８は映像と音声のデータの追加的なフォーマティングとコピー処理を遂行することも要求されるであろう。通常では映像と音声のデータが衛星またはケーブル接続を介したＡ／Ｖコンテンツ配信に使用されるトランスポート・ストリーム・インターフェース（図２の２０４）上で伝送された場合、この追加的なフォーマティング処理は普通では要求されない。そのようなフォーマティング・オペレーションをしなければならないＣＰＵを救済するために、パケット処理回路は、衛星放送またはケーブル放送の復調器が入来するデータをフィルタ処理するそれに類似した方式で入来するネットワーク・パケットを構文解析するように構成される。図４に示された図はそのようなパケット処理回路を特色とするＳＴＢシステム４００の一実施形態を説明している。

ここで図４を参照すると、トランスポート・ストリーム・インターフェース（ＴＳＩ）４０４はチューナー４０１ａ、４０１ｂ、４０１ｃをＳＴＢ／ＰＶＲ Ｏｎ ａ Ｃｈｉｐ（ＳＯＣ）４０６へと直接結合させることが可能である。ＴＳＩ４０４はパケット処理回路４０２をＳＴＢ／ＰＶＲ ＳＯＣ４０６へと結合させることもやはり可能である。ＴＳＩ４０４はリアルタイムのアプリケーション・データを転送するために特別に構成された専用のバスであることが可能である。図４は１つのＴＳＩを備えた実施形態を例示しているが、他の実施形態は複数のＴＳＩを備えて構成されることが可能である。例えばメモリ・バスもしくはＩ／Ｏバス・インターフェース／接続を表すローカル・バス４１０を介してパケット・プロセッサ４０２がＳＴＢ／ＰＶＲ ＳＯＣ４０６へと連結されることもやはり可能である。ローカル・バス４１０は、ネットワーク・データ・フローの中に統合される非映像と非音声のデータ用に使用される帯域外（ＯＯＢ）接続であることが可能である。ローカル・バス４１０の実施形態は、限定はされないが様々なＣＰＵバス・インターフェース、ＰＣＩ、ＡＨＢ、ＤＤＲ、ＳＤＲＡＭ、当該技術でよく知られている他の同様のバスを含むことが可能である。一実施形態では、パケット処理回路４０２はＳＴＢ／ＰＶＲ ＳＯＣ４０６内に構成されることが可能な内蔵プロセッサ上で走る符号に通常は付随するいくつかの機能を実行するイーサネット／ＩＰデコーダである。そのような機能の１つの例はＴＣＰ／ＩＰプロトコル一式の中に含まれるネットワーク・スタックに関連して遂行される機能を含む。

パケット処理回路の一実施形態４０２は図５に示され、データ・ストリーミング用途のためにパケット・フィルタとルータ（ＰＦＲ）５０４に連結されたイーサネット制御装置５０２（これは１０／１００／１０００および１０Ｇｉｇ物理層（ＰＨＹ）と、媒体アクセス制御装置（ＭＡＣ）を含むことが可能である）を有する。ＰＦＲ５０４は、受信バッファ５０８ａ〜５０８ｃで表される数「ｎ」の受信バッファとインターフェースすることが可能であり、それらはホスト・インターフェース５４８を介してホスト・バス５５０とインターフェースすることが可能である。イーサネット制御装置５０２もやはり制御信号バス５０６を通じ、ホスト・インターフェース５４８を介してホスト・バス５５０とインターフェースすることが可能である。或る実施形態ではホスト・バス５５０は図４のローカル・バス４１０と一致する。或る実施形態では、ホスト・バス５５０（および／またはローカル・バス４１０）はマスタおよび／またはスレーブＤＭＡをサポートすることが可能である。パケット処理回路４０２から出る出力は、ＴＳＩバッファ５１０ａ〜５１０ｄで表されてＦＩＦＯであることが可能な数「ｎ」のＴＳＩバッファによって供給されることが可能である。代替オプションの実施形態（図示せず）では、パケット処理回路４０２から出る出力は、ＴＳＩバッファ５１０ａ〜５１０ｄを使用せずにＰＦＲ５０４によって直接ＴＳＩ４０４へと供給されることが可能である。或るセットの実施形態ではＴＳＩバッファ５１０ａ〜５１０ｄは物理的または論理的にパケット処理回路４０２の外側でかつ遠隔に置かれ、ＤＤＲ、ＤＤＲ２、ＳＤＲＡＭ、ＳＲＡＭ、またはＦＬＡＳＨ ＲＡＭといった標準的なメモリ・バス・アーキテクチャを使用してパケット処理回路４０２、さらに特定するとＰＦＲ５０４へと結合することが可能である。一実施形態では、パケット処理回路４０２は最新式の民生用エレクトロニクス用途、特に低ジッターでタイムクリティカル（等時性）の情報の伝送を必要とする用途をサポートするように構成される。そのような情報の例は、限定はされないが一定のビット速度でのデータの転送を必要とする映像と音声アプリケーションのストリーミングを含む。図示されていないが可能であり、かつ考えられる他の実施形態では、パケット処理回路４０２はリアルタイムのデータを使用する他の選択されたアプリケーションをサポートするように構成されることが可能である。

一実施形態では、パケット処理回路４０２は多数データ・タイプのストリームを同時にフィルタ処理し、経路指定するように構成され、それにより、特定のイーサネット・パケットをホスト・インターフェース５４８のような様々なホスト・インターフェースへと転送する。可能なホスト・インターフェースは、ＰＣＩ、ローカル・バスまたはメモリ・バスといった標準的なバス・アーキテクチャや、多様なデータ・バス幅と制御定義を利用する非標準のバスを含む。パケット・プロセッサ４０２はデータ消費のためにアプリケーション・データ・ストリームを受信デバイス、例えばビデオ・デコーダへとリダイレクションするように動作することが可能である。図１１は映像と音声のデータがネットワーク上、このケースではイーサネットのネットワーク上でのコンテンツ・プロバイダからレンダリング・デバイスへの転送のためにパケット内にカプセル化されることが可能な方法の例を例示している。さらに特定すると、ＲＴＰビデオ／オーディオ・コンテンツ、ＲＴＰオーディオ・コンテンツ、ＭＰＥＧコンテンツに関してカプセル化の例が示されている。或るセットの実施形態では、ＰＰＣ４０２は様々な構成／制御レジスタを通じて、かつＳＯＣ４０６と関連してＲＴＰ接続を管理するように構成されることが可能であり、リアルタイム・アプリケーションにおける低減されたジッターと低減されたバッファ処理必要条件を可能にする。

一実施形態によるパケット処理回路４０２によって遂行される論理データ・ストリームのフィルタ処理と、アプリケーション・データの経路指定のフローが図１２Ａ〜Ｂに示されている。図１２Ａ〜Ｂのフローは、ビデオ・サーバまたはオーディオ・サーバが既に受信器との接続を確立していること、その接続がホスト・バス・インターフェース（図４の５４８）を通じて確立されること、その接続がいずれかの特定のＭＡＣまたはトランスポート機能を伴わずに確立されること、パケット処理回路４０２が標準的ネットワークのイーサネット制御装置（図４の５０２）を有することを前提にして達成される。しかしながら、図１２Ａ〜Ｂのフローは、論理データ・ストリームのフィルタ処理と、イーサネット規格ではないいずれかの選択されたネットワーク規格に準拠するデータ・パケットのその選択されたネットワーク規格に付随する前提に従ったアプリケーション・データ経路指定を実施することが可能である。

前述したように、イーサネット接続に関するパケット処理回路４０２は、性能と柔軟性が要求される内蔵アプリケーションのために設計された１０／１００／１０００および１０Ｇｉｇイーサネット制御装置（図５の５０２）でよい。或るセットの実施形態では、イーサネット制御装置５０２は、ＩＥＥＥ ８０２．３ １０ＢＡＳＥ−Ｔおよび８０２．３ｕ １００ＢＡＳＥ−ＴＸ準拠品である。図１２Ａ〜Ｂに示されるように、（図４のＳＴＢ／ＰＶＲ４０６のような）セントラル・コントローラ用に意図されたデータ・パケット、このケースではイーサネット・パケットが途中で割込みされる（１２０２）。このパケットは、イーサネット制御装置５０２の中に含まれるイーサネットＭＡＣデータ・バッファ内に保存される（１２０４）。イーサネット制御装置５０２の中に含まれるＭＡＣは図６に示されるようなイーサネット・ヘッダ情報を使用してアドレスのフィルタ処理を行う。図６に示されるように、表６００はイーサネットＩＩフレームのフォーマットを例示しており、表６０２は８０２．３フレームのフォーマットを例示している。図６に示されたフォーマットはイーサネットと８０２．３のパケットの例であるが、或る実施形態ではパケット処理回路４０２は、他のアプリケーションのサポートに使用される他の媒体アクセスのフォーマットに従って内蔵されたデータのパケットを同様にホストもしくはシステムへとリダイレクション／経路指定するように構成されてもよい。

再び図５を参照すると、好ましい実施形態では受信経路内の次のブロックはＰＦＲ５０４である。ＰＦＲ５０４は受信バッファ５０８ａ〜５０８ｃのいずれか、またはＴＳＩバッファ５１０ａ〜５１０ｄのいずれかへの適切な経路指定を判定するために様々なネットワーク、トランスポートおよびアプリケーション層のヘッダ情報を利用することが可能である。或る実行例で使用されるネットワーク、トランスポートおよびアプリケーション層のヘッダの例は図７、８、および９に示されている。さらに特定すると、図７中の表７００はネットワーク層プロトコルＩＰヘッダの例を例示しており、図８中の表８００はトランスポート層プロトコルＴＣＰヘッダの例を例示しており、図８中の表８０２はトランスポート層プロトコルＵＤＰヘッダの例を示しており、図９中の表９００はアプリケーション層プロトコルＲＴＰバージョン２ヘッダの例を例示している。

再び図５を参照すると、ＰＦＲ５０４は受信されたイーサネット・パケットを特定の合致ポートに基づき、特定のプライオリティ技法に従って保存するために受信バッファ５０８ａ〜５０８ｃを利用する。そのプライオリティ技法においては、ＳＯＣ４０６がその特定のパケットが制御装置５０２によって直列に受信されたシーケンスとは異なるシーケンス内の合致ポートに対応するパケットの特定のシーケンスを、ホスト・インターフェース５４８を通じて、検索するように動作してもよい。言い換えると、ＳＯＣは、受信バッファ５０８ａ〜５０８ｃに保存されたデータ・パケットを、ＬＡＮ５０１を介してデータ・パケットが当初伝送されたシーケンスに対して異なる順序で検索するように動作することが可能である。

図１２Ａ〜Ｂと図７の表７００の両方を参照すると、ＩＰヘッダ領域の「Flagment Offset」と「Flag」はデータ・パケットが細分化されているかどうかを判定するために構文解析される（１２０６）。細分化はＭＡＣ長さまたはイーサネット・パケット長さを超える論理ＩＰデータ・パケットの全長として解釈される。一実施形態では、パケット処理回路４０２は細分化されたＩＰデータグラムをサポートするように構成される。そのようなサポートを有効にするために、最大ＩＰフレーム（或るセットの実施形態では最大で６５，５３５バイトまで）の長さと釣り合いのとれたサイズの記憶メモリがパケット処理回路４０２の中に内的に構成されるか、あるいは外的には専用のバスを通じてパケット処理回路４０２とインターフェースする。或るセットの実施形態では、内部メモリがバッファの要求条件を満たし得ないケースに外部メモリが必要とされるかどうかを判定するために「Flagment Offset」と「Flag」領域に関する値がチェックされる。

再び図１２Ａ〜Ｂと図７の表７００を参照すると、「Header Checksum」領域はデータ・パケットのデータ完全性をＩＰヘッダの妥当性確認の一部として確認する（１２０８、１２１０）ために使用される。いくつかの実施形態ではチェックサムの値は有効化されるが、他の実施形態ではチェックサムの値はたとえそれが利用可能であっても有効化されないこともある。他のチェックサムおよび／またはＣＲＣ領域は図７の表７００に示されたヘッダ情報の一部として利用可能にされ、冗長チェックは必要とされない。或るセットの実施形態では、関連するヘッダの長さを確認するため、およびさらなる処理に備えて後に続くヘッダのオフセットを判定するためにインターネット・ヘッダ長（ＩＨＬ）領域がＩＰヘッダ有効性の一部としてチェックされる（１２０８、１２１０）。付け加えると、パケットの経路指定を確認するために「Destination IP address」がチェックされることもある。

ここで図１２Ａ〜Ｂと図８の表８００を参照すると、トランスポート層ＴＣＰヘッダ「Destination Port」情報はデータ・パケットがＴＣＰポートを目標にしているかどうかを判定するため（１２１８）、および無効ＴＣＰポートのケースでは受信バッファ（図５の５０８ａ〜５０８ｃ）のうちの１つへ（１２１２）、あるいは有効ＴＣＰポートのケースではトランスポート・ストリーム・バッファ（図５の５１０ａ〜５１０ｄ）のいずれかへ（１２２４）とデータ・パケットの経路指定を続けるために使用される。データ完全性を判定するために「Checksum」領域が評価されることもある。

図８の表８０２を参照すると、トランスポート層ＵＤＰヘッダ「Destination Port」はデータ・パケットがＵＤＰポートを目標にしているかどうかを判定するため（１２１６）、および無効ＵＤＰポートのケースでは受信バッファ（図５の５０８ａ〜５０８ｃ）のうちの１つへ（１２１２）、あるいは有効ＵＤＰポートのケースではトランスポート・ストリーム・バッファ（図５の５１０ａ〜５１０ｄ）のいずれかへ（１２２４）とデータ・パケットの経路指定を続けるために使用される。データ完全性を判定するために「Checksum」領域と「Length」領域が評価されることもある。

図９の表９００を参照すると、アプリケーション層ＲＴＰヘッダ「PT」（ペイロード・タイプ）領域はペイロード・データ・タイプを判定するため（１２２４）、ＴＳＩバッファへの転送のためにそれが有効なペイロード・データ・タイプであるかどうかを確認するため（１２２２）に使用され、および受信バッファ（図５の５０８ａ〜５０８ｃ）のうちの１つへ（１２１２）、あるいはトランスポート・ストリーム・バッファ（図５の５１０ａ〜５１０ｄ）のいずれかへ（１２２０）とペイロード・データの経路指定を続けるために使用される。パケットの順序間違いまたは重複を判定するために「Sequence number」領域が評価されることもある。同期とジッターの計算値を含めた時間クリティカルな情報に関するフィードバックを入手して、ホスト・システムがリアルタイムのデータ・ストリーミングを容易にするために「Time Stamp」領域が評価されることもある。例えば、限定はされないがリアルタイム・ストリーミング・プロトコル（ＲＴＳＰ：Real Time Streaming Protocol）を含めた多くのリアルタイムのストリーミング・プロトコルのうちの１つとともにマルチメディア・コンテンツが「Time Stamp」領域の情報を利用する。

図１０と図１１は或るセットの実施形態で使用されるイーサネット・パケット構造の中の様々なヘッダの配置と順序を示している。図示されたパケット構造は一度データまたはビデオ・ストリームが構成されて開始されると変わらないが、しかし個々のヘッダの様々な領域はネットワーク・トラフィックや経路指定オプションに基づいて変わることがある。図１０と図１１に示されるように、イーサネット・パケットは（複数の）ヘッダとペイロードで構成される。ヘッダはアプリケーションとネットワークのタイプに応じて変わる。１つまたは複数のヘッダが必要とされ、ヘッダの順序は通常ではＭＡＣ、ネットワーク（図１０、１１のＩＰ）、トランスポート（ＵＤＰとＴＣＰ）、アプリケーション層プロトコル（図１０、１１のＲＴＰ）、その他のアプリケーション・ヘッダである。

パケット・プロセッサ４０２は、それがデータを適切な外部ホストまたはＴＳＩへ経路指定する方法に柔軟性を有するように構成される。或るセットの実施形態では、ＴＳＩ（図４の４０４）は複数の特定の方法、信号定義、プロトコル、バスシーケンス、タイミングを有し、それらが一体となってデータ・フローを構成する。好ましい実施形態では、ＴＳＩ４０４は通常のホスト、デバイス、および／またはメモリのインターフェースとは異なる方式で動作する。通常もしくは標準的なホスト・インターフェースはＰＣＩ、ＶＣＩ、ＰＶＣＩ、ＡＨＢ、ＡＳＢ、ＡＰＢ、カード・バス、ローカル・バス、その他のＣＰＵホスト・バス・インターフェースを含み、それらは共用システム・インターフェース（ＳＳＩ）として定義される。ホスト・インターフェースはＤＤＲ、ＤＤＲ２、ＳＤＲＡＭ、ＳＲＡＭ、ＦＬＡＳＨ ＲＡＭ、同期ＳＲＡＭ（ＳＳＲＡＭ）を含むこともあり、それらはメモリ・インターフェース（ＭＩ）として定義される。

図１３の図はパケット処理回路４０２に関して総合的なデータ・フロー、経路指定、フィルタ処理の構造を示している。一実施形態では、この構造は、図７、８、９の表７００、８００、８０２、９００にそれぞれ示されるようなヘッダ領域を解釈するようにプログラム可能なフィルタ・ブロック１３０４を含む。この構造はまた、ペイロード・ルータ１３０６、ペイロードとヘッダのルータ１３０８、ヘッダ・ルータ１３１０も含む。これらのルータが図７、８、９に規定されるヘッダに限定されないことは気付くであろう。いくつかの実施形態は、他の独自仕様で非標準のカプセル化ヘッダ・タイプを含めた他のＩＥＴＦヘッダ・タイプをも含む。さらに別の実施形態では、個々のルータ１３０６、１３０８、１３１０のいずれかおよび／またはすべては「カット・スルー」または「蓄積転送」アーキテクチャをサポートするように構成されてもよい。これら２つのアーキテクチャの間の違いはバッファ利用法、バッファ・サイズ、ジッター、システム待ち時間許容差の設計パラメータに影響を及ぼす。例えば、ストリーミング・コンテンツが一定のビットレートで伝送されるケースで、かつ映像の場合にそのコンテンツがレンダリング・デバイスのフレーム速度に適合していれば、両方のアーキテクチャが存続することが可能である。そのような制約が不可能であれば、バッファのシーケンスは蓄積転送アーキテクチャに従って実施される。

ペイロード・ルータ１３０６はペイロードがＴＳＩ １３１６またはＳＳＩ／ＭＩ １３１８のどちらへ経路指定されるかを決定するために使用される。図１４はペイロード・ルータ１４０６（図１３からのペイロード・ルータ１３０６を図１４に表す）だけが使用される実施形態に関してフローの構造を例示しており、このケースではヘッダは除去される。図１４中で濃く輪郭を描かれた経路がこのケースに関するフローを示している。図示されるように、ＭＡＣ／ＰＨＹ１４０２はパケットを受信する。このパケットは、フィルタ１４０４によってフィルタ処理され、かつペイロード・ルータ１４０６によってＴＳＩ １４１６および／またはＳＳＩ／ＭＩ １４１８へ経路指定される。これに対応して図２１は図５によるパケット処理回路４０２の実施形態を示しており、フィルタ処理されたパケットが図１４のフロー構造に従って、ＴＳＩ出力部へ経路指定される一方、ヘッダが除かれたときに、パケットの転送に含まれる構成要素を強調している。イーサネット制御装置２１０２は、ＬＡＮ２１０１上で受信されたデータをパケット・フィルタとルータ２１０４へ送る。図２１に示されるように、ＴＳＩインターフェース・バッファ２１１０ａ〜２１１０ｄは各々のパケット２１１１ａ〜２１１１ｄに関して個々のヘッダとペイロードを処理する。ヘッダは除去されることがあり、アプリケーション・データすなわちペイロードがＴＳＩポートへ経路指定される。やはり図示されるように、或る実施形態ではＴＳＩバッファまたはＦＩＦＯ２１１０ａ〜２１１０ｄはペイロード・データがＴＳＩ出力部へと送られる前にそれを保存する。ＴＳＩ出力部でのデータ消費デバイスのフレーム速度と同等の一定のビットレートを達成するためにシステム全体の能力に基づいてバッファ処理が必要とされたり、必要とされないこともある。図２１に見られるように、（「ＭＡＣ」または「ＭＡＣとＩＰ」または「ＭＡＣ、ＩＰ、ＵＤＰ、ＲＴＰ」のヘッダや他の変形物を有するイーサネットのコンテキストで示される）ヘッダは引き剥がされ、アプリケーション・データはＴＳＩへと送られる。

図１５は、ペイロードとヘッダのルータ１５０８（図１３からのペイロードとヘッダのルータ１３０８を図１５に表す）がペイロードとヘッダの両方をＳＳＩおよび／またはＭＩ １５１８（図１３からのペイロードとヘッダのルータ１３１８を図１５に表す）へ経路指定する実施形態に関してフローの構造を例示している。図１５中で濃く輪郭を描かれた経路がこのケースに関するフローを例示している。図示されるように、ＭＡＣ／ＰＨＹ１５０２はパケットを受信する。このパケットはフィルタ１５０４によってフィルタ処理され、かつペイロードとヘッダのルータ１５０８によってＳＳＩ／ＭＩ １５１８へ経路指定される。図１５に示されるように、ペイロード１５１２とヘッダ１５１４は区別してＳＳＩ／ＭＩ １５１８へ経路指定される。ある意味では、図１５に示されたフロー構造はイーサネット・パケットを全部ホスト・システムへ経路指定させる。或る実施形態では、（フィルタ１５０４によって処理されるときに）フィルタ基準を満たすパケットがいずれの特定のアプリケーション・タイプにも特異的ではないパケットを含むことが可能である。図５に戻って参照すると、ホスト・インターフェース５４８へ経路指定されるすべてのパケットを有し、かつＴＳＩインターフェース５１０ａ〜５１０ｄを利用しないようにパケット処理回路４０２が構成される実施形態では、図１５に示されるフロー構造が利用される。

好ましい実施形態では、ヘッダがＴＳＩ １５１６へ経路指定されることはなく、その一方でペイロードはＴＳＩ １５１６またはＳＳＩ／ＭＩ １５１８のどちらかへ経路指定される。図１６はペイロードがＴＳＩ １６１６（図１３からのＴＳＩ １３１６を図１６に表す）へ経路指定され、その一方で付随するヘッダがＳＳＩ／ＭＩ １６１８（図１３からのＳＳＩ／ＭＩ １３１８を図１６に表す）へ経路指定される実施形態に関するフローの構造を例示している。これに対応して図２２は図５によるパケット処理回路４０２の実施形態を示しており、ペイロードがＴＳＩ出力部２２１０ａ〜２２１０ｃへ経路指定され、その一方でヘッダが図１６のフロー構造に従ってホスト・インターフェース２２４８を介して受信バッファ２２０８ａ〜２２０８ｃのうちの１つを通ってホスト・バス２２５０へ経路指定されるときにパケット転送に含まれる構成要素を強調している。図２２に示された実装またはプログラムされたオプションのように、イーサネット制御装置２２０２はＭＡＣ層を通ったイーサネット・パケットを送って独自のＩＥＥＥ８０２．３の６バイトの個々のマルチキャスト・アドレス、またはグループのマルチキャスト・アドレスのどちらかをフィルタ処理する。パケットはＰＦＲ２２０４内で、ネットワーク層、トランスポート層、および／またはアプリケーション層を含む１つまたは複数の層での適切なヘッダ情報に関して構文解析される。一実施形態では、（パケット２２１１ａ〜２２１１ｄからの）アプリケーション・データまたはデータ・ペイロードが引き剥がされ、かつ／またはＴＳＩポート２２１０ａ〜２２１０ｄのうちの１つまたは複数へ経路指定される。（同じくパケット２２１１ａ〜２２１１ｄからの）対応するヘッダまたは複数のヘッダは、図２２に描かれたようにバッファ２２０８ｂを使用し、ＳＳＩ／ＭＩ２２４８を経由してホスト・バス２２５０へと送られる。図２２に示されるようなバッファ処理は場合によって行なわれ、前に列挙した全体的なシステム・アーキテクチャのトレードオフに応じてカット・スルーまたは蓄積転送法が使用されることが可能である。

或るセットの実施形態では、フィルタ基準のいずれにも合致しないイーサネット・パケットは同じ経路を通って送られる。図２３は図５によるパケット処理回路４０２の実施形態を示しており、フィルタ基準のいずれにも合致しないパケットが同じ経路を通って送られるときにパケット転送に含まれる構成要素を強調している。図２３に見られるように、合致せず、かつアプリケーションに特化されていないいずれのパケットもバッファ２３０８ｃを経由してホスト・インターフェース２３４８へ経路指定される。

図２４は図５によるパケット処理回路４０２の実施形態を示しており、非合致パケットがバッファ２４０８ｃ内に置かれ、合致パケットがバッファ２４０８ｂ内に置かれるときにパケット転送に含まれる構成要素を強調している。或る実施形態では、多数のバッファまたはＦＩＦＯ（２４０８ａ〜２４０８ｃ）の使用はホスト・システムが優先待ち行列を作ることを可能にし、様々なヘッダ・タイプ、ＩＰ、ＵＤＰ、ＴＣＰ、またはアプリケーション・パケット・タイプを備えた特定のイーサネット・パケットが付随のホスト・ポートへ経路指定される。これによって、個々のイーサネット・パケットの処理がホスト・システムによって優先付けられる。図２３に示された実装またはプログラムされたオプションのように、ホスト・バス２３５０へ経路指定されるペイロードが暗号化されたデータを含むこと、または含まないこともある。

図１７は、イーサネット・データ・ヘッダがホスト・インターフェースへ経路指定され、ペイロード・データが除去される実施形態に関するフローの構造を例示している。ヘッダ・ルータ１７１４（図１３からのヘッダ・ルータ１３１４を図１７に表す）はＭＡＣ／ＰＨＹ１７０２によって受信されてフィルタ１７０４によってフィルタ処理されたイーサネット・パケットのヘッダまたは複数のヘッダをＳＳＩ／ＭＩ １７１８（図１３からのＳＳＩ／ＭＩ １３１８を図１７に表す）へ経路指定するために使用される。これは所定のアプリケーションに関してペイロードが必要とされないときに実行される。或るセットの実施形態では、図１７に例示されたフロー構造は診断と性能の最適化のために使用される。ヘッダ情報は統計学的情報のために使用され、ペイロードは除去されるので追加的なホストの処理を招くことはないであろう。

図１８は一実施形態によるトランスポート・ストリーム信号のインターフェースを説明している。図１８のインターフェースはデータ・ストリーミングを取り扱うように設計され、非標準のインターフェースを表す。或るセットの実施形態では、ストリーミング用の映像と音声のデータはこのインターフェース上で転送される。図１８に示されるように、これらの信号はＴＳエラー出力、ＴＳパケット・クロック、ＴＳ（オクテット、ニブル、またはビット）クロック、データ有効を含み、さらに限定はされないがシリアル・ビット・ストリーム、４ビット（ニブル）もしくは８ビット（バイト）接続の形式であるトランスポート・ストリーム・データを含む。一実施形態によるこれらの信号のタイミングと関係は図１９に概説される。上述したように、トランスポート・ストリーム・データ１９０２はシリアル・ビット・ストリーム、４ビット（ニブル）もしくは８ビット（バイト）タイプのバス接続を使用して供給される。図９で、「バイト０、バイト１、バイト２、．．．バイトＮ」はトランスポート・ストリーム・データのバス幅が８ビットであることを示している。ニブルまたはシリアル・バス幅については、これは「ニブル０、ニブル１、．．．ニブルＮ」や、「ビット０、ビット１、．．．ビットＮ」としてそれぞれ指定される。ＴＳパケット・クロック１９０６の立ち上がり（このケースではアサート）エッジはパケットまたはフレームの最初の８ビット（バイト）、４ビット（ニブル）、またはビットを示すことが可能である。このコンテキストでのパケットは必ずしもイーサネット・パケットを意味するわけではなく、イーサネット・データ・ペイロードの開始時のデータ・ペイロード・バイトの始まり、または始まりからのオフセットを意味する。一実施形態では、ＴＳパケット・クロック１９０６は所定のアプリケーションに基づいて特定の周波数で走る同期クロックである。映像アプリケーション、例えばＭＰＥＧ２では、シリアル・データに関してＴＳパケット・クロック１９０６のクロック速度は２７ＭＨｚである。ニブルまたはバイトのバス幅では周波数はさらに低くてもよい。ＴＳデータ有効信号１９０４はパケットまたはフレームの開始と終了を判定するために使用される。ＴＳデータ有効信号１９０４はパケットまたはフレームの最初のバイトでアサート開始され、最後のバイトでアサート停止される。ＴＳパケットエラー信号１９１０はトランスポート・ストリーム・データ１９０２の受信で間違ったデータまたはエラーにフラグを立てるために使用される。ＴＳパケットエラー信号１９１０がＴＳパケット・クロック１９０６の立下り中にアサートされると、トランスポート・ストリーム・データ１９０２に含まれるデータは無視される。

図５に戻って参照すると、パケット処理回路４０２内に含まれるホスト・インターフェース５４８はパケット処理回路４０２とパケット処理回路４０２に連結されるホスト・システム（例えば図４のＳＴＢ／ＰＶＲ ＳＯＣ４０６）との間の通信用バスとして機能する。或るセットの実施形態では、ホスト・インターフェース５４８を実施するために標準のバス・アーキテクチャを使用できる。使用できる標準のバス・アーキテクチャの例はＰＣＩ、ＶＣＩ、ＰＶＣＩ、ＡＨＢ、ＡＳＢ、ＡＰＢ、カード・バス、ローカル・バスを含む。付け加えると、ＤＤＲ、ＤＤＲ２、ＳＤＲＡＭ、ＳＲＡＭ、ＦＬＡＳＨ ＲＡＭ、ＳＳＲＡＭのようなメモリ・バス・アーキテクチャも使用できる。例として、標準の「ローカル・バス」に関する信号が図２０に示されている。

上記で複数の実施形態が相当詳細に説明されてきたが、イーサネット以外の通信チャネル上でのデータ転送のための他の変形例が可能である。さらに、いったん上記の開示が充分に理解されると、数多くの変形例や改良例が当業者に明らかになるであろう。添付の特許請求項がそのような変形例と改良例すべてを包含すると解釈されることが意図される。本出願明細書に使用されたセクション見出しが単に構成目的のためのものであって、本出願明細書に与えられた説明と添付の特許請求項を限定するように意図されていないことに留意すべきである。

音声映像コンテンツ配信のための先行技術によるクローズド・ネットワーク・モデルを例示する図である。 先行技術による、通常のセットトップボックス／パーソナル・ビデオ・レコーダ・システムを例示する図である。 先行技術による、セットトップボックス／パーソナル・ビデオ・レコーダ・システムのための通常のトランスポート・ストリーム・フローを例示するフロー・チャートである。 パケット処理回路を組み入れるセットトップボックス／パーソナル・ビデオ・レコーダ・システムの一実施形態を例示する図である。 図４のパケット処理回路の一実施形態を例示する図である。 一実施形態によるイーサネットＩＩフレームのフォーマット、および８０２．３フレームのフォーマットを例示する図である。 一実施形態によるネットワーク層プロトコルＩＰヘッダの構造を示す図である。 一実施形態によるトランスポート層プロトコルＴＣＰヘッダの構造、およびトランスポート層プロトコルＵＤＰヘッダの構造を示す図である。 一実施形態によるアプリケーション層プロトコルＲＴＰバージョン２ヘッダの構造を示す図である。 一実施形態によるイーサネット・パケット・ヘッダの例を示す図である。 一実施形態による映像と音声のペイロードのカプセル化の例を示す図である。 一実施形態による論理データ・ストリームのフィルタ処理、およびアプリケーション・データの経路指定の例を示す図である。 一実施形態による論理データ・ストリームのフィルタ処理、およびアプリケーション・データの経路指定の例を示す図である。 一実施形態による図４のパケット処理回路に関する一般的なデータ・フローの経路指定およびフィルタ処理を示す図である。 一実施形態による、ＴＳＩ、ＳＳＩ、またはＭＩへのペイロードに関するデータ・フローを示す図である。 一実施形態による、ＴＳＩ、ＳＳＩ、またはＭＩへのペイロードおよび（複数の）ヘッダに関するデータ・フローを示す図である。 一実施形態による、ＴＳＩへのペイロード、およびＳＳＩまたはＭＩへの（複数の）ヘッダに関するデータ・フローを示す図である。 一実施形態による、ＳＳＩまたはＭＩへの（複数の）ヘッダに関するデータ・フローを示す図である。 一実施形態によるトランスポート・ストリーム信号の定義を示す図である。 一実施形態によるトランスポート・ストリーム信号のタイミングを示す図である。 一実施形態によるローカル・バス信号の定義を示す図である。 フィルタ処理されたパケットがＴＳＩ出力部へ経路指定され、その一方でヘッダが除去される一実施形態を例示する図である。 フィルタ処理されたパケットがＴＳＩ出力部へ経路指定され、その一方でヘッダがホスト受信バッファを経由してホスト・バスへ経路指定される一実施形態を例示する図である。 合致せず、アプリケーションに特化されていないパケットすべてがホスト受信バッファを経由してホスト・インターフェースへ経路指定される一実施形態を例示する図である。 合致しないパケットすべてがホスト受信バッファを経由してホスト・インターフェースへ経路指定され、合致するパケットがホスト受信バッファへ経路指定される一実施形態を例示する図である。

符号の説明

４０１ａ〜４０１ｃ チューナー、４０２ パケット・プロセッサ（パケット処理回路）、５０４，２１０４、２２０４ パケット・フィルタおよびルータ（ＰＦＲ）、５０６ 制御信号バス、５０８ａ〜５０８ｃ、２２０８ａ〜２２０８ｃ、２３０８ｃ、２４０８ａ〜２４０８ｃ 受信バッファ、５１０ａ〜５１０ｄ、２１１０ａ〜２１１０ｄ ＴＳＩバッファ、５４８、２２４８，２３４８ ホスト・インターフェース、５５０、２２５０ ホスト・バス

Claims (21)

1. セントラル・コントローラへ目標を定められたイーサネット・パケットを受信することと、
   前記イーサネット・パケットを、そのイーサネット・パケットに対応する経路指定情報を識別することを含むフィルタ処理することと、
   前記経路指定情報に従ってトランスポート・ストリーム・インターフェース（ＴＳＩ）を経由して前記イーサネット・パケットの少なくとも第１の部分を前記セントラル・コントローラへ経路指定することとを含み、
   前記イーサネット・パケットがイーサネット・プロトコルに従った１つまたは複数のカプセル化ヘッダを含み、前記経路指定情報を識別することが前記１つまたは複数のカプセル化ヘッダから得られる情報を使用して行われ、
   前記ＴＳＩがリアルタイムのデータおよび／または非リアルタイムのデータを転送するように構成されることを特徴とするデータを配信する方法。
2. 前記ＴＳＩが、
   エラー信号と、
   データ有効信号と、
   パケット・クロック信号と、
   トランスポート・ストリーム・データ・バスと、さらに
   オクテット・クロック信号、
   ニブル・クロック信号、
   ビット・クロック信号のうちの１つを含む専用のインターフェースであって、
   前記トランスポート・ストリーム・データ・バスが、
   ８ビットのトランスポート・ストリーム、
   ４ビットのトランスポート・ストリーム、
   シリアル・トランスポート・ストリームのうちの１つまたは複数を転送するように構成される、請求項１に記載の方法。
3. 前記経路指定情報を識別する前記が第１の行き先ポートを識別することを含み、前記ＴＳＩを経由して前記イーサネット・パケットの少なくとも第１の部分を前記セントラル・コントローラへ経路指定することが、前記ＴＳＩを経由して前記イーサネット・パケットの少なくとも前記第１の部分を前記第１の行き先ポートへ経路指定することを含む、請求項１に記載の方法。
4. 前記カプセル化ヘッダが、
   ＭＡＣヘッダと、
   ＩＰヘッダ情報と、
   ＴＣＰヘッダ情報、ＵＤＰヘッダ情報のうちの１つまたは複数を含むトランスポート層ヘッダと、
   ＨＴＴＰヘッダ情報、ＲＴＰヘッダ情報、ＲＴＳＰヘッダ情報、ＦＴＰヘッダ情報、ＴＦＴＰヘッダ情報のうちの１つまたは複数を含むアプリケーション層ヘッダと
   とを有する、請求項１に記載の方法。
5. 前記受信、前記フィルタ処理、前記経路指定が複数のイーサネット・パケットに関して遂行される、請求項１に記載の方法。
6. ホスト・コントローラへ目標を定められたデータ・パケットを受信するように構成されたコントローラ回路と、
   前記コントローラ回路の出力部に連結されるように構成された入力部を備えたルータ回路とを有し、前記ルータ回路が各々のデータ・パケットをフィルタ処理し、かつ前記データ・パケットに対応するそれぞれの経路指定情報を得るように動作可能であり、さらに第１のインターフェースを介して、前記データ・パケットに対応する前記それぞれの経路指定情報に従って各々のデータ・パケットの少なくとも第１の部分を前記ホスト・コントローラへ経路指定するように動作可能であり、
   各々のデータ・パケットがそれぞれのヘッダ情報を含み、前記それぞれの経路指定情報が前記それぞれのヘッダ情報から得られ、
   前記第１のインターフェースがリアルタイムのデータおよび／または非リアルタイムのデータを転送するように構成されることを特徴とするデータを配信するシステム。
7. 行き先ポートの第１のセットに対応する前記第１のインターフェースが、出力部と、前記ルータ回路の出力部に結合するように構成された入力部とを有し、
   前記システムが、前記ルータ回路のＩ／Ｏ接続部に結合するように構成された第１のＩ／Ｏ接続部を有する、行き先ポートの第２のセットに対応する第２のインターフェースをさらに有し、
   前記ルータ回路がさらに、
   前記それぞれの経路指定情報が行き先ポートの前記第１のセットを示していれば、前記第１のインターフェースを経由して各々のデータ・パケットの少なくとも前記第１の部分を前記ホスト・コントローラへ経路指定し、かつ
   前記それぞれの経路指定情報が行き先ポートの前記第２のセットを示していれば、前記第２のインターフェースを経由して前記データ・パケットの少なくとも前記第１の部分を前記ホスト・コントローラへ経路指定するように動作可能である、請求項６に記載のシステム。
8. 前記ルータ回路の前記出力部に結合するように構成された入力部と前記第１のインターフェースの前記入力部に結合するように構成された出力部とを各々が有する１つまたは複数の第１のバッファであって、前記ルータ回路がさらに各々のデータ・パケットを１つまたは複数の前記第１のバッファの中に保存し、かつ前記第１のインターフェースを介して前記データ・パケットを保持する前記１つまたは複数の前記第１のバッファから前記ホスト・コントローラへ各々のデータ・パケットの前記第１の部分を経路指定するように動作可能である第１のバッファ、および
   前記ルータ回路の前記Ｉ／Ｏ接続部に結合するように構成された第１のＩ／Ｏ接続部と前記第２のインターフェースのＩ／Ｏ接続部に結合するように構成された第２のＩ／Ｏ接続部を有する１つまたは複数の第２のバッファであって、前記ルータ回路がさらに各々のデータ・パケットを１つまたは複数の前記第２のバッファの中に保存し、かつ前記第２のインターフェースを介して前記データ・パケットを保持する前記１つまたは複数の前記第２のバッファから前記ホスト・コントローラへと各々のデータ・パケットの前記第１の部分を経路指定するように動作可能である第２のバッファ
   の１つまたは複数をさらに有する、請求項７に記載のシステム。
9. 前記経路指定情報が第１の行き先ポートを示し、
   前記第１のインターフェースを経由して各々のデータ・パケットの少なくとも前記第１の部分を前記ホスト・コントローラへ経路指定する過程で、前記第１のポートが行き先ポートの前記第１のセットの中に含まれ、
   前記第２のインターフェースを経由して各々のデータ・パケットの少なくとも前記第１の部分を前記ホスト・コントローラへ経路指定する過程で、前記第１のポートが行き先ポートの前記第２のセットの中に含まれる、請求項７に記載のシステム。
10. 前記経路指定情報がさらに第２の行き先ポートを示し、前記ルータ回路がさらに、
    前記第２の行き先ポートがポートの前記第１のセットに含まれる場合に前記第１のインターフェースを経由して前記データ・パケットの少なくとも第２の部分を前記ホスト・コントローラへ経路指定し、
    前記第２の行き先ポートがポートのポートの前記第２のセットに含まれる場合に前記第２のインターフェースを経由して前記データ・パケットの少なくとも第２の部分を前記ホスト・コントローラへ経路指定するように動作可能である、請求項９に記載のシステム。
11. 前記コントローラ回路が、前記第２のインターフェースの第２のＩ／Ｏ接続部に結合された第２のＩ／Ｏ接続部をさらに有し、それにより、前記コントローラ回路と前記第２のインターフェースの間にＩ／Ｏ経路を確立し、前記コントローラ回路がさらに前記Ｉ／Ｏ経路上で前記第２のインターフェースを経由して、各々のデータ・パケットに対応するそれぞれのリアルタイムの状態／制御情報を前記ホスト・コントローラへ経路指定するように動作可能である、請求項７に記載のシステム。
12. 前記コントローラ回路がイーサネット制御装置を有し、前記データ・パケットがイーサネット・パケットを含み、前記イーサネット・パケットが、
    多数の転送速度をサポートする単一で有線のイーサネット接続と、
    多数の転送速度をサポートする単一で無線のイーサネット接続のいずれか一方で前記イーサネット制御装置によって受信される、請求項６に記載のシステム。
13. 前記第２のインターフェースが、
    ＰＣＩ、ＶＣＩ、ＰＶＣＩ、ＡＨＢインターフェース、ＡＳＢインターフェース、ＡＰＢインターフェース、カード・バス・インターフェース、ローカル・バス・インターフェース、ＣＰＵホスト・バス・インターフェースのうちの１つを含む共用システム・インターフェースと、
    ＤＤＲインターフェース、ＤＤＲ２インターフェース、ＳＤＲＡＭインターフェース、ＳＲＡＭインターフェース、Ｆｌａｓｈ ＲＡＭインターフェースのうちの１つを含むメモリ・インターフェースと
    のいずれか一方を有する、請求項１２に記載のシステム。
14. 各々のデータ・パケットがさらにペイロード・データを含む、請求項６に記載のシステム。
15. 前記ペイロード・データが音声コンテンツおよび／または映像のコンテンツを含み、前記データ・パケットの前記第１の部分が前記ペイロード・データである、請求項１４に記載のシステム。
16. 前記ルータ回路がさらに、前記それぞれのヘッダ情報を含む前記データ・パケットがリアルタイムの接続で前記コントローラ回路によって受信されれば、前記それぞれのヘッダ情報にタイムスタンプ・データを追加するように動作可能である、請求項１４に記載のシステム。
17. 前記リアルタイムの接続が、
    ＲＴＰと、
    ＲＴＣＰのうちの一方を利用する、請求項１６に記載のシステム。
18. 前記ルータ回路がさらに、前記経路指定情報が得られるとすぐに、かつ前記データ・パケットが全部受信され終わる前に、前記データ・パケットの前記第１の部分の経路指定を開始するように動作可能である、請求項６に記載のシステム。
19. 集積回路である、請求項６に記載のシステム。
20. 入力部、出力部、およびＩ／Ｏ接続部を有するシステム・オン・チップ（ＳＯＣ）コントローラをさらに含み、
    前記コントローラ回路が、第１のＩ／Ｏ接続部と出力部を有し、かつ前記第１のＩ／Ｏ接続部で前記データ・パケットを受信するように動作可能であるイーサネット制御装置を含み、各々のデータ・パケットが前記ＳＯＣコントローラへ目標を定められたイーサネット・パケットを含み、
    前記ルータが、各々のイーサネット・パケットに対応するそれぞれの第１の行き先ポートを識別するように動作可能であり、前記ルータ回路が出力部とＩ／Ｏ接続部をさらに有し、
    前記システムがさらに、
    前記ルータ回路の前記出力部に結合した入力部を含み、かつ前記ＳＯＣコントローラの前記入力部のうちの第１の入力部に結合した出力部をさらに含む専用のＴＳＩであって、行き先ポートの第１のセットに対応するＴＳＩと、
    前記ルータ回路の前記Ｉ／Ｏ接続部に結合した第１のＩ／Ｏ接続部を含み、かつ前記ＳＯＣコントローラの前記Ｉ／Ｏ接続部の第１の接続部に結合した第２のＩ／Ｏ接続部をさらに含む第２のインターフェースであって、行き先ポートの第２のセットに対応する第２のインターフェースを含み、
    前記ルータ回路がさらに、
    前記第１の行き先ポートがポートの前記第１のセットに含まれる場合に前記ＴＳＩを経由して各々のイーサネット・パケットの少なくとも前記第１の部分を前記ＳＯＣコントローラへ経路指定し、
    前記第１の行き先ポートがポートの前記第２のセットに含まれる場合に前記第２のインターフェースを経由して各々のイーサネット・パケットの少なくとも前記第２の部分を前記ＳＯＣコントローラへ経路指定するように動作可能であり、
    前記ＳＯＣコントローラが、各々のイーサネット・パケットの前記経路指定された第１の部分を処理し、それによって目標のデータを入手し、前記目標のデータを１つまたは複数の目標のデバイスへと供給するように動作可能である、請求項６に記載のシステム。
21. 前記１つまたは複数の目標のデバイスが、
    １つまたは複数の音声用デジタル／アナログ変換器（ＤＡＣ）と、
    １つまたは複数の映像用ＤＡＣのうちの１つまたは複数とを有する、請求項２０に記載のシステム。

Images