WO2023132277A1

WO2023132277A1 - 通信制御装置、通信制御方法、及びアプリケーション用制御プログラム

Info

Publication number: WO2023132277A1
Application number: PCT/JP2022/047684
Authority: WO
Inventors: 功佑山岡
Original assignee: 株式会社デンソー
Priority date: 2022-01-06
Filing date: 2022-12-23
Publication date: 2023-07-13
Also published as: CN118511585A; JP2023100458A; US20240349113A1

Abstract

通信マネージャ（８７）は、アプリ（９）が使用している通信回線に輻輳が生じたことを検出すると、アプリ（９）に対して帯域制限をかけるとともに、アプリ（９）に向けて帯域制限通知を送出する。帯域制限通知は、例えば環境劣化や、重要サービス作動中、優先度負けなどといった、輻輳／帯域制限の理由を含む。また、通信マネージャ（８７）は、帯域制限通知として、輻輳／帯域制限の理由に応じた推奨制御内容を含むメッセージを送信することがある。アプリ（９）は帯域制限通知を受信したことに基づき、ＴＣＰリトライ等を停止させる。

Description

通信制御装置、通信制御方法、及びアプリケーション用制御プログラム

関連出願の相互参照

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

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

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

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

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

　特許文献１に開示の構成では、輻輳が生じた場合、優先度が高いアプリケーションにおいてもサーバからの応答を取得できないことが生じうる。また、優先度が低いアプリケーションにしてみると、サーバからの応答が返ってこない場合に、優先度が高い他のアプリケーションの通信が優先されているのか、輻輳が生じているのか、その理由が判断できない。

　特許文献１に開示の構成ではアプリケーションにおいて通信遅延の理由が不明となりうるため、例えば、ＴＣＰレイヤ／アプリケーションレイヤでの再送要求（いわゆるリトライ）が頻発しうる。再送要求の頻発は、通信制御装置の処理負荷の増大を招きうる。また、アプリケーション自身も、リトライ処理に伴い処理負荷が増大しうる。

　本開示は、上記の検討又は着眼点に基づいて成されたものであり、その目的の１つは、輻輳の発生をアプリケーションが認識可能な通信制御装置、通信制御方法、及びアプリケーション用制御プログラムを提供することにある。

　ここに開示される通信制御装置は、第１のネットワークに接続する装置により実施されるアプリケーションによる通信であって、第１のネットワークとは異なる第２のネットワークに接続する外部装置との通信を制御する通信制御装置であって、外部装置と通信するための通信回線の状態を監視し、通信回線における輻輳の発生を検知し、輻輳の発生を検知したことに基づいて、輻輳を検出している通信回線を使用中のアプリケーションに対し、使用回線が輻輳していることを示す通知を送信するように構成されている。

　上記構成によれば、アプリケーションが輻輳の発生を把握可能となる。

　本開示の通信制御方法は、第１のネットワークに接続する装置により実施されるアプリケーションによる通信であって、第１のネットワークとは異なる第２のネットワークに接続する外部装置との通信を制御する通信制御装置による通信制御方法であって、外部装置と通信するための通信回線の状態を監視し、通信回線における輻輳の発生を検知し、輻輳の発生を検知したことに基づいて、輻輳を検出している通信回線を使用中のアプリケーションに対し、使用回線が輻輳していることを示す通知を送信する。

　上記方法によれば通信制御装置と同様の作用により同様の効果が得られる。

　本開示のアプリケーション用制御プログラムは、外部装置とデータ通信を実施するアプリケーションを実行する装置に、アプリケーションと外部装置との通信を制御する通信制御装置から、アプリケーションの通信に用いられる通信回線に輻輳が生じていることを示すメッセージを取得することと、通信回線の輻輳が生じていることを示すメッセージを受信した場合に、外部装置との通信を制限することと、を実行させる命令を含む。

　上記制御プログラムによれば、輻輳が発生したことの通知に基づき、外部装置との通信が制限される。

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

車両用通信システムの全体像を説明するための図である。中継サーバの構成を示すブロック図である。車載システムの構成を示すブロック図である。ＥＣＵの構成を示すブロック図である。通信開始要求のフレーム構成の一例を示す図である。通信条件の一例を示す図である。通信マネージャの機能について説明するための図である。通信マネージャの機能ブロック図である。通信状態管理部の作動を説明するための図である。帯域制限通知の構成の一例を示す図である。制限理由の一例を示す図である。帯域制限通知の他の構成例を示す図である。推奨制御の一例を示す図である。通知レベルが２に設定されているアプリに向けて通知する、制限理由ごとの推奨制御内容と補足情報の一例を示す図である。通知レベルが３に設定されているアプリに向けて通知する、制限理由ごとの推奨制御内容と補足情報の一例を示す図である。通信マネージャの作動を説明するためのシーケンス図である。通信マネージャの作動を説明するためのシーケンス図である。輻輳に由来して一部のアプリの通信回線を切り替える場合を示す図である。輻輳に由来して一部のアプリの通信タイミングを調整する場合を示す図である。帯域制限通知に対するアプリの作動を説明するためのフローチャートである。帯域制限通知送信後の通信マネージャの作動を説明するための図である。比較構成の課題を説明するための図である。アプリが帯域制限機能を備える構成例を示す図である。アプリが帯域制限機能を備える場合の通信マネージャの作動を説明するためのフローチャートである。

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

　＜全体構成＞
　図１に示すように車両用通信システムＳｙｓは、車載システム１、セルラー基地局２、広域通信ネットワーク３、サーバ４、及び中継サーバ５を含む。また、車両用通信システムＳｙｓは、任意の要素としてＷｉ－Ｆｉ（登録商標）基地局６を含みうる。なお、図１にはセルラー基地局２、Ｗｉ－Ｆｉ基地局６を１つずつしか示していないが、これらは複数存在しうる。車載システム１を搭載した車両Ｖｃもまた、図１には１つしか示していないが、システム全体としては複数存在しうる。

　車載システム１は、別途詳細を後述するように、複数のＥＣＵ（Electronic Control Unit）７と、無線通信装置８を備える。ＥＣＵ７は、車両Ｖｃに搭載される制御装置である。また、車載システム１は、複数のアプリケーション（以降、アプリ９）を備える。アプリ９は、ＥＣＵ７上で動作するプログラムである。

　無線通信装置８は、アプリ９が外部装置としてのサーバ４とデータ通信を実施するためのインターフェースとして車両で使用される装置である。無線通信装置８は、アプリ９とサーバ４との通信を制御する。無線通信装置８が通信制御装置に相当する。無線通信装置８は、セルラー回線及びＷｉ－Ｆｉ回線といった、通信方式が異なる複数種類の無線通信サービス（換言すれば通信回線）を利用可能に構成されている。ここでのセルラー回線とは、セルラー基地局２を介した通信回線、換言すれば、４Ｇ等に準拠した通信回線を指す。また、Ｗｉ－Ｆｉ回線とは、Ｗｉ－Ｆｉ基地局６を経由する通信回線を指す。Ｗｉ－Ｆｉ回線は、Ｗｉ－Ｆｉ基地局６の通信エリア内に車両Ｖｃが存在する場合に利用可能となる。

　アプリ９は、サーバ４と通信することにより、車両Ｖｃのユーザに所定のサービスを提供する。アプリ９は、ＥＣＵ７が備える演算コアが所定のアプリケーションソフトウェアを実行することで実現される。アプリ９は、アプリケーション用制御プログラムを含みうる。本開示の「アプリケーション」、「アプリ」との記載は、アプリケーションを実行する装置／演算コアと読み替えることができる。演算コアは、ＣＰＵ（Central Processing Unit）などのプロセッサを指す。

　セルラー基地局２は、無線通信装置８と４Ｇ等の規格に準拠した無線信号を送受信する設備である。セルラー基地局２は、ｅＮＢ（evolved NodeB）とも称される。セルラー基地局２は、５Ｇで使用されるｇＮＢ（next generation NodeB）であってもよい。セルラー基地局２は、無線通信装置８と制御信号をやり取りすることで、無線通信装置８による広域通信ネットワーク３への接続、ひいては無線通信装置８と種々のサーバ４とのデータ通信を実現する。

　セルラー基地局２は、多様な参照信号（ＲＳ：Reference Signal）を随時送信する。参照信号の例としては、ＣＲＳ（Cell-specific RS）や、ＣＳＩ－ＲＳ（CSI-Reference Signal）などがある。ＣＳＩは、Channel State Informationの略である。ＣＲＳはセル選択用の制御信号である。ＣＳＩ－ＲＳは、上り又は下り方向の伝送路の状態を推定するためのＲＳである。各種ＲＳは、１つの側面において、無線通信装置８が、通信回線の通信速度やレイテンシ、パケットロス率など、いわゆるＱｏＳ（Quality of Service）を評価するための制御信号に相当する。

　広域通信ネットワーク３は、ＥＰＣ（Evolved Packet Core）などのコアネットワークを含む。また、広域通信ネットワーク３は、インターネット、あるいは、インターネット以外のＩＰ（Internet Protocol）ネットワークをも含みうる。広域通信ネットワーク３は、サーバ４、中継サーバ５、及びＷｉ－Ｆｉ基地局６が接続するネットワークであればよい。広域通信ネットワーク３が第２のネットワークに相当する。

　本開示では、ＭＭＥ（Mobility Management Entity）や、Ｓ－ＧＷ（Serving Gateway）など、広域通信ネットワーク３を構成する通信設備をまとめてネットワーク側装置と称する。ネットワーク側装置には、セルラー基地局２を含めることができる。なお、ＭＭＥは、セル内のＵＥ（User Equipment）の管理や、セルラー基地局２の制御を担当する設備である。

　サーバ４は、アプリ９とデータ通信を実行することで、所定のサービスを提供するための処理を実行するコンピュータである。サーバ４とアプリ９とのデータ通信は中継サーバ５を介して実施される。サーバ４は、車両Ｖｃで使用されるアプリ９から受信したデータに対して所定の処理を実行する。サーバ４は、提供サービスに応じたデータをアプリ９に送信したり、アプリ９からデータを収集したりする。サーバ４は、アプリ９ごとに存在しうる。サーバ４が外部装置に相当する。

　中継サーバ５は、車両Ｖｃとサーバ４との通信を中継するサーバである。中継サーバ５は、車両Ｖｃとサーバ４との通信接続制御及び通信状態の監視を統合的に行う。無線通信装置８が広域通信ネットワーク３に接続している場合、中継サーバ５は、広域通信ネットワーク３を介して無線通信装置８と通信可能となる。中継サーバ５は、サーバ４からの要求に基づき、指定された車両Ｖｃに搭載されるＥＣＵ７へ向けて、データを送信したり、車両Ｖｃからのデータを取得したりする。

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

　なお、車両Ｖｃごとに、搭載されているＥＣＵ７の仕様は異なりうる。ＥＣＵの仕様には、ＯＳ（Operating System）や、走行用電源オフ時のＥＣＵ７／アプリ９の起動状態などが含まれうる。走行用電源は、車両Ｖｃが走行するための電源であって、車両Ｖｃがガソリン車である場合にはイグニッション電源を指す。車両Ｖｃが電動車である場合、走行用電源とはシステムメインリレーを指す。電動車には、電気自動車やハイブリッド車、燃料電池自動車が含まれる。

　＜車両が備えるアプリの一例について＞
　車両Ｖｃには、多様なアプリ９が搭載されうる。例えば車両Ｖｃは、車両状態確認アプリや、ＡＶＰ（Automated Valet Parking）アプリ、緊急通報アプリ、制御支援アプリなどの一部又は全部を備える。なお、ここで例示するアプリ９は一例であって、例示するもの以外にも車両Ｖｃでは多様なアプリが使用されうる。

