JP6574943B2 - 基地局、端末装置、及び通信方法 - Google Patents

Description

本開示は、基地局、端末装置、及び通信方法に関する。

車両等の移動体に搭載された通信装置を利用することによって、移動体と種々の対象物との間における直接的な通信が実現される。移動体に搭載された通信装置と種々の他の通信装置との間における通信は、Ｖ２Ｘ（Vehicle to X）通信と称されている。Ｖ２Ｘ通信については、これまで、ＤＳＲＣ（Dedicated Short Range Communication）が利用される通信システムについて検討されてきたが、近年、ＬＴＥ（Long Term Evolution）等の携帯電話の通信規格が利用される通信システムについての検討が進められている。

なお、Ｖ２Ｘ通信の議論が活発化する前より、Ｄ２Ｄ（Device to Device）と呼ばれる、通信装置同士の通信の検討が進められていた。このＤ２Ｄ通信については、例えば下記の特許文献１に開示されている。

特開２０１５−５０５２９号公報

一方で、上述したＶ２Ｘ通信は、Ｄ２Ｄ通信に比べて収容端末数がより多くなる傾向にある。そのため、Ｖ２Ｘ通信においては、リソースを効率的に使用することで、キャパシティをより拡大することが可能な仕組みの導入が求められている。

そこで、本開示では、Ｖ２Ｘ通信においてリソースを効率的に使用することが可能な、基地局、端末装置、及び方法について提案する。

本開示によれば、無線通信を行う通信部と、複数の端末装置間における端末間通信のために、セミパーシステントスケジューリングにおけるリソースを割り当て、前記リソースの割り当てに関する制御情報が、前記無線通信を介して前記端末装置に送信されるように制御する処理部と、を備える、基地局が提供される。

また、本開示によれば、無線通信を行う通信部と、他の端末装置との端末間通信のために、所定のリソースプールからセミパーシステントスケジューリングにおけるリソースを割り当て、前記リソースの割り当てに関する制御情報が、前記無線通信を介して前記他の端末装置に送信されるように制御する処理部と、を備える、端末装置が提供される。

また、本開示によれば、無線通信を行うことと、複数の端末装置間における端末間通信のために、セミパーシステントスケジューリングにおけるリソースを割り当て、前記リソースの割り当てに関する制御情報が、前記無線通信を介して前記端末装置に送信されるように制御することと、を含む、通信方法が提供される。

また、本開示によれば、無線通信を行う通信部と、
他の端末装置との端末間通信のために、所定のリソースプールからセミパーシステントスケジューリングにおけるリソースを割り当て、前記リソースの割り当てに関する制御情報が、前記無線通信を介して前記他の端末装置に送信されるように制御する処理部と、
を含む、通信方法が提供される。

以上説明したように本開示によれば、Ｖ２Ｘ通信においてリソースを効率的に使用することが可能な、基地局、端末装置、及び方法が提供される。

なお、上記の効果は必ずしも限定的なものではなく、上記の効果とともに、または上記の効果に代えて、本明細書に示されたいずれかの効果、または本明細書から把握され得る他の効果が奏されてもよい。

Ｖ２Ｘ通信の概要について説明するための説明図である。 Ｖ２Ｖ通信の第１のシナリオを説明するための説明図である。 Ｖ２Ｖ通信の第２のシナリオを説明するための説明図である。 Ｖ２Ｖ通信の第３のシナリオを説明するための説明図である。 Ｖ２Ｖ通信の第４のシナリオを説明するための説明図である。 Ｖ２Ｖ通信の第５のシナリオを説明するための説明図である。 ＩＢＥについて説明するための説明図である。 ＴＤＭ及びＦＤＭそれぞれにリソース割り当ての方法について説明するための説明図である。 ＳＰＳの概要について説明するための説明図である。 本開示の一実施形態による無線通信システムの構成を示す説明図である。 同実施形態に係るＵＥの論理的な構成の一例を示すブロック図である。 同実施形態に係るＵＥの論理的な構成の一例を示すブロック図である。 同実施形態に係るｅＮＢの論理的な構成の一例を示すブロック図である。 同実施形態に係るＲＳＵの論理的な構成の一例を示すブロック図である。 ＴＤＭにおいてＳＰＳを適用した場合の一例について説明するための説明図である。 FDM SA Periodを使用したＳＰＳの一例について示した図である。 SPS data offsetの導入例について説明するための説明図である。 SA pool period、Data pool period、及びオフセット値について説明するための説明図である。 Mode1での通信において、基地局がＳＰＳのリソース割り当てを実施する場合の一連の処理の流れの一例を示した図である。 Mode1での通信において、基地局がＳＰＳのリソース割り当てを実施する場合の一連の処理の流れの一例を示した図である。 位置情報を用いたＳＰＳのリコンフィギュレーション及びリリースの方法の一例について説明するための説明図である。 センシングとＳＰＳとを併用した場合の一例を示した図である。 端末によるリソース選択の方法の一例について説明するための説明図である。 端末によるリソース選択の方法の一例について説明するための説明図である。 SPS period内でＳＡを再送する場合の一例について示した図である。 Geo-location情報を用いたリソース割り当ての一例について説明するための説明図である。 送信プールと受信プールとのグルーピングに関する構成例を示した図である。 Congestion controlの一連の処理の流れの一例について示したフローチャートである。 ＩＢＥへの対策を考慮したMode2におけるリソース割り当ての一例を示した図である。 ｅＮＢの概略的な構成の第１の例を示すブロック図である。 ｅＮＢの概略的な構成の第２の例を示すブロック図である。 スマートフォンの概略的な構成の一例を示すブロック図である。 カーナビゲーション装置の概略的な構成の一例を示すブロック図である。

以下に添付図面を参照しながら、本開示の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。

なお、説明は以下の順序で行うものとする。
１．はじめに
１．１．Ｖ２Ｘ通信
１．２．技術的課題
２．構成例
２．１．システムの構成例
２．２．ＵＥ（ユーザ端末）の構成例
２．３．ＵＥ（移動体）の構成例
２．４．ｅＮＢの構成例
２．５．ＲＳＵの構成例
３．技術的特徴
３．１．ＳＰＳの実現
３．２．ＳＰＳのコンフィギュレーション及びリコンフィギュレーション
３．３．ＳＡデコーディング失敗時の制御
３．４．受信端末の動作
３．５．その他
４．応用例
４．１．ｅＮＢに関する応用例
４．２．ＵＥ及びＲＳＵに関する応用例
５．むすび

＜＜１．はじめに＞＞
＜１．１．Ｖ２Ｘ通信＞
将来の自動運転の実現のため、近年、車両等の移動体に搭載された通信装置を利用することによって、移動体と種々の対象物との間における直接的な通信への期待が高まってきている。車両と種々の対象物との間における通信は、Ｖ２Ｘ（Vehicle to X）通信と称されている。図１は、Ｖ２Ｘ通信の概要について説明するための説明図である。図１に示したように、Ｖ２Ｘ通信として、例えば、Ｖ２Ｖ（Vehicle to Vehicle）通信、Ｖ２Ｉ（Vehicle to Infrastructure）通信、Ｖ２Ｐ（Vehicle to Pedestrian）通信、Ｖ２Ｈ（Vehicle to Home）通信がある。その他、図示はされていないが、Ｖ２Ｘ通信として、例えばＶ２Ｎ（Ｖｅｈｉｃｌｅ ｔｏ Ｎｏｍａｄｉｃ ｄｅｖｉｃｅ）通信もある。ここで、Ｖ２Ｖ通信等の１文字目と３文字目は、それぞれ始点と終点とを意味しており、通信経路を限定するものではない。例えば、Ｖ２Ｖ通信は、移動体同士が直接的に通信すること、及び基地局等を介して間接的に通信することを含む概念である。

図１に示したように、Ｖ２Ｖ通信における車両の通信対象として、例えば、乗用車（passenger vehicle）、商用車（Commercial or fleet vehicle）、緊急車両（Emergency vehicle）又は輸送車（Transit vehicle）が挙げられる。また、Ｖ２Ｉ通信における車両の通信対象として、例えば、セルラーネットワーク（Celluler network）、データセンタ（Data centre）、商用車管理センタ（fleet or freight management centre）、交通管理センタ（Traffic management centre）、気象サービス（Weather service）、列車運行センタ（Rail operation centre）、駐車システム（Parking system）又は料金システム（Toll system）が挙げられる。また、Ｖ２Ｐ通信における車両の通信対象として、例えば、自転車の運転者（Cyclist）、歩行者用シェルタ（Pedestrian shelter）、又は自動二輪（Motorcycle）が挙げられる。また、Ｖ２Ｈ通信における車両の通信対象として、例えば、家庭用ネットワーク（Home network）、車庫（Garage）、又は商用ネットワーク（Enterprise or deeler networks）が挙げられる。

なお、Ｖ２Ｘ通信として、これまでは主に、802.11pベースのＤＳＲＣ（Dedicated Short Range Communication）が利用される通信システムについて検討されてきたが、近年、ＬＴＥ（Long Term Evolution）ベースの車載通信である”LTE-based V2X”の標準化の議論がスタートしている。

V2X通信のユースケースの一例を下記に示す。主にセーフティ（Safety）用途をターゲットとし、定期的に車両にメッセージを送るような「Periodical message」の送信や、イベントに応じて必要な情報を提供する「Event trigger message」のような通信が求められている(3GPP TR 22.885)。

（V2Xユースケース例）
1. Forward Collision Warning
2. Control Loss Warning
3. V2V Use case for emergency vehicle warning
4. V2V Emergency Stop Use case
5. Cooperative Adaptive Cruise Control
6. Ｖ２Ｉ Emergency Stop Use Case
7. Queue Warning
8. Road safety services
9. Automated Parking System
10. Wrong way driving warning
11. V2V message transfer under operator control
12. Pre-crash Sensing Warning
13. V2X in areas outside network coverage
14. V2X Road safety service via infrastructure
15. V2I/V2N Traffic Flow Optimization
16. Curve speed Warning
17. Warning to Pedestrian against pedestrian Collision
18. Vulnerable Road User(VRU) Safety
19. V2X by UE type RSU
20. V2X Minimum QoS
21. Use case for V2X access when roaming
22. Pedestrian Road Safety via V2P awareness messages
23. Mixed Use Traffic Management
24. Enhancing Positional Precision for traffic participants

また、上述したユースケースをベースとした要求事項の一例を、以下の表１に示す。

（物理レイヤ）
上述した要求事項を達成するために、Ｖ２Ｘ通信の物理レイヤの標準化が３ＧＰＰにおいては既に開始されており、車車間通信であるV2V通信の規格化を中心に、Ｖ２Ｉ／Ｎ、Ｖ２Ｐの規格化が行われている。

Ｖ２Ｘ通信のベース技術としては、３ＧＰＰで過去に規格化されたＤ２Ｄ(Device to device)通信があげられる。Ｄ２Ｄ通信は基地局を介さない端末間通信のため、Ｖ２Ｖ通信やＶ２Ｐ通信にエンハンスして適応されることが考えられる（一部Ｖ２Ｉ通信にも適応可能）。このような端末間のインタフェースをＰＣ５インタフェースと呼ぶ。また、Ｖ２Ｉ通信やＶ２Ｎ通信においては、既存の基地局と端末間の通信をエンハンスして適応することが考えられる。このような基地局、端末間のインタフェースをＵｎインタフェースと呼ぶ。

このようにＶ２Ｘ通信実現のためには、ＰＣ５インタフェースやＵｎインタフェースを、要求事項を満たすようにエンハンスしていくことが必要とされる。

主なエンハンスメントのポイントは下記の通りである。

（エンハンスメントの一例）
・リソース割り当ての改善
・ドップラー周波数対策
・同期手法の確立
・低消費電力通信の実現
・低遅延通信の実現
・・・等

Ｖ２Ｘ通信のオペレーションシナリオは多様に考えられる。一例として、図２〜図６を参照しながら、Ｖ２Ｖ通信のオペレーションシナリオの例を説明する。

図２は、Ｖ２Ｖ通信の第１のシナリオを説明するための説明図である。第１のシナリオでは、車両等の移動体同士が直接的にＶ２Ｖ通信を行う。この場合の通信リンクは、ＳＬ（SideLink）とも称される。

図３は、Ｖ２Ｖ通信の第２のシナリオを説明するための説明図である。第２のシナリオでは、車両等の移動体同士が、Ｅ−ＵＴＲＡＮ（Evolved Universal Terrestrial Radio Access Network）を介して、即ち基地局を介して間接的にＶ２Ｖ通信を行う。送信側から基地局への通信リンクはＵＬ（Uplink）とも称され、基地局から受信側への通信リンクはＤＬ（Downlink）とも称される。

図４は、Ｖ２Ｖ通信の第３のシナリオを説明するための説明図である。第３のシナリオでは、車両等の移動体が、ＲＳＵ又はＲＳＵタイプのＵＥ、及びＥ−ＵＴＲＡＮを順に介して他の移動体へ信号を送信する。各装置間の通信リンクは、順にＳＬ、ＵＬ、及びＤＬである。

図５は、Ｖ２Ｖ通信の第４のシナリオを説明するための説明図である。第４のシナリオでは、車両等の移動体が、Ｅ−ＵＴＲＡＮ、及びＲＳＵ又はＲＳＵタイプのＵＥを順に介して他の移動体へ信号を送信する。各装置間の通信リンクは、順にＵＬ、ＤＬ及びＳＬである。

図６は、Ｖ２Ｖ通信の第５のシナリオを説明するための説明図である。第５のシナリオでは、車両等の移動体同士が、ＲＳＵ又はＲＳＵタイプのＵＥを介して間接的にＶ２Ｖ通信を行う。移動体とＲＳＵ又はＲＳＵタイプのＵＥとの間の通信リンクは、ＳＬである。

