JP2009520421A - デジタルテレビサービスの送信方法、対応するゲートウェイおよびネットワーク - Google Patents

Abstract

本発明は、それぞれが少なくとも１つのデジタル視聴覚サービスを含む複数のデジタルマルチプレックスを受信することができるゲートウェイを介してデジタルテレビサービスを送信する方法に関し、ゲートウェイは、前記複数のマルチプレックスのうちの制限された数のマルチプレックスを受信し、それを少なくとも１つの端末に送信することができる。ゲートウェイがその容量制限に達するとき、サービスへのアクセスを向上させるために、ゲートウェイは、少なくとも１つの使用可能サービスのリストを端末のうちの少なくとも１つに送信し（４３）、使用可能サービスは、前記端末のうちの少なくとも１つに既に送信された可能なサービスによって、ゲートウェイが受信することができるマルチプレックス上に存在する。

Description

本発明は、デジタルテレビの分野に関し、より詳細には、その家庭用サービス放送に関する。

従来技術によっては、たとえば（参照規格ＲＦＣ７９１によって定義された「インターネットプロトコル」からの）のＩＰタイプのネットワークを介してゲートウェイ（すなわちＤＮＧ、英語名「Ｄｅｌｉｖｅｒｙ Ｎｅｔｗｏｒｋ Ｇａｔｅｗａｙ：デジタルネットワークゲートウェイ」）に接続された端末によってサービスを受信することを可能にする解決策が提供されるべきである。デジタルサービス事業者はそれぞれ、サービス提供物を有する。これらのサービスは、サービスセット内で再編成される。マルチプレックスという名前の各セットが、デジタルデータの１つまたは複数のストリームからなる。これらのマルチプレックスは、衛星、ネットワークケーブルヘッドまたはＴＮＴ送信機（すなわち地上デジタルテレビ、または「デジタルビデオ放送：Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ」を表すＤＶＢ）によって送信される所与の周波数に対応し得る放送用リンクを介して分配される。各マルチプレックスは、１つまたは複数のサービスを含むことができる。

ＤＮＧは、受信チューナを備え、受信チューナは、衛星またはケーブル、さらには所与の周波数の使用によるＴＮＴへの接続、ならびにそこでブロードキャストされるデジタルデータのマルチプレックスの受信を可能にする。このマルチプレックス内のサービスは、放送局によって定義された番組編成の枠組み内で放送される一連の番組（ｅｍｉｓｓｉｏｎ）と定義される。ＤＮＧに接続された第１の端末がサービスを要求するとき、ＤＮＧのチューナは、要求されたサービスを含むマルチプレックスの周波数にロックする。次いで、他の端末を介して可能なそれぞれ異なるマルチプレックスのサービスへのアクセスが妨げられ、チューナは、とりわけ他のマルチプレックス内に、したがって他の周波数上に位置するサービスについて、受信され得るすべてのマルチプレックスに関連するすべてのサービスを提供できるとは限らない。

したがって、この技術は、制限された数のマルチプレックスの受信を可能にするゲートウェイにリンクされた複数の端末を含む家庭内ネットワークに最適化されていないという欠点を提示している。

本発明の目的は、従来技術の欠点を克服することである。

より詳細には、本発明の目的は、少なくとも１つの可能な他の端末が、したがってデジタルテレビサービスを含むマルチプレックスの受信容量制限に達するゲートウェイによって中継されたサービスを既に受信しているときに、ゲートウェイによって中継されたサービスへの端末のアクセスを容易にすることである。

この目的のために、本発明は、複数のデジタルマルチプレックスを受信することができるゲートウェイを介してデジタルテレビサービスを送信する方法を提案する。各マルチプレックスは、少なくとも１つのデジタル視聴覚サービスを含み、ゲートウェイは、複数のマルチプレックスのうちの制限された数（特に１つまたは複数の受信チューナの容量に従って制限される）のマルチプレックスを受信し、ゲートウェイに接続された少なくとも１つの端末にそれらを送信するように適応される。この方法は、使用可能サービスと呼ばれる少なくとも１つのサービスのリストを端末のうちの少なくとも１つに送信するステップを含むという点で注目に値する。使用可能サービスは、ゲートウェイが受信し得るマルチプレックス上に存在し、使用可能サービスのリストは、端末のうちの少なくとも１つに既に送信された可能なサービスによって決まる。

したがって、サービスへのアクセスの管理は、ゲートウェイの受信容量が制限されるとき、端末が使用可能サービスのリストを受信し、したがって、他の端末によって要求されたサービスの送信にゲートウェイのリソースが割り当てられているときに、端末がアクセス権限を有していないサービスを要求しないので、容易になる。

優先的には、この方法は、少なくとも１つのマルチプレックスを受信するステップを含み、使用可能サービスのリストは、ゲートウェイのマルチプレックスの受信容量に到達するときに受信されるマルチプレックス（１つまたは複数）に存在するサービスを含み、他のマルチプレックスのサービスを含まない。

有利な特徴によれば、各端末は、ゲートウェイによって送信されるサービスへのアクセス優先度を有し、この方法は、サービスにアクセスする端末の優先度に従って最大の端末優先度を決定するステップを含み、サービスのリストは、ゲートウェイのマルチプレックスの受信容量に到達するときに受信されるマルチプレックス（１つまたは複数）内に存在するサービスを含み、最大優先度以下の優先端末に送信される。

特定の特徴によれば、複数のマルチプレックスのすべてのサービスを含むサービスのリストが、厳密に最大優先度より大きい優先度を有する端末に送信される。

有利なことに、テーブルは、サービスを受信しないすべての端末に送信される。

特定の特徴によれば、マルチプレックスは、衛星を介して送信され、かつ／または地上デジタルテレビマルチプレックスタイプのものである。

好ましい特徴によれば、使用可能サービスと呼ばれる少なくとも１つのサービスのリストを端末のうちの少なくとも１つに送信するステップは、ＵＤＰプロトコルによるブロードキャストである。

別の特徴によれば、この方法は、ＩＧＭＰプロトコルによるコマンドの送信を含む、端末へのサービスの送信を管理する少なくとも１つのステップを含む。サービス送信管理ステップは、たとえば、「ｊｏｉｎ」「ｌｅａｖｅ」および「ｋｅｅｐ ａｌｉｖｅ」コマンドのうちの１つまたは複数のＩＧＭＰコマンドを含む。

