JP2008530830A - ゲートウェイサーバにおける受信リソース割り当て方法及びシステム - Google Patents

Abstract

開示した実施形態は、ゲートウェイサービスデバイスにおける効率的なやり方でリソースを割り当てる方法と装置に関する。装置は、複数のエンドユーザ端末（２２ａ−２２ｎ）に接続されたゲートウェイサーバまたはヘッドエンドユニット（１４ａ、ｂ）を含む。ゲートウェイサーバ（１４ａ、ｂ）は、エンドユーザ端末（２２ａ−２２ｎ）にサービスを提供するために使用する受信リソースの割り当てを管理するコントローラ（７０）を含む。方法は、サービス要求を受信し（３０４）、その要求をすでに使用中のサービスと比較し（３０８）、一致すれば、エンドユーザ端末（２２ａ−２２ｎ）にサービスに関する新しい情報を含む更新されたデータストリームを提供する（３１４）ことを含む。

Description

本発明は、複数の受信リソースを含むゲートウェイサーバに、リソース保存方法に基づきこれらのリソースをクライアントに動的に割り当てさせることに関する。

このセクションの目的は、以下に説明して特許を請求する本発明の様々な態様に関連する技術の様々な側面を読者に紹介することである。この説明により、本発明の様々な態様の理解を容易にする背景情報を読者に提供する役に立つと思われる。従って、言うまでもなくこれらの記載は上記を考慮して読むべきであり、先行技術として認める（ａｄｍｉｓｓｉｏｎｓ ｏｆ ｐｒｉｏｒ ａｒｔ）ものではない。

周知の通り、ディレクＴＶ等の衛星テレビシステムはここ数年で非常に普及した。実際、１９９４年にディレクＴＶが始まって以来、米国の１２００万世帯が衛星テレビの受信契約をしている。受信契約者のほとんどは一戸建て住宅に住んでおり、衛星放送受信アンテナを設置して配線するのは比較的容易である。例えば、衛星放送受信アンテナを住宅の屋根に設置できる。

しかし多数の潜在的受信契約者は、ホテルや高層アパート等の集合住宅（ＭＤＵ）に住んでいるか仮住まいしている。残念ながらＭＤＵ内の個々の住戸に衛星テレビサービスを提供するには別の課題がある。住戸ごとに１つの衛星受信用アンテナを設けて配線をすることは現実的ではないし、非常に高いコストがかかる。例えば、１０００戸が入った高層アパートでは、建物の屋根に１０００個の衛星受信用アンテナを設置することは現実的ではない。従来のシステムではこれらの問題を回避するために、デジタル衛星テレビジョン信号をアナログ信号に変換する。そのアナログ信号は１本の同軸ケーブルを介して複数の住戸に送信できる。しかし、これらのシステムでは、提供できるチャンネル数が制限され、完全にデジタルのシステムと比較して品質が低下してしまい、一戸建て住宅に住むユーザがいつも経験しているような衛星テレビを経験させることができない。

ＭＤＵの個別住戸に衛星信号等のサービスを直接配信すれば、一戸建て住宅と同様の経験を提供できるが、やっかいな問題が発生することがある。例えば、アンテナ（ｄｉｓｈ）から衛星信号を配信するには、特別な配信器と配線が必要であり、これらはＭＤＵの施設には無いことが多い。施設を改装するためのコストは莫大である。

離れた場所に配置された信号受信用の専用リソースを用いて各住戸がサービスを受けるシステムを作ることも可能である。例えば、メインの同調機能を中央制御室に配置し、他と異なる信号（ｕｎｉｑｕｅ ｓｉｇｎａｌ）すなわちサービスを各住戸に送信することができる。この接続は建物中に張り巡らされたイーサネットまたは同軸ケーブルを用いてできる。一般的に、ビデオコンテンツを配信するシステムの場合、各エンドユーザは自分自身の専用同調・復号回路を持たなければならない。これにはコストがかかり効率もよくなく、特に大きなＭＤＵの施設の場合にはそうである。

それゆえ、望ましいことは、中央に配置される受信リソースとして使用される回路の数を減らせる（ｌｉｍｉｔ）システムを開発することである。さらに、動作性能を最大化してコストを最小化するために、同調リソースを管理するソリューションであって、システム中の最小数の同調リソースを使用するものが望ましい。

開示する実施形態は、受信リソースの割り当て方法及び装置に関する。その装置は、複数の信号を受信して一連のデータストリームを出力するヘッドエンドすなわちゲートウェイサーバユニットを含む。その一連のデータストリームはＭＤＵ等の施設内に配置された複数のＳＴＢに供給される。本装置はさらに、ヘッドエンドユニット内の一組の受信リソースと、要求信号を受信するレシーバと、その要求信号を処理し受信リソースの使用を管理するコントローラとを含む。その方法は、ヘッドエンドユニットにより使用される受信リソースを割り当て、ＳＴＢにより要求されたサービスを提供するプロセスを含む。前記方法は、さらに、ＳＴＢからサービスの要求信号を受信する段階と、このサービス要求をすでに提供されているサービスと比較する段階と、新しく要求されたサービスと現在提供されているサービスとが一致した場合、前記要求されたサービスをすでに提供している前記受信リソースの１つの共同使用を確立する段階とを含む。

本発明の有利性は図面を参照して以下の詳細な説明を読めば明らかとなるであろう。

本発明の特徴と有利性は、例として与えられた以下の説明から明らかになるであろう。

