JP7537341B2 - 車両用通信システム、中継サーバ、車両用通信機 - Google Patents

Description

本開示は、車両で使用される通信機とサーバとのデータ通信を中継する技術に関する。

特許文献１には、他車両から車車間通信で取得した通信データを、他の車両からの要求に基づき、当該他車両の代わりに所定のサーバにアップロードする構成が開示されている。便宜上、他車両のデータ通信を当該他車両の代わりに行うことを代行通信と記載する。代行通信は、１つの側面において他車両とサーバとの通信を中継する行為と解することができる。

特許文献２には、ＰＤＣＰ（Packet Data Convergence Protocol）レイヤでのパケット量を観測することで、ユーザ装置ごとの通信量を管理する構成が開示されている。具体的には、ユーザ装置への送達確認が取れたＰＤＣＰ－ＳＤＵ（Service Data Unit）のデータ量の総和と、ユーザ装置から受信したＰＤＣＰ－ＳＤＵのデータ量の総和を元に通信量を管理（測定）する構成が開示されている。なお、各先行技術文献の記載内容は、本開示における技術的要素の説明として、参照により援用することができる。

特開２０２０－１６２０３１号公報 国際公開第２０１７／０２２３８８号

車両用通信システムにおいては、ユーザ装置としての各車両がどれくらいデータ通信を行ったのか、換言すれば、車両ごとの通信量を管理したいといった需要がある。一方、例えば特許文献１に開示されているように、任意の車両である第１車両が、第１車両にとっての他車両である第２車両とサーバとのデータ通信を代行可能な構成では、各車両の通信量が不明瞭となりうる。

具体的には、第１車両の通信量は、第２車両の通信を代行した分だけ増大する。また、第２車両の通信量は、第１車両に代行してもらった分だけ少なくなりうる。すなわち、代行通信を導入すると、車両ごとの実質的な通信量が不明瞭となってしまう。

本開示は、上記の検討又は着眼点に基づいて成されたものであり、その目的の１つは、車両ごとの通信量が不明瞭となる恐れを低減可能な車両用通信システム、中継サーバ、車両用通信機を提供することにある。

ここに開示される車両用通信システムは、セルラー基地局を介した無線通信であるセルラー通信と車車間通信とを実施可能に構成された、それぞれ異なる車両で使用される複数の通信機（１）と、通信機とアプリケーションサーバとのデータ通信を中継するとともに、通信機ごとのデータ通信量を管理する中継サーバ（５）と、を含み、
複数の通信機のそれぞれは、他の通信機である他機からの依頼に基づき、代行通信として、他機とアプリケーションサーバとのデータ通信を中継する代行処理部（Ｆ３５）を備え、代行通信を行う場合には、代行通信のためのポートとして、代行通信の依頼元としての他機または自機が、代行通信ではない通常の通信時には使用していないポートを用いてセルラー通信を実施することと、代行通信のためのポートの番号を中継サーバに通知することと、を実施し、中継サーバは、通信に使用されているポートの番号に基づいて、代行通信のデータ量を代行通信ではないデータ通信の量とは分けて管理するように構成されている。

上記のシステム構成によれば、代行通信時と通常の通信時とで、通信に使用されるポートが異なる。故に、中継サーバは、ポート番号をもとに通信機ごとの実質的な通信量を管理することが可能となる。なお、通常の通信とは、代行通信ではない通信、すなわち他機のためではなく自機のための通信を指す。

ここに開示される中継サーバは、車両で使用される通信機とアプリケーションサーバとのデータ通信を中継するとともに、通信機ごとのデータ通信量を管理する中継サーバであって、通信機が他の通信機である他機とアプリケーションサーバとのデータ通信を代行する場合には、通信機から代行通信のためのポートの番号を取得することと、データ通信に使用されているポートの番号に基づいて、代行通信のデータ量を代行通信ではないデータ通信の量とは分けて管理するように構成されている。

上記の中継サーバによれば、代行通信時と通常の通信時とで通信に使用されるポートが異なるため、当該ポート番号の違いに基づいて、通常の通信量と代行通信に伴う通信量とを区別することが可能となる。

ここに開示される車両用通信機は、セルラー基地局を介した無線通信であるセルラー通信と車車間通信とを実施可能に構成された車両用通信機であって、車両用通信機と任意の外部装置との通信は、車両用通信機の通信量を管理する機能を備えた所定の中継サーバを介して行われるように構成されており、他の車両用通信機である他機からの依頼に基づき、代行通信として、車車間通信とセルラー通信を併用して、他機と外部装置とのデータ通信を中継する代行処理部（Ｆ３５）を備え、代行処理部は、代行通信を行う場合には、代行通信のためのポートとして、代行通信の依頼元としての他機または自機が、代行通信ではない通常の通信時には使用していないポートを用いて外部装置と通信することと、代行通信のためのポートの番号を中継サーバに通知することと、を実施するように構成されている。

上記の車両用通信機は、通常の通信時と、代行通信時とで、ポート番号を異ならせるとともに、代行通信に用いるポート番号を中継サーバに通知する。当該構成によれば中継サーバは当該ポート番号の違いに基づいて、通常の通信量と代行通信に伴う通信量とを区別することが可能となる。

なお、特許請求の範囲に記載した括弧内の符号は、一つの態様として後述する実施形態に記載の具体的手段との対応関係を示すものであって、本開示の技術的範囲を限定するものではない。

車両用通信システムの全体像を示す図である。 中継サーバの構成を示すブロック図である。 車載通信機の構成を示すブロック図である。 車載通信機の機能を説明するためのブロック図である。 代行通信を利用しない場合の通信手順を説明するためのシーケンス図である。 代行通信を利用する場合の通信手順を説明するためのシーケンス図である。 代行通信を開始するための手続きを説明するためのシーケンス図である。 データ量の管理態様の一例を示す図である。 データ量の管理態様の一例を示す図である。

以下、本開示の実施形態について図を用いて説明する。図１は、本開示に係る車両用通信システム１００の概略的な構成の一例を示す図である。車両用通信システム１００は、例えばＬＴＥ（Long Term Evolution）に準拠した無線通信を提供する。実施形態で説明を省略している部分は、ＬＴＥの規格で定められている方法で行われるものとする。なお、車両用通信システム１００は、３Ｇ規格や、４Ｇ規格、５Ｇ規格などに準拠した無線通信を提供するものであってもよい。以降ではＬＴＥ、３Ｇ、４Ｇ、５ＧなどをまとめてＬＴＥ等とも記載する。以下の実施形態は、３ＧＰＰ（Third Generation Partnership Project）が規定する３Ｇや４Ｇ、５Ｇなどに準拠するように適宜変更して実施可能である。

＜全体構成＞
図１に示すように車両用通信システム１００は、車載通信機１、セルラー基地局２、コアネットワーク３、アプリサーバ４、及び中継サーバ５を含む。また、車両用通信システム１００は、任意の要素としてＷｉ－Ｆｉ（登録商標）規格に準拠した無線ＬＡＮ（Local Area Network）を提供するＷｉ－Ｆｉ基地局６を含みうる。なお、図１にはセルラー基地局２、Ｗｉ－Ｆｉ基地局６を１つずつしか示していないが、これらは複数存在しうる。

第１車両Ｖ１と第２車両Ｖ２は、以下に説明する車載通信機１を搭載した車両である。図１には車載通信機１を搭載した車両Ｖｃを、第１車両Ｖ１と第２車両Ｖ２の２台しか示していないが、システム全体としては３台以上存在しうる。便宜上、第１車両Ｖ１に搭載されている車載通信機１のことを第１通信機１Ａとも記載する。また、第２車両Ｖ２に搭載されている車載通信機１を第２通信機１Ｂとも記載する。第１通信機１Ａと第２通信機１Ｂは基本的には同じ構成とするが、必ずしも完全に同一仕様である必要はない。第１通信機１Ａと第２通信機１Ｂは、使用されているソフトウェアバージョン、ＯＳ、アンテナ数、契約している通信事業者、利用可能な通信回線の数、通信料金プランなどが異なっていても良い。

各車載通信機１は、以下の説明の通り、車両Ｖｃで使用される任意のアプリケーション（以降、アプリ８１）に対応するアプリサーバ４と、データ通信を実施する。アプリサーバ４が外部装置に相当する。車載通信機１が車両用通信機に相当する。

各車載通信機１は、セルラー回線を用いた無線通信であるセルラー通信と、車車間通信と、Ｗｉ－Ｆｉ通信と、をそれぞれ実施可能に構成されている。ここでのセルラー回線とは、セルラー基地局２を介した通信回線、換言すればＬＴＥ／４Ｇ／５Ｇ規格に準拠した通信回線を指す。また、車車間通信とは、車両同士の直接的な通信を指す。車車間通信の規格としては、ＩＥＥＥ８０２．１１ｐ規格に対応するＤＳＲＣ（Dedicated Short Range Communications）や、ＩＥＥＥ１６０９等にて開示されているＷＡＶＥ（Wireless Access in Vehicular Environment）規格等を採用することができる。車車間通信は、ＡＲＩＢ（Association of Radio Industries and Businesses）のＳＴＤ－Ｔ７５規格に準拠していても良い。車車間通信には、ＬＴＥ等の規格に準拠するセルラーＶ２Ｘを含めることができる。Ｗｉ－Ｆｉ通信とは、Ｗｉ－Ｆｉ基地局６を経由するデータ通信を指す。Ｗｉ－Ｆｉ通信は、Ｗｉ－Ｆｉ基地局６の通信エリア内に車両Ｖｃが存在する場合に実施可能となる。

なお、複数の車載通信機１の中には、それぞれＡＰＮ（Access Point Name）が異なる複数のセルラー回線を利用可能に構成されたものがあってもよい。ＡＰＮは、１つの側面において通信サービスの識別子である。ＡＰＮには、通信サービスを提供する通信事業者（いわゆるキャリア）が紐付いている。例えば第１通信機は１つのＡＰＮを利用可能に構成されており、第２通信機１Ｂは２つのＡＰＮを並列的に利用可能に構成されている。第１通信機１Ａが使用可能なＡＰＮは、第２通信機１Ｂが使用可能な２つのＡＰＮのいずれか一方と同一であってもよい。ＡＰＮが異なれば、仮に通信相手となるアプリサーバ４が同一であっても、当該アプリサーバ４までデータが流れる経路は、実体的、又は、仮想的に相違する。複数のセルラー回線は、それぞれ異なる通信経路を実現する。

セルラー基地局２は、車載通信機１とＬＴＥ等の規格に準拠した無線信号を送受信する設備である。セルラー基地局２は、ｅＮＢ（evolved NodeB）とも称される。セルラー基地局２は、５Ｇで使用されるｇＮＢ（next generation NodeB）であってもよい。

セルラー基地局２は、ＩＰ（Internet Protocol）ネットワーク等のアクセス回線を介してコアネットワーク３と接続されている。セルラー基地局２は、車載通信機１とコアネットワーク３との間でトラフィックを中継する。セルラー基地局２は、例えば車載通信機１からの要求に基づいて送信機会の割り当てなどを実施する。送信機会は、データ送信に使用可能な周波数帯や時間、変調方式などによって構成される。

セルラー基地局２は、各種参照信号（ＲＳ：Reference Signal）を随時送信する。参照信号としては、ＣＲＳ（Cell-specific RS）や、ＳＲＳ（Sounding RS）、ＣＳＩ－ＲＳ（CSI-Reference Signal）、ＤＭＲＳ（DeModulation RS）などがある。ＣＲＳはセル選択用の制御信号である。ＳＲＳやＣＳＩ－ＲＳ、ＤＭＲＳは、上り又は下り方向の伝送路の状態を推定するためのＲＳである。伝搬路状態を示す情報はＣＳＩ（Channel State Information）とも称される。各種ＲＳは、１つの側面において、車載通信機１が、通信回線の状態を評価するための制御信号に相当する。ここでの通信回線の状態とは、例えば通信速度やレイテンシ、パケットロス率などを指す。各種ＲＳの送信は、定期的に実施されてもよいし、所定のイベントが生じたことを受けて実施されても良い。ＲＳの送信は、例えばユーザ装置（ＵＥ：User Equipment）からの問い合わせを受けたことや、通信エラーの発生頻度が所定の閾値を超過したことなどをトリガとして実行されても良い。

