JP2010041192A - 通信システム、通信装置および通信方法 - Google Patents

Abstract

【課題】バスリセット後のデータ通信の開始遅延を抑止する。
【解決手段】通信装置１の送信部１ａは、通信装置２，３，４とのリンクが再構築された後に、自装置が通信装置２，３，４が通信に用いるリソースの割り当てを管理する管理ノードとなった場合、通信装置２，３，４に自装置の識別情報Ｄ１を報知する。通信装置２の受信部２ｂは、通信装置１から識別情報Ｄ１を受信する。判定部２ｃは、受信部２ｂが受信した識別情報Ｄ１に基づいて、リンクの再構築前後で管理ノードが変更しているか否かを判定する。送信部２ｄは、判定部２ｃから管理ノードが変更していない旨の判定結果を取得すると、リソース割当記憶部２ａに記憶されたバスリセット前に割り当てられていたリソース情報に基づくリソースを用いて他の通信装置にデータを送信する。
【選択図】図１

Description

本件は、通信システム、通信装置および通信方法に関し、特にアイソクロナス転送方式により通信する通信システム、通信装置および通信方法に関する。

従来、音声や動画のデータを通信するマルチメディア通信システムが普及している。マルチメディア通信システムでは、デジタルレコーダやデジタルカメラ等、複数のデジタル機器が相互に接続され、他の機器から受信するデータの再生等を行うことができる。このようなマルチメディア通信システムでは、扱うデータ容量が大きく、再生中に途切れが発生しない等、鑑賞に耐え得る所定のサービス品質を備えたデータ通信が求められる。

この課題に対し、アイソクロナス転送（Isochronous Transfer）方式と呼ばれるデータ転送方式が知られている。アイソクロナス転送方式では、機器間での通信に対して一定の通信帯域を確保し、動画再生等の用途に応じて必要なデータ転送量を保証することができる。

このようなデータ転送方式では、各機器間の通信で使用されるチャネルや帯域等のリソースを所定の管理ノードが割り当ててデータ転送量を保証する。管理ノードは、ネットワーク上の通信を集中管理している。管理ノードを設置する方法としては、固定的にある機器が管理ノードの役割を所有する方法（例えば、特許文献１参照）や、ネットワーク上の各機器の中から１つを管理ノードとして（システム起動時等に）動的に選択する方法が知られている（例えば、特許文献２参照）。

しかし、前者の方法では管理ノードがネットワークに参加していなければ管理機能を提供できない。このため、各機器の参加・不参加が流動的なマルチメディア通信システムでは後者の方法が望ましい。

特に、後者の方法で管理ノードを設置し、アイソクロナス転送のためのリソースを管理する通信方式は、ＩＥＥＥ（Institute of Electrical and Electronics Engineers）１３９４やＩＥＥＥ１３９４を車載用に拡張したＩＤＢ（Intelligent transportation system Data Bus）１３９４等の通信規格に用いられている（例えば、非特許文献１，２，３参照）。なお、アイソクロナス転送のリソースを管理する管理マネージャは、アイソクロナスリソースマネージャ（ＩＲＭ：Isochronous Resource Manager）と呼ばれる。ＩＲＭは、利用可能なチャネルの空き状況および利用可能な帯域の空き状況を管理する。

これらの規格では、ＩＲＭはネットワークの構成時（バスリセット時）に発生する各機器間の調停により決定される。バスリセットは、ある機器がネットワークに新規に参加またはネットワークから離脱する等、ネットワークのトポロジーが変化したタイミングで発生する。これにより、各機器が任意のタイミングで参加・離脱が可能な通信環境を実現している。
特開平８−３２８９７０号公報 特表２００１−５１５３１２号公報 The Institute of Electrical and Electronics Engineers (IEEE), "IEEE Standard for a High Performance Serial Bus", IEEE Std 1394-1995. The Institute of Electrical and Electronics Engineers (IEEE), "IEEE Standard for a High Performance Serial Bus - Amendment 1", IEEE Std 1394a-2000. The Institute of Electrical and Electronics Engineers (IEEE), "IEEE Standard for a High Performance Serial Bus - Amendment 2", IEEE Std 1394b-2002.

しかし、上記非特許文献１，２，３に記載の方法では、バスリセットの度に、再度、各機器間でＩＲＭの選択を行い、それに伴ってリソースの管理情報もリセットされる。そして、ＩＲＭ決定後、ＩＲＭ以外のノードであるソースノードは、データ通信のためにＩＲＭに対してリソースの利用状況の通知を要求（Ｒｅａｄリクエストという）し、これに対するＲｅａｄレスポンスに基づいて、リソースの取得要求（Ｌｏｃｋリクエストという）を行う。更に、ＩＲＭでは、Ｌｏｃｋリクエストで要求されているリソースの割り当て可否を制御して、ソースノードに割当ＯＫまたはＮＧを示すレスポンスを返す。ソースノードは、割当ＯＫであれば要求したリソースを用いて通信を行い、ＮＧであれば再度ＩＲＭにＲｅａｄリクエストを送信して、リソースの取得要求を送り直す。

このように、バスリセット後には、ソースノードはデータ送信のためにＲｅａｄリクエストでリソースの空き状況を確認し、Ｌｏｃｋリクエストでリソースの取得要求を行わなければならない。このため、データ送信の開始までに遅延が発生するという問題がある。また、ネットワーク上に多数のソースノードが存在する場合には、ＩＲＭへの要求が輻輳して処理負荷が増大し、遅延の影響が大きくなる可能性もある。

本件はこのような点に鑑みてなされたものであり、バスリセット後のデータ通信の開始遅延を抑止可能な通信システム、通信装置および通信方法を提供することを目的とする。

上記課題を解決するために、複数の通信装置が相互に通信する通信システムが提供される。この通信システムは、第１の通信装置および第２の通信装置を有する。第１の通信装置は、他の複数の通信装置とのリンクが再構築された後に、自装置が他の複数の通信装置が通信に用いるリソースの割り当てを管理する管理ノードとなった場合、他の複数の通信装置に自装置の識別情報を報知する。第２の通信装置は、この識別情報を受信すると、識別情報に基づいてリンクの再構築前後で管理ノードが変更しているか否かを判定する。そして、第２の通信装置は、管理ノードが変更していない場合、リンクの再構築前に割り当てられていたリソースを用いて他の通信装置との通信を行う。

また、上記課題を解決するために他の複数の通信装置と接続された通信装置が提供される。この通信装置は、送信部を有する。送信部は、他の複数の通信装置とのリンクが再構築された後に、自装置が他の複数の通信装置が通信に用いるリソースの割り当てを管理する管理ノードとなった場合、他の複数の通信装置に自装置の識別情報を報知する。

また、上記課題を解決するために他の複数の通信装置と接続された通信装置が提供される。この通信装置は、リソース割当記憶部、受信部、判定部および送信部を有する。リソース割当記憶部は、リンクの再構築前に割り当てられていた通信用のリソース割当情報を記憶する。受信部は、リンクの再構築後に通信用のリソースの割り当てを管理する管理ノードからこの管理ノードの識別情報を受信する。判定部は、受信部が受信した識別情報に基づいて、リンクの再構築前後で管理ノードが変更しているか否かを判定する。送信部は、判定部が管理ノードが変更していないと判定すると、リソース割当記憶部に記憶されたリソース割当情報に基づくリソースを用いて他の通信装置にデータを送信する。

また、上記課題を解決するために、上記通信システムと同様の処理を行う通信方法が提供される。

上記通信システム、通信装置および通信方法によれば、バスリセット後のデータ通信の開始遅延を抑止することができる。

以下、本実施の形態を図面を参照して詳細に説明する。
図１は、通信システムの概要を示す図である。この通信システムは、アイソクロナス転信方式を用いてデータの送受信を行うシステムである。この通信システムは、通信装置１，２，３，４を有する。

