WO2024070538A1

WO2024070538A1 - メッセージ制御装置、及び、メッセージ制御方法

Info

Publication number: WO2024070538A1
Application number: PCT/JP2023/032439
Authority: WO
Inventors: 貴久山城
Original assignee: 株式会社デンソー
Priority date: 2022-09-29
Filing date: 2023-09-06
Publication date: 2024-04-04
Also published as: JP2024050080A

Abstract

本開示の一態様に係るメッセージ制御装置は、メッセージの送信にマルチホップ通信が必要であるか否かを判定する制御部と、マルチホップ通信が必要であると判定された場合、マルチホップ通信を用いてメッセージを送信する通信部と、を含む。これにより、マルチホップ通信をする必要性が高い場合にはマルチホップ通信をすると決定でき、シングルホップ通信でもメッセージを伝達できる場合にはシングルホップ通信をすると決定できる。よって、無線リソースの使用を抑制しつつ、通信の信頼性を向上できる。

Description

メッセージ制御装置、及び、メッセージ制御方法

関連出願の相互参照

　この出願は、２０２２年９月２９日に日本に出願された特許出願第２０２２－１５６６８１号を基礎としており、基礎の出願の内容を、全体的に、参照により援用している。

　本開示は、メッセージをシングルホップ通信及びマルチホップ通信のいずれでも送信できるメッセージ制御装置、及び、メッセージ制御方法に関する。

　自動運転、安全運転支援などのために、車両が取得した情報を他の車両あるいは路側機と無線を介して共有することが検討されている。また、車車間通信及び路車間通信において、シングルホップ通信又はマルチホップ通信を用いることが検討されている。シングルホップ通信は、送信元ノードから宛先ノードへパケットを直接送信する。マルチホップ通信は、送信元ノードから１つ以上のノードを介して宛先のノード又はエリアへパケットを送信する。例えば、路側通信機の電波が届く範囲から車載通信機が外れている場合、車載通信機はマルチホップ通信を用いて路側通信機と通信する（特許文献１）。

特許第５９０９９６０号公報

　マルチホップ通信の多用は通信容量が多くなりすぎ、また通信帯域を圧迫する。すなわち、マルチホップ通信の多用は無線リソースを多く使用する。そのため、多くの通信にシングルホップ通信を用いることが検討されている。しかしながら、シングルホップ通信の信頼性は、マルチホップ通信の信頼性よりも低くなる場合も生じる。

　そこで、本開示は、無線リソースの使用を抑制しつつ、通信の信頼性を向上させるメッセージ制御装置、及び、メッセージ制御方法を提供することを目的の１つとする。

　本開示の一態様に係るメッセージ制御装置は、メッセージの送信にマルチホップ通信が必要であるか否かを判定する制御部と、マルチホップ通信が必要であると判定された場合、マルチホップ通信を用いてメッセージを送信する通信部と、を含む。

　本開示の一態様に係るメッセージ制御方法は、メッセージの送信にマルチホップ通信が必要であるか否かを判定することと、マルチホップ通信が必要であると判定された場合、マルチホップ通信を用いてメッセージを送信することと、を含む。

　本開示の一態様によれば、無線リソースの使用を抑制しつつ、通信の信頼性を向上できる。

図１は、一実施形態に係る高度道路交通システムの概略構成の一例を示す図である。図２Ａは、ＧＵＣの一例を示す図である。図２Ｂは、ＧＡＣの一例を示す図である。図２Ｃは、ＧＢＣの一例を示す図である。図３は、シングルホップ通信の失敗の一例を示す。図４は、制御部の動作の一例を示す図である。図５は、制御部の動作の別の一例を示す図である。図６は、第１の実施形態に係るマルチホップ通信及び宛先の決定の一例を示す。図７は、第１の実施形態に係るマルチホップ通信及びシングルホップ通信の決定の一例を示す。図８は、第３の実施形態に係るマルチホップ通信及び宛先の決定の一例を示す。図９は、第４の実施形態に係るマルチホップ通信及び宛先の決定の一例を示す。図１０は、第７の実施形態に係る車両によるマルチホップ通信及び宛先の決定の一例を示す。図１１は、第７の実施形態に係るＲＳＵによるマルチホップ通信及び宛先の決定の一例を示す。図１２は、一実施形態に係る車両の一例を示す図である。図１３は、一実施形態に係るＲＳＵの一例を示す図である。

　以下、本開示の実施の形態について添付図面を参照して詳細に説明する。以下の説明では、同一の部には同一の符号が付される。同一の部は名称、機能などが同じであるため、詳細な説明は繰り返さない。

　（高度道路交通システム）
　図１は、一実施形態に係る高度道路交通システムの概略構成の一例を示す図である。図１に示す高度道路交通システム１は、車両１０と、路側機２０と、ＩＴＳサーバ３０と、を含んでもよい。高度道路交通システム１は、Intelligent Transport System（以下、ＩＴＳ）、道路交通システム、交通システムなどと互いに読み替えられてもよい。路側機２０は、Road-Side Unit（以下、ＲＳＵ）２０と呼ばれてもよい。

　ＩＴＳ１は、情報（例えば、交通情報、自動運転のための情報など）を複数の車両において共有するシステム（いわゆる協調ＩＴＳ（Cooperative ITS（ＣＩＴＳ）））と呼ばれてもよい。ＩＴＳ１において、本開示の後述の各実施形態に係るメッセージ制御方法のいずれか又はこれらの組み合わせを用いて通信が行われる。

　車両１０は、車道上を走行する車である。車両１０は、自動車であってもよいし、自動では動かない車（例えば自転車）であってもよい。自動車は四輪車両及び二輪車両の一方又は両方であってもよい。

　車両１０は、車載の通信装置を有し、無線通信により、他の車両１０、ＲＳＵ２０、ＩＴＳサーバ３０などと通信できる。無線通信の方式は、例えば、Long Term Evolution（ＬＴＥ）、5th generation mobile communication system（５Ｇ）、Ｗｉ－Ｆｉ（登録商標）である。

　車両１０間の直接通信は、Vehicle-to-Vehicle（Ｖ２Ｖ）通信と呼ばれてもよい。車両１０及びＲＳＵ２０の通信は、Vehicle to Infrastructure（Ｖ２Ｉ）通信と呼ばれてもよい。Ｖ２Ｖ通信及びＶ２Ｉ通信は、Vehicle-to-Everything（Ｖ２Ｘ）通信と呼ばれてもよい。

　車両１０間で送信されるメッセージとしては、例えば以下の少なくとも１つが用いられてもよい：
　・車両の位置、速度などを定期的に送信する協調認識メッセージ（Cooperative Awareness Message（ＣＡＭ））、
　・特定の事態が生じるときに通知する分散型環境通報メッセージ（Decentralized Environmental Notification Message（ＤＥＮＭ））、
　・知覚センサに基づいて知覚（認識）される環境を共有するための集団知覚メッセージ（Collective Perception Message（ＣＰＭ））。

　ＣＡＭは、ＥＴＳＩ（European Telecommunications Standards Institute）が提案する協調認識（ＣＡ（Cooperative Awareness））サービスにおいて送信されるメッセージである。道路交通における協調認識は、道路利用者及び路側インフラストラクチャが相互の位置、動態及び属性を知ることができることを意味する。道路利用者とは、自動車、トラック、オートバイ、自転車、歩行者等、交通安全や制御を行う道路上や周辺のあらゆる利用者を指し、路側インフラストラクチャとは、道路標識、信号機、障壁、入口などの設備を指す。

　ＣＰＭは、ＥＴＳＩが提案するＣＰサービスにおいて送信されるメッセージである。ＣＰサービスは、ＣＰＭを送信する車両で検出された周囲の道路利用者や他の物標の位置、挙動、属性を、周囲に通知するサービスである。

　ＲＳＵ２０は、周辺の道路状況、周辺の信号機の情報などを収集する。信号機の情報には、信号機の灯色を含めることができる。また、ＲＳＵ２０は、収集した情報を、車両１０、他のＲＳＵ２０、ＩＴＳサーバ３０などと通信する機能を有する。信号機は交通信号機と呼ばれてもよい。信号機の情報は、交通信号状態を示す情報と呼ばれてもよい。ＲＳＵ２０はセンサを備えて、そのセンサにより情報を収集してもよい。このセンサにはカメラが含まれていてもよい。道路状況の一例は道路の混雑状況、落下物の有無、路面の状況である。

　ＲＳＵ２０は、車両１０及びＩＴＳサーバ３０間の通信を中継してもよい。ＲＳＵ２０は、信号機、センサの一方又は両方と、有線又は無線によって通信可能なように接続されてもよい。

　なお、ＲＳＵ２０が備える通信部として移動通信端末が用いられてもよい。移動通信端末は、例えば、携帯電話、スマートフォン、タブレット型端末などの携帯端末である。通信端末は、カメラなどのセンサを１つ以上搭載しているため、有用な情報の提供に寄与することが期待される。

　ＩＴＳサーバ３０は、車両１０、ＲＳＵ２０などから受信した情報に基づいて、車両１０に対して交通情報、運転支援のための情報などを提供したり、信号機の灯色を制御したりしてもよい。ＩＴＳサーバ３０は、クラウドサーバでもオンプレミスサーバでもよい。車両１０など各装置の機能構成及びハードウェア構成の一例については後述する。

　なお、図１に示すＩＴＳ１のシステム構成は一例であり、ＩＴＳシステム１の構成は図１に示す構成に限られない。当然、車両１０の数は図１に示した数に限られない。また、ＲＳＵ２０、ＩＴＳサーバ３０の数も、図１に示した数に限られない。

　（Ｖ２Ｘ通信）
　欧州のＶ２Ｘ規格において、車両の位置情報を用いてルーティングを行うGeoNetworkingが検討されている。GeoNetworkingは、ポイント・ツー・ポイント（Point-to-Point）通信及びポイント・ツー・マルチポイント（Point-to-Multipoint）通信における転送方式（地理的アドレス指定方法及び転送アルゴリズム）を含む。GeoNetworkingの転送方式として、Single Hop Broadcast（ＳＨＢ）、GeoUnicast（Geographically-Scoped Unicast（ＧＵＣ））、GeoAnycast（Geographically-Scoped AnyCast（ＧＡＣ））、GeoBroadcast（Geographically-Scoped BroadCast（ＧＢＣ））、Topologically Scoped Broadcast（ＴＳＢ）、が検討されている。

　送信元の通信装置、受信する通信装置はノードと呼ばれてもよい。転送は、受信と送信を行うので転送する通信装置もノードと呼ばれてもよい。図２Ａの例のように、ＧＵＣにおいて、送信元の車両は、宛先として１つの車両が存在している位置を指定し、周辺の車両へメッセージを送信する。そのメッセージは、宛先へ近づくように転送されることによって、宛先の車両へ到達する。位置は、たとえば、座標によって指定される。

　図２Ｂの例のように、ＧＡＣにおいて、送信元の車両は、宛先として１つのエリアを指定し、周辺の車両へメッセージを送信する。エリアは範囲と読み替えてもよい。宛先とするエリアの形状は、たとえば、円形、長方形、楕円のいずれかである。送信元の車両が送信したメッセージは、宛先として指定されたエリアへ近づくように転送されることによって、宛先のエリア内のいずれか１つの車両へ到達する。

　図２Ｃの例のように、ＧＢＣにおいて、送信元の車両は、宛先として１つのエリアを指定し、周辺の車両へメッセージを送信する。そのメッセージは、宛先のエリアへ近づくように転送される。ＧＢＣも、宛先とするエリアの形状を、たとえば、円形、長方形、楕円のいずれかとすることができる。宛先のエリアに存在するいずれか１つの車両がメッセージを受信した場合、その車両から宛先のエリアにメッセージがブロードキャストされる。メッセージにより指定されたエリア内に存在する車両は、ブロードキャストされたメッセージを受信した場合、そのメッセージを再度ブロードキャストする。一度、メッセージをブロードキャストした車両は、その後はメッセージを受信しても、再度、メッセージをブロードキャストしない。このようにして、宛先となっているエリアに存在している全部の車両にメッセージが伝達される。

　ＴＳＢは、ホップ回数がｎ回であり、各回ともメッセージを周囲にブロードキャストする。ＳＨＢはホップ回数が１回であるＴＳＢと考えてもよい。

