特許 6233479 通信機、移動局、無線通信システム、及びコンピュータプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6233479

(24)【登録日】2017年11月2日

(45)【発行日】2017年11月22日

(54)【発明の名称】通信機、移動局、無線通信システム、及びコンピュータプログラム

(51)【国際特許分類】

   H04W 80/08 20090101AFI20171113BHJP

   H04W 4/04 20090101ALI20171113BHJP

   G08G 1/09 20060101ALI20171113BHJP

【ＦＩ】

   H04W80/08

   H04W4/04 111

   H04W4/04 113

   G08G1/09 F

   G08G1/09 H

【請求項の数】10

【全頁数】29

(21)【出願番号】特願2016-179181(P2016-179181)

(22)【出願日】2016年9月14日

(62)【分割の表示】特願2012-151203(P2012-151203)の分割

【原出願日】2012年7月5日

(65)【公開番号】特開2016-220252(P2016-220252A)

(43)【公開日】2016年12月22日

【審査請求日】2016年10月13日

(73)【特許権者】

【識別番号】000002130

【氏名又は名称】住友電気工業株式会社

(74)【代理人】

【識別番号】110000280

【氏名又は名称】特許業務法人サンクレスト国際特許事務所

(72)【発明者】

【氏名】浦山 博史

【審査官】 深津 始

(56)【参考文献】

【文献】 特開２０１２−３３４１６（ＪＰ，Ａ）

【文献】 特開２００８−２１９４０９（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｂ ７／２４ −Ｈ０４Ｂ ７／２６

Ｈ０４Ｗ ４／００ −Ｈ０４Ｗ ９９／００

Ｇ０８Ｇ １／０９

(57)【特許請求の範囲】

【請求項1】

基地局向けの通信パケットを送信可能な通信機であって、
前記通信機が送信する通信パケットには、通信形態を区別するための種別情報が含まれ、
前記通信形態は、送信元通信機種別と宛先通信機種別との組み合わせで区別される通信形態であり、
前記種別情報は、前記通信パケットの制御フィールドであって、前記通信パケットの受信側においてＭＡＣ層よりも上位層又は当該上位層がアクセスする処理部において読み取られる制御フィールドに設けられている
ことを特徴とする通信機。

【請求項2】

前記種別情報は、宛先通信機が基地局であるか移動局であるかを識別可能な情報である
請求項１記載の通信機。

【請求項3】

前記種別情報は、７００ＭＨｚ帯高度道路交通システム標準規格（ＡＲＩＢ ＳＴＤ−Ｔ１０９）に規定するレイヤ７ヘッダに設けられている
請求項１又は２に記載の通信機。

【請求項4】

前記種別情報は、前記通信パケットの受信側において、セキュリティ処理が行われたセキュアなアプリケーションデータを、アンセキュアなアプリケーションデータにする処理を行う前に読み取られる制御フィールドに設けられている
請求項１〜３のいずれか１項に記載の通信機。

【請求項5】

前記通信機は、基地局である
請求項１〜４のいずれか１項に記載の通信機。

【請求項6】

前記通信機は、移動局である
請求項１〜４のいずれか１項に記載の通信機。

【請求項7】

基地局及び他の移動局との間で無線通信を行う移動局であって、
受信した通信パケットから、通信形態を区別するための情報を読み取ることで、前記通信パケットが、基地局向けに送信された通信パケットであるか否かを識別し、前記通信パケットが、基地局向けに送信された通信パケットである場合には、前記通信パケットを破棄するよう構成され、
前記通信形態は、送信元通信機種別と宛先通信機種別との組み合わせで区別される通信形態であり、
前記情報は、前記通信パケットの制御フィールドであって、前記移動局においてＭＡＣ層よりも上位層又は当該上位層がアクセスする処理部において読み取られる制御フィールドに設けられている
ことを特徴とする移動局。

【請求項8】

無線通信を行う基地局及び移動局を含む無線通信システムであって、
前記基地局又は前記移動局は、通信形態を区別するための情報が含まれる通信パケットを送信するよう構成され、
前記通信形態は、送信元通信機種別と宛先通信機種別との組み合わせで区別される通信形態であり、
前記移動局は、受信した通信パケットから、前記情報を読み取ることで、前記通信パケットが、基地局向けに送信された通信パケットであるか否かを識別し、前記通信パケットが、基地局向けに送信された通信パケットである場合には、前記通信パケットを破棄するよう構成され、
前記情報は、前記通信パケットの制御フィールドであって、前記通信パケットの受信側においてＭＡＣ層よりも上位層又は当該上位層がアクセスする処理部において読み取られる制御フィールドに設けられている
ことを特徴とする無線通信システム。

【請求項9】

基地局向けの通信パケットを送信可能な通信機に設けられたコンピュータによって実行されるコンピュータプログラムであって、
通信形態を区別するための情報が含まれる通信パケットを生成する処理を前記コンピュータに実行させるよう構成され、
前記通信形態は、送信元通信機種別と宛先通信機種別との組み合わせで区別される通信形態であり、
前記情報は、前記通信パケットの制御フィールドであって、前記通信パケットの受信側においてＭＡＣ層よりも上位層又は当該上位層がアクセスする処理部において読み取られる制御フィールドに設けられている
ことを特徴とするコンピュータプログラム。

【請求項10】

基地局及び他の移動局との間で無線通信を行う移動局に設けられたコンピュータによって実行されるコンピュータプログラムであって、
受信した通信パケットから、通信形態を区別するための情報を読み取ることで、前記通信パケットが、基地局向けに送信された通信パケットであるか否かを識別する処理、及び、
前記通信パケットが、基地局向けに送信された通信パケットである場合には、前記通信パケットを破棄する処理、
を前記コンピュータに実行させるよう構成され、
前記通信形態は、送信元通信機種別と宛先通信機種別との組み合わせで区別される通信形態であり、
前記情報は、前記通信パケットの制御フィールドであって、前記移動局においてＭＡＣ層よりも上位層又は当該上位層がアクセスする処理部において読み取られる制御フィールドに設けられている
ことを特徴とするコンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、例えば、高度道路交通システム（ＩＴＳ：Intelligent Transport System）の構成要素として好適である通信機、基地局及び移動局を有する無線通信システム、並びに、通信機のためのコンピュータプログラムに関するものである。

【背景技術】

【0002】

従来、ＩＴＳの一環として、路側に設置される基地局と、移動局（車両に搭載される車載通信機等）と、を有する無線通信システムが検討されている。
非特許文献１及び非特許文献２には、ＩＴＳのための無線通信システムについて記載されている。

【0003】

ＩＴＳのための無線通信システムでは、路側に設置された基地局（路側通信機）が、車両に搭載された移動局（移動体通信機）に対して情報を送信する路車間通信と、車両に搭載された移動局間で情報を送信する車車間通信と、が行われる。

【0004】

車車間通信を行うことで、車両に搭載された移動局が、車両の位置や速度などの情報からなるアプリケーションデータが格納された通信パケットを他の移動局に送信することができ、別の車両との衝突を回避する安全運転支援に役立てることができる。
また、路車間通信を行うことで、路側に設置された基地局が、前記車両情報又は交通信号機の情報などのアプリケーションデータが格納された通信パケットを移動局に送信することができる。

【先行技術文献】

【非特許文献】

【0005】

【非特許文献1】一般社団法人電波産業会、”７００ＭＨｚ帯高度道路交通システム ＡＲＩＢ−ＳＴＤ Ｔ１０９ １．０版“，［online］、平成２４年２月１４日、［平成２４年６月６日検索］、インターネット<http://www.arib.or.jp/tyosakenkyu/kikaku_tushin/tsushin_kikaku_number.html>

【非特許文献2】ＩＴＳ情報通信システム推進会議、”７００ＭＨｚ帯高度道路交通システム拡張機能ガイドライン ＩＴＳ ＦＯＲＵＭ ＲＣ−０１０ １．０版”，[online]、２０１２年３月２６日、［平成２４年６月６日検索］、インターネット<http://www.itsforum.gr.jp/>

【発明の概要】

【発明が解決しようとする課題】

【0006】

ＩＴＳのための無線通信システムでは、基地局及び多数の移動局から次々と送信されてくる大量の通信パケットを可能な限り受信することが求められる。
したがって、送信側と受信側との間でＡＣＫなどのやりとりを行って接続チャネルを確立するコネクション型通信ではなくコネクションレス型通信が行われる。したがって、受信側は、送信側から一方的に送信された通信パケットを受信する必要があり、たとえ、受信に失敗しても再送処理は行われない。

【0007】

無線通信システムにおいて行われる通信として、前述の路車間通信及び車車間通信だけを想定する場合、移動局（車載通信機など）としては、送信されてくる通信パケットは全て車両（移動局）向けであるから、送信されてくる大量の通信パケットを、可能な範囲で受信することに問題はない。

【0008】

しかし、ＩＴＳのための無線通信システムでは、路側に設置される基地局（路側通信機）間で情報を送信する路路間通信を行うことも検討されている。
路路間通信が行われる場合、移動局としては、路側に設置される基地局からの通信パケットのうち、路路間通信用のパケット（路路間通信パケット）は受信するのは避けたいところである。

【0009】

ところが、前述のように、移動局は送信されてくる大量の通信パケットを可能な限り受信することが求められている。そのため、例えば、非特許文献１では、通信パケットのＭＡＣ制御フィールドに格納される宛先アドレスとして、ブロードキャストアドレスのみが規定されている。つまり、通信パケットは、同報通信（ブロードキャスト）のためだけに用いられることになっている。

【0010】