通信装置１，２，３，４は、デイジーチェーンで有線のネットワークで接続される。通信装置１は、通信装置２，３と接続される。通信装置３は、通信装置４と接続される。この場合、通信装置２，３の間の通信は、通信装置１を介してバケツリレー方式で行われる。同様に、通信装置１と通信装置４の間の通信は、通信装置３を介して行われる。同様に、通信装置２と通信装置４の間の通信は、通信装置１および通信装置３を介して行われる。

通信装置１は、バスリセット後にアイソクロナス転送のためのリソースを管理する管理ノードとしての役割を取得したノードである。通信装置１は、送信部１ａを有する。
送信部１ａは、通信装置１が管理ノードとしての役割を取得後に、通信装置１を識別する識別情報Ｄ１を通信装置２，３，４に送信する。

通信装置２，３，４は、通信装置１から割り当てられたリソースを用いてデータ通信を行う。ここでは、通信装置２の構成に関してのみ説明するが、通信装置３，４に関しても同様である。通信装置２は、リソース割当記憶部２ａ、受信部２ｂ、判定部２ｃおよび送信部２ｄを有する。

リソース割当記憶部２ａは、バスリセット前に通信装置１から通信装置２に割り当てられていたリソース割当情報を記憶する。
受信部２ｂは、通信装置１から取得する識別情報Ｄ１を判定部２ｃに出力する。

判定部２ｃは、受信部２ｂから識別情報Ｄ１を取得すると、識別情報Ｄ１に基づいてバスリセット前後で管理ノードの役割を有するノードが変更しているか否かを判定する。判定部２ｃは、判定結果を送信部２ｄに出力する。管理ノードの役割を有するノードが変更していないとは、すなわち、通信装置１がバスリセット前にも管理ノードとしての役割を有していたことを意味する。

送信部２ｄは、判定部２ｃから管理ノードが変更していない旨の判定結果を取得すると、リソース割当記憶部２ａに記憶されたリソース割当情報に基づくリソースを用いて他の装置にデータを送信する。

このような通信システムによれば、バスリセットが発生するとバスリセット後に管理ノードの役割を取得した通信装置１により通信装置１を識別する識別情報が通信装置２，３，４に送信される。そして、通信装置２，３，４は、バスリセット前後で管理ノードが変更していないと判定されると、バスリセット前に通信装置２，３，４に割り当てられていたリソースを用いて他の装置とのデータ通信が行われる。

このため、バスリセット後に通信装置２，３，４側から通信装置１に対してリソースの利用状況を確認する必要がなくなり、また、利用状況に応じてリソースの取得要求を行う必要もなくなる。また、通信装置１に対するこれら要求の輻輳も防止される。このように、リソース取得のための処理ステップを削減し、通信装置１の処理負荷の増大を防止することで、データ通信の開始遅延を抑止することができる。

なお、送信部１ａは、識別情報Ｄ１と共に、リソースの利用状況を通信装置２，３，４に送信することもできる。このようにすると、通信装置１がバスリセット前に管理ノードではない場合にも、通信装置２，３，４は、識別情報Ｄ１と共に取得するリソースの利用状況に基づいて通信装置１にリソースの割当要求を行うことができる。これにより、通信装置２，３，４側から通信装置１に対するリソースの利用状況の確認の動作が不要となるため、バスリセット前後で管理ノードが変更している場合にもデータ通信の開始遅延を抑止することができる。

更に、通信装置１および通信装置２，３，４は、それぞれが管理ノードとしての役割を有することができる。すなわち、ネットワークの構成によっては、通信装置２，３，４のいずれかが通信装置１と同様の機能を果たすこともあり、また、通信装置１が通信装置２，３，４と同様の機能を果たすこともある。

ところで、図１に示した通信システムは、例えば、ＩＥＥＥ１３９４やＩＤＢ１３９４に準拠したマルチメディア通信システムで行われる音声や動画のデータを通信する場合に有用である。そこで、このような通信システムをマルチメディア通信システムに関連付けた場合の例を用いて本実施の形態を図面を参照して詳細に説明する。

図２は、通信システムのシステム構成を示す図である。この通信システムは、ネットワークで接続された複数のデジタル機器がアイソクロナス転送方式で相互に通信を行うＩＥＥＥ１３９４またはＩＤＢ１３９４準拠のマルチメディア通信システムである。この通信システムは、ＩＲＭノード１００、ソースノード２００，３００，４００，５００を有する。ＩＲＭノード１００は、バスリセット後にアイソクロナス転送のためのリソースを管理する役割を取得したアイソクロナスリソースマネージャである。ＩＲＭの役割を取得するノードは、バスリセット時に発生する各機器間の調停により決定される。この調停処理は、バスリセット後に各ノード間で送受信されるＳｅｌｆ−ＩＤ（IDentifier）パケットと呼ばれる所定のデータパケットに基づいて実行される。ＩＲＭノード１００は、例えば、デジタルレコーダ等のデジタル機器である。

ソースノード２００，３００，４００，５００は、ＩＲＭノード１００が割り当てたリソースを用いて通信を行う通信装置である。ソースノード２００，３００，４００，５００は、ＩＲＭノード１００と同様に、例えば、ＤＶＤプレーヤ、液晶モニタ、デジタルカメラ等のデジタル機器である。

ＩＲＭノード１００およびソースノード２００，３００，４００，５００は、デイジーチェーンで有線のネットワークにより接続される。ＩＲＭノード１００は、ソースノード２００，３００と接続される。ソースノード４００，５００は、ソースノード２００と接続される。この場合、ソースノード２００，３００の間の通信は、ＩＲＭノード１００を介してバケツリレー方式で行われる。このように各ノードが、接続を中継するノードを介して相互に通信を行うことができる。

なお、ソースノード２００，３００，４００，５００は、それぞれがＩＲＭとしての役割を有することができる。すなわち、バスリセット後の各ノード間の調停の結果によって、ソースノード２００，３００，４００，５００のいずれかがＩＲＭノード１００と同様の通信機能を果たすこともある。また、ＩＲＭノード１００がソースノード２００，３００，４００，５００と同様の通信機能を果たすこともある。

この通信システムでは、バスリセットが発生した場合でも、データ通信を開始するまでの遅延を抑止することができる。以下では、このようなＩＲＭノード１００、ソースノード２００，３００，４００，５００の各構成に関して説明する。

図３は、ＩＲＭノードのハードウェア構成を示す図である。ＩＲＭノード１００は、ＣＰＵ（Central Processing Unit）１０１によって装置全体が制御されている。ＣＰＵ１０１には、バス１０９を介してＲＯＭ（Read Only Memory）１０２、ＲＡＭ（Random Access Memory）１０３、ＨＤＤ（Hard Disk Drive）１０４、入力インタフェース１０５、出力インタフェース１０６および通信インタフェース１０７，１０８が接続されている。

ＲＯＭ１０２には、ＩＲＭノード１００上のＢＩＯＳ（Basic Input / Output System）のプログラム等が格納される。また、ＲＯＭ１０２には、製造時等に各ノードに固有の識別情報であるＣｈｉｐ−ＩＤが格納される。

ＲＡＭ１０３には、ＣＰＵ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションソフト（以下、アプリケーションという）のプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ１０３には、ＣＰＵ１０１による処理に必要な各種データが格納される。

ＨＤＤ１０４には、ＯＳのプログラム、アプリケーションのプログラムおよび各種動画や音声のデータが格納される。また、ＨＤＤ１０４には、ＣＰＵ１０１による処理に必要な各種データが格納される。なお、ＨＤＤ１０４の代わりにフラッシュメモリ等、他の不揮発性メモリ（ＮＶＲＡＭ：Non Volatile RAM）を用いても構わない。また、ＨＤＤ１０４に格納されるＯＳのプログラムやアプリケーションのプログラムは、ＲＯＭ１０２に格納されてもよい。

入力インタフェース１０５には、操作キー１１が接続されている。入力インタフェース１０５は、操作キー１１から送られてくる信号を、バス１０９を介してＣＰＵ１０１に送信する。