　ＳＨＢは、シングルホップ通信、シングルホップ型通信、と呼ばれてもよい。ＧＵＣ、ＧＡＣ、ＧＢＣ、ＴＳＢは、マルチホップ通信、マルチホップ型通信と呼ばれてもよい。

　メッセージの種別に応じた転送方式を用いることが検討されている。例えば、ＤＥＮＭに対してＧＢＣが用いられることが検討されている。ＤＥＮＭは、路面凍結や道路上の障害物などの環境の情報を伝達するメッセージであり、後続の複数の車両にその環境の情報を伝える必要がある。そのため、ＤＥＮＭには、ブロードキャストが用いられ、マルチホップ通信が好ましい場合が多い。

　マルチホップ通信は、送信元の車両から宛先の車両へ中継車両を経由することで、ＳＨＢよりも遠くの車両へメッセージを送ることができる。また、マルチホップ通信は、電波障害物によりＳＨＢではメッセージを送信しにくいエリアへも、そのメッセージを送信できる可能性もある。しかしながら、マルチホップ通信の多用は、無線リソースを多く使用する。

　そのため、Ｖ２Ｘ通信はＳＨＢを用いる場合が多い。例えば、ＣＡＭ、ＣＰＭ、Basic Safety Message（以下、ＢＳＭ）のように定期的に送信されるメッセージに対して、ＳＨＢを用いることが検討されている。ＢＳＭは、ＳＡＥ（Society of Automotive Engineers）が提案するメッセージであり、用途はＣＡＭと同様である。ＢＳＭは、ＣＡＭと同様、車両の位置、速度などを含んでもよい。

　ＳＨＢを用いることで通信容量の圧迫などの問題が少なくなる。しかしながら、ＳＨＢでは、必要な宛先へメッセージが届けられない恐れがある。たとえば、ＳＨＢでは、図３の例のように、遮蔽物によって電波が送信元から送信先へ到達しない場合がある。図３の例では、交差点の周辺に構造物がある。構造物及び遮蔽物は電波遮蔽物あるいは電波障害物と言い換えられてもよい。自車は道路上を交差点へ向かっており、交差路上の他車へＳＨＢを用いてメッセージを送信する。しかし、そのメッセージを表している電波が遮蔽物を十分に回り込まず、送受信に失敗する場合がある。

　ＣＡＭなどの定期的に送信されるメッセージの送信をマルチホップ通信とすれば、図３に示す例において、自車が送信したメッセージは交差路上の他車へ到達する可能性が高くなる。しかし、マルチホップ通信を多用すると、無線リソースを多く使用する。

　そこで、本開示の開発者は、マルチホップ通信を多用することによる生じる問題を低減しつつ、より確実なＶ２Ｘ通信を行う方法を着想した。

　なお、以下の実施形態の説明において、Ｖ２Ｘ通信装置によって通信されるメッセージは、ＣＰＭ、ＣＡＭ、ＤＥＮＭ、ＢＳＭのいずれかであってもよいし、CAR 2 CAR Communication Consortium（Ｃ２ＣＣＣ）の基本システム構成（Basic System Profile（ＢＳＰ））、その他の規格において規定されるメッセージであってもよい。以下の実施形態のメッセージは、周期的に送信するメッセージである。ただし、実施形態のメッセージは、周期的に送信しないメッセージであってもよい。また、実施形態のメッセージ周期的に送信するメッセージと周期的に送信しないメッセージとを含んでいてもよい。

　Ｖ２Ｘ通信装置は車両１０に搭載される。Ｖ２Ｘ通信装置はＲＳＵ２０に搭載されてもよい。Ｖ２Ｘ通信装置はＩＴＳステーション（ＩＴＳ－Ｓ）に対応していてもよいし、ＩＴＳ－Ｓに含まれていてもよい。ＩＴＳ－Ｓは、情報交換を行う装置であり、ＯＢＵ（On-Board Unit）、ＲＳＵ、携帯端末のいずれでもよく、また、それらに含まれるものであってもよい。携帯端末は、例えばＰＤＡ（Personal Digital Assistant）あるいはスマートフォンである。ＯＢＵは車載機と呼ばれてもよい。

　（メッセージ制御方法）
　本開示の一実施形態に係るメッセージ制御方法について、以下で説明する。各メッセージ制御方法は、上述のＩＴＳ１に適用されてもよい。

　図１２を用いて後述するように、車両１０は、制御部１１、センサ１２、ロケータ１３、入力／出力部１４、通信部１５を備えてもよい。

　通信部１５は、Ｖ２Ｘ通信を行ってもよい。制御部１１は、Ｖ２Ｘ通信によって得られる情報を取得してもよい。Ｖ２Ｘ通信によって得られる情報は、Ｖ２Ｘ受信結果であってもよい。Ｖ２Ｘ受信結果はＶ２Ｘ通信状態を示す情報であってもよい。

　Ｖ２Ｘ通信状態は、Ｖ２Ｘ通信の品質を示していてもよい。Ｖ２Ｘ通信の品質は受信状況を示すものであってもよい。Ｖ２Ｘ通信状態は、例えば、送信の成功あるいは失敗、受信の成功あるいは失敗を示してもよい。また、Ｖ２Ｘ通信状態は、ACKnowledgement（ＡＣＫ）及び／又はNegative ACKnowledgement（ＮＡＣＫ）の受信の成功あるいは失敗を示してもよい。Ｖ２Ｘ受信状態は、受信信号の測定結果、誤り率、ＳＮＲ（Signal to Noise Ratio）の少なくとも１つであってもよい。誤り率は、Packet Error Rate（ＰＥＲ）、BLock Error Rate（ＢＬＥＲ）、Bit Error Rate（ＢＥＲ）などにより表してもよい。

　Ｖ２Ｘ通信状態は、Ｖ２Ｘ通信によって受信されるメッセージに含まれる情報であってもよい。このメッセージは、パケット単位で通信されてもよい。メッセージはデータと読み替えてもよい。Ｖ２Ｘ通信によって受信されるメッセージは、他車の状態（以下、他車状態）、ＲＳＵの状態（以下、ＲＳＵ状態）、交通信号機の状態（以下、交通信号状態）、交通情報、ノードの位置（以下、ノード位置）、マルチホップ通信の要求（以下、マルチホップ通信要求）、の少なくとも１つを含んでもよい。通信要求は通信指示であってもよい。

　車両からのメッセージは、他車状態、ノード位置、マルチホップ通信要求、の少なくとも１つを含んでもよい。他車状態は、他車の位置（以下、他車位置）、他車の速度、他車のブレーキ状態の少なくとも１つを含んでもよい。ＲＳＵ２０からのメッセージは、ＲＳＵ状態、ノード位置、交通信号状態、交通情報、マルチホップ通信要求、の少なくとも１つを含んでもよい。交通信号状態は、ＲＳＵ２０と接続あるいは連携している交通信号機の状態を含んでもよい。交通信号機の状態は、交通信号機の灯色を含んでいてもよい。交通信号機の状態は、通行可能であるか通行不可であるかを示す情報を含んでいてもよい。通信部１５は、放送及び／又はＶ２Ｘ通信によって交通情報を取得してもよい。交通情報は、渋滞に関する情報（例えば、渋滞の位置）を含んでもよい。

　通信部１５は、制御部１１によって決定された通信方式を用いてメッセージを送信してもよい。制御部１１は、通信方式を、マルチホップ通信及びシングルホップ通信のいずれとするかを決定する。また、制御部１１は、マルチホップ通信すると決定した場合、転送方式も決定し、かつ、決定した転送方式に応じて定まる通信パラメータも決定する。通信パラメータは、ホップ数、宛先などを含む。通信パラメータは通信設定と読み替えてもよい。宛先が点である場合、宛先は、位置を含んでいてもよい。位置は、緯度及び経度によって表されてもよい。宛先が点である場合は、転送方式がＧＵＣである場合であってもよい。宛先がエリアである場合、宛先は、エリアの形状及びエリアの位置を含んでもよい。エリアの形状は、円形、長方、楕円の１つ以上を含む複数の候補形状の１つを示していてもよい。宛先がエリアである場合は、転送方式がＧＡＣ又はＧＢＣである場合であってもよい。エリアの位置は、エリアの中心位置と、エリアのサイズと、エリアの角度と、の１つ以上を含んでいてもよい。エリアの中心位置は、緯度及び経度によって表されてもよい。エリアの形状が円形である場合、エリアのサイズは、半径であってもよい。エリアの形状が長方形である場合、エリアのサイズは、長辺の長さ及び短辺の長さであってもよく、エリアの角度は長辺の方位角であってもよい。エリアの形状が楕円である場合、エリアのサイズは、長軸の長さ及び短軸の長さであってもよく、エリアの角度は長軸の方位角であってもよい。宛先のエリアは、宛先エリア、推定エリア、見通し外通信となるエリア、シングルホップ通信が困難であるエリア、マルチホップ通信を必要とするエリア、などと読み替えてもよい。制御部１１は、宛先を推定し、宛先が点である場合に、転送方式をＧＵＣと決定してもよい。制御部１１は、宛先を推定し、宛先がエリアである場合に、転送方式をＧＡＣ又はＧＢＣと決定してもよい。宛先がエリアである場合、制御部１１は、推定したエリアを、複数の候補形状の１つに近似し、エリアの形状及びエリアの位置を決定してもよい。エリアの形状は、後述の実施形態によって異なってもよいし、マルチホップ通信の必要性の判定に用いる情報によって異なってもよい。

　センサ１２は、センサ１２が搭載された車両１０の周辺の環境（周辺環境情報）を検出してもよい。検出は、認識あるいは標定と読み替えてもよい。センサ１２が記載された車両１０を自車と記載することもある。センサ１２は、自車の周辺の道路形状、自車の周辺の交通信号機の交通信号状態、自車周辺に位置する交差点の周辺に存在する障害物の状況、自車に最も近い先行車の検出状況、の少なくとも１つを検出してもよい。自車の周辺には、自車の前方が含まれることが好ましい。センサ１２が検出する障害物は、遮蔽物と読み替えてもよい。センサ１２が検出する障害物には建物が含まれてもよい。

　制御部１１は、ロケータ１３からの情報に基づいて、自車の位置情報（以下、自車位置情報）を取得してもよい。取得は、測定、検出、算出のいずれかと読み替えてもよい。自車位置情報は、自車の位置、及び、自車の位置の変化に関連する情報の一方又は両方であってもよい。自車の位置は、例えば、緯度及び経度で表すことができる。自車の位置の変化に関連する情報は、例えば、自車の進行方向、速度の少なくとも１つを含んでもよい。

　制御部１１内のメモリ１１２は、地図情報を記憶してもよい。通信部１５は、地図情報を受信してもよい。地図情報は、道路及び交差点の位置を含む。地図情報は、道路構造を含んでいてもよい。道路構造は道路及び交差点の形状を含んでもよい。道路の形状は、その道路の曲がり具合を示す情報により表されてもよい。地図情報は、建物の位置を含んでもよい。建物の位置は、建物が存在する位置を示す１つの座標ではなく、建物が存在する範囲を示してもよい。建物が存在する範囲は構造物の配置と言い換えてもよい。地図情報は、少なくとも一部の道路について道路ごとの車両の平均速度を含んでもよい。

　制御部１１は、センサ１２、駆動部、操作部の少なくとも１つから、自車状態を取得してもよい。自車状態は、自車の速度、加速度、ブレーキ状態、自車の進行方向、ステアリング角度の１つ以上を含んでもよい。

　制御部１１内のメモリ１１２は、一定時間過去から現在までの自車の走行軌跡（自車位置情報の履歴）を記憶してもよい。走行軌跡は、ロケータ１３及びセンサ１２の一方又は両方からの情報に基づいて制御部１１が決定する。

　制御部１１は、周辺車両との連携運転の実行状況（連携運転状態）を記憶してもよいし、連携運転を制御してもよい。通信部１５は、連携運転状態を受信してもよい。連携運転は、自車及び周辺車両の隊列走行であってもよい。連携運転状態は、隊列走行が有効であるか無効であるかを含んでもよいし、隊列メンバの位置を含んでもよい。

