JP2014075678A - 通信機、通信処理装置、アプリケーション装置、コンピュータプログラム、及び送信方法 - Google Patents

Abstract

【課題】送信期間において送信可能なアプリケーションのデータ量を、アプリケーションデータの送信要求元（アプリケーション）が容易に認識できるようにする。
【解決手段】通信機２は、アプリケーションデータの送信要求に応じて、前記アプリケーションデータを、周期的に割り当てられる１又は複数の送信期間において送信させる通信処理部２５ａを備えている。通信処理部２５ａは、一周期で割り当てられる１又は複数の送信期間において送信できるアプリケーションデータのデータ量を送信要求の要求元に認識させるための情報を、要求元に通知する通知処理を行う。
【選択図】図４

Description

本発明は、通信機、通信処理装置、アプリケーション装置、コンピュータプログラム、及び送信方法に関する。

近年、路車間通信、車車間通信による高度道路交通システム（ＩＴＳ）が検討されている。路車間通信とは、路側通信機（基地局）と車載通信機（移動局）との間の通信であり、車車間通信とは、車載通信機（移動局）間の通信である。
このような高度道路交通システムのための通信方式については、標準規格及びガイドラインが制定されている（非特許文献１，２参照）。

非特許文献１では、所定の送信周期（１００ｍｓ）毎に到来する最大１６個の路車間通信期間が離散的に設けられ、路車間通信期間以外の時間帯が車車間通信期間として設定される。

一般社団法人電波産業会、"７００ＭＨｚ帯高度道路交通システム ＡＲＩＢ−ＳＴＤＴ１０９ １．０版"，［online］、平成２４年２月１４日、［平成２４年９月１８日検索］、インターネット<http://www.arib.or.jp/tyosakenkyu/kikaku_tushin/tsushin_kikaku_number.html> ＩＴＳ情報通信システム推進会議、"７００ＭＨｚ帯高度道路交通システム拡張機能ガイドライン ＩＴＳ ＦＯＲＵＭ ＲＣ−０１０ １．０版"，[online]、２０１２年３月２６日、［平成２４年９月１８日検索］、インターネット<http://www.itsforum.gr.jp/>

それぞれの路側通信機には、一送信周期内の複数（最大１６個）の路車間通信期間のうちの１又は複数の路車間通信期間が、送信期間として割り当てられる。電波干渉を回避するため、割り当てられる路車間通信期間は、路側通信機ごとに異なったものとされることがある。
各路側通信機は、割り当てられた送信期間（路車間通信期間）において、交通情報などのアプリケーションデータの送信を行う。

つまり、路側通信機は、所定の周期（１００ｍｓ）毎に割り当てられた１又は複数の送信期間において、アプリケーションデータを送信する。

一つの送信周期（１００ｍｓ）内のアプリケーションデータのデータ量は、一つの送信周期で割り当てられた１又は複数の送信期間内で送信し得るデータ量の最大値未満であることが望まれる。アプリケーションデータのデータ量が最大値を超えると、超えた分のデータは、その送信周期では送信できなくなる。

路車間通信期間において送信される路車間通信データには、データを送信する路側通信機の周囲に存在する車両や歩行者等に関する交通情報等を含ませることができるが、これらのデータは交通量によって大きく変動するケースがある。また、交通情報以外の周辺情報等を送信する場合にもそれらの情報は時間帯や季節等によって随時変動しうる、と考えられ、路側通信機を設置して運用を開始した当初よりも大幅にデータ量が増大することがありうる。
また、例えば、路車間通信期間において、車載通信機向けの路車間通信データだけでなく、他の路側通信機向けの路路間通信データも送信しようとした場合、路車間通信データのデータ量に路路間通信データのデータ量が加わって、データ量が大きくなり、前記最大値を超え易くなる。

データ量が大きくなる場合にも、一つの送信周期において送信すべきデータ量の最大値を予め見積もることが可能であれば、その最大値に応じて、その路側通信機に割り当てられる送信期間を予め長く設定することはできる。
しかし、一周期において送信すべきデータ量の最大値を予め見積もるのは必ずしも容易ではない。

例えば、路路間通信では、ある路側通信機が、自ら生成した路路間通信データを送信するほか、他の路側通信機がさらに別の路側通信機向けに生成した路路間通信データを転送のために送信しなければならないことがある。しかも、路路間通信データのサイズは、データによってまちまちである。また、ブロードキャスト送信されて再送が行われない路車間通信とは異なり、路路間通信では、通信相手が決まっているため、伝搬環境の変動により再送が生じる可能性もある。
したがって、路車間通信期間において、路車間通信に加えて路路間通信も行われる場合、一周期において送信すべきデータ量の最大値を予め見積もることは困難となる。

この結果、一周期内で送信すべきアプリケーションデータのデータ量が、予め設定された送信期間では送信不可能なデータ量となることがある。
また、割り当てられる送信期間を長くするとしても、非特許文献１に準拠する場合、非特許文献１に規定される送信周期毎の最大送信時間である１０．５ｍｓを超えることはできない。

非特許文献１，２に従うと、生成されたアプリケーションデータのデータ量が、予め設定された送信期間では送信可能なデータ量を超えた場合であっても、非特許文献１，２に規定する通信プロトコルでの通信処理の対象になりかねない。この場合、非特許文献１，２に規定する通信プロトコルでの送信処理及びその送信処理に関連する処理が、送信できない過剰なデータに対しても行われ、無駄な処理（セキュリティ処理及び送信処理など）が発生する。

無駄な処理の発生を回避するには、アプリケーションデータを生成又は転送するアプリケーションが、非特許文献１，２に規定する通信プロトコルでの通信処理を行う通信処理部に対して、送信要求を行う前に、送信可否を判定することが考えられる。
つまり、アプリケーションが、通信処理部に対して、アプリケーションデータを与える前に、そのアプリケーションデータが、予め設定された送信期間で送信可能か否かを判定することで、過剰なデータを通信処理部に与えることが防止できる。

そのような判定を行う方法として、例えば、通信処理部において行われる送信処理及びその送信処理に関連する処理と同じ処理を、アプリケーションにおいても事前に行うことが考えられるが、この方法の場合、アプリケーションは下位レイヤで行われる通信処理と同一の処理を事前に行う必要があり、２重処理となって、アプリケーションでの処理負荷が増大する。また、下位レイヤでの通信処理方法が変更されるたびに、アプリケーションでの処理内容もそれに応じて修正する必要が生じ、メンテナンスにも多大なコストを要する。
特に、送信処理に関連して、アプリケーションデータに対するセキュリティ処理（暗号化など）が行われる場合、処理負荷が大きくなりやすい。つまり、セキュリティ処理の負荷は大きいため、過剰なデータに対してセキュリティ処理をアプリケーションにて行うと、アプリケーションの処理負荷が非常に大きくなる。
また、非特許文献２に規定する拡張層（Extended Layer）が利用される場合、拡張層では、アプリケーションデータの分割処理という複雑な処理をアプリケーションでも事前に行う必要が生じ、アプリケーションの処理負荷が非常に大きくなる。

そこで、本発明は、送信期間において送信可能なアプリケーションのデータ量を、アプリケーションデータの送信要求元が容易に認識できるようにすることを目的とする。