出力インタフェース１０６には、表示板１２が接続されている。出力インタフェース１０６は、ＣＰＵ１０１からの命令に従って、ユーザへの通知情報やＣＰＵ１０１の処理結果等を表示板１２に出力する。表示板１２は、例えば、液晶モニタや７セグメントディスプレイである。

通信インタフェース１０７，１０８は、ＩＥＥＥ１３９４またはＩＤＢ１３９４準拠の通信インタフェースである。通信インタフェース１０７は、ソースノード２００と接続される。通信インタフェース１０８は、ソースノード３００と接続される。ＩＲＭノード１００は、通信インタフェース１０７，１０８を介してソースノード２００，３００との間でデータの送受信を行う。また、ＩＲＭノード１００は、通信インタフェース１０８およびソースノード３００を介してソースノード４００，５００との間でデータの送受信を行う。

なお、ソースノード２００，３００，４００，５００もＩＲＭノード１００と同様のハードウェア構成により実現することができる。
図４は、ＩＲＭノードおよびソースノードの機能を示す図である。ＩＲＭノード１００は、リソース情報記憶部１１０、退避情報記憶部１２０、ＩＲＭ記憶部１３０、ＩＲＭ判定部１４０、メモリ管理部１５０、パケット処理部１６０、読み出し部１６５、リソース割当部１７０、送信部１８０および受信部１９０を有する。

リソース情報記憶部１１０は、ＩＲＭノード１００およびソースノード２００，３００，４００，５００がデータ通信に用いるリソースの利用状況を示すリソース情報を記憶する。ここで、リソースの利用状況とは、０チャネル〜６３チャネルまでの計６４チャネルの利用状況および通信帯域の利用状況である。チャネルの利用状況は、例えば、CHANNEL AVAILABLEレジスタと呼ばれる計６４ビットのレジスタ群により記憶され、ファームウェアによりテーブル管理される。また、通信帯域の利用状況は、例えば、BANDWIDTH AVAILAVLEレジスタと呼ばれる３２ビットのレジスタにより記憶され、ファームウェアによりテーブル管理される。

退避情報記憶部１２０は、リソース情報記憶部１１０に記憶されたリソースの利用状況を示す情報の複製を記憶する。退避情報記憶部１２０に複製が格納されるタイミングは、リソース情報記憶部１１０が更新されたタイミングである。

ＩＲＭ記憶部１３０は、今回のＩＲＭノード（すなわち、ＩＲＭノード１００）より１世代前のＩＲＭノードの識別情報が格納される。識別情報は、例えば、各ノードに一意に付与されたＣｈｉｐ−ＩＤである。なお、各ノードを一意に特定できる情報であれば、他の識別情報を用いても構わない。

ＩＲＭ判定部１４０は、バスリセットが発生すると、ソースノード２００，３００，４００，５００との調停の結果、自装置がＩＲＭノードであるか否かを判定する。ＩＲＭ判定部１４０は、自装置がＩＲＭノードであると判定すると、以下の場合に応じて、メモリ管理部１５０への指示を行う。（１）バスリセット前も自装置がＩＲＭノードであった場合、リソース情報記憶部１１０に記憶されたリソース情報をクリア（初期化）し、退避情報記憶部１２０に記憶されたバスリセット前のリソース情報の複製をリソース情報記憶部１１０に復元するよう指示する。（２）バスリセット前は自装置がＩＲＭノードでなかった場合、リソース情報記憶部１１０に記憶されたリソース情報をクリアするよう指示する。

なお、（１）の場合であるか（２）の場合であるかの判定は、ＩＲＭ記憶部１３０に記憶された識別情報が今回ＩＲＭノードである自装置の識別情報と一致するか否かによって行うことができる。ＩＲＭ判定部１４０は、前回ＩＲＭノード確定後に、今回のＩＲＭより１世代前のＩＲＭノードの識別情報をＩＲＭ記憶部１３０に格納している。ＩＲＭ判定部１４０は、この判定後に、ＩＲＭ記憶部１３０に記憶された識別情報を今回のＩＲＭノードである自装置の識別情報に更新する。

また、ＩＲＭ判定部１４０は、メモリ管理部１５０への指示後、パケット処理部１６０に対して自装置がＩＲＭノードであることを通知する。
メモリ管理部１５０は、ＩＲＭ判定部１４０からの指示に基づいて、リソース情報記憶部１１０に対する処理を行う。すなわち、バスリセット前後でＩＲＭノードが変更していない場合、リソース情報記憶部１１０をクリアして退避情報記憶部１２０に格納されたバスリセット前のリソース情報の複製をリソース情報記憶部１１０に復元する。また、バスリセット前後でＩＲＭノードが変更している場合、リソース情報記憶部１１０をクリアする。このように、リソース情報記憶部１１０に記憶された不要なリソース情報をクリアすることで、リソース管理における誤動作を防止する。

また、メモリ管理部１５０は、リソース情報記憶部１１０に記憶されたリソース情報が更新されると退避情報記憶部１２０に記憶されたリソース情報の複製も最新の状態に同期する。

パケット処理部１６０は、ＩＲＭ判定部１４０から自装置がＩＲＭノードである旨の通知を受けると、読み出し部１６５を介してリソース情報記憶部１１０に記憶されたリソース情報を取得する。そして、パケット処理部１６０は、自装置の識別情報およびリソース情報を含む所定の物理（ＰＨＹ）パケットを生成して、送信部１８０に出力する。

また、パケット処理部１６０は、受信部１９０を介してソースノード２００，３００，４００，５００からＲｅａｄリクエストを取得すると、読み出し部１６５を介してリソース情報記憶部１１０に記憶されたリソース情報を取得する。そして、Ｒｅａｄリクエストの送信元に対するＲｅａｄレスポンスを生成して送信部１８０に出力する。

更に、パケット処理部１６０は、受信部１９０を介してソースノード２００，３００，４００，５００からＬｏｃｋリクエストを取得すると、リソース割当部１７０にリソースの割り当てを指示し、リソース割当部１７０からリソースの割当結果（割り当てＯＫまたはＮＧ）を取得する。そして、Ｌｏｃｋリクエストの送信元に対する割当結果に応じたＯＫレスポンスまたはＮＧレスポンスを生成して送信部１８０に出力する。

読み出し部１６５は、パケット処理部１６０から取得する読み出し指示に基づいて、リソース情報記憶部１１０に記憶されたリソース情報を取得し、取得したリソース情報をパケット処理部１６０に出力する。

リソース割当部１７０は、パケット処理部１６０からのリソース割当指示に基づいて、リソース情報記憶部１１０に記憶されたリソース情報を更新する。リソース割当部１７０は、リソースの割当結果（割り当てＯＫまたはＮＧ）をパケット処理部１６０に出力する。

送信部１８０は、パケット処理部１６０から取得するＰＨＹパケットをソースノード２００，３００，４００，５００に対して、報知（ブロードキャスト送信）する。また、送信部１８０は、パケット処理部１６０から取得するＲｅａｄレスポンスやＯＫ／ＮＧレスポンスを各リクエスト送信元のソースノード２００，３００，４００，５００に送信する。

受信部１９０は、ソースノード２００，３００，４００，５００から送信されるＲｅａｄリクエストやＬｏｃｋリクエストを受信する。受信部１９０は、受信したＲｅａｄリクエストやＬｏｃｋリクエストをパケット処理部１６０に出力する。

以下では、ソースノード２００の構成に関して説明するが、ソースノード３００，４００，５００に関しても同様の構成である。
ソースノード２００は、リソース割当記憶部２１０、ＩＲＭ記憶部２２０、受信部２３０、パケット処理部２４０、ＩＲＭ判定部２５０および送信部２６０を有する。

リソース割当記憶部２１０は、バスリセット前に自装置が１世代前のＩＲＭノードから割り当てられていたリソースを記憶する。
ＩＲＭ記憶部２２０は、バスリセット前のＩＲＭノードの識別情報を記憶する。

受信部２３０は、ＩＲＭノード１００からＰＨＹパケットおよび各種リクエストに対するレスポンスを受信する。受信部２３０は、受信したＰＨＹパケットやレスポンスをパケット処理部２４０に出力する。