本発明の１つ以上の実施形態を以下に説明する。これらの実施形態を簡潔に説明するため、本明細書において実際の実施形態の特徴のすべては説明しない。言うまでもなく、かかる実際の実施形態の開発において、いかなる技術開発及び設計のプロジェクトと同様に、実施形態に特有の多数の決定をして、システム関係の制約及びビジネス関係の制約に沿った開発者の目的を達成しなければならない。これらの制約は実施形態ごとに変化する。さらに、言うまでもなく、かかる開発の手間は複雑であり時間がかかるが、それでもやはり、本開示の利益にあずかる当業者にとっては設計、製造、生産をするルーティンであろう。

図１を参照して、一実施形態による衛星テレビジョン・オーバーＩＰの一例を示すブロック図が示され、広く参照数字１０により指示されている。図示したように、システム１０は、１つ以上の衛星受信用アンテナ１２ａ乃至１２ｍ、衛星ゲートウェイ１４等のヘッドエンドユニットすなわちゲートウェイサーバ、ＩＰ配信ネットワーク２０、１つ以上のセットトップボックス（ＳＴＢ）２２ａ乃至２２ｎを含む。これらのセットトップボックスはエンドユーザ装置として機能する。しかし、図１に示したシステムの実施形態がシステム１０の単なる一実施形態であることが、当業者には明らかであろう。であるから、代替的な実施形態では、図示したシステム１０のコンポーネントを配置し直してもよいし省略してもよい。また、システム１０に別のコンポーネントを追加してもよい。例えば、小さな修正を加えて、システム１０の構成を衛星のものでないビデオとオーディオのサービスを配信するようにしてもよい。

衛星受信用アンテナ１２ａ乃至１２ｍは、地球を廻っている衛星から送信されたビデオ、オーディオ、その他のテレビジョン関係のデータを受信するように構成してもよい。以下に詳しく説明するように、一実施形態では、衛星受信用アンテナ１２ａ乃至１２ｍは、１０．７乃至１２．７５ギガヘルツ（ＧＨｚ）のＫｕバンドのディレクＴＶの放送（ｐｒｏｇｒａｍｍｉｎｇ）を受信するように構成されている。しかし、別の実施形態では、衛星受信用アンテナ１２ａ乃至１２ｍは、他のタイプの直接放送衛星を受信したり、ディッシュネットワーク（Ｄｉｓｈ Ｎｅｔｗｏｒｋ）信号、エクスプレスビュー（ｅｘｐｒｅｓｓＶｕ）信号、スターチョイス（ＳｔａｒＣｈｏｉｃｅ）信号等のテレビジョン受信専用（ＴＶＲＯ）信号を受信したりしてもよい。衛星ベースでない他のシステムでは、衛星受信用アンテナ１２ａ乃至１２ｍはシステム１０には無くてもよい。

一実施形態では、衛星受信用アンテナ１２ａ乃至１２ｍ内の低ノイズブロックコンバータ（ＬＮＣ）が地球を廻っている衛星からの入来信号を受信し、この入来信号を９５０乃至２１５０メガヘルツ（ＭＨｚ）間のＬバンド中の周波数に変換する。図２を参照してさらに詳しく説明するが、衛星受信用アンテナ１２ａ乃至１２ｍの各々は、一周波数（トランスポンダと呼ばれる）上の偏光（ｐｏｌａｒｉｚａｔｉｏｎ）した１つ以上の入来信号を受信し、これらの衛星信号をＬバンド信号またはトランスポートストリームに変換するように構成されている。各Ｌバンド信号またはトランスポートストリームは、それ自体が１つの番組のトランスポートストリーム（一組の単一番組トランスポートストリーム（ＳＰＴＳ）の１つと呼ばれることが多い）を表すか、または、多重化された複数のトランスポートストリーム（複数番組トランスポートストリーム（ＭＰＴＳ）と呼ばれることが多い）を表す。各番組ストリームが順次、オーディオ信号及び／またはビデオ信号を表してもよい。また、ＳＰＴＳの各々は、ＭＰＴＳに含まれる異なるストリームを区別するために使用でき、ＳＰＴＳでも使用できる番組識別子（ＰＩＤ）等である識別子（ａ ｆｏｒｍ ｏｆ ｉｄｅｎｔｉｆｉｅｒ）を含んでもよい。

衛星受信用アンテナ１２ａ乃至１２ｍは、ヘッドエンドユニットまたはゲートウェイサーバ（例えば衛星ゲートウェイ１４）にＬバンド信号を送信するように構成できる。あるいは、非衛星の実施形態では、ヘッドエンドユニットはケーブルテレビジョンレシーバ、高精細度テレビジョンレシーバ、またはビデオ配信システムであってもよい。

衛星ゲートウェイ１４は、衛星同調・復調・逆多重モジュール１６と、インターネットプロトコル（ＩＰ）ラッパーモジュール１８とを含む。モジュール１６は複数の受信リソースを含み、その受信リソースは同調器、復調器、及び逆多重器を含んでおり、衛星１２ａ乃至１２ｍから伝送された変調され多重化されたＬバンド信号を複数のデータストリーム（ＳＰＴＳ）に変換する。各データストリームはサービス（例えば、テレビジョンチャンネルビデオ、テレビジョンチャンネルオーディオ、プログラムガイド等）を担っている。一実施形態では、モジュール１６は、衛星受信用アンテナ１２ａ乃至１２ｍにより受信されたＬバンド信号の大きなグループから特定のＬバンド信号を受信するように構成される。モジュール１６は、これらの信号を処理して、モジュール１６が受信したすべてのサービスの新しい単一の番組トランスポートストリームを作成する。しかし、別の実施形態では、モジュール１６は、衛星受信用アンテナ１２ａ乃至１２ｍが受信したサービスの全部または一部のみのトランスポートストリームを作成できる。

