JP5362925B2 - 路側機および車載器 - Google Patents

Description

本発明は、通信技術に関し、特に所定の情報が含まれた信号を送受信する路側機および車載器に関する。

交差点の出会い頭の衝突事故を防止や渋滞の緩和を目的とした路車間通信による道路情報、あるいは交差点情報を提供したり、車車間通信による車両の運行情報の相互提供したりするための運転支援システムの検討がなされている。路車間通信では、路側機と車載器との間において交差点の状況に関する情報が通信される。路車間通信では、交差点や路側に路側機の設置が必要になり、手間と費用が大きくなる。これに対して、車車間通信、つまり車両に搭載された車載器間で情報を通信する形態であれば、路側機の設置が不要になる。その場合、例えば、ＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）等によって現在の位置情報をリアルタイムに検出し、その位置情報を車載器同士で交換しあうことによって、自車両および他車両がそれぞれ交差点へ進入するどの道路に位置するかを判断する（例えば、特許文献１参照）。

無線通信は、有線通信に比較して通信の傍受が容易になるので、通信内容の秘匿性を確保することが困難になる。また、ネットワーク経由で機器の制御を行う場合、第三者のなりすましにより不正な通信による操作が行われるおそれがある。無線通信において、通信内容の秘匿性を確保するためには、通信データを暗号化し、かつ、暗号化の際に使用する鍵を定期的に更新する必要がある。例えば、ネットワーク装置のそれぞれは、暗号鍵の更新の際、更新前に使用されている旧暗号鍵によって暗号化が行われたデータのみの送受信が可能な初期状態にある。この状態から、各装置は、旧暗号鍵および更新後の新暗号鍵によって暗号化が行われた双方のデータの送受信を行うことが可能で、新暗号鍵によって暗号化が行われたデータの送受信に関しては動作未確認の状態に移行する。さらに、各装置は、旧暗号鍵、新暗号鍵の双方で暗号化されたデータの送受信が可能であり、新暗号鍵で暗号化されたデータの送受信に関しても動作確認済みの状態に遷移する。最終的に、各装置は、鍵更新完了後の新暗号鍵によって暗号化されたデータのみの送受信が可能な状態に順次遷移する（例えば、特許文献２参照）。

特開２００５−２０２９１３号公報 特開２００７−１０４３１０号公報

無線ＬＡＮを車車間通信に適用する場合、不特定多数の端末装置へ情報を送信する必要があるために、信号はブロードキャストにて送信されることが望ましい。しかしながら、交差点などでは、車両数の増加、つまり端末装置数の増加がトラヒックを増加させることによって、パケット信号の衝突の増加が想定される。その結果、パケット信号に含まれたデータが他の端末装置へ伝送されなくなる。このような状態が、車車間通信において発生すれば、交差点の出会い頭の衝突事故を防止するという目的が達成されなくなる。さらに、車車間通信に加えて路車間通信が実行されれば、通信形態が多様になる。その際、車車間通信と路車間通信との間における相互の影響の低減が要求される。

このような状況において、なりすましやメッセージの改ざんを防止する目的のために、共通鍵暗号方式によって生成されたメッセージ認証コード（ＭＡＣ：Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）あるいは公開鍵暗号方式によって生成された電子署名がメッセージに添付される。受信側においては、メッセージ認証コードや電子署名によるメッセージの検証がなされる。ブロードキャストにて送信されたメッセージにメッセージ認証コードあるいは電子署名が付加されている場合、メッセージ認証コードあるいは電子署名によるメッセージの検証を所定の期間内に完了することが要求される。

本発明はこうした状況に鑑みてなされたものであり、その目的は、電子署名によるメッセージの検証を所定の期間内に完了させる技術を提供することにある。

上記課題を解決するために、本発明のある態様の端末装置は、複数のサブフレームを時間多重することによって形成されたスーパーフレームのうち、２つ以上のサブフレームのそれぞれにおいて、基地局装置からのパケット信号を周期的に受信する受信部と、受信部において受信したパケット信号をもとに、基地局装置からのパケット信号を受信したサブフレームに対して、優先順位を付与する解析部と、解析部において付与した優先順位のうち、高い優先順位が付与されたサブフレームにて受信したパケット信号を優先的に処理する処理部と、を備える。

本発明の別の態様もまた、通信装置である。この装置は、少なくともセキュリティヘッダとペイロードとをもとに、秘密鍵による電子署名を生成する生成部と、少なくともペイロードとセキュリティフッタとに対して、暗号化処理を実行する暗号化部と、少なくともセキュリティヘッダ、ペイロード、セキュリティフッタが配置されたセキュリティフレームを出力する出力部とを備える。生成部が生成すべき電子署名の対象となるセキュリティヘッダには、公開鍵証明書が含まれており、当該公開鍵証明書に対応した秘密鍵が電子署名を生成するために使用されており、暗号化部は、セキュリティヘッダを暗号化処理の対象から除外しており、セキュリティフッタには、生成部において生成した電子署名が含まれており、出力部から出力されるセキュリティフレームのうち、ペイロード、セキュリティフッタには、暗号化部による暗号化処理がなされている。

なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システム、記録媒体、コンピュータプログラムなどの間で変換したものもまた、本発明の態様として有効である。

本発明によれば、電子署名によるメッセージの検証を所定の期間内に完了できる。

本発明の実施例に係る通信システムの構成を示す図である。 図２（ａ）−（ｄ）は、図１の通信システムにおいて規定されるスーパーフレームのフォーマットを示す図である。 図３（ａ）−（ｂ）は、図２（ａ）−（ｄ）のサブフレームの構成を示す図である。 図４（ａ）−（ｆ）は、図１の通信システムにおいて規定される各レイヤのフレームのフォーマットを示す図である。 図４（ｅ）のセキュリティフレームのデータ構造を示す図である。 図５のメッセージタイプのデータ構造を示す図である。 図５の鍵ＩＤのデータ構造を示す図である。 図５の機器ＩＤのデータ構造を示す図である。 図５の公開鍵証明書のデータ構造を示す図である。 図５のＮｏｎｃｅのデータ構造を示す図である。 図５のデータ長のデータ構造を示す図である。 図１２（ａ）−（ｂ）は、図５の管理データのデータ構造を示す図である。 図１の基地局装置の構成を示す図である。 図１４（ａ）−（ｅ）は、図１３の基地局装置においてなされる署名生成処理の概要を示す図である。 図１５（ａ）−（ｄ）は、図１３の基地局装置においてなされる暗号化処理の概要を示す図である。 図１６（ａ）−（ｄ）は、図１３の基地局装置において生成されるセキュリティフレームのフォーマットを示す図である。 図１の車両に搭載された端末装置の構成を示す図である。 図１８（ａ）−（ｃ）は、図１７の端末装置においてなされるメッセージ認証コード生成の概要を示す図である。 図１９（ａ）−（ｄ）は、図１７の端末装置においてなされる暗号化処理の概要を示す図である。 図２０（ａ）−（ｂ）は、図１７の端末装置において生成されるセキュリティフレームのフォーマットを示す図である。 本発明の変形例に係る端末装置の構成を示す図である。 図２１の端末装置の受信処理の概要を示す図である。 図２１の端末装置による受信処理の手順を示すフローチャートである。 本発明の別の変形例に係る端末装置の構成を示す図である。 図２４の優先順位保持部に記憶されたテーブルのデータ構造を示す図である。 図２４の端末装置による受信処理の手順を示すフローチャートである。 本発明のさらに別の変形例に係る端末装置の受信処理の概要を示す図である。 本発明のさらに別の変形例に係る端末装置の受信処理の概要を示す図である。 変形例に係るセキュリティフレームのデータ構造例を示す図である。 変形例に係る優先順位にしたがったパケット信号の処理手順を示すフローチャートである。 優先順位切り替え処理を説明するための図（その１）である。 優先順位切り替え処理を説明するための図（その２）である。

本発明を具体的に説明する前に、概要を述べる。本発明の実施例は、車両に搭載された端末装置間において車車間通信を実行するとともに、交差点等に設置された基地局装置から端末装置へ路車間通信も実行する通信システムに関する。車車間通信として、端末装置は、車両の速度や位置等の自車両情報を格納したパケット信号をブロードキャストにより送信する（以下、パケット信号のブロードキャストによる送信を「報知」という）。また、他の端末装置は、パケット信号を受信するとともに、データをもとに車両の接近等を認識する。さらに、路車間通信として、基地局装置は、交差点情報および渋滞情報等が格納されたパケット信号を報知する。以下、説明を簡単にするために、車車間通信および路車間通信のパケット信号に含まれる情報の総称を「データ」という。

交差点情報には、交差点の位置、基地局装置が設置された交差点の撮影画像や、交差点内の車両の位置情報等の交差点の状況に関する情報が含まれる。端末装置は、この交差点情報をモニタに表示、この交差点情報をもとに交差点車両の状況を認識して、出会い頭・右折・左折による衝突防止を目的とした他の車両や歩行者の存在等をユーザに伝達し、事故の防止を図る。また、渋滞情報は、基地局装置が設置された交差点近辺の走路の混雑状況、道路工事や事故に関する情報が含まれる。この情報をもとに進行方向の渋滞をユーザに伝達、あるいは、迂回路を提示する。

このような通信では、データの完全性、真正性、機密性が望まれる。完全性とは、情報が改ざんされていないことを保障することであり、真正性とは、データの提供元を保証することであり、機密性とは、データが第三者に知られないことである。例えば、完全性のためには共通鍵暗号を用いたデータ認証子コードあるいは公開鍵暗号を用いた電子署名の付加が、真正性のためには、公開鍵証明書とデータへの電子署名（ＰＫＩ：公開鍵インフラストラクチャー）の付加が、機密性のためには、データの暗号化が行われる。これらの処理の量は互いに異なっており、必要に応じて適用されるべきである。車車間通信のトラヒックは路車間通信のトラヒックよりも多いので、車車間通信では、データの完全性および機密性を保証することとし、データ認証子コードの添付と、データの暗号化を行う。データ認証子コードを使用するのは、電子署名に比べてデータ量が少なく、検証処理が軽いためである。路車間通信では、完全性、真正性および機密性を保証し、路側機の公開鍵証明書、電子署名の添付、データの暗号化を行う。これは、車車間通信に比べて送信データ長に余裕があること、送信されるデータに信号機の情報などの重要な情報が含まれるためである。また、送信されるデータの種類によって、データの暗号化を行わない場合も、メッセージ認証コードあるいは電子署名を添付しない場合も対応する。

