JP2013168993A - フレキシブルｒｌｃｐｄｕサイズのためにｒｌｃを機能強化する方法および装置 - Google Patents

Abstract

【課題】可変ＲＬＣパケットデータユニットサイズが許容される無線通信システムにおける、無線リンク制御プロトコルの機能強化を提供する。
【解決手段】機能強化は、バイトカウントベースのメトリックを使用してＲＬＣ送信（Ｔｘ）ウィンドウサイズを更新する方法を採る。ウィンドウサイズ更新は、ＲＬＣの初期化およびセットアップに続いて、ＲＬＣ Ｔｘ動作を実行し（３０５）、ＰＤＵを除去してＴｘウィンドウの下端を増加させるのか否かを決定し（３１０）、増加させる場合、Ｔｘエンティティに関係する量を計算し（３１５）、ウィンドウ長との比較の結果（３２０）、必要に応じてウィンドウの上端を増加させる（３３０）。機能強化は、アップリンクおよびダウンリンク通信の両方に適用される。
【選択図】図３

Description

本発明は、無線通信に関する。より詳細には、無線インターフェースプロトコルおよびネットワークアーキテクチャに関する。

本明細書では、高速パケットアクセスエボリューション（ＨＳＰＡ＋：ｈｉｇｈ ｓｐｅｅｄ ｐａｃｋｅｔ ａｃｃｅｓｓ ｅｖｏｌｕｔｉｏｎ）とは、ユニバーサル移動体通信システム（ＵＭＴＳ：Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ）無線通信システムで使用される高速ダウンリンクパケットアクセス（ＨＳＤＰＡ）規格および高速アップリンクパケットアクセス（ＨＳＵＰＡ）規格に関する、第３世代パートナシッププロジェクト（３ＧＰＰ）無線アクセス技術の進化的機能強化のことを指す。ＨＳＰＡ＋の一部として提案された、ＨＳＤＰＡ（３ＧＰＰ ＵＭＴＳ規格リリース５）およびＨＳＵＰＡ（３ＧＰＰ ＵＭＴＳ規格リリース６）に対する改良のいくつかは、より高いデータレート、より高いシステム容量およびカバレージ、パケットサービスに対する機能強化されたサポート、短縮された待ち時間（latency）、低減されたオペレータコスト、ならびに３ＧＰＰレガシシステムとの下位互換性を含む。本明細書では、３ＧＰＰレガシシステムとは、一般に、リリース６およびそれ以前の既存の３ＧＰＰ規格のうちのいずれか１つまたは複数の規格のことを指す。これらの改良を達成するには、無線インターフェースプロトコルおよびネットワークアーキテクチャの両方の進化を必要とする。

以下のリストは、関連する略語を含む。

・ ３ＧＰＰ−第３世代パートナシッププロジェクト（Ｔｈｉｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）
・ ＡＭ−確認型モード（Ａｃｋｎｏｗｌｅｄｇｅｄ Ｍｏｄｅ）
・ ＡＭＤ−確認型モードデータ（Ａｃｋｎｏｗｌｅｄｇｅｄ Ｍｏｄｅ Ｄａｔａ）
・ ＡＲＱ−自動再送要求（Ａｕｔｏｍａｔｉｃ Ｒｅｐｅａｔ Ｒｅｑｕｅｓｔ）
・ ＣＮ−コアネットワーク（Ｃｏｒｅ Ｎｅｔｗｏｒｋ）
・ ＣＰ−制御プレーン（Ｃｏｎｔｒｏｌ Ｐｌａｎｅ）
・ ＣＳ−回線交換（Ｃｉｒｃｕｉｔ Ｓｗｉｔｃｈｅｄ）
・ ＤＬ−ダウンリンク（Ｄｏｗｎｌｉｎｋ）
・ ＨＡＲＱ−ハイブリッド自動再送要求（Ｈｙｂｒｉｄ Ａｕｔｏｍａｔｉｃ Ｒｅｐｅａｔ Ｒｅｑｕｅｓｔ）
・ ＨＳＤＰＡ−高速ダウンリンクパケットアクセス（Ｈｉｇｈ Ｓｐｅｅｄ Ｄｏｗｎｌｉｎｋ Ｐａｃｋｅｔ Ａｃｃｅｓｓ）
・ ＨＳＵＰＡ−高速アップリンクパケットアクセス（Ｈｉｇｈ Ｓｐｅｅｄ Ｕｐｌｉｎｋ Ｐａｃｋｅｔ Ａｃｃｅｓｓ）
・ ＩＰ−インターネットプロトコル（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）
・ ＬＣＩＤ−論理チャネル識別子（Ｌｏｇｉｃａｌ Ｃｈａｎｎｅｌ Ｉｄｅｎｔｉｆｉｅｒ）
・ ＬＴＥ−ロングタームエボリューション（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）
・ ＭＡＣ−媒体アクセス制御（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）
・ ＰＤＣＰ−パケットデータコンバージェンスプロトコル（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）
・ ＰＤＵ−パケットデータユニット（Ｐａｃｋｅｔ Ｄａｔａ Ｕｎｉｔ）
・ ＰＨＹ−物理（Ｐｈｙｓｉｃａｌ）
・ ＰＳ−パケット交換（Ｐａｃｋｅｔ Ｓｗｉｔｃｈｅｄ）
・ ＱｏＳ−サービス品質（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）
・ ＲＡＮ−無線アクセスネットワーク（Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）
・ ＲＬＣ−無線リンク制御（Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ）
・ ＲＮＣ−無線ネットワークコントローラ（Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌｌｅｒ）
・ ＣＲＮＣ−制御ＲＮＣ（Ｃｏｎｔｒｏｌｌｉｎｇ ＲＮＣ）
・ ＳＲＮＣ−サービスＲＮＣ（Ｓｅｒｖｉｎｇ ＲＮＣ）
・ ＲＮＳ−無線ネットワークサブシステム（Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｓｕｂｓｙｓｔｅｍ）
・ ＲｏＨＣ−ロバストヘッダ圧縮（Ｒｏｂｕｓｔ Ｈｅａｄｅｒ Ｃｏｍｐｒｅｓｓｉｏｎ）
・ ＲＲＣ−無線リソース制御（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）
・ ＲＲＭ−無線リソース管理（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｍａｎａｇｅｍｅｎｔ）
・ Ｒｘ−受信（Ｒｅｃｅｐｔｉｏｎ／Ｒｅｃｅｉｖｉｎｇ）
・ ＳＡＰ−サービスアクセスポイント（Ｓｅｒｖｉｃｅ Ａｃｃｅｓｓ Ｐｏｉｎｔ）
・ ＳＤＵ−サービスデータユニット（Ｓｅｒｖｉｃｅ Ｄａｔａ Ｕｎｉｔ）
・ ＳＮ−シーケンス番号（Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ）
・ ＴＢ−トランスポートブロック（Ｔｒａｎｓｐｏｒｔ Ｂｌｏｃｋ）
・ ＴＢＳ−トランスポートブロックセット（Ｔｒａｎｓｐｏｒｔ Ｂｌｏｃｋ Ｓｅｔ）
・ ＴＦ−トランスポートフォーマット（Ｔｒａｎｓｐｏｒｔ Ｆｏｒｍａｔ）
・ ＴＦＣ−トランスポートフォーマットコンビネーション（Ｔｒａｎｓｐｏｒｔ Ｆｏｒｍａｔ Ｃｏｍｂｉｎａｔｉｏｎ）
・ ＴＦＲＣ−トランスポートフォーマットリソースコンビネーション（Ｔｒａｎｓｐｏｒｔ Ｆｏｒｍａｔ Ｒｅｓｏｕｒｃｅ Ｃｏｍｂｉｎａｔｉｏｎ）
・ ＴＭ−透過モード（Ｔｒａｎｓｐａｒｅｎｔ Ｍｏｄｅ）
・ ＴＭ−透過モードデータ（Ｔｒａｎｓｐａｒｅｎｔ Ｍｏｄｅ Ｄａｔａ）
・ Ｔｘ−送信（Ｔｒａｎｓｍｉｓｓｉｏｎ／Ｔｒａｎｓｍｉｔｔｉｎｇ）
・ ＵＥ−ユーザ機器（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）
・ ＵＬ−アップリンク（Ｕｐｌｉｎｋ）
・ ＵＭ−非確認型モード（Ｕｎａｃｋｎｏｗｌｅｄｇｅｄ Ｍｏｄｅ）
・ ＵＭＤ−非確認型モードデータ（Ｕｎａｃｋｎｏｗｌｅｄｇｅｄ Ｍｏｄｅ Ｄａｔａ）
・ ＵＰ−ユーザプレーン（Ｕｓｅｒ Ｐｌａｎｅ）
・ ＵＭＴＳ−ユニバーサル移動体通信システム（Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ）
・ ＵＴＲＡＮ−ユニバーサル地上無線アクセスネットワーク（Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）
・ ＷＴＲＵ−無線送受信ユニット（Ｗｉｒｅｌｅｓｓ Ｔｒａｎｓｍｉｔ／Ｒｅｃｅｉｖｅ Ｕｎｉｔ）

レイヤ２無線インターフェースプロトコルは、媒体アクセス管理（ＭＡＣ）プロトコルおよび無線リンク制御（ＲＬＣ）プロトコルを含む。ＭＡＣプロトコルおよびＲＬＣプロトコルの機能のいくつかが、これ以降で説明されるが、説明されない他の機能も、３ＧＰＰ規格で説明されるように機能するものと仮定される。

ＭＡＣプロトコルの主要機能のいくつかとして、以下のものがある。
・ ＭＡＣパケットデータユニット（ＰＤＵ）の、物理チャネルへのチャネルマッピング。
・ 高位レイヤデータの、パケットデータユニット（ＰＤＵ）への多重化。
・ スケジューリングおよびレート制御のためのデータ優先順位を考慮するサービス品質（ＱｏＳ）。
・ ＱｏＳおよび多重化のためのリンクアダプテーション（ｌｉｎｋ ａｄａｐｔａｔｉｏｎ）。
・ 誤り訂正用の高速再送の制御のためのハイブリッド自動再送要求（ＨＡＲＱ）。

ＭＡＣレイヤは、高位レイヤデータをＭＡＣ ＰＤＵに多重化する。物理（ＰＨＹ）レイヤに送信されるＭＡＣ ＰＤＵは、トランスポートブロック（ＴＢ）と呼ばれる。１組のＴＢは、トランスポートブロックセット（ＴＢＳ）と呼ばれ、そのＴＢＳの物理レイヤアトリビュートを記述する対応するトランスポートフォーマット（ＴＦ）で、送信時間間隔（ＴＴＩ：ｔｒａｎｓｐｏｒｔ ｔｉｍｅ ｉｎｔｅｒｖａｌ）毎に、ＰＨＹレイヤに送信される。２つ以上の論理ＲＬＣチャネルのデータを合成または多重化することでＴＢＳが得られた場合、トランスポートフォーマットコンビネーション（ＴＦＣ）として知られるＴＦの組合せが使用される。リンクアダプテーションの一部として、ＭＡＣレイヤは、ＲＬＣ論理チャネル優先順位、ＲＬＣバッファ占有率、物理チャネル状態、および論理チャネル多重化に基づいて、ＴＦＣ選択を実行する。ここでのＭＡＣ ＴＦＣ選択への言及は、総称的なものであり、例えば、ＨＳＤＰＡの高速ＭＡＣ（ＭＡＣ−ｈｓ：ｈｉｇｈ ｓｐｅｅｄ ＭＡＣ）プロトコルにおけるトランスポートフォーマットリソースコンビネーション（ＴＦＲＣ）選択も含むことができる。

レイヤ２のＲＬＣプロトコルは、データの待ち時間（latency）およびスループットに大きな影響を有する。リリース６およびそれ以前のものを含む、３ＧＰＰレガシシステムにおけるＲＬＣプロトコルは、無線ネットワークコントローラ（ＲＮＣ）ノード内に物理的に配置される。

Ｔｘ ＲＬＣエンティティにおいて行われる送信（Ｔｘ）ＲＬＣプロトコルの主要機能のいくつかとして、以下のものがある。
・ ＵＥが２つ以上のセルに同時に接続され、データを受信することを可能にする、マクロダイバシティ（ｍａｃｒｏ−ｄｉｖｅｒｓｉｔｙ）。
・ 高位レイヤ無線ベアラ（ｒａｄｉｏ ｂｅａｒｅｒ）のセグメンテーション。
・ 高位レイヤ無線ベアラのコンカチネーション。
・ 受信した誤りのあるＰＤＵの誤り検出および回復。
・ 受信した誤りのあるＰＤＵの高速再送のためのＨＡＲＱアシストＡＲＱ（ＨＡＲＱ Ａｓｓｉｓｔｅｄ ＡＲＱ）。

Ｒｘ ＲＬＣエンティティにおいて行われる受信（Ｒｘ）ＲＬＣプロトコルの主要機能のいくつかとして、以下のものがある。
・ 重複ＰＤＵ検出。
・ 順序通りのＰＤＵ受け渡し（ＰＤＵ ｄｅｌｉｖｅｒｙ）。
・ 受信した誤りのあるＰＤＵの誤り検出および回復。
・ 受信した誤りのあるＰＤＵの高速再送のためのＨＡＲＱアシストＡＲＱ。
・ 受信したＰＤＵからの、高位レイヤデータの再構築。

ＲＬＣレイヤの３つの動作モードは、確認型モード（ＡＭ）、非確認型モード（ＵＭ）、および透過モード（ＴＭ）である。いくつかの高位レイヤユーザプレーンデータの送信を含むＡＭ動作では、ＲＬＣプロトコルは、ステータスおよび制御情報がＲｘ ＲＬＣエンティティからＴｘ ＲＬＣエンティティに送信されるように、双方向的である。いくつかの制御プレーン無線リソース制御（ＲＲＣ）信号データの送信を含むＴＭおよびＵＭ動作では、ＲＬＣプロトコルは、Ｔｘ ＲＬＣエンティティおよびＲｘ ＲＬＣエンティティがステータスおよび制御情報の交換を行わず独立であるように、単一方向的である。また、ＨＡＲＱアシストＡＲＱ、ならびに誤り検出および回復などの機能のいくつかは、一般に、ＡＭ動作においてのみ使用される。

ＲＬＣ ＰＤＵサイズは、ＲＬＣ論理チャネルによって搬送されるアプリケーションデータの長期サービス品質（ＱｏＳ）要件に基づいて、ＲＲＣレイヤによって決定される。リリース６およびそれ以前のものを含む、３ＧＰＰレガシシステムによれば、ＲＬＣレイヤは、ＲＲＣレイヤによって、所定のＲＬＣ ＰＤＵサイズで半静的（semi-static basis）に構成される。したがって、ＲＬＣ ＰＤＵサイズは、上位レイヤによって、半静的に固定されており、シーケンス番号（ＳＮ）が、ＲＬＣ ＰＤＵに割り当てられる。ＡＭデータのＲＬＣ ＰＤＵは、０から４０９５までの領域内で循環するモジュロ整数のシーケンス番号（ＳＮ）によって番号付けされる。