以上説明した各シナリオは、移動体の片方を歩行者に変えると、Ｖ２Ｐ通信のシナリオとなる。同様に、各シナリオは、移動体の片方をインフラ又はネットワークに変えると、それぞれＶ２Ｉ通信又はＶ２Ｎ通信のシナリオとなる。

＜１．２．技術的課題＞
続いて、本実施形態の技術的課題について説明する。なお、本開示では、Ｖ２Ｘ通信におけるリソース割り当ての方法についてフォーカスする。Ｖ２Ｘ通信は、要求事項や通信環境などがＤ２Ｄ通信とは異なるため、既存のＤ２Ｄ通信をそのまま用いることが困難である。そのため、Ｖ２Ｘ通信に適応するかたちにエンハンスする必要がある。Ｄ２Ｄ通信とＶ２Ｘ通信の特徴の違いを以下に示す。
・特徴１：Ｖ２Ｘ通信は信頼性の要求が高く、低遅延通信が必要とされる。
・特徴２：Ｖ２Ｘ特有のトラフィックが存在する。
・特徴３：Ｖ２Ｘは様々なリンクを持つ。
・特徴４：ＩＢＥ(In-Band Emission)問題。
・特徴５：ＨＤ(Half Duplex)問題。
・特徴６：Ｄ２Ｄに比べてキャパシティ（Capacity）が大きな課題になる。
・特徴７：位置情報が常に得られる。

まず、特徴１については、Ｖ２Ｘ通信のユースケースから明白である。Ｖ２Ｘ通信はセーフティ（Safety）の用途が多く、信頼性が非常に重要な指標となる。また、車の移動速度がＤ２Ｄの歩行ユースケースと比較して速いことから、低遅延通信の実現が必要とされる。

特徴２として示したトラフィックについては、Ｖ２Ｘ通信においては、主に「Periodical traffic」と「Event trigger traffic」との二つのトラフィックが想定されている。「Periodic traffic」は定期的にデータを周辺車両に通知するような通信であり、これもＶ２Ｘの特徴的な点である。

特徴３として示したリンクについては、Ｖ２Ｘ通信では車の通信対象として、Ｖ／Ｉ／Ｎ／Ｐを想定している。このような多様なリンクを持つ点もＶ２Ｘ通信特有である。

特徴４として示したＩＢＥ／ＨＤ問題については、端末のトポロジーとＲＦ（Radio Frequency）性能が関係してくる。まず、ＩＢＥについて図７を用いて説明する。図７は、ＩＢＥについて説明するための説明図である。Ｖ２Ｖ通信では、基地局端末間通信とは異なり、送受信の端末の位置関係が常に変化する。もし送信端末の近隣に受信端末がいた場合、送信側からのエミッション（Emission）が近隣の受信端末に影響する場合がある。周波数軸上で直交性を保っているが、送受信端末の距離の近さからＩＢＥの影響が顕著になる。図では、端末Ａが端末ＤへＩＢＥを与えている様子を示している。このように送受信端末間の距離が近いような場合は、周波数上で隣接するリソースに対して干渉が起こってしまう可能性がある。ただしこの問題はＤ２Ｄでも起こりえる。しかしながら、Ｄ２Ｄより多くの端末が通信を行うようなＶ２Ｘ通信においては、ＩＢＥ問題はより顕著に顕在化する。

特徴５として示したＨＤ問題は、端末が送信しているときに受信することが困難となる問題を示す。そのため、Ｖ２Ｘ通信においては、「複数回受信の機会を用意する」、「データを送信するフレームで他のユーザの送信を割り当てない」等の対応が必要になってくる。ＨＤ問題もＶ２Ｘ特有の問題ではないが、多くの送受信を行う必要があるＶ２Ｘ通信では大きな制約となる。

次に、特徴６として示したキャパシティ（Capacity）について説明する。前述したとおり、Ｄ２Ｄ通信と比較してＶ２Ｘ通信は収容端末数が非常に多くなる。さらに、自動車は道路の上を走行するため、必然的に端末密度は局所的に増加してしまう。そのため、Ｖ２Ｘ通信においては、キャパシティ（Capacity）の改善が必要不可欠になる。不要なオーバーヘッドなどは最大限削除し、効率的な通信を実現する必要がある。

また、特徴７については、近年の自動車におけるナビゲーション装置の搭載率を見てもわかるとおり、自動車は自身の位置情報を常に知っているものと想定される。このような位置情報は、Ｖ２Ｘ通信をエンハンスする上で非常に重要な特徴になる。

これらの問題を解決する為、３ＧＰＰではＦＤＭ（周波数分割多重：Frequency Division Multiplexing）を用いたリソース割り当ての方法が現在検討されている。ＴＤＭ（時分割多重：Time Division Multiplexing）割り当てとＦＤＭ割り当てについて図８を用いて説明を行う。図８は、ＴＤＭ及びＦＤＭそれぞれにリソース割り当ての方法について説明するための説明図である。Ｄ２Ｄ通信やＶ２Ｘ通信が行われるＰＣ５インタフェースは、主に制御チャネル部(ＰＳＣＣＨ: Physical Sidelink Control CHannel)とデータチャネル部(ＰＳＳＣＨ: Physical Sidelink Shared CHannel)から構成されている。ＰＳＣＣＨにおいてＰＳＳＣＨのリソース指示などを通知するため、ＴＤＭ方式では、パケットの発生から送信までの遅延が大きくなるといった問題がある。一方で、端末のコンプレキシティ（Complexity）が良いというメリットがある。なお、Ｄ２ＤではＴＤＭ割り当て方式が採用されている。これに対しては、ＦＤＭ方式では、周波数方向にＰＳＣＣＨがマッピングされているため、遅延が改善される。また、制御情報（ＳＡ：Scheduling Assignment）とデータ（Ｄａｔａ）を同じＳＦ（Sub Frame）で送信することで、ＩＢＥやＨＤの問題も改善することが期待できる。そのため、Ｖ２Ｘ通信では、ＦＤＭ方式を用いた通信方法の確立が求められている。

なお、参考までに、Ｖ２Ｘ通信では、ＳＡとＤａｔａはそれぞれ複数回反復して（Repetition）送信することが想定される。これは、Ｄ２Ｄでは、ＡＣＫ／ＮＡＣＫがサポートされておらず、確実に端末までデータを届けるためにこのような反復（Repetition）が導入されているためである。

ＦＤＭ方式に加えてさらなるエンハンスメントの追加も検討されている。前述した特徴６のキャパシティの問題を解決する為に、現在ＳＰＳ(Semi-Persistent Scheduling)の導入も検討されている。これは、Ｖ２Ｘ通信で特徴のあるトラフィックタイプ（特徴２）の特性をうまく利用している。ＳＰＳの概要を図９に示す。図９は、ＳＰＳの概要について説明するための説明図である。ＳＰＳでは一つのＳＡで複数のデータをスケジューリングする。そのため、データ送信の度にＳＡを送信する必要がなく、オーバーヘッドの削減が可能になる。特にＶ２ＸのPeriodical trafficのような周期的な通信においては、このようなスケジューリングが大きな効果を生むことが確認されている。そのため、Ｖ２Ｘ通信では、ＳＰＳの導入も求められている。

次に、位置情報を用いたエンハンスメントについて説明する。特徴６として述べたとおり、Ｖ２Ｘではキャパシティが大きな問題となる。そこで、周波数リソースの空間再利用が検討されている。空間再利用を行うに当たり、特徴７として説明した、自動車の位置情報を活用する。この位置情報を用いたエンハンスメントも現在３ＧＰＰで議論されている。

これまでが、ＰＣ５インタフェースのエンハンスメントの概要である。Ｖ２Ｘ通信では、リソース割り当ての方法として、Mode1の「Centralized resource allocation」とMode2の「Autonomous resource selection」の２種類がある。Mode1の場合は、ＰＣ５インタフェースのリソース割り当てを基地局がすべて行う。端末側では基地局に指示されたリソースで送信を行うだけでよい。基地局端末間のオーバーヘッドが懸念されるが、リソースが直交して割り当てられるため通信特性はよい。一方で、Mode2では、端末は基地局から通知されたリソースプールの中から、自律的に送信に使用するリソースを選択する。Mode1のオーバーヘッドの懸念がないが、他端末と同じリソースを選択してしまう可能性もあるため、コリジョン（Collision）の課題が顕在化する可能性がある。Mode2は基地局のネットワーク（Network）内であるインカバレッジ（In-coverage）のみならず、アウトオブカバレッジ（Out-of-coverage）でオペレーションできるというメリットもある。

このMode2のコリジョン（Collision）の問題についても、現在いくつかの提案が行われている。ソリューション（Solution）は大きく２つに分けられる。一つは「Energy sensing」である。「Energy sensing」では、ある一定期間リソースをセンシングし、そのセンシング結果に基づいて、比較的使用されていないリソースから通信用のリソースを選択する方法である。簡単である一方、電力レベルなので精度はそこまで高くない。もう一つの方法は、「SA decoding」である。これは、他ユーザが送信しているＳＡ（制御情報）をデコードし、使用されているリソースの場所を認識する方法である。使用されているリソースが精度よく発見することができる反面、ＳＡリソース自体のセンシングが行えないなどのデメリットがある。

最後に、これまでのエンハンスメントの説明一覧を表２として以下に示す。これは一例であり、代表的なエンハンスメントを記載しており、その他にもさまざまな方法が検討されている。

＜＜２．構成例＞＞
以下、各実施形態において共通する無線通信システムの構成例を説明する。

＜２．１．システムの構成例＞
図１０は、本開示の一実施形態による無線通信システムの構成を示す説明図である。図１０に示したように、本開示の実施形態による無線通信システムは、ＵＥ１０、ＵＥ２０、車両２２、ｅＮＢ３０、ＧＮＳＳ衛星４０、及びＲＳＵ５０を有する。

ｅＮＢ３０は、セル内に位置するＵＥ２０にセルラー通信サービスを提供するセルラー基地局である。例えば、ｅＮＢ３０は、ＵＥ１０及びＵＥ２０が通信するためのリソースをスケジュールし、スケジュールしたリソースをＵＥ１０及びＵＥ２０に通知する。そして、ｅＮＢ３０は、当該リソースにおいてＵＥ１０及びＵＥ２０との間でアップリンク通信またはダウンリンク通信を行う。

ＧＮＳＳ衛星４０は、地球を所定の軌道に沿って周回する人工衛星（通信装置）である。ＧＮＳＳ衛星４０は、航法メッセージを含むＧＮＳＳ（Global Navigation Satellite System）信号を送信する。航法メッセージは、ＧＮＳＳ衛星４０の軌道情報および時間情報などの、位置測定のための種々の情報を含む。

ＲＳＵ５０は、道路脇に設置される通信装置である。ＲＳＵ５０は、車両２２若しくは車両２２に搭載されたＵＥ２０、又はユーザ１２が携行するＵＥ１０と双方向通信を行うことができる。なお、ＲＳＵ５０は、車両２２若しくは車両２２に搭載されたＵＥ２０、又はユーザ１２が携行するＵＥ１０とＤＳＲＣ通信を行い得るが、本実施形態においては、ＲＳＵ５０が、車両２２若しくは車両２２に搭載されたＵＥ２０、又はユーザ１２が携行するＵＥ１０とセルラー通信の方式に従って通信することも想定される。

ＵＥ２０は、車両２２に搭載され、車両２２の走行に伴って移動する通信装置である。ＵＥ２０は、ｅＮＢ３０による制御に従ってｅＮＢ３０と通信する機能を有する。また、ＵＥ２０は、ＧＮＳＳ衛星４０から送信されるＧＮＳＳ信号を受信し、ＧＮＳＳ信号に含まれる航法メッセージからＵＥ２０の位置情報を測定する機能を有する。また、ＵＥ２０は、ＲＳＵ５０と通信する機能を有する。さらに、本実施形態によるＵＥ２０は、ユーザ１２に携行されるＵＥ１０、又は他の車両２２に搭載されたＵＥ２０と直接通信すること、すなわち、Ｄ２Ｄ通信を行うことも可能である。以下では、ＵＥ２０及び車両２２（移動体）を特に区別する必要がない場合、ＵＥ２０と総称する。

ＵＥ１０は、ユーザ１２に携行され、ユーザ１２の歩行、走行又はユーザ１２が乗車した乗り物（バス、バイク、又は車等）の移動に伴って移動する通信装置である。ＵＥ１０は、ｅＮＢ３０による制御に従ってｅＮＢ３０と通信する機能を有する。また、ＵＥ１０は、ＧＮＳＳ衛星４０から送信されるＧＮＳＳ信号を受信し、ＧＮＳＳ信号に含まれる航法メッセージからＵＥ１０の位置情報を測定する機能を有する。また、ＵＥ１０は、ＲＳＵ５０と通信する機能を有する。さらに、本実施形態によるＵＥ１０は、他のＵＥ１０又はＵＥ２０と直接通信すること、すなわち、Ｄ２Ｄ通信を行うことも可能である。ＵＥ１０とＵＥ２０との通信はＶ２Ｐ通信とも称される。

なお、図１０においては移動体の一例として車両２２を示しているが、移動体は車両２２に限定されない。例えば、移動体は、船舶、航空機および自転車などであってもよい。また、上記では、ＵＥ２０がＧＮＳＳ信号を受信する機能を有することを説明したが、車両２２がＧＮＳＳ信号を受信する機能を有し、車両２２がＧＮＳＳ信号の受信結果をＵＥ２０に出力してもよい。

＜２．２．ＵＥ（ユーザ端末）の構成例＞
図１１は、本開示の一実施形態に係るＵＥ１０の論理的な構成の一例を示すブロック図である。図１１に示すように、本実施形態に係るＵＥ１０は、アンテナ部１１０、無線通信部１２０、ＧＮＳＳ信号処理部１３０、記憶部１４０及び処理部１５０を含む。