　車両状態確認アプリは、総走行距離や、バッテリー残量、各ドアの開閉状態、室内温度といった車両Ｖｃの状態を、ユーザがユーザデバイス上で確認するためのアプリである。ユーザデバイスとは、スマートフォンや、タブレット端末、ラップトップ、デスクトップＰＣなどを指す。車両状態確認アプリは、各種情報を定期的にサーバ４にアップロードする。車両状態確認アプリに対応するサーバ４は、アプリから取得した車両状態のデータを保存し、ユーザからの要求に基づき、所定のユーザデバイスに送信する。

　なお、車両状態確認アプリは、車載カメラの映像を、サーバ４を経由してユーザデバイスに表示したり、サーバ４に保存したりするための車載ソフトウェアであっても良い。車両状態確認アプリは、サーバ４を経由して送信されるユーザからの指示信号に基づき、ドアの施開錠状態や、窓の開度、灯火装置の点灯状態を制御する機能を備えていても良い。つまり、車両状態確認アプリは、車両Ｖｃのボディ系電装設備や空調装置を遠隔制御するためのアプリとして構成されていても良い。ボディ系電装設備には、各種灯火装置や、ドアロックモータ、ウインドウモータなどが含まれる。

　ＡＶＰアプリは、自動駐車サービスや自動出庫サービスを提供するアプリである。自動駐車サービスとは、車両Ｖｃを空いている駐車スペースまで自動走行させて駐車させることを指す。自動出庫サービスとは、駐車されている車両Ｖｃを起動させてユーザのもとまで自動走行させるサービスを指す。ＡＶＰアプリに対応するサーバ４は、アプリ９からの要求に基づき、駐車可能な空きスペース等の目標駐車位置情報を送信しうる。また、ＡＶＰアプリに対応するサーバ４は、ユーザデバイスからの出庫要求に基づき、ＡＶＰアプリに対しユーザの現在位置などを送信する。

　緊急通報アプリは、事故や乗員の異常などをトリガに、所定のセンタやユーザデバイスに異常の発生を連絡するアプリである。緊急通報アプリは、車両Ｖｃの不正開錠など、盗難に係る異常を検出してセンタ等に通知するアプリであってもよい。緊急通報アプリは相対的に重要度が高いアプリに相当する。

　制御支援アプリは、定期的に又は所定のイベントが生じた場合に、サーバ４から、制御計画作成の参考となる情報である制御支援情報を受信するアプリである。制御支援情報とは、渋滞末尾や路上落下物の位置など、走行上の障害物の位置や種別を示す準動的な地図要素についての情報である。制御支援情報は、車両Ｖｃの前方に存在する信号機の位置とその点灯状態を示す情報や、交差点内外における進行方向に応じた走行軌道を示す情報であっても良い。制御支援アプリに対応するサーバ４は、アプリからの要求に基づき、車両Ｖｃの現在位置に応じた制御支援情報を配信しうる。

　＜中継サーバ５について＞
　中継サーバ５は、前述の通り、車両Ｖｃとサーバ４との通信、ひいてはアプリ９とサーバ４との通信を中継するサーバである。中継サーバ５は、オートモーティブ無線通信プラットフォーム（ＡＣＰ：Automotive Communication Platform）において、クラウド側の主要機能を提供するコンピュータに相当する。ＡＣＰは、車両Ｖｃごとのシステム構成の違いを隠蔽（抽象化）しつつ、サーバ４とアプリ９とのセキュアなデータ通信を可能にするための技術である。

　例えばモデルやリリース年（世代）、グレード等の違いに由来して、駐車中に電源がオフとなるＥＣＵと電源がオフにならないＥＣＵの組み合わせは車両Ｖｃごとに相違しうる。また、車両Ｖｃごとに、ＥＣＵを含む車載システム１の構成自体が相違しうる。中継サーバ５は、車両Ｖｃごとのシステム構成の違いやＥＣＵごとの電源状態の違い、すなわち、車両Ｖｃごと及びＥＣＵ７ごとの多様性を、サーバ４側から隠蔽する。そして、中継サーバ５は、あたかも各ＥＣＵ７とサーバ４とが常時接続されているような擬似的な常時接続を実現する。中継サーバ５は、１つの側面においてＡＣＰを構成するサーバであるため、ＡＣＰサーバと呼ぶこともできる。

　そのような中継サーバ５は、図２に示すように通信装置５１、サーバプロセッサ５２、ＲＡＭ（Random Access Memory）５３、及びストレージ５４を備える。通信装置５１は、無線通信装置８や各種サーバ４と通信を実施するための構成である。通信装置５１は、サーバ４などの他の装置とＴＬＳ（Transport Layer Security）を用いた暗号通信を実施可能に構成されていてよい。サーバプロセッサ５２は、ＣＰＵなどの演算コアである。ＲＡＭ５３は、書き換え可能な揮発性メモリである。ストレージ５４は、書き換え可能な不揮発性メモリである。ストレージ５４には、無線通信装置８とサーバ４とのデータ通信を中継するためのプログラムである中継サーバプログラムが保存されている。中継サーバプログラムは、ＡＣＰクラウドソフトウェアと呼ぶこともできる。

　サーバプロセッサ５２は、無線通信装置８やサーバ４と制御信号をやり取りすることで、各種装置のアドレス情報やポート番号といった、通信経路情報（いわゆる5-tuple）を取得する。アドレス情報は、ＩＰアドレスとＭＡＣ（Media Access Control）アドレスの何れか一方であってもよいし、両方であってもよい。

　中継サーバ５は、随時、サーバ４に対してアプリ９との通信に必要な情報を通知する。アプリ９との通信に必要な情報とは、アプリ９に割り当てられている通信経路情報などである。中継サーバ５は無線通信装置８にも、サーバ４との通信に必要な情報を通知する。中継サーバ５は通信経路情報を用いてアプリ９－サーバ４間の秘匿化／暗号化されたデータ通信を中継する。

　なお、中継サーバ５は複数のコンピュータを用いて実現されていても良い。中継サーバ５が提供する機能の一部又は全部は、各サーバ４が有していてもよい。中継サーバ５は、サーバ４と統合されていても良い。加えて、中継サーバ５は任意の要素であって省略されても良い。つまり、車両Ｖｃとサーバ４とは中継サーバ５を介さずにデータ通信を実施するように構成されていても良い。

　＜ＥＣＵについて＞
　車載システム１が備える複数のＥＣＵ７はそれぞれ、図３に示すように、車両内ネットワークＮｗを介して無線通信装置８と接続されている。車両内ネットワークＮｗは、車両内に構築された通信ネットワークである。車両内ネットワークＮｗの規格は、Controller Area Network（ＣＡＮは登録商標）や、イーサネット（登録商標）など、任意の規格であってよい。車両内ネットワークＮｗが第１のネットワークに相当する。なお、一部のＥＣＵ７は、車両内ネットワークＮｗを介することなく直接的に無線通信装置８と接続されていてもよい。また、或るＥＣＵ７と無線通信装置８との間には他のＥＣＵ７が介在していても良い。

　図３に示す例では、ＥＣＵ７として、４つのＥＣＵ７ａ～７ｄが無線通信装置８に接続されている場合を例示している。無線通信装置８に接続するＥＣＵ７の数は適宜変更可能である。無線通信装置８に接続するＥＣＵ７は１つだけであってもよい。複数のＥＣＵ７はそれぞれ役務／制御対象等が異なる。

　各ＥＣＵ７は、図４に示すように、ＥＣＵプロセッサ７１と、ＲＡＭ７２と、ＲＯＭ（Read Only Memory）７３などを備えるコンピュータであってよい。ＥＣＵプロセッサ７１はＣＰＵなどの演算コアである。各ＥＣＵ７は、ＲＯＭ７３に格納されているプログラムを実行することで、当該プログラムに応じた処理を実行する。各ＥＣＵ７には固有の識別情報であるＥＣＵ－ＩＤが割り当てられている。

　ＥＣＵ７は、１つ又は複数のアプリ９を実行可能に構成されている。なお、複数のＥＣＵ７が連携して１つのアプリ９を実行するように構成されていても良い。図３に示す第１アプリ９１はＥＣＵ７ａによって実行されるアプリ９であり、第２アプリ９２及び第３アプリ９３は、ＥＣＵ７ｂによって実行されるアプリ９である。第４アプリ９４はＥＣＵ７ｃ、７ｄの協働によって実現されるアプリ９である。

　なお、図中の「Ａｐｐ」はアプリケーション／アプリの略である。また、図中の「ＡｐｐＮ」は第Ｎアプリを意味する。例えば「Ａｐｐ１」は第１アプリ９１を指し、「Ａｐｐ２」は第２アプリ９２を指す。各アプリ９は、前述のＡＶＰアプリなど多様なアプリであってよい。複数のアプリ９はそれぞれ異なるサービス／機能を提供する。

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

　＜アプリの作動について＞
　アプリ９は、当該アプリ９に対応するサーバ４を宛先とする送信用データを無線通信装置８に出力する。また、アプリ９は、サーバ４からのデータを無線通信装置８から取得する。各アプリ９は、サーバ４へ向けた送信用データの発生等に伴って、無線通信装置８に向けて通信開始要求を出力する。通信開始要求は、データ通信の開始を要求する所定の電気信号、メッセージ、又は通信フレームに相当する。通信開始要求は、アプリＩＤを含む。また、通信開始要求は、サーバ４とのデータ通信に係る条件を示す通信条件を含みうる。

　通信開始要求は、図５に示すように、アプリＩＤと、通信条件と、通知先アドレスと、通知条件と、通知レベルと、を含みうる。図中のＦｃ１は通信フレームにおいてアプリＩＤが配置される領域であるアプリＩＤフィールドを示している。Ｆｃ２は通信フレームにおいて通信条件が配置される領域である通信条件フィールドを示している。Ｆｃ３は通信フレームにおいて通知先アドレスが配置される領域である通知先アドレスフィールドを示している。Ｆｃ４は通信フレームにおいて通知条件が配置される領域である通知条件フィールドを示している。Ｆｃ５は通信フレームにおいて、通知レベルが配置される領域である通知レベルフィールドを示している。

　通信条件を構成する項目としては、図６に示すように、（Ａ）許容待ち時間、（Ｂ）許容ＲＴＴ、（Ｃ）通信頻度、（Ｄ）平均サイズ、（Ｅ）最小帯域、（Ｆ）緊急性、及び（Ｇ）制御利用性などがある。

　（Ａ）許容待ち時間は、いつまでに通信を開始する必要が有るか、換言すれば、アプリ９が許容可能な通信開始までの待ち時間を示す。なお、図６中の設定値例の欄に示す「ｄ」、「ｈ」、「ｍｉｎ」、「ｓ」、「ｍｓ」は順に「日」、「時」、「分」、「秒」、「ミリ秒」など、時間の単位を示す。（Ｂ）許容ＲＴＴは、許容可能な応答遅延時間を示す。ＲＴＴは、ラウンドトリップタイム（Round-Trip Time）の略である。

　（Ｃ）通信頻度は、データ送信／受信の実行頻度を示す。（Ｄ）平均サイズは、アプリ９とサーバ４との間でやり取りされる１つのデータセットのサイズの想定値を示す。（Ｅ）最小帯域は、確保されるべき通信帯域の最小値を示す。最小帯域は１０Ｍｂｐｓや１Ｍｂｐｓといった通信速度の概念で表現されうる。最小帯域は、通信頻度や平均サイズなどに基づいて無線通信装置８が算出及び設定しても良い。