本発明は、それぞれが少なくとも１つのデジタル視聴覚サービスを含む複数のデジタルマルチプレックスの受信、およびデジタルテレビサービスの送信に適したゲートウェイにも関し、ゲートウェイは複数のマルチプレックスうちの制限された数のマルチプレックスを受信し、ゲートウェイに接続された少なくとも１つの端末にそれらを送信することに適する。本発明によれば、ゲートウェイは、使用可能サービスと呼ばれる少なくとも１つのサービスのリストを端末のうちの少なくとも１つに送信する手段を含み、使用可能サービスは、ゲートウェイが受信し得るマルチプレックス上に存在し、使用可能サービスのリストは、端末のうちの少なくとも１つに既に送信された可能なサービスによって決まる。

さらに、本発明は、端末と、上記で示されたゲートウェイとを含む通信ネットワークに関する。

添付の図面を参照した以下の説明を読むことから、本発明についての理解が深まり、また他の特定の特徴および利点が明らかになろう。

図１は、本発明の特定の一実施形態によるテレビサービス受信システム１を示している。

システム１は、
−ゲートウェイ１０と、
−１６のリンクを介してゲートウェイ１０に接続された受信アンテナ１６０と、
−１５のリンクを介してゲートウェイ１０に接続されたｘＤＳＬネットワーク（ＤＳＬはデジタル加入者回線を表す）１５０にアクセスするインターフェースと、
−１７のリンクを介してゲートウェイ１０に接続された家庭内ネットワーク１１と、
−ネットワーク１１にリンクされた（たとえばテレビおよび／または記録装置と関連する「セットトップボックス」タイプまたはデジタルサービス受信機の）端末１２から１４とを含む。

ネットワーク１１は優先的には、ＩＰタイプのものであり、ゲートウェイ１０と、端末１２から１４との間のデジタルテレビサービスのデータ交換を可能にする。

受信アンテナ１６０（衛星および／または地上）は、たとえばＤＶＢ規格（「デジタルビデオ放送」）と互換性のある）デジタルテレビおよび／または無線サービスマルチプレックスの受信手段を含む。それは、デジタルテレビサービスマルチプレックスに対応する信号を受信すること、およびゲートウェイ１０にそれらを送信することに適している。それぞれのマルチプレックスは、周波数に関連付けられる。マルチプレックスは、（たとえばＤＶＢ−Ｓ規格と互換性のある受信の場合には）衛星伝送を介して、かつ／または（たとえばＤＶＢ−Ｔ規格と互換性のある受信の場合には）地上伝送を介して受信される。

本発明によれば、ＡＤＳＬネットワークへの（より一般にはｘＤＳＬネットワーク、あるいは他の任意のデジタルまたはアナログオーディオ／ビデオソースへの）アクセスは任意選択である。衛星または地上ソースとは別のソースへの接続が実施される場合、ゲートウェイ１０は、このソースによって提供されたサービスを、このアンテナに接続されたアンテナおよびチューナ（１つまたは複数）（ならびに対応するマルチプレックス（１つまたは複数））を介した受信によって使用可能なサービスのリストに組み込むことができる。

図２は、ゲートウェイ１０を概略的に示している。

ゲートウェイ１０は、アドレスおよびデータバス２４によって相互接続された、
−マイクロプロセッサ２０（またはＣＰＵ）と、
−ＲＯＭタイプの不揮発性メモリ（読取り専用メモリ）２５と、
−ランダムアクセスメモリすなわちＲＡＭ２６と、
−リンク１５上で受信される信号の受信チューナ２１と、
−チューナ２１によって送信されたマルチプレックスデータを受信するデマルチプレクサ２７と、
−リンク１６を介してｘＤＳＬ信号を受信するｘＤＳＬインターフェース２２と、
−リンク１７を介して家庭内ネットワーク１１にリンクされたインターフェース２３とを含む。

チューナ２１は、複数のデジタルテレビサービスマルチプレックスを受信し、一度に１つのマルチプレックスだけを受信し得る。それでもなお、それは、受信された複数のマルチプレックスのサービスからのデータを同時にまたは順次提供するように適応される。

インターフェース２３は、家庭内ネットワーク、具体的には端末１２から１４までのネットワークから生じ、またはそれを宛先とする情報データの（ＩＰタイプの）パケットを送受信する。

さらに、図２に示された要素はそれぞれ、当業者によく知られている。これらの共通要素については、ここでは述べない。

本説明で使用される単語「レジスタ」は、言及された各メモリ内で、低容量の（何らかのバイナリデータ）のメモリゾーンと、大容量のメモリゾーン（プログラム全体の格納、または画像を表すデータのすべてを可能にする）の両方を示すことに留意されたい。

ＲＯＭ２５メモリは、具体的には、
−プログラム、「ｐｒｏｇ」２５０と、
−選択することができるサービスのテーブル、ＤＶＢ−テーブル２５１と、
−ネットワーク１１を介してゲートウェイ１０に接続されており、ゲートウェイ１０内に記録されているすべての端末のリストを含むテーブル、Ｄｅｖｉｃｅ−Ｔａｂｌｅ２５２であって、それぞれの端末は、リスニングモード（ｌｉｓｔｅｎｉｎｇ ｍｏｄｅ）のままでいなければならないマルチキャストＩＰアドレスに関連付けられる、Ｄｅｖｉｃｅ−Ｔａｂｌｅ２５２とを含む。

テーブル、ＤＶＢテーブル２５１は特に、アンテナ１６０によって受信されたすべてのマルチプレックスのうちユーザによって関心があると見なされたサービスのリストを含む。確かに、ゲートウェイの構成段階では、ユーザは、マルチプレックスが存在するすべての周波数をアンテナ１６０によってスキャンすることで得られた特定のサービスを取り除く可能性がある。特定のマルチプレックスについて、テーブル２５１は、既に事前にプログラムされたサービス（たとえば加入登録によって提供されるサービス）を含むこともできる。要するに、テーブル２５１は、選択することができるサービスのリストを含む。選択することができる各サービスについて、テーブル２５１は、必要ならば、ネットワーク１１上の対応するサービスのブロードキャストのために、使用されるマルチキャストＩＰアドレスをも含む。

