目的

一部の顧客は、専用の Bluetooth ゲートウェイを導入する代わりに、iOS または Android のモバイル アプリを使用してバックグラウンドで Bluetooth ビーコン ブロードキャストを受信したいと考えています。この論文では、特に次のようなデバイスの場合、Lansitec ビーコン ベースの監視にこのアプローチが技術的に実現可能かどうかを評価します。 B002 Bluetoothラベル そして B005 Bluetoothビーコン. 問題は、スマートフォンがビーコンを検出できるかどうかではない。検出は可能だ。本当の問題は、スマートフォンアプリがバックグラウンドで、長期間にわたって、ゲートウェイの代わりになるほどの信頼性と安定性でビーコンを検出できるかどうかだ。.

私たちの見解は単純です。場合によっては実現可能ですが、それは適切な条件下に限られます。一般的な消費者向けスマートフォンや、気軽に利用するアプリの場合、この方法は通常、専用ゲートウェイの完全な代替手段とみなせるほど信頼性が高くありません。.

対象となるユースケース

要求されたアーキテクチャは、紙面上では単純明快である。 B002 または B005 ビーコンは設定された間隔でBLEデータを送信します。顧客のアプリを実行しているスマートフォンは、これらの送信データをスキャンし、ビーコンIDと信号強度を読み取り、検出イベントをサーバーにアップロードします。.

それはLansitecの能力に合致する。 ビーコン. 。 B002 iBeaconをベースにした超薄型BLEラベルで、広告間隔は100msから10秒まで設定可能、見通し線伝送距離は150mと記載されている。 B005 設定可能な間隔を備えた、より堅牢なIP68ビーコンです。オプション AoAサポート, そして、同じく見通し距離150メートルと記載されている。.

つまり、問題はビーコン側ではなく、電話側にあるということだ。.

これは通常のLansitecモデルと何が違うのですか？

ランシテックの Bモバイル 解決、, Bluetoothゲートウェイ 固定された場所に配置されます。 ビーコン 定期的に広告する、, ゲートウェイ データを受信すると、サーバーはそれらの既知の位置に基づいて位置を計算または解釈します。 ゲートウェイ. 同じ文書には、 ゲートウェイ 想定される展開モデルでは受信は事実上常にオンであり、 RSSI 壁、干渉、マルチパス効果などにより変動する可能性があります。.

アプリをこの場所に配置すると、ソリューション全体の設計が変わります。.

固定 ゲートウェイ 通常の電話にはない3つの機能を提供します。

• 既知の物理的位置
• 安定した電力動作
• 予測可能な受信可用性

これは、お客様に最初にお伝えする注意点です。アプリがビーコンを検知したとしても、移動中のスマートフォンは固定されたスマートフォンと機能的に同等ではありません。 ゲートウェイ。

iOSでの実現可能性

iOSでは、バックグラウンドでのBluetoothの動作は可能ですが、制限があります。Appleによると、フォアグラウンド専用アプリは、バックグラウンドまたはサスペンド中にアドバタイジング周辺機器をスキャンして検出することはできません。Bluetoothを中央に配置するバックグラウンドモードを宣言したアプリは、バックグラウンドで周辺機器を検出して接続できますが、バックグラウンドスキャンの動作が異なります。重複した検出は統合され、スキャン間隔が長くなる可能性があるため、検出に時間がかかる場合があります。Appleはまた、Bluetoothイベントで起動したアプリはすぐに終了するべきであり、サスペンド負荷が問題になる前にバックグラウンドでの動作は約10秒までとしています。. ⁽¹⁾

iOSには便利な回避策が1つあります。それはビーコン領域監視です。AppleのCore LocationフレームワークはiBeacon領域を監視し、領域への進入または退出イベントでアプリを起動できます。ただし、トレードオフもあります。Appleは領域監視をアプリごとに20領域に制限しており、アプリがフォアグラウンドにある間のみビーコン測距を行うことを明示的に推奨しています。. ⁽²⁾

では、実際にはどういう意味なのでしょうか？

iOSの場合、アプリはビーコン関連のバックグラウンド動作、特に大まかな「領域への進入／領域からの退出」ワークフローをサポートできます。しかし、広範囲にわたる展開において、ゲートウェイのような継続的なパッシブスキャンを行うためのプラットフォームとしては適していません。顧客がインフラストラクチャのように静かに動作する常時監視型のスマートフォンを求めている場合、iOSは最適な選択肢とは言えません。.

Androidの実現可能性

Androidはより柔軟性がありますが、魔法ではありません。Googleの現在の開発者向けガイドラインでは、バックグラウンドでのBLE通信は可能であるものの、アプリのプロセスはアクティブな状態を維持する必要があります。プロセスが強制終了されると、接続は切断されます。また、Googleは、フィルタリングされたスキャンを使用しない限り、フィルタリングされていないスキャンは画面がオフになると停止し、画面がオンになると再開されると述べています。.

バックグラウンドでの利用に関して、Android ではいくつかの方法が説明されています。PendingIntent を使用したスキャン、CompanionDeviceService の使用、WorkManager の使用、または connectedDevice タイプでフォアグラウンド サービスを実行する方法です。Google は、定期的なスキャンは非効率的で中断される可能性があるため、一般的な解決策としては推奨していません。Android 14 以降では、フォアグラウンド サービスで適切なサービス タイプを明示的に宣言する必要があります。. ⁽³⁾

