JP2012513129A - Ｉｐｔｖセッションをセットアップするためのネットワーク装置及び方法 - Google Patents

Abstract

本発明は、ネットワーク装置とネットワーク装置における方法とに関する。ネットワーク装置は、ローカルネットワークに接続するためのコネクタと、利用可能なコンテンツと当該コンテンツが入手可能なローカルネットワークにおけるアドレスとに関する情報をローカルネットワークにあるセットトップボックスに提供するサーバと、当該コンテンツと第２ネットワークにあるＩＰＴＶサーバからアクセス可能なＩＰＴＶコンテンツとをマッチングするＩＰＴＶプロキシサーバとを有するネットワーク装置し、第２ネットワークはゲートウェイ装置を有する第１ネットワークとの接続を開始し、アドレスにおけるコンテンツをリクエストしたセットトップボックスがＩＰＴＶサーバからＩＰＴＶコンテンツを受信する。

Description

本発明は、一般にＩＰＴＶに関し、特にＩＰＴＶセッションをセットアップするための装置及び方法に関する。

このセクションは、以下で説明及び／又は請求される本発明の各種特徴に関連する様々な技術的特徴を読者に紹介するためのものである。この説明は、本発明の各種特徴のより良好な理解を促進するための背景情報を読者に提供するのに役立つと信じられる。従って、これらの説明はこの観点から読まれるべきであり、従来技術の自認としてみなされるべきでないことが理解されるべきである。

インターネットプロトコルテレビ（ＩＰＴＶ）は、ＩＰＴＶサーバとＩＰＴＶクライアントとの間でエンド・ツー・エンドに一般に行き渡っている。ホームネットワークにいるクライアントは、インターネット上にあるＩＰＴＶサーバのＩＰＴＶコンテンツにアクセスする。サーバは、ホームネットワークにはない。ホームネットワークにいる各クライアントは、個別にサーバに接続してＩＰＴＶコンテンツを取得する。クライアントは、ＩＥＴＦ ＲＦＣ２２３６に規定されるようなＩＧＭＰ（Ｉｎｔｅｒｎｅｔ Ｇｒｏｕｐ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）などを用いて、マルチキャストアドレスに登録する。

Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ産業コンソーシアムは、ホームネットワークのための基準モデルを指定した。これは、“ＤＶＢ−ＨＮ（Ｈｏｍｅ Ｎｅｔｗｏｒｋ） Ｒｅｆｅｒｅｎｃｅ Ｍｏｄｅｌ Ｐｈａｓｅ １；ＤＶＢ Ｄｏｃｕｍｅｎｔ Ａ１０９；Ｆｅｂｒｕａｒｙ ２００７”であり、ＤＶＢ−ＨＮにより以降において参照される。ＤＶＢ−ＨＮは、ＩＰベースネットワークを介したＭＰＥＧ−２トランスポートストリームベースのＤＶＢサービスのトランスポートのためのホームネットワークの基準モデルを提案する。ＭＰＥＧ−２トランスポートストリームは、ＥＴＳＩ ＴＳ １０２ ０３４ ｖ１．３．１としても参照される“Ｔｒａｎｓｐｏｒｔ ｏｆ ＭＰＥＧ ２ Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍ（ＴＳ） Ｂａｓｅｄ ＤＶＢ Ｓｅｒｖｉｃｅｓ ｏｖｅｒ ＩＰ Ｂａｓｅｄ Ｎｅｔｗｏｒｋｓ；ＤＶＢ Ｄｏｃｕｍｅｎｔ Ａ０８６ Ｒｅｖ．３；Ｍａｒｃｈ ２００７”に規定されるＤＶＢ ＩＰフェーズ１プロトコルを用いてブロードバンドアクセスネットワークを介し送信され、ＤＶＢ−ＩＰにより以降において参照される。特に、ＤＶＢ−ＩＰは、双方向ＩＰネットワーク上のＤＶＢベースＡ／ＶサービスのためのＳｅｒｖｉｃｅ Ｄｉｓｃｏｖｅｒｙ ａｎｄ Ｓｅｌｅｃｔｉｏｎ（ＳＤ＆Ｓ）機構を規定する。サービス検出は、双方向ＩＰネットワーク上で利用可能なＤＶＢ−ＩＰサービスの検出を可能にする機構である。サービス検出は、受信機における情報によりサービスのリストを提供し、ユーザがサービスを選択し、選択されたサービスにアクセスすることを可能にする。