ＲＬＣ ＰＤＵタイプは、ＤＡＴＡ、ＣＯＮＴＲＯＬ、およびＳＴＡＴＵＳである。ＤＡＴＡ ＰＤＵは、ユーザデータ、ピギーバックされたＳＴＡＴＵＳ情報、およびＲＬＣがＡＭで動作している場合のポーリングビットを転送するために使用され、ポーリングビットは、受信機にステータスレポートを要求するために使用される。ＣＯＮＴＲＯＬ ＰＤＵは、ＲＬＣ ＲＥＳＥＴコマンドおよびＲＥＳＥＴ肯定応答（ＡＣＫ）コマンドのために使用される。ＳＴＡＴＵＳ ＰＤＵは、ＡＭで動作している２つのＲＬＣエンティティの間でステータス情報を交換するために使用され、例えば、ウィンドウサイズＳＵＦＩおよび受信ウィンドウ移動（ＭＲＷ：Ｍｏｖｅ Ｒｅｃｅｉｖｉｎｇ Ｗｉｎｄｏｗ）ＳＵＦＩを含む、異なるタイプのスーパフィールド（ＳＵＦＩ：ｓｕｐｅｒ−ｆｉｅｌｄ）を含むことができる。

送信ウィンドウとは、送信のために処理されている、または現在送信されているＰＤＵからなるグループのことを指す。同様に、受信ウィンドウとは、一般に、受信機で受信されている、または処理されているＰＤＵからなるグループのことを指す。送信ウィンドウサイズまたは受信ウィンドウサイズとは、一般に、それぞれシステムによって送信または受信されているＰＤＵの数のことを指す。送信ウィンドウサイズおよび受信ウィンドウサイズは、システムに過剰な負荷をかけて、望ましくないパケット喪失レートを招かないように、フロー制御を使用して管理される必要がある。一般的に言って、あるＰＤＵが受信機で正常に受信された後、新しいＰＤＵを送信ウィンドウおよび／または受信ウィンドウに追加することができる。

ＲＬＣ送信ウィンドウは、下側境界および上側境界からなる。下側境界は、送信した中で最低のＳＮを有するＰＤＵのＳＮからなり、上側境界は、送信した中で最高のＳＮを有するＰＤＵのＳＮからなる。ＲＬＣは、下側境界から上側境界までの送信ＰＤＵの最大数が最大ウィンドウサイズを超えないように、最大送信ウィンドウサイズを用いて構成される。ＲＬＣ受信ウィンドウも、同様に構成される。ＲＬＣ受信ウィンドウの下側境界は、順序通り並べた中で最後の受信ＰＤＵのＳＮに後続するＳＮであり、上側境界は、受信した中で最高のシーケンス番号を有するＰＤＵのＳＮである。受信ウィンドウも、最大ウィンドウサイズを有し、最大予想ＰＤＵ ＳＮは、下側境界ＳＮに最大構成ウィンドウサイズを加算したものに等しい。送信ウィンドウおよび受信ウィンドウは、これ以降で説明されるように、それぞれ送信状態変数および受信状態変数を使用して管理される。

フロー制御用の技法の中には、ＲＮＣ／Ｎｏｄｅ Ｂフロー制御、ＲＬＣフロー制御、およびＲＬＣステータスレポーティングがある。ＲＮＣ／Ｎｏｄｅ Ｂフロー制御とは、Ｎｏｄｅ Ｂ内でバッファされるダウンリンクデータを最小化する手順のことを指す。一般に、ＵＥを宛先とするデータは、コアネットワーク（ＣＮ）から、ソース無線ネットワークコントローラ（ＳＲＮＣ：ｓｏｕｒｃｅ ｒａｄｉｏ ｎｅｔｗｏｒｋ ｃｏｎｔｒｏｌｌｅｒ）およびＮｏｄｅ Ｂ、ならびに異なる無線ネットワークサブシステム（ＲＮＳ）を有するセルにＵＥがハンドオフされるドリフト状況におけるドリフト無線ネットワークコントローラ（ＤＲＮＣ：ｄｒｉｆｔ ｒａｄｉｏ ｎｅｔｗｏｒｋ ｃｏｎｔｒｏｌｌｅｒ）を介して流れる。Ｎｏｄｅ Ｂは、ＳＲＮＣおよびドリフト下におけるＤＲＮＣに、アロケーションクレジット（ａｌｌｏｃａｔｉｏｎ ｃｒｅｄｉｔ）を与えて、ＳＲＮＣが、それと同数のＰＤＵをＮｏｄｅ Ｂに送信できるようにするが、当該ＲＮＣは、より多くのクレジットが与えられるまで、より多くのＰＤＵを送信することはできない。ＲＬＣフロー制御とは、Ｔｘ ＲＬＣエンティティおよびＲｘ ＲＬＣエンティティの間での、ウィンドウサイズを含む、パケット転送の管理のことを指す。ＲＬＣステータスレポーティングは、送信機によってポーリングが行われたときに、受信機が送信機にステータス情報を報告できるようにする。

３ＧＰＰ規格によれば、以下のパラメータを含む、フロー制御用の様々なＲＬＣプロトコルパラメータが、上位レイヤによってＲＬＣレイヤに伝達される。
・ Ｐｏｌｌ＿Ｗｉｎｄｏｗ
・ Ｃｏｎｆｉｇｕｒｅｄ＿Ｔｘ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅ
・ Ｃｏｎｆｉｇｕｒｅｄ＿Ｒｘ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅ

これ以降でさらに詳細に説明されるこれらのパラメータは、送信ウィンドウサイズおよび受信ウィンドウサイズを設定するために、フロー制御用の様々なＲＬＣ状態変数とともに、ＲＬＣレイヤによって使用される。３ＧＰＰレガシシステムによれば、そのようなＲＬＣ状態変数は、ＳＮに依存する。例えば、以下のＲＬＣ送信機状態変数は、ＳＮによって影響される。
・ ＶＴ（Ｓ）は、初回に送信される次のＡＭデータＰＤＵのＳＮを含む送信状態変数である。
・ ＶＴ（Ａ）は、順序通り並べた中で最後の送達確認された（last in-sequence acknowledge）ＡＭＤ ＰＤＵのＳＮに後続するＳＮを含む送達確認状態変数であり、送信ウィンドウの下端を形成する。
・ ＶＴ（ＭＳ）は、相手側受信機（peer receiver）によって拒否され得る最初のＡＭデータＰＤＵのＳＮを含む最大送信状態変数である。
・ ＶＴ（ＷＳ）は、送信ウィンドウサイズ状態変数である。

ＶＴ（Ｓ）、ＶＴ（Ａ）、ＶＴ（ＭＳ）、ＶＲ（Ｒ）、ＶＲ（Ｈ）、およびＶＲ（ＭＲ）に関するすべての算術演算は、１つまたは複数のＳＮに依存する。以下のＲＬＣ受信機状態変数も、ＳＮによって影響される。
・ ＶＲ（Ｒ）は、順序通り並べた中で最後の受信ＡＭデータＰＤＵのＳＮに後続するＳＮを含む受信状態変数である。
・ ＶＲ（Ｈ）は、いずれかの受信ＡＭデータＰＤＵの最高ＳＮに後続するＳＮを含む最高予想状態変数である。
・ ＶＲ（ＭＲ）は、受信機によって拒否される最初のＡＭデータＰＤＵのＳＮを含む最大許容可能受信状態変数である。

3GPP TS 25.322 V．7.2.0 3GPP TS 25.322 V．7.1.0 Section 9.6 3GPP TS 25.322 V．7.1.0 subclause 11.3.2 3GPP TS 25.322 V．7.1.0 subclause 3GPP TS 25.322 V．7.1.0 subclause 11.3.2.1 3GPP TS 25.322 V．7.1.0 subclause 9.4 3GPP TS 25.322 V．7.1.0 subclause 9.5 3GPP TS 25.322 V．7.1.0 subclause 9.7.3

３ＧＰＰレガシシステムでは、ＲＮＣ／Ｎｏｄｅ Ｂフロー制御、ＲＬＣフロー制御およびＲＬＣステータスレポーティングなどの、データ転送サービスをサポートするために必要とされる多くの機能が、ＳＮに基づいており、またはＲＬＣ ＰＤＵサイズが固定である場合はＰＤＵの数に事実上基づいている。その理由は、ＰＤＵの数および既知で固定のＰＤＵサイズを使用して、送信ウィンドウサイズおよび受信ウィンドウサイズを正確に特徴付けることができることにある。しかしながら、ＨＳＰＡ＋のための提案では、ＲＬＣは、フレキシブルＲＬＣ ＰＤＵサイズを可能にするために、上位レイヤによって構成することができる。ＲＲＣレイヤなどの上位レイヤが、フレキシブルＲＬＣ ＰＤＵサイズ動作を構成する場合、ＲＬＣ ＰＤＵサイズは、半静的に指定された最大ＲＬＣ ＰＤＵペイロードサイズまで変化させることができる。

既存のＳＮベースＲＬＣ動作は、フレキシブルＲＬＣ ＰＤＵサイズを用いた場合、効率的に機能し得ないことが、本明細書において認識される。その理由は、ＰＤＵの数を使用してウィンドウサイズを定めると、可変ウィンドウサイズが得られるが、それが、ＲＮＣにおけるバッファオーバフローおよびＮｏｄｅ Ｂにおけるバッファアンダフローを引き起こす可能性があることにある。したがって、フレキシブルＲＬＣ ＰＤＵサイズ動作の場合にウィンドウサイズを設定するための代替的な方法を提供することは有益である。

可変ＲＬＣパケットデータユニット（ＰＤＵ）サイズが許容される、高速パケットアクセスエボリューション（ＨＳＰＡ＋）、およびロングタームエボリューション（ＬＴＥ）システムなどの他の無線システムのための、無線リンク制御（ＲＬＣ）プロトコルの機能強化が開示される。ＲＬＣ ＰＤＵサイズが固定されない場合、無線ネットワークコントローラ（ＲＮＣ）／Ｎｏｄｅ Ｂフロー制御、ＲＬＣフロー制御、ステータスレポーティング、およびポーリングメカニズムは、シーケンス番号（ＳＮ）、またはＰＤＵの数にもっぱら依存するのではなく、バイトカウント（ｂｙｔｅ ｃｏｕｎｔ）ベースの方法も使用するように構成される。ＲＬＣのために提案されるバイトカウントベースの方法は、アップリンク通信およびダウンリンク通信の両方に適用される。

より詳細な理解は、例として与えられ、添付の図面と併せて理解される以下の説明から得ることができるだろう。

本発明により、効率的な、フレキシブルＲＬＣ ＰＤＵサイズ動作の場合にウィンドウサイズを設定するための代替的な方法を提供する。

ＲＬＣ ＳＴＡＴＵＳパケットデータユニット（ＰＤＵ）内のスーパフィールド（ＳＵＦＩ）の構造を示す図である。 本発明による、バイトベースのクレジットアロケーションを使用するＲＮＣ／Ｎｏｄｅ Ｂフロー制御のフロー図である。 本発明による、ＲＬＣ送信（Ｔｘ）ウィンドウ更新のフロー図である。 本発明による、ＲＬＣ受信（Ｒｘ）ウィンドウ更新のフロー図である。 本発明による、機能強化オクテットベースのＲＬＣ ＰＤＵ生成のフロー図である。

これ以降で言及される場合、「無線送受信ユニット（ＷＴＲＵ）」という用語は、ユーザ機器（ＵＥ）、移動局、固定もしくは移動加入者ユニット、ページャ、セルラ電話、携帯情報端末（ＰＤＡ）、コンピュータまたは無線環境で動作可能な他の任意のタイプのユーザデバイスを含むが、それらに限定されない。これ以降で言及される場合、「基地局」という用語は、Ｎｏｄｅ Ｂ、サイトコントローラ、アクセスポイント（ＡＰ）または無線環境で動作可能な他の任意のタイプのインターフェースデバイスを含むが、それらに限定されない。

本明細書では、フレキシブルＲＬＣパケットデータユニット（ＰＤＵ）サイズのために、無線ネットワークコントローラ（ＲＮＣ）／Ｎｏｄｅ Ｂフロー制御、無線リンク制御（ＲＬＣ）フロー制御、ＲＬＣステータスレポーティング、およびポーリングメカニズムを機能強化するためのバイトカウントベースの方法が提供される。提案される機能強化は、ＲＬＣ ＰＤＵサイズがフレキシブルである場合に、ＲＬＣ機能の効率的動作を可能にし、固定ＲＬＣ ＰＤＵサイズ用に設計されたシーケンス番号（ＳＮ）に基づいて、レガシＲＬＣ機能を改善する。提案されるＲＬＣ機能強化は、アップリンク（ＵＥからユニバーサル地上無線アクセスネットワーク（ＵＴＲＡＮ））通信およびダウンリンク（ＵＴＲＡＮからＵＥ）通信の両方に適用され、高速パケットアクセスエボリューション（ＨＳＰＡ＋）システム、ロングタームエボリューション（ＬＴＥ）システム、広帯域符号分割多元接続（ＷＣＤＭＡ）（登録商標）システムを含むが、それらに限定されない、任意の無線通信システムにおいて使用することができる。ＬＴＥなどの無線システムの場合、ＵＴＲＡＮは、進化型ＵＴＲＡＮ（Ｅ−ＵＴＲＡＮ）に相当する。

提案されるＲＬＣ機能強化は、ＲＬＣが完全にＮｏｄｅ Ｂで動作するアーキテクチャにおいて、または、一部はＲＮＣで一部はＮｏｄｅ Ｂで動作するアーキテクチャにおいて使用することができる。提案されるＲＬＣ機能強化は、本明細書では、主としてＨＳＰＡ＋を参照して説明される。多くの機能およびパラメータは、ＨＳＤＰＡおよびＨＳＵＰＡ用の機能およびパラメータに基づいており、本明細書に組み込まれる３ＧＰＰ ＲＬＣプロトコル仕様書リリース７（非特許文献１を参照）を含む３ＧＰＰ技術仕様書（ＴＳ）と併せて理解することができる。ＲＬＣは、指定された最大ＲＬＣ ＰＤＵペイロードサイズを有するフレキシブルＰＤＵサイズをサポートするために、高位レイヤによって構成できることが仮定される。最大ＲＬＣ ＰＤＵサイズは、指定された最大ＲＬＣ ＰＤＵペイロードサイズから推測できることも仮定される。代替として、最大ＲＬＣ ＰＤＵサイズは、直接指定することもできる。また、バイトという用語とオクテットという用語は、交換可能に使用され、送信機（ｔｒａｎｓｍｉｔｔｅｒ）という用語とセンダ（ｓｅｎｄｅｒ）という用語も同様である。

