JPWO2016163509A1

JPWO2016163509A1 - 通信端末

Info

Publication number: JPWO2016163509A1
Application number: JP2017511088A
Authority: JP
Inventors: 真平安川; 聡永田; ユンボゼン; チュンジョウ; ユンセンジャン
Original assignee: NTT Docomo Inc
Current assignee: NTT Docomo Inc
Priority date: 2015-04-09
Filing date: 2016-04-08
Publication date: 2018-02-01
Also published as: CN107431950A; WO2016163509A1; US20180116007A1

Abstract

Ｄ２Ｄにおいて複数のリモートＵＥに対して効率よくデータを送信する。通信端末は、レイヤ２の宛先情報に含まれる特定情報が、Ｄ２Ｄを行う対象である複数の端末を個別に特定するように、前記宛先情報を設定する設定部と、前記特定情報を、１スケジューリング期間において前記複数の端末ごとに異なるサブフレームの制御チャネルに割り当て、前記複数の端末それぞれに送信する送信データを、前記１スケジューリング期間において前記複数の端末ごとに異なるサブフレームのデータチャネルに割り当てる割り当て部とを備える。

Description

本発明は、次世代移動通信システムにおける通信端末に関する。

ＬＴＥ（Long Term Evolution）やＬＴＥの後継システム（例えば、ＬＴＥ−Ａ（LTE Advanced）、ＦＲＡ（Future Radio Access）、４Ｇなどともいう）では、ユーザ端末同士が無線基地局を介さないで直接通信を行うＤ２Ｄ（Device to Device）技術が検討されている（例えば、非特許文献１）。

Ｄ２Ｄは、通信可能な他のユーザ端末を見つけ出すためのＤ２Ｄディスカバリ（D2D discovery、Ｄ２Ｄ発見ともいう）と、端末間で直接通信するためのＤ２Ｄコミュニケーション（D2D direct communication、Ｄ２Ｄ通信、端末間直接通信などともいう）と、に大別される。以下では、Ｄ２Ｄコミュニケーション、Ｄ２Ｄディスカバリなどを特に区別しないときは、単にＤ２Ｄと呼ぶ。また、Ｄ２Ｄで送受信される信号を、Ｄ２Ｄ信号と呼ぶ。

Ｄ２Ｄ信号用のリソースとして、ネットワークが各ユーザ端末に対して、上りリンクリソースの一部を準静的（semi-static）に割り当てることが検討されている。例えば、ユーザ端末は、割り当てられたＤ２Ｄディスカバリリソースを用いて発見用信号（ディスカバリ信号（discovery signal））を送信する。また、ユーザ端末は、他のユーザ端末から送信された発見用信号をＤ２Ｄディスカバリリソースで受信することにより、通信可能な他のユーザ端末を見つけ出すことができる。

"Key drivers for LTE success: Services Evolution"、２０１１年９月、3GPP、インターネットURL： http://www.3gpp.org/ftp/Information/presentations/presentations_2011/2011_09_LTE_Asia/2011_LTE-Asia_3GPP_Service_evolution.pdf

上述のＤ２Ｄにおいて、Ｒｅｌ．１３では、レイヤ３のリレー装置を規定することが検討されている。例えば、カバレッジ内のユーザ端末がカバレッジ外のユーザ端末（以降「リモートＵＥ」）との間でＤ２Ｄを行うとともに、リレー装置として機能することで結果的にカバレッジを拡大することが考えられる。このため、ユーザ端末からリモートＵＥに対して効率的にデータを送信する仕組みが求められている。

本発明はかかる点に鑑みてなされたものであり、Ｄ２Ｄにおいて複数のリモートＵＥに対して効率よくデータを送信する通信端末を提供することを目的の１つとする。

本発明の通信端末は、レイヤ２の宛先情報に含まれる特定情報が、Ｄ２Ｄを行う対象である複数の端末を個別に特定するように、前記宛先情報を設定する設定部と、前記特定情報を、１スケジューリング期間において前記複数の端末ごとに異なるサブフレームの制御チャネルに割り当て、前記複数の端末それぞれに送信する送信データを、前記１スケジューリング期間において前記複数の端末ごとに異なるサブフレームのデータチャネルに割り当てる割り当て部とを備える。

本発明によれば、Ｄ２Ｄにおいて複数のリモートＵＥに対して効率よくデータを送信することができる。

Ｄ２Ｄコミュニケーションにおける無線リソースの構成を示す図である。ＰＳＣＣＨのリソースビットマップ例を示す図である。無線通信システムの概略構成の一例を示す概略構成図である。Ｄ２Ｄにおいて、異なるリモート端末宛に宛先ＩＤと送信データとを生成する処理を説明する図である。異なるリモート端末宛のデータ送信が異なったＰＳＣＣＨ期間（１スケジューリング期間）で送信される例を説明する図である。本実施の形態における無線通信システムの概略構成の一例を示す概略構成図である。本実施の形態におけるＳＣＩ送信を説明するための図である。本実施の形態の態様１における、異なるリモート端末宛に宛先ＩＤと送信データとを生成する処理を説明する図である。本実施の形態の態様１における、データ送信を説明するための図である。本実施の形態の態様２における、異なるリモート端末宛に宛先ＩＤと送信データとを生成する処理を説明する図である。本実施の形態の態様２における、データ送信を説明するための図である。本実施の形態の態様２における、無線通信システムの構成要素間の処理を説明するための図である。本実施の形態の態様３における、異なるリモート端末宛に宛先ＩＤと送信データとを生成する処理を説明する図である。本実施の形態の態様３における、データ送信を説明するための図である。本実施の形態に係る無線通信システムの構成の一例を示す図である。本実施の形態に係る無線基地局の全体構成の一例を示す図である。本実施の形態に係るユーザ端末の全体構成の一例を示す図である。本実施の形態に係るユーザ端末（リレー装置）の機能構成の一例を示す図である。本実施の形態に係るユーザ端末（リモートＵＥ）の機能構成の一例を示す図である。本実施の形態の態様１における、サイドリンクグラントの上書きを説明するための図である。本実施の形態の態様１−１における、複数のサイドリンクグラントの設定を説明するための図である。本実施の形態の態様１−２における、複数のサイドリンクグラントの設定を説明するための図である。本実施の形態の態様１−３における、複数のサイドリンクグラントの設定を説明するための図である。本実施の形態の態様３における、Ｌ２宛先ＩＤの衝突を説明するための図である。本実施の形態の態様３−１における、ＭＡＣヘッダを説明するための図である。本実施の形態の態様３−２、態様３−３における、Ｌ２宛先ＩＤの変更を説明するための図である。

先ず、Ｒｅｌ．１２でサポートされているＤ２Ｄについて説明する。図１Ａは、Ｒｅｌ．１２でサポートされているＤ２Ｄにおいて、Ｄ２Ｄコミュニケーションで送信される無線リソースの構成を示している。縦軸は周波数を示し、横軸は時間を示している。Ｄ２Ｄコミュニケーションでは、１スケジューリングで送信される制御情報及びデータを１周期（１スケジューリング期間）とし、ＰＳＣＣＨ（Physical Sidelink Control Channel）周期又はＣｏｍｍｕｎｉｃａｔｉｏｎ周期と称する。ＰＳＣＣＨ周期は例えば４０ｍｓ以上の長さを有する。

Ｄ２Ｄでは、ＵＬリソースが用いられているため、送信される無線リソースの周波数端には、ＰＵＣＣＨ（Physical Uplink Control Channel）が配置されている。このＰＵＣＣＨより中心周波数側にＰＳＣＣＨ用のリソースプール（ＳＡプール）とＰＳＳＣＨ（Physical Sidelink Shared Channel）用のリソースプール（データプール）が時間軸に沿って確保されている。これらのリソースプールは、例えば報知によって（ＳＩＢ（System Information Block）などに書き込まれて）予め確保される。なお、ＰＳＳＣＨリソースプールについては、Ｒｅｌ．１２で規定されているモード２（ユーザ端末がランダムに送信リソースを決定する）のリソース割り当てのために通知され、モード１（無線基地局によりリソースが割り当てられる）では全ての上りリンクリソースがＰＳＳＣＨで共用される。

ＰＳＣＣＨには、ＰＳＳＣＨで送信されるデータに関する制御情報が割り当てられる。制御情報は、１ＰＲＢ(Physical Resource Block)ペアの固定リソースサイズであり、ＱＰＳＫ（Quadrature Phase Shift Keying）が適用される場合にはＭＣＳ（Modulation and Coding Scheme）のインデックを指定してもよい。また、ＰＳＣＣＨ上の制御情報への無線リソースの割り当てにあたっては、図１に示されるように、周波数ホッピングによる、１繰り返し（Repetition）が行われてもよい。

ＰＳＳＣＨは、ＭＡＣ（Media Access Control）ＰＤＵ（Packet Date Unit）のデータの送信に使用される。ＰＳＣＣＨ上のデータへの無線リソースの割り当てにあたっては、図１に示されるように、周波数ホッピングによる、繰り返しを３回行ってもよい。ＰＳＳＣＨはＰＵＳＣＨと同様に準静的（semi-static）な割り当てで使用することができる。

このようなＤ２Ｄ無線リソースの構成では、１つのＰＳＣＣＨのスケジューリングを用いて（複数のＭＡＣＰＤＵをスケジューリングして）、ＰＳＳＣＨで、例えば音声などのデータを連続して送信する。図１Ｂは、ＰＳＣＣＨ及びＰＳＳＣＨのためのＰＵＳＣＨベースの構成を示す。

