JP6669041B2 - 通信装置、通信方法及びコンピュータプログラム - Google Patents

Description

本開示は、通信装置、通信方法及びコンピュータプログラムに関する。

端末装置間のＤ２Ｄ（Ｄｅｖｉｃｅ ｔｏ Ｄｅｖｉｃｅ）通信においてリソースを割り当てるための技術が開示されている（例えば特許文献１）。

その一方で、将来の自動運転の実現のため、近年、車載通信（Ｖ２Ｘ通信）への期待が高まってきている。Ｖ２Ｘ通信とは、Ｖｅｈｉｃｌｅ ｔｏ Ｘ通信の略であり、車と“何か”が通信を行うシステムである。ここでの“何か”の例として、車両（Ｖｅｈｉｃｌｅ）、施設（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ／Ｎｅｔｗｏｒｋ）、歩行者（Ｐｅｄｅｓｔｒｉａｎ）等が挙げられる（Ｖ２Ｖ，Ｖ２Ｉ／Ｎ，Ｖ２Ｐ）。車用の無線通信としては、これまで主に、８０２．１１ｐベースのＤＳＲＣ（Ｄｅｄｉｃａｔｅｄ Ｓｈｏｒｔ Ｒａｎｇｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）の開発が進められてきたが、近年になり、ＬＴＥベースの車載通信である“ＬＴＥ−ｂａｓｅｄ Ｖ２Ｘ”の標準化議論がスタートしている。

特表２０１５−５０８９４３号公報

本開示では、Ｖ２Ｘ通信を初めとした装置間通信において効率的なリソースのセンシングが可能な、新規かつ改良された通信装置、通信方法及びコンピュータプログラムを提案する。

本開示によれば、装置間通信を実行する端末装置がリソース選択できるリソース領域を割当て、前記リソース領域のセンシングの範囲に関する情報を前記端末装置に提供する制御部を備える、通信装置が提供される。

また本開示によれば、基地局から割り当てられたリソース領域の中からリソースを選択し、選択したリソースを用いて装置間通信を実行する際に、前記リソース領域のセンシングの範囲を状況に応じて決定する制御部を備える、通信装置が提供される。

また本開示によれば、装置間通信を実行する端末装置がリソース選択できるリソース領域を割当て、前記リソース領域のセンシングの範囲に関する情報を前記端末装置に提供することを含む、通信方法が提供される。

また本開示によれば、基地局から割り当てられたリソース領域の中からリソースを選択し、選択したリソースを用いて装置間通信を実行する際に、前記リソース領域のセンシングの範囲を状況に応じて決定することを含む、通信方法が提供される。

また本開示によれば、装置間通信を実行する端末装置がリソース選択できるリソース領域を割当て、前記リソース領域のセンシングの範囲に関する情報を前記端末装置に提供することをコンピュータに実行させる、コンピュータプログラムが提供される。

また本開示によれば、基地局から割り当てられたリソース領域の中からリソースを選択し、選択したリソースを用いて装置間通信を実行する際に、前記リソース領域のセンシングの範囲を状況に応じて決定することをコンピュータに実行させる、コンピュータプログラムが提供される。

以上説明したように本開示によれば、Ｖ２Ｘ通信を初めとした装置間通信において効率的なリソースのセンシングが可能な、新規かつ改良された通信装置、通信方法及びコンピュータプログラムが提供される。

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

Ｖ２Ｘオペレーションシナリオを説明する説明図である。 Ｖ２Ｘオペレーションシナリオを説明する説明図である。 Ｖ２Ｘオペレーションシナリオを説明する説明図である。 Ｖ２Ｘオペレーションシナリオを説明する説明図である。 Ｖ２Ｘオペレーションシナリオを説明する説明図である。 ＩＢＥについて説明する説明図である。 ＴＤＭ割り当てとＦＤＭ割り当てについて説明する説明図である。 ＳＰＳの概要を説明する説明図である。 ＳＰＳの概要を説明する説明図である。 ＳＰＳの概要を説明する説明図である。 本開示の実施の形態に係る端末装置の動作例を示す流れ図である。 端末装置における、送信データの発生からデータ送信予約までを説明する説明図である。 リソースプールに導入されるScheduling periodの例を示す説明図である。 グルーピングされたScheduling periodの例を示す説明図である。 端末装置がScheduling periodのナンバーに応じてリソースホッピングを行う例を示す説明図である。 共通センシング領域について説明する説明図である。 本開示の実施形態に係る基地局１００の構成の一例を示すブロック図である。 本開示の実施形態に係る端末装置２００の構成の一例を示すブロック図である。 本開示に係る技術が適用され得るｅＮＢの概略的な構成の第１の例を示すブロック図である。 本開示に係る技術が適用され得るｅＮＢの概略的な構成の第２の例を示すブロック図である。 本開示に係る技術が適用され得るスマートフォン９００の概略的な構成の一例を示すブロック図である。 本開示に係る技術が適用され得るカーナビゲーション装置９２０の概略的な構成の一例を示すブロック図である。 同実施の形態に係るNetwork側及び歩行者UE側の処理の例を示す説明図である。 同実施の形態に係るNetwork側及び歩行者UE側の処理の例を示す説明図である。 同実施の形態に係るNetwork側及び歩行者UE側の処理の例を示す説明図である。 同実施の形態に係るNetwork側及び歩行者UE側の処理の例を示す説明図である。 同実施の形態に係るNetwork側及び歩行者UE側の処理の例を示す説明図である。 同実施の形態に係るNetwork側及び歩行者UE側の処理の例を示す説明図である。 同実施の形態に係るNetwork側及び歩行者UE側の処理の例を示す説明図である。 同実施の形態に係るNetwork側及び歩行者UE側の処理の例を示す説明図である。 Burst sensingの例を示す説明図である。 Burst sensingの例を示す説明図である。 Distributed sensingの例を示す説明図である。 Sub-sensingごとの設定を同一にしたセンシングの例を示す説明図である。 Sub-sensingごとの設定を変化させたセンシングの例を示す説明図である。

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

なお、説明は以下の順序で行うものとする。
１．本開示の実施の形態
１．１．概要
１．２．実施例
１．３．構成例
２．応用例
３．まとめ

＜１．本開示の実施の形態＞
［１．１．概要］
まず、本開示の実施の形態の概要を説明する。

上述したように、将来の自動運転の実現のため、近年、車載通信（Ｖ２Ｘ通信）への期待が高まってきている。Ｖ２Ｘ通信とは、Ｖｅｈｉｃｌｅ ｔｏ Ｘ通信の略であり、車と“何か”が通信を行うシステムである。ここでの“何か”の例として、車両（Ｖｅｈｉｃｌｅ）、施設（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ／Ｎｅｔｗｏｒｋ）、歩行者（Ｐｅｄｅｓｔｒｉａｎ）等が挙げられる（Ｖ２Ｖ，Ｖ２Ｉ／Ｎ，Ｖ２Ｐ）。車用の無線通信としては、これまで主に、８０２．１１ｐベースのＤＳＲＣの開発が進められてきたが、近年になり、ＬＴＥベースの車載通信である“ＬＴＥ−ｂａｓｅｄ Ｖ２Ｘ”の標準化議論がスタートしている。

Ｖ２Ｘ通信のユースケースの一例を下記に示す。主に安全用途をターゲットとし、定期的に車両にメッセージを送るような周期的なメッセージの送信や、イベントに応じて必要な情報を提供するイベントトリガメッセージのような通信が求められている（３ＧＰＰ ＴＲ ２２．８８５）。

（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.V2I
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

これらのユースケースをベースとした要求事項の一例を下記に示す。

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

Ｖ２Ｘ通信のベース技術としては、３ＧＰＰで過去に規格化されたＤ２Ｄ（Ｄｅｖｉｃｅ ｔｏ ｄｅｖｉｃｅ）通信があげられる。Ｄ２Ｄ通信は基地局を介さない端末間通信のため、Ｖ２Ｖ通信やＶ２Ｐ通信にエンハンスして適応されることが考えられる（一部Ｖ２Ｉ通信にも適応可能）。このような端末間のインタフェースをＰＣ５インタフェースと呼ぶ。

また、Ｖ２Ｉ通信やＶ２Ｎ通信においては、既存の基地局と端末間の通信をエンハンスして適応することが考えられる。このような基地局、端末間のインタフェースをＵｕインタフェースと呼ぶ。

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

主なエンハンスメントのポイントは、例えば、リソース割り当ての改善、ドップラー周波数対策、同期手法の確立、低消費電力通信の実現、低遅延通信の実現などである。

（Ｖ２Ｘオペレーションシナリオ）
Ｖ２Ｘオペレーションシナリオを説明する。Ｖ２Ｖ通信をベースに構成される。なお、以下の説明で片方の自動車が歩行者になるとＶ２Ｐ通信となり、施設やネットワークで終端するとＶ２Ｉ／Ｎ通信となる。

図１〜図５は、Ｖ２Ｘオペレーションシナリオを説明する説明図である。図１は、車両同士が基地局（Ｅ−ＵＴＲＡＮ）を介さずに直接通信するシナリオを示している。図２は、車両同士が基地局を介して通信するシナリオを示している。図３及び図４は、車両同士が端末（ＵＥ、ここでは路側無線装置（ＲＳＵ））及び基地局を介して通信するシナリオを示している。図５は、車両同士が端末（ＵＥ、ここでは路側無線装置（ＲＳＵ））を介して通信するシナリオを示している。

Ｖ２Ｘ通信は、要求事項や通信環境などがＤ２Ｄ通信とは異なるため、既存のＤ２Ｄ通信をそのまま用いることはできない。そのため、Ｖ２Ｘ通信に適応する形にエンハンスする必要がある。Ｄ２Ｄ通信とＶ２Ｘ通信の特徴の違いを下記に示す。

（１）Ｖ２Ｘ通信は信頼性が高く、低遅延通信が必要。
（２）Ｖ２Ｘ特有のトラフィックが存在する。
（３）Ｖ２Ｘは様々なリンクを持つ。
（４）ＩＢＥ（Ｉｎ−Ｂａｎｄ Ｅｍｉｓｓｉｏｎ）問題。
（５）ＨＤ（Ｈａｌｆ Ｄｕｐｌｅｘ）問題。
（６）Ｄ２ＤよりＣａｐａｃｉｔｙが大きな課題になる。
（７）位置情報が常に得られる。

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

（２）のＶ２Ｘ特有のトラフィックについては、Ｖ２Ｘ通信では、主にＰｅｒｉｏｄｉｃ ｔｒａｆｆｉｃとＥｖｅｎｔ ｔｒｉｇｇｅｒ ｔｒａｆｆｉｃの二つが想定されている。Ｐｅｒｉｏｄｉｃ ｔｒａｆｆｉｃは定期的にデータを周辺車両に通知するような通信であり、これもＶ２Ｘの特徴的な点である。

（３）の様々なリンクについては、Ｖ２Ｘ通信では車の通信対象（Ｘ）として、Ｖ（車両）／Ｉ（施設）／Ｎ（ネットワーク）／Ｐ（歩行者）を想定している。このような多様なリンクを持つ点もＶ２Ｘ通信特有である。

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

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

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

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

これらの問題を解決する為、３ＧＰＰではＦＤＭ（Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘｉｎｇ ；周波数分割多重化）を用いたリソース割り当て方法が現在検討されている。ＴＤＭ（Ｔｉｍｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘｉｎｇ；時分割多重化）割り当てとＦＤＭ割り当てについて、図７を用いて説明を行う。Ｄ２Ｄ通信やＶ２Ｘ通信が行われるＰＣ５インタフェースは、主に制御チャネル部（ＰＳＣＣＨ：Ｐｈｙｓｉｃａｌ Ｓｉｄｅｌｉｎｋ Ｃｏｎｔｒｏｌ ＣＨａｎｎｅｌ）とデータチャネル部（ＰＳＳＣＨ：Ｐｈｙｓｉｃａｌ Ｓｉｄｅｌｉｎｋ Ｓｈａｒｅｄ ＣＨａｎｎｅｌ）から構成されている。

ＰＳＣＣＨにおいてＰＳＳＣＨのリソース指示などを通知するため、ＴＤＭ方式では、パケットの発生から送信までの遅延が大きくなるといった問題がある。一方で、端末の複雑度（Ｃｏｍｐｌｅｘｉｔｙ）が良いというメリットがある。なお、Ｄ２ＤではＴＤＭ割り当て方式が採用されている。これに対しては、ＦＤＭ方式では、周波数方向にＰＳＣＣＨがマッピングされているため、遅延が改善される。また、ＳＡ（Ｓｃｈｅｄｕｌｉｎｇ Ａｓｓｉｇｎｍｅｎｔ）とＤａｔａを同じＳＦ（サブフレーム）で送信することで、ＩＢＥやＨＤの問題も改善することが期待できる。そのため、Ｖ２Ｘ通信では、ＦＤＭ方式を用いた通信方法の確立が求められている。