ここで説明している受信リソースは、同調器、復調器、逆多重器等の回路を含み、これらの回路が同調、復調、逆多重等の機能を果たすが、これらの受信リソースは、デジタル手段を含むその他の手段により入来信号を分離または処理する機能を実施してもよいし、異なる時間スロットまたは別の入力ケーブルで受信した処理信号を処理してもよい。これらの機能をモジュール１６で実施してもよい。

衛星同調・復調・逆多重モジュール１６は、ＳＰＴＳをＩＰラッパー（ＩＰ ｗｒａｐｐｅｒ）モジュール１８に伝送してもよい。一実施形態では、ＩＰラッパーモジュール１８は、ＳＰＴＳ中のデータを、ＩＰ配信ネットワーク２０を介した伝送に適した複数のＩＰパケットにパッケージしなおす（ｒｅｐａｃｋａｇｅｓ）。例えば、ＩＰラッパーモジュール１８は、ＳＰＴＳ中のディレクＴＶプロトコルパケットをＩＰパケットに変換できる。また、ＩＰラッパーモジュール１８は、ＳＴＢ２２ａ乃至２２ｎからサーバ要求を受信し、サービスを要求したＳＴＢ２２ａ乃至２２ｎにＩＰ ＳＰＴＳをマルチキャスト（すなわち、ＩＰアドレスを介して１つ以上のＳＴＢ２２ａ乃至２２ｎにブロードキャスト）する。

別の実施形態では、ＩＰラッパーモジュール１８は、ＳＴＢ２２ａ乃至２２ｎにより要求されていないサービスのＩＰ ＳＰＴＳをマルチキャストするように構成することもできる。例えば、受信リソースは５つのＳＰＴＳを出力するが、そのＳＰＴＳの１つだけが実際には要求されている。しかし、このサービスを提供する要件に関係する理由から、もう１つのＳＰＴＳはマルチキャストＩＰである。留意すべきことは、モジュール１６と１８は、衛星ゲートウェイ１４の単なる実施例であることである。別の実施形態では、図２と図３を参照して以下に説明するように、モジュール１６と１８の機能は様々な好適なコンポーネントまたはモジュール間に再配信されても集約されてもよい。

ＩＰ配信ネットワーク２０は、１つ以上のルータ、スイッチ、モデム、スプリッタ、またはブリッジを含む。例えば、一実施形態では、衛星ゲートウェイ１４は主配線盤（ＭＤＦ）に結合され、その主配線盤は中間配線盤（ＩＤＦ）に結合され、その中間配線盤は同軸・イーサネットブリッジに結合され、その同軸・イーサネットブリッジはルータに結合され、そのルータは１つ以上のＳＴＢ２２ａ乃至２２ｎに結合される。他の実施形態では、ＩＰ配信ネットワーク２０は、デジタル加入者線アクセス多重化器（ＤＳＬＡＭ）に結合された主配線盤であり、そのデジタル加入者アクセス多重化器はＤＳＬモデムに結合され、そのＤＳＬモデムはルータに結合されている。さらに別の実施形態では、ＩＰ配信ネットワークは、８０２．１１やＷｉＭａｘネットワーク等の無線ネットワークを含む。この種の実施形態では、ＳＴＢ２２ａ乃至２２ｎはマルチキャストＩＰパケットを受信するように構成された無線レシーバを含む。当業者には言うまでもないが、上記の実施形態は単なる実施例である。であるから、別の実施形態において、多数の好適なＩＰ配信ネットワークの形態をシステム１０で使用することができる。

ＩＰ配信ネットワーク２０は、１つ以上のＳＴＢ２２ａ乃至２２ｎに結合され得る。ＳＴＢ２２ａ乃至２２ｎは、ＩＰ配信ネットワーク２０を介してＩＰ ＳＰＴＳ等のＩＰパケットを受信できるビデオレシーバ、オーディオレシーバ及び／またはその他の好適なデータレシーバである。言うまでもなくＳＴＢという用語は、ここではテレビの上に設置される装置以外も含み得る。むしろ、ＳＴＢ２２ａ乃至２２ｎは、住居のエンドユーザ装置として動作するいかなる装置でもよく、テレビ、ディスプレイ、またはコンピュータの内部または外部のいずれであってもよく、本願で説明したように機能するように構成され得る。ビデオコンポーネント、コンピュータ、無線電話、その他のビデオレコーダを含むが、これらに限定はされない。一実施形態では、ＳＴＢ２２ａ乃至２２ｎは、（入力ポート中の）イーサネットポートを介してビデオ及び／またはオーディオ等のサービスを受信するように構成されたディレクＴＶレシーバであってもよい。別の実施形態では、ＳＴＢ２２ａ乃至２２ｎは、同軸ケーブル、ツイストペア線、銅線、または（ＩＥＥＥ８０２．１１標準規格等の無線標準規格を介して）空中線を介してマルチキャスト伝送を受信するように設計及び／または構成されている。

