JP2010502071A

JP2010502071A - 受信器／デコーダの接続の管理のための機構

Info

Publication number: JP2010502071A
Application number: JP2009525091A
Authority: JP
Inventors: ルプランス，パトリック; リボルト，ダヴィド
Original assignee: Thomson Licensing SAS
Current assignee: Thomson Licensing SAS
Priority date: 2006-08-22
Filing date: 2007-08-17
Publication date: 2010-01-21
Anticipated expiration: 2027-08-17
Also published as: WO2008023130A3; KR20090071540A; US20100002779A1; WO2008023130A2; EP2055042A2; KR101375182B1; JP5122568B2

Abstract

【課題】
【解決手段】
本発明は、通信装置に関し、変調および復調するための手段を有し、一方を通信ネットワークに接続し他方を少なくとの一つの受信器／デコーダに接続する通信装置であって、前記受信器／デコーダからの要求の受信に応答して、前記通信ネットワークの利用可能なバンド幅に基づき、以下の異なる可能性について選択するための手段：
・前記要求を変更せずに通信ネットワークに伝送すること；または、
・より低い品質のストリームを求めるために要求を変更すること；または、
・前記要求をネットワークに伝送することを拒否し、かつ受信器／デコーダに予め設定されたマルチメディア・ファイルを送ること、
を有する通信装置である。
本発明は、通信方法にも関連する。

Description

本発明は情報通信技術の領域に関する。

本発明は、より詳細には受信器／デコーダに係る管理のための機構に関する。

特許文献１（モトローラ）は、ＩＰサブネットワークのマルチキャスト・データの管理のための方法および装置を開示している。実施例の通信システムは、連結されるサブネットワークを監視する受信器／デコーダを有している。マルチキャスト・ルータは、受信器／デコーダの要請に応じて、一つ以上のグループ（例えばビデオ・プログラムグループ）に受信器／デコーダを連結する。例えば、受信器／デコーダが第１のグループを去る場合、ルーターに対して「切断」（ｌｅａｖｅ）メッセージを送信する。他の受信器／デコーダは、これを認識しているので、この第１のグループにサブスクライブ（ｓｕｂｓｃｒｉｂｅ）するためには、「参加」（ｊｏｉｎ）メッセージを送らなければならない。このため、ルーターは、それがこの第１のグループをサブネットワークに連結しなければならないということを直ちに知らされる。

特許文献２（ＭａｒｃｏｎｉＣｏｍｍｕｎｉｃａｔｉｏｎｓ）は、帯域幅制御を有する会議のための方法および装置を開示している。この先行技術文献は、受信器／デコーダの要求の受信に応答して、通信ネットワーク上の利用可能帯域幅を考慮し、以下の異なる可能性について選択するための手段を有する装置を開示していない。
・前記要求を変更せずに通信ネットワークに伝送すること；または、
・より低い品質のストリームを求めるために要求を変更すること；または、
・前記要求をネットワークに伝送することを拒否し、かつ受信器／デコーダに予め設定されたマルチメディア・ファイルを送ること。

非特許文献１は、通信ネットワークのサービス品質を管理するための解決策を開示している。この先行技術文献は、受信器／デコーダの要求の受信に応答して、通信ネットワーク上の利用可能帯域幅を考慮した、以下の異なる可能性について選択するための手段を有する装置を開示していない。
・前記要求を変更せずに通信ネットワークに伝送すること；または、
・より低い品質のストリームを求めるために要求を変更すること；または、
・前記要求をネットワークに伝送することを拒否し、かつ受信器／デコーダに予め設定されたマルチメディア・ファイルを送ること。

特許文献３は、マルチキャスト受信器のためのアドミッション制御手段を開示している。この先行技術文献は、受信器／デコーダの要求の受信に応答して、通信ネットワーク上の利用可能帯域幅を考慮した、以下の異なる可能性について選択するための手段を有する装置を開示していない。
・前記要求を変更せずに通信ネットワークに伝送すること；または、
・より低い品質のストリームを求めるために要求を変更すること；または、
・前記要求をネットワークに伝送することを拒否し、かつ受信器／デコーダに予め設定されたマルチメディア・ファイルを送ること。