パケット処理部２４０は、受信部２３０からＰＨＹパケットを取得すると、ＩＲＭノード１００の識別情報を抽出してＩＲＭ判定部２５０に出力する。パケット処理部２４０は、ＩＲＭ判定部２５０からバスリセット前後でＩＲＭノードが変更しているか否かの判定結果を取得する。パケット処理部２４０は、取得した判定結果に応じて以下の処理を行う。（１）バスリセット前後でＩＲＭノードが変更していない場合、送信部２６０にリソース割当記憶部２１０に記憶されたバスリセット前のリソース情報が利用可能であると設定する。（２）バスリセット前後でＩＲＭノードが変更している場合、取得したＰＨＹパケットに含まれるリソース情報に基づいてＬｏｃｋリクエストを生成し、送信部２６０を介してＩＲＭノード１００に送信する。

なお、パケット処理部２４０は、（２）の処理後、受信部２３０を介してＩＲＭノード１００からＯＫレスポンスを取得すると、Ｌｏｃｋリクエストで要求したリソース情報でリソース割当記憶部２１０に記憶されたリソース割当情報を更新する。そして、このリソース情報が利用可能であると設定する。また、パケット処理部２４０は、（２）の処理後、ＮＧレスポンスを取得すると、Ｒｅａｄリクエストを生成してＩＲＭノード１００に対してリソースの利用状況を確認し、利用状況に応じて再度ＬｏｃｋリクエストをＩＲＭノード１００に送信する。

ＩＲＭ判定部２５０は、パケット処理部２４０からＩＲＭノード１００の識別情報を取得する。ＩＲＭ判定部２５０は、取得した識別情報とＩＲＭ記憶部２２０に記憶されたバスリセット前のＩＲＭノードの識別情報に基づいて、今回のバスリセット前後でＩＲＭノードが変更しているか否かを判定する。ＩＲＭ判定部２５０は、判定結果をパケット処理部２４０に出力する。また、ＩＲＭ判定部２５０は、判定後にパケット処理部２４０から取得した今回のＩＲＭノードの識別情報によりＩＲＭ記憶部２２０に格納された前回のＩＲＭノードの識別情報を更新する。

送信部２６０は、パケット処理部２４０から取得するＬｏｃｋリクエストやＲｅａｄリクエストをＩＲＭノード１００に送信する。また、送信部２６０は、リソース割当記憶部２１０に記憶された利用可能なリソース割当情報に基づくリソースを用いて他の装置とデータ通信を行う。

図５は、チャネル管理テーブルのデータ構造例を示す図である。チャネル管理テーブル１１１は、リソース情報記憶部１１０に記憶される。なお、チャネル管理テーブル１１１をバスリセット前後で保持できるよう、その複製が退避情報記憶部１２０に記憶される。チャネル管理テーブル１１１には、ＣＨを示す項目および利用状況を示す項目が設けられている。各項目の横方向に並べられた情報同士が対応付けられて、１つのチャネルに関する情報を構成する。チャネル管理テーブル１１１は、例えば、チャネルの利用状況を管理するための所定のCHANNELS AVAILABLEレジスタに記憶された情報をテーブル形式に管理したものである。

ＣＨを示す項目には、チャネル番号を示す項目が設定される。利用状況を示す項目には、各チャネル番号が既に割り当て済みか否かを示す情報が設定される。
チャネル管理テーブル１１１には、例えば、ＣＨが“１”、利用状況が“空き”という情報が設定される。これは、チャネル番号“１”は、ＩＲＭノード１００やソースノード２００，３００，４００，５００の間のデータ通信に割り当てられていないことを示している。また、チャネル管理テーブル１１１には、例えば、ＣＨが“２”、利用状況が“割り当て済み”という情報が設定される。これは、チャネル番号“２”が、ＩＲＭノード１００やソースノード２００，３００，４００，５００の間のいずれかのデータ通信に割り当て済みであることを示している。

図６は、帯域管理テーブルのデータ構造例を示す図である。帯域管理テーブル１１２は、リソース情報記憶部１１０に記憶される。なお、帯域管理テーブル１１２をバスリセット前後で保持できるよう、その複製が退避情報記憶部１２０に記憶される。帯域管理テーブル１１２には、利用可能帯域を示す項目が設けられている。帯域管理テーブル１１２は、例えば、利用可能帯域を管理するための所定のBANDWIDTH AVAILABLEレジスタに記憶された情報をテーブル形式に管理したものである。

利用可能帯域を示す項目には、データ通信に利用することができる帯域幅が設定される。帯域管理テーブル１１２には、例えば、利用可能帯域が“３９１５”という情報が設定される。これは、ＩＲＭノード１００やソースノード２００，３００，４００，５００の間のデータ通信に割り当てることのできる帯域幅が“３９１５”であることを示している。帯域幅の単位はデータ転送レートであり、適当な換算を行うことでＭｂｐｓ（Mega Bit Per Second）等に置き換えることも可能である。

なお、利用可能帯域の初期値は“４９１５”であり、データ通信に割り当てられるとその分だけ帯域幅は減少する。すなわち、利用可能帯域が“３９１５”である場合、他のデータ通信で“１０００”の帯域幅が既に占有されていることを示している。

図７は、ＩＲＭ記憶テーブルのデータ構造例を示す図である。ＩＲＭ記憶テーブル１３１は、ＩＲＭ記憶部１３０に記憶される。また、ＩＲＭ記憶部２２０もＩＲＭ記憶テーブル１３１と同様の情報が設定されたＩＲＭ記憶テーブルを記憶する。ＩＲＭ記憶テーブル１３１には、Ｃｈｉｐ−ＩＤを示す項目が設けられている。

Ｃｈｉｐ−ＩＤを示す項目には、バスリセット前のＩＲＭノードを識別する識別情報として、その装置に付与されたＣｈｉｐ−ＩＤが設定される。ＩＲＭ記憶テーブル１３１には、例えば、Ｃｈｉｐ−ＩＤが“２１５”という情報が設定される。これは、バスリセット前にＩＲＭノードであったノードのＣｈｉｐ−ＩＤが“２１５”であったことを示している。すなわち、ＩＲＭノード１００のＩＲＭ判定部１４０は、Ｃｈｉｐ−ＩＤ“２１５”が自装置のＣｈｉｐ−ＩＤと同一である場合、バスリセット前後でＩＲＭノードが変更しておらず、自装置が引き続きＩＲＭの役割を有すると判定することができる。

また、ソースノード２００のＩＲＭ判定部２５０は、ＩＲＭノード１００から受信するＰＨＹパケットに含まれるＣｈｉｐ−ＩＤに基づいて、ＩＲＭ記憶部２２０に記憶されたＣｈｉｐ−ＩＤ“２１５”と同一であるか否かを判定する。そして、同一である場合、バスリセット前後でＩＲＭノードが変更しておらず、ＩＲＭノード１００が引き続きＩＲＭの役割を有すると認識することができる。

図８は、リソース割当テーブルのデータ構造例を示す図である。リソース割当テーブル２１１は、リソース割当記憶部２１０に記憶される。リソース割当テーブル２１１には、ＣＨを示す項目および割当帯域を示す項目が設けられている。各項目の横方向に並べられた情報同士が対応付けられて、バスリセット前に割り当てられていたリソースの情報を構成する。

ＣＨを示す項目には、バスリセット前にデータ通信のために割り当てられていたチャネル番号が設定される。割当帯域を示す項目には、バスリセット前にデータ通信のために割り当てられていた帯域幅が設定される。

リソース割当テーブル２１１には、例えば、ＣＨが“３”、割当帯域が“１０００”という情報が設定される。これは、ソースノード２００がバスリセット前にチャネル番号“３”、使用帯域幅“１０００”のリソースを用いてデータ通信を行っていたことを示している。

ソースノード２００は、ＩＲＭノード１００がバスリセット前後でＩＲＭの役割を引き続き有している場合には、リソース割当テーブル２１１に記憶されたリソース情報に基づいて、他の装置とデータ通信を行うことができる。

