JP6959331B2 - データ送信ノード、データ受信ノード、データ受信ノードにデータを送信するための方法、および、データ送信ノードからデータを受信するための方法 - Google Patents

Description

本開示は、通信システムにおける複数のレイヤ上での送受信処理、ならびに対応する伝送装置、方法、およびプログラムに関する。

ＷＣＤＭＡ（登録商標）無線アクセス技術に基づく第３世代モバイルシステム（３Ｇ）は世界中で広範に展開されている。この技術を拡張または発展させる第１段階は、競争力の高い無線アクセス技術を与える、高速下りパケットアクセス（ＨＳＤＰＡ：Ｈｉｇｈ−Ｓｐｅｅｄ Ｄｏｗｎｌｉｎｋ Ｐａｃｋｅｔ Ａｃｃｅｓｓ）および高速上りパケットアクセス（ＨＳＵＰＡ：Ｈｉｇｈ Ｓｐｅｅｄ Ｕｐｌｉｎｋ Ｐａｃｋｅｔ Ａｃｃｅｓｓ）とも呼ばれる拡張された上りリンクを導入することを伴う。３ＧＰＰは、ユーザ要求のさらなる増大と新しい無線アクセス技術との競争に備えて、ロング・ターム・エボリューション（ＬＴＥ：Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）と呼ばれる新しい移動通信システムを導入した。ＬＴＥは、高速データおよびメディア伝送、ならびに大容量音声サポートに対するキャリアニーズを、今後１０年間にわたって満たすように設計されている。高いビットレートを提供する能力は、ＬＴＥにとって重要な尺度である。進化型ＵＭＴＳ地上無線アクセス（ＵＴＲＡ：ＵＭＴＳ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ）およびＵＭＴＳ地上無線アクセスネットワーク（ＵＴＲＡＮ：ＵＭＴＳ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）と呼ばれるロング・ターム・エボリューション（ＬＴＥ）に関する作業項目（ＷＩ：ｗｏｒｋ ｉｔｅｍ）仕様がリリース８（Ｒｅｌ．８ ＬＴＥ）として最終決定されている。ＬＴＥシステムは、低待ち時間および低コストで完全なＩＰベースの機能を提供する効率的なパケットベースの無線アクセスおよび無線アクセスネットワークを表す。ＬＴＥでは、所与のスペクトルを使用して柔軟なシステム展開を達成するために、１．４、３．０、５．０、１０．０、１５．０、および２０．０ＭＨｚなどのスケーラブルな複数の伝送帯域幅が指定される。下りリンクでは、シンボルレートが低いためにマルチパス干渉（ＭＰＩ：ｍｕｌｔｉｐａｔｈ ｉｎｔｅｒｆｅｒｅｎｃｅ）に対して固有の耐性があり、サイクリックプレフィックス（ＣＰ：ｃｙｃｌｉｃ ｐｒｅｆｉｘ）を使用し、異なる伝送帯域幅構成に対して親和性があるために、直交周波数分割多重化（ＯＦＤＭ：Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘｉｎｇ）ベースの無線アクセスが採用された。上りリンクでは、ユーザ機器（ＵＥ：ｕｓｅｒ ｅｑｕｉｐｍｅｎｔ）の送信電力に制限があることを考慮するとピークデータ転送速度の改善よりも広域カバレッジの提供が優先されるため、シングルキャリア周波数分割多元接続（ＳＣ‐ＦＤＭＡ：Ｓｉｎｇｌｅ‐ｃａｒｒｉｅｒ ｆｒｅｑｕｅｎｃｙ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ）ベースの無線アクセスが採用された。Ｒｅｌ．８ ＬＴＥでは、多入力多出力（ＭＩＭＯ：ｍｕｌｔｉｐｌｅ−ｉｎｐｕｔ ｍｕｌｔｉｐｌｅ−ｏｕｔｐｕｔ）チャネル伝送技術を含む多くの重要なパケット無線アクセス技術が用いられ、非常に効率的な制御シグナリング構造が達成される。

ＬＴＥアーキテクチャ
図１に全体的なアーキテクチャを示し、図２にＥ‐ＵＴＲＡＮアーキテクチャのより詳細な図を示す。Ｅ‐ＵＴＲＡＮはｅＮＢからなり、ＵＥにＥ‐ＵＴＲＡユーザプレーン（ＰＤＣＰ／ＲＬＣ／ＭＡＣ／ＰＨＹ）および制御プレーン（ＲＲＣ）のプロトコル終端を提供する。ｅＮＢは、ユーザプレーンのヘッダ圧縮および暗号化の機能を含む物理（ＰＨＹ：Ｐｈｙｓｉｃａｌ）層、媒体アクセス制御（ＭＡＣ：Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）層、無線リンク制御（ＲＬＣ：Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ）層、およびパケットデータ制御プロトコル（ＰＤＣＰ：Ｐａｃｋｅｔ ｄａｔａ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）層をホストする。ｅＮＢはまた、制御プレーンに対応する無線リソース制御（ＲＲＣ：Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）機能も提供する。ｅＮＢは、無線リソース管理、アドミッション制御、スケジューリング、折衝されたＵＬ ＱｏＳの実施、セル情報ブロードキャスト、ユーザプレーンおよび制御プレーンデータの暗号化／解読、ＤＬ／ＵＬユーザ・プレーン・パケット・ヘッダの圧縮／解凍を含む多くの機能を果たす。ｅＮＢは、Ｘ２インターフェースを使用して相互接続される。ｅＮＢはまた、Ｓ１インターフェースによってＥＰＣ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｃｏｒｅ（進化型パケットコア））に、より具体的には、Ｓ１‐ＭＭＥによってＭＭＥ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ（モビリティ管理エンティティ））と、Ｓ１‐Ｕを介してサービングゲートウェイ（Ｓ‐ＧＷ）とに接続される。Ｓ１インターフェースは、ＭＭＥ／サービングゲートウェイとｅＮＢとの間の多対多の関係をサポートする。ＳＧＷは、ユーザ・データ・パケットをルーティング、転送すると同時に、ｅＮＢ間のハンドオーバ中のユーザプレーンのモビリティアンカとして働き、ＬＴＥと他の３ＧＰＰ技術との間のモビリティのためのアンカとしても働く（Ｓ４インターフェースを終端し、２Ｇ／３ＧシステムとＰＤＮ ＧＷとの間でトラフィックを中継する）。アイドル状態のＵＥでは、ＳＧＷは、ＤＬデータパスを終端し、ＵＥにＤＬデータが到着するとページングをトリガする。ＳＧＷは、ＵＥコンテキスト、例えば、ＩＰベアラサービスのパラメータ、ネットワーク内部ルーティング情報を管理し、格納する。ＳＧＷはまた、合法的傍受の場合にユーザトラフィックの複製を行う。

ＭＭＥは、ＬＴＥアクセスネットワークの主要な制御ノードである。ＭＭＥは、再送信を含むアイドルモードＵＥの追跡およびページング手順を担当する。ＭＭＥは、ベアラアクティブ化／非アクティブ化プロセスに関与し、初期接続時と、コアネットワーク（ＣＮ：Ｃｏｒｅ Ｎｅｔｗｏｒｋ）ノードの再配置を伴うＬＴＥ内ハンドオーバ時にＵＥにＳＧＷを選択する役割も担う。ＭＭＥはまた、（ＨＳＳと対話することによって）ユーザを認証する役割も担う。非アクセス層（ＮＡＳ：Ｎｏｎ−Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）シグナリングはＭＭＥで終端し、ＭＭＥは一時的な識別の生成およびＵＥへの割当も担当する。ＭＭＥは、サービスプロバイダの公衆陸上移動網（ＰＬＭＮ：Ｐｕｂｌｉｃ Ｌａｎｄ Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋ）にキャンプオンするＵＥの権限をチェックし、ＵＥのローミング制限を実施する。ＭＭＥは、ＮＡＳシグナリングの暗号化／完全性保護のためのネットワークにおける終端点であり、セキュリティキー管理を処理する。シグナリングの合法的傍受もＭＭＥによってサポートされる。ＭＭＥはまた、ＳＧＳＮからのＭＭＥで終端するＳ３インターフェースを用いたＬＴＥと２Ｇ／３Ｇアクセスネットワークとの間のモビリティのための制御プレーン機能も提供する。ＭＭＥはまた、ローミングＵＥのためにホームＨＳＳに対してＳ６ａインターフェースを終了する。

３ＧＰＰ ＬＴＥシステムの下りコンポーネントキャリアは、いわゆるサブフレーム単位で時間・周波数領域で細分される。３ＧＰＰ ＬＴＥでは、各サブフレームは２つの下りスロットに分割され、第１の下りスロットは第１のＯＦＤＭシンボル内の制御チャネル領域（ＰＤＣＣＨ領域）を含む。各サブフレームは、時間領域における所与の数のＯＦＤＭシンボル（３ＧＰＰ ＬＴＥ（リリース８）では１２または１４個のＯＦＤＭシンボル）からなり、各ＯＦＤＭシンボルはコンポーネントキャリアの全帯域幅に及ぶ。よって、ＯＦＤＭシンボルは各々、それぞれのサブキャリア上で伝送されるいくつかの変調シンボルからなる。

例えば３ＧＰＰロング・ターム・エボリューション（ＬＴＥ）で使用されるように、例えばＯＦＤＭを用いたマルチキャリア通信システムを想定すると、スケジューラが割り当てられることのできるリソースの最小単位は、１つの「リソースブロック」である。物理リソースブロック（ＰＲＢ）は、時間領域における連続したＯＦＤＭシンボル（例えば、７個のＯＦＤＭシンボル）および周波数領域における連続したサブキャリア（例えば、１つのコンポーネントキャリアに１２個のサブキャリア）として定義される。３ＧＰＰ ＬＴＥ（リリース８）では、物理リソースブロックはよって、時間領域で１つのスロット、周波数領域で１８０ｋＨｚに対応するリソースエレメントからなる（下りリソースグリッドのさらなる詳細については、例えば、参照により本明細書に組み込まれる、ｈｔｔｐ：／／ｗｗｗ．３ｇｐｐ．ｏｒｇで入手可能な非特許文献１、セクション６．２を参照）。

１つのサブフレームは２つのスロットからなり、いわゆる「通常の」ＣＰ（サイクリックプレフィックス）が使用される場合は１つのサブフレームに１４個のＯＦＤＭシンボルがあり、いわゆる「拡張」ＣＰが使用される場合は１つのサブフレームに１２個のＯＦＤＭシンボルがある。用語の説明のため、以下では、完全なサブフレームに及ぶ同じ連続したサブキャリアに相当する時間・周波数リソースを「リソースブロック対」、または対応する「ＲＢ対」または「ＰＲＢ対」と呼ぶ。

「コンポーネントキャリア」という用語は、周波数領域におけるいくつかのリソースブロックの組み合わせを指す。ＬＴＥの将来のリリースでは、「コンポーネントキャリア」という用語は使用されなくなり、代わりに、この用語が「セル」に変更され、「セル」は、下りリソースと任意選択で上りリソースとの組み合わせを指す。下りリソースのキャリア周波数と上りリソースのキャリア周波数との間のリンクは、下りリソース上で伝送されるシステム情報で示される。コンポーネントキャリア構造についての同様の想定が、後のリリースにも当てはまる。

［ＯＳＩ階層の概要］
図３Ａに、ＬＴＥアーキテクチャのさらなる考察の基礎となる階層モデルの簡単な概要を示す。

開放型システム間相互接続参照モデル（ＯＳＩ（Ｏｐｅｎ Ｓｙｓｔｅｍｓ Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ）モデルまたはＯＳＩ参照モデル）は、通信およびコンピュータ・ネットワーク・プロトコル設計のための階層化された抽象的記述である。ＯＳＩモデルは、システムの機能を一連のレイヤに分割する。各レイヤには、下位のレイヤの機能のみを使用し、上位のレイヤにのみ機能をエクスポートするという特性がある。これら一連のレイヤからなるプロトコル挙動を実装するシステムは、「プロトコルスタック」または「スタック」として知られている。その主な特徴は、あるレイヤが別のレイヤとどのように相互作用するかについての仕様を規定するレイヤ間の結合にある。すなわち、ある製造者によって作成されたレイヤが別の製造者のレイヤからと共に動作することができる。本開示の目的のために、最初の３つのレイヤについてのみ以下でさらに詳細に説明する。

物理層またはレイヤ１の主な目的は、特定の物理媒体（同軸ケーブル、ツイストペア、光ファイバ、無線インターフェースなど）上での情報（ビット）の転送である。物理層は、データを通信チャネル上で伝送される信号（またはシンボル）に変換または変調する。

データリンク層（またはレイヤ２）の目的は、入力データをデータフレームに分割することによって特定の物理層と互換性を有するように情報フローを形成することである（セグメント化および再組立て（Ｓｅｇｍｅｎｔａｔｉｏｎ Ａｎｄ Ｒｅ‐ａｓｓｅｍｂｌｙ）（ＳＡＲ）機能）。さらに、データリンク層は、失われたフレームの再送信を要求することによって、潜在的な伝送誤りを検出、修正しうる。データリンク層は通常、アドレス指定機構を提供し、そしてデータ転送速度を受信側容量と整合させるためにフロー制御アルゴリズムを提供しうる。共有媒体が複数の送信側と受信側とによって同時に使用される場合、データリンク層は通常、物理媒体へのアクセスを規制、制御する機構を提供する。

データリンク層によって提供される機能は多数あるので、データリンク層はしばしばサブレイヤ（例えばＵＭＴＳではＲＬＣ層とＭＡＣ層）に細分される。レイヤ２プロトコルの典型的な例が、固定回線ネットワーク用のＰＰＰ／ＨＤＬＣ、ＡＴＭ、フレームリレー、および無線システム用のＲＬＣ、ＬＬＣ、またはＭＡＣである。レイヤ２のサブレイヤＰＤＣＰ、ＲＬＣおよびＭＡＣに関するより詳細な情報については後述する。本出願では、サブレイヤを「レイヤ」とも呼び、よって本出願で用いる「レイヤ」という用語は必ずしもＯＳＩモデルのレイヤを意味しないことに留意されたい。

ネットワーク層またはレイヤ３は、トランスポート層によって要求されるサービス品質を維持しながら、１つまたは複数のネットワークを介して送信元から宛先へ可変長パケットを転送するための機能的、手順的手段を提供する。通常、ネットワーク層の主な目的は、とりわけネットワークルーティング、ネットワークフラグメンテーション、および輻輳制御の機能を果たすことである。ネットワーク層プロトコルの主な例は、ＩＰインターネットプロトコルまたはＸ．２５である。

レイヤ４からレイヤ７に関しては、アプリケーションおよびサービスによっては、レイヤ３より上位で動作するアプリケーションおよびサービスがしばしば、ＯＳＩモデルの様々なレイヤに帰されるべき様々な機能を実装するため、アプリケーションまたはサービスをＯＳＩモデルの特定のレイヤに帰することが難しい場合があることに留意されたい。したがって、特にＴＣＰ（ＵＤＰ）／ＩＰベースのネットワークでは、場合によっては、レイヤ４以上が組み合わされていわゆる「アプリケーション層」を形成する。

［レイヤサービスおよびデータ交換］
以下では、本明細書で使用されるサービス・データ・ユニット（ＳＤＵ：ｓｅｒｖｉｃｅ ｄａｔａ ｕｎｉｔ）およびプロトコル・データ・ユニット（ＰＤＵ：ｐｒｏｔｏｃｏｌ ｄａｔａ ｕｎｉｔ）という用語を、図３Ｂとの関連で定義する。ＯＳＩモデルにおけるレイヤ間のパケット交換を一般的に形式的に説明するために、ＳＤＵエンティティおよびＰＤＵエンティティが導入された。ＳＤＵは、いわゆるサービス・アクセス・ポイント（ＳＡＰ：ｓｅｒｖｉｃｅ ａｃｃｅｓｓ ｐｏｉｎｔ）を介してレイヤＮに位置するプロトコルにサービスを要求するレイヤＮ＋１のプロトコルから送信される情報の単位（データ／情報ブロック）である。ＰＤＵは、同じレイヤＮに位置する同じプロトコルの送信側と受信側とのピアプロセス間で交換される情報の単位である。

ＰＤＵは、一般に、レイヤＮ固有のヘッダによって先行され、任意選択でトレーラによって終端される（１つまたは複数の）受信ＳＤＵの処理済みバージョンからなるペイロード部によって形成される。（レイヤ１を除いて）これらのピアプロセス間には直接の物理接続がないため、ＰＤＵは処理のためにレイヤＮ−１に転送される。したがって、レイヤＮのＰＤＵは、レイヤＮ−１の観点からは、ＳＤＵである。

［ＬＴＥユーザプレーン（Ｕ‐Ｐｌａｎｅ、ＵＰ）および制御プレーン（Ｃ‐Ｐｌａｎｅ、ＣＰ）プロトコル：］
ＬＴＥレイヤ２ユーザプレーン／制御プレーン・プロトコル・スタックは、３つのサブレイヤ、ＰＤＣＰ、ＲＬＣ、およびＭＡＣを含む。

前述したように、送信側では、各レイヤは、そのレイヤがサービスを提供する上位層からＳＤＵを受信し、下位の層にＰＤＵを出力する。ＲＬＣ層はＰＤＣＰ層からパケットを受信する。これらのパケットは、ＰＤＣＰの観点からはＰＤＣＰ ＰＤＵと呼ばれ、ＲＬＣの観点からはＲＬＣ ＳＤＵを表す。ＲＬＣ層は、下位のレイヤ、すなわちＭＡＣ層に提供されるパケットを作成する。ＲＬＣによってＭＡＣ層に提供されるパケットは、ＲＬＣの観点からはＲＬＣ ＰＤＵであり、ＭＡＣの観点からはＭＡＣ ＳＤＵである。受信側では、プロセスが反転され、各レイヤはＳＤＵを上位のレイヤに渡し、そこでＳＤＵはＰＤＵとして受信される。

物理層は本質的にターボ符号化と巡回冗長検査（ＣＲＣ：ｃｙｃｌｉｃ ｒｅｄｕｎｄａｎｃｙ ｃｈｅｃｋ）によって保護されたビットパイプを提供するが、リンク層プロトコルは、信頼性、セキュリティおよび完全性を高めることによって上位層へのサービスを強化する。加えて、リンク層は、マルチユーザ媒体アクセスおよびスケジューリングも担当する。ＬＴＥリンク層設計の主な課題の１つは、広範な異なるサービスとデータ転送速度とでインターネットプロトコル（ＩＰ）のデータフローに必要な信頼性レベルと遅延を提供することである。特に、プロトコルオーバーヘッドが拡張しなければならない。例えば、ボイス・オーバー・アイピー（ＶｏＩＰ：ｖｏｉｃｅ ｏｖｅｒ ＩＰ）フローは１００ミリ秒程度の遅延と最大１％までのパケット損失を許容できると広く想定されている。他方、ＴＣＰファイルのダウンロードは、低帯域幅・遅延の製品を使用したリンク上の方がうまくいくことは周知である。結果として、非常に高いデータ転送速度（例えば、１００Ｍｂ／ｓ）でのダウンロードは、遅延がさらに低いことを必要とし、ＩＰパケット損失に対してＶｏＩＰトラフィックよりも敏感であることになる。

