(57)【要約】本発明は少なくとも１つのリンクを介して接続されたバスを含む通信ネットワークにおけるリンクのリソース管理方法に関しており、バスに接続されたノードの複数のプロトコル層に対して少なくとも１つのリンクがトランスペアレントとなるネットワークを形成する。本発明の方法はリンクアウェアアプリケーションにとって利用可能な少なくとも１つのリンクを介して利用可能なリソースの情報を形成することを特徴とする。
2004527987.tif 000002
【特許請求の範囲】
【請求項１】
バスに接続されたノードの複数のプロトコル層に対して少なくとも１つのリンクがトランスペアレントとなるネットワークを形成するために、
少なくとも１つのリンクを介して接続されたバスを含む通信ネットワークにおけるリンクのリソース管理方法において、
リンクアウェアアプリケーションにとって利用可能な少なくとも１つのリンクを介して利用可能なリソース情報を形成する
ことを特徴とする通信ネットワークにおけるリンクのリソース管理方法。
【請求項２】
各リンクが複数のポータルを含んでおり、ここで少なくとも１つのポータルがリンクに関するリソース情報を含んでいる、請求項１記載の方法。
【請求項３】
リソース情報はリンクを介して利用可能な帯域幅のデータを含んでいる、請求項２記載の方法。
【請求項４】
リソース情報はリンクを介して利用可能なチャネルのデータを含んでいる、請求項２または３記載の方法。
【請求項５】
アプリケーションによりネットワークの２つのノード間のコネクションを確立する際に（ａ）バスコネクションに対してチャネルおよび帯域幅をリザーブするステップと、（ｂ）接続すべきノード間のパス上のリンクを識別するステップと、（ｃ）ステップａが有効であったときパスの各リンクに対するリソースをリザーブするステップとを行う、請求項４記載の方法。
【請求項６】
前記ステップｃにおいてアプリケーションによりステップａでリザーブされたものと同じ帯域幅および同じチャネルのリザーブを要求する、請求項５記載の方法。
【請求項７】
前記ステップｃにおいて、アプリケーションにより接続すべきノードの識別子をリザーブすべきリソースを有するリンクのポータルへ送信し、当該のリンクについて要求された帯域幅が利用可能であるか否かを接続されるノードに関連して判別し、当該の判別に関連して帯域幅のリザーブ要求を認容するかまたは拒否する、請求項６記載の方法。
【請求項８】
前記ステップｃにおいて、リンクについて要求されたチャネルの利用可能性を検査し、チャネルが利用可能であればチャネルリザーブを認容し、当該のリンクについてリザーブされたチャネルの数が最大数に達したか否かを検査し、達した場合には以降のリザーブを拒否する、請求項７記載の方法。
【請求項９】
ネットワークのチャネルの利用可能性を表すレジスタと各リンクのチャネルの利用可能性を表すレジスタとを設け、ここで２つのレジスタは同数のチャネルを有しており、
各リンクは同時にリザーブできるチャネルの最大数を有しており、当該の最大数はレジスタのチャネル数に等しいかそれより小さく、
リンク検査のためのリソース情報を表すポータルにより、チャネルリザーブが認容された後、同時にリザーブできるチャネル数が最大数に達したか否かを検査し、達した場合には当該のリンクに対して利用可能なチャネルが存在しないことが表示されるようにリンクのレジスタを修正する、
請求項７記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は通信ネットワークにおけるリンク（例えば無線リンク）のリソース管理方法に関する。本発明は特に無線リンクを介して接続された有線通信バスを含むネットワークにおけるリンクのリソース管理方法に関する。
【０００２】
複数の伝送媒体が接続されるネットワークでは、各伝送媒体で利用可能な帯域幅が必ずしも一致していない。
【０００３】
例えば５ＧＨｚのＥＴＳＩＢＲＡＮＨｉｐｅｒｌａｎ２の無線リンクを用いてＩＥＥＥ１３９４の２つの有線シリアルバスを接続すると、各有線バスで利用できる帯域幅は１００Ｍｂ／ｓ以上となるにもかかわらず、無線リンクで利用できる帯域幅は３０Ｍｂ／ｓにとどまる。その結果、このリンクを用いたコネクションにとって無線リンクがネックとなってしまう。
【０００４】
図１にはこのようなネットワークの例が示されている。このネットワークは２つのバス１１、１２を有しており、バス１１はソース装置１３およびシンク装置１４へ、バス１２はシンク装置１５およびソース装置１６へ接続されている。例えばソース装置１３はディジタルＶＣＲであり、シンク装置１４、１５はディスプレイであり、ソース装置１６はチューナである。さらにバス１１はポータル１７に、バス１２はポータル１８に接続されており、２つのポータルはバス１１、１２間の無線リンクを形成している。当該の無線リンクは装置１３〜１６に対してＩＥＥＥ１３９４のレベルでトランスペアレントであり、つまりこれらの装置は同じ物理バス上にあると見なすことができる。
【０００５】
当該の無線リンクで利用可能な帯域幅が３０Ｍｂ／ｓであり、第１のコネクションがＶＣＲ１３とディスプレイ１５とのあいだに２０Ｍｂ／ｓで形成されるとする。このリンクは装置１４、１６にとってもトランスペアレントであるので、チューナ１６とディスプレイ１４とのあいだに第２のコネクションを形成することはできるが、この第２のコネクションに必要な帯域幅が残りの無線帯域幅より大きいとディスプレイ１４は適切な画像を表示することができなくなる。しかし、第２のコネクションを形成したアプリケーションが関与しているかぎり、ＩＥＥＥ１３９４のレベルがトランスペアレントであるために、このレベルでは問題なくコネクションが確立されたことになっている。
【０００６】
したがって本発明の課題は、少なくとも１つのリンクを介して接続されたバスを含む通信ネットワークにおけるリンクのリソース管理方法において、バスに接続されたノードの複数のプロトコル層に対して少なくとも１つのリンクがトランスペアレントとなるネットワークを形成することである。この課題は本発明により、リンクアウェアアプリケーションにとって利用可能な少なくとも１つのリンクを介して利用可能なリソースの情報を形成することにより解決される。
【０００７】
本発明の１つの実施形態によれば、各リンクが複数のポータルを含んでおり、ここで少なくとも１つのポータルがリンクに関するリソース情報を含んでいる。
【０００８】
本発明の別の実施形態によれば、リソース情報はリンクを介して利用可能な帯域幅のデータを含んでいる。リソース情報はリンクを介して利用可能なチャネルのデータを含むこともできる。
【０００９】
本発明のさらに別の実施形態によれば、アプリケーションによりネットワークの２つのノード間のコネクションを確立する際に（ａ）バスコネクションに対してチャネルおよび帯域幅をリザーブするステップと、（ｂ）接続すべきノード間のパス上のリンクを識別するステップと、（ｃ）ステップａが有効であったときパス上の各リンクに対するリソースをリザーブするステップとが行われる。
【００１０】
本発明のさらに別の実施形態によれば、前記ステップｃにおいてアプリケーションによりステップａでリザーブされたものと同じ帯域幅および同じチャネルのリザーブを要求する。
【００１１】
本発明のさらに別の実施形態によれば、前記ステップｃにおいて、アプリケーションにより接続すべきノードの識別子をリザーブすべきリソースを有するリンクのポータルへ送信し、リンクについて要求された帯域幅の利用可能性を接続すべきノードに関連して判別し、この判別に関連して帯域幅のリザーブ要求を認容するかまたは拒否する。
【００１２】
本発明のさらに別の実施形態によれば、前記ステップｃにおいて、リンクについて要求されたチャネルの利用可能性を検査し、チャネルが利用可能である場合にはチャネルリザーブを認容し、リンクについてリザーブされたチャネル数が最大数に達したか否かを検査し、達した場合には以降のリザーブを拒否する。
【００１３】
本発明のさらに別の実施形態によれば、ネットワークのチャネルの利用可能性を表すレジスタと各リンクのチャネルの利用可能性を表すレジスタとを設け、ここで２つのレジスタが同数のチャネルを有するようにする。各リンクは同時にリザーブできるチャネル数の最大数を有しており、当該の最大数はレジスタ内のチャネル数に等しいかそれより小さい。リンク検査のためのリソース情報を表すポータルは、チャネルリザーブが認容された後、同時にリザーブできるチャネル数の最大数に達したか否かを検査し、達した場合には当該のリンクに対して利用可能なチャネルが存在しないことが表示されるようにリンクのレジスタを修正する。
【００１４】
本発明の他の特徴および利点を添付図を参照しながら以下の実施例に則して説明する。ただしこれらの実施例は本発明を限定するものではない。
【００１５】
図１にはリンクによって生じる帯域幅の問題を示すための従来の無線リンクを含むネットワークが示されている。図２には本発明の実施例の無線リンクを含むネットワークと本発明で用いられるレジスタとが示されている。このネットワークには無線リンクを形成するポータル装置内のソフトウェアスタックも存在する。図３には無線リンクで利用可能なチャネルを表すレジスタを使用してチャネルをリザーブするプロセスのフローチャートが示されている。図４にはリザーブされたチャネルをリリースするプロセスのフローチャートが示されている。図５には本発明の別の実施例によるリンクの帯域幅のリザーブプロセスが示されている。図６には図５の帯域幅のリリースプロセスが示されている。図７には本発明の別の実施例により種々のネットワーク間で共有されるマルチポータルリンクが示されている。図８には無線リンクの利用を低減するように修正された図１のネットワークでのノードとバスとのコネクションが示されている。
【００１６】
本発明の実施例はＥＴＳＩＢＲＡＮＨｉｐｅｒｌａｎ２無線リンクを基礎としているが、他のテクノロジも使用可能である。こうしたテクノロジの例としてインターネットプロトコルＩＰが挙げられる。さらに以下では有線バス間のリンクが無線であるケースについて説明するが、本発明にとって無線リンクが必須であるというわけではない。
【００１７】
ＩＥＥＥ１３９４についての情報は刊行物ＩＥＥＥ１３９４−１９９５およびＩＥＥＥ１３９４ａ−２０００に記載されている。
【００１８】
１．一般的な情報
理解しやすくするために、それぞれ２つずつポータルを有するリンクを示した図を参照しながら実施例を説明する。ただし本発明は３つ以上のポータルを有するリンクにも適用可能である。
【００１９】
図２には２つのＩＥＥＥ１３９４バス２１、２２（以下デバイスクラスタとも称する）から成るネットワークが示されている。それぞれ有線のＩＥＥＥ１３９４バスは、複数の装置すなわち各ノード２３、２４、２９および２５、２６、３０と、無線のＨｉｐｅｒｌａｎ２リンクへのポータル２７および２８とを有している。ノードはＩＥＥＥ１３９４装置である。アプリケーションは無線リンクの存在と位置とについてアウェアである。
【００２０】
この実施例によれば、ポータル２７および２８は他の装置にとってはトランスペアレントではない。これはこれらの装置が各バス上のノードとは見なされず、バスのリセット後に物理的な識別子が付されることを意味する。しかしＩＥＥＥ１３９４層のレベルではリンクはトランスペアレントであり、全てのノードが単一のバス上にあってリセット後にも相応の物理的な識別子が属するものと見なされる。ポータル２７、２８はバスのリセットが行われると自身でそれぞれのクラスタ上のノードを表すＩＤパケットを作成する。
【００２１】
各ノードはＩＥＥＥ１３９４のソフトウェアスタックを有している。これは物理層、データリンク層、トランザクション層およびアプリケーション層である。各ポータルはこれらの層を有線のバスインタフェース上に有しており、Ｈｉｐｅｒｌａｎ２のプロトコルスタックを使用して通信を行う。
【００２２】
２．リンクリソースマネージャおよび関連するレジスタ
本発明によれば、ノードのアプリケーションにとって種々のクラスタ上で利用可能な無線リンクのリソースのリザーブ情報をポータルが形成する。この実施例では、この情報はリンクで利用可能な帯域幅およびチャネルを含む。この情報は無線リンクの少なくとも１つのポータル内に存在する‘無線リソースレジスタ’内に保持され、種々のバス上のノードのアプリケーションまたはミドルウェアからアクセス可能である。
【００２３】
ＩＥＥＥ１３９４バスは、ＩＥＥＥ１３９４−１９９５規格に定められているように、いわゆるIsochronous Resource Manager：ＩＲＭを有することが知られており、これは‘BANDWIDTH＿AVAILABLE’および‘CHANNELS＿AVAILABLE’と称される２つのレジスタを保持している。これらのレジスタはそれぞれ６４個の最大同時チャネルのうちバス上で利用可能な帯域幅およびチャネルを表す。
【００２４】
この実施例ではＩＥＥＥ１３９４層に関するかぎり無線リンクがトランスペアレントであるので、ネットワークには単一のＩＲＭが存在する。
【００２５】
ＩＲＭの‘BANDWIDTH＿AVAILABLE’レジスタは上述の規格では次表１によって定義されている。
【００２６】
【表１】
2004527987.tif 000003
【００２７】
bw＿remainingの初期値は０×１３３３（１０進法の４９１５）の帯域幅単位に等しい。ノードのアプリケーションが有線バスの帯域幅をリザーブしようとするたびに、この値が検査され、充分な帯域幅が利用できる場合には要求された帯域幅分がデクリメントされる。利用できない場合にはコネクションは確立されない。
【００２８】
ＩＲＭの‘CHANNELS＿AVAILABLE’レジスタは上述の規格では次表２によって定義されている。
【００２９】
【表２】
2004527987.tif 000004
【００３０】
このレジスタの初期値は０×ＦＦＦＦＦＦＦＦである。各ビットは特定のチャネルの利用可能性を表している。CHANNELS＿AVAILABLE＿hiの最下位ビットはチャネルの利用可能性０を表しており、CHANNELS＿AVAILABLE＿loの最上位ビットはチャネル６３を表している。アプリケーションが有線バスの帯域幅をリザーブしようとするたびにレジスタが検査され、利用可能なチャネルが選択され、レジスタの相応のビットが０へセットされる。利用可能なチャネルが存在しない場合にはコネクションは確立されない。
【００３１】
帯域幅またはチャネルをリザーブするために、レジスタはまず最初に読み出し要求メッセージを介してアプリケーションにより読み出される。アプリケーションはレジスタの内容を含んだ読み出し応答メッセージを受け取る。要求されたリソースの利用可能性が検査された後、このアプリケーションは相応のレジスタへのアクセスをロックし、適切な新しい値を書き込む。このロックおよび書き込みのオペレーションは、アプリケーションがロック要求を作成しＩＲＭがロック応答を返送することにより行われる。ＩＥＥＥ１３９４−１９９５によればレジスタは個別にアクセスされる。ＩＥＥＥ１３９４−２０００によれば、ロック要求について対立が生じた場合にはロック応答として実際値が返送されるので、読み出しが必ず行われるわけではない。
【００３２】
この実施例によれば、リソースマネージャはリンクレベルで実現されている。このリソースマネージャはＩＥＥＥ１３９４−１９９５のＩＲＭと区別するために以下では‘リンクリソースマネージャ’または‘ＬＲＭ’と称される。
【００３３】
この実施例によれば、ＬＲＭは無線リンクの１つのポータル内に実現されている。ＬＲＭは２つのレジスタ、つまり‘LINK＿BANDWIDTH＿AVAILABLE’レジスタおよび‘LINK＿CHANNELS＿AVAILABLE’レジスタを管理しており、これらのレジスタはそれぞれ無線リンクで利用可能な帯域幅およびチャネルおよびその他の情報を示している。
【００３４】
本発明によるＬＲＭの‘LINK＿BANDWIDTH＿AVAILABLE’レジスタは次表３のフォーマットを有している。
【００３５】
【表３】
2004527987.tif 000005
【００３６】
‘LRM＿bw＿remaining’はＩＲＭの‘BANDWIDTH＿AVAILABLE’レジスタのbw＿remainingフィールドに類似したシグニフィケーションを有している。リンクで利用可能な帯域幅が有線バスで利用可能な帯域幅と異なっている場合、このパラメータの初期値は異なってくる。リンクを介した帯域幅のほうが小さい場合、このフィールドの初期値は小さくなる。帯域幅が大きい場合にはリザーブが行われてもゼロには決して達しない。なぜなら無線リンクに接続されたバス上の帯域幅が制限係数となるからである。
【００３７】
‘Source＿PhyID’フィールドはソース装置の物理識別子を含む。‘Sink＿PhyID’フィールドはシンク装置の物理識別子を含む。これらのフィールドの内容はロック要求メッセージを用いてリザーブを行うアプリケーションによって定義される。このとき話者ノード（ソース側）のＩＤと聴取者ノード（シンク側）のＩＤとのＬＲＭが通知される。これらの識別子が既知となると、ＬＲＭは実際に利用可能な帯域幅を求めるが、これは後述するようにLRM＿BANDWIDTH＿AVAILABLEレジスタの‘link＿bw＿remaining’フィールドに示されているものとは異なることもある。
【００３８】
別の実施形態によれば、要求された‘Source＿PhyID’フィールドおよび‘Sink＿PhyID’フィールドはコネクションをリザーブすべきポータル間の物理識別子を含む。
【００３９】
２つ以上のポータルを備えた無線リンクでは、２つのポータル間で利用可能な帯域幅は異なっており、これは例えばポータル間の伝送品質の関数に依存している。ＬＲＭではどの２つのポータルがコネクションの一部となるのかが既知になっていないと実際にこれらのポータル間で利用可能な帯域幅を示すことができない。ポータルはＬＲＭによって話者ノードと聴取者ノードのＩＤから導出される。したがって‘link＿bw＿remaining’フィールドによって示される帯域幅は２つのポータル間で利用可能な実際の帯域幅を反映していない場合がある。
【００４０】
この実施例によれば、‘link＿bw＿remaining’フィールドは無線リンクのポータル間で利用可能な最大帯域幅を表している。したがってアプリケーションは要求量が‘link＿bw＿remaining’フィールドに示されている量よりも大きい場合、ただちに帯域幅のリザーブが不可能であることを判別できる。他のケースでは、ＬＲＭはまずリザーブに関与する２つのポータル間で利用可能な帯域幅を計算し、リザーブを許可または拒否し、ソースとシンクとのあいだで利用可能な実際の帯域幅をロック応答の‘link＿bw＿available’フィールドとして返送する。
【００４１】
別の実施例によれば、‘link＿bw＿remaining’フィールドはアプリケーションの要求しうる帯域幅の値よりも大きいダミー値を含んでいる。この場合ＬＲＭがつねに帯域幅のリザーブを拒否する。なぜならアプリケーションが読み出し要求から有効な帯域幅情報を導出できないからである。
【００４２】
無線リンクが厳密に２つのポータルに制限されている場合、このリンクを介して利用可能な帯域幅はソース装置およびシンク装置の関数とはならない。別の実施例によれば、このようなリンクを含むネットワークでは、ＬＲＭのLINK＿BANDWIDTH＿AVAILABLEレジスタの第１の２つのフィールドは要求されない。ただしこのフィールドは無線リンクの２つのポータル上では使用可能である。
【００４３】
‘channel’フィールドはリザーブを行うアプリケーションの要求したチャネルの数を含んでいる。この数はＩＲＭのCHANNELS＿AVAILABLEレジスタにすでに割り当てられた数と同じである。これは後述するように、アプリケーションがまず最初にＩＥＥＥ１３９４ネットワークのＩＲＭに対してリザーブを行い、その後、無線リンクのＬＲＭのリザーブを行うためである。このフィールドの内容はＬＲＭのLINK＿BANDWIDTH＿AVAILABLEにアクセスを求めるロック要求としてＬＲＭへ供給される。
【００４４】
‘ｆ’フィールドは当該のリンクで要求されたチャネルの利用可能性を表すフラグを含んでいる。このフィールドはロック応答において要求されたチャネルが利用可能であれば０となり、利用できなければ１となる。これはＬＲＭによりセットされる。
【００４５】
ＬＲＭのCHANNELS＿BANDWIDTH＿AVAILABLEレジスタは次表４で定義されるフォーマットを有する。これはＩＲＭのCHANNELS＿AVAILABLEレジスタのフォーマットに似ているが、異なって作用する個所もある。
【００４６】
【表４】
2004527987.tif 000006
【００４７】
このレジスタの内容はＩＲＭのCHANNELS＿AVAILABLEレジスタの内容と同じ意味を有する。
【００４８】
無線リンクはＩＥＥＥ１３９４バスの６４個のチャネル限界を超える最大チャネル数を許可することがある。たとえリンクがＩＥＥＥ１３９４よりも大きい数のチャネルを許可しても、使用できるのはＩＥＥＥ１３９４のチャネル数である。なぜならＩＥＥＥ１３９４ネットワークのＩＲＭがこの数に制限されるからである。
【００４９】
無線リンクがチャネルの小さいほうの数を許可すると、以下のアルゴリズムが用いられる。このアルゴリズムは図３のリザーブメカニズムおよび図４のリリースメカニズムとして示されている。
（ａ）‘link＿channels＿available’（‘link＿channels＿available＿hi’および‘link＿channels＿available＿lo’）ビットを初期値として１にセットしなければならない。
（ｂ）アプリケーションがリンクのＬＲＭによって空いたチャネルを要求したとき、これが最後の１つでなければチャネルのリザーブが認容され、チャネルのフラグが０にセットされる。
（ｃ）アプリケーションがチャネルを要求し、このチャネルが当該のリンクに対して利用可能な最後のチャネルであったときには（ＩＲＭのCHANNELS＿AVAILABLEレジスタに利用可能なチャネルが残っていても）、チャネルのリザーブは認容されるが、LINK＿CHANNEL＿AVAILABLEの全てのフラグが０にセットされる。これによりこのリンクを介してこれ以降チャネルが利用できないことが表される。
【００５０】
ＬＲＭはメモリ内にアプリケーションによって実際にリザーブされたレジスタのチャネルのリストを保持する。これに対して無線リンクによって課された制限のために単に利用不可能であるチャネルも存在する。
（ｄ）アプリケーションがチャネルをリリースすると、当該のチャネルのフラグが１にセットされる。リンクが完全にリザーブされた場合、このチャネルリリースにより全ての非リザーブチャネルフラグが１へセットされる。
【００５１】
LINK＿CHANNELS＿AVAILABLEレジスタはＩＲＭのCHANNELS＿AVAILABLEレジスタと同様には管理されない。これは読み出し要求を受け入れるが、ロック応答は受け入れない。したがってアプリケーションは無線リンクを介して利用可能なチャネルが残っているか否かを検査できる。実際のチャネルリザーブはLINK＿BANDWIDTH＿AVAILABLEレジスタのロック応答に続いてＬＲＭによってなされる。
【００５２】
３．レジスタの使用法
LINK＿BANDWIDTH＿AVAILABLEレジスタの機能は利用可能な帯域幅を表すことだけにとどまらない。読み出し要求によって読み出しが行われると、当該のリンクで利用可能な帯域幅が返送されるが、ロック要求は帯域幅のリザーブをトリガするだけでなく、チャネルリザーブもトリガする。これに対してLINK＿CHANNELS＿AVAILABLAVAILABLEレジスタは読み出しモードでしかアクセスされず、ロックモードではアクセスされない。
【００５３】
リザーブしようとするアプリケーションはまず最初にＩＲＭによるリザーブを実行し、次に得られたチャネル番号とリザーブされた帯域幅とを使用してソースノードとシンクノードとのあいだの無線リンクのリザーブを行う。
【００５４】
LINK＿BANDWIDTH＿AVAILABLEレジスタでロック要求が行われると、話者はＩＥＥＥ１３９４ネットワーク上のソース装置の‘PhyID’、ＩＥＥＥ１３９４ネットワーク上のシンク装置のPhyID、要求されたチャネル（このチャネルはすでにＩＲＭによって割り当てられている）、および新たな帯域幅の値を供給しなければならない。新たな帯域幅の値とは読み出し要求によって読み出され、リザーブすべき量だけデクリメントされた値のことである。
【００５５】
１つのメッセージ（ロック要求）により全ての割り当て（帯域幅およびチャネルの割り当て）が実行される。ソース装置およびシンク装置のPhyIDはリンクのＬＲＭがポータル間の異なる帯域幅を処理する能力を有している場合、これによって使用される。
【００５６】
LINK＿BANDWIDTH＿AVAILABLEレジスタの特性を以下に表５〜表７を用いて説明する。これらの表はそれぞれ読み出し要求およびロック要求に続いて得られた初期値を表している。
【００５７】
【表５】
2004527987.tif 000007
【００５８】
【表６】
2004527987.tif 000008
【００５９】
【表７】
2004527987.tif 000009
【００６０】
読み出し要求が行われると、link＿bw＿remaining値が読み出し応答として返送される。
【００６１】
ロック要求は先行して読み出された帯域幅の値［ＩＥＥＥ１３９４−１９９５の用語では‘arg＿value’フィールド］と新たな帯域幅の値［ＩＥＥＥ１３９４−１９９５の用語では‘data＿value’］とを含む。ＬＲＭはlink＿bw＿remainingフィールドのその時点での値とロック要求で受け取られた値とを比較する。値が等しければ、当該の読み出し要求およびロック要求のあいだに他の要求が許可されていないということなので、リザーブの処理が進行する。ここでlink＿bw＿remainingフィールドに書き込まれた新たな帯域幅の値は前述のマルチポータルリンクの計算ルールのために必ずしもロック要求およびロック応答で返送されない。換言すれば、次の読み出し要求が最後のロック要求で送信されたものの残りの帯域幅になるとはかぎらないということである。
【００６２】
LINK＿BANDWIDTH＿AVAILABLEレジスタでのロック要求で生じうるエラーの原因として次のことが考えられる。
（１）このリンクについて利用可能な帯域幅が当該の読み出し要求およびロック要求のあいだのインターバルで変更されており、ロック要求の‘arg＿value’が有効でなくなっているケース。ＬＲＭはこの状況をＩＲＭと同様に管理する。
（２）このリンクについてソースとシンクとのあいだで利用可能な帯域幅が充分でないケース。これはlink＿bw＿remainingフィールドで返送される値がこのリンクの伝送に対するベストの帯域幅であるためにレジスタの読み出し時には検出されないことがある。このときポータルに依存して異なる帯域幅容量を有するリンクは、ソースPhyIDとシンクPhyIDとのあいだのパスの実際の帯域幅を返送してからロックを拒否する。これはＬＲＭにとってロック要求メッセージからPhyIDが既知となるため、当該の特定のコネクションについて利用可能な真の帯域幅を計算できるからである。
（３）要求されたチャネルが利用できないケース。これは他のアプリケーションの要求したチャネルがすでにＩＲＭで割り当てられてしまっており、そのチャネルがリンクで利用可能な最後のチャネルであった場合にのみ発生する。このときはＩＲＭのCHANNELS＿AVAILABLEレジスタで幾つかのチャネルが空いていても利用できず、コネクションはリンクのＬＲＭを介しては確立できない。この場合にはＬＲＭは‘ｆ’を１へセットし、これをロック応答で返送する。
【００６３】
LINK＿CHANNELS＿AVAILABLEレジスタの特性を以下に表８、表９を用いて説明する。これらの表はそれぞれ読み出し要求およびロック要求に続いて得られた初期値を表している。
【００６４】
【表８】
2004527987.tif 000010
【００６５】
【表９】
2004527987.tif 000011
【００６６】
アプリケーションが要求したリザーブをソースノードとシンクノードとのあいだのリンクのＬＲＭで取得するのに失敗した場合、すでにリザーブされたリソースの割り当て解除を要求しなければならない。
【００６７】
４．ＬＩＮＫ＿ＢＡＮＤＷＩＤＴＨ＿ＡＶＡＩＬＡＢＬＥレジスタの使用例
以下ではＬＲＭのLINK＿BANDWIDTH＿AVAILABLEレジスタの使用例を表１０〜表１６を用いて説明する。この実施例ではリンクは最大で２つのチャネルをサポートしている。
【００６８】
レジスタの初期値は次表１０によって定義される。例えばこれは利用可能な帯域幅としてトータルで４９１５単位を有している。
【００６９】
【表１０】
2004527987.tif 000012
【００７０】
図２のノード２３のアプリケーションがソースノード２３とシンクノード２５とのあいだのリンクについてチャネルおよび帯域幅の割り当てを望んでいるとする。まずこのアプリケーションはＩＥＥＥ１３９４−１９９５のルールに則してＩＲＭでチャネルおよび帯域幅の割り当てを要求する。割り当てられたチャネルは例えばチャネル番号７であり、帯域幅は５００単位である。その後ノード２３のアプリケーションはＬＲＭのLINK＿BANDWIDTH＿AVAILABLEレジスタへロック要求を行う。そのパラメータを次表１１に示す。
【００７１】
【表１１】
2004527987.tif 000013
【００７２】
ロックが認容され、LINK＿CHANNELS＿AVAILABLEレジスタが更新されると、次表１２によって定義される応答が形成される。
【００７３】
【表１２】
2004527987.tif 000014
【００７４】
次にノード２６のアプリケーションがソースノード２６とシンクノード２４とのあいだのリンクについてチャネルおよび帯域幅の割り当てを決定する。ＩＲＭでのリザーブはすでになされたとする。例えばチャネルはチャネル番号３３であり、要求された帯域幅は１０００単位である。同時にノード２５のアプリケーションがソースノード２９とシンクノード３０とのあいだでチャネル１２および帯域幅２０００単位についてＬＲＭでのロック要求を行う。これは次表１３のように行われる。
【００７５】
【表１３】
2004527987.tif 000015
【００７６】
ロック要求が認容され、LINK＿CHANNELS＿AVAILABLEレジスタが更新されると、次表１４によって定義される応答が形成される。
【００７７】
【表１４】
2004527987.tif 000016
【００７８】
ノード２６のアプリケーションのロック要求はこのリンクが２つのチャネルしか供給していないために拒否される。
【００７９】
【表１５】
2004527987.tif 000017
【００８０】
当該のロック応答は拒否され、レジスタのフィールドは次表１６のようになる。
【００８１】
【表１６】
2004527987.tif 000018
【００８２】
‘ｆ’のフラグは１にセットされ、これによりこのリンクで利用可能なチャネルがもはや存在しないことが表される。link＿bw＿remainingフィールドは最後に更新された値、つまりノード２５のアプリケーションの要求が許可された後の値を示している。
【００８３】
ロック応答はSource＿PhyIDの値、Sink＿PhyIDの値およびチャネルフィールドを含んでおり、これにより話者は要求へのリプライを得ることができる。
【００８４】
リソースのリザーブまたはリリースの際には次のオペレーションが実行される。
（１）“Allocate new”（新規割り当て）
このオペレーションは新たなチャネルおよび所定量の帯域幅を割り当てるときに行われる。チャネルは利用可能で空いており、要求された帯域幅も利用可能である。このオペレーションは割り当てと称される。なぜなら先行して読み出され要求‘arg＿value’とともに送信された帯域幅の値がlink＿bw＿remainingフィールドに書き込むべき新たな値‘data＿value’よりも大きいからである。channel＿availableフラグは０へセットされる。
【００８５】
ＬＲＭはチャネルと割り当てられた帯域幅との関係を記憶する。本発明の別の実施例によれば、チャネルを帯域幅なしでリザーブすることもできる。こうした手段もポータルのベンダに応じて可能である。
（２）“Allocate more”（付加割り当て）
このオペレーションは先行して割り当てられたチャネルに対して充分な帯域幅が利用できる場合に付加的な帯域幅を割り当てるときに行われる。ＬＲＭはロック要求のチャネル番号がすでに割り当てられたチャネルに相応するという事実によってこのオペレーションを識別する。要求された帯域幅の差分がこのチャネルですでにリザーブされた帯域幅に加えられる。channel＿availableフラグは０のままである。ポータルはアプリケーションがすでに割り当てられたチャネルの帯域幅をリザーブして他のストリームを送信するのを妨げず、バス上での衝突も生じない［ＩＥＥＥ１３９４−１９９５］。
（３）“Release full”（フルリリース）
このオペレーションはチャネルとこのチャネルに対して割り当てられた帯域幅とがリリースされるときに行われる。ＬＲＭはロック要求（読み出し要求の結果であることもある）の‘arg＿value’フィールドが‘data＿value’（link＿bandwidth＿availableフィールドに書き込むべき新しい値であることもある）よりも小さいことからこのオペレーションをリリースとして識別する。リソースのリリースがフルリリースであるということは先行の２つのフィールドの差がこのチャネルに対して割り当てられた帯域幅に等しいという事実により示される。LINK＿CHANNELS＿AVAILABLEレジスタのチャネルのフラグは１にセットされ、ここが空いたことが示される。ロック要求で割り当てられた帯域幅以上のリリースが示されている場合、割り当てられた帯域幅のみがリリースされる。
（４）“Release some”（部分リリース）
このオペレーションは与えられたチャネルに対して一部の帯域幅のみがリリースされるときに行われる。ＬＲＭはロック要求の‘link＿bw＿remaining’フィールドの‘arg＿value’が‘data＿value’よりも小さく、その差がこのチャネルに割り当てられた帯域幅よりも小さいという事実によって、このオペレーションを部分リリースと識別する。チャネルはリザーブされたままLINK＿CHANNELS＿AVAILABLEレジスタ内に残り、相応のフラグも値０にとどまる。リリースされた帯域幅は当該のチャネルについて減算され、ＬＲＭはこれを記憶する。
【００８６】
１つのリンクについて利用可能な全てのチャネルがリザーブされた場合、LINK＿CHANNELS＿AVAILABLEレジスタの全てのフラグが０にセットされる。ＬＲＭはレジスタ内でマーキングされたものと比較して真にリザーブされたチャネルのリストを保持する。‘Allocate more’オペレーションに対するロック要求をＬＲＭが受け取ると、このＬＲＭはこの要求が真にリザーブされたチャネルに相応する場合にのみ付加的な帯域幅を割り当てる。
【００８７】
５．ＬＩＮＫ＿ＣＨＡＮＮＥＬＳ＿ＡＶＡＩＬＡＢＬＥレジスタの使用例
LINK＿CHANNELS＿AVAILABLEレジスタの使用例を以下に種々の時点でのレジスタ内容を示した表１７〜表２１を用いて説明する。この実施例では無線リンクは３つのチャネル容量を有している。
【００８８】
最初は無線リンクのどのチャネルも利用されていない。このときのLINK＿CHANNELS＿AVAILABLEレジスタのステータスは次表１７によって示される。
【００８９】
【表１７】
2004527987.tif 000019
【００９０】
第１のアプリケーションが例えばチャネル７をリザーブする。これが割り当てられた後、レジスタのステータスは次表１８によって示されるようになる。
【００９１】
【表１８】
2004527987.tif 000020
【００９２】
第２のアプリケーションがチャネル３３をリザーブする。レジスタのステータスは次表のようになる。
【００９３】
【表１９】
2004527987.tif 000021
【００９４】
このリンクにはあと１つしか利用可能なチャネルがない。第３のアプリケーションがチャネル２に割り当てられると、レジスタのステータスは次表のようになる。
【００９５】
【表２０】
2004527987.tif 000022
【００９６】
このリンクはもはやチャネルを供給できないので、全てのチャネルフラグが０にセットされる。第４のアプリケーションがこのリンクのレジスタを読み出しても、リザーブ可能なさらなるチャネルは導出できない。
【００９７】
ここで第２のアプリケーションがチャネル３３をリリースすると、レジスタのステータスは次表のようになる。
【００９８】
【表２１】
2004527987.tif 000023
【００９９】
この無線リンクではいま１つのチャネルが利用可能である。使用されていない全てのチャネルのフラグが１へセットされる。
【０１００】
有利には、１つのチャネルがグローバルなＩＲＭによるリザーブを必要とする事実によりまず複数の無線リンクでリザーブされるチャネルのＩＤが考慮されコンフリクトが生じないことが保証される。先にＩＲＭによって割り当てを受けていないチャネルがＬＲＭによってリザーブされることはない。
【０１０１】
ネットワークのアプリケーションは無線リンクアウェアであってもそうでなくてもよい。非リンクアウェアアプリケーションが１つまたは複数の無線リンクを含むコネクションを形成しようとする場合、このリンクのＬＲＭが自身の要求したリソースのリザーブを行えるように構成してもよいし、または本発明の別の実施例によりリンクアウェアアプリケーションによってなされたコネクションを優先させてもよい。
【０１０２】
６．コネクション形成プロセス
ここで本発明の実施例によりリンクアウェアアプリケーションの使用するコネクションプロセスを簡単に説明する。このプロセスはコネクション開始、コネクション終了、バスリセット後のコネクション確立、既存のコネクションに新たなコネクションを重ねるコネクションのオーバレイに関する。
【０１０３】
以下のプロセスには、１つまたは複数のリンクでリザーブすべきリソースが話者ノードと聴取者ノードとのあいだのパスに存在しているか否かを判別するためにアプリケーションはネットワークトポロジを取得する必要のあるものがある。
【０１０４】
アプリケーションはトポロジマップをＩＥＥＥ１３９４物理層から得ることができる。物理層はバスリセット後にこうしたマップを形成する。このマップは種々のノードがどのように接続されるかを表すものである。
【０１０５】
本発明によれば、各ポータルはメモリ内にポータルを指定する識別子を含んでいる。アプリケーションがバスリセット後に要求を行ってトポロジマップを取得すると、ネットワーク上の全てのノードのメモリへのアクセスが行われ、当該のノードがポータルであるか否かが判別される。リンクは２つのポータルが連続してトポロジマップ内で検出された場合に識別される。
【０１０６】
６．１コネクション開始
コネクションを開始するために、アプリケーションは次の（１）〜（５）を行わなければならない。
（１）ネットワークのトポロジマップを求め、１つまたは複数のリンクがソースノードとシンクノードとのあいだのパスに存在するか否かを検査する。
（２）ソースノードのアウトプットプラグコントロールレジスタ［ＩＥＥＥ１３９４バスを介しての同時ストリーム伝送を説明したＩＥＣ６１８８３に定義されている‘ｏＰＣＲ’］に対して、この情報が話者クライアント（例えばアプリケーション）によって与えられたのでない場合に帯域幅を取得するための読み出し要求を行う。
（３）ＩＲＭのBANDWIDTH＿AVAILABLEレジスタに対してＩＥＥＥ１３９４ネットワーク上で利用可能な帯域幅を取得するための読み出し要求を行う。さらにＩＲＭのCHANNELS＿AVAILABLEレジスタに対してＩＥＥＥ１３９４ネットワーク上で利用可能なチャネルのリストを取得するための読み出し要求を行う。さらにコネクションのクロスしている各リンクのＬＲＭのLINK＿BANDWIDTH＿AVAILABLEレジスタに対して利用可能な帯域幅を取得するための読み出し要求を行う。さらにコネクションのクロスしている各リンクのＬＲＭのLINK＿CHANNELS＿AVAILABLEレジスタに対してチャネルの利用可能性を検査するための読み出し要求を行う。さらにシンクノードのインプットプラグコントロールレジスタ［ＩＥＣ６１８８３に定義されている‘ｉＰＣＲ’］に対してこれが空いていてストリームを受け取れるか否か確認するための読み出し要求を行う。
（４）ＩＲＭのBANDWIDTH＿AVAILABLEレジスタに対してＩＥＥＥ１３９４ネットワーク上で利用可能な帯域幅をリザーブするためのロック要求を行う。さらにＩＲＭのCHANNELS＿AVAILABLEレジスタに対してＩＥＥＥ１３９４ネットワーク上で利用可能なチャネルをロックするためのロック要求を行う。
（５）要求が有効であった場合、コネクションがクロスしている各リンクのＬＲＭのLINK＿BANDWIDTH＿AVAILABLEレジスタに対して、ソースのPhyID、シンクのPhyIDおよびＩＲＭですでに割り当てられているチャネル番号とが各リンクの帯域幅をリザーブするためにロック要求として送信される。さらにソースのｏＰＣＲに対してコネクションの存在が表すようにロック要求が行われ、レジスタが修正される。さらにシンクのｉＰＣＲに対してコネクションの存在が表されるようにロック要求が行われ、レジスタが修正される。
【０１０７】
６．２コネクション終了
コネクションを終了するために、アプリケーションは次の（１）〜（２）を行わなければならない。
（１）オーバレイされていない／コネクションに１つの聴取者ノードしかが存在しないことを確認するための読み出し要求をソースのｏＰＣＲに対して行う。さらに読み出し要求をＩＲＭのBANDWIDTH＿AVAILABLEレジスタに対して行う。さらに読み出し要求をコネクションのクロスする各リンクについてＬＲＭのLINK＿BANDWIDTH＿AVAILABLEレジスタに対して行う。
（２）ロック要求をＩＲＭのBANDWIDTH＿AVAILABLEレジスタに対して行う。さらにロック要求をＩＲＭのCHANNELS＿AVAILABLEレジスタに対して行う。さらにロック要求をコネクションのクロスする各リンクについてＬＲＭのLINK＿BANDWIDTH＿AVAILABLEレジスタに対して行う。さらにロック要求をソースノードのｏＰＣＲに対して行う。さらにロック要求をシンクノードのｉＰＣＲに対して行う。
【０１０８】
６．３ネットワークリセット後のコネクション再形成
バスリセットはリンクを介して伝播する。コネクションを形成したアプリケーションはバスリセットが発生したことにアウェアであり、どこであっても起源となりうる。再形成は基本的にコネクション形成と同じルールにしたがって行われる。ＬＲＭレジスタはＩＲＭレジスタと同様にリセットされる。
【０１０９】
６．４コネクションのオーバレイ
コネクションをオーバレイするために、アプリケーションは次の（１）〜（４）を行わなければならない。
（１）トポロジマップを求め、１つまたは複数のリンクがソースノードとシンクノードとのあいだのパス上に存在するか否かを検査し、いずれがコネクションに対してリザーブされているかを導出する。
（２）読み出し要求をソースのｏＰＣＲに対して行い、話者クライアントによって与えられているのでない場合、要求された帯域幅を既知にする。
（３）コネクションのクロスする各リンクのＬＲＭのLINK＿BANDWIDTH＿AVAILABLEレジスタに対して各リンクで利用可能な帯域幅を取得するための読み出し要求を行う。さらにコネクションのクロスする各リンクのうちまだリザーブされていないものについてＬＲＭのLINK＿CHANNELS＿AVAILABLEレジスタに対してチャネルの利用可能性を検査する読み出し要求を行う。さらにシンクノードのｉＰＣＲに対してこれが空いていることを確認するための読み出し要求を行う。
（４）コネクションのクロスしている各リンクのＬＲＭのLINK＿BANDWIDTH＿AVAILABLEレジスタに対してソースのPhyID、シンクのPhyIDおよびＩＲＭですでに割り当てられているチャネル番号とがロック要求で送信される。さらにソースのｏＰＣＲに対してロック要求を行う。さらにシンクのｉＰＣＲに対してロック要求を行う。
【０１１０】
上述のプロセスを用いてアプリケーションはコネクションが形成されるか否かということと、なぜ充分なリソースが得られなかったかということを検出する。本発明の目的ではないが、ここで別のプロセスにより失敗したコネクションを回避するためにアプリケーションにネットワークトポロジの修正を提案させることもできる。
【０１１１】
図８には図１のネットワークが表されている。ここではソース１３がバス１２に、ソース１６がバス１１にそれぞれ接続されており、ユーザに対するアプリケーションの指示に応じて動作する。
【０１１２】
７．帯域幅の使用法の改善形態
第１のアプリケーションが３０Ｍｂ／ｓを提供しているＨｉｐｅｒｌａｎ２リンクを介して２０Ｍｂ／ｓの帯域幅をリザーブする場合１０Ｍｂ／ｓの帯域幅が余るが、第２のアプリケーションが１５Ｍｂ／ｓを要求するとリザーブはできない。
【０１１３】
本発明の別の実施例によれば、リンクのＬＲＭによりリザーブ要求に対してアプリケーションが実際に使用した帯域幅が確認され、差分が他のアプリケーションの割り当てに利用可能となる。
【０１１４】
図５には１つのリンクを介して利用可能な帯域幅を表す垂直のバーが示されている。この実施例では利用可能な帯域幅はトータルで１０単位である。アプリケーションがリザーブした各チャネルについてＬＲＭは２つのパラメータを保持する。第１のパラメータ（以下‘Ｒ’と称する）はリザーブされた帯域幅を表す。第２のパラメータ（以下‘Ｏ’と称する）はリザーブされた帯域幅とチャネル上のアプリケーションが実際に使用した帯域幅とのあいだの差を表す。Ｏはこのチャネルに対して最適化された帯域幅を表している。
【０１１５】
図５の実施例によれば、３つのアプリケーションＡ１、Ａ２、Ａ３が帯域幅を順次にリザーブしようとしている。参照記号Ｒ、Ｏの近傍に示された値はそれぞれ各アプリケーションに対する帯域幅を表している。
【０１１６】
第１のアプリケーションＡ１はステップ１でチャネル７上に３単位をリザーブしているが、ＬＲＭはこのアプリケーションが１単位しか使用していないことを検出した。ＬＲＭはＡ１に対するパラメータＯをステップ２で値２へセットする。その後、第２のアプリケーションＡ２がステップ３でチャネル３３上に４単位をリザーブしたが、２単位しか使用しなかった。このアプリケーションに対するパラメータＯはステップ４で値２へセットされる。さらに第３のアプリケーションＡ３がステップ５でチャネル２上に４単位をリザーブし、これを全て使用した。したがって３単位が他のアプリケーションに対して割り当て可能であり、ＬＲＭは新たなlink＿bw＿available値を適切にセットする。
【０１１７】
図６にはアプリケーションが図５の帯域幅をリリースする様子が示されている。アプリケーションはリザーブした帯域幅と使用した帯域幅とが個別に考えられることにアウェアでないので、適当なロック要求を用いてリザーブ量をリリースしようとする。
【０１１８】
第１のアプリケーションＡ１がチャネルおよび帯域幅をステップ６でリリースしようとしている。このアプリケーションはlink＿bw＿available値３を３単位増大するロック要求を送信する。ＬＲＭはアプリケーションＡ１が３単位のリリースを行おうとしていることに対して、３単位増大されたlink＿bw＿available値を含むポジティブのロック応答を返送してシミュレートする。ただしこれについては実際に使用された単位量、すなわち１のみの増大が有効である。同様のコンセプトがＡ２、Ａ３のリソースリリースについても当てはまる。
【０１１９】
プロシージャによっては、アプリケーションはロック要求においてLINK＿BANDWIDTH＿AVAILABLEレジスタ内で与えられる最大帯域幅よりも大きな帯域幅値を使用しなければならないことがある。例えばステップ８において、４単位の帯域幅をリリースするために、第２のアプリケーションＡ２は値１２を‘data＿value’としてロック要求で使用する。なぜならこのレジスタのその時点での値が８だからである。
【０１２０】
ただしアプリケーションによる帯域幅のリリースでは０×１ＦＦＦを超える帯域幅値は使用されない。なぜならこれがこのためにリザーブされた１３ビットで符号化することのできる最大値であるからである。つまりＬＲＭは１つのチャネル上の帯域幅を０×１ＦＦＦから当該のリンクで利用可能な帯域幅最大値を減算した値よりも大きくは増大しない。
【０１２１】
例えばリンクの帯域幅０×１３３３についてどのチャネルの増大の限度も最大値０×ＣＣＣを超えない。
【０１２２】
８．単一のリンクを用いた複数のネットワークのコネクション
本発明の別の実施例によれば、１つのリンクが同時に複数のタイプのネットワークによって用いられる。図８には４つのポータル７４〜７７を含むリンクが示されている。ポータル７４、７５はそれぞれ２つのＩＥＥＥ１３９４バス７０、７１に接続されている。ポータル７６、７７はそれぞれ２つのＩＥＥＥ１３９４バス７２、７３に接続されている。２つのバス７０、７１はリンクを介してトランスペアレントに接続されている。つまり低い層では全てのバス装置が単一のバス上に存在していると見なすことができる。同様のことが２つのＩＰネットワークにも当てはまり、全てのＩＰ装置は単一のＩＰネットワーク上に存在すると見なすことができる。バス７０、７１およびＩＰネットワーク７２、７３から成るネットワークは互いの存在を無視する。ただしこれらはポータル７４〜７７によって形成されるリンクのリソースの利用を共有している。ポータルは単一の装置内にまとめられていてもよいし、また例えば無線リンクの場合のように個別の装置として形成してもよい。
【０１２３】
ポータルは帯域幅リソースを２つのタイプのネットワークに割り当てなければならない。この実施例によれば、個別のＬＲＭがそれぞれのタイプのネットワークに対して設けられる。この実施例では１つのＬＲＭがＩＥＥＥ１３９４バスのネットワークに対して設けられ、もう１つのＬＲＭがＩＰネットワークに対して設けられる。２つのＬＲＭを以下ではＬＲＭ‐１３９４およびＬＲＭ‐ＩＰと称する。ＬＲＭ‐ＩＰを介したＩＰ装置のインタフェースはＬＲＭ‐１３９４を介したＬＲＭ‐１３９４ノードへのインタフェースと同様に設けなくてもよい。
【０１２４】
２つのＬＲＭは同じリソースを割り当てるので、これらはリソースの割り当てについての情報をリンクの実際のインプリメンテーションに応じて交換する。
【０１２５】
２つのバス間のリンクで使用される帯域幅については、たとえリンクの容量が大きくてもバス上で利用可能な帯域幅を超過することはできないことを前述した。この実施例では同じリソースに対して競合する複数のネットワークはネットワークに対する制限効果を所定の条件のもとで有する。
【０１２６】
以下のケースではリンク帯域幅がＩＥＥＥ１３９４帯域幅よりも大きいことを考慮している。
【０１２７】
この場合、ＩＰネットワーク上の帯域幅のリザーブはＬＲＭ‐１３９４のLINK＿BANDWIDTH＿AVAILABLEレジスタのbw＿remaining値をトータルのリンク帯域幅がＩＥＥＥ１３９４の０×１３３３単位よりも低くなるまで低減しない。同じ特性はチャネルにも当てはまる。またこれは逆についても真であり、つまりＩＥＥＥ１３９４ネットワークでリザーブされた帯域幅およびチャネルについても当てはまる。
【０１２８】
９．ＬＲＭ選択
本発明はネットワーク当たり１組のポータルのみ含むポイントツーポイントリンクでも機能するし、またネットワーク当たり２組以上のポータルを含むマルチポイントリンクでも機能する。どちらの場合にも所定のネットワーク内でＬＲＭ装置の選択について２つの手法が存在する。各ネットワークの１つのポータルがＬＲＭの役割を果たすとき、一方では各アプリケーションがメッセージをこの装置へ送信し、また一方では各アプリケーションがメッセージを接続されたポータルへ送信して、リンク内のプライベートプロトコルによってポータルを同期する。
【０１２９】
換言すれば、第１のケースではＬＲＭは全ての候補のなかから選択された単一のポータルにより管理され、選択されたポータルはアプリケーションにとって既知となる。第２のケースでは選択は行われず、アプリケーションはＬＲＭがどこに位置するのか知らないので単に最寄りのポータルへ要求を送信する。
【０１３０】
これらの２つの手法を以下にＩＥＥＥ１３９４バスのリンクを含むネットワークの例に則して説明する。
（ａ）ＬＲＭに対して単一のポータルが選択されるとき
１つのポータルがＬＲＭの役割を果たす。選択はネットワークまたはバスのリセット中に行われる。ＬＲＭ選択の２つの手法を以下に説明する。第１の手法はネットワークトポロジの分析に基づくものであり、第２の手法はポータルによってなされる決定に基づいて、選択されたＬＲＭの物理識別子がアプリケーションに報知されるかまたは曝露されるものである。
【０１３１】
トポロジアルゴリズム：候補のうち最大のPhyID値を有するポータルがＬＲＭとして選択される。このアルゴリズムはきわめて単純であり、トポロジがＩＥＥＥ１３９４の層からただちに利用可能となるので有利である。ただし各バスがリセットされた後にはアプリケーションはトポロジを検査し、各リンクについての新たなＬＲＭを定めなければならない。
【０１３２】
プライベートリンク選択：リンク内のダイナミックプロトコル、すなわちポータル間でリンク専用のプロトコルを介して選択が行われる。つまりバスリセット後にＬＲＭを変更することができ、例えばＬＲＭであったポータルが削除されることもある。
【０１３３】
さらにＩＥＥＥ１３９４アプリケーションに対してどのノードがＬＲＭとなっているかを知らせるために、ポータルのコンフィグレーションメモリ（‘config rom’）において専用エントリを定義しなければならない。この新たなエントリは全てのポータル装置のコンフィグレーションメモリに存在するようになる。
【０１３４】
この実施例にしたがってエントリされるメモリのフォーマットは次表２２のようになるが、別のフォーマットも可能である。
【０１３５】
【表２２】
2004527987.tif 000024
【０１３６】
‘ｓ’は同期ビットである。この同期ビットが１にセットされると、PhyID値は更新されてはおらず目下変更中であると考えられる。これは例えばバスリセット後に発生する。同期ビットが０にセットされると、PhyID値は当該のリンクのＬＲＭのPhyIDを表す。PhyID値の更新プロセスはリンクに対してプライベートとなっている。
（ｂ）ＬＲＭが選択されないとき
第２の手法では、各アプリケーションがメッセージすなわち読み出し要求およびロック要求を接続されたポータルへ送信する。各ポータルはＬＲＭレジスタを有している。リンク内のプライベートプロトコルによりポータル間の同期が実行され、同時に複数のロック要求が行われるコンフリクトが回避される。
【図面の簡単な説明】
【０１３７】
【図１】従来の無線リンクを含むネットワークを示す図である。
【０１３８】
【図２】本発明の実施例の無線リンクを含むネットワークと本発明で用いられるレジスタとを示す図である。
【０１３９】
【図３】チャネルをリザーブするプロセスのフローチャートである。
【０１４０】
【図４】リザーブされたチャネルをリリースするプロセスのフローチャートである。
【０１４１】
【図５】本発明の別の実施例によるリンクの帯域幅のリザーブプロセスを示す図である。
【０１４２】
【図６】図５の帯域幅のリリースプロセスを示す図である。
【０１４３】
【図７】本発明の別の実施例により種々のネットワーク間で共有されるマルチポータルリンクを示す図である。
【０１４４】
【図８】無線リンクの利用を低減するように修正された図１のネットワークでのノードとバスとのコネクションを示す図である。
【図１】
2004527987.tif 000025
【図２】
2004527987.tif 000026
【図３】
2004527987.tif 000027
【図４】
2004527987.tif 000028
【図５】
2004527987.tif 000029
【図６】
2004527987.tif 000030
【図７】
2004527987.tif 000031
【図８】
2004527987.tif 000032
【国際公開パンフレット】
2004527987.tif 000033
2004527987.tif 000034
2004527987.tif 000035
2004527987.tif 000036
2004527987.tif 000037
2004527987.tif 000038
2004527987.tif 000039
2004527987.tif 000040
2004527987.tif 000041
2004527987.tif 000042
2004527987.tif 000043
2004527987.tif 000044
2004527987.tif 000045
2004527987.tif 000046
2004527987.tif 000047
2004527987.tif 000048
2004527987.tif 000049
2004527987.tif 000050
2004527987.tif 000051
2004527987.tif 000052
2004527987.tif 000053
2004527987.tif 000054
2004527987.tif 000055
2004527987.tif 000056
2004527987.tif 000057
2004527987.tif 000058
2004527987.tif 000059
2004527987.tif 000060
2004527987.tif 000061
2004527987.tif 000062
2004527987.tif 000063
2004527987.tif 000064
2004527987.tif 000065
2004527987.tif 000066
2004527987.tif 000067
【手続補正書】
【提出日】平成15年7月9日(2003.7.9)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】０００５
【補正方法】変更
【補正の内容】
【０００５】
当該の無線リンクで利用可能な帯域幅が３０Ｍｂ／ｓであり、第１のコネクションがＶＣＲ１３とディスプレイ１５とのあいだに２０Ｍｂ／ｓで形成されるとする。このリンクは装置１４、１６にとってもトランスペアレントであるので、チューナ１６とディスプレイ１４とのあいだに第２のコネクションを形成することはできるが、この第２のコネクションに必要な帯域幅が残りの無線帯域幅より大きいとディスプレイ１４は適切な画像を表示することができなくなる。しかし、第２のコネクションを形成したアプリケーションが関与しているかぎり、ＩＥＥＥ１３９４のレベルがトランスペアレントであるために、このレベルでは問題なくコネクションが確立されたことになっている。
欧州特許出願公開第０９３３９００号明細書には、ＩＥＥＥ１３９４バスをＩＥＥＥ１３９４ブリッジを介して接続する方法が記載されている。ここでは各バスおよびブリッジは独立のバスから成っており、２つのノードは異なるバスから帯域幅およびチャネルをリザーブして、ノード間の同時通信を行うことができる。この方法では相応の３つの帯域幅のリザーブが独立の各バス上で行われる。３つのリザーブとは送信側ノードをホストしているバスで行われるものと、ブリッジで行われるものと、受信側ノードをホストしているバスで行われるものとの３つである。
上掲の明細書に記載されている手法とは異なり、本発明ではバスを接続しているリンクがトランスペアレントとなるケースを扱っている。これはバス上の１つのノードが同じネットワークに属する接続されたバスの全てのノードを見ることができることを意味している。