以下に述べる本発明の諸ステップを実施するアルゴリズムは、これらのステップを実施するゲートウェイ１０に関連するＲＯＭ２５メモリに格納される。電源投入されたとき、マイクロプロセッサ２０は、これらのアルゴリズムの命令をロードし実行する。

ランダムアクセスメモリ２６は特に、
−レジスタ２６０内の、ゲートウェイ１０を切り換える役割を担うマイクロプロセッサ２０のオペレーティングプログラムと、
−アンテナ１６０によって受信され得る、選択可能なサービスのリスト２６１、Ｌｉｓｔ−Ｓｅｒｖｉｃｅ−Ｆｕｌｌと、
−所与のときにリスト２５２の端末に使用可能サービスのリスト２６２、Ｌｉｓｔ−Ｓｅｒｖｉｃｅ−Ｐａｒｔと、
−現在のマルチプレックスＲＸ−ＴＳ２６３（ゲートウェイのチューナ２１によって判断された時間に受信される現在のマルチプレックス）を識別するパラメータと、
−記録された各端末についてその受信状態を示すテーブル２６４、Ｄｅｖｉｃｅ−Ｓｔａｔｅとを含む。

テーブル２６４は特に、テーブル２５２の各端末がサービスを受信するかどうか示し、そうである場合は受信されたサービスの識別子を、そうでない場合は、何も受信しないことを示す。

本発明の一変形形態によれば、ゲートウェイは、複数のチューナを含む。したがって、それは、複数のマルチプレックスを同時に受信することができる。この場合、使用可能サービスのリスト２６５は、すべてのマルチプレックスが端末によって使用される場合には制限され、次いで、同時に受信されたすべてのマルチプレックスに存在するサービスを含む。次いで、レジスタＲＸ−ＴＳ２６３は、現在のマルチプレックス、すなわちゲートウェイの少なくとも１つのチューナによって考慮された時間に受信されるマルチプレックスを識別する。

図３は、ゲートウェイ１０によって実施されるサービススキャンをフローチャートの形で示している。このアルゴリズムは特に、選択することができるサービスのテーブル２５０の構成または更新を可能にする。

ゲートウェイ１０初期化のステップ３０の後、ステップ３１の間、ゲートウェイは、そのチューナ２１に、受信することができるマルチプレックスに対応する周波数帯の低周波に対応する第１の周波数Ｆｏにロックするように命じる。

次いで、テスト３２の間、ゲートウェイ１０は、現在の周波数が有効かどうか検証する。

有効である場合、ステップ３３の間、ゲートウェイ１０は、現在の周波数に対応するマルチプレックスに関する情報を受信し、マルチプレックスによって提供されるサービスの数に対応するサービスのリストを記録する。

次いで、ステップ３４の間、ゲートウェイは、現在の周波数に対応するマルチプレックス内に存在する各サービスにマルチキャストＩＰアドレスを割り当て、対応するポート番号を有するＩＰアドレスをサービステーブル内に記録する。

次いで、ステップ３５の間、ゲートウェイ１０は、現在の周波数を増分する。

次いで、テスト３６の間、それは、受信することができるマルチプレックスに対応する周波数帯の最後に到達するかどうか検証する。

到達しない場合は、テスト３２が繰り返される。

到達する場合は、ステップ３７の間、サービスは並べ替えられ、契約外サービス（ｓｅｒｖｉｃｅ ｅｘｃｌ．ｓｕｂｓｃｒｉｐｔｉｏｎ）および／またはユーザが関心のないサービスは取り除かれ、他のサービスが選択されることができ、テーブル２５１に記録される。

実例として、テーブル２５１の一例が、図５に提示されている。このテーブル２５１は、
−列５０の、チューナの制御を可能にする、ＧＨｚで表現されたマルチプレックス（すなわちＴＳ）の周波数と、
−列５１の、所与のマルチプレックス内で選択することができるサービスに特有のパラメータを指定するＤＶＢトリプレット（特に、デマルチプレクサ２７が、そのマルチプレックスからの対応するサービスを逆多重化することを可能にするパラメータ、すなわちマルチプレックス（またはＤＶＢ規格によるトランスポートストリームに対応するＴＳ）内のネットワーク識別子、トランスポート識別子およびサービス識別子）と、
−列５２の、マルチキャストＩＰアドレス、および対応するゲートウェイポートとを含む。

したがって、それぞれの周波数１０．７７２ＧＨｚおよび１０．８０３ＧＨｚを有するマルチプレックスについて、３つのデジタルテレビサービスを選択することができ、そのそれぞれに、ＩＰアドレスが割り当てられている。同様に、周波数１０．７２９ＧＨｚを有するマルチプレックスについて、単一のサービスを選択することができる。

衛星受信の場合には、同じ周波数が、それぞれ水平および垂直の極性を有する２つのマルチプレックスを含み得る。この変形形態によれば、テーブル２５１は、極性をも含み、対応するマルチプレックスを受信するためにチューナは、周波数と極性の両方を知っていなければならない。さらに、この変形形態によれば、可能な極性のそれぞれについて、図３に示されたサービススキャンアルゴリズムのステップ３１から３６が実行され、ゲートウェイは、マルチプレックスに関連する極性と周波数の両方を記録する。

図４は、ゲートウェイ１０によって実装されたサービス送信アルゴリズムをフローチャートの形で示している。このアルゴリズムは特に、ゲートウェイ１０によって記録された端末に提供されたサービスリストの更新を管理する。

