JPWO2019064986A1 - 通信装置及び通信方法 - Google Patents

Abstract

端末間で直接通信を行う通信装置及び通信方法を提供する。基地局の配下で端末として動作する通信装置は、無線信号を送受信する通信部と、前記通信部による、所定のリソースプールを用いたデータの送信を制御する制御部を具備する。前記制御部は、パケット受信時において、前記基地局から通知される情報、他端末から通知される情報、又は、前記端末自身から得られる情報のうち少なくとも１つに基づいて、前記所定のリソースプール内でのパケットのリレー通信の実施を判定し、送信元端末、端末自身、又は基地局が確保したリソースを使ってリレー通信を実施する。

Description

本明細書で開示する技術は、端末間で直接通信を行う通信装置及び通信方法に関する。

将来の自動運転の実現のため、近年、車載通信（Ｖ２Ｘ通信）への期待が高まってきている。Ｖ２Ｘ通信とは、Ｖｅｈｉｃｌｅｔｏ Ｘ通信の略であり、車と「何か」が通信を行うシステムである。ここでの「何か」の例として、Ｖｅｈｉｃｌｅ、 Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ、Ｎｅｔｗｏｒｋ、Ｐｅｄｅｓｔｒｉａｎなどが挙げられる（Ｖ２Ｖ、Ｖ２Ｉ／Ｎ、Ｖ２Ｐ）。

自動車向けの無線通信としては、これまで主に、ＩＥＥＥ８０２．１１ｐベースのＤＳＲＣ（Ｄｅｄｉｃａｔｅｄ Ｓｈｏｒｔ Ｒａｎｇｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）の開発が進められてきた。近年になり、３ＧＰＰ（Ｔｈｉｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）において、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）ベースの車載通信である“ＬＴＥ−ｂａｓｅｄＶ２Ｘ”の標準規格化が行われた。３ＧＰＰにおいては、さらに、５Ｇ（ＮＲ：Ｎｅｗ Ｒａｄｉｏ）において、Ｖ２Ｘの標準化活動が継続している（例えば、特許文献１を参照のこと）。

特開２０１７−１３９６５９号公報

本明細書で開示する技術の目的は、端末間で直接通信を行う通信装置及び通信方法を提供することにある。

本明細書で開示する技術の第１の側面は、基地局の配下で端末として動作する通信装置であって、
無線信号を送受信する通信部と、
前記通信部による、所定のリソースプールを用いたデータの送信を制御する制御部と、
を具備し、
前記制御部は、パケット受信時において、前記基地局から通知される情報、他端末から通知される情報、又は、前記端末自身から得られる情報のうち少なくとも１つに基づいて、前記所定のリソースプール内でのパケットのリレー通信の実施を制御する、
通信装置である。

前記制御部は、前記基地局から通知される、リレー通信を実施すべきエリア又は実施してもよいエリアを示す情報、前記基地局からのリレー通信の実施の指示又はリレー通信の停止の指示に基づいて、リレー通信の実施を判定する。

また、前記制御部は、前記パケットの送信元端末から得られる、前記パケットの送信用リソースの割り当て方法に関する情報、前記パケットの優先度情報、前記パケットの鮮度情報、

前記制御部は、前記パケットの通信に用いるチャネルの混雑度、前記チャネルの状態、前記パケットの再送情報、又は、前記端末自身の位置情報のうち少なくとも１つに基づいて、リレー通信の実施を判定する。

また、前記制御部は、リレー通信用のリソースの確保をさらに制御する。前記制御部は、前記リソースプール内でのリレー通信用のリソースのセンシングを制御し、又は、前記パケットの送信元端末が予約したリレー通信用のリソースを用いた前記パケットのリレー通信の実施を制御し、又は、前記基地局が確保したリレー通信用のリソースを用いた前記パケットのリレー通信の実施を制御する。

また、前記制御部は、パケットの鮮度情報、パケットの優先度情報、チャネル混雑度などに応じて、前記パケットのリレー通信の実施確率をさらに制御する。

また、本明細書で開示する技術の第２の側面は、基地局の配下で端末として動作する通信装置における通信方法であって、
所定のリソースプールにおいてパケットを受信するステップと、
前記基地局から通知される情報、他端末から通知される情報、又は、前記端末自身から得られる情報のうち少なくとも１つに基づいて、前記パケットのリレー通信の実施を制御するステップと、
を有する通信方法である。

本明細書で開示する技術によれば、端末間で直接通信を行う通信装置及び通信方法を提供することができる。

なお、本明細書に記載された効果は、あくまでも例示であり、本発明の効果はこれに限定されるものではない。また、本発明が、上記の効果以外に、さらに付加的な効果を奏する場合もある。

本明細書で開示する技術のさらに他の目的、特徴や利点は、後述する実施形態や添付する図面に基づくより詳細な説明によって明らかになるであろう。

図１は、Ｖ２Ｘ通信の概要を示した図である。 図２は、Ｖ２Ｖ通信の第１のシナリオを示した図である。 図３は、Ｖ２Ｖ通信の第２のシナリオを示した図である。 図４は、Ｖ２Ｖ通信の第３のシナリオを示した図である。 図５は、Ｖ２Ｖ通信の第４のシナリオを示した図である。 図６は、Ｖ２Ｖ通信の第５のシナリオを示した図である。 図７は、Ｖ２Ｘ通信が実施される無線通信システムの構成例を模式的に示した図である。 図８は、ユーザが携行する通信装置（ＵＥ）の機能的構成例を模式的に示した図である。 図９は、車両などの移動体に搭載して用いられる通信装置（ＵＥ）の機能的構成例を模式的に示した図である。 図１０は、基地局（Ｅ−ＵＴＲＡＮ、ｅＮＢ）として動作する通信装置の機能的構成例を模式的に示した図である。 図１１は、ＲＳＵとして動作する通信装置の機能的構成例を模式的に示した図である。 図１２は、Ｖ２Ｘリレー通信において想定されるシナリオを例示した図である。 図１３は、端末が信号を受信したときに実施する処理手順を示したフローチャートである。 図１４は、リレー端末がパケットのリレー通信の実施判定を行う処理手順を示したフローチャートである。 図１５は、送信元端末がリレー通信用のリソースを予約してリレー通信を行う通信シーケンス例を示した図である。 図１６は、リレー通信用リソースの割り当て例を示した図である。 図１７は、リレー端末がハイブリッドなリレー通信用リソースの確保方法によりリレー通信を実施するための処理手順を示したフローチャートである。 図１８は、基地局がサイドリンクにおけるリレー通信用リソースの割り当てを行う通信シーケンス例を示した図である。

以下、図面を参照しながら本明細書で開示する技術の実施形態について詳細に説明する。

Ａ．システム構成
車両などの移動体に通信装置を搭載することによって、移動体と種々の対象物との間で直接的な通信が実現される。とりわけ、車両と種々の対象物との間の通信はＶ２Ｘ通信と呼ばれる。図１には、Ｖ２Ｘ通信の概要を示している。図示のように、Ｖ２Ｘ通信として、Ｖ２Ｖ（Ｖｅｈｉｃｌｅ ｔｏ Ｖｅｈｉｃｌｅ）通信、Ｖ２Ｉ（Ｖｅｈｉｃｌｅ ｔｏ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）通信、Ｖ２Ｐ（Ｖｅｈｉｃｌｅ ｔｏ Ｐｅｄｅｓｔｒｉａｎ）通信、Ｖ２Ｈ（Ｖｅｈｉｃｌｅ ｔｏ Ｈｏｍｅ）通信などが挙げられる。また、図示を省略するが、Ｖ２Ｎ（Ｖｅｈｉｃｌｅ ｔｏ Ｎｅｔｗｏｒｋ）通信も、Ｖ２Ｘ通信に含まれる。なお、Ｖ２Ｘ通信の１文字目と３文字目は、それぞれ通信の始点と終点を意味しており、通信経路を限定するものではない。例えば、Ｖ２Ｖ通信は、車両同士が直接的に通信することと、基地局などを介して車両同士が間接的に通信することの両方を含む概念である。

Ｖ２Ｖ通信における車両の通信対象として、乗用車（ｐａｓｓｅｎｇｅｒ ｖｅｈｉｃｌｅ）、商用車（Ｃｏｍｍｅｒｃｉａｌ ｏｒ ｆｌｅｅｔ ｖｅｈｉｃｌｅ）、緊急車両（Ｅｍｅｒｇｅｎｃｙ ｖｅｈｉｃｌｅ）、輸送車（Ｔｒａｎｓｉｔ ｖｅｈｉｃｌｅ）などが挙げられる。また、Ｖ２Ｉ通信における車両の通信対象として、セルラーネットワーク（Ｃｅｌｌｕｌｅｒ ｎｅｔｗｏｒｋ）、データセンタ（Ｄａｔａ ｃｅｎｔｒｅ）、商用車管理センタ（ｆｌｅｅｔ ｏｒ ｆｒｅｉｇｈｔ ｍａｎａｇｅｍｅｎｔ ｃｅｎｔｒｅ）、交通管理センタ（Ｔｒａｆｆｉｃ ｍａｎａｇｅｍｅｎｔ ｃｅｎｔｒｅ）、気象サービス（Ｗｅａｔｈｅｒ ｓｅｒｖｉｃｅ）、列車運行センタ（Ｒａｉｌ ｏｐｅｒａｔｉｏｎ ｃｅｎｔｒｅ）、駐車システム（Ｐａｒｋｉｎｇ ｓｙｓｔｅｍ）、料金システム（Ｔｏｌｌ ｓｙｓｔｅｍ）などが挙げられる。また、Ｖ２Ｐ通信における車両の通信対象として、自転車の運転者（Ｃｙｃｌｉｓｔ）、歩行者用シェルタ（Ｐｅｄｅｓｔｒｉａｎ ｓｈｅｌｔｅｒ）、自動二輪（Ｍｏｔｏｒｃｙｃｌｅ）などが挙げられる。また、Ｖ２Ｈ通信における車両の通信対象として、家庭用ネットワーク（Ｈｏｍｅ ｎｅｔｗｏｒｋ）、車庫（Ｇａｒａｇｅ）、商用ネットワーク（Ｅｎｔｅｒｐｒｉｓｅ ｏｒ ｄｅｅｌｅｒ ｎｅｔｗｏｒｋｓ）などが挙げられる。