以下のメトリックの１つまたは複数は、フレキシブルＲＬＣ ＰＤＵサイズがＲＲＣによって設定される場合、ウィンドウサイズを定義および管理するために、単独でまたは組み合わせて使用することができる。
・ バイトの数。
・ ブロックの数。各ブロックは一定の数のバイトである。
・ ＰＤＵまたはシーケンス番号（ＳＮ）の数。

ウィンドウ定義用に使用されるメトリックは、無線ベアラのためのＲＲＣセットアップ手順、構成手順、および再構成手順の最中に伝達され、ネゴシエートされる。これ以前に列挙されたウィンドウサイズ用のメトリックは、接続中にフロー制御用のウィンドウを更新するすべてのメッセージングに適用することができる。例えば、ウィンドウサイズメトリックは、ＲＬＣ ＣＯＮＴＲＯＬまたはＳＴＡＴＵＳ ＰＤＵ内のウィンドウサイズスーパフィールド（ＳＵＦＩ）および受信ウィンドウ移動（ＭＲＷ）ＳＵＦＩに含まれることができる。

無線ベアラ情報要素（ＲＬＣ情報）を用いてＲＬＣのＲＲＣ構成および再構成においてフレキシブルＲＬＣ ＰＤＵサイズをサポートする、確認型モード（ＡＭ）ＲＬＣの場合、フレキシブルＲＬＣ ＰＤＵサイズの使用を通知するために、以下の情報のいずれか１つまたは複数をＲＲＣによってＲＬＣに提供することができる。
・ ＣＨＯＩＣＥダウンリンクＲＬＣモード情報は、他のＲＬＣモードに加えて、フレキシブルＲＬＣ ＰＤＵサイズモード用の新しいインジケータを含む。フレキシブルＲＬＣ ＰＤＵサイズモードが通知された場合、ＲＬＣエンティティは、このモードに従って、他のＲＬＣプロトコルパラメータを解釈することができる。
・ ＲＬＣ情報の一部としての他の任意の新しい情報要素も、フレキシブルＲＬＣ ＰＤＵサイズモードを通知するために使用することができる。
・ ビット単位のダウンリンク（ＤＬ）ＲＬＣ ＰＤＵサイズ情報は、再使用することができ、フレキシブルＲＬＣ ＰＤＵサイズモードの文脈において、以下のように解釈することができる。
・ これ以降で説明されるようにＰＤＵの数で指定される他のプロトコルパラメータを特に拡大（ｓｃａｌｅ）または乗算するために送信される、（ビット数を８で除算した後の）オクテット単位のＲＬＣスケールパラメータであって、受信（Ｒｘ）ＲＬＣエンティティおよび送信（Ｔｘ）ＲＬＣエンティティにおいて同じ値を有するＲＬＣスケールパラメータとして、または
・ フレキシブルＲＬＣ ＰＤＵサイズモードにおける最大ＲＬＣ ＰＤＵサイズであって、次にさらに、上述されたＲＬＣスケールパラメータとして使用することができる最大ＲＬＣ ＰＤＵサイズの指定として。
・ Ｐｏｌｌ＿ＰＤＵ、Ｐｏｌｌ＿ＳＤＵ、Ｃｏｎｆｉｇｕｒｅｄ＿Ｔｘ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅ、およびＣｏｎｆｉｇｕｒｅｄ＿Ｒｘ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅ（非特許文献２を参照）含むが、それらに限定されない、ＲＲＣなどの上位レイヤによってＲＬＣに通知されるプロトコルパラメータは、以下の２つの方法で、指定および解釈することができる。
・ ＰＤＵの数、またはＰｏｌｌ＿ＳＤＵの場合はサービスデータユニット（ＳＤＵ）の数での指定および解釈。その整数値から、ＲＬＣは数学計算を実行することによってオクテット単位のウィンドウサイズを導き出すことができる。例えば、指定された数のＰＤＵ（またはＰｏｌｌ＿ＳＤＵの場合はＳＤＵ）は、上位レイヤによって指定されたオクテット単位のＲＬＣスケールパラメータで乗算することができる。
・ バイト単位での指定および解釈。このオプションでは、プロトコルパラメータをバイト単位で保持するように新しいフィールドを定義することができる。

ＲＬＣ ＳＴＡＴＵＳ ＰＤＵでは、送信機のウィンドウサイズを設定するために受信機によって使用されるウィンドウサイズスーパフィールド（ＳＵＦＩ）は、オクテット量を提供するように構成される。この機能強化は、上述されたようにフレキシブルＲＬＣ ＰＤＵサイズモードがＲＲＣによって設定された場合に使用され、２つの方法で指定することができる。
・ ＰＤＵの数での指定、その数から、ＲＬＣは数学計算を実行することによってオクテット単位の等価量を導き出す。例えば、指定された数のＰＤＵは、上位レイヤによって指定された上述のオクテット単位のＲＬＣスケールパラメータで乗算することができる。
・ タイプ、長さ、および値成分を有する新しいＳＵＦＩとしてバイト単位での指定。例えば、表１に示されるビット１０００などの長さが４ビットの現在未使用または予約タイプのフィールドは、表１および図１に示されるような、バイト数、ＷＩＮＤＯＷ＿ＢＹＴＥＳ ＳＵＦＩを指定するための新しいＳＵＦＩタイプを導入するために使用することができ、ＳＵＦＩ長さ成分は、可能な限りで最大のウィンドウサイズＳＵＦＩ値をバイト単位で保持するのに十分な大きさに定義される。

ＲＮＣ／Ｎｏｄｅ Ｂフロー制御
本明細書では、ＲＮＣ／Ｎｏｄｅ Ｂフロー制御の機能強化が、ＲＬＣエンティティがＲＮＣ内に保持される場合について説明される。しかし、同様の機能強化は、ＲＬＣエンティティがＲＮＣおよびＮｏｄｅ Ｂ内に存在する場合にも定義することができる。ＲＮＣおよびＮｏｄｅ Ｂの間の共通トランスポートチャネルデータストリーム用のＵＴＲＡＮ Ｉｕｒインターフェースユーザプレーンプロトコルに関する３ＧＰＰ ＴＳ ２５．４２５、および２つのＲＮＣの間の共通トランスポートチャネルデータストリーム用のＵＴＲＡＮ Ｉｕｂインターフェースユーザプレーンプロトコルに関する３ＧＰＰ ＴＳ ２４．４３５などの、既存の３ＧＰＰ規格によれば、データＭＡＣ（ＭＡＣ−ｄ）エンティティは、ＲＬＣ ＰＤＵを受信し、適切なヘッダ情報を付加した後に、それらをＮｏｄｅ Ｂ内の高速ＭＡＣ（ＭＡＣ−ｈｓ）エンティティに転送するために、ＲＮＣ内に保持することができる。３ＧＰＰレガシシステムでは、Ｎｏｄｅ Ｂは、容量アロケーションフレームを、サービスＲＮＣ（ＳＲＮＣ）と、場合によっては制御ＲＮＣ（ＣＲＮＣ）とに送信し、最大ＰＤＵサイズと、送信できるＰＤＵの数とを通知する。加えて、アロケーションが一定の数の期間毎または不定の期間毎に周期的に行われるように、パラメータを送信することもできる。

ＲＮＣからＮｏｄｅ Ｂに送信されるＭＡＣ ＰＤＵの数、および対応する送信時間間隔は、クレジットアロケーションスキームに基づいたフロー制御アルゴリズムによって規制される。クレジットは、送信できるＭＡＣ−ｄ ＰＤＵの数を表す。ＲＮＣは、クレジットを要求し、Ｎｏｄｅ Ｂは、指定された送信時間間隔とともにクレジットを与える。

ＲＬＣ ＰＤＵサイズが可変である場合、その結果、ＭＡＣ−ｄ ＰＤＵサイズも可変である。したがって、ＭＡＣ−ｄ ＰＤＵの数に関して、クレジットの数を指定するのでは不十分である。ＭＡＣ−ｄ ＰＤＵサイズが可変である場合に、ＲＮＣ／Ｎｏｄｅ Ｂフロー制御を実行するための可能な手法が複数存在する。１つの可能性は、ＲＮＣ／Ｎｏｄｅ Ｂフロー制御を排除することであるが、しかし、これは、ネットワークのためのフロー制御を行い、加えて、ＴＣＰウィンドウとＲＬＣウィンドウの間の相互作用を処理するために、トランスポート制御プロトコル（ＴＣＰ）などのユーザデータプロトコルに依存することが必要になる。

代替として、クレジットアロケーションは、ＰＤＵの数の代わりに、バイト単位で指定することができ、これは、２つの方法で行うことができる。ＰＤＵの数の代わりに、クレジットのバイト数を指定するために、既存のフレームに新しいフィールドを追加することができる。代替として、無線ベアラセットアップまたは再構成時に、または既存の制御フレームもしくは新しい制御フレームを使用する各利用可能な制御フレームで、表示を通知することができ、それは、アロケーションが実際には、クレジットにバイト単位の最大ＰＤＵサイズを乗算して、バイト合計を導き出すことによる、バイトアロケーションであることを通知する。したがって、ＲＮＣからＮｏｄｅ Ｂに転送できるＰＤＵの最大数は、ＰＤＵの数に関して通知されたクレジットに等しくないが、ＰＤＵ内のバイトの総数によって制限される。バイトベースの手法を使用して、ＲＮＣは、任意選択で、ＰＤＵ ＳＮからバイト単位のその長さへのマッピングを維持することができる。ＲＮＣがＮｏｄｅ Ｂからクレジットアロケーションを受信すると、新しいバイト長ベースのクレジットアロケーションによって指定されたバイト長制約に違反することなく、できるだけ多くのＰＤＵを送信することが可能になる。

図２は、バイトベースのクレジットアロケーションを使用するＲＮＣ／Ｎｏｄｅ Ｂフロー制御のフロー図を示している。Ｎｏｄｅ Ｂが、バイト単位のクレジットアロケーションを通知する（ステップ２０５）。ＲＮＣが、バイト単位のクレジットアロケーションを受信する（ステップ２１０）。ＲＮＣは、ＰＤＵ ＳＮからバイト単位のＰＤＵ長へのマッピングを維持し（ステップ２２０）、受信したクレジットアロケーションを超過しないＰＤＵを送信する（ステップ２２０）。

ＲＬＣフロー制御
ＲＬＣフロー制御は、利用送信（Ｔｘ）ウィンドウの下端のＰＤＵが送達を肯定的に確認され、したがって、正しく受信された場合に、最大ウィンドウサイズによって課された限界内にまだ留まっているならば、ＲＬＣ Ｔｘウィンドウを進めることによって達成される。Ｔｘウィンドウの下端のＰＤＵは、順序通り並べた中で最後の送達確認されたＰＤＵに後続するＰＤＵとして定義される。フレキシブルＲＬＣ ＰＤＵサイズが設定される場合、最大ウィンドウサイズ限界が違反されないように、適切なステップがとられるべきである。Ｔｘウィンドウサイズは、バイト単位で指定される。

図３は、ＲＬＣ送信（Ｔｘ）ウィンドウを更新するための方法３００のフロー図である。ＲＬＣの初期化およびセットアップに続いて、ＲＬＣ Ｔｘ動作が実行される（ステップ３０５）。ＲＬＣ Ｔｘ動作は、例えば、ＲＬＣ受信機からのステータスおよび制御情報の受信とすることができる。ＲＬＣ Ｔｘエンティティは、利用Ｔｘウィンドウから１つまたは複数のＰＤＵを除去し、利用Ｔｘウィンドウの下端を増加させるかどうかを決定する（ステップ３１０）。以下の場合に、１つまたは複数のＰＤＵを除去することができる。
・ ＰＤＵが受信機によって肯定的に送達確認された場合、または
・ ＰＤＵが受信機によって否定的に送達確認されたが、受信機が送信機の最大再送回数を超過したといった他の理由から、ＲＬＣ送信機がこのＰＤＵを廃棄すると決定した場合、または
・ 送信機におけるタイマベースの廃棄の結果として。

説明を容易にするため、ＲＬＣ Ｔｘエンティティに関係するある量について、以下の表記が使用される。
・ ＴｘＷＭＡＸ：最大ウィンドウサイズのバイト単位の長さ。
・ ＴｘＷＵＴＩＬ：利用Ｔｘウィンドウのバイト単位の長さ、または代替として、状態変数Ｖ（Ａ）およびＶ（Ｔ）によって境界が画定されるウィンドウ内の送達確認されたパケットのバイト単位の長さ。
・ ＴｘＬ：ＲＬＣ ＳＤＵ廃棄手順または１つまたは複数の肯定応答の受信のために廃棄される１つまたは複数のＰＤＵのバイト単位の長さ。
・ ＴｘＮ：初回に送信される次の１つまたは複数のＰＤＵのバイト単位の長さ。

ＲＬＣ Ｔｘエンティティは、以下のウィンドウ長（ＷＬ）量を計算する（ステップ３１５）。

ＷＬ＝ＴｘＷＵＴＩＬ−ＴｘＬ＋ＴｘＮ 式（１）
ＲＬＣ Ｔｘエンティティは、ＷＬ量が最大ウィンドウサイズＴｘＷＭＡＸより小さいかどうかを判定する（ステップ３２０）。ＷＬがＴｘＷＭＡＸより小さくない場合、次の１つまたは複数のＰＤＵは送信されず、ウィンドウの上端は増加されない（ステップ３２５）。ＷＬがＴｘＷＭＡＸより小さい場合、次の１つまたは複数のＰＤＵが送信され、ウィンドウの上端が増加される（ステップ３３０）。

フレキシブルＲＬＣ ＰＤＵサイズが設定される場合、最大ウィンドウサイズ限界が違反されないことを保証するために、同様のＲＬＣフロー制御法が、ＲＬＣ Ｒｘエンティティにおいて適用される。Ｒｘウィンドウサイズは、バイト単位で指定される。図４は、本明細書の教示による、ＲＬＣ受信（Ｒｘ）ウィンドウを更新するための方法４００のフロー図を示している。ＲＬＣの初期化およびセットアップの後、ＲＬＣ Ｒｘ動作が実行される（ステップ４０５）。ＲＬＣ Ｒｘ動作は、例えば、新しいＰＤＵの受信とすることができる。ＲＬＣ Ｒｘエンティティは、Ｒｘウィンドウの下端を増加させるかどうかを決定する（ステップ４１０）。ＲＬＣ Ｒｘエンティティは、以下の場合に、そのＲｘウィンドウの下端を増加させ、それによってＲｘＷＵＴＩＬを小さくすることができる。
・ 順序通り並べた中で最後の受信ＰＤＵのＳＮに後続するＳＮを有するＰＤＵを受信した場合、または
・ ＲＬＣ Ｔｘエンティティから受信ウィンドウ移動（ＭＲＷ）を受信した場合。