　制御部１１は、車両及び環境の少なくとも１つの状態を示す情報（以下、状態情報）に基づいて、Ｖ２Ｘ通信におけるマルチホップ通信又はシングルホップ通信を制御してもよい。状態情報は、地図情報、自車位置情報、Ｖ２Ｘ通信状態、自車状態、走行軌跡、連携運転状態、周辺環境情報の１つ以上を含んでもよい。制御部１１は、状態情報に基づいて、マルチホップ通信の必要性と、宛先と、マルチホップ通信の最大ホップ数と、の少なくとも１つを判定してもよい。マルチホップ通信の必要性の判定により、通信方式をＳＨＢとするかマルチホップ通信とするかを判定することになる。宛先は、位置、エリアのいずれか１つであってもよい。

　後述のように、ＲＳＵ２０は、制御部２１、通信部２５を備える。制御部２１は、制御部１１と同様の機能を有していてもよい。制御部２１内のメモリ２１２は、ＲＳＵ２０の位置情報を記憶してもよいし、地図情報を記憶してもよい。通信部２５は、地図情報を受信してもよい。地図情報は、ＲＳＵ２０の周辺の道路及び交差点の形状を含んでもよい。地図情報は、ＲＳＵ２０の周辺の建物の位置を含んでもよい。地図情報は、少なくとも一部の道路について道路ごとの車両の平均速度を含んでもよい。

　通信部２５は、通信部１５と同様の機能を有していてもよい。通信部２５は、通信部１５の機能の他に、有線ネットワーク（例えば、光ファイバ網）に接続され、有線ネットワークとの通信を行ってもよいし、信号機に接続され、信号機との通信を行ってもよい。なお、ＲＳＵ２０はカメラなどを含むセンサで検出した情報を、通信部２５から、車両１０、他のＲＳＵ２０及びＩＴＳサーバ３０の少なくとも１つへ送信してもよい。

　図４は、制御部１１の動作の一例を示す。まずＳ１２０において、制御部１１は、状態情報を取得する。その後、Ｓ１３０において、制御部１１は、取得された状態情報に基づいて、メッセージの送信にマルチホップ通信が必要であるか否かを判定する。すなわち、メッセージの送信のための通信方式を、マルチホップ通信及びシングルホップ通信のいずれにするかを決定する。Ｓ１３０においてマルチホップ通信が必要であると判定した場合（Ｙ）、Ｓ１４０において、制御部１１は、Ｓ１２０で取得した状態情報に基づいて、マルチホップ通信の通信設定を決定する。決定する通信設定には宛先が含まれる。また、決定する通信設定には最大ホップ数が含まれていてもよい。宛先が車両の位置である場合、転送方式はＧＵＣとすることができる。転送方式も通信設定の１つとしてもよい。宛先がエリアである場合の転送方式の一例はＧＡＣあるいはＧＢＣである。

　その後、Ｓ１５０において、制御部１１は、Ｓ１４０で決定した通信設定によるマルチホップ通信を用いてメッセージを送信する。一方、Ｓ１３０においてマルチホップ通信が不要であると判定した場合（Ｎ）、Ｓ１６０において、制御部１１は、シングルホップ通信を用いてそのメッセージを送信する。図４に示す動作は、定期的に繰り返されてもよいし、送信するメッセージの発生の度に実行されてもよい。

　図５は、制御部１１の動作の別の一例を示す。図５に示す動作例は、メッセージ転送に関する動作例である。まずＳ２１０において、制御部１１は、通信部１５によって受信されたメッセージを取得する。その後、Ｓ２２０において、制御部１１は、状態情報を取得する。その後、Ｓ２３０において、制御部１１は、Ｓ２１０で取得したメッセージと、Ｓ２２０で取得した状態情報と、に基づいて、メッセージの送信にマルチホップ通信が必要であるか否かを判定する。すなわち、メッセージの送信のための通信方式を、マルチホップ通信及びシングルホップ通信のいずれにするかを決定する。

　このＳ２３０では、状態情報は用いず、Ｓ２１０で取得したメッセージを解析してマルチホップ通信が必要であるか（換言すれば転送が必要であるか）を判定してもよい。Ｓ２１０で取得したメッセージにより位置情報が指定されており、位置情報が示す位置に自車が存在していない場合、制御部１１はマルチホップ通信が必要であると判定する。この場合、転送方式はＧＵＣになる。

　また、Ｓ２１０で取得したメッセージにより宛先とするエリアが指定されており、そのエリアに自車が存在していない場合にも、制御部１１はマルチホップ通信が必要であると判定する。この場合、転送方式はＧＡＣあるいはＧＢＣになる。Ｓ２１０で取得したメッセージにより宛先とするエリアが指定されており、そのエリアに自車が存在している場合であっても、転送方式としてＧＢＣが指定されている場合には、メッセージを転送すると判定することもある。たとえば、そのエリアにまだメッセージを受信していない車両が存在する場合には、メッセージを転送すると判定する。

　Ｓ２３０においてマルチホップ通信が必要であると判定した場合（Ｙ）、Ｓ２４０において、制御部１１は、Ｓ２１０で取得したメッセージ、及び、Ｓ２２０で取得した状態情報の一方又は両方に基づいて、マルチホップ通信の通信設定を決定する。その後、Ｓ２５０において、制御部１１は、Ｓ２１０で受信したメッセージを送信すなわち転送する。一方、Ｓ２３０において、マルチホップ通信が不要であると判定した場合（Ｎ）、制御部１１は、Ｓ２１０で受信したメッセージを転送せずにこの動作を終了する。この動作は、通信部１５がメッセージを受信する度に実行されてもよいし、定期的に繰り返されてもよい。

　図５の動作を実行するメッセージは、定期的に送信されるメッセージであってもよい。定期的は周期的と読み替えてもよい。定期的の一例は、１０Ｈｚから１Ｈｚの間の送信頻度（レート）、すなわち、１００ｍｓから１０００ｍｓの間の送信間隔である。たとえば、前述のＣＡＭ、ＣＰＭ、ＤＥＮＭの１つ以上のメッセージについて図５の動作を実行してもよい。

　本開示において、制御部１１の動作は、制御部２１の動作と読み替えられてもよい。本開示において、通信部１５の動作は、通信部２５の動作と読み替えられてもよい。

　＜第１の実施形態＞
　制御部１１は、地図情報及び自車位置情報の少なくとも一方に基づいて、マルチホップ通信の必要性を判定してもよい。制御部１１によりマルチホップ通信が必要であると判定された場合、通信部１５は、マルチホップ通信を用いてメッセージを送信してもよい。制御部１１によりマルチホップ通信が不要であると判定された場合、通信部１５は、シングルホップ通信を用いてメッセージを送信してもよい。

　制御部１１は、地図情報及び自車位置情報に基づいて、自車の前方に交差点が存在するか否かを判定してもよい。自車の前方は、ＳＨＢによる通信距離以内の前方であってもよい。あるいは、自車の前方は、数百メートル以下に定められた判定距離以下の前方であってもよい。通信距離および判定距離は所定距離の一例である。判定距離は自車の速度により変化させてもよい。判定距離は、一定時間に自車が走行できる距離であってもよい。前方は、自車が走行中の道路上に限られず、右左折などにより自車が走行可能な道路を含んでいてもよい。この判定は、図４のＳ１３０にて実行してもよい。自車の前方に交差点が存在すると判定した場合、その交差点の周辺に構造物が存在するか否かによらず、制御部１１は、マルチホップ通信が必要であると判定してもよい。交差点の周辺には構造物が存在する場合が多いからである。ただし、次に説明するように構造物の存在を考慮してもよい。

　制御部１１は、地図情報及び自車位置情報に基づいて、自車の前方の交差点の周辺に存在する構造物の配置を取得してもよい。制御部１１は、その構造物の配置に基づいて、交差路上の車両とのシングルホップ通信が困難であるか否か、すなわち、交差路上の車両とのシングルホップ通信による通信品質が悪いか否かを推定してもよい。また、制御部１１は、その構造物の配置に基づいて、交差路上の車両との通信が見通し（line of sight、ＬＯＳ）通信であるか見通し外（non line of sight、ＮＬＯＳ）通信であるかを推定してもよい。制御部１１は、交差路上のエリア、かつ、構造物を考慮しない場合にシングルホップ通信可能なエリアのうち、構造物によって自車から遮蔽されるエリア（見通し外通信となるエリア）をシングルホップ通信が困難であるエリアと推定してもよい。制御部１１は、電波の回り込みを考慮し、見通し外通信となるエリアが少ない場合にはシングルホップ通信が困難であると推定しなくてもよい。したがって、見通し外通信となる角度、見通し通信となる角度に対する見通し外通信となる角度の割合が、それらに対して設定された閾値以上である場合に、制御部１１は、シングルホップ通信が困難であると推定してもよい。電波の回り込みは、電波の周波数によって異なる。メッセージが送信される電波の周波数は５ＧＨｚ帯、７００ＭＨｚ帯など種々の周波数帯の周波数であってもよい。シングルホップ通信が困難であると推定された場合、制御部１１は、マルチホップ通信が必要であると判定してもよい。

　制御部１１は、自車の前方の交差点に交通信号機があるか否かを判定してもよい。交通信号機があるか否かは、地図情報及び自車位置情報から判定してもよい。また、交通信号機があるか否かは、路側機との通信により判定してもよいし、カメラなどのセンサ１２から提供される信号に基づいて判定してもよい。その交差点に交通信号機がある場合、制御部１１は、マルチホップ通信が不要であると判定してもよい。交通信号機により、交差点に進入できる車両が制御されるので、通信不能となったときの問題が生じにくいからである。

　〔通信設定〕
　次に、通信設定について説明する。制御部１１は、ＳＨＢが困難であると推定したエリアを含む宛先エリアを設定してもよい。また、制御部１１は、交差路上の車両とのＳＨＢが困難であると推定した場合、地図情報と自車位置情報と自車の速度とに基づいて、自車の前方の交差路上にマルチホップ通信の宛先となるエリアを推定してもよい。宛先となるエリアは、その交差路上であって自車から一定距離内である範囲と、交差路上であって自車の進行方向から一定角度内である範囲と、交差路上であって自車から見て構造物に隠れる範囲と、の少なくとも１つを満たす範囲であってもよい。また、宛先となるエリアは、交差路上を走行する車両が交差点に進入する時刻が、自車が交差点に進入する時刻と重なる可能性があるエリアとしてもよい。

　図６の例において、自車は、道路上を交差点へ走行している。構造物により自車の走行路に対する交差路上へのシングルホップ通信が困難であると判定された場合、自車は、マルチホップ通信が必要であると判定する。マルチホップ通信での宛先エリアは、交差路上を走行する車両が交差点に進入する時刻が、自車が交差点に進入する時刻と重なる可能性があるエリアとしてもよい。自車が交差点に進入する時刻は、自車の車速と交差点までの距離から推定できる。この時刻に、交差路上を走行する車両が交差点に進入するかどうかは、交差路上を走行する車両の位置と速度とにより算出できる。交差路上を走行する車両の速度が事前に設定した速度範囲であるとすれば、自車は、自車と同じ時刻に交差点に進入できる交差路上の車両が位置するエリアを算出できる。

　図６に示す推定エリアは、このようにして算出したエリアを説明している。図６に示す推定エリアの形状は、交差路に沿った長方形のエリアである。自車は、マルチホップ通信の宛先としてこの推定エリアを指定し、マルチホップ通信を用いてメッセージを送信してもよい。エリアを指定するので、転送方式としてＧＡＣあるいはＧＢＣを用いることができる。図６では、自車がマルチホップ通信を設定して送信したメッセージを、自車より推定エリアに近く、かつ、自車と同じ車線上を走行する他車が推定エリアに転送している。

　制御部１１は、宛先とするエリアまでの距離に応じて最大ホップ数を決定してもよい。また、最大ホップ数は事前に設定された固定値であってもよい。

　図７の例は、マルチホップ通信とシングルホップ通信とを併用する例である。図７に示す例は、図６に示す例よりも交差点周囲に位置する構造物が小さい。そのため、推定エリアｂに位置する車両との間ではＳＨＢが可能である。推定エリアｂは、見通し通信可能なエリアであってもよい。図７に示す自車の位置及び速度は図６と同じであるとする。推定エリアａは、図６に示す推定エリアから推定エリアｂを除いたエリアであってもよい。