コアネットワーク３は、いわゆるＥＰＣ（Evolved Packet Core）である。コアネットワーク３では、ユーザの認証、契約分析、データパケットの転送経路の設定、ＱｏＳ（Quality of Service）の制御などの機能を提供する。コアネットワーク３は、例えばＩＰネットワークや携帯電話網等の、通信事業者によって提供される公衆通信ネットワークを含みうる。コアネットワーク３内においてデータの転送経路はＡＰＮ毎に異なるものとなる。コアネットワーク３を構成する種々の設備を以降ではネットワーク側装置とも記載する。前述のセルラー基地局２もネットワーク側装置に含めることができる。

アプリサーバ４は、車両Ｖｃで使用されるアプリ８１との連携により、所定のサービス（機能）を提供するための設備である。図１に示す種々のアプリサーバ４は、車両Ｖｃで使用されるアプリ８１から受信したデータに対して所定の処理を実行する、アプリケーションサーバに相当する。アプリサーバ４は、提供サービスに応じたデータをアプリ８１に送信したり、アプリ８１からデータを収集したりする。

中継サーバ５は、車両Ｖｃとアプリサーバ４との通信を中継するサーバである。中継サーバ５は、車両Ｖｃとアプリサーバ４との通信接続制御と、通信状態の監視を統合的に行う。中継サーバ５は、車載通信機１との協働により、オートモーティブ無線通信プラットフォーム（ＡＣＰ：Automotive Communication Platform）を構成する。ＡＣＰは、いつでも、どこでも、アプリサーバ４とアプリ８１とのセキュアな通信接続を可能にするための技術である。例えば車両Ｖｃごとに、モデルやリリース年（世代）、グレード等の違いに由来して、駐車中に電源がオフとなるＥＣＵと電源がオフにならないＥＣＵの組み合わせが相違しうる。また、車両Ｖｃごとに、ＥＣＵを含む車載システムの構成が相違しうる。中継サーバ５は、ＥＣＵごとの電源状態の違いや車両ごとのシステム構成の違いを、アプリサーバ４側から隠蔽する役割を果たす。その結果、あたかも各ＥＣＵ８とアプリサーバ４とが常時接続されているような状況、すなわち、ＥＣＵ８－アプリサーバ４間の擬似的な常時接続が実現される。このように中継サーバ５は、１つの側面においてＡＣＰを構成するサーバであるため、ＡＣＰサーバと呼ぶこともできる。

中継サーバ５は、車両Ｖｃに搭載された車載通信機１との間で、コアネットワーク３を介した無線通信によって情報をやり取りできる。中継サーバ５は、携帯電話回線だけでなく、Ｗｉ－Ｆｉや及びＶ２Ｘ等の無線通信によっても、車載通信機１と通信可能である。中継サーバ５は、アプリサーバ４からの要求に基づき、指定された車両Ｖｃに搭載されるＥＣＵ８へ向けて、データを送信したり、車両からのデータを取得したりする。

中継サーバ５は、図２に示すように通信装置５１、プロセッサ５２、ＲＡＭ５３、及びストレージ５４を用いて構成されている。通信装置５１は、車載通信機１や各種アプリサーバ４と通信を実施するための構成である。プロセッサ５２は、例えばＣＰＵ（Central Processing Unit）などの演算コアである。ＲＡＭ５３は、書き換え可能な揮発性メモリである。ストレージ５４は、書き換え可能な不揮発性メモリである。ストレージ５４には、車載通信機１とアプリサーバ４とのデータ通信を中継するためのプログラムである中継サーバプログラムが保存されている。中継サーバプログラムはＡＣＰクラウドソフトウェアと呼ぶこともできる。

中継サーバ５は、プロセッサ５２がストレージ５４に保存されている中継サーバプログラムを実行することにより発現される機能モジュールとして、例えば経路管理部Ｇ１、中継処理部Ｇ２、及び通信量管理部Ｇ３を備える。

経路管理部Ｇ１は、車載通信機１から各種アプリサーバ４までの通信経路情報を管理する構成である。ここでの通信経路情報には、例えば、送信元ＩＰアドレスや、ソースポート番号、宛先ＩＰアドレス、宛先ポート番号、プロトコル番号など、いわゆる５－ｔｕｐｌｅを含む。

ソースポート番号は、車載通信機１によってアプリ８１毎に固有の番号が割り当てられる。ポート番号は、例えば１６ビットの数値によって表現されうる。各ソースポート番号は、アプリ８１毎の識別情報であるアプリＩＤ（アプリ識別子）と対応付けられて保存される。なお、１つのアプリ８１に対して複数のソースポートが割り当てられることもある。車載通信機１は、例えば動的に利用可能とされている４９１５２から６５５３５までの範囲で、ソースポート番号を動的に設定可能に設定するように構成されていても良い。ソースポート番号は、送信元ポート番号と呼ぶこともできる。

経路管理部Ｇ１は、車載通信機１やアプリサーバ４と制御信号をやり取りすることで通信経路設定情報を取得する。経路管理部Ｇ１としての中継サーバ５は、アプリ８１に割り当てられているソースポート番号など、アプリ８１とアプリサーバ４とが通信するために必要な情報をアプリサーバ４に通知する。経路管理部Ｇ１が経路情報取得部に相当する。

その他、経路管理部Ｇ１は、ソースポート番号を、アプリＩＤ、ＥＣＵ－ＩＤ、及び通信機ＩＤを互いに紐づけて管理する。アプリＩＤは、アプリ８１を識別する識別情報である。ＥＣＵ－ＩＤは、ＥＣＵ８を識別する識別情報である。通信機ＩＤは、車載通信機１（車両Ｖｃ）を識別する識別情報である。中継サーバ５が保持するソースポートごとのアプリＩＤ、ＥＣＵ－ＩＤ及び通信機ＩＤについての情報は、車載通信機１との通信より、車載通信機１が保持する情報と同期される。

中継処理部Ｇ２は、経路管理部Ｇ１が取得している通信経路情報を元に、車載通信機１から送信されてきたデータを、ヘッダ等に記載の宛先情報に応じて定まるアプリサーバ４に転送する。また、中継処理部Ｇ２はアプリサーバ４から送信されてきたデータを車載通信機１に転送する。

通信量管理部Ｇ３は、車載通信機１ごとのデータ通信量を管理する構成である。例えば通信量管理部Ｇ３は、ＩＰアドレスを用いて車載通信機１ごとの通信量を管理する。具体的には、通信量管理部Ｇ３は、上り通信においてはＩＰヘッダに示される送信元ＩＰアドレス、下り通信においては宛先ＩＰアドレスを用いて車載通信機１ごとの通信量を管理する。ＩＰヘッダが、送信元ＩＰアドレスや宛先ＩＰアドレスが挿入されるデータフィールドに相当する。また、同一の車載通信機１に関しては、ソースポート番号とアプリＩＤとの対応関係を用いて、アプリ８１毎の通信量を管理する。ソースポートに対して１つのアプリ８１が対応付けられているため、或るソースポートを経由するデータ通信の総量は、当該ソースポートに対応付けられているアプリ８１の通信量の一部または全部を示す。また、アプリ８１の通信量を通信回線毎に区別して管理する構成によれば、別途後述するようにアプリ８１毎の通信量も算出可能となる。

なお、通信量管理部Ｇ３は、ＰＤＣＰ（Packet Data Convergence Protocol）レイヤでのパケット量を観測することで、ユーザ装置ごとの通信量を管理するように構成されていても良い。すなわち、通信量管理部Ｇ３は、ＰＤＣＰに係るネットワーク側装置より、ユーザ装置への送達確認が取れたＰＤＣＰ－ＳＤＵのデータ量と、ユーザ装置から受信したＰＤＣＰ－ＳＤＵのデータ量とを取得して通信量を管理しても良い。ＳＤＵはService Data Unitの略である。

その他、中継サーバ５は、アプリサーバ４や車両Ｖｃを認証する処理を実行するように構成されていても良い。中継サーバ５が提供する機能の一部又は全部は、各アプリサーバ４が有していてもよい。また、中継サーバ５が備える機能の一部又は全部は、ネットワーク側装置が備えていても良い。１つの観点において、中継サーバ５はネットワーク側装置の一種と解することができる。機能配置は適宜変更可能である。

Ｗｉ－Ｆｉ基地局６は、Ｗｉ－Ｆｉに準拠した無線ＬＡＮを形成するための通信設備である。Ｗｉ－Ｆｉの規格としては、ＩＥＥＥ８０２．１１ｎやＩＥＥＥ８０２．１１ａｃ、ＩＥＥＥ８０２．１１ａｘ（いわゆるＷｉ－Ｆｉ６）など、多様な規格を採用可能である。Ｗｉ－Ｆｉ基地局６は、インフラ設備として、多様なサービス事業者によって任意の箇所に配置されている。なお、本開示のＷｉ－Ｆｉは、無料のＷｉ－Ｆｉや、ユーザ或いは車両メーカが利用契約済みのＷｉ－Ｆｉなど、車載通信機１が利用可能なＷｉ－Ｆｉを指す。

＜アプリサーバ４の一例について＞
アプリサーバ４Ａは、例えば、車両Ｖｃの制御の参考となる動的又は準動的な交通情報（以降、制御支援情報）を配信するアプリサーバ４である。制御支援情報とは、例えば、車両周辺に存在する他の移動体の現在位置や移動速度、進行方向などを示す情報などである。制御支援情報は、例えば通行規制がなされている区間や、渋滞の末尾位置、路上落下物の位置などといった、走行上の障害物の位置や種別を示す準動的な地図要素についての情報であってもよい。制御支援情報は、車両Ｖｃの前方に存在する信号機の位置とその点灯状態を示す情報や、交差点内における進行方向に応じた走行軌道を示す情報であっても良い。このようなアプリサーバ４Ａは、先進運転支援（ＡＤＡＳ：Advanced Driver-Assistance Systems）系アプリケーションに対応するアプリサーバ４に相当する。

アプリサーバ４Ｂは、車両Ｖｃからアップロードされるプローブデータに基づいて、地図データを生成及び更新するサーバである。アプリサーバ４Ｂは、所定のデータベースに格納されている静的地図データを、車両Ｖｃからの要求に基づき配信するサーバであってもよい。アプリサーバ４Ｂが配信する地図データは、高精度地図データでもよいし、ナビ地図データでもよい。高精度地図データは、道路構造、及び、道路沿いに配置されている地物についての位置座標等を、自動運転に利用可能な精度で示す地図データに相当する。ナビ地図データは、ナビゲーション用の地図データであって、高精度地図データよりも相対的に精度の劣る地図データに相当する。このようなアプリサーバ４Ｂは、地図データを取り扱う地図系アプリに対応するアプリサーバ４に相当する。なお、地図系アプリには、地図データを用いた経路案内等を行うナビゲーションアプリを含めることができる。

アプリサーバ４Ｃは、例えばクラウド上に保存されている音楽データを車両Ｖｃに送信するアプリサーバ４である。このようなアプリサーバ４Ｃは、車両Ｖｃにおいて音楽を再生する音楽アプリに対応するアプリサーバ４に相当する。

なお、アプリサーバ４としては、その他、多様なサーバ／センタを採用可能である。車両用通信システム１００は、アプリサーバ４として、車両Ｖｃを遠隔制御する遠隔制御サーバを含んでいても良い。遠隔制御サーバは、車両Ｖｃから送信されてきた車載カメラ画像や車速、現在位置などの車両情報を所定のディスプレイに表示するとともに、オペレータが入力装置に行った操作信号を車両Ｖｃに送信する。ここでのオペレータとは、車両Ｖｃの外部から遠隔操作によって車両を制御する権限を有する人物を指す。