説明を容易にするため、ＲＬＣ Ｒｘエンティティに関係するある量について、以下の表記が使用される。
・ ＲｘＷＭＡＸ：最大ウィンドウサイズのバイト単位の長さ。
・ ＲｘＷＵＴＩＬ：利用Ｒｘウィンドウのバイト単位の長さ。
・ ＲｘＤ：順序通りの受信のために受信ウィンドウから除去される１つまたは複数のＰＤＵのバイト単位の長さ。
・ ＲｘＮ：初回に受信される次の１つまたは複数のＰＤＵのバイト単位の長さ。

ＲＬＣ Ｒｘエンティティは、以下のウィンドウ長（ＷＬ）量を計算する（ステップ４１５）。
ＷＬ＝ＲｘＷＵＴＩＬ＋ＲｘＮ−ＲｘＤ 式（２）

ＲＬＣ Ｒｘエンティティは、ＷＬ量が最大ウィンドウサイズＲｘＷＭＡＸより小さいかどうかを判定する（ステップ４２０）。ＷＬがＲｘＷＭＡＸより小さくない場合、次のＰＤＵは受信されず、Ｒｘウィンドウの上端は増加されない（ステップ４２５）。ＷＬがＲｘＷＭＡＸより小さい場合、最高の受信ＳＮに後続するＳＮを有するＰＤＵを廃棄することなく、次のＰＤＵが受信され、Ｒｘウィンドウの上端が増加される（ステップ４３０）。

オクテットベースの方法を使用する、ＲＬＣ送信機および受信機の状態変数の設定が、これ以降で説明される。フレキシブルＲＬＣ ＰＤＵサイズモードがＲＲＣレイヤによって設定され、ＲＬＣがＡＭで動作する場合、ＡＭデータＲＬＣ ＰＤＵは、領域内で循環するモジュロ整数のシーケンス番号（ＳＮ）によって番号付けされる。一般に、この領域は、範囲が０から４０９５までであるが、ＲＲＣまたは他の上位レイヤによって、異なる最大値が設定されてもよい。ＶＴ（Ｓ）、ＶＴ（Ａ）、ＶＴ（ＭＳ）、ＶＲ（Ｒ）、ＶＲ（Ｈ）、およびＶＲ（ＭＲ）に関する算術演算は、法演算を施したＳＮ（ＳＮ ｍｏｄｕｌｕｓ）によって影響されることを思い出されたい。

オクテット単位のパラメータまたは状態変数Ｍａｘｉｍｕｍ＿Ｔｘ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅは、ＲＬＣ送信機によって維持することができる。このパラメータは、最初、上位レイヤによって送信されたオクテット単位のプロトコルパラメータＣｏｎｆｉｇｕｒｅｄ＿Ｔｘ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅに等しく設定され、後で、ＲＬＣ ＳＴＡＴＵＳ ＰＤＵ内のウィンドウサイズＳＵＦＩによって示されるオクテット量に更新することができる。状態変数ＶＴ（ＷＳ）は、オクテット単位のＭａｘｉｍｕｍ＿Ｔｘ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅから導き出すことができ、ＶＴ（Ａ）およびＶＴ（Ａ）＋ＶＴ（ＷＳ）によって境界が画定されるウィンドウのオクテット長が、オクテット単位のＭａｘｉｍｕｍ＿Ｔｘ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅを超過しないように、４０９５（またはＲＲＣ／上位レイヤによって設定された最大値）以下の最大の非負整数に等しく設定することができる。状態変数ＶＴ（ＷＳ）は、オクテット単位のＭａｘｉｍｕｍ＿Ｔｘ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅが更新されたときに、更新される。代替として、状態変数ＶＴ（ＷＳ）は、ＶＴ（Ａ）およびＶＴ（Ａ）＋ＶＴ（ＷＳ）によって境界が画定されるウィンドウのオクテット長が、
・ オクテット単位のプロトコルパラメータＣｏｎｆｉｇｕｒｅｄ＿Ｔｘ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅ、および
・ 上で定義されたようなＲＬＣ ＳＴＡＴＵＳ ＰＤＵ内のオクテット量を指示するウィンドウサイズＳＵＦＩ
を超過しないように、４０９５（またはＲＲＣ／上位レイヤによって設定された最大値）以下の最大の非負整数として導き出すことができる。

状態変数ＶＴ（ＭＳ）は、ＶＴ（ＭＳ）＝ＶＴ（Ａ）＋ＶＴ（ＷＳ）として計算されるＳＮであり、ＶＴ（ＷＳ）は、上述されたように導き出される。状態変数ＶＲ（ＭＲ）は、ＶＲ（Ｒ）およびＶＲ（ＭＲ）によって境界が画定されるウィンドウのオクテット単位の長さが、オクテット単位のＣｏｎｆｉｇｕｒｅｄ＿Ｒｘ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅを超過せずに可能な限り大きくなるように、上位レイヤから送信されたオクテット単位のＣｏｎｆｉｇｕｒｅｄ＿Ｒｘ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅから導き出されるＳＮである。

ＲＬＣ ＰＤＵ生成の機能強化
図５は、以下のパラメータに基づいた、アップリンクおよびダウンリンクの両方に関する、機能強化されたオクテットベースのＲＬＣ ＰＤＵ生成のための方法５００のフロー図を示している。
・ Ｃｕｒｒｅｎｔ＿Ｃｒｅｄｉｔ：アップリンクでは、これは、ＭＡＣリンクアダプテーションに基づいて送信でき、ＭＡＣによってＵＥ内のＲＬＣ、またはロングタームエボリューション（ＬＴＥ）システムおよびリリース８広帯域符号分割多元接続（ＷＣＤＭＡ）システムなどのフラットアーキテクチャシステムにおけるＮｏｄｅ Ｂ内のＲＬＣに送信される、データの量である。ダウンリンクでは、これは、残りのクレジットアロケーションに、Ｎｏｄｅ ＢからＲＮＣに送信された新しいクレジットアロケーションを加算した結果である。この量は、オクテット単位で表される。
・ Ａｖａｉｌａｂｌｅ＿Ｄａｔａ：これは、ＲＬＣエンティティにおいて送信される利用可能なデータである。この量は、オクテット単位で表される。
・ Ｌｅｆｔｏｖｅｒ＿Ｗｉｎｄｏｗ：これは、ＲＬＣ送信機においてＶＴ（Ｓ）およびＶＴ（ＭＳ）によって境界が画定されるウィンドウの長さである。この量は、オクテット単位で表される。
・ Ｍａｘｉｍｕｍ＿ＲＬＣ＿ＰＤＵ＿ｓｉｚｅ：これは、上位レイヤ、例えば、ＲＲＣレイヤによって設定される最大ＲＬＣ ＰＤＵサイズである。
・ Ｍｉｎｉｍｕｍ＿ＲＬＣ＿ＰＤＵ＿ｓｉｚｅ：これは、上位レイヤ、例えば、ＲＲＣレイヤによって設定されるパラメータであり、最小ＲＬＣ ＰＤＵサイズを指定する。代替として、上位レイヤは、Ｍｉｎｉｍｕｍ＿ＲＬＣ＿ＰＤＵ＿ｓｉｚｅをそれから推測できる、最小ＲＬＣ ＰＤＵペイロードサイズを指定することもできる。

ＲＬＣ ＰＤＵ生成の開始時に、各送信時間間隔（ＴＴＩ）において、以下の量が計算される（ステップ５０５）。
Ｘ＝Ｍｉｎ｛Ｃｕｒｒｅｎｔ＿Ｃｒｅｄｉｔ，Ａｖａｉｌａｂｌｅ＿Ｄａｔａ，Ｌｅｆｔｏｖｅｒ＿Ｗｉｎｄｏｗ｝ 式（３）
Ｎ＝Ｆｌｏｏｒ｛Ｘ／Ｍａｘｉｍｕｍ＿ＲＬＣ＿ＰＤＵ＿ｓｉｚｅ｝ 式（４）
Ｌ＝Ｘ ｍｏｄ Ｍａｘｉｍｕｍ＿ＲＬＣ＿ＰＤＵ＿ｓｉｚｅ 式（５）
ここで、関数Ｍｉｎ｛・｝は、集合内から最小値を返し、関数Ｆｌｏｏｒ｛・｝は、より小さい最も近い整数値を返し、ａ ｍｏｄ ｂは、ａをｂで除算した剰余である。サイズがＭａｘｉｍｕｍ＿ＲＬＣ＿ＰＤＵ＿ｓｉｚｅのＲＬＣ ＰＤＵがＮ個生成される（ステップ５０５）。任意選択で、Ｌがゼロと異なる場合、ＴＴＩの間に、追加ＲＬＣ ＰＤＵを１つ生成することができる。ＸがＬｅｆｔｏｖｅｒ＿ＷｉｎｄｏｗまたはＣｕｒｒｅｎｔ＿Ｃｒｅｄｉｔパラメータに等しいかどうかが判定される（ステップ５１０）。等しい場合、ＬがＭｉｎｉｍｕｍ＿ＲＬＣ＿ＰＤＵ＿ｓｉｚｅパラメータより大きいかどうか、またはＸがＡｖａｉｌａｂｌｅ＿Ｄａｔａに等しいかどうかが判定される（５１５）。ＬがＭｉｎｉｍｕｍ＿ＲＬＣ＿ＰＤＵ＿ｓｉｚｅより大きい場合、またはＸがＡｖａｉｌａｂｌｅ＿Ｄａｔａに等しい場合、長さＬのＲＬＣ ＰＤＵが生成される（５２０）。また、ＸがＬｅｆｔｏｖｅｒ＿ＷｉｎｄｏｗおよびＣｕｒｒｅｎｔ＿Ｃｒｅｄｉｔのどちらとも等しくない場合、長さＬのＲＬＣ ＰＤＵが生成される（５２０）。任意選択で、ＬがＭｉｎｉｍｕｍ＿ＲＬＣ＿ＰＤＵ＿ｓｉｚｅより小さい場合、Ｍｉｎｉｍｕｍ＿ＲＬＣ＿ＰＤＵ＿ｓｉｚｅのＲＬＣ ＰＤＵを生成することもできる。生成されたＲＬＣ ＰＤＵは、送信のためにバッファに保存される（５２５）。方法５００は、すべてのＴＴＩ毎に、または代替として、データが利用可能な場合もしくは下位レイヤによって要求された場合に、繰り返すことができる（５３０）。

これ以前で説明された方法５００の結果として、典型的にはＴＴＩまたは他の何らかのシステム指定された期間である当該期間内に生成された、最大ＲＬＣ ＰＤＵサイズに等しい長さのＰＤＵの数は、Ｍｉｎ｛Ｃｕｒｒｅｎｔ＿Ｃｒｅｄｉｔ，Ａｖａｉｌａｂｌｅ＿Ｄａｔａ，Ｌｅｆｔｏｖｅｒ＿Ｗｉｎｄｏｗ｝／Ｍａｘｉｍｕｍ＿ＲＬＣ＿ＰＤＵ＿ｓｉｚｅより小さい最大の非負整数に等しい。Ｍｉｎ｛Ｃｕｒｒｅｎｔ＿Ｃｒｅｄｉｔ，Ａｖａｉｌａｂｌｅ＿Ｄａｔａ，Ｌｅｆｔｏｖｅｒ＿Ｗｉｎｄｏｗ｝＝Ｃｕｒｒｅｎｔ＿Ｃｒｅｄｉｔである場合、Ｍｉｎ｛Ｃｕｒｒｅｎｔ＿Ｃｒｅｄｉｔ，Ｌｅｆｔｏｖｅｒ＿Ｗｉｎｄｏｗ，Ａｖａｉｌａｂｌｅ＿Ｄａｔａ｝ｍｏｄ Ｍａｘｉｍｕｍ＿ＲＬＣ＿ＰＤＵ＿ｓｉｚｅに等しいサイズの別のＲＬＣ ＰＤＵも、同じ期間内に生成することができる。Ｍｉｎ｛Ｃｕｒｒｅｎｔ＿Ｃｒｅｄｉｔ，Ａｖａｉｌａｂｌｅ＿Ｄａｔａ，Ｌｅｆｔｏｖｅｒ＿Ｗｉｎｄｏｗ｝＝Ａｖａｉｌａｂｌｅ＿Ｄａｔａである場合、Ｍｉｎ｛Ｃｕｒｒｅｎｔ＿Ｃｒｅｄｉｔ，Ｌｅｆｔｏｖｅｒ＿Ｗｉｎｄｏｗ，Ａｖａｉｌａｂｌｅ＿Ｄａｔａ｝ｍｏｄ Ｍａｘｉｍｕｍ＿ＲＬＣ＿ＰＤＵ＿ｓｉｚｅに等しいサイズの別のＲＬＣ ＰＤＵも、同じ期間内に生成することができる。Ｍｉｎ｛Ｃｕｒｒｅｎｔ＿Ｃｒｅｄｉｔ，Ａｖａｉｌａｂｌｅ＿Ｄａｔａ，Ｌｅｆｔｏｖｅｒ＿Ｗｉｎｄｏｗ｝＝Ｌｅｆｔｏｖｅｒ＿Ｗｉｎｄｏｗである場合、このＰＤＵの長さがＭｉｎｉｍｕｍ＿ＲＬＣ＿ＰＤＵ＿ｓｉｚｅより大きいときに限って、Ｍｉｎ｛Ｃｕｒｒｅｎｔ＿Ｃｒｅｄｉｔ，Ｌｅｆｔｏｖｅｒ＿Ｗｉｎｄｏｗ，Ａｖａｉｌａｂｌｅ＿Ｄａｔａ｝ｍｏｄ Ｍａｘｉｍｕｍ＿ＲＬＣ＿ＰＤＵ＿ｓｉｚｅに等しいサイズの別のＲＬＣ ＰＤＵも、同じ期間内に生成することができる。

可変サイズＲＬＣ ＰＤＵ生成は、Ｍｉｎｉｍｕｍ＿ＲＬＣ＿ＰＤＵ＿ｓｉｚｅ制限および／またはＭａｘｉｍｕｍ＿ＲＬＣ＿ＰＤＵ＿ｓｉｚｅ制限なしに適用することもできる。代替として、最大および最小ＲＬＣ ＰＤＵサイズ制限を定義し、ＭＡＣレイヤリンクアダプテーションとのＴＴＩベースの関係を必要とせずに、これらの制限を有するサイズを送信機が選択することを可能にすることも可能である。代替として、パラメータｍｉｎｉｍｕｍ＿ＲＬＣ＿ＰＤＵ＿ｓｉｚｅおよびｍａｘｉｍｕｍ＿ＲＬＣ＿ＰＤＵ＿ｓｉｚｅが定義されていないシステム内で、サイズＸのＲＬＣ ＰＤＵを生成することもできる。

