JP2005501477A

JP2005501477A - ＵＰｎＰネットワークとＨＡＶｉネットワークとをブリッジするための方法

Info

Publication number: JP2005501477A
Application number: JP2003524192A
Authority: JP
Inventors: アンリ，ジャン−バプティスト; ビュルクリン，ヘルムート
Original assignee: Thomson Licensing SAS
Current assignee: Thomson Licensing SAS
Priority date: 2001-08-22
Filing date: 2002-08-20
Publication date: 2005-01-13
Also published as: US20040246992A1; CN1545781A; KR20040030973A; AU2002336994A1; WO2003019864A3; WO2003019864A2; EP1419620A2; MXPA04001541A; EP1286501A1

Abstract

本発明は、ＨＡＶｉネットワークとＵＰｎＰネットワークとをブリッジするための方法に関する。ここでは、両者のネットワークは、一方のネットワークから他のネットワークへのソフトウェアエレメントを表すブリッジ装置に接続される。本方法は、ＵＰｎＰネットワークに接続されているＵＰｎＰ装置を検出するステップと、ＨＡＶｉネットワーク上のＵＰｎＰ装置を表すために、それぞれのＵＰｎＰ装置のためのプロキシＨＡＶｉ装置制御モジュールを作成するステップとを備えており、該プロキシＨＡＶｉ装置制御モジュールを記録するステップを特徴としており、該プロキシＨＡＶｉ装置制御モジュールは、レガシーデバイスのタイプであるとして宣言される。

Description

