RTC 音声映像伝送における弱ネットワーク対策技術
本ドキュメントでは、弱ネットワーク環境における RTC（リアルタイムコミュニケーション）の音声映像伝送を支える、対策技術の概要を紹介します。
RTC 音声映像技術は急速に発展し、多様なアプリケーションやシーンへ浸透しています。一方で、ユーザーからはより低遅延・高解像度・途切れのない再生といった高い品質が期待されており、それに応える必要があります。
上記のユーザー体験は、RTC の主要な3つの指標（リアルタイム性、鮮明度、スムーズさ）に対応しますが、これらをすべて同時に最大化することは難しい場合が多々あります。低遅延を最優先する場面では画質を落とさざるを得ないこともあり、逆に画質重視では多少の遅延を許容することがあります。
それでもなお最適な効果を得るためには、ネットワーク伝送の最適化が欠かせません。その最大の障壁は「弱ネットワーク」に起因する輻輳、パケット損失、ジッタといった問題です。これらはユーザーエクスペリエンスを著しく損なう主要因といえます。
“弱ネットワーク対策技術” とは、こうしたネットワーク劣化要因や関連する障害を克服するための様々な手法を総称したものです。
TCP/IP プロトコル層選択のポイント
まずはトランスポート層プロトコルについて簡単に説明します。
TCP/IP 階層モデルにおいて、トランスポート層はアプリケーション層の下位に位置し、OS が実装を提供します。代表的なプロトコルには TCP と UDP の2種類があります。TCP はコネクション型で信頼性を重視したプロトコル、UDP はコネクションレス型で、信頼性確保の処理がアプリケーション層に任されるプロトコルです。
リアルタイム音声映像の場面では、UDP を優先的に使うことが業界の常識 となっています。理由は以下の通りです。
- TCP は音声映像のリアルタイム通信向けに設計されていません。輻輳制御およびエラー制御などによって信頼性とスループットを重視するため、遅延が大きくなりがちです。弱ネットワーク下では遅延がさらに増大し、ITU G.114 の指標によればエンドツーエンド遅延が 400ms を超えると、対話品質に明確な悪影響が出るとされています。
- TCP の輻輳制御やエラー制御は OS 内部にあり、アプリケーション側が調整しづらい構造です。状況に応じた柔軟な最適化ができません。
- UDP はヘッダのオーバーヘッドが小さく、制御ロジックはアプリケーション層に委ねられるために拡張性・柔軟性が高いのです。
したがって、本書で取り上げる弱ネットワーク問題や対策技術は、UDP およびその上位の RTP/RTCP を利用するケースを前提に進めます。
弱ネットワークの主な問題と対策
リアルタイム音声映像伝送において「弱ネットワーク問題」とは、主にネットワーク輻輳、パケット損失、ジッタ によってユーザー体験が悪化する事象を指します。これらは画面のカクつきや大きな遅延を引き起こし、ネットワークの構成が複雑かつ多様であるほど問題が顕在化しやすくなります。こうした状況下でのスムーズなコミュニケーション確保は、RTC 分野の重要なテーマです。
輻輳の問題
ネットワークを流れるデータ量がボトルネック容量を超えると、ネットワーク上で輻輳が起こります。
輻輳が発生すると、突発的なパケット損失やジッタが高まります。適切に感知・制御（例：送信レートダウン）ができないと、受信側ではカクつきや遅延増大・画質低下などが顕著になります。
輻輳対策としては、ネットワークの混雑状態を検出し、できるだけ早く復帰するための「輻輳制御アルゴリズム」を設計し、ユーザー体験への影響を最小化することが重要です。
1) 輻輳制御アルゴリズムへの要件
RFC8836 には、双方向リアルタイム音声映像通信の輻輳制御アルゴリズムに求められる事項が体系的に示されています。要点としては：
- 遅延: アルゴリズム自体が追加で発生させる遅延を極力抑えつつ、必要なスループットを確保する。
- スループット: 与えられたシーン内でできるだけ高いスループットを目指す。
- 公平性: 他のリアルタイム流量や TCP トラフィックと帯域を公平に共有する。
- スタベーション回避: TCP 流と競合しても両者が「飢え死に」しないようにする。
- 収束速度: メディアストリーム開始時に、できるだけ早く安定状態に到達する。
- ネットワーク依存性: 特別なネットワーク機能に依存しない。
- 安定度: メディアストリームが一時中断・変更されても安定を保つ。
- 迅速な反応: ボトルネック帯域やリンク遅延など、ネットワーク環境が変化した際に素早く追従する。
要するに、輻輳制御アルゴリズムは (1) 輻輳を正確かつ早期に検知し、(2) その発生を抑えつつ速やかに復元するための送信制御を行うという2大課題に取り組む必要があります。
2) 輻輳検知アルゴリズム
輻輳検知アルゴリズムは、測定手法の違いにより主に以下の2系統に分類できます。
- Loss-based: パケット損失 イベントを監視して輻輳を判断
- Delay-based: 遅延の変動（RTT/OWD 等）を監視して輻輳を判断
双方向リアルタイム通信では、輻輳の兆候を早期に検知・緩和する「Delay-based」の手法が好まれます。損失が起きる前に輻輳を感知できるためです。
一方、Loss-based方式はリンク容量を探索するためパケット送信を増やし続け、損失が発生して初めて輻輳を認識します。特にバッファが大きい環境ではネットワーク遅延が無制限に増大し、数秒単位の遅延を引き起こすこともあります。
ただし、Delay-based アルゴリズムは、損失ベースの流量と競合した際に遅延を過敏に検知しすぎ、送信レートを下げすぎる「飢え死に」現象が発生する恐れもあるため、適切な競合対策が必要です。
Delay-based 手法は RTT (往復伝搬時間) あるいは OWD (片方向伝搬時間) を用いて輻輳推定を行います。RTT は測定しやすい反面、上り・下り双方の遅延の影響が混在しがちです。OWD 測定によりそれを回避できます。下図のように、送信間隔と受信間隔の差異からネットワーク内のキューイング遅延を推定する仕組みです。
3) 輻輳応答手法
簡潔に言えば、輻輳応答手法とは、ネットワークの輻輳状態に応じて適切な送信レートを算出することです。さらに送信端で行う他の弱ネットワーク対策（音声映像エンコーダのビットレート制御、ARQ／FEC の制御等）によって総合的に送信量を調整します。転送ノードが途中にある場合は、SVC レイヤーやマルチストリームなどの方式も考慮されます。
4) 代表的な輻輳制御フレームワーク
次の図は、かつて Google の WebRTC が採用していた初期の輻輳制御フレームワークです。
送信端と受信端のハイブリッド制御を行い、送信端は Loss-based アルゴリズムを、受信端は Delay-based アルゴリズムを用います。
- パケット損失率 < 2% なら送信帯域を 8% 増加
- 2%～10% の場合は維持
- 10% を超えれば送信帯域を大幅に削減する (rate × (1 - 0.5×loss))
受信端では Kalman フィルタを用いて片方向遅延を推定し、実際の受信スループットと組み合わせて帯域を見積もります。その結果を RTCP メッセージでフィードバックし、送信端は損失ベースと遅延ベース両方の結果の最小値を最終帯域として設定します。
次に示すのが改善後の WebRTC 輻輳制御フレームワークです。
ここでは一連の制御ロジックが送信端に集約され、受信端は測定データを返すだけです。
新しいフレームワークでは線形回帰を用いて片方向遅延の増減傾向（上昇・安定・下降）を評価し、現在の送信レートと合わせて最適帯域を推定します。また「積極的な帯域プロービング」を導入し、起動時の収束の速さやネットワーク変動へ対応する速度も向上させています。
パケット損失の問題
前述の通り、RTC でのリアルタイム媒体伝送は主に RTP/UDP 上で行われるため、パケット損失対策はアプリケーション層が担います。
ネットワーク伝送レイヤーでは ARQ（自動再送要請）と FEC（順方向誤り訂正）が代表的な手段です。エンコーディング側での工夫（動画の B フレームなど）と合わせることで損失耐性を高めますが、ここではネットワーク伝送部分に着目します。
1) ARQ（Automatic Repeat Request）
RTP/RTCP では、受信端がシーケンス番号の連続性を監視し、欠落を検知したら RTCP の “NACK” 要求を送信端に送り、失われたパケットの再送を要求する方式が取られます。以下の図のように動作します。
欠落（seq# 101 や 102 など）が見つかったら、NACK(req 101, 102) を送信し、送信端はこれらのパケットを再送します。専用の SSRC を用いることで損失統計や再送帯域を分離して管理しやすくなります。
ARQ には以下のような考慮事項があります：
- 初回リクエストの遅延: 欠落を検出して即リクエストするか、FEC と組み合わせるかなどで検討。
- 再リクエスト間隔: 同一パケットに対する再リクエストは RTT 分以上の間隔を空ける。
- リクエスト回数制限: RTT や許容遅延から最大回数を算出。
- ARQ 帯域制限: 再送パケットが帯域を圧迫しないよう上限を設定。
- 再送パケットの送信用 SSRC: 別 SSRC を使うと損失率や再送帯域を正確に把握できる。
2) FEC（Forward Error Correction）
リアルタイム音声映像で広く用いられる FEC は、パケットロスをすぐに回復できる利点があります。
基本的には、送信端でソースパケット以外に冗長パケットを追加し、受信端はその冗長パケットを利用して欠落データを復元します。
冗長データの生成方式には XOR や行列ベースなど複数がありますが、詳細は省略します。
以下は送信端側の FEC フレームワーク例です（ADU = 音声映像などのアプリケーションデータ）。エンコーダが一定の修復率で FEC パケットを生成し、それらとソースパケットおよび保護関係メタ情報などを一緒に送ります。
次は受信端側です。ソースパケットと修復パケットを FEC デコーダへ入力し、欠落があれば保護関係に基づいて復元し、上位に引き渡します。
RTP/RTCP の枠組みでは、ULPFEC（RFC5109）や FlexFEC（RFC8627）などが標準化されています。
- ULPFEC は Uneven Level Protection（重要度によって冗長度を変える）
- FlexFEC はインターリーブ／ノンインターリーブのパリティ符号を柔軟にサポートします
3) ARQ と FEC の組み合わせ
FEC と比べた場合、ARQ は再送により遅延が増える欠点がある一方、帯域利用効率は高いというメリットがあります。理想的には遅延要求を満たしつつ最低限の追加帯域で損失耐性を確保することが目標です。
したがって、ARQ と FEC を組み合わせる際は以下の点を考慮します：
- RTT や最大遅延許容値から再送可能回数を算出し、許容範囲内でできるだけ ARQ を活用する。
- 再送だけで損失率を1%未満に下げられるなら、FEC は不要となる場合がある。
- FEC を使う場合は、残余の損失率に応じた冗長率を設定し、最終的な保険とする。
次の図は、異なる RTT 条件下で ARQ と FEC をどのように使い分けるかを示した例です。RTT<20ms、最大遅延100ms の状況で損失率30%でも ARQ だけで1%以下まで抑えられるため FEC は不要になります。RTT が大きくなるにつれ FEC の比率が増え、最終的には FEC のみで回復するようになります。
ジッタの問題
ジッタ とは、ネットワーク遅延が時間的に変動することです。ジッタが大きいと映像が飛んだり音声が途切れたりして、音声映像の品質に深刻な影響を及ぼします。原因としては、新たなストリームの参入や送信レートの不安定性、ネットワークの総合的な揺らぎなどが挙げられます。
通常は、受信端でジッタバッファを設けることでこれを吸収し、再生を安定化させます。
必要なバッファを計算することが課題です。大きすぎると余分な遅延を生み、小さすぎるとジッタを吸収しきれません。Google の WebRTC 実装では、音声と映像で異なる推定手法が使われています：
- 音声：NetEQ モジュールによりヒストグラム＋フォーゲットファクターで到着間隔を統計し、95 パーセンタイルを参照してジッタ遅延を見積もる。
- 映像：フレームサイズや遅延変動を計測し、カルマンフィルタによる動的推定を行う。
ただし、WebRTC は1対1の通話を想定しているため、中継サーバを介する多人数会議などでは更なる最適化が必要になる場合があります。
Tencent RTC における弱ネットワーク対策の実践
TRTC (Tencent RTC) は弱ネットワーク環境で高い性能を示します。コア技術の最適化と実証テストから、以下のように大きな効果が確認されています。世界規模のエンドツーエンド遅延は 300ms 以下、パケット損失許容は 80% 超、ジッタも 1000ms 超まで耐えられます。主な対策を以下にまとめます。
1. トランスポート層の最適化
UDP + RTP/RTCP の構造により、TCP のようなキュー詰まりや輻輳制御の遅延を回避。
• NACK ベースの再送機構：シーケンスが不連続な場合のみ NACK を発行し、抜けたパケットを正確に再送。不要な ACK の往復を削減し遅延を低減。
• FEC（Forward Error Correction）との統合：送信端で少量の冗長パケットを送っておき、受信端でそれを使って欠落を復元し、再送待ちの遅延を大幅に削減。
• FEC と ARQ をリアルタイムに切り替えまたは併用し、状況に応じて冗長率や再送回数を調整。
2. QoS による自動帯域制御
QoS は、リアルタイムでパケット損失率、RTT、ジッタ等を測定し、使用可能な帯域を推定。
推定に基づき、エンコーダのビットレートや FEC 冗長度、再送量を即時に調整。ネットワークの急変に迅速対応し、過剰送信による輻輳や無駄な冗長を回避。
3. コーデック層での改良
動画フレームの参照関係を変更し、「前フレームへの厳密依存」を緩和。単一のフレーム損失によって後続のデコード連鎖が崩れにくくし、ロス耐性を向上。
音声では PLC（Packet Loss Concealment）を採用。フレーム損失時に前後フレームの特徴から不足分を補間し、高損失でも自然に近い音質を保つ。
4. ジッタバッファと同期への取り組み
受信側に適切な Jitter Buffer を設定。到着時間と再生時間に合わせてバッファ量を動的に調整し、低遅延と安定性のバランスを確保。
音声と映像の同期機構も提供。両者の到着差分やジッタを検知し、再生速度を微調整して映像と音声を合わせることで、再生のズレによる視聴感の悪化を防ぐ。
5. エコーキャンセリングとダブルトーク対策
Tencent 自社開発の TRAE（Tencent Real-time Audio Engine）によって、スピーカーとマイク間の AEC（Acoustic Echo Cancellation） を実現し、音声ループを防止。
同時発話（ダブルトーク）が起きてもフィードバックノイズを除去し、双方が相手の声を明瞭に聞き取れるよう最適化している。
6. クラウド側の意思決定とビッグデータ分析
QoE (Quality of Experience) フレームワークを導入し、パケット損失率、遅延、MOS スコアなどをリアルタイムで集約。ユーザーの主観的体験を正確に評価。
クラウド意思決定システムがユーザーやネットワークごとにパラメータを微調整し、最適な送受信戦略と最高の音声映像品質を提供。
これら複数の技術を組み合わせることで、TRTC は大きなパケット損失や深刻なジッタを抱える環境でも低遅延・高品質の通信を維持できます。オンライン教育、リモートワーク、双方向ライブ配信などさまざまなシーンで有用なソリューションを提供しています。
Discussion