Ｄ２Ｄの制御チャネル（ＰＳＣＣＨ）で送信される制御情報のＳＣＩ（Sidelink Control Information）フォーマット０には、周波数ホッピングフラグ（１ビット）と、リソースブロック割り当て及びホッピングリソース割り当て（log₂(N^SL _RB(N^SL _RB+1)/2)ビット）と、タイムリソースパターン（７ビット）と、ＭＣＳ（５ビット）と、ＴＡ（１１ビット）と、グループ宛先ＩＤ（８ビット）が含まれる。

周波数ホッピングフラグ、リソースブロック割り当て及びホッピングリソース割り当ては、既存のものである。ＰＵＳＣＨのホッピングに類似するホッピングをＰＳＳＣＨに適用することができる。また、タイプ１ＰＵＳＣＨホッピングやタイプ２ＰＵＳＣＨホッピングがサポートされている。

タイムリソースパターンは、ビットマップの情報であって、例えば図２に示されるように、特定のサブフレームで信号を送信するか否かを示す情報を０、１で示す。Ｄ２Ｄでは、通常、同じ上りリンクリソースを使っているため、送受信に制限がある。そのため、サブフレームごとに送受信を規定する必要がある。

ＭＣＳは５ビットで６４ＱＡＭ（Quadrature Amplitude Modulation）は適用されず、ＴＡ（Time Adjustment）はＰＳＳＣＨ受信の時間調整に用いられる。

グループ宛先ＩＤは、Ｄ２Ｄでは基本的にブロードキャストベースの設計がなされており、Ｄ２Ｄを行う通信端末は、到達する信号をすべて受信している。このため、Ｄ２Ｄにおいて、多くの通信端末がデータの送信を行った場合、受信側の通信端末ではバッテリの消費が早くなることが考えられる。

上述したように、Ｒｅｌ．１３のＤ２Ｄでは、レイヤ３のリレーを規定することが検討されており、カバレッジ内の通信端末（ユーザ端末）がリモートＵＥとの間でＤ２Ｄを行うとともに、リレー装置として機能し、無線基地局からのデータを中継することが考えられている。これにより無線基地局のカバレッジが拡大する。

例えば、図３に示される無線通信システムでは、リレー装置として機能するユーザ端末ＵＥ１が、無線基地局から送られた異なるデータを、カバレッジ外に位置するリモートＵＥ２、リモートＵＥ３にそれぞれ中継することが想定されている。この場合、ユーザ端末ＵＥ１は、図４に示されるように、リモートＵＥ２用にＭＡＣＰＤＵ１を生成するとともに、リモートＵＥ３用にＭＡＣＰＤＵ２を生成する。さらに、ユーザ端末ＵＥ１はリモートＵＥ２を特定する宛先ＩＤ１を生成し、リモートＵＥ３を特定する宛先ＩＤ２を生成する。宛先ＩＤ１には、リモートＵＥ２のレイヤ２の宛先ＩＤにおけるＬＳＢ（Least Significant Bit）８ビットが適用される。また、宛先ＩＤ２には、リモートＵＥ３のレイヤ２の宛先ＩＤにおけるＬＳＢ８ビットが適用される。

この後、ユーザ端末ＵＥ１は、生成された宛先及びデータを無線リソースに割り当てる処理を行う。ただし、上述のように、Ｄ２Ｄにおいては、１ＰＳＣＣＨ周期で１回のデータ送信を１つのリモートＵＥ（又は１つの宛先グループ）に送ることしかできない。このため、図５Ａ及び図５Ｂに示されるように、リモートＵＥ２へのデータ送信とリモートＵＥ３へのデータ送信とが異なるＰＳＣＣＨ周期で行われるように、無線リソースを宛先ＩＤ及び送信データに割り当てる。

すなわち、１つ目のＰＳＣＣＨ周期でリモートＵＥ２、ＵＥ３のいずれか一方に宛てたデータ送信を行った後、２つ目以降のＰＳＣＣＨ周期で他方に宛てたデータ送信を行うことになる。このため、各リモートＵＥにおいてデータ受信の遅延が発生することが考えられる。特に、送信データが音声データである場合には、このような遅延はユーザビリティの低下につながる。

また、カバレッジの拡大において、リレー装置として機能する通信端末は多くのリモートＵＥと通信することが望まれるが、アクセスするリモートＵＥ数が増加することに比例して、データ受信の遅延発生が増加することが考えられる。

本願発明者らは、レイヤ１−レイヤ３におけるグループ宛先ＩＤに着目し、さらに、少なくともレイヤ３における宛先ＩＤではリモートＵＥを個別に特定できることにも着目することで本発明に至った。

（態様１〜３の共通構成と概略）
図６には、本実施の形態における無線通信システムの概略構成が示されている。通信端末ＵＥ１は、Ｄ２Ｄをサポートする（Ｄ２Ｄディスカバリ及びＤ２Ｄコミュニケーション可能な）ユーザ端末であり、無線基地局のカバレッジ内に位置する。また、リモートＵＥ２、リモートＵＥ３は、Ｄ２Ｄをサポートするユーザ端末であり、上記カバレッジ外に位置する。

通信端末ＵＥ１は、リモートＵＥ２、ＵＥ３との間でＤ２Ｄに基づいた通信を行う。また、通信端末ＵＥ１は、無線基地局から送信されたデータをカバレッジ外のリモートＵＥ２、ＵＥ３に送信する、いわゆるリレー装置としても機能する。なお、通信端末ＵＥ１は、ユーザにより携帯可能な通信端末でも、上記無線基地局のカバレッジ内に配置された固定の通信端末であってもよい。本実施の形態において、通信端末ＵＥ１は、単一のＰＳＣＣＨ周期でリモートＵＥ２、ＵＥ３に宛てて異なるデータを送信する。

各態様については後述するが、態様１では、図７Ａに示されるように、レイヤ１（Ｌ１）、レイヤ２（Ｌ２）、レイヤ３（Ｌ３）の各宛先ＩＤが、リモートＵＥ２、リモートＵＥ３に対して異なるように設定される。態様２では、図７Ｂに示されるように、各リモートＵＥに対して同じＬ２グループＩＤが設定される。態様３では、図７Ｃに示されるようにＬ２宛先ＩＤのＬＳＢ８ビットが各リモートＵＥに対して同じになるように設定される。

ただし、態様１では、リモートＵＥ２がＡＡＡ、リモートＵＥ２がＢＢＢとなっているが全てのビットが異なっている必要はなく、ＡＡＡ、ＢＢＢの組み合わせが異なっていればよい。例えば、Ｌ２の１ビットでも異なっていればよい。態様２では、リモートＵＥ間でＬ２が共通になる。態様３では、物理層（Ｌ１）では必ずグループ受信できるが、Ｌ２のＩＤとしてはリモートＵＥごとに違う必要がある。このため、末尾８ビットがリモートＵＥで共通、残りのビット（２４−８＝１６ビット）の内の少なくとも１ビットがＵＥで異なる。

（態様１）
態様１について、図７Ａ、図８、図９を参照して説明する。
上述のように、態様１では、Ｌ１、Ｌ２、Ｌ３の各宛先ＩＤが、リモートＵＥ２、リモートＵＥ３に対して異なるように設定される（図７Ａ）。このため、通信端末ＵＥ１は、送信データ（複数のＭＡＣＰＤＵ）を送信するためのＨＡＲＱエンティティをリモートＵＥ２、ＵＥ３ごとに備える（図８）。また、異なるＨＡＲＱエンティティ間のスケジューリング（例えば、ＰＳＣＣＨリソースおよびデータＴ−ＲＰＴ（Time−Resource Pattern）選択）は独立に（independent）行われてもよく、また、従属して（dependent）行われてもよい。

図８に示されるように、通信端末ＵＥ１において、ＭＡＣレイヤには、ＳＬＨＡＲＱ１、ＳＬＨＡＲＱ２といった異なるＨＡＲＱエンティティ／プロセスが構成される。ＳＬＨＡＲＱ１は、リモートＵＥ２宛てのＲＬＣ（Radio Link Control）ＰＤＵ（Packet Data Unit）（ＭＡＣ（Media Access）ＳＤＵ（Service Data Unit）１）にＭＡＣ用ヘッダを付加してＭＡＣＰＤＵ１を生成する。一方、ＳＬＨＡＲＱ２は、リモートＵＥ３宛てのＲＬＣＰＤＵ（ＭＡＣＳＤＵ２）にＭＡＣ用ヘッダを付加してＭＡＣＰＤＵ２を生成する。

通信端末ＵＥ１はリモートＵＥ２を特定する宛先ＩＤ１を生成し、リモートＵＥ３を特定する宛先ＩＤ２を生成する。ＰＳＣＣＨの宛先ＩＤ１には、リモートＵＥ２のレイヤ２の宛先ＩＤにおけるＬＳＢ８ビットが適用される。ＰＳＣＣＨの宛先ＩＤ２には、リモートＵＥ３のレイヤ２の宛先ＩＤにおけるＬＳＢ８ビットが適用される。

通信端末ＵＥ１は、ＰＳＣＣＨリソースプールに、生成された宛先ＩＤ１及び宛先ＩＤ２を割り当てる。例えば、図９に示されるように、宛先ＩＤ１及び宛先ＩＤ２が時間軸上で重複しないように、異なるサブフレームのリソースが宛先ＩＤ１及び宛先ＩＤ２それぞれに割り当てられる。周波数ホッピングを行った場合であっても、同図に示されるように、異なるサブフレームのリソースが、周波数ホッピング先の宛先ＩＤ１及び宛先ＩＤ２に割り当てられる。