Ｖ２Ｖ通信における車両の通信対象として、乗用車（ｐａｓｓｅｎｇｅｒ ｖｅｈｉｃｌｅ）、商用車（Ｃｏｍｍｅｒｃｉａｌ ｏｒ ｆｌｅｅｔ ｖｅｈｉｃｌｅ）、緊急車両（Ｅｍｅｒｇｅｎｃｙ ｖｅｈｉｃｌｅ）、輸送車（Ｔｒａｎｓｉｔ ｖｅｈｉｃｌｅ）などが挙げられる。また、Ｖ２Ｉ通信における車両の通信対象として、セルラーネットワーク（Ｃｅｌｌｕｌｅｒ ｎｅｔｗｏｒｋ）、データセンタ（Ｄａｔａ ｃｅｎｔｒｅ）、商用車管理センタ（ｆｌｅｅｔ ｏｒ ｆｒｅｉｇｈｔ ｍａｎａｇｅｍｅｎｔ ｃｅｎｔｒｅ）、交通管理センタ（Ｔｒａｆｆｉｃ ｍａｎａｇｅｍｅｎｔ ｃｅｎｔｒｅ）、気象サービス（Ｗｅａｔｈｅｒ ｓｅｒｖｉｃｅ）、列車運行センタ（Ｒａｉｌ ｏｐｅｒａｔｉｏｎ ｃｅｎｔｒｅ）、駐車システム（Ｐａｒｋｉｎｇ ｓｙｓｔｅｍ）、料金システム（Ｔｏｌｌ ｓｙｓｔｅｍ）などが挙げられる。また、Ｖ２Ｐ通信における車両の通信対象として、自転車の運転者（Ｃｙｃｌｉｓｔ）、歩行者用シェルタ（Ｐｅｄｅｓｔｒｉａｎ ｓｈｅｌｔｅｒ）、自動二輪（Ｍｏｔｏｒｃｙｃｌｅ）などが挙げられる。また、Ｖ２Ｈ通信における車両の通信対象として、家庭用ネットワーク（Ｈｏｍｅ ｎｅｔｗｏｒｋ）、車庫（Ｇａｒａｇｅ）、商用ネットワーク（Ｅｎｔｅｒｐｒｉｓｅ ｏｒ ｄｅｅｌｅｒ ｎｅｔｗｏｒｋｓ）などが挙げられる。

自動車向けの無線通信としては、これまで主にＩＥＥＥ８０２．１１ｐベースのＤＳＲＣの開発が進められてきたが、近年になり、３ＧＰＰにおいてＬＴＥ−ｂａｓｅｄＶ２Ｘの標準規格化が行われた（前述）。ＬＴＥベースのＶ２Ｘ通信では、基本的なセーフティメッセージなどのやり取りなどがサポートされている。

一方で、さらなるＶ２Ｘ通信の改善をめざし、３ＧＰＰでは５Ｇ技術を用いたｅＶ２Ｘ（ｅｎｈａｎｃｅｄ Ｖ２Ｘ）通信の検討が行われている。ｅＶ２Ｘ通信では、これまでＬＴＥベースのＶ２Ｘではサポートできなかったような、高信頼性、低遅延、高速通信、及びハイキャパシティを必要とする新たなユースケースをサポートする。ｅＶ２Ｘ向けのユースケース及び要求事項は３ＧＰＰ ＴＲ２２．８８６に記載されている。ｅＶ２Ｘによってサポートされる主なユースケースとして、以下の（１）〜（４）が挙げられる。

（１）Ｖｅｈｉｃｌｅ Ｐｌａｔｏｏｎｎｉｎｇ
複数の車両が隊列となり、同じ方向に走行する、隊列走行のユースケースであり、隊列走行を主導する車から隊列走行を制御するための情報をやり取りする。これらの情報のやりとりにより、隊列走行の車間距離をより詰めることが可能となる。

（２）Ｅｘｔｅｎｄｅｄ Ｓｅｎｓｏｒｓ
センサー関連の情報（データ処理前のＲａｗデータや処理されたデータ）を車車間などで交換することを可能とする。センサー情報は、ローカルセンサーや、周辺の車両やＲＳＵ（Ｒｏａｄ Ｓｉｄｅ Ｕｎｉｔ：路側ユニット）や歩行者間のライブビデオイメージやＶ２Ｘアプリケーションサーバなどを通して集められる。車両はこれらの情報交換により、自身のセンサー情報では得られない情報を入手することができ、より広範囲の環境を認知若しくは認識することが可能となる。多くの情報を交換する必要があるため、通信には高いデータレートが求められる。

（３）Ａｄｖａｎｃｅｄ Ｄｒｉｖｉｎｇ
準自動走行や、完全自動走行を可能とする。それぞれの車両はＲＳＵが自身のセンサーなどから得られた認知／認識情報を周辺車両へとシェアすることで、車両の軌道や操作を同期、協調しながら調整することができる。それぞれの車両は、ドライビングの意図や意思を周辺車両とシェアすることも可能である。

（４）Ｒｅｍｏｔｅ Ｄｒｉｖｉｎｇ
遠隔操縦者やＶ２Ｘアプリケーションに遠隔操縦させる。運転ができない人や、危険地域に対して遠隔操作が用いられる。ルートや走行する道がある程度決まっているような公共交通機関に対しては、クラウドコンピューティングをベースとした操縦を用いることも可能である。高い信頼性と低い伝送遅延が通信には求められる。

上述したようなユースケース（１）〜（４）を実現するためには、ｅＶ２Ｘ通信の物理レイヤのエンハンスメントが必要となる。主なエンハンスメントとしては、インフラ、端末間通信の改善、及び端末間通信の改善が挙げられる。インフラ、端末間通信としては、Ｖ２Ｎ通信並びにＶ２Ｉ（ｅＮＢ（ｅｖｏｌｖｅｄ Ｎｏｄｅ Ｂ） ｔｙｐｅ ＲＳＵ：基地局型ＲＳＵ）通信が改善の対象となる。また、端末間通信としては、Ｖ２Ｖ通信並びにＶ２Ｐ通信が改善の対象となる。これらＶ２Ｘ通信の物理レイヤにおいて必要と考えられる主なエンハンスメントのポイントを以下に示す。

・チャネルフォーマット
−Ｆｌｅｘｉｂｌｅ ｎｕｍｅｒｏｌｏｇｙ
−ｓｈｏｒｔ ＴＴＩ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｔｉｍｅ Ｉｎｔｅｒｖａｌ）
−マルチアンテナ対応
−Ｗａｖｅｆｏｒｍエンハンスメント
・サイドリンクフィードバック通信
−ＨＡＲＱ（Ｈｙｂｒｉｄ Ａｕｔｏｍａｔｉｃ Ｒｅｐｅａｔ Ｒｅｑｕｅｓｔ）
−ＣＳＩ（Ｃｈａｎｎｅｌ Ｓｔａｔｕｓ Ｉｎｆｏｒｍａｔｉｏｎ）
・サイドリンク通信におけるリソース割り当て方式
・車両位置情報推定技術
・端末間リレー通信
・ユニキャスト通信、マルチキャスト通信のサポート
・マルチキャリア通信、キャリアアグリゲーション
・高周波周波数（ミリ波）対応（例：６ＧＨｚ以上）

本明細書では、ｅＶ２Ｘ通信の物理レイヤのエンハンスメントのうち、とりわけ端末間リレー通信若しくはサイドリンクリレー通信に着目するが、この点の詳細については後述に譲る。

Ｖ２Ｘ通信のオペレーションシナリオはさまざまである。Ｖ２Ｘ通信のオペレーションシナリオは、Ｖ２Ｖ通信をベースに構成され、片方の自動車がＰｅｄｅｓｒｉａｎになるとＶ２Ｐ通信となり、ＩｎｆｒａｓｔｒｕｃｔｕｒｅやＮｅｔｗｏｒｋで終端するとＶ２Ｉ通信又はＶ２Ｎ通信となる。図２〜図６には、Ｖ２Ｘ通信のベースとなるＶ２Ｖ通信のシナリオを例示している。

図２には、Ｖ２Ｖ通信の第１のシナリオを示している。第１のシナリオでは、車両などの移動体同士が直接的にＶ２Ｖ通信を行う。この場合の車両同士が直接的に通信を行う通信リンクは、ＳＬ（サイドリンク）である。

図３には、Ｖ２Ｖ通信の第２のシナリオを示している。第２のシナリオでは、車両などの移動体同士が、Ｅ−ＵＴＲＡＮ（Ｅｖｏｌｖｅｄ Ｕｎｉｖｅｒｓａ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ）を介して、すなわち基地局を介して間接的にＶ２Ｖ通信を行う。送信側から基地局への通信リンクはＵＬ（アップリンク）であり、基地局から受信側への通信リンクはＤＬ（ダウンリンク）である。

図４には、Ｖ２Ｖ通信の第３のシナリオを示している。第３のシナリオでは、車両などの移動体が、ＲＳＵ又はＲＳＵタイプのユーザ端末（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ：ＵＥ）、及びＥ−ＵＴＲＡＮを順に介して他の移動体へ信号を送信する。各装置間の通信リンクは、順にＳＬ、ＵＬ、及びＤＬである。

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

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

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

図７には、Ｖ２Ｘ通信が実施される無線通信システムの構成例を模式的に示している。図示の無線通信システムは、ＵＥ１０と、ＵＥ２０と、車両２２と、ｅＮＢ（基地局）３０と、ＧＮＳＳ（Ｇｌｏｂａｌ Ｎａｖｉｇａｔｉｏｎ Ｓａｔｅｌｌｉｔｅ Ｓｙｓｔｅｍ）衛星４０と、ＲＳＵ５０で構成される。

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

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

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

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

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

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

図８には、通信装置の機能的構成例を模式的に示している。図８に示す通信装置は、例えば、図７に示した無線通信システムのうちユーザ１２に携行されるＵＥ１０に対応する。また、図８に示す通信装置は、サイドリンクリレー通信を行うリレー端末としても動作するものとする。

図８に示すように、ＵＥ１０は、アンテナ部１１０と、無線通信部１２０、ＧＮＳＳ信号処理部１３０と、記憶部１４０と、処理部１５０を備えている。

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

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

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

記憶部１４０は、ＵＥ１０の動作のためのプログラム及びさまざまなデータを、一時的に又は不揮発的に記憶する。

処理部１５０は、ＵＥ１０のさまざまな機能を提供する。例えば、処理部１５０は、無線通信部１２０により行われる通信を制御する。後述するサイドリンクリレー通信におけるリレー端末としてのＵＥ１０の通信動作は、基本的には処理部１５０の制御によって実現されるものとする。