もちろん、以上で述べたアプリ８１の内容や役務は一例であって適宜変更可能である。車両Ｖｃには、上述した機能以外にも、動画アプリや、緊急通報アプリ、遠隔制御アプリ、音声認識アプリ、プローブアプリ、ソフト更新アプリなど、多様なアプリ８１が搭載されうる。動画アプリはクラウド上に保存されている動画をストリーミング再生するためのアプリ８１である。緊急通報アプリは事故や乗員の異常などをトリガに所定のセンタに連絡するアプリ８１であり、遠隔制御アプリは車両Ｖｃを遠隔制御するためのアプリ８１である。音声認識アプリは車載マイクで取得したユーザの発話内容を認識するアプリ８１であり、プローブアプリは車載カメラなどで認識した道路形状などのプローブデータをサーバにアップロードするアプリ８１である。ソフト更新アプリはアプリサーバ４から取得したデータに基づいて任意のＥＣＵ８のソフトウェアの更新を行うアプリ８１である。

また、ここでは一例として１つのＥＣＵ８が１つのアプリ８１に対応するものとするがこれに限らない。１つのＥＣＵ８が複数のアプリ８１を備えていても良い。さらに、複数のＥＣＵ８が連携して１つのアプリ８１を実行するように構成されていても良い。

＜車載通信機１の構成について＞
車載通信機１は、上述した無線通信機能を提供する装置であって、コアネットワーク３にとってのＵＥに相当する。車載通信機１は、図３に示すように車両に搭載されているＥＣＵ８と接続されて使用される。車両Ｖｃは車載通信機１の搭載により、インターネットに接続可能なコネクテッドカーとなる。車載通信機１は、ＤＣＭ（Data Communication Module）やＴＣＵ（Telematics Control Unit）などと呼ぶこともできる。車載通信機１には固有の識別情報としての通信機ＩＤが割り当てられている。通信機ＩＤは、ＤＣＭ－ＩＤや、ＴＣＵ－ＩＤと呼ぶこともできる。車載通信機１は、例えばインストゥルメントパネル内に収容されている。なお、車載通信機１は、ユーザが取り外し可能に構成されていてもよい。また、車載通信機１は、ユーザによって車室内に持ち込まれた、スマートフォン等の携帯端末であってもよい。

車載通信機１は、少なくとも１つの加入者識別モジュール（以降、ＳＩＭ：Subscriber Identity Module）１５を備える。これにより車載通信機１は、当該ＳＩＭ１５に対応する少なくとも１つのＡＰＮを用いたデータ通信を実施可能に構成されている。ＳＩＭ１５に対応するＡＰＮとは、当該ＳＩＭ１５の情報に基づき利用可能なＡＰＮを指す。ＳＩＭ１５は複数のＡＰＮを利用可能なものであってもよいし、１つのＡＰＮを利用可能なものであってもよい。

加えて、車載通信機１は、Ｗｉ－Ｆｉ通信可能に構成されており、各ＥＣＵ８での通信トラフィックの発生状況に応じて、複数のセルラー回線及びＷｉ－Ｆｉ回線を使い分ける。つまり、車載通信機１は、多様な通信回線を、通信の用途や通信状況に基づいて使い分ける。車載通信機１が利用可能な通信回線あるいは通信経路の概念には、セルラー回線だけでなく、Ｗｉ－Ｆｉ回線を含めることができる。

図３では車載通信機１に接続するＥＣＵ８を２つしか図示していないが３つ以上存在しうる。車載通信機１に直接的に又は間接的に接続するＥＣＵ８は１つであってもよい。例えば車載通信機１は、車両内に構築された通信ネットワークである車両内ネットワークＩｖＮを介して各ＥＣＵ８と相互通信可能に構成されている。

なお、車載通信機１とＥＣＵ８は、車両内ネットワークＩｖＮを介することなく直接的に通信可能に構成されていてもよい。車載通信機１は車両全体を統括するＥＣＵであるセントラルＥＣＵや、車両内と外部とを切り分け、セキュリティを確保するためのゲートウェイＥＣＵを介して、他のＥＣＵと通信可能に構成されていても良い。車両内ネットワークＩｖＮの規格としては、例えばController Area Network（ＣＡＮは登録商標）や、イーサネット（登録商標）、ＦｌｅｘＲａｙ（登録商標）など、多様な規格を採用可能である。車載通信機１の詳細は別途後述する。

各ＥＣＵ８は、ＣＰＵなどの演算コアとＲＡＭなどのメモリとを備えるコンピュータとして構成されており、各ＥＣＵ８に割り当てられたプログラムを実行することで、当該プログラムに応じた処理を実行する。以降では車載通信機１に接続するＥＣＵ８を区別して記載する場合には、ＥＣＵ８Ａ、ＥＣＵ８Ｂとも記載する。各ＥＣＵ８にはＥＣＵ－ＩＤが割り当てられている。

また、ＥＣＵ８はアプリ８１と、ＡＣＰクライアント８２を備える。アプリ８１は、ＣＰＵ等のハードウェアが所定のアプリケーションソフトウェアを実行することで実現される。本開示の「アプリケーション」及び「アプリ」との記載は、アプリケーションを実行する装置／演算コアと読み替えることができる。演算コアは、ＣＰＵなどのプロセッサに相当する。

アプリ８１は、複数のアプリサーバ４の何れかに対応する。例えばＥＣＵ８Ａが備えるアプリ８１Ａは、定期的に又は所定のイベントが生じた場合に、アプリサーバ４Ａから、制御計画の作成の参考となるリアルタイムな情報（つまり制御支援情報）を取得する。制御支援情報を要求するイベントとは例えば交差点や合流分岐地点までの残り時間／距離が所定値未満となったことを採用することができる。アプリ８１Ａは、一定時間おきに現在位置に応じた制御支援情報をアプリサーバ４Ａに問い合わせるように構成されていても良い。このようなアプリ８１Ａは、ＡＤＡＳ系のアプリケーションの一例に相当する。アプリ８１Ａは下り通信が主となるアプリの一例に相当する。

また、ＥＣＵ８Ｂが備えるアプリ８１Ｂは、プローブアプリである。アプリ８１Ｂは、定期的に又はアプリサーバ４Ｂからの要求に基づき、プローブデータをアプリサーバ４Ｂに送信する。アプリ８１Ｂは上り通信が主となるアプリの一例に相当する。

各アプリ８１には固有の識別情報であるアプリＩＤが割り当てられている。アプリＩＤは、アプリ８１の設計者が割り当てても良いし、車両Ｖｃ（実体的にはＥＣＵ８）へのインストール時に、車両Ｖｃへのソフトウェアのインストール等を統括的に管理する所定のＥＣＵ８によって割り当てられても良い。アプリＩＤはＡｐｐ－ＩＤと記載することができる。

各アプリ８１は、当該アプリ８１に対応するアプリサーバ４を宛先とする送信用データをＡＣＰクライアント８２に出力するとともに、対応するアプリサーバ４からのデータを車載通信機１及びＡＣＰクライアント８２を介して取得する。また、各アプリ８１は、アプリサーバ４へ向けた送信用データの発生等に伴って、ＡＣＰクライアント８２に向けて通信要求を出力する。通信要求は、例えば所定の電気信号、メッセージ、又は通信フレームに相当する。通信要求は、アプリＩＤを含む。

アプリ８１は、送信データを暗号化したり、アプリサーバ４から暗号化されて送信されてきたデータを復号したりする暗号処理部を備える。例えば、アプリ８１は、ＴＬＳ（Transport Layer Security）暗号化通信を実施可能に構成されている。暗号通信の方式としては多様な方式を採用可能である。アプリ８１は、より好適な態様として、電子証明書等を用いて、通信相手の認証、通信内容の暗号化及び改竄の検出等を実施可能に構成されている。なお、アプリ８１に限らず、ここでは一例としてはアプリサーバ４、中継サーバ５、車載通信機１などの他の装置もＴＬＳ通信を実施可能に構成されているものとする。

ＡＣＰクライアント８２は、アプリ８１と車載通信機１との通信を仲介する役割を担う構成である。ＡＣＰクライアント８２は、車両内中継モジュールと呼ぶこともできる。ＡＣＰクライアント８２は、アプリ８１毎或いはＥＣＵ８毎に配置されうる。ＡＣＰクライアント８２もまた、ＣＰＵ等のハードウェアが、所定のソフトウェアであるＡＣＰクライアントソフトウェアを実行することで実現される。ＡＣＰクライアント８２は、アプリ８１からの通信開始要求を車載通信機１に伝達するとともに、当該通信開始要求に対する車載通信機１からの回答をアプリ８１に伝達する。

また、ＡＣＰクライアント８２は、アプリＩＤやＥＣＵ－ＩＤを定期的に又は所定のイベントが生じた場合に車載通信機１に通知する。これにより車載通信機１はどのアプリ８１がどのＥＣＵ８に存在するのかを特定可能となる。各種ＩＤの通知は、例えば走行用電源がオンとなったタイミングや、所定の時刻で行われてもよい。なお、走行用電源は、例えばエンジン車においてはイグニッション電源である。電気自動車においてはシステムメインリレーが走行用電源に相当する。

その他、ＡＣＰクライアント８２は、車載通信機１からの指示信号に基づき、ＥＣＵ８の電源のオンオフ状態を切り替える。また、ＡＣＰクライアント８２は、車載通信機１からの信号に基づき、アプリ８１の起動状態も制御しうる。例えばＡＣＰクライアント８２は、車載通信機１を介して、アプリサーバ４から送信されたプッシュ通知を受信した場合にはＥＣＵ８の電源をオンにして、対応するアプリ８１を起動させる。

なお、ＡＣＰクライアント８２は任意の要素であって省略されても良い。また、ＡＣＰクライアント８２の機能はアプリ８１自身が備えていても良い。ＡＣＰクライアント８２はアプリ８１の一部として構成されていても良い。加えて、ＡＣＰクライアント８２は車載通信機１の一部として構成されていても良い。また、アプリ８１が備える暗号通信機能はＡＣＰクライアント８２が備えていても良い。各構成の機能配置は適宜変更可能である。

また、図３では、１つのＥＣＵ８が備えるアプリ８１を１つとする例を示しているが、ＥＣＵ８が備えるアプリ８１は複数あっても良い。ＥＣＵ８が複数存在する場合、当該ＥＣＵ８のＡＣＰクライアント８２は各アプリ８１のアプリＩＤや起動状態を管理しうる。

車載通信機１は、車両Ｖｃに搭載される任意のアプリ８１の要求に従って当該アプリ８１に対応するアプリサーバ４Ａにデータ送信を行う。また、アプリサーバ４から送信されたデータを受信してアプリ８１に転送する。前述の通り、アプリサーバ４との通信は、中継サーバ５やネットワーク装置を介して行われる。

当該車載通信機１は、処理部１１、ＲＡＭ１２、ストレージ１３、通信インターフェース１４、ＳＩＭ１５、及びこれらを接続するバス等を備えたコンピュータを主体として構成されている。処理部１１は、ＲＡＭ１２と結合された演算処理のためのハードウェアである。処理部１１は、ＣＰＵ等の演算コアを少なくとも一つ含む構成である。処理部１１は、ＲＡＭ１２へのアクセスにより、種々の処理を実行する。

ストレージ１３は、フラッシュメモリ等の不揮発性の記憶媒体を含む構成である。ストレージ１３には、処理部１１によって実行されるプログラムとして、通信制御プログラムが格納されている。処理部１１が上記プログラムを実行することは、通信制御プログラムに対応する方法である通信制御方法を実行することに相当する。ストレージ１３には、車載通信機１が利用可能なＡＰＮについての情報（例えばプロファイル等）が登録されている。