図１は、ＤＶＢ−ＨＮによるホームネットワークを示す。それは、ホームネットワーク５とアクセスネットワーク７とを接続するためのルーティング手段を有する、以降においてＨＧにより示されるホームゲートウェイ１を有する。ホームネットワーク５に接続されるＩＰＴＶ ＳＴＢ２は、アクセスネットワーク７を介しＩＰＴＶサーバ６上のコンテンツにアクセスする。ＩＰＴＶ ＳＴＢは、ＳＤ＆Ｓクライアントモジュール２１を有し、サーバは、ＳＤ＆Ｓサーバモジュール６１を有する。ＩＰＴＶ ＳＴＢによりサービスが検出及び選択されると、ＩＰＴＶストリーム８がアクセスネットワークを介しＩＰＴＶ ＳＴＢに送信される。それは、ＩＥＴＦ ＲＦＣ３５５０によりリアルタイムトランスポートプロトコル（ＲＴＰ）を用いてマルチキャストモードにより送信される。

ＤＶＢ−ＨＮはまた、“ＵＰｎＰ ＣＤＳ：ＵＰｎＰ Ｃｏｎｔｅｎｔ Ｄｉｒｅｃｔｏｒｙ Ｓｅｒｖｉｃｅ Ｔｅｍｐｌａｔｅ Ｖｅｒｓｉｏｎ １．０１”においてさらに定義されるコンテンツディレクトリサービスを定義する。ＵＰｎＰ ＣＤＳは、各装置が他の装置により提供可能なコンテンツを特定することを可能にする。曲、映画、写真などのほぼ任意のタイプのコンテンツが、このサービスを介し列挙可能である。セットトップボックスなど、以降においてＨＮ ＳＴＢと呼ばれるＤＶＢ−ＨＮクライアントが、このコンテンツ検出サービスを用いてホームネットワークにあるパーソナルビデオレコーダで利用可能なＭＰＥＧ−２サービスにアクセスする。それは、通常はＵＰｎＰ ＣＤＳ処理を実行するためのＣＤＳクライアントモジュールを有する。ＤＶＢ−ＨＮは、ＤＬＮＡガイドラインＩＥＣ６２４８１−１ Ｅｄ．１とＩＥＣ６２４８１−２ Ｅｄ．１とを再利用している。ＩＥＣ６２４８１−１ Ｅｄ．１は、“ＤＬＮＡ Ｎｅｔｗｏｒｋｅｄ Ｄｅｖｉｃｅ Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｇｕｉｄｅｌｉｎｅｓ ｅｘｐａｎｄｅｄ Ｍａｒｃｈ ２００６ Ｖｏｌｕｍｅ １：Ａｒｃｈｉｔｅｃｔｕｒｅ ａｎｄ Ｐｒｏｔｏｃｏｌｓ”に対応する。ＩＥＣ６２４８１−２ Ｅｄ．２は、“ＤＬＮＡ Ｎｅｔｗｏｒｋｅｄ Ｄｅｖｉｃｅ Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｇｕｉｄｅｌｉｎｅｓ ｅｘｐａｎｄｅｄ Ｍａｒｃｈ ２００６ Ｖｏｌｕｍｅ ２：Ｍｅｄｉａ Ｆｏｒｍａｔ Ｐｒｏｆｉｌｅｓ”に対応する。特に、ＤＶＢ−ＨＮクライアントは、ＵＰｎＰ ＣＤＳをサポートすることによって、ＤＬＮＡサーバにより示されるメタデータを抽出可能である。それは、ＤＬＮＡサーバ上で利用可能なコンテンツを抽出するため、トランスポート及びセッションマネージメントプロトコルとしてＨＴＴＰをサポートする。

図１はまた、ＵＰｎＰ ＣＤＳ及びＤＬＮＡによるホームネットワーク内のコンテンツ配信を示す。ＨＮ ＳＴＢ３は、ＣＤＳサーバモジュール４１を有するＨＮサーバ４上のコンテンツにアクセスする。ＨＮ ＳＴＢは、サーバ４のＣＤＳサーバモジュール上のコンテンツを特定するよう構成されるＣＤＳクライアントモジュール３１を有する。ＨＮサーバ上でコンテンツが選択されると、ＨＮストリーム９がホームネットワークを介しＨＮ ＳＴＢに送信される。ＨＮストリームは、ＩＥＴＦ ＲＦＣ２６１６によるＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）によりユニキャストモードによって送信される。それはまた、ＲＴＰを用いて送信され、ＩＥＴＦ ＲＦＣ２３２６によりリアルタイムストリーミングプロトコル（ＲＴＳＰ）セッションによって制御されてもよい。それは、ＨＮ ＳＴＢのみに送信される。

