WO2022118793A1

WO2022118793A1 - 通信制御装置、通信制御方法、及び中継サーバ

Info

Publication number: WO2022118793A1
Application number: PCT/JP2021/043625
Authority: WO
Inventors: 正幸星野; 佳祐生島
Original assignee: 株式会社デンソー
Priority date: 2020-12-03
Filing date: 2021-11-29
Publication date: 2022-06-09
Also published as: JP7468321B2; CN116615892A; US20230300226A1; EP4258613A1; EP4258613A4; JP2022088980A

Abstract

車両（Ｈｖ）が備える複数のアプリ（８１）はそれぞれ、対応するサーバ（４）との通信の必要性が生じた場合、無線通信装置（７）に対してアプリＩＤや通信条件を含む通信開始要求を出力する。無線通信装置（７）は、アプリ（８１）から通知された通信条件を充足する通信回線が存在するか否かを、通信回線毎の空き容量や通信速度などをもとに判定する。通信条件を充足する回線が存在する場合には当該アプリ（８１）用のソースポートを確保するとともに、ルーティング設定を行う。そして、通信要求元のアプリ（８１）に対してソースポート番号を含む通信許可応答を返送する。一方、通信条件を充足する回線が存在しない場合にアプリ（８１）に対して割当不可応答を返送する。

Description

通信制御装置、通信制御方法、及び中継サーバ

関連出願の相互参照

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

　本開示は、車両で使用されるアプリケーションとサーバとの通信を中継する技術に関する。

　特許文献１には、車両が備える複数のＥＣＵ（Electronic Control Unit）が、通信装置を介して、車両外部に配されているサーバとデータ通信を行う構成が開示されている。また、特許文献１に開示の通信装置は、通信装置からサーバへのデータの送信の効率化を図るために、予めＥＣＵ毎に設定されている優先度に基づいてデータの送信順を調整する構成が開示されている。具体的には、優先度の高いＥＣＵから入力されたデータを、優先度が相対的に低いＥＣＵからのデータよりも先にサーバに送信する。

特開２００６－８８８２９号公報

　特許文献１には、予め設定された優先度に基づいてアプリケーション毎のパケット送信順を調整する構成は開示されている。しかしながら、特許文献１には、アプリケーション毎に通信回線／通信帯域の割り当て状態を動的に制御する技術については何ら言及されていない。

　アプリケーション毎の通信回線／通信帯域の割当状態を動的に制御する方法としては、例えば、アプリケーション毎に予め優先度を設定しておき、当該優先度を用いてアプリケーション毎の割当状態を調整する方法が考えられる。

　しかしながら、今後は、車両に搭載されるアプリケーションは動的に変更されうる。また、車両毎に搭載されるアプリケーションの組み合わせは異なることが想定される。故に、無線通信を制御する通信制御装置に、アプリケーション毎の優先順位を事前に登録しておくことは難しい。加えて、アプリケーション毎に、例えば要求する通信速度や、レイテンシ、セキュリティレベル、許容可能な通信料の上限値などといった、データ通信に係る特性や設定（つまり通信条件）は異なりうる。そのため、優先度という１つのパラメータでは、アプリケーション毎の通信回線の割当状態を適正に制御することは難しい。

　本開示は、この事情に基づいて成されたものであり、その目的とするところは、アプリケーション毎の通信特性に応じた通信経路を設定可能な通信制御装置、通信制御方法、及び中継サーバを提供することにある。

　その目的を達成するための通信制御装置は、少なくとも１つの通信回線を利用可能に構成されてあって、車両で実行される複数のアプリケーションのそれぞれと外部装置との通信回線を用いた通信を制御する通信制御装置であって、アプリケーションから外部装置とのデータ通信の開始要求を受け付ける要求受付部と、開始要求の要求元であるアプリケーションから、外部装置とのデータ通信に係る条件を示す通信条件を取得する通信条件取得部と、通信条件に応じたデータ通信を実施可能であるか否かを、通信回線の状態、及び、通信実行中の他のアプリケーションである先行アプリの通信条件の少なくとも何れか一方に基づいて判断する通信可否判断部と、通信可否判断部によって要求元と外部装置との通信が可能であると判定されたことに基づき、要求元から外部装置までの通信経路を設定する処理を行う経路設定部と、通信可否判断部の判断結果を示す情報を要求元に返送する応答部と、を備え、通信経路の設定は、要求元へのソースポート番号の割当を含み、応答部は、通信可否判断部によってデータ通信は可能であると判定された場合には、ソースポート番号を要求元に通知するように構成されている。

　上記構成によれば、予め設定された優先度ではなく、通信開始の要求元としてのアプリケーションから通知される通信条件と、通信回線の状態と、先行アプリの通信条件とに基づいて、要求元の通信条件に応じたデータ通信が実施可能か否かを判断する。また、通信可能であると判定した場合には、要求元に対する通信経路を要求元の通信条件に基づいて設定する。このような構成によれば、車両で使用されるアプリケーションが変更されたり、車両毎に搭載アプリケーションの組み合わせが異なっていたりしても、アプリケーション毎の通信特性に応じた通信経路を設定可能となる。

　また上記目的を達成するための通信制御方法は、少なくとも１つの通信回線を用いて実行される、車両で使用される少なくとも１つのアプリケーションと車両の外部に存在する通信装置である外部装置との通信の実施状況を制御する通信制御方法であって、アプリケーションが、車両で使用される無線通信装置に向けて、外部装置とのデータ通信の開始要求を送信することと、無線通信装置が、開始要求の要求元であるアプリケーションから、外部装置とのデータ通信に係る条件を示す通信条件を取得することと、無線通信装置が、通信回線の状態、及び、通信実行中の他のアプリケーションである先行アプリの通信条件の少なくとも何れか一方に基づいて、要求元の通信条件に応じた通信を実施可能であるか否かを判断することと、要求元と外部装置との通信が可能であると判定されたことに基づき、無線通信装置が、要求元のためのソースポート番号を確保するとともに、要求元から外部装置までの通信経路を設定することと、無線通信装置が、要求元から外部装置までの通信経路に関する情報として少なくともソースポート番号を含む経路情報を、要求元に対して通知することと、要求元は、ソースポート番号を用いて外部装置と暗号通信を実行することと、を含む。

　さらに上記目的を達成するための中継サーバは、車両で使用されるアプリケーションと、アプリケーションと連携して動作する外部装置とのデータ通信を中継する中継サーバであって、アプリケーションとの通信は、車両に搭載されている無線通信装置を介して通信するように構成されており、無線通信装置は、所定の複数の通信回線の中からアプリケーションが指定する通信条件を充足する通信回線を選択的に用いるように構成されており、無線通信装置から、アプリケーションに割り当てているソースポート番号を含む通信経路情報を、アプリケーションの識別情報であるアプリ識別子と対応付けて取得する経路情報取得部と、アプリケーションに割り当てられているソースポート番号を用いて送受信された通信回線毎のデータ量を、アプリ識別子またはソースポート番号と紐付けて管理する通信量管理部と、を備える。

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

車両用通信システムの全体構成を説明するための図である。ＡＣＰサーバの構成を説明するためのブロック図である。車載通信システムの構成を示すブロック図である。無線通信装置の機能を説明するためのブロック図である。通信条件に含まれうる項目の一例を示す図である。通信条件に適合する通信経路を割当可能な場合のシーケンス図である。通信条件に適合する通信経路を割当不能な場合のシーケンス図である。経路割当処理についてのフローチャートである。許容ＲＴＴを用いて割当回線を選定する処理についてのフローチャートである。許容待ち時間を用いて先行アプリの通信を維持するか否かを判断する処理についてのフローチャートである。データ保持可能時間を用いて先行アプリの通信を維持するか否かを判断する処理についてのフローチャートである。データ欠損フラグを用いて先行アプリの通信を維持するか否かを判断する処理についてのフローチャートである。通信量管理部の作動を説明するための図である。

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

　＜全体構成＞
　図１に示すように車両用通信システム１００は、車載通信システム１、セルラー基地局２、コアネットワーク３、サーバ４、及びＡＣＰサーバ５を含む。また、車両用通信システム１００は、任意の要素としてＷｉ－Ｆｉ基地局６を含みうる。なお、図１にはセルラー基地局２、Ｗｉ－Ｆｉ基地局６を１つずつしか示していないが、これらは複数存在しうる。

　車載通信システム１は、車両Ｈｖに構築されている通信システムである。車載通信システム１は、以下の説明の通り、複数のアプリケーション（以降、アプリ８１）を備え、各アプリ８１に対応する複数のサーバ４のそれぞれとデータ通信を実施する。サーバ４が外部装置に相当する。

　車載通信システム１を搭載した車両Ｈｖもまた、図１には１つしか示していないが、システム全体としては複数存在しうる。各車両Ｈｖに搭載されているＥＣＵ（Electronic Control Unit）の仕様や、ＥＣＵにインストールされているアプリ８１のバージョン等は異なりうる。ＥＣＵの仕様には、ＯＳ（Operating System）や、車両電源オフ時のアプリ８１の起動状態などが含まれうる。

　車載通信システム１はセルラー回線及びＷｉ－Ｆｉ回線といった、通信方式が異なる複数種類の無線通信サービス（換言すれば通信回線）を利用可能に構成されている。ここでのセルラー回線とは、セルラー基地局２を介した通信回線、換言すればＬＴＥ／４Ｇ／５Ｇ規格に準拠した通信回線を指す。また、Ｗｉ－Ｆｉ回線とは、Ｗｉ－Ｆｉ基地局６を経由する通信回線を指す。Ｗｉ－Ｆｉ回線は、Ｗｉ－Ｆｉ基地局６の通信エリア内に車両Ｈｖが存在する場合に実施可能となる。

　セルラー基地局２は、車載通信システム１とＬＴＥ等の規格に準拠した無線信号を送受信する設備である。セルラー基地局２は、ｅＮＢ（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）の制御などの機能を提供する。コアネットワーク３は、例えばＩＰネットワークや携帯電話網等の、通信事業者によって提供される公衆通信ネットワークを含みうる。

　コアネットワーク３は、例えば、ＭＭＥや、Ｓ－ＧＷ、Ｐ－ＧＷ、ＰＣＲＦなどを含む。ＭＭＥは、Mobility Management Entityの略であって、セル内のＵＥの管理や、セルラー基地局２の制御を担当する。ＭＭＥは、例えばセルラー基地局２とＳ－ＧＷ（Serving Gateway）との間における制御信号のゲートウェイとしての役割を担う。Ｓ－ＧＷは、ＵＥからのデータのゲートウェイに相当する構成である。Ｐ－ＧＷは、Packet Data Network Gatewayの略であって、インターネットなどのＰＤＮ（Packet Data Network）に接続するためのゲートウェイに相当する。Ｐ－ＧＷは、ＩＰアドレスの割当などや、Ｓ－ＧＷへのパケット転送を実施する。ＰＣＲＦは、Policy and Charging Rules Functionの略であって、ユーザデータの転送のＱｏＳ及び課金のための制御を行う論理ノードである。ＰＣＲＦは、ネットワークポリシーや課金のルールをもつデータベースを含む。

　その他、コアネットワーク３は、ＨＬＲ（Home Location Register）／ＨＳＳ（Home Subscriber Server）などを含んでいてもよい。コアネットワーク３を構成する装置の名称や組み合わせなどは、例えば５Ｇなど、車両用通信システム１００が採用する通信規格に対応するように適宜変更可能である。また、コアネットワーク３における機能配置は適宜変更可能である。例えばＰＣＲＦが提供する機能は別の装置が備えていても良い。

