このアプリケーションの一部のコンテンツは現時点では利用できません。
このような状況が続く場合は、にお問い合わせくださいフィードバック & お問い合わせ
1. (WO2019064986) 通信装置及び通信方法
Document

明 細 書

発明の名称 通信装置及び通信方法

技術分野

0001  

背景技術

0002   0003  

先行技術文献

特許文献

0004  

発明の概要

発明が解決しようとする課題

0005  

課題を解決するための手段

0006   0007   0008   0009   0010   0011   0012  

発明の効果

0013   0014   0015  

図面の簡単な説明

0016  

発明を実施するための形態

0017   0018   0019   0020   0021   0022   0023   0024   0025   0026   0027   0028   0029   0030   0031   0032   0033   0034   0035   0036   0037   0038   0039   0040   0041   0042   0043   0044   0045   0046   0047   0048   0049   0050   0051   0052   0053   0054   0055   0056   0057   0058   0059   0060   0061   0062   0063   0064   0065   0066   0067   0068   0069   0070   0071   0072   0073   0074   0075   0076   0077   0078   0079   0080   0081   0082   0083   0084   0085   0086   0087   0088   0089   0090   0091   0092   0093   0094   0095   0096   0097   0098   0099   0100   0101   0102   0103   0104   0105   0106   0107   0108   0109   0110   0111   0112   0113   0114   0115   0116   0117   0118   0119   0120   0121   0122   0123   0124   0125   0126   0127   0128   0129   0130   0131   0132   0133   0134   0135   0136   0137   0138   0139   0140   0141   0142   0143   0144   0145   0146   0147   0148   0149   0150   0151   0152   0153   0154   0155   0156   0157   0158   0159   0160   0161   0162   0163   0164   0165   0166   0167   0168   0169   0170   0171   0172   0173   0174   0175   0176   0177   0178   0179   0180   0181   0182   0183   0184   0185   0186   0187  

産業上の利用可能性

0188   0189   0190   0191  

符号の説明

0192  

請求の範囲

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20  

図面

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18  

明 細 書

発明の名称 : 通信装置及び通信方法

技術分野

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

背景技術

[0002]
 将来の自動運転の実現のため、近年、車載通信(V2X通信)への期待が高まってきている。V2X通信とは、Vehicleto X通信の略であり、車と「何か」が通信を行うシステムである。ここでの「何か」の例として、Vehicle、 Infrastructure、Network、Pedestrianなどが挙げられる(V2V、V2I/N、V2P)。
[0003]
 自動車向けの無線通信としては、これまで主に、IEEE802.11pベースのDSRC(Dedicated Short Range Communication)の開発が進められてきた。近年になり、3GPP(Third Generation Partnership Project)において、LTE(Long Term Evolution)ベースの車載通信である“LTE-basedV2X”の標準規格化が行われた。3GPPにおいては、さらに、5G(NR:New Radio)において、V2Xの標準化活動が継続している(例えば、特許文献1を参照のこと)。

先行技術文献

特許文献

[0004]
特許文献1 : 特開2017-139659号公報

発明の概要

発明が解決しようとする課題

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

課題を解決するための手段

[0006]
 本明細書で開示する技術の第1の側面は、基地局の配下で端末として動作する通信装置であって、
 無線信号を送受信する通信部と、
 前記通信部による、所定のリソースプールを用いたデータの送信を制御する制御部と、
を具備し、
 前記制御部は、パケット受信時において、前記基地局から通知される情報、他端末から通知される情報、又は、前記端末自身から得られる情報のうち少なくとも1つに基づいて、前記所定のリソースプール内でのパケットのリレー通信の実施を制御する、
通信装置である。
[0007]
 前記制御部は、前記基地局から通知される、リレー通信を実施すべきエリア又は実施してもよいエリアを示す情報、前記基地局からのリレー通信の実施の指示又はリレー通信の停止の指示に基づいて、リレー通信の実施を判定する。
[0008]
 また、前記制御部は、前記パケットの送信元端末から得られる、前記パケットの送信用リソースの割り当て方法に関する情報、前記パケットの優先度情報、前記パケットの鮮度情報、
[0009]
 前記制御部は、前記パケットの通信に用いるチャネルの混雑度、前記チャネルの状態、前記パケットの再送情報、又は、前記端末自身の位置情報のうち少なくとも1つに基づいて、リレー通信の実施を判定する。
[0010]
 また、前記制御部は、リレー通信用のリソースの確保をさらに制御する。前記制御部は、前記リソースプール内でのリレー通信用のリソースのセンシングを制御し、又は、前記パケットの送信元端末が予約したリレー通信用のリソースを用いた前記パケットのリレー通信の実施を制御し、又は、前記基地局が確保したリレー通信用のリソースを用いた前記パケットのリレー通信の実施を制御する。
[0011]
 また、前記制御部は、パケットの鮮度情報、パケットの優先度情報、チャネル混雑度などに応じて、前記パケットのリレー通信の実施確率をさらに制御する。
[0012]
 また、本明細書で開示する技術の第2の側面は、基地局の配下で端末として動作する通信装置における通信方法であって、
 所定のリソースプールにおいてパケットを受信するステップと、
 前記基地局から通知される情報、他端末から通知される情報、又は、前記端末自身から得られる情報のうち少なくとも1つに基づいて、前記パケットのリレー通信の実施を制御するステップと、
を有する通信方法である。

発明の効果

[0013]
 本明細書で開示する技術によれば、端末間で直接通信を行う通信装置及び通信方法を提供することができる。
[0014]
 なお、本明細書に記載された効果は、あくまでも例示であり、本発明の効果はこれに限定されるものではない。また、本発明が、上記の効果以外に、さらに付加的な効果を奏する場合もある。
[0015]
 本明細書で開示する技術のさらに他の目的、特徴や利点は、後述する実施形態や添付する図面に基づくより詳細な説明によって明らかになるであろう。

図面の簡単な説明

[0016]
[図1] 図1は、V2X通信の概要を示した図である。
[図2] 図2は、V2V通信の第1のシナリオを示した図である。
[図3] 図3は、V2V通信の第2のシナリオを示した図である。
[図4] 図4は、V2V通信の第3のシナリオを示した図である。
[図5] 図5は、V2V通信の第4のシナリオを示した図である。
[図6] 図6は、V2V通信の第5のシナリオを示した図である。
[図7] 図7は、V2X通信が実施される無線通信システムの構成例を模式的に示した図である。
[図8] 図8は、ユーザが携行する通信装置(UE)の機能的構成例を模式的に示した図である。
[図9] 図9は、車両などの移動体に搭載して用いられる通信装置(UE)の機能的構成例を模式的に示した図である。
[図10] 図10は、基地局(E-UTRAN、eNB)として動作する通信装置の機能的構成例を模式的に示した図である。
[図11] 図11は、RSUとして動作する通信装置の機能的構成例を模式的に示した図である。
[図12] 図12は、V2Xリレー通信において想定されるシナリオを例示した図である。
[図13] 図13は、端末が信号を受信したときに実施する処理手順を示したフローチャートである。
[図14] 図14は、リレー端末がパケットのリレー通信の実施判定を行う処理手順を示したフローチャートである。
[図15] 図15は、送信元端末がリレー通信用のリソースを予約してリレー通信を行う通信シーケンス例を示した図である。
[図16] 図16は、リレー通信用リソースの割り当て例を示した図である。
[図17] 図17は、リレー端末がハイブリッドなリレー通信用リソースの確保方法によりリレー通信を実施するための処理手順を示したフローチャートである。
[図18] 図18は、基地局がサイドリンクにおけるリレー通信用リソースの割り当てを行う通信シーケンス例を示した図である。

発明を実施するための形態

[0017]
 以下、図面を参照しながら本明細書で開示する技術の実施形態について詳細に説明する。
[0018]
A.システム構成
 車両などの移動体に通信装置を搭載することによって、移動体と種々の対象物との間で直接的な通信が実現される。とりわけ、車両と種々の対象物との間の通信はV2X通信と呼ばれる。図1には、V2X通信の概要を示している。図示のように、V2X通信として、V2V(Vehicle to Vehicle)通信、V2I(Vehicle to Infrastructure)通信、V2P(Vehicle to Pedestrian)通信、V2H(Vehicle to Home)通信などが挙げられる。また、図示を省略するが、V2N(Vehicle to Network)通信も、V2X通信に含まれる。なお、V2X通信の1文字目と3文字目は、それぞれ通信の始点と終点を意味しており、通信経路を限定するものではない。例えば、V2V通信は、車両同士が直接的に通信することと、基地局などを介して車両同士が間接的に通信することの両方を含む概念である。
[0019]
 V2V通信における車両の通信対象として、乗用車(passenger vehicle)、商用車(Commercial or fleet vehicle)、緊急車両(Emergency vehicle)、輸送車(Transit vehicle)などが挙げられる。また、V2I通信における車両の通信対象として、セルラーネットワーク(Celluler network)、データセンタ(Data centre)、商用車管理センタ(fleet or freight management centre)、交通管理センタ(Traffic management centre)、気象サービス(Weather service)、列車運行センタ(Rail operation centre)、駐車システム(Parking system)、料金システム(Toll system)などが挙げられる。また、V2P通信における車両の通信対象として、自転車の運転者(Cyclist)、歩行者用シェルタ(Pedestrian shelter)、自動二輪(Motorcycle)などが挙げられる。また、V2H通信における車両の通信対象として、家庭用ネットワーク(Home network)、車庫(Garage)、商用ネットワーク(Enterprise or deeler networks)などが挙げられる。
