JP4364935B2 - 通信局、管理局、通信局の制御方法、管理局の制御方法、通信プログラム - Google Patents

Description

本発明は、通信リソースを確保した上でデータの送信を行うことができる通信ネットワークに接続された通信局、通信局の制御方法、通信システム、通信プログラム、記録媒体に関するものである。

近年、家庭内におけるＡＶ（Audio/Visual）機器のデジタル化が進んでいる。例えば、テレビにおいては、衛星放送に加えて地上波放送もデジタル化が計画されており、また、ＤＶＤ（Digital Versatile Disk）によるホームシアターなども広く普及している。さらに、通信インフラの整備によりインターネットにおけるブロードバンド化が進展しており、このインターネットを介して高画質の映像データをストリーミングで受信する、というような映像配信も実用化されている。

このように、家庭内に各種ＡＶ機器が備えられるようになると、これらのＡＶ機器をネットワークに接続し、相互に連携させて動作させる、という使用形態の需要が生じてくる。家庭内において、例えば複数の部屋にある各種ＡＶ機器をネットワークで接続する際には、例えばＩＥＥＥ１３９４などを利用した有線によるネットワークとともに、例えば無線ＬＡＮなどを利用した無線によるネットワークを利用するシステムを構築する必要性が高くなる。

以上のようなシステムにおいて、ＩＥＥＥ１３９４によるネットワークと、無線ＬＡＮによるネットワークとの双方において、帯域の保証された通信路を確立する方法として、次のような手法が提案されている（例えば特許文献１：日本国公開特許公報「特開２０００−２２４２１６号公報（公開日：２０００年８月１１日）」を参照）。まず、映像送信装置がＩＥＥＥ１３９４バスの帯域及びチャネルを取得した後、帯域通知用パケットが映像送信装置から無線ゲートウェイに対して送信される。同様にして、無線ゲートウェイが無線ＬＡＮの帯域を取得した後、帯域通知用パケットが無線ゲートウェイから映像受信装置に送信される。映像受信装置は、受信した帯域通知用パケットの内容を見てＡＣＫパケットを返送する。無線ゲートウェイは、ＡＣＫパケットを映像受信装置から受信すると、映像送信装置に対して同様にＡＣＫパケットを送信する。以上のシーケンスが行われることによって、映像送信装置から映像受信装置に到る通信経路における帯域が確保され、以降、映像信号の送受信が行われることになる。

このように、ネットワーク上では通信路を確立するときに、いずれかの通信局が、その通信路に用いられる帯域幅（通信リソース）を取得、変更、または開放する役割を担うことになる。

例えば、ＩＥＥＥ１３９４の通信方式において、ストリームの送受信局であるか、その他第三局であるかとは関係なく、コネクションを確立する局が、そのコネクションに用いられるネットワーク上の帯域を取得する役割を担っている。また、Ｂｌｕｅｔｏｏｔｈ（登録商標）の通信方式においては、いわゆるＳＣＯリンクは、マスターとスレーブとの間に確立されるが、リソースの取得およびリンクの確立は、マスター側とスレーブ側とのいずれからでも可能である。さらに、ＩＥＥＥ８０２．１５．３の通信方式においても、ダイレクトリンク（Ｄｅｖ−Ｄｅｖ通信）のリソース取得は、ＰＮＣ側とＤｅｖ側とのいずれからでも可能である。

なお、ＩＥＥＥ１３９４とは、高速のシリアル・インターフェース規格であり、その転送速度としては１００Ｍｂｐｓ、２００Ｍｂｐｓ、および４００Ｍｂｐｓの３種類が現状で存在している。音声や動画などの一定のタイミングで転送することが不可欠なデータを優先的に転送するアイソクロナス（等時）転送方式を持ち、マルチメディア・データ向けのインタフェースとしての性格を有している。

一方、ネットワーク上で帯域の保証された通信路を確立する他の方法として、ネットワークに接続された通信局のいずれかを中央管理局とし、この中央管理局がネットワーク上の帯域を統合的に管理する手法が知られている。

その一例として、ＩＥＥＥ Ｐ８０２．１１ｅ Ｄｒａｆｔ８．０（非特許文献２）におけるリソース取得の制約について説明する。各無線局は、無線リソース管理局であるＱＡＰ／ＨＣに対して無線リソース（帯域）の要求を行うが、この際に以下の制約が存在する。

（１）無線リソースの要求を行えるのは非ＱＡＰ／ＨＣのみである。すなわち、常にＱＡＰ／ＨＣが自分自身に対して無線リソースの要求を行うことはできない。

（２）ダイレクトリンクの場合は、その２局間で流すストリームの送信局のみがＱＡＰ／ＨＣに対して無線リソースの要求を行える。

ここで、ＩＥＥＥ Ｐ８０２．１１ｅのダイレクトリンクについて説明しておく。従来のＩＥＥＥ Ｐ８０２．１１系の無線ＬＡＮでは、ＡＰではない無線局同士が通信を行う際には、ＡＰを経由して通信することが必須であった。これに対して、ＩＥＥＥ Ｐ８０２．１１ｅにおいては、新たに、ダイレクトリンクという通信方式を定め、ＡＰではない無線局同士が直接通信を行うことを可能にした。このダイレクトリンクを行うためには、当該無線局の組およびＱＡＰ／ＨＣの三者がダイレクトリンクの使用に合意することが必要である。

なお、無線リソースを確保した通信を非ＱＡＰ／ＨＣである無線局間で行う場合には、ＱＡＰ／ＨＣ経由の通信では無線局―ＱＡＰ／ＨＣとＱＡＰ／ＨＣ−無線局の２本のストリームについてそれぞれリソース確保が必要であるのに対して、ダイレクトリンクを用いる場合には、無線局―無線局の１本のストリームについてのリソースを確保すれば通信が可能となる。

また、UPnP QoS Architecture 0.01（March 24 2003）（非特許文献１）のように、ネットワークをまたがって、ＱｏＳの設定を行うようなプロトコルが提案されているが、各々のネットワークでＱｏＳを設定するための仕組みについては、述べられていない。

なお、本願発明に関連する先行技術文献としては、IEEE 802.11e Draft8.0（非特許文献２）がある。

特開２０００−２２４２１６号公報（公開日：２０００年８月１１日）

UPnP QoS Architecture 0.01（March 24 2003） ＩＥＥＥ Ｐ８０２．１１ｅ Ｄｒａｆｔ８．０

しかし、従来の通信局では、通信ネットワークの構成によって、各通信局がストリーム送信、あるいは受信を行う際に、自局がリソース取得の役割を持つか否かが、自局に関する情報だけでは判定できず、不明となる場合が生じていた。

例えば、ＩＥＥＥ Ｐ８０２．１１ｅの通信方式において、自局が非ＱＡＰ／ＨＣである場合を考える。ダウンリンク（つまり、送信局がＱＡＰ／ＨＣ）のときには、自局が受信局であれば、リソース取得の役割を持つのに対して、ダイレクトリンク（つまり、送信局が同一ＢＢＳ内の非ＱＡＰ／ＨＣ）のときには、自局が受信局であっても、リソース取得の役割を持たない。したがって、このような場合には、自局が受信局であるという情報だけでは、自局がリソース取得の役割を持つか否かを判断できない。

本発明は、上記の問題点を解決するためになされたもので、その目的は、通信ネットワークにそれぞれ設けられている通信局同士で通信を行う際に、接続される通信ネットワークがどのような構成となっていても、的確に通信リソースの取得、変更、または開放の処理を実行し、スムーズな相互通信を可能とさせる通信局、通信局の制御方法、通信システム、通信プログラム、記録媒体を提供することにある。

上記の課題を解決するために、本発明に係る通信局は、一つ以上の通信ネットワークを介してデータの送受信を行う通信経路の一部もしくはすべての通信経路における通信リソースを確保した上でデータの送受信を行う通信局であって、上記通信ネットワークに関する事象および／または状態を検出する事象・状態検出部と、上記事象・状態検出部が検出した、上記通信ネットワークに関する事象および／または状態の内容に応じて、自局が通信リソースの取得、変更、または開放する処理を担当するか否かを判定する通信リソース処理担当判定部と、上記通信リソース処理担当判定部の判定結果に基づいて、上記通信ネットワークにおける通信リソースを取得、変更、または開放する通信リソース管理部とを備えた構成となっている。

また、本発明に係る通信局の制御方法は、一つ以上の通信ネットワークを介してデータの送受信を行う通信経路の一部もしくはすべての通信経路における通信リソースを確保した上でデータの送受信を行う通信局の制御方法であって、上記通信ネットワークに関する事象および／または状態を検出する事象・状態検出ステップと、上記検出した、上記通信ネットワークに関する事象および／または状態の内容に応じて、自局が通信リソースの取得、変更、または開放する処理を担当するか否かを判定する通信リソース処理担当判定ステップと、上記判定結果に基づいて、上記通信ネットワークにおける通信リソースを取得、変更、または開放する通信リソース管理ステップとを含む方法である。

上記の構成では、まず事象・状態検出部によって、通信ネットワークに関する事象および／または状態が検出される。この内容に応じて、通信リソース処理担当判定部によって、通信ネットワークにおいて、自局が通信リソースを取得、変更、または開放する処理を担当すべきか否かが判定され、これに基づいて、通信リソース管理部が、通信ネットワークの通信リソースを取得、変更、または開放する。なお、通信ネットワークは、複数であっても単体であってもよい。

すなわち、通信ネットワーク上のデータ送信局（通信局）が、通信ネットワーク上のデータ受信局に対してデータ送信を行う際、自局が通信リソースを取得、変更、または開放する処理を担当すべき場合には、データ送信局は、通信リソースを取得、変更、または開放する処理を行い、データ受信局との間の通信路を確立する一方、他局（データ受信局を含む）が通信リソースを取得、変更、または開放する処理を担当すべき場合には、他局（データ受信局を含む）によって通信路が確立されるまで待機する。

したがって、データ送信局のリソース取得等処理と、データ受信局のリソース取得等処理とが互いに衝突したり、逆に、データ送信局とデータ受信局との両者ともにリソース取得等処理を行わないことによって、通信路の確立が遅れたりすることがない。

それゆえ、通信ネットワークにそれぞれ設けられている通信局同士で通信を行う際に、各通信ネットワークの構成の複雑である場合や、接続される通信局の数が多い場合であっても、的確に通信リソースの取得、変更、または開放の処理を実行し、スムーズな相互通信を実現できるという効果を奏する。

また、本発明に係る通信局は、一つ以上の通信ネットワークを介してデータの送受信を行う通信経路の一部もしくはすべての通信経路における通信リソースを確保した上でデータの送受信を行う通信局であって、上記通信ネットワークに関する事象および／または状態を検出する事象・状態検出部と、上記事象・状態検出部が検出した、上記通信ネットワークに関する事象および／または状態の内容に応じて、どの局がある通信ネットワークにおける通信リソースの取得、変更、または開放する処理を担当するか否かを判定する通信リソース処理担当判定部と、上記通信リソース処理担当判定部の判定結果に基づいて、ある一つの通信ネットワークにおける通信リソースを取得、変更、または開放する通信リソース管理局に対して、通信リソースの取得、変更、または開放する処理を指示する通信リソース取得要求部とを備えた構成となっている。

また、本発明に係る通信局の制御方法は、一つ以上の通信ネットワークを介してデータの送受信を行う通信経路の一部もしくはすべての通信経路における通信リソースを確保した上でデータの送受信を行う通信局の制御方法であって、上記通信ネットワークに関する事象および／または状態を検出する事象・状態検出ステップと、上記検出した、上記通信ネットワークに関する事象および／または状態の内容に応じて、どの局がある通信ネットワークにおける通信リソースの取得、変更、または開放する処理を担当するか否かを判定する通信リソース処理担当判定ステップと、上記判定結果に基づいて、ある一つの通信ネットワークにおける通信リソースを取得、変更、または開放する通信リソース管理局に対して、通信リソースの取得、変更、または開放する処理を指示する通信リソース取得要求ステップとを含む方法である。

リソースを取得して送受信できるネットワークが複数接続されている場合、リソースをそれぞれのネットワークで取得をしようとすると、ストリームを送受信するために通るネットワーク全体でのリソースの管理ができなくなる。そこで、上記構成を備えた通信局（管理マネージャ）をネットワークのどこかに設け、その通信局がネットワークのリソース取得局に対して、リソース取得の指示を出す。

上記の構成によれば、通信ネットワーク上のデータ送信局が、通信ネットワーク上のデータ受信局に対してデータ送信を行う際、通信ネットワークにおける通信リソースを取得、変更、または開放する通信リソース管理局に対して、通信リソースの取得、変更、または開放する処理を管理マネージャが指示する。