ＦＤＭ方式に加えてさらなるエンハンスメントの追加も検討されている。前述した（６）のキャパシティの問題を解決する為に、現在ＳＰＳ（Ｓｅｍｉ−Ｐｅｒｓｉｓｔｅｎｔ Ｓｃｈｅｄｕｌｉｎｇ）の導入も検討されている。これは、Ｖ２Ｘ通信で特徴のあるトラフィックタイプの特性をうまく利用している。ＳＰＳの概要を図８〜図１０に示す。ＳＰＳでは一つのＳＡで複数のデータをスケジューリングする。そのため、データ送信の度にＳＡを送信する必要がなく、オーバーヘッドの削減が可能になる。特にＶ２ＸのＰｅｒｉｏｄｉｃａｌ ｔｒａｆｆｉｃのような周期的な通信においては、このようなスケジューリングが大きな効果を生むことが確認されている。そのため、Ｖ２Ｘ通信では、ＳＰＳの導入も求められている。
（６）で述べたとおり、Ｖ２Ｘではキャパシティが大きな問題となる。そこで、周波数リソースの空間再利用が検討されている。空間再利用を行うに当たり、（７）で説明した、自動車の位置情報を活用する。この位置情報を用いたエンハンスメントも現在３ＧＰＰで議論されている。

これまでが、ＰＣ５インタフェースのエンハンスメントの概要である。Ｖ２Ｘ通信では、リソース割り当ての方法として、Ｍｏｄｅ１のＣｅｎｔｒａｌｉｚｅｄ ｒｅｓｏｕｒｃｅ ａｌｌｏｃａｔｉｏｎとＭｏｄｅ２のＡｕｔｏｎｏｍｏｕｓ ｒｅｓｏｕｒｃｅ ｓｅｌｅｃｔｉｏｎの２種類がある。Ｍｏｄｅ１の場合は、ＰＣ５インタフェースのリソース割り当てを基地局がすべて行う。端末側では基地局に指示されたリソースで送信を行うだけでよい。基地局端末間のオーバーヘッドが懸念されるが、リソースが直交して割り当てられるため通信特性はよい。一方で、Ｍｏｄｅ２では、端末は基地局から通知されたリソースプールの中から、自律的に送信に使用するリソースを選択する。Ｍｏｄｅ１のオーバーヘッドの懸念がないが、他端末と同じリソースを選択してしまう可能性もあるため、Ｃｏｌｌｉｓｉｏｎの課題が出てくる。Ｍｏｄｅ２は基地局のＮｅｔｗｏｒｋ内であるＩｎ−ｃｏｖｅｒａｇｅのみならず、Ｏｕｔ−ｏｆ−ｏｖｅｒａｇｅでオペレーションできるというメリットもある。

このＭｏｄｅ２のＣｏｌｌｉｓｉｏｎ問題についても、現在いくつかの提案が行われている。Ｓｏｌｕｔｉｏｎは大きく２つに分けられる。一つはＥｎｅｒｇｙ ｓｅｎｓｉｎｇである。Ｅｎｅｒｇｙ ｓｅｎｓｉｎｇでは、ある一定期間リソースをセンシングし、そのセンシング結果に基づいて、比較的使用されていないリソースから通信用のリソースを選択する方法である。簡単である一方、電力レベルなので精度はそこまで高くない。ただし、ＬＴＥ以外のシステムをセンシングすることが可能である。もう一つの方法は、ＳＡ ｄｅｃｏｄｉｎｇである。これは、他ユーザが送信しているＳＡ（制御情報）をデコードし、使用されているリソースの場所を認識する方法である。使用されているリソースが精度よく発見することができる反面、ＳＡリソース自体のセンシングが行えない、ＳＡのデコードを失敗すると使用されているリソースが検出できないなどのデメリットがある。

Ｖ２Ｘ通信のような装置間通信において、優先度が異なるパケットの送信が管理されなければならず、優先度の高い通信ほど確実に行われるべきである。従って、端末装置がどのようにリソースを選択して装置間通信を行うかが非常に重要となる。

そこで本件開示者は、上述の内容に鑑み、Ｖ２Ｘ通信のような装置間通信において効率的にリソースが選択できる技術について鋭意検討を行った。その結果、本件開示者は、以下で説明するように、Ｖ２Ｘ通信のような装置間通信において、効率的に、センシングを用いてリソースが選択できる技術を考案するに至った。

以上、本開示の実施の形態の概要について説明した。続いて、本開示の実施の形態における実施例について詳細に説明する。

［１．２．実施例］
まず、Ｖ２Ｘ通信のような装置間通信を行う端末装置が、リソースをセンシングしてからデータを送信するまでの概要を説明する。

図１１は、本開示の実施の形態に係る端末装置の動作例を示す流れ図である。図１１に示したのは、装置間通信を行う端末装置が、リソースをセンシングしてからデータを送信するまでの概要を示す流れ図である。以下、図１１を用いて本開示の実施の形態に係る端末装置の動作例について説明する。

端末装置は、トリガに応じて、以下のリソース選択、再選択の処理を走らせるかどうか判断する（ステップＳ１０１）。ここでのトリガは、例えば送信パケット発生時や、リソース衝突検出時など様々なものがありうる。詳細は後述する。

リソース選択、再選択の処理を走らせると判断した場合は（ステップＳ１０１、Ｙｅｓ）、続いて端末装置は、基地局が割り当てたリソース領域に対してセンシングを実行する（ステップＳ１０２）。センシング方法には、SA decodingとEnergy sensingとがある。端末装置は、これらのセンシング方法を用いて、無線通信環境を認識する。そして端末装置は、センシングの結果に基づいて、リソース領域の中から、データの送信に使用するリソースを選択する（ステップＳ１０３）。

データの送信に使用するリソースを選択すると、続いて端末装置は、選択したリソースを用いてデータ送信を実施する（ステップＳ１０４）。端末装置は、データ送信の実施に加えて、必要に応じて将来使用するためのリソース予約を実施しても良い（ステップＳ１０５）。データ送信の実施とリソース予約の実施の順番は逆でもよい。

なお、上述した一連のセンシングを用いた通信方法は、ＳＰＳを想定しているが、Dynamic schedulingに対して適応してもよい。

以上、端末装置による、リソースをセンシングしてからデータを送信するまでの概要について説明した。続いて、上述した各処理について、それぞれ詳細に説明する。

（１．トリガリング）
（１−１．リソースの再選択のトリガ）
まず、図１１のステップＳ１０１のトリガリングについて詳細に説明する。ＳＰＳの場合では、端末装置は、一度確保したリソースを使い続けるのが基本である。そのため、リソースを再選択（リセレクション）する際には何らかのトリガが必要になる。ここでは、トリガ条件について説明する。

（１）カウンタ
端末装置は、例えば、リソースの再選択のために設定されるカウンタ値が０になった場合をトリガ条件としてもよい。カウンタ値は、例えば乱数によって端末装置にセッティングされてもよい。乱数は基地局からSIBもしくはRRC signalingで通知されてもよく、端末装置に予め設定されても良い。基地局が乱数を通知する場合、基地局から乱数値そのものを通知してもよく、乱数のシードを通知しても良い。また、基地局が乱数を通知する場合、セル共通に乱数値や乱数のシードを通知してもよく、端末装置毎に値を決めて通知しても良い。

端末装置は、カウンタ値を、例えば、サブフレームやスロットの時間経過ごとに減算してもよく、センシングしたサブフレームやスロットごとに減算させてもよい。また端末装置は、カウンタ値を、送信するトラフィックの量ごとに減算させてもよい。この場合、端末装置は、優先度の高いトラフィックを持っている場合は減算量を増やしてもよい。トラフィック量を量子化するための閾値情報は、基地局からSIBもしくはRRC signalingにて通知されてもよい。閾値は端末装置ごとでもよく、セルごとでもよい。また閾値は、トラフィックタイプごとでもよい。また閾値は、端末装置に予め設定されてもよい。

また端末装置は、カウンタ値を、使用しているリソースサイズと、実際に通信要求を満たすために必要なリソースサイズとのギャップを用いて減算させてもよい。２つのリソースサイズ間のギャップは量子化されてもよく、端末装置は、その上で複数の段階にレベル分けして、そのレベルに応じてカウンタ値の減算を実施してもよい。量子化するための閾値情報は基地局からSIBもしくはRRC signalingにて通知されてもよい。閾値は端末装置ごとでもよく、セルごとでもよい。また閾値は、トラフィックタイプごとでもよい。また閾値は、端末装置に予め設定されてもよい。

また端末装置は、カウンタ値を、送信権利を獲得するごとに減算させてもよい。例えば、端末装置は、センシングを実施して送信権利を獲得した場合に、送信は行わずに減算だけを実施してもよい。送信権利獲得に用いる閾値情報は基地局からSIBもしくはRRC signalingにて通知されてもよい。閾値は端末装置ごとでもよく、セルごとでもよい。また閾値は、トラフィックタイプごとでもよい。また閾値は、端末装置に予め設定されてもよい。

また端末装置は、基地局、周辺端末またはＲＳＵからカウンタ値の減算量を直接通知された場合に、基地局、周辺端末またはＲＳＵから指示された量を減算してもよい。これは、カウンタ値を強制的に０に減算することも含まれる。基地局からは、カウンタ値の減算量を例えばRRC signalingにて通知されうる。周辺端末からは、カウンタ値の減算量をSCIもしくはPSSCHを用いて通知されうる。

また端末装置は、カウンタ値を、Sidelinkのトラフィック量に応じて減算してもよい。端末装置は、トラフィック量を、周辺端末からのデータ受信量を用いて把握してもよく、基地局からのトラフィック量通知に基づいて把握してもよい。トラフィック量の閾値情報は基地局からSIBもしくはRRC signalingにて通知されてもよい。閾値は端末装置ごとに設定されてもよく、セルごとに設定されてもよい。また閾値は、トラフィックタイプごとに設定されてもよい。また閾値は、端末装置に予め設定されてもよい。

（２）リソース割り当て状況が端末装置の要求を満たせない
端末装置は、リソース割り当て状況が端末装置の要求を満たせない場合をトリガ条件としてもよい。端末装置の要求としては、例えば、遅延要求、信頼性、フェアネス、ＱｏＳ等があり得る。

端末装置は、リソース割り当て状況として、使用しているリソースサイズと、実際に通信要求を満たすために必要なリソースサイズとのギャップを用いてもよい。２つのリソースサイズ間のギャップは量子化されてもよく、端末装置は、その上で複数の段階にレベル分けして、そのレベルに応じてリソース割り当て状況を判定してもよい。量子化するための閾値情報は基地局からSIBもしくはRRC signalingにて通知されてもよい。閾値は端末装置ごとでもよく、セルごとでもよい。また閾値は、トラフィックタイプごとでもよい。また閾値は、端末装置に予め設定されてもよい。

（３）端末装置が将来の送信におけるリソースのコリジョン（他ユーザとのリソースの重複）を発見した場合
端末装置は、将来の送信におけるリソースのコリジョン（他ユーザとのリソースの重複）を発見した場合をトリガ条件としてもよい。端末装置は、例えば、SA decodingを行い、リソース割り当て状況を把握し、自装置の送信との重複があるかどうかを発見してもよい。

この場合、例えば、端末装置は、コリジョンの発生回数が閾値以上であればリセレクションを実施してもよい。コリジョンの発生回数はTransport blockごとでもよく、Repetitionごとでもよい。閾値情報は基地局からSIBもしくはRRC signalingにて通知されてもよい。閾値は端末装置ごとでもよく、セルごとでもよい。また閾値は、トラフィックタイプごとでもよい。また閾値は、端末装置に予め設定されてもよい。

（４）基地局がリセレクションを通知する
端末装置は、基地局がリセレクションを通知した場合をトリガ条件としてもよい。

基地局は、例えば、トラフィックの混雑度（リソース使用率）に基づいてリセレクションが必要かどうか判断してもよい。この場合、基地局自身がSidelinkのリソースをモニタリングするか、Sidelinkのトラフィック情報を端末装置からレポートしてもらう。端末装置は、トラフィック情報のレポート方法を、基地局からSIBもしくはRRC signalingにて設定されてもよい。

基地局は、また例えば、特定の端末のリソースの使用状況（時間や送信回数や送信トラフィック量）に基づいてリセレクションが必要かどうか判断してもよい。この場合、端末装置は、定期的に基地局に対してリソースの使用状況をレポートしてもよい。端末装置は、リソースの使用状況のレポート方法を、基地局からSIBもしくはRRC signalingにて設定されてもよい。