　以降では、例えばＭＭＥやＳ－ＧＷなどのコアネットワーク３を構成する各装置、及び、セルラー基地局２を区別しない場合には、ネットワーク側装置とも記載する。なお、例えばＰＣＲＦなどの通信設備は、ＡＰＮ（Access Point Name）毎又は電気通信事業者毎に配置されうる。ＡＰＮは、１つの側面において通信サービスの識別子である。ＡＰＮには、通信サービスを提供する通信事業者（いわゆるキャリア）が紐付いている。コアネットワーク３内においてデータの転送経路はＡＰＮ毎に異なるものとなる。

　サーバ４は、車両とデータ通信を実行することで、所定のサービスを提供するための処理を実行する設備である。車両Ｈｖには各サーバ４に対応するアプリ８１がインストールされている。図１に示す各サーバ４は、車両Ｈｖで使用される複数のアプリ８１のそれぞれに対応する処理を実行する、アプリケーションサーバに相当する。

　ＡＣＰサーバ５は、車両Ｈｖとサーバ４との通信を中継するサーバである。ＡＣＰサーバ５は中継サーバと呼ぶこともできる。部材名称中のＡＣＰは、Automotive Communication Platformの略である。ＡＣＰサーバ５は、車両Ｈｖとサーバ４との通信接続制御と、通信状態の監視を統合的に行う。

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

　ＡＣＰサーバ５は、プロセッサ５２がストレージ５４に保存されている中継サーバプログラムを実行することにより発現される機能モジュールとして、例えば経路管理部Ｇ１、中継処理部Ｇ２、及び通信量管理部Ｇ３を備える。経路管理部Ｇ１は、無線通信装置７から各種サーバ４までの通信経路情報を管理する構成である。ここでの通信経路情報には、例えば、送信元ＩＰアドレスや、ソースポート番号、宛先ＩＰアドレス、宛先ポート番号、プロトコル番号など、いわゆる５－ｔａｐｌｅを含む。

　ソースポート番号は、無線通信装置７によってアプリ８１毎に固有の番号が割り当てられる。ポート番号は、例えば１６ビットの数値によって表現されうる。各ソースポート番号は、アプリ８１毎の識別情報であるアプリＩＤ（アプリ識別子）と対応付けられて保存される。ソースポート番号は送信元ポート番号と呼ぶこともできる。経路管理部Ｇ１は、無線通信装置７やサーバ４と制御信号をやり取りすることで通信経路情報を取得する。経路管理部Ｇ１としてのＡＣＰサーバ５は、アプリ８１に割り当てられているソースポート番号など、通信上必要な情報をサーバ４に通知する。経路管理部Ｇ１が経路情報取得部に相当する。

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

　通信量管理部Ｇ３は、アプリ８１毎のソースポート番号とアプリＩＤとを用いて、アプリ８１毎の通信量を管理する。すなわち、同一のソースポートを用いてやり取りされるデータの量を、通信に使用された回線毎に区別して管理する。アプリ８１とソースポートとは１対１で対応するため、或るソースポートを経由するデータ通信の総量は、当該ソースポートに対応付けられているアプリ８１の通信量に相当する。また、アプリ８１の通信量を通信回線毎に区別して管理する構成によれば、別途後述するようにアプリ８１毎の通信料も算出可能となる。

　その他、ＡＣＰサーバ５は、通信の中継機能だけでなく、例えばサーバ４や車両Ｈｖを認証する処理を実行するように構成されていても良い。なお、ＡＣＰサーバ５が提供する機能は、各サーバ４が有していてもよい。ＡＣＰサーバ５は、サーバ４と統合されていても良い。ＡＣＰサーバ５は、車両Ｈｖの外部に設けられたサーバ４の一種と解することもできる。加えて、ＡＣＰサーバ５は任意の要素であって省略されても良い。つまり、車両Ｈｖとサーバ４とはＡＣＰサーバ５を介さずにデータ通信を実施するように構成されていても良い。

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

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

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

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

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

　＜車載通信システム１の構成について＞
　車載通信システム１は、図３に示すように無線通信装置７と複数のＥＣＵ８を含む。無線通信装置７は、上述した無線通信機能を提供する装置であって、コアネットワーク３にとってのＵＥに相当する。無線通信装置７は、少なくとも１つの加入者識別モジュール（以降、ＳＩＭ：Subscriber Identity Module）７５を備える。これにより無線通信装置７は、当該ＳＩＭ７５に対応する少なくとも１つのＡＰＮを用いたデータ通信を実施可能に構成されている。ＳＩＭ７５に対応するＡＰＮとは、当該ＳＩＭ７５の情報に基づき利用可能なＡＰＮを指す。

　本実施形態の無線通信装置７は一例として、それぞれＡＰＮが異なる複数のセルラー回線を利用可能に構成されている。ＡＰＮが異なれば、仮に通信相手となるサーバ４が同一であっても、当該サーバ４までデータが流れる経路は、実体的、又は、仮想的に相違する。複数のセルラー回線は、それぞれ異なる通信経路を実現する。つまり、無線通信装置７は、複数の通信経路を用いてサーバ４とデータ通信可能に構成されている。

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

　各ＥＣＵ８は、車両内に構築された通信ネットワークである車両内ネットワークＮｗを介して無線通信装置７と接続されている。車両内ネットワークＮｗに接続された装置同士は相互に通信可能である。つまり、無線通信装置７は、複数のＥＣＵ８のそれぞれと相互通信可能に構成されている。なお、車載通信システム１が備える特定の装置同士は、車両内ネットワークＮｗを介することなく直接的に通信可能に構成されていてもよい。図３において車両内ネットワークＮｗはバス型に構成されているが、これに限らない。ネットワークトポロジは、メッシュ型や、スター型、リング型などであってもよい。車両内ネットワークＮｗの規格としては、例えばController Area Network（ＣＡＮは登録商標）や、イーサネット（登録商標）、ＦｌｅｘＲａｙ（登録商標）など、多様な規格を採用可能である。

　各ＥＣＵ８は、ＣＰＵなどの演算コアとＲＡＭなどのメモリとを備えるコンピュータとして構成されており、各ＥＣＵ８に割り当てられたプログラムを実行することで、当該プログラムに応じた処理を実行する。以降では複数のＥＣＵ８を区別して記載する場合には、ＥＣＵ８Ａ、ＥＣＵ８Ｂ、ＥＣＵ８Ｃとも記載する。なお、車両Ｈｖが備えるＥＣＵ８は、３つに限定されない。１個や２個であってもよいし、４個以上であってもよい。

　複数のＥＣＵ８はそれぞれ異なる機能を提供するアプリ８１を備える。すなわち、ＥＣＵ８Ａ～８Ｃは、それぞれアプリ８１Ａ～８１Ｃを備える。また、各ＥＣＵ８はＡＣＰクライアント８２を備える。

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

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

　アプリ８１Ｂは、例えば、ディスプレイを含むＨＭＩ（Human Machine Interface）システムと連携し、乗員によって設定された目的地までの経路案内を実施するアプリである。アプリ８１Ｂは、例えばサーバ４Ｂから現在位置や走行予定経路に応じた範囲の地図をダウンロードするとともに、当該地図データを用いて経路案内処理を実施する。このようなアプリ８１Ｂは地図データに基づく経路案内等を行う地図系アプリケーションに相当する。アプリ８１Ｃは、オーディオ機能を提供するアプリ、すなわち音楽アプリケーションである。アプリ８１Ｃは、例えばユーザから指定された音楽データ、或いは、アプリ８１Ｃ又はサーバ４Ｃが選定した音楽データをサーバ４Ｃから取得してストリーミング再生する処理を行う。

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

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

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

　各アプリ８１は、当該アプリ８１に対応するサーバ４を宛先とする送信用データを無線通信装置７に出力するとともに、対応するサーバ４からのデータを無線通信装置７から取得する。また、各アプリ８１は、サーバ４へ向けた送信用データの発生等に伴って、ＡＣＰクライアント８２に向けて通信開始要求を出力する。通信開始要求は、例えば所定の電気信号、メッセージ、又は通信フレームに相当する。通信開始要求は、アプリＩＤを含む。また、通信開始要求は、サーバ４とのデータ通信に係る条件を示す通信条件を含んでいても良い。

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

　なお、ＡＣＰクライアント８２は任意の要素であって省略されても良い。また、ＡＣＰクライアント８２の機能はアプリ８１自身が備えていても良い。ＡＣＰクライアント８２はアプリ８１の一部として構成されていても良い。加えて、ＡＣＰクライアント８２は無線通信装置７の一部として構成されていても良い。各構成の機能配置は適宜変更可能である。ＡＣＰクライアント８２は、対応するアプリ８１の通信要求及び通信条件を管理する機能を有する。通信条件の詳細については別途後述する。

　＜無線通信装置７の構成について＞
　無線通信装置７は、車両Ｈｖに搭載される複数のアプリ８１の要求に従ってサーバ４Ａ～４Ｃにデータ送信を行うと共に、サーバ４Ａ～４Ｃから送信されたデータの受信を行う。このような無線通信装置７は、各ＥＣＵ８が所定の通信相手としてのサーバ４と無線通信するための無線インターフェースに相当する。車両Ｈｖは無線通信装置７の搭載により、インターネットに接続可能なコネクテッドカーとなる。無線通信装置７は、ＤＣＭ（Data Communication Module）やＴＣＵ（Telematics Control Unit）などと呼ぶこともできる。無線通信装置７は、例えばインストゥルメントパネル内に収容されている。なお、無線通信装置７は、ユーザが取り外し可能に構成されていてもよい。また、無線通信装置７は、ユーザによって車室内に持ち込まれた、スマートフォン等の携帯端末であってもよい。

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

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

　通信インターフェース７４は、車両内ネットワークＮｗを介してＥＣＵ８と通信するための回路モジュールである。通信インターフェース７４は、アナログ回路素子やＩＣ、車両内ネットワークＮｗの通信規格に準拠したＰＨＹチップなどを用いて実現されている。通信インターフェース７４には、例えばＥＣＵ８から入力された送信用データのほか、車速センサが検出した車速データなど、多様なデータが入力される。ここでの送信用データとは、サーバ４向けの通信トラフィック（換言すればデータ）に相当する。

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

　本実施形態では一例として、無線通信装置７が備えるＳＩＭ７５は、２つのＡＰＮが利用可能に構成されている。換言すればＳＩＭ５５は、２つのセルラー回線が利用可能なＳＩＭである。以降では無線通信装置７がＳＩＭ７５を用いて利用可能な２つセルラー回線のことを第１回線、第２回線と称する。また、第１、第２回線のうち、相対的にＱｏＳが低いセルラー回線のことを低ＱｏＳセルラー回線と称するとともに、相対的にＱｏＳが高いセルラー回線のことを高ＱｏＳセルラー回線とも称する。

