メインコンテンツまでスキップ

3.2.1.2. Receiver Behavior (受信機動作) (RFC 8724 のセクション 8.4.3.2 を置き換え)

3.2.1.2. Receiver Behavior (受信機動作)

その時点で処理されていない RuleID と DTag ペアを持つ SCHC Fragment を受信したとき:

  • receiver (受信機) はその RuleID 値に対してその DTag 値が最近使用されていないことを確認すべきであり, それにより受信した SCHC Fragment が以前のフラグメント化された SCHC Packet 送信の残骸でないことを確保します。Inactivity Timer (非活動タイマー) の初期値は receiver での DTag 値の推奨ライフタイムです。SCHC Fragment がそのような残骸であると判断された場合, receiver はそれを黙って無視して破棄してもよい。

  • receiver はその RuleID と DTag 値のペアで新しい SCHC Packet を組み立てるプロセスを開始しなければならない。receiver はその RuleID と DTag 値のペアに対して Inactivity Timer を開始しなければならない。その RuleID と DTag 値のペアに対して Attempts counter (試行カウンタ) を 0 に初期化しなければならない。receiver がこれを行うためのリソースが不足している場合, SCHC Receiver-Abort (SCHC 受信機中止) で sender に応答しなければならない。

処理中の RuleID と DTag ペアに対する任意の SCHC F/R メッセージの受信時, receiver はその RuleID と DTag ペアに関連する Inactivity Timer をリセットしなければならない。

本セクションの残りで議論されるすべてのメッセージ受信は, 簡潔にするために詳しく説明されていなくても, "処理中の RuleID と DTag ペアに一致する" と理解されるべきである。

SCHC Fragment メッセージを受信すると, receiver はペイロード長と SCHC Fragment の W および FCN フィールドに基づいて, どの tiles が受信されたかを判断します。

  • FCN が All-1 でありペイロードが存在する場合, padding bits (パディングビット) を含む完全な SCHC Fragment Payload を組み立てなければならない。これは receiver が最後の tile のサイズを知らないためであり, したがってこの段階では padding bits と tile データビットは区別できません。それらは SCHC C/D サブレイヤによって削除されます。SCHC Fragment Payload のサイズが1つの通常の tile のサイズに L2 Word のサイズを加えたものを超えるか等しい場合, これはエラーフラグを発生させるべきです。

  • それ以外の場合, tiles は事前に既知の tile サイズに基づいて組み立てられなければならない。

    • Profile で許可されている場合, ペイロードの最後には最後の tile が含まれる可能性があり, それは短い可能性があります。この段階では padding bits と tile データビットは区別できません。

    • ペイロードには, Profile で許可されている場合, 通常の tile サイズよりも正確に1つの L2 Word 小さい最後から2番目の tile が含まれる可能性があります。

    • それ以外の場合, padding bits は破棄されなければならない。これが可能なのは次の理由によります:

      • tiles のサイズは事前に既知であり,

      • tiles は L2 Word よりも大きく, また

      • padding bits は常に L2 Word より厳密に小さい。

SCHC All-0 SCHC Fragment を受信したとき:

  • receiver が再構成中のパケットに対して tiles が欠落している windows を知っている場合 (および, ネットワーク条件, sender バッファ/キャッシュサイズ, およびサポートされるアプリケーション遅延などの特定のパラメータに応じて), 最も番号の小さい window から始めて, 欠落している tiles に対して SCHC Compound ACK を返してもよい。

SCHC ACK REQ または All-1 SCHC Fragment を受信したとき:

  • receiver が再構成中のパケットに対して tiles が欠落している windows を知っている場合, 最も番号の小さい window から始めて, 欠落している tiles に対して SCHC Compound ACK を返さなければならない。

  • それ以外の場合:

    • 少なくとも1つの tile を受信している場合, 現在 tiles を持っている最も番号の大きい window に対して SCHC Compound ACK を返さなければならない,

    • それ以外の場合, window number 0 に対して SCHC Compound ACK を返さなければならない。

Profile は receiver が SCHC Compound ACK を送信する他の時間と状況, およびこれらの状況で SCHC Compound ACK がどの window について報告するかを指定してもよい。

SCHC Compound ACK を送信する際, receiver は Attempts counter を増やさなければならない。

All-1 SCHC Fragment を受信した後, receiver は少なくとも最後の window に対して SCHC Compound ACK を送信する準備をするたびに, 再構成された SCHC Packet の完全性をチェックしなければならない。

SCHC Sender-Abort を受信すると, receiver はエラー条件で終了してもよい。

Inactivity Timer の有効期限が切れると, receiver は SCHC Receiver-Abort を送信しなければならず, エラー条件で終了してもよい。

Attempts counter が MAX_ACK_REQUESTS を超えると, receiver は SCHC Receiver-Abort を送信しなければならず, エラー条件で終了してもよい。

SCHC Packet の再構成は次の場合に終了します:

  • Sender-Abort が受信された,

  • Inactivity Timer が期限切れになった,

  • Attempts counter が MAX_ACK_REQUESTS を超えた, または

  • 少なくとも1つの All-1 SCHC Fragment が受信され, 再構成された SCHC Packet の完全性チェックが成功した。

この仕様に従う receiver 動作を実装する Finite State Machine (有限状態機械) のいくつかの可能な例の1つについては, RFC 8724 の図 44 を参照してください。提供される例は図 43 の sender Finite State Machine と一致するように意図されています。