JP2017139662A - 通信装置、通信方法、送信装置及び受信装置 - Google Patents

Abstract

【課題】Ｖ２Ｘ通信におけるメッセージの送受信をより確実に成功させることが可能な仕組みを提供する。【解決手段】送信装置から受信装置へＶ２Ｘ通信を用いて送信されるメッセージを、前記送信装置と協調して前記受信装置へ送信する処理部、を備える通信装置。【選択図】図１４

Description

本開示は、通信装置、通信方法、送信装置及び受信装置に関する。

車両等の移動体に搭載された通信装置を利用することによって、移動体と種々の対象物との間における直接的な通信が実現される。移動体に搭載された通信装置と種々の他の通信装置との間における通信は、Ｖ２Ｘ（Ｖｅｈｉｃｌｅ ｔｏ Ｘ）通信と称されている。Ｖ２Ｘ通信については、これまで、ＤＳＲＣ（Ｄｅｄｉｃａｔｅｄ Ｓｈｏｒｔ Ｒａｎｇｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）が利用される通信システムについて検討されてきたが、近年、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）等の携帯電話の通信規格が利用される通信システムについての検討が進められている。なお、ＬＴＥの通信規格に関するシステムについては、例えば下記非特許文献１に開示されている。

３ＧＰＰ ＴＲ ２２．８８５ "Ｓｔｕｄｙ ｏｎ ＬＴＥ ｓｕｐｐｏｒｔ ｆｏｒ Ｖｅｈｉｃｌｅ ｔｏ Ｅｖｅｒｙｔｈｉｎｇ （Ｖ２Ｘ） ｓｅｒｖｉｃｅｓ"

上記のＶ２Ｘ通信においては、歩行者に携行される通信装置、移動体に搭載される通信装置及び道路脇に設置される通信装置等が相互にメッセージをやり取りすることで、交通の利便性の向上及び安全性の確保等が実現される。ただし、歩行者に携行される通信装置に電力量の制限があること、及び移動体に搭載される通信装置が高速に移動し得ること等を考慮すれば、メッセージの送受信の失敗に伴う再送は極力行われないことが望ましい。そこで、本開示では、Ｖ２Ｘ通信におけるメッセージの送受信をより確実に成功させることが可能な仕組みを提供する。

本開示によれば、送信装置から受信装置へＶ２Ｘ通信を用いて送信されるメッセージを、前記送信装置と協調して前記受信装置へ送信する処理部、を備える通信装置が提供される。

また、本開示によれば、送信装置から受信装置へＶ２Ｘ通信を用いて送信されるメッセージを、プロセッサにより前記送信装置と協調して前記受信装置へ送信すること、を含む方法が提供される。

また、本開示によれば、送信装置であって、前記送信装置と協調してメッセージを送信する通信装置によりＶ２Ｘ通信を用いて送信されるメッセージと前記送信装置がＶ２Ｘ通信を用いて送信するメッセージとを受信装置に合成させるための制御情報を送信する処理部、を備える送信装置が提供される。

また、本開示によれば、送信装置によりＶ２Ｘ通信を用いて送信されるメッセージと、前記送信装置と協調してメッセージを送信する通信装置から送信されるメッセージとを、受信した制御情報に基づいて合成する処理部、を備える受信装置が提供される。

以上説明したように本開示によれば、Ｖ２Ｘ通信におけるメッセージの送受信をより確実に成功させることが可能な仕組みを提供する。なお、上記の効果は必ずしも限定的なものではなく、上記の効果とともに、または上記の効果に代えて、本明細書に示されたいずれかの効果、または本明細書から把握され得る他の効果が奏されてもよい。

Ｖ２Ｘ通信の概要について説明するための説明図である。 Ｖ２Ｖ通信の第１のシナリオを説明するための説明図である。 Ｖ２Ｖ通信の第２のシナリオを説明するための説明図である。 Ｖ２Ｖ通信の第３のシナリオを説明するための説明図である。 Ｖ２Ｖ通信の第４のシナリオを説明するための説明図である。 Ｖ２Ｖ通信の第５のシナリオを説明するための説明図である。 本開示の一実施形態による無線通信システムの構成を示す説明図である。 同実施形態に係るＵＥの論理的な構成の一例を示すブロック図である。 同実施形態に係るＵＥの論理的な構成の一例を示すブロック図である。 同実施形態に係るｅＮＢの論理的な構成の一例を示すブロック図である。 同実施形態に係るＲＳＵの論理的な構成の一例を示すブロック図である。 本実施形態に係る送信装置による支援有りＶ２Ｘ通信の開始判断処理の流れの一例を示すフローチャートである。 本実施形態に係る協調送信の概要を説明するための図である。 本実施形態に係る協調送信のタイムチャートを示す図である。 本実施形態に係る独立リレータイプの協調送信のタイムチャートを示す図である。 本実施形態に係る制御下リレータイプの協調送信のタイムチャートを示す図である。 本実施形態に係る変更有りリレータイプの協調送信のタイムチャートを示す図である。 本実施形態に係る変更有りリレータイプの協調送信のタイムチャートを示す図である。 本実施形態に係る２つの支援装置が受信装置へメッセージを協調送信する例を説明するための図である。 本実施形態に係る２つの支援装置が受信装置へメッセージを協調送信する例を説明するための図である。 本実施形態に係る支援装置間でメッセージのリレーが行われる例を説明するための図である。 本実施形態に係る支援装置間でメッセージのリレーが行われる例を説明するための図である。 本実施形態に係る協調送信の他の例を説明するための図である。 本実施形態に係る送信装置により実行される協調送信処理の流れの一例を示すフローチャートである。 本実施形態に係る支援装置により実行される協調送信処理の流れの一例を示すフローチャートである。 本実施形態に係る受信装置により実行される受信処理の流れの一例を示すフローチャートである。 本実施形態に係る送信装置により実行される代理送信処理の流れの一例を示すフローチャートである。 本実施形態に係る送信装置により実行されるＵｕ多重送信処理の流れの一例を示すフローチャートである。 ｅＮＢの概略的な構成の第１の例を示すブロック図である。 ｅＮＢの概略的な構成の第２の例を示すブロック図である。 スマートフォンの概略的な構成の一例を示すブロック図である。 カーナビゲーション装置の概略的な構成の一例を示すブロック図である。

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

また、本明細書及び図面において、実質的に同一の機能構成を有する複数の構成要素を、同一の符号の後に異なるアルファベットを付して区別する場合もある。例えば、実質的に同一の機能構成または論理的意義を有する複数の構成を、必要に応じてＵＥ１０Ａ、１０Ｂおよび１０Ｃのように区別する。ただし、実質的に同一の機能構成を有する複数の構成要素の各々が特に区別されなくてもよい場合、同一符号のみを付する。例えば、ＵＥ１０Ａ、１０Ｂおよび１０Ｃが特に区別されなくてもよい場合には、ＵＥ１０Ａ、１０Ｂおよび１０Ｃの各々を単にＵＥ１０と称する。

なお、説明は以下の順序で行うものとする。
１．はじめに
１．１．Ｖ２Ｘ通信
１．２．技術的課題
２．構成例
２．１．システムの構成例
２．２．ＵＥ（ユーザ端末）の構成例
２．３．ＵＥ（移動体）の構成例
２．４．ｅＮＢの構成例
２．５．ＲＳＵの構成例
３．技術的特徴
３．１．基本動作
３．２．協調送信
３．２．１．概要
３．２．２．協調送信のタイプ
３．２．３．処理の流れ
３．３．代理送信
３．４．Ｕｕ多重送信
４．応用例
５．まとめ

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

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

なお、Ｖ２Ｘ通信では、ＤＳＲＣ（Ｄｅｄｉｃａｔｅｄ Ｓｈｏｒｔ Ｒａｎｇｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）が利用される通信システムについて検討されてきたが、近年、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）等の携帯電話の通信規格が利用される通信システムについての検討が進められている。

Ｖ２Ｘ通信の適用例として、例えば、前方衝突警告、制御不能警告、緊急車両警告、緊急停車、適応走行支援、交通状態警告、交通安全、自動駐車、経路逸脱警告、メッセージ送信、衝突警告、通信範囲拡大、交通量適正化、カーブ速度警報、歩行者衝突警告又は脆弱者安全等を目的とした通信システムが挙げられる。その他、ＲＳＵ（Ｒｏａｄ Ｓｉｄｅ Ｕｎｉｔ）タイプのユーザ端末（ＵＥ：User Equipment）によるＶ２Ｘ通信、Ｖ２Ｘ通信の最低ＱｏＳ、ローミング時のＶ２Ｘアクセス、歩行者の交通安全のためのＶ２Ｐ通信を介したメッセージの提供、交通管理のための混合使用、又は交通参加者のための位置測定精度の向上等が検討されている。