　図７の例では、自車は、図４のＳ１４０で決定する通信設定において、推定エリアａを宛先に決定し、Ｓ１５０にてメッセージを送信する。更に自車は、交差路上のエリアのうち、ＳＨＢが可能な推定エリアｂへはマルチホップ通信が不要であると判定し、推定エリアｂあるいは推定エリアｂ内の他車に対し、ＳＨＢなどのシングルホップ通信を用いてメッセージを送信してもよい。なお、自車は、先に推定エリアｂに向けてメッセージを送信し、その後、推定エリアａにメッセージを送信してもよい。

　制御部１１は、地図情報と自車位置情報とに基づいて、宛先までの経路の複雑度を決定してもよい。宛先までの経路は道路を走行する場合の経路である。その複雑度は、その経路において交差点などで曲がる回数に基づいて決定してもよい。電波は直進性が高いので、曲がる回数が多いほどシングルホップ通信ではメッセージを伝達できない可能性が高くなるからである。もちろん、地図情報に基づいて構造物の存在の有無を考慮してもよい。ただし、曲がる回数が多い地域は、市街地など構造物が存在している可能性が高い地域であることが多いので、宛先までの直線方向には構造物が存在しているとみなしてもよい。

　また、距離が遠いほどシングルホップ通信ではメッセージを伝達しにくくなる。制御部１１は、宛先までの経路において曲がる回数と宛先までの距離に基づいて複雑度を決定してもよい。制御部１１は、上記経路において曲がる回数が多くなるほど、また、距離が遠いほど複雑度を高い値にしてもよい。

　制御部１１は、その複雑度に基づいて、マルチホップ通信の最大ホップ数を決定あるいは変更してもよい。また、前述したように、距離が遠いほどシングルホップ通信ではメッセージを伝達しにくくなるので、距離に応じてマルチホップ通信の最大ホップ数を決定あるいは変更してもよい。制御部１１は、マルチホップ通信が必要であると判定された場合にマルチホップ通信の最大ホップ数を決定あるいは変更してもよい。

　制御部１１は、複雑度が閾値より高い又は閾値以上である場合、最大ホップ数の値を、複雑度が閾値以下又は閾値よりも低い場合よりも増加させてもよい。制御部１１は、複雑度が閾値より高い又は閾値以上である場合、最大ホップ数を第１値から第２値へ変更し、第２値をマルチホップ通信に用いてもよい。制御部１１は、第１値に一定数を加算することによって第２値を算出してもよい。第１値は、仕様において規定された値であってもよいし、以前に決定あるいは設定された値であってもよい。第２値は、仕様において規定された値であってもよい。第１値と第２値は車両状況や周辺状況に応じて変更される値であってもよい。

　この実施形態によれば、車両は、地図情報及び自車位置情報の少なくとも一方に基づいて、メッセージをマルチホップ通信するかシングルホップ通信するかを決定する。これにより、マルチホップ通信をする必要性が高い場合にはマルチホップ通信をすると決定でき、シングルホップ通信でもメッセージを伝達できる場合にはシングルホップ通信をすると決定できる。よって、無線リソースの使用を抑制しつつ、通信の信頼性を向上できる。

　＜第２の実施形態＞
　制御部１１は、Ｖ２Ｘ通信によって得られる情報に基づいて、マルチホップ通信の必要性を判定してもよい。制御部１１は、マルチホップ通信が必要であると判定した場合、Ｖ２Ｘ通信によって得られる情報に基づいて、マルチホップ通信の通信設定を決定してもよい。制御部１１は、決定するマルチホップ通信の通信設定に、宛先とマルチホップ通信の最大ホップ数の一方又は両方を含めてもよい。

　制御部１１によりマルチホップ通信が必要であると判定された場合、通信部１５は、マルチホップ通信を用いてメッセージを送信してもよい。制御部１１によりマルチホップ通信が不要であると判定された場合、通信部１５は、シングルホップ通信を用いてメッセージを送信してもよい。

　制御部１１は、Ｖ２Ｘ通信によって他車から受信した受信メッセージから他車位置を取得してもよいし、受信メッセージ内の他車状態に基づいて、他車通行エリアを推定してもよい。他車通行エリアは、他車がこの後一定時間内に通行すると推定できるエリアである。他車通行エリアは、他車の位置、進行方向、速度をもとに推定できる。制御部１１は、他車位置あるいは他車通行エリアに基づいて、他車の進行方向の前方に交差点（例えば、自車の前方の交差点）が存在するか否かを判定してもよい。制御部１１は、その交差点の存在に基づいて、マルチホップ通信の必要性を判定してもよい。前方の意味は、自車の場合と同じ意味であってよい。制御部１１は、例えば、他車の前方に交差点が存在すると判定された場合、マルチホップ通信が必要であると判定してもよい。また、制御部１１は、他車の前方に存在する交差点が、自車の前方に存在する交差点でもあると判定された場合に、自車が送信するメッセージはマルチホップ通信が必要であると判定してもよい。

　制御部１１は、他車からのメッセージの受信状況に基づいて、他車が存在するエリアとのシングルホップ通信が困難であるか否かを判定してもよい。受信状況は通信品質に置き換えてもよい。受信状況は、ＰＥＲなど、前述したＶ２Ｘ受信状態をもとに判定してよい。その通信が困難であると判定された場合、制御部１１は、マルチホップ通信が必要であると判定してもよい。ここでのマルチホップ通信は、他車からのメッセージに基づき、他車位置が分かっている場合にはＧＵＣとしてもよい。

　制御部１１は、他車状態と自車状態に基づいて、他車が自車へ接近する可能性が高いか否かを判定してもよい。他車の進行方向と自車の進行方向とが交差しており、かつ、その交差する点へ他車が到達する予想時刻と自車が到達する予想時刻とが近い場合に、制御部１１は、他車が自車へ接近する可能性が高いと判定してもよい。予測時刻が近いとは、たとえば、２つの予想時刻の差が数秒程度であることを意味していてもよい。他車及び自車は、道路を走行するので、他車が自車へ接近する可能性が高いか否かを判定する際に、制御部１１は、地図情報をさらに用いてもよい。予想時刻の算出には、自車及び他車の位置及び速度に加え、自車及び他車の加速度も用いてもよい。加速度がマイナスである場合、車両は減速中である。ブレーキ操作により車両は減速できる。したがって、制御部１１は、ブレーキ状態に基づいて加速度を決定してもよい。

　他車が自車へ接近する可能性が高いと判定された場合、制御部１１は、マルチホップ通信が必要であると判定してもよい。他車が自車へ接近する可能性が高い場合、自車のメッセージを他車に届ける必要性が高いからである。なお、他車が自車へ接近する可能性が高い場合であっても、他車との間に構造物がないなど、シングルホップ通信で通信できる可能性が高いと判定できる場合には、制御部１１は、マルチホップ通信が必要であると判定しなくてもよい。

　また、制御部１１は、他車状態に基づいて、他車が高速である、又は、他車の状況の緊急性が高い場合に、マルチホップ通信が必要であると判定してもよい。制御部１１は、自車状態に基づいて、自車が高速である、又は、自車の状況の緊急性が高い場合に、マルチホップ通信が必要であると判定してもよい。

　制御部１１は、Ｖ２Ｘ通信によってＲＳＵ２０から受信されるメッセージに基づいて、自車が送信あるいは転送するメッセージをマルチホップ通信とするか否かを判定してもよい。たとえば、ＲＳＵ２０から受信されるメッセージに含まれる交通信号状態に基づいて、交通信号機（例えば、自車の前方の交差点の交通信号機）の灯色が通行可能を示す色（たとえば青色あるいは緑色）であるか否かを判定してもよい。その交通信号機の灯色が通行可能を示す色であると判定された場合、制御部１１は、マルチホップ通信が必要であると判定してもよい。自車の前方の交差点の交通信号機が通行可能を示している場合、自車はその交差点に進入すると考えられる。そこで、制御部１１は、より高い確率で、自車の周辺に存在する他車へ自車が送信するメッセージを伝達できるようにするために、マルチホップ通信が必要であると判定することができる。ここでのマルチホップ通信は、自車が走行する道路と交差する交差路上であって交差点へ向かう方向のエリア、たとえば、図６に示した推定エリアを宛先とする転送方式とすることができる。この転送方式はＧＡＣ又はＧＢＣであってもよい。また、転送方式を、交差路において交差点に向かう先頭車両など、特定の他車の位置を宛先としたＧＵＣとしてもよい。

　ＲＳＵ２０は位置が固定されている。そのため、ＲＳＵ２０は、その周囲にある構造物によりシングルホップ通信では通信が困難であるか否かを把握できる。そこで、ＲＳＵ２０は、周囲にマルチホップ通信を指示あるいは要求する信号を送信してもよい。制御部１１は、ＲＳＵ２０からマルチホップ通信の指示あるいは要求が受信された場合、マルチホップ通信が必要であると判定してもよい。

　他車は、走行中に随時、Ｖ２Ｘ通信の通信品質を判定できる。その他車において、マルチホップ通信が必要であると判定した場合、後続車もマルチホップ通信が必要である可能性が高い。したがって、上記他車は、周囲にマルチホップ通信の指示あるいは要求を含むメッセージを送信することがある。制御部１１は、他車からマルチホップ通信の指示あるいは要求を受信した場合、マルチホップ通信が必要であると判定してもよい。

　前述した他車と同様に、自車も、周囲の車両が送信するメッセージはマルチホップ通信が必要であると判定した場合、制御部１１は、マルチホップ通信要求を他車及びＲＳＵ２０へ送信してもよい。自車が送信したマルチホップ通信要求を受信した他車は、その他車が送信するメッセージをマルチホップ通信で送信してもよい。また、自車が送信したマルチホップ通信要求を受信したＲＳＵ２０は、周囲にマルチホップ通信を指示あるいは要求する信号を送信してもよい。制御部１１は、マルチホップ通信要求の送信に、マルチホップ通信を用いてもよい。なお、制御部１１は、自車が送信するメッセージをマルチホップ通信とする場合には、メッセージの通信設定をマルチホップ通信する設定とする。

　制御部１１は、他車からＶ２Ｘ通信により受信するメッセージの通信状態に基づいて、自車が送信するメッセージに対してマルチホップ通信が必要であるか否かを判定してもよい。たとえば、制御部１１は、他車から受信する予定のメッセージを受信したか否かにより、自車が送信するメッセージに対してマルチホップ通信が必要であるか否かを判定してもよい。制御部１１は、他車から定期的にメッセージを受信している場合、又は、他車へメッセージを送信し、それに対する応答が必要とされている場合、その他車からメッセージを受信する予定であると判定してもよい。他車から受信する予定のメッセージが受信されなかった場合、制御部１１は、マルチホップ通信が必要であると判定してもよい。制御部１１は、他車からの直前の受信メッセージに基づいて、その他車の位置（他車位置）を取得してもよい。

　制御部１１は、マルチホップ通信が必要であると判定した場合、その他車位置をマルチホップ通信の宛先として指定してもよい。他車位置を宛先とする場合、マルチホップ通信としてＧＵＣを用いてもよい。制御部１１は、マルチホップ通信が必要であると判定した場合、他車が存在する可能性がある他車存在エリアを宛先としてメッセージをマルチホップ通信してもよい。他車の位置の推定精度が低い場合に宛先を他車存在エリアとすることが好ましい。他車の位置の推定精度が低下する一例は、他車との間の通信状態が悪く、定期的に他車が送信するメッセージを受信できない場合である。他車存在エリアは、その他車位置から一定距離内の円形エリアであってよい。また、他車存在エリアを、交差路上であって他車位置から一定距離内のエリアとしてもよい。また、他車位置の推定精度が悪いほど、他車存在エリアを大きくしてもよい。他車存在エリアを宛先とするマルチホップ通信としてＧＡＣあるいはＧＢＣを用いてもよい。

　図８の例において、自車は、道路上を交差点へ走行している。自車が走行する道路と交差する交差路には、車両１０である他車１０ａが自車と同じ交差点に向かって走行している。交差点周囲には構造物がある。自車と他車１０ａがこの構造物により見通し外となる位置関係ではＳＨＢは困難である可能性がある。

　時刻ｔ＝ｔ１時点では、自車と他車１０ａは構造物により遮蔽されない位置関係にあり、シングルホップ通信により相互に通信ができる。時刻ｔ＝ｔ１時点で、自車は他車１０ａからのメッセージを受信して、他車の位置、速度、進行方向を取得している。

