Air-Gapped Connectivity: 最適化された逆トンネルによるLiFi光無線ネットワーク

電波が禁止されている場合、光があなたのデータパイプとなります。高セキュリティのLiFi設置に固有の物理的制約や突然の視線喪失に耐えるネットワークトンネルの設定方法をご紹介します。

極秘の企業施設、SCADA制御の産業プラント、レーダーに敏感な防衛インフラでは、従来のRadio Frequency (RF) 通信—Wi-Fiや携帯ネットワークなど—は厳しく禁止されています。RFの盗聴リスク、電磁干渉（EMI）の壊滅的な影響、石油化学ゾーンの爆発性雰囲気などの理由で、エンジニアは長らく物理的な銅線や光ファイバーケーブルに頼ってきました。

物理的な接続は、動的な運用環境やアジャイルな開発インフラ、自律型ロボットの運用を妨げます。そこでLight Fidelity (LiFi) と光無線通信（OWC）が登場します。2023年6月に標準化されたIEEE 802.11bbとして、LiFiは近赤外線800 nmから1,000 nmの波長帯で動作し、MACデータサービスアクセスポイントで10 Mb/sから9.6 Gb/sのスループットを実現します—Wi-Fi 6とほぼ同等です。研究者は高度な波長分割多重（WDM）構成を用いて、実験室条件下で224 Gbit/s超のピークデータレートを示しています。

LiFiは、Vertical-Cavity Surface-Emitting Lasers（VCSEL）や高度なLEDなどの固体光源を用いて、超高周波数でデータを変調します。動作範囲は広く、未許可のスペクトルであり、設置された部屋の外からは基本的に検出できません：光子は硬い壁を通り抜けません。

しかし、この物理的なセキュリティ特性は、突然の視線（LoS）ネットワークトンネリングの劣化という深刻な脆弱性ももたらします。通路に一時的な障害物—通行人、AGV、構造振動など—が入ると、光リンクは瞬時に崩壊します。安全な開発環境や逆SSHトンネル、産業用テレメトリパイプラインを守るために、ネットワークインフラのエンジニアは高度なトランスポート層の最適化と積極的なForward Error Correction（FEC）を実装しなければなりません。

---

1. LiFiネットワークアーキテクチャの構造

堅牢なLiFiネットワークを構築するには、光トランシーバとネットワークスタックの相互作用を深く理解する必要があります。従来のRFとは異なり、LiFiは主に指向性であり、視線制約に厳密に従います。壁や天井の反射による拡張もありますが、最も高スループットな経路は常に直接のLoSリンクです。

標準規格：IEEE 802.11bbとその進化

IEEE 802.11bb規格は2023年6月に承認され、pureLiFiとFraunhofer HHIが共同で主導したタスクグループによって開発されました。PHY仕様と双方向LiFi動作のシステムアーキテクチャを定義し、800–1,000 nmの近赤外線帯域で動作し、MAC層のスループットは最大9.6 Gb/sです。

次世代規格もすでに開発中です。IEEE 802.11bk-2025（Enhanced Light Communications、ELC）は、可視光の400–600 nmと拡張された近赤外の1,200–1,600 nmの新しい光学帯域に拡張し、波長分割多重（WDM）をサポート、量子耐性暗号（PQC）拡張も導入します。2025年5月から活動を開始したIEEE 802.11brタスクグループは、マルチリンク運用によるモバイル端末のハンドオフを改善しています。

これらは学術的な演習ではありません。2024年4月時点で、pureLiFiと提携したVibrintは、認証済みのLiFi通信機能を商用化し、政府の機密環境向けに提供しています。2021年には、米陸軍ヨーロッパ・アフリカ司令部が、pureLiFiのKitefinシステムを用いて、戦術・戦略環境で数千台の認証済みLiFiユニットを展開し、最初の大規模運用を完了しています。

送信機と受信機のダイナミクス

標準的な光無線リンクは、デジタル→光変調器と光→デジタル受信器から構成されます：

ダウンリンク（アクセスポイント）： 商用または堅牢なLED/VCSEL装置に超高速デジタル変調ドライバを装備。高度なシステムは、ナノ秒単位で狭い光ビームを制御できる独立制御可能なVCSELアレイを使用し、空間多重を実現します。