したがって、データ送信局のリソース取得等処理と、データ受信局のリソース取得等処理とが互いに衝突したり、逆に、データ送信局とデータ受信局との両者ともにリソース取得等処理を行わないことによって、通信路の確立が遅れたりすることがない。

それゆえ、通信ネットワークにそれぞれ設けられている通信局同士で通信を行う際に、各通信ネットワークの構成の複雑である場合や、接続される通信局の数が多い場合であっても、的確に通信リソースの取得、変更、または開放の処理を実行し、スムーズな相互通信を実現できるという効果を奏する。

なお、本発明に係る通信局およびその制御方法では、上記の構成において、通信ネットワークは単一の構成であってもよいし、異なる種類の通信ネットワークを含む構成であってもよい。よって、利用者は、互いに異なる種類の複数の通信ネットワークを含んだより広域の通信ネットワークを容易に導入することが可能となるという効果を併せて奏する。

本発明のさらに他の目的、特徴、および優れた点は、以下に示す記載によって十分わかるであろう。また、本発明の利益は、添付図面を参照した次の説明で明白になるであろう。

本発明に係る通信局は、通信ネットワークに関する事象および／または状態を検出する事象・状態検出部と、上記事象・状態検出部が検出した、上記通信ネットワークに関する事象および／または状態の内容に応じて、自局が通信リソースの取得、変更、または開放する処理を担当するか否かを判定する通信リソース処理担当判定部と、上記通信リソース処理担当判定部の判定結果に基づいて、上記通信ネットワークにおける通信リソースを取得、変更、または開放する通信リソース管理部とを備えた構成となっている。

したがって、データ送信局のリソース取得等処理と、データ受信局のリソース取得等処理とが互いに衝突したり、逆に、データ送信局とデータ受信局との両者ともにリソース取得等処理を行わないことによって、通信路の確立が遅れたりすることがない。

それゆえ、通信ネットワークにそれぞれ設けられている通信局同士で通信を行う際に、各通信ネットワークの構成の複雑である場合や、接続される通信局の数が多い場合であっても、的確に通信リソースの取得、変更、または開放の処理を実行し、スムーズな相互通信を実現できるという効果を奏する。

本発明の一実施形態に係る通信ネットワークシステムの概略構成を示すブロック図である。 上記通信ネットワークシステムにおけるメッセージシーケンスを示す図である。 上記通信ネットワークシステムのうち、本発明に直接関わる部分の概略構成を示すブロック図である。 図３に示す通信ネットワークシステムが備える無線ＡＶ機器（通信局）の概略構成を示すブロック図である。 無線ＡＶ機器における処理の流れを示すフローチャートである。 上記通信ネットワークシステムにおけるメッセージシーケンスを示す図である。 本発明の他の実施形態に係る通信ネットワークシステムの概略構成を示すブロック図である。 本発明の他の実施形態に係る無線ＡＶ機器における処理の流れを示すフローチャートである。 本発明のさらに他の実施形態に係る無線ＡＶ機器の概略構成を示すブロック図である。 本発明のさらに他の実施形態に係る無線ＡＶ機器における処理の流れを示すフローチャートである。 本発明のさらに他の実施形態に係る無線ＡＶ機器の概略構成を示すブロック図である。 本発明のさらに他の実施形態に係る無線ＡＶ機器における処理の流れを示すフローチャートである。 本発明のさらに他の実施形態に係る通信ネットワークシステムの概略構成を示すブロック図である。 上記通信ネットワークシステムにおけるメッセージシーケンスを示す図である。 本発明のさらに他の実施形態に係る通信ネットワークシステムの概略構成を示すブロック図である。 上記通信ネットワークシステムにおけるメッセージシーケンスを示す図である。 本発明のさらに他の実施形態に係る通信ネットワークシステムにおけるメッセージシーケンスを示す図である。

（実施の形態１）
本発明の実施の一形態について図１ないし図６に基づいて説明すれば、以下のとおりである。

（１−１．ネットワーク構成）
図１は、本実施形態に係る通信ネットワークシステムの概略構成を示すブロック図である。同図に示すように、この通信ネットワークシステムは、コントローラ１、第１無線局（通信局）２、第２無線局（通信局）３、ターゲット４、第１ＩＲＭ（Isochronous Resource Manager）５、第２ＩＲＭ７、およびＱＡＰ／ＨＣ（通信リソース管理局）６を備えた構成となっている。

コントローラ１、第１無線局２、および第１ＩＲＭ５は、第１有線ネットワーク８によって接続されており、これらによって第１有線ネットワークシステムが形成されている。また、第２無線局３、ターゲット４、および第２ＩＲＭ７も、第２有線ネットワーク１０によって接続されており、これらによって第２有線ネットワークシステムが形成されている。本実施形態では、これら第１および第２有線ネットワークシステムが、ＩＥＥＥ１３９４準拠のネットワークシステムであるものとする。

また、第１無線局２、第２無線局３、およびＱＡＰ／ＨＣ６は、無線ネットワーク９によって接続されており、これらによって無線ネットワークシステムが形成されている。本実施形態では、この無線ネットワークシステムが、ＩＥＥＥ Ｐ８０２．１１ｅ Ｄｒａｆｔ８．０準拠のネットワークシステムであるものとする。

コントローラ１は、ユーザが上記通信ネットワークシステムを利用する際に、システム上の装置、この場合ではターゲット４の制御を行う際に用いられる装置である。本実施形態では、このコントローラ１として映像表示手段としてのテレビを想定している。この場合、テレビのリモコンなどによる入力手段によって、ユーザからの上記各機器に対する動作制御指示が行われることになる。

ターゲット４は、コントローラ１によって動作の制御が行われる機器である。本実施形態では、このターゲット４として、映像信号出力手段としてのＶＴＲ（Video Tape Recorder）を想定している。すなわち、本実施形態では、このＶＴＲから出力された映像信号が、第２有線ネットワーク１０、無線ネットワーク９、および第１有線ネットワーク８を介して、コントローラ１としてのテレビに送信され、テレビにおいて映像が表示される、というシステム動作が想定されている。

第１無線局２は、第１有線ネットワークシステムと無線ネットワークシステムとの間で信号の中継を行う装置であり、第１有線ネットワーク８および無線ネットワーク９に接続されている。また、第２無線局３は、無線ネットワークシステムと第２有線ネットワークシステムとの間で信号の中継を行う装置であり、無線ネットワーク９および第２有線ネットワーク１０に接続されている。

第１ＩＲＭ５は、第１有線ネットワークシステムにおける信号伝送の帯域・チャネル管理を行う装置である。また、第２ＩＲＭ７は、第２有線ネットワークシステムにおける信号伝送の帯域・チャネル管理を行う装置である。また、ＱＡＰ／ＨＣ６は、無線ネットワークシステムにおける送信権の管理を行う装置である。

（１−２．メッセージシーケンス）
次に、上記通信ネットワークシステムにおけるメッセージシーケンスについて図２を参照しながら以下に説明する。まず、ステップ１（以降、Ｓ１のように称する）において、コントローラ１は、ユーザからの操作などにより制御対象となるターゲット４を決定すると、自らの接続される第１有線ネットワークシステム上の帯域およびチャネルの取得要求を第１ＩＲＭ５に対して送信する。第１ＩＲＭ５は、要求された帯域およびチャネルを確保した上でリソース取得応答をコントローラ１に送信する（Ｓ２）。帯域およびチャネルの取得に成功したら、コントローラ１は第１無線局２に対してコネクション確立要求を送信する（Ｓ３）。第１無線局２は、指定されたコネクションが確立可能か否かを判断し、コネクション確立応答をコントローラ１に送信する（Ｓ４）。

第１無線局２は、コントローラ１からコネクション確立要求を受け付けると、自局は無線ネットワーク９上でストリーム受信を行うことと、自局および第２無線局３がＱＡＰ／ＨＣではないことを確認した後に、自局と第２無線局３との間のコネクション確立要求を第２無線局３へ送信する（Ｓ５）。第２無線局３は、第１無線局２からコネクション確立要求を受信すると、ＱＡＰ／ＨＣ６に対して帯域取得要求を送信する（Ｓ６）。

ＱＡＰ／ＨＣ６は、第２無線局３から要求された帯域を割り与えるとともに、帯域取得応答を第２無線局３へ送信する（Ｓ７）。帯域取得応答を受信した第２無線局３は、帯域取得結果も踏まえて第１無線局２との間にコネクションを確立することが可能か否かを判断し、判断結果を含むコネクション確立応答を第１無線局２へ送信する（Ｓ８）。

第２無線局３は、続けて、自らの接続される第２有線ネットワークシステム上の帯域およびチャネルの取得要求を第２ＩＲＭ７に対して送信する（Ｓ９）。第２ＩＲＭ７は、要求された帯域およびチャネルを確保した上でリソース取得応答を第２無線局３に送信する（Ｓ１０）。帯域およびチャネルの取得に成功したら、第２無線局３はターゲット４に対してコネクション確立要求を送信する（Ｓ１１）。ターゲット４は、指定されたコネクションが確立可能か否かを判断し、コネクション確立応答を第２無線局３に送信する（Ｓ１２）。

すなわち、上記従来のメッセージシーケンスにおいて、第１無線局２，第２無線局３，ＱＡＰ／ＨＣ６を接続する無線ネットワーク９に注目すれば、第２無線局３は、第１無線局２からのコネクション確立要求（Ｓ５）に応じて、帯域を管理するＱＡＰ／ＨＣ６に帯域取得要求を送信し（Ｓ６）、これによって、必要帯域を確保している。

なお、コントローラ１はターゲット４を帯域確保処理開始前に認識可能であり、その認識結果に基づいてコントローラ１からターゲット４までの通信経路は事前に定めることが可能となっているものとする。これを実現する方法としては様々な方法が考えられるが、以下に１つの例について説明する。

まず、第１無線局２が、第２無線局３が接続されている第２有線ネットワーク１０に接続されている機器の情報の取得要求を第２無線局３に対して送信し、この情報を取得する。その後、コントローラ１が第１無線局２にアクセスし、第２有線ネットワークシステムに接続されている機器の情報を得て、これら機器の中から接続を行いたい機器、すなわちターゲット４を選択する。第１無線局２は、コントローラ１によって選択されたターゲット４に関する情報、具体的には、ＣｏｎｆｉｇＲＯＭおよびＰＣＲ（Plug Control Register）の情報を第２無線局３を介してターゲット４から取得し、これに基づいて仮想的なターゲット４を作成する。以降は、コントローラ１が第１無線局２内に設けられた仮想的なターゲット４に対してアクセスすることによって通信が行われることになる。

（１−３．無線局の構成）
次に、第１無線局２または第２無線局３の構成について説明する。

本発明は上記メッセージシーケンスのうち第１無線局２および第２無線局３によるＳ５実行前の判定方法、すなわち自局がＱＡＰ／ＨＣ６に対して無線帯域要求を行うか否かを判定する方法、についての発明であり、第１有線ネットワーク８および第２有線ネットワーク１０との接続は必須ではない。説明の簡略化のため、以後は図３に示すように、ＱＡＰ／ＨＣ６、第１無線局２、第２無線局３からなる無線ネットワーク９における動作を例にとって説明する。

第１無線局２、第２無線局３は、無線ネットワーク９を介して接続されている。また、ＱＡＰ／ＨＣ６は、無線ネットワーク９における送信権の管理を行う装置である。

なお、第１無線局２または第２無線局３は、構成としてはほぼ同様のものであるので、ここでは、両者を無線ＡＶ機器（通信局）４０と総称して説明する。無線ＡＶ機器４０は無線通信機能を有するＡＶ機器であって、放送などのストリームデータを無線通信することが可能である。以下の説明では、特に、第１無線局２としての無線ＡＶ機器４０を想定しているが、基本的には第２無線局３にも同様に適用されるものである。

図４は、無線ＡＶ機器４０の概略構成を示すブロック図である。同図に示すように、無線ＡＶ機器４０は、アプリケーション４２、無線パケット処理部２５、無線ＰＨＹ２６、無線リソース管理部３０、無線ネットワーク管理部３１およびアドレス判定部４１を備えた構成となっている。

アプリケーション４２は、通信相手局の決定、通信帯域の予約要求、ストリームの送受信開始などの指示を行うものであり、情報をユーザに提示する機能とユーザからの入力を受け付ける機能を有する。