図１は、本発明の実施例に係る通信システム１００の構成を示す。これは、ひとつの交差点を上方から見た場合に相当する。通信システム１００は、基地局装置１０、車両１２と総称される第１車両１２ａ、第２車両１２ｂ、第３車両１２ｃ、第４車両１２ｄ、第５車両１２ｅ、第６車両１２ｆ、第７車両１２ｇ、第８車両１２ｈ、ネットワーク２０２を含む。なお、各車両１２には、図示しない端末装置が搭載されている。

図示のごとく、図面の水平方向、つまり左右の方向に向かう道路と、図面の垂直方向、つまり上下の方向に向かう道路とが中心部分で交差している。ここで、図面の上側が方角の「北」に相当し、左側が方角の「西」に相当し、下側が方角の「南」に相当し、右側が方角の「東」に相当する。また、ふたつの道路の交差部分が「交差点」である。第１車両１２ａ、第２車両１２ｂが、左から右へ向かって進んでおり、第３車両１２ｃ、第４車両１２ｄが、右から左へ向かって進んでいる。また、第５車両１２ｅ、第６車両１２ｆが、上から下へ向かって進んでおり、第７車両１２ｇ、第８車両１２ｈが、下から上へ向かって進んでいる。

通信システム１００は、交差点に基地局装置１０を配置する。基地局装置１０は、端末装置間の通信を制御する。基地局装置１０は、図示しないＧＰＳ衛星から受信した信号や、図示しない他の基地局装置１０にて形成されたスーパーフレームをもとに、複数のサブフレームが含まれたスーパーフレームを繰り返し生成する。ここで、各サブフレームの先頭部分に路車送信期間が設定可能であるような規定がなされている。基地局装置１０は、複数のサブフレームのうち、他の基地局装置１０によって路車送信期間が設定されていないサブフレームを選択する。基地局装置１０は、選択したサブフレームの先頭部分に路車送信期間を設定する。基地局装置１０は、設定した路車送信期間においてパケット信号を報知する。これが、前述の路車間通信に相当する。

端末装置は、基地局装置１０からのパケット信号を受信すると、パケット信号に含まれた情報をもとに、スーパーフレームを生成する。その結果、複数の端末装置のそれぞれにおいて生成されるスーパーフレームは、基地局装置１０において生成されるスーパーフレームに同期する。ここで、端末装置が、基地局装置１０からのパケット信号を受信できる場合、端末装置はエリア２１２に存在するといえる。端末装置は、エリア２１２に存在する場合、車車送信期間においてキャリアセンスにてパケット信号を報知する。これが、前述の車車間通信に相当する。

路車間通信では、公開鍵暗号方式における秘密鍵によって生成した電子署名と、この電子署名を検証する路側機の公開鍵証明書が添付される。電子署名とは、紙文書における印や署名に相当し、主に本人確認、偽造・かいざんの防止のために使用される。具体的に説明すると、ある文書についてその作成者として文書に記載されている者がある場合、その文書が本当にその作成名義人によって作成されたものであることは、紙の文書の場合、その文書に付されたその作成者の署名や印によって証明される。しかしながら、電子文書には直接印を押したり署名を付したりすることはできないので、これを証明するために、電子署名が使用される。電子署名を生成するためには、ハッシュ関数と公開鍵暗号が使用される。

電子署名として、公開鍵暗号方式に基づくデジタル署名が有力である。公開鍵暗号方式に基づく方式として、具体的には、ＲＳＡ、ＤＳＡ、ＥＣＤＳＡ等が使用される。電子署名方式は、鍵生成アルゴリズム、署名アルゴリズム、検証アルゴリズムによって構成される。鍵生成アルゴリズムは電子署名の事前準備に相当する。鍵生成アルゴリズムは、ユーザの公開鍵および秘密鍵を出力する。鍵生成アルゴリズムが実行される度に異なる乱数が選ばれ、路側機毎に異なる公開鍵・秘密鍵のペアが割り当てられる。公開鍵のさらに第三者によって電子署名を添付された公開鍵証明書の体をなしている。

路側機は、署名アルゴリズムによって電子署名を作成する際、データとともに自分の秘密鍵を入力する。署名に用いる秘密鍵を知っているのは、その秘密鍵をもつ路側機だけのはずなので電子署名を添付したデータの送信元を、識別する根拠となる。データと公開鍵証明書と電子署名を受け取ったユーザ端末装置は、予め公開されている路側機の公開鍵証明書検証用の認証鍵によって、添付された路側機の公開鍵証明書を検証し、発信元である路側機の正当性を確認する。正当性が確認されると、路側機の公開鍵証明書から公開鍵を取り出し、データに添付された電子署名を検証し、その結果を出力する。このような公開鍵暗号方式の検証処理の処理負荷は、一般的に重い。

一方、車車間通信では、共通鍵暗号方式によって生成されたメッセージ認証コードが添付されたパケット信号が報知される。共通鍵暗号方式では、送信側の端末装置と受信側の端末装置とが同一の鍵を用いる。受信側の端末装置にとって検証に用いる鍵が既知であり、鍵の証明書が不要になるので、公開鍵暗号方式と比較して伝送効率の悪化が抑制される。また、同じ鍵を持たない場合、データ認証コードが確認できないため、データの完全性は保証される。共通鍵暗号は、ＤＥＳ、ＡＥＳなどがある。なお、データの暗号化は、路車間通信も車車間通信も共通鍵暗号方式が用いられる。

図２（ａ）−（ｄ）は、通信システム１００において規定されるスーパーフレームのフォーマットを示す。図２（ａ）は、スーパーフレームの構成を示す。スーパーフレームは、第１サブフレームから第Ｎサブフレームと示されるＮ個のサブフレームによって形成されている。例えば、スーパーフレームの長さが１００ｍｓｅｃであり、Ｎが８である場合、１２．５ｍｓｅｃの長さのサブフレームが規定される。Ｎは、８以外であってもよい。図２（ｂ）は、第１基地局装置１０ａによって生成されるスーパーフレームの構成を示す。第１基地局装置１０ａは、基地局装置１０のうちの任意のひとつに相当する。第１基地局装置１０ａは、第１サブフレームの先頭部分に路車送信期間を設定する。また、第１基地局装置１０ａは、第１サブフレームにおいて路車送信期間に続いて車車送信期間を設定する。車車送信期間とは、端末装置がパケット信号を報知可能な期間である。つまり、第１サブフレームの先頭期間である路車送信期間において第１基地局装置１０ａはパケット信号を報知可能であり、かつフレームのうち、路車送信期間以外の車車送信期間において端末装置がパケット信号を報知可能であるような規定がなされる。さらに、第１基地局装置１０ａは、第２サブフレームから第Ｎサブフレームに車車送信期間のみを設定する。

図２（ｃ）は、第２基地局装置１０ｂによって生成されるスーパーフレームの構成を示す。第２基地局装置１０ｂは、第１基地局装置１０ａとは異なった基地局装置１０に相当する。第２基地局装置１０ｂは、第２サブフレームの先頭部分に路車送信期間を設定する。また、第２基地局装置１０ｂは、第２サブフレームにおける路車送信期間の後段、第１サブフレーム、第３サブフレームから第Ｎサブフレームに車車送信期間を設定する。図２（ｄ）は、第３基地局装置１０ｃによって生成されるスーパーフレームの構成を示す。第３基地局装置１０ｃは、第１基地局装置１０ａや第２基地局装置１０ｂとは異なった基地局装置１０に相当する。第３基地局装置１０ｃは、第３サブフレームの先頭部分に路車送信期間を設定する。また、第３基地局装置１０ｃは、第３サブフレームにおける路車送信期間の後段、第１サブフレーム、第２サブフレーム、第４サブフレームから第Ｎサブフレームに車車送信期間を設定する。このように、複数の基地局装置１０は、互いに異なったサブフレームを選択し、選択したサブフレームの先頭部分に路車送信期間を設定する。

図３（ａ）−（ｂ）は、サブフレームの構成を示す。図示のごとく、ひとつのサブフレームは、路車送信期間、車車送信期間の順に構成される。路車送信期間では、基地局装置１０がパケット信号を報知し、車車送信期間は、所定の長さを有し、かつ端末装置がパケット信号を報知可能である。図３（ｂ）は、路車送信期間におけるパケット信号の配置を示す。図示のごとく、路車送信期間において、複数のＲＳＵパケット信号が並べられている。ここで、前後のパケット信号は、ＳＩＦＳ（Ｓｈｏｒｔ Ｉｎｔｅｒｆｒａｍｅ Ｓｐａｃｅ）だけ離れている。

図４（ａ）−（ｆ）は、通信システム１００において規定される各レイヤのフレームのフォーマットを示す。図４（ａ）は、物理レイヤのフレームフォーマットを示す。図示のごとく、フレームには、ＰＬＣＰプリアンブル、ＰＬＣＰヘッダ、ＰＳＤＵ（Ｐｈｙｓｉｃａｌ Ｌａｙｅｒ Ｓｅｒｖｉｃｅ Ｄａｔａ Ｕｎｉｔ）、テールが順に配置される。図４（ｂ）は、ＭＡＣレイヤのフレームフォーマットを示す。このフレームは、図４（ａ）のＰＳＤＵに格納される。図示のごとく、フレームには、ＭＡＣヘッダ、ＭＳＤＵ（ＭＡＣ Ｌａｙｅｒ Ｓｅｒｖｉｃｅ Ｄａｔａ Ｕｎｉｔ）、ＦＣＳが順に配置される。図４（ｃ）は、ＬＬＣレイヤのフレームフォーマットを示す。このフレームは、図４（ｂ）のＭＳＤＵに格納される。図示のごとく、フレームには、ＬＬＣヘッダ、ＬＳＤＵ（ＬＬＣ Ｌａｙｅｒ Ｓｅｒｖｉｃｅ Ｄａｔａ Ｕｎｉｔ）が順に配置される。