　時刻ｔ＝ｔ２になると、自車と他車１０ａは、構造物により見通し外の位置関係になっている。そこで、自車は、送信するメッセージをＳＨＢからマルチホップ通信に切り替えて送信する。宛先とするエリアは、時刻ｔ１時点で取得している他車１０ａの速度と位置とをもとにして定まる時刻ｔ＝ｔ２での他車１０ａの位置を基準として、時刻ｔ＝ｔ１後に他車１０ａの速度が変化する可能性がある範囲を考慮して決定する。図８において、破線で示す四角は、このようにして決定した宛先とするエリアを説明している。また、自車は、時刻ｔ＝ｔ２における他車１０ａの位置を宛先とするＧＵＣでメッセージを送信してもよい。

　図８の例では時刻ｔ＝ｔ２において、自車より宛先に近くかつ自車と同じ車線上を走行する他車１０ｂが存在しており、この他車１０ｂが、自車が送信したメッセージを、交差路を走行している他車１０ａに転送している。

　この例では、図４のＳ１３０における判定条件を、交差路上の他車１０ａの存在を自車が認識できていること、自車と他車１０ａが接近する可能性があると判定したこと、構造物により自車と他車がＳＨＢでは通信が困難であると判定したこと、としている。

　自車は、この判定条件が成立した場合にはマルチホップ通信によりメッセージを送信し、この判定条件が成立しない場合にはシングルホップ通信によりメッセージを送信する。このようにすることで、無線リソースの使用を抑制しつつ、通信の信頼性を向上できる。

　＜第３の実施形態＞
　制御部１１は、走行軌跡（自車が過去に走行した経路）及び自車状態の少なくとも一方に基づいて、マルチホップ通信の必要性を判定してもよい。走行軌跡は、過去一定時間あるいは一定距離ごとに自車が存在した位置を示す情報であってよい。制御部１１によりマルチホップ通信が必要であると判定された場合、通信部１５は、マルチホップ通信を用いてメッセージを送信してもよい。制御部１１によりマルチホップ通信が不要であると判定された場合、通信部１５は、シングルホップ通信を用いてメッセージを送信してもよい。

　制御部１１は、自車状態に基づいて、マルチホップ通信が必要であるか否かを判定してもよい。例えば、自車状態に基づいて、自車の急ブレーキが検出された場合、又は、自車の故障あるいは異常が検出された場合、又は、後続車両が自車に接近する可能性が高いと推定される場合、制御部１１は、マルチホップ通信が必要であると判定してもよい。

　急ブレーキは、急減速、急制動と言うこともできる。急ブレーキは、加速度の絶対値が事前に設定された閾値より大きい負の加速度を意味する。故障あるいは異常は、走行系の装置の故障あるいは異常であってもよい。後続車両が自車に接近する可能性が高いと推定される一例は、自車の急ブレーキが検出された場合であって、自車の後方の一定距離内に後続車両が存在する、あるいは、存在する可能性が高い場合である。自車の後方の一定距離内に後続車両が存在するか否かは、後続車両との車車間通信により把握できる。交通量の多い道路を走行中であれば、自車の後方の一定距離内に後続車両が存在する可能性が高いと判定してよい。

　制御部１１は、走行軌跡に基づいて、マルチホップ通信が必要であるか否かを判定してもよい。ＳＨＢによる通信距離と同等に設定した走行軌跡において、右折あるいは左折した部分がある場合に、マルチホップ通信が必要であると判定してよい。

　制御部１１は、構造物の存在も考慮し、自車状態と走行軌跡と構造物が存在している範囲とに基づいて、マルチホップ通信が必要であるか否かを判定してもよい。制御部１１は、自車状態に基づいてマルチホップ通信が必要であると判定し、かつ、走行軌跡に基づいてマルチホップ通信が必要であると判定し、さらに、構造物によりＳＨＢではメッセージの通信が困難であると判定した場合に、マルチホップ通信が必要であると判定してよい。構造物の範囲は地図情報をもとに把握できる。また、構造物の範囲は、自車に備えられたセンサにより検出してもよい。

　制御部１１は、マルチホップ通信が必要であると判定した場合、走行軌跡に基づいて、マルチホップ通信の宛先を決定してもよい。例えば、自車の急ブレーキが検出された場合、制御部１１は、走行軌跡に基づいて、後続車両が存在する可能性が高いエリア（後続車両エリア）を決定し、その後続車両エリアを、マルチホップ通信の宛先として指定してもよい。後続車両エリアは、自車が送信するメッセージが後続車両に伝達されるべきエリアということもできる。後続車両エリアは、自車が送信するメッセージが後続車両に伝達されるべきエリアのうち、ＳＨＢではメッセージを伝達しにくいエリアを含んでいてもよい。

　後続車両エリアがＳＨＢではメッセージを伝達しにくいエリアを含んでいれば、その後続車両エリアを宛先として、マルチホップ通信によりメッセージを送信することで、自車のメッセージを高い確率で後続車両に伝えることができる。

　図９の例において、自車は、交差点を右折した後、急ブレーキを掛けた。自車状態に基づいて自車の急ブレーキが検出できる。また、走行軌跡に基づいて自車が右折直後であると判定できる。交差点周辺には、自車が現在走行する道路と、直前に走行していた道路とに隣接する構造物が存在する。そのため、自車は、送信するメッセージに対してマルチホップ通信が必要であると判定する。

　自車は、走行軌跡に基づいて後続車両エリアを決定する。図９に示す後続車両エリアは、ＳＨＢで送信すべき範囲に含まれる走行軌跡により特定される道路であって、自車が現在走行している道路に交差点で接続する道路上をエリアとしている。その後、自車は、後続車両エリアを、マルチホップ通信の宛先として指定し、マルチホップ通信を用いてメッセージを送信してもよい。マルチホップ通信の通信設定における転送方式は、ＧＡＣあるいはＧＢＣとすることができる。また、自車が交差点を曲がる前のＶ２Ｘ通信によりメッセージを送信すべき後続車両の位置が特定できる場合、転送方式をＧＵＣとしてもよい。

　図９では、交差点付近にも他車が存在する。交差点に存在している他車は自車との間に通信を遮蔽する構造物が存在しない。自車が送信したメッセージは、交差点に存在している他車により転送されて後続車両エリアに存在している他車へ送信される。

　マルチホップ通信が必要であるか否かを判定するために走行軌跡を用いることで、無線リソースの使用を抑制しつつ、通信の信頼性を向上できる。

　＜第４の実施形態＞
　制御部１１は、連携運転状態に基づいて、マルチホップ通信の必要性と、宛先と、マルチホップ通信の最大ホップ数と、の少なくとも１つを判定してもよい。制御部１１によりマルチホップ通信が必要であると判定された場合、通信部１５は、マルチホップ通信を用いてメッセージを送信してもよい。制御部１１によりマルチホップ通信が不要であると判定された場合、通信部１５は、シングルホップ通信を用いてメッセージを送信してもよい。

　隊列走行が有効であれば連携運転状態である。制御部１１は、隊列走行が有効であると判定された場合、すなわち連携運転状態であれば、制御部１１は、マルチホップ通信が必要であると判定してもよい。隊列走行中、隊列走行をしている車両は、隊列走行している車両の一部又は全部と隊列走行状態であるとの認識を伝え合うことがある。そこで、自車は、他車との通信により隊列走行状態であるか否かを認識できる。

　自車が隊列走行中、隊列に含まれる他車のうち自車から相対的に近い他車が電波遮蔽物になり、自車から相対的に遠い他車には、シングルホップ通信では自車からメッセージを送信できない可能性もある。そこで、制御部１１は、自車が隊列走行中であると判定した場合、自車から送信するメッセージはマルチホップ通信が必要であると判定してもよい。

　制御部１１は、連携運転状態である場合、連携運転の情報に基づいて、マルチホップ通信の宛先を決定してもよい。たとえば、制御部１１は、自車を含んでいる隊列の先頭車両あるいは後端車両の位置をマルチホップ通信の宛先とし、転送方式をＧＵＣとするマルチホップ通信にてメッセージを送信してもよい。

　この実施形態によれば、マルチホップ通信が必要であるか否かを判定するために車両の連携運転状態を用いることで、無線リソースの使用を抑制しつつ、通信の信頼性を向上できる。

　＜第５の実施形態＞
　制御部１１は、周辺環境情報に基づいて、マルチホップ通信の必要性と、宛先と、マルチホップ通信の最大ホップ数と、の少なくとも１つを判定してもよい。周辺環境情報は、前述のように、車両１０の周辺の環境である。環境には、道路の形状、障害物の位置及び大きさ、交通信号機の状態が含まれていてもよい。

　例えば、制御部１１は、センサ１２に基づいて、自車の前方の道路形状を取得し、その道路形状に基づいて、自車の前方に交差点が存在するか否かを判定してもよい。自車の前方に交差点が存在すると判定された場合、制御部１１は、マルチホップ通信が必要であると判定してもよい。

　制御部１１は、第１の実施形態における地図情報の代わりに、センサ１２の検出結果を用いてもよい。たとえば、地図情報から前方道路形状を認識する代わりに、センサ１２の検出結果から前方道路形状を認識してもよい。また、地図情報から前方交差点周辺にある建物の有無及びその建物の範囲を認識する代わりに、センサ１２の検出結果から前方交差点周辺にある建物の有無及びその建物の範囲を認識してもよい。

　また、制御部１１は、地図情報とセンサ１２の検出結果との組み合わせを用いてもよい。また、Ｖ２Ｘ通信で受信した自車以外のセンサの検出結果を用いてもよいし、Ｖ２Ｘ通信で受信した自車以外のセンサの検出結果と、センサ１２の検出結果の組み合わせを用いてもよい。

　センサ１２と地図情報の組み合わせの一例として、交通信号状態の取得にはセンサ１２の検出結果を使う例が考えられる。制御部１１は、交差点の存在を地図情報から認識する。制御部１１は、センサ１２に基づいて、自車の前方の交通信号状態を取得し、その交通信号状態に基づいて、交通信号機の灯色が通行可能を示す色であるか否かを判定してもよい。交通信号機の灯色が通行可能を示す色であると判定された場合、制御部１１は、マルチホップ通信が必要であると判定してもよい。制御部１１は、第２の実施形態におけるＶ２Ｘ通信の受信結果（例えば、ＲＳＵ２０からの交通信号状態）の代わりに、センサ１２の検出結果を用いてもよいし、Ｖ２Ｘ通信の受信結果と、センサ１２の検出結果と、の組み合わせを用いてもよい。

　例えば、制御部１１は、センサ１２の検出結果に基づいて、自車の先行車の位置を逐次取得し、センサ１２の検出結果からその先行車をロストしたと判定した場合、マルチホップ通信が必要であると判定してもよい。ロストは、見失った、あるいは、検出できなかったと言い換えてもよい。先行車は、自車の前方を走行する車両において自車に最も近い車両でもよい。ただし、先行車は、自車の前方において自車との距離が先行車判定距離以下である車両でもよい。先行車判定距離は、シングルホップ通信の通信距離あるいはそれ以下に設定されてもよい。

　制御部１１は、先行車をロストしたことによりマルチホップ通信が必要であると判定した場合、先行車をロストした位置を含み、先行車が進行したと推定できる方向に延びるエリアを宛先とするマルチホップ通信を実行してもよい。先行車が進行したと推定できる方向は、先行車がロストする直前の移動方向から決定できる。

　マルチホップ通信の宛先とするエリアを、先行車が進行したと推定できる方向に延びるエリアとすることで、先行車の右折又は左折によってその先行車をロストした場合であっても、無線リソースの使用を抑制しつつ、通信の信頼性を向上できる。

　＜第６の実施形態＞
　これまでの実施形態では、メッセージを送信する自車が、マルチホップ通信が必要であると判定し、マルチホップ通信であることを示す情報を含めてメッセージを送信していた。これに対して、第６の実施形態では、メッセージを受信する側が、受信したメッセージを転送するか否かを判定する。

　この判定は、車両１０に搭載された制御部１１が実行してもよいし、ＲＳＵ２０が備える制御部２１が実行してもよい。制御部１１が判定を実行する場合、制御部１１は通信部１５を制御する。制御部２１が判定を実行する場合、制御部２１は通信部２５を制御する。以下の説明において、制御部１１は制御部２１と読み替えることができる。制御部１１を制御部２と読み替える場合、通信部１５は通信部２５と読み替える。