　（Ｆ）緊急性は、緊急性の高い通信であるか否か、換言すれば、直ちに通信が開始されるべき通信であるか否かを示す。緊急性は、フラグで表現されてよい。緊急性フラグが１（オン）の場合は緊急性の高い通信であることを示し、緊急性フラグが０（オフ）の場合は緊急性の低い通信であることを示す。緊急性フラグがオンに設定されるアプリ９とは緊急通報アプリや、事故データをサーバ４にアップロードするアプリ、盗難検知アプリ等である。緊急性の高さは、上述した許容待ち時間に基づいて無線通信装置８が判断しても良い。

　（Ｇ）制御利用性は、サーバ４とやり取りされるデータが車両Ｖｃの走行制御に使用されるデータであるか否かを示す。制御利用性は、フラグで表現されてよい。制御利用性フラグが１（オン）の場合は、車両制御に使用されるデータを取り扱う通信であることを示し、制御利用性フラグが０（オフ）の場合は、車両制御には関係ない／関係性が薄いデータを取り扱う通信であることを示す。緊急性と制御利用性は、何れも重要性、すなわち重要な通信であるか否かを示す。緊急性と制御利用性の項目は、重要性といったパラメータに統合されていても良い。

　なお、アプリ９が無線通信装置８に伝える通信条件は、上記全ての項目を含む必要はない。上記の項目群は一例であって、通信条件の具体的な項目の組み合わせは適宜変更可能である。また、上記以外にも通信条件は、Ｗｉ－Ｆｉ回線を積極的に使うことを希望するかなどのフラグを含んでいても良い。

　本実施形態では一例として、アプリ９毎の通信条件は通信開始要求に含まれる形で無線通信装置８に伝達されるが、通信条件の通知態様はこれに限定されない。アプリ９は、通信開始要求とは別に、自発的に通信条件を示すメッセージを送出してもよい。また、アプリ９は、無線通信装置８からの要求に基づき通信条件を示すメッセージを送信してもよい。その他、アプリ９は、走行用電源のオンに伴ってＥＣＵ７と無線通信装置８とが通信接続したタイミングで、無線通信装置８に向けて通信条件を送信されてもよい。アプリ９は、サーバ４向けの通信トラフィック（換言すれば送信用データ）が発生したことに基づいて、無線通信装置８に通信条件等を都度送信しても良い。その他、通信条件は、各アプリ９から無線通信装置８に向けて送信されたデータのヘッダなどに記述されていても良い。

　通知先アドレスフィールドＦｃ３に格納される通知先アドレスは、無線通信装置８が後述する通信状況通知の宛先を特定するための情報である。通信状況通知は、アプリ９の使用回線が輻輳している、あるいは帯域制限中であるなどといった通信の現況と、その理由を示すデータを含む。また、通信状況通知は、付加情報（換言すれば参考情報）として、推奨制御内容や、制御判断材料などを含みうる。通信状況通知の詳細については別途後述する。

　通知先アドレスとしては、車両内ネットワークＮｗにおけるＥＣＵ７の通信アドレスなどであってよい。なお、アプリＩＤをもとに無線通信装置８が通信状況通知の送信先を特定可能な場合には、通知先アドレスフィールドＦｃ３は省略されても良い。

　通知条件フィールドＦｃ４は、無線通信装置８に通信状況通知を送信させる条件である通知条件を指定するコードが格納される。通知条件は、所定時間以内に輻輳が予測される場合、軽度の輻輳が生じた場合、重度の輻輳が生じた場合、使用中の回線が利用不能となった場合などであってよい。また、輻輳／帯域制限の理由なども送信条件の構成要素として採用可能である。なお、本開示における重度の輻輳とは遅延時間が所定の第１閾値（例えば１０秒）以上となる状態である。重度の輻輳状態とは実質的に通信不能な状態や、通信接続が遮断された状態も含めることができる。軽度の輻輳とは遅延時間が第２閾値（例えば５秒）以上、第１閾値未満となる状態である。第２閾値は第１閾値よりも所定量小さい値に設定されうる。

　通知レベルフィールドＦｃ５には、通信状況通知として、アプリ９が無線通信装置８から通知して欲しい情報の細かさ／量を指定するコードが格納される。参考情報の細かさ／量は、レベル１～３の３段階で表現されてよい。レベル値が大きいほど、より多くの／より細かい情報の提供を希望することを示す。レベル１が最も情報量が少ない。

　レベル１は、輻輳が生じているか否かといった通信状況の事実と、その理由の通知を希望するレベルである。レベル２は、通信状況と、その理由に加えて、推奨制御内容の通知（提案）を希望するレベルである。レベル３は、通信状況と、その理由、推奨制御内容に加えて、制御判断材料の通知を希望するレベルである。本開示ではアプリ９が通知を希望する項目の種別等を示すレベルのことを通知レベルと称する。通知レベルは、換言すれば、無線通信装置８がアプリ９に対して通知する項目を定めるパラメータに相当する。通知レベルフィールドＦｃ５は、通知希望の項目（換言すれば要求項目）を示すコードが配置されるフィールドであってもよい。なお、通知レベルとしては、アプリ９が通信状況通知の送信を希望しない／無線通信装置８が通信状況通知を送信しないレベル０が用意されていても良い。

　＜無線通信装置について＞
　無線通信装置８は、少なくとも１つの加入者識別モジュール（以降、ＳＩＭ：Subscriber Identity Module）を備えることにより、少なくとも１つのセルラー回線を利用可能に構成されている。ＳＩＭは、回線の契約者を識別するための情報が記録されたＩＣモジュールであって、ＩＣカードとして構成されている。ＳＩＭの搭載により無線通信装置８は、当該ＳＩＭに対応する少なくとも１つのＡＰＮ（Access Point Name）を用いたデータ通信を実施可能に構成されている。ＳＩＭに対応するＡＰＮとは、当該ＳＩＭの情報に基づき利用可能なＡＰＮを指す。本実施形態の無線通信装置８は一例として、それぞれＡＰＮが異なる２つのセルラー回線を利用可能に構成されている。以降では無線通信装置８がＳＩＭを用いて利用可能な２つセルラー回線のことを第１回線、第２回線と称する。

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

　無線通信装置８には、固有の識別情報としての通信機ＩＤが割り当てられている。通信機ＩＤは、中継サーバ５やサーバ４が、複数の無線通信装置８（車両Ｖｃ）のそれぞれを識別するための情報として機能する。無線通信装置８は、インストゥルメントパネル内に収容されていてよい。なお、無線通信装置８は、ユーザが車両Ｖｃに対して着脱可能に構成されたデバイスであってもよい。また、無線通信装置８は、ユーザによって車室内に持ち込まれた、スマートフォン等の携帯端末であってもよい。

　無線通信装置８は、通信プロセッサ８１、ＲＡＭ８２、ストレージ８３、車内通信部８４、及びこれらを接続するバス等を備えたコンピュータを主体として構成されている。また、無線通信装置８は、無線通信部８５及び温度センサ８６を備える。無線通信部８５は、セルラー通信部８５ａとＷｉ－Ｆｉ通信部８５ｂを備える。

　通信プロセッサ８１は、ＲＡＭ８２と結合された演算処理のためのハードウェアである。通信プロセッサ８１は、ＣＰＵ等の演算コアを少なくとも一つ含む。通信プロセッサ８１は、ＲＡＭ８２へのアクセスにより、種々の処理を実行する。通信プロセッサ８１から見て、自分自身を備える無線通信装置８が自装置に相当する。

　ストレージ８３は、フラッシュメモリ等の不揮発性の記憶媒体を含む装置である。ストレージ８３には、通信プロセッサ８１によって実行されるプログラムとして、通信制御プログラムが格納されている。通信プロセッサ８１が上記プログラムを実行することは、通信制御プログラムに対応する通信制御方法を通信プロセッサ８１が実行することに相当する。ストレージ８３には、無線通信装置８が利用可能なＡＰＮについての情報（例えばプロファイル）が登録されている。また、ストレージ８３には、無線通信装置８が利用可能なＷｉ－ＦｉのＳＳＩＤ（Service Set Identifier）や暗号化キーなどが登録されている。

　またストレージ８３には、電波マップが保存されている。電波マップは、道路上の地点／所定区間ごとの電波強度を示すデータである。電波マップは、地点ごとの上り／下りスループットや往復レイテンシなどを示すデータであってもよい。電波マップは、地点ごとのＣＳＩ（Channel State Information）を示すデータであってもよい。電波マップは中継サーバ５やセルラー基地局２から配信されうる。電波マップは動的に更新されうる。無線通信装置８における電波マップの保存先はＲＡＭ８２等の揮発性メモリであってもよい。

　通信プロセッサ８１はストレージ８３にインストールされている通信制御プログラムを実行する事により、車内通信部８４及び無線通信部８５の動作を制御する通信マネージャ８７として動作する。通信マネージャ８７は、アプリケーション層及びトランスポート層の一部又は全部としての処理を実行する。通信マネージャ８７の詳細は別途後述する。

　車内通信部８４は、車両内ネットワークＮｗを介してＥＣＵ７と通信するための回路モジュールである。車内通信部８４は、各ＥＣＵ７が出力した送信用データを受け取り、通信マネージャ８７へ出力する。また、車内通信部８４は、通信プロセッサ８１から入力されたデータを、宛先として指定されたＥＣＵ７に向けて出力する。車内通信部８４は、各ＥＣＵ７から多重化されて入力されたデータを、所定の方式で分離することで、本来のデータを取得する。このような車内通信部８４は、アナログ回路素子やＩＣ、車両内ネットワークＮｗの通信規格に準拠したＰＨＹチップなどを用いて実現されている。車内通信部８４には、ＥＣＵ７から入力された送信用データのほか、車速センサが検出した車速データなど、多様なデータが入力される。ここでの送信用データとは、サーバ４向けの通信トラフィック（換言すればデータ）に相当する。

　セルラー通信部８５ａは、４Ｇ等の無線通信プロトコルにおけるデータリンクレイヤ及び物理レイヤを担当する通信モジュールである。セルラー通信部８５ａは、ＬＴＥで用いられる周波数帯の電波を送受信可能なアンテナを含む。また、セルラー通信部８５ａは、ベースバンド信号から高周波信号への変換及びその逆変換に相当する信号処理を行うトランシーバと、ＩＰパケットと物理チャネルの信号との変換を行うパケット処理部と、を含む。

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

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

　なお、Ｗｉ－Ｆｉ通信部８５ｂは、Ｗｉ－Ｆｉ基地局６から発せられるビーコンを受信することによって、Ｗｉ－Ｆｉ基地局６の存在を認識する。Ｗｉ－Ｆｉ通信部８５ｂとＷｉ－Ｆｉ基地局６との通信接続は、通信マネージャ８７によって制御される。また、Ｗｉ－Ｆｉ通信部８５ｂの動作状態、電源状態は、通信マネージャ８７によって制御される。なお、Ｗｉ－Ｆｉ通信部８５ｂは、必ずしも無線通信装置８に内蔵されている必要はない。Ｗｉ－Ｆｉ通信部８５ｂは無線通信装置８の外部に設けられていても良い。

　温度センサ８６は、通信プロセッサ８１周辺の温度を検出するセンサである。温度センサ８６の出力値は、ＲＡＭ８２等を介して通信プロセッサ８１に入力される。温度センサ８６は、チップ温度を計測するセンサに相当する。なお、ここでのチップとは無線通信に係る処理を実行するＣＰＵやＩＣなどを指す。本開示のチップ温度は、通信プロセッサ８１の温度であってもよいし、セルラー通信用のチップの温度であってもよい。