全体として、これは部分的に関連し合っているＬＴＥリンク層の３つのサブレイヤによって達成される。パケットデータ収束プロトコル（ＰＤＣＰ：Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）副層は、主としてＩＰヘッダの圧縮および暗号化を担当する。加えて、ＰＤＣＰ副層は、ｅＮＢ間のハンドオーバが発生した場合の損失なしのモビリティをサポートし、上位層制御プロトコルに完全性保護を提供する。無線リンク制御（ＲＬＣ）副層は、主にＡＲＱ機能を含み、データのセグメント化および連結をサポートする。データのセグメント化および連結により、データ転送速度に関係なくプロトコルのオーバーヘッドが最小化される。最後に、媒体アクセス制御（ＭＡＣ）副層はＨＡＲＱを提供し、スケジューリング動作やランダムアクセスなどの媒体アクセスに必要な機能を担当する。

特に、媒体アクセス制御（ＭＡＣ）層は、ＬＴＥ無線プロトコルスタックのレイヤ２アーキテクチャにおける最下位のサブレイヤであり、例えば、非特許文献２によって定義されている。下位の物理層への接続はトランスポートチャネルによるものであり、上位のＲＬＣ層への接続は論理チャネルによるものである。したがってＭＡＣ層は、論理チャネルとトランスポートチャネルとの間の多重化および多重分離を行う。送信側のＭＡＣ層は、論理チャネルを介して受信されたＭＡＣ ＳＤＵからトランスポートブロックとして知られるＭＡＣ ＰＤＵを構築し、受信側のＭＡＣ層は、トランスポートチャネルを介して受信されたＭＡＣ ＰＤＵからＭＡＣ ＳＤＵを回復する。

ＭＡＣ層は、論理チャネルを介してＲＬＣ層にデータ転送サービスを提供し（参照により本明細書に組み込まれるＴＳ３６．３２１の５．４項および５．３項を参照）、論理チャネルは、制御データ（例えば、ＲＲＣシグナリング）を搬送する制御論理チャネルまたはユーザ・プレーン・データを搬送するトラフィック論理チャネルのどちらかである。他方、ＭＡＣ層からのデータは、下りリンクまたは上りリンクとして分類されるトランスポートチャネルを介して物理層と交換される。データは、それが無線でどのように伝送されるかに応じて、トランスポートチャネルに多重化される。

物理層は、無線インターフェースを介したデータおよび制御情報の実際の伝送を担う。すなわち、物理層は、送信側の無線インターフェース上でＭＡＣトランスポートチャネルからすべての情報を搬送する。物理層によって行われる重要な機能のいくつかには、ＲＲＣ層のための符号化および変調、リンク適応（ＡＭＣ）、電力制御、セル探索（初期同期とハンドオーバのための）、および他の測定（ＬＴＥシステム内およびシステム間の）が含まれる。物理層は、変調方式、符号化率（すなわち、変調および符号化方式、ＭＣＳ）、物理リソースブロックの数などの伝送パラメータに基づいて伝送を行う。物理層の機能に関するさらなる情報は、参照により本明細書に組み込まれる非特許文献３に記載されている。

無線リソース制御（ＲＲＣ）層は、無線インターフェースにおけるＵＥとｅＮＢとの間の通信、およびいくつかのセルを横切って移動するＵＥのモビリティを制御する。ＲＲＣプロトコルはまた、ＮＡＳ情報の転送もサポートする。ＲＲＣ＿ＩＤＬＥのＵＥでは、ＲＲＣは着呼のネットワークからの通知をサポートする。ＲＲＣ接続制御は、ページング、測定構成および通知、無線リソース構成、初期セキュリティアクティブ化、およびシグナリング無線ベアラ（ＳＲＢ：Ｓｉｇｎａｌｌｉｎｇ Ｒａｄｉｏ Ｂｅａｒｅｒ）とユーザデータを搬送する無線ベアラ（データ無線ベアラ、ＤＲＢ：Ｄａｔａ Ｒａｄｉｏ Ｂｅａｒｅｒ）との確立を含む、ＲＲＣ接続の確立、変更および解放に関連したすべての手順をカバーする。

無線リンク制御（ＲＬＣ）副層は、主にＡＲＱ機能を含み、データのセグメント化および連結をサポートする。すなわち、ＲＬＣ層は、ＲＬＣ ＳＤＵをＭＡＣ層によって指示されるサイズに入れるために、ＲＬＣ ＳＤＵのフレーミングを行う。データのセグメント化および連結により、データ転送速度に関係なくプロトコルのオーバーヘッドが最小化される。ＲＬＣ層は、論理チャネルを介してＭＡＣ層に接続される。各論理チャネルは、異なるタイプのトラフィックを搬送する。ＲＬＣ層の上位のレイヤは通常ＰＤＣＰ層であるが、場合によっては、ＲＲＣ層である。すなわち、論理チャネルＢＣＣＨ（Ｂｒｏａｄｃａｓｔ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）、ＰＣＣＨ（Ｐａｇｉｎｇ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）およびＣＣＣＨ（Ｃｏｍｍｏｎ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）上で伝送されるＲＲＣメッセージは、セキュリティ保護を必要とせず、よって、ＲＬＣ層に直接進み、ＰＤＣＰ層を迂回する。

［ＲＬＣ再送信プロトコル］
ＲＬＣが、欠落したＰＤＵの再送信を要求するように構成されている場合、これを確認モード（ＡＭ：Ａｃｋｎｏｗｌｅｄｇｅｄ Ｍｏｄｅ）で動作しているという。これは、ＷＣＤＭＡ／ＨＳＰＡで使用される対応する機構と同様である。全体として、ＲＬＣには、透過モード（ＴＭ：Ｔｒａｎｓｐａｒｅｎｔ Ｍｏｄｅ）、非確認モード（ＵＭ：Ｕｎａｃｋｎｏｗｌｅｄｇｅｄ Ｍｏｄｅ）、および確認モード（ＡＭ）の３つの動作モードがある。各ＲＬＣエンティティは、ＲＲＣによってこれらのモードのうちの１つで動作するように構成される。

透過モードでは、上位層から受信されたＲＬＣ ＳＤＵにプロトコルオーバーヘッドが追加されない。特殊な場合には、制限されたセグメント化／再組立て能力での伝送を行うことができる。セグメント化／再組立てが使用されるかどうかは、無線ベアラセットアップ手順において折衝されなければならない。透過モードは、例えば、音声のような非常に遅延に敏感なサービスに使用される。

非確認モードでは、再送信プロトコルが使用されないため、データ配信が保証されない。ＰＤＵ構造は、上位層における完全性確認のためのシーケンス番号を含む。ＲＬＣシーケンス番号に基づき、受信ＵＭ ＲＬＣエンティティは受信ＲＬＣ ＰＤＵの並べ替えを行うことができる。セグメント化と連結は、データに追加されたヘッダフィールドによって提供される。非確認モードのＲＬＣエンティティは、上りリンクと下りリンクとの間には関連付けが定義されていないため、単方向である。誤ったデータが受信された場合、対応するＰＤＵは構成に応じて廃棄またはマークされる。送信側では、タイマによって指定された一定時間内に送信されないＲＬＣ ＳＤＵは廃棄され、送信バッファから除去される。上位層から受信されたＲＬＣ ＳＤＵは、送信側でＲＬＣ ＰＤＵにセグメント化／連結される。受信側では、しかるべく再組立てが行われる。非確認モードは、誤りのない配信の重要度が配信時間の短さと比べて低いサービス、例えば、特定のＲＲＣシグナリング手順、ＭＢＭＳなどのセル・ブロードキャスト・サービス、ボイス・オーバー・アイピー（ＶｏＩＰ）などに使用される。

確認モードでは、ＲＬＣ層は、自動再送要求（ＡＲＱ：Ａｕｔｏｍａｔｉｃ Ｒｅｐｅａｔ Ｒｅｑｕｅｓｔ）プロトコルによる誤り訂正をサポートし、通常、誤りのないデータ配信が最も重要なファイル転送などのＩＰベースのサービスに使用される。ＲＬＣ再送信は、例えば、ピアＲＬＣ受信側エンティティから受信されたＲＬＣ状況通知、すなわちＡＣＫ／ＮＡＣＫに基づくものである。確認モードは、無線インターフェースのビット誤り率が高い場合の再送信によるパケットデータの信頼性の高い搬送のために設計されている。ＰＤＵに誤りがあり、またはＰＤＵが失われた場合、受信側からのＲＬＣ状況通知を受信すると送信側によって再送信が行われる。

ＡＲＱは、誤ったＰＤＵまたは欠落したＰＤＵの再送信のための再送信方式として使用される。例えば、着信シーケンス番号を監視することによって、受信側ＲＬＣエンティティは、欠落したＰＤＵを突き止めることができる。次いで、ＲＬＣ状況通知を受信ＲＬＣ側で生成し、送信側ＲＬＣエンティティにフィードバックして、欠落しているかまたは復号に失敗したＰＤＵの再送信を要求することができる。ＲＬＣ状況通知を送信側がポーリングすることもできる。すなわち、ポーリング機能は、ＲＬＣ送信側に受信バッファ状況を知らせるようにＲＬＣ受信側から状況通知を得るために、ＲＬＣ送信側によって使用される。状況通知は、ＨＡＲＱ並べ替えが完了する最後のＲＬＣデータＰＤＵまで、ＲＬＣデータＰＤＵまたはそれらの部分に関する肯定応答（ＡＣＫ）または否定応答情報（ＮＡＣＫ）を提供する。ポーリングフィールドが「１」に設定されているＰＤＵがある場合、またはＲＬＣデータＰＤＵが欠落していると検出された場合には、ＲＬＣ受信側は状況通知をトリガする。ＲＬＣ送信側でＲＬＣ状況通知のポーリングをトリガするいくつかのトリガが、参照により本明細書に組み込まれる、非特許文献４の５．２．３項で定義されている。送信側では、送信は送信ウィンドウ内のＰＤＵに対してのみ許可され、送信ウィンドウはＲＬＣ状況通知によってのみ更新される。したがって、ＲＬＣ状況通知が遅延すると、送信ウィンドウを進めることができず、送信が停滞する可能性がある。受信側はトリガされると送信側にＲＬＣ状況通知を送信する。

［レイヤ１／レイヤ２制御シグナリング］
スケジュールされたユーザに、ユーザの割当状況、トランスポートフォーマット、および他の伝送関連情報（例えば、ＨＡＲＱ情報、送信電力制御（ＴＰＣ：ｔｒａｎｓｍｉｔ ｐｏｗｅｒ ｃｏｎｔｒｏｌ）コマンド）を知らせるために、Ｌ１／Ｌ２制御シグナリングが、データと共に下りリンクで送信される。ユーザ割当がサブフレームごとに変化しうると想定して、Ｌ１／Ｌ２制御シグナリングがサブフレーム内の下りデータと多重化される。ユーザ割当は、ＴＴＩ（送信時間間隔：Ｔｒａｎｓｍｉｓｓｉｏｎ Ｔｉｍｅ Ｉｎｔｅｒｖａｌ）ベースで行われてもよく、その場合ＴＴＩ長はサブフレームの倍数とすることができることに留意されたい。ＴＴＩ長は、すべてのユーザについてサービスエリア内で固定されていてもよく、ユーザごとに異なっていてもよく、ユーザごとに動的であってもよい。一般に、Ｌ１／２制御シグナリングは、ＴＴＩ当たり１回だけ送信するのみでよい。一般性を失うことなく、以下ではＴＴＩが１つのサブフレームと等しいと仮定する。

Ｌ１／Ｌ２制御シグナリングは、物理下り制御チャネル（ＰＤＣＣＨ：Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）上で伝送される。ＰＤＣＣＨは、メッセージを下り制御情報（ＤＣＩ：Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）として搬送し、ＤＣＩは、ほとんどの場合、移動端末またはＵＥグループのためのリソース割当および他の制御情報を含む１つのサブフレームでいくつかのＰＤＣＣＨを伝送することができる。

一般に、上り無線リソースまたは下り無線リソースを割り当てるためのＬ１／Ｌ２制御シグナリングで送信される情報（特にＬＴＥ（‐Ａ）リリース１０）は、以下の項目に分類することができる。
− ユーザＩＤ、割り当てられているユーザを示す。これは通常、ＣＲＣをユーザＩＤでマスクすることによってチェックサムに含まれる。
− リソース割当情報、ユーザが割り当てられているリソース（例えば、リソースブロック、ＲＢ）を示す。あるいは、この情報はリソースブロック割当（ＲＢＡ：Ｒｅｓｏｕｒｃｅ Ｂｌｏｃｋ Ａｓｓｉｇｎｍｅｎｔ）と呼ばれる。ユーザが割り当てられているＲＢの数は動的でありうることに留意されたい。
− キャリアインジケータ、第１のキャリア上で伝送された制御チャネルが、第２のキャリアに関するリソース、すなわち、第２のキャリア上のリソースまたは第２のキャリアに関連したリソースを割り当てる場合に使用される。（クロス・キャリアス・ケジューリング）。
− 用いられた変調方式および符号化率を決定する変調および符号化方式。
− データパケットまたはその一部の再送信に特に有用な新データインジケータ（ＮＤＩ：ｎｅｗ ｄａｔａ ｉｎｄｉｃａｔｏｒ）および／または冗長バージョン（ＲＶ：ｒｅｄｕｎｄａｎｃｙ ｖｅｒｓｉｏｎ）などのＨＡＲＱ情報。

− 割り当てられた上りデータまたは制御情報送信の送信電力を調整する電力制御コマンド。
− 適用された循環シフトおよび／または直交カバー・コード・インデックスなどの参照信号情報、割当に関連した参照信号の送信または受信に用いられる。
− 割当の順序を識別するために使用される上りリンクまたは下りリンク割当インデックス、ＴＤＤシステムで特に有用である。
− ホッピング情報、例えば、周波数ダイバーシチを増加させるためにリソースホッピングを適用するかどうかおよびどのように適用するかの指示。
− ＣＳＩ要求、割り当てられたリソース内のチャネル状態情報の送信をトリガするために使用される。
− マルチクラスタ情報、送信が行われるのが単一のクラスタ（連続したＲＢのセット）においてか、それとも複数のクラスタ（連続したＲＢの少なくとも２つの非連続のセット）においてかを指示および制御するために使用されるフラグである。マルチクラスタ割当は、３ＧＰＰ ＬＴＥ‐（Ａ）リリース１０によって導入された。

上記のリストは非網羅的であり、使用されるＤＣＩフォーマットによってはすべての言及された情報項目が各ＰＤＣＣＨ伝送に存在する必要はないことに留意されたい。

下り制御情報は、全体サイズが異なり、上述したようにそれらのフィールドに含まれる情報も異なるいくつかのフォーマットで発生する。現在ＬＴＥに定義されている様々なＤＣＩフォーマットは以下の通りであり、非特許文献５、セクション５．３．３．１に詳細に記載されている（現行バージョンｖ１３．０．０は、ｈｔｔｐ：／／ｗｗｗ．３ｇｐｐ．ｏｒｇで入手することができ、参照により本明細書に組み込まれる）。例えば、以下のＤＣＩフォーマットを使用して、上りリンクのリソース許可を搬送することができる。
− フォーマット０：ＤＣＩフォーマット０は、上り送信モード１または２で単一アンテナポート送信を使用した、ＰＵＳＣＨのリソース許可の送信に使用される。
− フォーマット４：ＤＣＩフォーマット４は、上り送信モード２で閉ループ空間多重伝送を使用した、ＰＵＳＣＨのスケジューリングに使用される。

［ＬＴＥの上りアクセス方式］
上り方式は、スケジュールされたアクセス、すなわちｅＮＢによって制御されたアクセスとコンテンションベースのアクセスの両方を可能にする。

スケジュールされたアクセスの場合、ＵＥは、上りデータ送信のために特定の時間にわたる特定の周波数リソース（すなわち、時間／周波数リソース）を割り当てられる。しかしながら、いくつかの時間／周波数リソースをコンテンションベースのアクセスに割り当てることができる。これらの時間／周波数リソース内で、ＵＥは、最初にスケジュールされずに送信することができる。ＵＥがコンテンションベースのアクセスを行っている１つのシナリオは、例えば、ランダムアクセス、すなわち、ＵＥがセルへの初期アクセスを行っているとき、または上りリソースを要求するためのものである。

スケジュールされたアクセスでは、ＮｏｄｅＢスケジューラはユーザに上りデータ送信のための一意の周波数／時間リソースを割り当てる。より具体的には、スケジューラは、どの（１つまたは複数の）ＵＥがどの物理チャネルリソース（周波数）で送信を許可されるか、および移動端末によって送信に使用されるべき対応するトランスポートフォーマットを決定する。

割当情報は、スケジューリング許可を介してＵＥにシグナリングされ、Ｌ１／Ｌ２制御チャネル上で送信される。スケジューリング許可メッセージは、ＵＥが周波数帯域のどの部分を使用することを許可されるかの情報、許可の有効期間、およびＵＥが今後の上り送信に使用しなければならないトランスポートフォーマットを含む。最短有効期間は１サブフレームである。選択された方式によっては、許可メッセージには追加情報も含まれうる。「ＵＥごとの」許可だけがＵＬ‐ＳＣＨ上で送信する権利を許可するために使用される（すなわち、「ＲＢごとのＵＥごとの」許可はない）。したがって、ＵＥは、いくつかの規則に従って、割り当てられたリソースを無線ベアラ間で分配する必要がある。ＨＳＵＰＡとは異なり、ＵＥベースのトランスポートフォーマットの選択はない。ｅＮＢは何らかの情報、例えば、チャネル品質フィードバックや、通知されたスケジューリング情報や、ＱｏＳ情報に基づいてトランスポートフォーマットを決定し、ＵＥは選択されたトランスポートフォーマットに従わなければならない。

通常のスケジューリングモードは、下り送信リソースの割当のための下りリンク割当メッセージおよび上り送信リソースの割当のための上りリンク許可メッセージによる動的スケジューリングであり、これらは通常、特定の単一のサブフレームについて有効である。それらのメッセージは、ＵＥのＣ‐ＲＮＴＩを使用してＰＤＣＣＨ上で送信される。動的スケジューリングは、ＴＣＰなど、トラフィックが集中的で、レートが動的なサービスタイプには効率がよい。