図９には、車両などの移動体に搭載して用いられる通信装置の機能的構成例を模式的に示している。図９に示す通信装置は、例えば、図７に示した無線通信システムのうち車両２２に搭載されるＵＥ２０に対応する。また、図９に示す通信装置は、サイドリンクリレー通信を行うリレー端末としても動作するものとする。

図９に示すように、ＵＥ２０は、アンテナ部２１０と、無線通信部２２０、ＧＮＳＳ信号処理部２３０と、記憶部２４０と、処理部２５０を備えている。

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

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

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

記憶部２４０は、ＵＥ２０の動作のためのプログラム及びさまざまなデータを、一時的に又は不揮発的に記憶する。

処理部２５０は、ＵＥ２０のさまざまな機能を提供する。例えば、処理部２５０は、無線通信部２２０により行われる通信を制御する。後述するサイドリンクリレー通信におけるリレー端末としてのＵＥ２０の通信動作は、基本的には処理部２５０の制御によって実現されるものとする。

また、図１０には、主に基地局として動作する通信装置の機能的構成例を模式的に示している。図１０に示す通信装置は、例えば図２〜図６に示したＶ２Ｖ通信環境におけるＥ−ＵＴＲＡＮ、若しくは図７に示した無線通信システムにおけるｅＮＢ３０に対応する。

図１０に示すように、ｅＮＢ３０は、アンテナ部３１０と、無線通信部３２０、ネットワーク通信部３３０と、記憶部３４０と、処理部３５０を備えている。

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

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

ネットワーク通信部３３０は、図示しないネットワークを経由して情報を送受信する。例えば、ネットワーク通信部３３０は、他のノードへの情報を送信し、他のノードからの情報を受信する。ここで言う他のノードは、他の基地局及びコアネットワークノードを含むものとする。

記憶部３４０は、ｅＮＢ３０の動作のためのプログラム及びさまざまなデータを、一時的に又は不揮発的に記憶する。

処理部３５０は、ｅＮＢ３０のさまざまな機能を提供する。例えば、処理部３５０は、配下のユーザ端末（ＵＥ１０、ＵＥ２０）、及びＲＳＵ５０により行われる通信を制御する。

さらに本実施形態では、処理部３５０は、サイドリンクリレー通信において、配下のユーザ端末（ＵＥ１０、ＵＥ２０）、及びＲＳＵ５０などがリレー端末としてリレーの実施を行うかどうかを判定し、判定結果を各端末に通知する処理を行う場合もある。

図１１には、図７に示した無線通信システムにおいてＲＳＵ５０として用いられる通信装置の機能的構成例を模式的に示している。図示のように、ＲＳＵ５０は、アンテナ部５１０と、無線通信部５２０、記憶部５３０と、処理部５４０を備えている。

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

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

記憶部５３０は、ＲＳＵ５０の動作のためのプログラム及びさまざまなデータを、一時的に又は不揮発的に記憶する。

処理部５４０は、ＲＳＵ５０のさまざまな機能を提供する。例えば、処理部５４０は、無線通信部５２０により行われる通信を制御する。後述するサイドリンクリレー通信におけるリレー端末としてのＲＳＵ５０の通信動作は、基本的には処理部５４０の制御によって実現されるものとする。

Ｂ．サイドリンクリレー通信
ｅＶ２Ｘ通信では、６ＧＨｚ以上の、ミリ波とも呼ばれる高周波周波数を用いることが想定されている（前述）。高周波周波数信号は、直進性が高く、且つ距離減衰が激しい。このため、自動車向けの通信環境を想定すると、交差点や車混雑時には、Ｖ２Ｘ通信（とりわけ、Ｖ２Ｖ通信やＶ２Ｐ通信）で見通し通信を確保することが難しくなる。

そこで、本明細書では、ｅＶ２Ｘ通信の物理レイヤのエンハンスメントのうち、とりわけ端末間リレー通信若しくはサイドリンクリレー通信に着目して、このような課題を解決する。

Ｂ−１．Ｖ２Ｘリレー通信の想定シナリオ
図１２には、Ｖ２Ｘリレー通信において想定されるシナリオを例示している。Ｖ２Ｘリレー通信の主なデプロイメント（Ｖ、Ｉ（Ｎ）、Ｐ、…の組み合わせ）は以下に示す通りである。端末間の通信には、例えば６ＧＨｚ以上の高周波数が用いられることを想定している。

・Ｖ２Ｖ２Ｘ通信 − 車⇔車
・Ｉ２Ｉ２Ｘ通信 − インフラ⇔インフラ
・Ｐ２Ｐ２Ｘ通信 − 歩行者⇔歩行者
・Ｖ２Ｉ２Ｘ通信（Ｉ２Ｖ２Ｘを含む） − 車⇔インフラ
・Ｐ２Ｉ２Ｘ通信（Ｐ２Ｖ２Ｘを含む） − 歩行者⇔インフラ
・Ｐ２Ｖ２Ｘ通信（Ｖ２Ｐ２Ｘを含む） − 歩行者⇔車

Ｂ−２．Ｖ２Ｘリレー通信の適用判断処理
図１２に示した各端末は、信号を受信したときにリレー通信を実施するかどうかを判断する。図１３には、端末が信号を受信したときに実施する処理手順をフローチャートの形式で示している。ここで言う端末は、Ｖｅｈｉｃｌｅでもよく、ＲＳＵのようなＩｎｆｒａｓｔｒｕｃｔｕｒｅでもよく、あるいはＰｅｄｅｓｔｒｉａｎ端末のようなＶｕｌｎｅｒａｂｌｅユーザであってもよい。すなわち、リレー端末は図８、図９、若しくは図１１に示した通信装置に相当する。

端末は、信号を受信したとき、リレー通信実施のための条件をクリアしているかどうかをチェックする（ステップＳ１３０１）。そして、リレー通信実施のための条件をクリアしている場合にのみ（ステップＳ１３０１のＹｅｓ）、リレー通信を実施する（ステップＳ１３０２）。それ以外の場合には（ステップＳ１３０１のＮｏ）、リレー通信を実施しない（ステップＳ１３０３）。

ステップＳ１３０１では、以下に示すような情報を用いて、リレー通信実施のための条件をクリアしているかどうかが判断される。

（１）基地局から通知される情報
・基地局からの指示情報又は制御情報
・基地局から提供される情報
（２）リレー端末以外の端末（Ｖ／Ｉ／Ｐ端末）から通知される情報
（３）リレー端末自身で得られる情報

上記のような情報がリレー通信実施のための条件をクリアしているかどうかを判断する判断基準について、例えば端末タイプに応じて異なるルールを設定してもよい。例えばＲＳＵや車毎に異なる判断基準を設定してもよい。以下では、リレー通信実施のための各条件の詳細について説明する。

Ｂ−３．基地局から通知される情報
Ｂ−３−１．基地局からの指示情報又は制御情報
基地局やアプリレーションレイヤーにおいてリレー通信の実施判定を行い、その判定結果を端末に通知するケースがある。基地局からの指示情報又は制御情報とは、リレー通信の実施判定結果の通知に相当する。

Ｂ−３−１−１．リレー通信実施の決定に用いる情報
基地局やアプリレーションレイヤーでは、例えば以下の条件（１）〜（８）を用いて、端末がリレー通信を実施するかどうかを決定する。なお、ここで言うアプリレーションレイヤーとして、例えばＩＴＳ（Ｉｎｔｅｌｌｉｇｅｎｔ Ｔｒａｎｓｐｏｒｔ Ｓｙｓｔｅｍｓ）アプリケーションサーバや、Ｖ２Ｘファンクションサーバなどが挙げられる。

（１）端末位置情報
（２）端末における通信の見通し状態
（３）割り当て周波数、使用周波数
（４）Ｖ２Ｘ通信に割り当てた（使用可能な）リソース量
（５）他システムからの被干渉量
（６）端末におけるサイドリンクのＲＳＲＰ（Ｒｅｆｅｒｅｎｃｅ Ｓｉｇｎａｌ Ｒｅｃｅｉｖｅｄ Ｐｏｗｅｒ）、ＲＳＳＩ（Ｒｅｃｅｉｖｅｄ Ｓｉｇｎａｌ Ｓｔｒｅｎｇｔｈ Ｉｎｄｉｃａｔｏｒ）、又はＲＳＲＱ（Ｒｅｆｅｒｅｎｃｅ Ｓｉｇｎａｌ Ｒｅｃｅｉｖｅｄ Ｑｕａｌｉｔｙ）情報
（７）端末カテゴリー、端末ケイパビリティ
（８）オペレーションの時間帯

基地局は、管理者としての機能により、上記（１）〜（８）のような情報を指し示すことができる。上記のうち（５）の被干渉量については、端末からレポートされる情報を用いてもよいし、基地局で測定してもよい。

基地局は、上記（１）及び（２）のような端末のエリアに関する情報に基づいて、端末によるリレー通信の実施判定を行うことができる。また、基地局は、上記（３）及び（４）のような、端末が使用できるリソースの余裕に関する情報に基づいて、端末によるリレー通信の実施判定を行うことができる（チャネルが混雑していると、必然的に、端末に割り当てられるリソース量は削減される）。また、基地局は、上記（５）及び（６）のような端末のチャネル状態若しくはチャネルの混雑度に関する情報に基づいて、端末によるリレー通信の実施判定を行うことができる。また、基地局は、上記（７）のような端末の仕様に関する情報に基づいて、端末によるリレー通信の実施判定を行うことができる。また、基地局は、端末によるリレー通信の実施判定の基準を、オペレーションの時間帯に応じて切り替えるようにしてもよい。

Ｂ−３−１−２．リレー通信実施の決定結果の通知方法
そして、基地局は、上記の条件（１）〜（８）などを用いて端末のリレー通信実施の決定を行うと、端末に対してリレー通信のＥｎａｂｌｅ／Ｄｉｓａｂｌｅを通知する。端末は、基地局からＥｎａｂｌｅが通知されるとリレー通信を実施し、また、基地局からＤｉｓａｂｌｅが通知されるとリレー通信の実施を停止する。

基地局が端末にＥｎａｂｌｅ／Ｄｉｓａｂｌｅを通知する方法はいくつか考えられる。以下では、ＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）シグナリングを通して通知する方法、システム情報としてブロードキャストする方法、並びにＩｍｐｌｉｃｉｔにリレー通信の実施を制御する方法の３通りについて説明しておく。