アンテナ部１１０は、無線通信部１２０により出力される信号を電波として空間に放射する。また、アンテナ部１１０は、空間の電波を信号に変換し、当該信号を無線通信部１２０へ出力する。

無線通信部１２０は、信号を送受信する。例えば、無線通信部１２０は、ｅＮＢ３０からのダウンリンク信号を受信し、ｅＮＢ３０へのアップリンク信号を送信する。また、無線通信部１２０は、他のＵＥ１０、ＵＥ２０又はＲＳＵ５０との間でサイドリンク信号を送受信する。

ＧＮＳＳ信号処理部１３０は、ＧＮＳＳ衛星４０から送信されたＧＮＳＳ信号についての処理を行う構成である。例えば、ＧＮＳＳ信号処理部１３０は、ＧＮＳＳ信号を処理することにより、ＵＥ１０の位置情報および時間情報を測定する。

記憶部１４０は、ＵＥ１０の動作のためのプログラム及び様々なデータを一時的に又は恒久的に記憶する。

処理部１５０は、ＵＥ１０の様々な機能を提供する。例えば、処理部１５０は、無線通信部１２０により行われる通信を制御する。

＜２．３．ＵＥ（移動体）の構成例＞
図１２は、本開示の一実施形態に係るＵＥ２０の論理的な構成の一例を示すブロック図である。図１２に示すように、本実施形態に係るＵＥ２０は、アンテナ部２１０、無線通信部２２０、ＧＮＳＳ信号処理部２３０、記憶部２４０及び処理部２５０を含む。

アンテナ部２１０は、無線通信部２２０により出力される信号を電波として空間に放射する。また、アンテナ部２１０は、空間の電波を信号に変換し、当該信号を無線通信部２２０へ出力する。

無線通信部２２０は、信号を送受信する。例えば、無線通信部２２０は、ｅＮＢ３０からのダウンリンク信号を受信し、ｅＮＢ３０へのアップリンク信号を送信する。また、無線通信部２２０は、ＵＥ１０、他のＵＥ２０又はＲＳＵ５０との間でサイドリンク信号を送受信する。

ＧＮＳＳ信号処理部２３０は、ＧＮＳＳ衛星４０から送信されたＧＮＳＳ信号についての処理を行う構成である。例えば、ＧＮＳＳ信号処理部２３０は、ＧＮＳＳ信号を処理することにより、ＵＥ２０の位置情報および時間情報を測定する。

記憶部２４０は、ＵＥ２０の動作のためのプログラム及び様々なデータを一時的に又は恒久的に記憶する。

処理部２５０は、ＵＥ２０の様々な機能を提供する。例えば、処理部２５０は、無線通信部２２０により行われる通信を制御する。

＜２．４．ｅＮＢの構成例＞
図１３は、本開示の一実施形態に係るｅＮＢ３０の論理的な構成の一例を示すブロック図である。図１３に示すように、本実施形態に係るｅＮＢ３０は、アンテナ部３１０、無線通信部３２０、ネットワーク通信部３３０、記憶部３４０及び処理部３５０を含む。

アンテナ部３１０は、無線通信部３２０により出力される信号を電波として空間に放射する。また、アンテナ部３１０は、空間の電波を信号に変換し、当該信号を無線通信部３２０へ出力する。

無線通信部３２０は、信号を送受信する。例えば、無線通信部３２０は、ＵＥ１０、ＵＥ２０又はＲＳＵ５０からのアップリンク信号を受信し、ＵＥ１０、ＵＥ２０又はＲＳＵ５０へのダウンリンク信号を送信する。

ネットワーク通信部３３０は、情報を送受信する。例えば、ネットワーク通信部３３０は、他のノードへの情報を送信し、他のノードからの情報を受信する。例えば、上記他のノードは、他の基地局及びコアネットワークノードを含む。

記憶部３４０は、ｅＮＢ３０の動作のためのプログラム及び様々なデータを一時的に又は恒久的に記憶する。

処理部３５０は、ｅＮＢ３０の様々な機能を提供する。例えば、処理部３５０は、配下のＵＥ１０、ＵＥ２０、及びＲＳＵ５０により行われる通信を制御する。

＜２．５．ＲＳＵの構成例＞
図１４は、本開示の一実施形態に係るＲＳＵ５０の論理的な構成の一例を示すブロック図である。図１４に示すように、本実施形態に係るＲＳＵ５０は、アンテナ部５１０、無線通信部５２０、記憶部５３０及び処理部５４０を含む。

アンテナ部５１０は、無線通信部５２０により出力される信号を電波として空間に放射する。また、アンテナ部５１０は、空間の電波を信号に変換し、当該信号を無線通信部５２０へ出力する。

無線通信部５２０は、信号を送受信する。例えば、無線通信部５２０は、ｅＮＢ３０からのダウンリンク信号を受信し、ｅＮＢ３０へのアップリンク信号を送信する。また、無線通信部５２０は、ＵＥ１０、ＵＥ２０又は他のＲＳＵ５０との間でサイドリンク信号を送受信する。

記憶部５３０は、ＲＳＵ５０の動作のためのプログラム及び様々なデータを一時的に又は恒久的に記憶する。

処理部５４０は、ＲＳＵ５０の様々な機能を提供する。例えば、処理部５４０は、無線通信部５２０により行われる通信を制御する。

以上、各実施形態において共通する構成例を説明した。

＜＜３．技術的特徴＞＞
続いて、各実施形態の技術的特徴を詳細に説明する。

＜３．１．ＳＰＳの実現＞
まず、ＳＰＳを実現するための仕組みの一例にについて説明する。Semi-persistentにスケジューリングを行うためには、データリソースを低いオーバーヘッド（Overhead）でフレキシブルに通知する必要がある。

（ａ）ＴＤＭの場合
まず、ＴＤＭの場合に着目する。例えば、図１５は、ＴＤＭにおいてＳＰＳを適用した場合の一例について説明するための説明図である。図１５では、データ（Ｄａｔａ）を４つ反復（Repetition）している場合の例を示している。ＴＤＭでは、Ｄ２Ｄにおける「SA period」の定義を流用する。1^st transmissionはそれぞれのデータリソースの場所を通知し、2^nd transmission以降リピート（Repeat）する。オプション（Option）で周波数ホッピングやサブフレームシフトなどの調整を行ってもよい。周波数ホッピングを行う際は、ホッピング（Hopping）に関する情報を制御情報（ＳＡ）で通知する。サブフレームシフトを行う際は、シフト量をＳＡで通知する。周波数ホッピングやサブフレームシフトを行う場合には、ＳＰＳ送信回数をパラメータとしてホッピング（Hopping）量やシフト量を変化させてもよい。「SA period」は、Ｄ２Ｄと同様に基地局から通知されてもよく、あらかじめ設定（Preconfigure）されてもよい。

（ｂ）ＦＤＭの場合
次いで、ＦＤＭの場合に着目する。ＦＤＭの場合については、「FDM SA Period」の導入、「SPS data offset」の導入、及び、「SA resource pool」と「Data resource pool」とを時間方向で区切る方法について説明する。

（ｂ−１）FDM SA Periodの導入
「FDM SA Period」の導入について説明する。本説明では、まずパラメータの定義や設定について説明する。ＦＤＭでは、ＴＤＭとは異なり、Ｄ２Ｄにおける「SA period」を流用することが困難である。そのため、新たに「FDM SA Period」を定義する。

ここで、「FDM SA Period」とは、制御情報（ＳＡ）とデータ（Ｄａｔａ）のリソースプールのセットを示すものとする。「FDM SA Period」内で送信されたＳＡとそれに関連するＤａｔａは、「FDM SA Period」内で送信が完了する。「FDM SA Period」は、ＵＥごとに定義されてもよく、全ＵＥ共通で定義されてもよい。

ＴＤＭと同様に、周波数ホッピング（Hopping）やサブフレームシフト等を行い、時間、周波数方向で調整することも可能である。例えば、図１６は、「FDM SA Period」を使用したＳＰＳの一例を示している。

次いで、パラメータの割り当てや通知の例について説明する。「FDM SA Period」は基地局から割り当てられてもよく、UE自身で任意に設定してもよい。また、トラフィックの種類（Event trigger、Periodical等）に応じて設定してもよい。トラフィックの種類と、「FDM SA Period」の割り当てテーブルを基地局から通知されてもよく、あらかじめ設定（Preconfigured）されていてもよい。また、全ＵＥ共通の値が設定されてもよい。この場合においても、基地局が設定してもよく、あらかじめ設定（Preconfigured）されていてもよい。また、リソースプール（Resource pool）固有の「FDM SA Period」であってもよい。「SPS period（換言すると、SPSが設定される期間）」として、「FDM SA Period」をベースに何回送信するかの情報をＳＡで受信端末へ通知する。「FDM SA Period」、ＳＰＳ回数で「SPS period」の通知を行う。

（ｂ−２）SPS data offsetの導入
続いて、「SPS data offset」の導入について説明する。本説明では、まずパラメータの定義や設定について説明する。「FDM SA Period」では、２回目の送信以降はＳＡ部分の領域が無駄になり、レイテンシ（Latency）の悪化が懸念される。そのため、データ部だけを考慮したＳＰＳを行うために、「SPS data offset」の導入を行う。

例えば、図１７は、「SPS data offset」の導入例について説明するための説明図である。「SPS data offset」は、基本的に最初のデータ送信から反復（Repetition）送信３回の計４回送信される期間（「Data period」と定義する）よりも長く設定されるが、それよりも短く設定することも可能である。ＴＤＭ同様に、周波数ホッピング（Hopping）やサブフレームシフト等を行い、時間、周波数方向で調整することも可能である。

次いで、パラメータの割り当てや通知の例について説明する。「SA data offset」は基地局から割り当てられてもよく、ＵＥ自身で任意に設定してもよい。また、トラフィックの種類（Event trigger、Periodicalなど）に応じて設定してもよい。トラフィックの種類と、「SA data offset」の割り当てテーブルが基地局から通知されてもよく、あらかじめ設定（Preconfigured）されてもよい。また、全ＵＥ共通の値が設定されてもよい。この場合においても、基地局が設定してもよく、あらかじめ設定（Preconfigured）されていてもよい。リソースプール（Resource pool）固有の「SA data offset」であってもよい。「SPS period」として、「SA data offset」をベースに何回送信するかの情報をＳＡで受信端末へ通知する。「SA data offset」、ＳＰＳ回数で「SPS period」の通知を行う。

（ｂ−３）SA resource poolとData resource poolを時間方向で区切る方法
続いて、「SA resource pool」と「Data resource pool」を時間方向で区切る方法について説明する。本説明では、まずパラメータの定義や設定について説明する。「SA resource pool」と「Data resource pool」については、ＴＤＭと同様に、「SA pool」と「Data pool」とを一定時間で区切る。「SA pool period」、「Data pool period」、及びオフセット（Offset）値を導入する。例えば、図１８は、「SA pool period」、「Data pool period」、及びオフセット（Offset）値について説明するための説明図である。図１８に示すように、「SA pool」と関連する「Data pool」を同じ時間に割り当てることも可能であり、また、「SA pool」と関連する「Data pool」のオフセット（Offset）値を通知することも可能である。また、前述した「FDM SA Period」を「SA pool」と「Data pool」とオフセット（Offset）値とから設定（Configure）することも可能である。

次いで、パラメータの割り当てや通知の例について説明する。「SA pool period」、「Data pool period」、及びオフセット（Offset）値は、前述した「FDM SA Period」や「SPS data offset」と同様に、基地局から割り当てられてもよく、ＵＥ自身で任意に設定することも可能である。また、トラフィックの種類（Event trigger、Periodicalなど）に応じて設定されてもよい。トラフィックの種類と、「SA data offset」の割り当てテーブルを基地局から通知されてもよく、あらかじめ設定（Preconfigured）されてもよい。また、全ＵＥ共通の値が設定されてもよい。この場合においても、基地局が設定してもよく、あらかじめ設定（Preconfigured）されていてもよい。また、リソースプール（Resource pool）固有のオフセット（Offset）値を導入してもよい。

＜３．２．ＳＰＳのコンフィギュレーション及びリコンフィギュレーション＞
続いて、ＳＰＳのコンフィギュレーション（Configuration）及びリコンフィギュレーション（Reconfiguration）を行う方法について説明する。ＳＰＳの設定及び再設定については、Mode1及びMode2両方のケースを考慮することが望ましい。また、基地局のＨＯ（Hand Over）やGeo-locationベースのリソースプール割り当て変更などを行った場合などは対応が必要となる。また、ＳＰＳ送信中に「Event trigger message」の送信が必要になった場合などは、急きょＳＰＳをリリース（Release）やサスペンド（Suspend）する必要がでてくる。

（ａ）Mode1での通信
まず、Mode1での通信について説明する。

（ａ−１）処理の流れ
例えば、図１９及び図２０は、Mode1での通信において、基地局（ＲＳＵも可）がＳＰＳのリソース割り当てを実施する場合の一連の処理の流れの一例を示している。

（ａ−１−１）ＳＰＳを事前設定する場合
まず、図１９を参照して、ＳＰＳを事前設定する場合の一例について説明する。この場合には、まず基地局は、RRC connection要求をトリガに（Ｓ１０１）、ＳＰＳのコンフィギュレーション（Configuration）を行い、端末へ事前に設定（Configure）しておく（Ｓ１０３）。RRC connection setup、RRC connection reconfiguration、RRC connection re-establishment messageのどれかを用いて基地局から端末にＳＰＳのコンフィギュレーション（Configuration）を通知する。

