JP7419562B2 - 通信制御方法 - Google Patents

Description

本発明は、移動通信システムに用いる通信制御方法に関する。

移動通信システムの標準化プロジェクトである３ＧＰＰ（Ｔｈｉｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）の規格において、ユーザ装置間で無線通信を行うサイドリンク通信が規定されている（例えば、非特許文献１参照）。サイドリンク通信により、例えば、車両間通信（Ｖ２Ｖ：Ｖｅｈｉｃｌｅ ｔｏ Ｖｅｈｉｃｌｅ）を含むＶ２Ｘ（Ｖｅｈｉｃｌｅ ｔｏ Ｅｖｅｒｙｔｈｉｎｇ）サービスなどを実現することが可能となる。

サイドリンク通信では、ＮＧ－ＲＡＮ（Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ－Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）によりスケジューリングされたリソースを用いてユーザ装置間で無線通信が行われる場合（モード１）がある。また、サイドリンク通信では、ユーザ装置が自律的にリソースプールの中からリソースを選択して無線通信を行う場合（モード２）がある。

さらに、ユーザ装置がＮＧ－ＲＡＮのカバレッジ範囲内にあるときは、ユーザ装置のＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）状態に関係なくサイドリンク通信がサポートされる。さらに、ユーザ装置がＮＧ－ＲＡＮのカバレッジ範囲外にあるときでもサイドリンク通信はサポートされる。

したがって、例えば、ユーザ装置がＮＧ－ＲＡＮのカバレッジ範囲内にあるときは、スケジューリングされたリソースを用いて他のユーザ装置と無線通信が可能であり、また、自律的にリソースを選択して無線通信が可能である。他方、ユーザ装置がＮＧ－ＲＡＮのカバレッジ範囲外にあるときは、自律的にリソースを選択して他のユーザ装置と無線通信が可能となる。

さらに、サイドリンク通信では、ユニキャスト送信、グループキャスト送信、及びブロードキャスト送信をサポートしている。ユニキャスト送信では、ペアのピアユーザ装置間でユーザトラフィックが送受信される。また、グループキャスト送信では、サイドリンク内のグループに属するユーザ装置間でユーザトラフィックが送受信される。さらに、ブロードキャスト送信では、サイドリンク内のユーザ装置間でユーザトラフィックが送受信される。

３ＧＰＰ ＴＳ ３８．３００ Ｖ１６．２．０ （２０２０－０７）

第１の態様に係る通信制御方法は、第１及び第２のユーザ装置を有し、前記第１及び第２のユーザ装置との間でサイドリンク通信による無線通信が行われる移動通信システムにおける通信制御方法である。前記通信制御方法は、前記第２のユーザ装置とＰＣ５－ＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）コネクティッド状態にある前記第１のユーザ装置が、前記サイドリンク通信に用いる無線リソースのチャネル利用率を測定し、前記測定したチャネル利用率を前記第２のユーザ装置へ送信することを有する。さらに、前記通信制御方法は、前記第２のユーザ装置が、前記チャネル利用率を受信することを有する。

第２の態様に係る通信制御方法は、第１及び第２のユーザ装置を有し、前記第１及び第２のユーザ装置との間でサイドリンク通信による無線通信が行われる移動通信システムにおける通信制御方法である。前記通信制御方法は、前記第２のユーザ装置とＰＣ５－ＲＲＣコネクティッド状態にある前記第１のユーザ装置が、前記第２のユーザ装置が送信に用いる無線リソースを第３のユーザ装置が用いているか否かを判定し、前記無線リソースを前記第３のユーザ装置が用いていると判定したとき、前記無線リソースに関する情報を前記第２のユーザ装置へ送信することを含む。又は、前記通信制御方法は、前記第２のユーザ装置とＰＣ５－ＲＲＣコネクティッド状態にある前記第１のユーザ装置が、前記サイドリンク通信において使用されていない無線リソースを検出し、検出した前記無線リソースを前記第２のユーザ装置へ送信することを有する。前記通信制御方法は、さらに、前記第２のユーザ装置は、前記無線リソースに関する情報又は前記無線リソースを受信することを有する。

第３の態様に係る通信制御方法は、第１及び第２のユーザ装置を有し、前記第１及び第２のユーザ装置との間でサイドリンク通信による無線通信が行われる移動通信システムにおける通信制御方法である。前記通信制御方法は、前記第２のユーザ装置とＰＣ５－ＲＲＣコネクティッド状態にある前記第１のユーザ装置が、タイミング情報を前記第２のユーザ装置へ送信することと、前記第２のユーザ装置が、前記タイミング情報を受信することと、を有する。

図１は、一実施形態に係る移動通信システムの構成例を示す図である。 図２は、一実施形態に係るユーザ装置の構成例を示す図である。 図３は、一実施形態に係る基地局の構成例を示す図である。 図４は、Ｕｕインターフェイスのユーザプレーンのプロトコルスタックの構成例を示す図である。 図５は、Ｕｕインターフェイスの制御プレーンのプロトコルスタックの構成例を示す図である。 図６は、ＰＣ５のユーザプレーンのプロトコルスタックの構成例を示す図である。 図７は、ＰＣ５の制御プレーンのプロトコルスタックの構成例を示す図である。 図８（Ａ）は隠れ端末問題の例を説明するための図、図８（Ｂ）はＰＣ５－ＲＲＣ接続の動作例を表す図である。 図９は、実施例１の動作例を表す図である。 図１０は、実施例２－１の動作例を表す図である。 図１１は、実施例２－２の動作例を表す図である。 図１２は、ユーザ装置間でサイドリンク通信が行われている例を表す図である。 図１３は、実施例３－１の動作例を表す図である。 図１４は、実施例３－２の動作例を表す図である。 図１５は、実施例３－３の動作例を表す図である。

図面を参照しながら、実施形態に係る移動通信システムについて説明する。図面の記載において、同一又は類似の部分には同一又は類似の符号を付している。

（移動通信システムの構成）
まず、一実施形態に係る移動通信システムの構成例について説明する。一実施形態に係る移動通信システムは３ＧＰＰの５Ｇシステムであるが、移動通信システムには、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）が少なくとも部分的に適用されてもよい。

図１は、一実施形態に係る移動通信システム１０の構成例を示す図である。

図１に示すように、移動通信システム１０は、ユーザ装置（ＵＥ：Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）１００と、５Ｇの無線アクセスネットワーク（ＮＧ－ＲＡＮ）３００とを有する。

ＵＥ１００は、移動可能な装置である。ＵＥ１００は、ユーザにより利用される装置であればどのような装置であっても構わないが、例えば、ＵＥ１００は、携帯電話端末（スマートフォンを含む）やタブレット端末、ノートＰＣ、通信モジュール（通信カード又はチップセットを含む）、センサ若しくはセンサに設けられる装置、車両若しくは車両に設けられる装置（Ｖｅｈｉｃｌｅ ＵＥ）、飛行体若しくは飛行体に設けられる装置（Ａｅｒｉａｌ ＵＥ）など、無線通信が可能な装置である。なお、本実施の形態におけるＵＥ１００は、サイドリンク通信を利用して、他のＵＥと直接無線通信を行うことができる。

ＮＧ－ＲＡＮ３００は、５Ｇシステムにおいて「ｇＮＢ」（「ｎｅｘｔ ｇｅｎｅｒａｔｉｏｎ Ｎｏｄｅ Ｂ」）と呼ばれる基地局装置２００－１を含む。また、ＮＧ－ＲＡＮ３００は、ＮＲ（Ｎｅｗ Ｒａｄｉｏ）と協調可能なＬＴＥ基地局である基地局装置２００－２を含む。基地局装置２００－２は、「ｎｇ－ｅＮＢ」と呼ばれる。