米国特許出願番号第２００３／０３５３７８号米国特許出願番号第２００５／２３７９５２号米国特許出願番号第２００６／１４６８５７号

「ＭｕｌｔｉｃａｓｔｉｎｇｉｎＤｉｆｆｅｒｅｎｔｉａｔｅｄＳｅｒｖｉｃｅＤｏｍａｉｎｓ」（ＢａｉｊａｎＹａｎｇｅｔａｌ，ＩＥＥＥＧｌｏｂａｌＴｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓＣｏｎｆｅｒｅｎｃｅ，１７Ｎｏｖｅｍｂｅｒ２００３）

本発明は、ＡＤＳＬ（非同期デジタル加入者回線）ゲートウェイに関連し、複数の受信器／デコーダまたは、セットトップボックス（ＳＴＢ：ＳｅｔＴｏｐＢｏｘｅｓ）の技術に関する。他の受信器／デコーダによって伝送されるストリームによって使用されるＡＤＳＬバンド幅があまりに広い場合、受信器／デコーダをマルチキャスト・ストリームに接続することを拒否するメカニズムが実装されなければならない。

１つの解決策は、パケットが各受信器／デコーダによって送信されたＩＧＭＰ（ＩｎｔｅｒｎｅｔＧｒｏｕｐＭａｎａｇｅｍｅｎｔＰｒｏｔｏｃｏｌ）をゲートウェイが監視することである。そして、各ストリームの特性を定義しているサービス・プランを使用して、使用する総バンド幅を算出することである。マルチキャスト・ストリームを受信するためには、受信器／デコーダがマルチキャストにＩＧＭＰ「参加」（ｊｏｉｎ）パケットを送信しなければならない。このパケットはマルチキャスト・ルータのチェーンに反映され、一つのルーターが、要求されたストリームを、要求が受信された他のルーターのポートに要請する。「参加」パケットの受け取り通知は、受信器／デコーダに返送されない。

ゲートウェイがこのＩＧＭＰパケットを傍受し、かつバンド幅がオーバーロードを防止すると決めた場合、受信器／デコーダへのためのストリームの増加は行われない。従って、テレビスクリーンは、黒いままの状態となる。

本発明は、従来技術のようにバンド幅に負担をかすぎることのリスクを回避するために、受信器／デコーダにストリームが伝送されず、スクリーンが黒いままの状態になるという、欠点を解決するための手段を提供する。

この目的のために、その典型的な例として、本発明は、一方が通信ネットワークに対接続され、他方が少なくとも一つの受信器／デコーダに接続される通信装置に関する。そして、前記受信器／デコーダからの要求の受信に応答して、通信ネットワークのバンド幅に基づき、以下の異なる可能性について選択するための手段を有することを特徴とする：
・前記要求を変更せずに通信ネットワークに伝送すること；または、
・より低い品質のストリームを求めるために要求を変更すること；または、
・前記要求をネットワークに伝送することを拒否し、かつ受信器／デコーダに予め設定されたマルチメディア・ファイルを送ること。

好ましくは、さらに前記装置は、すべてのマルチキャストアドレス、および少なくとも一つの対応するストリームの特徴、例えばプログラム名、使用するコーデックまたは使用するバンド幅、を含んでいるサービス・プランを操作するための手段を有する。

都合のよいことに、前記要求は、確認されたＩＧＭＰ要求によって確立し、前記装置は、当該通信装置に接続している受信器／デコーダの各々に受信されているストリームの表を操作するための手段を有する。

好ましくは、前記装置は、通信ネットワークに使用されているバンド幅を計算するための手段および、サービス・プランおよびストリームの表から、新しいＩＧＭＰ要求の新しいオンデマンドのストリームの受信のために必要とされる、通信ネットワークのバンド幅を計算するための手段を有する。