　第６の実施形態は、制御部１１が図５に示す処理を実行する場合について説明する。制御部１１は、通信部１５によって受信されたメッセージを取得した場合、状態情報に基づいてマルチホップ通信の必要性を判定する。本実施形態では、マルチホップ通信の必要性は、メッセージ転送の必要性ということもできる。

　状態情報として以下を例示できる。すなわち、状態情報には、地図情報、自車位置情報、Ｖ２Ｘ通信状態、自車状態、走行軌跡、連携運転状態、周辺環境情報、道路情報から１つ以上を含んでいてもよい。

　制御部１１は、マルチホップ通信が必要であると判定した場合、状態情報に基づいて通信設定を決定してもよい。通信設定は、たとえば、宛先と、マルチホップ通信の最大ホップ数との少なくとも１つである。

　制御部１１によりマルチホップ通信が必要であると判定された場合、通信部１５は、マルチホップ通信を用いてそのメッセージを転送してもよい。制御部１１によりマルチホップ通信が不要であると判定された場合、通信部１５は、そのメッセージを転送しなくてもよい。

　受信メッセージはシングルホップ通信であったけれども、制御部１１は、そのメッセージの転送が必要であると判定した場合、そのメッセージをマルチホップ通信へ変更し、通信部１５は、そのメッセージを転送してもよい。受信メッセージがマルチホップ通信であっても、制御部１１がそのメッセージの転送が不要であると判定した場合、通信部１５は、そのメッセージを転送しなくてもよい。たとえば、自車位置が宛先になっている、あるいは、自車が宛先エリアにいる場合に、制御部１１は、受信したメッセージを転送不要と判定してよい。

　メッセージには送信元の位置が含まれていることがあるので、制御部１１は、受信メッセージに基づいて、送信元の位置を取得してもよい。メッセージの送信元は、たとえば、他車あるいはＲＳＵ２０である。受信メッセージの送信元の位置を取得できると、その受信メッセージの転送要否を判定しやすい。たとえば、送信元に対する交差路上にメッセージが届く必要があるが、交差路上ではそのメッセージが受信されることが困難である場合に、制御部１１は、受信メッセージを転送する必要があると判定する。たとえば、交差点の周辺に構造物がある場合、又は、送信元に対する交差路上において送信元からの見通し外となるエリアがある場合は、交差路上ではメッセージが受信されることが困難である。そのエリアにメッセージが届く必要がある場合には、制御部１１は、受信メッセージを転送する必要があると判定する。上記エリアにメッセージを必要とする送信先が存在する場合、上記エリアにメッセージが届く必要があることになる。

　送信元車両が交差路上の車両に接近する可能性が高い場合も、制御部１１は、受信メッセージを転送する必要があると判定してよい。送信元車両が交差路上の車両に接近する可能性は、第２の実施形態で説明した他車が自車へ接近する可能性と同じ意味であってよい。制御部１１は、送信元及び送信先が見通し外となる場合、そのメッセージの転送が必要であると判定してもよい。

　制御部１１は、そのメッセージの転送が必要であると判定した場合、状態情報に基づいて、マルチホップ通信の宛先すなわち送信先を決定してもよい。制御部１１は、送信元に対する交差路上であってそのメッセージが受信されることが困難であるエリアを宛先に決定してもよい。また、制御部１１は、送信元に対する交差路上であって送信元からの見通し外となるエリアを宛先に決定してもよい。また、制御部１１は、そのメッセージを必要とする車両が存在するエリアを宛先に決定してもよい。

　図１０を用いて、自車がメッセージを転送する具体例を説明する。図１０の例において、自車は、走行路上の送信元車両からシングルホップ通信のメッセージを受信する。自車は、そのメッセージの転送が必要であると判定した場合、送信元車両の走行路に対する交差路上の内のそのメッセージが受信されることが困難であるエリアを推定してもよい。その後、自車は、マルチホップ通信の宛先として推定エリアを指定し、マルチホップ通信を用いてそのメッセージを転送してもよい。

　自車は、受信メッセージに含まれる情報に基づいて、自車が走行する道路と交差する交差路上でも受信メッセージが受信される必要があるか否かを判定する。受信メッセージがＳＨＢで送信されている場合、送信元車両の位置とＳＨＢの通信範囲とから、受信メッセージが受信される必要がある範囲を決定できる。決定した範囲に交差路が含まれている場合に、自車は、交差路上でも受信メッセージが受信される必要があると判定してよい。

　図１０の例では、交差点周囲には、送信元車両がＳＨＢで送信するメッセージの受信を困難にする構造物が存在する。自車は、この構造物が存在することを、地図情報あるいは自車が構造物付近を通過した際のセンサ検出結果から認識できる。したがって、自車は、受信メッセージを転送する必要があると判定する。

　転送するメッセージの宛先を図１０に破線枠で例示している。宛先とするエリアは、交差路上を交差点に向かって走行する車両の位置が、送信元車両と同時期に交差点に進入する可能性がある位置となるエリアである。自車は、受信メッセージから、送信元車両の位置と速度と交差点の位置とを認識しているので、送信元車両が交差点に進入するまでに要する所要時間を予測できる。交差路上を走行する車両の速度範囲も、制限速度等に基づいて事前に予測できる。この速度範囲と、上述の所要時間から、宛先とするエリアの大きさを決定できる。自車は、交差路上を走行する車両の速度を、車車間通信、センサなどにより取得できることもある。速度を取得できた場合には、事前に予測した速度範囲に代えて、取得した速度を基準とし加減速により速度が変化する速度変化範囲を用いてもよい。

　自車は、このようにして決定した宛先を含めて受信メッセージを転送する。自車は、メッセージの転送が必要である場合に限りメッセージを転送するので、無線リソースの使用を抑制しつつ、通信の信頼性を向上できる。

　また、宛先を、送信元車両が走行する道路に交差する交差路上のエリアとしている。転送が不要なエリアを宛先としていない点でも、無線リソースの使用を抑制できる。

　次に、ＲＳＵ２０がメッセージを転送する具体例を説明する。例えば、見通しの悪い交差点に設置されたＲＳＵ２０において、通信部２５が、送信元車両からシングルホップ通信のメッセージを受信した場合、制御部２１は、そのメッセージをマルチホップ通信へ変更し、送信元車両に対する交差路上の宛先位置を指定してもよい。

　図１１の例において、ＲＳＵ２０は、見通しの悪い交差点に設置されている。すなわち、ＲＳＵ２０が面している道路に位置する車両と、その道路に交差する交差路に位置する車両との通信には、交差点周囲にある構造物により見通し外のエリアがある。送信元車両は、図１１に示す位置において、交差路上に見通し外エリアが存在する。

　この例において、ＲＳＵ２０は、送信元車両からシングルホップ通信のメッセージを受信する。ＳＨＢでは通信が困難になる環境が周囲に存在するＲＳＵ２０など、ＲＳＵ２０が設置されている環境に基づいて、ＲＳＵ２０は、すべての受信メッセージを転送する設定になっていてもよい。

　また、ＲＳＵ２０は、受信メッセージが受信されるべきエリアに受信が困難なエリアがあるか否かを判定し、受信が困難になるエリアがある場合に、受信メッセージを転送すると判定してもよい。受信が困難になるエリアの有無は、受信メッセージに含まれる送信元車両の位置と、ＲＳＵ２０が取得あるいは記憶する地図情報とをもとにして判定してもよい。たとえば、図１１に示す例では、送信元車両が送信するメッセージは、構造物により、送信元車両が走行する道路と交差する交差路上に受信が困難になるエリアが存在する。一方、図１１に示す例では、交差点において図１１における上側には構造物は存在しない。そのため、送信元車両の位置が交差点において図１１における上側であれば、ＲＳＵ２０は受信メッセージを転送すると判定しなくてもよい。

　ＲＳＵ２０は、受信したメッセージの転送が必要であると判定した場合、そのメッセージが受信されることが困難であるエリアを推定してもよい。メッセージが受信されることが困難であるエリアは、送信元車両の走行路に対する交差路上であって、事前に設定されたエリアでもよい。構造物の位置は事前に取得できる。送信元車両がどの範囲であれば、構造物により交差路上に受信が困難になるエリアが生じるか、及び、そのエリアの大きさは算出できる。ＲＳＵ２０は、送信元車両の位置を変化させつつ算出したエリアを全部含む固定エリアを受信が困難であるエリアとしてもよい。あるいは、ＲＳＵ２０は、受信メッセージに含まれる送信元車両の位置と地図情報から、都度、受信が困難であるエリアを算出してもよい。ＲＳＵ２０は、マルチホップ通信の宛先として受信が困難になるエリアを指定し、マルチホップ通信を用いてそのメッセージを転送してもよい。

　さらに、制御部１１あるいは制御部２１（以下、単に制御部１１）は、渋滞を検出した場合に、ＳＨＢで受信したメッセージをマルチホップ通信によって転送すると判定してもよい。渋滞があると、渋滞最後尾に連結する車両の速度が急に低下することがあるので、急ブレーキを検出した場合と同様、後続車は注意が必要である。そこで、制御部１１は、渋滞を検出した場合に、メッセージをマルチホップ通信とする。制御部１１は、渋滞を検出したことに加えて、渋滞が生じている位置の道路形状を考慮してマルチホップ通信とするか否かを判定してもよい。たとえば、制御部１１は、渋滞を検出したことに加えて、渋滞の最後尾の位置が、交差点の出口付近、あるいは、急カーブの途中あるいは出口付近である場合に、メッセージを転送すると判定してもよい。急カーブであるか否かは、たとえば、事前に設定した閾値と道路が曲がっている程度とを比較して決定してよい。制御部１１は、渋滞を検出したことに基づいてマルチホップ通信とする場合、渋滞へ向かう道路上のエリアを宛先としてもよい。

　急カーブを走行している場合、交差点付近を走行している場合と同様、運転に注意が必要である。そこで、自車が急カーブを走行している場合、制御部１１は、渋滞の検出によらず、メッセージをマルチホップ通信すると決定してもよい。

　例えば、制御部１１は、Ｖ２Ｘ通信に基づいて輻輳状態を検出してもよい。通信部１５がマルチホップ通信のメッセージを受信し、且つ、輻輳状態が検出された場合、制御部１１はマルチホップ通信における転送を中止してもよい。また、制御部１１は、輻輳状態が検出された場合、これまでの説明において示した条件などによればマルチホップ通信すると決定できるとしても、そのメッセージをシングルホップ通信としてもよい。シングルホップ通信とすることは、マルチホップ通信をシングルホップ通信へ変更することを意味していてもよい。通信部１５がシングルホップ通信のメッセージを受信し、且つ、輻輳状態が検出された場合、制御部１１は、これまでの説明において示した条件などによればマルチホップ通信に変更してメッセージを転送すると決定できるとしても、マルチホップ通信が不要であると判定してもよい。

　（付記）
　本開示の一実施形態に関して、以下を付記する。