ｇＮＢ２００－１とｎｇ－ｅＮＢ２００－２は、ＮＧ－ＲＡＮノードと呼ばれることもある。ｇＮＢ２００－１とｎｇ－ｅＮＢ２００－２とは、基地局間インターフェイスであるＸｎインターフェイスを介して相互に接続される。ｇＮＢ２００－１とｎｇ－ｅＮＢ２００－２は、１又は複数のセルを管理する。ｇＮＢ２００－１とｎｇ－ｅＮＢ２００－２は、自セルとの接続を確立したＵＥ１００との無線通信を行う。ｇＮＢ２００－１とｎｇ－ｅＮＢ２００－２は、無線リソース管理（ＲＲＭ）機能、ユーザデータ（以下、単に「データ」という）のルーティング機能、モビリティ制御・スケジューリングのための測定制御機能等を有する。「セル」は、無線通信エリアの最小単位を示す用語として用いられる。「セル」は、ＵＥ１００との無線通信を行う機能又はリソースを示す用語としても用いられる。１つのセルは１つのキャリア周波数に属する。

図１に示すように、ｇＮＢ２００－１とｎｇ－ｅＮＢ２００－２との間はＸｎインターフェイスで接続される。また、ｇＮＢ２００－１とＵＥ１００－１との間と、ｎｇ－ｅＮＢ２００－２とＵＥ１００－２との間は、基地局ユーザ装置間インターフェイスであるＵｕインターフェイスで接続される。さらに、ＵＥ１００－１～１００－３間は、ユーザ装置間インターフェイスであるＰＣ５インターフェイスで接続される。

なお、３ＧＰＰでは、ＮＲサイドリンク通信とＶ２Ｘサイドリンク通信とが規定される。ＮＲサイドリンク通信は、例えば、ネットワークノードを経由することなく、ＮＲ（Ｎｅｗ Ｒａｄｉｏ）技術を利用して、ＵＥ１００－１～１００－３間において、少なくともＶ２Ｘ通信が可能な通信のことである。また、Ｖ２Ｘサイドリンク通信は、例えば、ネットワークノードを経由することなく、Ｅ－ＵＴＲＡ（Ｅｖｏｌｖｅｄ－Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ）技術を利用して、Ｖ２Ｘ通信が可能な通信のことである。以下では、ＮＲサイドリンク通信とＶ２Ｘサイドリンク通信とをとくに区別することなく、「サイドリンク通信」と称する場合がある。したがって、「サイドリンク通信」には、ＮＲサイドリンク通信が含まれてもよいし、Ｖ２Ｘサイドリンク通信が含まれてもよい。

また、図１において、ｇＮＢ２００－１が５Ｇのコアネットワークである５ＧＣ（５Ｇ Ｃｏｒｅ ｎｅｔｗｏｒｋ）に接続されてもよいし、ｎｇ－ｅＮＢ２００－２がＬＴＥのコアネットワークであるＥＰＣ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｃｏｒｅ）に接続されてもよい。或いは、ｇＮＢ２００－１がＥＰＣに接続されてもよいし、ｎｇ－ｅＮＢ２００－２が５ＧＣに接続されてもよい。

なお、以下においては、ｇＮＢ２００－１とｎｇ－ｅＮＢ２００－２のうち、代表して、ｇＮＢ２００－１を基地局装置の例として説明する。また、ｇＮＢ２００－１をｇＮＢ２００、ＵＥ１００－１～１００－３をＵＥ１００と表記する場合がある。

図２は、一実施形態に係るＵＥ１００（ユーザ装置）の構成を示す図である。

図２に示すように、ＵＥ１００は、受信部１１０、送信部１２０、及び制御部１３０を備える。

受信部１１０は、制御部１３０の制御下で各種の受信を行う。受信部１１０は、アンテナ及び受信機を含む。受信機は、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換（ダウンコンバート）して制御部１３０に出力する。なお、本実施の形態におけるＵＥ１００は、ｇＮＢ２００だけではなく、他のＵＥとの間でサイドリンク通信による無線通信を行うことが可能である。そのため、受信部１１０は、他のＵＥから送信されたメッセージ又はデータなどを受信することも可能である。

送信部１２０は、制御部１３０の制御下で各種の送信を行う。送信部１２０は、アンテナ及び送信機を含む。送信機は、制御部１３０が出力するベースバンド信号（送信信号）を無線信号に変換（アップコンバート）してアンテナから送信する。本実施の形態では、送信部１２０は、ｇＮＢ２００へデータなどを送信するだけはなく、サイドリンク通信により、他のＵＥへ、メッセージ又はデータなどを送信することが可能である。

制御部１３０は、ＵＥ１００における各種の制御を行う。制御部１３０は、少なくとも１つのプロセッサと、プロセッサと電気的に接続された少なくとも１つのメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサと、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）と、を含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。本実施の形態における制御部１３０は、以下に示す実施例で説明する各種の制御又は処理を行うことが可能である。

図３は、一実施形態に係るｇＮＢ２００（基地局）の構成を示す図である。

図３に示すように、ｇＮＢ２００は、送信部２１０、受信部２２０、制御部２３０、及びバックホール通信部２４０を備える。

送信部２１０は、制御部２３０の制御下で各種の送信を行う。送信部２１０は、アンテナ及び送信機を含む。送信機は、制御部２３０が出力するベースバンド信号（送信信号）を無線信号に変換（アップコンバート）してアンテナから送信する。

受信部２２０は、制御部２３０の制御下で各種の受信を行う。受信部２２０は、アンテナ及び受信機を含む。受信機は、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換（ダウンコンバート）して制御部２３０に出力する。

制御部２３０は、ｇＮＢ２００における各種の制御を行う。制御部２３０は、少なくとも１つのプロセッサと、プロセッサと電気的に接続された少なくとも１つのメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサと、ＣＰＵと、を含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。ＣＰＵに代えて、ＤＳＰ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ）やＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）などのプロセッサやコントローラであってもよい。

バックホール通信部２４０は、基地局間インターフェイスを介して隣接基地局と接続される。バックホール通信部２４０は、基地局－コアネットワーク間インターフェイスを介して５ＧＣの各ノードと接続される。なお、ｇＮＢ２００は、ＣＵ（Ｃｅｎｔｒａｌ Ｕｎｉｔ）とＤＵ（Ｄｉｓｔｒｉｂｕｔｅｄ Ｕｎｉｔ）とで構成され（すなわち、機能分割され）、両ユニット間がＦ１インターフェイスで接続されてもよい。

（Ｕｕインターフェイスにおけるプロトコルスタックについて）
図４は、Ｕｕインターフェイスにおいて、データを取り扱うユーザプレーンの無線インターフェイスのプロトコルスタックの構成を示す図である。

図４に示すように、Ｕｕインターフェイスにおけるユーザプレーンの無線インターフェイスプロトコルは、物理（ＰＨＹ）レイヤと、ＭＡＣ（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）レイヤと、ＲＬＣ（Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ）レイヤと、ＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）レイヤと、ＳＤＡＰ（Ｓｅｒｖｉｃｅ Ｄａｔａ Ａｄａｐｔａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）レイヤとを有する。

ＰＨＹレイヤは、符号化・復号、変調・復調、アンテナマッピング・デマッピング、及びリソースマッピング・デマッピングを行う。ＵＥ１００のＰＨＹレイヤとｇＮＢ２００のＰＨＹレイヤとの間では、物理チャネルを介してデータ及び制御情報が伝送される。

ＭＡＣレイヤは、データの優先制御、ハイブリッドＡＲＱ（ＨＡＲＱ）による再送処理、及びランダムアクセスプロシージャ等を行う。ＵＥ１００のＭＡＣレイヤとｇＮＢ２００のＭＡＣレイヤとの間では、トランスポートチャネルを介してデータ及び制御情報が伝送される。ｇＮＢ２００のＭＡＣレイヤはスケジューラを含む。スケジューラは、上下リンクのトランスポートフォーマット（トランスポートブロックサイズ、変調・符号化方式（ＭＣＳ））及びＵＥ１００への割当リソースブロックを決定する。

ＲＬＣレイヤは、ＭＡＣレイヤ及びＰＨＹレイヤの機能を利用してデータを受信側のＲＬＣレイヤに伝送する。ＵＥ１００のＲＬＣレイヤとｇＮＢ２００のＲＬＣレイヤとの間では、論理チャネルを介してデータ及び制御情報が伝送される。

ＰＤＣＰレイヤは、ヘッダ圧縮・伸張、及び暗号化・復号化を行う。