通信インターフェース１４は、車両内ネットワークＩｖＮを介してＥＣＵ８と通信するための回路モジュールである。通信インターフェース１４は、アナログ回路素子やＩＣ、車両内ネットワークＩｖＮの通信規格に準拠したＰＨＹチップなどを用いて実現されている。

ＳＩＭ１５は、回線の契約者を識別するための情報が記録されたＩＣモジュールであって、例えばＩＣカードとして構成されている。例えばＳＩＭ１５には、ＩＭＳＩ（International Mobile Subscriber Identity）と呼ばれる固有番号が、契約者の電話番号と結びついて記録されている。また、ＳＩＭ１５には、利用可能な周波数や、在圏セルを決定するために観測する周波数の優先順位などといった、無線通信接続に係る設定データも登録されている。ＳＩＭ１５は、図示しないカードスロットに挿入されたものでもよいし、ｅＳＩＭ（Embedded SIM）であってもよい。ここでのＳＩＭ１５の概念には、着脱可能なカードタイプのものと、組み込み型のもの（つまりｅＳＩＭ）の両方が含まれる。前述の通り、車載通信機１は複数のＳＩＭを備え、複数のセルラー回線を並列的に使用可能に構成されていても良い。

車載通信機１は、図４に示すように機能ブロックとして、車内通信部Ｆ１、無線通信部Ｆ２、及び通信制御部Ｆ３を備える。無線通信部Ｆ２は、セルラー通信部Ｆ２１、Ｗｉ－Ｆｉ通信部Ｆ２２、及び車車間通信部Ｆ２３を備える。通信制御部Ｆ３が通信制御装置に相当する。

車内通信部Ｆ１は、各ＥＣＵ８が出力した送信用データを受け取り、無線通信部Ｆ２へ出力するとともに、無線通信部Ｆ２が受信したデータを、転送すべきＥＣＵ８に向けて出力する構成である。例えば車内通信部Ｆ１は、各ＥＣＵ８から多重化されて入力されたデータを、所定の方式で分離することで、本来のデータを取得する。

車内通信部Ｆ１は、各ＥＣＵ８から入力されたデータを無線送信するまで一時的に保持する記憶領域であるバッファを含む。バッファは、ＲＡＭ等の書き換え可能な記憶媒体を用いて実現されればよい。車内通信部Ｆ１は、バッファに滞留しているデータの量やそれらのデータのヘッダに格納された情報を監視する機能も備える。当該バッファは通信制御部Ｆ３が備えていても良い。バッファに入っているデータは、順次、無線通信部Ｆ２にて取り出され、データの入力元（つまりＥＣＵ８）に応じた通信経路で宛先となるアプリサーバ４に向けて送信される。ＥＣＵ８毎の通信経路の割当状態は、通信制御部Ｆ３によって制御される。

セルラー通信部Ｆ２１は、例えばＬＴＥ等の無線通信プロトコルにおけるデータリンクレイヤ及び物理レイヤを担当する通信モジュールである。セルラー通信部Ｆ２１は、ＬＴＥで用いられる周波数帯の電波を送受信可能なアンテナを含む。また、セルラー通信部Ｆ２１は、ＬＴＥの通信規格に準拠してベースバンド信号から高周波信号への変換およびその逆変換に相当する信号処理を行うトランシーバと、ＩＰパケットと物理チャネルの信号との変換を行うパケット処理部と、を含む。なお、アンテナは受信ダイバーシティ等のために複数設けられていても良い。

セルラー通信部Ｆ２１は、車内通信部Ｆ１から入力されたＩＰパケットに対して、ＰＤＣＰ・ＲＬＣ・ＭＡＣの各データリンクサブレイヤでの処理を行う。また、符号化や、変調、デジタルアナログ変換等の処理を施すことで、入力されたデータに対応する搬送波信号を生成する。そして、生成した搬送波信号をアンテナに出力することで電波として放射させる。ＭＡＣはMedia Access Controlの略である。加えて、セルラー通信部Ｆ２１は、アンテナにて受信した受信信号に対して、アナログデジタル変換処理や復調処理といった所定の処理を施すことでデジタル値によって表現された情報系列（つまりデジタルデータ）に変換する。そして、その受信信号に対応するデータを、車内通信部Ｆ１に出力する。

Ｗｉ－Ｆｉ通信部Ｆ２２は、Ｗｉ－Ｆｉ基地局６を介してインターネットに接続し、アプリサーバ４と通信するための通信モジュールである。Ｗｉ－Ｆｉ通信部Ｆ２２は、例えば２．４ＧＨｚ帯や５ＧＨｚ帯など、Ｗｉ－Ｆｉ規格で使用される周波数帯の電波を送受信するためのアンテナと、変調回路、復調回路などを用いて構成されている。Ｗｉ－Ｆｉ通信部Ｆ２２は、車内通信部Ｆ１又は通信制御部Ｆ３から入力されたデータに対応する無線信号を放射する。また、Ｗｉ－Ｆｉ通信部Ｆ２２は、アンテナにて受信した受信信号に対応するデータを、車内通信部Ｆ１又は通信制御部Ｆ３に出力する。

なお、Ｗｉ－Ｆｉ通信部Ｆ２２は、Ｗｉ－Ｆｉ基地局６から発せられるビーコンを受信することによって、Ｗｉ－Ｆｉ基地局６の存在を認識する。Ｗｉ－Ｆｉ通信部Ｆ２２とＷｉ－Ｆｉ基地局６との通信接続は、通信制御部Ｆ３によって制御される。なお、Ｗｉ－Ｆｉ通信部Ｆ２２は、必ずしも車載通信機１に内蔵されている必要はない。Ｗｉ－Ｆｉ通信部Ｆ２２は車載通信機１がその動作状態を制御可能な態様で車載通信機１の外部に設けられていても良い。

車車間通信部Ｆ２３は、所定の周波数帯の電波を用いて他車両が備える車載通信機１と直接的な無線通信（つまり車車間通信）を実施するための通信モジュールである。車車間通信部Ｆ２３は、車車間通信用の周波数帯の電波を送受信するためのアンテナと、変調回路、復調回路などを用いて構成されている。車車間通信部Ｆ２３は、通信制御部Ｆ３から入力されたデータを変調して車車間通信用のアンテナに出力し、無線送信する。また、車車間通信部Ｆ２３は、アンテナで受信した信号を復調して通信制御部Ｆ３に提供する。

なお、本実施形態では一例として、車車間通信はＤＳＲＣ（ＷＡＶＥ）など、セルラー基地局２との通信方式とは異なる通信方式で実施されるものとするが、これに限らない。車車間通信もまた、ＬＴＥ等の規格に従って実施されてもよい。それに伴い、車車間通信部Ｆ２３は、セルラー通信部Ｆ２１と統合されていても良い。さらに、車車間通信は、Ｗｉ－Ｆｉ等の規格に従って実施されてもよい。それに伴い、車車間通信部Ｆ２３は、Ｗｉ－Ｆｉ通信部Ｆ２２と統合されていても良い。本開示における車車間通信とは、車載通信機１同士の直接的な通信を指し、その通信方式としては任意のものを採用可能である。

通信制御部Ｆ３は、各セルラー回線の通信状態を監視及び制御する。通信制御部Ｆ３は、所定の接続イベントが生じたことを受けて、セルラー回線を確立する手続きを実行する。複数のＡＰＮを利用可能に構成されている場合にはＡＰＮごとの回線を確立する。通信接続を確立するための手続きには、アタッチ要求の送信やＡＰＮ情報の送信などが含まれる。なお、例えばコアネットワーク３は、車載通信機１から通知されたＡＰＮ等の情報などに基づき、契約内容に応じた無線ベアラ及びＰＤＮコネクションを用意する。接続イベントとしては、ソフトウェア更新や、不具合による車載通信機１の再起動が行われた場合、ユーザまたは整備工場等のスタッフによってセルラー通信機能、換言すればモバイルネットワーク接続が有効化された場合などが挙げられる。

また、通信制御部Ｆ３は、Ｗｉ－Ｆｉ通信部Ｆ２２の動作を制御する。通信制御部Ｆ３は、Ｗｉ－Ｆｉ通信部Ｆ２２がビーコンを受信したことに基づいて、Ｗｉ－Ｆｉ基地局６との通信接続を開始する。すなわち、ＩＰアドレスの取得や、セキュリティ設定（暗号鍵の交換など）のための制御信号をＷｉ－Ｆｉ基地局６とやり取りする。さらに、通信制御部Ｆ３は車車間通信部Ｆ２３の動作も制御する。

さらに、通信制御部Ｆ３は、機能部として、経路特性取得部Ｆ３１、余力評価部Ｆ３２、経路設定部Ｆ３３、ポート管理部Ｆ３４、及び代行処理部Ｆ３５を備える。また、通信制御部Ｆ３は、例えばＲＡＭ１２などの書き換え可能な記憶媒体を用いて実現される指標保持部Ｍ１を備える。

経路特性取得部Ｆ３１は、通信回線毎の通信特性を示す種々の情報を取得する構成である。例えば経路特性取得部Ｆ３１は、ネットワーク側装置からセルラー回線毎の通信速度に関連するパラメータを取得する。セルラー回線毎の通信設定パラメータとしては、割当周波数や、パケット転送の優先順位、目標遅延時間、パケットロス率などが挙げられる。目標遅延時間は、ネットワーク側装置が想定する通信遅延時間の最大値である。目標遅延時間は、ネットワーク側装置によって設定される遅延特性設定値（delayThreshold）に対応する。経路特性取得部Ｆ３１が取得した通信設定パラメータは、例えば指標保持部Ｍ１に保存される。

経路特性取得部Ｆ３１は、セルラー回線毎の状態情報として、セルラー回線毎のラウンドトリップタイム（ＲＴＴ：Round-Trip Time）やスループットを逐次評価し、指標保持部Ｍ１に保存しても良い。ＲＴＴは、通信相手に信号やデータを発信してから、応答が返ってくるまでにかかる時間、すなわち応答遅延時間である。ＲＴＴは、往復レイテンシとも称される。スループットは、伝送路を通じて単位時間あたりに送受信できるデータ量を表す。スループットは通信速度を示す指標に相当する。なお、スループットは上り通信と下り通信とで別々に評価されてもよい。また、ＲＴＴやレイテンシなどに関し、直近所定時間以内における観測値の平均値を以ってセルラー回線毎の状態を評価しても良い。

その他、経路特性取得部Ｆ３１は、契約回線に対応するセルラー基地局２の負荷状況や、混雑度、余力を示す情報を取得しても良い。また、経路特性取得部Ｆ３１は、送信電力の余力であるパワーヘッドルーム（以降、ＰＨＲ：Power Headroom）を、セルラー回線毎に算出してもよい。ＰＨＲは、上りリンク共有チャネル（以降、ＰＵＳＣＨ：Physical Uplink Shared Channel）における現在の送信電力の設定値と最大送信電力との差分を表すパラメータである。また、経路特性取得部Ｆ３１は、ＲＳＲＰや、ＲＳＳＩ、ＲＳＲＱなどを算出してもよい。ＲＳＲＰは、Reference Signal Received Powerの略である。ＲＳＳＩはReceived Signal Strength Indicatorの略である。ＲＳＲＱはReference Signal Received Qualityの略である。ＲＳＲＰは、単位リソースエレメント当たりのＲＳの平均受信電力である。ＲＳＳＩは、ＲＳを収容するＯＦＤＭシンボルにおいてＬＴＥシステム帯域全体の電力を測定した値である。ＲＳＲＱは、セル固有の参照信号の受信電力と、受信帯域幅内の総電力との比である。ＲＳＲＱは、大きいほどセルラー基地局２からの信号の受信品質が良いことを示す。ＰＨＲや、ＲＳＲＰ、ＲＳＳＩ、ＲＳＲＱの算出方法自体は、３ＧＰＰが規定する方法により算出されればよい。