　［付記１］
　メッセージの送信にマルチホップ通信が必要であるか否かを判定する制御部と、
　マルチホップ通信が必要であると判定された場合、マルチホップ通信を用いてメッセージを送信する通信部と、を含むメッセージ制御装置。
　［付記２］
　制御部は、シングルホップ通信によるメッセージの通信エリアの少なくとも一部に、電波障害物によりシングルホップ通信が困難であるエリアがあるか否かに基づいて、メッセージの送信にマルチホップ通信が必要であるか否かを判定する、付記１に記載のメッセージ制御装置。
　［付記３］
　メッセージ制御装置は車両で用いられており、
　制御部は、車両の周辺の道路構造に基づいて、メッセージの送信にマルチホップ通信が必要であるか否かを判定する、付記１に記載のメッセージ制御装置。
　［付記４］
　制御部は、車両が、所定距離内の前方に交差点がある位置を走行中であるか否かに基づいて、メッセージの送信にマルチホップ通信が必要であるか否かを判定する、付記３に記載のメッセージ制御装置。
　［付記５］
　制御部は、交差点において車両が走行する道路と交差する交差路と、車両との間に電波障害物が存在することに基づいて、メッセージの送信にマルチホップ通信が必要であると判定する、付記４に記載のメッセージ制御装置。
　［付記６］
　制御部は、車両が、所定距離内の前方に交差点がある位置を走行中である場合、交差点において車両が走行する道路と交差する交差路と、車両との間に電波障害物が存在するかどうかによらず、メッセージの送信にマルチホップ通信が必要であると判定する、付記４に記載のメッセージ制御装置。
　［付記７］
　制御部は、車両が所定距離内の前方に交差点がある位置を走行中であるか否か、及び、交差点に信号機があるか否かに基づいて、メッセージの送信にマルチホップ通信が必要であるか否かを判定する、付記４に記載のメッセージ制御装置。
　［付記８］
　制御部は、信号機の灯色が、車両が交差点へ進入することを許可する灯色であることに基づいて、メッセージの送信にマルチホップ通信が必要であると判定する、付記７に記載のメッセージ制御装置。
　［付記９］
　制御部は、車両が、急カーブを走行中であるか否かに基づいて、メッセージの送信にマルチホップ通信が必要であるか否かを判定する、付記３に記載のメッセージ制御装置。
　［付記１０］
　制御部は、通信相手から送信される信号の受信状況に基づいて、メッセージの送信にマルチホップ通信が必要であるか否かを判定する、付記１に記載のメッセージ制御装置。
　［付記１１］
　制御部は、マルチホップ通信を要求する信号を受信したか否かに基づいて、メッセージの送信にマルチホップ通信が必要であるか否かを判定する、付記１に記載のメッセージ制御装置。
　［付記１２］
　制御部によりマルチホップ通信が必要であると判定された場合、通信部は、電波障害物によりシングルホップ通信が困難であるエリアを含む宛先エリアにメッセージを送信する、付記２に記載のメッセージ制御装置。
　［付記１３］
　制御部によりマルチホップ通信が必要であると判定された場合、通信部は、宛先の少なくとも一部が、交差点において車両が走行する道路と交差する交差路を含むエリアにメッセージを送信する、付記４に記載のメッセージ制御装置。
　［付記１４］
　宛先とするエリアの形状が交差路に沿った長方形である、付記１３に記載のメッセージ制御装置。
　［付記１５］
　メッセージの送信にマルチホップ通信が必要であるか否かを判定することと、
　マルチホップ通信が必要であると判定された場合、マルチホップ通信を用いてメッセージを送信することと、を含むメッセージ制御方法。

　（ハードウェア構成）
　図１２は、一実施形態に係る車両１０の一例を示す図である。車両１０は、制御部１１、センサ１２、ロケータ１３、入力／出力部１４、通信部１５を備える。本例が示すブロック図は、機能単位のブロックを示している。これらの機能ブロック（構成部）はそれぞれ、ハードウェア及びソフトウェアの少なくとも一方の任意の組み合わせによって実現される。なお、上述の実施形態において説明した「車両」は、車両１０の中のいずれか又は複数の機能ブロック（例えば、制御部１１、通信部１５）と互いに読み替えられてもよい。

　図１２には本開示の説明に必要な部分のみが示されている。車両１０は、運転のために必要な部分、例えば、駆動部及び操作部を含む。駆動部は、例えば、エンジン及びモータの一方又は両方である。操作部は、例えば、ステアリングホイールである。

　制御部１１は、マイクロプロセッサ（以下、単にプロセッサ）１１１、メモリ１１２、通信インターフェース１１３で構成される。通信インターフェース１１３は、例えば、入出力（Input/Output（ＩＯ））ポートである。制御部１１は、電子制御ユニット（Electronic Control Unit（ＥＣＵ））と呼ばれてもよいし、周辺装置とのインターフェース、制御装置、演算装置、レジスタなどを含む中央処理装置（Central Processing Unit（ＣＰＵ））によって構成されてもよい。

　制御部１１は、マイクロプロセッサ、デジタル信号プロセッサ（Digital Signal Processor（ＤＳＰ））、Application Specific Integrated Circuit（ＡＳＩＣ）、Programmable Logic Device（ＰＬＤ）、Field Programmable Gate Array（ＦＰＧＡ）などのハードウェアを含んで構成されてもよく、当該ハードウェアを用いて上記プロセッサ１１１の処理が実現されてもよい。例えば、プロセッサ１１１は、これらのハードウェアの少なくとも１つを用いて実装されてもよい。

　車両１０などにおける各機能（例えば、メッセージの生成、センサ１２からの情報に基づく処理）は、例えば、プロセッサ１１１、メモリ１１２などのハードウェア上に所定のソフトウェア（プログラム）を読み込ませることによって、プロセッサ１１１が演算を行い、通信部１５を介する通信を制御したり、メモリ１１２におけるデータの読み出し及び書き込みの少なくとも一方を制御したりすることによって実現されてもよい。

　プロセッサ１１１は、例えば、オペレーティングシステムを動作させて車載のコンピュータ全体を制御してもよい。また、プロセッサ１１１は、プログラム、ソフトウェアモジュール、データなどをメモリ１１２に読み出し、これらに従って各種の処理を実行してもよい。当該プログラムは、上述の実施形態において説明した動作の少なくとも一部をコンピュータに実行させるためのプログラムであってもよい。プログラムはプログラムコードと読み替えてもよい。

　メモリ１１２は、コンピュータ読み取り可能な記録媒体であり、例えば、Read Only Memory（ＲＯＭ）、Erasable Programmable ROM（ＥＰＲＯＭ）、Electrically EPROM、Random Access Memory（ＲＡＭ）、その他の適切な記憶媒体の少なくとも１つによって構成されてもよい。メモリ１１２は、レジスタ、キャッシュ、メインメモリ（主記憶装置）などと呼ばれてもよい。メモリ１１２は、本開示の一実施形態に係る方法を実施するために実行可能なプログラム、ソフトウェアモジュールなどを保存することができる。

　なお、制御部１１には、メモリ１１２より大容量のコンピュータ読み取り可能な記録媒体であるストレージ（補助記憶装置）が含まれてもよい。制御部１１は、メモリ１１２において読み書きするデータを当該ストレージとの間で読み書きしてもよい。ストレージについては制御部１１が備えることに限定されず、制御部１１とは独立しており、通信線で制御部１１と接続されていてもよい。

　通信インターフェース１１３は、入出力ポートと呼ばれてもよく、制御部１１と他のブロックとの情報のやり取りに用いられてもよい。他のブロックは、例えば運転のために用いられるブロックである。制御部１１は、通信インターフェース１１３を介して、センサ１２からの信号を取得してもよい。

　制御部１１は、慣性航法装置（Inertial Navigation System（ＩＮＳ））、人工知能（Artificial Intelligence（ＡＩ））チップ、ＡＩプロセッサ、ＡＩ機能などに基づいて、運転支援機能、自動運転機能などを提供してもよい。

　センサ１２は、例えば、電流センサ、車輪の回転数センサ、タイヤの空気圧センサ、車両の速度センサ、加速度センサ、角速度センサ、物体検知センサなどを含んでもよい。各センサは、それぞれ計測によって得られた信号（オンオフ信号、アナログ信号、デジタル信号など）を、通信インターフェース１１３を介して制御部１１に与えてもよい。例えば、物体検知センサは、障害物、車両、歩行者などの物標を検出すると検出信号を生成してもよい。

　なお、センサ１２は、車両１０の周辺環境の情報を提供できるデバイスを含んでもよく、例えば、ミリ波レーダ、Light Detection and Ranging（ＬｉＤＡＲ）、カメラ、ジャイロシステム（例えば、慣性計測装置（Inertial Measurement Unit（ＩＭＵ）））などを含んでもよい。センサ１２は車両１０に複数搭載されていてもよく、同一種別のセンサ１２が車両に複数搭載されてもよい。たとえば、センサ１２としてのカメラが、車両１０前方、後方及び両側方に搭載されてもよい。

　ロケータ１３は、車両１０の位置情報を取得する。ロケータ１３は、測位システム（例えば、衛星測位システム（Global Navigation Satellite System（ＧＮＳＳ）、Global Positioning System（ＧＰＳ）など））、地図情報（例えば、高精細（High Definition（ＨＤ））マップ、自動運転車（Autonomous Vehicle（ＡＶ））マップなど）、上述のセンサ１２から得られる速度、加速度、角速度などに基づいて、上記位置情報を取得してもよい。

　入力／出力部１４は、外部からの入力を受け付ける入力デバイス、外部への出力を実施する出力デバイスを含む。入力デバイスは、例えば、キーボード、マウス、マイクロフォン、スイッチ、ボタン、センサである。出力デバイスは、例えば、ディスプレイ、スピーカー、Light Emitting Diode（ＬＥＤ）ランプである。入力デバイス及び出力デバイスは、一体となった構成（例えば、タッチパネル）であってもよい。

　入力／出力部１４は、カーナビゲーションシステム、オーディオシステム、テレビ、ラジオなどといった、運転情報などの各種情報を提供するための各種機器と、これらの機器を制御する１つ以上のＥＣＵとから構成されてもよい。入力／出力部１４は。外部装置（例えば、ＩＴＳサーバ３０）から通信部１５を介して取得した情報を利用して、車両１０の乗員に各種情報／サービスを提供してもよい。

　入力／出力部１４は、ユーザからの操作により入力を受け付けてもよいし、所定の機器、記憶媒体などと接続されてデータの入力を受け付けてもよい。入力／出力部１４は、入力結果を例えば制御部１１に出力してもよい。

　入力／出力部１４は、ユーザに対して知覚できる形式でデータ、コンテンツなどの出力を行ってもよい。

　通信部１５は、無線を介して外部装置（例えば、他の車両１０、ＩＴＳサーバ３０など）との通信を行うためのハードウェアであり、例えば、送受信デバイス、ネットワークデバイス、ネットワークコントローラ、ネットワークカード、通信モジュールなどともいう。通信部１５は、高周波スイッチ、デュプレクサ、フィルタ、アンプ、周波数シンセサイザ、アンテナなどを含んで構成されてもよい。通信部１５は、本開示に係る技術分野での共通認識に基づいて説明されるトランスミッター、レシーバー、送受信回路又は送受信装置により構成することができる。

　通信部１５は、例えば、Long Term Evolution（ＬＴＥ）、LTE-Advanced（ＬＴＥ－Ａ）、LTE-Beyond（ＬＴＥ－Ｂ）、ＳＵＰＥＲ３Ｇ、ＩＭＴ－Ａｄｖａｎｃｅｄ、4th generation mobile communication system（４Ｇ）、5th generation mobile communication system（５Ｇ）、6th generation mobile communication system（６Ｇ）、xth generation mobile communication system（ｘＧ（ｘは、例えば整数、小数））、Future Radio Access（ＦＲＡ）、Ｎｅｗ－Radio Access Technology（ＲＡＴ）、New Radio（ＮＲ）、New radio access（ＮＸ）、Future generation radio access（ＦＸ）、Global System for Mobile communications（ＧＳＭ（登録商標））、ＣＤＭＡ２０００、Ultra Mobile Broadband（ＵＭＢ）、ＩＥＥＥ８０２．１１（Ｗｉ－Ｆｉ（登録商標））、ＩＥＥＥ８０２．１６（ＷｉＭＡＸ（登録商標））、ＩＥＥＥ８０２．２０、Ultra-WideBand（ＵＷＢ）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、その他の無線通信方式、又はこれらに基づいて拡張、修正、作成又は規定された無線通信方式を用いて通信を行ってもよい。

　通信部１５は、制御部１１のプロセッサ１１１によって制御可能であってもよい、通信部１５は、制御部１１に含まれてもよい。

　通信部１５は、センサ１２からの信号、当該信号に基づいて得られる情報、入力／出力部１４からの入力に基づく情報などの少なくとも１つを、無線通信を介して外部装置へ送信してもよい。

　通信部１５は、外部装置から受信した種々の情報（交通情報、信号情報、車間情報など）を受信し、制御部１１に提供してもよい。これらの情報は、入力／出力部１４を介して出力されてもよい。制御部１１は、これらの情報に基づいて制御を行ってもよい。

　なお、各機能ブロックの実現方法は特に限定されない。すなわち、各機能ブロックは、物理的又は論理的に結合した１つの装置を用いて実現されてもよいし、物理的又は論理的に分離した２つ以上の装置を直接的又は間接的に（例えば、有線、無線などを用いて）接続し、これら複数の装置を用いて実現されてもよい。機能ブロックは、上記１つの装置又は上記複数の装置にソフトウェアを組み合わせて実現されてもよい。

