(57)【要約】【課題】空き容量を考慮した転送経路で情報を転送することができるストレージ装置を提供すること。【解決手段】ストレージ装置は、無線通信回路と、記憶装置と、コントローラとを備える。無線通信回路は、外部の第１装置に無線通信により接続する。記憶装置は、記憶領域を有する。コントローラは、第１装置との間の通信の品質を示す数値情報である第１情報を記憶装置の記憶領域の空き容量である第１容量に基づいて補正することによって補正された第１情報である第２情報を取得する。【選択図】図１７
2020046927.tif 000002
【特許請求の範囲】
【請求項１】
外部の第１装置に無線通信により接続する無線通信回路と、
記憶領域を有する記憶装置と、
前記第１装置との間の前記無線通信の品質を示す数値情報である第１情報を前記記憶装置の前記記憶領域の空き容量である第１容量に基づいて補正することによって補正された前記第１情報である第２情報を取得するコントローラと、
を備えるストレージ装置。
【請求項２】
前記第１装置から前記数値情報である第３情報を含む第１信号を受信した場合、前記コントローラは前記第３情報に前記第２情報を加算する、
請求項１に記載のストレージ装置。
【請求項３】
前記第１情報を補正する処理は、前記第１情報を前記第１容量と前記第１装置が備える記憶装置の記憶領域の空き容量である第２容量とに基づいて補正する処理である、
請求項１に記載のストレージ装置。
【請求項４】
前記第１情報を補正する処理は、前記第１情報を前記第１容量と前記第２容量との平均値で除算する処理を含む、
請求項３に記載のストレージ装置。
【請求項５】
前記無線通信回路は、前記第１装置と異なる外部の第２装置に無線通信により接続し、
前記コントローラは、前記第３情報を、前記第３情報に前記第２情報が加算されて得られる値で更新し、更新された後の前記第３情報を含む前記第１信号を前記第２装置に転送する、
請求項２に記載のストレージ装置。
【請求項６】
前記第１信号は、第３装置によって発行された信号であり、
前記コントローラは、前記第１装置をネクストホップとし、更新された後の前記第３情報をメトリックとして含む前記第３装置への経路情報を生成して保持する、
請求項５に記載のストレージ装置。
【請求項７】
前記無線通信回路は、前記第１装置および前記第２装置を含む複数の第４装置に無線で接続し、
前記コントローラは、データを要求する第２信号を受信し、当該第２信号のあて先が前記ストレージ装置である場合、前記第２信号に対する応答であり前記データを含む第３信号を生成し、前記複数の第４装置のうちの前記第３信号を中継する第５装置を前記経路情報に基づいて決定する、
請求項６に記載のストレージ装置。
【請求項８】
前記コントローラは、前記第３信号を受信した場合、当該受信した第３信号に含まれるデータのコピーを前記ストレージ装置が備える前記記憶装置に格納する、
請求項７に記載のストレージ装置。
【請求項９】
複数のストレージ装置が互いに無線通信により接続されて構成されるストレージネットワークを備え、
前記複数のストレージ装置それぞれは、前記無線通信の品質を示す数値情報である第１情報を前記複数のストレージ装置それぞれの記憶領域の空き容量に基づいて補正し、補正された前記第１情報である第２情報に基づいて前記ストレージネットワーク内の前記無線通信の経路を決定する、
ストレージシステム。
【請求項１０】
ユーザに接続されたゲートウェイをさらに備え、
前記ゲートウェイは、前記ユーザから前記複数のストレージ装置のうちの第１ストレージ装置が保持する第１データのリードを指示された場合、第１信号を送信し、
前記第１ストレージ装置は、前記複数のストレージ装置のうちの２以上の第２ストレージ装置に無線通信で接続し、前記第２情報に基づいて第１ルーティングテーブルを生成し、前記第１信号を受信すると、前記第１データを含む前記ゲートウェイをあて先とした第２信号を生成し、前記２以上の第２ストレージ装置のうちの前記第２信号を中継するストレージ装置を前記第１ルーティングテーブルに基づいて決定する、
請求項９に記載のストレージシステム。
【請求項１１】
前記複数のストレージ装置のうちの前記第２信号を中継する第３ストレージ装置は、前記第１データのコピーである第２データを生成して、前記第２データを保持する、
請求項１０に記載のストレージシステム。
【請求項１２】
前記ゲートウェイは、前記ユーザから前記第１データのリードが再び指示された場合、前記第３ストレージ装置をあて先とした第３信号を送信し、
前記第３ストレージ装置は、前記第３信号を受信すると、前記第２データを含む前記ゲートウェイをあて先とした第４信号を生成し、前記生成した第４信号を送信する、
請求項１１に記載のストレージシステム。
【請求項１３】
前記第３ストレージ装置は、第４ストレージ装置と第５ストレージ装置とを含み、
前記ゲートウェイは、前記ユーザから前記第１データのリードが再び指示された場合、前記第４ストレージ装置をあて先とした第３信号と、前記第５ストレージ装置をあて先とした第４信号と、を送信し、
前記第４ストレージ装置は、前記第３信号を受信すると、前記第２データのうちの一部を含む前記ゲートウェイをあて先とした第５信号を生成して送信し、
前記第５ストレージ装置は、前記第４信号を受信すると、前記第２データのうちの他の一部を含む前記ゲートウェイをあて先とした第６信号を送信する、
請求項１２に記載のストレージシステム。
【請求項１４】
前記第１ストレージ装置は、前記第２信号を送信中に前記複数のストレージ装置のうちの前記第２信号の転送経路上の一が無線通信不能になった場合、前記第１ルーティングテーブルを再生成し、再生成後の前記第１ルーティングテーブルに基づいて前記第２信号の送信を再開する、
請求項１０に記載のストレージシステム。
【請求項１５】
前記第３ストレージ装置は、前記第２データを保持したタイミングからの経過時間に基づくタイミングで前記第２データを削除する、
請求項１１に記載のストレージシステム。
【請求項１６】
前記ゲートウェイは、前記第１データのリードが指示された時間間隔に基づいて前記第１信号を送信するか第３信号を送信するかを決定し、
前記第３信号は、前記第１データを要求し、かつ前記第２データの保存を要求しない信号である、
請求項１１に記載のストレージシステム。
【請求項１７】
前記第１ストレージ装置は、前記第１情報に基づく第２ルーティングテーブルを生成し、前記第３信号を受信した場合、前記第１データを含む前記ゲートウェイをあて先とした第４信号を生成し、前記２以上の第２ストレージ装置のうちの前記第４信号を中継するストレージ装置を前記第２ルーティングテーブルに基づいて決定する、
請求項１６に記載のストレージシステム。
【請求項１８】
前記第１情報を補正する処理は、前記複数のストレージ装置のうちの互いに無線で接続された２つのストレージ装置の前記第１情報を前記２つのストレージ装置の記憶領域の空き容量の平均値で除算する処理を含む、
請求項９に記載のストレージシステム。
【請求項１９】
無線通信機能を有するストレージ装置に無線通信により接続された第１装置と前記ストレージ装置との間の無線通信の品質を示す数値情報である第１情報を前記ストレージ装置の記憶領域の空き容量である第１容量に基づいて補正することと、
前記補正された第１情報である第２情報を取得することと、
を備える方法。
【請求項２０】
複数のストレージ装置が互いに無線通信により接続されて構成されるストレージネットワークにおいて、前記無線通信の品質を示す数値情報である第１情報を前記複数のストレージ装置それぞれの記憶領域の空き容量に基づいて補正することと、
前記補正された第１情報である第２情報に基づいて前記ストレージネットワーク内の前記無線通信の経路を決定することと、
を備える方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本実施形態は、ストレージ装置、ストレージシステム、および方法に関する。
【背景技術】
【０００２】
無線LAN（Local  Area  Network）を用いたメッシュネットワークの構築には，IEEE  802.11sやRPL(Routing  Protocol  for  Low-Power  and  Lossy  Networks)といったルーティングプロトコルが採用される。
【０００３】
また、近年、無線通信装置を備えたＳＤメモリカードなど、無線LANを用いた通信が可能なストレージ装置が知られている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１６−５８９２２号公報
【特許文献２】国際公開第２０１５／０３３４５１号公報
【特許文献３】特表２０１２−５０６５８２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
一つの実施形態は、自身の記憶領域の空き容量を考慮した無線通信の転送経路で情報を転送することができるストレージ装置を提供することを目的とする。
【課題を解決するための手段】
【０００６】
一つの実施形態によれば、ストレージ装置は、無線通信回路と、記憶装置と、コントローラとを備える。無線通信回路は、外部の第１装置に無線通信により接続する。記憶装置は、記憶領域を有する。コントローラは、第１装置との間の無線通信の品質を示す数値情報である第１情報を記憶装置の記憶領域の空き容量である第１容量に基づいて補正することによって補正された第１情報である第２情報を取得する。
【図面の簡単な説明】
【０００７】
【図１】図１は、第１の実施形態のストレージシステムの構成の一例を示す図である。
【図２】図２は、第１の実施形態の１つのＷＳＤ(Wireless  SD)の運用形態の一例を示す図である。
【図３】図３は、第１の実施形態の１つのＷＳＤの構成の一例を示す図である。
【図４】図４は、第１の実施形態のゲートウェイの構成の一例を示す図である。
【図５】図５は、第１の実施形態のＷＳＤの第１ルーティングテーブルのデータ構成例を示す図である。
【図６】図６は、第１の実施形態のゲートウェイの第１ルーティングテーブルのデータ構成例を示す図である。
【図７】図７は、第１の実施形態のノード間の第２のメトリックの例を示す図である。
【図８】図８は、第１の実施形態の第２ルーティングテーブルのデータ構成例を示す図である。
【図９】図９は、第１の実施形態のファイル情報のデータ構造の一例を示す図である。
【図１０】図１０は、第１の実施形態のフレームの構成例を示す図である。
【図１１】図１１は、第１の実施形態のProactive  Path  Requestフレームの転送例を示す図である。
【図１２】図１２は、第１の実施形態のProactive  Path  Replyフレームの転送例を示す図である。
【図１３】図１３は、第１の実施形態のProactive  Path  Requestフレームの構成の一例を示す図である。
【図１４】図１４は、第１の実施形態のProactive  Path  Replyフレームの構成の一例を示す図である。
【図１５】図１５は、第１の実施形態のビーコンの構成の一例を示す図である。
【図１６】図１６は、第１の実施形態のノード間でビーコンが送受信される動作の一例を説明するための図である。
【図１７】図１７は、第２のメトリックを取得する第１の実施形態の方法の一例を示すフローチャートである。
【図１８】図１８は、第１の実施形態のProactive  Path  Requestを送信する動作の一例を示すフローチャートである。
【図１９】図１９は、第１の実施形態のProactive  Path  Requestを受信したノードの動作の一例を示すフローチャートである。
【図２０】図２０は、第１の実施形態のProactive  Path  Replyを受信したノードの動作の一例を説明するフローチャートである。
【図２１】図２１は、第１の実施形態のノード間の接続例を示す図である。
【図２２】図２２は、ＷＳＤ１０２がProactive  Path  Requestフレームに基づいて取得した第１の実施形態のルーティング情報の一例を示す図である。
【図２３】図２３は、ＷＳＤ１０２による書き換えの前後の第１の実施形態のProactive  Path  Requestを説明するための図である。
【図２４】図２４は、ＷＳＤ１０３がProactive  Path  Requestに基づいて取得した第１の実施形態のルーティング情報の一例を示す図である。
【図２５】図２５は、ＷＳＤ１０３が別のProactive  Path  Requestフレームに基づいて取得した第１の実施形態のルーティング情報の一例を示す図である。
【図２６】図２６は、ＷＳＤ１０３による書き換えの前後の第１の実施形態のProactive  Path  Requestを説明するための図である。
【図２７】図２７は、ＷＳＤ１０２が別のProactive  Path  Requestフレームに基づいて取得した第１の実施形態のルーティング情報の一例を示す図である。
【図２８】図２８は、ＷＳＤ１０５がProactive  Path  Requestに基づいて取得した第１の実施形態のルーティング情報の一例を示す図である。
【図２９】図２９は、ＷＳＤ１０５が別のProactive  Path  Requestに基づいて取得した第１の実施形態のルーティング情報の一例を示す図である。
【図３０】図３０は、ＷＳＤ１０６がProactive  Path  Requestに基づいて取得した第１の実施形態のルーティング情報の一例を示す図である。
【図３１】図３１は、ＷＳＤ１０８がProactive  Path  Requestに基づいて取得した第１の実施形態のルーティング情報の一例を示す図である。
【図３２】図３２は、ＷＳＤ１０９がProactive  Path  Requestに基づいて取得した第１の実施形態のルーティング情報の一例を示す図である。
【図３３】図３３は、ＷＳＤ１０２が生成して送信する第１の実施形態のProactive  Path  Replyを説明するための図である。
【図３４】図３４は、第１の実施形態のゲートウェイ２０１の第１ルーティングテーブルを示す図である。
【図３５】図３５は、ＷＳＤ１０３が生成して送信する第１の実施形態のProactive  Path  Replyを説明するための図である。
【図３６】図３６は、第１の実施形態のゲートウェイ２０１の第１ルーティングテーブル３１ｂを示す図である。
【図３７】図３７は、ＷＳＤ１０６が生成して送信する第１の実施形態のProactive  Path  Replyを説明するための図である。
【図３８】図３８は、ＷＳＤ１０３による書き換えの前後の第１の実施形態のProactive  Path  Replyを説明するための図である。
【図３９】図３９は、第１の実施形態のゲートウェイ２０１の第１ルーティングテーブル３１ｂを示す図である。
【図４０】図４０は、第１の実施形態のゲートウェイ２０１の完成した第１ルーティングテーブル３１ｂを示す図である。
【図４１】図４１は、第１の実施形態のリード要求フレームの構成の一例を示す図である。
【図４２】図４２は、第１の実施形態のリード応答フレームの構成の一例を示す図である。
【図４３】図４３は、第１の実施形態のリードアンドストア要求フレームの構成の一例を示す図である。
【図４４】図４４は、第１の実施形態のリードアンドストア応答フレームの構成の一例を示す図である。
【図４５】図４５は、第１の実施形態のステータス要求フレームの構成の一例を示す図である。
【図４６】図４６は、第１の実施形態のステータス応答フレームの構成の一例を示す図である。
【図４７】図４７は、ファイルのライトの際のゲートウェイ２００の第１の実施形態の動作の一例を説明するフローチャートである。
【図４８】図４８は、ライト要求のあて先のＷＳＤ１００（対象ＷＳＤ１００）の第１の実施形態の動作の一例を示すフローチャートである。
【図４９】図４９は、ファイル＃１が対象ファイルであり、ＷＳＤ１０３が対象ＷＳＤである場合に、図４７の処理と図４８の処理とが完了した時点のストレージシステム１の状態を説明するための模式図である。
【図５０】図５０は、ファイルのリードの際のゲートウェイの第１の実施形態の動作の一例を説明するフローチャートである。
【図５１】図５１は、ファイルのリードの際の要求（リード要求またはリードアンドストア要求）のあて先のＷＳＤ１００（対象ＷＳＤ１００）の動作の一例を示すフローチャートである。
【図５２】図５２は、ファイルのリードの際の応答を中継するＷＳＤ１００の第１の実施形態の動作の一例を示すフローチャートである。
【図５３】図５３は、ファイル＃１がＷＳＤ１０３に保持され、ゲートウェイ２０２がＷＳＤ１０３にファイル＃１のリードをリードアンドストア要求によって要求した場合にファイル＃１のコピーが生成・保存される様子を示す図である。
【図５４】図５４は、ＷＳＤ１００がファイルのコピーを消去する第１の実施形態の動作の一例を示すフローチャートである。
【図５５】図５５は、第２の実施形態のゲートウェイ２０２によって確認された転送経路を説明するための図である。
【図５６】図５６は、第３の実施形態のＷＳＤ１０６が通信不能となった場合のストレージシステム１の状態を示す模式図である。
【図５７】図５７は、再生成された第３の実施形態の第２ルーティングテーブル３２を示す図である。
【図５８】図５８は、ファイル＃１を含むリードアンドストア応答を送信完了した後の第３の実施形態のストレージシステム１の状態を示す模式図である。
【図５９】図５９は、第３の実施形態のゲートウェイ２０２によって確認されたファイル＃１の所有者を説明するための図である。
【発明を実施するための形態】
【０００８】
以下に添付図面を参照して、実施形態にかかるストレージ装置、ストレージシステム、および方法を詳細に説明する。なお、これらの実施形態により本発明が限定されるものではない。
【０００９】
（第１の実施形態）
（１）ストレージシステムの構成
（１−１）基本的な構成
図１は、第１の実施形態のストレージシステムの構成の一例を示す図である。ストレージシステム１は、無線通信を可能に構成された複数のストレージ装置（Wireless  Storage  Device:  ＷＳＤ）１００と１以上のゲートウェイ（gateway）２００とを備える。
【００１０】
図１には、複数のストレージ装置１００の一例として、９個のストレージ装置１０１〜１０９が示されている。また、１以上のゲートウェイ２００の一例として、２つのゲートウェイ２０１、２０２が示されている。
【００１１】
ストレージ装置１００間、ストレージ装置１００とゲートウェイ２００との間の実線は、無線の通信経路を示している。複数のストレージ装置１００と１以上のゲートウェイ２００とが互いに無線で通信可能に接続されることによって、メッシュネットワークが形成されている。このメッシュネットワークのうちの、複数のストレージ装置１００のみによって構成される部分を、ストレージネットワークと表記することがある。
【００１２】
各ゲートウェイ２００は、複数のストレージ装置１００のうちの１以上のストレージ装置１００に、無線で通信可能に接続されている。本図の例では、ゲートウェイ２０１は、ストレージ装置１０１〜１０３に接続され、ゲートウェイ２０２は、ストレージ装置１０１、１０４、１０７に接続されている。
【００１３】
各通信経路には、メトリック（Metric:  MTR）が図示されている。メトリックは、通信の品質を示す数値情報である。メトリックが小さいことは、通信の品質が優れていることを示す。つまり、メトリックが小さいほど、転送に要する時間が短い。
【００１４】
無線LANを用いたメッシュネットワークの規格であるIEEE  802.11sによれば、メトリック“Ｃａ１”は、下記の式（１）によって得られる。
【数１】
2020046927.tif 000003
【００１５】
ただし、“Ｏ”は、ＰＬＣＰヘッダ、ＰＬＣＰプリアンブル、ＲＴＳ、ＣＴＳ、などの通信の際に発生するオーバーヘッドの合計をマイクロ秒の単位で表した値である。“Ｂｔ”は、定数であり、例えば８１９２である。“ｒ”は、Ｍｂｐｓの単位で表した送信ＰＨＹレートである。“ef”は、パーセントの単位で表したフレームエラーレートである。
【００１６】
実施形態では、通信の品質を表す数値情報が、第１のメトリックとして使用される。第１のメトリックは、例えば式（１）によって得られる数値情報である。実施形態では、さらに、第１のメトリックに加えて、第１のメトリックをストレージの空き容量に基づいて補正して得られる第２のメトリックが使用される。第２のメトリックの詳細については後述する。
【００１７】
また、図１では、各ストレージ装置１００のそれぞれに、ストレージ（図３のストレージ２０）の空き容量が図示されている。また、各ゲートウェイ２００には、ストレージの空き容量として、“０ＧＢｙｔｅ”が図示されている。
【００１８】
なお、ストレージの空き容量とは、より厳密には、ユーザ３００から送られてきたデータが格納可能な記憶領域の空き領域である。ここでは、各ストレージ装置１００は、まだユーザ３００からのデータが格納されていない状態になっていることとする。すなわち、この時の空き容量は表記容量に等しいこととする。各ストレージ装置１００のストレージの空き容量は、データが格納されると、その分だけ減少する。
【００１９】
各ゲートウェイ２００は、ストレージシステム１に対してデータの格納やデータの読み出しを指示する１以上のユーザ３００が接続される。ここでは一例として、ゲートウェイ２０１には、２つのユーザ３００としてユーザ３０１およびユーザ３０２が接続されている。ゲートウェイ２０２には、３つのユーザ３００としてユーザ３０３〜３０５が接続されている。
【００２０】
ユーザ３００は、例えば、コンピュータである。ユーザ３００は、ゲートウェイ２００に対して無線で接続されてもよいし、有線で接続されてもよい。ユーザ３００は、ネットワークハブやルータなどを介してゲートウェイ２００に接続されてもよい。
【００２１】
ユーザ３００は、自身に接続されたゲートウェイ２００に対して指示を送る。ユーザ３００は、ストレージネットワークを構成するストレージ装置１００の数や、ストレージネットワークのネットワークトポロジを意識する必要がない。
【００２２】
以降、ゲートウェイ２００やストレージ装置１００を、ノードと表記する場合がある。また、あるノードに着目した場合において、当該ノードに無線で通信可能に接続された別のノードを、隣接ノードと表記する場合がある。また、ストレージ装置１００を、ＷＳＤ１００と略す場合がある。また、あるＷＳＤ１００に着目した場合において、当該ＷＳＤ１００に無線で通信可能に接続された別のＷＳＤ１００を、隣接ＷＳＤ１００と表記する場合がある。また、接続されるとは、特に断りがない限り、無線で通信可能に接続されていることをいう。
【００２３】
また、第１のノードが第２のノードに宛てた情報を生成（発行）して送信する場合、第１のノードを、発行元、発行元のノード、送信元、または送信元のノードと表記する。第２のノードを、あて先、あて先のノードと表記する。
【００２４】
また、第１のノードが第２のノードと直接に接続されてない場合、第２のノードに宛てた情報は、第３のノードを経由して第２のノードに到達する。第３のノードを、中継ノードと表記する。また、中継ノードがＷＳＤ１００である場合、その中継ノードを、中継ＷＳＤ１００と表記する。
【００２５】
また、第１のノードから第２のノードまでの情報の経路を、転送経路と表記する。また、互いに隣接する２つのノード間で情報を送受信する動作を、転送と表記する。
【００２６】
また、互いに隣接する２つのノードのうちの一のノードが他のノードに情報を転送する場合において、当該一のノードを転送元、または転送元のノードと表記する。また、当該他のノードを、転送先、または転送先のノードと表記する。
【００２７】
また、以降の説明では、ユーザ３００からのデータは、一例として、ファイル単位で管理されることとする。ユーザ３００からのデータの管理の単位は、ファイルでなくてもよい。
【００２８】
また、以降の説明では、無線の通信方式の一例として、802.11sをベースとした方式が適用される場合について述べる。実施形態の技術に使用できる無線の通信方式はこれに限定されない。
【００２９】
また、第１のメトリックの算出方法は、式（１）を用いた方法に限定されない。第１のメトリックを算出するための式は、規格やネットワークの利用目的に応じて変形され得る。
【００３０】
また、ストレージネットワークを構成するストレージ装置１００の数は、９個に限定されない。ストレージネットワークを構成するストレージ装置１００の数は、静的に、または動的に、変更され得る。
【００３１】
また、ストレージシステム１を構成するゲートウェイ２００の数は、２個に限定されない。ストレージシステム１を構成するゲートウェイ２００の数は、静的に、または動的に、変更され得る。
【００３２】
（１−２）ストレージ装置（ＷＳＤ）１００の構成
図２は、１つのＷＳＤ１００の運用形態の一例を示す図である。本実施形態では、ＷＳＤ１００は、例えば、無線通信機能を備えたＳＤメモリカードである。
【００３３】
ＷＳＤ１００は、カードリーダ４００に接続される。カードリーダ４００は、モバイルバッテリ５００に接続されている。ＷＳＤ１００は、カードリーダ４００を介してモバイルバッテリ５００から供給される電力によって駆動される。この運用形態では、ＷＳＤ１００に対するカードリーダ４００を介したデータの入出力は実行されない。カードリーダ４００とモバイルバッテリ５００とは、単に、ＷＳＤ１００に対して電力を供給する手段としてのみ機能する。
【００３４】
例えば、それぞれＷＳＤ１００、カードリーダ４００、およびモバイルバッテリ５００を含む９個のセットが、１つの建物の１つのフロアを均一にカバーするように設置されることで、図１に示したストレージネットワークが形成される。
【００３５】
なお、ＷＳＤ１００は、ＳＤメモリカードに限定されない。無線通信機能とストレージとを備える任意の装置が、実施形態のＷＳＤ１００として使用され得る。また、ＷＳＤ１００に電力を供給する手段は、上記した手段に限定されない。ＷＳＤ１００には、任意の方法で電力が供給され得る。
【００３６】
図３は、１つのＷＳＤ１００の構成の一例を示す図である。ＷＳＤ１００は、コントローラ１０と、ストレージ２０と、を備える。
【００３７】
ストレージ２０は、ＷＳＤ１００が備える記憶装置である。つまり、ストレージ２０には、ストレージシステム１がユーザ３００から受信したデータが格納される。
【００３８】
ストレージ２０を構成する記憶装置の種類は、特定の種類に限定されない。例えば、ストレージ２０は、ＮＡＮＤ型フラッシュメモリ、ＮＯＲ型フラッシュメモリ、ＲｅＲＡＭ（Resistive  Random  Access  Memory）、ＭＲＡＭ（Magnetoresistive  Random  Access  Memory）、磁気ディスク装置、など、任意の種類の記憶装置によって構成され得る。ストレージ２０は、不揮発性であってもよいし、不揮発性でなくてもよい。
【００３９】
コントローラ１０は、隣接ノードから転送されてきた各種要求や各種応答を別の隣接ノードに転送する処理、隣接ノードから転送されてきた各種要求に応じてストレージ２０にアクセスする処理、及び隣接ノードから転送されてきた各種要求に応答する処理、を実行する。アクセスは、データのライト、データのリード、およびデータのイレースを含む。
【００４０】
コントローラ１０は、具体的には、デバイスコントローラ１１、ＣＰＵ（Central  Processing  Unit）１２、無線通信装置（無線通信回路）１３、ＲＡＭ（Random  Access  Memory）１４、およびホストコントローラ１５を備える。コントローラ１０は、半導体集積回路である。
【００４１】
無線通信装置１３は、他のノードと電波を用いた通信を行うための通信装置である。無線通信装置１３は、他のノードとの間で、情報を、フレームと呼ばれる単位で送受信する。フレームとして送受信される情報は、データや、各種要求や、各種応答を含む。情報の処理は、ＣＰＵ１２によって実行される。
【００４２】
デバイスコントローラ１１は、ホストと有線で接続するためのインタフェース装置である。ホストは、単体のＷＳＤ１００を補助記憶装置として使用する装置である。ホストは、例えば、デジタルスチルカメラである。
【００４３】
デバイスコントローラ１１は、複数のピンを含むコネクタを備えている。コネクタは、データの入出力ピンやＷＳＤ１００の制御信号の入出力ピンのほかに、電力供給のためのピンを含んでいる。デバイスコントローラ１１は、モバイルバッテリ５００などから供給される電力を、そのまま、または変換して、ＷＳＤ１００が備える各種の構成要素に供給することができる。
【００４４】
なお、実施形態では、ＷＳＤ１００は、デバイスコントローラ１１がホストに接続されてない状態で運用される。電力を供給する手段にデバイスコントローラ１１が接続されていれば十分である。すなわち、実施形態にかかるＷＳＤ１００は、２つの通信手段（デバイスコントローラ１１／無線通信装置１３）を具備し、特に無線通信装置１３を経由して通信する。
【００４５】
ホストコントローラ１５は、ストレージ２０にアクセスするためのインタフェース装置である。
【００４６】
ＲＡＭ１４は、ＣＰＵ１２にワークエリアとしての機能を提供する記憶装置である。ＲＡＭ１４の種類は、特定の種類の記憶装置に限定されない。例えば、ＲＡＭ１４は、ＤＲＡＭ（Dynamic  Random  Access  Memory）、ＳＲＡＭ（Static  Random  Access  Memory）、またはこれらの組み合わせであってもよい。
【００４７】
ＲＡＭ１４には、第１ルーティングテーブル３１ａ、第２ルーティングテーブル３２、およびファイル情報３３が格納される。第１ルーティングテーブル３１ａ、第２ルーティングテーブル３２、および後述する第１ルーティングテーブル３１ｂを総称して、ルーティングテーブル３４と表記することがある。ＲＡＭ１４に格納されるこれらの情報の詳細は後述する。
【００４８】
ＣＰＵ１２は、コンピュータプログラムを実行可能なプロセッサである。ＣＰＵ１２は、ファームウェア（ファームウェアプログラム）を実行することによって、ＷＳＤ１００を制御する機能を実現する。コントローラ１０が行う処理は、ＣＰＵ１２によって実現される。
【００４９】
なお、コントローラ１０は、ＡＳＩＣ（application  specific  integrated  circuit）やＦＰＧＡ（field-programmable  gate  array）などのハードウェア回路を備え、ＷＳＤ１００を制御する機能のうちの一部または全部は、ハードウェア回路によって実現されてもよい。つまり、コントローラ１０の機能は、ソフトウェア、ハードウェア、またはこれらの組み合わせによって実現され得る。
【００５０】
また、コントローラ１０は、ＳｏＣ（System-on-a-chip）として構成されてもよい。コントローラ１０は、複数のチップによって構成されてもよい。
【００５１】
（１−３）ゲートウェイ２００の構成
図４は、実施形態のゲートウェイ２００の構成の一例を示す図である。ゲートウェイ２００は、ＣＰＵ４１、無線通信装置４２、メモリ４３、および有線通信装置４４を備える。
【００５２】
ＣＰＵ４１は、所定のコンピュータプログラムに基づき、ゲートウェイ２００の機能を実現する。
【００５３】
無線通信装置４２は、他のノードやユーザ３００と電波を用いた通信を行うための無線通信装置である。有線通信装置４４は、ユーザ３００と有線での通信を行うための装置である。ゲートウェイ２００は、ユーザ３００と、無線通信装置４２または有線通信装置４４を用いて通信する。
【００５４】
メモリ４３は、揮発性のメモリ、不揮発性のメモリ、またはこれらの組み合わせによって構成される。
【００５５】
実施形態ではメモリ４３には第１ルーティングテーブル３１ｂが格納される。第１ルーティングテーブル３１ｂの詳細は後述する。第１ルーティングテーブル３１ｂと、前記した第１ルーティングテーブル３１ａおよび第２ルーティングテーブル３２とを総称して、ルーティングテーブル３４と表記することがある。
【００５６】
ゲートウェイ２００は、ユーザ３００からの指示に応じた要求を生成して、生成した要求をあて先のＷＳＤ１００に送信することができる。ユーザ３００からの指示に応じた要求は、ライト要求やリード要求などを含む。
【００５７】
ライト要求は、あて先のＷＳＤ１００に、データをストレージ２０に格納させるための要求である。リード要求は、あて先のＷＳＤ１００に、データをストレージ２０から読み出させて当該データを応答として出力させるための要求である。
【００５８】
実施形態では、ゲートウェイ２００は、さらに、リードアンドストア要求を生成して送信することができる。リードアンドストア要求は、あて先のＷＳＤ１００に、データをストレージ２０から読み出させて当該データを応答として出力させるとともに、当該応答を中継するＷＳＤ１００に、当該データをストレージ２０に格納させるための要求である。
【００５９】
ゲートウェイ２００は、同じデータのリードが複数回、指示された場合、当該指示の時間間隔に応じて、リード要求を発行するかリードアンドストア要求を発行するかを決定する。
【００６０】
あるデータのリードが指示された時間の間隔が所定値を下回っている場合、ゲートウェイ２００は、当該データを対象としたリードアンドストア要求を発行する。また、ゲートウェイ２００は、あるデータのリードが指示された時間の間隔が所定値を越えている場合、当該データを対象としたリード要求を発行する。
【００６１】
リードアンドストア要求によれば、リードが指示されたデータのコピーが、応答の転送経路上の各中継ノード（ＷＳＤ１００）に格納される。ゲートウェイ２００は、リードアンドストア要求を発行した後に、さらに当該データをリードする指示を受領した場合、当該データまたは当該データのコピーを保持する複数のＷＳＤ１００のうちから、リード要求（またはリードアンドストア要求）のあて先を決定することができる。
【００６２】
同じデータをリードする指示の頻度が高い場合、そのデータを保持するＷＳＤ１００に処理が集中し、その結果として、ストレージシステム１のスループットが低下する。
【００６３】
実施形態では、同じデータをリードする指示の頻度が高い場合、そのデータを保持するＷＳＤ１００の数が増やされる。これによって、以降にそのデータのリードが指示された場合であっても、１つのＷＳＤ１００に処理が集中することが防止される。これによって、ストレージシステム１のスループットの低下が抑制される。
【００６４】
リードアンドストア要求とその応答などについての詳細な説明は、後述する。
【００６５】
（１−４）第１ルーティングテーブル３１ａ、３１ｂ
メッシュネットワークにおいては、発行元からあて先までの転送経路上の各ノードは、接続された１以上の隣接ノードのうちのどのノードに転送すればよいかを知る必要がある。接続された１以上の隣接ノードのうちの転送先のノードは、ネクストホップと呼ばれる。
【００６６】
第１ルーティングテーブル３１ａ、３１ｂは、第１のメトリックを最小にすることができる転送経路でフレームを転送するためのネクストホップを示す情報である。つまり、あて先への存在し得る１以上の転送経路のうちの、第１のメトリックが最小である転送経路を構成する隣接ノードのみが第１ルーティングテーブル３１ａ、３１ｂに記録される。
【００６７】
図５は、第１ルーティングテーブル３１ａのデータ構成例を示す図である。本図は、ＷＳＤ１０３が備える第１ルーティングテーブル３１ａを示している。
【００６８】
図５に示されるように、第１ルーティングテーブル３１ａは、複数のレコードを備え得る。各レコードは、あて先のノード（“Destination”）、ネクストホップ（“Next  Hop”）、第１のメトリック（“First  Metric”）、およびあて先のノードのストレージ２０の空き容量とを含んでいる。あて先がゲートウェイ２０２であるレコードには、空き容量として０Ｇｂｙｔｅが設定されている。
【００６９】
図１の例に従えば、あて先がゲートウェイ２０２である場合、ＷＳＤ１０３からＷＳＤ１０６、ＷＳＤ１０５、およびＷＳＤ１０４をこの順番で経由してゲートウェイ２０２に至る転送経路において、第１のメトリックの合計が「４０」となる。他の転送経路の場合、第１のメトリックの合計は、「４０」を越える。
【００７０】
よって、図５の例に示されるように、ＷＳＤ１０３の第１ルーティングテーブル３１ａのゲートウェイ２０２のレコードには、ネクストホップとしてＷＳＤ１０６が記録され、第１のメトリックとして「４０」が記録される。
【００７１】
ＷＳＤ１０３は、あて先がゲートウェイ２０２であるフレームを受信した場合、図５に示される第１ルーティングテーブル３１ａに基づき、ＷＳＤ１０６を当該フレームの転送先（すなわち、ネクストホップ）として特定することができる。
【００７２】
各ノードは、自身が保持する第１ルーティングテーブル３１ａ、３１ｂに基づいて転送先を決定することによって、第１のメトリックを最小にすることができる転送経路に沿ったフレームの転送を実現する。
【００７３】
図６は、第１ルーティングテーブル３１ｂのデータ構成例を示す図である。本図は、ゲートウェイ２０１が備える第１ルーティングテーブル３１ｂを示している。第１ルーティングテーブル３１ｂは、第１ルーティングテーブル３１ａと同様のデータ構造を有している。
【００７４】
即ち、第１ルーティングテーブル３１ｂは、複数のレコードを備え得る。各レコードは、あて先のノード、ネクストホップ、第１のメトリック、およびあて先のノードのストレージ２０の空き容量とを含んでいる。あて先がゲートウェイ２０２であるレコードには、空き容量として０Ｇｂｙｔｅが設定されている。
【００７５】
つまり、第１ルーティングテーブル３１ｂには、あて先のノードに情報を送信する場合に第１のメトリックを最小とするための転送先が記録されている。
【００７６】
ゲートウェイ２０１は、図６に示される第１ルーティングテーブル３１ｂに従って転送先を決定する。これによって、隣接ノードのうちの第１のメトリックが最小になる転送経路を構成するノードにフレームが転送される。
【００７７】
（１−５）第２のメトリック
第２のメトリックは、第１のメトリックをストレージ２０の容量に基づいて補正することによって得られる。例えば、第２のメトリックは、下記の式（２）によって得られる。
【数２】
2020046927.tif 000004
【００７８】
ただし、“Ｃａ１”は、第１のメトリックである。“Ｓｍ”は、ＷＳＤ１０１〜１０９の表記容量のうちの最大の容量である。“Ｓａ”は、隣接する２つのノードそれぞれの空き容量の平均値である。
【００７９】
隣接する２つのノード間の接続毎に第２のメトリックが式（２）を用いて演算される。図７に示される、隣接する２つのノード間に記載されたそれぞれの数値は、第２のメトリックを示している。
【００８０】
具体例として、ＷＳＤ１０６とＷＳＤ１０９との間の第２のメトリックを求め方について説明する。
【００８１】
ＷＳＤ１０１〜１０９の表記容量のうちの最大の容量は、例えばＷＳＤ１０７、ＷＳＤ１０８、ＷＳＤ１０９の空き容量としても示されている６４［ＧＢｙｔｅ］とする。つまり、“Ｓｍ”は、６４［ＧＢｙｔｅ］である。
【００８２】
また、ＷＳＤ１０６の空き容量は１６［ＧＢｙｔｅ］であり、ＷＳＤ１０９の空き容量は６４［ＧＢｙｔｅ］である。よって、“Ｓａ”は、４０（＝（１６＋６４）／２）［ＧＢｙｔｅ］である。
【００８３】
また、ＷＳＤ１０６とＷＳＤ１０９との間の第１のメトリック“Ｃａ１”は、図１に示すように１０である。
【００８４】
これらの値が式（２）に代入されることで、ＷＳＤ１０６とＷＳＤ１０９との間の第１のメトリック“Ｃａ２”として、１６（＝１０×６４／４０）を得ることができる。
【００８５】
このように、第２のメトリックを演算する処理は、第１のメトリックを、隣接する２つのノードの空き容量の平均値で除算する処理を含んでいる。よって、第２のメトリックが小さいことは、通信の品質が優れていることか、または転送元および転送先の空き容量が大きいことを意味することになる。
【００８６】
なお、式（２）は、第１のメトリックを空き容量に基づいて補正する処理の一例である。第１のメトリックを空き容量に基づいて補正する処理は、これに限定されない。
【００８７】
例えば、第１のメトリックを、隣接する２つのノードそれぞれの空き容量の合計値で除算することによって第２のメトリックを演算してもよい。または、第１のメトリックを、２つの互いに隣接するノードのうちの一方の空き容量で除算することによって第２のメトリックを演算してもよい。つまり、第１のメトリックが空き容量に基づいて補正される限り、任意の方法で第２のメトリックが算出され得る。
【００８８】
（１−６）第２ルーティングテーブル３２
第２ルーティングテーブル３２は、第１のメトリックの替わりに第２のメトリックに基づいて生成されている点で、第１ルーティングテーブル３１ａ、３１ｂと異なっている。
【００８９】
つまり、第２ルーティングテーブル３２は、第２のメトリック（より詳しくは第２のメトリックの合計）を最小にすることができる転送経路でフレームを転送するためのネクストホップを示す情報である。あて先への存在し得る１以上の転送経路のうちの、第２のメトリックが最小である転送経路を構成する隣接ノードのみが第２ルーティングテーブル３２に記録される。
【００９０】
図８は、第２ルーティングテーブル３２のデータ構成例を示す図である。本図は、ＷＳＤ１０３が備える第２ルーティングテーブル３２を示している。
【００９１】
図８に示されるように、第２ルーティングテーブル３２は、複数のレコードを備え得る。各レコードは、あて先のノード（“Destination”）、ネクストホップ（”Next  Hop”）、第２のメトリック（“Second  Metric”）、およびあて先のノードのストレージ２０の空き容量とを含んでいる。あて先がゲートウェイ２０２であるレコードには、空き容量として０Ｇｂｙｔｅが設定されている。
【００９２】
図７の例に従えば、あて先がゲートウェイ２０２である場合、ＷＳＤ１０３からＷＳＤ１０６、ＷＳＤ１０９、ＷＳＤ１０８、およびＷＳＤ１０７をこの順番で経由してゲートウェイ２０２に至る転送経路において、第２のメトリックの合計が「１２２」となる。他の転送経路の場合に第２のメトリックの合計は、「１２２」を越える。
【００９３】
よって、図８の例に示されるように、第２ルーティングテーブル３２の、あて先がゲートウェイ２０２であるレコードには、ネクストホップとしてＷＳＤ１０６が記録され、第２のメトリックとして「１２２」が記録される。
【００９４】
第１ルーティングテーブル３１ａは、通信の品質のみを考慮した第１のメトリックに基づいて生成されていることに対し、第２ルーティングテーブル３２は、通信の品質だけでなくストレージ２０の空き容量をも考慮して生成されている。よって、各ノードが第２ルーティングテーブル３２を用いてフレームの転送先を特定することによって、第１ルーティングテーブル３１ａを用いた場合と比較して、当該フレームを空き容量が大きいノードをできるだけ優先的に経由させることが可能となる。
【００９５】
例えば、ＷＳＤ１０３からゲートウェイ２０２にフレームが転送される場合、図５に示された第１ルーティングテーブル３１ａによれば、ＷＳＤ１０３からＷＳＤ１０６、ＷＳＤ１０５、およびＷＳＤ１０４をこの順番で経由してゲートウェイ２０２に至る転送経路が使用される。この転送経路は、通信の品質が最も優れた転送経路である。
【００９６】
これに対し、図７のメトリックと図８に示された第２ルーティングテーブル３２によれば、前述したように、ＷＳＤ１０３からＷＳＤ１０６、ＷＳＤ１０９、ＷＳＤ１０８、およびＷＳＤ１０７をこの順番で経由してゲートウェイ２０２に至る転送経路が使用される。この転送経路によれば、第１ルーティングテーブル３１ａが使用される場合の転送経路に比べて通信の品質が劣るものの、空き容量が大きいＷＳＤ１０９、ＷＳＤ１０８、およびＷＳＤ１０７を経由することができる。
【００９７】
実施形態では、第２ルーティングテーブル３２は、リードアンドストア要求の応答の転送に使用される。これによって、空き容量が大きいノードに優先的にデータのコピーを保持させることが可能となる。また、通信の品質が優れた転送経路上の特定のノードにデータのコピーが集中することを防止することができる。
【００９８】
また、リードアンドストア要求の応答を除く他のフレームの転送には、第１ルーティングテーブル３１ａ、３１ｂが使用される。これによって、フレームを最も早い通信経路であて先に到達させることができる。
【００９９】
以降、第１ルーティングテーブル３１ａおよび第１ルーティングテーブル３１ｂを、総称して、第１ルーティングテーブル３１と表記することがある。 
【０１００】
（１−７）ファイル情報３３
各ＷＳＤ１００は、自身が備えるストレージ２０に格納されているファイルの一覧をファイル情報３３に記録する。
【０１０１】
図９は、実施形態のあるＷＳＤ１００に保持されるファイル情報３３のデータ構造の一例を示す図である。本図に示されるように、ファイル情報３３には、ファイルハッシュ、ファイル名、ファイルサイズ、更新日時、およびファイルタイプが、この順願でCSV(Comma-Separated  Values)フォーマットで記録されている。ファイルハッシュとしては、例えばSHA-256が利用できる。
【０１０２】
ファイルタイプは、オリジナルであるかコピーであるかを示す情報である。ファイルタイプに関し、オリジナルは、ライト要求に従って格納されたデータであることを意味する。また、コピーは、リードアンドストア要求に従って格納されたデータであることを意味する。
【０１０３】
例えば、図９から、「test1.txt」という名称が付されたファイルに関し、ファイルサイズは「128000Byte」であり、更新日時は「20180803231214（=2018年8月3日23時12分14秒）」であり、ファイルタイプはオリジナルである、ファイルハッシュは「ハッシュ値＃１」であることが読み取れる。
【０１０４】
（２）ストレージシステム１の動作
（２−１）フレーム
前述したように、ノード間ではフレームが転送される。各種要求、各種応答、および各種データは、フレームとして転送される。フレームは、例えば図１０に示す構成を有している。
【０１０５】
図１０に示されるように、フレームは、ヘッダ部とデータ部とを備える。データ部は、ボディとも称され得る。
【０１０６】
ヘッダ部は、Frame  Control、Duration、Receiver  Address、Transmitter  Address、Destination  Address、Sequence  Control、Source  Address、Mesh  Header、などのエレメントを備える。
【０１０７】
フレームは、ハンドシェイクで利用されるManagementフレームや、データの送受信を行うためのDataフレームなど、複数の種類を有する。Frame  Controlエレメントとしては、フレームの種類を示すＩＤが設定される。
【０１０８】
Receiver  Addressエレメントは、転送先のノードのＩＤである。
【０１０９】
ノードのＩＤとしては、例えばＭＡＣアドレス（Media  Access  Control  address）が使用され得る。なお、ノードのＩＤは、ＭＡＣアドレスに限定されない。各ノードを識別可能な情報であれば、任意の情報がノードのＩＤとして使用され得る。
【０１１０】
Transmitter  Addressエレメントは、転送元のノードのＩＤである。
【０１１１】
Destination  Addressエレメントは、あて先のノードのＩＤである。
【０１１２】
Sequence  Controlエレメントは、フレームのシーケンス番号である。シーケンス番号は、フレームが送信される毎に１ずつインクリメントされる。
【０１１３】
Source  Addressエレメントは、送信元のノードのＩＤである。
【０１１４】
Mesh  Headerエレメントは、フレームの生存時間(TTL=Time  To  Live)である。メッシュネットワーク上をフレームが延々とループし続けることを防ぐため，ホップ数の許容される上限値が、生存時間として設定される。
【０１１５】
データ部には、各種要求やデータが格納される。
【０１１６】
なお、図１０に示された構成は一例である。フレームの構成は、図１０に示した構成に限定されない。
【０１１７】
（２−２）ルーティングテーブル３４の生成
（２−２−１）ノード間の通信の概要
ルーティングテーブル３４（第１ルーティングテーブル３１ａ、第１ルーティングテーブル３１ｂ、第２ルーティングテーブル３２）の生成には、Proactive  Path  RequestフレームとProactive  Path  Replyフレームとが使用される。Proactive  Path  RequestフレームとProactive  Path  Replyフレームとは、転送経路を生成するための信号の一例である。
【０１１８】
Proactive  Path  Requestフレームは、転送経路の探索を要求するフレームである。Proactive  Path  Replyフレームは、Proactive  Path  Requestフレームを受信したノードがProactive  Path  Requestフレームに対する応答として送信するフレームである。
【０１１９】
図１１は、実施形態のProactive  Path  Requestフレームの転送例を示す図であり、図１２は、実施形態のProactive  Path  Replyフレームの転送例を示す図である。図１１、図１２において、ノード６００は、ストレージ装置１００またはゲートウェイ２００である。
【０１２０】
詳細は後述するが、例えばあるノード６００（ノード６０１と表記する）がルーティングテーブルを生成する場合には、Proactive  Path  Requestフレームを生成する。そして、ノード６００は、生成したProactive  Path  Requestフレームを、図１１に示されるように、他のノード６００（ノード６０２と表記する）に、ブロードキャストで送信する。
【０１２１】
ノード６０２は、Proactive  Path  Requestフレームを受信すると、所定の処理を行った後に、Proactive  Path  Requestフレームを他のノード６０２に転送する。
【０１２２】
また、ノード６０２は、Proactive  Path  Requestフレームを受信すると、所定の処理を行った後に、メトリック（第１メトリックまたは第２メトリック）に関する情報を少なくとも含むProactive  Path  Replyフレームを生成する。そして、ノード６０２は、生成したProactive  Path  Replyフレームを、図１２に示されるように、Proactive  Path  Requestフレームの発行元であるノード６０１に宛ててユニキャストで送信する。
【０１２３】
各ノード６０２からのProactive  Path  Replyフレームは、直接にまたは他のノード６０２を経由してノード６０１に送られる。ノード６０１は、各ノード６０２からのProactive  Path  Replyフレームに含まれるメトリック（第１メトリックまたは第２メトリック）に関する情報を集約することによって、ルーティングテーブル３４を生成する。
【０１２４】
なお、Proactive  Path  Requestフレームの送信間隔やProactive  Path  Requestフレームの送信のタイミングは、任意に設定可能である。各ノードが頻繁に移動することが想定される場合には、Proactive  Path  Requestフレームの送信間隔として短い時間が設定され得る。各ノードが固定されて動かないことが想定される場合には、Proactive  Path  Requestフレームの送信間隔として長い時間が設定され得る。
【０１２５】
（２−２−２）Proactive  Path  Request
図１３は、実施形態のProactive  Path  Requestフレームの構成の一例を示す図である。本図に示される実施形態のProactive  Path  Requestフレームは、例えば、IEEE  802.11sで規定されている従来のProactive  Path  RequestフレームのReserved領域に、MAX  Capacity  Flag、Free  Space  Flag、Network  MAX  Capacity、およびMetric  With  Free  Space  Flagが追加された構成を有する。
【０１２６】
MAX  Capacity  Flagは、Proactive  Path  Replyフレームに最大容量（つまり表記容量）を記載することを要求するか否かを示すフラグである。例えば、MAX  Capacity  Flagが０であることは、最大容量の記載が不要であることを意味する。MAX  Capacity  Flagが１であることは、最大容量の記載を要することを意味する。
【０１２７】
Free  Space  Flagは、Proactive  Path  Replyフレームに空き容量を記載することを要求するか否かを示すフラグである。例えば、Free  Space  Flagが０であることは、空き容量の記載が不要であることを意味する。Free  Space  Flagが１であることは、空き容量の記載を要することを意味する。
【０１２８】
Metric  With  Free  Space  Flagは、メトリックとして第１のメトリックを要求するか第２のメトリックを要求するかを示すフラグである。例えば、Metric  With  Free  Space  Flagが０であることは、第１のメトリックが要求されていることを意味する。Metric  With  Free  Space  Flagが１であることは、第２のメトリックが要求されていることを示す。
【０１２９】
Network  MAX  Capacityは、各ノードの最大容量における最大値（つまり各ノードの表記容量の最大値）を設定するフィールドである。ゲートウェイ２０１が図６の第１ルーティングテーブル３１ｂを作成した時、各ノードの最大容量が分かる。この最大容量の最大値を設定するフィールドがNetwork  MAX  Capacityである。
【０１３０】
（２−２−３）Proactive  Path  Replyフレーム
図１４は、実施形態のProactive  Path  Replyフレームの構成の一例を示す図である。本図に示される実施形態のProactive  Path  Replyフレームは、例えば、IEEE  802.11sで規定されている従来のProactive  Path  ReplyフレームのFlagsフィールドに存在するReserved領域に、MAX  Capacity  Flag、Free  Space  Flag、およびMetric  With  Free  Space  Flagが追加された構成を有する。
【０１３１】
MAX  Capacity  Flagは、Proactive  Path  Replyフレームに最大容量（つまり表記容量）を記載されているか否かを示すフラグである。MAX  Capacity  Flagが０であることは、最大容量が記載されていないことを意味する。MAX  Capacity  Flagが１であることは、最大容量が記載されていることを意味する。
【０１３２】
最大容量が記載されるフィールドは、Proactive  Path  Replyフレーム内の、Originator  HWMP  Sequence  Numberが記載されるフィールドに後続する位置に用意されている。即ち、図１４に示されるMAX  Capacityフィールドは、最大容量が記載され得るフィールドである。
【０１３３】
Free  Space  Flagは、Proactive  Path  Replyフレームに空き容量が記載されているか否かを示すフラグである。Free  Space  Flagが０であることは、空き容量が記載されていないことを意味する。Free  Space  Flagが１であることは、空き容量が記載されていることを意味する。
【０１３４】
空き容量が記載されるフィールドは、Proactive  Path  Replyフレーム内の、MAX  Capacityフィールドに後続する位置に用意されている。即ち、図１４に示されるFree  Spaceフィールドは、空き容量が記載され得るフィールドである。
【０１３５】
Metric  With  Free  Space  Flagは、第１のメトリックが記載されているか第２のメトリックが記載されているかを示すフラグである。Metric  With  Free  Space  Flagが０であることは、第１のメトリックが記載されていることを意味する。Metric  With  Free  Space  Flagが１であることは、第２のメトリックが記載されていることを示す。
【０１３６】
なお、第１のメトリックまたは第２のメトリックは、図１４に示されるMetricフィールドに記載される。
【０１３７】
（２−２−４）隣接ノードの空き容量の取得
各ノードは、第２のメトリックを演算するためには、隣接ノードの空き容量を知る必要がある。各ノードは、隣接ノードの空き容量を、Free  Space  Flagに１が設定されたProactive  Path  Requestフレームを送信することによって得ることができる。実施形態では、より簡単な方法として、各ノードは、無線通信装置１３、４２の電波が届く範囲の他のノードから受信するビーコンに基づいて取得することもできる。
【０１３８】
ビーコンは、無線LAN端末が短い周期（例えば１００ミリ秒に１回の間隔）で、自身のステータスを周囲へ通知するために定期的に送信するフレームである。
【０１３９】
図１５は、実施形態のビーコンの構成の一例を示す図である。従来のビーコンは、Element  IDフィールド、Lengthフィールド、Element  ID  Extensionフィールド、およびInformationフィールドを有する。実施形態のビーコンは、従来のビーコンのInformationフィールドに、MAX  CapacityとFree  Spaceが記載され得るフィールドが設けられた構成を有する。
【０１４０】
MAX  Capacityフィールドには、ビーコンを送信したノードの最大容量（表記容量）が記載され得る。Free  Spaceフィールドには、ビーコンを送信したノードの空き容量が記載され得る。
【０１４１】
以降、MAX  Capacityフィールドに記載された最大容量とFree  Spaceフィールドに記載された空き容量とを総称して、Free  Space  Informationエレメントと表記することがある。
【０１４２】
図１６は、実施形態のノード間でビーコンが送受信される動作の一例を説明するための図である。説明をわかりやすくするために、本図では、４つのノード（ゲートウェイ２０２、ＷＳＤ１０１、ＷＳＤ１０２、およびＷＳＤ１０３）のみが示されている。
【０１４３】
ゲートウェイ２０２はＷＳＤ１０１のビーコンに含まれるFree  Space  Informationエレメントから、ＷＳＤ１０１の有するストレージの最大容量が32GByte、空き容量が16GByteであることを知る。
【０１４４】
ＷＳＤ１０１は、ゲートウェイ２０２からのビーコンに含まれるFree  Space  Informationエレメントから、ゲートウェイ２０２の有するストレージの最大容量が0GByte、空き容量が0GByteであることを知る。同様に、ＷＳＤ１０１は、ＷＳＤ１０２からのビーコンに含まれるFree  Space  Informationエレメントから最大容量が16GByte、空き容量が8GByteであることを知る。
【０１４５】
ＷＳＤ１０２は、ＷＳＤ１０１からのビーコンに含まれるFree  Space  Informationエレメントから、ＷＳＤ１０１の有するストレージの最大容量が32GByte、空き容量が16GByteであることを知る。同様に、ＷＳＤ１０２は、ＷＳＤ１０３からのビーコンに含まれるFree  Space  Informationエレメントから最大容量が8GByte、空き容量も8GByteであることを知る。
【０１４６】
ＷＳＤ１０３は、ＷＳＤ１０２からのビーコンに含まれるFree  Space  Informationエレメントから、ＷＳＤ１０２の有するストレージの最大容量が16GByte、空き容量が8GByteであることを知る。
【０１４７】
前述したとおり、ビーコンは、短い周期で定期的に送信される。したがって、各ノードは、隣接ノードが有するストレージの空き容量をほぼリアルタイムに把握することが可能である。
【０１４８】
（２−２−５）第２のメトリックを取得する方法
図１７は、第２のメトリックを取得する実施形態の方法の一例を示すフローチャートである。本図に示される動作を実行するノードを、対象ノードと表記する。なお、対象ノードがＷＳＤ１００である場合、本図に示される動作は、コントローラ１０によって実行される。また、対象ノードがゲートウェイ２００である場合、本図に示される動作は、ＣＰＵ４１によって実行される。
【０１４９】
まず、対象ノードは、所定の時間（ビーコンの送信間隔の時間）だけ待機する（Ｓ１０１）。そして、対象ノードは、隣接ノードからのビーコンを無線通信装置１３を介して受信すると（Ｓ１０２）、当該ビーコンに含まれるFree  Space  Informationエレメントから、隣接ノードのストレージの空き容量を取得する（Ｓ１０３）。
【０１５０】
そして、対象ノードは、取得した隣接ノードのストレージの空き容量と自身のストレージの空き容量とに基づいて、隣接ノードまでの第２のメトリックを演算する（Ｓ１０４）。
【０１５１】
Ｓ１０４では、例えば式（２）が使用される。“Ｓｍ”、即ちＷＳＤ１０１〜１０９の表記容量のうちの最大の容量は、定期的に送信される図１３のProactive  Path  Requestフレームに含まれるNetwork  MAX  Capacityフィールドの参照や、ルーティングテーブル３４を参照するなどによって得ることが可能である。
【０１５２】
式（２）に含まれる第１のメトリック“Ｃａ１”の取得方法は、特定の方法に限定されない。対象ノードは、従来から存在する任意の方法で第１のメトリック“Ｃａ１”を取得することができる。または、対象ノードは、本実施形態にかかる方法又は今後開発される任意の方法で第１のメトリック“Ｃａ１”を取得することができる。
【０１５３】
対象ノードは、Ｓ１０４に続いて、Ｓ１０１を再び実行する。なお、ここでは説明を省略したが、対象ノードは、所定の時間ごとに隣接ノードからビーコンを受信するだけでなく、所定の時間ごとにビーコンを送信することができる。対象ノードは、所定の時間ごとにビーコンを送信することによって、自身のストレージの空き容量を隣接ノードに通知することができる。
【０１５４】
このように、図１７の例では、各ノードでは、ビーコンを受信する毎にビーコンの送信元との間の第２のメトリックが演算される。ビーコンは、短い間隔で送信されるので、各ノードは、送信元との間の第２のメトリックをほぼリアルタイムに把握することが可能である。
【０１５５】
（２−２−６）Proactive  Path  Requestを送信する動作
前述したように、各ノードは、ルーティングテーブル３４を生成する際には、Proactive  Path  Requestを生成して、生成したProactive  Path  Requestをブロードキャストで送信することができる。
【０１５６】
図１８は、実施形態のProactive  Path  Requestを送信する動作の一例を示すフローチャートである。本図の説明において、Proactive  Path  Requestの送信元のノードを、対象ノードと表記する。なお、対象ノードがＷＳＤ１００である場合、本図に示される動作は、コントローラ１０によって実行される。また、対象ノードがゲートウェイ２００である場合、本図に示される動作は、ＣＰＵ４１によって実行される。
【０１５７】
まず、対象ノードは、第１ルーティングテーブル３１を作成するか否かを判定する（Ｓ２０１）。Ｓ２０１では、作成の対象が第１ルーティングテーブル３１であるか第２ルーティングテーブル３２であるかが判定される。
【０１５８】
対象ノードがゲートウェイ２００である場合、第２ルーティングテーブル３２は不要であるので、Ｓ２０１では、第１ルーティングテーブル３１を作成する、と判定される。
【０１５９】
第１ルーティングテーブル３１を作成すると判定された場合（Ｓ２０１：Ｙｅｓ）、対象ノードは、Metric  With  Free  Space  Flagに０を設定したProactive  Path  Requestをブロードキャストで送信する（Ｓ２０２）。
【０１６０】
第１ルーティングテーブル３１を作成しないと判定された場合（Ｓ２０１：Ｎｏ）、換言すると、第２ルーティングテーブル３２を作成すると判定された場合、対象ノードは、Metric  With  Free  Space  Flagに１を設定したProactive  Path  Requestをブロードキャストで送信する（Ｓ２０３）。
【０１６１】
Ｓ２０２またはＳ２０３の後、Proactive  Path  Requestを送信する動作が終了する。
【０１６２】
なお、対象ノードは、作成の対象が第１ルーティングテーブル３１であるか第２ルーティングテーブル３２であるかに関わらず、Free  Space  FlagおよびMAX  Capacity  Flagとして０および１のうちの任意の値を設定することができる。対象ノードは、ルーティングテーブル３４に最大容量を記録する場合には、MAX  Capacity  Flagとして１を設定する。対象ノードは、ルーティングテーブル３４に空き容量を記録する場合には、Free  Space  Flagとして１を設定する。
【０１６３】
（２−２−７）Proactive  Path  Requestを受信したノードの動作
図１９は、実施形態のProactive  Path  Requestを受信したノードの動作の一例を示すフローチャートである。本図の説明において、Proactive  Path  Requestを受信したノードを、対象ノードと表記する。なお、対象ノードがＷＳＤ１００である場合、本図に示される動作は、コントローラ１０によって実行される。また、対象ノードがゲートウェイ２００である場合、本図に示される動作は、ＣＰＵ４１によって実行される。
【０１６４】
対象ノードは、Proactive  Path  Requestを受信すると、Proactive  Path  Requestに含まれるMetric  With  Free  Space  Flagが０であるか否かを判定する（Ｓ３０１）。前述したように、第１のメトリックが要求されている場合には、Metric  With  Free  Space  Flagとして０が設定されており、第２のメトリックが要求されている場合には、Metric  With  Free  Space  Flagとして１が設定されている。
【０１６５】
Metric  With  Free  Space  Flagが０であると判定された場合（Ｓ３０１：Ｙｅｓ）、対象ノードは、Proactive  Path  Requestに含まれるMetricフィールドの値にProactive  Path  Requestの転送元までの第１のメトリックを加算する（Ｓ３０２）。
【０１６６】
そして、対象ノードは、自身の第１ルーティングテーブル３１に、Ｓ３０２によって得られた第１のメトリックを記録する（Ｓ３０３）。より詳しくは、対象ノードは、Proactive  Path  Requestの発行元のアドレスを“Destination”として記録し、Proactive  Path  Requestの転送元のアドレスを“Next  Hop”として記録し、Ｓ３０２によって得られた第１のメトリックを“First  Metric”として記録する。
【０１６７】
続いて、対象ノードは、Proactive  Path  Requestに含まれるMetricフィールドの値をＳ３０２によって得られた第１のメトリックで更新して、更新後のProactive  Path  Requestをブロードキャストで転送する（Ｓ３０４）。
【０１６８】
さらに、対象ノードは、Metric  With  Free  Space  Flagとして０が設定されたProactive  Path  Replyを、Proactive  Path  Requestの発行元のノードに宛てて、ユニキャストで送信する（Ｓ３０５）。なお、対象ノードは、Proactive  Path  ReplyのMetricフィールドに０を設定する。Metricフィールドには、Proactive  Path  Replyが転送される毎に加算されたメトリックが格納される。Ｓ３０５では、Metricフィールドには初期値である０が格納される。
【０１６９】
Ｓ３０５によって、対象ノードでの動作が終了する。
【０１７０】
Metric  With  Free  Space  Flagが０でないと判定された場合（Ｓ３０１：Ｎｏ）、即ちMetric  With  Free  Space  Flagが１である場合、対象ノードは、Proactive  Path  Requestに含まれるMetricフィールドの値にProactive  Path  Requestの転送元までの第２のメトリックを加算する（Ｓ３０６）。
【０１７１】
対象ノードは、例えば図１７を用いて説明された動作によって、各隣接ノードまでの第２のメトリックを取得している。Ｓ３０６では、対象ノードは、隣接ノードのうちのProactive  Path  Requestの転送元までの第２のメトリックを用いる。
【０１７２】
そして、対象ノードは、自身の第２ルーティングテーブル３２に、Ｓ３０６によって得られた第２のメトリックを記録する（Ｓ３０７）。より詳しくは、対象ノードは、Proactive  Path  Requestの発行元のアドレスを“Destination”として記録し、Proactive  Path  Requestの転送元のアドレスを“Next  Hop”として記録し、Ｓ３０６によって得られた第２のメトリックを“Second  Metric”として記録する。
【０１７３】
続いて、対象ノードは、Proactive  Path  Requestに含まれるMetricフィールドの値をＳ３０６によって得られた第２のメトリックで更新して、更新後のProactive  Path  Requestをブロードキャストで転送する（Ｓ３０８）。
【０１７４】
さらに、対象ノードは、Metric  With  Free  Space  Flagとして１が設定されたProactive  Path  Replyを、Proactive  Path  Requestの発行元のノードに宛てて、ユニキャストで送信する（Ｓ３０９）。なお、対象ノードは、Ｓ３０５の場合と同様に、Proactive  Path  ReplyのMetricフィールドに０を設定する。
【０１７５】
Ｓ３０９によって、対象ノードでの動作が終了する。
【０１７６】
なお、図１９には記載されていないが、対象ノードは、Proactive  Path  Requestに含まれるFree  Space  FlagやMAX  Capacity  Flagに応じて、Proactive  Path  Replyに、自身のストレージの空き容量や最大容量を記載することができる。
【０１７７】
具体的には、対象ノードは、Proactive  Path  RequestのFree  Space  Flagが１である場合、Proactive  Path  ReplyのFree  Spaceフィールドに自身のストレージの空き容量を記載する。その場合には、対象ノードは、Proactive  Path  ReplyのFree  Space  Flagとして１を設定する。
【０１７８】
また、対象ノードは、Proactive  Path  RequestのFree  Space  Flagが０である場合、Proactive  Path  ReplyのFree  Spaceフィールドに自身のストレージの空き容量を記載しない。その場合には、対象ノードは、Proactive  Path  ReplyのFree  Space  Flagとして０を設定する。
【０１７９】
また、対象ノードは、Proactive  Path  RequestのMAX  Capacity  Flagが１である場合、Proactive  Path  ReplyのMAX  Capacityフィールドに自身のストレージの最大容量を記載する。その場合には、対象ノードは、Proactive  Path  ReplyのMAX  Capacity  Flagとして１を設定する。
【０１８０】
また、対象ノードは、Proactive  Path  RequestのMAX  Capacity  Flagが０である場合、Proactive  Path  ReplyのMAX  Capacityフィールドに自身のストレージの最大容量を記載しない。その場合には、対象ノードは、Proactive  Path  ReplyのMAX  Capacity  Flagとして０を設定する。
【０１８１】
（２−２−８）Proactive  Path  Replyを受信したノードの動作
図２０は、Proactive  Path  Replyを受信したノードの動作の一例を説明するフローチャートである。本図の説明において、Proactive  Path  Replyを受信したノードを、対象ノードと表記する。なお、対象ノードがＷＳＤ１００である場合、本図に示される動作は、コントローラ１０によって実行される。また、対象ノードがゲートウェイ２００である場合、本図に示される動作は、ＣＰＵ４１によって実行される。
【０１８２】
対象ノードは、Proactive  Path  Replyを受信すると、Proactive  Path  Replyに含まれるMetric  With  Free  Space  Flagが０であるか否かを判定する（Ｓ４０１）。前述したように、第１のメトリックが要求されている場合には、Metric  With  Free  Space  Flagとして０が設定されており、第２のメトリックが要求されている場合には、Metric  With  Free  Space  Flagとして１が設定されている。
【０１８３】
Metric  With  Free  Space  Flagが０であると判定された場合（Ｓ４０１：Ｙｅｓ）、対象ノードは、Proactive  Path  Replyに含まれるMetricフィールドの値にProactive  Path  Replyの転送元までの第１のメトリックを加算する（Ｓ４０２）。
【０１８４】
そして、対象ノードは、自身がProactive  Path  Replyのあて先であるか否かを判定する（Ｓ４０３）。
【０１８５】
自身がProactive  Path  Replyのあて先であると判定された場合（Ｓ４０３：Ｙｅｓ）、対象ノードは、自身の第１ルーティングテーブル３１に、Ｓ４０２によって得られた第１のメトリックを記録する（Ｓ４０４）。より詳しくは、対象ノードは、Proactive  Path  Replyの発行元のアドレスを“Destination”として記録し、Proactive  Path  Replyの転送元のアドレスを“Next  Hop”として記録し、Ｓ４０２によって得られた第１のメトリックを“First  Metric”として記録する。
【０１８６】
自身がProactive  Path  Replyのあて先でないと判定された場合（Ｓ４０３：Ｎｏ）、対象ノードは、Proactive  Path  Replyに含まれるMetricフィールドの値をＳ４０２によって得られた第１のメトリックで更新して、更新後のProactive  Path  Replyをユニキャストで転送する（Ｓ４０５）。Ｓ４０５では、転送の際に、第１ルーティングテーブル３１が参照される。
【０１８７】
一方、Metric  With  Free  Space  Flagが０でないと判定された場合（Ｓ４０１：Ｎｏ）、即ちMetric  With  Free  Space  Flagが１である場合、対象ノードは、Proactive  Path  Replyに含まれるMetricフィールドの値にProactive  Path  Replyの転送元までの第２のメトリックを加算する（Ｓ４０６）。
【０１８８】
そして、対象ノードは、自身がProactive  Path  Replyのあて先であるか否かを判定する（Ｓ４０７）。
【０１８９】
自身がProactive  Path  Replyのあて先であると判定された場合（Ｓ４０７：Ｙｅｓ）、対象ノードは、自身の第２ルーティングテーブル３２に、Ｓ４０６によって得られた第２のメトリックを記録する（Ｓ４０８）。より詳しくは、対象ノードは、Proactive  Path  Replyの発行元のアドレスを“Destination”として記録し、Proactive  Path  Replyの転送元のアドレスを“Next  Hop”として記録し、Ｓ４０６によって得られた第２のメトリックを“Second  Metric”として記録する。
【０１９０】
自身がProactive  Path  Replyのあて先でないと判定された場合（Ｓ４０７：Ｎｏ）、対象ノードは、Proactive  Path  Replyに含まれるMetricフィールドの値をＳ４０６によって得られた第２のメトリックで更新して、更新後のProactive  Path  Replyをユニキャストで転送する（Ｓ４０９）。Ｓ４０９では、転送の際に、第２ルーティングテーブル３２が参照される。
【０１９１】
Ｓ４０５、Ｓ４０６、Ｓ４０８、またはＳ４０９の後、対象ノードでの動作が終了する。
【０１９２】
なお、対象ノードは、自身がProactive  Path  Replyのあて先であった場合において（Ｓ４０３：ＹｅｓまたはＳ４０７：Ｙｅｓ）、Proactive  Path  Replyに空き容量や最大容量が記載されている場合、Ｓ４０４またはＳ４０８において、その空き容量や最大容量をルーティングテーブル３４に記録してもよい。これによって、対象ノードは、空き容量や最大容量をノード毎に記録したルーティングテーブル３４を得ることができる。
【０１９３】
（２−２−９）ルーティングテーブル３４の生成方法の具体例
図１８〜図２０に示された一連の動作が実行されることによって、Proactive  Path  Requestフレームの送信元のノードでは、Ｓ２０１の処理によって指定したルーティングテーブル３４が生成される。
【０１９４】
ここでは、ルーティングテーブル３４の生成方法の具体例として、第１ルーティングテーブル３１を生成する方法を説明する。なお、第２ルーティングテーブル３２を生成する方法は、使用されるメトリックの点で、第１ルーティングテーブル３１を生成する方法と異なる。下記の第１ルーティングテーブル３１の生成方法の具体例は、第１のメトリックを第２のメトリックと読み替えることによって、第２ルーティングテーブル３２の生成方法の具体例として理解することができる。
【０１９５】
また、説明を簡単にするために、図２１に示されるような、ゲートウェイ２０１、ＷＳＤ１０２、ＷＳＤ１０３、ＷＳＤ１０５、ＷＳＤ１０６、ＷＳＤ１０７、ＷＳＤ１０８からなるネットワークにおいて、ゲートウェイ２０１が第１ルーティングテーブル３１ｂを生成する場合について説明する。
【０１９６】
まず、ゲートウェイ２０１がProactive  Path  Requestをブロードキャストで送信する。このProactive  Path  Requestには、Originator  Mesh  STA  Addressエレメントとしてゲートウェイ２０１のＭＡＣアドレスが設定され、Metricエレメントとして０が設定される。
【０１９７】
ＷＳＤ１０２がゲートウェイ２０１からProactive  Path  Requestを受け取ると、Originator  Mesh  STA  Addressエレメントを“Destination”として取得し、Transmitter  Addressエレメントを“Next  Hop”として取得し、Metricエレメント(0)にＷＳＤ１０２が予め取得したゲートウェイ２０１までの第１のメトリック(20)を加算することによって得られる20(=0+20)を、“First  Metric”として取得する。
【０１９８】
以降、Proactive  Path  Requestフレームを受信したノードがProactive  Path  Requestフレームから取得する情報を、ルーティング情報と表記する。
【０１９９】
図２２は、ＷＳＤ１０２がProactive  Path  Requestフレームに基づいて取得したルーティング情報の一例を示す図である。本図に示されるように、ルーティング情報には、“Destination”としてゲートウェイ２０１が記録され、“Next  Hop”としてゲートウェイ２０１が記録され、“First  Metric”として２０が記録されている。ＷＳＤ１０２は、このルーティング情報を、ＷＳＤ１０２の第１ルーティングテーブル３１ａに、１レコードとして追加する。
【０２００】
ＷＳＤ１０２は、Proactive  Path  Requestをブロードキャストで受け取ったので、更にこのProactive  Path  Requestを転送するが、転送する際にこのProactive  Path  Requestの2カ所を書き換える。図２３は、ＷＳＤ１０２による書き換えの前後のProactive  Path  Requestを説明するための図である。
【０２０１】
図２３に示されるように、ＷＳＤ１０２は、Transmitter  AddressエレメントとMetricエレメントとを書き換える。ＷＳＤ１０２は、Transmitter  Addressエレメントをゲートウェイ２０１のアドレス（ＭＡＣアドレス）からＷＳＤ１０２のアドレス（ＭＡＣアドレス）に書き換える。また、ＷＳＤ１０２は、Metricエレメントを、０からルーティング情報に記録された第１のメトリックである２０に書き換える。
【０２０２】
ＷＳＤ１０３がゲートウェイ２０１からProactive  Path  Requestを受け取ると、ＷＳＤ１０３は、ルーティング情報を生成する。即ち、Originator  Mesh  STA  Addressエレメントを“Destination”として取得し、Transmitter  Addressエレメントを“Next  Hop”として取得し、Metricエレメント(0)にＷＳＤ１０３が予め取得したゲートウェイ２０１までの第１のメトリック(10)を加算することによって得られる10(=0+10)を、“First  Metric”として取得する。
【０２０３】
図２４は、ＷＳＤ１０３がProactive  Path  Requestに基づいて取得したルーティング情報の一例を示す図である。本図に示されるように、ルーティング情報には、“Destination”としてゲートウェイ２０１が記録され、“Next  Hop”としてゲートウェイ２０１が記録され、“First  Metric”として１０が記録されている。ＷＳＤ１０３は、このルーティング情報を、ＷＳＤ１０３の第１ルーティングテーブル３１ａに１レコードとして追加する。
【０２０４】
ここで、ＷＳＤ１０３は、ゲートウェイ２０１から送信されたProactive  Path  Requestを、ＷＳＤ１０２を経由して受信することができる。
【０２０５】
ＷＳＤ１０２を経由したProactive  Path  Requestは、図２３を用いて説明されたように、Transmitter  AddressエレメントとMetricエレメントとが書き換えられている。ＷＳＤ１０３は、Transmitter  AddressエレメントとMetricフィールドエレメントとが書き換えられた後のProactive  Path  Requestから、図２５に示されるルーティング情報を生成する。
【０２０６】
図２５に示されるルーティング情報によれば、ゲートウェイ２０１とＷＳＤ１０２との間の第１のメトリック(20)と、ＷＳＤ１０２とＷＳＤ１０３との間の第１のメトリック(30)との合計が、“First  Metric”として記録されている。つまり、図２５に示されるルーティング情報には、ＷＳＤ１０２を経由したProactive  Path  Requestの転送経路の合計の第１のメトリック(50)が記録されている。
【０２０７】
ＷＳＤ１０３は、図２４のルーティング情報と図２５のルーティング情報との間で第１のメトリック（第１のメトリックの合計）を比較し、第１のメトリック（第１のメトリックの合計）が大きい方、つまり図２５のルーティング情報を破棄する。
【０２０８】
これによって、ＷＳＤ１０３は、ゲートウェイ２０１からＷＳＤ１０３に至る２つの転送経路のうちの、通信の品質が優れた方で転送されてきたProactive  Path  Requestから取得したルーティング情報、つまり図２４のルーティング情報のみを、“Destination”としてゲートウェイ２０１が設定されたレコードとして保持することができる。
【０２０９】
ＷＳＤ１０３は、破棄されずに残ったルーティング情報、つまり図２４のルーティング情報に基づき、ゲートウェイ２０１から直接に受信したProactive  Path  Requestを書き換えて、書き換えた後のProactive  Path  Requestを転送する。
【０２１０】
図２６は、ＷＳＤ１０３による書き換えの前後のProactive  Path  Requestを説明するための図である。本図に示されるように、ＷＳＤ１０３は、Transmitter  AddressエレメントとMetricエレメントとを書き換える。ＷＳＤ１０３は、Transmitter  Addressエレメントをゲートウェイ２０１のアドレス（ＭＡＣアドレス）からＷＳＤ１０３のアドレス（ＭＡＣアドレス）に書き換える。また、ＷＳＤ１０３は、Metricエレメントを、０から図２２に示されるルーティング情報として取得された第１のメトリック（第１のメトリックの合計）である１０に書き換える。
【０２１１】
なお、ＷＳＤ１０３は、それぞれ異なる転送経路に沿って転送されてきた２つのProactive  Path  Requestのうちの、最初に受信したProactive  Path  Requestの書き換えと転送とを、当該２つのProactive  Path  Requestのうちの残りのProactive  Path  Requestの受信を待たずに実行することができる。当該２つのProactive  Path  Requestのうちの最初に受信したProactive  Path  Requestは、当該２つのProactive  Path  Requestのうちの残りのProactive  Path  Requestよりも通信の品質が優れた転送経路で転送されてきたものであり、第１のメトリックの合計がより小さいことが明らかであるからである。
【０２１２】
ＷＳＤ１０３は、当該２つのProactive  Path  Requestのうちの最初に受信したProactive  Path  Requestの書き換えと転送とを実行するが、当該２つのProactive  Path  Requestのうちの残りのProactive  Path  Requestの書き換えおよび転送は実行しない。これによって、ＷＳＤ１０３は、最も通信の品質が高い転送経路で転送されたProactive  Path  Requestのみを、他のノードに転送することができる。
【０２１３】
また、ＷＳＤ１０３は、最も通信の品質が高い転送経路で転送されたProactive  Path  Requestに基づいて、第１ルーティングテーブル３１ａの対応するレコードを生成することができる。
【０２１４】
ＷＳＤ１０３のケースと同様に、ＷＳＤ１０２は、ゲートウェイ２０１から送信されたProactive  Path  Requestを、ＷＳＤ１０３を経由して受信することができる。ＷＳＤ１０２は、ゲートウェイ２０１から送信されたProactive  Path  Requestに基づき、図２７に示されるルーティング情報を生成する。しかしながら、図２７に示されるルーティング情報は、すでに生成されて保持されている図２２に示されるルーティング情報と比較して、メトリックの値が大きい。よって、ＷＳＤ１０２は、図２７に示されるルーティング情報を削除する。また、ＷＳＤ１０２は、ＷＳＤ１０３を経由して受信したProactive  Path  Requestの書き換えおよび転送を実行しない。
【０２１５】
これによって、ＷＳＤ１０２は、最も通信の品質が高い転送経路で転送されたProactive  Path  Requestのみを、他のノードに転送することができる。また、ＷＳＤ１０２は、最も通信の品質が高い転送経路で転送されたProactive  Path  Requestに基づいて、ＷＳＤ１０２の第１ルーティングテーブル３１ａの対応するレコードを生成することができる。
【０２１６】
ＷＳＤ１０５は、Proactive  Path  Requestを、ＷＳＤ１０２を経由して受信することができる。ＷＳＤ１０２を経由してＷＳＤ１０５に到達したProactive  Path  Requestは、図２３に示されるように、ＷＳＤ１０２によって書き換えられた後のProactive  Path  Requestである。ＷＳＤ１０５は、ＷＳＤ１０２によって書き換えられた後のProactive  Path  Requestに基づき、図２８に示されるルーティング情報を生成する。図２８に示されるように、ルーティング情報にはProactive  Path  Requestが転送されてきた経路の第１のメトリックの合計である50が記録されている。
【０２１７】
また、ＷＳＤ１０５は、Proactive  Path  Requestを、ＷＳＤ１０３とＷＳＤ１０６とをこの順番で経由して受信することができる。ＷＳＤ１０３とＷＳＤ１０６とをこの順番で経由してＷＳＤ１０５に到達したProactive  Path  Requestは、ＷＳＤ１０６によって、Transmitter  Addressフィールドの値がＷＳＤ１０６のアドレス（ＭＡＣアドレス）で書き換えられ、Metricフィールドの値がゲートウェイ２０１からＷＳＤ１０３を経由してＷＳＤ１０６に至る転送経路の合計の第１のメトリックである20に書き換えられている。ＷＳＤ１０５は、ＷＳＤ１０６によって書き換えられた後のProactive  Path  Requestに基づき、図２９に示されるルーティング情報を生成する。図２９に示されるように、ルーティング情報にはProactive  Path  Requestが転送されてきた経路の第１のメトリックの合計である30が記録されている。
【０２１８】
図２８に示されるルーティング情報と、図２９に示されるルーティング情報とでは、図２９に示されるルーティング情報のほうが第１のメトリック（第１のメトリックの合計）が小さい。よって、ＷＳＤ１０５は、ＷＳＤ１０３とＷＳＤ１０６とをこの順番で経由してＷＳＤ１０５に到達したProactive  Path  Requestの書き換えと転送とを実行し、ＷＳＤ１０２を経由してＷＳＤ１０５に到達したProactive  Path  Requestフレームの書き換えと転送とを実行しない。また、ＷＳＤ１０５は、図２９に示されるルーティング情報をＷＳＤ１０５の第１ルーティングテーブル３１ａに１レコードとして追加し、図２８に示されるルーティング情報を破棄する。
【０２１９】
このように、各ノードには、ゲートウェイ２０１からブロードキャストで送信され、それぞれ異なる転送経路で転送されてきた複数のProactive  Path  Requestのうちの、第１のメトリックの合計が最も小さい転送経路で転送されてきたProactive  Path  Requestの書き換えと転送とを実行する。そして、各ノードは、当該第１のメトリックの合計が最も小さい転送経路に基づいて、第１ルーティングテーブル３１ａの１レコードを生成する。
【０２２０】
参考のために、他のノードにおいて生成され第１ルーティングテーブル３１ａに追加されるルーティング情報を示す。図３０は、ＷＳＤ１０６のルーティング情報を示している。図３１は、ＷＳＤ１０８のルーティング情報を示している。図３２は、ＷＳＤ１０９のルーティング情報を示している。
【０２２１】
各ノードは、Proactive  Path  Requestを受け取った後、Proactive  Path  Requestの書き換えと転送とを実行するとともに、Proactive  Path  RequestのOriginator  Mesh  STA  Addressに記載されていたアドレス、即ちゲートウェイ２０１をあて先として、Proactive  Path  Replyをユニキャストで送信する。
【０２２２】
図３３は、ＷＳＤ１０２が生成して送信するProactive  Path  Replyを説明するための図である。ＷＳＤ１０２は、図２２に示されるルーティング情報（第１ルーティングテーブル３１ａ）に基づき、あて先がゲートウェイ２０１である場合のネクストホップがゲートウェイ２０１であることを知る。そして、ＷＳＤ１０２は、Proactive  Path  Replyに対し、Originator  Mesh  STA  Addressエレメントとしてゲートウェイ２０１のアドレスを設定し、Target  Mesh  STA  Addressエレメントとして自ノード(ＷＳＤ１０２)のアドレスを設定し、Metricエレメントとして0を設定し、ヘッダ部のSource  Addressエレメントとして自ノード(ＷＳＤ１０２)のアドレスを設定し、Destination  Addressエレメントとしてゲートウェイ２０１のアドレスを設定する。ＷＳＤ１０２は、これらの情報が設定されたProactive  Path  Replyを、ネクストホップであるゲートウェイ２０１へ転送する。
【０２２３】
ゲートウェイ２０１がＷＳＤ１０２から転送されてきたProactive  Path  Replyを受信すると、Target  Mesh  STA  Addressエレメントを“Destination”として取得し、Transmitter  Addressエレメントを“Next  Hop”として取得し、Metricエレメント（０）にゲートウェイ２０１が予め取得したＷＳＤ１０２までの第１のメトリック（２０）を加算することによって得られる20(=0+20)を、“First  Metric”として取得する。
【０２２４】
そして、ゲートウェイ２０１は、取得したこれらの値を、第１ルーティングテーブル３１ｂに１レコードとして追加する。図３４は、上記の手順で生成されたゲートウェイ２０１の第１ルーティングテーブル３１ｂを示す図である。
【０２２５】
図３５は、ＷＳＤ１０３が生成して送信するProactive  Path  Replyを説明するための図である。ＷＳＤ１０３は、図２４に示されるルーティング情報（第１ルーティングテーブル３１ａ）に基づき、あて先がゲートウェイ２０１である場合のネクストホップがゲートウェイ２０１であることを知る。そして、ＷＳＤ１０３は、Proactive  Path  Replyに対し、Originator  Mesh  STA  Addressエレメントとしてゲートウェイ２０１のアドレスを設定し、Target  Mesh  STA  Addressエレメントとして自ノード(ＷＳＤ１０３)のアドレスを設定し、Metricエレメントとして0を設定し、ヘッダ部のSource  Addressエレメントとして自ノード(ＷＳＤ１０３)のアドレスを設定し、Destination  Addressエレメントとしてゲートウェイ２０１のアドレスを設定する。ＷＳＤ１０３は、これらの情報が設定されたProactive  Path  Replyを、ネクストホップであるゲートウェイ２０１へ転送する。
【０２２６】
ゲートウェイ２０１がＷＳＤ１０３から転送されてきたProactive  Path  Replyを受信すると、Target  Mesh  STA  Addressエレメントを“Destination”として取得し、Transmitter  Addressエレメントを“Next  Hop”として取得し、Metricエレメント（０）にゲートウェイ２０１が予め取得したＷＳＤ１０３までの第１のメトリック（１０）を加算することによって得られる10(=0+10)を、“First  Metric”として取得する。
【０２２７】
そして、ゲートウェイ２０１は、取得したこれらの値を、第１ルーティングテーブル３１ｂに１レコードとして追加する。図３６は、上記の手順で生成されたゲートウェイ２０１の第１ルーティングテーブル３１ｂを示す図である。
【０２２８】
図３７は、ＷＳＤ１０６が生成して送信するProactive  Path  Replyを説明するための図である。ＷＳＤ１０６は、図３０に示されるルーティング情報（第１ルーティングテーブル３１ａ）に基づき、あて先がゲートウェイ２０１である場合のネクストホップがＷＳＤ１０３であることを知る。そして、ＷＳＤ１０６は、Proactive  Path  Replyに対し、Originator  Mesh  STA  Addressエレメントとしてゲートウェイ２０１のアドレスを設定し、Target  Mesh  STA  Addressエレメントとして自ノード(ＷＳＤ１０６)のアドレスを設定し、Metricエレメントとして0を設定し、ヘッダ部のSource  Addressエレメントとして自ノード(ＷＳＤ１０６)のアドレスを設定し、Destination  Addressエレメントとしてゲートウェイ２０１のアドレスを設定する。ＷＳＤ１０６は、これらの情報が設定されたProactive  Path  Replyを、ネクストホップであるＷＳＤ１０３へ転送する。
【０２２９】
ＷＳＤ１０３は、ＷＳＤ１０６から図３７に示されるProactive  Path  Replyを受信すると、ＷＳＤ１０３は、ヘッダ部のDestination  Addressを確認する。これによって、ＷＳＤ１０３は、Proactive  Path  Replyのあて先は、ＷＳＤ１０３ではないことを知る。ＷＳＤ１０３は、図２４に示されるルーティング情報（第１ルーティングテーブル３１ａ）に基づき、あて先がゲートウェイ２０１である場合のネクストホップがゲートウェイ２０１であることを知る。そして、ＷＳＤ１０３は、Proactive  Path  Replyを書き換える。
【０２３０】
図３８は、ＷＳＤ１０３による書き換えの前後のProactive  Path  Replyを説明するための図である。
【０２３１】
図３８に示されるように、ＷＳＤ１０３は、ヘッダ部のReceiver  AddressエレメントおよびTransmitter  Addressエレメントと、データ部のMetricエレメントとを書き換える。具体的には、ＷＳＤ１０３は、Receiver  Addressエレメントを、自ノード（ＷＳＤ１０３）のアドレスから転送先（ゲートウェイ２０１）のアドレスに書き換え、Transmitter  Addressエレメントを、ＷＳＤ１０６のアドレスから、自ノード（ＷＳＤ１０３）のアドレスに書き換える。また、ＷＳＤ１０３は、Metricエレメント（０）にＷＳＤ１０３が予め取得したＷＳＤ１０６までの第１のメトリック（１０）を加算することによって得られる10(=0+10)を取得し、Metricエレメントを、取得したこの値に書き換える。
【０２３２】
ＷＳＤ１０３は、書き換え後のProactive  Path  Replyをネクストホップであるゲートウェイ２０１へ転送する。
【０２３３】
ゲートウェイ２０１がＷＳＤ１０６からＷＳＤ１０３を経由して転送されてきたProactive  Path  Replyを受信すると、Target  Mesh  STA  Addressエレメントを“Destination”として取得し、Transmitter  Addressエレメントを“Next  Hop”として取得し、Metricエレメント（１０）にゲートウェイ２０１が予め取得したＷＳＤ１０３までの第１のメトリック（１０）を加算することによって得られる２０(＝１０＋１０)を、“First  Metric”として取得する。
【０２３４】
そして、ゲートウェイ２０１は、取得したこれらの値を、第１ルーティングテーブル３１ｂに１レコードとして追加する。図３９は、上記の手順で生成されたゲートウェイ２０１の第１ルーティングテーブル３１ｂを示す図である。
【０２３５】
このように、Proactive  Path  Replyを受信したノードは、当該Proactive  Path  Replyのあて先が自身でない場合、Metricエレメントを、当該MetricエレメントにProactive  Path  Replyフレームの転送元までの第１のメトリックを加算して、加算によって得られた値で更新し、更新後のProactive  Path  Replyを第１ルーティングテーブル３１に従って転送する。
【０２３６】
これによって、Proactive  Path  Replyは、第１のメトリックの合計が最小である転送経路に沿って転送されて、あて先、即ちProactive  Path  Requestフレームの送信元に到達する。
【０２３７】
また、Proactive  Path  Replyの中継ノードおよびあて先のノード（即ちゲートウェイ２０１）は、転送元までの第１のメトリックを、Metricエレメントに加算する。これによって、Proactive  Path  Replyのあて先は、Proactive  Path  Replyの転送経路の第１のメトリックの合計を得ることができる。
【０２３８】
上記と同様の動作により、ＷＳＤ１０５、ＷＳＤ１０８、およびＷＳＤ１０９が生成し送信した各Proactive  Path  Replyは、第１ルーティングテーブル３１ａに従って転送される。各Proactive  Path  ReplyのMetricエレメントは、転送毎に第１のメトリックが加算される。ゲートウェイ２０１は、ＷＳＤ１０５、ＷＳＤ１０８、およびＷＳＤ１０９が生成し送信した各Proactive  Path  Replyに基づき、ＷＳＤ１０５、ＷＳＤ１０８、およびＷＳＤ１０９をあて先とした場合のネクストホップおよび第１のメトリックの合計を取得する。そして、ゲートウェイ２０１は、取得したこれらの情報を、第１ルーティングテーブル３１ｂに追加し、図４０に示す第１ルーティングテーブル３１ｂを得る。図４０は、完成した第１ルーティングテーブル３１ｂを示す図である。
【０２３９】
（２−３）ファイル制御
ノード間でのファイルの転送を制御するために、種々の要求や種々の応答が使用される。ここでは、リード要求、リード要求に対する応答であるリード応答、リードアンドストア要求、リードアンドストア要求に対する応答であるリードアンドストア応答、ステータス要求、ステータス要求に対する応答であるステータス応答について説明する。他の要求や応答（ライト要求、イレース要求、ライト応答、イレース応答など）については説明を省略する。
【０２４０】
（２−３−１）リード要求
リード要求は、フレーム（リード要求フレーム）の形式で送信される。図４１は、リード要求フレームの構成の一例を示す図である。なお、本図では、ヘッダ部の図示を省略している。つまり、図４１は、リード要求フレームのデータ部を示している。
【０２４１】
図４１に示されるように、リード要求フレームは、Commandエレメント、Request  Numberエレメント、File  Name  Lengthエレメント、File  Nameエレメント、Offsetエレメント、およびRead  Sizeエレメントを備える。
【０２４２】
Commandエレメントとしては、リード要求を示すＩＤが設定される。
【０２４３】
Request  Numberエレメントは、要求を送信する度に値が1ずつ増加するシーケンシャルナンバーである。応答を返す側は、Request  Numberエレメントと同じ値をResponse  Numberエレメントとして設定する。このように、Request  NumberエレメントとResponse  Numberエレメントとを整合させることで、要求と応答とが対応付けられる。
【０２４４】
File  Name  Lengthエレメントは、ファイル名の長さである。File  Nameエレメントは、ファイル名である。Offsetエレメントは、ファイルのリード場所をファイルの先頭からのオフセットで指定する。Read  Sizeエレメントは、オフセットからリードするサイズである。
【０２４５】
（２−３−２）リード応答
リード要求フレームのあて先のノードがリード要求フレームを受信した場合、リード応答を返す。リード応答は、フレーム（リード応答フレーム）の形式で送信される。
【０２４６】
図４２は、リード応答フレームの構成の一例を示す図である。なお、本図では、ヘッダ部の図示を省略している。つまり、図４２は、リード応答フレームのデータ部を示している。
【０２４７】
図４２に示されるように、リード応答フレームは、Commandエレメント、Response  Numberエレメント、Resultエレメント、File  Data  Sizeエレメント、およびFile  Dataエレメントを備える。
【０２４８】
Commandエレメントとしては、リード応答を示すＩＤが設定される。Response  Numberエレメントとしては、対応するリード要求フレームのResponse  Numberエレメントと同一の値が設定される。
【０２４９】
Resultエレメントは、リードリクエストの実行結果である。例えば、リード要求フレームで指定されたファイルをリードできた時はResultエレメントとして０が設定され、当該ファイルをリードできない時はResultエレメントとして１が設定される。また、リード要求フレームに設定されていたOffsetがファイルサイズより大きい時など、設定値に異常が見られる場合、Resultエレメントを用いてエラーが通知される。
【０２５０】
File  Dataエレメントは、リード要求フレームによって要求されたデータ（ファイル）である。File  Data  Sizeエレメントは、File  Dataエレメントに設定されたファイルのサイズを示す。
【０２５１】
（２−３−３）リードアンドストア要求
リードアンドストア要求は、フレーム（リードアンドストア要求フレーム）の形式で送信される。
【０２５２】
図４３は、リードアンドストア要求フレームの構成の一例を示す図である。なお、本図では、ヘッダ部の図示を省略している。つまり、図４３は、リードアンドストア要求フレームのデータ部を示している。
【０２５３】
リードアンドストア要求フレームは、図４１に示されるリード要求フレームと同様に、Commandエレメント、Request  Numberエレメント、File  Name  Lengthエレメント、File  Nameエレメント、Offsetエレメント、およびRead  Sizeエレメントを備える。
【０２５４】
リードアンドストア要求フレームでは、Commandエレメントとして、リードアンドストア要求を示すＩＤが設定される。リードアンドストア要求フレームのCommandエレメント以外の全てのエレメントは、リード要求フレームの同名のエレメントと同じ意味を有する。
【０２５５】
（２−３−４）リードアンドストア応答
リードアンドストア応答は、フレーム（リードアンドストア応答フレーム）の形式で送信される。
【０２５６】
図４４は、リードアンドストア応答フレームの構成の一例を示す図である。なお、本図では、ヘッダ部の図示を省略している。つまり、図４４は、リードアンドストア応答フレームのデータ部を示している。
【０２５７】
リードアンドストア応答フレームは、Commandエレメント、Response  Numberエレメント、Resultエレメント、File  Name  Lengthエレメント、File  Nameエレメント、File  Hashエレメント、Offsetエレメント、File  Data  Sizeエレメント、およびFile  Dataエレメントを備える。
【０２５８】
Commandエレメントとしては、リードアンドストア応答のＩＤが設定される。Response  Numberエレメント、Resultエレメント、File  Data  Sizeエレメント、およびFile  Dataエレメントは、リード応答フレームの同名のエレメントと同じ意味を有する。
【０２５９】
File  Name  Lengthエレメントは、ファイル名の長さである。File  Nameエレメントは、ファイル名である。File  Hashエレメントは、ファイルのハッシュ値である。Offsetエレメントは、ファイルの先頭からのオフセットであり、File  Dataエレメントがファイルのどの位置の情報であるかを示す。
【０２６０】
（２−３−５）ステータス要求
各ノードは、他のノードのステータスを、ステータス要求を用いることによって確認することができる。ステータスは、例えば、指定されたファイルを有しているか否かである。ステータス要求は、フレーム（ステータス要求フレーム）の形式で送信される。
【０２６１】
図４５は、ステータス要求フレームの構成の一例を示す図である。図４５は、ヘッダ部の図示を省略している。つまり、図４５は、ステータス要求フレームのデータ部を示している。
【０２６２】
ステータス要求フレームは、Commandエレメント、Request  Numberエレメント、File  Name  Lengthエレメント、およびFile  Nameエレメントを備える。
【０２６３】
Commandエレメントとしては、ステータス要求を示すＩＤが設定される。Request  Numberエレメント、File  Name  Lengthエレメント、およびFile  Nameエレメントは、他の要求の同名のエレメントと同様の意味を有する。ステータス要求フレームの送信元は、File  Name  Lengthエレメント、およびFile  Nameエレメントを用いることによってファイルを指定することができる。
【０２６４】
（２−３−６）ステータス応答
ステータス要求フレームのあて先がステータス要求フレームを受信すると、ステータス応答を送信する。ステータス応答は、フレーム（ステータス応答フレーム）の形式で送信される。
【０２６５】
図４６は、ステータス応答フレームの構成の一例を示す図である。なお、本図では、ヘッダ部の図示を省略している。つまり、図４６は、ステータス応答フレームのデータ部を示している。
【０２６６】
ステータス応答フレームは、Commandエレメント、Response  Numberエレメント、Resultエレメント、File  Hashエレメント、File  Name  Lengthエレメント、File  Nameエレメント、File  Sizeエレメント、Last  Updateエレメント、およびTypeエレメントを備える。
【０２６７】
Commandエレメントとしては、ステータス応答を示すＩＤが設定される。Response  Numberエレメント、Resultエレメント、File  Hashエレメント、File  Name  Lengthエレメント、File  Nameエレメント、およびFile  Sizeエレメントは、他の応答の同名のエレメントと同じ意味を有する。
【０２６８】
Last  Updateエレメントは、ファイルの最終更新の時刻である。Last  Updateエレメントには、例えば、ファイル情報３３に記載された更新日時が設定される。
【０２６９】
Typeエレメントには、ファイル情報３３に記載されたファイルタイプが設定される。
【０２７０】
（２−３−７）ファイルのライトの動作
ユーザ３００からファイルのライトが指示されると、指示されたデータは、各ノードの協働により、いずれか１つのＷＳＤ１００のストレージに格納される。指示されたデータのライトを実現するための各ノードの動作を以下に説明する。
【０２７１】
ゲートウェイ２００は、ユーザ３００からのライトの指示を受信する。ゲートウェイ２００は、ユーザ３００からライトの指示を受信すると、次に説明する動作を実行する。
【０２７２】
図４７は、ファイルのライトの際のゲートウェイ２００の動作の一例を説明するフローチャートである。本図および図４８の説明において、ユーザ３００からライトが指示されたファイルを、対象ファイルと表記する。また、対象ファイルが格納されるＷＳＤ１００を、対象ＷＳＤ１００と表記する。
【０２７３】
まず、ゲートウェイ２００は、各ノードにブロードキャストでステータス要求を送信することによって、各ノードのステータスを確認する（Ｓ５０１）。
【０２７４】
具体的には、例えば、ゲートウェイ２００は、対象ファイルを指定してステータス要求をブロードキャストで送信する。各ノードは、ステータス要求を受信すると、対象ファイルの有無を記載したステータス応答をユニキャストで返信する。これによって、ゲートウェイ２００は、各ノードが対象ファイルを有しているか否かを知ることができる。
【０２７５】
続いて、ゲートウェイ２００は、対象ファイルを格納させるＷＳＤ１００、つまり対象ＷＳＤ１００を決定する（Ｓ５０２）。
【０２７６】
具体的には、ゲートウェイ２００は、対象ファイルを有するＷＳＤ１００が存在する場合には、そのＷＳＤ１００を対象ＷＳＤ１００として決定する。対象ファイルを有するＷＳＤ１００が存在しない場合には、ゲートウェイ２００は、転送経路の第１のメトリックと、空き容量と、に基づいて、対象ＷＳＤ１００を決定する。例えば、ゲートウェイ２００は、転送経路の第１のメトリックができるだけ小さく、かつ対象ファイルのサイズよりも大きい空き容量を有するＷＳＤ１００を、対象ＷＳＤ１００として決定する。転送経路の第１のメトリックと、空き容量と、は、第１ルーティングテーブル３１に記載されている。
【０２７７】
例えば、ゲートウェイ２０１が図６に示される第１ルーティングテーブル３１ｂを有し、１００Ｍｂｙｔｅのサイズのファイル＃１のライトが指示された場合、図６に示される第１ルーティングテーブル３１ｂに基づき、第１メトリックが小さく、かつ１００Ｍｂｙｔｅ以上の空き容量を有するＷＳＤ１００として、ＷＳＤ１０３を選択する。そして、ゲートウェイ２０１は、選択されたＷＳＤ１０３を、対象ＷＳＤ１００として決定する。
【０２７８】
続いて、ゲートウェイ２００は、対象ＷＳＤ１００を宛先としたライト要求を生成して、生成したライト要求を第１ルーティングテーブル３１ｂに従って送信する（Ｓ５０３）。そして、ゲートウェイ２００は動作を終了する。
【０２７９】
なお、ゲートウェイ２００は、ライト要求を送信後、対象ＷＳＤ１００からライトが成功したか否かなどを示すライト応答を受信して、当該ライト応答の内容をユーザ３００に通知してもよい。ライト応答に関する動作についてはここでは省略する。
【０２８０】
ライト要求は、各ノードの第１ルーティングテーブル３１ａに従って転送されて、あて先のＷＳＤ１００に到達する。
【０２８１】
図４８は、ライト要求のあて先のＷＳＤ１００（対象ＷＳＤ１００）の動作の一例を示すフローチャートである。本図に示されるように、対象ＷＳＤ１００は、ライト要求を受信すると、ライト要求に含まれる対象ファイルを自身が備えるストレージ２０に保存する（Ｓ６０１）。
【０２８２】
そして、対象ＷＳＤ１００は、ファイル情報３３を更新する（Ｓ６０２）。つまり、対象ＷＳＤ１００は、ファイル情報３３に、対象ファイルのファイル名、更新日時、およびファイルタイプなどを書き込む。なお、対象ファイルのファイルタイプは「オリジナル」である。
【０２８３】
Ｓ６０２によって、対象ＷＳＤ１００の動作が完了する。
【０２８４】
図４９は、ファイル＃１が対象ファイルであり、ＷＳＤ１０３が対象ＷＳＤである場合に、図４７の処理と図４８の処理とが完了した時点のストレージシステム１の状態を説明するための模式図である。本図に示されるように、ファイル＃１がＷＳＤ１０３のみに格納されていることが読み取れる。
【０２８５】
（２−３−８）ファイルのリードの動作
ユーザ３００からファイルのリードが指示されると、各ノードの協働により、指示されたデータを有するＷＳＤ１００から当該データがリードされ、ゲートウェイ２００を介してユーザ３００に出力される。以下では、このリードにかかる一連の動作を説明する。
【０２８６】
ゲートウェイ２００は、ユーザ３００からのリードの指示を受信する。ゲートウェイ２００は、ユーザ３００からリードの指示を受信すると、次に説明する動作を実行する。
【０２８７】
図５０は、ファイルのリードの際のゲートウェイ２００の動作の一例を説明するフローチャートである。図５０〜図５２の説明において、ユーザ３００からリードが指示されたファイルを、対象ファイルと表記する。なお、対象ファイルは、ファイルタイプがオリジナルであるファイルだけでなく、ファイルタイプがコピーであるファイルをも含むこととする。また、対象ファイルをリードするＷＳＤ１００を、対象ＷＳＤ１００と表記する。
【０２８８】
まず、ゲートウェイ２００は、ブロードキャストでステータス要求を各ノードへ送信することによって、対象ファイルを所有するＷＳＤ１００を確認する（Ｓ７０１）。
【０２８９】
具体的には、例えば、ゲートウェイ２００は、対象ファイルを指定してステータス要求をブロードキャストで送信する。各ノードは、ステータス要求を受信すると、対象ファイルの有無やファイルタイプなどを記載したステータス応答をユニキャストで返信する。これによって、ゲートウェイ２００は、対象ファイルを所有している１以上のＷＳＤ１００を知ることができる。
【０２９０】
続いて、ゲートウェイ２００は、対象ファイルを所有している１以上のＷＳＤ１００のうちから、転送経路の第１のメトリックが最も小さいＷＳＤ１００を、対象ファイルをリードするＷＳＤ１００（対象ＷＳＤ１００）として特定する（Ｓ７０２）。第１のメトリックは、第１ルーティングテーブル３１を参照することによって得ることができる。
【０２９１】
続いて、ゲートウェイ２００は、対象ファイルをリードする指示の間隔が所定のしきい値を下回ったか否かを判定する（Ｓ７０３）。
【０２９２】
対象ファイルをリードする指示の間隔とは、ゲートウェイ２００は、自身の接続された一のユーザ３００から対象ファイルをリードする指示を受信してから、当該一のユーザ３００または自身の接続された他のユーザ３００から対象ファイルをリードする指示を受信するまでの時間をいう。つまり、Ｓ７０３では、ゲートウェイ２００は、今回と同じか異なるユーザ３００から前回に対象ファイルをリードする指示を受信してから今回に対象ファイルをリードする指示を受信するまでの時間が所定のしきい値を下回ったか否かを判定する。
【０２９３】
対象ファイルをリードする指示の間隔が所定のしきい値を下回っていないと判定された場合（Ｓ７０３：Ｎｏ）、ゲートウェイ２００は、対象ＷＳＤ１００をあて先としたリード要求を生成して、当該リード要求を第１ルーティングテーブル３１ｂに従って送信する（Ｓ７０４）。リード要求は、第１ルーティングテーブル３１に従って対象ＷＳＤ１００まで転送される。
【０２９４】
対象ファイルをリードする指示の間隔が所定のしきい値を下回ったと判定された場合（Ｓ７０３：Ｙｅｓ）、ゲートウェイ２００は、対象ＷＳＤ１００をあて先としたリードアンドストア要求を生成して、当該リードアンドストア要求を第１ルーティングテーブル３１ｂに従って送信する（Ｓ７０５）。リードアンドストア要求は、第１ルーティングテーブル３１に従って対象ＷＳＤ１００まで転送される。
【０２９５】
Ｓ７０４またはＳ７０５の後、ゲートウェイ２００は、応答（リード応答またはリードアンドストア応答）を受信する（Ｓ７０６）。ゲートウェイ２００は、応答に含まれる対象ファイルを、指示の送信元のユーザ３００に出力し（Ｓ７０７）、動作を終了する。
【０２９６】
図５１は、ファイルのリードの際の要求（リード要求またはリードアンドストア要求）のあて先のＷＳＤ１００（対象ＷＳＤ１００）の動作の一例を示すフローチャートである。
【０２９７】
対象ＷＳＤ１００は、リード要求を受信すると（Ｓ８０１：Ｙｅｓ）、対象データを自身のストレージ（ストレージ２０）からリードし、ゲートウェイ２００をあて先としたリード応答を生成し、生成したリード応答を、第１ルーティングテーブル３１ａに従って送信する（Ｓ８０２）。
【０２９８】
リード応答は、対象データを含む。リード応答は、各ノードによって、第１ルーティングテーブル３１ａに従って転送される。これによって、リード応答は、通信の品質が最も優れた転送経路に沿ってゲートウェイ２００まで転送される。
【０２９９】
対象ＷＳＤ１００は、リード要求ではなくリードアンドストア要求を受信すると（Ｓ８０１：Ｎｏ、Ｓ８０３：Ｙｅｓ）、対象データを自身のストレージ（ストレージ２０）からリードし、ゲートウェイ２００をあて先としたリードアンドストア応答を生成し、生成したリードアンドストア応答を、第２ルーティングテーブル３２に従って送信する（Ｓ８０４）。
【０３００】
リードアンドストア応答は、対象データを含む。リードアンドストア応答は、各ノードによって、第２ルーティングテーブル３２に従って転送される。これによって、リードアンドストア応答は、通信の品質とストレージの空き容量とを考慮した転送経路に沿ってゲートウェイ２００まで転送される。
【０３０１】
対象ＷＳＤ１００は、Ｓ８０２またはＳ８０４の処理の後、動作を終了する。
【０３０２】
図５２は、ファイルのリードの際の応答（リード応答またはリードアンドストア応答）を中継する中継ＷＳＤ１００の動作の一例を示すフローチャートである。
【０３０３】
中継ＷＳＤ１００は、リード応答を受信すると（Ｓ９０１：Ｙｅｓ）、そのリード応答を、第１ルーティングテーブル３１ａに従って転送する（Ｓ９０２）。
【０３０４】
中継ＷＳＤ１００は、リード応答ではなくリードアンドストア応答を受信すると（Ｓ９０１：Ｎｏ、Ｓ９０３：Ｙｅｓ）、リードアンドストア応答に含まれている対象ファイルのコピーを生成して、生成したコピーを自身のストレージ２０に保存する（Ｓ９０４）。そして、中継ＷＳＤ１００は、対象ファイルのコピーの保存に応じてファイル情報３３を更新する（Ｓ９０５）。
【０３０５】
つまり、中継ＷＳＤ１００は、ファイル情報３３に、対象ファイルのファイル名、更新日時、およびファイルタイプなどを書き込む。なお、Ｓ９０５の場合、対象ファイルのファイルタイプは「コピー」である
【０３０６】
Ｓ９０５に続いて、中継ＷＳＤ１００は、第２ルーティングテーブル３２に従ってリードアンドストア応答を転送する（Ｓ９０６）。
【０３０７】
Ｓ９０２またはＳ９０６の後、中継ＷＳＤ１００は、動作を終了する。
【０３０８】
ゲートウェイ２００がリードアンドストア要求を使用した場合、リードアンドストア応答によって、各中継ＷＳＤ１００に対象ファイルのコピーが保存される。
【０３０９】
図５３は、ファイル＃１がＷＳＤ１０３に保持され、ゲートウェイ２０２がＷＳＤ１０３にファイル＃１のリードをリードアンドストア要求によって要求した場合にファイル＃１のコピーが生成・保存される様子を示す図である。
【０３１０】
ＷＳＤ１０３は、リードアンドストア要求を受信すると、リードアンドストア応答を生成して、生成したリードアンドストア応答を送信する。リードアンドストア応答は、第２ルーティングテーブル３２に従って転送される。つまり、リードアンドストア応答は、図７を用いて説明したように、ＷＳＤ１０３からＷＳＤ１０６、ＷＳＤ１０９、ＷＳＤ１０８、およびＷＳＤ１０７をこの順番で経由してゲートウェイ２０２に至る転送経路（図５３の点線が示す経路）に沿って転送される。その結果、図５３に示されるように、リードアンドストア応答を中継したＷＳＤ１０６、ＷＳＤ１０９、ＷＳＤ１０８、およびＷＳＤ１０７のそれぞれに、ファイル＃１（ファイル＃１のコピー）が保存される。
【０３１１】
以降にファイル＃１のリードが指示された場合、ゲートウェイ２００は、ＷＳＤ１０３、ＷＳＤ１０６、ＷＳＤ１０９、ＷＳＤ１０８、およびＷＳＤ１０７のうちからリード要求またはリードアンドストア要求のあて先を選ぶことができる。
【０３１２】
（２−３−９）ファイルのコピーの処理
前述したように、リードアンドストア要求が使用されると、中継ＷＳＤ１００にファイルのコピーが保存される。しかしながら、ＷＳＤ１００に多数のファイルのコピーが保存されると、そのＷＳＤ１００のストレージの空き容量が枯渇する。
【０３１３】
そこで、実施形態では、各ＷＳＤ１００は、ファイルのコピーが保存されてからの経過時間に応じて当該コピーを自発的に消去するように構成される。
【０３１４】
図５４は、ＷＳＤ１００がファイルのコピーを消去する動作の一例を示すフローチャートである。まず、ＷＳＤ１００は、保存されてから所定時間が経過した、ファイルタイプが「コピー」であるファイルがあるか否かを判定する（Ｓ１００１）。Ｓ１００１では、ＷＳＤ１００は、自身が保持するファイル情報３３を参照することによって、ファイルタイプが「コピー」であるファイルを検出する。
【０３１５】
保存されてから所定時間が経過した、ファイルタイプが「コピー」であるファイルがないと判定された場合（Ｓ１００１：Ｎｏ）、Ｓ１００１の判定処理が再び実行される。
【０３１６】
保存されてから所定時間が経過した、ファイルタイプが「コピー」であるファイルがあると判定された場合（Ｓ１００１：Ｙｅｓ）、ＷＳＤ１００は、そのファイルをストレージから削除する（Ｓ１００２）。そして、ＷＳＤ１００は、Ｓ１００２の動作に応じて、ファイル情報３３を更新する（Ｓ１００３）。つまり、ＷＳＤ１００は、削除したファイルに関する記録をファイル情報３３から削除する。
【０３１７】
Ｓ１００３の後、Ｓ１００１の判定処理が再び実行される。
【０３１８】
以上述べたように、第１の実施形態によれば、ＷＳＤ１００は、通信の品質を示す第１のメトリックを空き容量に基づいて補正することによって第２のメトリックを取得し、第２のメトリックに基づいて通信の経路を決定する。
【０３１９】
これによって、ＷＳＤ１００は、空き容量を考慮した転送経路で情報を転送することが可能となる。
【０３２０】
なお、第２のメトリックは、第１のメトリックが、空き容量に加えてＷＳＤ１００の寿命情報に基づいて補正されることによって取得されてもよい。寿命情報は、例えば、Ｓ.Ｍ.Ａ.Ｒ.Ｔ.情報などから入手できる不良セクタ数である。第２のメトリックは、寿命が近いストレージ装置１００ほど（例えば不良セクタ数が多いほど）第２のメトリックが大きくなるように算出される。第２のメトリックの算出に寿命情報が使用されることによって、故障しそうなＷＳＤ１００をできるだけ回避した転送経路でリードアンドストア応答を転送することが可能となる。
【０３２１】
また、ＷＳＤ１００は、他のノードからMetric  With  Free  Space  Flagが１であるProactive  Path  RequestやMetric  With  Free  Space  Flagが１であるProactive  Path  Replyなどの信号を受信すると、当該信号に含まれるMetricエレメントに当該信号の転送元までの第２のメトリックを加算する。
【０３２２】
これによって、転送経路のメトリックとして、空き容量を考慮したメトリックを得ることが可能となる。つまり、空き容量を考慮した転送経路で情報を転送することが可能となる。
【０３２３】
なお、第１のメトリックを補正する処理は、式（２）に例示されるように、自身のノードの空き容量と、信号の転送元の空き容量と、に基づいて補正する処理である。
【０３２４】
より具体的には、第１のメトリックを補正する処理は、第１のメトリックを、自身のノードの空き容量と、信号の転送元の空き容量と、の平均値で除算する処理を含む。
【０３２５】
これによって、第２のメトリックは、転送経路の第２のメトリックは、転送経路内のノードの空き容量が大きいほど、小さくなる。
【０３２６】
また、ＷＳＤ１００は、Metric  With  Free  Space  Flagが１であるProactive  Path  RequestやMetric  With  Free  Space  Flagが１であるProactive  Path  Replyなどの信号のMetricエレメントを、当該Metricエレメントに当該信号の転送元までの第２のメトリックを加算して得られる値で更新し、更新後の当該信号を転送元とは異なるノードに転送する。
【０３２７】
Metric  With  Free  Space  Flagが１であるProactive  Path  RequestやMetric  With  Free  Space  Flagが１であるProactive  Path  Replyなどの信号が転送される毎にMetricエレメントに第２のメトリックが合算されるので、転送経路の第２のメトリックの合計を得ることが可能となる。
【０３２８】
また、ＷＳＤ１００は、Metric  With  Free  Space  Flagが１であるProactive  Path  Requestの発行元のノードを“Destination”とし、当該Proactive  Path  Requestの転送元のノードを“Next  Hop”とし、更新された後の第２のメトリックを“Second  Metric”としたレコードを第２ルーティングテーブル３２に追加する。
【０３２９】
これによって、ＷＳＤ１００は、Metric  With  Free  Space  Flagが１であるProactive  Path  Requestを受信した場合、第２ルーティングテーブル３２を生成することができる。
【０３３０】
また、ＷＳＤ１００は、リードアンドストア要求を受信し、当該リードアンドストア要求のあて先が自身である場合、リードアンドストア要求に対する応答であるリードアンドストア応答を生成する。そして、ＷＳＤ１００は、生成したリードアンドストア応答を、第２ルーティングテーブル３２に従って送信する。
【０３３１】
これによって、リードアンドストア応答を中継ノードの空き容量を考慮した転送経路で転送することが可能となる。
【０３３２】
また、ＷＳＤ１００は、リードアンドストア応答を受信した場合、リードアンドストア応答に含まれるファイルのコピーを生成して、当該コピーをストレージ２０に格納する。
【０３３３】
これによって、リードアンドストア要求によって要求されたファイルは、複数のＷＳＤ１００に格納されるので、当該ファイルのリードの指示の頻度が高い場合であっても、１つのＷＳＤ１００に処理が集中することが防止される。つまり、ストレージシステム１の性能が向上する。
【０３３４】
また、ゲートウェイ２００は、ユーザ３００からファイルのリードが指示された場合、リードアンドストア要求を送信することができる。リードアンドストア要求のあて先のＷＳＤ１００は、予め第２ルーティングテーブル３２を生成して有している。当該ＷＳＤ１００は、リードアンドストア要求を受信すると、ゲートウェイ２００をあて先とした対象ファイルを含むリードアンドストア応答を生成し、生成したリードアンドストア応答を第２ルーティングテーブル３２に従って送信する。つまり、ＷＳＤ１００は、隣接ＷＳＤ１００のうちの、第２のメトリックが最小となる転送経路を構成するＷＳＤ１００に、リードアンドストア応答を転送する。
【０３３５】
これによって、リードアンドストア応答を中継ノードの空き容量を考慮した転送経路で転送することが可能となる。
【０３３６】
ＷＳＤ１００は、リードアンドストア応答を受信した場合、リードアンドストア応答に含まれるファイルのコピーを生成して、当該コピーをストレージ２０に格納する。ゲートウェイ２００は、ユーザ３００から同じファイルのリードが再び指示された場合、ファイルのコピーを所有するＷＳＤ１００をあて先としたリード要求またはリードアンドストア要求を生成して送信することができる。
【０３３７】
これによって、同じファイルのリードの指示の頻度が高い場合であっても、１つのＷＳＤ１００に処理が集中することが防止される。
【０３３８】
また、ＷＳＤ１００は、ファイルのコピーを保持したタイミングからの経過時間に基づくタイミングで当該コピーを削除する。
【０３３９】
これによって、ファイルのコピーが大量に保存されることによってストレージ２０の空き容量が枯渇することが防止される。
【０３４０】
（第２の実施形態）
リードアンドストア要求が使用されることによって、同じファイルが複数のＷＳＤ１００に保存され得る。リードが指示されたファイルが複数のＷＳＤ１００に保存されている場合に、ゲートウェイ２００は、複数のＷＳＤ１００から同じファイルのそれぞれ異なる一部をリードして、複数のＷＳＤ１００から転送されてきたそれぞれ異なる一部を結合して出力してもよい。
【０３４１】
例えば、図５３に示されるようにファイル＃１がＷＳＤ１０３、ＷＳＤ１０６、ＷＳＤ１０７、ＷＳＤ１０８、およびＷＳＤ１０９に保存されている場合を考える。
【０３４２】
ゲートウェイ２０２は、ファイル＃１のリードが指示された場合、まず、ステータス要求を用いることによって、ＷＳＤ１０３、ＷＳＤ１０６、ＷＳＤ１０７、ＷＳＤ１０８、およびＷＳＤ１０９がファイル＃１を有していることを知る。
【０３４３】
さらに、ゲートウェイ２０２は、ＷＳＤ１０３、ＷＳＤ１０６、ＷＳＤ１０７、ＷＳＤ１０８、およびＷＳＤ１０９のそれぞれからゲートウェイ２０２までの転送経路を返信させる。これによって、図５５に示される、ファイル＃１の所有者、ネクストホップ、第１のメトリック、および転送経路を示した表を生成する。なお、転送経路は、traceroute等の既存のネットワークコマンドなどによって得ることができる。
【０３４４】
ゲートウェイ２０２は、図５５に示される表から、転送経路が重複せず、かつ転送経路の第１のメトリックが小さいファイル＃１の複数の所有者を、要求（リード要求またはリードアンドストア要求）のあて先として選択する。
【０３４５】
図５５の表の場合、例えばゲートウェイ２０２は、ＷＳＤ１０６とＷＳＤ１０７とを要求のあて先として選択する。
【０３４６】
例えば、ＷＳＤ１０３およびＷＳＤ１０９は、ＷＳＤ１０５、ＷＳＤ１０４、ゲートウェイ２０２においてＷＳＤ１０６の場合と転送経路が重複する。また、ＷＳＤ１０３およびＷＳＤ１０９の転送経路の第１のメトリックは、それぞれ、ＷＳＤ１０６の場合よりも大きい。よって、ＷＳＤ１０３およびＷＳＤ１０９は、要求のあて先として選択されない。
【０３４７】
また、ＷＳＤ１０８は、ＷＳＤ１０７とＷＳＤ１０２とにおいてＷＳＤ１０７の場合と転送経路が重複する。また、ＷＳＤ１０８の転送経路の第１のメトリックは、ＷＳＤ１０６の場合よりも大きい。よって、ＷＳＤ１０７は、要求のあて先として選択されない。
【０３４８】
転送経路が重複する場合、重複する部分の中継ノードにおける必要な処理の量が増加するため、転送速度が低下する。その場合、１つのＷＳＤ１００にファイルを送信させた場合にくらべてスループットが低下する可能性がある。第２の実施形態では、応答の転送経路が重複しない複数のＷＳＤ１００が要求のあて先として選択されることで、スループットの低下が抑制される。
【０３４９】
例えば、ゲートウェイ２０２は、ＷＳＤ１０６をあて先とした、ファイル＃１の前半部分をリードする要求を生成し、送信する。また、ゲートウェイ２０２は、ＷＳＤ１０７をあて先とした、ファイル＃１の後半部分をリードする要求を生成し、送信する。ゲートウェイ２０２は、ＷＳＤ１０６が送信した応答に含まれるファイル＃１の前半部分と、ＷＳＤ１０７が送信した応答に含まれるファイル＃１の後半部分と、を結合して、完全なファイル＃１を生成し、生成した完全なファイル＃１をユーザ３００に出力する。
【０３５０】
このように、第２の実施形態によれば、ゲートウェイ２００は、要求されたファイルのコピーを保持する２つのＷＳＤ１００のそれぞれに対して当該ファイルのそれぞれ異なる部分をリードする要求を送信する。
【０３５１】
これによって、ストレージシステム１は、要求されたファイルを早く出力することが可能となる。即ち、ストレージシステム１の性能が向上する。
【０３５２】
（第３の実施形態）
隣接ノードとの距離が長くなったり、無線ＬＡＮの電波に干渉する電波の発生源が動作を開始したりすると、ＷＳＤ１００は、通信不能となる場合がある。また、ＷＳＤ１００は、電力供給が停止した場合においても、通信不能となる。
【０３５３】
ストレージネットワークにおいて、ファイルを転送中に、当該ファイルの転送経路上の中継ＷＳＤ１００が電力供給の問題や無線の問題により通信不能となった場合、転送経路を変更することが望まれる。
【０３５４】
ＷＳＤ１００は、リードアンドストア応答を送信中に、リードアンドストア応答の転送経路上の中継ＷＳＤ１００が通信不能になった場合、リードアンドストア応答の送信を中断して、第２ルーティングテーブル３２を再生成する。つまり、ＷＳＤ１００は、それまで使用していた第２ルーティングテーブル３２を破棄し、Proactive  Path  Requestをブロードキャストで送信することによって、第２ルーティングテーブル３２を新しく生成する。
【０３５５】
新しく生成された第２ルーティングテーブル３２によれば、通信不能となったＷＳＤ１００を避けた転送経路に対応したネクストホップを知ることができる。ＷＳＤ１００は、新しく生成した第２ルーティングテーブル３２に従ってリードアンドストア応答の送信を再開する。
【０３５６】
例えば、ＷＳＤ１０３が、図８に示される第２ルーティングテーブル３２に基づいてファイル＃１を含むゲートウェイ２０２をあて先としたリードアンドストア要求を送信している最中にＷＳＤ＃６が通信不能となったことを考える。
【０３５７】
図８に示される第２ルーティングテーブル３２によれば、リードアンドストア要求は、ＷＳＤ１０６、ＷＳＤ１０９、ＷＳＤ１０８、ＷＳＤ１０７をこの順番で経由してゲートウェイ２０２に至る転送経路で転送される。
【０３５８】
そのリードアンドストア要求の転送の最中にＷＳＤ１０６が通信不能となった場合、図５６に示されるように、ＷＳＤ１０７、ＷＳＤ１０８、およびＷＳＤ１０９にファイル＃１の前半部分が格納された状態でリードアンドストア要求の送信が停止される。
【０３５９】
すると、ＷＳＤ１０３は、ＷＳＤ１０６が通信不能となるまで使用していた第２ルーティングテーブル３２を破棄する。そして、ＷＳＤ１０３は、Proactive  Path  Requestをブロードキャストで送信することによって、第２ルーティングテーブル３２を再生成する。
【０３６０】
図５７は、再生成された第２ルーティングテーブル３２を示す図である。図８に示される第２ルーティングテーブル３２には、ネクストホップとしてＷＳＤ１０６が記録されたレコードが含まれている。図５７の再生成された第２ルーティングテーブル３２には、ネクストホップとしてＷＳＤ１０６が記録されたレコードが含まれていない。即ち、再生成された第２ルーティングテーブル３２に記録された全てのレコードは、ＷＳＤ１０６を経由しないものとなっている。
【０３６１】
ＷＳＤ１０３は、リードアンドストア要求の送信を再開する。ＷＳＤ１０３は、図５７に示される第２ルーティングテーブル３２に基づき、ＷＳＤ１０２にリードアンドストア要求を送信する。これによって、送信の再開後のリードアンドストア要求は、ＷＳＤ１０２およびＷＳＤ１０１をこの順で経由してゲートウェイ２０２に至る転送経路に沿って転送される。
【０３６２】
図５８は、ファイル＃１を含むリードアンドストア応答を送信完了した後のストレージシステム１の状態を示す模式図である。リードアンドストア応答の送信の再開後は、リードアンドストア応答は、ＷＳＤ１０２およびＷＳＤ１０１を経由する。これによって、ＷＳＤ１０２およびＷＳＤ１０１は、ファイル＃１の後半部分を保持することになる。
【０３６３】
その後、ゲートウェイ２０２は、ファイル＃１をリードする指示を受信した場合、ステータス要求をブロードキャストで送信するなどによってファイル＃１を所有するＷＳＤ１００を確認する。これによって、ゲートウェイ２０２は、例えば図５９に示されるように、ＷＳＤ１０１、ＷＳＤ１０２、ＷＳＤ１０７、ＷＳＤ１０８、およびＷＳＤ１０９のそれぞれにファイル＃１の一部が保持されており、ＷＳＤ１０３にファイル＃１のオリジナルが保持されていることを知る。
【０３６４】
図５９によれば、ＷＳＤ１０１までの転送経路の第１のメトリックは２０であり、ＷＳＤ１０７までの転送経路の第１のメトリックは４０であり、それぞれの第１のメトリックは、ファイル＃１のオリジナルを所有するＷＳＤ１０３までの転送経路の第１のメトリックよりも小さいことが読み取れる。また、ＷＳＤ１０１およびＷＳＤ１０７のそれぞれが所有するファイル＃１の一部を連結すれば、ファイル＃１が復元できることが読み取れる。
【０３６５】
そこで、ゲートウェイ２０２は、ＷＳＤ１０１とＷＳＤ１０７とに対してファイル＃１を取得するようにリード要求またはリードアンドストア要求を送信する。これによって、ゲートウェイ２０２は、ＷＳＤ１０１とＷＳＤ１０７とに部分的に保存されていたファイル＃１を連結してユーザ３００に出力することができる。
【０３６６】
なお、以上の説明においては、IEEE  802.11sを基本として実施形態の技術を適用した場合について説明した。実施形態の技術は、任意の規格に基づいて通信を行うストレージ装置１００、ゲートウェイ２００、ストレージシステム１に適用することができる。実施形態の各ノードが送受信する信号（各種要求や応答）のフレーム構成は、以上の述べたフレーム構成だけに限定されない。実施形態の各ノードが送受信する信号（各種要求や応答）のフレーム構成に対しては、任意のエレメントが追加されたり、任意のエレメントが削除され得る。
【０３６７】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【０３６８】
１  ストレージシステム、１０  コントローラ、１１  デバイスコントローラ、１２  ＣＰＵ、１３  無線通信装置、１４  ＲＡＭ、１５  ホストコントローラ、２０  ストレージ、３１，３１ａ，３１ｂ  第１ルーティングテーブル、３２  第２ルーティングテーブル、３３  ファイル情報、３４  ルーティングテーブル、４１  ＣＰＵ、４２  無線通信装置、４３  メモリ、１００，１０１〜１０９  ストレージ装置、２００，２０１，２０２  ゲートウェイ、３００，３０１〜３０５  ユーザ、４００  カードリーダ、５００  モバイルバッテリ、６００，６０１，６０２  ノード。
【図１】
2020046927.tif 000005
【図２】
2020046927.tif 000006
【図３】
2020046927.tif 000007
【図４】
2020046927.tif 000008
【図５】
2020046927.tif 000009
【図６】
2020046927.tif 000010
【図７】
2020046927.tif 000011
【図８】
2020046927.tif 000012
【図９】
2020046927.tif 000013
【図１０】
2020046927.tif 000014
【図１１】
2020046927.tif 000015
【図１２】
2020046927.tif 000016
【図１３】
2020046927.tif 000017
【図１４】
2020046927.tif 000018
【図１５】
2020046927.tif 000019
【図１６】
2020046927.tif 000020
【図１７】
2020046927.tif 000021
【図１８】
2020046927.tif 000022
【図１９】
2020046927.tif 000023
【図２０】
2020046927.tif 000024
【図２１】
2020046927.tif 000025
【図２２】
2020046927.tif 000026
【図２３】
2020046927.tif 000027
【図２４】
2020046927.tif 000028
【図２５】
2020046927.tif 000029
【図２６】
2020046927.tif 000030
【図２７】
2020046927.tif 000031
【図２８】
2020046927.tif 000032
【図２９】
2020046927.tif 000033
【図３０】
2020046927.tif 000034
【図３１】
2020046927.tif 000035
【図３２】
2020046927.tif 000036
【図３３】
2020046927.tif 000037
【図３４】
2020046927.tif 000038
【図３５】
2020046927.tif 000039
【図３６】
2020046927.tif 000040
【図３７】
2020046927.tif 000041
【図３８】
2020046927.tif 000042
【図３９】
2020046927.tif 000043
【図４０】
2020046927.tif 000044
【図４１】
2020046927.tif 000045
【図４２】
2020046927.tif 000046
【図４３】
2020046927.tif 000047
【図４４】
2020046927.tif 000048
【図４５】
2020046927.tif 000049
【図４６】
2020046927.tif 000050
【図４７】
2020046927.tif 000051
【図４８】
2020046927.tif 000052
【図４９】
2020046927.tif 000053
【図５０】
2020046927.tif 000054
【図５１】
2020046927.tif 000055
【図５２】
2020046927.tif 000056
【図５３】
2020046927.tif 000057
【図５４】
2020046927.tif 000058
【図５５】
2020046927.tif 000059
【図５６】
2020046927.tif 000060
【図５７】
2020046927.tif 000061
【図５８】
2020046927.tif 000062
【図５９】
2020046927.tif 000063