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

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

Info

Publication number
JP6342109B2
JP6342109B2 JP2012221622A JP2012221622A JP6342109B2 JP 6342109 B2 JP6342109 B2 JP 6342109B2 JP 2012221622 A JP2012221622 A JP 2012221622A JP 2012221622 A JP2012221622 A JP 2012221622A JP 6342109 B2 JP6342109 B2 JP 6342109B2
Authority
JP
Japan
Prior art keywords
transmitted
application data
transmission
communication
data
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.)
Active
Application number
JP2012221622A
Other languages
English (en)
Other versions
JP2014075678A (ja
Inventor
博史 浦山
博史 浦山
文哉 齊藤
文哉 齊藤
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sumitomo Electric Industries Ltd
Original Assignee
Sumitomo Electric Industries Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Sumitomo Electric Industries Ltd filed Critical Sumitomo Electric Industries Ltd
Priority to JP2012221622A priority Critical patent/JP6342109B2/ja
Publication of JP2014075678A publication Critical patent/JP2014075678A/ja
Application granted granted Critical
Publication of JP6342109B2 publication Critical patent/JP6342109B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Traffic Control Systems (AREA)
  • Mobile Radio Communication Systems (AREA)

Description

本発明は、通信機、通信処理装置、アプリケーション装置、コンピュータプログラム、及び送信方法に関する。
近年、路車間通信、車車間通信による高度道路交通システム(ITS)が検討されている。路車間通信とは、路側通信機(基地局)と車載通信機(移動局)との間の通信であり、車車間通信とは、車載通信機(移動局)間の通信である。
このような高度道路交通システムのための通信方式については、標準規格及びガイドラインが制定されている(非特許文献1,2参照)。
非特許文献1では、所定の送信周期(100ms)毎に到来する最大16個の路車間通信期間が離散的に設けられ、路車間通信期間以外の時間帯が車車間通信期間として設定される。
一般社団法人電波産業会、"700MHz帯高度道路交通システム ARIB−STDT109 1.0版",[online]、平成24年2月14日、[平成24年9月18日検索]、インターネット<http://www.arib.or.jp/tyosakenkyu/kikaku_tushin/tsushin_kikaku_number.html> ITS情報通信システム推進会議、"700MHz帯高度道路交通システム拡張機能ガイドライン ITS FORUM RC−010 1.0版",[online]、2012年3月26日、[平成24年9月18日検索]、インターネット<http://www.itsforum.gr.jp/>
それぞれの路側通信機には、一送信周期内の複数(最大16個)の路車間通信期間のうちの1又は複数の路車間通信期間が、送信期間として割り当てられる。電波干渉を回避するため、割り当てられる路車間通信期間は、路側通信機ごとに異なったものとされることがある。
各路側通信機は、割り当てられた送信期間(路車間通信期間)において、交通情報などのアプリケーションデータの送信を行う。
つまり、路側通信機は、所定の周期(100ms)毎に割り当てられた1又は複数の送信期間において、アプリケーションデータを送信する。
一つの送信周期(100ms)内のアプリケーションデータのデータ量は、一つの送信周期で割り当てられた1又は複数の送信期間内で送信し得るデータ量の最大値未満であることが望まれる。アプリケーションデータのデータ量が最大値を超えると、超えた分のデータは、その送信周期では送信できなくなる。
路車間通信期間において送信される路車間通信データには、データを送信する路側通信機の周囲に存在する車両や歩行者等に関する交通情報等を含ませることができるが、これらのデータは交通量によって大きく変動するケースがある。また、交通情報以外の周辺情報等を送信する場合にもそれらの情報は時間帯や季節等によって随時変動しうる、と考えられ、路側通信機を設置して運用を開始した当初よりも大幅にデータ量が増大することがありうる。
また、例えば、路車間通信期間において、車載通信機向けの路車間通信データだけでなく、他の路側通信機向けの路路間通信データも送信しようとした場合、路車間通信データのデータ量に路路間通信データのデータ量が加わって、データ量が大きくなり、前記最大値を超え易くなる。
データ量が大きくなる場合にも、一つの送信周期において送信すべきデータ量の最大値を予め見積もることが可能であれば、その最大値に応じて、その路側通信機に割り当てられる送信期間を予め長く設定することはできる。
しかし、一周期において送信すべきデータ量の最大値を予め見積もるのは必ずしも容易ではない。
例えば、路路間通信では、ある路側通信機が、自ら生成した路路間通信データを送信するほか、他の路側通信機がさらに別の路側通信機向けに生成した路路間通信データを転送のために送信しなければならないことがある。しかも、路路間通信データのサイズは、データによってまちまちである。また、ブロードキャスト送信されて再送が行われない路車間通信とは異なり、路路間通信では、通信相手が決まっているため、伝搬環境の変動により再送が生じる可能性もある。
したがって、路車間通信期間において、路車間通信に加えて路路間通信も行われる場合、一周期において送信すべきデータ量の最大値を予め見積もることは困難となる。
この結果、一周期内で送信すべきアプリケーションデータのデータ量が、予め設定された送信期間では送信不可能なデータ量となることがある。
また、割り当てられる送信期間を長くするとしても、非特許文献1に準拠する場合、非特許文献1に規定される送信周期毎の最大送信時間である10.5msを超えることはできない。
非特許文献1,2に従うと、生成されたアプリケーションデータのデータ量が、予め設定された送信期間では送信可能なデータ量を超えた場合であっても、非特許文献1,2に規定する通信プロトコルでの通信処理の対象になりかねない。この場合、非特許文献1,2に規定する通信プロトコルでの送信処理及びその送信処理に関連する処理が、送信できない過剰なデータに対しても行われ、無駄な処理(セキュリティ処理及び送信処理など)が発生する。
無駄な処理の発生を回避するには、アプリケーションデータを生成又は転送するアプリケーションが、非特許文献1,2に規定する通信プロトコルでの通信処理を行う通信処理部に対して、送信要求を行う前に、送信可否を判定することが考えられる。
つまり、アプリケーションが、通信処理部に対して、アプリケーションデータを与える前に、そのアプリケーションデータが、予め設定された送信期間で送信可能か否かを判定することで、過剰なデータを通信処理部に与えることが防止できる。
そのような判定を行う方法として、例えば、通信処理部において行われる送信処理及びその送信処理に関連する処理と同じ処理を、アプリケーションにおいても事前に行うことが考えられるが、この方法の場合、アプリケーションは下位レイヤで行われる通信処理と同一の処理を事前に行う必要があり、2重処理となって、アプリケーションでの処理負荷が増大する。また、下位レイヤでの通信処理方法が変更されるたびに、アプリケーションでの処理内容もそれに応じて修正する必要が生じ、メンテナンスにも多大なコストを要する。
特に、送信処理に関連して、アプリケーションデータに対するセキュリティ処理(暗号化など)が行われる場合、処理負荷が大きくなりやすい。つまり、セキュリティ処理の負荷は大きいため、過剰なデータに対してセキュリティ処理をアプリケーションにて行うと、アプリケーションの処理負荷が非常に大きくなる。
また、非特許文献2に規定する拡張層(Extended Layer)が利用される場合、拡張層では、アプリケーションデータの分割処理という複雑な処理をアプリケーションでも事前に行う必要が生じ、アプリケーションの処理負荷が非常に大きくなる。
そこで、本発明は、送信期間において送信可能なアプリケーションのデータ量を、アプリケーションデータの送信要求元が容易に認識できるようにすることを目的とする。
(1)一の観点からみた本発明は、アプリケーションデータの送信要求に応じて、前記アプリケーションデータを、周期的に割り当てられる1又は複数の送信期間において送信させる通信処理部を備え、前記通信処理部は、一周期で割り当てられる1又は複数の前記送信期間において送信できるアプリケーションデータのデータ量を前記送信要求の要求元に認識させるための情報を、前記要求元に通知する通知処理を行うことを特徴とする通信機である。
上記本発明によれば、一周期で割り当てられる1又は複数の前記送信期間において送信できるアプリケーションデータのデータ量が、送信要求の要求元に通知されるため、要求元は、周期で割り当てられる1又は複数の前記送信期間において送信できるアプリケーションデータのデータ量を容易に認識することができる。
(2)前記通信処理部は、送信要求された前記アプリケーションデータのうち、一周期内で割り当てられる1又は複数の前記送信期間内で送信しきれないデータを破棄する破棄処理を行うのが好ましい。この場合、破棄処理にて破棄されたデータは、通信処理部における破棄処理後の処理の対象とならないため、無駄な処理の発生を抑制できる。
(3)前記通信処理部は、通信機が準拠する通信プロトコルにおける複数のレイヤの処理を行うように構成され、前記通知処理によって通知される前記情報の生成処理と、前記破棄処理と、は、複数の前記レイヤのうちの同一のレイヤにおける処理として行われるのが好ましい。生成処理と破棄処理とが同一レイヤで行われることで、処理が容易となる。
(4)前記通信処理部は、通信機が準拠する通信プロトコルにおける複数のレイヤの処理を行うように構成され、前記複数のレイヤには、送信要求された前記アプリケーションデータに対するセキュリティ処理と、前記セキュリティ処理が行われた前記アプリケーションデータに対するデータ分割処理と、が行われる所定のレイヤを含み、前記所定のレイヤでは、前記通知処理によって通知される前記情報の生成も行われるのが好ましい。セキュリティ処理とデータ分割処理とが行われるレイヤ(例えば、非特許文献2の拡張層)によって、前記情報の生成を行うことで、効率的な処理が行える。
(5)前記通信処理部は、前記アプリケーションデータを一周期で割り当てられる1又は複数の前記送信期間において送信させる通信処理の結果に基づいて、前記通知処理によって通知される前記情報を生成するのが好ましい。一周期で割り当てられる1又は複数の前記送信期間において送信できるアプリケーションデータのデータ量を送信要求の要求元に認識させるための情報の生成を、通信処理の結果に基づいて生成することで、適切な情報を生成することができる。
(6)前記通知処理は、送信要求された前記アプリケーションデータを、一周期内で割り当てられる1又は複数の前記送信期間内で送信しきれないと判定された場合、又は、送信要求された前記アプリケーションデータを送信するためのパケットのデータ量が、1又は複数の前記送信期間に占める割合が所定の割合を超えたと判定された場合、に行われるのが好ましい。
この場合、通知の発生頻度を抑えることができる。
(7)他の観点からみた本発明は、前記(1)〜(6)のいずれか1項に記載の通信機に用いられる通信処理装置であって、アプリケーションデータの送信要求に応じて、前記アプリケーションデータを、周期的に割り当てられる1又は複数の送信期間において送信させる通信処理部を備え、前記通信処理部は、一周期で割り当てられる1又は複数の前記送信期間において送信できるアプリケーションデータのデータ量を前記送信要求の要求元に認識させるための情報を、前記要求元に通知することを特徴とする通信処理装置である。
(8)他の観点からみた本発明は、コンピュータを、(7)項記載の通信処理装置として機能させるためのコンピュータプログラムである。
(9)他の観点からみた本発明は、周期的に割り当てられる1又は複数の送信期間において送信されるべきアプリケーションデータの送信要求を、アプリケーションデータの送信処理を行う通信処理装置に対して与える要求部と、一周期で割り当てられる1又は複数の前記送信期間において送信できるアプリケーションデータのデータ量を認識するための情報を、前記通信処理装置から取得する取得部と、一周期で割り当てられる1又は複数の送信期間において送信されるべきアプリケーションデータのデータ量を、前記情報に基づいて調整するアプリケーション装置である。
(10)他の観点からみた本発明は、コンピュータを、(9)項記載のアプリケーション装置として機能させるためのコンピュータプログラムである。
(11)他の観点からみた本発明は、アプリケーションデータの送信要求が通信処理部に与えられ、前記送信要求を受けた前記通信処理部は、前記送信要求に応じて、前記アプリケーションデータを、周期的に割り当てられる1又は複数の送信期間において送信させるとともに、一周期で割り当てられる1又は複数の前記送信期間において送信できるアプリケーションデータのデータ量を前記送信要求の要求元に認識させるための情報を、前記要求元に通知し、前記要求元は、一周期で割り当てられる1又は複数の送信期間において送信されるべきアプリケーションデータのデータ量を、前記情報に基づいて調整することを特徴とする送信方法である。
本発明によれば、送信期間において送信可能なアプリケーションのデータ量を、アプリケーションデータの送信要求元が容易に認識することができる。
高度道路交通システムの実施の一形態を示す概略斜視図である。 路側通信機の構成図である。 (a)は無線フレーム(スーパーフレーム)を示す図であり、(b)は無線フレーム中の送信期間と送信禁止期間を示す図である。 通信機のプロトコルスタックを示す図である。 パケット構造を示す図である。 アプリケーションデータの送信シーケンスである。 図6の送信シーケンスの詳細な説明図である。 アプリケーションデータの送信シーケンスである。 アプリケーションデータの送信シーケンスである。 図9の送信シーケンスの詳細な説明図である。 アプリケーションデータの送信シーケンスである。
[1.第1実施形態]
図1は、本発明の一実施形態に係る高度道路交通システム(ITS)の全体構成を示す概略斜視図である。なお、本実施形態では、道路構造の一例として、南北方向と東西方向の複数の道路が互いに交差した碁盤目構造を想定している。
図1に示すように、本実施形態の高度道路交通システムは、交通信号機1、路側通信機(通信機)2、車載通信機(通信機)3(図2参照)、中央装置4、車載通信機3を搭載した車両5、及び、車両感知器や監視カメラ等よりなる路側センサ6を含む。
なお、本実施形態において特に説明しない点については、非特許文献1,2に準拠する。
交通信号機1と路側通信機2は、複数の交差点A1〜A5,B1〜B5、C1〜C5,D1〜D5のそれぞれに設置されており、電話回線等の有線通信回線7を介してルータ8に接続されている。このルータ8は交通管制センター内の中央装置4に接続されている。
中央装置4は、自身が管轄するエリアの交通信号機1及び路側通信機2とLAN(Local Area Network)を構成している。なお、中央装置4は、交通管制センターではなく道路上に設置してもよい。
路側センサ6は、各交差点に流入する車両台数をカウントする等の目的で、管轄エリア内の道路の各所に設置されている。この路側センサ6は、直下を通行する車両5を超音波感知する車両感知器、或いは、道路の交通状況を時系列に撮影する監視カメラ等よりなり、感知情報や画像データは通信回線7を介して中央装置4に送信される。
なお、図1では、図示を簡略化するために、各交差点に信号灯器が1つだけ描写されているが、実際の各交差点には、互いに交差する道路の上り下り用として少なくとも4つの信号灯器が設置されている。
高度道路交通システムにおいて、無線通信システムを構成する、複数の交差点それぞれに設置された複数の路側通信機(通信機)2は、その周囲を走行する車両の車載通信機3との間で無線通信(路車間通信)が可能である。
また、各路側通信機2は、自己の送信波が到達する所定範囲内に位置する他の路側通信機2とも無線通信(路路間通信)が可能である。
また、同じく無線通信システムを構成する車載通信機(通信機)3は、路側通信機2との間で無線通信を行うとともに、キャリアセンス方式で他の車載通信機3と無線通信(車車間通信)が可能である。
路側通信機2は、図2に示すように、無線通信のためのアンテナ20が接続された無線通信部(RF部;PHY部)21と、有線通信回線7を介して中央装置4と通信するための有線通信部22と、通信制御処理を行う通信処理装置25と、を備えている。
通信処理装置25は、制御部23と、必要な情報を記憶する記憶部24と、を備えている。制御部23は、無線通信及び有線通信の通信制御処理を行う。記憶部24は、無線通信及び優先通信のために必要な情報を記憶する。
通信処理装置25は、その機能の一部又は全部が、ハードウェア回路によって構成されていてもよいし、その機能の一部又は全部が、コンピュータプログラムによって実現されていてもよい。通信処理装置25の機能の一部又は全部がコンピュータプログラムによって実現される場合、通信処理装置25(制御部23)は、コンピュータを含み、コンピュータによって実行されるコンピュータプログラムは、記憶部24に記憶される。
図3(a)は、無線通信システムにおいて用いられる無線フレーム(スーパーフレーム)を示している。この無線フレームは、その時間軸方向の長さ(フレーム長)が100msに設定されている。つまり、1秒間に10フレームが発生する。
フレームは、例えば、路側通信機2が有するGPS受信機(図示省略)によって受信したGPS信号に含まれる1PPS(1秒周期の信号)に基づいて生成される。
一つの無線フレーム(100ms)は、複数の路車間通信期間SL1と、複数の車車間通信期間SL2と、を含んで構成されている。
路車間通信期間SL1は、路側通信機2に割り当てられる路車間通信用のタイムスロット(路側通信機用送信期間)であり、この時間帯SL1においては、路側通信機2による無線送信が許容される。路車間通信期間SL1は、一つの無線フレーム(100ms)内に最大16個まで設定可能である。
車車間通信期間SL2は、車載通信機3用のタイムスロット(車用通信期間)であり、この時間帯SL2は車載通信機3による無線送信用として開放するため、路側通信機2は路車間通信期間SL2では無線送信を行わない。
無線フレームに含まれている路車間通信期間SL1と、車車間通信期間SL2とは、時間軸方向に交互に配置されている。
路車間通信期間SL1には、それぞれスロット番号i(=1〜16)が付されている。
それぞれの路側通信機2には、無線フレームに含まれる複数の路車間通信期間SL1のうちの、一つ又は複数の路車間通信期間SL1が送信期間として設定され、その他の路車間通信期間SL1は送信が禁止される。すなわち、路側通信機2にとっては、車車間通信期間SL2及び自機2に割り当てられていない路車間通信期間SL1は、送信禁止期間となる。
図3(b)では、路側通信機2にn=4,5,6の3つの路車間通信期間SL1が送信期間として割り当てられている場合の送信禁止期間を示している。路側通信機2は、送信禁止期間以外の期間(送信期間)でデータ送信を行う。
一つの無線フレーム内において、一の路側通信機2に割り当てられる送信期間の数は任意である。また、一つの送信期間の期間長は、路車通信期間の期間長と等しくてもよいし、路車間通信期間よりも短くてもよい。また、一つの路車間通信期間内に複数の送信期間が設定されてもよい。
図4は、非特許文献1の標準規格に示す通信プロトコルスタックに、非特許文献2のガイドラインに示す拡張層(Extended Layer)ELを加えたものを示している。また、図4では、非特許文献1,2に規定されていない幾つかの機能も示している。
非特許文献1に規定されるプロトコルスタックは、レイヤ1(L1,物理層:Physical Layer)、レイヤ2(L2,データリンク層:Data Link Layer)、車車間・路車間共用通信制御情報層(IVC−RVC層:Inter-Vehicle Communication - Road to Vehicle Communication Layer)及びレイヤ7(L7,アプリケーション層:Application Layer)の4構造である。各層及びアプリケーションAPは、システム管理のための情報を有するシステム管理にアクセスすることができる。
レイヤ1は、IEEE802.11において規定される物理層に準拠して動作する。
レイヤ2は、MAC副層(Medium Access Control sublayer)と、LLC副層(Logical Link Control sublayer)と、から構成される。なお、MAC副層を、単に、MAC層(Medium Access Control layer)ともいい、LLC副層(Logical Link Control sublayer)を、単に、LLC層(Logical Link Control layer)ともいう。
MAC層は、無線チャネルの通信管理として、フレーム制御及び同報通信(ブロードキャスト)を行う。
LLC層は、上位層のエンティティ間でパケット伝送を行うために、確認なしコネクションレス型通信のサービスを提供する。
車車間・路車間共用通信制御情報層(IVC−RVC層)は、車車間・路車間共用通信制御に必要な情報の生成と管理を行う。非特許文献1では、路路間通信は規定されていないため、本実施形態のように、路車間通信期間SL1において路路間通信を行う場合、車車間・路車間共用通信制御情報層(IVC−RVC層)において、路路間通信は、路車間通信の一種として取り扱われる。
レイヤ7は、アプリケーションAPに対して通信制御手段(通信処理部としての機能)を提供するためのものである。アプリケーションAPは、送信される通信パケットに格納されるアプリケーションデータ(交通情報、車両情報など)をレイヤ7に与えるとともに、受信した通信パケットに格納されていたアプリケーションデータをレイヤ7から取得する。
非特許文献2に規定される拡張層ELは、レイヤ7の上位層として存在し、アプリケーションAPとレイヤ7との間の通信機能を拡張するためのものである。
拡張層ELは、アプリケーションAPに対してデータ伝送サービスを提供する。アプリケーションAPは、送信される通信パケットに格納されるアプリケーションデータ(交通情報、車両情報など)を拡張層ELに与える。データ伝送サービス提供のため、拡張層ELは、レイヤ7以下の下位階層に対してデータ伝送要求を出す。
また、拡張層ELは、アプリケーションAPから与えられたアプリケーションデータを分割し、分割データをレイヤ7に与えることができる。つまり、拡張層ELは、アプリケーションデータを分割して複数の分割データを生成する分割処理部として機能する。
また、レイヤ7から受け取った分割データを結合させてアプリケーションAPに与えることができる。
なお、拡張層ELは、レイヤ7とともに、セキュリティ管理にアクセスすることができる。
図4に示す拡張層EL、レイヤ7、IVC−RVC層、レイヤ2、アプリケーションAP、セキュリティ管理、及びシステム管理に相当する機能は、通信処理装置25によって実行される。また、レイヤ1の機能は、無線通信部21によって実行される。
なお、通信処理装置25のうち、図4のアプリケーションAPに相当する機能を、「アプリケーション装置25a」といい、図4のアプリケーションAPよりも下位の機能(拡張層EL、レイヤ7、IVC−RVC層、レイヤ2、セキュリティ管理、及びシステム管理)を、「通信処理部25b」という。
また、例えば、アプリケーション装置25aの機能は、コンピュータプログラムによって実現し、通信処理部25bの機能を、ハードウェアによって構成することができる。また、通信処理部25bの機能を、コンピュータプログラムによって実現してもよい。
図5は、路側通信機2(及び車載通信機3)によって送信される通信パケットの構成を示している。図5に示す通信パケットの構成は、非特許文献1,2に準拠したものである。
通信パケットは、先頭にPHYヘッダ(物理ヘッダ)を有している。PHYヘッダは、送信側の通信機2のレイヤ1(物理層)によって、MAC層から取得したMACフレーム(MPDU;MAC Protocol Data Unit)の前に付加される。
PHYヘッダは、受信側の通信機2,3におけるレイヤ1(物理層)において読み取られて、受信側のレイヤ1における通信制御処理に用いられる。なお、PHYヘッダを含む通信パケット全体が、PPDU(PHY Protocol Data Unit)である。PHYヘッダよりも後側のMACフレーム(MPDU)は、PSDU(PHY Service Data Unit)でもある。
PHYヘッダの構成は、IEEE802.11に準拠する。したがって、PHYヘッダには、プリアンブルなどが含まれる。
PHYヘッダに続いて、MAC制御フィールド(MACヘッダ)及びLLC制御フィールド(LLCヘッダ)が設けられている。MAC制御フィールドは、送信側の通信機2のレイヤ2のMAC層によって、LLC層から取得したLLCフレーム(LPDU;LLC Protocol Data Unit)の前に付加される。
MAC制御フィールドは、受信側の通信機2,3のレイヤ2のMAC層において読み取られて、受信側のMAC層における通信制御処理に用いられる。
MAC制御フィールドよりも後側のLLCフレーム(LPDU)は、MSDU(MAC Service Data Unit)でもある。
MAC制御フィールドに続くLLC制御フィールドは、送信側の通信機2のレイヤ2のLLC層によって、IVC−RVC層から取得したIRフレーム(IPDU;IVC-RVC Protocol Data Unit)の前に付加される。
LLC制御フィールドは、受信側の通信機2,3のレイヤ2のLLC層において読み取られて、受信側のLLC層における通信制御処理に用いられる。
また、LLC制御フィールドよりも後側のIRフレーム(IPDU)は、LSDU(LLC Service Data Unit)でもある。
LLC制御フィールに続いて、IR制御フィールド(IRヘッダ)が設けられている。IR制御フィールドは、送信側の通信機2のIVC−RVC層によって、APフレーム(APDU;Application Protocol Data Unit)の前に付加される。
IR制御フィールドは、受信側の通信機2,3のIVC−RVC層において読み取られて、受信側のIVC−RVC層における通信制御処理に用いられる。
IR制御フィールドよりも後側のAPフレーム(APDU;Application Protocol Data Unit)は、ISDU(IVC-RVC Service Data Unit)でもある。
IR制御フィールドに続いて、L7ヘッダが設けられている。L7ヘッダは、送信側の通信機2のレイヤ7によって、ASDU(Application Service Data Unit)の前に付加される。
L7ヘッダは、受信側の通信機2,3のレイヤ7において読み取られて、受信側のレイヤ7における通信制御処理に用いられる。
レイヤ7ヘッダよりも後側のELフレーム(EL−PDU;EL-Protocol Data Unit)は、ASDU(Application Service Data Unit)でもある。
L7ヘッダに続いて、ELヘッダ(EL基地局ヘッダ)が設けられている。ELヘッダは、送信側の通信機2の拡張層ELによって、EL−SDU(EL-Service Data Unit)の前に付加される。
ELヘッダは、受信側の通信機2,3の拡張層ELにおいて読み取られて、受信側の拡張層ELにおける処理に用いられる。
図6,7は、路側通信機2が、アプリケーションAPにて生成されたアプリケーションデータを送信するためのシーケンスを示している。
まず、アプリケーションAPのアプリケーションデータの生成部31(図4参照)は、路車間通信データ(例えば、図7に示す「路車A」「路車B」)や路路間通信データ(例えば、図7に示す「路路A」「路路B」「路路C」)を生成する。
すると、アプリケーションAPの要求部32(図4参照)は、生成されたアプリケーションデータそれぞれの送信要求であるEL-BaseStationBroadcastData要求を生成する(ステップS1)。
EL-BaseStationBroadcastData要求には、アプリケーションデータのほか、DataAssociatedInformation(データ関連情報)及びEL_ApplicationDataLength(アプリケーションデータの長さ情報)が含まれる。
DataAssociatedInformation(データ関連情報)は、1又は複数のアプリケーションデータそれぞれの順番と、1又は複数のアプリケーションデータの総数と、を含む。
例えば、図7に示すように、路車A、路車B、路路A、路路B、路路Cの5つのデータが生成された場合、総数=5に設定され、5つのアプリケーションデータそれぞれの順番として1〜5の値が設定される。つまり、各アプリケーションデータの「順番/総数」は、路車Aが「1/5」、路車Bが「2/5」、路路Aが「3/5」、路路Bが「4/5」、路路Cが「5/5」となる(図7参照)。
図4に示すように、拡張層ELの取得部がアプリケーションAPからEL-BaseStationBroadcastData要求を受けると、拡張層ELのセキュリティ処理部42は、必要に応じて、セキュリティ処理をセキュリティ管理SECに実行させる。
すなわち、拡張層ELは、アプリケーションAPからアプリケーションデータを受け取った際に、セキュリティ管理を経由する旨の指示を受け取った場合には、アプリケーションAPから受け取ったアプリケーションデータ(アンセキュアなアプリケーションデータ)を、セキュリティ管理SECに渡す(EL-Security要求(セキュリティ処理);ステップS2;図6参照)。なお、セキュリティ処理とは、セキュリティ管理SECにて実行される処理をいうだけでなく、拡張層ELのセキュリティ処理部42がセキュリティ管理SECにEL-Security要求を通知することもセキュリティ処理という。
セキュリティ管理SECでは、拡張層ELから受け取ったアンセキュアなアプリケーションデータに対して、セキュリティ処理を行って、セキュアなアプリケーションデータを生成する。
セキュリティ管理SECにおいて、アンセキュアなアプリケーションデータをセキュアなアプリケーションデータにする処理(セキュリティ処理)には、暗号化処理、署名処理などの処理が含まれる(ただし、非特許文献1,2では規定されていない)。
セキュリティ管理は、セキュリティ処理が施されたセキュアなアプリケーションデータを、拡張層ELに戻す(EL-Security応答;ステップS3;図6参照)。
セキュリティ管理SECによってセキュリティ処理が施されたセキュアなアプリケーションデータは、セキュリティヘッダを有しているなどの理由で、アンセキュアなアプリケーションに比べてデータ量が変動(増加)する。したがって、図7では、ステップS1におけるセキュリティ処理前の各アプリケーションデータのサイズよりも、ステップS2におけるセキュリティ処理後の各アプリケーションデータのサイズのほうが大きくなっている。
つまり、セキュリティ処理は、アプリケーションデータのデータ量を変動させる変動処理である。変動処理によるアプリケーションデータ量の変動は、アプリケーションAP側において、送信可能なデータ量を把握させるのを困難にさせる要因の一つとなっている。
続いて、拡張層ELの分割処理部43(図4参照)は、セキュリティ管理から与えられたセキュアなアプリケーションデータの分割を分割して、分割データを生成する(ステップS−4;データ分割処理)。
拡張層ELは、アプリケーションデータを分割した分割データそれぞれを、EL−SDUとして取り扱う。
拡張層ELのELヘッダ構築部44(図4参照)は、アプリケーションデータを分割して得られた分割データそれぞれを、EL−SDUとして扱い、各EL−SDU(分割データ)の前に付加されるELヘッダ(図7参照)を構築して(ステップS5)、EL−PDUを生成する。
ELヘッダ構築部44は、ELヘッダの生成のため、ELヘッダを構成する分割番号などの情報を生成する。
各分割データ(EL−SDU)に付加されるELヘッダの分割番号は、アプリケーションデータ毎の分割データの順番及び総数を有する。図7のステップS5では、分割番号(順番/総数)を、括弧付き数字で示した(なお、括弧無し数字は、DataAssociatedInformation(データ関連情報)が示すアプリケーションデータそれぞれの「順番/総数」である。
図7では、路路A(1/5)、路路B(2/5)、路車A(3/5)、路車B(4/5)、路車C(5/5)は、分割処理(ステップS4)によって、それぞれは2つに分割されている。
この場合、路路A(1/5)を分割して生成された2つの分割データのうちの一方の分割データに対応する分割番号の「順番」には(1)が設定され、他方の分割データに対応する分割番号の「順番」には(2)が設定される。路路A(1/5)を分割して生成された2つの分割データに対応する分割番号の「総数」には、いずれも(2)が設定される。
他のアプリケーションデータ(路路B(2/5)、路車A(3/5)、路車B(4/5)、路車C(5/5))についても、同様に分割番号が設定される。
なお、アプリケーションデータの分割の際には、路側通信機2に割り当てられた送信期間(図7の送信期間A,送信期間B)の期間長を考慮して、分割が行われる。このため、10個の分割データのうち、路路B(4/5)の2番目の分割データ(2)/(2)と、路路C(5/5)の分割データ(1)/(2),(2)/(2)は、下位レイヤに渡しても、図7の送信期間A,Bでは送信しきれないことがわかる。
そこで、EL層は、送信期間A,Bでは送信しきれない路路B(4/5)の2番目の分割データ(2)/(2)と、路路C(5/5)の分割データ(1)/(2),(2)/(2)を破棄する(破棄処理)。
そして、拡張層ELの要求部45(図4参照)は、レイヤ7への分割データ(EL−PDU)の送信要求であるBaseStationBroadcastData要求(データ送信要求)を生成し、そのBaseStationBroadcastData要求をレイヤ7に対し与える(ステップS6)。
また、要求部45は、拡張層ELは、ELヘッダが付加された各分割データ(EL−PDU)に対応するSequenceNumber(シーケンスナンバ)の設定も行う。SequenceNumber(シーケンスナンバ)は、一つの無線フレーム(送信周期=100ms)毎の送信期間において送信すべき1又は複数のアプリケーションデータすべての分割データの順番/総数を示すものである。
SequenceNumber(シーケンスナンバ)は、分割データ(パケット)のSequence(シーケンス)及びTotalNumber(総数)を含む。
図7では、送信期間A,Bにおいて送信可能な7個の分割データに対し、(Sequence/TotalNumber)として、1/7〜7/7の値が設定される。
BaseStationBroadcastData要求を受けたレイヤ7以下のレイヤでは、SequenceNumber(シーケンスナンバ)が1/7〜7/7である分割データを、送信期間A,Bにて送信させる処理が行われる。
拡張層ELの要求部45がBaseStationBroadcastData要求をレイヤ7に対して行うと、拡張層ELの応答部46(図4参照)は、EL-BaseStationBroadcastData応答を、アプリケーションAPに通知する(ステップS7;通知処理)。このEL-BaseStationBroadcastData応答は、非特許文献1,2では規定されていないものである。
応答部46が生成するEL-BaseStationBroadcastData応答には、一周期内の送信期間A,Bにおいて送信できるアプリケーションデータのデータ量を、EL-BaseStationBroadcastData要求の要求元であるアプリケーションAPに認識させるための情報(送信可能データ量)を含んでいる。応答部46は、前記情報(送信可能データ量)を生成する処理も行う(生成処理)。
送信できないアプリケーションデータを破棄する破棄処理と、前記情報(送信可能データ量)の生成処理と、を、拡張層ELという同一のレイヤで行うことで、処理が容易となる。
前記情報(送信可能データ量)は、例えば、アプリケーションAPからDataAssociatedInformation(データ関連情報)として通知されたアプリケーションデータの「順番/総数」(1/5〜5/5)のうち、送信期間A,Bにて完全に送信できたところまでのアプリケーションデータの「順番/総数」として生成される。
例えば、図7では、完全に送信できるのは、3/5の路路Aのデータまでである(4/5の路路Bのデータは一部しか送信できない)。したがって、前記情報(送信可能データ量)としては、路路Aのデータまで送信できたことを示す「3/5」となる。
また、前記情報(送信可能データ量)としては、送信期間A,Bにて完全に送信できたところまでのアプリケーションデータのデータ量であってもよい。当該データ量は、アプリケーションAPから通知されたEL_ApplicationDataLength(アプリケーションデータの長さ情報)を用いて、送信期間A,Bにて完全に送信できる3/5の路路Aのデータまでのデータ量を求めることができる。
例えば、図7では、1/5の路車Aのデータ量が600B,2/5の路車Bのデータ量が600B、3/5の路路Aのデータ量が300Bの場合、前記情報(送信可能データ量)としては、1500Bとなる。
以上のように、前記情報(送信可能データ量)は、拡張層ELにおける通信処理の結果に基づいて、生成される。
なお、送信期間A,Bにおいて送信できるアプリケーションデータのデータ量を、より正確にアプリケーションAPに認識させるためには、送信できるアプリケーションデータのデータ量は、アプリケーションAPが拡張層ELにアプリケーションデータを渡したときのアプリケーションデータの大きさを基準にすべきである。拡張層ELにおける変動処理によってアプリケーションデータのデータ量に変動が生じている場合、変動処理後のデータ量では、アプリケーションAPとしては、自ら生成したアプリケーションデータのうちのどの程度のデータが送信できたかを把握するのが困難になる。
応答部46は、全てのEL-BaseStationBroadcast要求に対して、EL-BaseStationBroadcastData応答を生成してもよいが、EL-BaseStationBroadcastData応答を生成しない場合があってもよい。
応答部46がEL-BaseStationBroadcastData応答を生成するのは、例えば、アプリケーションAPから送信を要求されたアプリケーションデータを、送信期間A,Bで送信しきれないと判定された場合に限ってもよい。
また、応答部46がEL-BaseStationBroadcastData応答を生成するのは、アプリケーションAPから送信を要求されたアプリケーションデータを送信するためのパケットのデータ量が、送信期間A,Bに占める割合が所定の割合(例えば、80%)を超えたと判定された場合に限ってもよい。
このように、EL-BaseStationBroadcastData応答の生成を制限することで、処理を簡素化することができる。
アプリケーションAPの取得部33(図4参照)が、EL-BaseStationBroadcastData応答を応答部45から受け取ると、EL-BaseStationBroadcastData応答に含まれる前記情報(送信可能データ量)は、アプリケーションAPの調整部34(図4参照)に与えられる。
拡張層ELは、EL-BaseStationBroadcastData要求を拡張層EL与えたときの、DataAssociatedInformation(データ関連情報)及びEL_ApplicationDataLength(アプリケーションデータの長さ情報)を、EL-BaseStationBroadcastData応答があるまで保持する。
調整部34は、EL-BaseStationBroadcastData応答に含まれる前記情報(送信可能データ量)を取得すると、EL-BaseStationBroadcastData要求を拡張層EL与えたときの、DataAssociatedInformation(データ関連情報)及び/又はEL_ApplicationDataLength(アプリケーションデータの長さ情報)を参照し、送信できたアプリケーションデータを特定する。また、送信できたアプリケーションデータの総データ量も特定する。
アプリケーションAPは、送信できたものとして特定されたアプリケーションデータについては破棄する。送信できなかったデータのうち、再送が必要な情報(例えば、路路間通信データ)については、再送のために保持する。
また、調整部34は、送信できたアプリケーションデータの総データ量を、生成部31に与える。生成部31は、新たにアプリケーションデータを生成する場合、調整部34から与えられた総データ量を、送信可能な総データ量とみなして、当該総データ量を超えない範囲で、送信周期(100ms)毎に送信すべきアプリケーションデータを生成する。
したがって、アプリケーションAPから拡張層EL以下のレイヤに与えられるアプリケーションデータのデータ量が、一送信周期(100ms)内の送信期間A,Bで送信可能なデータ量を超えることが抑制され、送信できないデータが無駄に拡張層EL以下のレイヤに与えられて、無駄な処理(特に、送信されないデータへのセキュリティ処理)が行われることが防止される。
なお、アプリケーションAPは、拡張層ELからEL-BaseStationBroadcastData応答を受け取る前には、一送信周期で送信可能な総データ量が把握できない。したがって、アプリケーションAPは、少なくとも1回は、一送信周期で送信可能な総データ量を超えたアプリケーションデータを、拡張層ELに与えてしまう可能性がある。しかし、拡張層ELからEL-BaseStationBroadcastData応答を受け取ると、一送信周期で送信可能な総データ量を認識できるため、通信処理部25bにおける無駄な処理(特に、セキュリティ処理)の発生を抑制することができる。
アプリケーションAPが、無駄なアプリケーションデータを通信処理部25bに与えないようにするには、アプリケーションAP自身が、通信処理部25における処理(拡張層EL以下の処理)を模擬して、送信期間A,Bにて送信可能なデータ量を見積もることも可能ではある。しかし、この場合、アプリケーションAPが、情報処理部25における処理と同様の処理を2重に行うことになり、無駄が生じる。
また、仮に、アプリケーションAPが、情報処理部25における処理よりも簡易な処理で、送信期間A,Bにて送信可能なデータ量を見積もることで、2重処理を軽減することはできる。ただし、この場合も、ある程度の2重処理になり、処理効率が低くなる。
これに対し、第1実施形態のように、実際に通信処理を行う通信処理部25b(拡張層EL)から送信期間A,Bにて送信可能なデータ量を示す情報を取得することで、2重処理を回避することができる。
また、第1実施形態では、セキュリティ処理後のアプリケーションデータを分割することで、分割データが送信期間A,Bにて送信可能であるかの判定がなされたが、セキュリティ処理前に、送信期間A,Bにて送信可能なアプリケーションデータのデータ量を見積もってもよい。
例えば、セキュリティ管理SECでのセキュリティ処理の前に、拡張層ELにて、セキュリティ管理SECでのセキュリティ処理後のアプリケーションデータのデータ量を推定する。そして、セキュリティ処理後のアプリケーションデータで仮想的な分割を行って、送信期間A,Bに収まるアプリケーションデータと収まらないアプリケーションデータを特定する。
そして、応答部46は、送信期間A,Bに収まるアプリケーションデータのデータ量をアプリケーションAPに認識させるための情報を含むEL-BaseStationBroadcast応答を、アプリケーションAPに通知する。
さらに、拡張層ELは、セキュリティ管理SECに渡すアプリケーションデータを、送信期間A,Bに収まるアプリケーションデータだけにすることで、無駄なセキュリティ処理の発生を防止できる。
また、第1実施形態において、拡張層ELが、アプリケーションAPからアプリケーションデータを受け取った際に、セキュリティ管理SECを経由しない旨の指示を受け取った場合には、図8に示すように、EL-Security要求(ステップS2)は省略される。
したがって、拡張層ELの分割処理部43は、アプリケーションAPから受け取ったアプリケーションデータ(アンセキュアなアプリケーションデータ)を分割して、分割データを生成する。
[2.第2実施形態]
図9,10は、第2実施形態に係る路側通信機2が、アプリケーションAPにて生成されたアプリケーションデータを生成するためのシーケンスを示している。第2実施形態の路側通信機2は、図4の拡張層ELを省略したものに相当する。したがって、拡張層ELによるアプリケーションデータの分割は行われない。また、第1実施形態において拡張層ELが有していた応答部46は、第2実施形態においてはMAC層が有する。
なお、第2実施形態において説明を省略した点については、第1実施形態と同様である。
まず、アプリケーションAPのアプリケーションデータの生成部31は、路車間通信データ(例えば、図10に示す「路車A」「路車B」)や路路間通信データ(例えば、図10に示す「路路A」「路路B」「路路C」)を生成する。
すると、アプリケーションAPの要求部32は、生成されたアプリケーションデータそれぞれの送信要求であるBaseStationBroadcastData要求を生成する(ステップS11)。
BaseStationBroadcastData要求には、アプリケーションデータのほか、SequenceNumber(シーケンスナンバ)が含まれる。
SequenceNumber(シーケンスナンバ)は、一つの無線フレーム(送信周期=100ms)毎の送信期間において送信すべき1又は複数のアプリケーションデータの順番/総数を示すものである。
SequenceNumber(シーケンスナンバ)は、アプリケーションデータそれぞれのSequence(シーケンス)及びTotalNumber(総数)を含む。
図10では、生成された5個のアプリケーションデータ(路車A,路車B,路路A,路路B,路路C)に対して、(Sequence/TotalNumber)として、1/5〜5/5の値が設定される。
アプリケーションAPの要求部32は、SequenceNumber(シーケンスナンバ)とともに、BaseStationBroadcastData要求(データ送信要求)をレイヤ7へ与える(ステップS11)。
レイヤ7(L7)では、アプリケーションAPからBaseStationBroadcastData要求を受けると、セキュリティ処理をセキュリティ管理SECに実行させる。
すなわち、レイヤ7は、アプリケーションAPからアプリケーションデータを受け取った際に、セキュリティ管理を経由する旨の指示を受け取った場合には、アプリケーションAPから受け取ったアプリケーションデータ(アンセキュアなアプリケーションデータ)を、セキュリティ管理SECに渡す(Security要求(セキュリティ処理);ステップS12;図9参照)。なお、セキュリティ処理とは、セキュリティ管理SECにて実行される処理をいうだけでなく、レイヤ7がセキュリティ管理SECにSecurity要求を通知することもセキュリティ処理という。
セキュリティ管理SECでは、レイヤ7から受け取ったアンセキュアなアプリケーションデータに対して、セキュリティ処理を行って、セキュアなアプリケーションデータを生成する。
セキュリティ管理SECにおいて、アンセキュアなアプリケーションデータをセキュアなアプリケーションデータにする処理(セキュリティ処理)には、暗号化処理、署名処理などの処理が含まれる。
セキュリティ管理は、セキュリティ処理が施されたセキュアなアプリケーションデータを、レイヤ7に戻す(Security応答;ステップS13;図9参照)。
アプリケーションデータは、セキュリティ処理前よりもセキュリティ処理後のほうが大きくなる。
続いて、レイヤ7は、L7ヘッダが付加されたアプリケーションデータ(APDU)をIVC−RVC層へ与えるためのIR−UNITDATA要求をIVC−RVC層に送付する(ステップS14;図9参照)。
IVC−RVC層は、APDUにIR制御フィールドを付加してIPDUを生成し、そのIPDUをLLC層に与えるためのDL−UNITDATA要求をLLC層に送付する(ステップ15;図9参照)。
LLC層は、IPDUにLLC制御フィールドを付加してLPDUを生成し、そのLPDU(MSDU)をMAC層に与えるためのMA−UNITDATA要求をMAC層に送付する(ステップS16;図9参照)。
MAC層は、LLC層から受領したMSDUを保持する。MAC層は、保持したMSDUのSequenceNunber(Sequence/TotalNumber)を参照し、TotalNumber(総数)に示された数の一連のMSDU群がすべて揃っていれば、送信周期(100ms)毎に到来する送信期間A,Bの開始時から順に、MPDU(MAC Protocol Data Unit)の生成を行い、レイヤ1に対して、送信要求を行う。
MAC層は、TotalNumber(総数)に示された数の一連のMSDU群を、一つの送信周期における送信期間A,Bで送信しきれない場合、送信できなかった送信できなかったパケット(MPDU)を破棄する(破棄処理)。
MAC層は、送信期間A,Bを用いた送信が完了すると、MA−UNITDATA応答を、LLC層に通知する(ステップS17;通知処理)。
MAC層が生成するMA−UNITDATA応答には、一周期内の送信期間A,Bにおいて送信できるアプリケーションデータのデータ量を、BaseStationBroadcastData要求の要求元であるアプリケーションAPに認識させるための情報(送信可能データ量)を含んでいる。MAC層(の応答部46)は、前記情報(送信可能データ量)を生成する処理も行う(生成処理)。
送信できないアプリケーションデータを破棄する破棄処理と、前記情報(送信可能データ量)の生成処理と、を、MAC層という同一のレイヤで行うことで、処理が容易となる。
前記情報(送信可能データ量)は、例えば、アプリケーションAPからSequenceNunber(Sequence/TotalNumber)として通知されたアプリケーションデータの「順番/総数」(1/5〜5/5)のうち、送信期間A,Bにて完全に送信できたところまでのアプリケーションデータの「順番/総数」として生成される。
例えば、図10では、完全に送信できるのは、4/5の路路Bのデータまでである。したがって、前記情報(送信可能データ量)としては、路路Bのデータまで送信できたことを示す「4/5」となる。
また、前記情報(送信可能データ量)としては、第1実施形態と同様に、送信期間A,Bにて完全に送信できたところまでのアプリケーションデータのデータ量であってもよい。
例えば、図10では、1/5〜4/5までのデータ量が、1500Bである場合、前記情報(送信可能データ量)としては、1500Bとなる。
なお、前記情報(送信可能データ量)として、「4/5」と「1500B」の双方が存在していてもよい。
以上のように、前記情報(送信可能データ量)は、MAC層における通信処理の結果に基づいて、生成される。
LLC層は、MAC層からMA−UNITDATA応答を受けると、そのMA−UNITDATAに含まれる前記情報(送信可能データ量)を含むDL−UNITDATA応答を、IVC−RVC層に通知する(ステップS18;通知処理)。
IVC−RVC層は、LLC層からDL−UNITDATA応答を受けると、そのDL−UNITDATAに含まれる前記情報(送信可能データ量)を含むIR−UNITDATA応答を、レイヤ7に通知する(ステップS19;通知処理)。
レイヤ7は、IVC−RVC層からIR−UNITDATA応答を受けると、そのIR−UNITDATAに含まれる前記情報(送信可能データ量)を含むBaseStationBroadcastData応答を、アプリケーションAPに通知する(ステップS20;通知処理)。
なお、MA−UNITDATA応答(ステップS17)、DL−UNITDATA応答(ステップS18)、IR−UNITDATA応答(ステップS19)、BaseStationBroadcastData応答(ステップS20)は、いずれも、非特許文献1,2では規定されていないものである。
アプリケーションAPの取得部33が、BaseStationBroadcastData応答(ステップS20)を受け取ると、BaseStationBroadcastData応答に含まれる前記情報(送信可能データ量)は、アプリケーションAPの調整部34に与えられる。
この結果、第1実施形態と同様に、アプリケーションAPからレイヤ7以下のレイヤに与えられるアプリケーションデータのデータ量が、一送信周期(100ms)内の送信期間A,Bで送信可能なデータ量を超えることが抑制され、送信できないデータが無駄にレイヤ7以下のレイヤに与えられて、無駄な処理(特に、送信されないデータへのセキュリティ処理)が行われることが防止される。
なお、第2実施形態において、レイヤ7が、アプリケーションAPからアプリケーションデータを受け取った際に、セキュリティ管理SECを経由しない旨の指示を受け取った場合には、図11に示すように、Security要求(ステップS12)は省略される。
本発明に関して、今回開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は、上記した意味ではなく、特許請求の範囲と均等の意味及び範囲内でのすべての変更が含まれることが意図される。
1 交通信号機
2 路側通信機
3 車載通信機
4 中央装置
5 車両
6 路側センサ
7 有線通信回線
21 無線通信部
22 有線通信部
23 制御部
24 記憶部
25 通信処理装置
25a アプリケーション装置
25b 通信処理部
31 生成部
32 要求部
33 取得部
34 調整部
41 取得部
42 セキュリティ処理部
43 分割処理部
44 ヘッダ構築部
45 要求部
46 応答部
AP アプリケーション(アプリケーション装置)
EL 拡張層

Claims (15)

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

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2012221622A JP6342109B2 (ja) 2012-10-03 2012-10-03 通信機、通信処理装置、アプリケーション装置、コンピュータプログラム、及び送信方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2012221622A JP6342109B2 (ja) 2012-10-03 2012-10-03 通信機、通信処理装置、アプリケーション装置、コンピュータプログラム、及び送信方法

Publications (2)

Publication Number Publication Date
JP2014075678A JP2014075678A (ja) 2014-04-24
JP6342109B2 true JP6342109B2 (ja) 2018-06-13

Family

ID=50749557

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2012221622A Active JP6342109B2 (ja) 2012-10-03 2012-10-03 通信機、通信処理装置、アプリケーション装置、コンピュータプログラム、及び送信方法

Country Status (1)

Country Link
JP (1) JP6342109B2 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109658723B (zh) * 2019-01-29 2020-11-24 郑州轻工业学院 一种交通移动化调度方法及调度平台

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007264825A (ja) * 2006-03-27 2007-10-11 Kenwood Corp 情報提供システム、情報提供装置、車載装置および情報提供方法
JP5649423B2 (ja) * 2010-12-01 2015-01-07 三菱電機株式会社 無線通信システムおよび無線通信方法

Also Published As

Publication number Publication date
JP2014075678A (ja) 2014-04-24

Similar Documents

Publication Publication Date Title
EP3711444B1 (en) Method and apparatus for performing sidelink communication by ue in nr v2x
CN110099370B (zh) 服务层南向接口和服务质量
US10659940B2 (en) Method and apparatus for context aware neighbor discovery in a network
CN105794135B (zh) 用于数据传输的跨层和跨应用确认
Shao et al. A multi-priority supported medium access control in vehicular ad hoc networks
CN102244683B (zh) 一种提高车联网应用中混合业务服务质量的方法
GB2507277A (en) Reserving shared medium resources in overlapping wireless networks
US11743759B2 (en) Method for effectively transmitting downlink data by server for controlling TCU mounted in vehicle
JP6342109B2 (ja) 通信機、通信処理装置、アプリケーション装置、コンピュータプログラム、及び送信方法
JP6007626B2 (ja) 通信機、移動局、無線通信システム、及びコンピュータプログラム
JP5949419B2 (ja) 無線通信システム、及びこれに用いる路側通信機、通信制御装置、コンピュータプログラム、通信方法
JP6338815B2 (ja) 通信機、送信方法、通信処理装置、及びコンピュータプログラム
JP6328412B2 (ja) 通信システム、基地局、通信方法および通信処理プログラム
JP6423591B2 (ja) 基地局、通信処理装置、送信方法、及びコンピュータプログラム
US20230087496A1 (en) Method for vru to predict movement path in wireless communication system supporting sidelink, and device for same
JP6055265B2 (ja) 移動局、コンピュータプログラム、及び通信パケットのデータ構造
JP2015115869A (ja) 通信システム、路側通信機、処理装置、処理方法およびコンピュータプログラム
JP6286817B2 (ja) 通信システム、通信機、通信処理装置、コンピュータプログラム、及び通信方法
JP2017073819A (ja) 通信機、送信方法、通信処理装置、及びコンピュータプログラム
Kloiber et al. Random transmit jitter against correlated packet collisions in vehicular safety communications
JP2018156664A (ja) 通信システム、基地局、通信方法および通信処理プログラム
EP4280637A1 (en) Method for transmitting message by v2x terminal in wireless communication system and device therefor
US20240064615A1 (en) Advertising service information for a service
JP6233479B2 (ja) 通信機、移動局、無線通信システム、及びコンピュータプログラム
JP6649712B2 (ja) 制御装置、無線装置、及び無線通信装置

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20150522

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20160323

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20160329

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20160526

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20161018

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170118

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20170126

A912 Re-examination (zenchi) completed and case transferred to appeal board

Free format text: JAPANESE INTERMEDIATE CODE: A912

Effective date: 20170303

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20180208

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20180516

R150 Certificate of patent or registration of utility model

Ref document number: 6342109

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250