図４（ｄ）車車間・路車間共用通信制御情報レイヤのフレームフォーマットを示す。このフレームは、図４（ｃ）のＬＳＤＵに格納される。図示のごとく、フレームには、ＲＳＵ制御ヘッダ、ＡＰＤＵ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）が順に配置される。図４（ｅ）は、セキュリティレイヤのフレームフォーマットを示す。このフレームは、図４（ｄ）のＡＰＤＵに格納される。図示のごとく、フレームには、セキュリティヘッダ、ＳＰＤＵ（Ｓｅｃｕｒｉｔｙ Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）、セキュリティフッタが順に配置される。図４（ｆ）は、アプリケーションレイヤのフレームフォーマットを示す。このフレームは、図４（ｅ）のＳＰＤＵに格納されており、アプリケーションデータによって構成される。なお、以上のフレームを単に「パケット信号」ということもある。

図５は、セキュリティフレームのデータ構造を示す。これは、図４（ｅ）の内容を詳細にした図である。図中のペイロードは、図４（ｅ）のＳＰＤＵに相当する。また、図中の管理データは、オプションであり、図４（ｅ）には示されていない。ここで、発信元情報、ペイロード、データ認証のデータ長さが可変である。発信元情報は、共通鍵方式を使用している場合、機器識別番号（機器ＩＤ）４バイトであり、公開鍵方式を使用している場合、発信元の機器ＩＤを含んだ公開鍵証明書１１１バイトである。また、データ認証は、共通鍵方式の場合、メッセージ認証コード１２バイトであり、公開鍵方式の場合、電子署名５６バイトである。ここでは、共通鍵方式におけるメッセージ認証コードは、ＡＥＳ１２８ビット、ＣＢＣモードにより暗号化されたデータの最終ブロック（１６バイト）の先頭から１２バイトである。また、公開鍵方式における電子署名は、２２４ビットの楕円曲線暗号を用いたＥＣＤＡＳアルゴリズムによってもとめられた５６バイトである。ハッシュ関数としてはＳＨＡ−２２４を用いるものとする。

図６は、メッセージタイプのデータ構造を示す。メッセージタイプは０．５バイトにて構成されている。認証方式として、共通鍵方式は車車間通信に使用され、公開鍵方式は路車間通信に使用される。メッセージ形式がデータ認証付きデータである場合、電子署名やメッセージ認証コードが添付される。メッセージ形式が認証付き暗号化データである場合、電子署名やメッセージ認証コードの添付に加えてデータ暗号化がなされる。メッセージ形式が平文である場合、電子署名やメッセージ認証コードが添付されず、かつデータ暗号化もなされていない。

図７は、鍵ＩＤのデータ構造を示す。鍵ＩＤは２バイトにて構成されている。テーブル番号は、共通鍵のテーブル識別番号を示し、鍵番号は、共通鍵テーブル内での識別番号を示す。発信時には、鍵番号がランダムに選択される。図８は、機器ＩＤのデータ構造を示す。機器ＩＤは４バイトにて構成されており、メッセージ認証コードのときに使用される。種別には、機器の種類、機器が搭載されている車両の種類が示されている。個別種別には、各機器を識別するための識別番号が示されている。

図９は、公開鍵証明書のデータ構造を示す。公開鍵証明書には、図８の機器ＩＤが含まれている。また、公開鍵証明書は、電子署名のときに使用される。図１０は、Ｎｏｎｃｅのデータ構造を示す。Ｎｏｎｃｅは６バイトにて構成されている。また、Ｎｏｎｃｅは、時計機能の有無・精度により選択して設定される。図１１は、データ長のデータ構造を示す。データ長は１バイトから２バイトにて構成される。図示のごとく、車車間通信と路車間通信とでは、異なったデータ長が規定される。図１２（ａ）−（ｂ）は、管理データのデータ構造を示す。図１２（ａ）は、通知コードのデータ構造を示す。図１２（ｂ）は、通知コードの通知内容を示す。

図１３は、基地局装置１０の構成を示す。基地局装置１０は、アンテナ２０、ＲＦ部２２、変復調部２４、ＭＡＣフレーム処理部２６、セキュリティ処理部２８、制御部３０、ネットワーク通信部３２を含む。また、セキュリティ処理部２８は、データ認証処理部３４、暗号化処理部３６を含む。

ＲＦ部２２は、受信処理として、図示しない端末装置や他の基地局装置１０からのパケット信号をアンテナ２０にて受信する。ＲＦ部２２は、受信した無線周波数のパケット信号に対して周波数変換を実行し、ベースバンドのパケット信号を生成する。さらに、ＲＦ部２２は、ベースバンドのパケット信号を変復調部２４に出力する。一般的に、ベースバンドのパケット信号は、同相成分と直交成分によって形成されるので、ふたつの信号線が示されるべきであるが、ここでは、図を明瞭にするためにひとつの信号線だけを示すものとする。ＲＦ部２２には、ＬＮＡ（Ｌｏｗ Ｎｏｉｓｅ Ａｍｐｌｉｆｉｅｒ）、ミキサ、ＡＧＣ、Ａ／Ｄ変換部も含まれる。

ＲＦ部２２は、送信処理として、変復調部２４から入力したベースバンドのパケット信号に対して周波数変換を実行し、無線周波数のパケット信号を生成する。さらに、ＲＦ部２２は、路車送信期間において、無線周波数のパケット信号をアンテナ２０から送信する。また、ＲＦ部２２には、ＰＡ（Ｐｏｗｅｒ Ａｍｐｌｉｆｉｅｒ）、ミキサ、Ｄ／Ａ変換部も含まれる。

変復調部２４は、受信処理として、ＲＦ部２２からのベースバンドのパケット信号に対して、復調を実行する。さらに、変復調部２４は、復調した結果から、ＭＡＣフレームをＭＡＣフレーム処理部２６に出力する。また、変復調部２４は、送信処理として、ＭＡＣフレーム処理部２６からのＭＡＣフレームに対して、変調を実行する。さらに、変復調部２４は、変調した結果をベースバンドのパケット信号としてＲＦ部２２に出力する。ここで、通信システム１００は、ＯＦＤＭ（Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘｉｎｇ）変調方式に対応するので、変復調部２４は、受信処理としてＦＦＴ（Ｆａｓｔ Ｆｏｕｒｉｅｒ Ｔｒａｎｓｆｏｒｍ）も実行し、送信処理としてＩＦＦＴ（Ｉｎｖｅｒｓｅ Ｆａｓｔ Ｆｏｕｒｉｅｒ Ｔｒａｎｓｆｏｒｍ）も実行する。

ＭＡＣフレーム処理部２６は、受信処理として、変復調部２４からのＭＡＣフレームから、セキュリティフレームを取り出し、セキュリティ処理部２８に出力する。ＭＡＣフレーム処理部２６は、送信処理として、セキュリティ処理部２８からのセキュリティフレームに対して、ＭＡＣヘッダ、ＬＬＣヘッダ、およびＲＳＵ制御ヘッダを付加し、ＭＡＣフレームを生成し、変復調部２４に出力する。また、他の基地局装置あるいは端末装置からのパケット信号がぶつからないようにタイミング制御をする。

データ認証処理部３４は、送信処理として、ネットワーク通信部３２からのアプリケーションデータを受けつける。これは、図４（ｆ）のアプリケーションデータに相当する。データ認証処理部３４は、アプリケーションデータをペイロードに格納する。また、データ認証処理部３４は、図５から図１０に示されたセキュリティヘッダを生成する。その際、図９に示した公開鍵証明書が添付されるが、それが発信者認証に相当する。また、図６に示したメッセージ認証が、データ認証付きデータであるか、認証付き暗号化データである場合、データ認証処理部３４は、セキュリティヘッダとペイロードに対して電子署名を生成する。

そのため、電子署名の対象となるセキュリティヘッダには、公開鍵証明書が含まれており、当該公開鍵証明書に対応した秘密鍵が電子署名を生成するために使用されている。データ認証処理部３４は、電子署名をセキュリティフッタに格納する。なお、管理データが含まれている場合、データ認証処理部３４は、セキュリティヘッダ、管理データ、ペイロードをもとに、秘密鍵による電子署名を生成する。一方、図６に示したメッセージ認証が、平文である場合、データ認証処理部３４は、電子署名を生成しない。その際、データ認証処理部３４は、セキュリティフッタにダミーデータを格納する。

図１４（ａ）−（ｅ）は、基地局装置１０においてなされる署名生成処理の概要を示す。図１４（ａ）は、データ認証処理部３４での処理対象となるセキュリティヘッダ、管理データ、ペイロードを示す。図１４（ｂ）は、データ認証処理部３４において、セキュリティヘッダ、管理データ、ペイロードに対してなされるＳＨＡ−２２４の演算を示す。ＳＨＡ−２２４（Ｓｅｃｕｒｅ Ｈａｓｈ Ａｌｇｏｒｉｔｈｍ）は、一群の関連したハッシュ関数である。図１４（ｃ）は、ＳＨＡ−２２４の結果であるハッシュ値を示す。ハッシュ値は、２８バイトの固定長である。図１４（ｄ）は、データ認証処理部３４において、ハッシュ値に対してなされるＥＣＤＳＡ署名の演算を示す。図１４（ｅ）は、ＥＣＤＳＡ署名の演算結果である電子署名を示す。電子署名は、５６バイトの固定長である。図１３に戻る。

暗号化処理部３６は、図６に示したメッセージ認証が、認証付き暗号化データである場合に、データ認証処理部３４からのペイロードとセキュリティフッタとを受けつける。前述のごとく、セキュリティフッタには、データ認証処理部３４において生成した電子署名が含まれている。暗号化処理部３６は、ペイロードとセキュリティフッタとに対して、暗号化処理を実行する。暗号化には、例えば、ＡＥＳ１２８−ＣＴＲが使用される。なお、管理データが含まれている場合、暗号化処理部３６は、管理データ、ペイロード、セキュリティフッタに対して、暗号化処理を実行する。ここで、暗号化処理部３６は、セキュリティヘッダを暗号化処理の対象から除外する。