動的スケジューリングに加えて、永続的スケジューリングが定義され、永続的スケジューリングは、無線リソースを、１サブフレームよりも長い期間にわたって半静的に構成してＵＥに割り当てることを可能にし、よって、サブフレームごとのＰＤＣＣＨ上での特定の下りリンク割当メッセージまたは上りリンク許可メッセージが不要になる。永続的スケジューリングは、データパケットのサイズが小さく、周期的で、半静的なＶｏＩＰなどのサービスに有用である。よって、ＰＤＣＣＨのオーバーヘッドは、動的スケジューリングの場合と比較して著しく減少する。

［論理チャネルの優先順位付け、ＬＣＰ、手順］
上りリンクについては、ＵＥが割り当てられた無線リソースを使用して送信するためにＭＡＣ ＰＤＵを作成するためのプロセスは完全に標準化されており、これは、ＵＥが、構成された各無線ベアラのＱｏＳを、異なるＵＥ実装間で最適かつ一貫性のある方法で確実に満たすように設計されている。ＵＥは、ＰＤＣＣＨ上でシグナリングされた上り送信リソース許可メッセージに基づき、新しいＭＡＣに含まれるべき論理チャネルごとのデータ量を決定しなければならず、必要ならば、ＭＡＣ制御要素のためのスペースも割り当てなければならない。

複数の論理チャネルからのデータを用いてＭＡＣ ＰＤＵを構築する際に、最も簡単で直感的な方法は絶対優先順位ベースの方法であり、ＭＡＣ ＰＤＵ空間は論理チャネル優先順位の降順で論理チャネルに割り当てられる。すなわち、最も優先順位の高い論理チャネルからのデータがまずＭＡＣ ＰＤＵでサービスされ、続いて次に優先順位の高い論理チャネルからのデータがサービスされ、ＭＡＣ ＰＤＵ空間がなくなるまで続く。絶対優先順位ベースの方法は、ＵＥ実装に関してはきわめて単純であるが、時として優先順位の低い論理チャネルからのデータの枯渇につながることがある。枯渇とは、優先順位の高い論理チャネルからのデータがすべてのＭＡＣ ＰＤＵ空間を占有するため、優先順位の低い論理チャネルからのデータを送信できないことを意味する。

ＬＴＥでは、重要度の順にデータを送信するだけでなく、優先順位の低いデータの枯渇を回避するために、論理チャネルごとに優先ビットレート（ＰＢＲ：Ｐｒｉｏｒｉｔｉｚｅｄ Ｂｉｔ Ｒａｔｅ）が定義されている。ＰＢＲは、論理チャネルに保証されている最小データ転送速度である。たとえ論理チャネルの優先順位が低い場合でも、ＰＢＲを保証するために少なくとも少量のＭＡＣ ＰＤＵ空間が割り当てられる。よって、枯渇問題はＰＢＲを使用することで回避できる。

ＰＢＲを用いたＭＡＣ ＰＤＵの構築は、２ラウンドからなる。第１ラウンドでは、各論理チャネルは論理チャネル優先順位の降順でサービスされるが、ＭＡＣ ＰＤＵに含まれる各論理チャネルからのデータ量は、最初は論理チャネルの構成ＰＢＲ値に対応する量に制限される。すべての論理チャネルがそれらのＰＢＲ値までサービスされた後、ＭＡＣ ＰＤＵに空きがある場合、第２ラウンドが行われる。第２ラウンドでは、各論理チャネルは優先順位の降順で再度サービスされる。第１ラウンドと比較した第２ラウンドの主な違いは、優先順位の高いすべての論理チャネルにそれ以上送信すべきデータがない場合にのみ、優先順位の低い各論理チャネルにＭＡＣ ＰＤＵ空間を割り当てることができることである。

ＭＡＣ ＰＤＵは、各構成論理チャネルからのＭＡＣ ＳＤＵだけでなく、ＭＡＣ ＣＥも含みうる。パディングＢＳＲを除いて、ＭＡＣ ＣＥは、ＭＡＣ層の動作を制御するので、論理チャネルからのＭＡＣ ＳＤＵよりも優先順位が高い。よって、ＭＡＣ ＰＤＵが構成されるときに、ＭＡＣ ＣＥは、存在する場合には、最初に含まれるべきであり、残りの空間は論理チャネルからのＭＡＣ ＳＤＵに使用される。次いで、さらなる空間が残っており、ＢＳＲを含めるのに十分な大きさであれば、パディングＢＳＲがトリガされ、ＭＡＣ ＰＤＵに含められる。

論理チャネル優先順位付けは、例えば、本明細書に組み込まれる、非特許文献６の５．４．３．１項で標準化されている。ＵＥが１つのＴＴＩで複数のＭＡＣ ＰＤＵを送信するように要求されたときにどのＭＡＣ ＰＤＵにＭＡＣ制御要素が含められるかの決定は、ＵＥの実装次第である。

［バッファ状況通知］
ＵＥからｅＮｏｄｅＢへのバッファ状況通知（ＢＳＲ：ｂｕｆｆｅｒ ｓｔａｔｕｓ ｒｅｐｏｒｔｓ）は、ｅＮｏｄｅＢの上りリソース割当、すなわち上りリンクスケジューリングを支援するために使用される。下りリンクでは、ｅＮＢスケジューラは各ＵＥに配信されるべきデータ量を明らかに知っている。しかしながら、上り方向では、スケジューリング決定はｅＮＢでなされ、データのバッファはＵＥにあるので、ＵＬ−ＳＣＨ上で送信される必要があるデータ量を示すためにＵＥからｅＮＢにＢＳＲを送信しなければならない。

ＬＴＥのバッファ状況通知ＭＡＣ制御要素は、長いＢＳＲ（ＬＣＧ ＩＤ＃０〜３に対応する４つのバッファ・サイズ・フィールドを有する）または短いＢＳＲ（１つのＬＣＧ ＩＤフィールドと１つの対応するバッファ・サイズ・フィールドとを有する）のどちらかからなる。バッファ・サイズ・フィールドは、論理チャネルグループのすべての論理チャネルにわたって利用可能なデータの総量を示し、異なるバッファ・サイズ・レベルのインデックスとして符号化されたバイト数で示される（参照により本明細書に組み込まれる、非特許文献６、第６．１．３．１章も参照されたい）。

短いＢＳＲと長いＢＳＲのどちらがＵＥによって送信されるかは、トランスポートブロック内の利用可能な送信リソース、いくつの論理チャネルグループに空でないバッファがあるか、およびＵＥで特定のイベントがトリガされるかどうかに依存する。長いＢＳＲは４つの論理チャネルグループについてのデータ量を通知し、短いＢＳＲは最も高い論理チャネルグループだけについてバッファされたデータ量を示す。

論理チャネルグループの概念を導入する理由は、たとえＵＥが４つを超える論理チャネルを構成していても、個々の論理チャネルごとにバッファ状況を通知すると過剰のシグナリングオーバーヘッドを生じさせることになるからである。したがって、ｅＮＢは各論理チャネルを論理チャネルグループに割り当てる。好ましくは、同じ／同様のＱｏＳ要件を有する論理チャネルは、同じ論理チャネルグループ内に割り当てられるべきである。

ＢＳＲがトリガされたときに、ＵＥにトランスポートブロックにＢＳＲを含めるための上りリソースを割り当てられていない場合、ＵＥは、ＢＳＲを送信する上りリソースを割り当てられるようにｅＮｏｄｅＢにスケジューリング要求（ＳＲ：ｓｃｈｅｄｕｌｉｎｇ ｒｅｑｕｅｓｔ）を送信する。単一ビットスケジューリング要求が物理上り制御チャネル（ＰＵＣＣＨ：Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）上で送信される（専用スケジューリング要求、Ｄ−ＳＲ）か、またはＢＳＲを送信するための上り無線リソースの割当を要求するランダムアクセス手順（ＲＡＣＨ）が行われる。

３ＧＰＰ ＴＳ ３６．２１１，"Ｅｖｏｌｖｅｄ Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ（Ｅ−ＵＴＲＡ）；Ｐｈｙｓｉｃａｌ Ｃｈａｎｎｅｌｓ ａｎｄ Ｍｏｄｕｌａｔｉｏｎ（Ｒｅｌｅａｓｅ ８）" ３ＧＰＰ ＴＳ ３６．３２１，ｖｅｒｓｉｏｎ １３．０．０ ３ＧＰＰ ＴＳ ３６．２１３，ｖｅｒｓｉｏｎ １３．０．０ ３ＧＰＰ ＴＳ ３６．３２２，ｖｅｒｓｉｏｎ １３．０．０ ３ＧＰＰ ＴＳ ３６．２１２，ｖｅｒｓｉｏｎ ｖ１３．０．０ ３ＧＰＰ ＴＳ ３６．３２１，ｖｅｒｓｉｏｎ ｖ１２．４．０ ３ＧＰＰ ＴＳ ３６．３２２，Ｖｅｒｓｉｏｎ １３．２．０

ＮＲは非常に高いデータ転送速度を目標としているので、送信側と受信側の両方に利用可能な処理時間は、送信されるべきデータ量と比較して非常に限られる可能性もある。送信側処理時間を最小化する一例は、必要なリアルタイム処理を最小化することである。例えば、ＬＴＥでは、ＰＤＣＰ ＳＤＵ（すなわちＩＰパケット）が利用可能になると、ＰＤＣＰ ＰＤＵを生成することができる。すなわち、ＰＤＣＰ ＰＤＵの生成は、非リアルタイムで、すなわち、現在ＰＤＣＰ ＰＤＵに許可されているリソースが存在するか否かに関係なく行うことができる。しかしながら、ＲＬＣおよびＭＡＣ ＰＤＵは、リアルタイムで（すなわち、ＵＬ ｇｒａｎｔの受信後に）しか生成することができない。ＤＬ／ＵＬデータＳＤＵがスケジューラによって決定された割当ＴＢサイズの合計サイズ内に収まるためには、セグメント化、連結および多重化が必要である。連結およびセグメント化は、厳格なリアルタイム処理要件に従うように、それが行われる前にスケジューリング決定／許可サイズの知識を必要とする。これはまた、送信側が、ＲＬＣ層またはＭＡＣ層のどちらについても、例えばスケジューリング／許可情報の前のサブヘッダ／ヘッダの前処理を行うことができないことを意味する。「前処理」を行えないために、許可受信時に処理遅延を被る。ＲＬＣ処理およびある程度までのＭＡＣ処理を前もって完了することができれば（許可受信）、ＰＨＹ層へのＭＡＣ ＴＢ提出の遅延は、比較すると、ずっと小さいはずである。

さらに、Ｕ‐Ｐｌａｎｅプロトコルアーキテクチャの設計目標の１つは、レイヤ２のプロトコルオーバーヘッドを減らすことである。現在のＬＴＥプロトコルアーキテクチャでは、Ｌｅｎｇｔｈ（長さ）フィールドは、ＲＬＣに１回とＭＡＣに１回の２回含まれており、ヘッダオーバーヘッドが増大する。加えて、ＰＤＣＰとＲＬＣは既存のＬＴＥプロトコルアーキテクチャでは独自のシーケンス番号を使用するため、やはりヘッダのオーバーヘッドが増大する。

上記の知見に鑑みて、本開示の目的は、レイヤ処理の効率を改善する手法を提供することである。

これは、独立請求項の特徴によって達成される。

有利な実施形態は従属請求項の主題である。

本開示の一態様によれば、通信システムにおいて無線インターフェース上でデータ受信ノードにデータを送信するためのデータ送信ノードが提供され、本データ送信ノードは、データ受信ノードからフィードバックされた状況通知に従って自動再送要求、ＡＲＱ、再送信を行い、データへのセグメント化制御情報の追加を含む状況通知に含まれるセグメント長情報に基づいて再送信されるべきデータを再セグメント化し、または再セグメント化しないための第３層処理ユニットと、第３層処理ユニットから、第３層データユニットを受信し、リソース割当に基づいて第３層データユニットをセグメント化し、第３層データユニットのそれぞれのセグメントと再セグメント化が適用されるべきである場合に変更されるセグメント化制御情報とを含む複数の第２層データユニットを形成するための第２層処理ユニットと、第２層から、複数の第２層データユニットのうちの１つまたは複数を受信し、複数の第２層データユニットのうちの１つまたは複数をデータ送信に割り当てられたリソース上にマップするための第１層処理ユニットと、を含む。

本開示の別の態様によれば、通信システムにおいて無線インターフェース上でデータ受信ノードにデータを送信するためのデータ送信ノードが提供され、本データ送信ノードは、データ受信ノードからフィードバックされた状況通知に従って自動再送要求、ＡＲＱ、再送信を行うための第３層処理ユニットと、第３層処理ユニットから、第３層データユニットを受信し、状況通知に従い、リソース割当に基づいて第３層データユニットをセグメント化し、セグメント化された第３層データユニットのそれぞれのセグメントを含む複数の第２層データユニットを形成するための第２層処理ユニットと、第２層から、複数の第２層データユニットのうちの１つまたは複数を受信し、複数の第２層データユニットのうちの１つまたは複数をデータ送信に割り当てられたリソース上にマップするための第１層処理ユニットと、を含む。

本開示の別の態様によれば、通信システムにおいて無線インターフェース上でデータ送信ノードからデータを受信するためのデータ受信ノードが提供され、本データ受信ノードは、データ送信に割り当てられたリソースから複数の第２層データユニットのうちの１つまたは複数を逆マップし、複数の逆マップされた第２層データユニットのうちの１つまたは複数を第２層処理ユニットに提供するための第１層処理ユニットと、複数の第２層データユニットのうちの１つまたは複数からの複数の第３層ユニットセグメントおよびセグメント化制御情報の多重分離を行い、複数の多重分離された第３層ユニットセグメントをセグメント化制御情報と共に第３層処理ユニットに転送するための第２層処理ユニットと、複数の多重分離された第３層ユニットセグメントの並べ替えおよび多重分離された第３層ユニットセグメントの第３層データユニットへの組立てを行うための第３層処理ユニットと、を含む。

さらに、通信システムにおいて無線インターフェース上でデータ受信ノードにデータを送信するための方法が提供され、本方法は、データ受信ノードからフィードバックされた状況通知に従って自動再送要求、ＡＲＱ、再送信を行うことを含み、データへのセグメント化制御情報の追加を含む状況通知に含まれるセグメント長情報に基づいて再送信されるべきデータを再セグメント化し、または再セグメント化しない第３層処理を行う工程と、第３層処理から、第３層データユニットを受信し、リソース割当に基づいて第３層データユニットをセグメント化し、第３層データユニットのそれぞれのセグメントと再セグメント化が適用されるべきである場合に変更されるセグメント化制御情報とを含む複数の第２層データユニットを形成することを含む第２層処理を行う工程と、第２層から、複数の第２層データユニットのうちの１つまたは複数を受信し、複数の第２層データユニットのうちの１つまたは複数をデータ送信に割り当てられたリソース上にマップすることを含む第１層処理を行う工程と、を含む。

さらに、通信システムにおいて無線インターフェース上でデータ受信ノードにデータを送信するための方法が提供され、本方法は、データ受信ノードからフィードバックされた状況通知に従って自動再送要求、ＡＲＱ、再送信を行うことを含む第３層処理と、第３層処理から、第３層データユニットを受信し、状況通知に従い、リソース割当に基づいて第３層データユニットをセグメント化し、セグメント化された第３層データユニットのそれぞれのセグメントを含む複数の第２層データユニットを形成することを含む第２層処理と、第２層から、複数の第２層データユニットのうちの１つまたは複数を受信し、複数の第２層データユニットのうちの１つまたは複数をデータ送信に割り当てられたリソース上にマップすることを含む第１層処理と、を含む。

さらに、通信システムにおいて無線インターフェース上でデータ送信ノードからデータを受信するための方法が提供され、本方法は、データ送信に割り当てられたリソースから複数の第２層データユニットのうちの１つまたは複数を逆マップすることを含み、複数の逆マップされた第２層データユニットのうちの１つまたは複数を第２層処理ユニットに提供する第１層処理と、複数の第２層データユニットのうちの１つまたは複数からの複数の第３層ユニットセグメントおよびセグメント化制御情報の多重分離を行い、複数の多重分離された第３層ユニットセグメントをセグメント化制御情報と共に第３層処理ユニットに転送することを含む第２層処理と、複数の多重分離された第３層ユニットセグメントの並べ替えおよび多重分離された第３層ユニットセグメントの第３層データユニットへの組立てを行うことを含む第３層処理と、を含む。

さらに、コンピュータ上で行われると、コンピュータに上記の方法の工程を実行させる命令を格納するためのコンピュータ可読媒体が提供される。

以下で添付の図面を参照して例示的な実施形態についてより詳細に説明する。

３ＧＰＰ ＬＴＥシステムの例示的アーキテクチャを示す図である。 ３ＧＰＰ ＬＴＥの全体的なＥ‐ＵＴＲＡＮアーキテクチャの例示的概要を示す図である。 通信のための様々なレイヤを有するＯＳＩモデルを示す図である。 プロトコル・データ・ユニット（ＰＤＵ）とサービス・データ・ユニット（ＳＤＵ）との関係、およびそれらのレイヤ間交換を示す図である。 ＰＤＣＰ層、ＲＬＣ層、およびＭＡＣ層における様々な機能の概要を示すと共に、様々なレイヤによるＳＤＵ／ＰＤＵの処理の例示的に示す図である。 ＬＴＥユーザプレーンにおける無線アクセスネットワークの様々なレイヤによるデータの処理を示す概略図である。 ＭＡＣ‐ＰＤＵの前処理および前処理されたヘッダを変更することによるそれらの物理リソース上へのマッピングを示す概略図である。 ３つのレイヤによる例示的な送信側処理の概略図である。 ２つのＭＡＣ ＰＤＵのうちの１つが失われた場合の３つのレイヤによる例示的な受信側処理の概略図である。 ２つのＭＡＣ ＰＤＵのうちの１つが失われた場合の３つのレイヤによる例示的な送信側処理の概略図である。 両方のＭＡＣ ＰＤＵが正しく受信された場合の３つのレイヤによる例示的な受信側処理の概略図である。 初回送信のための送信側での例示的なレイヤ処理を示す概略図である。 非特許文献７で定義されている状況通知（ＳＴＡＴＵＳ ＰＤＵ）を示す図である。 ＲＬＣ状況通知の例示的フォーマットを示す概略図である。 セグメント番号を使用した初回送信のための送信側での例示的なレイヤ処理を示す概略図である。 セグメント番号を使用した初回送信のための受信側での例示的なレイヤ処理を示す概略図である。 （再）セグメント番号を使用した再送信のための送信側での例示的なレイヤ処理を示す概略図である。 （再）セグメント番号を使用した再送信のための受信側での例示的なレイヤ処理を示す概略図である。 マルチコネクションをサポートする初回送信のための送信側での例示的なレイヤ処理を示す概略図である。 マルチコネクションをサポートする初回送信のための受信側での例示的なレイヤ処理を示す概略図である。 マルチコネクションをサポートする再送信のための送信側での例示的なレイヤ処理を示す概略図である。 マルチコネクションをサポートする再送信のための受信側での例示的なレイヤ処理を示す概略図である。 例示的なデータ送信装置およびデータ受信装置の機能構造を示すブロック図である。 送信側と受信側とで行われる例示的な方法の工程を示す流れ図である。