ウィンドウ管理を実行するための代替方法として、固定ＲＬＣ ＰＤＵサイズ用に使用される現在の状態変数を維持し、フレキシブルＲＬＣ ＰＤＵのバイトカウントを扱う１組の新しい変数とともに同時に使用することができる。より具体的には、ＰＤＵの数に関して維持され、非機能強化ＲＬＣにおけるように処理される値のいくつかは、
・ ＲＬＣ送信機状態変数：ＶＴ（Ｓ）、ＶＴ（Ａ）、ＶＴ（ＭＳ）、ＶＴ（ＷＳ）
・ ＲＬＣ受信機状態変数：ＶＲ（Ｒ）、ＶＲ（Ｈ）、ＶＲ（ＭＲ）
を含むことができる。

ＶＴ（ＷＳ）は、ＰＤＵの最大数に関して維持され、最初は、ＰＤＵの数で提供されるＣｏｎｆｉｇｕｒｅｄ＿Ｔｘ＿Ｗｉｎｄｏｗ＿ｓｉｚｅパラメータに基づいて、高位レイヤによって設定される。この値は、ウィンドウに対して許容されるＰＤＵの最大数、および／またはシーケンス番号用に使用されるビット数によって制限されるＰＤＵの最大数に対応することができる。例えば、１２ビットが使用される場合、最大２^１２すなわち４０９６個のＰＤＵをサポートすることができる。任意選択で、フレキシブルＲＬＣ ＰＤＵサイズの場合、ＷＩＮＤＯＷ ＳＵＦＩを使用して受信機によってＶＴ（ＷＳ）を更新することを禁止することができる。ＶＴ（ＭＳ）の計算は、好ましくは、先と同じであり、ＶＴ（ＭＳ）＝ＶＴ（Ａ）＋ＶＴ（ＷＳ）である。他の受信機状態変数も、３ＧＰＰレガシ規格に従って、維持および処理することができる。

これらの変数に加えて、送信機および受信機のためのバイトカウントを扱う変数も、維持および処理される。使用できるいくつかの変数が、以下に列挙されており、バイト単位で維持されることが仮定されている。これらの変数の名前は、説明目的で使用されているに過ぎず、任意の名前を与えることができる。変数は、以下のものを含む。
・ Ｃｏｎｆｉｇｕｒｅ＿Ｔｘ＿Ｗｉｎｄｏｗ＿ｓｉｚｅ＿ｂｙｔｅｓ−このプロトコルパラメータは、オクテット単位の最大許容送信ウィンドウサイズおよび状態変数ＶＴ（ＷＳ）＿ｂｙｔｅｓの値の両方を示す。この変数は、例えば、以下の方法のいずれかで、すなわち、高位レイヤによって、ネットワークによって、ＵＥにおける事前設定によって、またはメモリ要件もしくはＵＥカテゴリに基づいたＵＥによる決定によって、設定することができる。
・ ＶＴ（ＷＳ）＿ｂｙｔｅｓ−オクテット単位で与えられる送信ウィンドウサイズ。この状態変数は、送信ウィンドウ用に使用されるオクテット単位のサイズを含む。任意選択で、送信機がＷＩＮＤＯＷ＿ＢＹＴＥ ＳＵＦＩを含むＳＴＡＴＵＳ ＰＤＵを受信した場合は、ＶＴ（ＷＳ）＿ｂｙｔｅｓは、ＷＳＮフィールドに等しい。この状態変数の初期値および最大値は、Ｃｏｎｆｉｇｕｒｅ＿Ｔｘ＿Ｗｉｎｄｏｗ＿ｓｉｚｅ＿ｂｙｔｅｓによって与えられる。
・ Ｗｉｎｄｏｗ＿ｕｔｉｌｉｚａｔｉｏｎ：利用Ｔｘウィンドウのバイト単位の長さ。すべての新しい送信毎に、バイトカウントは、初回に送信されるＲＬＣ ＰＤＵのサイズだけインクリメントされる。すべての廃棄されるＰＤＵ毎に、バイトカウントは、廃棄されるＲＬＣ ＰＤＵのサイズだけデクリメントされる。
・ ＲｘＷＭＡＸ：高位レイヤによってオクテット単位で提供された最大Ｒｘウィンドウサイズのバイト単位の長さ。
・ ＲｘＷＵＴＩＬ：利用Ｒｘウィンドウのバイト単位の長さ。この変数は、新しいＲＬＣ ＰＤＵの受信時に受信ＲＬＣ ＰＤＵサイズだけインクリメントされ、ＲＬＣ ＰＤＵがバッファから除去されるときにＲＬＣ ＰＤＵサイズだけデクリメントされる。
・ ＲｘＮ：同じ時間における受信ＰＤＵのバイト単位の長さ。

旧状態変数および新状態変数を組み合わせることで、ＲＬＣは、許容されるバイトの最大量に関して、および（送信用に利用可能なシーケンス番号の数によって制限される）許容されるＰＤＵの最大数に関しても、ＴｘウィンドウおよびＲｘウィンドウを制御することができるようになる。

フレキシブルＲＬＣ ＰＤＵサイズの導入によって影響されるＲＬＣ手順
３ＧＰＰ ＴＳ ２５．３２２ Ｖ．７．１．０における手順のいくつかは、フレキシブルＲＬＣ ＰＤＵに関してＴｘウィンドウおよびＲｘウィンドウをサポートおよび管理するために、本明細書の教示によって説明されるように更新することができ、以下の手順を含む。
・ ＡＭＤ ＰＤＵの送信。
・ ＡＭＤ ＰＤＵの下位レイヤへのサブミット。
・ 受信機によるＡＭＤ ＰＤＵの受信。
・ 受信機によるＡＭＤ ＰＤＵの受信。
・ 受信ウィンドウ外でのＡＭＤ ＰＤＵの受信。

Ｔｘ状態変数およびＲｘ状態変数の再設定および再初期化に関連する手順を更新することができる。

確認型モードデータ（ＡＭＤ）ＰＤＵの送信
固定ＲＬＣ ＰＤＵの場合、ＡＭＤ ＰＤＵが再送されたとき、送信機は、ＡＭＤ ＰＤＵのＳＮが最大送信変数ＶＴ（ＭＳ）よりも小さいことを保証しなければならない。ＷＩＮＤＯＷ ＳＵＦＩを使用して受信機によってウィンドウサイズが更新された場合、再送ＡＭＤ ＰＤＵのＳＮは、ＶＴ（ＭＳ）よりも大きいことがある。

フレキシブルＲＬＣ ＰＤＵサイズの場合、送信機は、再送されるＡＭＤ ＰＤＵまでのＴｘウィンドウ利用がバイト単位の最大ウィンドウサイズを超過しないことを、状態変数ＶＴ（ＷＳ）＿ｂｙｔｅｓを使用してチェックすることもできる。状態変数Ｗｉｎｄｏｗ＿ｕｔｉｌｉｚａｔｉｏｎは、再送バッファ内の送信されるＲＬＣ ＰＤＵの総サイズである。したがって、この条件がチェックされる場合、再送されるＳＮまでの利用は、独立に計算されなければならない。Ｗｉｎｄｏｗ＿ｕｔｉｌｉｚａｔｉｏｎがＶＴ（ＷＳ）＿ｂｙｔｅｓより小さい場合、条件は自動的に満たされるが、しかし、ｗｉｎｄｏｗ＿ｕｔｉｌｉｚａｔｉｏｎがＶＴ（ＷＳ）＿ｂｙｔｅｓより大きい場合、ＡＭＤ ＰＤＵまでのバッファ利用がＶＴ（ＷＳ）＿ｂｙｔｅｓを超過しないことを保証するために、バッファ利用が計算されなければならない。そのため任意選択で、ｗｉｎｄｏｗ＿ｕｔｉｌｉｚａｔｉｏｎが状態変数ＶＴ（ＷＳ）＿ｂｙｔｅｓを超過する場合、バッファ利用が計算される。

例えば、ＡＭＤ ＰＤＵ送信手順は、上位レイヤによって通知される固定およびフレキシブルＲＬＣ ＰＤＵサイズを考慮するために、以下の方法で変更することができる。
・ 固定ＲＬＣ ＰＤＵサイズが設定された場合、
・ 否定的に送達確認された各ＡＭＤ ＰＤＵについて、
・ ＡＭＤ ＰＤＵ ＳＮがＶＴ（ＭＳ）より小さい場合、
・ 再送のためにＡＭＤ ＰＤＵをスケジュールする。
・ フレキシブルＲＬＣ ＰＤＵサイズが設定された場合、
・ 否定的に送達確認された各ＡＭＤ ＰＤＵについて、
・ （１）ＡＭＤ ＰＤＵ ＳＮまでのウィンドウ利用がＶＴ（ＷＳ）＿ｂｙｔｅｓより小さい場合（この条件は、ｗｉｎｄｏｗ＿ｕｔｉｌｉｚａｔｉｏｎ＜ＶＴ（ＷＳ）＿ｂｙｔｅｓであれば常に真であり、またはＳＮまでの使用ウィンドウとして計算される）、および（２）任意選択で、ＡＭＤ ＰＤＵ ＳＮがＶＴ（Ｍ）より小さい場合、
・ 再送のためにＡＭＤ ＰＤＵをスケジュールする。

ＡＭＤ ＰＤＵの下位レイヤへのサブミット
ＡＭＤ ＰＤＵの送信を可能にする条件の１つは、ＡＭＤ ＰＤＵ ＳＮが状態変数ＶＴ（ＭＳ）より小さいことである。フレキシブルＲＬＣ ＰＤＵサイズが設定される場合、送信または再送ＰＤＵに関するウィンドウ利用がバイト単位の最大ウィンドウサイズを超過しないことをチェックする追加条件も確認されるべきである。下位レイヤは、ＭＡＣレイヤおよび物理レイヤを含む。

１つの手法によれば、１つまたは複数のＡＭＤ ＰＤＵが送信または再送のためにスケジュールされた場合（例えば、非特許文献３を参照）、センダは、以下のことができる。
・ 下位レイヤに送ることが許可されていないＡＭＤ ＰＤＵはどれもサブミット（submit）しない。固定ＲＬＣ ＰＤＵサイズが設定される場合、ＡＭＤ ＰＤＵは、ＡＭＤ ＰＤＵがＶＴ（ＭＳ）より小さなＳＮを有する場合、またはＡＭＤ ＰＤＵがＶＴ（Ｓ）−１に等しいＳＮを有する場合、送信することが許可される。フレキシブルＲＬＣ ＰＤＵサイズが設定される場合、ＡＭＤ ＰＤＵは、（１）ＡＭＤ ＰＤＵがＶＴ（ＭＳ）より小さなＳＮを有する場合、または任意選択で、ＡＭＤ ＰＤＵがＶＴ（Ｓ）−１に等しいＳＮを有する場合、および（２）送信されるＡＭＤ ＰＤＵが、ｗｉｎｄｏｗ＿ｕｔｉｌｉｚａｔｉｏｎ＋ＡＭＤ ＰＤＵサイズによって決定されるウィンドウ利用がＶＴ（ＷＳ）＿ｂｙｔｅｓを超過する原因とならない場合、送信することが許可される。加えて、ＡＭＤ ＰＤＵは、ＡＭＤ ＰＤＵが局所サスペンド機能（ｌｏｃａｌ ｓｕｓｐｅｎｄ ｆｕｎｃｔｉｏｎ）（例えば、非特許文献４を参照）によって送信することを制約されない場合、送信することが許可される。
・ 送信または再送のためにスケジュールされたＡＭＤ ＰＤＵの数、および送信または再送のために許可されたＡＭＤ ＰＤＵの数の両方を、下位レイヤに通知（inform）する。任意選択で、フレキシブルＲＬＣ ＰＤＵサイズが設定される場合、センダは、スケジュールされたバイトの数を下位レイヤに通知することができる。
・ 非特許文献５に従って、ＡＭＤ ＰＤＵの内容を設定する。
・ 要求された数のＡＭＤ ＰＤＵを下位レイヤにサブミット（submit）する。任意選択で、フレキシブルＲＬＣ ＰＤＵサイズが設定される場合、センダは、下位レイヤによって要求された数のバイトを下位レイヤにサブミットすることもできる。
・ 初回に送信されるＡＭＤ ＰＤＵよりも高い優先順位で再送を処理する。
・ 下位レイヤにサブミットされた各ＡＭＤ ＰＤＵについて、ＶＴ（ＤＡＴ）を除いた状態変数を更新し（状態変数については、例えば、非特許文献６を参照）、ＶＴ（ＤＡＴ）は、ＡＭＤ ＰＤＵが送信されるようスケジュールされている回数をカウントし、ＡＭＤ ＰＤＵの内容が設定されたときに既に更新されている（例えば、非特許文献３を参照）。
・ フレキシブルＲＬＣ ＰＤＵサイズが設定される場合、ｗｉｎｄｏｗ＿ｕｔｉｌｉｚａｔｉｏｎ変数を更新し、したがって、バイトカウントの追跡に関連付けられた変数も更新する。
・ （１）受信機にステータスレポートを要求するために送信機によって使用されるポーリングビットが、ＡＭＤ ＰＤＵのいずれかにおいて「１」に設定され、（２）下位レイヤによって示されるポーリングを含むＡＭＤ ＰＤＵを追跡するためのタイマであるＴｉｍｅｒ＿Ｐｏｌｌが設定された場合、タイマＴｉｍｅｒ＿Ｐｏｌｌを開始する（例えば、非特許文献７を参照）。
・ 廃棄構成に従って下位レイヤにサブミットされないＡＭＤ ＰＤＵをバッファする（例えば、非特許文献８を参照）。

受信機によるＡＭＤ ＰＤＵの受信
受信機によるＡＭＤ ＰＤＵの受信に関連する手順は、フレキシブルＲＬＣ ＰＤＵサイズのためのバイトカウントに関連する受信機状態変数の更新を含むように更新される。機能強化された手順は、以下のように定義される。ＡＭＤ ＰＤＵの受信時に、受信機は、
・ ＵＥにおいて、
・ ダウンリンクＡＭＤ ＰＤＵサイズがまだ設定されていない場合、
・ ダウンリンクＡＭＤ ＰＤＵサイズを受信ＰＤＵのサイズに設定する。
・ 各受信ＡＭＤ ＰＤＵについて、受信機状態変数ＶＲ（Ｒ）、ＶＲ（Ｈ）、およびＶＲ（ＭＲ）を更新する（例えば、非特許文献６を参照）。
・ フレキシブルＲＬＣ ＰＤＵサイズが設定される場合、
・ ＲｘＷＵＴＩＬを、ＲｘＷＵＴＩＬに新しく受信したＲＬＣ ＰＤＵのサイズを加算し、順序通りの受信のためにバッファから除去したＲＬＣ ＰＤＵのサイズを減算したものに等しく設定することによって、ＲｘＷＵＴＩＬ状態変数を更新する。

受信ウィンドウ外でのＡＭＤ ＰＤＵの受信
固定ＲＬＣ ＰＤＵサイズが設定される場合、区間ＶＲ（Ｒ）≦ＳＮ＜ＶＲ（ＭＲ）の外部のＳＮを有するＡＭＤ ＰＤＵの受信時に、受信機は、
・ ＡＭＤ ＰＤＵを廃棄し、
・ 廃棄されたＡＭＤ ＰＤＵ内のポーリングビットが「１」に設定されている場合、
・ ＳＴＡＴＵＳ ＰＤＵ転送手順を開始する。

