期待のネット新技術

物流拠点におけるWi-Fi HaLowは「十分に実用的でコスト面に優位性」とWBAが評価

Wi-Fi HaLowの現在地(2)

 前回に引き続き、WBA(Wireless Broadband Alliance)が公開した「Wi-Fi HaLow for IoT Field Trials Report」の内容を紹介しよう。

 White Paperにある7つのユースケースにおけるフィールドテストのうち、前回は「1. Smart Home」を取り上げたが、今回は「2 & 3. Warehouse & Distribution Center」(倉庫&配送センター)。昨今では日本でもあちこちで見かけるようになり、しかも年々巨大化しつつある倉庫や配送センター、物流業などでの利用を想定したテストとなる。

Wi-Fi 6の電波も多い、約1万㎡の倉庫における実用性をテスト

 今回利用されたのは、シカゴ郊外にある11万平方ft(10220㎡弱)の倉庫というか、物流センターに近い建物である(図1)。一般的に大規模物流施設の目安とされるのはおおむね1万㎡だそうで、一応これを超える面積ではある(が、最近はもっと巨大なものも多い)。

 建屋はおそらく平屋であるが、屋根の高さは手前のローディングドックに駐車しているトレーラーの3倍以上あることを考えると、高さは相当にある(10m以上)ものと思われる

図1:ローディングドック(荷物の上げ下ろしが出来る口)はこの写真では20カ所見えているが、全部で22カ所なのだそうで、見えないところにまだあと2つあるらしい
図2:内部のイメージ。身近なところで言えば、COSTCOとかIKEAの商品集積ブースに近い。荷物の移動はフォークリフトを使って行うことになる

 さて、このケースでは、次の3つを目標として設定したうえ、テストが行われている。

  • 倉庫全体(オフィスや会議室、スタッフのロッカーエリア、建物の角に設置されている休憩所を含む)を、最小限のAccess Pointでカバーすること
  • 鉄製の保管棚や完成品倉庫、内壁、22箇所あるローディングドックのドアを貫通して通信を行えること
  • Wi-Fi HaLowが既存のネットワークインフラに干渉を引き起こさずに、同時に(Wi-Fi HaLowで接続された)デバイスの同時動作を行えること

 ちなみにこの倉庫、既におおよそ40箇所のWi-Fi 6のAccess Pointが天井からぶら下がっており、トータルでは数百のSSIDが利用されているという、なかなかの混み具合である。特に2.4GHz帯はフォークリフトや荷物確認用のバーコードスキャナが多数利用されており、5GHzも結構利用率が高いとのこと。また900MHz帯に関しても、Wi-Fi HaLowとは無関係な機材で独自の通信が行われているという話であった。

 この環境下で、アクセスポイントとしてはMorse MicroのMM6108-EKH01を利用。地上高9ft(3m弱)の所に設置した。

図3:Access Pointの設置方法だそうである。何で段ボール箱の上に置いてあるのかは不明

 PHY Rateは32Mbpsで、送信出力は21dBmとなっている。クライアントはMM6108-EKH01とMM6108-EKH01-CAM、それにNewracom NRC7292-EVK kitとMM6108-EKH08を混ぜて、合計24台用意している。ちなみにクライアントの方は、必ずしも固定しているわけではなく、動き回る(例えばフォークリフトとか作業員などに装着する)ケースも想定しているとのことだ。

 さてインドアテスト1は、倉庫の中央あたりに1個だけAccess Pointを設置、倉庫全体に分散されているクライアントからのUDP/TCPでのUplink/Downlinkを行った際のHeat Mapである。