【技術分野】
【０００１】
本発明は、ＵＰｎＰネットワークとＨＡＶｉネットワークとをブリッジするための方法に関する。本発明は、特に、家庭用通信ネットワークの分野に適用される。
【背景技術】
【０００２】
ブリッジの機能は、ＵＰｎＰネットワーク上でＨＡＶｉソフトウェアエレメント（たとえば装置制御モジュール、及び機能要素モジュール）を表すこと、並びにＨＡＶｉネットワーク上でＵＰｎＰ装置及びサービスを表すことを含んでいる。
【０００３】
ＨＡＶｉ仕様によれば、ＨＡＶｉネットワーク上のそれぞれの装置は、これより所定の記述データ（自己記述データ用の“ＳＤＤ”データ）を読み出すことができるコンフィグレーションメモリを持たなければならない。
【０００４】
ＵＰｎＰ装置を表すブリッジのプロキシ装置は、実世界の装置ではなく、このためかかるコンフィグレーションメモリを有していない。
【０００５】
特許出願ＷＯ００７６１３１は、出願人ＴＨＯＭＳＯＮｍｕｌｔｉｍｅｄｉａ社の名で２０００年５月３１日に提出され、２０００年１２月１４日に公表されており、ＨＡＶｉ（ＨｏｍｅＡｕｄｉｏ／Ｖｉｄｅｏｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ）ネットワークとＵＰｎＰ（ＵｎｉｖｅｒｓａｌＰｌｕｇａｎｄＰｌａｙ）ネットワークとをブリッジするための装置及び方法に関する。
【発明の開示】
【課題を解決するための手段】
【０００６】
本発明は、ＨＡＶｉネットワークとＵＰｎＰネットワークとをブリッジするための方法に関する。両ネットワークは、一方のネットワークから他方のネットワークに関して、ソフトウェアエレメントを表すブリッジ装置に接続される。本方法は、ブリッジ装置のレベルで、ＵＰｎＰネットワークに接続されるＵＰｎＰ装置を検出するステップ、ＨＡＶｉネットワーク上で該ＵＰｎＰ装置を表すために、それぞれのＵＰｎＰ装置についてプロキシＨＡＶｉ装置制御モジュールを作成するステップとを備えており、該プロキシＨＡＶｉ装置制御モジュールを登録するステップを備え、該プロキシＨＡＶｉ装置制御モジュールは、レガシーデバイスのタイプであるとして宣言されることを特徴としている。
【０００７】
このＵＰｎＰ装置は、ＨＡＶｉネットワーク上のレガシー（ＬＡＶ）装置として表されるので、他のＨＡＶｉ装置は、任意のコンフィグレーションメモリがこれらの装置に存在することを期待しない。
【０００８】
本発明の実施の形態によれば、本方法は、ＵＰｎＰネットワーク上で少なくとも所定のタイプのＵＰｎＰサービスを検出するステップと、それぞれ検出されたＵＰｎＰサービスについてプロキシＨＡＶｉ機能要素モジュールを作成するステップと、該プロキシＨＡＶｉ機能要素モジュールを宣言するステップとをさらに備えている。ここで、１つのプロキシＨＡＶｉ機能要素モジュールは、１つの所与のＵＰｎＰサービスを表しており、ＵＰｎＰネットワーク上のＵＰｎＰサービスに関連するＵＰｎＰ装置を表す１つのプロキシＨＡＶｉ装置制御モジュールに統合される。
【０００９】
本発明の実施の形態によれば、本方法は、ＨＡＶｉネットワーク上でＨＡＶｉ装置制御モジュールとＨＡＶｉ機能要素モジュールを検出するステップと、それぞれのＨＡＶｉ装置制御モジュールのためのプロキシＵＰｎＰ装置と、それぞれのＨＡＶｉ機能要素モジュールのためのＵＰｎＰサービスとを作成するステップと、ＵＰｎＰルールに従ってプロキシ装置及びサービスを宣言するステップとをさらに備える。
【００１０】
本発明の実施の形態によれば、ＵＰｎＰ装置及び／又はサービスを表しているプロキシＨＡＶｉソフトウェアエレメントは、ＩＥＣ６１８８３規格に準拠しないタイプであるとして宣言される。
【００１１】
本発明の実施の形態によれば、本方法は、プロキシソフトウェアエレメントの登録前に、該プロキシソフトウェアエレメントに関連する記述データを要求するステップと、該記述データを受信した後でのみ該プロキシソフトウェアエレメントを登録するステップとをさらに備える。
【００１２】
本発明の他の特徴及び効果は、添付図面と共に説明される限定するものではない実施の形態の記載を通して明らかになるであろう。
【発明を実施するための最良の形態】
【００１３】
本発明の実施の形態によれば、ブリッジ装置は、ＨＡＶｉ装置とＵＰｎＰ装置とにリンクする。ＨＡＶｉは、“ＨｏｍｅＡｕｄｉｏ／Ｖｉｄｅｏｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ”を意味し、特に、ＩＥＥＥ１３９４バスに基づく家庭用ネットワークを制御するためのソフトウェアスタックを定義する。現在のＨＡＶｉ仕様のバージョンは、２００１年５月１５日に発表されたｖ１．１であり、アメリカ合衆国のＨＡＶｉ社２６９４ＢｉｓｈｏｐＤｒｉｖｅ，Ｓｕｉｔｅ２７５ＳａｎＲａｍｏｎ，Ｃａ９４５８３より入手することができる。ＵＰｎＰは、“ＵｎｉｖｅｒｓａｌＰｌｕｇａｎｄＰｌａｙ”を意味し、インターネットプロトコル（ＩＰ）に基づくネットワーク制御ソフトウェアスタックを提供する。ＵＰｎＰ仕様は、Ｍｉｃｒｏｓｏｆｔ社により運営されているＵＰｎＰフォーラムから入手することができる。
【００１４】
ＨＡＶｉネットワーク又はＵＰｎＰネットワークにおけるものとして、アプリケーション及び他のエレメントは、利用可能な機能性を決定することができる必要がある。
【００１５】
ＨＡＶｉネットワークでは、機能性は、ＦＣＭ（ＦｕｎｃｔｉｏｎａｌＣｏｎｔｒｏｌＭｏｄｕｌｅ）と呼ばれるソフトウェアエレメントにより表される。階層的に言えば、ＦＣＭは、ＤＣＭ（ＤｅｖｉｃｅＣｏｎｔｒｏｌＭｏｄｕｌｅ）に常に含まれており、１つの装置を表している。１つのＤＣＭは、１つ以上のＦＣＭを含むことができる（たとえば、１つのデジタルＶＣＲを表す１つのＤＣＭは、１つのチューナＦＣＭと１つのＶＣＲＦＣＭを含んでいる）。それぞれの装置について１つのＤＣＭのみが存在する。
【００１６】
ＨＡＶｉネットワークでは、あるソフトウェアエレメントがその機能をネットワークに提供したい場合、そのソフトウェアエレメントは、「レジストリ」と呼ばれるローカルソフトウェアエレメントで自身を登録しなければならない。（装置のブート時間で、或いは、たとえばＤＣＭ制御ユニットすなわち“ＤＣＵ”のダウンロードであるランタイムで）ＦＣＭが作成されたとき、そのソフトウェアエレメントは、自身が有する装置のレジストリに自身を登録する。
【００１７】
ネットワークにおいてどのサービスが利用可能であるかをアプリケーションが知りたい場合、そのアプリケーションは、ネットワークの全てのレジストリに問合せを送出する。
【００１８】
さらに、システムが実行している間に動的に作成されたソフトウェアエレメントについて、システムのイベントが存在する。レジストリは、ソフトウェアエレメントの登録及び削除を宣言するために、２つのイベントを利用することができる。このイベントは、ＮｅｗＳｏｆｔｗａｒｅＥｌｅｍｅｎｔ（あるソフトウェアエレメントがちょうど登録されたことを示す）、及びＧｏｎｅＳｏｆｔｗａｒｅＥｌｅｍｅｎｔ（ソフトウェアエレメントがちょうど登録から除外されたことを示す）である。ＨＡＶｉネットワークでは、ポーリングは必要ではない。
【００１９】
あるソフトウェアエレメントがＨＡＶｉレジストリよりも新しい（すなわち、そのソフトウェアエレメントが未知のタイプである）場合、このソフトウェアエレメントは、ＨＡＶｉネットワーク上でまだ新たな機能性として認識され、示される。
【００２０】
ＵＰｎＰは、ＨＡＶｉレジストリに類似した観念を組み込んでいない。しかし、ＵＰｎＰネットワークでは、装置のサービスは、ネットワーク上で宣言される場合がある。このため、ＵＰｎＰは、「マルチキャスト向けＵＤＰを通したＨＴＴＰ」（ＨＴＴＰＭＵ）を使用する。また、アプリケーションにとって、ネットワーク上のサービスをサーチすることも可能である。サービス・ディスカバリ・プロトコルは、シンプル・サービス・ディスカバリ・プロトコル（ＳＳＤＰ：ＳｉｍｐｌｅＳｅｒｖｉｃｅＤｉｓｃｏｖｅｒｙＰｒｏｔｏｃｏｌ）である。このプロトコルは、イベント通知のためのＧＥＮＡプロトコル（ＧｅｎｅｒａｌＥｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎＡｒｃｈｉｔｅｃｔｕｒｅ）と組み合わせることができる。あるアプリケーションがどのサービスを利用可能であるかを知りたいとき、そのアプリケーションは、ＳＳＤＰディスカバー・マルチキャスト・メッセージを送出する。要求に整合するサービスは、ユニキャストモード（ＨＴＴＰＵ）で応答を送り返さなければならない。問合せは、非常に広くすることができ（たとえば、全てのサービス）、又はより制限することもできる（たとえば、所定のタイプのサービス）。
【００２１】
あるサービスがネットワーク上で新しいサービスであるとき、その存在を宣言するために、ＧＥＮＡ−ＳＳＤＰ「有効“ａｌｉｖｅ”」マルチキャストメッセージを送出しなければならない。
【００２２】
有効メッセージ及びディスカバー応答メッセージは、年齢制限（“ｍａｘ−ａｇｅ”）フィールドを含んでいる。年齢制限フィールドは、そのサービスの有効性を秒で表す。そのサービスがこの時間の後にもなお存在する場合、別の有効メッセージがそのサービスにより送出されなければならない（又は、別のディスカバー問合せが行われる）。
【００２３】
ＵＰｎＰネットワークでは、シンプル・オブジェクト・アクセス・プロトコル（ＳＯＡＰ：ＳｉｍｐｌｅＯｂｊｅｃｔＡｃｃｅｓｓＰｒｏｔｏｃｏｌ）メッセージを使用して制御が実行される。
【００２４】
ブリッジ装置の役割は、一方のネットワークの任意の装置が他方のネットワークの任意の装置と通知可能であるために、一方の側から他方の側へのメッセージを変換するようなやり方で、両方のネットワークを接続することである。ブリッジは、ストリームを通過可能であるべきである。
【００２５】
図１は、ＩＥＥＥ１３９４バス２に接続されたＨＡＶｉ装置１を備えるＨＡＶｉネットワークの例を与えている。このＨＡＶｉネットワークは、ＩＰネット４に接続されるＵＰｎＰ装置３を備えるＵＰｎＰネットワークに接続されている。両方のネットワークは、ブリッジ装置５によりリンクされている。ブリッジ５は、一方のネットワークから他方のネットワークへ制御メッセージ、イベント、ストリーム等の変換すなわちマッピングを実行するためのソフトウェアと共に、ＨＡＶｉプロトコルスタック、ＩＰプロトコルスタックを備えている。
【００２６】
本発明の実施の形態によれば、ブリッジは、装置及びアプリケーションに対してトランスペアレントである。
【００２７】
本発明の実施の形態によれば、ＵＰｎＰ装置は、ＨＡＶｉＤＣＭにより表され、ＵＰｎＰサービスは、該サービスにリンクされるＵＰｎＰ装置を表すＤＣＭ内でＨＡＶｉＦＣＭにより表される。逆に、ＨＡＶｉＤＣＭは、ＵＰｎＰ装置により表され、ＨＡＶｉＦＣＭは、このＦＣＭを含むＤＣＭを表す装置に関連するサービスにより表される。ブリッジにより作成されるソフトウェアエレメントは、以下に説明される「プロキシ」ソフトウェアエレメントと呼ばれる。
【００２８】
それぞれのネットワーク上で適切に装置を表すことがブリッジの機能である。ＨＡＶｉネットワーク上のそれぞれのＤＣＭ又はＦＣＭについて、ブリッジは、ＵＰｎＰ装置又はＵＰｎＰサービスを作成する。逆に、それぞれのＵＰｎＰ装置、それぞれのＵＰｎＰサービスについて、ブリッジは、ＨＡＶｉＤＣＭを作成し、ＨＡＶｉＦＣＭをそれぞれ作成する。
【００２９】
ブリッジ装置は、サービス、装置、ＦＣＭ又はＤＣＭが追加又は削除されたときはいつでも、それぞれのネットワークの表示を更新するための役割を果たす。
【００３０】
それぞれのネットワークのコンフィグレーションに依存して、ブリッジは、ＵＰｎＰ装置を表す幾つかのＨＡＶｉＤＣＭを管理する。また、ブリッジは、自身のブリッジ機能以外の機能を有するため、自身のＤＣＭを管理する。たとえば、ブリッジ機能は、テレビ受信機又は衛星放送デコーダのような装置に含むことができる。
【００３１】
ＨＡＶｉ仕様及びＩＥＥＥ１２１２規格に準拠して、ＩＥＥＥ１３９４規格に準拠した装置であるそれぞれのＨＡＶｉ装置は、コンフィグレーションメモリを備えている。ＨＡＶｉ及びＩＥＥＥ１３９４−２０００規格は、このメモリに保持される多数のパラメータを定義している。ＨＡＶｉにより定義されるパラメータは、自己記述データ、すなわち“ＳＤＤ”と呼ばれ、別の装置により読み出される場合がある。ＵＰｎＰ装置を表すブリッジのＤＣＭは、ＳＤＤデータを含むことができるＨＡＶｉ／ＩＥＥＥ１３９４規格に準拠するコンフィグレーションメモリを有しない。
【００３２】
この問題を回避するために、ＵＰｎＰ装置を表すためにブリッジにより作成されたＤＣＭは、レガシーデバイス（“ＬＡＶ”、すなわち旧式のオーディオ／ビデオ装置）であるとして宣言される。これらの装置は、ＩＥＥＥ１３９４規格に準拠した装置である場合、又はＩＥＥＥ１３９４規格に準拠しない装置である場合があり、ＨＡＶｉ規格に準拠していないものとして考慮され、ＳＤＤデータを含むことが期待されない。ＤＣＭの性質は、ＤＣＭのデバイスクラス取得（ＤＣＭＧｅｔＤｅｖｉｃｅＣｌａｓｓ）と呼ばれるＤＣＭアプリケーション・プログラマブル・インタフェース（ＡＰＩ）の機能を使用して、他のソフトウェアエレメントにより認識することができる。
【００３３】
ＨＡＶｉ仕様によれば、ＤＣＭ又はＦＣＭは、そのローカルレジストリで自身を登録する。登録の間、ＤＣＭは、とりわけ、登録するソフトウェアエレメントが装置（ＤＣＭ）であるか、装置の機能要素（ＦＣＭ）であるか、或いはアプリケーションモジュールであるかを示すＴａｒｇｅｔＩＤと呼ばれるデータ構造といった所定の情報量を提供する。はじめの２つのケースでは、ＴａｒｇｅｔＩＤデータ構造は、ＤＣＭ又はＦＣＭが、とりわけ、ＩＥＥＥ１３９４規格に準拠したネットワークを通してアイソクロナスストリーム（たとえば、オーディオ及びビデオストリーム）の伝送を定義するＩＥＣ６１８８３規格に準拠しているかも示す。２つのＴａｒｇｅｔＩＤデータ構造は、同じになることはない。
【００３４】
ＨＡＶｉ仕様は、ＩＥＥＥ１３９４規格に準拠した装置をユニークに識別する６４ビットのデータ量であるＧＵＩＤ（ｇｌｏｂａｌｕｎｉｑｕｅｉｄｅｎｔｉｆｉｅｒ）をＴａｒｇｅｔＩＤ構造が含んでいることを要求している。ＧＵＩＤ識別子は、装置のコンフィグレーションＲＯＭに記憶され、ネットワークのリセットを通して持続性のある識別子である。ストリーミングの環境では、ターゲットＩＤに与えられるＧＵＩＤは、この装置に該ストリームが送出され、或いはこの装置から該ストリームが受信される物理的なＨＡＶｉ装置を識別する。所定の装置のタイプについて、この装置は、ストリームソース又はシンク装置に関連するＤＣＭのホスト装置ではなく、最終的なターゲット装置のＧＵＩＤである。
【００３５】
ＵＰｎＰ装置を表すＤＣＭは、自身のＧＵＩＤ識別子を有していない。しかし、ブリッジがＵＰｎＰネットワークから受信したストリームをＨＡＶｉネットワークに送出するとき、又はＵＰｎＰ装置に伝えられるＨＡＶｉ装置からのストリームを受信するとき、これらＵＰｎＰ装置を表すＤＣＭは、それらのＴａｒｇｅｔＩＤのデータ構造においてブリッジのＧＵＩＤ識別子を使用しなければならない。
【００３６】
家庭用ネットワーク環境では、ＨＡＶｉネットワークとＵＰｎＰネットワークの間のブリッジとしてのその機能とは独立して、ブリッジは、オーディオ及びビデオストリームを送出、受信及び処理するために典型的に設計される。そのとき、ブリッジ自身のＤＣＭを有し、このＤＣＭは、ＩＥＣ６１８８３規格に準拠するタイプのＤＣＭである。その登録の間、ブリッジ自身のＤＣＭは、自身のＧＵＩＤ識別子を使用する。
【００３７】
かかるケースでは、ＵＰｎＰ装置を表すＤＣＭの装置タイプは、ＩＥＣ６１８８３規格に準拠するＤＣＭとなることはできない。これは、ＨＡＶｉネットワークにおいて２つの同じＴａｒｇｅｔＩＤデータ構造を有することが原因である。たとえ、ブリッジ自身のＤＣＭがＩＥＣ６１８８３規格に準拠する（ＤＣＭ＿６１８８３）タイプではない場合であっても、ブリッジがＵＰｎＰ装置用の２つ以上のＤＣＭを扱うことになる場合には同じ問題が生じる。
【００３８】
ＵＰｎＰ装置のＤＣＭをＩＥＣ６１８８３規格に準拠しないタイプのＤＣＭであるとして宣言することが提案される。このケースでは、これらのＤＣＭのＴａｒｇｅｔＩＤデータ構造は、ブリッジのＧＵＩＤ識別子をなお含んでいるが（ブリッジはこれらＤＣＭのホストである）、ＴａｒｇｅｔＩＤは、ブリッジによりそれぞれのＤＣＭに内部的に属性付けされる更なるパラメータにより区別される。
【００３９】
ＵＰｎＰ装置がネットワークのＨＡＶｉ側でＩＥＣ６１８８３規格に準拠しない装置であるとして示されるという事実は、これらの装置がストリームを送出又は受信しないことを意味するのではなく、これらのストリームがＩＥＣ６１８８３規格に必ずしも準拠しないことを意味している。
【００４０】
同様なやり方で、ＵＰｎＰサービスを表すプロキシＦＣＭは、ＩＥＣ６１８８３規格に準拠しないＦＣＭであるとして宣言される。
【００４１】
説明したように、ＨＡＶｉ仕様は、ターゲットソフトウェアエレメントのタイプについて、５つの異なる値を定義している（ＤＣＭ＿６１８８３、ＤＣＭ＿ＮＯＮ６１８８３、ＦＣＭ＿６１８８３、ＦＣＭ＿ＮＯＮ６１８８３及びＡＭ）。先の問題を解決する変形例としての実施の形態として、追加のターゲットタイプが定義される。
【００４２】
ＤＣＭ＿ＰＲＯＸＹ又はＤＣＭ＿ＮＯＮ１３９４は、ＵＰｎＰ装置（又は別のＨＡＶｉではないネットワーク上の装置）を表すものとしてＤＣＭを識別する。
【００４３】
ＦＣＭ＿ＰＲＯＸＹ又はＦＣＭ＿ＮＯＮ１３９４は、ＵＰｎＰ装置（或いは別のＨＡＶｉではないネットワーク上のサービス又は機能）を表すものとしてＦＣＭを識別する。
【００４４】
ＵＰｎＰ側では、かかる問題は存在しない。これは、物理的な装置がルートデバイスで表されているからであり、ルートデバイスは幾つかの装置及びサービスを含むことができる。
【００４５】
新たなプロキシＤＣＭ又はＦＣＭがＵＰｎＰ装置又はサービスについて作成されたというイベントを受信したとき、ＨＡＶｉアプリケーションは、かかるＤＣＭ又はＦＣＭに関する追加の情報を取得したい場合がある。ＵＰｎＰ装置又はサービスが、ブリッジにより処理された新たなプロキシ装置又はサービスについて通知されたとき、逆もまた当てはまる。
【００４６】
このために、ブリッジは、該ブリッジがプロキシを作成するＨＡＶｉＤＣＭ又はＦＣＭ、或いはＵＰｎＰサービス又は装置のそれぞれに関する情報を収集する。この情報は、プロキシソフトウェアエレメント作成の宣言の前に収集される。
【００４７】
ブリッジは、以下の処理を実行する。
（ａ）新たなＨＡＶｉソフトウェアエレメントについて、ブリッジは、（「レジストリの属性検索“ＲｅｇｉｓｔｒｙＲｅｔｒｉｅｖｅＡｔｔｒｉｂｕｔｅｓ”」機能を使用して）エレメントの属性をレジストリから要求する。
【００４８】
新たなＵＰｎＰソフトウェアエレメントにとって、ブリッジは、先に説明した、シンプル・サービス・ディスカバリ・プロトコルによる「有効」メッセージを通して、ソフトウェアエレメントの記述を受信する。この記述は、ＸＭＬで書かれたユニバーサル・リソース・ロケータ（ＵＲＬ）であり、本発明によれば、全ての関連する情報を抽出するためにブリッジにより分析される。
（ｂ）ブリッジは、新たなプロキシソフトウェアエレメントを作成する。
（ｃ）ブリッジは、（ＵＰｎＰソフトウェアエレメントを表すプロキシについて）ＨＡＶｉネットワーク上で“ＮｅｗＳｏｆｔｗａｒｅＥｌｅｍｅｎｔ”イベントメッセージを使用して、又は（ＨＡＶｉソフトウェアエレメントについてプロキシを宣言するために）ＵＰｎＰネットワーク上で“ｓｓｄｐａｌｉｖｅ”マルチキャストメッセージを使用して、該プロキシソフトウェアエレメントの有効性を宣言するために、イベントを送出する。ＵＰｎＰに準拠して、このマルチキャストメッセージは、周期的に繰り返される。
【００４９】
イベントのマッピングが表１に与えられる。
【００５０】
【表１】

