JP4999989B2 - 車載通信装置および路車間−車々間通信連携システム - Google Patents

Description

本発明は、道路上を走行する移動局間で行われる車々間通信、および道路上に設置された基地局装置と移動局間で行われる路車間通信を利用して、移動局に対してサービスを提供する車載通信装置および路車間−車々間通信連携システムに関する。

近年、車々間通信を行う車載通信装置を利用して安全運転支援システムを実用化する案が検討されている。この場合、車載通信装置には、一般的に各車両間で一定周期ごとに自車両の情報を送受信し合う情報交換型アプリケーションが用いられる。また、車々間通信システムにおいては、各車両が自発的に情報を送信するために、従来からアクセス方式にＣＳＭＡ（Carrier Sense Multiple Access）方式を用いることが知られている。

ＣＳＭＡ方式において、情報交換型アプリケーションを利用すると、通信エリア内に存在する車両台数が増加した場合、通信トラフィックが増加し、通信容量を超えてしまうため、通信の信頼性が劣化する輻輳が発生し、車々間通信による情報伝達を確実に行えず安全支援サービスを提供できなくなることが考えられる。

そこで、特許文献１では、車々間通信システムにおいて輻輳が発生しないように、車両の危険な状況や通信路のトラフィック量に基づいて自車両の送信周期制御（情報量制御）を行うことによって輻輳を回避する方法が開示されている。

また、車々間通信システムでは情報交換型アプリケーション以外にも緊急情報を送信するアプリケーションなど複数のアプリケーションを利用することが将来的に想定されている。さらに、これらのアプリケーションを提供するためにはメッセージの再送や分割組み立てが必要と考えられている。

そこで、社団法人電波産業界にて定められた標準規格「狭域通信（ＤＳＲＣ）アプリケーションサブレイヤ ＡＲＩＢ ＳＴＤ−Ｔ８８」（平成１６年５月２５日策定）および特許文献２では路車間通信システムにおいて、マルチアプリケーションに対応するためにローカルポート制御プロトコル（Local Port Control Protocol:LPCP）を用い、メッセージの再送や分割組み立てに対応するためにローカルポートプロトコル（Local Port Protocol:LPP）を用いる方法が開示されている。

特開２００６−２０９３３３号公報 国際公開第２００５−０３９０７５号

特許文献１に記載の車載通信装置では、情報交換型アプリケーションとして単一のアプリケーションのみを想定した通信制御を行っていたため、緊急アプリケーションなどの他の複数アプリケーションを同時に利用する場合の通信制御には対応していなかった。また、特許文献１に記載の車載通信装置では、緊急アプリケーションなどの他の複数アプリケーションのためにあらかじめ通信帯域を確保しておくこともできなかった。

さらに、特許文献１に記載の車載通信装置では、自車両に対してのみ通信制御を行って輻輳を回避しているが、自車両の通信制御だけではネットワーク全体のトラフィック量を即座に減らすことができない問題があった。

また、特許文献２に記載の路車間通信システムでは、ローカルポート制御プロトコルによって、マルチアプリケーションに対応することが可能であり、ローカルポートプロトコルによって、メッセージの再送や分割／組み立てを行っていたが、車々間通信で必要とされる輻輳制御や優先度制御に対応することができなかった。

さらに特許文献２に記載の路車間通信システムでは、ローカルポートプロトコルによって、狭域通信（Dedicated Short Range Communication:DSRC）の接続状況を管理していたが、ローカルポートプロトコルには初期接続の手順を規定していないため、車々間通信システムに特許文献２に記載の路車間通信システムを直接利用することはできなかった。

本発明は上記のような問題点を解消するためになされたもので、情報の輻輳を回避する通信制御を行うとともに、車々間通信システムに必要とされる優先度制御や初期接続の確立手順を提供し、複数のアプリケーションに対応できて、メッセージの再送や分割／組み立てを行うことができ、路車間通信システムと車々間通信システムの双方に対応できる車載通信装置および路車間−車々間通信連携システムを提供することを目的とする。

本発明に係る請求項１記載の車載通信装置は、移動局および基地局にそれぞれ搭載され、無線通信により前記移動局間および前記移動局と前記基地局との間で相互に受信側および送信側となる車載通信装置であって、前記車載通信装置は、前記受信側の前記車載通信装置に周期的にメッセージを送信するアプリケーション処理部と、前記アプリケーション処理部に接続され、前記アプリケーション処理部から受信した前記メッセージの再送や分割／組み立てを含むトランザクションサービスを少なくとも提供するトランザクション管理部と、前記トランザクション管理部に接続され、前記トランザクション管理部から受信した前記メッセージに、前記アプリケーション処理部を含む上位プロトコルを識別するためのローカルポート番号を付加する転送サービス処理部と、前記転送サービス処理部に接続され、前記転送サービス処理部から受信した前記メッセージを、前記アプリケーション処理部で処理されるアプリケーションの優先度順に前記受信側の前記車載通信装置に対して送信し、前記転送サービス処理部に対する前記メッセージを送受信し、エラー情報を含むイベント情報を通知する車々間通信転送サービス処理部と、前記車々間通信転送サービス処理部に接続され、前記車々間通信転送サービス処理部から受信した前記メッセージを、無線通信により前記受信側の前記車載通信装置との間で送受信する送受信サービス処理部と、前記アプリケーション処理部および前記車々間通信転送サービス処理部に接続され、前記アプリケーション処理部から前記優先度を設定され、前記車々間通信転送サービス処理部からの要求に応じて前記優先度を通知する車々間通信管理サービス処理部とを備え、前記トランザクション管理部および前記転送サービス処理部は、前記移動局と前記基地局との間での路車間通信を行うための路車間通信プロトコルを構成し、前記車々間通信転送サービス処理部は、前記受信側の前記車載通信装置に対して前記車々間通信管理サービス処理部の有する通信制御情報を通知し、前記受信側の前記車載通信装置は、前記車々間通信転送サービス処理部において、受信した前記メッセージに付与された前記通信制御情報を前記車々間通信管理サービス処理部に送信し、受信した前記メッセージは前記転送サービス処理部に送信される。

本発明に係る請求項８記載の車載通信装置は、移動局および基地局にそれぞれ搭載され、無線通信により前記移動局間および前記移動局と前記基地局との間で相互に受信側および送信側となる車載通信装置であって、前記車載通信装置は、前記送信側から前記受信側に対して、路車間通信および車々間通信を利用してメッセージを送信するアプリケーション処理部と、前記アプリケーション処理部から受信した前記メッセージの再送や分割／組み立てを含むトランザクションサービス、前記アプリケーション処理部を含む上位プロトコルを識別するためのローカルポート番号の付加、および前記上位プロトコルに応じて前記メッセージの送信先を判別する路車間−車々間通信連携サービス処理部と、前記路車間−車々間通信連携サービス処理部から受信した前記メッセージを、前記アプリケーション処理部で処理されるアプリケーションの優先度順に前記受信側の前記車載通信装置に対して送信する車々間通信転送サービス処理部と、前記車々間通信転送サービス処理部を介して与えられる前記メッセージ、および前記路車間−車々間通信連携サービス処理部から直接与えられる前記メッセージに、識別のための識別子を付与して、無線通信により前記受信側の前記車載通信装置に送信する送受信サービス処理部と、前記アプリケーション処理部から前記優先度を設定され、前記車々間通信転送サービス処理部からの要求に応じて前記優先度を通知する車々間通信管理サービス処理部とを備え、前記路車間−車々間通信連携サービス処理部は、前記アプリケーション処理部から受信した前記メッセージを、路車間通信で送信するか、車々間通信で送信するかを判別し、前記路車間通信の場合には前記送受信サービス処理部に直接前記メッセージを与え、前記車々間通信の場合には前記車々間通信転送サービス処理部を経由して前記送受信サービス処理部に与え、前記受信側の前記車載通信装置の前記送受信サービス処理部は、前記送信側の前記車載通信装置から受信した前記メッセージに付与された前記識別子に基づき、前記メッセージを、路車間−車々間通信連携サービス処理部または車々間通信転送サービス処理部に送信する。

本発明に係る請求項１記載の車載通信装置によれば、既存の路車間通信プロトコルであるトランザクション管理部および転送サービス処理部に、車々間通信転送サービス処理部および車々間通信管理サービス処理部を備えることにより、路車間通信システムを提供する車載器と車々間通信システムを提供する車載器を共用化した車載通信装置を得ることができ、路車間通信システムと車々間通信システムの両方にサービスを提供することが可能となる。また、車々間通信転送サービス処理部と、車々間通信管理サービス処理部によって、アプリケーションごとの優先度が提供され、優先度制御が可能となるので、通信遅延の短縮が可能となる。また、当該車載通信装置により路車間−車々間通信連携システムを構成することで、上述したサービスが可能なシステムを得ることができる。

本発明に係る請求項８記載の車載通信装置によれば、路車間−車々間通信連携サービス処理部を備えることによって、路車間通信のデータは車々間通信転送サービス処理部を経由せずに送信でき、車々間通信のデータは車々間通信転送サービス処理部を経由して、必要な制御を行って相手に送信することができる。また、当該車載通信装置により路車間−車々間通信連携システムを構成することで、上述したサービスが可能なシステムを得ることができる。

本発明に係る実施の形態１に係る車載通信装置および路車間−車々間通信連携システムの構成の概略を示す図である。 本発明に係る実施の形態１の車載通信装置および路車間−車々間通信連携システムの構成の詳細を示す図である。 本発明に係る実施の形態１の車載通信装置および路車間−車々間通信連携システムの車々間通信アーキテクチャのプロトコル構成を示す図である。 本発明に係る実施の形態１のデータ転送サービスにおけるアプリケーションデータ転送手順の一例を示す図である。 本発明に係る実施の形態１のデータ転送サービスにおける制御データ転送手順の一例を示す図である。 本発明に係る実施の形態１のイベント通知サービスの一例を示す図である。 本発明に係る実施の形態１の優先度制御サービスの一例を示す図である。 本発明に係る実施の形態１の優先度制御サービスのシステム構成の一例を示す図である。 本発明に係る実施の形態１の輻輳制御サービスの送信周期制御の一例を示す図である。 本発明に係る実施の形態１の輻輳制御サービスの送信電力制御の一例を示す図である。 本発明に係る実施の形態１の輻輳制御サービスの受信感度制御の一例を示す図である。 本発明に係る実施の形態１の接続管理サービスの接続問い合わせの一例を示す図である。 本発明に係る実施の形態１の接続管理サービスの接続切断通知の一例を示す図である。 本発明に係る実施の形態１のデータ再送の一例を示す図である。 本発明に係る実施の形態１の重複受信チェックの一例を示す図である。 本発明に係る実施の形態１のプリミティブ種別を示す図である。 本発明に係る実施の形態１のパラメータ種別を示す図である。 本発明に係る実施の形態１のプリミティブ一覧を示す図である。 本発明に係る実施の形態１のプロトコルスタック上でのサービスインタフェースを示す図である。 本発明に係る実施の形態１のＡＣＭＬ-Connectionプリミティブの引数を示す図である。 本発明に係る実施の形態１のＡＣＭＬ-Notifyプリミティブの引数を示す図である。 本発明に係る実施の形態１のＡＣＭＬ-Registrationプリミティブの引数を示す図である。 本発明に係る実施の形態１のＡＣＭＬ-Deregistrationプリミティブの引数を示す図である。 本発明に係る実施の形態１のＡＣＭＬ-Getプリミティブの引数を示す図である。 本発明に係る実施の形態１のＡＣＭＬ-Setプリミティブの引数を示す図である。 本発明に係る実施の形態１のsendDataプリミティブの引数を示す図である。 本発明に係る実施の形態１のeventReportの引数を示す図である。 本発明に係る実施の形態１のＣＭＣＴＬ-sendDataプリミティブの引数を示す図である。 本発明に係る実施の形態１のＣＭＣＴＬ-eventReportプリミティブの引数を示す図である。 本発明に係る実施の形態１のＣＭＣＴＬ-Getプリミティブの引数を示す図である。 本発明に係る実施の形態１のＣＭＣＴＬ-Setプリミティブの引数を示す図である。 本発明に係る実施の形態１のＭＬＭＥ-Setプリミティブの引数を示す図である。 本発明に係る実施の形態１のＭＬＭＥ-Getプリミティブの引数を示す図である。 本発明に係る実施の形態１のＰＬＭＥ-Setプリミティブの引数を示す図である。 本発明に係る実施の形態１のＰＬＭＥ-Getプリミティブの引数を示す図である。 本発明に係る実施の形態１のアプリケーションデータのＰＤＵの関係を示す図である。 本発明に係る実施の形態１の制御データのＰＤＵの関係を示す図である。 本発明に係る実施の形態１のＣ２Ｃヘッダ情報を示す図である。 本発明に係る実施の形態１のＰＤＵ識別子を示す図である。 本発明に係る実施の形態１のBeacon ＰＤＵを示す図である。 本発明に係る実施の形態１のConnect Request ＰＤＵを示す図である。 本発明に係る実施の形態１のConnect Response ＰＤＵを示す図である。 本発明に係る実施の形態１のResult Codeの一覧を示す図である。 本発明に係る実施の形態１のAck PDUを示す図である。 本発明に係る実施の形態１のCongestion Control ＰＤＵを示す図である。 本発明に係る実施の形態１のEvent ＰＤＵを示す図である。 本発明に係る実施の形態１のEvent Codeの一覧を示す図である。 本発明に係る実施の形態１のデータ転送サービスのアプリケーションデータ送受信手順の一例を示す図である。 本発明に係る実施の形態１のデータ転送サービスの制御データ送受信手順の一例を示す図である。 本発明に係る実施の形態１の輻輳制御サービスの手順の一例を示す図である。 本発明に係る実施の形態１のBeacon ＰＤＵを利用した初期接続手順の一例を示す図である。 本発明に係る実施の形態１の初期接続手順のBeacon ＰＤＵ破棄の一例を示す図である。 本発明に係る実施の形態１の同報アプリケーションを利用した初期接続手順の一例を示す図である。 本発明に係る実施の形態１の初期接続手順の接続が無効な場合の手順の一例を示す図である。 本発明に係る実施の形態１の接続状態を通知する手順を示す図である。 本発明に係る実施の形態１のアプリケーションの登録／削除手順を示す図である。 本発明に係る実施の形態１の再送処理が有効な場合のデータ転送手順（基本シーケンス）を示す図である。 本発明に係る実施の形態１の再送処理手順の一例を示す図である。 本発明に係る実施の形態１の再送処理における重複チェック手順の一例を示す図である。 本発明に係る実施の形態１の車々間通信転送サービス処理部のデータ転送サービス処理部の処理手順を示すフローチャートである。 本発明に係る実施の形態１の車々間通信転送サービス処理部のイベント通知サービス処理部の処理手順を示すフローチャートである。 本発明に係る実施の形態１の車々間通信転送サービス処理部の優先度制御サービス処理部の処理手順を示すフローチャートである。 本発明に係る実施の形態１の車々間通信管理サービス処理部の輻輳制御サービス処理部の処理手順を示すフローチャートである。 本発明に係る実施の形態１の車々間通信管理サービス処理部の接続管理サービス処理部の初期接続手順の決定手順を示すフローチャートである。 本発明に係る実施の形態１の車々間通信管理サービス処理部の接続管理サービス処理部のビーコンを用いた初期接続手順を示すフローチャートである。 本発明に係る実施の形態１の車々間通信管理サービス処理部の接続管理サービス処理部の同報アプリケーションを用いた初期接続手順を示すフローチャートである。 本発明に係る実施の形態１のアプリケーション処理部の処理手順を示すフローチャートである。 本発明に係る実施の形態１のトランザクション管理部の処理手順を示すフローチャートである。 本発明に係る実施の形態１の転送サービス処理部の処理手順を示すフローチャートである。 本発明に係る実施の形態１の送受信サービス処理部の処理手順を示すフローチャートである。 本発明に係る実施の形態２の車載通信装置の構成の概略を示す図である。 本発明に係る実施の形態２の車載通信装置の構成の詳細を示す図である。 本発明に係る実施の形態３の車載通信装置の構成の詳細を示す図である。 本発明に係る実施の形態３の路車間通信アプリケーションに付加するＣ２Ｃヘッダ情報を示す図である。 本発明に係る実施の形態４の車載通信装置の構成の概略を示す図である。 本発明に係る実施の形態４のプロトコルスタック上でのサービスインタフェースを示す図である。 本発明に係る実施の形態４と実施の形態１とのプリミティブの相違点一覧を示す図である。 本発明に係る実施の形態５の車載通信装置の構成の概略を示す図である。 本発明に係る実施の形態５のプロトコルスタック上でのサービスインタフェースを示す図である。 本発明に係る実施の形態５と実施の形態１とのプリミティブの相違点一覧を示す図である。

＜Ａ．実施の形態１＞
＜Ａ−１．プロトコル構成＞
本発明に係る実施の形態１について、図１〜図７０を用いて説明する。なお、実施の形態１に係る車載通信装置および路車間−車々間通信連携システムは、路車間通信システムの車載通信装置としてサービスを提供したり、車々間通信システムの車載通信装置としてサービスを提供したりすることができる。本実施の形態１では、主として車々間通信システムの車載通信装置としてサービスを提供する場合について説明する。

図１は本発明の実施の形態１に係る車載通信装置１００および路車間−車々間通信連携システムのプロトコル構成を概略的に示すブロック図であり、図２は当該プロトコル構成を詳細に示すブロック図である。なお、図１および図２において、同一または相当する構成には同一の符号を付し、これは明細書の全文において共通する。

車載通信装置１００は、複数の車両の各々に搭載される。そして、当該車載通信装置１００を通じて、各車両間において無線通信が行われる。ここでの、車載通信装置１００とは自動車に搭載される移動可能な通信端末や基地局のように固定された通信装置を示す。また、無線通信とは、ＤＳＲＣを用いても良いし、無線ＬＡＮ（Local Area Network）や携帯電話など採用されるプロトコルを用いた通信でも良い。

また、本願明細書においては、車載通信装置１００が搭載された「自車両」（第１の車両）と称す１の車両に注目して説明するものとし、当該「自車両」以外で車載通信装置１００を搭載した複数の車両を、「周辺車両」（第２の車両）と称する。

図１に示すように、車載通信装置１００は、車々間通信転送サービス処理部１と、車々間通信管理サービス処理部２と、アプリケーション処理部３と、トランザクション管理部４と、転送サービス処理部５と、送受信サービス処理部６と、送受信サービス管理部７とを有する。

ここで、本実施の形態１においては、車々間通信転送サービス処理部１と、車々間通信管理サービス処理部２とを総称して、車々間通信サブプロトコルと呼ぶ。

車々間通信転送サービス処理部１（以下、車々間通信トランスポートサブレイヤとも呼称）は、転送サービス処理部５と送受信サービス処理部６との間に介在し、アプリケーション処理部３のアプリケーションの優先度を車々間通信管理サービス処理部２から取得し、優先度に応じて送信する順番を制御する優先度制御サービスを提供する。さらに、転送サービス処理部５や車々間通信管理サービス処理部２などに対して、メッセージを送受信するデータ転送サービスやエラーなどを通知するイベント通知サービスを提供する。

また、送受信されるデータ（ＰＤＵ：Protocol Data Unit）に送信周期や送信電力などの通信制御情報を付加することによって、輻輳制御に利用するための情報を周辺車両の車々間通信転送サービス処理部１に通知することができる。

車々間通信管理サービス処理部２（以下、車々間通信マネジメントレイヤとも呼称）は、アプリケーション処理部３、トランザクション管理部４、転送サービス処理部５、車々間通信転送サービス処理部１および送受信サービス管理部７に対して平行するように配置され、アプリケーション処理部３の有する車両の位置情報や速度情報などの車両情報と、送受信サービス管理部７の有する通信チャネルの利用率情報とを利用して、情報の輻輳を回避するための輻輳制御サービスを提供する。

ここで、車両情報とは車両の速度、加減速度、位置、走行方向およびウィンカーのＯＮ／ＯＦＦ情報などである。

さらに、車々間通信管理サービス処理部２は、相手局の車々間通信管理サービス処理部２と接続するために、初期接続の接続手順や切断手順を提供し、通信状況を管理する通信接続管理サービスを提供する。

また、車々間通信管理サービス処理部２は、輻輳制御サービスに利用する送信周期や通信接続管理サービスの通信状況をアプリケーション処理部３に通知するために、アプリケーション処理部３との間にインタフェース（第３のインタフェース）を有する。さらに、車々間通信管理サービス処理部２は、輻輳制御サービスに利用する送信電力、受信感度、および送信チャネルの情報を設定するためや、通信チャネル利用率の情報を取得するために送受信サービス管理部７との間にもインタフェース（第１のインタフェース）を有する。

また、車々間通信管理サービス処理部２は、送信するデータに付加する通信制御情報の取得や、受信したデータに付加された通信制御情報の設定、および制御データを相手局の車々間通信管理サービス処理部２への送信のために、車々間通信転送サービス処理部１とのインタフェース（第２のインタフェース）も有する。さらに、車々間通信管理サービス処理部２は、相手局に送信する制御データの再送制御サービスも提供する。

アプリケーション処理部３（以下、アプリケーションとも呼称）は、トランザクション管理部４上で動作する車々間通信アプリケーションを備えている。ここで、アプリケーション処理部３は、車々間通信アプリケーション以外にも、路車間通信システムのアプリケーションまたはＩＴＳ（Intelligent Transport Systems）に関するアプリケーション以外のアプリケーションなどを含んでも良い。

トランザクション管理部４（以下、ローカルポートプロトコルとも呼称）は、アプリケーション処理部３と転送サービス処理部５との間に介在し、転送サービス処理部５の機能を拡張する通信プロトコルである。トランザクション管理部４は、メッセージの再送や分割／組み立てなどのトランザクションサービス、および通信接続、切断などの通信状況を管理する接続管理サービスを提供する。

転送サービス処理部５（以下、ローカルポート制御プロトコルとも呼称）は、トランザクション管理部４と車々間通信転送サービス処理部１との間に介在し、アプリケーションの多重化を実現するための制御プロトコルである。転送サービス処理部５は、マルチアプリケーションを実現するために、上位プロトコルをローカルポート番号によって識別し、上位プロトコルに対してデータ転送とイベント通知などの管理サービスのためのサービスプリミティブ（インタフェース）を有する。

送受信サービス処理部６（以下、物理層およびデータリンク層ともいう）は、周辺局に搭載された車載通信装置１００との無線通信を行うために、送信サービスおよび受信サービスを提供する。