図4:UDPを使ったUplink。数字としては悪くない
図5:TCPを使ったUplink。UDPより多少落ちるものの、まぁこれも悪くない

 まずUplinkを見比べると、全体的にはUDPの方がやや転送速度が高め(プロトコルが簡単だからこれは当然である)であるのはいいとして、なぜかUDPでは図の左やや下あたり、多分完成品倉庫と思われるが、そこでは2.1Mbpsと低い数値になっている。もっとも、TCPだと7.8Mbpsまで改善しているし、その周囲はもっと高いスループットも記録されているので、あるいは測定時の揺らぎが大きく出たためかもしれない(とはいえ、複数回の測定を行っている筈だとは思うのだが)。

倉庫内にある遮蔽物の影響が大きい

 それはともかく、左上のオフィス/会議室と、その右の(おそらく)ロッカールームに関しては、Connectionそのものは確保されているが、かなりスループットが落ちている。これは右下の休憩エリアも同じである。ただ距離的にいえばもっと遠くになる左下の休憩エリアではそこまでスループットが落ちていない辺りは、単純に距離というよりも障害物や内部のレイアウトに結構影響されることが見て取れる。

図6:UDPを使ったUplink。Access Pointのそばはともかく、ちょっと外れると極端に悪化する
図7:TCPを使ったUplink。当然UDPよりも落ちる訳で、どの程度のスループットを求めるか次第ではあるが、離れた場所では結構厳しい

 ではDownlinkは、というと、UDP/TCP共に結構数字が落ちているのが分かる。これはどういうことか? そもそもアクセスポイントに使っているMorse MicroのMM6108-EKH01は、シャーシをGNDに見立てたダイポールアンテナというかスリーブアンテナの構造である。ただ900MHz帯ということは波長は333cm前後。1/4λは83.25cmとなる計算だが、もちろんこんな長さのアンテナは邪魔でしょうがないのでもっと短いものになるから、当然効率は落ちる。実際、データシートではアンテナの利得が1dBiとされている。

 それでもAccess Pointは9ftの高さに設置されているからマシだが、クライアントの方はもっと低い位置に置かれることになる(身長3mの作業員のヘルメットに装着、とでもいうならまた話は別だが)。これが受信状況に露骨に影響しているものと思われる。実のところこのDownlinkのTCP、つまり、図7の結果が普通に倉庫などでIEEE 802.11ahを使う場合の実力に近いのではないかと思われる。

 ちなみにこの図7で見ると、上下方向に関しては距離があってもそれなりのスループットがあるのに、左右方向はちょっと離れると覿面にスループットが落ちるあたり、倉庫の棚の向きが関係しているとしか考えられない。金属製の棚に荷物が大量に収められており、その荷物も恐らくは電波を遮蔽する。上下方向は通路だからそうした遮蔽物が少ない分、伝播特性も良いという訳だ。RSSI Heat Mapもこれを裏付ける結果になっている。もっとも、それでも一番条件の悪いであろうオフィスエリアの角(図4~8で言えば左上の隅)でも、TCPを使って1Mbps以上の通信が出来ている訳で、用途によっては十分な帯域とは言えるかと思う。

図8:TCPのUplinkにかなり連動した結果になっている様に思われる

カメラのテストでは、FPSの言及はないが9台を問題なく運用との結果

 インドアテスト2は、同じ倉庫内9カ所に監視カメラを設置、これで常時カメラ映像をクライアントからAccess Pointに同時送信するというものである。