第１のステップ４０の間、ゲートウェイは、使用されるそれぞれ異なる変数およびパラメータを初期化し、図３に提示されたアルゴリズムを実装することにより選択することができるサービスのテーブル２５１を特に作成し、（たとえば、プログラミングによって、および／または端末を探索するゲートウェイ、および／またはゲートウェイによってそれ自身の宣言を行う各端末によって）ネットワーク１１に接続された端末１２から１４をテーブル２５２に記録する。このステップの間、ゲートウェイは、テーブル２５１にリンクされた端末によって読み出すことができるフォーマットで使用可能であり、端末についての重要な情報、特に各サービスの
−名前、
−サービスプロバイダ（任意選択）、
−ポートを伴うＩＰブロードキャストアドレス、
−オーディオおよび／またはビデオフォーマット、および
−おそらく端末に有用であり得る他の情報を含む、すべてのサービスのリスト２６１をも構成する。
ゲートウェイ１０は、各端末に関連する「非接続」状況を含むテーブル２６４を初期化する。次いで、送信されたゲートウェイ１０は、記録された各端末にリスト２６１を送信する。この操作は特に、以下のやり方のうちの１つに従って実施されてもよい：
−ゲートウェイは、端末が受信待ちモードのままである対応するＩＰアドレス上で、ＵＤＰプロトコル（マルチキャストと呼ばれる伝送モード）に従って、リスト２６１を含むメッセージを各端末に送信し、あるいは
−それぞれの端末は、ＨＴＴＰプロトコル（すなわちＲＦＣ２６１６規格によって定義された「ハイパーテキスト転送プロトコル：Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ」）によるｇｅｔタイプ命令をゲートウェイ１０に送信し、ゲートウェイは、同じプロトコルに従って、リスト２６１を伴うｐｕｔタイプコマンドで応答する。それぞれの端末は、ゲートウェイによって送られた情報を取得するためのそれ自体のＩＰアドレスを有する（ユニキャストと呼ばれる伝送モード）。

本発明の枠組み内では、マルチキャスト伝送モードによるメッセージのブロードキャストは優先的には、ＵＤＰプロトコル（すなわちＲＦＣ７６８規格に定義された「ユーザデータグラムプロトコル：Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ」）、またはＵＤＰ／ＲＴＰプロトコル（すなわちＲＦＣ１８８９規格に定義されたリアルタイム伝送プロトコル：Ｒｅａｌｔｉｍｅ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｐｒｏｔｏｃｏｌ）によって実施される。ＲＴＰを使用すると、タイムスタンプがパケットに追加され、また受信時に、ジッタが制御されない（送信時間変更）場合に送信時刻を回復することが可能になる。ＲＴＰの使用によって、シーケンス番号の挿入、したがって、間違った順序で受信されたかもしれないパケットを整理することも可能になる。

次いで、ステップ４１の間、ゲートウェイ１０は、受信されるマルチプレックスおよび／または要求されるサービスの変更を待つ。この変更は特に、マルチプレックスの受信の開始時に、またはマルチプレックスの受信の終了時に、あるマルチプレックスを別のマルチプレックスにハンドオーバすることに対応する。こうしたステップは特に、マルチプレックス上のサービス照会、必要なサービスの変更（マルチプレックスの変更をももたらす）、および／または端末へのサービス送信の停止の結果である。

次いで、ステップ４２の間、ゲートウェイは、チューナ２１によって受信され得るマルチプレックスを決定する。上述の実施形態によれば、単一のマルチプレックスが、チューナ２１によって受信されてもよい。このケースでは、サービスが端末へ送信されない場合は、受信され得るサービスのリストは、（加入が有効であると仮定して）アンテナ１６０によって受信されたマルチプレックス（またはストリーム）内で使用可能なすべてのサービスに対応する。そうでない場合は、ゲートウェイ１０は、チューナ２１によって受信された同じマルチプレックスの少なくとも１つのサービスを１つまたは複数の端末１２から１４に送信する。次いで、使用可能サービスのリストは、受信されたマルチプレックス上に存在するサービスのリストである。次いで、このリストは、レジスタ２６２に記録される。

次いで、ステップ４３の間、ゲートウェイ１０は、使用可能サービスのリスト２６２を、ゲートウェイ１０により記録された「サービスに接続されていない」状況にある端末１２から１４のそれぞれに送信する。１つの端末だけが、レジスタ２６３に記録されたマルチプレックスを識別するパラメータに対応する、デマルチプレクサ２７によって逆多重化されたマルチプレックスのサービスを受信する場合、それは、選択可能な如何なるサービスをも受信することができ（実際、サービスを変更するには、それは、現在のサービスの受信を停止しなければならない）。したがって、ゲートウェイ１０は、選択することができるすべてのサービスのリスト２６１をそれに送信してもよい。一方、２つの端末が同じマルチプレックスからサービスを受信する場合、それらは、ゲートウェイが別のマルチプレックスに切り換わることを防止する。この場合、ゲートウェイ１０は、選択することができる現在のマルチプレックスのサービスに縮小されたリスト２６２をそれらに送信する。

一変形実施形態によれば、ステップ４３の間、ゲートウェイ１０は、リスト２６２を受信する端末に、「縮小したサービスリスト」タイプの表示すべき一情報を（たとえば、考慮されている端末がブラウザを備える場合には、ｈｔｔｐプロトコルに従うメッセージを介して）、使用可能サービスの詳細な説明と共に、またはそれ無しに送信する。この情報は、サービスを受信し、したがって、サービスへのアクセスを制限する役割を担う１つまたは複数の端末の識別子を含むこともできる。

図６は、本発明の一変形実施形態による、ゲートウェイ１０によって実装されたサービスの送信アルゴリズムをフローチャートの形で示しており、端末は、サービスへのアクセス優先度を有する。この変形形態によれば、各端末には、オーディオ／ビデオサービスへのアクセス優先度が割り当てられ、他の端末より高い優先度を有する端末は、より低い優先度を有する別の端末が別のマルチプレックスからのサービスに既にアクセスしている場合でも、すべてのサービスを制御する。この場合、使用可能サービスのリストは、最も高い優先度レベルを有する端末によるマルチプレックスへのアクセスによって決まる。

第１のステップ６２の間、ゲートウェイは、ゲートウェイと共に記録された端末の優先度レベルを考慮に入れることによって、上記で述べたステップ４０に類似の初期化を実施する。優先度は特に、テーブル２５２に記録される。この優先度は特に、ユーザによって（たとえば、ゲートウェイとのマン−マシン対話の形で直接に（したがってゲートウェイが画面およびデータ入力法（キーボード、マウス、触覚画面など）を備える）、あるいは適切な端末を介して）、あるいは端末の構成によって（たとえば事前に記録されまたはユーザによって導入された各マシンに特有のタイプまたはパラメータに従って）定義されてもよく、優先度は、ｈｔｔｐメッセージを介して端末からゲートウェイに送信することができる。優先度管理のための異なる変形形態によれば、優先度は、固定であっても、可変であってもよい。優先度は、接続、ゲートウェイおよび／あるいは１つまたは複数の端末上のメニュー、ならびに／あるいはユーザプロファイル（たとえばアクセスコードを伴う）に従って定義することもできる。