ＤＶＢ−ＩＰＴＶ規格によると、ＩＰＴＶコンテンツを受信することを所望するクライアントは、ＳＤ＆Ｓクライアントモジュールを実装する。このとき、クライアントはＩＰＴＶ ＳＴＢとなる。

ＳＤ＆Ｓモジュールを有しないＨＮ ＳＴＢは、ＩＰＴＶストリームを直接受信することはできない。しかしながら、ＩＰＴＶストリームは、ゲートウェイにあるプロキシ機能を介しアクセス可能とされてもよい。ＲＴＰ送信プロトコルは、ホームネットワークにおいて使用され、ＣＤＳモジュールとＲＴＳＰモジュールとはホームゲートウェイに統合される。従って、検出はＣＤＳを用いて実行される。ＲＴＳＰセッションはホームネットワークにローカルであり、マルチキャストはＨＮ ＳＴＢのためにユニキャストに変換可能である。トランスポートプロトコル変換は実行されない。ホームにおいてＲＴＰを利用する代わりに、ＨＴＴＰが利用されてもよく、ＲＴＰからＨＴＴＰへのトランスポートプロトコル変換がゲートウェイにおいて必要とされる。このトランスポートプロトコル変換は、マルチキャストからユニキャストへの変換が実行されるとき、それに加えて実行される。

双方のケースにおいて、ＨＧは複合的な装置である必要がある。それは、ＳＤ＆Ｓメタデータ全体を処理し、それらをＣＤＳメタデータに変換し、変換されたメタデータをそれの内部メモリに格納する。それは、ＲＴＳＰセッションを管理する必要があり、このためＲＴＳＰサーバの完全な実装を必要とする。それは、プッシュモードのＲＴＰストリームをプルモードのＨＴＴＰパケットに変換する必要がある。

本発明は、ＩＰＴＶプロキシ機能を実行するための装置を提供することによって、従来技術による複合的なゲートウェイ装置に関する問題点の少なくとも一部を解消しようとする。

本発明は、ローカルネットワークに接続するためのコネクタと、利用可能なコンテンツと当該コンテンツが入手可能なローカルネットワークにおけるアドレスとに関する情報をローカルネットワークにあるセットトップボックスに提供するサーバと、当該コンテンツと第２ネットワークにあるＩＰＴＶサーバからアクセス可能なＩＰＴＶコンテンツとをマッチングするＩＰＴＶプロキシサーバとを有するネットワーク装置であって、第２ネットワークはゲートウェイ装置を有する第１ネットワークとの接続を開始し、アドレスにおけるコンテンツをリクエストしたセットトップボックスがＩＰＴＶサーバからＩＰＴＶコンテンツを受信するネットワーク装置に関する。

ネットワーク装置は、ＨＮ ＳＴＢなどのローカルネットワークにあるセットトップボックスがローカルネットワークの外部にあるＩＰＴＶサーバからＩＰＴＶコンテンツを受信することを可能にする。ＳＴＢは、ＩＰＴＶサーバからＩＰＴＶコンテンツを直接受信することはできない。ネットワーク装置は、ＳＴＢとサーバとの間のプロキシとして機能する。ＳＴＢは、コンテンツがＩＰＴＶコンテンツであることを認識していない。それは、ネットワーク装置において利用可能なコンテンツを選択する。コンテンツは、オーディオビデオコンテンツなどのマルチメディアコンテンツとして提供される。コンテンツをＳＴＢに直接提供する代わりに、ネットワーク装置は、ＳＴＢがＩＰＴＶサーバからコンテンツを受信できるように、ＩＰＴＶサーバとの接続に着手する。

実施例によると、コンテンツがネットワーク装置において利用可能である場合、セットトップボックスからコンテンツにアクセスするためのリクエストを受信すると、ＩＰＴＶプロキシは、第２ネットワークにあるＩＰＴＶサーバとのＩＰＴＶセッションに加入するリクエストを送信し、その後、ＩＰＴＶコンテンツはセットトップボックスに配信される。

コンテンツがネットワーク装置において利用可能である場合、当該装置は、ＩＰＴＶセッションに加入するリクエストをＩＰＴＶサーバに直接送信する。

実施例によると、コンテンツが第２装置において利用可能である場合、ＩＰＴＶプロキシは、コンテンツに対応するＩＰＴＶセッションを第２装置に通知する。