[0020]
 V2V通信における車両の通信対象として、乗用車(passenger vehicle)、商用車(Commercial or fleet vehicle)、緊急車両(Emergency vehicle)、輸送車(Transit vehicle)などが挙げられる。また、V2I通信における車両の通信対象として、セルラーネットワーク(Celluler network)、データセンタ(Data centre)、商用車管理センタ(fleet or freight management centre)、交通管理センタ(Traffic management centre)、気象サービス(Weather service)、列車運行センタ(Rail operation centre)、駐車システム(Parking system)、料金システム(Toll system)などが挙げられる。また、V2P通信における車両の通信対象として、自転車の運転者(Cyclist)、歩行者用シェルタ(Pedestrian shelter)、自動二輪(Motorcycle)などが挙げられる。また、V2H通信における車両の通信対象として、家庭用ネットワーク(Home network)、車庫(Garage)、商用ネットワーク(Enterprise or deeler networks)などが挙げられる。
[0021]
 自動車向けの無線通信としては、これまで主にIEEE802.11pベースのDSRCの開発が進められてきたが、近年になり、3GPPにおいてLTE-basedV2Xの標準規格化が行われた(前述)。LTEベースのV2X通信では、基本的なセーフティメッセージなどのやり取りなどがサポートされている。
[0022]
 一方で、さらなるV2X通信の改善をめざし、3GPPでは5G技術を用いたeV2X(enhanced V2X)通信の検討が行われている。eV2X通信では、これまでLTEベースのV2Xではサポートできなかったような、高信頼性、低遅延、高速通信、及びハイキャパシティを必要とする新たなユースケースをサポートする。eV2X向けのユースケース及び要求事項は3GPP TR22.886に記載されている。eV2Xによってサポートされる主なユースケースとして、以下の(1)~(4)が挙げられる。
[0023]
(1)Vehicle Platoonning
 複数の車両が隊列となり、同じ方向に走行する、隊列走行のユースケースであり、隊列走行を主導する車から隊列走行を制御するための情報をやり取りする。これらの情報のやりとりにより、隊列走行の車間距離をより詰めることが可能となる。
[0024]
(2)Extended Sensors
 センサー関連の情報(データ処理前のRawデータや処理されたデータ)を車車間などで交換することを可能とする。センサー情報は、ローカルセンサーや、周辺の車両やRSU(Road Side Unit:路側ユニット)や歩行者間のライブビデオイメージやV2Xアプリケーションサーバなどを通して集められる。車両はこれらの情報交換により、自身のセンサー情報では得られない情報を入手することができ、より広範囲の環境を認知若しくは認識することが可能となる。多くの情報を交換する必要があるため、通信には高いデータレートが求められる。
[0025]
(3)Advanced Driving
 準自動走行や、完全自動走行を可能とする。それぞれの車両はRSUが自身のセンサーなどから得られた認知/認識情報を周辺車両へとシェアすることで、車両の軌道や操作を同期、協調しながら調整することができる。それぞれの車両は、ドライビングの意図や意思を周辺車両とシェアすることも可能である。
[0026]
(4)Remote Driving
 遠隔操縦者やV2Xアプリケーションに遠隔操縦させる。運転ができない人や、危険地域に対して遠隔操作が用いられる。ルートや走行する道がある程度決まっているような公共交通機関に対しては、クラウドコンピューティングをベースとした操縦を用いることも可能である。高い信頼性と低い伝送遅延が通信には求められる。
[0027]
 上述したようなユースケース(1)~(4)を実現するためには、eV2X通信の物理レイヤのエンハンスメントが必要となる。主なエンハンスメントとしては、インフラ、端末間通信の改善、及び端末間通信の改善が挙げられる。インフラ、端末間通信としては、V2N通信並びにV2I(eNB(evolved Node B) type RSU:基地局型RSU)通信が改善の対象となる。また、端末間通信としては、V2V通信並びにV2P通信が改善の対象となる。これらV2X通信の物理レイヤにおいて必要と考えられる主なエンハンスメントのポイントを以下に示す。
[0028]
・チャネルフォーマット
 -Flexible numerology
 -short TTI(Transmission Time Interval)
 -マルチアンテナ対応
 -Waveformエンハンスメント
・サイドリンクフィードバック通信
 -HARQ(Hybrid Automatic Repeat Request)
 -CSI(Channel Status Information)
・サイドリンク通信におけるリソース割り当て方式
・車両位置情報推定技術
・端末間リレー通信
・ユニキャスト通信、マルチキャスト通信のサポート
・マルチキャリア通信、キャリアアグリゲーション
・高周波周波数(ミリ波)対応(例:6GHz以上)
[0029]
 本明細書では、eV2X通信の物理レイヤのエンハンスメントのうち、とりわけ端末間リレー通信若しくはサイドリンクリレー通信に着目するが、この点の詳細については後述に譲る。
[0030]
 V2X通信のオペレーションシナリオはさまざまである。V2X通信のオペレーションシナリオは、V2V通信をベースに構成され、片方の自動車がPedesrianになるとV2P通信となり、InfrastructureやNetworkで終端するとV2I通信又はV2N通信となる。図2~図6には、V2X通信のベースとなるV2V通信のシナリオを例示している。
[0031]
 図2には、V2V通信の第1のシナリオを示している。第1のシナリオでは、車両などの移動体同士が直接的にV2V通信を行う。この場合の車両同士が直接的に通信を行う通信リンクは、SL(サイドリンク)である。
[0032]
 図3には、V2V通信の第2のシナリオを示している。第2のシナリオでは、車両などの移動体同士が、E-UTRAN(Evolved Universa  Terrestrial Radio Access)を介して、すなわち基地局を介して間接的にV2V通信を行う。送信側から基地局への通信リンクはUL(アップリンク)であり、基地局から受信側への通信リンクはDL(ダウンリンク)である。
[0033]
 図4には、V2V通信の第3のシナリオを示している。第3のシナリオでは、車両などの移動体が、RSU又はRSUタイプのユーザ端末(User Equipment:UE)、及びE-UTRANを順に介して他の移動体へ信号を送信する。各装置間の通信リンクは、順にSL、UL、及びDLである。
[0034]
 図5には、V2V通信の第4のシナリオを示している。第4のシナリオでは、車両などの移動体が、E-UTRAN、及びRSU又はRSUタイプのUEを順に介して他の移動体へ信号を送信する。各装置間の通信リンクは、順にUL、DL及びSLである。
[0035]
 図6には、V2V通信の第5のシナリオを示している。第5のシナリオでは、車両などの移動体同士が、RSU又はRSUタイプのUEを介して間接的にV2V通信を行う。移動体とRSU又はRSUタイプのUEとの間の通信リンクは、SLである。
[0036]
 図2~図6に示した各シナリオは、移動体の片方を歩行者に変えると、V2P通信のシナリオとなる。同様に、各シナリオは、移動体の片方をインフラ又はネットワークに変えると、それぞれV2I通信又はV2N通信のシナリオとなる。
[0037]
 図7には、V2X通信が実施される無線通信システムの構成例を模式的に示している。図示の無線通信システムは、UE10と、UE20と、車両22と、eNB(基地局)30と、GNSS(Global Navigation Satellite System)衛星40と、RSU50で構成される。
[0038]
 eNB30は、セル内に位置するUE20にセルラー通信サービスを提供するセルラー基地局である。例えば、eNB30は、UE10及びUE20が通信するためのリソースをスケジュールし、スケジュールしたリソースをUE10及びUE20に通知する。そして、eNB30は、当該リソースにおいてUE10及びUE20との間でアップリンク通信又はダウンリンク通信を行う。
[0039]
 GNSS衛星40は、地球を所定の軌道に沿って周回する人工衛星(通信装置)である。GNSS衛星40は、航法メッセージを含むGNSS信号を送信する。航法メッセージは、GNSS衛星40の軌道情報及び時間情報などの、位置測定のための種々の情報を含む。
[0040]
 RSU50は、道路脇に設置される通信装置である。RSU50は、車両22若しくは車両22に搭載されたUE20、又はユーザ12が携行するUE10と双方向通信を行うことができる。なお、RSU50は、車両22若しくは車両22に搭載されたUE20、又はユーザ12が携行するUE10とDSRC通信を行うことができる。また、本実施形態では、RSU50が、車両22若しくは車両22に搭載されたUE20、又はユーザ12が携行するUE10とセルラー通信の方式に従って通信することも想定される。
[0041]
 UE20は、車両22に搭載され、車両22の走行に伴って移動する通信装置である。UE20は、eNB30による制御に従ってeNB30と通信する機能を有する。また、UE20は、GNSS衛星40から送信されるGNSS信号を受信し、GNSS信号に含まれる航法メッセージからUE20の位置情報を測定する機能を有する。また、UE20は、RSU50と通信する機能を有する。さらに、本実施形態によるUE20は、ユーザ12に携行されるUE10、又は他の車両22に搭載されたUE20と直接通信すること、すなわち、サイドリンクなどのD2D通信を行うことも可能である。以下では、UE20及び移動体22を特に区別する必要がない場合、UE20と総称する。
[0042]
 UE10は、ユーザ12に携行され、ユーザ12の歩行、走行又はユーザ12が乗車した乗り物(バス、バイク、又は車両など)の移動に伴って移動する通信装置である。UE10は、eNB30による制御に従ってeNB30と通信する機能を有する。また、UE10は、GNSS衛星40から送信されるGNSS信号を受信し、GNSS信号に含まれる航法メッセージからUE10の位置情報を測定する機能を有する。また、UE10は、RSU50と通信する機能を有する。さらに、本実施形態では、UE10は、他のUE10又はUE20と直接通信すること、すなわち、サイドリンクなどのD2D通信を行うことも可能である。UE10とUE20との通信はV2P通信でもある。