無線ＰＨＹ２６は、無線ネットワーク９に接続されており、この無線ネットワーク経由でパケットや制御信号を受信あるいは送信する処理を行う物理層である。無線パケット処理部２５は、無線ＰＨＹ２６において受信されたパケットの種類を判定し、その種類に応じた処理を行う、あるいは、アプリケーション４２や無線ネットワーク管理部３１などからの要求によってパケットを作成し、これを無線ＰＨＹ２６へ渡す処理を行うものである。

無線リソース管理部３０は、無線ＡＶ機器４０が取得している無線リソースを管理するものである。無線ネットワーク管理部３１は、無線ネットワーク中でどの局が帯域管理を行うＱＡＰ／ＨＣであるかを記憶するものである。

アドレス判定部４１は、アプリケーション４２から得られる通信相手局のＭＡＣアドレスと、無線ネットワーク管理部３１から得られるＱＡＰ／ＨＣのＭＡＣアドレスとを比較し、同一か否かを判定する処理を行うものである。

（１−４．無線局における処理の流れ）
次に、無線ＡＶ機器４０における処理の流れについて、図５に示すフローチャートを参照しながら説明する。ここで、無線ＡＶ機器４０はテレビのようにストリームの受信のみを行う場合について説明する。

まず、無線リソース管理部３０は、無線ネットワーク管理部３１から自局が属しているＱＡＰ／ＨＣ６のＭＡＣアドレスを取得する（Ｓ１１１）。具体的には、無線リソース管理部３０は、自局がＱＡＰ／ＨＣ６にアソシエートする際に用いるＭＡＣアドレスを検出し、検出したＭＡＣアドレスを無線ネットワーク管理部３１に記憶させる。なお、アソシエートの対象となるＱＡＰ／ＨＣ６のＭＡＣアドレスは、ＱＡＰ／ＨＣ６がブロードキャストするビーコンに含まれている。

次に、アプリケーション４２は、ストリームの送信局となる通信相手局を決定する（Ｓ１１２）。具体的処理は、次のように行う。まず、アプリケーション４２が、無線ネットワーク９に接続された他の無線ＡＶ機器の機器情報を、無線ＰＨＹ２６および無線パケット処理部２５を経由して入手する。その後、アプリケーション４２は、入手した他の無線ＡＶ機器の機器情報をユーザに提示する。これに応じて、ユーザがアプリケーション４２の機能により、通信相手局となる他の無線ＡＶ機器を選択する。なお、ユーザが通信相手局を決定したら、アプリケーション４２は、当該通信相手局のＭＡＣアドレスを記憶しておく。

通信相手局を決定すれば、アプリケーション４２は、通信相手局上のアプリケーションと通信を行い、通信対象となるストリームを決定し、そのストリームの属性（ストリームの通信に必要な帯域幅など）を入手する。その後、アプリケーション４２は、無線リソース取得のトリガー（リソース取得トリガー）の受信を待つ。リソース取得トリガーとなる事象としては、ユーザがアプリケーション４２に対して「通信開始」ボタンを押すことなどが相当する。

アプリケーション４２は、リソース取得トリガーを受信すると（Ｓ１１３）、アドレス判定部４１の機能により、無線ネットワーク管理部３１が記憶するＱＡＰ／ＨＣ６のＭＡＣアドレスと、自ら記憶する通信相手局のＭＡＣアドレスとを比較して、無線ネットワークにおける相手局となる無線局がＱＡＰ／ＨＣ６であるか否かを判定する（Ｓ１１４）。

Ｓ１１４における比較の結果、無線ネットワーク管理部３１が記憶するＱＡＰ／ＨＣ６のＭＡＣアドレスと、自ら記憶する通信相手局のＭＡＣアドレスとが等しいなら、通信相手局はＱＡＰ／ＨＣ６であると認識できるため、アプリケーション４２は、無線リソース管理部３０の機能によって、当該無線ストリームにＴＳＩＤを割り与えた後に無線帯域確保要求を作成し、これを無線パケット処理部２５、無線ＰＨＹ２６経由で相手局であるＱＡＰ／ＨＣ６宛てに送信することによって、自局から無線リソースの取得を行う（Ｓ１１５）。

一方、Ｓ１１４における比較の結果、無線ネットワーク管理部３１が記憶するＱＡＰ／ＨＣ６のＭＡＣアドレスと、自ら記憶する通信相手局のＭＡＣアドレスとが異なっているなら、通信相手局はＱＡＰ／ＨＣではないと認識されるため、無線ＡＶ機器４０は、無線リソース（無線帯域）の取得を行わず、他局による無線リソースの確保を待機する（Ｓ１１６）。例えば、アプリケーション４２は、トリガーコマンドを作成して、通信相手局に送信し、このトリガーコマンドを受信した通信相手局がリソースの取得を行うのを待機する。

これら処理によって無線リソースの帯域確保が成功した場合、アプリケーション４２は、適宜、通信相手局への指示コマンド（例えばＰｌａｙコマンド）を作成し、無線パケット処理部２５および無線ＰＨＹ２６を経由して、通信相手局に各種の指示を行う。

（１−５．本実施形態の変更例）
以上、本発明の適用範囲は、上記の説明に限られるものではなく、本実施形態に、例えば、次のような変更を施してもよい。

（１）ＩＥＥＥ Ｐ８０２．１１ｅに準拠した無線ネットワーク９の代わりに、通信リソースを確保する他の無線ネットワークを用いてもよいし、有線ネットワークを用いてもよい。

（２）第１無線局２および第２無線局３の一例として、無線ＡＶ機器４０を説明したが、通信構成が同等であれば、無線ＡＶ機器４０の代わりに、電話など、他の種類の機器を用いてもよい。

（３）無線ＡＶ機器４０をストリームの受信局として用いるものと説明したが、同様の構成によって、無線ＡＶ機器４０をストリームの送信局として用いる場合にも、本発明を適用することができる。

（４）ＱＡＰ／ＨＣと非ＱＡＰ／ＨＣを識別する手段についても、受信ビーコンのＭＡＣアドレスに限られるものではなく、より上位層のアドレス（例えばネットワーク層のアドレス）などを用いてもよい。例えば、ネットワーク層のアドレスが特定の値であるか否かに基づいて、ＱＡＰ／ＨＣと非ＱＡＰ／ＨＣとを識別してもよい。

（５）Ｓ１１２において、通信相手局の決定はユーザの選択に基づくものとして説明したが、通信相手局の決定手法はこれに限られるものではなく、アプリケーション４２が、あらかじめ保有する通信相手局情報に基づいて、自動的に選択・決定してもよい。

（６）前述の説明では、アプリケーション４２は、通信相手局上のアプリケーションと通信を行い、通信対象となるストリームを決定し、そのストリームの属性（ストリームの通信に必要な帯域幅など）を入手するものとしたが、これに限られるものではない。例えば、アプリケーション４２が、あらかじめ通信相手局、通信対象ストリームおよびストリーム属性などの各種情報を保有しておき、この保有情報に基づいて、通信対象ストリームを決定したり、通信対象ストリームのストリーム属性を無線リソース管理部３０に通知したりしてもよい。

（７）Ｓ１１３では、ユーザからのリソース取得トリガー（ユーザがアプリケーション４２に対して「送信開始」ボタンを押すことなど）が明示的に存在する例について記したが、リソース取得トリガーをユーザ以外から得る構成であってもよい。例えば、無線ＡＶ機器４０が、常にストリームを出力可能としているチューナなどであれば、アプリケーション４２は、無線ＡＶ機器４０の内部で得る情報や、コントローラ１あるいは他の機器、無線局からの命令（特に送受信開始命令）や、他ネットワークからのストリームの受信の検出などをリソース取得トリガーとして用いてもよい。

（８）Ｓ１１６においては、アプリケーション４２は、トリガーに対応する通信相手局へのコマンドを作成し、このコマンドを上記通信相手局へ送信して、待機するものとして説明したが、単に、待機するのではなく、通信相手局に対して、トリガーに対応するコマンドとは別の無線リソースの確保を要求するコマンドを明示的に発行することにより、通信相手局に無線リソースの確保を実行させてもよい。同様に、アプリケーション４２は、下位層のネットワークの制約を満たす第三の局に無線リソースの確保を要求するコマンドを発行して、リソースの確保を実行させてもよい。

（９）また、無線ＡＶ機器４０は、自局がリソース取得を行えない場合、他局（送受信相手局または第三局）にリソース取得、変更あるいは開放を要求してもよい。この場合、他局のうち、いずれの通信局にリソース取得、変更あるいは開放を依頼するかは下位層の仕様（例えば、ＩＥＥＥ Ｐ８０２．１１ｅの仕様）に依存する。この構成によれば、上位層が下位層の制約を意識せずにリソース取得要求を発行できる。また、常に、送信局（あるいは受信局）からリソース取得要求を発行できるので、アプリケーション４２の構成を簡潔なものとすることができる。

ここで、上記変更例（９）について詳細に説明する。

図６は、自局がトポロジの関係でリソースの取得要求をできない場合に、他局に対して、リソースを取得してもらうときのシーケンスの一例を示す。なお、トポロジは図３、他局のブロック図は、図１１と同等である。

第２無線局３では、Ｓ２１でアプリケーション４２がリソースを取得するための命令を受信したが、通信経路判定部４３にて、自局が帯域を取得できないことが分かったので、そのストリームのリソースを取得できる第１無線局２に対して、Ｓ２２で、リソース取得をするためのフレームを送信している。このフレームの内容は、実際に、どのようなリソースを確保するのかを示す情報が含まれる。例えば、ＩＥＥＥ Ｐ８０２．１１ｅのネットワークでは、ＴＳＰＥＣと呼ばれるストリームの情報を示したものや、ＥＤＣＡおよびＨＣＣＡといったストリームの送信方法、どのようなＡｃｋのタイプを使用するかなどが含まれる。

リソース取得要求フレームを受信した第１無線局２は、Ｓ２２で、第２無線局３から受信したリソース取得要求フレームに入っている情報から、帯域確保要求フレームを作成し、Ｓ２３で、ＱＡＰ／ＨＣ６に対して、送信する。このときに、第１無線局２は、第２無線局３から受信した情報以外に、ＱＡＰ／ＨＣ６に対して要求する情報を作成してもよい。例えば、そのストリームを識別するための識別子などである。

ＱＡＰ／ＨＣ６は、第１無線局２から帯域確保要求フレームを受信した後、そのフレームに入っている情報から必要な帯域を計算し、その帯域が割り当てることが可能であるかどうかを判断し、結果を、Ｓ２４で、帯域確保返答フレームを送信する。

第１無線局２は、Ｓ２５で、Ｓ２４で受信した返答フレームの結果を第２無線局３に対して送信を行い、結果を通知する。また、Ｓ２４で返答フレームを受信した後、さらに、必要な設定を行ってもよい。

また、第１無線局２は、Ｓ２２で第２無線局３からリソース取得要求フレームを受信したときに、もうすでに、全く同じストリームを定義していたら、新たに取り直す必要はない。また、すでにその帯域の取得ができていることを、第２無線局３に対して、Ｓ２５のリソース返答フレームで返信してもよい。そのときは、リソースが取得できているというエラーで返してもよいし、リソースが取得完了したということを返してもよい。すなわち、本変更例の構成によれは、送信側、受信側関係なく、双方で、帯域取得のための命令をアプリケーションが出すことができる。

また、上記のＳ２３、およびＳ２４のフレームは、ＭＡＣ層におけるフレームであるが、Ｓ２２およびＳ２５で送信するフレームはどのような層のフレームでもよい。つまり、ＭＡＣ層で作成されたフレームでもよいし、それ以外の層で作成されたフレームでもよい。

ここで、帯域を取得するためには、必ず、その帯域を使用する送信局（DirectlinkとUplinkの場合）もしくは受信局（Downlinkの場合）が申請するというルールになっている。すなわち、Uplink（ＳＴＡ→ＱＡＰ）の場合、ＳＴＡ（ストリーム送信局）が帯域を取得する。Directlink（ＳＴＡ→ＳＴＡ）の場合、ＳＴＡ（ストリーム送信局）が帯域を取得する。Downlink（ＱＡＰ→ＳＴＡ）の場合、ＳＴＡ（ストリーム受信局）が帯域を取得する。

そして、自局が上記の場合のいずれにも当てはまっていない（リソース取得を行えない）と判断したとき、他局（相手局）に対して通知する。すなわち、自局がリソース取得を行えないと判定した場合には、上記通信ネットワーク上の他局に対して、リソース取得、変更あるいは開放を要求する。

そして、上記の通知を受信した局は、リソース取得を行えないと判定した相手局が、リソース取得、変更あるいは開放を要求してきた場合、通信ネットワーク上のリソース取得、変更あるいは開放を行う。

（１０）前述の説明では、無線帯域の取得に関する処理について説明しているが、帯域の変更、開放も同様にして実現できる。