（１）ＲＲＣシグナリングを用いて通知する方法
例えば、基地局は、ＲＲＣシグナリングを通して、各端末をｃｏｎｆｉｇｕｒｅしてもよい。基地局からリレー通信を指示された端末は、リレー端末として動作して、リレー通信を実施する

（２）システム情報としてブロードキャストする方法
また、基地局は、ＳＩＢ（Ｓｙｓｔｅｍ Ｉｎｆｏｒｍａｔｉｏｎ Ｂｌｏｃｋ）などのシステム情報としてリレー通信のＥｎａｂｌｅ／Ｄｉｓａｂｌｅの通知をブロードキャストしてもよい。例えば、基地局は、サイドリンク用のリソースプールの属性情報として、端末に対してリレー通信の可否を通知してもよい。リソースプール内の特定の領域においては必ずリレー通信を実施する、などの属性情報をシステム情報として通知してもよい。また、サイドリンクの使用周波数帯と紐付けしてリレー通信の可否を通知してもよい。Ｃａｒｒｉｅｒ Ｓｐｅｃｉｆｉｃ情報として端末にＰｒｅｃｏｎｆｉｇｕｒｅｄするなどである。

（３）Ｉｍｐｌｉｃｉｔに通知する方法
基地局は、端末に対するリソース割り当て時のリソース割り当て方法によって、Ｉｍｐｌｉｃｉｔにリレー通信の制御を行ってもよい。つまり、端末は、リレー通信用のリソースが基地局から割り当てられた時点で、リレー通信を実施すると判断する。

なお、３ＧＰＰの規格書ＴＳ ３６．２１３では、基地局によるサイドリンクのリソース割り当て方式としてモード１及びモード３が規格化されている。モード３ではリソースが準静的に割り当てられるが、モード１によるリソース割り当ては準静的でない。したがって、端末は、モード３によるリソース割り当て時に、上記のようにＩｍｐｌｉｃｉｔなリレー通信制御を行うことができる。

Ｂ−３−２．基地局から提供される情報
端末においてリレー通信の実施を判定するために、基地局から提供される情報として、例えば以下の（１）〜（５）を挙げることができる。そして、基地局は、これらの情報を、指示情報又は制御情報の場合と同様に、ＲＲＣシグナリングを通して通知したり、システム情報（ＳＩＢなど）として通知したりすることができる。

（１）サイドリンクのチャネル混雑度
ＣＢＲ（Ｃｈａｎｎｅｌ Ｂｕｓｙ Ｒａｔｉｏ）や、ＣＲ（Ｃｈａｎｎｅｌ Ｏｃｃｕｐａｎｃｙ Ｒａｔｉｏｎ）などの情報は、基地局側で計算されることがある。基地局は、端末にＣＢＲやＣＲの情報を端末に提供し、端末側ではこれらの情報に基づいてリレー通信の実施を判断することができる。例えば、チャネルが混雑していることが示されたときには、リレー端末は、サイドリンクの混雑防止を考慮して、リレー通信の実施を抑制するようにしてもよい。

（２）リレー通信すべきエリア情報
基地局は、端末に対して、リレー通信を実施すべきエリア情報、あるいはリレー通信を実施してもよいエリア情報を提供する。ここで言うエリア情報は、地理的な情報である。したがって、エリア情報を座標で指示してもよいし、ゾーンのような一定の区画の情報として通知してもよい。

（３）送信端末数
基地局は、所定のリソースプールにおいて存在する送信端末の台数を、端末に通知する。送信端末数は、所定のリソースプールにおける混み具合の指標として使用することができる。したがって、端末は、通知された送信端末数が多いときには、そのリソースプールにおける混雑を防止するために、リレー通信の実施を抑制するようにしてもよい。

（４）割り当てリソース数
基地局は、所定のリソースプールにおいて基地局が割り当てたリソース量の割合を、端末に通知する。割り当てリソース数は、所定のリソースプールにおける混み具合の指標として使用することができる。したがって、端末は、通知された割り当てリソース数が多いときには、そのリソースプールに余裕があると考えられることから、リレー通信を積極的に実施するようにしてもよい。

（５）基地局からの距離
基地局は、端末基地局間の距離を、端末に通知する。基地局から離れている端末は、Ｏｕｔ ｏｆ ｃｏｖｅｒａｇｅ領域が周辺に存在する可能性が高い。したがって、端末は、長い基地局間距離が通知されたときには、Ｏｕｔ ｏｆ ｃｏｖｅｒａｇｅ領域の端末をサポートするために、リレー通信を実施するように決定してもよい。なお、ＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）若しくはＧＮＳＳなどの位置情報を使って測距してもよい。あるいは、ＲＳＲＰ測定などを用いて基地局間の距離を推定するようにしてもよい。

以上をまとめると、基地局から端末に対して、リレー指示、エリア情報、並びにサイドリンク（チャネル）の混雑度という３種類の情報を提供することができる。

Ｂ−４．リレー端末以外の端末（Ｖ／Ｉ／Ｐ／Ｎ端末）から通知される情報
端末は、他端末から得られる情報を用いてリレー通信の実施判定を行うようにしてもよい。ここで言う他端末は、基地局（ｅＮＢ若しくはＥ−ＵＴＲＡＮ）以外の端末であり、ＶｅｈｉｃｌｅやＩｎｆｒａｓｔｒｕｃｔｕｒｅ（ＲＳＵ）、Ｐｅｄｅｓｔｒｉａｎなどの端末が想定される。これらの他端末とリレー端末との通信は、基本的にサイドリンクを用いて行われる。但し、ｅＮＢ経由の通信リンクを用いてもよい。

他端末から得られる情報には、リレー端末にパケットを送信した送信元端末から得られる情報と、（送信元端末に限定されない）リレー端末以外の端末から得られる情報に分けることができる。以下では、各々から得られる情報について説明する。

Ｂ−４−１．リレー端末にパケットを送信した送信元端末から得られる情報
パケットの送信元端末から得られる情報として、例えば以下の（１）〜（７）を挙げることができる。送信元端末は、ＳＣＩ（Ｓｉｄｅｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）若しくはパケットのＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）ヘッダに情報を記載して、リレー端末に提供することができる。

（１）送信したパケットのリレー通信の要否に関する情報
送信元端末は、ＳＣＩ若しくはパケットのＭＡＣヘッダにリレー通信の実施に関する情報を記載してもよい。リレー通信の要否に関して複数のレベルを定義して、送信元端末は送信パケットのリレー通信実施の必要性に応じたレベルをＳＣＩやＭＡＣヘッダに記載するようにしてもよい。

また、送信元端末は、リレー通信の要否に関する情報と併せて、送信パケットの有効時間や有効範囲、有効ホップ数などを指定するようにしてもよい。

また、送信元端末は、リレー通信の要否に関する情報を直接指示するのではなく、送信パケットをリレーすべき条件（若しくはリレーすべきでない条件）を通知するようにしてもよい。リレー端末は、送信パケットで通知された条件に基づいて、そのパケットについてリレー通信の実施判定を行う。また、リレー端末は、送信パケットで条件が通知される度に、リレー通信の実施判定のための条件を逐次更新するようにする。送信元端末は、例えば以下のような条件をＳＣＩやＭＡＣヘッダに記載するようにしてもよい。

・同じパケットＩＤのパケットを他端末から受信した場合には、リレーすべきではない。リレー通信を抑制することにより、パケットの氾濫を防ぐことにもなる。
・同じパケットＩＤのＡＣＫ信号を他端末から受信した場合には、リレーすべきでない。リレー通信を抑制することにより、パケットの氾濫を防ぐことにもなる。
・同じパケットＩＤのＮＡＣＫ信号を他端末から受信した場合には、リレーすべきである。送受信に失敗したパケットのリレー通信を実施することにより、システムの信頼性向上につながる。

リレー端末は、ブロードキャストやユニキャストといったパケットの属性情報を用いて、受信したパケットをリレーすべきかどうかを判断するようにしてもよい。送信元端末は、ＳＣＩ内に、パケットの種別といった情報を記載する。また、送信元端末は、ＳＣＩ内に記載する宛先情報を用いて、リレー通信の要否をＩｍｐｌｉｃｉｔに示してもよい。あるいは、リレー端末は、ＳＣＩ内に記載された宛先情報に基づいて、リレー通信の実施判定をＩｍｐｌｉｃｉｔに行ってもよい。例えば、リレー端末は、１つだけ宛先情報が含まれていた場合には、ユニキャストと判断してリレー通信を行わないが、宛先情報がない場合には、ブロードキャストと判断してリレー通信を行うようにしてもよい。

（２）パケットの優先度情報
送信元端末は、例えばＳＣＩ若しくはパケットのＭＡＣヘッダに、送信パケットの優先度情報を記載する。３ＧＰＰの規格書ＴＳ ３６．２１３に記載されている優先度情報を用いてもよい。同規格の優先度情報は本来リレー通信の優先度を規定するものではないが、セーフティパケットのような優先度の高いパケットは優先的にリレー通信を実施すべきであるということができる。

（３）パケットのリレーホップ数
送信元端末は、例えばＳＣＩ若しくはパケットのＭＡＣヘッダに、送信パケットのホップ数を記載する。

（４）パケットのリレー経路
送信元端末は、例えばＳＣＩ若しくはパケットのＭＡＣヘッダに、送信パケットのリレー経路を記載する。例えば、経路はＶ／Ｉ／Ｐ／Ｎのどれなのかを示す。また、パケットのリレー時間を併せて記載してもよい。

（５）パケットのリソースアロケーションモード情報
送信元端末は、例えばＳＣＩ若しくはパケットのＭＡＣヘッダに、送信パケット用に確保したリソースやリレー通信用に予約したリソースのリソースアロケーションモード情報を記載する。３ＧＰＰの規格書ＴＳ ３６．２１３では、基地局によるサイドリンクのリソース割り当て方式としてモード１及びモード３が記載され、また、端末によるサイドリンクのリソース割り当て方式としてモード２及びモード４が規格化されている。モード３によるリソース割り当てが準静的であるのに対し、モード１によるリソース割り当ては準静的ではない。また、モード４では端末がセンシングしてリソースを確保するのに対し、モード２では端末はセンシングせずにリソースを確保するので衝突する可能性がある。例えば、予約されたリレー通信用リソースがモード２であれば衝突する可能性があるのでリレー通信の実施を控えるが、モード１であれば衝突する可能性が低いのでリレー通信の実施を決定するようにしてもよい。