通信端末ＵＥ１は、ＰＳＳＣＨリソースプールに、生成されたＭＡＣＰＤＵ１及びＭＡＣＰＤＵ２を割り当てる。例えば、図９に示されるように、ＭＡＣＰＤＵ１及びＭＡＣＰＤＵ２が時間軸上で重複しないように、異なるサブフレームのリソースがＭＡＣＰＤＵ１及びＭＡＣＰＤＵ２それぞれに割り当てられる。周波数ホッピングを行った場合であっても、同図に示されるように、異なるサブフレームのリソースが、ＭＡＣＰＤＵ１及びＭＡＣＰＤＵ２に割り当てられる。

このようなリソース割り当てが行われることで、単一のＰＳＣＣＨ周期で、複数のリモートＵＥに異なるデータを送ること、言い換えると、パラレルにデータを送信することができる。

なお、上述のようにＤ２Ｄにおいては、上りリンクが用いられるため基本的にはシングルキャリアとなる。また、Ｌ２のグループＩＤは「ユニキャストＩＤ」「グループキャストＩＤ」「ブロードキャストＩＤ」の３種類に分類することができ、態様１で通知されるＩＤはユニキャストＩＤとなる。ユニキャストのＬ２のＩＤは、先ずはＳＣＩ（Sidelink Control Information）中の８ビットを使った宛先ＩＤとして用いられ、ＭＡＣＰＤＵのＭＡＣヘッダの中に残りのユニキャストＩＤのビット列が入ることになる。

態様１では、リモートＵＥ２、ＵＥ３ごとに、サイドリンクＨＡＲＱエンティティが分けられており、異なる宛先に対応する複数のＨＡＲＱエンティティが通信端末ＵＥ１に存在する。１つのＰＳＣＣＨ（ＳＣＩ）に関連付けられている複数のＭＡＣＰＤＵが同じリモートＵＥに送られる。単一のＰＳＣＣＨ周期において、複数のＰＳＣＣＨ（ＳＣＩ）及びそれに対応するデータ送信を行ってもよい。

異なるリモートＵＥに対してＰＳＣＣＨ又はデータの送信が同じサブフレームにおいて発生した場合（複数送信の発生）、通信端末ＵＥ１は、受信側のリモートＵＥの機能が対応可能であれば、態様１の複数の送信（不連続な割り当て）を行ってもよい。もしくは、通信端末ＵＥが、単一の送信を選択し、それ以外の送信を破棄してもよい。

上述の異なるＨＡＲＱエンティティ／プロセスによる、ＰＳＣＣＨ（ＳＣＩ）及びデータリソース選択は、独立に行われてもよい。ただし、リソースコリジョン（resource collision）や周波数セグメンテーション（frequency segmentation）が生じた場合、送信をランダムに破棄してもよい。

また、上記ＰＳＣＣＨ（ＳＣＩ）及びデータリソース選択が関連して行われる場合、各ＰＳＣＣＨ（ＳＣＩ）用のＰＳＣＣＨ（ＳＣＩ）リソースインデックスが、全てのインデックスからランダムに選択されてもよい。これにより、ＰＳＣＣＨ（ＳＣＩ）の全ての送信において、周波数セグメンテーションが生じない。もしくは、あらゆるパターンからデータＴ−ＲＰＴインデックスが選択されてもよい。この場合、Ｄ２Ｄデータの全ての送信において周波数セグメンテーションが発生しない。

異なるＨＡＲＱエンティティ／プロセス間（リモートＵＥ間）のスケジューリングには、異なったユーザ端末に対する基地局のスケジューリング（例えば、ラウンドロビンやＰＦ）に類似する手法を適用してもよい。

様態１において基地局からのＤ２Ｄリソース割り当て（モード１リソース割り当て）を行う場合、１送信端末に対して複数のＤＣＩ（Downlink Control Information）を送信してリソース割り当てを行う必要がある。このとき、同一のＤＣＩフォーマットを用いてＰＤＣＣＨまたはＥＰＤＣＣＨで複数ＤＣＩが送信され得るため、端末は該当するＤＣＩフォーマットが検出された場合もすべてのサーチスペースについて検出を試みる。

（態様１−１）
上述のように、Ｄ２Ｄのモード１リソース割り当てにおいては、１つの送信端末に対して複数のＤＣＩが送信される。しかしながら、上述のように１つのＰＳＣＣＨ周期（又はＳＣ（Sidelink Control）期間）では、１つのＤＣＩしか送信されないため、この結果、１つのサイドリンクグラント（Sidelink Grant）しか送信されない。このサイドリンクグラントは、ＳＣＩやデータの送信で用いられるサブフレームセットを特定することに用いることができる。なお、ＳＣ期間は、時系列上で繰り返される所定の長さであるため、ＳＣ周期と呼んでもよい。

ＳＣ周期は、例えば４０ｍｓ以上の長さを有するため、複数のサブフレームが含まれる。このため、いくつかのサブフレームでサイドリンクグラントを送信することが考えられるが（例えば、無線基地局による特定ユーザ端末に宛てたサイドリンクグラントの送信）、所定のサブフレーム後（例えば、４サブフレーム以降）に送られたサイドリンクグラントは先のサイドリンクグラントに上書きされる（図２０参照）。

態様１−１では、Ｄ２Ｄの送信端末として機能するユーザ端末において、複数のサイドリンクグラントを設定できるように構成する。例えば、図２１に示されるように、所定のサブフレーム数（例えば、４サブフレーム）以内であれば、複数のサイドリンクグラントの設定が可能となるようにユーザ端末を構成する。具体的には、図２１では、４サブフレーム以内に送信されたサイドリンクグラント＃１−＃３がユーザ端末で設定される。

ただし、複数のサイドリンクグラントが設定された後であって、所定のサブフレーム数以降にサイドリンクグラントを受信した場合、ユーザ端末側では、先に設定されたサイドリンクグラントのいずれのサイドリンクグラントに新たに送信されたサイドリンクグラントを上書きするのか判断できない。例えば、図２１においては、ユーザ端末はサイドリンクグラント＃４を受信した際、先に設定されているサイドリンクグラント＃１−＃３の内のいずれに対してサイドリンクグラント＃４を上書きするのか判断できない。

このため、ユーザ端末において、所定サブフレーム数以降であって、かつ、サイドリンクグラントを受信した場合に、ユーザ端末は、先に設定されたサイドリンクグラントをクリア（消去）し、新たにサイドリンクグラントを設定するように構成する。具体的には、図２１において、４サブフレーム数以降にサイドリンクグラント＃４が送信された場合、ユーザ端末は、先に設定されたサイドリンクグラント＃１−＃３をクリアし、新たにサイドリンクグラント＃４を設定する。

このように態様１−１によれば、既存のＤＣＩを用いた場合であっても、複数のサイドリンクグラントを設定することが可能となり、Ｄ２Ｄにおいて複数のリモートＵＥに対して効率よくデータを送信することができる。言い換えると、１つのＳＣ期間において、異なるグループＩＤ（特定情報）に対する複数のＳＣＩを送信することができる。なお、上述したように、態様１−１はＤ２Ｄのユーザ端末に適用することができる。このため、Ｄ２Ｄのユーザ端末間でリレー処理が行われる場合も態様１−１を同様に適用することができる。

（態様１−２）
次に、図２２を参照して態様１−２について説明する。態様１−２では、Ｄ２Ｄのユーザ端末に対して、サイドリンクグラントの書き換え要否を明示的に指示する（サイドリンクグラント番号（インデックス）を明示的に対応させる）ものである。対応づけにあたっては、ＤＣＩフォーマットの使用されていないビットフィールド（特定ビットフィールド）が用いられ、サイドリンクグラントインデックス（又は、書き換え又は新規サイドリンクグラント）が特定される。

特定ビットフィールドとしては、周波数ホッピングフラグなどの既存のビットフィールドの一部やゼロパディングによって使用されていないビットフィールドを用いてもよい。例えば、ＤＣＩフォーマット５は、ＤＣＩフォーマット０と同じペイロード長に設定するため、ゼロパディングされている。このゼロパディングされたビットフィールドを用いることができる。

ただし、周波数ホッピングフラグなどの本来使用されているビットフィールドを用いる場合には、このビットフィールドがサイドリンクグラントインデックス（又は、書き換え又は新規サイドリンクグラント）を特定するために用いられるということを、予めＲＲＣなどのハイヤレイヤシグナリングで通知してもよい（準静的（semi-static）に設定してもよい）。

図２２においては、サイドリンクグラント＃１が設定された後に、サイドリンクグラント＃２、＃３が順次送信されている。この際、特定ビットフィールドには上書きを示す“０”が特定ビットフィールド（Field X）に設定されているため、ユーザ端末はサイドリンクグラント＃１にサイドリンクグラント＃２を上書きする。

一方、サイドリンクグラント＃２の後に送信されたサイドリンクグラント＃３については、特定ビットフィールドには、新規のサイドリンクグラントを示す“１”が書き込まれているため、ユーザ端末はサイドリンクグラント＃３を新たに設定する。

このように態様１−２によれば、既存のＤＣＩを用いた場合であっても、複数のサイドリンクグラントを設定することが可能となり、Ｄ２Ｄにおいて複数のＵＥに対して効率よくデータを送信することができる。言い換えると、１つのＳＣ期間において、異なるグループＩＤに対する複数のＳＣＩを送信することができる。なお、上述したように、態様１−２はＤ２Ｄのユーザ端末に適用することができる。このため、Ｄ２Ｄのユーザ端末間でリレー処理が行われる場合も態様１−２を同様に適用することができる。