　例えば、プロセッサ１１１は１つだけ図示されているが、複数のプロセッサがあってもよい。また、処理は、１のプロセッサによって実行されてもよいし、処理が同時に、逐次に、又はその他の手法を用いて、２以上のプロセッサによって実行されてもよい。なお、プロセッサ１１１は、１以上のチップによって実装されてもよい。

　各機能ブロックのハードウェアは、情報を通信するためのバスによって接続されてもよい。バスは、単一のバスを用いて構成されてもよいし、装置間ごとに異なるバスを用いて構成されてもよい。バスは、有線又は無線によって実現されてもよい。

　なお、ＲＳＵ２０、ＩＴＳサーバ３０なども、車両１０と同様の構成を有してもよい。当業者であれば、車両１０関連の記載を、適宜読み替えて理解できる。

　なお、車両１０のうち、制御部１１を含む構成又は制御部１１と通信部１５を含む構成は、メッセージ制御装置と呼ばれてもよい。

　図１３は、一実施形態に係るＲＳＵの一例を示す図である。ＲＳＵ２０は、制御部２１、通信部２５を備える。制御部２１は、マイクロプロセッサ（以下、単にプロセッサ）２１１、メモリ２１２、通信インターフェース２１３を含んでもよい。

　制御部２１は、制御部１１と同様の機能を有してもよい。通信部２５は、通信部１５と同様の機能を有してもよい。プロセッサ２１１、メモリ２１２、通信インターフェース２１３はそれぞれ、プロセッサ１１１、メモリ１１２、通信インターフェース１１３と同様であってもよい。

　なお、ＲＳＵ２０のうち、制御部２１を含む構成又は制御部２１と通信部２５を含む構成は、メッセージ制御装置と呼ばれてもよい。

　メッセージ制御装置は、前述のメッセージ制御方法を実行してもよい。

　（変形例）
　なお、本開示において説明した用語及び本開示の理解に必要な用語については、同一の又は類似する意味を有する用語と置き換えてもよい。

　本開示において、装置、回路、デバイス、部（section）、ユニットなどの文言は、互いに読み替えることができる。

　本開示の車両は、任意の移動体（moving object）で読み替えられてもよい。移動体は、例えば、車両、輸送車両、自動車、自動二輪車、自転車、コネクテッドカー、ショベルカー、ブルドーザー、ホイールローダー、ダンプトラック、フォークリフト、列車、バス、リヤカー、人力車、船舶（ship and other watercraft）、飛行機、ロケット、人工衛星、ドローン、マルチコプター、クアッドコプター、気球及びこれらに搭載される物を含み、またこれらに限られない。

　移動体は、運行指令に基づいて自律走行する移動体であってもよい。移動体は、人が搭乗して動く移動体、換言すれば乗り物（例えば、車、飛行機など）であってもよいし、無人で動く移動体（例えば、ドローン、自動運転車など）であってもよい。移動体はロボットであってもよい。ロボットは有人型でも無人型でもよい。

　本開示において説明した情報、パラメータなどは、絶対値を用いて表されてもよいし、所定の値からの相対値を用いて表されてもよいし、対応する別の情報を用いて表されてもよい。例えば、無線リソースは、所定のインデックスによって指示されてもよい。

　本開示においてパラメータなどに使用する名称は、いかなる点においても限定的な名称ではない。さらに、これらのパラメータを使用する数式などは、本開示において明示的に開示したものと異なってもよい。

　本開示において説明した情報、信号などは、様々な異なる技術のいずれかを使用して表されてもよい。例えば、上記の説明全体に渡って言及され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、チップなどは、電圧、電流、電磁波、磁界若しくは磁性粒子、光場若しくは光子、又はこれらの任意の組み合わせによって表されてもよい。

　入出力された情報、信号などは、特定の場所（例えば、メモリ）に保存されてもよいし、管理テーブルを用いて管理してもよい。入出力される情報、信号などは、上書き、更新又は追記をされ得る。出力された情報、信号などは、削除されてもよい。入力された情報、信号などは、他の装置へ送信されてもよい。

　情報の通知は、本開示において説明した態様／実施形態に限られず、他の方法を用いて行われてもよい。

　また、所定の情報の通知（例えば、「Ｘであること」の通知）は、明示的な通知に限られず、暗示的に（例えば、当該所定の情報の通知を行わないことによって又は別の情報の通知によって）行われてもよい。

　ソフトウェアは、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語と呼ばれるか、他の名称で呼ばれるかを問わず、命令、命令セット、コード、コードセグメント、プログラムコード、プログラム、サブプログラム、ソフトウェアモジュール、アプリケーション、ソフトウェアアプリケーション、ソフトウェアパッケージ、ルーチン、サブルーチン、オブジェクト、実行可能ファイル、実行スレッド、手順、機能などを意味するよう広く解釈されるべきである。

　また、ソフトウェア、命令、情報などは、伝送媒体を介して送受信されてもよい。例えば、ソフトウェアが、有線技術（同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者回線（Digital Subscriber Line（ＤＳＬ））など）及び無線技術（赤外線、マイクロ波など）の少なくとも一方を使用してウェブサイト、サーバ、又は他のリモートソースから送信される場合、これらの有線技術及び無線技術の少なくとも一方は、伝送媒体の定義内に含まれる。

　本開示において説明した各態様／実施形態は単独で用いてもよいし、組み合わせて用いてもよいし、実行に伴って切り替えて用いてもよい。また、本開示において説明した各態様／実施形態の処理手順、シーケンス、フローチャートなどは、矛盾の無い限り、順序を入れ替えてもよい。例えば、本開示において説明した方法については、例示的な順序を用いて様々なステップの要素を提示しており、提示した特定の順序に限定されない。

　本開示において使用する「に基づいて」という記載は、別段に明記されていない限り、「のみに基づいて」を意味しない。言い換えれば、「に基づいて」という記載は、「のみに基づいて」と「に少なくとも基づいて」の両方を意味する。

　本開示において使用する「第１の」、「第２の」などの呼称を使用した要素へのいかなる参照も、それらの要素の量又は順序を全般的に限定しない。これらの呼称は、２つ以上の要素間を区別する便利な方法として本開示において使用され得る。したがって、第１及び第２の要素の参照は、２つの要素のみが採用され得ること又は何らかの形で第１の要素が第２の要素に先行しなければならないことを意味しない。

　本開示において、「Ａ／Ｂ」及び「Ａ及びＢの少なくとも一方」は、互いに読み替えられてもよい。また、本開示において、「Ａ／Ｂ／Ｃ」は、「Ａ、Ｂ及びＣの少なくとも１つ」を意味してもよい。

　本開示において、「ＡとＢが異なる」という用語は、「ＡとＢが互いに異なる」ことを意味してもよい。なお、当該用語は、「ＡとＢがそれぞれＣと異なる」ことを意味してもよい。「離れる」、「結合される」などの用語も、「異なる」と同様に解釈されてもよい。

　本開示において、「含む（include）」、「含んでいる（including）」及びこれらの変形が使用されている場合、これらの用語は、用語「備える（comprising）」と同様に、包括的であることが意図される。さらに、本開示において使用されている用語「又は（or）」は、排他的論理和ではないことが意図される。

　本開示において、例えば、英語でのa, an及びtheのように、翻訳によって冠詞が追加された場合、本開示は、これらの冠詞の後に続く名詞が複数形であることを含んでもよい。

　本開示において、「以下」、「未満」、「以上」、「より多い」、「と等しい」などは、互いに読み替えられてもよい。また、本開示において、「良い」、「悪い」、「大きい」、「小さい」、「高い」、「低い」、「早い」、「遅い」、「広い」、「狭い」、などを意味する文言は、原級、比較級及び最上級に限らず互いに読み替えられてもよい。また、本開示において、「良い」、「悪い」、「大きい」、「小さい」、「高い」、「低い」、「早い」、「遅い」、「広い」、「狭い」などを意味する文言は、「ｉ番目に」（ｉは任意の整数）を付けた表現として、原級、比較級及び最上級に限らず互いに読み替えられてもよい（例えば、「最高」は「ｉ番目に最高」と互いに読み替えられてもよい）。

　本開示において、「の（of）」、「のための（for）」、「に関する（regarding）」、「に関係する（related to）」、「に関連付けられる（associated with）」などは、互いに読み替えられてもよい。

　以上、本開示の実施形態について詳細に説明したが、当業者にとっては、本開示に係る構成は本開示中に明示された実施形態に限定されないということは明らかである。本開示は、明示された記載に基づいて定まる技術的な思想及びその範囲を逸脱することなく修正及び変更態様として実施することができる。したがって、本開示の記載は、例示説明を目的とし、本開示に係る構成に対して何ら制限的な意味をもたらさない。

Claims

　メッセージの送信にマルチホップ通信が必要であるか否かを判定する制御部と、
　前記マルチホップ通信が必要であると判定された場合、前記マルチホップ通信を用いて前記メッセージを送信する通信部と、を含むメッセージ制御装置。
　前記制御部は、シングルホップ通信による前記メッセージの通信エリアの少なくとも一部に、電波障害物により前記シングルホップ通信が困難であるエリアがあるか否かに基づいて、前記メッセージの送信にマルチホップ通信が必要であるか否かを判定する、請求項１に記載のメッセージ制御装置。
　前記メッセージ制御装置は車両で用いられており、
　前記制御部は、前記車両の周辺の道路構造に基づいて、前記メッセージの送信にマルチホップ通信が必要であるか否かを判定する、請求項１に記載のメッセージ制御装置。
　前記制御部は、前記車両が、所定距離内の前方に交差点がある位置を走行中であるか否かに基づいて、前記メッセージの送信にマルチホップ通信が必要であるか否かを判定する、請求項３に記載のメッセージ制御装置。
　前記制御部は、前記交差点において前記車両が走行する道路と交差する交差路と、前記車両との間に電波障害物が存在することに基づいて、前記メッセージの送信にマルチホップ通信が必要であると判定する、請求項４に記載のメッセージ制御装置。
　前記制御部は、前記車両が、所定距離内の前方に交差点がある位置を走行中である場合、前記交差点において前記車両が走行する道路と交差する交差路と、前記車両との間に電波障害物が存在するかどうかによらず、前記メッセージの送信にマルチホップ通信が必要であると判定する、請求項４に記載のメッセージ制御装置。
　前記制御部は、前記車両が所定距離内の前方に交差点がある位置を走行中であるか否か、及び、前記交差点に信号機があるか否かに基づいて、前記メッセージの送信にマルチホップ通信が必要であるか否かを判定する、請求項４に記載のメッセージ制御装置。
　前記制御部は、前記信号機の灯色が、前記車両が前記交差点へ進入することを許可する灯色であることに基づいて、前記メッセージの送信にマルチホップ通信が必要であると判定する、請求項７に記載のメッセージ制御装置。
　前記制御部は、前記車両が、急カーブを走行中であるか否かに基づいて、前記メッセージの送信にマルチホップ通信が必要であるか否かを判定する、請求項３に記載のメッセージ制御装置。
　前記制御部は、通信相手から送信される信号の受信状況に基づいて、前記メッセージの送信にマルチホップ通信が必要であるか否かを判定する、請求項１に記載のメッセージ制御装置。
　前記制御部は、マルチホップ通信を要求する信号を受信したか否かに基づいて、前記メッセージの送信にマルチホップ通信が必要であるか否かを判定する、請求項１に記載のメッセージ制御装置。
　前記制御部により前記マルチホップ通信が必要であると判定された場合、前記通信部は、電波障害物により前記シングルホップ通信が困難であるエリアを含む宛先エリアに前記メッセージを送信する、請求項２に記載のメッセージ制御装置。
　前記制御部により前記マルチホップ通信が必要であると判定された場合、前記通信部は、宛先の少なくとも一部が、前記交差点において前記車両が走行する道路と交差する交差路を含むエリアに前記メッセージを送信する、請求項４に記載のメッセージ制御装置。
　宛先とするエリアの形状が前記交差路に沿った長方形である請求項１３に記載のメッセージ制御装置。
　メッセージの送信にマルチホップ通信が必要であるか否かを判定することと、
　前記マルチホップ通信が必要であると判定された場合、前記マルチホップ通信を用いて前記メッセージを送信することと、を含むメッセージ制御方法。