（１１）前述の説明では、ＱＡＰ／ＨＣ６がリソースを管理する場合に、ＱＡＰ／ＨＣ６からリソースを取得する例について記したが、無線ＡＶ機器４０は、自局の管理するリソースを取得、変更、開放してもよい。例えば、無線リソース管理部３０は、自局と相手局との間で利用されているＴＳＩＤ（ＩＥＥＥ Ｐ８０２．１１ｅに準拠したＭＡＣ層でストリームを識別するためのＩＤ）を管理しており、無線帯域の取得を行う局が、帯域割り当てを要求する無線ストリームに対して新規にＴＳＩＤを割り与える。すなわち、ＴＳＩＤの値を決定するのはＱＡＰ／ＨＣ６に対して無線リソースを要求する局に相当する無線ＡＶ機器４０（第１無線局２あるいは第２無線局３）であるから、本実施形態において、無線ネットワーク９に接続された無線ＡＶ機器４０（第１無線局２あるいは第２無線局３）のうち、いずれの無線局がＴＳＩＤを決定すべきかを選択・決定する構成を採用してもよい。

なお、これら本実施形態の変更例は、以降の他の実施の形態にも同様に適用することが可能である。

（実施の形態２）
本発明の実施の一形態について図７、図８に基づいて説明すれば、以下のとおりである。なお、前記した実施の形態１で説明した構成と同様の機能を有する構成には、同一の符号を付記し、その説明を省略する。

（２−１．ネットワーク構成）
図７は、本実施形態に関わる通信ネットワークシステムの概略構成を示すブロック図である。同図に示すように、本実施形態に係るシステムは、図３に示す構成に加えて、有線ネットワーク１３と通信局１４とが設けられている。有線ネットワーク１３は、ＱＡＰ／ＨＣ６と後述の通信局１４とを接続するネットワークであり、ここではＥｔｈｅｒｎｅｔ（登録商標）のみから構成されるものを想定する。通信局１４は、有線ネットワーク１３、ＱＡＰ／ＨＣ６、無線ネットワーク９経由で第１無線局２と通信する。この通信には、下位層が無線か有線かを問わず、ＩＰ（Internet Protocol）を用いるものとする。

その他構成については図１に示す構成と同様であるので、ここではそれらの説明を省略する。

実施の形態１では、無線ネットワークにおいて、無線局がどの局がリソース管理局かを判定して、自局がリソースの取得を行うか否かを判定する場合の例を示した。本実施形態では、無線ネットワークと有線ネットワークが接続されている構成において、データの送受信を行う相手局が、自局と共通の通信リソースを管理する単位内（同一無線ネットワーク上）に存在するか否かを判定して、自局がリソースの取得を行うか否かを判定する場合の例を示す。

（２−２．無線局の構成）
本実施形態に係る無線ＡＶ機器４０（第１無線局２または第２無線局３）の概略構成を示すブロックは、図４に示したものと同じである。ただし、本実施形態に係る無線ＡＶ機器４０では、図４における、無線ネットワーク管理部３１およびアドレス判定部４１の機能が実施の形態１と異なっている。

本実施形態において、無線ネットワーク管理部３１は、実施の形態１での機能に加えて、無線ネットワーク９内の機器に割り与えられるアドレスの情報を記憶する。具体的には、ある無線局が無線ネットワーク９に加入する際に割り当てられるＩＰアドレスの値の範囲についての情報を保有している。

また、本実施形態において、アドレス判定部４１は、実施の形態１での機能に加えて、アプリケーション４２から得られる通信相手局のアドレスと、無線ネットワーク管理部３１の保有する無線ネットワーク９内の機器に割り当てられるＩＰアドレスの情報とを比較し、通信相手局が無線ネットワーク９内にいるものか否かを判定する処理を行う。

その他の構成については図３に示す構成と同様であるので、ここではそれらの説明を省略する。

（２−３．無線局における処理の流れ）
次に、無線ＡＶ機器４０における処理の流れについて、図８に示すフローチャートを参照しながら説明する。

まず、アプリケーション４２は、ストリームの送信局となる通信相手局を決定する（Ｓ１２１）。

具体的処理は、次のように行う。まず、アプリケーション４２が、無線ネットワーク９に接続された他の無線ＡＶ機器の機器情報を、無線ＰＨＹ２６および無線パケット処理部２５を経由して入手する。その後、アプリケーション４２は、入手した他の無線ＡＶ機器の機器情報をユーザに提示する。これに応じて、ユーザがアプリケーション４２の機能により、通信相手局となる他の無線ＡＶ機器を選択する。なお、ユーザが通信相手局を決定したら、アプリケーション４２は、当該通信相手局（ここでは、通信局１４）のＩＰアドレスを記憶しておく。

通信相手局を決定すれば、アプリケーション４２は、通信相手局上のアプリケーションと通信を行い、通信対象となるストリームを決定し、そのストリームの属性（ストリームの通信に必要な帯域幅など）を入手する。その後、アプリケーション４２は、無線リソース取得のトリガー（リソース取得トリガー）の受信を待つ。リソース取得トリガーとなる事象としては、ユーザがアプリケーション４２に対して「通信開始」ボタンを押すことなどが相当する。

アプリケーション４２は、リソース取得トリガーを受信すると（Ｓ１２２）、アドレス判定部４１の機能により、無線ネットワーク管理部３１が記憶する、無線ネットワーク内の機器に割り与えられるＩＰアドレスの情報と、自ら記憶する通信局１４のＩＰアドレスとを比較して、通信ネットワークにおいて、データの送受信を行う相手局が、自局と共通の通信リソースを管理する単位内に存在するか否かを判定する（Ｓ１２３）。

Ｓ１２３における比較の結果、図７のネットワーク構成であれば、通信局１４のＩＰアドレスは無線ネットワーク９の外部のもの（Ｓ１２３においてＹｅｓ）と認識されるため、アプリケーション４２は、無線リソース管理部３０の機能によって、当該無線ストリームにＴＳＩＤを割り与えた後に無線帯域確保要求を作成し、これを無線パケット処理部２５、無線ＰＨＹ２６経由で相手局であるＱＡＰ／ＨＣ６宛てに送信することによって、自局から無線リソースの取得を行う（Ｓ１２４）。

一方、Ｓ１２３における比較の結果、仮に、そのＩＰアドレスは無線ネットワーク９の内部のものであれば、通信局１４が無線ネットワーク９に接続されているものと認識できるため（Ｓ１２３においてＮｏ）、アプリケーション４２は、実施の形態１のＳ２６〜Ｓ３０およびＳ１１１〜Ｓ１１４（図５参照）の各処理を実行することによって、無線ネットワーク管理部３１が記憶するＱＡＰ／ＨＣ６のＭＡＣアドレスと、自ら記憶する通信相手局のＭＡＣアドレスとを比較して、無線ネットワークにおける相手局となる無線局がＱＡＰ／ＨＣ６であるか否かを判定し、自局から無線リソースの取得を行うか否かを決定する。

なお、無線リソースを確保した後の処理については、実施の形態１と同様であるので、ここでは説明を省略する。

以上、無線ＡＶ機器４０を第１無線局２であるものとして処理の流れを説明したが、第２無線局３についても、基本的に同様である。

以上のように、本実施形態において、無線ＡＶ機器４０（第１無線局２または第２無線局３）は、無線ネットワーク管理部３１によって、無線ネットワーク９に関する事象および／または状態として、通信相手局のＩＰアドレスを検出し、アプリケーション４２およびアドレス判定部４１は、上記検出結果に応じて、無線ネットワーク管理部３１において、自局が通信リソースを取得する処理を担当すべきか否かを判定し、この判定結果に基づいて、処理を実行するものである。

また、アプリケーション４２およびアドレス判定部４１は、無線ネットワーク９および有線ネットワーク１３からなる通信ネットワークにおいて、データの送受信を行う相手局が、自局と共通の通信リソースを管理する単位内に存在するか否かを判定する接続ネットワーク判定部としての機能を有しており、この判定結果に基づいて、無線ＡＶ機器４０（第１無線局２または第２無線局３）は、自局が通信リソースの取得する処理を担当するか否かを判定している。

なお、本実施形態では、アプリケーション４２およびアドレス判定部４１は、通信局１４が、自局と共通の通信リソースを管理する単位内に存在するか否かを、無線ネットワーク９で割り当てられるＩＰアドレスの値の範囲に基づいて判定したが、他の情報、例えば有線ネットワーク１３上のＩＰアドレスの範囲や、無線区間のみに有効なプロトコルを用いて収集した情報に基づいて判定してもよいし、通信局１４やその他の局に問い合わせて判定してもよい。

（実施の形態３）
本発明の実施の一形態について図３、図９、図１０に基づいて説明すれば、以下のとおりである。なお、前記した実施の形態１で説明した構成と同様の機能を有する構成には、同一の符号を付記し、その説明を省略する。

（３−１．ネットワーク構成）
本実施形態に関わる通信ネットワークシステムの概略構成は図３に示す構成と同様であるので、ここではそれらの説明を省略する。

（３−２．無線局の構成）
図９は、本実施形態に係る無線ＡＶ機器４０（第１無線局２または第２無線局３）の概略構成を示すブロック図である。図９に示す構成では、無線ネットワーク管理部３１とアドレス判定部４１とが存在しない点のみが、図３に示した構成と異なっている。

本実施形態では、無線ネットワーク９の内部において、自局がストリームの送信局か受信局かを判定して、自局がリソースの取得を行うか否かを判定する場合の例を示す。

（３−３．無線局における処理の流れ）
次に、無線ＡＶ機器４０における処理の流れについて、図１０に示すフローチャートを参照しながら説明する。

ここで、無線ＡＶ機器４０は、第２無線局３であって、ＤＶＨＳのようにストリームの送信（再生時）、あるいは受信（録画時）を行う無線局であるものとする。

また、ＱＡＰ／ＨＣ６はいわゆるアクセスポイントであって、ＡＶ機器としての機能を持たないものとし、第２無線局３の通信相手局は第１無線局２であって、第１無線局２は、デジタル放送のＳＴＢのように、ストリームの送信（放送受信時）あるいは受信（ＤＶＨＳから送信されるデータの再生時）を行う無線局であるものとする。

まず、アプリケーション４２は、ストリームの送信局となる通信相手局を決定する（Ｓ１３１）。

具体的処理は、次のように行う。まず、アプリケーション４２が、無線ネットワーク９に接続された他の無線ＡＶ機器の機器情報を、無線ＰＨＹ２６および無線パケット処理部２５を経由して入手する。その後、アプリケーション４２は、入手した他の無線ＡＶ機器の機器情報をユーザに提示する。これに応じて、ユーザがアプリケーション４２の機能により、通信相手局となる他の無線ＡＶ機器を選択する。なお、ユーザが通信相手局を決定したら、アプリケーション４２は、当該通信相手局（ここでは、第１無線局２）のアドレスを記憶しておく。

通信相手局を決定すれば、アプリケーション４２は、通信相手局上のアプリケーションと通信を行い、通信対象となるストリームを決定し、そのストリームの属性（ストリームの通信に必要な帯域幅など）を入手する。ここでは、第１無線局２と第２無線局３はともに非ＱＡＰ／ＨＣであり、この２つの無線局間で直接ストリームを送受信するために、ＩＥＥＥ Ｐ８０２．１１ｅにおけるダイレクトリンクの設定を行うものとする。すなわち、通信相手局に対して、ＱＡＰ／ＨＣ６経由でダイレクトリンクの確立要求を無線ネットワーク管理部３１、無線パケット処理部２５、無線ＰＨＹ２６経由で実行する。これが成功すると、以後の通信は当該局間で直接行われる。

また、アプリケーション４２は、自局がストリームを送信するか受信するかも決定する（Ｓ１３２）。具体的には、アプリケーション４２は、例えばＤＶＨＳの動作モードが「チューナ出力」になっていることの検出や、動作中のＤＶＨＳを停止したなどの無線ＡＶ機器４０上のローカルな状態あるいは操作の他、送受信局間で行う通信内容に基づいて、自局がストリームを送信するか受信するかを決定する。ここでは、無線ＡＶ機器４０（第２無線局３）はストリームを送信するものとする。

その後、アプリケーション４２は、無線リソース取得のトリガー（リソース取得トリガー）の受信を待つ。リソース取得トリガーとなる事象としては、ユーザがアプリケーション４２に対して「通信開始」ボタンを押すことなどが相当する。

アプリケーション４２は、リソース取得トリガーを受信すると（Ｓ１３３）、先に定めたストリームの方向は、自局が送信側であるか否かを判定する（Ｓ１３４）。