図９は、ＰＨＹパケットの第１の構成例を示す図である。ＰＨＹパケット７００は、バスリセット後にＩＲＭノードがＩＲＭノード１００に決定すると、パケット処理部１６０により生成される。そして、送信部１８０を介してソースノード２００，３００，４００，５００に報知される。ＰＨＹパケット７００は、通信チャネルの利用状況を各ソースノードに通知するためのパケットである。ＰＨＹパケット７００は、固定値領域７０１、Ｐｈｙ＿ＩＤ領域７０２、固定値領域７０３、ｔｙｐｅ領域７０４、Ｃｈｉｐ＿ＩＤ領域７０５およびチャネル利用状況領域７０６が設けられている。これらの領域は、計３２ビットの情報により設定される。ＰＨＹパケット７００は、更にエラーチェック用に各ビットの論理反転（計３２ビット）を含む（図示せず）。

固定値領域７０１は、ＰＨＹパケット７００の先頭である。固定値領域７０１は、２ビットの情報領域であり、“００”が設定される
ｐｈｙ＿ＩＤ領域７０２は、６ビットの情報領域であり、ＩＲＭノード１００のｐｈｙ＿ＩＤが設定される。ｐｈｙ＿ＩＤは、バスリセットが発生すると、ネットワーク上の各ノードでの調停によって決まる値である。ＩＲＭノード１００のｐｈｙ＿ＩＤは、“５”であり、ｐｈｙ＿ＩＤ領域７０２には、“５”を示すビット列“０００１０１”が設定される。

固定値領域７０３は、２ビットの情報領域であり、“００”が設定される。
ｔｙｐｅ領域７０４は、４ビットの情報領域であり、パケットを識別するｔｙｐｅが設定される。チャネルの利用状況を示すＰＨＹパケットを識別するためのｔｙｐｅとして、例えば、“０ｘＢ”〜“０ｘＥ”という値を各ノード間で予め合意しておく。なお、“０ｘ”は、値が１６進数で表されていることを示す。ｔｙｐｅ領域７０４には、例えば、“０ｘＢ”を示すビット列“１０１１”が設定される。

Ｃｈｉｐ＿ＩＤ領域７０５は、例えば、８ビットの情報領域であり、ＩＲＭノード１００に付与されたＣｈｉｐ＿ＩＤ“２１５”を示すビット列“１１０１０１１１”が設定される。

チャネル利用状況領域７０６は、１０ビットまたは１８ビットの情報領域であり、チャネルの利用状況を示すビット列が設定される。チャネル数は、合計で６４チャネル存在するため、これを通知するために、ＩＲＭノード１００は計４つのＰＨＹパケットを生成して送信する。

すなわち、ｔｙｐｅが“０ｘＢ”であるＰＨＹパケット７１０には、Ｃｈｉｐ＿ＩＤが設定されると共に、５４〜６３チャネルの計１０チャネル分の利用状況が１０ビットのチャネル利用状況領域７０６に設定される。なお、パケットの先頭側からチャネル番号の大きい順に６３，６２，・・・，５４チャネルの順で設定されるものとする。ＰＨＹパケット７１０でＣｈｉｐ＿ＩＤを確認可能であるため、以降のＰＨＹパケットには、Ｃｈｉｐ＿ＩＤの設定は不要となる。

ｔｙｐｅが“０ｘＣ”であるＰＨＹパケット７２０には、Ｃｈｉｐ＿ＩＤは設定されず、３６〜５３チャネルの計１８チャネル分の利用状況が１８ビットのチャネル利用状況領域７０６に設定される。ＰＨＹパケット７３０，７４０もＰＨＹパケット７２０と同様の構成である。ＰＨＹパケット７３０には、１８〜３５チャネルの計１８チャネル分の利用状況が設定される。また、ＰＨＹパケット７４０には、０〜１７チャネルの計１８チャネル分の利用状況が設定される。なお、ＰＨＹパケット７２０，７３０，７４０に関してもＰＨＹパケット７１０と同様に、パケットの先頭側からチャネル番号の大きい順に設定される。

なお、チャネルの利用状況は、例えば、“１”が空き、“０”が割り当て済みを示す。具体的には、ＰＨＹパケット７１０であれば、チャネル利用状況領域７０６には、例えば、ビット列“１１０１１１１０１１”が設定される。これは、６１，５６チャネルは既に割り当て済みであり、それ以外のチャネルは空きであることを示している。

図１０は、ＰＨＹパケットの第２の構成例を示す図である。ＰＨＹパケット８００もＰＨＹパケット７００と同様のタイミングで生成され、ＰＨＹパケット７００と共にソースノード２００，３００，４００，５００に報知される。ＰＨＹパケット８００は、データ通信のための利用可能な帯域幅を各ソースノードに通知するためのパケットである。ＰＨＹパケット８００は、固定値領域８０１、Ｐｈｙ＿ＩＤ領域８０２、固定値領域８０３、ｔｙｐｅ領域８０４、Ｃｈｉｐ＿ＩＤ領域８０５および利用可能帯域８０６が設けられている。これらの領域は、計３２ビットの情報により設定される。ＰＨＹパケット８００は、更にエラーチェック用に各ビットの論理反転（計３２ビット）を含む（図示せず）。

固定値領域８０１は、ＰＨＹパケット８００の先頭である。固定値領域８０１は、２ビットの情報領域であり、“００”が設定される
ｐｈｙ＿ＩＤ領域８０２は、６ビットの情報領域であり、ＩＲＭノード１００のｐｈｙ＿ＩＤが設定される。ｐｈｙ＿ＩＤ領域８０２には、ＩＲＭノード１００のｐｈｙ＿ＩＤ“５”を示すビット列“０００１０１”が設定される。

固定値領域８０３は、２ビットの情報領域であり、“００”が設定される。
ｔｙｐｅ領域８０４は、４ビットの情報領域であり、パケットを識別するｔｙｐｅが設定される。利用可能な帯域幅を示すＰＨＹパケットを識別するためのｔｙｐｅとして、例えば、“０ｘ２”および“０ｘ４”という値を各ノード間で予め合意しておく。ｔｙｐｅ領域８０４には、例えば、“０ｘ２”を示すビット列“００１０”が設定される。

Ｃｈｉｐ＿ＩＤ領域８０５は、例えば、８ビットの情報領域であり、ＩＲＭノード１００のＣｈｉｐ＿ＩＤ“２１５”を示すビット列“１１０１０１１１”が設定される。
利用可能帯域８０６は、利用可能な帯域幅を示すビット列が設定される。

なお、ＩＲＭノード１００は、利用可能な帯域幅を通知するために計２つのＰＨＹパケットを生成して送信する。
すなわち、ｔｙｐｅが“０ｘ２”であるＰＨＹパケット８１０には、Ｃｈｉｐ＿ＩＤを設定する。そして、ＰＨＹパケット８１０の残りの１０ビットは、予約（Reserved）領域とする。そして、ｔｙｐｅが“０ｘ４”であるＰＨＹパケット８２０には、Ｃｈｉｐ＿ＩＤを設定せず、ｔｙｐｅ領域８０４に続けて利用可能帯域８０６を設定する。ＰＨＹパケット８２０には、例えば、利用可能な帯域幅“３９１５”を示す１３ビットのビット列“０１１１１０１００１０１１”が設定される。なお、１３ビットとして例示したのは、BANDWIDTH AVAILABLEレジスタにおいて利用可能な帯域幅を記憶する１３ビットの所定のbw-remaining領域に対応付けたためである。１３ビットに限らず他のビット長でも構わない。また、余りの領域に関しては、他の用途に用いても構わない。

次に、以上のような構成を備える通信システムにおいて実行される処理の詳細を説明する。
まず、通常時にＩＲＭノードで実行されるリソース情報の退避処理について説明する。なお、以下の説明では、ＩＲＭノード１００とソースノード２００との間の処理に関して説明するが、他のソースノードに関しても同様である。