　ＱｏＳが低いセルラー回線とは、例えば、コアネットワーク３内におけるデータ転送の優先順位が低い、あるいは、帯域保証がされないなどの通信設定（換言すればポリシー条件）に由来して、通信速度が遅い／通信遅延が起きやすいセルラー回線に相当する。低ＱｏＳセルラー回線は例えばプローブデータのアップロードなど、即時性があまり要求されないデータ通信に適したセルラー回線と解する事ができる。一方、ＱｏＳが高いセルラー回線とは、通信遅延が起きにくいセルラー回線である。高ＱｏＳセルラー回線は、車両Ｈｖの遠隔制御等といった高い即時性が要求されるデータ通信に適したセルラー回線と解することができる。

　なお、ここでは一例としてＳＩＭ７５は、品質や伝送容量等の通信特性が異なる複数のセルラー回線を利用可能に設定されているものとするが、これに限らない。ＳＩＭ７５は、利用可能なセルラー回線は１つだけであってもよい。ただし、ＥＣＵ８からの多様な通信要件に柔軟に対応するために、無線通信装置７は、複数のセルラー回線を利用可能に構成されていることが好ましい。また、無線通信装置７は複数のＳＩＭ７５を備えていても良い。

　＜無線通信装置７の機能について＞
　ここでは無線通信装置７の機能及び作動について説明する。無線通信装置７は、図４に示すように機能ブロックとして、車内通信部Ｆ１、無線通信部Ｆ２、及び通信制御部Ｆ３を備える。無線通信部Ｆ２は、セルラー通信部Ｆ２１とＷｉ－Ｆｉ通信部Ｆ２２を備える。通信制御部Ｆ３が通信制御装置に相当する。

　車内通信部Ｆ１は、各ＥＣＵ８が出力した送信用データを受け取り、無線通信部Ｆ２へ出力するとともに、無線通信部Ｆ２が受信したデータを、転送すべきＥＣＵ８に向けて出力する構成である。例えば車内通信部Ｆ１は、各ＥＣＵ８から多重化されて入力されたデータを、所定の方式で分離することで、本来のデータを取得する。なお、車内通信部Ｆ１は、各ＥＣＵ８から入力されたデータをセルラー基地局２又はＷｉ－Ｆｉ基地局６に無線送信するまで一時的に保持する記憶領域であるバッファを含む。バッファは、ＲＡＭ等の書き換え可能な記憶媒体を用いて実現されればよい。車内通信部Ｆ１は、バッファに滞留しているデータの量やそれらのデータのヘッダに格納された情報を監視する機能も備える。

　バッファに入っているデータは、順次、無線通信部Ｆ２にて取り出され、データの入力元（つまりＥＣＵ８）に応じた通信経路で宛先となるサーバ４に向けて送信される。ＥＣＵ８毎の通信経路の割当状態は、通信制御部Ｆ３によって制御される。なお、通信経路を設定することは、例えば複数のセルラー回線及びＷｉ－Ｆｉといった、複数種類の通信回線のうちの何れを用いるかを選択することを含む。ＥＣＵ８毎、換言すればアプリ８１毎の通信経路の割当方法については別途後述する。

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

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

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

　なお、Ｗｉ－Ｆｉ通信部Ｆ２２は、Ｗｉ－Ｆｉ基地局６から発せられるビーコンを受信することによって、Ｗｉ－Ｆｉ基地局６の存在を認識する。Ｗｉ－Ｆｉ通信部Ｆ２２とＷｉ－Ｆｉ基地局６との通信接続は、通信制御部Ｆ３によって制御される。

　通信制御部Ｆ３は、各セルラー回線の通信状態を監視及び制御する。通信制御部Ｆ３は、所定の接続イベントが生じたことを受けて、ＡＰＮ毎の通信回線を確立する手続きを実行する。通信接続を確立するための手続きには、アタッチ要求の送信やＡＰＮ情報の送信などが含まれる。なお、例えばＭＭＥ３１などのネットワーク側装置は、無線通信装置７から通知されたＡＰＮ等の情報などに基づき、Ｓ－ＧＷ、Ｐ－ＧＷと連携し、契約内容に応じた無線ベアラ及びＰＤＮコネクションを用意する。

　接続イベントとしては、車両電源がオンとなった場合や、車両Ｈｖが備える操作部材に対する所定のユーザ操作に基づき無線通信機能が有効化された場合などを採用可能である。ここでの車両電源は、アクセサリ電源であってもよいし、走行用電源であってもよい。走行用電源は、車両Ｈｖが走行するための電源であって、車両Ｈｖがガソリン車である場合にはイグニッション電源を指す。車両Ｈｖが電気自動車やハイブリッド車である場合、走行用電源とはシステムメインリレーを指す。

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

　さらに、通信制御部Ｆ３は、機能部として、移動管理部Ｆ３１、経路特性取得部Ｆ３２、通信条件取得部Ｆ３３、経路設定部Ｆ３４、及び通信量管理部Ｆ３５を備える。また、通信制御部Ｆ３は、例えばＲＡＭ７２などの書き換え可能な記憶媒体を用いて実現される経路特性保持部Ｍ１を備える。

　移動管理部Ｆ３１は、ＳＩＭ７５で指定されるセルラー回線毎の在圏セルを特定するとともに、セルの移動管理を実施する構成である。移動管理部Ｆ３１は、在圏セルを選択するための指標として、セル毎のＲＳＲＰや、ＲＳＳＩ、ＲＳＲＱなどを算出する。ＲＳＲＰは、Reference Signal Received Powerの略である。ＲＳＳＩはReceived Signal Strength Indicatorの略である。ＲＳＲＱはReference Signal Received Qualityの略である。ＲＳＲＰは、単位リソースエレメント当たりのＲＳの平均受信電力である。ＲＳＳＩは、ＲＳを収容するＯＦＤＭシンボルにおいてＬＴＥシステム帯域全体の電力を測定した値である。ＲＳＲＱは、セル固有の参照信号の受信電力と、受信帯域幅内の総電力との比である。ＲＳＲＱは、大きいほどセルラー基地局２からの信号の受信品質が良いことを示す。

　そして、移動管理部Ｆ３１は、ＳＩＭ７５に対応するセル毎のＲＳＲＰなどの指標に基づき、必要に応じて在圏セルを切り替えるための処理を実施する。或るＳＩＭ７５に対応するセルとは、当該ＳＩＭ７５の情報に基づき接続可能なセルラー基地局、及び、そのセルを指す。移動管理部Ｆ３１が算出した各ＳＩＭ５５に対応するセル毎のＲＳＲＰやＲＳＲＱなどの情報は経路特性保持部Ｍ１に一時的に保持される。経路特性保持部Ｍ１が保持する情報は随時更新される。

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

　また、経路特性取得部Ｆ３２は、セルラー回線毎の通信事業者（いわゆるキャリア）の情報を取得して経路特性保持部Ｍ１に保存しても良い。仮に通信事業者毎に、保有する通信設備等に由来して、通信速度や通信の安定性が異なる場合には、通信事業者の情報が、セルラー回線毎の信頼性、換言すればＱｏＳを評価するための材料となりうる。例えば他の通信事業者が提供する通信設備を利用するＭＶＮＯ（Mobile Virtual Network Operator）が提供する通信回線は、通信設備を保有する通信事業者が提供する通信回線よりも下り通信速度が小さくなる傾向がある。そのように通信事業者の情報はセルラー回線毎の通信速度の優劣の指標となりうる。

　その他、経路特性取得部Ｆ３２は、セルラー回線毎の状態情報として、セルラー回線毎のラウンドトリップタイム（ＲＴＴ：Round-Trip Time）やスループットを逐次評価し、経路特性保持部Ｍ１に保存しても良い。ＲＴＴは、通信相手に信号やデータを発信してから、応答が返ってくるまでにかかる時間、すなわち応答遅延時間である。ＲＴＴは、往復レイテンシとも称される。スループットは、伝送路を通じて単位時間あたりに送受信できるデータ量を表す。スループットは通信速度を示す指標に相当する。なお、スループットは上り通信と下り通信とで別々に評価されてもよい。また、ＲＴＴやレイテンシなどに関し、直近所定時間以内における観測値の平均値を以ってセルラー回線毎の状態を評価しても良い。なお、第１回線が第２回線よりも下り通信速度が大きい傾向にある場合、第１回線はサーバ４へのアップロードよりもサーバ４からのデータ取得を頻繁に行うアプリ８１に適した通信回線と解することができる。また、ＲＴＴが非常に小さい回線は、通話アプリやウェブ会議アプリ、遠隔制御アプリなど、リアルタイム性が重要なアプリ８１に適した回線と解することができる。

　また、経路特性取得部Ｆ３２は、例えば割当周波数やＲＴＴなどのパラメータに基づいて、セルラー回線毎のＱｏＳを評価する。故に、経路特性取得部Ｆ３２は、１つの側面において無線通信サービス毎のＱｏＳを評価するサービス品質評価部と解することができる。経路特性取得部Ｆ３２は、移動管理部Ｆ３１と統合されていても良い。経路特性取得部Ｆ３２が回線特性取得部に相当する。

　通信条件取得部Ｆ３３は、各アプリ８１から通信条件を取得する。通信条件を構成する項目としては例えば図５に示すように、許容待ち時間、許容ＲＴＴ、最小帯域、想定データサイズ、データ保持可能時間、課金対象、データ欠損可否、プライバシー性、緊急性、機密性、及び制御利用性などを採用することができる。

　許容待ち時間は、いつまでに通信を開始する必要が有るか、換言すれば、通信開始まで許容可能な待ち時間を示す。例えば音声認識アプリの許容待ち時間は１秒や３秒などに設定されうる。また、プローブアプリであれば、許容待ち時間は１０分などに設定されうる。ソフト更新アプリの許容待ち時間は、８時間や１日などに設定されうる。緊急通報アプリ等の緊急性の高いアプリにおいては、例えば０秒や１００ミリ秒などに設定されうる。なお、図５中の設定値例の欄に示す「ｄ」、「ｈ」、「ｍｉｎ」、「ｓ」、「ｍｓ」は順に「日」、「時」、「分」、「秒」、「ミリ秒」など、時間の単位を示す。

　許容ＲＴＴは、許容可能な応答遅延時間を示す。例えば遠隔制御アプリであれば許容ＲＴＴは１ミリ秒などに設定されうる。また、通話アプリであれば許容ＲＴＴは１００ミリ秒などに設定されうる。許容ＲＴＴが許容遅延時間に相当する。最小帯域は、確保されるべき通信帯域の最小値を示す。最小帯域は例えば１０Ｍｂｐｓや１Ｍｂｐｓといった通信速度の概念で表現されうる。最小帯域は、想定データサイズや、データ保持可能時間、送信用データの生成頻度などに基づいて通信条件取得部Ｆ３３が算出及び設定しても良い。

　想定データサイズは、アプリ８１とサーバ４との間でやり取りされる１つのデータセットのサイズの想定値を示す。データ保持可能時間は、各アプリ８１が備えるキャッシュ領域に、送信用データを保持できる残り時間を示す。データ保持可能時間は逐次変動しうる。課金対象は、サーバ４との通信に伴う費用（いわゆる通信費）を誰が負担するべきかを示す。課金対象は、例えば、車両メーカ、ユーザ、及びその他に大別されうる。課金対象には通信の受益者が設定されることが好ましい。例えば車両メーカが車両Ｈｖに予めインストールしているアプリ８１など、車両メーカの都合で搭載されているアプリ８１については、課金対象は車両メーカに設定されうる。例えば地図を生成するためのプローブアプリにおいては、課金対象は車両メーカ又は所定の地図プロバイダに設定されうる。アプリ８１が行う通信の課金先を車両メーカとするか否かは車両メーカによって選定されうる。