都合のよいことに、前記装置は、ＡＤＳＬ（非同期デジタル加入者回線）と互換性を持つ。

有利な変形例によれば、前記装置は、コンフィギュレーション表にＵＲＬ（ＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅＬｏｃａｔｏｒ）を有し、かつ前記ＵＲＬから前記予め設定されたマルチメディア・ファイルを読み出すための手段、および前記マルチメディア・ファイルを前記受信器／デコーダにマルチキャスト・ストリームの状態で、およびループの状態で送信するための手段を有する。

好ましくは、マルチメディア・ファイルは、ＨＴＴＰプロトコル（ＨｙｐｅｒｔｅｘｔＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ）によって、前記ＵＲＬから読み出される。

実施例によれば、前記装置は、前記マルチメディア・ファイルをフォーマットするための手段を有する。

前記マルチメディア・ファイルは、ビデオ、アニメーションおよび／または音声のメッセージを含んでもよい。

好ましくは、前記装置は、変調および復調するための手段を有する。

本発明は通信装置を使用する通信の方法に関し、一方が通信ネットワークに接続され、他方が少なくとも一つの受信器／デコーダに接続される通信装置を使用した通信方法であって、前記受信器／デコーダからの要求の受信に応答して、前記通信ネットワークの利用可能なバンド幅に基づき、以下の異なる可能性について選択するステップ：
・前記要求を変更せずに通信ネットワークに伝送すること；または、
・より低い品質のストリームを求めるために要求を変更すること；または、
・前記要求をネットワークに伝送することを拒否し、かつ受信器／デコーダに予め設定されたマルチメディア・ファイルを送ること、を有する方法である。

好ましくは、さらに前記方法は、すべてのマルチキャストアドレス、および少なくとも一つの対応するストリームの特徴、例えばプログラム名、使用するコーデックまたは使用するバンド幅、を含んでいるサービス・プランを操作するステップを有する。

都合のよいことに、前記方法は、確認されたＩＧＭＰ要求によって確立し、該通信装置に接続している受信器／デコーダの各々に受信されているストリームの表を操作するステップを有する。

好ましくは、前記方法は、通信ネットワークに使用されているバンド幅を計算するステップおよび、前記サービス・プランおよび前記ストリームの表から、新しいＩＧＭＰ要求の新しいオンデマンドのストリームの受信のために必要とされる、通信ネットワークのバンド幅を計算するステップを有する。

有利な変形例によれば、前記方法は、コンフィギュレーション表にＵＲＬ（ＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅＬｏｃａｔｏｒ）を有し、かつ前記ＵＲＬから前記予め設定されたマルチメディア・ファイルを読み出すためのステップ、および前記マルチメディア・ファイルを前記受信器／デコーダにマルチキャスト・ストリームの状態で、およびループの状態で送信するステップを有する。

本発明は、図を参照することによって、事例として示されている実施例に係る以下の記述から、よりよく理解される。

本発明に係る装置および方法は以下のように多数の効果がある：
・それらは、ＳＴＢのいかなる修正も必要としない；
・それらは、受信器／デコーダ（ゲートウェイ）のいかなる付加的な計算機能も必要としない。なぜなら、ビデオ符号化を行わないからである；
・サービス拒否の各場合において、異なるＵＲＬを定めることが可能である；
・ゲートウェイによって送信されたＨＴＴＰ（ＨｙｐｅｒｔｅｘｔＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ）コマンドのパラメータを追加することが可能である。そして、ＨＴＴＰサーバが、即座に（ｏｎｔｈｅｆｌｙ）、ＭＰＥＧ（ＭｏｖｉｎｇＰｉｃｔｕｒｅＥｘｐｅｒｔｓＧｒｏｕｐ）情報ファイルを生成することを可能にする；および、
・より低くされたビットレートおよび低い解像度を有する他のストリームにリダイレクションすることが可能である。