余力評価部Ｆ３２は、経路特性取得部Ｆ３１が取得した通信速度や通信帯域の空き状況を直接的又は間接的に示す種々の指標に基づき、自装置（自機）が利用可能なセルラー回線の余力を評価する。余力が大きいほど、大きいデータを収容できることを示す。余力評価部Ｆ３２は、複数の指標を組み合わせて自装置が利用可能なセルラー回線ごとの余力を算出しうる。余力評価部Ｆ３２は、通信速度が大きいほど、遅延時間が短いほど、ＰＨＲが大きいほど、余力を大きく評価する。余力はスコアとして表現されても良いし、複数のランクで表現されてもよい。例えば、余力は、有／無の２段階で判定されても良いし、無／小／中の３段階で表現されても良い。余力が無い状態は後述する代行通信不能な状態に対応し、余力が小の状態はデータサイズが所定値以下の比較的小さいデータの代行通信のみ可能な状態に対応する。なお、余力は、ＰＨＲなど、所定の項目を１つだけ用いて決定されても良い。余力評価部Ｆ３２の評価結果は、例えば経路設定部Ｆ３３や代行処理部Ｆ３５などによって参照される。なお、余力評価部Ｆ３２は任意の要素である。

経路設定部Ｆ３３は、セルラー回線の特性に基づいて、各アプリ８１のデータ通信に用いる通信経路を設定する構成である。例えばＡＤＡＳアプリなど、リアルタイム性を要求するアプリ８１に対してはレイテンシが小さい通信回線を割り当てる。また、地図アプリなど、データサイズが相対的に大きいことが見込まれるアプリ８１へは、通信速度や余力が大きい通信回線を優先的に割り当てる。なお、Ｗｉ－Ｆｉ通信が使える環境下においては、リアルタイム性を要求しないアプリ８１に対しては優先的に通信経路としてＷｉ－Ｆｉ通信を割り当てる。通信経路を構成する要素には、通信回線の種別のほか、割り当てる通信帯域の大きさ（幅）や、割当周波数、通信プロトコルの種別などを含めることができる。通信プロトコルにはＴＣＰ（Transmission Control Protocol）やＵＤＰ（User Datagram Protocol）などが含まれる。

経路設定部Ｆ３３は、アプリ８１またはアプリサーバ４からの通信開始要求を受け付けると、当該アプリのためのソースポートを確保するとともに、ルーティング処理を実行し、アプリ８１からアプリサーバ４までの通信経路を設定する。これにより、送信元ＩＰアドレスや、ソースポート番号、宛先ＩＰアドレス、宛先ポート番号、プロトコルなどが決定される。なお、ソースポートはアプリ８１毎に割り当てられる。つまり、１つのソースポートが複数のアプリ８１で共用されないように設定する。なお、１つのアプリに対して複数のソースポート番号が割り当てられても良い。

経路設定部Ｆ３３としての車載通信機１は、アプリサーバ４までの通信経路の設定が完了すると、ＡＣＰクライアント８２に対して通信開始要求に対する応答として、通信を許可する旨のメッセージである通信許可応答を返送する。通信許可応答には、少なくともソースポート番号が含まれる。また、車載通信機１は通信許可応答には、送信元ＩＰアドレスや、宛先ＩＰアドレス、宛先ポート番号、プロトコルが含まれていても良い。

通信制御部Ｆ３は、ソースポート番号に加えて、トークンを用いて各アプリ８１の通信の実施権を制御する。トークンは、いま通信してもよいか否かを示す制御信号に相当する。各アプリ８１は、車載通信機１からトークンが入力されている間は、通知されているソースポートを用いてアプリサーバ４と通信可能となる。なお、ソースポートは維持しつつ、トークンの有無は動的に切り替えられても良い。アプリ８１は、いったんトークンが入力されたら、その後トークンを取り下げる趣旨の信号が入力されるまでは通信権を保持しているものと判断するように構成されていてもよい。通信制御部Ｆ３は、回線の使用状況や他のアプリ８１の通信需要を鑑みて、個々のアプリ８１のトークンの有無を動的に制御しうる。

ポート管理部Ｆ３４は、各アプリ８１に割り当てているソースポート番号を管理する。また、ポート管理部Ｆ３４は、各ＡＣＰクライアント８２からの通知に基づき、アプリ８１がどのＥＣＵ８にあるのかを管理する。ポート管理部Ｆ３４は、各アプリ８１のアプリＩＤと、各ＥＣＵ８のＥＣＵ－ＩＤとを、ソースポート番号と紐付けてＲＡＭ１２に保存する。ポート管理部Ｆ３４は、ソースポート番号ごとのアプリＩＤ及びＥＣＵ－ＩＤを、車載通信機１に紐づく通信機ＩＤと共に、中継サーバ５に通知する。こうした処理により、中継サーバ５と車載通信機１が保持するＩＤ情報が同期される。

代行処理部Ｆ３５は、自装置の通信環境に応じて、自装置周辺に存在する他の車載通信機１に対し、自装置の代わりにアプリサーバ４との通信を代行すること（以降、代行通信）を要求する。ここでの代行通信とは、他車両のアプリ８１とアプリサーバ４との通信を中継することを指す。代行通信の概念には、他車両から車車間通信で取得したデータをセルラー通信で指定されたアプリサーバ４に送信する上り通信の代行と、セルラー通信でアプリサーバ４からダウンロードしたデータを車車間通信で依頼元に転送する下り通信の代行が含まれる。代行との表現は、多くの場合、転送あるいは中継と言い換えることができる。代行通信を要求することは、自車両のアプリ８１とアプリサーバ４との通信を他車両に中継するように要求することに相当する。車両間、換言すれば車載通信機１間の通信は車車間通信によって実施される。車載通信機１－アプリサーバ４間の通信は、Ｗｉ－Ｆｉ回線又はセルラー通信によって実施される。前述の通り、車載通信機１とアプリサーバ４とのデータ通信は中継サーバ５が介在する。

代行通信を行うための準備処理として、代行処理部Ｆ３５は定期的に車車間通信により、他装置（他機）と自装置が利用可能な通信回線ごとの通信状態を共有する。通信回線ごとの通信状態には、セルラー回線ごとの通信状態に限らず、Ｗｉ－Ｆｉの通信状態を含めることができる。通信状態には、例えば中継サーバ５までの通信速度が含まれる。また、代行処理部Ｆ３５は、通信状態を示す情報として、使用可能な回線ごとの回線の混雑度や、代行通信可能な通信容量などを他装置と共有してもよい。通信状態を示す情報には、余力評価部Ｆ３２が算出するセルラー回線ごとの余力を含めることができる。

代行処理部Ｆ３５は、自装置での通信状態と、他装置での通信状態とを比較して、他装置に代行通信を依頼するか否かを判断する。例えば、自装置が中継サーバ５（ひいてはアプリサーバ４）とデータ通信するよりも、他装置に中継してもらったほうが通信時間を短く抑えられることが期待できる場合に、代行通信を依頼する。より具体的には、他装置での上り通信速度が、自装置での上り通信速度よりも所定の代行利用閾値以上大きい場合に、他装置に代行通信を依頼する。ここで使用される代行利用閾値は例えば車車間通信による遅延時間に対応するパラメータである。代行利用閾値は、予め設定された一定の値であってもよいし、車車間通信でのレイテンシの観測値に応じて動的に変更されても良い。代行処理部Ｆ３５は、車車間通信による中継を介しても、総合的に通信時間を短く抑えられることが期待できる場合に、他装置に対して代行通信を依頼する。

また、代行処理部Ｆ３５は他装置から代行通信の依頼を受領した場合には、当該依頼に基づき、代行通信用の通信経路を確保し、依頼元から車車間通信で送信されてきたデータを中継サーバ５に向けて転送する。通信経路の確保には、代行通信用のソースポート番号や、代行通信の依頼元の通信機ＩＤなどを中継サーバ５に通知することを含む。当該代行通信に係る車載通信機１等の作動の詳細については別途後述する。

＜全体の処理フローについて＞
次に、図５及び図６に示すシーケンス図を用いて、第１通信機１Ａが備える任意のアプリ８１がアプリサーバ４とデータ通信を開始するための処理フローについて説明する。図５は、第１通信機１Ａが代行通信を利用せずに、自装置のセルラー回線又はＷｉ－Ｆｉ通信を用いてデータ通信を行う場合のシーケンス図である。図６は、第１通信機１Ａが第２通信機１Ｂが備える代行通信機能を利用してアプリサーバ４とのデータ通信を行う場合のシーケンス図である。

図５及び図６に示すＥＣＵ８は、第１車両Ｖ１が備える任意のＥＣＵ８とすることができる。また、図５及び図６に示すアプリサーバ４は、図５及び図６に示すＥＣＵ８が備えるアプリ８１に対応するアプリサーバ４である。以下では便宜上、通信要求の出力元であるアプリ８１のことを対象アプリとも記載する。

なお、以下の説明の前提として、各車載通信機１は、セルラー回線を用いた中継サーバ５との通信接続が確立している。中継サーバ５及びアプリサーバ４もまた相互通信可能な状態にあって、疎通確認のための通信やデータ通信を随時実施する。また、第１通信機１Ａと第２通信機１Ｂは車車間通信可能な位置関係を維持している。第１通信機１Ａと第２通信機１Ｂは互いに中継サーバ５との通信状態を車車間通信により随時共有している（Ｓ０１）。

まず、第１通信機１Ａが備える対象アプリ８１においてアプリサーバ４への送信用データが発生すると、当該アプリ８１は、当該アプリ８１に対応するＡＣＰクライアント８２に対して通信要求を出力する（ステップＳ１０）。或るアプリ８１に対応するＡＣＰクライアント８２とは、当該アプリ８１を収容しているＥＣＵ８、つまり同一のＥＣＵ８が備えるＡＣＰクライアント８２を指す。

アプリ８１からＡＣＰクライアント８２へと出力される通信要求は、アプリＩＤを含む。なお、通信要求には、通信条件を含んでいても良い。通信条件を構成する項目としては例えば、許容待ち時間、許容ＲＴＴ、想定データサイズ、データ欠損可否などを採用することができる。許容待ち時間は通信開始まで許容可能な待ち時間を示す。許容ＲＴＴは、許容可能な応答遅延時間を示す。想定データサイズは、アプリ８１とアプリサーバ４との間でやり取りされる１つのデータセットのサイズの想定値を示す。想定データサイズは、必要な通信容量を示す。データ欠損可否は、データの部分的な欠損を許容するか否か、換言すれば、通信の信頼性を重視するか否かを示す。通信条件はアプリ８１毎に固定であってもよいし、送信用データの量や内容に応じて可変であってもよい。

ＡＣＰクライアント８２は、アプリ８１からの通信要求を受信すると、当該要求を受け付ける（ステップＳ１１）。具体的には、アプリＩＤと通信条件とを紐付けて所定の記憶領域に一時保存する。通信要求の受付状態を示すデータは、例えばＥＣＵ８が備えるＲＡＭなどに保存される。通信条件は、事前にＡＣＰクライアント８２がアプリ８１と通信することで取得しておいても良いし、上述の通り通信要求として受信しても良い。ＡＣＰクライアント８２は通信要求の受付処理が完了すると、アプリＩＤと通信条件とを含む通信開始要求を第１通信機１Ａに送信する（ステップＳ１２）。

第１通信機１Ａは、ＡＣＰクライアント８２からの通信開始要求が入力されたことに基づいて、ＡＣＰクライアント８２から通知された通信条件を充足する通信経路の割り当てが可能か否かを、通信回線毎の状態に基づき判断する（ステップＳ１３）。その際、第１通信機１Ａの通信制御部Ｆ３は、自装置が利用可能な通信回線だけでなく、車車間通信で取得している第２通信機１Ｂでの通信状態をもとに、代行通信の利用を検討する。すなわち、代行処理部Ｆ３５が、自装置での通信状態と、他装置での通信状態とを比較して、他装置に代行通信を依頼するか否かを判断する。ここでの代行処理部Ｆ３５にとっての自装置とは第１通信機１Ａを指し、他装置とは第２通信機１Ｂを指す。なお、自装置の周辺に他装置が複数存在する場合には、他装置ごとに代行通信の利用を検討する。