通信パケットがブロードキャストされたものであると、宛先アドレスでは宛先を区別できないことになる。また、送信元アドレスが特定できたとしても、アドレスのみから、送信元の通信機が基地局であるのか移動局であるのかを区別するのは容易ではない。したがって、移動局は、アドレスを参照しても、その通信パケットが路車間通信用であるのか、路路間通信用であるのかを、区別することはできない。

【0011】

そうすると、移動局は、受信した通信パケットに格納されているアプリケーションデータを読み取って、そのアプリケーションデータが当該移動局に必要なデータであれば利用し、そのアプリケーションデータが基地局向けのデータであれば、利用せずに破棄することになる。

【0012】

その結果、移動局としては、路路間通信パケットを受信してしまうと、その路路間通信パケットから不要なアプリケーションデータを読み出すための処理を無駄に行うことになる。このため、本来処理すべき路車間通信パケット又は車車間通信パケットの処理遅延が大きくなる。

【0013】

このような問題は、通信パケットの宛先アドレスでは、その通信パケットの宛先である通信機の種別が基地局であるのか移動局であるのか区別できない場合に共通して生じうる問題である。
また、上記問題は、例えば、移動局が基地局向けの通信パケット（車路間通信パケット）を送信した場合にも同様に生じる。

【0014】

そこで、本発明は、通信パケットの宛先アドレスでは、その通信パケットの宛先である通信機の種別が基地局であるのか移動局であるのか区別できない場合において、通信パケットを受信した移動局がアプリケーションデータを読み出すための処理を無駄に行ってしまうことを抑制することを目的とする。

【課題を解決するための手段】

【0015】

（１）一の観点からみた本発明において、通信機が送信する通信パケットには、通信形態を区別するための種別情報が含まれ、前記通信形態は、送信元通信機種別と宛先通信機種別との組み合わせで区別される通信形態であり、前記種別情報は、前記通信パケットの制御フィールドであって、前記通信パケットの受信側においてＭＡＣ層よりも上位層又は当該上位層がアクセスする処理部において読み取られる制御フィールドに設けられている。

【0016】

他の観点からみた本発明は、基地局向けの通信パケットを送信可能な通信機であって、前記通信機が送信する通信パケットには、宛先の通信機種別を示す情報を有する種別情報が含まれ、前記種別情報は、前記通信パケットの制御フィールドであって、前記通信パケットの受信側においてＭＡＣ層よりも上位層又は当該上位層がアクセスする処理部において読み取られる制御フィールドに設けられていることを特徴とする通信機である。
他の観点からみた上記本発明によれば、通信機が送信する通信パケットに、宛先の通信機種別を示す情報が含まれている。したがって、通信パケットの受信側である移動局は、通信パケットの宛先アドレスがブロードキャストアドレスである場合のように、宛先アドレス自体は自局宛とみなされる場合においても、宛先の通信機種別を示す情報に基づいて、当該通信パケットが自局において取得すべきものであるかどうかを判定することができる。
この結果、移動局は、受信した通信パケットの要否を判定できる。

【0017】

しかも、情報は、通信パケットの受信側においてＭＡＣ層よりも上位層又は当該上位層がアクセスする処理部において読み取られる制御フィールドに設けられているため、アプリケーションデータを読み出す前に、受信した通信パケットの要否を判定することが可能である。
よって、通信パケットを受信した移動局がアプリケーションデータを読み出すための処理を無駄に行ってしまうことを抑制することができる。

【0018】

（２）前記情報は、通信機が基地局であるか移動局であるかを識別可能な情報であるのが好ましい。この場合、通信機種別を示す情報によって、宛先の通信機が基地局であるか移動局であるかを識別することができる。

【0019】

（３）前記通信機は、通信パケットの宛先アドレスとしてブロードキャストアドレスのみが規定された規格に準拠した移動局が含まれ得る無線通信システムにおいて用いられるものであるとともに、基地局向けの通信パケットを送信する際には、前記通信パケットのＭＡＣ制御フィールドにおける宛先アドレスとして、非ブロードキャストアドレスであって前記基地局が宛先となるアドレスをセットするのが好ましい。
この場合、通信パケットは、宛先となった基地局に届く。一方、通信パケットの宛先アドレスとしてブロードキャストアドレスのみが規定された規格に準拠した移動局にとっては、通信パケットの宛先アドレスはブロードキャストアドレスであることが前提となっているため、非ブロードキャストアドレスが格納された通信パケットは、当該移動局によって破棄されることが期待される。

【0020】

（４）前記情報は、下記ａ）〜ｄ）のうちの少なくとも一つに設けられているのが好ましい。
ａ）７００ＭＨｚ帯高度道路交通システム標準規格（ＡＲＩＢ ＳＴＤ−Ｔ１０９）に規定するＩＲ制御フィールド
ｂ）７００ＭＨｚ帯高度道路交通システム標準規格（ＡＲＩＢ ＳＴＤ−Ｔ１０９）に規定するレイヤ７ヘッダ
ｃ）７００ＭＨｚ帯高度道路交通システム拡張機能ガイドライン（ＩＴＳ ＦＯＲＵＭ ＲＣ−０１０）に規定するＥＬヘッダ
ｄ）通信パケットに格納されるアプリケーションデータに対するセキュリティ管理のためのフィールド

【0021】

（５）前記情報は、前記通信パケットの受信側において、セキュリティ処理が行われたセキュアなアプリケーションデータを、アンセキュアなアプリケーションデータにする処理を行う前に読み取られる制御フィールドに設けられているのが好ましい。この場合、前記情報を、セキュアなアプリケーションデータを、アンセキュアなアプリケーションデータにする処理を行う前に読み取ることができ、セキュアなアプリケーションデータを、アンセキュアなアプリケーションデータにする処理を無駄に行ってしまうことを防止できる。

【0022】

（６）前記通信パケットには、前記種別情報として、送信元の通信機種別を示す情報が更に設けられているのが好ましい。この場合、通信パケットの受信側は、送信元の通信機種別も把握できる。

【0023】

（７）他の観点からみた本発明は、通信パケットの宛先アドレスとしてブロードキャストアドレスのみが規定された規格に準拠した移動局が含まれ得る無線通信システムにおいて用いられる通信機であって、基地局向けの通信パケットを送信する際には、前記通信パケットのＭＡＣ制御フィールドにおける宛先アドレスとして、非ブロードキャストアドレスであって前記他の基地局が宛先となるアドレスをセットすることを特徴とする基地局である。

【0024】

この場合、通信パケットの宛先アドレスとしてブロードキャストアドレスのみが規定された規格に準拠した移動局にとっては、通信パケットの宛先アドレスはブロードキャストアドレスであることが前提となっているため、非ブロードキャストアドレスが格納された通信パケットは、当該移動局によって破棄されることが期待される。
よって、通信パケットを受信した移動局がアプリケーションデータを読み出すための処理を無駄に行ってしまうことを抑制することができる。

【0025】

（８）前記通信機は、基地局として使用できる。
（９）前記通信機は、移動局として使用できる。

【0026】

（１０）他の観点からみた本発明は、基地局及び他の移動局との間で無線通信を行う移動局であって、受信した通信パケットから、宛先の通信機種別を示す情報を読み取ることで、前記通信パケットが、基地局向けに送信された通信パケットであるか否かを識別し、前記通信パケットが、基地局向けに送信された通信パケットである場合には、前記通信パケットを破棄するよう構成され、前記情報は、前記通信パケットの制御フィールドであって、前記移動局においてＭＡＣ層よりも上位層又は当該上位層がアクセスする処理部において読み取られる制御フィールドに設けられていることを特徴とする移動局である。

【0027】

（１１）他の観点からみた本発明は、無線通信を行う基地局及び移動局を含む無線通信システムであって、前記基地局又は基地局は、宛先の通信機種別を示す情報が含まれる通信パケットを送信するよう構成され、前記移動局は、受信した通信パケットから、前記情報を読み取ることで、前記通信パケットが、基地局向けに送信された通信パケットであるか否かを識別し、前記通信パケットが、基地局向けに送信された通信パケットである場合には、前記通信パケットを破棄するよう構成され、前記情報は、前記通信パケットの制御フィールドであって、前記前記通信パケットの受信側においてＭＡＣ層よりも上位層又は当該上位層がアクセスする処理部において読み取られる制御フィールドに設けられていることを特徴とする無線通信システムである。

【0028】

（１２）他の観点からみた本発明は、基地局向けの通信パケットを送信可能な通信機に設けられたコンピュータによって実行されるコンピュータプログラムであって、宛先の通信機種別を示す情報が含まれる通信パケットを生成する処理を前記コンピュータに実行させるよう構成され、前記情報は、前記通信パケットの制御フィールドであって、前記通信パケットの受信側においてＭＡＣ層よりも上位層又は当該上位層がアクセスする処理部において読み取られる制御フィールドに設けられていることを特徴とするコンピュータプログラムである。

【0029】

（１３）他の観点からみた本発明は、基地局及び他の移動局との間で無線通信を行う移動局に設けられたコンピュータによって実行されるコンピュータプログラムであって、受信した通信パケットから、宛先の通信機種別を示す情報を読み取ることで、前記通信パケットが、基地局向けに送信された通信パケットであるか否かを識別する処理、及び、前記通信パケットが、基地局向けに送信された通信パケットである場合には、前記通信パケットを破棄する処理、を前記コンピュータに実行させるよう構成され、前記情報は、前記通信パケットの制御フィールドであって、前記移動局においてＭＡＣ層よりも上位層又は当該上位層がアクセスする処理部において読み取られる制御フィールドに設けられていることを特徴とするコンピュータプログラムである。

【発明の効果】