Ｓ１３４における判定の結果、本実施形態では、第２無線局３から第１無線局２に送信する方向のストリームであるので、第２無線局３のアプリケーション４２は、無線リソース管理部３０の機能によって、当該無線ストリームにＴＳＩＤを割り与えた後に無線帯域確保要求を作成し、これを無線パケット処理部２５、無線ＰＨＹ２６経由で相手局である第１無線局２宛てに送信することによって、自局から無線リソースの取得を行う（Ｓ１３５）。

一方、Ｓ１３４における比較の結果、仮に、ストリームの方向は、自局が送信側でなければ、送信局は第１無線局２であるものと認識できるので、第２無線局３のアプリケーション４２は、無線リソース（無線帯域）の取得を行わず、通信相手局（第１無線局２）による無線リソースの確保を待機する（Ｓ１３６）。

なお、無線リソースを確保した後の処理については、実施の形態１と同様であるので、ここでは説明を省略する。

以上、無線ＡＶ機器４０を第２無線局３であるものとして処理の流れを説明したが、第１無線局２についても、基本的に同様である。

以上のように、本実施形態の無線ＡＶ機器４０（第１無線局２または第２無線局３）において、アプリケーション４２は、無線ネットワーク９に関する事象および／または状態として自局がストリームを送信するか受信するかを判定するストリーム送受信判定部として機能し、さらに、この判定結果に基づいて、自局が通信リソースの取得、変更、または開放する処理を実行するものである。

（実施の形態４）
本発明の実施の一形態について図１、図１１、図１２に基づいて説明すれば、以下のとおりである。なお、前記した実施の形態１で説明した構成と同様の機能を有する構成には、同一の符号を付記し、その説明を省略する。

（４−１．ネットワーク構成）
本実施形態に関わる通信ネットワークシステムの概略構成は図１に示す構成と同様であるので、ここではそれらの説明を省略する。

（４−２．無線局の構成）
図１１は、本実施形態に係る無線ＡＶ機器４０（第１無線局２または第２無線局３）の概略構成を示すブロック図である。図１１に示す構成では、無線ネットワーク管理部３１の機能、アドレス判定部４１の代わりに通信経路判定部４３が設けられている点のみが、図４に示した構成と異なっている。

無線ネットワーク管理部３１は、実施の形態１と同様、ＱＡＰ／ＨＣ６のアドレスを記憶するとともに、非ＱＡＰ／ＨＣ局間の通信がＱＡＰ／ＨＣ６を介さず直接行われる場合に、各無線局の情報を記憶する。具体的には、ＱＡＰ／ＨＣ６のアドレスに加えて、自局との間でダイレクトリンクプロトコルによるダイレクトリンク設定が成功した無線局のアドレスを保有している。

通信経路判定部４３は、アプリケーション４２から得られる通信相手局のアドレスと、無線ネットワーク管理部３１から得られるダイレクトリンク設定中の無線局のアドレスとを比較し、通信相手局がダイレクトリンクで通信されるものか否かを判定する処理を実行する。

本実施形態では、無線ネットワーク９の内部において、非ＱＡＰ／ＨＣの無線局間でストリームの通信を行う際に、当該ストリームをＱＡＰ／ＨＣ経由で送信するか直接送信するかを判定して、自局がリソースの取得を行うか否かを判定する場合の例を示す。

（４−３．無線局における処理の流れ）
次に、無線ＡＶ機器４０における処理の流れについて、図１２に示すフローチャートを参照しながら説明する。ここで、無線ＡＶ機器４０は、第２無線局３であって、テレビのようにストリームの受信のみを行うものとする。

まず、アプリケーション４２は、ストリームの送信局となる通信相手局を決定する（Ｓ１４１）。

具体的処理は、次のように行う。まず、アプリケーション４２が、無線ネットワーク９に接続された他の無線ＡＶ機器の機器情報を、無線ＰＨＹ２６および無線パケット処理部２５を経由して入手する。その後、アプリケーション４２は、入手した他の無線ＡＶ機器の機器情報をユーザに提示する。これに応じて、ユーザがアプリケーション４２の機能により、通信相手局となる他の無線ＡＶ機器を選択する。なお、ユーザが通信相手局を決定したら、アプリケーション４２は、当該通信相手局（ここでは、第１無線局２）のアドレスを記憶しておく。

通信相手局を決定すれば、アプリケーション４２は、通信相手局上のアプリケーションと通信を行い、通信対象となるストリームを決定し、そのストリームの属性（ストリームの通信に必要な帯域幅など）を入手する。その後、アプリケーション４２は、無線リソース取得のトリガー（リソース取得トリガー）の受信を待つ。リソース取得トリガーとなる事象としては、ユーザがアプリケーション４２に対して「通信開始」ボタンを押すことなどが相当する。

次に、アプリケーション４２は、通信相手局と通信するための通信経路を設定する（Ｓ１４２）。ここで、第１無線局２と第２無線局３はともに非ＱＡＰ／ＨＣであり、必要に応じて、この２つの無線局間で直接ストリームを送受信するために、ＩＥＥＥ Ｐ８０２．１１ｅにおけるダイレクトリンクの設定を行う。すなわち、無線ネットワーク管理部３１の有するＱＡＰ／ＨＣ６のアドレスと通信相手局のアドレスを比較し、当該通信相手局がＱＡＰ／ＨＣ６でない場合は、必要に応じて、ダイレクトリンクの確立要求を無線ネットワーク管理部３１、無線パケット処理部２５、無線ＰＨＹ２６経由で実行する。これが成功すると、以後の通信は当該局間で直接行われる。

その後、アプリケーション４２は、無線リソース取得のトリガー（リソース取得トリガー）の受信を待つ。リソース取得トリガーとなる事象としては、ユーザがアプリケーション４２に対して「通信開始」ボタンを押すことなどが相当する。

アプリケーション４２は、リソース取得トリガーを受信すると、通信経路判定部４３の機能によって、通信相手局との間の通信経路として、ダイレクトリンクが確立しているか否か（ＱＡＰ／ＨＣ６を経由しないでよいか否か）を判定する（Ｓ１４４）。

Ｓ１４４における判定の結果、通信相手局との間の通信経路として、ダイレクトリンクが確立していなければ、アプリケーション４２は、無線リソース管理部３０の機能によって、当該無線ストリームにＴＳＩＤを割り与えた後に無線帯域確保要求を作成し、これを無線パケット処理部２５、無線ＰＨＹ２６経由でＱＡＰ／ＨＣ６宛てに送信することによって、自局から自局とＱＡＰ／ＨＣ６との間の無線リソースの取得を行う（Ｓ１４５）。

一方、Ｓ１４４における比較の結果、通信相手局との間の通信経路として、ダイレクトリンクが確立していれば、ストリームの送信局である通信相手局がリソースの取得を行うため、アプリケーション４２は、無線リソースの取得を行わず、通信相手局（第１無線局２）による無線リソースの確保を待機する（Ｓ１４６）。

なお、無線リソースを確保した後の処理については、実施の形態１と同様であるので、ここでは説明を省略する。

以上のように、本実施形態の無線ＡＶ機器４０（第１無線局２または第２無線局３）において、アプリケーション４２および通信経路判定部４３は、無線ネットワーク９に関する事象および／または状態として、ストリームの通信経路を判定する通信経路判定部として機能し、さらに、この判定結果に基づいて、自局が通信リソースの取得、変更、または開放する処理を実行するものである。

（実施の形態５）
本発明の実施の一形態について図１３、図１４に基づいて説明すれば、以下のとおりである。なお、前記した実施の形態１〜４で説明した構成と同様の機能を有する構成には、同一の符号を付記し、その説明を省略する。

上述した実施形態では、図３のように無線ネットワークが一つだけのトポロジであった。本実施の形態では、双方が無線ネットワークである図１３のようなトポロジの場合の例について説明する。

（５−１．ネットワーク構成）
図１３は、本実施形態に関わる通信ネットワークシステムの概略構成を示すブロック図である。同図に示すように、本実施形態に関わる通信ネットワークシステムは、両端に無線ネットワーク９Ａ・９Ｂがあり、それを有線ネットワーク１３で接続している。この構成において、第１無線局２Ａから第４無線局３Ｂに対して、ストリームを送信する場合、リソースをそれぞれの無線ネットワーク９Ａ・９Ｂで取得しなければならない。

（５−２．フレームシーケンス）
図１４に、上記のような構成の通信ネットワークシステムにおいて、リソース取得を行うフレームシーケンスの一例を示す。

まず、第４無線局３Ｂでは、Ｓ３１でアプリケーション４２がリソースを取得するための命令を受信し自身で無線ネットワーク９Ｂの帯域を取得できると判定し、Ｓ３２，Ｓ３３で帯域を確保している。そこで、相手局が無線ネットワーク９Ｂの中にないことが分かったので、そのストリームの送信局である第１無線局２Ａに対して、Ｓ３４で、リソース取得をするためのフレームを送信している。

このフレームの内容は、実際に、どのようなリソースを確保するのかということが含まれる。例えば、ＩＥＥＥ Ｐ８０２．１１ｅのネットワークでは、ＴＳＰＥＣと呼ばれるストリームの情報を示したものや、ＥＤＣＡおよびＨＣＣＡといったストリームの送信方法、どのようなＡｃｋのタイプを使用するかなどが含まれる。また、ネットワークにまたがるため、ネットワーク全体で守らなければならない値（ジッタ、ディレイなど）は、各ネットワークで分割されて送信されてもよい。

次に、リソース取得要求フレームを受信した第１無線局２Ａは、Ｓ３４で、第４無線局３Ｂから受信したリソース取得要求フレームに入っている情報から、帯域確保要求フレームを作成し、Ｓ３５で、ＱＡＰ／ＨＣ６Ａに対して、送信する。このときに、第１無線局２Ａは、第４無線局３Ｂから受信した情報以外に、ＱＡＰ／ＨＣ６Ａに対して要求する情報を作成してもよい。例えば、そのストリームを識別するための識別子などである。

ＱＡＰ／ＨＣ６Ａは、第１無線局２Ａから帯域確保要求フレームを受信した後、そのフレームに入っている情報から必要な帯域を計算し、その帯域が割り当てることが可能であるかどうかを判断し、結果を、Ｓ３６で、帯域確保返答フレームを送信する。

第１無線局２Ａは、Ｓ３７で、Ｓ３６で受信した返答フレームの結果を第４無線局２Ｂに対して送信を行い、結果を通知する。また、Ｓ３７で返答フレームを受信した後、さらに、必要な設定を行ってもよい。

さらに、無線ネットワーク９Ｂでは、リソースの取得が成功したが、無線ネットワーク９Ａでは、リソースの取得が失敗した場合には、ストリームの送信を行わなくてもよい。また、ストリームの送信を行わない場合には、無線ネットワーク９Ｂの取得したリソースを開放するべきである。さらに、上記のような場合でも、ストリームを送信してもよい。この場合は、無線ネットワーク９Ａでは、ベストエフォートや、優先度ベースでストリームが送信される。それゆえ、優先度をあげてストリームを送信することが望ましい。これにより、受信側できちんと再生できる可能性が大きくなる。

第１無線局２Ａは、Ｓ３４で第４無線局３Ｂからリソース取得要求フレームを受信したときに、もうすでに、まったく同じストリームを定義していたら、新たに取り直す必要なない。また、すでにその帯域の取得ができていることを、第４無線局３Ｂに対して、Ｓ３７のリソース返答フレームで送信してもよい。そのときは、リソースが取得できているというエラーで返してもよいし、リソースが取得完了したということを返してもよい。すなわち、本実施形態の構成によれば、送信側、受信側関係なく、双方で、帯域取得のための命令をアプリケーションが出すことができる。

さらに、図１３のようなトポロジでも、上記のようなＳ３４，Ｓ３８といったフレームを使用しなくても、実施の形態１や実施の形態２を組み合わせることによって実現は可能である。

（実施の形態６）
本発明の実施の一形態について図１５、図１６に基づいて説明すれば、以下のとおりである。なお、前記した実施の形態１〜５で説明した構成と同様の機能を有する構成には、同一の符号を付記し、その説明を省略する。

リソースを取得して送受信できるネットワークが複数接続されている場合、リソースをそれぞれのネットワークで取得をしようとすると、ストリームを送受信するために通るネットワーク全体でのリソースの管理ができなくなる。そのような場合には、図１５のトポロジに示すような、管理マネージャ６０をネットワークのどこかに設け、その管理マネージャ６０が各ネットワークのリソース取得局に対して、リソース取得の指示を出してもよい。