図9:カメラはONVIF(https://www.onvif.org)を利用して各カメラの最大許容スループットの上限を設定したとの事

 Access Pointはチャネル幅8MHzに設定。送られてきた映像は一括してノートPCに表示するというもので、典型的なビデオ監視カメラのTaskである。

図10:監視カメラの映像をまとめたもの。ちなみに最小で640×480pixelとされているが、カメラ側でH.265のエンコードまで行えるものなら、おそらく1Mbpsあれば2K程度は何とかなる気がする

 昨今だとこれにAIを組み合わせて異常事態の検出などを行う事になるが、それはネットワークというよりもカメラないし監視装置(今回ならノートPC)上で動く処理なので、ネットワークには関係がない。今回はONVIFを組み合わせることで、近距離ではカメラの最大解像度(4Kないし2K)での映像配信に成功、帯域が厳しいところでも640×480pixelでの送信が可能だった、としている。

 もっともWhite Paperではフレームレートに関しては一切言及がない。本気というのも変な話だが、セキュリティレベルの高いところでは、4K/60fpsでの伝送が求められる(最近はAIを利用しての認識が進んだこともあり、より高い解像度やフレームレートでも対応できるようになってきた)が、今回はそこまでセキュリティレベルが高いわけではないようで、毎分1枚とは言わないものの1fps程度でも十分という認識なのだと思われる。

 640×480pixelでもフルカラーをRAWで送ると1フレームあたり21MBほどになるが、JPEG圧縮を掛けると100KBを切る程度でしかない。つまり800kbpsあれば毎秒1枚は送信可能であり、1Mbps程度が維持できれば1fpsでの送信が可能となる。この結果として、少なくとも倉庫内の監視カメラ9台の接続程度であれば十分可能、というのが結論となっている。

各種のIoT機器17台の運用テストも支障なし

 インドアテスト3は前回のSmart Homeの時と同じく、Mixed-Useである。今回は、次のような17台のクライアントを接続し、継続的にデータの収集(これはクライアント→Access Point)や制御データの送信(これはAccess Point→クライアント)を稼働させるというものである。

  • CO2センサー
  • ドアロック
  • オーディオデバイス(構内放送など)
  • ガレージドアのGarage Door Actuator
  • ガス漏れ検出器
  • 温度/湿度センサー
  • Weather Station

 こちらも結果から言えば、17台のクライアントを同時に接続してそのデータを収集したり、制御を行う事に支障はなかった、という結論となっている。

図11:これは温度と湿度をAWSに送ってDashboardでまとめて管理している様子。正確な周期は判らないが、30秒間隔よりは短い(10~15秒程度?)ものと思われる

 ちなみにIEEE 802.11ahは仕様上、最大8191台のクライアントを接続可能とされるが、その限界性能の追及は今回の目的ではないとされている。

屋外で500m程度の距離までは、遮蔽物がなければ安定

 次はアウトドアテストである。屋外、具体的には倉庫の外にあるセキュリティゲートのそばにアクセスポイントを設置、一方クライアントにはGPSを組み合わせ、10秒毎に現在位置とRSSIを記録しながら倉庫の周囲を移動するという形でRSSI Heat Mapを作成した。

図12:設置の高さは不明だが、Access PointはおそらくはSecurity Gate(要は通用口に置かれた事務所)の屋根近く、クライアントはトラックか何かを利用したものと思われる

 RSSIとスループットの関係は、先の図7と図8を見比べればおおむね分かると思うが、-70dBm程度でおおむね10Mbps、-90dBmで1Mbps程度で、-90dBmを下回ると通信が困難という感じになる。

 図12でいうと、Access Pointの場所を中心に、東西方向はそれぞれ300m程度、南北方向は500m程度まで通信可能となっている。ただ南北方向に関して言えば、ちょうど道路に沿ったかたちになっており、ほぼ見通しで通信できる点が大きいと思う。

 反対に、東西というか西側で言えば、別の建物の影は-90dBmを下回って通信不能になっている。これは東の端もそうで、結局設置場所をうまく選べば500mくらいの距離までの通信は可能であるが、他の建物その他の陰になると覿面にスループットが落ちることが分かる。とはいえ、100m程度の範囲であれば建物の影でも通信が維持されているあたりは、2.4GHz帯や5GHz帯を使うよりは障害物に強いと評しても差し支えないと思う。

冗長性テストは平均8秒で再接続との結果

 Warehouse & Distribution Centerでは、マルチAccess Pointの冗長性テストも行われた。一応倉庫の中央にAccess Pointを置いておけば倉庫内で通信できるのはインドアテストで実証済だが、ビジネスとして使う以上Access Pointの故障に備える必要はあるし、中央に1カ所だとRSSIに偏りが出るのはすでに確認された通りなので、冗長構成は当然必要である。

 テストは2つのAccess Pointを用意し、どちらも同じSSIDとSAEセキュリティの設定を行っている。まず複数のベンダーのクライアント6台がAccess Point 1に接続して通信が安定した状態になった段階で、20mほど離れた場所に設置したAccess Point 2の電源を入れて通信可能状態になった事を確認してから、Access Point 1を切断した。この状況でクライアントはすぐにAccess Point 2への再接続を行い、平均8秒(最短2秒、最長18秒)でAccess Point 2への再接続を完了したとしている。

 ちなみにWhite Paperでは、このクラスの倉庫では4台のAccess Pointで冗長構成を取ることで再接続までの時間をより短縮可能であり、この際にはIEEE 802.11r-2008(Fast BSS Transition)の実装が効果的な可能性があるとするも、テストの範囲からは外れると除外している。現実問題として現状のIEEE 802.11ahの機器でIEEE 802.11rを実装しているものが存在しないから、テスト範囲外としたのは妥当だろう。ただ今後、産業分野などでもっと広範に使われるようになるならば、実装されることもあるかもしれない。

25MBのファイルのOTA Updateは3分未満で完了

 次がOTA Updateである。要するにファームウェアとかプログラムをネットワーク経由でUpdateを行う手法である。今回は6台のクライアントに対して、それぞれ25MBのファイルを配布するかたちでテストを行い、3分未満で完了したことが確認された。

 25MBは一般的なOTA Updateで利用されるファームウェアのサイズではない(かなり大きい)が、これが問題なく行えたことで、近い将来に予想されるアプリケーションに対しても十分対応できる、としている。

Bridgeテストも支障なく、「低コストの通信インフラとして優位性」と評価

 最後にEthernet Cable Replacement/Wireless Bridge/Mesh Backhaulのテストが行われた。文字通りで、Ethernet Cableを敷設できない場所でネットワークを利用するためのBridgeとして使えるかどうかの確認である。

 テストでは2台のMM6108-EKH01キットをBridge Modeでペア接続するように設定。会議室に設置されたMM6108-EKH01キットはGoogle Wi-Fi 5ルーターにEthernetで接続。その先にノートPCとSmart Speakerが接続された。一方もう一台のMM6108-EKH01キットは倉庫の中央に設置され、やはりEthernet Cableで接続したNetGearのNightHawk 4G LTEモバイルホットスポットルーターと接続された。この状態で、会議室内のHomepod Miniによるストリーミングオーディオ、およびノートPCによるストリーミングビデオの再生に成功している。

図13:左端がMM6108-EKH01キット、その奥にあるのがGoogleのWi-Fi 5ルーターの模様。テーブルの上に置かれたバッテリーは多分特に何の関係もないと思う

 MM6108-EKH01キットは8MHz Channelでの動作になっているが、図7を見る限りスループットそのものは1Mbps超といったところで、「つながらない」のと「遅いけどつながる」のでは天と地ほども差があるわけで、White PaperでもWarehouse & Distribution Centerのテストのまとめとして「Wi-Fi HaLowは、1台のAccess Pointで大規模な物流センターの倉庫をカバー出来ることが確認され、安全で信頼性の高い無線ネットワーク技術として、幅広いサービスのIoT接続を実現できることが分かった。またWi-Fi HaLowは、既存の現場でオーバーレイ・ネットワークとして使用することが可能で、独自規格のRFや携帯ベースのソリューションよりインフラコストの優位性がある」としている。

大原 雄介

フリーのテクニカルライター。CPUやメモリ、チップセットから通信関係、OS、データベース、医療関係まで得意分野は多岐に渡る。ホームページはhttp://www.yusuke-ohara.com/