（６）パケットの生成時間、送信時間
送信元端末は、例えばＳＣＩ若しくはパケットのＭＡＣヘッダに、送信パケットの生成時間、送信時間を記載する。

（７）パケットの生成エリア、送信エリア
送信元端末は、例えばＳＣＩ若しくはパケットのＭＡＣヘッダに、送信パケットの生成エリア、送信エリアの情報を記載する。ここで言うエリアとは地理的な情報であり、座標で指示してもよいし、ゾーンのような一定の区画の情報として通知してもよい。

なお、上記（３）〜（７）の情報は、パケットの「鮮度」を示す情報ということもできる。例えば、上記（２）〜（７）のうち２以上のパラメータを組み合せてパケットの鮮度情報を定義し、送信元端末は、例えばＳＣＩ若しくはパケットのＭＡＣヘッダに、鮮度情報を記載する。パケットに関するパラメータから鮮度情報を導出する計算式は、基地局により設定されてもよいし、各ユーザ端末にＰｒｅ−ｃｏｆｉｇｕｒａｔｉｏｎされてもよい。情報技術の分野においては、鮮度が高いほど意味のある、ということができる。鮮度が高いパケットは、例えば情報エントロピーが高いものとして定義される（確率の低い情報ほど、高いエントロピーを示す）。したがって、リレー端末は、鮮度情報若しくは情報エントロピーに基づいてパケットのリレー通信の実施判定を行うようにすることで、より意味のある情報を持ったパケットをリレーすることが可能になる。

なお、上記（３）〜（７）のパラメータから鮮度情報を導出する計算式は、基地局により設定されてもよいし、各ユーザ端末にＰｒｅ−ｃｏｆｉｇｕｒａｔｉｏｎされてもよい。例えば、基地局からユーザ端末へ、ＲＲＣシグナリングやシステム情報（ＳＩＢ）として、このような計算式が通知される。

Ｂ−４−２．リレー端末以外から得られる情報
リレー端末以外から得られる情報として、例えば以下の（１）〜（３）のような、サイドリンクのチャネル状況を示す情報を挙げることができる。ここで言うリレー端末以外の端末には、リレー端末にパケットを送信した送信元端末と、送信元端末ではないリレー端末以外の端末とを含むものとする。

（１）サイドリンクのチャネル混雑度
リレー端末以外の端末で測定されたＣＢＲやＣＲなどの情報が、サイドリンクでリレー端末にシェアされる。例えば、チャネルが混雑していることが示されたときには、リレー端末は、混雑防止を考慮して、リレー通信の実施を抑制するようにしてもよい。

（２）サイドリンクのチャネル状態
リレー端末以外の端末から、ＲＳＲＰ、ＲＳＳＩ、ＲＳＲＱなどの情報を通知してもらう。測定者端末の位置情報も含めて通知してもらうとよい。例えば、チャネルが混雑していると、受信電力すなわちＲＳＳＩが増大することから、リレー端末は、リレー通信の実施を控えるように判断してもよい。

（３）他端末におけるＡＣＫ／ＮＡＣＫ情報
リレー端末以外の端末から、これまで送信してきたパケットのＡＣＫ／ＮＡＣＫの統計情報などを通知してもらう。例えば、ＮＡＣＫの割合が所定の閾値以上となるエリアでは、通信が成立していないので、リレー通信を実施すると判定する。あるいは、ＮＡＣＫの割合が所定の閾値以上となるエリアでは、チャネルが混雑していることが推定されるので、リレー通信の実施を控えると判断することもできる。

Ｂ−５．リレー端末自身で得られる情報
リレー端末自身から得られる情報として、例えば以下の（１）〜（４）のような情報を挙げることができる。

（１）サイドリンクのチャネル混雑度・占有度
リレー端末自身でＣＢＲやＣＲなどの情報を測定する。例えば、チャネルが混雑していることが示されたときには、リレー端末は、サイドリンクの混雑防止を考慮して、リレー通信の実施を抑制するようにしてもよい。

（２）サイドリンクのチャネル状態
リレー端末自身で、ＲＳＲＰ、ＲＳＳＩ、ＲＳＲＱなどのサイドリンクにおけるチャネル状態を測定する。例えば、チャネルが混雑していると、受信電力すなわちＲＳＳＩが増大することから、リレー端末は、リレー通信の実施を控えるように判断してもよい。

（３）ＡＣＫ／ＮＡＣＫ情報
他端末から送信されてきたパケットのＡＣＫ／ＮＡＣＫの情報を自身でデコードする。例えば、ＮＡＣＫの割合が所定の閾値以上となるエリアでは、通信が成立していないので、リレー端末は、リレー通信を実施すると判定する。あるいは、ＮＡＣＫの割合が所定の閾値以上となるエリアでは、チャネルが混雑していることが推定されるので、リレー端末は、リレー通信の実施を控えると判断することもできる。

（４）端末位置情報
例えばＧＰＳ若しくはＧＮＳＳなどの位置情報を使って、リレー端末自身の位置情報を測距する。そして、リレー端末は、リレー端末自身がリレー通信を実施すべきエリア、あるいはリレー通信を実施してもよいエリアにいるかどうかに基づいて、リレー通信の実施判定を行う。

Ｂ−６．リレー通信の実施判定処理
上記では、リレー端末がリレー通信の実施判定に使用する情報が、基地局やリレー端末以外の端末から通知され、又はリレー端末自身で取得することを説明してきた。また、これらの取得方法により取得される情報は、上述したようにさまざまなパラメータからなるが、以下の（１）〜（５）にまとめることができる。

（１）基地局からのリレー指示
（２）パケットの優先度
（３）サイドリンクの混雑度
（４）エリア情報
（５）パケットの鮮度

上記のパラメータのうち、（１）基地局からのリレー指示は絶対であり、基地局からリレーが指示されたリレー端末は必ずリレー通信を実施する。これに対し、（２）〜（５）のパラメータは、必須ではないが昇り順で重要度が高いものとする。リレー端末は、例えば図１４にフローチャートの形式で示す処理手順に従って、パケットのリレー通信の実施判定を行うことができる。

リレー端末は、まず基地局からリレー通信のＥｎａｂｌｅの指示を受けたかどうかをチェックする（ステップＳ１４０１）。そして、基地局からリレー通信のＥｎａｂｌｅの指示を受けている場合には（ステップＳ１４０１のＹｅｓ）、リレー端末は、リレー通信を実施して（ステップＳ１４０２）、本処理を終了する。

また、リレー端末は、基地局からリレー指示を受けていない場合には（ステップＳ１４０１のＮｏ）、受信したパケットに対して送信元端末から指定されている優先度をチェックする（ステップＳ１４０３）。

ここで、優先度が高いパケットの場合には（ステップＳ１４０３のＹｅｓ）、より低い混雑度の閾値ＴＨ１を設定して、リレー通信に使用するサイドリンクのチャネル混雑度（ＣＢＲ若しくはＣＲ）を閾値ＴＨ１と大小比較する（ステップＳ１４０４）。また、優先度が低いパケットの場合には（ステップＳ１４０３のＮｏ）、より高い混雑度の閾値ＴＨ２を設定して（但し、ＴＨ２＞ＴＨ１）、リレー通信に使用するサイドリンクのチャネル混雑度（ＣＢＲ若しくはＣＲ）を閾値ＴＨ２と大小比較する（ステップＳ１４０７）。

そして、サイドリンクのチャネル混雑度（ＣＢＲ若しくはＣＲ）が、閾値ＴＨ１以下のとき（ステップＳ１４０４のＹｅｓ）、又は、閾値ＴＨ２以下のとき（ステップＳ１４０７のＹｅｓ）には、リレー端末がリレー通信を実施すべきエリア、あるいはリレー通信を実施してもよいエリアにいるかどうかをさらにチェックする（ステップＳ１４０５）。

リレー端末がリレー通信を実施すべきエリア、あるいはリレー通信を実施してもよいエリアにいるときには（ステップＳ１４０５のＹｅｓ）、続いて、パケットの鮮度をチェックする（ステップＳ１４０６）。そして、リレー端末がリレー通信を実施可能な状態にあり、且つ、パケットの鮮度がよい場合には（ステップＳ１４０６のＹｅｓ）、リレー端末は、リレー通信を実施して（ステップＳ１４０２）、本処理を終了する。

他方、リレー通信に使用するサイドリンクのチャネル混雑度（ＣＢＲ若しくはＣＲ）が閾値ＴＨ１を超え（ステップＳ１４０４のＮｏ）、又は、閾値ＴＨ２を超えるため（ステップＳ１４０７のＮｏ）、リレー通信を抑制してチャネルの混雑を防止すべきとき、リレー端末が実施すべきエリア又はリレー通信を実施してもよいエリアにおらず、リレー通信を実施できる状況にないとき（ステップＳ１４０５のＮｏ）、あるいは、パケットの鮮度が落ちてしまい（ステップＳ１４０６のＮｏ）、リレー通信する必要性が低いときには、リレー端末は、リレー通信を実施しないで（ステップＳ１４０８）、本処理を終了する。

図１４に示した実施判定の処理手順のうち、ステップＳ１４０１、Ｓ１４０３〜Ｓ１４０６は、例えば図１３に示したフローチャートのステップＳ１３０１内で実施される処理に相当する。

但し、リレー端末によるリレー通信の実施判定処理は図１４に示した処理手順に限定されるものではなく、実装次第で適宜修正又は変更されることが想定される。例えば、図１４に示した処理手順では、リレー端末は、基地局からリレー通信のＥｎａｂｌｅの指示を受けたときには必ずリレー通信を実施するように判定するが、このような判定処理には限定されない。リレー端末は、基地局からリレー通信のＥｎａｂｌｅの指示を受けていないとき（若しくは、Ｄｉｓａｂｌｅの指示を受けたとき）には、決してリレー通信を実施しないこととする判定処理や、Ｅｎａｂｌｅの指示を受けた場合においてチャネルの混雑度やパケットの優先度など他の条件に応じてリレー通信の実施を決定する、といったような判定処理も想定される。

Ｃ．リレー端末によるリレーパケットの送信方法
上述したように、リレー端末は、パケットを受信したときにリレー通信の実施判定を行う。そして、実施すると判定された場合には、リレー端末は、リレー通信のための送信処理を実施する。

Ｃ−１．変更パラメータ
リレー端末は、リレー通信の実施に際し、以下のパラメータを変更する。