端末側で、もしＳＰＳを用いるトラフィック、例えば「Periodical traffic」等が発生した場合には（Ｓ１０５）、設定（Configure）されたＳＰＳをアクティベート（Activate）して送信を行う（Ｓ１１１）。そして送信完了後に、リリース（Release）を行う。トラフィック（Traffic）発生後（Ｓ１０５）、アクティベーション（Activation）確認のために基地局側に「Scheduling request」を送信してもよい（Ｓ１０７）。基地局側では、「Scheduling grant」と同時に、ＳＰＳのアクティベーション（Activation）を行う（Ｓ１０９）。端末側では、事前に設定（Configure）されているＳＰＳをアクティベーション（Activation）して送信を行う（Ｓ１１１）。

（ａ―１−２）ＳＰＳを適宜設定する場合
次いで、図２０を参照して、ＳＰＳを適宜設定する場合の一例について説明する。端末はＳＰＳ用のトラフィックが発生した時点で（Ｓ２０１）、基地局に対してスケジューリングリクエストを送信する（Ｓ２０３）。基地局側では「SPS configuration」を行い、アクティベーション（Activation）指示を端末側へ返す（Ｓ２０５）。受信した端末は、指示された通りにＳＰＳ送信を実施する（Ｓ２０７）。

（ａ―２）SPS configuration message
次いで、「SPS configuration message」について説明する。「SPS configuration message」は、「Resource allocation」情報を含む。例えば、「Resource allocation」情報は、割り当てられたリソースの位置情報を含む。割り当てられたリソースの位置情報の具体的な一例として、1^st transmissionのリソースの位置情報が挙げられる。また、他の一例として、2^nd transmission以降の送信フレーム情報、プール情報、SA period情報などが含まれてもよい。これらの情報は、例えば、SA Pool、Data pool、FDM SA Period、SPS Data offset値などを用いて通知される。また、ＨＡＲＱ（Hybrid Automatic Repeat reQuest」）の再送を想定し、ＨＡＲＱ用再送用リソース情報が含まれてもよい。

また、「Resource allocation」情報は、送信回数情報を含んでもよい。送信回数情報としては、「２」から「規定なし」までが設定され得る。規定なしの場合には、ＳＰＳがリリース（Release）されるまで送信し続けることとなる。

また、「Resource allocation」情報は、反復（Repetition）数を示す情報を含んでもよい。当該情報により、各送信場所における反復（Repetition）数が指示される。例えば、3^rd transmissionのみ「Data repetition」を４回から５回に増やす等の制御が可能となる。

また、「Resource allocation」情報は、送信電力情報を含んでもよい。送信電力情報は、送信場所ごとに規定されてもよいし、全体で共通であってもよい。

また、「Resource allocation」情報は、「Component carrier」情報を含んでもよい。例えば、マルチキャリア通信を行う場合には、対象となる「Component carrier」情報が通知されてもよい。

また、「Resource allocation」情報は、対象リソースプール（Resource Pool）情報を含んでもよい。対象リソースプール情報は、どのリソースプールを対象にＳＰＳが設定されているかを示す。

また、「Resource allocation」情報は、ＲＶ（Redundancy Version）情報を含んでもよい。なお、ＲＶは、送信場所ごとに設定されてもよいし、共通で設定されていてもよい。また、ＲＶは、あらかじめ設定（Preconfigured）されていてもよい。

また、「Resource allocation」情報は、「Suspend period」を示す情報を含んでもよい。当該情報は、例えば、「Event trigger message」等を送信する必要があり、ＳＰＳを一時中断する場合における停止期間の設定を示している。なお、「Suspend period」は、例えば、「SA Period」や「SA pool」、「Data pool」等のパラメータを用いて設定される。

（ａ―３）SA contents情報
続いて、「SA contents情報」について説明する。送信端末は、ＳＰＳ送信を行う際に、受信端末に向けてＳＡ（制御情報）とＤａｔａとを送信する。ここでは、ＳＡのコンテンツについて説明する。ＳＡのコンテンツとして、前述したSPS configurationと同様に、割り当てられたリソースの位置情報、送信回数情報、反復（Repetition）数を示す情報、送信電力情報、及びＲＶ情報が挙げられる。なお、これらの情報については、SPS configurationの場合と同様のため、詳細な説明は省略する。

（ａ―４）SPS re-configuration/Release方法
続いて、図２１を参照して、位置情報を用いたＳＰＳのリコンフィギュレーション（Re-configuration）及びリリース（Release）の方法の一例について説明する。図２１は、位置情報を用いたＳＰＳのリコンフィギュレーション及びリリースの方法の一例について説明するための説明図である。

まず端末は位置測定を行い（Ｓ３０１）、位置情報を基地局に通知する（Ｓ３０３）。その後、基地局側は、位置情報に応じたリソースプール（Resource pool）の割り当てを実施する（Geo-location based resource allocation）（Ｓ３０５）。また、基地局は、必要に応じて、これまでのリソースプール（RP）におけるＳＰＳのリリース（Release）もしくは、新たなリソースプール（RP）に対してのリコンフィギュレーション（Re-configuration）を実施する（Ｓ３０７）。

ここで、位置情報に応じたリソースプール（Resource pool）の割り当ての一例について説明する。例えば、レポートされた端末位置で使用していないリソースプール（Resource pool）に対するＳＰＳをリリースする。また、端末の将来位置を予測し、将来使用するリソースプール（Resource pool）に対してＳＰＳを設定（Configure）する。そして、対象リソースプールとその「SPS configuration」を通知する。

なお、リリース（Release）またはリコンフィギュレーション（Reconfiguration）の結果は端末へと通知され、端末は、基地局からの指示通りにＳＰＳのリリース（Release）またはリコンフィギュレーション（Reconfiguration）を実施する（Ｓ３０９）。

（ａ―５）その他のＳＰＳのリリース方法
続いて、ＳＰＳをリリースする方法の他の一例について説明する。例えば、端末は、アイドル（ＩＤＬＥ）モードになった場合にＳＰＳをリリースする方法が挙げられる。この場合には、端末自身でアイドルモードを検出し、アイドルモードに遷移した場合にＳＰＳをリリースする。

また、端末は、基地局の圏外となった場合にＳＰＳをリリースしてもよい。この場合には、端末は、ＲＳＲＰ（Reference Signal Received Power）を測定し、測定結果が所定の閾値以下になった場合に圏外と判断し、ＳＰＳをリリースする。

また、端末は、基地局のハンドオーバー（Hand over）時にＳＰＳをリリースしてもよい。この場合には、端末は、新しい基地局にハンドオーバー（Hand over）した際に、ハンドオーバー元の基地局のＳＰＳをリリースする。ＳＰＳのリリース通知は、ハンドオーバー先の基地局から通知されてもよく、端末側でハンドオーバー元の基地局のＲＳＲＰなどをもとに判断してもよい。

また、「Mode1 operation」の終了通知に基づきＳＰＳをリリースする方法が挙げられる。この場合には、基地局から端末へ、「Mode1 operation」の終了の通知があった場合にＳＰＳも同時にリリースされる。

また、周辺端末からリリースリクエストがあった場合にリリースする方法が挙げられる。この場合には、端末は、例えば、周辺端末からＶ２Ｖ通信を用いて、ＳＰＳリリース依頼があったが場合にリリースを行う。なお、リリース依頼を受信した端末は、基地局にその旨をレポートしてもよい。また、周辺端末から基地局にＳＰＳリリースリクエストがあった場合に、基地局は、対象の端末にリリース依頼を出してもよい。このとき周辺端末は、対象の端末ＩＤを通知してもよい。基地局は、周辺端末から通知された端末ＩＤに対してＳＰＳをリリースしてもよく、任意に選択してもよい。

また、ＳＰＳを使用するトラフィックがなくなった場合にリリースする方法が挙げられる。この場合には、端末は、ＳＰＳを使用するようなPeriodical trafficを送信する必要がなくなった場合に、基地局にその旨を通知する。なお、ＢＳＲ（Buffer status report）を用いて通知されてもよい。このとき、端末は、そのままＳＰＳのリリースを行う。

また、端末の位置情報をもとにリリースする方法が挙げられる。この場合には、基地局（ｅＮＢ）が、端末位置情報を用いてＳＰＳのリリースを指示してもよい。また、端末が、自身の位置情報に基づきＳＰＳのリリースを実施してもよい。

また、基地局が無線周波数の使用状況をもとにリリースを行う方法が挙げられる。例えば、無線周波数がひっ迫してきた場合、より綿密にリソース制御を行うためにＳＰＳの使用を停止する。

（ｂ）Mode2での通信
続いて、Mode2での通信に着目する。Mode2での通信では、例えば、端末が自ら、リソースプールの中から送信に必要なリソースを選択して送信してもよい。この場合には、リソースプールの情報は、基地局から通知されるか、もしくは、あらかじめ設定（Preconfigured）される。なお、リソース選択の際には、他のユーザとのコリジョン（Collision）の少ないリソースを選択するために、例えば、送信端末はセンシングを行い、他のユーザが使用していないリソースをなるべく割り当てるようにする。なお、センシング方法には「Energy sensing」と「SA decoding」の方法がある。

例えば、図２２に、センシングとＳＰＳとを併用した場合の一例を示す。この場合には、端末はＳＰＳのリソース選択前にセンシング（Sensing）を実施し、センシングの結果をもとに、他端末に使用されていないリソースを選択するようにリソース割り当てを実施する。リソース割り当ては各「SA period」間において固定（Fix）でもよい。また、他の一例として、Periodで周波数時間位置を任意に変更する等のように、リソース割り当てがフレキシブル（Flexible）に行われてもよい。

（ｂ−１）端末のリソース選択方法
ここで、端末によるリソース選択の方法について説明する。リソースの選択時に注意を要する点は、主に以下の２点である。
・２つのユーザが、同じタイミングでセンシングを行い、リソース割り当てが被ってしまう場合がある。リソースの選択方法によっては、ＳＰＳの期間中ずっとコリジョン（Collision）が起こってしまう可能性があるため、これを避ける必要がある。
・端末が選択したリソースを、いかに端末に少ないオーバーヘッドで通知するかがポイントになる。

上記に示した２点を鑑み、リソースの選択方法について、以下に選択方法１〜５の５点を提案する。
・選択方法１：リソースを任意に選択する方法
・選択方法２：「SA period」間で特定の送信パターンを用いる方法
・選択方法３：上記選択方法１及び２のハイブリッド（Hybrid）型
・選択方法４：送信端末自身でコリジョンの検出を行い、ＳＰＳのリコンフィギュレーション（Reconfiguration）を実施する方法
・選択方法５：近隣端末、基地局、またはＲＳＵにコリジョンを検出してもらい、送信方法を切り替える方法（コリジョンフィードバック）。

まず、選択方法１について説明する。この場合には、例えば、端末は、センシングの結果をベースに使用可能なリソースを任意に選択する。「SA period」間でリソース割り当ての相関がないため、連続してコリジョン（Collision）が起こる可能性は低い。端末は、選択したリソース情報を、ビットマップテーブルを用いて受信側へと通知する。この場合には、膨大なビット数が必要となる。

次いで、選択方法２について説明する。この場合には、例えば、端末は、センシングの結果をベースに使用可能なリソースを認識する。その後、規定の送信パターン（換言すると、送信のためのリソース割り当てのパターン）の中から、他ユーザと衝突の可能性が少ないパターンの候補をいくつか選択し、その中からランダムに一つ選択する。なお、同じタイミングでリソース選択を行った端末がいる場合には、同じパターンを選択する可能性がある。また、パターンが十分ではない場合には、センシング結果を最大限活用することが困難となる（センシングを行い、リソースが占有されていると分かっていても避けられない）場合が出てくる。端末は選択したパターン情報を、パターンインデックス（Index）として通知する。通知に必要なビット数は比較的少ない。全送信領域で1^st transmissionの位置をコピーする固定（FIX）送信方法もここに含まれる。

次いで、選択方法３について説明する。この場合には、Ｎ番目（Ｎは自然数）の送信まで任意選択を行い、それ以降はパターンを用いて送信する。パターンはＮ番目の送信をベースに生成される。Ｎ番目とＮ＋１番目に相関をもたせず、新規のパターンをＮ＋１番目から適応してもよい。この選択方法は、Ｎ番目の送信までは、選択方法１の特性があり、Ｎ＋１番目以降の送信は選択方法２の特性を持つ。端末は、Ｎの情報と、Ｎまでのビットマップテーブルの情報及びパターンインデックス（Index）を受信端末に通知する。

次いで、選択方法４について説明する。例えば、図２３は、端末によるリソース選択の方法の一例について説明するための説明図であり、選択方法４に基づく一連の処理の流れの一例を示している。具体的には、送信端末は、センシング及びＳＰＳリソース割り当てを実施する（Ｓ４０１）。次いで、送信端末は、自身がＳＡを送信する「SA period」内で、自分が送信する領域以外のＳＡをデコードする（Ｓ４０３）。もし、自身の割り当てと同じ端末を発見した場合には（Ｓ４０５、ＹＥＳ）、リセレクションを行うか否かを決定するためにあらかじめ規定された確率αに基づき、リセレクション（即ち、リソースの再割り当て）を行うか否かを判断する（Ｓ４０７）。リセレクションを行うことを決定した場合には（Ｓ４０７、ＹＥＳ）、送信端末は、リセレクションを実施する。リセレクションは、新たに検出した他ユーザの割り当て状況を加味して実施される（Ｓ４０９）。もともとの1^st transmissionの「SA period」にリセレクションが間に合わない場合は、次以降の「SA period」で変更を適応する。この場合、割り当て変更のためＳＡは再度送信される。なお、割り当て結果の通知について、選択方法１〜３のいずれの方法でもよい。なお、自身の割り当てと同じ端末が発見されなかった場合（Ｓ４０５、ＮＯ）や、リセレクションを行わない場合（Ｓ４０７、ＮＯ）には、送信端末は、事前に行ったリソースの割り当てに基づきデータを送信する（Ｓ４１１）。

