私が住んでいるアパートのブロック用に温度センサーネットワークを構築するために何が必要かを考えていました。ワイヤレスメッシュが機能する場合、いくつかの優れた機能があります。特に、携帯電話やWi-Fiの信号が届かないガレージやセラーの保管場所にセンサーを配置できました。
メッシュを使用しない理由として考えられるのは、バッテリーの頻繁な交換を避けるために、スリープ状態のエンドデバイスも使用したい場合があるためです。私が見ることができることから、これが機能する唯一の方法は、デバイスが同時にウェイクアップし、信号がネットワークを伝播するのに十分な長さになるように、クロック同期を使用することです。
このような解決策が説明されているのを聞いたことがありますが、それが実際にどれほどうまく機能するのでしょうか。ドリフトを避けるために、おそらく定期的なクロック同期をプロトコルに追加する必要があります。誰かがこれについての経験がありますか？また、クロック同期とは別に、メッシュデバイスとスリープデバイスを一緒に使用するための他の戦略はありますか？
回答:
時間の同期を必要とせずに、スリープ状態のノードを許可することは実際に可能です。基本的な考え方は、ノードが最終的に起動するまでメッセージを複数回送信することです。もちろん、巧妙な最適化の余地はたくさんあります。そのため、このアイデアに基づくMACレイヤーのアプローチは何百もあります。
しかし、あなたの質問は特にノードが事前にいつ送信するかを知っているMAC層、つまり時分割多元接続（TDMA）を求めているので、それらのアプローチに焦点を当てます。
すでに述べたように、1つの問題はクロックドリフトであるため、デバイスは時間同期のために定期的にウェイクアップする必要があります。私たちが話している典型的な短距離無線アプリケーションでは、単一のホップでの信号伝播時間自体は大きな問題ではありません。したがって、中央のコーディネーターが、ノードに認識されている定期的な時間間隔で、現在時刻を含むビーコンを送信するだけで十分です。
マルチホップネットワークでは、さらに複雑になります。待ち時間が長すぎるため、ビーコンを転送するだけでは機能しません。解決策は、複数ではないがすべてのノードがビーコンを送信する、つまりコーディネーターに近いノードからビーコンを受信し、それを使用して自身のクロックドリフトを修正し、修正された時間で独自のビーコンを送信することです。サークルを作成しないようにする必要があります（そこにいる、それを行ってください...）。
ネットワークのすべてのノードが同じ時間の概念を持っているので、2番目の問題があります。ノードは、送信または受信のためにいつウェイクアップする必要があるかをどのようにして知るのですか？基本的に4つのアプローチがあり、これらを組み合わせることもできます。
共通スロット：すべてのノードが同時に起動し、競合ベースのアクセス方法を使用してパケットを送信します利点：簡単（CSMA / CAの方法を知っている場合）。短所：衝突が発生しやすく、スループットが低下します。
事前定義済み：制限された数のノードの場合、ノードに固定スロットを割り当てることができます。たとえば、ノード2は最初のタイムスロットでノード1に送信でき、ノード3は2番目のタイムスロットでノード2に送信できます。利点：専用スロットと衝突なし。短所：トポロジーを修正する必要があります（ワイヤレスメッシュネットワークでは非常に困難です）。
一元化：中央コーディネーターがトポロジーに関するノードからの情報を要求し、グローバルスケジュールを計算して、それをノードに再配布します。利点：事前定義されたトポロジは必要ありません。短所：スケーリングが不十分で、トポロジーが変更されやすい（プロセス全体を再起動する必要がある）。
分散型：通信を希望する2つのノードがスロット自体をネゴシエートします。隣接するデバイスが同時に送信しないようにする必要があるため、非常に複雑です。利点：交渉がローカルであるため、拡張性が高い。短所：実装が複雑です。
IEEE 802.15.4規格には、現在研究で注目されているTSCHとDSMEの2つの関連技術があります。
TSCH自体は非常に基本的です。それは時間同期問題を解決するだけですが、スロット割り当て問題を上位層に残します。このギャップを埋めようとする6TiSCHがありますが、まだ進行中です。たとえば、ContikiやOpenWSNに含まれる実装があります。
一方、DSMEはすでに分散型スロットネゴシエーションのメカニズムを提供しています。実際には、これのopenDSMEと呼ばれるオープンソース実装を構築しています。シミュレーションを実行するためのビデオチュートリアルがありますが、ハードウェアの実装は残念ながらまだ文書化されていません。使用したい場合は、別の質問をするか、直接お問い合わせください。