（１）一の観点からみた本発明は、アプリケーションデータの送信要求に応じて、前記アプリケーションデータを、周期的に割り当てられる１又は複数の送信期間において送信させる通信処理部を備え、前記通信処理部は、一周期で割り当てられる１又は複数の前記送信期間において送信できるアプリケーションデータのデータ量を前記送信要求の要求元に認識させるための情報を、前記要求元に通知する通知処理を行うことを特徴とする通信機である。

上記本発明によれば、一周期で割り当てられる１又は複数の前記送信期間において送信できるアプリケーションデータのデータ量が、送信要求の要求元に通知されるため、要求元は、周期で割り当てられる１又は複数の前記送信期間において送信できるアプリケーションデータのデータ量を容易に認識することができる。

（２）前記通信処理部は、送信要求された前記アプリケーションデータのうち、一周期内で割り当てられる１又は複数の前記送信期間内で送信しきれないデータを破棄する破棄処理を行うのが好ましい。この場合、破棄処理にて破棄されたデータは、通信処理部における破棄処理後の処理の対象とならないため、無駄な処理の発生を抑制できる。

（３）前記通信処理部は、通信機が準拠する通信プロトコルにおける複数のレイヤの処理を行うように構成され、前記通知処理によって通知される前記情報の生成処理と、前記破棄処理と、は、複数の前記レイヤのうちの同一のレイヤにおける処理として行われるのが好ましい。生成処理と破棄処理とが同一レイヤで行われることで、処理が容易となる。

（４）前記通信処理部は、通信機が準拠する通信プロトコルにおける複数のレイヤの処理を行うように構成され、前記複数のレイヤには、送信要求された前記アプリケーションデータに対するセキュリティ処理と、前記セキュリティ処理が行われた前記アプリケーションデータに対するデータ分割処理と、が行われる所定のレイヤを含み、前記所定のレイヤでは、前記通知処理によって通知される前記情報の生成も行われるのが好ましい。セキュリティ処理とデータ分割処理とが行われるレイヤ（例えば、非特許文献２の拡張層）によって、前記情報の生成を行うことで、効率的な処理が行える。

（５）前記通信処理部は、前記アプリケーションデータを一周期で割り当てられる１又は複数の前記送信期間において送信させる通信処理の結果に基づいて、前記通知処理によって通知される前記情報を生成するのが好ましい。一周期で割り当てられる１又は複数の前記送信期間において送信できるアプリケーションデータのデータ量を送信要求の要求元に認識させるための情報の生成を、通信処理の結果に基づいて生成することで、適切な情報を生成することができる。

（６）前記通知処理は、送信要求された前記アプリケーションデータを、一周期内で割り当てられる１又は複数の前記送信期間内で送信しきれないと判定された場合、又は、送信要求された前記アプリケーションデータを送信するためのパケットのデータ量が、１又は複数の前記送信期間に占める割合が所定の割合を超えたと判定された場合、に行われるのが好ましい。
この場合、通知の発生頻度を抑えることができる。

（７）他の観点からみた本発明は、前記（１）〜（６）のいずれか１項に記載の通信機に用いられる通信処理装置であって、アプリケーションデータの送信要求に応じて、前記アプリケーションデータを、周期的に割り当てられる１又は複数の送信期間において送信させる通信処理部を備え、前記通信処理部は、一周期で割り当てられる１又は複数の前記送信期間において送信できるアプリケーションデータのデータ量を前記送信要求の要求元に認識させるための情報を、前記要求元に通知することを特徴とする通信処理装置である。

（８）他の観点からみた本発明は、コンピュータを、（７）項記載の通信処理装置として機能させるためのコンピュータプログラムである。

（９）他の観点からみた本発明は、周期的に割り当てられる１又は複数の送信期間において送信されるべきアプリケーションデータの送信要求を、アプリケーションデータの送信処理を行う通信処理装置に対して与える要求部と、一周期で割り当てられる１又は複数の前記送信期間において送信できるアプリケーションデータのデータ量を認識するための情報を、前記通信処理装置から取得する取得部と、一周期で割り当てられる１又は複数の送信期間において送信されるべきアプリケーションデータのデータ量を、前記情報に基づいて調整するアプリケーション装置である。

（１０）他の観点からみた本発明は、コンピュータを、（９）項記載のアプリケーション装置として機能させるためのコンピュータプログラムである。

（１１）他の観点からみた本発明は、アプリケーションデータの送信要求が通信処理部に与えられ、前記送信要求を受けた前記通信処理部は、前記送信要求に応じて、前記アプリケーションデータを、周期的に割り当てられる１又は複数の送信期間において送信させるとともに、一周期で割り当てられる１又は複数の前記送信期間において送信できるアプリケーションデータのデータ量を前記送信要求の要求元に認識させるための情報を、前記要求元に通知し、前記要求元は、一周期で割り当てられる１又は複数の送信期間において送信されるべきアプリケーションデータのデータ量を、前記情報に基づいて調整することを特徴とする送信方法である。

本発明によれば、送信期間において送信可能なアプリケーションのデータ量を、アプリケーションデータの送信要求元が容易に認識することができる。

高度道路交通システムの実施の一形態を示す概略斜視図である。 路側通信機の構成図である。 （ａ）は無線フレーム（スーパーフレーム）を示す図であり、（ｂ）は無線フレーム中の送信期間と送信禁止期間を示す図である。 通信機のプロトコルスタックを示す図である。 パケット構造を示す図である。 アプリケーションデータの送信シーケンスである。 図６の送信シーケンスの詳細な説明図である。 アプリケーションデータの送信シーケンスである。 アプリケーションデータの送信シーケンスである。 図９の送信シーケンスの詳細な説明図である。 アプリケーションデータの送信シーケンスである。

［１．第１実施形態］
図１は、本発明の一実施形態に係る高度道路交通システム（ＩＴＳ）の全体構成を示す概略斜視図である。なお、本実施形態では、道路構造の一例として、南北方向と東西方向の複数の道路が互いに交差した碁盤目構造を想定している。
図１に示すように、本実施形態の高度道路交通システムは、交通信号機１、路側通信機（通信機）２、車載通信機（通信機）３（図２参照）、中央装置４、車載通信機３を搭載した車両５、及び、車両感知器や監視カメラ等よりなる路側センサ６を含む。
なお、本実施形態において特に説明しない点については、非特許文献１，２に準拠する。

交通信号機１と路側通信機２は、複数の交差点Ａ１〜Ａ５，Ｂ１〜Ｂ５、Ｃ１〜Ｃ５，Ｄ１〜Ｄ５のそれぞれに設置されており、電話回線等の有線通信回線７を介してルータ８に接続されている。このルータ８は交通管制センター内の中央装置４に接続されている。
中央装置４は、自身が管轄するエリアの交通信号機１及び路側通信機２とＬＡＮ（Local Area Network）を構成している。なお、中央装置４は、交通管制センターではなく道路上に設置してもよい。

路側センサ６は、各交差点に流入する車両台数をカウントする等の目的で、管轄エリア内の道路の各所に設置されている。この路側センサ６は、直下を通行する車両５を超音波感知する車両感知器、或いは、道路の交通状況を時系列に撮影する監視カメラ等よりなり、感知情報や画像データは通信回線７を介して中央装置４に送信される。
なお、図１では、図示を簡略化するために、各交差点に信号灯器が１つだけ描写されているが、実際の各交差点には、互いに交差する道路の上り下り用として少なくとも４つの信号灯器が設置されている。