・使用するリソース
・使用するリソースプール
・使用する周波数キャリア
・送信電力
・ＲＶ（Ｒｅｄｕｎｄａｎｃｙ Ｖｅｒｓｉｏｎ）情報
・ＭＩＭＯ（Ｍｕｌｔｉｐｌｅ Ｉｎｐｕｔ Ｍｕｌｔｉｐｌｅ Ｏｕｔｐｕｔ）の適用、ビームフォーミングの適用
・送信ダイバーシティ適用
・ＣｏＭＰ（Ｃｏｏｒｄｉｎａｔｅｄ Ｍｕｌｔｉ−ｐｏｉｎｔ：高データレートのカバレッジ拡大や、セル端におけるスループット改善を目的とした多地点協調）の適用
・パケット優先度情報
・パケット情報エントロピー（鮮度情報）
・ＭＡ ｓｉｇｎａｔｕｒｅ

Ｃ−２．リレー通信用のリソース確保方法
リレー端末がリレー通信を実施することを決定したとき、リレー通信に用いるリソースを確保する必要がある。ここでは、リレー端末がリレー通信に用いるリソースを確保する方法について説明する。

Ｃ−２−１．リレー端末自身がリレー通信用リソースを確保
リレー通信を実施することを決定したリレー端末が、自らリレー通信用のリソースを確保する。

リレー端末は、リレーパケットの送信時にセンシングを実施して、リレー通信用のリソースを確保する。

また、リレー端末は、センシング時に、リレー通信用のリソースということを考慮してリソース選択を実施する。つまり、リレー用のリソースに与えられる優先度レベルを用いてリソースを確保する。

Ｃ−２−２．送信元端末がリレー通信用リソースを予約
リレー端末にパケットを送信した直近の送信元端末が、リレー通信用のリソースを予約する。

送信元端末は、ＳＣＩなどのパケット制御情報の中に、リレー通信用のリソース予約情報を含めておくことができる。リレー端末は、事前に予約されたリレー通信用リソースを使って、リレー通信を実施することができる。

図１５には、送信元端末がリレー通信用のリソースを予約してリレー通信を行う通信シーケンス例を示している。

送信元端末は、トラフィックが発生すると（ＳＥＱ１５０１）、センシングを用いてサイドリンクによりリレー端末へのデータ送信を行うためのリソースを、サイドリンク用のリソースプールの中から選択する（ＳＥＱ１５０２）。このとき、送信元端末は、サイドリンク用のリソースプール内で、リレー端末のリレー通信用のリソースを併せて選択する。このようにして、送信元端末は、自分のデータ送信用のリソースと、リレー端末のリレー通信用リソースをそれぞれ確保する（ＳＥＱ１５０３）。

その後、送信元端末は、パケット制御情報（ＳＣＩ）を用いて、データ送信用リソースのリソース位置と、リレー通信用リソースの予約情報をリレー端末に通知し、続いて、ＳＣＩで通知したリソースを使ってリレー端末へのデータ送信を行う（ＳＥＱ１５０４）。

これに対し、リレー端末は、ＳＣＩで通知されたデータ送信用のリソース位置にて送信元端末からの送信データを受信し、復号処理する（ＳＥＱ１５０５）。そして、リレー端末は、例えば図１３又は図１４に示したリレー判定の実施判定処理を実施する（ＳＥＱ１５０６）。

ここでは、説明の便宜上、リレー端末はリレー通信を実施することを決定したとする。したがって、リレー端末は、送信元端末からＳＣＩで通知されたリレー通信用のリソースを使って、送信先端末へのリレー通信を実施する（ＳＥＱ１５０７）。このとき、リレー端末は、パケット制御情報（ＳＣＩ）を用いて、リレー通信用リソースのリソース位置を送信先端末に通知する。また、リレー端末は、上記と同様に、送信先端末のためのリレー通信用リソースを予約して、ＳＣＩで併せて通知するようにしてもよい。

また、送信元端末は、Ｒｅｓｅｒｖａｔｉｏｎ ｉｎｄｉｃａｔｏｒなどを用いて、リレー通信リソースの通知を行ってもよい。ここで、Ｒｅｓｅｒｖａｔｉｏｎ ｉｎｄｉｃａｔｏｒとは、例えばあるリソースを用いてデータ送信したときに、その送信データのリソースを基準として所定の時間オフセット値だけ時間方向に離れたリソース位置をリレー通信用に予約したことを示すビット（すなわち、１ビットで基準のリソースを繰り返し使用することを示すもの）である。

図１６には、リレー通信用リソースの割り当て例を示している。但し、同図において、横軸を時間軸とし、縦軸を周波数軸とする。送信元端末は、サイドリンクにおいて、ＳＣＩを送信した後に、リレー端末にデータを送信する。ＳＣＩ内には、参照番号１６０１で示す、データリソースの時間周波数領域を指示する情報と、参照番号１６０２で示す、リレー通信用リソースを予約情報であるＲｅｓｅｒｖａｔｉｏｎ ｉｎｄｉｃａｔｏｒが含まれている。また、参照番号１６０３で示す、ＳＣＩで指示されたデータ送信用リソースと予約されたリレー通信用リソースの時間オフセット値は、規定値であってもよいし、ＳＣＩ内で通知してもよい。

Ｃ−２−３．ハイブリッドなリレー通信用リソースの確保方法

送信元端末によりリレー通信用リソースを予約する方法と、リレー端末が自らリレー通信用リソースを確保する方法を組み合わせる。具体的には、リレー端末は、基本的には送信元端末が予約したリレー通信用リソースを使用するが、予約されたそのリソースを再センシングして使用できないときには、自らリレー通信用リソースを確保する。

図１７には、リレー端末がハイブリッドなリレー通信用リソースの確保方法によりリレー通信を実施するための処理手順をフローチャートの形式で示している。図示の処理手順は、リレー端末として動作する通信装置の処理部２５０が主導して実施される。

リレー端末は、送信元端末からデータパケットを受信すると（ステップＳ１７０１）、リレー通信の実施判定を行う。ここでは、説明の便宜上、リレー端末はリレー通信を実施すると決定したものとする。

また、リレー端末は、そのデータ送信の際に送信元端末から受信したＳＣＩから、リレー通信用に予約されたリソースの位置情報を取得する（ステップＳ１７０２）。

次いで、リレー端末は、ステップＳ１７０２でＳＣＩから取得したリレー通信用リソースの再センシングを実施する（ステップＳ１７０３）。そして、リレー端末は、ステップＳ１７０２で取得したリレー通信用リソースの再センシングすることができた場合には（ステップＳ１７０４のＹｅｓ）、送信元端末により予約されたそのリレー通信用リソースをそのまま使って、ステップＳ１７０１で受信したパケットのリレー通信を実施する（ステップＳ１７０５）。

一方、リレー端末は、送信元端末により予約されたリレー通信用リソースを再センシングすることができなかった場合には（ステップＳ１７０４のＮｏ）、自らリレー通信用リソースのセンシングを実施する（ステップＳ１７０６）。

ここで、リレー端末は、自らリレー通信用リソースを確保することができた場合には（ステップＳ１７０７のＹｅｓ）、そのリソースを使って、ステップＳ１７０１で受信したパケットのリレー通信を実施する（ステップＳ１７０８）。

また、リレー端末は、自らもリレー通信用リソースを確保することができなかった場合には（ステップＳ１７０７のＮｏ）、リレー通信を行わない（ステップＳ１７０９）。

Ｃ−２−４．基地局によるリレー通信用リソースの確保方法
基地局がリレー通信用のリソース割り当てを行うようにしてもよい。例えば、基地局からリレー端末に対して、Ｕｕリンク（基地局と端末間の無線区間）経由のＤＣＩ（Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）で、割り当てたリレー通信用リソースのＧｒａｎｔ（許可）が通知される。

図１８には、基地局がサイドリンクにおけるリレー通信用リソースの割り当てを行う通信シーケンス例を示している。なお、同図中の送信元端末及びリレー端末はそれぞれ異なる車両に搭載された通信装置（図９を参照のこと）であり、基地局はｅＮＢ又はＲＳＵ（図１０を参照のこと）に相当する。

送信元端末は、トラフィックが発生すると（ＳＥＱ１８０１）、接続先の基地局に対して、スケジューリングリクエストによるサイドリンクのためのリソースを要求する（ＳＥＱ１８０２）。ここでは、送信元端末は、データ送信のためのリソースに加えて、リレー通信用リソースを要求する。

基地局は、送信元端末からのサイドリンクのためのリソース要求に応答して、データ送信のためのリソース、及び、リレー通信用リソース割り当てを行う（ＳＥＱ１８０３）。そして、基地局は、送信元端末とリレー端末の各々に対し、ＤＣＩ経由で、割り当てたリソースを通知する（ＳＥＱ１８０４）。

その後、送信元端末は、サイドリンクによるデータ送信に割り当てられたリソースを使って、リレー端末へのデータ送信を行う（ＳＥＱ１８０５）。これに対し、リレー端末は、送信元端末からの送信データを受信し復号処理する（ＳＥＱ１８０６）。そして、リレー端末は、例えば図１３又は図１４に示したリレー判定の実施判定処理を実施する（ＳＥＱ１８０７）。

ここでは、説明の便宜上、リレー端末はリレー通信を実施することを決定したとする。送信元端末は、サイドリンクによるデータ送信に割り当てられたリソースを使って、送信先端末（図示しない）へのリレー通信を行う（ＳＥＱ１８１１）。

なお、リレー端末は、リレー通信の際に、上記と同様に基地局に対して、次のリレー通信用リソースを要求するようにしてもよい（ＳＥＱ１８０８）。この場合、基地局は、リレー端末からのリソース要求に応答して、リレー通信用リソース割り当てを行うと（ＳＥＱ１８０９）、リレー端末とその送信先端末（図示しない）の各々に対し、ＤＣＩ経由で、割り当てたリソースを通知する（ＳＥＱ１８１０）。

Ｃ−３．パケットの氾濫を防ぐ対応
リレー通信が制限なく行なわれると、無線伝送路上にパケットが氾濫して、チャネル（サイドリンク）の混雑が発生してしまうおそれがある。リレー通信は必要な時に必要な量だけ実施されるべきである。ここでは、パケットの氾濫を防ぐための幾つかの方法について説明する。