（態様１−３）
次に、図２３を参照して態様１−３について説明する。態様１−３では、既存のＤＣＩフォーマットを用い、サーチスペースを分割して、サイドリンクグラントを特定する情報（例えば、宛先インデックスやサイドリンクグラントインデックス）に予め対応付けるものである。ＰＳＣＣＨ周期内には複数のサーチスペース候補が含まれているため、この内のサーチスペースが時間・周波数分割されて上記対応付けに用いられる。

サーチスペースの分割にあたっては、ＲＮＴＩ又は時間−周波数リソースを用いることもできる。分割により生成されたサブサーチスペースは、上述のように宛先インデックスやサイドリンクグラントインデックスに対応付けられる。対応付けはＲＲＣシグナリングなどのハイヤレイヤシグナリングで通知される。

図２３では、サブフレーム＃ａでサイドリンクグラント＃１が送信され、その後、４サブフレーム後のサブフレーム＃ａ＋４でサイドリンクグラント＃２が送信されている。その後、さらに２サブフレーム後のサブフレーム＃ａ＋６でサイドリンク＃１が送信されている。ユーザ端末は、サブサーチスペースからサイドリンクグラント＃１、＃２を特定することができるため、サブフレーム＃ａ＋６において、受信したサイドリンクグラント＃１を、サブフレーム＃ａで設定したサイドリンクグラント＃１に上書きする。

このように態様１−３によれば、既存のＤＣＩを用いた場合であっても、複数のサイドリンクグラントを設定することが可能となり、Ｄ２Ｄにおいて複数のリモートＵＥに対して効率よくデータを送信することができる。言い換えると、１つのＳＣ期間において、異なるグループＩＤに対する複数のＳＣＩを送信することができる。なお、上述したように、態様１−３はＤ２Ｄのユーザ端末に適用することができる。このため、Ｄ２Ｄのユーザ端末間でリレー処理が行われる場合も態様１−３を同様に適用することができる。

また、上記態様１−１〜１−３においては、既存のＤＣＩフォーマットが用いられている。しかしながら、例えば、サイドリンクグラントを特定する情報（例えば、宛先インデックスやサイドリンクグラントインデックス）が組み込まれている新たなＤＣＩフォーマットを設定してもよい。

（態様２）
次に、態様２について、図７Ｂ、図１０、図１１を参照して説明する。
上述のように態様２では、図７Ｂに示されるように、各リモートＵＥに対して同じＬ２グループＩＤが設定される。すなわち、通信端末ＵＥ１により中継されたデータを受信する全てのリモートＵＥには同じＬ２グループＩＤが設定される。このようなグループＩＤは、Ｄ２Ｄディスカバリで用いられる信号／通知（カバレッジ内のユーザ端末からカバレッジ外のユーザ端末に向けた信号／通知）にグループＩＤを含ませることで、リモートＵＥに対するグループＩＤの通知を実現してもよい。

通信端末ＵＥ１のＭＡＣレイヤでは、送信データ（下りリンクデータ）がいずれのリモートＵＥに宛てたものであるのか判断することができない。しかしながら、ハイヤレイヤ（ＲＬＣ／ＰＤＣＰ／ＩＰ）では、異なるリモートＵＥに対するデータをマルチプレクシング（デマルチプレクシング）することができる（図１０）。

また、同図に示されるように、通信端末ＵＥ１のＭＡＣレイヤには、ＳＬＨＡＲＱが構成されており、このＳＬＨＡＲＱは、リモートＵＥ２宛てのＲＬＣＰＤＵ（ＭＡＣＳＤＵ１）にＭＡＣ用ヘッダを付加してＭＡＣＰＤＵ１を生成する。一方、ＳＬＨＡＲＱ２は、リモートＵＥ３宛てのＲＬＣＰＤＵ（ＭＡＣＳＤＵ２）にＭＡＣ用ヘッダを付加してＭＡＣＰＤＵ２を生成する。通信端末ＵＥ１はリモートＵＥ２／ＵＥ３を特定するグループＩＤを生成する。

通信端末ＵＥ１は、ＰＳＣＣＨリソースプールに、設定または生成されたグループＩＤを割り当てる（図１１）。図１１に示されるＰＳＣＣＨリソースプールでは、周波数ホッピングが行われている。また、通信端末ＵＥ１は、ＰＳＳＣＨリソースプールに、生成されたＭＡＣＰＤＵ１及びＭＡＣＰＤＵ２を割り当てる。例えば、図１１に示されるように、ＭＡＣＰＤＵ１及びＭＡＣＰＤＵ２が時間軸上で重複しないように、異なるサブフレームのリソースがＭＡＣＰＤＵ１及びＭＡＣＰＤＵ２それぞれに割り当てられる。周波数ホッピングを行った場合であっても、同図に示されるように、異なるサブフレームのリソースが、ＭＡＣＰＤＵ１及びＭＡＣＰＤＵ２に割り当てられる。

このようなリソース割り当てが行われることで、単一のＰＳＣＣＨ周期で、複数のリモートＵＥごとの送信データを送ることができる。図１０及び図１１では、リモートＵＥ２用の送信データとリモートＵＥ３用の送信データとが、通信端末１のＭＡＣレイヤにおいて区別できないため、同じハッチングが施されている。しかしながら、Ｌ３の宛先ＩＤは、リモートＵＥごとに異なっているため、各リモートＵＥは、Ｌ３の宛先ＩＤを用いて自身宛ての送信データであるか否か判断することができる。

また、態様２において、通信端末ＵＥ１とＤ２Ｄを行う全てのリモートＵＥは、同じグループ宛先Ｌ２ＩＤを用いてデータの受信を行う。ここで、グループ宛先Ｌ２ＩＤは、通信端末ＵＥ１（リレー装置）を選択する前に、リレーＵＥからのアナウンスメントに含まれてもよい。もしくは、グループ宛先Ｌ２ＩＤは、リモートＵＥによる通信端末（リレー装置）が選択された後に、通信端末からリモートＵＥ宛ての信号で通知するようにしてもよい。また、複数の異なった通信端末がリレー装置として用いられる場合、宛先Ｌ２ＩＤを通信端末ごとに異なるように設定してもよい。

態様２では、物理レイヤ（ＰＨＹ）及びＭＡＣレイヤでは、全リモートＵＥに宛てられる送信データ（ＤＬデータ）全てがリモートＵＥで受信される。ＰＤＣＰ／ＲＬＣ／ＩＰレイヤなどのハイヤレイヤでは、異なるリモートＵＥに宛てたデータのマルチプレクシング／デマルチプレクシングを制御してもよい。

リモートＵＥのＤＬ受信に使用されるグループ宛先Ｌ２ＩＤは、通信端末ＵＥ１（リレー装置）からリモートＵＥに送信される。全てのリモートＵＥは、同じグループ宛先Ｌ２ＩＤを用いてＤＬデータ受信を行う。

ここで、Ｄ２Ｄを用いた中継処理（リモートＵＥのＤＬ受信）を行うための通信フローを図１２を参照して説明する。

同図に示されるように、無線基地局（ｅＮＢ）、その無線基地局のカバレッジ内に位置する通信端末（ＰｒｏＳｅＵＥ−ｔｏ−ＮＷリレー）、ＭＭＥ（Mobility Management Entity）、ＳＧＷ（Signaling Gateway）、及び、ＰＧＷ（Packet Data network Gateway）は、Ｅ−ＵＴＲＡＮイニシャルアタッチ、及び、ＵＥ要求のＰＤＮコネクティビティが行われている（ステップ１）。

通信端末とリモートＵＥとはディスカバリ処理を行い、Ｄ２Ｄコミュニケーション可能な端末を発見する（ステップ２）。このようなディスカバリ処理には、Ｒｅｌ．１２で規定されているモデルであって、アナウンシングとモニタリングで端末を発見するモデルＡがある。また、Ｒｅｌ．１２にサポートされていないモードであって、リクエストとレスポンスで端末を発見するモデルＢもある。

次に、リモートＵＥは、ディスカバリ処理によって通信端末（ＰｒｏＳｅＵＥ−ｔｏ−ＮＷリレー）が１つ以上発見された場合、いずれの通信端末をリレー装置として用いるのかを決める通信端末選択処理を行う（ステップ３）。この際、リモートＵＥは関連するＰＤコネクションを選択してもよい。

この後、リモートＵＥと通信端末との間で、リモートＵＥＩＰアドレス用の処理が行われる。ここでは、リモートＵＥから通信端末に宛ててルータ要請が行われ（ステップ４）、このルータ要請に応じて通信端末からリモートＵＥに宛ててルータ広告が送られる（ステップ５）。

以上の処理が行われた後に、Ｄ２Ｄを用いたリレー処理が実施される。ＤＬ受信Ｌ２ＩＤを通知する信号は、それのみで独自の信号（separate signal）であっても、通信端末（リレー装置）からリモートＵＥへの他の信号を組み合わせてもよい。例えば、ＤＬ受信のための２４ビットＩＤであるグループＩＤは、図１２、ステップ２のディスカバリ処理のディスカバリメッセージに含まれてもよい。言い換えると、上記グループ宛先Ｌ２ＩＤは、モデルＡにおいて、２４ビットのグループＩＤとしてディスカバリメッセージに含めるように構成し、リモートＵＥに通知するようにしてもよい。