上記の適用例のための要求事項の一覧を、下記の表１に示す。

上記の要求事項を満たすために、Ｖ２Ｘ通信の物理レイヤの標準化が３ＧＰＰにおいて検討されている。Ｖ２Ｘ通信のベース技術としては、３ＧＰＰで過去に規格化されたＤ２Ｄ（Ｄｅｖｉｃｅ ｔｏ ｄｅｖｉｃｅ）通信が挙げられる。Ｄ２Ｄ通信は、基地局を介さない端末間通信であるため、Ｖ２Ｖ通信、Ｖ２Ｐ通信又は一部のＶ２Ｉ通信への拡張に向くと言える。このような、端末間のインタフェースは、ＰＣ５インタフェースとも称される。一方、Ｖ２Ｉ通信又はＶ２Ｎに関しては、ＬＴＥ等の既存の基地局と端末との通信技術を拡張することが想定されている。このような、基地局と端末とのインタフェースは、Ｕｕインタフェースとも称される。今後の検討では、ＰＣ５インタフェース及びＵｕインタフェースを、上記の要求事項を満たすよう拡張することが求められる。主な拡張ポイントとしては、例えばリソース割り当ての改善、ドップラー周波数対策、同期手法の確立、低消費電力通信の実現、及び低遅延通信の実現等が挙げられる。

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

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

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

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

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

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

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

＜１．２．技術的課題＞
Ｖ２Ｐ通信では、移動体に搭載された通信装置と歩行者が携行する通信装置との間で通信が行われる。Ｖ２Ｐ通信における要求項目の一例を以下に説明する。遅延要求としては、サーバーから端末まで５００ｍｓ以内、且つＥｎｄ−ｔｏ−ｅｎｄで１００ｍｓ以内の遅延であることが挙げられる。オペレーション要求としては、マルチＭＮＯ（mobile network operator）対応であることが挙げられる。消費電力要求としては、バッテリー消費を最小化することが挙げられる。カバレッジ要求としては、衝突４秒以上前にＶ２Ｐ通信可能な範囲がカバーされることが挙げられる。例えば、時速１００ｋｍであれば、２７．７ｍ／ｓ×４ｓの約１１０．８ｍ以上を半径とするカバレッジが要求される。メッセージ要求としては、典型的には５０〜３００バイト、最大１２００バイトであることが挙げられる。通信品質要求としては、バイクと車との相対速度で時速２８０ｋｍ、歩行者と車との相対速度で時速１６０ｋｍの環境での通信が確立されることが挙げられる。

本開示では、上述した要求項目のうち、バッテリー消費の最小化を技術的課題とする。歩行者が携行する通信装置として想定されるスマートフォン等は、バッテリー量が豊富ではない場合が多い。そのため、バッテリー消費の最小化は、Ｖ２Ｐ通信の導入のために重要な課題であると言える。

ここで、歩行者が携行する通信装置は、信号を送信する頻度が他の装置と比較して少ないため、受信側がより確実に受信することが望ましい。それにより、再送回数が削減されて、歩行者が携行する通信装置の電力消費が低減されるためである。また、移動体に搭載される通信装置は、高速に移動し得るため、再送によるタイムラグが事故を引き起こす要因にもなり兼ねない。このような事情から、本開示では、送信装置による送信を他の通信装置が支援することで、受信装置におけるメッセージ到達確率を向上させる仕組みを提供する。

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

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

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

ＧＮＳＳ衛星４０は、地球を所定の軌道に沿って周回する人工衛星（通信装置）である。ＧＮＳＳ衛星４０は、航法メッセージを含むＧＮＳＳ（Ｇｌｏｂａｌ Ｎａｖｉｇａｔｉｏｎ Ｓａｔｅｌｌｉｔｅ Ｓｙｓｔｅｍ）信号を送信する。航法メッセージは、ＧＮＳＳ衛星４０の軌道情報および時間情報などの、位置測定のための種々の情報を含む。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

以上、各実施形態において共通する構成例を説明した。続いて、各実施形態の技術的特徴を詳細に説明する。

＜＜３．技術的特徴＞＞
本実施形態では、送信装置による送信を他の通信装置（以下、支援装置とも称する）が支援することで、受信装置におけるメッセージ到達確率を向上させる仕組みを提供する。

以下では、一例として送信装置がＵＥ１０であり、受信装置がＵＥ２０であり、支援装置がｅＮＢ３０又はＲＳＵ５０であるものとして説明する。ＵＥ１０にはバッテリー量の制限が課される場合がある一方、ｅＮＢ３０又はＲＳＵ５０は豊富なバッテリー量を有する又は電源と接続されていることが想定される。そのため、ｅＮＢ３０又はＲＳＵ５０がその豊富な電力を背景にＵＥ１０による送信を支援することで、メッセージ到達確率の向上及びＵＥ１０の電力消費の低減が可能となる。なお、ＲＳＵ５０には、ＵＥタイプとｅＮＢタイプがあるものとする。ＵＥタイプのＲＳＵ５０は、ＵＥとしての動作が可能であり、少なくとも他のＵＥとの間にＰＣ５インタフェースをサポートし、ｅＮＢ３０との間にＵｕインタフェースをサポートする。また、ｅＮＢタイプのＲＳＵ５０は、ｅＮＢ３０としての動作が可能なＲＳＵである。

なお、送信装置、受信装置、及び支援装置は上記の例に限定されない。例えば、送信装置がＵＥ２０であり受信装置がＵＥ１０であってもよいし、送信装置及び受信装置が共にＵＥ１０であってもよいし、共にＵＥ２０であってもよい。他にも、送信装置は、ＲＳＵ５０であってもよい。また、支援装置は、ＵＥ１０又はＵＥ２０であってもよいし、複数であってもよい。

＜３．１．基本動作＞
ＵＥ１０は、ｅＮＢ３０又はＲＳＵ５０の支援を得られる場合にｅＮＢ３０又はＲＳＵ５０の支援を受けてＶ２Ｘ通信を行い、支援を得られない場合は通常のＶ２Ｘ通信を行う。以下では、前者を支援有りのＶ２Ｘ通信とも称し、後者を支援無しのＶ２Ｘ通信とも称する。

そのために、ＵＥ１０は、周囲のｅＮＢ３０又はＲＳＵ５０を発見する。例えば、ＵＥ１０は、ＲＳＵ５０からのディスカバリ信号（Discovery signal）又はＰＳＢＣＨ（Physical Sidelink Broadcast Channel）により、ＲＳＵ５０を発見し得る。また、ＵＥ１０は、ｅＮＢ３０からのＰＢＣＨ（Physical Broadcast Channel）、ＰＤＣＣＨ（Physical Downlink Control Channel)、ＭＩＢ（Master Information Block）又はＳＩＢ（System Information Block）により、ｅＮＢ３０を発見し得る。

そして、ＵＥ１０は、発見したｅＮＢ３０又はＲＳＵ５０が、支援有りのＶ２Ｘ通信をサポートしているか否かを確認する。例えば、ｅＮＢ３０又はＲＳＵ５０は、ＵＥ１０を支援して（例えば、ＵＥ１０と協調して、又はＵＥ１０の代理で等）ＵＥ２０へメッセージをリレー可能であることを示す情報を、ＵＥ１０に通知する。具体的には、ディスカバリ信号又はシステム情報（ＳＩＢ又はＭＩＢ）に、支援有りのＶ２Ｘ通信をサポートしているか否かを示すサポート情報が含まれ得る。そのため、ＵＥ１０は、ディスカバリ信号又はシステム情報からサポート情報を取得して、上記確認を行う。

ＵＥ１０は、支援有りのＶ２Ｘ通信をサポートしているｅＮＢ３０又はＲＳＵ５０が確認された場合に支援有りのＶ２Ｘ通信を行い、支援有りのＶ２Ｘ通信をサポートしているｅＮＢ３０又はＲＳＵ５０が確認されない場合に支援無しのＶ２Ｘ通信を行う。以下、このような処理の流れを、図１２を参照して説明する。