［本開示の基礎］
［Ｌ１／Ｌ２処理］
図４に、リンク層プロトコルを介して物理層に至るまでのＩＰパケットのデータフローを例示的に示す。この図には、各プロトコルサブレイヤがデータユニットに独自のプロトコルヘッダを追加することと、サブフレーム上のトランスポートブロックのマッピングとが示されている。トランスポートブロック（ＴＢ）は、物理層にマップされたＭＡＣ ＰＤＵを表す。

ＬＴＥにおけるトランスポートブロックのサブフレームへのマッピングは、いわゆる送信時間間隔（ＴＴＩ：ｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅ ｉｎｔｅｒｖａｌ）内で行われる。一般に、単入力単出力（ＳＩＳＯ：ｓｉｎｇｌｅ ｉｎｐｕｔ ｓｉｎｇｌｅ ｏｕｔｐｕｔ）、すなわち、送信側と受信側が１つのアンテナで動作する場合には、単一のトランスポートブロックが１つのＴＴＩにおいて１つのサブフレームにマップされる。ＭＩＭＯ／ＭＩＳＯ（ｍｕｌｔｉｐｌｅ ｉｎｐｕｔ ｍｕｌｔｉｐｌｅ ｏｕｔｐｕｔ／ｍｕｌｔｉｐｌｅ ｉｎｐｕｔ ｓｉｎｇｌｅ ｏｕｔｐｕｔ（多入力多出力／多入力単一出力））の場合には、２つのトランスポートブロックに対応する２つのコードワードが、１つのＴＴＩにおいて物理リソースにマップされうる。一般には、３つ以上のトランスポートブロックがマッピングのために考慮されうる。

ＬＴＥ Ｌ２機能を以下の表にまとめる。

ＬＴＥでは、ＲＬＣ層はＰＤＣＰ ＰＤＵの連結／セグメント化を行う。

送信側がトランスポートブロック（ＴＢ）のサイズを知っている場合、ＭＡＣ層は論理チャネル優先順位付け（ＬＣＰ）を行って、各ＲＬＣエンティティが送信すべき（下位層、すなわちＭＡＣ／ＰＨＹに提供すべき）データ量を決定する。各ＲＬＣエンティティは、１つまたは複数のＲＬＣ ＳＤＵを含む１つのＲＬＣ ＰＤＵを提供する。ＲＬＣ ＰＤＵで終わるＲＬＣ ＳＤＵごとに、対応するＬ‐ｆｉｅｌｄ（長さフィールド）が追加され、これにより受信側は対応するＳＤＵを抽出することができる。最後に含まれるＲＬＣ ＳＤＵがＲＬＣ ＰＤＵに完全に収まらない場合、そのＲＬＣ ＳＤＵはセグメント化される。すなわち、ＲＬＣ ＳＤＵの残りの部分は後続の（１つまたは複数の）ＲＬＣ ＰＤＵで送信されることになる。ＲＬＣ ＰＤＵの最初（最後）のバイトがＲＬＣ ＳＤＵの最初（最後）のバイトに対応するかどうかは、ＲＬＣヘッダに位置する「Ｆｒａｍｉｎｇ Ｉｎｆｏ」フラグ（２ビット）によって示される。それ以外に、セグメント化は、いかなるオーバーヘッドの追加をしない。ＲＬＣシーケンス番号（ＳＮ）は、データの元の順序を再確立し、損失を検出するためにＲＬＣ ＰＤＵヘッダに追加される。

ＭＡＣは、異なる論理チャネル識別子（ＬＣＩＤ）のＲＬＣ ＰＤＵを多重化し、対応するサブヘッダをＬＣＩＤおよびＬ‐ｆｉｅｌｄと共に追加する。トランスポートブロック構造のハイレベル図が図４に示されている。最近、３ＧＰＰは、新しい無線（ＮＲ：ｎｅｗ ｒａｄｉｏ）という名前で第５世代システムの研究作業に着手した。ＮＲは非常に高いデータ転送速度（目下、下りリンクで最大２０Ｇｂｉｔ／秒、上りリンクで１０Ｇｂｉｔ／秒）を目標としている。

［本開示の詳細な説明］
移動局または移動ノードまたはユーザ端末またはユーザ機器（ＵＥ）は、通信ネットワーク内の物理エンティティである。１つのノードは、複数の機能エンティティを有しうる。機能エンティティとは、ノードまたはネットワークの他の機能エンティティに対して所定の機能セットを実施し、かつ／または提供するソフトウェアまたはハードウェアモジュールを指す。ノードは、ノードをノードが通信するための通信設備または媒体に接続する１つまたは複数のインターフェースを有しうる。同様に、ネットワークエンティティは、機能エンティティを機能エンティティが他の機能エンティティまたはコレスポンデントノードと通信するための通信設備または媒体に接続する論理インターフェースを有しうる。

特許請求の範囲および本出願で使用される「無線リソース」という用語は、時間・周波数無線リソースなどの物理的無線リソースを指すものとして広く理解されたい。

以下の例示的な実施形態は、５Ｇ移動通信システムに想定される新しい無線技術のための改善された無線インターフェース層処理を提供する。今のところ、５Ｇ移動通信システムに関して合意されている詳細はごくわずかであり、そのため、以下では、実施形態の基礎をなす原理を説明できるように、多くの仮定を行う必要がある。しかしながら、これらの仮定については、本開示の範囲を限定すべきではない単なる例として理解されたい。特許請求の範囲に記載されている本開示の原理は、異なるシナリオに、本明細書に明記されていない方法で適用できることを当業者は理解するであろう。例えば、新しい無線技術は、ＬＴＥ（‐Ａ）のためにすでに定義されている無線技術から進化することになるが、５Ｇ移動通信システムの要件を満たすためにいくつかの変更が予想できる。したがって、様々な実施形態の特定の例示的な実施態様は、（リリース１０／１１／１２／１３／１４などによる）ＬＴＥ（‐Ａ）通信システムのためにすでに定義されている手順、メッセージ、機能などを、それらが５Ｇ通信システムの新しい無線技術と以下の実施形態について説明される様々な実施態様との両方に等しく適用できる限り、さらに再利用することもできるはずである。

本開示によれば、連結／セグメント化機能は、ＲＬＣ層からＭＡＣエンティティに移される。この手法はいくつかの利点を提供し、例えば、ＵＬ ｇｒａｎｔが受信される前に、（送信が上りリンクで行われる場合）ＲＬＣ ＰＤＵおよび部分的にＭＡＣ ＰＤＵを端末で事前構築することができる。これにより、それぞれのＲＬＣ ＰＤＵおよび部分的にＭＡＣ ＰＤＵを事前構築することによって処理時間が短縮される。ＲＬＣ層は、ＭＡＣスケジューリング決定およびＲＬＣ ＰＤＵサイズ指示（両方ともＬ１／Ｌ２シグナリングによるリソース割当と共に搬送される）を待たなくてよい。これにより、トランスポートブロックを生成する際の処理時間が短縮される。

図５Ａに、送信側（ＴＸ）と受信側（ＲＸ）側とのプロトコル層の主な機能を示す。図から分かるように、送信側では、セグメント化はＲＬＣ層と協働してＭＡＣ層で行われる。

図５Ｂに、送信側で行われる基本動作を示す。

ａ）ＲＬＣおよび／またはＭＡＣ ＰＤＵはＰＤＣＰ ＰＤＵごとに前処理される。すなわち、ＲＬＣ層はＰＤＣＰ ＰＤＵを連結しない。しかしながら、ＲＬＣ層は、ＲＬＣ ＳＤＵ（ＰＤＣＰ ＰＤＵ）をさらにセグメント化してよく、これが、ＰＤＣＰ ＰＤＵセグメント化の２つの結果、すなわちＲ１‐ＰＤＵ１およびＲ２‐ＰＤＵ２によって示されている。前処理は、所与の無線条件（例えば、ＲＳＳＩ／ＲＳＲＰなど）において、特定の高信頼水準で統計的に利用可能な「最小（または代替として平均）許可サイズ」に基づくものとすることができる。そのため、擬似ＬＣＰが（推定許可サイズで機能するため）この最小または平均許可サイズで実行され、それに応じてＲＬＣおよびＭＡＣ ＰＤＵが前処理される。（実際の）許可が受信され、ＬＣＰがＭＡＣ層で実行されたときに、ＬＣＰの結果に基づいて許可されたリソースに収容することができる（すなわち、対応するＭＡＣ ＰＤＵのサイズが対応するＬＣＩＤの許可サイズ以下である）前処理されたＲＬＣ ＰＤＵの一部が、物理層に提出されることになる。物理層はこれらに対するその処理を即座に、すなわち、時点ｔ１において開始しうる。図５Ｂでは、前処理されたＭＡＣヘッダを添付した事前セグメント化されたＲ１‐ＰＤＵ１およびＲ２‐ＰＤＵ１を、許可されたリソースに収容することができる。

ｂ）事前セグメント化されたＲ１‐ＰＤＵ２およびＲ２‐ＰＤＵ２を許可されたリソースに全体として収容することはできず、よって、割当サイズの知識を用いて、ＬＣＰが行われた後にこれらのＰＤＵのさらなるセグメント化が必要である。言い換えると、（上記工程後の）残りの許可は、前処理されたＰＤＵがセグメント化されることを必要とし、それらの対応するヘッダが再計算される必要がある。セグメント化は、（すでに前処理され、ＭＡＣ層に提出されたＲＬＣ ＰＤＵに対しては）ＭＡＣ層で、またはＲＬＣ層で（ＲＬＣはＬＣＰの結果に基づくセグメント化後にヘッダを再計算する）行うことができる。このＬ２処理の後、結果として得られたＭＡＣ ＰＤＵの部分（セグメント）は物理層に提出される。物理層は、続いて（すなわち、時点ｔ２において）これらに対するその処理を開始しうる。

図５Ｂでは、２つの異なるＲＬＣエンティティは異なる論理チャネルに属する。したがって、ＭＡＣは、論理チャネル優先順位付け手順（ＬＣＰ）に基づいて、対応するＭＡＣ ＰＤＵのうちのどちらがどの時点で物理層に提供されるべきであるかも決定する。ＬＣＰ手順の一例はＬＴＥから知られており、上記の背景技術の項に記載されている。とはいえ、本開示はこれに限定されず、一般に適用可能である。

受信側では、物理層処理の後、対応する逆の工程が行われる。

ａ）ＭＡＣ層は、ＭＡＣヘッダ（基本的にはＬＣＩＤフィールドとＬｅｎｇｔｈフィールド）に基づいて多重分離を行い、結果として得られる（１つまたは複数の）ＭＡＣ ＳＤＵをＲＬＣに与える。ＭＡＣ層がＭＡＣ ＳＤＵをＲＬＣ層に渡すとき、ＭＡＣ層もセグメント化／連結ヘッダフィールドを保持する。というのは、セグメント化および連結はＭＡＣによって行われ、セグメントの並べ替えおよび再組立てはＲＬＣによって行われるからである。これが、ＭＡＣがＲＬＣにセグメント化ヘッダフィールドを渡す理由である。言い換えると、ＭＡＣ層はＲＬＣに、ＭＡＣ ＳＤＵだけでなく、セグメント化／連結に関連したＭＡＣヘッダの一部も渡す。

ｂ）ＲＬＣ層は、（１つまたは複数の）完全なＲＬＣ ＳＤＵをＰＤＣＰに転送する前に、（もしあれば）ＲＬＣ ＰＤＵセグメントを再組立てする。ＰＤＣＰへの完全なＲＬＣ ＳＤＵの提出は、順不同で行われ、すなわち、例えば、既定の時間内または既定の回数の再送信内に正しく受信されなかったためにセグメントが欠落している場所に「穴」を含む。しかしながら、ＲＬＣは、（１つまたは複数の）欠落したＰＤＵおよび（１つまたは複数の）ＰＤＵセグメントを追跡する必要がある。ＡＲＱはＲＬＣで実行され、そのため、欠落したＲＬＣ ＰＤＵおよび／またはＰＤＵセグメントがあれば、可能な再送信のために送信側に通知されることになる。ここで、ＡＲＱは、タイマＴｉｍｅｒ１が満了するまで、欠落したＲＬＣ ＰＤＵおよび／またはＰＤＵセグメントを取得しようとすることになる。Ｔｉｍｅｒ１は、穴が最初に現れたとき（または後続／次のＲＬＣ ＳＤＵがＰＤＣＰ層に配信されるとき）に開始される。Ｔｉｍｅｒ１が満了すると、ＲＬＣはＰＤＣＰ層とＲＲＣに通知する。ＲＲＣは、無線リンク障害（ＲＬＦ：Ｒａｄｉｏ Ｌｉｎｋ Ｆａｉｌｕｒｅ）手順をトリガするなどのさらなる措置を講じうる。一般に、ＴＣＰのような上位層のエンドツーエンドプロトコルは、さらに正しい配信に対処しうる。

ｃ）ＰＤＣＰ層はＲＬＣから受信した着信ＰＤＵをＰＤＣＰ ＳＮ（または、ヘッダから直接利用できる場合はＣＯＵＮＴ、そうでない場合はＰＤＣＰヘッダに含まれるＳＮからＣＯＵＮＴを推定／計算する必要がある）に基づいて解読する。ＣＯＵＮＴの計算は、最後のＰＤＣＰ ＳＮと直前に受信したＰＤＣＰ ＰＤＵヘッダ内のＰＤＣＰ ＳＮ値との差を用いて最後のＣＯＵＮＴ値を調整することによって行われる。ここで、「最後」とは、正常に解読された前のＰＤＣＰ ＰＤＵを指す。加えて、ＰＤＣＰは「（１つまたは複数の）穴」がＲＬＣから到着するのを待つ。しかしながら、対応するＰＤＣＰ ＰＤＵが受信される前にＲＬＣからの指示が（Ｔｉｍｅｒ１満了時に）来た場合、ＰＤＣＰ ＳＤＵは（穴を含めて）上位層に提出される。

上記の手法は、ＡＭだけでなくＵＭにも適用できる。ＵＭが適用される場合には、ＲＬＣ層で再送信は行われない。とはいえ、受信側では、ＲＬＣ ＰＤＵまたはＲＬＣ ＰＤＵセグメントが欠落している場合、ＲＬＣ ＳＤＵがさらに組み立てられ、ＰＤＣＰ層に提供される。

ＡＭでは、ＲＬＣ ＰＤＵおよび／またはＰＤＵセグメントが欠落していることをＲＬＣ状況通知が示すと、送信側ＲＬＣは、対応する欠落したＲＬＣ ＰＤＵおよび／またはＰＤＵセグメントを、それを再送信することによって受信側が（１つまたは複数の）セグメントを再組立てするのを支援する適切なヘッダを含めてＭＡＣ層に提出する。

あるいは、ＲＬＣ層は、たとえ対応するＲＬＣ ＰＤＵの１セグメントのみが欠落していると示されたとしても、ＲＬＣ ＰＤＵ全体をＭＡＣ層に提出してもよい。加えて、ＲＬＣ層は、状況通知の詳細（すなわち、状況通知全体）をＭＡＣ層と共有する。この手法の利点は、ＲＬＣヘッダのオーバーヘッドが減ることである。再セグメント化がＲＬＣ層で行われる場合には、ＲＬＣ層は、ヘッダオーバーヘッドを増やすセグメント化ヘッダフィールドを追加する。この問題を克服するために、完全なＲＬＣ ＰＤＵがＭＡＣに送信され、ＭＡＣは状況通知に基づいてセグメント化を行う。ユニバーサル（共通）シーケンス番号がレイヤ（ＰＤＣＰ、ＲＬＣ、ＭＡＣ）間で使用されているので、ＲＬＣの状況通知はＭＡＣによって理解される。この場合、ＭＡＣ層は、この知識およびＬＣＰの結果に基づいて再セグメント化を行い、受信側が（１つまたは複数の）セグメントを再組立てするのを支援する適切なヘッダを含める。

上記の説明では、ＵＭＴＳ／ＬＴＥ（‐Ａ）規格で用いられる用語である「ＭＡＣ」、「ＲＬＣ」および「ＰＤＣＰ」に言及していることに留意されたい。しかしながら、本開示はこれらの規格にも、これらの規格の進歩にも限定されず、使用される用語に関係なく機能しうる。

言い換えると、このフレームワークは、（物理層に対応する）物理リソースへの／からのデータのマッピング／逆マッピングを担当する第１層、（ＭＡＣに対応する）第２層、ならびに（ＲＬＣおよび／またはＰＤＣＰに対応する）第３層があるプロトコルスタックとみなすことができる。ここでの「第１層」、「第２層」および「第３層」という用語は、必ずしもＯＳＩモデル層に対応するわけではないことに留意されたい。

プロトコルスタック処理待ち時間の短縮は、第１の物理層、第２層、および第３層を用いて送信側で達成することができ、第２層は第３層から（リソース割当の知識なしで第３層によって生成された）前処理された第３層ＰＤＵを受信し、（上りリンクで受信側から、または下りリンクで内部から）物理層のためのリソース割当を受信する。前処理された第３層ＰＤＵは、（すでに第３層または第２層で）セグメント化情報を含むヘッダを追加されうる。そのような前処理された第３層ＰＤＵは、優先順位が異なりうる複数の論理チャネルに対応する複数の第３層エンティティに提供されうることに留意されたい。したがって、第２層は次いで、優先順位付け手順を行いうる。受信したリソース割当に基づき、またおそらくは優先順位付け手順の結果にも基づき、第２の層は次いで、第１の時点ｔ１に第２層ヘッダとしてセグメント化情報を含む適切な前処理された第３層ＰＤＵを第１層に提供し、時点ｔ１より後の時点ｔ２に第１層にデータを提供する前に、おそらくは前処理されたＰＤＵのさらなるセグメント化を行い、ヘッダ内のセグメント化情報をそれに応じて変更する。

第３層がＡＲＱを実施する場合、第２層で受信される第３層のＰＤＵは、ＡＲＱ状況通知に従ってすでに事前セグメント化されている可能性があることに留意されたい。しかし、この手法は、第３層がＡＲＱを実施しない場合にも適用可能である。事前セグメント化は、その場合、過去の割当のいくつかの統計的尺度に基づいて、または他の規則に従って行われてもよく、あるいは全く行われなくてもよい。

