RFC 3095：ROHC は戻りチャネルなしで始まった

要約

無線リンクでは、小さな音声ペイロードに対してIP、UDP、RTPヘッダーが大きな比率を占める。一定または予測可能なフィールドを省けば容量を節約できるが、受信側は共有状態から元のヘッダーを復元しなければならない。更新を一つ失えば、リンク自体が正しく届けた後続パケットまで復元不能になり得る。

RFC 3095は「状態」と「モード」を分けた。圧縮側のIR、FO、SO状態は予測モデルの成熟度を示し、伸長側のNo Context、Static Context、Full Contextは復元可能な範囲を示す。モードが答えるのは別の問い、すなわち戻り経路にどの程度の調整権限が実在するかである。

出発点は明確だった。圧縮はU-modeで始めなければならない。戻り経路が使えない、または望ましくない場合でも動作するためである。圧縮側は十分な情報を繰り返したと判断すれば、楽観的アプローチでより短い形式へ進む。タイムアウト、周期更新、フィールド変化の乱れが起きれば、より情報量の多い形式へ戻る。

「十分らしい」は確認応答ではない。沈黙による損害を限定する判断であり、沈黙を受信証明に変えるものではない。

圧縮側は戻りチャネルの存在を宣言だけで作れない。パケットを受けた伸長側が希望モードを含むフィードバックを送り、初めてO-modeまたはR-modeへの移行が可能になる。

この方向には理由がある。圧縮側が観測できるのは送信内容であり、復元に成功したかを観測するのは伸長側である。直接のコンテキスト障害を負う側が、次の形式を選ぶ側へ制御要求を返す。

RFC 4815は後に、モード移行を三段階のハンドシェイクとして明確化した。確認点の前後では旧モードと新モードを正しく使い分ける必要がある。「信頼」という名前だけでは、両端を同時に移す手順にならない。

O-modeは、エラー回復要求と重要なコンテキスト更新への任意の確認に戻りチャネルを使う。ただし純粋なシーケンス番号更新は同じ扱いではなく、周期更新も行わない。目的は高い圧縮効率と、フィードバックの疎な利用だった。

これはリスクの消滅ではなく配分変更である。検出された障害には応答できる一方、長い損失・誤りバーストではR-modeより頻繁にコンテキストが無効化され得るとRFCは記している。

NACKが語るのは復元状態である。音声が聞き取れたか、アプリケーションがペイロードを使ったか、利用者にサービスが届いたかは証明しない。

R-modeは戻りチャネルをより多く使い、両端に厳格な規則を課した。シーケンス番号を含む全コンテキスト更新を確認するが、すべてのR-modeパケットが更新を行うわけではない。安全な参照原則により、7ビットまたは8ビットCRCを持つパケットだけがコンテキストを更新し、後続復元の参照になれる。

ここでの信頼性は限定された意味を持つ。ヘッダーやフィードバックの損失・破損から損失伝播と損傷伝播を減らすことである。残留ビット誤りやCRCの限界は残る。R-modeはペイロード、アプリケーション、全経路の成功証明ではない。

RFC 3096は、高誤り率と長い往復遅延を持つリンクを要件の背景とし、WCDMA、EDGE、CDMA-2000を挙げた。復元ヘッダーは元と意味的に同一でなければならず、不可能ならパケットを破棄する。また、以前の損失が後続ヘッダーを壊す誤り伝播を最小化するよう求めた。

効率の計算には補助制御とフィードバックも含める必要があった。順方向ヘッダーだけを小さく見せ、逆方向の確認や回復を帳簿から外すことは許されない。

RFC 3409は下位層との契約を明示した。U-modeはフィードバックなしで動くが、O-modeとR-modeは小さな逆方向パケットを下位層が運ぶ必要がある。プロトコルは実在する能力を利用できても、存在しない能力を仮定できない。

RFC 4815は修正と明確化を集めた。RFC 4995はフレームワークとプロファイルを分離し、実装者が旧仕様を複雑で時に不明瞭と感じたことを記録しつつ互換性を述べた。RFC 5225は損失や並べ替えへの仕組みを持つ簡略化されたROHCv2プロファイルを定義した。

RFC 3241はPPP上での交渉と運搬方法を標準化した。これらは仕様作業の証拠であり、特定事業者の導入、実測の周波数利用効率、ハンドオーバー成功、特定製品間の相互運用を証明しない。

歴史的な境界は明快である。RFC 3095はフィードバックを、方向と費用と観測者を持つ能力として扱った。圧縮側の予測、伸長側が共有コンテキストについて確認できること、エンドツーエンド観測が必要な結果を分離したのである。