　＜通信マネージャの機能について＞
　通信マネージャ８７はアプリ９とサーバ４との通信を中継及び制御する存在である。アプリ９が送出したデータ（いわゆるメッセージ）は、図７に示すようにネットワーク層（Ｌ３）、データリンク層（Ｌ２）、物理層（Ｌ１）を経由して、無線通信装置８に入力される。無線通信装置８に到達したアプリ９からのデータは、通信マネージャ８７にて指定されている通信回線を用いてサーバ４に向けて無線送信される。

　通信マネージャ８７は、機能ブロックとして図８に示すように接続制御部Ｆ１、回線状態取得部Ｆ２、通信要求受付部Ｆ３、通信状態管理部Ｆ４、動的制御部Ｆ５、及び通知処理部Ｆ６を備える。通信マネージャ８７は、ＡＣＰを構成する車両側の機能部であるＡＣＰエンジンに相当する。

　接続制御部Ｆ１は、セルラー通信部８５ａの動作を制御する。接続制御部Ｆ１は、所定の接続イベントが生じたことを受けて、ＡＰＮ毎の通信回線を確立する手続きを実行する。通信接続を確立するための手続きには、アタッチ要求の送信やＡＰＮ情報の送信などが含まれる。接続イベントとしては、走行用電源がオンとなった場合や、車両Ｖｃが備える操作部材に対する所定のユーザ操作に基づき、セルラー通信機能が有効化された場合などを採用可能である。

　また、接続制御部Ｆ１は、セルラー回線毎の在圏セルを決定及び移動管理を実施する。接続制御部Ｆ１は、在圏セルを選択するための指標として、セル毎のＲＳＲＰや、ＲＳＳＩ、ＲＳＲＱなどを取得する。本開示における「取得」には、他の装置／センサから入力されたデータなどを元に内部演算によって生成／検出することも含まれる。ＲＳＲＰは、Reference Signal Received Powerの略である。ＲＳＳＩはReceived Signal Strength Indicatorの略である。ＲＳＲＱはReference Signal Received Qualityの略である。ＲＳＲＰは、単位リソースエレメント当たりのＲＳの平均受信電力である。ＲＳＳＩは、ＲＳを収容するＯＦＤＭシンボルにおいてＬＴＥシステム帯域全体の電力を測定した値である。ＲＳＲＱは、セル固有の参照信号の受信電力と、受信帯域幅内の総電力との比である。ＲＳＲＱは、大きいほどセルラー基地局２からの信号の受信品質が良いことを示す。

　そして、接続制御部Ｆ１は、セル毎のＲＳＲＰなどの指標に基づき、必要に応じて在圏セルを切り替えるための処理を実施する。接続制御部Ｆ１が算出した在圏セルや隣接セルといったセル毎のＲＳＲＰやＲＳＲＱなどの情報は、ＲＡＭ８２に一時的に保持される。ＲＡＭ８２が保持する情報は随時更新される。なお、在圏セルの切り替え（再選択）を行う機能はセルラー通信部８５ａが備えていても良い。また、ＲＳＲＰなどの取得は、回線状態取得部Ｆ２が実施してもよい。

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

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

　また、回線状態取得部Ｆ２は、セルラー回線毎の状態情報として、セルラー回線毎のＲＴＴやスループットを逐次評価し、ＲＡＭ８２に保存しても良い。ＲＴＴは、通信相手に信号やデータを発信してから、応答が返ってくるまでにかかる時間、すなわち応答遅延時間である。ＲＴＴは、往復レイテンシとも称される。スループットは、伝送路を通じて単位時間あたりに送受信できるデータ量を表す。スループットは通信速度を示す指標に相当する。回線状態取得部Ｆ２は、スループットを上り通信と下り通信とで別々に取得してもよい。回線状態取得部Ｆ２は、接続制御部Ｆ１からＲＳＲＰやＲＳＲＱなどの観測値を取得しても良い。回線状態取得部Ｆ２は、上記パラメータの一部又は全部に基づいて、セルラー回線毎のＱｏＳを評価してもよい。

　回線状態取得部Ｆ２としての通信プロセッサ８１は、通信回線毎に輻輳が生じているか否かを判断する。輻輳の判断材料としては、パケットロス率、遅延時間、及びそれらの両方を採用可能である。回線状態取得部Ｆ２は、パケットロス率が所定値以上である場合に輻輳が生じていると判定する。また、回線状態取得部Ｆ２は、応答遅延時間が所定値以上である場合に輻輳が生じていると判定する。輻輳の検知方式としては、NewReno、Vegas、Illinois、YeAH、DCTCPなどといった、ＴＣＰの輻輳制御で使用される多様な方式を援用可能である。回線状態取得部Ｆ２は、輻輳の発生／通信帯域の不足を予測するものであってもよい。

　また、通信プロセッサ８１は、無線通信装置８内部での輻輳を検知可能に構成されていてもよい。複数のアプリ９からのアクセスが通信マネージャ８７に集中している状態も一種の輻輳に相当する。通信プロセッサ８１は、通信用のバッファ／キューへのデータの滞留度合いに基づいて無線通信装置８内部での輻輳（高負荷状態）を検出しうる。また、車両内ネットワークＮｗが混雑している状態も輻輳の一種に相当する。本開示では、無線区間以降での輻輳を車外輻輳、無線通信装置８内部での輻輳を装置内輻輳、車両内ネットワークＮｗでの輻輳を車内輻輳とも称する。通信プロセッサ８１は、車外輻輳に限らず、装置内輻輳や、車内輻輳を検出可能に構成されていても良い。

　通信要求受付部Ｆ３は、車両内外からのデータ通信の要求を受け付ける。車両内部からの通信開始要求とは、アプリ９からの通信開始要求に相当し、車両外部からの通信開始要求とは、サーバ４からの通信開始要求に相当する。なお、サーバ４からの通信開始要求は、中継サーバ５を介して無線通信装置８に到達するため、車両外部からの通信開始要求は中継サーバ５からの通信開始要求と解することもできる。

　通信要求受付部Ｆ３は、アプリ９からの通信開始要求を受信したことに基づいて、当該アプリ９と対応するサーバ４との通信を開始するための手続き（経路設定）等を開始する。また、通信要求受付部Ｆ３は、中継サーバ５から、或るアプリ９向けのデータが存在することが通知された場合、対象となるアプリ９とサーバ４との通信開始要求を受け付ける。

　通信要求受付部Ｆ３は、各アプリ９から通信開始の要求とともに／独立して、通信条件を取得する。通信要求受付部Ｆ３が受け付けた通信要求及び条件は、要求元としてのアプリ９毎に区別してＲＡＭ８２に一時保存される。なお、アプリ９ごとの通信条件は、時間の経過に伴って動的に変更されうる。

　通信状態管理部Ｆ４は、アプリ９の通信状態を管理する。アプリ９ごとの通信状態は、図９に示すように、優先度や、実行状態、制限の有無、通信頻度、データサイズなどの複数の項目を含むテーブルで管理されうる。優先度は、通信回線の割当やパケット転送に係る優先順位を示すパラメータである。図９に示す例では第２アプリ９２が最も優先順位が高いことを示している。通信状態管理部Ｆ４は、アプリ９ごとの優先順位を、通信条件に示される緊急性や、制御利用性、許容ＲＴＴ、許容待ち時間などをもとに動的に設定する。なお、アプリ９毎の優先度は予め設定された固定値であってもよい。また、アプリ９毎の優先度は、車両Ｖｃが走行中か否かに応じて切り替えられてもよい。制御支援アプリの優先度は、停車中は走行中に比べて低く設定されても良い。

　実行状態の欄には、通信中か、休止中かを示す値が設定される。通信中とは、実際にデータ通信を実施している状態を指す。休止中とは、通信を停止している状態に相当する。休止中とは、接続を維持したままデータの送受信を停止している状態（いわゆるアイドル状態）であってよい。休止中は、通信接続を解除している状態であってもよい。帯域制限の欄には、アプリ９の通信帯域に制限をかけているか否かを示す値が入力される。帯域制限をかけている場合とは、利用可能な帯域を所定値以下に制限している状態を指す。利用可能な通信帯域の設定値（上限値）は０であってもよく、帯域制限をかけている状態には実質的に通信を遮断／禁止している状態を含めることができる。

　通信頻度の欄は、サーバ４との通信の実行頻度を示す。通信頻度は、直近所定時間以内における実際の通信頻度をもとに決定されてもよい。また、通信頻度の欄には、通信条件に示される通信頻度の値、換言すればアプリ９が自己申告してきた値が入力されても良い。データサイズの欄は、アプリ９－サーバ４間でやり取りされる１つのデータセット（例えばファイル）の平均サイズを示す。データサイズは、過去に送受信されたファイルのサイズをもとに決定される。また、データサイズの欄には、通信条件に示される平均データサイズの値、換言すればアプリ９が自己申告してきた値が登録されてもよい。

　その他、通信状態テーブルには通知レベルが含まれていても良い。通信状態管理部Ｆ４はアプリ９ごとの通知レベルも管理しうる。また、通信状態管理部Ｆ４は、アプリ９ごとの通信状態に応じて通信状態テーブルの値を随時更新する。通信状態管理部Ｆ４が保持する通信状態テーブルは、動的制御部Ｆ５によって参照される。

　動的制御部Ｆ５は、優先度制御や、回線割当、帯域制御などを実施する。優先度制御は、アプリ９に設定されている優先度に基づいて、アプリ９から入力された送信用データ（通信パケット）の送信順序を調整する処理を指す。回線割当は、アプリ９毎の通信条件及び通信回線毎の特性に基づいて各アプリ９に割り当てる通信回線を決定／変更する処理を指す。なお、通信経路を構成する要素には、通信回線の種別のほか、割り当てる通信帯域の大きさ（幅）や、割当周波数などを含めることができる。帯域制御は、アプリ９に割り当てる通信帯域を調整する処理を指す。

　動的制御部Ｆ５は、通信回線の状況や無線通信装置８の内部状態に基づいて、一部又はすべてのアプリ９に対して通信帯域を制限する処理を実施する。動的制御部Ｆ５は、回線状態取得部Ｆ２が或る通信回線での輻輳を検知した場合、輻輳が生じている回線である輻輳回線を使用しているアプリ９の組み合わせに基づいて、帯域制限をかけるアプリ９を選定する。そして、該当アプリ９に対して必要に応じたレベルの帯域制限をかける。また、動的制御部Ｆ５は、チップ温度や、通信プロセッサ８１の負荷状況など、通信マネージャ８７の内部状態によってもアプリ９への帯域制限を実施しうる。

　通知処理部Ｆ６は、通信状況等に係るメッセージをアプリ９とやり取りする処理モジュールである。通知処理部Ｆ６としての通信プロセッサ８１は、或るアプリ９が使用可能な通信帯域に変化が生じた場合、又は、或るアプリ９の通信速度に影響を与える事象の発生を検出した場合に、該当アプリ９に向けて通信状況通知を送信する。

　通知処理部Ｆ６は、動的制御部Ｆ５が或るアプリ９に対して帯域制限をかけることを決定した場合、当該対象アプリに対して、帯域制限通知を送信する。帯域制限通知は、帯域制限中であることと、その理由を示す信号である。なお、帯域制限は１つのシーンにおいて輻輳の発生とともに実施される。故に、帯域制限通知は、１つの局面において、アプリ９の使用回線が輻輳していることと、その理由を示す信号に相当する。帯域制限通知は、通信マネージャ８７がアプリ９に対して、使用回線の輻輳／帯域制限の実施を通知するためのメッセージに相当する。なお、通知処理部Ｆ６は、動的制御部Ｆ５が或るアプリ９に対して実際に帯域制限をかける前の時点、回線状態取得部Ｆ２が或る通信回線での輻輳を検知したタイミングで、該当回線を使用中のアプリ９に対して帯域制限通知を送信しても良い。