さらに、本開示はまた、有利には、二重接続またはｍｕｌｔｉ‐ｃｏｎｎｅｃｔｉｖｉｔｙにも適用されうる。ｍｕｌｔｉ‐ｃｏｎｎｅｃｔｉｖｉｔｙは、接続モードにある複数の受信側／送信側ＵＥを、非理想的バックホールを介して接続された複数の別個のスケジューラによって提供されるＥ‐ＵＴＲＡおよびＮＲの中の無線リソースを利用するように構成するための動作モードである。言い換えると、多重接続では、送信側（端末など）における第３層より上位のレイヤは、複数の基地局（ｅＮＢ）に送信されるべき同じパケット（ＩＰまたはＰＤＣＰ）を提供する。その場合、２つ以上の基地局が同じパケットを独立して受信し、よってネットワークが正しく受信する確率が高まる。

ｍｕｌｔｉ‐ｃｏｎｎｅｃｔｉｖｉｔｙの概念は、３ＧＰＰ ＲＡＮ作業グループで検討中の１つの有望なソリューションであるいわゆる「ｄｕａｌ ｃｏｎｎｅｃｔｉｖｉｔｙ」と多少類似している、いわゆる「ｄｕａｌ ｃｏｎｎｅｃｔｉｖｉｔｙ」概念である。「ｄｕａｌ ｃｏｎｎｅｃｔｉｖｉｔｙ」という用語は、所与のＵＥが非理想的バックホールと接続された少なくとも２つの異なるネットワークノードによって提供される無線リソースを消費する動作を指すのに使用される。本質的に、ＵＥは、マクロセル（マクロｅＮＢ）とスモールセル（セカンダリｅＮＢ）の両方と接続されている。さらに、ＵＥのｄｕａｌ ｃｏｎｎｅｃｔｉｖｉｔｙに関与する各ｅＮＢは、異なる役割を担いうる。それらの役割は、必ずしもｅＮＢの電力クラスに依存するわけではなく、ＵＥ間で異なりうる。しかしながら、異なるデータがＵＥから異なるｅＮＢに送信されるｄｕａｌ ｃｏｎｎｅｃｔｉｖｉｔｙとは異なり、ｍｕｌｔｉ‐ｃｏｎｎｅｃｔｉｖｉｔｙでは、同じＩＰ／ＰＤＣＰパケットが複数のリンク／セル上で送信される。複数の受信側ｅＮＢの間で、１つは、複数の接続を介して受信されたセグメントの再組立てを行うレイヤを実施するマスタｅＮＢとして機能している。マスタｅＮＢはその他のｅＮＢと通信する。

例えば、ＬＴＥに関して言うと、ＰＤＣＰ層は、単一接続からｍｕｌｔｉ ｃｏｎｎｅｃｔｉｖｉｔｙへの切り替え時にすでに行っている他の機能に加えて、再組立て機能も引き継ぐ。ＡＲＱは依然としてＲＬＣ層（ＡＭ内）で実行されてよく、この場合、ＰＤＣＰ層は（完全にまたは部分的に）欠落したＰＤＣＰ ＳＮの詳細をＲＬＣ層と共有する必要がある。ＰＤＣＰ層は、ＲＬＣ層にセグメントの欠落部分について知らせる。その後、ＲＬＣ層の受信側エンティティは、ＲＬＣ層の送信側エンティティに状況通知を送信する。したがって、ＲＬＣ層とＰＤＣＰ層とで別個のＡＲＱは不要であり、単一接続とｍｕｌｔｉ‐ｃｏｎｎｅｃｔｉｖｉｔｙのＡＲＱがどちらも、ＲＬＣ層で実行されうることを意味する。あるいは、ＰＤＣＰ層はそれ自体の状況通知を作成してそれをＴＸ‐ＰＤＣＰエンティティに送信することができる。状況通知は、欠落したＰＤＣＰ ＰＤＵおよび／またはＰＤＵセグメントに関する情報を含むことになる。

上述のように待ち時間短縮および／またはオーバーヘッド削減を可能にするために、本開示は、送信側と受信側とで実施されるべき効率的な階層モデルを提供する。これには、以下のうちの１つまたは複数が含まれる。
− セグメント化を第２層に、すなわち、データを（第３層から）物理リソースにマップするのでリアルタイム処理を行わなければならない物理層のできるだけ近くに移す。これにより、対応する許可が受信される前であっても、共有チャネル上で送信するためのデータを準備する可能性が提供される。（端末実装はこれが可能か否かを利用しうる。言い換えると、端末タイミングが前処理されたＰＤＵを利用するか否かは、実装に任されてよい）。
− 複数のレイヤによってアクセスされる共通制御情報を用いる。通常、階層モデルは、各レイヤがそのレイヤで生成された制御情報にのみアクセスすることを前提としている。これにより、複数のレイヤ、つまり異なるレイヤのＰＤＵのヘッダにおいて重複した複製制御情報が提供されることがある。これは、受信データの並べ替えを可能にするシーケンス番号の場合に該当しうる。複数のレイヤ（ＰＤＣＰやＲＬＣなど）に共通シーケンス番号が使用されてよく、これによりヘッダのオーバーヘッドが削減される。
− 上位層（第３層、より詳細にはＲＬＣやＰＤＣＰなど）がＡＲＱ機能をサポートする。したがって、第３層の状況通知に基づいて、第３層はＰＤＵのセグメント化を行う。ここでは、状況通知に基づく第３層ＰＤＵのセグメント化は、下位層（第２層、より詳細にはＭＡＣ）で行われた受信割当に基づいて行われるセグメント化とは異なりうると仮定される。第３層が状況通知に基づいてセグメント化情報を第２層に提供し、第２層だけが割当と状況通知の両方に基づいてセグメント化を行う場合、同様の利点が達成されうる。この手法により、時間（前処理のおかげで）とリソース（再セグメント化は欠落したセグメントのみの再送信を可能にする）の両方を節約することが可能になる。

［ＡＲＱのためのレイヤ２セグメント化、レイヤ３事前セグメント化］
一実施形態によれば、通信システムにおいて無線インターフェース上でデータ受信ノードにデータを送信するためのデータ送信ノードが提供される。プロトコルスタック階層モデルの機能を実施するために、データ送信ノードは、データ受信ノードからフィードバックされた状況通知に従ってＡＲＱ再送信を行い、または行わず、（もしあれば）状況通知に含まれるセグメント長情報に基づいて再送信されるべきデータを再セグメント化し、または再セグメント化しないための第３層処理ユニットを含む。再セグメント化は、例えばヘッダとして、セグメント化されたデータにセグメント化制御情報を追加することを含む。このヘッダはまた、第２層でも有利に解釈されて使用され、第３層データユニットと共に第２層に提供される。この実施形態では、再送信プロトコルは第３層によって処理されると仮定され、これは第３層の下位または上位の他のレイヤにおける独立したＡＲＱ／ＨＡＲＱプロトコルの適用を排除しない。

データ送信ノードは、第３層処理ユニットから、第３層データユニットを受信し、リソース割当に基づいて第３層データユニットをセグメント化し、第３層データユニットのそれぞれのセグメントと再セグメント化が適用されるべきである場合に変更されるセグメント化制御情報とを含む複数の第２層データユニットを形成するための第２層処理ユニットをさらに含む。リソース割当は、データ受信ノードから受信されるか、またはデータ送信ノードで生成されうる。例えば、送信ノードが端末（ＵＥ）である場合、リソース割当（上りリンク許可）は基地局から、すなわちデータ受信ノードから受信されうる。他方、送信ノードが基地局である場合、送信のためのリソース割当は基地局で生成され、ＭＡＣ層に提供されうる。しかしながら、本開示は、端末間または中継器と端末間または中継器と基地局間の直接通信にも適用可能である。

最後に、データ送信ノードは、第２層から、複数の第２層データユニットのうちの１つまたは複数を受信し、複数の第２層データユニットのうちの１つまたは複数をデータ送信に割り当てられたリソース上にマップするための第１層処理ユニットを含む。

データ送信ノードは、そのヘッダ内にシーケンス番号を提供するための第４層処理ユニットをさらに含みうることに留意されたい。シーケンス番号は、新しい第４層ＳＤＵごとに、すなわち、ＩＰパケットごとに増加し、シーケンス番号が既定の最大値を有する間、増加は循環的でありうる。第３層は有利には別のシーケンス番号を提供せず、ＰＤＣＰ層によって提供されたシーケンス番号を含む第４層処理ユニットをカプセル化する。

ＬＴＥ用語に関しては、第１層は物理層であってよく、第２層はＭＡＣ層であってよく、第３層はＲＬＣ層であってよく、第４層はＰＤＣＰであってよい。しかしながら、第３層は、いくつかの実施形態ではＰＤＣＰ層とみなされ、または、特に現行のＬＴＥから進化したアーキテクチャの場合には、ＲＬＣとＰＤＣＰの両方の機能を有する１つの結合レイヤとみなされうることに留意されたい。

図６に、この実施形態による、ＬＴＥ用語を使用して例示された送信側での処理を示す。送信側は、上りリンクで基地局にデータを送信する端末であってよい。しかしながら、本開示はこれに限定されず、送信側は、別の端末に、または任意の他のノードにデータを送信する端末であってもよい。さらに、本開示は、基地局、または中継ノード、またはデータ送信側である別のノードにも適用されうる。

図６に示すように、１２００バイトの長さのＩＰパケット１がＰＤＣＰ層に提供され、よってＰＤＣＰ ＳＤＵを形成する。ＰＤＣＰ ＳＤＵは、単一のビットでありうるＤ／Ｃインジケータを含むヘッダを追加される。このビットは、ＰＤＣＰ ＰＤＵの内容がデータＰＤＵかそれとも制御ＰＤＵかを示す。この例では、このビットはデータＰＤＵには設定され（すなわち、ビットは１に等しく）、制御ＰＤＵには設定されていない（すなわち、ビットは０に等しい）。しかしながら、一般に、設定／未設定は反転されてもよい。ＰＤＣＰヘッダは、ＰＤＣＰシーケンス番号（ＳＮ）をさらに含む。

ＰＤＣＰ ＰＤＵ１は（ペイロードが１２００バイトであり）、ＲＬＣ層に送信され、よってＲＬＣ ＳＤＵを形成する。ＲＬＣ層は、ＲＬＣ ＰＤＵへの関連ＲＬＣヘッダを含む。図から分かるように、ＲＬＣヘッダは別のＤ／Ｃフラグ、Ｐフラグ、およびＲＦフラグを含む。Ｄ／Ｃフラグは、ＲＬＣ ＰＤＵによって制御またはデータが搬送されるかどうかを示し、Ｐフラグは、受信側（ピアＲＬＣエンティティ）に状況通知を要求するために設定されるポーリングビットである。Ｄ／Ｃフラグが設定されていない場合、状況通知は要求されない。ＲＦフラグは、ＲＬＣ ＰＤＵが完全ＰＤＣＰ ＰＤＵであるかそれともＰＤＣＰ ＰＤＵセグメントであるかを示す再セグメント化フラグである。ＲＦ値は最初に０に設定され、ＲＬＣ ＰＤＵが完全なＰＤＵであることを示し、次いでＲＬＣ ＰＤＵ１の一部としてＭＡＣ層に配信される。この例では、ＰＤＣＰ ＰＤＵ／ＩＰパケットのデータの初回送信では、ＲＬＣ層はセグメント化を行わず、むしろＭＡＣ層がセグメント化を行う。したがって、初回送信時には、ＲＦ値は常に０に設定される。

図６の例では、送信側ＭＡＣエンティティは、受信した許可に基づいてＲＬＣ ＰＤＵをセグメント化する必要がある。さらに、この例で想定されている許可サイズは、２つの異なる送信機会において８００バイトおよび４００バイトである（または８００バイトに少なくとも１つの許可が、残りは別の許可を待つ）。よって、ＭＡＣ層は、ＭＡＣ ＳＤＵに対応するＲＬＣ ＰＤＵをセグメント化する。ＲＬＣ ＰＤＵのセグメント化後、送信側ＭＡＣエンティティは、含まれるＲＬＣ ＰＤＵのセグメントオフセット（ＳＯ：ｓｅｇｍｅｎｔ ｏｆｆｓｅｔ）および最後のセグメントフィールド（ＬＳＦ：ｌａｓｔ ｓｅｇｍｅｎｔ ｆｉｅｌｄ）を示すために、セグメント化に関連するＭＡＣヘッダ部分をそれぞれのＭＡＣ ＰＤＵに含め、図６にＭＡＣ ＰＤＵ１およびＭＡＣ ＰＤＵ２として示されているＭＡＣ ＰＤＵを形成する。ＭＡＣ ＰＤＵ１は８００バイトのペイロードを含み、ＭＡＣ ＰＤＵ２は４００バイトのペイロードを含む。ＭＡＣ ＰＤＵ１とＭＡＣ ＰＤＵ２とはそれぞれＴＴＩ０とＴＴＩ１とに送信される。次いで、ＴＴＩ０とＴＴＩ１とは、異なるリソース、例えば異なる時間リソースに多重化される。しかしながら、これは、２つのＭＡＣ ＰＤＵを異なる時点にマップすることに本開示を限定するものではないことに留意されたい。一般には、２つ以上のＭＡＣ ＰＤＵが、異なるタイプのリソース、例えば、ＭＩＭＯシステムの異なる周波数や異なるストリーム、直交符号などにマップされうる。

この例のＳＯフィールドは、元のＰＤＵ内のＰＤＵセグメントの位置をバイト単位で示す。具体的には、ＳＯフィールドは、ＰＤＵセグメントのデータフィールドの最初のバイトが対応する元のＰＤＵのデータフィールド内の位置を示す。元のＰＤＵのデータフィールドの最初のバイトは、ＳＯフィールド値０で参照される。ＬＳＦフィールドは、ＰＤＵセグメントの最後のバイトがＰＤＵの最後のバイトに対応するか否かを示す。

ＭＡＣ層は、ＭＡＣ ＰＤＵ１とＭＡＣ ＰＤＵ２とに、論理チャネルＩＤ（ＬＣＩＤ）や拡張フラグ（Ｅ）など、ＭＡＣヘッダの後に続く他のフィールドがあるか否かを示すさらなるフィールドを含めてよい。値１は、このフィールドの後に少なくとも１つまたは複数のＥ／ＬＣＩＤフィールドがあることを示す。値０は、このフィールドの後にこれ以上Ｅ／ＬＣＩＤフィールドがないことを示し、次のバイトがＭＡＣ ＳＤＵの開始バイトであることを意味する。ヘッダ内にはいくつかのさらなるフィールドまたは予約フィールドがありうる（図には示されていない）。

この実施形態によれば、通信システムにおいて無線インターフェース上でデータ送信ノードからデータを受信するためのデータ受信ノードが開示される。本データ受信ノードは、データ送信に割り当てられたリソースから複数の第２層データユニットのうちの１つまたは複数を逆マップし、複数の逆マップされた第２層データユニットのうちの１つまたは複数を第２層処理ユニットに提供するための第１層処理ユニットを含む。さらに、本データ受信ノードは、複数の第２層データユニットのうちの１つまたは複数からの複数の第３層ユニットセグメントおよびセグメント化制御情報の多重分離を行い、複数の多重分離された第３層ユニットセグメントをセグメント化制御情報と共に第３層処理ユニットに転送するための第２層処理ユニットをさらに含む。本データ受信ノードは、複数の多重分離された第３層ユニットセグメントの並べ替えおよび第３層ユニットへの組立てを行うための第３層処理ユニットをさらに含む。

よって、第２層データユニットの一部である（また特に第２層ヘッダで搬送されうる）セグメント化情報も、第３層で見られ、使用される。よってこの手法は、一方では厳密なレイヤ分離を無視し、他方ではオーバーヘッドを節約し、第３層での並べ替えおよび再組立てを効率的に行うことを可能にする。これは、ＡＲＱ手順が第３層で実施される場合、特に有利であるが、これは必須ではなく、本開示を限定するものではない。

例示的な実施態様によれば、データ受信装置内の第３層処理ユニットは、少なくとも１つの第３層ユニットセグメントが正しく受信されたか否かを示す状況通知を搬送する制御データを生成するようにさらに構成される。状況通知は、少なくとも１つの第３層データユニットについての肯定応答もしくは否定応答のうちの少なくとも１つ、および／または第３層データユニットの正しく受信されたセグメントもしくは欠落したセグメントの識別を含みうる。ここで用いられうる状況通知の例示的フォーマットは、非特許文献７、セクション６．２．１．６に記載されている。しかしながら、これは一例にすぎず、状況通知のフォーマットおよび内容は、それが第３層ＰＤＵまたはそのセグメントの肯定受信応答および／または否定受信応答を可能にする限り、異なっていてもよいことに留意されたい。

図７に、誤りが発生しやすいチャネル上で受信されたＭＡＣ ＰＤＵ１およびＭＡＣ ＰＤＵ２の例示的な受信処理を示す。図７に示すように、ＭＡＣ ＰＤＵ１（８００バイトのペイロード）は正しく受信されるが、ＭＡＣ ＰＤＵ２（４００バイトのペイロード）は失われている（正しく復号され得なかった、すなわちＣＲＣが失敗した）。

ＭＡＣ層は、ＲＬＣ ＰＤＵ１の多重分離を行い、それをＲＬＣ層に送信する。次いでＲＬＣ層は、ＭＡＣセグメントの再組立ておよび並べ替えを行う。ＲＬＣ受信側（ＲＸ）は、ＭＡＣ ＰＤＵ１に属する８００〜１２００バイトを正しく受信したことを示す状況通知をＲＬＣ送信側（ＴＸ）に送信する。ＲＬＣ ＰＤＵセグメントの並べ替えおよび再組立ては、ＭＡＣ層からのヘッダ情報に基づいて行われる。これは、図７の例では、特にセグメントオフセットおよびＬＳＦインジケータを含む。ＲＬＣ層のＤ／Ｃフィールドは、ＲＬＣデータＰＤＵと状況通知のようなＲＬＣ制御ＰＤＵとの区別を可能にする。

図８に、送信側が（例えば、状況通知に基づいて）第２の欠落したＭＡＣ‐ＰＤＵ２セグメントを知っていると仮定して、ＲＬＣ送信側における例示的な後続の動作を示す。図８に示すように、この例では、ＲＬＣ ＴＸは、送信バッファから対応する欠落したパケットの完全なＲＬＣ ＰＤＵを取り出し、ＲＬＣ状況通知によって欠落していると示されている４００（８００〜１２００）バイトの新しいセグメント化（再セグメント化）を行う。再セグメント化は適切なＲＬＣヘッダを添付することも含む。ＲＬＣヘッダはここでは、バイト単位のオフセットによって再送信されるべきＲＬＣ ＰＤＵセグメントの位置を示すセグメントオフセットを含む。この例では、８０１から１２００までの欠落した４００バイトが再送信されることになるので、セグメント化オフセットＳＯ＝８０１である。次いで欠落した４００バイトに対応する再セグメント化されたＲＬＣ ＰＤＵがＭＡＣ層に配信される。