（６−１．ネットワーク構成）
図１５は、本実施形態に関わる通信ネットワークシステムの概略構成を示すブロック図である。同図に示すように、本実施形態に関わる通信ネットワークシステムは、両端に無線ネットワーク９Ａ・９Ｂがあり、それを有線ネットワーク１３で接続している。さらに、有線ネットワーク１３には、管理マネージャ６０が接続されている。

（６−２．管理マネージャ）
上記管理マネージャ６０は、ネットワーク監視局としての機能を有する。具体的には、管理マネージャ６０は、例えば次の処理を行う。（１）ストリームの経路全体における帯域の管理（どのようなネットワーク・通信局を通過するのか、各々の経路に応じた帯域確保の要請）、（２）各ネットワークにおける状況の確認（帯域情報（どのくらい帯域が余っているのか）、通信局情報（ＡＰ／ＨＣ、ＳＴＡなど）、通信方法（Eather、802.11a/b/g/eなど））。

そして、上記のような情報を、各ネットワークに参加している通信局のいずれかが、管理マネージャ６０に対して通知する。例えば、ＱＡＰ／ＨＣ６が代表となってネットワークの状況を調べて通知する。もしくは、それぞれの無線局２・３が管理マネージャ６０に対して通知する。管理マネージャ６０がそれぞれの無線局２・３に通知するように命令する、などが考えられる。

管理マネージャ６０がリソース管理局であるＱＡＰ／ＨＣ６を知る仕組みについては、あらかじめ登録されていてもよいし、ブロードキャストのパケットを送信して探索したり、ＱＡＰ／ＨＣ６が管理マネージャ６０に対して、ネットワークが接続されたときに通知することが可能である。

また、実際に帯域を確保してストリームを送信する手順の概略は、次のとおりである。

［１］ストリームを送信／受信する通信局が、そのストリームの情報を相手局のアドレスを管理マネージャ６０に通知する。

［２］管理マネージャ６０が、その通知について経路・帯域などを計算し、各ネットワークに対して帯域確保の要求を行う。なお、（ア）経路上のネットワーク、通信局の情報は、あらかじめ取得しておいてもよいし、このときに取得するようにしてもよい。（イ）帯域は、ストリームの情報から計算する。また、計算方法はネットワーク経路に応じて変更してもよい。なお、オーバーヘッドなどが異なることが考えられる。

［３］管理マネージャ６０が、送信局／受信局に対して、帯域確保の結果を通知する。なお、各ネットワークで要求が失敗するかもしれないが、そのような場合には、ストリーム自体を流さない、もしくは、帯域が確保されていないということを、送受信局に対して通知する。

［４］ストリームの送受信を開始する。

（６−３．フレームシーケンス）
図１６に、上記のような構成の通信ネットワークシステムにおいて、リソース取得を行うフレームシーケンスの一例を示す。

上述した実施の形態４（図１３、図１４）のときと同様に、第１無線局２Ａから第４無線局３Ｂに対してストリームを送信するときに、無線ネットワーク９Ａ・９Ｂそれぞれでリソースを確保する。そこで、管理マネージャ６０は、それぞれネットワーク９Ａ・９Ｂのリソースを取得できる第１無線局２Ａおよび第４無線局３Ｂに対して、リソースの取得を指示する（Ｓ４１，Ｓ４５）。そして、Ｓ４４，Ｓ４８で、管理マネージャ６０がそれぞれのリソース取得の結果を取得し、実際にストリームの送受信を開始する。

なお、リソース取得のための情報は、前述したものでよい。また、実際に各無線ネットワークにおけるリソース取得する方法は、前述した実施の形態に記述したとおりである。

ここで、管理マネージャ６０は、ネットワークの種類、構成、用途、特性に応じて、ある程度、情報を変更したり、ネットワーク全体で配分すべき情報を決定することが望ましい。そのために、管理マネージャ６０の機能として、各ネットワークの情報を取得する機能があってもよい。例えば、どのようなネットワークなのか、送受信するストリームのためのリソースを確保できる局はいったいどの局なのかというような情報を取得できるようにしておいてもよい。この機能があれば、リソース取得の時に、リソース取得情報をより正確に記述できるはずである。

また、管理マネージャ６０はどのネットワークにあってもよい。管理マネージャ６０は、図１５では有線ネットワーク１３に接続されているが、例えば、無線ネットワーク９Ａ・９Ｂの中にあってもよい。

さらに、管理マネージャ６０は、各ネットワークで特定の局のみとしか通信できないような構成にしておいてもよい。例えば、有線ネットワーク１３に接続されているＱＡＰ／ＨＣ６Ａ・６Ｂのみとしか通信できないようにしておいてもよい。このような場合には、リソース取得要求フレームを受信した、ＱＡＰ／ＨＣ６Ａ・６Ｂは、実施の形態１の（１−５．本実施形態の変更例）（９）で前述したように、そのストリームのためにリソースを取得できる局に対してリソース取得の要求を出して、リソースの取得要求を行えばよい。

（実施の形態７）
本発明の実施の一形態について図１７に基づいて説明すれば、以下のとおりである。なお、前記した実施の形態１〜６で説明した構成と同様の機能を有する構成には、同一の符号を付記し、その説明を省略する。

本実施の形態では、通信局Ｂから通信局Ｃに対してストリームを送信するときに、ＩＥＥＥ Ｐ８０２．１１ｅネットワークにおいてどの局が帯域確保の命令を送信する局であるかということを判定するために、ＤＬＰを使用して無線ネットワーク内でのトポロジ（Direction）を判定する方法を示す。

図１７を用いて、ＤＬＰ（Direct Link Protocol）の設定方法を説明する。通常のＩＥＥＥ Ｐ８０２．１１の通信方式では、ＡＰ（Access Point）がすべての通信の橋渡しをすることになっている。つまり、通信局Ｂから通信局Ｃにデータを転送しようとすると、通信局Ｂ→通信局Ａ→通信局Ｃと送信する必要があったが、これでは、通信するための伝送帯域が２倍必要となり、データの送受信を行うのに無駄が生じる。このため、ＩＥＥＥ Ｐ８０２．１１ｅでは、ＡＰ以外の通信局の間を直接通信できるように設定すれば、パケットを直接送受信してもよいということが定義されている。

具体的には、通信局Ｂと通信局Ｃが直接通信したい場合には、まず、通信局ＢがＡＰ／ＨＣに対して、通信局Ｃと直接通信したいということを伝えるためのＤＬＰ要求フレームを送信する（Ｓ５１）。ＡＰ／ＨＣは、通信局ＣがＤＬＰを実行できるかどうかを判断して、実行できるようであれば、ＤＬＰ要求フレームを通信局Ｃに対して送信する（Ｓ５２）。通信局Ｃは、ＤＬＰ要求フレームを受信したら、ＤＬＰをするかどうかの判断を行い、ＤＬＰ返答フレームをＡＰ／ＨＣに送信する（Ｓ５３）。ＡＰ／ＨＣは、受信したＤＬＰ返答フレームを通信局Ｂに転送する（Ｓ５４）。

以上のシーケンスがすべて成功すれば、通信局Ｂと通信局Ｃが直接通信できるようになる。ＡＰ／ＨＣは、すべての局と通信ができることが前提となっているので、ＤＬＰをする必要はない。

なお、図１７中、ＳＭＥ（Station Management Entity（IEEE802.11））は、ステーション（端末、通信局）の管理機能である。ＳＭＥは、特定のレイヤの管理を行うものでなく、ＭＬＭＥやＰＬＭＥ（PHY Layer Management Entity）との間で様々な情報や制御信号のやりとり（MLME-DLP requestなど）を行って、MACやPHYを制御する。図４では、アドレス判定部４１、無線ネットワーク管理部３１、無線リソース管理部３０などが、ＳＭＥに相当する。

また、ＭＬＭＥ（MAC Layer Management entity（IEEE802.11））は、ＭＡＣ管理機能である。このＭＬＭＥを通して、ＭＡＣ層に命令・設定を行う。例えば、ネットワークの作成、加入や、帯域の確保、ＤＬＰの設定といった処理を実際に無線上で行うためのパケットを送受信する。図４では、無線パケット処理部２５がＭＬＭＥに相当する。

ＡＰ／ＨＣが通信局Ｃであれば、ＡＰ／ＨＣに対してストリームを送信することになるので、Directionは、アップリンク（Uplink）となる。

ＡＰ／ＨＣがＤＬＰ要求フレームを受信したときに（Ｓ５１）、同じＢＳＳ（Basic Service Set（IEEE802.11））の中に通信局Ｃがいない場合には、ＢＳＳの中にいないというエラーを返す。この場合は、通信局ＢからＡＰ／ＨＣに対してストリームを送信することになるので、Directionはアップリンクとなる。すべてのシーケンスが成功して通信局Ｃとダイレクト（Direct）に通信できるようになったら、Directionはダイレクトリンク（Directlink）となる。なお、ＢＳＳは、IEEE802.11のインフラストラクチャモードにおける基本単位であり、ＡＰと複数のＳＴＡで構成されるネットワークである。

通信局ＢがＡＰ／ＨＣの場合には、通信局Ｃが自身のＢＳＳの中にいることが分かっているので、Directionはダウンリンク（Downlink）となる。

アップリンク、ダイレクトリンクの場合で自局が送信局（Sender）の場合には、自局が帯域確保を行い、ダウンリンクのときには、相手局が帯域確保を行うことになる。

（８．補足）
本発明は上述した各実施形態に限定されるものではなく、請求項に示した範囲で種々の変更が可能であり、異なる実施形態にそれぞれ開示された技術的手段を適宜組み合わせて得られる実施形態についても本発明の技術的範囲に含まれる。

例えば、実施の形態１〜４において、いずれの局がリソース管理局であるか、通信ネットワークにおいて、データの送受信を行う通信相手局が自局と共通の通信リソースを管理する単位内に存在するか否か、自局がストリームの送信局であるか受信局であるか、通信経路がＱＡＰ／ＨＣ経由であるか否かなどの判定条件を、主に個別に用いる例について説明したが、これら判定条件の利用方法は、以上の説明に限定されるものではなく、実施の形態２で説明したように、これら判定条件を組み合わせることによって、リソースの取得を行う／行わないという判定を行ってもよい。

また、判定条件は上述したものに限定されるものではなく、対象となるネットワークにおける制約に応じて異なる条件となってもよい。

また、実施の形態１〜４において、アドレス判定部、通信経路判定部が自局にあるという説明を行ったが、各ネットワーク内におけるリソースを確保するために必要となる各判定部が、ストリームの送受信に関わらない他局にあってもよい。例えば、アドレス判定部が自局にあり、他局に通信経路判定部があって、情報を送信し、通信経路判定部を保持している局がリソース取得を行ってもよい。それぞれの判定部同士が通信するためにパケットを送信してもよい。また、そのパケットは、どのようなレイヤで送信されてもよい。さらに、それらのパケットの送信には、無線だけでなく、有線で接続された通信路を使用してもよい。

また、実施の形態１〜４において、無線ネットワークのリソースを確保することを重点に記述したが、有線ネットワークのリソースを確保したり、両者が混合したネットワークのリソースを確保するためにも利用でき、ネットワークの種別を問わない。

また、前記各実施の形態で説明した各通信局（無線局２・３、ＱＡＰ／ＨＣ６、通信局１４、管理マネージャ６０、特に無線ＡＶ機器４０、など）の各ブロックは、ハードウェアロジックによって構成してもよいし、次のようにＣＰＵを用いてソフトウェアによって実現してもよい。

すなわち、前記の各通信局は、各機能を実現する制御プログラムの命令を実行するＣＰＵ（central processing unit）、上記プログラムを格納したＲＯＭ（read only memory）、上記プログラムを展開するＲＡＭ（random access memory）、上記プログラムおよび各種データを格納するメモリ等の記憶装置（記録媒体）などを備えている。そして、本発明の目的は、上述した機能を実現するソフトウェアである前記の各通信局の制御プログラムのプログラムコード（実行形式プログラム、中間コードプログラム、ソースプログラム）をコンピュータで読み取り可能に記録した記録媒体を、上記の各通信局に供給し、そのコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に記録されているプログラムコードを読み出し実行することによっても、達成可能である。

上記記録媒体としては、例えば、磁気テープやカセットテープ等のテープ系、フロッピー（登録商標）ディスク／ハードディスク等の磁気ディスクやＣＤ−ＲＯＭ／ＭＯ／ＭＤ／ＤＶＤ／ＣＤ−Ｒ等の光ディスクを含むディスク系、ＩＣカード（メモリカードを含む）／光カード等のカード系、あるいはマスクＲＯＭ／ＥＰＲＯＭ／ＥＥＰＲＯＭ／フラッシュＲＯＭ等の半導体メモリ系などを用いることができる。