[0043]
 なお、図7では移動体の一例として車両22を示しているが、移動体は車両22に限定されない。例えば、移動体は、船舶、航空機及び自転車などであってもよい。また、上記では、UE20がGNSS信号を受信する機能を有することを説明したが、車両22がGNSS信号を受信する機能を有し、車両22がGNSS信号の受信結果をUE20に出力してもよい。
[0044]
 図8には、通信装置の機能的構成例を模式的に示している。図8に示す通信装置は、例えば、図7に示した無線通信システムのうちユーザ12に携行されるUE10に対応する。また、図8に示す通信装置は、サイドリンクリレー通信を行うリレー端末としても動作するものとする。
[0045]
 図8に示すように、UE10は、アンテナ部110と、無線通信部120、GNSS信号処理部130と、記憶部140と、処理部150を備えている。
[0046]
 アンテナ部110は、無線通信部120により出力される信号を電波として空間に放射する。また、アンテナ部110は、空間の電波を信号に変換し、当該信号を無線通信部120へ出力する。
[0047]
 無線通信部120は、信号を送受信する。例えば、無線通信部120は、eNB30からのダウンリンク信号を受信し、eNB30へのアップリンク信号を送信する。また、無線通信部120は、他のUE10、UE20又はRSU50との間でサイドリンク信号を送受信する。
[0048]
 GNSS信号処理部130は、GNSS衛星10から送信されたGNSS信号についての処理を行う構成である。例えば、GNSS信号処理部130は、GNSS信号を処理することにより、UE10の位置情報及び時間情報を測定する。
[0049]
 記憶部140は、UE10の動作のためのプログラム及びさまざまなデータを、一時的に又は不揮発的に記憶する。
[0050]
 処理部150は、UE10のさまざまな機能を提供する。例えば、処理部150は、無線通信部120により行われる通信を制御する。後述するサイドリンクリレー通信におけるリレー端末としてのUE10の通信動作は、基本的には処理部150の制御によって実現されるものとする。
[0051]
 図9には、車両などの移動体に搭載して用いられる通信装置の機能的構成例を模式的に示している。図9に示す通信装置は、例えば、図7に示した無線通信システムのうち車両22に搭載されるUE20に対応する。また、図9に示す通信装置は、サイドリンクリレー通信を行うリレー端末としても動作するものとする。
[0052]
 図9に示すように、UE20は、アンテナ部210と、無線通信部220、GNSS信号処理部230と、記憶部240と、処理部250を備えている。
[0053]
 アンテナ部210は、無線通信部220により出力される信号を電波として空間に放射する。また、アンテナ部210は、空間の電波を信号に変換し、当該信号を無線通信部220へ出力する。
[0054]
 無線通信部220は、信号を送受信する。例えば、無線通信部220は、eNB30からのダウンリンク信号を受信し、eNB30へのアップリンク信号を送信する。また、無線通信部220は、UE10、他のUE20又はRSU50との間でサイドリンク信号を送受信する。
[0055]
 GNSS信号処理部230は、GNSS衛星40から送信されたGNSS信号についての処理を行う構成である。例えば、GNSS信号処理部230は、GNSS信号を処理することにより、UE20の位置情報及び時間情報を測定する。
[0056]
 記憶部240は、UE20の動作のためのプログラム及びさまざまなデータを、一時的に又は不揮発的に記憶する。
[0057]
 処理部250は、UE20のさまざまな機能を提供する。例えば、処理部250は、無線通信部220により行われる通信を制御する。後述するサイドリンクリレー通信におけるリレー端末としてのUE20の通信動作は、基本的には処理部250の制御によって実現されるものとする。
[0058]
 また、図10には、主に基地局として動作する通信装置の機能的構成例を模式的に示している。図10に示す通信装置は、例えば図2~図6に示したV2V通信環境におけるE-UTRAN、若しくは図7に示した無線通信システムにおけるeNB30に対応する。
[0059]
 図10に示すように、eNB30は、アンテナ部310と、無線通信部320、ネットワーク通信部330と、記憶部340と、処理部350を備えている。
[0060]
 アンテナ部310は、無線通信部320により出力される信号を電波として空間に放射する。また、アンテナ部310は、空間の電波を信号に変換し、当該信号を無線通信部320へ出力する。
[0061]
 無線通信部320は、信号を送受信する。例えば、無線通信部320は、UE10、UE20、又はRSU50からのアップリンク信号を受信し、UE10、UE20、又はRSU50へのダウンリンク信号を送信する。
[0062]
 ネットワーク通信部330は、図示しないネットワークを経由して情報を送受信する。例えば、ネットワーク通信部330は、他のノードへの情報を送信し、他のノードからの情報を受信する。ここで言う他のノードは、他の基地局及びコアネットワークノードを含むものとする。
[0063]
 記憶部340は、eNB30の動作のためのプログラム及びさまざまなデータを、一時的に又は不揮発的に記憶する。
[0064]
 処理部350は、eNB30のさまざまな機能を提供する。例えば、処理部350は、配下のユーザ端末(UE10、UE20)、及びRSU50により行われる通信を制御する。
[0065]
 さらに本実施形態では、処理部350は、サイドリンクリレー通信において、配下のユーザ端末(UE10、UE20)、及びRSU50などがリレー端末としてリレーの実施を行うかどうかを判定し、判定結果を各端末に通知する処理を行う場合もある。
[0066]
 図11には、図7に示した無線通信システムにおいてRSU50として用いられる通信装置の機能的構成例を模式的に示している。図示のように、RSU50は、アンテナ部510と、無線通信部520、記憶部530と、処理部540を備えている。
[0067]
 アンテナ部510は、無線通信部520により出力される信号を電波として空間に放射する。また、アンテナ部510は、空間の電波を信号に変換し、当該信号を無線通信部520へ出力する。
[0068]
 無線通信部520は、信号を送受信する。例えば、無線通信部520は、eNB30からのダウンリンク信号を受信し、eNB30へのアップリンク信号を送信する。また、無線通信部520は、UE10、UE20、又は他のRSU50との間でサイドリンク信号を送受信する。
[0069]
 記憶部530は、RSU50の動作のためのプログラム及びさまざまなデータを、一時的に又は不揮発的に記憶する。
[0070]
 処理部540は、RSU50のさまざまな機能を提供する。例えば、処理部540は、無線通信部520により行われる通信を制御する。後述するサイドリンクリレー通信におけるリレー端末としてのRSU50の通信動作は、基本的には処理部540の制御によって実現されるものとする。
[0071]
B.サイドリンクリレー通信
 eV2X通信では、6GHz以上の、ミリ波とも呼ばれる高周波周波数を用いることが想定されている(前述)。高周波周波数信号は、直進性が高く、且つ距離減衰が激しい。このため、自動車向けの通信環境を想定すると、交差点や車混雑時には、V2X通信(とりわけ、V2V通信やV2P通信)で見通し通信を確保することが難しくなる。
[0072]
 そこで、本明細書では、eV2X通信の物理レイヤのエンハンスメントのうち、とりわけ端末間リレー通信若しくはサイドリンクリレー通信に着目して、このような課題を解決する。
[0073]
B-1.V2Xリレー通信の想定シナリオ
 図12には、V2Xリレー通信において想定されるシナリオを例示している。V2Xリレー通信の主なデプロイメント(V、I(N)、P、…の組み合わせ)は以下に示す通りである。端末間の通信には、例えば6GHz以上の高周波数が用いられることを想定している。
[0074]
・V2V2X通信               - 車⇔車
・I2I2X通信               - インフラ⇔インフラ
・P2P2X通信               - 歩行者⇔歩行者
・V2I2X通信(I2V2Xを含む)     - 車⇔インフラ
・P2I2X通信(P2V2Xを含む)     - 歩行者⇔インフラ
・P2V2X通信(V2P2Xを含む)     - 歩行者⇔車
[0075]
B-2.V2Xリレー通信の適用判断処理
 図12に示した各端末は、信号を受信したときにリレー通信を実施するかどうかを判断する。図13には、端末が信号を受信したときに実施する処理手順をフローチャートの形式で示している。ここで言う端末は、Vehicleでもよく、RSUのようなInfrastructureでもよく、あるいはPedestrian端末のようなVulnerableユーザであってもよい。すなわち、リレー端末は図8、図9、若しくは図11に示した通信装置に相当する。
[0076]
 端末は、信号を受信したとき、リレー通信実施のための条件をクリアしているかどうかをチェックする(ステップS1301)。そして、リレー通信実施のための条件をクリアしている場合にのみ(ステップS1301のYes)、リレー通信を実施する(ステップS1302)。それ以外の場合には(ステップS1301のNo)、リレー通信を実施しない(ステップS1303)。
[0077]
 ステップS1301では、以下に示すような情報を用いて、リレー通信実施のための条件をクリアしているかどうかが判断される。
[0078]
(1)基地局から通知される情報
  ・基地局からの指示情報又は制御情報
  ・基地局から提供される情報
(2)リレー端末以外の端末(V/I/P端末)から通知される情報
(3)リレー端末自身で得られる情報
[0079]
 上記のような情報がリレー通信実施のための条件をクリアしているかどうかを判断する判断基準について、例えば端末タイプに応じて異なるルールを設定してもよい。例えばRSUや車毎に異なる判断基準を設定してもよい。以下では、リレー通信実施のための各条件の詳細について説明する。