【0030】

本発明によれば、通信パケットの宛先アドレスでは、その通信パケットの宛先である通信機の種別が基地局であるのか移動局であるのか区別できない場合においても、通信パケットを受信した移動局がアプリケーションデータを読み出すための処理を無駄に行ってしまうことを抑制することができる。

【図面の簡単な説明】

【0031】

【図1】本発明の実施形態に係る路側通信機を含む高度道路交通システムの全体構成を示す概略斜視図である。

【図2】上記高度道路交通システムの管轄エリアの一部を示す道路平面図である。

【図3】路側通信機と車載通信機の内部構成を示すブロック図である。

【図4】タイムスロットの一例を示す概念図である。

【図5】通信プロトコルスタックを示す図である。

【図6】通信フレームの構成図である。

【図7】（ａ）はＭＡＣ制御フィールドを示し、（ｂ）はＬＬＣ制御フィールドを示し、（ｃ）はＩＲ制御フィールドを示し、（ｄ）はＬ７ヘッダを示す図である。

【図8】拡張レイヤを有するプロトコルスタックを示す図である。

【図9】ＥＬヘッダを有する通信フレームの構成図である。

【図10】ＥＬヘッダを示す図である。

【図11】個別情報及び共通情報の説明図である。

【図12】宛先通信機種別情報などの説明図である。

【図13】宛先通信機種別情報などの説明図である。

【図14】宛先通信機種別情報などの説明図である。

【図15】宛先通信機種別情報などの説明図である。

【発明を実施するための形態】

【0032】

〔システムの全体構成〕
図１は、高度道路交通システム（ＩＴＳ）の全体構成を示す概略斜視図である。なお、図１では、道路構造の一例として、南北方向と東西方向の複数の道路が互いに交差した碁盤目構造を想定している。
図１に示すように、高度道路交通システムは、交通信号機１、路側に設置された基地局２、車両に搭載された移動局３（図２及び図３参照）、中央装置４、移動局を搭載した車両５、及び、各種の車両感知器よりなる路側センサ６などを含む。なお、以下、路側に設置された基地局２を「路側通信機」といい、車両に搭載された移動局３を「車載通信機」という。
なお、本実施形態に係る高度道路交通システムは、非特許文献１に示す標準規格及び非特許文献２に示すガイドラインに準拠している。

【0033】

交通信号機１と路側通信機２は、複数の交差点Ｊｉ（図例では、ｉ＝１〜１２）のそれぞれに設置されており、電話回線等の通信回線７を介してルータ８に接続されている。このルータ８は交通管制センター内の中央装置４に接続されている。
中央装置４は、自身が管轄するエリアに含まれる各交差点Ｊｉの交通信号機１及び路側通信機２とＬＡＮ（Local Area Network）を構成している。従って、中央装置４は、各交通信号機１及び各路側通信機２との間で双方向通信が可能である。なお、中央装置４は、交通管制センターではなく道路上に設置してもよい。

【0034】

図１及び図２では、図示を簡略化するために、十字路交差点である各交差点Ｊｉに信号灯器が１つだけ描写されているが、実際の各交差点Ｊｉには、互いに交差する道路の上り下り用として少なくとも４つの信号灯器が設置されている。

【0035】

路側センサ６は、各交差点Ｊｉに流入する車両台数をカウントしたり、渋滞末尾を検出したりする目的で、管轄エリア内の適所に設置された各種の車両感知器よりなる。
この車両感知器としては、例えば、超音波式車両感知器、マイクロ波式車両感知器、光学式車両感知器（光ビーコン）、「画像式車両感知器」及び「旅行時間計測用感知器」などを採用することができる。

【0036】

〔中央装置〕
中央装置４は、ワークステーション（ＷＳ）やパーソナルコンピュータ（ＰＣ）等よりなる制御部を有している。この制御部は、路側通信機２や路側センサ６からの各種の交通情報の収集・処理（演算）・記録、信号制御及び情報提供を統括的に行う。
具体的には、中央装置４の制御部は、自身のネットワークに属する交差点Ｊｉの交通信号機１に対して、同一道路上の交通信号機１群を調整する系統制御や、この系統制御を道路網に拡張した広域制御（面制御）を行うことができる。

【0037】

また、中央装置４は、通信回線７を介してＬＡＮ側と接続された通信インタフェースである通信部を有している。この通信部は、信号灯器の灯色切り替えタイミングに関する信号制御指令Ｓ１や、渋滞情報等を含む交通情報Ｓ２を所定時間ごとに交通信号機１及び路側通信機２に送信している（図１参照）。
信号制御指令Ｓ１は、前記系統制御や広域制御を行う場合の信号制御パラメータの演算周期（例えば、１．０〜２．５分）ごとに送信され、交通情報Ｓ２は、例えば５分ごとに送信される。

【0038】

また、中央装置４の通信部は、各交差点Ｊｉに対応する路側通信機２から、当該路側通信機２が車載通信機３から受信した車両５の位置や速度等を含む車両情報（アプリケーションデータ）Ｓ３を受信し、各道路に設置された路側センサ６から前記感知情報Ｓ４を受信する。
中央装置４の制御部は、管轄エリア内の路側通信機２や路側センサ６などから通信部が取得した車両情報Ｓ３及び感知情報Ｓ４に基づいて、前記系統制御や広域制御を実行することができる。

【0039】

〔無線通信の方式等〕
図２は、上記高度道路交通システムの管轄エリアの一部を示す道路平面図である。
図２では、互いに交差する２つの道路の各々が上りと下りで片側１車線のものとして例示されているが、道路構造はこれに限られるものではない。
図２にも示すように、本実施形態の高度道路交通システムは、車載通信機３との間で無線通信が可能な複数の路側通信機２と、ＣＳＭＡ方式で無線通信を行う移動無線送受信機の一種である複数の車載通信機３とを有する、無線通信システムを含んでいる。

【0040】

路側通信機２は、それぞれ路側の交差点Ｊｉごとに設置されていて、図１及び図２に例示するように、例えば交通信号機１の支柱に取り付けられている。車載通信機３は、道路を走行する車両５に搭載されている。
路側通信機２は、自身の受信エリアＡｒ内にある車載通信機３からの無線信号を受信可能であり、その受信エリアＡｒが他の路側通信機２のアンテナに到達している場合には、当該他の路側通信機２からの無線信号も受信可能である。

【0041】

本実施形態の路側通信機２では、道路の延長方向に沿った指向性を有する複数のアンテナ２０ａ，２０ｂ（図３及び図７参照）を採用しているため、受信エリアＡｒが交差点Ｊ２から道路の延長方向に沿って延びた形状になっている。
なお、図２では、交差点Ｊ２に設置された路側通信機２の受信エリアＡｒのみが描かれているが、その他の交差点Ｊｉに設置された路側通信機２の受信エリアＡｒも同様に、交差点Ｊｉから道路の延長方向に沿って延びた形状になっている。

【0042】

本実施形態の高度道路交通システムでは、路側通信機２同士の通信（路路間通信）については無線通信が用いられ、また、路側通信機２と車載通信機３との間の通信（「路」から「車」への路車間通信と「車」から「路」への車路間通信との双方を含む。）と車載通信機３同士（車車間通信）についても、無線通信が用いられている。
なお、前記した通り、交通管制センターに設けられた中央装置４は、各路側通信機２と有線での双方向通信が可能となっているが、これらの間も無線通信であってもよい。

【0043】

路側通信機２には、自身が無線送信するための専用のタイムスロット（図４の第１スロットＴ１）をＴＤＭＡ方式で割り当てられており、このタイムスロット以外の時間帯（図４の第２スロットＴ２）には無線送信を行わない。従って、路側専用のタイムスロット以外の時間帯は、車載通信機３のためのＣＳＭＡ方式による送信時間として開放されている。
また、路側通信機２は、自身の送信タイミングを制御するために、他の路側通信機２との時刻同期機能を有している。この路側通信機２の時刻同期は、例えば、自身の時計をＧＰＳ時刻に合わせるＧＰＳ同期や、自身の時計を他の路側通信機２からの送信信号に合わせるエア同期等によって行われる。

【0044】

〔路側通信機（基地局）〕
図３は、路側通信機２と車載通信機３の内部構成を示すブロック図である。
路側通信機２は、無線通信のためのアンテナ２０ａ，２０ｂを有する無線通信部（送受信部）２１と、中央装置４と双方向通信する有線通信部２２と、それらの通信制御を行うプロセッサ（ＣＰＵ：Central Processing Unit）等よりなる制御部２３と、制御部２３に接続されたＲＯＭやＲＡＭ等の記憶装置よりなる記憶部２４とを備えている。

【0045】

記憶部２４は、制御部（コンピュータ）２３が実行する通信制御処理のためのコンピュータプログラムや、各通信機２，３の通信機ＩＤなどを記憶している。制御部２３が実行する処理は、コンピュータプログラムが制御部２３によって実行されることで行われる。

【0046】

無線通信部２１は、交差点Ｊｉの道路方向に沿った指向性を有する２つのアンテナ２０ａ，２０ｂを備えており、この２つのアンテナ２０ａ，２０ｂのうちのいずれか１つを受信アンテナとして選択する選択受信方式を採用している。なお、選択受信方式を採用する無線通信部２１の具体的構成（図６）については後述する。

【0047】