下記のステップ４１および４２は、図４に示されたアルゴリズムの諸ステップに類似する。したがって、それらは、同じ言及内容を有しており、さらには論じない。

次いで、ステップ６０の間、ゲートウェイは以下の場合に、マルチプレクサに要求側端末へのサービスの送信を要求する。

−サービスが端末に送信されない；
−要求されたサービスが現在のマルチプレックス２６３（別の端末によって要求されたサービスに対応するマルチプレックス）上に存在する；または
−端末が、サービスを受信する端末よりも厳密に高い優先度を有する。

最後のケースでは、対応するサービスは、（優先度を有する端末によって要求されたサービスに対応するマルチプレックス内に存在する場合を除いて、）サービスを受信する端末（１つまたは複数）に、もはや送信されない。

有利なことに、本発明によれば、より低い優先度を有する端末は、それに使用可能なサービスに制限されたサービスのリストを受信しているので、それがアクセスを有していないサービスを要求し得ない。

本発明の異なる変形形態によれば、ゲートウェイは、要求されたサービスをもはや受信しない端末に、情報メッセージを送信しまたは送信せず、新しい現在のマルチプレックス（事前にプログラムされたサービスまたは他のサービス）上に存在するデフォルトサービスを送信し、またはさらには送信しない。本発明の一変形形態によれば、非優先端末へのサービスの削除につながる、マルチプレックスの変更を検出するゲートウェイは、優先度を有する端末に警告メッセージ（たとえば、このアクションは、「識別子」端末へのサービスの損失につながる）、および／または確認メッセージ（次いで、要求されたアクションが確認される場合にだけ、マルチプレックスハンドオーバが行われる）を送信してもよい。

ステップ６１の間、次いで、使用可能サービスのリスト２６２は、受信されたマルチプレックス上に存在するサービスのリストである。ゲートウェイ１０は、サービスへのアクセスの最高優先度を有する端末より厳密に低い優先度を有するゲートウェイ１０と共に記録された端末１２から１４のそれぞれに、使用可能サービス２６２のリストを送信する。したがって、これらの端末は、現在のマルチプレックスのサービスだけにアクセスし得る。ゲートウェイ１０は、サービスへのアクセスの最高優先度を有する端末より厳密に高い優先度を有する各端末にリスト２６１をも送信する。したがって、より高い優先度を有するこれらの端末のうちの１つは、選択することができるどのようなサービスをもアクセスすることができる。現在のマルチプレックスのサービスが、サービスを受信する端末のうちのより高い優先度を有する単一の端末によって受信される場合、それは、選択することができるどのようなサービスをも受信してもよく（実際、サービスを変更するには、それは、現在のサービスの受信を停止しなければならない）、ゲートウェイは、リスト２６１をそれに送信してもよい。しかし、等しい優先度を有し、またサービスを受信する端末のうちで最高優先度を有する２つの端末が同じマルチプレックスからのサービスを受信する場合、それらは、ゲートウェイが別のマルチプレックスに切り換えることを防止する。この場合、ゲートウェイ１０は、選択することができる現在のマルチプレックスのサービスに縮小されたリスト２６２をそれらに送信する。有利なことに、端末の優先度は、アクセス競合の状況を回避するためにすべて異なる。

端末によるサービスの受信の停止を検出するために、ゲートウェイは、要求されたサービスに端末が依然として接続されていることを検証するために端末へのｋｅｅｐ−ａｌｉｖｅタイプのＩＧＭＰメッセージ（ＲＦＣ １１１２規格によって定義されたプロトコル「インターネットグループ管理プロトコル」に対応する）を送信する。端末が接続されている場合は、それは、ＩＧＭＰメッセージで応答する。応答がないことは、それがもはや接続されていないことを示す。端末は、ｌｅａｖｅタイプのＩＧＭＰコマンドを介してサービス要求の終了を示すこともできる。ＩＧＭＰプロトコルを使用すると、ビデオがマルチキャストで送信され、したがって端末が優先的には、ストリームへの接続を要求するためにＩＧＭＰを使用するので、述べられた機構の実装が容易になる。さらに、ＩＧＭＰは既にサポート機構を含み、このサポート機構によって、（停電、故障など）端末のスイッチが偶然にオフになる場合のサービス停止の管理が容易になる。したがって、ＩＧＭＰメッセージの使用は、本発明の実施に望ましく、（たとえばＲＴＳＰのように）別のプロトコルを考案し、および／または上に実装することを必要とする。端末によるサービス受信停止の後に、ゲートウェイは、テーブル２６３およびリスト２６２内の対応する端末の状況を更新し、ステップ４３（優先度が管理されない場合）、または６１（優先度管理の機構を備える場合）の説明に示されたのと同じ条件に従ってリスト２６１および２６２のうちの１つを端末に送信する。

図７は、ゲートウェイ１０によって実装されたサービス要求受信の処理アルゴリズムをフローチャートの形で示している。

初期化ステップ７０の後、ステップ７１の間、ゲートウェイ１０は、端末に割り当てられたマルチキャストアドレス上で端末によって送られたＩＧＭＰプロトコルによるｊｏｉｎコマンドを受信するために待機モードに入る。このコマンドは、以前に受信された最後のリスト２６１または２６２のサービスのうちに存在するサービス要求に対応する。

次いで、ステップ７２の間、ゲートウェイは、受信されたｊｏｉｎコマンド内に存在するＩＰアドレスによってそのブロードキャストアドレスが与えられるサービスに対応するマルチプレックスの参照を探索する。

次いで、ステップ７３の間、ゲートウェイ１０は、このマルチプレックスが現在のマルチプレックスに対応するかどうか検証する。

そうである場合は、ステップ７５の間、ゲートウェイは、デマルチプレクサに、要求されたサービスを要求側端末に送信することを要求し、上述されたステップ４３または６１のうちの１つに従って、サービスリストの送信を実施する。次いで、ステップ７１が繰り返される。

そうでない場合は、優先度管理を実装する一変形形態によれば、ステップ７４の間、ゲートウェイは、ステップ６０の説明に関して示されるように、マルチプレックスの変更が可能かどうか検証する。

マルチプレックスの変更が可能である場合は、ステップ７７の間、ゲートウェイは、チューナにはマルチプレックスの変更を、またデマルチプレクサには要求されたサービスを要求側端末に送信することを要求し、上述されたステップ６１に従ってサービスリストの送信を実施する。次いで、ステップ７１が繰り返される。