また、前記の各通信局を通信ネットワークと接続可能に構成し、上記プログラムコードを通信ネットワークを介して供給してもよい。この通信ネットワークとしては、特に限定されず、例えば、インターネット、イントラネット、エキストラネット、ＬＡＮ、ＩＳＤＮ、ＶＡＮ、ＣＡＴＶ通信網、仮想専用網（virtual private network）、電話回線網、移動体通信網、衛星通信網等が利用可能である。また、通信ネットワークを構成する伝送媒体としては、特に限定されず、例えば、ＩＥＥＥ１３９４、ＵＳＢ、電力線搬送、ケーブルＴＶ回線、電話線、ＡＤＳＬ回線等の有線でも、ＩｒＤＡやリモコンのような赤外線、Ｂｌｕｅｔｏｏｔｈ（登録商標）、８０２．１１無線、ＨＤＲ、携帯電話網、衛星回線、地上波デジタル網等の無線でも利用可能である。なお、本発明は、上記プログラムコードが電子的な伝送で具現化された、搬送波に埋め込まれたコンピュータデータ信号の形態でも実現され得る。

最後に、本発明に係る通信局は、一つ以上の通信ネットワークを介してデータの送受信を行う通信経路の一部もしくはすべての通信経路における通信リソースを確保した上でデータの送受信を行う通信局であって、上記通信ネットワークに関する事象および／または状態を検出する事象・状態検出部と、上記事象・状態検出部が検出した、上記通信ネットワークに関する事象および／または状態の内容に応じて、自局が通信リソースの取得、変更、または開放する処理を担当するか否かを判定する通信リソース処理担当判定部と、上記通信リソース処理担当判定部の判定結果に基づいて、上記通信ネットワークにおける通信リソースを取得、変更、または開放する通信リソース管理部とを備えた構成となっていてもよい。

また、本発明に係る通信局の制御方法は、一つ以上の通信ネットワークを介してデータの送受信を行う通信経路の一部もしくはすべての通信経路における通信リソースを確保した上でデータの送受信を行う通信局の制御方法であって、上記通信ネットワークに関する事象および／または状態を検出する事象・状態検出ステップと、上記検出した、上記通信ネットワークに関する事象および／または状態の内容に応じて、自局が通信リソースの取得、変更、または開放する処理を担当するか否かを判定する通信リソース処理担当判定ステップと、上記判定結果に基づいて、上記通信ネットワークにおける通信リソースを取得、変更、または開放する通信リソース管理ステップとを含む方法であってもよい。

上記の構成では、まず事象・状態検出部によって、通信ネットワークに関する事象および／または状態が検出される。この内容に応じて、通信リソース処理担当判定部によって、通信ネットワークにおいて、自局が通信リソースを取得、変更、または開放する処理を担当すべきか否かが判定され、これに基づいて、通信リソース管理部が、通信ネットワークの通信リソースを取得、変更、または開放する。なお、通信ネットワークは、複数であっても単体であってもよい。

すなわち、通信ネットワーク上のデータ送信局（通信局）が、通信ネットワーク上のデータ受信局に対してデータ送信を行う際、自局が通信リソースを取得、変更、または開放する処理を担当すべき場合には、データ送信局は、通信リソースを取得、変更、または開放する処理を行い、データ受信局との間の通信路を確立する一方、他局（データ受信局を含む）が通信リソースを取得、変更、または開放する処理を担当すべき場合には、他局（データ受信局を含む）によって通信路が確立されるまで待機する。

したがって、データ送信局のリソース取得等処理と、データ受信局のリソース取得等処理とが互いに衝突したり、逆に、データ送信局とデータ受信局との両者ともにリソース取得等処理を行わないことによって、通信路の確立が遅れたりすることがない。

それゆえ、通信ネットワークにそれぞれ設けられている通信局同士で通信を行う際に、各通信ネットワークの構成の複雑である場合や、接続される通信局の数が多い場合であっても、的確に通信リソースの取得、変更、または開放の処理を実行し、スムーズな相互通信を実現できるという効果を奏する。

また、上記の構成において、通信ネットワークは単一の構成であってもよいし、異なる種類の通信ネットワークを含む構成であってもよい。よって、利用者は、互いに異なる種類の通信ネットワークを含んだより広域の通信ネットワークを容易に導入することが可能となるという効果を併せて奏する。

また、本発明に係るネットワーク中継装置は、上記の構成において、上記通信リソース処理担当判定部は、上記通信ネットワークに接続された他の通信局のうち、いずれの局が通信リソース管理局かを判定する通信リソース管理局判定部を備え、上記通信リソース管理局判定部の判定結果に基づいて、自局が通信リソースの取得、変更、または開放する処理を担当するか否かを判定する構成となっていてもよい。

上記の構成では、まず、通信リソース管理局判定部によって、通信ネットワークに接続された他の通信局（自局を含む）のうち、いずれの局が通信リソース管理局かが判定される。通信リソース管理局判定部は、各局のアドレスや通信リソース管理局が発行する信号などの情報に基づいて、通信ネットワークに接続された他の通信局のうち、いずれの局が通信リソース管理局かを判定する。この判定結果に基づき、上記通信リソース処理担当判定部によって、自局が通信リソースの取得、変更、または開放する処理を担当するか否かが判定される。

これにより、上記作用効果に加えて、接続されたネットワーク上に帯域を管理する中央管理局が存在する場合にも、自局が通信リソースの取得、変更、または開放する処理を担当するか否かを的確に判定し、この判定結果に基づいて、より的確な通信リソースの取得、変更、または開放の処理を実行し、スムーズな相互通信を実現できるという効果を奏する。

また、本発明に係る通信局は、上記の構成において、上記通信リソース処理担当判定部は、上記通信ネットワークにおいて、データの送受信を行う相手局が、自局と共通の通信リソースを管理する単位内に存在するか否かを判定する接続ネットワーク判定部を備え、上記接続ネットワーク判定部の判定結果に基づいて、自局が通信リソースの取得、変更、または開放する処理を担当するか否かを判定する構成となっていてもよい。

上記の構成では、まず、接続ネットワーク判定部によって、通信ネットワークにおいて、データの送受信を行う相手局が、自局と共通の通信リソースを管理する単位内に存在するか否かが判定される。上記通信リソース処理担当判定部は、例えば上位層のアドレス（例えば、ＩＰアドレス）の構造やＱＢＳＳ内部に存在する通信局のＭＡＣアドレス一覧情報などに基づいて、ＩＥＥＥ Ｐ８０２．１１ｅにおける同一のＱＢＢＳのように、自局と共通の通信リソースを管理する単位内に存在するか否かを判定する。この判定結果に基づき、上記通信リソース処理担当判定部によって、自局が通信リソースの取得、変更、または開放する処理を担当するか否かが判定される。例えば、通信リソース処理担当判定部は、データの送受信を行う相手局が、自局と共通の通信リソースを管理する単位内に存在しなければ、自局が通信リソースの取得、変更、または開放する処理を担当すると判定する一方、データの送受信を行う相手局が、自局と共通の通信リソースを管理する単位内に存在すれば、自局は通信リソースの取得、変更、または開放する処理を担当せず、他局によって通信路が確立されるまで待機する。

これにより、上記作用効果に加えて、上記通信ネットワーク内に、通信リソースを管理する単位が存在する場合であっても、的確な通信リソースの取得、変更、または開放の処理を実行し、スムーズな相互通信を実現できるという効果を奏する。

また、本発明に係る通信局は、上記の構成において、上記通信リソース処理担当判定部は、上記通信ネットワークにおいて、自局がストリームを送信するか受信するかを判定するストリーム送受信判定部を備え、上記接続ネットワーク判定部の判定結果に基づいて、自局が通信リソースの取得、変更、または開放する処理を担当するか否かを判定する構成となっていてもよい。

上記の構成では、まず、ストリーム送受信判定部によって、通信ネットワークにおいて、自局がストリームを送信するか受信するかを判定するか否かが判定される。ストリーム送受信判定部は、例えば、ＩＥＥＥ Ｐ８０２．１１ｅ通信方式のダイレクトリンクにおいて、自局が、ストリームを送信するのか、ストリームを受信するのかを判定する。この判定結果に基づき、上記通信リソース処理担当判定部によって、自局が通信リソースの取得、変更、または開放する処理を担当するか否かが判定される。

例えば、通信リソース処理担当判定部は、通信ネットワークにおいて、自局がストリームを送信する場合には、自局が通信リソースの取得、変更、または開放する処理を担当すると判定する一方、自局がストリームを受信する場合には、自局は通信リソースの取得、変更、または開放する処理を担当せず、他局によって通信路が確立されるまで待機する。

これにより、上記作用効果に加えて、ストリーム送受信による通信を行う場合に、自局が通信リソースの取得、変更、または開放する処理を担当するか否かを的確に判定し、この判定結果に基づいて、的確な通信リソースの取得、変更、または開放の処理を実行し、スムーズな相互通信を実現できるという効果を奏する。

また、本発明に係る通信局は、上記の構成において、上記通信リソース処理担当判定部は、上記通信ネットワークにおけるストリームの通信経路を判定する通信経路判定部を備え、上記通信経路判定部の判定結果に基づいて、自局が通信リソースの取得、変更、または開放する処理を担当するか否かを判定する構成となっていてもよい。

上記の構成では、まず、ストリーム送受信判定部によって、通信ネットワークにおけるストリームの通信経路が判定される。ストリーム送受信判定部は、例えば、ＩＥＥＥ Ｐ８０２．１１ｅ通信方式において、ダイレクトリンクでデータ通信を行うのか、ＱＡＰ／ＨＣ経由でデータ通信を行うのかというストリームの通信経路を判定する。この判定結果に基づき、上記通信リソース処理担当判定部によって、自局が通信リソースの取得、変更、または開放する処理を担当するか否かが判定される。

例えば、通信リソース処理担当判定部は、ＩＥＥＥ Ｐ８０２．１１ｅ通信方式において、ダイレクトリンクでデータ通信を行う場合には、送信局−受信局間の１本の通信路を確保すればよいので、通信リソースの取得、変更、または開放する処理を担当せず、相手局に任せるものと判定する一方、ＱＡＰ／ＨＣ経由でデータ通信を行う場合には、送信局−ＱＡＰ／ＨＣ間およびＱＡＰ／ＨＣ−受信局間の２本の通信路を確保する必要があるので、自局が通信リソースの取得、変更、または開放する処理を担当するものと判定する。

これにより、上記作用効果に加えて、ストリーム送受信による通信を行う場合に、特に、２つの通信局間で直接通信を行うことも他の局を経由して通信を行うこともできる場合に、的確な通信リソースの取得、変更、または開放の処理を実行し、スムーズな相互通信を実現できるという効果を奏する。

また、上記の構成において、上記通信ネットワーク上には、該通信ネットワークのリソースを管理するリソース管理局が存在する場合に、本発明に係る通信局は、上記リソース管理局に対して、上記通信ネットワークにおける通信リソースを取得、変更、または開放する構成となっていてもよい。

また、本発明に係る通信局は、上記の構成において、自局が管理する上記通信ネットワークのリソースに対して、上記通信ネットワークにおける通信リソースを取得、変更、または開放する構成となっていてもよい。

これら構成によれば、それぞれ、通信ネットワークのリソースをリソース管理局が管理する場合、通信局が自ら管理する場合において、的確な通信リソースの取得、変更、または開放の処理を実行し、スムーズな相互通信を実現できるという効果を奏する。

また、本発明に係る通信局は、自局がリソース取得を行えないと判定した場合には、上記通信ネットワーク上の他局に対して、リソース取得、変更あるいは開放を要求する構成となっていてもよい。

上記の構成によれば、上位層が下位層の制約を意識せずにリソース取得要求を発行でき、また、常に送信局（あるいは受信局）からリソース取得要求を発行できるので、本発明に係る通信局を簡潔な構成で実現できるという効果を奏する。

また、本発明に係る通信局は、上記の構成において、上記事象・状態検出部は、上記通信ネットワークに接続された他の通信局にネットワークの状態の情報を要求する構成となっていてもよい。

以上の構成において、上記事象・状態検出部は、例えば、上記通信ネットワークに接続された他の通信局にネットワーク情報を要求する構成であってもよいし、上記通信ネットワークに接続された他の通信局のアドレス情報を検出する構成であってもよい。

さらに、本発明に係る通信局は、上記の構成において、リソース取得を行えないと判定した相手局が、リソース取得、変更あるいは開放を要求してきた場合に、上記通信ネットワーク上のリソース取得、変更あるいは開放を行う構成となっていてもよい。