図１２は、本実施形態に係る送信装置（例えば、ＵＥ１０）による支援有りＶ２Ｘ通信の開始判断処理の流れの一例を示すフローチャートである。図１２に示すように、まず、ＵＥ１０は、ｅＮＢ３０又はＲＳＵ５０からのディスカバリ信号、ＰＳＢＣＨ、ＰＢＣＨ又はＰＤＣＣＨ等の信号を受信して（ステップＳ１０２）、ｅＮＢ３０又はＲＳＵ５０の発見を試みる（ステップＳ１０４）。受信した信号からのｅＮＢ３０又はＲＳＵ５０の発見に成功した場合（ステップＳ１０４／ＹＥＳ）、ＵＥ１０は、ディスカバリ信号又はシステム情報に含まれるサポート情報を確認して、発見したｅＮＢ３０又はＲＳＵ５０が支援有りのＶ２Ｘ通信をサポートしているか否かを判定する（ステップＳ１０６）。発見したｅＮＢ３０又はＲＳＵ５０が支援有りのＶ２Ｘ通信をサポートしていると判定された場合（ステップＳ１０６／ＹＥＳ）、ＵＥ１０は、支援有りのＶ２Ｘ通信に移行する（ステップＳ１０８）。一方で、受信した信号からのｅＮＢ３０又はＲＳＵ５０の発見に失敗した場合（ステップＳ１０４／ＮＯ）、ＵＥ１０は、支援無しのＶ２Ｘ通信を継続して（ステップＳ１１０）、処理は再度ステップＳ１０２に戻る。発見したｅＮＢ３０又はＲＳＵ５０が支援有りのＶ２Ｘ通信をサポートしていないと判定された場合（ステップＳ１０６／ＮＯ）も、ＵＥ１０は、支援無しのＶ２Ｘ通信を継続して（ステップＳ１１０）、処理は再度ステップＳ１０２に戻る。

以上、ＵＥ１０の基本動作を説明した。続いて、支援有りのＶ２Ｘ通信の具体的な動作を説明する。支援有りのＶ２Ｘ通信には、協調送信、代理送信、及びＵｕ多重送信の３種類が考えられる。

＜３．２．協調送信＞
＜３．２．１．概要＞
本通信方法は、送信装置（例えば、ＵＥ１０）と支援装置（例えば、ＲＳＵ５０）とが協調して、受信装置（例えば、ＵＥ２０）にメッセージを送信する方法である。

本通信方法は、ＬＴＥにおいて基地局同士が協調してメッセージを送信するセル間協調送受信（ＣｏＭＰ：Coordinated Multi-Point transmission／reception）技術を、Ｖ２Ｘ通信に拡張したものである、と言える。ＬＴＥにおけるＣｏＭＰと本通信方法との第１の相違点は、基地局同士が協調するのか、ＵＥ１０と支援装置とが協調するのか、という点である。第２の相違点は、Ｖ２Ｘ通信ではＬＴＥと異なり、メッセージ到達確率を向上させるために、送信装置が毎メッセージごとに複数回繰り返し送信を行う点である。よって、支援装置は、送信装置による繰り返し送信の最初の期間で協調送信すべきメッセージを取得して、取得したメッセージを繰り返し送信の残りの期間で送信する。

本実施形態に係る支援装置は、送信装置から受信装置へＶ２Ｘ通信を用いて送信されるメッセージを、送信装置と協調して受信装置へ送信する。また、本実施形態に係る送信装置は、支援装置によりＶ２Ｘ通信を用いて送信されるメッセージと送信装置がＶ２Ｘ通信を用いて送信するメッセージとを受信装置に合成させるための制御情報（後述する協調送信パラメータ）を、受信装置又は支援装置に送信する。そして、本実施形態に係る受信装置は、送信装置によりＶ２Ｘ通信を用いて送信されるメッセージと、送信装置と協調してメッセージを送信する支援装置から送信されるメッセージとを、受信した制御情報に基づいて合成する。このようにして、受信装置における受信メッセージの合成が可能となるため、受信品質（例えば、ＳＩＮＲ：signal−to−interference−plus−noise ratio）が改善され、メッセージ到達確率が向上する。

以下、図１３及び図１４を参照して、本通信方法について詳しく説明する。

図１３は、本実施形態に係る協調送信の概要を説明するための図である。図１３に示すように、ＵＥ１０は、移動体２２に搭載されたＵＥ２０へメッセージを送信する。ＵＥ１０は、毎メッセージごとに複数回繰り返し送信を行う。宛先がＵＥ２０であることから、ＵＥ１０はＰＣ５インタフェースを用いてメッセージの送信を行う。従って、図１３に示すように、このメッセージは、ＰＣ５インタフェースを有するＲＳＵ５０が受信可能である。ＲＳＵ５０は、受信したメッセージを宛先のＵＥ２０にリレーする。ＵＥ２０は、ＵＥ１０から受信したダイレクトメッセージと、ＲＳＵ５０によりリレーされたリレーメッセージとを合成する。これにより、受信品質が改善され、メッセージ到達確率が向上する。

図１４は、本実施形態に係る協調送信のタイムチャートを示す図である。図中の「Ｐｅｄｅｓｔｒｉａｎ Ｔｘ」とは、ＵＥ１０により送信されるメッセージを示す。「ＲＳＵ ＴＸ／ＲＸ」とは、ＲＳＵ５０により送信される又は受信されるメッセージを示す。「Ｖｅｈｉｃｌｅ ＲＸ」とは、ＵＥ２０により受信されるメッセージを示す。図１４に示すように、ＵＥ１０は、ＲＶを０としてメッセージを送信する。このメッセージは、ＵＥ２０及びＲＳＵ５０の各々に受信される。次いで、ＲＳＵ５０は、受信したメッセージをそのままＵＥ２０に送信（即ち、リレー）する。このメッセージは、ＵＥ２０により受信される。そして、ＵＥ２０は、受信したこれらのメッセージを合成する。なお、図１４においては、ＵＥ１０による再送（即ち、繰り返し送信）のメッセージは省略されている。例えば、ＲＳＵ５０によるリレーのタイミングは、ＵＥ１０による再送と同一のタイミングであってもよい。

協調送信には、複数のタイプが存在し得る。例えば、変更無しリレータイプ、変更有りリレータイプ及びインタフェース変更リレータイプ等が挙げられる。以下、これらについて詳細に説明する。

＜３．２．２．協調送信のタイプ＞
（１）変更無しリレータイプ
例えば、支援装置は、受信したメッセージのＲＶを変更せずにリレーしてもよい。

（１．１）独立リレータイプ
支援装置は、送信装置から独立してメッセージの送信を行ってもよい。この場合、受信装置は、送信装置からの受信のためのリソース、及び支援装置からの受信のためのリソースの、２つのリソースで受信動作を行う。以下、図１５を参照して、独立リレータイプにおける協調送信の概要を説明する。

図１５は、本実施形態に係る独立リレータイプの協調送信のタイムチャートを示す図である。図中の「Ｐｅｄｅｓｔｒｉａｎ Ｔｘ」とは、ＵＥ１０により送信されるメッセージを示す。「ＲＳＵ ＴＸ／ＲＸ」とは、ＲＳＵ５０により送信される又は受信されるメッセージを示す。「Ｖｅｈｉｃｌｅ ＲＸ」とは、ＵＥ２０により受信されるメッセージを示す。図１５に示すように、ＵＥ１０は、ＲＶを０とするメッセージ及びＰＳＣＣＨ（Physical Sidelink Control Channel）を送信する。このメッセージ及びＰＳＣＣＨは、ＵＥ２０及びＲＳＵ５０の各々に受信される。次いで、ＲＳＵ５０は、受信したＰＳＣＣＨに基づいて、ＲＶを変更することなくメッセージをＲＳＵ５０にリレーする。その際、ＲＳＵ５０は、ＰＳＣＣＨもＵＥ２０に送信する。このメッセージ及びＰＳＣＣＨは、ＵＥ２０により受信される。そして、ＵＥ２０は、受信した各々のＰＳＣＣＨを参照して、各々のメッセージを合成する。なお、図１５においては、ＰＳＣＣＨとデータ信号とが別の時間リソースで送受信されることが示されているが、同一又は重複する時間リソースで送受信されてもよい。他のタイムチャートにおいても同様である。また、図１５においては、ＵＥ１０による再送（即ち、繰り返し送信）のメッセージは省略されている。例えば、ＲＳＵ５０によるリレーのタイミングは、ＵＥ１０による再送と同一のタイミングであってもよい。

図１５に示したように、ＵＥ１０は、ＰＳＣＣＨをＵＥ２０及びＲＳＵ５０に通知する。このＰＳＣＣＨには、協調送信に関するパラメータ（即ち、制御情報）が含まれ得る。ＲＳＵ５０は、ＵＥ１０から受信した本パラメータに基づいてメッセージをＵＥ２０にリレーする。さらに、ＲＳＵ５０は、協調送信に関するパラメータを含むＰＳＣＣＨをＵＥ２０に通知する。ＵＥ２０は、これらのパラメータに基づいてメッセージの合成を行う。協調送信に関するパラメータを、以下では協調送信パラメータとも称する。ＵＥ１０から通知される協調送信パラメータとＲＳＵ５０から通知される協調送信パラメータとは、同一であってもよいし異なっていてもよい。以下、ＵＥ１０から通知される協調送信パラメータに含まれ得る情報の一例を説明する。