マルチプレックスの変更が可能でない場合は、ステップ７６の間、ゲートウェイは、要求されたサービスをそれが提供し得ないことを要求側端末に示す。次いで、ステップ７１が繰り返される。理論上、本発明は、ステップ７１を通過することを回避しまたは制限する。しかし、安全性の理由により、テスト７３およびステップ７６（特定の実装形態によれば、使用可能サービスのリストが、不正確に受信され、あるいは後に受信されまたは読み出される）。優先度機構が存在しない本発明の一変形形態によれば、ステップ７２の直後に、テスト７３、ステップ７５を実施しない。優先度機構を有する本発明の別の変形形態によれば、否定テスト７３の直後に、テスト７４またはステップ７６、ステップ７７を実施しない。

図８は、端末１２によって実装されたサービス受信アルゴリズムを示す。

初期化ステップ８０の間、端末１２は、その構成に従って、サービスの受信に特有のパラメータを更新する。

次いで、ステップ８１の間、端末１２は待機し、次いで、使用可能サービスのリストを受信し、ローカルメモリにそれを記録する。したがって、端末１２は、それをユーザに提示してもよい。

次いで、ステップ８２の間、端末１２は、サービス要求をゲートウェイに送信し、サービスは、ステップ８１の間に受信されたリストに属する使用可能サービスのうちから選択されている。可能なサービスによって決まるサービスのリストが少なくとも１つの他の端末に送信されているので、他の端末に送信された可能なサービス、および端末１２によって要求されたサービスを含むマルチプレックスにアクセスするための競合は生じない。

したがって、ステップ８３の間、端末１２は、ゲートウェイが対応するマルチプレックスを受信するので、要求されたサービスに対応するデータを受信する。このように、要求されたサービスに対応するマルチプレックスの受信の可能性がないことに関連する失敗は発生しない（チューナは、他の端末を妨害せずに、このマルチプレックスを受信することができる）。端末間でアクセス優先度を実装する変形形態によれば、より低い優先度を有する端末だけが、それがおそらく要求したサービスをもはや受信しない可能性が高い。

次いで、ステップ８４の間、端末１２は、（特に、ユーザによる中断または期限切れに対応する）サービス終了を待つ。端末間のアクセス優先度を実装する変形形態では、サービスの終了は、サービスがもはや使用可能でなく（より高い優先度を有する端末が、ステップ８２で要求されたサービスを含むマルチプレックスとは別のマルチプレックスに存在するサービスを要求する場合）、あるいはデフォルトサービスへのハンドオーバによって置き換えられることを示すメッセージの受信に対応することもある。

次いで、ステップ８５の間、端末１２は、ゲートウェイ１０が使用可能サービスのリストを更新し得るように、要求されたサービスの終了を示す情報をゲートウェイ１０に送信する。このステップ１２は、サービスの終了がゲートウェイ１０にリンクされる場合、省略されてもよい（特に、端末間の優先度を実装するときのケースであり得る）。

ステップ８５の後、ステップ８１が繰り返される。

図９は、チューナ２１と、デマルチプレクサ２７と、マイクロプロセッサ２０と、端末１２、１３との間の交換の一例を示している。実装された機構についての理解を促すために、最も重要な交換だけが表されている。さらに、図９によれば、交換は、上から下へと順に行われると仮定している。

したがって、第１のステップ９０の間、ＣＰＵ２０およびチューナ９０は、テーブル２５１の構成のために受信することができるマルチプレックスに関する情報を交換する。交換９０は優先的には、初期化段階に行われる。

したがって、マルチキャストモードによれば、ＣＰＵ２０は、選択することができるサービスのリストを含むメッセージ９１および９２を端末にブロードキャストし、それぞれの端末は、それに割り当てられたＩＰアドレスに関連のあるメッセージを受信待ちする。あるいはまた、端末（図９の実例による１２または１３）は、コマンド９３、ｇｅｔ ｈｔｔｐを送信し、コマンド９４、ｐｕｔ ｈｔｔｐを介して、選択可能なサービスのリストを受信してもよい。この変形形態によれば、端末は、任意の可能な変更について通知を受ける状態のままであるために、コマンド９３の通常のブロードキャストを行う役割を担う。読みやすくするために、下記では、マルチキャストモードのブロードキャストだけを使用することとする。

次に、いずれかの操作段階の後に続く交換について述べる。

そのような訳で、端末１２は、ゲートウェイＩＰアドレスに、（たとえばマルチプレックスＴＳ１上に存在する）要求されたサービスのアドレスを含むｊｏｉｎ ＩＧＭＰコマンドを送信する。

この要求の受信の後に続いて、ＣＰＵは、他の端末に、マルチプレックスＴＳ１上に存在するサービスのリスト２６２（端末１３へのメッセージ９６）を、チューナにマルチプレックスＴＳ１にロックするよう求める要求（メッセージ９７）を、およびデマルチプレクサ２７に、テーブル２５１に記録されたデータに従って対応するマルチキャストＩＰアドレス上で要求されたサービスを送ることを求める要求（メッセージ９８）を送信する。

次いで、チューナは、マルチプレックスＴＳ１に関するデータ９９をデマルチプレクサに送信し、このデマルチプレクサは、ＵＤＰプロトコル（すなわちユーザデータグラムプロトコル：Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）に従って、ＣＰＵによって示されたマルチキャストブロードキャストアドレス上で、メッセージ９８によって要求されたサービスを送信する。

この実施例によれば、端末１３は、端末１２によって要求されたサービスと異なる、要求されたサービスｓｅｒｖ２のアドレスを含むｊｏｉｎ ＩＧＭＰ コマンドをゲートウェイのＩＰアドレスに送信する。

このサービスは、端末１３がメッセージ９６を考慮に入れているので、マルチプレックスＴＳ１上で使用可能である。次いで、ＣＰＵは、対応するマルチキャストＩＰアドレス上で要求されたサービスを送信することをデマルチプレクサ２７に要求し（メッセージ１０２）、端末１２にリスト２６２を送信する（メッセージ１１３）。次いで、デマルチプレクサは、ＣＰＵによって示されたマルチキャストアドレス上で、メッセージ１０２によって要求されたサービスをブロードキャストする。

