802.11ba (WUR) またはヘビとハリネズミを交配する方法

少し前に、私は他のさまざまなリソースやブログで、ZigBee が死んで客室乗務員を埋葬する時期が来たという事実について話しました。 IPv6 と 6LowPan の上で Thread が動作する悪いゲームに良い顔をするには、これに適した Bluetooth (LE) で十分です。 しかし、これについてはまた別の機会にお話しします。 今日は、委員会の作業グループが 802.11ah の後によく考え、LRLP (長距離低電力) のようなものの本格的なバージョンを 802.11 標準のプールに追加する時期が来たと判断した経緯について説明します。 LoRAへ。 しかし、下位互換性という神聖な雌牛を屠ることなしにこれを実装するのは不可能であることが判明しました。 その結果、ロングレンジは放棄され、ローパワーのみが残りましたが、これも非常に優れています。 その結果、802.11 + 802.15.4、または単純に Wi-Fi + ZigBee が混合されました。 つまり、新しいテクノロジーは LoraWAN ソリューションの競合相手ではなく、逆に、LoraWAN ソリューションを補完するために作成されていると言えます。

それでは、最も重要なことから始めましょう - 802.11ba をサポートするデバイスには 802.11 つの無線モジュールが必要です。 どうやら、エンジニアは、ターゲット ウェイク タイム (TWT) テクノロジを備えた XNUMXah/ax を検討した結果、これでは十分ではなく、消費電力を大幅に削減する必要があると判断したようです。 この規格が、プライマリ通信無線 (PCR) とウェイクアップ無線 (WUR) という XNUMX つの異なるタイプの無線に分割することを規定している理由。 最初の場合はすべてが明確で、これがメインの無線であり、データを送受信する場合、XNUMX番目の場合はそれほど多くはありません。 実際、WUR は主にリスニング デバイス (RX) として機能し、動作時の消費電力が非常に少ないように設計されています。 その主なタスクは、AP からウェイクアップ信号を受信し、PCR を有効にすることです。 つまり、この方法によりコールド スタート時間が大幅に短縮され、最高の精度で特定の時間にデバイスをウェイクアップできるようになります。 これは、たとえばデバイスが XNUMX 台ではなく XNUMX 台あり、それぞれのデバイスと短時間でデータを交換する必要がある場合に非常に便利です。 さらに、覚醒の頻度と周期性のロジックは AP 側に移動します。 たとえば、アクチュエータ自体が起動して空中で何かを送信し、残りの時間はスリープするときに LoRAWAN が PUSH 方式を使用する場合、この場合は逆に、いつどのデバイスが起動するかを AP が決定します。アクチュエータ自体は...常にスリープしているわけではありません。

次に、フレーム形式と互換性について説明します。 802.11ah が最初の試みとして 868/915 MHz 帯域または単に SUB-1GHz 向けに作成された場合、802.11ba はすでに 2.4 GHz および 5 GHz 帯域を対象としています。 以前の「新しい」標準では、古いデバイスでも理解できるプリアンブルによって互換性が実現されていました。 つまり、古いデバイスは必ずしもフレーム全体を認識できる必要はなく、このフレームがいつ開始され、送信がどれくらい続くかを理解できれば十分であるという計算が常に行われてきました。 彼らが前文から得た情報はこれです。 802.11ba も例外ではありません。この方式は実証済みです (コストの問題は今のところ無視します)。

その結果、802.11ba フレームは次のようになります。

非 HT プリアンブルと BPSK 変調による短い OFDM フラグメントにより、すべての 802.11a/g/n/ac/ax デバイスがこのフレームの送信の開始を聞き取ることができ、干渉せず、ブロードキャスト リスニング モードになります。 プリアンブルの後には、本質的に L-STF/L-LTF に相当する同期フィールド (SYNC) が続きます。 これは、周波数を調整し、デバイスの受信機を同期できるようにするために機能します。 そしてこの瞬間に、送信デバイスは 4 MHz の別のチャネル幅に切り替わります。 何のために？ すべてがとてもシンプルです。 これは、電力を削減し、同等の信号対雑音比 (SINR) を達成できるようにするために必要です。 または、出力をそのままにして、送信範囲を大幅に拡大します。 これは非常に洗練されたソリューションであり、電源要件を大幅に削減できると言えます。 たとえば、人気のある ESP8266 を思い出してください。 54 Mbps のビットレートと 16dBm の電力を使用する送信モードでは、196 mA を消費しますが、これは CR2032 のようなものとしては法外に高い値です。 チャネル幅を 50 分の 2032 に減らし、送信電力を XNUMX 分の XNUMX に減らすと、実際には送信範囲が失われることはありませんが、消費電流は XNUMX 分の XNUMX、たとえば約 XNUMX mA に減少します。 これは、WUR のフレームを送信する AP 側にとって重要というわけではありませんが、それでも悪くありません。 しかし、STA の場合、これはすでに理にかなっています。なぜなら、消費電力が低いため、CRXNUMX や、定格放電電流が低く長期エネルギー貯蔵用に設計されたバッテリーなどを使用できるからです。 もちろん、何もタダでは得られず、チャネル幅を縮小すると、それぞれ XNUMX フレームの送信時間の増加とともにチャネル速度の低下につながります。