本発明の方法の実施例を例示した図である。本発明の通信装置を例示した図である。本発明の方法の実施例を例示した図である。ＩＧＭＰパケットを例示した図である。

通信装置（または住宅用ゲートウェイ）（１）（図１および２に示される）は、次の部分を有する。
・プロセッサ（１１）、
・ランダム・アクセス・メモリ（３１）、
・記憶装置（３２）、
・外部通信ネットワークに対するインタフェース（１５）、例えばＤＳＬまたは光ファイバーネットワークとのインタフェース、
・ＷＬＡＮインタフェース（１４）、
・ＤＥＣＴインタフェース（１２）、
・ブルートゥース・インタフェース（１３）および、
・複数のイーサネット（登録商標）・インタフェース（２１、２２、２３、２４）。

通信装置（または住宅用ゲートウェイ）（１）は、マルチキャストアドレスの全ておよび対応するストリームの特徴（プログラム名、コーデックおよび使用するバンド幅）を含む「サービス・プラン」を読み出す。通信装置は、ＩＧＭＰ要求を確認して、受信されたストリームの表を維持する。このテーブルおよびサービス・プランから、これは、新しいＩＧＭＰ要求によって、使用するバンド幅、および必要とされる付加的なバンド幅を計算する。利用可能なバンド幅（例えばＡＤＳＬ）から、通信装置は、この要求が修正なしで送信するか、より低い品質のストリームにリダイレクトされなければならないかまたは、予め設定されたマルチメディア・ファイルを伝達することを拒否されなければならないかどうかを決める。

実施例において、サービス・プランは、ネットワークで利用するために、ユーザの住宅に、いくつかのデコーダを設置する申し込みを要求する場合がある。申し込みはユーザ毎に異なるか、ＩＰ当たり異なってもよい：ポートアドレスは、サービス毎にユニークである。

各サービスにかかわるパラメータのリストは、ゲートウェイの機能によって異ならせてもよい。

特定の実施例では、ゲートウェイに供給されるサービス・プランは、以下の形を有する：すなわち、サービス名、ＩＰ：ポート・サービスアドレス、ビデオ符号化タイプ、音声符号化タイプ、サービスビットレートＫｂｉｔ／ｓである。

本発明において、正しい符号化フォーマットの情報を送信するためには、ゲートウェイはビデオおよびおそらく音声（声のメッセージがユーザに提供される場合）のコーデックの形式を知っていることを必要とする。ゲートウェイは、接続したデコーダのキャパシティを知らない。しかし、デコーダがその復号の能力に対応しないストリームを要求しないと仮定してもよい。

サービス・プランの例を表１に示す。

実際には、サービス・プランが、必ずしも表形式であるというわけではない。

デコーダ（セットトップボックス）とＩＧＭＰスイッチ／ルーターの間に通過しているＩＧＭＰプロトコルによって、ゲートウェイ（例えばＡＤＳＬ）は、ネットワークに接続されている装置が受け入れるストリームの全てを知ることができ、受信されたストリームからテーブルを作成する。

このストリームの表は、転送先の受信器のアドレスに係る受信されたストリームに対応するＩＰアドレスをパラメータとして有する。

ストリーム・テーブルは、ペアのリストである。したがって、このペアは、ソース・ストリームのＩＰアドレスと関連した転送先のＩＰアドレスのペアを含む。

例えば、その例を表２に示す。

実際には、ストリーム・テーブルが、必ずしも表形式であるというわけではない。ゲートウェイは、前記受信器／デコーダからの要求の受信に応じて、低い品質のストリームの要求に変更してもよい。ＩＧＭＰパケットに行う修正は、本明細書において説明する。ＩＧＭＰプロトコルは、ＲＦＣ２２３６によって定義される。