【手続補正２】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ネットワークがバスの使用するプロトコルを考慮して単一のバーチャルバスを形成するために、
少なくとも２つのバスがリンクに接続されている通信ネットワークにおけるリンクのリソース管理方法において、
ネットワークのノード内にリンクアウェアアプリケーションを設けてリンクのリソースリザーブ情報を取得するステップと、
リンクの装置間のコネクションを確立するために前記情報にアクセスするステップと、
コネクションを確立することができるか否かを前記情報に関連して判別するステップとを有する
ことを特徴とする通信ネットワークにおけるリンクのリソース管理方法。
【請求項２】
リンクアウェアアプリケーションはバスをリンクに接続するポータルのうち１つから前記情報を取得する、請求項１記載の方法。
【請求項３】
前記情報はリンクを介して利用可能な帯域幅のデータを含んでいる、請求項２記載の方法。
【請求項４】
前記情報はリンクを介して利用可能なチャネルのデータを含んでいる、請求項２または３記載の方法。
【請求項５】
アプリケーションによりネットワークの２つのノード間のコネクションを確立する際に（ａ）バスコネクションに対してチャネルおよび帯域幅をリザーブするステップと、（ｂ）接続すべきノード間のパス上のリンクを識別するステップと、（ｃ）ステップａが有効であったときパスの各リンクに対するリソースをリザーブするステップとを行う、請求項４記載の方法。
【請求項６】
前記ステップｃにおいてアプリケーションによりステップａでリザーブされたものと同じ帯域幅および同じチャネルのリザーブを要求する、請求項５記載の方法。
【請求項７】
前記ステップｃにおいて、アプリケーションにより接続すべきノードの識別子をリザーブすべきリソースを有するリンクのポータルへ送信し、当該のリンクについて要求された帯域幅が利用可能であるか否かを接続すべきノードに関連して判別し、当該の判別に関連して帯域幅のリザーブ要求を認容するかまたは拒否する、請求項６記載の方法。
【請求項８】
前記ステップｃにおいて、リンクについて要求されたチャネルの利用可能性を検査し、チャネルが利用可能であればチャネルリザーブを認容し、当該のリンクについてリザーブされたチャネルの数が最大数に達したか否かを検査し、達した場合には以降のリザーブを拒否する、請求項７記載の方法。
【請求項９】
ネットワークのチャネルの利用可能性を表すレジスタと各リンクのチャネルの利用可能性を表すレジスタとを設け、ここで２つのレジスタは同数のチャネルを有しており、
各リンクは同時にリザーブできるチャネルの最大数を有しており、当該の最大数はレジスタのチャネル数に等しいかそれより小さく、
リンク検査のためのリソース情報を与えるポータルにより、チャネルリザーブが認容された後、同時にリザーブできるチャネル数が最大数に達したか否かを検査し、達した場合には当該のリンクに対して利用可能なチャネルが存在しないことが表示されるようにリンクのレジスタを修正する、
請求項７記載の方法。
【国際調査報告】
2004527987.tif 000068
2004527987.tif 000069
2004527987.tif 000070