アップリンク（クライアントエンド）： 高感度のフォトダイオード（PD）で終端し、通常はアバランシェフォトダイオード（APD）やPINフォトダイオードを使用。光強度の変動をキャプチャし、トランジスタインピーダンス増幅器（TIA）とアナログ→デジタル変換器（ADC）を通じてデジタルベースバンドデータを抽出します。

問題点：アトセルとバイナリ消失チャネル

施設をカバーするために、エンジニアは*attocell*と呼ばれる小さな非干渉の光セルを展開します。受信フォトダイオードの視野角（FOV）制限により、クライアント端末は特定のアクセスポイントの光コーン内にいる間のみ接続を維持します。

これにより、バイナリ消失チャネル（BEC）が発生します—LiFi環境におけるアクティブネットワークトンネルの主要な脅威です。RFと異なり、信号は距離に伴う緩やかな劣化ではなく、ステップ関数的にドロップアウトします。光路を遮ると、信号対雑音比（SNR）はマイクロ秒でゼロに落ち込みます。標準的なTCPトンネルはDevOpsデータや産業用テレメトリのルーティングにおいて、これを深刻なネットワーク混雑とみなして、混雑崩壊を引き起こします—次節で詳述します。

---

2. なぜ従来のトンネリングプロトコルは光リンクで崩壊するのか

標準的な企業のリモートアクセスフレームワーク—OpenVPN（TCPモード）、標準SSHトンネル、またはWireGuard over UDP—は、基盤となる物理媒体が常に持続的であると暗黙に仮定しています。LiFiのステップ関数的な消失特性にさらされると、これらのプロトコルは致命的な失敗を示します。

TCPの混雑崩壊の罠

逆トンネルをTCPで初期化すると、状態を追跡するACK確認フレームワークに依存しますが、これはバースト消失には根本的に不適合です。TCP送信側がACKを受信できず、再送タイムアウト（RTO）が発生すると、RFC 5681に定義された以下のシーケンスが実行されます：

1. ssthreshは現在の輻輳ウィンドウの半分に設定される
2. cwndは1 MSS（最大セグメントサイズ）にリセットされる
3. 送信側はスロースタートフェーズに再び入り、cwndはssthreshまで指数関数的に増加し、その後線形に増加します

実際の結果：LiFiビームを数百ミリ秒遮る物体があると、連続するパケットが一度に破壊されます。受信側はギャップを検知し、その後のデータをアプリケーション層に転送せず、受信パケットをバッファします。ACKを受け取れない送信側はRTOを経てcwndを最小にし、ラインオブサイトが復旧しても、すぐに回復せず、スロースタートを経てスループットを再構築します。この回復期間中、アプリケーションは遅延とスループットの著しい低下を経験します。これがHead-of-Line (HoL) ブロッキングの最も破壊的な形態です。

これは理論的な話だけではありません。バーストパケット損失によるTCPの研究では、TCP TahoeやRenoを用いた実装では、パケット損失により少なくとも1秒間タイムアウトが発生することが示されています。TCP SACKも、順不同のデータを選択的にACKすることで回復時間を短縮しますが、複数のパケットが同時に失われた場合、パイプラインの排出なしに回復できないことがあります。

WireGuardとサイレントタイムアウト

WireGuardはUDP（デフォルトポート51820）上で動作し、HoLブロッキングを回避しますが、内部のTCPストリームのバースト損失には対応できません。その二次的な失敗モードは微妙です。

WireGuardの公式ドキュメントは、PersistentKeepalive値を25秒に推奨しています—これはほとんどのファイアウォール実装でNATマッピングを維持するための合理的な間隔です。パケットは小さく、WireGuardペイロードは32バイト（16バイトのヘッダーと16バイトのPoly1305タグ）、IPv4上では約60バイトです。キープアライブ間隔が完全に静止していると、ファイアウォールやNATデバイスはUDPセッションのマッピングを期限切れにします。LiFiのLoSダウンと正確に同期した場合や、それを超えると、NATの状態テーブルが非同期になり、外部トンネルの再構築が必要となることがあります。

セルラーのNATデバイスはタイムアウトを30秒程度に設定していることもあり、標準の25秒のキープアライブでは不十分な場合があります。

---

3. 耐障害性の高いトランスポート層設計：予防的 vs. 反応的回復

LiFiインフラを跨ぐ高可用性トンネルを維持するには、リンク障害に対して反応的（再送）と予防的（冗長性挿入）の両方に対応する二重戦略のアーキテクチャが必要です。