[0080]
B-3.基地局から通知される情報
B-3-1.基地局からの指示情報又は制御情報
 基地局やアプリレーションレイヤーにおいてリレー通信の実施判定を行い、その判定結果を端末に通知するケースがある。基地局からの指示情報又は制御情報とは、リレー通信の実施判定結果の通知に相当する。
[0081]
B-3-1-1.リレー通信実施の決定に用いる情報
 基地局やアプリレーションレイヤーでは、例えば以下の条件(1)~(8)を用いて、端末がリレー通信を実施するかどうかを決定する。なお、ここで言うアプリレーションレイヤーとして、例えばITS(Intelligent Transport Systems)アプリケーションサーバや、V2Xファンクションサーバなどが挙げられる。
[0082]
(1)端末位置情報
(2)端末における通信の見通し状態
(3)割り当て周波数、使用周波数
(4)V2X通信に割り当てた(使用可能な)リソース量
(5)他システムからの被干渉量
(6)端末におけるサイドリンクのRSRP(Reference Signal Received Power)、RSSI(Received Signal Strength Indicator)、又はRSRQ(Reference Signal Received Quality)情報
(7)端末カテゴリー、端末ケイパビリティ
(8)オペレーションの時間帯
[0083]
 基地局は、管理者としての機能により、上記(1)~(8)のような情報を指し示すことができる。上記のうち(5)の被干渉量については、端末からレポートされる情報を用いてもよいし、基地局で測定してもよい。
[0084]
 基地局は、上記(1)及び(2)のような端末のエリアに関する情報に基づいて、端末によるリレー通信の実施判定を行うことができる。また、基地局は、上記(3)及び(4)のような、端末が使用できるリソースの余裕に関する情報に基づいて、端末によるリレー通信の実施判定を行うことができる(チャネルが混雑していると、必然的に、端末に割り当てられるリソース量は削減される)。また、基地局は、上記(5)及び(6)のような端末のチャネル状態若しくはチャネルの混雑度に関する情報に基づいて、端末によるリレー通信の実施判定を行うことができる。また、基地局は、上記(7)のような端末の仕様に関する情報に基づいて、端末によるリレー通信の実施判定を行うことができる。また、基地局は、端末によるリレー通信の実施判定の基準を、オペレーションの時間帯に応じて切り替えるようにしてもよい。
[0085]
B-3-1-2.リレー通信実施の決定結果の通知方法
 そして、基地局は、上記の条件(1)~(8)などを用いて端末のリレー通信実施の決定を行うと、端末に対してリレー通信のEnable/Disableを通知する。端末は、基地局からEnableが通知されるとリレー通信を実施し、また、基地局からDisableが通知されるとリレー通信の実施を停止する。
[0086]
 基地局が端末にEnable/Disableを通知する方法はいくつか考えられる。以下では、RRC(Radio Resource Control)シグナリングを通して通知する方法、システム情報としてブロードキャストする方法、並びにImplicitにリレー通信の実施を制御する方法の3通りについて説明しておく。
[0087]
(1)RRCシグナリングを用いて通知する方法
 例えば、基地局は、RRCシグナリングを通して、各端末をconfigureしてもよい。基地局からリレー通信を指示された端末は、リレー端末として動作して、リレー通信を実施する
[0088]
(2)システム情報としてブロードキャストする方法
 また、基地局は、SIB(System Information Block)などのシステム情報としてリレー通信のEnable/Disableの通知をブロードキャストしてもよい。例えば、基地局は、サイドリンク用のリソースプールの属性情報として、端末に対してリレー通信の可否を通知してもよい。リソースプール内の特定の領域においては必ずリレー通信を実施する、などの属性情報をシステム情報として通知してもよい。また、サイドリンクの使用周波数帯と紐付けしてリレー通信の可否を通知してもよい。Carrier Specific情報として端末にPreconfiguredするなどである。
[0089]
(3)Implicitに通知する方法
 基地局は、端末に対するリソース割り当て時のリソース割り当て方法によって、Implicitにリレー通信の制御を行ってもよい。つまり、端末は、リレー通信用のリソースが基地局から割り当てられた時点で、リレー通信を実施すると判断する。
[0090]
 なお、3GPPの規格書TS 36.213では、基地局によるサイドリンクのリソース割り当て方式としてモード1及びモード3が規格化されている。モード3ではリソースが準静的に割り当てられるが、モード1によるリソース割り当ては準静的でない。したがって、端末は、モード3によるリソース割り当て時に、上記のようにImplicitなリレー通信制御を行うことができる。
[0091]
B-3-2.基地局から提供される情報
 端末においてリレー通信の実施を判定するために、基地局から提供される情報として、例えば以下の(1)~(5)を挙げることができる。そして、基地局は、これらの情報を、指示情報又は制御情報の場合と同様に、RRCシグナリングを通して通知したり、システム情報(SIBなど)として通知したりすることができる。
[0092]
(1)サイドリンクのチャネル混雑度
 CBR(Channel Busy Ratio)や、CR(Channel Occupancy Ration)などの情報は、基地局側で計算されることがある。基地局は、端末にCBRやCRの情報を端末に提供し、端末側ではこれらの情報に基づいてリレー通信の実施を判断することができる。例えば、チャネルが混雑していることが示されたときには、リレー端末は、サイドリンクの混雑防止を考慮して、リレー通信の実施を抑制するようにしてもよい。
[0093]
(2)リレー通信すべきエリア情報
 基地局は、端末に対して、リレー通信を実施すべきエリア情報、あるいはリレー通信を実施してもよいエリア情報を提供する。ここで言うエリア情報は、地理的な情報である。したがって、エリア情報を座標で指示してもよいし、ゾーンのような一定の区画の情報として通知してもよい。
[0094]
(3)送信端末数
 基地局は、所定のリソースプールにおいて存在する送信端末の台数を、端末に通知する。送信端末数は、所定のリソースプールにおける混み具合の指標として使用することができる。したがって、端末は、通知された送信端末数が多いときには、そのリソースプールにおける混雑を防止するために、リレー通信の実施を抑制するようにしてもよい。
[0095]
(4)割り当てリソース数
 基地局は、所定のリソースプールにおいて基地局が割り当てたリソース量の割合を、端末に通知する。割り当てリソース数は、所定のリソースプールにおける混み具合の指標として使用することができる。したがって、端末は、通知された割り当てリソース数が多いときには、そのリソースプールに余裕があると考えられることから、リレー通信を積極的に実施するようにしてもよい。
[0096]
(5)基地局からの距離
 基地局は、端末基地局間の距離を、端末に通知する。基地局から離れている端末は、Out of coverage領域が周辺に存在する可能性が高い。したがって、端末は、長い基地局間距離が通知されたときには、Out of coverage領域の端末をサポートするために、リレー通信を実施するように決定してもよい。なお、GPS(Global Positioning System)若しくはGNSSなどの位置情報を使って測距してもよい。あるいは、RSRP測定などを用いて基地局間の距離を推定するようにしてもよい。
[0097]
 以上をまとめると、基地局から端末に対して、リレー指示、エリア情報、並びにサイドリンク(チャネル)の混雑度という3種類の情報を提供することができる。
[0098]
B-4.リレー端末以外の端末(V/I/P/N端末)から通知される情報
 端末は、他端末から得られる情報を用いてリレー通信の実施判定を行うようにしてもよい。ここで言う他端末は、基地局(eNB若しくはE-UTRAN)以外の端末であり、VehicleやInfrastructure(RSU)、Pedestrianなどの端末が想定される。これらの他端末とリレー端末との通信は、基本的にサイドリンクを用いて行われる。但し、eNB経由の通信リンクを用いてもよい。
[0099]
 他端末から得られる情報には、リレー端末にパケットを送信した送信元端末から得られる情報と、(送信元端末に限定されない)リレー端末以外の端末から得られる情報に分けることができる。以下では、各々から得られる情報について説明する。
[0100]
B-4-1.リレー端末にパケットを送信した送信元端末から得られる情報
 パケットの送信元端末から得られる情報として、例えば以下の(1)~(7)を挙げることができる。送信元端末は、SCI(Sidelink Control Information)若しくはパケットのMAC(Media Access Control)ヘッダに情報を記載して、リレー端末に提供することができる。
[0101]
(1)送信したパケットのリレー通信の要否に関する情報
 送信元端末は、SCI若しくはパケットのMACヘッダにリレー通信の実施に関する情報を記載してもよい。リレー通信の要否に関して複数のレベルを定義して、送信元端末は送信パケットのリレー通信実施の必要性に応じたレベルをSCIやMACヘッダに記載するようにしてもよい。
[0102]
 また、送信元端末は、リレー通信の要否に関する情報と併せて、送信パケットの有効時間や有効範囲、有効ホップ数などを指定するようにしてもよい。
[0103]
 また、送信元端末は、リレー通信の要否に関する情報を直接指示するのではなく、送信パケットをリレーすべき条件(若しくはリレーすべきでない条件)を通知するようにしてもよい。リレー端末は、送信パケットで通知された条件に基づいて、そのパケットについてリレー通信の実施判定を行う。また、リレー端末は、送信パケットで条件が通知される度に、リレー通信の実施判定のための条件を逐次更新するようにする。送信元端末は、例えば以下のような条件をSCIやMACヘッダに記載するようにしてもよい。