送受信サービス管理部７（以下、物理層管理部あるいはデータリンク層管理部とも呼称）は、送受信サービス処理部６の管理や、情報の格納のために、通信制御情報が格納される管理情報ベース（ＭＩＢ：Management Information Base）を備えている。

次に、図２を用いて車載通信装置１００の構成についてさらに説明する。
＜車々間通信転送サービス処理部１＞
車々間通信転送サービス処理部１は、データ転送サービス処理部１１と、イベント通知サービス処理部１２と、優先度制御サービス処理部１３とを有している。

データ転送サービス処理部１１は、アプリケーション処理部３などの上位プロトコルの要求に応じて、メッセージを送信するデータ転送サービスを提供する。また、送受信されるデータ（ＰＤＵ）に送信周期や送信電力などの通信制御情報を付加することによって、輻輳制御に利用するための情報を周辺車両の車々間通信転送サービス処理部１に通知することができる。車々間通信転送サービス処理部１は、通信制御情報を車々間通信管理サービス処理部２の管理情報格納部２４より取得する。さらに、車々間通信転送サービス処理部１は、転送サービス処理部５に対して、データ転送を行うためのインタフェースを有する。

イベント通知サービス処理部１２は、車々間通信転送サービス処理部１内で発生したエラーやイベントを上位プロトコルに通知したり、車々間通信管理サービス処理部２や下位プロトコルで発生したエラーおよびイベントを上位プロトコルに透過的に通知したりする。さらに、車々間通信転送サービス処理部１は、転送サービス処理部５に対して、イベント通知を行うためのインタフェースを有する。

優先度制御サービス処理部１３は、アプリケーション処理部３などの上位プロトコルが送信を要求するメッセージの優先度に応じて、送信する順序を制御する。車々間通信転送サービス処理部１は、アプリケーションの優先度を車々間通信管理サービス処理部２の管理情報格納部２４より取得する。また、車々間通信転送サービス処理部１は、優先度に応じた送信制御を実現するために車々間通信管理サービス処理部２に対して、インタフェースを有する。

＜車々間通信管理サービス処理部２＞
車々間通信管理サービス処理部２は、輻輳制御サービス処理部２１と、接続管理サービス処理部２２と、再送制御サービス処理部２３と、管理情報格納部２４とを有している。

輻輳制御サービス処理部２１は、アプリケーション処理部３に対して、通信の信頼性を向上させるために、送信周期や送信電力、および受信感度を制御する輻輳制御サービスを提供する。輻輳制御サービス処理部２１は、輻輳制御サービスで利用する自局や相手局の車両情報をアプリケーション処理部３から取得し、自局の通信チャネル利用率や送信電力などの通信制御情報を、送受信サービス管理部７の通信制御情報格納部７１から取得する。また、周辺局の通信チャネル利用率や送信電力などの通信制御情報は管理情報格納部２４より取得する。車々間通信管理サービス処理部２は、アプリケーション処理部３および送受信サービス管理部７に対して輻輳制御サービスを行うためのインタフェースを有する。

そして、輻輳制御サービス処理部２１は、送信周期制御処理部２１１と、送信電力制御処理部２１２と、受信感度制御処理部２１３とを有している。

送信周期制御処理部２１１は、周期的にメッセージを送信するアプリケーション処理部３に対して、輻輳を回避するための送信周期を算出し、通知する。これにより、この車載通信装置のアプリケーション処理部３は、輻輳制御サービス処理部２１から通知された送信周期に従ってメッセージを周期的に送信するため、送信トラフィックを増減させることができる。

送信電力制御処理部２１２は、送受信サービス管理部７に対して、輻輳を回避するための送信電力を算出し、通知する。これにより、この車載通信装置の送受信サービス管理部７は、送信電力制御処理部２１２から通知された送信電力に従ってメッセージを受信する電力の閾値を設定するため、送信するエリアを拡大したり、縮小したりさせることができる。

受信感度制御処理部２１３は、送受信サービス管理部７に対して、輻輳を回避するための受信感度を算出し、通知する。これにより、この車載通信装置の送受信サービス管理部７は、受信感度制御処理部２１３から通知された受信感度に従ってメッセージを受信する電力の閾値を設定するため、受信できるエリアを拡大したり、縮小したりさせることができる。

接続管理サービス処理部２２は、アプリケーション処理部３の要求に応じて、周辺局との初期接続を開始するための制御メッセージを送信する。また、接続管理サービス処理部２２は、周辺局との通信状況の管理およびアプリケーション処理部３への通知を行う。さらに、接続管理サービス処理部２２は、周期的にメッセージを送信するアプリケーション処理部３が動作しているかどうかで、初期接続手順を使い分け、効率的な接続管理サービスを提供する。

再送制御サービス処理部２３は、接続管理サービスを提供するための制御メッセージに対して、相手局に到達しなかったメッセージの再送を行う。これにより、車々間通信管理サービス処理部２は、トランザクション管理部４がサポートできない車々間通信管理サービス処理部２の制御メッセージに対しても再送制御が可能となる。

管理情報格納部２４は、輻輳制御サービスで利用する送信周期や送信電力などの通信制御情報や、接続管理サービスで利用する自局や周辺局の車両情報などを格納する。また、管理情報格納部２４は、車々間通信転送サービス処理部１が送受信するデータ（ＰＤＵ）に含まれる送信周期および送信電力などの通信制御情報を格納する。さらに、管理情報格納部２４は、アプリケーション処理部３から登録／削除される提供可能なアプリケーションの情報を格納する。

＜アプリケーション処理部３＞
アプリケーション処理部３は、車々間通信アプリケーション部３１を有している。
車々間通信アプリケーション部３１は、周期的に自車両の車両情報を同報送信するアプリケーション、ブレーキやウィンカーなどの動作時に自車両の車両情報を同報送信するアプリケーション、およびその他にドライバーの快適性や利便性を高めるアプリケーションなどを含んでいる。

＜トランザクション管理部４＞
トランザクション管理部４は、トランザクションサービス処理部４１と、ＬＰＰ接続管理サービス処理部４２とを有している。

トランザクションサービス処理部４１は、相手局に到達しなかったメッセージの再送や、メッセージの分割／組み立てなどのトランザクションサービスを提供する。これにより、車々間通信システムに要求される再送制御や分割／組み立て制御を提供する。また、相手局へのメッセージの送信や、送信したメッセージに対して相手局からの応答を要求するトランザクションサービスを提供する。さらに、トランザクションサービス処理部４１は、アプリケーション処理部３から送信されたメッセージを連続して送信する連送制御サービスを提供する。これにより、この車載通信通信装置は、相手局に対してメッセージが到着する確率を高くすることができる。

ＬＰＰ接続管理サービス処理部４２は、アプリケーション処理部３からの要求に応じての接続状況の報告、新規接続や切断の通知、相手局が有する受信可能なポート番号の管理、およびあるポートが受信可能になったことをアプリケーション処理部３への通知などの接続管理サービスを提供する。

＜転送サービス処理部５＞
転送サービス処理部５は、ＬＰＣＰ（Local Port Control Protocol）転送サービス処理部５１と、管理サービス処理部５２とを有している。

ＬＰＣＰ転送サービス処理部５１は、アプリケーション処理部３などの上位プロトコルを、ローカルポート番号と呼ぶ識別子を用いて、送信元および送信先のアプリケーション処理部３を識別する。また、転送サービス処理部５は、上位プロトコルであるアプリケーション処理部３およびトランザクション管理部４に対して、データ転送を行うためのインタフェースを有する。これにより、この車載通信通信装置は、マルチアプリケーションを実現することができる。

管理サービス処理部５２は、上位プロトコルに対して、転送サービス処理部５内で発生したエラーやイベントを相手局や自局に通知する管理サービスを提供する。また、管理サービス処理部５２は、車々間通信転送サービス処理部１などの下位プロトコルから通知されるエラーやイベントを自局のアプリケーション処理部３に対して透過的に通知するサービスを提供する。また、転送サービス処理部５は、トランザクション管理部４に対して、イベント通知サービスを提供するためのインタフェースを有する。

＜送受信サービス処理部６＞
送受信サービス処理部６は、送信サービス処理部６１と、受信サービス処理部６２とを有している。

送信サービス処理部６１は、車々間通信転送サービス処理部１から送信されたデータを、周辺車両にブロードキャスト送信または特定車両にユニキャスト送信する。また、送信サービス処理部６１は、送信電力を切り替えることができ、送信する際の送信電力を通信制御情報格納部７１より取得する。また、送信サービス処理部６１は、送信する通信チャネルを切り替えることができ、例えば、車々間通信管理サービス処理部２からの情報を制御チャネルに送信し、アプリケーション処理部３からの情報をデータチャネルに送信することができる。

受信サービス処理部６２は、周辺車両から送信された情報を受信し、受信した情報を車々間通信転送サービス処理部１に送信する。また、受信サービス処理部６２は、受信感度を切り替えることができ、受信感度を通信制御情報格納部７１より取得する。さらに、受信サービス処理部６２は、通信チャネル上において一定値以上の電波強度を受信した場合をビジーと判定し、所定時間通信チャネルを観測する。そして、受信サービス処理部６２は、その所定時間のビジーの割合を通信チャネルの利用率として計測し、通信制御情報格納部７１に格納する。

＜送受信サービス管理部７＞
送受信サービス管理部７は、通信制御情報格納部７１を有している。
通信制御情報格納部７１は、周辺局に搭載された車載通信装置１００との無線通信を行うための送信電力や受信感度などの情報を格納する。また、通信制御情報格納部７１は、受信サービス処理部６２が測定した通信チャネル利用率などの情報を格納する。さらに、通信制御情報格納部７１は、送信電力や受信感度を、車々間通信管理サービス処理部２の輻輳制御サービス処理部２１により、輻輳を回避するための値に設定する。

＜Ａ−２．プロトコル仕様＞
以下では、本発明に係る車載通信装置および路車間−車々間通信連携システムにおける車々間通信転送サービス処理部１と、車々間通信管理サービス処理部２とで構成される車々間通信サブプロトコルの仕様について詳細に説明する。

＜１．車々間通信サブプロトコルの概要＞
車々間通信サブプロトコル（Car-To-Car Sub Protocol）は、車々間通信トランスポートサブレイヤ（Ｃ２Ｃ Transport Sub Layer：ＣＴＬ）と車々間通信マネジメントレイヤ（Ｃ２Ｃ Management Layer：ＣＭＬ）とで構成される。車々間通信アーキテクチャのプロトコル構成を図３に示す。

車々間通信トランスポートサブレイヤ（ＣＴＬ）は、ローカルポート制御プロトコル（Local Port Control Protocol：ＬＰＣＰ）と通信下位プロトコルとの間に介在し、車々間通信システムのアプリケーションに対して優先度制御を提供し、車々間通信マネジメントレイヤ（ＣＭＬ）の機能を補完する。また、上位プロトコル（以下、Upper Layerとも呼称）またはＣＭＬに対してメッセージを転送するイベント転送サービスおよびＣＴＬ内で発生したエラーおよびイベントなどを上位プロトコルに通知するイベント通知サービスを提供する。

車々間通信マネジメントレイヤ（ＣＭＬ）は、アプリケーションまたはＣＴＬに対して、通信の信頼性を向上させるために送信周期、送信電力、受信感度および送信チャネルを制御する輻輳制御サービスと、初期接続の開始や切断を行ったり、通信状況を管理したりする接続管理サービスを提供する。また、ＣＭＬは通信下位プロトコルの管理層の機能を拡張する。さらに、ＣＭＬは初期接続を行うための制御メッセージの信頼性を向上させるためにデータ再送サービスを提供する。

ローカルポートプロトコル（Local Port Protocol：ＬＰＰ）は、データの再送や分割／組み立てなどのトランザクションサービス、および初期接続や切断などの通信状況を管理する接続管理サービスを提供する。これにより、ＬＰＰは、車々間通信システムに要求される再送制御や分割／組み立て制御を実現する。

ＬＰＣＰは、アプリケーション処理部３などの上位プロトコルをローカルポート番号を用いて識別し、上位プロトコルに対してデータ転送やイベント通知などの管理サービスのためのインタフェースを有する。これにより、ＬＰＣＰは、車々間通信システムにおいてマルチアプリケーションを実現する。

また、通信下位プロトコルとしては、ＩＥＥＥ８０２．１１ｐプロトコルおよび５．８ＧＨｚ帯やＵＨＦ／ＶＨＦ帯の通信プロトコルなどを想定している。さらに、通信下位プロトコルは、通信下位プロトコルの情報を格納する管理層を有する。

通信下位プロトコルは、データリンク層（Layer2：Ｌ２）と、データリンク層の下位に物理層（Layer1：Ｌ１）と、データリンク層を管理するデータリンク層管理部（Media access control Layer Management Entity：ＭＬＭＥ）と、物理層を管理する物理層管理部（Physical Layer Management Entity：ＰＬＭＥ）とを有する。ここで、通信下位プロトコルとして、例えばＩＥＥＥ８０２．１１ｐプロトコルおよび５．８ＧＨｚ帯やＵＨＦ／ＶＨＦ帯の通信プロトコルを用いても良いし、それ以外の通信プロトコルを用いても良い。また、特に図示していないがＭＬＭＥおよびＰＬＭＥは、管理情報が格納される管理情報ベース（ＭＩＢ：Management Information Base）を備えている。