コンテンツが他の装置において利用可能である場合、ＩＰＴＶプロキシは、コンテンツとＩＰＴＶストリームとの間の対応関係に関する情報を当該装置に利用可能にする。

実施例によると、ネットワーク装置は、セットトップボックスがコンテンツにアクセスすることを可能にするＲＴＳＰサーバを有する。

ＳＴＢは、情報を利用可能にするため、ネットワーク装置のＲＴＳＰサーバとのＲＴＳＰセッションをセットアップする。

実施例によると、ネットワーク装置は、セットトップボックスがコンテンツにアクセスすることを可能にするためＨＴＴＰサーバを有する。

ＳＴＢは、情報を利用可能にするため、ネットワーク装置のＨＴＴＰサーバとのセッションをセットアップする。

実施例によると、ネットワーク装置は、利用可能なコンテンツに関する情報をセットトップボックスに提供するためＣＤＳサーバを有する。

本発明の他の課題は、ローカルネットワークと第２ネットワークとを接続するよう構成されるゲートウェイを有するローカルネットワークにあるセットトップボックスと第２ネットワークにあるＩＰＴＶサーバとの間のＩＰＴＶ通信をセットアップするためのネットワーク装置における方法であって、利用可能なコンテンツとコンテンツが入手可能なローカルネットワークにおけるアドレスとに関する情報を提供するステップと、コンテンツがネットワーク装置において利用可能である場合、コンテンツを受信するためのリクエストをセットトップボックスから受信すると、ＩＰＴＶコンテンツがセットトップボックスに配信されるように、第２ネットワークにあるＩＰＴＶサーバとのＩＰＴＶセッションに加入するリクエストを送信するステップと、コンテンツがローカルネットワークにある第２装置において利用可能である場合、ＩＰＴＶコンテンツがセットトップボックスに配信されるように、コンテンツに対応するＩＰＴＶセッションを第２装置に通知するステップとを有する方法である。

実施例によると、ネットワーク装置は、第２装置からのリクエストの受信後、コンテンツに対応するＩＰＴＶセッションを第２措置に通知する。

本発明の他の課題は、コンピュータ上で実行されると、本発明による方法のステップを実行するプログラムコード命令を有するコンピュータプログラムである。“コンピュータプログラム”は、ディスケットやカセットなどのプログラムを含む格納スペースだけでなく、電気又は光信号などの信号において構成されるコンピュータプログラムサポートを意味する。

開示される実施例に関する特徴が、以下に提供される。これらの特徴は読者に本発明がとりうる形態の概略を提供するためのものにすぎず、これらの特徴は本発明の範囲を限定するものでないことが理解されるべきである。実際、本発明は、以下に与えられない各種特徴を網羅する。

図１は、従来技術によるホームネットワークを示す。 図２は、第１実施例によるホームネットワークを示す。 図３は、実施例によるチューナ装置のブロック図である。 図４は、第１実施例によるＨＮ ＳＴＢとＩＰＴＶサーバとの間でＩＰＴＶセッションをセットアップするのに用いられるメッセージのフロー図である。 図５は、第１実施例の変形によるＨＮ ＳＴＢとＩＰＴＶサーバとの間でＩＰＴＶセッションをセットアップするのに用いられるメッセージのフロー図である。 図６は、第２実施例によるホームネットワークを示す。 図７は、第２実施例によるＨＮ ＳＴＢとＩＰＴＶサーバとの間でＩＰＴＶセッションをセットアップするのに用いられるメッセージのフロー図である。 図８は、第３実施例によるホームネットワークを示す。 図９は、第３実施例によるＨＮ ＳＴＢとＩＰＴＶサーバとの間でＩＰＴＶセッションをセットアップするのに用いられるメッセージのフロー図である。 図１０は、第４実施例によるホームネットワークを示す。 図１１は、第４実施例によるＨＮ ＳＴＢとＩＰＴＶサーバとの間でＩＰＴＶセッションをセットアップするのに用いられるメッセージのフロー図である。 図面において、図示されたブロックは純粋に機能的なエンティティであり、必ずしも物理的に別々のエンティティに対応するとは限らない。すなわち、それらは、ハードウェア又はソフトウェアの形態により開発可能であり、又は１以上の集積回路により実現可能である。