[0104]
・同じパケットIDのパケットを他端末から受信した場合には、リレーすべきではない。リレー通信を抑制することにより、パケットの氾濫を防ぐことにもなる。
・同じパケットIDのACK信号を他端末から受信した場合には、リレーすべきでない。リレー通信を抑制することにより、パケットの氾濫を防ぐことにもなる。
・同じパケットIDのNACK信号を他端末から受信した場合には、リレーすべきである。送受信に失敗したパケットのリレー通信を実施することにより、システムの信頼性向上につながる。
[0105]
 リレー端末は、ブロードキャストやユニキャストといったパケットの属性情報を用いて、受信したパケットをリレーすべきかどうかを判断するようにしてもよい。送信元端末は、SCI内に、パケットの種別といった情報を記載する。また、送信元端末は、SCI内に記載する宛先情報を用いて、リレー通信の要否をImplicitに示してもよい。あるいは、リレー端末は、SCI内に記載された宛先情報に基づいて、リレー通信の実施判定をImplicitに行ってもよい。例えば、リレー端末は、1つだけ宛先情報が含まれていた場合には、ユニキャストと判断してリレー通信を行わないが、宛先情報がない場合には、ブロードキャストと判断してリレー通信を行うようにしてもよい。
[0106]
(2)パケットの優先度情報
 送信元端末は、例えばSCI若しくはパケットのMACヘッダに、送信パケットの優先度情報を記載する。3GPPの規格書TS 36.213に記載されている優先度情報を用いてもよい。同規格の優先度情報は本来リレー通信の優先度を規定するものではないが、セーフティパケットのような優先度の高いパケットは優先的にリレー通信を実施すべきであるということができる。
[0107]
(3)パケットのリレーホップ数
 送信元端末は、例えばSCI若しくはパケットのMACヘッダに、送信パケットのホップ数を記載する。
[0108]
(4)パケットのリレー経路
 送信元端末は、例えばSCI若しくはパケットのMACヘッダに、送信パケットのリレー経路を記載する。例えば、経路はV/I/P/Nのどれなのかを示す。また、パケットのリレー時間を併せて記載してもよい。
[0109]
(5)パケットのリソースアロケーションモード情報
 送信元端末は、例えばSCI若しくはパケットのMACヘッダに、送信パケット用に確保したリソースやリレー通信用に予約したリソースのリソースアロケーションモード情報を記載する。3GPPの規格書TS 36.213では、基地局によるサイドリンクのリソース割り当て方式としてモード1及びモード3が記載され、また、端末によるサイドリンクのリソース割り当て方式としてモード2及びモード4が規格化されている。モード3によるリソース割り当てが準静的であるのに対し、モード1によるリソース割り当ては準静的ではない。また、モード4では端末がセンシングしてリソースを確保するのに対し、モード2では端末はセンシングせずにリソースを確保するので衝突する可能性がある。例えば、予約されたリレー通信用リソースがモード2であれば衝突する可能性があるのでリレー通信の実施を控えるが、モード1であれば衝突する可能性が低いのでリレー通信の実施を決定するようにしてもよい。
[0110]
(6)パケットの生成時間、送信時間
 送信元端末は、例えばSCI若しくはパケットのMACヘッダに、送信パケットの生成時間、送信時間を記載する。
[0111]
(7)パケットの生成エリア、送信エリア
 送信元端末は、例えばSCI若しくはパケットのMACヘッダに、送信パケットの生成エリア、送信エリアの情報を記載する。ここで言うエリアとは地理的な情報であり、座標で指示してもよいし、ゾーンのような一定の区画の情報として通知してもよい。
[0112]
 なお、上記(3)~(7)の情報は、パケットの「鮮度」を示す情報ということもできる。例えば、上記(2)~(7)のうち2以上のパラメータを組み合せてパケットの鮮度情報を定義し、送信元端末は、例えばSCI若しくはパケットのMACヘッダに、鮮度情報を記載する。パケットに関するパラメータから鮮度情報を導出する計算式は、基地局により設定されてもよいし、各ユーザ端末にPre-cofigurationされてもよい。情報技術の分野においては、鮮度が高いほど意味のある、ということができる。鮮度が高いパケットは、例えば情報エントロピーが高いものとして定義される(確率の低い情報ほど、高いエントロピーを示す)。したがって、リレー端末は、鮮度情報若しくは情報エントロピーに基づいてパケットのリレー通信の実施判定を行うようにすることで、より意味のある情報を持ったパケットをリレーすることが可能になる。
[0113]
 なお、上記(3)~(7)のパラメータから鮮度情報を導出する計算式は、基地局により設定されてもよいし、各ユーザ端末にPre-cofigurationされてもよい。例えば、基地局からユーザ端末へ、RRCシグナリングやシステム情報(SIB)として、このような計算式が通知される。
[0114]
B-4-2.リレー端末以外から得られる情報
 リレー端末以外から得られる情報として、例えば以下の(1)~(3)のような、サイドリンクのチャネル状況を示す情報を挙げることができる。ここで言うリレー端末以外の端末には、リレー端末にパケットを送信した送信元端末と、送信元端末ではないリレー端末以外の端末とを含むものとする。
[0115]
(1)サイドリンクのチャネル混雑度
 リレー端末以外の端末で測定されたCBRやCRなどの情報が、サイドリンクでリレー端末にシェアされる。例えば、チャネルが混雑していることが示されたときには、リレー端末は、混雑防止を考慮して、リレー通信の実施を抑制するようにしてもよい。
[0116]
(2)サイドリンクのチャネル状態
 リレー端末以外の端末から、RSRP、RSSI、RSRQなどの情報を通知してもらう。測定者端末の位置情報も含めて通知してもらうとよい。例えば、チャネルが混雑していると、受信電力すなわちRSSIが増大することから、リレー端末は、リレー通信の実施を控えるように判断してもよい。
[0117]
(3)他端末におけるACK/NACK情報
 リレー端末以外の端末から、これまで送信してきたパケットのACK/NACKの統計情報などを通知してもらう。例えば、NACKの割合が所定の閾値以上となるエリアでは、通信が成立していないので、リレー通信を実施すると判定する。あるいは、NACKの割合が所定の閾値以上となるエリアでは、チャネルが混雑していることが推定されるので、リレー通信の実施を控えると判断することもできる。
[0118]
B-5.リレー端末自身で得られる情報
 リレー端末自身から得られる情報として、例えば以下の(1)~(4)のような情報を挙げることができる。
[0119]
(1)サイドリンクのチャネル混雑度・占有度
 リレー端末自身でCBRやCRなどの情報を測定する。例えば、チャネルが混雑していることが示されたときには、リレー端末は、サイドリンクの混雑防止を考慮して、リレー通信の実施を抑制するようにしてもよい。
[0120]
(2)サイドリンクのチャネル状態
 リレー端末自身で、RSRP、RSSI、RSRQなどのサイドリンクにおけるチャネル状態を測定する。例えば、チャネルが混雑していると、受信電力すなわちRSSIが増大することから、リレー端末は、リレー通信の実施を控えるように判断してもよい。
[0121]
(3)ACK/NACK情報
 他端末から送信されてきたパケットのACK/NACKの情報を自身でデコードする。例えば、NACKの割合が所定の閾値以上となるエリアでは、通信が成立していないので、リレー端末は、リレー通信を実施すると判定する。あるいは、NACKの割合が所定の閾値以上となるエリアでは、チャネルが混雑していることが推定されるので、リレー端末は、リレー通信の実施を控えると判断することもできる。
[0122]
(4)端末位置情報
 例えばGPS若しくはGNSSなどの位置情報を使って、リレー端末自身の位置情報を測距する。そして、リレー端末は、リレー端末自身がリレー通信を実施すべきエリア、あるいはリレー通信を実施してもよいエリアにいるかどうかに基づいて、リレー通信の実施判定を行う。
[0123]
B-6.リレー通信の実施判定処理
 上記では、リレー端末がリレー通信の実施判定に使用する情報が、基地局やリレー端末以外の端末から通知され、又はリレー端末自身で取得することを説明してきた。また、これらの取得方法により取得される情報は、上述したようにさまざまなパラメータからなるが、以下の(1)~(5)にまとめることができる。
[0124]
(1)基地局からのリレー指示
(2)パケットの優先度
(3)サイドリンクの混雑度
(4)エリア情報
(5)パケットの鮮度
[0125]
 上記のパラメータのうち、(1)基地局からのリレー指示は絶対であり、基地局からリレーが指示されたリレー端末は必ずリレー通信を実施する。これに対し、(2)~(5)のパラメータは、必須ではないが昇り順で重要度が高いものとする。リレー端末は、例えば図14にフローチャートの形式で示す処理手順に従って、パケットのリレー通信の実施判定を行うことができる。
[0126]
 リレー端末は、まず基地局からリレー通信のEnableの指示を受けたかどうかをチェックする(ステップS1401)。そして、基地局からリレー通信のEnableの指示を受けている場合には(ステップS1401のYes)、リレー端末は、リレー通信を実施して(ステップS1402)、本処理を終了する。
[0127]
 また、リレー端末は、基地局からリレー指示を受けていない場合には(ステップS1401のNo)、受信したパケットに対して送信元端末から指定されている優先度をチェックする(ステップS1403)。
[0128]
 ここで、優先度が高いパケットの場合には(ステップS1403のYes)、より低い混雑度の閾値TH1を設定して、リレー通信に使用するサイドリンクのチャネル混雑度(CBR若しくはCR)を閾値TH1と大小比較する(ステップS1404)。また、優先度が低いパケットの場合には(ステップS1403のNo)、より高い混雑度の閾値TH2を設定して(但し、TH2>TH1)、リレー通信に使用するサイドリンクのチャネル混雑度(CBR若しくはCR)を閾値TH2と大小比較する(ステップS1407)。