図１５（ａ）−（ｄ）は、基地局装置１０においてなされる暗号化処理の概要を示す。図１５（ａ）は、暗号化処理部３６における暗号化に使用される暗号鍵の構成を示す。図示のごとく、暗号鍵は１６バイトの固定長である。図１５（ｂ）は、暗号化処理部３６における暗号化処理のための演算を示す。図示のごとく、暗号化は、暗号鍵によって１６バイト単位になされる。具体的に説明すると、暗号化処理部３６は、管理データとペイロードとのサイズが１６バイトの整数倍になるように、パディングを挿入するとともに、署名のサイズも１６バイトの整数倍になるように、８バイトのパディングを挿入する。図１５（ｃ）は、暗号化の結果を示す。図示のごとく、暗号化管理データ、暗号化ペイロード、暗号化署名が生成される。図１５（ｄ）は、暗号化処理部３６からの出力を示す。図示のごとく、暗号化管理データ、暗号化ペイロード、暗号化署名が一体的に出力される。図１３に戻る。

セキュリティ処理部２８は、図４（ｅ）、図５のごとく、少なくともセキュリティヘッダ、ペイロード、セキュリティフッタが配置されたセキュリティフレームを出力する。管理データが含まれていることもある。なお、メッセージ認証が、認証付き暗号化データである場合、セキュリティフレームのうち、ペイロード、セキュリティフッタは、暗号化されている。管理データが含まれている場合、管理データも暗号化されている。図１６（ａ）−（ｄ）は、基地局装置１０において生成されるセキュリティフレームのフォーマットを示す。図１６（ａ）は、管理データが含まれていない場合を示す。図１６（ｂ）は、管理データのうち、通知コードおよび機器ＩＤのみが含まれている場合を示す。図１６（ｃ）は、管理データにパラメータが含まれている場合を示す。図１６（ｄ）は、管理データのみが含まれ、ペイロードが含まれていない場合を示す。これらの図に示されているように、メッセージ形式が、データ認証付きデータであるか、認証付き暗号化データであるか、平文であるかにかかわらず、セキュリティフレームのフォーマットは共通である。図１３に戻る。セキュリティ処理部２８は、セキュリティフレームをＭＡＣフレーム処理部２６へ出力する。

セキュリティ処理部２８は、受信処理として、ＭＡＣフレーム処理部２６からのセキュリティフレームを受けつける。セキュリティ処理部２８は、セキュリティフレームのうちのセキュリティヘッダの内容を確認する。メッセージ形式がデータ認証付きデータである場合、データ認証処理部３４は、メッセージの検証処理を実行する。メッセージ形式が認証付き暗号化データである場合、データ認証処理部３４は、メッセージの検証処理を実行し、暗号化処理部３６は、復号処理を実行する。なお、メッセージ形式が平文である場合、これらの処理は省略される。ここで、セキュリティフレームの送信元が他の基地局装置１０である場合、データ認証処理部３４や暗号化処理部３６は、前述の電子署名の生成処理や暗号化処理に対応したメッセージの検証処理や復号処理を実行する。さらに、データ認証処理部３４は、セキュリティフレームに含まれた公開鍵証明書をもとに、機器認証も実行する。一方、セキュリティフレームの送信元が端末装置である場合、データ認証処理部３４や暗号化処理部３６は、端末装置においてなされる電子署名の生成処理や暗号化処理に対応したメッセージの検証処理や復号処理を実行する。端末装置においてなされる電子署名の生成処理や暗号化処理は後述する。セキュリティ処理部２８は、処理結果をネットワーク通信部３２へ出力する。

ネットワーク通信部３２は、図示しないネットワークに接続される。ネットワーク通信部３２は、セキュリティ処理部２８での処理結果を図示しないネットワークへ出力したり、内部に蓄積して、定期的に図示しないネットワークへ出力したりする。ネットワーク通信部３２は、図示しないネットワークから道路情報（工事、渋滞など）を受けつける。制御部３０は、基地局装置１０全体の処理を制御する。

この構成は、ハードウエア的には、任意のコンピュータのＣＰＵ、メモリ、その他のＬＳＩで実現でき、ソフトウエア的にはメモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。

図１７は、車両１２に搭載された端末装置１４の構成を示す。端末装置１４は、アンテナ５０、ＲＦ部５２、変復調部５４、ＭＡＣフレーム処理部５６、セキュリティ処理部５８、受信処理部６０、データ生成部６２、通知部７０、制御部７２を含む。また、セキュリティ処理部５８は、データ認証処理部６４、暗号化処理部６６を含む。アンテナ５０、ＲＦ部５２、変復調部５４、ＭＡＣフレーム処理部５６は、図１３のアンテナ２０、ＲＦ部２２、変復調部２４、ＭＡＣフレーム処理部２６と同様の処理を実行する。そのため、ここでは、同様の処理の説明を割愛し、差異を中心に説明する。

データ認証処理部６４は、送信処理として、データ生成部６２からのアプリケーションデータを受けつける。これは、図４（ｆ）のアプリケーションデータに相当する。データ認証処理部６４は、アプリケーションデータをペイロードに格納する。また、データ認証処理部６４は、図５から図１０に示されたセキュリティヘッダを生成する。また、図６に示したメッセージ認証が、データ認証付きデータであるか、認証付き暗号化データである場合、データ認証処理部６４は、セキュリティヘッダとペイロードとをもとに、共通鍵によるメッセージ認証コードを生成する。

データ認証処理部６４は、メッセージ認証コードをセキュリティフッタに格納する。なお、管理データが含まれている場合、データ認証処理部６４は、セキュリティヘッダ、管理データ、ペイロードをもとに、共通鍵によるメッセージ認証コードを生成する。一方、図６に示したメッセージ認証が、平文である場合、データ認証処理部６４は、メッセージ認証コードを生成しない。その際、データ認証処理部６４は、セキュリティフッタにダミーデータを格納する。

図１８（ａ）−（ｃ）は、端末装置１４においてなされるメッセージ認証コード生成の概要を示す。図１８（ａ）は、データ認証処理部６４での処理対象となるセキュリティヘッダ、管理データ、ペイロードを示す。データ認証処理部６４は、セキュリティヘッダのサイズが３２バイトになるようにパディングを挿入するとともに、管理データとペイロードとのサイズが１６バイトの整数倍になるように、パディングを挿入する。図１８（ｂ）は、データ認証処理部６４において、パディングが挿入されたセキュリティヘッダ、管理データ、ペイロードに対してなされるＡＥＳ１２８−ＣＢＣモード暗号処理の演算を示す。図１８（ｃ）は、暗号結果を示すとともに、暗号結果から生成されるメッセージ認証コードを示す。メッセージ認証コードは、１２バイトの固定長である。図１７に戻る。

暗号化処理部６６は、図６に示したメッセージ認証が、認証付き暗号化データである場合に、データ認証処理部６４からのペイロードとセキュリティフッタとを受けつける。前述のごとく、セキュリティフッタには、データ認証処理部６４において生成したメッセージ認証コードが含まれている。暗号化処理部６６は、ペイロードとセキュリティフッタとに対して、暗号化処理を実行する。暗号化には、例えば、ＡＥＳ−ＣＴＲが使用される。なお、管理データが含まれている場合、暗号化処理部６６は、管理データ、ペイロード、セキュリティフッタに対して、暗号化処理を実行する。ここで、暗号化処理部６６は、セキュリティヘッダを暗号化処理の対象から除外する。

図１９（ａ）−（ｄ）は、端末装置１４においてなされる暗号化処理の概要を示す。図１９（ａ）は、暗号化処理部６６における暗号化に使用される暗号鍵の構成を示す。図示のごとく、暗号鍵は１６バイトの固定長である。図１９（ｂ）は、暗号化処理部６６における暗号化処理のための演算を示す。図示のごとく、暗号化は、暗号鍵によって１６バイト単位になされる。具体的に説明すると、暗号化処理部６６は、管理データとペイロードとのサイズが１６バイトの整数倍になるように、パディングを挿入するとともに、メッセージ認証コードのサイズも１６バイトの整数倍になるように、４バイトのパディングを挿入する。図１９（ｃ）は、暗号化の結果を示す。図示のごとく、暗号化管理データ、暗号化ペイロード、暗号化メッセージ認証コードが生成される。図１９（ｄ）は、暗号化処理部６６からの出力を示す。図示のごとく、暗号化管理データ、暗号化ペイロード、暗号化メッセージ認証コードが一体的に出力される。図１７に戻る。

セキュリティ処理部５８は、図４（ｅ）、図５のごとく、少なくともセキュリティヘッダ、ペイロード、セキュリティフッタが配置されたセキュリティフレームを出力する。管理データが含まれていることもある。なお、メッセージ認証が、認証付き暗号化データである場合、セキュリティフレームのうち、ペイロード、セキュリティフッタは、暗号化されている。管理データが含まれている場合、管理データも暗号化されている。図２０（ａ）−（ｂ）は、端末装置１４において生成されるセキュリティフレームのフォーマットを示す。図２０（ａ）は、管理データが含まれていない場合を示す。図２０（ｂ）は、管理データが含まれている場合を示す。図１７に戻る。セキュリティ処理部５８は、セキュリティフレームをＭＡＣフレーム処理部５６へ出力する。

セキュリティ処理部５８は、受信処理として、ＭＡＣフレーム処理部２６からのセキュリティフレームを受けつける。セキュリティ処理部５８は、セキュリティフレームのうちのセキュリティヘッダの内容を確認する。メッセージ形式がデータ認証付きデータである場合、データ認証処理部６４は、メッセージの検証処理を実行する。メッセージ形式が認証付き暗号化データである場合、データ認証処理部６４は、メッセージの検証処理を実行し、暗号化処理部６６は、復号処理を実行する。なお、メッセージ形式が平文である場合、これらの処理は省略される。ここで、セキュリティフレームの送信元が他の端末装置１４である場合、データ認証処理部６４や暗号化処理部６６は、前述の電子署名の生成処理や暗号化処理に対応したメッセージの検証処理や復号処理を実行する。一方、セキュリティフレームの送信元が基地局装置１０である場合、データ認証処理部６４や暗号化処理部６６は、既に説明した基地局装置１０においてなされる電子署名の生成処理や暗号化処理に対応したメッセージの検証処理や復号処理を実行する。セキュリティ処理部５８は、処理結果を受信処理部６０へ出力する。