図２において、本発明の第１実施例によるシステムが示される。ホームゲートウェイ装置は、ＩＰＴＶプロキシモジュール１．１と、ＲＴＳＰサーバモジュール１．２と、ＭＣ／ＵＣと呼ばれるマルチキャスト・ツー・ユニキャスト送信モジュール１．３とを有する。ＩＰＴＶプロキシモジュール１．１は、後述されるようなＩＰＴＶプロキシ機能を実行するよう構成される。特に、それは、チャネルのアドレスを取得するためのリクエストをＲＴＳＰサーバ１．２から受信する。当該リクエストを受信すると、それは、アドレスを取得するためのリクエストを後述されるようなチューナに送信する。ゲートウェイＲＴＳＰサーバは、ＩＰＴＶプロキシと通信するためのモジュールを備えたＩＥＴＦ ＲＦＣ ２３２６に準拠している。

従来技術によるシステムに加えて、システムは、以降においてＢＢＴ又はチューナと呼ばれるブロードバンドチューナ１０を有する。チューナは、ＩＰＴＶプロキシモジュール１０１を有する。それは、後述されるようなＩＰＴＶプロキシ機能を実行するよう構成される。特に、図４に示されるように、それはチャネル識別子とマルチキャストアドレスとの間の対応関係を管理する。ゲートウェイＩＰＴＶプロキシからのチャネルに対するリクエストに対して、それは、チャネルに対応するマルチキャストアドレスを提供する。当該マルチキャストアドレスは、チューナのＳＤ＆Ｓクライアント１０５によってＳＤ＆Ｓサーバ６１から以前に受信されたものである。ＳＤ＆Ｓクライアントによる受信後、マルチキャストアドレスはデータベースに格納され、ＩＰＴＶプロキシによりアクセス可能となる。

第１実施例によると、チューナは、ＣＤＳサーバモジュール１０２を有する。それは、ＣＤＳクライアントモジュールを有するホームネットワークの何れかのＨＮ−ＳＴＢによりＣＤＳ機能を実行するよう構成される。

より一般には、チューナＩＰＴＶプロキシモジュールは、ＣＤＳモジュールに構成されてもよい。

マルチキャスト・ツー・ユニキャスト変換は、レイヤ３、すなわち、ＩＰレイヤにおけるものである。マルチキャストＩＰアドレスは、パケットの他の何れも変更することなく送信先のＨＮ ＳＴＢ装置のユニキャストＩＰアドレスに変換される。ＵＤＰやＲＴＰなどの上位のプロトコルレイヤスタックの残りは、特段の記載がない場合には変更されないままである。ＲＴＳＰサーバモジュール１．２は、ＩＥＴＦ ＲＦＣ ２３２６に準拠する。

図４は、ＨＮ ＳＴＢとＩＰＴＶサーバとの間でＩＰＴＶセッションをセットアップするのに用いられるメッセージのフロー図である。ステップＳ１において、ＨＮ ＳＴＢは、ＣＤＳを用いて利用可能なサービスを確認するため、チューナをブラウズする。ステップＳ２において、それは、ＩＰＴＶストリームがプレミアムチャネルであるチャネル上で利用可能であるという情報をブロードバンドチューナから取得する。

ステップＳ３において、ＨＮ ＳＴＢは、ゲートウェイのＲＴＳＰサーバにＲＴＳＰ ＳＥＴＵＰメッセージを送信する。ＲＴＳＰ ＳＥＴＵＰメッセージは、ストリームがどのように送られるか指示する。メッセージは、ストリームとチャネルに関する情報を有する。それは、アクセスネットワークのＩＰＴＶストリームに関する情報を有しない。その後、ステップＳ４において、ゲートウェイＩＰＴＶプロキシは、チューナのＩＰＴＶプロキシから当該情報をリクエストし、ステップＳ５において、チューナのＩＰＴＶプロキシは、当該ＲＴＳＰセッションのマルチキャストアドレスにより応答する。その後、ゲートウェイは、アクセスネットワーク側でマルチキャスト接続を実行し、受信したＩＰＴＶパケットをＨＮ ＳＴＢにユニキャストモードにより転送するため、自らのルーティングテーブルを設定する。ＲＴＳＰ ＳＥＴＵＰに応答して、ステップＳ６において、ゲートウェイは、ＲＴＳＰ ＯＫメッセージをＨＮ ＳＴＢに送信する。その後、ステップＳ７において、ＨＮ ＳＴＢは、ストリームを再生するため、ＲＴＳＰ ＰＬＡＹメッセージをＲＴＳＰサーバに送信する。これにより、ステップＳ８において、ゲートウェイはマルチキャストグループに加入することになる。その後、ＭＣ／ＵＣモジュールは、マルチキャストストリームを受信し、当該ストリームをＨＮ ＳＴＢに送信されるユニキャストストリームに変換する。単一のストリームであるユニキャストストリームは、ホームネットワーク上に送信される。その後、当該ストリームは、ホームネットワーク上で管理及び制御される。もちろん、ストリームは、ユニキャストに変換されなくてもよく、ホームネットワーク上にマルチキャストストリームとして送信されてもよい。