[0129]
 そして、サイドリンクのチャネル混雑度(CBR若しくはCR)が、閾値TH1以下のとき(ステップS1404のYes)、又は、閾値TH2以下のとき(ステップS1407のYes)には、リレー端末がリレー通信を実施すべきエリア、あるいはリレー通信を実施してもよいエリアにいるかどうかをさらにチェックする(ステップS1405)。
[0130]
 リレー端末がリレー通信を実施すべきエリア、あるいはリレー通信を実施してもよいエリアにいるときには(ステップS1405のYes)、続いて、パケットの鮮度をチェックする(ステップS1406)。そして、リレー端末がリレー通信を実施可能な状態にあり、且つ、パケットの鮮度がよい場合には(ステップS1406のYes)、リレー端末は、リレー通信を実施して(ステップS1402)、本処理を終了する。
[0131]
 他方、リレー通信に使用するサイドリンクのチャネル混雑度(CBR若しくはCR)が閾値TH1を超え(ステップS1404のNo)、又は、閾値TH2を超えるため(ステップS1407のNo)、リレー通信を抑制してチャネルの混雑を防止すべきとき、リレー端末が実施すべきエリア又はリレー通信を実施してもよいエリアにおらず、リレー通信を実施できる状況にないとき(ステップS1405のNo)、あるいは、パケットの鮮度が落ちてしまい(ステップS1406のNo)、リレー通信する必要性が低いときには、リレー端末は、リレー通信を実施しないで(ステップS1408)、本処理を終了する。
[0132]
 図14に示した実施判定の処理手順のうち、ステップS1401、S1403~S1406は、例えば図13に示したフローチャートのステップS1301内で実施される処理に相当する。
[0133]
 但し、リレー端末によるリレー通信の実施判定処理は図14に示した処理手順に限定されるものではなく、実装次第で適宜修正又は変更されることが想定される。例えば、図14に示した処理手順では、リレー端末は、基地局からリレー通信のEnableの指示を受けたときには必ずリレー通信を実施するように判定するが、このような判定処理には限定されない。リレー端末は、基地局からリレー通信のEnableの指示を受けていないとき(若しくは、Disableの指示を受けたとき)には、決してリレー通信を実施しないこととする判定処理や、Enableの指示を受けた場合においてチャネルの混雑度やパケットの優先度など他の条件に応じてリレー通信の実施を決定する、といったような判定処理も想定される。
[0134]
C.リレー端末によるリレーパケットの送信方法
 上述したように、リレー端末は、パケットを受信したときにリレー通信の実施判定を行う。そして、実施すると判定された場合には、リレー端末は、リレー通信のための送信処理を実施する。
[0135]
C-1.変更パラメータ
 リレー端末は、リレー通信の実施に際し、以下のパラメータを変更する。
[0136]
・使用するリソース
・使用するリソースプール
・使用する周波数キャリア
・送信電力
・RV(Redundancy Version)情報
・MIMO(Multiple Input Multiple Output)の適用、ビームフォーミングの適用
・送信ダイバーシティ適用
・CoMP(Coordinated Multi-point:高データレートのカバレッジ拡大や、セル端におけるスループット改善を目的とした多地点協調)の適用
・パケット優先度情報
・パケット情報エントロピー(鮮度情報)
・MA signature
[0137]
C-2.リレー通信用のリソース確保方法
 リレー端末がリレー通信を実施することを決定したとき、リレー通信に用いるリソースを確保する必要がある。ここでは、リレー端末がリレー通信に用いるリソースを確保する方法について説明する。
[0138]
C-2-1.リレー端末自身がリレー通信用リソースを確保
 リレー通信を実施することを決定したリレー端末が、自らリレー通信用のリソースを確保する。
[0139]
 リレー端末は、リレーパケットの送信時にセンシングを実施して、リレー通信用のリソースを確保する。
[0140]
 また、リレー端末は、センシング時に、リレー通信用のリソースということを考慮してリソース選択を実施する。つまり、リレー用のリソースに与えられる優先度レベルを用いてリソースを確保する。
[0141]
C-2-2.送信元端末がリレー通信用リソースを予約
 リレー端末にパケットを送信した直近の送信元端末が、リレー通信用のリソースを予約する。
[0142]
 送信元端末は、SCIなどのパケット制御情報の中に、リレー通信用のリソース予約情報を含めておくことができる。リレー端末は、事前に予約されたリレー通信用リソースを使って、リレー通信を実施することができる。
[0143]
 図15には、送信元端末がリレー通信用のリソースを予約してリレー通信を行う通信シーケンス例を示している。
[0144]
 送信元端末は、トラフィックが発生すると(SEQ1501)、センシングを用いてサイドリンクによりリレー端末へのデータ送信を行うためのリソースを、サイドリンク用のリソースプールの中から選択する(SEQ1502)。このとき、送信元端末は、サイドリンク用のリソースプール内で、リレー端末のリレー通信用のリソースを併せて選択する。このようにして、送信元端末は、自分のデータ送信用のリソースと、リレー端末のリレー通信用リソースをそれぞれ確保する(SEQ1503)。
[0145]
 その後、送信元端末は、パケット制御情報(SCI)を用いて、データ送信用リソースのリソース位置と、リレー通信用リソースの予約情報をリレー端末に通知し、続いて、SCIで通知したリソースを使ってリレー端末へのデータ送信を行う(SEQ1504)。
[0146]
 これに対し、リレー端末は、SCIで通知されたデータ送信用のリソース位置にて送信元端末からの送信データを受信し、復号処理する(SEQ1505)。そして、リレー端末は、例えば図13又は図14に示したリレー判定の実施判定処理を実施する(SEQ1506)。
[0147]
 ここでは、説明の便宜上、リレー端末はリレー通信を実施することを決定したとする。したがって、リレー端末は、送信元端末からSCIで通知されたリレー通信用のリソースを使って、送信先端末へのリレー通信を実施する(SEQ1507)。このとき、リレー端末は、パケット制御情報(SCI)を用いて、リレー通信用リソースのリソース位置を送信先端末に通知する。また、リレー端末は、上記と同様に、送信先端末のためのリレー通信用リソースを予約して、SCIで併せて通知するようにしてもよい。
[0148]
 また、送信元端末は、Reservation indicatorなどを用いて、リレー通信リソースの通知を行ってもよい。ここで、Reservation indicatorとは、例えばあるリソースを用いてデータ送信したときに、その送信データのリソースを基準として所定の時間オフセット値だけ時間方向に離れたリソース位置をリレー通信用に予約したことを示すビット(すなわち、1ビットで基準のリソースを繰り返し使用することを示すもの)である。
[0149]
 図16には、リレー通信用リソースの割り当て例を示している。但し、同図において、横軸を時間軸とし、縦軸を周波数軸とする。送信元端末は、サイドリンクにおいて、SCIを送信した後に、リレー端末にデータを送信する。SCI内には、参照番号1601で示す、データリソースの時間周波数領域を指示する情報と、参照番号1602で示す、リレー通信用リソースを予約情報であるReservation indicatorが含まれている。また、参照番号1603で示す、SCIで指示されたデータ送信用リソースと予約されたリレー通信用リソースの時間オフセット値は、規定値であってもよいし、SCI内で通知してもよい。
[0150]
C-2-3.ハイブリッドなリレー通信用リソースの確保方法
[0151]
 送信元端末によりリレー通信用リソースを予約する方法と、リレー端末が自らリレー通信用リソースを確保する方法を組み合わせる。具体的には、リレー端末は、基本的には送信元端末が予約したリレー通信用リソースを使用するが、予約されたそのリソースを再センシングして使用できないときには、自らリレー通信用リソースを確保する。
[0152]
 図17には、リレー端末がハイブリッドなリレー通信用リソースの確保方法によりリレー通信を実施するための処理手順をフローチャートの形式で示している。図示の処理手順は、リレー端末として動作する通信装置の処理部250が主導して実施される。
[0153]
 リレー端末は、送信元端末からデータパケットを受信すると(ステップS1701)、リレー通信の実施判定を行う。ここでは、説明の便宜上、リレー端末はリレー通信を実施すると決定したものとする。
[0154]
 また、リレー端末は、そのデータ送信の際に送信元端末から受信したSCIから、リレー通信用に予約されたリソースの位置情報を取得する(ステップS1702)。
[0155]
 次いで、リレー端末は、ステップS1702でSCIから取得したリレー通信用リソースの再センシングを実施する(ステップS1703)。そして、リレー端末は、ステップS1702で取得したリレー通信用リソースの再センシングすることができた場合には(ステップS1704のYes)、送信元端末により予約されたそのリレー通信用リソースをそのまま使って、ステップS1701で受信したパケットのリレー通信を実施する(ステップS1705)。
[0156]
 一方、リレー端末は、送信元端末により予約されたリレー通信用リソースを再センシングすることができなかった場合には(ステップS1704のNo)、自らリレー通信用リソースのセンシングを実施する(ステップS1706)。
[0157]
 ここで、リレー端末は、自らリレー通信用リソースを確保することができた場合には(ステップS1707のYes)、そのリソースを使って、ステップS1701で受信したパケットのリレー通信を実施する(ステップS1708)。
[0158]
 また、リレー端末は、自らもリレー通信用リソースを確保することができなかった場合には(ステップS1707のNo)、リレー通信を行わない(ステップS1709)。