受信処理部６０は、セキュリティ処理部５８から受け取ったデータと、データ生成部６２から受け取った自車両情報に基づいて、衝突の危険性、救急車や消防車といった緊急車両の接近、進行方向の道路および交差点の混雑状況などを推定する。また、データが、画像情報であれば通知部７０にて表示できるように処理する。通知部７０は、図示しないモニタやランプやスピーカ等のユーザへの通知手段を含む。受信処理部６０からの指示にしたがって、図示しない他の車両１２の接近等を運転者へモニタやランプやスピーカを介して通知する。また、渋滞情報や交差点等の画像情報等をモニタに表示する。

データ生成部６２は、図示しないＧＰＳ受信機、ジャイロスコープ、車速センサ等を含んでおり、それらから供給される情報によって、図示しない自車両の情報、つまり端末装置１４が搭載された車両１２の存在位置、進行方向、移動速度等を取得する。なお、存在位置は、緯度・経度によって示される。これらの取得には公知の技術が使用されればよいので、ここでは説明を省略する。データ生成部６２は、取得した情報をもとにデータを生成し、生成したデータをアプリケーションデータとしてセキュリティ処理部５８に出力する。制御部７２は、端末装置１４全体の動作を制御する。

次に、本発明の変形例を説明する。本発明の変形例は、実施例と同様に、車車間通信と路車間通信とが実行される通信システムに関する。端末装置は、路車送信期間において、基地局装置からのパケット信号を複数受信する。パケット信号の数が７であり、かつ電子署名が添付されている場合、端末装置は、１回の発信者認証処理と７回のメッセージ認証処理を実行する。ここで、発信者認証処理は、最初のパケット信号に対してのみ実行する。その結果、端末装置は、路車送信期間において、ＥＣＤＳＡ検証処理を８回実行し、ＳＨＡ演算を７回実行する。さらに、スーパーフレームには、複数のサブフレームが含まれており、サブフレーム数を１６とすると、端末装置には、スーパーフレームの間に１２８回のＥＣＤＳＡ検証処理が要求される。前述のごとく、スーパーフレームの長さは１００ｍｓｅｃであるので、１回のＥＣＤＳＡ検証処理に対して、１ｍｓｅｃよりも短期間に終了することが必要とされる。一般的に、ＥＣＤＳＡ検証処理の処理量は大きく、１ｍｓｅｃよりも短期間に処理を完了するような高速な演算器を端末装置に搭載することは困難である。すなわち、全ての路車間通信によるパケットを検証しようとすると端末装置の大幅なコストアップに繋がり、普及を妨げる結果となる。

これに対応するために、変形例に係る基地局装置は、基地局装置の位置情報をパケット信号に含めて報知する。例えば、基地局装置の位置情報は、セキュリティヘッダに含まれる。端末装置は、所定の期間にわたって、基地局装置からのパケット信号を複数受信すると、各パケット信号から位置情報を抽出する。端末装置は、各パケット信号から抽出した位置情報と、自らの位置情報とを比較することによって、各パケット信号を報知した基地局装置と端末装置との距離を導出する。端末装置は、距離の短い基地局装置に対して優先順位が高くなるように、複数のサブフレームのそれぞれに対して優先順位を付与する。端末装置は、優先順位の高いサブフレームから優先的に、路車送信期間においてパケット信号を受信する。スーパーフレームの間に処理ができないサブフレームにおいて、端末装置は、路車送信期間におけるパケット信号を受信しない。本発明の変形例に係る通信システム１００は、図１と同様のタイプであり、本発明の変形例に係る基地局装置１０は、図１３と同様のタイプである。ここでは差異を中心に説明する。

基地局装置１０におけるセキュリティ処理部２８は、セキュリティヘッダに位置情報を含める。位置情報は、緯度と経度とによって示されるが、高度が含まれていてもよい。なお、位置情報の情報量を低減するために、緯度と経度との上位部分の情報が省略されていてもよい。

図２１は、本発明の変形例に係る端末装置１４の構成を示す。端末装置１４は、アンテナ５０、ＲＦ部５２、変復調部５４、ＭＡＣフレーム処理部５６、セキュリティ処理部５８、受信処理部６０、データ生成部６２、通知部７０、制御部７２、解析部７４を含む。また、セキュリティ処理部５８は、データ認証処理部６４、暗号化処理部６６を含み、解析部７４は、フレーム検出部７６、ＲＳＵ検出部７８、取得部８０、導出部８２、優先順位決定部８４、優先順位保持部８６、決定部８８を含む。端末装置１４の送信処理は、図１７の端末装置１４と同様である。

フレーム検出部７６は、ＭＡＣフレーム処理部５６を介して、受信されたパケット信号であって、かつ基地局装置１０からのパケット信号を取得する。このようなパケット信号は、スーパーフレームのうち、２つ以上のサブフレームのそれぞれにおける路車送信期間にて、周期的に受信されている。前述のごとく、パケット信号には、送信元になる基地局装置１０の位置情報が含まれている。フレーム検出部７６は、このようなパケット信号を取得したときに、スーパーフレームの検出を確認する。その結果、スーパーフレームとのタイミング同期、スーパーフレームに含まれた複数のサブフレームのそれぞれとのタイミング同期が確立する。

ＲＳＵ検出部７８は、フレーム検出部７６において検出されたスーパーフレームに含まれた複数のサブフレームのうち、基地局装置１０からのパケット信号を受信したサブフレームを特定する。これは、複数のサブフレームのうち、路車送信期間が設定されたサブフレームを検出することに相当する。ＲＳＵ検出部７８は、路車送信期間が設定されたサブフレームに関する情報を優先順位決定部８４へ出力する。ここで、路車送信期間が設定されたサブフレームに関する情報では、サブフレームと、当該サブフレームにおいて路車送信期間を設定している基地局装置１０とが対応づけて示されている。

取得部８０は、受信したパケット信号のうち、セキュリティヘッダに含まれた基地局装置１０の位置情報を取得する。複数の基地局装置１０からのパケット信号を受信している場合、取得部８０は、各基地局装置１０の位置情報を取得する。取得部８０は、本端末装置１４の位置情報も取得する。本端末装置１４の位置情報は、データ生成部６２から供給されている。取得部８０は、本端末装置１４の位置情報と各基地局装置１０の位置情報とを導出部８２へ出力する。

導出部８２は、取得部８０から、本端末装置１４の位置情報と各基地局装置１０の位置情報とを受けつける。導出部８２は、本端末装置１４の位置情報と各基地局装置１０の位置情報とをもとに、各基地局装置１０との間の距離を導出する。距離の導出のために、例えば、ベクトル演算がなされる。導出部８２は、各基地局装置１０との間の距離を優先順位決定部８４へ出力する。

優先順位決定部８４は、ＲＳＵ検出部７８から、路車送信期間が設定されたサブフレームに関する情報を受けつけるとともに、導出部８２から、各基地局装置１０との間の距離を受けつける。優先順位決定部８４は、導出した距離が短くなるほど優先順位が高くなるように、各基地局装置１０に対して優先順位を付与する。また、優先順位決定部８４は、路車送信期間が設定されたサブフレームに関する情報をもとに、各基地局装置１０が路車送信期間を設定しているサブフレームを特定することによって、各サブフレームに優先順位を付与する。なお、路車送信期間が設定されていないサブフレームに対しては優先順位が付与されなくてもよく、最も低い優先順位が付与されてもよい。優先順位決定部８４は、各サブフレームに付与した優先順位を優先順位保持部８６へ出力する。

優先順位保持部８６は、優先順位決定部８４から、各サブフレームに付与した優先順位を受けつけ、優先順位に関する情報を記憶する。決定部８８は、各サブフレームに付与した優先順位のうち、高い優先順位が付与されたサブフレームにて受信したパケット信号をセキュリティ処理部５８に優先的に処理させる。例えば、端末装置１４の処理能力から、２つのサブフレームに設定された路車送信期間でのパケット信号を処理可能であった場合、決定部８８は、優先順位の高い方からふたつのサブフレームを選択する。セキュリティ処理部５８は、決定部８８から指示されたサブフレームの路車送信期間において、パケット信号に対する受信処理を実行する。セキュリティ処理部５８は、その他のサブフレームの路車送信期間において、受信処理を停止する。

図２２は、端末装置１４の受信処理の概要を示す。図中の横軸が時間を示す。ここでは、ひとつのスーパーフレームにおいて、第ｉサブフレームの路車送信期間にパケット信号を報知している基地局装置１０までの距離が「中」であるとする。また、第ｊサブフレームの路車送信期間にパケット信号を報知している基地局装置１０までの距離が「近」であり、第ｋサブフレームの路車送信期間にパケット信号を報知している基地局装置１０までの距離が「遠」であるとする。そのため、端末装置１４は、第ｉサブフレームに優先順位「２」を付与し、第ｊサブフレームに優先順位「１」を付与し、第ｋサブフレームに優先順位「３」を付与する。ここで、路車送信期間でのパケット信号を処理可能なサブフレーム数が「２」であった場合、端末装置１４は、第ｉサブフレームと第ｊサブフレームにおける受信を決定する。

以上の構成による通信システム１００の動作を説明する。図２３は、端末装置１４による受信処理の手順を示すフローチャートである。決定部８８は、スーパーフレームの間に処理可能なサブフレーム数あるいは復号可能なＥＣＤＳＡ数を設定する（Ｓ１０）。導出部８２は、各基地局装置１０との間の距離を導出する（Ｓ１２）。優先順位決定部８４は、ＲＳＵパケット信号を受信したサブフレームに対して、距離をもとに優先順位を付与する（Ｓ１４）。セキュリティ処理部５８は、優先順位にしたがってパケット信号を処理する（Ｓ１６）。ここでは、優先順位を基地局装置と端末装置の距離によって決定するとしたが、車両に搭載された端末装置は移動するので、端末装置の移動方向を優先順位の決定に加味することも考えられる。すなわち、端末装置を搭載した車両の進行方向を判断基準に加え、進行方向に近いものに対して優先順位を高く設定するようにしてもよい。