高度道路交通システムにおいて、無線通信システムを構成する、複数の交差点それぞれに設置された複数の路側通信機（通信機）２は、その周囲を走行する車両の車載通信機３との間で無線通信（路車間通信）が可能である。
また、各路側通信機２は、自己の送信波が到達する所定範囲内に位置する他の路側通信機２とも無線通信（路路間通信）が可能である。
また、同じく無線通信システムを構成する車載通信機（通信機）３は、路側通信機２との間で無線通信を行うとともに、キャリアセンス方式で他の車載通信機３と無線通信（車車間通信）が可能である。

路側通信機２は、図２に示すように、無線通信のためのアンテナ２０が接続された無線通信部（ＲＦ部；ＰＨＹ部）２１と、有線通信回線７を介して中央装置４と通信するための有線通信部２２と、通信制御処理を行う通信処理装置２５と、を備えている。
通信処理装置２５は、制御部２３と、必要な情報を記憶する記憶部２４と、を備えている。制御部２３は、無線通信及び有線通信の通信制御処理を行う。記憶部２４は、無線通信及び優先通信のために必要な情報を記憶する。

通信処理装置２５は、その機能の一部又は全部が、ハードウェア回路によって構成されていてもよいし、その機能の一部又は全部が、コンピュータプログラムによって実現されていてもよい。通信処理装置２５の機能の一部又は全部がコンピュータプログラムによって実現される場合、通信処理装置２５（制御部２３）は、コンピュータを含み、コンピュータによって実行されるコンピュータプログラムは、記憶部２４に記憶される。

図３（ａ）は、無線通信システムにおいて用いられる無線フレーム（スーパーフレーム）を示している。この無線フレームは、その時間軸方向の長さ（フレーム長）が１００ｍｓに設定されている。つまり、１秒間に１０フレームが発生する。
フレームは、例えば、路側通信機２が有するＧＰＳ受信機（図示省略）によって受信したＧＰＳ信号に含まれる１ＰＰＳ（１秒周期の信号）に基づいて生成される。

一つの無線フレーム（１００ｍｓ）は、複数の路車間通信期間ＳＬ１と、複数の車車間通信期間ＳＬ２と、を含んで構成されている。
路車間通信期間ＳＬ１は、路側通信機２に割り当てられる路車間通信用のタイムスロット（路側通信機用送信期間）であり、この時間帯ＳＬ１においては、路側通信機２による無線送信が許容される。路車間通信期間ＳＬ１は、一つの無線フレーム（１００ｍｓ）内に最大１６個まで設定可能である。

車車間通信期間ＳＬ２は、車載通信機３用のタイムスロット（車用通信期間）であり、この時間帯ＳＬ２は車載通信機３による無線送信用として開放するため、路側通信機２は路車間通信期間ＳＬ２では無線送信を行わない。

無線フレームに含まれている路車間通信期間ＳＬ１と、車車間通信期間ＳＬ２とは、時間軸方向に交互に配置されている。
路車間通信期間ＳＬ１には、それぞれスロット番号ｉ（＝１〜１６）が付されている。

それぞれの路側通信機２には、無線フレームに含まれる複数の路車間通信期間ＳＬ１のうちの、一つ又は複数の路車間通信期間ＳＬ１が送信期間として設定され、その他の路車間通信期間ＳＬ１は送信が禁止される。すなわち、路側通信機２にとっては、車車間通信期間ＳＬ２及び自機２に割り当てられていない路車間通信期間ＳＬ１は、送信禁止期間となる。
図３（ｂ）では、路側通信機２にｎ＝４，５，６の３つの路車間通信期間ＳＬ１が送信期間として割り当てられている場合の送信禁止期間を示している。路側通信機２は、送信禁止期間以外の期間（送信期間）でデータ送信を行う。

一つの無線フレーム内において、一の路側通信機２に割り当てられる送信期間の数は任意である。また、一つの送信期間の期間長は、路車通信期間の期間長と等しくてもよいし、路車間通信期間よりも短くてもよい。また、一つの路車間通信期間内に複数の送信期間が設定されてもよい。

図４は、非特許文献１の標準規格に示す通信プロトコルスタックに、非特許文献２のガイドラインに示す拡張層（Extended Layer）ＥＬを加えたものを示している。また、図４では、非特許文献１，２に規定されていない幾つかの機能も示している。

非特許文献１に規定されるプロトコルスタックは、レイヤ１（Ｌ１，物理層：Physical Layer）、レイヤ２（Ｌ２，データリンク層：Data Link Layer）、車車間・路車間共用通信制御情報層（ＩＶＣ−ＲＶＣ層：Inter-Vehicle Communication - Road to Vehicle Communication Layer）及びレイヤ７（Ｌ７，アプリケーション層：Application Layer）の４構造である。各層及びアプリケーションＡＰは、システム管理のための情報を有するシステム管理にアクセスすることができる。

レイヤ１は、ＩＥＥＥ８０２．１１において規定される物理層に準拠して動作する。
レイヤ２は、ＭＡＣ副層（Medium Access Control sublayer）と、ＬＬＣ副層（Logical Link Control sublayer）と、から構成される。なお、ＭＡＣ副層を、単に、ＭＡＣ層（Medium Access Control layer）ともいい、ＬＬＣ副層（Logical Link Control sublayer）を、単に、ＬＬＣ層（Logical Link Control layer）ともいう。

ＭＡＣ層は、無線チャネルの通信管理として、フレーム制御及び同報通信（ブロードキャスト）を行う。
ＬＬＣ層は、上位層のエンティティ間でパケット伝送を行うために、確認なしコネクションレス型通信のサービスを提供する。

車車間・路車間共用通信制御情報層（ＩＶＣ−ＲＶＣ層）は、車車間・路車間共用通信制御に必要な情報の生成と管理を行う。非特許文献１では、路路間通信は規定されていないため、本実施形態のように、路車間通信期間ＳＬ１において路路間通信を行う場合、車車間・路車間共用通信制御情報層（ＩＶＣ−ＲＶＣ層）において、路路間通信は、路車間通信の一種として取り扱われる。

レイヤ７は、アプリケーションＡＰに対して通信制御手段（通信処理部としての機能）を提供するためのものである。アプリケーションＡＰは、送信される通信パケットに格納されるアプリケーションデータ（交通情報、車両情報など）をレイヤ７に与えるとともに、受信した通信パケットに格納されていたアプリケーションデータをレイヤ７から取得する。

非特許文献２に規定される拡張層ＥＬは、レイヤ７の上位層として存在し、アプリケーションＡＰとレイヤ７との間の通信機能を拡張するためのものである。
拡張層ＥＬは、アプリケーションＡＰに対してデータ伝送サービスを提供する。アプリケーションＡＰは、送信される通信パケットに格納されるアプリケーションデータ（交通情報、車両情報など）を拡張層ＥＬに与える。データ伝送サービス提供のため、拡張層ＥＬは、レイヤ７以下の下位階層に対してデータ伝送要求を出す。

また、拡張層ＥＬは、アプリケーションＡＰから与えられたアプリケーションデータを分割し、分割データをレイヤ７に与えることができる。つまり、拡張層ＥＬは、アプリケーションデータを分割して複数の分割データを生成する分割処理部として機能する。
また、レイヤ７から受け取った分割データを結合させてアプリケーションＡＰに与えることができる。
なお、拡張層ＥＬは、レイヤ７とともに、セキュリティ管理にアクセスすることができる。