[0159]
C-2-4.基地局によるリレー通信用リソースの確保方法
 基地局がリレー通信用のリソース割り当てを行うようにしてもよい。例えば、基地局からリレー端末に対して、Uuリンク(基地局と端末間の無線区間)経由のDCI(Downlink Control Information)で、割り当てたリレー通信用リソースのGrant(許可)が通知される。
[0160]
 図18には、基地局がサイドリンクにおけるリレー通信用リソースの割り当てを行う通信シーケンス例を示している。なお、同図中の送信元端末及びリレー端末はそれぞれ異なる車両に搭載された通信装置(図9を参照のこと)であり、基地局はeNB又はRSU(図10を参照のこと)に相当する。
[0161]
 送信元端末は、トラフィックが発生すると(SEQ1801)、接続先の基地局に対して、スケジューリングリクエストによるサイドリンクのためのリソースを要求する(SEQ1802)。ここでは、送信元端末は、データ送信のためのリソースに加えて、リレー通信用リソースを要求する。
[0162]
 基地局は、送信元端末からのサイドリンクのためのリソース要求に応答して、データ送信のためのリソース、及び、リレー通信用リソース割り当てを行う(SEQ1803)。そして、基地局は、送信元端末とリレー端末の各々に対し、DCI経由で、割り当てたリソースを通知する(SEQ1804)。
[0163]
 その後、送信元端末は、サイドリンクによるデータ送信に割り当てられたリソースを使って、リレー端末へのデータ送信を行う(SEQ1805)。これに対し、リレー端末は、送信元端末からの送信データを受信し復号処理する(SEQ1806)。そして、リレー端末は、例えば図13又は図14に示したリレー判定の実施判定処理を実施する(SEQ1807)。
[0164]
 ここでは、説明の便宜上、リレー端末はリレー通信を実施することを決定したとする。送信元端末は、サイドリンクによるデータ送信に割り当てられたリソースを使って、送信先端末(図示しない)へのリレー通信を行う(SEQ1811)。
[0165]
 なお、リレー端末は、リレー通信の際に、上記と同様に基地局に対して、次のリレー通信用リソースを要求するようにしてもよい(SEQ1808)。この場合、基地局は、リレー端末からのリソース要求に応答して、リレー通信用リソース割り当てを行うと(SEQ1809)、リレー端末とその送信先端末(図示しない)の各々に対し、DCI経由で、割り当てたリソースを通知する(SEQ1810)。
[0166]
C-3.パケットの氾濫を防ぐ対応
 リレー通信が制限なく行なわれると、無線伝送路上にパケットが氾濫して、チャネル(サイドリンク)の混雑が発生してしまうおそれがある。リレー通信は必要な時に必要な量だけ実施されるべきである。ここでは、パケットの氾濫を防ぐための幾つかの方法について説明する。
[0167]
C-3-1.パケットの情報エントロピー(鮮度情報)を用いた方法
 パケットの鮮度若しくは情報エントロピーに応じて、最終的なリレーの実施確率を調整する。なお、パケットの情報エントロピーは、上述したようにパケットの鮮度を示す1つ又は複数のパラメータの組み合わせに基づいて定義することができるが、リレー通信の制限に用いる情報エントロピーは特定の定義には限定されないものとする。
[0168]
 リレー端末は、送信元端末からパケットを受信したときに、例えば図13又は図14に示した処理手順に従ってリレー通信の実施判定を行う。そして、リレー端末は、リレー通信を実施することを決定した場合であっても、実際にリレー通信を実施するかどうかを所定の確率に応じて判断する。例えば、受信したパケットの鮮度がよければ、リレー端末は、リレー通信を実施すると判定すると、100%に近い確率で最終的にリレー通信を実施する。他方、鮮度が落ちているパケットを受信したときには、リレー端末は、リレー通信を実施すると判定した場合であっても、例えば50%を下回る低い確率でしか、最終的にリレー通信を実施しないようにする。
[0169]
 なお、パケットの鮮度情報と確率情報との関係は、基地局から設定されるか、又は端末自身にPre-cofigurationされてもよい。ここで言うPre-cofigurationとは、例えば端末の出荷時に設定することに相当する(但し、基地局が書き換えを行うことも想定される)。前者の場合、基地局は、配下のリレー端末におけるリレー通信の実施確率を調整することで、自セル内のリソースプールにおけるリレーパケットの占有率を統括的にコントロールすることができる。基地局は、例えばRRCシグナリングやシステム情報(SIB)として、各リレー端末に対してリレー通信の実施確率に関する情報を通知することができる。
[0170]
 また、パケットの鮮度情報と確率情報との関係を、周波数特異的に決定してもよい。例えば、リレー端末は、パケットの鮮度又は情報エントロピーを表す数値とのリレー通信の実施確率とのマッピングテーブルを用いて、リレー通信の対象となるパケットから求められた鮮度からリレー通信の実施確率に変換するようにしてもよい。このようなマッピングテーブルを用いれば、例えば鮮度レベルが1といった情報エントロピーが高いパケットの場合、リレー通信の実施確率を80%といった高確率に変換する。また、パケットの優先度情報に応じて複数のマッピングテーブルを設定してもよい。例えば同じパケットの鮮度情報(若しくは情報エントロピー)であっても、パケットの優先度が高い場合にはより高い実施確率に変換するマッピングテーブルを設定するようにしてもよい。
[0171]
 サイドリンクのチャネル混雑度に応じてリレー通信の実施判定を行うべきことは、B-4-2項で既に説明した通りである。例えば、CBRやCRなどの情報によってチャネルが混雑していることが示されているときには、リレー端末は、混雑防止を考慮して、リレー通信の実施を抑制するべきである。そこで、CBR又はCRに応じて、複数のマッピングテーブルを設定してもよい。例えば、同じパケットの鮮度情報(若しくは情報エントロピー)であっても、CBRやCRがチャネルの混雑を示す場合にはより低い実施確率に変換するマッピングテーブルを設定するようにしてもよい。
[0172]
 また、パケットの鮮度若しくは情報エントロピーに応じて、最終的なリレーの実施確率を調整する場合、パケットの鮮度情報を更新するようにしてもよい。B-4-1項で挙げた、パケットに関するいくつかのパラメータの1つ又は複数の組み合わせに用いて、パケットの鮮度情報を更新する。
[0173]
 なお、パケットに関するパラメータから鮮度情報を導出する計算式は、基地局により設定されてもよいし、各ユーザ端末にPre-cofigurationされてもよい。例えば、基地局からユーザ端末へ、RRCシグナリングやシステム情報(SIB)として、このような計算式が通知される。
[0174]
C-3-2.パケットから得られる情報に基づくリレー通信の実施確率の調整
 既にB-4-1項で説明したように、リレー端末にパケットを送信した送信元端末から、パケットに関するいくつかのパラメータを取得することができる。これらのパラメータの上限値を用いて、リレー端末におけるリレー通信の実施確率を変化させてもよい。
[0175]
 例えば、パケットのリレーホップ数の上限が5に設定されている場合には、パケットに記載されたホップ数カウントが5を超える場合には、リレー端末は、リレー通信の実施確率を20%など低い確率に設定する。
[0176]
 このような、パラメータの上限値と実施確率との関係は、基地局より設定されてもよいし、端末にPre-cofigurationされてもよい。基地局により設定される場合には、例えば、基地局からユーザ端末へ、RRCシグナリングやシステム情報(SIB)として通知される。
[0177]
C-3-3.パケットの伝送状況に応じたリレー通信の実施確率の調整
 リレー端末は、リレー通信の対象となるパケットを受信した回数や、他端末からのACK/NACK情報を用いて、リレー通信の実施確率を変化させてもよい。すなわち、リレー端末は、対象パケットの受信回数やACK/NACK情報など、パケットの伝送状況を示す各パラメータに閾値を決めるとともに、閾値を超えたパラメータとリレー通信の実施確率を設定する。
[0178]
 例えば、対象パケットを他端末から3回受信した場合にはリレー通信の実施確率を10%にするなど、リレー端末は、パケットの受信回数が閾値を超えるとリレー通信の実施確率を抑制するようにしてもよい。
[0179]
 パケットの伝送状況を示すパラメータ毎の閾値とリレー通信の実施確率との関係は、基地局により設定されてもよいし、各ユーザ端末にPre-cofigurationされてもよい。例えば、基地局からユーザ端末へ、RRCシグナリングやシステム情報(SIB)として、閾値とリレー通信の実施確率との関係が通知される。
[0180]
C-3-4.パケットの氾濫防止対策の実施タイミング
 上述したように、リレー端末は、リレー通信の対象となるパケットの鮮度情報や、パケットやその伝送状況に関するパラメータに応じて、リレー通信の実施確率を調整することで、パケットの氾濫を防止する対策をとることができる。リレー端末は、リレー通信の実施判定を行った直後に実施確率を設定してもよい。また、リレー端末がリレー通信の実施判定を行う条件の一部として、実施確率を設定してもよい。例えば、図14に示したフローチャートにおいて、ステップS1402の直前に、実施確率に応じたさあ周的なリレー通信の実施判定処理を行うようにしてもよい。
[0181]
D.実施例
 ここでは、リレー端末が基地局からの指示によりリレー通信を行う場合を例にとって、リレー通信の実施例について説明する。
[0182]
 まず、リレー通信実施のための1つ目の条件として、基地局からリレー端末へ、リレー通信のEnableの指示が設定される。
[0183]
 次に、リレー通信実施のための2つ目の条件として、リレー端末の端末Capability情報を設定する。すなわち、リレー端末がリレー通信を実施できるCapabilityであるかどうかをリレー通信実施の条件とする。