　また、通知処理部Ｆ６は、或る通信回線が干渉や通信圏外への移動によって一時的に利用不能となった場合、当該通信回線を利用していたアプリ９に対し、回線切断通知を送信する。回線切断通知は、使用回線が利用不能となったこと、及び、その理由を示す信号である。なお、通信プロセッサ８１は、帯域制限処理の結果として通信回線が遮断（切断）状態となったアプリ９に対しては、回線切断通知の代わりに、帯域制限通知を送信しても良い。

　さらに、本実施形態の通知処理部Ｆ６はより好ましい態様として、チップ温度上昇などの理由によって通信速度（通信スループット）が所定値以下となった通信回線が存在する場合、当該回線を使用しているアプリ９に対して速度低下通知を送信しうる。速度低下通知は、低速状態であること、及びその理由を示す信号に相当する。通信プロセッサ８１は、帯域制限処理の結果として通信が低速状態となったアプリ９に対しては、速度低下通知の代わりに、帯域制限通知を送信しても良い。

　以上で述べた帯域制限通知、回線切断通知、及び速度低下通知は何れも、通信状況通知の一種に相当する。帯域制限通知、回線切断通知、及び速度低下通知のフレーム構成は同じである。もちろん、他の態様として帯域制限通知、回線切断通知、及び速度低下通知はそれぞれ異なるフレーム構成を有していても良い。以下の説明における通信状況通知との記載は適宜、帯域制限通知、回線切断通知、又は速度低下通知と読み替えることができる。

　通信状況通知の中身／構成は、通知対象とするアプリ９の通知レベルによって異なりうる。例えば、通知レベルが１に設定されているアプリ９に対して送信される帯域制限通知は、図１０に示すようにメッセージタイプフィールドＦｄ１と、理由フィールドＦｄ２と、を備える。

　メッセージタイプフィールドＦｄ１は、当該メッセージが帯域制限通知、回線切断通知、及び速度低下通知の何れに該当するか（つまりメッセージのタイプ）を示す。帯域制限通知である場合、メッセージタイプフィールドＦｄ１には使用回線に輻輳が生じていること／帯域制限中であることを示す所定コードが配置される。

　理由フィールドＦｄ２は、帯域制限や回線遮断、速度低下（以降、帯域制限等）の理由を示すコードが配置される領域である。帯域制限等の理由としては、図１１に示すように「優先度負け」や、「トラフィック急増」、「環境劣化」、「チップ温度上昇」、「回線切断」、「重要サービス作動中」、「３Ｇ回線使用中」、「干渉回避」、「高負荷状態」、「契約上限到達」などがある。

　これらの理由は、１つの側面において、帯域制限の理由である制限理由と呼ぶことができる。また、下記理由の一部は、回線切断の理由である切断理由、或いは、通信速度低下の理由である速度低下理由と呼ぶこともできる。各理由には、理由を示すコードである理由コードが割り当てられている。図１１に示す理由コードの値は一例であって適宜変更可能である。

　なお、「優先度負け」は、優先度の高い他のアプリ９のトラフィックと競合した結果として、或るアプリ９が利用可能な通信帯域を制限（縮小）する場合に対応する。通知処理部Ｆ６は、優先度負けによる帯域制限が施されるアプリ９に対し、理由フィールドＦｄ２に優先度負けであることを示すビット列を配置した帯域制限通知を送信する。

　「トラフィック急増」は、通信データ量が増加し輻輳が発生した場合に対応する。例えば大容量かつ重要なデータのやり取りが開始された場合にトラフィック急増が生じうる。「トラフィック急増」は、電波環境や、ネットワーク側装置から通信マネージャ８７に対して割り当てられている帯域自体の変動は比較的小さい場合に適用されうる。通知処理部Ｆ６は、トラフィック急増による帯域制限が施されるアプリ９に対しては、理由フィールドＦｄ２にトラフィック急増であることを示すビット列を配置した帯域制限通知を送信する。

　「環境劣化」は、通信環境が悪化し輻輳が発生した場合に対応する。通知処理部Ｆ６は、環境劣化に起因して帯域制限が施されるアプリ９に対しては、理由フィールドＦｄ２に環境劣化を示すビット列を配置した帯域制限通知を送信する。なお、環境劣化による帯域制限は、通信マネージャ８７が中継するトラフィックの増加量は所定値未満である場合に適用されうる。つまり、通信マネージャ８７が取り扱うトラフィック量は変わっていないものの、利用可能な無線リソースが縮小した結果として輻輳が生じた／予見される場合に、通信プロセッサ８１は環境劣化によるアプリ単位での帯域制限を実施しうる。

　「チップ温度上昇」は、通信プロセッサ８１の温度が上昇したため、通信スループットが抑制された場合に対応する。通信プロセッサ８１は、温度センサ８６の出力に基づいて、チップ温度が所定値以上か否かを判定する。通信プロセッサ８１は、チップ温度が所定値以上である場合には、通信速度／処理速度が低速状態に遷移しうる。低速状態とは、速度が所定値以下である状態を指す。例えば低速状態は、通信速度／処理速度が最大値／平均値の１０％以下である状態であってよい。通知処理部Ｆ６は、チップ温度上昇に伴う速度低下が生じる回線を使用中のアプリ９に対しては、理由フィールドＦｄ２にチップ温度上昇であることを示すビット列を配置した速度低下通知／帯域制限通知を送信する。

　「回線切断」は、何らかの事情でセルラー回線が切断した場合や、Ｗｉ－Ｆｉ回線使用中においてＷｉ－Ｆｉのアクセスポイントの圏外となった場合に対応する。通知処理部Ｆ６は、切断された回線を使用していたアプリ９に対しては、理由フィールドＦｄ２に回線切断を示すビット列を配置した回線切断通知を送信する。

　「重要サービス作動中」は、緊急通報サービスや、自動運転サービスなど、人命に関わる重要サービスが作動中であり、その結果として通信帯域が不足した場合に対応する。通知処理部Ｆ６は、重要サービス作動に起因して帯域制限が施されるアプリ９に対しては、理由コードに重要サービス作動中であることを示すビット列を配置した帯域制限通知を送信する。なお、他の実施形態においては、重要サービス作動中は、優先度負けと統合されていても良い。

　「３Ｇ回線使用中」は、通信マネージャ８７がＬＴＥ／４Ｇの圏外となりスループットが低下している状態に対応する。「干渉回避」は、電波干渉抑止のための出力制限を実施中である場合に対応する。通信プロセッサ８１は、無線通信部８５が観測しているノイズレベル等に基づいて干渉電波の有無を判断可能である。「高負荷状態」は、通信プロセッサ８１が高負荷状態である場合に対応する。通信プロセッサ８１は、高負荷状態に起因して帯域制限がかけられているアプリ９に対して、理由フィールドＦｄ２に高負荷状態であることを示すビット列を配置した帯域制限通知を送信する。「契約上限到達」は、通信データ量が契約上の上限値に到達／超過している場合に対応する。

　また、通知レベルが２又は３に設定されているアプリに対して送信される帯域制限通知は、図１２に示すように、メッセージタイプフィールドＦｄ１と理由フィールドＦｄ２に加えて、推奨制御フィールドＦｄ３と補足情報フィールドＦｄ４を備える。推奨制御フィールドＦｄ３は、推奨制御内容を示す領域である。推奨制御内容は、帯域制限等に対してアプリ９が取るべき応答方針を示す。推奨制御内容を示す帯域制限通知を送信することは、通知先のアプリ９に対して、当該制御の実行を推奨／提案／指示することに相当する。

　補足情報フィールドＦｄ４は、推奨制御内容に関連する情報が格納される領域である。補足情報フィールドＦｄ４のビット長は動的に調整可能であっても良い。推奨制御内容や補足情報が参考情報に相当する。

　推奨制御内容のバリエーションとしては例えば、図１３に示すように、「一定時間待機」、「再開指示待機」、「タイミングシフト」、「リトライ間隔動的制御」、「回線切替」、「セルラー回線不使用」などが挙げられる。各推奨制御内容には、固有のコードである推奨制御コードが割り当てられている。図１３に示す推奨制御コードの値は一例であって適宜変更可能である。

　「一定時間待機」は、データ送信／受信を一定時間待機することを意味する。「再開指示待機」は、サーバ４とのデータ通信を再開しても良いことを示す再開許可通知を通信マネージャ８７から受信するまでは通信を休止することを意味する。一定時間待機の場合、アプリ９は通信マネージャ８７からの再開許可通知を受信しなくとも、所定時間後には通信を実施しうる。通信マネージャ８７は、輻輳などの速度低下／遮断理由が解消するまでの時間の予測が困難な場合に、一定時間待機ではなく再開指示待機を推奨制御として選択しうる。

　「タイミングシフト」は、データの送信タイミングをシフトすることを意味する。なお、一定時間待機もタイミングシフトの一種に相当する。一定時間待機は待機時間が固定値或いは通信マネージャ８７の指示値であるのに対し、タイミングシフトは、通信マネージャ８７から提供される補足データに基づき、アプリ９自身が送信タイミングを判断する点で相違する。タイミングシフトは、一定時間待機に比べてアプリ９側での制御難度／自由度が高い制御内容に相当する。

　「リトライ間隔動的制御」はＴＣＰなどでのリトライ間隔をデフォルト値から車両Ｖｃの走行状況に応じて動的に調整することを意味する。リトライ間隔は再送時間と呼ぶこともできる。リトライ間隔動的制御は、停車中はリトライ間隔を６０秒などに設定する一方、走行中は５秒や１０秒など、電波環境の変化が期待できる値に設定する制御を指す。リトライ間隔動的制御は、停止中においてはリトライを停止し、走行中においてはリトライ間隔をデフォルト値よりも所定量増大させることであってもよい。リトライ間隔の増大量は、３秒や１０秒などの一定値であっても良いし、通信マネージャ８７が回線状況に応じて動的に決定しても良い。リトライ間隔のデフォルト値は、帯域制限をかけていない場合に適用される値であって、アプリ９毎に異なりうる。

　「回線切替」は、使用回線を現在の回線とは異なる通信回線に切り替えることを意味する。対象アプリが現在第１回線を使用中である場合、回線切替は、使用回線を第１回線から第２回線又はＷｉ－Ｆｉ回線に切り替えることに相当する。「セルラー回線不使用」は、セルラー回線の使用を極力避けることを意味する。

　帯域制限等の理由に応じた推奨制御の選定は、通知処理部Ｆ６が実施しても良いし、動的制御部Ｆ５が実施しても良い。通信マネージャ８７内における機能配置は適宜変更可能である。

　ところで、本実施形態の通知処理部Ｆ６は、通知レベルが２であるか３であるかによって、通信状況通知に含める参考情報の細かさ／量を変更する。図１４は、制御対象アプリの通知レベルが２に設定されている場合の、推奨制御内容と補足情報の組み合わせの一例を示す図である。また、図１５は、制御対象アプリの通知レベルが３に設定されている場合の、推奨制御内容と補足情報の組み合わせの一例を示す図である。

　通知処理部Ｆ６は、通知レベルが２に設定されているアプリ９に対し、推奨制御として一定時間待機を提案する場合、待機時間や、通信を再開してもよい時刻を示すデータを補足情報フィールドＦｄ４に格納した通信状況通知を送信する。また、通知処理部Ｆ６は、通知レベルが２に設定されているアプリ９に対し、推奨制御として再開指示待機を提案する場合、通信再開を許可する予測時刻や再開条件などが補足情報フィールドＦｄ４に格納された通信状況通知を送信する。

