(57)【要約】      （修正有）【課題】Ｅ−ＴＦＣ（拡張トランスポート・フォーマット・コンビネーション）選択の一部として、拡張ＭＡＣ（媒体アクセス制御）−ｅ  ＰＤＵ（パケット・データ・ユニット）を論理チャネルからのデータで満たすための技術及び可変長のヘッダーにより非スケジュール・データ・フローのＧＢＲ（保証されたビット・レート）を維持するための技術を提供する。【解決手段】Ｅ−ＴＦＣ選択アルゴリズムは、ＭＡＣレイヤからＲＬＣ（無線リンク制御）レイヤへの単一の要求を使用して、拡張ＭＡＣ−ｅ  ＰＤＵを作成するために、ある論理チャネルについて、それが送信することができるビット数を要求する。ＭＡＣエンティティは、ＲＬＣエンティティに対する複数の要求を実行する。ＭＡＣエンティティは、ＲＬＣエンティティに対して、セットサイズの１つ又は複数の拡張ＭＡＣ−ｅ  ＰＤＵを作成するよう単一の要求を行う。【選択図】図３Ａ
2015213368.tif 000002
【特許請求の範囲】
【請求項１】
拡張トランスポートフォーマットコンビネーション（Ｅ−ＴＦＣ）選択に関連付けられた拡張媒体アクセス制御（ＭＡＣ−ｅ）パケットデータユニット（ＰＤＵ）を作成するための方法であって、
第１の論理チャネルに関連付けられた第１の無線リンク制御（ＲＬＣ）ＰＤＵのセグメントが送信に使用可能であることを決定するステップであって、前記セグメントは前の送信から残存している、ステップと、
前記セグメントおよび対応するヘッダーのサイズが決定されたサイズを超えないという条件で、前記セグメントおよび前記対応するヘッダーを前記拡張ＭＡＣ−ｅ  ＰＤＵに含めるステップと、
前記セグメントおよび前記対応するヘッダーのサイズが前記決定されたサイズを超えるという条件で、前記セグメントを第１のサブセグメントおよび第２のサブセグメントに再セグメント化し、前記第１のサブセグメントおよび前記対応するヘッダーを前記拡張ＭＡＣ−ｅ  ＰＤＵに含め、および、次の送信のために前記第２のサブセグメントを格納するステップと、
前記拡張ＭＡＣ−ｅ  ＰＤＵを送信するステップと
を含むことを特徴とする方法。
【請求項２】
第２のＲＬＣ  ＰＤＵおよび対応するヘッダーが前記拡張ＭＡＣ−ｅ  ＰＤＵに含まれる、および、前記第２のＲＬＣ  ＰＤＵおよび前記対応するヘッダーのサイズが前記決定されたサイズを超えるという条件で、
前記第２のＲＬＣ  ＰＤＵを第１のセグメントおよび第２のセグメントに分けるステップと、
前記第１のセグメントおよび対応するヘッダーを前記拡張ＭＡＣ−ｅ  ＰＤＵに含め、および、次の送信のために前記残存している第２のセグメントを格納するステップと
をさらに含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記第２のＲＬＣ  ＰＤＵは、前記第１の論理チャネルに関連付けられることを特徴とする請求項２に記載の方法。
【請求項４】
前記決定されたサイズは、残余使用可能ペイロードまたは残余許可ペイロードの最小値であることを特徴とする請求項２に記載の方法。
【請求項５】
前記第１の論理チャネルは、最も優先順位の高い論理チャネルであることを特徴とする請求項１に記載の方法。
【請求項６】
前記第２のＲＬＣ  ＰＤＵおよび前記対応するヘッダーは、前記拡張ＭＡＣ−ｅ  ＰＤＵに含まれることを特徴とする請求項２に記載の方法。
【請求項７】
無線送受信ユニット（ＷＴＲＵ）であって、少なくとも、
第１の論理チャネルに関連付けられた第１の無線リンク制御（ＲＬＣ）パケットデータユニット（ＰＤＵ）のセグメントが送信に使用可能であることを決定し、前記セグメントは前の送信から残存しており、
前記セグメントおよび対応するヘッダーのサイズが決定されたサイズを超えないという条件で、前記セグメントおよび前記対応するヘッダーを拡張媒体アクセス制御（ＭＡＣ−ｅ）ＰＤＵに含め、
前記セグメントおよび前記対応するヘッダーのサイズが前記決定されたサイズを超えるという条件で、
前記セグメントを第１のサブセグメントおよび第２のサブセグメントに再セグメント化し、前記第１のサブセグメントおよび前記対応するヘッダーを前記拡張ＭＡＣ−ｅ  ＰＤＵに含め、および、次の送信のために前記残存している第２のサブセグメントを格納する
ように構成されたプロセッサと、
前記拡張ＭＡＣ−ｅ  ＰＤＵを送信するように構成された送信機と
を備えたことを特徴とするＷＴＲＵ。
【請求項８】
前記プロセッサは、
第２のＲＬＣ  ＰＤＵおよび対応するヘッダーが前記拡張ＭＡＣ−ｅ  ＰＤＵに含まれる、および、前記第２のＲＬＣ  ＰＤＵおよび前記対応するヘッダーのサイズが前記決定されたサイズを超えるという条件で、
前記第２のＲＬＣ  ＰＤＵを第１のセグメントおよび第２のセグメントに分け、
前記第１のセグメントおよび対応するヘッダーを前記拡張ＭＡＣ−ｅ  ＰＤＵに含め、および、次の送信のために前記残存している第２のセグメントを格納する
ようにさらに構成されたことを特徴とする請求項７に記載のＷＴＲＵ。
【請求項９】
前記第２のＲＬＣ  ＰＤＵは、前記第１の論理チャネルに関連付けられることを特徴とする請求項８に記載のＷＴＲＵ。
【請求項１０】
前記決定されたサイズは、残余使用可能ペイロードまたは残余許可ペイロードの最小値であることを特徴とする請求項８に記載のＷＴＲＵ。
【請求項１１】
前記第１の論理チャネルは、最も優先順位の高い論理チャネルであることを特徴とする請求項７に記載のＷＴＲＵ。
【請求項１２】
前記第２のＲＬＣ  ＰＤＵおよび前記対応するヘッダーは、前記拡張ＭＡＣ−ｅ  ＰＤＵに含まれることを特徴とする請求項８に記載のＷＴＲＵ。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、無線通信に関する。
【背景技術】
【０００２】
ＵＭＴＳ（ユニバーサル移動体通信システム：Universal Mobile Telecommunications Systems）技術に従う無線通信システムは、３Ｇ（第３世代）無線システムの一環として開発されており、３ＧＰＰ（第３世代パートナーシッププロジェクト：Third Generation Partnership Project）によって維持されている。図１に、現在の３ＧＰＰ仕様による一般のＵＭＴＳシステム・アーキテクチャが示されている。ＵＭＴＳネットワークアーキテクチャは、Ｉｕインターフェイスを介してＵＴＲＡＮ（ＵＭＴＳ地上無線アクセスネットワーク：UMTS Terrestrial Radio Access Network）に相互接続されているＣＮ（コアネットワーク：core network）を含む。ＵＴＲＡＮは、Ｕｕ無線インターフェイスを介して、３ＧＰＰ標準でＵＥ（ユーザ機器：user equipment）と呼ばれるＷＴＲＵ（無線送受信ユニット：wireless transmit/receive unit）を介してユーザに無線通信サービスを提供するように構成されている。ＵＭＴＳ標準で定義される、一般に使用されるエア・インターフェイスは、Ｗ−ＣＤＭＡ（広帯域符号分割多元接続：wideband code division multiple access）である。ＵＴＲＡＮは、１つまたは複数のＲＮＣ（無線ネットワーク・コントローラ：radio network controller）と、３ＧＰＰでＮｏｄｅＢと呼ばれる基地局とを有し、これらはまとめてＵＥとの無線通信のための地理的カバレージを提供する。ＵＬ（アップリンク：uplink）通信は、ＵＥからＮｏｄｅＢへの送信を指し、ＤＬ（ダウンリンク：downlink）通信は、ＮｏｄｅＢからＵＥへの送信を指す。１つまたは複数のＮｏｄｅＢは、Ｉｕｂインターフェイスを介して各ＲＮＣに接続され、ＵＴＲＡＮ内のＲＮＣは、Ｉｕｒインターフェイスを介して通信する。
【０００３】
ＨＳＵＰＡ（高速アップリンク・パケット・アクセス：high speed uplink packet access）についての３ＧＰＰ標準リリース６によれば、ＭＡＣレイヤは、より上位レイヤのデータをＭＡＣ−ｅ  ＰＤＵに多重化する。ＴＴＩ（送信時間間隔：transmission time interval）で、ＭＡＣレイヤは、Ｅ−ＤＰＤＣＨ（E-DCH（拡張専用チャネル：enhanced dedicated channel）（専用物理データ制御チャネル：dedicated physical data control channel）を介して送信されるように、１つのＭＡＣ−ｅ  ＰＤＵをＰＨＹレイヤに送信する。リンク・アダプテーションの一環として、ＭＡＣレイヤは、ＲＬＣ（無線リンク制御）論理チャネル優先順位、ＲＬＣバッファ占有率、物理チャネル状態、サービング許可（ｓｅｒｖｉｎｇ  ｇｒａｎｔ）、非サービング許可、電力制限、ＨＡＲＱ（ハイブリッド自動再送要求）プロファイル、および論理チャネル多重化に基づくＥ−ＴＦＣ（拡張トランスポート・フォーマット・コンビネーション）選択を行う。
【０００４】
Ｅ−ＴＦＣ選択機能の一部として、ＵＥは、最初に、送信すべきデータを有する最も高い優先順位の上位レイヤＭＡＣ−ｄフローを識別する。次いでＵＥは、このＭＡＣ−ｄフローと多重化することができ、その許可によって現在のＴＴＬで送信することができるＭＡＣ−ｄフローを識別する。選択されたＭＡＣ−ｄフローのＨＡＲＱプロファイルに基づいて、ＵＥは、送信に使用するための電力オフセットを識別する。この電力オフセットおよびＥ−ＴＦＣ制限手順に基づいて、ＭＡＣは、使用可能なサービングおよび／または非サービング許可を考慮に入れることなく、使用可能な電力のみに基づいて、今度の送信についてＵＥによって送信することができる、最大サポート・ペイロード(maximum supported payload)と呼ばれる、サポートされる最大のＭＡＣ−ｅ  ＰＤＵサイズまたはＥ−ＴＦＣを決定する。次いで、Ｅ−ＴＦＣ選択アルゴリズムは、サービング許可および選択された電力オフセットに基づいて送信することができる、スケジュール・ペイロード（scheduled payload）と呼ばれる最大データ量を決定する。非スケジュールフローの場合、Ｅ−ＴＦＣ選択アルゴリズムは、非スケジュール・ペイロードを決定するために、非スケジュール許可を考慮に入れる。総許可ペイロード（total granted payload）は、決定されたスケジュール・ペイロードおよび非スケジュール・ペイロードに等しく、ＵＥが、サービング許可および非スケジュール許可に基づいて送信することができるデータの量と定義される。しかし、ＵＥが電力を制限されているかもしれないという事実のため、ＵＥが送信することができる使用可能なデータ量（使用可能なペイロード）は、最大サポート・ペイロードと総許可ペイロードとの間の最小値に相当する。
【０００５】
使用可能なペイロードが決定されると、ＭＡＣレイヤは、優先順位順に現在のＴＴＩにおいて多重化することができるＭＡＣ−ｄフローに対応する論理チャネルからのデータを要求する。使用可能なペイロードに従ってＭＡＣ−ｅ  ＰＤＵを満たすためのすべてのデータが使用可能なとき、またはＲＬＣデータがそれ以上使用可能ではないとき、ＭＡＣ−ｅ  ＰＤＵは、利得係数である選択されたベータ係数でＥ−ＤＰＤＣＨを介して送信されるように、物理レイヤに送信される。
【０００６】
３ＧＰＰ標準リリース６によれば、ＡＭ（応答モード：acknowledged mode）のＲＬＣ（無線リンク制御：radio link control）レイヤは、固定されたＲＬＣ  ＰＤＵ（プロトコル・データ・ユニット：protocol data unit）サイズを使用して動作することしかできない。さらに、ＮｏｄｅＢにおけるＭＡＣ−ｈｓ（高速媒体アクセス制御：high-speed medium access control）エンティティおよびＵＥにおけるＭＡＣ−ｅ／ｅｓ（媒体アクセス制御：medium access control）エンティティは、上位レイヤからのＳＤＵ（サービス・データ・ユニット：service data unit）のセグメンテーションをサポートしない。これらの制限は、特にＨＳＰＡ（高速パケットアクセス：high speed packet access）がより高いデータレートに向かって進化するにつれて、性能の限界をもたらし得る。より高いデータレートに達し、プロトコル・オーバーヘッドおよびパディングを低減するために、３ＧＰＰリリース７のＬ２（レイヤ２）プロトコルにいくつかの新しい特徴が導入された。特に、ダウンリンクにおける柔軟なＲＬＣ  ＰＤＵサイズおよびＭＡＣセグメンテーションが導入された。しかし、３ＧＰＰリリース７におけるアップリンク操作では、対応するＬ２の強化は導入されなかった。
【０００７】
より最近では、アップリンクにおけるＬ２操作に強化を導入するためのＩｍｐｒｏｖｅｄ  Ｌ２  Ｕｐｌｉｎｋについて、新しい３ＧＰＰ作業項目が提案されている。Ｉｍｐｒｏｖｅｄ  Ｌ２  Ｕｐｌｉｎｋの目的の一部は、ＣＥＬＬ＿ＦＡＣＨアップリンク送信への潜在的な強化に応じて、柔軟なＲＬＣ  ＰＤＵサイズのサポートと、ＭＡＣ−ｄおよびＭＡＣ−ｃのＰＤＵを含む上位レイヤＰＤＵのＭＡＣセグメンテーションのサポートと、古いプロトコルフォーマットと新しいプロトコルフォーマットとの間のスムーズな遷移と、ＣＥＬＬ＿ＤＣＨ、ＣＥＬＬ＿ＦＡＣＨ、ＣＥＬＬ＿ＰＣＨおよびＵＲＡ＿ＰＣＨの状態間のシームレスな状態遷移のサポートとを含む。
【０００８】
現在のＥ−ＴＦＣ選択アルゴリズムは、リリース７またはそれ以前、および固定のＲＬＣ  ＰＤＵサイズを必要とする現在のＥ−ＤＣＨ（拡張専用チャネル：enhanced dedicated channel）機能を含む、現在の３ＧＰＰ標準リリースのために設計されている。リリース７またはそれ以前の現在のＥ−ＴＦＣ選択アルゴリズムは、提案されたＩｍｐｒｏｖｅｄ  Ｌａｙｅｒ２  Ｕｐｌｉｎｋの下で、ＭＡＣ−ｅ／ｅｓ  ＰＤＵの非効率な作成をもたらすことを理解されたい。というのは、現在のＥ−ＴＦＣ選択アルゴリズムは、論理チャネルごとの柔軟なＲＬＣ  ＰＤＵサイズ、ＲＬＣ  ＰＤＵのセグメンテーション、および拡張ＭＡＣ−ｅｓＰＤＵでのＲＬＣ  ＰＤＵの量に基づく柔軟なヘッダー・フォーマット・サイズを考慮に入れるように設計されていないからである。
【発明の概要】
【発明が解決しようとする課題】
【０００９】
したがって、最適なＲＬＣ  ＰＤＵサイズのＭＡＣ−ｅ  ＰＤＵを作成するときに、柔軟なＲＬＣ  ＰＤＵサイズ、ＲＬＣ  ＰＤＵのセグメンテーション、および柔軟なヘッダー・フォーマット・サイズを含む追加機能を考慮に入れる新しいＥ−ＴＦＣ選択機能が望まれる。
【課題を解決するための手段】
【００１０】
アップリンク無線通信のＥ−ＴＦＣ（拡張トランスポート・フォーマット・コンビネーション：enhanced transport format combination）のための方法および装置が開示される。Ｅ−ＴＦＣ選択のための提案された技術は、柔軟なＲＬＣ（無線リンク制御：radio link control）ＰＤＵ（パケット・データ・ユニット：packet data unit）サイズ、およびＭＡＣ−ｄ  ＰＤＵのＭＡＣ（媒体アクセス制御：media access control）レイヤのセグメンテーションをサポートする。したがって、ＲＬＣ  ＰＤＵは、選択されたＥ−ＴＦＣトランスポート・ブロック・サイズに適切に収まる(フィットする)ように作成される。選択されたＥ−ＴＦＣに基づいて、ＭＡＣエンティティおよびＲＬＣエンティティは、送信すべきデータ量を最大にし、ＲＬＣプロトコルとＭＡＣプロトコルとの間のオーバーヘッドの量を低減するために、ＴＴＩ（送信時間間隔：transmission time interval）ベースでＲＬＣ  ＰＤＵサイズを作成するように連携する。
【００１１】
Ｅ−ＴＦＣ選択の一部として拡張ＭＡＣ−ｅ  ＰＤＵ（パケット・データ・ユニット：packet data unit）を論理チャネルからのデータで満たすための方法が提供される。一実施形態において、Ｅ−ＴＦＣ選択アルゴリズムは、ＭＡＣレイヤからＲＬＣレイヤへの単一の要求を使用して、場合によっては異なるサイズの１つまたは複数のＰＤＵを作成するために、ある論理チャネルについて、送信することができるビット数を要求する。別の実施形態において、ＭＡＣエンティティは、ＲＬＣエンティティに対する複数の要求を実行する。別の実施形態において、ＭＡＣエンティティは、ＲＬＣエンティティに対して、セットサイズの１つまたは複数のＰＤＵを作成するよう単一の要求を行う。また、可変長ヘッダーにより非スケジュール・データ・フローのＧＢＲ（保証されたビット・レート：guaranteed bit rate）を維持するための技術も提供される。
【００１２】
添付の図面と共に例として示される以下の説明から、より詳しい理解を得ることができよう。
【図面の簡単な説明】
【００１３】
【図１】従来のＵＭＴＳ（ユニバーサル移動体通信システム：Universal Mobile Telecommunications System）ネットワークのシステム・アーキテクチャの概要を示す図である。
【図２】本明細書の教示による拡張ＭＡＣ−ｅ／ｅｓエンティティを示すブロック図である。
【図３Ａ】一実施形態に従ってＥ−ＴＦＣ選択の一部として拡張ＭＡＣ−ｅ  ＰＤＵ（パケット・データ・ユニット：packet data unit）を論理チャネルからのデータで満たすための手順を示すフロー図である。
【図３Ｂ】一実施形態に従ってＥ−ＴＦＣ選択の一部として拡張ＭＡＣ−ｅ  ＰＤＵ（パケット・データ・ユニット）を論理チャネルからのデータで満たすための手順を示すフロー図である。
【図４】別の実施形態に従ってＥ−ＴＦＣ選択の一部として拡張ＭＡＣ−ｅ  ＰＤＵを論理チャネルからのデータで満たすための手順を示すフロー図である。
【図５】別の実施形態に従ってＥ−ＴＦＣ選択の一部として拡張ＭＡＣ−ｅ  ＰＤＵを論理チャネルからのデータで満たすための手順を示すフロー図である。
【図６】別の実施形態に従ってＥ−ＴＦＣ選択の一部として拡張ＭＡＣ−ｅ  ＰＤＵを論理チャネルからのデータで満たすための簡略化された手順を示すフロー図である。
【発明を実施するための形態】
【００１４】
以下で言及するとき、「ＷＴＲＵ（無線送受信ユニット：wireless transmit/receive unit）」という用語は、それだけには限定されないが、ＵＥ（ユーザ機器：user equipment）、移動局、固定式または携帯式の加入者ユニット、ページャ、セルラー電話、ＰＤＡ（個人用携帯型情報端末：personal digital assistant）、コンピュータ、または無線環境で動作することができる他の任意のタイプのユーザ装置を含む。以下で言及するとき、「基地局」という用語は、それだけに限定されないが、Ｎｏｄｅ−Ｂ、サイトコントローラ、ＡＰ（アクセスポイント：access point）、または無線環境で動作することができる他の任意のタイプのインターフェイス装置を含む。
【００１５】
提案された３ＧＰＰのＩｍｐｒｏｖｅｄ  Ｌ２（Ｌａｙｅｒ２）  Ｕｐｌｉｎｋ作業項目の一部として、レイヤ２プロトコルに追加された新しい機能を考慮に入れる効率的なＥ−ＴＦＣ（拡張トランスポート・フォーマット・コンビネーション：enhanced transport format combination）選択アルゴリズムが提供される。Ｅ−ＴＦＣ選択のための提案された実施形態では、拡張されたＭＡＣ−ｅ  ＰＤＵ（パケット・データ・ユニット：packet data unit）を、１つまたは複数のＲＬＣ（無線リンク制御：radio link control）論理チャネルまたはＭＡＣ−ｄのデータ・フローおよびＭＡＣ−ｃのデータ・フローからのデータで満たす必要があるとき、ＷＴＲＵがたどり得るイベントのシーケンスについて説明する。Ｅ−ＴＦＣ選択のための提案された実施形態は、個々に、または任意の組み合わせで使用することができる。Ｅ−ＴＦＣ選択は、アップリンク通信についてＷＴＲＵまたはＵＥによって実行されるものとして説明されているが、本明細書の教示は、ダウンリンク通信およびアップリンク通信の両方に適用することができ、また基地局、ＮｏｄｅＢ、ＮｏｄｅＢとＲＮＣ（無線ネットワーク・コントローラ：radio network controller）との併用によって実行され得る。
【００１６】
本明細書では、拡張ＭＡＣ−ｅ、拡張ＭＡＣ−ｅｓ、および拡張ＭＡＣ−ｅ／ｅｓは、それだけには限定されないが、ＭＡＣ−ｅ、ＭＡＣ−ｅｓ、およびＭＡＣ−ｅ／ｅｓを含む、ＨＳＰＡ（高速パケットアクセス：high speed packet access）における既存のＭＡＣ（媒体アクセス制御：medium access control）プロトコルの拡張バージョンを表すために使用される。残余使用可能ペイロード（Remaining Available Payload）は、サービング許可および非サービング許可、使用可能な電力、選択された電力オフセット、およびスケジュール情報を含む、使用可能な許可のために送信することができる最大データ量を指す。残余許可ペイロード（Remaining Granted Payload）は、非スケジュールのＭＡＣ−ｄフローが処理されているときの残余非スケジュール・ペイロード、およびスケジュールＭＡＣ−ｄフローの残余スケジュール・ペイロードを指す。本明細書では、関数ＭＩＮ（Ａ，Ｂ）は、ビット数に関して、パラメータＡおよびＢの中から最小値を戻す。
【００１７】
上位レイヤＰＤＵは、ＭＡＣ−ｄ  ＰＤＵ、ＭＡＣ−ｃ  ＰＤＵ、またはＲＬＣ  ＰＤＵを指す。ＭＡＣ−ｄ、ＭＡＣ−ｃおよびＲＬＣ  ＰＤＵは、本明細書で提案された実施形態において同じように扱われ得る。ＲＬＣ  ＰＤＵは、専用の論理チャネルに属し、ＭＡＣ−ｄエンティティに転送される。次いでＭＡＣ−ｄエンティティは、データを拡張ＭＡＣ−ｅｓエンティティに転送する。ＭＡＣ−ｄの出力は、ＭＡＣ−ｄ  ＰＤＵと呼ぶ。ＭＡＣ−ｄ  ＰＤＵは、ＤＣＣＨ（専用制御チャネル：dedicated control channel）またはＤＴＣＨ（専用トラフィックチャネル：dedicated traffic channel）論理チャネルから受信されたデータを含み、ＭＡＣ−ｃ  ＰＤＵは、ＣＣＣＨ（共通制御チャネル：common control channel）など、共通チャネルから受信されたデータを含む。便宜上、本明細書の実施形態の一部は、ＲＬＣ  ＰＤＵを参照して記載され得るが、実施形態は、ＭＡＣ−ｄまたはＭＡＣ−ｃ  ＰＤＵに等しく適用可能であり、ＲＬＣ、ＭＡＣ−ｄおよびＭＡＣ−ｃ  ＰＤＵについて同じ機能を有する。
【００１８】
図２は、本明細書の教示による拡張ＭＡＣ−ｅ／ｅｓエンティティ２００のブロック図を示す。拡張ＭＡＣ−ｅ／ｅｓエンティティ２００は、ＭＡＣ−ｄ、ＭＡＣ−ｃおよびＲＬＣ（無線リンク制御）エンティティを含む、上位レイヤ・エンティティからの論理チャネルデータを、拡張ＭＡＣ−ｅ  ＰＤＵに多重化し、それらをＴＢ（トランスポート・ブロック：transport block）の形でＰＨＹ（物理）レイヤ・エンティティに提供する。拡張ＭＡＣ−ｅ／ｅｓエンティティ２１０は、以下のエンティティ、すなわち、ＨＡＲＱ（ハイブリッド自動再送要求：hybrid automatic repeat request）エンティティ２２２、セグメンテーション・バッファ２１６を含み得るセグメンテーション・エンティティ２１４、マルチプレクサおよびＴＳＮ設定エンティティ２１８、スケジュール・エンティティ２２０、およびＥ−ＴＦＣ（拡張トランスポート・フォーマット・コンビネーション）選択エンティティ２１２を含み得る。
【００１９】
ＨＡＲＱエンティティ２２２は、拡張ＭＡＣ−ｅペイロードを格納し、再送することを含む、誤り訂正のためのＨＡＲＱプロトコルに関係するＭＡＣレイヤ機能を扱う責任がある。セグメンテーション・エンティティ２１４は、大きすぎて拡張ＭＡＣ−ｅ  ＰＤＵに収まらないときに上位レイヤＰＤＵをセグメント化し、そのセグメントをマルチプレクサ２１８に送信する。残りのセグメントは、セグメンテーション・バッファ２１６に格納される。マルチプレクサおよびＴＳＮ設定エンティティ２１８は、セグメント化された、または完全な上位レイヤＰＤＵを含む複数の拡張ＭＡＣ−ｅｓ  ＳＤＵを連結して、拡張ＭＡＣ−ｅｓ  ＰＤＵにする責任がある。また、マルチプレクサおよびＴＳＮ設定エンティティ２１８は、多重化された論理チャネルからの複数の拡張ＭＡＣ−ｅｓ  ＰＤＵを拡張ＭＡＣ−ｅ  ＰＤＵに多重化して、Ｅ−ＴＦＣ選択エンティティ２１２によって指示されるように、次のＴＴＩ（送信時間間隔）で送信するためにＰＨＹレイヤに提供する。スケジュール・エンティティ２２０は、関連のアップリンク・シグナリングをルーティングする責任がある。Ｅ−ＴＦＣ選択エンティティ２１２は、スケジュール情報、相対的許可（ＲＧ：relative grant）、絶対的許可（ＡＧ：absolute grant）、およびサービング許可（ＳＧ：serving grant）、並びに使用可能な電力リソースに基づいて、どれだけのデータをＴＴＩで送信することができるかを決定し、使用可能な電力に基づいて、ＵＥが送信することができる最大使用可能データを決定するために使用されるＥ−ＴＦＣ制限を決定する。Ｅ−ＴＦＣ選択エンティティ２１２は、マルチプレクサ２１８の制御も行う。
【００２０】
一実施形態において、Ｅ−ＴＦＣ選択アルゴリズムは、ＭＡＣレイヤからＲＬＣレイヤへの単一の要求を使用する。拡張ＭＡＣエンティティは、単一の要求で、論理チャネルについて、自分が送信することができるビット数をその論理チャネルに要求する。示されたビット数、使用可能なデータビット数、並びに新しいおよび再送されたデータビット数に基づいて、ＲＬＣエンティティは、拡張ＭＡＣ−ｅ  ＰＤＵに収まるように、ＲＬＣ  ＰＤＵを作成し、または配信する。Ｅ−ＴＦＣ制限、スケジュール許可、すべてのＭＡＣ−ｄフローの非スケジュール許可、およびスケジュール情報に基づいて、ＷＴＲＵは、残余使用可能ペイロードと呼ばれる、送信することができる最大データ量を決定する。拡張ＭＡＣ−ｅ  ＰＤＵを論理チャネルビットで満たすとき、残余使用可能ペイロードは、スケジュール済み送信の量子化損失（quantization loss）の原因となり得る。いったん残余使用可能ペイロードが計算されると、スケジュール情報（Scheduling Information）を送信する必要がある場合、そのスケジュール情報は、残余使用可能ペイロードから差し引かれる。
【００２１】
Ｅ−ＴＦＣ選択アルゴリズムは、論理チャネルごとに、単体で、または組み合わせで使用され得る以下のルールのうちの１つまたは複数によって拡張ＭＡＣ−ｅ  ＰＤＵを作成する。１つのルールによれば、セグメンテーション・バッファにおけるビットは、処理中の論理チャネルの他のＲＬＣ  ＰＤＵより高い送信優先順位を有する。別のルールによれば、セグメンテーション・エンティティにおけるあるセグメントがその論理チャネルについて送信される最大データ量より大きい場合、ＷＴＲＵは、ＭＡＣセグメントを再セグメント化し、拡張ＭＡＣ−ｅ／ｅｓヘッダーを考慮に入れて、拡張ＭＡＣ−ｅ  ＰＤＵで可能な最大量のデータを送信する。
【００２２】
別のルールによれば、任意の残りのセグメントは、セグメンテーション・バッファに格納される。別のルールによれば、セグメンテーション・バッファにセグメントがない場合、またはセグメントが追加された後に拡張ＭＡＣ−ｅ  ＰＤＵに依然として使用可能なスペースがある場合、ＭＡＣエンティティは、（残余使用可能ペイロードおよび残余許可ペイロード）−（セグメントが追加された場合にそのセグメントを送信するために必要な任意のＭＡＣヘッダービットを含む追加された任意のセグメントのサイズ）によって決定されるように、自分が送信することができる最大数のビットを論理チャネルに要求することができる。次いで、ＲＬＣエンティティは、最適に選択されたサイズの１つまたは複数の新しいＲＬＣ  ＰＤＵおよび／または１つまたは複数の再送されたＲＬＣ  ＰＤＵを要求されたビット数まで、またはそれを超える数、提供し得る。
【００２３】
別のルールによれば、ＲＬＣ  ＭＡＣ−ｄまたはＭＡＣ−ｃ  ＰＤＵであり得る上位レイヤのＰＤＵは、提供されるＲＬＣ  ＰＤＵの最後がその論理チャネルまたはＭＡＣ−ｄフローの最大許容または使用可能数を超えるとき、ＭＡＣヘッダーに必要なスペースを考慮に入れながら、セグメンテーション・エンティティによってセグメント化され得る。
【００２４】
別のルールによれば、送信すべきデータの量および対応する拡張ＭＡＣ−ｅ／ｅｓヘッダーは、許可および／またはＥ−ＴＦＣ制限によって示されるように、その論理チャネルについて、使用可能な残余ペイロードまたは使用可能な許可ペイロードであるビットの最大許容数を超えなくてよい。拡張ＭＡＣ−ｅ／ｅｓヘッダーが柔軟であり、拡張ＭＡＣ−ｅ／ｅｓ  ＳＤＵ（サービス・データ・ユニット）におけるＲＬＣ  ＰＤＵの数に依存するという事実により、Ｅ−ＴＦＣ選択エンティティは、任意の追加の拡張ＭＡＣ−ｅｓ  ＳＤＵで追加される追加ヘッダーも考慮に入れる必要がある。これは、拡張ＭＡＣ−ｅ／ｅｓエンティティによって実行されるＲＬＣに対する最初の要求で考慮に入れることができる。例えば、拡張ＭＡＣ−ｅ／ｅｓは、残余使用可能ビット量のために、Ｋ個のＲＬＣ  ＰＤＵが受信されることを想定し得る。したがって、拡張ＭＡＣ−ｅ／ｅｓは、以下の計算、すなわち、要求すべきビット数＝（送信することができる使用可能なビット）−Ｋ×（ＲＬＣ  ＰＤＵ当たりの追加のヘッダービット数）−（論理チャネルについての固定ヘッダービット数）に従って要求すべきビット数を計算することができる。あるいは、ＲＬＣエンティティは、作成された新しいＲＬＣ  ＰＤＵごとに要求される追加のヘッダービット数を考慮に入れることができ、ＭＡＣは、使用可能な量のビットを論理チャネルに要求するだけである。例えば、ＭＡＣの要求を受信した後、作成されたまたは送信された新しいＲＬＣ  ＰＤＵごとに、ＲＬＣエンティティは、追加のヘッダービットを、拡張ＭＡＣ−ｅ／ｅｓに転送する必要がある総残余ビットから差し引くことができる。
【００２５】
図３Ａおよび３Ｂは、一実施形態に従って、上記に列挙したルールによって、Ｅ−ＴＦＣ選択の一部として拡張ＭＡＣ−ｅ  ＰＤＵを論理チャネルからのデータで満たすための手順３００のフロー図を示す。図３Ａおよび３Ｂにおいて、ｈ１は、拡張ＭＡＣ−ｅｓ  ＰＤＵ当たり必要なヘッダービット数を指し、ｈ２は、拡張ＭＡＣ−ｅｓ  ＳＤＵ当たりの拡張ＭＡＣ−ｅヘッダーに必要なヘッダービット数を指す。
【００２６】
ステップ３０５で、各ＴＴＩにおいて、送信することができ、現在のＴＴＩにおける多重化制限を満たす各論理チャネルが優先順位順に評価される。ステップ３１０で、セグメンテーション・バッファが、送信すべきビットまたはセグメントを含むかどうかが決定される。セグメンテーション・バッファが送信すべきビットまたはセグメントを含む場合、ステップ３１５で、そのセグメントにおけるビット数＋対応する拡張ＭＡＣ−ｅ／ｅｓヘッダーのｈ１＋ｈ２ビットが、ＭＩＮ（残余使用可能ペイロード，残余許可ペイロード）より大きいかどうかが決定される。ステップ３１５が真である場合、ステップ３２０で、セグメントがさらにセグメント化されて、ＭＩＮ（残余使用可能ペイロード−（ｈ１＋ｈ２），残余許可ペイロード−（ｈ１＋ｈ２））に等しいいくつかのビットを含むサブセグメントを生成する。ステップ３２５で、サブセグメントおよび対応する拡張ＭＡＣ−ｅ／ｅｓヘッダーは、拡張ＭＡＣ−ｅ  ＰＤＵに追加され、追加されたビット数が、残余許可ペイロードおよび残余使用可能ペイロードから差し引かれる。追加されたビット数は、サブセグメントにおけるビット数＋ｈ１＋ｈ２に等しい。ステップ３２８で、拡張ＭＡＣ−ｅ  ＰＤＵにおいて使用可能なスペースがそれ以上ないと決定される、または残余使用可能ペイロードがゼロであると決定されると、手順３００が終了する。そうでない場合、手順３００は、ステップ３０５に戻って、次の論理チャネルについて、手順を繰り返す。
【００２７】
ステップ３１５で決定されるように、セグメントにおけるビット数＋ｈ１＋ｈ２がＭＩＮ（残余使用可能ペイロード，残余許可ペイロード）未満である場合、ステップ３３０で、セグメントおよび対応する拡張ＭＡＣ−ｅ／ｅｓヘッダーは、拡張ＭＡＣ−ｅ  ＰＤＵに追加され、追加されたビット数は、残余許可ペイロードおよび残余使用可能ペイロードから差し引かれる。追加されたビット数は、そのセグメントにおけるビット数＋ｈ１＋ｈ２である。ステップ３３５で、拡張ＭＡＣ−ｅ  ＰＤＵにおいて依然としてスペースがある場合、ＭＩＮ（残余使用可能ペイロード，残余許可ペイロード）ビットが、ＲＬＣ論理チャネルに要求される。さらに、残余許可ペイロードが０を超え、拡張ＭＡＣ−ｅ  ＰＤＵに依然としてスペースがあるとき、ＲＬＣ論理チャネルにビットを要求することができる。
【００２８】
任意選択で、拡張ＭＡＣ−ｅ／ｅｓヘッダーは、ＲＬＣエンティティに対する要求で、またはＲＬＣエンティティによって考慮に入れられ得る。より詳細には、ＲＬＣエンティティは、ＲＬＣ  ＰＤＵ当たり追加すべき拡張ＭＡＣ−ｅヘッダーのみを考慮に入れることができる。作成すべきＲＬＣ  ＰＤＵのサイズを計算するとき、ＵＥは、作成または再送するＲＬＣ  ＰＤＵごとに、拡張ＭＡＣ−ｅヘッダー部分、ｈ２を、要求された使用可能なビット数から差し引く。あるいは、ＲＬＣエンティティは、拡張ＭＡＣエンティティに送り出されたすべてのＲＬＣ  ＰＤＵについて、１つの拡張ＭＡＣ−ｅｓヘッダーが追加されることを考慮に入れることもできる。したがって、最初に、ＲＬＣエンティティは、要求されたビット数からｈ１を差し引き、次いで、ＲＬＣ  ＰＤＵを引き続き作成し、この場合、作成されたＲＬＣ  ＰＤＵ当たりのＮ個も考慮に入れる。しかし、ＲＬＣエンティティは、拡張ＭＡＣエンティティがその論理チャネルから追加すべきセグメントを有するかどうか、およびその論理チャネルの拡張ＭＡＣ−ｅｓヘッダー部分がすでに考慮に入れられているかどうかについてわからないので、論理チャネルにデータを要求する前に、拡張ＭＡＣエンティティが拡張ＭＡＣ−ｅｓヘッダーを考慮に入れることが好ましい。
【００２９】
ステップ３１０で、セグメンテーション・バッファにおいて送信すべきビットがないと決定された場合、ステップ３４０で、ＭＩＮ（残余許可ペイロード，残余使用可能ペイロード）に等しいいくつかのビットがＲＬＣ論理チャネルに要求される。任意選択で、その論理チャネルにデータを要求する前に、拡張ＭＡＣエンティティは、拡張ＭＡＣ−ｅｓヘッダーを、残余許可ペイロードおよび残余使用可能ペイロードから差し引くことができる。このオプションにより、ＲＬＣエンティティは、作成するＲＬＣ  ＰＤＵごとに拡張ＭＡＣ−ｅヘッダー部分を考慮に入れるだけでよい。拡張ＭＡＣエンティティが拡張ＭＡＣ−ｅｓヘッダー部分を差し引かない場合、ＲＬＣは、ＲＬＣ  ＰＤＵを生成するときにこの拡張ＭＡＣ−ｅｓヘッダー部分を考慮に入れることができる。
【００３０】
ステップ３３５および３４０のそれぞれの後、ステップ３５０で、要求されたＲＬＣ論理チャネルからＲＬＣ  ＰＤＵが提供されたかどうかが決定される。要求された論理チャネルからＲＬＣ  ＰＤＵが提供されていない場合、手順３００は、ステップ３０５に戻って、次の論理チャネルについて繰り返される。ＲＬＣ論理チャネルからビットが提供された場合、ステップ３５５で、配信されたＲＬＣ  ＰＤＵのサイズ＋ＭＡＣ−ｅヘッダー部分の合計が要求されたビット数を超えるかどうかが決定される。例えば、Ｎが１以上である場合、Ｎ個のＲＬＣ  ＰＤＵが配信されたとすると、追加すべき拡張ＭＡＣ−ｅヘッダー部分は、ビット数ｈ２のＮ倍に等しく、合計が、ＭＩＮ（残余許可ペイロード、残余使用可能ペイロード）に等しくなり得る要求されたビット数と比較される。ＲＬＣ論理チャネルから配信されたビット数＋拡張ＭＡＣ−ｅヘッダー部分のＮ×ｈ２ビットが、要求されたビット数未満である場合、ステップ３７０で、配信されたＲＬＣ  ＰＤＵからのビットが、ＭＩＮ（残余許可ペイロード，残余使用可能ペイロード）に等しいビット数まで、拡張ＭＡＣ−ｅ  ＰＤＵに追加される。
【００３１】
ＲＬＣから配信されたビット数＋拡張ＭＡＣ−ｅヘッダー部分が、要求されたビット数を超える場合、ステップ３６０で、要求されたビット数に従って１つまたは複数の完全なＲＬＣ  ＰＤＵが拡張ＭＡＣ−ｅ  ＰＤＵに追加され、次いで最後のＲＬＣ  ＰＤＵが、セグメント化され、残りの使用可能な、許可されるスペースに従って、拡張ＭＡＣ−ｅ  ＰＤＵに追加される。より詳細には、ＲＬＣ  ＰＤＵ＋ＲＬＣ  ＰＤＵ当たりの拡張ＭＡＣ−ｅヘッダー部分の合計が、要求されたビット数未満となるように、１つまたは複数の完全なＲＬＣ  ＰＤＵが追加される。セグメント化された最後のＲＬＣ  ＰＤＵのビットに関する残余使用可能スペースが、ｘ１およびｘ２の最小値に従って決定され、この場合、ｘ１＝残余許可ペイロード−（拡張ＭＡＣ−ｅに追加されたＲＬＣ  ＰＤＵのサイズ＋追加されたＲＬＣ  ＰＤＵ当たりのｈ２−追加すべきセグメントのｈ２）であり、ｘ２＝残余使用可能ペイロード−（拡張ＭＡＣ−ｅに追加されたＲＬＣ  ＰＤＵのサイズ＋追加されたＲＬＣ  ＰＤＵ当たりのｈ２−追加すべきセグメントのｈ２）である。ステップ３６５で、残りのセグメントまたはビットは、セグメンテーション・バッファに格納される。
【００３２】
ステップ３６５および３７０のそれぞれの後、関連のヘッダーからのビットを含む拡張ＭＡＣ−ｅ  ＰＤＵに追加された総ビット数が、ステップ３７５で、残余許可ペイロードおよび残余使用可能ペイロードから差し引かれる。ステップ３８０で、残余使用可能ペイロードが使い果たされた、または、現在のＴＴＩにおいて、データがそれ以上論理チャネルで使用できない場合、そのＴＴＩについて、手順３００は終了する。残余使用可能ペイロードがすべて使い果たされたわけではなく、データが依然として論理チャネルにおいて使用可能である場合、手順３００は、ステップ３０５に戻る。
【００３３】
図４は、別の実施形態に従って、Ｅ−ＴＦＣ選択の一部としてＭＡＣ−ｅ  ＰＤＵを論理チャネルからのデータで満たすための手順４００のフロー図を示す。手順４００によれば、ＭＡＣエンティティは、ＲＬＣエンティティに対する複数の要求を実行する。ＭＡＣエンティティは、選択されたＥ−ＴＦＣに基づいて、ＲＬＣ  ＰＤＵサイズを求める。要求されたＲＬＣ  ＰＤＵを受信した後、拡張ＭＡＣ−ｅ  ＰＤＵに依然として使用可能なスペースがある場合、ＭＡＣエンティティは、その論理チャネルについて送信することができるビット数に到達する、またはそれを超えるまで、追加のＲＬＣ  ＰＤＵを要求することができる。残余使用可能ペイロードおよび残余許可ペイロードは、上記と同じ定義を有する。さらに、変数ｈ１は、第１のＲＬＣ  ＰＤＵまたはそのセグメントを含むために必要な追加のヘッダービット数を指し、変数ｈ２は、同じ論理チャネルに属するその後のＲＬＣ  ＰＤＵまたはそのセグメントを含むために必要な追加のヘッダービット数を指す。変数Ｂは、論理チャネルに現在使用可能なビット数を指す。
【００３４】
図４を参照すると、ステップ４０５で、現在のＴＴＩにおいて送信することができる論理チャネルについて、その論理チャネルに現在使用可能な最大ビット数Ｂは、ＭＩＮ（残余使用可能ペイロード，残余許可ペイロード）に従って決定される。上述したように、残余使用可能ペイロードは、量子化損失を考慮に入れ得る。
【００３５】
ステップ４１０で、セグメンテーション・バッファが送信すべきビットまたはセグメントを含む場合、拡張ＭＡＣ−ｅ  ＰＤＵは、ヘッダーのための空きを残しながら、セグメンテーション・バッファからのできるだけ多くのビットで満たされ、セグメントがＢ−ｈ１を超える場合、セグメントは、拡張ＭＡＣ−ｅ  ＰＤＵに追加するためにセグメント化され、残りのビットは、セグメンテーション・バッファに格納される。ステップ４１５で、対応するヘッダーは、拡張ＭＡＣ−ｅ  ＰＤＵに挿入され、ヘッダーサイズｈ１を含む拡張ＭＡＣ−ｅ  ＰＤＵに追加されるビット数がＢから差し引かれる。
【００３６】
ステップ４２０で、Ｂが０より大きいかどうかが決定される。Ｂが０を超えない場合、ステップ４２８で、拡張ＭＡＣ−ｅ  ＰＤＵに使用可能なスペースがあるかどうかが決定される。拡張ＭＡＣ−ｅ  ＰＤＵにスペースがある場合、手順４００は、ステップ４０５に戻り、現在のＴＴＩにおいて送信することができる次の論理チャネルがある場合は、それについて繰り返される。拡張ＭＡＣ−ｅ  ＰＤＵにそれ以上スペースがない場合、手順４００は、終了する。
【００３７】
Ｂが０を超える場合、ステップ４２５において、データがセグメンテーション・バッファから含まれた場合（ステップ４１０）、ＲＬＣエンティティにサイズ（Ｂ−ｈ２）ビットのＲＬＣ  ＰＤＵが要求され、または、データがセグメンテーション・バッファから含まれなかった場合（ステップ４１０）、サイズ（Ｂ−ｈ１）のものが要求される。ステップ４３０で、ＲＬＣエンティティがＲＬＣ  ＰＤＵを配信したかどうかが決定される。ＲＬＣエンティティがＲＬＣ  ＰＤＵを配信しなかった場合、手順４００は、ステップ４０５に戻り、現在のＴＴＩにおいて送信することができる次の論理チャネルがある場合は、それについて繰り返される。
【００３８】
ＲＬＣエンティティがＲＬＣ  ＰＤＵを配信した場合、ステップ４３５で、ビット数に関して、配信されたＲＬＣ  ＰＤＵのサイズが要求されたＲＬＣ  ＰＤＵサイズ未満であるかどうかが決定される。配信されたＲＬＣ  ＰＤＵサイズが要求されたＲＬＣ  ＰＤＵサイズを超える場合、ステップ４５０で、ヘッダーのための空きを残しながら、拡張ＭＡＣ−ｅ  ＰＤＵが配信されたＲＬＣ  ＰＤＵからのできるだけ多くのビットで満たされる。配信されたＲＬＣ  ＰＤＵを拡張ＭＡＣ−ｅ  ＰＤＵに収まるようにセグメント化する必要がある場合、残りのビットは、セグメンテーション・バッファに格納される。その後、手順４００は、ステップ４０５に戻り、現在のＴＴＩにおいて送信することができる次の論理チャネルがある場合、それについて繰り返される。
【００３９】
配信されたＲＬＣ  ＰＤＵサイズが要求されたＲＬＣ  ＰＤＵサイズ未満である場合、ステップ４４０で、拡張ＭＡＣ−ｅ  ＰＤＵが配信されたＲＬＣ  ＰＤＵおよび対応するヘッダーで満たされ、ＲＬＣ  ＰＤＵのサイズおよびヘッダーが、Ｂから差し引かれる。その後、ＭＡＣ−ｅ  ＰＤＵにおける残りのスペースを満たすことを試みるために、手順４００は、ステップ４２０に戻る。
【００４０】
図５は、別の実施形態に従って、Ｅ−ＴＦＣ選択の一部としてＭＡＣ−ｅ  ＰＤＵを論理チャネルからのデータで満たすための手順５００のフロー図を示す。手順５００によれば、ＭＡＣエンティティは、ＲＬＣエンティティに対して、セットサイズの１つまたは複数のＰＤＵを作成するよう単一の要求を行う。ＲＬＣは、これらの入力を取得し、使用可能なデータ量および送信される最大データ量に基づいて、要求されたサイズのＮ個のＲＬＣ  ＰＤＵを送信する。ＲＬＣ  ＰＤＵが再送の必要がある場合、ＲＬＣは、再送されたＰＤＵを送信し、スペースが依然として使用可能である場合、要求されたサイズのＮ個の新しいＲＬＣ  ＰＤＵも送信する。拡張ＭＡＣ−ｅ／ｅｓエンティティに送信すべきＲＬＣ  ＰＤＵの数を選択するとき、ＲＬＣエンティティは、多くて１つの追加のＰＤＵを送信することができ、これは、送信すべき使用可能な最大サイズを超える。
【００４１】
図５を参照すると、ステップ５０５で、現在のＴＴＩにおいて送信することができる論理チャネルについて、その論理チャネルに現在使用可能な最大ビット数Ｂは、ＭＩＮ（残余使用可能ペイロード，残余許可ペイロード）に従って決定される。上述したように、残余使用可能ペイロードは、量子化損失を考慮に入れ得る。
【００４２】
ステップ５１０で、セグメンテーション・バッファが送信すべきビットまたはセグメントを含む場合、拡張ＭＡＣ−ｅ  ＰＤＵは、ヘッダーのための空きを残しながら、セグメンテーション・バッファからのできるだけ多くのビットで満たされ、セグメントがＢ−ｈ１を超える場合、セグメントは、拡張ＭＡＣ−ｅ  ＰＤＵに追加するためにセグメント化され、残りのビットは、セグメンテーション・バッファに格納される。ステップ５１５で、対応するヘッダーは、拡張ＭＡＣ−ｅ  ＰＤＵに挿入され、ヘッダーサイズｈ１を含む拡張ＭＡＣ−ｅ  ＰＤＵに追加されるビット数がＢから差し引かれる。
【００４３】
ステップ５２０で、Ｂが０より大きいかどうかが決定される。Ｂが０を超えない場合、ステップ５２８で、拡張ＭＡＣ−ｅ  ＰＤＵに使用可能なスペースがあるかどうかが決定される。拡張ＭＡＣ−ｅ  ＰＤＵにスペースがある場合、手順５００は、ステップ５０５に戻り、現在のＴＴＩにおいて送信することができる次の論理チャネルがある場合は、それについて繰り返される。拡張ＭＡＣ−ｅ  ＰＤＵにそれ以上スペースがない場合、手順５００は、終了する。
【００４４】
Ｂが０を超える場合、ステップ５２５で、データがセグメンテーション・バッファから含まれた場合（ステップ５１０）、ＲＬＣエンティティにサイズ（Ｂ−ｈ２）ビットのＲＬＣ  ＰＤＵが要求され、データがセグメンテーション・バッファから含まれなかった場合（ステップ５１０）、サイズ（Ｂ−ｈ１）のものが要求され、（Ｂ−ｈ２）または（Ｂ−ｈ１）が最大許容ＲＬＣ  ＰＤＵサイズを超える場合、最大ＲＬＣ  ＰＤＵサイズのＰＤＵが要求され、ＲＬＣエンティティに、（Ｂ−ｈ２またはｈ１）／（最大ＲＬＣ  ＰＤＵサイズ）に等しいいくつかのＰＤＵ、または、ＰＤＵサイズおよび送信される許容ビット数のいずれかが提供される。拡張ＭＡＣエンティティがヘッダーサイズを考慮に入れてもよく、またはＲＬＣがヘッダーサイズを考慮に入れてもよい。
【００４５】
ステップ５３０で、ＲＬＣエンティティがＲＬＣ  ＰＤＵを配信したかどうかが決定される。ＲＬＣエンティティがＲＬＣ  ＰＤＵを配信しなかった場合、手順５００は、ステップ５０５に戻り、現在のＴＴＩにおいて送信することができる次の論理チャネルがある場合は、それについて繰り返される。
【００４６】
ＲＬＣエンティティがＲＬＣ  ＰＤＵを配信した場合、ステップ５３５で、配信されたＲＬＣ  ＰＤＵのサイズが拡張ＭＡＣ−ｅ  ＰＤＵにおける使用可能なスペース未満であるかどうかが決定される。配信されたＲＬＣ  ＰＤＵサイズが拡張ＭＡＣ−ｅ  ＰＤＵにおける使用可能なスペースを超える場合、ステップ５５０で、ヘッダーのための空きを残しながら、ＭＡＣ−ｅ  ＰＤＵが、配信されたＲＬＣ  ＰＤＵからのできるだけ多くのビットで満たされ、配信されたＲＬＣ  ＰＤＵをＭＡＣ−ｅ  ＰＤＵに収まるようにセグメント化する必要がある場合、残りのビットは、セグメンテーション・バッファに格納される。その後、手順５００は、ステップ５０５に戻り、現在のＴＴＩにおいて送信することができる次の論理チャネルがある場合、それについて繰り返される。
【００４７】
配信されたＲＬＣ  ＰＤＵサイズが拡張ＭＡＣ−ｅ  ＰＤＵにおける使用可能なスペース未満である場合、ステップ５４０で、ＭＡＣ−ｅ  ＰＤＵが、配信されたＲＬＣ  ＰＤＵおよび対応するヘッダーで満たされ、ＲＬＣ  ＰＤＵのサイズおよびヘッダーがＢから差し引かれる。その後、ＭＡＣ−ｅ  ＰＤＵにおける残りのスペースを満たすために、手順５００は、ステップ５１０に戻る。
【００４８】
ＲＬＣエンティティは、例えば、最小ＲＬＣサイズなど、作成できるＲＬＣ  ＰＤＵサイズに下限を設けることもできる。最小ＲＬＣ  ＰＤＵサイズは、上位レイヤによって構成することができる、あるいは静的値、または最適な送信についての計算値とすることができる。例えば、ＭＡＣエンティティによって要求されたビット数（または要求されたビット数−再送されたＲＬＣ  ＰＤＵのビット数）が最小ＲＬＣ  ＰＤＵサイズ未満である場合、ＲＬＣエンティティは、以下のうちの１つまたは組み合わせを行い得る。すなわち、任意のデータをＭＡＣエンティティに送信しない、および最小ＲＬＣ  ＰＤＵサイズ以上のサイズのより大きいＲＬＣ  ＰＤＵを作成することができ、したがって、ＭＡＣエンティティは、より大きいＰＤＵを扱う必要がある。
【００４９】
一実施形態において、こうしたサイズが定義される場合、ＷＴＲＵは、最小許容ＭＡＣセグメントサイズから最小ＲＬＣ  ＰＤＵサイズを導出するように構成され得る。例えば、最小ＲＬＣ  ＰＤＵサイズは、最小ＭＡＣセグメントサイズの倍数とすることができる。あるいは、最小ＲＬＣ  ＰＤＵサイズは、ＷＴＲＵにおいて予め構成された静的値とすることができる。
【００５０】
あるいは、ＵＴＲＡＮは、最大ＲＬＣ  ＰＤＵサイズを決定し、Ｌ２またはＬ３（ＲＲＣ）シグナリングを使用して最大ＲＬＣ  ＰＤＵサイズ値をＷＴＲＵに伝えることができる。例えば、ＵＴＲＡＮは、ＲＲＣ  ＩＥ（情報要素：information element）「ＲＬＣ  ｉｎｆｏ」を使用して、最小ＲＬＣ  ＰＤＵサイズおよび最大ＲＬＣ  ＰＤＵサイズを使用するようにＷＴＲＵを構成することができる。最大ＲＬＣ  ＰＤＵサイズ値のシグナリングは、無線ベアラ構成または無線ベアラ再構成時に起こり得る。さらに、最大ＲＬＣ  ＰＤＵサイズ値のシグナリングは、トランスポートチャネル構成またはトランスポートチャネル再構成時に起こり得る。
【００５１】
別の実施形態によれば、可変長ヘッダーにより非スケジュール・データ・フローのＧＢＲ（保証されたビット・レート）を維持するための技術も提供される。非スケジュール・データ・フローは、構成された保証されたビット・レートによるデータ・フローである。ＵＬ（アップリンク）におけるレイヤ２の強化の導入により、拡張ＭＡＣ−ｅ／ｅｓのオーバーヘッドは、ＲＬＣ  ＰＤＵサイズ、および拡張ＭＡＣ−ｅｓ  ＰＤＵにおけるＲＬＣ  ＰＤＵの数に依存するようになった。ネットワークは、非スケジュール・データ・フローの許可を構成するとき、このデータを送信するために使用される電力が、必要なビット量＋拡張ＭＡＣ−ｅ／ｅｓヘッダービットを送信するのに十分であるようにその非スケジュール・データ・フローの許可を構成する。提案された方法は、拡張ＭＡＣ−ｅｓ  ＳＤＵの数に基づいてヘッダーフィールドが変わることを考慮に入れて、構成された許可内で適切なデータ量を送信することができることを保証する。上述したように、ｈ１は、第１のＲＬＣ  ＰＤＵまたはそのセグメントを含むために必要な追加のヘッダービット数を指し、ｈ２は、同じ論理チャネルに属するその後のＲＬＣ  ＰＤＵまたはそのセグメントを含むために必要な追加のヘッダービット数を指す。Ｂは、論理チャネルに現在使用可能なビット数を指す。
【００５２】
非スケジュール・データ・フローのビット・レートを保証するために、以下の手順のうちの任意の１つを、単体で、または組み合わせで使用することができる。一手順において、ネットワークは、拡張ＭＡＣ−ｅ／ｅｓヘッダー・スペースの最悪の場合のシナリオを考慮に入れることによって、控えめな許可を非スケジュールフローに提供することができる。これは、ＲＬＣエンティティは最小サイズより小さいＲＬＣ  ＰＤＵを作成せず、しかしＭＡＣエンティティはこれらのＲＬＣ  ＰＤＵをセグメント化することができるように、例えば３００ビットなどの最小ＲＬＣ  ＰＤＵサイズをシグナリングし、または想定することによって行うことができる。これは、ＲＮＣ（無線ネットワーク・コントローラ）に対する最悪の場合のオーバーヘッドを確立し、これは次いで、非スケジュール許可を決定するために、ＲＮＣによって使用される。例えば、意図されたＧＢＲが、Ｘビット／ＴＴＩに等しい場合、ネットワークは、セグメンテーションの可能性を考慮して、（Ｘ＋ｈ２＋（（Ｘ／ｍｉｎ  ＲＬＣ  ＰＤＵサイズ）−１）＊（ｈｌ）ビットの非スケジュール許可を割り当てることができる。代替の手順において、ネットワークは、上述したような、しかし平均ＲＬＣ  ＰＤＵサイズに基づく控えめな許可を提供し得る。ＲＬＣ  ＰＤＵが平均より小さい場合、非スケジュールフローは、スケジュールフローの電力の一部を費やして、必要なビット数が送信されることを確実にすることができる。別の手順において、ネットワークは、より柔軟な非スケジュール許可を構成することができる。これは、絶対値および分散値、例えば、ＷＴＲＵが使用することができる）＋／−値などをＷＴＲＵに提供することによって行うことができる。
【００５３】
図６は、別の実施形態に従って、Ｅ−ＴＦＣ選択の一部として拡張ＭＡＣ−ｅ  ＰＤＵを論理チャネルからのデータで満たす簡略化された手順６００のフロー図を示す。ステップ６０５で、セグメンテーション・バッファにセグメントがある場合、セグメントが拡張ＭＡＣ−ｅ  ＰＤＵに追加され、この場合、セグメントは、ＭＡＣ−ｅ  ＰＤＵに収まるように再セグメント化され得る。ステップ６１０で、拡張ＭＡＣ−ｅ  ＰＤＵにスペースがある場合、送信することができる最大ビット数がＲＬＣエンティティに要求される。ステップ６１５で、受信されたＲＬＣ  ＰＤＵは、ＭＡＣ−ｅ  ＰＤＵにおける使用可能なスペースを満たすためにＭＡＣ−ｅ  ＰＤＵに追加され、最後のＲＬＣ  ＰＤＵは、必要な場合、ＭＡＣ−ｅ  ＰＤＵに収まるようにセグメント化され得る。さらに、拡張ＭＡＣ−ｅ  ＰＤＵを作成するために、上述した任意の手順における任意のステップを、手順６００との組み合わせで使用することができる。
【００５４】
Ｅ−ＴＦＣ選択の一部としての図３Ａおよび３Ｂの手順３００、図４の手順４００、図５の手順５００、および／または図６の手順６００は、図２のＥ−ＴＦＣ選択エンティティ２１２によって実行され得る。この場合、ＲＬＣ  ＰＤＵのセグメンテーションは、セグメンテーション・エンティティ２１４によって実行され、セグメントは、セグメンテーション・バッファ２１６に格納され得る。ＭＡＣ−ｃ、ＭＡＣ−ｄ、またはＲＬＣエンティティへのビットの要求は、拡張ＭＡＣ−ｅ／ｅｓエンティティ２１０によって行われる。
【００５５】
上記では特徴および要素が特定の組み合わせで記載されているが、各特徴または要素は、他の特徴および要素無しに単独で、または他の特徴および要素の有無にかかわらず様々な組み合わせで使用することができる。本明細書に提供された方法またはフロー図は、汎用コンピュータまたはプロセッサによって実行するために、コンピュータ可読記憶媒体に組み込まれるコンピュータプログラム、ソフトウェア、またはファームウェアにおいて実施することができる。コンピュータ可読記憶媒体の例には、ＲＯＭ（読み取り専用メモリ）、ＲＡＭ（ランダムアクセスメモリ）、レジスタ、キャッシュメモリ、半導体メモリ装置、内蔵ハードディスクおよび取外式ディスクなどの磁気媒体、光磁気媒体、並びにＣＤ−ＲＯＭディスクやＤＶＤ（デジタル多目的ディスク）などの光媒体などがある。
【００５６】
適したプロセッサには、一例として、汎用プロセッサ、専用プロセッサ、従来のプロセッサ、ＤＳＰ（デジタル信号プロセッサ）、複数のマイクロプロセッサ、ＤＳＰコアと関連する１つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、ＡＳＩＣ（特定用途向け集積回路）、ＦＰＧＡ（フィールドプログラマブルゲートアレイ）回路、他の任意のタイプのＩＣ（集積回路）および／または状態機械などがある。
【００５７】
＜実施形態＞
１．Ｅ−ＴＦＣ（拡張トランスポート・フォーマット・コンビネーション）選択の一部としてＭＡＣ−ｅ（拡張媒体アクセス制御）ＰＤＵ（パケット・データ・ユニット）を作成するための方法。
【００５８】
２．セグメンテーション・バッファが送信すべきビットまたはセグメントを含むかどうかを決定するステップをさらに含む実施形態１に記載の方法。
【００５９】
３．セグメンテーション・バッファが送信すべきセグメントを含む場合、次いで、対応するヘッダーを含むセグメントにおけるビット数が残余使用可能ペイロードおよび残余許可ペイロードの最小値未満である場合、対応するヘッダーを含むセグメントを拡張ＭＡＣ−ｅ  ＰＤＵに追加するステップをさらに含む実施形態２に記載の方法。
【００６０】
４．拡張ＭＡＣ−ｅ  ＰＤＵに追加された総ビット数を残余許可ペイロードおよび残余使用可能ペイロードから差し引くステップをさらに含む実施形態３に記載の方法。
【００６１】
５．残余許可ペイロードおよび残余使用可能ペイロードがゼロを超える場合、残余使用可能ペイロードおよび残余許可ペイロードの最小値に等しいいくつかのビットをＲＬＣ（無線リンク制御）論理チャネルに要求するステップをさらに含む実施形態１に記載の方法。
【００６２】
６．対応するヘッダーを含むセグメントにおけるビット数が残余使用可能ペイロードおよび残余許可ペイロードの最小値を超える場合、セグメントをセグメント化して、ヘッダーサイズ未満の残余使用可能ペイロード、およびヘッダーサイズ未満の残余許可ペイロードの最小値に等しいいくつかのビットを含むサブセグメントを生成するステップをさらに含む前記実施形態のいずれかに記載の方法。
【００６３】
７．対応するヘッダーを含むサブセグメントを拡張ＭＡＣ−ｅ  ＰＤＵに追加するステップをさらに含む実施形態６に記載の方法。
【００６４】
８．拡張ＭＡＣ−ｅ  ＰＤＵに追加された総ビット数を残余許可ペイロードおよび残余使用可能ペイロードから差し引くステップであって、追加された総ビット数は、対応するＭＡＣ−ｅヘッダー部分のために追加されるビットを含む、ステップをさらに含む実施形態７に記載の方法。
【００６５】
９．対応するヘッダーは、拡張ＭＡＣ−ｅｓヘッダーおよび拡張ＭＡＣ−ｅヘッダーを含む実施形態６〜８のいずれかに記載の方法。
【００６６】
１０．対応する拡張ＭＡＣ−ｅｓヘッダー部分を残余使用可能ペイロードおよび残余許可ペイロードから差し引くステップをさらに含む実施形態３〜９のいずれかに記載の方法。
【００６７】
１１．セグメンテーション・バッファが送信すべきセグメントを含んでいない場合、残余使用可能ペイロードおよび残余許可ペイロードの最小値に等しいいくつかのビットをＲＬＣ論理チャネルに要求するステップをさらに含む前記実施形態のいずれかに記載の方法。
【００６８】
１２．ＲＬＣ論理チャネルにいくつかのビットを要求するステップに応答して、ＲＬＣ論理チャネルについて、少なくとも１つのＲＬＣ  ＰＤＵを受信するステップをさらに含む実施形態１１に記載の方法。
【００６９】
１３．要求されたビット数に関して、対応するヘッダー部分を含む少なくとも１つのＲＬＣ  ＰＤＵの合計サイズを決定するステップをさらに含む実施形態１２に記載の方法。
【００７０】
１４．対応するヘッダー部分を含む少なくとも１つのＲＬＣ  ＰＤＵの合計サイズが要求されたビット数未満である場合、拡張ＭＡＣ−ｅ  ＰＤＵを少なくとも１つのＲＬＣ  ＰＤＵで満たすステップをさらに含む実施形態１３に記載の方法。
【００７１】
１５．拡張ＭＡＣ−ｅ  ＰＤＵに追加された総ビット数を残余許可ペイロードおよび残余使用可能ペイロードから差し引くステップであって、追加された総ビット数は、ＲＬＣ  ＰＤＵおよび対応するヘッダー部分についてのいくつかのビットを含む、ステップをさらに含む実施形態１４に記載の方法。
【００７２】
１６．対応するヘッダーを含む少なくとも１つのＲＬＣ  ＰＤＵの合計サイズが要求されたビット数を超える場合、少なくとも１つのＲＬＣ  ＰＤＵの中から１つまたは複数の完全なＲＬＣ  ＰＤＵを拡張ＭＡＣ−ｅ  ＰＤＵに追加するステップをさらに含む実施形態１１〜１５のいずれかに記載の方法。
【００７３】
１７．少なくとも１つのＲＬＣ  ＰＤＵの中の最後のＲＬＣ  ＰＤＵをセグメント化して、サブセグメントおよび残余セグメントを生成するステップをさらに含む実施形態１６に記載の方法。
【００７４】
１８．サブセグメントを拡張ＭＡＣ−ｅ  ＰＤＵに追加するステップをさらに含む実施形態１７に記載の方法。
【００７５】
１９．セグメンテーション・バッファに残余セグメントを格納するステップをさらに含む実施形態１８に記載の方法。
【００７６】
２０．拡張ＭＡＣ−ｅ  ＰＤＵに追加された総ビット数を残余許可ペイロードおよび残余使用可能ペイロードから差し引くステップであって、追加された総ビット数は、ＲＬＣ  ＰＤＵおよび対応するヘッダー部分についてのいくつかのビットを含む、ステップをさらに含む実施形態１９に記載の方法。
【００７７】
２１．サブセグメントは、ＲＬＣ論理チャネルについて、拡張ＭＡＣ−ｅ  ＰＤＵにおける使用可能な残余スペースに等しいいくつかのビットを有する実施形態１６〜２０のいずれかに記載の方法。
【００７８】
２２．少なくとも１つのＲＬＣ  ＰＤＵは、ＭＡＣ−ｃ  ＰＤＵおよびＭＡＣ−ｄ  ＰＤＵのうちの一方である実施形態１２〜２１のいずれかに記載の方法。
【００７９】
２３．ＲＬＣ論理チャネルは、現在のＴＴＩ（送信時間間隔）において送信することができ、現在のＴＴＩにおける多重化制限を満たす前記実施形態のいずれかに記載の方法。
【００８０】
２４．残余使用可能ペイロードは、現在のＴＴＩ（送信時間間隔）で送信することができる最大データ量であり、使用可能許可、スケジュール許可、非スケジュール許可、最大使用可能電力、および選択された電力オフセットのうちの１つまたは複数に基づく前記実施形態のいずれかに記載の方法。
【００８１】
２５．残余許可ペイロードは、スケジュールされたＭＡＣ−ｄフローに対応するＲＬＣ論理チャネルについてのサービング許可および選択された電力オフセットにより送信することができる最大データ量である前記実施形態のいずれかに記載の方法。
【００８２】
２６．残余許可ペイロードは、非スケジュールＭＡＣ−ｄフローに対応する論理チャネルについての非スケジュール許可により送信することができる最大データ量である前記実施形態のいずれかに記載の方法。
【００８３】
２７．現在のＴＴＩ（送信時間間隔）において現在の論理チャネルで使用可能なデータがそれ以上なく、残余使用可能ペイロードが使い果たされていないとき、多重化制限を満たす次に優先順位が高いチャネルを処理するステップをさらに含む前記実施形態のいずれかに記載の方法。
【００８４】
２８．残余許可ペイロードが使い果たされ、残余使用可能ペイロードが使い果たされていないとき、多重化制限を満たす次に優先順位が高いチャネルを処理するステップをさらに含む前記実施形態のいずれかに記載の方法。
【００８５】
２９．残余使用可能ペイロードが使い果たされていると、現在のＴＴＩ（送信時間間隔）について方法を終了するステップをさらに含む前記実施形態のいずれかに記載の方法。
【００８６】
３０．現在のＴＴＩ（送信時間間隔）において論理チャネルに使用可能なデータがそれ以上ないとき、現在のＴＴＩについて方法を終了するステップをさらに含む前記実施形態のいずれかに記載の方法。
【００８７】
３１．優先順位順に多重化制限を満たす論理チャネルについて実行される前記実施形態のいずれかに記載の方法。
【００８８】
３２．Ｅ−ＴＦＣ（拡張トランスポート・フォーマット・コンビネーション）選択の一部としてＭＡＣ−ｅ（拡張媒体アクセス制御）ＰＤＵ（パケット・データ・ユニット）を作成するための方法。
【００８９】
３３．残余使用可能ペイロードおよび残余許可ペイロードの最小値に従って、論理チャネルについて現在使用可能な最大ビット数Ｂを決定するステップをさらに含む実施形態３２に記載の方法。
【００９０】
３４．セグメンテーション・バッファが送信すべきセグメントを含む場合、ヘッダーのための空きを残しながら、拡張ＭＡＣ−ｅ  ＰＤＵをセグメントからのできるだけ多くのビットで満たすステップをさらに含む実施形態３３に記載の方法。
【００９１】
３５．ｈ１が第１のＲＬＣ（無線リンク制御）ＰＤＵまたはそのセグメントのためのいくつかのヘッダービットである場合、セグメントがＢ−ｈ１を超えるとしたら、セグメントをサブセグメントおよび残余セグメントにセグメント化するステップをさらに含む実施形態３４に記載の方法。
【００９２】
３６．サブセグメントを拡張ＭＡＣ−ｅ  ＰＤＵに追加するステップをさらに含む実施形態３５に記載の方法。
【００９３】
３７．セグメンテーション・バッファに残余セグメントを格納するステップをさらに含む実施形態３６に記載の方法。
【００９４】
３８．残余使用可能ペイロードが量子化損失のために調整され得る実施形態３２〜３７のいずれかに記載の方法。
【００９５】
３９．拡張ＭＡＣ−ｅ  ＰＤＵに対応するヘッダーを挿入することをさらに含む実施形態３２〜３８のいずれかに記載の方法。
【００９６】
４０．Ｂから拡張ＭＡＣ−ｅ  ＰＤＵに追加された総ビット数を差し引くステップであって、追加された総ビット数は、セグメントおよびヘッダーサイズからのいくつかのビットを含む、ステップをさらに含む実施形態３９に記載の方法。
【００９７】
４１．Ｂがゼロを超える場合に、データがセグメンテーション・バッファから含まれた場合、論理チャネルにサイズＢ−ｈ２ビットのＲＬＣ  ＰＤＵを要求し、この場合ｈ２は次のＲＬＣ  ＰＤＵまたはそのセグメントのためのいくつかのヘッダービットであり、データがセグメンテーション・バッファから含まれなかった場合、サイズＢ−ｈ１のものを要求するステップをさらに含む実施形態３９〜４０のいずれかに記載の方法。
【００９８】
４２．論理チャネルにＲＬＣ  ＰＤＵを要求するステップに応答して、論理チャネルについて、少なくとも１つのＲＬＣ  ＰＤＵを受信するステップをさらに含む実施形態４１に記載の方法。
【００９９】
４３．要求されたビット数に関して、少なくとも１つのＲＬＣ  ＰＤＵの合計サイズを決定するステップをさらに含む実施形態４２に記載の方法。
【０１００】
４４．少なくとも１つのＲＬＣ  ＰＤＵの合計サイズが要求されたビット数未満である場合、少なくともＲＬＣ  ＰＤＵおよび対応するヘッダーからのビットを拡張ＭＡＣ−ｅ  ＰＤＵに追加するステップをさらに含む実施形態４３に記載の方法。
【０１０１】
４５．拡張ＭＡＣ−ｅ  ＰＤＵに追加された総ビット数をＢから差し引くステップをさらに含む実施形態４４に記載の方法。
【０１０２】
４６．少なくとも１つのＲＬＣ  ＰＤＵの合計サイズが、要求されたビット数を超える場合、ヘッダーのための空きを残しながら、少なくとも１つのＲＬＣ  ＰＤＵからのビットを拡張ＭＡＣ−ｅ  ＰＤＵに追加するステップをさらに含む実施形態４４〜４５のいずれかに記載の方法。
【０１０３】
４７．拡張ＭＡＣ−ｅ  ＰＤＵに追加されるとき、少なくとも１つのＲＬＣ  ＰＤＵがセグメント化された場合、セグメンテーション・バッファに残余ビットを格納するステップをさらに含む実施形態４６に記載の方法。
【０１０４】
４８．ＷＴＲＵ（無線送受信ユニット）によって実行される前記実施形態のいずれかに記載の方法。
【０１０５】
４９．基地局によって実行される実施形態１〜４７のいずれかに記載の方法。
【０１０６】
５０．ＵＥ（ユーザ機器）によって実行される実施形態１〜４７のいずれかに記載の方法。
【０１０７】
５１．ＮｏｄｅＢによって実行される実施形態１〜４７のいずれかに記載の方法。
【０１０８】
５２．拡張ＭＡＣ−ｅ／ｅｓ（媒体アクセス制御）エンティティによって実行される実施形態１〜４７のいずれかに記載の方法。
【０１０９】
５３．Ｅ−ＴＦＣ（拡張トランスポート・フォーマット・コンビネーション）選択エンティティによって実行される実施形態１〜４７のいずれかに記載の方法。
【０１１０】
ソフトウェアと関連するプロセッサは、ＷＴＲＵ（無線送受信ユニット）、ＵＥ（ユーザ機器）、端末、基地局、ＲＮＣ（無線ネットワーク・コントローラ）、または任意のホストコンピュータで使用するための無線周波数送受信装置を実施するために使用することができる。ＷＴＲＵは、カメラ、ビデオカメラモジュール、テレビ電話、スピーカフォン、振動装置、スピーカ、マイクロフォン、テレビ送受信機、ハンズフリーヘッドセット、キーボード、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、ＦＭ（周波数変調）無線ユニット、ＬＣＤ（液晶ディスプレイ）表示装置、ＯＬＥＤ（有機発光ダイオード）表示装置、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ、および／または任意のＷＬＡＮ（無線ローカルエリアネットワーク）またはＵＷＢ（超広帯域）モジュールなど、ハードウェアおよび／またはソフトウェアに実装されるモジュールと共に使用することができる。
【図１】
2015213368.tif 000003
【図２】
2015213368.tif 000004
【図３Ａ】
2015213368.tif 000005
【図３Ｂ】
2015213368.tif 000006
【図４】
2015213368.tif 000007
【図５】
2015213368.tif 000008
【図６】
2015213368.tif 000009