[0184]
 次に、リレー端末は、他の端末からパケットを受信すると、そのパケットについてリレー通信を実施するかどうかを判定する。上述したように、リレー端末は基地局からリレー通信のEnableの指示を受け、且つ、リレー端末自身はリレー通信を行えるCapability情報が設定されている。したがって、リレー端末は、これらの情報に基づいて、リレー通信を実施すると判定する。
[0185]
 その後、リレー端末は、リレー通信実施のための送信準備を行う。リレー通信のためには、通信用のリソースを確保する必要がある。ここで、受信パケットのSCIに記載されている情報を参照し、送信元端末がリレー通信用リソースを予約しているかどうかを確認する。そして、リレー通信用リソースが予約されている場合には、リレー端末は、自らリソースを確保する必要がなく、送信元端末によって予約されたリソースを用いて、リレー通信を実施することができる。
[0186]
 また、リレー端末は、リレー通信を開始する直前に、実施確率の調整をさらに行う。受信したパケットの鮮度レベルが2であったとし、基地局より与えられた鮮度レベルと実施確率のマッピングテーブルを参照して、鮮度レベル2を実施確率80%に変換する。したがって、リレー端末は、確率80%でリレー通信を最終的に実施することになる。
[0187]
 そして、リレー端末は、乱数を用いて判定して結果、20%の確率となった。このため、リレー端末は、最終的にリレー通信の実施を取りやめる。リレー通信のためにリソースが使用されることがないので、リレー端末は、周辺端末に対してのリソースのリリースメッセージを通知する。

産業上の利用可能性

[0188]
 以上、特定の実施形態を参照しながら、本明細書で開示する技術について詳細に説明してきた。しかしながら、本明細書で開示する技術の要旨を逸脱しない範囲で当業者が該実施形態の修正や代用を成し得ることは自明である。
[0189]
 本明細書では、V2X通信におけるサイドリンク通信に関する実施形態を中心に説明してきたが、本明細書で開示する技術の要旨はこれに限定されるものではない。すなわち、本明細書で開示する技術は、V2X通信以外のユースケースにも同様に適用することが可能である。本明細書で開示する技術は、D2D(Device to Device)通信やMTC(Machine Type Communication)などさまざまなタイプの端末間直接通信に適用することができる。また、本明細書で開示する技術は、Moving cell(移動式基地局)やRelay通信などへも適用することができる。
[0190]
 要するに、例示という形態により本明細書で開示する技術について説明してきたのであり、本明細書の記載内容を限定的に解釈するべきではない。本明細書で開示する技術の要旨を判断するためには、特許請求の範囲を参酌すべきである。
[0191]
 なお、本明細書の開示の技術は、以下のような構成をとることも可能である。
(1)基地局の配下で端末として動作する通信装置であって、
 無線信号を送受信する通信部と、
 前記通信部による、所定のリソースプールを用いたデータの送信を制御する制御部と、
を具備し、
 前記制御部は、パケット受信時において、前記基地局から通知される情報、他端末から通知される情報、又は、前記端末自身から得られる情報のうち少なくとも1つに基づいて、前記所定のリソースプール内でのパケットのリレー通信の実施を制御する、
通信装置。
(1-1)前記通信部は、前記基地局から割り当てられたサイドリンク用の前記所定のリソースプールを用いて無線信号の送受信を行う、
上記(1)に記載の通信装置。
(2)前記制御部は、前記基地局から通知される、リレー通信を実施すべきエリア又は実施してもよいエリアを示す情報に基づいて、リレー通信の実施を判定する、
上記(1)に記載の通信装置。
(2-1)エリアは、地理的な座標情報、又は、ゾーンの識別情報で示される、
上記(2)の記載の通信装置。
(3)前記制御部は、前記基地局からの、リレー通信の実施の指示又はリレー通信の停止の指示に基づいて、リレー通信の実施を判定する、
上記(1)又は(2)のいずれかに記載の通信装置。
(3-1)前記制御部は、前記基地局からのRRCシグナリング、又はSIBのブロードキャストにより、リレー通信の実施の指示又はリレー通信の停止の指示を受け取る、
上記(3)に記載の通信装置。
(3-2)前記制御部は、前記基地局から通知されるチャネル混雑度に関する情報に基づいて、リレー通信の実施を判定する、
上記(3)に記載の通信装置。
(3-3)前記制御部は、前記基地局から通知される、前記所定のリソースプール内に存在する送信端末数に基づいて、リレー通信の実施を判定する、
上記(3)に記載の通信装置。
(3-4)前記制御部は、前記基地局から割り当てられたリソース量に基づいて、リレー通信の実施を判定する、
上記(3)に記載の通信装置。
(3-5)前記制御部は、前記基地局からの距離に基づいて、リレー通信の実施を判定する、
上記(3)に記載の通信装置。
(4)前記制御部は、前記パケットの送信元端末から得られる、前記パケットの送信用リソースの割り当て方法に関する情報に基づいて、リレー通信の実施を判定する、
上記(1)乃至(3)のいずれかに記載の通信装置。
(5)前記制御部は、前記パケットの送信元端末から得られる前記パケットの優先度情報に基づいて、リレー通信の実施を判定する、
上記(1)乃至(4)のいずれかに記載の通信装置。
(6)前記制御部は、前記パケットの送信元端末から得られる前記パケットの鮮度情報に基づいて、リレー通信の実施を判定する、
上記(1)乃至(5)のいずれかに記載の通信装置。
(7)前記制御部は、前記パケットの送信元端末から得られる、前記パケットのリレーホップ数、前記パケットのリレー経路、前記パケットの生成時間又は送信時間、前記パケットの生成エリア又は送信エリアのうち少なくとも1つから求められる前記鮮度情報に基づいて、リレー通信の実施を判定する、
上記(6)に記載の通信装置。
(8)前記制御部は、前記パケットの通信に用いるチャネルの混雑度、前記チャネルの状態、前記パケットの再送情報、又は、前記端末自身の位置情報のうち少なくとも1つに基づいて、リレー通信の実施を判定する、
上記(1)乃至(7)のいずれかに記載の通信装置。
(9)前記制御部は、リレー通信用のリソースの確保をさらに制御する、
上記(1)乃至(8)のいずれかに記載の通信装置。
(10)前記制御部は、前記リソースプール内でのリレー通信用のリソースのセンシングを制御する、
上記(9)に記載の通信装置。
(11)前記制御部は、前記パケットの送信元端末が予約したリレー通信用のリソースを用いた前記パケットのリレー通信の実施を制御する、
上記(9)に記載の通信装置。
(12)前記制御部は、前記パケットの送信元端末が予約したリレー通信用のリソースをセンシングして使用できないときには、自らリレー通信用のリソースのセンシングを制御する、
上記(11)に記載の通信装置。
(13)前記制御部は、前記基地局が確保したリレー通信用のリソースを用いた前記パケットのリレー通信の実施を制御する、
上記(9)に記載の通信装置。
(14)前記制御部は、前記パケットのリレー通信の実施確率をさらに制御する、
上記(1)乃至(13)のいずれかに記載の通信装置。
(15)前記制御部は、前記パケットの鮮度情報に応じて前記パケットのリレー通信の実施確率を制御する、
上記(14)に記載の通信装置。
(16)前記制御部は、前記基地局から設定され、又は前記端末自身にあらかじめ設定された、パケットの鮮度情報と実施確率との関係に基づいて、前記パケットのリレー通信の実施確率を制御する、
上記(15)に記載の通信装置。
(17)前記制御部は、前記パケットの優先度情報に対応したパケットの鮮度情報と実施確率との関係に基づいて、前記パケットのリレー通信の実施確率を制御する、
上記(15)又は(16)のいずれかに記載の通信装置。
(18)前記制御部は、リレー通信に使用するチャネルの混雑度に対応したパケットの鮮度情報と実施確率との関係に基づいて、前記パケットのリレー通信の実施確率を制御する、
上記(15)乃至(17)のいずれかに記載の通信装置。
(19)前記制御部は、前記パケットの送信元端末から得られる情報に基づいて、前記パケットの鮮度情報を更新する、
上記(15)乃至(18)のいずれかに記載の通信装置。
(20)基地局の配下で端末として動作する通信装置における通信方法であって、
 所定のリソースプールにおいてパケットを受信するステップと、
 前記基地局から通知される情報、他端末から通知される情報、又は、前記端末自身から得られる情報のうち少なくとも1つに基づいて、前記パケットのリレー通信の実施を制御するステップと、
を有する通信方法。

符号の説明

[0192]
 10…UE(ユーザ携行)、20…UE(車両搭載)
 22…移動体(車両)、30…eNB、40…GNSS衛星
 50…RSU
 110…アンテナ部、120…無線通信部
 130…GNSS信号処理部、140…記憶部、150…処理部
 210…アンテナ部、220…無線通信部
 230…GNSS信号処理部、240…記憶部、250…処理部
 310…アンテナ部、320…無線通信部
 330…ネットワーク通信部、340…記憶部、350…処理部
 510…アンテナ部、520…無線通信部
 530…記憶部、540…処理部

請求の範囲

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

図面

[ 図 1]

[ 図 2]

[ 図 3]

[ 図 4]

[ 図 5]

[ 図 6]

[ 図 7]

[ 図 8]

[ 図 9]

[ 図 10]

[ 図 11]

[ 図 12]

[ 図 13]

[ 図 14]

[ 図 15]

[ 図 16]

[ 図 17]

[ 図 18]