図４に示す拡張層ＥＬ、レイヤ７、ＩＶＣ−ＲＶＣ層、レイヤ２、アプリケーションＡＰ、セキュリティ管理、及びシステム管理に相当する機能は、通信処理装置２５によって実行される。また、レイヤ１の機能は、無線通信部２１によって実行される。
なお、通信処理装置２５のうち、図４のアプリケーションＡＰに相当する機能を、「アプリケーション装置２５ａ」といい、図４のアプリケーションＡＰよりも下位の機能(拡張層ＥＬ、レイヤ７、ＩＶＣ−ＲＶＣ層、レイヤ２、セキュリティ管理、及びシステム管理)を、「通信処理部２５ｂ」という。
また、例えば、アプリケーション装置２５ａの機能は、コンピュータプログラムによって実現し、通信処理部２５ｂの機能を、ハードウェアによって構成することができる。また、通信処理部２５ｂの機能を、コンピュータプログラムによって実現してもよい。

図５は、路側通信機２（及び車載通信機３）によって送信される通信パケットの構成を示している。図５に示す通信パケットの構成は、非特許文献１，２に準拠したものである。

通信パケットは、先頭にＰＨＹヘッダ（物理ヘッダ）を有している。ＰＨＹヘッダは、送信側の通信機２のレイヤ１（物理層）によって、ＭＡＣ層から取得したＭＡＣフレーム（ＭＰＤＵ；MAC Protocol Data Unit）の前に付加される。
ＰＨＹヘッダは、受信側の通信機２，３におけるレイヤ１（物理層）において読み取られて、受信側のレイヤ１における通信制御処理に用いられる。なお、ＰＨＹヘッダを含む通信パケット全体が、ＰＰＤＵ（PHY Protocol Data Unit）である。ＰＨＹヘッダよりも後側のＭＡＣフレーム（ＭＰＤＵ）は、ＰＳＤＵ（PHY Service Data Unit）でもある。

ＰＨＹヘッダの構成は、ＩＥＥＥ８０２．１１に準拠する。したがって、ＰＨＹヘッダには、プリアンブルなどが含まれる。

ＰＨＹヘッダに続いて、ＭＡＣ制御フィールド（ＭＡＣヘッダ）及びＬＬＣ制御フィールド（ＬＬＣヘッダ）が設けられている。ＭＡＣ制御フィールドは、送信側の通信機２のレイヤ２のＭＡＣ層によって、ＬＬＣ層から取得したＬＬＣフレーム（ＬＰＤＵ；LLC Protocol Data Unit）の前に付加される。
ＭＡＣ制御フィールドは、受信側の通信機２，３のレイヤ２のＭＡＣ層において読み取られて、受信側のＭＡＣ層における通信制御処理に用いられる。
ＭＡＣ制御フィールドよりも後側のＬＬＣフレーム（ＬＰＤＵ）は、ＭＳＤＵ（MAC Service Data Unit）でもある。

ＭＡＣ制御フィールドに続くＬＬＣ制御フィールドは、送信側の通信機２のレイヤ２のＬＬＣ層によって、ＩＶＣ−ＲＶＣ層から取得したＩＲフレーム（ＩＰＤＵ；IVC-RVC Protocol Data Unit）の前に付加される。
ＬＬＣ制御フィールドは、受信側の通信機２，３のレイヤ２のＬＬＣ層において読み取られて、受信側のＬＬＣ層における通信制御処理に用いられる。
また、ＬＬＣ制御フィールドよりも後側のＩＲフレーム（ＩＰＤＵ）は、ＬＳＤＵ（LLC Service Data Unit）でもある。

ＬＬＣ制御フィールに続いて、ＩＲ制御フィールド（ＩＲヘッダ）が設けられている。ＩＲ制御フィールドは、送信側の通信機２のＩＶＣ−ＲＶＣ層によって、ＡＰフレーム（ＡＰＤＵ；Application Protocol Data Unit）の前に付加される。
ＩＲ制御フィールドは、受信側の通信機２，３のＩＶＣ−ＲＶＣ層において読み取られて、受信側のＩＶＣ−ＲＶＣ層における通信制御処理に用いられる。
ＩＲ制御フィールドよりも後側のＡＰフレーム（ＡＰＤＵ；Application Protocol Data Unit）は、ＩＳＤＵ（IVC-RVC Service Data Unit）でもある。

ＩＲ制御フィールドに続いて、Ｌ７ヘッダが設けられている。Ｌ７ヘッダは、送信側の通信機２のレイヤ７によって、ＡＳＤＵ（Application Service Data Unit）の前に付加される。
Ｌ７ヘッダは、受信側の通信機２，３のレイヤ７において読み取られて、受信側のレイヤ７における通信制御処理に用いられる。
レイヤ７ヘッダよりも後側のＥＬフレーム（ＥＬ−ＰＤＵ；EL-Protocol Data Unit）は、ＡＳＤＵ（Application Service Data Unit）でもある。

Ｌ７ヘッダに続いて、ＥＬヘッダ（ＥＬ基地局ヘッダ）が設けられている。ＥＬヘッダは、送信側の通信機２の拡張層ＥＬによって、ＥＬ−ＳＤＵ（EL-Service Data Unit）の前に付加される。
ＥＬヘッダは、受信側の通信機２，３の拡張層ＥＬにおいて読み取られて、受信側の拡張層ＥＬにおける処理に用いられる。

図６，７は、路側通信機２が、アプリケーションＡＰにて生成されたアプリケーションデータを送信するためのシーケンスを示している。
まず、アプリケーションＡＰのアプリケーションデータの生成部３１（図４参照）は、路車間通信データ（例えば、図７に示す「路車Ａ」「路車Ｂ」）や路路間通信データ（例えば、図７に示す「路路Ａ」「路路Ｂ」「路路Ｃ」）を生成する。
すると、アプリケーションＡＰの要求部３２（図４参照）は、生成されたアプリケーションデータそれぞれの送信要求であるEL-BaseStationBroadcastData要求を生成する（ステップＳ１）。

EL-BaseStationBroadcastData要求には、アプリケーションデータのほか、DataAssociatedInformation（データ関連情報）及びEL_ApplicationDataLength（アプリケーションデータの長さ情報）が含まれる。
DataAssociatedInformation（データ関連情報）は、１又は複数のアプリケーションデータそれぞれの順番と、１又は複数のアプリケーションデータの総数と、を含む。
例えば、図７に示すように、路車Ａ、路車Ｂ、路路Ａ、路路Ｂ、路路Ｃの５つのデータが生成された場合、総数＝５に設定され、５つのアプリケーションデータそれぞれの順番として１〜５の値が設定される。つまり、各アプリケーションデータの「順番／総数」は、路車Ａが「１／５」、路車Ｂが「２／５」、路路Ａが「３／５」、路路Ｂが「４／５」、路路Ｃが「５／５」となる（図７参照）。

図４に示すように、拡張層ＥＬの取得部がアプリケーションＡＰからEL-BaseStationBroadcastData要求を受けると、拡張層ＥＬのセキュリティ処理部４２は、必要に応じて、セキュリティ処理をセキュリティ管理ＳＥＣに実行させる。
すなわち、拡張層ＥＬは、アプリケーションＡＰからアプリケーションデータを受け取った際に、セキュリティ管理を経由する旨の指示を受け取った場合には、アプリケーションＡＰから受け取ったアプリケーションデータ（アンセキュアなアプリケーションデータ）を、セキュリティ管理ＳＥＣに渡す（EL-Security要求（セキュリティ処理）；ステップＳ２；図６参照）。なお、セキュリティ処理とは、セキュリティ管理ＳＥＣにて実行される処理をいうだけでなく、拡張層ＥＬのセキュリティ処理部４２がセキュリティ管理ＳＥＣにEL-Security要求を通知することもセキュリティ処理という。