上述のとおり、システム１０は、宇宙空間の衛星により送信されたビデオ、オーディオ、及び／またはその他のデータを受信し、ＩＰ配信ネットワーク２０を介して配信するためにこのデータを処理／変換する。ここで図２を参照して、ＩＰシステム１０を介した衛星テレビジョンの他の実施形態を示している。各衛星受信アンテナ１２ａ乃至１２ｍは、軌道を回る１つ以上の衛星からの信号を受信するように構成されている。当業者には言うまでもなく、衛星及びその衛星から送信される信号は、その衛星がある軌道スロットにより呼ばれることが多い。例えば、衛星受信用アンテナ１２ａは、１０１度の軌道スロットに配置されたディレクＴＶからの信号を受信するように構成されている。同様に、衛星受信用アンテナ１２ｂは、１１９度に配置された衛星からの信号を受信し、衛星受信用アンテナ１２ｃは、１１０度の軌道スロットに配置された衛星からの信号を受信する。言うまでもなく、別の実施形態では、衛星受信用アンテナ１２ａ乃至１２ｃは、９５度軌道スロット等の様々な軌道スロットに配置された他の複数の衛星からの信号を受信し得る。また、衛星受信用アンテナ１２ａ乃至１２ｃは、偏光した衛星信号を受信するように構成してもよい。例えば、衛星受信用アンテナ１２ａは、左偏光（図中、１０１Ｌ）と右偏光（図中、１０１Ｒ）の信号を受信するように構成してもよい。

図１を参照して説明したように、衛星受信用アンテナ１２ａ乃至１２ｃは、ＫＵバンドで衛星信号を受信して、それをＬバンド信号に変換して、衛星ゲートウェイ１４に送信する。しかし、一部の実施形態では、衛星ゲートウェイ１４に届く前に、衛星受信用アンテナ１２ａ−１２ｃで作られたＬバンド信号を結合して少ない信号にしても、分割して多い信号にしてもよい。例えば、図２に示したように、衛星受信用アンテナ１２ｂと１２ｃからのＬバンド信号を、スイッチ２４で、１１０度衛星と１１９度衛星からの左偏光ストリームの両方からのトランスポートストリームを含む単一のＬバンド信号に結合してもよい。

システム１０は、複数の１：２スプリッタ２６ａ、２６ｂ、２６ｃ、２６ｄも含み、衛星受信アンテナ１２ａ−１２ｃから伝送されたＬバンド信号を２つのＬバンド信号に分割する。その２つのＬバンド信号の各々は、分割される前のトランスポートストリームのサービスの半分を含む。別の実施形態では、１：２スプリッタ２６ａ−２６ｂは省略されても、衛星ゲートウェイ１４ａと１４ｂに組み込まれてもよい。

新しく分割されたＬバンド信号は、１：２スプリッタ２６ａ−２６ｄから衛星ゲートウェイ１４ａと１４ｂに伝送される。図２に示すシステム１０の実施形態は、２つの衛星ゲートウェイ１４ａと１４ｂを含む。しかし、別の実施形態では、システム１０が含む衛星ゲートウェイ１４の数は好適であればいくつでもよい。例えば、一実施形態では、システムは３つの衛星ゲートウェイ１４を含み得る。

衛星ゲートウェイ１４ａと１４ｂは、そのＬバンド信号をさらに分割し、受信リソースを用いて、そのＬバンド信号の１つ以上のサービスに同調し、１つ以上のＳＰＴＳを作成する。そのＳＰＴＳはＩＰパケットに再度パッケージ化され、ＩＰ配信ネットワーク２０を介してマルチキャストされる。また、１つ以上の衛星ゲートウェイ１４ａと１４ｂは、公衆交換電話網（ＰＳＴＮ）と結合され得る。衛星ゲートウェイ１４ａと１４ｂはＰＳＴＮ２８と結合しているので、ＳＴＢ２２ａ−２２ｎはＩＰ配信ネットワーク２０と衛星ゲートウェイ１４ａと１４ｂとを介して衛星サービスプロバイダと通信することができる。この機能により、有利にも、各個別ＳＴＢ２２ａ−２２ｎをＰＳＴＮ２８に直接結合する必要は無くなる。

ＩＰ配信ネットワーク２０はインターネットサービスプロバイダ（ＩＳＰ）３０と結合していてもよい。一実施形態では、ＩＰ配信ネットワーク２０を利用して、高速データアクセス等のインターネットサービスを、ＳＴＢ２２ａ−２２ｎ及び／または（ＩＰ配信ネットワークに結合されている）その他の好適なデバイス（図示せず）に提供する。

上記の通り、衛星ゲートウェイ１４ａ、ｂは複数のＬバンド信号を受信するように構成され、複数のＳＰＴＳを作成し、ＩＰ配信ネットワーク２０を介して要求されたＳＰＴＳをマルチキャストすることができる。図３を参照して、衛星ゲートウェイ１４の一例のブロック図を示した。図示したように、衛星ゲートウェイ１４ａと１４ｂは、パワーサプライ４０と、２つのフロントエンド４１ａ、４１ｂと、バックエンド５２とを含む。パワーサプライ４０は、いくつかの業界標準のＡＣまたはＤＣのパワーサプライの１つであり、フロントエンド４１ａ、ｂとバックエンド５２に下記の機能を実行させるように構成することができる。

衛星ゲートウェイ１４ａ、ｂは、２つのフロントエンド４１ａ、ｂも含む。一実施形態では、フロントエンド４１ａ、ｂの各々は、１：２スプリッタ２６ａ−２６ｄから２つのＬバンド信号入力を受信するように構成されている。この１：２スプリッタ２６ａ−２６ｄは、図２を参照して説明したものである。例えば、フロントエンド４１ａは１：２スプリッタ２６ａから２つのＬバンド信号を受信し、フロントエンド４１ｂは１：２スプリッタ２６ｂから２つのＬバンド信号を受信する。一実施形態では、フロントエンド４１ａ、ｂへのＬバンド入力の各々は８つ以下のサービスを含む。