次いで、選択方法５について説明する。例えば、図２４は、端末によるリソース選択の方法の一例について説明するための説明図であり、選択方法５に基づく一連の処理の流れの一例を示している。具体的には、受信端末(近隣端末、基地局、及びＲＳＵのいずれも可)はＳＡをデコードし（Ｓ５０１）、コリジョンを検出した場合には（Ｓ５０３、ＹＥＳ）、送信端末に対してコリジョンしている旨を通知する。ここで、コリジョンの判定について説明する。コリジョンの判定は、例えば、パターンが使用されている場合、パターンＩＤが同じかどうかで判断されてもよい（Ｓ５０５）。また、ランダム選択の場合には、コリジョン率を計算することで、当該コリジョン率を規定の閾値βとすることでコリジョンが判断されてもよい。また、通知されるシグナリングとしては、「Collision indicator」、「コリジョン（Collision）率（即ち、どの程度コリジョンしているか）」、「送信端末ＩＤ（即ち、誰と誰がコリジョンしているか）」、及び「コリジョン（Collision）が発生したリソースの場所（例えば、「SA period」番号、ＳＦＮ（Single Frequency Network）番号等）」が挙げられる。

＜３．３．ＳＡデコーディング失敗時の制御＞
続いて、ＳＰＳにおいてＳＡデコーディングに失敗した場合の制御の一例について説明する。ＳＰＳにおいてＳＡデコーディングに失敗した場合には、それ以降のデータの受信についても失敗する可能性がある。そのため、ＳＡデコーディングに失敗した場合においてもリカバーできるような仕組みが必要となる。

（ａ）SPS period内でSAの再送を実施する方法
まず、「SPS period」内でＳＡの再送を実施する方法について説明する。例えば、図２５は、「SPS period」内でＳＡを再送する場合の一例について示している。図２５に示すように、送信端末は、ＳＰＳのＳＡを受信した端末向けに、ＳＡの追加送信を実施してもよい。

なお、追加送信を行うための条件が設定されていてもよい。例えば、「SPS period」がある閾値以上の端末に対して、ＳＡの追加送信が実施されてもよい。この場合は、当該閾値は、例えば、基地局から通知されてもよいし、あらかじめ設定（Preconfigured）されていてもよい。

また、他の一例として、リソースプールのリソース占有率が閾値以下の場合（即ち、すいている場合）に、ＳＡの追加送信が実施されてもよい。この場合には、リソースプールの混雑度を検出するため、送信端末はセンシングを実施する。なお、当該センシングは「Energy sensing」でもよく「SA decoding」でもよい。また、当該閾値については、例えば、基地局から通知されてもよいし、あらかじめ設定（Preconfigured）されていてもよい。

また、他の一例として、ＳＡを追加送信するか否かを決定するためにあらかじめ規定された確率γに基づき、全員に再送されないように乱数で制限してもよい。なお、当該確率γについては、例えば、基地局から通知されてもよいし、あらかじめ設定（Preconfigured）されていてもよい。

また、追加送信が決定した端末は、ＳＡ再送のためのリソースを選択する。例えば、Mode1の場合には、端末は、基地局に「Scheduling request」を送信する。この場合には、基地局は、端末へ再送用のSAリソースを指示するか、もしくは、最初の送信からの「Timing offset」情報を送信端末へと通知する。なお、最初の送信からの「Timing offset」情報が送信端末へと通知される場合には、周波数方向は固定となる。また、他の一例として、Mode2の場合には、端末は、自律的にリソースを選択する。

次いで、追加送信されるＳＡについて説明する。例えば、端末は、1^st TransmissionのSAから、変化する点は修正を行い送信してもよい。具体的な一例として、端末は、ＳＰＳ内の「SA period」数などは、既に送った分を減算して通知する。また、他の一例として、端末は、再送分のＳＡであることを示す情報を、再送するＳＡ内に入れておいてもよい。また、最初のＳＡ送信タイミングに関する情報が合わせて通知されてもよい。この場合には、受信した端末は、最初のSA送信タイミングと再送SAの受信タイミングから、残りの送信回数を予測する。

（ｂ）SA periodをまたいでSA repetitionを送信する方法
続いて、「SA period」をまたいで「SA repetition」を送信する方法について説明する。ＳＡは、反復（Repetition）して送信が行われている。Ｄ２Ｄの規格では、「SA period」内の「SA pool」で２回反復（Repetition）送信が行われている。この反復（Repetition）送信が、1^st TransmissionのＳＡ内ではなく、初めから「SPS period」の途中の「SA pool」で送信が行われてもよい。反復（Repetition）場所については、Mode1の場合には基地局から通知され、Mode2の場合には端末自ら選択する。

（ｃ）ＳＡの再送もしくは反復（Repetition）を異なるリソースプールで行う方法
続いて、ＳＡの再送もしくは反復（Repetition）を異なるリソースプール（Resource pool）で行う方法について説明する。この方法は、ダイバーシチを得るため、複数のリソースプール（Resource pool）で送信を行う方法である。

例えば、図２６は、「Geo-location情報」を用いたリソース割り当ての一例について説明するための説明図である。図２６に示すように、「Geo-location based resource allocation」を用いられている場合には、近隣では異なるリソースプール（Resource pool）が用いられている。通常受信側は、自身のエリアの周辺の複数のプール（Pool）をモニタリングして、送信端末からの信号をもれなく受信するようにする。一方で、送信側は、基本的に自分の位置に割り当てられているリソースプールにおいて送信を行う。ＳＰＳ送信の際には、受信側のデコード失敗を防ぐために、送信側は複数のリソースプールにまたがって送信を行う。

送信するパターンとしては、以下に説明する３つのパターンが挙げられる。まず、パターン１では、送信端末の位置に割り当てられているリソースプールにおいて、ＳＡとＤａｔａが送信される。さらに周辺位置に割り当てられているリソースプールに対して、ＳＡとＤａｔａが送信される。

また、パターン２では、送信端末の位置に割り当てられているリソースプールにおいて、ＳＡとＤａｔａが送信される。さらに周辺位置に割り当てられているリソースプールに対しては、ＳＡが送信される。

また、パターン３では、送信端末の位置に割り当てられているリソースプールにおいて、ＳＡとＤａｔａが送信される。さらに周辺位置に割り当てられているリソースプールに対しては、Ｄａｔａが送信される。

送信端末は、送信端末の位置に割り当てられているリソースプールにおいて送信を行うＳＡにおいて、次回送信を行うリソースプール情報を通知してもよい。このＳＡを受信した受信端末は、次回ＳＰＳ送信時に指定されたリソースプールをモニターしに行く。また、ＳＡにおいて送信する情報は、この他にも、同時に送信を行っているリソースプール情報でもよく、実際に送信を割り当てたリソースブロック情報でもよい。また、次回送信を行うリソースブロック情報でもよい。

（ｃ−１）アクティベーション（Activation）の方法
続いて、アクティベーション（Activation）の方法について説明する。

例えば、Mode1の場合には、端末は、Multiple pool transmissionのConfiguration指示、周辺リソースプールの情報、及び、周辺リソースプールでＳＡを送信するリソース情報を通知してもらう。

また、Mode2の場合には、端末は自身で判断することとなる。具体的な一例として、「SPS period」がある閾値以上の端末を対象として、アクティベーションが行われてもよい。なお、当該閾値については、例えば、基地局から通知されてもよいし、あらかじめ設定（Preconfigured）されていてもよい。

また、他の一例として、リソースプールのリソース占有率が閾値以下の場合（即ち、すいている場合）に、アクティベーションが行われてもよい。この場合には、リソースプールの混雑度を検出するため、送信端末はセンシングを実施する。なお、当該センシングは「Energy sensing」でもよく「SA decoding」でもよい。また、当該閾値については、例えば、基地局から通知されてもよいし、あらかじめ設定（Preconfigured）されていてもよい。

また、他の一例として、ＳＡを追加送信するか否かを決定するためにあらかじめ規定された確率γに基づき、全員に再送されないように乱数で制限してもよい。なお、当該確率γについては、例えば、基地局から通知されてもよいし、あらかじめ設定（Preconfigured）されていてもよい。

＜３．４．受信端末の動作＞
続いて、受信端末の動作について説明する。

（ａ）受信端末におけるＰＳＣＣＨとＰＳＳＣＨの受信制限
ＦＤＭの場合、ＳＡとＤａｔａが同じサブフレーム（Subframe）で送信されるケースがあるため、受信端末は基本的にはＳＡとＤａｔａすべてをデコードする必要がある。そのため、帯域幅が広くなると、デコードしなければいけない帯域も増え、受信端末の負荷が増大する。そのため、端末ごとに、ＰＳＣＣＨとＰＳＳＣＨのデコード範囲を制限するための仕組みが必要となる。なお、本説明では、ＰＳＣＣＨのデコード範囲制限について説明する。

まず、受信リソースプールにおいて、端末のグループ化を導入する。例えば、図２７に、送信プールと受信プールとのグルーピングに関する構成例を示す。端末は割り当てられたグループごとに、受信リソースプール内のＳＡ領域をパーティショニング（Partitioning）して、対象のパーティション（Partition）のみをデコードする。送信側は、送信リソースプールにおいて、受信端末の全グループ（Group）が受信できるように送信を行う。例えば、図２７では、グループＡとグループＢとに向けて異なる時間で２回送信が行われている。

なお、グルーピングについては、例えば、端末ＩＤやＲＮＴＩを用いて行われてもよい。また、他の一例として、基地局からグルーピングに関するグループ情報が通知されてもよい。

（ｂ）受信端末におけるデータデコード優先度設定
続いて、ＳＡをデコードした結果としてデータ領域が被っていると判断した場合に、どのデータを優先してデコードするかを判断するための仕組みの一例について説明する。なお、本内容は、例えば、ランダム選択の場合にも起こる可能性がある。

具体的な一例として、ＳＡをデコードした結果として、１つ以上のデータが同じリソースに被っていると判断された場合には、端末は、優先度制御部テーブルに応じてデコードするパケットを選択してもよい。なお、また、当該優先度制御部テーブルについては、例えば、基地局から提供されてもよいし、あらかじめ設定（Preconfigured）されていてもよい。

また、他の一例として、送信端末は、ＳＡ内にパケットのトラフィックタイプの情報を含めてもよい。この場合には、受信端末は、トラフィックタイプの情報に応じて優先度を変化させてもよい。

また、他の一例として、送信方法に応じて優先度が設定されてもよい。具体的な一例として、ＳＰＳとそれ以外とで異なる優先度が設定されてもよい。また、他の一例として、ＭＣＳやＲＶに応じて優先度を設定されてもよい。

また、他の一例として、再送（Retransmission）回数を用いて優先度が制御されてもよい。例えば、将来再送（Retransmission）されそうなパケットについては、優先度を下げてデコードされてもよい。

また、他の一例として、ひとつ前のデータ送信のＳＩＮＲ（signal-to-interference noise ratio）を比較して、デコードされてもよい。例えば、ＳＩＮＲを高い方が優先的にデコードされてもよい。この場合には、よりデコードの確率が高い方が選択される。

＜３．５．その他＞
（ａ）コンジェスチョン（Congestion）対策１
続いて、コンジェスチョン（Congestion）への第１の対策について説明する。トラフィックが増加した場合には、送信制御が行われないと輻輳が発生し、パケットエラーレートが増加する場合がある。そのため、基地局や端末側で、「Congestion control」の仕組みが必要となる。

（ａ−１）Mode1におけるCongestion control
まず、Mode1における「Congestion control」について説明する。Mode1の場合には、基地局により「Congestion control」が実施される。例えば、図２８は、「Congestion control」の一連の処理の流れの一例について示したフローチャートである。具体的には、まず、基地局は無線通信の利用率を把握するために、各車両にセンシングを実施させ（Ｓ６０１、Ｓ６０３）、無線通信の混雑度状況をレポートしてもらう（Ｓ６０５）。これにより、基地局は混雑度を把握することが可能となる（Ｓ６０７）。そして、基地局は、混雑度に応じて、リソース割り当てに制約を設ける。また、基地局は、パケットのプライオリティに応じて、リソース割り当ての優先度を制御する。

（ａ−２）Mode2におけるCongestion control
次いで、Mode2における「Congestion control」について説明する。Mode2については、基地局のサポートがある場合と、基地局のサポートが無い場合とで処理が異なる。

例えば、基地局のサポートがある場合には、端末は、基地局からの混雑度状況の報告に応じてパケット送信の制御を変更する。具体的には、まず、図２８に示した例と同様に、基地局は、混雑度把握のため各端末に対してセンシングの結果をレポートしてもらう。混雑度状況の把握後に、基地局は、各端末に対して、「混雑度レベルの通知」と「パケット送信確率σの通知」とを行う。

「混雑度レベルの通知」を受信した端末は、混雑度レベルが示す混雑度に応じて、リソース割り当てに制約を設ける。また、端末は、パケットのプライオリティに応じて、リソース割り当ての優先度を制御する。

また、「パケット送信確率σの通知」を受けた端末は、パケットを送信する際に、送信確率σをベースに送信するか否かを判断する。なお、このとき端末は、一定以上の優先度を持つパケットについては除外してもよい。

また、基地局のサポートが無い場合には、端末は、混雑度レベルの把握のために、センシングを定期的に実施してもよい。この場合には、例えば、端末は、あらかじめ設定（Preconfigure）された閾値より上であれば混雑と判断してもよい。そして、混雑状態であれば、端末は、事前に設定（Preconfigure）されたパケット送信確率σを用いて送信するか否かを決定する。