（５）他の端末装置がリソースのリリースを通知
端末装置は、他の端末装置がリソースのリリースを通知した場合をトリガ条件としてもよい。この場合、端末装置は、他の端末装置からのリソースのリリース通知が閾値を超えた場合にリセレクションを実施しても良い。他の端末装置からのリソースのリリース通知は、例えばSCIにて送信される。閾値情報は基地局からSIBもしくはRRC signalingにて通知されてもよい。閾値は端末装置ごとでもよく、セルごとでもよい。また閾値は、トラフィックタイプごとでもよい。また閾値は、端末装置に予め設定されてもよい。

（６）他の端末装置からコリジョンレポートを通知
端末装置は、他の端末装置がコリジョンレポートを通知した場合をトリガ条件としてもよい。この場合、端末装置は、他の端末装置からのコリジョンレポート通知が閾値を超えた場合にリセレクションを実施しても良い。他の端末装置からのコリジョンレポート通知は、例えばSCIにて送信される。閾値情報は基地局からSIBもしくはRRC signalingにて通知されてもよい。閾値は端末装置ごとでもよく、セルごとでもよい。また閾値は、トラフィックタイプごとでもよい。また閾値は、端末装置に予め設定されてもよい。

（７）Sidelinkの混雑
端末装置は、Sidelinkが混雑した場合をトリガ条件としてもよい。この場合、端末装置は、Sidelinkの混雑度が所定の閾値を超えた場合にリセレクションを実施してもよい。なお、Sidelinkの混雑度は端末装置が測定してもよく、基地局が測定しても良い。閾値情報は基地局からSIBもしくはRRC signalingにて通知されてもよい。閾値は端末装置ごとでもよく、セルごとでもよい。また閾値は、トラフィックタイプごとでもよい。また閾値は、端末装置に予め設定されてもよい。

以上、（１）〜（７）の７つの例を挙げてトリガ条件を示した。端末装置は、これらのトリガ条件を、単独で用いてもよく、複数組み合わせて用いても良い。

上述のトリガ条件が満たされると、端末装置はリソースの再選択を実施する。リソース選択時においては、ＩＢＥの影響を最小化するため、端末装置は、位置情報を用いたリソース割り当てを実施してもよい。ＳＡの中に、データを送信する端末装置の位置情報もしくは位置のゾーン情報を含めることによって、端末装置は、近隣にいる端末装置の存在を検知し、近隣の端末装置と可能な限り同じSubframeを用いて信号を送信するようなオペレーションが可能になる。このように近隣の端末装置と可能な限り同じSubframeを用いて信号を送信することで、上述のＩＢＥ問題の改善に繋がる。

（１−２．リセレクションの大量発生による発散の防止）
上述したようなトリガ条件によって端末装置はリセレクションを実施することができる。しかし、あらゆる端末装置でリセレクションが大量に発生すると、端末装置が使用するリソースが頻繁に変わり、センシング自体の意味が無くなる。結果として通信システムが不安定になる。このような発散を防ぐ方法を説明する。

（１）システム側から発散を制御する
例えば、端末装置は、上述のリセレクションのトリガ条件を満たした後に、本当にリセレクションをやるかどうかを、確率αによって決定してもよい。確率αは基地局からSIBもしくはRRC signalingにて通知されてもよい。確率αは端末装置ごとでもよく、セルごとでもよい。また確率αは、トラフィックタイプごとでもよい。また確率αは、端末装置に予め設定されてもよい。

また例えば、端末装置は、上述のリセレクションのトリガ条件を満たした後に、リセレクション実施後に、新たに選択したリソースを用いるか、これまでのリソースを用いるかを、確率βによって決定してもよい。確率βは基地局からSIBもしくはRRC signalingにて通知されてもよい。確率βは端末装置ごとでもよく、セルごとでもよい。また確率βは、トラフィックタイプごとでもよい。また確率βは、端末装置に予め設定されてもよい。確率βは、確率αと同じでもよく、異なっても良い。

また例えば、端末装置は、上述のリセレクションのトリガ条件に用いる閾値を一律に増加してもよい。閾値修正のためのシグナリングは、基地局からSIBもしくはRRC signalingにて通知される。端末装置は、事前に増加量または増加率を基地局から通知されてもよく、予め設定されていてもよい。そして、端末装置は、閾値の増加のアクティベーション及び解除を基地局から指示されてもよい。

（２）リセレクションがシステム内でどの程度発生しているかを基地局が把握する
例えば、端末装置は、リセレクションを実施した後に、リセレクションを実施した旨を基地局にレポートしても良い。端末装置は、レポート方法を、基地局からSIBもしくはRRC signalingにて設定されても良い。

この場合、全ての端末装置がリセレクションの度に基地局にレポートを行うとオーバーヘッドが増加しうる。従って、端末装置は、リセレクションを実施した後に、リセレクションを実施した旨を、確率γで基地局にレポートしても良い。確率γは基地局からSIBまたはRRC signalingにて通知されてもよい。確率γは端末装置ごとでもよく、セルごとでもよい。また確率γは、トラフィックタイプごとでもよい。また確率γは、端末装置に予め設定されてもよい。確率γは、確率α及び／またはβと同じでもよく、異なっても良い。

（２．センシング、データ送信、リソース予約）
（２−１．センシング領域の制限）
端末装置の消費電力を低減させるためには、リソース領域をセンシングするセンシング領域を制限することが望ましい。以下では、端末装置に対して、センシング領域をどう規定するか、センシング領域に対するセンシングからデータ送信、リソース予約をどう規定するか、を説明する。

図１２は、端末装置における、送信データの発生からデータ送信予約までを説明する説明図である。リソース領域３００は、ＳＡリソース３０１とデータリソース３０２とを含む。

あるタイミングで端末装置に送信データが発生すると、端末装置は、時刻ｎ−ａ〜ｎ−ｂの区間からなるセンシング領域３１１においてセンシングを行う。端末装置は、センシングとしてＳＡセンシング及び／またはエナジーセンシングを用いうる。端末装置は、センシング領域３１１においてセンシングを行うと、時刻ｎにおいてリソースの選択を行う。端末装置は、ＳＡリソース３０１とデータリソース３０２の両方についてリソースの選択を行う。

時刻ｎにおいてリソースの選択を行うと、続いて端末装置は、時刻ｎ＋ｃにおいて、ＳＡリソース３０１のリソース３２１を用いてＳＡの送信を行い、時刻ｎ＋ｄにおいて、データリソース３０２のリソース３２２を用いてデータの送信を行う。さらに端末装置は、将来の（時刻ｎ＋ｅでの）データ送信のためにデータリソース３０２のリソース３２３を予約する。

なお、図１２に示したａからｅの各パラメータは正の値である。図１２に示したａからｅの各パラメータは、ＳＰＳ毎に設定されてもよい。また、図１２に示したａ、ｂの各パラメータは、ＳＰＳ間で共通に設定されても良い。

図１２に示した一連の処理を端末装置が実施するためには、ａからｅの各パラメータの端末装置への設定が必要になる。

（１）パラメータａ、ｂ
パラメータａ、ｂは、端末装置のセンシングの精度に大きく影響する一方、センシング期間が長いと遅延要求が満たせないため、適切に設定されることが望ましい。

本実施形態では、複数の（ａ、ｂ）の組の設定を用意して、基地局から端末装置に値を設定する。例えば、Configuration 1（a1,b1）、Configuration 2（a2,b2）、…のような設定である。複数の設定は端末装置に予め設定されても良い。

それぞれのConfigurationは、トラフィックタイプごとに設定されてもよく、トラフィックの優先度ごとに設定されてもよい。またそれぞれのConfigurationは、端末装置の移動速度に応じて設定されてもよく、端末装置のタイプ（歩行者が使用するPedestrian UE、車両に搭載されるVehicle UE等）、端末装置の位置情報（端末装置が使用しているリソースプール）などによって設定されてもよい。またそれぞれのConfigurationは、Sidelinkのリソースの使用状況、例えば、Sidelinkのリソースの使用率に応じて設定されてもよい。それぞれのConfigurationは、端末装置間で共通でもよく、端末装置ごとに設定されてもよい。またそれぞれのConfigurationは、端末装置間で共通でもよく、端末装置ごとに設定されてもよい。

例えば、Event trigger messageのようなレイテンシ要求があるようなメッセージの場合、端末装置に、センシング領域３１１のセンシングウィンドウが小さくなるようなConfigurationが割り当てられることによって、端末装置のセンシング時間を短縮し、送信までの遅延を小さくすることができる。

また例えば、移動速度が速い端末装置は、無線通信環境の変化が高速に変化するため、センシング時間を長くとって測定を行っても、実際に送信を行うときの無線通信環境を正しく予測できない場合が出てくる。従って、移動速度が速い端末装置に対しては、センシング領域３１１のセンシングウィンドウが小さくなるようなConfigurationが割り当てられてもよい。

また、端末装置ごとにConfigurationを割り当てる場合も同様に、例えばPedestrian UEのような消費電力を小さく抑えたい要求がある端末装置については、センシング領域３１１のセンシングウィンドウを小さくするように設定されることが望ましい。一方で、Ｖ２Ｖ通信を行うような、バッテリに余裕があるような端末装置については、センシング領域３１１のセンシングウィンドウを大きくするように設定されてもよい。

なお、基地局からConfigurationが設定される場合、端末装置は、Configurationを、基地局からSIBもしくはRRC signalingにて設定されても良い。また、端末装置に予めConfigurationが設定されてもよい。

ＳＰＳおいて、SA decodingを用いた将来のリソース使用状況の予測は有効である。その一方、送信端末が、他端末のＳＡの送信直後にセンシングを開始した場合など、ＳＡのデコードが行えない場合がある。また、ＳＡのデコードに失敗する場合もあり得る。このような場合に端末装置は将来のリソース使用状況を予測することが困難になる。

端末装置は、センシングの恩恵を最大限受けるために、センシング結果から、いかに将来のリソースの使用状況を予測するかが重要である。そのため、センシング領域とデータ送信領域のリソース使用状況の相関が高いような環境が実現できれば、端末装置は、センシング領域の状況から将来のリソース使用状況を高い精度で予測することが可能となる。

そこで本実施形態では、リソースプールにScheduling periodを導入する。図１３は、Scheduling
periodの例を示す説明図である。Scheduling periodは、リソースプール毎に設けられる。

そして、本実施形態では、このScheduling period単位でグルーピングを実施する。このグルーピングはリソースプール毎に設定される。それぞれのグループは、地理情報に応じて設定されてもよい。図１４は、グルーピングされたScheduling periodの例を示す説明図である。図１４には、１つおきにグルーピングされたScheduling periodの例が示されている。もちろん、Scheduling
periodのグルーピングのパターンは図１４に示したものに限定されるものではない。

端末装置は、複数のScheduling periodのグループから１つのグループを選択し、送信を行うようにする。この際、各Scheduling period間でリソース使用の相関が高くなるように運用することが望ましい。

各Scheduling periodのグループ内のScheduling periodにおいて、ナンバリングがなされてもよい。そして端末装置は、このScheduling periodのナンバーに応じてリソースホッピングなどを実施してもよい。図１５は、端末装置がScheduling periodのナンバーに応じてリソースホッピングを行う例を示す説明図である。もちろん、ホッピングのパターンは図１５に示したものに限定されるものではない。

基地局からリソースホッピングに関するパラメータが設定される場合、端末装置は、パラメータを、基地局からSIBもしくはRRC signalingにて設定されても良い。また、端末装置に予めパラメータが設定されてもよい。

また、Scheduling period、Scheduling periodのグループ、Scheduling periodのナンバーの情報は、基地局からSIBもしくはRRC signalingにて設定されても良い。また、図１２に示したパラメータａ〜ｅは、Scheduling periodの間隔から算出されてもよい。

（２）パラメータｃ、ｄ
パラメータｃ、ｄは、送信遅延に影響を与えるパラメータである。パラメータｃは、トラフィックタイプごとに設定されてもよく、トラフィックの優先度ごとに設定されてもよい。またパラメータｃは、端末装置の移動速度に応じて設定されてもよく、端末装置のタイプ（Pedestrian UE、Vehicle UEなど）、端末装置の位置情報などによって設定されてもよい。またパラメータｃは、端末装置間で共通であってもよく、端末装置ごとに設定されてもよい。

パラメータｄは端末装置間で異なる値が設定されてもよく、また、端末装置間で共通でもよい。また、パラメータｄはパラメータｃと同じ値でもよい。

パラメータｃ、ｄは、基地局から設定する場合、基地局からSIBもしくはRRC signalingにて端末装置に設定される。またパラメータｃ、ｄは、事前に端末装置に設定されてもよい。

（３）パラメータｅ
端末装置は、センシング結果を基に送信用のデータを決定するだけでなく、将来使用するリソースの確保も行うことができる。リソースの確保も行う場合、リソース予約情報（すなわち、パラメータｅに関する情報）を周辺の端末装置に通知する方法が必要となる。