ＳＤＡＰレイヤは、コアネットワークがＱｏＳ制御を行う単位であるＩＰフローとＡＳ（Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）がＱｏＳ制御を行う単位である無線ベアラとのマッピングを行う。なお、ＲＡＮがＥＰＣに接続される場合は、ＳＤＡＰが無くてもよい。

図５は、Ｕｕインターフェイスにおいて、シグナリング（制御信号）を取り扱う制御プレーンの無線インターフェイスのプロトコルスタックの構成を示す図である。なお、図５では、５ＧＣに含まれるノードとしてＡＭＦ（Ａｃｃｅｓｓ ａｎｄ Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｆｕｎｃｔｉｏｎ）が表記される。

図５に示すように、Ｕｕインターフェイスにおける制御プレーンの無線インターフェイスのプロトコルスタックは、図４に示したＳＤＡＰレイヤに代えて、ＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）レイヤ及びＮＡＳ（Ｎｏｎ－Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）レイヤを有する。

ＵＥ１００のＲＲＣレイヤとｇＮＢ２００のＲＲＣレイヤとの間では、各種設定のためのＲＲＣシグナリングが伝送される。ＲＲＣレイヤは、無線ベアラの確立、再確立及び解放に応じて、論理チャネル、トランスポートチャネル、及び物理チャネルを制御する。ＵＥ１００のＲＲＣとｇＮＢ２００のＲＲＣとの間に接続（ＲＲＣ接続）がある場合、ＵＥ１００はＲＲＣコネクティッド状態にある。ＵＥ１００のＲＲＣとｇＮＢ２００のＲＲＣとの間に接続（ＲＲＣ接続）がない場合、ＵＥ１００はＲＲＣアイドル状態にある。また、ＲＲＣ接続が中断（サスペンド）されている場合、ＵＥ１００はＲＲＣインアクティブ状態にある。

ＲＲＣレイヤの上位に位置するＮＡＳレイヤは、セッション管理及びモビリティ管理等を行う。ＵＥ１００のＮＡＳレイヤとＡＭＦ３００のＮＡＳレイヤとの間では、ＮＡＳシグナリングが伝送される。

なお、ＵＥ１００は、無線インターフェイスのプロトコル以外にアプリケーションレイヤ等を有する。

（ＰＣ５インターフェイスにおけるプロトコルスタックについて）
図６は、ＰＣ５インターフェイスにおけるユーザプレーンのプロトコルスタックの構成例を表す図である。

図６に示すように、ＰＣ５インターフェイスにおけるユーザプレーンのプロトコルは、Ｕｕインターフェイスにおけるユーザプレーンのプロトコルと同様に、ＰＨＹレイヤ、ＭＡＣレイヤ、ＲＬＣレイヤ、ＰＤＣＰレイヤ、及びＳＤＡＰレイヤの各レイヤを含む。

また、図７は、ＰＣ５インターフェイスにおける制御プレーンのプロトコルスタックの構成例を表す図である。

図７に示すように、ＰＣ５インターフェイスにおける制御プレーンのプロトコルも、Ｕｕインターフェイスにおける制御プレーンのプロトコルと同様に、ＰＨＹレイヤ、ＭＡＣレイヤ、ＲＬＣレイヤ、ＰＤＣＰレイヤ、及びＲＲＣレイヤを含む。

ユーザプレーンのＭＡＣレイヤでは、サイドリンク通信におけるトランポートレイヤ（ＳＣＣＨ（Ｓｉｄｅｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）、ＳＴＣＨ（Ｓｉｄｅｌｉｎｋ Ｔｒａｎｓｐｏｒｔ Ｃｈａｎｎｅｌ）、及びＳＢＣＣＨ（Ｓｉｄｅｌｉｎｋ Ｂｒｏａｄｃａｓｔ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ））を介して、データが伝送される。また、制御プレーンのＭＡＣレイヤでは、サイドリンク通信におけるトランスポートレイヤを介して、制御情報が伝送される。さらに、少なくともいずれ一方のプレーンのＭＡＣレイヤにおいては、上りリンク通信とサイドリンク通信との間の優先ハンドリング、サイドリンクのＣＳＩ（Ｃｈａｎｎｅｌ Ｓｔａｔｅ Ｉｎｆｏｒｍａｔｉｏｎ）報告などが行われる。

また、制御プレーンのＲＲＣレイヤでは、ピアＵＥ１００－１，１００－２間でのＰＣ５－ＲＲＣメッセージの転送、ＰＣ５－ＲＲＣ接続の維持と管理、ＰＣ５－ＲＲＣ接続におけるサイドリンク無線リンクの失敗（Ｆａｉｌｕｒｅ）の検出などが行われる。

なお、ＰＣ５－ＲＲＣ接続は、レイヤ２における送信元と宛先のＩＤのペアに対する２つのＵＥ１００間の論理接続のことである。ＰＣ５－ＲＲＣ接続は、対応するＰＣ５ユニキャストリンクが確立された後に確立される。ＰＣ５－ＲＲＣ接続とＰＣ５ユニキャストリンクとは１対１の関係がある。ＵＥ１００は、レイヤ２における送信元と宛先のＩＤのペアが異なる１つ以上の他のＵＥとの間で、複数のＰＣ５－ＲＲＣ接続を有することが可能である。ＵＥ１００は、サイドリンク通信に興味がない場合、或いは、レイヤ２リンク解放プロシージャが完了した場合などに、ＰＣ５－ＲＲＣ接続を解放する。ＰＣ５－ＲＲＣ接続されたＵＥ１００－１，１００－２は、ＰＣ５－ＲＲＣ接続（コネクティッド）状態となる。

（サイドリンク通信の物理チャネルについて）
サイドリンク通信における物理チャネルとして、物理サイドリンク制御チャネル（ＰＳＣＣＨ：Ｐｈｙｓｉｃａｌ Ｓｉｄｅｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）と、物理サイドリンク共有チャネル（ＰＳＳＣＨ：Ｐｈｙｓｉｃａｌ Ｓｉｄｅｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ）がある。また、サイドリンク通信における物理チャネルとして、物理サイドリンクフィードバックチャネル（ＰＳＦＣＨ：Ｐｈｙｓｉｃａｌ Ｓｉｄｅｌｉｎｋ Ｆｅｅｄｂａｃｋ Ｃｈａｎｎｅｌ）、及び物理サイドリンクブロードキャスト（ＰＳＢＣＨ：Ｐｈｙｓｉｃａｌ Ｓｉｄｅｌｉｎｋ Ｂｒｏａｄｃａｓｔ Ｃｈａｎｎｅｌ）がある。

ＰＳＣＣＨでは、ＵＥ１００がＰＳＳＣＨで使用するリソースに関する制御情報などが送信される。ＰＳＣＣＨでは、２段階に分けで異なる制御情報（ＳＣＩ：Ｓｉｄｅｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）が送信される場合がある。ＰＳＳＣＨでは、データのＴＢ（Ｔｒａｎｓｐｏｒｔ Ｂｌｏｃｋ）の送信、ＨＡＲＱ手順などの制御情報の一部が送信される。ＰＳＦＣＨは、ＰＳＳＣＨ送信の受信対象であるＵＥ１００－２から送信を実行したＵＥ１００－１へ、ＨＡＲＱフィードバック情報が送信される。ＰＳＦＣＨは、ユニキャスト送信とグループキャスト送信に適用されてよい。ＰＳＢＣＨは、直接フレーム番号（ＤＦＮ：Ｄｉｒｅｃｔ Ｆｒａｍｅ Ｎｕｍｂｅｒ）、同期に関する情報などが伝送される。

（動作例）
次に動作例について説明する。動作例は以下の順番で説明する。

実施例１：ＰＣ５－ＲＲＣ接続されたＵＥ１００間において、ＣＢＲ測定結果を共有する
実施例２－１：ＰＣ５－ＲＲＣ接続されたＵＥ１００へ送信リソースの変更通知を行う
実施例２－２：ＰＣ５－ＲＲＣ接続されたＵＥ１００へ空き（又は使用されていない）リソースを通知する
実施例３－１：受信側ＵＥが送信側ＵＥへサイドリンク受信ができないタイミングを通知する
実施例３－２：送信側ＵＥが受信側ＵＥへサイドリンク送信ができないタイミングを通知する
実施例３－３：相手方ＵＥへ送受信できないタイミングを通知する

