(57)【要約】  少なくとも２つの装置クラスタをインタフェースするブリッジを有する通信ネットワークにおける接続を管理する方法。該接続は各々が異なるクラスタに接続された第１装置と第２装置との間で確立される。該方法は、該接続を確立するよう形成されたアプリケーションのレベルで：  ブリッジ上の接続に対する予約リソースを要求する工程；及び  接続に割り当てられたリソースのステータスに関する少なくとも１つのイベント・タイプの通知を受信するよう、当該ブリッジのポータルに登録する工程；  を有する。  この発明は更に、上記の方法を実施する装置に関する。
2005510178.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも２つの装置クラスタをインタフェースするブリッジを有する通信ネットワークにおける接続を管理する方法であって、該接続が、異なるクラスタに接続された、第１装置と第２装置との間で確立され、該接続を確立するよう形成されたアプリケーションのレベルで：
前記ブリッジ上の前記接続に対するリソースの予約を行う要求を行う工程；及び
前記接続に割り当てられた該リソースのステータスに関する少なくとも１つのイベント・タイプの通知を受信するよう、前記ブリッジのポータルに登録する工程；
を有することを特徴とする方法。
【請求項２】
請求項１記載の方法であって、前記ポータルは、前記接続を確立する装置が接続された前記クラスタのノード、又は、前記ブリッジの中央制御装置、であることを特徴とする方法。
【請求項３】
請求項1又は２記載の方法であって、リソースの予約を行う前記要求が、通知を送信する、前記アプリケーションのアドレスを有することを特徴とする方法。
【請求項４】
請求項3記載の方法であって、前記アドレスが前記アプリケーションをホストするノードのアドレス領域におけるオフセットを有することを特徴とする方法。
【請求項５】
請求項1乃至４何れか記載の方法であって、前記ブリッジが、アイソクロナス・リソース・マネージャを有する、無線ブリッジであって、更に：
前記リソースの予約を行う要求、を受信する工程；
に加えて、
前記ポータルに該要求を前記アイソクロナス・リソース・マネージャに対して転送させ、その応答を待たせて、該応答を前記アプリケーションに対して返信させる工程；
を有することを特徴とする方法。
【請求項６】
請求項５記載の方法であって、更に、前記ポータルのレベルで、前記予約が前記アイソクロナス・リソース・マネージャによって行われることに成功した場合：
前記予約のパラメータを前記接続に関係する全てのポータルに対して送信する工程；
を有することを特徴とする方法。
【請求項７】
請求項６記載の方法であって、前記パラメータを前記ポータルに送信する前記工程は前記アイソクロナス・リソース・マネージャの前記応答を前記アプリケーションに対して転送する工程の前に実施されることを特徴とする方法。
【請求項８】
請求項５乃至７何れか記載の方法であって、前記アプリケーションによる予約を行う要求が前記ブリッジの前記アイソクロナス・リソース・マネージャに対してアドレス指定可能な、予約を行う、要求に類似したフォーマットを有し、前記アプリケーションによる該予約を行う要求が前記接続用ソース及びシンク・ノードの識別子を有し、前記ポータルが更に：
前記アプリケーションの前記予約を行う要求の前記ソース及びシンク・ノードの識別子を、前記ブリッジの前記ソース及びシンク・ノードを接続するポータルの識別子によって、置換する工程；及び
前記アイソクロナス・リソース・マネージャの前記応答における該置換とは逆の変更を実施する工程；
を実施することを特徴とする方法。
【請求項９】
請求項1乃至７何れか記載の方法であって、更に、前記アプリケーションのレベルで：
前記ブリッジから、該ブリッジのどのポータルが接続に関係しているかを判定するトポロジー情報を受信する工程；
を有することを特徴とする方法。
【請求項１０】
請求項９記載の方法であって、前記アプリケーションによる予約要求が更に、前記ブリッジに対して前記接続のソース及びシンク・ノードを接続する前記ポータルの識別子を有することを特徴とする方法。
【請求項１１】
ブリッジによって接続された複数のクラスタを有する通信ネットワークにおけるクラスタに対する接続用装置であって、前記ブリッジ上の接続に対するリソースの予約を行う要求を行うアプリケーションと、該接続に割り当てられた該リソースのステータスに関するイベントの通知を受信するよう、前記ブリッジのポータルに登録するアプリケーション、とを有することを特徴とする装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信ネットワーク、特に無線リンクによって相互接続された有線通信バスを有するネットワーク、における、無線リンクであり得る、リンク上の接続を管理する方法に関するものである。
【背景技術】
【０００２】
複数の相互接続伝送媒体を有するネットワークにおいては、各伝送媒体上で利用可能な帯域幅は必ずしも同じでない。
【０００３】
例えば、２つの、5GHzのETSI（欧州電気通信標準化協会）BRAN（広帯域幅無線アクセス・ネットワーク）ハイパーラン２無線リンクを用いてお互いに接続された、IEEE1394有線シリアル・バスを検討する場合、各有線バス上で利用可能な帯域幅は100Mb/s以上になり得る一方、無線リンク上で利用可能な帯域幅は30Mb/sまでに制限され得る。したがって、無線リンクはこのリンクを用いた接続に対してボトルネックをもたらす。
【０００４】
図１はそのようなネットワークの一例の図である。該ネットワークは２つの、ソース装置13及びシンク装置14に接続されたバス11及び、シンク装置15及びソース装置16に接続されたバス12を有する。ソース装置13は例えば、ディジタルVCRである一方、シンク装置14及び15はディスプレイで、ソース装置16はチューナである。バス11はポータル17にも接続される一方、バス12はポータル18に接続され、両方のポータルがバス11とバス12との間の無線リンクを形成する。無線リンクはIEEE1394のレベルで装置13乃至16に対して透過である、すなわち、これらの装置は、該装置が同じ物理バスにある印象を有する。
【０００５】
無線リンク上で利用可能な帯域幅が30Mb/sと仮定して、20Mb/sの第１接続がVCR13とディスプレイ15との間で確立される。第２接続はチューナ16とディスプレイ14との間で確立し得るが、それは当該リンクが装置16及び14に対して透過であるからであるが、この第２接続に必要な帯域幅が残りの無線帯域幅よりも大きい場合、ディスプレイ14は、仮に映像を表示したとしても、好ましい映像は表示しない。第２接続を構築したアプリケーションに関して言うと、該接続はそれでも、IEEE1394レベルでの影響なく確立されるが、それはそのレベルでの当該リンクの透過性によるものであるが、実際は、一部のデータしか当該リンクを通らないか、データが全然当該リンクを通らない。
【０００６】
更に、従来の方法で、この問題点に関するものがある（例えば、「METHOD  FOR  MANAGING  BANDWIDTH  OVER  A  WIRELESS  LINK  IN  A  COMMUNICATION  NETWORK」と題するThomson  Licensing  SAによる西暦2001年5月29日付出願の欧州特許出願に関する特許文献１参照。）。
【特許文献１】欧州特許出願公開第０１１１３１２１．６号明細書
【発明の開示】
【発明が解決しようとする課題】
【０００７】
本発明は、少なくとも２つの装置クラスタをインタフェースするブリッジを有する通信ネットワークにおける接続を管理する方法に関し、該接続は、各々が異なるクラスタに接続された、第１装置と第２装置、との間で確立され、該接続を確立するよう形成されたアプリケーションのレベルで：
ブリッジ上の接続に対する予約リソースを要求する工程；及び
接続に割り当てられたリソースのステータスに関する少なくとも１つのイベント・タイプの通知を受信するよう、該ブリッジのポータルに登録する工程；
を有する。
【課題を解決するための手段】
【０００８】
本発明の実施例によれば、ポータルは接続を確立する装置が接続されたクラスタのノード、すなわちブリッジの中央制御装置である。
【０００９】
本発明の実施例によれば、予約リソースに対する要求は、通知を送信する、アプリケーションのアドレスを有する。
【００１０】
本発明の実施例によれば、アドレスはアプリケーションをホストするノードのアドレス領域におけるオフセットを有する。
【００１１】
本発明の実施例によれば、ブリッジはアイソクロナス・リソース・マネージャを有する無線ブリッジで、更に、リソース予約要求を受信する工程に加えて、ポータルに、該要求をアイソクロナス・リソース・マネージャに転送させ、その応答を待たせて、該応答をアプリケーションに返信させる、工程を有する。
【００１２】
本発明の実施例によれば、該方法は更に、ポータルのレベルで、アイソクロナス・リソース・マネージャとの予約に成功した場合、当該接続に関係する全てのポータルに対して予約のパラメータを送信する工程を有する。
【００１３】
本発明の実施例によれば、ポータルに対してパラメータを送信する工程はアイソクロナス・リソース・マネージャの応答をアプリケーションに対して転送する工程の前に実施される。
【００１４】
本発明の実施例によれば、アプリケーションによる予約要求はブリッジのアイソクロナス・リソース・マネージャに対してアドレス指定可能な予約要求と類似したフォーマットを有し、アプリケーションによる該予約要求は接続用ソース及びシンク・ノードの識別子を有し、当該ポータルは更に、アプリケーションの予約要求のソース及びシンク・ノード識別子を、ソース及びシンク・ノードをブリッジに接続するポータルの識別子によって、置換する工程及びアイソクロナス・リソース・マネージャの応答において逆の変更を実施する工程を実施する。
【００１５】
本発明の実施例によれば、該方法は更に、アプリケーションのレベルで、ブリッジから、該ブリッジのどのポータルが接続に関係しているかを判定するよう、トポロジー情報を受信する工程を有する。
【００１６】
本発明の実施例によれば、アプリケーションによる予約要求は更に、ブリッジに対する接続のソース及びシンク・ノードを接続するポータルの識別子を有する。
【００１７】
本発明は更に、ブリッジによって接続された複数のクラスタを有する通信ネットワークにおけるクラスタに対して接続する装置に関し、該装置はブリッジ上の接続に対するリソース予約を要求するアプリケーションと、接続に対して割り当てられたリソースのステータスに関するイベントの通知を受信するブリッジのポータルに登録するアプリケーションとを有する。
【発明を実施するための最良の形態】
【００１８】
本発明の他の特性及び利点は非限定的実施例の説明及び添付図面の説明からわかる。
【００１９】
該実施例はIEEE1394バスを接続するETSI  BRAN  ハイパーラン２無線リンクの利用に基づいたものであるが、当該リンクについてもサブネットワークについても、他の技術を用い得る。当該リンク用の別の技術の例はインターネット・プロトコル（「IP」）である。更に、有線バス間のリンクは必ずしも無線でなくてもよいが、以下の実施例ではこれがあてはまる。
【００２０】
IEEE1394バスに関する追加情報は米国電気電子学会（IEEE）によって編集された標準化資料、特に資料A：IEEE1394-1995及び資料B：IEEE1394a-2000、において見つけることができる。ハイパーラン２は欧州電気通信標準化協会（ETSI）によって定義された広帯域幅無線アクセス・ネットワーク（BRAN）である。
【００２１】
ハイパーラン２を用いたIEEE1394ネットワークの接続に関する情報は特に、資料C：ETSI  TS  101  493-3  V1.2.1B(2001-010)-技術仕様-広帯域幅無線アクセス・ネットワーク（BRAN）-ハイパーラン  タイプ２-パケット・ベース・コンバージェンス・レイヤ：Part  3：IEEE1394サービス依存部コンバージェンス・サブレイヤ（SSCS）、及び資料D：ETSI  TS  101  493-4  V1.1.1(2001-07)-技術仕様-広帯域幅無線アクセス・ネットワーク（BRAN）-ハイパーラン  タイプ２-パケット・ベース・コンバージェンス・レイヤ：Part  4：IEEE1394ブリッジ依存部ファンクションズ・サブレイヤにおいて見つけることができる。
【００２２】
背景情報の最後の資料は、IEC（国際電気標準会議）によって発表された、資料E：IEC61883「Digital  Interface  for  Consumer  Audio/Video  Equipment」である。該第１部は特に、リスナ及びトーカ装置の入力プラグと出力プラグとの間の接続を確立することを説明している。
【実施例】
【００２３】
図２は（装置クラスタ又はサブネットワークとも呼ばれる）３つのIEEE1394バス201、202、及び211、によって形成されたネットワークを表し、該バス各々は有線IEEE1394バス、複数の装置（各々、ノード203、204、209及び205、206、210及び212）及び、無線ハイパーラン２リンクに対する（バス207、208及び213各々に対する）ハイパーラン２(HL2)ノード又は「ポータル」を有する。該ノードはIEEE1394装置である。本説明の目的で、少なくともノード209のアプリケーションは無線リンクの存在及び特性を知っている。
【００２４】
本実施例によれば、HL2ノード207、208及び213は他の装置に対して、該ノードは更に該ノード各々のバス上のノードとしてもみなされる、すなわち、該ノードはバス再設定後に物理識別子が付与される、という意味で、透過でない。IEEE1394レイヤのレベルでは、しかしながら、リンクは透過である、すなわち、全てのノードは単一のバス上にあるとみなされ、物理識別子が再設定後適宜、付与される。HL2ノード207及び208は自己識別パケットを出して該ノード各々のクラスタ上のノードを、バス再設定が実施される場合、表現する。
【００２５】
各ノードはIEEE1394ソフトウェア・スタック、すなわち、物理層、リンク層及びトランザクション層、更にはアプリケーション層、を有する。各HL2ノードは更に、これらの層を当該有線バス・インタフェース上に有する。最後に、HL2ノードはハイパーラン２プロトコル・スタックを用いて通信する。
【００２６】
ハイパーラン２ネットワークにおいては、中央制御装置として動作するノードを有し、更に該ノードには無線ノードが登録する。中央制御装置は更に、ハイパーラン２無線フレームにおいてリソースを割り当てる役目を担う。資料Cは、中央制御装置のIEEE1394サービス依存部コンバージェンス・サブレイヤ（SSCS）中にある、アイソクロナス・リソース・マネージャ（「IRM」）を定義する。HL2  IRMの目的はチャネル及び帯域幅予約機能を設けることにあるが、それはCHANNEL＿AVAILABLE及びBANDWIDTH＿AVAILABLEレジスタをその対応IEEE1394として設けるものでない。異なる物理モードが無線リンク上のリスナ・ノードとトーカ・ノードとの間で考えられるので、利用可能な帯域幅はトーカ及びリスナによって変わってくる。
【００２７】
無線ネットワーク上でアイソクロナス・ストリームをストリーミングする間に起こる課題のひとつに、無線フレームにおいて予約される時間スロットの量がソースと行き先の位置によって変わってくるということがある。異なるソース及び行き先は同じ変調手法を用いないことがあり、したがってフレームにおける時間スロットの点から同様な要件を有しないことがある。変調手法（物理モード）の選定はソースと行き先との間のリンク・バジェットによって変わってくる。これが、資料Eに記載されたようなIEC-61883CMP（接続管理プロトコル）を修正して、それを無線環境の制約に形成するよう1394ＳＳＣＳを定義する場合の理論的根拠となっている。
【００２８】
本実施例によれば、資料Cの付録A.4に記載されたようなHL2  IRMインタフェースはHL2アウェア・アプリケーションに対してアクセス可能にされる。
【００２９】
リンク・バジェットが特定のストリームに対して時間がたてば減少することがあり得るので、ストリームがある程度の時間が経過した後、停止され得る。本発明によれば、ストリームがHL2ネットワーク上で停止される場合にアプリケーションが通知され得るよう、イベントのメカニズムが定義される。
【００３０】
有線HL2アウェア・アプリケーションは、有線装置上で実行しているが、ハイパーラン/2ネットワークを用いた透過ブリッジの存在を知っている、アプリケーションとして定義される。本明細書及び特許請求の範囲における、このHL２アウェア・アプリケーションに対する、処理は任意のものである。それらが実施されなければ、それらはストリーミングが無線ネットワーク上で確立されることを妨げない。しかしながら、それらが実施された場合、それらはアプリケーションが、リソース予約に成功したかどうかを、知ることを可能にする。それは更に接続が切断されたかについて通知されることを可能にする。
【００３１】
ノードは以下に：
「トーカ」はアイソクロナス・データをソースする有線又は無線ノードである；
「リスナ」はアイソクロナス・データをシンクする有線又は無線ノードである；
HL2アウェア・アプリケーションのHL2ペアレントはこのHL2アウェア・アプリケーションをHL2ネットワークに接続するHL2ノードである；
トーカのHL2ペアレントはトーカをHL2ネットワークに接続するHL2ノードである；及び
リスナのHL2ペアレントはリスナをHL2ネットワークに接続するHL2ノードである；
として、示す。
【００３２】
ノードは、資料Dに規定されたような構成ROMにおける所定オフセットでのユニット・ディレクトリを含む場合、HL2ノードとして特定される。このユニット・ディレクトリは「指定子＿ID（識別子）」及び「バージョン」と呼ばれるパラメータを含み、そしてそれはいかなるIEEE1394ノードをも、対象ノードがHL2ノードかどうかを検証することを可能にする。0180c216及び00020016がHL2ノードを特徴付ける。
【００３３】
HL2ユニット・ディレクトリは更にロック・コマンドを送信するのに用いるアドレス・オフセットを記述する項目を含む。このアドレス・オフセットはIEEE1212セクション4.2に記載されたように0xFFFF  F000  0800で開始するユニット領域にある。この項目のフォーマットは図３に示す。
【００３４】
図４は図２のネットワークの図で、上記に示されたものの一部を、ノード209がHL2アウェア・アプリケーション、ノード210がリスナ・ノード及びノード212がトーカ・ノードである場合について、表す。例示の目的で、HL2  IRMはHL2ノード213によって管理される。
【００３５】
HL2  IRMインタフェースを次に説明する。
【００３６】
本発明によれば、HL2アウェア・アプリケーションはそのローカル・バスのノードの構成ROMを検査する。更に、どのノードがHL2ユニット・ディレクトリを含み、したがってどのノードがHL2ノードであるかを検出する。
【００３７】
中央制御装置の1394SSCSレイヤはHL2  IRMを含み、そのインタフェースは1394SSCS技術仕様（資料C）に記載されている。
【００３８】
無線1394アプリケーションは通常、ロック・コマンドを送信してシリアル・バス上でリソース予約を行う。
【００３９】
HL2アウェア・アプリケーション（有線装置上で実行している、例えば、ノード209）がHL2ノードの存在をそのローカル・バス上で検出する場合、それは、本実施例によって、1394SSCS資料によって規定された、アイソクロナス・ストリームをオープン及びクローズするコマンドと同様なコマンドを用いる。有線アプリケーションはHL2  IRMがどのノード上で実行しているかを必ずしも知っているわけではないので、図４、ノード207の例の場合、有線アプリケーションがこれらのコマンドをそのペアレントHL2ノードに対して（適切な内部トポロジー・マップを調べた後）送信することが提案されている。それはこれらのコマンドを当該HL2ユニット・ディレクトリ項目において規定されたアドレス・オフセットに対して送信する。
【００４０】
変形実施例によれば、このアドレスも固定化し得、当該HL2ユニット・ディレクトリ項目においてコード化される必要はない。
【００４１】
ペアレント無線ノード209はHL2  IRMがどのHL2ノード(207)上で実行するかを知っている。それがロック・コマンドを受信する場合、それはこのコマンドをプロキシとして動作するHL2  IRMに対して伝える。HL2  IRMがロック応答をペアレント無線ノード207に返信する場合、それはこの応答をアプリケーションまで戻す。
【００４２】
ロック・コマンドをうまく伝えた（すなわち、HL2アウェア・アプリケーション・アクションがHL2  IRMによってうまく完了された）、HL2アウェア・アプリケーションのペアレント無線ノードは、リスナ及びトーカ各々のHL2ペアレント・ノードのHL2  iPCR（プラグ制御レジスタ）及びoPCRプラグ制御レジスタを、対応するペイロード値によって構成するので、HL2アイソクロナス予約プロトコルを、HL2アウェア・アプリケーションによる更なるアクションがなにもなくても、完了し得る。
【００４３】
次に新規コマンドを説明する：
新規コマンドはHL2要求/応答システムに基づくものである。要求コマンドはチャネルを割り当て、特定量の帯域幅を割り当て、チャネル及び帯域幅を開放して、バス再設定後に再び割り当てることを可能にする。図５に一般メッセージ・フォーマットを表す。
【００４４】
パラメータは以下：
「コマンド」：表１に詳細に記載した、要求のコマンド；
【００４５】
【表１】
2005510178.tif 000003
「ステータス」：表２に詳細に記載した、応答のステータス；
【００４６】
【表２】
2005510178.tif 000004
の通リである。
【００４７】
コマンドは２段階：
HL2アウェア・アプリケーションがこれらのコマンドについて何を知る必要があるか；及び
HL2ノードがこれらのコマンドについて何を知る必要があるか；
にて、説明する。
【００４８】
ALLOCATE＿SOMEコマンド
図６は本実施例による、このコマンドのフォーマットを示す。
【００４９】
パラメータ
HL2  1394  SSCS仕様とは異なるかたちで用いられるフィールドには、本明細書及び添付図面において、下線を付す：
コマンド：この場合、0x00である；
talker＿ID：トーカ・ノード（ストリームのソース）の物理ID；
listener＿ID：リスナ・ノード（ストリームのシンク）の物理ID；
チャネル：1394IRMで既に割り当てられた1394チャネル；
ペイロード：（IEC-６１８８３に記載されたような）ストリームに対するデータ・ペイロード。これはoPCRで読み取られるか、又は、アプリケーションによって与えられる；
通知CSRオフセット高：HL2ペアレント・ノードから1394アプリケーションへの通知に用いられるCSRオフセットの最初の16ビット；
通知CSRオフセット低：HL2ペアレント・ノードから1394アプリケーションへの通知に用いられるCSRオフセットの最後の32ビット；
ステータス：以下に記載したような応答ステータス。
【００５０】
HL2アウェア・アプリケーションは実際のトーカ及びリスナのノードIDを（これらが有線ノードであっても）、ALLOCATE＿SOMEロック・コマンドのtalker＿ID及びlistener＿IDフィールドにおいて、用いる。
【００５１】
HL2ノード動作
ペアレント無線ノードはどのHL2のノード上でIRMが実行するかがわかる。それは更に、無線ネットワークのトポロジー・マップがわかる。ALLOCATE＿SOMEロック・コマンドを受信すると、チャネル・フィールドを取り外して（HL2  SSCSロック・コマンドを生成して）実際のtalker＿ID及びlistener＿IDを各々の無線ペアレント・ノードのnode＿IDに変換する。更に、1394ペイロード・フィールドをHL2ペイロード・フィールドに変換する（ペイロード値はIEEE1394バス上とハイパーラン２上とでは異なったかたちで表す。）更に、このコマンドを、プロキシとして動作するHL2  IRMに伝える。
【００５２】
IRMロック応答を受信すると、ペアレント無線ノードはHL2  IRMによって割り当てられた無線チャネルを有線1394チャネルによって置換する。更にtalker＿ID、listener＿ID及びペイロード・フィールドを初期有線1394値と置換して、更にこの応答をアプリケーションに伝える。
【００５３】
ペアレント無線ノードはチャネル値を記憶してハイパーラン２チャネルとIEEE1394チャネルとの間のマッピングを実施する。それはさらに、notification＿CSR＿offsetフィールドを記憶して、該フィールドは更にHL2アウェア・アプリケーションに、リンク上の割り当てアプリケーション帯域幅がもう保証できない場合に、通知するのに用いられる。これについては以下のイベント通知の記載部分で詳細に説明する。
【００５４】
ペアレント無線ノードは更に、HL2トーカ・ノードとHL2リスナ・ノードとが通信するよう、「透過ブリッジ間管理」コマンド（例えば、ロック・ベースのコマンド、又はある特定のレジスタに対する書き込み要求）を生成して、HL2無線チャネルを1394有線チャネルにマッピングする。
【００５５】
最終的には、上記のように、ペアレントHLS無線ノードは、1394SSCS（資料C）に記載されたように、トーカ及びリスナ各々のHL2ペアレント・ノードのiPCR及びoPCRを構成する。
【００５６】
MODIFY＿BANDWIDTHコマンド
図７は本実施例による、このコマンドのフォーマットを示す。
【００５７】
パラメータ
コマンド：この場合、0x01である
チャネル：（有線）1394IRMで既に割り当てられたような1394チャネル
ペイロード：（IEC-61883に記載されたような）ストリームに対するデータ・ペイロード。これはoPCRから読み取られるか、アプリケーションによって与えられる。
【００５８】
このコールは既に割り当てられたチャネル上の帯域幅を変更するのに用いられる。ペイロード値は前の値を置換する。ペイロードに対してナル値でコールされた場合、チャネルは開放されない。このコマンドはアプリケーションによって該アプリケーションのペアレントHL2ノードに送信される。
【００５９】
HL2ノード動作
HL2ペアレント・ノードはこのコマンドを傍受する。それはチャネル及びペイロード・フィールドを対応するHL2チャネル及びペイロード・フィールドに変換してこのコマンドをHL2  IRMに伝える。HL2ペアレント・ノードはロック応答をIRMから受信してHL2チャネル及びペイロード・フィールドを、該応答をHL2アウェア・アプリケーションに送り返す前に、変更する。
【００６０】
RECLAIM＿THISコマンド
図７は、本実施例による、このコマンドのフォーマットを示す。
【００６１】
パラメータ
コマンド：この場合、0x02である。
【００６２】
チャネル：1394IRMで既に、再び割り当てられたような1394チャネル
ペイロード：既に上記で説明したような、ストリームに対するデータ・ペイロード
このコールはバス再設定後にチャネル及び帯域幅を再び割り当てるのに用いられる。このコマンドはアプリケーションのペアレントHL２ノードに送信される。
【００６３】
HL2ノード動作
バス再設定が、HL2バス再設定の場合に、HL2バス上で伝播されると、HL2ペアレント・ノードはこのコマンドを傍受する。それはチャネル及びペイロード・フィールドを対応するHL2チャネル及びペイロード・フィールドに変換してこのコマンドをHL2  IRMに伝える。IRMからロック応答を受信するHL2ペアレント・ノードは、HL2チャネル及びペイロード・フィールドを逆変換してHL2アウェア・アプリケーションに返信する。
【００６４】
RELEASE＿THISコマンド
図８は本実施例による、このコマンドのフォーマットを示す。
【００６５】
パラメータ
コマンド：この場合、0x03である。
【００６６】
チャネル：（1394IRMにおいて開放されたように）開放されるチャネル
このコールはチャネル及びその関連する帯域幅を開放するのに用いられる。このコマンドはアプリケーションのペアレントHL2ノードに送信される。
【００６７】
HL2ノード動作
HL2ペアレント・ノードはこのコマンドを傍受する。それはチャネル・フィールドを対応するHL2チャネル・フィールドに変換してこのコマンドをHL2  IRMに伝える。ロック応答をIRMから受信するHL2ペアレント・ノードはHL2チャネル・フィールドを逆変換してそれをHL2アウェア・アプリケーションに返信する。
【００６８】
次にイベント通知について説明する。
【００６９】
上述のように、ハイパーラン２のような無線ネットワークの特異性は、帯域幅特性が、動的パラメータである、リンク・バジェットによって変わってくることである。以後、このレベルでのいかなる問題をもアプリケーションに通知する通知メカニズムを明確化する。
【００７０】
ALLOCATE＿SOME要求によって、アプリケーションはHL2ペアレント・ノードにこの通知に対するアドレス・オフセットを設ける。このオフセットはアプリケーションの1394ノードのCSR領域における特定のレジスタを特定する。このメカニズムによって、全てのアプリケーションはこの目的で、特定のレジスタを有し得る。
【００７１】
問題がHL2バス上で発生する場合、HL2ペアレント・ノードはHL2バスによってイベント・メカニズムが（1394SSCS付録Aにおいて定義されたイベント通知専用HL2＿CSRを用いて）通知される。アプリケーションに帯域幅の問題を通知するよう、HL2ペアレント・ノードはこのレジスタ上で1394クアドレット書き込み要求を、図９に示すフォーマットによって、行う。
【００７２】
「ステータス」パラメータは、表３で示すように、帯域幅の問題の原因を示す。
【００７３】
【表３】
2005510178.tif 000005
「チャネル」パラメータは当該問題によって左右される1394チャネルを示す。パラメータはアプリケーションが当該問題に係わるストリームを特定することを可能にする。
【００７４】
次に接続処理を説明する。
【００７５】
本実施例による、HL2アウェア・アプリケーションが従ういくつかの方法を示す。それらは接続の設定、接続の切断、バス再設定後の設定の再確立、及び接続のオーバレイに関する。
【００７６】
設定
接続を設定するよう、アプリケーションは少なくとも以下の：
a.他のバス装置の構成ROMを解析してローカル・バス上でのHL2ノードの存在を検出する；
b.無線リンクのトポロジー・マップを要求して、どのHL2ノードがソースとシンクとの間の経路上にあるかを確かめる；
c.ソースのoPCRに読み取り要求を行って要求帯域幅を判定する。この情報は更に、クライアントによって直接設けられ得る；
d.シンクのiPCRに読み取り要求を行ってそれが空き状態であることを検証する；
e.読み取り要求を：
1.IRM  BANDWIDTH＿AVAILABLEレジスタ；
2.IRM  CHANNELS＿AVAILABLEレジスタ；
に行う；
f.ロック要求を：
1.IRM  BANDWIDTH＿AVAILABLEレジスタ；
2.IRM  CHANNELS＿AVAILABLEレジスタ；
に行う（このように、工程c.乃至f.はIEC61883に従う）；
g.ALLOCATE＿SOMEロック要求をそのペアレントHL2ノードに行う；
h.ALLOCATE＿SOMEが成功であった場合、ロック要求を（IEC61883に記載されたように）：
1.ソースのoPCR；
2.シンクのiPCR；
に行う；
i.さもなければ、有線バス上のリソースを（IEC61883に記載されたように）開放して障害を報告する；
工程の一部を行う。
【００７７】
アクションの順序は例示的なものであって、他の組み合わせも考えられる。
【００７８】
切断
接続をクローズするよう、アプリケーションは少なくとも以下の工程の一部を実施する：
読み取り要求を：
それがオーバレイされていないことを検証するよう、ソースのoPCRに行う；
IRM  BANDWIDTH＿AVAILABLEレジスタに行う；
ロック要求を：
IRM  BANDWIDTH＿AVAILABLEレジスタに行う；
IRM  CHANNELS＿AVAILABLEレジスタに行う；
ソースのoPCRに行う；
シンクのiPCRに行う。
【００７９】
RELEASE＿THISロック・コマンドをそのHL2ペアレント・ノードに対して、ストリームが渡る各HL2リンクについて、送信する。
【００８０】
工程３は更に、工程１の直後に行い得ることを特筆する。
【００８１】
バス再設定後の再確立
バス再設定はHL2ネットワーク上を伝搬するので、接続を構築したアプリケーションはバス再設定が発生したことを、それがHL2ネットワークのもう一方の側でのことでも、知っている。再確立は基本的に、接続の設定と同様な規則に、ALLOCATE＿SOMEロック・コマンドがRECLAIM＿THISロック・コマンドによって置換されることを除いて、従う。
【００８２】
オーバレイ
接続をオーバレイするよう、アプリケーションは無線ネットワークのトポロジー・マップを要求し、無線ネットワークがソースとシンクとの間の経路上にあるかを確かめて、帯域幅をHL2リンク上で予約しなければならないかを推定しなければならない。無線ネットワークが以前、該経路上になかった場合、ALLOCATE＿SOMEコマンドが生成されなくてはならず、処理はその場合、接続の処理になる。接続の新規リスナのiPCRへの書き込みも行われる。
【００８３】
その新規リスナに対して、利用可能なリンク・バジェットが十分でない場合、アプリケーションは、本明細書にイベント通知に関して記載したような、通知メッセージに依存し得る。
【００８４】
透過ブリッジによって開始されたリソース予約関係：
透過ブリッジはＰＣＲロック応答を傍受してＨＬ２バス上でのリソース予約を引起す。これらのリソース予約は時には、ＨＬ２アウェア・アプリケーションによって引起されたリソース予約と衝突する。この課題は以下のように解決される：
ＨＬ２アウェア・アプリケーションは最初に、ＨＬ２リソースを予約（ＡＬＬＯＣＡＴＥ＿ＳＯＭＥコマンドを送信）して、それが終わった後にのみ、ロック要求及び応答をノードＰＣＲに送信する必要がある。
【００８５】
ＨＬ２リソース予約がうまくいった（ペアレント・ノードが肯定ＡＬＬＯＣＡＴＥ＿ＳＯＭＥ応答をＩＲＭからうまく受信した）後、ＨＬ２ペアレント・ノードはブリッジ間管理コマンド（ロック・ベース・コマンド又はクアドレット書き込みベース・コマンド）を他のＨＬ２ノードに、それらにＨＬ２チャネルの存在と現時の1394チャネルとのマッピングについて通知するよう、送信する必要がある。
【００８６】
本変形例によれば、ＨＬ２ペアレント・ノードはブリッジ間管理コマンドを、ＡＬＬＯＣＡＴＥ＿ＳＯＭＥコマンドをＨＬ２アウェア・アプリケーションに伝える前に、送信する。その場合、全てのＨＬ２ノードがこのＨＬ２チャネルの確立について、ＰＣＲロック応答を傍受する前に、通知される。したがって、これらのＨＬ２ノードは同様な予約を再び、ＰＣＲロック応答を受信する場合に、行おうとしない。
【００８７】
以下の変形例を上記の実施例に形成し得る：
(a)1394アプリケーションはHL2ペアレント・ノードにHL2ペアレント・トーカ及びリスナ・ノードの物理識別子（「PhyID」）を、ALLOCATE＿SOMEメッセージ中にて、送信する。これはHL2ペアレント・ノードの動作を、該HL2ペアレント・ノードがこの情報を自ら判定する必要がなくなることで、容易にする。
【００８８】
(b)1394アプリケーションはロック・コマンド（ALLOCATE＿SOMEなど）をある、所定のHL2ノード（例えば、中央制御装置）に送信して、そのリンク・ペアレントには送信しない。所定のHL2ノードは更に、1394アプリケーションのHL2ペアレント・ノードを判定する。
【００８９】
(c)（例えば「SUBSCRIBE」と呼ばれる）新規要求はアプリケーションがリソース予約とは無関係にイベントを利用することを可能にするよう定義される。言い換えれば、アプリケーションはそれが要求において規定するチャネルに関するイベントを受信する。要求「UNSUBSCRIBE」も定義される。
【００９０】
(d)RECLAIM_THIS要求を削除することが考えられるが、それは1394バス再設定がHL2バス再設定をもたらさないからであり、逆も同様である。
【００９１】
本発明はアプリケーションが要求ストリームを確立することが可能かどうかを知ることを可能にする。
【００９２】
本発明はリンク・リソース管理をすっきりさせることを可能にする。
【００９３】
本発明は1394-1995及び1394a-2000最適化アルゴリズムに、接続管理において、従うものである。
【００９４】
本発明は2つ以上の1394クラスタを相互接続するネットワークを対象とする。
【００９５】
本発明はアプリケーションが利用者に、ストリームの確立が不可能である場合に、警告することを可能にする。これは、通常一緒に用いられるソース及びシンクを無線リンクの同じ側におくことによって、異なるトポロジー・マップによってネットワークがよりよく機能することを、利用者に示唆するスマート・アルゴリズムにつながり得る。図１の例によれば、アプリケーションはソース１とソース２を逆にすることを示唆し、そしてそれは図10のトポロジーにつながる。
【図面の簡単な説明】
【００９６】
【図１】上述の、無線リンクを有して、このリンクによってもたらされる帯域幅ボトルネックを示す、ネットワークの図である。
【図２】３つのサブネットワーク間のリンクを有して、本実施例による方法を実施するネットワークの図である。
【図３】HL2ノード・ユニット・ディレクトリにおけるアドレス・オフセット・レジスタの図である。
【図４】図２のネットワークの別の表現の、接続に関係するいろいろなノードの役目を説明する、図である。
【図５】本実施例において定義されたメッセージの一般メッセージ・フォーマットの図である。
【図６】「ALLOCATE＿SOME」コマンドのメッセージ・フォーマットの図である。
【図７】以下の：「MODIFY＿BANDWIDTH」；「RECLAIM＿THIS」；コマンドのメッセージ・フォーマットの図である。
【図８】「RELEASE＿THIS」コマンドのメッセージ・フォーマットの図である。
【図９】イベント通知用データ・クアドレット書き込み要求フォーマットの図である。
【図１０】リンク上のボトルネックを回避するノード接続変更後のネットワークにおけるリンクの図である。
【図１】
2005510178.tif 000006
【図２】
2005510178.tif 000007
【図３】
2005510178.tif 000008
【図４】
2005510178.tif 000009
【図５】
2005510178.tif 000010
【図６】
2005510178.tif 000011
【図７】
2005510178.tif 000012
【図８】
2005510178.tif 000013
【図９】
2005510178.tif 000014
【図１０】
2005510178.tif 000015
【手続補正書】
【提出日】平成16年5月25日(2004.5.25)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】請求項１
【補正方法】変更
【補正の内容】
【請求項１】
少なくとも２つの装置クラスタをインタフェースするブリッジを有する通信ネットワークにおける接続を管理する方法であって、該接続が、異なるクラスタに接続された、第１装置と第２装置との間で確立され、該接続を確立するよう形成されたアプリケーションのレベルで：
前記ブリッジ上の前記接続に対するリソースの予約を行う要求を行う工程；及び
該要求を行う間に、前記接続に割り当てられた該リソースのステータスに関する少なくとも１つのイベント・タイプの通知を受信するよう、前記ブリッジのポータルに登録する工程；
を有することを特徴とする方法。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】０００７
【補正方法】変更
【補正の内容】
【０００７】
本発明は、少なくとも２つの装置クラスタをインタフェースするブリッジを有する通信ネットワークにおける接続を管理する方法に関し、該接続は、各々が異なるクラスタに接続された、第１装置と第２装置、との間で確立され、該接続を確立するよう形成されたアプリケーションのレベルで：
ブリッジ上の接続に対する予約リソースを要求する工程；及び
該要求する間に、接続に割り当てられたリソースのステータスに関する少なくとも１つのイベント・タイプの通知を受信するよう、該ブリッジのポータルに登録する工程；
を有する。
【手続補正書】
【提出日】平成16年6月30日(2004.6.30)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】請求項１
【補正方法】変更
【補正の内容】
【請求項１】
少なくとも２つの装置クラスタをインタフェースするブリッジを有する通信ネットワークにおける接続を管理する方法であって、該接続が、異なるクラスタに接続された、第１装置と第２装置との間で確立され、該接続を確立するよう形成されたアプリケーションのレベルで：
前記ブリッジ上の前記接続に対するリソースの予約を行う要求を行う工程；及び
前記接続に割り当てられた該リソースのステータスに関する少なくとも１つのイベント・タイプの通知を受信するよう、前記ブリッジのポータルに登録する工程；
を有することを特徴とする方法。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】０００７
【補正方法】変更
【補正の内容】
【０００７】
本発明は、少なくとも２つの装置クラスタをインタフェースするブリッジを有する通信ネットワークにおける接続を管理する方法に関し、該接続は、各々が異なるクラスタに接続された、第１装置と第２装置、との間で確立され、該接続を確立するよう形成されたアプリケーションのレベルで：
ブリッジ上の接続に対する予約リソースを要求する工程；及び
接続に割り当てられたリソースのステータスに関する少なくとも１つのイベント・タイプの通知を受信するよう、該ブリッジのポータルに登録する工程；
を有する。
【国際調査報告】
2005510178.tif 000016
2005510178.tif 000017
2005510178.tif 000018
2005510178.tif 000019