JP5258791B2

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

Info

Publication number: JP5258791B2
Application number: JP2009548335A
Authority: JP
Inventors: パニダイアナ; エム．ミラージェイムズ; マリニエールポール; イー．テリーステファン; エー．グランディスディア
Original assignee: インターデイジタルテクノロジーコーポレーション
Priority date: 2007-02-02
Filing date: 2008-02-04
Publication date: 2013-08-07
Anticipated expiration: 2028-02-04
Also published as: US8498284B2; CA2677112C; AR065158A1; TWI499259B; JP2014187709A; AU2008214378A1; KR20090121299A; CN101675627A; US20170094560A1; EP2429235B1; US9554398B2; TW200835272A; EP2429235A1; US20130279490A1; US9936423B2; JP5555791B2; KR20140015620A; IL200075A0; US20080212561A1; KR20130044362A

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

無線リンク制御（ＲＬＣ）動作を強化する方法において、
容量割り当てがバイトアロケーションであることを示している制御フレームを受信するステップと、
プロセッサを用いて、クレジットに最大ＰＤＵサイズを乗算することによって、容量割り当てを決定するステップと
を備えることを特徴とする方法。
前記クレジットは、ＰＤＵの数であることを特徴とする請求項１に記載の方法。
前記容量割り当ては、オクテットの数として計算されることを特徴とする請求項１に記載の方法。
クレジットのバイト数を規定する情報を含むフレームを受信するステップをさらに備えることを特徴とする請求項１に記載の方法。
ＰＤＵシーケンス番号（ＳＮ）の、関連付けられたバイト単位の長さへのマッピングをストアするステップと、
前記クレジットのバイト数を越えることなしに、ＰＤＵを送信するステップと
をさらに備えることを特徴とする請求項４に記載の方法。
前記決定するステップは、ＲＮＣによって実行されることを特徴とする請求項１に記載の方法。
前記ＲＮＣは、サービングＲＮＣ（ＳＲＮＣ）であることを特徴とする請求項６に記載の方法。
前記ＲＮＣは、制御ＲＮＣ（ＣＲＮＣ）であることを特徴とする請求項６に記載の方法。
フレキシブルパケットデータユニット（ＰＤＵ）サイズが設定されたことを決定するステップをさらに備えることを特徴とする請求項１に記載の方法。
容量割り当てがバイトアロケーションであることを示している制御フレームを受信し、および
クレジットに最大ＰＤＵサイズを乗算することによって、容量割り当てを決定するよう構成されたプロセッサ
を備えたことを特徴とするネットワークエンティティ。
前記クレジットは、ＰＤＵの数であることを特徴とする請求項１０に記載のネットワークエンティティ。
前記容量割り当ては、オクテットの数として計算されることを特徴とする請求項１０に記載のネットワークエンティティ。
前記プロセッサは、クレジットのバイト数を規定する情報を含むフレームを受信するようさらに構成されていることを特徴とする請求項１０に記載のネットワークエンティティ。
前記プロセッサは、
ＰＤＵシーケンス番号（ＳＮ）の関連付けられたバイト単位の長さへのマッピングをストアし、および、
クレジットのバイト数を越えることなしに、ＰＤＵを送信する
ようさらに構成されていることを特徴とする請求項１３に記載のネットワークエンティティ。
前記決定することは、ＲＮＣによって実行されることを特徴とする請求項１０に記載のネットワークエンティティ。
前記ＲＮＣは、サービングＲＮＣ（ＳＲＮＣ）であることを特徴とする請求項１５に記載のネットワークエンティティ。
前記ＲＮＣは、制御ＲＮＣ（ＣＲＮＣ）であることを特徴とする請求項１５に記載のネットワークエンティティ。
前記プロセッサは、フレキシブルパケットデータユニット（ＰＤＵ）サイズが設定されたことを決定するようさらに構成されていることを特徴とする請求項１０に記載のネットワークエンティティ。