　より具体的には、通知処理部Ｆ６は、環境劣化に起因する再開指示待機を提案する場合、補足情報として帯域制限を解除可能となるまでの予測時間を付加した通信状況通知を送信してもよい。帯域制限を解除可能となるまでの予測時間は、電波マップと自車両の走行計画とをもとに算出されてよい。通知処理部Ｆ６は、チップ温度上昇に起因する再開指示待機を提案する場合、補足情報として現在のチップ温度と、再開可能なチップ温度などを付加した通信状況通知を送信する。通知処理部Ｆ６は、通知レベルが２に設定されているアプリ９に対し、推奨制御としてセルラー回線不使用を提案する場合、Ｗｉ－Ｆｉに接続可能となるまでの予測時間を示すデータを補足情報フィールドＦｄ４に格納した通信状況通知を送信する。

　また、通知処理部Ｆ６は、通知レベルが３に設定されているアプリ９に対し、推奨制御としてタイミングシフトを提案する場合、トラフィック予測データを補足情報フィールドＦｄ４に格納した通信状況通知を送信する。トラフィック予測データは、今後所定時間以内のトラフィック量の予測推移を示すデータである。トラフィック予測データは、他のアプリ９との競合リスクが低い通信タイミングを示すデータに相当する。トラフィック予測データは、現在通信中のアプリ９ごとの通信条件に示される通信頻度や平均データサイズ、最終通信時刻などをもとに生成されうる。

　通知処理部Ｆ６は、通知レベルが３に設定されているアプリ９に対し、リトライ間隔動的制御を提案する場合、通信状態にかかる現況データを補足情報フィールドＦｄ４に格納した通信状況通知を送信する。通信状態にかかる現況データは、現在の通信トラフィックと通信スループットの推定値であってよい。通知処理部Ｆ６は、通知レベルが３に設定されているアプリ９に対し、チップ温度上昇に由来する再開指示待機を提案する場合にも、通信状態にかかる現況データを補足情報フィールドＦｄ４に格納した通信状況通知を送信する。

　通知処理部Ｆ６は、通知レベルが３に設定されているアプリ９に対し、回線切断に起因する回線切替を提案する場合、利用可能回線情報を補足情報フィールドＦｄ４に格納した通信状況通知を送信する。利用可能回線情報とは、現時点で利用可能な通信回線を示す。なお、通知処理部Ｆ６は、回線切断に起因する回線切替を提案する場合、補足情報として電波マップ、又は、通信回線が復旧するまでの予測時間を付加した通信状況通知を送信してもよい。

　通知処理部Ｆ６は、通知レベルが３に設定されているアプリ９に対し、重要サービス作動中に起因する回線切替を提案する場合、作動サービス情報を補足情報フィールドＦｄ４に格納した通信状況通知を送信する。作動サービス情報とは、作動中の重要サービスの種別を示す。作動サービス情報は、当該サービスに係る通信が完了するまでの残り時間の推定値を含んでいても良い。なお、通知処理部Ｆ６は、回線切断や重要サービス作動中に起因する回線切替を提案する場合、補足情報として利用可能回線情報や電波マップを付加した通信状況通知を送信してもよい。

　通知処理部Ｆ６は、通知レベルが３に設定されているアプリ９に対し、３Ｇ回線使用中に起因する再開指示待機を提案する場合、電波マップを補足情報フィールドＦｄ４に格納した通信状況通知を送信する。なお、通知処理部Ｆ６は、３Ｇ回線使用中に起因する再開指示待機を提案する場合、補足情報として４Ｇ復帰予測時間を付加した通信状況通知を送信してもよい。４Ｇ復帰予測時間は、電波マップが備える４Ｇエリア情報と、自車両の現在位置及び移動速度などをもとに算出されうる。４Ｇエリア情報は４Ｇが利用可能なエリアを示す情報である。

　通知処理部Ｆ６は、通知レベルが３に設定されているアプリ９に対し、高負荷状態に起因する再開指示待機を提案する場合、負荷状況データを補足情報フィールドＦｄ４に格納した通信状況通知を送信する。負荷状況データは、通信プロセッサ８１の処理負荷を示すデータである。処理負荷は、例えばＣＰＵやメモリの使用率や、プロセス数、バッファに滞留しているトラフィック量などによって表現されうる。なお、通知処理部Ｆ６は、高負荷状態に起因する再開指示待機を提案する場合、補足情報として処理負荷が所定値未満となるまでの予測時間を付加した通信状況通知を送信してもよい。処理負荷が所定値未満となるまでの予測時間は、直近所定時間以内の処理速度（処理スループット）と、現在の処理負荷量から算出されうる。

　なお、制限理由に応じてアプリ９に提案する推奨制御の具体的な内容は適宜変更可能である。また、補足情報として通知する情報種別も適宜変更可能である。その他、通知レベルが１のアプリ９用の通信状況通知もまた、フレーム構成として、推奨制御フィールドＦｄ３と補足情報フィールドＦｄ４を備えていても良い。その場合には、推奨制御フィールドＦｄ３と補足情報フィールドＦｄ４には、推奨する制御内容がないことを示す所定のコードが挿入されうる。このように通信状況通知の構成は、通知レベルによらずに共通化されていても良い。

　＜システム全体の処理の流れ＞
　次に、図１６及び図１７に示すシーケンス図を用いて、アプリ９、通信マネージャ８７、中継サーバ５、及びサーバ４の相互作用について説明する。図１６、図１７に示す第１アプリ９１、第２アプリ９２はそれぞれ任意のアプリであってよい。以下の説明において第１アプリ９１は、第２アプリ９２よりも優先度が高いアプリである。図１６、図１７に示す第１サーバ４１は第１アプリ９１に対応するサーバ４であり、第２サーバ４２は第２アプリ９２に対応するサーバ４である。図１７は図１６に示すシーケンスの後続シーケンスを示す。図１６、図１７の説明における処理の実行主体としての通信マネージャ８７は、無線通信装置８又は通信プロセッサ８１と読み替えることができる。

　まず、通信マネージャ８７は、所定の接続イベントが生じたタイミングで、ＡＰＮ毎の通信回線を確立する（ステップＳ０１）。つまり、通信マネージャ８７はアプリ９からの通信開始要求に先立って、中継サーバ５との通信経路を確保する。通信マネージャ８７と中継サーバ５との間の通信接続が確立されている状態においては、通信マネージャ８７と中継サーバ５は適宜所定のタイミングで所定の制御信号を送受信することで疎通確認を実施する（ステップＳ０２ｃ）。また、中継サーバ５とサーバ４も、一定時間おきに所定の制御信号を送受信することで疎通確認を実施する（ステップＳ０２ａ、Ｓ０２ｂ）。なお、通信マネージャ８７は、図１６に示す処理フローと並行して、車両Ｖｃの移動に伴うハンドオーバーなどを実行する。また、通信マネージャ８７は、図１６に示す処理フローと並行して、車両Ｖｃの移動に伴うＷｉ－Ｆｉ基地局６との通信接続～切断を繰り返し実行する。

　その後、第１アプリ９１において送信用データが発生すると、第１アプリ９１は通信マネージャ８７に通信開始要求を出力する（ステップＳ１１ａ）。同様に、第２アプリ９２は随時通信マネージャ８７に通信開始要求を出力する（ステップＳ１１ｂ）。アプリ９から通信マネージャ８７へと出力される通信開始要求には、前述の通りアプリＩＤや通信条件、通知条件等を含む。なお、通信条件等は、事前に通信マネージャ８７がアプリ９と通信することで取得しておいても良い。

　通信マネージャ８７は、アプリ９からの通信開始要求を受信すると、当該要求を受け付ける（ステップＳ１２）。具体的には、アプリＩＤと通信条件とを紐付けて所定の記憶領域に一時保存する。図１６では便宜上、要求受付処理に対応するステップを１つしか示していないが、要求受付処理は、通信開始要求毎、つまりアプリ９ごとに実施される。

　通信マネージャ８７は、通信開始要求に基づき、要求元のアプリ９に対し、通知された通信条件を充足する通信回線を割り当て、経路設定処理を実施する（ステップＳ１３）。経路設定処理は例えば、アプリ９用のポートの確保を含む。経路設定処理により、送信元ＩＰアドレスや、ソースポート番号、宛先ＩＰアドレス、宛先ポート番号、プロトコルなどが決定される。なお、ソースポートはアプリ９毎に割り当てられる。１つのポート番号に対応するアプリ９は１つである。通信マネージャ８７は、１つのアプリに対して複数のソースポート番号が割り当てても良い。もちろん、ソースポートの確保、換言すればポート番号の取得は、通信マネージャ８７ではなく、アプリ９自身が実施しても良い。

　なお、本実施形態では、アプリ９のデータ通信を収容するセルラー回線の候補としては、第１回線と第２回線とがある。また、車両Ｖｃが利用可能なＷｉ－Ｆｉ基地局６の通信範囲内に車両Ｖｃが存在する場合には、Ｗｉ－Ｆｉ回線も採用可能な通信経路の選択肢に含めることができる。ここでは第１回線に十分な通信帯域が存在するものとして、通信マネージャ８７は、第１アプリ９１及び第２アプリ９２の両方に対して第１回線を割り当てる。

　通信マネージャ８７は、サーバ４までの通信経路の設定が完了すると、第１アプリ９１、第２アプリ９２のそれぞれに対して対応するサーバ４までの経路情報を送信する（ステップＳ１４ａ、Ｓ１４ｂ）。通信経路情報の通知は、通信の開始を許可する旨のメッセージである通信許可応答に相当しうる。

　アプリ９は、通信マネージャ８７から経路情報を受信すると、当該経路情報に示されるポート番号や宛先アドレスを用いて、サーバ４と暗号通信を開始する（ステップＳ１５ａ、Ｓ１５ｂ）。例えば、アプリ９とサーバ４とはＴＬＳ通信を実施する。

　なお、前述の通り、アプリ９とサーバ４との通信は、中継サーバ５を介して実施される。通信マネージャ８７は、アプリ９だけでなく中継サーバ５に対しても、通信要求元のアプリＩＤをポート番号と対応付けて通知する。通信マネージャ８７及び中継サーバ５は、アプリ９毎にユニークに割り当てられたソースポートを元にトラフィックを識別し、通信制御を行う。中継サーバ５は、通信マネージャ８７から通知されてきたポート番号を用いて、暗号化されたデータの転送処理を実施する。なお、通信マネージャ８７及び中継サーバ５は、５－ｔｕｐｌｅ情報に含まれる複数項目を組み合わせて用いて転送処理を実施しても良い。中継サーバ５／通信マネージャ８７が通信トラフィックの送信元や転送先を特定するために使用する情報は適宜変更可能である。

　その後、第１アプリ９１及び第２アプリ９２が第１回線を使用している状態において、通信マネージャ８７は第１回線の輻輳を検知すると（ステップＳ２１　ＹＥＳ）、第１アプリ９１、第２アプリ９２の優先度を比較し、帯域制限をかけるアプリ９を選択する。ここでは一例として通信マネージャ８７は、相対的に優先度の低い第２アプリ９２に対して帯域制限をかけることを決定する。そして通信マネージャ８７は、第２アプリ９２に対して帯域制限をかける（ステップＳ２２）。ここでの帯域制限は、通信を完全に停止させる通信遮断相当の処理であってもよいし、所定値以下での速度での通信の継続を許容するものであってもよい。なお、回線の状況によっては、通信マネージャ８７は、第２アプリ９２だけでなく、第１アプリ９１にも帯域制限を実施しうる。

　通信マネージャ８７は、帯域制限の開始とともに／それに先立って、帯域制限の理由に応じた帯域制限通知を生成し（ステップＳ２３）、第２アプリ９２に送信する（ステップＳ２４）。例えば通信マネージャ８７は、優先度負けあるいはトラフィック急増による帯域制限をかけることを示す帯域制限通知を送信する。第２アプリ９２の通知レベルが２又は３に設定されている場合、通信マネージャ８７は、推奨制御内容や補足情報を含むメッセージを送信してよい。通信マネージャ８７は、再開指示待機／一定時間待機を推奨する帯域制限通知を送信してもよい。