例えば代行処理部Ｆ３５は、自装置ではアプリ８１が要求する通信条件を充足する通信を実施できない一方、他装置によればアプリ８１が要求する通信条件を充足させることができる場合に、代行通信を採用することを決定する。また、代行処理部Ｆ３５は自装置がアプリサーバ４と通信するよりも代行通信を利用したほうが、総合的な通信効率が高まる場合にも代行通信を利用することを決定する。

代行通信を利用したほうが総合的な通信効率が高まる場合としては、上記例示のほか、自装置の在圏セルにおけるＰＨＲが所定値以下である場合、より具体的には最大送信電力に達している場合であって、他装置のＰＨＲが所定値以上である場合がある。また、同様にセルラー基地局２との通信にパケット誤りを生じ再送が頻発している場合なども、代行通信を利用したほうが総合的な通信効率が高まる場合に含めることができる。代行通信を利用する条件である代行依頼条件は適宜設定されうる。

代行通信が利用できない場合や、代行通信を利用せずに自装置がアプリサーバ４と通信したほうが通信効率が高まる場合には、代行通信を利用しないことを決定する。代行通信が利用できない場合とは、例えば車車間通信可能な他装置が存在しない場合などである。

代行通信を利用しないことを決定した場合には（Ｓ１３１ ＮＯ）、自装置が利用可能な通信回線の中から、アプリ８１とアプリサーバ４との通信に使用する回線を選択する。利用可能な回線が複数存在する場合には、通信回線毎の使用状況や品質などに基づいて、アプリ８１の通信条件に最も好適なものを選択する。なお、利用可能な通信回線が１つだけである場合には当該回線を選択する。

そして、選択した通信回線を用いた通信経路の設定処理を実施する（ステップＳ１４）。すなわち、経路設定部Ｆ３３が対象アプリ用のソースポートを確保するとともに、ルーティング処理を実行し、アプリ８１からアプリサーバ４までの通信経路を設定する。これにより、送信元ＩＰアドレスなどが決定される。なお、ルーティング処理は、ＤＮＳ（Domain Name System）を用いた宛先ＩＰアドレスの取得や、コネクションの確立、ルーティングテーブルの生成などを含む。ルーティング処理自体は、所定のシグナリング手順に従って実施される。

また、ステップＳ１４の経路設定には、第１通信機１Ａが中継サーバ５に対して対象アプリのアプリＩＤ、通信機ＩＤをソースポート番号と対応付けて通知することが含まれる。第１通信機１Ａは、中継サーバ５に対し、ソースポート番号以外の通信経路情報を通知しても良い。ソースポート番号以外の通信経路情報とは例えば送信元及び宛先ＩＰアドレス、宛先ポート番号などである。無線通信に使用する回線種別や通信事業者、ＡＰＮなどの一部又は全部を経路情報に含めることができる。

第１通信機１Ａは、アプリサーバ４までの通信経路の設定が完了すると、ＡＣＰクライアント８２に対して通信開始要求に対する応答として、通信を許可する旨のメッセージである通信許可応答を返送する（ステップＳ１５）。通信許可応答には、例えばソースポート番号や宛先ＩＰアドレスなどの経路情報が含まれる。また、第１通信機１Ａは通信開始要求に対する応答として、経路情報に加えて、通信の実施権の有無を示すトークンを送信しても良い。

ＡＣＰクライアント８２は、第１通信機１Ａからの通信許可応答を受領すると、要求管理処理として、対象アプリに割り当てられているアプリＩＤと、経路情報と、トークンの有無を紐付けて保存する（ステップＳ１６）。そして、ＡＣＰクライアント８２は、アプリ８１に対して通信開始要求に対する第１通信機１Ａからの応答の報告として、ソースポート番号やトークンの有無を通知する（ステップＳ１７）。ＡＣＰクライアント８２は、第１通信機１Ａから宛先ＩＰアドレスなど、ソースポート番号以外の経路情報をアプリ８１に通知しても良い。

アプリ８１は、ステップＳ１６においてＡＣＰクライアント８２から通信経路が確保されたことを示す報告を受信すると、当該報告に示されるソースポート番号を用いて、アプリサーバ４と暗号通信を開始する（ステップＳ１８）。例えば、アプリ８１とアプリサーバ４とはＴＬＳ暗号通信を実施する。この場合、アプリ８１が生成した暗号化されたデータは、第１通信機１Ａから無線送信され、セルラー基地局２を含むネットワーク側装置、及び中継サーバ５で中継されてアプリサーバ４に到達する。もちろん、下り通信も上り通信と同様に実施されうる。すなわち、アプリケーションサーバ３から転送用のデータを代行通信用のポートを用いたセルラー通信で受信し、当該受信データを車車間通信により依頼元としての他機に転送する。

なお、ステップＳ１３において通信制御部Ｆ３は、自装置が利用可能な通信回線の中に、ＡＣＰクライアント８２から通知された通信条件を充足する通信回線があるか否かを、通信回線毎の使用状況や品質などに基づいて検証してもよい。すなわち、ＡＣＰクライアント８２から通知された通信条件を充足する通信経路の割り当てが可能かどうかを、通信回線毎の使用状況や品質などに基づいて判断してもよい。自装置が利用可能な通信回線の概念には、自装置が利用可能なセルラー回線やＷｉ－Ｆｉの他、代行通信を含めることができる。

ステップＳ１３において通信制御部Ｆ３は、ＡＣＰクライアント８２から通知された通信条件を充足する通信回線がなかった場合には、割当不可応答をＡＣＰクライアント８２に返送しても良い。割当不可応答は、割当不可であることを示すメッセージである。割当不可応答は、単に要求された通信条件を充足する通信回線が存在しないことだけを示すメッセージであっても良い。割当不可応答は、通信条件を充足する通信を実施可能となるまでの待機時間の見込み値を含んでいても良い。その他、割当不可応答は、現在の状況において実施可能な通信条件を含んでいても良い。例えば現時点で提供可能な通信サービスのＲＴＴや送信可能なデータサイズなどを通知しても良い。

前述の通り、アプリ８１とアプリサーバ４との通信は、中継サーバ５を介して実施される。中継サーバ５は、第１通信機１Ａから通知されてきたソースポート番号を用いて、アプリ８１毎の通信量を管理する（ステップＳ２０）。すなわち、ソースポートを用いてやり取りされるデータの量を計測する。データ量は別途後述するように、通信に使用された回線毎に区別して管理される。

以上が代行通信を利用しないパターンの作動である。ステップＳ１３において代行通信を利用すると決定した場合には（Ｓ１３１ ＹＥＳ）、図６に示すようにステップＳ１４Ａとして、代行通信設定処理を実施する。

代行通信設定処理については図７を用いて説明する。図７に示すフローチャートは、Ｓ１４Ａとして実行される。ここでは一例として代行通信設定処理はステップＳ４１～Ｓ４８を含む。もちろん、代行通信設定処理が含むステップ数や、処理の順序は適宜変更可能である。なお、本開示では代行通信を依頼する車載通信機１を依頼元通信機、代行通信を引き受けて実施する車載通信機１を代行通信機とも記載する。代行通信機は一時中継機、転送機とも呼ぶ事もできる。以下の例では第１通信機１Ａが依頼元通信機に相当し、第２通信機１Ｂが代行通信機に相当する。

代行通信設定処理では、まず第１通信機１Ａが第２通信機１Ｂに対し、車車間通信にて代行通信の実施を要求する信号である代行通信要求信号を送信する（ステップＳ４１）。代行通信要求信号は、例えば送信元のＭＡＣアドレスなど、Ｌ２ヘッダ（ＭＡＣヘッダ）を構成する情報を含みうる。ＭＡＣヘッダが送信元ＭＡＣアドレスや宛先ＭＡＣアドレスを示すデータフィールドに相当する。なお、ここでの送信元とは第１通信機１Ａを指す。

上り通信に関する代行通信の依頼である場合、依頼元通信機としての第１通信機１Ａは、代行通信で送信してもらいたいデータ量である代行送信量を、依頼先としての第２通信機１Ｂに通知してもよい。代行送信量は、代行通信要求信号に含まれていても良い。代行通信要求信号には、代行を依頼する通信のタイプが、上り通信が主体的な通信か、下り通信が主体的な通信かを示す情報を含んでいても良い。依頼元通信機は、上り通信の代行を依頼するのか、下り通信の代行を依頼しているのかを示す通信方向フラグを含む代行通信要求信号を送信するように構成されていても良い。

第２通信機１Ｂは代行通信要求を受信すると、代行処理部Ｆ３５が自装置の通信状況をもとに、代行通信を引き受けるか否かを判断する（ステップＳ４２）。本ステップにおける自装置とは第２通信機１Ｂを指す。代行処理部Ｆ３５は、例えば自装置内の通信需要（トラフィック量）に対して通信速度に余裕がある場合や、ＲＴＴが所定値以下に抑えられている場合に、代行通信を許可する。通信速度に余裕がある場合とは、例えば通信速度が所定値以上である場合を含む。

代行処理部Ｆ３５は、依頼元としての第１通信機１Ａから代行送信量が通知されている場合、自機の通信状態をもとに通知された代行送信量を所定時間以内に送信できるか否かを判断し、当該判断結果に基づいて代行通信を引き受けるか否かを判断しても良い。その場合、依頼元から通知されたデータ量を所定時間以内に送信できないと判断した場合には、代行通信を引き受けないことを決定する。

なお、他装置からの代行通信要求を承諾する条件である代行承諾条件は適宜設計されればよい。代行処理部Ｆ３５は、余力評価部Ｆ３２が算出している通信回線の余力が所定値以上である場合に代行通信を承諾しても良い。代行処理部Ｆ３５は、送信電力に余剰のある場合、具体的には自装置のセルラー回線のＰＨＲの値が所定値以上である場合に上り通信の代行を承諾しても良い。代行処理部Ｆ３５は、自装置が利用可能なセルラー回線の受信品質が良い場合、具体的にはＲＳＲＱが所定値以上である場合に、下り通信の代行を承諾しても良い。代行処理部Ｆ３５は自装置が利用可能なセルラー回線又はＷｉ－Ｆｉ通信の状態が所定の代行承諾条件を充足している場合、代行通信を承諾する。代行承諾条件として、下り通信用の条件と上り通信用の条件が別々に設定されていても良い。

第２通信機１Ｂは、自装置が利用可能なセルラー回線等の状態に基づき代行通信要求を承諾すると判断した場合には、第１通信機１Ａに向けて、承諾応答を車車間通信で返送する（ステップＳ４３）。承諾応答は、代行通信を引き受けることを宣言する応答信号である。承諾応答はＡＣＫの一種と解することができる。承諾応答は、例えば自装置のＭＡＣアドレスや、ＩＰアドレスなど、依頼元通信機が代行通信機を特定するための情報を含んでいれば良い。なお、第２通信機１Ｂは、転送先ＩＰアドレスとして自装置のＩＰアドレスを第１通信機１Ａに通知してもよい。

なお、第２通信機１Ｂは、自装置が利用可能なセルラー回線又はＷｉ－Ｆｉ通信の状態が代行承諾条件を充足していない場合には、代行通信を拒否する旨の応答信号である拒否応答を返送してもよい。拒否応答はＮＡＣＫの一種と解することができる。代行通信を要求された車載通信機１は、自装置が利用可能な通信回線の状態をもとに当該依頼を引き受けるか否かを決定し、その決定結果を返送する。

