---
title: パケットロス検出・回収機能の設計 #mobile_mob
tags:  #ios #swift #ble #core bluetooth  
author: [Shuichi Tsutsumi](https://docswell.com/user/shu223)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/5JGLQZQ47L.jpg?width=480
description: 2026.8.26に開催された「Mobile Mob #2 〜スマホのハードウェア制御の悩み・工夫をもっと語り合う〜」での発表資料です。  ※あくまでiOSエンジニア視点からの話です
published: August 26, 26
canonical: https://docswell.com/s/shu223/ZWR8E4-packetloss
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/5JGLQZQ47L.jpg)

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


# Page. 2

![Page Image](https://bcdn.docswell.com/page/47QYKLKREP.jpg)

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


# Page. 3

![Page Image](https://bcdn.docswell.com/page/KE4WPDPQJ1.jpg)

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


# Page. 4

![Page Image](https://bcdn.docswell.com/page/L71Y9Z9LJG.jpg)

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


# Page. 5

![Page Image](https://bcdn.docswell.com/page/G7WGQ9QQE2.jpg)

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


# Page. 6

![Page Image](https://bcdn.docswell.com/page/4JZLW9W3E3.jpg)

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


# Page. 7

![Page Image](https://bcdn.docswell.com/page/YE6WGKGZEV.jpg)

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


# Page. 8

![Page Image](https://bcdn.docswell.com/page/GE5MVPV9E4.jpg)

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


# Page. 9

![Page Image](https://bcdn.docswell.com/page/97293635JR.jpg)

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


# Page. 10

![Page Image](https://bcdn.docswell.com/page/DJY419167M.jpg)

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


# Page. 11

![Page Image](https://bcdn.docswell.com/page/V7NY2LQ1E8.jpg)

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


# Page. 12

![Page Image](https://bcdn.docswell.com/page/YJ9P14DY73.jpg)

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


# Page. 13

![Page Image](https://bcdn.docswell.com/page/GJ8D4Q3KJD.jpg)

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


# Page. 14

![Page Image](https://bcdn.docswell.com/page/LJLM6XVPER.jpg)

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


# Page. 15

![Page Image](https://bcdn.docswell.com/page/47MY5LG27W.jpg)

実装中の反省点まとめ


# Page. 16

![Page Image](https://bcdn.docswell.com/page/P7R93KZ5E9.jpg)

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


# Page. 17

![Page Image](https://bcdn.docswell.com/page/PJXQ4L9X7X.jpg)

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


# Page. 18

![Page Image](https://bcdn.docswell.com/page/3JK9ZLP9JD.jpg)

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


# Page. 19

![Page Image](https://bcdn.docswell.com/page/LE3WD3X9E5.jpg)

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


# Page. 20

![Page Image](https://bcdn.docswell.com/page/8EDKP4287G.jpg)

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


# Page. 21

![Page Image](https://bcdn.docswell.com/page/V7PKNM1WJ8.jpg)

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


