パケットロス検出・回収機能の設計 #mobile_mob

パケットロス検出・ 回収機能の設計 Mobile Mob #2 〜スマホのハードウェア制御の悩み・工夫をもっと語り合う〜

堤 修一 • フリーランスiOSエンジニア • ID: shu223 • GitHub • Docswell（スライド） • Zenn, Qiita, note, はてなブログ, X (Twitter) • YouTube, Podcast • 著書： 商業出版4冊、個人出版多数

• https://github.com/shu223
• https://www.docswell.com/user/shu223
• https://zenn.dev/shu223
• https://shu223.hatenablog.com/
• https://www.youtube.com/@shu223
• https://shu223.booth.pm/items

過去に関わったハードウェア系プロジェクト（の一部）

• 外部デバイス連携プロジェクトは他にも多数 • カメラ、Bluetooth、マイク、センサー、GPU / Neural Engine などスマホ自体のハードウェアを利用するプロジェクトも多数 経験 ハードウェア絡みの案件は大好物です。

いま関わっているハードウェア系プロジェクト • 米国FDA取得に向けて動いている海外の医療デバイス案件 • 生体データを記録する国産ウェアラブルデバイス案件

2つの案件の共通点 • どちらも時系列の生体データを取り扱う • 実証実験や臨床試験を行い、収集したデータを分析や学習に用いる → データの欠損は、そのまま分析・学習の品質低下になる

パケットロスってそんなに発生するの？ • 電子レンジを近くで使う • アルミホイルでデバイスを包む • iPhoneの近くでAirPodsケースをパカパカする → 容易に再現できる

本日のお題： パケットロスをいかに検出し、回収するか • 検出: どのデータが欠けたかを特定する • 回収: 欠けたデータを後から埋め直す

必要になってから考えればいい？

プロジェクトの途中から足そうとすると・・・ • ファーム側・デバイス側にも変更が必要になる • 送信に失敗したパケットをデバイスが保存していない • 保存しようにもストレージが足りない • データ構造的に無理（BLEで実際に送るバイト列に連番が無い たか」を指定できない） • BLE APIの変更・追加が必要 • もちろん合わせてアプリ側の改修も必要になる • データ構造を変えるとあちこちに影響 「どれが欠け

プロジェクト初期からパケットロス検 出・回収を考慮して設計しよう

回収方式の違い 再送要求型 • デバイス側では全データを Flashに記録 • アプリ側でロスを検出し、 再送要求インターフェイス （欠けた番号を指定して取り 寄せる）で回収 取り置き回収型 • デバイス側は送れなかった分 だけFlashに退避 • アプリ側では測定完了時に 欠番があれば退避分をまとめ て引き取る

共通して必要なこと • 全パケットに「宛名」（フレーム連番等）を付与 • デバイス側で送れなかったデータを保持（容量・保持期限） • 回収用のBLEインターフェイス 1 1 取り置き回収型のとあるデバイスでは、パケロス回収専用コマンドを作らず、既存のファイル同期コマンドを利用

回収方式を考える際の観点 • デバイスが何を持てるか（全録可能か） • （後付けの場合）既存仕様・既存ユーザーとの整合性

実装中の反省点まとめ

1. 要件と実機制約の矛盾に気付かずハマった 「計測しながらリアルタイムに回収」が当初要件 → なかなかうまく動かない → お客さん経由でハード開発元に確認したところ「再送要求は測定停止 中しか受け付けない（測定中は無応答）」という仕様書に無い制約が判明 → 「停止後の回収」へ方針を切り替え 教訓： 要件が出てきている ハード／FW側でもその要件を満たすよう 作られている、という思い込みを避ける

2. 考慮漏れ • 検出漏れ: フレームの一部パケットが欠けるケースだけを想定し、フレーム丸ごと欠ける ケースを考慮していなかった 2 • 運用スケール想定漏れ: 回収は1フレーム（1秒分のデータ）あたり実時間1秒。計測20時 間でロスが1時間分あれば、回収にも約1時間かかる → キャンセルと手動リトライが必須 • 実ユーザーのデフォルト状態: 開発中は「停止ボタンがある」状態で検証していたが、実 運用では停止ボタンが無く、「切断（＝計測終了） → 回収開始」が主経路だった（切断 されているのですぐに回収できない） 2 そもそもの当初の勘違いとして、パケットロスは稀に・瞬間的に発生するものという思い込みもあった（実際は容易に・連続的に発生する）

3. 仕様書どおりに書いても動かない • 自分の環境で再現しない: すべての再送要求に「データ無し」応答が 返り回収が全件失敗する症状が、先方環境では100%再現。原因は FWバグだった • アプリ / 電波 / FW の3者で切り分ける • 仕様書によると連番は4バイト。実際にはFWは2バイトしか受け付 けない実装になっていた

4. 仕様書にない制約 • （再掲）再送要求は測定停止中しか受け付けない • 連続して送ると、最後の1件しか応答が返らない

まとめ • BLEリアルタイム収集ではパケットロスは避けられない。前提として設計する • パケットロス検出・回収の設計として必要なポイント • 全パケットに「宛名」（フレーム連番等）を付与 • デバイス側で送れなかったデータを保持 • 回収用のBLEインターフェイス • 回収方式： 再送要求型 / 取り置き型 • シンプルに見えますが、それでも実装中はいろいろありました

P.S. 懇親会で話したいこと • 外部デバイス込みのE2Eテストの自動化、どこまでできてま すか？