フレキシブルＲＬＣ ＰＤＵサイズが設定される場合、ＲｘＷＵＴＩＬに追加されるサイズがＲｘＷＭＡＸを超過する新しいＡＭＤ ＰＤＵ（ＲｘＷＭＡＸ＜ＲｘＷＵＴＩＬ＋新しく受信されたＡＭＤ ＰＤＵのサイズもしくはＲｘＮ）の受信時、または区間ＶＲ（Ｒ）≦ＳＮ＜ＶＲ（ＭＲ）の外部のＳＮを有するＡＭＤ ＰＤＵの受信時に、受信機は、
・ ＡＭＤ ＰＤＵを廃棄し、
・ 廃棄されたＡＭＤ ＰＤＵ内のポーリングビットが「１」に設定されている場合、
・ ＳＴＡＴＵＳ ＰＤＵ転送手順を開始する。

ＲＬＣステータスレポーティング
ＡＲＱをサポートするための送達確認情報を含むＲＬＣステータスレポートは、様々なシナリオにおいて、ＲＬＣ ＴｘエンティティおよびＲＬＣ Ｒｘエンティティによってトリガすることができる。フレキシブルＲＬＣ ＰＤＵサイズを処理するため、ＲＬＣ ＴｘエンティティおよびＲＬＣ Ｒｘエンティティは、ＲＬＣ ＰＤＵ ＳＮの、対応するバイト単位のＰＤＵ長へのマッピングを維持することができる。これは、使用されるフロー制御ウィンドウのバイト単位の長さ、または上述されたような他のバイトベースのメトリックの計算および維持を可能にする。

すべてのＰｏｌｌ＿ＰＤＵ ＰＤＵに対して等価なパラメータ、ポーリングを追跡するための状態変数ＶＴ（ＰＤＵ）の上限は、バイト単位で設定することができる。この場合、送信機は、ＰＤＵカウントポーリングメカニズムを有することができ、および／または送信機が受信機にすべてのＰｏｌｌ＿Ｂｙｔｅｓバイトをポーリングするように、バイトカウントポーリングメカニズムを有することができる。説明目的で、本明細書では、高位レイヤによって提供されるポーリングパラメータをＰｏｌｌ＿Ｂｙｔｅｓと呼ぶことが仮定されている。ポーリングのために構成される場合、ＲＬＣ送信機は、あるＰＤＵ内のポーリングビットを以下のように設定することによって、ステータスレポートをトリガすることができる。
・ ＲＬＣ送信機は、ポーリングビットを含む最後のＰＤＵを送信して以降にＰＤＵで送信されたバイトの総数のカウンタを維持し、ポーリングビットを含む最後のＰＤＵは、例えば、Ｐｏｌｌ＿ＰＤＵ、Ｐｏｌｌ＿ＳＤＵ、もしくはＰｏｌｌ＿ｂｙｔｅｓを含む、任意のタイプのポーリングトリガに帰することができ、または代替として、バイトポーリングメカニズムのためにトリガされたポーリングビットを含む最後のＰＤＵに制限することもできる。
・ カウンタが値Ｐｏｌｌ＿Ｂｙｔｅｓに到達した場合、またはそれを超過した場合、ＲＬＣ送信機は、カウンタが値Ｐｏｌｌ＿Ｂｙｔｅｓより大きくまたは等しくなった原因のＰＤＵ（または代替として、次のＰＤＵ）内のポーリングビットを設定し、カウンタをリセットする。

本明細書では、ポーリングビットの設定とは、ポーリング要求のことを指し、ポーリング要求は、ＰＯＬＬ ＳＵＦＩ ＰＤＵからなることができ、またはＡＭＤ ＲＬＣ ＰＤＵ内のポーリングビットの設定からなることができる。ＰＤＵで送信されるバイトの総数とは、初回に送信されるＰＤＵのサイズのことを指す。代替として、それは、再送も含めて、送信されるすべてのＰＤＵのサイズのことを指すこともできる。送信されるバイトのカウント総数は、ＲＬＣ確認型モードデータ（ＡＭＤ）ＰＤＵ、ＲＬＣ ＡＭＤ ＰＤＵセグメント、またはＲＬＣ ＳＤＵの一部分の初回送信だけをカウントすることができ、これらのデータの一部分の再送は、カウントすることはできない。

プロトコルパラメータＰｏｌｌ＿ＰＤＵおよびＰｏｌｌ＿ＳＤＵは、ＰＤＵカウント間隔を示すために、ＲＲＣなどの上位レイヤによって、ＲＬＣレイヤに通知される。加えて、オクテット単位のプロトコルパラメータＰｏｌｌ＿Ｂｙｔｅｓは、高位レイヤによって通知および設定することができる。ＲＬＣ送信機におけるポーリング手順は、以下のものを含むことができる。
・ ＲＬＣ送信機は、ポーリングビットを含む最後のＰＤＵを送信して以降にＰＤＵで送信されたバイトの総数を追跡するために、変数Ｐｏｌｌ＿Ｏｃｔｅｔｓカウンタを維持し、ポーリングビットを含む最後のＰＤＵは、例えば、高位レイヤからのパラメータＰｏｌｌ＿ＰＤＵ、Ｐｏｌｌ＿ＳＤＵ、またはＰｏｌｌ＿Ｂｙｔｅｓの受信に起因してトリガされることができる。代替として、Ｐｏｌｌ＿Ｏｃｔｅｔｓは、バイトポーリングメカニズムだけに起因してトリガされたポーリングビットを含む最後のＰＤＵ以降に送信されたバイトの総数を追跡することもできる。

Ｐｏｌｌ＿Ｏｃｔｅｔｓカウンタは、任意選択で、各ＲＬＣ確認型モードデータ（ＡＭＤ）ＰＤＵの初回送信のバイトの総数をカウントすることができる。Ｐｏｌｌ＿Ｏｃｔｅｔｓカウンタは、任意選択で、ＲＬＣ制御ＰＤＵがカウントされないように、ＲＬＣデータＰＤＵだけをカウントすることができる。Ｐｏｌｌ＿ＯｃｔｅｔｓカウンタがＰｏｌｌ＿Ｂｙｔｅｓ間隔値に到達した場合、ＲＬＣ送信機は、Ｐｏｌｌ＿ＯｃｔｅｔｓカウンタにＰｏｌｌ＿Ｂｙｔｅｓの閾値を超過させるＰＤＵ（または任意選択で、次のＰＤＵ）内のポーリングビットを設定し、Ｐｏｌｌ＿Ｏｃｔｅｔｓカウンタをリセットする。Ｐｏｌｌ＿ＰＤＵの受信など他のポーリング条件のためにポーリングビットが設定された場合も、Ｐｏｌｌ＿Ｏｃｔｅｔｓカウンタをリセットすることができる。

ＡＭ ＲＬＣに対してフレキシブルＲＬＣ ＰＤＵサイズがサポートされ、フレキシブルＲＬＣ ＰＤＵサイズモードがＲＲＣレイヤによって設定され、ウィンドウベースのポーリングが上位レイヤによって構成される場合、受信機にポーリングを行うよう送信機に通知するために、プロトコルパラメータＰｏｌｌ＿Ｗｉｎｄｏｗが、上位レイヤによってＲＬＣに伝達される。Ｐｏｌｌ＿Ｗｉｎｄｏｗは、ウィンドウパーセンテージ単位またはバイト数単位で与えることができる。ポーリングは、値ＫがパラメータＰｏｌｌ＿Ｗｉｎｄｏｗより大きい、または等しい場合に、各ＡＭＤ ＰＤＵについて送信機によってトリガされ、ここで、Ｋは、
Ｋ＝ｕｔｉｌｉｚｅｄ＿ｗｉｎｄｏｗ／Ｍａｘｉｍｕｍ＿Ｔｘ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅ（オクテット単位） 式（６）
として定義される送信ウィンドウパーセンテージであり、ｕｔｉｌｉｚｅｄ＿ｗｉｎｄｏｗは、状態変数ＶＴ（Ａ）およびＶＴ（Ｓ）によって境界が画定されるウィンドウのオクテット単位の長さである。ｕｔｉｌｉｚｅｄ＿ｗｉｎｄｏｗは、送信バッファ内に残っているデータによって利用されているバッファを表す。Ｐｏｌｌ＿Ｗｉｎｄｏｗがバイト数単位で与えられる場合、Ｋはｕｔｉｌｉｚｅｄ＿ｗｉｎｄｏｗに等しい。したがって、送信機は、ｕｔｉｌｉｚｅｄ＿ｗｉｎｄｏｗがネットワークによって伝達されたバイト数Ｐｏｌｌ＿ｗｉｎｄｏｗを超過した場合に、ポーリング要求をトリガする。

ＲＬＣ送信機は、使用／利用Ｔｘウィンドウサイズが、バイト数単位または最大ウィンドウサイズのパーセンテージ単位で、あるシステム構成閾値を上回った場合に、ポーリングビットを設定することによって、ステータスレポートをトリガすることができる。ＲＬＣ受信機は、使用／利用Ｒｘウィンドウサイズが、バイト数単位または最大ウィンドウサイズのパーセンテージ単位で、あるシステム構成閾値を上回った場合に、ステータスレポートをトリガすることができる。「ウィンドウベースのポーリング」が上位レイヤによって構成される場合、Ｐｏｌｌ＿Ｗｉｎｄｏｗは、送信機が受信機にポーリングを行う時を示す。ポーリングは、値ＪがパラメータＰｏｌｌ＿Ｗｉｎｄｏｗより大きい場合に、各ＡＭＤ ＰＤＵについてトリガされ、ここで、Ｊは、

として定義される送信ウィンドウパーセンテージであり、定数４０９６は、非特許文献６に記載されたＡＭのための法であり、ＶＴ（Ｓ）は、ＡＭＤ ＰＤＵが下位レイヤにサブミットされる前の、Ｐｏｌｌ＿Ｗｉｎｄｏｗの初期値である。

フレキシブルＲＬＣ ＰＤＵサイズが設定される場合、ポーリングは、Ｋの値がパラメータＰｏｌｌ＿Ｗｉｎｄｏｗより大きい場合にも、各ＡＭＤ ＰＤＵについてトリガされ、ここで、Ｋは、

本明細書の教示は、ＲＬＣ送信（Ｔｘ）エンティティおよびＲＬＣ受信（Ｒｘ）エンティティとの関連で説明されたが、アップリンク（ＵＥからＵＴＲＡＮ／Ｅ−ＵＴＲＡＮ）通信およびダウンリンク（ＵＴＲＡＮ／Ｅ−ＵＴＲＡＮからＵＥ）通信の両方に適用可能である。例えば、アップリンク方向では、パラメータＣｏｎｆｉｇｕｒｅｄ＿Ｔｘ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅの構成／再構成は、以下のことの原因となる。
・ 上述されたように、ＵＥがＣｏｎｆｉｇｕｒｅｄ＿Ｔｘ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅから状態変数ＶＴ（ＷＳ）を導き出すこと。
・ 上述されたように、ＵＥが状態変数ＶＴ（ＭＳ）を更新すること。

実施形態
１．フレキシブルパケットデータユニット（ＰＤＵ）サイズをサポートするように構成された、ＲＬＣエンティティにおける無線リンク制御（ＲＬＣ）動作を機能強化する方法。

２．バイトカウントベースのウィンドウサイズメトリックに基づいて、ウィンドウサイズを定義し、管理するステップを含む実施形態１に記載の方法。

３．ウィンドウサイズを定義し、管理するステップが、バイト数を含むウィンドウサイズメトリックに基づく、先行する実施形態のいずれかに記載の方法。

４．ウィンドウサイズを定義し、管理するステップが、ブロック数を含むウィンドウサイズメトリックに基づき、各ブロックは、一定の数のバイトである、先行する実施形態のいずれかに記載の方法。

５．ウィンドウサイズを定義し、管理するステップが、パケットデータユニット（ＰＤＵ）シーケンス番号にさらに基づく、先行する実施形態のいずれかに記載の方法。

６．ウィンドウサイズメトリックをＲＬＣ制御ＰＤＵ内に含むステップをさらに含む先行する実施形態のいずれかに記載の方法。

７．ウィンドウサイズメトリックをＲＬＣステータスＰＤＵ内に含めるステップをさらに含む先行する実施形態のいずれかに記載の方法。

８．高位レイヤから最大ＲＬＣ ＰＤＵペイロードサイズを受信するステップをさらに含む先行する実施形態のいずれかに記載の方法。

９．最大ＲＬＣ ＰＤＵペイロードサイズから最大ＲＬＣ ＰＤＵサイズを推測するステップをさらに含む実施形態８に記載の方法。

１０．高位レイヤから最大ＲＬＣ ＰＤＵサイズを受信するステップをさらに含む先行する実施形態のいずれかに記載の方法。

１１．無線ベアラのセットアップの最中に、バイトカウントベースのウィンドウサイズメトリックを受信し、ネゴシエートするステップをさらに含む先行する実施形態のいずれかに記載の方法。

１２．無線ベアラの構成の最中に、バイトカウントベースのウィンドウサイズメトリックを受信し、ネゴシエートするステップをさらに含む先行する実施形態のいずれかに記載の方法。

１３．無線ベアラの再構成の最中に、バイトカウントベースのウィンドウサイズメトリックを受信し、ネゴシエートするステップをさらに含む先行する実施形態のいずれかに記載の方法。

１４．接続中のフロー制御のためにウィンドウを更新するすべてのメッセージングにおいて、バイトベースのウィンドウサイズメトリックを適用するステップをさらに含む先行する実施形態のいずれかに記載の方法。

１５．すべてのメッセージングにおいて、ウィンドウサイズメトリックを適用するステップが、メッセージングが、ウィンドウサイズスーパフィールド（ＳＵＦＩ）をＲＬＣ制御ＰＤＵおよびＲＬＣステータスＰＤＵ内に含むようなものである、実施形態１４に記載の方法。

１６．すべてのメッセージングにおいて、ウィンドウサイズメトリックを適用するステップが、メッセージングが、受信ウィンドウ移動（ＭＲＷ）ＳＵＦＩをＲＬＣ制御ＰＤＵおよびＲＬＣステータスＰＤＵ内に含むようなものである、実施形態１４〜１５のいずれかに記載の方法。

１７．ＲＬＣエンティティは、確認型モード（ＡＭ）で動作している、先行する実施形態のいずれかに記載の方法。

１８．無線リソース制御（ＲＲＣ）エンティティから、他のＲＬＣモードに加えてフレキシブルＲＬＣ ＰＤＵサイズモード用の新しいインジケータを含むＣＨＯＩＣＥダウンリンクＲＬＣモード情報を含む無線ベアラ情報要素を受信するステップをさらに含む実施形態１７に記載の方法。