Ｃ−３−１．パケットの情報エントロピー（鮮度情報）を用いた方法
パケットの鮮度若しくは情報エントロピーに応じて、最終的なリレーの実施確率を調整する。なお、パケットの情報エントロピーは、上述したようにパケットの鮮度を示す１つ又は複数のパラメータの組み合わせに基づいて定義することができるが、リレー通信の制限に用いる情報エントロピーは特定の定義には限定されないものとする。

リレー端末は、送信元端末からパケットを受信したときに、例えば図１３又は図１４に示した処理手順に従ってリレー通信の実施判定を行う。そして、リレー端末は、リレー通信を実施することを決定した場合であっても、実際にリレー通信を実施するかどうかを所定の確率に応じて判断する。例えば、受信したパケットの鮮度がよければ、リレー端末は、リレー通信を実施すると判定すると、１００％に近い確率で最終的にリレー通信を実施する。他方、鮮度が落ちているパケットを受信したときには、リレー端末は、リレー通信を実施すると判定した場合であっても、例えば５０％を下回る低い確率でしか、最終的にリレー通信を実施しないようにする。

なお、パケットの鮮度情報と確率情報との関係は、基地局から設定されるか、又は端末自身にＰｒｅ−ｃｏｆｉｇｕｒａｔｉｏｎされてもよい。ここで言うＰｒｅ−ｃｏｆｉｇｕｒａｔｉｏｎとは、例えば端末の出荷時に設定することに相当する（但し、基地局が書き換えを行うことも想定される）。前者の場合、基地局は、配下のリレー端末におけるリレー通信の実施確率を調整することで、自セル内のリソースプールにおけるリレーパケットの占有率を統括的にコントロールすることができる。基地局は、例えばＲＲＣシグナリングやシステム情報（ＳＩＢ）として、各リレー端末に対してリレー通信の実施確率に関する情報を通知することができる。

また、パケットの鮮度情報と確率情報との関係を、周波数特異的に決定してもよい。例えば、リレー端末は、パケットの鮮度又は情報エントロピーを表す数値とのリレー通信の実施確率とのマッピングテーブルを用いて、リレー通信の対象となるパケットから求められた鮮度からリレー通信の実施確率に変換するようにしてもよい。このようなマッピングテーブルを用いれば、例えば鮮度レベルが１といった情報エントロピーが高いパケットの場合、リレー通信の実施確率を８０％といった高確率に変換する。また、パケットの優先度情報に応じて複数のマッピングテーブルを設定してもよい。例えば同じパケットの鮮度情報（若しくは情報エントロピー）であっても、パケットの優先度が高い場合にはより高い実施確率に変換するマッピングテーブルを設定するようにしてもよい。

サイドリンクのチャネル混雑度に応じてリレー通信の実施判定を行うべきことは、Ｂ−４−２項で既に説明した通りである。例えば、ＣＢＲやＣＲなどの情報によってチャネルが混雑していることが示されているときには、リレー端末は、混雑防止を考慮して、リレー通信の実施を抑制するべきである。そこで、ＣＢＲ又はＣＲに応じて、複数のマッピングテーブルを設定してもよい。例えば、同じパケットの鮮度情報（若しくは情報エントロピー）であっても、ＣＢＲやＣＲがチャネルの混雑を示す場合にはより低い実施確率に変換するマッピングテーブルを設定するようにしてもよい。

また、パケットの鮮度若しくは情報エントロピーに応じて、最終的なリレーの実施確率を調整する場合、パケットの鮮度情報を更新するようにしてもよい。Ｂ−４−１項で挙げた、パケットに関するいくつかのパラメータの１つ又は複数の組み合わせに用いて、パケットの鮮度情報を更新する。

なお、パケットに関するパラメータから鮮度情報を導出する計算式は、基地局により設定されてもよいし、各ユーザ端末にＰｒｅ−ｃｏｆｉｇｕｒａｔｉｏｎされてもよい。例えば、基地局からユーザ端末へ、ＲＲＣシグナリングやシステム情報（ＳＩＢ）として、このような計算式が通知される。

Ｃ−３−２．パケットから得られる情報に基づくリレー通信の実施確率の調整
既にＢ−４−１項で説明したように、リレー端末にパケットを送信した送信元端末から、パケットに関するいくつかのパラメータを取得することができる。これらのパラメータの上限値を用いて、リレー端末におけるリレー通信の実施確率を変化させてもよい。

例えば、パケットのリレーホップ数の上限が５に設定されている場合には、パケットに記載されたホップ数カウントが５を超える場合には、リレー端末は、リレー通信の実施確率を２０％など低い確率に設定する。

このような、パラメータの上限値と実施確率との関係は、基地局より設定されてもよいし、端末にＰｒｅ−ｃｏｆｉｇｕｒａｔｉｏｎされてもよい。基地局により設定される場合には、例えば、基地局からユーザ端末へ、ＲＲＣシグナリングやシステム情報（ＳＩＢ）として通知される。

Ｃ−３−３．パケットの伝送状況に応じたリレー通信の実施確率の調整
リレー端末は、リレー通信の対象となるパケットを受信した回数や、他端末からのＡＣＫ／ＮＡＣＫ情報を用いて、リレー通信の実施確率を変化させてもよい。すなわち、リレー端末は、対象パケットの受信回数やＡＣＫ／ＮＡＣＫ情報など、パケットの伝送状況を示す各パラメータに閾値を決めるとともに、閾値を超えたパラメータとリレー通信の実施確率を設定する。

例えば、対象パケットを他端末から３回受信した場合にはリレー通信の実施確率を１０％にするなど、リレー端末は、パケットの受信回数が閾値を超えるとリレー通信の実施確率を抑制するようにしてもよい。

パケットの伝送状況を示すパラメータ毎の閾値とリレー通信の実施確率との関係は、基地局により設定されてもよいし、各ユーザ端末にＰｒｅ−ｃｏｆｉｇｕｒａｔｉｏｎされてもよい。例えば、基地局からユーザ端末へ、ＲＲＣシグナリングやシステム情報（ＳＩＢ）として、閾値とリレー通信の実施確率との関係が通知される。

Ｃ−３−４．パケットの氾濫防止対策の実施タイミング
上述したように、リレー端末は、リレー通信の対象となるパケットの鮮度情報や、パケットやその伝送状況に関するパラメータに応じて、リレー通信の実施確率を調整することで、パケットの氾濫を防止する対策をとることができる。リレー端末は、リレー通信の実施判定を行った直後に実施確率を設定してもよい。また、リレー端末がリレー通信の実施判定を行う条件の一部として、実施確率を設定してもよい。例えば、図１４に示したフローチャートにおいて、ステップＳ１４０２の直前に、実施確率に応じたさあ周的なリレー通信の実施判定処理を行うようにしてもよい。

Ｄ．実施例
ここでは、リレー端末が基地局からの指示によりリレー通信を行う場合を例にとって、リレー通信の実施例について説明する。

まず、リレー通信実施のための１つ目の条件として、基地局からリレー端末へ、リレー通信のＥｎａｂｌｅの指示が設定される。

次に、リレー通信実施のための２つ目の条件として、リレー端末の端末Ｃａｐａｂｉｌｉｔｙ情報を設定する。すなわち、リレー端末がリレー通信を実施できるＣａｐａｂｉｌｉｔｙであるかどうかをリレー通信実施の条件とする。

次に、リレー端末は、他の端末からパケットを受信すると、そのパケットについてリレー通信を実施するかどうかを判定する。上述したように、リレー端末は基地局からリレー通信のＥｎａｂｌｅの指示を受け、且つ、リレー端末自身はリレー通信を行えるＣａｐａｂｉｌｉｔｙ情報が設定されている。したがって、リレー端末は、これらの情報に基づいて、リレー通信を実施すると判定する。

その後、リレー端末は、リレー通信実施のための送信準備を行う。リレー通信のためには、通信用のリソースを確保する必要がある。ここで、受信パケットのＳＣＩに記載されている情報を参照し、送信元端末がリレー通信用リソースを予約しているかどうかを確認する。そして、リレー通信用リソースが予約されている場合には、リレー端末は、自らリソースを確保する必要がなく、送信元端末によって予約されたリソースを用いて、リレー通信を実施することができる。

また、リレー端末は、リレー通信を開始する直前に、実施確率の調整をさらに行う。受信したパケットの鮮度レベルが２であったとし、基地局より与えられた鮮度レベルと実施確率のマッピングテーブルを参照して、鮮度レベル２を実施確率８０％に変換する。したがって、リレー端末は、確率８０％でリレー通信を最終的に実施することになる。

そして、リレー端末は、乱数を用いて判定して結果、２０％の確率となった。このため、リレー端末は、最終的にリレー通信の実施を取りやめる。リレー通信のためにリソースが使用されることがないので、リレー端末は、周辺端末に対してのリソースのリリースメッセージを通知する。

以上、特定の実施形態を参照しながら、本明細書で開示する技術について詳細に説明してきた。しかしながら、本明細書で開示する技術の要旨を逸脱しない範囲で当業者が該実施形態の修正や代用を成し得ることは自明である。

本明細書では、Ｖ２Ｘ通信におけるサイドリンク通信に関する実施形態を中心に説明してきたが、本明細書で開示する技術の要旨はこれに限定されるものではない。すなわち、本明細書で開示する技術は、Ｖ２Ｘ通信以外のユースケースにも同様に適用することが可能である。本明細書で開示する技術は、Ｄ２Ｄ（Ｄｅｖｉｃｅ ｔｏ Ｄｅｖｉｃｅ）通信やＭＴＣ（Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）などさまざまなタイプの端末間直接通信に適用することができる。また、本明細書で開示する技術は、Ｍｏｖｉｎｇ ｃｅｌｌ（移動式基地局）やＲｅｌａｙ通信などへも適用することができる。

要するに、例示という形態により本明細書で開示する技術について説明してきたのであり、本明細書の記載内容を限定的に解釈するべきではない。本明細書で開示する技術の要旨を判断するためには、特許請求の範囲を参酌すべきである。