（ｂ）コンジェスチョン（Congestion）対策２
続いて、コンジェスチョン（Congestion）への第２の対策について説明する。前述したように、トラフィックが増加した場合には、送信制御が行われないと輻輳が発生し、パケットエラーレートが増加する場合がある。このような状況下では、「SA pool」を「Traffic type」やＶ２Ｘリンクなどで分けるために複数設定してしまうと、フレキシビリティを失いリソースの利用効率が低下する場合がある。そこで、コンジェスチョン（Congestion）時に、リソースをうまく利用することができるように、「SA pool」を、状況に応じて設定可能（Configurable）に構成する。

具体的な一例として、「Event trigger traffic」用と「Periodical traffic」用との二つの「SA Pool」を規定した場合に着目する。この場合には、例えば、「Periodical traffic」用のプールが混雑しており、かつ、「Event trigger traffic」用のプールがすいている場合には、送信端末は、一時的に「Event trigger traffic」用のプールを使用する。

（ｂ−１）Mode1における動作及びシグナリング
ここで、Mode1における動作及びシグナリングについて説明する。例えば、Mode1の場合には、基地局は、図２８に示した例と同様の方法に基づき、「SA Pool」それぞれの混雑状況を把握する。もし、プールにおける相対的な混雑度の比率が閾値以上であれば、基地局は、混雑度の低い「SA pool」を混雑度の高い「SA pool」の一部として割り当てを実施する。そして、基地局は、「SA pool」のコンフィギュレーション（Configuration）情報を書き換え、端末に通知する。

（ｂ−２）Mode2における動作及びシグナリング
次いで、Mode2における動作及びシグナリングについて説明する。Mode2については、基地局のサポートがある場合と、基地局のサポートが無い場合とで処理が異なる。

例えば、基地局のサポートがある場合には、端末は、基地局からの混雑度状況の報告に応じて使用するSAを変更する。具体的には、まず、図２８に示した例と同様に、基地局は、混雑度把握のため各端末に対してセンシングの結果をレポートしてもらう。混雑度状況の把握後に、基地局は、各端末に対して、「混雑度レベルの通知」を行う。

「混雑度レベルの通知」を受信した端末は、混雑度レベルが示す混雑度に応じて、使用可能な「SA Pool」ごとに規定されている制御（換言すると、当該「SA Pool」の用途）を書き換える。このような制御に基づき、端末は、例えば、「Periodical traffic」用の「SA pool」であっても、「Event trigger」の用途で使用する（即ち、ＳＡの送信を行う）ことも可能となる。

また、基地局のサポートが無い場合には、端末は、混雑度レベルの把握のために、センシングを定期的に実施してもよい。この場合には、例えば、端末は、あらかじめ設定（Preconfigure）された閾値より上であれば混雑と判断してもよい。そして、混雑状態であれば、端末は、使用可能な「SA Pool」に対して規定されている制御（換言すると、当該「SA Pool」の用途）を書き換えてもよい。

（ｃ）ＩＢＥ対策
続いて、ＩＢＥへの対策について説明する。ＦＤＭ割り当てにおいて、同一サブフレームに対して複数ユーザの割り当てを行うと、ＩＢＥの問題が発生する場合がある。一方で、単一ユーザのみを割り当てた場合には、リソースを使い切らず、結果としてリソースの無駄遣いとなる場合がある。

そこで、ＩＢＥ対策のために、リソース間のリソースをミューティング（Muting）する。ただし、自身のリソースが隣接している場合は除くものとする。Mode1の場合には、基地局はまず、送信端末と受信端末をいくつかのグループに分け、グループごとにリソースを割り当てる。グループ割り当ては、ＩＢＥがなるべく最小になるように設定される。もし、ＩＢＥが発生しうるグループ同士を同じ時間に割り当てる場合、グループ間のリソースをミューティングすることでＩＢＥを軽減する。

また、Mode2の場合については、図２９を参照して説明する。図２９は、ＩＢＥへの対策を考慮したMode2におけるリソース割り当ての一例を示している。例えば、第１のパターンとして、他の端末のアロケーション位置より、周波数方向に距離Ｌだけ離間したリソースを選択する方法が挙げられる。なお、周波数方向に離間させる距離Ｌについては、基地局から割り当てられてもよく、あらかじめ設定（Preconfigured）されていてもよい。また、当該周波数方向の距離Ｌは、混雑度に応じて変更されてもよい。また、当該周波数方向の距離Ｌは、他の端末の割り当て領域に依存して設定されてもよい。具体的な一例として、他の端末の割り当て領域が大きいほど、より離間するように、当該周波数方向の距離Ｌが設定されてもよい。また、当該周波数方向の距離Ｌは、リソースブロック単位で規定されてもよい。

また、第２のパターンとして、他端末のアロケーション位置に隣接してリソースの選択が行われるが（Ｌ＝０）、送信時には、他端末と隣接している周波数領域をミューティング（Muting）する方法が挙げられる。なお、ミューティングする周波数方向の範囲（以降では、「ミューティング量」とも称する）は、リソース選択前に事前に設定しておく。また、ミューティング量を考慮して、ＰＲＢ（Physical Resource Block）の割り当て量を計算する。また、ミューティング量は、基地局から割り当てられてもよく、あらかじめ設定（Preconfigured）されていてもよい。また、ミューティング量は、混雑度に応じて変更されてもよい。また、ミューティング量は、他の端末の割り当て領域に依存して設定されてもよい。具体的な一例として、他の端末の割り当て領域が大きいほど、ミューティング量がより大きくなるように設定されてもよい。

なお、上述したＩＢＥ対策については、ＳＰＳのみには限定されない。

＜＜４．応用例＞＞
本開示に係る技術は、様々な製品へ応用可能である。例えば、ｅＮＢ３０は、マクロｅＮＢ又はスモールｅＮＢなどのいずれかの種類のｅＮＢ（evolved Node B）として実現されてもよい。スモールｅＮＢは、ピコｅＮＢ、マイクロｅＮＢ又はホーム（フェムト）ｅＮＢなどの、マクロセルよりも小さいセルをカバーするｅＮＢであってよい。その代わりに、ｅＮＢ３０は、ＮｏｄｅＢ又はＢＴＳ（Base Transceiver Station）などの他の種類の基地局として実現されてもよい。ｅＮＢ３０は、無線通信を制御する本体（基地局装置ともいう）と、本体とは別の場所に配置される１つ以上のＲＲＨ（Remote Radio Head）とを含んでもよい。また、後述する様々な種類の端末が一時的に又は半永続的に基地局機能を実行することにより、ｅＮＢ３０として動作してもよい。さらに、ｅＮＢ３０の少なくとも一部の構成要素は、基地局装置又は基地局装置のためのモジュールにおいて実現されてもよい。

また、例えば、ＵＥ１０、ＵＥ２０又はＲＳＵ５０は、スマートフォン、タブレットＰＣ（Personal Computer）、ノートＰＣ、携帯型ゲーム端末、携帯型／ドングル型のモバイルルータ若しくはデジタルカメラなどのモバイル端末、又はカーナビゲーション装置などの車載端末として実現されてもよい。また、ＵＥ１０、ＵＥ２０又はＲＳＵ５０は、Ｍ２Ｍ（Machine To Machine）通信を行う端末（ＭＴＣ（Machine Type Communication）端末ともいう）として実現されてもよい。さらに、ＵＥ１０、ＵＥ２０又はＲＳＵ５０の少なくとも一部の構成要素は、これら端末に搭載されるモジュール（例えば、１つのダイで構成される集積回路モジュール）において実現されてもよい。

＜４．１．ｅＮＢに関する応用例＞
（第１の応用例）
図３０は、本開示に係る技術が適用され得るｅＮＢの概略的な構成の第１の例を示すブロック図である。ｅＮＢ８００は、１つ以上のアンテナ８１０、及び基地局装置８２０を有する。各アンテナ８１０及び基地局装置８２０は、ＲＦケーブルを介して互いに接続され得る。

アンテナ８１０の各々は、単一の又は複数のアンテナ素子（例えば、ＭＩＭＯアンテナを構成する複数のアンテナ素子）を有し、基地局装置８２０による無線信号の送受信のために使用される。ｅＮＢ８００は、図３０に示したように複数のアンテナ８１０を有し、複数のアンテナ８１０は、例えばｅＮＢ８００が使用する複数の周波数帯域にそれぞれ対応してもよい。なお、図３０にはｅＮＢ８００が複数のアンテナ８１０を有する例を示したが、ｅＮＢ８００は単一のアンテナ８１０を有してもよい。

基地局装置８２０は、コントローラ８２１、メモリ８２２、ネットワークインタフェース８２３及び無線通信インタフェース８２５を備える。

コントローラ８２１は、例えばＣＰＵ又はＤＳＰであってよく、基地局装置８２０の上位レイヤの様々な機能を動作させる。例えば、コントローラ８２１は、無線通信インタフェース８２５により処理された信号内のデータからデータパケットを生成し、生成したパケットをネットワークインタフェース８２３を介して転送する。コントローラ８２１は、複数のベースバンドプロセッサからのデータをバンドリングすることによりバンドルドパケットを生成し、生成したバンドルドパケットを転送してもよい。また、コントローラ８２１は、無線リソース管理（Radio Resource Control）、無線ベアラ制御（Radio Bearer Control）、移動性管理（Mobility Management）、流入制御（Admission Control）又はスケジューリング（Scheduling）などの制御を実行する論理的な機能を有してもよい。また、当該制御は、周辺のｅＮＢ又はコアネットワークノードと連携して実行されてもよい。メモリ８２２は、ＲＡＭ及びＲＯＭを含み、コントローラ８２１により実行されるプログラム、及び様々な制御データ（例えば、端末リスト、送信電力データ及びスケジューリングデータなど）を記憶する。

ネットワークインタフェース８２３は、基地局装置８２０をコアネットワーク８２４に接続するための通信インタフェースである。コントローラ８２１は、ネットワークインタフェース８２３を介して、コアネットワークノード又は他のｅＮＢと通信してもよい。その場合に、ｅＮＢ８００と、コアネットワークノード又は他のｅＮＢとは、論理的なインタフェース（例えば、Ｓ１インタフェース又はＸ２インタフェース）により互いに接続されてもよい。ネットワークインタフェース８２３は、有線通信インタフェースであってもよく、又は無線バックホールのための無線通信インタフェースであってもよい。ネットワークインタフェース８２３が無線通信インタフェースである場合、ネットワークインタフェース８２３は、無線通信インタフェース８２５により使用される周波数帯域よりもより高い周波数帯域を無線通信に使用してもよい。

無線通信インタフェース８２５は、ＬＴＥ（Long Term Evolution）又はＬＴＥ−Ａｄｖａｎｃｅｄなどのいずれかのセルラー通信方式をサポートし、アンテナ８１０を介して、ｅＮＢ８００のセル内に位置する端末に無線接続を提供する。無線通信インタフェース８２５は、典型的には、ベースバンド（ＢＢ）プロセッサ８２６及びＲＦ回路８２７などを含み得る。ＢＢプロセッサ８２６は、例えば、符号化／復号、変調／復調及び多重化／逆多重化などを行なってよく、各レイヤ（例えば、Ｌ１、ＭＡＣ（Medium Access Control）、ＲＬＣ（Radio Link Control）及びＰＤＣＰ（Packet Data Convergence Protocol））の様々な信号処理を実行する。ＢＢプロセッサ８２６は、コントローラ８２１の代わりに、上述した論理的な機能の一部又は全部を有してもよい。ＢＢプロセッサ８２６は、通信制御プログラムを記憶するメモリ、当該プログラムを実行するプロセッサ及び関連する回路を含むモジュールであってもよく、ＢＢプロセッサ８２６の機能は、上記プログラムのアップデートにより変更可能であってもよい。また、上記モジュールは、基地局装置８２０のスロットに挿入されるカード若しくはブレードであってもよく、又は上記カード若しくは上記ブレードに搭載されるチップであってもよい。一方、ＲＦ回路８２７は、ミキサ、フィルタ及びアンプなどを含んでもよく、アンテナ８１０を介して無線信号を送受信する。

無線通信インタフェース８２５は、図３０に示したように複数のＢＢプロセッサ８２６を含み、複数のＢＢプロセッサ８２６は、例えばｅＮＢ８００が使用する複数の周波数帯域にそれぞれ対応してもよい。また、無線通信インタフェース８２５は、図３０に示したように複数のＲＦ回路８２７を含み、複数のＲＦ回路８２７は、例えば複数のアンテナ素子にそれぞれ対応してもよい。なお、図３０には無線通信インタフェース８２５が複数のＢＢプロセッサ８２６及び複数のＲＦ回路８２７を含む例を示したが、無線通信インタフェース８２５は単一のＢＢプロセッサ８２６又は単一のＲＦ回路８２７を含んでもよい。

図３０に示したｅＮＢ８００において、図１３を参照して説明した処理部３５０は、無線通信インタフェース８２５（例えば、ＢＢプロセッサ８２６）、又はコントローラ８２１において実装されてもよい。また、無線通信部３２０は、無線通信インタフェース８２５（例えば、ＲＦ回路８２７）において実装されてもよい。また、アンテナ部３１０は、アンテナ８１０において実装されてもよい。また、ネットワーク通信部３３０は、コントローラ８２１及び／又はネットワークインタフェース８２３において実装されてもよい。また、記憶部３４０は、メモリ８２２において実装されてもよい。

（第２の応用例）
図３１は、本開示に係る技術が適用され得るｅＮＢの概略的な構成の第２の例を示すブロック図である。ｅＮＢ８３０は、１つ以上のアンテナ８４０、基地局装置８５０、及びＲＲＨ８６０を有する。各アンテナ８４０及びＲＲＨ８６０は、ＲＦケーブルを介して互いに接続され得る。また、基地局装置８５０及びＲＲＨ８６０は、光ファイバケーブルなどの高速回線で互いに接続され得る。