・送信装置が通知する協調送信パラメータ
例えば、協調送信パラメータは、送信装置と支援装置との協調を実施するか否か（即ち実施を要求するか否か）を示す協調送信指標（CoMP indicator）を含み得る。これにより、受信装置及び支援装置は、協調送信が行われるか否かを知得することが可能となる。

また、協調送信パラメータは、送信装置と支援装置との協調のタイプを示す協調送信タイプ（CoMP type）を含み得る。協調送信タイプとしては、変更無しリレータイプ、変更有りリレータイプ及びインタフェース変更リレータイプ等の他、協調送信に関与する支援装置の数、及び受信装置での合成方法等が挙げられる。

また、協調送信パラメータは、送信装置の識別情報を示す送信装置ＩＤを含み得る。また、協調送信パラメータは、受信装置の識別情報を示す受信装置ＩＤを含み得る。協調送信パラメータは、受信装置ＩＤと共に、又は代えて受信装置グループＩＤを含み得る。

また、協調送信パラメータは、協調送信の対象のメッセージのＲＶ情報（ＲＶ値及び／又はＲＶパターン）を含み得る。

また、協調送信パラメータは、協調送信の対象のメッセージの繰り返し送信回数を含み得る。これにより、支援装置は、Ｖ２Ｘ通信の支援が可能か否かを判断可能である。例えば、繰り返し送信回数が上限値に達していなければ、送信装置による残りの繰り返し送信のタイミングでの、支援装置によるリレーが可能であると判断され得る。

また、協調送信パラメータは、協調送信の対象のメッセージの識別情報を示すメッセージＩＤ又はパケットＩＤを含み得る。

また、協調送信パラメータは、ＭＣＳ（Modulation and Coding Scheme）情報を含み得る。

また、協調送信パラメータは、ＴＡ（Timing Advance）情報を含み得る。ＲＳＵ５０は、ＴＡ情報を参照することで、リレータイミングを適切に制御することが可能となる。

また、協調送信パラメータは、周波数ホッピング指標（Frequency hopping indicator）情報を含み得る。支援装置は、周波数ホッピング指標を参照することで、リレーに用いる周波数リソースを適切に制御することが可能となる。

以上、送信装置が通知する協調送信パラメータについて説明した。支援装置は、これらの協調送信パラメータに基づいて、メッセージの送信に用いる無線リソースを設定する。支援装置は、メッセージのリレーに用いる無線リソースを自身で制御可能であるため、例えば自身の通信状況に応じて適切な設定を行うことが可能である。続いて、支援装置が通知する協調送信パラメータについて説明する。

・支援装置が通知する協調送信パラメータ
協調送信パラメータは、支援装置が送信するメッセージが、送信装置から受信したメッセージのリレーであることを示す情報を含み得る。受信装置は、この情報に基づいて合成することが可能となる。さらに支援装置が通知する協調送信パラメータは、上述した送信装置が通知する協調送信パラメータと同様の情報を含んでいてもよい。例えば、支援装置が通知する協調送信パラメータに、メッセージＩＤ又はパケットＩＤをＰＳＣＣＨが含まれる場合、受信装置は、同一のメッセージＩＤ又はパケットＩＤが付された、送信装置及び支援装置の各々から受信したメッセージを合成することが可能となる。

以上、協調送信パラメータの一例を説明した。協調送信パラメータは、ＰＳＣＣＨに含まれて通知されてもよい。また、協調送信パラメータは、ＰＳＣＣＨとＰＳＳＣＨ（Physical Sidelink Shared Channel）とに分散して含まれていてもよい。例えば、ＰＳＳＣＨに、協調送信指標以外の協調送信パラメータが含まれ、ＰＳＣＣＨに、協調送信指標、及びその他の協調送信パラメータが含まれるＰＳＳＣＨ上の領域を示す情報が含まれてもよい。

（１．２）制御下リレータイプ
支援装置は、送信装置による制御に基づいてメッセージの送信を行ってもよい。この場合、送信装置から支援装置に通知される協調送信パラメータに、支援装置がリレーに用いるべき無線リソースを示す情報が含まれることとなる。そのため、受信装置は、協調送信パラメータに従い、送信装置からのメッセージと支援装置からのメッセージとを、同一のリソース上で受信することが可能となる。以下、図１６を参照して、制御下リレータイプにおける協調送信の概要を説明する。

図１６は、本実施形態に係る制御下リレータイプの協調送信のタイムチャートを示す図である。図中の「Ｐｅｄｅｓｔｒｉａｎ Ｔｘ」とは、ＵＥ１０により送信されるメッセージを示す。「ＲＳＵ ＴＸ／ＲＸ」とは、ＲＳＵ５０により送信される又は受信されるメッセージを示す。「Ｖｅｈｉｃｌｅ ＲＸ」とは、ＵＥ２０により受信されるメッセージを示す。図１６に示すように、ＵＥ１０は、ＲＶを０とするメッセージ及びＰＳＣＣＨを送信する。このメッセージ及びＰＳＣＣＨは、ＵＥ２０及びＲＳＵ５０の各々に受信される。次いで、ＲＳＵ５０は、受信したＰＳＣＣＨに含まれる協調送信パラメータに基づいて、ＲＶを変更することなくメッセージをＲＳＵ５０にリレーする。そして、ＵＥ２０は、ＵＥ１０から受信したＰＳＣＣＨを参照して、各々のメッセージを合成する。なお、図１６においては、ＵＥ１０による再送（即ち、繰り返し送信）のメッセージは省略されている。例えば、ＲＳＵ５０によるリレーのタイミングは、ＵＥ１０による再送と同一のタイミングであってもよい。

以下、送信装置から通知される協調送信パラメータについて説明する。本タイプの協調送信における協調送信パラメータは、上述した独立リレータイプと同様の情報を含み得る。そこで以下では、本タイプの協調送信における協調送信パラメータにさらに含まれ得る情報の一例を説明する。

例えば、協調送信パラメータは、受信装置への送信に用いるべき無線リソースを示す情報を含み得る。具体的には、協調送信パラメータは、リレー用リソースプール情報を含み得る。また、協調送信パラメータは、リレー用ＲＰＴ(Resource Pattern of Transmission)情報を含み得る。ここで、リレー用ＲＰＴは、通常のＲＰＴと比較して、時間が遅れていることが望ましい。また、協調送信パラメータは、リレー用周波数帯域情報を含み得る。支援装置は、これらの情報を参照することで、送信装置により指定された無線リソースを、メッセージのリレーに用いることが可能となる。これに伴い、受信装置は、送信装置からのメッセージと支援装置からのメッセージとを、同一のリソース上で受信することが可能となる。

以上、協調送信パラメータの一例を説明した。協調送信パラメータは、ＰＳＣＣＨに含まれて通知されてもよいし、ＰＳＣＣＨとＰＳＳＣＨとに分散して含まれていてもよい。

（２）変更有りリレータイプ
例えば、支援装置は、送信装置から送信されるメッセージのＲＶを変更して受信装置へリレーしてもよい。

具体的には、支援装置は、ＲＶをランダムに変更してリレーしてもよい。他にも、支援装置は、ＲＶを協調送信パラメータに基づいて変更してリレーしてもよい。その場合、支援装置は、送信装置と同一のタイミングで送信するメッセージに、送信装置と同一のＲＶを付与することが可能となる。以下、図１７及び図１８を参照して変更有りリレータイプにおける協調送信の概要を説明する。

図１７及び図１８は、本実施形態に係る変更有りリレータイプの協調送信のタイムチャートを示す図である。図１７は、ＲＳＵ５０が一度目の受信に成功するケースであり、図１８は、ＲＳＵ５０が一度目の受信に失敗して二度目で成功するケースである。図中の「Ｐｅｄｅｓｔｒｉａｎ Ｔｘ」とは、ＵＥ１０により送信されるメッセージを示す。「ＲＳＵ ＴＸ／ＲＸ」とは、ＲＳＵ５０により送信される又は受信されるメッセージを示す。「Ｖｅｈｉｃｌｅ ＲＸ」とは、ＵＥ２０により受信されるメッセージを示す。

図１７に示すように、ＵＥ１０は、ＲＶを０とするメッセージ及びＰＳＣＣＨを送信する。このメッセージ及びＰＳＣＣＨは、ＵＥ２０及びＲＳＵ５０の各々に受信される。次いで、ＵＥ１０は、ＲＶを２としてメッセージを再送（即ち、繰り返し送信）する。他方、ＲＳＵ５０は、受信したＰＳＣＣＨに含まれる協調送信パラメータに基づいて、ＲＶを変更してメッセージをＵＥ２０にリレーする。このとき、ＲＳＵ５０は、ＵＥ１０により再送されるメッセージ同じくＲＶを２として、且つＵＥ１０による再送と同一のリソース（例えば、時間及び周波数）で、メッセージをリレーする。これにより、ＵＥ２０は、ＵＥ１０及びＲＳＵ５０からの同一のＲＶのメッセージを、同一のリソースで受信することが可能となる。そして、ＵＥ２０は、ＵＥ１０から受信したＰＳＣＣＨを参照して、ＲＶが２のメッセージと、先に受信したＲＶが０のメッセージとを合成する。