図１１は、ＩＲＭノードのリソース情報退避処理の手順を示すフローチャートである。以下、図１１に示す処理をステップ番号に沿って説明する。
［ステップＳ１１］受信部１９０は、ソースノード２００からのＬｏｃｋリクエスト等のリソースの割当要求を受信するとパケット処理部１６０に出力する。パケット処理部１６０は、受信部１９０から取得するリソースの割当要求をリソース割当部１７０に出力する。リソース割当部１７０は、要求されたリソースの割り当てを制御し、割り当て結果に応じてリソース情報記憶部１１０に記憶されたリソース情報（チャネル管理テーブル１１１や帯域管理テーブル１１２）を更新する。

［ステップＳ１２］メモリ管理部１５０は、リソース情報記憶部１１０を参照して、リソース情報が更新されているか否かを判定する。更新されている場合、処理がステップＳ１３に移される。更新されていない場合、処理が完了する。

［ステップＳ１３］メモリ管理部１５０は、リソース情報記憶部１１０に記憶されたチャネル管理テーブル１１１および帯域管理テーブル１１２に基づいて、退避情報記憶部１２０に記憶された各テーブルの複製を最新の情報に更新する。

このようにして、ＩＲＭノード１００はチャネル管理テーブル１１１および帯域管理テーブル１１２を退避情報記憶部１２０に退避させておく。これにより、バスリセットが発生して、リソース情報記憶部１１０に記憶されたリソース情報がリセットされる場合にも、バスリセット前のリソース情報を保持しておくことができる。

次に、バスリセット後のＩＲＭノード１００およびソースノード２００のリソース割当処理に関して説明する。
図１２は、ＩＲＭノードのＰＨＹパケット送信処理の手順を示すフローチャートである。以下、図１２に示す処理をステップ番号に沿って説明する。

［ステップＳ２１］ＩＲＭ判定部１４０は、自装置がバスリセット前に引き続きＩＲＭノードであるか否かを判定する。引き続きＩＲＭノードである場合、メモリ管理部１５０がリソース情報記憶部１１０に記憶されたリソース情報をクリアして、処理がステップＳ２２に移される。前回ＩＲＭノードではなく、今回ＩＲＭノードの役割を新たに取得した場合、メモリ管理部１５０がリソース情報記憶部１１０に記憶されたリソース情報をクリアして、処理がステップＳ２３に移される。

［ステップＳ２２］メモリ管理部１５０は、退避情報記憶部１２０に記憶されたチャネル管理テーブル１１１および帯域管理テーブル１１２の複製を用いて、バスリセット前のリソース情報記憶部１１０のリソース情報を復元する。

［ステップＳ２３］パケット処理部１６０は、読み出し部１６５を介してリソース情報記憶部１１０に記憶されたリソース情報を取得する。そして、パケット処理部１６０は、自装置のＣｈｉｐ＿ＩＤおよび取得したリソース情報を用いて、ＰＨＹパケット７１０，７２０，７３０，７４０，８１０，８２０（以下では、ＰＨＹパケット群とする）を生成する。パケット処理部１６０は、生成したＰＨＹパケット群を送信部１８０に出力する。

［ステップＳ２４］送信部１８０は、パケット処理部１６０から取得するＰＨＹパケット群をソースノード２００，３００，４００，５００に報知する。
このようにして、ＩＲＭノード１００は、バスリセット前に引き続き自装置がＩＲＭの役割を有している場合、バスリセット前のリソース情報を含むＰＨＹパケットを報知する。また、バスリセット前に自装置がＩＲＭの役割を有していない場合には、メモリ管理部１５０によりクリア後のリソース情報を含むＰＨＹパケットを報知する。

図１３は、ソースノードのＰＨＹパケット受信処理の手順を示すフローチャートである。以下、図１３に示す処理をステップ番号に沿って説明する。以下の処理は、ソースノード２００において、図１２に示す処理に引き続き実行される。

［ステップＳ３１］受信部２３０は、ＩＲＭノード１００からＰＨＹパケット群を受信する。受信部２３０は、受信したＰＨＹパケット群をパケット処理部２４０に出力する。パケット処理部２４０は、受信部２３０から取得するＰＨＹパケット群からＣｈｉｐ＿ＩＤを抽出してＩＲＭ判定部２５０に出力する。

［ステップＳ３２］ＩＲＭ判定部２５０は、パケット処理部２４０から取得するＣｈｉｐ＿ＩＤとＩＲＭ記憶部２２０に記憶されたＣｈｉｐ＿ＩＤとを比較し、両者が同一であるか否か、すなわち、ＩＲＭノードが前回から変更しているか否かを判定する。変更していない場合、ＩＲＭ判定部２５０は、その旨をパケット処理部２４０に通知して処理がステップＳ３３に移される。変更している場合、ＩＲＭ判定部２５０は、その旨をパケット処理部２４０に通知して処理がステップＳ３４に移される。

［ステップＳ３３］パケット処理部２４０は、リソース割当記憶部２１０に記憶されたバスリセット前のリソース割当情報を利用可能なリソースとして設定する。
［ステップＳ３４］パケット処理部２４０は、ＩＲＭノード１００に対してリソースを取得するための処理を実行する。パケット処理部２４０は、ＩＲＭノード１００から新たに取得したリソース情報をリソース割当記憶部２１０に格納し、これを利用可能なリソースとして設定する。

［ステップＳ３５］送信部２６０は、リソース割当記憶部２１０に記憶された利用可能なリソースを用いて他のノードとのデータ通信を行う。
このようにして、ソースノード２００は、バスリセット前後でＩＲＭの役割を有するノードが変更していない場合には、バスリセット前に利用していたリソースを用いて、データ通信を開始することができる。すなわち、ＲｅａｄリクエストやＬｏｃｋリクエストによるリソース取得の手順を省くことができ、データ通信の開始までに発生し得る遅延を抑止することができる。

以下に、上記ステップＳ３４の処理を詳細に説明する。
図１４は、ソースノードのリソース取得処理の手順を示すフローチャートである。以下、図１４に示す処理をステップ番号に沿って説明する。なお、以下の処理は、上記ステップＳ３４の処理であり、すなわち、ＩＲＭノードがバスリセット前後で変更されている場合のソースノード２００のリソース取得処理の詳細を示したものである。

［ステップＳ４１］パケット処理部２４０は、ＰＨＹパケット群に含まれるリソース情報を参照して空きチャネル、利用可能帯域を取得し、空きリソースに応じたＬｏｃｋリクエストを生成する。パケット処理部２４０は、生成したＬｏｃｋリクエストを送信部２６０に出力する。

［ステップＳ４２］送信部２６０は、パケット処理部２４０から取得するＬｏｃｋリクエストをＩＲＭノード１００に送信する。
［ステップＳ４３］受信部１９０は、ソースノード２００からＬｏｃｋリクエストを受信する。受信部１９０は、受信したＬｏｃｋリクエストをパケット処理部１６０に出力する。

［ステップＳ４４］パケット処理部１６０は、受信部１９０からＬｏｃｋリクエストを取得すると、リソース割当部１７０にリソースの割り当てを指示する。リソース割当部１７０からリソースの割当結果（割り当てＯＫまたはＮＧ）を取得する。

［ステップＳ４５］リソース割当部１７０は、パケット処理部１６０から指示されたリソースの割り当てが可能か否かを判定する。可能である場合、リソース割当部１７０が、パケット処理部１６０に割り当てＯＫを通知して処理がステップＳ４６に移される。不可である場合、リソース割当部１７０が、パケット処理部１６０に割り当てＮＧを通知して処理がステップＳ４８に移される。

［ステップＳ４６］パケット処理部１６０は、ＯＫレスポンスを生成して送信部１８０に出力する。送信部１８０は、パケット処理部１６０から取得するＯＫレスポンスをソースノード２００に送信する。

［ステップＳ４７］受信部２３０は、ＩＲＭノード１００からＯＫレスポンスを受信する。受信部２３０は、受信したＯＫレスポンスをパケット処理部２４０に出力する。
［ステップＳ４８］パケット処理部１６０は、ＮＧレスポンスを生成して送信部１８０に出力する。送信部１８０は、パケット処理部１６０から取得するＮＧレスポンスをソースノード２００に送信する。