　第２アプリ９２は、通信マネージャ８７からの帯域制限通知の受信に反応して、帯域制限の開始を承諾する旨の応答メッセージ（いわゆるＡｃｋ）を送信する（ステップＳ２５）。そして、受信した帯域制限通知に示される理由／推奨制御内容／補足情報等に基づいて、例えばサーバ４とのデータ通信を休止する（ステップＳ２６）。なお、通信の休止は、帯域制限通知に対するリカバリ処理の一例であって、別途、回線切替などの処理を実行しても良い。リカバリ処理とは、帯域制限等に対して臨時的に実施する処理を指す。通信の休止や、回線切替、通信タイミングの変更などがリカバリ処理に相当する。また、ファイル圧縮方式の変更や、送信データの間引き（厳選）処理など、通常時には実施しない、トラフィック量を抑制するための処理もまた、リカバリ処理に含まれうる。さらに、通信関連以外にも、サービスの停止／品質劣化を他のアプリ９／ＥＣＵ７／ユーザに通知する処理もリカバリ処理の一例に相当する。リカバリ処理は、帯域制限／通信トラブルに対する応答制御に相当する。なお、第１アプリ９１とサーバ４とのデータ通信は継続されうる。

　さらにその後、図１７に示すように通信マネージャ８７は第１回線の輻輳が解消したことを検知すると（ステップＳ３１　ＹＥＳ）、第２アプリ９２に対する帯域制限を解除する（ステップＳ３２）。そして、通信マネージャ８７は第２アプリ９２に対して、再開許可通知を送信する（ステップＳ３３）。再開許可通知は、帯域制限が解除したことを示すメッセージの一種に相当する。第２アプリ９２は、再開許可通知を受信したことに基づいてＡｃｋを返送するとともに（ステップＳ３４）、第１回線を用いた通信を再開する（ステップＳ３５）。

　＜輻輳発生時の応答方針の補足＞
　なお、図１６、図１７では第１回線の輻輳に対する処置として、通信マネージャ８７は、第２アプリ９２に通信を休止させる態様について述べたが、これに限らない。第１回線の輻輳に対し、通信マネージャ８７は図１８に示すように、第２アプリ９２の使用回線を第２回線に切り替えさせてもよい。また、変更先の通信回線は、第２回線ではなく、Ｗｉ－Ｆｉ回線であっても良い。さらに、通信回線の切り替えは、通信マネージャ８７ではなく、第２アプリ９２が主体となって実施しても良い。なお、図１８に示す第１キューｑ１は、第１回線で送信されるデータ用のキューであり、第２キューｑ２は、第２回線で送信されるデータ用のキューである。

　また、第１回線の輻輳に対し、通信マネージャ８７は、第２アプリ９２にタイミングシフトを提案してもよい。通信マネージャ８７は第２アプリ９２に対して、補足情報としてトラフィック予測データを含む帯域制限通知を送信してもよい。トラフィック予測データは、図１９に示すように、今後所定時間以内のトラフィック量の推移、換言すれば競合確率の推移を示すデータである。競合確率は、無線通信装置８が利用可能な通信帯域に対する送信トラフィック量の比率をもとに算出されうる。図中のＴ１ａ、Ｔ２ａは、当初予定していた通信タイミングを示しており、Ｔ１ｂ、Ｔ２ｂは変更後の通信タイミングを示している。

　第２アプリ９２は、通信マネージャ８７から提供されたトラフィック予測データをもとに、競合確率が低いタイミングを決定し、変更後のスケジュールでデータ通信を実施しうる。このように通信マネージャ８７は、補足情報の提供により、アプリ９の通信タイミングを間接的に制御しても良い。

　＜帯域制限通知に対するアプリの応答についての補足＞
　アプリ９は、図２０に示すように、帯域制限通知を受信すると（ステップＳ４１　ＹＥＳ）、当該通知に示される理由等に基づき、応答方針、換言すればリカバリ処理の内容を決定する（ステップＳ４２）。仮に帯域制限通知に推奨制御内容が含まれている場合、応答方針の決定には、推奨制御を実行するか否か、つまり通信マネージャ８７からの提案に従うか否かを決定することが含まれる。帯域制限通知に対してどのように応答するかはアプリ９ごとに予めプログラムされている。アプリ９は、通信の抑制に向けた制御を実行する場合には通信マネージャ８７に対してＡｃｋを返送し、決定した制御を開始する（ステップＳ４３）。一方、アプリ９は、通信の抑制に向けた制御を実行しないことを決定した場合には、帯域制限通知に対する否定的な応答としてＮａｃｋを通信マネージャ８７に返送しうる。

　なお、アプリ９は、推奨制御として回線切替が提案されている場合、通信マネージャ８７に対して、第２回線やＷｉ－Ｆｉ回線など、利用可能な回線への切替要求を出力しうる。つまり、アプリ９は通信マネージャ８７との協働により、使用回線の切替を実施しうる。また、アプリ９は、推奨制御として、タイミングシフトが提案されている場合には、トラフィック予測データをもとに通信タイミングを決定し、当該タイミングでの通信を実行する。その他、アプリ９は、帯域制限に対する応答方針として通信の休止を決定した場合には、通信マネージャ８７からの再開許可通知を待機する。

　＜帯域制限通知の送信態様の補足＞
　以上では、帯域制限をかけることを決定したタイミングで、第２アプリ９２に対して帯域制限通知を送信する態様について述べたが、帯域制限通知の送信タイミングはこれに限定されない。通信マネージャ８７は、アプリ９毎の通知条件に従って、帯域制限通知を送信可能である。例えば第２アプリ９２の通知条件が、１０秒以内に帯域制限が予見される場合と規定されている場合には、当該条件が充足したタイミングで帯域制限通知を送信しうる。この場合の帯域制限通知は帯域制限予告と称する事もできる。

　また第２アプリ９２の通知条件が、帯域制限が５秒以上続く場合と規定されている場合には、通信マネージャ８７は、帯域制限の継続時間が５秒以上となることが予見される場合に第２アプリ９２に対して帯域制限通知を発信しうる。上記設定の場合、帯域制限が５秒以内に解除できる見込みがある場合には、通信マネージャ８７は帯域制限通知の送信を省略可能である。

　また第２アプリ９２の通知条件が、重度の輻輳が生じた場合と規定されている場合には、通信マネージャ８７は、重度の輻輳が生じた場合にのみ第２アプリ９２に対して帯域制限通知を発信しうる。上記設定の場合、輻輳のレベルが軽度である場合には、通信マネージャ８７は帯域制限通知の送信を省略可能である。通信マネージャ８７は、帯域制限通知に限らず、回線切断通知なども通知条件に従ったタイミングで送信する。

　＜アプリの応答に対する通信マネージャの作動について＞
　通信マネージャ８７は、図２１に示すように帯域制限通知を送信してから所定時間経過しても、通知先のアプリ９からの応答が得られなかった場合には（ステップＳ５１　ＮＯ）、帯域制限通知を再送しても良い（ステップＳ５２）。また、アプリ９から受信した帯域制限通知に対する応答がＡｃｋではなかった場合（ステップＳ５３　ＮＯ）、当該アプリ９に対する通知レベルを１段階下げても良い（ステップＳ５４）。Ａｃｋを受信できなかった場合には、Ｎａｃｋ等の否定的な応答を受信した場合も含まれる。

　なお、ステップＳ５２は通知レベルを下げる処理であっても良い。また、通信マネージャ８７は帯域制限通知を所定回数送信してもアプリ９からのＡｃｋが得られなかった場合には、当該アプリの通知レベルを下げても良い。通知レベルを下げる事により、通信マネージャ８７からの提案に従わないアプリ９に対する補足情報の生成等の処理が省略可能となる。その結果、通信マネージャ８７の処理負荷を低減可能となる。通信マネージャ８７は、アプリ９の通知レベルとして、帯域制限通知の送信を停止するレベル０を設定可能に構成されていても良い。帯域制限通知等に対する応答の受信状況に基づいて変更された通知レベルは、走行用原電のオンオフに伴ってリセットされても良い。

　＜回線割当の補足＞
　アプリ９に対する回線割当に際し、通信マネージャ８７は、通信回線毎のステータスを確認する。ここでのステータスには、ネットワーク側装置から割り当てられている通信帯域の大きさや、空き容量、割当周波数などを含めることができる。また、通信回線毎のステータスには、回線状態取得部Ｆ２によって逐次評価されている通信回線毎のスループットやＲＴＴなども含めることができる。もちろん、セルラー回線のステータス情報には、ネットワーク側装置から通知されるパケット転送の優先順位や、目標遅延時間、パケットロス率などを含めることができる。在圏セル毎のＲＳＲＰや、ＲＳＳＩ、ＲＳＲＱなどもセルラー回線のステータスとして援用可能である。Ｗｉ－Ｆｉ回線が利用可能であるか否かもＷｉ－Ｆｉ回線のステータスに含まれる。本開示ではこのような各通信回線の現況を確認する処理（工程）を、回線状況確認処理とも呼ぶ。

　通信マネージャ８７は、回線状況確認処理により取得した回線毎のステータスに基づいて、通信要求元としてのアプリ９に割り当てる通信回線を選択する。アプリ９に割り当てる通信回線は、アプリ９から通知された通信条件を充足する通信回線、或いは、通信条件を充足する見込みがある通信回線である。通信マネージャ８７は、複数の回線のうち、許容ＲＴＴや、最小帯域、平均サイズなどといった通信条件を充足する回線が割当回線として選択する。

　＜効果＞
　ここでは以上で述べた構成である提案構成の利点について、比較構成を導入して説明する。比較構成は、アプリ９に対して帯域制限をかけた場合に通信マネージャ８７が対象とするアプリ９に何も通知しない構成である。比較構成のように、通信マネージャ８７がアプリ９に対して帯域制限をかけたことを通知しない場合、当該アプリ９側では、サーバ４から応答が返ってこない理由が不明である。なお、ここでのアプリ９側とは、アプリ９本体とその下位に位置するＴＣＰ層などを指す。

　そのため、図２２に示すようにアプリ９側では、所定の間隔でＴＣＰリトライが繰り返されうる。加えて、アプリ９自身もまた、タイムアウトが発生するまで、再送処理を実行しうる。つまり、通信マネージャ８７が対象アプリに対して帯域制限をかけたことを通知しない場合、サーバ４と通信不能であることをすぐには認識できず、サーバ４からの応答を待機する状態が継続しうる。換言すれば、帯域制限の影響伝搬に時間がかかる。加えて、アプリ９又はアプリ側ＴＣＰが何度もリトライを実施する結果として、通信マネージャ８７の処理負荷が増加し、実行スループットのさらなる低下が生じうる。

　そのような課題に対し、上記提案構成によれば、通信マネージャ８７が或るアプリ９に帯域制限をかけた場合には速やかに帯域制限通知を送信する。当該構成によれば、アプリ９はタイムアウト等を待たずに、サーバ４との通信が困難／不能であることを認識可能となる。ひいては、サーバ４との通信が困難／不能であることを踏まえ、速やかに適切な応答制御（リカバリ処理）を実行可能となる。また、アプリ９側が不毛なリトライを繰り返すことを抑制する効果も期待できる。

　さらに、上記提案構成の通信マネージャ８７は、帯域制限がかかっているという事実だけでなく、制限理由もアプリ９に通知する。当該構成によれば、アプリ９は、サーバ４からの応答が返ってこない理由を認識できる。またその結果としてアプリ９は、回線切替や、タイミングシフトなど、制限理由に応じた適切な応答を選択可能となりうる。