　データ欠損可否は、データの連続性が重要な通信であるか否か、換言すれば、データの欠損を抑制すべき通信であるか否かを示す。データ欠損可否は、例えばフラグで表現されうる。例えばデータ欠損フラグが１（オン）の場合はデータの欠損を禁止又は低減すべきタイプの通信であることを示し、データ欠損フラグが０（オフ）の場合はデータの欠損等を許容するタイプの通信であることを示す。

　データ欠損が許容されないアプリ８１とは、例えば急ブレーキや急ハンドルなどの運転操作の履歴に基づいて保険料を管理するサービスに係るアプリである。急ブレーキ等の有無は加速度等の連続的なデータをもとに検出される。仮に急ブレーキが行われたタイミングの挙動データが欠損してしまうと、急ブレーキの発生を検出することが困難となり、保険料等を適正に判断できなくなってしまう。また、事故の責任割合を判定する上でも、事故発生前後における車両挙動を連続的に示すデータが重要となる。そのように車両Ｈｖやユーザの経時的な振る舞いを連続的に報告するようなアプリ８１においては、データ欠損フラグはオンに設定されうる。遠隔制御アプリにおいてもデータ欠損フラグはオンに設定されうる。なお、音楽アプリなどでは、データ欠損フラグはオフに設定されうる。

　プライバシー性は、ユーザのプライバシー情報を含む通信であるか否かを示す。プライバシー性は、例えばフラグで表現されうる。例えばプライバシーフラグが１の場合はプライバシー情報を含むタイプの通信であることを示し、プライバシーフラグが０の場合はプライバシー情報を含まないタイプの通信であることを示す。なお、ここでのプライバシー情報とは、個人情報とも言い換えることができる。プライバシー情報には例えばユーザの顔画像や、住所、電話番号、名前などが含まれうる。

　緊急性は、緊急性の高い通信であるか否か、換言すれば、直ちに通信が開始されるべき通信であるか否かを示す。緊急性は、例えばフラグで表現されうる。例えば緊急性フラグが１（オン）の場合は緊急性の高い通信であることを示し、緊急性フラグが０（オフ）の場合は緊急性の低い通信であることを示す。緊急性フラグがオンに設定されるアプリ８１とは緊急通報アプリや、事故データをサーバ４にアップロードするアプリ、盗難検知アプリ等である。なお、盗難検知アプリは、車両Ｈｖの盗難又は不正使用を検知すると、ユーザ又は所定の管理者に通報するアプリである。緊急性の高さは、上述した許容待ち時間に基づいて通信条件取得部Ｆ３３が判断しても良い。例えば許容待ち時間が所定の緊急閾値未満に設定されている場合に、緊急性の高いデータ通信及びアプリ８１であると判定しても良い。緊急閾値は例えば２００ミリ秒などに設定されうる。

　機密性は、機密情報を含む通信であるか否かを示す。機密性は、例えばフラグで表現されうる。例えば機密性フラグが１（オン）の場合は機密情報を含むタイプの通信であることを示し、機密性フラグが０（オフ）の場合は機密情報を含まないタイプの通信であることを示す。機密性フラグは、通信制御部Ｆ３において、例えばデータを複数の経路で分散して送受信するべきか否か、又は、通信経路としてＶＰＮ（Virtual Private Network）などの専用線を使用するべきか否かの判断材料として用いられうる。機密性フラグをオンに設定するアプリ８１とは、例えば、クラウド上に保存されている仕事上の機密書類を閲覧又は編集するアプリ８１や、車両Ｈｖで使用される鍵情報を更新するアプリ８１などである。

　制御利用性は、サーバ４とやり取りされるデータが車両Ｈｖの走行制御に使用されるデータであるか否かを示す。制御利用性は、例えばフラグで表現されうる。例えば制御利用性フラグが１（オン）の場合は、車両制御に使用されるデータを取り扱う通信であることを示し、制御利用性フラグが０（オフ）の場合は、車両制御には関係ない／関係性が薄いデータを取り扱う通信であることを示す。

　なお、通信条件は、上記全ての項目を含む必要はない。上記の項目群は一例であって、通信条件の具体的な項目の組み合わせは適宜変更可能である。また、上記以外にも通信条件は、例えばＷｉ－Ｆｉを積極的に使うことを希望するか、或いは、ユーザへの通信費請求が発生する回線の使用を禁止するかなどのフラグを含んでいても良い。通信条件は、アプリ８１における送信用データの生成頻度などの参考情報を含んでいても良い。

　アプリ８１毎の通信条件は、例えばＡＣＰクライアント８２から所定の制御信号として無線通信装置７に入力される。例えば、通信条件は、車両電源のオンに伴ってＥＣＵ８と無線通信装置７とが通信接続したタイミングで、ＡＣＰクライアント８２から無線通信装置７に向けて通知されてもよい。また、アプリ８１においてサーバ４向けの通信トラフィック（換言すれば送信用データ）が発生したことに基づいて、ＡＣＰクライアント８２から無線通信装置７に通知されても良い。通信条件は通信トラフィック毎に指定されても良い。なお、通信条件は、所定のタイミング又は定期的に無線通信装置７が各アプリ８１に対して通信条件を問い合わせることで取得しても良い。その他、通信条件は、各アプリ８１から無線通信装置７に向けて送信されたデータのヘッダなどに記述されていても良い。

　経路設定部Ｆ３４は、アプリ８１毎の通信条件及びセルラー回線毎の特性に基づいて、各アプリ８１のデータ通信に用いる通信経路を設定する構成である。経路設定部Ｆ３４の詳細は別途後述する。通信経路を構成する要素には、通信回線の種別のほか、割り当てる通信帯域の大きさ（幅）や、割当周波数、通信プロトコルの種別などを含めることができる。通信プロトコルにはＴＣＰ（Transmission Control Protocol）やＵＤＰ（User Datagram Protocol）などが含まれる。

　通信量管理部Ｆ３５は、ＡＣＰサーバ５が備える通信量管理部Ｇ３と同様に、アプリケーション毎のソースポート番号とアプリＩＤとを用いて、アプリ８１毎の通信量を管理する構成である。なお、本実施形態では一例として無線通信装置７とＡＣＰサーバ５の両方でアプリ８１毎の回線別の通信量を管理するものとするがこれに限らない。アプリ８１毎の無線通信装置７とＡＣＰサーバ５の何れか一方で管理されればよい。例えば無線通信装置７は通信量管理部Ｆ３５を備えていなくとも良い。

　＜システム全体の処理の流れ＞
　次に、図６及び図７に示すシーケンス図を用いて、アプリ８１、ＡＣＰクライアント８２、無線通信装置７、ＡＣＰサーバ５、及びサーバ４の相互作用について説明する。図６に示すＥＣＵ８は任意のＥＣＵ８とすることができる。また、図６に示すサーバ４は、図６に示すＥＣＵ８が備えるアプリ８１に対応するサーバ４である。図７に示すアプリ８１及びサーバ４も互いに対応するもの、換言すれば同一のサービスを提供するための構成である。図６はアプリ８１からの要求に対応する通信経路を割り当てることができた場合のシーケンス図であり、図７はアプリ８１からの要求に対応する通信経路を割り当てることができなかった場合のシーケンス図である。以下における処理の実行主体としての無線通信装置７は、通信制御部Ｆ３と読み替えることができる。以下では便宜上、通信開始要求の出力元であるアプリ８１のことを要求元アプリとも記載する。

　まず、無線通信装置７は、所定の接続イベントが生じたタイミングで、ＡＰＮ毎の通信回線を確立する（ステップＳ０１）。無線通信装置７とＡＣＰサーバ５との間の通信接続が確立されている状態においては、無線通信装置７とＡＣＰサーバ５は適宜所定のタイミングで所定の制御信号を送受信することで疎通確認を実施する（ステップＳ０２）。また、ＡＣＰサーバ５とサーバ４も、例えば一定時間おきに所定の制御信号を送受信することで疎通確認を実施する（ステップＳ０３）。すなわち、無線通信装置７はアプリ８１からの通信開始要求に先立って、ＡＣＰサーバ５との通信経路を確保する。

　なお、無線通信装置７の通信制御部Ｆ３は、図６に示す処理フローと並行して、車両Ｈｖの移動に伴うハンドオーバーなどを実行する。また、通信制御部Ｆ３は、図６に示す処理フローと並行して、車両Ｈｖの移動に伴うＷｉ－Ｆｉ基地局６との通信接続～切断を繰り返し実行する。

　その後、アプリ８１において送信用データが発生すると、アプリ８１はＡＣＰクライアント８２に通信開始要求を出力する（ステップＳ１０）。アプリ８１からＡＣＰクライアント８２へと出力される通信開始要求は、例えばアプリＩＤを含む。なお、通信開始要求には、初期通信条件を含んでいても良い。初期通信条件は、通信開始要求が発生した時点での通信条件である。初期通信条件はアプリ８１毎に固定であってもよいし、送信用データの量や内容に応じて可変であってもよい。初期通信条件を固定値とする場合、初期通信条件はデフォルト通信条件と呼ぶこともできる。

　ＡＣＰクライアント８２は、アプリ８１からの通信開始要求を受信すると、当該要求を受け付ける（ステップＳ１１）。具体的には、アプリＩＤと通信条件とを紐付けて所定の記憶領域に一時保存する。通信開始要求の受付状態を示すデータは、例えばＥＣＵ８が備えるＲＡＭなどに保存される。通信条件は、事前にＡＣＰクライアント８２がアプリ８１と通信することで取得しておいても良いし、上述の通り通信開始要求として受信しても良い。また、ＥＣＵ８が備える不揮発性メモリ等にデフォルト通信条件が登録されている場合には、ＡＣＰクライアント８２が当該保存データを参照することで通信条件を取得してもよい。アプリＩＤと通信条件との紐付けが完了すると、アプリＩＤと通信条件とを含む通信開始要求を無線通信装置７に送信する（ステップＳ１２）。

　無線通信装置７は、ＡＣＰクライアント８２からの通信開始要求が入力されたことに基づいて、アプリ８１の通信開始要求を受け付ける（ステップＳ１２Ａ）。ステップＳ１２Ａを実行する無線通信装置７が要求受付部に相当する。そして、ＡＣＰクライアント８２から通知された通信条件を充足する通信経路の割り当てが可能かどうかを、通信回線毎の使用状況や品質などに基づいて判断する（ステップＳ１３）。ステップＳ１３を実行する無線通信装置７が通信可否判断部に相当する。

　なお、上記の通り本実施形態では、アプリ８１のデータ通信を収容する通信回線の候補としては、第１回線と第２回線とがある。また、車両Ｈｖが利用可能なＷｉ－Ｆｉ基地局６の通信範囲内に車両Ｈｖが存在する場合には、Ｗｉ－Ｆｉ回線も採用可能な通信経路の選択肢に含めることができる。通信回線の割当の可否を判断する処理である経路割当処理については別途後述する。