次いでＭＡＣ層は、受信したＲＬＣ ＰＤＵのセグメント化を行い、ＭＡＣ ＰＤＵ１（２００バイトのデータを含む）とＭＡＣ ＰＤＵ２（同様に２００バイトのデータを含む）とを形成し、これらは次いで、初回送信について図６を参照して上述したように、ＴＴＩ０とＴＴＩ１とにそれぞれ送信される。当然ながら、ＭＡＣ層は一般に、必要な場合にのみセグメント化を行う。ここでこの例では、許可サイズは十分ではなく、それが、ＭＡＣ層がＭＡＣ ＰＤＵ１とＭＡＣ ＰＤＵ２とを形成する理由である。割当が十分である場合、セグメント化は不要であり、またはおそらく連結が行われる（割当が１つのＭＡＣ ＰＤＵに必要とされるよりも大きい場合）。

特に、ＭＡＣ層は、ＲＬＣヘッダからＳＯフィールドおよびＬＳＦフィールドを読み取り、許可サイズに基づいて、すなわちこの例では、２００バイトと２００バイトのセグメント化サイズをそれぞれ反映するようにそれらを変更する。図８から分かるように、ＭＡＣ層は、セグメント化されたＭＡＣ ＰＤＵのそれぞれのヘッダにおいて新しいセグメント化情報、すなわち、初回送信の（再セグメント化されていない）ＲＬＣ ＰＤＵ内の再送信されるべきデータの新しいセグメントの位置に対応する、ＳＯ＝８０１およびＳＯ＝１００１とＬＳＦとを提供する。図９に、図８からのＭＡＣ ＰＤＵ１およびＭＡＣ ＰＤＵ２が両方とも正しく受信された例を示す。ＭＡＣ層は、正しく受信されたＭＡＣ ＰＤＵ１およびＭＡＣ ＰＤＵ２をＲＬＣ層に配信する。ＲＬＣ層は、ＭＡＣセグメントの並べ替えおよび再組立てを行い、次いで完全なＰＤＣＰ ＰＤＵをＰＤＣＰ層に配信する。並べ替えは、シーケンス番号（ＳＮ）に基づいて行われる。上述したように、有利には、オーバーヘッドを節約するために、ＰＤＣＰ層とＲＬＣ層の両方に単一のシーケンス番号が使用される。

言い換えると、ＲＬＣ ＲＸは、（再送信された、または初回送信後に正しく受信された）ＲＬＣ ＰＤＵのすべてのセグメントを収集し、ＭＡＣヘッダ情報に基づいてそれらを並べ替え、ＲＬＣ ＰＤＵを再組立てする。再組立てされたＰＤＵは次いで、さらに処理するために、（ＰＤＣＰ、またはＰＤＣＰがない場合は直接ＩＰなどの）上位層に提供されうる。

したがって、本開示は、以下の表２に示すように、ＲＡＮプロトコルスタックの異なるレイヤによって行われる機能を変更する。

以下の表３〜表５に、それぞれのレイヤ、ＰＤＣＰ、ＲＬＣおよびＭＡＣのヘッダの例を示す。

上記の表では、シーケンス番号の長さは１０ビットとして例示されている。しかしながら、これは一例にすぎず本開示を限定するものではないことに留意されたい。すでにＬＴＥでは、無線ベアラの特性に応じて、ＰＤＣＰシーケンス番号の長さを、５ビット、７ビット、または１２ビットとすることができる。当業者には明らかなように、シーケンス番号の長さはシステム設計の問題であり、本開示では任意の長さになるように選択されうる。

図６に示すように、ＰＤＣＰ ＰＤＵは受信側のＲＬＣ層に送信される。有利には、ＰＤＣＰ層、ＲＬＣ層およびＭＡＣ層は、これらすべてのレイヤによって理解されるユニバーサルシーケンス番号を使用する。この例では、ＰＤＣＰシーケンス番号が使用され、ＰＤＣＰシーケンス番号は、３つのレイヤすべてによって、または、ＳＮは下位層では必ずしも必要とされないので、少なくともＰＤＣＰとＲＬＣとによって理解される。

ＲＬＣ層は、ＲＬＣ ＰＤＵ、例えば、完全なＰＤＵかセグメント化されたＰＤＵかを示すＲＦフィールドに、関連するＲＬＣヘッダを含める。ＲＦ値は、最初は０に設定され、状況通知がＲＬＣ ＴＸに到着すると更新される。送信側は、ＲＬＣデータＰＤＵを送信するときに、起こりうる再送信のためにＲＬＣ ＰＤＵを再送信バッファにまだ格納している。再送信は、状況通知によって受信側から要求されうる。図６から分かるように、次いでＲＬＣ ＰＤＵはＭＡＣ層に配信される。その後、送信側ＭＡＣエンティティは、上位層（ＲＬＣ）から受信したＭＡＣ ＳＤＵに対してセグメント化および／または連結を行って、（１つまたは複数の）ＭＡＣ ＰＤＵを形成する。

各送信機会（ＴＴＩ）におけるＭＡＣ ＰＤＵのサイズは、無線チャネル条件およびそのために利用可能な送信リソースに応じて、ＭＡＣ層自体によって決定され通知される。背景技術の項で述べたように、各ＴＴＩで異なる割当が可能になる（例えば、リンク適応を向上させるための様々な変調および符号化方式による異なる量のデータを収容できる）ように共有チャネルに動的スケジューリングが適用されうる。

よって各送信ＭＡＣ ＰＤＵのサイズは異なりうる。送信側ＭＡＣエンティティは、ＲＬＣ ＰＤＵ／ＭＡＣ ＳＤＵを、それらがＭＡＣエンティティに到着する順序でＭＡＣ ＰＤＵに含める。したがって、単一のＭＡＣ ＰＤＵは、ＭＡＣが、それぞれのセグメントサイズおよび割り当てられたリソースに応じてセグメント化だけでなく連結も行いうるため、完全なＲＬＣ ＰＤＵまたはＲＬＣ ＰＤＵセグメントを含む可能性がある。ＭＡＣ ＰＤＵがＮ（Ｎは０よりも大きい整数）個のＲＬＣ ＰＤＵおよび／またはＰＤＵセグメントを含む場合には、ＭＡＣ層は、すべてのそれぞれの対応するＲＬＣ ＰＤＵおよび／またはＰＤＵセグメントについてＮ−１個のＬｅｎｇｔｈフィールド（Ｌ‐ｆｉｅｌｄ）、すなわち、最後のものを除くＲＬＣ ＰＤＵおよび／またはＰＤＵセグメントごとに１つのＬ‐ｆｉｅｌｄを含むことになる。

受信側では、図７に示すように（図６〜図９の例は連結ではなくセグメント化に関連するのでＬＩフィールドは示されていない）、ＭＡＣ層は、ヘッダの長さと、Ｌ‐ｆｉｅｌｄで、ＭＡＣ ＰＤＵの長さの両方を知っているので、実際のデータがどこから開始するかを知っている。ここではヘッダの長さが分かっているものと仮定する。例えば、ヘッダの長さは予め定義されており（例えば規格で指定されており）かつ／またはヘッダのフィールド内に示されていてよい。上記の例では、拡張ビットは、ヘッダが継続するかそれとも終了するかを示すために使用され、それによってヘッダサイズを決定することが可能になる。

ＭＡＣ層はセグメント化フィールド（ＳＯおよびＬＳＦ）を除去することなくＭＡＣ ＰＤＵの多重分離を行い、次いで多重分離されたＲＬＣ ＰＤＵ／セグメントはＲＬＣ層に配信される。受信側ＲＬＣ層は、ＲＬＣ ＰＤＵセグメントを受信すると、それらが順不同で受信された場合には、それらをまず並べ替えて再組立てする（図９も参照）。ＭＡＣ層で並べ替えおよび再組立てを行わない利点の１つは、処理時間の短縮である。受信側で１つのセグメントが欠落している場合には、ＭＡＣ層は再組立ておよび並べ替えを行うことができず、そのため上位層（ＲＬＣ）への配信に遅延が加わることになる。再組立ておよび並べ替えを遅延させないように、ＭＡＣ層は、図６を参照して上述したように、セグメント化および連結はＭＡＣ層によって行われるため、セグメント化フィールド（ＳＯ、ＬＳＦ）をＲＬＣ層に渡す。したがって、ＲＬＣ層は、ＭＡＣ層から受信した（１つまたは複数の）セグメント化ヘッダフィールドを読み取り、セグメント化（ＳＯ、ＬＳＦなど）および連結（ＬＩなど）の（１つまたは複数の）ヘッダフィールドに基づいて、ＲＬＣ層は、適切な場合には、並べ替えおよび再組立てを行う。したがって、この例では、受信側ＲＬＣ層がＭＡＣ層シグナリングフィールドを理解し、使用しなければならないので、クロスレイヤインタラクションが必要である。

ＭＡＣ層で順不同に受信されたＲＬＣ ＰＤＵは、上位層（ＲＬＣ）に配信される。誤りのない送信をサポートするために受信側ＲＬＣにおいてＡＲＱ動作が行われる（確認モード）。送信側が欠落したＲＬＣ ＰＤＵのみを再送信することができるように、受信側は送信側に、ＲＬＣ ＰＤＵの欠落した（１つまたは複数の）ＰＤＵまたは（１つまたは複数の）ＰＤＵセグメントの情報を示すＲＬＣ状況通知を提供する。

欠落した１つまたは複数のＰＤＵ／セグメントを伴った状況通知に応答して、ＲＬＣ層の送信側は、送信バッファから対応する欠落したパケットの完全なＲＬＣ ＰＤＵを取り出し、ＲＬＣ状況通知によって示されている欠落した（１つまたは複数の）セグメントに基づいて（再）セグメント化を行う。状況通知の受信後に再セグメント化が行われた場合、ＲＬＣはＲＦフィールドを０から１に変更する。次いで、（再）セグメント化された（１つまたは複数の）ＰＤＵがＭＡＣ層に配信され、ＭＡＣ層はＲＦフラグを読み取る。無線条件は再送信手順の間に悪化しうるので、欠落した１つまたは複数のＰＤＵは、（ＭＡＣ層によって行われる）再送の前により小さいセグメントに分割（再セグメント化）されなければならない可能性がある。これが図８に示されており、欠落した４００バイトのペイロードのＲＬＣ ＰＤＵは、ＲＬＣ層において再送信バッファ内の元の１２００バイトのペイロードのＲＬＣ ＰＤＵから取り出され、より小さい２００バイトのペイロードのＭＡＣ ＰＤＵにさらに分割（再セグメント化）される。

［ＭＡＣ層における再セグメント化］
図８を見ると、ＲＬＣ送信側が、セグメントの欠落した部分に基づいて、すなわち、正しく受信されなかった、ＲＬＣ状況通知によって示されＭＡＣ層に配信される４００バイト長のデータに基づいて再セグメント化を行うので、ＲＬＣオーバーヘッドがわずかに増大することが分かる。したがって、ＲＬＣでは（ＳＯ、ＲＦおよびＬＳＦを含む）再セグメント化ヘッダが必要であり、これによりＲＬＣヘッダのオーバーヘッドが増大する。

オーバーヘッドを削減するために、一実施形態によれば、再セグメント化はＭＡＣ層で行われる。

特に、この実施形態によれば、通信システムにおいて無線インターフェース上でデータ受信ノードにデータを送信するためのデータ送信ノードが提供される。データ送信ノードは、データ受信ノードからフィードバックされた状況通知に従って自動再送要求、ＡＲＱ、再送信を行うための第３層処理ユニットを含む。データ送信ノードは、第３層処理ユニットから、第３層データユニットを受信し、状況通知に従い、リソース割当に基づいて第３層データユニットをセグメント化し、セグメント化された第３層データユニットのそれぞれのセグメントを含む複数の第２層データユニットを形成するための第２層処理ユニットをさらに含む。第２層から、複数の第２層データユニットを受信し、複数の第２層データユニットをデータ送信に割り当てられたリソース上にマップするための第１層処理ユニットも存在する。

したがって、セグメント化機能は、物理層に最も近いレイヤである第２層に完全に移される。これを選択された例に基づいて図１０においてより詳細に示す。

送信側のＲＬＣ層は、ＰＤＣＰ ＰＤＵ（ＲＬＣ ＳＤＵ）に、状況通知を要求するポーリングビット（この実施形態がＵＭではなくＡＭで適用される場合）と、ＲＬＣ ＰＤＵが搬送するのがペイロード（ユーザ）データかそれとも制御データかを示すＤ／Ｃフィールドとを含むヘッダを追加する。ＲＬＣ層は非確認モードでも動作しうるので、本開示は、ＡＲＱを行うＲＬＣ層に限定されないことに留意されたい。

ＲＬＣ ＴＸ層は、ＲＬＣ ＲＸから受信した状況通知をＭＡＣ層に配信する。ＭＡＣ層は、シーケンス番号（ＳＮ）、ＳＯｓｔａｒｔおよびＳＯｅｎｄ値などのセグメント化情報を状況通知から読み取り、それに応じてセグメント化を行う。したがって、ＲＬＣ ＴＸは再送信バッファから完全なＲＬＣ ＰＤＵを取り出し、それをＭＡＣ ＴＸに送信する。これは図１０に例示されており、図１０には、図８に示すような４００バイトのみではなく１２００バイトのＰＤＣＰ ＳＤＵデータを有するデータフィールドを含むＲＬＣ ＰＤＵが示されている。

その後、ＭＡＣ ＴＸ層は、図１０に示すように、ＲＬＣ状況通知によって示され、ＲＬＣ層によってＭＡＣ層に転送されるＳＯｓｔａｒｔ、ＳＯｅｎｄ、ＳＮなどのセグメント化情報に基づいてセグメント化を行う。それに従って、ＭＡＣ ＰＤＵヘッダが生成される。図１０のヘッダは、ＬＣＩＤ（論理チャネル識別）と、さらなるヘッダ情報が存在するか否かを示すＥビットと、ここでは、ＲＬＣ ＰＤＵ内の搬送セグメントの開始を示すセグメントオフセット（バイト単位でありうる）およびカプセル化されたＲＬＣ ＰＤＵセグメントがＲＬＣ ＰＤＵ内の最後であるか否かを示す最後のセグメントフィールド（ＬＳＦ）を含む、セグメント化情報とを含む。図１０から分かるように、２００バイトと２００バイトの２つのセグメントのための８０１と１００１のオフセットがそれぞれシグナリングされる。

図１１Ａに、非特許文献７で定義されている状況通知（ＳＴＡＴＵＳ ＰＤＵ）を示す。ＳＴＡＴＵＳ ＰＤＵは、ＳＴＡＴＵＳ ＰＤＵペイロードとＲＬＣ制御ＰＤＵヘッダからなる。ＲＬＣ制御ＰＤＵヘッダは、Ｄ／ＣとＣＰＴフィールドからなる。ＳＴＡＴＵＳ ＰＤＵペイロードは、ＲＬＣ制御ＰＤＵヘッダに続く最初のビットから開始し、１つのＡＣＫ＿ＳＮおよび１つのＥ１と、ＮＡＣＫ＿ＳＮ、Ｅ１およびＥ２の０個以上のセットと、おそらくは、ＮＡＣＫ＿ＳＮごとのＳＯｓｔａｒｔとＳＯｅｎｄのセットからなる。必要に応じて、オクテット整列を達成するためにＳＴＡＴＵＳ ＰＤＵの終わりに１〜７個のパディングビットが含められる。

図１１Ｂに、ＲＬＣ状況通知の例示的フォーマットを示す。この例示的な状況通知は、図１１Ａに例示されたＬＴＥ状況通知と類似しており、類似したフィールドを含む。図１１Ｂの状況通知は、ＲＬＣシーケンス番号ではなくＰＤＣＰシーケンス番号が伝達されるという点で、図１１ＡのＬＴＥ状況通知とは異なる。

特に、状況通知は、Ｄ／Ｃフィールドと、ＰＤＵが状況ＰＤＵであるか否かを示すＣＰＴ（コントロールＰＤＵタイプ）フィールドとを含み、状況通知の状況ＰＤＵを示す。ＰＤＣＰ ＡＣＫ＿ＳＮは、状況通知（ＳＴＡＴＵＳ ＰＤＵ）において欠落していると通知されていない次の未受信ＲＬＣデータＰＤＵのＳＮを示す１０ビットの長さのフィールドである。接頭辞「ＰＤＣＰ」は、ここでは、共通のＳＮがＲＬＣとＰＤＣＰ層に使用されており、よって状況通知にも適用されることを強調するものである。

拡張ビット１（Ｅ１）は、ＰＤＣＰ ＮＡＣＫ＿ＳＮ、Ｅ１、およびＥ２のセットが後に続くか否かを示す。０に設定されている場合、ＮＡＣＫ＿ＳＮ、Ｅ１、およびＥ２のセットは後に続かず、１に設定されている場合、ＮＡＣＫ＿ＳＮ、Ｅ１、およびＥ２のセットが後に続く。

否定応答ＳＮ（ＮＡＣＫ＿ＳＮ）、この例ではＰＤＣＰ ＮＡＣＫ＿ＳＮフィールドは、ＡＭ ＲＬＣエンティティの受信側で失われたと検出されたＲＬＣ ＰＤＵ（またはその一部分）のＳＮを示す。

拡張ビット２（Ｅ２）は、ＳＯｓｔａｒｔとＳＯｅｎｄのセットが後に続くか否かを示す。０に設定されている場合、ＳＯｓｔａｒｔとＳＯｅｎｄのセットはこのＮＡＣＫ＿ＳＮの後に続かず、１に設定されている場合、ＳＯｓｔａｒｔとＳＯｅｎｄのセットがこのＮＡＣＫ＿ＳＮの後に続く。

３６．３２２によれば、セクション６．２．２．１８、セクション６．２．２．１９に、これらのＳＯｓｔａｒｔとＳＯｅｎｄを次のように記載する。
− ＳＯｓｔａｒｔ（１５ビット）：ＳＯｓｔａｒｔフィールドは（ＳＯｅｎｄフィールドと共に）、ＡＭ ＲＬＣエンティティの受信側で失われたと検出されたＳＮ＝ＮＡＣＫ＿ＳＮ（そのＳＯｓｔａｒｔが関連するＮＡＣＫ＿ＳＮ）を有するＲＬＣ ＰＤＵの部分を示す。具体的には、ＳＯｓｔａｒｔフィールドは、ＲＬＣ ＰＤＵのＤａｔａフィールド内のＲＬＣ ＰＤＵの部分の最初のバイトの位置をバイト単位で示す。
− ＳＯｅｎｄ（１５ビット）：ＳＯｅｎｄフィールドは（ＳＯｓｔａｒｔフィールドと共に）、ＡＭ ＲＬＣエンティティの受信側で失われたと検出されたＳＮ＝ＮＡＣＫ＿ＳＮ（そのＳＯｅｎｄが関連するＮＡＣＫ＿ＳＮ）を有するＲＬＣ ＰＤＵの部分を示す。具体的には、ＳＯｅｎｄフィールドは、ＲＬＣ ＰＤＵのＤａｔａフィールド内のＡＭＤ ＰＤＵの部分の最後のバイトの位置をバイト単位で示す。特別なＳＯｅｎｄ値「１１１１１１１１１１１１１１１」は、ＡＭＤ ＰＤＵの欠落した部分がＡＭＤ ＰＤＵの最後のバイトまでのすべてのバイトを含むことを示すために使用される。