制御部２３は、無線通信部２１や有線通信部２２が送受信するＩＴＳ用アプリケーションデータを総括的に制御する通信制御機能を有する。
例えば、制御部２３は、無線通信部２１が車載通信機３から受信した車両情報（アプリケーションデータ）Ｓ３を記憶部２４に一時的に記憶させ、有線通信部２２を通じて中央装置４に転送する。また、制御部２３は、有線通信部２２が中央装置４から受信した交通情報（アプリケーションデータ）Ｓ２等を、記憶部２４に一時的に記憶させ、当該交通情報Ｓ２を含む通信パケットを無線通信部２１からブロードキャスト送信する。

【0048】

また、制御部２３は、記憶部２４に記憶されたタイムスロットの割当情報（アプリケーションデータ）Ｓ５を含む通信パケットを、無線通信部２１を介してブロードキャスト送信する。この割当情報Ｓ５は、路側通信機２の送信時間（図４の第１スロットＴ１）を車載通信機３に通知するための情報である。
路側通信機２から割当情報Ｓ５を取得した車両５の車載通信機３は、その割当情報Ｓ５を送信した路側通信機２が送信を行わない時間帯（図４の第２スロットＴ２）に、キャリアセンス方式による無線送信を行う。

【0049】

〔タイムスロットの割当情報〕
図４は、上記割当情報Ｓ５に含まれるタイムスロットの一例を示す概念図である。
図４に示すように、タイムスロットには第１スロットＴ１と第２スロットＴ２とが含まれており、これらのスロットＴ１，Ｔ２は所定長のサイクルＣ（例えば、１００ｍ秒）内で所定回数だけ繰り返すようになっている。
第１スロットＴ１は、路側通信機２用のタイムスロットであり、この時間帯においては路側通信機２による無線送信が許容される。第１スロットＴ１にはスロット番号ｉが付されており、このスロット番号ｉは周期的にインクリメント又はデクリメントされる。

【0050】

また、第２スロットＴ２は、車載通信機３用のタイムスロットである。この時間帯は車載通信機３による無線送信用として開放するため、路側通信機２は第２スロットＴ２では無線送信を行わない。
図４に示すタイムスロットにおいて、各スロット番号ｉ＝１〜３の第１スロットＴ１に記したドット●は、当該第１スロットＴ１に複数の路側通信機２の送信時間が割り当てられていることを示している。

【0051】

すなわち、図４に示す例では、スロット番号（１）の第１スロットＴ１には、交差点Ｊ１とＪ５（図１参照）にある２つの路側通信機２の送信時間が割り当てられ、スロット番号（２）の第１スロットＴ１には、交差点Ｊ２，Ｊ６及びＪ８にある３つの路側通信機２の送信時間が割り当てられ、スロット番号（３）の第１スロットＴ１には、交差点Ｊ３にある１つの路側通信機２の送信時間が割り当てられている。

【0052】

このように、各路側通信機２の送信時間は、第１スロットＴ１に対して１対１対応で割り当てられるのではなく、互いに電波干渉が生じない交差点Ｊｉに設置された路側通信機２同士について、同じスロット番号ｉに重複して割り当て可能となっている。
かかるスロット割当は、中央装置４が総括的に行うこともできるし、他装置から取得した設置位置やスロット情報を利用して各路側通信機２が自律的に行うこともできる。
また、複数の路側通信機２，２…の中から１つの親機を予め選定しておき、この親機が、他の路側通信機２である子機同士で電波干渉が生じない送信タイミングとなるように、スロット割当を行うようにすることもできる。

【0053】

〔車載通信機〕
図３に戻り、車載通信機３は、無線通信のためのアンテナ３０を有する通信部（送受信部）３１と、この通信部３１に対する通信制御を行うプロセッサ等よりなる制御部３２と、この制御部３２に接続されたＲＯＭやＲＡＭ等の記憶装置よりなる記憶部３３とを備えている。
記憶部３３は、制御部（コンピュータ）３２が実行する通信制御処理のためのコンピュータプログラムや、各通信機２，３の通信機ＩＤ等を記憶している。制御部２３が実行する処理は、コンピュータプログラムが制御部３２によって実行されることで行われる。

【0054】

車載通信機３の制御部３２は、車車間通信のためのキャリアセンス方式による無線通信を通信部３１に行わせるものであり、路側通信機２との間の時分割多重方式での通信制御機能は有していない。
従って、車載通信機３の通信部３１は、所定の搬送波周波数の受信レベルを常時感知しており、その値がある閾値以上である場合は無線送信を行わず、当該閾値未満になった場合にのみ無線送信を行うようになっている。

【0055】

なお、車載通信機３の制御部３２は、車両５（車載通信機３）の現時の位置、方向及び速度等を含む車両情報（アプリケーションデータ）Ｓ３を含む通信パケットを、通信部３１を介して外部にブロードキャストで無線送信させている。
また、車載通信機３の制御部３２は、他の車両５から直接受信した車両情報Ｓ３や、路側通信機２から受信した他の車両５の車両情報Ｓ３に含まれる、位置、速度及び方向に基づいて、右直衝突や出合い頭衝突等を回避するための安全運転支援制御を行うことができる。

【0056】

更に、車載通信機３の制御部３２は、路側通信機２がブロードキャスト送信したタイムスロットの割当情報（アプリケーションデータ）Ｓ５を通信部３１が受信すると、この割当情報Ｓ５を含む通信フレームを生成し、この通信フレームの無線信号をブロードキャスト送信して他の車載通信機３に割当情報Ｓ５を転送する。
従って、路側通信機２がダウンリンク送信した無線信号と、その路側通信機２の送信エリア外の車載通信機３がブロードキャスト送信した無線信号とが、その路側通信機２の送信エリア内の車載通信機３に同時に届くことはない。

【0057】

［通信プロトコルスタック］
図５は、路側通信機２及び車載通信機３が準拠する非特許文献１に記載の通信プロトコルスタックを示している。
図５に示す機能に基づく処理は、路側通信機２の制御部２３及び車載通信機３の制御部３２によって実行される。

【0058】

図５に示すプロトコルスタックは、ＯＳＩ参照モデルを参照して各層が規定されており、レイヤ１（Ｌ１，物理層：Physical Layer）、レイヤ２（Ｌ２，データリンク層：Data Link Layer）、車車間・路車間共用通信制御情報層（ＩＶＣ−ＲＶＣ層：Inter-Vehicle Communication - Road to Vehicle Communication Layer）、及び、レイヤ７（Ｌ７，アプリケーション層：Application Layer）を有している。

【0059】

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

【0060】

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

【0061】

車車間・路車間共用通信制御情報層（ＩＶＣ−ＲＶＣ層）は、車車間・路車間共用通信制御に必要な情報の生成と管理を行う。非特許文献１では、路路間通信は規定されていないが、本実施形態のように、路路間通信を行う場合、車車間・路車間共用通信制御情報層（ＩＶＣ−ＲＶＣ層）において、路路間通信の通信制御に必要な情報の生成と管理を行うことができる。

【0062】

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

【0063】

ここで、路側通信機（基地局）２のアプリケーションとしては、車載通信機３又は他の路側通信機２に対して提供されるアプリケーションデータ（交通情報・車両情報など）の取得・生成を行い、そのアプリケーションデータをレイヤ７によって提供される通信制御手段によって送信するアプリケーションが含まれる。
また、路側通信機２のアプリケーションとしては、レイヤ７によって提供される通信制御手段によって車載通信機３又は他の路側通信機２から受信したアプリケーションデータ（交通情報・車両情報など）を取得し、処理又は転送するアプリケーションが含まれる。

【0064】

さらに、車載通信機３のアプリケーションとしては、他の車載通信機３又は路側通信機２に対して提供されるアプリケーションデータ（交通情報・車両情報など）の取得・生成を行い、そのアプリケーションデータをレイヤ７によって提供される通信制御手段によって送信するアプリケーションが含まれる。
また、車載通信機３のアプリケーションとしては、レイヤ７によって提供される通信制御手段によって他の車載通信機３又は路側通信機２から受信したアプリケーションデータ（交通情報・車両情報など）を取得し、処理又は転送するアプリケーションが含まれる。

【0065】

前述の各層Ｌ１，Ｌ２，ＩＶＣ−ＲＶＣ，Ｌ７における処理及びアプリケーションＡＰにおける処理は、前記制御部２３及び前記制御部３２によって実行される。
また、前記制御部２３及び前記制御部３２は、図５におけるセキュリティ管理（ＳＥＣ）の処理、及びシステム管理（ＳＭＥ）の処理も実行する。

【0066】

セキュリティ管理（ＳＥＣ）は、セキュリティ・サービスアクセスポイント（ＳＥＣ−ＳＡＰ）を介して、レイヤ７との間で、セキュリティ処理のために情報のやりとりをおこなう。具体的には、セキュリティ管理では、レイヤ７から取得したアンセキュアなアプリケーションデータをセキュアにしてレイヤ７に返す処理、及び、レイヤ７から取得したセキュアなアプリケーションデータをアンセキュアにしてレイヤ７に返す処理が行われる。

【0067】

システム管理（ＳＭＥ）は、レイヤマネジメントエンティティ（ＬＭＥ）を介して、各層Ｌ１，Ｌ２，ＩＶＣ−ＲＶＣ，Ｌ７との間で、システム管理に関する情報のやりとりをおこなう。

【0068】

［非特許文献１記載の通信パケットの構成］
図６は、路側通信機２及び車載通信機２によって送信される通信パケットの構成を示している。図６に示す通信パケットの構成は、基本的に、非特許文献１に準拠したものである。

【0069】

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

【0070】

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

【0071】

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

【0072】

図７（ａ）に示すように、ＭＡＣ制御フィールドは、フレーム制御フィールド、保持期間フィールド、宛先アドレスフィールド、送信元アドレスフィールド、無線局識別符号フィールド、及び送信カウント値フィールドを有している。

【0073】