アンテナ８４０の各々は、単一の又は複数のアンテナ素子（例えば、ＭＩＭＯアンテナを構成する複数のアンテナ素子）を有し、ＲＲＨ８６０による無線信号の送受信のために使用される。ｅＮＢ８３０は、図３１に示したように複数のアンテナ８４０を有し、複数のアンテナ８４０は、例えばｅＮＢ８３０が使用する複数の周波数帯域にそれぞれ対応してもよい。なお、図３１にはｅＮＢ８３０が複数のアンテナ８４０を有する例を示したが、ｅＮＢ８３０は単一のアンテナ８４０を有してもよい。

基地局装置８５０は、コントローラ８５１、メモリ８５２、ネットワークインタフェース８５３、無線通信インタフェース８５５及び接続インタフェース８５７を備える。コントローラ８５１、メモリ８５２及びネットワークインタフェース８５３は、図３０を参照して説明したコントローラ８２１、メモリ８２２及びネットワークインタフェース８２３と同様のものである。

無線通信インタフェース８５５は、ＬＴＥ又はＬＴＥ−Ａｄｖａｎｃｅｄなどのいずれかのセルラー通信方式をサポートし、ＲＲＨ８６０及びアンテナ８４０を介して、ＲＲＨ８６０に対応するセクタ内に位置する端末に無線接続を提供する。無線通信インタフェース８５５は、典型的には、ＢＢプロセッサ８５６などを含み得る。ＢＢプロセッサ８５６は、接続インタフェース８５７を介してＲＲＨ８６０のＲＦ回路８６４と接続されることを除き、図３０を参照して説明したＢＢプロセッサ８２６と同様のものである。無線通信インタフェース８５５は、図３１に示したように複数のＢＢプロセッサ８５６を含み、複数のＢＢプロセッサ８５６は、例えばｅＮＢ８３０が使用する複数の周波数帯域にそれぞれ対応してもよい。なお、図３１には無線通信インタフェース８５５が複数のＢＢプロセッサ８５６を含む例を示したが、無線通信インタフェース８５５は単一のＢＢプロセッサ８５６を含んでもよい。

接続インタフェース８５７は、基地局装置８５０（無線通信インタフェース８５５）をＲＲＨ８６０と接続するためのインタフェースである。接続インタフェース８５７は、基地局装置８５０（無線通信インタフェース８５５）とＲＲＨ８６０とを接続する上記高速回線での通信のための通信モジュールであってもよい。

また、ＲＲＨ８６０は、接続インタフェース８６１及び無線通信インタフェース８６３を備える。

接続インタフェース８６１は、ＲＲＨ８６０（無線通信インタフェース８６３）を基地局装置８５０と接続するためのインタフェースである。接続インタフェース８６１は、上記高速回線での通信のための通信モジュールであってもよい。

無線通信インタフェース８６３は、アンテナ８４０を介して無線信号を送受信する。無線通信インタフェース８６３は、典型的には、ＲＦ回路８６４などを含み得る。ＲＦ回路８６４は、ミキサ、フィルタ及びアンプなどを含んでもよく、アンテナ８４０を介して無線信号を送受信する。無線通信インタフェース８６３は、図３１に示したように複数のＲＦ回路８６４を含み、複数のＲＦ回路８６４は、例えば複数のアンテナ素子にそれぞれ対応してもよい。なお、図３１には無線通信インタフェース８６３が複数のＲＦ回路８６４を含む例を示したが、無線通信インタフェース８６３は単一のＲＦ回路８６４を含んでもよい。

図３１に示したｅＮＢ８３０において、図１３を参照して説明した処理部３５０は、無線通信インタフェース８５５、無線通信インタフェース８６３及び／又はコントローラ８５１において実装されてもよい。また、無線通信部３２０は、無線通信インタフェース８６３（例えば、ＲＦ回路８６４）において実装されてもよい。また、アンテナ部３１０は、アンテナ８４０において実装されてもよい。また、ネットワーク通信部３３０は、コントローラ８５１及び／又はネットワークインタフェース８５３において実装されてもよい。また、記憶部３４０は、メモリ８５２において実装されてもよい。

＜４．２．ＵＥ及びＲＳＵに関する応用例＞
（第１の応用例）
図３２は、本開示に係る技術が適用され得るスマートフォン９００の概略的な構成の一例を示すブロック図である。スマートフォン９００は、プロセッサ９０１、メモリ９０２、ストレージ９０３、外部接続インタフェース９０４、カメラ９０６、センサ９０７、マイクロフォン９０８、入力デバイス９０９、表示デバイス９１０、スピーカ９１１、無線通信インタフェース９１２、１つ以上のアンテナスイッチ９１５、１つ以上のアンテナ９１６、バス９１７、バッテリー９１８及び補助コントローラ９１９を備える。

プロセッサ９０１は、例えばＣＰＵ又はＳｏＣ（System on Chip）であってよく、スマートフォン９００のアプリケーションレイヤ及びその他のレイヤの機能を制御する。メモリ９０２は、ＲＡＭ及びＲＯＭを含み、プロセッサ９０１により実行されるプログラム及びデータを記憶する。ストレージ９０３は、半導体メモリ又はハードディスクなどの記憶媒体を含み得る。外部接続インタフェース９０４は、メモリーカード又はＵＳＢ（Universal Serial Bus）デバイスなどの外付けデバイスをスマートフォン９００へ接続するためのインタフェースである。

カメラ９０６は、例えば、ＣＣＤ（Charge Coupled Device）又はＣＭＯＳ（Complementary Metal Oxide Semiconductor）などの撮像素子を有し、撮像画像を生成する。センサ９０７は、例えば、測位センサ、ジャイロセンサ、地磁気センサ及び加速度センサなどのセンサ群を含み得る。マイクロフォン９０８は、スマートフォン９００へ入力される音声を音声信号へ変換する。入力デバイス９０９は、例えば、表示デバイス９１０の画面上へのタッチを検出するタッチセンサ、キーパッド、キーボード、ボタン又はスイッチなどを含み、ユーザからの操作又は情報入力を受け付ける。表示デバイス９１０は、液晶ディスプレイ（ＬＣＤ）又は有機発光ダイオード（ＯＬＥＤ）ディスプレイなどの画面を有し、スマートフォン９００の出力画像を表示する。スピーカ９１１は、スマートフォン９００から出力される音声信号を音声に変換する。

無線通信インタフェース９１２は、ＬＴＥ又はＬＴＥ−Ａｄｖａｎｃｅｄなどのいずれかのセルラー通信方式をサポートし、無線通信を実行する。無線通信インタフェース９１２は、典型的には、ＢＢプロセッサ９１３及びＲＦ回路９１４などを含み得る。ＢＢプロセッサ９１３は、例えば、符号化／復号、変調／復調及び多重化／逆多重化などを行なってよく、無線通信のための様々な信号処理を実行する。一方、ＲＦ回路９１４は、ミキサ、フィルタ及びアンプなどを含んでもよく、アンテナ９１６を介して無線信号を送受信する。無線通信インタフェース９１２は、ＢＢプロセッサ９１３及びＲＦ回路９１４を集積したワンチップのモジュールであってもよい。無線通信インタフェース９１２は、図３２に示したように複数のＢＢプロセッサ９１３及び複数のＲＦ回路９１４を含んでもよい。なお、図３２には無線通信インタフェース９１２が複数のＢＢプロセッサ９１３及び複数のＲＦ回路９１４を含む例を示したが、無線通信インタフェース９１２は単一のＢＢプロセッサ９１３又は単一のＲＦ回路９１４を含んでもよい。

さらに、無線通信インタフェース９１２は、セルラー通信方式に加えて、近距離無線通信方式、近接無線通信方式又は無線ＬＡＮ（Local Area Network）方式などの他の種類の無線通信方式をサポートしてもよく、その場合に、無線通信方式ごとのＢＢプロセッサ９１３及びＲＦ回路９１４を含んでもよい。

アンテナスイッチ９１５の各々は、無線通信インタフェース９１２に含まれる複数の回路（例えば、異なる無線通信方式のための回路）の間でアンテナ９１６の接続先を切り替える。

アンテナ９１６の各々は、単一の又は複数のアンテナ素子（例えば、ＭＩＭＯアンテナを構成する複数のアンテナ素子）を有し、無線通信インタフェース９１２による無線信号の送受信のために使用される。スマートフォン９００は、図３２に示したように複数のアンテナ９１６を有してもよい。なお、図３２にはスマートフォン９００が複数のアンテナ９１６を有する例を示したが、スマートフォン９００は単一のアンテナ９１６を有してもよい。

さらに、スマートフォン９００は、無線通信方式ごとにアンテナ９１６を備えてもよい。その場合に、アンテナスイッチ９１５は、スマートフォン９００の構成から省略されてもよい。

バス９１７は、プロセッサ９０１、メモリ９０２、ストレージ９０３、外部接続インタフェース９０４、カメラ９０６、センサ９０７、マイクロフォン９０８、入力デバイス９０９、表示デバイス９１０、スピーカ９１１、無線通信インタフェース９１２及び補助コントローラ９１９を互いに接続する。バッテリー９１８は、図中に破線で部分的に示した給電ラインを介して、図３２に示したスマートフォン９００の各ブロックへ電力を供給する。補助コントローラ９１９は、例えば、スリープモードにおいて、スマートフォン９００の必要最低限の機能を動作させる。

図３２に示したスマートフォン９００において、図１１を参照して説明した処理部１５０、図１２を参照して説明した処理部２５０、又は図１４を参照して説明した処理部５４０は、無線通信インタフェース９１２又はプロセッサ９０１において実装されてもよい。また、無線通信部１２０、無線通信部２２０、又は無線通信部５２０は、無線通信インタフェース９１２（例えば、ＲＦ回路９１４）において実装されてもよい。また、ＧＮＳＳ信号処理部１３０又はＧＮＳＳ信号処理部２３０は、センサ９０７において実装されてもよい。また、アンテナ部１１０、アンテナ部２１０又はアンテナ部５１０は、アンテナ９１６において実装されてもよい。また、記憶部１４０、記憶部２４０又は記憶部５３０は、メモリ９０２において実装されてもよい。

（第２の応用例）
図３３は、本開示に係る技術が適用され得るカーナビゲーション装置９２０の概略的な構成の一例を示すブロック図である。カーナビゲーション装置９２０は、プロセッサ９２１、メモリ９２２、ＧＰＳ（Global Positioning System）モジュール９２４、センサ９２５、データインタフェース９２６、コンテンツプレーヤ９２７、記憶媒体インタフェース９２８、入力デバイス９２９、表示デバイス９３０、スピーカ９３１、無線通信インタフェース９３３、１つ以上のアンテナスイッチ９３６、１つ以上のアンテナ９３７及びバッテリー９３８を備える。

プロセッサ９２１は、例えばＣＰＵ又はＳｏＣであってよく、カーナビゲーション装置９２０のナビゲーション機能及びその他の機能を制御する。メモリ９２２は、ＲＡＭ及びＲＯＭを含み、プロセッサ９２１により実行されるプログラム及びデータを記憶する。

ＧＰＳモジュール９２４は、ＧＰＳ衛星から受信されるＧＰＳ信号を用いて、カーナビゲーション装置９２０の位置（例えば、緯度、経度及び高度）を測定する。センサ９２５は、例えば、ジャイロセンサ、地磁気センサ及び気圧センサなどのセンサ群を含み得る。データインタフェース９２６は、例えば、図示しない端子を介して車載ネットワーク９４１に接続され、車速データなどの車両側で生成されるデータを取得する。

コンテンツプレーヤ９２７は、記憶媒体インタフェース９２８に挿入される記憶媒体（例えば、ＣＤ又はＤＶＤ）に記憶されているコンテンツを再生する。入力デバイス９２９は、例えば、表示デバイス９３０の画面上へのタッチを検出するタッチセンサ、ボタン又はスイッチなどを含み、ユーザからの操作又は情報入力を受け付ける。表示デバイス９３０は、ＬＣＤ又はＯＬＥＤディスプレイなどの画面を有し、ナビゲーション機能又は再生されるコンテンツの画像を表示する。スピーカ９３１は、ナビゲーション機能又は再生されるコンテンツの音声を出力する。

無線通信インタフェース９３３は、ＬＴＥ又はＬＴＥ−Ａｄｖａｎｃｅｄなどのいずれかのセルラー通信方式をサポートし、無線通信を実行する。無線通信インタフェース９３３は、典型的には、ＢＢプロセッサ９３４及びＲＦ回路９３５などを含み得る。ＢＢプロセッサ９３４は、例えば、符号化／復号、変調／復調及び多重化／逆多重化などを行なってよく、無線通信のための様々な信号処理を実行する。一方、ＲＦ回路９３５は、ミキサ、フィルタ及びアンプなどを含んでもよく、アンテナ９３７を介して無線信号を送受信する。無線通信インタフェース９３３は、ＢＢプロセッサ９３４及びＲＦ回路９３５を集積したワンチップのモジュールであってもよい。無線通信インタフェース９３３は、図３３に示したように複数のＢＢプロセッサ９３４及び複数のＲＦ回路９３５を含んでもよい。なお、図３３には無線通信インタフェース９３３が複数のＢＢプロセッサ９３４及び複数のＲＦ回路９３５を含む例を示したが、無線通信インタフェース９３３は単一のＢＢプロセッサ９３４又は単一のＲＦ回路９３５を含んでもよい。

さらに、無線通信インタフェース９３３は、セルラー通信方式に加えて、近距離無線通信方式、近接無線通信方式又は無線ＬＡＮ方式などの他の種類の無線通信方式をサポートしてもよく、その場合に、無線通信方式ごとのＢＢプロセッサ９３４及びＲＦ回路９３５を含んでもよい。

アンテナスイッチ９３６の各々は、無線通信インタフェース９３３に含まれる複数の回路（例えば、異なる無線通信方式のための回路）の間でアンテナ９３７の接続先を切り替える。