次に、本発明の別の変形例を説明する。本発明の別の変形例も、これまでと同様に、車車間通信と路車間通信とが実行される通信システムに関する。変形例では、スーパーフレームの長さに合わせてＥＣＤＳＡ検証処理数を制限するために、基地局装置が、位置情報をパケット信号に含めて報知する。また、端末装置は、距離の近い基地局装置が路車送信期間を設定したサブフレームに対して高くなるような優先順位を設定し、優先順位の高いサブフレームから優先的にＥＣＤＳＡ検証処理を実行する。別の変形例でも、スーパーフレームの長さに合わせてＥＣＤＳＡ検証処理数を制限することを目的とする。しかしながら、別の変形例に係る基地局装置は、位置情報をパケット信号に含めない。

一方、端末装置は、基地局装置からのパケット信号を複数受信すると、各パケット信号の受信電力を測定する。端末装置は、受信電力の高いパケット信号の送信元になる基地局装置に対して優先順位が高くなるように、複数のサブフレームのそれぞれに対して優先順位を付与する。端末装置は、優先順位の高いサブフレームから優先的に、路車送信期間においてパケット信号を受信する。本発明の別の変形例に係る通信システム１００は、図１と同様のタイプであり、本発明の別の変形例に係る基地局装置１０は、図１３と同様のタイプである。ここでは差異を中心に説明する。

図２４は、本発明の別の変形例に係る端末装置１４の構成を示す。端末装置１４は、図２１に示された端末装置１４の取得部８０、導出部８２の代わりに、ＲＳＳＩ検出部９０を含む。ＲＳＳＩ検出部９０は、サブフレーム中に設定された路車送信期間において受信したパケット信号のＲＳＳＩを検出する。これは、パケット信号の受信電力を測定することに相当する。なお、ひとつの路車送信期間では、複数のパケット信号を受信しているが、ＲＳＳＩ検出部９０は、これらの平均を計算し、平均値を当該サブフレームにおけるＲＳＳＩとする。ＲＳＳＩ検出部９０は、各サブフレームにおけるＲＳＳＩを優先順位決定部８４へ出力する。

優先順位決定部８４は、ＲＳＵ検出部７８から、路車送信期間が設定されたサブフレームに関する情報を受けつけるとともに、ＲＳＳＩ検出部９０から、各サブフレームにおけるＲＳＳＩを受けつける。優先順位決定部８４は、ＲＳＳＩが高くなるほど優先順位が高くなるように、各サブフレームに対して優先順位を付与する。これは、各基地局装置１０に対して優先順位を付与することに相当する。優先順位決定部８４は、各サブフレームに付与した優先順位を優先順位保持部８６へ出力する。

図２５は、優先順位保持部８６に記憶されたテーブルのデータ構造を示す。ここでは、スーパーフレーム中に１６のサブフレームが配置されているとしている。「ＲＳＵの存在」は、路車送信期間が設定されていることに相当する。「優先順位（フロー１）」が、優先順位決定部８４によって、前述のごとく、決定された優先順位である。また、優先順位決定部８４は、ＲＳＳＩの時間変動も監視し、時間変動をもとに優先順位を設定してもよい。例えば、ＲＳＳＩが増加しているほど、高い優先順位が付与されてもよい。これが、「優先順位（フロー１）増減考慮」に相当する。「優先順位２（フロー）Ｍ＝２」と「優先順位（フロー１）増減考慮偽対策」については後述する。

以上の構成による通信システム１００の動作を説明する。図２６は、端末装置１４による受信処理の手順を示すフローチャートである。決定部８８は、スーパーフレームの間に処理可能なサブフレーム数あるいは復号可能なＥＣＤＳＡ数を設定する（Ｓ３０）。優先順位決定部８４は、ＲＳＵパケット信号を受信したサブフレームに対して、ＲＳＳＩをもとに優先順位を付与する（Ｓ３２）。セキュリティ処理部５８は、優先順位にしたがってパケット信号を処理する（Ｓ３４）。なお、ＲＳＳＩの増減と距離との組合せをもとに優先順位が付与されてもよい。

次に、本発明のさらに別の変形例を説明する。本発明のさらに別の変形例も、これまでと同様に、車車間通信と路車間通信とが実行される通信システムに関する。別の変形例では、スーパーフレームの長さに合わせてＥＣＤＳＡ検証処理の回数を制限するために、受信電力をもとに、複数のサブフレームのそれぞれに対して優先順位を付与している。さらに別の変形例は、これに続く処理に相当する。端末装置は、高い優先順位のサブフレームにおける路車送信期間から優先的にパケット信号を処理する。パケット信号に含まれた電子署名によってメッセージ認証がなされるが、検証を通らないこともありえる。

端末装置は、検証が通らなかった場合、次のスーパーフレームから、当該サブフレームにおける路車送信期間での処理を除外する。これは、当該サブフレームの優先順位を破棄し、これよりも低い優先順位を繰り上げることに相当する。本発明のさらに別の変形例に係る通信システム１００は、図１と同様のタイプであり、本発明のさらに別の変形例に係る基地局装置１０は、図１３と同様のタイプであり、本発明のさらに別の変形例に係る端末装置１４は、図２４と同様のタイプである。ここでは差異を中心に説明する。

データ認証処理部６４は、前述のごとく、受信処理として、セキュリティフッタに含まれた電子署名に対して検証処理を実行し、検証結果が無効である場合、その旨を解析部７４へ通知する。優先順位決定部８４は、検証結果が無効である旨を受けつけると、優先順位保持部８６を参照して、それに対応したサブフレームに対する優先順位を破棄する。さらに、優先順位決定部８４は、優先順位保持部８６を参照して、破棄した優先順位よりも低い優先順位を繰り上げるように、優先順位を修正する。優先順位保持部８６は、修正した優先順位を記憶する。これが、図２５の「優先順位（フロー１）増減考慮偽対策」に相当する。セキュリティ処理部５８は、新たな優先順位に対応したパケット信号を処理する。つまり、セキュリティ処理部５８は、検証結果が無効であったサブフレームに対する処理を次のスーパーフレームから除外する。

図２７は、本発明のさらに別の変形例に係る端末装置１４の受信処理の概要を示す。ここでは、ひとつのスーパーフレームにおいて、第ｉサブフレームの路車送信期間に受信したパケット信号のＲＳＳＩが「中」であるとする。また、第ｊサブフレームの路車送信期間に受信したパケット信号のＲＳＳＩが「大」であり、第ｋサブフレームの路車送信期間に受信したパケット信号のＲＳＳＩが「小」であるとする。そのため、端末装置１４は、第ｉサブフレームに優先順位「２」を付与し、第ｊサブフレームに優先順位「１」を付与し、第ｋサブフレームに優先順位「３」を付与する。しかしながら、第ｊサブフレームに対する認証が失敗したので、第ｉサブフレームに優先順位「１」を付与し、第ｋサブフレームに優先順位「２」を付与する。

次に、本発明のさらに別の変形例を説明する。本発明のさらに別の変形例も、これまでと同様に、車車間通信と路車間通信とが実行される通信システムに関する。別の変形例では、スーパーフレームの長さに合わせてＥＣＤＳＡ検証処理数を制限するために、受信電力をもとに、複数のサブフレームのそれぞれに対して優先順位を付与している。さらに別の変形例でも、同様に優先順位を付与するが、優先順位の付与対象が別の実施例と異なる。さらに別の実施例では、スーパーフレームを複数の区間に分割する。例えば、前半の区間と後半の区間のように、スーパーフレームが２つの区間に分割される。その際、各区間には、整数個のサブフレームが含まれる。

端末装置は、前半の区間（以下、「第１区間」という）に含まれた複数のサブフレームに対して優先順位を付与し、後半の区間（以下、「第２区間」という）に含まれた複数のサブフレームに対しても優先順位を付与する。ここで、第１区間における優先順位と第２区間における優先順位とは独立である。このように処理することによって、連続したサブフレームにてＥＣＤＳＡを演算する可能性が低減される。本発明のさらに別の変形例に係る通信システム１００は、図１と同様のタイプであり、本発明のさらに別の変形例に係る基地局装置１０は、図１３と同様のタイプであり、本発明のさらに別の変形例に係る端末装置１４は、図２４と同様のタイプである。ここでは差異を中心に説明する。

優先順位決定部８４は、スーパーフレームのうちの第１区間に含まれた複数のサブフレームに対して、優先順位を付与するとともに、第２区間に含まれた複数のサブフレームのうちの一部とは別の部分に対しても優先順位を独立して付与する。図２８は、本発明のさらに別の変形例に係る端末装置１４の受信処理の概要を示す。ここでは、説明を明瞭にするために、ひとつのスーパーフレームが８つのサブフレームによって形成されているとする。端末装置１４は、第１区間において、第３サブフレームに最も高い優先順位を付与するとともに、第２区間において、第５サブフレームに最も高い優先順位を付与する。

次に、本発明のさらに別の変形例を説明する。本発明のさらに別の変形例も、これまでと同様に、車車間通信と路車間通信とが実行される通信システムに関する。本変形例に係る通信システム１００は図１と同様のタイプであり、基地局装置１０は図１３と同様のタイプであり、端末装置１４は図２１と同様のタイプである。本変形例では、優先順位決定部８４によりサブフレームに優先順位が付与された後、決定部８８はその優先順位にしたがい電子署名検証の間引き率を調整する。決定部８８は優先順位が高いサブフレームほどＲＳＵパケット信号の電子署名検証の間引き率を低く設定し、優先順位が低いサブフレームほどＲＳＵパケット信号の電子署名検証の間引き率を高く設定する。なお、優先順位が最も高いサブフレームでは、ＲＳＵパケット信号の電子署名検証の間引きを実行しなくてもよい。セキュリティ処理部５８は、解析部７４において基地局装置１０からのサブフレーム毎に付与した優先順位に応じた間引き率で、基地局装置１０からのサブフレーム毎の検証タイミングを設定し、その検証タイミングにて、基地局装置１０からのサブフレームにて受信したパケット信号に含まれた電子署名に対する検証処理を実行する。セキュリティ処理部５８は、さらに公開鍵証明書の検証処理を行い、当該検証タイミングでは、公開鍵証明書の検証処理または電子署名に対する検証処理のいずれか一方を実行する。