［ステップＳ４９］受信部２３０は、ＩＲＭノード１００からＮＧレスポンスを受信する。受信部２３０は、受信したＮＧレスポンスをパケット処理部２４０に出力する。
［ステップＳ５０］パケット処理部２４０は、ＩＲＭノード１００に対するＲｅａｄリクエストを生成して送信部２６０を介してＩＲＭノード１００に送信する。そして、パケット処理部２４０は、Ｒｅａｄリクエストに対するＲｅａｄレスポンスに基づいて、再度Ｌｏｃｋリクエストを生成して送信部２６０を介してＩＲＭノード１００に送信する。以降の処理は、ステップＳ４３と同様である。

［ステップＳ５１］パケット処理部２４０は、先のＬｏｃｋリクエスト生成時に要求したリソース情報をリソース割当記憶部２１０に格納し、これを利用可能なリソースとして設定する。

このようにして、ソースノード２００は、ＩＲＭノードがバスリセット前後で変更している場合にも、ＩＲＭノード１００から受信したＰＨＹパケットに基づいてＬｏｃｋリクエストを生成し、データ通信に用いるリソースを要求することができる。すなわち、Ｒｅａｄリクエストによるリソース利用状況の確認の手順を省くことができ、データ通信の開始までに発生し得る遅延を抑止することができる。

図１５は、バスリセット後のデータ通信開始までの処理の流れを示す第１のシーケンス図である。図１５で示す処理は、ＩＲＭノード１００がバスリセット後にも引き続きＩＲＭの役割を取得する場合を示している。以下、図１５に示す処理をステップ番号に沿って説明する。

［ステップＳ６１］ネットワーク上のトポロジ変化等に伴いバスリセットが発生する。
［ステップＳ６２］ＩＲＭノード１００が、バスリセット前に引き続きＩＲＭの役割を取得する。

［ステップＳ６３］ＩＲＭノード１００は、自装置が保持するリソース情報をクリアし、バスリセット前のリソース情報を復元する。
［ステップＳ６４］ＩＲＭノード１００は、ソースノード２００に、自装置のＣｈｉｐ＿ＩＤおよび自装置が保持するリソース情報に基づくＰＨＹパケットを送信する。なお、ＰＨＹパケットは、ネットワーク上の全てのソースノードに報知される。

［ステップＳ６５］ソースノード２００は、ＰＨＹパケットを受信し、ＰＨＹパケットに含まれるＣｈｉｐ＿ＩＤに基づいて、バスリセット前後でＩＲＭの役割を有するノードが変更していないと判定する。そして、ソースノード２００は、バスリセット前に割り当てられていたリソースを用いてソースノード３００に対するデータ送信を開始する。

このように、ソースノード２００は、ＩＲＭノード１００に対してリソースの取得要求を行うことなく迅速にデータ送信を開始することができる。なお、上記ステップＳ６３でリソース情報を復元することにより、その後、各ソースノードが利用するリソースの利用状況との整合性を保つことができる。

図１６は、バスリセット後のデータ通信開始までの処理の流れを示す第２のシーケンス図である。図１６で示す処理は、ＩＲＭノード１００が、バスリセット前にはソースノードであり、バスリセット後にＩＲＭの役割を取得する場合を示している。

［ステップＳ７１］ネットワーク上のトポロジ変化等に伴いバスリセットが発生する。
［ステップＳ７２］バスリセット前にはソースノードとして機能していたＩＲＭノード１００が、ＩＲＭの役割を取得する。

［ステップＳ７３］ＩＲＭノード１００は、自装置が保持するリソース情報をクリアし、自装置のＣｈｉｐ＿ＩＤおよびクリア後のリソース情報に基づくＰＨＹパケットをソースノード２００に送信する。

［ステップＳ７４］ソースノード２００は、ＰＨＹパケットを受信し、ＰＨＹパケットに含まれるＣｈｉｐ＿ＩＤに基づいて、バスリセット前後でＩＲＭの役割を有するノードが変更していると判定する。そして、ソースノード２００は、ＰＨＹパケットに含まれるリソース情報に基づくＬｏｃｋリクエストをＩＲＭノード１００に送信する。

［ステップＳ７５］ＩＲＭノード１００は、Ｌｏｃｋリクエストを受信し、Ｌｏｃｋリクエストで要求されているリソースを割り当てる。その後、ＩＲＭノード１００は、要求されたリソースの割り当てＯＫを示すＯＫレスポンスをソースノード２００に送信する。

［ステップＳ７６］ソースノード２００は、Ｌｏｃｋリクエストで要求したリソースを用いてソースノード３００に対するデータ送信を開始する。
このように、ＩＲＭノードがバスリセット前後で変更している場合でも、ＰＨＹパケットに含まれるリソース情報に基づいてＬｏｃｋリクエストを送信することができるため、迅速にデータ送信を開始することができる。

図１７は、バスリセット後のデータ通信開始までの処理の流れを示す第３のシーケンス図である。図１７で示す処理は、図１６と同様にＩＲＭノード１００が、バスリセット前にはソースノードであり、バスリセット後にＩＲＭの役割を取得する場合を示している。図１６と異なるのは、ソースノード２００が最初のＬｏｃｋリクエストでリソースを取得できない場合という点である。

［ステップＳ８１］ネットワーク上のトポロジ変化等に伴いバスリセットが発生する。
［ステップＳ８２］バスリセット前にはソースノードとして機能していたＩＲＭノード１００が、ＩＲＭの役割を取得する。

［ステップＳ８３］ＩＲＭノード１００は、自装置が保持するリソース情報をクリアし、自装置のＣｈｉｐ＿ＩＤおよびクリア後のリソース情報に基づくＰＨＹパケットをソースノード２００に送信する。

［ステップＳ８４］ソースノード２００は、ＰＨＹパケットを受信し、ＰＨＹパケットに含まれるＣｈｉｐ＿ＩＤに基づいて、バスリセット前後でＩＲＭの役割を有するノードが変更していると判定する。そして、ソースノード２００は、ＰＨＹパケットに含まれるリソース情報に基づくＬｏｃｋリクエストをＩＲＭノード１００に送信する。

［ステップＳ８５］ＩＲＭノード１００は、Ｌｏｃｋリクエストを受信し、Ｌｏｃｋリクエストで要求されているリソースが、既に他の通信で占有されている等により、割り当て不可であると判定する。ＩＲＭノード１００は、要求されたリソースの割り当てＮＧを示すＮＧレスポンスをソースノード２００に送信する。

［ステップＳ８６］ソースノード２００は、リソースの利用状況を確認するためにＩＲＭノード１００にＲｅａｄリクエストを送信する。
［ステップＳ８７］ＩＲＭノード１００は、ソースノード２００からのＲｅａｄリクエストに対して、リソースの利用状況を通知するＲｅａｄレスポンスを応答する。

［ステップＳ８８］ソースノード２００は、Ｒｅａｄレスポンスに基づくＬｏｃｋリクエストをＩＲＭノード１００に送信する。
［ステップＳ８９］ＩＲＭノード１００は、Ｌｏｃｋリクエストを受信し、Ｌｏｃｋリクエストで要求されているリソースを割り当てる。その後、ＩＲＭノード１００は、要求されたリソースの割り当てＯＫを示すＯＫレスポンスをソースノード２００に送信する。

［ステップＳ９０］ソースノード２００は、Ｌｏｃｋリクエストで要求したリソースを用いてソースノード３００に対するデータ送信を開始する。
このように、図１６におけるＬｏｃｋリクエストによってリソースを取得できなかった場合にも、Ｒｅａｄリクエストによってリソースの利用状況を確認し、再度Ｌｏｃｋリクエストを送信することができる。