　ステップＳ１３の判断処理の結果、通信条件を充足する通信回線が存在すると判定した場合には、ステップＳ１４を実行する。ステップＳ１４では経路設定部Ｆ３４が要求元アプリ用のソースポートを確保するとともに、ルーティング処理を実行し、アプリ８１からサーバ４までの通信経路を設定する。これにより、送信元ＩＰアドレスや、ソースポート番号、宛先ＩＰアドレス、宛先ポート番号、プロトコルなどが決定される。なお、ソースポートはアプリ８１毎に割り当てられる。つまり、ソースポート番号とアプリＩＤとは１対１の関係を有するように設定される。なお、１つのソースポートに対応するアプリ８１が１つであればよい。他の態様として、１つのアプリに対して複数のソースポート番号が割り当てられても良い。例えば機密性が高いデータを複数の経路で分散して送受信する必要があるアプリ８１に対しては複数のソースポート番号が割り当てられても良い。

　無線通信装置７は、サーバ４までの通信経路の設定が完了すると、ＡＣＰクライアント８２に対して通信開始要求に対する応答として、通信を許可する旨のメッセージである通信許可応答を返送する（ステップＳ１５）。ステップＳ１５及び後述するステップＳ２１を実行する無線通信装置７が応答部に相当する。

　通信許可応答には、例えばソースポート番号が含まれる。また、無線通信装置７は要求応答として、ソースポート番号に加えて、通信の実施権の有無を示すトークンを送信しても良い。トークンは、いま通信してもよいか否かを示す制御信号に相当する。アプリ８１は、無線通信装置７からトークンが入力されている間は通知されているソースポートを用いてサーバ４と通信可能となる。

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

　また、無線通信装置７は、ＡＣＰサーバ５に対して要求元アプリのアプリＩＤをソースポート番号と対応付けて通知する（ステップＳ１６）。無線通信装置７は、ＡＣＰサーバ５に対して、ソースポート番号以外の通信経路情報を通知しても良い。ソースポート番号以外の通信経路情報とは例えば送信元及び宛先ＩＰアドレス、宛先ポート番号などである。また、例えば第１回線、第２回線、及びＷｉ－Ｆｉ回線の何れを用いたかといった、無線通信に使用した回線情報も、通信経路情報に含まれる。

　ＡＣＰクライアント８２は、無線通信装置７からの応答を受領すると、要求管理処理として、アプリＩＤと、ソースポート番号と、トークンの有無を紐付けて保存する（ステップＳ１７）。なお、ＡＣＰクライアント８２は要求応答として、無線通信装置７からソースポート番号以外の通信経路情報も通知された場合には、ソースポート番号とともに、他の通信経路情報も紐付けて保存する。そして、ＡＣＰクライアント８２は、アプリ８１に対して通信開始要求に対する無線通信装置７からの応答の報告として、ソースポート番号やトークンの有無を通知する（ステップＳ１８）。また、ＡＣＰクライアント８２は、無線通信装置７からＩＰアドレスなどの通信経路情報も通知されている場合には、それらの情報をアプリ８１に通知しても良い。

　アプリ８１は、ステップＳ１７においてＡＣＰクライアント８２から応答報告を受信すると、当該応答報告に示されるソースポート番号を用いて、サーバ４と暗号通信を開始する（ステップＳ１９）。例えば、アプリ８１とサーバ４とはＴＬＳ（Transport Layer Security）暗号化通信を実施する。暗号通信の実施パターンとしては多様なパターンを採用可能である。例えばアプリ８１でデータ本体（いわゆるペイロード）を暗号化し、ソースポート番号とともに無線通信装置７に出力し、無線通信装置７側でソースポート番号に対応するヘッダを付加し、パケット化して無線送信する。また、他の態様としては、アプリ８１が暗号化したデータ本体に、５ｔａｐｌｅを含むヘッダを付加して無線通信装置７に出力してもよい。その場合、無線通信装置７は、アプリ８１から入力されたデータセットのヘッダのソースポート番号を参照し、当該ソースポート番号に対応する通信経路で無線出力すればよい。

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

　以上がアプリ８１から通知された通信条件を充足する通信回線が存在する場合のパターンである。ステップＳ１３において通信条件を充足する通信回線が存在しなかった場合には、割当不可であることを示すメッセージである割当不可応答をＡＣＰクライアント８２に返送する（図７　ステップＳ２１参照）。なお、割当不可と判定することは、通知された通信条件に応じた通信を実施不能であると判定することに相当する。割当不可は通信不可と言い換えることができる。

　割当不可応答は、単に要求された通信条件を充足する通信回線が存在しないことだけを示すメッセージであっても良い。割当不可応答は、通信条件を充足する通信を実施可能となるまでの待機時間の見込み値を含んでいても良い。換言すれば、無線通信装置７は割当不可応答として待機時間を指示しても良い。待機時間の見込み値は、他のアプリ８１の通信状況などを元に推定すれば良い。例えば、各アプリ８１に対して通信が必要な残り時間やトラフィックの残量などを問い合わせ、それらの回答結果を元に待機時間の見込み値を算定しても良い。その他、割当不可応答は、現在の状況において実施可能な通信条件を含んでいても良い。例えば現時点で提供可能な通信サービスのＲＴＴや送信可能なデータサイズなどを通知しても良い。

　ＡＣＰクライアント８２は、無線通信装置７からの割当不可応答を受領すると、要求管理処理として、通信開始待ちであることを示すフラグをオンに設定し（ステップＳ２２）、通信開始待ち状態であることをアプリ８１に報告する（ステップＳ２３）。

　さらに、ＡＣＰクライアント８２は、通信開始待ち状態の間は、通信条件に含まれる許容待ち時間やデータ保持可能時間等の諸元を随時更新する（ステップＳ２４）。そして、所定のリトライ周期で、更新された通信条件を含む通信開始要求を無線通信装置７に出力する（ステップＳ２５）。便宜上、ステップＳ２４～Ｓ２５の一連の処理をリトライ処理（ステップＳ３０）とも称する。リトライ処理を実行するたびに、許容待ち時間は減少していくとともに、データ保持可能時間も短くなっていく。なお、ステップＳ２５以降においては、ステップＳ１３と同様に無線通信装置７にて通信状況を充足する通信回線を割り当て可能かどうかの判断がなされる。

　リトライ周期は、例えば５秒や１０秒等、一定値であってもよい。また、リトライ周期は、初期通信条件に示される許容待ち時間の１０％や２０％に相当する値などに設定されてもよい。リトライ周期を初期通信条件に含まれる許容待ち時間に応じた値に設定する構成によれば、アプリ８１の特性に応じた周期で通信開始要求が再送されることとなる。その結果、必要以上に通信の開始を待機する恐れを低減することができる。なお、リトライ周期は、無線通信装置７から通知された待機時間の見込み値に応じた長さに設定されても良い。

　＜経路割当処理について＞
　ここでは図８に示すフローチャートを用いて通信制御部Ｆ３が実行する経路割当処理について説明する。図８に示すフローチャートに対応する経路割当処理は、例えばＥＣＵ８から通信開始要求が入力されたこと（図６　ステップＳ１２）に基づいて開始される。経路割当処理は、図６のステップＳ１３～Ｓ１５、及び、図７のステップＳ１３、Ｓ２１を含む一連の処理に対応する。ここでは一例として経路割当処理はステップＳ１０１～Ｓ１１２を含む。もちろん、経路割当処理が備えるステップ数や処理順序などは適宜変更可能である。

　まずステップＳ１０１では、通信開始要求として、ＡＣＰクライアント８２を介してアプリ８１からアプリＩＤと通信条件とを取得してステップＳ１０２に移る。このようなステップＳ１０１は通信条件取得ステップと呼ぶことができる。

　ステップＳ１０２では通信制御部Ｆ３が、通信回線毎のステータスを確認する。ここでのステータスには、ネットワーク側装置から割り当てられている通信帯域の大きさや、空き容量、割当周波数、現在適用されている通信規格（４Ｇか５Ｇか等）などを含めることができる。また、通信回線毎のステータスには、経路特性取得部Ｆ３２によって逐次評価されている通信回線毎のスループットやＲＴＴなども含めることができる。もちろん、セルラー回線のステータス情報には、ネットワーク側装置から通知されるパケット転送の優先順位や、目標遅延時間、パケットロス率などを含めることができる。また、在圏セル毎のＲＳＲＰや、ＲＳＳＩ、ＲＳＲＱなどもセルラー回線のステータスとして援用可能である。

　その他、通信回線毎のステータスには、その通信回線を提供する通信事業者や、専用回線であるか否かなどといった属性情報を含めることができる。また、Ｗｉ－Ｆｉ回線が利用可能であるか否かも通信状況の概念に含まれる。このようなステップＳ１０２は各通信経路の現況を確認する通信状況確認ステップと呼ぶことができる。ステップＳ１０２が完了するとステップＳ１０３に移る。

　ステップＳ１０３では経路設定部Ｆ３４が、ステップＳ１０１で取得した回線毎のステータスに基づいて、要求元アプリに割り当てる通信回線である割当回線を選択する。割当回線は、アプリ８１から通知された通信条件を充足する通信回線、或いは、通信条件を充足する見込みがある通信回線であることが好ましい。なお、割当回線の選択肢は、ステップＳ１０２実行時点においてＷｉ－Ｆｉ回線が利用可能であるか否かに応じて変更することができる。

　例えば、通信条件として許容待ち時間が所定のＷｉ－Ｆｉ待機時間以上に設定されている場合には、ステップＳ１０２の実行時点でＷｉ－Ｆｉ通信が利用不可である場合であっても、通信費用抑制の観点からＷｉ－Ｆｉ回線を割当回線に設定することが好ましい。Ｗｉ－Ｆｉ待機時間は、例えば１時間や２時間など、当該設定時間が経過するまでにＷｉ－Ｆｉスポットに進入することが期待できる長さに設定されればよい。そのような構成によれば、開始待ち時間が十分に大きいアプリ８１の通信は、いったん保留となり、Ｗｉ－Ｆｉスポットに入ったタイミングで実行される事となる。その結果、通信費用の抑制効果が期待できる。

　また、ステップＳ１０２実行時点においてＷｉ－Ｆｉ通信が利用不可であり、かつ、通信条件として許容待ち時間がＷｉ－Ｆｉ待ち時間未満に設定されている場合には、セルラー回線としての第１回線や第２回線が、割当回線の候補となりうる。例えば開始待ち時間が１０秒や５分、２０分などに設定されている場合、セルラー回線が割当回線の候補となりうる。複数のセルラー回線のなかでは、許容ＲＴＴや、最小帯域、想定データサイズ、課金対象、データ欠損可否など、通信条件を充足する回線が割当回線として選択されることが好ましい。

　その他、通信制御部Ｆ３は、通信事業者やＡＰＮ、割当周波数に基づいて割当回線を選択しても良い。その場合、通信条件には参考情報として、優先的に使用するべき通信事業者やＡＰＮ、割当周波数などを含みうる。無線通信装置７が複数のセルラー回線を利用可能に構成されていることを前提とする場合、通信条件は、複数のセルラー回線の中からアプリ８１が使用するべき回線を決定するための情報を含んでいればよい。

　なお、ステップＳ１０２実行時点においてＷｉ－Ｆｉ通信が利用可能である場合には、Ｗｉ－Ｆｉ回線もまた割当回線の候補となりうる。その場合、Ｗｉ－Ｆｉ回線を割当回線として選択するか否かは、当該Ｗｉ－Ｆｉ回線の通信速度やセキュリティレベル等が通信条件を充足するか否かによる。仮にＷｉ－Ｆｉ回線でも通信条件を充足する場合には、Ｗｉ－Ｆｉ回線が割当回線に設定されうる。