図２９は、変形例に係るセキュリティフレームのデータ構造例を示す図である。このデータ構造では、セキュリティヘッダとして「バージョン」、「メッセージ形式」、「鍵ＩＤ」、「ｎｏｎｃｅ」、「データ長」および「公開鍵証明書」が配置され、その後に「ペイロード」が配置され、最後にセキュリティフッタとして「電子署名」および「ＭＡＣ」が配置される。この例では、署名対象は「ペイロード」であり、ＭＡＣ生成対象は「ｎｏｎｃｅ」、「データ長」、「公開鍵証明書」、「ペイロード」および「電子署名」であり、暗号対象は「ペイロード」、「電子署名」および「ＭＡＣ」である。したがって、電子署名を生成した後、ＭＡＣを生成し、次いで、暗号化する。

「バージョン」はフレームフォーマットのバージョンを示す。「メッセージ形式」はメッセージ形式を指定する。メッセージ形式には、平文データ形式、認証付きデータ形式および認証付き暗号化データ形式がある。メッセージ形式が、平文データ形式および認証付きデータ形式である場合、先に述べた暗号化が行われない。また、平文データ形式である場合、電子署名およびＭＡＣが生成されない。従って、「電子署名」および「ＭＡＣ」には既知のデータ、例えば、全てに０が設定される。「鍵ＩＤ」は基地局装置１０と端末装置１４間で共有されている通信鍵を識別するための情報である。データ形式が証付きデータ形式および認証付き暗号化データ形式である場合、「鍵ＩＤ」で識別される通信鍵を用いてＭＡＣ生成あるいは暗号化が行われる。当該通信鍵には、事前に共有された共通鍵暗号方式の共通鍵、たとえば、ＡＥＳ（Ａｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ）鍵を用いることができる。

「ｎｏｎｃｅ」は、通信鍵を用いたＭＡＣ生成および暗号化において結果を攪乱するために用いる通信毎にユニークな値がセットされる。この値は乱数であってもよいし、送信時刻であってもよい。さらに、乱数または送信時刻に発信元の機器ＩＤが追加されてもよい。「データ長」は暗号対象のデータ長（より具体的にはバイト数）を設置する。なお、「公開鍵証明書」のデータ長が固定長であるならば、「ペイロード」のデータ長をセットしてもよい。

「公開鍵証明書」は基地局装置１０に固有の公開鍵に対する公開鍵証明書をセットする。公開鍵証明書は公開鍵とその公開鍵の所有主体を結びつける証明書である。公開鍵証明書には、署名者の識別情報、機器ＩＤ、有効期限、公開鍵（鍵生成アルゴリズム、サイズなどを含む）、署名者の署名などが含まれる。本変形例では、署名者は認証局（ＣＡ：Ｃｅｒｔｉｆｉｃａｔｅ Ａｕｔｈｏｒｉｔｙ）とする。当該署名は、たとえば、ＲＳＡ、ＤＳＡ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｔｕｒｅ Ａｌｇｏｒｉｔｈｍ）、ＥＣＤＳＡ（Ｅｌｌｉｐｔｉｃ Ｃｕｒｖｅ−ＤＳＡ）などの公開鍵暗号方式により生成される。本変形例ではＥＣＤＳＡを採用する。

「電子署名」には、「ペイロード」に対する署名がセットされる。署名は「公開鍵証明書」に含まれる公開鍵と対をなす秘密鍵を用いて生成された署名である。

「ＭＡＣ」には、共通鍵とＭＡＣ対象に所定のＭＡＣアルゴリズムを適用して生成されたＭＡＣがセットされる。共通鍵は基地局装置１０と端末装置１４間で共有されている通信鍵である。図２９の例では、「ＭＡＣ」は、ＡＥＳアルゴリズムと「鍵ＩＤ」により特定される通信鍵を用いたＣＢＣ−ＭＡＣの値を代入する。認証付き暗号化データの場合は、ＣＣＭ（Ｃｏｕｎｔｅｒ ｗｉｔｈ ＣＢＣ−ＭＡＣ）モードにより生成されることとなる。「ＭＡＣ」は「電子署名」より簡易な認証方法であり、データ量も少なく、かつ、高速処理が可能である。基地局装置１０のデータ認証処理部３４は、「電子署名」と「ＭＡＣ」の両方を生成する。

本変形例に係る端末装置１４による受信処理の手順は、図２３のフローチャートと同様である。本変形例では図２３のフローチャートのステップＳ１６における優先順位にしたがったパケット信号の処理の内容が異なる。

図３０は、変形例に係る優先順位にしたがったパケット信号の処理手順を示すフローチャートである。決定部８８は、優先順位決定部８４によりＲＳＵパケット信号を受信したサブフレームに対して付与された優先順位を参照する（Ｓ１６１）。決定部８８は、優先順位が「１」のサブフレームにて受信されるＲＳＵパケット信号のセキュリティフッタに含まれる電子署名を、セキュリティ処理部５８に高頻度で検証させる（Ｓ１６２）。即ち、近距離に位置する基地局装置１０からのＲＳＵパケット信号における電子署名検証の間引きを少なくする。決定部８８は、優先順位が「２」のサブフレームにて受信されるＲＳＵパケット信号のセキュリティフッタに含まれる電子署名を、セキュリティ処理部５８に中頻度で検証させる（Ｓ１６３）。決定部８８は、優先順位が「３」のサブフレームにて受信されるＲＳＵパケット信号のセキュリティフッタに含まれる電子署名を、セキュリティ処理部５８に低頻度で検証させる（Ｓ１６４）。即ち、遠距離に位置する基地局装置１０からのパケット信号における電子署名検証の間引きを多くする。

なお、決定部８８はスーパーフレームの間に処理可能なサブフレーム数あるいは復号可能なＥＣＤＳＡ数に応じて、優先順位「１」、優先順位「２」、優先順位「３」のそれぞれに割り当てる間引き率および間引きタイミングを決定する。たとえば、優先順位が「１」のサブフレームにて受信されるＲＳＵパケット信号に含まれる電子署名の検証を１００ｍｓｅｃに１回実行し、優先順位が「２」のサブフレームにて受信されるＲＳＵパケット信号に含まれる電子署名の検証を１ｓｅｃに１回実行し、優先順位が「１」のサブフレームにて受信されるＲＳＵパケット信号に含まれる電子署名の検証を１ｍｉｎに１回実行する。

決定部８８は、電子署名検証をスキップしたＲＳＵパケット信号について、そのセキュリティフッタに付加されたＭＡＣを、セキュリティ処理部５８に検証させる（Ｓ１６５）。ＭＡＣ検証はＥＣＤＳＡを使用しないためＥＣＤＳＡコアの負荷を上昇させない。ＭＡＣ検証はＡＥＳを使用するが、ＡＥＳの処理負荷は小さい。

これまで、端末装置１４のデータ認証処理部６４はセキュリティフッタに含まれる電子署名の検証処理を実行すると説明した。より厳密には、データ認証処理部６４はセキュリティヘッダに含まれる公開鍵証明書の検証と、セキュリティフッタに含まれる電子署名の検証の両方を実行する。

データ認証処理部６４は、基地局装置１０から送信されるＲＳＵパケット信号に含まれる公開鍵証明書に含まれる電子署名を認証鍵（公開鍵）を用いて検証する。この認証鍵は予め組み込まれていてもよいし、安全な手段で事後的に取得したものであってもよい。公開鍵証明書の電子署名は、「ペイロード」の電子署名と同様に、ＥＣＤＳＡが採用される。

公開鍵証明書に含まれる電子署名に対する検証が成功すれば、公開鍵証明書に含まれる基地局装置１０が生成した公開鍵は、認証局により証明された真性なものであると推定できる。しかしながら、この署名にはＥＣＤＳＡが用いられるため、すべてのＲＳＵパケット信号において公開鍵証明書の検証を実行すると処理負荷が増大する。そこで、公開鍵証明書の検証を適宜、スキップする。たとえば、ある基地局装置１０の電波圏内に入って最初に受信したＲＳＵパケット信号に含まれる公開鍵証明書のみを検証し、それ以降のＲＳＵパケット信号については後述する記憶領域に保持されるダイジェストの比較だけを行い、一致した場合には、図２９の「電子署名」の検証を行う。

データ認証処理部６４は、検証が成功した公開鍵証明書から取得したダイジェストを、証明書検証ログとして所定の記憶領域に保持する。ダイジェストは、公開鍵証明書の電子署名の対象データに対するハッシュ値、または、その部分である。なお、ダイジェストに変えて、公開鍵証明書に含まれるシリアル番号（識別情報）、電子署名、公開鍵、機器ＩＤを使用してもよい。前述の記憶領域はＦＩＦＯ形式のＲＡＭで形成され、最大ＲＳＵスロットの数以上のデータを格納する領域を持つ。本実施例ではスーパーフレームは１６のサブフレームを含むため、最大ＲＳＵスロットの数は１６である。

データ認証処理部６４は、基地局装置１０から送信されるパケット信号を受信すると、そのＲＳＵパケット信号に含まれる公開鍵証明書から取り出したダイジェストと、前述の記憶領域に保持されるダイジェストとを比較する。両者が一致する場合、当該ＲＳＵパケット信号に含まれる公開鍵証明書の検証をスキップする。すなわち、正式な検証を実行せずに公開鍵証明書のダイジェストの一致をもって検証成功とみなす。これは、公開鍵証明書のダイジェストが一致している間は、同一の基地局装置１０から送信されたパケット信号と推定できるためである。すなわち、ある基地局装置１０から報知されたパケット信号に含まれる公開鍵証明書の検証が一度成功すれば、その基地局装置１０から報知される後続のパケット信号の信頼性は高いと判断できる。