言い換えると、ＳＯｓｔａｒｔとＳＯｅｎｄとは、否定応答されたＲＬＣ ＰＤＵセグメントの開始と終了とをそれぞれ示す。

［セグメント番号］
セグメントオフセット（開始と終了を合わせて）は、通常は長さ３０ビットであり、特に小さいセグメントでは、ＭＡＣサブヘッダのオーバーヘッドを増大させる。

オーバーヘッドを削減するために、この実施形態では、セグメント識別は、よって、第３層データユニット内の第３層データユニットのセグメントのシーケンス番号を示すセグメント番号である。このセグメント番号は、図に示されるように、すなわちＳＯフィールドの代わりにデータＰＤＵにおいて使用されうる。しかしながら、セグメント番号は有利には、状況通知（ＳＴＡＴＵＳ ＰＤＵ）においてＳＯｓｔａｒｔおよびＳＯｅｎｄを置き換えるためにも使用されうる。

一例では、ＭＡＣサブヘッダ（すなわち、セグメント化に関連したヘッダの部分）は、３０ビットのセグメントオフセット（１５ビットのＳＯｓｔａｒｔと１５ビットのＳＯｅｎｄ）の代わりに４ビットの長さのセグメント番号を使用することによって削減される。よって、ＭＡＣ層は、セグメント番号を示す４ビットに基づいてセグメント化を行う。４ビットのセグメント番号は最大１６個のセグメントを区別することを可能にする。しかしながら、４という数はここでは例示のためのものにすぎない。対応するユーザプレーン層アーキテクチャに、より多くのまたはより少ないセグメントが必要である場合、もっと多くのビットを使用してこれを行うこともできる。この実施形態の手法は、ＲＬＣ ＰＤＵ内の各セグメントの開始と終了の代わりに、セグメントごとのセグメント番号をシグナリングすることによってオーバーヘッドを削減するものである。セグメントの数はオフセットが関連しているＲＬＣ ＰＤＵ内のビット数より確実に小さいので、オーバーヘッドは一般に、オフセットではなくセグメントをアドレス指定することによって節約される。

セグメント番号の使用を送信側について図１２に示す。特に、図１２には、ＰＤＣＰ層に提供されたＩＰパケットが示されており、ここで、ＩＰパケットは、Ｄ／ＣフィールドおよびＰＤＣＰ ＳＮを追加され、このヘッダ情報と共にＲＬＣ層に提供される。ＲＬＣ層は、Ｄ／Ｃフィールドとポーリングフィールドとを含む独自のヘッダを追加することによってＰＤＣＰ ＰＤＵをカプセル化する。ここでは、ＲＬＣ層でセグメント化が行われないので、ＲＦフィールドは不要である。むしろ、ＲＬＣ ＰＤＵ１全体がＭＡＣ層に提供される。

図１２に示すように、ＭＡＣ層では、ＲＬＣ ＰＤＵは、８００バイトと４００バイトとをそれぞれ含む２つのセグメント、セグメント０とセグメント１とに分割される。このセグメント化は、割当サイズに基づいて行われうる。ＲＬＣ ＰＤＵのセグメント化の後、送信側ＭＡＣエンティティは、ＭＡＣ ＰＤＵを形成する関連するＭＡＣヘッダを含む。特に、ヘッダは、含まれるＲＬＣ ＰＤＵについてのセグメントの長さを示す長さインジケータ（ＬＩ）、セグメント番号（例えば上述した４ビット）、最後のセグメントフィールド（ＬＳＦ）、および０に設定されたフィールドＲ（再セグメント化が続いて行われないことを示す）を含む。ＬＩフィールドは、１つのＭＡＣ ＰＤＵが２つ以上のＲＬＣ ＰＤＵを含む連結の場合に必要である。セグメント化の場合には、許可サイズは知られており、そのため受信側は許可のサイズを知っており、それに応じて逆の動作を行うことができる。

ＭＡＣ層は次いで、セグメント化情報に基づいて、図１２にＭＡＣ ＰＤＵ１およびＭＡＣ ＰＤＵ２として示されている２つのＭＡＣ ＰＤＵを形成する。ＭＡＣ ＰＤＵ１とＭＡＣ ＰＤＵ２とは、それぞれの送信時間間隔ＴＴＩ０とＴＴＩ１とにそれぞれ送信される。

図１３に、セグメント番号がセグメントオフセットの代わりに用いられるこの実施形態についての例示的な受信側レイヤ処理を示す。

図１３に示すように、受信側では、ＭＡＣ ＰＤＵ１が正しく受信され、ＭＡＣ ＰＤＵ２が失われる。ＭＡＣ層は、ＭＡＣ ＰＤＵ１を（Ｒ、セグメント番号およびＬＳＦを含む）セグメント化ヘッダと共にＲＬＣ層に配信し、受信側のＲＬＣ層は、欠落した８００〜１２００バイト（すなわち、ＭＡＣ ＰＤＵ２）を示す状況通知を送信側ＲＬＣエンティティに送信する。ＲＬＣ層は次いで、ＲＬＣセグメントの再組立ておよび並べ替えを行う。ここでは、最初の８００バイトのセグメントだけが正しく受信されており、よってこの例では並べ替えを行う必要はない。

図１４に、データ受信側から状況通知を受信した際の例示的な送信側レイヤ処理を示す。図１４に示すように、ＲＬＣ層は再送信バッファから完全なＲＬＣ ＰＤＵを取り出す（これは、欠落した４００バイトだけではなく、ＲＬＣ ＰＤＵに含まれる１２００バイトのＰＤＣＰ ＳＤＵデータによって示されている）。ＭＡＣ層は次いで、ＲＬＣ状況通知に基づいて再セグメント化を行う。

ＲＬＣ ＰＤＵの再セグメント化の後、送信側ＭＡＣエンティティは、それぞれの含まれるＲＬＣ ＰＤＵについての長さ（ＬＩ）、３ビットのリセグメント番号、最後のリセグメントフィールド（ＬＲＦ）およびＲ＝１（再セグメント化が後に続くことを示す）を示すためにそれぞれの再セグメント化ＭＡＣ ＰＤＵに関連するＭＡＣヘッダを含め、図１４でＭＡＣ ＰＤＵ１およびＭＡＣ ＰＤＵ２として示されているＭＡＣ ＰＤＵを形成する。

必要ならば、ＭＡＣ層は、例えば、ＲＬＣ状況通知で通知された欠落したセグメントが、（ＬＣＰの実行後に）対応するＬＣＩＤに使用可能な許可に収まらない場合に、セグメント番号の欠落した部分の再セグメント化を行いうる。このために、ＭＡＣは、例えば３ビット（または必要ならばそれ以上）を使用して、ＲＬＣ ＰＤＵの対応するセグメントの「リセグメント」を識別しうる。

要約すると、第２層処理ユニットは、第２層データユニットのヘッダに、第３層データユニットのセグメント内の第３層データユニットのセグメントのシーケンス番号を示すリセグメント番号を含むセグメント識別を含め、リセグメント番号はセグメント番号より少ないビット数を使用してシグナリングされる。しかしながら、これは本開示を限定するものではないことに留意されたい。セグメント番号とリセグメント番号のサイズは同じであってもよい。「リセグメント」に用いられうる別の用語は、「サブセグメント」である。というのは、それが前のセグメント化の結果として得られるセグメントのサブセグメントだからである。

図１４では、再送はさほど頻繁ではなく、よってより大きいオーバーヘッドが許容できると仮定されているので、代替として、セグメントにセグメント番号が使用され、サブセグメントにサブセグメント番号の代わりにセグメントオフセットが使用されうる。

図１５に、図１４に示すＭＡＣ ＰＤＵ１およびＭＡＣ ＰＤＵ２の再送信を受信した際の受信側レイヤ処理を示す。

図１５に示すように、ＭＡＣ層は、ＭＡＣ ＰＤＵ１およびＭＡＣ ＰＤＵ２の多重分離を行い、それらのヘッダの一部を除去する。しかしながら、並べ替えおよび再組立てはＲＬＣ層で行われるので、ＭＡＣ層は、関連するセグメント化ヘッダフィールド（Ｒフィールド、セグメント番号、ＬＳＦ、ＬＲＦおよびリセグメント番号）を保持する。ＲＬＣは次いで、ＭＡＣセグメントの並べ替えおよび再組立てを行い、その結果（ＰＤＣＰ ＰＤＵ）をＰＤＣＰ層に送信する。

［第２層での並べ替えおよび再組立て］
本開示の別の実施形態によれば、受信側はさらに変更される。特に、並べ替えおよび再組立てをＲＬＣ層で行う代わりに、ＭＡＣ層が並べ替えおよび再組立てを行う。その場合、クロスレイヤインタラクションは不要である。この構成では、ＭＡＣ層は再送信処理の実行も担当する。セグメントのいずれかの部分が欠落している場合、ＭＡＣ層の受信側エンティティはＭＡＣ ＴＸに状況通知を送信する。ＭＡＣ状況通知はＲＬＣ状況通知とわずかに異なる。特に、どの状況通知がどのＬＣＩＤ（論理チャネル）に属するかを区別するために状況通知にＬＣＩＤフィールドが設けられる。

言い換えると、通信システムにおいて無線インターフェース上でデータ送信ノードからデータを受信するためのデータ受信ノードであって、本データ受信ノードは、データ送信に割り当てられたリソースから複数の第２層データユニットのうちの１つまたは複数を逆マップし、複数の逆マップされた第２層データユニットのうちの１つまたは複数を第２層処理ユニットに提供するための第１層処理ユニットと、複数の第２層データユニットのうちの１つまたは複数からの複数の第３層ユニットセグメントおよびセグメント化制御情報の多重分離を行い、複数の多重分離された第３層ユニットセグメントをセグメント化制御情報と共に第３層処理ユニットに転送するための第２層処理ユニットと、を含む。さらに、第２層処理ユニットは、複数の多重分離された第３層ユニットセグメントの並べ替えおよび多重分離された第３層ユニットセグメントの第３層データユニットへの組立ても行っている。第２層処理ユニットはまた、データが正しく受信されたか否かを確認し、ピア第２層エンティティに状況通知を送信するようにも構成されうる。受信側のこの実施形態は、セグメント化／連結が上述した第２層で行われる受信側の実施形態に特に適している。

［より多くのリンクに対するより多くのｅＮＢの同じベアラについてのｍｕｌｔｉ‐ｃｏｎｎｅｃｔｉｖｉｔｙ／ｄｕａｌ ｃｏｎｎｅｃｔｉｖｉｔｙ］
ｍｕｌｔｉ‐ｃｏｎｎｅｃｔｉｖｉｔｙの場合、ＰＤＣＰ層は重複したパケットを異なるｅＮＢに配信する。

以下の表７に、各レイヤの主な機能を有するｍｕｌｔｉ‐ｃｏｎｎｅｃｔｉｖｉｔｙのプロトコルスタックを記載する。

図１６に、ｍｕｌｔｉ‐ｃｏｎｎｅｃｔｉｖｉｔｙをサポートするこの実施形態によるＩＰパケット１の新規送信の場合の送信側レイヤ処理を示す。

特に、第１層は物理層であり、第２層は媒体アクセス制御、ＭＡＣ、層であり、第３層はパケットデータ制御プロトコル、ＰＤＣＰ、層である。しかしながら、ＰＤＣＰ層とＲＬＣ層とは１つの層に結合されてもよく、またはＲＬＣがその機能を行ってもよいことに留意されたい。第３層処理ユニットは、無線インターフェース上で、異なるそれぞれの基地局、または一般的にデータ受信ノードに送信するために、同じ第３層データユニットを異なる下位層スタックに提供するように構成される。下位層スタックは、個々に、互いに独立してセグメント化／再組立てを行うことができる。下位層スタックは、物理層とＭＡＣとを含みうる。しかしながら、下位層スタックは、ＲＬＣ層をさらに含んでいてもよい。

やはり上述したように、このレイヤは、現在のＬＴＥ層とは異なる名称で呼ばれ、異なる機能を有しうる。一般に、ｍｕｌｔｉ‐ｃｏｎｎｅｃｔｉｖｉｔｙには、上位層からパッカーを受信し、それぞれの複数のスタックの下位層に独自のＰＤＵとしてカプセル化されたパケットの複数（２つ以上）のコピーを提供する共通の１つの層がある。複数のスタックは、上記の実施形態のいずれかに記載されているように、別々に、互いに独立してセグメント化および再組立てを処理し、それによって複数のスタックがそれぞれの物理チャネル条件およびデータ受信の状況に適応できることが保証される。

第３層は有利には再送信処理を制御する。上記のｍｕｌｔｉ‐ｃｏｎｎｅｃｔｉｖｉｔｙのシナリオでは、受信側の各下位層スタックがパケットを正しく受信して再組立てする必要はない。他のすべてのスタックからパケットのセグメントを収集するそれらのうちの１つがパケットを再組立てすることができれば十分である。これによりある種の多様性が提供され、スループットが増加する。

図１６に示すように、ＩＰパケット１はＰＤＣＰ層のＰＤＣＰヘッダに添付され、対応するＰＤＣＰ ＰＤＵは２つの異なる基地局、ここではｅＮＢ１とｅＮＢ２とに送信される。基地局ｅＮＢ１とｅＮＢ２と（ネットワークノード）は、上述したようにプロトコル層をそれぞれ実装する（ＲＬＣ／ＭＡＣ／ＰＨＹ）。ｅＮＢ１は、ＲＬＣ ＰＤＵ１に対応するＰＤＣＰ ＰＤＵを、それぞれ８００バイトと４００バイトとを含む２つのセグメントＭＡＣ ＰＤＵ１とＭＡＣ ＰＤＵ２とに渡す。異なるセル内のチャネル品質は異なりうるので、ｅＮＢ２は異なるセグメント化を用いる場合がある。よってこの例では、ｅＮＢ２は、ＲＬＣ ＰＤＵ１を、それぞれ５００バイトと７００バイトとを含む２つのセグメントＭＡＣ ＰＤＵ１とＭＡＣ ＰＤＵ２とにセグメント化する。ＲＬＣ層は、確認モードで動作している場合、ＡＲＱ機能をさらに担当しうる。しかしながら、上述したように、ＰＤＣＰはＲＬＣ再送信を制御しうる。特に、（それぞれのｅＮＢの）各ＲＬＣ層は、マスタｅＮＢのＰＤＣＰに状況通知を渡すことができ、マスタｅＮＢは、再送信が必要であるか否か、およびパケットのどのセグメントについてかを決定する。ＰＤＣＰは次いで、それぞれのＲＬＣ層に再送信をしかるべく行うように指示する。

図１７に受信側の処理を示す。図１７に示すように、ｅＮＢ１は、０〜８００バイトを含むＭＡＣ ＰＤＵ１を受信するが、８０１〜１２００バイトのＭＡＣ ＰＤＵ２は失われる。他方、ｅＮＢ２は、０〜５００バイトを含むＭＡＣ ＰＤＵ１を受信するが、５０１〜１２００バイトは、ＭＡＣ ＰＤＵ２の欠落により失われる。ＰＤＣＰ層は、中央の並べ替えおよび再組立てを行う。

この実施形態でＲＬＣ層において並べ替えおよび再組立てを行わないことの利点は、ｍｕｌｔｉ‐ｃｏｎｎｅｃｔｉｖｉｔｙの間の不要な再送信を回避することである。再組立ておよび並べ替えがＲＬＣ層で行われた場合には、両方のｅＮＢのＲＬＣ層がＲＬＣ ＴＸにそれぞれ個別のＲＬＣ状況通知を送信することになる（ｅＮＢ１のＲＬＣは８０１〜１２００バイトの状況通知を送信し、ｅＮＢ２のＲＬＣは５０１〜１２００バイトの状況通知を送信し、これまでのところ実際に欠落した部分は８０１〜１２００バイトである）。この場合、ＲＬＣ ＴＸは、ＲＬＣ ＲＸで廃棄されることになる必要以上のセグメントを再送信することになりうる。

この問題を克服するために、この実施形態のＲＬＣ層は、可能な限り透過的に機能し、中央の並べ替えおよび再組立て機能は、ＰＤＣＰ層で実行される。並べ替えおよび再組立てを行うために、セグメント化はＭＡＣで行われているので、ＰＤＣＰ層はＭＡＣ層のセグメントヘッダ（ＳＯおよびＬＳＦ）を理解しなければならない。ＰＤＣＰは、ＲＬＣ層についての上記の実施形態で説明したのと同様に、ＭＡＣ層からＰＤＵを受信し、中央の並べ替えおよび再組立てを行う。それは共通セグメントを重ね合わせ、セグメントの欠落した部分、すなわちｅＮＢのいずれによっても正しく受信されていない部分のみを示す状況通知を送信する。

図１７を見ると、ＭＡＣ ＰＤＵは上述したようなセグメント化情報、すなわち、ＳＯおよびＬＳＦを含むことが分かる。しかしながら、その他の実施形態と同様に、セグメント化情報は、代わりにセグメント番号およびセグメントの長さを含んでいてもよい。さらに、図１５に、オーバーヘッドを削減するためのＲＬＣ層におけるＰＤＣＰ ＳＮの使用も示す。しかしながら、本開示はこれに限定されず、一般に、現在のＬＴＥの場合と同様に、ＰＤＣＰ層とＲＬＣ層とに別々のシーケンス番号が使用されてもよい。上述したように、クロスレイヤ設計は伝送の効率を向上させうる。特に、状況通知は、有利には、協調層（第３、ＰＤＣＰ）の下位のレイヤ（ＲＬＣ）で送受信され、受信されたセグメントをマッチングし、どのセグメントが送信されるべきかを決定するために協調層に提供される。さらに、ＭＡＣセグメント化情報は、並べ替えおよび再組立て、ならびに再送信の協調を可能にするために、協調層に渡されうる。

しかしながら、本開示は、ＰＤＣＰが再送信協調を行わない場合およびセグメントが各リンク上で実際に重複して再送信される場合に、わずかに効率が悪いときでさえも、やはり機能しうることに留意されたい。 有利には、図１７において、ＰＤＣＰ ＲＸは、欠落した８０１〜１２００バイトの状況通知を送信する。有利には、この状況通知は両方の（一般的には複数の）ｅＮＢに送信され、そのため両方のリンク上で再送信によってダイバーシチが達成される。しかしながら、本開示はこれに限定されず、一般に、再送信のためには、単一の接続が再確立されうる。