また、ＤＬ受信Ｌ２ＩＤを通知する信号は、Ｄ２Ｄディスカバリチャネルもしくはコミュニケーションチャネルを用いることができる独自の信号を設計してもよい。さらに、図１２に示されるように、グループ宛先Ｌ２ＩＤ（ＤＬ受信レイヤ２ＩＤ）は、リモートＵＥＩＰアドレス用の処理の後に、通信端末からリモートＵＥに通知されるようにしてもよい。リレーＵＥのアドレス（例えばＩＰアドレスやＬ２アドレスなど）を元に予め定められたルールにもとづいてグループＩＤを生成することでシグナリングのオーバヘッドを削減してもよい。

上述した、Ｌ２グループ宛先ＩＤの通知方法は、いわゆる、Ｌ２グループ宛先ＩＤをイクスプリシット（explicit）に通知する方法であると言える。しかしながら、このようなイクスプリシットな通知方法以外にも、ディスカバリメッセージの一部やＩＰアドレスを用いて、Ｌ２グループ宛先ＩＤを自動的に構成するという方法も考えられる。

（態様３）
次に態様３について図７Ｃ、図１３、図１４を参照して説明する。
上述のように、態様３では、図７Ｃに示されるようにＬ２宛先ＩＤのＬＳＢ８ビットが各リモートＵＥに対して同じになるように設定される。通信端末ＵＥ１をリレー装置として用いる全てのリモートＵＥは、Ｌ２宛先ＩＤの下位８ビット（ＬＳＢ８ビット）を共通に用いる。ただし、Ｌ２宛先ＩＤのＭＳＢ１６ビット（Ｌ２宛先ＩＤの２４ビットからＬＳＢ８ビットを差し引いた残りのビット）はリモートＵＥ間で異なる。

態様３では、リモートＵＥにおけるフィルタリングをＬ２とＬ３とで行うが、そもそもＬ１のＩＤというのはＬ２のＩＤの一部を用いている。このため、Ｌ２ＩＤの一部をリモートＵＥで共通に用いて、残りを固有に使うという概念に態様３は基づいている。

通信端末ＵＥ１のＭＡＣレイヤには、図１３に示されるように、ＳＬＨＡＲＱが構成されており、このＳＬＨＡＲＱ１は、異なるリモートＵＥに対するデータをマルチプレクシング（デマルチプレクシング）する。具体的には、ＳＬＨＡＲＱ１は、リモートＵＥ２宛てのＲＬＣＰＤＵ（ＭＡＣＳＤＵ１）にＭＡＣ用ヘッダを付加してＭＡＣＰＤＵ１を生成する。また、ＳＬＨＡＲＱ１は、リモートＵＥ３宛てのＲＬＣＰＤＵ（ＭＡＣＳＤＵ２）にＭＡＣ用ヘッダを付加してＭＡＣＰＤＵ２を生成する。通信端末ＵＥ１はリモートＵＥ２／ＵＥ３を特定するグループＩＤを生成する。

通信端末ＵＥ１は、ＰＳＣＣＨリソースプールに、生成されたグループＩＤを割り当てる（図１４）。図１４に示されるＰＳＣＣＨリソースプールでは、周波数ホッピングが行われている。また、通信端末ＵＥ１は、ＰＳＳＣＨリソースプールに、生成されたＭＡＣＰＤＵ１及びＭＡＣＰＤＵ２を割り当てる。例えば、図１４に示されるように、ＭＡＣＰＤＵ１及びＭＡＣＰＤＵ２が時間軸上で重複しないように、異なるサブフレームのリソースがＭＡＣＰＤＵ１及びＭＡＣＰＤＵ２それぞれに割り当てられる。周波数ホッピングを行った場合であっても、同図に示されるように、異なるサブフレームのリソースが、ＭＡＣＰＤＵ１及びＭＡＣＰＤＵ２に割り当てられる。

このようなリソース割り当てが行われることで、単一のＰＳＣＣＨ周期で、複数のリモートＵＥごとの送信データを送ることができる。

リモートＵＥおいて、通信端末ＵＥ（リレー装置）から送られるＤＬデータを受信するために用いられるＬ２宛先ＩＤは、通信端末ＵＥから通知される。また、単一のＰＳＣＣＨ周期（ＳＡ周期）では、単一のＰＳＣＣＨ（ＳＣＩ）が複数のリモートＵＥに宛てられたＭＡＣＰＤＵに割り当てられるリソースを示す。

なお、態様３におけるＤ２Ｄを用いた中継処理（リモートＵＥのＤＬ受信）を行うための通信処理については、上述の態様２と概ね同様のステップを踏まえるため詳細な説明は省略する。

態様３では、ＤＬ受信Ｌ２ＩＤを通知するための信号は、それのみで独自の信号（separate signal）であっても、通信端末（リレー装置）からリモートＵＥへの他の信号を組み合わせてもよい。この際、Ｄ２Ｄディスカバリのチャネル、もしくはＤ２Ｄコミュニケーションのチャネルを使用してもよい。リモートＵＥ間で共通のＬＳＢ８ビットは様態２と同様にして設定し、リモートＵＥ間で独立のＬ２宛先ＩＤのＭＳＢ１６ビットは各リモートＵＥのＬ２ＩＤに基づいて予め定められたルールにもとづいて生成してもよい。例えば、それぞれ元になるＩＤの先頭や末尾の数ビットを用いることが考えられる。また、リモートＵＥにおいて、オリジナルのＬ２ＩＤは、他のＤ２Ｄデータ／信号の受信に使用してもよい。

上記実施の形態では、リモートＵＥは無線基地局のカバレッジに位置することを前提として説明しているがこれに限らない。ユーザ端末は、カバレッジ内に存在している場合であっても、Ｄ２Ｄを行う他のユーザ端末をリレー装置として指定し、無線基地局から送信されるデータを中継するように処理してもよい。特に、カバレッジ外に位置するユーザ端末が、無線基地局のカバレッジ内に移動した場合に、Ｄ２Ｄによるリレー処理を継続するようにしてもよい。

このような態様３ではＬ２宛先ＩＤのＭＳＢ１６ビット（Ｌ２宛先ＩＤの２４ビットからＬＳＢ８ビットを差し引いた残りのビット）はリモートＵＥ間で異なることが前提とされているが、複数のリモートＵＥ間でこのＭＳＢ１６ビットが一致した場合、すなわち、ＬＳＢ８ビット書き換え後（共通化後）に複数リモートＵＥ間でＬ２宛先ＩＤ（ＭＳＢ１６ビット）が衝突（conflict）した場合の対策は有効であると考えられる。

図２４は、このようなＬ２宛先ＩＤが衝突する一例を説明するための図である。なお、図２４では、説明のためＬＳＢ８ビットが左側に、ＭＳＢ１６ビットが右側に表示されている。同図では、同じグループに属するリモートＵＥ２とリモートＵＥ３とのＬ２宛先ＩＤが示されている。これらのＬ２宛先ＩＤでは、ＬＳＢ８ビットの内の１ビットのみが異なっている。上述の態様３では、ＬＳＢ８ビットは、ＳＣＩに組み込まれる際、グループ内で共通のＩＤに書き換えられる（上書きされる）。

一方、ＭＳＢ１６ビットはＭＡＣヘッダに組み込まれるが、そもそも、リモートＵＥ２、ＵＥ３で異なっていたＩＤビットはＬＳＢ８ビットに含まれていたため、ＭＡＣヘッダに組み込まれるＭＳＢ１６ビットは、リモートＵＥ２、リモートＵＥ３間で同じビット列になる。このため、リモートＵＥ２、リモートＵＥ３は、データを受信する際に自身に宛てたデータであるのか否か判断することができない。

また、リレーＵＥや無線基地局からＬ２宛先ＩＤの分配（払い出し）が行われない場合も考えられるため、複数リモートＵＥ間でＬ２宛先ＩＤ（ＭＳＢ１６ビット）が衝突した場合の対策は有効であると考えられる。以上、端末間でリレーを行う場合で説明したが、同様にリレーを用いない場合にも複数端末に宛てたデータを送信するためにＳＣＩ上の宛先ＩＤを上書きすることは有効であり、同様のＬ２宛先ＩＤの衝突対策は適用可能であると考えられる。

（態様３−１）
ここで、態様３−１を図２５を参照して説明する。なお、図２５では、説明のためＬＳＢ８ビットが左側に、ＭＳＢ１６ビットが右側に表示されている。態様３−１は、複数ＵＥ間でＬ２宛先ＩＤ（ＭＳＢ１６ビット）が衝突した場合の対策が施されている。態様３−１では、図２５に示されるように、新たなＭＡＣヘッダが定義されている。このＭＡＣヘッダは、ＬＳＢ８ビットがグループＩＤへ上書きされる前のＬ２宛先ＩＤ（２４ビット）全てを含んでいる。このため、ＳＣＩにおいて、ＬＳＢ８ビットがグループＩＤに上書きされる場合であっても、Ｄ２Ｄの受信端末ＵＥ４、ＵＥ５においてＬ２宛先ＩＤの識別が可能となる。

新しいＭＡＣヘッダと既存のＭＡＣヘッダとを区別するために、新たなＭＡＣヘッダに対応するバージョンＩＤを定義する必要がある。また、各ＵＥ４、ＵＥ５は、ＬＳＢ８ビットが書き換えられる前のＬ２宛先ＩＤと、ＬＳＢ８ビットが書き換えられた後のＬ２宛先ＩＤとの双方を、自身のＬ２宛先ＩＤであると認識できるように設定される。