セキュリティ管理ＳＥＣでは、拡張層ＥＬから受け取ったアンセキュアなアプリケーションデータに対して、セキュリティ処理を行って、セキュアなアプリケーションデータを生成する。
セキュリティ管理ＳＥＣにおいて、アンセキュアなアプリケーションデータをセキュアなアプリケーションデータにする処理（セキュリティ処理）には、暗号化処理、署名処理などの処理が含まれる（ただし、非特許文献１，２では規定されていない）。
セキュリティ管理は、セキュリティ処理が施されたセキュアなアプリケーションデータを、拡張層ＥＬに戻す（EL-Security応答；ステップＳ３；図６参照）。

セキュリティ管理ＳＥＣによってセキュリティ処理が施されたセキュアなアプリケーションデータは、セキュリティヘッダを有しているなどの理由で、アンセキュアなアプリケーションに比べてデータ量が変動（増加）する。したがって、図７では、ステップＳ１におけるセキュリティ処理前の各アプリケーションデータのサイズよりも、ステップＳ２におけるセキュリティ処理後の各アプリケーションデータのサイズのほうが大きくなっている。
つまり、セキュリティ処理は、アプリケーションデータのデータ量を変動させる変動処理である。変動処理によるアプリケーションデータ量の変動は、アプリケーションＡＰ側において、送信可能なデータ量を把握させるのを困難にさせる要因の一つとなっている。

続いて、拡張層ＥＬの分割処理部４３（図４参照）は、セキュリティ管理から与えられたセキュアなアプリケーションデータの分割を分割して、分割データを生成する（ステップＳ−４；データ分割処理）。
拡張層ＥＬは、アプリケーションデータを分割した分割データそれぞれを、ＥＬ−ＳＤＵとして取り扱う。

拡張層ＥＬのＥＬヘッダ構築部４４（図４参照）は、アプリケーションデータを分割して得られた分割データそれぞれを、ＥＬ−ＳＤＵとして扱い、各ＥＬ−ＳＤＵ（分割データ）の前に付加されるＥＬヘッダ（図７参照）を構築して（ステップＳ５）、ＥＬ−ＰＤＵを生成する。
ＥＬヘッダ構築部４４は、ＥＬヘッダの生成のため、ＥＬヘッダを構成する分割番号などの情報を生成する。

各分割データ（ＥＬ−ＳＤＵ）に付加されるＥＬヘッダの分割番号は、アプリケーションデータ毎の分割データの順番及び総数を有する。図７のステップＳ５では、分割番号（順番／総数）を、括弧付き数字で示した（なお、括弧無し数字は、DataAssociatedInformation（データ関連情報）が示すアプリケーションデータそれぞれの「順番／総数」である。

図７では、路路Ａ（１／５）、路路Ｂ（２／５）、路車Ａ（３／５）、路車Ｂ（４／５）、路車Ｃ（５／５）は、分割処理（ステップＳ４）によって、それぞれは２つに分割されている。
この場合、路路Ａ（１／５）を分割して生成された２つの分割データのうちの一方の分割データに対応する分割番号の「順番」には（１）が設定され、他方の分割データに対応する分割番号の「順番」には（２）が設定される。路路Ａ（１／５）を分割して生成された２つの分割データに対応する分割番号の「総数」には、いずれも（２）が設定される。
他のアプリケーションデータ（路路Ｂ（２／５）、路車Ａ（３／５）、路車Ｂ（４／５）、路車Ｃ（５／５））についても、同様に分割番号が設定される。

なお、アプリケーションデータの分割の際には、路側通信機２に割り当てられた送信期間（図７の送信期間Ａ，送信期間Ｂ）の期間長を考慮して、分割が行われる。このため、１０個の分割データのうち、路路Ｂ（４／５）の２番目の分割データ（２）／（２）と、路路Ｃ（５／５）の分割データ（１）／（２），（２）／（２）は、下位レイヤに渡しても、図７の送信期間Ａ，Ｂでは送信しきれないことがわかる。
そこで、ＥＬ層は、送信期間Ａ，Ｂでは送信しきれない路路Ｂ（４／５）の２番目の分割データ（２）／（２）と、路路Ｃ（５／５）の分割データ（１）／（２），（２）／（２）を破棄する（破棄処理）。

そして、拡張層ＥＬの要求部４５（図４参照）は、レイヤ７への分割データ（ＥＬ−ＰＤＵ）の送信要求であるBaseStationBroadcastData要求（データ送信要求）を生成し、そのBaseStationBroadcastData要求をレイヤ７に対し与える（ステップＳ６）。
また、要求部４５は、拡張層ＥＬは、ＥＬヘッダが付加された各分割データ（ＥＬ−ＰＤＵ）に対応するSequenceNumber（シーケンスナンバ）の設定も行う。SequenceNumber（シーケンスナンバ）は、一つの無線フレーム（送信周期＝１００ｍｓ）毎の送信期間において送信すべき１又は複数のアプリケーションデータすべての分割データの順番／総数を示すものである。
SequenceNumber（シーケンスナンバ）は、分割データ（パケット）のSequence（シーケンス）及びTotalNumber（総数）を含む。
図７では、送信期間Ａ，Ｂにおいて送信可能な７個の分割データに対し、（Sequence／TotalNumber）として、１／７〜７／７の値が設定される。

BaseStationBroadcastData要求を受けたレイヤ７以下のレイヤでは、SequenceNumber（シーケンスナンバ）が１／７〜７／７である分割データを、送信期間Ａ，Ｂにて送信させる処理が行われる。

拡張層ＥＬの要求部４５がBaseStationBroadcastData要求をレイヤ７に対して行うと、拡張層ＥＬの応答部４６（図４参照）は、EL-BaseStationBroadcastData応答を、アプリケーションＡＰに通知する（ステップＳ７；通知処理）。このEL-BaseStationBroadcastData応答は、非特許文献１，２では規定されていないものである。

応答部４６が生成するEL-BaseStationBroadcastData応答には、一周期内の送信期間Ａ，Ｂにおいて送信できるアプリケーションデータのデータ量を、EL-BaseStationBroadcastData要求の要求元であるアプリケーションＡＰに認識させるための情報（送信可能データ量）を含んでいる。応答部４６は、前記情報（送信可能データ量）を生成する処理も行う（生成処理）。
送信できないアプリケーションデータを破棄する破棄処理と、前記情報（送信可能データ量）の生成処理と、を、拡張層ＥＬという同一のレイヤで行うことで、処理が容易となる。

前記情報（送信可能データ量）は、例えば、アプリケーションＡＰからDataAssociatedInformation（データ関連情報）として通知されたアプリケーションデータの「順番／総数」（１／５〜５／５）のうち、送信期間Ａ，Ｂにて完全に送信できたところまでのアプリケーションデータの「順番／総数」として生成される。
例えば、図７では、完全に送信できるのは、３／５の路路Ａのデータまでである（４／５の路路Ｂのデータは一部しか送信できない）。したがって、前記情報（送信可能データ量）としては、路路Ａのデータまで送信できたことを示す「３／５」となる。