　割当可能な通信回線が複数存在する場合には、それら複数の通信回線のうち、スループットがより大きいものを割当回線として採用してもよい。また、複数の通信回線のうち、ＲＴＴがより小さいものを割当回線に設定してもよい。スループットとＲＴＴのどちらを優先的に用いて要求元アプリ用の回線を選定するかは、要求元アプリが要求する通信の特性、すなわち低遅延性と大容量性のどちらを優先するかによって決定されることが好ましい。低遅延性は許容ＲＴＴに対応し、大容量性は想定データサイズに対応する。その他、無線通信装置７が複数のセルラー回線を利用可能に構成されている場合、どのセルラー回線を優先的に使用するかが無線通信装置７に予め設定されていても良い。その場合、優先順位が高いセルラー回線から通信開始要求の到着順に割り当てていっても良い。セルラー回線毎の優先順位は事前に設定された一定値であってもよいし、ＱｏＳに基づいて動的に変更されても良い。

　なお、ここでは一例として、ステップＳ１０３での判断においては、実際に要求元アプリのデータ通信を収容できるほどの空き容量（つまり余裕）が割当回線にあるかどうかまでは判断しない。すなわち、割当回線は、属性情報やネットワーク側装置から通知されている情報などをもとに選択されうる。

　もちろん、他の態様として、経路設定部Ｆ３４は、ＲＴＴの観測値等のステータスを鑑みて通信条件を充足する回線を割当回線として選定するように構成されていても良い。通信条件を充足する回線は、適合回線と呼ぶことができる。例えば図９に示すように、或る通信回線におけるＲＴＴの観測値が、要求元アプリの許容ＲＴＴよりも小さい場合には（Ｓ３０１　ＹＥＳ）、当該通信回線を割当回線の候補として採用する（Ｓ３０３）。一方、注目している通信回線のＲＴＴの観測値が要求元アプリの許容ＲＴＴ以上である場合には（Ｓ３０１　ＮＯ）、当該通信回線を割当回線の候補から除外する（Ｓ３０３）。仮に、実際のＲＴＴが要求元アプリの許容ＲＴＴ未満である通信回線が１つも存在しない場合には、割当不可と判定してもよい。その場合はステップＳ１０９に移る。

　同様に、経路設定部Ｆ３４は、スループットの観測値等のステータスを鑑みて通信条件を充足するものを割当回線として選定するように構成されていても良い。想定データサイズで規定される空き容量を有する通信回線が存在しない場合には、割当不可と判断しても良い。ステップＳ１０３が完了するとステップＳ１０４に移る。

　ステップＳ１０４では経路設定部Ｆ３４は、ステップＳ１０３で決定した割当回線を使用中の他のアプリ８１である先行アプリが存在するかを判断する。先行アプリは、割当回線を用いた通信を実行中の、要求元アプリ以外のアプリ８１に相当する。先行アプリが存在する場合にはステップＳ１０４を肯定判定してステップＳ１０５に移る。一方、先行アプリが存在しない場合にはステップＳ１０４を否定判定してステップＳ１０６に移る。なお、先行アプリが存在するか否かを判定することは、割当回線が使用中であるか否かを判定することに相当する。また、先行アプリは必ずしも１つとは限らない。複数の先行アプリが存在する場合もありうる。

　ステップＳ１０５では経路設定部Ｆ３４は、割当回線に要求元アプリの通信を収容しても先行アプリと要求元アプリの両方の通信条件を満たす事ができるか否か、換言すれば、先行アプリと要求元アプリの通信が共存できるか否かを判定する。複数のアプリ８１のデータ通信が共存できる状態とは、それぞれの通信条件を充足しつつ、各データ通信を同時に／並列的に実行可能であることに相当する。

　例えば経路設定部Ｆ３４は、割当回線における現状のスループット及びＲＴＴのそれぞれの観測値と、要求元アプリの想定データサイズとに基づいて、各アプリの許容ＲＴＴなどの要件を充足できるか否かを判定する。例えば現状のＲＴＴの観測値が、割当回線を使用する各アプリの許容ＲＴＴの最小値よりもさらに所定の収容可能閾値以上小さい場合に、先行アプリと要求元アプリの通信は共存可能であると判定してもよい。収容可能閾値は、例えば要求元アプリの想定データサイズが大きいほど大きい値に設定されていることが好ましい。例えば収容可能閾値は、想定データサイズと現在のスループットで除算した値である影響時間とすることができる。また、収容可能閾値は、影響時間から所定の尤度を加えた値とすることもできる。影響時間は、要求元アプリのトラフィックを割当回線に収容した場合に生じうる、ＲＴＴの増加量の概算値に相当する。

　先行アプリと要求元アプリの通信は共存可能であると判定した場合にはステップＳ１０５を肯定判定してステップＳ１０６に移る。一方、先行アプリと要求元アプリの通信は共存できないと判定した場合、すなわち、何れかのアプリにおける通信条件が充足されなくなる場合にはステップＳ１０５を否定判定してステップＳ１０７に移る。

　ステップＳ１０６では経路設定部Ｆ３４が、ステップＳ１０３で選定された割当回線を用いて、ネットワーク側装置やＡＣＰサーバ５、サーバ４などと経路設定のための制御信号をやり取りし、無線通信装置７からサーバ４までの通信経路を確保する。すなわちソースポート番号の確保や、宛先ポート番号の取得、送信元及び宛先ＩＰアドレスの取得などを実行する。当該ステップＳ１０６が完了するとステップＳ１１２に移る。

　ステップＳ１０７では通信要求元のアプリ８１の通信条件と先行アプリの通信条件と比較し、先行アプリの通信を維持させるべきか否かを判断する（ステップＳ１０８）。先行アプリの通信を維持させることは、要求元アプリの通信開始要求を却下するということに相当する。また、先行アプリの通信を維持しないということは、要求元アプリの通信開始要求を承諾し、先行アプリに割り当てている通信リソースの一部又は全部を要求元アプリに割り当てることに相当する。ここでの通信リソースとは、例えば通信帯域である。通信帯域には、例えばリソースブロックの概念を含めることができる。

　例えば図１０に示すように、要求元アプリの許容開始待ち時間が所定の割り込み閾値以上である場合には（Ｓ４０１　ＮＯ）、先行アプリを維持することを決断する（ＳＳ４０３）。その場合、図８のステップＳ１０８は肯定判定されて、ステップＳ１０９に移り、要求元アプリに割当不可応答を返送する。割り込み閾値は、例えば１分や３０秒など、比較的に速やかに通信を開始する必要がある状態を想定した値に設定されている。もちろん、割り込み閾値は５分や１０分などであってもよい。一方、要求元アプリの許容開始待ち時間が割り込み閾値未満である場合には（Ｓ４０１　ＹＥＳ）、要求元アプリに帯域を割り当てることを決定する。その場合、図８のステップＳ１０８は否定判定されて、ステップＳ１１０に移る。

　なお、先行アプリを維持するかどうか、換言すれば先行アプリと要求元アプリの通信のどちらを優先させるかを判断するためのパラメータとしては、許容待ち時間の他に、データ保持可能時間も使用可能である。例えば図１１に示すように、要求元アプリのデータ保持可能時間が所定の割り込み閾値以上である場合には（Ｓ５０１　ＮＯ）、先行アプリを維持すると判断してもよい（Ｓ５０３）。また、要求元アプリのデータ保持可能時間が割り込み閾値未満である場合には（Ｓ５０１　ＹＥＳ）、要求元アプリの通信を優先させると判断してもよい（Ｓ５０２）。データ保持可能時間に対する割り込み閾値もまた、例えば２分や４分など、すぐに通信を開始する必要がある状態を想定した値に設定されている。なお、データ保持可能時間の減少速度は、要求元アプリでの送信用データの発生速度に応じて異なりうる。故にデータ保持可能時間に対する割り込み閾値は、許容待ち時間に対する割り込み閾値よりも長めに設定されることが好ましい。その他、通信条件に示される緊急性フラグや制御利用性フラグなどに基づいて先行アプリと要求元アプリの通信のどちらを優先させるかを判断してもよい。要求元アプリの通信条件に応じたデータ通信を実施可能と判断する場合には、先行アプリの通信を退避させた上で、要求元アプリの通信を開始する場合も含まれる。

　ステップＳ１１０では、要求元アプリの通信を実施可能であると判定するとともに、例えば先行アプリの通信をいったん切断する。先行アプリの通信をいったん切断した場合には、先行アプリが使用していた通信帯域が解放される。なお、ステップＳ１１０の処理内容は、要求元アプリのトラフィックを収容可能なように先行アプリの通信パラメータを変更する処理であってもよい。また、要求元アプリのトラフィックを収容可能なように先行アプリの通信パラメータを変更するということは、例えば、要求元アプリの想定データサイズに応じた分だけ、先行アプリに割り当てていた帯域を縮小することに相当する。なお、先行アプリの通信を別回線に収容可能である場合には、先行アプリに別回線を割り当ててもよい。ステップＳ１１０での処理が完了するとステップＳ１１１に移る。

　ステップＳ１１１では、ステップＳ１０６と同様に、経路設定部Ｆ３４が、ステップＳ１０３で選定された割当回線を用いて、ネットワーク側装置やサーバ４などと経路設定のための制御信号をやり取りし、無線通信装置７からサーバ４までの通信経路を確保する。当該ステップＳ１１１が完了するとステップＳ１１２に移る。

　ステップＳ１１２では要求元アプリに対応するＡＣＰクライアント８２に向けて通信許可応答を返送して本フローを終了する。通信許可応答にはソースポート番号が含まれる。

　なお、以上では先行アプリが存在する場合には、先行アプリと要求元アプリの通信条件を比較するステップを含む態様を開示したがこれに限らない。先行アプリが存在する場合であっても、割当回線のスループットや空き容量、ＲＴＴなどが、要求元アプリの通信条件を充足する状態となっている場合には、先行アプリの通信条件との比較を省略してステップＳ１０６を実行しても良い。つまり、先行アプリとの通信条件の比較処理は任意の要素とすることができる。

　＜作動の具体例＞
　ここでは上記の経路割当処理の具体例をいくつか例示する。なお、ここで述べるそれぞれ異なるアプリ８１である第１アプリと第２アプリは、何れも同一の通信回線、例えば第１回線を使う場合を想定している。

　例えば第１アプリが通信を実施している状態において、第２アプリから、許容待ち時間が１０分に設定されている通信開始要求を受領した場合には、第１アプリの通信を継続させる。また、第２アプリに対応するＡＣＰクライアント８２に向けて割当不可応答を出力する。第２アプリに対応するＡＣＰクライアント８２は、第２アプリに通信の許可が出なかったことを報告するとともに、通信条件を随時更新し、定期的にリトライ処理を実行する。

　なお、リトライ処理を実行する際、通信条件に含まれる許容待ち時間は、最初に通信開始要求を出力した時点からの経過時間に応じて短くなっていく。故に、いつかは通信条件に規定される許容待ち時間が割り込み閾値未満となって、第２アプリに対する通信回線の割当が実行される。なお、データ保持可能時間もまた、最初に通信開始要求を出力した時点からの経過時間、及び、要求元アプリでのトラフィックの生成速度に応じて短くなっていく。故に、時間の経過に伴って通信条件に規定されるデータ保持可能時間が割り込み閾値未満となって、第２アプリへの通信回線の割当が実行される場合もありうる。

