JP2018050137A - 通信装置、及び送信方法 - Google Patents

Abstract

【課題】無線通信システムで使用される通信装置において、データユニットの生成にかかる時間を短縮する。【解決手段】無線通信システムにおいて使用される通信装置において、他の通信装置に送信する第１データユニットを生成する第１生成部と、前記第１生成部により生成された第１データユニットに当該第１データユニットのサイズを示す値を付加し、当該第１データユニットと当該値とを有するペイロードを含む第２データユニットを生成する第２生成部と、前記第２データユニットを前記他の通信装置に送信する送信部とを備える。【選択図】図７

Description

本発明は、無線通信システムにおけるユーザ装置及び基地局等の通信装置に関連するものである。

現在、３ＧＰＰ（3rd Generation Partnership Project）において、第４世代の無線通信システムの一つであるＬＴＥ（Long Term Evolution）−Ａｄｖａｎｃｅｄの後継にあたる５Ｇと呼ばれる次世代のシステムの検討が進んでいる。５Ｇでは、主にｅＭＢＢ（extended Mobile Broadband）、ｍＭＴＣ(massive Machine Type Communication）、ＵＲＬＬＣ（Ultra Reliability and Low Latency Communication）の３つのユースケースが想定されている。

例えば、ＵＲＬＬＣは、低遅延及び高信頼性による無線通信を実現することを目的としている。ＵＲＬＬＣにおいて低遅延を実現するための具体策として、Ｓｈｏｒｔ ＴＴＩ長（サブフレーム長、サブフレーム間隔とも呼ばれる）の導入、パケット生成からデータ送信までの制御遅延の短縮化等が検討されている。

3GPP TS 36.321 V13.2.0 3GPP TS 36.322 V13.2.0 3GPP TS 36.323 V13.2.1 3GPP TS 36.300 V13.4.0

既存のＬＴＥにおいて、基地局（ｅＮＢ）とユーザ装置（ＵＥ）との間におけるＵ−Ｐｌａｎｅ（ユーザプレーン）の無線インタフェースプロトコルは、レイヤ１（ＰＨＹ）とレイヤ２とで構成されている。レイヤ２は、ＭＡＣ（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）（非特許文献１参照）、ＲＬＣ（Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ）（非特許文献２参照）、及びＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）（非特許文献３参照）の３つのサブレイヤから構成されている。なお、Ｃ−ＰｌａｎｅはＵ−Ｐｌａｎｅと同様のプロトコルと、レイヤ３であるＲＲＣとで構成される。

３ＧＰＰ標準化において、５Ｇのレイヤ２はＬＴＥにおける上記レイヤ２の構成をベースに検討されているが、現状のＬＴＥにおけるレイヤ２の制御においては、ＲＬＣ ＰＤＵ等のデータユニットのヘッダ算出等に時間がかかり、５Ｇで検討されているＴＴＩ等を想定した際に、ＲＬＣ ＰＤＵ等のデータユニットの生成を規定時間内に完了できない可能性があるという課題がある。なお、この課題は、ＲＬＣに限らない種々のレイヤで生じ得る課題である。

本発明は上記の点に鑑みてなされたものであり、無線通信システムで使用される通信装置において、データユニットの生成にかかる時間を短縮することを可能とする技術を提供することを目的とする。

なお、後述する第２の実施の形態において説明するように、第２の実施の形態に係る発明は、無線通信システムの通信装置において、所定のレイヤでの順序補正処理に起因する遅延を解消することを目的としている。

開示の技術によれば、無線通信システムにおいて使用される通信装置であって、
他の通信装置に送信する第１データユニットを生成する第１生成部と、
前記第１生成部により生成された第１データユニットに当該第１データユニットのサイズを示す値を付加し、当該第１データユニットと当該値とを有するペイロードを含む第２データユニットを生成する第２生成部と、
前記第２データユニットを前記他の通信装置に送信する送信部と
を備えることを特徴とする通信装置が提供される。

開示の技術によれば、無線通信システムで使用される通信装置において、データユニットの生成にかかる時間を短縮することを可能とする技術が提供される。

本発明の実施の形態における無線通信システムの構成図である。 ユーザ装置１０（基地局２０）におけるレイヤ２の構成例を示す図である。 ＬＴＥのデータフローの例を示す図である。 ＲＬＣ ＰＤＵの構成例を示す図である。 従来のＬＴＥにおけるＲＬＣ ＰＤＵの送信処理例を説明するための図である。 ５ＧにおけるＲＬＣ ＰＤＵの送信処理例を説明するための図である。 第１の実施の形態におけるＲＬＣ ＰＤＵの生成処理を説明するための図である。 第１の実施の形態におけるＲＬＣ ＰＤＵの生成処理を説明するための図である。 第１の実施の形態におけるＲＬＣ ＰＤＵの生成処理を説明するための図である。 第１の実施の形態におけるＲＬＣ ＰＤＵの生成処理を説明するための図である。 Ｒｅａｌｔｉｍｅ処理／Ｎｏｎ−ｒｅａｌｔｉｍｅ処理を説明するための図である。 Ｒｅａｌｔｉｍｅ処理／Ｎｏｎ−ｒｅａｌｔｉｍｅ処理を説明するための図である。 第１の実施の形態における変形例を説明するための図である。 第１の実施の形態における変形例を説明するための図である。 第２の実施の形態に対応する課題を説明するための図である。 第２の実施の形態におけるユーザ装置１０（基地局２０）の処理を説明するための図である。 第２の実施の形態における変形例を説明するための図である。 第２の実施の形態における変形例を説明するための図である。 第２の実施の形態における変形例を説明するための図である。 第２の実施の形態における変形例においてＤｕａｌ Ｃｏｎｎｅｃｔｉｖｉｔｙを適用する場合の動作を説明するための図である。 ユーザ装置１０の機能構成図である。（ａ）は全体を示し、（ｂ）は第１の実施の形態におけるレイヤ２処理部１０３の例を示し、（ｃ）は第２の実施の形態におけるレイヤ２処理部１０３の例を示す。 基地局２０の機能構成図である。（ａ）は全体を示し、（ｂ）は第１の実施の形態におけるレイヤ２処理部２０３の例を示し、（ｃ）は第２の実施の形態におけるレイヤ２処理部２０３の例を示す。 ユーザ装置１０及び基地局２０のハードウェア構成図である。

以下、図面を参照して本発明の実施の形態（本実施の形態）を説明する。なお、以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。

本実施の形態の無線通信システムは、少なくともＬＴＥの通信方式をサポートしていることを想定している。よって、無線通信システムが動作するにあたっては、適宜、ＬＴＥで規定された既存技術を使用できる。ただし、当該既存技術はＬＴＥに限られない。また、本明細書で使用する「ＬＴＥ」は、特に断らない限り、ＬＴＥ−Ａｄｖａｎｃｅｄ、及び、ＬＴＥ−Ａｄｖａｎｃｅｄ以降の方式を含む広い意味を有するものとする。また、本発明は、ＬＴＥ以外の通信方式にも適用可能である。

また、以下の第１及び第２の実施の形態では、既存のＬＴＥで使用されているＭＡＣ、ＲＬＣ、ＰＤＣＰ等の用語を使用しているが、これは便宜上のものであり、これらと同様の機能が他の名称で呼ばれてもよい。

また、本明細書における「データユニット」は、「パケット」、「フレーム」、「データグラム」等と呼ばれてもよい。以下で説明するＰＤＵ、ＳＤＵはいずれも「データユニット」の例である。

また、以下で説明する第１、第２の実施の形態では、特定のレイヤのデータユニットを対象としているが、これらは例であり、本発明は、第１、第２の実施の形態で説明したレイヤに限定されず、その他のレイヤにも適用可能である。

（システム全体構成）
図１に本実施の形態（第１、第２の実施の形態に共通）に係る無線通信システムの構成図を示す。本実施の形態に係る無線通信システムは、図１に示すように、ユーザ装置１０、及び基地局２０を含む。図１には、ユーザ装置１０、及び基地局２０が１つずつ示されているが、これは例であり、それぞれ複数であってもよい。また、以下で説明する動作は、基本的にユーザ装置１０の動作として説明するが、基地局２０でも同様の動作を行うことが可能である。そのことを表すために、以下では、"ユーザ装置１０（基地局２０）"等の記載を用いている。ユーザ装置１０と基地局２０とを総称して「通信装置」と称してもよい。

また、第１の実施の形態（変形例を含む）、又は、第２の実施の形態（変形例を含む）、又は、第１の実施の形態（変形例を含む）と第２の実施の形態（変形例を含む）の両方が、ユーザ装置間が基地局を介さずに直接通信を行うｓｉｄｅｌｉｎｋ通信に適用されてもよい。

（レイヤ２の構成例）
本実施の形態（第１、第２の実施の形態に共通）において着目しているレイヤ２における処理に関して、ユーザ装置１０（基地局２０）は、ＬＴＥで規定されているレイヤ２の動作をベースとして、以降で説明する処理を行うこととしていることから、まず、ユーザ装置１０（基地局２０）が備えるレイヤ２の基本的な機能構成を図２を参照して説明する。なお、ＰＤＣＰサブレイヤ（あるいはＰＤＣＰレイヤ）をＰＤＣＰエンティティ又はＰＤＣＰ処理部と称してもよい。ＲＬＣサブレイヤ（あるいはＲＬＣレイヤ）をＲＬＣエンティティ又はＲＬＣ処理部と称してもよい。ＭＡＣサブレイヤ（あるいはＭＡＣレイヤ）をＭＡＣエンティティ又はＭＡＣ処理部と称してもよい。

＜ＰＤＣＰ＞
Ｔｘで示される送信側（例：ユーザ装置１０から基地局２０への送信）において、ＰＤＣＰサブレイヤでは、ＩＰパケットのヘッダ圧縮処理（ＲＯＨＣ）と秘匿処理（ｓｅｃｕｒｉｔｙ）が実施され、ＲＬＣサブレイヤにＰＤＣＰ ＰＤＵが渡される。Ｒｘで示される受信側では、送信側に対応するヘッダ復元、秘匿解除、Ｉｎｔｅｇｒｉｔｙ ｃｈｅｃｋ等の処理が行われる。また、ハンドオーバ時には、送信側にて送達未確認のユーザデータを再送することでパケットロスを回避し、受信側にて重複検出と順序補正とを行う。

＜ＲＬＣ＞
ＲＬＣサブレイヤでは、ＡＭ（Ａｃｋｎｏｗｌｅｄｇｅｄ Ｍｏｄｅ）、ＵＭ（Ｕｎａｃｋｎｏｗｌｅｄｇｅｄ Ｍｏｄｅ）、ＴＭ（Ｔｒａｎｓｐａｒｅｎｔ Ｍｏｄｅ）の３モードがある。ＲＬＣ−ＡＭ／ＵＭの送信側では、ＭＡＣレイヤから通知されるＴＢ（トランスポートブロック）サイズに基づいて、ＰＤＣＰ ＰＤＵの切り出し（ｓｅｇｍｅｎｔａｔｉｏｎ）及び連結（ｃｏｎｃａｔｅｎａｔｉｏｎ）を行うことで、ＴＴＩ毎のＴＢサイズに見合ったＲＬＣ ＰＤＵを生成して、それをＭＡＣサブレイヤに渡す。受信側では、ＰＤＣＰ ＰＤＵの再構築を行う。

また、ＲＬＣ−ＡＭでは、受信側からの送達確認信号（ＳＴＡＴＵＳ ＰＤＵ）に基づいて、送信側がＲＬＣ ＰＤＵを再送するＡＲＱ制御が実施される。また、ＲＬＣ−ＡＭ／ＵＭの受信側では、更に重複検出と順序補正とが行われる。

＜ＭＡＣ＞
ＭＡＣサブレイヤでは共有チャネルリソースがスケジューリングされる。すなわち、下りリンクでは、基地局２０のスケジューラがどのユーザ装置に対するどのベアラのＲＬＣ ＰＤＵをＴＢに多重して送信するかを決定する。上りリンクでは、基地局２０のスケジューラが、どのユーザ装置にＰＵＳＣＨにてデータ送信させるかを決定し、ユーザ装置１０がどのベアラのＲＬＣ ＰＤＵをＴＢに多重するかを決定する。送信側のＭＡＣ ｅｎｔｉｔｙと受信側のＭＡＣ ｅｎｔｉｔｙとがＨＡＲＱを用いてＴＢを伝送し、受信側では、ＴＢからＲＬＣ ＰＤＵを抽出してＲＬＣ ｅｎｔｉｔｙに渡す。

図３にＰＤＣＰ、ＲＬＣ、ＭＡＣ、及びＰＨＹにおけるデータフロー例を示す。図３に示すとおり、送信側では上位レイヤから下位レイヤにＰＤＵが渡され、受信側では、下位レイヤから上位レイヤにＳＤＵが渡される。

以下、第１の実施の形態と第２の実施の形態を詳細に説明する。

（第１の実施の形態）
＜第１の実施の形態の課題について＞
まず、図４〜６を参照して第１の実施の形態における課題を詳細に説明する。

前述したように、ユーザ装置１０（基地局２０）のＲＬＣレイヤでは、送信側において、ＭＡＣレイヤから通知されるＴＢサイズに基づいて、ＲＬＣ ＳＤＵからのデータ切り出し（ｓｅｇｍｅｎｔａｔｉｏｎ）及びデータ連結（Ｃｏｎｃａｔｅｎａｔｉｏｎ）を行うことでＲＬＣ ＰＤＵを生成する。

図４にＲＬＣ ＰＤＵ（ここでは、ＲＬＣ−ＡＭのＰＤＵであるＡＭＤ ＰＤＵを示す）の例を示す（非特許文献２）。ヘッダにおけるＤ／ＣはＤａｔａ ｏｒ Ｃｏｎｔｒｏｌを意味し、本ＲＬＣ ＰＤＵがＤａｔａ ＰＤＵかＣｏｎｔｒｏｌ ＰＤＵかを示す。ＲＦはＲｅ−ｓｅｇｍｅｎｔａｔｉｏｎ Ｆｌａｇであり、本ＲＬＣ ＰＤＵがＡＭＤ ＰＤＵか、ＡＭＤ ＰＤＵ ｓｅｇｍｅｎｔかを示す。ＰはＰｏｌｌｉｎｇ ｂｉｔであり、ＳＴＡＴＵＳ ｒｅｐｏｒｔ要求の有無を表す。ＦＩはＦｒａｍｅ Ｉｎｆｏであり、Ｄａｔａの最初／最後のビットがＳＤＵの最初／最後かどうかを示す。ＥはＥｘｔｅｎｓｉｏｎ ｂｉｔであり、ＥとＬＩの組、又はＤａｔａのどちらが後続するのかを示す。ＳＮはＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒであり、各ＰＤＵに振られた通し番号である。

ＬＩは、Ｌｅｎｇｔｈ Ｉｎｄｉｃａｔｏｒであり、ｄａｔａフィールド（ペイロードと呼んでもよい）中での、ＲＬＣ ＳＤＵの境界を示す。つまり、ＬＩは、ｄａｔａフィールドにおける、対応するＲＬＣ ＳＤＵの長さ（データのサイズ）を示す。送信側のＲＬＣレイヤでは、ユーザ装置１０（基地局２０）は、Ｃｏｎｃａｔｅｎａｔｉｏｎを行う際に、受信側のＲＬＣレイヤで（連結された）ＲＬＣ ＳＤＵの境目がわかるように、当該ＬＩを用いて各ＲＬＣ ＳＤＵの長さをＲＬＣヘッダ内で通知することとしている。

すなわち、従来のＬＴＥにおいて、ＲＬＣレイヤにおけるＲＬＣ ＰＤＵ生成は、実際にリソース割当てが行われ、ＴＢサイズが決定された後でしか実施できない。より具体的な例を図５を参照して説明する。図５は従来のＬＴＥにおけるユーザ装置からのＲＬＣレイヤに着目したデータ送信の例を示している。図５に示すとおり、ユーザ装置が基地局からＵＬ ｇｒａｎｔを受信すると、ＵＥは、ＴＢサイズ決定等のＵＬ ｇｒａｎｔに対する処理を行い（ステップＳ１）、ＲＬＣ ＳＤＵのｃｏｎｃａｔｅｎａｔｉｏｎ／ｓｅｇｍｅｎｔａｔｉｏｎを行う（ステップＳ２）。続いてユーザ装置は、ＲＬＣ ＰＤＵのヘッダの算出処理（ＬＩの算出等）を行って（ステップＳ３）、ＲＬＣ ＰＤＵの送信処理を行う（ステップＳ４）。なお、既存のＬＴＥでは、ユーザ装置は、ＵＬ ｇｒａｎｔを受信してから４ｍｓ（４ＴＴＩ）後にデータ送信（ＰＵＳＣＨ送信）を行うことが規定されている。

次に、５Ｇにおいて想定されているように、ＴＴＩが短縮された場合におけるユーザ装置からのデータ送信の例を図６を参照して説明する。図６の例では、ＵＬ ｇｒａｎｔを受信してから１ｍｓ後にデータ送信（ＰＵＳＣＨ送信）を行うことを想定している。図６に示すように、ＵＬ ｇｒａｎｔに対する処理（ステップＳ１１）、ｃｏｎｃａｔｅｎａｔｉｏｎ／ｓｅｇｍｅｎｔａｔｉｏｎ（ステップＳ１２）、ＲＬＣ ＰＤＵのヘッダの算出処理（ステップＳ１３）、及びＲＬＣ ＰＤＵの送信処理を行う（ステップＳ１４）のに時間がかかり、規定時間内にＲＬＣ ＰＤＵの生成、送信を完了できない可能性がある。

すなわち、５ＧでＴＴＩが短縮され、ビットレートが上がると、データ処理（ＲＬＣ ＰＤＵ生成）が間に合わない可能性があるという課題がある。ユーザ装置の処理能力を向上させればこの課題を解決できる可能性があるが、ユーザ装置が複雑になりコスト高となってしまい、好ましい解決策ではない。

＜第１の実施の形態における処理内容＞
上記の課題を解決するために第１の実施の形態では、ＲＬＣ ＰＤＵのフォーマットを、既存のＲＬＣ ＰＤＵのフォーマットから変更し、ＲＬＣ ＳＤＵの長さをＲＬＣ ＰＤＵのヘッダ以外の領域（つまり、ペイロード内）で通知することとしている。

より具体的には、ユーザ装置１０（基地局２０）は、データを送信する場合に、ＲＬＣレイヤにおいて、ＰＤＣＰレイヤからＲＬＣ ＳＤＵを受信すると、ＲＬＣ ＰＤＵのサイズが決定されているか否かに関わらずに（つまり、ＴＢサイズが決定されているか否かに関わらずに）、ＲＬＣ ＳＤＵの長さ（サイズ）であるＬＩフィールドの値を算出する。このような処理により、ユーザ装置１０（基地局２０）は、ＬＩフィールドの値の算出を、ＴＢサイズが決定される前（ユーザ装置１０であればＵＬ ｇｒａｎｔを受信する前）にオフラインで行うことができる。その結果、ＲＬＣ ＰＤＵ生成に際し、計算量が削減されるため、例えば、図６に示した例において、装置の複雑化を抑えつつ、規定時間内でのデータ送信を行うことが可能となる。

ＬＩフィールドの挿入位置については、ＲＬＣヘッダ以外の箇所であればよく、例えば、ＲＬＣ ＳＤＵの直前である。また、ＬＩフィールドの挿入位置は、ＲＬＣ ＳＤＵの直後でもよい。

図７を参照して、ユーザ装置１０におけるＲＬＣ ＰＤＵの生成処理の例を説明する。図７に示す例において、ユーザ装置１０は、ＲＬＣ ＳＤＵが生成される度に、当該ＲＬＣ ＳＤＵに対応するＬＩフィールドの値を計算し、ＬＩフィールドの値を当該ＲＬＣ ＳＤＵに付加する。図７の例では、１、２、３に示す順番で、ＲＬＣ ＳＤＵのＬＩフィールドの値の算出及び付加が行われることが示されている。なお、ＬＩフィールドの値がセットされたＬＩフィールドを「ＬＩ」と称してもよい。

図７の例では、例えば、ＬＩを付加したＲＬＣ ＳＤＵ（ＬＩ＋ＲＬＣ ＳＤＵ）をバッファに格納しておき、ＲＬＣ ＰＤＵの長さ（ＲＬＣ ＰＤＵのペイロードの長さＡ）が決まった後に、各「ＬＩ＋ＲＬＣ ＳＤＵ」を連結している。図７の例では、ＲＬＣ ＰＤＵのペイロードの長さＡが、ちょうど３つの「ＬＩ＋ＲＬＣ ＳＤＵ」を連結した長さに等しい例を示している。ただし、より一般的には、ＲＬＣ ＰＤＵのペイロードの長さは、整数個の「ＬＩ＋ＲＬＣ ＳＤＵ」を連結した長さとは一致せず、例えば、図８に示すように、１の「ＬＩ＋ＲＬＣ ＳＤＵ」における一部（ＬＩを含まない）、２、３の「ＬＩ＋ＲＬＣ ＳＤＵ」、及び４の「ＬＩ＋ＲＬＣ ＳＤＵ」の一部（ＬＩを含む）がＲＬＣ ＰＤＵのペイロードに格納される。

上記の例では、ＬＩとＲＬＣ ＳＤＵを事前に（ＲＬＣ ＰＤＵのペイロードの長さが決定される前に）連結することとしているが、ＬＩとＲＬＣ ＳＤＵをＲＬＣ ＰＤＵの長さが決定された後に連結することとしてもよい。

また、「ＬＩ＋ＲＬＣ ＳＤＵ」を事前に（ＲＬＣ ＰＤＵのペイロードの長さが決定される前に）連結することとしてもよい。この場合の処理の例を図９を参照して説明する。この場合、ユーザ装置１０（基地局２０）は、ＲＬＣ ＳＤＵが生成される度にＬＩを算出し、当該ＬＩをＲＬＣ ＳＤＵの先頭に付加するとともに、「ＬＩ＋ＲＬＣ ＳＤＵ」を、直前に作成した「ＬＩ＋ＲＬＣ ＳＤＵ」に連結する。連結されたデータ（ビット列）は、バッファに格納される。そして、ＲＬＣ ＰＤＵのペイロードの長さが決定されたときに、ユーザ装置１０（基地局２０）は、ビット列をＲＬＣ ＰＤＵのペイロードに格納する。

図９の例では、ユーザ装置１０（基地局２０）は、ＲＬＣ ＰＤＵのペイロードの長さに合わせて、１で示す「ＬＩ＋ＲＬＣ ＳＤＵ」の一部、２、３で示す「ＬＩ＋ＲＬＣ ＳＤＵ」、及び、４で示す「ＬＩ＋ＲＬＣ ＳＤＵ」の一部を連結したビット列を、バッファに格納ざれたビット列から切り出して、ＲＬＣ ＰＤＵのペイロードに格納する。上記の切り出しの処理をｓｅｇｍｅｎｔａｔｉｏｎと呼んでもよい。

すなわち、従来のＣｏｎｃａｔｅｎａｔｉｏｎ処理はＴＢサイズ決定後にしか実施できなかったが、本実施の形態に係るＲＬＣ ＰＤＵのフォーマットを用いることで、Ｃｏｎｃａｔｅｎａｔｉｏｎについてもオフラインで（ＴＢサイズ決定前に）実施することが可能となる。

このためＣｏｎｃａｔｅｎａｔｉｏｎは、ＰＤＣＰレイヤで実施されてもよい。この場合の処理は、例えば、図９における「ＲＬＣ ＳＤＵ」を「ＰＤＣＰ ＰＤＵ」に置き換えた処理に相当する。

上述した例では、ＬＩをＲＬＣ ＳＤＵの先頭（直前）に付加したが、図１０に示すように、ＬＩをＲＬＣ ＳＤＵの末尾（直後）に付加することとしてもよい。なお、ＬＩフィールドの長さについては予め定めた長さとしてよい。

ユーザ装置１０（基地局２０）において、ＴＢ決定後にしか実施できない処理をＲｅａｌｔｉｍｅ処理（ＲＴ処理）と呼び、ＴＢサイズ決定前に実施可能な処理をＮｏｎ−ｒｅａｌｔｉｍｅ処理（ＲＴ処理）と呼ぶ。

図１１は、従来のＬＴＥのレイヤ２におけるＮＲ処理とＲＴ処理の区分を示し、図１２は、本実施の形態におけるレイヤ２におけるＮＲ処理とＲＴ処理の区分（例）を示す。図１１に示すように、従来のＬＴＥでは、ＣｏｎｃａｔｅｎａｔｉｏｎとＳｅｇｍｅｎｔａｔｉｏｎは、ＴＢ決定後にしか実施できない。一方、図１２に示すように、本実施の形態では、既に説明したように、Ｃｏｎｃａｔｅｎａｔｉｏｎ処理をＴＢサイズ決定前に実施することができる。

＜受信側の処理について＞
本実施の形態におけるＲＬＣレイヤの受信側の処理を説明する。ユーザ装置１０（基地局２０）は、ＲＬＣ ＰＤＵを受信した場合、ＲＬＣヘッダにおけるＳＮが連続していれば、ＰＤＵのペイロード部分にあるＬＩ（ＲＬＣ ＳＤＵ長）を観測して、対応するＲＬＣ ＳＤＵのデータ（ｂｙｔｅ ｓｅｇｍｅｎｔ）を取得してＲＬＣ ＳＤＵを再構築する。例えば、ユーザ装置１０（基地局２０）が、図７に示すＲＬＣ ＰＤＵを受信する場合、ユーザ装置１０（基地局２０）は、まず、最初のＬＩ（ＲＬＣヘッダに隣接するＬＩ）に基づき１で示すＲＬＣ ＳＤＵを取得し、次のＬＩに基づき２で示すＲＬＣ ＳＤＵを取得し、更に次のＬＩに基づき３で示すＲＬＣ ＳＤＵを取得する。

＜その他の例＞
ユーザ装置１０は、ネットワーク（つまり基地局２０）から、第１の実施の形態（後述する変形例を含む）で説明する機能を適用することを指示する指示情報を受信した場合にのみ、第１の実施の形態（変形例を含む）で説明する機能を適用することとしてもよいし、常に当該機能を適用してもよい。

また、第１の実施の形態（変形例を含む）で説明する機能は、ユーザ装置１０（基地局２０）において、ＲＬＣ−ＡＭのみに適用されてもよい。

また、第１の実施の形態（変形例を含む）で説明する機能は、特定のユーザ装置にのみ適用されてもよい。この場合、例えば、当該機能に対応しているユーザ装置は、当該機能に対応していることを示す能力情報（ｃａｐａｂｉｌｉｔｙ）をＮＷ（基地局２０）へ通知する。また、当該特定のユーザ装置は、例えば、特定のサービスを提供するユーザ装置である。当該特定のサービスは、例えば、短いＴＴＩを用いるサービス、又は、期待されるスループット（Ｔｐｕｔ）が所定値を超えるサービス、又は、これら両方である。また、当該特定のサービスは、特定のベアラ（例：Ｂｅｓｔ ｅｆｆｏｒｔ）を設定するサービスであってもよいし、広帯域での通信サービス（例：ＣＡ及び／又はＤＣ等が設定されていること）であってもよい。

また、第１の実施の形態（変形例を含む）で説明する機能は、下りリンクの通信と、上りリンクの通信と、ユーザ装置間が基地局を介さずに直接通信を行うｓｉｄｅｌｉｎｋ通信とのそれぞれにおいて、適用されるか否かが決められてもよい。つまり、下りリンクの通信と、上りリンクの通信と、ｓｉｄｅｌｉｎｋ通信との間で、第１の実施の形態（変形例を含む）で説明する機能が適用されるか否かが異なっていても良い。

＜第１の実施の形態における変形例＞
以下、第１の実施の形態における変形例を説明する。既に説明したとおり、第１の実施の形態ではＲＬＣ ＳＤＵ長（ＬＩ）をＲＬＣヘッダではない領域へ移動させる。このようにした場合、受信側で以下で説明するような課題が発生し得る。なお、以下の変形例を実施しない場合でも、第１の実施の形態により、データユニットの生成時間短縮という効果を得られる。

通常、ＲＬＣレイヤ（ここではＲＬＣ−ＡＭを想定している）ではｉｎ−ｓｅｑｕｅｎｃｅ ｄｅｌｉｖｅｒｙが保証される（ＳＮが抜けなく受信される）ため、仮に受信側でＳＮに抜けがあった（途中のＲＬＣ ＰＤＵを受信できていない）場合、当該抜け部分が受信できるまで、後続のＲＬＣ ＰＤＵからＲＬＣ ＳＤＵを構築しない。つまり、受信側は抜けた部分の再送を送信側に要求し続ける。

一方、ハンドオーバもしくは再接続時のようにＲＬＣレイヤが一旦再構築される（初期化／Ｆｌｕｓｈされる）ケース（ＲＬＣ ｒｅ−ｅｓｔａｂｌｉｓｈｍｅｎｔ）においては、受信側において、受信したデータがｏｕｔ−ｏｆ−ｏｒｄｅｒであっても、再構築可能な場合には、ＲＬＣ ＰＤＵからＲＬＣ ＳＤＵを再構築して、当該ＲＬＣ ＳＤＵをＰＤＣＰレイヤへ送出する。これによって、ハンドオーバ／再接続後に送信側から再送されるデータ量を抑えることができ、リソース利用効率を高めることが可能となる。

従来のＲＬＣ ＰＤＵフォーマットでは、ＲＬＣ ＰＤＵに抜けがあった場合においても、ヘッダにＬＩがある（ＲＬＣ ＳＤＵの境目の情報がある）ため、ペイロードからＲＬＣ ＳＤＵを可能な限り再構築することが可能である。この場合の例を図１３の左側に示す。図１３（左側）に示すように、受信側は、ＲＬＣ ＰＤＵに抜けがある場合でも、受信したＲＬＣ ＰＤＵのＲＬＣヘッダにおけるＬＩの情報から、ペイロードの中の２で示すＲＬＣ ＳＤＵのデータ位置を把握できるので、２で示すＲＬＣ ＳＤＵを取得できる。

一方、第１の実施の形態におけるフォーマットでは、ＬＩを含むＲＬＣ ＰＤＵが抜けてしまっていると、ペイロード内でどこがＲＬＣ ＳＤＵの境目であるかが解らず、ＲＬＣ ｒｅ−ｅｓｔａｂｌｉｓｈｍｅｎｔ時にＲＬＣ ＳＤＵを再構築することができない。この場合の例を図１３の右側に示す。図１３（右側）に示すように、受信側では、１で示すＲＬＣ ＳＤＵのＬＩを含むＲＬＣ ＰＤＵを受信せず、２で示すＲＬＣ ＳＤＵのＬＩを含むＲＬＣ ＰＤＵを受信する。この場合、受信側は、受信したＲＬＣ ＰＤＵのペイロードにおけるＲＬＣ ＳＤＵの境目（２で示すＲＬＣ ＳＤＵの開始位置）を把握できないので、受信したＲＬＣ ＰＤＵの中に２で示すＲＬＣ ＳＤＵが存在する場合でも、それを取得することができない。

そこで、本変形例では、ＲＬＣ ＰＤＵにおいて、ＲＬＣ ＳＤＵの境目の情報を通知する。より具体的には、図１４に示すように、ユーザ装置１０（基地局２０）は、ＲＬＣ ＰＤＵの生成の際に、ＲＬＣヘッダの末尾から、ＲＬＣヘッダから見て最も近いＬＩフィールドの開始（ｏｃｔｅｔ）までの長さ（Ｌｅｎｇｔｈ ｏｆｆｓｅｔ）をＲＬＣヘッダに含める。また、ユーザ装置１０（基地局２０）は、ＲＬＣ ＰＤＵの生成の際に、ＲＬＣヘッダの末尾から、ＲＬＣヘッダから見て最も近いＲＬＣ ＳＤＵの先頭（最初のｂｙｔｅ ｓｅｇｍｅｎｔ）までの長さ（Ｌｅｎｇｔｈ ｏｆｆｓｅｔ）をＲＬＣヘッダに含めることとしてもよい。いずれの場合も、Ｌｅｎｇｔｈ ｏｆｆｓｅｔは、ＲＬＣ ＳＤＵの位置に対応する情報である。

受信側においては、ユーザ装置１０（基地局２０）は、ＲＬＣ ＰＤＵの抜けがある場合でも、ペイロード内のどこにＲＬＣ ＳＤＵを構成するデータ（ｂｙｔｅ ｓｅｇｍｅｎｔ）があるかを把握可能である。例えば、図１３の右側のケースにおいて、受信側のユーザ装置１０（基地局２０）は、受信したＲＬＣ ＰＤＵのヘッダにおけるＬｅｎｇｔｈ ｏｆｆｓｅｔに基づき、２で示すＲＬＣ ＳＤＵを取得することができる。

＜変形例における特殊ケースのハンドリングについて＞
ペイロードの先頭のデータ（ｂｙｔｅ ｓｅｇｍｅｎｔ）がＬＩフィールドの先頭（ｏｃｔｅｔ）に対応する場合、すなわち、ＲＬＣ ＰＤＵのペイロード（データフィールド）の先頭から、「ＬＩ＋ＲＬＣ ＳＤＵ」の先頭が開始する場合（例：図７）には、Ｌｅｎｇｔｈ ｏｆｆｓｅｔ＝０としてもよいし、Ｌｅｎｇｔｈ ｏｆｆｓｅｔのフィールド自体をＲＬＣヘッダに挿入しないこととしてもよい。また、ＲＬＣヘッダの中にＬｅｎｇｔｈ ｏｆｆｓｅｔのフィールドの有無を示すｆｌａｇを挿入してもよい。

ＲＬＣペイロード内に、ＲＬＣ ＳＤＵの境目が無い場合には、例えば、Ｌｅｎｇｔｈ ｏｆｆｓｅｔ＝ペイロード長＋１としてもよいし、Ｌｅｎｇｔｈ ｏｆｆｓｅｔのフィールド自体をＲＬＣヘッダに挿入しないこととしてもよい。また、ＲＬＣヘッダの中にＬｅｎｇｔｈ ｏｆｆｓｅｔのフィールドの有無を示すｆｌａｇを挿入してもよい。

（第２の実施の形態）
以下、第２の実施の形態を説明する。以下で説明する第２の実施の形態における機能は、これまでに説明した第１の実施の形態の機能を適用した上で適用してもよいし、第１の実施の形態の機能とは独立に、例えば、従来のＬＴＥのレイヤ２の機能に対して適用されてもよい。

＜第２の実施の形態における課題について＞
既に説明したように、ＲＬＣレイヤでは通常ｉｎ−ｓｅｑｕｅｎｃｅ ｄｅｌｉｖｅｒｙ（ＲＬＣ ＰＤＵのＳＮの順序に従った転送）を保証するため、抜けたＲＬＣ ＰＤＵが存在する場合には、ｏｕｔ−ｏｆ−ｏｒｄｅｒのＲＬＣ ＰＤＵ（ＳＮは新しいが、先に受信完了したＲＬＣ ＰＤＵ）はＲＬＣレイヤでバッファに格納される。

このため、受信側では、抜けたＲＬＣ ＰＤＵが受信されると、その時点でやっとＲＬＣ ＳＤＵを組み上げてＰＤＣＰレイヤの受信処理（秘匿解除処理等）を行うことが可能となる。しかし、ＰＤＣＰレイヤの処理は比較的重い処理であるため、多数のＲＬＣ ＰＤＵがｒｅｏｒｄｅｒｉｎｇ待ちとなっていると、所定時間内にデータを上位レイヤへ送出することができず、Ｅ２Ｅ（ｅｎｄ ｔｏ ｅｎｄ）遅延が伸びてしまうという課題がある。すなわち。従来のＬＴＥでは、ＲＬＣレイヤのＲｅｏｒｄｅｒｉｎｇ（順序補正）遅延によって、Ｕ−ｐｌａｎｅの追加遅延が発生するという課題がある。第２の実施の形態に係る技術は、この課題を解決するための技術であり、当該技術は、無線通信システムの通信装置において、所定のレイヤでの順序補正処理に起因する遅延を解消することを可能とすることを目的とした技術である。

従来のＬＴＥにおけるこの課題が発生する状況の一例を図１５に示している。図１５に示す例では、受信側のＲＬＣレイヤにおいて、ＳＮ＝１のＲＬＣ ＰＤＵを受信できておらず、それ以降のＳＮのＲＬＣ ＰＤＵはバッファリングされる。

＜第２の実施の形態における処理内容について＞
上記の課題を解決するために、第２の実施の形態においては、ＲＬＣ ｒｅ−ｅｓｔａｂｌｉｓｈｍｅｎｔ手順が起動されていない場合でも、受信側のユーザ装置１０（基地局２０）は、ＲＬＣレイヤにおいて、受信したＲＬＣ ＰＤＵから、再構築が可能なＲＬＣ ＳＤＵ（ｏｒその一部）を再構築する。再構築の方法自体は、例えば、図１３の左側における方法（従来のＬＴＥ）、又は、図１４のＬｅｎｇｔｈ ｏｆｆｓｅｔを備える場合において、当該Ｌｅｎｇｔｈ ｏｆｆｓｅｔを用いる方法（第１の実施の形態）を使用することができる。

一例を図１６を参照して説明する。図１６に示す例において、受信側のユーザ装置１０（基地局２０）は、ＳＮ＝１のＲＬＣ ＰＤＵを受信せずに、ＳＮ＝２、３のＲＬＣ ＰＤＵを受信する。第２の実施の形態では、ＲＬＣ ｒｅ−ｅｓｔａｂｌｉｓｈｍｅｎｔ手順が起動されているか否かに関わらずに、ユーザ装置１０（又は基地局２０）は、ＳＮ＝１のＲＬＣ ＰＤＵを受信しないまま、ＳＮ＝２、３のＲＬＣ ＰＤＵの各々からＲＬＣ ＳＤＵを取得し、ＰＤＣＰレイヤに渡す。また、その後、ユーザ装置１０（又は基地局２０）がＳＮ＝１のＲＬＣ ＰＤＵを受信した場合には、ＳＮ＝１のＲＬＣ ＰＤＵからＲＬＣ ＳＤＵを取得し、ＰＤＣＰレイヤに渡す。

ＰＤＣＰレイヤに渡すＲＬＣ ＳＤＵは、ＲＬＣ ＳＤＵ全体であってもよいし、ＲＬＣ ＰＤＵのペイロードにおける先頭側（又は末尾側）から取得される、ＲＬＣ ＳＤＵの一部であってもよい（例：図８、図９）。

上記のような処理により、ｒｅｏｒｄｅｒｉｎｇ待ちのＲＬＣ ＰＤＵのデータ（例：図１６におけるＳＮ＝２、３のＲＬＣ ＰＤＵ）については、抜けＲＬＣ ＰＤＵ（例：図１６におけるＳＮ＝１のＲＬＣ ＰＤＵ）が受信される前でもＰＤＣＰレイヤの秘匿解除処理を実施することができ、抜けＲＬＣ ＰＤＵを受信した時点で、より遅延なく上位レイヤへＰＤＣＰ ＳＤＵを送出することができる。つまり、順序補正処理に起因する遅延を解消できる。

＜第２の実施の形態における変形例＞
上述した処理において、ＰＤＣＰレイヤとしてはｏｕｔ−ｏｆ−ｏｒｄｅｒのＰＤＣＰ ＰＤＵ（或いは、その一部）が未だＲＬＣ／ＭＡＣレイヤで再送中なのか、送信側で既に破棄されたのかを判別することができず、受信側において、（上位レイヤでの）送信側でのパケットロスの検出が遅延する可能性がある（ＴＣＰ ｗｉｎｄｏｗの縮退が遅延する）という課題がある。

この課題を図１７、図１８を参照して説明する。図１７は、従来のＬＴＥにおけるＰＤＣＰレイヤとＲＬＣレイヤの送受信動作を示し、図１８は、上述した第２の実施の形態の処理を行う場合におけるＰＤＣＰレイヤとＲＬＣレイヤの送受信動作を示す。

図１７に示すように、従来のＬＴＥにおいて、送信側のＰＤＣＰレイヤでＳＮ＝０のＰＤＣＰ ＰＤＵが破棄され、ＳＮ＝１、２のＰＤＣＰ ＰＤＵが、ＳＮ＝０、１、２のＲＬＣ ＰＤＵにより受信側に送信される。受信側のＲＬＣレイヤでは、ＲＬＣ ＰＤＵのＳＮの順序を保証して、ＰＤＣＰレイヤへのＲＬＣ ＳＤＵの転送を行う。図１７の例では、受信側のＲＬＣレイヤでは、送信側が送信した順番に、抜けなくＲＬＣ ＰＤＵを受信し、ＰＤＣＰレイヤに対し、取得したＲＬＣ ＳＤＵを渡す。ＰＤＣＰレイヤでは、次にＳＮ＝０のＰＤＣＰ ＰＤＵを期待していたが、ＳＮ＝０のＰＤＣＰ ＰＤＵを受信することなく、ＳＮ＝１のＰＤＣＰ ＰＤＵが受信されたと判断される。つまり、この場合、受信側のＰＤＣＰレイヤにおいて、「ＰＤＣＰ ＳＮ＝０のＰＤＣＰ ＰＤＵは送信側で無線での送信はされずに破棄された」と暗黙的に判定可能である。

第２の実施の形態に係る処理を行う場合を図１８を参照して説明する。図１８のケース１の場合、送信側のＰＤＣＰレイヤにおいてＳＮ＝０のＰＤＣＰ ＰＤＵが破棄され、ＳＮ＝１のＰＤＣＰ ＰＤＵが、ＳＮ＝０のＲＬＣ ＰＤＵにより受信側に送信される。受信側では、ＳＮ＝０のＲＬＣ ＰＤＵを受信し、ＰＤＣＰレイヤでは、ＳＮ＝０のＰＤＣＰ ＰＤＵを期待していたが、ＳＮ＝１のＰＤＣＰ ＰＤＵを受信する。

図１８に示すケース２の場合において、送信側は、送信したＳＮ＝０のＲＬＣ ＰＤＵの送達を確認できないため（ＳＮ＝０のＲＬＣ ＰＤＵが受信側に届いていないため）、ＳＮ＝０のＲＬＣ ＰＤＵの再送を行っている。一方、ＳＮ＝１のＲＬＣ ＰＤＵは受信側に届く。受信側では、ＳＮ＝０のＲＬＣ ＰＤＵを受信していないが、第２の実施の形態では、先に受信したＳＮ＝１のＲＬＣ ＰＤＵからＲＬＣ ＳＤＵ（ＳＮ＝１のＰＤＣＰ ＰＤＵ）を取得し、ＰＤＣＰレイヤに渡す。

上記の状況において、受信側のＰＤＣＰレイヤは、ケース１とケース２を区別できず、送信側で破棄されたか、或いは、無線で再送中かを判定できない。よって、受信側において、（上位レイヤでの）送信側でのパケットロスの検出が遅延する可能性があるという課題がある。

＜第２の実施の形態の変形例における処理内容＞
そこで、第２の実施の形態の変形例では、受信側のユーザ装置１０（基地局２０）において、ＲＬＣレイヤからＰＤＣＰレイヤへＰＤＣＰ ＰＤＵ（或いは、その一部）を送出する際に、ＲＬＣレイヤからＰＤＣＰレイヤへ、未だ受信が期待されるデータがあるか否かを通知する。「ＲＬＣレイヤからＰＤＣＰレイヤへＰＤＣＰ ＰＤＵ（或いは、その一部）を送出する際」とは、例えば、ＰＤＣＰ ＰＤＵ（或いは、その一部）とともに、未だ受信が期待されるデータがあるか否かを示す情報を通知することである。

図１８に示すケース１及びケース２における変形例の動作を図１９に示す。図１９に示すように、ケース１においては、受信側のユーザ装置１０（基地局２０）は、ＲＬＣレイヤにおいてＲＬＣ ＰＤＵを正しい順番で受信するので、当該正しく受信したＲＬＣ ＰＤＵから取得するＲＬＣ ＳＤＵ（＝ＰＤＣＰ ＰＤＵ）をＲＬＣレイヤからＰＤＣＰレイヤに渡す際に、当該ＲＬＣ ＳＤＵを運んだＲＬＣ ＰＤＵは正しい順番で受信できたことを示す情報をＰＤＣＰレイヤに通知する。ＰＤＣＰレイヤにおいては、当該通知により、ＳＮ＝０のＰＤＣＰ ＰＤＵの抜けを検知するが、当該ＰＤＵは送信側で破棄されたと判定することができる。

ケース２では、受信側のユーザ装置１０（基地局２０）は、ＲＬＣレイヤにおいて、ＳＮ＝０のＲＬＣ ＰＤＵが抜けていることを検知する。そして、受信側のユーザ装置１０（基地局２０）は、受信したＳＮ＝１のＲＬＣ ＰＤＵから取得したＲＬＣ ＳＤＵ（＝ＰＤＣＰ ＰＤＵ）をＲＬＣレイヤからＰＤＣＰレイヤに渡す際に、再送中の古いデータがあることを示す情報をＰＤＣＰレイヤに通知する。当該情報は、ＳＮ＝０のＲＬＣ ＰＤＵが未受信であることを示す情報であってもよい。ＰＤＣＰレイヤにおいて、当該通知により、ＳＮ＝０のＰＤＣＰ ＰＤＵは未だ無線で送信中であると判定できる。

変形例における上述した通知（これを便宜上、受信状況通知と呼ぶ）により、受信側のＰＤＣＰレイヤは送信側でのパケットロスをいち早く検出することが可能となる。

当該受信状況通知はＲＬＣレイヤからのデータ（ＰＤＣＰ ＰＤＵ）送出に際して、逐一実施されてもよいし（例：ＰＤＣＰ ＰＤＵ単位）、未だ受信が期待されるデータがある場合（ｏｒ無い場合）にのみ実施されてもよい。

受信状況通知に際しては、ＲＬＣレイヤでＲｅｏｒｄｅｒｉｎｇ待ちとなっているＲＬＣ ＰＤＵの状況が併せて報告されてもよい。つまり、図１９のケース２の例であれば、ＳＮ＝１のＲＬＣ ＰＤＵに関する状況を報告する。報告の内容としては、例えば、ｒｅｏｒｄｅｒｉｎｇ待ちＲＬＣ ＰＤＵデータ総量、ＰＤＵ数、ＲＬＣ ＡＣＫ／ＮＡＣＫのフィードバック状況、ｒｅｏｒｄｅｒｉｎｇ待ちとなっているＲＬＣ ＰＤＵの内の最古のＳＮ、Ｒｅｏｒｄｅｒｉｎｇ待ち時間等がある。これらの全部が報告されてもよいし、これらのうちの一部（１つ又は複数）が報告されてもよい。

もしくは、ＲＬＣレイヤで抜けているＲＬＣ ＰＤＵの情報が受信状況通知と併せて報告されてもよい。図１９のケース２の例であれば、ＳＮ＝０のＲＬＣ ＰＤＵに関する情報を報告する。報告の内容としては、例えば、抜けているＲＬＣ ＰＤＵの個数、ＲＬＣ ＡＣＫ／ＮＡＣＫのフィードバック状況等である。これらの全部が報告されてもよいし、これらのうちの一部（１つ又は複数）が報告されてもよい。

また、受信側のユーザ装置１０（基地局２０）において、ＲＬＣ（／ＰＤＣＰ）がｒｅ−ｅｓｔａｂｌｉｓｈｍｅｎｔされる場合には、当該受信状況通知を実施しないこととしてもよい。このケースでは、ＲＬＣレイヤがｏｕｔ−ｏｆ−ｏｒｄｅｒのＲＬＣ ＳＤＵをＰＤＣＰレイヤへ送出するはずであるからである。

なお、本実施の形態においては、既存のＬＴＥと同様に、ＰＤＣＰレイヤにおいてＣＯＵＮＴ値（Ｈｙｐｅｒ ｆｒａｍｅ ｎｕｍｂｅｒ＋ＰＤＣＰ ＳＮ）を用いた秘匿処理を行っている。Ｈｙｐｅｒ ｆｒａｍｅ ｎｕｍｂｅｒ（ＨＦＮ）は、ＰＤＣＰ ＳＮが周回する度にインクリメントされる。受信側は、受信したＰＤＣＰ ＰＤＵのヘッダに含まれるＰＤＣＰ ＳＮからＨＦＮを推定する。

ここで、受信側のユーザ装置１０（基地局２０）において、受信状況通知の実施を、ＰＤＣＰ ＰＤＵのヘッダにおけるＳＮ長が所定値以上の場合に限って行うこととしてもよい。

具体的には、例えば、ＳＮ長がＬＴＥで採用された１５ｂｉｔ以上又は１８ｂｉｔ以上である場合、或いは、ＣＯＵＮＴ値（３２ｂｉｔ）がヘッダ内に含まれる場合に限定して受信状況通知の実施を行うこととしてもよい。

上記のように、ＰＤＣＰレイヤでは、ＰＤＣＰ ＰＤＵのｄｅｃｉｐｈｅｒｉｎｇ処理に用いるＰＤＣＰ Ｈｙｐｅｒ Ｆｒａｍｅ Ｎｕｍｂｅｒを、受信したＰＤＣＰ ＰＤＵのＳＮを見ながら、インクリメントすべきかを判定しているが、第２の実施の形態においては、ＰＤＣＰレイヤが受信を期待するＳＮよりも大きくとんだＳＮを受信し得るので、あまりに短いＳＮの場合には、ＰＤＣＰレイヤで誤ったＨｙｐｅｒ Ｆｒａｍｅ Ｎｕｍｂｅｒを推定してしまう可能性がある。そのため、受信状況通知の実施を、ＰＤＣＰ ＰＤＵのヘッダにおけるＳＮ長が所定値以上の場合に限って行うこととしてよい。このような限定を行うことで、ＰＤＣＰレイヤで誤ったＨｙｐｅｒ Ｆｒａｍｅ Ｎｕｍｂｅｒを推定してしまう可能性を削減できる。

＜その他の例＞
ユーザ装置１０は、ネットワーク（つまり基地局２０）から、第２の実施の形態（変形例を含む）で説明する機能を適用することを指示する指示情報を受信した場合にのみ、第２の実施の形態（変形例を含む）で説明する機能を適用することしてもよいし、常に当該機能を適用してもよい。

また、第２の実施の形態（変形例を含む）で説明する機能は、ユーザ装置１０（基地局２０）において、ＲＬＣ−ＡＭのみに適用されてもよい。

また、第２の実施の形態（変形例を含む）で説明する機能は、特定のユーザ装置にのみ適用されてもよい。この場合、例えば、当該機能に対応しているユーザ装置は、当該機能に対応していることを示す能力情報（ｃａｐａｂｉｌｉｔｙ）をＮＷ（基地局２０）へ通知する。また、当該特定のユーザ装置は、例えば、特定のサービスを提供するユーザ装置である。当該特定のサービスは、例えば、短いＴＴＩを用いるサービス、又は、期待されるスループット（Ｔｐｕｔ）が所定値を超えるサービス、又は、これら両方である。また、当該特定のサービスは、特定のベアラ（例：Ｂｅｓｔ ｅｆｆｏｒｔ）を設定するサービスであってもよいし、広帯域での通信サービス（例：ＣＡ及び／又はＤＣ等が設定されていること）であってもよい。

また、図２０に例示するＤｕａｌ ＣｏｎｎｅｃｔｉｖｉｔｙのＳｐｌｉｔ ｂｅａｒｅｒ（非特許文献４参照）を適用する場合のように、１つのＰＤＣＰ ｅｎｔｉｔｙに対して、複数のＲＬＣ ｅｎｔｉｔｙが関連付けられる場合には、ユーザ装置１０（基地局２０）におけるＰＤＣＰレイヤは、いずれか一方のみからのｉｎｄｉｃａｔｉｏｎ（受信状況通知）を期待してもよいし、両方からのｉｎｄｉｃａｔｉｏｎを期待してもよい。なお、図２０に示す構成は、例えば、ＵＬでＤｕａｌ ＣｏｎｎｅｃｔｉｖｉｔｙのＳｐｌｉｔ ｂｅａｒｅｒを行うユーザ装置１０のレイヤ２の構成を示す。この場合、ユーザ装置１０には、ＭｅＮＢ用のＭＡＣエンティティ、ＲＬＣエンティティ、及びＰＤＣＰエンティティと、ＳｅＮＢ用のＭＡＣエンティティ、ＲＬＣエンティティ、及びＰＤＣＰエンティティとが備えられる。また、図２０に示す構成は、例えば、ＤＬでＤｕａｌ ＣｏｎｎｅｃｔｉｖｉｔｙのＳｐｌｉｔ ｂｅａｒｅｒを行う基地局２０（ここでは、ＭｅＮＢとＳｅＮＢの２つからなる）におけるレイヤ２の構成を示すものと解釈してもよい。

また、第２の実施の形態（変形例を含む）で説明する機能は、下りリンクの通信と、上りリンクの通信と、ユーザ装置間が基地局を介さずに直接通信を行うｓｉｄｅｌｉｎｋ通信とのそれぞれにおいて、適用されるか否かが決められてもよい。つまり、下りリンクの通信と、上りリンクの通信と、ｓｉｄｅｌｉｎｋ通信との間で、第２の実施の形態（変形例を含む）で説明する機能が適用されるか否かが異なっていても良い。

（装置構成）
以上説明した第１、第２の実施の形態の動作を実行するユーザ装置１０及び基地局２０の機能構成例を説明する。ユーザ装置１０及び基地局２０はそれぞれ、レイヤ２に関して、第１の実施の形態（変形例を含む）の機能のみを有することとしてもよいし、第２の実施の形態（変形例を含む）の機能のみを有することとしてもよいし、第１の実施の形態（変形例を含む）の機能と第２の実施の形態（変形例を含む）の機能の両方を含むこととしてもよい。以下では、ユーザ装置１０及び基地局２０はそれぞれ、特に断らない限り、第１の実施の形態（変形例を含む）の機能と第２の実施の形態（変形例を含む）の機能の両方を含むことを想定している。

＜ユーザ装置＞
図２１の（ａ）は、ユーザ装置１０の機能構成の一例を示す図である。図２１（ａ）に示すように、ユーザ装置１０は、信号送信部１０１と、信号受信部１０２と、レイヤ２処理部１０３と、上位レイヤ処理部１０４とを有する。図２１（ａ）に示す機能構成は一例に過ぎない。本実施の形態に係る動作を実行できるのであれば、機能区分及び機能部の名称はどのようなものでもよい。例えば、レイヤ２処理部１０３を受信側と送信側に分けて、送信側のレイヤ２処理部を信号送信部１０１に含め、受信側のレイヤ２処理部を信号受信部１０２に含めてもよい。

信号送信部１０１は、送信側の物理レイヤの機能部に相当し、レイヤ２処理部１０３から渡される信号を無線で送信するように構成されている。信号受信部１０２は、受信側の物理レイヤの機能部に相当し、各種の信号を無線受信し、受信した信号をレイヤ２処理部１０３に渡すように構成されている。

レイヤ２処理部１０３は、基本構成として図２を参照して説明したレイヤ２の構成を備えるとともに、第１の実施の形態（変形例を含む）で説明した処理機能と第２の実施の形態（変形例を含む）で説明した処理機能を有する。

また、例えば、第１の実施の形態（変形例を含む）で説明した処理機能に対応して、（ｂ）に示すように、レイヤ２処理部１０３は、他の通信装置に送信する第１データユニットを生成する第１生成部１１３と、第１生成部１１３により生成された第１データユニットに当該第１データユニットのサイズを示す値を付加し、当該第１データユニットと当該値とを有するペイロードを含む第２データユニットを生成する第２生成部１２３とを備えてもよい。

また、例えば、第２の実施の形態（変形例を含む）で説明した処理機能に対応して、（ｃ）に示すように、レイヤ２処理部１０３は、他の通信装置から受信した、シーケンス番号を有する第１データユニットに対する処理を実行する第１レイヤ処理部１３３と、第１データユニットから取得された第２データユニットに対する処理を実行する第２レイヤ処理部１４３とを有し、第１レイヤ処理部１３３は、受信された第１データユニットから第２データユニットを取得して、当該第２データユニットを第２レイヤ処理部１４３に渡す際に、受信が期待される未受信の第１データユニットが有るか否かを第２レイヤ処理部１４３に通知するように構成されてもよい。

上位レイヤ処理部１０４は、レイヤ２よりも上位のレイヤの処理を行うように構成されている。上位レイヤ処理部１０４は、例えば、ＩＰパケットの送信（生成）・受信処理、Ｃ−ｐｌａｎｅでの処理としてのＲＲＣ処理を実行するように構成されている。

＜基地局２０＞
図２２の（ａ）は、基地局２０の機能構成の一例を示す図である。図２２（ａ）に示すように、基地局２０は、信号送信部２０１と、信号受信部２０２と、レイヤ２処理部２０３と、上位レイヤ処理部２０４とを有する。図２２（ａ）に示す機能構成は一例に過ぎない。本実施の形態に係る動作を実行できるのであれば、機能区分及び機能部の名称はどのようなものでもよい。例えば、レイヤ２処理部２０３を受信側と送信側に分けて、送信側のレイヤ２処理部を信号送信部２０１に含め、受信側のレイヤ２処理部を信号受信部２０２に含めてもよい。

信号送信部２０１は、送信側の物理レイヤの機能部に相当し、レイヤ２処理部２０３から渡される信号を無線で送信するように構成されている。信号受信部２０２は、受信側の物理レイヤの機能部に相当し、各種の信号を無線受信し、受信した信号をレイヤ２処理部２０３に渡すように構成されている。

レイヤ２処理部２０３は、基本構成として図２を参照して説明したレイヤ２の構成を備えるとともに、第１の実施の形態（変形例を含む）で説明した処理機能と第２の実施の形態（変形例を含む）で説明した処理機能を有する。

また、例えば、第１の実施の形態（変形例を含む）で説明した処理機能に対応して、（ｂ）に示すように、レイヤ２処理部２０３は、他の通信装置に送信する第１データユニットを生成する第１生成部２１３と、第１生成部２１３により生成された第１データユニットに当該第１データユニットのサイズを示す値を付加し、当該第１データユニットと当該値とを有するペイロードを含む第２データユニットを生成する第２生成部２２３とを備えてもよい。

また、例えば、第２の実施の形態（変形例を含む）で説明した処理機能に対応して、（ｃ）に示すように、レイヤ２処理部２０３は、他の通信装置から受信した、シーケンス番号を有する第１データユニットに対する処理を実行する第１レイヤ処理部２３３と、第１データユニットから取得された第２データユニットに対する処理を実行する第２レイヤ処理部２４３とを有し、第１レイヤ処理部２３３は、受信された第１データユニットから第２データユニットを取得して、当該第２データユニットを第２レイヤ処理部２４３に渡す際に、受信が期待される未受信の第１データユニットが有るか否かを第２レイヤ処理部２４３に通知するように構成されてもよい。

上位レイヤ処理部２０４は、レイヤ２よりも上位のレイヤの処理を行うように構成されている。上位レイヤ処理部２０４は、例えば、ＩＰパケットの送信（生成）・受信処理、Ｃ−ｐｌａｎｅでの処理としてのＲＲＣ処理を実行するように構成されている。

＜ハードウェア構成＞
上記実施の形態の説明に用いたブロック図（図２１及び図２２）は、機能単位のブロックを示している。これらの機能ブロック（構成部）は、ハードウェア及び／又はソフトウェアの任意の組み合わせによって実現される。また、各機能ブロックの実現手段は特に限定されない。すなわち、各機能ブロックは、物理的及び／又は論理的に複数要素が結合した１つの装置により実現されてもよいし、物理的及び／又は論理的に分離した２つ以上の装置を直接的及び／又は間接的に（例えば、有線及び／又は無線）で接続し、これら複数の装置により実現されてもよい。

また、例えば、本発明の一実施の形態におけるユーザ装置１０と基地局２０はいずれも、本実施の形態に係る処理を行うコンピュータとして機能してもよい。図２３は、本実施の形態に係るユーザ装置１０及び基地局２０のハードウェア構成の一例を示す図である。上述のユーザ装置１０及び基地局２０はそれぞれ、物理的には、プロセッサ１００１、メモリ１００２、ストレージ１００３、通信装置１００４、入力装置１００５、出力装置１００６、バス１００７などを含むコンピュータ装置として構成されてもよい。

なお、以下の説明では、「装置」という文言は、回路、デバイス、ユニットなどに読み替えることができる。ユーザ装置１０及び基地局２０のハードウェア構成は、図に示した１００１〜１００６で示される各装置を１つ又は複数含むように構成されてもよいし、一部の装置を含まずに構成されてもよい。

ユーザ装置１０及び基地局２０における各機能は、プロセッサ１００１、メモリ１００２などのハードウェア上に所定のソフトウェア（プログラム）を読み込ませることで、プロセッサ１００１が演算を行い、通信装置１００４による通信、メモリ１００２及びストレージ１００３におけるデータの読み出し及び／又は書き込みを制御することで実現される。

プロセッサ１００１は、例えば、オペレーティングシステムを動作させてコンピュータ全体を制御する。プロセッサ１００１は、周辺装置とのインターフェース、制御装置、演算装置、レジスタなどを含む中央処理装置（ＣＰＵ：Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）で構成されてもよい。

また、プロセッサ１００１は、プログラム（プログラムコード）、ソフトウェアモジュール又はデータを、ストレージ１００３及び／又は通信装置１００４からメモリ１００２に読み出し、これらに従って各種の処理を実行する。プログラムとしては、上述の実施の形態で説明した動作の少なくとも一部をコンピュータに実行させるプログラムが用いられる。例えば、ユーザ装置１０の信号送信部１０１、信号受信部１０２、レイヤ２処理部１０３、上位レイヤ処理部１０４は、メモリ１００２に格納され、プロセッサ１００１で動作する制御プログラムによって実現されてもよい。また、基地局２０の信号送信部２０１、信号受信部２０２、レイヤ２処理部２０３、上位レイヤ処理部２０４は、メモリ１００２に格納され、プロセッサ１００１で動作する制御プログラムによって実現されてもよい。上述の各種処理は、１つのプロセッサ１００１で実行される旨を説明してきたが、２以上のプロセッサ１００１により同時又は逐次に実行されてもよい。プロセッサ１００１は、１以上のチップで実装されてもよい。なお、プログラムは、電気通信回線を介してネットワークから送信されても良い。

メモリ１００２は、コンピュータ読み取り可能な記録媒体であり、例えば、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＥＰＲＯＭ（Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ ＲＯＭ）、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ ＲＯＭ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）などの少なくとも１つで構成されてもよい。メモリ１００２は、レジスタ、キャッシュ、メインメモリ（主記憶装置）などと呼ばれてもよい。メモリ１００２は、本発明の一実施の形態に係る処理を実施するために実行可能なプログラム（プログラムコード）、ソフトウェアモジュールなどを保存することができる。

ストレージ１００３は、コンピュータ読み取り可能な記録媒体であり、例えば、ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｃ ＲＯＭ）などの光ディスク、ハードディスクドライブ、フレキシブルディスク、光磁気ディスク（例えば、コンパクトディスク、デジタル多用途ディスク、Ｂｌｕ−ｒａｙ（登録商標）ディスク）、スマートカード、フラッシュメモリ（例えば、カード、スティック、キードライブ）、フロッピー（登録商標）ディスク、磁気ストリップなどの少なくとも１つで構成されてもよい。ストレージ１００３は、補助記憶装置と呼ばれてもよい。上述の記憶媒体は、例えば、メモリ１００２及び／又はストレージ１００３を含むデータベース、サーバその他の適切な媒体であってもよい。

通信装置１００４は、有線及び／又は無線ネットワークを介してコンピュータ間の通信を行うためのハードウェア（送受信デバイス）であり、例えばネットワークデバイス、ネットワークコントローラ、ネットワークカード、通信モジュールなどともいう。例えば、ユーザ装置１０の信号送信部１０１及び信号受信部１０２は、通信装置１００４で実現されてもよい。また、基地局２０の信号送信部２０１及び信号受信部２０２は、通信装置１００４で実現されてもよい。

入力装置１００５は、外部からの入力を受け付ける入力デバイス（例えば、キーボード、マウス、マイクロフォン、スイッチ、ボタン、センサなど）である。出力装置１００６は、外部への出力を実施する出力デバイス（例えば、ディスプレイ、スピーカー、LEDランプなど）である。なお、入力装置１００５及び出力装置１００６は、一体となった構成（例えば、タッチパネル）であってもよい。

また、プロセッサ１００１及びメモリ１００２などの各装置は、情報を通信するためのバス１００７で接続される。バス１００７は、単一のバスで構成されてもよいし、装置間で異なるバスで構成されてもよい。

また、ユーザ装置１０及び基地局２０はそれぞれ、マイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ：Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ）、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）、ＰＬＤ（Ｐｒｏｇｒａｍｍａｂｌｅ Ｌｏｇｉｃ Ｄｅｖｉｃｅ）、ＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）などのハードウェアを含んで構成されてもよく、当該ハードウェアにより、各機能ブロックの一部又は全てが実現されてもよい。例えば、プロセッサ１００１は、これらのハードウェアの少なくとも１つで実装されてもよい。

（実施の形態のまとめ）
以上、説明したように、本実施の形態によれば、無線通信システムにおいて使用される通信装置であって、他の通信装置に送信する第１データユニットを生成する第１生成部と、前記第１生成部により生成された第１データユニットに当該第１データユニットのサイズを示す値を付加し、当該第１データユニットと当該値とを有するペイロードを含む第２データユニットを生成する第２生成部と、前記第２データユニットを前記他の通信装置に送信する送信部とを備えることを特徴とする通信装置が提供される。この構成により、無線通信システムで使用される通信装置において、データユニットの生成にかかる時間を短縮することが可能となる。

前記第２生成部は、前記第１データユニットと当該第１データユニットのサイズを示す値とを有するデータを複数個連結することにより前記第２データユニットを生成することとしてもよい。この構成により、第２データユニットの生成処理を迅速に行うことができる。

前記第２データユニットのサイズは、前記送信部において利用できる無線リソースに基づき決定されるサイズであり、前記第２生成部は、前記第２データユニットのサイズが決定される前に、前記連結を実行することとしてもよい。この構成により、Ｎｏｎ−ｒｅａｌｔｉｍｅ処理により、連結を実行することができる。

前記第２データユニットはヘッダ領域を有し、前記第２生成部は、前記第２データユニットにおける前記ヘッダ領域の中に、前記ペイロードにおける所定の第１データユニットの位置に対応する情報を含めることとしてもよい。この構成により、ペイロードの中に、所定の第１データユニットの位置を判断するための情報がない場合でも、当該所定の第１データユニットの位置を把握することができる。

また、本実施の形態によれば、無線通信システムにおいて使用される通信装置が実行する送信方法であって、他の通信装置に送信する第１データユニットを生成する第１生成ステップと、前記第１生成ステップにより生成された第１データユニットに当該第１データユニットのサイズを示す値を付加し、当該第１データユニットと当該値とを有するペイロードを含む第２データユニットを生成する第２生成ステップと、前記第２データユニットを前記他の通信装置に送信する送信ステップとを備えることを特徴とする送信方法が提供される。この構成により、無線通信システムで使用される通信装置において、データユニットの生成にかかる時間を短縮することが可能となる。

また、本実施の形態によれば、無線通信システムにおいて使用される通信装置であって、シーケンス番号を有する第１データユニットを他の通信装置から受信する受信部と、前記受信部により、前記シーケンス番号の順序のとおりに第１データユニットが受信されない場合でも、受信された第１データユニットから第２データユニットを取得し、当該第２データユニットから上位レイヤのデータを取得するための処理（例：秘匿解除処理）を実行するレイヤ２処理部とを備えることを特徴とする通信装置が提供される。この構成により、無線通信システムの通信装置において、所定のレイヤでの順序補正処理に起因する遅延を解消することが可能となる。

前記レイヤ２処理部は、前記第１データユニットに対する処理を実行する第１レイヤ処理部と、前記第２データユニットに対する処理を実行する第２レイヤ処理部とを有し、前記第１レイヤ処理部は、前記受信された第１データユニットから前記第２データユニットを取得して、当該第２データユニットを前記第２レイヤ処理部に渡す際に、受信が期待される未受信の第１データユニットが有るか否かを前記第２レイヤ処理部に通知することとしてもよい。この構成により、通信装置は、第２データユニットが送信側で破棄されたのか、それとも、無線で再送中なのかを判別することができる。

（実施形態の補足）
以上、本発明の実施の形態を説明してきたが、開示される発明はそのような実施形態に限定されず、当業者は様々な変形例、修正例、代替例、置換例等を理解するであろう。発明の理解を促すため具体的な数値例を用いて説明がなされたが、特に断りのない限り、それらの数値は単なる一例に過ぎず適切な如何なる値が使用されてもよい。上記の説明における項目の区分けは本発明に本質的ではなく、２以上の項目に記載された事項が必要に応じて組み合わせて使用されてよいし、ある項目に記載された事項が、別の項目に記載された事項に（矛盾しない限り）適用されてよい。機能ブロック図における機能部又は処理部の境界は必ずしも物理的な部品の境界に対応するとは限らない。複数の機能部の動作が物理的には１つの部品で行われてもよいし、あるいは１つの機能部の動作が物理的には複数の部品により行われてもよい。実施の形態で述べた処理手順については、矛盾の無い限り処理の順序を入れ替えてもよい。処理説明の便宜上、ユーザ装置１０及び基地局２０は機能的なブロック図を用いて説明されたが、そのような装置はハードウェアで、ソフトウェアで又はそれらの組み合わせで実現されてもよい。本発明の実施の形態に従ってユーザ装置１０が有するプロセッサにより動作するソフトウェア及び本発明の実施の形態に従って基地局２０が有するプロセッサにより動作するソフトウェアはそれぞれ、ランダムアクセスメモリ（ＲＡＭ）、フラッシュメモリ、読み取り専用メモリ（ＲＯＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、レジスタ、ハードディスク（ＨＤＤ）、リムーバブルディスク、ＣＤ−ＲＯＭ、データベース、サーバその他の適切な如何なる記憶媒体に保存されてもよい。

また、情報の通知は、本明細書で説明した態様／実施形態に限られず、他の方法で行われてもよい。例えば、情報の通知は、物理レイヤシグナリング（例えば、ＤＣＩ（Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）、ＵＣＩ（Ｕｐｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ））、上位レイヤシグナリング（例えば、ＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）シグナリング、ＭＡＣ（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）シグナリング、ブロードキャスト情報（ＭＩＢ（Ｍａｓｔｅｒ Ｉｎｆｏｒｍａｔｉｏｎ Ｂｌｏｃｋ）、ＳＩＢ（Ｓｙｓｔｅｍ Ｉｎｆｏｒｍａｔｉｏｎ Ｂｌｏｃｋ）））、その他の信号又はこれらの組み合わせによって実施されてもよい。また、ＲＲＣシグナリングは、ＲＲＣメッセージと呼ばれてもよく、例えば、ＲＲＣ接続セットアップ（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｓｅｔｕｐ）メッセージ、ＲＲＣ接続再構成（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ）メッセージなどであってもよい。

本明細書で説明した各態様／実施形態は、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）、ＬＴＥ−Ａ（ＬＴＥ−Ａｄｖａｎｃｅｄ）、ＳＵＰＥＲ ３Ｇ、ＩＭＴ−Ａｄｖａｎｃｅｄ、４Ｇ、５Ｇ、ＦＲＡ（Ｆｕｔｕｒｅ Ｒａｄｉｏ Ａｃｃｅｓｓ）、Ｗ−ＣＤＭＡ（登録商標）、ＧＳＭ（登録商標）、ＣＤＭＡ２０００、ＵＭＢ（Ｕｌｔｒａ Ｍｏｂｉｌｅ Ｂｒｏａｄｂａｎｄ）、ＩＥＥＥ ８０２．１１（Ｗｉ−Ｆｉ）、ＩＥＥＥ ８０２．１６（ＷｉＭＡＸ）、ＩＥＥＥ ８０２．２０、ＵＷＢ（Ｕｌｔｒａ−ＷｉｄｅＢａｎｄ）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、その他の適切なシステムを利用するシステム及び／又はこれらに基づいて拡張された次世代システムに適用されてもよい。

本明細書で説明した各態様／実施形態の処理手順、シーケンス、フローチャートなどは、矛盾の無い限り、順序を入れ替えてもよい。例えば、本明細書で説明した方法については、例示的な順序で様々なステップの要素を提示しており、提示した特定の順序に限定されない。

本明細書において基地局２０によって行われるとした特定動作は、場合によってはその上位ノード（ｕｐｐｅｒ ｎｏｄｅ）によって行われることもある。基地局２０を有する１つまたは複数のネットワークノード（ｎｅｔｗｏｒｋ ｎｏｄｅｓ）からなるネットワークにおいて、ユーザ装置１０との通信のために行われる様々な動作は、基地局２０および／または基地局２０以外の他のネットワークノード（例えば、ＭＭＥまたはＳ−ＧＷなどが考えられるが、これらに限られない）によって行われ得ることは明らかである。上記において基地局２０以外の他のネットワークノードが１つである場合を例示したが、複数の他のネットワークノードの組み合わせ（例えば、ＭＭＥおよびＳ−ＧＷ）であってもよい。

本明細書で説明した各態様／実施形態は単独で用いてもよいし、組み合わせて用いてもよいし、実行に伴って切り替えて用いてもよい。

ユーザ装置１０は、当業者によって、加入者局、モバイルユニット、加入者ユニット、ワイヤレスユニット、リモートユニット、モバイルデバイス、ワイヤレスデバイス、ワイヤレス通信デバイス、リモートデバイス、モバイル加入者局、アクセス端末、モバイル端末、ワイヤレス端末、リモート端末、ハンドセット、ユーザエージェント、モバイルクライアント、クライアント、またはいくつかの他の適切な用語で呼ばれる場合もある。

基地局２０は、当業者によって、ＮＢ（ＮｏｄｅＢ）、ｅＮＢ（ｅｎｈａｎｃｅｄ ＮｏｄｅＢ）、ベースステーション（Ｂａｓｅ Ｓｔａｔｉｏｎ）、またはいくつかの他の適切な用語で呼ばれる場合もある。

本明細書で使用する「判断（ｄｅｔｅｒｍｉｎｉｎｇ）」、「決定（ｄｅｔｅｒｍｉｎｉｎｇ）」という用語は、多種多様な動作を包含する場合がある。「判断」、「決定」は、例えば、判定（ｊｕｄｇｉｎｇ）、計算（ｃａｌｃｕｌａｔｉｎｇ）、算出（ｃｏｍｐｕｔｉｎｇ）、処理（ｐｒｏｃｅｓｓｉｎｇ）、導出（ｄｅｒｉｖｉｎｇ）、調査（ｉｎｖｅｓｔｉｇａｔｉｎｇ）、探索（ｌｏｏｋｉｎｇ ｕｐ）（例えば、テーブル、データベースまたは別のデータ構造での探索）、確認（ａｓｃｅｒｔａｉｎｉｎｇ）した事を「判断」「決定」したとみなす事などを含み得る。また、「判断」、「決定」は、受信（ｒｅｃｅｉｖｉｎｇ）（例えば、情報を受信すること）、送信（ｔｒａｎｓｍｉｔｔｉｎｇ）（例えば、情報を送信すること）、入力（ｉｎｐｕｔ）、出力（ｏｕｔｐｕｔ）、アクセス（ａｃｃｅｓｓｉｎｇ）（例えば、メモリ中のデータにアクセスすること）した事を「判断」「決定」したとみなす事などを含み得る。また、「判断」、「決定」は、解決（ｒｅｓｏｌｖｉｎｇ）、選択（ｓｅｌｅｃｔｉｎｇ）、選定（ｃｈｏｏｓｉｎｇ）、確立（ｅｓｔａｂｌｉｓｈｉｎｇ）、比較（ｃｏｍｐａｒｉｎｇ）などした事を「判断」「決定」したとみなす事を含み得る。つまり、「判断」「決定」は、何らかの動作を「判断」「決定」したとみなす事を含み得る。

本明細書で使用する「に基づいて」という記載は、別段に明記されていない限り、「のみに基づいて」を意味しない。言い換えれば、「に基づいて」という記載は、「のみに基づいて」と「に少なくとも基づいて」の両方を意味する。

「含む（ｉｎｃｌｕｄｅ）」、「含んでいる（ｉｎｃｌｕｄｉｎｇ）」、およびそれらの変形が、本明細書あるいは特許請求の範囲で使用されている限り、これら用語は、用語「備える（ｃｏｍｐｒｉｓｉｎｇ）」と同様に、包括的であることが意図される。さらに、本明細書あるいは特許請求の範囲において使用されている用語「または（ｏｒ）」は、排他的論理和ではないことが意図される。

本開示の全体において、例えば、英語でのａ，ａｎ，及びｔｈｅのように、翻訳により冠詞が追加された場合、これらの冠詞は、文脈から明らかにそうではないことが示されていなければ、複数のものを含み得る。

以上、本発明について詳細に説明したが、当業者にとっては、本発明が本明細書中に説明した実施形態に限定されるものではないということは明らかである。本発明は、特許請求の範囲の記載により定まる本発明の趣旨及び範囲を逸脱することなく修正及び変更態様として実施することができる。したがって、本明細書の記載は、例示説明を目的とするものであり、本発明に対して何ら制限的な意味を有するものではない。

１０ ユーザ装置
２０ 基地局
１０１ 信号送信部
１０２ 信号受信部
１０３ レイヤ２処理部
１１３ 第１生成部
１２３ 第２生成部
１３３ 第１レイヤ処理部
１４３ 第２レイヤ処理部
１０４ 上位レイヤ処理部
２０１ 信号送信部
２０２ 信号受信部
２０３ レイヤ２処理部
２１３ 第１生成部
２２３ 第２生成部
２３３ 第１レイヤ処理部
２４３ 第２レイヤ処理部
２０４ 上位レイヤ処理部
１００１ プロセッサ
１００２ メモリ
１００３ ストレージ
１００４ 通信装置
１００５ 入力装置
１００６ 出力装置

Claims (5)

1. 無線通信システムにおいて使用される通信装置であって、
   他の通信装置に送信する第１データユニットを生成する第１生成部と、
   前記第１生成部により生成された第１データユニットに当該第１データユニットのサイズを示す値を付加し、当該第１データユニットと当該値とを有するペイロードを含む第２データユニットを生成する第２生成部と、
   前記第２データユニットを前記他の通信装置に送信する送信部と
   を備えることを特徴とする通信装置。
2. 前記第２生成部は、前記第１データユニットと当該第１データユニットのサイズを示す値とを有するデータを複数個連結することにより前記第２データユニットを生成する
   ことを特徴とする請求項１に記載の通信装置。
3. 前記第２データユニットのサイズは、前記送信部において利用できる無線リソースに基づき決定されるサイズであり、
   前記第２生成部は、前記第２データユニットのサイズが決定される前に、前記連結を実行する
   ことを特徴とする請求項２に記載の通信装置。
4. 前記第２データユニットはヘッダ領域を有し、
   前記第２生成部は、前記第２データユニットにおける前記ヘッダ領域の中に、前記ペイロードにおける所定の第１データユニットの位置に対応する情報を含める
   ことを特徴とする請求項１ないし３のうちいずれか１項に記載の通信装置。
5. 無線通信システムにおいて使用される通信装置が実行する送信方法であって、
   他の通信装置に送信する第１データユニットを生成する第１生成ステップと、
   前記第１生成ステップにより生成された第１データユニットに当該第１データユニットのサイズを示す値を付加し、当該第１データユニットと当該値とを有するペイロードを含む第２データユニットを生成する第２生成ステップと、
   前記第２データユニットを前記他の通信装置に送信する送信ステップと
   を備えることを特徴とする送信方法。

Images