ＭＡＣ制御フィールドに含まれる上記の各フィールドのうち、送信元アドレスフィールドには、送信元となる通信機２，３のＭＡＣアドレスが格納される。通信機２，３のＭＡＣアドレスは、単なるアドレスであるため、通信機２，３の種別を示すものではない。

【0074】

ＭＡＣ制御フィールドに含まれる上記の各フィールドのうち、宛先アドレスフィールドには、宛先のアドレスが格納される。ただし、非特許文献１において、宛先アドレスとしては、ブロードキャストアドレスのみが規定されている。非特許文献１において、宛先アドレスは、すべての基地局（路側通信機）２及び移動局（車載通信機）３が解釈しなければならないこととされている。

【0075】

したがって、図６に示す通信パケットが無線信号として送信されていることを検出した全ての路側通信機２及び車載通信機３は、当該通信パケットを自機（自局）２，３宛の通信パケットとして受信することになる。
ただし、通信パケットの受信側２，３のＭＡＣ層では、受信した通信パケットが、車車間通信パケット、路路間通信パケット、及び路車間通信パケットのうちのいずれであるのかは、区別できない。

【0076】

なお、ＭＡＣ制御フィールドに含まれる上記の各フィールドのうち、無線局識別符号フィールドには、無線局識別符号を格納することができるが、非特許文献１によると、無線局識別符号は、ＭＡＣ制御フィールドにおいて無視されることとなっている。
したがって、ＭＡＣ制御フィールドに含まれる各フィールドに格納される情報は、通信機２，３の種別を示すものではない。

【0077】

通信パケットの受信側２，３のＭＡＣ層は、受信に成功した通信パケットのＭＡＣフレーム（ＭＰＤＵ）から、ＭＡＣ制御フィールド等を取り除いたＬＬＣフレーム（ＬＰＤＵ；ＭＳＤＵ）を、ＬＬＣ層に与える。

【0078】

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

【0079】

図７（ｂ）に示すように、ＬＬＣ制御フィールドは、ＤＳＡＰ（Destination Service Access Point）アドレスフィールド、ＳＳＡＰ（Source Service Access Point）アドレスフィールド、制御フィールド、及びプロトコル識別子フィールドを有している。
非特許文献１において、ＬＬＣ制御フィールドにおける各フィールドに格納される情報は、通信機２，３の種別を示すものではない。

【0080】

通信パケットの受信側２，３のＬＬＣ層は、受信した通信パケットのＬＬＣフレーム（ＬＰＤＵ）から、ＬＬＣ制御フィールドを取り除いたＩＲフレーム（ＩＰＤＵ；ＬＳＤＵ）を、ＩＶＣ−ＲＶＣ層に与える。

【0081】

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

【0082】

図７（ｃ）に示すように、ＩＲ制御フィールドは、バージョンフィールド、識別情報フィールド、同期情報フィールド、予約フィールド、送信時刻フィールド、路車間通信期間情報フィールド、及び拡張領域フィールドを有している。

【0083】

識別情報フィールドに格納される識別情報は、送信元の識別に用いられる。識別情報フィールドは、４ビットのフィールドである。４ビットのうち、先頭ビットが送信元の識別に用いられ、送信元が基地局であれば「１」、送信元が移動局であれば「０」が格納される。したがって、識別情報フィールドに格納される識別情報は、送信元の通信機２，３の種別を示すものである。
なお、４ビットの識別情報フィールドのうち、先頭ビット以外の他のビットは、非特許文献１において、今後のための予約とされており、未定義である。

【0084】

なお、ＩＲ制御フィールドにおける予約フィールド（１ビット）は、今後のための予約とされている。
また、ＩＲ制御フィールドにおける拡張領域フィールド（１６ビット）も、今後のための予約フィールドとされている。

【0085】

非特許文献１によると、ＩＲ制御フィールドにおいて、識別情報フィールド以外の各フィールドに格納される情報は、通信機２，３の種別を示すものではない。

【0086】

通信パケットの受信側２，３のＩＶＣ−ＲＶＣ層は、受信した通信パケットのＩＲフレーム（ＩＰＤＵ）から、ＩＲ制御フィールドを取り除いたＡＰフレーム（ＡＰＤＵ；ＩＳＤＵ）を、レイヤ７に与える。

【0087】

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

【0088】

図７（ｄ）に示すように、レイヤ７ヘッダは、バージョンフィールド、セキュリティ区分情報フィールド、予約フィールド、及びアプリケーション関連情報フィールドを有している。

【0089】

レイヤ７ヘッダのセキュリティ区分情報フィールド（１ビット）には、セキュリティ区分情報が格納される。セキュリティ区分情報は、アプリケーションデータの処理を行う際に、セキュリティ管理ＳＥＣを経由するか否かを示す情報であり、「０」であればセキュリティ管理ＳＥＣを経由しないことを示し、「１」であればセキュリティ管理ＳＥＣを経由することを示す。

【0090】

レイヤ７ヘッダのアプリケーション関連情報フィールド（８ビット）には、送信側においてアプリケーションＡＰがレイヤ７に伝えるアプリケーション関連情報、又は、受信側においてレイヤ７がアプリケーションに伝えるアプリケーション関連情報が格納される。
非特許文献１では、アプリケーション関連情報の詳細は、規定されていない。

【0091】

レイヤ７ヘッダの予約フィールド（３ビット）は、今後のための予約とされている。

【0092】

非特許文献１によると、レイヤ７ヘッダの各フィールドに格納される情報は、通信機２，３の種別を示すものではない。

【0093】

送信側の通信機２，３のレイヤ７は、アプリケーションＡＰからアプリケーションデータを受け取った際に、セキュリティ管理ＳＥＣを経由しない旨の指示を受け取った場合には、アプリケーションＡＰから受け取ったアプリケーションデータ（アンセキュアなアプリケーションデータ）を、ＡＳＤＵとして取り扱う。つまり、アンセキュアなアプリケーションデータの前にレイヤ７ヘッダが付加される。この場合、レイヤ７ヘッダのセキュリティ区分情報フィールドには、セキュリティ管理ＳＥＣを経由しないことを示す「０」が格納される。

【0094】

受信側の通信機２，３のレイヤ７は、受信した通信パケットのレイヤ７ヘッダのセキュリティ区分情報に、セキュリティ管理ＳＥＣを経由しないことを示す「０」が格納されている場合、ＡＰＤＵからレイヤ７ヘッダを除いた部分をＡＳＤＵ（アンセキュアなアプリケーションデータ）として扱う。つまり、このＡＳＤＵ（アンセキュアなアプリケーションデータ）は、アプリケーションＡＰに与えられる。

【0095】

一方、送信側の通信機２，３のレイヤ７は、アプリケーションＡＰからアプリケーションデータを受け取った際に、セキュリティ管理ＳＥＣを経由する旨の指示を受け取った場合には、アプリケーションＡＰから受け取ったアプリケーションデータ（アンセキュアなアプリケーションデータ）を、セキュリティサービスアクセスポイントＳＥＣ−ＳＡＰを介して、セキュリティ管理ＳＥＣに渡す。

【0096】

セキュリティ管理ＳＥＣでは、レイヤ７から受け取ったアンセキュアなアプリケーションデータに対して、セキュリティ処理を行って、セキュアなアプリケーションデータを生成する。
図６に示すＡＳＤＵは、セキュリティ管理ＳＥＣによってセキュリティ処理が行われたセキュアなアプリケーションデータを示している。非特許文献１においてセキュアなアプリケーションデータの詳細についての規定はないが、セキュアなアプリケーションデータは、セキュリティ管理ヘッダ（セキュリティ管理のためのフィールド）及びアプリケーションデータ本体によって構成することができる。
セキュリティ管理ヘッダには、セキュリティ管理ＳＥＣによって、セキュリティ管理に関する情報が格納される。
なお、アプリケーションデータがセキュアである場合には、ＡＳＤＵに含まれる情報のうち、セキュリティ管理ヘッダは、制御フィールであるとみなす。

【0097】

セキュリティ管理ＳＥＣは、セキュリティ処理が施されたセキュアなアプリケーションデータを、セキュリティサービスアクセスポイントＳＥＣ−ＳＡＰを介して、レイヤ７に戻す。
レイヤ７は、セキュリティ管理ＳＥＣから与えられたセキュアなアプリケーションデータを、ＡＳＤＵとして取り扱う。つまり、セキュアなアプリケーションデータ(ＡＳＤＵ)の前にレイヤ７ヘッダが付加される。この場合、レイヤ７ヘッダのセキュリティ区分情報フィールドには、セキュリティ管理ＳＥＣを経由することを示す「１」が格納される。

【0098】

受信側の通信機２，３のレイヤ７は、受信した通信パケットのレイヤ７ヘッダのセキュリティ区分情報に、セキュリティ管理ＳＥＣを経由することを示す「１」が格納されている場合、ＡＰＤＵからレイヤ７ヘッダを除いた部分をセキュアなアプリケーションデータとして扱う。この場合、レイヤ７は、セキュアなアプリケーションデータを、セキュリティ管理ＳＥＣに渡す。

【0099】

セキュリティ管理ＳＥＣでは、レイヤ７から与えられたセキュアなアプリケーションデータをアンセキュアなアプリケーションデータにする処理が行われる。
セキュリティ管理ＳＥＣは、アンセキュアになったアプリケーションデータを、レイヤ７に戻す。
レイヤ７は、セキュリティ管理ＳＥＣから戻されたアンセキュアなアプリケーションデータをＡＳＤＵとして扱う。つまり、このＡＳＤＵ（アンセキュアなアプリケーションデータ）は、アプリケーションＡＰに与えられる。