　以上の制御態様によれば、複数のアプリ８１が同時通信可能な構成においても、許容通信待ち時間の大きいアプリ８１の通信が、すでに通信中のアプリ８１の通信に影響を及ぼすことを抑制可能となる。

　また、他の例として、第１アプリが通信している状態において、第２アプリの通信開始要求を受領した場合、両方のアプリ８１の許容ＲＴＴが両立できるかを判定する。そして、両方のアプリの許容ＲＴＴを両立できる見込みがある場合には、第２アプリのソースポートを確保し、ルーティング処理を実行する。なお、仮に第２アプリのほうが第１アプリよりも許容ＲＴＴが小さい場合には、第２アプリの通信品質が確保されやすいように、先行アプリに相当する第１アプリに割り当てている帯域を縮小してもよい。つまり、許容ＲＴＴが小さい方のアプリ８１の通信を優先させてもよい。

　このような制御態様によれば、先行アプリと同時通信した際に見込まれる通信品質（主としてＲＴＴ）を考慮した上で要求元アプリの通信接続を提供できる。

　さらなる他の例としては、第１アプリが通信を実施している状態において、データ保持可能時間が所定の割り込み閾値未満である第２アプリからの通信開始要求を受領した場合には、通信制御部Ｆ３は第２アプリの通信開始が必要であると判断する。そして、第２アプリへの経路設定を実施する。また、先行アプリとしての第１アプリに対しては、第２アプリの通信が迅速に実行されるよう、第１アプリの通信パラメータの変更あるいは通信切断を実施しても良い。

　上記の制御態様によれば、先行して通信している第１アプリとの同時通信を勘案しつつ、データ保持可能時間の短い第２アプリに通信接続を提供できる。その結果、第２アプリにおいてバッファあふれが生じる恐れを低減できる。

　また、他の例として、経路設定部Ｆ３４は、要求元アプリのデータ欠損フラグがオンに設定された通信開始要求を取得した場合には、先行アプリの通信がデータの欠損を許容するタイプのものであるかどうかに基づいて応答を変更する。図１２に示すように先行アプリがデータの欠損を許容している場合には（Ｓ６０１　ＹＥＳ）、要求元アプリを先行アプリよりも優先して帯域を割り当てる（Ｓ６０２）。一方、先行アプリもまたデータの欠損を不可としている場合には（Ｓ６０１　ＮＯ）、例えば先行アプリの通信を維持する（Ｓ６０３）。

　より具体的には、データ欠損フラグがオンの第１アプリの通信中に、データ欠損フラグがオフの第２アプリからの通信開始要求を受領した場合には、通信制御部Ｆ３は第２アプリのＡＣＰクライアント８２に対して割当不可応答を送信する。第２アプリのＡＣＰクライアント８２は、所定のリトライ周期で通信条件の諸元をアップデートした上で通信開始要求を再送する。

　このような制御態様によれば、複数のアプリ８１が同時に通信可能な構成において、データ欠損不可のアプリ８１の通信品質が、他のアプリ８１の通信によって損なわれる恐れを低減できる。なお、データ欠損フラグがオフの第２アプリの通信中に、データ欠損フラグがオンの第１アプリからの通信開始要求を受領した場合には、通信制御部Ｆ３は第２アプリ用の帯域を縮小又は解放するとともに、第１アプリ用の経路を確保する。そして第１アプリのＡＣＰクライアント８２に対して通信許可応答を返送する。なお、第２アプリに対して通信切断を行った場合にはその旨を第２アプリのＡＣＰクライアント８２に通知する。

　また、先行アプリも要求元アプリも両方ともデータの欠損を許容しない場合には、他の通信パラメータに基づいて、どちらの通信を優先させるかを決定してもよい。例えば先行アプリも要求元アプリも両方ともデータの欠損を許容しない場合には、データ保持可能時間が短い方の通信を優先させる。なお、本実施形態のように複数のセルラー回線を利用可能である場合には、より信頼度が高い回線に、より通信条件が厳しいアプリ８１を優先的に割り当てることが好ましい。信頼度が高い回線とは、スループットやＲＳＲＱなどのパラメータが相対的に高品質な回線を指す。

　その他、先行アプリの通信開始要求時に受け取った想定データサイズが所定の制限閾値以上である場合、以降において当該回線の使用を許可するアプリ８１は、想定データサイズが所定値未満のものに限定してもよい。そのような構成によれば、無線通信装置７で合算した通信速度を所定値以上に維持可能となる。

　また、緊急通信フラグが緊急と設定されたアプリの通信開始要求は、即座に割当可と応答するとともに通信経路確保に際して、当該通信の信頼度が最も高い回線を割り当てることが好ましい。

　＜ソースポート毎の割当回線についての補足＞
　各アプリ８１に割り当てる通信回線は、一定ではなく動的に変更されうる。換言すれば、ソースポートに紐づく通信回線は動的に通信制御部Ｆ３によって動的に変更されうる。例えば、Ｗｉ－Ｆｉ回線を積極的に使用することが通信条件として指定されている場合には、Ｗｉ－Ｆｉ回線が利用可能となったタイミングでセルラー回線からＷｉ－Ｆｉ回線へと変更する場合もある。

　また、通信制御部Ｆ３は、セルラー回線の中でもスループットの低下や、レイテンシの劣化などの通信品質の変動を受けて、アプリ８１毎の通信回線の割り当て状態を変更しうる。加えて、アプリ８１毎の通信状況、例えば或るアプリ８１の通信が終了したことや緊急性が高いアプリ８１からの通信開始要求を受けて、他のアプリ８１への通信回線の割り当てを変更することもある。

　なお、回線毎のステータスの変動や、アプリ８１毎の通信状態の変化以外にも、車両Ｈｖの所定挙動や、車両Ｈｖに対するユーザ操作に基づいて、アプリ８１への通信回線状態を変更するように構成されていてもよい。例えば車両Ｈｖが信号待ち等で一時停車したことを受けて、アプリ８１毎の通信回線を割り当てし直してもよい。通信回線の切り替えには通信の瞬断が伴う場合があるが、車両Ｈｖが停車中であれば通信の瞬断が車両Ｈｖの走行制御に影響を与える恐れを低減できるためである。

　＜通信量／通信料の管理について＞
　アプリ８１からサーバ４までのルーティング設定が完了すると、アプリ８１は、無線通信装置７から通知されているソースポート番号を用いて、サーバ４と暗号通信を開始する。通信自体が暗号化されると、例えばアプリＩＤなど、無線通信装置７に入力されたデータの生成元を示す情報も暗号化されて不明となる。そのため、無線通信装置７は、どのアプリ８１がどれくらい通信しているのかが不明となる。なお、暗号通信においても暗号化されない情報とは、例えばソースポート番号と、送信元ＩＰアドレス、宛先ポート番号、宛先ＩＰアドレスなどである。アプリＩＤ等を含むペイロード、換言すればアプリケーションデータは暗号化されて不明となる。

　そこで、本実施形態の通信制御部Ｆ３及びＡＣＰサーバ５は、ソースポート番号とアプリＩＤとを対応付けて記憶するとともに、ソースポート毎の通信量を、使用回線毎に区分して管理する（図６のＳ２０）。例えばＡＣＰサーバ５は、図１３に示すように、アプリＩＤと、ソースポート番号と、回線毎の通信量とを記録する。このようにソースポート毎の割当回線及びその通信量の履歴を保持する構成によれば、ソースポートとアプリ８１が対応しているため、アプリ８１毎の通信量を特定する事ができる。特に通信量を回線毎に区別して記録するため、回線毎の料金体系を考慮した通信料金の合計値を算出可能となる。

　また、上記の構成によれば、ＡＣＰサーバ５は、各車両Ｈｖでのアプリ８１毎の回線別使用量を収集可能となる。故に、例えば、通信費を車両メーカが負担するように設定されているアプリ８１が有る場合には、車両メーカは、各車両Ｈｖでの当該アプリ８１の総通信量に対応する料金をまとめて通信事業者に支払うことが可能となる。また、アプリ８１毎の通信料金を算出可能となれば、通信料／通信量が所定の上限値に達しつつあるアプリ８１の使用を控えるようにユーザに提案するなどのシステム応答の実施可能となる。或いは、所定の通信料金の上限値に達しつつあるアプリ８１に関しては、積極的にＷｉ－Ｆｉ通信を使用するように通信条件を変更するなどのシステム応答も採用可能となる。

　＜効果＞
　以上の構成によれば、無線通信装置７は、要求元アプリから通知される通信条件と、他のアプリ８１の通信状況及び通信条件をもとに、要求元アプリと外部装置とのデータ通信が実施可能かどうかを判断する。このような構成によれば、車両Ｈｖで使用されるアプリ８１が動的に変更されたり、車両Ｈｖ毎に搭載されるアプリ８１の組み合わせが異なっていたりしても、アプリ８１毎の通信特性に応じた通信回線の割り当てを柔軟に実施可能となる。

　また、無線通信装置７が要求元アプリに対して、すぐに通信可能かどうかの判断結果を応答として返送する。そのため、アプリ８１としては、すぐに通信開始できるのか否かを把握可能となる。特に、通信可能と判断した場合には、通信に供されるソースポート番号を通知するため、要求元アプリは当該ソースポートを用いた暗号通信を実施することも可能となる。

　さらに、以上のシステム構成では無線通信装置７が、アプリ８１毎のサーバ４とのデータ通信を統括的に制御し、アプリ８１毎に、アプリ８１が要求する通信条件に応じた通信経路を割り当てる。これにより、複数のアプリ８１を含むシステム全体として、たとえば遅延時間など、アプリ８１毎の通信状態が各アプリ８１の許容範囲を逸脱する恐れを抑制できる。換言すれば、通信の遅延時間等にかかる要求が異なる複数種類のデータ通信を並列的に実行する必要が有る場合において、各データ通信のタイプに応じた回線を併用することで、全体として通信効率を高めることができる。

　また、無線通信装置７は、各アプリ８１に対して通信開始のタイミングを調停する。例えば許容開始時間やデータ保持可能時間が十分に大きいアプリ８１から通信開始要求が到着した時点において、通信回線の使用割合が高い場合には、割当不可応答を返送することにより、通信開始を保留状態とする。このような構成によれば、急いで通信を開始する必要がないアプリ８１のデータ通信を開始することで、無線リソースが逼迫し、先行アプリの通信に支障が生じる恐れを低減できる。

　加えて、緊急性が高いアプリ８１からデータ通信の開始が要求された場合には、優先的に当該アプリ８１に対して経路割当を行う。これにより、緊急性が低いアプリ８１が通信を実施していることに起因して緊急性が高いアプリ８１の通信に支障が生じる恐れを低減できる。なお、緊急性が高いアプリとは、緊急通報アプリや、ＡＤＡＳ系のアプリ、遠隔制御アプリなどである。

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

　＜優先制御の補足＞
　先行アプリと要求元アプリの通信のどちらを優先させるかを判断材料は、開始待ち時間やデータ保持可能時間、データ欠損可否など、上述したパラメータに限定されない。例えば先行アプリと要求元アプリとでデータ保持時間やデータ欠損可否などの条件が同じである場合には、緊急性フラグがオンとなっている方を優先しても良い。また、先行アプリと要求元アプリとでデータ保持時間やデータ欠損可否などの条件が同じである場合には、制御利用性フラグがオンとなっている方を優先しても良い。プライバシーフラグや機密性フラグがオンに設定されているアプリ８１には、それらのフラグがオフに設定されているアプリ８１よりも優先的にＶＰＮ回線を割り当てることが好ましい。アプリ８１とデータ通信の内容／特性は基本的に１対１で対応するため、ここでのアプリ８１はデータ通信と読み替えることもできる。