　また、通信マネージャ８７は、アプリ９に対して制限理由、換言すれば通信状況／内部状態に応じた推奨制御内容をアプリ９に通知する。当該構成によれば、アプリ９は、通信状況／内部状態に応じたリカバリ処理を実施しやすくなる。特に、上記提案構成における通信マネージャ８７は、推奨制御内容に合わせて、より細かい制御を可能とするための補足情報もアプリ９に提供する。当該構成によれば、アプリ９は、アプリ９の事情／特性に応じたリカバリ処理を実施可能となる。

　以上では通信マネージャ８７としての通信プロセッサ８１が、帯域制限実行時／輻輳発生時に、関連するアプリ９に対して帯域制限通知を送信する場合の効果について述べたが、回線切断通知や速度低下通知を送信する場合も同様の効果が得られる。

　その他、上述した実施形態では、アプリ９ごとの通知レベルに応じて、当該アプリ９に通知する内容を変更する。当該構成は、全てのアプリ９に一律的な情報を配信するのではなく、アプリ９ごとの要望に応じた情報を提供する構成に相当する。当該構成によれば、アプリ９がより適正なリカバリ処理を実行可能となりうる。また、アプリ９がリカバリ処理を実施する上で必要十分な情報を提供可能となる。なお、通知レベルに応じた通知内容の変更は任意の要素であって省略されても良い。

　上述した実施形態では、アプリ９ごとの通知条件に応じて、当該アプリ９に通信状況通知を送信するタイミングを変更する。当該構成によれば、アプリ９ごとの要望に応じたタイミングで、通信状況を把握可能となる。それに伴い、アプリ９はより適正なリカバリ処理を実行可能となりうる。なお、アプリ９毎の通知条件に応じた通知タイミングの調整は任意の要素であって省略されても良い。

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

　例えば上述した実施形態では、帯域制限機能は通信マネージャ８７のみが備える構成、換言すれば、通信マネージャ８７が各アプリ９の通信トラフィックを集中制御する構成について述べたがこれに限らない。図２３に示すようにアプリ９もまた、帯域制限機能を備えていても良い。帯域制限機能は、通信マネージャ８７及びアプリ９に分散配置されていても良い。

　アプリ９が帯域制限機能を備える場合、通信マネージャ８７は輻輳の検知を随時行い、輻輳の発生を検知したことに基づき、一部又は全部のアプリ９に対して帯域制限要求を発信する（図２４　ステップＳ６１）。帯域制限要求は、輻輳の発生を通知するメッセージに相当する。帯域制限要求は、所定時間当りの通信量の上限値、或いは、トラフィック量の削減目標値を含んでいても良い。アプリ９は、通信マネージャ８７からの帯域制限要求に従い、帯域制御を実施する。通信マネージャ８７は、帯域制限要求を送信したアプリ９のその後の通信量／挙動を監視し（ステップＳ６２）、通信量の削減がなされたかどうかを判断する（ステップＳ６３）。そして、通信量の削減が確認できなかったアプリ９に対しては、通信マネージャ８７にて帯域制限をかける（ステップＳ６４）。

　このように通信マネージャ８７は帯域制限要求に従わないアプリ９に関しては、通信マネージャ８７にて強制的に帯域制限を実施しても良い。当該構成によれば、通信マネージャ８７の処理負荷を低減でき、チップ温度上昇等によるスループットの低下を抑制可能となる。

　その他、通信マネージャ８７が無線区間での輻輳を検知することは任意の要素であって、必須の要素ではない。通信マネージャ８７は、輻輳の検知は実施せずに、輻輳以外の少なくとも１つの事象の発生を検出し、当該検出事象の発生をアプリ９に通知するように構成されていても良い。アプリ９とサーバ４との通信に影響を与える輻輳以外の事象とは、例えばチップ温度上昇や、高負荷状態、回線切断、干渉発生、契約上限到達などである。また、通信マネージャ８７は、輻輳検知にもとづく帯域制限は実施せずに、輻輳／通信速度の低下、回線遮断など、通信状況の事実のみをアプリ９に通知するように構成されていても良い。

　＜付言（１）＞
　本開示には、次の構成も含まれる。
　［構成（１）］
　車両で動作するアプリケーションと車両外部に存在する外部装置とのデータ通信を制御する通信制御装置であって、
　自装置が利用可能な少なくとも１つの通信回線の状態を監視し、通信回線が切断されたことを検知することと、
　通信回線が切断されたことを検知したことに基づいて、切断された通信回線を利用していたアプリケーションに対し、使用していた通信回線が利用不能となったことを示す通知を送信することと、を実施するように構成されている通信制御装置。

　上記の構成によれば、通信回線が切断された場合、アプリはその旨を通信のタイムアウトを待たずに（つまり速やかに）認識可能となる。それに伴い、アプリ側の不毛なリトライの実施の抑制や、アプリ／通信制御装置の処理負荷低減といった効果が期待できる。なお、通信回線の切断とは、通信接続の切断に相当する。通信回線の切断が生じる場合としては、通信圏外への移動、システム障害、電波環境の悪化などである。通信圏外には、山奥などの郊外の他、地下駐車場やトンネル内も含まれうる。

　［構成（２）］
　車両で動作するアプリケーションと車両外部に存在する外部装置とのデータ通信を制御する通信制御装置であって、
　自装置が利用可能な少なくとも１つの通信回線における通信速度を取得することと、
　通信速度が所定値以下であることを検知したことに基づいて、通信速度が所定値以下である通信回線を利用しているアプリケーションに対し、使用回線が低速状態であることを示す通知を送信することと、を実施するように構成されている通信制御装置。

　上記の構成によれば、アプリは使用回線の通信速度が何らかの事情により所定値以下となっていることを速やかに認識可能となる。ひいては、アプリによる不毛なリトライの実施の抑制や、アプリ／通信制御装置の処理負荷低減といった効果が期待できる。

　＜付言（２）＞
　本開示に記載の装置、システム、並びにそれらの手法は、コンピュータプログラムにより具体化された１つ又は複数の機能を実行するようにプログラムされたプロセッサを構成する専用コンピュータにより、実現されてもよい。また、本開示に記載の装置及びその手法は、専用ハードウェア論理回路を用いて実現されてもよい。さらに、本開示に記載の装置及びその手法は、コンピュータプログラムを実行するプロセッサと一つ以上のハードウェア論理回路との組み合わせにより構成された一つ以上の専用コンピュータにより、実現されてもよい。通信プロセッサ８１が備える機能の一部又は全部はハードウェアとして実現されても良い。或る機能をハードウェアとして実現する態様には、１つ又は複数のＩＣなどを用いて実現する態様が含まれる。プロセッサ（演算コア）としては、ＣＰＵや、ＭＰＵ、ＧＰＵ、ＤＦＰ（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）、フラッシュメモリ等を採用可能である。

Claims

　第１のネットワークに接続する装置により実施されるアプリケーションによる通信であって、前記第１のネットワークとは異なる第２のネットワークに接続する外部装置との通信を制御する通信制御装置であって、
　前記外部装置と通信するための通信回線の状態を監視し、前記通信回線における輻輳の発生を検知し、
　輻輳の発生を検知したことに基づいて、輻輳を検出している前記通信回線を使用中の前記アプリケーションに対し、使用回線が輻輳していることを示す通知を送信するように構成されている通信制御装置。
　請求項１に記載の通信制御装置であって、
　前記通知は、使用回線が輻輳していること、及び、その理由を示す信号である通信制御装置。
　請求項１に記載の通信制御装置であって、
　前記通信回線の輻輳を検知したことに基づいて、前記アプリケーションに対して帯域制限をかけ、
　帯域制限をかける前記アプリケーションに対しては前記通知を出力するように構成されている通信制御装置。
　請求項３に記載の通信制御装置であって、
　前記通知は、前記アプリケーションの通信速度に制限がかけられていること、及び、その理由を示す信号である通信制御装置。
　請求項３又は４に記載の通信制御装置であって、
　帯域制限がかけられている前記アプリケーションに対し、帯域制限に対する応答制御を決定するための参考情報を送信するように構成されている通信制御装置。
　請求項５に記載の通信制御装置であって、
　前記参考情報は、自装置が推奨する制御の内容、帯域制限の理由が解消するまでの予測時間、前記通信回線を流れる時間ごとのトラフィック量の予測データ、通知時点において利用可能な前記通信回線の情報、地点ごとの通信品質を示す電波マップ、及び、次回通信可能なタイミングの少なくとも何れか１つである通信制御装置。
　請求項５又は６に記載の通信制御装置であって、
　前記アプリケーションから、当該アプリケーションが通知を希望する前記参考情報の細かさ又は量を示す通知レベルを取得し、
　帯域制限がかけられている前記アプリケーションに対し、当該アプリケーションによって指定されている前記通知レベルに応じた前記参考情報を提供するように構成されている通信制御装置。
　請求項２から７の何れか１項に記載の通信制御装置であって、
　前記アプリケーションから、当該アプリケーションが前記通知の送信を希望する条件である通知条件を取得し、
　前記通知条件が充足したことに基づいて前記アプリケーションに対して前記通知を送信するように構成されている通信制御装置。
　請求項１から８の何れか１項に記載の通信制御装置であって、
　前記通信回線の輻輳を検知したことに基づいて、前記アプリケーションに対して、所定時間当りの通信量を所定値以下に制限するように要求する帯域制限要求を出力するように構成されている通信制御装置。
　請求項９に記載の通信制御装置であって、
　前記帯域制限要求を送信した前記アプリケーションが前記帯域制限要求に従っているかどうかを判断し、
　前記アプリケーションが前記帯域制限要求に従っていない場合には、前記アプリケーションに対して帯域制限をかけるように構成されている通信制御装置。
　請求項１から１０の何れか１項に記載の通信制御装置であって、
　前記通信回線の切断を検出した場合には、切断された前記通信回線を利用していた前記アプリケーションに対して、使用回線が利用不能となったことを示す回線切断通知を送信するように構成されている通信制御装置。
　請求項１から１１の何れか１項に記載の通信制御装置であって、
　前記通信回線の通信速度を取得し、
　前記通信速度が所定値以下である前記通信回線が存在する場合には、当該通信速度が所定値以下の前記通信回線を利用している前記アプリケーションに対して、低速状態であることを示す速度低下通知を送信するように構成されている通信制御装置。
　前記第１のネットワークに接続する少なくとも一つ以上の装置により実施される複数のアプリケーションの通信を制御する、請求項３に記載の通信制御装置であって、
　複数の前記アプリケーションのうち、帯域制限をかけない前記アプリケーションに対しては前記通知を出力しないように構成されている通信制御装置。
　第１のネットワークに接続する装置により実施されるアプリケーションによる通信であって、前記第１のネットワークとは異なる第２のネットワークに接続する外部装置との通信を制御する通信制御装置による通信制御方法であって、
　前記外部装置と通信するための通信回線の状態を監視し、前記通信回線における輻輳の発生を検知し、
　輻輳の発生を検知したことに基づいて、輻輳を検出している前記通信回線を使用中の前記アプリケーションに対し、使用回線が輻輳していることを示す通知を送信する通信制御方法。
　外部装置とデータ通信を実施するアプリケーションを実行する装置に、
　前記アプリケーションと前記外部装置との通信を制御する通信制御装置（８）から、前記アプリケーションの通信に用いられる通信回線に輻輳が生じていることを示すメッセージを取得することと、
　前記通信回線の輻輳が生じていることを示す前記メッセージを受信した場合に、前記外部装置との通信を制限することと、を実行させる命令を含むアプリケーション用制御プログラム。