図１８に示すように、ＵＥ１０は、ＲＶを０とするメッセージ及びＰＳＣＣＨを送信する。このメッセージ及びＰＳＣＣＨは、ＵＥ２０及びＲＳＵ５０の各々に受信される。次いで、ＵＥ１０は、ＲＶを２として、次いでＲＶを１としてメッセージを再送（即ち、繰り返し送信）する。他方、ＲＳＵ５０は、ＲＶを０とするメッセージ単体のデコードに失敗し、ＲＶを２とするメッセージとの合成によりデコードに成功したものとする。その場合、ＲＳＵ５０は、合成して得たメッセージを、ＲＶを変更してＵＥ２０にリレーする。このとき、ＲＳＵ５０は、ＵＥ１０により次に再送されるメッセージ同じくＲＶを１として、且つＵＥ１０による再送と同一のリソース（例えば、時間及び周波数）で、メッセージをリレーする。これにより、ＵＥ２０は、ＵＥ１０及びＲＳＵ５０からの同一のＲＶのメッセージを、同一のリソースで受信することが可能となる。そして、ＵＥ２０は、ＵＥ１０から受信したＰＳＣＣＨを参照して、ＲＶが０、１及び２のメッセージを合成する。

（３）インタフェース変更リレータイプ
支援装置は、送信装置からＰＣ５インタフェースで送信されたメッセージを、ＰＣ５インタフェースで受信装置にリレーしてもよい。また、支援装置は、送信装置からＰＣ５インタフェースで送信されたメッセージを、Ｕｕインタフェースで受信装置にリレーしてもよい。後者の場合、支援装置は、ｅＮＢタイプのＲＳＵ５０であってもよい。また、後者の場合、例えば、ＲＳＵ５０からｅＮＢ３０へ一旦中継されて、ｅＮＢ３０からＵｕインタフェースで受信装置にメッセージが送信されることも想定される。

例えば、支援装置は、送信装置から通知されたＰＳＣＣＨに含まれる協調送信パラメータに基づいて、インタフェースを変更してメッセージをリレーし得る。以下、本タイプの協調送信における協調送信パラメータに含まれ得る情報の一例を説明する。

例えば、協調送信パラメータは、協調送信指標、協調送信タイプ、送信装置ＩＤ、受信装置ＩＤ（及び／又は受信装置グループＩＤ）、ＲＶ情報（ＲＶ値及び／又はＲＶパターン）、繰り返し送信回数、及び／又はメッセージＩＤ若しくはパケットＩＤを含み得る。さらに、協調送信パラメータは、いつまでにリレー（即ち、送信）すべきかを示すリレー期限（即ち、送信期限）を示す情報を含み得る。リレー期限を示す情報が含まれることで、期限内でのリレーが可能となる。

（４）その他のリレータイプ
例えば、協調送信には、複数の支援装置が関与してもよい。以下、図１９〜図２２を参照して、複数の支援装置が関与する協調送信について説明する。

図１９及び図２０は、２つの支援装置が受信装置へメッセージを協調送信する例を説明するための図である。

図１９に示すように、ＵＥ１０がＰＣ５インタフェースで送信したメッセージが、ＵＥ２０の他、ＲＳＵ５０Ａ（ｅＮＢタイプ）及びＲＳＵ５０Ｂに受信される。そして、ＲＳＵ５０Ａ及びＲＳＵ５０Ｂが受信したメッセージをＵＥ２０にリレーする。リレーの際、ＲＳＵ５０ＡはＵｕインタフェースを用いてもよい。

図２０における「Ｐｅｄｅｓｔｒｉａｎ Ｔｘ」とは、ＵＥ１０により送信されるメッセージを示す。「ＲＳＵ ＴＸ／ＲＸ」とは、ＲＳＵ５０Ｂにより送信される又は受信されるメッセージを示す。「ｅＮＢ ＴＸ／ＲＸ」とは、ＲＳＵ５０Ａにより送信される又は受信されるメッセージを示す。「Ｖｅｈｉｃｌｅ ＲＸ」とは、ＵＥ２０により受信されるメッセージを示す。図２０に示すように、ＵＥ１０は、ＲＶを０としてメッセージを送信する。このメッセージは、ＵＥ２０、ＲＳＵ５０Ａ及びＲＳＵ５０Ｂの各々に受信される。次いで、ＲＳＵ５０Ａ及び５０Ｂは、受信したメッセージをＵＥ２０に送信（即ち、リレー）する。これらメッセージは、ＵＥ２０により受信される。そして、ＵＥ２０は、受信したこれらのメッセージを合成する。なお、図２０においては、ＵＥ１０による再送（即ち、繰り返し送信）のメッセージは省略されている。例えば、ＲＳＵ５０Ａ及び５０Ｂによるリレーのタイミングは、ＵＥ１０による再送と同一のタイミングであってもよい。

図２１及び図２２は、支援装置間でメッセージのリレーが行われる例を説明するための図である。

図２１に示した例では、ＵＥ１０がＰＣ５インタフェースで送信したメッセージが、ＵＥ２０の他、ＲＳＵ５０Ａ（ｅＮＢタイプ）に受信される。そして、ＲＳＵ５０Ａは、受信したメッセージをＲＳＵ５０Ｂにリレーする。この場合、ＲＳＵ５０Ａは中継装置に相当し、ＲＳＵ５０Ｂは、ＲＳＵ５０Ａから受信したメッセージをＵＥ２０にリレーすることとなる。

図２２に示した例では、ＵＥ１０がＰＣ５インタフェースで送信したメッセージが、ＵＥ２０の他、ＲＳＵ５０Ｂに受信される。そして、ＲＳＵ５０Ｂは、受信したメッセージをＲＳＵ５０Ａ（ｅＮＢタイプ）にリレーする。この場合、ＲＳＵ５０Ｂは中継装置に相当し、ＲＳＵ５０Ａは、ＲＳＵ５０Ｂから受信したメッセージをＵＥ２０にリレーすることとなる。なお、ＲＳＵ５０Ａによるリレーには、Ｕｕインタフェースが用いられてもよい。また、ＲＳＵ５０Ａの代わりに、ｅＮＢ３０がリレーしてもよい。

以上、複数の支援装置が関与する協調送信について説明した。複数の支援装置が関与する場合であっても、上記詳しく説明した１つの支援装置が関与する場合の技術的特徴が同様に適用され得る。例えば、関与する複数の支援装置は、送信装置から独立してリレーを行ってもよいし、送信装置による制御下でリレーしてもよい。

（５）変形例
上記では、ＵＥ１０とｅＮＢ３０又はＲＳＵ５０とが協調する例を説明したが、本技術はかかる例に限定されない。例えば、ＲＳＵ５０同士が協調してもよい。この場合について図２３を参照して具体的に説明する。

図２３は、本実施形態に係る協調送信の他の例を説明するための図である。図２３に示すように、ＲＳＵ５０Ａ及びＲＳＵ５０Ｂが、ＵＥ１０又はＵＥ２０にメッセージを協調送信している。この場合、ＲＳＵ５０Ａ又はＲＳＵ５０Ｂのいずれか一方が送信装置であり、他方が支援装置である。また、ＵＥ１０又はＵＥ２０が受信装置である。なお、ＵＥ１０が受信装置である場合、メッセージはＩ２Ｐメッセージとも称される。また、ＵＥ２０が受信装置である場合、メッセージはＩ２Ｖメッセージとも称される。

ＲＳＵ５０Ａ及びＲＳＵ５０Ｂは、無線又は有線でＩ２Ｉ通信を行ってもよい。無線の場合のインタフェースはＰＣ５インタフェースとも称され、有線の場合のインタフェースはＸ２インタフェースとも称される。また、ｅＮＢ３０は、ＲＳＵ５０Ａ及びＲＳＵ５０Ｂとの間でＵｕインタフェース又はＸ２インタフェースによる通信を行ってもよく、例えばＲＳＵ５０Ａ及びＲＳＵ５０Ｂを制御する。

協調送信パラメータは、ＲＳＵ５０間のＰＣ５インタフェース又はＸ２インタフェースを用いて、送信装置から支援装置へ通知されてもよい。また、協調送信パラメータは、ｅＮＢ３０とのＵｕインタフェース又はＸ２インタフェースを用いて、即ちｅＮＢ３０を経由して、送信装置から支援装置へ通知されてもよい。その他、ｅＮＢ３０により協調送信パラメータが設定され、協調送信パラメータがＵｕインタフェース又はＸ２インタフェースにより送信装置及び支援装置に通知されてもよい。