以下、ブリッジを通したメッセージの伝送について説明する。ＨＡＶｉソフトウェアエレメントがプロキシＤＣＭ又はＦＣＭにメッセージを送出するとき、ブリッジは、このメッセージをＵＰｎＰメッセージに変換する。このメッセージは、装置又はサービス制御に関するものである場合にはＳＯＡＰに基づき、イベントの通知に関するものである場合にはＧＥＮＡ（ＧｅｎｅｒａｌＥｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎＡｒｃｈｉｔｅｃｔｕｒｅ）に基づく。ＵＰｎＰ装置又はサービスがブリッジのプロキシ装置又はサービスをアドレス指定したときには、上記の逆が採用される。
【００５１】
この変換は、全てのメッセージに適用されない。以下の限定するものではない例では、ＨＡＶｉメッセージが送出されないが、プロキシエレメントにより直接回答される。プロキシＦＣＭは、ＦＣＭがＤＣＭのＳＥＩＤを取得するコマンド（ＦＣＭＧｅｔＤｃｍＳｅｉｄ）を受信する。プロキシＦＣＭは、属しているプロキシＤＣＭのＳＥＩＤを返して回答する。
【００５２】
ＨＡＶｉのユニークな識別子（ＨＵＩＤ：ＨＡＶｉＵｎｉｑｕｅＩｄｅｎｔｉｆｉｅｒ）が使用され、ＤＣＭ、ＦＣＭ又はアプリケーションモジュール（ＡＭ）がユニークに識別される。ＨＵＩＤは、ＵＰｎＰ装置又はサービスのそれぞれのＨＡＶｉプロキシについて作成される。ＨＵＩＤ識別子は、ＴａｒｇｅｔＩＤ、及び多数の他の識別子“Ｉｎｔｅｒｌａｃｅｄ”、“Ｖｅｎｄｏｒｌｄ”、“ｎ１Ｕｎｉｑｕｅｎｅｓｓ”、“ｎ２Ａｓｓｉｇｎｅｒ”を含んでいる。“ｎ１Ｕｎｉｑｕｅｎｅｓｓ”は真（ＴＲＵＥ）に設定され、“ｎ２Ａｓｓｉｇｎｅｒ”は、ＤＣＭについて非（ＮＯＮＥ）に設定され、ＦＣＭについて非（ＮＯＮＥ）又はＤＣＭに設定される。結果的に、ＵＰｎＰ装置のＨＡＶｉプロキシのＨＵＩＤの伝送を要求するメッセージは、ＳＥＩＤ識別子の伝送を要求するメッセージとして扱われる。
【００５３】
ＨＡＶｉエンティティにより送出される少なくとも以下のメッセージは、ＵＰｎＰ側に送出されず、ブリッジにより直接回答される。
ＦＣＭがＤＣＭのＳＥＩＤを取得（ＦｃｍＧｅｔＤｃｍＳｅｉｄ）
ＤＣＭがＨＵＩＤを取得（ＤｃｍＧｅｔＨｕｉｄ）
ＤＣＭがＦＣＭのＳＥＩＤリストを取得（ＤｃｍＧｅｔＦｃｍＳｅｉｄＬｉｓｔ）
ＦＣＭがＨＵＩＤを取得（ＦｃｍＧｅｔＨｕｉｄ）。
【００５４】
適切な変換を達成するために、ＨＡＶｉＡＰＩとＵＰｎＰＡＰＩとの間で等価な変換が確立される必要がある。直接な１対１の対応関係は常に可能ではないため、ブリッジは、１つのメッセージを複数のメッセージでエミュレートして適切な結果を得る必要があるか、又は要求を処理することができない旨を送出者に通知する初期メッセージに対する応答を送り返す必要がある。
【００５５】
ＨＡＶｉＶＣＲＡＰＩ、ＨＡＶｉＡｕｄｉｏ／ＶｉｄｅｏＤｉｓｃＡＰＩ及びＵＰｎＰＡＴＶＴｒａｎｓｐｏｒｔＡＰＩの間の等価な変換が存在するときは、表２に与えられる。
【００５６】
【表２】