また、前記情報（送信可能データ量）としては、送信期間Ａ，Ｂにて完全に送信できたところまでのアプリケーションデータのデータ量であってもよい。当該データ量は、アプリケーションＡＰから通知されたEL_ApplicationDataLength（アプリケーションデータの長さ情報）を用いて、送信期間Ａ，Ｂにて完全に送信できる３／５の路路Ａのデータまでのデータ量を求めることができる。
例えば、図７では、１／５の路車Ａのデータ量が６００Ｂ，２／５の路車Ｂのデータ量が６００Ｂ、３／５の路路Ａのデータ量が３００Ｂの場合、前記情報（送信可能データ量）としては、１５００Ｂとなる。

以上のように、前記情報（送信可能データ量）は、拡張層ＥＬにおける通信処理の結果に基づいて、生成される。

なお、送信期間Ａ，Ｂにおいて送信できるアプリケーションデータのデータ量を、より正確にアプリケーションＡＰに認識させるためには、送信できるアプリケーションデータのデータ量は、アプリケーションＡＰが拡張層ＥＬにアプリケーションデータを渡したときのアプリケーションデータの大きさを基準にすべきである。拡張層ＥＬにおける変動処理によってアプリケーションデータのデータ量に変動が生じている場合、変動処理後のデータ量では、アプリケーションＡＰとしては、自ら生成したアプリケーションデータのうちのどの程度のデータが送信できたかを把握するのが困難になる。

応答部４６は、全てのEL-BaseStationBroadcast要求に対して、EL-BaseStationBroadcastData応答を生成してもよいが、EL-BaseStationBroadcastData応答を生成しない場合があってもよい。
応答部４６がEL-BaseStationBroadcastData応答を生成するのは、例えば、アプリケーションＡＰから送信を要求されたアプリケーションデータを、送信期間Ａ，Ｂで送信しきれないと判定された場合に限ってもよい。
また、応答部４６がEL-BaseStationBroadcastData応答を生成するのは、アプリケーションＡＰから送信を要求されたアプリケーションデータを送信するためのパケットのデータ量が、送信期間Ａ，Ｂに占める割合が所定の割合（例えば、８０％）を超えたと判定された場合に限ってもよい。
このように、EL-BaseStationBroadcastData応答の生成を制限することで、処理を簡素化することができる。

アプリケーションＡＰの取得部３３（図４参照）が、EL-BaseStationBroadcastData応答を応答部４５から受け取ると、EL-BaseStationBroadcastData応答に含まれる前記情報（送信可能データ量）は、アプリケーションＡＰの調整部３４（図４参照）に与えられる。
拡張層ＥＬは、EL-BaseStationBroadcastData要求を拡張層ＥＬ与えたときの、DataAssociatedInformation（データ関連情報）及びEL_ApplicationDataLength（アプリケーションデータの長さ情報）を、EL-BaseStationBroadcastData応答があるまで保持する。
調整部３４は、EL-BaseStationBroadcastData応答に含まれる前記情報（送信可能データ量）を取得すると、EL-BaseStationBroadcastData要求を拡張層ＥＬ与えたときの、DataAssociatedInformation（データ関連情報）及び／又はEL_ApplicationDataLength（アプリケーションデータの長さ情報）を参照し、送信できたアプリケーションデータを特定する。また、送信できたアプリケーションデータの総データ量も特定する。

アプリケーションＡＰは、送信できたものとして特定されたアプリケーションデータについては破棄する。送信できなかったデータのうち、再送が必要な情報（例えば、路路間通信データ）については、再送のために保持する。

また、調整部３４は、送信できたアプリケーションデータの総データ量を、生成部３１に与える。生成部３１は、新たにアプリケーションデータを生成する場合、調整部３４から与えられた総データ量を、送信可能な総データ量とみなして、当該総データ量を超えない範囲で、送信周期（１００ｍｓ）毎に送信すべきアプリケーションデータを生成する。

したがって、アプリケーションＡＰから拡張層ＥＬ以下のレイヤに与えられるアプリケーションデータのデータ量が、一送信周期（１００ｍｓ）内の送信期間Ａ，Ｂで送信可能なデータ量を超えることが抑制され、送信できないデータが無駄に拡張層ＥＬ以下のレイヤに与えられて、無駄な処理（特に、送信されないデータへのセキュリティ処理）が行われることが防止される。

なお、アプリケーションＡＰは、拡張層ＥＬからEL-BaseStationBroadcastData応答を受け取る前には、一送信周期で送信可能な総データ量が把握できない。したがって、アプリケーションＡＰは、少なくとも１回は、一送信周期で送信可能な総データ量を超えたアプリケーションデータを、拡張層ＥＬに与えてしまう可能性がある。しかし、拡張層ＥＬからEL-BaseStationBroadcastData応答を受け取ると、一送信周期で送信可能な総データ量を認識できるため、通信処理部２５ｂにおける無駄な処理（特に、セキュリティ処理）の発生を抑制することができる。

アプリケーションＡＰが、無駄なアプリケーションデータを通信処理部２５ｂに与えないようにするには、アプリケーションＡＰ自身が、通信処理部２５における処理（拡張層ＥＬ以下の処理）を模擬して、送信期間Ａ，Ｂにて送信可能なデータ量を見積もることも可能ではある。しかし、この場合、アプリケーションＡＰが、情報処理部２５における処理と同様の処理を２重に行うことになり、無駄が生じる。

また、仮に、アプリケーションＡＰが、情報処理部２５における処理よりも簡易な処理で、送信期間Ａ，Ｂにて送信可能なデータ量を見積もることで、２重処理を軽減することはできる。ただし、この場合も、ある程度の２重処理になり、処理効率が低くなる。
これに対し、第１実施形態のように、実際に通信処理を行う通信処理部２５ｂ（拡張層ＥＬ）から送信期間Ａ，Ｂにて送信可能なデータ量を示す情報を取得することで、２重処理を回避することができる。

また、第１実施形態では、セキュリティ処理後のアプリケーションデータを分割することで、分割データが送信期間Ａ，Ｂにて送信可能であるかの判定がなされたが、セキュリティ処理前に、送信期間Ａ，Ｂにて送信可能なアプリケーションデータのデータ量を見積もってもよい。

例えば、セキュリティ管理ＳＥＣでのセキュリティ処理の前に、拡張層ＥＬにて、セキュリティ管理ＳＥＣでのセキュリティ処理後のアプリケーションデータのデータ量を推定する。そして、セキュリティ処理後のアプリケーションデータで仮想的な分割を行って、送信期間Ａ，Ｂに収まるアプリケーションデータと収まらないアプリケーションデータを特定する。
そして、応答部４６は、送信期間Ａ，Ｂに収まるアプリケーションデータのデータ量をアプリケーションＡＰに認識させるための情報を含むEL-BaseStationBroadcast応答を、アプリケーションＡＰに通知する。
さらに、拡張層ＥＬは、セキュリティ管理ＳＥＣに渡すアプリケーションデータを、送信期間Ａ，Ｂに収まるアプリケーションデータだけにすることで、無駄なセキュリティ処理の発生を防止できる。

また、第１実施形態において、拡張層ＥＬが、アプリケーションＡＰからアプリケーションデータを受け取った際に、セキュリティ管理ＳＥＣを経由しない旨の指示を受け取った場合には、図８に示すように、EL-Security要求（ステップＳ２）は省略される。
したがって、拡張層ＥＬの分割処理部４３は、アプリケーションＡＰから受け取ったアプリケーションデータ（アンセキュアなアプリケーションデータ）を分割して、分割データを生成する。