例示として、端末１３は、コマンド１０４、ＩＧＭＰ ｌｅａｖｅをＣＰＵ２０に送信する。次いで、ＣＰＵは、ｓｅｒｖ２サービスの送信停止のコマンド１０５をデマルチプレクサに送信し、選択することができるすべてのサービスのリスト２６１を、マルチプレックスＴＳ１上でサービスを受信する現在唯一の端末である端末１２に送信する（メッセージ１１３）。

次いで、端末１２によって開始されるマルチプレックスハンドオーバ操作について述べるが、この端末１２はまず、受信されたサービス（メッセージ１０６、ｌｅａｖｅ ＩＧＭＰ）、次いでマルチプレックスＴＳ３に属するｓｅｒｖ３サービス（コマンド１０７、ｊｏｉｎ ＩＧＭＰ）の停止をＣＰＵに要求する。コマンド１０６と１０７は接近しているので、ＣＰＵが、縮小したブロードキャストリストを更新し、他の端末に更新を送信する時間を有していなかった可能性がある。したがって、コマンド１０７の受信後、ＣＰＵは、マルチプレックスＴＳ３上に存在するサービスのリスト２６２を他の端末に送信し（端末１３へのメッセージ１０８）、チューナにマルチプレックスＴＳ３にロックすることを求め（メッセージ１０９）、デマルチプレクサ２７に、テーブル２５１に記録されたデータに従って対応するマルチキャストＩＰアドレス上で要求されたサービスを送信することを求める（メッセージ１１０）要求を行う。次いで、チューナは、マルチプレックスＴＳ３に関するデータ１１１をデマルチプレクサに送り、このデマルチプレクサは、ＵＤＰプロトコルに従って、ＣＰＵによって示されたマルチキャストアドレス上で、メッセージ１１２によって要求されたサービスを送信する。

当然ながら、本発明は、上述された実施形態に限定されない。

具体的には、ゲートウェイは、図１に示されるようにｘＤＳＬリンクに接続される場合、ｘＤＳＬを介して使用可能なサービスを端末に提案してもよい。一般に、ｘＤＳＬ帯域幅は制限され、制限された数のｘＤＳＬサービスが同時にアクセスされ得る（たとえば、複数の使用可能サービスのうちの単一のサービスが、ｘＤＳＬを介して受信されてもよい）。この場合、ｘＤＳＬサービスが受信されない場合、選択することができるサービスのリストは、ｘＤＳＬを介して使用可能であり、また多分ユーザによってまたは加入登録用のシステムによって選択されるサービスを含み、したがって、これらのサービスが、選択可能なサービス（リスト２６１）、または特定のときに使用可能なサービス（リスト２６１または２６１）に加わる。サービスが、ｘＤＳＬを介してと、チューナを介しての両方で使用可能である場合、ｘＤＳＬとチューナの間のアクセス優先度は、任意の基準、特にコスト、サービス品質、サービスを受信する端末また要求元の優先度、要求されたサービスが、受信されるマルチプレックスに属するという事実に従って定義されてもよい（チューナの容量が既に使用されている場合、他の端末のためにサービスへのアクセスを制限するのではなく、ｘＤＳＬを介した受信を使用して、この容量を使用することがより有利である）。同様に、本発明の一変形形態によれば、要求されたサービスに従って、また特に、現在のマルチプレックス上で単一のサービスが要求され、端末が、ｘＤＳＬによって受信されたサービスをも含む別のマルチプレックス上に存在するサービスを要求する場合、ｘＤＳＬとチューナの間のハンドオーバ機構が設計される。ｘＤＳＬサービスが受信される場合、ゲートウェイは、このサービスに従って、使用可能サービスのリストを更新し、縮小した使用可能サービスリストは、このサービスと、現在のマルチプレックスのサービスとを含み、このリストは、
−最低優先度を有する端末に、または
−端末間に優先度機構が実装されない場合は、接続されていない端末に、また少なくとも２つの端末が、現在のマルチプレックスによって提供されたサービスを受信する場合は、接続されたすべての端末に送信される。
チューナを介して選択することができるサービス、およびｘＤＳＬを介して受信されるサービスのリストを含むリストが、最高優先度を有する端末に送信され、あるいは端末間で優先度機構が実施されない場合は、現在のマルチプレックスに接続される単一の端末に送信される。チューナまたはｘＤＳＬを介して選択することができるすべてのサービスのリストは、ｘＤＳＬを介してサービスを受信する端末に送信される。

本発明の別の変形形態によれば、ゲートウェイは、２つ以上のチューナ、たとえば２、３または４つ以上のチューナ、（たとえば、１つまたは複数の衛星を介してマルチプレックスを受信する１つまたは複数のチューナ、および／またはＤＶＢ−Ｔシステムを介してマルチプレックスを受信する１つまたは複数のチューナ）を含む。この変形形態によれば、マルチプレックスの受信容量に達しない限り、ゲートウェイは、すべてのマルチプレックス上に存在する、選択可能なサービスのリストを送信する。ゲートウェイは、チューナの容量に達するとすぐに、上記で述べたように本発明を実施し、すべてのチューナが、使用可能サービスのリストの管理のために、単一のチューナと見なされる。一変形形態によれば、優先度機構が実装されるとき、優先端末が、現在のマルチプレックスのうちの１つに存在しない（すなわちチューナのうちの１つによって判断された時間に受信される）サービスにアクセスしたい場合は、ゲートウェイは、優先的には、現在の各マルチプレックスについて、このマルチプレックスからサービスを受信する最高優先度を有する端末を識別し、最高優先度を有するこれらの端末のうちで最低優先度を有する端末を識別し、サービスを要求する最高優先度を有する端末に、対応する現在のマルチプレックスを割り当てる。他のシナリオを考慮することができ、また上記に言及したのと同じ原理に従って実施してもよく、特に、
−優先度が割り当てられない場合は、サービスへのアクセスを有していない端末は、現在のマルチプレックスに対応する縮小したサービスリストを受信し、他の端末にサービスを提供しないマルチプレックスのサービスを受信する端末は優先的には、選択可能なすべてのサービスのリストに対応するサービスのリストを受信する。
−優先度が割り当てられる場合は、接続された端末より高い優先度を有する端末は、選択可能なすべてのサービスのリストに対応するサービスリストを受信し、接続された端末より低い優先度を有する端末は、チューナの容量に達したときに、縮小したサービスリストを受信する。

