ルーティングプランが作成された後にメッシュネットワークにおいて他のデバイスとの間で協調通信を可能にするデバイスが実施する方法500であって、前記ルーティングプランに基づいてパケットを受信することができる利用可能な近隣デバイスを決定する段階504と、前記利用可能な近隣デバイスのうち協調するデバイスを決定する段階506と、協調すると決定した他のデバイスに前記パケットを転送する段階508とを備える方法。前記ルーティングプランの作成は、ルーティングテーブルに基づいて行われる請求項1に記載の方法。前記ルーティングプランの作成は、前記ルーティングプランを前記利用可能な近隣デバイスに送信することを含む請求項1に記載の方法。前記利用可能な近隣デバイスを決定する段階は、前記デバイスに最も近接している近隣デバイスを含む請求項1に記載の方法。前記利用可能な近隣デバイスを決定する段階は、信号品質に基づいて行われる請求項1に記載の方法。前記利用可能な近隣デバイスのうち協調するデバイスを決定する段階は、確率転送関数に基づいて実行される請求項1に記載の方法。前記確率転送は、前記ノードにおいてランダムに生成された数を前記確率転送関数によって決定された値と比較することを含む請求項6に記載の方法。前記転送する段階を実行した後で、前記ルーティングプランにおいてチャネル容量を判断する段階をさらに備える請求項1に記載の方法。メッシュネットワークにおいて他のデバイスとの協調を決定するデバイス400であって、1以上のプロセッサ402と、前記1以上のプロセッサに結合されているメモリ404とを備え、前記メモリは、ルーティングテーブル408と、前記ルーティングテーブルから作成されるルーティングプランと、前記デバイスへの近接性とに基づいて、協調する相手である前記他のデバイスを決定するアルゴリズム410とを有するデバイス。前記デバイスおよび前記他のデバイスは、無線インターフェースを介して通信する請求項9に記載のデバイス。前記メモリは、専用チップセットである請求項9に記載のデバイス。前記ルーティングテーブルは、所定のものである請求項9に記載のデバイス。前記アルゴリズムは、確率転送関数を含む請求項9に記載のデバイス。前記確率転送関数は、認識関数である請求項13に記載のデバイス。前記確率転送関数から導出される値を、ランダムに生成された数と比較する請求項13に記載のデバイス。命令を格納している1以上のコンピュータ可読格納媒体であって、前記命令が1以上のプロセッサで実行されると、前記1以上のプロセッサは、近隣デバイスに渡すルーティングプランを作成する処理502と、データパケットを受信することができる利用可能な近隣デバイスを判断する処理504と、前記利用可能な近隣デバイスのうち実際に前記データパケットを送信するデバイスを決定する処理506と、前記データパケットを、前記データパケットの受信相手として決定された前記デバイスに転送する処理508とを含む動作を実行する1以上のコンピュータ可読格納媒体。前記ルーティングプランは、所定のルーティングテーブルに基づいて決定する請求項16に記載の1以上のコンピュータ可読格納媒体。前記決定する処理は、NBR_RHが前記利用可能な近隣デバイスのうち一の近隣デバイスであり、stimulusが、コーディング変調レート、サービス品質、信号ノイズ比、および電池電力のうち1以上の関数であり、thresholdは、ネットワーク混雑度に比例して決まる場合、で表される確率転送式に基づいて行われる請求項16に記載の1以上のコンピュータ可読格納媒体。前記転送する処理は、前記データパケットを符号化することを含む請求項16に記載の1以上のコンピュータ可読格納媒体。前記動作は、モバイルメッシュネットワーク内のノードによって実行される請求項16に記載の1以上のコンピュータ可読格納媒体。本明細書で説明する実施形態は、ユーザのサービス品質QoS、スループットを改善し、モバイルエリアネットワークMANET等の動的メッシュネットワークでのリンクの停止を低減することを目的としている。オーバーヘッドが少ない群知能と呼ばれる分散協調処理を実現することができる。特定の実施形態によると、マルチホップルーティングプランによって接続が構築または定義されるネットワークでは、動的に混乱が発生するホップに対処するべく補償を実行することができる。特に、通信システム、および、しきい値を利用したリソース割り当てモデルでの協調を実現することができる。従来、ノード間の協調は、メッシュネットワークにおいてマルチホッププロトコルを利用する通信システムにおいて実施され得るが、協調のために係るコストが大きい。このため、ハイブリッド自動再送要求HARQが協調方法/方式の実施をトリガしてオーバーヘッドを削減し、帯域幅/電力効率を改善することが提案されている。しきい値を利用したリソース割り当てモデルは、蟻社会の観察結果に基づいたモデルである。蟻社会では、それぞれの蟻が、他の蟻とコミュニケーションを取ることなく、コロニーの要求を最も満たし易いタスクに対する対応および従事について、いつ、どこで、どのようにして行うかについて判断を下すことができる。この比喩では、ノードが蟻で、ネットワークがコロニーである。言い換えると、ノードが、別のノードとどのように協調するかを判断する。まとめると、採用する概念は、ネットワーク内のノードの協調通信で利用する群知能と見なすことができる。この概念は、MANETまたはモバイルアドホックネットワークにおいて、協調するノード間でリアルタイムにハンドシェイクを行うことなく、自動的に協調を決断することが可能となる方式を提供することを目的としている。これによって、オーバーヘッドおよび干渉を発生させることなく、システムの信号ノイズ比SNRを自動的に向上させることができ、結果として、システムの信頼性が高くなる。最も効果的な支援を提供可能で、ネットワークの干渉レベルを分散方式で低減可能な協調ノードについて、判断を下すことができる。また、本明細書で説明するアルゴリズムは、MANET設定に利用すると、協調リンクで必要な再送が少なくなるように協調を発生させるべき最良リンクを特定することによって先手を取る形で協調通信を可能とするので、スループット、スペクトル効率およびエネルギー効率を高めることができる。<ネットワークの例>図1は、ノード間の協調通信のために群知能を実施するネットワーク100を示す図である。ネットワーク100は、さまざまなネットワークの1つであってよく、具体的にはモバイルエリアネットワークまたはモバイルアドホックネットワーク、一般的にはMANETと呼ばれるものであってよい。ネットワーク100は、複数のノードが追加または削除されるとしてよい。各デバイス、または、各ノードは、独立して自由に移動し、ネットワーク100内を移動すると近隣デバイスまたは近隣ノードが変化する。本例では、ノードA102、ノードB104、ノードC106、ノードD108、ノードE110、ノードF112、ノードG114、ノードH116、ノードI118、ノードJ120、ノードK122、ノードL124、ノードM126、ノードN128、ノードO130、ノードP132、ノードQ134、ノードR136、ノードS138、および、ノードT140を図示している。特定の実施例では、ノードの位置は不規則に並べることも考えられる。ノード102-140は、さまざまな通信プロトコルまたは通信規格を利用して互いに通信を実行することができる。規格の例としては、IEEE802.11および符号分割多重アクセスCDMAが挙げられる。ノード102-140は、無線インターフェースを介して通信を行う。データまたはメッセージは、さまざまな符号化方式/規格を利用して符号化され得るパケットとして送信され得る。ノード102-140は、モバイルデバイスとして、上述したようにネットワーク100内を移動することが可能である。ノード102-140は、近隣ノードに対して、ルータまたは中継デバイスとして利用可能である。ノード102-140はそれぞれ、当該ノードの利用に関係ないトラフィックつまり、パケットを転送することができる。このノードは、他のノードに対してルータとして機能する。本例では、ノードK122を、デスティネーションノード130にメッセージを送信することを希望するソースノードと見なす。ルーティングプランは、パケットを転送する中間ノードを用いて決定する。この場合、パケットは、ソースノードであるノードK122からノードL124に渡されリンク142で示す、ノードL124がこのメッセージをノードM126に中継しリンク144で示す、ノードM126はノードN128にメッセージを中継しリンク146で示す、ノードN128はノードO130にメッセージを中継するリンク148で示す。本例のルーティングプランは、ノードK122/ノードL124/ノードM126/ノードN128/ノードO130である。図2を参照すると、近隣ノードによって送信がどのようにサポートされるかを示すサブネットワークが図示されている。上述したように、MANETまたはネットワーク100は、規則的に配置されたノード102-140で構成される完全メッシュである。作成されたルーティングプランが提供されるとしてよく、それに基づいて各ノードにルーティングテーブルが提供される。本例では、各ノードは、8個の最も近い近隣ノードとのみ通信を行うことができる。例えば、ソースノードであるノードK122は、ノードF112、ノードG114、ノードL124、ノードP132およびノードQ134と通信を行う。ノードK122は、先行する3つのノード不図示と通信を行うことが可能であるが、パケット送信は前へ進むので、関連する協調ノードのみを図示している。このため、ノードF112は、リンク200および202で示すように、パケットをノードK122からノードL124へと中継する協調ノードとして利用され得る。同様に、ノードG114は、リンク204および206で示すように、同様に実行され、ノードP132は、リンク208および210で示すように同様に実行され、ノードQ134は、リンク212および214で示すように同様に実行される。このため、近隣ノードは、メッセージパケット送信をヒアリングすることができ、メッセージの送信を支援するために利用可能である。しかし、近隣ノードが支援するタイミングを決定する必要がある。近隣ノードからの協調または支援によって、パケットまたはメッセージの強度は高くなるつまり、パケット/メッセージを後続のノードに転送するノードが多くなる。具体例を挙げると、ノードによる支援/協調は、ネットワーク内で他のノードにおけるノイズが大きくなる可能性があるので、望ましくない場合があるとしてよい。どのように決定するかについては、転送関数fPforwardingを参照しつつさらに後述する。図3を参照すると、協調通信の群知能を示すサブネットワークが図示されている。具体的には、協調ノードの群移動を図示している。リンク300から326は、パケットを送信可能なパケット送信経路を示しており、本例では、短縮された経路は、ノードL124からノードO130である全経路は、上述しているように、ノードK122からノードO130である。パケットがソースノードであるノードK122からデスティネーションノードであるノードO130へと配信されるようにルーティングテーブルルーティングプランが作成されていることを考えると、ルーティングテーブルが作成された後の問題点は、ノードK122からノードO130の間のホップとなるノード間での協調により信頼性の高い通信を可能とするにはどうすればよいか、という点にあるとしてよい。このマルチホップルートでのホップのいずれかで混乱が発生すると、近隣ノードは自動的に、協調方式を開始すると決定して、マルチホップルートプランのうち失敗が発生した箇所の補償を行う。この方式について以下で説明する。近隣ノードをデスティネーションとするパケットを正しくデコードすることができるノードについては、以下で説明する蟻コロニーリソース割り当てモデルから導出した関数fPforwardingに応じて、パケットを次のホップデスティネーションに転送することを選択可能である。NBR_RHは、到達可能な近隣ノードであり、次のホップデスティネーションが直近の近隣ノードである場合であって、ルーティングテーブルに応じて現在のノードが到達可能である場合に、1の値を与えられる。それ以外は、NBR_RHは0である。可変値であるstimulusは、以下の値の関数である。パケット符号化/変調レート:符号化/変調レートが高効率化されると、メトリックレベルが高くなる。これは、パケットエラーレートの可能性が高くなるためである。QoSに応じたパケットの分類:リアルタイムパケットは、メトリックレベルが高くなる。これは、リアルタイムパケットは、正しく受信される必要があり、再送ができないためである。SNR差分=現在のノードから次のホップのノードまでのリンクの信号ノイズ比SNRの推定値-原点のノードから次のホップのノードまでのリンクのSNR推定値:SNR差分が大きくなると、メトリック値が大きくなる。これは、原点のノードと次のホップのノードとの間のリンクSNRが大きい場合には、SNR差分が小さくなり、協調は恐らく不要であることを示す。他方、原点のノードと次のホップのノードとの間のリンクSNRが小さい場合には、SNR差分が大きくなり、このノードは協調ノードとして貢献度が高い。このように、本発明に係るアルゴリズムは、必要な場合にのみ協調を可能とし、不要でありシステムで発生する干渉が大きくなるばかりであると自動的に削除する。クライアントデバイスの電池電力レベル:電力レベルが低いノードは、支援を行わないことを選択し、十分な電力を持つノードは、支援を行うことを選択する。可変値であるthresholdは、現在のノードで検出されるか、現在のノードで実行される干渉測定結果から決まるコリジョンレートによって決まるネットワークの混雑/干渉レベルに比例して変化する。現在のノードの周囲を取り囲む近隣ネットワークつまり、サブネットワークまたはネットワーク100がビジー状態であると検出されると、現在のノードは、サイレント状態になり、他のノードが行なっている近傍での送信と干渉を発生させることはない。しかし、近隣ノードがビジー状態でない場合、現在のノードは、協調することにより近傍のノードを支援することができる。<協調/パケットの転送の判断>転送を判断するために利用される方法として、転送確率Pforwardingがある。関数の一例として、以下の式で表せるものが挙げられる。この関数によると、Pを二乗することでPforwardingの値が高い方を選択し、Pforwardingの値が低い方を格下げする。各ノードにおいて、0と1との間の乱数を生成するとしてよい。乱数がfPforwarding未満である場合には、現在のノードは送信に関与する。そうでない場合には、現在のノードまたはアクティブなノードは、サイレント状態のままである。他の関数を選択することも可能である。以下では一例となるシナリオを説明する。図1を再び参照して、ノードK122がパケットをノードL124に送信した後、ノードF112、P132、G114、L124およびQ134は全て、送信をヒアリングすることができる。ノードL124がパケットを正しく受信しなかった場合、ノードL124は、NACK否定確認応答メッセージをノードK122に送信するか、または、ノードL124からノードK122へとACKを送信しない。そして、ノードK122からの再送が実行される。この場合、ノードF112、P132、G114およびQ134は、NACKをヒアリングすることができるか、ACKをヒアリングしない。そして、ノードK122と協調してパケットをノードL124へと再度送信する。一実施例を挙げると、ノードG114およびQ134は、ノードF112およびP132よりも、ノードK122と協調する可能性が高い。これは、ノードG114およびQ134は、ノードL124により近接しているからである。ノードG114およびQ134はさらに、ノードG114またはQ134からノードL124へのSNR推定値が高いので、Pforwardingが高い。各ノードが再送まで待機する時間は、決定されると、同期を目的とした定期的なハンドシェイクにおいて全ての近隣ノードにおいてやり取りされる。例えば、CTS/RTS送信許可/送信要求のハンドシェイクを利用する場合、全ての近隣ノードは、一のノードがRTS送信要求を受信した後に送信を開始すべきタイミングを知ることができる。これは、この情報が標準的なプロトコルで明記可能であるためである。CTS/RTSハンドシェイクを行わない送信の場合、タイミング情報および次ホップルーティング情報は、ネットワークルーティングメインテナンスおよび同期のために必要となる定期ハンドシェイクにおいて、やり取りすることができる。ノードL124およびノードF112、P132、G114およびQ134が全て正しくパケットを受信したと仮定する。パケットは、ノードL124からノードM126へと転送され得る。尚、ノードF112およびP132は、パケットの転送に関与しない。これは、ノードM126は、ノードF112およびP132の直近の近隣ノードではなく、NBR_RH=0のためにPforwarding値がゼロとなるからである。アルゴリズムは自動的に、協調に関与しないノードを除外して、協調を実際に支援するノードのみを残して全体的なシステム干渉レベルを低減することができる。一のノードがパケットを次のホップに転送するまで待機する時間は、近隣ノードの間で知られている。これは、この情報が、同期のための定期ハンドシェイクでやり取りされるためである。繰り返しになるが、CTS/RTSハンドシェイクが利用されると、全ての近隣ノードは、標準的なプロトコル仕様に基づき、RTSを受信した後に送信を開始すべきタイミングを知ることができる。ノードL124は、ノードG114および/またはQ134の支援を受けつつ、ノードM126にパケットを送信すると仮定される。続いて、パケットがノードM126に到着すると、送信範囲内であるのでノードA102、B104、C106、H116、M126、F112、K122、P132、Q134およびR136が送信を受信するが、アルゴリズムを適用することによって、パケットのノードN128への転送においてノードM126と協調するのはノードH116およびR136のみとすることができる。全てのその他のノードはPforwardingがゼロである。これは、ノードN128は、ノードA102、B104、C106、F112、K122、P132およびQ134の直近の近隣ノードではないためである。同様に、ノードN128からノードO130への最後のホップについて、ノードN128からノードO130へのパケットの送信においてノードI118およびS138のみがノードN128と協調する。<協調によるデスティネーションノードでのチャネル容量ゲイン>ノードH116、M126およびR136からノードN128への協調による容量ゲインを示すべく、一例として、分析を実行する。近隣ノード間は距離が短く、定期的に同期が行なわれるので、近隣ノードは、程度に多少はあれ、同期していると仮定される。説明を簡略化するべく、以下のシナリオではゲインが等しい3つの単一入力単一出力SISOチャネルが受信側のノードN128で結合されると考える。MIMO方式およびコヒーレントチャネル推定方式を利用したより高度な方法では、得られるゲインがさらに多くなるとしてよい。パイロットおよびデータサブキャリアからノードNで受信した信号は、以下のように定義される。数3において、は、送信側ノードH/M/Rから受信側ノードNへのチャネルをそれぞれ表す。は、ノードH116、M126およびR136からノードN128で受信した信号を表す。は、サブキャリアでノードN128に送信されるQAMシンボルを表す。サブキャリアがパイロットである場合、は、ノードN128で分かっている。nは、ノードN128における熱ノイズを表す。最終的なデコードされたシンボルは、以下の式で定義され得る。式中、は、複素共役を表し、||||は、ベクトルの複素数の振幅二乗を表す。は、パイロットサブキャリアに基づき測定される。ノードN128において、ノードH116およびR126からの協調がある場合およびない場合のSNRはそれぞれ、以下の式で表される。式中、およびはそれぞれ、信号および受信ノイズ電力である。レーリーフェージングチャネルの最悪のケースを仮定するとhがガウス変数を用いて生成され、平均値がゼロでバラツキが1であり、設定がである場合、協調ありの場合のSNRの累積分布プロットCDFは、協調なしの場合のSNRのCDFと比較すると、SNRが改善していることが分かる比較的低いSNRでは、SNRゲインが5dBとなっていることが分かる。シャノンの公式を用いてチャネル容量に変換すると、協調によって、SNRが低い場合には容量が大きくなり、つまり、チャネルを利用することができ、また、SNR値が低くない場合でも利用できる。<ノードデバイスの例>図4は、協調通信を実施するべく群知能を実装するデバイスまたはノード400の例を示す図である。ノード400は、ノード102-140等、上述したノードの実施形態例であってよい。上述したように、ノード400は、さまざまな無線デバイスのうち1つであってよく、モバイルメッシュまたはMANETネットワークの一部である。ノード400は、このようなネットワークに、移動により出入りすることができる。また、ノード400は、ネットワーク内の他のノードと、通信および協調する。ノード400は、1以上のプロセッサ402を有する。プロセッサは、メモリ404と通信するように構成されている。メモリ404は、さまざまな種類のメモリおよび/またはメモリデバイスを含み得る。これらに限定されないが、ランダムアクセスメモリRAM、リードオンリーメモリROM、内部メモリおよび外部メモリを含むとしてよい。メモリ404はさらに、本明細書で説明するプロセスを実装するチップセットを含むとしてよい。メモリ404は、デバイス102で実行可能なコンピュータ可読命令を含むとしてよい。本明細書で説明した構成要素は、集積化されているとしてもよいし、メモリ404の一部として含まれているとしてもよいと理解されたい。ノード400は、1以上のさまざまな無線入出力インターフェース用のプロトコルおよび規格、例えば、CDMA、IEEE802.11およびその関連規格等を利用することができる。ノード400は、ブロック406で示すように、無線インターフェース用の無線I/Oを備える。メモリ404は、上述したように実装されるルーティングテーブル408を備える。メモリ404はさらに、協調通信に対処するべくアルゴリズム410を備える。アルゴリズム410は、群知能および協調通信をサポートする上述したアルゴリズム/等式を含む。本例では、ノード400はさらに、パケット送信をサポートするエンコーダ/デコーダ412を備える。言い換えると、エンコーダ/デコーダ412は、パケットおよびメッセージの暗号化および復号化を行うために利用され得る。<群知能のプロセスの例>図5は、メッシュネットワークにおける協調通信用の群知能のプロセス500の一例を説明するためのフローチャートである。一例を挙げると、協調通信用の群知能は、デバイスまたはノード400によって実行されるとしてよい。当該方法を記載している順序は、限定と解釈されるべきではなく、本明細書で説明する方法を構成するブロックは、当該方法または別の方法を実行するべく任意のものを統合することができる。また、各ブロックは、本明細書で説明する主題の意図および範囲から逸脱することなく、当該方法から削除することもできる。さらに、当該方法は、本発明の範囲から逸脱することなく、任意の適切なハードウェア、ソフトウェア、ファームウェア、または、これらの組み合わせによって実装され得る。ブロック502において、ルーティングプランおよび/またはルーティングテーブルを作成する。ルーティングプランおよびルーティングテーブルは、所定のものであってよく、所与のノードから後続のノードへの、最終的には、デスティネーションノードへのパケットまたはメッセージの経路を記述するため用いられるとしてよい。ルーティングプランは、所与のノードからデスティネーションノードまでの特定の経路であり、ルーティングテーブルは、パケットまたはメッセージを転送するために利用可能なノードに関する情報を提供する。ブロック504において、パケットまたはメッセージを転送する際に支援する近隣ノード、または、協調するために支援する近隣ノードを判断する。一貫して均一な構造を持つマトリクスネットワークでは、上述したように、支援または協調を行う候補ノードは、例えば、隣接または近隣の8個のノードであってよい。ネットワークは均一な構造ではなく支援および協調を行う候補ノードは変わるものと考えられる。このようなネットワークでは、一のノードの近隣ノードは、現在のノードと直接通信可能なノードであると定義される。近隣ノードが決定されると、通常の定期的なハンドシェイクを実行して、ルーティング、転送および同期のための情報のやり取りを行う。ブロック506において、各近隣ノードは、パケット/メッセージの送信に対して協調または支援するか否かを判断することができる。この判断は、上述した転送関数に基づいて行うことができる。具体的には、転送確率関数を実施することができる。いずれにしても、各ノードは、パケット/メッセージの転送に対して協調または支援を行う近隣ノードを決定することができると考えられる。この決定は、ネットワークおよび/または他のノードとは独立して行われる。ブロック508において、パケット/メッセージを転送する。ノードは、次のホップであるノードにパケット/メッセージを送信し、近隣ノードが、パケット/メッセージを次のホップのノードに送信する際に支援または協調を行うことができる。<結論>本願で提示する図面およびフローチャートに基づき方法の例について具体的且つ詳細に説明したが、図示した特定の処理は記載した順序で実行する必要はなく、状況に応じて、修正するとしてよく、および/または、完全に削除するとしてもよいと理解されたい。本願で説明するように、モジュールおよびエンジンは、ソフトウェア、ハードウェア、ファームウェアまたはこれらの組み合わせを用いて実行するとしてよい。また、説明した処理および方法は、コンピュータ、プロセッサ等のコンピューティングデバイスによって、1以上のコンピュータ可読格納媒体CRSMを含むメモリに格納されている命令に基づき、実行されるとしてよい。CRSMは、格納している命令を実行するべく、コンピューティングデバイスがアクセス可能な物理的媒体であれば、どのようなものであってもよい。CRSMは、これらに限定されないが、ランダムアクセスメモリRAM、リードオンリーメモリROM、電気的消去可能プログラム可能リードオンリーメモリEEPROM、フラッシュメモリまたはその他のソリッドステートメモリ技術、コンパクトディスクリードオンリーメモリCD-ROM、デジタルバーサティルディスクDVDまたは他の光ディスクストレージ、磁気ディスクストレージまたは他の磁気格納デバイス、または、所望の情報を格納するために利用され、コンピューティングデバイスがアクセス可能な任意のその他の媒体を含むとしてよい。