［２．第２実施形態］
図９，１０は、第２実施形態に係る路側通信機２が、アプリケーションＡＰにて生成されたアプリケーションデータを生成するためのシーケンスを示している。第２実施形態の路側通信機２は、図４の拡張層ＥＬを省略したものに相当する。したがって、拡張層ＥＬによるアプリケーションデータの分割は行われない。また、第１実施形態において拡張層ＥＬが有していた応答部４６は、第２実施形態においてはＭＡＣ層が有する。
なお、第２実施形態において説明を省略した点については、第１実施形態と同様である。

まず、アプリケーションＡＰのアプリケーションデータの生成部３１は、路車間通信データ（例えば、図１０に示す「路車Ａ」「路車Ｂ」）や路路間通信データ（例えば、図１０に示す「路路Ａ」「路路Ｂ」「路路Ｃ」）を生成する。
すると、アプリケーションＡＰの要求部３２は、生成されたアプリケーションデータそれぞれの送信要求であるBaseStationBroadcastData要求を生成する（ステップＳ１１）。

BaseStationBroadcastData要求には、アプリケーションデータのほか、SequenceNumber（シーケンスナンバ）が含まれる。
SequenceNumber（シーケンスナンバ）は、一つの無線フレーム（送信周期＝１００ｍｓ）毎の送信期間において送信すべき１又は複数のアプリケーションデータの順番／総数を示すものである。
SequenceNumber（シーケンスナンバ）は、アプリケーションデータそれぞれのSequence（シーケンス）及びTotalNumber（総数）を含む。
図１０では、生成された５個のアプリケーションデータ（路車Ａ，路車Ｂ，路路Ａ，路路Ｂ，路路Ｃ）に対して、（Sequence／TotalNumber）として、１／５〜５／５の値が設定される。

アプリケーションＡＰの要求部３２は、SequenceNumber（シーケンスナンバ）とともに、BaseStationBroadcastData要求（データ送信要求）をレイヤ７へ与える（ステップＳ１１）。

レイヤ７（Ｌ７）では、アプリケーションＡＰからBaseStationBroadcastData要求を受けると、セキュリティ処理をセキュリティ管理ＳＥＣに実行させる。
すなわち、レイヤ７は、アプリケーションＡＰからアプリケーションデータを受け取った際に、セキュリティ管理を経由する旨の指示を受け取った場合には、アプリケーションＡＰから受け取ったアプリケーションデータ（アンセキュアなアプリケーションデータ）を、セキュリティ管理ＳＥＣに渡す（Security要求（セキュリティ処理）；ステップＳ１２；図９参照）。なお、セキュリティ処理とは、セキュリティ管理ＳＥＣにて実行される処理をいうだけでなく、レイヤ７がセキュリティ管理ＳＥＣにSecurity要求を通知することもセキュリティ処理という。

セキュリティ管理ＳＥＣでは、レイヤ７から受け取ったアンセキュアなアプリケーションデータに対して、セキュリティ処理を行って、セキュアなアプリケーションデータを生成する。
セキュリティ管理ＳＥＣにおいて、アンセキュアなアプリケーションデータをセキュアなアプリケーションデータにする処理（セキュリティ処理）には、暗号化処理、署名処理などの処理が含まれる。
セキュリティ管理は、セキュリティ処理が施されたセキュアなアプリケーションデータを、レイヤ７に戻す（Security応答；ステップＳ１３；図９参照）。
アプリケーションデータは、セキュリティ処理前よりもセキュリティ処理後のほうが大きくなる。

続いて、レイヤ７は、Ｌ７ヘッダが付加されたアプリケーションデータ（ＡＰＤＵ）をＩＶＣ−ＲＶＣ層へ与えるためのＩＲ−ＵＮＩＴＤＡＴＡ要求をＩＶＣ−ＲＶＣ層に送付する（ステップＳ１４；図９参照）。
ＩＶＣ−ＲＶＣ層は、ＡＰＤＵにＩＲ制御フィールドを付加してＩＰＤＵを生成し、そのＩＰＤＵをＬＬＣ層に与えるためのＤＬ−ＵＮＩＴＤＡＴＡ要求をＬＬＣ層に送付する（ステップ１５；図９参照）。

ＬＬＣ層は、ＩＰＤＵにＬＬＣ制御フィールドを付加してＬＰＤＵを生成し、そのＬＰＤＵ（ＭＳＤＵ）をＭＡＣ層に与えるためのＭＡ−ＵＮＩＴＤＡＴＡ要求をＭＡＣ層に送付する（ステップＳ１６；図９参照）。

ＭＡＣ層は、ＬＬＣ層から受領したＭＳＤＵを保持する。ＭＡＣ層は、保持したＭＳＤＵのSequenceNunber（Sequence／TotalNumber）を参照し、TotalNumber（総数）に示された数の一連のＭＳＤＵ群がすべて揃っていれば、送信周期（１００ｍｓ）毎に到来する送信期間Ａ，Ｂの開始時から順に、ＭＰＤＵ（MAC Protocol Data Unit）の生成を行い、レイヤ１に対して、送信要求を行う。

ＭＡＣ層は、TotalNumber（総数）に示された数の一連のＭＳＤＵ群を、一つの送信周期における送信期間Ａ，Ｂで送信しきれない場合、送信できなかった送信できなかったパケット（ＭＰＤＵ）を破棄する（破棄処理）。

ＭＡＣ層は、送信期間Ａ，Ｂを用いた送信が完了すると、ＭＡ−ＵＮＩＴＤＡＴＡ応答を、ＬＬＣ層に通知する（ステップＳ１７；通知処理）。

ＭＡＣ層が生成するＭＡ−ＵＮＩＴＤＡＴＡ応答には、一周期内の送信期間Ａ，Ｂにおいて送信できるアプリケーションデータのデータ量を、BaseStationBroadcastData要求の要求元であるアプリケーションＡＰに認識させるための情報（送信可能データ量）を含んでいる。ＭＡＣ層（の応答部４６）は、前記情報（送信可能データ量）を生成する処理も行う（生成処理）。
送信できないアプリケーションデータを破棄する破棄処理と、前記情報（送信可能データ量）の生成処理と、を、ＭＡＣ層という同一のレイヤで行うことで、処理が容易となる。

前記情報（送信可能データ量）は、例えば、アプリケーションＡＰからSequenceNunber（Sequence／TotalNumber）として通知されたアプリケーションデータの「順番／総数」（１／５〜５／５）のうち、送信期間Ａ，Ｂにて完全に送信できたところまでのアプリケーションデータの「順番／総数」として生成される。
例えば、図１０では、完全に送信できるのは、４／５の路路Ｂのデータまでである。したがって、前記情報（送信可能データ量）としては、路路Ｂのデータまで送信できたことを示す「４／５」となる。

また、前記情報（送信可能データ量）としては、第１実施形態と同様に、送信期間Ａ，Ｂにて完全に送信できたところまでのアプリケーションデータのデータ量であってもよい。
例えば、図１０では、１／５〜４／５までのデータ量が、１５００Ｂである場合、前記情報（送信可能データ量）としては、１５００Ｂとなる。
なお、前記情報（送信可能データ量）として、「４／５」と「１５００Ｂ」の双方が存在していてもよい。

以上のように、前記情報（送信可能データ量）は、ＭＡＣ層における通信処理の結果に基づいて、生成される。