データリンク層は、ＯＳＩ（Open Systems Interconnection）参照モデルの第２層であり、アクセス方式について規定される。物理層は、ＯＳＩ参照モデルの第１層であり、物理的に伝送方式について規定される。データリンク層管理部（ＭＬＭＥ）は、データリンク層を管理したり、データリンク層で利用する情報を格納したりする。物理層管理部(ＰＬＭＥ）は、物理層を管理したり、物理層で利用する情報を格納したりする。

ＣＴＬとＣＭＬが有する機能は以下の通りである。
（１）ＣＴＬが提供するサービス
（ａ）データ転送サービス
（ｂ）イベント通知サービス
（ｃ）優先度制御サービス
（２）ＣＭＬが提供するサービス
（ａ）輻輳制御サービス
（ｂ）接続管理サービス
（ｃ）データ再送サービス
＜２．機能の概要＞
２．１ 車々間通信トランスポートサブレイヤの機能
２．１．１ データ転送サービス
ＣＴＬは、アプリケーションおよびＬＰＰ、ＬＰＣＰなどの上位プロトコルおよびＣＭＬに対して、データ転送サービスを提供する。データ転送サービスの詳細な手順は５．１節で説明する。図４に上位プロトコルに対してデータ転送サービスを提供する例を示し、図５にＣＭＬに対してデータ転送サービスを提供する例を示す。

２．１．２ イベント通知サービス
ＣＴＬは、ＣＴＬ内で発生したイベントやエラー、およびＣＭＬから受信したらイベント（通信接続や切断の通知など）を上位プロトコルおよび相手局に通知するためにイベント通知サービスを提供する。図６にイベント通知サービスを提供する例を示す。

２．１．３ 優先度制御サービス
ＣＴＬは、上位プロトコルおよびＣＭＬのデータ優先度に応じて送信順を制御する優先度制御サービスを提供する。これにより、緊急度の高いデータを優先的に送信することが可能になる。優先度制御サービスの詳細な手順は５．２節で説明する。図７に優先度制御サービスの例を示す。ただし、優先度制御サービスは通信下位プロトコルで提供される場合にはオプションとして提供される。

ＣＴＬは、優先度制御サービスでは、優先度ごとにキューを用意し、優先度の高いキューにあるデータを優先的に通信下位プロトコルに渡す。図８に優先度制御サービスを提供するためのキュー構成の例を示す。

２．２ 車々間通信マネジメントレイヤの機能
２．２．１ 輻輳制御サービス
ＣＭＬは、アプリケーションに対して通信の信頼性を向上させるために、送信周期や送信電力、および受信感度を制御する輻輳制御サービスを提供する。輻輳制御サービスの詳細な手順は５．３節で説明する。輻輳制御サービスは、次のサービスのいずれかを用いても良いし、いくつかを連携して用いても良い。
（１）送信周期制御サービス
周期的に車両情報などのメッセージを送信するアプリケーションの送信周期をアプリケーションに通知するサービス。
（２）送信電力制御サービス
アプリケーションに必要な通信エリアを確保したり、輻輳を回避するために通信エリアを絞ったりするために送信電力を制御するサービス。
（３）受信感度制御サービス
アプリケーションに必要な通信エリアを限定するために受信感度を制御するサービス。

２．２．１．１ 送信周期制御サービス
ＣＭＬは、送信周期制御サービスは、周期的に車両情報などのメッセージを送信するアプリケーションに対して、輻輳を回避するために設定される送信周期を通知する。

ＣＭＬは、送信周期制御サービスでは、ＣＭＬの有する自車両の情報および周辺車両の情報と、自車両の検出するチャネル利用率情報および周辺車両の検出するチャネル利用率情報を利用して送信周期を算出する。これにより、この車載通信装置は、周辺車両との危険な状況や通信環境の混雑状況に応じて送信周期を制御することが可能になる。

ＣＭＬは、送信周期を算出した後、周期的に情報の送信を行うアプリケーションに対して送信周期の変更を通知する。送信周期を通知されたアプリケーションは、通知を受信した後は通知された送信周期ごとにメッセージの送信を開始する。図９に送信周期制御サービスの例を示す。

２．２．１．２ 送信電力制御サービス
ＣＭＬは、送信電力制御サービスでは、通信下位プロトコルの管理層に対して、アプリケーションに必要とされる通信エリアを確保したり、輻輳を回避するための通信エリアに制限したりするために、メッセージを送信する際の送信電力を制御する。

ＣＭＬは、送信電力制御サービスでは、ＣＭＬの有する自車両の情報および周辺車両の情報と、自車両の検出するチャネル利用率情報および周辺車両の検出するチャネル利用率情報を利用して、通信が必要な車両との通信エリアを確保したり、不必要なエリアに電波を送信することを回避したりする送信電力を算出する。

ＣＭＬは、送信電力を算出した後、ＰＬＭＥに対して送信電力を通知し、通信下位プロトコルは通知された送信電力に従ってメッセージの送信を行う。図１０に送信電力制御サービスの例を示す。

２．２．１．３ 受信感度制御サービス
ＣＭＬは、受信感度制御サービスでは、通信下位プロトコルの管理層に対して、アプリケーションに必要とされる通信エリアまたは輻輳を回避するための通信エリアに限定するために、メッセージを受信する際の受信感度を制御する機能を提供する。

ＣＭＬは、ＣＭＬの有する自車両の情報および周辺車両の情報と、自車両の検出するチャネル利用率情報および周辺車両の検出するチャネル利用率情報を利用して、アプリケーションに必要とされる通信エリアや輻輳を回避するための通信エリアに限定する受信感度を算出する。

ＣＭＬは、受信感度を算出した後、ＰＬＭＥに対して受信感度を通知し、通信下位プロトコルは通知された受信感度に従ってメッセージの受信を行う。図１１に受信感度制御サービスの例を示す。

２．２．２ 接続管理サービス
ＣＭＬは、車々間通信システムに必要な通信接続の初期接続を開始したり、接続状態の管理や通知を行ったりする接続管理サービスを提供する。

ＣＭＬは、接続管理サービスでは、次のサービスをアプリケーションに対して提供することで、アプリケーションに通信の開始や終了のトリガーを提供する。また、接続管理サービス間で提供可能なアプリケーションを通知し合うことで、相手移動局がサポートするアプリケーションを管理し、各アプリケーションの要求に応じてそれらの状況を報告したり、通信可能になったりすることを通知する機能を提供する。
（１）接続問い合わせサービス
周辺移動局との接続状況を管理および監視を行い、アプリケーションからの要求に応じて接続状況および新規接続・切断を通知するサービス。
（２）接続／切断通知サービス
ＣＴＬを経由して上位プロトコルに対して接続状況および新規接続／切断を通知するサービス。
（３）時刻同期サービス
複数の通信チャネルが利用できる場合にチャネルを切り替えるタイミングを同期させるために、時刻を同期するサービス。

ＣＭＬは、接続管理サービスでは、高速な初期接続を実現するために、周期的にメッセージを送信するアプリケーションのデータ、および周期的に送信するビーコンメッセージを受信した場合に、相手移動局との初期接続を開始する。

２．２．２．１ 接続問い合わせサービス
接続問い合わせサービスは、アプリケーションが車々間通信の接続が確立しているかどうかを問い合わせるサービスである。接続問い合わせサービスは、問い合わせする際に、車々間通信の接続状況を即座に回答を行う参照サービスと、接続が確立していない場合に接続するまで待機し接続した時点で通知を行う通知サービスの２種類のサービスを規定する。図１２に接続問い合わせサービスの例を示す。

２．２．２．２ 接続／切断通知サービス
接続／切断通知サービスは、アプリケーションおよびＣＴＬに対して、通信接続の通知および切断の通知を行うサービスである。図１３に接続／切断通知サービスの例を示す。

２．２．２．３ 時刻同期サービス
ＣＭＬは、車々間通信プロトコルが複数の通信チャネルをサポートしている場合、通信チャネルを切り替えるタイミングを統一するために時刻同期サービスを提供する。

ＣＭＬは、時刻同期サービスでは、複数あるチャネルのうち一つを制御チャネルと定義し、制御チャネル上に周期的にビーコンメッセージを送信する。ビーコンメッセージによって、時刻同期を取ると同時に相手局のサポートするアプリケーション情報を把握することも可能である。

２．２．３ データ再送サービス
ＣＭＬは、制御メッセージに対して、通信の信頼性を確保するためにデータ再送サービスを提供する。ＣＭＬは、データ再送サービスでは、再送タイマと再送カウンタにより再送の制御を行い、再送タイマがタイムアウト時に再送を行う。図１４にデータ再送サービスの例を示し、図１５にデータ再送サービスの重複チェックの例を示す。
データ再送サービスの再送処理手順の概要を以下に示す。
（１）制御メッセージ送信する際に、再送タイマをスタートし、再送カウンタを０にセットする。
（２）再送タイマのタイムアウトまでに、相手移動局から応答のメッセージを受信できなかった場合には再送カウンタを１インクリメントし、メッセージを再送すると同時に再送タイマをリスタートする。
（３）再送カウンタが最大再送回数を超えた場合には、メッセージ再送を中止する。

＜３．サービスインタフェース（Service Access Point：ＳＡＰ）＞
次に、ＣＴＬおよびＣＭＬが有するインタフェースについて説明する。
３．１ 記法の説明
本発明で規定されるプリミティブ種別の一覧を図１６に示す。また、本発明でのプリミティブの定義テーブルで用いられるパラメータ種別の一覧を図１７に示す。

３．２ サービスインタフェース一覧
ＣＴＬおよびＣＭＬが有するサービスインタフェースの一覧を図１８に示す。また、車々間通信プロトコルスタックにおけるＳＡＰの位置を図１９に示す。

３．３ アプリケーションとＣＭＬとのＳＡＰ（ＡＣＭＬ ＳＡＰ）
輻輳制御サービスおよび接続管理サービスとして、ＣＭＬはアプリケーションに対して、以下の６種類のプリミティブを提供する。
（１）接続開始プリミティブ（ＡＣＭＬ-Connection）
（２）アプリケーション通知プリミティブ（ＡＣＭＬ-Notify）
（３）アプリケーション情報登録プリミティブ（ＡＣＭＬ-Registration）
（４）アプリケーション情報削除プリミティブ（ＡＣＭＬ-Deregistration）
（５）ＣＭＬ情報取得プリミティブ（ＡＣＭＬ-Get）
（６）ＣＭＬ情報設定プリミティブ（ＡＣＭＬ-Set）
３．３．１ 接続開始プリミティブ（ＡＣＭＬ-Connection）
（１）処理概要
ＡＣＭＬ-Connectionプリミティブは、アプリケーションが周辺局との接続を要求したり、接続状態を問い合わせたり、ビーコンメッセージの送信を要求したりするプリミティブである。個別通信を行うアプリケーションは、ＡＣＭＬ-Connectionプリミティブの発行により開始される。
（２）定義
図２０は、ＡＣＭＬ-Connectionプリミティブの引数を示す図である。
portNo：要求元アプリケーションを識別するための識別子である。
serviceType：接続問い合わせサービスのタイプを示す識別子である。「０」の場合は接続状況を即座に回答を行う参照サービスを示し、「１」の場合は接続した時点で通知を行う通知サービスを示す。
connectionFlag：アプリケーションが相手局との接続を行うかを示すフラグである。「０」の場合は相手局との接続を行わないことを示し、「１」の場合は相手局と接続を行うことを示す。
destinationLID：接続要求などを行う相手局を示す識別子である。
connectStatus：接続状態を示す識別子である。「０」の場合は未接続の状態を示し、「１」の場合は接続済みの状態を示す。
beaconFlag：ビーコンメッセージの送信を要求するかを示すフラグである。「０」の場合はビーコンメッセージの送信を要求しないことを示し、「１」の場合はビーコンメッセージの送信を要求することを示す。

３．３．２ アプリケーション通知プリミティブ（ＡＣＭＬ-Notify）
（１）処理概要
ＡＣＭＬ-Notifyプリミティブは、ＣＭＬがアプリケーションに対して、送信周期の変更などを通知したり、アプリケーションがＣＭＬに対して輻輳制御メッセージの送信を要求したりするプリミティブである。送信周期の変更は、周期的に送信を行うアプリケーションに対して発行される。また、ＡＣＭＬ-Notifyプリミティブは、上記以外にもアプリケーションに情報を通知したり、ＣＭＬに処理を要求したりする場合に利用する。
（２）定義
図２１は、ＡＣＭＬ-Notifyプリミティブの引数を示す図である。
portNo：要求元アプリケーションを識別するための識別子である。
notifyCode：アプリケーションに通知する内容を示す識別子である。
notifyParameter：アプリケーションに通知する内容のパラメータ値である。

３．３．３ アプリケーション情報登録プリミティブ（ＡＣＭＬ-Registration）
（１）処理概要
ＡＣＭＬ-Registrationプリミティブは、アプリケーションがＣＭＬに対して、アプリケーション情報を登録するためのプリミティブである。
（２）定義
図２２は、ＡＣＭＬ-Registrationプリミティブの引数を示す図である。
portNo：登録を要求するアプリケーションを識別するための識別子である。
priority：アプリケーションの優先度を示す識別子である。
applicationType：アプリケーションの種類（路車間／車々間／その他）を示す識別子である。
resultCode：登録結果を示す識別子である。

３．３．４ アプリケーション情報削除プリミティブ（ＡＣＭＬ-Deregistration）
（１）処理概要
ＡＣＭＬ-Deregistrationプリミティブは、アプリケーションがＣＭＬに対して、アプリケーション情報を削除するためのプリミティブである。

（２）定義
図２３は、ＡＣＭＬ-Deregistrationプリミティブの引数を示す図である。
portNo：削除を要求するアプリケーションを識別するための識別子である。
resultCode：削除結果を示す識別子である。

３．３．５ ＣＭＬ情報取得プリミティブ（ＡＣＭＬ-Get）
（１）処理概要
ＡＣＭＬ-Getプリミティブは、アプリケーションがＣＭＬの変数を取得するためのプリミティブである。
（２）定義
図２４は、ＡＣＭＬ-Getプリミティブの引数を示す図である。
mibIndex：取得を要求する変数を指示する識別子である。
mibStatus：要求を実行した結果を示す識別子である。
mibParameter：取得した変数の内容である。

３．３．６ ＣＭＬ情報設定プリミティブ（ＡＣＭＬ-Set）
（１）処理概要
ＡＣＭＬ-Setプリミティブは、アプリケーションがＣＭＬの変数を設定するためのプリミティブである。
（２）定義
図２５は、ＡＣＭＬ-Setプリミティブの引数を示す図である。
mibIndex：設定を要求する変数を指示する識別子である。
mibStatus：要求を実行した結果を示す識別子である。
mibParameter：設定する変数の内容である。

３．４ ＣＴＬと上位プロトコルとのＳＡＰ（ＡＣＴＬ ＳＡＰ）
データ転送サービスおよびイベント通知サービスとして、ＣＴＬは上位プロトコルに対して、以下の２種類のプリミティブを提供する。
（１）アプリケーションデータ転送プリミティブ（sendData）
（２）イベント通知プリミティブ（eventReport）
３．４．１ アプリケーションデータ転送プリミティブ（sendData）
（１）処理概要
sendDataプリミティブは、上位プロトコルがＣＴＬに対して、アプリケーションデータの送受信を行うためのプリミティブである。
（２）定義
図２６は、sendDataプリミティブの引数を示す図である。
linkAddress：車々間通信で利用するリンクアドレスであり、通信する相手局を識別するために用いる識別子である。
parameter：上位プロトコルとやり取りするデータ本体を示す。

３．４．２ イベント通知プリミティブ（eventReport）
（１）処理概要
eventReportプリミティブは、ＣＴＬが上位プロトコルに対して、ＣＴＬ内で発生したエラーなどの事象を通知するためのプリミティブである。
（２）定義
図２７は、eventReportプリミティブの引数を示す図である。
linkAddress：車々間通信で利用するリンクアドレスであり、通信する相手局を識別するために用いる識別子である。
eventCode：発生したイベントやエラーを示すコードを表す識別子である。
extensionParameter：変数eventCodeの内容を補足するためのパラメータを示す。

３．５ ＣＴＬとＣＭＬとのＳＡＰ（ＣＭＣＴＬ ＳＡＰ）
データ転送サービスおよびイベント通知サービスとして、ＣＴＬはＣＭＬに対して、以下の４種類のプリミティブを提供する。
（１）制御データ転送プリミティブ（ＣＭＣＴＬ-SendData）
（２）イベント通知プリミティブ（ＣＭＣＴＬ-EventReport）
（３）ＣＭＬ情報取得プリミティブ（ＣＭＣＴＬ-Get）
（４）ＣＭＬ情報設定プリミティブ（ＣＭＣＴＬ-Set）
３．５．１ 制御データ転送プリミティブ（ＣＭＣＴＬ-SendData）
（１）処理概要
ＣＭＣＴＬ-SendDataプリミティブは、ＣＭＬがＣＴＬに対し、制御メッセージの送信を要求するためのプリミティブである。
（２）定義
図２８は、ＣＭＣＴＬ-SendDataプリミティブの引数を示す図である。
linkAddress：車々間通信で利用するリンクアドレスであり、通信する相手局を識別するために用いる識別子である。
pduIdentifier：ＣＭＬとやり取りするＰＤＵの種類を示す。
parameter：ＣＭＬとやり取りするデータ本体を示す。
priority：送信するデータの優先度を示す。

３．５．２ イベント通知プリミティブ（ＣＭＣＴＬ-EventReport）
（１）処理概要
ＣＭＣＴＬ-EventReportプリミティブは、ＣＭＬがＣＴＬに対し、ＣＭＬ内で発生したエラーなどの事象を通知したり、ＣＴＬがＣＭＬに対し、ＣＴＬ内で発生したイベントなどの事象を通知したりするためのプリミティブである。
（２）定義
図２９は、ＣＭＣＴＬ-EventReportプリミティブの引数を示す図である。
linkAddress：車々間通信で利用するリンクアドレスであり、通信する相手局を識別するために用いる識別子である。
eventCode：発生したイベントを示すコードを表す識別子である。
extensionParameter：変数eventCodeの内容を補足するためのパラメータを示す。

３．５．３ ＣＭＬ情報取得プリミティブ（ＣＭＣＴＬ-Get）
（１）処理概要
ＣＭＣＴＬ-Getプリミティブは、ＣＴＬがＣＭＬの変数を取得するためのプリミティブである。
（２）定義
図３０は、ＣＭＣＴＬ-Getプリミティブの引数を示す図である。
mibIndex：取得を要求する変数を指示する識別子である。
mibStatus：要求を実行した結果を示す識別子である。
mibParameter：取得した変数の内容である。

３．５．４ ＣＭＬ情報設定プリミティブ（ＣＭＣＴＬ-Set）
（１）処理概要
ＣＭＣＴＬ-Setプリミティブは、ＣＴＬがＣＭＬの変数を設定するためのプリミティブである。
（２）定義
図３１は、ＣＭＣＴＬ-Setプリミティブの引数を示す図である。
mibIndex：設定を要求する変数を指示する識別子である。
mibStatus：要求を実行した結果を示す識別子である。
mibParameter：設定する変数の内容である。

３．６ ＣＭＬとＭＬＭＥとのＳＡＰ（ＭＬＭＥ−ＣＭＬ ＳＡＰ）
輻輳制御サービスとして、ＣＭＬはＭＬＭＥに対して、以下の２種類のプリミティブを提供する。
（１）ＭＬＭＥ情報取得プリミティブ（ＭＬＭＥ-Get）
（２）ＭＬＭＥ情報設定プリミティブ（ＭＬＭＥ-Set）
３．６．１ ＭＬＭＥ情報取得プリミティブ（ＭＬＭＥ-Get）
（１）処理概要
ＭＬＭＥ-Getプリミティブは、ＣＭＬがＭＬＭＥの変数を取得するためのプリミティブである。
（２）定義
図３２は、ＭＬＭＥ-Getプリミティブの引数を示す図である。
mibIndex：取得を要求する変数を指示する識別子である。
mibStatus：要求を実行した結果を示す識別子である。
mibParameter：取得した変数の内容である。

３．６．２ ＭＬＭＥ情報設定プリミティブ（ＭＬＭＥ-Set）
（１）処理概要
ＭＬＭＥ-Setプリミティブは、ＣＭＬがＭＬＭＥの変数を設定するためのプリミティブである。
（２）定義
図３３は、ＭＬＭＥ-Setプリミティブの引数を示す図である。
mibIndex：設定を要求する変数を指示する識別子である。
mibStatus：要求を実行した結果を示す識別子である。
mibParameter：設定する変数の内容である。

３．７ ＣＭＬとＰＬＭＥとのＳＡＰ（ＰＬＭＥ−ＣＭＬ ＳＡＰ）
輻輳制御サービスとして、ＣＭＬはＰＬＭＥに対して、以下の２種類のプリミティブを提供する。
（１）ＰＬＭＥ情報取得プリミティブ（ＰＬＭＥ-Get）
（２）ＰＬＭＥ情報設定プリミティブ（ＰＬＭＥ-Set）
３．７．１ ＰＬＭＥ情報取得プリミティブ（ＰＬＭＥ-Get）
（１）処理概要
ＰＬＭＥ-Getプリミティブは、ＣＭＬがＰＬＭＥの変数を取得するためのプリミティブである。
（２）定義
図３４は、ＰＬＭＥ-Getプリミティブの引数を示す図である。
mibIndex：取得を要求する変数を指示する識別子である。
mibStatus：要求を実行した結果を示す識別子である。
mibParameter：取得した変数の内容である。

３．７．２ ＰＬＭＥ情報設定プリミティブ（ＰＬＭＥ-Set）
（１）処理概要
ＰＬＭＥ-Setプリミティブは、ＣＭＬがＰＬＭＥの変数を設定するためのプリミティブである。
（２）定義
図３５は、ＰＬＭＥ-Setプリミティブの引数を示す図である。
mibIndex：設定を要求する変数を指示する識別子である。
mibStatus：要求を実行した結果を示す識別子である。
mibParameter：設定する変数の内容である。

＜４．プロトコルデータ単位（Protocol Data Unit：ＰＤＵ）
４．１ ＰＤＵの構成
次に、ＣＴＬおよびＣＭＬで用いられるプロトコルデータユニット（ＰＤＵ）について説明する。図３６にアプリケーションデータを送信する際のＰＤＵ構成について示し、図３７に制御データを送信する際のＰＤＵ構成を示す。ここで、ＰＤＵとＳＤＵ（Service Data Unit）の関係について述べると、あるLayerにおいてヘッダがない状態をＳＤＵと呼び、そのLayerにおいてヘッダを付与した状態をＰＤＵと呼ぶ。

図３６に示すＰＤＵは、アプリケーションデータに、ＬＰＰヘッダ、ＬＰＣＰヘッダを付加してＣＴＬに渡され、ＣＴＬにおいてＣ２Ｃヘッダを付与され、通信下位プロトコル（Layer2）に渡される。図３７に示すＰＤＵは、ＣＭＬで生成される制御データをＣＴＬに渡され、ＣＴＬにおいてＣ２Ｃヘッダを付与され、通信下位プロトコル（Layer2）に渡される。

ここで、図３６に示すＰＤＵは、アプリケーションデータがＬＰＰ上でＬＰＰ ＳＤＵとして扱われ、ＬＰＰヘッダを付加されＬＰＰ ＰＤＵとなり、ＬＰＣＰに渡す。渡されたデータはＬＰＣＰ上でＬＰＣＰ ＳＤＵとして扱われ、ＬＰＣＰヘッダを付加されＬＰＣＰ ＰＤＵとなり、ＣＴＬに渡される。ＣＴＬ上では、渡されたデータがＣ２Ｃ ＳＤＵとして扱われ、Ｃ２Ｃヘッダを付加されＣ２Ｃ ＰＤＵとなり、Layer2に渡され、Layer2上ではＭＳＤＵ（ＭＡＣ ＳＤＵ）として扱われる。

４．２ Ｃ２Ｃヘッダ情報
図３８はＣＴＬにおいて付与するヘッダであるＣ２Ｃヘッダ情報を示す図である。
（１）Data Indetifier(データ識別子）
データの種類を区別する識別子である。「０」はアプリケーションデータ（上位プロトコルのデータ）を示し、「１」は管理データ（ＣＭＬのデータ）を示す。
２）ＰＤＵ Identifier（ＰＤＵ識別子）
ＰＤＵの種類を区別する識別子である。図３９に示すData IdentifierとＰＤＵ Identifierの値を示す。
（３）Node Priority（車両優先度）
車両の優先度（危険度）である。ＣＭＬのＣＭＬ変数取得プリミティブにより取得する。
（４）Channel Occupancy（通信チャネル利用率）
所定時間内における通信帯域がビジーの割合である。単位は［％］とし、０から１００までの値を設定される。ＣＭＬ変数取得プリミティブにより取得される。
（５）Cyclic Interval（送信周期）
周期的に情報を送信するアプリケーションの送信する時間間隔である。単位は［１０msec］とし、１（１０msec）から２５５（２５５０msec）までの値が設定される。ＣＭＬ変数取得プリミティブにより取得される。
（６）Transmission Power（送信電力）
Ｃ２Ｃヘッダ生成時に設定されている送信電力の値である。単位は［０．１dBm］とし、−５．０dBmから２０．０dBmまでの値が設定される。ＣＭＬ変数取得プリミティブにより取得される。
（７）Receiver Sensitivity(受信感度）
Ｃ２Ｃヘッダ生成時に設定されている受信感度の値を格納する。単位は［１dBm］とし、−１２７dBmから０dBmまでの値を設定する。ＣＭＬ変数取得プリミティブにより取得する。
（８）Reserved（予約）
予約領域を確保する。

４．３ ビーコンメッセージ（Beacon ＰＤＵ）
初期接続を開始するトリガーとしたり、時刻同期を取ったりするためのビーコンメッセージを送信するＰＤＵである。図４０にビーコンメッセージの形式を示す。
（１）ＴＳＦ Timer（ＴＳＦタイマ）
時刻同期を取るためのＴＳＦタイマである。値は０−２⁶⁴の範囲を取る。
（２）Next Beacon Transmission Timing（次にビーコンを送信するタイミング）
ビーコンメッセージを送信する次回のタイミングである。単位は［msec］とし、０−１０００の範囲を取る。
（３）ＣＭＬ Profile（ＣＭＬプロファイル）
自局のサポートする機能、アプリケーション情報、チャネル情報、および通信制御情報が格納されるＣＭＬプロファイルである。

４．４ 接続要求メッセージ（Connect Request ＰＤＵ）
通信接続の要求を行うためのＰＤＵである。図４１に接続要求メッセージの形式を示す。
（１）Required Ack Flag（再送要求フラグ）
再送処理が有効かどうかを示すフラグである。「１」の場合はＰＤＵの再送処理が有効となり、メッセージを相手に通知する共に確認応答（Ack ＰＤＵ）を要求する。「０」の場合は再送処理を無効とする。
（２）Retransmit Flag（再送フラグ）
再送されたＰＤＵかどうかを示すフラグである。「１」を示す場合は、再送されたＰＤＵであることを示す。
（３）Sequence Number（シーケンス番号）
シーケンス番号である。相手局のリンクアドレスとシーケンス番号から、重複するＰＤＵを検出する。
（４）ＣＭＬ Profile（ＣＭＬプロファイル）
自局のサポートする機能や、アプリケーション情報、チャネル情報、および通信制御情報が格納されるＣＭＬプロファイルである。

４．５ 接続応答メッセージ（Connect Response ＰＤＵ）
接続要求に応答するためのＰＤＵである。図４２に接続応答メッセージの形式を示す。
（１）Result Code（リザルトコード）
初期接続を行うか否かの結果を示す。接続する相手局とサポートするアプリケーションが異なる場合は「接続しない」を通知し、サポートするアプリケーションが存在する場合は「接続する」を通知する。図４３にResult Codeの内容を示す。
（２）Required Ack Flag（再送要求フラグ）
再送処理が有効かどうかを示すフラグである。「１」の場合はＰＤＵの再送処理が有効となり、メッセージを相手に通知する共に確認応答（Ack ＰＤＵ）を要求する。「０」の場合は再送処理を無効とする。
（３）Retransmit Flag（再送フラグ）
再送されたＰＤＵかどうかを示すフラグである。「１」を示す場合は、再送されたＰＤＵであることを示す。
（４）Sequence Number（シーケンス番号）
シーケンス番号である。相手局のリンクアドレスとシーケンス番号から、重複するＰＤＵを検出する。
（５）Profile Flag（プロファイルフラグ）
Connect Response ＰＤＵにＣＭＬプロファイル情報が付加されているかどうかを示すフラグである。「０」の場合は、後続するＣＭＬ ProfileフィールドにはＣＭＬプロファイルが格納されておらず、「１」の場合は後続するＣＭＬ ProfileフィールドにＣＭＬプロファイルが格納されている。
Beacon ＰＤＵにより、ＣＭＬプロファイルが提供済みの場合に、この識別子を「０」に設定し、ＣＭＬプロファイルを格納しない。Beacon ＰＤＵを利用していない場合（周期的に送信するアプリケーション主導の接続手順の場合）は、この識別子を「１」に設定し、ＣＭＬプロファイルを格納する。
（６）ＣＭＬ Profile（ＣＭＬプロファイル）
自局のサポートする機能や、アプリケーション情報、チャネル情報、および通信制御情報が格納されるＣＭＬプロファイルである。

４．６ 確認応答メッセージ（Ack ＰＤＵ）
再送要求が行われている場合に確認応答を返すＰＤＵである。図４４に確認応答メッセージの形式を示す。
（１）Retransmit Flag（再送フラグ）
再送されたＰＤＵかどうかを示すフラグをである。「１」を示す場合は、再送されたＰＤＵであることを示す。
（２）Sequence Number（シーケンス番号）
シーケンス番号である。相手局のリンクアドレスとシーケンス番号から、重複するＰＤＵを検出する。

４．７ 輻輳制御メッセージ（Congestion Control ＰＤＵ）
輻輳制御を行うために、周辺車両に設定する通信パラメータを要求する場合のＰＤＵである。図４５に輻輳制御メッセージの形式を示す。
（１）Transmission Power for others（要求する送信電力）
周辺車両に対して要求する送信電力の値である。単位は［０．１dBm］とし、−５．０dBmから２０．０dBmまでの値が設定される。
（２）Transmission Interval for others（要求する送信周期）
周辺車両に対して要求する送信周期の値である。単位は［１０msec］とし、１（１０msec）から２５５（２５５０msec）までの値が設定される。
（３）Receiver Sensitivity for others（要求する受信感度）
周辺車両に対して要求する受信感度の値である。単位は［１dBm］とし、−１２７dBmから０dBmまでの値が設定される。

４．８ イベント通知メッセージ（Event ＰＤＵ）
ＣＴＬおよびＣＭＬ内で発生したエラーなどのイベントを相手局に通知するＰＤＵである。図４６にイベント通知メッセージの形式に示す。
（１）eventCode（イベントコード）
イベントの内容を示すコードである。図４７にイベントコードの内容を示す。
（２）extensionParameter（パラメータ）
イベントの内容を補完するパラメータである。

＜５．動作手順＞
５．１ データ転送手順
５．１．１ アプリケーションデータ送受信手順
ＣＴＬにおけるアプリケーションデータを送受信する手順について記載する。図４８にメッセージ転送の基本処理シーケンス例を示す。

（送信手順）
（１）ＣＴＬはＬＰＣＰからデータ送信要求プリミティブ（sendData.req）を受け取ると、変数parameterからＣ２Ｃ ＳＤＵを取得する。
（２）ＣＴＬはＣ２Ｃ ＳＤＵ内のＬＰＣＰ制御情報を参照して、送信元ポート番号を取得する。
（３）ＣＴＬはＣＭＬ情報取得プリミティブ（ＣＭＣＴＬ-Get）を用いて、送信元ポート番号の優先度を取得する。
（４）ＣＹＬはＣ２Ｃ Headerを付加して、Ｃ２Ｃ ＰＤＵを生成した後、取得した優先度のキューに格納し、優先度制御処理を適用する。
（５）ＣＴＬは優先度制御により、送信待機した後、通信下位プロトコルのデータ伝送プリミティブ（ＤＬ-Unitdata.req）で送信し、送信処理を完了する。

以下の場合のＣ２ＣＳ ＤＵは無効とし、処理しない。

・変数linkAddressがグループ同報リンクアドレスで、そのアドレス値が「０」でない場合、その要求プリミティブは破棄し、ＬＰＣＰに対してイベント通知プリミティブ（eventReport）にて、状態「指定されたグループ同報リンクアドレスは有効でない」を通知する。

（受信手順）
（１）ＣＴＬは通信下位プロトコルからデータ伝送プリミティブ（ＤＬ-Unitdata.ind）で、Ｃ２Ｃ ＰＤＵを受け取ると、そのＰＤＵからデータ識別子、ＰＤＵ識別子、車両優先度、チャネル利用率、送信周期、送信電力、受信感度、ユーザデータを取り出す。
（２）ＣＴＬはデータ識別子（Data Identifier）が「０」を示し、ＰＤＵ識別子（ＰＤＵ Identifier）が「０」または「１」の場合は、上位プロトコルに対して、データ送信通知プリミティブ（sendData.ind）で相手局からのデータ（Ｃ２Ｃ ＳＤＵ）の受信を転送する。
（３）ＣＴＬはＤＬ-Unitdata.indで得られた送信元リンクアドレスと、受信した車両優先度、チャネル利用率、送信周期、送信電力、受信感度をＣＭＬに対して、ＣＭＬ情報設定プリミティブ（ＣＭＣＴＬ-Set）を用いて登録し、受信処理を完了する。
以下の場合のＣ２Ｃ ＰＤＵは無効とし、処理しない。
・データ識別子が「０」であり、ＰＤＵ識別子が「０」または「１」でない場合、その通知プリミティブは破棄し、相手局ＣＴＬに対してイベント通知メッセージにて、状態「指定されたＰＤＵ識別子は有効でない」を通知する。
・データ識別子が有効でない場合、その通知プリミティブは破棄し、相手局ＣＴＬに対してイベント通知メッセージにて、状態「指定されたデータ識別子は有効でない」を通知する。

５．１．２ 制御データ送受信手順
ＣＴＬにおける制御データを送受信する手順について記載する。図４９にメッセージ転送の基本処理シーケンス例を示す。

（送信手順）
（１）ＣＴＬはＣＭＬから制御データ送信要求プリミティブ（ＣＭＣＴＬ-SendData.req）を受け取ると、変数parameterからＣ２Ｃ ＳＤＵ、変数priorityから優先度を取得する。
（２）ＣＴＬはＣ２Ｃ Headerを付加して、Ｃ２Ｃ ＰＤＵを生成した後、変数priorityから取得した優先度のキューに格納し、優先度制御処理を適用する。
（３）ＣＴＬは優先度制御により、送信待機した後、通信下位プロトコルのデータ伝送プリミティブ（ＤＬ-Unitdata.req）で送信し、送信処理を完了する。
以下の場合のＣ２Ｃ ＰＤＵは無効とし、処理しない。
・変数linkAddressがグループ同報リンクアドレスで、そのアドレス値が「０」でない場合、その要求プリミティブは破棄し、ＣＭＬに対してイベント通知プリミティブ（ＣＭＣＴＬ-EventReport）にて、状態「指定されたグループ同報リンクアドレスは有効でない」を通知する。

（受信手順）
（１）ＣＴＬは通信下位プロトコルからデータ伝送プリミティブ（ＤＬ-Unitdata.ind）でＣ２Ｃ ＰＤＵを受け取ると、そのＰＤＵからデータ識別子、ＰＤＵ識別子、車両優先度、チャネル利用率、送信周期、送信電力、受信感度、ユーザデータを取り出す。
（２）ＣＴＬはデータ識別子（Data Identifier）が「１」を示す場合はＣＭＬに対して、制御データ送信通知プリミティブ（ＣＭＣＴＬ-SendData.ind）で相手局からのデータの受信を通知する。
（３）ＤＬ-Unitdata.indで得られた送信元リンクアドレスと、受信した車両優先度、チャネル利用率、送信周期、送信電力、受信感度をＣＭＬに対して、ＣＭＬ情報設定プリミティブ（ＣＭＣＴＬ-Set）を用いて登録し、受信処理を完了する。

５．２ 優先度制御サービス手順
（１）ＣＴＬは優先度ごとにキューに格納されたデータを、優先度の高いほうから順に取り出し、データ伝送プリミティブ（ＤＬ-Unitdata.req）を用いて、送信する。
（２）ＣＴＬは優先度の高いキューが空になれば、優先度が一つ低いキューからデータを取り出して送信する。
優先度のキューにおいて、優先度“Middle”キューには周期的に情報を送信する情報交換型アプリケーションのデータのみが格納され、新しいデータが格納された場合にはキューにある古いデータは破棄し、最新のデータを保持する。なお、優先度“High”キューには緊急情報、“Low”キューには非リアルタイム情報を格納する。

５．３ 輻輳制御サービス手順
５．３．１ 通信制御手順
輻輳制御は以下の手順を、車両情報が変更された場合および周期的に行う。図５０にＣＭＬにおける輻輳制御の基本シーケンスを示す。
（１）アプリケーションはＣＭＬに対して、アプリケーション情報設定プリミティブ（ＡＣＭＬ-Set）を用いて、自車両の車両情報および周辺車両から受信した車両情報を設定する。
（２）ＣＭＬは周期的にＰＬＭＥに対して、ＰＬＭＥ情報取得プリミティブ（ＰＬＭＥ-Get）を用いて、通信チャネルの利用率情報を取得する。
（３）ＣＭＬは収集した情報から、輻輳を回避するために設定すべき送信周期・送信電力・受信感度を算出する。ここでは各パラメータを算出する具体的なアルゴリズムについては５．３．１．１に示す。
（４）ＣＭＬは周期的に情報を送信するアプリケーションに対して、アプリケーション通知プリミティブ（ＡＣＭＬ-Notify）を用いて算出した送信周期を通知する。
（５）前記アプリケーションは通知された送信周期に従って、次のタイミング以降の車両情報の送信を繰り返し行う。
（６）ＣＭＬはＰＬＭＥに対して、ＰＬＭＥ情報設定プリミティブ（ＰＬＭＥ-Set）を用いて、算出した送信電力および受信感度を設定する。
（７）通信下位プロトコルでは設定された送信電力および受信感度に従って、次の送受信を開始する。この際、送信するチャネルの種類によって、設定する送信電力および受信感度を切り替えても良い。

５．３．１．１ 輻輳制御アルゴリズム
ＣＭＬにおける輻輳制御アルゴリズムを説明する。まず、輻輳制御に必要な情報の収集および設定について述べる。自車両および周辺車両の位置、速度、加速度、および走行方向はアプリケーションによって、ＣＭＬに設定され、自車両の通信制御パラメータ（チャネル利用率、送信周期、送信電力、受信感度）および周辺車両の通信制御パラメータもＣＭＬに格納されている。さらに、ここで用いる必要な通信距離はＣＭＬ内で算出しても良いし、アプリケーションで算出し、ＣＭＬ情報設定プリミティブで設定しても良い。
次に、送信周期を制御する輻輳制御について示す。

（送信周期制御アルゴリズム）
本発明では、通信チャネルが混雑していない場合はアプリケーションの要求仕様である送信周期の値を適用し、通信チャネルが混雑し始めた場合に送信周期を徐々に長くする手法を利用する。

まず、自車両の通信チャネル利用率Ｏｉ（ｔ）と周辺車両の通信チャネル利用率Ｏｊ（ｔ）から最大値Ｏｍａｘ（ｔ）を選択する。

Ｏｍａｘ（ｔ）＝ｍａｘ｛Ｏｉ（ｔ）、Ｏｊ（ｔ）｝（ｊ＝１，・・・，Ｎ）
ただし、Ｎは自車両ｉが通信中の車両台数を示す。

次に、送信周期を通信チャネル利用率Ｏｍａｘ（ｔ）に基づいて算出する。ここでは送信周期Ｔ（ｔ＋１）は通信チャネル利用率に基づき、目標とする通信チャネル利用率Ｏｔｈに収束する設定する。自車両の検出するチャネル利用率と周辺車両のチャネル利用率および目標のチャネル利用率を用いて、目標値と最大値の差分を利用してフィードバック制御を行うと、送信周期は次式のように算出する。

Ｔ（ｔ＋１）＝Ｔ（ｔ）＋Ｋ×｛Ｏｍａｘ（ｔ）−Ｏｔｈ｝
＋Ｋ／Ｉ×∫｛Ｏｍａｘ（ｔ）−Ｏｔｈ｝ｄｔ
＋Ｋ×Ｔｄ×ｄ／ｄｔ｛Ｏｍａｘ（ｔ）−Ｏｔｈ｝
ただし、Ｔ（ｔ＋１）は次に適用する送信周期を示し、Ｔ（ｔ）は前回適用された送信周期を示し、Ｏｍａｘ（ｔ）は最大の通信チャネル利用率、Ｋは比例ゲイン、Ｉは積分時間、Ｔｄは微分時間を示す。この比例ゲイン、積分時間、および微分時間の設定値によって、通信チャネル利用率を目標の閾値に収束させるまでに要する時間を変更させることができる。また、目標のチャネル利用率を調整することによって、実現できる通信の信頼性を変更できるため、アプリケーションが要求する信頼性によって目標のチャネル利用率を設定することができる。
次に、送信電力を制御する輻輳制御について示す。

（送信電力制御アルゴリズム）
送信間隔と同様に、送信電力を制御することで効率的に輻輳を回避できると考えられるので、混雑し始めた場合には通信エリアを絞る。

送信電力を制御する場合においても、通信チャネル利用率を通信の信頼性確保が見込める目標値に抑える手法を利用する。自車両の送信電力を絞ることで、周辺車両にとっては通信トラフィック量が減らすことができる。そのため、周辺車両の通信チャネル利用率の最も高い値に基づいて制御を行うことで、最もチャネル利用率の高い車両の検出する通信トラフィック量を効率的に制限できる。

送信電力の算出には、送信周期と同様にフィードバック制御を適用し、自車両との通信台数が一定台数以下になるように送信電力を算出する。まず、周辺車両から受信した送信周期Ｔｊ（ｔ）（ｊ＝１，・・・，Ｎ）と自車両で把握できる通信台数Ｎ［台］から次のように自車両の通信チャネル利用率Ｏ（ｔ）を算出する。

ただし、Ｓは送信するデータサイズ［bit］、Ｃは伝送速度［bit per sec］を示す。

次に、通信チャネル利用率Ｏ（ｔ）が目標チャネル利用率Ｏｔｈよりも小さくなる通信台数ｍ［台］を算出する。自車両との車間距離Ｄｊが短い周辺車両から順に、ｊ＝１、２、３・・・、Ｎと設定し、Ｏ（ｔ）＞Ｏｔｈとなる最初のｊをｊ＝ｌとすると、ｍ＝ｌ−１と設定できる。この際の車間距離はＤｍであり、これが目標の通信距離となる。

自車両と通信できる台数がｍ［台］に収束するように次式のように必要となる通信距離Ｄ（ｔ＋１）を算出する。

Ｄ（ｔ＋１）＝Ｄ（ｔ）＋Ｋ×｛ｎ（ｔ）−ｍ｝
＋Ｋ／Ｉ×∫｛ｎ（ｔ）−ｍ｝ｄｔ
＋Ｋ×Ｔｄ×ｄ／ｄｔ｛ｎ（ｔ）−ｍ｝
ただし、Ｄ（ｔ＋１）は次に送信する通信距離を示し、Ｄ（ｔ）は前回設定された通信距離を示し、ｎ（ｔ）［台］は現在自車両と通信している台数、Ｋは比例ゲイン、Ｉは積分時間、Ｔｄは微分時間を示す。なお、ここでの比例ゲイン、積分時間、微分時間は送信周期制御アルゴリズムと同じ値を適用してもいいし、異なる値を適用しても良い。

次に、通信距離Ｄ（ｔ＋１）を実現するための送信電力Ｐ（ｔ＋１）をあらかじめ設定されている通信仕様から算出し、新たな送信電力として適用する。

（受信感度制御アルゴリズム）
受信感度を制御することによって、自車両の受信できるエリアを制限することができる。送信電力が相手車両において発生する輻輳を回避するのに対し、受信感度は自車両において発生する輻輳を回避できる。そのため、送信電力制御アルゴリズムにおいて算出された送信電力Ｐ（ｔ＋１）と以前の送信電力Ｐ（ｔ）の差分を一部だけ受信感度に振り分けることで、相手車両における輻輳を軽減するか、自車両における輻輳を軽減するかを選択することができる。

まず、送信電力制御だけの場合には、送信電力をａ（ａ＝Ｐ（ｔ＋１）−Ｐ（ｔ））［dBm］だけ小さく設定していた。ここで、受信感度制御を適用し、一部ｂ［dBm］を受信感度に振り分けると、送信電力は（ａ−ｂ）［dBm］小さく設定し、受信感度はｂ［dBm］だけ大きく設定することで、送信電力制御を利用した場合と同様に輻輳を軽減することが可能になる。

５．３．２ 輻輳制御メッセージ送信手順
輻輳制御メッセージは以下の手順で送信される。
（送信手順）
（１）ＣＭＬは輻輳制御メッセージの送信契機になると、相手局に指示する通信制御パラメータ値を決定する。例えば、本発明では輻輳制御メッセージの送信契機は通信チャネル利用率が４０％を超えた場合に行ったり、アプリケーション処理部３から輻輳制御メッセージの送信要求があったりした場合うものとする。また、相手局に指示する通信制御パラメータ値は自局で設定される値を適用する。
（２）ＣＭＬはCongestion Control ＰＤＵを生成し、ＣＴＬに対して、制御データ送信要求プリミティブ（ＣＭＣＴＬ-SendData.req）を発行する。

（受信手順）
（１）ＣＭＬはＣＴＬから制御データ送信通知プリミティブ（ＣＭＣＴＬ-SendData.ind）を受信すると、変数parameterから指示された通信制御パラメータ値を取り出す。
（２）ＣＭＬは相手局の車両優先度と自局の車両優先度を比較し、相手局の車両優先度が高く、通信チャネル利用率が大きければ、相手局の指定するパラメータに設定して通信を行う。

５．４ 初期接続手順
５．４．１ 初期接続開始手順
（１）アプリケーションはＣＭＬに対して、接続開始プリミティブ（ＡＣＭＬ-Connection）を用いて、個別通信を行うための接続要求を行う。
（２）ＣＭＬは、ＡＣＭＬ-Connectionの変数connectionFlagが「１」を示す場合にはアプリケーションが個別通信を行うために、接続要求フラグを「１」に設定する（接続要求フラグが「１」の場合には、周辺局から同報メッセージおよびビーコンメッセージを受信した場合に初期接続シーケンスを開始する）。
（３）ＣＭＬは、アプリケーション情報テーブルを参照し、周期的に車両情報を送信する同報アプリケーションがサポートされているかを確認する。
（ａ）ＣＭＬは同報アプリケーションがサポートされている場合にはビーコンメッセージ（Beacon ＰＤＵ）送信フラグを「０」に設定し、５．４．３に示すように同報アプリケーションメッセージの受信を契機に初期接続シーケンスを開始する。
（ｂ）ＣＭＬは同報アプリケーションがサポートされていない場合、かつ接続開始プリミティブの変数beaconFlagが「１」を示す場合にはビーコンメッセージ（Beacon ＰＤＵ）送信フラグを「１」に設定し、５．４．２に示すようにビーコンメッセージの送信シーケンスを開始する。

５．４．２ ビーコンメッセージを用いた初期接続手順
図５１にＣＭＬにおけるビーコンメッセージを用いた場合の初期接続手順の基本シーケンスを示す。また、図５２にＣＭＬにおけるビーコンメッセージを用いた初期接続手順のビーコンメッセージを破棄する場合のシーケンスを示す。
（１）ＣＭＬは周辺局がビーコンメッセージを送信しているかを確認する。ビーコンスキャンを行うために、ビーコンスキャンタイマを起動する。
（ａ）ＣＭＬはビーコンスキャンタイマがタイムアウトするまでに、周辺局からBeacon ＰＤＵを受信した場合は、（３）以降に記載の手順に従って初期接続シーケンスを開始する。
（ｂ）ＣＭＬはビーコンスキャンタイマがタイムアウトするまでに、周辺局からBeacon ＰＤＵを受信しなかった場合は、（２）以降に記載の手順に従って初期接続シーケンスを開始する。
（２）ＣＭＬはBeacon ＰＤＵを生成し、制御メッセージ送信プリミティブ（ＣＭＣＴＬ-SendData）を用いて、ＣＴＬに送信を要求する。
（３）ＣＴＬから制御メッセージ送信プリミティブによって、Beacon ＰＤＵを示すメッセージが通知されると、接続状況を確認するために接続管理テーブルを参照する。
（ａ）「接続済み」の場合には受信したBeacon ＰＤＵを破棄し、初期接続シーケンスを完了する。
（ｂ）「未接続」の場合には接続要求フラグを参照し、接続要求フラグが「１」を示す場合は相手局のLinkAddressと受信したBeacon ＰＤＵからＣＭＬ Profileを接続管理テーブルに登録し、Connect Request ＰＤＵを生成し、制御メッセージ送信プリミティブ（ＣＭＣＴＬ-SendData）を用いて、ＣＴＬに送信を要求する。接続要求フラグが「０」を示す場合は初期接続シーケンスを開始しない。
（４）ＣＭＬはＣＴＬから制御メッセージ送信プリミティブによって、Connect Request ＰＤＵを示すメッセージが通知されると、接続状況を確認するために接続管理テーブルを参照する。
（ａ）「接続済み」の場合には受信したConnect Request ＰＤＵを破棄し、Connect Response ＰＤＵを用いて、resultCode「接続済み」を返す。
（ｂ）「未接続」の場合には相手局のLinkAddressと受信したConnect Request ＰＤＵからＣＭＬ Profileを接続管理テーブルに登録し「接続済み」に設定する。Connect Response ＰＤＵを生成し、制御メッセージ送信プリミティブ（ＣＭＣＴＬ-SendData）を用いて、ＣＴＬに送信を要求する。
（５）ＣＭＬはＣＴＬから制御メッセージ送信プリミティブによって、Connect Response ＰＤＵを示すメッセージが通知されると、接続状況を確認するために接続管理テーブルを参照する。相手局のLinkAddressに対して、接続管理テーブルを「接続済み」に設定する。Ack ＰＤＵを生成し、制御メッセージ送信プリミティブ（ＣＭＣＴＬ-SendData）を用いて、ＣＴＬに送信を要求する。
（６）ＣＭＬはＣＴＬから制御メッセージ送信プリミティブによって、Ack ＰＤＵを示すメッセージが通知されると、アプリケーションに接続開始応答プリミティブ（ＡＣＭＬ-Connection.cnf）を返し、初期接続シーケンスを完了する。

５．４．３ 同報アプリケーションを用いた初期接続手順
図５３にＣＭＬにおける同報アプリケーションを用いた場合の初期接続手順の基本シーケンスを示す。また、図５４にＣＭＬにおける同報アプリケーションを用いた初期接続手順の接続を行わない場合のシーケンスを示す。ただし、周期的に情報を送信するアプリケーションを用いた初期接続手順は、シングルチャネル利用時にのみサポートされる。
（１）ＣＴＬは相手局から同報アプリケーションのデータを受信した後、ＣＭＬは、ＣＴＬからＣＭＬ情報設定プリミティブを用いて、Ｃ２Ｃ Headerに含まれる情報の登録を要求されると、接続管理テーブルを参照し、相手局との接続状況を確認する。
（ａ）「接続済み」の場合には、初期接続シーケンスを完了する。
（ｂ）「未接続」の場合には接続要求フラグを参照し、接続要求フラグが「１」を示す場合はConnect Request ＰＤＵを生成し、制御メッセージ送信プリミティブ（ＣＭＣＴＬ-SendData）を用いて、ＣＴＬに送信を要求する。接続要求フラグが「０」を示す場合は初期接続シーケンスを開始しない。
（２）ＣＭＬはＣＴＬから制御メッセージ送信プリミティブによって、Connect Request ＰＤＵを示すメッセージが通知されると、接続状況を確認するために接続管理テーブルを参照する。
（ａ）「接続済み」の場合には受信したConnect Request ＰＤＵを破棄し、Connect Response ＰＤＵを用いて、resultCode「接続済み」を返す。
（ｂ）「未接続」の場合には接続要求フラグを参照し、接続要求フラグが「１」を示す場合は相手局のLinkAddressと受信したConnect Request ＰＤＵからＣＭＬ Profileを接続管理テーブルに登録し、「接続済み」に設定する。Connect Response ＰＤＵを生成し、制御メッセージ送信プリミティブ（ＣＭＣＴＬ-SendData）を用いて、ＣＴＬに送信を要求する。接続要求フラグが「０」を示す場合はConnect Response ＰＤＵを用いて、resultCode「接続しない」を返す。
（３）ＣＭＬはＣＴＬから制御メッセージ送信プリミティブによって、Connect Response ＰＤＵを示すメッセージが通知されると、変数resultCodeを参照し、「接続しない」を示す場合はConnect Response ＰＤＵを破棄し、「接続する」を示す場合は接続状況を確認するために接続管理テーブルを参照する。相手局のLinkAddressに対して、接続管理テーブルを「接続済み」に設定する。Ack ＰＤＵを生成し、制御メッセージ送信プリミティブ（ＣＭＣＴＬ-SendData）を用いて、ＣＴＬに送信を要求する。
（４）ＣＭＬはＣＴＬから制御メッセージ送信プリミティブによって、Ack ＰＤＵを示すメッセージが通知されると、アプリケーションに接続開始応答プリミティブ（ＡＣＭＬ-Connection.cnf）を返し、初期接続シーケンスを完了する。

５．４．４ 接続状況通知手順
ＣＭＬは、相手局との接続が確立すると、イベント通知プリミティブを利用してＣＴＬに「接続が確立した」ことを通知する。ＣＴＬは接続が確立したことを通知されると、イベント通知プリミティブを用いて上位層に通知する。また、タイムアウトなどにより、相手局と切断した場合にも同様の手順によって、「切断した」イベントを通知する。図５５に接続状況を通知する手順の例を示す。
（１）ＣＭＬは、Connect Request ＰＤＵおよび、Connect Response ＰＤＵを受信して、相手局との通信接続が確立する。
（２）ＣＭＬは、イベント通知プリミティブ（ＣＭＣＴＬ-EventReport）を用いて、ＣＴＬに接続が確立したことを通知する。
（３）ＣＴＬは、イベント通知プリミティブ（EventReport.ind）を用いて、上位層に接続が確立したことを通知する。

５．５ アプリケーション登録／削除手順
図５６にＣＭＬにおけるアプリケーション情報の登録および削除手順を示す。

５．５．１ 登録手順
（１）移動局の各アプリケーションは、提供可能な状態になったらアプリケーション登録要求プリミティブ（ＡＣＭＬ-Registration.req）を用いて、ＣＭＬに登録する。
（２）ＣＭＬはアプリケーション情報テーブルを更新する。
（３）ＣＭＬはアプリケーション登録通知プリミティブ（ＡＣＭＬ-Registration.ind）を用いて、アプリケーションに登録結果を通知する。

５．５．２ 削除手順
（１）移動局の各アプリケーションは、提供不可能な状態になったらアプリケーション削除プリミティブ（ＡＣＭＬ-Deregistration）を用いて、ＣＭＬに通知する。
（２）ＣＭＬはアプリケーション情報テーブルを更新する。
（３）ＣＭＬはアプリケーション削除通知プリミティブ（ＡＣＭＬ-Deregistration.ind）を用いて、アプリケーションに削除結果を通知する。

５．６ 再送制御手順
図５７に再送処理が有効な場合のＣＭＬにおける基本処理シーケンス例を示し、図５８に再送を行う場合のＣＭＬにおける処理シーケンス例を示し、図５９に再送処理における重複チェックを行う場合のＣＭＬにおけるシーケンス例を示す。

（送信手順）
（１）ＣＭＬは制御データ（接続要求メッセージ、接続応答メッセージ）を送信する場合、再送処理が有効な接続管理サービスが開始される。
（２）ＣＭＬはRequired Ack Flag（再送要求フラグ）が「１」を示すＰＤＵを作成し、制御メッセージ送信プリミティブ（ＣＭＣＴＬ-SendData.req）を用いて、ＣＴＬに送信を要求する。
（３）ＣＭＬは送信を要求すると同時に再送タイマを起動し、前記ＰＤＵを保持し、相手局からの応答メッセージの受信を待機する。
（４）ＣＭＬは再送タイマがタイムアウトするまでに、相手局からの応答メッセージを受信すると、再送タイマを停止し、保持していたＰＤＵを破棄し、このトランザクションを完了する。
（５）ＣＭＬは（３）で送信したＰＤＵが相手局に到達しないなど何らかの理由により応答メッセージを受信するまでに再送タイマがタイムアウトした場合は、Retransmit Flag（再送フラグ）を「１」に設定して、ＣＴＬにＰＤＵの送信を要求すると同時に再送タイマを再起動、再送カウンタを１インクリメントする。
（６）ＣＭＬは数回再送を繰り返しても応答メッセージを受信できずに、再送カウンタが最大再送回数を超えた場合は、保持していたＰＤＵを破棄し、このトランザクションを完了する。

（受信手順）
（１）ＣＭＬはＣＴＬから制御メッセージ送信通知プリミティブ（ＣＭＣＴＬ-SendData.ind）により、Required Ack Flag（再送要求フラグ）が「１」を示すＰＤＵを受信した場合は応答メッセージを生成し、制御メッセージ送信プリミティブ（ＣＭＣＴＬ-SendData.req）を用いて、ＣＴＬに送信を要求する。
（２）ＣＭＬは送信を要求すると同時にウェイトタイマを起動する。
（３）ＣＭＬは（２）で送信した応答メッセージが相手局に到達しないなどの理由で、再度同じＣＭＬ−ＳＤＵを受信した場合には、受信したＰＤＵを破棄し、再度応答メッセージを生成し、制御メッセージ送信プリミティブ（ＣＭＣＴＬ-SendData.req）を用いて、ＣＴＬに送信を要求し、ウェイとタイマを再起動する。
（４）（２）または（３）で起動したウェイトタイマがタイムアウトすると、このトランザクションを完了する。

実施の形態１に係る車載通信装置および路車間−車々間通信連携システムは、以上説明した車々間通信サブプロトコルの仕様に従って動作する。

＜Ａ−３．車載通信装置１００の動作＞
以下、図２を参照しつつ図６０〜図７１を用いて実施の形態１の車載通信装置１００の各部の動作について説明する。

＜Ａ−３−１．データ転送サービス処理部１１の動作＞
図６０は、車々間通信転送サービス処理部１のデータ転送サービス処理部１１の動作を示すフローチャートである。

データ転送サービス処理部１１は、メッセージの送信要求および受信通知の受信まで待機する（ステップＳ１０１）。ここで送信要求および受信通知を受信していない場合（「Ｎｏ」の場合）には、データ転送サービス処理部１１は、送信要求および受信通知の受信の待機を継続する。これに対して、送信要求および受信通知を受信した場合（「Ｙｅｓ」の場合）には、ステップＳ１０２へと移行する。

ステップＳ１０２では、ステップＳ１０１で受信したデータの送信要求および受信通知を識別し、送信要求である場合（「Ｙｅｓ」の場合）には、ステップＳ１０３へと移行する。これに対して、受信通知である場合（「Ｎｏ」の場合）、ステップＳ１１０へと移行する。

ステップＳ１０３では、ステップＳ１０２で受信した送信要求が転送サービス処理部５からの要求か、車々間通信管理サービス処理部２からの要求かを識別し、転送サービス処理部５からの要求の場合（「Ｙｅｓ」の場合）には、ステップＳ１０４へと移行する。これに対して、車々間通信管理サービス処理部２からの要求の場合（「Ｎｏ」の場合）には、ステップＳ１０８へと移行する。

次に、ステップＳ１０４では、ＬＰＣＰ転送サービス処理部５１から発行されたプリミティブから、送信するデータ（Ｃ２Ｃ ＳＤＵ）を取り出し、ＬＰＣＰヘッダから送信元ポート番号を取得する。

ステップＳ１０５では、データ転送サービス処理部１１は車々間通信管理サービス処理部２の管理情報格納部２４から、送信元ポート番号を示すアプリケーションの優先度およびメッセージに付与する通信制御情報のパラメータを取得する。

そして、ステップＳ１０６では、取得した通信制御情報からＣ２Ｃヘッダ作成し、Ｃ２Ｃ ＰＤＵを生成する。

次に、ステップＳ１０７では、ステップＳ１０６で生成したＣ２Ｃ ＰＤＵと、Ｓ１０５で取得した優先度とを、優先度制御サービス処理部１３に送信し、転送サービス処理部５からのデータ送信手順が完了する。

また、ステップＳ１０３で、車々間通信管理サービス処理部２からの送信要求であると識別された場合、ステップＳ１０８では、まず車々間通信管理サービス処理部２から発行されたプリミティブから、送信するデータ（Ｃ２Ｃ ＳＤＵ）と優先度とを取得する。

次に、ステップＳ１０９では、データ転送サービス処理部１１は車々間通信管理サービス処理部２の管理情報格納部２４から、Ｃ２Ｃヘッダに付与する通信制御情報のパラメータを取得する。

そして、ステップＳ１０６およびＳ１０７の処理を行い、車々間通信管理サービス処理部２のデータ送信手順を完了する。

また、ステップＳ１０２において、データの受信通知を受け取ったものと識別された場合、ステップＳ１１０ではデータ転送サービス処理部１１は送受信サービス処理部６から発行されたプリミティブから、受信したデータ（Ｃ２Ｃ ＰＤＵ）を取得する。さらに、Ｃ２Ｃヘッダから各パラメータを取得する。

次に、ステップＳ１１１では、受信したデータの配信先を選択するためにデータ識別子（Data Identifier）を参照し、転送サービス処理部５（ＬＰＣＰ）に送信するか、車々間通信管理サービス処理部２（ＣＭＬ）に送信するかを判断する。

ステップＳ１１１でデータ識別子が「０」を示す場合（「Ｙｅｓ」の場合）は、ステップＳ１１２へと移行する。これに対して、データ識別子が「１」を示す場合（「Ｎｏ」の場合）は、ステップＳ１１４へと移行する。

そして、ステップＳ１１２では、受信したＣ２Ｃ ＳＤＵを転送サービス処理部５のＬＰＣＰ転送サービス処理部５１に送信する。

次に、ステップＳ１１３では、受信したＣ２Ｃヘッダの通信制御情報を車々間通信管理サービス処理部２の管理情報格納部２４に設定し、データ受信手順が完了する。

一方、ステップＳ１１１において、受信したデータを車々間通信管理サービス処理部２に送信すると判断された場合、ステップＳ１１４では、取得したＣ２Ｃ ＳＤＵを車々間通信管理サービス処理部２に送信する。次に、ステップＳ１１３の処理を行い、データ受信手順が完了する。

なお、ステップＳ１０７およびＳ１１３の処理完了後、ステップＳ１０１へと戻り、次のメッセージの送信要求および受信通知の受信まで待機する。

＜Ａ−３−２．イベント通知サービス処理部１２の動作＞
図６１は、車々間通信転送サービス処理部１のイベント通知サービス処理部１２の動作を示すフローチャートである。

イベント通知サービス処理部１２は、エラーやイベントの発生を知らせるイベント通知を受信するまで待機する（ステップＳ２０１）。当該イベント通知を受信していない場合（「Ｎｏ」の場合）には、待機状態を継続する。これに対して、イベント通知を受信した場合（「Ｙｅｓ」の場合）には、ステップＳ２０２へと移行する。

ステップＳ２０２では、ステップＳ２０１で受信したイベント通知が車々間通信転送サービス処理部１内でのイベントか、車々間通信管理サービス処理部２から通知されたイベントかを識別し、車々間通信転送サービス処理部１のイベントの場合（「Ｙｅｓ」の場合）には、ステップＳ２０３へと移行する。これに対して、車々間通信管理サービス処理部２のイベントの場合（「Ｎｏ」の場合）には、ステップＳ２０５へと移行する。

次に、ステップＳ２０３では、発生したエラーやイベントに該当するイベントコードを設定する。

そして、ステップＳ２０４では、イベント通知プリミティブを管理サービス処理部５２に対して送信し、イベント通知処理を完了する。

一方、ステップＳ２０２において、車々間通信管理サービス処理部２からのイベント通知であると識別された場合には、車々間通信管理サービス処理部２から通知されたイベントコードを、イベント通知サービス処理部１２のイベントコードに設定する（Ｓ２０５）。

次に、ステップＳ２０４の処理を行い、イベント通知処理を完了する。なお、ステップＳ２０４の処理完了後、ステップＳ２０１へと戻り、次の処理を実行する。

＜Ａ−３−３．優先度制御サービス処理部１３の動作＞
図６２は、車々間通信転送サービス処理部１の優先度制御サービス処理部１３の動作を示すフローチャートである。

優先度制御サービス処理部１３は、送受信するデータ（メッセージ）を受信するまで待機する（ステップＳ３０１）。当該メッセージを受信していない場合（「Ｎｏ」の場合）には、データ受信の待機状態を継続する。これに対して、当該メッセージを受信した場合（「Ｙｅｓ」の場合）は、ステップＳ３０２へと移行する。

ステップＳ３０２では、ステップＳ３０１で受信したデータが送信するデータか、受信したデータかを識別し、送信するデータの場合（「Ｙｅｓ」の場合）には、ステップＳ３０３へと移行する。これに対して、受信したデータの場合（「Ｎｏ」の場合）は、ステップＳ３０６へと移行する。

次に、ステップＳ３０３では、送信するデータと同時に受け取った優先度を参照し、当該優先度の送信キューに送信データを格納する。

そして、ステップＳ３０４では、各送信キューに送信データが格納されているかを確認し、データが存在する場合（「Ｙｅｓ」の場合）には、ステップＳ３０５へと移行する。

それに対して、ステップ３０４で、送信キューにデータが存在しないことを確認した場合（「Ｎｏ」の場合）には、ステップＳ３０１へと戻り、メッセージを受信するまで待機する。

一方、ステップＳ３０５に進んだ場合、優先度制御サービス処理部１３は優先度の高い送信キューに格納されているデータから順番に受信サービス処理部６１に送信し、優先度制御処理の送信手順を完了し、ステップＳ３０１に戻って、次のメッセージの受信まで待機する。

なお、ステップＳ３０５での処理終了後は、ステップＳ３０４に戻り、キューに残ったデータがある場合には送信を繰り返し、データが存在しない場合にはステップＳ３０１へと戻り、メッセージを受信するまで待機する。

ステップＳ３０２において、優先度制御サービス処理部１３が受信サービス処理部６２からデータを受信したものと識別した場合、ステップＳ３０６では、受信したデータをデータ転送サービス処理部１１に送信し、優先度制御処理の受信手順を完了する。なお、ステップＳ３０６の処理完了後、ステップＳ３０１へと戻り、次のメッセージの受信まで待機する。

＜Ａ−３−４．輻輳制御サービス処理部２１の動作＞
図６３は、車々間通信管理サービス処理部２の輻輳制御サービス処理部２１の動作を示すフローチャートである。

輻輳制御サービス処理部２１は、輻輳制御メッセージを受信するまで待機する（ステップＳ４０１）。当該メッセージを受信していない場合（「Ｎｏ」の場合）には、ステップＳ４０７へと移行する。これに対して、当該メッセージを受信した場合（「Ｙｅｓ」の場合）には、ステップＳ４０２へと移行する。

ステップＳ４０２では、ステップＳ４０１で受信した輻輳制御メッセージから、相手局の危険度や、相手局が自局に要求する送信周期、送信電力、および受信感度などの通信制御情報を取得する。

次に、ステップＳ４０３では、ステップＳ４０２で取得した相手局の危険度と自局の危険度とを比較し、自局よりも相手局のほうが危険と判断した場合（「Ｙｅｓ」の場合）には、ステップＳ４０４へと移行する。これに対して、相手局より自局のほうが危険と判断した場合（「Ｎｏ」の場合）には、ステップＳ４０６へと移行する。

ステップＳ４０４では、ステップＳ４０２で取得した送信周期を自局のアプリケーションに設定するために、車々間通信アプリケーション部３１に通知する。

そして、ステップＳ４０５では、ステップＳ４０２で取得した送信電力や受信感度を自局の通信制御情報格納部７１に設定し、輻輳制御メッセージを受信した場合の処理手順を完了する。

一方、ステップＳ４０３において、相手局よりも自局が危険な状況にあると判断した場合、ステップＳ４０６では、ステップＳ４０１で受信した輻輳制御メッセージを破棄して、輻輳制御メッセージを受信した場合の処理手順を完了する。

また、ステップＳ４０１において、輻輳制御メッセージを受信しなかった場合、ステップＳ４０７では、輻輳を制御するための通信制御パラメータを算出するために、車々間通信アプリケーション部３１および通信制御情報格納部７１から車両情報や通信チャネル情報などを取得する。

次に、ステップＳ４０８では、輻輳制御アルゴリズムに基づき、ステップＳ４０７で取得した情報を元に、輻輳を回避するための送信周期、送信電力、および受信感度を算出する。

そして、ステップＳ４０９では、ステップＳ４０８で算出した送信周期を車々間通信アプリケーション部３１に通知する。

さらに、ステップＳ４１０では、ステップＳ４０８で算出した送信電力、受信感度を通信制御情報格納部７１に設定し、輻輳制御のための通信制御パラメータ設定手順を完了する。なお、ステップＳ４０５、Ｓ４０６、Ｓ４１０の処理完了後は、ステップＳ４０１へと戻り、次のメッセージの受信まで待機する。

＜Ａ−３−５．接続管理サービス処理部２２および再送制御サービス処理部２３の動作＞
図６４〜図６６を用いて、車々間通信管理サービス処理部２の接続管理サービス処理部２２および再送制御サービス処理部２３の動作について説明する。

図６４は、接続管理サービス処理部２２の初期接続手順の方法を決定するフローチャートであり、図６５は、ビーコンメッセージを利用した場合の初期接続手順を示すフローチャートであり、図６６は、同報アプリケーションを利用した場合の初期接続手順を示すフローチャートである。

まず、図６４を用いて、初期接続手順の方法を説明する。

接続管理サービス処理部２２は、車々間通信アプリケーション部３１からの接続要求を受信するまで待機する（ステップＳ５０１）。当該接続要求を受信していない場合（「Ｎｏ」の場合）には、ステップＳ５０７へと移行する。これに対して、当該接続要求を受信した場合（「Ｙｅｓ」の場合）には、ステップＳ５０２へと移行する。

ステップＳ５０２では、ステップＳ５０１で受信した接続要求の変数である接続要求フラグが「１」を示すか否かを判定する。そして、当該接続要求フラグが「１」を示さない場合（「Ｎｏ」の場合）は、ステップＳ５０１へ戻る。これに対して、当該接続要求フラグが「１」を示す場合（「Ｙｅｓ」の場合）は、ステップＳ５０３へと移行する。

次に、ステップＳ５０３では、周期的に情報を送信するアプリケーションが起動中であるか否かを判定する。当該アプリケーションが起動していない場合（「Ｎｏ」の場合）には、ステップＳ５０５へと移行する。これに対して、当該アプリケーションが起動している場合（「Ｙｅｓ」の場合）には、ステップＳ５０４へと移行する。

そして、ステップＳ５０４では、同報アプリケーションを利用した初期接続手順（シーケンス）を適用し、図６６に示す手順で初期接続を開始する。ここで、同報アプリケーションとは周期的に情報を送信するアプリケーションのことである。

ステップＳ５０３において、周期的に情報を送信するアプリケーションが起動していないと判定された場合、ステップＳ５０５では、ステップＳ５０１で受信した接続要求の変数ビーコンフラグが「１」を示すか否かを判定する。当該ビーコンフラグが「１」を示さない場合（「Ｎｏ」の場合）は、ステップＳ５０１へ戻る。これに対して、当該ビーコンフラグが「１」を示す場合（「Ｙｅｓ」の場合）、ステップＳ５０６へ移行し、ビーコンメッセージを利用した初期接続手順（シーケンス）を適用し、図６５に示す手順で初期接続を開始する。

一方、ステップＳ５０１において、車々間通信アプリケーション部３１から接続要求を受信しなかった場合、ステップＳ５０７で、周辺局からビーコンメッセージおよび接続要求メッセージを受信するまで待機する。そして、当該メッセージを受信しなかった場合（「Ｎｏ」の場合）は、ステップＳ５０１へ戻る。それに対して、当該メッセージを受信した場合は（「Ｙｅｓ」の場合）は、ステップＳ５０８へ移行する。

次に、ステップＳ５０８では、ステップＳ５０７で受信したメッセージを破棄し、ステップＳ５０１に戻る。

次に、図６５を用いてビーコンメッセージを利用した場合の初期接続手順について説明する。

接続管理サービス処理部２２は、ビーコンメッセージが送信されているかを確認するためビーコンスキャンを行うので、スキャンタイマを起動する（ステップＳ６０１）。

ステップＳ６０２では、接続管理サービス処理部２２は、ステップＳ６０１のスキャンタイマがタイムアウトするまでにビーコンメッセージを受信したか否かを判断する。当該ビーコンメッセージを受信しなかった場合（「Ｎｏ」の場合）は、ステップＳ６１２へ移行する。それに対して、当該ビーコンメッセージを受信した場合（「Ｙｅｓ」の場合）は、ステップＳ６０３へ移行する。

次に、ステップＳ６０３では、接続管理サービス処理部２２は、接続管理テーブルを参照し、ビーコンの送信元車両との接続状況を確認する。そして、ステップＳ６０４で相手局と接続済みと判定された場合（「Ｎｏ」の場合）は、ステップＳ６１１へ移行し、初期接続手順を完了する。それに対して、相手局と未接続と判定された場合（「Ｙｅｓ」の場合）は、ステップＳ６０５へ移行する。

そして、ステップＳ６０５では、接続管理サービス処理部２２は、ビーコンの送信元車両に対して接続要求を行うために、接続要求メッセージを生成し、接続要求メッセージを再送制御サービス処理部２３に送信する。そして、ステップＳ６０６において、再送制御サービス処理部２３は、接続要求メッセージをデータ転送サービス処理部１１に送信すると同時に再送タイマを起動する。

ステップＳ６０７では、再送制御サービス処理部２３は、再送タイマがタイムアウトするまでに接続応答メッセージを受信したか否かを判断し、当該接続応答メッセージを受信できなかった場合（「Ｎｏ」の場合）は、ステップＳ６０６に戻り、接続要求メッセージを再送する。それに対して、当該接続応答メッセージを受信した場合（「Ｙｅｓ」の場合）は、ステップＳ６０８へ移行する。

ステップＳ６０８では、再送制御サービス処理部２３は、受信したメッセージを接続管理サービス処理部２２に渡し、接続管理サービス処理部２２は接続管理テーブルを「接続済み」に更新し、相手局との初期接続を確立する。次に、ステップＳ６０９において、接続管理サービス処理部２２は確認応答メッセージを生成し、相手局に送信するためにデータ転送サービス処理部１１に渡す。そして、ステップＳ６１０で、アプリケーション処理部に接続が確立したことを通知し、初期接続手順を完了する。

一方、ステップＳ６０２で、接続管理サービス処理部２２は、ビーコンメッセージを受信せずにスキャンタイマがタイムアウトした場合、ステップＳ６１２で、接続要求メッセージを受信したか否かを判断する。そして、当該接続要求メッセージを受信できなかった場合（「Ｎｏ」の場合）は、ステップＳ６２１へ移行する。それに対して、当該接続要求メッセージを受信した場合（「Ｙｅｓ」の場合）は、ステップＳ６１３へ移行する。

ステップＳ６１３では、接続管理サービス処理部２２は接続管理テーブルを参照し、相手局との接続状況を確認する。そして、ステップＳ６１４で相手局と接続済みと判定された場合（「Ｎｏ」の場合）は、ステップＳ６２０へ移行する。それに対して、相手局と未接続と判定された場合（「Ｙｅｓ」の場合）は、ステップＳ６１５へ移行する。

そして、ステップＳ６１５では、接続管理サービス処理部２２は、接続管理テーブルを「接続済み」に更新し、相手局との初期接続を確立し、車々間通信アプリケーション３１に接続が確立したことを通知する。

次に、ステップＳ６１６では、接続管理サービス処理部２２は相手局からの接続要求に対する応答を行うために、接続応答メッセージを再送制御サービス処理部２３に送信する。

ステップＳ６１７では、再送制御サービス処理部２３は、接続応答メッセージをデータ転送サービス処理部１１に送信すると同時に再送タイマを起動する。

そして、ステップＳ６１８で、再送制御サービス処理部２３は、再送タイマがタイムアウトするまでに確認応答メッセージを受信したか否かを判断する。当該確認応答メッセージを受信できなかった場合（「Ｎｏ」の場合）は、ステップＳ６１７に戻り、接続応答メッセージを再送する。それに対して、当該確認応答メッセージを受信した場合（「Ｙｅｓ」の場合）は、ステップＳ６１９へ移行する。

ステップＳ６１９では、再送制御サービス処理部２３は、受信したメッセージを接続管理サービス処理部２２へ送信し、接続管理サービス処理部２２は初期接続手順を完了する。

なお、ステップＳ６１４において、接続管理サービス処理部２２は、相手局と接続済みだった場合には、ステップＳ６２０で、接続応答メッセージの変数リザルトコードを「接続済み」に設定し、ステップＳ６１６で接続応答メッセージを生成する。以降は、ステップＳ６１７〜Ｓ６１９の手順に従って初期接続手順を実行する。

一方、ステップＳ６１２において、接続管理サービス処理部２２は、接続要求メッセージを受信できなかった場合には、ステップＳ６２１で、ビーコンメッセージを生成する。そして、ビーコンメッセージを送信すると同時にビーコンタイマを起動する（ステップＳ６２２）。

その後、ステップＳ６２３において、接続管理サービス処理部２２は、ステップＳ６２２で起動したビーコンタイマがタイムアウトするまでに接続要求メッセージを受信できるか否かを判断する。当該メッセージを受信できなかった場合（「Ｎｏ」の場合）には、ステップＳ６２２へ戻り、ビーコンメッセージを再度送信する。それに対して、当該タイムアウトするまでに接続要求メッセージを受信した場合（「Ｙｅｓ」の場合）には、ステップＳ６１３へ移行し、ステップＳ６１３〜Ｓ６１９の手順に従って初期接続を実行する。

次に、図６６を用いて同報アプリケーションを利用した場合の初期接続手順について説明する。

接続管理サービス処理部２２は、車々間通信転送サービス処理部１が同報アプリケーションを受信したことによって、管理情報格納部２４の情報が更新されたか否かを判定する（ステップＳ７０１）。当該情報が更新されなかった場合（「Ｎｏ」の場合）には、ステップＳ７１３へ移行する。それに対して、当該情報が更新された場合（「Ｙｅｓ」の場合）には、ステップＳ７０２へ移行する。

次に、ステップＳ７０２では、接続管理サービス処理部２２は、接続管理テーブルを参照し、情報が更新された車両との接続状況を確認する。そして、ステップＳ７０３で相手局と接続済みと判定された場合（「Ｎｏ」の場合）は、ステップＳ７１１へ移行し、初期接続手順を終了する。それに対して、未接続の場合（「Ｙｅｓ」の場合）は、ステップＳ７０４へ移行する。

そして、ステップＳ７０４では、接続管理サービス処理部２２は、接続要求フラグを参照して、「１」を示すか否かを判定し、当該接続要求フラグが「１」を示していない場合（「Ｎｏ」の場合）は、ステップＳ７１２へ移行し、初期接続手順を終了する。それに対して、当該接続要求フラグが「１」を示す場合（「Ｙｅｓ」の場合）は、ステップＳ７０５へ移行する。

そして、ステップＳ７０５では、接続管理サービス処理部２２は、相手車両に対して接続要求を行うために、接続要求メッセージを生成し、接続要求メッセージを再送制御サービス処理部２３に送信する。

その後、ステップＳ７０６では、接続管理サービス処理部２２は、再送制御サービス処理部２３は、接続要求メッセージをデータ転送サービス処理部１１に送信すると同時に再送タイマを起動する。

ステップＳ７０７では、再送制御サービス処理部２３は、再送タイマがタイムアウトするまでに接続応答メッセージを受信したか否かを判断する。そして、当該接続応答メッセージを受信できなかった場合（「Ｎｏ」の場合）は、ステップＳ７０６へ戻り、接続要求メッセージを再送する。それに対して、当該接続応答メッセージを受信した場合（「Ｙｅｓ」の場合は）、ステップＳ７０８へ移行する。

ステップＳ７０８では、再送制御サービス処理部２３は受信したメッセージを接続管理サービス処理部２２に渡し、接続管理サービス処理部２２では接続管理テーブルを「接続済み」に更新し、相手局との初期接続を確立すると同時に車々間通信アプリケーション部３１に接続を通知する。

次に、ステップＳ７０９では、接続管理サービス処理部２２は確認応答メッセージを生成し、相手局に送信するためにデータ転送サービス処理部１１に渡す。そして、ステップＳ７１０で、アプリケーション処理部に接続が確立したことを通知し、初期接続手順を完了する。

一方、ステップＳ７０１で、接続管理サービス処理部２２は、管理情報格納部２４の情報が更新されなかったと判定された場合、ステップＳ７１３で、接続要求メッセージを受信できたか否かを判断し、当該接続要求メッセージを受信できなかった場合（「Ｎｏ」の場合）は、ステップＳ７０１へ戻る。それに対して、当該接続要求メッセージを受信した場合（「Ｙｅｓ」の場合）は、ステップＳ７１４へ移行する。

次に、ステップＳ７１４では、接続管理サービス処理部２２は、接続管理テーブルを参照し、相手局との接続状況を確認する。そして、ステップＳ７１５で相手局と接続済みと判定された場合（「Ｎｏ」の場合）は、ステップＳ７２１へ移行する。それに対して、未接続の場合（「Ｙｅｓ」の場合）は、ステップＳ７１６へ移行する。

そして、ステップＳ７１６では、接続管理サービス処理部２２は、接続管理テーブルを「接続済み」に更新し、相手局との初期接続を確立し、車々間通信アプリケーション３１に接続が確立したことを通知する。

次にステップＳ７１７では、接続管理サービス処理部２２は相手局からの接続要求に対する応答を行うために、接続応答メッセージを再送制御サービス処理部２３に送信する。

その後、ステップＳ７１８では、再送制御サービス処理部２３は、接続応答メッセージをデータ転送サービス処理部１１に送信すると同時に再送タイマを起動する。

ステップＳ７１９では、再送制御サービス処理部２３は、再送タイマがタイムアウトするまでに確認応答メッセージを受信したか否かを判断し、当該確認応答メッセージを受信できなかった場合（「Ｎｏ」の場合）は、ステップＳ７１８へ戻り、接続応答メッセージを再送する。それに対して、当該確認応答メッセージを受信した場合（「Ｙｅｓ」の場合）は、ステップＳ７２０へ移行し、初期接続手順を完了する。

なお、ステップＳ７１５において、再送制御サービス処理部２３は、相手局と接続済みと判定された場合は、ステップＳ７２１で、接続応答メッセージの変数リザルトコードを「接続済み」に設定し、ステップＳ７１７で接続応答メッセージを生成する。なお、以降はステップＳ７１８〜Ｓ７２０の手順に従って初期接続手順を実行する。

＜Ａ−３−６．車々間通信アプリケーション部３１の動作＞
図６７は、アプリケーション処理部３の車々間通信アプリケーション部３１の動作を示すフローチャートである。

車々間通信アプリケーション部３１は、起動後、車々間通信管理サービス処理部２の管理情報格納部２４に対して、アプリケーション情報を登録する（ステップＳ８０１）。

次に、車々間通信アプリケーション部３１はデータの送信要求またはデータの受信通知があるまで待機する（ステップＳ８０２）。当該要求および通知を受信していない場合（「Ｎｏ」の場合）は、要求および通知の受信まで待機を継続する。これに対して、当該要求および通知を受信した場合（「Ｙｅｓ」の場合）は、ステップＳ８０３へと移行する。

ステップＳ８０３では、ステップＳ８０２で受信した内容が送信要求であるか否かを判定し、送信要求の場合（「Ｙｅｓ」の場合）には、ステップＳ８０４へと移行する。これに対して、受信通知の場合（「Ｎｏ」の場合）には、ステップＳ８０６へと移行する。

次に、ステップＳ８０４では、送信要求されたデータを同報通信するか否かを判定し、同報通信の場合（「Ｙｅｓ」の場合）には、ステップＳ８０５へと移行する。これに対して、同報通信ではなく個別通信の場合（「Ｎｏ」の場合）には、ステップＳ８０７へと移行する。

そして、ステップＳ８０５では、送信するデータをトランザクション管理部４のトランザクションサービス処理部４１に送信し、アプリケーション処理部の同報通信処理手順を完了する。

一方、ステップＳ８０３において、データの受信通知を受け取ったと判定された場合、ステップＳ８０６では、車々間通信アプリケーション部３１は受信したデータを読み取り、車両情報を車々間通信管理サービス処理部２の管理情報格納部２４に設定し、アプリケーション処理部のデータ受信処理手順を完了する。

また、ステップＳ８０４において、データを個別通信する場合、ステップＳ８０７では、車々間通信アプリケーション部３１は車々間通信管理サービス処理部２の接続管理サービス処理部２２に接続要求を送信する。

次に、ステップＳ８０８では、接続管理サービス処理部２２から接続確立通知を受信したか否かを判定し、接続確立を通知した場合（「Ｙｅｓ」の場合）には、ステップＳ８０９へと以降する。これに対して、接続確立通知を受信できなかった場合（「Ｎｏ」の場合）は、ステップＳ８１０へと移行する。

ステップＳ８０９では、車々間通信アプリケーション部３１はトランザクションサービス処理部４１に送信するデータを送信し、個別通信の送信処理手順を完了する。

また、ステップＳ８１０では、車々間通信アプリケーション部３１は送信要求のあったデータを破棄し、送信処理手順を完了する。

なお、ステップＳ８０５、Ｓ８０６，Ｓ８０９およびＳ８１０の処理完了後は、Ｓ８０２以降の処理を繰り返し実行する。

＜Ａ−３−７．トランザクションサービス処理部４１の動作＞
図６８は、トランザクション管理部４のトランザクションサービス処理部４１の動作を示すフローチャートである。

トランザクションサービス処理部４１は、データの送信要求またはデータの受信通知があるまで待機する（ステップＳ９０１）。当該要求および通知を受信していない場合（「Ｎｏ」の場合）には、要求および通知の受信まで待機を継続する。これに対して、当該要求および通知を受信した場合（「Ｙｅｓ」の場合）には、ステップＳ９０２へと移行する。

ステップＳ９０２では、ステップＳ９０１で受信した内容が送信要求であるか否かを判定し、送信要求の場合（「Ｙｅｓ」の場合）には、ステップＳ９０３へと移行する。これに対して、受信通知の場合（「Ｎｏ」の場合）には、ステップＳ９０５へと移行する。

ステップＳ９０３では、トランザクションサービス処理部４１は、必要に応じて分割や再送、連送などの送信処理を行い、ステップＳ９０４で送信データにＬＰＰヘッダを付与し、転送サービス処理部５のＬＰＣＰ転送サービス処理部５１に送信する。

一方、ステップＳ９０２でデータの受信通知を受け取ったと判定された場合、ステップＳ９０５で、組み立や接続管理などの受信処理を実行する。

そして、ステップＳ９０６では、受信したデータがアプリケーションへ渡すデータか否かを判定し、アプリケーションに送信するデータの場合（「Ｙｅｓ」の場合）は、ステップＳ９０７へと移行する。これに対して、ＬＰＰ接続管理サービス処理部４２から送信した制御データを受信した場合（「Ｎｏ」の場合）は、ステップＳ９０８へと移行する。

ステップＳ９０７では、アプリケーション処理部３の車々間通信アプリケーション部３１に送信データを渡し、トランザクション管理部４のアプリケーションデータ受信処理手順を完了する。

また、ステップＳ９０８では、ＬＰＰ接続管理サービス処理部４２に制御データを渡し、トランザクション管理部３の制御データ受信処理手順を完了する。

なお、ステップＳ９０４、Ｓ９０７およびＳ９０８の処理完了後は、ステップＳ９０１以降の処理を繰り返し実行する。

＜Ａ−３−８．ＬＰＣＰ転送サービス処理部５１の動作＞
図６９は、転送サービス処理部５のＬＰＣＰ転送サービス処理部５１の動作を示すフローチャートである。

ＬＰＣＰ転送サービス処理部５１は、データの送信要求またはデータの受信通知があるまで待機する（ステップＳ１００１）。当該要求および通知を受信していない場合（「Ｎｏ」の場合）には、要求および通知の受信まで待機を継続する。これに対して、当該要求および通知を受信した場合（「Ｙｅｓ」の場合）には、ステップＳ１００２へと移行する。

ステップＳ１００２では、ステップＳ１００１で受信した内容が送信要求であるか否かを判定し、送信要求の場合（「Ｙｅｓ」の場合）には、ステップＳ１００３へと移行する。これに対して、受信通知の場合（「Ｎｏ」の場合）には、ステップＳ１００５へと移行する。

次に、ステップＳ１００３では、ＬＰＣＰ転送サービス処理部５１はローカルポート番号などのＬＰＣＰヘッダを付与し、ステップＳ１００４で転送サービス処理部５のデータ転送サービス処理部１１に送信データを渡して、転送サービス処理部５でのデータ送信処理手順を完了する。

一方、ステップＳ１００２においてデータの受信通知を受け取った場合、ステップＳ１００５において、ＬＰＣＰ転送サービス処理部５１はローカルポート番号を参照し、受信したデータの配信先を識別する。そして、ステップＳ１００６では、配信先へ受信データを送信し、転送サービス処理部５のデータ受信処理手順を完了する。

なお、ステップＳ１００４およびＳ１００６の処理完了後は、ステップＳ１００１以降の処理を繰り返し実行する。

＜Ａ−３−９．送受信サービス処理部６の動作＞
図７０は、送受信サービス処理部６の動作を示すフローチャートである。

送信サービス処理部６１および受信サービス処理部６２は、データの送信要求またはデータの受信通知があるまで待機する（ステップＳ１１０１）。当該要求および通知を受信していない場合（「Ｎｏ」の場合）には、要求および通知の受信まで待機を継続する。これに対して、当該要求および通知を受信した場合（「Ｙｅｓ」の場合）は、ステップＳ１１０２へと移行する。

ステップＳ１１０２では、Ｓ１１０１で受信した内容が送信要求であるか否かを判定し、送信要求の場合（「Ｙｅｓ」の場合）には、ステップＳ１１０３へと移行する。これに対して、受信通知の場合（「Ｎｏ」の場合）には、ステップＳ１１０５へと移行する。

次に、ステップＳ１１０３では、送信サービス処理部６１は送受信サービス管理部７の通信制御情報格納部７１から送信電力を取得し、ステップＳ１１０４では、取得した送信電力を用いて無線通信を行い、送受信サービス処理部６の送信処理手順を完了する。

一方、ステップＳ１１０２でデータの受信通知がされたと判定された場合、ステップＳ１１０５では、受信サービス処理部６２は送受信サービス管理部７の通信制御情報格納部７１から受信感度を取得する。

そして、ステップＳ１１０６では、受信したデータの電力がキャリアセンス感度以上か否かを判定し、キャリアセンス感度以上の電力を受信した場合（「Ｙｅｓ」の場合）には、ステップＳ１１０７へと移行し、キャリアセンス感度に満たない電力を受信した場合（「Ｎｏ」の場合）には、ステップＳ１１０８へと移行する。

ステップＳ１１０７では、受信サービス処理部６２が通信チャネルがビジーと判定し、通信制御情報格納部７１の通信チャネルの利用率を更新する。

そして、Ｓ１１０８では、受信サービス処理部６２は受信したデータの電力が受信感度以上あるか否かを判定し、受信感度以上の電力を受信した場合（「Ｙｅｓ」の場合）、ステップＳ１１０９へと移行する。これに対して、受信感度に満たない電力を受信した場合（「Ｎｏ」の場合）は、ステップＳ１１１０へと移行する。

ステップＳ１１０９では、受信サービス処理部６２は受信したデータを車々間通信管理サービス処理部１の優先度制御サービス処理部１３に送信し、受信処理手順を完了する。

一方、ステップＳ１１１０では、受信サービス処理部６２は受信したデータを破棄し、受信処理手順を完了する。

なお、ステップＳ１１０４、Ｓ１１０９およびＳ１１１０の処理完了後は、ステップＳ１１０１以降の処理を繰り返し実行する。

＜Ａ−４．効果＞
以上説明した、本発明に係る実施の形態１の車載通信装置および路車間−車々間通信連携システムにおいては、車々間通信転送サービス処理部１と車々間通信管理サービス処理部２は、既存の路車間通信プロトコルである転送サービス処理部（ＬＰＣＰ）に対するインタフェースを有することで、路車間通信システムを提供する車載器と車々間通信システムを提供する車載器とを共用化できる車載通信装置を得ることができ、路車間通信システムと車々間通信システムの両方にサービスを提供できる車載通信装置を得ることが可能となる。

また、車々間通信転送サービス処理部１は、アプリケーション処理部と、送受信サービス処理部との間に介在するので、複数アプリケーションの優先度に応じて通信を制御できるため優先度の高いアプリケーションの情報を優先的に送信することが可能となる。

また、車々間通信管理サービス処理部２は、アプリケーション処理部３、車々間通信転送サービス処理部１および送受信サービス管理部７に対して平行するように配置されているので、アプリケーション処理部３から受け取る各車両の車両情報および危険度、および送受信サービス管理部から取得するチャネル利用率に基づいて、自車両および周辺車両の輻輳を回避するための通信制御を行うことが可能となる。これにより、車両台数が増加した場合でも通信誤り率が改善できる。

また、車々間通信転送サービス処理部１は、車々間通信管理サービス処理部２を経由して優先度を取得できるので、既存のプロトコルであるトランザクション管理部（ローカルポートプロトコル）４や転送サービス処理部（ローカルポート制御プロトコル）５などから優先度を取得できない場合でも、優先度制御を提供することが可能になる。

また、車々間通信転送サービス処理部１は、送信するメッセージに送信電力や受信感度、および通信チャネルの利用率などの通信制御情報を付加することで、通信制御を行う際に必要な情報を効率的に収集することができる。これにより、車々間通信管理サービス処理部２が、輻輳制御を行う際に周辺車両の検出した情報に基づいて送信周期や送信電力などの通信パラメータの設定を行うことができ、効率的な輻輳制御を行うことが可能になる。

また、車々間通信管理サービス処理部２は、アプリケーション処理部３から送受信サービス管理部６に渡って平行するように配置されているので、アプリケーション処理部３や送受信サービス管理部７の情報の取得や、アプリケーション処理部３や送受信サービス管理部７への設定が可能となる。

また、車々間通信管理サービス処理部２は、通信接続管理サービスを提供するために、初期接続を行うための接続手順を規定し、接続状況を管理するので、アプリケーション処理部３が移動局に対して個別に通信を開始することが可能となる。また、送受信サービス処理部６が初期接続手順を有していない場合に、車々間通信管理サービス処理部２が初期接続の開始や通信接続の管理を行うことができる。

また、車々間通信管理サービス処理部２は、車々間通信転送サービス処理部１を経由して、アプリケーション処理部３やトランザクション管理部４に、通信接続確立の通知を行うことができる。

また、車々間通信管理サービス処理部２は、周期的にメッセージを送信するアプリケーションが動作している場合には、当該アプリケーションのメッセージを受信したことを契機に、初期接続の接続要求を相手移動局に送信することで、高速かつ効率的な初期接続を行うことが可能となる。

また、車々間通信管理サービス処理部２は、周期的にメッセージを送信するアプリケーションが動作していない場合には、周期的にメッセージを送信し、周辺の移動局がメッセージを受信することを契機に、初期接続の接続要求を相手移動局に送信することで、初期接続を開始することが可能となる。

また、車々間通信管理サービス処理部２は、初期接続を行う際に、通信チャネル上に初期接続に必要とされるメッセージが送信されているかを監視することで、無駄なメッセージの送信を回避し、通信帯域を有効に利用できる。

また、車々間通信管理サービス処理部２は、周辺移動局に対して、送信電力や受信感度、および送信チャネルなどを指示できる制御メッセージを送信することで、即座に通信帯域の利用率を抑えることや、自局の送信を優先的に行うことが可能になる。

＜Ａ−５．変形例＞
以上説明した実施の形態１では、トランザクション管理部４（ローカルポートプロトコル）と、転送サービス処理部５（ローカルポート制御プロトコル）と、車々間通信転送サービス処理部１（車々間通信トランスポートサブレイヤ）と、車々間通信管理サービス処理部２（車々間通信マネジメントレイヤ）とで構成される階層構造を示したが、ローカルポートプロトコルやローカルポート制御プロトコルの代わりに他の双方向に通信可能なプロトコルを用いても良い。

例えば、アメリカで検討されているプロトコルＩＥＥＥ１６０９．３やヨーロッパのＣＡＬＭ（Communications Architecture for Land Mobile environment）で検討されているプロトコルＦＡＳＴやＧｅｏ−Ｒｏｕｔｉｎｇなどを用いても良い。

また、車々間通信管理サービス処理部２は、アプリケーション処理部３、トランザクション管理部４、転送サービス処理部５、車々間通信転送サービス処理部１および送受信サービス管理部７に対して平行するように配置される構造を示したが、ＩＥＥＥ１６０９．３で検討されている管理部ＷＭＥ（WAVE Management Entity）やＣＡＬＭで検討されている管理部ＣＭＥ（CALM Management Entity）も車々間通信管理サービス処理部２と同じように配置されるため、車々間通信管理サービス処理部２をＷＭＥやＣＭＥに含める構成やＷＭＥやＣＭＥを含む構成を用いても良い。ここで、ＷＡＶＥはWireless Access in Vehicular Environmentsの略語である。

また、車々間通信管理サービス処理部２がＷＭＥに含まれる場合、アプリケーション処理部３や送受信サービス管理部７とのインタフェースは、ＷＭＥとアプリケーション間およびＷＭＥとＭＬＭＥ／ＰＬＭＥ間のインタフェースに置き換えたり、追加しても良い。また、車々間通信転送サービス部１と車々間通信管理サービス処理部２とのインタフェースは、ＣＭＥとＦＡＳＴとのインタフェースに統合しても良い。

また、アプリケーション処理部３は、車々間通信システムのアプリケーションに限らず、路車間通信システムのアプリケーションやＩＴＳに関するアプリケーション以外のアプリケーションなどを用いても良い。

また、車々間通信管理サービス処理部２は、輻輳を回避するために設定する通信パラメータとして送信周期、送信電力、および受信感度に限らず、送信チャネルや送受信アンテナの指向性、および送信する周波数帯域などを用いても良い。

＜Ｂ．実施の形態２＞
＜Ｂ−１．プロトコル構成＞
本発明に係る実施の形態２について、図７１および図７２を用いて説明する。

図７１は本発明に係る実施の形態２の車載通信装置１０１および路車間−車々間通信連携システムのプロトコル構成を示すブロック図であり、図７２は車載通信装置１０１および路車間−車々間通信連携システムのプロトコル構成を詳細に示すブロック図である。なお、実施の形態１と同一の部位には同一の符号を付し、重複する詳細な説明は省略する。

図７１および図７２に示すように、実施の形態２の車載通信装置１０１は、車々間通信転送サービス処理部１、車々間通信管理サービス処理部２、アプリケーション処理部３、送受信サービス処理部６および送受信サービス管理部７を有している。

従って、実施の形態２の車載通信装置１０１および路車間−車々間通信連携システムにおいては、図１に示した車載通信装置１００における既存の路車間通信プロトコルであるトランザクション管理部４および転送サービス処理部５に代えて、路車間−車々間通信連携サービス処理部８を有し、アプリケーション処理部３に路車間通信アプリケーション部３２を有する点が実施の形態１に示す車載通信装置１００および路車間−車々間通信連携システムと異なる点である。

そして、実施の形態２の車載通信装置１０１では、実施の形態１と同様にアプリケーション処理部３には車々間通信アプリケーション部３１を備えているため、車々間通信のアプリケーションを提供可能である。

さらに車載通信装置１０１では路車間通信アプリケーション部３２と路車間−車々間通信連携サービス処理部８とを備えているため、路車間通信のアプリケーションを提供することも可能となる。

図７２に示すように、路車間−車々間通信連携サービス処理部８は、実施の形態１に示すトランザクション管理部４および転送サービス処理部５と同等の機能を有しており、トランザクションサービス処理部４１、ＬＰＰ接続管理サービス処理部４２、ＬＰＣＰ転送サービス処理部５１および管理サービス処理部５２を有している。

＜Ｂ−２．車載通信装置１０１の動作＞
車載通信装置１０１においては、路車間通信アプリケーション部３２が送信するデータは、路車間−車々間通信連携サービス処理部８のトランザクションサービス処理部４１およびＬＰＣＰ転送サービス処理部５１を経由して、送受信サービス処理部６から相手局へ送信され、車々間通信アプリケーション部３１が送信するデータとは異なり、車々間通信転送サービス処理部１のデータ転送サービス処理部１１を経由しない。

また、送受信サービス処理部６は、周辺局からデータを受信した場合、送信サービス処理部６が付与したヘッダ情報を参照し、路車間−車々間通信連携サービス処理部８に送信するか、車々間通信転送サービス処理部１に送信するかを判別する。これにより、路車間通信のアプリケーションは路車間−車々間通信連携サービス処理部８を経由して路車間通信アプリケーション部３２へ送信され、車々間通信のアプリケーションは車々間通信転送サービス処理部１、路車間−車々間通信連携サービス処理部８を経由して車々間通信アプリケーション部３１へ送信される。

＜Ｂ−３．効果＞
以上説明したように、実施の形態２の車載通信装置１０１は、路車間−車々間通信連携サービス処理部８を備えることによって、路車間通信のデータは車々間通信転送サービス処理部１を経由せずに相手局に送信でき、車々間通信のデータは車々間通信転送サービス処理部１を経由して、必要な制御を行って周辺局に送信することができる。これにより、路車間通信の車載器と車々間通信の車載器を共用化することができる。

＜Ｂ−４．変形例＞
なお、実施の形態２では、路車間−車々間通信連携サービス処理部８と、車々間通信転送サービス処理部１と、車々間通信管理サービス処理部２とで構成される階層構造を示したが、路車間−車々間通信連携サービス処理部８には、実施の形態１と同様にローカルポートプロトコルやローカルポート制御プロトコルなどの既存のプロトコルを用いても良い。

＜Ｃ．実施の形態３＞
＜Ｃ−１．プロトコル構成＞
本発明に係る実施の形態３について、図７３および図７４を用いて説明する。

図７３は本発明に係る実施の形態２の車載通信装置１０２および路車間−車々間通信連携システムのプロトコル構成を詳細に示すブロック図である。なお、実施の形態１および実施の形態２と同一の部位には同一の符号を付し、重複する詳細な説明は省略する。

図７３に示すように、車載通信装置１０２は、図１を用いて説明した実施の形態１の車載通信装置１００とほぼ同じ構成であるが、アプリケーション処理部３において、路車間通信アプリケーション部３２を有する点が実施の形態１の車載通信装置１０１と異なる点である。

＜Ｃ−２．車載通信装置１０２の動作＞
路車間通信アプリケーション部３２が送信するデータは、実施の形態１の車載通信装置１００と同様にトランザクション処理部４、転送サービス処理部５を経由して、車々間通信転送サービス処理部１に渡される。

車々間通信転送サービス処理部１は、転送サービス処理部５から受信したＣ２Ｃ ＳＤＵからＬＰＣＰヘッダのポート番号を参照し、図６０のステップＳ１０５において優先度を取得する際に、同時にアプリケーションの種類を取得し、路車間通信アプリケーションか、車々間通信アプリケーションかを識別する。

取得したアプリケーションの種類が、車々間通信アプリケーションの場合には実施の形態１に記載の送受信手順を適用してメッセージの送受信を行うが、路車間通信アプリケーションの場合には図３８に示すＣ２Ｃヘッダの代わりに図７４に示すＣ２Ｃヘッダを付与して、優先度制御サービス処理部１３を経由せずに、送受信サービス処理部６に渡し、メッセージの送信を行う。この際、送信サービス処理部６１が送信する送信電力は路車間通信用の値を定義しておき、その値を適用しても良いし、車々間通信管理サービス処理部２が路車間通信に適した送信電力を算出しても良い。また、路車間通信アプリケーション部３２の情報を送信する場合には、輻輳制御サービスや接続管理サービスは提供しなくても良い。

車々間通信管理サービス処理部２は、前記路車間通信アプリケーション部３２の情報を送信する前に、路車間通信アプリケーション部３２からアプリケーション通知プリミティブやアプリケーション登録プリミティブにより、輻輳制御メッセージを送信し、周辺局の車々間通信アプリケーション部３１の送信周期を長くしたり、送信電力を低くしたりすることができる。

車々間通信転送サービス処理部１は、前記送信データを受信サービス処理部６２から受信した場合には、Ｃ２Ｃヘッダを参照し、データ識別子とＰＤＵ識別子から転送先および受信処理を識別する。データ識別子が「０」、ＰＤＵ識別子が「０」を示す場合には実施の形態１と同様の手順で処理を行い、データ識別子が「０」、ＰＤＵ識別子が「１」を示す場合には、データ本体部分を取り出し、転送サービス処理部５に渡して受信処理を完了する。この際、受信サービス処理部６２が設定する受信感度は路車間通信用の値を定義しておき、その値を適用しても良いし、車々間通信管理サービス処理部２が路車間通信に適した受信感度を算出しても良い。

車々間通信転送サービス処理部１は、前記路車間通信アプリケーション部３２のデータを受信した場合、車々間通信管理サービス処理部２に対してイベント通知プリミティブを発行し、自局の周辺に路側機が存在することを通知する。これにより、車々間通信管理サービス処理部２は、車々間通信アプリケーション部３１のデータを送信する際の送信電力を輻輳制御サービスにより設定される値よりも小さめに設定したり、送信周期は長めに設定したりする。

＜Ｃ−３．効果＞
以上説明したように、実施の形態３の車載通信装置１０２は、実施の形態１の車載通信装置１００と同様に、アプリケーション処理部３は車々間通信アプリケーション部３１を備えているため、車々間通信のアプリケーションを提供可能である。さらに車載通信装置１０２は路車間通信アプリケーション部３２を備えているため、路車間通信のアプリケーションを提供することも可能となる。

また、車々間通信転送サービス処理部１が、路車間通信アプリケーションと車々間通信アプリケーションによって、送受信手順を使い分けるため、路車間通信アプリケーションデータの場合は最小限のヘッダ情報を付加し、データ本体を透過させることができる。これにより、車載通信装置１０２は既存の路車間通信システムの動作に対しては影響を与えず、車々間通信システムにのみ各種制御サービスを提供できる。

また、車々間通信管理サービス処理部２が、路車間通信アプリケーションの送信を優先的に行うために、輻輳制御メッセージにより周辺局の車々間通信アプリケーションの送信電力および送信周期を制御できる。これにより、路車間通信アプリケーションの通信信頼性を向上させることができる。

また、車々間通信転送サービス処理部１が、路車間通信アプリケーションの有無を車々間通信管理サービス処理部２に通知することによって、路車間通信アプリケーションを優先的に送受信させるために、車々間通信アプリケーションの送信電力を抑えたり、送信周期を長くしたりさせることができる。これにより、路車間通信アプリケーションの通信信頼性を向上させることができる。

＜Ｄ．実施の形態４＞
＜Ｄ−１．プロトコル構成＞
本発明に係る実施の形態４について、図７５〜図７７を用いて説明する。なお、実施の形態１と同一の部位には同一の符号を付し、重複する詳細な説明は省略する。

図７５は本発明に係る実施の形態４の車載通信装置１０３の構成を示すブロック図である。図７５に示すように、車載通信装置１０３は図１を用いて説明した実施の形態１の車載通信装置１００とほぼ同じ構成であるが、トランザクション管理部４と転送サービス処理部５がＷＡＶＥ（Wireless Access in Vehicular Environments）転送部９に置き換わっている点と、車々間通信管理サービス処理部２がＷＡＶＥ管理部１０に含まれている点で、実施の形態１の車載通信装置１００と異なっている。

ＷＡＶＥ転送部９は、ＩＥＥＥ１６０９．３内のＷＳＭＰ（WAVE Short Message Protocol）と呼ばれるプロトコルであり、アプリケーション処理部３の要求に従ってデータを送信するサービスの提供や、受信したデータをアプリケーション処理部３に通知するサービスの提供を行う。

ＷＡＶＥ管理部１０は、ＩＥＥＥ１６０９．３内のＷＭＥと呼ばれる管理機能であり、アプリケーション処理部３の要求に応じて接続管理サービスを提供したり、アプリケーションに対してＷＭＥの管理するデータの設定／取得を行う情報アクセスサービスを提供する。

実施の形態１の図３の構成では、日本の路車間通信規格であるトランザクション管理部４（ＬＰＰ）と、転送サービス処理部５（ＬＰＣＰ）とで構成される階層構造を示したが、図７５に示すように実施の形態４の構成ではアメリカの路車間通信および車々間通信規格であるプロトコルＩＥＥＥ１６０９．３のＷＳＭＰを利用した構成である。

また、実施の形態１の図３の構成の車々間通信管理サービス処理部２は、ＩＥＥＥ１６０９．３の管理部ＷＭＥと同じように配置されているため、実施の形態４の図７５の構成の車々間通信管理サービス処理部２はＷＭＥに含まれた構成となる。

実施の形態４の送受信サービス処理部６は、ＩＥＥＥ８０２．１１ｐとＩＥＥＥ１６０９．４を想定し、周辺局に搭載された車載通信装置１０３と無線通信を行ったり、無線通信を行う周波数チャネルを切り替えたりする。

実施の形態４の車々間通信転送サービス処理部１はＷＡＶＥ転送部９と送受信サービス処理部６との間に存在し、ＷＡＶＥ転送部９やＷＡＶＥ管理部１０に対してデータ転送サービスおよび優先度制御サービスを提供する。さらに、ＷＡＶＥ管理サービス処理部１０に対して、イベント通知サービスを提供する。

実施の形態４の車々間通信管理サービス処理部２は、ＷＡＶＥ管理部１０の内部にＷＡＶＥ管理部１０の一つの機能として存在し、アプリケーション処理部３や車々間通信転送サービス処理部１に対して、輻輳制御サービス、接続管理サービス、およびデータ再送サービスを提供する。また、ＷＡＶＥ管理部１０は送受信サービス管理部７の機能を拡張する。

＜Ｄ−２．サービスインタフェース（ＳＡＰ）＞
図７６は本発明に係る実施の形態４の車々間通信アーキテクチャのプロトコル構成におけるＳＡＰの位置を示した図である。図７６におけるサービスインタフェースのうち、実施の形態１と異なるＳＡＰの一覧を図７７に示す。実施の形態１と同じＳＡＰについては図１８に示したＳＡＰと同等の機能であるため、重複する説明は省略する。また、図７７に示すＳＡＰのパラメータの説明については、ＩＥＥＥの標準規格に開示されており、当業者であれば当該規格を参照することで理解できるので、説明を省略する。

実施の形態１で示した図１８のＣＭＣＴＬ ＳＡＰ、ＭＬＭＥ ＳＡＰ、ＰＬＭＥ ＳＡＰは、実施の形態４と同じＳＡＰであるためそのまま利用することが可能であるが、図１８のＡＣＭＬ ＳＡＰおよびＡＣＴＬ ＳＡＰは、実施の形態４のＳＡＰとは異なるため、実施の形態１をそのまま適用することができない。そこで、図７６に示される構成の場合、実施の形態４ではＷＳＭＰやＷＭＥが提供するインタフェースに合わせるために、ＡＣＭＬ ＳＡＰはＷＭＥ ＳＡＰに置換し、ＡＣＴＬ ＳＡＰはＬＳＡＰに置換している。

＜Ｄ−２−１．アプリケーションとＷＭＥとのＳＡＰ（ＷＭＥ ＳＡＰ）＞
ＷＭＥはアプリケーションに対して、図７７に示すように次の６種類のプリミティブを提供する。
（１）接続要求プリミティブ（ＷＭＥ-Application）
実施の形態１のＡＣＭＬ-Connectプリミティブと同等の機能、パラメータを提供する。ＷＭＥ-Applicationプリミティブはアプリケーションが周辺局との接続を要求したり、切断するプリミティブである。
（２）アプリケーション通知プリミティブ（ＷＭＥ-Notification）
実施の形態１のＡＣＭＬ-Notifyプリミティブと同等の機能、パラメータを提供する。ＷＭＥ-Notificationは周辺局との接続状態に変化があった場合に、ＷＡＶＥ管理部１０からアプリケーション処理部３に対して通知するプリミティブである。
（３）アプリケーション情報登録プリミティブ（ＷＭＥ-ApplicationRegistration）
実施の形態１のＡＣＭＬ-RegistrationプリミティブおよびＡＣＭＬ-Deregistrationプリミティブと同等の機能、パラメータを提供する。ＷＭＥ-ApplicationRegistrationプリミティブは、アプリケーション情報の登録や削除を行うプリミティブである。
（４）ＷＭＥ情報取得プリミティブ（ＷＭＥ-Get）
実施の形態１のＡＣＭＬ-Getプリミティブと同等の機能、パラメータを提供する。ＷＭＥ-Getプリミティブは、アプリケーションがＷＭＥの管理する情報を取得するためのプリミティブである。
（５）ＷＭＥ情報設定プリミティブ（ＷＭＥ-Set）
実施の形態１のＡＣＭＬ-Setプリミティブと同等の機能、パラメータを提供する。ＷＭＥ-Setプリミティブは、アプリケーションがＷＭＥの管理する情報を設定するためのプリミティブである。
（６）受信電力要求プリミティブ（ＷＭＥ-RCPIREQUEST）
実施の形態１ではサポートしていないプリミティブである。ＷＭＥ-RCPIREQUESTプリミティブは、アプリケーションが特定の車両に対して、受信電力を測定するためのデータ送信を要求するプリミティブである。

＜Ｄ−２−２．ＣＴＬとＷＳＭＰとのＳＡＰ（ＬＳＡＰ）＞
ＣＴＬはＷＳＭＰに対して、図７７に示すように次の１種類のプリミティブを提供する。また、ＬＳＡＰはデータリンク層がＡＣＴＬに提供するプリミティブでもあるため、ＣＴＬを挿入してもＩＥＥＥ１６０９．３の通信には影響を与えない。
（１）データ転送プリミティブ（ＵＬ-ＵＮＩＴＤＡＴＡ）
実施の形態１のSendDataプリミティブと同等の機能、パラメータを提供する。ＵＬ-ＵＮＩＴＤＡＴＡプリミティブは、ＷＳＭＰがＣＴＬに対して、データ送受信を行うためのプリミティブである。

以上のように、ＳＡＰの名前は実施の形態１と異なるが、図７７に示すＳＡＰに置き換えることにより、ＩＥＥＥ１６０９．３を利用した場合でも、本発明のＣＴＬおよびＣＭＬが提供するデータ転送サービス、イベント通知サービス、優先度制御サービス、輻輳制御サービス、接続管理サービス、およびデータ再送サービスを提供することが可能となる。

＜Ｄ−３．車載通信装置１０３の動作＞
アプリケーション処理部３がデータを送信する場合、送信するデータはＷＡＶＥ転送部８に渡す。

ＷＡＶＥ転送部８は、アプリケーション処理部３から渡されたデータに、アプリケーションの種類、提供可能なアプリケーションリスト、利用可能な周波数チャネル情報などを含むＷＳＭヘッダを付与して、車々間通信転送サービス処理部１に渡す。

車々間通信転送サービス処理部１は、ＷＳＭヘッダからアプリケーションの種類を取得し、該当するアプリケーションの優先度を車々間通信管理サービス処理部２およびＷＡＶＥ管理部１０から取得する。車々間通信転送サービス処理部１はＣ２Ｃヘッダを付与した後、優先度制御サービス処理部に渡して優先度制御を行い、送受信サービス処理部６を経由してデータを周辺局に送信する。

車々間通信転送サービス処理部１内でエラーやイベントが発生した場合、ＣＭＣＴＬ-EventReportプリミティブを用いて、車々間通信管理サービス処理部２を経由して、アプリケーション処理部３にイベント情報を通知する。

アプリケーション処理部３が初期接続を要求する場合、ＷＡＶＥ管理部１０の提供するＷＭＥ-Applicationプリミティブを利用して、接続管理サービスを実施する。

また、ＷＭＥ-Applicationプリミティブに初期接続の種類を選択するパラメータを追加した場合には、ＷＡＶＥ管理部１０の機能を用いて初期接続を行うこともできるし、車々間通信管理サービス処理部２の機能を用いて初期接続を行うこともできる。

アプリケーション処理部３は、提供可能な状態になったアプリケーションの情報を、ＷＭＥ-ApplicationRegistrationプリミティブを用いてＷＡＶＥ管理部１０に登録し、提供不可能な状態になった場合は同プリミティブを用いてＷＡＶＥ管理部１０から削除する。

＜Ｄ−４．効果＞
以上説明したように、実施の形態４のプロトコル構成を有する車載通信装置１０３は、ＷＡＶＥ転送部９およびＷＡＶＥ管理部１０を備えることにより、ＩＥＥＥのプロトコルを用いた場合の車載通信装置においても、実施の形態１のプロトコル構成の車載通信装置１００と同様に、路車間通信システムと車々間通信システムの両方にサービスを提供できる車載通信装置を得ることが可能となる。

また、ＩＥＥＥプロトコルを用いた車載装置に車々間通信転送サービス処理部１および車々間通信管理サービス処理部２を備えることにより、ＩＥＥＥプロトコルでは提供できなかった輻輳制御サービスを実現することができる。

＜Ｅ．実施の形態５＞
＜Ｅ−１．プロトコル構成＞
本発明に係る実施の形態５について、図７８〜図８０を用いて説明する。なお、実施の形態１と同一の部位には同一の符号を付し、重複する詳細な説明は省略する。

図７８は本発明に係る実施の形態５の車載通信装置１０４の構成を示すブロック図である。図７８に示すように、車載通信装置１０４は図１を用いて説明した実施の形態１の車載通信装置１００とほぼ同じ構成であるが、トランザクション管理部４と転送サービス処理部５が、ＣＡＬＭ（Communication Access for Land Mobiles）転送部１１１に置き換わっている点と、車々間通信管理サービス処理部２がＣＡＬＭ管理部１１２に含まれている点が、実施の形態１の車載通信装置１００と異なっている。

ＣＡＬＭ転送部１１１は、ＣＡＬＭのＦＡＳＴ、Ｇｅｏ-Routing、およびＬＰＴＰ（Local Port Transport Protocol）と呼ばれるプロトコルで構成されており、アプリケーション処理部３の要求に従ってデータを送信するサービスを提供したり、宛先車両までデータを届ける経路探索サービスを提供する。

ＣＡＬＭ管理部１１２は、ＣＡＬＭのＣＭＥ（CALM Management Entity）と呼ばれる管理層であり、アプリケーション処理部３の要求に応じて接続管理サービスを提供したり、アプリケーションに対してＣＭＥの管理するデータの設定／取得を行う情報アクセスサービスを提供する。

実施の形態１の図３に示した構成では、日本の路車間通信規格であるトランザクション管理部４（ＬＰＰ）と、転送サービス処理部５（ＬＰＣＰ）とで構成される階層構造を示したが、図７８に示すように、実施の形態５の構成ではヨーロッパで検討されている路車間通信および車々間通信規格であるＣＡＬＭのプロトコルのネットワーク層、トランスポート層、および管理層を利用した構成である。

また、実施の形態１の図３の構成の車々間通信管理サービス処理部２は、ＣＡＬＭの管理部ＣＭＥと同じように配置されているため、実施の形態５の図７８の構成では、車々間通信管理サービス処理部２をＣＭＥに含めている。

実施の形態５の送受信サービス処理部６は、ＩＥＥＥ８０２．１１ｐや無線ＬＡＮなどを想定し、周辺局に搭載された車載通信装置１０４と無線通信を行う。

また、実施の形態５の送受信サービス管理部７は、ＣＡＬＭのＩＭＥ（Interface Management Entity）と呼ばれる管理層を利用する。

また、実施の形態５の車々間通信転送サービス処理部１は、ＣＡＬＭ転送部１１１と送受信サービス処理部６との間に存在し、ＣＡＬＭ転送部１１１やＣＡＬＭ管理部１１２に対してデータ転送サービスおよび優先度制御サービスを提供する。さらに、ＣＡＬＭ管理部１１２に対して、イベント通知サービスを提供する。

また、実施の形態５の車々間通信管理サービス処理部２は、ＣＡＬＭ管理部１１２の内部に存在し、アプリケーション処理部３や車々間通信転送サービス処理部１に対して、輻輳制御サービス、接続管理サービス、およびデータ再送サービスを提供する。また、ＣＡＬＭ管理部１１２は送受信サービス管理部７の機能を拡張する。

＜Ｅ−２．サービスインタフェース（ＳＡＰ）＞
図７９は本発明に係る実施の形態５の車々間通信アーキテクチャのプロトコル構成におけるＳＡＰの位置を示した図である。図７９におけるサービスインタフェースのうち、実施の形態１と異なるＳＡＰの一覧を図８０に示す。実施の形態１と同じＳＡＰについては図１８に示したＳＡＰと同等の機能であるため、重複する説明は省略する。

また、図８０に示すＳＡＰのパラメータは、ＣＡＬＭのプロトコル、ＩＥＥＥのプロトコルの双方において規格が成立していないが、ドラフト段階の概要を知ることはでき、それによれば、両プロトコルともに、本願発明と同種のＳＡＰパラメータを有するため、規格が未確定でも本願発明の適用は可能である。

例えば、Ａ-Command（またはＡ-Request）を用いる場合、ＳＡＰパラメータとしてCommandNoとCommandValue（RequestNoとRequestValue）を指定するのに対し、本願では、コマンドやリクエストごとに、ＡＣＭＬ-Connect、ＡＣＭＬ-Notify、ＡＣＭＬ-Registration、ＡＣＭＬ-Deregistrationを規定することで対応するものとしている。

また、本願では、ＡＣＭＬ-SetおよびＡＣＭＬ-Getに対して、それぞれmibIndexおよびmibParameterを指定してデータの設定および取得を行うのに対して、Ａ-SetParamおよびＡ-GetParamに対しては、ParamNoおよびParamValueに置き換えて実現することを想定しているので、規格が未確定でも対応することが可能である。以下、具体的に説明する。

実施の形態１で示した図１８のＣＭＣＴＬ ＳＡＰは、実施の形態５と同じＳＡＰであるためそのまま利用することが可能であるが、図１８のＡＣＭＬ ＳＡＰ、ＣＴＬ ＳＡＰ、ＭＬＭＥ ＳＡＰ、およびＰＬＭＥ ＳＡＰは、実施の形態５とＳＡＰが異なるため、実施の形態１をそのまま適用することができない。そこで、図７９に示されるプロトコル構成の場合、ＣＡＬＭネットワーク層／トランスポート層およびＣＭＥが提供するインタフェースに合わせるために、ＡＣＭＬ ＳＡＰはＡ−ＳＡＰに置換し、ＣＴＬ ＳＡＰはＣ−ＳＡＰに置換し、ＰＬＭＥ ＳＡＰとＰＬＭＥ ＳＡＰはＭ−ＳＡＰに置換している。

＜Ｅ−２−１．アプリケーションとＣＭＥとのＳＡＰ（Ａ−ＳＡＰ）＞
ＣＭＥはアプリケーションに対して、図８０に示すように次の４種類のプリミティブを提供する。
（１）コマンド実行プリミティブ（Ａ-Command）
実施の形態１のＡＣＭＬ-Connect、ＡＣＭＬ-Notify、ＡＣＭＬ-Registration、ＡＣＭＬ-Deregistrationの各プリミティブと同等の機能、パラメータを提供し、各種コマンドの実行をＣＡＬＭ転送部１１１およびＣＡＬＭ管理部１１２に対して要求する。
（２）リクエスト実行プリミティブ（Ａ-Request）
実施の形態１のＡＣＭＬ-Connect、ＡＣＭＬ-Notify、ＡＣＭＬ-Registration、ＡＣＭＬ-Deregistrationの各プリミティブと同等の機能、パラメータを提供し、各種リクエストの実行をＣＡＬＭ転送部１１１およびＣＡＬＭ管理部１１２に対して要求する。
（３）ＣＭＥ情報取得プリミティブ（Ａ-GetParam）
実施の形態１のＡＣＭＬ-Getプリミティブと同等の機能、パラメータを提供し、ＣＭＥの有する情報を取得するプリミティブである。
（４）ＣＭＥ情報設定プリミティブ（Ａ-SetParam）
実施の形態１のＡＣＭＬ-Setプリミティブと同等の機能、パラメータを提供し、ＣＭＥに対して情報を設定するプリミティブである。

＜Ｅ−２−２．ＣＴＬとＣＡＬＭネットワーク層／トランスポート層とのＳＡＰ（Ｃ−ＳＡＰ）＞
ＣＴＬはＣＡＬＭ転送部１１１に対して、図８０に示すように次の１種類のプリミティブを提供する。また、Ｃ−ＳＡＰはデータリンク層がＣＡＬＭ転送部１１１に提供するプリミティブでもあるため、ＣＴＬを挿入してもＣＡＬＭ転送部１１１の通信には影響を与えない。
（１）データ転送プリミティブ（ＵＬ-ＵＮＩＴＤＡＴＡ）
実施の形態１のSendDataプリミティブと同等の機能、パラメータを提供する。ＵＬ-ＵＮＩＴＤＡＴＡプリミティブは、ＣＡＬＭ転送部１１１がＣＴＬに対して、データ送受信を行うためのプリミティブである。

＜Ｅ−２−３．ＣＭＥとＩＭＥとのＳＡＰ（Ｍ−ＳＡＰ）＞
ＣＭＥはＩＭＥに対して、図８０に示すように次の２種類のプリミティブを提供する。
（１）ＩＭＥ情報取得プリミティブ（ＣＩＭＡＥ-SetParam）
実施の形態１のＭＬＭＥ-SetおよびＰＬＭＥ-Setプリミティブと同等の機能、パラメータを提供し、ＩＭＥの有する情報を取得するプリミティブである。
（２）ＩＭＥ情報設定プリミティブ（ＣＩＭＡＥ-GetParam）
実施の形態１のＭＬＭＥ-GetプリミティブおよびＰＬＭＥ-Getプリミティブと同等の機能、パラメータを提供し、ＩＭＥに対して情報を設定するプリミティブである。

以上のように、ＳＡＰの名前は実施の形態１と異なるが、図８０に示すＳＡＰを用いることにより、ＣＡＬＭ転送部１１１およびＣＡＬＭ管理部１１２を利用した場合でも、本発明のＣＴＬおよびＣＭＬが提供する機能を実現することが可能となる。

＜Ｅ−３．車載通信装置１０４の動作＞
アプリケーション処理部３がデータを送信する場合、送信するデータはＣＡＬＭ転送部１１１に渡され、ＣＡＬＭ転送部１１１はアプリケーションの種類、提供可能なアプリケーションリスト、利用可能な通信メディア情報などを含むＣＡＬＭヘッダを付与して、車々間通信転送サービス処理部１に渡す。

車々間通信転送サービス処理部１は、ＣＡＬＭヘッダからアプリケーションの種類を取得し、該当するアプリケーションの優先度を車々間通信管理サービス処理部２およびＣＡＬＭ管理部１１２から取得する。車々間通信転送サービス処理部１はＣ２Ｃヘッダを付与した後、優先度制御サービス処理部に渡して優先度制御を行い、送受信サービス処理部６からデータを送信する。

車々間通信転送サービス処理部１内でエラーやイベントが発生した場合、ＣＭＣＴＬ-EventReportプリミティブを用いて、車々間通信管理サービス処理部２を経由して、アプリケーション処理部３にイベント情報を通知する。

アプリケーション処理部３が初期接続を要求する場合、ＣＡＬＭ管理部１１２の提供するＡ-CommandプリミティブやＡ-Requestプリミティブを利用して、接続管理サービスを実施する。

また、Ａ-CommandプリミティブやＡ-Requestプリミティブに初期接続の種類を選択するパラメータを追加した場合には、ＣＡＬＭ管理部１１２の機能を用いて初期接続を行うこともできるし、車々間通信管理サービス処理部２の機能を用いて初期接続を行うこともできる。

アプリケーション処理部３は、提供可能な状態になったアプリケーションの情報を、Ａ-SetParamプリミティブを用いてＣＡＬＭ管理部１１２に登録し、提供不可能な状態になった場合は同プリミティブを用いてＣＡＬＭ管理部１１２から削除する。

＜Ｅ−４．効果＞
以上説明したように、実施の形態５のプロトコル構成を有する車載通信装置１０４は、ＣＡＬＭ転送部１１１およびＣＡＬＭ管理部１１２を備えることにより、ＣＡＬＭのプロトコルを用いた場合の車載通信装置においても、実施の形態１のプロトコル構成の車載通信装置１００と同様に、路車間通信システムと車々間通信システムの両方にサービスを提供できる車載通信装置を得ることが可能となる。

また、ＣＡＬＭプロトコルを用いた車載装置に車々間通信転送サービス処理部１および車々間通信管理サービス処理部２を備えることにより、ＣＡＬＭプロトコルでは提供できなかった輻輳制御サービスを実現することができる。

この発明は詳細に説明されたが、上記した説明は、すべての局面において、例示であって、この発明がそれに限定されるものではない。例示されていない無数の変形例が、この発明の範囲から外れることなく想定され得るものと解される。

Claims (12)

1. 移動局および基地局にそれぞれ搭載され、無線通信により前記移動局間および前記移動局と前記基地局との間で相互に受信側および送信側となる車載通信装置であって、
   前記車載通信装置は、
   前記受信側の前記車載通信装置に周期的にメッセージを送信するアプリケーション処理部と、
   前記アプリケーション処理部に接続され、前記アプリケーション処理部から受信した前記メッセージの再送や分割／組み立てを含むトランザクションサービスを少なくとも提供するトランザクション管理部と、
   前記トランザクション管理部に接続され、前記トランザクション管理部から受信した前記メッセージに、前記アプリケーション処理部を含む上位プロトコルを識別するためのローカルポート番号を付加する転送サービス処理部と、
   前記転送サービス処理部に接続され、前記転送サービス処理部から受信した前記メッセージを、前記アプリケーション処理部で処理されるアプリケーションの優先度順に前記受信側の前記車載通信装置に対して送信し、前記転送サービス処理部に対する前記メッセージを送受信し、エラー情報を含むイベント情報を通知する車々間通信転送サービス処理部と、
   前記車々間通信転送サービス処理部に接続され、前記車々間通信転送サービス処理部から受信した前記メッセージを、無線通信により前記受信側の前記車載通信装置との間で送受信する送受信サービス処理部と、
   前記アプリケーション処理部および前記車々間通信転送サービス処理部に接続され、前記アプリケーション処理部から前記優先度を設定され、前記車々間通信転送サービス処理部からの要求に応じて前記優先度を通知する車々間通信管理サービス処理部とを備え、
   前記トランザクション管理部および前記転送サービス処理部は、前記移動局と前記基地局との間での路車間通信を行うための路車間通信プロトコルを構成し、
   前記車々間通信転送サービス処理部は、前記受信側の前記車載通信装置に対して前記車々間通信管理サービス処理部の有する通信制御情報を通知し、
   前記受信側の前記車載通信装置は、
   前記車々間通信転送サービス処理部において、受信した前記メッセージに付与された前記通信制御情報を前記車々間通信管理サービス処理部に送信し、受信した前記メッセージは前記転送サービス処理部に送信される、車載通信装置。
2. 前記送受信サービス処理部が、前記メッセージを送受信する際の送信電力、受信感度および通信チャネルの利用率を少なくとも含む前記通信制御情報を管理する送受信サービス管理部をさらに備え、
   前記車々間通信管理サービス処理部は、
   前記送受信サービス管理部との間に設けられ、前記送受信サービス管理部からの前記通信チャネルの利用率の取得、前記送受信サービス管理部に対する前記送信電力および前記受信感度の設定のための第１のインタフェースと、
   前記車々間通信転送サービス処理部との間に設けられ、前記通信制御情報を前記車々間通信転送サービス処理部に与える第２のインタフェースと、
   前記アプリケーション処理部との間に設けられ、周期的に送信される前記メッセージの送信周期を設定するための第３のインタフェースと、を有し、
   前記アプリケーション処理部は前記車々間通信管理サービス処理部を経由して、前記車々間通信転送サービス部に対する前記イベント情報の通知、前記受信側の前記送信周期、前記送信電力および前記受信感度を指定するメッセージの送信要求、前記送受信サービス管理部に対する前記送信電力および前記受信感度の設定を行う、請求項１記載の車載通信装置。
3. 前記車々間通信転送サービス処理部は、
   前記車々間通信管理サービス処理部から取得した前記送信電力、前記受信感度および前記通信チャネルの利用率に前記送信周期の情報を加えて前記通信制御情報とし、前記転送サービス処理部から受信した前記メッセージに付加することで、前記受信側の前記車載通信装置に対して前記通信制御情報を通知し、
   前記受信側の前記車々間通信管理サービス処理部は、前記送信側の前記通信制御情報に基づいて、前記受信側の前記アプリケーション処理部からのメッセージを送信する際の送信電力、受信感度、送信周期を決定する、請求項２記載の車載通信装置。
4. 前記送信側の前記車載通信装置の前記車々間通信管理サービス処理部は、
   前記受信側の前記車載通信装置との初期接続を行うためのメッセージを、前記アプリケーション処理部からの要求に応じて、前記車々間通信転送サービス処理部を経由して受信側の前記車々間通信管理サービス処理部に対して送信開始する、請求項１記載の車載通信装置。
5. 前記車々間通信管理サービス処理部は、
   前記車々間通信転送サービス処理部を経由して、前記トランザクション管理部および前記アプリケーション処理部を含む上位プロトコルに対して、通信接続の状況および前記車々間通信管理サービス処理部内で発生したイベント情報を少なくとも通知する、請求項１記載の車載通信装置。
6. 前記受信側の前記車載通信装置の前記車々間通信転送サービス処理部は、
   前記送信側の前記車載通信装置からの前記メッセージを受信し、前記メッセージに含まれる前記通信制御情報を前記車々間通信管理サービス処理部に設定し、
   前記受信側の前記車載通信装置の前記車々間通信管理サービス処理部は、
   前記通信制御情報が設定されることを契機に、前記送信側の前記車載通信装置に対して初期接続の接続手順を開始する請求項１記載の車載通信装置。
7. 前記アプリケーション処理部は、
   アプリケーションの種類を前記車々間通信管理サービス処理部に登録し、
   前記車々間通信転送サービス処理部は、
   前記メッセージに付加されたローカルポート番号を利用して、前記車々間通信管理サービス処理部から前記アプリケーションの種類を取得し、識別することにより、前記アプリケーションの種類に応じた送受信処理を行い、路車間通信アプリケーションの場合には前記メッセージを車々間通信アプリケーションよりも優先的に前記送受信サービス処理部に送信する、請求項１記載の車載通信装置。
8. 移動局および基地局にそれぞれ搭載され、無線通信により前記移動局間および前記移動局と前記基地局との間で相互に受信側および送信側となる車載通信装置であって、
   前記車載通信装置は、
   前記送信側から前記受信側に対して、路車間通信および車々間通信を利用してメッセージを送信するアプリケーション処理部と、
   前記アプリケーション処理部から受信した前記メッセージの再送や分割／組み立てを含むトランザクションサービス、前記アプリケーション処理部を含む上位プロトコルを識別するためのローカルポート番号の付加、および前記上位プロトコルに応じて前記メッセージの送信先を判別する路車間−車々間通信連携サービス処理部と、
   前記路車間−車々間通信連携サービス処理部から受信した前記メッセージを、前記アプリケーション処理部で処理されるアプリケーションの優先度順に前記受信側の前記車載通信装置に対して送信する車々間通信転送サービス処理部と、
   前記車々間通信転送サービス処理部を介して与えられる前記メッセージ、および前記路車間−車々間通信連携サービス処理部から直接与えられる前記メッセージに、識別のための識別子を付与して、無線通信により前記受信側の前記車載通信装置に送信する送受信サービス処理部と、
   前記アプリケーション処理部から前記優先度を設定され、前記車々間通信転送サービス処理部からの要求に応じて前記優先度を通知する車々間通信管理サービス処理部とを備え、
   前記路車間−車々間通信連携サービス処理部は、
   前記アプリケーション処理部から受信した前記メッセージを、路車間通信で送信するか、車々間通信で送信するかを判別し、前記路車間通信の場合には前記送受信サービス処理部に直接前記メッセージを与え、前記車々間通信の場合には前記車々間通信転送サービス処理部を経由して前記送受信サービス処理部に与え、
   前記受信側の前記車載通信装置の前記送受信サービス処理部は、
   前記送信側の前記車載通信装置から受信した前記メッセージに付与された前記識別子に基づき、前記メッセージを、路車間−車々間通信連携サービス処理部または車々間通信転送サービス処理部に送信する車載通信装置。
9. 前記車々間通信転送サービス処理部は、路車間通信アプリケーションのメッセージを受信したことを、前記車々間通信管理サービス処理部に通知し、
   前記車々間通信管理サービス処理部は、前記路車間通信アプリケーションのメッセージの受信を契機に、車々間通信アプリケーションのメッセージを送信する際の前記送信電力および前記送信周期を制御することにより、路車間通信アプリケーションのメッセージを優先的に送受信する、請求項１記載の車載通信装置。
10. 移動局および基地局にそれぞれ搭載され、無線通信により前記移動局間および前記移動局と前記基地局との間で相互に受信側および送信側となる車載通信装置であって、
    前記車載通信装置は、
    アプリケーションから受信したメッセージを、アプリケーションの優先度順に前記受信側の前記車載通信装置に対して送信し、アプリケーションに対するメッセージを送受信し、エラー情報を含むイベント情報を通知し、送信電力、受信感度、通信チャネルの利用率に送信周期の情報を加えて通信制御情報とし、アプリケーションから受信したメッセージに付加することにより前記受信側の前記車載通信装置に対して前記通信制御情報を通知する車々間通信転送サービス処理部と、
    アプリケーションおよび前記車々間通信転送サービス処理部に接続され、アプリケーションから優先度を設定され、前記車々間通信転送サービス処理部からの要求に応じて前記優先度を通知し、前記通信制御情報に基づいてメッセージを送信する際の送信電力、受信感度、送信周期を決定および設定し、前記車載通信装置との初期接続を行うためのメッセージをアプリケーションからの要求に応じて、前記車々間通信転送サービス処理部を経由して前記受信側の前記車々間通信管理サービス処理部に対して送信する車々間通信管理サービス処理部とを備え、
    前記車々間通信転送サービス処理部は、前記受信側の前記車載通信装置に対して前記車々間通信管理サービス処理部の有する通信制御情報を通知し、
    前記受信側の前記車載通信装置は、
    前記車々間通信転送サービス処理部において、受信した前記メッセージに付与された前記通信制御情報を前記車々間通信管理サービス処理部に送信し、受信した前記メッセージをアプリケーションに送信する、車載通信装置。
11. 移動局および基地局にそれぞれ搭載され、無線通信により前記移動局間および前記移動局と前記基地局との間で相互に受信側および送信側となる車載通信装置であって、
    前記車載通信装置は、
    前記受信側の前記車載通信装置に周期的にメッセージを送信するアプリケーション処理部と、
    前記アプリケーション処理部に接続され、前記アプリケーション処理部から受信した前記メッセージの送信を行うとともに、前記アプリケーション処理部から受信した前記メッセージに、前記アプリケーション処理部を含む上位プロトコルを識別するためのアプリケーション番号や提供可能なアプリケーション一覧および利用可能な周波数チャネル情報を付与する転送部と、
    前記転送部に接続され、前記転送部から受信した前記メッセージを、前記アプリケーション処理部で処理されるアプリケーションの優先度順に前記受信側の前記車載通信装置に対して送信し、前記転送部に対する前記メッセージを送受信し、エラー情報を含むイベント情報を通知し、送信電力、受信感度、通信チャネルの利用率に送信周期の情報を加えて通信制御情報とし、アプリケーションから受信したメッセージに付加することにより前記受信側の前記車載通信装置に対して前記通信制御情報を通知する車々間通信転送サービス処理部と、
    前記車々間通信転送サービス処理部に接続され、前記車々間通信転送サービス処理部から受信した前記メッセージを、無線通信により前記受信側の前記車載通信装置との間で送受信する送受信サービス処理部と、
    前記送受信サービス処理部が、前記メッセージを送受信する際の送信電力、受信感度および通信チャネルの利用率を少なくとも含む前記通信制御情報を管理する送受信サービス管理部と、
    前記アプリケーション処理部と前記車々間通信転送サービス処理部と前記送受信サービス管理部に接続され、前記アプリケーション処理部の情報を管理するとともに、前記アプリケーションの要求に応じて接続管理サービスを開始する管理部とを備え、
    前記管理部は、
    前記アプリケーション処理部から前記優先度を設定され、前記車々間通信転送サービス処理部からの要求に応じて前記優先度を通知し、前記通信制御情報に基づいてメッセージを送信する際の送信電力、受信感度、送信周期を決定または設定する車々間通信管理サービス処理部を含み、
    前記転送部および前記管理部は、前記移動局と前記基地局との間での路車間通信および車々間通信を行うためのプロトコルを構成し、
    前記車々間通信転送サービス処理部は、前記受信側の前記車載通信装置に対して前記車々間通信管理サービス処理部の有する前記通信制御情報を通知し、
    前記受信側の前記車載通信装置は、
    前記車々間通信転送サービス処理部において、受信した前記メッセージに付与された前記通信制御情報を前記車々間通信管理サービス処理部に送信し、受信した前記メッセージは前記転送部に送信される、車載通信装置。
12. 請求項１、請求項８、請求項１０および請求項１１の何れかに記載の車載通信装置により構成され、前記移動局間および前記移動局と前記基地局との間での無線通信を行う、路車間−車々間通信連携システム。

Images