（実施例１）
図８（Ａ）は隠れ端末問題の例を表す図である。図８（Ａ）に示すように、ＵＥ１００－１とＵＥ１００－３とは互いに無線信号が届かない範囲に位置する。すなわち、ＵＥ１００－１は、ＵＥ１００－３から送信された無線信号を受信することができない。また、ＵＥ１００－３もＵＥ１００－１から送信された無線信号を受信することができない。したがって、ＵＥ１００－１とＵＥ１００－３とは、キャリアセンスを行っても、他方から送信された無線信号を検知しない。

このような状況で、図８（Ａ）に示すように、ＵＥ１００－２が、ＵＥ１００－１からの無線信号を受信できる範囲に位置するとともに、ＵＥ１００－３からの無線信号を受信できる範囲に位置する場合を考える。そして、ＵＥ１００－１とＵＥ１００－３とが同一の無線リソースを用いて無線信号をＵＥ１００－２へ送信する場合を考える。

この場合、ＵＥ１００－２では、ＵＥ１００－１から送信された無線信号とＵＥ１００－３から送信された無線信号とを受信しようとするが、同一の無線リソースを用いて送信された無線信号のため、一方が他方の干渉となって、正常に受信することができない。

このように、ＵＥ１００－２が無線信号を正常に受信することができなくなる問題が隠れ端末問題である。

ＵＥ１００－１，１００－２間と、ＵＥ１００－２，１００－３間とでサイドリンク通信による無線通信が行われるため、サイドリンク通信においても隠れ端末問題が発生し得る。

本実施の形態では、受信側のＵＥ１００－２における干渉を回避できるようにした通信制御情報を提供する。

本実施例１における通信制御方法では、ＵＥ１００－１とＰＣ５－ＲＲＣコネクティッド状態にあるＵＥ１００－２がチャネル利用率を測定する。このようなチャネル利用率の一例として、チャネルビジー率（ＣＢＲ：Ｃｈａｎｎｅｌ Ｂｕｓｙ Ｒａｔｉｏ）がある。ＵＥ１００－２は、測定したチャネル利用率をＵＥ１００－１へ送信する。

ＵＥ１００－１では、受信したチャネル利用率に基づいて、送信リソースの再選択を行う。または、ＵＥ１００－１では、受信したチャネル利用率に基づいて、新たな送信リソースをｇＮＢ２００へ要求して、送信リソースの割り当てを受けることもできる。さらに、ＵＥ１００－１は、その双方を実行することもできる。

送信側のＵＥ１００－１は、このように再選択した送信リソース又は割り当てを受けた新たな送信リソースを用いて、受信側のＵＥ１００－２へデータなどを送信する。この場合、受信側のＵＥ１００－２は、他のＵＥ１００－３とは異なる無線リソースによりＵＥ１００－１からデータなどが送信される。そのため、受信側のＵＥ１００－２では、他のＵＥ１００－３からの送信が干渉になることなく、送信側のＵＥ１００－１から送信されたデータなどを受信できる。よって、本実施例１では、隠れ端末問題による干渉を回避することができる。

次に、実施例１による動作例について説明する。図９は、本実施例１による動作例を表す図である。

ステップＳ１１０において、ＵＥ１００－１とＵＥ１００－２との間のＰＣ５－ＲＲＣ接続が行われる。図８（Ｂ）はＰＣ５－ＲＲＣ接続の変更手順の例を表す図である。この変更手順は、サイドリンクＤＲＢ（Ｄａｔａ Ｒａｄｉｏ Ｂｅａｒｅｒ）の確立、変更、及び解放が行われる場合に行われる。

ステップＳ１０１において、ＵＥ１００－１は、ＲＲＣ再設定サイドリンク（ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎＳｉｄｅｌｉｎｋ）メッセージをＵＥ１００－２へ送信する。ＲＲＣ再設定サイドリンクメッセージは、ＵＥ１００間で交換されるメッセージである。ＲＲＣ再設定サイドリンクメッセージには、ＵＥ１００間でのＰＣ５－ＲＲＣ接続に関する設定情報などが含まれる。ＲＲＣ再設定サイドリンクメッセージは、ユニキャスト送信において（のみ）用いられるメッセージである。

ステップＳ１０２において、ＵＥ１００－２は、ＲＲＣ再設定完了サイドリンク（ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｐｌｅｔｅＳｉｄｅｌｉｎｋ）メッセージをＵＥ１００－１へ送信する。ＲＲＣ再設定完了サイドリンクメッセージは、ＰＣ５－ＲＲＣ再設定が正常に完了したことを確認するために送信されるメッセージである。

以上により、ＵＥ１００－１とＵＥ１００－２とは、ＰＣ５－ＲＲＣ接続され、ＰＣ５－ＲＲＣコネクティッド状態となる。

図９に戻り、ステップＳ１１０において、ＵＥ１００－１とＵＥ１００－２との間でＰＣ５－ＲＲＣコネクティッド状態になると、ステップＳ１１１において、ＵＥ１００－２は、ＣＢＲ測定を行う。ＵＥ１００－２の制御部１３０がＣＢＲ測定を行ってもよい。サブフレームｎで測定されたＣＢＲは、例えば、以下のように定義される。

１）ＰＳＳＣＨの場合、ＣＢＲは、ＵＥ１００－２によって測定されたリソースプールのＳ－ＲＳＳＩ（Ｓｉｄｅｌｉｎｋ－Ｒｅｃｅｉｖｅｄ Ｓｉｇｎａｌ Ｓｔｒｅｎｇｔｈ Ｉｎｄｉｃａｔｏｒ）が、サブフレーム［ｎ－１００，ｎ－１］上でセンスされた、（予め）設定された閾値を超えるサブチャネルの部分である。

２）ＰＳＣＣＨの場合、ＣＢＲは、（予め）設定されたプールにおいて、ＵＥ１００－２により測定されたＰＳＣＣＨプールのＳ－ＲＳＳＩが、サブフレーム［ｎ－１００，ｎ－１］上でセンスされた、（予め）設定された閾値を超えるＰＳＣＣＨプールのリソース部分である。ただし、ＰＳＣＣＨプールは、周波数領域で２つの連続するＰＲＢ（Ｐｈｙｓｉｃａｌ Ｒｅｓｏｕｒｃｅ Ｂｌｏｃｋ）のサイズを持つリソースから構成されると仮定している。また、（予め）設定されたプールは、ＰＳＣＣＨが非隣接リソースブロックで対応するＰＳＳＣＨとともに送信されるかもしれないように構成されたプールである。

ＣＢＲ測定については、ＵＥ１００－２は、サイドリンク通信で利用する無線リソースに対して行ってもよい。また、ＵＥ１００－２は、サイドリンク通信で利用する周波数（又はチャネル）に対してＣＢＲ測定を行ってもよい。後者の場合、ＵＥ１００－２は、予め設定されたセンシングウィンドウの時間内における候補リソースに対してＣＢＲ測定を行ってもよい。ＣＢＲは、このように、チャネル利用率の一例であってもよい。

ステップＳ１１２において、ＵＥ１００－２は、ＣＢＲの測定結果をＵＥ１００－１へ送信する。この場合、ＵＥ１００－２は、ＣＢＲの測定結果を含む測定報告サイドリンク（ＭｅａｓｕｒｅｍｅｎｔＲｅｐｏｒｔＳｉｄｅｌｉｎｋ）メッセージをＵＥ１００－１へ送信してもよい。測定報告サイドリンクメッセージは、ＮＲサイドリンクの測定結果を通知するためにＵＥ１００間で用いられるメッセージである。

なお、ＵＥ１００－２は、ＲＲＣ再設定サイドリンクメッセージに含まれる情報要素であるＳＬ－ＭｅａｓＣｏｎｆｉｇで、ＣＢＲ測定が設定された場合（のみ）、ＣＢＲ測定結果を報告するようにしてもよい（又はＣＢＲ測定を行うようにしてもよい）。この場合、ＲＲＣ再設定サイドリンクメッセージは、ＵＥ１００－１から送信されたメッセージである。