指標	従来のVPNトンネル（TCP-SSH / OpenVPN）	耐障害性の高い光リンク（QUIC + FEC）
主な伝送方式	TCP（状態追跡、線形）	UDP / QUIC（コネクションレス、多ストリーム）
消失回復	反応的ARQ（損失時に再送）	予防的ブロック消失符号化（FEC）
バーストダウンタイムへの対応	輻輳ウィンドウ崩壊; スロースタート	パリティパケット再構築; RTTペナルティなし
Head-of-lineブロッキング	重要; 一つの損失で全ストリーム停止	なし;ストリームごとに独立
接続識別子	IP4タプルに紐づく	暗号化コネクションID（QUIC RFC 9000）
キープアライブのオーバーヘッド	高; 頻繁なTCPキープアライブ	低; CIDは経路変更に耐える

ARQとFEC：損失の哲学

標準ネットワークはAutomatic Repeat reQuest (ARQ)に依存します：受信側が欠落データを検知し、送信側に再送を要求します。ARQは根本的に反応的であり、再送ごとに少なくとも1RTTを要します。LiFiのようにLoSダウンタイムが数百ミリ秒に及ぶ場合、ARQは敗北戦略です。損失検知から再送要求、データ受領までにバッファが飢餓状態になったり、アプリケーションタイムアウトが発生したりします。

耐障害性の高いLiFiトンネルはForward Error Correction (FEC)に移行します：送信側は、送信前に数学的冗長性をアウトバウンドデータに挿入します。これにより、バーストパケット損失が発生しても、受信側はパリティ情報から欠落データをローカルに再構築でき、RTTのペナルティや再送要求は不要です。

なぜQUICが理想的なキャリアなのか

RFC 9000は2021年5月に公開され、QUICトランスポートプロトコルを定義しています。これにはLiFiトンネルに特有のいくつかの特性があります：

コネクションの移行： QUICは単一のネットワークパスに厳密に拘束されません。コネクションID（CID）を用いて、新しいネットワークパスに移行可能です。これにより、モバイル端末が光セル間を移動しても、FEC層が移行ギャップを橋渡しすれば、トンネルは切断されずに継続します。

ストリームの独立多重化： TCPはすべてのデータを順序付きバイトストリームに直列化しますが、QUICは複数の論理ストリームを分離し、一つのストリームのパケット損失が他に影響しません。バックグラウンドのファイル同期の損失は、前景のテレメトリを遅らせません。

0-RTT確立： QUICは、既知のサーバーとの次回接続でゼロRTTで再接続でき、回復時間を短縮します。

---

4. パケットレベルのForward Error Correction（FEC）の実装

最大の安定性を確保するには、バイナリ消失チャネル上で、ブロックレベルまたはレイタレス符号化をパケット層で採用する必要があります。主要なアプローチはReed-Solomonブロック符号とFountain Codes（RaptorQ）です。

Reed-Solomon（N, K）ブロック符号

Reed-Solomonコードは（N, K）形式で動作します。エンコーダはK個の元のソースパケットを受け取り、合計N個のパケットを生成します—K個のソースパケットと（N−K）個の数学的に導出されたパリティパケットです。受信側は、N個のうち任意のK個のパケットから元のKパケットを復元可能です—ただし、損失がN−Kを超えない場合に限ります。

この数学的基盤は、有限体（Galois Field）上の演算に依存します。N,Kのコードでは、ジェネレータ行列GをGF(2^q)上のヴァンダモンドまたはカウシー構造で構築し、ソースデータベクターDに掛け算します：

Y = G · D

LiFiのドロップアウト中にパケットが失われた場合、受信側は削除されたパケットのインデックスに対応する行を除いた修正行列G’を作成し、受信したデータY’から元のデータを正確に復元します：