アンテナ９３７の各々は、単一の又は複数のアンテナ素子（例えば、ＭＩＭＯアンテナを構成する複数のアンテナ素子）を有し、無線通信インタフェース９３３による無線信号の送受信のために使用される。カーナビゲーション装置９２０は、図３３に示したように複数のアンテナ９３７を有してもよい。なお、図３３にはカーナビゲーション装置９２０が複数のアンテナ９３７を有する例を示したが、カーナビゲーション装置９２０は単一のアンテナ９３７を有してもよい。

さらに、カーナビゲーション装置９２０は、無線通信方式ごとにアンテナ９３７を備えてもよい。その場合に、アンテナスイッチ９３６は、カーナビゲーション装置９２０の構成から省略されてもよい。

バッテリー９３８は、図中に破線で部分的に示した給電ラインを介して、図３３に示したカーナビゲーション装置９２０の各ブロックへ電力を供給する。また、バッテリー９３８は、車両側から給電される電力を蓄積する。

図３３に示したカーナビゲーション装置９２０において、図１１を参照して説明した処理部１５０、図１２を参照して説明した処理部２５０、又は図１４を参照して説明した処理部５４０は、無線通信インタフェース９３３又はプロセッサ９２１において実装されてもよい。また、無線通信部１２０、無線通信部２２０、又は無線通信部５２０は、無線通信インタフェース９３３（例えば、ＲＦ回路９３５）において実装されてもよい。また、ＧＮＳＳ信号処理部１３０又はＧＮＳＳ信号処理部２３０は、ＧＰＳモジュール９２４において実装されてもよい。また、アンテナ部１１０、アンテナ部２１０又はアンテナ部５１０は、アンテナ９３７において実装されてもよい。また、記憶部１４０、記憶部２４０又は記憶部５３０は、メモリ９２２において実装されてもよい。

また、本開示に係る技術は、上述したカーナビゲーション装置９２０の１つ以上のブロックと、車載ネットワーク９４１と、車両側モジュール９４２とを含む車載システム（又は車両）９４０として実現されてもよい。即ち、図１２を参照して説明した処理部２５０を備える装置として車載システム（又は車両）９４０が提供されてもよい。

＜＜５．むすび＞＞
以上、図１〜図３３を参照して、本開示の一実施形態について詳細に説明した。

前述したように、Mode1での動作時には、本実施形態に係る基地局は、複数の端末装置間における端末間通信（即ち、Ｖ２Ｘ通信）のために、ＳＰＳにおけるリソースを割り当て、当該リソースの割り当てに関する制御情報が、無線通信を介して端末装置に送信されるように制御する。また、Mode2での動作時においては、本実施形態に係る端末装置は、他の端末装置との端末間通信（即ち、Ｖ２Ｘ通信）のために、所定のリソースプールからＳＰＳにおけるリソースを割り当て、当該リソースの割り当てに関する制御情報が、無線通信を介して他の端末装置に送信されるように制御する。以上のような構成により、本実施形態に係る無線通信システムは、Ｖ２Ｘ通信においてもＳＰＳを適用することで、リソースを効率的に使用することで可能となり、ひいてはキャパシティをより拡大することが可能となる。

以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本開示の技術的範囲はかかる例に限定されない。本開示の技術分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。

また、本明細書に記載された効果は、あくまで説明的または例示的なものであって限定的ではない。つまり、本開示に係る技術は、上記の効果とともに、または上記の効果に代えて、本明細書の記載から当業者には明らかな他の効果を奏しうる。

なお、以下のような構成も本開示の技術的範囲に属する。
（１）
無線通信を行う通信部と、
複数の端末装置間における端末間通信のために、セミパーシステントスケジューリングにおけるリソースを割り当て、前記リソースの割り当てに関する制御情報が、前記無線通信を介して前記端末装置に送信されるように制御する処理部と、
を備える、基地局。
（２）
前記処理部は、マルチキャリア通信をサポートする場合に、対象となるコンポーネントキャリア情報が、前記制御情報に関連付けられて通知されるように制御する、前記（１）に記載の基地局。
（３）
前記処理部は、所定のリソースプールから前記リソースを割り当て、当該リソースプールに関する情報が、前記制御情報に関連付けられて通知されるように制御する、前記（１）または（２）に記載の基地局。
（４）
前記端末装置から当該端末装置の位置情報を取得する取得部を備え、
前記処理部は、取得した前記端末装置の位置情報に応じた前記リソースプールから、当該端末装置に対して前記リソースを割り当てる、
前記（３）に記載の基地局。
（５）
前記処理部は、取得した前記端末装置の位置情報に基づく、以降における当該端末装置の位置の予測結果に応じた前記リソースプールに対してセミパーシステントスケジューリングを設定し、当該リソースプールに関する情報が当該端末装置に通知されるように制御する、前記（４）に記載の基地局。
（６）
前記処理部は、セミパーシステントスケジューリングを一時中断する場合の停止期間に関する情報を、前記制御情報に関連付けられて通知されるように制御する、前記（１）〜（５）のいずれか一項に記載の基地局。
（７）
前記処理部は、セミパーシステントスケジューリングをリリースまたはリコンフィギュレーションした場合に、当該リリースまたはリコンフィギュレーションの結果に関する情報が、前記端末装置に通知されるように制御する、前記（１）〜（６）のいずれか一項に記載の基地局。
（８）
前記処理部は、前記複数の端末装置のうち第１の端末装置が、前記制御情報を送信した１以上の第２の端末装置のうち少なくとも一部を対象として、前記制御情報が送信されてから当該制御情報を追加送信するまでの期間に関する情報が、前記第１の端末装置に通知されるように制御する、前記（１）〜（７）のいずれか一項に記載の基地局。
（９）
無線通信を行う通信部と、
他の端末装置との端末間通信のために、所定のリソースプールからセミパーシステントスケジューリングにおけるリソースを割り当て、前記リソースの割り当てに関する制御情報が、前記無線通信を介して前記他の端末装置に送信されるように制御する処理部と、
を備える、端末装置。
（１０）
前記処理部は、前記リソースの使用状況をセンシングし、当該センシングの結果に応じて、前記端末間通信のための前記リソースを割り当てる、前記（９）に記載の端末装置。
（１１）
前記処理部は、前記制御情報として、前記リソースの割り当てに応じたビットマップテーブルが、前記他の端末装置に送信されるように制御する、前記（１０）に記載の端末装置。
（１２）
前記処理部は、前記センシングの結果に基づき、前記リソースの割り当てのための所定の送信パターンの候補の中から適用する前記送信パターンを選択し、選択した前記送信パターンに関する情報が、前記他の端末装置に送信されるように制御する、前記（１０）に記載の端末装置。
（１３）
前記処理部は、
Ｎを自然数とした場合に、前記他の端末装置に対する送信のうち、Ｎ回目の送信までについては前記センシングの結果に基づき前記リソースを任意に割り当て、Ｎ＋１回目以降の送信については、前記送信パターンに応じて前記リソースを割り当て、
前記リソースを任意に割り当てて送信する回数Ｎに関する情報と、Ｎ回目の送信までの前記リソースの割り当てに応じたビットマップテーブルと、選択した前記送信パターンに関する情報とが、前記他の端末装置に送信されるように制御する、前記（１２）に記載の端末装置。
（１４）
前記処理部は、割り当てた前記リソースのうち少なくとも一部が衝突する他の端末装置を検出し、当該検出結果に応じて前記リソースの再割り当てを実施する、前記（１０）に記載の端末装置。
（１５）
割り当てた前記リソースのうち少なくとも一部が衝突する他の端末装置の検出結果に応じた情報を外部装置から取得する取得部を備え、
前記処理部は、取得した前記検出結果に応じた情報に基づき、前記リソースの再割り当てを実施する、
前記（１０）に記載の端末装置。
（１６）
前記取得部は、前記検出結果に応じた情報として、前記衝突の有無、前記衝突の度合い、前記衝突が生じている他の端末装置に関する情報、及び前記衝突が生じた前記リソースのうち、少なくともいずれかの情報を取得する、前記（１５）に記載の端末装置。
（１７）
前記処理部は、
周波数分割多重方式に基づき、前記制御情報の送信と、当該制御情報により割り当てられた前記リソースを介したデータの送信とを行うための送信期間を設定し、
設定した当該送信期間に関する情報が、前記端末装置に通知されるように制御する、前記（９）〜（１６）のいずれか一項に記載の端末装置。
（１８）
前記処理部は、
前記制御情報により割り当てられた前記リソースを介して送信されたデータを、再送するまでの期間に応じたオフセット値を設定し、
設定した前記オフセット値に関する情報が、前記端末装置に通知されるように制御する、前記（９）〜（１６）のいずれか一項に記載の端末装置。
（１９）
前記処理部は、
前記制御情報が送信される期間と、当該当該制御情報により割り当てられた前記リソースを介してデータが送信される期間との間のオフセット値を設定し、
設定した前記オフセット値に関する情報が、前記他の端末装置に通知されるように制御する、前記（９）〜（１６）のいずれか一項に記載の端末装置。
（２０）
前記処理部は、前記制御情報が送信された１以上の前記他の端末装置のうち少なくとも一部を対象として、所定の条件に基づき、前記制御情報が追加送信されるように制御する、前記（９）〜（１９）のいずれか一項に記載の端末装置。
（２１）
前記処理部は、前記制御情報を送信するために設定された互いに異なる複数のリソースプールのうち、第１のリソースプールの混雑度の状況に応じて、第２のリソースプールを前記第１のリソースプールの一部として割り当てる、前記（９）〜（２０）のいずれか一項に記載の端末装置。
（２２）
前記処理部は、前記制御情報を送信するために設定された互いに用途の異なる複数のリソースプールのうち、第１のリソースプールの混雑度の状況に応じて、第２のリソースプールの用途を変更する、前記（９）〜（２１）のいずれか一項に記載の端末装置。
（２３）
前記処理部は、前記リソースを割り当てるためのリソースプールの混雑度の状況に応じて、前記リソースの割り当てを制限する、前記（９）〜（２２）のいずれか一項に記載の端末装置。
（２４）
無線通信を行うことと、
複数の端末装置間における端末間通信のために、セミパーシステントスケジューリングにおけるリソースを割り当て、前記リソースの割り当てに関する制御情報が、前記無線通信を介して前記端末装置に送信されるように制御することと、
を含む、通信方法。
（２５）
無線通信を行う通信部と、
他の端末装置との端末間通信のために、所定のリソースプールからセミパーシステントスケジューリングにおけるリソースを割り当て、前記リソースの割り当てに関する制御情報が、前記無線通信を介して前記他の端末装置に送信されるように制御する処理部と、
を含む、通信方法。

１０ ＵＥ
１１０ アンテナ部
１２０ 無線通信部
１３０ ＧＮＳＳ信号処理部
１４０ 記憶部
１５０ 処理部
２０ ＵＥ
２１０ アンテナ部
２２０ 無線通信部
２３０ ＧＮＳＳ信号処理部
２４０ 記憶部
２５０ 処理部
２２ 車両
３０ ｅＮＢ
３１０ アンテナ部
３２０ 無線通信部
３３０ ネットワーク通信部
３４０ 記憶部
３５０ 処理部
４０ ＧＮＳＳ衛星
５０ ＲＳＵ

Claims (8)

1. 無線通信を行う通信部と、
   複数の端末装置間における端末間通信のために、セミパーシステントスケジューリングにおけるリソースを割り当て、前記リソースの割り当てに関する制御情報が、前記無線通信を介して前記端末装置に送信されるように制御する処理部と、
   前記端末装置から当該端末装置の位置情報を取得する取得部と、
   を備え、
   前記処理部は、取得した前記端末装置の位置情報に応じた所定のリソースプールから、当該端末装置に対して前記リソースを割り当てる、基地局。
2. 前記処理部は、マルチキャリア通信をサポートする場合に、対象となるコンポーネントキャリア情報が、前記制御情報に関連付けられて通知されるように制御する、請求項１に記載の基地局。
3. 前記処理部は、前記リソースプールに関する情報が、前記制御情報に関連付けられて通知されるように制御する、請求項１または２に記載の基地局。
4. 前記処理部は、取得した前記端末装置の位置情報に基づく、以降における当該端末装置の位置の予測結果に応じた前記リソースプールに対してセミパーシステントスケジューリングを設定し、当該リソースプールに関する情報が当該端末装置に通知されるように制御する、請求項１〜３の何れか１項に記載の基地局。
5. 前記処理部は、セミパーシステントスケジューリングを一時中断する場合の停止期間に関する情報を、前記制御情報に関連付けられて通知されるように制御する、請求項１に記載の基地局。
6. 前記処理部は、セミパーシステントスケジューリングをリリースまたはリコンフィギュレーションした場合に、当該リリースまたはリコンフィギュレーションの結果に関する情報が、前記端末装置に通知されるように制御する、請求項１〜５のいずれか一項に記載の基地局。
7. 前記処理部は、前記複数の端末装置のうち第１の端末装置から前記制御情報が送信された１以上の第２の端末装置のうち少なくとも一部が、前記制御情報が送信されてから当該制御情報を追加送信するまでの期間に関する情報を前記第１の端末装置に通知するように制御する、請求項１〜６のいずれか一項に記載の基地局。
8. 無線通信を行うことと、
   複数の端末装置間における端末間通信のために、セミパーシステントスケジューリングにおけるリソースを割り当て、前記リソースの割り当てに関する制御情報が、前記無線通信を介して前記端末装置に送信されるように制御することと、
   前記端末装置から当該端末装置の位置情報を取得することと、
   を含み、
   前記リソースの割り当てでは、取得した前記端末装置の位置情報に応じた所定のリソースプールから、当該端末装置に対して前記リソースが割り当てられる、通信方法。

Images