図１８に示すように、ＰＤＣＰ ＴＸは、状況通知を受信すると、送信バッファから完全なＰＤＣＰ ＰＤＵ（１２００バイト）を取り出し、ＰＤＣＰ状況通知によって示されている８００〜１２００バイトの再セグメント化（抽出）を行い、次いで８００〜１２００バイトのＰＤＵセグメント（リセグメントＰＤＵ）がＭＡＣに配信される。各ｅＮＢのＭＡＣ層は、上記の実施形態で説明したように、リソース割当に従って独自のセグメント化を行う。この場合、図１８から分かるように、（ｅＮＢ１に送信する）第１のＭＡＣエンティティは、８０１〜１２００バイトを２つのＭＡＣ ＰＤＵ、すなわち、８０１〜９００バイトのＭＡＣ ＰＤＵ１と９０１〜１２００バイトの第２のＭＡＣ ＰＤＵ２とにセグメント化する。他方、（ｅＮＢ２に送信する）第２のＭＡＣエンティティは、８０１〜１２００バイトをバイト８０１〜１０００バイトの第１のＭＡＣ ＰＤＵ１と１００１〜１２００バイトの第２のＭＡＣ ＰＤＵ２とにセグメント化する。

一般には、代替方法もある。すなわち、前述したように、ＰＤＣＰは再送信バッファから完全なＰＤＵを取り出し、次いで、ＰＤＣＰ状況通知によって示されている欠落したパケットの再セグメント化を行う。

しかしながら、代替として、ＰＤＣＰ状況通知は、ＭＡＣ層によって理解されてもよく、したがって、ＰＤＣＰは、再セグメント化を行うのではなく、完全なＰＤＵをＭＡＣに渡す。ＭＡＣはその場合、ＰＤＣＰ状況通知に基づいてセグメント化を行うことになる。

さらに別の可能な方法は、ＰＤＣＰがＲＬＣに、セグメントの（１つまたは複数の）欠落した部分について知らせることであろう。その後、ＲＬＣ層は状況通知をＲＬＣ ＴＸに送信する。

それに対応して、図１９に、図１８の再送信を受信した際の受信側（この上りデータ送信の例ではネットワーク側）を示す。特に、この例では、すべてのセグメントがＭＡＣで正しく受信され、多重分離されている。ＲＬＣは、基本的に、受信したセグメントをＭＡＣから受信したセグメント化情報と共にＰＤＣＰに渡し、ＰＤＣＰは、マルチコネクションのすべてのノード（ここではｅＮＢ１とｅＮＢ２）から受信したすべてのセグメントの並べ替えおよび再組立てを行う。

図２０に、通信システム２０００の一部でありチャネル２０９０上で通信する送信装置２０００ｔと受信装置２０００ｒとを示す。特に、第４層処理ユニット２０４０ｔ、第３層処理ユニット２０３０ｔ、第２層処理ユニット２０２０ｔ、および第１層処理ユニット２０１０ｔは、上記実施の形態に記載されているように対応するレイヤの処理を行う。送信部２０５０は、その（１つまたは複数の）アンテナを介して物理リソース上にマップされた信号を送信する。受信装置２０００ｒは、これに対応して、第４層処理ユニット２０４０ｒ、第３層処理ユニット２０３０ｒ、第２層処理ユニット２０２０ｒ、および第１層処理ユニット２０１０ｒと、その（１つまたは複数の）アンテナ上で送信された信号を受信する受信部２０６０とを含む。

図２１に、本開示に係る方法の実施形態のうちの１つを例示する。特に、左側にはデータ送信側で行われる方法を示し、右側にはデータ受信側で行われる方法を例示する。

本送信方法は、第３層ＳＤＵを受信する工程２１１０ｔと、第３層ＳＤＵに基づいて、例えばヘッダを添付することによってＰＤＵを生成する工程２１２０ｔと、ＰＤＵを第２層に渡す工程２１３０ｔとを含む、第３層によって行われる工程を含みうる。次いで第２層処理は、第３層ＰＤＵを第２層ＳＤＵとして受信する工程２１４０ｔと、受信した割当に基づいて（いくつかの実施形態では状況通知にも基づいて）、上述したようにセグメント化または連結を行う工程２１５０ｔと、そのように形成されたＰＤＵを第１層に渡す工程２１６０ｔとを含みうる。次いで第１層処理は、第２層からＳＤＵを受信する工程２１７０ｔと、ＳＤＵを物理リソースにマップする工程２１８０ｔと、送信する工程２１９０ｔとを含む。

受信側では、第１層処理の一部として、受信２１９０ｒが行われ、次いでデータは物理リソースから逆マップされ２１８０ｒ、第２層に渡される２１７０ｒ。第２層処理は、ＰＤＵを受信する工程２１６０ｒを含み、ＰＤＵを多重分離し２１５０ｒ、並べ替えおよび再組立てのために第３層に渡す２１４０ｒ（上述したように、１つの代替の実施形態では、並べ替えおよび再組立ても第２層で行われる）。第３層処理は、ＰＤＵを受信する工程２１３０ｒと、並べ替えおよび再構成を行う工程２１２０ｒと、再組立てされたパケットを上位層に渡す工程２１１０ｒとを含む。

さらに、データ受信側での状況通知の送信と、データ送信側で状況通知を受信する工程２１２８ｔとを含む、第３層で再送信機構を実装する実施形態がある。状況通知がいくつかのセグメントについての否定応答を含む場合（２１２５ｔ、「はい」）、再セグメント化は第３層で（あるいは、いくつかの実施形態では第２層で）行われる。

［本開示のハードウェアおよびソフトウェア実装］
他の例示的な実施形態は、ハードウェアおよびソフトウェアを使用した上述の様々な実施形態の実装に関するものである。これに関連して、ユーザ端末（移動端末）およびｅＮｏｄｅＢ（基地局）が提供される。ユーザ端末および基地局は、受信部、送信部、プロセッサなど、方法に適切に関与する対応するエンティティを含む、本明細書に記載した方法を行うように適合される。

様々な実施形態は、コンピューティングデバイス（プロセッサ）を使用して実装または実行されうることをさらに理解されたい。コンピューティングデバイスまたはプロセッサは、例えば、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ：ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｏｒ）、特定用途向け集積回路（ＡＳＩＣ：ａｐｐｌｉｃａｔｉｏｎ ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ：ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ｌｏｇｉｃ ａｒｒａｙ）または他のプログラマブル論理回路などであってもよい。これらは、そこに結合されたデータ入出力を含みうる。様々な実施形態は、これらのデバイスの組み合わせによっても実行または具体化されうる。

さらに、様々な実施形態は、プロセッサによって、またはハードウェアにおいて直接実行されるソフトウェアモジュールによって実装されてもよい。また、ソフトウェアモジュールとハードウェア実装との組み合わせも可能である。ソフトウェアモジュールは、例えば、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、レジスタ、ハードディスク、ＣＤ‐ＲＯＭ、ＤＶＤなどの任意の種類のコンピュータ可読記憶媒体に格納されてよい。

異なる実施形態の個々の特徴は、個別にまたは任意に組み合わせて、別の実施形態の主題としうることにさらに留意されたい。

当業者には、特定の実施形態において示される本開示に対して多くの変形および／または修正が行われうることができることが理解されよう。したがって、本明細書の実施形態は、あらゆる点で例示的であり、限定的ではないとみなされるべきである。

要約すると、本開示は、通信システムにおける受信側と送信側とにおけるレイヤ処理に関するものである。レイヤ処理は、少なくとも第１層、第２層、および第３層における処理を含む。送信側では、第３層は、パケットを受信し、パケットのヘッダを追加し、パケットを第２層に転送する。第２層は、セグメント化を行い、セグメント化されたデータを第１層に提供し、第１層はセグメント化されたデータを物理リソース上にマップする。セグメント化は割り当てられたリソースに基づくものである。再送信は第３層で行われてもよく、よって、第３層は特定のセグメントについて受信したフィードバックに従ってパケットを再セグメント化し、再セグメント化されたデータを下位層に提供しうる。あるいは、フィードバック情報は第２層に提供され、その場合第２層はフィードバック情報を考慮に入れてセグメント化を行う。それに対応して、受信側は、第３層で並べ替えおよび再組立てを行い、またそのための制御情報を第２層から受信する。

Claims (15)

1. 通信システムにおいて無線インターフェース上でデータ受信ノードにデータを送信するためのデータ送信ノードであって、
   前記データ受信ノードからフィードバックされた状況通知に従って自動再送要求（ＡＲＱ）再送信を行い、データへのセグメント化制御情報の追加を含む前記状況通知に含まれるセグメント長情報に基づいて再送信されるべき前記データを再セグメント化し、または再セグメント化しないための第３層の処理ユニットと、
   前記第３層の処理ユニットから、第３層データユニットを受信し、リソース割当に基づいて前記第３層データユニットをセグメント化し、該セグメント化によって分けられた前記第３層データユニットのそれぞれのセグメントと再セグメント化が適用されるべきである場合に変更される前記セグメント化制御情報とを含む複数の第２層データユニットを形成するための第２層の処理ユニットと、
   前記第２層から、前記複数の前記第２層データユニットのうちの１つまたは複数を受信し、前記複数の前記第２層データユニットのうちの前記１つまたは複数をデータ送信に割り当てられたリソース上にマップするための第１層の処理ユニットと、
   前記割り当てられたリソース上にマップされた前記データを送信するための送信部と
   を含む、データ送信ノード。
2. 前記第３層の処理ユニットが、前記第３層データユニットに、前記含まれるデータが制御データかそれともペイロードデータかの指示、前記送信されるデータについての状況通知が要求されるか否かを示すポーリング指示、前記第３層データユニットが上位層データユニット全体または上位層データユニットのセグメントを含むか否かを示す再セグメント化指示のうちの少なくとも１つを含むヘッダを追加するように構成されており、
   前記第２層の処理ユニットが前記第２層データユニットに、前記第２層データユニットによって搬送される前記第３層データユニットの前記セグメントを示すセグメント識別、前記第２層データユニットによって搬送される前記第３層データユニットの前記セグメントが、前記第３層データユニットの最後のセグメントであるか否かを示す最後のセグメントフラグのうちの少なくとも１つを含むヘッダを追加するように構成されている、
   請求項１に記載のデータ送信ノード。
3. 前記第１層が物理層であり、前記第２層が媒体アクセス制御（ＭＡＣ）層であり、前記第３層がパケットデータ制御プロトコル（ＰＤＣＰ）層であり、
   前記第３層の処理ユニットが、前記無線インターフェース上で、異なるそれぞれの基地局に送信するために、同じ第３層データユニットを異なる下位層スタックに提供し、再送信処理を制御するように構成されており、
   前記下位層スタックが、個々に、互いに独立してセグメント化／再組立てを行うことができる、
   請求項１または２に記載のデータ送信ノード。
4. 通信システムにおいて無線インターフェース上でデータ受信ノードにデータを送信するためのデータ送信ノードであって、
   前記データ受信ノードからフィードバックされた状況通知に従って自動再送要求（ＡＲＱ）再送信を行うための第３層の処理ユニットと、
   前記第３層の処理ユニットから、第３層データユニットを受信し、前記状況通知に従い、リソース割当に基づいて前記第３層データユニットをセグメント化し、該セグメント化によって分けられた前記第３層データユニットのそれぞれのセグメントを含む複数の第２層データユニットを形成するための第２層の処理ユニットと、
   前記第２層から、前記複数の前記第２層データユニットのうちの１つまたは複数を受信し、前記複数の前記第２層データユニットのうちの前記１つまたは複数をデータ送信に割り当てられたリソース上にマップするための第１層の処理ユニットと、
   前記割り当てられたリソース上にマップされた前記データを送信するための送信部と
   を含む、データ送信ノード。
5. 前記第２層の処理ユニットが、前記第２層データユニットのヘッダに、前記第３層データユニット内の前記第３層データユニットの前記セグメントのシーケンス番号を示すセグメント番号を含むセグメント識別を含める、
   請求項１〜４のいずれか一項に記載のデータ送信ノード。
6. 前記第２層の処理ユニットが、前記第２層データユニットの前記ヘッダに、前記第３層データユニットの前記セグメント内の前記第３層データユニットの前記セグメントのシーケンス番号を示すリセグメント番号を含む前記セグメント識別を含め、前記リセグメント番号が前記セグメント番号より少ないビット数を使用してシグナリングされる、
   請求項５に記載のデータ送信ノード。
7. 前記第１層が物理層であり、前記第２層が媒体アクセス制御（ＭＡＣ）層であり、前記第３層が無線リンク制御（ＲＬＣ）層であり、
   前記データ送信ノードが、シーケンス番号を提供するための、パケットデータ制御プロトコル（ＰＤＣＰ）層である第４層の処理ユニットをさらに含み、
   前記第３層が別のシーケンス番号を提供せず、前記ＰＤＣＰ層によって提供された前記シーケンス番号を含む第４層データユニットをカプセル化する、
   請求項１〜６のいずれか一項に記載のデータ送信ノード。
8. 前記状況通知が、前記シーケンス番号によって識別された前記第４層データユニットにおいてカプセル化された前記第３層データユニットの少なくとも１つのセグメントについての肯定応答または否定応答を含む、
   請求項７に記載のデータ送信ノード。
9. 前記第２層の処理ユニットが、
   第２層データユニットに、複数の第３層データユニットを含め、前記第２層データユニットに、それぞれの含まれる第３層データユニットについてその長さを示す長さフィールドを含める
   ようにさらに構成されている、請求項１〜８のいずれか一項に記載のデータ送信ノード。
10. 通信システムにおいて無線インターフェース上でデータ送信ノードからデータを受信するための受信部と、
    データ送信に割り当てられたリソースから複数の第２層データユニットのうちの１つまたは複数を逆マップし、前記複数の第２層データユニットのうちの前記逆マップされた１つまたは複数を第２層の処理ユニットに提供するための第１層の処理ユニットと、
    前記複数の第２層データユニットのうちの前記１つまたは複数からの複数の第３層ユニットセグメントおよびセグメント化制御情報の多重分離を行い、前記多重分離された複数の第３層ユニットセグメントを前記セグメント化制御情報と共に第３層の処理ユニットに転送するための前記第２層の処理ユニットと、
    前記データ送信ノードにフィードバックする状況通知を用いて自動再送要求（ＡＲＱ）を行い、前記多重分離された複数の第３層ユニットセグメントの並べ替えおよび前記多重分離された複数の第３層ユニットセグメントの第３層データユニットへの組立てを行うための前記第３層の処理ユニットと
    を含む、データ受信ノード。
11. 前記第３層の処理ユニットが、少なくとも１つの第３層ユニットセグメントが正しく受信されたか否かを示す前記状況通知を搬送する制御データを生成し、前記生成された状況通知を、前記無線インターフェース上で前記データ送信ノードに送信するために前記第２層の処理ユニットに提供するようにさらに構成されており、
    前記状況通知が、少なくとも１つの第３層データユニットについての肯定応答もしくは否定応答のうちの少なくとも１つ、および／または前記第３層データユニットの正しく受信されたセグメントもしくは欠落したセグメントの識別を含む、
    請求項１０に記載のデータ受信ノード。
12. 前記セグメント化制御情報が、前記第３層データユニット内の第３層ユニットセグメントのオフセットをバイト単位で示すセグメントオフセット、前記第３層データユニット内の前記第３層データユニットの前記第３層ユニットセグメントのシーケンス番号を示すセグメント番号および前記第３層ユニットセグメントの長さ、前記第３層ユニットセグメントの長さ、および前記第３層ユニットセグメントが前記第３層データユニット内の最後のセグメントであるか否かのインジケータのうちの少なくとも１つを含む、
    請求項１０または１１に記載のデータ受信ノード。
13. 通信システムにおいて無線インターフェース上でデータ受信ノードにデータを送信するための方法であって、
    前記データ受信ノードからフィードバックされた状況通知に従って自動再送要求（ＡＲＱ）再送信を行うことを含み、データへのセグメント化制御情報の追加を含む前記状況通知に含まれるセグメント長情報に基づいて再送信されるべき前記データを再セグメント化し、または再セグメント化しないための第３層の処理を行う工程と、
    前記第３層から、第３層データユニットを受信し、リソース割当に基づいて前記第３層データユニットをセグメント化し、該セグメント化によって分けられた前記第３層データユニットのそれぞれのセグメントと再セグメント化が適用されるべきである場合に変更される前記セグメント化制御情報とを含む複数の第２層データユニットを形成することを含む第２層の処理を行う工程と、
    前記第２層から、前記複数の前記第２層データユニットのうちの１つまたは複数を受信し、前記複数の前記第２層データユニットのうちの前記１つまたは複数をデータ送信に割り当てられたリソース上にマップすることを含む第１層の処理を行う工程と
    を含む、方法。
14. 通信システムにおいて無線インターフェース上でデータ受信ノードにデータを送信するための方法であって、
    前記データ受信ノードからフィードバックされた状況通知に従って自動再送要求（ＡＲＱ）再送信を行うことを含む第３層の処理と、
    前記第３層から、第３層データユニットを受信し、前記状況通知に従い、リソース割当に基づいて前記第３層データユニットをセグメント化し、該セグメント化によって分けられた前記第３層データユニットのそれぞれのセグメントを含む複数の第２層データユニットを形成することを含む第２層の処理と、
    前記第２層から、前記複数の前記第２層データユニットのうちの１つまたは複数を受信し、前記複数の前記第２層データユニットのうちの前記１つまたは複数をデータ送信に割り当てられたリソース上にマップすることを含む第１層の処理と
    を含む、方法。
15. 通信システムにおいて無線インターフェース上でデータ送信ノードからデータを受信するための方法であって、
    データ送信に割り当てられたリソースから複数の第２層データユニットのうちの１つまたは複数を逆マップすることを含み、前記複数の第２層データユニットのうちの前記逆マップされた１つまたは複数を第２層に提供するための第１層の処理と、
    前記複数の第２層データユニットのうちの前記１つまたは複数からの複数の第３層ユニットセグメントおよびセグメント化制御情報の多重分離を行い、前記多重分離された複数の第３層ユニットセグメントを前記セグメント化制御情報と共に第３層に転送することを含む前記第２層の処理と、
    前記データ送信ノードにフィードバックする状況通知を用いて自動再送要求（ＡＲＱ）を行い、前記多重分離された複数の第３層ユニットセグメントの並べ替えおよび前記多重分離された複数の第３層ユニットセグメントの第３層データユニットへの組立てを行うことを含む前記第３層の処理と
    を含む、方法。
    

Images