　＜各種アプリ８１の補足説明＞
　上述した遠隔制御アプリは、例えば、車両外部に配置された遠隔制御センタから送信された遠隔制御用のデータに基づき、各種走行アクチュエータに制御信号を出力することにより、車両Ｈｖの挙動を制御するアプリ８１である。また、遠隔制御アプリは、車載カメラ画像などの画像や、車速センサなどの走行状態を示すセンサデータを遠隔制御センタに向けて送信すべく、無線通信装置７に出力する。

　上述したプローブアプリは、車両Ｈｖには例えば周辺監視センサが特定した地物の観測位置を示すデータセットをプローブデータとしてサーバ４に逐次送信するアプリ８１である。プローブデータは、例えば区画線や道路標識、信号機などのランドマーク等に対する一定時間（例えば４００ミリ秒）以内の認識結果をパッケージ化したデータに相当する。プローブデータは、例えば、送信元情報や、走行軌道情報、走路情報、および地物情報を含んでもよい。走行軌道情報は、車両Ｈｖが走行した軌道を示す情報である。地物情報は、ランドマーク等の地物の観測座標を示す。また、プローブデータには、車速や、舵角、ヨーレート、ウインカー作動情報、ワイパー作動情報などといった、車両挙動情報が含まれていてもよい。プローブデータはサーバ４が地図データを生成更新するための材料データに相当する。

　加えて、車両に搭載されるアプリ８１の種類は以上で例示したものに限定されない。多様なアプリ８１が車両Ｈｖに搭載されうる。例えばアプリ８１としては、ドライブレコーダ機能を提供するアプリや、自己診断機能（いわゆるＯＢＤ：On Board Diagnostics）としての機能を提供するアプリ、自動運転機能を提供する自動運転アプリなどを含めることができる。

　なお、自動運転アプリは、例えば、自動運転時の車両内、及び、車室外の状況を示すデータセットを走行状態報告として、無線通信装置７を介してサーバ４に逐次送信する。自動運転時の車両内の状況には、自動運転アプリの作動状態や、乗員の状態を含めることができる。自動運転アプリの作動状態を示すデータには、自動運転アプリにおける周辺環境の認識結果や、走行計画、各走行アクチュエータの目標制御量などの算出結果も含まれる。自動運転アプリは、所定のサーバ４より、中長期的な走行計画などを示すデータを受信するように構成されていても良い。なお、自動運転アプリに対応するサーバ４は、例えば車載通信システム１からアップロードされてくる走行状態報告を受信し、走行計画を作成及び修正して配信してもよい。

　＜適用車両＞
　車載通信システム１は、四輪自動車のほか、二輪自動車、三輪自動車等、道路上を走行可能な多様な車両に搭載可能である。原動機付き自転車も二輪自動車に含めることができる。当該システムが適用される車両Ｈｖは、個人によって所有されるオーナーカーであってもよいし、カーシェアリングサービスや車両貸し出しサービスに供される車両であってもよい。また、車両Ｈｖは、サービスカーであってもよい。サービスカーには、タクシーや路線バス、乗り合いバスなどが含まれる。また、サービスカーは、運転手が搭乗していない、ロボットタクシー又は無人運行バスなどであってもよい。サービスカーには、荷物を所定の目的地まで自動運搬する無人配送ロボットとしての車両を含めることができる。さらに、車両Ｈｖは、車両外部に存在するオペレータによって遠隔操作される遠隔操作車両であってもよい。

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

　少なくとも１つの通信回線を利用可能に構成されてあって、車両で実行される複数のアプリケーション（８１）のそれぞれと外部装置（４）との前記通信回線を用いた通信を制御する通信制御装置であって、
　前記アプリケーションから前記外部装置とのデータ通信の開始要求を受け付ける要求受付部（Ｓ１２Ａ）と、
　前記開始要求の要求元である前記アプリケーションから、前記外部装置との前記データ通信に係る条件を示す通信条件を取得する通信条件取得部（Ｆ３３）と、
　前記通信条件に応じた前記データ通信を実施可能であるか否かを、前記通信回線の状態、及び、通信実行中の他の前記アプリケーションである先行アプリの前記通信条件の少なくとも何れか一方に基づいて判断する通信可否判断部（Ｓ１３）と、
　前記通信可否判断部によって前記要求元と前記外部装置との前記通信が可能であると判定されたことに基づき、前記要求元から前記外部装置までの通信経路を設定する処理を行う経路設定部（Ｆ３４）と、
　前記通信可否判断部の判断結果を示す情報を前記要求元に返送する応答部（Ｓ１５、Ｓ２１）と、を備え、
　前記通信経路の設定は、前記要求元へのソースポート番号の割当を含み、
　前記応答部は、前記通信可否判断部によって前記データ通信は可能であると判定された場合には、前記ソースポート番号を前記要求元に通知するように構成されている通信制御装置。
　請求項１に記載の通信制御装置であって、
　前記応答部は、前記通信可否判断部によって前記データ通信は可能ではないと判定された場合には、通信不可であることを示す割当不可応答として、前記通信条件を充足する通信を実施可能となるまでの待機時間の見込み値、及び、現在の状況において実施可能な通信条件の少なくとも何れか一方を含むメッセージを前記要求元に返送するように構成されている通信制御装置。
　請求項１又は２に記載の通信制御装置であって、
　前記応答部は、前記通信可否判断部によって前記データ通信は可能であると判定された場合には、前記ソースポート番号とともに、通信の実施権があることを示すトークンを前記要求元に送出するように構成されている通信制御装置。
　請求項１から３の何れか１項に記載の通信制御装置であって、
　前記通信条件は、通信開始まで許容可能な待ち時間を示す許容待ち時間、許容可能な応答遅延時間を示す許容遅延時間、前記アプリケーションが利用可能なキャッシュ領域に送信用データを保持できる残り時間を示すデータ保持可能時間、送受信するデータサイズの想定値、及び、データの欠損を許容するか否かの少なくとも何れか１つの項目についての情報を含んでいる通信制御装置。
　請求項１から４の何れか１項に記載の通信制御装置であって、
　前記通信可否判断部は、前記要求元の前記通信条件と前記先行アプリの前記通信条件とを比較して、前記先行アプリと前記要求元の通信のどちらを優先するべきかを判断し、
　前記経路設定部は、前記要求元を優先するべきと判断した場合には、前記先行アプリに割り当てている通信帯域の一部又は全部を前記要求元の通信に割り当てるように構成されている通信制御装置。
　請求項１から５の何れか１項に記載の通信制御装置であって、
　前記通信条件は、通信開始まで許容可能な待ち時間を示す許容待ち時間を含み、
　前記経路設定部は、前記要求元の前記通信条件に含まれる前記許容待ち時間が所定の割り込み閾値未満となっている場合には、前記先行アプリに割り当てている通信帯域の一部又は全部を前記要求元の通信に割り当てるように構成されている通信制御装置。
　請求項１から６の何れか１項に記載の通信制御装置であって、
　前記通信条件は、許容可能な応答遅延時間を示す許容遅延時間を含み、
　前記通信回線の前記応答遅延時間を観測する回線特性取得部（Ｆ３２）を備え、
　前記通信可否判断部は、前記回線特性取得部によって取得されている前記応答遅延時間の観測値が、前記要求元の前記通信条件に含まれる前記許容遅延時間よりも小さい前記通信回線が存在しない場合には、前記通信条件に応じた通信を実施できないと判定する通信制御装置。
　請求項１から７の何れか１項に記載の通信制御装置であって、
　前記通信条件は、前記アプリケーションが利用可能なキャッシュ領域に送信用データを保持できる残り時間を示すデータ保持可能時間を含み、
　前記経路設定部は、前記要求元の前記通信条件に含まれる前記データ保持可能時間が所定の割り込み閾値未満となっている場合には、前記先行アプリに割り当てていた通信帯域の一部又は全部を前記要求元の通信に割り当てるように構成されている通信制御装置。
　請求項１から８の何れか１項に記載の通信制御装置であって、
　前記通信条件は、データの欠損を許容するか否かを含み、
　前記経路設定部は、前記要求元の前記通信条件がデータの欠損を許容しないことを含んでいる場合には、前記先行アプリに割り当てていた通信帯域の一部又は全部を前記要求元の通信に割り当てるように構成されている通信制御装置。
　請求項１から９の何れか１項に記載の通信制御装置であって、
　複数の前記アプリケーションのそれぞれには固有の識別情報であるアプリ識別子が設定されており、
　前記開始要求には前記要求元の前記アプリ識別子が含まれており、
　前記要求元に割り当てた前記ソースポート番号と、前記ソースポート番号を用いて送受信された通信回線毎のデータ量とを紐付けて管理する通信量管理部（Ｆ３５）を備える通信制御装置。
　少なくとも１つの通信回線を用いて実行される、車両で使用される少なくとも１つのアプリケーション（８１）と前記車両の外部に存在する通信装置である外部装置（４）との通信の実施状況を制御する通信制御方法であって、
　前記アプリケーション（８１）が、前記車両で使用される無線通信装置（７）に向けて、前記外部装置とのデータ通信の開始要求を送信すること（Ｓ１０）と、
　前記無線通信装置が、前記開始要求の要求元である前記アプリケーションから、前記外部装置との前記データ通信に係る条件を示す通信条件を取得すること（Ｓ１０１）と、
　前記無線通信装置が、前記通信回線の状態、及び、通信実行中の他の前記アプリケーションである先行アプリの前記通信条件の少なくとも何れか一方に基づいて、前記要求元の前記通信条件に応じた通信を実施可能であるか否かを判断すること（Ｓ１３）と、
　前記要求元と前記外部装置との前記通信が可能であると判定されたことに基づき、前記無線通信装置が、前記要求元のためのソースポート番号を確保するとともに、前記要求元から前記外部装置までの通信経路を設定すること（Ｓ１４）と、
　前記無線通信装置が、前記要求元から前記外部装置までの通信経路に関する情報として少なくとも前記ソースポート番号を含む経路情報を、前記要求元に対して通知すること（Ｓ１５）と、
　前記要求元は、前記ソースポート番号を用いて前記外部装置と暗号通信を実行すること（Ｓ１９）と、を含む通信制御方法。
　車両で使用されるアプリケーション（８１）と、前記アプリケーションと連携して動作する外部装置（４）とのデータ通信を中継する中継サーバ（５）であって、
　前記アプリケーションとの通信は、前記車両に搭載されている無線通信装置（７）を介して通信するように構成されており、
　前記無線通信装置は、所定の複数の通信回線の中から前記アプリケーションが指定する通信条件を充足する通信回線を選択的に用いるように構成されており、
　前記無線通信装置から、前記アプリケーションに割り当てているソースポート番号を含む通信経路情報を、前記アプリケーションの識別情報であるアプリ識別子と対応付けて取得する経路情報取得部（Ｇ１）と、
　前記アプリケーションに割り当てられている前記ソースポート番号を用いて送受信された通信回線毎のデータ量を、前記アプリ識別子またはソースポート番号と紐付けて管理する通信量管理部（Ｇ３）と、を備える中継サーバ。