例えば、端末装置は、SCIを用いてリソース予約情報を周辺の端末装置に通知してもよい。具体的には、端末装置は、SCIにパラメータｅの情報を含めて、周辺の端末装置に通知してもよい。端末装置は、パラメータｅの情報を含める際に、周波数方向を含めてもよい。また、端末装置は、パラメータｅによりリソースの予約の回数をSCIに含めてもよい。また、端末装置は、予約したリソースの場所をビットマップで指示してもよい。また、端末装置は、周波数ホッピングパターンの情報をSCIに含めてもよい。また、使用するホッピングパターンは基地局からDCI、SIBまたはRRC signalingにて設定される。また、使用するホッピングパターンは、端末装置に事前に設定されてもよい。

また例えば、端末装置は、ＳＡリソース及びデータリソースの割り当て方法からパラメータｅを導出して、周辺の端末装置に通知しても良い。例えば、端末装置は、ＳＡリソースまたはデータリソースの繰り返しの時間間隔または周波数間隔を用いてパラメータｅを導出し、パラメータｅを通知してもよい。

また端末装置は、ＳＡリソースとデータリソースとの時間オフセットまたは周波数オフセットを用いてパラメータｅを導出し、パラメータｅを通知してもよい。

また周辺の端末装置は、ＳＡリソースまたはデータリソースが割り当てられた場所から、リソースの予約場所を推定してもよい。例えば、事前に決められた時間領域または周波数領域にＳＡリソースまたはデータリソースが割り当てられた場合、周辺の端末装置は、リソース予約が実施されたと判断してもよい。この事前に決められた時間領域または、周波数領域は、基地局から通知されてもよい。

また端末装置は、ＳＡリソースまたはデータリソースの繰り返しのマッピング情報（Ｄ２Ｄで規定されているTime resource pattern）のインジケータを用いて、リソース予約の情報を通知してもよい。周辺の端末装置は、Time resource patternの情報が規定された閾値を超えていた場合、他の端末装置でリソースの予約が実施されていると判断してもよい。この閾値は複数でもよく、基地局からSIBまたはRRC signalingにて通知されてもよく、端末装置に予め設定されてもよい。

端末装置は、センシング後にリソース選択を行うが、リソースの選択時において、トラフィックの混雑等からリソースを確保できない場合がある。この場合、端末装置によるリソース選択が先延ばしされ、過去に行ったセンシング結果と選択するリソースとの間の相関が低くなる恐れがある。

そこで端末装置は、リソースの選択時にリソースを確保できなかった場合は、リソースが選択できるまで、センシング期間を延長してもよい。つまり、リソース選択タイミングがｎからｎ１となり、センシングウィンドウはｎ−ａ〜ｎ１−ｂまでの期間となる。

しかし、センシングを長く続けると、過去の古いセンシング情報がリソース選択に悪影響を与える可能性がある。従って端末装置は、例えばｎ１−ｎの値がある閾値以上になった場合は、リソース選択を諦めてリソースのリセレクションフェーズへ移行してもよい。この際の閾値情報は基地局からSIBもしくはRRC signalingにて端末装置に通知されてもよい。閾値は端末装置ごとでもよく、セルごとでもよく、またトラフィックタイプごとでもよい。また閾値は端末装置に予め設定されてもよい。

また端末装置は、リソースの選択時にリソースを確保できなかった場合は、リソースが選択できるまで、センシングウィンドウをスライドしてもよい。つまり、リソースタイミングがｎからｎ１となり、センシングウィンドウはｎ１−ａ〜ｎ１−ｂまでの期間となる。

ＳＰＳが複数設定された場合、センシング区間をどう保つか、またセンシングをどう効率的に行うか、が重要となる。

複数のＳＰＳが用いられる場合、ＳＰＳごとにパラメータａ〜ｅが規定されるようにする。センシング領域を規定するパラメータａ、ｂについては、共通センシング領域を規定するパラメータａ＿ｃｏｍ、ｂ＿ｃｏｍを設定する。

図１６は、共通センシング領域について説明する説明図である。図１６には２つのＳＰＳ（ＳＰＳ１、ＳＰＳ２）が示されている。ＳＰＳ１に対しては、センシング領域を規定するパラメータとしてパラメータａ＿ｓｐｓ１、ｂ＿ｓｐｓ１が用いられるが、ＳＰＳ２に対しては、共通センシング領域を規定するパラメータａ＿ｃｏｍ、ｂ＿ｃｏｍが割り当てられる。

なお、それぞれのＳＰＳについて、共通センシング領域を用いるか、各ＳＰＳに独自に規定されたセンシング領域を用いるかは、基地局からSIBもしくはRRC signalingにて端末装置に通知されてもよい。この情報は端末装置ごとでもよく、セルごとでもよく、またトラフィックタイプごとでもよい。またこの情報は端末装置に予め設定されてもよい。

また、センシング領域に送信パケットが発生し、端末装置がセンシングを行えない場合も考えられる。その場合、端末装置は、センシングが実施できない時間分、センシング領域を延長してもよい。すなわちパラメータａ、ｂを用いれば、端末装置は、ｂ−ａ＋ｚ（ｚは延長分）だけセンシング領域を延長してもよい。そして、延長したセンシング領域がある閾値以上になった場合、例えば、ｂ−ａ＋ｚが閾値ＴＨ１を超えた場合、または、ｚが閾値ＴＨ２を超えた場合、端末装置は、センシングをやり直してもよい。この閾値は、基地局からSIBもしくはRRC signalingにて端末装置に通知されてもよい。この閾値は、端末装置ごとでもよく、セルごとでもよく、またトラフィックタイプごとでもよい。またこの閾値は、端末装置に予め設定されてもよい。

Ｖ２Ｘ通信では、様々な優先度を持ったメッセージが送信される。従って、端末装置は、優先度情報をリソース選択にどのように反映するか、また、優先度情報をどのように入手するか、が重要である。

例えば端末装置は、ＳＡの中にパケットの優先度情報を入れても良い。他の端末装置は、SA decodingにおいて、各パケットの優先度情報と、そのパケットが使用するリソースとを特定することができる。他に、端末装置は、優先度情報を判別する手法として、例えば、ＳＡの繰り返し回数で判別してもよく、繰り返し時のリソース割り当て位置で判別してもよく、ＳＡの割り当てそのもので判別してもよい。もちろん端末装置は、ＳＡの代わりにデータのリソース割り当て位置によっても優先度情報を判別してもよい。

また例えば端末装置は、ＳＡの中にパケットの優先度情報を入れ、にパケットの優先度情報をリソース選択に用いてもよい。他の端末装置は、SA decodingにおいて、各パケットの優先度情報と、そのパケットが使用するリソースとを特定することができる。同様に、他の端末装置は、Energy detectionを行い、比較的電力の低いリソースを特定することができる。受信したパケットの優先度情報、Energy detectionの結果及び送信端末が送信するパケットの優先度情報を用いることによって、端末装置は、たとえSA decodingでリソースが占有されていると分かった場合においても、高い優先度のパケットを持っていれば、比較的電力が低く、送信されているパケットの優先度が低いリソースを選択することが可能になる。

また例えば端末装置は、ＳＡの中に送信元の情報を入れてもよい。送信元の情報は、送信元の属性（車両、歩行者など）でもよく、ＩＤのような一意に識別できる情報などでもよい。他の端末装置は、SA decodingにおいて、各パケットの送信元の情報と、そのパケットが使用するリソースとを特定することができる。

Pedestrian UEの場合、消費電力をなるべく抑えて送信を行う要求があるため、パケットの送信回数が車両よりも少ないことが予想される。そのため、端末装置がセンシングを行い、リソース選択を行う際は、このようなPedestrian UEは優先的に守られる必要がある。そこで端末装置は、センシングを実施し、送信者の特性が判断できれば、その送信者の使用しているリソースに影響が出ないようにリソース選択が行えるようになる。

一方で、ロバストと思われる端末、例えば車のような端末に対しては、多少干渉を与えても問題ないと判断することもできる。従って端末装置は、センシングを行い、車のような端末がリソースを使用していると分かっていても、干渉を小さくするように送信電力などを調整し、送信してもよい。

また例えば端末装置は、ＳＡの中に送信電力情報を入れてもよい。送信電力情報には、送信電力値、基地局から通知されたTPC command情報などが含まれうる。他の端末装置は、取得した送信電力情報と受信電力情報とからパスロスを計算し、同じリソースを使用しても良いかどうか判断しても良い。例えば、送信電力情報に比べて受信電力情報が極めて小さければ、その電波を送信した端末装置は遠方にあることが想定されるので、端末装置は、同じリソースを使用して良いと判断できる。端末装置は、パスロスの計算にエナジーセンシングを用いても良い。また端末装置は、受信電力の絶対値から、同じリソースを使用するかどうかの判断を行っても良い。また端末装置は、パケットの優先度情報とあわせて同じリソースを使ってよいかの判断を行ってもよく、最大送信電力の調整を行ってもよい。

端末装置は、センシングを実施した時点で、送信電力と受信電力の情報を用いてパスロスを計算することができる。このパスロスから送信元の端末がどの程度離れたエリアにいるかが予測できる。この時、センシングを実施する端末装置が、比較的低い消費電力で送信するようなパケットを持っていた場合（例えば定期的なメッセージであり、かつ渋滞が発生していて送信電力が小さくてもよい場合など）、当該端末装置は、送信元の端末装置との距離を考慮して、同じリソースで送信してもよいかどうかの判断を行うことが出来る。

また端末装置は、パケットの優先度ごとに同じリソースでの送信判断を行ってもよい。例えば端末装置は、SA decodingの結果、リソースが占有されていると分かった場合においてもパスロス計算を行い、本当に送信できないかどうかの判断を行ってもよい。端末装置は、送信パケットの優先度が高い場合は、このようなセンシングを実施することで、占有されているリソースにおいても、さらに使える可能性のあるリソースを選択し、どうしても送信しなければならないような優先度の高いパケットの送信を実施することが可能となる。

（３．リソース選択）
端末装置は、リソース領域のセンシング結果を基にリソースの選択を実施する。もし使用可能なリソースがない場合、端末装置は、使用可能なリソースが見つかるまで送信ができない。このような場合、長時間メッセージの送信ができない端末装置が出てくる可能性がある。従って、端末装置間のフェアネスを保つようなリソース選択方法を用意することが望ましい。すなわち、センシングを行い、リソース選択フェーズでリソースの選択が行えなかった端末装置に対して、どのように優先してリソース選択できるようにするかが重要である。

そこで本実施形態では、センシングを行い、リソース選択フェーズでリソースの選択が行えなかった端末装置は、強制的にリセレクションフェーズに移行させる。例えば、リソースの再選択のトリガとしてカウンタ値が０になったことを設定した場合、端末装置は、リソース選択フェーズでリソースの選択が行えなかった場合、カウンタ値を強制的に０にしてリセレクションフェーズに移行する。端末装置は、この際、強制的にリセレクションフェーズに移行した回数を記録するカウンタ（強制リセレクションカウンタ）の値を増加させる。もちろん、リソースの再選択のトリガは他のものが用いられても良い。

そして強制的にリセレクションフェーズに移行した端末装置は、次回カウンタの値を所定量（ｘ）だけ増減させてもよい。増加させると、次回リソースを長期間使えるようになる。このｘの値は、基地局からSIBもしくはRRC signalingにて端末装置に通知されてもよい。このｘの値は、端末装置ごとでもよく、セルごとでもよく、またトラフィックタイプごとでもよい。またこのｘの値は、端末装置に予め設定されてもよい。

次回カウンタの増減量は、強制リセレクションカウンタによって調整されても良い。例えば、ｘに強制リセレクションカウンタを掛けたものを次回カウンタの増減量としてもよく、ｘに強制リセレクションカウンタを乗じたものを次回カウンタの増減量としてもよい。

また、強制的にリセレクションフェーズに移行した端末装置は、次回のセンシング期間を短くしても良い。例えば、センシング期間を規定するパラメータａの値を所定量（ｙ）だけ減算させてもよい。このｙの値は、基地局からSIBもしくはRRC signalingにて端末装置に通知されてもよい。このｙの値は、端末装置ごとでもよく、セルごとでもよく、またトラフィックタイプごとでもよい。またこのｙの値は、端末装置に予め設定されてもよい。

端末装置は、強制リセレクションカウンタの値が所定の閾値以上になると、基地局にその旨をレポートしても良い。基地局は、強制リセレクションカウンタの値が所定の閾値以上になった端末装置に対して、優先的にリソースを割り当てる。この閾値は、基地局からSIBもしくはRRC signalingにて端末装置に通知されてもよい。この閾値は、端末装置ごとでもよく、セルごとでもよく、またトラフィックタイプごとでもよい。またこの閾値は、端末装置に予め設定されてもよい。