本実施例によると、ゲートウェイＩＰＴＶプロキシとチューナとの間の通信は、ＵＰｎＰ機構を用いて実行される。ゲートウェイＩＰＴＶプロキシは、何れのＣＤＳがこのＲＴＳＰのＵＲＬをＨＮ ＳＴＢに提供していたかに関する事前の知識はない。従って、それは、ＨＮにあるすべてのＣＤＳにリクエストを送信する。このＲＴＳＰ ＵＲＬの知っているものだけが、ＣＤＳに回答する。また、外部のＩＰＴＶサービスを処理するＣＤＳを、それのデバイス記述において特別なＸＭＬタグを有する特別なＣＤＳとして明示することが可能である（例えば、“ＩＰＴＶ ＣＤＳ”など）。従って、ゲートウェイのみが、リクエストに対してこのＣＤＳをターゲットする。変形の実施例によると、ゲートウェイＩＰＴＶプロキシが直接抽出するため、ＣＤＳ識別子をＲＴＳＰ ＵＲＬに含めることも可能である。例えば、以下のＵＲＬが、ＣＤＳ識別子１２３４５６７８９０ＡＢＣＤＥＦを構成する。

チューナのＣＤＳは、

のようなパラメータを抽出するアクションを実行する。

これは、以下に示されるようなＸＭＬベースのメッセージである。

第１実施例の変形によると、ステップＳ２において、ＨＮ ＳＴＢは、本発明の範囲外の方法によりマルチキャストアドレス情報を直接取得する。ゲートウェイがマルチキャストＩＰＴＶストリームに接続するための情報は、ＣＤＳにより提供されるＲＴＳＰ ＵＲＬに含まれる。図５に示されるように、ＲＴＳＰ ＵＲＬは、ストリームがＲＴＰベースであることを示す“ｒｔｐ”部分を有し、“２２４．１２．３４．５６”は、それを検出するためのマルチキャストアドレスを通知する。ポート番号もまた追加できる。

このとき、ゲートウェイとチューナとの間には通信は必要とされない。本実施例では、ステップＳ４及びＳ５は不要である。ＲＴＳＰ ＰＬＡＹを受信すると、ゲートウェイはマルチキャストグループに加入する。

第２実施例によると、ＲＴＳＰサーバとＣＤＳサーバの各モジュールは共に、図６に示されるようにチューナ装置内に設けられる。このとき、ホームゲートウェイの機能は、ルーティングパケットに集中される。すべての検出及び管理タスクは、チューナ装置内で実行される。再び、１つのストリームのみ、すなわち、ユニキャストストリームがホームネットワーク上に送信される。ストリームはまた、ユニキャストに変換されなくてもよく、ホームネットワーク上でマルチキャストストリームとして送信されてもよい。

図７に示されるように、ステップＳ１６において、チューナとゲートウェイとの間の通信は、加入マルチキャストメッセージに限定される。チューナは、接続するマルチキャストアドレスと、ＨＮ ＳＴＢの宛先ＩＰアドレスとを示す。これら２つの情報によって、ステップＳ１７において、ＨＧは、ＩＧＭＰ接続を実行し、ＨＮ内の正しい宛先へのマルチキャスト・ツー・ユニキャスト変換を実行可能である。

本実施例によると、チューナとＨＧとの間の通信は、ＵＰｎＰ機構を用いて実行される。ＨＧは、チューナによりこのような情報を提供するよう呼び出される特定のアクションを有する特定のＩＰＴＶプロキシＵＰｎＰモジュールを有する。

これは、以下に示されるＸＭＬベースのメッセージである。

第３実施例によると、図８に示されるように、ＩＰＴＶストリームはＲＴＰからＨＴＴＰに変換され、もちろん、マルチキャストからユニキャストに変換される。この変換は、ホームゲートウェイにおいて実行される。ホームゲートウェイは、ＩＰＴＶプロキシモジュール１．１と、ＭＣ／ＵＣモジュール１．３と、ＨＴＴＰモジュール１．２１と、ＲＴＰ／ＨＴＴＰ変換モジュール１．２２とを有する。