フロントエンド４１ａ、ｂは、１：４Ｌバンドスプリッタ４２ａ、４２ｂ、４２ｃ、４２ｄを用いてＬバンド入力を再分割する。再分割すると、Ｌバンド信号はデュアルチューナリンクの４つのバンク４４ａ、４４ｂ、４４ｃ、４４ｄに通される。バンク４４ａ−４４ｄ中のデュアルチューナリンクの各々は、そのデュアルチューナリンクが受信したＬバンド信号内の２つのサービスに同調して、ＳＰＴＳを作成するように構成されている。各デュアルチューナリンクは、そのＳＰＴＳを、低電圧差動シグナリング（ＬＶＤＳ）ドライバ４８ａ、４８ｂ、４８ｃ、４８ｄの１つに送る。ＬＶＤＳドライバ４８ａ−４８ｄは、バックエンド５２に伝送するため、トランスポート信号を増幅するように構成されている。別の実施形態では、ＬＶＤＳドライバ４８ａ−４８ｄの替わりに、別のドライバ及び／またはアンプを使用することもできる。他の実施形態では、バックエンド５２へのルーティングのために、すべてのトランスポート信号を一緒にシリアライゼーションする。

図示したように、フロントエンド４１ａ、ｂはマイクロプロセッサ４６ａ、４６ｂも含む。一実施形態では、マイクロプロセッサ４６ａ、ｂは、デュアルチューナリンクのバンク４４ａ−４４ｄと、１：４Ｌバンドスプリッタ４２ａ−４２ｄを制御し、及び／またはコマンドを中継する。マイクロプロセッサ４６ａ、ｂは、ＳＴマイクロエレクトロニクスが製造したＳＴ１０マイクロプロセッサであってもよい。他の実施形態では、別のプロセッサを使用してもよいし、バックエンド５２中のプロセッサからの制御を受けてもよい。マイクロプロセッサ４６ａ、ｂはＬＶＤＳレシーバ及びトランスミッタモジュール５０ａと５０ｂに結合されている。ＬＶＤＳレシーバ／トランスミッタモジュール５０ａ、ｂは、以下に説明するように、マイクロプロセッサ４６ａ、ｂとバックエンド５２の構成要素との間の通信を容易にする。

次にバックエンド５２について、バックエンド５２はＬＶＤＳレシーバ５４ａ、５４ｂ、５４ｃ、及び５４ｄを含む。これらのレシーバは、ＬＶＤＳドライバ４８ａ−４８ｄにより送信されたＳＰＴＳまたはＭＰＴＳ等のトランスポートストリーム信号を受信するように構成されている。バックエンド５２は、ＬＶＤＳレシーバ／トランスミッタモジュール５６ａと５６ｂも含む。これらのモジュールはＬＶＤＳレシーバ／トランスミッタモジュール５０ａと５０ｂと通信するように構成されている。

図示したように、ＬＶＤＳレシーバ５４ａ−５４ｄとＬＶＤＳレシーバ／トランスミッタ５６ａ、ｂは、コントローラまたはトランスポートプロセッサ５８ａ、５８ｂと通信するように構成されている。一実施形態では、トランスポートプロセッサ５８ａ、ｂは、フロントエンド４１ａ、ｂのデュアルチューナリンクにより作成されたＳＰＴＳを受信するように構成されている。例えば、トランスポートプロセッサ５８ａ、ｂは１６個のＳＰＴＳを作成するように構成され得る。一般的に、トランスポートプロセッサ５８ａ、ｂはＮ個のＳＰＴＳを作成することができる。ここで、Ｎは、トランスポートプロセッサ５８ａ、ｂへの入力において利用可能な個々の番組ストリーム数以下の数である。トランスポートプロセッサ５８ａ、ｂは、ＳＰＴＳを、ＩＰ配信ネットワーク２０を介してマルチキャストできるＩＰパケットに再度パケット化するように構成してもよい。例えば、トランスポートプロセッサ５８ａ、ｂは、ディレクＴＶプロトコルパケットをＩＰプロトコルパケットに再度パッケージ化し、このＩＰパケットを１つ以上のＳＴＢ２２ａ−２２ｎにマルチキャストする。

トランスポートプロセッサ５８ａ、ｂは、バス６２に結合している。このバス６２は、例えば、３２ビット、６６ＭＨｚのＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ）バスである。バス６２を介して、トランスポートプロセッサ５８ａ、ｂは、他のコントローラ、ネットワークプロセッサ７０、イーサネットインターフェイス８４、及び／または拡張スロット６６と通信することができる。ネットワークプロセッサ７０は、ＳＴＢ２２ａ−２２ｎからサービスに対する要求を受信し、トランスポートプロセッサ５８ａ、ｂに命令してその要求されたサービスをマルチキャストするように構成されている。また、ネットワークプロセッサ７０は、これらのサービスの動作及び配信を管理するが、その管理は、ＳＴＢ２２ａ−２２ｎから要求を受信して、現在利用されているサービスのリストを保持し、これらのサービスをＳＴＢ２２ａ−２２ｎに提供するために受信リソースのマッチングまたは割り当てをすることにより行う。一実施形態では、ネットワークプロセッサはインテル社性のＩＸＰ４２５ネットワークプロセッサである。図示はしていないが、ネットワークプロセッサ７０は、衛星ゲートウェイ１４ａ、ｂのフロントパネルに状態データを送信し、またはデバッグポートを介して衛星ゲートウェイ１４ａ、ｂのデバッグまたは監視をサポートするように構成されている。