また、ＳＬ－ＭｅａｓＣｏｎｆｉｇで、ＣＢＲ測定対象が設定されていてもよい。ＣＢＲ設定対象の例として、サブバンド、プール、周波数、ＰＲＢが対象となっていてもよい。

さらに、ＣＢＲ測定結果は、周波数毎、プール毎、サブバンド毎、ＰＲＢ毎であってもよい。或いは、ＣＢＲ測定結果は、これらをすべて含んでいてもよい。

ステップＳ１１３において、ＵＥ１００－１は、受信したＣＢＲ測定結果に基づいて、送信リソースを再選択する。本処理は、ＵＥ１００－１主導で送信リソースの割り当てが行われる場合である。ＵＥ１００－１は、送信リソースとして、送信周波数、送信プール、送信サブバンド、又は送信ＰＲＢを再選択してもよい。例えば、ＵＥ１００－１は、ＣＢＲ測定結果が悪い（又はＣＢＲ測定結果が閾値より低い）サブバンドを送信リソースの選択対象から除外するなどである。

ステップＳ１１４において、ＵＥ１００－１は、ｇＮＢ２００へ、新たな送信リソースを要求する。本処理は、ｇＮＢ２００主導でリソースの割り当てが行われる場合である。この場合、ＵＥ１００－１は、当該要求を含むサイドリンクＵＥ情報（ＳｉｄｅｌｉｎｋＵＥＩｎｆｏｒｍａｔｉｏｎ）メッセージをｇＮＢ２００へ送信してもよい。サイドリンクＵＥ情報メッセージは、Ｖ２Ｘサイドリンク通信に関心があったり、伝送リソースの割り当て又は解放をＵＥ１００がネットワークへ要求したりする際などに用いられるメッセージである。なお、ＵＥ１００－１は、サイドリンクＵＥ情報メッセージに、対向ＵＥ１００－２のＣＢＲ結果が悪化した（又は閾値より低い）などの情報（又は原因値）を含めて送信してもよい。或いは、ＵＥ１００－１は、サイドリンクＵＥ情報メッセージに、ステップＳ１１２で受信したＣＢＲ測定結果を含めてｇＮＢ２００へ送信してもよい。

ステップＳ１１５において、ｇＮＢ２００は、サイドリンク通信用にリソース割り当てを行い、割り当て情報をＵＥ１００－１へ送信する。割り当て情報は、ＰＤＣＣＨ（Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）を用いて送信される。

ステップＳ１１６において、ＵＥ１００－１は、再選択したリソース（ステップＳ１１３）又は割り当てを受けたリソース（ステップＳ１１５）を用いて、ＵＥ１００－２へ制御情報とデータとを送信する。

なお、上記した例では、ＵＥ１００－１は、送信リソースの再選択（ステップＳ１１３）とリソース要求（ステップＳ１１４）との双方を行う例を説明した。例えば、ＵＥ１００－１は、いずれか一方を行うようにしてもよい。また、２つの処理（ステップＳ１１３とステップＳ１１４）は、ＣＢＲ測定結果が閾値より悪化した場合（又は閾値より低い場合）に実行されてもよい。もしくは、ステップＳ１１３において適切な送信リソース再選択の候補が無かった場合（つまり、割当済送信リソースの全てについてＣＢＲ測定結果が悪化しており、ＵＥ１００－１が送信リソースを再選択できなかった場合）に、ステップＳ１１３の処理が実行されてもよい。

さらに、上記した例では、ＣＢＲ測定について説明した。ＣＢＲ測定に代えて、チャネル占有率（ＣＲ：Ｃｈａｎｎｅｌ Ｏｃｃｕｐｙ Ｒａｔｉｏ）であってもよい。サブフレームｎで評価されるＣＲは、サブフレーム［ｎ－ａ，ｎ－１］がその伝送に使用され、サブフレーム［ｎ，ｎ＋ｂ］で付与されたサブチャネルの総数を、[ｎ－ａ，ｎ＋ｂ]上の伝送プールで構成されたサブチャネルの総数で除算したものとして定義される。ただし、「ａ」は正の整数、「ｂ」は「０」又は正の整数であり、「ａ」と「ｂ」は、ａ＋ｂ＋１＝１０００，ａ≧５００，かつ、ｎ＋ｂは現在の送信に対するグラントの最後の送信機会を超えてはならない。

ＵＥ１００－２は、制御部１３０により、ＣＲ測定を行って、ＣＲ測定結果を、測定報告サイドリンクメッセージに含めて、ＵＥ１００－１へ送信してもよい。ＣＲはチャネル利用率の一例であってもよい。

ＵＥ１００－１は、上述した動作例を行うことで、ＵＥ１００－２のＣＢＲ測定結果を取得することができる。同様に、ＵＥ１００－３は、ＵＥ１００－２との間で、上述した動作例を行うことで、ＵＥ１００－２のＣＢＲ測定結果を取得することができる。したがって、複数のＵＥ１００－１～１００－３間で、受信側のＵＥ１００－２のＣＢＲ測定結果を共有することができる。

勿論、ＵＥ１００－１がＵＥ１００－２のＣＢＲ測定結果に基づいて送信リソースを再選択することで、受信側のＵＥ１００－２における干渉の発生を防止することができる。しかし、さらに、このように、送信側のＵＥ１００－１，１００－３は、ＣＢＲ測定結果を共有することで、ＣＢＲ測定結果に基づいて、互いに異なる送信リソースを用いてデータなどを送信することも可能である。したがって、受信側のＵＥ１００－２では、干渉が発生することなく正常にデータなどを受信することが可能となる。

（実施例２－１）
図１０は、実施例２－１における動作例を示す図である。本実施例２－１における通信制御方法では、送信側のＵＥ１００－１とＰＣ５－ＲＲＣコネクディッド状態にある受信側のＵＥ１００－２は、センシングを行い、送信側のＵＥ１００－１が送信に利用しているリソースについて他のＵＥ１００－３が利用しているか否かを判定する。ＵＥ１００－２は、他のＵＥ１００－３が利用していると判定したとき、送信側のＵＥ１００－１に対して、現在使用している送信リソースの変更要求を送信する。

送信リソースの変更要求を受けた送信側のＵＥ１００－１は、再選択などにより送信リソースを変更することができる。送信側のＵＥ１００－１は、送信リソースを変更することで、他のＵＥ１００－３が用いている送信リソースとは異なるリソースで、データなどを送信できる。これにより、受信側のＵＥ１００－２では、他のＵＥ１００－３からの送信が干渉となることなく、送信側のＵＥ１００－１から送信されたデータなどを正常に受信することができる。

図１０は、実施例２－１の動作例を示す図である。ＵＥ１００－１が送信側、ＵＥ１００－２が受信側である。

ステップＳ１２０において、ＵＥ１００－１とＵＥ１００－２とは、ＰＣ５－ＲＲＣ接続され、ＰＣ５－ＲＲＣコネクティッド状態となる。ＵＥ１００－１とＵＥ１００－２とは、例えば、図８（Ｂ）に示すプロシージャを実行することで、ＰＣ５－ＲＲＣコネクティッド状態となる。

ステップＳ１２１において、受信側のＵＥ１００－２は、センシングを行う。具体的には、受信側のＵＥ１００－２は、現在送信側のＵＥ１００－１が使用している送信リソースについて、未送信区間などを使って、センシングすることで、他のＵＥ（例えばＵＥ１００－３）が使用しているか否かを判定する。この判定のことを干渉判定と称する場合がある。受信側のＵＥ１００－２は、センシングした結果と閾値とを比較して、干渉判定を行ってもよい。この閾値は、例えば、ｇＮＢ２００から報知された報知情報又はｇＮＢ２００から送信されたＲＲＣ再設定（ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎ）メッセージに含まれてもよい。

ステップＳ１２２において、受信側のＵＥ１００－２は、送信リソースの変更要求を、送信側ＵＥ１００－１へ送信する。送信リソースは、周波数、リソースプール、サブバンド、又はＰＲＢなどで表されてもよい。ＵＥ１００－２は、送信リソースの変更要求を含む、ＲＲＣ再設定サイドリンクメッセージ、測定報告サイドリンクメッセージ、又は新たなメッセージ（ＵＥＡｓｓｉｓｔａｎｃｅＩｎｆｏｒｍａｔｉｏｎＳｉｄｅｌｉｎｋなどのメッセージ）を送信することで、変更要求を送信するようにしてもよい。

