JP2016019078A - 路側通信機、セキュリティ処理方法、及びコンピュータプログラム - Google Patents
路側通信機、セキュリティ処理方法、及びコンピュータプログラム Download PDFInfo
- Publication number
- JP2016019078A JP2016019078A JP2014139593A JP2014139593A JP2016019078A JP 2016019078 A JP2016019078 A JP 2016019078A JP 2014139593 A JP2014139593 A JP 2014139593A JP 2014139593 A JP2014139593 A JP 2014139593A JP 2016019078 A JP2016019078 A JP 2016019078A
- Authority
- JP
- Japan
- Prior art keywords
- communication
- communication device
- data
- security processing
- roadside
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Abstract
【課題】路車間通信及び路路間通信のそれぞれに対して適切なセキュリティ処理を施すことができる路側通信機等を提供する。【解決手段】セキュリティ処理を施したデータを移動通信機と路側通信機とに送信する路側通信機であって、一又は複数のデータをセキュリティ処理の実行単位として設定する設定部を備え、前記設定部は、前記移動通信機宛のデータと前記路側通信機宛のデータとに対して、異なる基準により前記実行単位を設定する。【選択図】図１０
Description
本発明は、路側通信機、セキュリティ処理方法、及びコンピュータプログラムに関する。
近年、路車間通信、車車間通信による高度道路交通システム（ＩＴＳ）が検討されている。路車間通信とは、路側通信機（基地局）と車載通信機（移動局）との間の通信であり、車車間通信とは、車載通信機（移動局）間の通信である（特許文献１参照）。
このような高度道路交通システムのための通信方式については、標準規格及びガイドラインが制定されている（非特許文献１，２参照）。
また、最近では、路車間通信及び車車間通信だけでなく、路側通信機同士が無線により通信を行う「路路間通信」についても検討され（例えば、特許文献２参照）、実験用のガイドラインも制定されている（非特許文献３参照）。
このような高度道路交通システムのための通信方式については、標準規格及びガイドラインが制定されている（非特許文献１，２参照）。
また、最近では、路車間通信及び車車間通信だけでなく、路側通信機同士が無線により通信を行う「路路間通信」についても検討され（例えば、特許文献２参照）、実験用のガイドラインも制定されている（非特許文献３参照）。
一般社団法人電波産業会、"７００ＭＨｚ帯高度道路交通システム ＡＲＩＢ−ＳＴＤＴ１０９ １．０版"，［online］、インターネット<http://www.arib.or.jp/tyosakenkyu/kikaku_tushin/tsushin_kikaku_number.html>
ＩＴＳ情報通信システム推進会議、"７００ＭＨｚ帯高度道路交通システム拡張機能ガイドライン ＩＴＳ ＦＯＲＵＭ ＲＣ−０１０ １．０版"，[online]、インターネット<http://www.itsforum.gr.jp/>
"７００ＭＨｚ帯高度道路交通システム 実験用路路間通信ガイドライン ＩＴＳ ＦＯＲＵＭ ＲＣ−０１２ １．０版",［online］、インターネット<http://www.itsforum.gr.jp/Public/J7Database/p47/ITS_FORUM_RC-012_v10.pdf>
路路間又は路車間で通信を行う場合、送信データの真正性や機密性等のセキュリティを確保することが求められる。
前記特許文献１においては、１つの制御周期（スーパーフレーム；例えば１００ｍｓ）に路側通信機から車側通信機に連続して送信される複数の一連の通信パケットに対して、それぞれ個別にセキュリティ処理を施すのではなく、互いに関連するセキュリティ処理を施している。これにより、セキュリティ処理（暗号化や復号化等）に要する演算負荷を軽減することが可能である。
前記特許文献１においては、１つの制御周期（スーパーフレーム；例えば１００ｍｓ）に路側通信機から車側通信機に連続して送信される複数の一連の通信パケットに対して、それぞれ個別にセキュリティ処理を施すのではなく、互いに関連するセキュリティ処理を施している。これにより、セキュリティ処理（暗号化や復号化等）に要する演算負荷を軽減することが可能である。
しかし、特許文献１記載の技術では、セキュリティ処理を施した一連の通信パケットのうちいずれかを受信側の通信機が受信できないと、他の通信パケットも含めて全体を復号化（デコード）できなくなるという不都合がある。
もっとも、路車間通信のために路側通信機から車載通信機に送信される情報は、信号情報や安全支援情報、車両検知情報等であり、一連の通信パケットを全て受信しなければサービスとして利用できない場合が多い。したがって、デコードの可否に関わらず、いずれかの通信パケットを受信できなかった時点でそのサービスを利用できなくなるので、上記の不都合はそれほど問題とはならない。
もっとも、路車間通信のために路側通信機から車載通信機に送信される情報は、信号情報や安全支援情報、車両検知情報等であり、一連の通信パケットを全て受信しなければサービスとして利用できない場合が多い。したがって、デコードの可否に関わらず、いずれかの通信パケットを受信できなかった時点でそのサービスを利用できなくなるので、上記の不都合はそれほど問題とはならない。
一方、路路間通信のために路側通信機から１つの制御周期で送信される複数の通信パケットは、１つの路側通信機宛ではなく、異なる路側通信機に宛てたものである場合が多い。そのため、仮にこれらの複数の通信パケットに対して特許文献１記載のようなセキュリティ処理を施したとすると、各路側通信機は自機宛以外のものも含めて全ての通信パケットを受信しなければデコード処理ができなくなる。
本発明は、路車間通信及び路路間通信のそれぞれに対して適切なセキュリティ処理を施すことができる路側通信機等を提供することを目的とする。
本発明の一態様に係る路側通信機は、
セキュリティ処理を施したデータを移動通信機と路側通信機とに送信する路側通信機であって、
一又は複数のデータをセキュリティ処理の実行単位として設定する設定部を備え、
前記設定部は、前記移動通信機宛のデータと前記路側通信機宛のデータとに対して、異なる基準により前記実行単位を設定するものである。
セキュリティ処理を施したデータを移動通信機と路側通信機とに送信する路側通信機であって、
一又は複数のデータをセキュリティ処理の実行単位として設定する設定部を備え、
前記設定部は、前記移動通信機宛のデータと前記路側通信機宛のデータとに対して、異なる基準により前記実行単位を設定するものである。
本発明の一態様に係るセキュリティ処理方法は、
移動通信機と路側通信機とにデータを送信する路側通信機において、前記データにセキュリティ処理を施すための方法であって、
前記移動通信機宛のデータと前記路側通信機宛のデータとで、異なる基準により一又は複数のデータをセキュリティ処理の実行単位として設定するものである。
移動通信機と路側通信機とにデータを送信する路側通信機において、前記データにセキュリティ処理を施すための方法であって、
前記移動通信機宛のデータと前記路側通信機宛のデータとで、異なる基準により一又は複数のデータをセキュリティ処理の実行単位として設定するものである。
本発明の一態様に係るコンピュータプログラムは、
移動通信機と路側通信機とにデータを送信する路側通信機において、コンピュータに前記データのセキュリティ処理を実行させるためのコンピュータプログラムであって、
一又は複数のデータをセキュリティ処理の実行単位として設定する設定部としてコンピュータを機能させ、
前記設定部は、前記移動通信機宛のデータと前記路側通信機宛のデータとに対して、異なる基準により前記実行単位を設定する、コンピュータプログラムである。
移動通信機と路側通信機とにデータを送信する路側通信機において、コンピュータに前記データのセキュリティ処理を実行させるためのコンピュータプログラムであって、
一又は複数のデータをセキュリティ処理の実行単位として設定する設定部としてコンピュータを機能させ、
前記設定部は、前記移動通信機宛のデータと前記路側通信機宛のデータとに対して、異なる基準により前記実行単位を設定する、コンピュータプログラムである。
なお、本発明は、以上のような路側通信機、セキュリティ処理方法、及びコンピュータプログラムとして実現することができるだけでなく、例えば、移動通信機として実現したり、路側通信機及び移動通信機を備えた通信システムとして実現したり、その通信システムの処理をステップとする通信方法として実現したり、通信システムの一部又は全部の装置を実現する半導体集積回路として実現したりすることができる。また、コンピュータプログラムは、フラッシュメモリー、ＣＤ−ＲＯＭ、又はＤＶＤ−ＲＯＭ等の記憶媒体に記憶させることができる。
本発明によれば、路車間通信及び路路間通信のそれぞれに対して適切なセキュリティ処理を施すことができる。
［本発明の実施形態の要旨］
最初に本発明の実施形態の要旨を列記して説明する。なお、以下に記載する各実施形態は、その一部を任意に組み合わせることも可能である。
（１）本発明の実施形態に係る路側通信機は、
セキュリティ処理を施したデータを移動通信機と路側通信機とに送信する路側通信機であって、
一又は複数のデータをセキュリティ処理の実行単位として設定する設定部を備え、
前記設定部は、前記移動通信機宛のデータと前記路側通信機宛のデータとに対して、異なる基準により前記実行単位を設定するものである。
最初に本発明の実施形態の要旨を列記して説明する。なお、以下に記載する各実施形態は、その一部を任意に組み合わせることも可能である。
（１）本発明の実施形態に係る路側通信機は、
セキュリティ処理を施したデータを移動通信機と路側通信機とに送信する路側通信機であって、
一又は複数のデータをセキュリティ処理の実行単位として設定する設定部を備え、
前記設定部は、前記移動通信機宛のデータと前記路側通信機宛のデータとに対して、異なる基準により前記実行単位を設定するものである。
この構成によれば、路車間通信と路路間通信とで、それぞれのデータに対して適切な実行単位でセキュリティ処理を施すことが可能となる。
なお、セキュリティ処理の実行単位とは、１つのセキュリティ処理の影響が及ぶ範囲をいい、例えば、その実行単位に含まれるいずれかのデータが欠けると、少なくとも１つのデータについてデコード処理が行えなくなるような単位をいう。
なお、セキュリティ処理の実行単位とは、１つのセキュリティ処理の影響が及ぶ範囲をいい、例えば、その実行単位に含まれるいずれかのデータが欠けると、少なくとも１つのデータについてデコード処理が行えなくなるような単位をいう。
（２）前記設定部は、
前記移動通信機宛のデータに対してサービス毎にセキュリティ処理の実行単位を設定し、
前記路側通信機宛のデータに対してデータ毎又は宛先毎にセキュリティ処理の実行単位を設定してもよい。
移動通信機宛のデータは、１つのサービスについての情報が複数のデータにわたる場合が多く、しかも移動通信機が全てのデータを受信しなければ、そのサービスに係る情報を取得できない場合が多い。したがって、移動通信機宛のデータは、サービス毎の実行単位でセキュリティ処理を行うことにより、データ１つ１つに個別のセキュリティ処理を行う場合に比べて処理負担を軽減することが可能となる。
他方、路側通信機宛のデータは、移動通信機宛のデータと比較して送信される頻度が少なく、通信の遅延に対する制限も緩やかである。したがって、セキュリティ処理の実行単位をデータ毎又は宛先毎にして処理負担が増大したとしても、それによる問題は生じ難い。また、１つの制御周期内に複数の路側通信機宛のデータがある場合、多くとも宛先毎の実行単位でセキュリティ処理が行われるため、受信側の路側通信機は、他機宛のデータを受信できなくても、自機宛のデータを受信できればそのデコード処理を行うことが可能となる。
なお、高度道路交通システムには、安全運転支援、交通管理、道路管理等の種々の分野があり、これらの分野には、交通関連情報、目的地情報、走行環境情報（天候、路面状況等）、危険警告情報（障害物、周辺車両の挙動等）、運転補助情報（速度制御、ハンドル制御等）、交通流の最適化についての情報（信号制御、経路案内等）、交通規制情報（事故情報、迂回情報等）など、多くの情報の提供サービスが含まれる。したがって、本発明の実施形態では、これらのサービス毎にセキュリティ処理を施すことができる。
前記移動通信機宛のデータに対してサービス毎にセキュリティ処理の実行単位を設定し、
前記路側通信機宛のデータに対してデータ毎又は宛先毎にセキュリティ処理の実行単位を設定してもよい。
移動通信機宛のデータは、１つのサービスについての情報が複数のデータにわたる場合が多く、しかも移動通信機が全てのデータを受信しなければ、そのサービスに係る情報を取得できない場合が多い。したがって、移動通信機宛のデータは、サービス毎の実行単位でセキュリティ処理を行うことにより、データ１つ１つに個別のセキュリティ処理を行う場合に比べて処理負担を軽減することが可能となる。
他方、路側通信機宛のデータは、移動通信機宛のデータと比較して送信される頻度が少なく、通信の遅延に対する制限も緩やかである。したがって、セキュリティ処理の実行単位をデータ毎又は宛先毎にして処理負担が増大したとしても、それによる問題は生じ難い。また、１つの制御周期内に複数の路側通信機宛のデータがある場合、多くとも宛先毎の実行単位でセキュリティ処理が行われるため、受信側の路側通信機は、他機宛のデータを受信できなくても、自機宛のデータを受信できればそのデコード処理を行うことが可能となる。
なお、高度道路交通システムには、安全運転支援、交通管理、道路管理等の種々の分野があり、これらの分野には、交通関連情報、目的地情報、走行環境情報（天候、路面状況等）、危険警告情報（障害物、周辺車両の挙動等）、運転補助情報（速度制御、ハンドル制御等）、交通流の最適化についての情報（信号制御、経路案内等）、交通規制情報（事故情報、迂回情報等）など、多くの情報の提供サービスが含まれる。したがって、本発明の実施形態では、これらのサービス毎にセキュリティ処理を施すことができる。
（３）前記設定部は、
前記移動通信機宛のデータに対して１つの制御周期内で送信されるもの毎にセキュリティ処理の実行単位を設定し、
前記路側通信機宛のデータに対してデータ毎又は宛先毎にセキュリティ処理の実行単位を設定してもよい。
移動通信機宛のデータは、１つのサービスについての情報が複数のデータにわたる場合が多く、しかもこれらのデータを１つの制御周期内で送信しなければならない。また、移動通信機が全てのデータを受信しなければ、そのサービスに係る情報を取得できない場合が多い。したがって、移動通信機宛のデータは、１制御周期内で送信されるもの毎の実行単位でセキュリティ処理を行うことにより、データ１つ１つに個別のセキュリティ処理を行う場合に比べて処理負担を軽減することが可能となる。
他方、路側通信機宛のデータは、移動通信機宛のデータと比較して送信される頻度が少なく、通信の遅延に対する制限も緩やかである。したがって、セキュリティ処理の実行単位をデータ毎又は宛先毎にして処理負担が増大したとしても、それによる不都合は生じ難い。また、１つの制御周期内に複数の路側通信機宛のデータがある場合、多くとも宛先毎の実行単位でセキュリティ処理が行われるため、受信側の路側通信機は、他機宛のデータを受信できなくても、自機宛のデータを通信できればデコード処理を行うことが可能となる。
前記移動通信機宛のデータに対して１つの制御周期内で送信されるもの毎にセキュリティ処理の実行単位を設定し、
前記路側通信機宛のデータに対してデータ毎又は宛先毎にセキュリティ処理の実行単位を設定してもよい。
移動通信機宛のデータは、１つのサービスについての情報が複数のデータにわたる場合が多く、しかもこれらのデータを１つの制御周期内で送信しなければならない。また、移動通信機が全てのデータを受信しなければ、そのサービスに係る情報を取得できない場合が多い。したがって、移動通信機宛のデータは、１制御周期内で送信されるもの毎の実行単位でセキュリティ処理を行うことにより、データ１つ１つに個別のセキュリティ処理を行う場合に比べて処理負担を軽減することが可能となる。
他方、路側通信機宛のデータは、移動通信機宛のデータと比較して送信される頻度が少なく、通信の遅延に対する制限も緩やかである。したがって、セキュリティ処理の実行単位をデータ毎又は宛先毎にして処理負担が増大したとしても、それによる不都合は生じ難い。また、１つの制御周期内に複数の路側通信機宛のデータがある場合、多くとも宛先毎の実行単位でセキュリティ処理が行われるため、受信側の路側通信機は、他機宛のデータを受信できなくても、自機宛のデータを通信できればデコード処理を行うことが可能となる。
（４）前記設定部は、通信状況の良否に応じて、前記路側通信機宛のデータに対するセキュリティ処理の実行単位として宛先毎又はデータ毎のいずれかを選択して設定してもよい。
通信状況の良否は、データの受信の成否に大きく影響する。一方、セキュリティ処理の実行単位は、その大きさ（データ数）が大きいほど、あるデータの受信失敗が他のデータのデコード処理に与える悪影響（デコード処理の失敗等）が大きくなる。したがって、通信状況の良否に応じてセキュリティ処理の実行単位を宛先毎又はデータ毎に設定することで、当該実行単位の大きさを適切に設定し、デコード処理への悪影響を小さくすることができる。
通信状況の良否は、データの受信の成否に大きく影響する。一方、セキュリティ処理の実行単位は、その大きさ（データ数）が大きいほど、あるデータの受信失敗が他のデータのデコード処理に与える悪影響（デコード処理の失敗等）が大きくなる。したがって、通信状況の良否に応じてセキュリティ処理の実行単位を宛先毎又はデータ毎に設定することで、当該実行単位の大きさを適切に設定し、デコード処理への悪影響を小さくすることができる。
（５）前記設定部は、宛先となる路側通信機に接続される端末数に応じて、当該路側通信機宛のデータに対するセキュリティ処理の実行単位として宛先毎又はデータ毎のいずれかを選択して設定してもよい。
宛先となる路側通信機に端末が接続されている場合、受信したデータは、その端末に対する情報であることが多い。したがって、路側通信機に接続されている端末の数が多いほど、データの受信失敗やデコード処理の失敗による悪影響が大きくなる。したがって、宛先となる路側通信機に接続される端末数に応じてセキュリティ処理の実行単位を宛先毎又はデータ毎に設定することで、当該実行単位の大きさを適切に設定し、データの受信失敗やデコード処理の失敗による悪影響を小さくすることが可能となる。
宛先となる路側通信機に端末が接続されている場合、受信したデータは、その端末に対する情報であることが多い。したがって、路側通信機に接続されている端末の数が多いほど、データの受信失敗やデコード処理の失敗による悪影響が大きくなる。したがって、宛先となる路側通信機に接続される端末数に応じてセキュリティ処理の実行単位を宛先毎又はデータ毎に設定することで、当該実行単位の大きさを適切に設定し、データの受信失敗やデコード処理の失敗による悪影響を小さくすることが可能となる。
（６）本発明の実施形態に係るセキュリティ処理方法は、
移動通信機と路側通信機とにデータを送信する路側通信機において、前記データにセキュリティ処理を施すための方法であって、
前記移動通信機宛のデータと前記路側通信機宛のデータとに対して、異なる基準により一又は複数のデータをセキュリティ処理の実行単位として設定するものである。
移動通信機と路側通信機とにデータを送信する路側通信機において、前記データにセキュリティ処理を施すための方法であって、
前記移動通信機宛のデータと前記路側通信機宛のデータとに対して、異なる基準により一又は複数のデータをセキュリティ処理の実行単位として設定するものである。
（７）本発明の実施形態に係るコンピュータプログラムは、
移動通信機と路側通信機とにデータを送信する路側通信機において、コンピュータに前記データのセキュリティ処理を実行させるためのコンピュータプログラムであって、
一又は複数のデータをセキュリティ処理の実行単位として設定する設定部としてコンピュータを機能させ、
前記設定部は、前記移動通信機宛のデータと前記路側通信機宛のデータとに対して、異なる基準により前記実行単位を設定する、コンピュータプログラムである。
移動通信機と路側通信機とにデータを送信する路側通信機において、コンピュータに前記データのセキュリティ処理を実行させるためのコンピュータプログラムであって、
一又は複数のデータをセキュリティ処理の実行単位として設定する設定部としてコンピュータを機能させ、
前記設定部は、前記移動通信機宛のデータと前記路側通信機宛のデータとに対して、異なる基準により前記実行単位を設定する、コンピュータプログラムである。
以下、本発明の好ましい実施形態について図面を参照しながら説明する。
［本発明の実施形態の詳細］
［通信システムの全体構成］
図１は、本発明の一実施形態に係る高度道路交通システム（ＩＴＳ）の全体構成を示す概略斜視図である。なお、本実施形態では、道路構造の一例として、南北方向と東西方向の複数の道路が互いに交差した碁盤目構造を想定している。
図１に示すように、本実施形態の高度道路交通システムは、交通信号機１、路側通信機（基地局）２、車載通信機（移動局；移動通信機）３（図２参照）、中央装置４、車載通信機３を搭載した車両５、及び、車両感知器や監視カメラ等よりなる路側センサ６を含む。移動局としては、車載通信機３に限られず、例えば、歩行者が所持する歩行者用通信機であってもよい。
なお、本実施形態において特に説明しない点については、非特許文献１〜３に準拠する。
［本発明の実施形態の詳細］
［通信システムの全体構成］
図１は、本発明の一実施形態に係る高度道路交通システム（ＩＴＳ）の全体構成を示す概略斜視図である。なお、本実施形態では、道路構造の一例として、南北方向と東西方向の複数の道路が互いに交差した碁盤目構造を想定している。
図１に示すように、本実施形態の高度道路交通システムは、交通信号機１、路側通信機（基地局）２、車載通信機（移動局；移動通信機）３（図２参照）、中央装置４、車載通信機３を搭載した車両５、及び、車両感知器や監視カメラ等よりなる路側センサ６を含む。移動局としては、車載通信機３に限られず、例えば、歩行者が所持する歩行者用通信機であってもよい。
なお、本実施形態において特に説明しない点については、非特許文献１〜３に準拠する。
交通信号機１と路側通信機２（２Ａ，２Ｂ）は、複数の交差点Ａ１〜Ａ５，Ｂ１〜Ｂ５、Ｃ１〜Ｃ５，Ｄ１〜Ｄ５，Ｅ１〜Ｅ５のそれぞれに設置されている。複数の路側通信機２のうちの一部の路側通信機２Ａは、電話回線等の有線通信回線７を介してルータ８に接続されている。このルータ８は交通管制センター内の中央装置４に接続されている。複数の路側通信機２には、ルータ８に接続されていない路側通信機２Ｂも含まれている。
中央装置４は、自身が管轄するエリアの交通信号機１及び路側通信機２とＬＡＮ（Local Area Network）を構成している。なお、中央装置４は、交通管制センターではなく道路上に設置してもよい。
中央装置４に有線通信回線７で接続されている路側通信機２Ａ（オンライン路側通信機）は、中央装置４の管轄するエリアに含まれる全ての路側通信機のうちの一部であり、中央装置４に対して有線通信回線７で接続されていない路側通信機２Ｂ（スタンドアローン路側通信機）も存在する。
図１では、交差点Ａ１〜Ａ５に設置された路側通信機２Ａが、オンライン路側通信機であり、他の交差点Ｂ１〜Ｂ５，Ｃ１〜Ｃ５，Ｄ１〜Ｄ５及びＥ１〜Ｅ５に設置された路側通信機２Ｂが、スタンドアローン路側通信機である。このように、全ての路側通信機をオンライン路側通信機としないことで、有線通信回線７の設置・維持コストを低減できる。
なお、オンライン路側通信機２Ａと、スタンドアローン路側通信機２Ｂと、を区別しない場合には、「路側通信機２」というものとする。
なお、オンライン路側通信機２Ａと、スタンドアローン路側通信機２Ｂと、を区別しない場合には、「路側通信機２」というものとする。
路側センサ６は、各交差点に流入する車両台数をカウントする等の目的で、管轄エリア内の道路の各所に設置されている。この路側センサ６は、直下を通行する車両５を超音波感知する車両感知器、或いは、道路の交通状況を時系列に撮影する監視カメラ等よりなり、感知情報や画像データは通信回線７を介して中央装置４に送信される。
なお、図１では、図示を簡略化するために、各交差点に信号灯器が１つだけ描写されているが、実際の各交差点には、互いに交差する道路の上り下り用として少なくとも４つの信号灯器が設置されている。
なお、図１では、図示を簡略化するために、各交差点に信号灯器が１つだけ描写されているが、実際の各交差点には、互いに交差する道路の上り下り用として少なくとも４つの信号灯器が設置されている。
高度道路交通システムにおいて、無線通信システムを構成する、複数の交差点それぞれに設置された複数の路側通信機（基地局）２は、その周囲を走行する車両の車載通信機（移動局）３との間で無線通信（路車間通信）が可能である。
また、各路側通信機２は、自己の送信波が到達する所定範囲内に位置する他の路側通信機２との間でも無線通信（路路間通信）が可能である。
また、各路側通信機２は、自己の送信波が到達する所定範囲内に位置する他の路側通信機２との間でも無線通信（路路間通信）が可能である。
同様に、無線通信システムを構成する車載通信機３は、路側通信機２との間で無線通信を行うとともに、キャリアセンス方式でその周辺を走行する他の車載通信機３との間で無線通信（車車間通信）が可能である。
オンライン路側通信機（基地局）２Ａは、図２（ａ）に示すように、無線通信のためのアンテナ２０が接続された無線通信部（ＲＦ部；ＰＨＹ部）２１と、有線通信回線７を介して中央装置４と通信するための有線通信部２２と、通信制御処理を行う通信処理装置２５と、を備えている。
通信処理装置２５は、制御部２３と、セキュリティ処理部２６と、記憶部２４と、を備えている。制御部２３は、無線通信及び有線通信の通信制御処理を行う。また、制御部２３は、後述する設定部２３Ａとして機能する。セキュリティ処理部２６は、通信パケットに対して所定のセキュリティ処理を施す。このセキュリティ処理部２６は、制御部２３の一機能部であってもよい。記憶部２４は、無線通信及び有線通信のために必要な情報を記憶する。
通信処理装置２５は、制御部２３と、セキュリティ処理部２６と、記憶部２４と、を備えている。制御部２３は、無線通信及び有線通信の通信制御処理を行う。また、制御部２３は、後述する設定部２３Ａとして機能する。セキュリティ処理部２６は、通信パケットに対して所定のセキュリティ処理を施す。このセキュリティ処理部２６は、制御部２３の一機能部であってもよい。記憶部２４は、無線通信及び有線通信のために必要な情報を記憶する。
通信処理装置２５は、その機能の一部又は全部が、ハードウェア回路によって構成されていてもよいし、その機能の一部又は全部が、コンピュータプログラムによって実現されていてもよい。通信処理装置２５の機能の一部又は全部がコンピュータプログラムによって実現される場合、通信処理装置２５（制御部２３、セキュリティ処理部２６）は、コンピュータを含み、コンピュータによって実行されるコンピュータプログラムは、記憶部２４に記憶される。
スタンドアローン路側通信機（基地局）２Ｂは、図２（ｂ）に示すように、オンライン路側通信機２Ａから、有線通信部２２を省略したものに相当する。
車載通信機（移動局）３は、無線通信のためのアンテナ３０が接続された無線通信部（ＲＦ部；ＰＨＹ部；受信部）３１と、通信制御処理を行う通信処理装置３５と、を備えている。
通信処理装置３５は、制御部３３と、セキュリティ処理部３６と、記憶部３４と、を備えている。制御部３３は、無線通信及び有線通信の通信制御処理を行う。また、セキュリティ処理部３６は、通信パケットに所定のセキュリティ処理を施す。このセキュリティ処理部３６は、制御部３３の一機能部であってもよい。記憶部３４は、無線通信及び有線通信のために必要な情報を記憶する。
車載通信機（移動局）３は、無線通信のためのアンテナ３０が接続された無線通信部（ＲＦ部；ＰＨＹ部；受信部）３１と、通信制御処理を行う通信処理装置３５と、を備えている。
通信処理装置３５は、制御部３３と、セキュリティ処理部３６と、記憶部３４と、を備えている。制御部３３は、無線通信及び有線通信の通信制御処理を行う。また、セキュリティ処理部３６は、通信パケットに所定のセキュリティ処理を施す。このセキュリティ処理部３６は、制御部３３の一機能部であってもよい。記憶部３４は、無線通信及び有線通信のために必要な情報を記憶する。
車載通信機３の通信処理装置３５は、その機能の一部又は全部が、ハードウェア回路によって構成されていてもよいし、その機能の一部又は全部が、コンピュータプログラムによって実現されていてもよい。通信処理装置３５の機能の一部又は全部がコンピュータプログラムによって実現される場合、通信処理装置３５（制御部３３、セキュリティ処理部３６）は、コンピュータを含み、コンピュータによって実行されるコンピュータプログラムは、記憶部３４に記憶される。
［無線フレーム］
図３（ａ）は、無線通信システムにおいて用いられる無線フレーム（スーパーフレーム）を示している。この無線フレームは、その時間軸方向の長さ（フレーム長）が１００ｍｓに設定されている。つまり、１秒間に１０フレームが発生する。
無線フレームは、例えば、路側通信機２が有するＧＰＳ受信機（図示省略）によって受信したＧＰＳ信号に含まれる１ＰＰＳ（１秒周期の信号）に基づいて生成される。
図３（ａ）は、無線通信システムにおいて用いられる無線フレーム（スーパーフレーム）を示している。この無線フレームは、その時間軸方向の長さ（フレーム長）が１００ｍｓに設定されている。つまり、１秒間に１０フレームが発生する。
無線フレームは、例えば、路側通信機２が有するＧＰＳ受信機（図示省略）によって受信したＧＰＳ信号に含まれる１ＰＰＳ（１秒周期の信号）に基づいて生成される。
一つの無線フレーム（１００ｍｓ）は、複数の路車間通信期間ＳＬ１と、複数の車車間通信期間ＳＬ２と、を含んで構成されている。
路車間通信期間ＳＬ１は、路側通信機２に割り当てられる路車間通信用のタイムスロット（路側通信機用送信期間）であり、この時間帯ＳＬ１においては、路側通信機２による無線送信が許容される。路車間通信期間ＳＬ１は、一つの無線フレーム（１００ｍｓ）内に最大１６個まで設定可能である。
路車間通信期間ＳＬ１は、路側通信機２に割り当てられる路車間通信用のタイムスロット（路側通信機用送信期間）であり、この時間帯ＳＬ１においては、路側通信機２による無線送信が許容される。路車間通信期間ＳＬ１は、一つの無線フレーム（１００ｍｓ）内に最大１６個まで設定可能である。
車車間通信期間ＳＬ２は、車載通信機３用のタイムスロット（車用通信期間）であり、この時間帯ＳＬ２は車載通信機３によるＣＳＭＡ方式による無線送信時間として開放するため、路側通信機２は車車間通信期間ＳＬ２では無線送信を行わない。
無線フレームに含まれている路車間通信期間ＳＬ１と、車車間通信期間ＳＬ２とは、時間軸方向に交互に配置されている。
路車間通信期間ＳＬ１には、それぞれスロット番号ｎ（＝１〜１６）が付されている。
それぞれの路側通信機２には、無線フレームに含まれる複数の路車間通信期間ＳＬ１のうちの、一つ又は複数の路車間通信期間ＳＬ１が送信期間として設定され、その他の路車間通信期間ＳＬ１は送信が禁止される。すなわち、路側通信機２にとっては、車車間通信期間ＳＬ２及び自機２に割り当てられていない路車間通信期間ＳＬ１は、送信禁止期間となる。
路車間通信期間ＳＬ１には、それぞれスロット番号ｎ（＝１〜１６）が付されている。
それぞれの路側通信機２には、無線フレームに含まれる複数の路車間通信期間ＳＬ１のうちの、一つ又は複数の路車間通信期間ＳＬ１が送信期間として設定され、その他の路車間通信期間ＳＬ１は送信が禁止される。すなわち、路側通信機２にとっては、車車間通信期間ＳＬ２及び自機２に割り当てられていない路車間通信期間ＳＬ１は、送信禁止期間となる。
図３（ｂ）では、路側通信機２にｎ＝４，５，６の３つの路車間通信期間ＳＬ１が送信期間として割り当てられている場合の送信禁止期間を示している。路側通信機２は、送信禁止期間以外の期間（送信期間）でデータ送信を行う。図３（ｂ）に示す送信期間は、周期的（１００ｍｓ毎）に発生する。つまり、路側通信機２は、１００ｍｓ毎に周期的に割り当てられる送信期間において、通信パケットを送信することができる。
一つの無線フレーム内において、一の路側通信機２に割り当てられる送信期間の数は任意である。また、一つの送信期間の期間長は、路車通信期間の期間長と等しくてもよいし、路車間通信期間よりも短くてもよい。また、一つの路車間通信期間ＳＬ１内に複数の送信期間が設定されてもよい。
［プロトコルスタック］
図４は、非特許文献１の標準規格に示す通信プロトコルスタックに、非特許文献２のガイドラインに示す拡張層（Extended Layer）ＥＬを加えたものを示している。
非特許文献１に規定されるプロトコルスタックは、レイヤ１（Ｌ１，物理層：Physical Layer）、レイヤ２（Ｌ２，データリンク層：Data Link Layer）、車車間・路車間共用通信制御情報層（ＩＶＣ−ＲＶＣ層：Inter-Vehicle Communication - Road to Vehicle Communication Layer）及びレイヤ７（Ｌ７，アプリケーション層：Application Layer）の４層構造である。各層及びアプリケーションＡＰは、システム管理のための情報を有するシステム管理にアクセスすることができる。
図４は、非特許文献１の標準規格に示す通信プロトコルスタックに、非特許文献２のガイドラインに示す拡張層（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）ともいう。
レイヤ２は、ＭＡＣ副層（Medium Access Control sublayer）と、ＬＬＣ副層（Logical Link Control sublayer）と、から構成される。なお、ＭＡＣ副層を、単に、ＭＡＣ層（Medium Access Control layer）ともいい、ＬＬＣ副層（Logical Link Control sublayer）を、単に、ＬＬＣ層（Logical Link Control layer）ともいう。
ＭＡＣ層は、無線チャネルの通信管理として、フレーム制御及び同報通信（ブロードキャスト）を行う。路側通信機２のＭＡＣ層は、自機２に割り当てられた送信期間において、通信パケットを送信する処理を行う。
ＬＬＣ層は、上位層のエンティティ間でパケット伝送を行うために、確認なしコネクションレス型通信のサービスを提供する。
ＬＬＣ層は、上位層のエンティティ間でパケット伝送を行うために、確認なしコネクションレス型通信のサービスを提供する。
車車間・路車間共用通信制御情報層（ＩＶＣ−ＲＶＣ層）は、車車間・路車間共用通信制御に必要な情報の生成と管理を行う。非特許文献１では、路路間通信は規定されていないため、本実施形態のように、路車間通信期間ＳＬ１において路路間通信を行う場合、車車間・路車間共用通信制御情報層（ＩＶＣ−ＲＶＣ層）において、路路間通信は、路車間通信の一種として取り扱われる。
レイヤ７は、アプリケーションＡＰに対して通信制御手段を提供するためのものである。アプリケーションＡＰは、送信される通信パケットに格納されるアプリケーションデータ（交通情報、車両情報など）をレイヤ７に与えるとともに、受信した通信パケットに格納されていたアプリケーションデータをレイヤ７から取得する。
非特許文献２に規定される拡張層ＥＬは、レイヤ７の上位層として存在し、アプリケーションＡＰとレイヤ７との間の通信機能を拡張するためのものである。
拡張層ＥＬは、アプリケーションＡＰに対してデータ伝送サービスを提供する。アプリケーションＡＰは、送信される通信パケットに格納されるアプリケーションデータ（交通情報、車両情報など）を含む送信要求（EL-BaseStationBroadcastData要求又はEL-MobileStationBroadcastData要求）を拡張層ＥＬに与える。データ伝送サービス提供のため、拡張層ＥＬは、レイヤ７以下の下位階層に対してデータ伝送要求（BaseStationBroadcast要求又はMobileStationBroadcastData要求）を出す。
拡張層ＥＬは、アプリケーションＡＰに対してデータ伝送サービスを提供する。アプリケーションＡＰは、送信される通信パケットに格納されるアプリケーションデータ（交通情報、車両情報など）を含む送信要求（EL-BaseStationBroadcastData要求又はEL-MobileStationBroadcastData要求）を拡張層ＥＬに与える。データ伝送サービス提供のため、拡張層ＥＬは、レイヤ７以下の下位階層に対してデータ伝送要求（BaseStationBroadcast要求又はMobileStationBroadcastData要求）を出す。
また、拡張層ＥＬは、アプリケーションＡＰから与えられたアプリケーションデータを分割し、分割データをレイヤ７に与えることができる。また、レイヤ７から受け取った分割データを結合させてアプリケーションＡＰに与えることができる。
なお、拡張層ＥＬは、レイヤ７とともに、セキュリティ管理ＳＥＣにアクセスすることができる。
なお、拡張層ＥＬは、レイヤ７とともに、セキュリティ管理ＳＥＣにアクセスすることができる。
図４に示す拡張層ＥＬ、レイヤ７、ＩＶＣ−ＲＶＣ層、レイヤ２、アプリケーションＡＰ、セキュリティ管理ＳＥＣ、及びシステム管理に相当する機能は、路側通信機２の通信処理装置２５及び車載通信機３の通信処理装置３５それぞれによって実行される。また、レイヤ１の機能は、路側通信機２の無線通信部２１及び車載通信機３の無線通信部３１それぞれによって実行される。
なお、通信処理装置２５のうち、図４のアプリケーションＡＰに相当する機能を、「アプリケーション部２５ａ」といい、図４のアプリケーションＡＰよりも下位の機能（拡張層ＥＬ、レイヤ７、ＩＶＣ−ＲＶＣ層、レイヤ２、セキュリティ管理ＳＥＣ、及びシステム管理）を、「通信処理部２５ｂ」ということがある。
また、通信処理装置３５のうち、図４のアプリケーションＡＰに相当する機能を、「アプリケーション部３５ａ」といい、図４のアプリケーションＡＰよりも下位の機能（拡張層ＥＬ、レイヤ７、ＩＶＣ−ＲＶＣ層、レイヤ２、セキュリティ管理ＳＥＣ、及びシステム管理）を、「通信処理部３５ｂ」ということがある。
また、通信処理装置３５のうち、図４のアプリケーションＡＰに相当する機能を、「アプリケーション部３５ａ」といい、図４のアプリケーションＡＰよりも下位の機能（拡張層ＥＬ、レイヤ７、ＩＶＣ−ＲＶＣ層、レイヤ２、セキュリティ管理ＳＥＣ、及びシステム管理）を、「通信処理部３５ｂ」ということがある。
アプリケーション部２５ａ，３５ａの機能は、コンピュータプログラムによって実現し、通信処理部２５ｂ，３５ｂの機能を、ハードウェアによって構成することができる。また、通信処理部２５ｂ，３５ｂの機能を、コンピュータプログラムによって実現してもよい。
本実施形態のアプリケーションＡＰ（アプリケーション部２５ａ，３５ａ）は、複数のアプリケーションＡＰ１，ＡＰ２を有している。図４では、複数のアプリケーションとして、第１アプリケーションＡＰ１と第２アプリケーションＡＰ２とを示した。
第１アプリケーションＡＰ１及び第２アプリケーションＡＰ２は、例えば、アプリケーションデータを提供するサービスプロバイダの違いに対応している。例えば、第１アプリケーションＡＰ１は、第１サービスプロバイダによるサービスを提供するためのアプリケーションであり、第２アプリケーションＡＰ２は、第２サービスプロバイダによるサービスを提供するためのアプリケーションである。
また、第１アプリケーションＡＰ１及び第２アプリケーションＡＰ２は、提供されるデータ（サービス）の内容の違いに対応していてもよい。例えば、第１アプリケーションＡＰ１は、交通情報を提供するためのアプリケーションであり、第２アプリケーションＡＰ２は、安全運転支援情報を提供するためのアプリケーションである。
さらに、第１アプリケーションＡＰ１及び第２アプリケーションＡＰ２は、例えば、通信形態の違いに対応していてもよい。例えば、第１アプリケーションＡＰ１は、路車間通信データを提供するためのアプリケーションであり、第２アプリケーションＡＰ２は、路路間通信データを提供するためのアプリケーションである。
［通信パケットと通信シーケンス］
図５は、路側通信機２及び車載通信機３によって送信される通信パケットの構成を示している。図５に示す通信パケットの構成は、セキュリティヘッダ及びセキュリティフッタを除き、非特許文献１，２に準拠したものである。
路車間通信、路路間通信、及び車車間通信で送信されるデータは、いずれも、図５に示す通信パケットの形式で送信される。
図５は、路側通信機２及び車載通信機３によって送信される通信パケットの構成を示している。図５に示す通信パケットの構成は、セキュリティヘッダ及びセキュリティフッタを除き、非特許文献１，２に準拠したものである。
路車間通信、路路間通信、及び車車間通信で送信されるデータは、いずれも、図５に示す通信パケットの形式で送信される。
通信パケットは、先頭にＰＨＹヘッダ（物理ヘッダ）を有している。ＰＨＹヘッダは、送信側の路側通信機２または車載通信機３のレイヤ１（物理層）によって、ＭＡＣ層から取得したＭＡＣフレーム（ＭＰＤＵ；MAC Protocol Data Unit）の前に付加される。
ＰＨＹヘッダは、受信側の通信機２，３におけるレイヤ１（物理層）において読み取られて、受信側のレイヤ１における通信制御処理に用いられる。なお、ＰＨＹヘッダを含む通信パケット全体が、ＰＰＤＵ（PHY Protocol Data Unit）である。ＰＨＹヘッダよりも後側のＭＡＣフレーム（ＭＰＤＵ）は、ＰＳＤＵ（PHY Service Data Unit）でもある。ＰＨＹヘッダの構成は、ＩＥＥＥ８０２．１１に準拠する。
ＰＨＹヘッダは、受信側の通信機２，３におけるレイヤ１（物理層）において読み取られて、受信側のレイヤ１における通信制御処理に用いられる。なお、ＰＨＹヘッダを含む通信パケット全体が、ＰＰＤＵ（PHY Protocol Data Unit）である。ＰＨＹヘッダよりも後側のＭＡＣフレーム（ＭＰＤＵ）は、ＰＳＤＵ（PHY Service Data Unit）でもある。ＰＨＹヘッダの構成は、ＩＥＥＥ８０２．１１に準拠する。
ＰＨＹヘッダに続いて、ＭＡＣ制御フィールド（ＭＡＣヘッダ）及びＬＬＣ制御フィールド（ＬＬＣヘッダ）が設けられている。ＭＡＣ制御フィールドは、送信側の通信機２，３のレイヤ２のＭＡＣ層によって、ＬＬＣ層から取得したＬＬＣフレーム（ＬＰＤＵ；LLC Protocol Data Unit）の前に付加される。
ＭＡＣ制御フィールドは、受信側の通信機２，３のレイヤ２のＭＡＣ層において読み取られて、受信側のＭＡＣ層における通信制御処理に用いられる。
ＭＡＣ制御フィールドよりも後側のＬＬＣフレーム（ＬＰＤＵ）は、ＭＳＤＵ（MAC Service Data Unit）でもある。
ＭＡＣ制御フィールドは、受信側の通信機２，３のレイヤ２のＭＡＣ層において読み取られて、受信側のＭＡＣ層における通信制御処理に用いられる。
ＭＡＣ制御フィールドよりも後側のＬＬＣフレーム（ＬＰＤＵ）は、ＭＳＤＵ（MAC Service Data Unit）でもある。
ＭＡＣ制御フィールドに続くＬＬＣ制御フィールドは、送信側の通信機２，３のレイヤ２のＬＬＣ層によって、ＩＶＣ−ＲＶＣ層から取得したＩＲフレーム（ＩＰＤＵ；IVC-RVC Protocol Data Unit）の前に付加される。
ＬＬＣ制御フィールドは、受信側の通信機２，３のレイヤ２のＬＬＣ層において読み取られて、受信側のＬＬＣ層における通信制御処理に用いられる。
また、ＬＬＣ制御フィールドよりも後側のＩＲフレーム（ＩＰＤＵ）は、ＬＳＤＵ（LLC Service Data Unit）でもある。
ＬＬＣ制御フィールドは、受信側の通信機２，３のレイヤ２のＬＬＣ層において読み取られて、受信側のＬＬＣ層における通信制御処理に用いられる。
また、ＬＬＣ制御フィールドよりも後側のＩＲフレーム（ＩＰＤＵ）は、ＬＳＤＵ（LLC Service Data Unit）でもある。
ＬＬＣ制御フィールドに続いて、ＩＲ制御フィールド（ＩＲヘッダ）が設けられている。ＩＲ制御フィールドは、送信側の通信機２，３のＩＶＣ−ＲＶＣ層によって、ＡＰフレーム（ＡＰＤＵ；Application Protocol Data Unit）の前に付加される。
ＩＲ制御フィールドは、受信側の通信機２，３のＩＶＣ−ＲＶＣ層において読み取られて、受信側のＩＶＣ−ＲＶＣ層における通信制御処理に用いられる。
ＩＲ制御フィールドよりも後側のＡＰフレーム（ＡＰＤＵ；Application Protocol Data Unit）は、ＩＳＤＵ（IVC-RVC Service Data Unit）でもある。
ＩＲ制御フィールドは、受信側の通信機２，３のＩＶＣ−ＲＶＣ層において読み取られて、受信側のＩＶＣ−ＲＶＣ層における通信制御処理に用いられる。
ＩＲ制御フィールドよりも後側のＡＰフレーム（ＡＰＤＵ；Application Protocol Data Unit）は、ＩＳＤＵ（IVC-RVC Service Data Unit）でもある。
ＩＲ制御フィールドに続いて、Ｌ７ヘッダが設けられている。Ｌ７ヘッダは、送信側の通信機２，３のレイヤ７によって、ＡＳＤＵ（Application Service Data Unit）の前に付加される。
Ｌ７ヘッダは、受信側の通信機２，３のレイヤ７において読み取られて、受信側のレイヤ７における通信制御処理に用いられる。
レイヤ７ヘッダよりも後側のＥＬフレーム（ＥＬ−ＰＤＵ；EL-Protocol Data Unit）は、ＡＳＤＵ（Application Service Data Unit）でもある。
Ｌ７ヘッダは、受信側の通信機２，３のレイヤ７において読み取られて、受信側のレイヤ７における通信制御処理に用いられる。
レイヤ７ヘッダよりも後側のＥＬフレーム（ＥＬ−ＰＤＵ；EL-Protocol Data Unit）は、ＡＳＤＵ（Application Service Data Unit）でもある。
Ｌ７ヘッダに続いて、ＥＬヘッダ（ＥＬ基地局ヘッダ）が設けられている。ＥＬヘッダは、送信側の通信機２，３の拡張層ＥＬによって、ＥＬ−ＳＤＵ（EL-Service Data Unit）の前に付加される。
ＥＬヘッダは、受信側の通信機２，３の拡張層ＥＬにおいて読み取られて、受信側の拡張層ＥＬにおける処理に用いられる。
ＥＬヘッダは、受信側の通信機２，３の拡張層ＥＬにおいて読み取られて、受信側の拡張層ＥＬにおける処理に用いられる。
ＥＬ−ＳＤＵは、セキュリティヘッダ、アプリケーションデータ、及びセキュリティフッタを有している。アプリケーションデータは、アプリケーションＡＰから通信処理部２５ｂ，３５ｂに与えられる。
アプリケーションデータは、受信側の通信機２，３のアプリケーションＡＰによって読み取られて、受信側のアプリケーションＡＰにおける処理に用いられる。
アプリケーションＡＰは、送信すべきデータを生成したり、受信したデータを読み取って自らの処理に用いたり、受信したデータを再送（転送）する処理を行うことができる。
アプリケーションＡＰは、送信すべきデータを生成したり、受信したデータを読み取って自らの処理に用いたり、受信したデータを再送（転送）する処理を行うことができる。
図６に示すように、送信側の通信機が基地局２である場合、送信側のアプリケーションＡＰは、アプリケーションデータの送信要求を、「EL-BaseStationBroadcastData要求」として、拡張層ＥＬに出力する。EL-BaseStationBroadcastData要求には、アプリケーションデータ及びその他の情報（例えば図７参照）が含まれる。
送信側の拡張層ＥＬは、送信要求に含まれるアプリケーションＡＰからアプリケーションデータを受け取ると、必要に応じて、セキュリティ処理をセキュリティ管理ＳＥＣに実行させる（図６の「Security要求」）。
送信側のセキュリティ管理（セキュリティ処理部）ＳＥＣでは、拡張層ＥＬから受け取ったアンセキュアなアプリケーションデータに対して、セキュリティ処理を行って、セキュアなアプリケーションデータを生成する。
送信側のセキュリティ管理（セキュリティ処理部）ＳＥＣでは、拡張層ＥＬから受け取ったアンセキュアなアプリケーションデータに対して、セキュリティ処理を行って、セキュアなアプリケーションデータを生成する。
セキュリティ管理ＳＥＣにおいて、アンセキュアなアプリケーションデータをセキュアなアプリケーションデータにする処理（セキュリティ処理）には、暗号化処理、署名処理等の処理が含まれる（ただし、非特許文献１，２では規定されていない）。
セキュリティ管理は、セキュリティ処理が施されたセキュアなアプリケーションデータ（ＥＬ−ＳＤＵ）（図５参照）を、拡張層ＥＬに戻す（図６の「Security応答」）。
セキュリティ管理は、セキュリティ処理が施されたセキュアなアプリケーションデータ（ＥＬ−ＳＤＵ）（図５参照）を、拡張層ＥＬに戻す（図６の「Security応答」）。
送信側の拡張層ＥＬは、セキュアなアプリケーションデータにＥＬヘッダを付加してアプリケーションデータ（ＥＬ−ＰＤＵ）（図５参照）を生成する。
拡張層ＥＬは、図６に示すように、レイヤ７への送信要求として、「BaseStationBroadcastData要求」を、ＥＬ−ＰＤＵ毎（図５参照）に生成する。BaseStationBroadcastData要求には、ＥＬ−ＰＤＵ（ＡＳＤＵ）及びその他の情報が含まれる。
送信側のレイヤ７は、ＥＬ−ＰＤＵ（ＡＳＤＵ）にＬ７ヘッダを付加して、ＡＰＤＵを生成する。
続いて、送信側のレイヤ７よりも下位の層は、順次処理を行い、周期的（１００ｍｓ）に割り当てられる送信期間において、通信パケットを送出する。
拡張層ＥＬは、図６に示すように、レイヤ７への送信要求として、「BaseStationBroadcastData要求」を、ＥＬ−ＰＤＵ毎（図５参照）に生成する。BaseStationBroadcastData要求には、ＥＬ−ＰＤＵ（ＡＳＤＵ）及びその他の情報が含まれる。
送信側のレイヤ７は、ＥＬ−ＰＤＵ（ＡＳＤＵ）にＬ７ヘッダを付加して、ＡＰＤＵを生成する。
続いて、送信側のレイヤ７よりも下位の層は、順次処理を行い、周期的（１００ｍｓ）に割り当てられる送信期間において、通信パケットを送出する。
そして、受信側の通信機２，３のレイヤ７は、下位レイヤからＡＰＤＵを受け取ると、図６に示すように、そのＡＰＤＵに含まれるＡＳＤＵ（ＥＬ−ＰＤＵ）を拡張層ＥＬに受け取らせるための「BaseStationBroadcastData表示」を生成し、拡張層ＥＬに与える。
受信側の拡張層ＥＬは、ＥＬ−ＰＤＵを受け取った場合、ＥＬ−ＰＤＵからＥＬヘッダ（付加情報）を除き、ＥＬ−ＳＤＵ（図５参照）を生成する。
受信側の拡張層ＥＬは、ＥＬ−ＰＤＵを受け取った場合、ＥＬ−ＰＤＵからＥＬヘッダ（付加情報）を除き、ＥＬ−ＳＤＵ（図５参照）を生成する。
受信側の拡張層ＥＬは、ＥＬ−ＳＤＵがセキュアなアプリケーションデータである場合、セキュアなアプリケーションデータ（ＥＬ−ＳＤＵ）を、セキュリティ管理ＳＥＣに渡す（図６の「Unsecurity要求」）。セキュリティ管理ＳＥＣは、セキュアなアプリケーションデータに対して、アンセキュリティ処理（デコード処理）を行って、アンセキュアなアプリケーションデータ（ＥＬ−ＳＤＵ）に戻す（図６の「Unsecurity応答」）。
拡張層ＥＬは、セキュリティ管理ＳＥＣからアンセキュアなアプリケーションデータ（ＥＬ−ＳＤＵ）を受け取ると、アンセキュアなアプリケーションデータ（ＥＬ−ＳＤＵ）を、アプリケーションＡＰに渡すため、受信通知を生成する。
拡張層ＥＬは、セキュリティ管理ＳＥＣからアンセキュアなアプリケーションデータ（ＥＬ−ＳＤＵ）を受け取ると、アンセキュアなアプリケーションデータ（ＥＬ−ＳＤＵ）を、アプリケーションＡＰに渡すため、受信通知を生成する。
拡張層ＥＬは、アプリケーションデータ（ＥＬ−ＳＤＵ）の受信通知として、「EL-BaseStationBroadcastData表示」を生成し、それをアプリケーションＡＰに与える。EL-BaseStationBroadcastData表示には、アプリケーションデータ（ＥＬ−ＳＤＵ）及びその他の情報（後述）が含まれる。
［EL-BaseStationBroadcastData要求］
図７は、EL-BaseStationBroadcastData要求に含まれる情報を示す説明図である。
非特許文献２に規定されたEL-BaseStationBroadcastData要求には、アプリケーションデータ（ApplicationData）のほか、
（１）データ関連情報（DataAssociatedInformation）
（２）アプリケーション関連情報（ApplicationAssociatedInformation）
（３）セキュリティインフォメーション（SecurityInformation）
が含まれている。
図７は、EL-BaseStationBroadcastData要求に含まれる情報を示す説明図である。
非特許文献２に規定されたEL-BaseStationBroadcastData要求には、アプリケーションデータ（ApplicationData）のほか、
（１）データ関連情報（DataAssociatedInformation）
（２）アプリケーション関連情報（ApplicationAssociatedInformation）
（３）セキュリティインフォメーション（SecurityInformation）
が含まれている。
非特許文献２の規定では、データ関連情報は、基地局ＩＤ（BaseStationID）、データ順番（DataSequence）、及びデータ総数（DataTotalNumber）を有している。
基地局ＩＤは、路車間通信及び路路間通信における情報の送信元となる基地局（路側通信機２）を識別するＩＤ情報である。
データ順番は、アプリケーションデータの順番を示す情報（データ順番情報）である。
データ総数は、アプリケーションデータの総数を示す情報（データ総数情報）である。
基地局ＩＤは、路車間通信及び路路間通信における情報の送信元となる基地局（路側通信機２）を識別するＩＤ情報である。
データ順番は、アプリケーションデータの順番を示す情報（データ順番情報）である。
データ総数は、アプリケーションデータの総数を示す情報（データ総数情報）である。
また、データ順番及びデータ総数は、１つの送信周期（制御周期）、例えば１００ｍｓの無線フレーム内で送信されるアプリケーションデータの順番及び総数を示している。
図７に示すように、EL-BaseStationBroadcastData要求に含まれるデータ関連情報は、拡張層ＥＬにおいて生成されるＥＬ−ＰＤＵ（ＡＳＤＵ）のＥＬヘッダ内に格納される。
図７に示すように、EL-BaseStationBroadcastData要求に含まれるデータ関連情報は、拡張層ＥＬにおいて生成されるＥＬ−ＰＤＵ（ＡＳＤＵ）のＥＬヘッダ内に格納される。
また、非特許文献３の規定では、アプリケーション関連情報は、「通信種別」に関する情報を有している。この通信種別は、路車間通信及び路路間通信における情報の送信先（宛先）を識別する情報である。具体的に、通信種別は、送信側の通信機と受信側の通信機との組合せを示す。
本実施形態では、送信側の通信機と受信側の通信機との組合せのうち、路側通信機２から車載通信機３への路車間通信（以下、「ＲＶ」（Road to Vehicle）ともいう）と、路側通信機２から他の路側通信機２への路路間通信（以下、「ＲＲ」（Road to Road）ともいう）と、について説明する。
本実施形態では、送信側の通信機と受信側の通信機との組合せのうち、路側通信機２から車載通信機３への路車間通信（以下、「ＲＶ」（Road to Vehicle）ともいう）と、路側通信機２から他の路側通信機２への路路間通信（以下、「ＲＲ」（Road to Road）ともいう）と、について説明する。
アプリケーション関連情報に含まれる通信種別は、拡張層ＥＬからレイヤ７への送信要求であるBaseStationBroadcastData要求にも含まれる。そして、通信種別は、図７に示すように、レイヤ７において生成されるＡＰＤＵ（ＩＳＤＵ）のＬ７ヘッダ内に格納される。
本実施形態のセキュリティインフォメーションは、セキュリティ処理の実行単位を示す情報を有している。具体的には、同一の実行単位に含まれる各データの番号（順番）と、当該実行単位における最終データの番号との組合せによって実行単位が指定されている（図８及び図９参照）。このようにデータ番号と最終データ番号とによってセキュリティ処理の実行単位の指定する方法は、例えば、特許文献１（段落［００９６］、図１７等参照）において公知である。
セキュリティインフォメーションに含まれるセキュリティ処理の実行単位の情報は、セキュリティ管理ＳＥＣに受け渡される。セキュリティ管理ＳＥＣは、セキュリティインフォメーションのセキュリティ処理の実行単位をもとにセキュリティ処理を実行する。なお、セキュリティ管理ＳＥＣでは、セキュリティ処理を施した通信パケットにセキュリティヘッダを付与する。このセキュリティヘッダには、セキュリティ処理の実行単位を指定するために用いた、データ番号と最終データ番号とが格納される。
図８及び図９は、前述したデータ関連情報、アプリケーション関連情報、及びセキュリティインフォメーションにおける通信パケットの指定形式をテーブルで示している。いずれの図においても、１つの制御周期に６個の通信パケット（データ）が送信されるものとする。
図８及び図９のアプリケーション関連情報には、通信種別として、１番目の通信パケットから４番目の通信パケットにＲＶ（路車間通信）が指定され、５番目及び６番目の通信パケットにＲＲ（路路間通信）が指定されている。
図８及び図９のアプリケーション関連情報には、通信種別として、１番目の通信パケットから４番目の通信パケットにＲＶ（路車間通信）が指定され、５番目及び６番目の通信パケットにＲＲ（路路間通信）が指定されている。
一方、データ関連情報には、１つの制御周期に送信されるデータ順番及びデータ総数が通信種別毎に指定されている。具体的に、ＲＶ用の通信パケットは、（データ順番／データ総数）の形式で、１／４〜４／４のように指定され、ＲＲ用の通信パケットは、（データ順番／データ総数）の形式で、１／２，２／２のように指定されている。
これに対して、セキュリティインフォメーションには、セキュリティ処理の実行単位が、各通信パケットのデータ番号と実行単位内の最終データ番号との組合せで、（データ番号／最終データ番号）の形式で指定されている。具体的に、図８及び図９に示すＲＶ用の４つの通信パケットは、データ番号が「０」から始まり、０番から３番までがセキュリティ処理の実行単位となっている。したがって、セキュリティ処理の実行単位は、０／３，１／３，２／３，３／３のように指定されている。
また、図８に示すＲＲ用の２つの通信パケットは、セキュリティ処理の実行単位がそれぞれ０／０、０／０のように指定されている。つまり、セキュリティ処理の実行単位が「通信パケット毎」に設定されている。
また、図９に示すＲＲ用の２つの通信パケットは、セキュリティ処理の実行単位が０／１、１／１のように指定されている。この２つの通信パケットは宛先が同一となっている。したがって、セキュリティ処理の実行単位が「宛先毎」に設定されている。
ＲＲ用の通信パケットに対して、図８及び図９のいずれの態様でセキュリティ処理を実行するかは、後述する所定の条件により判別する。
また、図９に示すＲＲ用の２つの通信パケットは、セキュリティ処理の実行単位が０／１、１／１のように指定されている。この２つの通信パケットは宛先が同一となっている。したがって、セキュリティ処理の実行単位が「宛先毎」に設定されている。
ＲＲ用の通信パケットに対して、図８及び図９のいずれの態様でセキュリティ処理を実行するかは、後述する所定の条件により判別する。
［セキュリティ処理］
次に具体的なセキュリティ処理について説明する。
本実施形態では、車載通信機３宛の通信パケットと、路側通信機２宛の通信パケットとは異なる基準でセキュリティ処理の実行単位が設定される。
具体的には、路車間通信ＲＶの場合、車載通信機３宛の通信パケットは「サービス毎」にセキュリティ処理が実行される。サービス毎とは、例えば、信号情報や安全運転支援情報等の車載通信機３に提供する情報（又は情報群）毎である。図８及び図９に示す例では、１つの制御周期内の路車間通信ＲＶ用の４つの通信パケットは、いずれも同一サービスに用いられるものであり、同一の（又は互いに関連する）セキュリティ処理が実行される。ただし、これらの情報が互いに異なるサービスに関するものであれば、それぞれ個々にセキュリティ処理の実行単位が指定されることになる。
次に具体的なセキュリティ処理について説明する。
本実施形態では、車載通信機３宛の通信パケットと、路側通信機２宛の通信パケットとは異なる基準でセキュリティ処理の実行単位が設定される。
具体的には、路車間通信ＲＶの場合、車載通信機３宛の通信パケットは「サービス毎」にセキュリティ処理が実行される。サービス毎とは、例えば、信号情報や安全運転支援情報等の車載通信機３に提供する情報（又は情報群）毎である。図８及び図９に示す例では、１つの制御周期内の路車間通信ＲＶ用の４つの通信パケットは、いずれも同一サービスに用いられるものであり、同一の（又は互いに関連する）セキュリティ処理が実行される。ただし、これらの情報が互いに異なるサービスに関するものであれば、それぞれ個々にセキュリティ処理の実行単位が指定されることになる。
これに対して、路路間通信ＲＲの場合、路側通信機２宛の通信パケットは、「通信パケット毎」又は「宛先毎」にセキュリティ処理の実行単位が設定される。
セキュリティ処理の実行単位が「通信パケット毎」の場合、図８に示すように、ＲＲ用の通信パケットそれぞれにセキュリティ処理が実行される。
セキュリティ処理の実行単位が「宛先毎」の場合、図９に示すように、同一の宛先のＲＲ用の通信パケットに同一の又は互いに関連するセキュリティ処理が実行される。例えば、図１５に示すように、互いに隣接して複数の路側通信機２が配置され、ある路側通信機Ａが、他の路側通信機Ｂ宛に複数の通信パケットを送信する場合、これらの通信パケットには同一の又は関連するセキュリティ処理が行われる。図９には、路路間通信ＲＲ用の２つの通信パケットの宛先がいずれも「Ｂ」の路側通信機２であることを示している。なお、図８に示す例においても、路路間通信ＲＲ用の２つの通信パケットの宛先がいずれも「Ｂ」とされているが、セキュリティ処理の実行単位は、「宛先毎」ではなく「通信パケット毎」とされている。この実行単位の判別は後述する所定の条件により行われる。
セキュリティ処理の実行単位が「通信パケット毎」の場合、図８に示すように、ＲＲ用の通信パケットそれぞれにセキュリティ処理が実行される。
セキュリティ処理の実行単位が「宛先毎」の場合、図９に示すように、同一の宛先のＲＲ用の通信パケットに同一の又は互いに関連するセキュリティ処理が実行される。例えば、図１５に示すように、互いに隣接して複数の路側通信機２が配置され、ある路側通信機Ａが、他の路側通信機Ｂ宛に複数の通信パケットを送信する場合、これらの通信パケットには同一の又は関連するセキュリティ処理が行われる。図９には、路路間通信ＲＲ用の２つの通信パケットの宛先がいずれも「Ｂ」の路側通信機２であることを示している。なお、図８に示す例においても、路路間通信ＲＲ用の２つの通信パケットの宛先がいずれも「Ｂ」とされているが、セキュリティ処理の実行単位は、「宛先毎」ではなく「通信パケット毎」とされている。この実行単位の判別は後述する所定の条件により行われる。
以上のように、路車間通信ＲＶと路路間通信ＲＲとは、セキュリティ処理の実行単位が異なる基準により設定される。ただし、いずれの通信の場合もセキュリティ処理の実行単位が複数の通信パケットに及ぶ場合と、単一の通信パケットになる場合とがある。そして、本実施形態では、セキュリティ処理の実行単位が複数の通信パケットに及ぶ場合と、単一の通信パケットになる場合とで、セキュリティ処理の方法が異なっている。以下、その詳細について説明する。
図１０（ａ）は、図８及び図９における路車間通信ＲＶに適用されるセキュリティ処理を示している。この場合、（データ番号／最終データ番号）の形式で指定された同一のサービスに係る複数の通信パケット０／３〜３／３が、セキュリティ処理の実行単位とされている。このセキュリティ処理においては、複数の通信パケットのうちの先頭の通信パケットに電子署名が付与され、後続パケットには電子署名が省略されている。ただし、先頭パケットの電子署名には、ハッシュ関数等を用いて生成された後続パケットのダイジェスト（ハッシュ値）のリストが付加されている。
より具体的には、図１１に示すように、先頭パケットには、アプリケーションデータとハッシュ値リストと電子署名と公開鍵証明書とが含まれている。ハッシュ値リストは、後続パケットのアプリケーションデータのハッシュ値が登録され、リスト化されている。電子署名は、先頭パケットのアプリケーションデータとハッシュ値リストと公開鍵暗号方式における秘密鍵とから生成したものである。なお、電子署名を生成するためのアプリケーションデータは、当該アプリケーションデータの全部であってもよいし一部であってもよい。あるいは、アプリケーションデータのハッシュ値（ダイジェスト）であってもよい。また、電子署名を生成するためのハッシュ値リストも、当該ハッシュ値リストのハッシュ値（ダイジェスト）であってもよい。当該アプリケーションデータと当該ハッシュ値リストをハッシュ化したハッシュ値以上のセキュリティ処理は、通信処理装置２５のセキュリティ処理部２６の機能により行われる。
送信側の路側通信機２は、公開鍵証明書、電子署名、アプリケーションデータ、及びハッシュ値リストを含む先頭パケットと、アプリケーションデータを含む後続パケットとを受信側の車載通信機３（又は路側通信機２）に送信する。電子署名に使用した公開鍵暗号方式の公開鍵（公開鍵証明書）は、先頭パケットとは別に受信側の通信機２，３に提供してもよい。なお、ここでは詳細に説明しないが、電子署名、アプリケーションデータ、及びハッシュ値リスト等は、例えば共通鍵暗号方式による共通鍵を用いて暗号化してもよい。これによりこれらの情報の漏洩を防止することができる。また、路路間通信用途などではユニキャスト通信が想定されるため、この暗号化に使用された共通鍵を、受信側の通信機２，３が所有する公開鍵暗号方式の公開鍵により暗号化して送信してもよい。暗号化された共通鍵は、秘密鍵を所有する受信側の通信機２，３しか復号化できないので、当該共通鍵の漏洩を防止することができる。また、電子署名、アプリケーションデータ、及びハッシュリストと共通鍵とを用いてＭＡＣ（メッセージ認証コード）を生成し、これを各パケットに格納してもよい。
以上の先頭パケットを受信した受信側の通信機２，３は、セキュリティ処理部２６，３６の機能により、公開鍵暗号方式における公開鍵と先頭パケットに含まれるアプリケーションデータ及びハッシュ値リストとから電子署名を検証する。検証が成功すれば、それらのデータは、正当な路側通信機２から送信されたものであること（真正性）を証明できる。
一方、後続パケットを受信した受信側の通信機２，３は、後続パケットに含まれるアプリケーションデータのハッシュ値を求める。そして、そのハッシュ値を、先頭パケットに含まれるハッシュ値リストと照合する。そして、当該ハッシュ値がハッシュ値リストに登録されたものであれば、後続パケットのアプリケーションデータは、正当な路側通信機２から送信されたものであること（真正性）を間接的に証明することができる。
以上のセキュリティ処理の例では、複数の通信パケットのうちの先頭の通信パケットに電子署名が付与され、後続パケットには電子署名が省略されるので、電子署名に要するセキュリティ処理部２６の演算負荷を軽減することができる。しかも、後続パケットのハッシュ値を先頭パケットにリスト化して登録し、そのリストを先頭パケットの電子署名に加えることで、後続パケットについても電子署名と略同等のセキュリティ機能（真正性）を担保することができる。
図１０（ｂ）（１）は、図８における路路間通信ＲＲに適用されるセキュリティ処理を示している。この場合、路路間通信ＲＲ用の２つの通信パケット０／０，０／０は、それぞれ個別にセキュリティ処理が実行される。つまり、セキュリティ処理の実行単位が通信パケット毎に設定されている。また、２つの通信パケットは、宛先が同一である。このセキュリティ処理では、通信パケットのそれぞれに電子署名が付与される。
より具体的には、図１２に示すように、通信パケットには、アプリケーションデータと電子署名とが含まれている。電子署名は、アプリケーションデータと公開鍵暗号方式における秘密鍵とから生成したものである。なお、電子署名を生成するためのアプリケーションデータは、当該アプリケーションデータの全部であってもよいし一部であってもよい。あるいはアプリケーションデータのハッシュ値（ダイジェスト）であってもよい。
送信側の路側通信機２は、電子署名及びアプリケーションデータを含む通信パケットを、受信側の車載通信機３又は路側通信機２に送信する。電子署名に使用した公開鍵暗号方式の公開鍵（公開鍵証明書）も先頭パケットに格納して送信してもよい。なお、ここでは詳細に説明しないが、電子署名及びアプリケーションデータは、共通鍵暗号方式によって暗号化してもよく、この場合、これらの情報の漏洩を防止することができる。また、路路間通信用途などではユニキャスト通信が想定されるため、この暗号化に使用した共通鍵を、受信側の通信機２，３が所有する公開鍵暗号方式における公開鍵により暗号化して送信してもよい。暗号化された共通鍵は、公開鍵暗号方式における秘密鍵を所有する受信側の通信機しか復号化できないので、当該共通鍵の漏洩を防止することができる。
以上の通信パケットを受信した通信機２，３は、公開鍵暗号方式における公開鍵と通信パケットに含まれるアプリケーションデータとから電子署名を検証する。検証が成功すれば、それらのデータは、正当な路側通信機２から送信されたものであること（真正性）を証明できる。
図１０（ａ）に示すセキュリティ処理の場合、受信側の車載通信機３は、先頭パケットを受信しないと、後続パケットの真正性を検証することができない。すなわち、適切なデコード処理を行うことができない。
これに対して図１０（ｂ）（１）に示すセキュリティ処理は、各通信パケット毎に実行されるので、連続して送信される複数の通信パケットのうちいずれかが欠けていたとしても、受信されたものについては確実にデコード処理を行うことができる。したがって、宛先の異なる複数の通信パケットが送信された場合、受信側の路側通信機２は、少なくとも自機宛の通信パケットを受信すればその他の通信パケットを受信しなくてもデコード処理を行うことができる。また、路路間通信ＲＲは、路車間通信ＲＶに比べて頻度が少ないので、全ての通信パケットに電子署名が付与されていたとしてもセキュリティ処理部２６の処理負担は少なく、また、通信の遅延に対する制限が緩やかであるため、電子署名の処理に時間がかかっても許容される。したがって、路路間通信ＲＲにおいては通信パケット毎にセキュリティ処理を施したとしてもそれほど問題は生じない。
これに対して図１０（ｂ）（１）に示すセキュリティ処理は、各通信パケット毎に実行されるので、連続して送信される複数の通信パケットのうちいずれかが欠けていたとしても、受信されたものについては確実にデコード処理を行うことができる。したがって、宛先の異なる複数の通信パケットが送信された場合、受信側の路側通信機２は、少なくとも自機宛の通信パケットを受信すればその他の通信パケットを受信しなくてもデコード処理を行うことができる。また、路路間通信ＲＲは、路車間通信ＲＶに比べて頻度が少ないので、全ての通信パケットに電子署名が付与されていたとしてもセキュリティ処理部２６の処理負担は少なく、また、通信の遅延に対する制限が緩やかであるため、電子署名の処理に時間がかかっても許容される。したがって、路路間通信ＲＲにおいては通信パケット毎にセキュリティ処理を施したとしてもそれほど問題は生じない。
一方、図１０（ｂ）（２）に示すセキュリティ処理は、宛先が同一の複数の通信パケット０／１，１／１に対して、図１１と同様のセキュリティ処理を施すものである。したがって、この場合、例えば、宛先となる路側通信機２は、先頭パケットと後続パケットとの双方を受信しなければ適切なデコードが行えない。しかしながら、先頭パケットのみに電子署名を付加すればよいので、セキュリティ処理部２６による処理負担を軽減することができる。さらに、先頭パケットの電子署名には、後続パケットのアプリケーションデータのハッシュ値を格納したハッシュ値リストが含まれるので、後続パケットについても電子署名と略同等のセキュリティ機能（真正性）を担保することができる。
また、セキュリティ処理の実行単位が宛先毎であるので、受信側の路側通信機２は、他機宛の通信パケットを受信できなくても、自機宛の通信パケットを受信できればそのデコード処理が可能であり、自機に必要な情報を好適に利用することができる。
また、セキュリティ処理の実行単位が宛先毎であるので、受信側の路側通信機２は、他機宛の通信パケットを受信できなくても、自機宛の通信パケットを受信できればそのデコード処理が可能であり、自機に必要な情報を好適に利用することができる。
［セキュリティ処理の実行単位設定処理］
次に、路側通信機２が送信する通信パケットのセキュリティ処理の実行単位、すなわち、路車間通信に適用される「サービス毎」の実行単位と、路路間通信に適用される「通信パケット毎」又は「宛先毎」の実行単位とを設定する手順について説明する。この設定処理は、図２に示す制御部２３の設定部２３Ａが行う処理である。また、図４に示すアプリケーション部２５ａが行う処理でもある。
次に、路側通信機２が送信する通信パケットのセキュリティ処理の実行単位、すなわち、路車間通信に適用される「サービス毎」の実行単位と、路路間通信に適用される「通信パケット毎」又は「宛先毎」の実行単位とを設定する手順について説明する。この設定処理は、図２に示す制御部２３の設定部２３Ａが行う処理である。また、図４に示すアプリケーション部２５ａが行う処理でもある。
図１３に示すように、設定部２３Ａは、ステップＳ１において、送信しようとする通信パケットの通信種別を判別する。
通信種別が路車間通信ＲＶである場合、ステップＳ２において、設定部２３Ａは、セキュリティ処理の実行単位を「サービス毎」に設定する。
なお、路車間通信ＲＶにおいて、通信対象となる車両は、一般車両と、緊急車両（パトカー、消防車、及び救急車等）のような特定車両とに分けることができる。そして、特定車両には、一般車両とは異なるサービスが提供されることが想定される。したがって、セキュリティ処理の実行単位は、通信対象の車両種別（一般車両、特定車両）に応じて設定することもでき、これによってサービス毎に実行単位を設定するのと実質的に同等の処理を行うことができる。また、一般車両と特定車両とで、セキュリティ処理の内容（例えば、暗号強度）を変えることもできる。例えば、パトカー等の緊急車両に提供するサービスは、一般車両に提供するサービスに比べて高い秘匿性が要求されることが想定されるので、この場合には、暗号強度を高めたセキュリティ処理を施すことが好ましい。
通信種別が路車間通信ＲＶである場合、ステップＳ２において、設定部２３Ａは、セキュリティ処理の実行単位を「サービス毎」に設定する。
なお、路車間通信ＲＶにおいて、通信対象となる車両は、一般車両と、緊急車両（パトカー、消防車、及び救急車等）のような特定車両とに分けることができる。そして、特定車両には、一般車両とは異なるサービスが提供されることが想定される。したがって、セキュリティ処理の実行単位は、通信対象の車両種別（一般車両、特定車両）に応じて設定することもでき、これによってサービス毎に実行単位を設定するのと実質的に同等の処理を行うことができる。また、一般車両と特定車両とで、セキュリティ処理の内容（例えば、暗号強度）を変えることもできる。例えば、パトカー等の緊急車両に提供するサービスは、一般車両に提供するサービスに比べて高い秘匿性が要求されることが想定されるので、この場合には、暗号強度を高めたセキュリティ処理を施すことが好ましい。
一方、通信種別が路路間通信ＲＲである場合、ステップＳ３において、さらにセキュリティ処理の実行単位をさらに細分して判別する処理を行う。
図１４は、セキュリティ処理の実行単位の細分判別処理手順を示すフローチャートである。ステップＳ１１において、設定部２３Ａは、通信環境（通信状況）の良否を判別する。例えば、自機が受信する通信パケットの到達率が所定の閾値以上の時は、通信環境が良好であるとしてステップＳ１２に処理を進め、所定の閾値未満のときは、通信環境が悪い状況であるため、ステップＳ１３に処理を進める。
図１４は、セキュリティ処理の実行単位の細分判別処理手順を示すフローチャートである。ステップＳ１１において、設定部２３Ａは、通信環境（通信状況）の良否を判別する。例えば、自機が受信する通信パケットの到達率が所定の閾値以上の時は、通信環境が良好であるとしてステップＳ１２に処理を進め、所定の閾値未満のときは、通信環境が悪い状況であるため、ステップＳ１３に処理を進める。
ステップＳ１２において、設定部２３Ａは、宛先の路側通信機２に複数の端末が接続されているか否かを判別する。複数の端末としては、交通信号機１や路側センサ６等がある。宛先の路側通信機２に複数の端末が接続されている場合、各端末には、送信側の路側通信機２からの通信パケットにより情報が提供される。このとき、上述のように複数の通信パケットのセキュリティ処理の実行単位が「宛先毎」に設定されていると、複数の通信パケットのうちのいずれかを受信できないと、その宛先の全ての通信パケットをデコード処理できず、全ての端末へ情報を提供できなくなる可能性がある。そのため、このようなケースでは、セキュリティ処理の実行単位を「通信パケット毎」に設定する。
また、ステップＳ１１において通信環境が悪いと判断された場合にも、受信側の路側通信機２が通信パケットの受信に失敗する可能性が高くなる。このような場合にセキュリティ処理の実行単位が「宛先毎」に設定されていたとすると、複数の通信パケットのうちのいずれかを受信できないと、その宛先の全ての通信パケットをデコード処理できず、情報を取得できなくなる可能性がある。そのため、このような場合もセキュリティ処理の実行単位を通信パケット単位とする。
他方、通信環境が良好であり、宛先の路側通信機２に複数の端末が接続されていない場合には、設定部２３Ａは、ステップＳ１４において、セキュリティ処理の実行単位を「宛先毎」に設定する。この場合、宛先となる通信機２は、通信パケットの受信に失敗する可能性が少なく、しかも受信に失敗したとしても接続されている端末に与える影響も小さいので、宛先毎に複数の通信パケットをセキュリティ処理することができ、これによってセキュリティ処理に要する負担を軽減することができる。
図１３に戻り、設定部２３Ａは、ステップＳ４において、同一の制御周期内の全ての通信パケットについてセキュリティ処理の実行単位を設定したか否かを判別し、全ての通信パケットについて設定が終了していれば処理を終了する。
路側通信機２は、例えば、自機宛ではない通信パケットについては、受信したとしてもデコード等のセキュリティ処理を行わず、そのまま破棄するように構成してもよい。
例えば、図１５に示すように、路側通信機Ａは、その周囲にある他の路側通信機Ｂ〜Ｅとの間で通信パケットの送受信が可能であるが、他の路側通信機Ｂ〜Ｅは、路側通信機Ａ以外の路側通信機から送信された通信パケットを必要としない場合もある。
例えば、図１５に示すように、路側通信機Ａは、その周囲にある他の路側通信機Ｂ〜Ｅとの間で通信パケットの送受信が可能であるが、他の路側通信機Ｂ〜Ｅは、路側通信機Ａ以外の路側通信機から送信された通信パケットを必要としない場合もある。
このような場合に、路側通信機Ｂ〜Ｅが、受信した全ての通信パケットに対してデコード処理を行ったとすると、不要な通信パケットに対して無駄な処理を行うこととなり、効率が悪い。そのため、本実施形態では、各路側通信機Ｂ〜Ｅの記憶部２４には、受信の必要がある送信元の他の路側通信機が予め登録されている。例えば、受信の必要がある送信元を登録した受信テーブルが記憶部２４に記憶される。そして、各路側通信機Ｂ〜Ｅは、通信パケットを受信したときに、そのパケットに含まれる送信元の情報（ＥＬヘッダに格納される基地局ＩＤ（図７参照））を確認し、受信テーブルを参照してその送信元からの通信パケットの受信要否を確認する。そして、受信の必要が無い通信パケットを受信した場合にはデコード処理（復号化、署名検証等）を行うことなくそのパケットを破棄する。このように構成することで、必要な情報だけを効率よく取得することができる。
［セキュリティ処理の他の例］
セキュリティ処理は、以上に説明したものに限られず、種々の方法によるものを採用することができる。例えば、特許文献１に記載された公知のセキュリティ処理を採用することができる。
図１６は、本発明の他の実施形態に係る、通信パケットのセキュリティフレームのデータ構造を示す説明図である。この実施形態は、特許文献１に記載された公知のセキュリティ処理に係るものである。図１６（ａ）に示すように、先頭パケットは、バージョン・メッセージタイプ、ＭＡＣ方式ヘッダ、ＭＡＣ方式ペイロード、ＭＡＣ方式フッタからなる。
セキュリティ処理は、以上に説明したものに限られず、種々の方法によるものを採用することができる。例えば、特許文献１に記載された公知のセキュリティ処理を採用することができる。
図１６は、本発明の他の実施形態に係る、通信パケットのセキュリティフレームのデータ構造を示す説明図である。この実施形態は、特許文献１に記載された公知のセキュリティ処理に係るものである。図１６（ａ）に示すように、先頭パケットは、バージョン・メッセージタイプ、ＭＡＣ方式ヘッダ、ＭＡＣ方式ペイロード、ＭＡＣ方式フッタからなる。
バージョン・メッセージタイプは、フレームフォーマットのバージョンがセットされる。ＭＡＣ方式ヘッダに含まれるメッセージ形式は、データ認証方式を規定する認証タイプと、「ペイロード」に対する保護の形式を指定するメッセージタイプの２つがセットされる。
「マスタ鍵ＩＤ」は、マスタ鍵を識別するための識別情報である。「暗号化通信鍵」は、マスタ鍵で暗号化した通信鍵である。この通信鍵は送信元で乱数生成する。「Ｎｏｎｓｅ」は、通信鍵を用いた暗号化処理（暗号化あるいはＭＡＣ生成）において結果を攪乱するために用いる通信毎にユニークな値である。ここでは「乱数」と「機器ＩＤ」がセットされる。「機器ＩＤ」は、パケット信号の発信元である路側通信機２に対して割り当てられた機器ＩＤをセットする。
「マスタ鍵ＩＤ」は、マスタ鍵を識別するための識別情報である。「暗号化通信鍵」は、マスタ鍵で暗号化した通信鍵である。この通信鍵は送信元で乱数生成する。「Ｎｏｎｓｅ」は、通信鍵を用いた暗号化処理（暗号化あるいはＭＡＣ生成）において結果を攪乱するために用いる通信毎にユニークな値である。ここでは「乱数」と「機器ＩＤ」がセットされる。「機器ＩＤ」は、パケット信号の発信元である路側通信機２に対して割り当てられた機器ＩＤをセットする。
「乱数」は、パケット信号の送信時に送信元が発生した乱数がセットされる。「ペイロード長」は、「ペイロード」のバイト数がセットされる。
「公開鍵証明書」は、送信元の路側通信機２に固有の公開鍵に対する公開鍵証明書をセットする。公開鍵証明書は公開鍵とその公開鍵の所有主体を結びつける証明書である。公開鍵証明書には、署名者の識別情報、公開鍵証明書の識別情報（機器ＩＤであってもよい）、有効期限、公開鍵（鍵生成アルゴリズム、サイズなどを含む）、署名者の署名などが含まれる。当該署名は、例えば、ＲＳＡ、ＤＳＡ（ＤｉｇｉｔａｌＳｉｇｎａｔｕｒｅ Ａｌｇｏｒｉｔｈｍ）、ＥＣＤＳＡ（Ｅｌｌｉｐｔｉｃ Ｃｕｒｖｅ−ＤＳＡ）などの公開鍵暗号方式により生成される。「後続パケットの認証用ハッシュ値」は、図１６（ｂ）に示す後続の通信パケットの「アプリケーション」に対するハッシュ値のリストをセットする。「アプリケーション」には、アプリケーションデータがセットされる。
「公開鍵証明書」は、送信元の路側通信機２に固有の公開鍵に対する公開鍵証明書をセットする。公開鍵証明書は公開鍵とその公開鍵の所有主体を結びつける証明書である。公開鍵証明書には、署名者の識別情報、公開鍵証明書の識別情報（機器ＩＤであってもよい）、有効期限、公開鍵（鍵生成アルゴリズム、サイズなどを含む）、署名者の署名などが含まれる。当該署名は、例えば、ＲＳＡ、ＤＳＡ（ＤｉｇｉｔａｌＳｉｇｎａｔｕｒｅ Ａｌｇｏｒｉｔｈｍ）、ＥＣＤＳＡ（Ｅｌｌｉｐｔｉｃ Ｃｕｒｖｅ−ＤＳＡ）などの公開鍵暗号方式により生成される。「後続パケットの認証用ハッシュ値」は、図１６（ｂ）に示す後続の通信パケットの「アプリケーション」に対するハッシュ値のリストをセットする。「アプリケーション」には、アプリケーションデータがセットされる。
「電子署名」は、「後続パケットの認証用ハッシュ値」、「アプリケーションデータ」に対する署名がセットされる。署名は「公開鍵証明書」に含まれる公開鍵と対をなす秘密鍵を用いて生成された署名である。さらに、署名をセットした後、ＭＡＣ値が、導出されて「ＭＡＣ」にセットされる。この例では、ＭＡＣの演算対象は「ＭＡＣ方式ヘッダ」の「Ｎｏｎｃｅ」と「ペイロード長」と「ＭＡＣ方式ペイロード」であり、暗号化の対象は「ＭＡＣ方式ペイロード」と「ＭＡＣ方式フッタ」である。なお、ペイロードおよびメッセージ認証コード（ＭＡＣ）を共通鍵（乱数）を用いて暗号化することで、メッセージを秘匿してもよい。
図１６（ｂ）の後続パケットのデータ構造は、「バージョン・メッセージタイプ」、「ＭＡＣ方式ヘッダ」に続いて、「ＭＡＣ方式ペイロード」が配置され、最後に「ＭＡＣ方式フッタ」が配置される。「ＭＡＣ方式ヘッダ」と「ＭＡＣ方式フッタ」の構造は、図１６（ａ）と同一なので説明を省略する。また、「ＭＡＣ方式ペイロード」には、「証明書ダイジェスト」、「アプリケーションデータ」が含まれる。「証明書ダイジェスト」は、送信元の路側通信機２に固有の公開鍵に対する公開鍵証明書のダイジェストがセットされる。「ＭＡＣ」には、ＭＡＣ値が導出されてセットされる。図１６（ａ）と同様に、ＭＡＣの演算対象は「ＭＡＣ方式ヘッダ」の「Ｎｏｎｃｅ」と「ペイロード長」と、「ＭＡＣ方式ペイロード」である。暗号化の対象は「ＭＡＣ方式ペイロード」と「ＭＡＣ方式フッタ」である。
以上のような先頭パケット及び後続パケットを路側通信機２から送信し、他の通信機２，３が受信すると、制御部２３，３３、セキュリティ処理部２６，３６は、ＭＡＣ方式ヘッダの内容を確認し、メッセージの復号処理および検証処理を実行する。制御部２３，３３は、記憶部２４，３４に保持されたマスタ鍵によってＭＡＣ方式ヘッダの暗号化通信鍵を復号して通信鍵を取り出す。鍵ＩＤにしたがって、記憶部に保持された共通鍵のうち、セキュリティフレームに対して使用された共通鍵を通信鍵として取り出す。そして、「ＭＡＣ方式ペイロード」および「ＭＡＣ方式フッタ」を復号し、通信鍵を用いて復号後の「ＭＡＣ方式ペイロード」に対するＭＡＣを生成し、「ＭＡＣ」の値と比較する。一致すればメッセージの完全性が確認される。また、「電子署名」の検証を行う。検証に成功すれば、メッセージの発信元の真正性が確認できる。また、後続パケットの「アプリケーション」のハッシュを演算し、先頭パケットの「後続パケットの認証用ハッシュリスト」に含まれる自身に対するハッシュと比較する。先頭パケットの署名検証に成功し、かつ、ハッシュが一致すれば、メッセージの発信元の真正性が確認される。
図１７は、他の実施形態におけるセキュリティ処理を示す説明図である。
この実施形態では、路側通信機２におけるセキュリティ処理部２６において一連の複数の通信パケットを一纏めにして暗号化し、暗号化されたデータを複数に分割して送信する。受信側の通信機では、分割されたデータを結合した上で復号化することによって、もとの複数の通信パケットを取得する。このような方法によっても、一連の複数の通信パケットにセキュリティ処理を施すことができる。
この実施形態では、路側通信機２におけるセキュリティ処理部２６において一連の複数の通信パケットを一纏めにして暗号化し、暗号化されたデータを複数に分割して送信する。受信側の通信機では、分割されたデータを結合した上で復号化することによって、もとの複数の通信パケットを取得する。このような方法によっても、一連の複数の通信パケットにセキュリティ処理を施すことができる。
［付記］
本発明に関して、今回開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は、上記した意味ではなく、特許請求の範囲と均等の意味及び範囲内でのすべての変更が含まれることが意図される。
例えば、セキュリティ処理の具体的な態様は上記に説明したものに限られず、種々の処理を適用することができる。
本発明に関して、今回開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は、上記した意味ではなく、特許請求の範囲と均等の意味及び範囲内でのすべての変更が含まれることが意図される。
例えば、セキュリティ処理の具体的な態様は上記に説明したものに限られず、種々の処理を適用することができる。
１：交通信号機
２：路側通信機（基地局）
２Ａ：オンライン路側通信機
２Ｂ：スタンドアローン路側通信機
３：車載通信機（移動局；移動通信機）
４：中央装置
５：車両
６：路側センサ
７：有線通信回線
８：ルータ
１８：記憶部
２０：アンテナ
２１：無線通信部
２２：有線通信部
２３：制御部
２３Ａ：設定部
２４：記憶部
２５：通信処理装置
２５ａ：アプリケーション部
２５ｂ：通信処理部
２６：セキュリティ処理部
３０：アンテナ
３１：無線通信部
３３：制御部
３４：記憶部
３５：通信処理装置
３５ａ：アプリケーション部
３５ｂ：通信処理部
３６：セキュリティ処理部
Ａ１：交差点
Ａ２：交差点
Ａ３：交差点
Ａ４：交差点
Ａ５：交差点
ＡＰ：アプリケーション
ＡＰ１：第１アプリケーション
ＡＰ２：第２アプリケーション
Ｂ１：交差点
Ｂ２：交差点
Ｂ３：交差点
Ｂ４：交差点
Ｂ５：交差点
ＥＬ：拡張層
Ｌ７：レイヤ７
ＲＲ：路路間通信
ＲＶ：路車間通信
ＳＥＣ：セキュリティ管理
２：路側通信機（基地局）
２Ａ：オンライン路側通信機
２Ｂ：スタンドアローン路側通信機
３：車載通信機（移動局；移動通信機）
４：中央装置
５：車両
６：路側センサ
７：有線通信回線
８：ルータ
１８：記憶部
２０：アンテナ
２１：無線通信部
２２：有線通信部
２３：制御部
２３Ａ：設定部
２４：記憶部
２５：通信処理装置
２５ａ：アプリケーション部
２５ｂ：通信処理部
２６：セキュリティ処理部
３０：アンテナ
３１：無線通信部
３３：制御部
３４：記憶部
３５：通信処理装置
３５ａ：アプリケーション部
３５ｂ：通信処理部
３６：セキュリティ処理部
Ａ１：交差点
Ａ２：交差点
Ａ３：交差点
Ａ４：交差点
Ａ５：交差点
ＡＰ：アプリケーション
ＡＰ１：第１アプリケーション
ＡＰ２：第２アプリケーション
Ｂ１：交差点
Ｂ２：交差点
Ｂ３：交差点
Ｂ４：交差点
Ｂ５：交差点
ＥＬ：拡張層
Ｌ７：レイヤ７
ＲＲ：路路間通信
ＲＶ：路車間通信
ＳＥＣ：セキュリティ管理
Claims (7)
- セキュリティ処理を施したデータを移動通信機と路側通信機とに送信する路側通信機であって、
一又は複数のデータをセキュリティ処理の実行単位として設定する設定部を備え、
前記設定部は、前記移動通信機宛のデータと前記路側通信機宛のデータとに対して、異なる基準により前記実行単位を設定する、路側通信機。 - 前記設定部は、
前記移動通信機宛のデータに対してサービス毎にセキュリティ処理の実行単位を設定し、
前記路側通信機宛のデータに対してデータ毎又は宛先毎にセキュリティ処理の実行単位を設定する、請求項１に記載の路側通信機。 - 前記設定部は、
前記移動通信機宛のデータに対して１つの制御周期内で送信されるもの毎にセキュリティ処理の実行単位を設定し、
前記路側通信機宛のデータに対してデータ毎又は宛先毎にセキュリティ処理の実行単位を設定する、請求項１に記載の路側通信機。 - 前記設定部は、通信状況の良否に応じて、前記路側通信機宛のデータに対するセキュリティ処理の実行単位として宛先毎又はデータ毎のいずれかを選択して設定する、請求項２又は請求項３に記載の路側通信機。
- 前記設定部は、宛先となる路側通信機に接続される端末数に応じて、当該路側通信機宛のデータに対するセキュリティ処理の実行単位として宛先毎又はデータ毎のいずれかを選択して設定する、請求項２〜請求項４のいずれか１項に記載の路側通信機。
- 移動通信機と路側通信機とにデータを送信する路側通信機において、前記データにセキュリティ処理を施すための方法であって、
前記移動通信機宛のデータと前記路側通信機宛のデータとに対して、異なる基準により一又は複数のデータをセキュリティ処理の実行単位として設定する、セキュリティ処理方法。 - 移動通信機と路側通信機とにデータを送信する路側通信機において、コンピュータに前記データのセキュリティ処理を実行させるコンピュータプログラムであって、
一又は複数のデータをセキュリティ処理の実行単位として設定する設定部としてコンピュータを機能させ、
前記設定部は、前記移動通信機宛のデータと前記路側通信機宛のデータとに対して、異なる基準により前記実行単位を設定する、コンピュータプログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2014139593A JP2016019078A (ja) | 2014-07-07 | 2014-07-07 | 路側通信機、セキュリティ処理方法、及びコンピュータプログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2014139593A JP2016019078A (ja) | 2014-07-07 | 2014-07-07 | 路側通信機、セキュリティ処理方法、及びコンピュータプログラム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2016019078A true JP2016019078A (ja) | 2016-02-01 |
Family
ID=55234025
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2014139593A Pending JP2016019078A (ja) | 2014-07-07 | 2014-07-07 | 路側通信機、セキュリティ処理方法、及びコンピュータプログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2016019078A (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2022528361A (ja) * | 2019-03-25 | 2022-06-10 | マイクロン テクノロジー，インク． | 自律環境における非自律車両の運転者支援 |
-
2014
- 2014-07-07 JP JP2014139593A patent/JP2016019078A/ja active Pending
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2022528361A (ja) * | 2019-03-25 | 2022-06-10 | マイクロン テクノロジー，インク． | 自律環境における非自律車両の運転者支援 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP5362925B2 (ja) | 路側機および車載器 | |
| KR101521412B1 (ko) | 인증기반 메시지 집계 프로토콜 관리시스템 | |
| US11811943B2 (en) | Verification of messages using hash chaining | |
| EP3637672A1 (en) | V2x communication device and secured communication method thereof | |
| JP6799563B2 (ja) | 受信装置、受信方法 | |
| JP6112467B2 (ja) | 通信装置 | |
| JP5991561B2 (ja) | 無線装置 | |
| US11523278B2 (en) | Method for secured communication and apparatus therefor | |
| JP5895214B2 (ja) | 無線装置 | |
| CN115580419A (zh) | 运载工具服务提供商系统、用于该系统的方法及存储介质 | |
| JP2016019078A (ja) | 路側通信機、セキュリティ処理方法、及びコンピュータプログラム | |
| CN115580867A (zh) | 运载工具服务订户系统、用于该系统的方法及存储介质 | |
| JP6102109B2 (ja) | 路側通信機、無線通信システム、及び送信方法 | |
| JP6187888B2 (ja) | 処理装置 | |
| JP2010183261A (ja) | 移動体側通信装置、路側通信装置、それらの装置を備える通信システム及びそれらの装置間の通信方法、並びに情報収集方法 | |
| JP5991560B2 (ja) | 無線装置 | |
| JP6286817B2 (ja) | 通信システム、通信機、通信処理装置、コンピュータプログラム、及び通信方法 | |
| Sasikala et al. | Key management techniques for vanets | |
| JP6183629B2 (ja) | 処理装置 | |
| Agarwal et al. | Vehicular Ad Hoc Networks: Hashing and Trust Computation Techniques | |
| Saravanakumar | Monitoring Vehicle Communication and Road Condition in VANET | |
| JP5903629B2 (ja) | 無線装置 | |
| Singh et al. | Dynamic Environment Improvement for Vanets | |
| JP2016057494A (ja) | 無線機、セキュリティ処理方法、及びコンピュータプログラム | |
| Siwach et al. | Analysis of Security Problems in Vehicular Ad-hoc Networks using LTE Cellular Network. |