既存のＭＡＣヘッダおよび新しいＭＡＣヘッダのいずれを用いて送信するかは基地局から送信端末に対して上位レイヤシグナリングや物理レイヤシグナリングで通知してもよいし、送信端末が自律的に選択してもよい。上位レイヤシグナリングで通知する場合、ＭＡＣヘッダのバージョンを通知してもよいし、ＲＮＴＩごとに適用するＭＡＣヘッダのバージョンを指定してもよい。

このように態様３−１によれば、ＳＣＩに含まれるＬＳＢ８ビットが複数のＵＥで共通になるように書き換えられた場合であっても、各ＵＥにおいて、ＭＡＣヘッダでＬ２宛先ＩＤを識別することができる。これにより、Ｄ２Ｄにおいて複数のＵＥに対して効率よくデータを送信することができる。なお、上述の説明から明らかなように、態様３−１はＤ２Ｄのユーザ端末に適用することができる。このため、Ｄ２Ｄのユーザ端末間でリレー処理が行われる場合も態様３−１を同様に適用することができる。例えば、図３に示されるリモート端末ＵＥ２、ＵＥ３において、本態様を適用してもよい。

（態様３−２）
次に、態様３−２を図２６を参照して説明する。なお、図２６では、説明のためＬＳＢ８ビットが左側に、ＭＳＢ１６ビットが右側に表示されている。態様３−２では、Ｌ２宛先ＩＤの衝突が発生した場合にＵＥが自律的にＬ２宛先ＩＤを変更する。例えば、リレーに用いる場合で既にリレーＵＥとの間で通信が確立されている場合、リモートＵＥは、リレーＵＥとの間でＩＰアドレス用の処理（例えば、図１２のステップ３の後の処理）を再度開始する。

また、リレーに用いる場合でリモートＵＥがリレーＵＥとの間でリレー処理を行う（リレー通信の確立）前であれば、リモートＵＥが自身のＬ２宛先ＩＤ（ＭＳＢ１６ビット）をブロードキャストする。リモートＵＥのＬ２宛先ＩＤを受信したＵＥは、ブロードキャストされたＭＳＢ１６ビットが、自身のＬ２宛先ＩＤのＭＳＢ１６ビットと衝突しているか否かを判断し、衝突している場合には、その旨をリモートＵＥに通知する。リモートＵＥは、衝突している旨が他のＵＥから通知された場合、自身のＬ２宛先ＩＤのＭＳＢ１６ビットを変更する。

図２６では、ＵＥ５が自身のＬ２宛先ＩＤのＭＳＢ１６ビットが、ＵＥ４のＭＳＢ１６ビットと衝突していることを検出し、自身のＭＳＢ１６ビットの最下位ビットを「０」から「１」に変更している。

なお、上述した態様３−２における、ＵＥの処理、又は、Ｌ２宛先ＩＤがブロードキャストされたＵＥの処理は、ＵＥの動作として規定することが好ましい。また、ＵＥからのＬ２宛先ＩＤの通知にあたっては、上記ブロードキャストに限らず、ＰＳＳＣＨ及びＰＳＣＣＨを用いた通知や、ディスカバリ信号（ＰＳＤＣＨ）を用いてもよい。

このように態様３−２によれば、ＳＣＩに含まれるＬＳＢ８ビットが複数のＵＥで共通になるように書き換えられた場合であっても、Ｌ２宛先ＩＤのＭＳＢ１６ビットが適宜変更される。これにより、Ｄ２Ｄにおいて複数のＵＥに対して効率よくデータを送信することができる。なお、上述の説明から明らかなように、態様３−２はＤ２Ｄのユーザ端末（受信ユーザ端末）に適用することができる。このため、Ｄ２Ｄのユーザ端末間でリレー処理が行われる場合、リモート端末に対して態様３−２を同様に適用することができる。例えば、図３に示されるリモート端末ＵＥ２、ＵＥ３において、本態様を適用してもよい。

（態様３−３）
次に、態様３−３を説明する。態様３−３は、上記態様３−２と異なって、送信ＵＥにおいて、Ｌ２宛先ＩＤの衝突を検出する。リレーで用いる場合には、リレー処理を行う（リレー通信の確立）の直前又は直後に、リレーＵＥはＬ２宛先ＩＤの衝突を検出する。通常、リモートＵＥからリレーＵＥに対して何らかの要求が送信される場合、送信される情報にはリモートＵＥの受信Ｌ２宛先ＩＤが含まれている。リレーＵＥは、送信されたＬ２宛先ＩＤを用いて衝突の検出を行う。

送信ＵＥは、要求に含まれているＬ２宛先ＩＤのＭＳＢ１６ビットが、他の宛先ＵＥのＭＳＢ１６ビットと衝突しているか否かを判断し、衝突している場合には、その旨を宛先ＵＥに通知する。宛先ＵＥは、衝突している旨が他のＵＥから通知された場合、自身のＬ２宛先ＩＤのＭＳＢ１６ビットを変更する（図２６）。

送信ＵＥから受信ＵＥへの衝突の通知は、例えば、ＭＡＣコントロールシグナリングや、ＲＲＣシグナリングなどの上位レイヤのシグナリングを用いてもよい。また、上述した態様３−３における、リレーＵＥやリモートＵＥ処理は、ＵＥのプロシージャとして規定することが好ましい。

このように態様３−３によれば、ＳＣＩに含まれるＬＳＢ８ビットが複数のＵＥで共通になるように書き換えられた場合であっても、Ｌ２宛先ＩＤのＭＳＢ１６ビットが適宜変更される。これにより、Ｄ２Ｄにおいて複数の宛先ＵＥに対して効率よくデータを送信することができる。なお、上述の説明から明らかなように、態様３−３はＤ２Ｄのユーザ端末（送信ユーザ端末）に適用することができる。このため、Ｄ２Ｄのユーザ端末間でリレー処理が行われる場合、リレー端末に対して態様３−３を同様に適用することができる。例えば、図３に示されるリレー端末ＵＥ１において、本態様を適用してもよい。

態様３では異なるＬ２アドレスに対するデータ送信を共有リソースを用いて行うため、無線基地局からのＤ２Ｄ用リソース割り当ても共通になされなければならない。そのため、無線基地局に対して報告するＳｉｄｅｌｉｎｋＢＳＲ（Buffer Status Report）でリモートＵＥ間で共通のグループインデックスを用いて共通のＢＳＲを報告してもよい。そのために基地局に報告するＤ２Ｄ通信の宛先をリモートＵＥ間で共通の宛先ＩＤを用いて報告してもよい。例えば、Ｌ２宛先グループアドレスのうちリモートＵＥ間で異なるビット列をゼロとすることで共通化が図れる。あるいは、リレーグループ用の宛先を従来とは別のシグナリングで報告してもよい。

（無線通信システムの構成）
以下、本発明の一実施形態に係る無線通信システムの構成について説明する。この無線通信システムでは、本発明の実施形態に係る無線通信方法が適用される。なお、上述の態様１〜３は、それぞれ単独で適用されてもよいし、組み合わせて適用してもよい。ただし、上記態様１〜３内の複数を組み合わせる場合、通信端末とリモートＵＥとの間で、いずれの態様に対応するリレー処理が行われるかを示す情報が共有される必要がある。

図１５は、本発明の一実施形態に係る無線通信システムの概略構成の一例を示す図である。なお、図１５に示す無線通信システムは、例えば、ＬＴＥシステム、ＳＵＰＥＲ３Ｇ、ＬＴＥ−Ａシステムなどが包含されるシステムである。この無線通信システムでは、複数のコンポーネントキャリア（ＰＣＣ、ＳＣＣ、ＴＣＣ）を一体としたキャリアアグリゲーション（ＣＡ）及び／又はデュアルコネクティビティ（ＤＣ）を適用することができる。なお、この無線通信システムは、ＩＭＴ−Ａｄｖａｎｃｅｄと呼ばれても良いし、４Ｇ、５Ｇ、ＦＲＡ（Future Radio Access）などと呼ばれても良い。

図１５に示す無線通信システム１では、マクロセルを形成する無線基地局１０が配置され、このマクロセル内外にユーザ端末２０（２０ａ、２０ｂ）が位置する。

ユーザ端末２０ａは、無線基地局１０に接続することができる。ユーザ端末２０ｂは、ユーザ端末２０ａと同様の構成を備えるものの、無線基地局１０のカバレッジ外に位置するため、無線基地局１０に直接接続することはできない。

無線基地局１０は、上位局装置３０に接続され、上位局装置３０を介してコアネットワーク４０に接続される。なお、上位局装置３０には、例えば、アクセスゲートウェイ装置、無線ネットワークコントローラ（ＲＮＣ）、モビリティマネジメントエンティティ（ＭＭＥ）などが含まれるが、これに限定されるものではない。

なお、無線基地局１０は、相対的に広いカバレッジを有する無線基地局であり、マクロ基地局、集約ノード、ｅＮＢ（eNodeB）、送受信ポイントなどと呼ばれてもよい。また、無線基地局１２は、局所的なカバレッジを有する無線基地局であり、スモール基地局、マイクロ基地局、ピコ基地局、フェムト基地局、ＨｅＮＢ（Home eNodeB）、ＲＲＨ（Remote Radio Head）、送受信ポイントなどと呼ばれてもよい。各ユーザ端末２０は、ＬＴＥ、ＬＴＥ−Ａなどの各種通信方式に対応した端末であり、移動通信端末だけでなく固定通信端末を含んでよい。