図示したように、トランスポートプロセッサ５８ａ、ｂは、バス６２を介して、イーサネットインターフェイス６８に結合している。一実施形態では、イーサネットインターフェイス６８はギガビットイーサネットインターフェイスである。このギガビットイーサネットインターフェイスは、ＩＰ配信ネットワークに銅線または光ファイバーのインターフェイスのいずれかを提供する。他の実施形態では、デジタルホームネットワークアプリケーションで使用されるような他のインターフェイスを使用してもよい。また、バス６２は、ＰＣＩ拡張スロット等の拡張スロットに結合され、衛星ゲートウェイ１４ａ、ｂのアップグレードまたは拡張を可能としてもよい。

トランスポートプロセッサ５８ａ、ｂはホストバス６４に結合されてもよい。一実施形態では、ホストバス６４は、トランスポートプロセッサ５８ａ、ｂをモデム７２に接続する１６ビットのデータバスである。上述のように、このモデム７２は、ＰＳＴＮ２８を介して通信するように構成されている。別の実施形態において、モデム７２はバス６２にも結合している。

ネットワークプロセッサ７０は、ゲートウェイ１４ａ、ｂの動作の様々な態様に関する情報を格納するメモリも含んでいる。そのメモリは、図示はしていないが、ネットワークプロセッサ７０内にあってもその外にあってもよい。そのメモリは、受信リソースのステータス情報及び同調情報を格納するように使用されてもよい。また、メモリを使用して、各受信リソースが提供できるサービスに関する情報を格納し、現在ＳＴＢ２２ａ−２２ｎに提供されているサービスのリストを保持することもできる。

当業者には言うまでもなく、トランスポートプロセッサ５８ａ、ｂと、ネットワークプロセッサ７０と、マイクロプロセッサ４６ａ、ｂとは、ゲートウェイ１４ａ、ｂの動作に必要な制御機能を実行できるより大きなコントローラまたは処理ユニットに含まれてもよい。制御機能の一部または全部は、他のブロックに分散していてもよく、ゲートウェイ１４ａ、ｂ中の主要な動作には影響しない。

トランスポートプロセッサ５８ａ、ｂは、受信リソースからのトランスポートストリームの処理を管理してもよい。一実施形態では、トランスポートプロセッサ５８ａ、ｂは、所与の受信リソースから供給されるＳＰＴＳを受けてすべてのＳＰＴＳを一緒に含むＩＰマルチキャストストリームを作成してもよい。別の実施形態では、プロセッサはＳＴＢ２２ａ−２２ｎにより要求されたＳＰＴＳのみを取り、それぞれのＳＰＴＳに対して別々のＩＰマルチキャストストリームを作成する。両方のアプローチを組み合わせて使用することも可能である。また、ネットワークプロセッサ７０は、現在使用されている各リソースに提供されるすべてのサービスのリストを、そのサービスが実際に現在要求されていてもいなくても保持する。また、トランスポートプロセッサ５８ａ、ｂは、サービス及び受信リソースのリスト等の情報の記憶を提供するメモリを含んでいてもよい。

上記の通り、衛星ゲートウェイ１４ａ、ｂは、ＩＰ配信ネットワーク２０を介してＳＴＢ２２ａ−２２ｎにサービスをマルチキャストする。サービスを構成するＩＰパケットがＳＴＢ２２ａ−２２ｎの１つに到達すると、ＳＴＢ２２ａ−２２ｎ内のイーサネット集積回路（ＩＣ）がそのＩＰパケットを復号して、ＳＴＢ２２ａ−２２ｎにそのサービスを実行させる（例えば、テレビジョンチャンネル）。しかし、イーサネットＩＣは、ある数の非同期データストリームをサポートすることができるだけでもよい。上記のビデオ、オーディオ、その他のサービスのマルチキャストは、非同期ストリームの一例である。

上記の通り、ＳＴＢ２２ａ−２２ｎ内のイーサネットＩＣは、任意の時点において、ある数の非同期ストリームのみを処理するように設計されていてもよい。従って、イーサネットＩＣの容量を超える非同期ストリームは破棄されるか失われることもある。例えば、ＳＴＢ２２ａ−２２ｎの１つ内のイーサネットＩＣが任意の時点において４つの非同期ストリームを処理する容量を有する場合、５つめの非同期ストリームはドロップされ得る。この５つめの非同期ストリームがビデオストリームを担うマルチキャストである場合、そのビデオサービスのＳＴＢの表示は中断されるかも知れない。このため、システム１０内の非同期ストリームの数を最小化することが望ましい。

図４を参照して、ゲートウェイデバイスのリソースを割り当ててＳＴＢにサービスする方法３００が示されている。ネットワークプロセッサ７０は、ゲートウェイ１４の動作と関連する他のタスクを実行しつつ、ステップ３０２において、１つ以上のＳＴＢ２２ａ−２２ｎにより発せられた要求を待つ。ステップ３０４において、サービス要求がネットワークプロセッサ７０で受信され、ステップ３０６において、そのサービス要求がそのネットワークプロセッサ７０により処理される。ステップ３０６における処理の結果は、ＳＴＢ２２ａ−２２ｎにサービスを提供するために正しいチャンネルに同調する必要があるパラメータを含む情報のセットである。ステップ３０８において、第１の比較をして、現在要求されているパラメータが、すでに割り当てられ進行中のサービスで使用されているパラメータと一致するか決定する。これらのパラメータは、例えば、受信リソースを介して衛星システムからサービスを受信する同調情報を含む。この比較には、ＳＴＢに現在提供されているサービスの比較、または受信リソースが現在同調しているＬバンドトランスポート信号に基づき利用できるすべてのサービスのリストの比較を含む。比較の結果一致しており、答えがＹＥＳであれば、ステップ３１４において、ＳＴＢ２２ａ−２２ｎの現在の要求を選択されたチャンネルにより提供されるサービスのリストに加える。ステップ３１６において、ネットワークプロセッサ７０は、メッセージを作成して、サービス要求が成功した要求元のＳＴＢ２２ａ−２２ｎに送り返す。