さらに、ｘＤＳＬリンク、または他の任意の有線リンク、および１つまたは複数のチューナを備えた変形形態が、本発明に従って組み合わされてもよい。

本発明は、ゲートウェイに関連付けられた任意のタイプのネットワークとも互換性があり、このネットワークは、必ずしも家庭用ではないが、短距離または長距離（たとえばインターネットネットワーク）とすることができる。

本発明は、図２のものとは異なるゲートウェイ実装、特に、異なる構造、および／あるいは異なるインターフェースまたは構成要素（多かれ少なかれ統合されたコンポーネントなど）を有するゲートウェイとも互換性がある。

本発明の特定の一実施形態によるテレビサービス受信システムを示す図である。 図１のシステムで実装されたゲートウェイの概略ブロック図である。 図２のゲートウェイによって実装されたアルゴリズムを表す図である。 図２のゲートウェイによって実装されたアルゴリズムを表す図である。 図２のゲートウェイによって実装されたテーブルを示す図である。 本発明の一変形形態によるゲートウェイによって実装されたアルゴリズムを示す図である。 図２のゲートウェイによって実装されたアルゴリズムを表す図である。 図１のシステムの端末によって実装されたアルゴリズムを示す図である。 図１のシステムの異なる要素間の交換の一例を示す図である。

Claims (11)

1. それぞれが少なくとも１つのデジタル視聴覚サービスを含む複数のデジタルマルチプレックスを受信するのに適したゲートウェイ（１０）を介してデジタルテレビサービスを送信する方法であって、前記ゲートウェイは、１つまたは複数の受信チューナの容量に従って制限された、前記複数のマルチプレックスのうちの制限された数のマルチプレックスを受信し、前記ゲートウェイにリンクされた少なくとも１つの端末（１２から１４）にそれらを送信するのに適しており、前記方法は、使用可能サービスと呼ばれる少なくとも１つのサービスのリスト（２６１、２６２）を前記端末のうちの少なくとも１つに送信するステップ（４３）を含み、前記使用可能サービスは、前記ゲートウェイが受信し得る前記マルチプレックス上に存在しており、使用可能サービスの前記リストは、前記端末のうちの少なくとも１つに既に送信された前記可能なサービスによって決まることを特徴とする方法。
2. 前記方法は、少なくとも１つのマルチプレックスの受信ステップを含み、使用可能サービスの前記リストは、前記ゲートウェイのマルチプレックス受信容量に達するときに受信された前記マルチプレックス（１つまたは複数）に存在する前記サービスを含み、他のマルチプレックスの前記サービスを含まないことを特徴とする請求項１に記載の方法。
3. それぞれの端末は、前記ゲートウェイによって送信された前記サービスへのアクセス優先度を有し、前記方法は、サービスにアクセスする前記端末の前記優先度に従って最大端末優先度を決定するステップ（６０）を含み、サービスのリストは、前記ゲートウェイの受信容量に達するときに受信された前記マルチプレックス（１つまたは複数）に存在する前記サービスを含み、前記最大優先度以下の優先端末に送信されることを特徴とする請求項１および２のいずれか１項に記載の方法。
4. 前記複数のマルチプレックスの前記サービスのすべてを含むサービスのリストは、前記最大優先度より厳密に大きい優先度を有する前記端末に送信されることを特徴とする請求項３に記載の方法。
5. 前記テーブルは、サービスを受信しない前記端末のすべてに送信されることを特徴とする請求項１および２のいずれか１項に記載の方法。
6. 前記マルチプレックスは衛星によって送信されることを特徴とする請求項１から５のいずれか１項に記載の方法。
7. 前記マルチプレックスは地上デジタルテレビマルチプレックスタイプのものであることを特徴とする請求項１から５のいずれか１項に記載の方法。
8. 使用可能サービスと呼ばれる少なくとも１つのサービスのリストを前記端末のうちの少なくとも１つに送信する前記送信ステップ（９６、１１３、１１４、１０８）は、ＵＤＰプロトコルに従ってブロードキャストされることを特徴とする請求項１から７のいずれか１項に記載の方法。
9. ＩＧＭＰプロトコルによるコマンドの送信を含む、端末へのサービスの送信を管理する少なくとも１つの管理ステップ（９５、１０１、１０４、１０７）を含むことを特徴とする請求項１から８のいずれか１項に記載の方法。
10. それぞれが少なくとも１つのデジタル視聴覚サービスを含む複数のデジタルマルチプレックスの受信、およびデジタルテレビサービスの送信に適したゲートウェイ（１０）であって、１つまたは複数の受信チューナの容量に従って制限される、前記複数のマルチプレックスうちの制限された数のマルチプレックスを受信し、前記ゲートウェイにリンクされた少なくとも１つの端末（１２から１４）にそれらを送信することに適しており、前記ゲートウェイは、使用可能サービスと呼ばれる少なくとも１つのサービスのリスト（２６１、２６２）を前記端末のうちの少なくとも１つに送信する手段を含み、前記使用可能サービスは、前記ゲートウェイが受信し得る前記マルチプレックス上に存在し、使用可能サービスの前記リストは、前記端末のうちの少なくとも１つに既に送信された前記可能なサービスによって決まることを特徴とするゲートウェイ。
11. 端末（１２から１４）と、それぞれが少なくとも１つのデジタル視聴覚サービスを含む複数のデジタルマルチプレックスの受信、およびデジタルテレビサービスの送信に適した請求項１０に記載のゲートウェイ（１０）とを含む通信ネットワーク（１）であって、前記ゲートウェイは、１つまたは複数の受信チューナの前記容量に従って制限される、前記複数のマルチプレックスうちの制限された数のマルチプレックスを受信し、前記ゲートウェイにリンクされた前記端末にそれらを送信することに適しており、使用可能サービスと呼ばれる少なくとも１つのサービスのリスト（２６１、２６２）を前記端末のうちの少なくとも１つに送信する手段を含み、前記使用可能サービスは、前記ゲートウェイが受信し得る前記マルチプレックス上に存在し、使用可能サービスの前記リストは、前記端末のうちの少なくとも１つに既に送信された前記可能なサービスによって決まることを特徴とする通信ネットワーク。

Images