図９に示されるように、ＨＴＴＰサーバは、ＨＮ ＳＴＢからＨＴＴＰ ＧＥＴのみを受信する。このメッセージは、アクセスネットワークのＩＰＴＶストリームに関する情報を有しない。その後、ＨＴＴＰサーバは、ＣＤＳからこの情報をリクエストし、ＣＤＳは、当該ＨＴＴＰセッションのマルチキャストアドレスにより応答する。その後、ＨＧは、アクセスネットワーク側においてマルチキャスト接続を実行し、ユニキャストＨＴＴＰモードにより受信したマルチキャストＲＴＰ ＩＰＴＶパケットをＨＮ ＳＴＢに転送するため、それのルーティングテーブルとトランスポートプロトコル変換を設定する。

第３実施例の変形によると、ステップＳ２において、ＨＮ ＳＴＢは、マルチキャストアドレスを直接取得する。ゲートウェイがマルチキャストＩＰＴＶストリームに接続するための情報は、ＨＴＴＰ ＧＥＴに含まれる。特に、それは、ストリームがＲＴＰベースであることを示す“ｒｔｐ”パラメータを有し、“２２４．１２．３４．５６”は、それを検出するためのマルチキャストアドレスを通知する。ポートもまた追加することが可能である。

図１０に示される第４実施例によると、ＨＴＴＰサーバはチューナ装置内に設けられる。このとき、ホームゲートウェイの機能はルーティングパケットに集中される。図１１に示されるように、すべての検出及び管理タスクはチューナ装置内で実行される。ＲＴＰストリームは、ＲＴＰからＨＴＴＰへの変換を実行するブロードバンドチューナ装置に送信される。その後、それは、ＨＴＴＰストリームをＨＮ ＳＴＢに送信する。

第４実施例の変形では、ＨＧは、マルチキャストからユニキャストへの変換を実行しない。マルチキャストストリームは、チューナに送られる。ゲートウェイは、マルチキャストストリームをどこに送信するか知るため、チューナからＩＰＴＶサーバへのＩＧＭＰメッセージをモニタするＩＧＭＰ監視手段を有する。その後、ブロードバンドチューナは、ＲＴＰからＨＴＴＰへの変換を実行し、ユニキャストＨＴＴＰストリームをＨＮ ＳＴＢに送信する。

より一般には、チューナ装置１０は図３において機能的に示される。それは、サービス及びコンテンツ検出サービスを提供する検出モジュール１０．２を有する。第１実施例によると、検出手段は、ＣＤＳモジュールに備えられる。

本実施例に示されるように、チューナ装置は、ホームネットワークにおけるセッションを管理する管理モジュール１０．１を有してもよい。本実施例によると、セッション管理は、ＲＴＳＰ又はＨＴＴＰに備えられる。

それはまた、コンテンツを送信する、特にＩＰＴＶサーバからマルチキャストモードによりコンテンツを受信し、ユニキャストモードによりコンテンツをクライアントに配信する送信モジュール１０．３を有してもよい。

それはまた、プロセッサ１０．４と、ホームネットワークとのインタフェースのための通信モジュール１０．５とを有する。特に、通信モジュール１０．５は、イーサネット（登録商標）又はＷｉ−Ｆｉネットワークを介し通信するイーサネット（登録商標）インタフェース又はＷｉ−Ｆｉインタフェースである。それはまた、低速通信手段と高速通信手段との組み合わせとすることも可能である。

チューナは、ホームネットワークの何れかの装置、特にＳＴＢに埋め込むことが可能である。それはまた、スタンドアローン装置とすることも可能である。

ホームネットワークは、必ずしも同質なネットワークである必要はない。それは、高速イーサネット（登録商標）又はギガビットイーサネット（登録商標）などの高速部分と共に、Ｗｉ−ＦｉやＰｏｗｅｒｌｉｎｅなどの低速部分を含むものであってもよい。チューナは、ＣＤＳ及びプロトコル変換機能を収集するが、必ずしもレンダリング機能を有しない装置と、レンダリング機能を提供するＨＮ ＳＴＢなどの装置との２ボックスセットとして提供することができる。チューナボックスは、高速インタフェースを介しホームゲートウェイに接続され、レンダリング装置は低速インタフェースに接続される。

説明、請求項及び図面に開示された参照は、独立して又は何れか適切な組み合わせにより提供されてもよい。適切な場合には、各特徴はハードウェア、ソフトウェア又はこれらの組み合わせにより実現されてもよい。