一実施形態では、ネットワークプロセッサ７０は、マルチキャストＩＰデータで使用されるリアルタイムストリーミングプロトコル（ＲＴＳＰ）の機能を利用してメッセージを提供する。プロセッサ７０は、データストリームをＳＴＢ２２ａ−２２ｎへの通知メッセージで修正する。その通知メッセージは、ＳＴＢ２２ａ−２２ｎが要求されたサービスを含むマルチキャストＩＰストリームと関連するパケットを受け取り始めることを示すものである。ＲＴＳＰとマルチキャストＩＰの利用は、サーバがＳＴＢ２２ａ−２２ｎに提供するデータストリームの通知及び修正をする方法の一例である。他の実施形態では、必要な受信リソース等のサービスのパラメータに関して一致が成り立っているとネットワークプロセッサ７０が決定すると、ネットワークプロセッサ７０は、それに加えて、受信リソースにより受信されている要求されたサービスも現在提供されているサービスと一致するか比較する。一致したら、ネットワークプロセッサ７０は、前述のＲＴＳＰ等の手段により通知をする。サービスが一致しなければ、ネットワークプロセッサ７０は新しいサービスを開始する必要がある。その開始は、トランスポートプロセッサ５８ａ、ｂを介してＩＰマルチキャストの新しいデータストリームを生成して、上記の方法により、このサービスが利用可能であることを要求したＳＴＢ２２ａ−２２ｎに通知することにより行われる。

ステップ３０８において、比較の結果が一致しなければ、ステップ３１０において、プロセッサ７０はそのサービス要求を収容する同調器が利用可能か決定する。同調器が利用可能であれば、ネットワークプロセッサ７０は、ステップ３１２において、この利用可能な同調器に制御信号を送り、ステップ３１４において、サービスリストを更新して新しいサービスと新しい同調器を加える。次に、ステップ３１６において、ネットワークプロセッサ７０はＳＴＢ２２ａ−２２ｎにメッセージを送り返す。

ステップ３１０に戻り、フロントエンド４１ａ、ｂ中の同調器または受信リソースが既存のサービス要求に割り当てられているとき、ステップ３１８において、ネットワークプロセッサ７０はＳＴＢ２２ａ−２２ｎに、すべてのリソースが使用中のためサービス要求は受け入れられなかったことを示すメッセージを送る。その後、ステップ３２０において、ネットワークプロセッサ７０は、新しいサービス要求を受け取るまで、待機モードに入る。

この実施形態では、イーサネットまたは同様のインターフェイスで受信リソースを割り当てる方法を利用する構成を詳細に説明したが、他のインターフェイスを利用して同様の管理方法を享受することができる。例えば、同軸ケーブルインターフェイスを利用するシステムにおいて、リソースとサービスを管理して、不必要に高い動作帯域幅のために高価である伝送機器に要する費用を最小化することができる。当業者には言うまでもなく、同調器等の受信リソースを動的に割り当てるかかるシステムは、ヘッドエンドユニットやゲートウェイサーバでの使用に有利である。

本発明はいろいろな一部変更や代替的形式をとりうるが、具体的な実施形態を図面中で例として示し、ここに詳細に説明する。しかし、言うまでもなく、本発明は開示した具体的な形体に限定されるものではない。むしろ、本発明は、添付した請求の範囲に記載された本発明の精神と範囲に含まれるすべての修正、等価物、代替物を含むものである。

本発明の衛星テレビジョン・オーバー・ＩＰシステムの一例を示すブロック図である。 図１に示した衛星テレビジョン・オーバーＩＰの一例の他の実施形態である。 本発明の衛星ゲートウェイの一例を示すブロック図である。 本発明の衛星ゲートウェイ中のチューナ等の受信リソースの割り当て方法の一例を示すフローチャートである。

Claims (31)

1. ネットワークにおいて受信リソースを割り当てる方法であって、
   受信リソースに対する要求を受信する段階と、
   前記要求された受信リソースを現在使用されている複数の受信リソースと比較する段階と、
   前記現在使用されている受信リソースが前記要求された受信リソースと一致したとき、前記現在使用されている受信リソースの１つの共同使用を確立する段階とを有する方法。
2. さらに、前記要求された受信リソースが前記現在使用されている受信リソースの１つと一致しないとき、使用されていない受信リソースを割り当てる段階を有する、請求項１に記載の方法。
3. 前記受信リソースは、信号のグループから１つの信号を受信するレシーバを有する、請求項１に記載の方法。
4. 受信リソースに対する要求を受信する段階は、さらに
   サービスに対する要求を受信する段階をさらに有し、前記サービスがデータストリームとして提供される、請求項１に記載の方法。
5. 共同使用を確立する段階は、さらに
   前記データストリームを複数の要求元の表示を含むように修正する段階を有する、請求項４に記載の方法。