本変形例に係る協調送信パラメータは、上記説明した情報と同様の情報を含み得る。もちろん、本変形例に係る協調送信パラメータは、上記説明した情報と共に、又は代えて多様な情報を含み得る。以下、本変形例に係る協調送信パラメータに含まれ得る情報の一例を説明する。

例えば、協調送信パラメータは、協調送信のために利用すべき無線リソースを示すリソース情報を含み得る。

また、協調送信パラメータは、協調送信を行うタイミングを示すタイミング情報を含み得る。

また、協調送信パラメータは、協調送信の対象となる受信装置（例えば、ＵＥ１０又はＵＥ２０）を示す対象ＵＥ情報を含み得る。

また、協調送信パラメータは、協調送信の対象となるデータ、又は協調送信の対象となるデータを示す情報を含み得る。

以上、本変形例に係る協調送信パラメータについて説明した。支援装置は、これらの協調送信パラメータに基づいて、メッセージの協調送信を行う。

＜３．２．３．処理の流れ＞
以下、図２４〜図２６を参照して、協調送信に関する処理の流れの一例を説明する。

図２４は、本実施形態に係る送信装置（例えば、ＵＥ１０）により実行される協調送信処理の流れの一例を示すフローチャートである。図２４に示すように、まず、ＵＥ１０は、協調送信タイプを選択する（ステップＳ２０２）。協調送信タイプには、例えば上記説明した変更無しリレータイプ、変更有りリレータイプ、及びインタフェース変更リレータイプ等がある。ＵＥ１０は、これらの協調送信タイプのいずれかひとつを選択する。次いで、ＵＥ１０は、協調送信パラメータを含むＰＳＣＣＨ及びＰＳＳＣＨを、ＰＣ５インタフェースを用いて送信する（ステップＳ２０４、Ｓ２０６）。

図２５は、本実施形態に係る支援装置（例えば、ＲＳＵ５０）により実行される協調送信処理の流れの一例を示すフローチャートである。図２５に示すように、まず、ＲＳＵ５０は、送信装置（例えば、ＵＥ１０）から受信したＰＳＣＣＨをデコードする（ステップＳ３０２）。次いで、ＲＳＵ５０は、協調送信指標が有効であるか否かを判定する（ステップＳ３０４）。有効でないと判定された場合（ステップＳ３０４／ＮＯ）、処理は終了する。一方で、有効であると判定された場合（ステップＳ３０４／ＹＥＳ）、ＲＳＵ５０は、協調送信タイプを確認する（ステップＳ３０６）。次に、ＲＳＵ５０は、送信装置から受信したＰＳＳＣＨをデコードする（ステップＳ３０８）。そして、ＲＳＵ５０は、デコードしたメッセージを、協調送信タイプに応じてＵＥ２０にリレーする（ステップＳ３１０）。例えば、協調送信タイプが変更無しリレータイプである場合、ＲＳＵ５０は、ＰＳＣＣＨで通知された協調送信パラメータに従い、ＰＣ５インタフェースでメッセージを送信する。例えば、協調送信タイプが変更有りリレータイプである場合、ＲＳＵ５０は、ＰＳＣＣＨで通知された協調送信パラメータに従い、且つＲＶを変更して、ＰＣ５インタフェースでメッセージを送信する。例えば、協調送信タイプがインタフェース変更リレータイプである場合、ＲＳＵ５０は、ＰＳＣＣＨで通知された協調送信パラメータに従い、Ｕｕインタフェースでメッセージを送信する。

図２６は、本実施形態に係る受信装置（例えば、ＵＥ２０）により実行される受信処理の流れの一例を示すフローチャートである。図２６に示すように、まず、ＵＥ２０は、送信装置（例えば、ＵＥ１０）から受信したＰＳＣＣＨをデコードする（ステップＳ４０２）。次いで、ＵＥ２０は、協調送信指標が有効であるか否かを判定する（ステップＳ４０４）。有効でないと判定された場合（ステップＳ４０４／ＮＯ）、ＵＥ２０は、送信装置から受信したＰＳＳＣＨをデコードする（ステップＳ４０６）。一方で、有効であると判定された場合（ステップＳ４０４／ＹＥＳ）、ＵＥ２０は、協調送信タイプを確認する（ステップＳ４０８）。次に、ＵＥ２０は、送信装置から受信したＰＳＳＣＨをデコードし（ステップＳ４１０）、支援装置（例えば、ＲＳＵ５０）から受信したＰＳＳＣＨをデコードする（ステップＳ４１２）。そして、ＵＥ２０は、各々のＰＳＳＣＨをデコードして得たパケットを合成する（ステップＳ４１４）。

＜３．３．代理送信＞
本通信方法は、支援装置（例えば、ＲＳＵ５０）が、送信装置（例えば、ＵＥ１０）の代理で受信装置（例えば、ＵＥ２０）にメッセージを送信する方法である。

本実施形態に係る支援装置は、送信装置から受信装置へＶ２Ｘ通信を用いて送信されるメッセージを、送信装置の代理で受信装置へ送信する。また、本実施形態に係る送信装置は、支援装置に送信装置の代理でＶ２Ｘ通信を用いてメッセージを送信させるための制御情報（後述する代理送信パラメータ）を、受信装置又は支援装置に送信する。そして、本実施形態に係る受信装置は、支援装置により送信装置の代理でＶ２Ｘ通信を用いて送信されたメッセージを受信する。このようにして、支援装置による豊富な電力を背景にした代理送信が実現されるので、受信品質が改善され、メッセージ到達確率が向上する。また、送信装置は、支援装置による代理送信により、繰り返し送信の回数を削減することが可能となり、電力消費を低減させることが可能となる。

例えば、送信装置は、代理送信のためのパラメータ（即ち、制御情報）を支援装置に通知し得る。支援装置は、送信装置から受信した本パラメータに基づいて、メッセージを受信装置にリレーする。このパラメータを、以下では代理送信パラメータとも称する。以下、代理送信パラメータに含まれ得る情報の一例を説明する。

・代理送信パラメータ
例えば、代理送信パラメータは、支援装置が代理送信を実施するか否か（即ち実施を要求するか否か）を示す代理送信指標を含み得る。これにより、受信装置及び支援装置は、代理送信が行われるか否かを知得することが可能となる。

また、代理送信パラメータは、送信装置の識別情報を示す送信装置ＩＤを含み得る。また、代理送信パラメータは、受信装置の識別情報を示す受信装置ＩＤを含み得る。代理送信パラメータは、受信装置ＩＤと共に、又は代えて受信装置グループＩＤを含み得る。

また、代理送信パラメータは、代理送信の対象のメッセージのＲＶ情報（ＲＶ値及び／又はＲＶパターン）を含み得る。

また、代理送信パラメータは、代理送信の対象のメッセージの繰り返し送信回数を含み得る。これにより、支援装置は、Ｖ２Ｘ通信の支援が可能か否かを判断可能である。例えば、繰り返し送信回数が上限値に達していなければ、送信装置による残りの繰り返し送信のタイミングでの、支援装置による代理送信が可能であると判断され得る。

また、代理送信パラメータは、代理送信の対象のメッセージの識別情報を示すメッセージＩＤ又はパケットＩＤを含み得る。

また、代理送信パラメータは、ＭＣＳ情報を含み得る。

また、代理送信パラメータは、ＴＡ情報を含み得る。支援装置は、ＴＡ情報を参照することで、リレータイミングを適切に制御することが可能となる。

また、代理送信パラメータは、周波数ホッピング指標（Frequency hopping indicator）情報を含み得る。支援装置は、周波数ホッピング指標を参照することで、リレーに用いる周波数リソースを適切に制御することが可能となる。

また、代理送信パラメータは、いつまでにリレー（即ち、送信）すべきかを示すリレー期限（即ち、送信期限）を示す情報を含み得る。

以上、代理送信パラメータの一例を説明した。代理送信パラメータは、ＰＳＣＣＨに含まれて通知されてもよい。また、代理送信パラメータは、ＰＳＣＣＨとＰＳＳＣＨとに分散して含まれていてもよい。例えば、ＰＳＳＣＨに、代理送信指標以外の代理送信パラメータが含まれ、ＰＳＣＣＨに、代理送信指標、及びその他の代理送信パラメータが含まれるＰＳＳＣＨ上の領域を示す情報が含まれてもよい。

・報告
送信装置は、支援装置による代理送信実施に伴い、自身の繰り返し送信を停止してもよい。例えば、支援装置は、代理送信パラメータの受信に成功して代理送信を実施する場合、代理送信を実施することを送信装置に報告する。送信装置は、この報告を受信した場合、自身の繰り返し送信を停止する。