例えば基地局は、強制リセレクションカウンタの値が所定の閾値以上になった端末装置に対して、新しいリソースプールを提供してもよく、他の端末装置に対して送信を控えるよう指示してもよい。

端末装置は、ＳＡから得られた情報より、他端末で占有されていないリソースを送信可能リソースとして判断してもよく、エナジーセンシングを用いて、規定の閾値以下であれば送信可能リソースとして判断してもよい。端末装置は、ＳＡから得られた情報より、他端末で占有されていないリソースが無ければ、エナジーセンシングを用いて、規定の閾値以下であれば送信可能リソースとして判断してもよい。

この際、端末装置は、優先度情報ごとに設定した閾値を用いてリソースを選択しても良い。優先度情報としては、例えば送信パケットタイプ、端末装置の種別（Pedestrian、Vehicleなど）、送信パケットサイズ、強制リセレクションカウンタ（バックオフタイマ）等があり得る。優先度情報ごとの閾値は、基地局からSIBもしくはRRC signalingにて端末装置に通知されてもよい。この閾値は、端末装置ごとでもよく、セルごとでもよく、またトラフィックタイプごとでもよい。またこの閾値は、端末装置に予め設定されてもよい。

またこの際、端末装置は、送信電力に応じてリソースを選択してもよい。例えば、送信電力が低い端末装置は、ある程度電力を検出したリソースを使用可能とし、送信電力の高い端末装置は、小さい電力を検出したリソースを選択してもよい。送信電力と閾値情報との紐付けは、基地局からSIBもしくはRRC signalingにて端末装置に通知されてもよい。この紐付けは、端末装置ごとでもよく、セルごとでもよく、またトラフィックタイプごとでもよい。またこの紐付けは、端末装置に予め設定されてもよい。また端末装置は、送信電力の代わりに基地局から通知されたTPC command情報を用いてもよい。

また端末装置は、自装置の送信電力に応じてリソースを使用するかどうか判断しても良い。例えば、端末装置は、リソースを使用するかどうかの判断を、検出した電力と、自装置の送信電力との差が閾値を超えていればであれば、リソースを使用すると判断しても良い。この閾値は、基地局からSIBもしくはRRC signalingにて端末装置に通知されてもよい。この閾値は、端末装置ごとでもよく、セルごとでもよく、またトラフィックタイプごとでもよい。またこの閾値は、端末装置に予め設定されてもよい。

（Ｖ２Ｐ通信における消費電力の改善）
次に、Ｖ２Ｐ通信における消費電力の改善に関して説明する。Ｖ２Ｐ通信における要求事項には、例えば以下のような要求がある。
・遅延要求：サーバーから端末まで500ms以内。V2PのEnd-to-endで100ms以内
・オペレーション要求：Multi MNO(Mobile Network Operator)対応
・消費電力要求：バッテリー消費を最小化
・カバレッジ要求：４秒程度耐えうる範囲をカバー。時速100km/hであればおおよそ27.7*4=110.8m
・メッセージ要求：サイズは典型的に50〜300バイト、最大で1200バイト
・通信品質要求：オートバイ〜車で最大280km/h、歩行者〜車で最大160km/hの環境で通信を確立

Pedestrian UE（歩行者端末）のシナリオではスマートフォンのようなデバイスを用いた通信が想定されるため、バッテリーが豊富にある車とは違い、V2P通信による消費電力の増加が大きな問題となる。V2P通信実現のためには、低消費電力での通信が必要不可欠になる。以降、V2P通信における消費電力関連の課題及び解決方法について述べる。

（１）Pedestrian UEの動作
歩行者端末と車端末とは、同じリソースプールをシェアし、さらに歩行者端末は自律的にリソースを選択する場合に、リソースの衝突（リソースコリジョン）が起こり、車端末のPPR(Packet Reception Ratio)を劣化させる可能性がある。車端末でのセンシングのように、センシングを行えばリソースの衝突の問題が改善できる。しかしながら一方で、歩行者端末は、リソースをセンシングすると消費電力が増えてしまう。そこで、センシングが必要な場合のみセンシング機能をActivationする方法が望まれる。例えば、UE端末位置やネットワークの混雑度状況に応じて、センシング機能をActivationするなどの方法がある。

歩行者端末と車端末とで異なるリソースプールを使うことで、歩行者端末と車端末との間のリソース衝突はなくなる。その場合、歩行者端末はセンシングせずに、ランダムにリソースの選択（ランダムセレクション）を行うことが可能になる。

全体フローの流れは、測定→判断→制御である。それぞれの実施主体はネットワーク側または端末側である。その制御には自律制御と中央制御がある。自律制御の場合は、位置情報をベースにしたセンシング機能のActivationと、信号検出（シグナリング）によるセンシング機能のActivationとが考えられる。また中央制御の場合は、Network、eNB、RSU、第三者端末からの指示によるセンシング機能のActivationが考えられる。

自律制御か中央制御かの違いは、判断する主体がUE側にあるかNetwork側にあるかの違いだけである。そのため、位置情報ベースのActivation、信号検出によるActivationのそれぞれにおいて、UE側での判断、Network側での判断の２つを説明する。なお、Network側とは、本実施形態ではeNBやRSUのような集中制御局を示す。

（１−１）位置情報ベースのActivation
歩行者自身の近傍に車端末がいない場合に、P2V通信は必要ない。自動車は道路を走るため、歩行者端末は道路の近傍にいるかどうかを判断する。歩行者端末は、道路近傍にいる場合のみ、センシング機能をActiveさせる。位置の測定、道路近傍にいるかどうかの判断、センシング機能の制御は、歩行者UE側、ネットワーク側どちらで行われてもよい。判断の結果によってはActivationを行わない場合、歩行者UEはリソースプールの中のキャンディデイトリソースをランダム的に選択できる。また実施場所が異なる場合は、必要に応じてシグナリングが必要になる。

端末側でのポジショニング測定方法には、GNSS、A-GNSSなどがある。Network側でのポジショニング測定方法には、OTDOA(Observed Time Difference of Arrival)、UTDOA(Uplink Time Difference of Arrival)、D2D aided positioning、E-CID(Enhanced Cell Identification)、TBS(Terrestrial beacon systems)、Wi-Fi（登録商標）やBluetooth（登録商標）をベースにした測定などがある。

判断処理の例を示す。予めマップ情報を入手しておき、歩行者UE自身の位置情報とマップ情報を比較する。そして、その歩行者UEが道路近傍にいると判断された場合に、センシングがActivateされる。また３次元の情報に基づいてActivateの有無を判断してもよい。すなわち、判断の際に高さ方向が考慮されてもよい。例えば、横断歩道橋にいる歩行者UEはセンシングを行わないようにしてもよい。また、一定の時間以内に道路に近づいていると判断された場合、センシングがActivateされると判断されても良い。

制御処理の例を示す。制御処理では、歩行者UEのセンシング機能のActivationを行う。センシングに必要なパラメータが、ネットワーク側から歩行者UE側に提供されてもよく、ネットワークは歩行者UEに対してセンシング用の必要なパラメータをconfigure（preconfigure）してもよい。なお、歩行者UEのセンシング機能のActivationを行わない場合には、explicitlyあるいはimplicitly通知が行われる。

時間軸の情報としては、例えば、センシングの周期、センシングの持続時間、センシングのスタート起点がある。周波数軸の情報としては、例えば、センシングする帯域がある。センシング方法としては、例えば、SA decoding、Energy sensing、SA decodingとenergy sensingとの組み合わせ、などがある。

一連の処理の流れについて図面を参照しながら説明する。図２３は、本開示の実施の形態に係るNetwork側及び歩行者UE側の処理の例を示す説明図である。図２３には、測定、判断、制御の全てを歩行者UE側で行う例が示されている。すなわち、歩行者UEは、位置の測定処理を行い（ステップＳ２０１）、測定結果に基づいてセンシング機能をActiveさせるかどうかの判断処理を行い（ステップＳ２０２）、判断処理に基づいた制御を実行する（ステップＳ２０３）。この場合、シグナリングは不要となる。また、歩行者UEはOOC(Out-Of-Coverage)の場合にこの流れに従う。またこの場合、センシングに関わる情報を歩行者UEにconfigure（preconfigure）する。

図２４は、本開示の実施の形態に係るNetwork側及び歩行者UE側の処理の例を示す説明図である。図２４には、測定、判断を歩行者UE側で行い、制御をNetwork側で行う例が示されている。すなわち、歩行者UEは、位置の測定処理を行い（ステップＳ２１１）、測定結果に基づいてセンシング機能をActiveさせるかどうかの判断処理を行い（ステップＳ２１２）、判断結果をNetwork側に通知する（ステップＳ２１３）。Network側は、判断結果に基づいた制御を実行し（ステップＳ２１４）、センシング機能のActivation通知及びセンシングに関わる情報の通知を行う（ステップＳ２１５）。センシングに関わる情報が歩行者UEにconfigure（preconfigure）されている場合は、歩行者UEは判断結果をNetwork側に通知する必要は無い。また、このケースの場合、Activationを行わない場合はシグナリングが不要となり、歩行者UEはランダムセレクションを行う。

図２５は、本開示の実施の形態に係るNetwork側及び歩行者UE側の処理の例を示す説明図である。図２５には、測定、制御を歩行者UE側で行い、判断をNetwork側で行う例が示されている。すなわち、歩行者UEは、位置の測定処理を行い（ステップＳ２２１）、測定結果をNetwork側に通知する（ステップＳ２２２）。Network側は、測定結果に基づいたセンシング機能をActiveさせるかどうかの判断処理を行い（ステップＳ２２３）、歩行者UEへセンシング機能のActivation通知を行う（ステップＳ２２４）。歩行者UEは、通知に基づいた制御を実行する（ステップＳ２２５）。このケースの場合、センシングに関わる情報を歩行者UEにconfigure（preconfigure）する。

図２６は、本開示の実施の形態に係るNetwork側及び歩行者UE側の処理の例を示す説明図である。図２６には、測定を歩行者UE側で行い、判断、制御をNetwork側で行う例が示されている。すなわち、歩行者UEは、位置の測定処理を行い（ステップＳ２３１）、測定結果をNetwork側に通知する（ステップＳ２３２）。Network側は、測定結果に基づいたセンシング機能をActiveさせるかどうかの判断処理を行い（ステップＳ２３３）、判断処理に基づいた制御を実行する（ステップＳ２３４）。そしてNetwork側は、センシング機能のActivation通知及びセンシングに関わる情報の通知を行う（ステップＳ２３５）。このケースの場合、センシングに関わる情報を歩行者UEにconfigure（preconfigure）する。

図２７は、本開示の実施の形態に係るNetwork側及び歩行者UE側の処理の例を示す説明図である。図２７には、測定をNetwork側で行い、判断、制御を歩行者UE側で行う例が示されている。すなわち、Network側は、位置の測定処理を行い（ステップＳ２４１）、測定結果を歩行者UEに通知する（ステップＳ２４２）。歩行者UEは、取得した測定結果に基づいてセンシング機能をActiveさせるかどうかの判断処理を行い（ステップＳ２４３）、判断処理に基づいた制御を実行する（ステップＳ２４４）。このケースの場合、センシングに関わる情報を歩行者UEにconfigure（preconfigure）する。

図２８は、本開示の実施の形態に係るNetwork側及び歩行者UE側の処理の例を示す説明図である。図２８には、測定、制御をNetwork側で行い、判断を歩行者UE側で行う例が示されている。すなわち、Network側は、位置の測定処理を行い（ステップＳ２５１）、測定結果を歩行者UEに通知する（ステップＳ２５２）。歩行者UEは、取得した測定結果に基づいてセンシング機能をActiveさせるかどうかの判断処理を行い（ステップＳ２５３）、判断結果をNetwork側に通知する（ステップＳ２５４）。Network側は、判断結果に基づいた制御を実行し（ステップＳ２５５）、センシング機能のActivation通知及びセンシングに関わる情報の通知を行う（ステップＳ２５６）。センシングに関わる情報が歩行者UEにconfigure（preconfigure）されている場合は、歩行者UEは判断結果をNetwork側に通知する必要は無い。また、このケースの場合、Activationを行わない場合はシグナリングが不要となり、歩行者UEはランダムセレクションを行う。

図２９は、本開示の実施の形態に係るNetwork側及び歩行者UE側の処理の例を示す説明図である。図２９には、測定、判断をNetwork側で行い、制御を歩行者UE側で行う例が示されている。すなわち、Network側は、位置の測定処理を行い（ステップＳ２６１）、測定結果に基づいてセンシング機能をActiveさせるかどうかの判断処理を行い（ステップＳ２６２）、判断結果を歩行者UEに通知する（ステップＳ２６３）。歩行者UEは、判断処理に基づいた制御を実行する（ステップＳ２６４）。このケースの場合、センシングに関わる情報を歩行者UEにconfigure（preconfigure）する。