第１通信機１Ａは、代行通信要求に対して承諾応答を受信した場合には、代行通信用のソースポートを新たに用意する（ステップＳ４４）。ここで用意するソースポート番号は、第１通信機１Ａがセルラー回線又はＷｉ－Ｆｉを用いてアプリサーバ４とデータ通信する際に使用するソースポートとは異なるものとする。便宜上、代行通信用に用意されるソースポートのことを代行通信用ソースポートとも記載する。第１通信機１Ａは代行通信用ソースポート番号、及び、最終的な宛先情報を車車間通信で第２通信機１Ｂに通知する（ステップＳ４５）。最終的な宛先情報とは、対象アプリが通信したいアプリサーバ４のＩＰアドレスを指す。

なお、宛先情報には最終的な宛先とするアプリサーバ４のＭＡＣアドレスなどが含まれていても良い。また、代行通信用のポートは、第２通信機１Ｂが未使用のポートであってもよい。さらに、代行通信用のソースポート番号は、第１通信機１Ａと第２通信機１Ｂの両方が未使用のポートであってもよい。そのようなポート設定態様によれば、どのレイヤで通信量を計測する場合であっても、代行通信による通信量と、代行通信ではない通信量とを区別可能となる。

第２通信機１Ｂは、第１通信機１Ａから代行通信用のソースポート番号及び宛先情報を取得すると、中継サーバ５に対して、第１通信機１Ａから指定されたソースポートを代行通信用に確保するように要求する（ステップＳ４６）。また、第２通信機１Ｂは、当該ポート番号は、第１通信機１Ａとアプリサーバ４との通信のためのポートであることを中継サーバ５に通知する。その際、対象アプリのアプリＩＤや第１通信機１Ａの通信機ＩＤ、対象アプリを収容するＥＣＵ－ＩＤなどを中継サーバ５に通知しても良い。対象アプリのＩＤ等は、第１通信機１Ａから取得可能である。例えば、対象アプリのＩＤ等は、代行通信要求に含まれていても良いし、承諾応答に対するさらなる応答として、第１通信機１Ａから第２通信機１Ｂに送信されても良い。

そして、第２通信機１Ｂは、第１通信機１Ａから通知された宛先ＩＰアドレスをもとにルーティング処理を実施し、指定されたアプリサーバ４までの通信経路を確立する（ステップＳ４７）。通信経路の用意が整うと第２通信機１Ｂは第１通信機１Ａに向けて、経路確立報告を送信する（ステップＳ４８）。経路確立報告は、代理通信可能な状態になったことを通知する無線信号に相当する。

第１通信機１Ａは、第２通信機１Ｂからの経路確立報告を受信すると、対象アプリに対応するＡＣＰクライアント８２に許可応答を送信する（図６ Ｓ１５）。ＡＣＰクライアント８２は、第１通信機１Ａからの通信許可応答を受領すると、要求管理処理（ステップＳ１６）を実施し、アプリ８１に対してソースポート番号やトークンの有無を通知する（ステップＳ１７）。

アプリ８１は、ＡＣＰクライアント８２から通信経路が確保されたことを示す報告を受信すると、Ｌ３ヘッダに送信元を自装置、宛先として所望のアプリサーバ４を指定した、暗号化されたデータを含む通信パケットを生成して、第１通信機１Ａに出力する。ここでのＬ３とは、ＯＳＩ参照モデルにおけるレイヤ３（ネットワーク層）を指す。Ｌ３ヘッダは例えばＩＰヘッダを指す。すなわち、アプリ８１は、ＩＰヘッダとしてのデータフィールドに、宛先とするアプリサーバ４のＩＰアドレスや、代行通信用のソースポート番号を挿入したＩＰパケットを第１通信機１Ａに出力する。

第１通信機１Ａは、転送用のデータとして、アプリ８１から入力されたＩＰパケットに、第２通信機１ＢのＭＡＣアドレスを宛先ＭＡＣアドレスに設定したＬ２ヘッダ（いわゆるＭＡＣヘッダ）を付加した通信フレームを生成する。そして当該通信フレームを、車車間通信で第２通信機１Ｂに送信する。ここでのＬ２は、ＯＳＩ参照モデルにおけるレイヤ２（データリンク層）を指す。

第２通信機１Ｂは、第１通信機１Ａからのデータを受信すると、事前のルーティング処理にて用意したルーティングテーブルに基づき、Ｌ２ヘッダ（ＭＡＣヘッダ）の書き換えにより、転送処理を行う。１つの態様として第２通信機１Ｂは代行通信時に、依頼元通信機から提供されたデータのＬ３ヘッダ（ＩＰヘッダ）は書き換えない。すなわち、代行通信機としての第２通信機１Ｂは、ＩＰアドレスやポート番号の書き換えは行わずに転送を行う。

上記の構成によれば、第１通信機１Ａが送信した通信パケットは、第２通信機１Ｂ、ネットワーク側装置、及び中継サーバ５で中継されてアプリサーバ４に到達する。すなわち、代行通信利用時は、第１通信機１Ａからのデータは、直接ネットワーク側装置に入るのではなく、第２通信機１Ｂを経由する。以上では上り通信時の作動について主として述べたが、下り通信も同様の通信経路で実施されうる。ソースポートは車載通信機１のポートを指すものであって、下り通信においてはソースポートとの記載は宛先ポートと置き換えて実施可能である。

中継サーバ５は、代行通信用のポートが使用された通信に関しては、代行通信での通信量として、通常の通信量とは分けて計上する。例えば図８に示すように、代行通信によって行われた通信のデータ量は、ポート番号によって通常の通信で行われたデータ量とは分けて管理される。なお、通常の通信とは、代行されていない通信、すなわち、アプリ８１が所属する車載通信機１が自装置で利用可能なセルラー回線又はＷｉ－Ｆｉを用いて行った通信を指す。代行通信機にとっての通常の通信とは、当該車載通信機１自分自身（つまり自機）のための通信を指す。

図８に示すＴＣＵ－ＩＤは通信機ＩＤを意味し、一例として「１０１」は第１通信機１Ａの通信機ＩＤを、「１０２」は第２通信機１Ｂの通信機ＩＤを表している。また、ポート番号が４９１５２に設定された行の通信量は、通常の通信での通信量を表し、ポート番号が４９１５４に設定された行の通信量は、第２通信機１Ｂによって代行された通信量を表す。代行機ＩＤは、代行通信を行った車載通信機１のＩＤを指す。図８に示す例では第２通信機１Ｂが１．２ＧＢ分、第１通信機１Ａのデータ通信を代行した場合を示している。通信量及びポート番号は、さらに、通信回線の種別や、回線を提供する通信事業者ごとに区分されて管理されても良い。

なお、代行通信機がＭＡＣヘッダの送信先を書き換えて転送する構成では、中継サーバ５が上り通信で受信する通信パケットの送信元ＩＰアドレスは、代行通信で到着した場合も通常の通信で到着した場合もどちらも第１通信機１Ａのものとなる。そのため中継サーバ５は、送信元ＩＰアドレス情報からは、観測した通信パケットが、代行通信で到着した通信パケットか通常通信で到着した通信パケットかどうかを識別できない。これに対し、本開示の構成によれば、代行通信時と通常の通信時とで、通信に使用するポートを異ならせることで、中継サーバ５は、代行通信で到着した通信パケットと、通常の通信で到着した通信パケットを区別可能となる。

＜効果＞
上記の構成によれば、代行通信時と通常の通信時とで、通信に使用するポートを異ならせる。そして、ポート番号ごとに区別して通信量を計上することにより、代行された通信の量と、代行されていない通信の量とを区別して管理することができる。その結果、例えば通信量に応じた課金を適正に実施可能となる。

例えば特許文献２に開示されているように、ＵＥに割り当てられたベアラ情報に基づきＵＥごとの通信量を管理する構成では、第１通信機１Ａの通信を代行した分が、第２通信機１Ｂの通信量として計上されうる。具体的に、図８に示す例を用いて説明すると、１．２ＧＢ分の通信量が第２通信機１Ｂの通信量として計上されうる。なお、ＵＥごとの無線ベアラの割当量に基づきＵＥごとの通信量を管理する構成は、コントロールプレーン（Control-plane）の制御情報を用いて、第２通信機１Ｂの実通信量を特定する構成に相当する。実通信量とは実際に無線ベアラ等のリソースを使用した量に対応する通信量であって、代行通信分が含まれる。

そのような懸念に対し、上記構成によれば、代行通信による通信量を通常の通信量と区別可能であるため、第１通信機１Ａの通信を代行した分が第２通信機１Ｂの通信量として計上されることを回避可能となる。あるいは、第２通信機１Ｂの実通信量から、第１通信機１Ａの通信を代行した分を除外可能となる。

以上、本開示の実施形態を説明したが、本開示は上述の実施形態に限定されるものではなく、以降で述べる種々の変形例も本開示の技術的範囲に含まれ、さらに、下記以外にも要旨を逸脱しない範囲内で種々変更して実施することができる。例えば下記の種々の補足や変形例などは、技術的な矛盾が生じない範囲において適宜組み合わせて実施することができる。なお、以上で述べた部材と同一の機能を有する部材については、同一の符号を付し、その説明を省略することがある。また、構成の一部のみに言及している場合、他の部分については上記説明を適用することができる。

以上では、代行通信機としての第２通信機１Ｂは、ＩＰヘッダの中身を書き換えずに、ＭＡＣヘッダの送信先を書き換えて転送することにより、代行通信を実現する態様お開示したがこれに限らない。例えば代行通信機としての第２通信機１Ｂは、自装置から所望のアプリサーバ４までの通信経路を確立した上で、送信元ＩＰアドレスを自装置のＩＰアドレスに書き換えて転送するように構成されていても良い。その場合、第２通信機１Ｂは、代行通信要求を受け付けたことに基づき、未使用のソースポートの中から、代行通信用のソースポートを設定し、当該代理通信用ソースポートを中継サーバに通知する。代行通信においては当該代行通信用のポートを用いて第１通信機１Ａとアプリサーバ４とのデータ通信を中継すれば良い。

上記の変形例においても中継サーバ５はデータ通信に用いられたポート番号から、代行通信によるものか、通常の通信によるものかを識別することができる。なお、図９はＩＰアドレスの書き換えを行う場合の通信量の管理結果の一例を示す。仮に送信元／宛先ＩＰアドレスに基づいて車載通信機１ごとの通信量を管理する構成においては、いったんは第２通信機１Ｂの通信量として代行通信分も計上されるが、ソースポート番号を用いて除外可能となる。なお、図９に示す依頼元ＩＤとは、依頼元通信機の通信機ＩＤを意味するものである。ソースポート番号「４９１５８」は、代行通信用に用意したソースポート番号であって、当該番号に紐づく通信量は、第１通信機１Ａの通信を代行した分を示している。

なお、前述のＰＤＣＰレイヤでのパケット量を観測することで、ユーザ装置ごとの通信量を管理する構成においても、図９に示すように代行通信分の通信量が代行通信機としての第２通信機に計上されうる。本開示の構成によれば、これまでの説明の通り、代行通信量を非代行通信のデータ量と分けて管理可能となるため、どのレイヤで通信量を計上する場合であっても、各車載通信機１での実質的な通信量を最終的に特定可能となる。

ところで、アプリ８１ごとに、換言すれば、データ通信の種別ごとに、代行通信を利用可能か否かが予め設定されていても良い。例えば動作視聴や音楽再生、ウェブブラウジングなど、エンターテイメント性の強いアプリ、あるいはプライベート性の高いアプリ、緊急性が低いアプリは代行通信を利用不可に設定されていても良い。一方、車両モデルに関するデータや、公共性が強いデータは代行通信を利用可能に設定されていても良い。車両モデルに関するデータとは、搭載されているＥＣＵの情報や、車載通信機１の情報等を指す。ＥＣＵ／車載通信機１の情報とは、型番や、ＩＤ、グレード、リリース年（世代）などの一部又は全部を指す。公共性が強いデータとは、換言すれば、第三者にとっても有益なデータであって、例えば、プローブデータが想定される。プローブデータの概念には、走行軌跡や、交通情報、路面情報などを含めることができる。プローブデータは、事故車両や駐車車両、落下物、交通規制、渋滞区間などの動的な地図要素についての観測データであってもよい。プローブデータは、地点ごとのワイパーの作動速度や、車線変更が行われた地点の情報、急ブレーキが行われた地点の情報といった、車両挙動を示すデータであってもよい。プローブデータは、広く、静的な地図、又は動的な地図を作成するためのデータと解することができる。