表２に与えられるＡＰＩに関連するイベント間の等価な変換は、表３に示されている。
【００５７】
【表３】

図２〜図５は、ＵＰｎＰ装置をＵＰｎＰネットワークに接続することで、ブリッジによりトリガされる処理を例示している。図２の最初のネットワークでは、ＨＡＶｉ装置１のみがＨＡＶｉネットワークに接続され、ＩＰネットワークには装置が接続されていない。ＨＡＶｉ装置は、プロキシサービス１６とプロキシ接続マネージャサービス１０とを備えるプロキシ装置１５として、ＵＰｎＰネットワークへのブリッジにより表される。説明を明確にするために、図３〜図５では、説明が必要とされない場合には、ブリッジのＵＰｎＰ側に関するＨＡＶｉ装置に対応するプロキシソフトウェアエレメントを示していない。
【００５８】
図３により例示されるように、ＵＰｎＰ装置３は、このケースではＵＰｎＰＶＣＲであり、ＩＰネットワーク４に接続されている。ブリッジ５は、ＳＳＤＰプロトコルを介して、この接続について通知される。次いで、ブリッジは、装置のＸＭＬ記述を分析して、新たに接続された装置がＶＣＲサービスを含むＶＣＲ装置であることを発見する。
【００５９】
図４により例示されるように、ブリッジは、ＵＰｎＰＶＣＲ装置及びサービスをシミュレートするために、ＨＡＶｉＤＣＭ８及びＨＡＶｉＶＣＲＦＣＭ９をプロキシソフトウェアエレメントとして作成する。次いで、２つの新たなＨＡＶｉソフトウェアエレメントは、ブリッジのメッセージシステム（図４における“ＭＳＧ”）からＳＥＩＤ識別子を要求し、ブリッジのレジストリ“Ｒｅｇ”で登録する。この登録により、レジストリは、ＨＡＶｉネットワークを通して、新たなソフトウェアエレメントのイベントを送出する。
【００６０】
ＨＡＶｉ装置１のアプリケーションが「再生」コマンドをＵＰｎＰＶＣＲ３に送出したいとき、自身のメッセージシステムを使用して、「ＶＣＲ再生」メッセージをＶＣＲＦＣＭに送出する。そのとき、ブリッジのアプリケーションは、適切な制御メッセージをＵＰｎＰＶＣＲサービスに送出する。この処理は、図５に例示されている。
【００６１】
図６及び図７には、ストリームの確立が例示されている。図６は、ＨＡＶｉ装置１により始動されるストリームの確立に関し、図７は、ＵＰｎＰ装置３により始動されるストリームの確立に関する。
【００６２】
図６のケースでは、装置１のアプリケーション、たとえばユーザインタフェースは、そのストリームマネージャ（ＳＭ）の「フロー・トゥー“ＦｌｏｗＴｏ”」機能を呼出す。この機能は、ストリームの確立を担当するＨＡＶｉにおけるソフトウェアエレメントである。フロー・トゥー機能の呼出しのパラメータは、ソースのプラグ及びシンクＦＣＭの識別子である。この情報は、「ＦＣＭプラグ“ＦｃｍＰｌｕｇ”」と呼ばれるデータ構造に設けられる。接続されるＦＣＭ（このケースでは、ＨＡＶｉ装置１のＦＣＭ、及びＵＰｎＰ装置３を表すブリッジのプロキシＦＣＭ）は、既に説明した“ＴａｒｇｅｔＩＤ”データ構造を使用して識別される。ソースプラグのＴａｒｇｅｔＩＤは、ブリッジのＧＵＩＤ識別子を示している。
【００６３】
ストリームマネージャは、「ＤＣＭ接続“ＤＣＭＣｏｎｎｅｃｔ”」機能の呼出しを使用して、関連するＤＣＭ及びＦＣＭのレベルで、要求される内部プラグ接続をトリガする。また、ストリームマネージャは、ＩＥＥＥ１３９４規格に従うアイソクロノスリソースの保存を行い、関連する装置のＩＥＣ６１８８３規格に従うプラグ制御レジスタを更新する（ステップＥ１及びＥ２）。
【００６４】
本発明の実施の形態に従い、プロキシＤＣＭ８に対する「ＤＣＭ接続」機能の呼出しにより、ＵＰｎＰネットワークでの対応する接続処理がトリガされる。プロキシＤＣＭは、ＵＰｎＰ接続マネージャサービス１０及び１１を呼出す。これらのサービスは、それぞれ、ＵＰｎＰ装置としてＨＡＶｉ装置１の表現の一部であり、ＵＰｎＰＶＣＲ３の一部である。呼出される機能は、「接続マネージャ接続準備“ＣｏｎｎｅｃｔｉｏｎＭｇｒＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎ”」である（ステップＥ３）。また、プロキシＤＣＭは、ＩＰ接続を確立し（ステップＥ４）、ブリッジ内の内部接続を確立する（ステップＥ５）。
【００６５】
図６の例では、プロキシＤＣＭは、変形例となる実施の形態に従い内部ブリッジ接続を確立しているが、このタスクは、ブリッジの専用のソフトウェアモジュールにより実行される。このモジュールは、全ての内部ストリーム接続を集約化し、これにより、リソース管理上の処理及び帯域幅が簡略化される。なお、同じ結果を達成しつつ、幾つかの処理の順序を変更することができる。
【００６６】
図７は、ＵＰｎＰ装置３により始動されたときのストリームを確立するための処理を示している。制御ポイント１３（すなわち、ＵＰｎＰコントローラ）は、シンク及びソースコネクションサービス１０及び１１の両者で、ＵＰｎＰの「接続マネージャ接続準備“ＣｏｎｎｅｃｔｉｏｎＭｇｒＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎ”」コマンドを実施する（ステップＥ１）。また、制御ポイント１３は、ＩＰコネクションをセットアップする（ステップＥ２）。制御ポイント１３からのコマンドをブリッジ５で受信することは、ブリッジのストリームマネージャ１４に対する呼出し機能をトリガする（ステップＥ３「フロー・トゥー機能」）。先のケースでは、ストリームマネージャは、ＤＣＭを呼出し、ＨＡＶｉ装置とブリッジの間でＩＥＣ６１８８３規格に従う接続を確立する。内部接続がセットアップされる（ステップＥ６）。
【００６７】
図６及び図７の両方のケースでは、プロキシＤＣＭ及びプロキシＵＰｎＰ装置は、「ＤＣＭ接続」機能の呼出し、「接続マネージャ接続準備」機能の呼出しのそれぞれの受信に応じて作動すべきかを判定しなければならない。
【００６８】
たとえば、プロキシＤＣＭは、装置１のストリームマネージャからのコマンドを受信したときに、接続を確立すべきであるが、ＵＰｎＰ装置が接続を始動したときにブリッジのストリームマネージャ１４からのコマンドが受信されたときに、接続を確立すべきではない。同様に、コネクションサービス１０が「接続マネージャ接続準備」機能の呼出しをＤＣＭ８から受信したとき、ＵＰｎＰネットワーク上のコネクションを確立すべきであり、呼出しがＵＰｎＰ装置３の制御ポイントから受信されたときに該コネクションを確立すべきではない。
【００６９】
上述した説明は、主にＨＡＶｉＤＣＭ／ＦＣＭとＵＰｎＰ装置／サービスの等価な変換に焦点を当てている。なお、ＤＣＭ及びＦＣＭ以外の幾つかのＨＡＶｉソフトウェアエレメントは、ＵＰｎＰ側でプロキシを必要とする。また、プロキシＵＰｎＰ装置は、ＨＡＶｉＦＣＭを表すプロキシサービスに加えて、サービスを統合する必要がある。たとえば、ＨＡＶｉは、システムエレメントのストリームマネージャを使用するが、ＵＰｎＰ装置は、コネクションマネージャサービスが幾つかのストリーミングを行うことができることを必要とする。他のサービスも同様に追加される場合がある。
【図面の簡単な説明】
【００７０】
【図１】ＨＡＶｉ−ＵＰｎＰブリッジ装置を備えるネットワークのブロック図である。
【図２】ＵＰｎＰ装置を備え、ＵＰｎＰ装置との接続前にある図１のネットワークのブロック図である。
【図３】ＵＰｎＰ装置の宣言フェーズの間にある、図４のネットワークのブロック図である。
【図４】ＵＰｎＰ装置のＤＣＭ及びＦＣＭを作成後にある、図５のネットワークのブロック図である。
【図５】ＵＰｎＰ装置がＨＡＶｉ装置により制御されるときのメッセージの流れを詳細に説明する図６のネットワークのブロック図である。
【図６】図１のネットワークのブロック図であって、ＨＡＶｉ装置により起動されたときのブリッジを通した接続を確立するための本発明の実施の形態で使用される処理のブロック図である。
【図７】ネットワークのブロック図であって、ＵＰｎＰ装置により起動されたときのブリッジを通した接続を確立するための本発明の実施の形態で使用される処理のブロック図である。