これが重要な点です。AndroidはiOSよりもこの点で優れていますが、信頼性は導入時の規律に大きく左右されます。.

一般的なAndroidスマートフォンでは、メーカーのバッテリー最適化、ユーザー設定、バックグラウンド制限、メモリ不足などが原因でアプリが停止する可能性があります。バックグラウンドでプロセスが強制終了されないようにするには、カスタマイズされた産業グレードのAndroidデバイスが必要になるかもしれません。ホワイトリスト、高優先度アプリ処理、制御された電源設定、役割に応じたワークフローを備えた管理対象デバイスであれば、はるかに高い確率で成功します。.

アプリのアプローチが機能する場合

アプリベースのアイデアが妥当なケースを3つ見てきました。.

まず、アプリが継続的に運用されている場合

ユーザーが勤務時間中にアプリを開いたままにしている場合や、スマートフォンが作業工程の一部として設置・使用されている場合、ビーコンの受信がより現実的になります。例えば、車両や建設機械に設置されている場合などが挙げられます。Uberのドライバーアプリのようなものです。.

第二に、ハードウェアが制御されている場合

堅牢な、あるいはカスタマイズされたAndroidスマートフォン、特に企業が管理するスマートフォンは、個人用の端末よりもはるかに優れています。ここでいうスマートフォンは、単なるモバイルアプリプラットフォームではなく、半専用端末です。そのため、より高度なカスタマイズが求められ、プロセスが円滑に進むようにソフトウェアをカスタマイズすることが妥当と言えるでしょう。.

第三に、要件がインフラストラクチャレベルの位置情報ではなく、イベント検出である場合

顧客が必要としている情報が「ビーコンが検出された」「ビーコンが電話の近くにある」「作業員が管理対象の携帯端末を持ってゾーンに入った」といったものだけであれば、このアプリで十分かもしれません。. ユーザーの行動とは無関係に、安定した部屋レベルまたはサイトレベルの監視が必要な場合は、いいえ、それは ゲートウェイ 地域。.

明確に述べるべき主な制限事項

アプリを使ったアプローチには、以下のような根本的な限界がある。

• バックグラウンド実行はOSによって制御されます。. iOSとAndroidはどちらもバッテリー寿命を最大化するために積極的に最適化を行っている。. 
• 電話は固定されたインフラではない。. で Bモバイル, 、 修理済み ゲートウェイ 位置情報は追跡ロジックの一部です。.
• RSSI 不安定です。. Lansitecの文書には、部屋の向こう側からの受信が弱いと記載されている。, RSSI 変動、および多重経路効果。.
• ユーザーの行動は重要です。. ユーザーがアプリをスワイプして閉じたり、権限を無効にしたり、Bluetoothをオフにしたり、スマートフォンを積極的な省電力モードにしたりすると、パフォーマンスが低下します。.
• プラットフォームの多様性は確かに存在する。. 特にAndroidでは、メーカーによって動作が異なり、Appleが一元的な管理を行っているiOSとは異なり、ブランド独自のカスタマイズが頻繁に行われているのは珍しいことではない。.

実践的な推奨事項

アプリによるアプローチを強く希望されるお客様には、以下の方法をお勧めします。.

使用 Android、iOSではない, 概念実証の基本として、フィルタリングされたBLEスキャン、許可されている場合はフォアグラウンドサービス動作、およびエンタープライズデバイス管理を中心に構築します。可能であれば、堅牢なデバイスまたはカスタマイズされたデバイスを使用します。アプリは一時的な使用ではなく、運用ワークフローに結び付けます。アプリは、アプリストアからの気軽なインストールではなく、管理された端末として扱います。.

iOSの場合、ソリューションの範囲をより限定的に設定する必要があります。アラート機能、プレゼンスヒント、制御されたビーコン領域ワークフローをサポートする可能性はありますが、要求の厳しい展開環境におけるゲートウェイの完全な置き換えには対応していません。.

また、安定したサイトカバレッジ、ユーザー行動への依存度の最小化、そして追跡のための安定した基準点を必要とするお客様には、専用のBluetoothゲートウェイアーキテクチャを引き続きご活用ください。これは、エンジニアリングと安定した機能性の観点から、依然として最良のソリューションです。.

結論

はい、モバイルアプリはバックグラウンドでビーコンブロードキャストを受信できます。しかし、だからといってそれが自動的に Bluetoothゲートウェイ.

iOSでは、この方法は限定的であり、せいぜい条件付きで扱うべきである。標準のAndroidでは可能だが、不安定である。カスタマイズされたAndroidデバイスや産業用Androidデバイス、特に管理された運用環境においては、はるかに現実的になる。.

最終的な結論は以下の通りです。

アプリ専用のバックグラウンド監視ソリューションは、制御されたデバイスと継続的なアプリ使用を伴う一部のAndroid展開では実現可能です。しかし、固定監視の信頼できる一般的な代替手段ではありません。 Bluetoothゲートウェイ, 特にiOS搭載端末や、管理されていない一般消費者向け端末において顕著です。.

参考文献および参考文献:

1. Apple: Core Bluetooth プログラミングガイド
2. Apple：位置情報とマッププログラミングガイド
3. Android: バックグラウンドでのBLE通信