D = (G')⁻¹ · Y'

実用的には、GF(2^8)やGF(2^16)上で動作するReed-Solomonコードが一般的です。広く使われているオープンソース実装はklauspost/reedsolomon Goライブラリで、SIMD最適化されたガロア場演算を用いて1 GB/s超のエンコード速度を実現しています。この符号化方式はLinuxのソフトウェアRAIDや、Backblaze、Microsoft Azure、Facebookの分散ストレージでも採用されています。

例えば、（N=20, K=15）コードは、15パケットのブロックに対して5パリティパケットを追加し、約33%のオーバーヘッドで、5パケットのバースト消失に耐えられます。

固定レートのReed-Solomonの制約は、損失が（N−K）を超えると、そのブロック全体が復元不能になる点です。長時間のLoSダウンタイムには別のアプローチが必要です。

Fountain Codes（RaptorQ）による任意のドロップアウト

レイタレスFountain Codes、特にRaptorQ（IETF RFC 6330、2011年8月）は、固定レートの上限を排除します。符号化器はK個のソースパケットを、ほぼ無制限のエンコードシンボルのストリームに変換します。受信側は、Kを少し超えるエンコードシンボルの任意の組み合わせを受け取ることで、完全なペイロードを再構築できます—RFCは、多くの場合K個の符号だけで十分と規定しています。

この再構築は、どのパケットが到着または失われたかに依存せず、光の断絶時間にも左右されません。長時間のドロップアウトでも、ブロック境界を超えて復元不能になることはありません。RaptorQのオーバーヘッドは非常に小さく、ほぼすべての条件で0.1%以下です。

RFC 6330は、FECエンコーディングID 6に対応した完全仕様のFEC方式です。オープンソース実装にはOpenRQ（Java、MITライセンス）やharmony-one/go-raptorqがあります。商用トンネルには、アプリケーションレベルのFECラッパーがこれらのライブラリをUDP/QUIC送信パスと連携させます。

---

5. アーキテクチャガイド：堅牢なLiFiトンネルスタックの構築

以下のアーキテクチャは、WireGuard（暗号化されたトンネルカーネル）とユーザースペースFECラッパー（Reed-SolomonまたはRaptorQをUDP層で適用）を組み合わせて、セキュアな開発や産業環境向けのブラックアウト耐性逆トンネルを実現します。

ステップ1：ユーザースペースFECラッパーの展開

ローカルのセキュアクライアント（LiFiアップリンクでデータを送信するマシン）では、FECプロキシを設定し、WireGuardのUDP出力をインターセプトしてパリティパケットを挿入し、冗長ストリームをリモートの光ゲートウェイに転送します：

# アグレッシブなFECトンネルラッパーを初期化
# モード： (N=20, K=15) - 15ソースパケット + 5パリティパケット（約33%オーバーヘッド）
fec-tunnel-client --local-listen 127.0.0.1:9000 \
                  --remote-target 192.168.10.50:9000 \
                  --fec-k 15 --fec-n 20 \
                  --mtu 1280 --timeout 50

--mtu 1280フラグは、各UDPデータグラムに付加されるFECブロックヘッダの追加分を考慮し、IPフラグメンテーションを防ぎます。--timeout 50（ミリ秒）は、FECブロックのエンコードウィンドウを設定し、K個のソースパケットをためてから完全なブロックを出力します。

ステップ2：WireGuardをFECループバック経由に設定

WireGuardの暗号化されたUDP出力を、LiFiリンクに直接送るのではなく、ローカルのFECループバックに向けます。MTUを1200に下げてフラグメント化を防ぎ、PersistentKeepaliveをデフォルトの25秒より短く設定して、堅牢なファイアウォールのNATタイムアウトに対応します：

# /etc/wireguard/lifi-secure-tunnel.conf
[Interface]
PrivateKey = [CLIENT_PRIVATE_KEY_BASE64]
Address = 10.0.0.2/24
MTU = 1200
ListenPort = 51820

[Peer]
PublicKey = [GATEWAY_PUBLIC_KEY_BASE64]
# 暗号化されたWireGuard UDPをローカルFECラッパーにルーティング
Endpoint = 127.0.0.1:9000
PersistentKeepalive = 10
AllowedIPs = 10.0.0.0/24

PersistentKeepalive = 10は、10秒ごとに60バイトのキープアライブパケットを送信し、状態を維持します。これは、SCIF隣接のファイアウォールで一般的なアクティブな状態管理に適しています。

ステップ3：サーバー側のFEC復元エンジン

受信ゲートウェイ（セキュアネットワーク側のLiFi天井トランシーバに配線された）では、対応するFECデコーダがストリームを復元し、クリーンなUDPをローカルのWireGuardリスナーに渡します：

# サーバー側FEC復元エンジンの初期化
fec-tunnel-server --local-listen 192.168.10.50:9000 \
                  --remote-target 127.0.0.1:51820 \
                  --fec-k 15 --fec-n 20

パケットのフロー全体は次の通りです：

[ 開発マシン ]
      |
      | (アプリケーション通信)
      v
[ WireGuard tun0 インターフェース ]
      |
      | (ChaCha20-Poly1305暗号化されたUDPループバック)
      v
[ ユーザースペースFECプロキシ ]
      |
      | (RS符号化されたUDP：1ブロックあたり15データ + 5パリティ)
      v
[ LiFi変調ドライバ ]
      |
      | (高周波赤外線パルス、800–1000nm)
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      [ 物理的視線 ]   <– 作業者がビームを横切る
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |
      | (遮断された光子; デコーダはブロックを保持)
      v
[ アバランシェフォトダイオード + TIA ]
      |
      | (再構成されたアナログ信号)
      v
[ サーバーFECエンジン ]             <– 行列逆変換で損失パケットを復元
      |
      | (クリーンなUDPストリーム)
      v
[ WireGuardゲートウェイ wg0 ]
      |
      v
[ セキュアターゲットネットワーク ]

エンジニアがこの展開でDockerイメージのプッシュやリポジトリ同期を行うと、FEC層は光学的な消失バーストを静かに吸収します。WireGuardはパケットロスを検知せず、その輻輳状態も維持されます。

---

6. 環境ベクトルに対する堅牢化技術

LoSダウンタイムの問題を超えて、LiFi展開にはいくつかの二次的な環境脅威に対処する必要があります。

周囲光汚染とフォトダイオードの飽和

フォトダイオードの主要な故障モードは、外部光源による飽和です—窓からの自然光、高輝度アーク溶接の閃光、フィルタ不足の天井照明など。静的な周囲光子にフォトダイオードが満たされると、そのダイナミックレンジが圧縮され、ビット誤り率（BER）が上昇します。これは、トンネルのFEC設定に関係なく発生します。

二つの対策を併用します：

光学バンドパスフィルタリング： 850 nmを中心とした狭帯域フィルタ（±20 nm）を受信窓に取り付け、意図した信号波長以外の光子を物理的に遮断します。これにより、外部の光子フラックスを大幅に削減できます。

DCキャンセリング機能付き変調方式： Manchester符号化やPulse-Position Modulation（PPM）は、一定の平均光出力レベルを維持します。これにより、受信側のハイパスフィルタは、背景の直流光を除去し、高周波のデータ変調だけを抽出します。IEEE 802.11bb仕様では、OFDMを用いたIM/DDチャネルに適応したベースバンドが採用されており、PAPR（ピーク対平均電力比）の管理も行われています。次世代の802.11bkではこれが拡張されます。

ダイナミックジッタバッファリング

光ビームの一部だけを部分的にクリップする物理的障害物がある場合、信号は完全に遮断されず、振幅の急激な変動を伴います。これにより、ジッタ（到着間隔の変動）が発生し、アプリケーション層のタイムアウトを引き起こす可能性があります。

このため、ユーザースペースのプロキシにダイナミックジッタバッファを挿入し、不規則なパケット到着を吸収し、tunやtapの仮想ネットワークインターフェースに予測可能な速度でデータを供給します。バッファのサイズは、展開環境のLiFiハードウェアのドロップアウト特性に合わせて調整します。一般的な工業環境では50–200 msのバッファが推奨されます。

ソケットバッファの調整によるブラックアウト後のバースト回復

長時間のLiFiダウンタイムが解消し、FECデコーダがバッファされたブロックを再構築すると、一度に複数のパケットがWireGuardインターフェースに到着します。カーネルのソケットバッファが十分でないと、パケットは処理前にドロップされ、FECの効果が無駄になります。Linuxでは、UDP受信バッファの上限を増やす必要があります：

# UDPソケット受信バッファの上限を増加
sudo sysctl -w net.core.rmem_max=26214400
sudo sysctl -w net.core.rmem_default=262144

# 起動時に適用
echo "net.core.rmem_max=26214400" | sudo tee -a /etc/sysctl.d/99-lifi-tunnel.conf
 echor "net.core.rmem_default=262144" | sudo tee -a /etc/sysctl.d/99-lifi-tunnel.conf

---

7. 実運用例：光ベースルーティングの適用範囲

LiFiは、セキュアな通信のための理論的な概念だけではありません。いくつかの重要インフラ分野で実運用されています。

SCADAと産業製造

現代の産業環境—石油化学精製所、高電圧の自動化変電所、爆発性雰囲気のATEXゾーン—では、EMIリスクや高電流誘導機械周辺のアーク放電リスクにより、RF無線の安全な展開は困難です。光無線データリンクを天井に展開すれば、数ギガビットの通信を自律ロボットアームやAGVに提供し、環境にRF放射を一切放出しません。

Fraunhofer IPMSは、20年以上にわたりLiFiの開発を続けており、そのソリューションは遅延と信頼性の面でWi-Fiや5Gを凌駕すると特記しています。

高セキュリティの政府・防衛インフラ

SCIF（Sensitive Compartmented Information Facilities）や軍事研究環境では、標準の電波は盗聴リスクが高すぎます。外部の高利得指向性アンテナでRF放射を捕捉される恐れがあります。可視光や近赤外線は、建築材料を透過しないため、物理的な境界が絶対的な信号境界となります。

これが、pureLiFiのKitefinシステムが2021年に米陸軍ヨーロッパ・アフリカ司令部に採用された理由です。世界初の大規模LiFi展開であり、Intelligent WavesやVibrintも、米国政府や国家安全保障市場向けに認証済みLiFiソリューションを提供しています。検知や傍受の確率が低く、電磁シグネチャもほぼゼロ、ジャミング耐性も高いため、分類された環境においてRF技術を凌駕します。

航空宇宙と航空電子組立

高高度航空機、衛星、誘導システムの組立・調整段階では、電波干渉を避けるために、ファームウェアの更新やセンサーのリアルタイム監視を行います。LiFiトンネルは、EMCクリーンルームの電波規制を破ることなく、ファームウェア更新やセンサー監視を可能にします。航空・輸送業界は、IEEE 802.11br（ELC）タスクグループの関係者として、次世代LiFi MACの開発に関心を示しています。

---

8. まとめ：光のフロンティアを切り拓く

LiFiは、IEEE 802.11bb（2023年承認）とその後継規格802.11bk、802.11br（2024–2025年開発中）により、標準化された相互運用可能なエコシステムへと進化しています。エンジニアは、そのトランスポート層の失敗モードを理解し、適切な対策を講じる必要があります。

核心のポイント：LiFiの物理層のセキュリティは非常に優れていますが、遅延と信頼性のペナルティにより、短時間のLoS断絶時に従来の状態追跡TCPトンネルは破綻します。解決策は、ハードウェアの高速化ではなく、正しいトランスポートアーキテクチャの採用です。

レガシーのTCPトンネルをUDP/QUICに置き換え、積極的な数学的消失訂正（Reed-SolomonやRaptorQ）を組み込み、カーネルソケットバッファや光学バンドパスフィルタリングを適切に調整することで、突然のLoS喪失にもアプリケーションに見える影響なく耐える逆トンネルを構築できます。

未来の高セキュリティネットワークでは、データパイプラインは脆弱な光子かもしれません。適切な暗号化と数学的支柱を用いれば、そのトンネルは破綻しなくて済みます。

---

変更履歴

• 標準規格の修正： IEEE 802.11bbの承認は2023年6月と確認され、MAC層のスループット範囲は10 Mb/sから9.6 Gb/sに修正（研究条件の224 Gbpsはシステムレベルの数値ではなく、実験室のWDM研究の結果です）。ピーク研究デモの文脈でのみ224 Gbit/sの数値を保持。
• ELC/802.11bkと802.11brの追加： 2024–2025年に活発な次世代規格の詳細を追記。LiFiの可視光・近赤外線帯域拡張とWDM、PQCの追加を明記。
• WireGuardのキープアライブの正確な記述： 25秒はWireGuardの推奨値であり、60バイトのオンワイヤサイズも確認済み。例示の設定では10秒に短縮。
• TCPの混雑崩壊の根拠： RFC 5681に基づく詳細なcwndやssthreshの動作を記載し、曖昧な「混雑崩壊」の表現を正確に修正。
• RaptorQのRFC 6330との整合性： IETF標準に基づく符号化方式と、復元閾値の正確な説明を追加。
• Reed-Solomonの実装例： klauspost/reedsolomonのMITライセンスのGoライブラリを引用し、速度や採用例を明示。
• 実運用例の追加： pureLiFi Kitefin / US Army USAREUR-AF展開（2021年）、Vibrintの認証済LiFi（2024年4月）、Fraunhofer HHIの産業用事例、Intelligent Wavesの導入例を追記。
• MTUとソケットバッファの具体的設定値： ポストブラックアウトのバースト処理のためのsysctl設定例を新規追加。
• 虚偽の数値や未検証のベンチマークの削除： 信頼性のある情報のみを掲載し、未検証の速度や比較数値は除外。