上記のようにアプリ／データ種別ごとに代行通信の可否が設定されている構成によれば、緊急性の低い通信が代行通信されることで、車車間通信用の無線リソースが逼迫したり、各車載通信機１での処理負荷が増大したりする恐れを低減できる。なお、代行通信を利用可能なアプリ／データ通信と、代行通信を利用禁止するアプリ／データ通信は、予め設定されていても良いし、中継サーバ５などの外部指示又はユーザ操作に基づき設定変更可能に構成されていても良い。

以上では中継サーバ５を通信の中継及び通信量の管理を行うサーバとする態様を開示したがこれに限らない。中継サーバ５自身も所定のアプリ８１に対応する処理を実施する、アプリサーバ４の一種として構成されていても良い。また、中継サーバ５の機能は、任意の１つのアプリサーバ４が代表的に備えていても良いし、各アプリサーバ４が備えていても良い。

＜付言（１）＞
本開示には以下の構成／方法も含まれる。

［構成（１）］
セルラー通信と車車間通信とを実施可能に構成された、それぞれ異なる車両で使用される複数の通信機と、通信機と任意のアプリケーションサーバとのデータ通信を中継するとともに、通信機ごとのデータ通信量を管理する中継サーバと、を含み、
複数の通信機のそれぞれは、他の通信機である他機から代行通信の要求を受けた場合には、中継サーバとの協働により、代行通信用の経路設定を行い、中継サーバは、経路設定情報をもとに、通信機自身のための通信量と、代行通信のための通信量とを分けて管理するように構成されている車両用通信システム。
［方法（１）］
セルラー通信と車車間通信とを実施可能に構成された、それぞれ異なる車両で使用される複数の通信機（１）と、通信機とアプリケーションサーバとのデータ通信を中継するとともに、通信機ごとのデータ通信量を管理する中継サーバ（５）と、が協働して実施する通信量管理方法であって、
通信機が、他の通信機である他機からの依頼に基づき、代行通信として、他機とアプリケーションサーバとのデータ通信を中継することと、
通信機が、代行通信を行う場合には、代行通信のためのポートとして、代行通信の依頼元としての他機または自機が、代行通信ではない通常の通信時には使用していないポートを用いてセルラー通信を実施することと、
通信機が代行通信のためのポートの番号を中継サーバに通知することと、
中継サーバが、通信に使用されているポートの番号に基づいて、代行通信のデータ量を代行通信ではないデータ通信の量とは分けて管理することと、を含む通信量管理方法。

＜付言（２）＞
本開示に記載の装置、システム、並びにそれらの手法は、コンピュータプログラムにより具体化された一つ乃至は複数の機能を実行するようにプログラムされたプロセッサを構成する専用コンピュータにより、実現されてもよい。また、本開示に記載の装置及びその手法は、専用ハードウェア論理回路を用いて実現されてもよい。さらに、本開示に記載の装置及びその手法は、コンピュータプログラムを実行するプロセッサと一つ以上のハードウェア論理回路との組み合わせにより構成された一つ以上の専用コンピュータにより、実現されてもよい。また、コンピュータプログラムは、コンピュータにより実行されるインストラクションとして、コンピュータ読み取り可能な非遷移有形記録媒体に記憶されていてもよい。つまり、例えば車載通信機１等が提供する手段および／または機能は、実体的なメモリ装置に記録されたソフトウェアおよびそれを実行するコンピュータ、ソフトウェアのみ、ハードウェアのみ、あるいはそれらの組み合わせによって提供できる。車載通信機１は、ＣＰＵ、ＭＰＵ、ＧＰＵ、及びＤＦＰ（Data Flow Processor）のうちの何れか１つを用いて又は複数を組み合わせて用いて実現されていてもよい。

車載通信機１が備える機能の一部は、システムオンチップ（ＳｏＣ：System-on-Chip）、ＦＰＧＡ（Field-Programmable Gate Array）や、ＡＳＩＣ（Application Specific Integrated Circuit）を用いて実現されていても良い。各種プログラムは、非遷移的実体的記録媒体（non- transitory tangible storage medium）に格納されていればよい。プログラムの保存媒体としては、ＨＤＤ（Hard-disk Drive）やＳＳＤ（Solid State Drive）、フラッシュメモリ、ＳＤ（Secure Digital）カード等、多様な記憶媒体を採用可能である。中継サーバ５の構成についても同様である。車両用通信システム１００を構成する各装置が実施する通信制御方法や、コンピュータを車載通信機１として機能させるためのプログラム、このプログラムを記録した半導体メモリ等の非遷移的実態的記録媒体等の形態も本開示の範囲に含まれる。コンピュータを中継サーバ５として機能させるためのプログラム、このプログラムを記録した半導体メモリ等の非遷移的実態的記録媒体等の形態も本開示の範囲に含まれる。

１ 車載通信機（車両用通信機）、１Ａ 第１通信機、１Ｂ 第２通信機、２ セルラー基地局、３ コアネットワーク、４ アプリサーバ、５ 中継サーバ、６ Ｗｉ－Ｆｉ基地局、８ ＥＣＵ、１１ 処理部、１２ ＲＡＭ、１３ ストレージ、５２ プロセッサ、５３ ＲＡＭ、５４ ストレージ、８１ アプリケーション、８２ ＡＣＰクライアント、Ｆ１ 車内通信部、Ｆ２ 無線通信部、Ｆ３ 通信制御部、Ｆ２１ セルラー通信部、Ｆ２２ Ｗｉ－Ｆｉ通信部、Ｆ２３ 車車間通信部、Ｆ３１ 経路特性取得部、Ｍ１ 指標保持部、Ｆ３２ 余力評価部、Ｆ３３ 経路設定部、Ｆ３４ ポート管理部、Ｆ３５ 代行処理部

Claims (11)

1. セルラー基地局を介した無線通信であるセルラー通信と車車間通信とを実施可能に構成された、それぞれ異なる車両で使用される複数の通信機（１）と、
   前記通信機とアプリケーションサーバとのデータ通信を中継するとともに、前記通信機ごとのデータ通信量を管理する中継サーバ（５）と、を含み、
   複数の前記通信機のそれぞれは、
   他の前記通信機である他機からの依頼に基づき、代行通信として、前記他機と前記アプリケーションサーバとのデータ通信を中継する代行処理部（Ｆ３５）を備え、
   前記代行通信を行う場合には、前記代行通信のためのポートとして、前記代行通信の依頼元としての前記他機または自機が、前記代行通信ではない通常の通信時には使用していないポートを用いて前記セルラー通信を実施することと、
   前記代行通信のためのポートの番号を前記中継サーバに通知することと、を実施し、
   前記中継サーバは、
   通信に使用されているポートの番号に基づいて、前記代行通信のデータ量を前記代行通信ではないデータ通信の量とは分けて管理するように構成されている車両用通信システム。
2. 請求項１に記載の車両用通信システムであって、
   前記代行処理部は、前記他機からの依頼に基づき前記代行通信を行う場合には、
   前記他機から転送用のデータを前記車車間通信で受信することと、
   前記他機から前記車車間通信で受信したデータを、前記代行通信のためのポートを用いた前記セルラー通信により、前記アプリケーションサーバに送信することと、を実施するように構成されている車両用通信システム。
3. 請求項１又は２に記載の車両用通信システムであって、
   前記代行処理部は、前記他機からの要求に基づき前記代行通信を行う場合には、
   前記アプリケーションサーバから転送用のデータを、前記代行通信のためのポートを用いた前記セルラー通信で受信することと、
   前記セルラー通信で前記アプリケーションサーバから受信したデータを、前記車車間通信により、前記依頼元としての前記他機に転送することと、を実施するように構成されている車両用通信システム。
4. 請求項１から３の何れか１項に記載の車両用通信システムであって、
   前記代行処理部は、前記依頼元が未使用のポートを前記代行通信のためのポートとして使用するように構成されている車両用通信システム。
5. 請求項１から４の何れか１項に記載の車両用通信システムであって、
   前記車車間通信でやり取りされるデータは、送信元及び宛先のＭＡＣアドレスを示すデータフィールドであるＭＡＣヘッダと、送信元及び宛先のＩＰアドレスを示すデータフィールドであるＩＰヘッダを含み、
   前記代行処理部は、ＩＰヘッダを書き換えずに、ＭＡＣヘッダの書き換えにより、前記代行通信としての転送処理を実施するように構成されている車両用通信システム。
6. 請求項１から５の何れか１項に記載の車両用通信システムであって、
   複数の前記通信機は、前記車車間通信によって、自機が利用可能なセルラー回線での通信状態を互いに共有するように構成されており、
   前記代行処理部は、自機が利用可能なセルラー回線の通信状態と、前記他機が利用可能なセルラー回線の通信状態とを比較することで、当該他機に対して前記代行通信を依頼するか否かを決定するように構成されている車両用通信システム。
7. 請求項６に記載の車両用通信システムであって、
   前記通信状態には、通信速度が含まれており、
   前記代行処理部は、自機が利用可能なセルラー回線の通信速度よりも、前記他機が利用可能なセルラー回線の通信速度のほうが所定値以上大きい場合に、当該他機に対して前記代行通信を依頼するように構成されている車両用通信システム。
8. 請求項１から７の何れか１項に記載の車両用通信システムであって、
   前記代行処理部は、他機から前記代行通信の依頼を受け付けた場合、自機が利用可能なセルラー回線での通信状態に基づき、前記代行通信を引き受けるか否かを決定し、
   その決定結果を前記依頼元に無線送信するように構成されている車両用通信システム。
9. 請求項８に記載の車両用通信システムであって、
   前記依頼元は、前記代行通信で送信したいデータ量を、依頼先に通知し、
   前記代行処理部は、自機が利用可能なセルラー回線の通信状態をもとに、前記依頼元から通知されたデータ量を所定時間以内に送信できるか否かを判断し、
   前記依頼元から通知されたデータ量を前記所定時間以内に送信できないと判断した場合には、前記代行通信を引き受けないことを示す回答を前記依頼元に送信する車両用通信システム。
10. 車両で使用される通信機とアプリケーションサーバとのデータ通信を中継するとともに、前記通信機ごとのデータ通信量を管理する中継サーバであって、
    前記通信機が他の前記通信機である他機と前記アプリケーションサーバとのデータ通信を代行する場合には、前記通信機から代行通信のためのポートの番号を取得することと、
    データ通信に使用されているポートの番号に基づいて、前記代行通信のデータ量を前記代行通信ではないデータ通信の量とは分けて管理するように構成されている中継サーバ。
11. セルラー基地局を介した無線通信であるセルラー通信と車車間通信とを実施可能に構成された車両用通信機であって、
    前記車両用通信機と任意の外部装置との通信は、前記車両用通信機の通信量を管理する機能を備えた所定の中継サーバを介して行われるように構成されており、
    他の前記車両用通信機である他機からの依頼に基づき、代行通信として、前記車車間通信と前記セルラー通信を併用して、前記他機と前記外部装置とのデータ通信を中継する代行処理部（Ｆ３５）を備え、
    前記代行処理部は、前記代行通信を行う場合には、前記代行通信のためのポートとして、前記代行通信の依頼元としての前記他機または自機が、前記代行通信ではない通常の通信時には使用していないポートを用いて前記外部装置と通信することと、
    前記代行通信のためのポートの番号を前記中継サーバに通知することと、を実施するように構成されている車両用通信機。

Images