【0100】

なお、セキュリティ管理ＳＥＣにおいて、アンセキュアなアプリケーションデータをセキュアなアプリケーションデータにする処理（セキュリティ処理）には、暗号化処理、署名処理などの処理が含まれる（ただし、非特許文献１では規定されていない）。
また、セキュリティ管理ＳＥＣにおいて、セキュアなアプリケーションデータをアンセキュアなアプリケーションデータにする処理には、暗号を復号化する処理、署名検証処理などの処理が含まれる（ただし、非特許文献１では規定されていない）。

【0101】

なお、アプリケーションデータへの暗号化処理は、アプリケーションデータを秘匿したい場合に行われる。例えば、路路間通信のアプリケーションデータには、機器の保守関連情報のように、車載通信機（移動局）３又は一部の路側通信機（基地局）２に対して、秘匿したい情報が含まれることがある。このような場合、アプリケーションデータは送信側にて暗号化され、受信側にて復号される。

【0102】

［非特許文献２の拡張レイヤ及び通信パケット構成］
図８は、図５のアプリケーションＡＰとレイヤ７との間の通信機能を拡張する拡張レイヤＥＬを示している。この拡張レイヤＥＬは非特許文献２のガイドラインに準拠したものである。非特許文献１の標準規格に加えて、非特許文献２のガイドラインにも準拠する路側通信機２及び車載通信機３の場合、拡張レイヤＥＬに基づく処理は、路側通信機２の制御部２３及び車載通信機３の制御部３２によって実行される。
なお、本実施形態に係る路側通信機２及び車載通信機３は、基本的に、非特許文献１の標準規格に加えて、非特許文献２のガイドラインにも準拠するものとする。

【0103】

拡張レイヤＥＬは、アプリケーションＡＰに対してデータ伝送サービスを提供する。アプリケーションＡＰは、送信される通信パケットに格納されるアプリケーションデータ（交通情報、車両情報など）を拡張レイヤＥＬに与える。データ伝送サービス提供のため、拡張レイヤＥＬは、レイヤ７以下の下位階層に対してデータ伝送要求を出す。

【0104】

また、拡張レイヤＥＬは、セキュリティサービスアクセスポイントＳＥＣ−ＳＡＰを介して、セキュリティ管理ＳＥＣとの間で、レイヤ７と同様に、セキュリティ処理のために情報のやりとりを行うことができる。
つまり、セキュリティ管理ＳＥＣは、レイヤ７及び拡張レイヤＥＬの双方との間で、情報のやりとりが可能である。

【0105】

図９は、図８に示す拡張レイヤＥＬに対応した通信パケット構成を示している。図９の通信パケットは、図６に示すＬ７ヘッダの後に、ＥＬヘッダ（ＥＬ基地局ヘッダ、ＥＬ移動局ヘッダ）を追加したものに相当する。

【0106】

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

【0107】

基地局（路側通信機）２によって付加されるＥＬヘッダ（ＥＬ基地局ヘッダ）は、図１０（ａ）に示すように、バージョンフィールド、ＥＬヘッダ種別フィールド、ＥＬセキュリティ区分情報フィールド、データ関連情報フィールド、分割番号フィールド、予約フィールドを有している。
移動局（車載通信機）３によって付加されるＥＬヘッダ（ＥＬ移動局ヘッダ）は、図１０（ｂ）に示すように、バージョンフィールド、ＥＬヘッダ種別フィールド、ＥＬセキュリティ区分情報フィールドを有している。

【0108】

ＥＬヘッダ種別フィールドは、ＥＬ基地局ヘッダとＥＬ移動局ヘッダを区別する情報が格納されるフィールドである。したがって、ＥＬヘッダ種別フィールドに格納される情報は、送信元の通信機２，３の種別を示すものである。

【0109】

ＥＬヘッダのセキュリティ区分情報フィールドは、レイヤ７ヘッダのセキュリティ区分情報フィールドと同じものである。
拡張レイヤＥＬは、セキュリティ管理ＳＥＣに、アンセキュアなアプリケーションデータをセキュアなアプリケーションデータにする処理、及び、セキュアなアプリケーションデータをアンセキュアなアプリケーションデータにする処理を実行させることに関し、レイヤ７と同様に動作する。

【0110】

ＥＬヘッダのデータ関連情報フィールド（１８ビット）には、アプリケーションデータの関連情報（Data Associated Information）が格納される。
ＥＬヘッダ（ＥＬ基地局ヘッダ）の予約フィールド（４ビット）は、今後のための予約である。

【0111】

図１０（ｃ）（ｄ）に示すように、アプリケーションデータの関連情報（Data Associated Information）としては、BaseStationID（基地局ＩＤ情報）、DataSequence（データ順番情報）、DataTotalNumber（データ総数情報）が設けられている。
BaseStationID（基地局ＩＤ情報）によって、送信元の基地局を個別に識別することができる。

【0112】

非特許文献２によると、ＥＬヘッダにおいて、ＥＬヘッダ種別フィールド以外の各フィールドに格納される情報は、通信機２，３の種別を示すものではない。

【0113】

［実施形態の通信パケット］
本実施形態の路側通信機２及び車載通信機３によって送信される通信パケットは、非特許文献１の標準規格だけに準拠する場合、基本的に、図６に示す構成と同じ構成を有し、非特許文献１の標準規格に加えて非特許文献２のガイドラインにも準拠する場合、基本的に、図９に示す構成と同じ構成を有する。

【0114】

本実施形態の路側通信機２及び車載通信機３によって送信される通信パケットが、非特許文献１及び２に記載のもの相違する点は、次の相違点１及び２に示す通りである。
なお、無線通信システム内には、次の相違点１及び２に示す相違点を有する通信パケットを送信することができる路側通信機２及び車載通信機３（実施形態に係る路側通信機２及び車載通信機３）だけでなく、非特許文献１及び２にのみに準拠した路側通信機２及び車載通信機３も含むことができる。

【0115】

本実施形態の路側通信機２及び車載通信機３によって送信される通信パケットは、基本的には非特許文献１及び２に準拠しているため、非特許文献１及び２にのみに準拠した車載通信機３（移動局）及び路側通信機２であっても、受信可能である。つまり、非特許文献１及び２に示す規格のみに準拠した車載通信機３（移動局）及び路側通信機２は、本実施形態に係る無線通信システムにおいても機能することができる。

【0116】

［相違点１：路路間通信における宛先アドレス］
非特許文献１に従うと、ＭＡＣ制御フィールドの宛先アドレスフィールドには、ブロードキャストアドレスのみが格納されることになるが、本実施形態の路側通信機２の制御部２３は、路側通信機２向け通信パケット（路路間通信パケット又は車路間通信パケット）を送信する際には、ＭＡＣ制御フィールドの宛先アドレスフィールドに、非ブロードキャストアドレスがセットされる。

【0117】

具体的には、本実施形態の路側通信機２の制御部２３（ＭＡＣ層）又は車載通信機３の制御部３２は、路側通信機向け通信パケットを送信する際には、宛先となる路側通信機２のアドレスを指定するユニキャストアドレス、又は、宛先として複数の路側通信機２を指定するマルチキャストアドレスを、ＭＡＣ制御フィールドの宛先アドレスフィールドに格納する。

【0118】

この場合、宛先となった路側通信機２は、ユニキャストアドレス又はマルチキャストアドレスによって自機（自局）が指定されているため、送信されてきた通信パケットを自機（自局）宛と判断して問題なく受信することができる。

【0119】

一方、宛先として指定されていない路側通信機２及び車載通信機３は、通信パケットを受信しても、ＭＡＣ層より上位階層で処理する前に、その通信パケットを破棄することができる。したがって、宛先として指定されていない車載通信機３等の処理負荷を軽減できる。
なお、宛先として指定されていない通信機２，３であっても、必要に応じて、ＭＡＣ層よりも上位階層での処理を行って、通信パケットに含まれるアプリケーションデータを取得してもよい。

【0120】

しかも、非特許文献１（及び２）のみに準拠した車載通信機３（全ての通信パケットがブロードキャストアドレスで送信されてくることを前提とした車載通信機３）においては、非ブロードキャストアドレスで送信されてきた通信パケットを、規格外の情報が格納されたイレギュラーなものとして、棄却することが期待される。
したがって、非特許文献１（及び２）のみに準拠した車載通信機３（全ての通信パケットがブロードキャストアドレスで送信されてくることを前提とした車載通信機３）と、路路間通信パケットはユニキャストアドレス又はマルチキャストアドレスで送信されてくることを前提とした車載通信機３）とを、同一の無線通信システム内に共存させることができる。

【0121】

ユニキャストでの路路間通信は、例えば、図１１に示す個別情報（アプリケーションデータ）の送信のために利用することができる。個別情報とは、特定の一の路側通信機２宛に送信されるべき情報をいい、例えば、第１の路側通信機２の近傍に設置された車両感知器６にて検出した情報を個別情報とすることができる。この場合、車両感知器６にて検出した情報は個別情報として、第１の路側通信機２Ａから、車両進行方向に位置する第２の路側通信機２Ｂ宛にユニキャスト送信される。

【0122】

マルチキャストでの路路間通信は、例えば、図１１に示す共通情報（アプリケーションデータ）の送信のために利用することができる。共通情報とは、複数の路側通信機２宛に共通して送信されるべき情報をいい、例えば、第１の路側通信機２の近傍に設置された交通信号機１の動作を示す情報を共通情報とすることができる。この場合、交通信号機１の動作を示す情報は、共通情報として、第１の路側通信機２Ａから、四方に位置する複数の路側通信機宛にマルチキャスト送信される。