6. 受信リソースに対する前記要求はサービスに対する要求に含まれる、請求項１に記載の方法。
7. サービスに対する要求を処理して受信リソースに対する前記要求を決定する段階をさらに含む、請求項１に記載の方法。
8. 前記要求された受信リソースを比較する段階は、前記要求された受信リソースを同調させるパラメータを前記現在使用されている受信リソースを同調させるパラメータと比較する段階を有する、請求項１に記載の方法。
9. 前記パラメータは周波数である、請求項８に記載の方法。
10. 前記要求された受信リソースを比較する段階は、前記要求された受信リソースを同調させるパラメータを前記現在使用されている受信リソースの各々を同調させるパラメータと比較する段階を有する、請求項１に記載の方法。
11. 前記パラメータは周波数である、請求項１０に記載の方法。
12. 前記要求された受信リソースを比較する段階は、前記要求された受信リソースに関連するサービスのパラメータを現在提供されているサービスのパラメータと比較する段階をさらに有する、請求項１に記載の方法。
13. 前記パラメータは番組識別子である、請求項１２に記載の方法。
14. 前記要求された受信リソースを比較する段階は、前記要求された受信リソースに関連するサービスのパラメータを現在提供されているサービスのセットの各々のパラメータと比較する段階をさらに有する、請求項１に記載の方法。
15. 前記パラメータは番組識別子である、請求項１４に記載の方法。
16. 前記受信リソースは同調器を有する、請求項１に記載の方法。
17. 複数の第１の信号を受信し、前記第１の信号を処理して第２の信号を発生する複数の第１のデバイスと、
    前記複数の第１のデバイスと通信可能に接続され、前記第２の信号を処理して少なくとも１つの第３の信号を発生する複数の第２のデバイスと、
    前記複数の第２のデバイスと通信可能に接続されたインターフェイスであって、前記複数の第２のデバイスから前記少なくとも１つの第３の信号を通過させられ、サービスに対する要求を受信して前記サービスに対する要求を前記複数の第２のデバイスに通過させるインターフェイスと、
    前記複数の第１のデバイスと前記複数の第２のデバイスとインターフェイスとに通信可能に接続されたコントローラであって、前記インターフェイスからのサービスに対する前記要求の受信に基づいて前記複数の第１のデバイスの割り当てを管理するコントローラとを有する装置。
18. 前記複数の第１の信号を受信する前記複数の第１のデバイスは、信号のグループのうちの信号を受信するレシーバである、請求項１７に記載の装置。
19. 前記レシーバは同調器である、請求項１８に記載の複数の受信リソース。
20. 前記第１の信号はＬバンド信号である、請求項１７に記載の装置。
21. 前記第２の信号はトランスポートストリームである、請求項１７に記載の装置。
22. 前記インターフェイスはインターネットプロトコルを用いてデータストリームを送信するデバイスである、請求項１７に記載の装置。
23. 前記インターフェイスは複数のエンドユーザデバイスと通信可能に接続された、請求項１７に記載の装置。
24. 前記エンドユーザデバイスはセットトップボックスである、請求項２３に記載の装置。
25. 前記コントローラはサービスに対する前記要求の受信に基づき前記複数の第１のデバイスの割り当てを管理し、その管理は、
    前記複数の第１のデバイスの１つに対する要求を含むサービスに対する要求を受信し、
    前記複数の第１のデバイスの１つに対する前記要求を現在使用されている前記複数の第１のデバイスと比較し、
    現在使用されている前記複数の第１のデバイスの１つが前記複数の第１のデバイスの１つに対する前記要求と一致したとき、前記複数の第１のデバイスの１つの共同使用を確立することにより行われる、請求項１７に記載の装置。
26. 前記コントローラは、前記要求の同調パラメータを現在使用されている前記複数の第１のデバイスの１つの同調パラメータと比較することにより、前記複数の第１のデバイスの１つに対する前記要求を比較する、請求項２５に記載のコントローラ。
27. 前記コントローラは、前記要求の同調パラメータを現在使用されている前記複数の第１のデバイスの各々の同調パラメータと比較することにより、前記複数の第１のデバイスの１つに対する前記要求を比較する、請求項２５に記載のコントローラ。
28. 前記コントローラは、サービスに対する前記要求のパラメータを前記複数の第１のデバイスを現在通過している前記複数の第２の信号の１つのパラメータと比較することにより、サービスに対する前記要求を比較する、請求項２５に記載のコントローラ。
29. 前記コントローラは、サービスに対する前記要求のパラメータを前記複数の第１のデバイスを現在通過している前記複数の第２の信号の各々のパラメータと比較することにより、サービスに対する前記要求を比較する、請求項２５に記載のコントローラ。
30. 前記コントローラはサービスに対する前記要求の受信に基づき前記複数の第１のデバイスの割り当てを管理し、その管理は、
    サービスに対する前記要求から前記複数の第１のデバイスの１つに対する要求を決定し、
    前記複数の第１のデバイスの１つに対する前記要求を現在使用されている前記複数の第１のデバイスと比較し、
    現在使用されている前記複数の第１のデバイスの１つが前記複数の第１のデバイスの１つに対する前記要求と一致したとき、前記複数の第１のデバイスの１つの共同使用を確立することにより行われる、請求項１７に記載の装置。
31. 受信リソースに対する要求を受信する手段と、
    前記要求された受信リソースを現在使用されている複数の受信リソースと比較する手段と、
    前記現在使用されている受信リソースが前記要求された受信リソースと一致したとき、前記現在使用されている受信リソースの１つの共同使用を確立する手段とを有するゲートウェイ装置。

Images