支援装置は、代理送信が完了した場合、即ち規定の繰り返し送信回数分の送信を完了した場合、代理送信が完了したことを送信装置に報告してもよい。また、支援装置は、代理送信が完了しなかった場合はその旨を送信装置に報告してもよい。

・処理の流れ
以下、図２７を参照して、代理送信に関する処理の流れを説明する。

図２７は、本実施形態に係る送信装置（例えば、ＵＥ１０）により実行される代理送信処理の流れの一例を示すフローチャートである。図２７に示すように、まず、ＵＥ１０は、代理送信モードでメッセージを送信する（ステップＳ５０２）。ここで、ＵＥ１０は、メッセージと共に代理送信パラメータを含むＰＳＣＣＨを送信し得る。次いでＵＥ１０は、ＲＳＵ５０から代理送信を実施することを示す報告を受信したか否かを判定する（ステップＳ５０４）。報告を受信していないと判定された場合（ステップＳ５０４／ＮＯ）、ＵＥ１０は、メッセージの繰り返し送信を継続する（ステップＳ５０６）。一方で、報告を受信したと判定された場合（ステップＳ５０４／ＹＥＳ）、ＵＥ１０は、メッセージの繰り返し送信を停止する（ステップＳ５０８）。

＜３．４．Ｕｕ多重送信＞
本通信方法は、送信装置（例えば、ＵＥ１０）が、Ｖ２Ｘ通信を用いて受信装置（例えば、ＵＥ２０）に送信すべきＶ２Ｘトラフィックを、ＰＣ５インタフェースの代わりにＵｕインタフェースを用いて送信して、支援装置（例えば、ｅＮＢ３０）による支援を受ける方法である。

本実施形態に係る送信装置は、Ｖ２Ｘ通信を用いて送信するトラフィック（以下、Ｖ２Ｘトラフィックとも称する）をＵｕインタフェースで送信するトラフィック（以下、Ｕｕトラフィックとも称する）に多重して、Ｕｕインタフェースで支援装置に送信する。また、送信装置は、このＵｕインタフェースでの多重に関する制御情報（後述するＵｕ多重送信パラメータ）を、支援装置に送信する。本実施形態に係る支援装置は、Ｕｕインタフェースにおいて受信した、送信装置から受信装置へＶ２Ｘ通信を用いて送信されるＶ２Ｘトラフィックを、送信装置と協調して又は送信装置の代理で受信装置へ送信する。そして、本実施形態に係る受信装置は、送信装置の代理で又は送信装置と協調して支援装置から送信されたＶ２Ｘトラフィックを受信する。このようにして、支援装置による豊富な電力を背景にした協調送信又は代理送信が実現されるので、受信品質が改善され、メッセージ到達確率が向上する。また、送信装置は、支援装置による協調送信又は代理送信により、繰り返し送信の回数を削減することが可能となり、電力消費を低減させることが可能となる。また、送信装置は、ＰＣインタフェースの代わりにＵｕインタフェースを利用することとなり、セルが小さい場合には、ＰＣインタフェースを利用する場合よりも電力消費を低減させることが可能となる。

例えば、送信装置は、Ｕｕ多重送信のためのパラメータ（即ち、制御情報）を支援装置に通知し得る。支援装置は、送信装置から受信した本パラメータに基づいて、多重されたＶ２Ｘトラフィックを受信装置にリレーする。このパラメータを、以下ではＵｕ多重送信パラメータとも称する。以下、Ｕｕ多重送信パラメータに含まれ得る情報の一例を説明する。

・Ｕｕ多重送信パラメータ
例えば、Ｕｕ多重送信パラメータは、送信装置がＶ２ＸトラフィックをＵｕインタフェースで送信したか否かを示すＵｕ多重送信指標を含み得る。これにより、受信装置及び支援装置は、Ｕｕ多重送信が行われるか否かを知得することが可能となる。

また、Ｕｕ多重送信パラメータは、Ｕｕインタフェースを用いて送信される信号のうち、どの領域（例えば、周波数リソース及び時間リソース）にＶ２Ｘトラフィックが多重されたかを示すＵｕ多重領域情報を含み得る。これにより、支援装置は、Ｖ２Ｘトラフィックを適切に取得することが可能となる。

また、Ｕｕ多重送信パラメータは、いつまでＵｕインタフェース経由での多重送信を行うかを示すＵｕ多重送信有効期間を含み得る。

また、Ｕｕ多重送信パラメータは、送信装置の識別情報を含み得る。送信装置の識別情報としては、例えば、送信装置の位置情報、Ｌａｎｅ ＩＤ及びエリアＩＤ等が挙げられる。

また、Ｕｕ多重送信パラメータは、送信装置によるメジャメント結果を示すチャネルメジャメント情報を含み得る。

また、Ｕｕ多重送信パラメータは、受信装置の識別情報を示す受信装置ＩＤを含み得る。Ｕｕ多重送信パラメータは、受信装置ＩＤと共に、又は代えて受信装置グループＩＤを含み得る。

また、Ｕｕ多重送信パラメータは、Ｕｕ多重送信の対象のメッセージのＲＶ情報（ＲＶ値及び／又はＲＶパターン）を含み得る。

また、Ｕｕ多重送信パラメータは、Ｕｕ多重送信の対象のメッセージの繰り返し送信回数を含み得る。これにより、支援装置は、Ｖ２Ｘ通信の支援が可能か否かを判断可能である。例えば、繰り返し送信回数が上限値に達していなければ、送信装置による残りの繰り返し送信のタイミングでの、支援装置によるＵｕ多重送信が可能であると判断され得る。

また、Ｕｕ多重送信パラメータは、Ｕｕ多重送信の対象のメッセージの識別情報を示すメッセージＩＤ又はパケットＩＤを含み得る。

また、Ｕｕ多重送信パラメータは、いつまでにリレー（即ち、送信）すべきかを示すリレー期限（即ち、送信期限）を示す情報を含み得る。

以上、Ｕｕ多重送信パラメータの一例を説明した。Ｕｕ多重送信パラメータは、ＵＣＩ（Uplink Control Information）に含まれて通知されてもよい。また、Ｕｕ多重送信パラメータは、ＵＣＩと例えばＰＵＳＣＨ（Physical Uplink Shared Channel）とに分散して含まれていてもよい。例えば、ＰＵＳＣＨに、Ｕｕ多重送信指標及びＵｕ多重領域情報以外のＵｕ多重送信パラメータが含まれ、ＵＣＩに、Ｕｕ多重送信指標及びＵｕ多重領域情報が含まれてもよい。この場合、Ｕｕ多重領域情報は、Ｖ２Ｘトラフィックに加え、Ｕｕ多重送信指標及びＵｕ多重領域情報以外のＵｕ多重送信パラメータが含まれる領域を示す。

・報告
支援装置は、代理送信又は協調送信が完了した場合、即ち規定の繰り返し送信回数分の送信を完了した場合、代理送信又は協調送信が完了したことを送信装置に報告してもよい。また、支援装置は、代理送信又は協調送信が完了しなかった場合はその旨を送信装置に報告してもよい。なお、これら報告は、例えばＤＣＩ（Downlink Control Information）又はＰＨＩＣＨ（Physical Hybrid-ARQ Indicator Channel）を用いて行われ得る。

・処理の流れ
以下、図２８を参照して、Ｕｕ多重送信に関する処理の流れを説明する。

図２８は、本実施形態に係る送信装置（例えば、ＵＥ１０）により実行されるＵｕ多重送信処理の流れの一例を示すフローチャートである。図２８に示すように、まず、ＵＥ１０において、Ｖ２Ｘトラフィックが発生する（ステップＳ６０２）。次いで、ＵＥ１０は、Ｕｕトラフィックがあるか否かを判定する（ステップＳ６０４）。Ｕｕトラフィックがあると判定された場合（ステップＳ６０４／ＹＥＳ）、ＵＥ１０は、Ｕｕインタフェースでのスケジューリングリクエスト送信からスケジューリンググラント受信までの時間がＶ２Ｘメッセージの周期以下であるか否かを判定する（ステップＳ６０６）。Ｖ２Ｘメッセージの周期以下であると判定された場合（ステップＳ６０６／ＹＥＳ）、ＵＥ１０は、Ｖ２ＸトラフィックとＵｕトラフィックとを多重してＵｕインタフェースにて送信する、Ｕｕ多重送信を行う（ステップＳ６０８）。他方、Ｕｕトラフィックがないと判定された場合（ステップＳ６０４／ＮＯ）、又はＶ２Ｘメッセージの周期以下でないと判定された場合（ステップＳ６０６／ＮＯ）、ＵＥ１０は、ＰＣ５インタフェースでＶ２Ｘトラフィックを送信する（ステップＳ６１０）。

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

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

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

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

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

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

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

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

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

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

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

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