ところで、チャンネル速度について。 現在の規格では、62.5 Kbps と 250 Kbps の 2 つのオプションが提供されています。 ZigBeeの匂いを感じますか？ チャネル幅は 4Mhz ではなく 802.11Mhz ですが、より高いスペクトル密度を備えた異なるタイプの変調を使用するため、これは簡単ではありません。 その結果、XNUMXba デバイスの範囲が広くなり、屋内 IoT シナリオに非常に役立ちます。

とはいえ、ちょっと待てよ…4MHz帯のうち20MHzしか使わずにエリア内の全局を強制的に沈黙させるなんて…「もったいない！」 -あなたは言うでしょう、そしてあなたは正しいでしょう。 しかし、いいえ、これこそが本当の無駄なのです。

この規格は、40 MHz および 80 MHz サブチャネルを使用する機能を提供します。 この場合、各サブチャネルのビットレートは異なる可能性があり、放送時間に合わせるために、フレームの最後にパディングが追加されます。 つまり、デバイスは 80 MHz すべての通信時間を占有することができますが、使用できるのは 16 MHz のみです。 これは本当の無駄です。

ちなみに、周囲の Wi-Fi デバイスは、そこで何がブロードキャストされているかを理解する可能性はありません。 通常の OFDM は 802.11ba フレームのエンコードに使用されないためです。 はい、まさにそのようにして、同盟は長年にわたって完璧に機能してきたものを放棄したのは有名です。 従来の OFDM の代わりに、マルチキャリア (MC)-OOK 変調が使用されます。 4MHz チャネルは 16 (?) のサブキャリアに分割されており、それぞれのサブキャリアはマンチェスター符号化を使用します。 同時に、DATA フィールド自体もビットレートに応じて論理的に 4 μs または 2 μs のセグメントに分割され、そのような各セグメントでは低または高エンコード レベルが XNUMX つに対応します。 これは、XNUMX または XNUMX の長い連続を避けるための解決策です。 最低賃金でのスクランブル。

MAC レベルも非常に簡素化されています。 これには次のフィールドのみが含まれます。

• フレームコントロール

  Beacon、WuP、Discovery またはベンダーが選択したその他の値を取ることができます。
  ビーコンは時刻同期に使用され、WuP は 802.11 つまたはデバイスのグループを起動するように設計されており、ディスカバリーは STA から AP への逆方向に動作し、48ba をサポートするアクセス ポイントを見つけるように設計されています。 フレームが XNUMX ビットを超える場合、このフィールドにはフレームの長さも含まれます。

• ID

  フレームのタイプに応じて、このフレームの宛先となる AP、STA、または STA のグループを識別できます。 (はい、デバイスをグループでウェイクアップできます。これはグループキャスト ウェイクアップと呼ばれ、非常に優れています)。

• タイプ依存 (TD)

  かなり柔軟な分野です。 その中には、正確な時刻、バージョン番号を含むファームウェア/構成の更新に関する信号、または STA が知っておくべき便利なものが送信されます。

• フレームチェックサムフィールド (FCS)
  ここではすべてがシンプルです。 これはチェックサムです

しかし、このテクノロジーが機能するには、必要な形式でフレームを送信するだけでは十分ではありません。 STA と AP は同意する必要があります。 STA は、PCR の初期化に必要な時間を含むパラメータを報告します。 すべてのネゴシエーションは通常の 802.11 フレームを使用して行われ、その後、STA は PCR を無効にして WUR イネーブル モードに入ることができます。 あるいは、可能であれば睡眠をとることもできます。 存在するならそれを使ったほうが良いからです。
次に、WUR デューティ サイクルと呼ばれる貴重なミリアンペア時間をさらに絞り込みます。 複雑なことは何もありません。TWT の場合と同様に、STA と AP が睡眠スケジュールに同意するだけです。 この後、STA はほとんど寝ていますが、時々 WUR をオンにして「何か役に立つものはありましたか?」を聞きます。 そして、必要な場合にのみ、トラフィック交換のためにメイン無線モジュールを起動します。

TWTやU-APSDと比べると状況は大きく変わりますね。

そして、すぐには考えられない重要なニュアンスがあります。 WUR はメイン モジュールと同じ周波数で動作する必要はありません。 逆に、別のチャネルで動作することが望ましく、推奨されます。 この場合、802.11ba 機能はネットワークの動作にまったく干渉せず、逆に、有用な情報を送信するために使用できます。 他の 802.11 標準 (802.11k/v など) 内のロケーション、近隣リストなど。 そして、メッシュ ネットワークにどのような利点がもたらされるか...ただし、これは別の記事のトピックです。

規格そのものの文書としての運命について言えば、 現在、ドラフト 6.0 は準備が整っており、承認率は 96% です。。 つまり、今年は実際の標準、または少なくとも最初の実装が期待できるということです。 それがどれほど広まるかは時間が経てばわかります。

そんなことは…(c) 悪のワイヤーズ男.

推奨読書:

IEEE 802.11ba - 大規模なモノのインターネットのための超低電力 Wi-Fi - 課題、未解決の問題、パフォーマンス評価

IEEE 802.11ba: グリーン IoT 向けの低電力ウェイクアップ無線

IEEE 802.11 対応ウェイクアップ無線: ユースケースとアプリケーション

出所： habr.com