ＬＬＣ層は、ＭＡＣ層からＭＡ−ＵＮＩＴＤＡＴＡ応答を受けると、そのＭＡ−ＵＮＩＴＤＡＴＡに含まれる前記情報（送信可能データ量）を含むＤＬ−ＵＮＩＴＤＡＴＡ応答を、ＩＶＣ−ＲＶＣ層に通知する（ステップＳ１８；通知処理）。
ＩＶＣ−ＲＶＣ層は、ＬＬＣ層からＤＬ−ＵＮＩＴＤＡＴＡ応答を受けると、そのＤＬ−ＵＮＩＴＤＡＴＡに含まれる前記情報（送信可能データ量）を含むＩＲ−ＵＮＩＴＤＡＴＡ応答を、レイヤ７に通知する（ステップＳ１９；通知処理）。
レイヤ７は、ＩＶＣ−ＲＶＣ層からＩＲ−ＵＮＩＴＤＡＴＡ応答を受けると、そのＩＲ−ＵＮＩＴＤＡＴＡに含まれる前記情報（送信可能データ量）を含むBaseStationBroadcastData応答を、アプリケーションＡＰに通知する（ステップＳ２０；通知処理）。

なお、ＭＡ−ＵＮＩＴＤＡＴＡ応答（ステップＳ１７）、ＤＬ−ＵＮＩＴＤＡＴＡ応答（ステップＳ１８）、ＩＲ−ＵＮＩＴＤＡＴＡ応答（ステップＳ１９）、BaseStationBroadcastData応答(ステップＳ２０)は、いずれも、非特許文献１，２では規定されていないものである。

アプリケーションＡＰの取得部３３が、BaseStationBroadcastData応答（ステップＳ２０）を受け取ると、BaseStationBroadcastData応答に含まれる前記情報（送信可能データ量）は、アプリケーションＡＰの調整部３４に与えられる。

この結果、第１実施形態と同様に、アプリケーションＡＰからレイヤ７以下のレイヤに与えられるアプリケーションデータのデータ量が、一送信周期（１００ｍｓ）内の送信期間Ａ，Ｂで送信可能なデータ量を超えることが抑制され、送信できないデータが無駄にレイヤ７以下のレイヤに与えられて、無駄な処理（特に、送信されないデータへのセキュリティ処理）が行われることが防止される。

なお、第２実施形態において、レイヤ７が、アプリケーションＡＰからアプリケーションデータを受け取った際に、セキュリティ管理ＳＥＣを経由しない旨の指示を受け取った場合には、図１１に示すように、Security要求（ステップＳ１２）は省略される。

本発明に関して、今回開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は、上記した意味ではなく、特許請求の範囲と均等の意味及び範囲内でのすべての変更が含まれることが意図される。

１ 交通信号機
２ 路側通信機
３ 車載通信機
４ 中央装置
５ 車両
６ 路側センサ
７ 有線通信回線
２１ 無線通信部
２２ 有線通信部
２３ 制御部
２４ 記憶部
２５ 通信処理装置
２５ａ アプリケーション装置
２５ｂ 通信処理部
３１ 生成部
３２ 要求部
３３ 取得部
３４ 調整部
４１ 取得部
４２ セキュリティ処理部
４３ 分割処理部
４４ ヘッダ構築部
４５ 要求部
４６ 応答部
ＡＰ アプリケーション（アプリケーション装置）
ＥＬ 拡張層

Claims (11)

1. アプリケーションデータの送信要求に応じて、前記アプリケーションデータを、周期的に割り当てられる１又は複数の送信期間において送信させる通信処理部を備え、
   前記通信処理部は、一周期で割り当てられる１又は複数の前記送信期間において送信できるアプリケーションデータのデータ量を前記送信要求の要求元に認識させるための情報を、前記要求元に通知する通知処理を行う
   ことを特徴とする通信機。
2. 前記通信処理部は、送信要求された前記アプリケーションデータのうち、一周期内で割り当てられる１又は複数の前記送信期間内で送信しきれないデータを破棄する破棄処理を行う
   請求項１記載の通信機。
3. 前記通信処理部は、通信機が準拠する通信プロトコルにおける複数のレイヤの処理を行うように構成され、
   前記通知処理によって通知される前記情報の生成処理と、前記破棄処理と、は、複数の前記レイヤのうちの同一のレイヤにおける処理として行われる
   請求項２記載の通信機。
4. 前記通信処理部は、通信機が準拠する通信プロトコルにおける複数のレイヤの処理を行うように構成され、
   前記複数のレイヤには、送信要求された前記アプリケーションデータに対するセキュリティ処理と、前記セキュリティ処理が行われた前記アプリケーションデータに対するデータ分割処理と、が行われる所定のレイヤを含み、
   前記所定のレイヤでは、前記通知処理によって通知される前記情報の生成も行われる
   請求項１〜３のいずれか１項に記載の通信機。
5. 前記通信処理部は、前記アプリケーションデータを一周期で割り当てられる１又は複数の前記送信期間において送信させる通信処理の結果に基づいて、前記通知処理によって通知される前記情報を生成する
   請求項１〜４のいずれか１項に記載の通信機。
6. 前記通知処理は、
   送信要求された前記アプリケーションデータを、一周期内で割り当てられる１又は複数の前記送信期間内で送信しきれないと判定された場合、又は、
   送信要求された前記アプリケーションデータを送信するためのパケットのデータ量が、１又は複数の前記送信期間に占める割合が所定の割合を超えたと判定された場合、
   に行われる請求項１〜５のいずれか１項に記載の通信機。
7. 請求項１記載の通信機に用いられる通信処理装置であって、
   アプリケーションデータの送信要求に応じて、前記アプリケーションデータを、周期的に割り当てられる１又は複数の送信期間において送信させる通信処理部を備え、
   前記通信処理部は、一周期で割り当てられる１又は複数の前記送信期間において送信できるアプリケーションデータのデータ量を前記送信要求の要求元に認識させるための情報を、前記要求元に通知する
   ことを特徴とする通信処理装置。
8. コンピュータを、請求項７記載の通信処理装置として機能させるためのコンピュータプログラム。
9. 周期的に割り当てられる１又は複数の送信期間において送信されるべきアプリケーションデータの送信要求を、アプリケーションデータの送信処理を行う通信処理装置に対して与える要求部と、
   一周期で割り当てられる１又は複数の前記送信期間において送信できるアプリケーションデータのデータ量を認識するための情報を、前記通信処理装置から取得する取得部と、
   一周期で割り当てられる１又は複数の送信期間において送信されるべきアプリケーションデータのデータ量を、前記情報に基づいて調整する
   アプリケーション装置。
10. コンピュータを、請求項９記載のアプリケーション装置として機能させるためのコンピュータプログラム。
11. アプリケーションデータの送信要求が通信処理部に与えられ、
    前記送信要求を受けた前記通信処理部は、
    前記送信要求に応じて、前記アプリケーションデータを、周期的に割り当てられる１又は複数の送信期間において送信させるとともに、
    一周期で割り当てられる１又は複数の前記送信期間において送信できるアプリケーションデータのデータ量を前記送信要求の要求元に認識させるための情報を、前記要求元に通知し、
    前記要求元は、一周期で割り当てられる１又は複数の送信期間において送信されるべきアプリケーションデータのデータ量を、前記情報に基づいて調整する
    ことを特徴とする送信方法。

Images