データ認証処理部６４は、公開鍵証明書のダイジェストが一致したＲＳＵパケット信号に含まれる認証付きメッセージを検証する。検証には、受信した公開鍵証明書に含まれる公開鍵と機器ＩＤを用いる。本実施例では電子署名付きメッセージ形式における「ペイロード」の真性の検証をする。電子署名付き暗号化メッセージ形式では、暗号を復号した後、同様な処理を行う。この電子署名は、当該パケット信号に含まれる公開鍵証明書に格納される公開鍵と対をなす秘密鍵により生成されているため、当該公開鍵を用いた当該電子署名付きメッセージに対する検証が成功すれば、当該メッセージは基地局装置１０により生成された真性なものであると推定できる。

しかしながら、この電子署名にもＥＣＤＳＡが用いられるため、すべてのＲＳＵパケット信号において電子署名付きメッセージの検証を実行すると処理負荷が増大する。そこで、公開鍵証明書を検証したパケット信号ではセキュリティフッタに含まれる電子署名の検証をスキップする。また前述の間引き処理を実行する。

図３１は、優先順位切り替え処理を説明するための図（その１）である。車両１２には端末装置１４が搭載される。図３１では車両１２が「西」から「東」に進行する。車両１２の進行方向に基地局装置１０である路側機が設置されている。端末装置１４の決定部８８は、基地局装置１０から受信したパケット信号に含まれる基地局装置１０の位置情報をもとに、基地局装置１０の電波圏内において基地局装置１０を中心に近距離エリアＡ１、中距離エリアＡ２、遠距離エリアＡ３を設定する。

車両１２が遠距離エリアＡ３に侵入すると端末装置１４のデータ認証処理部６４は、基地局装置１０からＲＳＵパケット信号を受信する。データ認証処理部６４は、最初に受信したＲＳＵパケット信号のセキュリティヘッダに含まれる公開鍵証明書を検証する。それ以降のＲＳＵパケット信号については、公開鍵証明書のダイジェストの比較およびメッセージ検証を実行する。遠距離エリアＡ３では優先順位が「３」の場合に設定される頻度でＲＳＵパケット信号のセキュリティフッタに含まれる電子署名を検証する。

車両１２がさらに進み、中距離エリアＡ２に侵入するとデータ認証処理部６４は、優先順位が「２」の場合に設定される頻度で、ＲＳＵパケット信号のセキュリティフッタに含まれる電子署名を検証する。車両１２がさらに進み、近距離エリアＡ１に侵入するとデータ認証処理部６４は、優先順位が「１」の場合に設定される頻度で、ＲＳＵパケット信号のセキュリティフッタに含まれる電子署名を検証する。基地局装置１０を通り過ぎ車両１２が中距離エリアＡ２に再侵入するとデータ認証処理部６４は、優先順位が「２」の場合に設定される頻度で、ＲＳＵパケット信号のセキュリティフッタに含まれる電子署名を検証する。車両１２がさらに進み、遠距離エリアＡ３に再侵入するとデータ認証処理部６４は、優先順位が「３」の場合に設定される頻度で、ＲＳＵパケット信号のセキュリティフッタに含まれる電子署名を検証する。車両１２がさらに進み、基地局装置１０の電波圏外に出ると基地局装置１０からのパケット信号を受信できなくなり、その検証処理も終了する。

図３２は、優先順位切り替え処理を説明するための図（その２）である。図３２は図３１と基本的に同じであるが、近距離エリアＡ１、中距離エリアＡ２の設定位置が異なる。決定部８８は、基地局装置１０から受信したパケット信号に含まれる基地局装置１０の位置情報をもとに、基地局装置１０の電波圏内において近距離エリアＡ１、中距離エリアＡ２、遠距離エリアＡ３を設定する。その際、遠距離エリアＡ３は基地局装置１０を中心に設定する。近距離エリアＡ１、中距離エリアＡ２は、基地局装置１０より車両１２に近い位置を中心に設定する。これにより、車両１２の進行方向に位置する基地局装置１０の優先順位が上がりやすくなる。

本発明の実施例によれば、セキュリティフレームのうち、ペイロード、セキュリティフッタには暗号化がなされるが、セキュリティヘッダには暗号化がなされないので、セキュリティヘッダの内容を早期に取得できる。また、セキュリティヘッダの内容が早期に取得されるので、受信処理を高速化できる。また、サブフレームに対して優先順位を付与し、高い優先順位が付与されたサブフレームにて受信したパケット信号を優先的に処理するので、処理すべきパケット信号数を低減できる。また、処理すべきパケット信号数が低減されるので、ＥＣＤＳＡ検証処理数を低減できる。

また、ＥＣＤＳＡ検証処理数が低減されるので、電子署名によるメッセージの検証を所定の期間内に完了できる。また、各基地局装置との間の距離が短くなるほど優先順位が高くなるように、優先順位を付与するので、近接した基地局装置からのパケット信号を受信しやすくできる。また、近接した基地局装置からのパケット信号が受信しやすくなるので、パケット信号の受信品質を向上できる。また、受信電力が高くなるほど優先順位が高くなるように、優先順位を付与するので、近接した基地局装置からのパケット信号を受信しやすくできる。

また、パケット信号に含まれた電子署名に対して実行した検証処理が無効である場合、当該パケット信号が受信されたサブフレームに対する処理を次のスーパーフレームから除外するので、偽りの基地局装置を無視できる。また、スーパーフレームを複数の区間に分割し、それぞれの区間において優先順位を付与するので、ＥＣＤＳＡ検証処理のタイミングを分散できる。また、ＥＣＤＳＡ検証処理のタイミングが分散されるので、処理を分散できる。

また、優先順位に応じて電子署名検証の間引き率を調整することにより柔軟な受信処理が可能となる。また、路車間通信において電子署名とＭＡＣを併用することにより、受信処理しないＲＳＵパケット信号を低減できる。また、公開鍵証明書の検証結果をログに残すことにより、証明書の検証回数を低減できる。

以上、本発明を実施例をもとに説明した。この実施例は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

本発明の変形例において、セキュリティヘッダの中に、基地局装置１０の位置情報が含まれている。しかしながらこれに限らず例えば、他の部分に、基地局装置１０の位置情報が含まれてもよい。本変形例によれば、通信システム１００の設計の自由度を向上できる。

本発明の別の変形例やさらに別の変形例において、優先順位決定部８４は、受信電力をもとに優先順位を付与している。しかしながらこれに限らず例えば、優先順位決定部８４は、実施例と同様に、各基地局装置１０との距離をもとに優先順位を付与してもよい。本変形例によれば、通信システム１００の設計の自由度を向上できる。

本発明のさらに別の変形例において、スーパーフレームは、ふたつの区間に分割されている。しかしながらこれに限らず例えば、スーパーフレームは、３つ以上の区間に分割されてもよい。本変形例によれば、通信システム１００の設計の自由度を向上できる。

１０ 基地局装置、 １２ 車両、 １４ 端末装置、 ２０ アンテナ、 ２２ ＲＦ部、 ２４ 変復調部、 ２６ ＭＡＣフレーム処理部、 ２８ セキュリティ処理部、 ３０ 制御部、 ３２ ネットワーク通信部、 ３４ データ認証処理部、 ３６ 暗号化処理部、 ５０ アンテナ、 ５２ ＲＦ部、 ５４ 変復調部、 ５６ ＭＡＣフレーム処理部、 ５８ セキュリティ処理部、 ６０ 受信処理部、 ６２ データ生成部、 ６４ データ認証処理部、 ６６ 暗号化処理部、 ７０ 通知部、 ７２ 制御部、 １００ 通信システム。

本発明はこうした状況に鑑みてなされたものであり、その目的は、電子署名によるメッセージの検証を所定の期間内に完了させる技術を提供することにある。

Claims (5)

1. 複数のサブフレームが含まれたフレームを繰り返し生成し、前記複数のサブフレームのいずれかの先頭期間に路車送信期間を設定し、その路車送信期間にパケット信号を送信する路側機であって、
   フレームフォーマットのバージョンを示すバージョンと、
   平文データ、認証付きデータ、または認証付き暗号化データを設定可能なメッセージタイプと、
   路側機の固有の公開鍵に対する公開鍵証明書と、
   暗号対象のデータ長と、
   アプリケーションデータと、
   前記アプリケーションデータを含む署名対象に対して、前記公開鍵と対をなす秘密鍵を用いて生成された署名と、
   共通鍵テーブルを識別するテーブルＩＤと、ランダムに選択され、前記共通鍵テーブル内の個別の鍵を識別する個別ＩＤとを含む鍵ＩＤであって、前記個別ＩＤによりランダムに選択され、前記アプリケーションデータ及び前記署名の暗号化に使用された共通鍵を特定する鍵ＩＤと、
   前記共通鍵を使用した演算結果を攪乱するために用いる通信毎にユニークな値が用いられるｎｏｎｃｅと、
   を含む通信データを生成する処理部と、
   生成された通信データを、ＯＦＤＭ（Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘｉｎｇ）変調方式のパケット信号としてブロードキャストする送信部と、を備え、
   前記処理部は、前記アプリケーションデータ及び前記署名を含む暗号対象を、路側機と車載器間で共有されている、前記鍵ＩＤで特定される共通鍵を用いて暗号化することを特徴とする路側機。
2. 前記公開鍵証明書には、公開鍵証明書のバージョン、対象者のタイプ、ＣＡ（Ｃｅｒｔｉｆｉｃａｔｅ Ａｕｔｈｏｒｉｔｙ）のＩＤ、範囲、有効期限、公開鍵、公開鍵のアルゴリズム、前記ＣＡの署名が含まれることを特徴とする請求項１に記載の路側機。
3. 前記通信データに、ロケーションをさらに含めることを特徴とする請求項１または２に記載の路側機。
4. 路側機からの路車間通信および車載器からの車車間通信を実行する車載器であって、
   請求項１から３のいずれかに記載の路側機からブロードキャストされたパケット信号を受信する通信部と、
   受信したパケット信号を復調する復調部と、
   路側機と車載器間で共有されている、前記鍵ＩＤで特定される共通鍵を用いて、前記パケット信号に含まれる暗号化データを復号する暗号化処理部と、
   前記署名に対して検証処理を実行するデータ認証処理部と、
   を備えることを特徴とする車載器。
5. 前記通信部は、前記路車送信期間以外の車車送信期間において、キャリアセンスによりパケット信号をブロードキャスト送信可能であることを特徴とする請求項４に記載の車載器。