１９．無線リソース制御（ＲＲＣ）エンティティから、フレキシブルＲＬＣ ＰＤＵサイズモード示す情報要素を含む無線ベアラ情報要素を受信するステップをさらに含む実施形態１７〜１８のいずれかに記載の方法。

２０．無線リソース制御（ＲＲＣ）エンティティから、オクテット単位のＲＬＣスケールパラメータまたはフレキシブルＲＬＣ ＰＤＵサイズモードの最大ＲＬＣ ＰＤＵサイズの一方を示すダウンリンクＲＬＣ ＰＤＵサイズ情報を含む無線ベアラ情報要素を受信するステップをさらに含む実施形態１７〜１９のいずれかに記載の方法。

２１．無線リソース制御（ＲＲＣ）エンティティから、Ｐｏｌｌ＿ＰＤＵ、Ｐｏｌｌ＿ＳＤＵ、Ｃｏｎｆｉｇｕｒｅｄ＿Ｔｘ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅ、およびＣｏｎｆｉｇｕｒｅｄ＿Ｒｘ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅを含む、ＲＲＣによって通知されたプロトコルパラメータを含む無線ベアラ情報要素を受信するステップをさらに含む実施形態１７〜２０のいずれかに記載の方法。

２２．プロトコルパラメータは、ＰＤＵの数およびバイト単位の少なくとも一方で指定され、解釈される、実施形態２１に記載の方法。

２３．送信のためにＲＬＣ ＰＤＵを受信するステップと、ウィンドウ利用がバイト単位で最大ウィンドウサイズを超過する場合、または受信したＲＬＣ ＰＤＵシーケンス番号がＰＤＵの数で最大ウィンドウサイズを超過する場合は、受信したＲＬＣ ＰＤＵを保持し、それらを下位レイヤにサブミットしないステップとをさらに含む実施形態１７〜２２のいずれかに記載の方法。

２４．ＲＬＣ ＳＴＡＴＵＳ ＰＤＵのオクテット量を指示するウィンドウサイズスーパフィールド（ＳＵＦＩ）をＲＲＣエンティティから受信するステップをさらに含む実施形態１７〜２２のいずれかに記載の方法。

２５．ウィンドウサイズＳＵＦＩは、ＰＤＵの数で指定される、実施形態２４に記載の方法。

２６．ＰＤＵの数にオクテット単位のＲＬＣスケールパラメータを乗じることによって、オクテット単位のウィンドウサイズを導き出すステップをさらに含む実施形態２５に記載の方法。

２７．ウィンドウサイズＳＵＦＩは、タイプ、長さおよび値成分を有する新しいＳＵＦＩ ＷＩＮＤＯＷ＿ＢＹＴＥＳとしてバイト単位で指定される、実施形態２４に記載の方法。

２８．最大ＲＬＣ ＰＤＵサイズを用いてフレキシブルパケットデータユニット（ＰＤＵ）サイズをサポートするように構成された、ＲＬＣエンティティにおける無線リンク制御（ＲＬＣ）動作を機能強化するための方法であって、バイトカウントベースのメトリックを使用してＲＬＣフロー制御を実行するステップを含む方法。

２９．バイトカウントベースのメトリックを使用してＲＬＣステータスレポーティングを実行するステップをさらに含む実施形態２８に記載の方法。

３０．ＲＬＣエンティティは、送信機においてＲＬＣ送信エンティティとして構成され、１つまたは複数のＰＤＵが受信機によって肯定的に送達確認された場合、ＲＬＣ送信動作の実行時にＲＬＣ送信ウィンドウを更新するステップをさらに含む実施形態２８〜２９のいずれかに記載の方法。

３１．ＲＬＣエンティティは、送信機においてＲＬＣ送信エンティティとして構成され、受信機が最大再送回数を超過した結果として、１つまたは複数のＰＤＵが受信機によって否定的に送達確認された場合、ＲＬＣ送信動作の実行時にＲＬＣ送信ウィンドウを更新するステップをさらに含む実施形態２８〜２９のいずれかに記載の方法。

３２．ＲＬＣエンティティは、送信機においてＲＬＣ送信エンティティとして構成され、送信機におけるタイマベースの廃棄の結果として、ＲＬＣ送信動作の実行時にＲＬＣ送信ウィンドウを更新するステップをさらに含む実施形態２８〜２９のいずれかに記載の方法。

３３．ＲＬＣ送信ウィンドウを更新するステップが、利用送信ウィンドウから１つまたは複数のＰＤＵを除去し、利用送信ウィンドウの下端を増加させるステップを含む実施形態３０〜３２のいずれかに記載の方法。

３４．以下のパラメータ、すなわち、最大ウィンドウサイズのバイト単位の長さに等しいＴｘＷＭＡＸと、利用送信ウィンドウのバイト単位の長さ、または送信状態変数Ｖ（Ａ）およびＶ（Ｔ）によって境界が画定されるウィンドウ内の送達確認されたパケットのバイト単位の長さの一方に等しいＴｘＷＵＴＩＬと、ＲＬＣ ＳＤＵ廃棄手順のために廃棄される１つまたは複数のＰＤＵのバイト単位の長さ、または１つまたは複数の肯定応答の受信のためのバイト単位の長さの一方に等しいＴｘＬと、初回に送信される次の１つまたは複数のＰＤＵのバイト単位の長さに等しいＴｘＮとを決定するステップをさらに含む実施形態３３に記載の方法。

３５．ウィンドウ長（ＷＬ）量ＷＬ＝ＴｘＷＵＴＩＬ−ＴｘＬ＋ＴｘＮを計算するステップをさらに含む実施形態３４に記載の方法。

３６．ＷＬがＴｘＷＭＡＸより小さい場合、次の１つまたは複数のＰＤＵを送信し、利用送信ウィンドウの上端を増加させるステップをさらに含む実施形態３５に記載の方法。

３７．ＲＬＣエンティティは、ＲＬＣ受信エンティティとして構成され、ＲＬＣ受信エンティティが順序通り並べた中で最後の受信ＰＤＵのシーケンス番号に後続するシーケンス番号を有する１つまたは複数のＰＤＵを受信した場合、ＲＬＣ受信動作の実行時にＲＬＣ受信ウィンドウを更新するステップをさらに含む実施形態２８〜２９のいずれかに記載の方法。

３８．ＲＬＣエンティティは、ＲＬＣ受信エンティティとして構成され、ＲＬＣ受信エンティティがＲＬＣ送信エンティティから受信ウィンドウ移動（ＭＲＷ）命令を受信した場合、ＲＬＣ受信動作の実行時にＲＬＣ受信ウィンドウを更新するステップをさらに含む実施形態２８〜２９のいずれかに記載の方法。

３９．ＲＬＣ受信ウィンドウを更新するステップが、利用受信ウィンドウの下端を増加させるステップを含む、実施形態３７〜３８のいずれかに記載の方法。

４０．以下のパラメータ、すなわち、最大ウィンドウサイズのバイト単位の長さに等しいＲｘＷＭＡＸと、利用受信ウィンドウのバイト単位の長さに等しいＲｘＷＵＴＩＬと、順序通りの受信のためにＲＬＣ受信ウィンドウから除去される１つまたは複数のＰＤＵのバイト単位の長さに等しいＲｘＤと、初回に受信される次の１つまたは複数のＰＤＵのバイト単位の長さに等しいＲｘＮとを決定するステップをさらに含む実施形態３９に記載の方法。

４１．ウィンドウ長（ＷＬ）量ＷＬ＝ＲｘＷＵＴＩＬ＋ＲｘＮ−ＲｘＤを計算するステップをさらに含む実施形態４０に記載の方法。

４２．ＷＬがＲｘＷＭＡＸより小さい場合、次の１つまたは複数のＰＤＵを受信し、利用受信ウィンドウの上端を増加させるステップをさらに含む実施形態４０に記載の方法。

４３．以下のパラメータ、すなわち、アップリンクではＭＡＣリンクアダプテーションに基づいて送信できるデータの量、ダウンリンクでは残りのクレジットアロケーションに新しく受信したクレジットアロケーションを加算したオクテット単位の結果であるデータの量に等しいＣｕｒｒｅｎｔ＿Ｃｒｅｄｉｔと、ＲＬＣ ＰＤＵフォーマットで送信される利用可能なデータに等しいオクテット単位のＡｖａｉｌａｂｌｅ＿Ｄａｔａと、ＲＬＣ送信機において状態変数ＶＴ（Ｓ）およびＶＴ（ＭＳ）によって境界が画定されるウィンドウの長さに等しいオクテット単位で表されるＬｅｆｔｏｖｅｒ＿Ｗｉｎｄｏｗと、上位レイヤによって設定される最大ＲＬＣ ＰＤＵサイズに等しいＭａｘｉｍｕｍ＿ＲＬＣ＿ＰＤＵ＿ｓｉｚｅと、最小ＲＬＣ ＰＤＵサイズまたは最小ＲＬＣ ＰＤＵペイロードサイズの一方を指定する、上位レイヤによって設定されるパラメータに等しいＭｉｎｉｍｕｍ＿ＲＬＣ＿ＰＤＵ＿ｓｉｚｅとを定義することによって、すべての時間間隔毎にＲＬＣ ＰＤＵを生成するステップをさらに含む実施形態２８〜４１のいずれかに記載の方法。

４４．パラメータＸ＝Ｍｉｎ｛Ｃｕｒｒｅｎｔ＿Ｃｒｅｄｉｔ，Ａｖａｉｌａｂｌｅ＿Ｄａｔａ，Ｌｅｆｔｏｖｅｒ＿Ｗｉｎｄｏｗ｝を計算するステップをさらに含み、ここで、Ｍｉｎ｛・｝は、集合内から最小値を返す、実施形態４３に記載の方法。

４５．パラメータＮ＝Ｆｌｏｏｒ｛Ｘ／Ｍａｘｉｍｕｍ＿ＲＬＣ＿ＰＤＵ＿ｓｉｚｅ｝を計算するステップをさらに含み、ここで、Ｆｌｏｏｒ｛・｝は、より小さい最も近い整数値およびａ ｍｏｄ ｂを返す、実施形態４３〜４４のいずれかに記載の方法。

４６．Ｌ＝Ｘ ｍｏｄ Ｍａｘｉｍｕｍ＿ＲＬＣ＿ＰＤＵ＿ｓｉｚｅを計算するステップをさらに含み、ここで、ａをｂで除算した剰余を返す、実施形態４３〜４５のいずれかに記載の方法。

４７．Ｍａｘｉｍｕｍ＿ＲＬＣ＿ＰＤＵ＿ｓｉｚｅに等しい長さのＰＤＵをＮ個生成するステップをさらに含む実施形態４５〜４６のいずれかに記載の方法。

４８．ＸがＬｅｆｔｏｖｅｒ＿ＷｉｎｄｏｗまたはＣｕｒｒｅｎｔ＿Ｃｒｅｄｉｔに等しくない場合、長さＬの別のＲＬＣ ＰＤＵを生成するステップをさらに含む実施形態４７に記載の方法。

４９．ＸがＬｅｆｔｏｖｅｒ＿ＷｉｎｄｏｗもしくはＣｕｒｒｅｎｔ＿Ｃｒｅｄｉｔに等しく、ＬがＭｉｎｉｍｕｍ＿ＲＬＣ＿ＰＤＵ＿ｓｉｚｅより大きい場合、またはＸがＡｖａｉｌａｂｌｅ＿Ｄａｔａに等しい場合、長さＬの別のＲＬＣ ＰＤＵを生成するステップをさらに含む実施形態４７〜４８のいずれかに記載の方法。

５０．ＸがＬｅｆｔｏｖｅｒ＿ＷｉｎｄｏｗもしくはＣｕｒｒｅｎｔ＿Ｃｒｅｄｉｔに等しく、ＬがＭｉｎｉｍｕｍ＿ＲＬＣ＿ＰＤＵ＿ｓｉｚｅより大きくない場合、長さＭｉｎｉｍｕｍ＿ＲＬＣ＿ＰＤＵ＿ｓｉｚｅの別のＲＬＣ ＰＤＵを生成するステップをさらに含む実施形態４７〜４９のいずれかに記載の方法。

５１．生成されたＲＬＣ ＰＤＵを送信のためにバッファに保存するステップをさらに含む実施形態４７〜５０のいずれかに記載の方法。

５２．時間間隔は、送信時間間隔（ＴＴＩ）の１倍または複数倍によって定義される、実施形態４３〜５１のいずれかに記載の方法。

５３．時間間隔は、データが送信のために利用可能になったとき、またはデータが下位レイヤに要求されたときの時間インスタンス（ｔｉｍｅ ｉｎｓｔａｎｃｅ）によって定義される、実施形態４３〜５１のいずれかに記載の方法。

５４．Ｍａｘｉｍｕｍ＿ＲＬＣ＿ＰＤＵ＿ｓｉｚｅおよびＭｉｎｉｍｕｍ＿ＲＬＣ＿ＰＤＵ＿ｓｉｚｅは、上位レイヤによって設定されない、実施形態４３〜５３のいずれかに記載の方法。

５５．状態変数を維持するステップをさらに含み、状態変数は、ＰＤＵの数およびバイト単位で指定され、解釈される、実施形態２８〜５４のいずれかに記載の方法。

５６．ＲＬＣエンティティは、ＲＬＣ送信エンティティとして構成され、オクテット単位の最大送信ウィンドウサイズを表す状態変数Ｍａｘｉｍｕｍ＿Ｔｘ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅを維持するステップを含む実施形態５５に記載の方法。

５７．状態変数Ｍａｘｉｍｕｍ＿Ｔｘ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅを、受信ＲＬＣステータスＰＤＵ内のウィンドウサイズスーパフィールド（ＳＵＦＩ）によって指定されるオクテット量に更新するステップをさらに含む実施形態５６に記載の方法。

５８．以下の状態変数、すなわち、送信状態変数ＶＴ（Ｓ）と、送達確認状態変数ＶＴ（Ａ）と、最大送信状態変数ＶＴ（ＭＳ）と、送信ウィンドウサイズ状態変数ＶＴ（ＷＳ）とを維持するステップをさらに含む実施形態５６〜５７のいずれかに記載の方法。

５９．オクテット単位の状態変数Ｍａｘｉｍｕｍ＿Ｔｘ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅに基づいて、状態変数ＶＴ（Ｓ）、ＶＴ（Ａ）、ＶＴ（ＭＳ）、およびＶＴ（ＷＳ）を更新するステップをさらに含む実施形態５８に記載の方法。

６０．ＲＬＣエンティティは、ＲＬＣ受信エンティティとして構成され、オクテット単位の最大受信ウィンドウサイズを表す状態変数Ｍａｘｉｍｕｍ＿Ｒｘ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅを維持するステップをさらに含む実施形態５５に記載の方法。

６１．上位レイヤから状態変数Ｍａｘｉｍｕｍ＿Ｒｘ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅを受信するステップをさらに含む実施形態６０に記載の方法。