【0123】

なお、本実施形態の路側通信機２の制御部２３（ＭＡＣ層）は、路路間通信パケット以外の通信パケット（路車間通信パケット）を送信する際には、非特許文献１に示すとおり、ＭＡＣ制御フィールドの宛先アドレスフィールドには、ブロードキャストアドレスをセットする。また、本実施形態の車載通信機２の制御部３２（ＭＡＣ層）は、車路間通信パケット以外の通信パケット（車車間通信パケット）を送信する際には、非特許文献１に示すとおり、ＭＡＣ制御フィールドの宛先アドレスフィールドには、ブロードキャストアドレスをセットする。

【0124】

［相違点２：宛先となる通信機の種別情報］
非特許文献１及び２によると、ＩＲ制御フィールドの識別情報フィールド（図７（ｃ）参照）、及び、ＥＬヘッダのＥＬヘッダ種別フィールド（図１０（ａ）（ｂ）参照）に格納される情報は、送信元の通信機２，３の種別を示す情報（種別情報；第１情報）として利用できる。しかし、宛先の通信機２，３の種別を示す情報は含まれていない。

【0125】

そこで、本実施形態の通信パケットには、アプリケーションデータ本体以外のフィールド（制御フィールド）に、宛先の通信機２，３の種別を示す情報（種別情報；第２情報）が追加されている。
宛先の通信機２，３の種別を示す情報が通信パケットに含まれていることで、受信側の通信機２，３は、路側通信機２から送信されたパケットが、他の路側通信機２向けのパケット（路路間通信パケット又は車路間通信パケット）であるのか、車載通信機３向けのパケット（路車間通信パケット又は車車間通信パケット）であるのかを区別することができる。

【0126】

したがって、車載通信機２は、路路間通信パケット又は車路間通信パケットを受信してしまっても（特に、路路間通信パケット又は車路間通信パケットがブロードキャストされた場合であっても）、宛先の通信機２，３の種別を示す第２情報を参照し、通信機種別が路側通信機（基地局）である場合には、アプリケーションデータ本体を読み取る前に、当該路路間通信パケットを破棄することができる。

【0127】

前述のように、宛先の通信機２，３の種別を示す情報（第２情報）は、図６に示す通信パケットにおける制御フィールド（ＰＨＹヘッダ、ＭＡＣ制御フィールド、ＬＬＣ制御フィールド、ＩＲ制御フィールド、Ｌ７ヘッダ、又はセキュリティ管理ヘッダ）に設けられている。
より具体的には、第２情報は、制御フィールドのうち、ＭＡＣ層よりも上位層において読み取られるフィールド（ＬＣ制御フィールド、ＩＲ制御フィールド、又はＬ７ヘッダ）、又は、当該上位層がアクセスする処理部（セキュリティ管理ＳＥＣ）において読み取られるフィールドに設けられる。

【0128】

第２情報を、ＭＡＣ層よりも上位層又は当該上位層がアクセスする処理部において読み取られる制御フィールドに設けることで、受信側の通信機２，３は、受信した通信パケットをＭＡＣ層にて破棄できない場合であっても（例えば、ＭＡＣ制御フィールドの宛先アドレスがブロードキャストアドレスである場合）、ＭＡＣ層よりも上位層にて破棄することが可能となる。
具体的には、例えば、車載通信機３は、受信した通信パケットの送信元の通信機２，３の種別を示す情報（第１情報）と宛先の通信機２，３の種別を示す情報（第２情報）とを参照し、送信元が路側通信機２であって、宛先も路側通信機２である場合には、受信した通信パケットは路路間通信パケットであると判定し、当該路路間通信パケットを破棄することができる。
また、車載通信機３は、受信した通信パケットの送信元の通信機２，３の種別を示す情報（第１情報）と宛先の通信機２，３の種別を示す情報（第２情報）とを参照し、送信元が車載通信機３であって、宛先が路側通信機２である場合には、受信した通信パケットは車路間通信パケットであると判定し、当該車路間通信パケットを破棄することができる。
なお、送信元の通信機種別を考慮せずに、宛先の通信機種別だけを考慮して、通信パケットを破棄するか否か判定してもよい。

【0129】

しかも、第１情報及び第２情報は、制御フィールドに設けられているため、受信側の通信機２，３のアプリケーションＡＰが、アプリケーションデータ（アプリケーションデータ本体）を読み取る前に、受信した通信パケットを破棄することができる。
したがって、読み取る必要のない通信パケットのアプリケーションデータ（例えば、車載通信機３にとっての路路間通信パケット又は車路間通信パケットのアプリケーションデータ）を、受信側の通信機２，３のアプリケーションＡＰが読み取って処理することによる処理負荷の発生を避けることができる。

【0130】

第２情報は、ＩＲ制御フィールド、Ｌ７ヘッダ、ＥＬヘッダ、及びセキュリティ管理ヘッダの少なくともいずれか一つに設けるのが更に好ましい。
ＩＲ制御フィールド、Ｌ７ヘッダ及びＥＬヘッダには、非特許文献１，２において、今後のために予約されたフィールド（空フィールド）が確保されているため、当該空フィールドに第２情報を格納することで、非特許文献１，２の規格との整合性を保ちつつ、第２情報を追加することができる。
また、セキュリティ管理ヘッダは、非特許文献１，２において規定されていないため、セキュリティ管理ヘッダに第２情報を格納することで、非特許文献１，２の規格との整合性を保ちつつ、第２情報を追加することができる。

【0131】

第２情報をＩＲ制御フィールドに設ける場合、ＩＲ制御フィールドの拡張領域フィールド（１６ビット）及び予約フィールド（１ビット）が予約フィールドであるため、当該拡張領域フィールド等に第２情報を格納するのに、好適である（図７参照）。
また、ＩＲ制御フィールドの識別情報フィールド（の先頭ビット）には、送信元が基地局であるか移動局であるかを識別する識別情報（通信機種別を示す第１情報）が格納されているため、受信側のＩＶＣ−ＲＶＣ層は、第１情報及び第２情報を読み取って、受信した通信パケットが路路間通信パケット又は車路間通信パケットであるか否かを判定し、路路間通信パケット又は車路間通信パケットであれば破棄することができる。
なお、識別情報フィールドの先頭ビット以外の３ビットには、送信元をさらに詳細に識別する情報を格納してもよい。

【0132】

第２情報をＬ７ヘッダに設ける場合、Ｌ７ヘッダの予約フィールド（３ビット）及び同じく予約フィールドであるアプリケーション関連情報フィールド（８ビット）のうちの少なくともいずれか一方に、第２情報を格納するのが好適である（図７参照）。なお、アプリケーション関連情報フィールドのほうが領域として大きいため、より好適である。
なお、第１情報も、Ｌ７ヘッダの予約フィールド（３ビット）及びアプリケーション関連情報フィールド（８ビット）のうちの少なくともいずれか一方に設けてもよいし、レイヤ７が、ＩＶＣ−ＲＶＣ層から第１情報（ＩＲ制御フィールドの識別情報）を取得してもよい。いずれの場合においても、受信側のレイヤ７は、受信した通信パケットが路路間通信パケット又は車路間通信パケットであるか否かを判定し、路路間通信パケット又は車路間通信パケットであれば破棄することができる。

【0133】

このように、第１情報と第２情報とは、同じレイヤで読み取られる制御フィールド（ヘッダ）に設けられていてもよいし、異なるレイヤで読み取られる制御フィールド（ヘッダ）に設けられていてもよい。

【0134】

第２情報をＥＬヘッダに設ける場合、ＥＬヘッダの予約フィールド（４ビット）に第２情報を格納するのが好適である。
第１情報として、ＥＬヘッダのＥＬヘッダ種別フィールドに格納されたＥＬヘッダ種別を用いる場合、受信側の拡張レイヤＥＬは、ＥＬヘッダ種別及び予約フィールド（４ビット）に格納された第２情報を参照することで、受信した通信パケットが路路間通信パケット又は車路間通信パケットであるか否かを判定し、路路間通信パケット又は車路間通信パケットであれば破棄することができる。

【0135】

また、拡張レイヤＥＬでは、BaseStationID（基地局ＩＤ情報）によって、送信元の基地局を個別に識別することができる。
路路間通信において、受信側の路側通信機２が、特定の路側通信機２からのアプリケーションデータだけを処理対象とし、それ以外の路側通信機２からのアプリケーションデータは処理対象としたくない場合がある。この場合、受信側の路側通信機２（の拡張レイヤＥＬ）は、受信した通信パケットが特定の路側通信機２からの路路間通信パケットであるか否かを、BaseStationID（基地局ＩＤ情報）を参照することによって判定し、特定の路側通信機２からの路路間通信パケットでなければ破棄することができる。

【0136】

第２情報をセキュリティ管理ヘッダに設ける場合、セキュリティ管理ヘッダの任意のフィールドに第２情報を格納することができる。また、第１情報も、セキュリティ管理ヘッダに設けてもよいし、セキュリティ管理ＳＥＣが、レイヤ７又は拡張レイヤＥＬから、第１情報を取得してもよい。いずれの場合においても、受信側のセキュリティ管理ＳＥＣは、受信した通信パケットが路路間通信パケット又は車路間通信パケットであるか否かを判定することができる。なお、セキュリティ管理が、路路間通信パケット又は車路間通信パケットであると判定した場合、その旨がレイヤ７に通知され、レイヤ７において路路間通信パケット車路間通信パケットを破棄することができる。

【0137】