図３０は、本開示の実施の形態に係るNetwork側及び歩行者UE側の処理の例を示す説明図である。図３０には、測定、判断、制御の全てをNetwork側で行う例が示されている。すなわち、Network側は、位置の測定処理を行い（ステップＳ２７１）、測定結果に基づいてセンシング機能をActiveさせるかどうかの判断処理を行い（ステップＳ２７２）、判断処理に基づいた制御を実行する（ステップＳ２７３）。そしてNetwork側は、センシング機能のActivation通知及びセンシングに関わる情報の通知を行う（ステップＳ２７４）。センシングに関わる情報が歩行者UEにconfigure（preconfigure）されている場合は、歩行者UEは判断結果をNetwork側に通知する必要は無い。また、このケースの場合、Activationを行わない場合はシグナリングが不要となり、歩行者UEはランダムセレクションを行う。

（１−２）信号検出によるActivation
次に信号検出によるActivationの例を説明する。この例では、歩行者UEは、自動車からの信号検出をトリガしてセンシング機能をActiveする。eNB、またはeNBタイプのRSUが信号を送出する。

（測定）
測定対象は、例えば、V2P通信帯域の電力、自動車からのsidelink synchronization signal/sidelink broadcast signal、eNB/RSUからのDCI、ネットワークのChannel level（歩行者UEが測定してもよく、eNBまたはRSUが通知してもよい）、自動車またはeNB/RSUからの車のパケットの一般情報（送信時間や送信帯域）である。

測定方法は、モニタリングに必要なパラメータを用いた測定により行う。モニタリングに必要なパラメータは、例えば、eNB、RSU、またはconfigurationされた(pre-configurationされた)パラメータから入手する。eNB、RSU、またはconfigurationされたパラメータは、帯域情報、同期情報、Measurement gapを提供する。歩行者UEは、測定対象に応じて下記より帯域情報（モニタリングを行う帯域情報）、同期情報（モニタリングする帯域における同期情報。フレームタイミング、中心周波数情報など）、Measurement gap情報（測定周期、測定期間など）の１つ以上を入手する。

歩行者UEは、Measurement gapに従って測定を行う。例えば、eNB、RSU、またはconfigurationされた(pre-configurationされた)パラメータが提供される。歩行者UEの情報に基づいてgapが設定される。歩行者UEの情報としては、例えば端末の位置情報、RF数、バッテリ残量等がある。その他、歩行者UEは、ネットワークの混雑度に応じて測定を行っても良い。

（判断）
歩行者UEは、特定のメッセージ、またはある一定閾値以上の信号またはメッセージを検出した場合に、センシング機能をActivateする。メッセージは、例えばDCI/broadcast signal、信号電力、Channel levelなどがある。DCI/broadcast signalには、リソースプールの情報（例えば歩行者はランダムセレクション専用のリソースプールを設定しておけば、センシングが不要）がある。またDCI/broadcast signalには、自動車UEのトラフィックに関する情報がある。自動車UEのトラフィックに関する情報には、自動車UEが設定可能な送信周期がある。例えば歩行者UEと自動車UEのトラフィックモデルによって、コリジョンが発生する可能性は低いようであれば、センシングが不要である。

信号電力には、例えば 帯域のS-RSSI、RSRP、RSRQなどがある。Channel levelには、例えばCBR（Channel Busy Ratio）があり、CBRがある一定の閾値以上になった場合、歩行者UEは、センシング機能をActiveにする。

（制御）
歩行者UEは、センシングに必要な制御情報を入手もしくは更新する。既に提供されている、もしくはconfigure(pre-configure)されている場合に、歩行者UEは、その提供されている、もしくはconfigure(pre-configure)されているパラメータを使う。また歩行者UEは、センシングに必要な制御情報を入手するためにeNBもしくはRSUに問い合わせを行ってもよく、センシングに必要な制御情報をeNBもしくはRSUにブロードキャストしてもらってもよい。

（２）センシングの詳細
歩行者端末のセンシング機能がActiveになる場合に、車端末のように常にセンシング（いわゆるFull sensing）されることが望まれるが、歩行者端末にとって電力の消費が大きすぎる。従って、歩行者端末のセンシング機能がActiveになる場合でも、さらなる消費電力の低減が求められる。歩行者端末が車端末と異なるセンシング方法を用いれば、歩行者端末と車端末の送信トラフィックなどの特性に基づいて、センシングに関するパラメータも歩行者端末と車端末とでは異なる可能性がある。また、歩行者端末のパケットはいつ送信されるのかが分からないので、リソースセレクションのタイミングも分からない。従って、歩行者端末にとってセンシングのタイミングの設定が消費電力を左右する。

そこで本実施形態では、歩行者端末は、フルセンシングではなく、一部のリソースだけをセンシングする。つまり歩行者端末はパーシャルセンシング（partial sensing）を行う。パーシャルセンシングは、Burst sensingとDistributed sensingという２種類のパーシャルセンシングに分類される。以下ではそれぞれの方法を説明する。

（２−１）Burst sensing
Burst sensingは、センシング期間（車端末がセンシングを行う期間であり、例えば1sと設定される）の中で、一度だけセンシングを行う方法であり、センシング対象のリソース（Sub-sensing window）は、連続したサブフレームから構成させる。Sub-sensing
windowは、送信可能なリソース候補（Selection window）と同じサイズになる。図３１は、Burst sensingの例を示す説明図である。

（２−２）Distributed sensing
車端末の最大reservation周期は１秒になる。なるべく車端末からの送信パケットを漏らずにセンシングするため、フルセンシングはリソースセレクションを行う１秒前から行う。Burst sensingであれば、リソースを選択する前のある一定時間以内（１秒未満）のリソースしかセンシングしていない。車端末のreservation周期がburst sensing windowのサイズより大きい場合に、送信パケットはセンシングされない場合がある。それが故に、歩行者端末は、リソースを選択する時に既に使われているリソースを選択してしまい、コリジョンが発生する可能性がある。図３２は、burst sensingを使って、コリジョンが発生した問題を示す説明図である。従って、１秒の期間全体に渡ってセンシングする必要がある。

Distributed sensingは、Sensingすべき期間内を複数回センシングすることで実施される。それぞれのセンシング期間は、Sensing periodとして定義される。それぞれのSub-sensing periodは、Selection windowと同じサイズである。端末は、複数のSensing periodのセンシング結果を用いて、Selection windowにおけるリソース使用状況を認識し、送信すべきリソースを決定する。例えば、Sensingすべき期間が１秒の場合であれば、例えば100ミリ秒ごとの期間に分割し、期間内でSensing periodを決定する。図３３は、Distributed sensingの例を示す説明図である。

（Distributed sensing with fixed window）
１秒間のsubframe（1000サブフレーム）を100msおきに区切ると、10ピリオドになる。すべてのピリオドを含めて、10回のsub-sensingを行う。それぞれのSub-sensing期間の設定はセンシングすべき期間にわたって同じにすることも可能である。すなわち、それぞれのセンシング期間における、センシングのstarting subframeやセンシング期間、センシングの間隔は固定である。図３４は、Sub-sensingごとの設定を同一にしたセンシングの例を示す説明図である。さらに、歩行者端末は自分の送信用のリソースプールと同じ領域をセンシングすることが望ましい、送信用のリソースプールと同じ領域をセンシングするので、信頼性が高い。

（Distributed sensing with shifted window）
１秒間のsubframe（1000サブフレーム）を100msおきに区切ると、10ピリオドになる。すべてのピリオドを含めて、10回のsub-sensingを行う。車端末の送信パケットの最大遅延は100msなので、100msおきにsub-sensingを行う。Sub-sensingごとの設定、例えばセンシングのstarting subframe、センシング期間、センシングの間隔は可変に設定できる。図３５は、Sub-sensingごとの設定を変化させたセンシングの例を示す説明図である。歩行者端末は、Starting subframeを、ランダムに決めても良く、パターンを基地局側から取得しても良い。このshifted windowの場合では、送信用のリソースプールを制限しなくてもよいので、リソースセレクションの柔軟性を高めることができる。これらのセンシングに関するパラメータは、パケットリザベーション周期に関するパラメータ(例えばi*P:iはパケットリザベーション周期（P*i）の構成要素であり、Pは基底となる固定値であり、iはネットワークから設定可能なパラメータである)、パケットリセレクションに関するパラメータ(リセレクションカウンタ)、チャネル混雑度であるＣＢＲ（Channel Busy Ratio）、センシングすべき対象領域を決定するために使用するパラメータの一つ以上を用いて、設定される。

ここではパーシャルセンシングのパラメータをiによって変更する方法を説明する。ここで、iとはパケットリザベーション周期（P*i）の構成要素であり、Pは基底となる固定値であり、iはネットワークから設定可能なパラメータである。例えば車端末としてはP=100msである。iの選択可能な値は集合で表示される。例えば｛0,1,2,3…｝のように表記される。i=0の場合に、パケットリザベーションを行わない。iは0以外の値であれば、今回送信用のリソースプールのi個先のリソースプール内の今回送信用の同じリソース（同じoffsetがある時間リソースと同じ周波数リソース）をリザーブする。iはビットマップとして基地局から設定されてもよい。

ここでのセンシングに関するパラメータはセンシングウィンドウの開始位置、センシングウィンドウサイズ、センシングの周波数領域、センシングのリソースプール、センシングウィンドウの番号を含み得る。

センシングに関するパラメータの設定は、ネットワーク側か、もしくは歩行者端末自身が行っても良い。また、端末にPreconfigurationされていてもよい。歩行者端末が、ネットワークのＣＢＲを用いて、センシングに関するパラメータを設定してもよい。例えば、ネットワークが混雑な場合に、センシングウィンドウサイズを大きく設定して、センシング候補を増やす。また、例えば、センシングを行うべきSub sensing periodを、CBRを用いて決定してもよい。歩行者端末が、パケットのリセレクションに関するパラメータ（リセレクションカウンタなど）を用いて、センシングに関するパラメータを設定してもよい。例えば、リセレクションカウンタの設定可能な集合値を用いて、センシングを行う領域を設定してもよい。

ここではセンシングに関するパラメータを、リザベーション周期に関するパラメータi、ネットワークのＣＢＲ、またはパケットのリセレクションに関するパラメータと、αというパラメータを用いて設定する方法を説明する。

ここでαはセンシングすべき対象領域（Sub sensing periodの中のSub sensing window）を示すパラメータである。つまり、どのセンシングすべき期間内のどのSub sensing windowをセンシングすればよいかをパラメータαを用いて決定する。パラメータαは基地局から通知される。例えば、パラメータiによって、Selection windowに影響のあるSub sensing windowを決定した後、それらをランキングし、どの順位までセンシングするかをこのパラメータαを用いて決定する。この他にも、センシングすべきSub sensing window番号を基地局から直接端末に通知してもよい。

歩行者端末がセンシングして、リソースセレクションを行う際に、センシングの結果によって、送信用のリソース候補な中に使えるリソースは相当少ない時がある。その場合、送信用のリソースを増やす必要がある。そのため、Sub sensing periodのサイズを拡張することで、リソース選択のための候補リソースを増加させる。また、拡張以外にも、新たに追加センシング領域をSub sensing period内に設定してもよい。

Sub sensing periodのサイズ拡張のタイミングは、端末が所定の回数以上、チャネルの混雑を検出した場合でもよい。つまり、歩行者端末はある一定のセンシング回数以上にセンシングを行った後、既定の送信リソースの候補の中にリソースの使用率を計算する。その使用率はある一定以上になると、歩行者端末が新しいセンシング候補を設定してセンシングを行う。また、端末は、所定の回数以上、チャネルの混雑を検出した場合、その後のセンシングをキャンセルし、ランダムセレクションに切り替えてもよい。

ここで、所定のセンシング回数（β）及びセンシングの混雑判定のための閾値設定（θ）は、ネットワーク側から設定されてもよく、端末自身で設定してもよい。また、Pre-configurationされてもよい。

歩行者端末がβ以上のセンシング回数にセンシングを行って、送信リソースの候補の中のリソースの使用率はθより大きい場合なら、歩行者端末が新しいセンシング候補を設定し、センシングを行う。歩行者端末がセンシングを完了したら、すべてのセンシング結果に基づき、送信リソースを選択する。新しいセンシング候補の設定は、歩行者端末が自らランダムに設定してもよい、ネットワーク側が設定した方法を通して設定してもよい。例えば、新しいセンシング候補を設定する際に、古いセンシング候補に基づいてある一定のsubframeでシフトする。