６２．以下の状態変数、すなわち、受信状態変数ＶＲ（Ｒ）と、最高予想状態変数ＶＲ（Ｈ）と、最大許容可能受信状態変数ＶＲ（ＭＲ）とを維持するステップをさらに含む実施形態６１に記載の方法。

６３．オクテット単位の状態変数Ｍａｘｉｍｕｍ＿Ｒｘ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅに基づいて、状態変数ＶＲ（Ｒ）、ＶＲ（Ｈ）、およびＶＲ（ＭＲ）を更新するステップをさらに含む実施形態６２に記載の方法。

６４．バイトカウントベースのメトリックを使用してＲＬＣポーリングメカニズムを定義し、管理するステップをさらに含む実施形態２８〜６３のいずれかに記載の方法。

６５．以下のパラメータ、すなわち、アップリンクではＭＡＣリンクアダプテーションに基づいて送信できるデータの量、ダウンリンクでは残りのクレジットアロケーションに新しく受信したクレジットアロケーションを加算したオクテット単位の結果であるデータの量に等しいＣｕｒｒｅｎｔ＿Ｃｒｅｄｉｔと、ＲＬＣ ＰＤＵフォーマットで送信される利用可能なデータに等しいオクテット単位のＡｖａｉｌａｂｌｅ＿Ｄａｔａと、ＲＬＣ送信機において状態変数ＶＴ（Ｓ）およびＶＴ（ＭＳ）によって境界が画定されるウィンドウの長さに等しいオクテット単位で表されるＬｅｆｔｏｖｅｒ＿Ｗｉｎｄｏｗとを定義するステップをさらに含む実施形態６４に記載の方法。

６６．パラメータＸ＝Ｍｉｎ｛Ｃｕｒｒｅｎｔ＿Ｃｒｅｄｉｔ，Ａｖａｉｌａｂｌｅ＿Ｄａｔａ，Ｌｅｆｔｏｖｅｒ＿Ｗｉｎｄｏｗ｝を計算するステップをさらに含む実施形態６５に記載の方法。

６７．オクテット単位の利用ウィンドウサイズがＸより大きい場合、確認型モードデータ（ＡＭＤ）ＰＤＵにおいてポーリングをトリガするステップをさらに含む実施形態６６に記載の方法。

６８．送信データの総量が知られた所定のオクテット量またはデータブロック量を超過する毎に、ＡＭＤ ＰＤＵにおいてポーリングをトリガするステップをさらに含む実施形態２８〜６７のいずれかに記載の方法。

６９．ウィンドウベースのポーリングが上位レイヤによって構成された場合に受信機にポーリングを行うために、プロトコルパラメータＰｏｌｌ＿Ｗｉｎｄｏｗを使用するステップをさらに含む実施形態６８に記載の方法。

７０．送信ウィンドウパーセンテージＫがＰｏｌｌ＿Ｗｉｎｄｏｗより大きい、または等しい場合に、各確認型モードデータ（ＡＭＤ）ＰＤＵについてポーリングをトリガするステップをさらに含み、ここで、Ｋは、Ｋ＝ｕｔｉｌｉｚｅｄ＿ｗｉｎｄｏｗ／Ｍａｘｉｍｕｍ＿Ｔｘ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅとしてオクテット単位で定義され、ｕｔｉｌｉｚｅｄ＿ｗｉｎｄｏｗは、状態変数ＶＴ（Ａ）およびＶＴ（Ｓ）によって境界が画定されるウィンドウのオクテット単位の長さである、実施形態６８に記載の方法。

７１．プロトコルパラメータＰｏｌｌ＿ＰＤＵおよびＰｏｌｌ＿ＳＤＵは、ＰＤＵカウント間隔を示すために、ＲＬＣ送信エンティティにおいて上位レイヤから受信される、実施形態２８〜７０のいずれかに記載の方法。

７２．オクテット単位のプロトコルパラメータＰｏｌｌ＿Ｂｙｔｅｓは、ポーリングの間のバイトカウント間隔を示すように構成される、実施形態２８〜７１のいずれかに記載の方法。

７３．ポーリング要求をトリガした最後のＰＤＵを送信して以降にＰＤＵで送信されたバイトの総数についての変数Ｐｏｌｌ＿ＯｃｔｅｔｓカウンタをＲＬＣ送信エンティティによって維持するステップをさらに含む実施形態７２に記載の方法。

７４．Ｐｏｌｌ＿ＯｃｔｅｔｓカウンタがＰｏｌｌ＿Ｂｙｔｅｓの値より大きく、または等しくなった場合、ＲＬＣ送信エンティティによって、Ｐｏｌｌ＿ＯｃｔｅｔｓカウンタにＰｏｌｌ＿Ｂｙｔｅｓを超過させるＰＤＵでポーリング要求をトリガし、Ｐｏｌｌ＿Ｏｃｔｅｔｓカウンタをリセットするステップをさらに含む実施形態７２に記載の方法。

７５．Ｐｏｌｌ＿Ｏｃｔｅｔｓカウンタは、初回に送信されるＰＤＵのバイトの総数をカウントする、実施形態７３〜７４のいずれかに記載の方法。

７６．Ｐｏｌｌ＿Ｏｃｔｅｔｓカウンタは、再送も含めて、送信されるすべてのＰＤＵのバイトの総数をカウントする、実施形態７３〜７４のいずれかに記載の方法。

７７．ポーリング要求をトリガするステップが、Ｐｏｌｌ＿ＯｃｔｅｔｓカウンタにＰｏｌｌ＿Ｂｙｔｅｓを超過させるＰＤＵ内のポーリングビットを設定するステップを含む、実施形態７３〜７６のいずれかに記載の方法。

７８．ポーリング要求をトリガするステップが、ＰＯＬＬ ＰＤＵを受信機に送信するステップを含む、実施形態７３〜７６のいずれかに記載の方法。

７９．ポーリング要求をトリガした最後のＰＤＵは、Ｐｏｌｌ＿Ｂｙｔｅｓメカニズムに起因する、実施形態７８に記載の方法。

８０．ポーリング要求をトリガした最後のＰＤＵは、Ｐｏｌｌ＿ＰＤＵまたはＰｏｌｌ＿ＳＤＵに起因する、実施形態７８に記載の方法。

８１．プロトコルパラメータＰｏｌｌ＿Ｗｉｎｄｏｗは、ＲＬＣ送信エンティティにおいて上位レイヤから受信される、実施形態６７〜６８のいずれかに記載の方法。

８２．ウィンドウベースのポーリングが上位レイヤによって構成される場合、受信機にポーリングを行うためにＰｏｌｌ＿Ｗｉｎｄｏｗを使用するステップをさらに含む実施形態８１に記載の方法。

８３．値ＪがＰｏｌｌ＿Ｗｉｎｄｏｗより大きい、または等しい場合に、送信機によって、各確認型モードデータ（ＡＭＤ）ＰＤＵについてポーリングをトリガするステップをさらに含み、ここで、Ｊは、

として定義され、数４０９６は、確認型モード（ＡＭ）のための法であり、ＶＴ（Ｓ）、ＶＴ（Ａ）、およびＶＴ（ＷＳ）は、状態変数である、実施形態８２に記載の方法。

８４．値ＫがＰｏｌｌ＿Ｗｉｎｄｏｗより大きい、または等しい場合に、各ＡＭＤ ＰＤＵについてポーリングをトリガするステップをさらに含み、ここで、Ｋは、

として定義される、実施形態８３に記載の方法。

８５．ＲＬＣエンティティによって実行される先行する実施形態のいずれかに記載の方法。

８６．実施形態８５のＲＬＣエンティティを含む無線送受信ユニット（ＷＴＲＵ）。

８７．実施形態８５のＲＬＣエンティティを含むＮｏｄｅ Ｂ。

８８．実施形態８５のＲＬＣエンティティを含む無線ネットワークコントローラ（ＲＮＣ）。

８９．フレキシブル無線リンク制御（ＲＬＣ）パケットデータユニット（ＰＤＵ）サイズがサポートされる場合の、ダウンリンクデータの無線ネットワークコントローラ（ＲＮＣ）／Ｎｏｄｅ Ｂフロー制御のための方法であって、バイト単位のクレジットアロケーションを通知するステップを含む方法。

９０．バイト単位のクレジットアロケーションを通知するステップが、クレジットのバイト数を指定する情報をフレームに追加するステップを含む、実施形態８９に記載の方法。

９１．クレジットのＰＤＵ数を指定する情報をフレームから省略するステップを含む、実施形態８９〜９０のいずれかに記載の方法。

９２．ＲＬＣエンティティによって実行される実施形態８９〜９１のいずれかに記載の方法。

９３．実施形態９２のＲＬＣエンティティを含むＮｏｄｅ Ｂ。

９４．フレキシブル無線リンク制御（ＲＬＣ）パケットデータユニット（ＰＤＵ）サイズがサポートされる場合の、ダウンリンクデータのＲＮＣ／Ｎｏｄｅ Ｂフロー制御のための方法であって、バイト単位のクレジットアロケーションを受信するステップを含む方法。

９５．バイト単位のクレジットアロケーションを受信するステップが、クレジットのバイト数を指定する情報を含むフレームを受信するステップを含む、実施形態９４に記載の方法。

９６．バイト単位のＰＤＵの最大サイズを保存するステップをさらに含む実施形態９４〜９５のいずれかに記載の方法。

９７．バイト単位のクレジットアロケーションを受信するステップが、クレジットのＰＤＵの数を指定する情報を含むフレームを受信するステップを含む、実施形態９６に記載の方法。

９８．クレジットのＰＤＵの数をバイト単位のＰＤＵの最大サイズで乗算するステップをさらに含む実施形態９７に記載の方法。

９９．ＰＤＵ ＳＮの、バイト単位の関連する長さへのマッピングを保存するステップをさらに含む実施形態９４〜９８のいずれかに記載の方法。

１００．受信クレジットアロケーションを超過することなく、ＰＤＵを送信するステップをさらに含む実施形態９９に記載の方法。

１０１．ＲＬＣエンティティによって実行される実施形態９４〜１００のいずれかに記載の方法。

１０２．実施形態１０１のＲＬＣエンティティを含む無線ネットワークコントローラ（ＲＮＣ）。

１０３．サービスＲＮＣ（ＳＲＮＣ）として構成される実施形態１０２のＲＮＣ。

１０４．ドリフトＲＮＣ（ＤＲＮＣ）として構成される実施形態１０２のＲＮＣ。

特徴および要素が特定の組合せで上では説明されたが、各特徴または要素は、他の特徴および要素を伴わずに単独で使用することができ、または他の特徴および要素を伴うもしくは伴わない様々な組合せで使用することができる。本明細書で提供された方法またはフロー図は、汎用コンピュータまたはプロセッサによる実行のための、コンピュータ読取り可能記憶媒体内に含まれるコンピュータプログラム、ソフトウェア、またはファームウェアで実施することができる。コンピュータ読取り可能記憶媒体の例は、リードオンリメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよび着脱可能ディスクなどの磁気媒体、光磁気媒体、ならびにＣＤ−ＲＯＭディスクおよびデジタル多用途ディスク（ＤＶＤ）などの光媒体を含む。

適切なプロセッサは、一例として、汎用プロセッサ、専用プロセッサ、従来型プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと連携する１つもしくは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、他の任意のタイプの集積回路（ＩＣ）、および／または状態マシーンを含む。

ソフトウェアと連携するプロセッサは、無線送受信ユニット（ＷＴＲＵ）、ユーザ機器（ＵＥ）、端末、基地局、無線ネットワークコントローラ（ＲＮＣ）、または任意のホストコンピュータで使用される無線周波トランシーバを実施するために使用することができる。ＷＴＲＵは、カメラ、ビデオカメラモジュール、ビデオフォン、スピーカフォン、バイブレーションデバイス、スピーカ、マイクロフォン、テレビトランシーバ、ハンズフリーヘッドセット、キーボード、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）ラジオユニット、液晶表示（ＬＣＤ）ディスプレイユニット、有機発光ダイオード（ＯＬＥＤ）ディスプレイユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ、および／または任意の無線ローカルエリアネットワーク（ＷＬＡＮ）もしくは超広帯域（ＵＷＢ）モジュールなど、ハードウェアおよび／またはソフトウェアで実施されるモジュールと併せて使用することができる。

Claims (10)

1. フレキシブルパケットデータユニットサイズをサポートするよう構成された送信エンティティからの送信されたバイト数と関連付けられたカウントを維持するカウントメカニズムを維持するステップと、
   前記カウントがＰｏｌｌ＿Ｂｙｔｅｓ値以上であるか否かを決定するステップと、
   前記カウントが、前記Ｐｏｌｌ＿Ｂｙｔｅｓ値以上であると決定された条件で、前記送信エンティティからの送信のためのパケットデータユニットがポーリング（ｐｏｌｌ）を含むように構成するステップと
   を備えることを特徴とするポーリングのための方法。
2. 前記パケットデータユニットは、前記パケットデータユニットの中でポーリングビットを設定することによって構成されることを特徴とする請求項１に記載の方法。
3. 前記パケットデータユニットは、確認（Ａｃｋｎｏｗｌｅｄｇｅ）モードデータパケットデータユニットであることを特徴とする請求項１に記載の方法。
4. 前記カウントは、元の送信の中で送信されたパケットデータユニットを含むことを特徴とする請求項１に記載の方法。
5. 前記カウントは、元の送信の中で送信されたパケットデータユニットおよび再送信の中で送信されたパケットデータユニットを含むことを特徴とする請求項１に記載の方法。
6. フレキシブルパケットデータユニットサイズをサポートするよう構成された送信エンティティにおいて、
   送信されたバイト数と関連付けられたカウントをストアするよう構成されたメモリと、
   前記カウントがＰｏｌｌ＿Ｂｙｔｅｓ値以上であるかどう否かを決定し、および、
   前記カウントが、前記Ｐｏｌｌ＿Ｂｙｔｅｓ値以上であると決定された条件で、前記送信エンティティからの送信のためのパケットデータユニットがポーリング（ｐｏｌｌ）を含むように構成するように構成されたプロセッサと
   を備えたことを特徴とする送信エンティティ。
7. 前記パケットデータユニットは、前記パケットデータユニットの中でポーリングビットを設定することによって構成されることを特徴とする請求項６に記載の送信エンティティ。
8. 前記パケットデータユニットは、確認（Ａｃｋｎｏｗｌｅｄｇｅ）モードデータパケットデータユニットであることを特徴とする請求項６に記載の送信エンティティ。
9. 前記カウントは、元の送信の中で送信されたパケットデータユニットを含むことを特徴とする請求項６に記載の送信エンティティ。
10. 前記カウントは、元の送信の中で送信されたパケットデータユニットおよび再送信の中で送信されたパケットデータユニットを含むことを特徴とする請求項６に記載の送信エンティティ。

Images