ＩＧＭＰパケットは、８つのオクテットで形成される。図４にその書式を示す。
・タイプ（Ｔｙｐｅ）には、送信されるコマンドが記述されている。
・最大応答時間（ＭａｘＲｅｓｐＴｉｍｅ）には、プロトコルを実装するステートマシンにおいて使用するタイマーの値が記述されている。
・チェックサムは、パケットデータの完全性を補償する。
・グループアドレスには、ユーザが、サブスクライブあるいは離れる（ｌｅａｖｅ）グループのマルチキャストアドレスが記述されている。

ゲートウェイは、アクセスするネットワークに発信する前にセットトップボックス（ＳＴＢ）から受信するＩＧＭＰ要求を修正することを可能にするリソースを有する。

このため、例えば、ＳＴＢの要求より低い品質のストリームを受信するために、サービステーブルから、ＴｙｐｅＭｅｍｂｅｒｓｈｉｐＲｅｐｏｒｔ（０ｘ１６）コマンドのグループアドレスのフィールドが修正される。

ＴｙｐｅＬｅａｖｅＧｒｏｕｐ（０ｘ１７）の要求にも、同じ修正を行なわなければならない点に留意する必要がある。

同様に、操作がＳＴＢに対して透明であるようにするため、アクセスネットワークから受信されるＴｙｐｅＭｅｍｂｅｒｓｈｉｐＱｕｅｒｙ（０ｘ１１）に対しては、グループアドレスのフィールドを修正してＳＴＢに送信する。

ゲートウェイは、以下の通りに進行してもよい：すなわち、ＩＧＭＰ要求をアクセスすべきネットワークに発信せず、そして、それ自身が、ビデオストリームを作り出し、おそらくそれがマルチキャストパケットの形で静止画像（ｆｉｘｅｄｉｍａｇｅ）を表して、ＳＴＢに発信するようにしてもよい。

以下に、ＩＧＭＰ要求が拒否され、マルチメディア・ファイルが伝達される場合を詳述する。

図１に示されるように、住宅用ゲートウェイは、そのコンフィギュレーション表に、ビデオ・ファイルがＨＴＴＰによって読み出されるＵＲＬ（ＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅＬｏｃａｔｏｒ）を含む。このビデオ・ファイルは、フォーマッティングの後、ループした形で、マルチキャスト・ストリームとしてゲートウェイによってＳＴＢに発信される。このため、ＡＤＳＬバンド幅が、ループの配信の間、使われないこととなる。

このファイルは、要請されたチャネルが配信されない理由をユーザに説明している情報を含む（例えば：あなたのＡＤＳＬサブスクリプションは、２つの高精細ストリームの同時表示を許容しておりません。あなたの回線の要領を増加させるためには、次のＵＲＬにアクセスしてください：ｈｔｔｐ：／／ｗｗｗ．ｏｒａｎｇｅ−ｆｔ．ｃｏｍ）。それがビデオ・ファイルとして、アニメーション（および声のメッセージ）を含んでもよい。

「サービス・プラン」を検索することによって、マルチキャストアドレスごとに、ビデオおよび使用するコーデックを通信装置が知ることができる。送信されるこの予め設定されたマルチメディア・ファイルは、同様の方式でエンコードされている。

本発明は、上述した説明において例として記載されている。当業者は、特許の範囲を超えることなく、本発明の変形例を作り出すことができるものと理解される。

Claims