なお、本明細書の開示の技術は、以下のような構成をとることも可能である。
（１）基地局の配下で端末として動作する通信装置であって、
無線信号を送受信する通信部と、
前記通信部による、所定のリソースプールを用いたデータの送信を制御する制御部と、
を具備し、
前記制御部は、パケット受信時において、前記基地局から通知される情報、他端末から通知される情報、又は、前記端末自身から得られる情報のうち少なくとも１つに基づいて、前記所定のリソースプール内でのパケットのリレー通信の実施を制御する、
通信装置。
（１−１）前記通信部は、前記基地局から割り当てられたサイドリンク用の前記所定のリソースプールを用いて無線信号の送受信を行う、
上記（１）に記載の通信装置。
（２）前記制御部は、前記基地局から通知される、リレー通信を実施すべきエリア又は実施してもよいエリアを示す情報に基づいて、リレー通信の実施を判定する、
上記（１）に記載の通信装置。
（２−１）エリアは、地理的な座標情報、又は、ゾーンの識別情報で示される、
上記（２）の記載の通信装置。
（３）前記制御部は、前記基地局からの、リレー通信の実施の指示又はリレー通信の停止の指示に基づいて、リレー通信の実施を判定する、
上記（１）又は（２）のいずれかに記載の通信装置。
（３−１）前記制御部は、前記基地局からのＲＲＣシグナリング、又はＳＩＢのブロードキャストにより、リレー通信の実施の指示又はリレー通信の停止の指示を受け取る、
上記（３）に記載の通信装置。
（３−２）前記制御部は、前記基地局から通知されるチャネル混雑度に関する情報に基づいて、リレー通信の実施を判定する、
上記（３）に記載の通信装置。
（３−３）前記制御部は、前記基地局から通知される、前記所定のリソースプール内に存在する送信端末数に基づいて、リレー通信の実施を判定する、
上記（３）に記載の通信装置。
（３−４）前記制御部は、前記基地局から割り当てられたリソース量に基づいて、リレー通信の実施を判定する、
上記（３）に記載の通信装置。
（３−５）前記制御部は、前記基地局からの距離に基づいて、リレー通信の実施を判定する、
上記（３）に記載の通信装置。
（４）前記制御部は、前記パケットの送信元端末から得られる、前記パケットの送信用リソースの割り当て方法に関する情報に基づいて、リレー通信の実施を判定する、
上記（１）乃至（３）のいずれかに記載の通信装置。
（５）前記制御部は、前記パケットの送信元端末から得られる前記パケットの優先度情報に基づいて、リレー通信の実施を判定する、
上記（１）乃至（４）のいずれかに記載の通信装置。
（６）前記制御部は、前記パケットの送信元端末から得られる前記パケットの鮮度情報に基づいて、リレー通信の実施を判定する、
上記（１）乃至（５）のいずれかに記載の通信装置。
（７）前記制御部は、前記パケットの送信元端末から得られる、前記パケットのリレーホップ数、前記パケットのリレー経路、前記パケットの生成時間又は送信時間、前記パケットの生成エリア又は送信エリアのうち少なくとも１つから求められる前記鮮度情報に基づいて、リレー通信の実施を判定する、
上記（６）に記載の通信装置。
（８）前記制御部は、前記パケットの通信に用いるチャネルの混雑度、前記チャネルの状態、前記パケットの再送情報、又は、前記端末自身の位置情報のうち少なくとも１つに基づいて、リレー通信の実施を判定する、
上記（１）乃至（７）のいずれかに記載の通信装置。
（９）前記制御部は、リレー通信用のリソースの確保をさらに制御する、
上記（１）乃至（８）のいずれかに記載の通信装置。
（１０）前記制御部は、前記リソースプール内でのリレー通信用のリソースのセンシングを制御する、
上記（９）に記載の通信装置。
（１１）前記制御部は、前記パケットの送信元端末が予約したリレー通信用のリソースを用いた前記パケットのリレー通信の実施を制御する、
上記（９）に記載の通信装置。
（１２）前記制御部は、前記パケットの送信元端末が予約したリレー通信用のリソースをセンシングして使用できないときには、自らリレー通信用のリソースのセンシングを制御する、
上記（１１）に記載の通信装置。
（１３）前記制御部は、前記基地局が確保したリレー通信用のリソースを用いた前記パケットのリレー通信の実施を制御する、
上記（９）に記載の通信装置。
（１４）前記制御部は、前記パケットのリレー通信の実施確率をさらに制御する、
上記（１）乃至（１３）のいずれかに記載の通信装置。
（１５）前記制御部は、前記パケットの鮮度情報に応じて前記パケットのリレー通信の実施確率を制御する、
上記（１４）に記載の通信装置。
（１６）前記制御部は、前記基地局から設定され、又は前記端末自身にあらかじめ設定された、パケットの鮮度情報と実施確率との関係に基づいて、前記パケットのリレー通信の実施確率を制御する、
上記（１５）に記載の通信装置。
（１７）前記制御部は、前記パケットの優先度情報に対応したパケットの鮮度情報と実施確率との関係に基づいて、前記パケットのリレー通信の実施確率を制御する、
上記（１５）又は（１６）のいずれかに記載の通信装置。
（１８）前記制御部は、リレー通信に使用するチャネルの混雑度に対応したパケットの鮮度情報と実施確率との関係に基づいて、前記パケットのリレー通信の実施確率を制御する、
上記（１５）乃至（１７）のいずれかに記載の通信装置。
（１９）前記制御部は、前記パケットの送信元端末から得られる情報に基づいて、前記パケットの鮮度情報を更新する、
上記（１５）乃至（１８）のいずれかに記載の通信装置。
（２０）基地局の配下で端末として動作する通信装置における通信方法であって、
所定のリソースプールにおいてパケットを受信するステップと、
前記基地局から通知される情報、他端末から通知される情報、又は、前記端末自身から得られる情報のうち少なくとも１つに基づいて、前記パケットのリレー通信の実施を制御するステップと、
を有する通信方法。

１０…ＵＥ（ユーザ携行）、２０…ＵＥ（車両搭載）
２２…移動体（車両）、３０…ｅＮＢ、４０…ＧＮＳＳ衛星
５０…ＲＳＵ
１１０…アンテナ部、１２０…無線通信部
１３０…ＧＮＳＳ信号処理部、１４０…記憶部、１５０…処理部
２１０…アンテナ部、２２０…無線通信部
２３０…ＧＮＳＳ信号処理部、２４０…記憶部、２５０…処理部
３１０…アンテナ部、３２０…無線通信部
３３０…ネットワーク通信部、３４０…記憶部、３５０…処理部
５１０…アンテナ部、５２０…無線通信部
５３０…記憶部、５４０…処理部

Claims (20)

1. 基地局の配下で端末として動作する通信装置であって、
   無線信号を送受信する通信部と、
   前記通信部による、所定のリソースプールを用いたデータの送信を制御する制御部と、
   を具備し、
   前記制御部は、パケット受信時において、前記基地局から通知される情報、他端末から通知される情報、又は、前記端末自身から得られる情報のうち少なくとも１つに基づいて、前記所定のリソースプール内でのパケットのリレー通信の実施を制御する、
   通信装置。
2. 前記制御部は、前記基地局から通知される、リレー通信を実施すべきエリア又は実施してもよいエリアを示す情報に基づいて、リレー通信の実施を判定する、
   請求項１に記載の通信装置。
3. 前記制御部は、前記基地局からの、リレー通信の実施の指示又はリレー通信の停止の指示に基づいて、リレー通信の実施を判定する、
   請求項１に記載の通信装置。
4. 前記制御部は、前記パケットの送信元端末から得られる、前記パケットの送信用リソースの割り当て方法に関する情報に基づいて、リレー通信の実施を判定する、
   請求項１に記載の通信装置。
5. 前記制御部は、前記パケットの送信元端末から得られる前記パケットの優先度情報に基づいて、リレー通信の実施を判定する、
   請求項１に記載の通信装置。
6. 前記制御部は、前記パケットの送信元端末から得られる前記パケットの鮮度情報に基づいて、リレー通信の実施を判定する、
   請求項１に記載の通信装置。
7. 前記制御部は、前記パケットの送信元端末から得られる、前記パケットのリレーホップ数、前記パケットのリレー経路、前記パケットの生成時間又は送信時間、前記パケットの生成エリア又は送信エリアのうち少なくとも１つから求められる前記鮮度情報に基づいて、リレー通信の実施を判定する、
   請求項６に記載の通信装置。
8. 前記制御部は、前記パケットの通信に用いるチャネルの混雑度、前記チャネルの状態、前記パケットの再送情報、又は、前記端末自身の位置情報のうち少なくとも１つに基づいて、リレー通信の実施を判定する、
   請求項１に記載の通信装置。
9. 前記制御部は、リレー通信用のリソースの確保をさらに制御する、
   請求項１に記載の通信装置。
10. 前記制御部は、前記リソースプール内でのリレー通信用のリソースのセンシングを制御する、
    請求項９に記載の通信装置。
11. 前記制御部は、前記パケットの送信元端末が予約したリレー通信用のリソースを用いた前記パケットのリレー通信の実施を制御する、
    請求項９に記載の通信装置。
12. 前記制御部は、前記パケットの送信元端末が予約したリレー通信用のリソースをセンシングして使用できないときには、自らリレー通信用のリソースのセンシングを制御する、
    請求項１１に記載の通信装置。
13. 前記制御部は、前記基地局が確保したリレー通信用のリソースを用いた前記パケットのリレー通信の実施を制御する、
    請求項９に記載の通信装置。
14. 前記制御部は、前記パケットのリレー通信の実施確率をさらに制御する、
    請求項１に記載の通信装置。
15. 前記制御部は、前記パケットの鮮度情報に応じて前記パケットのリレー通信の実施確率を制御する、
    請求項１４に記載の通信装置。
16. 前記制御部は、前記基地局から設定され、又は前記端末自身にあらかじめ設定された、パケットの鮮度情報と実施確率との関係に基づいて、前記パケットのリレー通信の実施確率を制御する、
    請求項１５に記載の通信装置。
17. 前記制御部は、前記パケットの優先度情報に対応したパケットの鮮度情報と実施確率との関係に基づいて、前記パケットのリレー通信の実施確率を制御する、
    請求項１５に記載の通信装置。
18. 前記制御部は、リレー通信に使用するチャネルの混雑度に対応したパケットの鮮度情報と実施確率との関係に基づいて、前記パケットのリレー通信の実施確率を制御する、
    請求項１５に記載の通信装置。
19. 前記制御部は、前記パケットの送信元端末から得られる情報に基づいて、前記パケットの鮮度情報を更新する、
    請求項１５に記載の通信装置。
20. 基地局の配下で端末として動作する通信装置における通信方法であって、
    所定のリソースプールにおいてパケットを受信するステップと、
    前記基地局から通知される情報、他端末から通知される情報、又は、前記端末自身から得られる情報のうち少なくとも１つに基づいて、前記パケットのリレー通信の実施を制御するステップと、
    を有する通信方法。