ステップＳ１２３において、送信側のＵＥ１００－１は、送信リソースを再選択する。送信リソースの選択は、実施例１と同様の処理（ステップＳ１１３）が行われてもよい。また、送信側ＵＥ１００－１は、送信リソースの再選択に代えて、実施例１と同様に、ｇＮＢ２００へ新たな送信リソースを要求（ステップＳ１１４）するようにしてもよい。或いは、送信側のＵＥ１００－１は、送信リソースの再選択（ステップＳ１２３）と新たな送信リソースの要求（ステップＳ１１４）の双方を行うようにしてもよい。

ステップＳ１２４において、送信側のＵＥ１００－１は、再選択した送信リソースを用いて、データを受信側のＵＥ１００－２へ送信する。

（実施例２－２）
図１１は、実施例２－２の動作例を示す図である。実施例２－１では、受信側のＵＥ１００－２は、送信リソースの変更要求を送信したが、本実施例２－２では、送信リソースとして空いている（又は使用されていない。以下も同じ。）リソースを送信する例である。受信側のＵＥ１００－２において空いている送信リソースを見つけ、それを送信側のＵＥ１００－１へ送信することで、ＵＥ１００－１は、他のＵＥが用いていない送信リソースを用いてデータなどを送信することができる。これにより、受信側のＵＥ１００－２では、他のＵＥ（例えばＵＥ１００－３）が利用していない送信リソースにより送信されたＵＥ１００－１からのデータを干渉なく正常に受信することができる。よって、本実施例２－２においても、受信側のＵＥ１００－２では、隠れ端末問題による干渉が発生することなく、送信側のＵＥ１００－１から送信されたデータなどを正常に受信することが可能となる。

ステップＳ１３０において、ＵＥ１００－１，１００－２は、ＰＣ５－ＲＲＣコネクティッド状態となる。

ステップＳ１３１において、受信側のＵＥ１００－２は、センシングを行い、空いている送信リソースを探索する。センシングは、実施例２－１と同様にＣＢＲ測定であってもよい。また、空いているか否かの判定は、実施例２－１と同様に、ｇＮＢ２００からｐｒｅｃｏｎｆｉｇｕｒａｔｉｏｎされた閾値を用いて行われてもよい。さらに、ＵＥ１００－２は、実施例２－１と同様に、周波数、リソースプール、サブバンド、又はＰＲＢを送信リソースとして探索してもよい。ＵＥ１００－２は、空いている送信リソースをリスト形式でメモリなどに保持してもよい。

ステップＳ１３２において、ＵＥ１００－２は、送信リソースとして空いている送信リソースを送信側ＵＥ１００－１へ送信する。空いている送信リソースは、周波数、リソースプール、サブバンド、又はＰＲＢで表されてもよい。また、ＵＥ１００－２は、空いている送信リソースをリスト形式で送信してもよい。

ステップＳ１３３において、送信側のＵＥ１００－１は、空いている送信リソースの中から、適切な送信リソースを再選択する。この場合、ＵＥ１００－１は、空いている送信リソースをｇＮＢ２００へ通知してもよい。サイドリンクＵＥ情報メッセージにより通知が行われてもよい。

ステップＳ１３４において、送信側のＵＥ１００－１は、再選択した送信リソースを用いてデータを、ＵＥ１００－２へ送信する。

（実施例３－１）
実施例３－１から実施例３－３は、ＵＥ１００が相手方のＵＥへ、サイドリンク通信の受信（以下、「サイドリンク受信」と称する場合がある。）や送信（以下、「サイドリンク送信」と称する場合がある。）などができないタイミング情報を通知する例である。

図１２は、送信側のＵＥ１００－１と受信側のＵＥ１００－２との間でサイドリンク通信を行おうとしている例を表している。

例えば、受信側のＵＥ１００－２では、サイドリンク受信ができないタイミングに、送信側のＵＥ１００－１がデータなどを送信しても、そのデータなどを受信することができない。そのため、送信側のＵＥ１００－１は、再送を行う場合がある。この場合、送信側のＵＥ１００－１は、何度送信を行っても、受信側のＵＥ１００－２はサイドリンク受信ができないタイミングのため、消費電力が無駄になるおそれがある。

そこで、本実施例３－１では、受信側のＵＥ１００－２では、サイドリンク受信ができないタイミングを特定し、特定したタイミング情報を送信側のＵＥ１００－１へ送信する。これにより、送信側のＵＥ１００－１では、受信側のＵＥ１００－２において受信ができないタイミングにデータなどを送信することがなく、それ以外のタイミングで送信することができる。よって、送信側のＵＥ１００－１は、再送を行うことがなくなるため、無駄な電力消費が発生するおそれがなくなり、消費電力の低減を図ることが可能となる。

図１３は実施例３－１の動作例を表す図である。ＵＥ１００－１が送信側、ＵＥ１００－２が受信側である。

ステップＳ１４０において、送信側のＵＥ１００－１と受信側のＵＥ１００－２とは、ＰＣ５－ＲＲＣ接続され、ＰＣ５－ＲＲＣコネクティッド状態となる。

ステップＳ１４１において、受信側のＵＥ１００－２は、サイドリンク受信ができないタイミングを特定する。

このようなタイミングの特定方法としては、例えば、以下がある。すなわち、ＵＥ１００－２は、ＵｕインターフェイスにおけるＤＬ（Ｄｏｗｎ Ｌｉｎｋ）受信を優先するサブフレームを、サイドリンク受信ができないタイミングとして特定してもよい。ｇＮＢ２００からの受信を優先するサブフレームとしては、ＤＲＸ（Ｄｉｓｃｏｎｔｉｎｕｏｕｓ Ｒｅｃｅｐｔｉｏｎ） ＯｎＤｕｒａｔｉｏｎなどであってよい。ＵＥ１００－２は、ｇＮＢ２００との間で、ＤＲＸ動作が行われている場合、ＤＲＸ ＯｎＤｕｒａｔｉｏｎ期間では、ＰＤＣＣＨ（Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）の監視及び少なくとも１回訪れるページングメッセージの受信を行う。そのため、ＵＥ１００－２は、この期間をサイドリンク受信ができないタイミングとして特定してもよい。

または、ＵＥ１００－２は、ＰＣ５－ＲＲＣ接続された他のＵＥ（ＵＥ１００－１でもよいし、ＵＥ１００－１以外のＵＥでもよい）との間でサイドリンク受信を優先するサブフレームを、サイドリンク受信ができないタイミングとして特定してもよい。このようなサブフレームの例として、サイドリンク通信におけるＤＲＸのＯｎＤｕｒａｔｉｏｎ期間であってもよい。ＵＥ１００－２は、この期間において、例えば、ＰＳＣＣＨを監視するため、この期間をサイドリンク受信ができないタイミングとして特定してもよい。

または、ＵＥ１００－２は、Ｍｅａｓｕｒｅｍｅｎｔを行うタイミングを、サイドリンク受信ができないタイミングとしてもよい。Ｍｅａｓｕｒｅｍｅｎｔを行うタイミングとしては、ｇＮＢ２００に対してＭｅａｓｕｒｅｍｅｎｔを行うタイミングと、他のＵＥに対してＭｅａｓｕｒｅｍｅｎｔを行うタイミングとがある。

または、ＵＥ１００－２は、トラフィックに基づくタイミングを、サイドリンク受信ができないタイミングとして特定してもよい。トラフィックに基づくタイミングとしては、例えば、ＳＰＳ（Ｓｅｍｉ－Ｐｅｒｓｉｓｔｅｎｃｅ Ｓｃｈｅｄｕｌｉｎｇ）により事前に割り当てられた（設定された）リソースのタイミングであってもよい。

ステップＳ１４２において、受信側のＵＥ１００－２は、サイドリンク受信ができないタイミングを示すタイミング情報を、送信側のＵＥ１００－１へ送信する。このようなタイミングは、「受信ギャップ」（又は「Ｒｘ ｇａｐ」）と呼ばれてもよい。