一方が通信ネットワークに接続され、他方が少なくとも一つの受信器／デコーダに接続される通信装置であって、前記受信器／デコーダからの要求の受信に応答して、前記通信ネットワークの利用可能なバンド幅に基づき、以下の異なる可能性について選択するための手段：
・前記要求を変更せずに通信ネットワークに伝送すること；または、
・より低い品質のストリームを求めるために要求を変更すること；または、
・前記要求をネットワークに伝送することを拒否し、かつ受信器／デコーダに予め設定されたマルチメディア・ファイルを送ること、
を有する通信装置。
すべてのマルチキャストアドレス、および少なくとも一つの対応するストリームの特徴、例えばプログラム名、使用するコーデックまたは使用するバンド幅、を含んでいるサービス・プランを操作するための手段、
を有する請求項１記載の通信装置。
前記要求は、確認されたＩＧＭＰ要求によって確立し、当該通信装置に接続している受信器／デコーダの各々に受信されているストリームの表を操作するための手段、
を有する請求項１または２記載の通信装置。
前記サービス・プランおよび前記ストリームの表から、通信ネットワークに使用されているバンド幅を計算するための手段および、新しいＩＧＭＰ要求の新しいオンデマンドのストリームの受信のために必要とされる、通信ネットワークのバンド幅を計算するための手段、
を有する請求項２または３に記載の通信装置。
ＡＤＳＬ（非同期デジタル加入者回線）と互換性を持つ、請求項１、２、３または４のいずれか１項記載の通信装置。
コンフィギュレーション表にＵＲＬ（ＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅＬｏｃａｔｏｒ）を有し、かつ前記ＵＲＬから前記予め設定されたマルチメディア・ファイルを読み出すための手段、および前記マルチメディア・ファイルを前記受信器／デコーダにマルチキャスト・ストリームの状態で、およびループの状態で送信するための手段、
を有する請求項１ないし５のいずれか１項記載の通信装置。
前記マルチメディア・ファイルは、ＨＴＴＰプロトコル（ＨｙｐｅｒｔｅｘｔＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ）によって、前記ＵＲＬから読み出される、請求項６記載の通信装置。
前記マルチメディア・ファイルをフォーマットするための手段、を有する請求項６または７記載の通信装置。
前記マルチメディア・ファイルは、ビデオを含む、請求項１ないし８のいずれか１項記載の通信装置。
前記マルチメディア・ファイルは、アニメーションを含む、請求項１ないし９のいずれか１項記載の通信装置。
前記マルチメディア・ファイルは、音声メッセージを含む、請求項１ないし１０のいずれか１項記載の通信装置。
変調および復調するための手段、を有する、請求項１ないし１１のいずれか１項記載の通信装置。
一方が通信ネットワークに接続され、他方が少なくとも一つの受信器／デコーダに接続される通信装置を使用した通信方法であって、前記受信器／デコーダからの要求の受信に応答して、前記通信ネットワークの利用可能なバンド幅に基づき、以下の異なる可能性について選択するステップ：
・前記要求を変更せずに通信ネットワークに伝送すること；または、
・より低い品質のストリームを求めるために要求を変更すること；または、
・前記要求をネットワークに伝送することを拒否し、かつ受信器／デコーダに予め設定されたマルチメディア・ファイルを送ること、
を有する通信方法。
すべてのマルチキャストアドレス、および少なくとも一つの対応するストリームの特徴、例えばプログラム名、使用するコーデックまたは使用するバンド幅、を含んでいるサービス・プランを操作するステップ、
を有する請求項１３記載の通信方法。
前記要求は、確認されたＩＧＭＰ要求によって確立し、該通信装置に接続している受信器／デコーダの各々に受信されているストリームの表を操作するステップ、
を有する請求項１３または１４記載の通信方法。
前記サービス・プランおよび前記ストリームの表から、通信ネットワークに使用されているバンド幅を計算するステップおよび、新しいＩＧＭＰ要求の新しいオンデマンドのストリームの受信のために必要とされる、通信ネットワークのバンド幅を計算するステップ、
を有する請求項１４または１５に記載の通信方法。
コンフィギュレーション表にＵＲＬ（ＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅＬｏｃａｔｏｒ）を有し、かつ前記ＵＲＬから前記予め設定されたマルチメディア・ファイルを読み出すためのステップ、および前記マルチメディア・ファイルを前記受信器／デコーダにマルチキャスト・ストリームの状態で、およびループの状態で送信するステップ、
を有する請求項１３ないし１６のいずれか１項記載の通信方法。