無線通信システムにおいては、無線アクセス方式として、下りリンクについてはＯＦＤＭＡ（直交周波数分割多元接続）が適用され、上りリンクについてはＳＣ−ＦＤＭＡ（シングルキャリア−周波数分割多元接続）が適用される。ＯＦＤＭＡは、周波数帯域を複数の狭い周波数帯域（サブキャリア）に分割し、各サブキャリアにデータをマッピングして通信を行うマルチキャリア伝送方式である。ＳＣ−ＦＤＭＡは、システム帯域幅を端末毎に１つ又は連続したリソースブロックからなる帯域に分割し、複数の端末が互いに異なる帯域を用いることで、端末間の干渉を低減するシングルキャリア伝送方式である。なお、上り及び下りの無線アクセス方式は、これらの組み合わせに限られない。

無線通信システム１では、下りリンクのチャネルとして、各ユーザ端末２０ａで共有される下り共有チャネル（ＰＤＳＣＨ：Physical Downlink Shared Channel）、報知チャネル（ＰＢＣＨ：Physical Broadcast Channel）、下りＬ１／Ｌ２制御チャネルなどが用いられる。ＰＤＳＣＨにより、ユーザデータや上位レイヤ制御情報、所定のＳＩＢ（System Information Block）が伝送される。また、ＰＢＣＨにより、ＭＩＢ（Master Information Block）などが伝送される。

下りＬ１／Ｌ２制御チャネルは、ＰＤＣＣＨ（Physical Downlink Control Channel）、ＥＰＤＣＣＨ（Enhanced Physical Downlink Control Channel）、ＰＣＦＩＣＨ（Physical Control Format Indicator Channel）、ＰＨＩＣＨ（Physical Hybrid-ARQ Indicator Channel）などを含む。ＰＤＣＣＨにより、ＰＤＳＣＨ及びＰＵＳＣＨのスケジューリング情報を含む下り制御情報（ＤＣＩ：Downlink Control Information）などが伝送される。ＰＣＦＩＣＨにより、ＰＤＣＣＨに用いるＯＦＤＭシンボル数が伝送される。ＰＨＩＣＨにより、ＰＵＳＣＨに対するＨＡＲＱの送達確認信号（ＡＣＫ／ＮＡＣＫ）が伝送される。ＥＰＤＣＣＨは、ＰＤＳＣＨ（下り共有データチャネル）と周波数分割多重され、ＰＤＣＣＨと同様にＤＣＩなどを伝送するために用いられてもよい。

また、下りリンクの参照信号として、セル固有参照信号（ＣＲＳ：Cell-specific Reference Signal）、チャネル状態測定用参照信号（ＣＳＩ−ＲＳ：Channel State Information-Reference Signal）、復調用に利用されるユーザ固有参照信号（ＤＭ−ＲＳ：Demodulation Reference Signal）などを含む。

無線通信システム１では、上りリンクのチャネルとして、各ユーザ端末２０で共有される上り共有チャネル（ＰＵＳＣＨ：Physical Uplink Shared Channel）、上り制御チャネル（ＰＵＣＣＨ：Physical Uplink Control Channel）、ランダムアクセスチャネル（ＰＲＡＣＨ：Physical Random Access Channel）などが用いられる。ＰＵＳＣＨにより、ユーザデータや上位レイヤ制御情報が伝送される。また、ＰＵＣＣＨにより、下りリンクの無線品質情報（ＣＱＩ：Channel Quality Indicator）、送達確認信号（ＨＡＲＱ−ＡＣＫ）などが伝送される。ＰＲＡＣＨにより、セルとの接続確立のためのランダムアクセスプリアンブル（ＲＡプリアンブル）が伝送される。

無線通信システム１では、Ｄ２Ｄをサポートするチャネルとして、ＰＳＳＳ（Primary Sidelink Synchronisation Signal）、ＳＳＳＳ（Secondary Sidelink Synchronisation Signal）、ＰＳＢＣＨ（Physical Sidelink Broadcast Channel）、ＰＳＣＣＨ（Physical Sidelink Control Channel）、ＰＳＳＣＨ（Physical Sidelink Shared Channel）が用いられる。

＜無線基地局＞
図１６は、本発明の一実施形態に係る無線基地局の全体構成の一例を示す図である。無線基地局１０は、複数の送受信アンテナ１０１と、アンプ部１０２と、送受信部１０３と、ベースバンド信号処理部１０４と、呼処理部１０５と、伝送路インターフェース１０６とを備えている。なお、送受信部１０３は、送信部及び受信部で構成される。

下りリンクにより無線基地局１０からユーザ端末２０ａに送信されるユーザデータは、上位局装置３０から伝送路インターフェース１０６を介してベースバンド信号処理部１０４に入力される。

ベースバンド信号処理部１０４では、ユーザデータに関して、ＰＤＣＰ（Packet Data Convergence Protocol）レイヤの処理、ユーザデータの分割・結合、ＲＬＣ（Radio Link Control）再送制御等のＲＬＣレイヤの送信処理、ＭＡＣ（Medium Access Control）再送制御（例えば、ＨＡＲＱ（Hybrid Automatic Repeat reQuest）の送信処理）、スケジューリング、伝送フォーマット選択、チャネル符号化、逆高速フーリエ変換（ＩＦＦＴ：Inverse Fast Fourier Transform）処理、プリコーディング処理等の送信処理が行われて各送受信部１０３に転送される。また、下り制御信号に関しても、チャネル符号化や逆高速フーリエ変換などの送信処理が行われて、各送受信部１０３に転送される。

各送受信部１０３は、ベースバンド信号処理部１０４からアンテナ毎にプリコーディングして出力されたベースバンド信号を無線周波数帯に変換して送信する。送受信部１０３で周波数変換された無線周波数信号は、アンプ部１０２により増幅され、送受信アンテナ１０１から送信される。

例えば、送受信部１０３は、ＣＡを行うＣＣに関する情報（例えば、ＴＣＣとなるセルの情報等）を送信することができる。また、送受信部１０３は、ＴＣＣにおける受信動作及び／又はランダムアクセス動作の指示をＰＣＣ及び／又はＳＣＣの下り制御情報（ＰＤＣＣＨ／ＥＰＤＣＣＨ）を利用してユーザ端末に通知することができる。なお、送受信部１０３は、本発明に係る技術分野での共通認識に基づいて説明されるトランスミッター／レシーバー、送受信回路又は送受信装置とすることができる。

一方、上り信号については、各送受信アンテナ１０１で受信された無線周波数信号がそれぞれアンプ部１０２で増幅される。各送受信部１０３はアンプ部１０２で増幅された上り信号を受信する。送受信部１０３は、受信信号をベースバンド信号に周波数変換して、ベースバンド信号処理部１０４に出力する。

ベースバンド信号処理部１０４では、入力された上り信号に含まれるユーザデータに対して、高速フーリエ変換（ＦＦＴ：Fast Fourier Transform）処理、逆離散フーリエ変換（ＩＤＦＴ：Inverse Discrete Fourier Transform）処理、誤り訂正復号、ＭＡＣ再送制御の受信処理、ＲＬＣレイヤ、ＰＤＣＰレイヤの受信処理がなされ、伝送路インターフェース１０６を介して上位局装置３０に転送される。呼処理部１０５は、通信チャネルの設定や解放等の呼処理や、無線基地局１０の状態管理や、無線リソースの管理を行う。

伝送路インターフェース１０６は、所定のインターフェースを介して、上位局装置３０と信号を送受信する。また、伝送路インターフェース１０６は、基地局間インターフェース（例えば、光ファイバ、Ｘ２インターフェース）を介して隣接無線基地局１０と信号を送受信（バックホールシグナリング）してもよい。

＜ユーザ端末＞
図１７は、本実施形態に係るユーザ端末の全体構成の一例を示す図である。ユーザ端末２０は、ＭＩＭＯ伝送のための複数の送受信アンテナ２０１と、アンプ部２０２と、送受信部２０３と、ベースバンド信号処理部２０４と、アプリケーション部２０５と、を備えている。なお、送受信部２０３は、送信部及び受信部から構成されてもよい。

複数の送受信アンテナ２０１で受信された無線周波数信号は、それぞれアンプ部２０２で増幅される。各送受信部２０３はアンプ部２０２で増幅された下り信号を受信する。送受信部２０３は、受信信号をベースバンド信号に周波数変換して、ベースバンド信号処理部２０４に出力する。

なお、送受信部２０３は、本発明に係る技術分野での共通認識に基づいて説明されるトランスミッター／レシーバー、送受信回路又は送受信装置とすることができる。

ベースバンド信号処理部２０４は、入力されたベースバンド信号に対して、ＦＦＴ処理や、誤り訂正復号、再送制御の受信処理などを行う。下りリンクのユーザデータは、アプリケーション部２０５に転送される。アプリケーション部２０５は、物理レイヤやＭＡＣレイヤより上位のレイヤに関する処理などを行う。また、下りリンクのデータのうち、報知情報もアプリケーション部２０５に転送される。

一方、上りリンクのユーザデータについては、アプリケーション部２０５からベースバンド信号処理部２０４に入力される。ベースバンド信号処理部２０４では、再送制御の送信処理（例えば、ＨＡＲＱの送信処理）や、チャネル符号化、プリコーディング、離散フーリエ変換（ＤＦＴ：Discrete Fourier Transform）処理、ＩＦＦＴ処理などが行われて各送受信部２０３に転送される。送受信部２０３は、ベースバンド信号処理部２０４から出力されたベースバンド信号を無線周波数帯に変換して送信する。送受信部２０３で周波数変換された無線周波数信号は、アンプ部２０２により増幅され、送受信アンテナ２０１から送信される。