タイミング情報は、ビットマップ形式で表されてもよい。例えば、各ビットはサブフレームと紐づけられてもよく、或いは、時間方向のリソースプールと紐づけられてもよい。

または、このようなタイミング情報は、周波数毎、リソースプール毎、又はサブバンド毎の情報であってもよい。すなわち、周波数毎、リソースプール毎、又はサブバンド毎にタイミング情報が紐づけられてもよい。或いは、周波数毎のタイミング情報、リソースプール毎のタイミング情報、及びサブバンド毎のタイミング情報がまとめられて、まとめられたものがタイミング情報として送信されてもよい。

または、このようなタイミング情報には、ビットマップ形式で複数のタイミング情報が含まれてもよい。すなわち、複雑なタイミングを表現するために、複数のビットマップが複数のタイミング情報として示されてもよい。

または、このようなタイミング情報は、周期的に繰り返されるものとして解釈されてもよい。すなわち、タイミング情報について、ビットマップが繰り返されるものとし解釈されてもよい。例えば、送信されるタイミング情報が「１０１１」の場合、「１０１１ １０１１ １０１１…」と「１０１１」が繰り返されていると、タイミング情報を受信したＵＥ１００－１が解釈する、などである。この場合、例えば、周期が「８」と設定されていると仮定する場合、タイミング情報を受信したＵＥ１００－１は、「１０１１ ００００」（欠落部分は「０」と仮定する）であると、解釈してもよい。

ステップＳ１４３において、送信側のＵＥ１００－１は、送信タイミングを調整する。ＵＥ１００－１は、受信したタイミング情報に基づいて、受信側のＵＥ１００－２が受信しないタイミング以外のタイミングが送信タイミングとなるように、送信タイミングを調整してもよい。

ステップＳ１４４において、送信側のＵＥ１００－１は調整された送信タイミングで、データなどを、受信側のＵＥ１００－２へ送信する。

（実施例３－２）
上記した実施例３－１では、サイドリンク受信ができないタイミングの情報を送信する例について説明した。本実施例３－２では、サイドリンク送信ができないタイミングの情報を送信する例についての実施例である。

例えば、ＤＲＸ動作を行っている受信側のＵＥ１００－２について、送信側のＵＥ１００－１が送信を行わないタイミングにウェイクアップしても、送信側のＵＥ１００－１からのデータなどを受信することはない。この場合、受信側のＵＥ１００－２は、受信の機会がないにも拘わらずウェイクアップしているため、消費電力が無駄になる。

そこで、送信側のＵＥ１００－１は、サイドリンク通信における送信を行わないタイミングの情報を、受信側のＵＥ１００－２へ送信する。これにより、受信側のＵＥ１００－２は、例えば、送信側のＵＥ１００－１において送信が行われないタイミングでウェイクアップして受信動作を行う、などということがなくなる。そのため、受信側のＵＥ１００－２では、消費電力の削減を図ることができる。

図１４は、実施例３－２の動作例を示す図である。

ステップＳ１５０において、送信側のＵＥ１００－１と受信側のＵＥ１００－２とは、ＰＣ５－ＲＲＣ接続を行う。ＵＥ１００－１，１００－２は、ＰＣ５－ＲＲＣコネクティッド状態になる。

ステップＳ１５１において、送信側のＵＥ１００－１は、サイドリンク送信ができないタイミングを特定する。

このようなタイミングの特定方法としては、例えば、以下がある。すなわち、ＵＥ１００－１は、ＵｕインターフェイスのＵＬ（Ｕｐ Ｌｉｎｋ）送信を優先するサブフレームを、サイドリンク送信ができないタイミングとして特定してもよい。そのようなタイミングとしては、例えば、Ｃｏｎｆｉｇｕｒｅｄ Ｇｒａｎｔされているタイミングであってもよい。Ｃｏｎｆｉｇｕｒｅｄ Ｇｒａｎｔは、例えば、ＵＥ１００がスケジューリング要求をｇＮＢ２００へ送信することなく、ＵＥ１００－１に予め割り当てられたＰＵＳＣＨ（Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｓｉｄｅｌｉｎｋ Ｃｈａｎｎｅｌ）の無線リソースのことである。ＵＥ１００は、このようなタイミングにおいて、ｇＮＢ２００へデータなどを送信する可能性が高いため、このようなタイミングを、サイドリンク送信ができないタイミングとして特定してもよい。

または、ＵＥ１００－１は、ＰＣ５－ＲＲＣ接続された他のＵＥ（ＵＥ１００－２でもよいし、ＵＥ１００－２以外のＵＥでもよい）との間でサイドリンク送信を優先するサブフレームを、サイドリンク送信ができないタイミングとして特定してもよい。このようなサブフレームの例として、サイドリンク通信におけるＤＲＸのＯｎＤｕｒａｔｉｏｎ期間であってもよい。

または、ＵＥ１００－１は、実施例３－１と同様に、トラフィックに基づくタイミング、例えば、ＳＰＳが割り当てられているタイミングを、サイドリンク送信ができないタイミングとして特定してもよい。

ステップＳ１５２において、送信側のＵＥ１００－１は、サイドリンク送信ができないタイミングを示すタイミング情報を、受信側のＵＥ１００－２へ送信する。このようなタイミングは、「送信ギャップ」（又は「Ｔｘ ｇａｐ」）と呼ばれてもよい。

タイミング情報は、実施例３－１と同様に、ビットマップ形式で表されてもよく、各ビットがサブフレーム又は時間方向のリソースプールと紐づけられてもよい。また、タイミング情報は、実施例３－１と同様に、周波数毎、プール毎、又はサブバンド毎の情報であってもよいし、周波数毎、プール毎、及びサブバンド毎の情報であってもよい。さらに、タイミング情報には、実施例３－１と同様に、ビットマップ形式で複数のタイミング情報が含まれてもよい。さらに、タイミング情報は、実施例３－１と同様に、ビットマップが繰り返されるものとして解釈されてもよい。

ステップＳ１５３において、受信側のＵＥ１００－２は、受信タイミングを調整する。ＵＥ１００－２は、受信したタイミング情報に基づいて、送信側のＵＥ１００－１が送信しないタイミング以外のタイミングが受信タイミングとなるように調整してもよい。例えば、ＵＥ１００－２は、送信しないタイミングにはウェイクアップしない（又は受信動作をスキップする）、としてもよい。

ステップＳ１５４において、受信側のＵＥ１００－２は、調整された受信タイミングで、送信側のＵＥ１００－１から送信されたデータなどを受信する。

（実施例３－３）
実施例３－１ではサイドリンク受信ができないタイミング、実施例３－２ではサイドリンク送信ができないタイミングをそれぞれ送信する例について説明した。本実施例３－３では、サイドリンク通信の送信及び受信ができないタイミング、すなわち、サイドリンク通信ができないタイミングを互いに通知し合う例について説明する。このようなタイミングは、「サイドリンクギャップ」（又は「Ｓｉｄｅｌｉｎｋ ｇａｐ」）と呼ばれてもよい。

図１５は、受信側のＵＥ１００－２が、サイドリンク送受信ができないタイミングを、送信側のＵＥ１００－１へ送信する動作例を示す図である。

ステップＳ１６０において、ＰＣ５－ＲＲＣ接続が行われ、ＵＥ１００－１，１００－２はＰＣ５－ＲＲＣコネクティッド状態となる。

ステップＳ１６１において、受信側のＵＥ１００－２はサイドリンク送受信ができないタイミングを特定する。特定の方法は、実施例３－１におけるステップＳ１４１と同様であってもよい。すなわち、ＵＥ１００－１は、ＵｕインターフェイスにおけるＤＬ（Ｄｏｗｎ Ｌｉｎｋ）受信を優先するサブフレームを、サイドリンク送受信ができないタイミングとして特定してもよい。または、ＵＥ１００－２は、ＰＣ５－ＲＲＣ接続された他のＵＥとの間でサイドリンク受信を優先するサブフレームを、サイドリンク送受信ができないタイミングとしてもよい。または、ＵＥ１００－２は、Ｍｅａｓｕｒｅｍｅｎｔを行うタイミング又はトラフィックに基づくタイミングを、サイドリンク送受信ができないタイミングとしてもよい。