歩行者端末がβ以上のセンシング回数にセンシングを行って、送信リソースの候補の中のリソースの使用率はθより大きい場合なら、消費電力を抑えるために、センシングを中止するができる。歩行者端末が送信リソースを選択する時、センシング結果に基づく既定の送信リソース候補の使えるリソース、と送信リソース候補以外の全部のリソースはcandidateとして、選択する。

［１．３．構成例］
次に、図１７を参照して、本開示の実施形態に係る基地局（ｅＮＢ）１００の構成の一例を説明する。図１７は、本開示の実施形態に係る基地局１００の構成の一例を示すブロック図である。図１７を参照すると、基地局１００は、アンテナ部１１０、無線通信部１２０、ネットワーク通信部１３０、記憶部１４０及び処理部１５０を備える。

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

（２）無線通信部１２０
無線通信部１２０は、信号を送受信する。例えば、無線通信部１２０は、端末装置へのダウンリンク信号を送信し、端末装置からのアップリンク信号を受信する。

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

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

（５）処理部１５０
処理部１５０は、基地局１００の様々な機能を提供する。処理部１５０は、送信処理部１５１及び通知部１５３を含む。なお、処理部１５０は、これらの構成要素以外の他の構成要素をさらに含み得る。即ち、処理部１５０は、これらの構成要素の動作以外の動作も行い得る。

送信処理部１５１は、端末装置２００へ向けたデータの送信に関する処理を実行する。その他、送信処理部１５１は、上述した基地局（ｅＮＢ）の処理全般を実行する。また通知部１５３は、端末装置２００に対する情報の通知に関する処理を実行する。すなわち、通知部１５３は、上述した基地局（ｅＮＢ）の、端末装置に対する通知処理全般を実行する。

処理部１５０は、本開示における制御部の一例として機能しうる。基地局１００は、係る構成を有することで、本実施形態に関する種々の処理、例えば、端末装置２００へのリソースの割り当て、割り当てたリソースに関する情報の端末装置２００への通知、端末装置２００からの情報の取得、等を実施することが可能となる。

次に、図１８を参照して、本開示の実施形態に係る端末装置２００の構成の一例を説明する。図１８は、本開示の実施形態に係る端末装置２００の構成の一例を示すブロック図である。図１８を参照すると、端末装置２００は、アンテナ部２１０、無線通信部２２０、記憶部２３０及び処理部２４０を備える。

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

（２）無線通信部２２０
無線通信部２２０は、信号を送受信する。例えば、無線通信部２２０は、基地局からのダウンリンク信号を受信し、基地局へのアップリンク信号を送信する。

（３）記憶部２３０
記憶部２３０は、端末装置２００の動作のためのプログラム及び様々なデータを一時的に又は恒久的に記憶する。

（４）処理部２４０
処理部２４０は、端末装置２００の様々な機能を提供する。処理部２４０は、取得部２４１及び受信処理部２４３を含む。なお、処理部２４０は、これらの構成要素以外の他の構成要素をさらに含み得る。即ち、処理部２４０は、これらの構成要素の動作以外の動作も行い得る。

取得部２４１は、基地局１００から送信されたデータの取得に関する処理を実行する。受信処理部２４３は、取得部２４１が取得したデータの受信に関する処理を実行する。受信処理部２４３は、上述した端末装置の処理全般を実行する。

処理部２４０は、本開示における制御部の一例として機能しうる。端末装置２００は、係る構成を有することで、本実施形態に関する種々の処理、例えば、リソースの確保、リソースの予約、他の端末装置や基地局１００へのデータの送信、等を実施することが可能となる。

＜２．応用例＞
本開示に係る技術は、様々な製品へ応用可能である。例えば、基地局１００は、マクロｅＮＢ又はスモールｅＮＢなどのいずれかの種類のｅＮＢ（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）モジュール９２４、センサ９２５、データインタフェース９２６、コンテンツプレーヤ９２７、記憶媒体インタフェース９２８、入力デバイス９２９、表示デバイス９３０、スピーカ９３１、無線通信インタフェース９３３、１つ以上のアンテナスイッチ９３６、１つ以上のアンテナ９３７及びバッテリー９３８を備える。

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

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

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

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

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

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

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

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

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

図２２に示したカーナビゲーション装置９２０において、図１８を参照して説明した処理部２４０に含まれる１つ以上の構成要素（取得部２４１及び／又は受信処理部２４３）は、無線通信インタフェース９３３において実装されてもよい。あるいは、これらの構成要素の少なくとも一部は、プロセッサ９２１において実装されてもよい。一例として、カーナビゲーション装置９２０は、無線通信インタフェース９３３の一部（例えば、ＢＢプロセッサ９３４）若しくは全部及び／又はプロセッサ９２１を含むモジュールを搭載し、当該モジュールにおいて上記１つ以上の構成要素が実装されてもよい。この場合に、上記モジュールは、プロセッサを上記１つ以上の構成要素として機能させるためのプログラム（換言すると、プロセッサに上記１つ以上の構成要素の動作を実行させるためのプログラム）を記憶し、当該プログラムを実行してもよい。別の例として、プロセッサを上記１つ以上の構成要素として機能させるためのプログラムがカーナビゲーション装置９２０にインストールされ、無線通信インタフェース９３３（例えば、ＢＢプロセッサ９３４）及び／又はプロセッサ９２１が当該プログラムを実行してもよい。以上のように、上記１つ以上の構成要素を備える装置としてカーナビゲーション装置９２０又は上記モジュールが提供されてもよく、プロセッサを上記１つ以上の構成要素として機能させるためのプログラムが提供されてもよい。また、上記プログラムを記録した読み取り可能な記録媒体が提供されてもよい。

また、図２２に示したカーナビゲーション装置９２０において、例えば、図１８を参照して説明した無線通信部２２０は、無線通信インタフェース９３３（例えば、ＲＦ回路９３５）において実装されてもよい。また、アンテナ部２１０は、アンテナ９３７において実装されてもよい。また、記憶部２３０は、メモリ９２２において実装されてもよい。

また、本開示に係る技術は、上述したカーナビゲーション装置９２０の１つ以上のブロックと、車載ネットワーク９４１と、車両側モジュール９４２とを含む車載システム（又は車両）９４０として実現されてもよい。即ち、取得部２４１及び／又は受信処理部２４３を備える装置として車載システム（又は車両）９４０が提供されてもよい。車両側モジュール９４２は、車速、エンジン回転数又は故障情報などの車両側データを生成し、生成したデータを車載ネットワーク９４１へ出力する。

＜３．まとめ＞
以上説明したように本開示の実施の形態によれば、以下で説明するように、Ｖ２Ｘ通信のような装置間通信を行う端末装置であって、効率的に、センシングを用いてリソースが選択できる端末装置、及び、そのような端末装置にリソースを提供する基地局が提供される。

本明細書の各装置が実行する処理における各ステップは、必ずしもシーケンス図またはフローチャートとして記載された順序に沿って時系列に処理する必要はない。例えば、各装置が実行する処理における各ステップは、フローチャートとして記載した順序と異なる順序で処理されても、並列的に処理されてもよい。

また、各装置に内蔵されるＣＰＵ、ＲＯＭおよびＲＡＭなどのハードウェアを、上述した各装置の構成と同等の機能を発揮させるためのコンピュータプログラムも作成可能である。また、該コンピュータプログラムを記憶させた記憶媒体も提供されることが可能である。また、機能ブロック図で示したそれぞれの機能ブロックをハードウェアまたはハードウェア回路で構成することで、一連の処理をハードウェアまたはハードウェア回路で実現することもできる。

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

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

なお、以下のような構成も本開示の技術的範囲に属する。
（１）
装置間通信を実行する端末装置がリソース選択できるリソース領域を割当て、前記リソース領域のセンシングの範囲に関する情報を前記端末装置に提供する制御部を備える、通信装置。
（２）
前記制御部は、前記端末装置が前記リソースを用いて通信するトラフィックの種類に応じて前記センシングの範囲を設定する、前記（１）に記載の通信装置。
（３）
前記制御部は、前記端末装置が前記リソースを用いて通信するトラフィックの優先度に応じて前記センシングの範囲を設定する、前記（１）に記載の通信装置。
（４）
前記制御部は、前記端末装置の移動速度に応じて前記センシングの範囲を設定する、前記（１）〜（３）のいずれかに記載の通信装置。
（５）
前記制御部は、前記端末装置の位置情報に応じて前記センシングの範囲を設定する、前記（１）〜（４）のいずれかに記載の通信装置。
（６）
前記制御部は、前記端末装置の種類に応じて前記センシングの範囲を設定する、前記（１）〜（５）のいずれかに記載の通信装置。
（７）
前記制御部は、Sidelinkのリソース使用状況に応じて前記センシングの範囲を設定する、前記（１）〜（６）のいずれかに記載の通信装置。
（８）
前記制御部は、前記端末装置ごとに前記センシングの範囲を設定する、前記（１）〜（７）のいずれかに記載の通信装置。
（９）
前記制御部は、全ての前記端末装置へ共通に前記センシングの範囲を設定する、前記（１）〜（７）のいずれかに記載の通信装置。
（１０）
前記制御部は、前記リソース領域の所定の範囲ごとにグルーピングを行う、前記（１）〜（９）のいずれかに記載の通信装置。
（１１）
前記制御部は、グルーピングされた範囲において前記端末装置に対してリソースホッピングを実施させるための情報を提供する、前記（１０）に記載の通信装置。
（１２）
前記制御部は、前記端末装置が前記リソースを選択してから情報を送信するまでの間隔に関する情報を提供する、前記（１）〜（１０）のいずれかに記載の通信装置。
（１３）
前記制御部は、前記端末装置が前記リソースを用いて通信するトラフィックの種類に応じて前記間隔を設定する、前記（１２）に記載の通信装置。
（１４）
前記制御部は、前記端末装置が前記リソースを用いて通信するトラフィックの優先度に応じて前記間隔を設定する、前記（１２）に記載の通信装置。
（１５）
前記制御部は、前記端末装置の移動速度に応じて前記間隔を設定する、前記（１２）〜（１４）のいずれかに記載の通信装置。
（１６）
前記制御部は、前記端末装置の位置情報に応じて前記間隔を設定する、前記（１２）〜（１５）のいずれかに記載の通信装置。
（１７）
前記制御部は、前記端末装置の種類に応じて前記間隔を設定する、前記（１２）〜（１６）のいずれかに記載の通信装置。
（１８）
前記制御部は、前記端末装置ごとに前記間隔を設定する、前記（１２）〜（１７）のいずれかに記載の通信装置。
（１９）
前記制御部は、全ての前記端末装置へ共通に前記間隔を設定する、前記（１２）〜（１７）のいずれかに記載の通信装置。
（２０）
基地局から割り当てられたリソース領域の中からリソースを選択し、選択したリソースを用いて装置間通信を実行する際に、前記リソース領域のセンシングの範囲を状況に応じて決定する制御部を備える、通信装置。
（２１）
前記制御部は、前記基地局から提供された情報に基づいて前記センシングの範囲を決定する、前記（２０）に記載の通信装置。
（２２）
前記制御部は、前記センシングの結果に基づいてリソースを選択してから情報を送信するまでの間隔を状況に応じて決定する、前記（２０）または（２１）に記載の通信装置。
（２３）
前記制御部は、前記基地局から提供された情報に基づいて前記間隔を決定する、前記（２３）に記載の通信装置。
（２４）
前記制御部は、前記情報として情報の優先度の情報を送信する、前記（２２）または（２３）に記載の通信装置。
（２５）
前記制御部は、前記情報として情報の送信元の情報を送信する、前記（２２）〜（２４）のいずれかに記載の通信装置。
（２６）
前記制御部は、前記情報として情報の送信電力に関する情報を送信する、前記（２２）〜（２５）のいずれかに記載の通信装置。
（２７）
前記制御部は、前記間隔の情報を用いて前記リソースの予約に関する情報を他の装置に通知する、前記（２２）〜（２６）のいずれかに記載の通信装置。
（２８）
前記制御部は、前記センシングの結果リソースを確保出来なかった場合に前記センシングの範囲を延長する、前記（２０）〜（２７）のいずれかに記載の通信装置。
（２９）
前記制御部は、前記センシングの範囲を所定量延長してもリソースを確保出来なかった場合に、前記リソース領域のセンシングの範囲を状況に応じて再決定する、前記（２８）に記載の通信装置。
（３０）
前記制御部は、前記センシングの範囲の再決定を所定回数行うと、前記基地局に対して報告する、前記（２９）に記載の通信装置。
（３１）
前記制御部は、エナジーセンシングによりリソースを選択する際の閾値を、前記装置間通信の際の送信電力情報に基づいて変化させる、前記（２０）〜（３０）のいずれかに記載の通信装置。
（３２）
装置間通信を実行する端末装置がリソース選択できるリソース領域を割当て、前記リソース領域のセンシングの範囲に関する情報を前記端末装置に提供することを含む、通信方法。
（３３）
基地局から割り当てられたリソース領域の中からリソースを選択し、選択したリソースを用いて装置間通信を実行する際に、前記リソース領域のセンシングの範囲を状況に応じて決定することを含む、通信方法。
（３４）
装置間通信を実行する端末装置がリソース選択できるリソース領域を割当て、前記リソース領域のセンシングの範囲に関する情報を前記端末装置に提供することをコンピュータに実行させる、コンピュータプログラム。
（３５）
基地局から割り当てられたリソース領域の中からリソースを選択し、選択したリソースを用いて装置間通信を実行する際に、前記リソース領域のセンシングの範囲を状況に応じて決定することをコンピュータに実行させる、コンピュータプログラム。
（３６）
基地局から割り当てられたリソース領域の中からリソースを選択し、選択したリソースを用いて装置間通信を実行する際に、前記基地局から通知されたパケットリザベーション周期、もしくはセンシングモードに関するパラメータのいずれか１つ以上を用いて、センシングに関するパラメータを設定する制御部を備える、通信装置。
（３７）
前記パケットリザベーションに関するパラメータはパラメータiの集合として定義される、前記（３６）に記載の通信装置。
（３８）
前記パラメータiはパケットリザベーション周期（P*i）の構成要素であり、Pは基底となる固定値であり、iはネットワークから設定可能なパラメータである、前記（３７）に記載の通信装置。
（３９）
前記センシングモードに関するパラメータはパラメータαとして定義される、前記（３７）または（３８）のいずれかに記載の通信装置。
（４０）
前記パラメータαを用いて、同一のiにおいてセンシングに関するパラメータの複数の設定方法のどちらかを使用することを決定する、前記（３９）に記載の通信装置。
（４１）
前記センシングに関するパラメータは、センシングウィンドウの開始位置、センシングウィンドウサイズ、センシングの周波数帯域、センシングのリソースプール、センシングウィンドウの番号を含む、前記（３６）に記載の通信装置。
（４２）
前記制御部は、前記基地局から通知されたパケットリザベーション周期、ネットワークのＣＢＲ（Ｃｈａｎｎｅｌ Ｂｕｓｙ Ｒａｔｉｏ）、パケットリセレクションに関するパラメータまたはセンシングすべき対象領域を示すパラメータのいずれか１つ以上を用いてセンシングに関するパラメータを設定する、前記（３６）に記載の通信装置。
（４３）
前記制御部は、所定のセンシング回数以上にセンシングを行った後、既定の送信リソースの候補の中にリソースの使用率を計算し、前記使用率が所定値以上になると、新しいセンシング候補を設定してセンシングを行う、前記（３６）に記載の通信装置。
（４４）
前記制御部は、所定のセンシング回数以上にセンシングを行った後、既定の送信リソースの候補の中にリソースの使用率を計算し、前記使用率が所定値以上になるとセンシングを中止する、前記（３６）に記載の通信装置。
（４５）
センシング回数の閾値β及び使用率の閾値θはネットワーク側から設定される、前記（４３）に記載の通信装置。
（４６）
前記制御部は、新しいセンシング候補を設定し、センシングを完了して、全てのセンシング結果に基づき送信リソースを選択する、前記（４３）に記載の通信装置。
（４７）
前記制御部は、ランダムに前記新しいセンシング候補を設定する、前記（４６）に記載の通信装置。
（４８）
前記制御部は、ネットワーク側から前記新しいセンシング候補の設定を受ける、前記（４６）に記載の通信装置。
（４９）
前記制御部は、センシングを中止して送信リソースを選択する際に、センシング結果に基づく既定の送信リソース候補の使用できるリソースと、送信リソース候補以外の全部のリソースを選択候補として、選択する、前記（４３）に記載の通信装置。
（５０）
基地局から割り当てられたリソース領域の中からリソースを選択し、選択したリソースを用いて装置間通信を実行する際に、前記基地局から通知されたパケットリザベーション周期、もしくはセンシングモードに関するパラメータのいずれか１つ以上を用いてセンシングに関するパラメータを設定することを含む、通信制御方法。