図１８及び図１９は、本実施の形態に係るユーザ端末の機能構成の一例を示す図である。図１８は、ユーザ端末２０がＤ２Ｄにおいてリレー装置として機能する場合の特徴部分の機能を示しており、図１９は、ユーザ端末２０がＤ２Ｄにおいて、リレー装置からＵＬデータを受信する場合の特徴部分の機能を示している。ただし、特別に図示されていないが、ユーザ端末２０は、無線通信に必要な他の機能ブロックも有しているものとする。

図１８に示されるように、ユーザ端末２０が有するベースバンド信号処理部２０４は、制御部４０１と、送信信号生成部４０２と、マッピング部４０３と、受信信号処理部４０４と、を備えている。

制御部４０１は、自身のユーザ端末２０がＤ２Ｄにおいてリレー装置として機能する場合、上述の態様１〜３のいずれかにしたがって、無線基地局１０から送られたデータを、ＵＬリソースを用いてリモート端末（無線基地局１０のカバレッジ外に位置する端末）に中継する処理を制御する。例えば、送信信号生成部４０２、マッピング部４０３を制御して、図８、図１０、図１３に示されるような、宛先ＩＤや送信データの生成処理を行う。

送信信号生成部４０２は、制御部４０１からの指示に基づいて、ＵＬ信号を生成して、マッピング部４０３に出力する。例えば、送信信号生成部４０２は、制御部４０１からの指示に基づいて、リモート端末ごとにＭＡＣＰＤＵを生成する。

マッピング部４０３は、制御部４０１からの指示に基づいて、送信信号生成部４０２で生成された上り信号（宛先ＩＤ及び／又は上りデータ）を無線リソースにマッピングして、送受信部２０３へ出力する。マッピング部４０３は、本発明に係る技術分野での共通認識に基づいて説明されるマッパー、マッピング回路又はマッピング装置とすることができる。

受信信号処理部４０４は、ＤＬ信号（例えば、無線基地局１０からＰＤＣＣＨ／ＥＰＤＣＣＨで送信される下り制御信号、ＰＤＳＣＨで送信される下りデータ信号等）に対して、受信処理（例えば、デマッピング、復調、復号等）を行う。受信信号処理部４０４は、無線基地局１０から受信した情報を、制御部４０１に出力する。受信信号処理部４０４は、例えば、報知情報、システム情報、ＲＲＣシグナリング、ＤＣＩなどを、制御部４０１に出力する。

図１９に示されるようにユーザ端末２０が有するベースバンド信号処理部２０４は、制御部４０１と、受信信号処理部４０４を備えている。制御部４０１は、例えば、Ｄ２Ｄにおいてリレー装置として機能するユーザ端末からデータ受信する場合、受信したデータを、自身に宛てられたデータであるか否か判断する。その際、態様１では、ＰＳＣＣＨを介して送られた宛先ＩＤが用いられる。態様２や態様３では、グループＩＤと、Ｌ２宛先ＩＤのＬＳＢ以外のビット又はＬ３の宛先ＩＤが用いられる。

制御部４０１は、自身のユーザ端末がリレー端末として機能している場合や複数の宛先ＩＤに対してデータを送信しようとしている場合やユーザ端末から要求された場合、複数のサイドリンクグラントを設定してもよい（態様１−１〜１−３）。また、新たなＭＡＣヘッダに基づいて送信データの生成や割り当てを行ったり（態様３−１）、複数端末間のＬ２宛先ＩＤの一致（衝突）を検出し、一致している場合にはその旨を端末に通知してもよい（態様３−３）。

制御部４０１は、自身のユーザ端末がリモート端末として機能している場合や複数の宛先ＩＤに対してデータを送信しようとしている場合やユーザ端末から要求された場合、複数のサイドリンクグラントを設定してもよく（態様１−１〜１−３）、新たなＭＡＣヘッダに基づいて自身に送られたデータの受信処理を行ってもよい（態様３−１）。また、通知されたＬ２宛先ＩＤが自身のものと同一（衝突）しているか否かの判断を行い、一致している場合にはその旨を通知元の端末に応答してもよい。さらに、Ｌ２宛先ＩＤの一致（衝突）が、リレー端末又は他の端末から通知された場合、Ｌ２宛先ＩＤの変更（書き換え）を行ってもよい（態様３−２、３−３）。

受信信号処理部４０４は、ＵＬチャネルを介して、リレー装置として機能するユーザ端末から受け取った信号（例えば、ユーザ端末２０ａからＰＳＣＣＨで送信される制御信号、ＰＳＳＣＨで送信されるデータ信号等）に対して、受信処理（例えば、デマッピング、復調、復号等）を行う。受信信号処理部４０４は、受信した情報を、アプリケーション部２０５に出力する。

受信信号処理部４０４は、本発明に係る技術分野での共通認識に基づいて説明される信号処理器、信号処理回路又は信号処理装置から構成することができる。また、受信信号処理部４０４は、本発明に係る受信部を構成することができる。

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

例えば、無線基地局１０やユーザ端末２０の各機能の一部又は全ては、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）、ＦＰＧＡ（Field Programmable Gate Array）等のハードウェアを用いて実現されても良い。また、無線基地局１０やユーザ端末２０は、プロセッサ（ＣＰＵ）と、ネットワーク接続用の通信インターフェースと、メモリと、プログラムを保持したコンピュータ読み取り可能な記憶媒体と、を含むコンピュータ装置によって実現されてもよい。

ここで、プロセッサやメモリなどは情報を通信するためのバスで接続される。また、コンピュータ読み取り可能な記録媒体は、例えば、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＥＰＲＯＭ、ＣＤ−ＲＯＭ、ＲＡＭ、ハードディスクなどの記憶媒体である。また、プログラムは、電気通信回線を介してネットワークから送信されても良い。また、無線基地局１０やユーザ端末２０は、入力キーなどの入力装置や、ディスプレイなどの出力装置を含んでいてもよい。

無線基地局１０及びユーザ端末２０の機能構成は、上述のハードウェアによって実現されてもよいし、プロセッサによって実行されるソフトウェアモジュールによって実現されてもよいし、両者の組み合わせによって実現されてもよい。プロセッサは、オペレーティングシステムを動作させてユーザ端末の全体を制御する。また、プロセッサは、記憶媒体からプログラム、ソフトウェアモジュールやデータをメモリに読み出し、これらに従って各種の処理を実行する。ここで、当該プログラムは、上記の各実施形態で説明した各動作を、コンピュータに実行させるプログラムであれば良い。例えば、ユーザ端末２０の制御部４０１は、メモリに格納され、プロセッサで動作する制御プログラムによって実現されてもよく、他の機能ブロックについても同様に実現されてもよい。

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

本出願は、２０１５年４月９日出願の特願２０１５−０８０４６３及び２０１５年５月１４日出願の特願２０１５−０９９５２３に基づく。この内容は、全てここに含めておく。

Claims

レイヤ２の宛先情報に含まれる特定情報が、Ｄ２Ｄを行う対象である複数の端末を個別に特定するように、前記宛先情報を設定する設定部と、
前記特定情報を、１スケジューリング期間において前記複数の端末ごとに異なるサブフレームの制御チャネルに割り当て、前記複数の端末それぞれに送信する送信データを、前記１スケジューリング期間において前記複数の端末ごとに異なるサブフレームのデータチャネルに割り当てる割り当て部と
を備える通信端末。
前記複数の端末は、前記通信端末と通信する基地局のカバレッジ外に位置し、
前記制御チャネルはＰＳＣＣＨ（Physical Sidelink Control Channel）であり、前記データチャネルはＰＳＳＣＨ（Physical Sidelink Shared Channel）であり、前記１スケジューリング期間は１ＰＳＣＣＨ周期に相当することを特徴とする請求項１記載の通信端末。
前記通信端末は、前記基地局から送信されたデータを前記送信データとして前記複数の端末に中継することを特徴とする請求項２記載の通信端末。
前記設定部は、前記１スケジューリング期間において、複数の異なる特定情報ごとに、サイドリンクグラントを設定し、
前記割り当て部は、前記サイドリンクグラントにしたがって、前記送信データを前記データチャネルに割り当てることを特徴とする請求項１から請求項３のいずれかに記載の通信端末。
レイヤ２の宛先情報において、Ｄ２Ｄを行う対象である複数の端末で共用されるグループ情報を設定する設定部と、
制御チャネルに前記グループ情報を割り当てるとともに、前記複数の端末それぞれに送信する送信データを、１スケジューリング期間において前記複数の端末ごとに異なるサブフレームのデータチャネルに割り当てる割り当て部と
を備える通信端末。
前記設定部は、前記宛先情報において、グループ情報を除く情報が前記複数の端末のそれぞれを特定するように前記宛先情報を設定することを特徴とする請求項５記載の通信端末。
前記複数の端末は、前記通信端末と通信する基地局のカバレッジ外に位置し、
前記前記制御チャネルはＰＳＣＣＨ（Physical Sidelink Control Channel）であり、前記データチャネルはＰＳＳＣＨ（Physical Sidelink Shared Channel）であり、前記１スケジューリング周期は１ＰＳＣＣＨ周期に相当することを特徴とする請求項５又は請求項６記載の通信端末。
前記通信端末は、前記基地局から送信されたデータを前記送信データとして前記複数の端末に中継することを特徴とする請求項７記載の通信端末。
前記割り当て部は、前記レイヤ２の宛先情報の全ビットをヘッダに含めた前記送信データを前記データチャネルに割り当てることを特徴とする請求項５から請求項８のいずれかに記載の通信端末。
前記設定部は、前記宛先情報において、グループ情報を除く情報が他の端末と一致する場合に、このグループ情報を除く情報を変更することを特徴とする請求項６記載の通信端末。