なお、セキュリティ管理ＳＥＣにて、受信した通信パケットが路路間通信パケット又は車路間通信パケットであるか否かを判定しようとすると、処理がセキュリティ管理ＳＥＣへ移行し、必然的に、セキュリティ管理ＳＥＣにおいてセキュアなアプリケーションデータをアンセキュアなアプリケーションデータにする処理も行われることになる。
したがって、セキュリティ管理ＳＥＣにおける処理負荷を避けるには、受信側のレイヤ７又は拡張レイヤＥＬが、セキュリティ管理ＳＥＣにセキュアなアプリケーションデータを渡す前に、路路間通信パケット又は車路間通信パケットであるか否かの判定が行われるほうがよい。
つまり、受信側のセキュリティ管理ＳＥＣにおける処理負荷を避けるには、拡張レイヤ若しくはレイヤ７又はレイヤ７よりも下位層で、路路間通信パケット又は車路間通信パケットであるか否かの判定が行われるほうがよい。

【0138】

かかる観点からは、第１情報及び第２情報は、セキュリティ管理ヘッダよりも前側の制御フィールド（ＬＬＣ制御フィールド、ＩＲ制御フィールド、Ｌ７ヘッダ、ＥＬヘッダ）に設けられているのが好ましい。この場合、第１情報及び第２情報は、受信側のＬＬＣ層、ＩＶＣ−ＲＶＣ層、レイヤ７、又は拡張レイヤＥＬにおいて読み取られる。したがって、セキュリティ管理ＳＥＣがセキュアなアプリケーションデータをアンセキュアにする前に、パケットを破棄することができる。

【0139】

図１２は、路路間通信又は車路間通信とそれ以外の通信とを区別するため等に用いられる情報（第２情報を含む）の例を示している。
図１２に示す情報は、第２情報である宛先通信機種別（４ビット）と、情報種別／宛先ＩＤ等情報（４ビット）と、を有している。
図１２に示す情報は、計８ビットであるため、レイヤ７のアプリケーション関連情報フィールド（８ビット）、又はＩＲ制御フィールドの拡張領域フィールド（１６ビット）に設けられる情報として好適である。また、図１２に示す情報を、セキュリティ管理ヘッダに設けてもよい。

【0140】

宛先通信機種別は、「路」ビット、「車」ビット、「歩」ビット、及び「予約」ビットを有している。「路」ビットは、宛先の通信機種別が路側通信機（基地局）２であるか否かを示し、「車」ビットは、宛先の通信機種別が、移動局のうち車載通信機であるか否かを示し、「歩」ビットは、宛先の通信機種別が、移動局のうち歩行者が携帯する歩行者用通信機であるか否かを示し、「予約」ビットは、今後のための予約ビットである。

【0141】

各ビットにおいて「１」が格納されている場合、そのビットが示す通信機が宛先として含まれることを示し、「０」が格納されている場合、そのビットが示す通信機は宛先には含まれないことを示す。
なお、第２情報は、図１２に示すように４ビット必要なものではなく、基地局（路側通信機）と移動局（車載通信機）とを区別するためだけの情報であれば、１ビットあれば足りる。

【0142】

図１２に示す情報種別／宛先ＩＤ等情報は、路路間通信又は車路間通信の場合において宛先となる路側通信機２のＩＤ、又は、路路間通信及び路路間通信以外の通信形態（路車間通信、路歩間通信、車路間通信、車車間通信、車歩間通信）において送信されるアプリケーションデータ（又はその他のデータ）の情報種別を示す。

【0143】

情報種別／宛先ＩＤ等情報は、「種別／ＩＤ」ビットと、内容ビット（ｂ２，ｂ１，ｂ０）と、を有している。「種別／ＩＤ」ビットは、内容ビットが情報種別を示しているのか、宛先となる路側通信機２のＩＤを示しているかを表すフラグである。
内容ビット（ｂ２〜ｂ０）には、宛先となる路側通信機２のＩＤ、又は、情報種別を示す情報が格納される。

【0144】

宛先となる路側通信機２のＩＤが、例えば、Ｌ７ヘッダのアプリケーション関連情報フィールド又はＩＲ制御フィールドの拡張領域フィールドに格納されていると、受信側のレイヤ７又はＩＶＣ−ＲＶＣ層は、宛先となる路側通信機２のＩＤによって、宛先の路側通信機を個別に識別することができる。

【0145】

内容ビット（ｂ２〜ｂ０）に格納される情報種別としては、図１２に示すように、例えば、セキュリティ情報更新案内のための情報、緊急車両の緊急発動中であることを報知する情報、津波発生など災害情報を報知する情報である。
内容ビット（ｂ２〜ｂ０）に格納される情報は、アプリケーションデータとは別に、受信側によって処理される情報であってもよいし、アプリケーションデータの種別を示す情報であってもよい。

【0146】

情報種別が、例えば、Ｌ７ヘッダのアプリケーション関連情報フィールド又はＩＲ制御フィールドの拡張領域フィールドに格納されていると、受信側では、アプリケーションＡＰがアプリケーションデータを取得しなくても、レイヤ７又はＩＶＣ−ＲＶＣ層においては、情報種別を迅速に把握することができる。

【0147】

図１３は、路路間通信又は車路間通信とそれ以外の通信とを区別するため等に用いられる情報の他の例を示している。
図１３に示す情報は、第１情報である送信元通信機種別（２ビット）と、第２情報である宛先通信機種別（４ビット）と、データ種別（２ビット）と、を有している。
図１３に示す情報は、計８ビットであるため、レイヤ７のアプリケーション関連情報フィールド（８ビット）、又はＩＲ制御フィールドの拡張領域フィールド（１６ビット）に設けられる情報として好適である。また、図１３に示す情報を、セキュリティ管理ヘッダに設けてもよい。

【0148】

図１３に示す送信元通信機種別は、「００」の場合、送信元の通信機種別が路側通信機（基地局）２であることを示し、「０１」の場合、送信元の通信機種別が車載通信機３であることを示し、「１０」である場合、送信元の通信機種別が歩行者用通信機であることを示す。なお、「１１」は今後のための予約である。
なお、図１３に示す宛先通信機種別は、図１２に示す宛先通信機種別と同様である。

【0149】

図１３に示すデータ種別は、通常の情報であるか、緊急時情報（優先度の高い情報）であるかを示すものである。データ種別が「００」であれば、通常の情報であることを示し、「０１」であれば、緊急時情報であることを示す。

【0150】

図１４は、路路間通信又は車路間通信とそれ以外の通信とを区別するため等に用いられる情報の他の例を示している。
図１４に示す情報は、第１情報である送信元通信機種別（２ビット）と、第２情報である宛先通信機種別（３ビット）と、データ種別（３ビット）と、を有している。
図１４に示す情報は、計８ビットであるため、レイヤ７のアプリケーション関連情報フィールド（８ビット）、又はＩＲ制御フィールドの拡張領域フィールド（１６ビット）に設けられる情報として好適である。また、図１４に示す情報を、セキュリティ管理ヘッダに設けてもよい。

【0151】

図１４に示す送信元通信機種別は、図１３に示す送信元通信機種別と同様である。
図１４に示す宛先通信機情報は、「路」ビット、「全端末」ビット、及び「予約」ビットを有している。「路」ビットは、宛先の通信機種別が路側通信機（基地局）２であるか否かを示し、「路」ビットに「１」が格納されていれば、路側通信機２が宛先として含まれる。「全端末」ビットに「１」が格納されていれば、路側通信機、車載通信機、及び歩行者用通信機を含む全端末が、宛先となる。「予約」ビットは、今後のための予約ビットである。

【0152】

図１４に示すデータ種別は、通常の情報であるか、緊急時情報（優先度の高い情報）であるかを示すものである。データ種別が「０００」であれば、通常の情報であることを示し、「００１」であれば、緊急時情報であることを示す。

【0153】

図１５は、路路間通信又は車路間通信とそれ以外の通信とを区別するため等に用いられる情報の他の例を示している。
図１５に示す情報は、第１情報である送信元通信機種別（２ビット）と、第２情報である宛先通信機種別（３ビット）と、データ種別（３ビット）と、を有している。
図１４に示す情報は、計８ビットであるため、レイヤ７のアプリケーション関連情報フィールド（８ビット）、又はＩＲ制御フィールドの拡張領域フィールド（１６ビット）に設けられる情報として好適である。また、図１５に示す情報を、セキュリティ管理ヘッダに設けてもよい。

【0154】

図１５に示す送信元通信機種別及び宛先通信機種別は、図１４に示す送信元通信機種別及び宛先通信機種別と同様である。

【0155】

図１５に示すデータ種別は、アプリケーションデータとして送信される情報の種別を示している。データ（情報）の種別としては、「安全運転支援」に関する情報、「車両情報」、「保守情報」、「セキュリティ情報更新案内」に関する情報、「緊急走行中」であることを示す情報、「歩行者情報」、「津波発生」に関する情報などがあげられる。

【0156】

本発明に関して、今回開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は、上記した意味ではなく、特許請求の範囲と均等の意味及び範囲内でのすべての変更が含まれることが意図される。
例えば、第１情報と第２情報は、情報として区別可能に設けられている必要はなく、例えば、路路間通信、路車間通信、及び車車間通信を含む複数の通信形態（送信元種別と宛先種別によって区別される通信形態）の種類を区別する情報が設けられていれば、第１情報及び第２情報の両方が設けられていることに相当する。

【符号の説明】

【0157】

１ 交通信号機
２ 路側通信機（基地局）
３ 車載通信機（移動局）
４ 中央装置
５ 車両
６ 路側センサ
７ 有線通信回線
２３ 制御部
２４ 記憶部
３２ 制御部
３３ 記憶部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】