１００ 端末装置
２００ 基地局

Claims (43)

1. 装置間通信を実行する通信装置がリソース領域の情報を受信し、前記リソース領域のセンシングの範囲を設定する制御部を備え、
   前記制御部は、
   前記通信装置がリソースを用いて通信するトラフィックの種類、当該トラフィックの優先度、前記通信装置の移動速度、前記通信装置の位置情報、前記通信装置の種類、又はサイドリンクのリソース使用状況のうちのいずれか１つに応じて、前記センシングの範囲を設定する
   通信装置。
2. 前記制御部は、前記通信装置ごとに前記センシングの範囲を設定する、請求項１に記載の通信装置。
3. 前記制御部は、全ての前記通信装置へ共通に前記センシングの範囲を設定する、請求項１に記載の通信装置。
4. 前記制御部は、前記リソース領域の所定の範囲ごとにグルーピングを行う、請求項１に記載の通信装置。
5. 前記制御部は、グルーピングされた範囲において前記通信装置に対してリソースホッピングを実施させるための情報を提供する、請求項４に記載の通信装置。
6. 前記制御部は、前記通信装置が前記リソースを選択してから情報を送信するまでの間隔に関する情報を提供する、請求項１〜４のいずれかに記載の通信装置。
7. 前記制御部は、前記通信装置が前記リソースを用いて通信するトラフィックの種類に応じて前記間隔を設定する、請求項６に記載の通信装置。
8. 前記制御部は、前記通信装置が前記リソースを用いて通信するトラフィックの優先度に応じて前記間隔を設定する、請求項６に記載の通信装置。
9. 前記制御部は、前記通信装置の移動速度に応じて前記間隔を設定する、請求項６に記載の通信装置。
10. 前記制御部は、前記通信装置の位置情報に応じて前記間隔を設定する、請求項６〜９のいずれかに記載の通信装置。
11. 前記制御部は、前記通信装置の種類に応じて前記間隔を設定する、請求項６〜１０のいずれかに記載の通信装置。
12. 前記制御部は、前記通信装置ごとに前記間隔を設定する、請求項６〜１１のいずれかに記載の通信装置。
13. 前記制御部は、全ての前記通信装置へ共通に前記間隔を設定する、請求項６〜１１のいずれかに記載の通信装置。
14. 基地局から割り当てられたリソース領域の中から装置間通信を行うリソースを選択し、選択したリソースを用いて装置間通信を実行する際に、センシングの範囲を決定する制御部を備え、
    前記制御部は、
    前記基地局から提供された情報に基づいて前記センシングの範囲を決定する
    通信装置。
15. 前記制御部は、前記センシングの結果に基づいてリソースを選択してから情報を送信するまでの間隔を決定する、請求項１４に記載の通信装置。
16. 前記制御部は、前記基地局から提供された情報に基づいて前記間隔を決定する、請求項１５に記載の通信装置。
17. 前記制御部は、前記情報として情報の優先度の情報を送信する、請求項１５または１６に記載の通信装置。
18. 前記制御部は、前記情報として情報の送信元の情報を送信する、請求項１５〜１７のいずれかに記載の通信装置。
19. 前記制御部は、前記情報として情報の送信電力に関する情報を送信する、請求項１５〜１８のいずれかに記載の通信装置。
20. 前記制御部は、前記間隔の情報を用いて前記リソースの予約に関する情報を他の装置に通知する、請求項１５〜１９のいずれかに記載の通信装置。
21. 前記制御部は、前記センシングの結果リソースを確保出来なかった場合に前記センシングの範囲を延長する、請求項１４〜２０のいずれかに記載の通信装置。
22. 前記制御部は、前記センシングの範囲を所定量延長してもリソースを確保出来なかった場合に、前記リソース領域のセンシングの範囲を状況に応じて再決定する、請求項２１に記載の通信装置。
23. 前記制御部は、前記センシングの範囲の再決定を所定回数行うと、前記基地局に対して報告する、請求項２１に記載の通信装置。
24. 前記制御部は、エナジーセンシングによりリソースを選択する際の閾値を、前記装置間通信の際の送信電力情報に基づいて変化させる、請求項１４〜２３のいずれかに記載の通信装置。
25. 装置間通信を実行する通信装置がリソース領域の情報を受信し、前記リソース領域のセンシングの範囲を設定することと、
    前記通信装置がリソースを用いて通信するトラフィックの種類、当該トラフィックの優先度、前記通信装置の移動速度、前記通信装置の位置情報、前記通信装置の種類、又はサイドリンクのリソース使用状況のうちのいずれか１つに応じて、前記センシングの範囲を設定することと、を含む、通信方法。
26. 基地局から割り当てられたリソース領域の中から装置間通信を行うリソースを選択し、選択したリソースを用いて装置間通信を実行する際に、センシングの範囲を基地局から提供された情報に基づいて決定する、通信方法。
27. 装置間通信を実行する通信装置がリソース領域の情報を受信し、前記リソース領域のセンシングの範囲を設定することと、
    前記通信装置がリソースを用いて通信するトラフィックの種類、当該トラフィックの優先度、前記通信装置の移動速度、前記通信装置の位置情報、前記通信装置の種類、又はサイドリンクのリソース使用状況のうちのいずれか１つに応じて、前記センシングの範囲を設定することと、をコンピュータに実行させる、コンピュータプログラム。
28. 基地局から割り当てられたリソース領域の中から装置間通信を行うリソースを選択し、選択したリソースを用いて装置間通信を実行する際に、センシングの範囲を基地局から提供された情報に基づいて決定することをコンピュータに実行させる、コンピュータプログラム。
29. 基地局から割り当てられたリソース領域の中からリソースを選択し、選択したリソースを用いて装置間通信を実行する際に、前記基地局から通知されたパケットリザベーション周期、もしくはセンシングモードに関するパラメータのいずれか１つ以上を用いて、センシングに関するパラメータを設定する制御部を備える、通信装置。
30. 前記パケットリザベーションに関するパラメータはパラメータiの集合として定義される、請求項２９に記載の通信装置。
31. 前記パラメータiはパケットリザベーション周期（P*i）の構成要素であり、Pは基底となる固定値であり、iはネットワークから設定可能なパラメータである、請求項３０に記載の通信装置。
32. 前記センシングモードに関するパラメータはパラメータαとして定義される、請求項３０または３１に記載の通信装置。
33. 前記パラメータαを用いて、同一のiにおいてセンシングに関するパラメータの複数の設定方法のどちらかを使用することを決定する、請求項３２に記載の通信装置。
34. 前記センシングに関するパラメータは、センシングウィンドウの開始位置、センシングウィンドウサイズ、センシングの周波数帯域、センシングのリソースプール、センシングウィンドウの番号を含む、請求項２９に記載の通信装置。
35. 前記制御部は、前記基地局から通知されたパケットリザベーション周期、ネットワークのＣＢＲ（Ｃｈａｎｎｅｌ Ｂｕｓｙ Ｒａｔｉｏ）、パケットリセレクションに関するパラメータまたはセンシングすべき対象領域を示すパラメータのいずれか１つ以上を用いてセンシングに関するパラメータを設定する、請求項２９に記載の通信装置。
36. 前記制御部は、所定のセンシング回数以上にセンシングを行った後、既定の送信リソースの候補の中にリソースの使用率を計算し、前記使用率が所定値以上になると、新しいセンシング候補を設定してセンシングを行う、請求項２９に記載の通信装置。
37. 前記制御部は、所定のセンシング回数以上にセンシングを行った後、既定の送信リソースの候補の中にリソースの使用率を計算し、前記使用率が所定値以上になるとセンシングを中止する、請求項２９に記載の通信装置。
38. センシング回数の閾値β及び使用率の閾値θはネットワーク側から設定される、請求項３６に記載の通信装置。
39. 前記制御部は、新しいセンシング候補を設定し、センシングを完了して、全てのセンシング結果に基づき送信リソースを選択する、請求項３６に記載の通信装置。
40. 前記制御部は、ランダムに前記新しいセンシング候補を設定する、請求項３９に記載の通信装置。
41. 前記制御部は、ネットワーク側から前記新しいセンシング候補の設定を受ける、請求項３９に記載の通信装置。
42. 前記制御部は、センシングを中止して送信リソースを選択する際に、センシング結果に基づく既定の送信リソース候補の使用できるリソースと、送信リソース候補以外の全部のリソースを選択候補として、選択する、請求項３６に記載の通信装置。
43. 基地局から割り当てられたリソース領域の中からリソースを選択し、選択したリソースを用いて装置間通信を実行する際に、前記基地局から通知されたパケットリザベーション周期、もしくはセンシングモードに関するパラメータのいずれか１つ以上を用いてセンシングに関するパラメータを設定することを含む、通信方法。

Images