このような通信システムによれば、バスリセット後にＩＲＭの役割を取得したＩＲＭノード１００によりＩＲＭノード１００を識別する識別情報がソースノード２００，３００，４００，５００に送信される。そして、ソースノード２００，３００，４００，５００は、バスリセット前後で管理ノードが変更していないと判定すると、バスリセット前にソースノード２００，３００，４００，５００に割り当てられていたリソースを用いて他のノードとのデータ通信を行う。

このため、バスリセット後に各ソースノード側からＩＲＭノード１００に対してリソースの利用状況を確認する必要がなくなり、また、利用状況に応じてリソースの取得要求を行う必要もなくなる。また、ＩＲＭノード１００に対するこれら要求の輻輳も防止される。このように、リソース取得のための処理ステップを削減し、ＩＲＭノード１００の処理負荷の増大を防止することで、データ通信の開始遅延を抑止することができる。

具体的には、従来の処理では、帯域４００ＭｂｐｓでＲｅａｄリクエストやＬｏｃｋリクエスト等のコマンドを送信したとしても、内部の処理等の影響もあり、１コマンドの送信当たり約１０ｍｓ（millisecond）かかっていた。すなわち、従来では、Ｒｅａｄリクエスト／レスポンス、Ｌｏｃｋリクエスト／レスポンスが送受信されるので、動画データ等の送信までに約４０ｍｓを要することになる。これは、動画の１フレームが、例えば、約１６．７ｍｓであるとすると２〜３フレーム分の映像が途切れることを示している。

これに対し、本実施の形態の通信システムでは、ＩＲＭノード１００がバスリセット前後で変わらなかった場合には、Ｒｅａｄリクエスト／レスポンス、Ｌｏｃｋリクエスト／レスポンスが省略される。このため、１０ｍｓ以下での動画データの送信開始が可能となる。このように、データ送信の開始遅延を１フレーム以内に抑えることで、動画データを途切れることなく再送することができる。

更に、ＩＲＭノード１００は、識別情報と共にリソースの利用状況をソースノード２００，３００，４００，５００に送信する。これにより、ＩＲＭノード１００がバスリセット前に管理ノードではなかった場合にも、各ソースノードは、取得したリソースの利用状況に基づいてＩＲＭノード１００にリソースの割当要求を行うことができる。これにより、各ソースノード側からＩＲＭノード１００に対するリソースの利用状況の確認の動作が不要となるため、バスリセット前後でＩＲＭノードが変更している場合にもデータ通信の開始遅延を抑止することができる。

以上、本件の通信システム、通信装置および通信方法を図示の実施の形態に基づいて説明したが、これらに限定されるものではなく、各部の構成は同様の機能を有する任意の構成のものに置き換えることができる。また、他の任意の構成物や工程が付加されてもよい。更に、前述した実施の形態のうちの任意の２以上の構成（特徴）を組み合わせたものであってもよい。

通信システムの概要を示す図である。 通信システムのシステム構成を示す図である。 ＩＲＭノードのハードウェア構成を示す図である。 ＩＲＭノードおよびソースノードの機能を示す図である。 チャネル管理テーブルのデータ構造例を示す図である。 帯域管理テーブルのデータ構造例を示す図である。 ＩＲＭ記憶テーブルのデータ構造例を示す図である。 リソース割当テーブルのデータ構造例を示す図である。 ＰＨＹパケットの第１の構成例を示す図である。 ＰＨＹパケットの第２の構成例を示す図である。 ＩＲＭノードのリソース情報退避処理の手順を示すフローチャートである。 ＩＲＭノードのＰＨＹパケット送信処理の手順を示すフローチャートである。 ソースノードのＰＨＹパケット受信処理の手順を示すフローチャートである。 ソースノードのリソース取得処理の手順を示すフローチャートである。 バスリセット後のデータ通信開始までの処理の流れを示す第１のシーケンス図である。 バスリセット後のデータ通信開始までの処理の流れを示す第２のシーケンス図である。 バスリセット後のデータ通信開始までの処理の流れを示す第３のシーケンス図である。

符号の説明

１，２，３，４ 通信装置
１ａ，２ｄ 送信部
２ａ リソース割当記憶部
２ｂ 受信部
２ｃ 判定部
Ｄ１ 識別情報

Claims (8)

1. 他の複数の通信装置とのリンクが再構築された後に、自装置が前記他の複数の通信装置が通信に用いるリソースの割り当てを管理する管理ノードとなった場合、前記他の複数の通信装置に自装置の識別情報を報知する第１の通信装置と、
   前記識別情報を受信すると、当該識別情報に基づいて前記リンクの再構築前後で前記管理ノードが変更しているか否かを判定し、前記管理ノードが変更していない場合、前記リンクの再構築前に割り当てられていたリソースを用いて他の通信装置との通信を行う第２の通信装置と、
   を有することを特徴とする通信システム。
2. 前記第１の通信装置は、
   自装置が前記管理ノードである場合、前記リソースの利用状況を示すリソース情報をリソース情報記憶部に格納し、前記リソース情報が前記リソースの割り当てに応じて更新されると当該リソース情報の複製を前記リンクの再構築前後で情報が保持される退避情報記憶部に退避し、
   前記リンクの再構築が発生した後も引き続き自装置が前記管理ノードとなった場合、前記退避情報記憶部に記憶された前記リソース情報の複製を用いて、前記リソース情報記憶部の前記リソース情報を復元する、
   ことを特徴とする請求項１記載の通信システム。
3. 前記第１の通信装置は、自装置が前記管理ノードとなった場合、前記識別情報と共に、リソースの利用状況を示すリソース情報を報知し、
   前記第２の通信装置は、前記管理ノードが前記リンクの再構築前後で変更している場合、前記リソース情報に基づいて前記第１の通信装置にリソース割当要求を送信し、当該要求に基づいてリソースを取得すると、取得したリソースを用いて他の通信装置との通信を行う、
   ことを特徴とする請求項１記載の通信システム。
4. 前記第１の通信装置は、前記識別情報および前記リソース情報を所定の物理パケットを用いて送信し、
   前記第２の通信装置は、前記リソース割当要求を所定のロックリクエストを用いて送信する、
   ことを特徴とする請求項３記載の通信システム。
5. 前記第１の通信装置は、前記リンクの再構築前は自装置が前記管理ノードでなく、かつ、前記リンクの再構築後に自装置が前記管理ノードとなった場合、前記リソースの利用状況を示すリソース情報を記憶するリソース情報記憶部に記憶された前記リソース情報を初期化する、
   ことを特徴とする請求項１記載の通信システム。
6. 他の複数の通信装置とのリンクが再構築された後に、自装置が前記他の複数の通信装置が通信に用いるリソースの割り当てを管理する管理ノードとなった場合、前記他の複数の通信装置に自装置の識別情報を報知する送信部を有することを特徴とする通信装置。
7. リンクの再構築前に割り当てられていた通信用のリソース割当情報を記憶するリソース割当記憶部と、
   前記リンクの再構築後に通信用のリソースの割り当てを管理する管理ノードから当該管理ノードの識別情報を受信する受信部と、
   前記受信部が受信した識別情報に基づいて、前記リンクの再構築前後で前記管理ノードが変更しているか否かを判定する判定部と、
   前記判定部が前記管理ノードが変更していないと判定すると、前記リソース割当記憶部に記憶された前記リソース割当情報に基づくリソースを用いて他の通信装置にデータを送信する送信部と、
   を有することを特徴とする通信装置。
8. 複数の通信装置が相互に通信する通信システムの通信方法において、
   第１の通信装置が、他の複数の通信装置とのリンクが再構築された後に、自装置が前記他の複数の通信装置が通信に用いるリソースの割り当てを管理する管理ノードとなった場合、前記他の複数の通信装置に自装置の識別情報を報知し、
   第２の通信装置が、前記識別情報を受信すると、当該識別情報に基づいて前記リンクの再構築前後で前記管理ノードが変更しているか否かを判定し、前記管理ノードが変更していない場合、前記リンクの再構築前に割り当てられていたリソースを用いて他の通信装置との通信を行う、
   ことを特徴とする通信方法。

Images