(57)【要約】  本開示のデータ送信ノードは、第３のレイヤから、データ送信用に割り当てられたリソースにマッピングされる少なくとも１つの第２レイヤサービスデータユニット（ＳＤＵ）を受信するとともに、少なくとも１つの第２レイヤＳＤＵおよび当該少なくとも１つの第２レイヤＳＤＵのいずれかの後に配置された少なくとも１つの第２レイヤ制御エレメントを含む第２レイヤプロトコルデータユニット（ＰＤＵ）を生成する第２レイヤ処理回路と、第２レイヤ処理回路により生成された第２レイヤＰＤＵを受信するとともに、データ送信用に割り当てられたリソースに第２レイヤＰＤＵをマッピングする第１レイヤ処理回路と、を備える。
2019533377.tif 000002
【特許請求の範囲】
【請求項１】
通信システムにおいてデータを無線チャネル上でデータ受信ノードに送信するデータ送信ノードであって、
動作時に、第３のレイヤから、データ送信用に割り当てられたリソースにマッピングされる少なくとも１つの第２レイヤサービスデータユニット（ＳＤＵ）を受信するとともに、前記少なくとも１つの第２レイヤＳＤＵおよび前記少なくとも１つの第２レイヤＳＤＵのいずれかの後に配置された少なくとも１つの第２レイヤ制御エレメントを含む第２レイヤプロトコルデータユニット（ＰＤＵ）を生成する第２レイヤ処理回路と、
動作時に、前記第２レイヤ処理回路により生成された前記第２レイヤＰＤＵを受信するとともに、データ送信用に割り当てられた前記リソースに前記第２レイヤＰＤＵをマッピングする第１レイヤ処理回路と、
を備えたデータ送信ノード。
【請求項２】
前記第２レイヤＰＤＵが、
前記少なくとも１つの第２レイヤＳＤＵのそれぞれと関連付けられた各第２レイヤサブヘッダと、
前記少なくとも１つの第２レイヤ制御エレメントのいずれかと関連付けられた各第２レイヤサブヘッダと、
をさらに含む、
請求項１に記載のデータ送信ノード。
【請求項３】
前記少なくとも１つの第２レイヤＳＤＵが、前記関連付けられた各サブヘッダの後に配置され、前記少なくとも１つの第２レイヤ制御エレメントが、前記関連付けられた各サブヘッダの前に配置された、
請求項２に記載のデータ送信ノード。
【請求項４】
前記少なくとも１つの第２レイヤＳＤＵのそれぞれと関連付けられた第２レイヤサブヘッダが、前記第２レイヤＰＤＵが少なくとも１つの第２レイヤ制御エレメントを含むかを示す存在インジケータを含む、
請求項３に記載のデータ送信ノード。
【請求項５】
前記少なくとも１つの第２レイヤ制御エレメントのいずれかと関連付けられた各第２レイヤサブヘッダが、各第２レイヤＳＤＵおよび各第２レイヤＳＤＵと関連付けられた各サブヘッダに先行する、
請求項２に記載のデータ送信ノード。
【請求項６】
前記第２レイヤＰＤＵが、パディングバッファステータスレポート（ＢＳＲ）および前記パディングＢＳＲと関連付けられた第２レイヤサブヘッダを含み、前記パディングＢＳＲおよび前記パディングＢＳＲと関連付けられた前記第２レイヤサブヘッダが、前記少なくとも１つの第２レイヤＳＤＵのいずれかの後に配置された、
請求項１〜５のいずれか一項に記載のデータ送信ノード。
【請求項７】
第１の種類の第２レイヤＰＤＵが、少なくとも１つの第２レイヤＳＤＵおよび前記少なくとも１つの第２レイヤＳＤＵのいずれかの後に配置された少なくとも１つの第２レイヤ制御エレメントを含み、
第２の種類のＰＤＵが、少なくとも１つの第２レイヤＳＤＵおよび前記少なくとも１つの第２レイヤＳＤＵのいずれかに先行する少なくとも１つの第２レイヤ制御エレメントを含み、
前記第２レイヤ処理回路が、第２の種類の第２レイヤＰＤＵを生成するようにさらに構成可能である、
請求項１に記載のデータ送信ノード。
【請求項８】
前記第２レイヤ処理回路が、前記第２レイヤＰＤＵに含まれる第２レイヤ制御エレメントの種類に応じて、第１の種類の第２レイヤＰＤＵまたは第２の種類の第２レイヤＰＤＵを生成するように構成可能である、
請求項７に記載のデータ送信ノード。
【請求項９】
前記第２レイヤ処理回路が、前記第２レイヤＰＤＵの生成が完了する前に、前記第２レイヤＰＤＵの一部を構成するパッケージを前記第１レイヤ処理回路へ転送し始めるように構成された、
請求項１〜８のいずれか一項に記載のデータ送信ノード。
【請求項１０】
通信システムにおいてデータを無線チャネル上でデータ送信ノードから受信するデータ受信ノードであって、
動作時に、データ受信用に割り当てられたリソースから、少なくとも１つの第２レイヤプロトコルデータユニット（ＰＤＵ）をデマッピングする第１レイヤ処理回路と、
動作時に、前記第１レイヤ処理回路によりデマッピングされた前記第２レイヤＰＤＵを受信して構文解析する第２レイヤ処理回路であり、前記第２レイヤＰＤＵが、少なくとも１つの第２レイヤサービスデータユニット（ＳＤＵ）および前記少なくとも１つの第２レイヤＳＤＵのいずれかに後続する少なくとも１つの第２レイヤ制御エレメントを含む、第２レイヤ処理回路と、
を備えたデータ受信ノード。
【請求項１１】
各第２レイヤサブヘッダが、
前記少なくとも１つの第２レイヤＳＤＵのそれぞれと関連付けられており、
前記少なくとも１つの第２レイヤ制御エレメントのいずれかと関連付けられている、
請求項１０に記載のデータ受信ノード。
【請求項１２】
前記少なくとも１つの第２レイヤＳＤＵのそれぞれと関連付けられた第２レイヤサブヘッダが、前記第２レイヤＰＤＵが少なくとも１つの第２レイヤ制御エレメントを含むかを示す存在インジケータを含み、
前記存在インジケータが、少なくとも１つの第２レイヤ制御エレメントが前記第２レイヤＰＤＵに含まれることを示す場合に、前記第２レイヤ処理回路が、前記第２レイヤＰＤＵの最後から開始して前記第２レイヤＰＤＵを構文解析する、
請求項１１に記載のデータ受信ノード。
【請求項１３】
前記第２レイヤ処理回路が、前記第２レイヤＰＤＵの最初から、第２レイヤ制御エレメントと関連付けられたサブヘッダを構文解析するとともに、前記第２レイヤＰＤＵから、任意の第２レイヤＳＤＵの後に配置された前記第２レイヤ制御エレメントを抽出するように構成された、
請求項１１に記載のデータ受信ノード。
【請求項１４】
通信システムにおいてデータを無線チャネル上でデータ受信ノードに送信する方法であって、
第３のレイヤから、データ送信用に割り当てられたリソースにマッピングされる少なくとも１つの第２レイヤサービスデータユニット（ＳＤＵ）を受信するとともに、前記少なくとも１つの第２レイヤＳＤＵおよび前記少なくとも１つの第２レイヤＳＤＵのいずれかの後に配置された少なくとも１つの第２レイヤ制御エレメントを含む第２レイヤプロトコルデータユニット（ＰＤＵ）を生成するステップと、
第２レイヤ処理回路により生成された前記第２レイヤＰＤＵを受信するとともに、データ送信用に割り当てられた前記リソースに前記第２レイヤＰＤＵをマッピングするステップと、
を含む方法。
【請求項１５】
通信システムにおいてデータを無線チャネル上でデータ送信ノードから受信する方法であって、
第１レイヤ処理により、データ受信用に割り当てられたリソースから、少なくとも１つの第２レイヤプロトコルデータユニット（ＰＤＵ）をデマッピングするステップと、
前記第１レイヤ処理によりデマッピングされた第２レイヤＰＤＵを受信して構文解析するステップであり、前記第２レイヤＰＤＵが、少なくとも１つの第２レイヤサービスデータユニット（ＳＤＵ）および前記少なくとも１つの第２レイヤＳＤＵのいずれかに後続する少なくとも１つの第２レイヤ制御エレメントを含む、前記第２レイヤＰＤＵを受信して構文解析するステップと、
を含む方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、通信システムにおける複数のレイヤ上の送信および受信処理のほか、対応する送信装置、方法、およびプログラムに関する。
【背景技術】
【０００２】
ＷＣＤＭＡ（登録商標）無線アクセス技術をベースとする第３世代の移動通信システム（３Ｇ）は、世界中で広範な規模で配備されつつある。この技術を機能強化または発展・進化させる上での最初のステップとして、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ：Ｈｉｇｈ−Ｓｐｅｅｄ  Ｄｏｗｎｌｉｎｋ  Ｐａｃｋｅｔ  Ａｃｃｅｓｓ）と、高速アップリンクパケットアクセス（ＨＳＵＰＡ：Ｈｉｇｈ−Ｓｐｅｅｄ  Ｕｐｌｉｎｋ  Ｐａｃｋｅｔ  Ａｃｃｅｓｓ）とも称するエンハンストアップリンクとが導入され、これにより、極めて競争力の高い無線アクセス技術が提供されている。ユーザからのますます増大する需要に対応し、新しい無線アクセス技術に対する競争力を確保する目的で、３ＧＰＰは、ロングタームエボリューション（ＬＴＥ）と称する新しい移動通信システムを導入した。ＬＴＥは、今後１０年間にわたり、データおよびメディアの高速トランスポートならびに大容量の音声サポートに要求されるキャリアを提供するように設計されている。高いビットレートを提供する能力は、ＬＴＥにおける重要な方策である。Ｅ−ＵＴＲＡ（Ｅｖｏｌｖｅｄ  ＵＭＴＳ  Ｔｅｒｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ（ＵＴＲＡ））およびＵＴＲＡＮ（ＵＭＴＳ  Ｔｅｒｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ）と称するＬＴＥに関する作業項目（ＷＩ：Ｗｏｒｋ  Ｉｔｅｍ）の仕様は、最終的にリリース８（ＬＴＥ  Ｒｅｌ．８）として公開される。ＬＴＥシステムは、パケットベースの効率的な無線アクセスおよび無線アクセスネットワークであり、ＩＰベースの全機能を低遅延かつ低コストで提供する。ＬＴＥでは、所与のスペクトルを用いてフレキシブルなシステム配備を達成するために、スケーラブルな複数の送信帯域幅（たとえば、１．４ＭＨｚ、３．０ＭＨｚ、５．０ＭＨｚ、１０．０ＭＨｚ、１５．０ＭＨｚ、および２０．０ＭＨｚ）が指定されている。ダウンリンクには、直交周波数分割多重（ＯＦＤＭ：Ｏｒｔｈｏｇｏｎａｌ  Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅｘｉｎｇ）をベースとする無線アクセスが採用されている。なぜなら、かかる無線アクセスは、低いシンボルレートのため本質的にマルチパス干渉（ＭＰＩ：ｍｕｌｔｉｐａｔｈ  ｉｎｔｅｒｆｅｒｅｎｃｅ）を受けにくく、また、巡回プレフィックス（ＣＰ：Ｃｙｃｌｉｃ  Ｐｒｅｆｉｘ）を使用しており、さらに、さまざまな送信帯域幅の構成に対応可能だからである。アップリンクには、シングルキャリア周波数分割多重アクセス（ＳＣ−ＦＤＭＡ：Ｓｉｎｇｌｅ−Ｃａｒｒｉｅｒ  Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ）をベースとする無線アクセスが採用されている。なぜなら、ユーザ機器（ＵＥ：Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ）の送信出力が限られていることを考えれば、ピークデータレートを向上させるよりも広いカバレッジエリアを提供することが優先されるからである。ＬＴＥ  Ｒｅｌ．８では、数多くの主要なパケット無線アクセス技術（たとえば、ＭＩＭＯ（Ｍｕｌｔｉｐｌｅ  Ｉｎｐｕｔ  Ｍｕｌｔｉｐｌｅ  Ｏｕｔｐｕｔ）チャネル伝送技術）が採用され、高効率の制御シグナリング構造が実現されている。
【０００３】
＜ＬＴＥアーキテクチャ＞
全体的なアーキテクチャを図１に示しており、Ｅ−ＵＴＲＡＮアーキテクチャのより詳細な描写を図２に与えている。Ｅ−ＵＴＲＡＮは、ｅＮＢから成り、ｅＮＢは、ＵＥ向けのＥ−ＵＴＲＡのユーザプレーン（ＰＤＣＰ／ＲＬＣ／ＭＡＣ／ＰＨＹ）プロトコルおよび制御プレーン（ＲＲＣ：Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ）プロトコルを終端させる。ｅＮＢは、物理（ＰＨＹ）レイヤ、媒体アクセス制御（ＭＡＣ：Ｍｅｄｉｕｍ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）レイヤ、無線リンク制御（ＲＬＣ：Ｒａｄｉｏ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ）レイヤ、およびパケットデータ制御プロトコル（ＰＤＣＰ：Ｐａｃｋｅｔ  Ｄａｔａ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）レイヤ（これらのレイヤは、ユーザプレーンのヘッダ圧縮および暗号化の機能を含む）をホストする。ｅＮＢは、制御プレーンに対応する無線リソース制御（ＲＲＣ）機能も提供する。ｅＮＢは、無線リソース管理、アドミッション制御、スケジューリング、交渉によるアップリンク（ＵＬ）サービス品質（ＱｏＳ：Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）の実施、セル情報のブロードキャスト、ユーザプレーンデータおよび制御プレーンデータの暗号化／復号、ダウンリンク（ＤＬ）／アップリンク（ＵＬ）のユーザプレーンパケットヘッダの圧縮／復元等、多くの機能を実行する。複数のｅＮＢは、Ｘ２インターフェースによって互いに接続されている。また、複数のｅＮＢは、Ｓ１インターフェースによってＥＰＣ（Ｅｖｏｌｖｅｄ  Ｐａｃｋｅｔ  Ｃｏｒｅ）、より具体的には、Ｓ１−ＭＭＥによってＭＭＥ（移動管理エンティティ：Ｍｏｂｉｌｉｔｙ  Ｍａｎａｇｅｍｅｎｔ  Ｅｎｔｉｔｙ）、Ｓ１−Ｕによってサービングゲートウェイ（Ｓ−ＧＷ：Ｓｅｒｖｉｎｇ  Ｇａｔｅｗａｙ）に接続されている。Ｓ１インターフェースは、ＭＭＥ／サービングゲートウェイとｅＮＢとの間の多対多関係をサポートする。ＳＧＷは、ユーザデータパケットをルーティングして転送する一方で、ｅＮＢ間のハンドオーバー時におけるユーザプレーンのモビリティアンカーとして機能し、さらに、ＬＴＥと他の３ＧＰＰ技術との間のモビリティのためのアンカー（Ｓ４インターフェースを終端させ、２Ｇ／３ＧシステムとＰＤＮ  ＧＷとの間でトラヒックを中継する）として機能する。ＳＧＷは、アイドル状態のＵＥに対して、ＤＬデータ経路を終端させ、そのＵＥにＤＬデータが到着した場合にページングをトリガーする。ＳＧＷは、ＵＥのコンテキスト（たとえば、ＩＰベアラサービスのパラメータまたはネットワーク内部ルーティング情報）を管理および格納する。また、合法傍受（ｌａｗｆｕｌ  ｉｎｔｅｒｃｅｐｔｉｏｎ）の場合にユーザトラヒックの複製を実行する。
【０００４】
ＭＭＥは、ＬＴＥアクセスネットワークの主要な制御ノードである。ＭＭＥは、アイドルモードのＵＥの追跡およびページング手順（再送信を含む）の役割を担う。ＭＭＥは、ベアラのアクティブ化／非アクティブ化プロセスに関与し、さらには、最初のアタッチ時と、コアネットワーク（ＣＮ：Ｃｏｒｅ  Ｎｅｔｗｏｒｋ）ノードの再配置を伴うＬＴＥ内ハンドオーバー時とに、ＵＥのＳＧＷを選定する役割も担う。また、（ＨＳＳと対話することによって）ユーザを認証する役割を担う。非アクセス層（ＮＡＳ：Ｎｏｎ−Ａｃｃｅｓｓ  Ｓｔｒａｔｕｍ）シグナリングは、ＭＭＥにおいて終端される。ＭＭＥは、一時的なＩＤを生成してＵＥに割り当てる役割も担う。ＭＭＥは、サービスプロバイダの公有地モバイルネットワーク（ＰＬＭＮ：Ｐｕｂｌｉｃ  Ｌａｎｄ  Ｍｏｂｉｌｅ  Ｎｅｔｗｏｒｋ）に入るためのＵＥの認証をチェックし、ＵＥのローミング制約を実施する。ＭＭＥは、ＮＡＳシグナリングの暗号化／完全性保護においてネットワーク内の終端点であり、セキュリティキーの管理を行う。シグナリングの合法傍受も、ＭＭＥによってサポートされる。また、ＭＭＥは、ＬＴＥアクセスネットワークと２Ｇ／３Ｇアクセスネットワークとの間のモビリティのための制御プレーン機能を提供し、ＳＧＳＮからのＳ３インターフェースを終端させる。さらに、ＭＭＥは、ローミングするＵＥのためのホームＨＳＳに向かうＳ６ａインターフェースを終端させる。
【０００５】
３ＧＰＰ  ＬＴＥシステムのダウンリンクコンポーネントキャリアは、いわゆるサブフレームにおける時間−周波数領域でさらに分割される。３ＧＰＰ  ＬＴＥにおいて、各サブフレームは、２つのダウンリンクスロットに分割される。第１のダウンリンクスロットは、第１のＯＦＤＭシンボル内の制御チャネル領域（ＰＤＣＣＨ領域）を備える。各サブフレームは、時間領域内の所与数のＯＦＤＭシンボルから成り（３ＧＰＰ  ＬＴＥ（Ｒｅｌ．８）では１２個または１４個のＯＦＤＭシンボル）、各ＯＦＤＭシンボルはコンポーネントキャリアの帯域幅全体に広がる。したがって、ＯＦＤＭシンボルはそれぞれ、各サブキャリアで送信される多くの変調シンボルから成る。
【０００６】
たとえば、３ＧＰＰロングタームエボリューション（ＬＴＥ）において使用されるＯＦＤＭ等を使用するマルチキャリア通信システムを仮定すると、スケジューラによって割り当て可能なリソースの最小単位は、１つの「リソースブロック」である。物理リソースブロック（ＰＲＢ：Ｐｈｙｓｉｃａｌ  Ｒｅｓｏｕｒｃｅ  Ｂｌｏｃｋ）は、時間領域における連続するＯＦＤＭシンボル（たとえば、７個のＯＦＤＭシンボル）および周波数領域における連続するサブキャリア（たとえば、コンポーネントキャリアの１２本のサブキャリア）として規定される。したがって、３ＧＰＰ  ＬＴＥ（Ｒｅｌ．８）では、物理リソースブロックがリソースエレメントから成り、時間領域における１つのスロットおよび周波数領域における１８０ｋＨｚに対応する（ダウンリンクリソースグリッドに関するさらなる詳細については、たとえば非特許文献１の第６．２項（ｈｔｔｐ：／／ｗｗｗ．３ｇｐｐ．ｏｒｇで入手可能であり、本明細書に援用する）を参照）。
【０００７】
１つのサブフレームは、２つのスロットから成る。いわゆる「通常の（ｎｏｒｍａｌ）」ＣＰ（巡回プレフィックス）が使用されるときにはサブフレーム内に１４個のＯＦＤＭシンボルが存在し、いわゆる「拡張（ｅｘｔｅｎｄｅｄ）」ＣＰが使用されるときにはサブフレーム内に１２個のＯＦＤＭシンボルが存在する。専門用語を目的として、以下では、サブフレーム全体に広がる同じ連続サブキャリアと同等の時間−周波数リソースを「リソースブロックペア（ｒｅｓｏｕｒｃｅ  ｂｌｏｃｋ  ｐａｉｒ）」または同等の「ＲＢペア（ＲＢ  ｐａｉｒ）」もしくは「ＰＲＢペア（ＰＲＢ  ｐａｉｒ）」と称する。
【０００８】
用語「コンポーネントキャリア（ｃｏｍｐｏｎｅｎｔ  ｃａｒｒｉｅｒ）」は、周波数領域におけるいくつかのリソースブロックの組み合わせを表す。ＬＴＥの今後のリリースにおいて、用語「コンポーネントキャリア」はもはや使用されず、代わりに、その専門用語がダウンリンクリソースおよび任意選択としてアップリンクリソースの組み合わせを表す「セル」に変更される。ダウンリンクリソースのキャリア周波数とアップリンクリソースのキャリア周波数との間のリンク付けは、ダウンリンクリソースで送信されるシステム情報において指定される。以降のリリースにも、コンポーネントキャリアの構造に関する同様の仮定が当てはまる。
【０００９】
＜ＯＳＩレイヤの総括＞
図３Ａは、ＬＴＥアーキテクチャの詳述の基礎となるレイヤモデルの概要を与えている。
【００１０】
開放型システム間相互接続（ＯＳＩ：Ｏｐｅｎ  Ｓｙｓｔｅｍｓ  Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ）参照モデル（ＯＳＩモデルまたはＯＳＩ参照モデル）は、通信およびコンピュータネットワークプロトコル設計用の階層化抽象記述である。ＯＳＩモデルは、システムの機能を一連のレイヤに分割する。各レイヤは、下のレイヤの機能のみを使用し、上のレイヤには機能をエクスポートするだけの特性を有する。これら一連のレイヤから成るプロトコル挙動を実装したシステムは、「プロトコルスタック」または「スタック」として知られている。その主要な特徴は、レイヤ間の接合にあり、レイヤ同士の相互作用方法に関する仕様を定めている。これは、１つの製造業者により書かれたレイヤが別の製造業者によるレイヤと協働し得ることを意味する。本開示を目的として、以下では、最初の３つのレイヤのみをより詳しく説明する。
【００１１】
物理レイヤすなわちレイヤ１の主目的は、特定の物理媒体（たとえば、同軸ケーブル、ツイストペアケーブル、光ファイバ、エアインターフェース等）を通じた情報（ビット）の伝送である。これにより、通信チャネル上で送信される信号（または、シンボル）へとデータが変換または変調される。
【００１２】
データリンクレイヤ（すなわち、レイヤ２）の目的は、入力データをデータフレームに分割すること（分割・再組み立て（ＳＡＲ：Ｓｅｇｍｅｎｔａｔｉｏｎ  Ａｎｄ  Ｒｅ−ａｓｓｅｍｂｌｙ）機能）によって、上記特定の物理レイヤに適合するように情報フローを成形することである。さらに、失われたフレームの再送信を要求することにより、潜在的な送信エラーを検出して修正するようにしてもよい。これは通常、アドレス指定メカニズムを提供するとともに、データレートを受信機容量と合わせるためのフロー制御アルゴリズムを提供可能である。複数の送信機および受信機が共有媒体を同時に使用する場合、データリンクレイヤは通常、物理媒体へのアクセスを規制・制御するメカニズムを提供する。
【００１３】
データリンクレイヤは、多くの機能を提供するため、サブレイヤ（たとえば、ＵＭＴＳのＲＬＣレイヤおよびＭＡＣレイヤ）に細分されることが多い。レイヤ２プロトコルの代表例は、固定回線ネットワーク用のＰＰＰ／ＨＤＬＣ、ＡＴＭ、フレームリレーおよび無線システム用のＲＬＣ、ＬＬＣ、またはＭＡＣである。レイヤ２のサブレイヤＰＤＣＰ、ＲＬＣ、およびＭＡＣに関する詳細な情報については後述する。なお、本願においては、サブレイヤを「レイヤ」とも称するため、本明細書において使用する用語「レイヤ」は、必ずしもＯＳＩモデルのレイヤを意味しない。
【００１４】
ネットワークレイヤすなわちレイヤ３は、トランスポートレイヤが要求するサービス品質を維持しつつ、１つまた複数のネットワークを介して、可変長のパケットを送信元から宛先に伝送する機能的および手続き的手段を提供する。通常、ネットワークレイヤの主目的はとりわけ、ネットワークルーティング、ネットワーク分割、および輻輳制御機能を実行することである。ネットワークレイヤプロトコルの主な例は、ＩＰ（インターネットプロトコル）またはＸ．２５である。
【００１５】
レイヤ４〜７に関しては、アプリケーションおよびサービスによって、ＯＳＩモデルの特定のレイヤにアプリケーションまたはサービスを結び付けるのが困難となる場合もあることに留意するものとする。レイヤ３よりも上で動作するアプリケーションおよびサービスは、ＯＳＩモデルの異なるレイヤに結び付けられる多様な機能を実行することが多いためである。したがって、特にＴＣＰ（ＵＤＰ）／ＩＰベースのネットワークにおいては、レイヤ４およびその上のレイヤを組み合わせて、いわゆる「アプリケーションレイヤ」を構成する場合もある。
【００１６】
＜レイヤサービスおよびデータ交換＞
以下、本明細書で使用するサービスデータユニット（ＳＤＵ）およびプロトコルデータユニット（ＰＤＵ）という用語を図３Ｂに関して規定する。ＯＳＩモデルのレイヤ間のパケット交換を包括して形式的に記述するため、ＳＤＵおよびＰＤＵエンティティが導入されている。ＳＤＵは、いわゆるサービスアクセスポイント（ＳＡＰ）を介して、レイヤＮにあるプロトコルにサービスを要求するレイヤＮ＋１のプロトコルから送信された情報（データ／情報ブロック）の単位である。ＰＤＵは、同じレイヤＮにある同じプロトコルの送信機および受信機におけるピアプロセス間で交換された情報の単位である。
【００１７】
ＰＤＵは一般的に、レイヤＮの特定のヘッダに続き、任意選択としてトレーラにより終了となる受信ＳＤＵを処理したものから成るペイロード部によって形成されている。これらのピアプロセス間には（レイヤ１を除いて）直接的な物理接続が存在しないため、ＰＤＵは、レイヤＮ−１に転送されて処理される。したがって、レイヤＮのＰＤＵは、レイヤＮ−１の観点ではＳＤＵである。
【００１８】
＜ＬＴＥユーザプレーン（ＵＰ（Ｕ−Ｐｌａｎｅ））および制御プレーン（ＣＰ（Ｃ−Ｐｌａｎｅ）プロトコル＞
ＬＴＥレイヤ２ユーザプレーン／制御プレーンプロトコルスタックは、ＰＤＣＰ、ＲＬＣ、およびＭＡＣという３つのサブレイヤを含む。
【００１９】
上記説明の通り、送信側においては、各レイヤがサービスを提供するより上のレイヤからＳＤＵを受信し、より下のレイヤにＰＤＵを出力する。ＲＬＣレイヤは、ＰＤＣＰレイヤからパケットを受信する。これらのパケットは、ＰＤＣＰの観点からはＰＤＣＰ  ＰＤＵと称し、ＲＬＣの観点からはＲＬＣ  ＳＤＵを表す。ＲＬＣレイヤは、下のレイヤすなわちＭＡＣレイヤに提供されるパケットを生成する。ＲＬＣによりＭＡＣレイヤに提供されるパケットは、ＲＬＣの観点からはＲＬＣ  ＰＤＵであり、ＭＡＣの観点からはＭＡＣ  ＳＤＵである。受信側ではプロセスが逆転し、各レイヤが上のレイヤまでＳＤＵを受け渡して、そこでＰＤＵとして受信される。
【００２０】
物理レイヤは本質的に、ターボ符号化および巡回冗長検査（ＣＲＣ）により保護されたビットパイプを提供するが、リンクレイヤプロトコルは、信頼性、セキュリティ、および完全性の向上によって、上位レイヤへのサービスを増強する。また、リンクレイヤは、マルチユーザ媒体アクセスおよびスケジューリングを担う。ＬＴＥリンクレイヤ設計の主要な課題の１つとして、広範な種々サービスおよびデータレートを伴うインターネットプロトコル（ＩＰ）データフローに対して、所要の信頼性レベルおよび遅延を与えることが挙げられる。特に、プロトコルオーバーヘッドのスケーリングが必要である。たとえば、ボイスオーバーＩＰ（ＶｏＩＰ）フローは、１００ｍｓオーダーの遅延および最大１パーセントのパケット損失を許容し得るものと広く仮定する。一方、ＴＣＰファイルのダウンロードは、帯域幅遅延が小さな製品のリンク上で良好に実行されることが良く知られている。結果として、非常に高いデータレート（たとえば、１００Ｍｂ／ｓ）でのダウンロードには、さらに遅延を抑える必要があり、また、ＶｏＩＰトラヒックよりもＩＰパケット損失の影響を受けやすい。
【００２１】
上記は概して、一部がつながったＬＴＥリンクレイヤの３つのサブレイヤによって実現される。パケットデータコンバージェンスプロトコル（ＰＤＣＰ：Ｐａｃｋｅｔ  Ｄａｔａ  Ｃｏｎｖｅｒｇｅｎｃｅ  Ｐｒｏｔｏｃｏｌ）サブレイヤは主として、ＩＰヘッダの圧縮および暗号化を担う。また、ｅＮＢ間ハンドオーバーの場合の低損失モビリティをサポートするとともに、上位レイヤの制御プロトコルに完全性保護を提供する。無線リンク制御（ＲＬＣ）サブレイヤは主として、ＡＲＱ機能を有しており、また、データの分割および連結をサポートする。後者の２つによって、データレートとは無関係にプロトコルオーバーヘッドが最小となる。最後に、媒体アクセス制御（ＭＡＣ）サブレイヤは、ＨＡＲＱを提供するとともに、スケジューリング動作およびランダムアクセス等の媒体アクセスに必要な機能を担う。
【００２２】
特に、媒体アクセス制御（ＭＡＣ）レイヤは、ＬＴＥの無線プロトコルスタックのレイヤ２アーキテクチャにおける最も下のサブレイヤであり、たとえば３ＧＰＰ技術規格である非特許文献２によって規定されている。下の物理レイヤとはトランスポートチャネルを通じて接続されており、上のＲＬＣレイヤとは論理チャネルを通じて接続されている。したがって、ＭＡＣレイヤは、論理チャネルとトランスポートチャネルとの間の多重化および逆多重化を実行する。送信側におけるＭＡＣレイヤは、論理チャネルを通じて受け取るＭＡＣ  ＳＤＵからＭＡＣ  ＰＤＵ（トランスポートブロックとしても知られている）を構築し、受信側におけるＭＡＣレイヤは、トランスポートチャネルを通じて受け取るＭＡＣ  ＰＤＵからＭＡＣ  ＳＤＵを復元する。
【００２３】
ＭＡＣレイヤは、論理チャネルを通じてＲＬＣレイヤにデータ伝送サービスを提供し（本明細書に援用する非特許文献３の第５．４項および第５．３項を参照）、この論理チャネルは、制御データ（たとえば、ＲＲＣシグナリング）を伝える制御論理チャネルまたはユーザプレーンデータを伝えるトラヒック論理チャネルのいずれかである。一方、ＭＡＣレイヤからのデータは、トランスポートチャネル（ダウンリンクまたはアップリンクとして分類される）を通じて物理レイヤと交換される。無線を通じた送信方式に応じて、データがトランスポートチャネルに多重化される。ＭＡＣ  ＳＤＵのほか、ＭＡＣ  ＰＤＵが必要に応じて、複数種類のＭＡＣ制御エレメントおよびパディングをさらに含んでいてもよい。
【００２４】
物理レイヤは、エアインターフェースを介して、データおよび制御情報を実際に送信する役割を担う。すなわち、物理レイヤは、送信側ではエアインターフェース上で、ＭＡＣトランスポートチャネルからのすべての情報を搬送する。物理レイヤによって実行されるいくつかの重要な機能としては、符号化および変調、リンクアダプテーション（ＡＭＣ）、電力制御、セルサーチ（最初の同期およびハンドオーバーを目的とする）、ＲＲＣレイヤのための他の測定（ＬＴＥシステムの内側およびシステム間）が挙げられる。物理レイヤは、送信パラメータ（変調方式、符号化率（すなわち変調・符号化方式（ＭＣＳ））、物理リソースブロックの数等）に基づいて、送信を実行する。物理レイヤの機能に関する別の情報は、３ＧＰＰ技術規格である非特許文献４に記載されており、これを本明細書に援用する。
【００２５】
無線リソース制御（ＲＲＣ）レイヤは、無線インターフェースにおけるＵＥとｅＮＢとの間の通信および複数のセルを横切って移動するＵＥのモビリティを制御する。ＲＲＣプロトコルは、ＮＡＳ情報の伝送もサポートする。ＲＲＣ＿ＩＤＬＥのＵＥに対して、ＲＲＣは、ネットワークからの着信呼の通知をサポートする。ＲＲＣ接続制御は、ＲＲＣ接続の確立、変更、および解除に関連するすべての手順（ページング、測定の設定および報告、無線リソースの設定、最初のセキュリティ起動、シグナリング無線ベアラ（ＳＲＢ：Ｓｉｇｎａｌｌｉｎｇ  Ｒａｄｉｏ  Ｂｅａｒｅｒ）およびユーザデータを伝える無線ベアラ（データ無線ベアラ（ＤＲＢ：Ｄａｔａ  Ｒａｄｉｏ  Ｂｅａｒｅｒ））の確立を含む）をカバーする。
【００２６】
無線リンク制御（ＲＬＣ）サブレイヤは、主としてＡＲＱ機能を有しており、また、データの分割および連結をサポートする。すなわち、ＲＬＣレイヤは、ＲＬＣ  ＳＤＵのフレーミングを実行し、ＭＡＣレイヤによって示されるサイズにする。後者の２つによって、データレートとは無関係にプロトコルオーバーヘッドが最小となる。ＲＬＣレイヤは、論理チャネルを介してＭＡＣレイヤに接続されている。各論理チャネルは、さまざまなタイプのトラヒックを伝える。ＲＬＣレイヤの上のレイヤは通常、ＰＤＣＰレイヤであるが、場合によってはＲＲＣレイヤである。すなわち、論理チャネルＢＣＣＨ（ブロードキャスト制御チャネル）、ＰＣＣＨ（ページング制御チャネル）、およびＣＣＣＨ（共通制御チャネル）で送信されるＲＲＣメッセージは、セキュリティ保護を必要としないため、ＰＤＣＰレイヤをバイパスしてＲＬＣレイヤに直接渡される。
【００２７】
＜ＲＬＣ再送信プロトコル＞
ＲＬＣは、行方不明のＰＤＵの再送信を要求するように設定されている場合、確認モード（ＡＭ：Ａｃｋｎｏｗｌｅｄｇｅｄ  Ｍｏｄｅ）で動作していると言える。これは、ＷＣＤＭＡ／ＨＳＰＡにおいて用いられる対応するメカニズムに類似する。ＲＬＣには概して、透過モード（ＴＭ：Ｔｒａｎｓｐａｒｅｎｔ  Ｍｏｄｅ）、非確認モード（ＵＭ：Ｕｎａｃｋｎｏｗｌｅｄｇｅｄ  Ｍｏｄｅ）、および確認モード（ＡＭ：Ａｃｋｎｏｗｌｅｄｇｅｄ  Ｍｏｄｅ）という３つの動作モードが存在する。各ＲＬＣエンティティは、ＲＲＣによって、これらのモードのうちの１つで動作するように設定されている。
【００２８】
透過モードにおいては、上位レイヤから受信したＲＬＣ  ＳＤＵにプロトコルオーバーヘッドが追加されることはない。特殊な場合に、分割／再組み立て能力が制限された送信を達成可能となる。分割／再組み立てが用いられるか否かに関わらず、無線ベアラセットアップ手順において交渉の必要がある。透過モードは、たとえば会話のように遅延の影響を非常に受けやすいサービスに用いられる。
【００２９】
非確認モードにおいては、再送信プロトコルが使用されないため、データ配送が保証されない。ＰＤＵ構造には、上位レイヤにおける完全性観測のためのシーケンス番号を含む。ＲＬＣシーケンス番号に基づいて、受信ＵＭ  ＲＬＣエンティティは、受信ＲＬＣ  ＰＤＵの並べ替えを実行可能である。分割および連結は、データに追加されたヘッダフィールドによってもたらされる。非確認モードのＲＬＣエンティティは、アップリンクとダウンリンクとの間に関係が規定されていないため、単向性である。誤りのあるデータが受信された場合は、設定に応じて、対応するＰＤＵの破棄またはマーキングが行われる。送信機においては、タイマーが指定する一定の時間内に送信されないＲＬＣ  ＳＤＵが送信バッファから破棄または削除される。上位レイヤから受信されたＲＬＣ  ＳＤＵは、送信側でＲＬＣ  ＰＤＵへと分割／連結される。受信側では、これに対応して再組み立てが実行される。非確認モードは、たとえば特定のＲＲＣシグナリング手順におけるＭＢＭＳおよびボイスオーバーＩＰ（ＶｏＩＰ）等のセルブロードキャストサービス等、配送時間の短さと比較して配送エラーのなさは重要でないサービスに用いられる。
【００３０】
確認モードにおいて、ＲＬＣレイヤは、自動再送要求（ＡＲＱ）プロトコルによるエラー修正をサポートするとともに、通常は、エラーのないデータ配送が最大の関心事であるファイル伝送等のＩＰベースのサービスに用いられる。ＲＬＣ再送信は、たとえば相手側ＲＬＣ受信エンティティから受信したＲＬＣステータスレポートすなわちＡＣＫ／ＮＡＣＫに基づく。確認モードは、エアインターフェースの高いビット誤り率の存在下における再送信を通じたパケットデータの確実なトランスポートのために設計されている。ＰＤＵの誤りまたは損失の場合は、受信側からのＲＬＣステータスレポートの受信に際して、送信側により再送信が実行される。
【００３１】
ＡＲＱは、誤りのあるＰＤＵまたは行方不明のＰＤＵを再送信する再送信方式として用いられる。たとえば、入ってくるシーケンス番号を監視することにより、受信ＲＬＣエンティティは、行方不明のＰＤＵを識別することができる。そして、受信ＲＬＣ側でＲＬＣステータスレポートを生成し、送信ＲＬＣエンティティにフィードバックして、行方不明のＰＤＵまたは復号化に失敗したＰＤＵの再送信を要求することができる。また、ＲＬＣステータスレポートは、送信機によりポーリング可能である。すなわち、ＲＬＣ送信機によるポーリング機能の使用により、ＲＬＣ受信側からステータスレポートが取得され、受信バッファステータスがＲＬＣ送信機に通知される。ステータスレポートは、ＨＡＲＱ並べ替えが完了する最後のＲＬＣデータＰＤＵまで、ＲＬＣデータＰＤＵに関する肯定応答（ＡＣＫ）もしくは否定応答情報（ＮＡＣＫ）またはそれらの一部を提供する。ＲＬＣ受信側は、ポーリングフィールドが「１」に設定されている場合またはＲＬＣデータＰＤＵが行方不明と検出された場合にステータスレポートをトリガーする。非特許文献５の第５．２．３項には、ＲＬＣ送信機においてＲＬＣステータスレポートのポーリングをトリガーする特定のトリガーが規定されており、これを本明細書に援用する。送信機においては、送信ウィンドウ内のＰＤＵに対してのみ送信が可能であり、当該送信ウィンドウは、ＲＬＣステータスレポートによってのみ更新される。したがって、ＲＬＣステータスレポートが遅延する場合は、送信ウィンドウを進めることができず、送信が詰まってしまう可能性もある。受信側は、トリガーされた場合にＲＬＣステータスレポートを送信側に送信する。
【００３２】
＜レイヤ１／レイヤ２制御シグナリング＞
スケジューリング対象のユーザにユーザの割り当て状態、トランスポートフォーマット、およびその他の送信関連情報（たとえば、ＨＡＲＱ情報、送信電力制御（ＴＰＣ：Ｔｒａｎｓｍｉｔ  Ｐｏｗｅｒ  Ｃｏｎｔｒｏｌ）コマンド）を通知する目的で、Ｌ１／Ｌ２制御シグナリングがデータとともにダウンリンクで送信される。Ｌ１／Ｌ２制御シグナリングは、サブフレーム内でダウンリンクデータとともに多重化される（ユーザ割り当てがサブフレーム単位で変化し得るものと仮定する）。ユーザ割り当てをＴＴＩ（送信時間間隔）ベースで実行することもできる。その場合、ＴＴＩ長がサブフレームの整数倍となり得ることに留意するものとする。ＴＴＩ長は、サービスエリア内ですべてのユーザに対して一定であってもよいし、異なるユーザに対して異なる長さであってもよいし、ユーザごとに動的であってもよい。一般的に、Ｌ１／Ｌ２制御シグナリングは、ＴＴＩ当たり１回送信すればよい。以下では、一般性を失うことなく、ＴＴＩが１サブフレームに等しいものと仮定する。
【００３３】
Ｌ１／Ｌ２制御シグナリングは、物理ダウンリンク制御チャネル（ＰＤＣＣＨ）で送信される。ＰＤＣＣＨは、ダウンリンク制御情報（ＤＣＩ：Ｄｏｗｎｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｉｎｆｏｒｍａｔｉｏｎ）としてのメッセージを搬送する。ＤＣＩには、ほとんどの場合、移動端末またはＵＥ群へのリソース割り当ておよびその他の制御情報が含まれる。複数のＰＤＣＣＨを１つのサブフレーム内で送信可能である。
【００３４】
一般的に、アップリンク無線リソースまたはダウンリンク無線リソースを割り当てる目的でＬ１／Ｌ２制御シグナリングで送られる情報は（特にＬＴＥ（−Ａ）Ｒｅｌ．１０）、以下の項目に分類可能である。
【００３５】
ユーザ識別情報（Ｕｓｅｒ  Ｉｄｅｎｔｉｔｙ）：割り当てる対象のユーザを示す。この情報は通常、ＣＲＣをユーザ識別情報によってマスクすることによりチェックサムに含まれる。
【００３６】
リソース割り当て情報（Ｒｅｓｏｕｒｃｅ  Ａｌｌｏｃａｔｉｏｎ  Ｉｎｆｏｒｍａｔｉｏｎ）：ユーザが割り当てられるリソース（たとえば、リソースブロック（ＲＢ））を示す。あるいは、この情報は、リソースブロック割り当て（ＲＢＡ：Ｒｅｓｏｕｒｃｅ  Ｂｌｏｃｋ  Ａｓｓｉｇｎｍｅｎｔ）と称する。なお、ユーザが割り当てられるＲＢの数は、動的とすることができる。
【００３７】
キャリアインジケータ（Ｃａｒｒｉｅｒ  ｉｎｄｉｃａｔｏｒ）：第１のキャリアで送信される制御チャネルが、第２のキャリアに関連するリソースすなわち第２のキャリアのリソースまたは第２のキャリアに関連するリソースを割り当てる場合に使用される（クロスキャリアスケジューリング）。
【００３８】
変調・符号化方式（Ｍｏｄｕｌａｔｉｏｎ  ａｎｄ  ｃｏｄｉｎｇ  ｓｃｈｅｍｅ）：採用される変調方式および符号化率を決定する。
【００３９】
ＨＡＲＱ情報：データパケットまたはその一部の再送信時に特に有用な新規データインジケータ（ＮＤＩ：Ｎｅｗ  Ｄａｔａ  Ｉｎｄｉｃａｔｏｒ）および／または冗長バージョン（ＲＶ：Ｒｅｄｕｎｄａｎｃｙ  Ｖｅｒｓｉｏｎ）等。
【００４０】
電力制御コマンド：割り当て対象のアップリンクのデータまたは制御情報の送信時の送信電力を調整する。
【００４１】
参照信号情報：割り当てと関連する参照信号の送信または受信に使用される適用循環シフトおよび／または直交カバーコード（ＯＣＣ）インデックス等。
【００４２】
アップリンク割り当てインデックスまたはダウンリンク割り当てインデックス：割り当ての順序を識別するために使用され、ＴＤＤシステムにおいて特に有用である。
【００４３】
ホッピング情報：たとえば、周波数ダイバーシティを増大させる目的でリソースホッピングを適用するかどうか、および適用方法を指示する。
【００４４】
ＣＳＩ要求：割り当てられるリソースにおいてチャネル状態情報（Ｃｈａｎｎｅｌ  Ｓｔａｔｅ  Ｉｎｆｏｒｍａｔｉｏｎ）を送信するようにトリガーするために使用される。
【００４５】
マルチクラスタ情報：シングルクラスタ（ＲＢの連続的なセット）で送信を行うか、マルチクラスタ（連続的なＲＢの少なくとも２つの不連続なセット）で送信を行うかを指示して制御するために使用されるフラグである。マルチクラスタ割り当ては、３ＧＰＰ  ＬＴＥ−（Ａ）Ｒｅｌ．１０により導入されている。
【００４６】
上記リストは、すべてを網羅したものではなく、また、使用されるＤＣＩフォーマットによっては、前述の情報項目すべてを各ＰＤＣＣＨ送信に含める必要はないことに留意するものとする。
【００４７】
ダウンリンク制御情報は、全体サイズおよび前述のフィールドに含まれる情報が異なる複数のフォーマットで生じる。ＬＴＥについて現在規定されているさまざまなＤＣＩフォーマットは以下の通りであり、非特許文献６の第５．３．３．１項（ｈｔｔｐ：／／ｗｗｗ．３ｇｐｐ．ｏｒｇで入手可能であり、本明細書に援用する）に詳しく記載されている。たとえば、以下のＤＣＩフォーマットを使用して、アップリンクのリソースグラントを搬送可能である。
【００４８】
フォーマット０：ＤＣＩフォーマット０は、ＰＵＳＣＨのリソースグラントの送信に用いられるものであり、アップリンク送信モード１または２において単一アンテナポート送信を使用する。
【００４９】
フォーマット４：ＤＣＩフォーマット４は、ＰＵＳＣＨのスケジューリングに用いられるものであり、アップリンク送信モード２において閉ループ空間多重送信を使用する。
【００５０】
＜ＬＴＥのアップリンクアクセス方式＞
アップリンク方式によれば、スケジューリングによるアクセス（すなわち、ｅＮＢによる制御）およびコンテンションベースのアクセスの両者が可能となる。
【００５１】
スケジューリングによるアクセスの場合、ＵＥには、アップリンクデータ送信用の一定時間にわたる特定の周波数リソース（すなわち、時間／周波数リソース）が割り当てられる。ただし、一部の時間／周波数リソースは、コンテンションベースのアクセスに対して割り当て可能である。これらの時間／周波数リソースにおいて、ＵＥは、最初のスケジューリングなしに送信可能である。ＵＥがコンテンションベースのアクセスを行う１つのシナリオとして、たとえばランダムアクセスすなわちセルに対する最初のアクセスまたはアップリンクリソースを要求する最初のアクセスをＵＥが実行する場合が挙げられる。
【００５２】
スケジューリングによるアクセスの場合、ｅＮｏｄｅＢスケジューラは、アップリンクデータ送信用の一意の周波数／時間リソースをユーザに割り当てる。より具体的に、スケジューラは、どのＵＥが、どの物理チャネルリソース（周波数）、および移動端末が送信に使用する対応するトランスポートフォーマットで送信が許可されたかを決定する。
【００５３】
割り当て情報は、スケジューリンググラントを介して、Ｌ１／Ｌ２制御チャネル上で送信されることにより、ＵＥに伝えられる。スケジューリンググラントメッセージには、ＵＥが使用を許可された周波数帯の部分、グラントの有効期間、および次回のアップリンク送信にＵＥが使用すべきトランスポートフォーマットに関する情報を含む。最も短い有効期間は、１サブフレームである。また、選択された方式に応じて、別の情報がグラントメッセージに含まれていてもよい。ＵＬ−ＳＣＨ上で送信する権利の付与には、「ＵＥ当たり」のグラントのみが使用される（すなわち、「ＵＥ当たり、ＲＢ当たり」のグラントは存在しない）。したがって、ＵＥは、いくつかのルールに従って無線ベアラ間で割り当てリソースを配分する必要がある。ＨＳＵＰＡと異なり、ＵＥベースのトランスポートフォーマットの選択はない。ｅＮＢは、いくつかの情報（たとえば、チャネル品質フィードバック、報告されたスケジューリング情報、およびＱｏＳ情報）に基づいてトランスポートフォーマットを決定する。ＵＥは、その選択されたトランスポートフォーマットに従う必要がある。
【００５４】
スケジューリングの一般的なモードは動的スケジューリングであり、ダウンリンク送信リソースの割り当て用のダウンリンク割り当てメッセージおよびアップリンク送信リソースの割り当て用のアップリンクグラントメッセージを用いて行われるが、これらは通例、特定のサブフレームに対してのみ有効である。これらのメッセージは、ＵＥのＣ−ＲＮＴＩ（Ｃｅｌｌ  Ｒａｄｉｏ  Ｎｅｔｗｏｒｋ  Ｔｅｍｐｏｒａｒｙ  Ｉｄｅｎｔｉｆｉｅｒ）を用いてＰＤＣＣＨ上で送信される。動的スケジューリングは、ＴＣＰ等、トラヒックのレートが集中的かつ動的なサービスタイプにおいて効率的である。
【００５５】
動的スケジューリングのほか、１サブフレームよりも長い期間にわたって無線リソースを準静的に設定してＵＥに割り当てることにより、サブフレームごとのＰＤＣＣＨを通じた特定のダウンリンク割り当てメッセージまたはアップリンクグラントメッセージの必要性を回避し得るパーシステントなスケジューリングが規定されている。パーシステントなスケジューリングは、データパケットのサイズが小さく、周期的で準静的なＶｏＩＰ等のサービスに有用である。このため、動的スケジューリングの場合と比較して、ＰＤＣＣＨのオーバーヘッドは大幅に低下する。
【００５６】
＜論理チャネル優先順位決定（ＬＣＰ：Ｌｏｇｉｃａｌ  Ｃｈａｎｎｅｌ  Ｐｒｉｏｒｉｔｉｚａｔｉｏｎ）手順＞
アップリンクについて、割り当てられた無線リソースを用いて送信するＭＡＣ  ＰＤＵをＵＥが生成するプロセスは、十分に標準化されている。これは、異なるＵＥ実装間で最適かつ一貫するように各設定無線ベアラのＱｏＳをＵＥが満たすように設計されている。ＰＤＣＣＨ上で伝えられるアップリンク送信リソースグラントメッセージに基づいて、ＵＥは、新たなＭＡＣに含まれる各論理チャネルのデータ量を決定するとともに、ＭＡＣ制御エレメント用のスペースを割り当てる必要がある。
【００５７】
複数の論理チャネルからのデータでＭＡＣ  ＰＤＵを構成する際、最も簡単かつ直感的な方法は、絶対優先順位に基づく方法であり、この方法では、論理チャネルの優先順位の降順にＭＡＣ  ＰＤＵスペースが論理チャネルに割り当てられる。すなわち、ＭＡＣ  ＰＤＵにおいては、優先順位が最も高い論理チャネルからのデータが最初に提供された後、優先順位が次に高い論理チャネルからのデータが提供され、ＭＡＣ  ＰＤＵスペースが無くなるまで継続される。絶対優先順位に基づく方法は、ＵＥ実装の観点では非常に簡単であるが、優先順位が低い論理チャネルからのデータが欠落する場合もある。この欠落は、優先順位が高い論理チャネルからのデータがＭＡＣ  ＰＤＵスペース全体を占めるため、優先順位が低い論理チャネルからのデータを送信できないことを意味する。
【００５８】
ＬＴＥにおいては、論理チャネルごとに優先ビットレート（ＰＢＲ：Ｐｒｉｏｒｉｔｉｚｅｄ  Ｂｉｔ  Ｒａｔｅ）が規定され、重要度の順にデータが送信されるとともに、優先順位が低いデータの欠落が回避される。ＰＢＲは、論理チャネルに対して保証された最低データレートである。当該論理チャネルの優先順位が低い場合であっても、少なくとも微小なＭＡＣ  ＰＤＵスペースの割り当てによって、ＰＢＲが保証される。このため、ＰＢＲの使用により、欠落の問題を回避することができる。
【００５９】
ＰＢＲによるＭＡＣ  ＰＤＵの構成は、２つの範囲から成る。第１の範囲においては、論理チャネルの優先順位の降順で各論理チャネルが提供されるが、ＭＡＣ  ＰＤＵに含まれる各論理チャネルからのデータの量は、その論理チャネルの設定されたＰＢＲ値に対応する量に最初から制限されている。すべての論理チャネルがそれぞれのＰＢＲ値まで提供された後、ＭＡＣ  ＰＤＵに余地があれば、第２の範囲が実行される。第２の範囲においては、各論理チャネルが再び優先順位の降順で提供される。第１の範囲と比較した場合の第２の範囲の大きな違いは、優先順位が高いすべての論理チャネルにおいて送信するデータがもうない場合にのみ、優先順位が低い各論理チャネルにＭＡＣ  ＰＤＵスペースを割り当て可能なことである。
【００６０】
ＭＡＣ  ＰＤＵは、設定された各論理チャネルからのＭＡＣ  ＳＤＵのみならず、ＭＡＣ  ＣＥを含んでいてもよい。パディングＢＳＲを除いて、ＭＡＣ  ＣＥは、ＭＡＣレイヤの動作を制御することから、論理チャネルからのＭＡＣ  ＳＤＵよりも優先順位が高い。このため、ＭＡＣ  ＰＤＵが構成される場合、ＭＡＣ  ＣＥが存在するならば最初に含まれ、残りのスペースは、論理チャネルからのＭＡＣ  ＳＤＵに用いられる。そして、別のスペースが残っており、ＢＳＲを含むのに十分な大きさであれば、パディングＢＳＲがトリガーされ、ＭＡＣ  ＰＤＵに含まれる。
【００６１】
論理チャネルの優先順位付けは、たとえば非特許文献３の第５．４．３．１項において標準化されており、これを本明細書に援用する。１つのＴＴＩにおいて複数のＭＡＣ  ＰＤＵを送信するようにＵＥが要求された場合にＭＡＣ制御エレメントが含まれるＭＡＣ  ＰＤＵを決定するかどうかは、ＵＥ実装次第である。
【００６２】
＜バッファステータスレポート＞
ＵＥからｅＮｏｄｅＢへのバッファステータスレポート（ＢＳＲ）は、ｅＮｏｄｅＢによるアップリンクリソースの割り当てすなわちアップリンクスケジューリングの支援に用いられる。ダウンリンクの場合、ｅＮＢスケジューラは、各ＵＥに配送されるデータの量を明らかに認識しているが、アップリンク方向の場合は、スケジューリングの決定がｅＮＢでなされるとともに、データのバッファがＵＥにあることから、ＵＬ−ＳＣＨ上で送信する必要があるデータの量を示すには、ＵＥからｅＮＢにＢＳＲが送られる必要がある。
【００６３】
ＬＴＥの場合のバッファステータスレポートのＭＡＣ制御エレメントは、長いＢＳＲ（ＬＣＧ  ＩＤ＃０〜３に対応する４つのバッファサイズフィールドを伴う）または短いＢＳＲ（１つのＬＣＧ  ＩＤフィールドおよび１つの対応するバッファサイズフィールドを伴う）のいずれかから成る。バッファサイズフィールドは、論理チャネル群のすべての論理チャネルにわたって利用可能なデータの総量を示すものであり、異なるバッファサイズレベルのインデックスとして符号化されたバイトの数で示される（非特許文献３の第６．１．３．１項も参照（本明細書に援用））。
【００６４】
ＵＥによって短いＢＳＲか長いＢＳＲのいずれが送信されるかは、トランスポートブロックにおいて利用可能な送信リソース、非空バッファを有する論理チャネル群の数、および特定のイベントがＵＥでトリガーされるかによって決まる。長いＢＳＲは、４つの論理チャネル群のデータの量を報告する一方、短いＢＳＲは、優先順位が最も高い論理チャネル群に対してのみバッファリングされたデータの量を示す。
【００６５】
論理チャネル群の概念を導入する理由は、ＵＥが５つ以上の論理チャネルを設定可能であるものの、個々の論理チャネルごとにバッファステータスを報告するのは、シグナリングオーバーヘッドが大きくなり過ぎるためである。したがって、ｅＮＢは、各論理チャネルを論理チャネル群に割り当てる。好ましくは、ＱｏＳ要件が同一／類似の論理チャネルは、同じ論理チャネル群内で割り当てられるものとする。
【００６６】
ＵＥは、ＢＳＲがトリガーされた場合にトランスポートブロックにおいてＢＳＲを含むようにアップリンクリソースが割り当てられていない場合、スケジューリングリクエスト（ＳＲ）をｅＮｏｄｅＢに送って、ＢＳＲを送信するアップリンクリソースが割り当てられるようにする。シングルビットのスケジューリングリクエストが物理アップリンク制御チャネル（ＰＵＣＣＨ：Ｐｈｙｓｉｃａｌ  Ｕｐｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ）上で送信される（専用スケジューリングリクエスト（Ｄ−ＳＲ：Ｄｅｄｉｃａｔｅｄ  Ｓｃｈｅｄｕｌｉｎｇ  Ｒｅｑｕｅｓｔ）。あるいは、ランダムアクセス手順（ＲＡＣＨ）の実行により、ＢＳＲを送信するためのアップリンク無線リソースの割り当てを要求する。
【００６７】
＜他のＭＡＣ制御エレメント＞
ＭＡＣ制御エレメントは、ＭＡＣレベルのピアツーピアシグナリングに用いられる。
【００６８】
ＬＴＥにおいては、別のＭＡＣ制御エレメントが規定されている。これらのＭＡＣ制御エレメントは、アップリンク送信またはダウンリンク送信に関連し得る。
【００６９】
電力ヘッドルームレポート（ＰＨＲ：Ｐｏｗｅｒ  Ｈｅａｄｒｏｏｍ  Ｒｅｐｏｒｔ）ＭＡＣ制御エレメントは、ＵＥが利用可能な電力ヘッドルームを報告するのに用いられた後、基地局において、ＵＥが使用可能なサブフレーム当たりのアップリンク帯域幅を決定するのに用いられる。これらのエレメントは、アップリンクにおいてスケジューリングノード（ｅＮＢ）に提供され、さまざまなＵＥに対するアップリンク送信リソースのスケジューリングを可能にするとともに、電力制限により使用できないユーザへのリソースの割り当てを回避可能とする。現在のところ、ＰＨＲは、ＵＥがアップリンク送信グラントを有するサブフレームすなわちアップリンクデータ送信を伴うサブフレームにおいてのみ送信可能である。
【００７０】
アクティブ化／非アクティブ化ＭＡＣ制御エレメントは、ＳＣｅｌｌすなわち主サービングセルのリソースに付加的なリソースを提供する副サービングセルのアクティブ化／非アクティブ化に用いられる。キャリアアグリゲーションが設定された場合の合理的なＵＥバッテリ消費を可能にするため、ＳＣｅｌｌのアクティブ化／非アクティブ化メカニズムがサポートされている。ＵＥに１つまたは複数のＳＣｅｌｌが設定されている場合、ｅＮｏｄｅＢは、設定されたＳＣｅｌｌをアクティブ化および非アクティブ化するようにしてもよい。アクティブ化／非アクティブ化は、ＰＣｅｌｌには当てはまらない。ＭＡＣ  ＣＥは、ＳＣｅｌｌのアクティブ化および非アクティブ化用のビットマップを搬送するが、１に設定されたビットが対応するＳＣｅｌｌのアクティブ化を表す一方、０に設定されたビットは、非アクティブ化を表す。ビットマップにより、ＳＣｅｌｌを個別のアクティブ化および非アクティブ化することができ、単一のアクティブ化／非アクティブ化コマンドによって、ＳＣｅｌｌのサブセットのアクティブ化／非アクティブ化を行うことができる。
【００７１】
セル無線ネットワーク一時識別子（Ｃ−ＲＮＴＩ：Ｃｅｌｌ  Ｒａｄｉｏ  Ｎｅｔｗｏｒｋ  Ｔｅｍｐｏｒａｒｙ  Ｉｄｅｎｔｉｆｉｅｒ）ＭＡＣ制御エレメントは、コンテンション解決を目的としたランダムアクセス手順において、それ自体のＣ−ＲＮＴＩをＵＥが送信できるようにする。
【００７２】
ＵＥコンテンション解決識別情報（ＵＥ  Ｃｏｎｔｅｎｔｉｏｎ  Ｒｅｓｏｌｕｔｉｏｎ  Ｉｄｅｎｔｉｔｙ）ＭＡＣ制御エレメントは、ＵＥがＣ−ＲＮＴＩを持たない場合にコンテンション解決を目的としたランダムアクセス手順において、ＵＥが送信したアップリンクＣＣＣＨ（コマンド制御チャネル）を送信するためｅＮｏｄｅＢにより用いられる。
【００７３】
ＤＲＸコマンドＭＡＣ制御エレメントは、ダウンリンクＰＲＸコマンドをＵＥに送信するためｅＮｏｄｅＢにより用いられる。
【００７４】
タイミングアドバンスコマンドＭＡＣ制御エレメントは、タイミングアドバンスコマンドをＵＥに送信してアップリンクタイミングを揃えるためｅＮｏｄｅＢにより用いられる。
【００７５】
ＭＢＭＳ動的スケジューリング情報ＭＡＣ制御エレメントは、ＭＢＭＳに対応したＵＥに対して、ＭＴＣＨ上のデータ送信のスケジューリングを通知するため、ＭＣＨごとに送信される。
【００７６】
上掲のＭＡＣ制御エレメントに関する詳細については、非特許文献７の第６．１．３項（本明細書に援用）を参照されたい。ＭＡＣ制御エレメントのタイプごとに、１つの特別なＬＣＩＤが割り当てられる。
【００７７】
＜Ｌ１／Ｌ２処理＞
図４は、リンクレイヤプロトコルを通じた物理レイヤまでのＩＰパケットのデータフローを例示的に示している。この図は、各プロトコルサブレイヤがそれ自体のプロトコルヘッダをデータユニットのほか、サブフレーム上のトランスポートブロックのマッピングに追加することを示している。トランスポートブロック（ＴＢ）は、物理レイヤにマッピングされたＭＡＣ  ＰＤＵを表す。
【００７８】
ＬＴＥにおけるサブフレームへのトランスポートブロックのマッピングは、いわゆる送信時間間隔（ＴＴＩ）において実行される。一般的に、単入力単出力（ＳＩＳＯ）すなわち１つのアンテナで送信機および受信機が動作する場合は、１つのトランスポートブロックが１つのＴＴＩにおいて１つのサブフレームにマッピングされる。ＭＩＭＯ／ＭＩＳＯ（多入力多出力／多入力単出力）の場合は、２つのトランスポートブロックに対応する２つのコードワードが１つのＴＴＩにおいて物理リソースにマッピングされるようになっていてもよい。一般的に、マッピングには３つ以上のトランスポートブロックが考えられる。
【００７９】
ＬＴＥのＬ２機能を下表にまとめる。
【表１】
2019533377.tif 000003
【００８０】
ＬＴＥにおいては、ＲＬＣレイヤがＰＤＣＰ  ＰＤＵの連結／分割を実行する。
【００８１】
送信機がトランスポートブロック（ＴＢ）サイズを把握している場合は、ＭＡＣレイヤが論理チャネル優先順位決定（ＬＣＰ）を実行して、各ＲＬＣエンティティが送信すべき（下位レイヤすなわちＭＡＣ／物理レイヤに提供すべき）データ量を決定する。各ＲＬＣエンティティは、１つまたは複数のＲＬＣ  ＳＤＵを含む１つのＲＬＣ  ＰＤＵを提供する。ＲＬＣ  ＰＤＵで終わる各ＲＬＣ  ＳＤＵについては、対応するＬフィールド（長さフィールド）が追加されるため、受信機は対応するＳＤＵを抽出することができる。最後に含まれるＲＬＣ  ＳＤＵがＲＬＣ  ＰＤＵに完全に適合するわけではない場合は、分割される。すなわち、ＲＬＣ  ＳＤＵの残りが後続のＲＬＣ  ＰＤＵにおいて送信されることになる。これは、ＲＬＣ  ＳＤＵの最初（最後）のバイトに対応するＲＬＣ  ＰＤＵの最初（最後）のバイトがＲＬＣヘッダ中の「フレーミング情報」フラグ（２ビット）により指定されているか否かに関わらず行われる。これ以外に、分割によってオーバーヘッドが追加となることはない。データの元の順序を復元して損失を検出するため、ＲＬＣシーケンス番号（ＳＮ）がＲＬＣ  ＰＤＵヘッダに追加される。
【００８２】
ＭＡＣは、異なる論理チャネル識別子（ＬＣＩＤ）のＲＬＣ  ＰＤＵを多重化して、対応するサブヘッダにＬＣＩＤおよびＬフィールドを追加する。トランスポートブロック構造の高レベル図を図４に示す。近年、３ＧＰＰは、新規無線（ＮＲ：Ｎｅｗ  Ｒａｄｉｏ）の名称の下、第５世代システムに関する研究および作業を開始した。ＮＲは、非常に高いデータレート（現在のところ、ダウンリンクで最大２０Ｇｂｉｔ／秒、アップリンクで最大１０Ｇｂｉｔ／秒）を目標としている。
【先行技術文献】
【非特許文献】
【００８３】
【非特許文献１】3GPP TS 36.211, "Evolved Universal Terrestrial Radio Access (E-UTRA); Physical Channels and Modulation (Release 8)"
【非特許文献２】3GPP TS 36.321, version 13.3.0
【非特許文献３】3GPP TS 36.321, version 12.4.0
【非特許文献４】3GPP TS 36.213, version 13.0.0
【非特許文献５】3GPP TS 36.322, version 13.0.0
【非特許文献６】3GPP TS 36.212, version 13.0.0 "Multiplexing and channel coding"
【非特許文献７】3GPP TS 36.321, version 13.3.0
【非特許文献８】3GPP TS 36.322, version 13.2.0
【発明の概要】
【発明が解決しようとする課題】
【００８４】
ＮＲが非常に高いデータレートを目標にしていることから、送信機および受信機の両者に利用可能な処理時間は、送信されるデータの量と比較して、極めて制限されている可能性もある。送信機の処理時間を最小限に抑える一例として、必要な実時間処理を最小限に抑えることが挙げられる。たとえば、ＬＴＥにおいては、ＰＤＣＰ  ＳＤＵ（すなわち、ＩＰパケット）が利用可能になったら、ＰＤＣＰ  ＰＤＵを生成可能である。すなわち、ＰＤＣＰ  ＰＤＵの生成は、非実時間的に実行可能である。すなわち、ＰＤＣＰ  ＰＤＵに対してリソースが現時点で許可されているか否かに関わらず実行可能である。ただし、ＲＬＣおよびＭＡＣ  ＰＤＵについては、実時間での（すなわち、ＵＬグラントの受信後の）生成のみ可能である。スケジューラにより決定された割り当てＴＢサイズ全体へのＤＬ／ＵＬデータＳＤＵの適合には、分割、連結、および多重化が必要である。連結および分割には、厳密な実時間処理要件の対象となるように、実行可能となる前にスケジューリング決定／グラントサイズを把握しておく必要がある。これはまた、たとえばスケジューリング／グラント情報の前のサブヘッダ／ヘッダのＲＬＣまたはＭＡＣレイヤのいずれかについて、送信機が如何なる前処理も行えないことを暗示している。「前処理」を実行できないことから、グラント受信に際して処理遅延が発生することになる。ＲＬＣ処理およびある程度のＭＡＣ処理を（グラント受信の）事前に完了できる場合、物理レイヤへのＭＡＣ  ＴＢ提供の遅延は、上記と比較してはるかに小さくなる。
【００８５】
さらに、ＬＴＥにおいて用いられるＭＡＣ  ＰＤＵフォーマットでは、ＴＢ生成が終了となる前の符号化の早期開始は不可能である。ＬＴＥにおいて、ＭＡＣ  ＰＤＵは、反復的なプロセスである。たとえば、制御情報（ヘッダ）のサイズが当該ＰＤＵ中のＳＤＵ数によって決まるためである。この反復プロセスでは、ＭＡＣ  ＰＤＵの送信が開始可能となるまでの時間を要する。ＭＡＣ制御エレメント（ＭＡＣ  ＣＥすなわちＢＳＲ，ＰＨＲ）がＭＡＣ  ＰＤＵ（ＴＢ）の最初に追加されるため、物理レイヤへのＭＡＣ  ＰＤＵの送信を開始する前に、その演算が必要となる。ＢＳＲの演算は、ＬＣＰの結果に基づいてのみ可能である一方、ＰＨＲの計算は、この値のＭＡＣへの入力に依存する。したがって、ＭＡＣヘッダの事前演算は不可能であり、ＭＡＣ  ＰＤＵ全体が構成されるまでは、ＭＡＣ  ＰＤＵを物理レイヤに転送することができない。このため、ＬＴＥのように、ＭＡＣ制御エレメントが任意のＭＡＣ  ＳＤＵの前に置かれている場合、ＭＡＣレイヤは、ＭＡＣ制御エレメントが演算された後に、利用可能なＭＡＣ  ＳＤＵのみを物理レイヤに配送することができる。たとえば、ＢＳＲの演算は、ＬＣＰの完了後にのみ可能である。また、電力ヘッドルームの計算にもいくらか時間を要する可能性があり、物理レイヤ信号（たとえば、ＰＵＣＣＨが送信されるか否かに関する情報）によって決まる。
【００８６】
上記見解を考慮して、本開示の目的は、レイヤ処理の効率を向上させる手法を提供することである。
【課題を解決するための手段】
【００８７】
上記は、独立請求項の特徴によって実現される。
【００８８】
有利な実施形態は、従属請求項の主題である。
【００８９】
本開示の一態様によれば、通信システムにおいてデータを無線チャネル上でデータ受信ノードに送信するデータ送信ノードであって、第３のレイヤから、データ送信用に割り当てられたリソースにマッピングされる少なくとも１つの第２レイヤサービスデータユニット（ＳＤＵ）を受信するとともに、少なくとも１つの第２レイヤＳＤＵおよび当該少なくとも１つの第２レイヤＳＤＵのいずれかの後に配置された少なくとも１つの第２レイヤ制御エレメントを含む第２レイヤプロトコルデータユニット（ＰＤＵ）を生成する第２レイヤ処理回路と、第２レイヤ処理回路により生成された第２レイヤＰＤＵを受信するとともに、データ送信用に割り当てられたリソースに第２レイヤＰＤＵをマッピングする第１レイヤ処理回路と、を備えた、データ送信ノードが提供される。
【００９０】
別の態様によれば、通信システムにおいてデータを無線チャネル上でデータ送信ノードから受信するデータ受信ノードであって、データ受信用に割り当てられたリソースから、少なくとも１つの第２レイヤプロトコルデータユニット（ＰＤＵ）をデマッピングする第１レイヤ処理回路と、第１レイヤ処理回路によりデマッピングされた第２レイヤＰＤＵを受信して構文解析する第２レイヤ処理回路であり、第２レイヤＰＤＵが、少なくとも１つの第２レイヤサービスデータユニット（ＳＤＵ）および当該少なくとも１つの第２レイヤＳＤＵのいずれかに後続する少なくとも１つの第２レイヤ制御エレメントを含む、第２レイヤ処理回路と、を備えた、データ受信ノードが提供される。
【００９１】
本開示のさらに別の態様によれば、通信システムにおいてデータを無線チャネル上でデータ受信ノードに送信する方法であって、第３のレイヤから、データ送信用に割り当てられたリソースにマッピングされる少なくとも１つの第２レイヤサービスデータユニット（ＳＤＵ）を受信するとともに、少なくとも１つの第２レイヤＳＤＵおよび当該少なくとも１つの第２レイヤＳＤＵのいずれかの後に配置された少なくとも１つの第２レイヤ制御エレメントを含む第２レイヤプロトコルデータユニット（ＰＤＵ）を生成するステップと、第２レイヤ処理により生成された第２レイヤＰＤＵを受信するとともに、データ送信用に割り当てられたリソースに第２レイヤＰＤＵをマッピングするステップと、を含む、方法が提供される。
【００９２】
別の態様においては、通信システムにおいてデータを無線チャネル上でデータ送信ノードから受信する方法であって、データ受信用に割り当てられたリソースから、少なくとも１つの第２レイヤプロトコルデータユニット（ＰＤＵ）をデマッピングするステップと、第１レイヤ処理回路によりデマッピングされた第２レイヤＰＤＵを受信して構文解析するステップであり、第２レイヤＰＤＵが、少なくとも１つの第２レイヤサービスデータユニット（ＳＤＵ）および当該少なくとも１つの第２レイヤＳＤＵのいずれかに後続する少なくとも１つの第２レイヤ制御エレメントを含む、第２レイヤＰＤＵを受信して構文解析するステップと、を含む、方法が開示される。
【００９３】
さらに、コンピュータ上で実行された場合に、上記方法の各ステップをコンピュータに実行させる命令を格納したコンピュータ可読媒体が提供される。
【００９４】
以下、添付の図面を参照して、例示的な実施形態をより詳しく説明する。
【図面の簡単な説明】
【００９５】
【図１】３ＧＰＰ  ＬＴＥシステムの例示的なアーキテクチャを示した図である。
【図２】３ＧＰＰ  ＬＴＥのＥ−ＵＴＲＡＮアーキテクチャ全体の例示的な概要を示した図である。
【図３Ａ】通信用のさまざまなレイヤを備えたＯＳＩモデルを示した図である。
【図３Ｂ】プロトコルデータユニット（ＰＤＵ）およびサービスデータユニット（ＳＤＵ）の関係ならびにそのレイヤ間交換を示した図である。
【図４】ＰＤＣＰ、ＲＬＣ、およびＭＡＣレイヤのさまざまな機能の概要を示すとともに、さまざまなレイヤによるＳＤＵ／ＰＤＵの処理を例示的に示した図である。
【図５Ａ】ＬＴＥのユーザプレーンにおける無線アクセスネットワークのさまざまなレイヤによるデータの処理を示した模式図である。
【図５Ｂ】ＭＡＣ  ＰＤＵの前処理および前処理されたヘッダの修正による物理リソースへのマッピングを示した模式図である。
【図６】３つのレイヤによる例示的な送信側処理の模式図である。
【図７】２つのＭＡＣ  ＰＤＵの一方が失われた場合の３つのレイヤによる例示的な受信側処理の模式図である。
【図８】２つのＭＡＣ  ＰＤＵの一方が失われた場合の３つのレイヤによる例示的な送信側処理の模式図である。
【図９】両ＭＡＣ  ＰＤＵが正しく受信された場合の３つのレイヤによる例示的な受信側処理の模式図である。
【図１０】第１の送信に対する送信側の例示的なレイヤ処理を示した模式図である。
【図１１Ａ】ＬＴＥステータスレポートの構造を示した模式図である。
【図１１Ｂ】ＲＬＣステータスレポートの構造を示した模式図である。
【図１２】分割番号を用いた第１の送信に対する送信側の例示的なレイヤ処理を示した模式図である。
【図１３】分割番号を用いた第１の送信に対する受信側の例示的なレイヤ処理を示した模式図である。
【図１４】（再）分割番号を用いた再送信に対する送信側の例示的なレイヤ処理を示した模式図である。
【図１５】（再）分割番号を用いた再送信に対する受信側の例示的なレイヤ処理を示した模式図である。
【図１６】多重接続をサポートする第１の送信に対する送信側の例示的なレイヤ処理を示した模式図である。
【図１７】多重接続をサポートする第１の送信に対する受信側の例示的なレイヤ処理を示した模式図である。
【図１８】多重接続をサポートする再送信に対する送信側の例示的なレイヤ処理を示した模式図である。
【図１９】多重接続をサポートする再送信に対する受信側の例示的なレイヤ処理を示した模式図である。
【図２０】例示的なデータ送信およびデータ受信装置の機能的構造を示したブロック図である。
【図２１】送信側および受信側で実行される例示的な方法の各ステップを示したフロー図である。
【図２２】ＮＲのユーザプレーンプロトコルスタックの例示的な構造を示した模式図である。
【図２３】例示的なＭＡＣ  ＰＤＵフォーマットを示した模式図である。
【図２４】ＭＡＣ  ＳＤＵに後続するＭＡＣ制御エレメントを含むＭＡＣ  ＰＤＵフォーマットの模式図である。
【図２５】別の例示的なＭＡＣ  ＰＤＵフォーマットおよびＭＡＣサブヘッダの例示的な構造を示した模式図である。
【図２６】バッファステータスレポートのＭＡＣ制御エレメントを含む例示的なＭＡＣ  ＰＤＵフォーマットを示した模式図である。
【図２７】アクティブ化／非アクティブ化のＭＡＣ制御エレメントを含む例示的なＭＡＣ  ＰＤＵフォーマットを示した模式図である。
【図２８】両方向に処理する例示的なＭＡＣ  ＰＤＵフォーマットを示した模式図である。
【図２９】図２８のＭＡＣ  ＰＤＵフォーマットならびにＭＡＣ制御エレメントおよび別のＭＡＣサブヘッダの存在を示すフラグを含むＭＡＣサブヘッダを示した模式図である。
【図３０】さらに別の例示的なＭＡＣ  ＰＤＵフォーマットを示した模式図である。
【図３１】データ送信ノードおよびデータ受信ノードの模式図である。
【図３２】データ送信方法およびデータ受信方法を示したフローチャートである。
【図３３】最初と最後にＭＡＣ制御エレメントを含む例示的なＰＤＵフォーマットを示した模式図である。
【発明を実施するための形態】
【００９６】
移動局、移動ノード、ユーザ端末、またはユーザ機器（ＵＥ）は、通信ネットワーク内の物理エンティティである。１つのノードが複数の機能エンティティを有していてもよい。機能エンティティは、所定組の機能の実装ならびに／またはノードもしくはネットワークの他の機能エンティティへの提供を行うソフトウェアまたはハードウェアモジュールを表す。ノードは、通信を可能にする通信設備または媒体にノードを接続する１つまたは複数のインターフェースを有していてもよい。同様に、ネットワークエンティティは、他の機能エンティティまたは対応するノードとの通信を可能にする通信設備または媒体に機能エンティティを接続する論理インターフェースを有していてもよい。
【００９７】
一組の請求項および本願において使用する用語「無線リソース」は、時間−周波数無線リソース等の物理的な無線リソースを表すものとして広く了解されるものとする。
【００９８】
以下の例示的な実施形態は、５Ｇ移動通信システムを想定した新規無線技術のための改良された無線インターフェースレイヤ処理を提供する。現在のところ、５Ｇ移動通信システムに関しては、ほとんどの詳細が合意に至っていないため、以下では、実施形態の基礎となる原理を説明可能とするため、多くの仮定を導入する必要がある。ただし、これらの仮定は、本開示の範囲を制限することのない単なる一例として了解されるものとする。当業者であれば、本明細書に明示的に記載していない方法で、特許請求の範囲に記載の本開示の原理が異なるシナリオに当てはまり得ることが認識されるであろう。たとえば、新規無線技術は、ＬＴＥ（−Ａ）に関して規定済みの無線技術から発展することになるが、５Ｇ移動通信システムの要件を満たすように複数の変更が予想される。その結果、種々実施形態の特定の例示的な実施態様は、５Ｇ通信システム用の新規無線技術および以下の実施形態に関して説明する種々実施態様の両者に等しく適用可能である限り、（Ｒｅｌ．１０／１１／１２／１３／１４等に係る）ＬＴＥ（−Ａ）通信システムに関して規定済みの手順、メッセージ、機能等を引き続き再利用することも可能である。
【００９９】
本開示によれば、連結／分割機能は、ＲＬＣレイヤからＭＡＣエンティティに移される。この手法によれば、いくつかの利点がもたらされ、たとえば、ＵＬグラントの受信前に、（送信がアップリンクで実行される場合に）端末でＲＬＣ  ＰＤＵおよびＭＡＣ  ＰＤＵの一部を事前構成可能である。これにより、各ＲＬＣ  ＰＤＵおよびＭＡＣ  ＰＤＵの一部の事前構成によって、処理時間が短縮される。ＲＬＣレイヤは、（Ｌ１／Ｌ２シグナリングによるリソース割り当てで搬送される）ＭＡＣスケジューリングの決定およびＲＬＣ  ＰＤＵサイズの指定を待つ必要がない。これにより、トランスポートブロックの生成における処理時間が短縮される。
【０１００】
図５Ａは、送信側（ＴＸ）および受信側（ＲＸ）のプロトコルレイヤの主要機能を示している。図示のように、送信側では、ＲＬＣレイヤとの協働によりＭＡＣレイヤで分割が実行される。
【０１０１】
図５Ｂは、送信側で実行される以下のような基本動作を示している。
【０１０２】
ａ）ＲＬＣおよび／またはＭＡＣ  ＰＤＵは、ＰＤＣＰ  ＰＤＵ数に基づいて前処理される。すなわち、ＲＬＣレイヤは、ＰＤＣＰ  ＰＤＵを連結しない。ただし、ＲＬＣレイヤは、ＲＬＣ  ＳＤＵ（ＰＤＣＰ  ＰＤＵ）をさらに分割するようにしてもよく、ＰＤＣＰ  ＰＤＵ分割の２つの結果すなわちＲ１−ＰＤＵ１およびＲ２−ＰＤＵ２によってこれを示す。前処理は、所与の無線条件（たとえば、ＲＳＳＩ／ＲＳＲＰ）において一定の高信頼度で統計的に利用可能な「最小（あるいは、平均）グラントサイズ」に基づくことも可能である。したがって、この最小または平均グラントサイズ上では、（推定グラントサイズと連動するため）疑似ＬＣＰが動作し、これに応じてＲＬＣおよびＭＡＣ  ＰＤＵが前処理される。（現実の）グラントが受信され、ＬＣＰがＭＡＣレイヤにおいて動作している場合は、ＬＣＰの結果に基づいて許可されたリソースに収容され得る（すなわち、対応するＭＡＣ  ＰＤＵのサイズが対応するＬＣＩＤのグラントサイズ以下である）前処理ＲＬＣ  ＰＤＵの一部が物理レイヤに提供されることになる。物理レイヤは、これらに対する処理を直ちに（すなわち、時点ｔ１に）開始するようにしてもよい。図５Ｂにおいて、前処理ＭＡＣヘッダを付加した事前分割Ｒ１−ＰＤＵ１およびＲ２−ＰＤＵ２は、許可されたリソースに収容可能である。
【０１０３】
ｂ）事前分割されたＲ１−ＰＤＵ１およびＲ２−ＰＤＵ２は、全体として許可されたリソースに収容できないため、ＬＣＰが実行された後、割り当てサイズを把握することによって、これらＰＤＵのさらなる分割が必要となる。言い換えると、（上記ステップ後の）残りのグラントによって、前処理ＰＤＵを分割することも必要であり、それぞれの対応するヘッダを再演算する必要がある。分割は、（前処理および提供済みのＲＬＣ  ＰＤＵに関しては）ＭＡＣレイヤで行うことも可能であるし、ＲＬＣレイヤで行うことも可能である（ＬＣＰの結果に基づいて分割後にＲＬＣがヘッダを再演算する）。このＬ２処理の後、ＭＡＣ  ＰＤＵの結果部分（セグメント）が物理レイヤに提供される。物理レイヤは、これらに対する処理を後で（すなわち、時点ｔ２に）開始するようにしてもよい。
【０１０４】
図５Ｂにおいて、２つの異なるＲＬＣエンティティは、異なる論理チャネルに属する。したがって、ＭＡＣは、論理チャネル優先順位決定手順（ＬＣＰ）に基づいて、どの時点に対応するＭＡＣ  ＰＤＵのいずれを物理レイヤに提供すべきかを決定する。ＬＣＰ手順の一例は、ＬＴＥにより知られており、上記背景技術の項で言及した。それにも関わらず、本開示は、一般的にはこれに限定されない。
【０１０５】
受信側においては、物理レイヤ処理の後、対応する逆ステップが実行される。
【０１０６】
ａ）ＭＡＣレイヤは、ＭＡＣヘッダ（基本的には、ＬＣＩＤフィールドおよび長さフィールド）に基づいて逆多重化を実行するとともに、結果としてのＭＡＣ  ＳＤＵをＲＬＣに与える。ＭＡＣレイヤは、ＭＡＣ  ＳＤＵをＲＬＣレイヤに受け渡した場合、分割／連結ヘッダフィールドも維持する。分割および連結がＭＡＣにより行われ、セグメントの並べ替えおよび再組み立てがＲＬＣにより実行されるためである。このため、ＭＡＣは、分割ヘッダフィールドをＲＬＣに受け渡す。言い換えると、ＭＡＣレイヤは、ＭＡＣ  ＳＤＵのみならず、分割／連結に関連するＭＡＣヘッダの一部もＲＬＣに受け渡す。
【０１０７】
ｂ）ＲＬＣレイヤは、ＲＬＣ  ＳＤＵ全体をＰＤＣＰに転送する前に、ＲＬＣ  ＰＤＵセグメント（存在する場合）を再組み立てする。ＲＬＣ  ＳＤＵ全体のＰＤＣＰへの提供もばらばらに行われる。すなわち、たとえばセグメントが失われた場所に「ホール」を含む。それは、所定の時間または所定の再送信数内に正しく受信されていないためである。ただし、ＲＬＣは、行方不明のＰＤＵおよびＰＤＵセグメントを追跡する必要がある。ＡＲＱがＲＬＣで動作するため、考え得る再送信に対して、行方不明の如何なるＲＬＣ  ＰＤＵおよび／またはＰＤＵセグメントも送信側に報告されるものとする。ここで、ＡＲＱは、タイマーＴｉｍｅｒ１の満了時点まで、行方不明のＲＬＣ  ＰＤＵおよび／またはＰＤＵセグメントを読み出そうとする。Ｔｉｍｅｒ１は、ホールが最初に見えた場合（または、後続／次のＲＬＣ  ＳＤＵがＰＤＣＰレイヤに配送される場合）に開始となる。Ｔｉｍｅｒ１の満了時点で、ＲＬＣは、ＰＤＣＰレイヤおよびＲＲＣに通知するものとする。ＲＲＣは、無線リンク障害（ＲＬＦ：Ｒａｄｉｏ  Ｌｉｎｋ  Ｆａｉｌｕｒｅ）手順のトリガーのような別の措置を講じる可能性もある。一般的に、ＴＣＰのような上位レイヤのエンドツーエンドプロトコルは依然として、正しい配送に対処可能である。
【０１０８】
ｃ）ＰＤＣＰレイヤは、ＰＤＣＰ  ＳＮ（または、ヘッダから直接利用可能な場合のＣＯＵＮＴ、あるいは、ＰＤＣＰヘッダに含まれるＳＮから推定／計算する必要があるＣＯＵＮＴ）に基づいて、ＲＬＣから受信した入力ＰＤＵを解読するものとする。ＣＯＵＮＴの計算は、最後のＰＤＣＰ  ＳＮ値とちょうど受信したＰＤＣＰ  ＰＤＵヘッダ中のＰＤＣＰ  ＳＮ値との差で最後のＣＯＵＮＴ値を調整することによって行われる。ここで、「最後の」は、解読に成功した過去のＰＤＣＰ  ＰＤＵを表す。また、ＰＤＣＰは、ＲＬＣからの「ホール」の到着を待つものとする。ただし、対応するＰＤＣＰ  ＰＤＵの受信前に（Ｔｉｍｅｒ１満了時点の）ＲＬＣからの指定が到着した場合、ＰＤＣＰ  ＳＤＵは、（ホールを含む）上位レイヤに提供される。
【０１０９】
上記手法は、ＡＭのみならず、ＵＭにも適用可能である。ＵＭが適用される場合は、ＲＬＣレイヤで再送信は行われない。それにも関わらず、受信側では、ＲＬＣ  ＰＤＵまたはＲＬＣ  ＰＤＵセグメントが行方不明の場合、ＲＬＣ  ＳＤＵが組み立てられ、ＰＤＣＰレイヤに提供される。
【０１１０】
ＡＭにおいて、ＲＬＣ  ＰＤＵおよび／またはＰＤＵセグメントが行方不明であることをＲＬＣステータスレポートが示している場合、送信側ＲＬＣは、適当なヘッダを含むＭＡＣレイヤに対して、対応する行方不明のＲＬＣ  ＰＤＵおよび／またはＰＤＵセグメントを提供して、再送信により受信機がセグメントを再組み立てするのを支援する。
【０１１１】
あるいは、ＲＬＣレイヤは、対応するＲＬＣ  ＰＤＵのセグメントのみが行方不明と指定された場合であっても、ＲＬＣ  ＰＤＵ全体をＭＡＣレイヤに提供するようにしてもよい。また、ＲＬＣレイヤは、ＭＡＣレイヤとステータスレポートの詳細（すなわち、ステータスレポート全体）を共有する。この手法の利点は、ＲＬＣヘッダのオーバーヘッドが低下することである。ＲＬＣレイヤにおいて再送信が行われると、ＲＬＣレイヤは、分割ヘッダフィールドを追加するため、ヘッダのオーバーヘッドが増加する。この問題を克服するため、ＲＬＣ  ＰＤＵ全体がＭＡＣに送られ、ＭＡＣは、ステータスレポートに基づいて分割を実行する。ＲＬＣのステータスレポートは、レイヤ（ＰＤＣＰ、ＲＬＣ、ＭＡＣ）間で普遍的な（共通の）シーケンス番号が使用されているため、ＭＡＣにより理解される。この場合、ＭＡＣレイヤは、この理解およびＬＣＰの結果に基づいて再分割を実行するとともに、適当なヘッダを含むことによって、受信機がセグメントを再組み立てするのを支援する。
【０１１２】
なお、上記説明では「ＭＡＣ」、「ＲＬＣ」、および「ＰＤＣＰ」に言及しているが、これらは、ＵＭＴＳ／ＬＴＥ（−Ａ）規格において採用された用語である。ただし、本開示は、これらの規格にもその上級版にも限定されず、使用する専門用語に関わらず作用するようになっていてもよい。
【０１１３】
言い換えると、上記フレームワークは、（物理レイヤに対応する）物理リソースに対するデータのマッピング／デマッピングを担う第１のレイヤ、（ＭＡＣに対応する）第２のレイヤ、および（ＲＬＣおよび／またはＰＤＣＰに対応する）第３のレイヤが存在するプロトコルスタックと見なし得る。なお、この場合の用語「第１のレイヤ」、「第２のレイヤ」、および「第３のレイヤ」は、必ずしもＯＳＩモデルレイヤに対応しない。
【０１１４】
プロトコルスタックの処置遅延の低減は、第１の物理レイヤ、第２のレイヤ、および第３のレイヤを有する送信側において実現可能であるが、第２のレイヤは、第３のレイヤから（リソース割り当てを把握せずに第３のレイヤにより生成された）前処理された第３レイヤＰＤＵを受信するとともに、（アップリンクにおいては受信機から、ダウンリンクにおいては内部から）物理レイヤのリソース割り当てを受信する。前処理された第３レイヤＰＤＵには、分割情報を含むヘッダが（第３のレイヤまたは第２のレイヤで前もって）追加されるようになっていてもよい。なお、このように前処理された第３レイヤＰＤＵは、優先順位が異なり得る複数の論理チャネルに対応する複数の第３レイヤエンティティに対して提供されるようになっていてもよい。したがって、第２のレイヤは、優先順位決定手順を実行するようにしてもよい。そして、第２のレイヤは、受信したリソース割り当てのほか、場合により優先順位決定手順の結果に基づいて、分割情報を含む適当に前処理された第３レイヤＰＤＵを第１の時点ｔ１で第２レイヤヘッダとして第１のレイヤに提供するとともに、場合により、前処理されたＰＤＵのさらなる分割を実行して、時点ｔ１よりも後の時点ｔ２で第１のレイヤにデータを提供する前に、ヘッダ中の分割情報を修正する。
【０１１５】
なお、第２のレイヤで受信された第３レイヤＰＤＵは、第３のレイヤがＡＲＱを実装している場合、ＡＲＱステータスレポートに従ってすでに事前分割されている可能性がある。ただし、この手法は、第３のレイヤがＡＲＱを実装していない場合にも適用可能である。そして、この事前分割は、過去の割り当てに関するいくつかの統計的尺度または別のルールに従って行われるようになっていてもよいが、必ずしも実行される必要はない。
【０１１６】
さらに、本開示は、二重接続または多重接続にも適用可能であるのが好都合である。多重接続は、非理想的なバックホールを介して接続された複数の異なるスケジューラが提供するＥ−ＵＴＲＡおよびＮＲの無線リソースを接続モードの複数の受信／送信ＵＥが利用するように構成された動作モードである。言い換えると、多重接続により、（端末等の）送信機の第３のレイヤの上のレイヤは、複数の基地局（ｅＮＢ）に送信される同じパケット（ＩＰまたはＰＤＣＰ）を提供する。そして、２つ以上の基地局が同じパケットを独立して受信するため、ネットワークによる正しい受信の確率が高くなる。
【０１１７】
多重接続の概念は、いわゆる「二重接続」概念として３ＧＰＰ  ＲＡＮ作業グループで議論されている前途有望なソリューションである二重接続といくらか類似している。用語「二重接続」は、非理想的なバックホールで接続された少なくとも２つの異なるネットワークノードにより提供される無線リソースを所与のＵＥが消費する動作を表すのに用いられる。本質的に、ＵＥは、マクロセル（マクロｅＮＢ）およびスモールセル（副ｅＮＢ）の両者と接続される。さらに、ＵＥの二重接続に含まれる各ｅＮＢは、異なる役割を仮定していてもよい。これらの役割は、必ずしもｅＮＢの電力クラスに依存せず、ＵＥ間で変動し得る。ただし、異なるデータがＵＥから異なるｅＮＢに送られる二重接続と異なり、多重接続においては、複数のリンク／セル上で同じＩＰ／ＰＤＣＰパケットが送信される。複数の受信ｅＮＢのうち、１つがマスターとして機能し、複数の接続を介して受信されたセグメントの再組み立てを実行するレイヤを実装する。マスターｅＮＢは、その他のｅＮＢと通信する。
【０１１８】
たとえば、ＬＴＥに関して言えば、ＰＤＣＰレイヤは、単接続から多重接続への切り替えに際してすでに実行している他の機能のほか、再組み立て機能を引き受ける。ＡＲＱは、（ＡＭにおいては）依然としてＲＬＣレイヤで動作し得るが、この場合、ＰＤＣＰレイヤは、行方不明のＰＤＣＰ  ＳＮの詳細（の全部または一部）をＲＬＣレイヤと共有することが必要となる。ＰＤＣＰレイヤは、セグメントの行方不明の部分について、ＲＬＣレイヤに通知することになる。その後、ＲＬＣレイヤの受信エンティティは、ＲＬＣレイヤの送信エンティティにステータスレポートを送信することになる。したがって、ＲＬＣレイヤとＰＤＣＰレイヤとで別個のＡＲＱは不要であり、これは、単接続および多重接続を意味するものであって、ＡＲＱはいずれもＲＬＣレイヤにて動作し得る。あるいは、ＰＤＣＰレイヤは、それ自体のステータスレポートを構成して、送信側ＰＤＣＰエンティティに送ることができる。ステータスレポートには、行方不明のＰＤＣＰ  ＰＤＵおよび／またはＰＤＵセグメントに関する情報を含むものとする。
【０１１９】
上述のように遅延の低減および／またはオーバーヘッドの低下を可能にするため、本開示は、送信側および受信側で実装される効率的なレイヤモデルを提供する。これには、以下のうちの１つまたは複数を含む。
【０１２０】
分割を第２のレイヤに移す。すなわち、データを（第３のレイヤから）物理リソースにマッピングするために実時間処理を実行する必要がある物理レイヤに可能な限り近づける。これにより、対応するグラントの受信前であっても、共有チャネル上でデータを送信する準備が可能となる（この可能性を端末の実装に利用してもよいし、利用しなくてもよい。言い換えると、端末のタイミングに前処理されたＰＤＵを利用するか否かは、実装次第であってもよい）。
【０１２１】
複数のレイヤがアクセスする共通の制御情報を採用する。通例、レイヤモデルでは、各レイヤが当該レイヤで生成された制御情報にしかアクセスしないものと仮定する。これにより、複数のレイヤで提供される複製制御情報すなわち異なるレイヤのＰＤＵのヘッダが重複する場合もある。これは、受信データの並べ替えを可能にするシーケンス番号に当てはまり得る。共通のシーケンス番号が（ＰＤＣＰおよびＲＬＣ等の）２つ以上のレイヤに用いられるようになっていてもよく、これによりヘッダのオーバーヘッドが低下する。
【０１２２】
上位レイヤ（第３のレイヤ、より詳細にはＲＬＣまたはＰＤＣＰ等）は、ＡＲＱ機能をサポートする。したがって、第３レイヤステータスレポートに基づいて、第３のレイヤは、ＰＤＵの分割を実行する。ここで、ステータスレポートに基づく第３レイヤＰＤＵの分割は、（第２のレイヤ、より詳細にはＭＡＣ等）で受信した割り当てに基づいて実行される分割とは異なっていてもよいと仮定する。第３のレイヤがステータスレポートに基づく情報を第２のレイヤに提供し、第２のレイヤのみが割り当ておよびステータスレポートの両者に基づいて分割を実行する場合に、同様の利点が実現され得る。この手法によれば、（前処理による）時間の節約およびリソースの節約（再分割によって、行方不明のセグメントのみを再送信可能）の両者が可能である。
【０１２３】
＜ＡＲＱのためのレイヤ２分割、レイヤ３事前分割＞
一実施形態によれば、通信システムにおいてデータを無線インターフェース上でデータ受信ノードに送信するデータ送信ノードが提供される。プロトコルスタックレイヤモデルの機能を実装するため、データ送信ノードは、データ受信ノードからフィードバックされたステータスレポートに従ってＡＲＱ再送信を実行するか、または実行せず、ステータスレポートに含まれるセグメント長さ情報に基づいて（存在する場合に）再送信されるデータを再分割するか、または再分割しない第３レイヤ処理ユニット（以下、「処理ユニット」は「処理回路」と置き換え可能）を備える。再分割には、たとえばヘッダとして、分割されたデータ分割制御情報に追加することを含む。このヘッダは、第２のレイヤにおいても解釈されるとともに使用され、第３レイヤデータユニットとともに第２のレイヤに提供されるのが好都合である。本実施形態においては、再送信プロトコルが第３のレイヤにより管理され、第３のレイヤの下位または上位の他のレイヤにおける独立したＡＲＱ／ＨＡＲＱプロトコルの適用は除外されないものと仮定する。
【０１２４】
データ送信ノードは、第３レイヤ処理ユニットから第３レイヤデータユニットを受信し、リソース割り当てに基づいて第３レイヤデータユニットを分割し、第３レイヤデータユニットの各セグメントおよび再分割が適用される場合に修正される分割制御情報を含む複数の第２レイヤデータユニットを形成する第２レイヤ処理ユニットをさらに備える。リソース割り当ては、データ受信ノードから受信されるようになっていてもよいし、データ送信ノードで生成されるようになっていてもよい。たとえば、送信ノードが端末（ＵＥ）である場合は、リソース割り当て（アップリンクグラント）が基地局すなわちデータ受信ノードから受信されるようになっていてもよい。一方、送信ノードが基地局である場合は、送信用のリソース割り当てが基地局で生成され、ＭＡＣレイヤに提供されるようになっていてもよい。ただし、本開示は、端末間、中継器と端末間、または中継器と基地局間の直接通信にも適用可能である。
【０１２５】
最後に、データ送信ノードは、第２のレイヤから、複数の第２レイヤデータユニットのうちの１つまたは複数を受信し、データ送信用に割り当てられたリソースに対して、複数の第２レイヤデータユニットのうちの１つまたは複数をマッピングする第１レイヤ処理ユニットを備える。
【０１２６】
なお、データ送信ノードは、ヘッダ内でシーケンス番号を提供する第４レイヤ処理ユニットをさらに備えていてもよい。シーケンス番号は、新しい第４レイヤＳＤＵすなわちＩＰパケットごとに増えるが、所定の最大値を有するため、増加が循環するようになっていてもよい。第３のレイヤは、別のシーケンス番号を提供しないものの、ＰＤＣＰレイヤが提供するシーケンス番号を含む第４レイヤ処理ユニットを包含するのが好都合である。
【０１２７】
ＬＴＥの専門用語に関しては、第１のレイヤが物理レイヤ、第２のレイヤがＭＡＣレイヤ、第３のレイヤがＲＬＣレイヤ、第４のレイヤがＰＤＣＰであってもよい。ただし、いくつかの実施形態においては、第３のレイヤをＰＤＣＰレイヤと考えてもよいし、特に現在のＬＴＥを基準として発展するアーキテクチャの場合は、ＲＬＣおよびＰＤＣＰの両機能を備えた１つの混合レイヤと考えてもよい。
【０１２８】
図６は、本実施形態に係る送信側の処理をＬＴＥ専門用語で例示している。送信側は、データをアップリンクにおいて基地局に送信する端末であってもよい。ただし、本開示はこれに限定されず、送信側は、データを別の端末またはその他任意のノードに送信する端末であってもよい。さらに、本開示は、基地局、中継ノード、またはデータ送信機である別のノードにも適用可能である。
【０１２９】
図６に示すように、長さ１２００バイトのＩＰパケット１がＰＤＣＰレイヤに提供されて、ＰＤＣＰ  ＳＤＵが形成される。ＰＤＣＰ  ＳＤＵには、単一ビットと考えられるＤ／Ｃインジケータを含むヘッダが追加される。このビットは、ＰＤＣＰ  ＰＤＵの内容がデータであるか制御ＰＤＵであるかを示す。本例においては、データＰＤＵの場合に設定され（すなわち、ビットが１に等しい）、制御ＰＤＵの場合に設定されない（すなわち、ビットが０に等しい）。ただし、一般的には、設定／非設定が逆であってもよい。ＰＤＣＰヘッダには、ＰＤＣＰシーケンス番号（ＳＮ）をさらに含む。
【０１３０】
ＰＤＣＰ  ＰＤＵ１（ペイロード１２００バイト）は、ＲＬＣレイヤに送られて、ＲＬＣ  ＳＤＵが形成される。ＲＬＣレイヤには、ＲＬＣ  ＰＤＵに関連するＲＬＣヘッダを含む。図示のように、ＲＬＣヘッダには、別のＤ／Ｃフラグ、Ｐフラグ、およびＲＦフラグを含む。Ｄ／Ｃフラグは、ＲＬＣ  ＰＤＵにより制御が搬送されるかデータが搬送されるかを示す一方、Ｐフラグは、受信機（相手側ＲＬＣエンティティ）にステータスレポートを要求するように設定されたポーリングビットである。これが設定されていない場合は、ステータスレポートが要求されていない。ＲＦフラグは、ＲＬＣ  ＰＤＵがＰＤＣＰ  ＰＤＵ全体であるかＰＤＣＰ  ＰＤＵセグメントであるかを示す再分割フラグである。ＲＦ値は、最初は０に設定されており、ＲＬＣ  ＰＤＵがＰＤＵ全体であることを示す。その後、ＲＬＣ  ＰＤＵ１の一部としてＭＡＣレイヤに配送される。本例において、ＰＤＣＰ  ＰＤＵ／ＩＰパケットのデータの最初の送信の場合は、ＲＬＣレイヤが分割を実行せず、ＭＡＣレイヤが分割を実行する。したがって、最初の送信の場合、ＲＦ値は常に、０に設定されている。
【０１３１】
図６の例において、送信ＭＡＣエンティティは、受信したグラントに基づいてＲＬＣ  ＰＤＵを分割する必要がある。さらに、本例において仮定されるグラントサイズは、２つの異なる送信機会において８００バイトおよび４００バイトである（または、少なくとも１つのグラントが８００バイト、残りが別のグラントを待つ）。このため、ＭＡＣレイヤは、ＭＡＣ  ＳＤＵに対応するＲＬＣ  ＰＤＵを分割する。ＲＬＣ  ＰＤＵの分割後、送信ＭＡＣエンティティは、分割関連ＭＡＣヘッダ部を各ＭＡＣ  ＰＤＵに含めることにより、含まれるＲＬＣ  ＰＤＵのセグメントオフセット（ＳＯ：Ｓｅｇｍｅｎｔ  Ｏｆｆｓｅｔ）および最終セグメントフィールド（ＬＳＦ：Ｌａｓｔ  Ｓｅｇｍｅｎｔ  Ｆｉｅｌｄ）を示すとともに、図６においてＭＡＣ  ＰＤＵ１およびＭＡＣ  ＰＤＵ２と表されるＭＡＣ  ＰＤＵを形成する。ＭＡＣ  ＰＤＵ１が８００バイトのペイロードを含む一方、ＭＡＣ  ＰＤＵ２は、４００バイトのペイロードを含む。ＭＡＣ  ＰＤＵ１およびＭＡＣ  ＰＤＵ２はそれぞれ、ＴＴＩ０およびＴＴＩ１に送信される。そして、ＴＴＩ０およびＴＴＩ１は、異なるリソース（たとえば、異なる時間リソース）となるように多重化される。ただし、本開示がこれによって、異なる時点への２つのＭＡＣ  ＰＤＵのマッピングに限定されることはない。一般的には、異なる種類のリソース（たとえば、ＭＩＭＯシステムの異なる周波数または異なるストリーム、直交コード等）に２つ以上のＭＡＣ  ＰＤＵがマッピングされる。
【０１３２】
本例におけるＳＯフィールドは、元のＰＤＵ内のＰＤＵセグメントの位置（バイト単位）を示す。具体的に、ＳＯフィールドは、ＰＤＵセグメントのデータフィールドの最初のバイトが対応する元のＰＤＵのデータフィールド内の位置を示す。元のＰＤＵのデータフィールドの最初のバイトは、ＳＯフィールドの値ゼロにより参照される。ＬＳＦフィールドは、ＰＤＵセグメントの最後のバイトがＰＤＵの最後のバイトに対応するか否かを示す。
【０１３３】
ＭＡＣレイヤは、論理チャネルＩＤ（ＬＣＩＤ）およびＭＡＣヘッダに続く他のフィールドが存在するか否かを示す拡張フラグ（Ｅ）等の別のフィールドをＭＡＣ  ＰＤＵ１およびＭＡＣ  ＰＤＵ２に含めるようにしてもよい。値１は、このフィールドに続いて少なくとも１つまたは複数のＥ／ＬＣＩＤフィールドが存在することを示す。値０は、このフィールドに続くＥ／ＬＣＩＤフィールドがもはや存在せず、次のバイトがＭＡＣ  ＳＤＵの開始バイトであることを示す。ヘッダには、いくつかの別のフィールドまたは予約フィールドが存在していてもよい（図示せず）。
【０１３４】
本実施形態によれば、通信システムにおいてデータを無線インターフェース上でデータ送信ノードから受信するデータ受信ノードも提供される。データ受信ノードは、データ送信用に割り当てられたリソースから、複数の第２レイヤデータユニットのうちの１つまたは複数をデマッピングするとともに、デマッピングされた複数の第２レイヤデータユニットのうちの１つまたは複数を第２レイヤ処理ユニットに提供する第１レイヤ処理ユニットを備える。さらに、データ受信ノードは、複数の第３レイヤユニットセグメントおよび複数の第２レイヤデータユニットのうちの１つまたは複数からの分割制御情報の逆多重化を実行するとともに、分割制御情報と併せて、逆多重化された複数の第３レイヤユニットセグメントを第３レイヤ処理ユニットに転送する第２レイヤ処理ユニットをさらに備える。データ受信ノードは、逆多重化された複数の第３レイヤセグメントの並べ替えおよび第３レイヤユニットへの組み込みを実行する第３レイヤ処理ユニットをさらに備える。
【０１３５】
このため、第２レイヤデータユニットの一部である（特に、第２レイヤヘッダにて搬送され得る）分割情報は、第３のレイヤでも確認され、使用される。したがって、この手法は、一方では厳密なレイヤ分離を無視し、他方ではオーバーヘッドを節約して、第３のレイヤでの並べ替えおよび再組み立ての効率的な実行を可能にする。これは特に、第３のレイヤにおいてＡＲＱ手順が実装されている場合に都合が良いものの、必ずしもその必要はなく、本開示を制限するものではない。
【０１３６】
例示的な一実施態様によれば、データ受信装置の第３レイヤ処理ユニットは、少なくとも１つの第３レイヤユニットセグメントが正しく受信されたか否かを示すステータスレポートを搬送する制御データを生成するようにさらに構成されている。ステータスレポートは、少なくとも１つの第３レイヤデータユニットの肯定応答もしくは否定応答ならびに／または第３レイヤデータユニットの正しく受信されたセグメントもしくは行方不明のセグメントの指定のうちの少なくとも１つを含んでいてもよい。ここで採用し得るステータスレポートの例示的なフォーマットについては、非特許文献８の第６．２．１．６項に見られる。ただし、これは一例に過ぎず、ステータスレポートは、第３レイヤＰＤＵまたはそのセグメントに対する肯定および／または否定受信応答が可能な限り、異なるフォーマットおよび内容を有していてもよい。
【０１３７】
図７は、エラーが発生しやすいチャネルを通じて受信されたＭＡＣ  ＰＤＵ１およびＭＡＣ  ＰＤＵ２の例示的な受信処理を示している。図７に示すように、ＭＡＣ  ＰＤＵ１（ペイロード８００バイト）は正しく受信されているものの、ＭＡＣ  ＰＤＵ２（ペイロード４００バイト）は失われている（正しく復号化できていない、すなわち、ＣＲＣ障害）。
【０１３８】
ＭＡＣレイヤは、ＲＬＣ  ＰＤＵ１の逆多重化を実行して、ＲＬＣレイヤに送信する。その後、ＲＬＣレイヤは、ＭＡＣセグメントの再組み立ておよび並べ替えを実行する。ＲＬＣ受信側（ＲＸ）は、ＭＡＣ  ＰＤＵ１に属する８００〜１２００バイトの正しい受信を示すステータスレポートをＲＬＣ送信側（ＴＸ）に送る。ＲＬＣ  ＰＤＵセグメントの並べ替えおよび再組み立ては、ＭＡＣレイヤからのヘッダ情報に基づいて実行される。図７の例においては特に、ヘッダ情報がセグメントオフセットおよびＬＳＦインジケータを含む。ＲＬＣレイヤのＤ／Ｃフィールドによれば、ＲＬＣデータＰＤＵとステータスレポート等のＲＬＣ制御ＰＤＵとの識別が可能である。
【０１３９】
図８は、ＲＬＣ送信側における例示的な後続動作を示しており、送信側が（たとえば、ステータスレポートに基づいて）行方不明の第２のＭＡＣ  ＰＤＵ２セグメントを認識しているものと仮定する。図８に示すように、本例において、ＲＬＣ  ＴＸは、送信バッファから対応する行方不明パケットのＲＬＣ  ＰＤＵ全体を取得し、ＲＬＣステータスレポートが行方不明として示す４００バイト（８００〜１２００）の新たな分割（再分割）を実行する。再分割には、適当なＲＬＣヘッダのアタッチも含む。ここで、ＲＬＣヘッダには、オフセット（バイト単位）により再送信されるＲＬＣ  ＰＤＵセグメントの位置を示すセグメントオフセットを含む。本例においては、８０１〜１２００の行方不明の４００バイトが再送信されるため、セグメントオフセットＳＯは８０１である。そして、行方不明の４００バイトに対応する再分割ＲＬＣ  ＰＤＵがＭＡＣレイヤに配送される。
【０１４０】
その後、ＭＡＣレイヤは、受信したＲＬＣ  ＰＤＵの分割を実行し、ＭＡＣ  ＰＤＵ１（２００バイトのデータを含む）およびＭＡＣ  ＰＤＵ２（同じく２００バイトのデータを含む）を形成する。これらはそれぞれ、最初の送信について図６を参照しつつ上述した通り、ＴＴＩ０およびＴＴＩ１に送られる。当然のことながら、一般的には、ＭＡＣレイヤのみが必要に応じて分割を実行する。ここで、本例においては、グラントサイズが十分ではないため、ＭＡＣレイヤがＭＡＣ  ＰＤＵ１およびＭＡＣ  ＰＤＵ２を形成する。割り当てが十分な場合は、分割が不要である。あるいは場合により（割り当てが１つのＭＡＣ  ＰＤＵに必要とされる以上の場合）、連結が実行される。
【０１４１】
特に、ＭＡＣレイヤは、ＲＬＣヘッダからＳＯフィールドおよびＬＳＦフィールドを読み込んで、グラントサイズに基づいて修正する。すなわち、本例においては、それぞれ２００バイトおよび２００バイトの分割サイズを反映させる。図８に見られるように、ＭＡＣレイヤは、分割されたＭＡＣ  ＰＤＵの各ヘッダ（すなわち、ＳＯ＝８０１およびＳＯ＝１００１）に新たな分割情報を提供するが、これらは、最初に送信された（再分割ではない）ＲＬＣ  ＰＤＵおよびＬＳＦ内で再送信されるデータの新たなセグメントの位置に対応する。図９は、図８のＭＡＣ  ＰＤＵ１およびＭＡＣ  ＰＤＵ２がともに正しく受信された一例を示している。ＭＡＣレイヤは、正しく受信されたＭＡＣ  ＰＤＵ１およびＭＡＣ  ＰＤＵ２をＲＬＣレイヤに配送する。ＲＬＣレイヤは、ＭＡＣセグメントの並べ替えおよび再組み立てを実行した後、ＰＤＣＰ  ＰＤＵ全体をＰＤＣＰレイヤに配送する。並べ替えは、シーケンス番号（ＳＮ）に基づいて実行される。前述の通り、オーバーヘッドを節約するため、ＰＤＣＰレイヤおよびＲＬＣレイヤの両者には、シーケンス番号が１つだけ用いられるのが好都合である。
【０１４２】
言い換えると、ＲＬＣ  ＲＸは、（最初の送信後に再送信または正しく受信された）ＲＬＣ  ＰＤＵのすべてのセグメントを収集し、ＭＡＣヘッダ情報に基づいて並べ替え、当該ＲＬＣ  ＰＤＵを再組み立てする。再組み立てされたＰＤＵはその後、上位レイヤ（ＰＤＣＰまたはＰＤＣＰが存在しない場合は直接ＩＰ）に提供されて、さらに処理される場合がある。
【０１４３】
以上から、本開示では、以下の表２に示すように、ＲＡＮプロトコルスタックの異なるレイヤが実行する機能を修正する。
【表２】
2019533377.tif 000004
【０１４４】
以下、表３〜表５は、レイヤＰＤＣＰ、ＲＬＣ、およびＭＡＣそれぞれのヘッダの例を示している。
【表３】
2019533377.tif 000005
【表４】
2019533377.tif 000006
【表５】
2019533377.tif 000007
【０１４５】
上表において、シーケンス番号の長さは、１０ビットと例示されている。ただし、これは一例に過ぎず、本開示を制限するものではない。ＬＴＥにおいてはすでに、無線ベアラの特性に応じて、ＰＤＣＰシーケンス番号の長さを５ビット、７ビット、または１２ビットにすることができる。シーケンス番号の長さは、当業者には明らかなように、システム設計の問題であり、本開示の目的では如何なる長さを有するように選択されてもよい。
【０１４６】
図６に示すように、ＰＤＣＰ  ＰＤＵは、受信機においてＲＬＣレイヤに送られる。ＰＤＣＰ、ＲＬＣ、およびＭＡＣレイヤは、これらすべてのレイヤが把握する汎用的なシーケンス番号を使用するのが好都合である。本例においては、これらすべてのレイヤが把握するか、または下位レイヤではＳＮが必ずしも必要ないために少なくともＰＤＣＰおよびＲＬＣが把握するＰＤＣＰシーケンス番号が使用される。
【０１４７】
ＲＬＣレイヤは、関連するＲＬＣヘッダ（たとえば、ＰＤＵ全体またはＰＤＵセグメントを示すＲＦフィールド）をＲＬＣ  ＰＤＵに含む。ＲＦ値は、最初は０に設定され、ステータスレポートがＲＬＣ  ＴＸに到着したら更新される。送信側がＲＬＣデータＰＤＵを送信する場合は、再送信の可能性を考えて、ＲＬＣ  ＰＤＵを依然として再送信バッファに格納する。ステータスレポートにより、受信機によって再送信が要求される場合がある。図６に見られるように、その後はＲＬＣ  ＰＤＵがＭＡＣレイヤに配送される。その後、送信ＭＡＣエンティティは、上位レイヤ（ＲＬＣ）から受信されたＭＡＣ  ＳＤＵに関して分割および／または連結を実行することにより、ＭＡＣ  ＰＤＵを形成する。
【０１４８】
各送信機会（ＴＴＩ）でのＭＡＣ  ＰＤＵのサイズは、無線チャネル状態および利用可能な送信リソースに応じて、ＭＡＣレイヤ自体により決定されて通知される。背景技術の項に記載の通り、各ＴＴＩにおいて異なる割り当て（たとえば、より良好なリンク適応のための変調およびコード化方式の変更による異なる量のデータの収容）が可能となるように、共有チャネルに対して動的なスケジューリングが適用されるようになっていてもよい。
【０１４９】
各送信ＭＡＣ  ＰＤＵのサイズは、上記のように異なり得る。送信ＭＡＣエンティティは、当該ＭＡＣエンティティに到着した順序で、ＲＬＣ  ＰＤＵ／ＭＡＣ  ＳＤＵをＭＡＣ  ＰＤＵに含める。したがって、各セグメントのサイズおよび割り当てリソースに応じてＭＡＣが分割のみならず、連結も実行し得るため、単一のＭＡＣ  ＰＤＵがＲＬＣ  ＰＤＵ全体またはＲＬＣ  ＰＤＵセグメントを含み得る。ＭＡＣ  ＰＤＵがＮ個（Ｎは０より大きな整数）のＲＬＣ  ＰＤＵおよび／またはＰＤＵセグメントを含む場合、ＭＡＣレイヤは、すべての対応するＲＬＣ  ＰＤＵおよび／またはＰＤＵセグメントそれぞれに対してＮ−１個の長さフィールド（Ｌフィールド）を含むものとする。すなわち、最後以外のＲＬＣ  ＰＤＵおよび／またはＰＤＵセグメントごとに１つのＬフィールドを含むものとする。
【０１５０】
受信側では、図７に示すように（図６〜図９の例が連結ではなく分割に関するため、ＬＩフィールドは図示せず）、ＭＡＣレイヤが実際のデータ開始位置を把握している。ヘッダ長のほか、ＬフィールドとともにＭＡＣ  ＰＤＵ長も把握しているためである。ここでは、ヘッダ長が把握されているものと仮定する。たとえば、予め規定されていてもよいし（たとえば、規格において指定されていてもよし）、ヘッダのフィールド内で指定されていてもよい。上記例では、ヘッダが継続するか終了となるかを示すのに、拡張ビットが用いられるため、これによりヘッダサイズを決定することができる。
【０１５１】
ＭＡＣレイヤは、分割フィールド（ＳＯおよびＬＳＦ）を削除せずにＭＡＣ  ＰＤＵの逆多重化を実行する。その後、逆多重化されたＲＬＣ  ＰＤＵ／セグメントは、ＲＬＣレイヤに配送される。受信ＲＬＣレイヤは、ＲＬＣ  ＰＤＵセグメントを受信した場合、シーケンス外で受信された場合は最初に並べ替えおよび再組み立てを行う（図９も参照）。ＭＡＣレイヤにおいて並べ替えおよび再組み立てを実行しない利点の１つとして、処理時間の短縮が挙げられる。受信側で１つのセグメントが行方不明の場合、ＭＡＣレイヤは、上位レイヤ（ＲＬＣ）への配送を遅らせることになる再組み立ておよび並べ替えを行わないことも可能である。再組み立ておよび並べ替えを遅らせないように、ＭＡＣレイヤは、分割フィールド（ＳＯ、ＬＳＦ）をＲＬＣレイヤに受け渡す。図６を参照して上述した通り、分割および連結がＭＡＣレイヤにより実行されるためである。したがって、ＲＬＣレイヤは、ＭＡＣレイヤから受信された分割ヘッダフィールドを読み出し、分割（たとえば、ＳＯ、ＬＳＦ）および連結（たとえば、ＬＩ）ヘッダフィールドに基づいて、並べ替えおよび再組み立てを必要に応じて実行する。これにより、受信ＲＬＣレイヤがＭＡＣレイヤシグナリングフィールドを把握して使用する必要があることから、本例においては、レイヤ間相互作用が必要となる。
【０１５２】
ＭＡＣレイヤにおいてシーケンス外で受信された如何なるＲＬＣ  ＰＤＵも、上位レイヤ（ＲＬＣ）に配送される。受信ＲＬＣにおいてはＡＲＱ動作が実行されて、エラーのない送信（確認モード）がサポートされる。送信側が行方不明のＲＬＣ  ＰＤＵのみを再送信できるように、受信側は、ＲＬＣ  ＰＤＵに関する行方不明のＰＤＵまたはＰＤＵセグメント情報を示すＲＬＣステータスレポートを送信側に提供する。
【０１５３】
１つまたは複数のＰＤＵ／セグメントが行方不明のステータスレポートに応答して、ＲＬＣレイヤの送信機は、送信バッファから、対応する行方不明のパケットのＲＬＣ  ＰＤＵ全体を取得し、ＲＬＣステータスレポートが示す行方不明のセグメントに基づいて（再）分割を実行する。ステータスレポートの受信後に再分割が実行された場合、ＲＬＣは、ＲＦフィールドを０から１に変更する。そして、（再）分割されたＰＤＵがＭＡＣレイヤに配送され、ＲＦフラグが読み出される。再送信手順において無線状態が劣化する可能性もあるため、行方不明のＰＤＵセグメントまたはＰＤＵは、（ＭＡＣレイヤにより行われる）再送信の前により小さなセグメントへと分解される（再分割される）ことが必要となり得る。これを図８に示すが、この図においては、再送信バッファ中の元のペイロード１２００バイトのＲＬＣ  ＰＤＵから、ペイロード４００バイトの行方不明のＲＬＣ  ＰＤＵがＲＬＣレイヤで取得され、より小さなペイロード２００バイトのＭＡＣ  ＰＤＵへとさらに分解（再分割）される。
【０１５４】
＜ＭＡＣレイヤにおける再分割＞
図８を参照すれば、ＲＬＣのオーバーヘッドがわずかに増加していることが分かる。ＲＬＣ送信機は、セグメントの行方不明の部分に基づいて、すなわち正しく受信されず、ＲＬＣステータスレポートにより示された後ＭＡＣレイヤに配送される４００バイトの長いデータに基づいて再分割を実行するためである。したがって、ＲＬＣにおいては再分割ヘッダ（ＳＯ、ＲＦ、およびＬＳＦを含む）が必要であり、このためＲＬＣヘッダのオーバーヘッドが増加する。
【０１５５】
オーバーヘッドを抑えるため、一実施形態によれば、ＭＡＣレイヤにおいて再分割が実行される。
【０１５６】
特に、本実施形態によれば、通信システムにおいてデータを無線インターフェース上でデータ受信ノードに送信するデータ送信ノードが提供される。データ送信ノードは、データ受信ノードからフィードバックされたステータスレポートに従って自動再送要求（ＡＲＱ）の再送信を実行する第３レイヤ処理ユニットを備える。データ送信ノードは、第３レイヤ処理ユニットから第３レイヤデータユニットを受信し、ステータスレポートに従うとともにリソース割り当てに基づいて第３レイヤデータユニットを分割し、分割された第３レイヤデータユニットの各セグメントを含む複数の第２レイヤデータユニットを形成する第２レイヤ処理ユニットをさらに備える。また、第２のレイヤから、複数の第２レイヤデータユニットを受信し、データ送信用に割り当てられたリソースに対して、複数の第２レイヤデータユニットをマッピングする第１レイヤ処理ユニットが存在する。
【０１５７】
したがって、分割機能は、物理レイヤに最も近いレイヤである第２のレイヤにすべて移される。選択例に基づいて、これを図１０に詳しく示す。
【０１５８】
送信機のＲＬＣレイヤは、ステータスレポートを要求するポーリングビット（本実施形態がＵＭではなくＡＭで適用される場合）およびＲＬＣ  ＰＤＵがペイロード（ユーザ）を搬送するか制御データを搬送するかを示すＤ／Ｃフィールドを含むヘッダをＰＤＣＰ  ＰＤＵ（ＲＬＣ  ＳＤＵ）に追加する。なお、ＲＬＣレイヤが非確認モードでも動作し得るため、本開示は、ＡＲＱを実行するＲＬＣレイヤに限定されない。
【０１５９】
ＲＬＣ  ＴＸレイヤは、ＲＬＣ  ＲＸから受信されたステータスレポートをＭＡＣレイヤに配送する。ＭＡＣレイヤは、シーケンス番号（ＳＮ）、ＳＯｓｔａｒｔ、およびＳＯｅｎｄ値等の分割情報をステータスレポートから読み出し、これに応じて分割を実行する。したがって、ＲＬＣ  ＴＸは、再送信バッファからＲＬＣ  ＰＤＵ全体を取得して、ＭＡＣ  ＴＸに送信する。これを図１０に示すが、この図は、図８に示すようなわずか４００バイトではなく、１２００バイトのＰＤＣＰ  ＳＤＵデータを備えたデータフィールドを含むＲＬＣＰＤＵを示している。
【０１６０】
その後、ＭＡＣ  ＴＸレイヤは、分割情報（たとえば、図１０に示すように、ＲＬＣステータスレポートにより示され、ＲＬＣレイヤによりＭＡＣレイヤまで転送されたＳＯｓｔａｒｔ、ＳＯｅｎｄ、およびＳＮ等）に基づいて分割を実行する。これによれば、ＭＡＣ  ＰＤＵヘッダが生成される。図１０のヘッダは、ＬＣＩＤ（論理チャネル識別子）、別のヘッダ情報が存在するか否かを示すＥビット、ならびに、ここではＲＬＣ  ＰＤＵ内の搬送セグメントの開始を示すセグメントオフセット（バイト単位が可能）、および包含されるＲＬＣ  ＰＤＵセグメントがＲＬＣ  ＰＤＵの最後であるか否かを示す最終セグメントフィールド（ＬＳＦ）を含む分割情報を含む。図１０に見られるように、それぞれ２００バイトおよび２００バイトの２つのセグメントに対する８０１および１００１のオフセットが伝えられる。
【０１６１】
図１１Ａは、非特許文献８において規定されたステータスレポート（ＳＴＡＴＵＳ  ＰＤＵ）を示している。ＳＴＡＴＵＳ  ＰＤＵは、ＳＴＡＴＵＳ  ＰＤＵペイロードおよびＲＬＣ制御ＰＤＵヘッダから成る。ＲＬＣ制御ＰＤＵヘッダは、Ｄ／ＣおよびＣＰＴフィールドから成る。ＳＴＡＴＵＳ  ＰＤＵペイロードは、ＲＬＣ制御ＰＤＵヘッダに続く最初のビットから始まり、１つのＡＣＫ＿ＳＮおよび１つのＥ１、ゼロ組以上のＮＡＣＫ＿ＳＮ、Ｅ１およびＥ２、ならびに場合により各ＮＡＣＫ＿ＳＮに対する一組のＳＯｓｔａｒｔおよびＳＯｅｎｄから成る。ＳＴＡＴＵＳ  ＰＤＵの最後には、必要に応じて１〜７つのパディングビットが含まれることで、オクテット（８ビット）の整列が実現される。
【０１６２】
図１１Ｂは、ＲＬＣステータスレポートの例示的なフォーマットを示している。この例示的なステータスレポートは、図１１Ａに例示のＬＴＥステータスレポートに類似し、同様のフィールドを含む。図１１Ｂのステータスレポートは、ＲＬＣシーケンス番号ではなくＰＤＣＰシーケンス番号が伝達される点において図１１Ａのステータスレポートと異なる。
【０１６３】
特に、このステータスレポートは、Ｄ／Ｃフィールドと、ＰＤＵがステータスＰＤＵであるか否かを示す（ステータスレポートのステータスＰＤＵを示す）ＣＰＴ（制御ＰＤＵタイプ）フィールドとを含む。ＰＤＣＰ  ＡＣＫ＿ＳＮは、ステータスレポート（ＳＴＡＴＵＳ  ＰＤＵ）において行方不明と報告されていない次の未受信ＲＬＣデータＰＤＵのＳＮを示す１０ビットの長いフィールドである。ここで、接頭語「ＰＤＣＰ」は、ＲＬＣおよびＰＤＣＰレイヤに共通のＳＮが使用されるため、ステータスレポートにも適用されることを強調している。
【０１６４】
拡張ビット１（Ｅ１）は、一組のＰＤＣＰ  ＮＡＣＫ＿ＳＮ、Ｅ１、およびＥ２が続くか否かを示しており、０に設定された場合は一組のＮＡＣＫ＿ＳＮ、Ｅ１、およびＥ２が続かず、１に設定された場合は一組のＮＡＣＫ＿ＳＮ、Ｅ１、およびＥ２が続く。
【０１６５】
否定応答ＳＮ（ＮＡＣＫ＿ＳＮ）（本例におけるＰＤＣＰ  ＮＡＣＫ＿ＳＮフィールド）は、ＡＭ  ＲＬＣエンティティの受信側で失われたものとして検出されたＲＬＣ  ＰＤＵ（または、その一部）のＳＮを示す。
【０１６６】
拡張ビット２（Ｅ２）は、一組のＳＯｓｔａｒｔおよびＳＯｅｎｄが続くか否かを示しており、０に設定された場合はこのＮＡＣＫ＿ＳＮに対して一組のＳＯｓｔａｒｔおよびＳＯｅｎｄが続かず、１に設定された場合はこのＮＡＣＫ＿ＳＮに対して一組のＳＯｓｔａｒｔおよびＳＯｅｎｄが続く。
【０１６７】
非特許文献８によれば、第６．２．２．１８項および第６．２．２．１９項において、これらＳＯｓｔａｒｔおよびＳＯｅｎｄが以下のように記載されている。
【０１６８】
ＳＯｓｔａｒｔ（１５ビット）：ＳＯｓｔａｒｔフィールドは（ＳＯｅｎｄフィールドと併せて）、ＡＭ  ＲＬＣエンティティの受信側で失われたものとして検出されたＳＮ＝ＮＡＣＫ＿ＳＮ（ＳＯｓｔａｒｔが関連するＮＡＣＫ＿ＳＮ）のＲＬＣ  ＰＤＵの部分を示す。具体的に、ＳＯｓｔａｒｔフィールドは、ＲＬＣ  ＰＤＵのデータフィールド内のＲＬＣ  ＰＤＵの部分の最初のバイトの位置をバイト単位で示す。
【０１６９】
ＳＯｅｎｄ（１５ビット）：ＳＯｅｎｄフィールドは（ＳＯｓｔａｒｔフィールドと併せて）、ＡＭ  ＲＬＣエンティティの受信側で失われたものとして検出されたＳＮ＝ＮＡＣＫ＿ＳＮ（ＳＯｅｎｄが関連するＮＡＣＫ＿ＳＮ）のＲＬＣ  ＰＤＵの部分を示す。具体的に、ＳＯｅｎｄフィールドは、ＲＬＣ  ＰＤＵのデータフィールド内のＡＭＤ  ＰＤＵの部分の最後のバイトの位置をバイト単位で示す。ＡＭＤ  ＰＤＵの行方不明の部分がＡＭＤ  ＰＤＵの最後のバイトまでの全バイトを含むことを示すには、特殊なＳＯｅｎｄ値「１１１１１１１１１１１１１１１」が用いられる。言い換えると、ＳＯｓｔａｒｔおよびＳＯｅｎｄはそれぞれ、否定応答のＲＬＣ  ＰＤＵセグメントの最初と最後を示す。
【０１７０】
＜セグメント番号＞
通常３０ビット長のセグメントオフセット（開始・終了ともに）は、特に小さなセグメントの場合に、ＭＡＣサブヘッダオーバーヘッドを増大させる。
【０１７１】
オーバーヘッドを抑えるため、本実施形態において、セグメント識別情報はこのように、第３レイヤデータユニット内の第３レイヤデータユニットのセグメントのシーケンス番号を示すセグメント番号である。このセグメント番号は、図示のように（すなわち、ＳＯフィールドの代わりに）データＰＤＵにおいて用いられるようになっていてもよい。ただし、セグメント番号は、ステータスレポート（ＳＴＡＴＵＳ  ＰＤＵ）での使用により、ＳＯｓｔａｒｔおよびＳＯｅｎｄを置き換え得るのが好都合である。
【０１７２】
一例において、ＭＡＣサブヘッダ（すなわち、分割に関連するヘッダの部分）は、３０ビットのセグメントオフセット（１５ビットのＳＯｓｔａｒｔおよび１５ビットのＳＯｅｎｄ）の代わりに４ビット長のセグメント番号を使用することにより短くなる。このため、ＭＡＣレイヤは、セグメント番号を示す４ビットに基づいて分割を実行する。４ビットのセグメント番号によれば、最大１６個のセグメントを識別可能である。ただし、ここで、４という数字は、例示目的に過ぎない。対応するユーザプレーンレイヤアーキテクチャに必要なセグメントが多い場合または少ない場合は、最大数のビットを用いて上記を行うことも可能である。本実施形態の手法は、ＲＬＣ  ＰＤＵ内の各セグメントの開始と終了の代わりに各セグメントのセグメント番号を伝えることによって、オーバーヘッドを抑える。オフセットが関連するＲＬＣ  ＰＤＵのビット数に対して、セグメントの数の方が確実に少ないため、オーバーヘッドは一般的に、オフセットではなくセグメントをアドレス指定することによって抑えられる。
【０１７３】
送信側の場合のセグメント番号の採用を図１２に示す。特に、図１２は、ＰＤＣＰに提供されるＩＰパケットを示しており、これは、Ｄ／ＣフィールドおよびＰＤＣＰ  ＳＮが追加されるとともに、このヘッダ情報と併せてＲＬＣレイヤに提供される。ＲＬＣレイヤは、Ｄ／Ｃフィールドおよびポーリングフィールドを含む自身のヘッダを追加することによってＰＤＣＰ  ＰＤＵを包含する。ここで、ＲＬＣレイヤで分割が実行されないことから、ＲＦフィールドは不要である。むしろ、ＲＬＣ  ＰＤＵ１は、全体としてＭＡＣレイヤに提供される。
【０１７４】
図１２に示すように、ＭＡＣレイヤにおいては、それぞれ８００バイトおよび４００バイトを含むセグメント０およびセグメント１という２つのセグメントにＲＬＣ  ＰＤＵが分割される。この分割は、割り当てサイズに基づいて実行されるようになっていてもよい。ＲＬＣ  ＰＤＵの分割後、送信ＭＡＣエンティティは、関連するＭＡＣヘッダを含めることにより、ＭＡＣ  ＰＤＵを形成する。特に、このヘッダは、セグメントの長さを示す長さインジケータ（ＬＩ）、セグメント番号（たとえば、上述の４ビット）、最終セグメントフィールド（ＬＳＦ）、および含まれるＲＬＣ  ＰＤＵに対して０に設定されたフィールドＲ（再分割が続かないことを示す）を含む。ＬＩフィールドは、１つのＭＡＣ  ＰＤＵが２つ以上のＲＬＣ  ＰＤＵを含む連結の場合に必要である。分割の場合は、グラントサイズが知られているため、受信機は、グラントのサイズを把握し、これに応じて逆の動作を実行することができる。
【０１７５】
そして、ＭＡＣレイヤは、分割情報に基づいて、図１２においてＭＡＣ  ＰＤＵ１およびＭＡＣ  ＰＤＵ２と称する２つのＭＡＣ  ＰＤＵを形成する。ＭＡＣ  ＰＤＵ１およびＭＡＣ  ＰＤＵ２はそれぞれ、各送信時間間隔ＴＴＩ０およびＴＴＩ１に送信される。
【表６】
2019533377.tif 000008
【０１７６】
図１３は、本実施形態の場合の例示的な受信側レイヤ処理を示しており、セグメントオフセットの代わりにセグメント番号が採用されている。
【０１７７】
図１３に示すように、受信側では、ＭＡＣ  ＰＤＵ１が正しく受信される一方、ＭＡＣ  ＰＤＵ２は失われる。ＭＡＣレイヤは、（Ｒ、セグメント番号、およびＬＳＦを含む）分割ヘッダとともにＭＡＣ  ＰＤＵ１をＲＬＣレイヤに配送する。一方、受信側のＲＬＣレイヤは、行方不明の８００〜１２００バイト（すなわち、ＭＡＣ  ＰＤＵ２）を示すステータスレポートを送信ＲＬＣエンティティに送信する。そして、ＲＬＣレイヤは、ＲＬＣセグメントの再組み立ておよび並べ替えを実行する。ここでは、最初の８００バイトのセグメントのみが正しく受信されるため、本例では並べ替えを実行する必要がない。
【０１７８】
図１４は、データ受信側からステータスレポートを受信した際の例示的な送信側レイヤ処理を示している。図１４に示すように、ＲＬＣレイヤは、再送信バッファからＲＬＣ  ＰＤＵ全体を取得する（このことは、行方不明の４００バイトのみならず、ＲＬＣ  ＰＤＵに含まれる１２００バイトのＰＤＣＰ  ＳＤＵデータによって示される）。そして、ＭＡＣレイヤは、ＲＬＣステータスレポートに基づいて、再分割を実行する。
【０１７９】
ＲＬＣ  ＰＤＵの再分割の後、送信ＭＡＣエンティティは、関連するＭＡＣヘッダをそれぞれの再分割ＭＡＣ  ＰＤＵに含めることにより、含まれる各ＲＬＣ  ＰＤＵに関して、それぞれの長さ（ＬＩ）、３ビットの再分割番号、最終再分割フィールド（ＬＲＦ）、およびＲ＝１（再分割が続くことを示す）を示すとともに、図１４においてＭＡＣ  ＰＤＵ１およびＭＡＣ  ＰＤＵ２と称するＭＡＣ  ＰＤＵを形成する。
【０１８０】
たとえば、ＲＬＣステータスレポートにおいて報告される通り、（ＬＣＰ実行後の）対応するＬＣＩＤの利用可能なグラントに行方不明のセグメントが適合し得ない場合は、必要に応じて、ＭＡＣレイヤがセグメント番号の行方不明の部分の再分割を実行するようにしてもよい。この目的のため、ＭＡＣは、たとえば３ビット（または、必要に応じてそれ以上）を用いることにより、ＲＬＣ  ＰＤＵの対応するセグメントの「再分割」を識別するようにしてもよい。
【０１８１】
以上をまとめて、第２レイヤ処理ユニットは、第３レイヤデータユニットのセグメント内の第３レイヤデータユニットのセグメントのシーケンス番号を示し、セグメント番号よりも少ないビット数で伝えられる再分割番号を含むセグメント識別情報を第２レイヤデータユニットのヘッダに含める。ただし、これは、本開示を制限するものではない。セグメント番号および再分割番号のサイズは、同じであってもよい。「再分割」に採用可能な別の用語は、「サブセグメント」である。これは、過去の分割の結果としてのセグメントのサブセグメントである。
【０１８２】
あるいは、図１４においては、セグメント番号がセグメントに用いられ、セグメントオフセットがサブセグメント番号の代わりにサブセグメントに用いられるようになっていてもよい。再送信が頻発しないことから、より高いオーバーヘッドを受け入れ可能であるものと仮定されるためである。
【０１８３】
図１５は、図１４に示すＭＡＣ  ＰＤＵ１およびＭＡＣ  ＰＤＵ２の再送信の受信時の受信側レイヤ処理を示している。
【０１８４】
図１５に示すように、ＭＡＣレイヤは、ＭＡＣ  ＰＤＵ１およびＭＡＣ  ＰＤＵ２の逆多重化を実行して、それぞれのヘッダの一部を削除する。ただし、並べ替えおよび再組み立てがＲＬＣレイヤで実行されることから、ＭＡＣレイヤは、関連する分割ヘッダフィールド（Ｒフィールド、セグメント番号、ＬＳＦ、ＬＲＦ、および再分割番号）を維持する。そして、ＲＬＣは、ＭＡＣセグメントの並べ替えおよび再組み立てを実行して、結果（ＰＤＣＰ  ＰＤＵ）をＰＤＣＰレイヤに送る。
【０１８５】
＜第２のレイヤにおける並べ替えおよび再組み立て＞
本開示の別の実施形態によれば、受信側がさらに変更される。特に、ＲＬＣレイヤで並べ替えおよび再組み立てを実行する代わりに、ＭＡＣレイヤが並べ替えおよび再組み立てを実行する。この場合は、レイヤ間相互作用が不要である。この構成において、ＭＡＣレイヤは、再送信処理の実行も担う。セグメントの任意の部分が行方不明の場合、ＭＡＣレイヤの受信エンティティは、ステータスレポートをＭＡＣ  ＴＸに送信する。ＭＡＣステータスレポートは、ＲＬＣステータスレポートと若干異なる。特に、このステータスレポートにおいては、どのステータスレポートがどのＬＣＩＤ（論理チャネル）に属するかを区別するＬＣＩＤフィールドが設けられる。
【０１８６】
言い換えると、通信システムにおいてデータを無線チャネル上でデータ送信ノードから受信するデータ受信ノードは、データ送信用に割り当てられたリソースから、複数の第２レイヤデータユニットのうちの１つまたは複数をデマッピングするとともに、デマッピングされた複数の第２レイヤデータユニットのうちの１つまたは複数を第２レイヤ処理ユニットに提供する第１レイヤ処理ユニットと、複数の第３レイヤユニットセグメントおよび複数の第２レイヤデータユニットのうちの１つまたは複数からの分割制御情報の逆多重化を実行するとともに、分割制御情報と併せて、逆多重化された複数の第３レイヤユニットセグメントを第３レイヤ処理ユニットに転送し、さらに、逆多重化された複数の第３レイヤユニットセグメントの並べ替えおよび逆多重化された第３レイヤユニットセグメントの第３レイヤデータユニットとしての組み立てを実行する第２レイヤ処理ユニットと、を備える。また、第２レイヤ処理ユニットは、データが正しく受信されたか否かをチェックするとともに、ステータスレポートを相手側の第２レイヤエンティティに送信するように構成されていてもよい。受信機の本実施形態は、上述の第２のレイヤにおいて分割／連結が実行される受信機実施形態に特に適している。
【０１８７】
＜より多くのｅＮＢに対する多重接続／二重接続とより多くのリンクに対する同じベアラ＞
多重接続の場合、ＰＤＣＰレイヤは、複製パケットを異なるｅＮＢに分配する。
【０１８８】
以下の表７は、各レイヤの主要機能について、多重接続のプロトコルスタックを記載している。
【表７】
2019533377.tif 000009
【０１８９】
図１６は、多重接続をサポートする本実施形態に係る、ＩＰパケット１の新たな送信の場合の送信側レイヤ処理を示している。
【０１９０】
特に、第１のレイヤが物理レイヤ、第２のレイヤが媒体アクセス制御（ＭＡＣ）レイヤ、第３のレイヤがパケットデータ制御プロトコル（ＰＤＣＰ）レイヤである。ただし、ＰＤＣＰレイヤおよびＲＬＣレイヤを１つのレイヤとして組み合わせるようにしてもよいし、ＲＬＣが機能を実行するようになっていてもよい。第３レイヤ処理ユニットは、無線インターフェース上で、異なる下位レイヤスタックへの同じ第３レイヤデータユニットを異なる各基地局（または、一般的にはデータ受信ノード）に提供するように構成されている。下位レイヤスタックは、互いに個別かつ独立して分割／再組み立てを実行することができる。下位レイヤスタックには、物理レイヤおよびＭＡＣを含んでいてもよい。ただし、ＲＬＣレイヤを依然として含んでいてもよい。
【０１９１】
上述した通り、このレイヤは、現行ＬＴＥのレイヤとは異なる名称であり、異なる機能を有していてもよい。一般的に、多重接続は、上位レイヤからパケットを受信し、自身のＰＤＵとして包含されるパケットの複数（２つ以上）のコピーを複数の各スタックの下位レイヤに提供する１つのレイヤを共通して有する。複数のスタックは、上記実施形態のいずれかに記載の通り、互いに別個かつ独立して分割および再組み立てを扱うが、これによって、それぞれの物理チャネル状態およびデータ受信ステータスに適応可能である。
【０１９２】
第３のレイヤは、再送信処理を制御するのが好都合である。上記多重接続シナリオにおいては、受信側の各下位レイヤスタックがパケットを正しく受信して再組み立てする必要がない。他のすべてのスタックからパケットのセグメントを収集する１つのスタックがパケットを再組み立てできれば十分である。これは、一種のダイバーシティをもたらし、スループットが向上する。
【０１９３】
図１６に示すように、ＩＰパケット１は、ＰＤＣＰレイヤ上のＰＤＣＰヘッダにアタッチされ、対応するＰＤＣＰ  ＰＤＵが２つの異なる基地局（ここでは、ｅＮＢ１およびｅＮＢ２）に送られる。上述の通り、基地局ｅＮＢ１およびｅＮＢ２（ネットワークノード）は、プロトコルレイヤ（ＲＬＣ／ＭＡＣ／物理レイヤ）をそれぞれ実装する。ｅＮＢ１は、８００バイトおよび４００バイトをそれぞれ含む２つのセグメントＭＡＣ  ＰＤＵ１およびＭＡＣ  ＰＤＵ２に対して、ＲＬＣ  ＰＤＵ１に対応するＰＤＣＰ  ＰＤＵを受け渡す。セルが異なればチャネル品質も異なり得るため、ｅＮＢ２は、異なる分割を採用するようにしてもよい。このため、本例において、ｅＮＢ２は、５００バイトおよび７００バイトをそれぞれ含む２つのセグメントＭＡＣ  ＰＤＵ１およびＭＡＣ  ＰＤＵ２へとＲＬＣ  ＰＤＵ１を分割する。ＲＬＣレイヤは、確認モードで動作している場合、ＡＲＱ機能をさらに担っていてもよい。ただし、上述の通り、ＰＤＣＰがＲＬＣ再送信を制御するようにしてもよい。特に、（各ｅＮＢの）各ＲＬＣレイヤは、マスターｅＮＢのＰＤＣＰにステータスレポートを受け渡すようにしてもよく、再送信が必要か否かおよび対象とするパケットのセグメントをマスターｅＮＢが決定する。これに応じて、ＰＤＣＰは、各ＲＬＣレイヤに対して再送信を実行するように命令する。
【０１９４】
図１７は、受信側での処理を示している。図１７に示すように、０〜８００バイトを含むＭＡＣ  ＰＤＵ１をｅＮＢ１が受信する一方、８０１〜１２００バイトのＭＡＣ  ＰＤＵ２は失われる。一方、０〜５００バイトを含むＭＡＣ  ＰＤＵ１をｅＮＢ２が受信する一方、ＭＡＣ  ＰＤＵ２の行方不明により、５０１〜１２００バイトは失われる。ＰＤＣＰレイヤは、集中式の並べ替えおよび再組み立てを実行する。
【０１９５】
本実施形態において、ＲＬＣレイヤで並べ替えおよび再組み立てを実行しない利点として、多重接続時の不要な再送信の回避が挙げられる。再組み立ておよび並べ替えがＲＬＣレイヤで実行された場合、両ｅＮＢのＲＬＣレイヤは、個々のＲＬＣステータスレポートをＲＬＣ  ＴＸに送信することになる（ｅＮＢ１のＲＬＣが８０１〜１２００バイトのステータスレポートを送信し、ｅＮＢ２のＲＬＣが５０１〜１２００バイトのステータスレポートを送信する。ここまで、実際に行方不明となっている部分は、８０１〜１２００バイトである）。この場合、ＲＬＣ  ＴＸは、必要以上のセグメントを再送信することも可能であるが、それはＲＬＣ  ＲＸで破棄されることになる。
【０１９６】
この問題を克服するため、本実施形態のＲＬＣレイヤは可能な限り透過的に作用し、中心の並べ替えおよび再組み立て機能は、ＰＤＣＰレイヤにて実行される。並べ替えおよび再組み立てを実行するため、ＰＤＣＰレイヤは、ＭＡＣレイヤのセグメントヘッダ（ＳＯおよびＬＳＦ）を理解する必要がある。分割がＭＡＣで実行されるためである。ＰＤＣＰは、ＭＡＣレイヤからＰＤＵを受信し、ＲＬＣレイヤに関して上記実施形態に説明したのと同様に、中心の並べ替えおよび再組み立てを実行する。これは、共通のセグメントと重なり、セグメントの行方不明部分すなわちいずれのｅＮＢによっても正しく受信されていない部分のみを示すステータスレポートを送信する。
【０１９７】
図１７を参照すれば、上述のような分割情報すなわちＳＯおよびＬＳＦをＭＡＣ  ＰＤＵが含むことが分かる。ただし、他の実施形態の場合と同様に、分割情報には、セグメント番号および代わりとなるセグメントの長さを含んでいてもよい。さらに、図１５は、ＲＬＣレイヤにおいてもＰＤＣＰ  ＳＮを使用して、オーバーヘッドを抑えることを示している。ただし、本開示はこれに限定されず、一般的には現行ＬＴＥと同様に、別個のシーケンス番号がＰＤＣＰおよびＲＬＣレイヤに用いられるようになっていてもよい。前述の通り、レイヤ間設計によって、送信の効率が向上する可能性もある。特に、ステータスレポートは、調整レイヤ（第３レイヤ、ＰＤＣＰ）の下のレイヤ（ＲＬＣ）で送受信され、調整レイヤに提供されてから、受信セグメントの整合および送信されるセグメントの決定がなされるのが好都合である。さらに、並べ替えおよび再組み立てのほか、再送信の調整を可能にするため、ＭＡＣ分割情報が調整レイヤに受け渡されるようになっていてもよい。
【０１９８】
ただし、ＰＤＣＰが再送信の調整を実行せず、セグメントが実際に各リンク上で冗長に再送信される場合であっても、本開示は、わずかに効率を落としながら、依然として作用し得る。図１７において、ＰＤＣＰ  ＲＸは、行方不明の８０１〜１２００バイトに関するステータスレポートを送信するのが好都合である。このステータスレポートは、（一般的に複数の）両ｅＮＢに送信されるのが好都合であり、両リンクを通じた再送信によってダイバーシティが実現される。ただし、本開示はこれに限定されず、一般的には、再送信を目的として、単接続が再確立されるようになっていてもよい。
【０１９９】
図１８に示すように、ＰＤＣＰ  ＴＸは、ステータスレポートの受信に際して、送信バッファからＰＤＣＰ  ＰＤＵ全体（１２００バイト）を取得し、ＰＤＣＰステータスレポートが示す８０１〜１２００バイトの再分割（抽出）を実行する。その後、８０１〜１２００バイトのＰＤＵセグメント（再分割ＰＤＵ）がＭＡＣに配送される。各ｅＮＢのＭＡＣレイヤは、上記実施形態に記載したリソース割り当てに従って、それ自身の分割を実行する。この場合、図１８に見られるように、（ｅＮＢ１に送信する）第１のＭＡＣエンティティは、８０１〜１２００バイトを２つのＭＡＣ  ＰＤＵ（すなわち、８０１〜９００バイトのＭＡＣ  ＰＤＵ１および９０１〜１２００バイトのＭＡＣ  ＰＤＵ２）に分割する。一方、（ｅＮＢ２に送信する）第２のＭＡＣエンティティは、８０１〜１２００バイトを８０１〜１０００バイトの第１のＭＡＣ  ＰＤＵ１および１００１〜１２００バイトの第２のＭＡＣ  ＰＤＵ２に分割する。
【０２００】
一般的には、代替手段も存在する。上述の通り、ＰＤＣＰは、再送信バッファからＰＤＵ全体を取得した後、ＰＤＣＰステータスレポートが示す行方不明パケットの再分割を実行する。
【０２０１】
ただし、上記の代替として、ＰＤＣＰステータスレポートは、ＭＡＣレイヤにより理解されるようになっていてもよい。したがって、ＰＤＣＰは、再分割を行うのではなく、ＰＤＵ全体をＭＡＣに受け渡す。そして、このＰＤＣＰステータスレポートに基づいて、ＭＡＣが分割を実行することになる。
【０２０２】
さらに別の可能性として、ＰＤＣＰがセグメントの行方不明部分をＲＬＣに通知することになる。その後、ＲＬＣレイヤは、ステータスレポートをＲＬＣ  ＴＸに送る。
【０２０３】
上記に対応して、図１９は、図１８の再送信の受信時の受信側（アップリンクデータ送信の本例におけるネットワーク側）を示している。特に、本例においては、すべてのセグメントがＭＡＣで正しく受信され、逆多重化される。ＲＬＣは基本的に、ＭＡＣから受信した分割情報と併せて、受信したセグメントをＰＤＣＰに受け渡す。ＰＤＣＰは、多重接続のすべてのノード（ここでは、ｅＮＢ１およびｅＮＢ２）から受信したすべてのセグメントの並べ替えおよび再組み立てを実行する。
【０２０４】
図２０は、通信システム２０００の一部であり、チャネル２０９０上で通信する送信装置２０００ｔおよび受信装置２０００ｒを示している。特に、上記実施形態に記載の通り、第４レイヤ処理ユニット２０４０ｔ、第３レイヤ処理ユニット２０３０ｔ、第２レイヤ処理ユニット２０２０ｔ、および第１レイヤ処理ユニット２０１０ｔが対応するレイヤの処理を実行する。送信機２０５０は、そのアンテナを介して、物理リソースにマッピングされた信号を送信する。これに対応して、受信装置２０００ｒは、第４レイヤ処理ユニット２０４０ｒ、第３レイヤ処理ユニット２０３０ｒ、第２レイヤ処理ユニット２０２０ｒ、および第１レイヤ処理ユニット２０１０ｒ、ならびにアンテナを通じて送信信号を受信する受信機２０６０を備える。
【０２０５】
図２１は、本開示に係る方法の実施形態のうちの１つを例示している。特に、左側には、データ送信側で実行される方法を示す一方、右側には、データ受信側で実行される方法を例示している。
【０２０６】
この送信方法は、第３のレイヤによって実行され、第３レイヤＳＤＵを受信するステップ２１１０ｔと、これに基づいて、たとえばヘッダの付加によりＰＤＵを生成するステップ２１２０ｔと、ＰＤＵを第２のレイヤに受け渡すステップ２１３０ｔとを含んでいてもよい。そして、第２レイヤ処理には、第３レイヤＰＤＵを第２レイヤＳＤＵとして受信するステップ２１４０ｔと、受信した割り当て（いくつかの実施形態においては、さらにステータスレポート）に基づいて、上述の通り分割または連結を実行するステップ２１５０ｔと、このように形成されたＰＤＵを第１のレイヤに受け渡すステップ２１６０ｔとを含んでいてもよい。そして、第１レイヤ処理には、第２のレイヤからＳＤＵを受信するステップ２１７０ｔと、これを物理リソースにマッピングするステップ２１８０ｔと、送信するステップ２１９０ｔとを含む。
【０２０７】
受信機においては、第１レイヤ処理の一部として、受信（２１９０ｒ）が実行された後、データが物理リソースからデマッピングされ（２１８０ｒ）、第２レイヤに受け渡される（２１７０ｒ）。第２レイヤ処理には、ＰＤＵを受信するステップ２１６０ｒと、これを逆多重化するステップ２１５０ｒと、第３のレイヤに受け渡して並べ替えおよび再組み立てを実行するステップ２１４０ｒとを含む（上述の通り、代替的な一実施形態においては、並べ替えおよび再組み立てが第２のレイヤにおいても実行される）。第３レイヤ処理には、ＰＤＵを受信するステップ２１３０ｒと、並べ替えおよび再組み立てを実行するステップ２１２０ｒと、再組み立てしたパケットを上位レイヤに受け渡すステップ２１１０ｒとを含む。
【０２０８】
さらに、第３のレイヤに再送信メカニズムを実装した実施形態も存在し、データ受信側でのステータスレポートの送信と、データ送信側でステータスレポートを受信するステップ２１２８ｔとを含む。いくつかのセグメントについてステータスレポートが否定応答を含む場合は（２１２５ｔ「ｙｅｓ」）、第３のレイヤ（あるいは、いくつかの実施形態においては第２のレイヤ）で再分割が実行される。
【０２０９】
以上をまとめて、本開示の一実施形態によれば、通信システムにおいてデータを無線インターフェース上でデータ受信ノードに送信するデータ送信ノードであって、データ受信ノードからフィードバックされたステータスレポートに従って自動再送要求（ＡＲＱ）再送信を実行するとともに、分割制御情報をデータに追加することを含むステータスレポートに含まれるセグメント長さ情報に基づいて再送信されるデータを再分割するか、または再分割しない第３レイヤ処理ユニットと、第３レイヤ処理ユニットから第３レイヤデータユニットを受信し、リソース割り当てに基づいて第３レイヤデータユニットを分割し、第３レイヤデータユニットの各セグメントおよび再分割が適用される場合に修正される分割制御情報を含む複数の第２レイヤデータユニットを形成する第２レイヤ処理ユニットと、第２のレイヤから、複数の第２レイヤデータユニットのうちの１つまたは複数を受信し、データ送信用に割り当てられたリソースに対して、複数の第２レイヤデータユニットのうちの１つまたは複数をマッピングする第１レイヤ処理ユニットと、を備えた、データ送信ノードが提供される。
【０２１０】
本開示の別の実施形態によれば、通信システムにおいてデータを無線インターフェース上でデータ受信ノードに送信するデータ送信ノードであって、データ受信ノードからフィードバックされたステータスレポートに従って自動再送要求（ＡＲＱ）再送信を実行する第３レイヤ処理ユニットと、第３レイヤ処理ユニットから第３レイヤデータユニットを受信し、ステータスレポートに従うとともにリソース割り当てに基づいて第３レイヤデータユニットを分割し、分割された第３レイヤデータユニットの各セグメントを含む複数の第２レイヤデータユニットを形成する第２レイヤ処理ユニットと、第２のレイヤから、複数の第２レイヤデータユニットのうちの１つまたは複数を受信し、データ送信用に割り当てられたリソースに対して、複数の第２レイヤデータユニットのうちの１つまたは複数をマッピングする第１レイヤ処理ユニットと、を備えた、データ送信ノードが提供される。
【０２１１】
本開示の別の実施形態によれば、通信システムにおいてデータを無線チャネル上でデータ送信ノードから受信するデータ受信ノードであって、データ送信用に割り当てられたリソースから、複数の第２レイヤデータユニットのうちの１つまたは複数をデマッピングするとともに、デマッピングされた複数の第２レイヤデータユニットのうちの１つまたは複数を第２レイヤ処理ユニットに提供する第１レイヤ処理ユニットと、複数の第３レイヤユニットセグメントおよび複数の第２レイヤデータユニットのうちの１つまたは複数からの分割制御情報の逆多重化を実行するとともに、分割制御情報と併せて、逆多重化された複数の第３レイヤユニットセグメントを第３レイヤ処理ユニットに転送する第２レイヤ処理ユニットと、逆多重化された複数の第３レイヤユニットセグメントの並べ替えおよび逆多重化された第３レイヤユニットセグメントの第３レイヤデータユニットとしての組み立てを実行する第３レイヤ処理ユニットと、を備えた、データ受信ノードが提供される。
【０２１２】
さらに、通信システムにおいてデータを無線インターフェース上でデータ受信ノードに送信する方法であって、データ受信ノードからフィードバックされたステータスレポートに従って自動再送要求（ＡＲＱ）再送信を実行するとともに、分割制御情報をデータに追加することを含むステータスレポートに含まれるセグメント長さ情報に基づいて再送信されるデータを再分割するか、または再分割しない第３レイヤ処理を実行するステップと、第３レイヤ処理ユニットから第３レイヤデータユニットを受信し、リソース割り当てに基づいて第３レイヤデータユニットを分割し、第３レイヤデータユニットの各セグメントおよび再分割が適用される場合に修正される分割制御情報を含む複数の第２レイヤデータユニットを形成する第２レイヤ処理を実行するステップと、第２のレイヤから、複数の第２レイヤデータユニットのうちの１つまたは複数を受信し、データ送信用に割り当てられたリソースに対して、複数の第２レイヤデータユニットのうちの１つまたは複数をマッピングする第１レイヤ処理を実行するステップと、を含む、方法が提供される。
【０２１３】
さらに、通信システムにおいてデータを無線インターフェース上でデータ受信ノードに送信する方法であって、データ受信ノードからフィードバックされたステータスレポートに従って自動再送要求（ＡＲＱ）再送信を実行する第３レイヤ処理と、第３レイヤ処理ユニットから第３レイヤデータユニットを受信し、ステータスレポートに従うとともにリソース割り当てに基づいて第３レイヤデータユニットを分割し、分割された第３レイヤデータユニットの各セグメントを含む複数の第２レイヤデータユニットを形成する第２レイヤ処理と、第２のレイヤから、複数の第２レイヤデータユニットのうちの１つまたは複数を受信し、データ送信用に割り当てられたリソースに対して、複数の第２レイヤデータユニットのうちの１つまたは複数をマッピングする第１レイヤ処理と、を含む、方法が提供される。
【０２１４】
さらに、通信システムにおいてデータを無線チャネル上でデータ送信ノードから受信する方法であって、データ送信用に割り当てられたリソースから、複数の第２レイヤデータユニットのうちの１つまたは複数をデマッピングするとともに、デマッピングされた複数の第２レイヤデータユニットのうちの１つまたは複数を第２レイヤ処理ユニットに提供する第１レイヤ処理と、複数の第３レイヤユニットセグメントおよび複数の第２レイヤデータユニットのうちの１つまたは複数からの分割制御情報の逆多重化を実行するとともに、分割制御情報と併せて、逆多重化された複数の第３レイヤユニットセグメントを第３レイヤ処理ユニットに転送する第２レイヤ処理と、逆多重化された複数の第３レイヤユニットセグメントの並べ替えおよび逆多重化された第３レイヤユニットセグメントの第３レイヤデータユニットとしての組み立てを実行する第３レイヤ処理と、を含む、方法が提供される。
【０２１５】
＜ＭＡＣサブヘッダ＞
ＭＡＣ  ＰＤＵは、バイト整列したビット列である。１つのＭＡＣ  ＰＤＵには、ＭＡＣ制御エレメントおよび／もしくはＭＡＣ  ＳＤＵならびに必要に応じてパディングと関連付けられたＭＡＣサブヘッダを少なくとも含む。ＭＡＣ制御エレメントは、ｅＮＢおよびＵＥのＭＡＣピア間のシグナリングに用いられる。ＭＡＣ  ＳＤＵは、上位レイヤ（ＲＬＣ）からのデータを含むため、ＲＬＣ  ＰＤＵに対応する。ＲＬＣ  ＰＤＵは、１つのサービスからのユーザデータを含む。ＭＡＣ  ＰＤＵは、ＭＡＣ制御エレメントおよびＭＡＣ  ＳＤＵごとにサブヘッダを含む。
【０２１６】
各サブヘッダは、論理チャネルＩＤ（ＬＣＩＤ）を含む。ＭＡＣ制御エレメントと関連付けられたサブヘッダにおいて、ＬＣＩＤは、搬送される各ＭＡＣ制御エレメントの制御エレメントタイプを指す。ＭＡＣ  ＳＤＵと関連付けられたサブヘッダにおいて、ＬＣＩＤは、搬送される各ＲＬＣ  ＰＤＵが属する論理チャネルの識別情報を示す。
【０２１７】
＜ユーザプレーンプロトコルスタック＞
図２２は、ユーザプレーンプロトコルスタックの例示的な構造を示している。上下方向には、第３のレイヤおよび第２のレイヤにおけるさまざまなデータユニットの配置を示している。最も上の行が第３レイヤＳＤＵを表し、２番目の行が第３レイヤＰＤＵを表し、３番目の行が第２レイヤＳＤＵを表し、最も下の行が第２レイヤＰＤＵを表す。図示の一実施形態においては、第３のレイヤがユーザプレーンのＲＬＣレイヤに対応し、第２のレイヤがユーザプレーンのＭＡＣレイヤに対応する。第４のレイヤは図示していないが、上記実施形態におけるユーザプレーンのＰＤＣＰレイヤに対応する。第３のレイヤおよび第２のレイヤは、破線によって視覚的に分離されている。
【０２１８】
データユニットは、論理チャネル（ＬＣ）を通じてＲＬＣレイヤからＭＡＣレイヤに受け渡される。図２２においては、論理チャネル識別子ＬＣＩＤ１およびＬＣＩＤ２を有する２つの論理チャネルを示している。ＬＣＩＤ１のチャネルに関するシグナリングおよびユーザデータは実線枠で示し、ＬＣＩＤ２と関連付けられたデータ要素は破線枠で示している。図に見られるように、異なる論理チャネルを通じて異なる量のデータユニットが提供されるようになっていてもよい。図示の例において、第３レイヤＳＤＵと関連付けられた最上行においては、第３レイヤＳＤＵに対応する最上行の２つのデータユニットがＬＣＩＤ１の第１の論理チャネルに属する（当該データユニットを「ＰＤＣＰ  ＰＤＵ１」および「ＰＤＣＰ  ＰＤＵ２」と表示）一方、１つのデータユニットがＬＣＩＤ２の第２の論理チャネルに属する（「ＰＤＣＰ  ＰＤＵ１」）。第３レイヤＳＤＵが対応する論理チャネルによって識別可能であることから、図中、２つの異なる論理チャネルが操作する２つの第３レイヤＳＤＵは、同じラベル「ＰＤＣＰ  ＰＤＵ１」を有する。ただし、本開示は、図２２に示す場合に限定されず、その代替として、ＴＢに割り当てられる同じ量のデータを異なる論理チャネルが操作するようになっていてもよい。また、論理チャネルが１つだけ存在していてもよいし、３つ以上存在していてもよい。
【０２１９】
識別子がＬＣＩＤ１およびＬＣＩＤ２の異なる論理チャネルを通じて、第４レイヤ処理ユニットから、第３レイヤＳＤＵとして処理される第４レイヤＰＤＵ（ＰＤＣＰ  ＰＤＵ１、ＰＤＣＰ  ＰＤＵ２、およびＰＤＣＰ  ＰＤＵ１と表示）が第３レイヤ処理ユニットにより受信される。第３レイヤＳＤＵに対応する第４レイヤＰＤＵそれぞれに対して、シーケンス番号（「ＲＬＣ  ＳＮ」として言及）を含む第３レイヤヘッダを追加することにより、第３レイヤ処理ユニットは、それぞれ第３レイヤヘッダおよび第３レイヤＳＤＵから成る第３レイヤＰＤＵを生成する。そして、第３レイヤＰＤＵは、第２のレイヤに転送され、第２レイヤＰＤＵとして受信される。２番目の行に示す第３レイヤＳＤＵが３番目の行に示す第２レイヤＰＤＵと同一であるものの、これら同一のデータユニットを図２２において重複して示しているのは、説明を理由としているに過ぎない。
【０２２０】
第２レイヤ処理ユニットは、第３のレイヤから第２レイヤＳＤＵを受信し、１つまたは複数の第２レイヤＳＤＵを何らかの第２レイヤ制御情報および場合によりパディングと連結することによって、図２２の最も下の行に示す第２レイヤＰＤＵを生成する。第２レイヤＰＤＵの生成においては、異なるデータ要素が連結される。特に、各ユーザデータおよび制御エレメントに対して、それぞれ「ＭＡＣ  ＬＣＩＤ０＋Ｌ」、「ＭＡＣ  ＬＣＩＤ１＋Ｌ」、「ＭＡＣ  ＬＣＩＤ２＋Ｌ」、「ＭＡＣ  ＬＣＩＤ  Ｐ」と表示する第２レイヤサブヘッダが提供される。このような表示は、（優先順位が割り当てられる）各ＬＣＩＤおよび長さ情報（Ｌ）に対応する優先順位決定制御情報をサブヘッダが搬送することを示す。第２レイヤ制御エレメント（「ＭＡＣ  ＣＥ」と表示）は、必要に応じて、第２レイヤＰＤＵのほか、パディングにもさらに挿入されるようになっていてもよい。図中、対応するサブヘッダ（「ＭＡＣ  ＬＣＩＤ  Ｐ」）を伴って、ＭＡＣ  ＰＤＵの最後にパディングを示している。パディングの前に対応するサブヘッダが存在する場合としては、単なるパディングの代わりにＭＡＣ  ＰＤＵに含まれ得るパディングＢＳＲが考えられる（パディングＢＳＲについては、非特許文献７の第５．４．５項も参照（本明細書に援用））。
【０２２１】
なお、いくつかのＬＴＥバージョンにおいては、パディングの長さに応じて、パディングに対応するサブヘッダが割り当てられる場合がある。特に、１バイトまたは２バイトのパディングが必要な場合を除いて、ＭＡＣ  ＰＤＵの最後にパディングが挿入される。１バイトまたは２バイトのパディングが必要な場合は、その他如何なるＭＡＣ  ＰＤＵサブヘッダの前に、パディングを表す１つまたは２つのＭＡＣ  ＰＤＵサブヘッダがＭＡＣ  ＰＤＵの最初に配置される。
【０２２２】
ＬＴＥの専門用語に関して、図２２は、単一のＭＡＣ  ＰＤＵへと連結された２つの異なる論理チャネルのＰＤＣＰ  ＰＤＵ（各ＲＬＣ  ＳＤＵを表す）を示している。この場合は、２つの論理チャネルに対応する３つのＭＡＣ  ＳＤＵを連結するとともに対応するＭＡＣサブヘッダをそれぞれに追加した後にも、割り当てられたリソースには、いくつかの場所が残っている。この場所には、１つまたは複数のＭＡＣ  ＣＥが挿入されるのが好都合である。いくつかの場所が依然として残る場合は、パディングが適用される。ＭＡＣ  ＰＤＵに対して単一のＭＡＣヘッダの代わりに各ＭＡＣサブヘッダを提供することにより、少なくともＭＡＣ  ＰＤＵを部分的に前処理可能である。
【０２２３】
上記に対応して、図２２に示すとともに上述したユーザプレーンプロトコルスタックは、ＮＲの例示的なユーザプレーンプロトコルスタックである。このようなユーザプレーンにより、第３レイヤヘッダおよび第２レイヤサブヘッダの前処理が可能となる。特に、第２レイヤサブヘッダが関連付けられた第２レイヤＳＤＵは、ＴＢ全体（ＭＡＣ  ＰＤＵ全体）が構築される前に、第１のレイヤに配送可能である。一方では、これによって、処理遅延を低減可能である。
【０２２４】
前述の処理遅延の低減を可能にすることに関連する利点は、本開示の実施形態により与えられるように、適当な第２レイヤ（ＭＡＣ）ＰＤＵフォーマットの結果である。以下、図２３〜図３０を参照して、第２レイヤＰＤＵフォーマットのさまざまな構成を説明する。これらの図においては、第２のレイヤがＭＡＣレイヤに対応するものと仮定するが、本開示は、第２のレイヤがＭＡＣレイヤである場合に限定されない。
【０２２５】
図２３は、図２２に関して説明したユーザプレーンプロトコルスタックに対応する例示的な第２レイヤＰＤＵを示した模式図である。第２レイヤＰＤＵには、２つの第２レイヤＳＤＵ、２つの第２レイヤ制御エレメント（ＣＥ）、対応する４つの各第２レイヤサブヘッダ、およびパディングを含む。各第２レイヤサブヘッダは、各第２レイヤＳＤＵおよび各第２レイヤ制御エレメントとそれぞれ関連付けられている。第２レイヤサブヘッダはそれぞれ、第２レイヤＳＤＵまたは関連する第２レイヤ制御エレメントに先行する。図中、各第２レイヤサブヘッダから各第２レイヤ制御エレメントまたは第２レイヤＳＤＵに向かう矢印によって、この関係を示している。図２４〜図３０においても、第２レイヤサブヘッダの関係を表すのに、同じ矢印表記を使用する。図２３に示す第２レイヤＰＤＵフォーマットにおいて、第２レイヤ制御エレメントは、すべての第２レイヤＳＤＵの前すなわち任意の第２レイヤＳＤＵの前に配置されている。言い換えると、第２レイヤ制御エレメントはそれぞれ、第２レイヤＳＤＵに先行する。パディングは、第２レイヤＰＤＵの最後に配置されている。ただし、この第２レイヤＰＤＵフォーマットにおいて、パディングは第２レイヤＰＤＵの任意選択的な構成要素に過ぎず、割り当てられた物理リソースに対応するＭＡＣ  ＰＤＵの長さに場所が残っている場合にのみ適用可能であって、この残った場所はあまりにも小さく、送信対象のその他如何なるＭＡＣ  ＳＤＵもＭＡＣ  ＣＥも収容できない。このことは、本明細書のその他の部分で説明する如何なる実施形態に係る如何なる第２レイヤＰＤＵフォーマットにも当てはまる。
【０２２６】
図２３においては、第２レイヤＳＤＵの数および第２レイヤ制御エレメントの数がともに２つである。ただし、本開示は、特定数の第２レイヤ制御エレメントにも、特定数の第２レイヤＳＤＵにも限定されない。特定数の第２レイヤ制御エレメントまたは第２レイヤＳＤＵを提案するのではなく、この図は、第２レイヤＰＤＵ内の第２レイヤサブヘッダ、第２レイヤＳＤＵ、第２レイヤ制御エレメント、およびパディングの特定の順序を示している。
【０２２７】
図２２を参照して前述した通り、図２３の配置には、ＭＡＣ  ＰＤＵ全体の組み立てを待つことなく、それぞれ対応するサブヘッダを有する各ＭＡＣ  ＣＥまたはＭＡＣ  ＳＤＵを個別に下位レイヤに提供可能という利点がある。
【０２２８】
図２３の第２レイヤＰＤＵフォーマットの欠点として、如何なる第２レイヤ制御エレメントも第２レイヤＳＤＵの前に配置されていることから、第２レイヤ処理ユニットが利用可能な第２レイヤＳＤＵを物理レイヤに配送できるのは、第２レイヤ制御エレメントの演算後のみである。ただし、いくつかのＭＡＣ  ＣＥを演算するため、優先順位決定手順等の計算が打ち切られるものとする。一方、いくつかのＭＡＣ  ＳＤＵの準備にはほとんど時間を要さない。ただし、ＭＡＣ  ＣＥの計算前には物理レイヤに提供することができない。
【０２２９】
＜ＭＡＣ制御エレメントの効率的なシグナリング＞
前述の欠点に対処するため、図２４は、ＭＡＣ  ＰＤＵの有利な一実施形態を示しており、如何なるＭＡＣ  ＳＤＵもＭＡＣ  ＣＥに先行する。特に、ＭＡＣ  ＰＤＵ２４００は、関連するサブヘッダ２４１ａが先行する第１のＭＡＣ  ＳＤＵ２４３ａから始まる。第１のＭＡＣ  ＳＤＵには、そのサブヘッダ２４１ｂを伴う第２のＭＡＣ  ＳＤＵ２４３ｂが続く。本例においては、ＭＡＣ  ＳＤＵが２つだけ存在しており、その論理チャネルＩＤ（優先順位）がそれぞれのサブヘッダにおいて伝えられるようになっていてもよい。ただし、本実施形態において、ＭＡＣ  ＰＤＵは、３つ以上のＭＡＣ  ＳＤＵを含んでいてもよい。ＭＡＣ  ＰＤＵ２４００は、第１のＭＡＣ  ＣＥ２４４ａと関連付けられたＭＡＣサブヘッダ２４２ａと、それに続いて、第２のＭＡＣ  ＣＥ２４４ｂと関連付けられたＭＡＣサブヘッダ２４２ｂとをさらに含む。ＭＡＣサブヘッダ２４２ａ、２４２ｂは、関連するそれぞれのＭＡＣ  ＣＥ２４４ａまたは２４４ｂに先行する。図示のように、ＭＡＣ  ＣＥ２４４ａおよびＭＡＣ  ＣＥ２４４ｂのほか、それぞれのＭＡＣサブヘッダ２４２ａおよび２４２ｂは、ＭＡＣ  ＳＤＵ２４３ａおよびＭＡＣ  ＳＤＵ２４３ｂならびにそれぞれのサブヘッダ２４１ａ、２４１ｂのいずれよりも後である。
【０２３０】
本実施形態は、２つのＭＡＣ  ＣＥが存在する場合に限定されない。ＭＡＣ  ＣＥが１つだけ存在していてもよいし、３つ以上存在していてもよい。さらに、ＭＡＣ  ＣＥの数がＭＡＣ  ＳＤＵの数に等しい場合を図に示すが、ＭＡＣ  ＣＥの数は、ＭＡＣ  ＳＤＵの数と異なっていてもよい。本実施形態に係るＭＡＣ  ＰＤＵにおいては、ＭＡＣ  ＳＤＵよりＭＡＣ  ＣＥが少なくてもよいし、ＭＡＣ  ＳＤＵよりＭＡＣ  ＣＥが多くてもよい。如何なるＭＡＣ  ＣＥも、それと関連付けられた如何なるＭＡＣサブヘッダも、ＭＡＣ  ＰＤＵおよびそれと関連付けられたサブヘッダの後であることは、本実施形態の特徴である。任意選択として、パディング２４５が追加されていてもよい。ＭＡＣ  ＳＤＵ、ＭＡＣ  ＣＥ、およびそれぞれのＭＡＣサブヘッダにＴＢの全リソースが使われている場合は、パディングが省略されてもよい。
【０２３１】
一般的には、ＭＡＣ  ＳＤＵおよびＭＡＣ  ＣＥをそれぞれのＭＡＣサブヘッダとともにマッピングした後にも、送信用に割り当てられたリソースに自由なリソースが残っており、これらの自由なリソースがそれ以上のＭＡＣ  ＣＥまたはＭＡＣ  ＳＤＵの搬送に不十分な場合に、パディングが挿入される。
【０２３２】
したがって、通信システム３１００においてデータを無線チャネル上でデータ受信ノードに送信するデータ送信ノードは、図２４に例示のＭＡＣ  ＰＤＵを生成することによって、処理遅延を低減するようにしてもよい。特に、このようなノードは、図３１に示す機器３１００ｔに対応していてもよく、第２レイヤ処理ユニット３１２０ｔおよび第１レイヤ処理ユニット３１１０ｔを備える。第２レイヤ処理ユニット３１２０ｔは、第３レイヤ処理ユニット３１３０ｔから、データ送信用に割り当てられたリソースにマッピングされる少なくとも１つの第２レイヤサービスデータユニット（ＳＤＵ）を受信するとともに、第２レイヤＰＤＵを生成するのに適している。このような第２レイヤ処理ユニットにより生成された第２レイヤＰＤＵには、第３のレイヤから受信した少なくとも１つの第２レイヤＳＤＵと、当該少なくとも１つの第２レイヤＳＤＵのいずれよりも後の少なくとも１つの第２レイヤ制御エレメントとを含む。第１レイヤ処理ユニット３１１０ｔは、第２レイヤ処理ユニットにより生成された第２レイヤＰＤＵを受信するとともに、データ送信用に割り当てられたリソースに第２レイヤＰＤＵをマッピングするのに適している。
【０２３３】
一方、通信システム３１００においてデータを無線チャネル上でデータ送信ノードから受信する受信ノードは、図２４に例示のＭＡＣ  ＰＤＵを受信・処理することによって、処理遅延を低減するようにしてもよい。特に、このようなノードは、図３１に示す機器（データ受信ノード）３１００ｒに対応していてもよく、第１レイヤ処理ユニット３１１０ｒおよび第２レイヤ処理ユニット３１２０ｒを備える。ここで、第１レイヤ処理ユニット３１１０ｒは、データ受信用に割り当てられたリソースから、少なくとも１つの第２レイヤプロトコルデータユニット（ＰＤＵ）をデマッピングするのに適している。さらに、第２レイヤ処理ユニット３１２０ｒは、第１レイヤ処理ユニットによりデマッピングされた第２レイヤＰＤＵを受信して構文解析するのに適している。このような第２レイヤ処理ユニットにより受信・構文解析された第２レイヤＰＤＵには、データ受信ノード３１００ｒに含まれる第３レイヤ処理ユニット３１３０ｒに転送される少なくとも１つの第２レイヤＳＤＵと、当該少なくとも１つの第２レイヤＳＤＵのいずれよりも後の少なくとも１つの第２レイヤ制御エレメントとを含む。
【０２３４】
データ送信ノードの第２レイヤ処理ユニットにより生成される第２レイヤＰＤＵおよびこれに対応してデータ受信ノードの第２レイヤ処理ユニットにより受信・構文解析される第２レイヤＰＤＵは、少なくとも１つの第２レイヤＳＤＵそれぞれと関連付けられた各第２レイヤサブヘッダと、少なくとも１つの第２レイヤ制御エレメントそれぞれと関連付けられた各第２レイヤサブヘッダとをさらに含むと好都合である。前述の通り、単一のＭＡＣヘッダではなく複数の各ＭＡＣサブヘッダをＭＡＣ  ＰＤＵに設けることにより、ＭＡＣ  ＰＤＵ全体ではなく、ＭＡＣ  ＰＤＵの一部を下位レイヤに転送することができる。一方、これによって、ＭＡＣ  ＰＤＵの一部が下位レイヤによって先に処理され得るため、遅延が抑えられる。
【０２３５】
なお、いくつかのシステムにおいては、ＭＡＣ  ＣＥおよび／またはＳＤＵのサブヘッダが不要となる場合もある。ＬＴＥのようなシステムにおいて、サブヘッダには通常、チャネルタイプ指定および長さ指定を含む場合がある。チャネルタイプ指定は、特定のＭＡＣ  ＰＤＵ部の優先順位決定に役立ち得る。長さ指定は、ＭＡＣ  ＳＤＵおよび／またはＭＡＣ  ＣＥの長さ等の対応するデータ部の長さを特定する。ただし、いくつかのシステムにおいて、ＭＡＣ  ＳＤＵは、所定の長さまたは別の方法で設定された長さを有していてもよく、いずれにしろ長さ指定が不要となる場合もある。
【０２３６】
図２５は、現行のＬＴＥ規格により知られているフォーマットと類似するＭＡＣ  ＳＤＵのサブヘッダフォーマットの一例を示している（非特許文献７の第６．２．１項も参照（本明細書に援用））。図２４に示したのと同じフォーマットを有するＭＡＣ  ＰＤＵを示しており、ＭＡＣサブヘッダのフォーマットは、ＭＡＣ  ＳＤＵ（図中、ＭＡＣ  ＳＤＵ２と表示）と関連付けられたＭＡＣサブヘッダにより例示される。このＭＡＣ  ＳＤＵはＭＡＣ  ＳＤＵ２４３ｂに対応し、その関連するＭＡＣサブヘッダは、図２４に示すＭＡＣサブヘッダ２４１ｂに対応する。したがって、ＭＡＣサブヘッダには、予約ビット（Ｒ）、フォーマット２フィールド（Ｆ２）、拡張フィールド（Ｅ）、論理チャネルＩＤ（ＬＣＩＤ）フィールドを含む。さらに、サブヘッダがＭＡＣ  ＳＤＵまたは可変サイズのＭＡＣ制御エレメントと関連付けられている場合は、長さフィールド（Ｌ）およびフォーマットフィールド（Ｆ）を含む。
【０２３７】
拡張フィールドＥは、１ビットのフィールドであってもよい。ＬＴＥにおいて、１行のＲ／Ｆ２／Ｅ／ＬＣＩＤは１オクテット（バイトすなわち８ビット）の長さであり、Ｒフィールドが１ビット長、Ｆ２フィールドが１ビット長、Ｅフィールドが１ビット長、ＬＣＩＤが５ビット長である。ＬＴＥにおいてすでに、Ｆ２＝１は、対応するＭＡＣ  ＳＤＵまたは可変サイズの制御エレメントのサイズが３２７６７バイト（１５ビット長のフィールドに対応）よりも大きく、当該サブヘッダがＭＡＣ  ＰＤＵの最後のサブヘッダではないことを示している。拡張フィールドＥは、ＰＤＵにおける別のＭＡＣサブヘッダの存在を示す。特に、値Ｅ＝１は、少なくともＲ／Ｆ２／Ｅ／ＬＣＩＤフィールド（ひいては、場合により対応するＳＤＵまたはＣＥ）を含む少なくとも１つ以上のＭＡＣサブヘッダがＭＡＣ  ＰＤＵの構文解析方向に後続することを示す。ＬＴＥにおける構文解析方向は、ＭＡＣ  ＰＤＵの最初（ヘッダから始まる）から最後に向かうものと仮定する。これは、図２５にも当てはまり、構文解析方向は左から右である。
【０２３８】
図２４においては、フィールドＦおよびＬを有するサブヘッダの２行目にこのような付加的なオクテットを示している。一般的に、ヘッダのオクテットが１つだけである場合は、長さフィールドＬが存在しない。したがって、ＭＡＣ  ＳＤＵの長さが伝えられることはない。ＬＴＥにおいて、ＭＡＣサブヘッダが固定長のＭＡＣ制御エレメントと関連付けられている場合は、ＭＡＣサブヘッダに第２のオクテットが含まれない。この場合、固定長のＭＡＣ制御エレメントの長さは、当該ＭＡＣ制御エレメントのタイプを特定するＬＣＩＤにより把握される。Ｆフィールドは、Ｌフィールドの長さを示しており、ＬＴＥにおいては、７ビットまたは１５ビット長であってもよい（したがって、１つまたは２つのオクテットにわたって拡がる）。Ｒフィールドは、現行のＬＴＥ規格において予約されているものの、規格の後続バージョンでは、別の１つまたは複数のインジケータで置き換えられてもよい。言い換えると、現行規格に従って動作する受信機では、Ｒフィールドが無視される。
【０２３９】
後述の通り、構文解析方向は一般的に、ＭＡＣ  ＰＤＵのフォーマットに応じて、ＭＡＣ  ＰＤＵの最初からＭＡＣ  ＰＤＵの最後に向かう方向であってもよいし、その逆であってもよい。
【０２４０】
ＬＴＥにおけるＭＡＣサブヘッダのフィールドについては、非特許文献７の第６．２．１項も参照可能であり、これを本明細書に援用する。
【０２４１】
ＬＣＩＤフィールドは、たとえばＬＴＥのように５ビットを有し、サブヘッダのタイプおよび論理チャネルを示す。あるいは、サブヘッダが制御エレメントと関連付けられている場合は、制御エレメントタイプを示す。ここで、サブヘッダのタイプは、サブヘッダがＭＡＣ  ＣＥサブヘッダであるか、ＭＡＣ  ＳＤＵサブヘッダであるか、またはそれ以外（たとえば、予約、パディング等）であるかを意味する。各ＭＡＣ  ＣＥタイプのサブヘッダは、ＭＡＣ  ＣＥのタイプを一意に規定する。たとえば、「１１１０１」は短いＢＳＲを表し、「１１０１０」はＰＨＲを表す一方、「１１０１１」はＣ−ＲＮＴＩを表し、「１１１１１」はパディングを表す。
【０２４２】
ＬＴＥにおける長さフィールドＬは、７ビットあるいは１５ビットを有していてもよく、サブヘッダがＭＡＣ制御エレメントと関連付けられているかＭＡＣ  ＳＤＵと関連付けられているかに応じて、ＭＡＣ  ＳＤＵの長さまたはＭＡＣ制御エレメントの長さを示す。Ｌフィールドにおいて、ＭＡＣ  ＳＤＵまたはＭＡＣ制御エレメントの長さは、バイト単位で与えられる。さらに、フォーマットフィールドＦは、Ｌフィールドの長さを示す１ビットのフィールドであってもよい。たとえば、値Ｆ＝０は、Ｌフィールドが７ビットを有することを示していてもよい。一方、値Ｆ＝１は、Ｌフィールドが１５ビットを有することを示していてもよい。
【０２４３】
ただし、本開示は、現行のＬＴＥ規格のサブヘッダフォーマットに限定されない。Ｅ、ＬＣＩＤ、Ｆ、およびＬフィールドの長さおよび値は、ＭＡＣサブヘッダの有利な一実施態様に対応した一例である。ただし、本開示の一実施形態に対応する構造を有するＭＡＣサブヘッダは、異なるフィールド長または可変値を用いて実装されるようになっていてもよい。
【０２４４】
本開示の例示的な一実施形態に係る例示的なＭＡＣ  ＰＤＵを図２６に示す。このＭＡＣ  ＰＤＵのフォーマットは、図２４に示すＭＡＣ  ＰＤＵのフォーマットに対応する。図２６に示すＭＡＣ  ＰＤＵには、ＭＡＣ  ＳＤＵおよびＭＡＣ制御エレメントを含むが、これらはすべて、それぞれの各ＭＡＣサブヘッダが先行する。ＭＡＣ  ＰＤＵの最後には、任意選択的な構成要素としてパディングを示している。本例においては、１つのＭＡＣ制御エレメントすなわちＢＳＲ  ＭＡＣ制御エレメントのみを示している。ただし、図２４に示すＭＡＣ  ＰＤＵフォーマットに対応して、ＭＡＣ制御エレメントおよびその各ＭＡＣサブヘッダは、各ＭＡＣ  ＳＤＵ（図中のＭＡＣ  ＳＤＵ１およびＭＡＣ  ＳＤＵ２）およびそれぞれの各ＭＡＣサブヘッダの後に配置されている。図示していないものの、ＭＡＣ  ＰＤＵに含まれる各ＭＡＣ  ＳＤＵおよび各ＭＡＣ  ＳＤＵの各ＭＡＣサブヘッダの後には、ＢＳＲ  ＭＡＣ制御エレメントの代わりに、異なる種類のＭＡＣ制御エレメントおよびその関連するサブヘッダが配置されていてもよい。たとえば、ＭＡＣ制御エレメントは、電力ヘッドルームレポート、ＢＳＲ（短いＢＳＲ、長いＢＳＲ、または不完全なＢＳＲ）、またはＣ−ＲＮＴＩであってもよい。したがって、第２レイヤ制御エレメントは、バッファステータスレポート、Ｃ−ＲＮＴＩ、および電力ヘッドルームレポートのいずれかであり、任意のバッファステータスレポート、Ｃ−ＲＮＴＩ、または電力ヘッドルームレポートと関連付けられた各第２レイヤサブヘッダは、少なくとも１つの第２レイヤＳＤＵそれぞれの後に配置される。
【０２４５】
図２４に示す実施形態に係るＭＡＣ  ＰＤＵにおいては、ＭＡＣ  ＣＥ（たとえば、ＢＳＲ  ＭＡＣ  ＣＥおよびＰＨＲ  ＭＡＣ  ＣＥ）およびそれぞれの関連するＭＡＣサブヘッダが常にＭＡＣ  ＳＤＵの後に配置されており、一方、ＭＡＣ  ＳＤＵおよびそれぞれの関連するＭＡＣサブヘッダは、ＴＢに対応するＭＡＣ  ＰＤＵの最初に位置付けられる。したがって、ＭＡＣ  ＰＤＵの最初は、ＭＡＣ  ＣＥに依存しない。たとえば、ＭＡＣ  ＣＥがＢＳＲの場合は、ＬＣＰの結果全体に依存せず、ＰＨＲの計算は、この値をＭＡＣに入力する物理レイヤに依存する。この独立性により、ＭＡＣ  ＰＤＵが完全に構成される前であっても、（最初のＭＡＣ  ＳＤＵの準備ができた場合に）ＭＡＣ  ＰＤＵの最初を第１レイヤ（物理レイヤ）処理ユニットに送ることができる。したがって、第２の（ＭＡＣ）レイヤは、最初の第２レイヤＳＤＵの準備ができた場合に、パケットの第１の（物理）レイヤへの転送を開始可能であり、第２レイヤ処理ユニットは、第２レイヤＰＤＵに属するパケットを下位レイヤに転送する前に、第２レイヤＰＤＵ全体を組み立てるまで待つ必要がない。これは、送信処理遅延の低減に有効であり、送信側すなわちデータ送信ノードは、ＢＳＲおよびＰＨＲの演算により多くの処理時間を使うことができる。ＢＳＲ  ＭＡＣ制御エレメントおよびＭＡＣ  ＰＨＲ制御エレメントはともに、ＴＢの最後すなわちＭＡＣ  ＰＤＵに含まれるＭＡＣ  ＳＤＵの後に位置付けられているためである。
【０２４６】
図２４および図２６に示すＭＡＣ  ＰＤＵフォーマットおよびこれに対応して図２５に示すＭＡＣサブヘッダ構造を使用する利点として、分割対象の最後の１つを除くほとんどのＭＡＣサブヘッダおよびＭＡＣ  ＳＤＵを前処理可能である。ただし、このようなＭＡＣ  ＰＤＵフォーマットは、送信機で扱いやすいものの、受信機では、特定種類のＭＡＣ  ＣＥすなわち（ｅＮＢからＵＥに送信された）ダウンリンク中のアクティブ化／非アクティブ化ＭＡＣ  ＣＥおよびＵＥコンテンション解決ＭＡＣ  ＣＥまたは（ＵＥからｅＮＢへの）アップリンク中のＣ−ＲＮＴＩを可能な限り素早く受信して処理することが重要となる可能性もある。したがって、ＬＴＥにおいては、これを主な理由として、ＭＡＣ  ＰＤＵの如何なるＭＡＣ  ＳＤＵよりも前にＭＡＣ  ＣＥが配置される。
【０２４７】
特定種類のＭＡＣ制御エレメント（ＤＬにおけるアクティブ化／非アクティブ化ＭＡＣ  ＣＥおよびＵＥコンテンション解決ＭＡＣ  ＣＥまたはＵＬにおけるＣ−ＲＮＴＩ）の早期処理は、図２７に示す本開示の一実施形態によって実現可能である。図示のＭＡＣ  ＰＤＵにおいては、ＭＡＣ制御エレメントおよびその関連するサブヘッダがＭＡＣ  ＰＤＵの最初に配置されており、（この場合はＭＡＣ  ＰＤＵの最初から最後に向かう構文解析方向に）ＭＡＣサブヘッダが関連するＭＡＣ制御エレメントに先行する。特に、図示のＭＡＣ制御エレメントは、アクティブ化／非アクティブ化ＭＡＣ  ＣＥである。アクティブ化／非アクティブ化ＭＡＣ  ＣＥは、如何なるＭＡＣ  ＳＤＵおよびＭＡＣ  ＳＤＵと関連付けられた如何なるＭＡＣサブヘッダにも先行する。図中、２つのＭＡＣ  ＳＤＵおよびそれぞれの関連するＭＡＣサブヘッダを示している。ただし、本開示の本実施形態は、ＭＡＣ  ＳＤＵの数が２つであることに限定されない。この代替として、ＭＡＣ  ＳＤＵが１つだけ存在していてもよいし、３つ以上のＭＡＣ  ＳＤＵがＭＡＣ  ＰＤＵに含まれていてもよい。図示のＭＡＣ制御エレメントは、アクティブ化／非アクティブ化ＣＥであるが、これの代替または追加として、ＭＡＣ  ＳＤＵの最初すなわちＭＡＣ  ＳＤＵおよびＭＡＣ  ＳＤＵと関連付けられた任意のＭＡＣサブヘッダの前には、ＵＥコンテンション解決ＭＡＣ  ＣＥおよびその関連するサブヘッダまたはＣ−ＲＮＴＩおよびそのサブヘッダが配置されていてもよい。図示のように、本実施形態のＭＡＣ  ＳＤＵは、必要に応じてパディングで終了していてもよい。
【０２４８】
言い換えると、ＭＡＣ  ＣＥは、ＭＡＣ  ＰＤＵの組み立て時に、そのタイプに応じて、ＭＡＣ  ＳＤＵの前または後に配置される。ＭＡＣ  ＣＥタイプは、各ＭＡＣ  ＣＥサブヘッダ（たとえば、ＬＣＩＤフィールド内）に規定されていてもよい。
【０２４９】
異なる種類のＭＡＣ  ＣＥがＭＡＣ  ＰＤＵに含まれていてもよく、そのうちの１つのタイプがＭＡＣ  ＰＤＵの最初すなわちＭＡＣ  ＳＤＵの前に配置されるのが好都合であり、別のタイプがＭＡＣ  ＰＤＵの最後すなわちＭＡＣ  ＳＤＵの後に配置されるのが好都合である。したがって、本開示の例示的な一実施形態においては、第２レイヤＳＤＵの後に配置された少なくとも１つの第２レイヤ制御エレメントのほか、第２レイヤＳＤＵの前に配置された第２レイヤ制御エレメントを第２レイヤＰＤＵがさらに含む。任意の第２レイヤＳＤＵの前に配置された第２レイヤ制御エレメントと関連付けられた第２レイヤサブヘッダはさらに、第２レイヤＰＤＵの最初の各第２レイヤ制御エレメントの前に包含・配置されていてもよい。
【０２５０】
本実施形態に係るＭＡＣ  ＰＤＵフォーマットの一例を図３３に示す。ＭＡＣ  ＰＤＵの最初には、ＭＡＣ  ＣＥすなわちＣ−ＲＮＴＩ  ＭＡＣ  ＣＥが存在し、このＣ−ＲＮＴＩ  ＭＡＣ  ＣＥと関連付けられたサブヘッダが先行する。Ｃ−ＲＮＴＩ  ＭＡＣ  ＣＥの後には、２つのＭＡＣ  ＳＤＵがＭＡＣ  ＰＤＵに含まれており、それぞれと関連するＭＡＣサブヘッダが先行する。ただし、本開示は、第２レイヤＳＤＵの数が２つであることに限定されず、１つまたは３つ以上の第２レイヤ制御エレメントが存在していてもよい。最後のＭＡＣ  ＳＤＵの後には、別のＭＡＣ  ＣＥが含まれており、これと関連するＭＡＣサブヘッダが先行する。図示の例において、このＭＡＣ  ＣＥは、ＢＳＲ  ＭＡＣ  ＣＥである。ただし、本開示は、任意のＭＡＣ  ＳＤＵの前のＭＡＣ  ＣＥがＣ−ＲＮＴＩ  ＭＡＣ  ＣＥであることに限定されず、任意のＭＡＣ  ＳＤＵの後のＭＡＣ  ＣＥがＢＳＲ  ＭＡＣ  ＣＥであることにも限定されない。Ｃ−ＲＮＴＩの代わりに、たとえばアクティブ化／非アクティブ化ＭＡＣ  ＣＥが存在していてもよく、ＢＳＲ  ＭＡＣ  ＣＥの代わりに、たとえばＭＡＣ  ＰＨＲ制御エレメントが存在していてもよい。さらに、各ＭＡＣ  ＳＤＵの前に配置された１つのＭＡＣ  ＣＥおよび後に配置された１つのＭＡＣ  ＣＥの代わりに、２つ以上のＭＡＣ  ＣＥが任意のＭＡＣ  ＳＤＵの前および／または後に配置されていてもよい。任意選択として、各ＭＡＣ  ＳＤＵの後に配置されたＭＡＣ  ＣＥの後では、ＭＡＣ  ＰＤＵの最後にパディングが含まれる。本開示は、ＬＴＥにより現在規定されているＣＥに限らず、如何なるシステムの如何なるＣＥにも適用可能である。一般的に、長い計算時間または他のレイヤからの入力を要するＣＥは、ＭＡＣ  ＰＤＵの最後に配置され得るのが好都合である。一方、利用可能なＣＥは、ＭＡＣ  ＰＤＵの最初に配置されていてもよい。
【０２５１】
図３３に示すＭＡＣ  ＰＤＵフォーマットは、下位レイヤ／上位レイヤへのＴＢ全体の転送のみならず、ＴＢの一部の転送を可能にする送信機／受信機に使用し得るのが好都合である。たとえば、ＴＢは、個々のコードワードとなる複数の部分へと細分されるとともに、各ＣＲＣにより提供されるようになっていてもよい。
【０２５２】
このため、ＭＡＣ  ＰＤＵがＴＢのさまざまな部分において分割され、Ｃ−ＲＮＴＩ  ＭＡＣ  ＣＥ等のＭＡＣ  ＣＥがＭＡＣ  ＰＤＵの最初に配置されている場合、これらのＭＡＣ  ＣＥは、ＴＢ全体の完成および転送を待つ必要なく、送信機において、コードワード内で物理レイヤにより処理可能である。
【０２５３】
受信側では、コードワードのうちの１つまたは複数が個別に受信され、それぞれのＣＲＣがチェックされるようになっていてもよい。そして、物理レイヤは、ＴＢ全体が正しく受信される前に、正しく受信された個々のコードワードをＭＡＣに転送するようにしてもよい。これが好都合であるのは、残りのＴＢのコードワードが正しく受信されてＭＡＣに受け渡される前に、ＭＡＣ  ＰＤＵの最初に位置付けられたＭＡＣ  ＣＥ（たとえば、Ｃ−ＲＮＴＩ）をＭＡＣレイヤから抽出可能なためである。ただし、ＴＢに関するすべてのコードワードが正しく受信されていない場合すなわちＴＢの受信に成功していない場合は、ＴＢ全体すなわちＭＡＣ  ＣＥおよびＭＡＣ  ＳＤＵ等の構文解析（前処理）済みの部分も破棄される。
【０２５４】
なお、上記のレイヤ処理は、例示である。本開示は、トランスポートブロックが１つのコードワードに対応し、複数の個々の部分で処理されない他のシステム設計にも適用可能である。
【０２５５】
したがって、受信機は、ＴＴＩの最後を待たなくても、各ＭＡＣ  ＣＥを処理することができる。このため、Ｃ−ＲＮＴＩ  ＭＡＣ  ＣＥ（または、アクティブ化／非アクティブ化ＭＡＣ  ＣＥ等の別のＭＡＣ  ＣＥ）の場合は、準備処理が可能である。
【０２５６】
これにより、データ送信機器および／またはデータ受信機器は、ＭＡＣ  ＳＤＵの前後に位置付けられた両ＭＡＣ  ＣＥを生成し、送信または受信可能であれば都合が良い。なお、一般的に、データ送信機器は、アップリンクにおける端末またはダウンリンクにおける基地局であってもよい。
【０２５７】
本開示の一実施形態において、通信システムにおいてデータを無線チャネル上でデータ受信ノードに送信するデータ送信ノードは、異なる種類の第２レイヤＰＤＵを生成するように構成された第２レイヤ処理ユニットを具備していてもよい。これは特に、少なくとも１つの第２レイヤＳＤＵおよび当該少なくとも１つの第２レイヤＳＤＵのいずれかに後続する少なくとも１つの第２レイヤ制御エレメントを含む第１の種類の第２レイヤＰＤＵを生成するのに適する可能性がある。これはさらに、少なくとも１つの第２レイヤサービスＳＤＵおよび当該少なくとも１つの第２レイヤＳＤＵのいずれかに先行する少なくとも１つの第２レイヤ制御エレメントを含む第２の種類のＰＤＵを生成するように構成可能であってもよい。
【０２５８】
上述の通り、ＭＡＣ  ＰＤＵにおいては、一部のＭＡＣ制御エレメントがＭＡＣ  ＳＤＵの後に配置されるのが好都合である一方、他のＭＡＣ制御エレメントがＭＡＣ  ＳＤＵの前に配置されるのが好都合である。このため、本開示の一実施形態は、タイプ切り替え第２レイヤ制御エレメント（タイプ切り替えＭＡＣ  ＣＥ）を含む第２レイヤＰＤＵを生成して、当該タイプ切り替え第２レイヤ制御エレメントを含む第２レイヤＰＤＵが第１の種類の第２レイヤＳＤＵであるか第２の種類の第２レイヤＳＤＵであるかを示すように構成可能な第２レイヤ処理ユニットを提供する。タイプ切り替え第２レイヤ制御エレメントは、如何なる第２レイヤＳＤＵにも、当該タイプ切り替え第２レイヤ制御エレメントと異なる如何なる第２レイヤ制御エレメントにも先行する。第２レイヤＰＤＵは、タイプ切り替え第２レイヤ制御エレメントと関連付けられ、タイプ切り替え第２レイヤ制御エレメントに先行する第２レイヤサブヘッダをさらに含む。タイプ切り替え第２レイヤ制御エレメントと関連付けられた第２レイヤサブヘッダは、当該タイプ切り替え第２レイヤ制御エレメントに先行する。ただし、この明示的なタイプ切り替えＭＡＣ  ＣＥは、一例に過ぎない。このようなＭＡＣ  ＣＥは、最初または最後にＣＥを有するＭＡＣ  ＰＤＵを生成するかを決定する必要がない。このような決定は、いくつかの所定（固定）ルールに従ってＭＡＣ  ＰＤＵに含まれるＭＡＣ  ＣＥのタイプにのみ基づいてなされるものであってもよい。
【０２５９】
さらに、一般的には、ＭＡＣ  ＰＤＵがＭＡＣ  ＳＤＵの前後に位置付けられた両ＭＡＣ  ＣＥを含み得ることが分かる。また、アップリンクとダウンリンクとが異なっていてもよい。たとえば、ダウンリンクにおいてはＭＡＣ  ＣＥが常に最初に位置付けられる（すなわち、如何なるＳＤＵにも先行する）一方、アップリンクにおいては、ＭＡＣ  ＣＥのタイプによってＳＤＵの前にマッピングされるか後にマッピングされるかが決まるようになっていてもよい。
【０２６０】
一般的に、ダウンリンクにおいて、通信システムにおいてデータを無線チャネル上でデータ受信ノードに送信するデータ送信ノードは、基地局であってもよい。ダウンリンクにおいて、通信システムにおいてデータを無線チャネル上でデータ送信ノードから受信するデータ受信ノードは、ＵＥであってもよい。上述の通り、アップリンクの場合は、データ送信ノードがＵＥであり、データ受信ノードが基地局（ｅＮＢ）であってもよい。
【０２６１】
一般的に、ＵＥおよび／または基地局は、データ送信ノードおよびデータ受信ノードの両者として動作可能であってもよい。特に、ＵＥは、ＣＥがＳＤＵの後に配置されたＭＡＣ  ＰＤＵを生成可能であるほか、ＭＡＣ  ＣＥが最初に配置されたＭＡＣ  ＰＤＵを受信可能であってもよい。同様に、基地局は、ＣＥが最初のＭＡＣ  ＰＤＵを送信可能であるほか、ＣＥが最後のＭＡＣ  ＰＤＵを受信可能であってもよい。ただし、本開示は、このような組み合わせに限定されず、場合によりＭＡＣ  ＣＥのタイプに応じて、ＭＡＣ  ＰＤＵの最後または最初にＭＡＣ  ＣＥを配置することの一方または両方を両方向でサポート可能またはサポートするように構成可能である。なお、一般的には、それぞれのタイプに応じて、ＭＡＣ  ＣＥをＭＡＣ  ＰＤＵの両端に含めることも可能である。
【０２６２】
図２３〜図２７に示す実施形態においては、ＭＡＣサブヘッダがそれぞれ、ＭＡＣ  ＳＤＵまたは関連するＭＡＣ制御エレメントの前に配置されている。このＭＡＣ  ＰＤＵにおけるＭＡＣサブヘッダの配置によれば、ＭＡＣ  ＰＤＵが受信機によって最初から最後に向かう方向（図２３〜図３０において左から右に向かう方向）に構文解析されることを前提として、受信機により可能な限り早くＭＡＣサブヘッダを処理することができる。ただし、場合によっては、ＭＡＣ  ＰＤＵの最後から最初に向かって（図中の右から左に）ＭＡＣ  ＰＤＵの構文解析を始めるのが好都合であることがある。特に、制御エレメントがＭＡＣ  ＰＤＵの最後に利用可能である場合、ＭＡＣ  ＰＤＵが最後から構文解析されるのであれば、受信機で制御エレメントを早期に処理可能である。
【０２６３】
受信機がＭＡＣ  ＰＤＵを最後から（逆方向に）構文解析する場合、ＭＡＣ制御エレメントと関連付けられたＭＡＣサブヘッダは、各制御エレメントの後（言い換えると、構文解析の方向で各制御エレメントの前）に配置されている場合、早期に処理可能である。このようなＭＡＣ制御エレメントと関連付けられたＭＡＣサブヘッダの早期処理を実現するため、本開示の一実施形態は、少なくとも１つの第２レイヤＳＤＵ、少なくとも１つの第２レイヤ制御エレメント、ならびに第２レイヤＳＤＵおよび第２レイヤ制御エレメントそれぞれと関連付けられた第２レイヤサブヘッダを含む第２レイヤＰＤＵを生成する第２レイヤ処理ユニットであって、少なくとも１つの第２レイヤＳＤＵに各関連サブヘッダが先行し、少なくとも１つの第２レイヤ制御エレメントに各関連サブヘッダが後続する、第２レイヤ処理ユニットを含むデータ送信を提供する。
【０２６４】
このような第２レイヤＰＤＵのフォーマットを図２８に示す。特に、この図は、２つのＭＡＣ  ＳＤＵ（ＭＡＣ  ＳＤＵ１およびＭＡＣ  ＳＤＵ２）を含むＭＡＣ  ＰＤＵを示している。ＭＡＣ  ＳＤＵ１およびＭＡＣ  ＳＤＵ２には、それぞれの関連するサブヘッダが直接先行する。図示のＭＡＣ  ＳＤＵの数は、例示に過ぎない。この代替として、ＭＡＣ  ＳＤＵが１つだけ存在していてもよいし、３つ以上のＭＡＣ  ＳＤＵがＭＡＣ  ＰＤＵに含まれていてもよい。ＭＡＣ  ＰＤＵは、各ＭＡＣ  ＳＤＵおよびＭＡＣ  ＳＤＵと関連付けられた各サブヘッダに後続する２つのＭＡＣ制御エレメント（ＭＡＣ  ＣＥ１およびＭＡＣ  ＣＥ２）と、これらのＭＡＣ制御エレメントとそれぞれ関連付けられたＭＡＣサブヘッダとをさらに含む。また、ＭＡＣ  ＰＤＵには、パディングが含まれていてもよい。
【０２６５】
ただし、受信機がＭＡＣ  ＰＤＵの最後から構文解析を開始する場合、パディングがＭＡＣ  ＰＤＵの最後すなわち任意のＭＡＣ制御エレメントの後に配置されていては、ＭＡＣ制御エレメントおよびそれぞれの関連するサブヘッダの処理が遅延する。そこで、パディングを最後に配置する代わりに、関連するサブヘッダを伴うＭＡＣ  ＳＤＵと関連するサブヘッダを伴うＭＡＣ制御エレメントとの間に配置されるようになっていてもよい。このような位置付けも有効なのは、ＰＤＵの最後から構文解析を開始する場合、パディングの長さが一般的には未知であるため、何らかの方法で（たとえば、シグナリング情報により）パディングの長さ情報が得られなければ構文解析を行えないためである。
【０２６６】
このパディングの配置の一例を図２８に示すが、この場合、パディングには、ＭＡＣ  ＳＤＵ２が直接先行し、ＭＡＣ  ＣＥ１が直接後続する。ＭＡＣ  ＣＥ１と関連付けられたサブヘッダがＭＡＣ  ＣＥ１の後に配置され、ＭＡＣ  ＣＥ２と関連付けられたサブヘッダがＭＡＣ  ＣＥ２の後に配置されている。これは、サブヘッダを構文解析方向で各ＭＡＣ  ＣＥに追加することに対応するが、ここでは少なくともすべてのＭＡＣ  ＣＥについて、逆方向すなわちＭＡＣ  ＰＤＵの最後から最初に向かう方向である。なお、ＭＡＣ  ＳＤＵは、ＭＡＣ  ＰＤＵの最初から最後に向かって、通常の方向（順方向）に構文解析されるようになっていてもよい。
【０２６７】
たとえば、２つのＭＡＣ制御エレメントは、ＢＳＲ  ＭＡＣ制御エレメントまたはＰＨＲ  ＭＡＣ制御エレメントであってもよい。本開示は、ＭＡＣ  ＰＤＵが２つのＭＡＣ制御エレメントを有することに限定されない。この代替として、３つ以上のＭＡＣ制御エレメントが存在していてもよいし、１つのＭＡＣ制御エレメントが存在していてもよく、たとえば、ＢＳＲ  ＭＡＣ制御エレメントまたはＰＨＲ  ＭＡＣ制御エレメントであってもよい。
【０２６８】
ＭＡＣ  ＰＤＵを効率的に短時間で構文解析するため、構文解析の初期段階で、ＭＡＣ制御エレメントがＭＡＣ  ＰＤＵにおいて利用可能であるかを受信機が決定できれば有効である。特に、ＭＡＣ  ＣＥがＭＡＣ  ＰＤＵの最後に位置付けられている場合は、このような指定によって、受信機がＭＡＣ  ＰＤＵの最後から後方にＭＡＣ  ＣＥの構文解析を始めるようにしてもよい。別のＭＡＣ制御エレメントの利用可能性に関する情報は、ＭＡＣサブヘッダに含めることができる。
【０２６９】
このため、例示的な一実施形態において、前述の通り第２レイヤＰＤＵを構成する第１の第２レイヤサブヘッダは、第２レイヤＰＤＵが少なくとも１つの第２レイヤ制御エレメントを含むかを示す存在インジケータを含む。
【０２７０】
あるいは、第２レイヤＰＤＵを構成する第２レイヤサブヘッダがすべて、存在インジケータを含んでいてもよい。この解決手段により、ＰＤＵ内のＳＤＵ／ＣＥの位置とは無関係に、サブヘッダのフォーマットを維持することができる。このようにして、現行のＬＴＥ仕様におけるＭＡＣサブヘッダにも準拠する。一方、リソースの利用に関しては、ＭＡＣ  ＰＤＵの最初のサブヘッダにのみ存在インジケータを含める方が効率的と考えられる。
【０２７１】
このような存在インジケータの一例を図２９に示す。図中、図２８に示すＭＡＣ  ＰＤＵフォーマットと類似のＭＡＣ  ＰＤＵフォーマットを示している。したがって、ＭＡＣ  ＰＤＵの最初には、ＭＡＣ  ＳＤＵと関連付けられ、ＭＡＣ  ＳＤＵに先行するＭＡＣサブヘッダが存在し、ＭＡＣ  ＰＤＵの最後には、ＭＡＣ制御エレメントと関連付けられ、ＭＡＣ制御エレメントに後続するＭＡＣサブヘッダが存在する。ＭＡＣ  ＰＤＵの最初のＭＡＣサブヘッダおよび最後のＭＡＣサブヘッダについて、当該ＭＡＣサブヘッダの構造をさらに示す。図２５においてすでに示したように、ＭＡＣサブヘッダは、予約ビット（Ｒ）、Ｆ２ビット、拡張フィールド（Ｅ）、およびＬＣＩＤを含む。Ｒ、Ｆ２、Ｅ、およびＬＣＩＤの構成は、図２５に関して論じた構成と同じである。ＭＡＣ  ＳＤＵと関連付けられた最初のＭＡＣサブヘッダは、ＦフィールドおよびＬフィールドを含む第２のオクテットをさらに含む。このような第２のオクテットは、図示の最後のＭＡＣサブヘッダについては示していない。このサブヘッダは、ＬＣＩＤに基づいてサイズが既知の固定長ＭＡＣ  ＣＥと関連付けられているものと仮定できるが、本実施形態には、サイズ可変の制御エレメントの場合も含み、この場合は、第２のオクテットおよび場合により第３のオクテットをＭＡＣサブヘッダに含める必要がある。ただし、ここでは、ＭＡＣ  ＰＤＵにＭＡＣ制御エレメントが存在するかを示すため、最初の予約ビットを使用している。ここで、ＭＡＣ  ＰＤＵに（少なくとも１つの）ＭＡＣ  ＣＥが存在する場合は、ＭＡＣ  ＰＤＵの最後に配置されるものと仮定する。したがって、存在インジケータの使用により、受信機に対して、逆方向に、すなわちＭＡＣ  ＰＤＵの最後からＭＡＣ  ＣＥ（および、それぞれの各ヘッダ）を構文解析するように指示することができる。これにより、ＭＡＣ  ＰＤＵの最初のＭＡＣサブヘッダおよび／またはすべてのＭＡＣサブヘッダに含まれるＲビットのうちの１つが送信機により設定される。
【０２７２】
たとえば、図２９に示すように、Ｒ＝１は、ＭＡＣ制御エレメントをＭＡＣ  ＰＤＵにおいて利用可能であることを意味し、Ｒ＝０は、ＭＡＣ制御エレメントを利用可能でないことを意味する。図中、ＭＡＣ  ＰＤＵの最初と最後の両ＭＡＣサブヘッダのＲビットをＲ＝１に設定しているが、これは、その他のサブヘッダが同じフォーマットを有し、Ｒフィールドが同様に設定される（Ｒ＝１）ことを仮定している。ただし、本開示は、すべてのＭＡＣサブヘッダのＲビットが１に設定される場合に限定されない。この代替として、たとえば、ＭＡＣ  ＰＤＵがＭＡＣ制御エレメントを含むかを示すのに、最初のＭＡＣサブヘッダのＲビットのみが設定されるようになっていてもよい。言い換えると、Ｒフィールドが最初のサブヘッダすなわち最初に構文解析されるサブヘッダに存在していれば十分である。ただし、すべてのサブヘッダに設定することも可能である。
【０２７３】
図２９においては、ＭＡＣ  ＰＤＵの最後のＭＡＣサブヘッダのＥビットが１に設定された場合を示している。ＭＡＣサブヘッダの構造に関して上述した通り、値Ｅ＝１は、少なくとも１つ以上のＭＡＣサブヘッダが構文解析方向に存在することを示す。構文解析が最後から始まるため、少なくとも１つ以上のＭＡＣサブヘッダは、（図２８のＭＡＣ制御エレメント「ＣＥ１」に対応する）最後のＭＡＣ制御エレメントの前のＭＡＣ制御エレメントと関連付けられたＭＡＣサブヘッダにより識別可能である。したがって、この図においては、最も右にあるＭＡＣサブヘッダが、１に設定されたＥフィールドを有しており、対応するＭＡＣ  ＣＥには、第２のＭＡＣ  ＣＥと関連付けられた第２のサブヘッダが（逆方向の構文解析方向に）後続することを意味する。第２のサブヘッダにおいては、逆方向の構文解析方向にサブヘッダはそれ以上存在せず、（任意選択としての）パディングのみが存在するため、Ｅフィールドが０に設定されている。
【０２７４】
なお、受信機における図２９のＭＡＣ  ＰＤＵの構文解析は、最初のＳＤＵの最初のサブヘッダから始まる。Ｒ＝１であることから、その後の構文解析は、上述の通り、ＭＡＣ  ＰＤＵの最後から後方に続くのが好都合である。ＭＡＣ  ＣＥが抽出された後、ＳＤＵの構文解析は、最初（図の左側）から再開されるようになっていてもよい。ただし、これは、構文解析の有利な一例に過ぎない。また、このＭＡＣ  ＰＤＵフォーマットによれば、ＳＤＵを最初に構文解析した後、ＭＡＣ  ＰＤＵの最後から最初に向かってＭＡＣ  ＣＥを構文解析することも可能である。
【０２７５】
したがって、本開示は、ＭＡＣ制御エレメントが利用可能でない場合は最初から、少なくとも１つのＭＡＣ制御エレメントが利用可能な場合は最後からＭＡＣ  ＰＤＵの構文解析を開始できる受信機も提供する。一実施形態において、データ受信ノードは、第２レイヤＰＤＵを受信して構文解析する第２レイヤ処理ユニットであって、少なくとも１つの第２レイヤ制御エレメントが第２レイヤＰＤＵに含まれることを存在インジケータが示す場合に、第２レイヤＰＤＵの最後から開始して第２レイヤＰＤＵを構文解析する、第２レイヤ処理ユニットを具備する。たとえば、受信機の第２レイヤ処理ユニットは、デフォルトで第２レイヤＰＤＵの最初から構文解析を行うように構成されていてもよい。このため、構文解析を開始したら、最初のサブヘッダの存在インジケータ（現行のＬＴＥ仕様における所定のＲビット等）を評価する。Ｒビットの値がＲ＝１であり、ＭＡＣ制御エレメントがＭＡＣ  ＰＤＵに含まれることを示している場合は、デフォルトの設定から逸脱して、ＭＡＣ  ＰＤＵを最後から構文解析する。なお、予約ビットＲを使用することは、ＭＡＣ  ＰＤＵにＭＡＣ  ＣＥが存在するかを示す存在インジケータを提供するのに有利な選択肢である。ただし、本開示はこれに限定されず、存在インジケータは、たとえばより長いＭＡＣサブヘッダの提供等、別の方法で導入されるようになっていてもよい。前述した通り、本開示は、ＬＴＥにより規定されたサブヘッダのフォーマットに限定されない。
【０２７６】
あるいは、第２レイヤ処理ユニットは、デフォルトでＭＡＣ  ＰＤＵの最後から構文解析を始めるように構成されていてもよい。この場合、構文解析を開始したら、ＭＡＣ  ＰＤＵの最後にＭＡＣサブヘッダを評価する。このサブヘッダのＲビットを評価して、ＭＡＣ  ＰＤＵにＭＡＣ制御エレメントが存在することを示すＲ＝１を検出した場合は、ＭＡＣ  ＰＤＵの構文解析を最後から継続する。
【０２７７】
ＭＡＣ  ＰＤＵが最後から構文解析された場合は、ＭＡＣサブヘッダおよびＭＡＣ制御エレメントの個々のオクテットが両方向に順序付けされるようになっていてもよい。言い換えると、ＭＡＤ  ＰＤＵの構文解析が逆方向である場合は、逆方向に構文解析される個々のＭＡＣサブヘッダおよびＭＡＣ  ＣＥ内のビット順序付けも逆方向であってもよいし、逆方向でなくてもよい。ただし、受信機が個々のＭＡＣサブヘッダおよびＭＡＣ制御エレメントを読み込む方向については、受信機が把握しておく必要がある。
【０２７８】
したがって、一実施形態においては、少なくとも１つの第２レイヤＳＤＵ、少なくとも１つの第２レイヤ制御エレメント、ならびに少なくとも１つの第２レイヤＳＤＵおよび少なくとも１つの第２レイヤ制御エレメントそれぞれと関連付けられたサブヘッダを含む第２レイヤＰＤＵを生成する第２レイヤ処理ユニットであって、少なくとも１つの第２レイヤＳＤＵに各関連サブヘッダが先行し、少なくとも１つの第２レイヤ制御エレメントに各関連サブヘッダが後続する、第２レイヤ処理ユニットを含む送信ノードが開示される。
【０２７９】
図２８および図２９に示すＭＡＣ  ＰＤＵフォーマットは、受信機および送信機の両者と関連する利点を暗示している。受信機は、ＭＡＣ  ＰＤＵを最後から構文解析して、ＭＡＣ  ＣＥ（存在する場合）を高速に処理することができる。
【０２８０】
一方、送信機は、ＭＡＣ  ＣＥがＭＡＣ  ＳＤＵの後に配置されていることから、ＭＡＣ  ＣＥの演算により多くの処理時間を掛けられる。
【０２８１】
本開示の別の例示的な実施形態を図３０に示す。この図は、ＭＡＣ制御エレメントがＭＡＣ  ＳＤＵの後に配置される一方、ＭＡＣ制御エレメントと関連付けられたＭＡＣサブヘッダがＭＡＣ  ＳＤＵの前に配置されたＰＤＵフォーマットを示している。特に、図示のＭＡＣ  ＰＤＵは、２つのＭＡＣ  ＳＤＵ（ＳＤＵ１およびＳＤＵ２）を含み、いずれにも、それぞれの関連するサブヘッダが先行する。さらに、ＭＡＣ  ＰＤＵは、それぞれにＭＡＣサブヘッダが関連付けられた２つのＭＡＣ制御エレメントを含む。ただし、ＭＡＣ制御エレメントと関連付けられたＭＡＣサブヘッダは、関連するＭＡＣ制御エレメントの前に直接配置される代わりに、ＭＡＣ  ＰＤＵの最初において（すべてＭＡＣ  ＰＤＵ内の）ＭＡＣ  ＳＤＵの前に配置されている。言い換えると、ＭＡＣ  ＳＤＵおよびそれぞれに関連するサブヘッダには、ＭＡＣ制御エレメントと関連付けられたＭＡＣサブヘッダが先行する一方、それぞれのＭＡＣ制御エレメント自体が後続する。ＭＡＣ  ＣＥは、任意のＳＤＵおよびそれぞれのヘッダの後で、本例においてはさらに、パディングの後に配置されているためである。図示の例において、ＭＡＣ  ＣＥ１のＭＡＣサブヘッダは、ＣＥ２のＭＡＣサブヘッダに先行し、これは、ＭＡＣ  ＳＤＵ１、ＭＡＣ  ＳＤＵ２、および両ＭＡＣ  ＳＤＵと関連付けられたサブヘッダに先行する。さらに、ＭＡＣ  ＣＥ１のサブヘッダがＭＡＣ  ＣＥ２のサブヘッダに先行するものの、ＭＡＣ制御エレメントＭＡＣ  ＣＥ１は、ＭＡＣ制御エレメントＣＥ２に後続する。これには、受信機での効率的な構文解析という利点がある。構文解析は、ＭＡＣ  ＰＤＵの最初から始まるため、第１のＭＡＣ  ＣＥ１のサブヘッダが読み出される。その後、パーサーは、別の構文解析を待つことなく直ちに、ＭＡＣ  ＰＤＵの最後から対応するＭＡＣ  ＣＥ１を「チョッピング」（抽出）するようにしてもよい。構文解析はその後、第２のＭＡＣ  ＣＥ２に関する次のサブヘッダから継続される。このサブヘッダを構文解析した後、ＭＡＣ  ＰＤＵの最後から第２のＭＡＣ  ＣＥ２がチョッピングされるようになっていてもよい。同様に、３つ以上のＭＡＣ  ＣＥが存在する場合は、ＭＡＣ  ＰＤＵの最初にそれぞれのサブヘッダの順序付けが順次行われる一方、ＭＡＣ  ＣＥ自体は、同じ順序で後方に、ＭＡＣ  ＰＤＵの最後から順序付けされる。
【０２８２】
ただし、本開示は、この特定の順序に限定されない。この代替として、ＭＡＣ制御エレメントと関連付けられたＭＡＣサブヘッダは、関連するＭＡＣ制御エレメントと同じ順序で配置されていてもよい。さらに、本実施形態は、ＭＡＣ  ＰＤＵが２つのＭＡＣ  ＳＤＵおよび２つのＭＡＣ制御エレメントを含むことに限定されない。ＭＡＣ  ＳＤＵおよびＭＡＣ制御エレメントの数は、２つでなくてもよいし、互いに異なっていてもよい。ＴＢにいくつかのリソースが残っている場合は、任意選択としてパディングがＭＡＣ  ＰＤＵに含まれる。図中、パディングがＭＡＣ  ＳＤＵとＭＡＣ制御エレメントとの間に配置されており、これによって、パディング長を把握する必要なく、ＭＡＣ  ＰＤＵの両側から構文解析を行える。
【０２８３】
なお、本開示の利点は、ＭＡＣ  ＰＤＵの構成によりもたらされる。受信機は、ＭＡＣ  ＰＤＵを構文解析して、ＣＥおよびＳＤＵを取得できる必要がある。構文解析の実行方法は、本開示に限定されない。たとえば、図３０の実施形態においても、受信機は、ＭＡＣ  ＰＤＵを最初から最後まで（図の左から右まで）構文解析するのみであってもよい。それにも関わらず、受信機がＭＡＣ  ＣＥを最初に構文解析した後、ＭＡＣ  ＰＤＵの残りの部分（ＳＤＵ、パディング）を構文解析可能な場合は、別の利点が実現され得る。
【０２８４】
さらに、図３０の実施形態では、如何なる存在インジケータも不要である。ＭＡＣ  ＣＥのヘッダがＭＡＣ  ＰＤＵの最初に順序付けされることから、特定の対応するサブヘッダの存在によって、ＭＡＣ  ＣＥの存在が示されるためである。
【０２８５】
言い換えると、一実施形態によれば、少なくとも１つの第２レイヤ制御エレメントのいずれかと関連付けられた各第２レイヤサブヘッダは、各第２レイヤＳＤＵおよび各第２レイヤＳＤＵと関連付けられた各サブヘッダに先行する。一方で、第２レイヤ制御エレメントは、任意の第２レイヤＳＤＵの後に位置付けられるのが好都合である。
【０２８６】
このため、第２レイヤＰＤＵの最初から、第２レイヤ制御エレメントと関連付けられたサブヘッダを構文解析するとともに、第２レイヤＰＤＵから、第２レイヤＳＤＵの後に配置された上記第２レイヤ制御エレメントを抽出するように第２レイヤ処理ユニットが構成された受信機が提供されるようになっていてもよい。
【０２８７】
サブヘッダにおいて、ＬＣＩＤは、サブヘッダがＭＡＣ  ＣＥに属するかＭＡＣ  ＳＤＵに属するかを示す。図３０に示すＰＤＵ構造の電気通信システムにおいて、受信機は、ＭＡＣ  ＰＤＵを最初から構文解析する。サブヘッダがＭＡＣ  ＣＥに属する場合、受信機は、ＭＡＣ  ＰＤＵの最後からＭＡＣ  ＣＥを読み出す。サブヘッダがＭＡＣ  ＳＤＵに属する場合、受信機は、ＳＤＵの処理をＭＡＣ  ＰＤＵの最初か始める。
【０２８８】
送信側に関する本実施形態の利点として、ＭＡＣ  ＣＥがＭＡＣ  ＳＤＵの後に配置されていることから、ＭＡＣ  ＣＥの演算により多くの処理時間を掛けられる。また、ＴＢの構成が完了する前に、利用可能なＭＡＣ  ＳＤＵを物理レイヤ処理に配送済みとすることができる。受信側に関する利点として、関連するＭＡＣヘッダがＴＢの最初に配置されていることから、ＭＡＣ  ＣＥを高速に処理可能である。ＵＥがＢＳＲの存在を把握するのは、ＬＣＰが終了となった後のみであるため、ＢＳＲ  ＭＡＣ  ＣＥのＭＡＣサブヘッダは、任意のＭＡＣ  ＳＤＵの後に配置されるのが好都合である。
【０２８９】
図３０に示すように、ＭＡＣ  ＣＥは、ＭＡＣ  ＰＤＵの最後に位置付け可能である。ただし、パディングＣＥがＭＡＣ  ＰＤＵに挿入される場合には、必ずしも当てはまらない。一実施形態によれば、第２レイヤＰＤＵは、パディングバッファステータスレポート（ＢＳＲ）およびパディングＢＳＲと関連付けられた第２レイヤサブヘッダを含み、パディングＢＳＲおよび当該パディングＢＳＲと関連付けられた第２レイヤサブヘッダは、少なくとも１つの第２レイヤＳＤＵのいずれかの後に配置される。
【０２９０】
特に、ＬＴＥにおいてはすでに、いわゆるパディングＢＳＲをＭＡＣ  ＰＤＵに挿入可能である。パディングＢＳＲは、周期的ではないため一般的にはＭＡＣ  ＰＤＵに含める必要のないＢＳＲまたは規則的もしくはトリガー後にＭＡＣ  ＰＤＵに含まれるトリガーＢＳＲである。ただし、ＭＡＣ  ＰＤＵが組み立てられた後も、このＭＡＣ  ＰＤＵに割り当てられたリソースの一部が自由であり、ＢＳＲを収容するのに十分な大きさである場合は、「パディングＢＳＲ」がＭＡＣ  ＰＤＵに挿入される。このようなパディングＢＳＲは、非パディングＢＳＲのＬＣＩＤと異なるＬＣＩＤを有していてもよく、特に、たとえば非特許文献７の表６．２．１−２における異なる種類のＢＳＲに対して指定されたＬＣＩＤ値と異なっていてもよい。このため、パディングＢＳＲがＭＡＣ  ＰＤＵに含まれる場合、図３０においては、そのサブヘッダとともにＭＡＣ  ＣＥ１の後すなわちＭＡＣ  ＰＤＵの最後に含まれることになる。
【０２９１】
さらに、図３２に示すように、通信システムにおいてデータを無線チャネル上でデータ受信ノードに送信する方法であって、第３のレイヤから、データ送信用に割り当てられたリソースにマッピングされる少なくとも１つの第２レイヤサービスデータユニット（ＳＤＵ）を受信するステップ３２２１ｔと、少なくとも１つの第２レイヤＳＤＵおよび当該少なくとも１つの第２レイヤＳＤＵのいずれかの後に配置された少なくとも１つの第２レイヤ制御エレメントを含む第２レイヤプロトコルデータユニット（ＰＤＵ）を生成するステップ３２２２ｔと、第２レイヤ処理により生成された第２レイヤＰＤＵを受信するステップ３２１１ｔと、データ送信用に割り当てられたリソースに第２レイヤＰＤＵをマッピングするステップ３２１２ｔと、を含む、方法が開示される。
【０２９２】
また、通信システムにおいてデータを無線チャネル上でデータ受信ノードに送信する方法であって、第２レイヤＰＤＵに含まれる第２レイヤ制御エレメントのタイプを決定するステップと、含まれる第２レイヤ制御エレメントのタイプに応じて、第１の種類の第２レイヤＰＤＵまたは第２の種類の第２レイヤＰＤＵを生成するステップと、をさらに含む、方法が開示される。この方法において、第１の種類の第２レイヤＰＤＵは、少なくとも１つの第２レイヤＳＤＵおよび当該少なくとも１つの第２レイヤＳＤＵのいずれかの後に配置された少なくとも１つの第２レイヤ制御エレメントを含み、第２の種類のＰＤＵは、少なくとも１つの第２レイヤＳＤＵおよび当該少なくとも１つの第２レイヤＳＤＵのいずれかに先行する少なくとも１つの第２レイヤ制御エレメントを含む。
【０２９３】
また、通信システムにおいてデータを無線チャネル上でデータ受信ノードに送信する方法であって、第２レイヤＰＤＵの一部を構成するパッケージを生成するステップと、第２レイヤＰＤＵの一部を構成するパッケージを第１レイヤ処理ユニットに転送するステップとが交互に繰り返し適用される、方法が開示される。これにより、第２レイヤＰＤＵの一部を構成するパッケージは、第２レイヤＰＤＵの生成が完了する前に、第１レイヤ処理ユニットに転送される。このようなパッケージは、それぞれのサブヘッダおよび／または関連するヘッダを有する各ＭＡＣ  ＣＥを伴う単一のＳＤＵであってもよいし、複数のＳＤＵであってもよい。
【０２９４】
また、図３２に示すように、通信システムにおいてデータを無線チャネル上でデータ送信ノードから受信する方法であって、データ受信用に割り当てられたリソースから、少なくとも１つの第２レイヤプロトコルデータユニット（ＰＤＵ）をデマッピングするステップ３２１１ｒと、第１レイヤ処理ユニットによりデマッピングされた第２レイヤＰＤＵを受信するステップ３２２１ｒおよび構文解析するステップ３２２２ｒであり、第２レイヤＰＤＵが、少なくとも１つの第２レイヤサービスデータユニット（ＳＤＵ）および当該少なくとも１つの第２レイヤＳＤＵのいずれかに後続する少なくとも１つの第２レイヤ制御エレメントを含む、第２レイヤＰＤＵを受信するステップ３２２１ｒおよび構文解析するステップ３２２２ｒと、を含む、方法が開示される。
【０２９５】
本開示の一実施形態において、データを受信する方法は、第２レイヤＰＤＵの最初から（すなわち、早く受信した部分から遅く受信した部分に向かって）第２レイヤＰＤＵを構文解析するステップを含む。
【０２９６】
別の実施形態において、データを受信する方法は、第２レイヤＣＥと関連付けられた各サブヘッダおよび各第２レイヤＣＥが処理されるまで第２レイヤＰＤＵの最後から第２レイヤＰＤＵを構文解析するステップと、第２レイヤＣＥおよび第２レイヤＣＥと関連付けられた各サブヘッダの処理の後、第２レイヤＰＤＵの残りの部分を最初から構文解析することにより、第２レイヤＳＤＵおよび当該第２レイヤＳＤＵと関連付けられた第２レイヤ制御エレメントを処理するステップと、を含む。この方法の利点として、第２レイヤＰＤＵが図２８および図２９に示すフォーマットを有する場合に、第２レイヤ制御エレメントがより高速に処理される。この場合、第２レイヤＣＥおよび第２レイヤＣＥと関連付けられたサブヘッダは、少なくとも１つの第２レイヤＳＤＵのいずれかの後に配置され、第２レイヤＣＥおよび第２レイヤＣＥと関連付けられたサブヘッダの後にはパディングが配置されていない。
【０２９７】
たとえば、第１または任意の第２レイヤサブヘッダが、第２レイヤＰＤＵが少なくとも１つの第２レイヤ制御エレメントを含むかを示す存在インジケータを含む場合、データを受信する方法は、第２レイヤＰＤＵの最後から開始して第２レイヤＰＤＵを構文解析するステップを含んでいてもよい。このような存在インジケータの一例は、図２９のＭＡＣ  ＰＤＵの最初のＭＡＣ  ＳＤＵと関連付けられたＭＡＣサブヘッダ中のＲビットである。したがって、このＲビットを評価した後、Ｒ＝１の場合は、第２レイヤＰＤＵの最後から開始して第２レイヤＰＤＵを構文解析するステップに従って、ＭＡＣ制御エレメントおよびＭＡＣ制御エレメントと関連付けられたＭＡＣサブヘッダを評価する。
【０２９８】
あるいは、例示的な一実施形態において、データを受信する方法は、第２レイヤＰＤＵの最初から、第２レイヤ制御エレメントと関連付けられたサブヘッダを構文解析するとともに、第２レイヤＰＤＵから、第２レイヤＳＤＵの後に配置された上記第２レイヤ制御エレメントを抽出するステップを含む。たとえば、この方法は、図３０に示すフォーマットを有する第２レイヤＰＤＵに適用可能である。第２レイヤＰＤＵの最初から、第２レイヤ制御エレメントと関連付けられた第２レイヤサブヘッダを構文解析するとともに、各第２レイヤ制御エレメントを抽出（「チョッピング」）するステップは、すべての第２レイヤ制御エレメントが抽出されるまで交互に行われるようになっていてもよい。その後、第２レイヤＰＤＵの残りの部分を最初から構文解析するステップに従って、少なくとも１つの第２レイヤＳＤＵおよび当該少なくとも１つの第２レイヤＳＤＵと関連付けられた１つまたは複数の第２レイヤサブヘッダを構文解析するようにしてもよい。
【０２９９】
＜本開示のハードウェアおよびソフトウェア実装＞
他の例示的な実施形態は、ハードウェアおよびソフトウェアの使用による上述の種々実施形態の実装に関する。これに関連して、ユーザ端末（移動端末）およびｅＮｏｄｅＢ（基地局）が提供される。ユーザ端末および基地局は、本明細書に記載の方法を実行するように構成されており、受信機、送信機、プロセッサ等の対応するエンティティがこれらの方法に適宜関与する。
【０３００】
コンピュータ機器（プロセッサ）を用いて種々実施形態が実装または実行され得ることもさらに認識される。コンピュータ機器またはプロセッサは、たとえば汎用プロセッサ、デジタルシグナルプロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、または他のプログラム可能な論理デバイス等であってもよい。これらには、データ入出力が結合されていてもよい。また、種々実施形態は、これらのデバイスの組み合わせによって実行または具現化されていてもよい。
【０３０１】
さらに、種々実施形態は、プロセッサによる実行またはハードウェアにおける直接的な実行が行われるソフトウェアモジュールによって実装されていてもよい。また、ソフトウェアモジュールおよびハードウェア実装の組み合わせも可能と考えられる。ソフトウェアモジュールは、たとえばＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、レジスタ、ハードディスク、ＣＤ−ＲＯＭ、ＤＶＤ等、如何なる種類のコンピュータ可読記憶媒体に格納されていてもよい。
【０３０２】
さまざまな実施形態の個々の特徴は、個別または任意の組み合わせにより、別の実施形態の主題であってもよいことにさらに留意するものとする。
【０３０３】
当業者には当然のことながら、特定の実施形態に示すように、本開示の多くの変形および／または改良が可能である。したがって、本実施形態は、あらゆる点で例示に過ぎず、何ら限定的なものではないと考えるべきである。
【０３０４】
以上をまとめて、本開示は、通信システムの受信機および送信機におけるレイヤ処理に関する。このレイヤ処理には、第１、第２、および第３のレイヤ上の処理を少なくとも含む。送信側において、第３のレイヤは、パケットを受信し、そのヘッダを追加して、パケットを第２のレイヤに転送する。第２のレイヤは、分割を実行して、その分割データを第１のレイヤに提供する。第１のレイヤは、分割データを物理リソースにマッピングする。分割は、割り当てられたリソースに基づく。第３のレイヤ上では、再送信が発生するようになっていてもよく、このため、第３のレイヤは、特定のセグメントに対して、受信したフィードバックに従ってパケットを再分割するとともに、再分割データを下位レイヤに提供するようにしてもよい。あるいは、フィードバック情報が第２のレイヤに提供され、これを考慮して第２のレイヤが分割を実行する。これに対応して、受信機は、第２のレイヤから制御情報も受信する第３のレイヤにおいて、並べ替えおよび再組み立てを実行する。
【０３０５】
さらに、本開示は、通信システムにおいてデータを無線チャネル上でデータ送信ノードからデータ受信ノードに送信するシステムおよび方法に関する。特に、データ送信ノードは、第３のレイヤから、データ送信用に割り当てられたリソースにマッピングされる少なくとも１つの第２レイヤサービスデータユニット（ＳＤＵ）を受信するとともに、少なくとも１つの第２レイヤＳＤＵおよび当該少なくとも１つの第２レイヤＳＤＵのいずれかの後に配置された少なくとも１つの第２レイヤ制御エレメントを含む第２レイヤプロトコルデータユニット（ＰＤＵ）を生成する第２レイヤ処理ユニットと、第２レイヤ処理ユニットにより生成された第２レイヤＰＤＵを受信するとともに、データ送信用に割り当てられたリソースに第２レイヤＰＤＵをマッピングする第１レイヤ処理ユニットと、を備える。データ受信ノードは、データ受信用に割り当てられたリソースから、少なくとも１つの第２レイヤプロトコルデータユニット（ＰＤＵ）をデマッピングする第１レイヤ処理ユニットと、第１レイヤ処理ユニットによりデマッピングされた第２レイヤＰＤＵを受信して構文解析する第２レイヤ処理ユニットであり、第２レイヤＰＤＵが、少なくとも１つの第２レイヤサービスデータユニット（ＳＤＵ）および当該少なくとも１つの第２レイヤＳＤＵのいずれかに後続する少なくとも１つの第２レイヤ制御エレメントを含む、第２レイヤ処理ユニットと、を備える。
【図１】
2019533377.tif 000010
【図２】
2019533377.tif 000011
【図３Ａ】
2019533377.tif 000012
【図３Ｂ】
2019533377.tif 000013
【図４】
2019533377.tif 000014
【図５Ａ】
2019533377.tif 000015
【図５Ｂ】
2019533377.tif 000016
【図６】
2019533377.tif 000017
【図７】
2019533377.tif 000018
【図８】
2019533377.tif 000019
【図９】
2019533377.tif 000020
【図１０】
2019533377.tif 000021
【図１１Ａ】
2019533377.tif 000022
【図１１Ｂ】
2019533377.tif 000023
【図１２】
2019533377.tif 000024
【図１３】
2019533377.tif 000025
【図１４】
2019533377.tif 000026
【図１５】
2019533377.tif 000027
【図１６】
2019533377.tif 000028
【図１７】
2019533377.tif 000029
【図１８】
2019533377.tif 000030
【図１９】
2019533377.tif 000031
【図２０】
2019533377.tif 000032
【図２１】
2019533377.tif 000033
【図２２】
2019533377.tif 000034
【図２３】
2019533377.tif 000035
【図２４】
2019533377.tif 000036
【図２５】
2019533377.tif 000037
【図２６】
2019533377.tif 000038
【図２７】
2019533377.tif 000039
【図２８】
2019533377.tif 000040
【図２９】
2019533377.tif 000041
【図３０】
2019533377.tif 000042
【図３１】
2019533377.tif 000043
【図３２】
2019533377.tif 000044
【図３３】
2019533377.tif 000045
【国際調査報告】
2019533377.tif 000046
2019533377.tif 000047