また、本発明に係る通信局は、上記の構成において、リソース取得を行えないと判定した相手局が、リソース取得、変更あるいは開放を要求してきた場合に、すでに同じデータに対するリソースを自局から取得しているかどうかを判定し、自局からリソースを取得していない場合には、上記通信ネットワーク上のリソース取得、変更あるいは開放を行い、自局からリソースを取得している場合には、相手局に対して、リソースの取得は終了することを通知する構成となっていてもよい。

また、本発明に係る通信局は、一つ以上の通信ネットワークを介してデータの送受信を行う通信経路の一部もしくはすべての通信経路における通信リソースを確保した上でデータの送受信を行う通信局であって、上記通信ネットワークに関する事象および／または状態を検出する事象・状態検出部と、上記事象・状態検出部が検出した、上記通信ネットワークに関する事象および／または状態の内容に応じて、どの局がある通信ネットワークにおける通信リソースの取得、変更、または開放する処理を担当するか否かを判定する通信リソース処理担当判定部と、上記通信リソース処理担当判定部の判定結果に基づいて、ある一つの通信ネットワークにおける通信リソースを取得、変更、または開放する通信リソース管理局に対して、通信リソースの取得、変更、または開放する処理を指示する通信リソース取得要求部とを備える構成となっていてもよい。

また、本発明に係る通信局の制御方法は、一つ以上の通信ネットワークを介してデータの送受信を行う通信経路の一部もしくはすべての通信経路における通信リソースを確保した上でデータの送受信を行う通信局の制御方法であって、上記通信ネットワークに関する事象および／または状態を検出する事象・状態検出ステップと、上記検出した、上記通信ネットワークに関する事象および／または状態の内容に応じて、どの局がある通信ネットワークにおける通信リソースの取得、変更、または開放する処理を担当するか否かを判定する通信リソース処理担当判定ステップと、上記判定結果に基づいて、ある一つの通信ネットワークにおける通信リソースを取得、変更、または開放する通信リソース管理局に対して、通信リソースの取得、変更、または開放する処理を指示する通信リソース取得要求ステップとを含む方法であってもよい。

上記の構成によれば、通信ネットワーク上のデータ送信局が、通信ネットワーク上のデータ受信局に対してデータ送信を行う際、通信ネットワークにおける通信リソースを取得、変更、または開放する通信リソース管理局に対して、通信リソースの取得、変更、または開放する処理を管理マネージャが指示する。

したがって、データ送信局のリソース取得等処理と、データ受信局のリソース取得等処理とが互いに衝突したり、逆に、データ送信局とデータ受信局との両者ともにリソース取得等処理を行わないことによって、通信路の確立が遅れたりすることがない。

それゆえ、通信ネットワークにそれぞれ設けられている通信局同士で通信を行う際に、各通信ネットワークの構成の複雑である場合や、接続される通信局の数が多い場合であっても、的確に通信リソースの取得、変更、または開放の処理を実行し、スムーズな相互通信を実現できるという効果を奏する。

また、本発明に係る通信局は、上記の構成において、上記の通信局がリソース取得、変更あるいは開放を要求してきた場合に、上記ある一つの通信ネットワーク上のリソース取得、変更あるいは開放を行うように構成されていてもよい。

また、本発明に係る通信局システムは、一つ以上の通信ネットワークを介してデータの送受信を行う通信経路の一部もしくはすべての通信経路における通信リソースを確保した上で互いにデータの送受信を行う通信局を複数有する通信システムであって、上記通信ネットワークに関する事象および／または状態を検出する事象・状態検出部と、上記事象・状態検出部が検出した、上記通信ネットワークに関する事象および／または状態の内容に応じて、自局が通信リソースの取得、変更、または開放する処理を担当するか否かを判定する通信リソース処理担当判定部と、上記通信リソース処理担当判定部の判定結果に基づいて、上記通信ネットワークにおける通信リソースを取得、変更、または開放する通信リソース管理部との各々が、上記複数の通信局の少なくともいずれか一つに設けられて構成されていてもよい。

上記の構成によれば、事象・状態検出部、通信リソース処理担当判定部、通信リソース管理部は、通信システムを構成する、互いに通信可能な通信局に設けられる。このように、事象・状態検出部、通信リソース処理担当判定部、通信リソース管理部は、各通信局が通信をできるような状態であれば、いずれの通信局に設けられていてもかまわない。例えば、３つの通信局に事象・状態検出部、通信リソース処理担当判定部、通信リソース管理部をそれぞれ設け、各々の機能を有する通信局間で、情報が適宜に通信によって伝達されれば問題ない。なお、このように構成した場合、ＩＥＥＥ８０２．１１とは異なるネットワーク構成となる。

本発明に係る通信プログラムは、本発明に係る通信局が行う各処理をコンピュータに実行させる構成となっている。また、本発明に係る通信プログラムは、本発明に係る通信局が行う各処理をコンピュータに実行させる通信プログラムを記録し、コンピュータ読み取り可能な構成となっている。

これら構成によれば、上記通信プログラムをコンピュータに読み取り、実行させることによって、上記の各作用効果を実現することができる。

発明の詳細な説明の項においてなされた具体的な実施態様または実施例は、あくまでも、本発明の技術内容を明らかにするものであって、そのような具体例にのみ限定して狭義に解釈されるべきものではなく、本発明の精神と特許請求事項との範囲内で、いろいろと変更して実施することができるものである。

本発明に係る通信局によれば、通信ネットワークがどのような構成となっていても、的確に通信リソースの取得、変更、または開放の処理を実行し、スムーズな相互通信が可能となるので、例えば家庭内において、複数の部屋にある各種ＡＶ機器を互いに、幅広い形態のネットワークで接続するようなシステムでの通信局として適用することができる。

Claims (14)

1. ネットワークに接続する機能を有すると共に、該ネットワークに接続している機器と通信する機能、及び該ネットワーク外の機器と該ネットワークに接続された中継局を介して通信する機能を有する通信局であって、
   自局が、通信リソース管理局が通信リソースを管理するネットワークに接続した状態で上記通信リソースを用いて相手機器とデータ通信を行うときに、上記相手機器が当該ネットワークに接続されているか否かを判定する判定部と、
   上記判定部の判定結果に応じて、上記通信リソース管理局に上記通信リソースの取得、変更、または開放を要求するか否かを変更する自局通信リソース管理部とを備える通信局。
2. 上記判定部は、上記相手機器のアドレスと、予め記憶している上記ネットワーク内の機器に割り当てられるアドレスとを比較することによって、上記相手機器が上記ネットワークに接続されているか否かを判定する請求項１に記載の通信局。
3. 上記通信リソースは、上記ネットワークの通信帯域である請求項１または２に記載の通信局。
4. 上記自局通信リソース管理部は、上記判定部が、上記相手機器が上記ネットワークに接続されていないと判定した場合に、上記通信リソースを取得し、
   上記判定部が、上記相手機器が上記ネットワークに接続されていると判定した場合に、上記相手機器に上記通信リソースの取得を要求する請求項１から３の何れか１項に記載の通信局。
5. ネットワークに接続する機能を有すると共に、該ネットワークに接続している機器と通信する機能、及び該ネットワーク外の機器と該ネットワークに接続された中継局を介して通信する機能を有する通信局の制御方法であって、
   上記通信局が、通信リソース管理局が通信リソースを管理するネットワークに接続した状態で上記通信リソースを用いて相手機器とデータ通信を行うときに、上記相手機器が当該ネットワークに接続されているか否かを判定するステップと、
   上記判定の結果に応じて、上記通信リソース管理局に上記通信リソースの取得、変更、または開放を要求するか否かを変更するステップとを含む通信局の制御方法。
6. ネットワークに接続する機能を有すると共に、該ネットワークに接続している機器と通信する機能、及び該ネットワーク外の機器と該ネットワークに接続された中継局を介して通信する機能を有する通信局であって、
   自局が、通信リソース管理局が通信リソースを管理するネットワークに接続した状態で上記通信リソースを用いて相手機器とデータ通信を行うときに、上記相手機器との通信経路に上記中継局が含まれるか否かを判定する通信経路判定部と、
   上記通信経路判定部の判定結果に応じて、上記通信リソース管理局に上記通信リソースの取得、変更、または開放を要求するか否かを変更する自局通信リソース管理部とを備える通信局。
7. 上記中継局を経由せずにデータ通信を行う設定に成功した通信相手のアドレスを記憶するネットワーク管理部を備え、
   上記通信経路判定部は、上記ネットワーク管理部が記憶しているアドレスと、上記相手機器のアドレスとを比較することによって、上記相手機器との通信経路に上記中継局が含まれるか否かを判定する請求項６に記載の通信局。
8. ネットワークに接続する機能を有すると共に、該ネットワークに接続している機器と通信する機能、及び該ネットワーク外の機器と該ネットワークに接続された中継局を介して通信する機能を有する通信局の制御方法であって、
   上記通信局が、通信リソース管理局が通信リソースを管理するネットワークに接続した状態で上記通信リソースを用いて相手機器とデータ通信を行うときに、上記相手機器との通信経路に上記中継局を含むか否かを判定するステップと、
   上記の判定結果に応じて、上記通信リソース管理局に上記通信リソースの取得、変更、または開放を要求するか否かを変更するステップとを含む通信局の制御方法。
9. 一つ以上の通信ネットワークを介してデータの送受信を行う通信経路の一部もしくはすべての通信経路の通信リソースを確保する通信リソース管理局に通信リソースを確保させた上でデータの送受信を行う通信局であって、
   上記通信ネットワークに接続された他の通信局のうち、いずれの局が上記通信リソース管理局であるかを判定する通信リソース管理局判定部と、
   上記通信リソース管理局判定部の判定結果に基づいて、自局が上記通信リソース管理局に通信リソースの取得、変更、または開放を要求するか否かを判定する通信リソース処理担当判定部と、
   上記通信リソース処理担当判定部の判定結果に基づいて、上記通信リソース管理局に通信リソースの取得、変更、または開放を要求する自局通信リソース管理部とを備える通信局。
10. 一つ以上の通信ネットワークを介してデータの送受信を行う通信経路全体の通信リソースを管理する管理局であって、
    上記通信ネットワークにおいてデータを送信する通信局またはデータを受信する通信局から、上記データを送受信するために必要な帯域を示す情報、及び上記データを受信または送信する通信局のアドレスを取得し、該取得した情報及びアドレスに応じて、いずれの通信局が上記データを送受信するために必要な通信リソースの取得、変更、または開放する処理を担当するかを判定する通信リソース処理担当判定部と、
    上記通信リソース処理担当判定部の判定によって特定された通信局に指示して、上記データを送受信するために必要な通信リソースを管理する通信リソース管理局に、上記通信リソースの取得、変更、または開放を要求させる通信リソース取得要求部とを備える管理局。
11. 請求項１０に記載の管理局の要求を受けて、上記通信リソース管理局に、上記通信リソースの取得、変更、または開放を要求する通信局。
12. 請求項１〜４、６、７、９の何れか１項に記載の通信局、または請求項１０に記載の管理局が行う各処理をコンピュータに実行させる通信プログラム。
13. 一つ以上の通信ネットワークを介してデータの送受信を行う通信経路の一部もしくはすべての通信経路の通信リソースを確保する通信リソース管理局に通信リソースを確保させた上でデータの送受信を行う通信局の制御方法であって、
    上記通信ネットワークに接続された他の通信局のうち、いずれの局が上記通信リソース管理局であるかを判定する通信リソース管理局判定ステップと、
    上記通信リソース管理局判定ステップの判定結果に応じて、自局が上記通信リソース管理局に通信リソースの取得、変更、または開放を要求するか否かを判定する通信リソース処理担当判定ステップと、
    上記通信リソース処理担当判定ステップの判定結果に基づいて、上記通信リソース管理局に通信リソースの取得、変更、または開放を要求する自局通信リソース管理ステップとを含む通信局の制御方法。
14. 一つ以上の通信ネットワークを介してデータの送受信を行う通信経路全体の通信リソースを管理する管理局の制御方法であって、
    上記通信ネットワークにおいてデータを送信する通信局またはデータを受信する通信局から、上記データを送受信するために必要な帯域を示す情報、及び上記データを受信または送信する通信局のアドレスを取得し、該取得した情報及びアドレスに応じて、いずれの通信局が上記データを送受信するために必要な通信リソースの取得、変更、または開放する処理を担当するかを判定する通信リソース処理担当判定ステップと、
    上記通信リソース処理担当判定ステップの判定によって特定された通信局に指示して、上記データを送受信するために必要な通信リソースを管理する通信リソース管理局に、上記通信リソースの取得、変更、または開放を要求させる通信リソース取得要求ステップとを含む管理局の制御方法。

Images