ステップＳ１６２において、受信側のＵＥ１００－２は、サイドリンク送受信ができないタイミングを示すタイミング情報を、送信側のＵＥ１００－１へ送信する。このようなタイミング情報も、実施例３－１と同様に表されてもよい。すなわち、タイミング情報は、ビットマップ形式であってもよいし、ビットマップ形式で複数のタイミング情報が含まれてもよい。また、ビットマップ情報は、周波数毎、リソースプール毎、又はサブバンド毎の情報でもよいし、これらすべてを含む情報であってもよい。さらに、ビットマップ情報は周期的に繰り返されるものとして解釈されてもよい。

ステップＳ１６３において、送信側のＵＥ１００－１は、実施例３－１のステップＳ１４３（図１３）と同様に、送信タイミングを調整することで、送受信タイミングを調整してもよい。すなわち、送信側のＵＥ１００－１は、送受信できないタイミングに送信を行わないように調整してもよい。

ステップＳ１６４において、送信側のＵＥ１００－１は、サイドリンク送受信ができないタイミングを特定する。サイドリンク送受信ができないタイミングの特定は、実施例３－２における、ステップＳ１５１と同様である。例えば、ＵＥ１００－１は、ＵｕインターフェイスのＵＬ（Ｕｐ Ｌｉｎｋ）送信を優先するサブフレーム、又は、ＰＣ５－ＲＲＣ接続された他のＵＥ（ＵＥ１００－２でもよいし、ＵＥ１００－２以外のＵＥでもよい）との間でサイドリンク送信を優先するサブフレームを、サイドリンク送受信ができないタイミングとして特定してもよい。または、ＵＥ１００－１は、トラフィックに基づくタイミングを、サイドリンク送受信ができないタイミングとして特定してもよい。

ステップＳ１６５において、送信側のＵＥ１００－１は、サイドリンク送受信ができないタイミングを示すタイミング情報を、受信側のＵＥ１００－２へ送信する。タイミング情報は、実施例３－２と同様に、ビットマップ形式であってもよいし、ビットマップ形式で複数のタイミング情報が含まれてもよい。また、ビットマップ情報は、周波数毎、リソースプール毎、又はサブバンド毎の情報でもよいし、これらすべてを含む情報であってもよい。さらに、ビットマップ情報は周期的に繰り返されるものとして解釈されてもよい。

ステップＳ１６６において、受信側のＵＥ１００－２は、送受信タイミングを調整する。ＵＥ１００－２は、実施例３－２と同様に、送受信しない（又は送信しない）タイミングにはウェイクアップしない（又は受信動作をスキップする）、としてもよい。

ステップＳ１６７において、送信側のＵＥ１００－１は、調整されたタイミングで、データなどを送信し、受信側のＵＥ１００－２は、調整されたタイミングで、送信側のＵＥ１００－１から送信されたデータなどを受信する。

なお、図１５では、先に受信側のＵＥ１００－２においてサイドリンク送受信ができないタイミングを特定して、その後、送信側のＵＥ１００－１においてサイドリンク送受信ができないタイミングを特定する例について説明した。受信側のＵＥ１００－２が先に特定するか、送信側のＵＥ１００－１が先に特定するかは問わない。そのため、先に、送信側のＵＥ１００－１においてサイドリンク送受信ができないタイミングを特定し、その後、受信側のＵＥ１００－２においてサイドリンク送受信ができないタイミングを特定してもよい。

（その他の実施形態）
上記実施例３－１から３－３では、ＵＥ１００が送信及び／又は受信できないタイミングを相手方に通知していたが、これに限らない。例えば、ＵＥ１００は、送信及び／又は受信できるタイミング（もしくは、送信及び／又は受信が見込まれるタイミング）を相手方に通知してもよい。この場合、実施例３－１から３－３において、「送信及び／又は受信できないタイミング」を、「送信及び／又は受信できるタイミング」と読み替えればよい。

ＵＥ１００又はｇＮＢ２００が行う各処理をコンピュータに実行させるプログラムが提供されてもよい。プログラムは、コンピュータ読取り可能媒体に記録されていてもよい。コンピュータ読取り可能媒体を用いれば、コンピュータにプログラムをインストールすることが可能である。ここで、プログラムが記録されたコンピュータ読取り可能媒体は、非一過性の記録媒体であってもよい。非一過性の記録媒体は、特に限定されるものではないが、例えば、ＣＤ－ＲＯＭやＤＶＤ－ＲＯＭ等の記録媒体であってもよい。

また、ＵＥ１００又はｇＮＢ２００が行う各処理を実行する回路を集積化し、ＵＥ１００又はｇＮＢ２００の少なくとも一部を半導体集積回路（チップセット、ＳｏＣ）として構成してもよい。

以上、図面を参照して一実施形態について詳しく説明したが、具体的な構成は上述のものに限られることはなく、要旨を逸脱しない範囲内において様々な設計変更等をすることが可能である。また、矛盾しない範囲で、各実施例の全部又は一部を組み合わせることも可能である。

１０ ：移動通信システム
１００（１００－１～１００－３）：ＵＥ
１１０ ：受信部
１２０ ：送信部
１３０ ：制御部
２００（２００－１）：ｇＮＢ
２００－２：ｎｇ－ｅＮＢ
２１０ ：送信部
２２０ ：受信部
２３０ ：制御部
２４０ ：バックホール通信部

本願は、米国仮出願第６３／０８６１４１号（２０２０年１０月１日出願）の優先権を主張し、その内容の全てが本願明細書に組み込まれている。

Claims (9)

1. 第１及び第２のユーザ装置を有し、前記第１及び第２のユーザ装置との間でサイドリンク通信による無線通信が行われる移動通信システムにおける通信制御方法であって、
   前記第１のユーザ装置が、前記サイドリンク通信によるデータ送受信の開始前に、リソース情報を前記第２のユーザ装置へ送信することと、
   前記第２のユーザ装置が、前記リソース情報を受信することと、を含み、
   前記リソース情報は、前記第１のユーザ装置が他の通信に用いるタイミングであるために前記サイドリンク通信において前記第１のユーザ装置が受信できないタイミングに関する情報である、通信制御方法。
2. 前記第２のユーザ装置は、前記受信ができないタイミングにおいて前記第１のユーザ装置へ送信を行わないこと、を含む請求項１記載の通信制御方法。
3. 前記リソース情報は、前記第１のユーザ装置が、前記サイドリンク通信において送信ができないタイミングを示す情報である、請求項１記載の通信制御方法。
4. 前記第２のユーザ装置は、前記送信ができないタイミングにおいてウェイクアップしないこと、をさらに含む請求項３記載の通信制御方法。
5. 前記リソース情報は、前記第１のユーザ装置が、前記サイドリンク通信において送信及び受信ができないタイミングを示す情報である、請求項１記載の通信制御方法。
6. 前記第２のユーザ装置は、前記送信及び受信ができないタイミングにおいて前記第１のユーザ装置へ送信を行わないこと、又は前記送信及び受信ができないタイミングにおいてウェイクアップしないこと、をさらに含む請求項５記載の通信制御方法。
7. 前記他の通信は、前記第１のユーザ装置と第３のユーザ装置とのサイドリンク通信における前記第３のユーザ装置からの受信又は基地局からの受信である、請求項１に記載の通信制御方法。
8. 第２のユーザ装置との間でサイドリンク通信による無線通信を行う第１のユーザ装置であって、
   前記サイドリンク通信によるデータ送受信の開始前に、リソース情報を前記第２のユーザ装置へ送信する送信部を備え、
   前記リソース情報は、前記第１のユーザ装置が他の通信に用いるタイミングであるために前記サイドリンク通信において前記第１のユーザ装置が受信できないタイミングに関する情報である、第１のユーザ装置。
9. 第２のユーザ装置との間でサイドリンク通信による無線通信を行う第１のユーザ装置を制御するためのプロセッサであって、
   前記サイドリンク通信によるデータ送受信の開始前に、リソース情報を前記第２のユーザ装置へ送信する処理を実行し、
   前記リソース情報は、前記第１のユーザ装置が他の通信に用いるタイミングであるために前記サイドリンク通信において前記第１のユーザ装置が受信できないタイミングに関する情報である、プロセッサ。
   

Images