＜＜５．まとめ＞＞
以上、図１〜図３２を参照して、本開示の一実施形態について詳細に説明した。上記説明したように、支援装置は、送信装置から受信装置へＶ２Ｘ通信を用いて送信されるメッセージを、前記送信装置と協調して前記受信装置へ送信する。支援装置が、送信装置によるＶ２Ｘ通信を支援することで、メッセージ到達確率を向上させることが可能となると共に、送信装置による再送回数を削減することで送信装置の電力消費を低減させることが可能となる。

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

また、本明細書においてフローチャート及びシーケンス図を用いて説明した処理は、必ずしも図示された順序で実行されなくてもよい。いくつかの処理ステップは、並列的に実行されてもよい。また、追加的な処理ステップが採用されてもよく、一部の処理ステップが省略されてもよい。

また、本明細書の装置（例えば、ＵＥ１０、ＵＥ２０、ｅＮＢ３０又はＲＳＵ５０、又はこれらの装置のためのモジュール）に備えられるプロセッサ（例えば、ＣＰＵ、ＤＳＰなど）を上記装置の構成要素（例えば、処理部１５０、処理部２５０、処理部３５０又は処理部５４０など）として機能させるためのコンピュータプログラム（換言すると、上記プロセッサに上記装置の構成要素の動作を実行させるためのコンピュータプログラム）も作成可能である。また、当該コンピュータプログラムを記録した記録媒体も提供されてもよい。また、上記コンピュータプログラムを記憶するメモリと、上記コンピュータプログラムを実行可能な１つ以上のプロセッサとを備える装置（例えば、基地局、基地局装置若しくは基地局装置のためのモジュール、又は、端末装置若しくは端末装置のためのモジュール）も提供されてもよい。また、上記装置の構成要素の動作を含む方法も、本開示に係る技術に含まれる。

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

なお、以下のような構成も本開示の技術的範囲に属する。
（１）
送信装置から受信装置へＶ２Ｘ通信を用いて送信されるメッセージを、前記送信装置と協調して前記受信装置へ送信する処理部、
を備える通信装置。
（２）
前記処理部は、前記送信装置から受信した制御情報に基づいて前記メッセージを前記受信装置へ送信する、前記（１）に記載の通信装置。
（３）
前記処理部は、前記制御情報に基づいて前記メッセージの送信に用いる無線リソースを設定する、前記（２）に記載の通信装置。
（４）
前記制御情報は、前記送信装置との協調を実施するか否かを示す情報を含む、前記（２）又は（３）に記載の通信装置。
（５）
前記制御情報は、前記送信装置との協調のタイプを示す情報を含む、前記（２）〜（４）のいずれか一項に記載の通信装置。
（６）
前記制御情報は、前記送信装置又は前記受信装置の識別情報を含む、前記（２）〜（５）のいずれか一項に記載の通信装置。
（７）
前記制御情報は、前記メッセージのＲＶ（Redundancy Version）情報を含む、前記（２）〜（６）のいずれか一項に記載の通信装置。
（８）
前記制御情報は、前記メッセージの識別情報を含む、前記（２）〜（７）のいずれか一項に記載の通信装置。
（９）
前記制御情報は、前記受信装置への送信に用いるべき無線リソースを示す情報を含む、前記（２）〜（８）のいずれか一項に記載の通信装置。
（１０）
前記処理部は、前記送信装置から送信される前記メッセージのＲＶ（Redundancy Version）を変更して前記受信装置へ送信する、前記（１）〜（９）のいずれか一項に記載の通信装置。
（１１）
前記処理部は、ＲＶを前記送信装置から受信した制御情報に基づいて変更する、前記（１０）に記載の通信装置。
（１２）
前記処理部は、ＲＶをランダムに変更する、前記（１０）に記載の通信装置。
（１３）
前記処理部は、前記送信装置からＰＣ５インタフェースで送信された前記メッセージを、ＰＣ５インタフェースで前記受信装置へ送信する、前記（１）〜（１２）のいずれか一項に記載の通信装置。
（１４）
前記処理部は、前記送信装置からＰＣ５インタフェースで送信された前記メッセージを、Ｕｕインタフェースで前記受信装置へ送信する、前記（１）〜（１２）のいずれか一項に記載の通信装置。
（１５）
前記処理部は、前記送信装置から受信した前記メッセージの送信期限を示す情報を含む制御情報に基づいて、前記メッセージをＵｕインタフェースで前記受信装置へ送信する、前記（１４）に記載の通信装置。
（１６）
前記処理部は、中継装置から受信した前記メッセージを前記受信装置へ送信する、前記（１）〜（１２）のいずれか一項に記載の通信装置。
（１７）
前記処理部は、前記送信装置と協調して前記受信装置へ前記メッセージを送信可能であることを示す情報を前記送信装置に通知する、前記（１）〜（１６）のいずれか一項に記載の通信装置。
（１８）
送信装置から受信装置へＶ２Ｘ通信を用いて送信されるメッセージを、プロセッサにより前記送信装置と協調して前記受信装置へ送信すること、
を含む通信方法。
（１９）
送信装置であって、
前記送信装置と協調してメッセージを送信する通信装置によりＶ２Ｘ通信を用いて送信されるメッセージと前記送信装置がＶ２Ｘ通信を用いて送信するメッセージとを受信装置に合成させるための制御情報を送信する処理部、
を備える送信装置。
（２０）
送信装置によりＶ２Ｘ通信を用いて送信されるメッセージと、前記送信装置と協調してメッセージを送信する通信装置から送信されるメッセージとを、受信した制御情報に基づいて合成する処理部、
を備える受信装置。

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

Claims (20)

1. 送信装置から受信装置へＶ２Ｘ通信を用いて送信されるメッセージを、前記送信装置と協調して前記受信装置へ送信する処理部、
   を備える通信装置。
2. 前記処理部は、前記送信装置から受信した制御情報に基づいて前記メッセージを前記受信装置へ送信する、請求項１に記載の通信装置。
3. 前記処理部は、前記制御情報に基づいて前記メッセージの送信に用いる無線リソースを設定する、請求項２に記載の通信装置。
4. 前記制御情報は、前記送信装置との協調を実施するか否かを示す情報を含む、請求項２に記載の通信装置。
5. 前記制御情報は、前記送信装置との協調のタイプを示す情報を含む、請求項２に記載の通信装置。
6. 前記制御情報は、前記送信装置又は前記受信装置の識別情報を含む、請求項２に記載の通信装置。
7. 前記制御情報は、前記メッセージのＲＶ（Redundancy Version）情報を含む、請求項２に記載の通信装置。
8. 前記制御情報は、前記メッセージの識別情報を含む、請求項２に記載の通信装置。
9. 前記制御情報は、前記受信装置への送信に用いるべき無線リソースを示す情報を含む、請求項２に記載の通信装置。
10. 前記処理部は、前記送信装置から送信される前記メッセージのＲＶ（Redundancy Version）を変更して前記受信装置へ送信する、請求項１に記載の通信装置。
11. 前記処理部は、ＲＶを前記送信装置から受信した制御情報に基づいて変更する、請求項１０に記載の通信装置。
12. 前記処理部は、ＲＶをランダムに変更する、請求項１０に記載の通信装置。
13. 前記処理部は、前記送信装置からＰＣ５インタフェースで送信された前記メッセージを、ＰＣ５インタフェースで前記受信装置へ送信する、請求項１に記載の通信装置。
14. 前記処理部は、前記送信装置からＰＣ５インタフェースで送信された前記メッセージを、Ｕｕインタフェースで前記受信装置へ送信する、請求項１に記載の通信装置。
15. 前記処理部は、前記送信装置から受信した前記メッセージの送信期限を示す情報を含む制御情報に基づいて、前記メッセージをＵｕインタフェースで前記受信装置へ送信する、請求項１４に記載の通信装置。
16. 前記処理部は、中継装置から受信した前記メッセージを前記受信装置へ送信する、請求項１に記載の通信装置。
17. 前記処理部は、前記送信装置と協調して前記受信装置へ前記メッセージを送信可能であることを示す情報を前記送信装置に通知する、請求項１に記載の通信装置。
18. 送信装置から受信装置へＶ２Ｘ通信を用いて送信されるメッセージを、プロセッサにより前記送信装置と協調して前記受信装置へ送信すること、
    を含む通信方法。
19. 送信装置であって、
    前記送信装置と協調してメッセージを送信する通信装置によりＶ２Ｘ通信を用いて送信されるメッセージと前記送信装置がＶ２Ｘ通信を用いて送信するメッセージとを受信装置に合成させるための制御情報を送信する処理部、
    を備える送信装置。
20. 送信装置によりＶ２Ｘ通信を用いて送信されるメッセージと、前記送信装置と協調してメッセージを送信する通信装置から送信されるメッセージとを、受信した制御情報に基づいて合成する処理部、
    を備える受信装置。

Images