ここでの“一実施例”又は“実施例”という表現は、当該実施例に関して説明される特定の機能、構成又は特徴が本発明の少なくとも１つの実現形態に含めることが可能であることを意味する。明細書の各箇所における“一実施例では”という表現は、必ずしも同じ実施例を参照するとは限らず、他の実施例を互いに排除した個別の又は他の実施例であるとは限らない。

請求項に記載される参照番号は、単なる例示的なものであり、請求項の範囲に対して限定的な効果を有するものでない。

Claims (11)

1. ローカルネットワークを第２ネットワークに接続するよう構成されるゲートウェイ装置を有する前記ローカルネットワークに接続するためのコネクタと、
   前記ローカルネットワーク上にあるセットトップボックスに、利用可能なマルチメディアコンテンツと、前記マルチメディアコンテンツが入手可能な前記ローカルネットワークにおけるアドレスとに関する情報を提供するサーバと、
   前記セットトップボックスから前記マルチメディアコンテンツを受信するためのリクエストを受信すると、前記マルチメディアコンテンツに対応するＩＰＴＶコンテンツを受信するために、前記第２ネットワークにあるＩＰＴＶサーバによるＩＰＴＶセッションに加入することを前記ゲートウェイ装置に通知し、前記ゲートウェイ装置が前記ＩＰＴＶサーバから受信したＩＰＴＶコンテンツを前記セットトップボックスに転送できるようにする手段を有するＩＰＴＶプロキシモジュールと、
   を有するネットワーク装置。
2. 前記ＩＰＴＶプロキシモジュールは、前記マルチメディアコンテンツに対応するＩＰＴＶセッションを、前記第２ネットワークにある第２装置に通知し、前記第２装置が前記ＩＰＴＶセッションに加入できるようにする手段を有する、請求項２記載の装置。
3. 前記加入のリクエストは、前記ゲートウェイ措置が前記ＩＰＴＶセッションに加入できるように、前記ゲートウェイ装置に送信される、請求項１記載の装置。
4. 前記セットトップボックスが前記マルチメディアコンテンツにアクセスすることを可能にするＲＴＳＰサーバをさらに有する、請求項１乃至３何れか一項記載の装置。
5. 前記セットトップボックスが前記マルチメディアコンテンツにアクセスすることを可能にするＨＴＴＰサーバをさらに有する、請求項１乃至４何れか一項記載の装置。
6. 利用可能なマルチメディアコンテンツに関する情報を前記セットトップボックスに提供するＣＤＳサーバをさらに有する、請求項１乃至５何れか一項記載の装置。
7. ローカルネットワークと第２ネットワークとを接続するよう構成されるゲートウェイ装置を有する前記ローカルネットワークにあるネットワーク装置において、前記ローカルネットワークにあるセットトップボックスと前記第２ネットワークにあるＩＰＴＶサーバとの間でＩＰＴＶ通信をセットアップするための方法であって、
   前記ネットワーク装置において、
   前記セットトップボックスに、利用可能なマルチメディアコンテンツと、前記マルチメディアコンテンツが入手可能な前記ローカルネットワークにおけるアドレスとに関する情報を提供するステップと、
   前記マルチメディアコンテンツが前記ネットワーク装置において利用可能である場合、前記セットトップボックスから前記マルチメディアコンテンツを受信するリクエストを受信すると、前記マルチメディアコンテンツに対応するＩＰＴＶコンテンツを受信するために、前記第２ネットワークにあるＩＰＴＶサーバによるＩＰＴＶセッションに加入することを前記ゲートウェイ装置に通知し、前記ゲートウェイ装置が前記ＩＰＴＶサーバから受信したＩＰＴＶコンテンツを前記セットトップボックスに転送できるようにするステップと、
   を有する方法。
8. 前記マルチメディアコンテンツが前記ゲートウェイ装置において利用可能である場合、前記ゲートウェイ装置に前記マルチメディアコンテンツに対応するＩＰＴＶセッションを通知する、請求項７記載の方法。
9. 前記ゲートウェイ装置からのリクエストの受信後、前記ゲートウェイ装置に前記マルチメディアコンテンツに対応するＩＰＴＶセッションを通知する、請求項７又は８記載の方法。
10. 前記加入のリクエストは、前記ゲートウェイ装置が前記ＩＰＴＶセッションに加入できるように、前記ゲートウェイ装置に送信される、請求項７記載の方法。
11. コンピュータ上で実行されると、請求項７記載の方法のステップを実行するためのプログラムコード命令を有するコンピュータプログラム。

Images