Claims

一方のネットワークから他方のネットワークへのソフトウェアエレメントを表すブリッジ装置に接続されるＨＡＶｉネットワークとＵＰｎＰネットワークとをブリッジするための方法であって、該ブリッジ装置のレベルで、
該ＵＰｎＰネットワークに接続されるＵＰｎＰ装置を検出するステップと、
該ＨＡＶｉネットワークで該ＵＰｎＰ装置を表すために、それぞれのＵＰｎＰ装置についてプロキシＨＡＶｉ装置制御モジュールを作成するステップとを備え、
該プロキシＨＡＶｉ装置制御モジュールを登録するステップを備え、
該プロキシＨＡＶｉ装置制御モジュールは、レガシーデバイスのタイプであると宣言される、
ことを特徴とする方法。
該ＵＰｎＰネットワークで少なくとも所定のタイプのＵＰｎＰサービスを検出するステップと、
それぞれ検出されたＵＰｎＰサービスについてプロキシＨＡＶｉ機能要素モジュールを作成するステップと、１つのプロキシＨＡＶｉ機能要素モジュールは、１つの所与のＵＰｎＰサービスを表し、該ＵＰｎＰネットワークのＵＰｎＰサービスに関連するＵＰｎＰ装置を表している１つのプロキシＨＡＶｉ装置制御モジュールと統合され、
該プロキシＨＡＶｉ機能要素モジュールを宣言するステップと、
をさらに備える請求項１記載の方法。
該ＨＡＶｉネットワークでＨＡＶｉ装置制御モジュールとＨＡＶｉ機能要素モジュールを検出するステップと、
それぞれのＨＡＶｉ装置制御モジュールのためのプロキシＵＰｎＰ装置と、それぞれのＨＡＶｉ機能要素モジュールのためのＵＰｎＰサービスとを作成するステップと、
ＵＰｎＰルールに従って該プロキシＵＰｎＰ装置とＵＰｎＰサービスを宣言するステップと、
をさらに備える請求項１又は２記載の方法。
ＵＰｎＰ装置及び／又はサービスを表しているプロキシＨＡＶｉソフトウェアエレメントは、ＩＥＣ６１８８３規格に準拠しないタイプであるとして宣言される、
請求項１乃至３のいずれか記載の方法。
プロキシソフトウェアエレメントの登録の前に、該プロキシソフトウェアエレメントに関連する記述データを要求するステップと、
該記述データを受信した後でのみ該プロキシソフトウェアエレメントを登録するステップと、
をさらに備える請求項１乃至４のいずれか記載の方法。
ＵＰｎＰ装置及び／又はサービスを表すＩＥＥＥ１３９４規格に準拠しないプロキシソフトウェアエレメントについて特定のターゲットタイプを提供するステップを備える、
請求項４記載の方法。