JP6992271B2 - 無線通信端末 - Google Patents

Description

本発明は、無線通信端末に関し、特に、データの送信順序を決定する技術に関する。

特許文献１では、パケットを、通信品質に関する要求値を持つパケットと、通信品質に関する要求値を持たないパケットに分け、通信品質に関する要求値が高いパケットを優先して送信する。通信品質としては、伝送速度、伝送遅延、ジッタが例示されている。

特開２００４－１４０６０４号公報

通信品質に関する要求値が高くても、優先して送信する必要がないデータもある。たとえば、以下の例がある。無線通信端末が車両に搭載されており、車載カメラが撮像した画像により道路異常が検出された場合、その場所の画像を撮像した画像データは、道路を管理するサーバ等に迅速に送信される必要がある。そのため、道路異常が発生している場所の画像データを送信する無線通信端末は、通信品質に関する要求値を高くすることが想定される。

しかし、１つの無線通信端末が、道路異常が発生している場所の画像データを送信すればよい。したがって、１つの無線通信端末が、道路異常が発生している場所の画像データを送信した後は、通信品質に関する要求値が高くても、道路異常が発生している場所の画像データは、優先して送信する必要がない。

本発明は、この事情に基づいて成されたものであり、その目的とするところは、送信する価値が高い送信データを優先して送信することができる無線通信端末を提供することにある。

上記目的は独立請求項に記載の特徴の組み合わせにより達成され、また、下位請求項は、発明の更なる有利な具体例を規定する。特許請求の範囲に記載した括弧内の符号は、一つの態様として後述する実施形態に記載の具体的手段との対応関係を示すものであって、本発明の技術的範囲を限定するものではない。

上記目的を達成するための本発明は、
送信データをデータ供給部から取得し、取得した送信データを送信データの種別により定まる通信品質要求に基づいて優先度クラス別に分類して、優先度クラス別に優先度バッファに記憶するデータ分類部（１１０）と、
優先度バッファに記憶されている送信データのデータ価値単価を決定するデータ価値単価決定部（１１１、６１１、７１１、８１１）と、
データ価値単価決定部が決定したデータ価値単価に基づいて送信データ価値単価を決定する送信価値単価決定部（１１２、２１２、３１２、４１２、５１２、９１２）と、
送信価値単価決定部が決定した送信データ価値単価が予め設定した送信閾値以上である送信データを送信順序付与対象として、データ分類部が分類した優先度クラスに基づいて、送信順序を付与する送信順序制御部（１１３、９１３、１０１３）と、
送信順序制御部が決定した送信順序に基づいて、送信データに通信リソースを割り当てるリソース割り当て部（１１４、９１４）と、
リソース割り当て部が割り当てた通信リソースで送信データを送信する送信部（１０１）とを備える無線通信端末である。

本発明では、送信データに対して、データの種別により定まる優先度クラスに加え、データ価値単価を決定し、このデータ価値単価に基づいて送信データ価値単価を決定する。この送信データ価値単価が送信閾値以上の送信データを送信順序付与対象として、優先度クラスに基づいて送信順序を付与する。

これにより、優先度クラスが高くても、送信データ価値単価が低い送信データには送信順序が付与されないことになる。その結果、送信する価値が高い送信データを優先して送信することができる。

第１実施形態の無線通信端末１００の使用状態を示す図である。 図１の無線通信端末１００の構成図である。 第１実施形態における優先度クラスを示す図である。 データ種別とデータ価値単価との対応関係を示すテーブルである。 第１実施形態において制御部１０４が実行する処理をフローチャートで示している。 図５のＳ７の詳細処理を示すフローチャートである。 第２実施形態の無線通信端末２００の構成図である。 図３からベストエフォート部分を抽出した表である。 第３実施形態の無線通信端末３００の構成図である。 図４の一部を抽出した表である。 データ価値単価を加算して送信データ価値単価を決定する図である。 データ価値単価を送信閾値ＴＨと比較して示す図である。 データ価値単価が加算された部分が送信閾値ＴＨを超えることを示す図である。 第４実施形態における無線通信端末４００の構成を示すブロック図である。 包含関係にある集合Ａと集合Ｂを示す図である。 送信価値単価決定部４１２が実行する処理を説明する図である。 送信価値単価決定部４１２が決定する送信データ価値単価の具体例を説明する図である。 第５実施形態における無線通信端末５００の構成を示すブロック図である。 導出関係を示す図である。 データ価値単価を加算して送信データ価値単価を決定する具体例を示す図である。 第６実施形態の無線通信端末６００の構成を示すブロック図である。 データ価値マップの一例を示す図である。 第７実施形態の無線通信端末７００の構成を示す図である。 第８実施形態の無線通信端末８００の構成を示す図である。 第９実施形態の無線通信端末９００の構成を示す図である。 第１０実施形態の無線通信端末１０００の構成を示す図である。 ２つの送信閾値ＴＨ１、ＴＨ２と送信データ価値単価の関係を示す図である。

＜第１実施形態＞
以下、本発明の実施形態を図面に基づいて説明する。図１は、本発明が適用された無線通信端末１００の使用状態を示している。図１に示す無線通信端末１００は、移動装置である車両２で用いられ、車両２とともに移動する。

無線通信端末１００は、サーバ３との間でデータの通信を行う。データの通信は送信と受信がある。無線通信端末１００とサーバ３との間の通信は、基地局４と通信回線網５とを介して行われる。無線通信端末１００からサーバ３へのデータ送信は上り送信であり、サーバ３から無線通信端末１００への送信は下り送信である。

［無線通信端末１００の構成］
無線通信端末１００は、図２に示すように、無線通信部１０１、優先度バッファ１０２、記憶部１０３、制御部１０４を備えている。無線通信部１０１は、電波で信号の送受信を行い、基地局４、通信回線網５を介して、サーバ３と通信を行う。無線通信部１０１が送受信を行う電波の周波数は、法規上、許容されていれば特に制限はない。また、通信方式は、移動通信システムで用いられているＬＴＥなどの通信方式に限られず、無線ＬＡＮなどの狭域通信を組み合わせて用いてもよい。無線通信部１０１は無線送信機能を備えており、請求項の送信部として機能する。

優先度バッファ１０２は、無線通信端末１００が送信するデータ（以下、送信データ）を一時的に記憶する。優先度バッファ１０２は、複数の優先度クラス別に送信データを格納する構成である。

本実施形態では、優先度クラスは、送信データのリアルタイム性に関する要求の高さにより定められている。図３に本実施形態における優先度クラスを例示している。図３には、優先度クラスとして、Ｃｏｎｔｒｏｌ、Ｕ＿Ｐ１、Ｕ＿Ｐ３、Ｕ＿Ｐ７、Ｕ＿Ｐ９が示されている。Ｃｏｎｔｒｏｌは制御チャネルを使用する優先度クラスという意味であり、最も優先度が高いことを意味する。Ｕ＿Ｐ１、Ｕ＿Ｐ３、Ｕ＿Ｐ７、Ｕ＿Ｐ９において、「Ｕ」はアップリンクであることを示しており、数字は小さいほど優先度が高い。

図３において、優先度クラスの上の行にはリアルタイム性に関する要求の高さが示されている。「Ｈａｒｄ」は、デッドラインまでに処理が行われないと重大な問題が生じることを意味する。「ｆｉｒｍ」は、デッドラインまでに処理が行われなくても、重大な問題が生じることはないが、デッドライン以降に処理を行っても処理の価値はゼロであることを意味する。

「ｓｏｆｔ」は、デッドラインまでに処理が行われなくても、重大な問題が生じることはなく、また、デッドライン以降に処理が行われる場合、処理の価値は、即座にゼロにはならず、徐々に低下することを意味する。

優先度クラスがＣｏｎｔｒｏｌに対応するリアルタイム性には、ｈａｒｄ以外にｕｎｋｎｏｗｎもある。リアルタイム性が不明の場合、リアルタイム性がｈｒａｄである可能性もあるからである。

リアルタイム性がｈｒａｄまたはｕｎｋｎｏｗｎ、優先度クラスがＣｏｎｔｒｏｌになっている送信データは、帯域確保型の通信方式でデータを送信する。優先度クラスがｆｉｒｍ、優先度クラスがＵ＿Ｐ１になっている送信データは、帯域保証型の通信方式でデータを送信する。リアルタイム性がｓｏｆｔなっている送信データは、ベストエフォート型の通信方式でデータを送信する。

このようにリアルタイム性は、デッドラインまでに処理が行われるか否かを指標としており、デッドラインまでに処理が行われるか否かには、伝送速度、伝送遅延が関係する。したがって、送信データのリアルタイム性に関する要求の高さにより優先度クラスを決定することは、送信データの種別により定まる通信品質要求に基づいて優先度クラスを定めていることになる。

図３においてサービスＩＤは、送信データを利用して実行する処理、あるいは、送信データの送信要求を特定するＩＤである。データＩＤは、サービスＩＤにより特定されるサービスにおいて必要となるデータを特定するＩＤである。なお、理解を容易にするために、図３では、サービスＩＤ、データＩＤともに単語で示さしているが、実際には、サービスＩＤ、データＩＤは数字列あるいは数字と文字の組み合わせで表現される。図３では、サービスＩＤとして示されている単語が、実行するサービスの種別を意味し、データＩＤとして示されている単語が送信データの種別を意味する。

「クエリ」は、送信データの送信要求である。クエリは、データ種別のいずれかに該当する送信データではないので、データＩＤは付与されておらず、また送信データ自体ではないことから、送信データは不明なのでリアルタイム性はｕｎｋｎｏｗｎになっている。

「電子牽引」は、電子制御により後続車両を牽引する制御であり、送信データは、後続車両を制御する制御信号になる。「遠隔監視」は、監視地点を、監視地点から離れた位置から監視するサービスであり、送信データは、その地点を撮像した画像データになる。

優先度クラスがＵ＿Ｐ３の「走行異常検出」は、車両２の走行異常を検出するサービスであり、送信データは、走行異常を検出しているときに車載前方カメラで撮像した画像データである。優先度クラスがＵ＿Ｐ７の「走行異常検出」は、車両２の走行異常を検出するサービスであり、送信データはＣＡＮデータである。なお、「ＣＡＮ」は登録商標である。「故障診断」は、車両２の故障を診断するサービスであり、送信データはＣＡＮデータである。

優先度クラスがＵ＿Ｐ９の「走行異常検出」は、車両２の走行異常を検出するサービスである点で優先度クラスがＵ＿Ｐ３の「走行異常検出」と同じである。また、送信データも優先度クラスがＵ＿Ｐ３と同じく画像データである。ただし「（ｓａｖｅ）」と表記されている。これは、送信要求があったときに送信できるように、保存しておくという意味である。この送信データは、当然、リアルタイム性の要求は高くない。したがって、優先度クラスは低くなっているのである。

記憶部１０３は、不揮発性の記憶媒体であり、図４に示すテーブルを記憶している。図４に示すテーブルの説明は後述する。

制御部１０４は、ＣＰＵ、ＲＡＭ、ＲＯＭ、Ｉ／Ｏ、およびこれらの構成を接続するバスラインなどを備えたコンピュータである。ＲＯＭには、汎用的なコンピュータを制御部１０４として機能させるためのプログラムが格納されている。なお、上述のプログラムは、非遷移的実体的記録媒体（non- transitory tangible storage medium）に格納されていればよく、その具体的な記憶媒体はＲＯＭに限らない。たとえば、フラッシュメモリに上述のプログラムが保存されていてもよい。ＣＰＵがこのプログラムを実行することは、制御プログラムに対応する方法が実行されることに相当する。

この制御部１０４は、ＣＰＵがＲＯＭに格納されているプログラムを実行することによって、図２に示す各部の機能を提供する。すなわち、制御部１０４は機能ブロックとして、データ分類部１１０、データ価値単価決定部１１１、送信価値単価決定部１１２、送信順序制御部１１３、リソース割り当て部１１４を備える。

なお、制御部１０４が備える機能ブロックの一部または全部は、一つあるいは複数のＩＣ等を用いて（換言すればハードウェアとして）実現してもよい。また、制御部１０４が備える機能ブロックの一部又は全部は、ＣＰＵによるソフトウェアの実行とハードウェア部材の組み合わせによって実現されてもよい。

制御部１０４は、車両２に備えられたデータ供給部６から、車内通信線を介して送信データを取得する。データ供給部６は、たとえば、車両２に搭載された種々のセンサである。センサにはカメラも含まれる。また、制御信号やＣＡＮデータを供給するＥＣＵもデータ供給部６の一例である。

データ分類部１１０は、データ供給部６から取得した送信データを、優先度クラス別に分類して、優先度クラス別に優先度バッファ１０２に格納する。優先度クラスは、送信データのリアルタイム性に関する要求の高さに基づいて決定する。どの種別の送信データが、どの優先度クラスに分類されるかは、予め定められている。

データ価値単価決定部１１１は、優先度バッファ１０２に記憶されている送信データのうち、リアルタイム性がｓｏｆｔ、よって、ベストエフォート型の通信方式で送信する送信データについてのデータ価値単価を決定する。送信データのデータ価値単価は、図４に示すテーブルに定められている。

図４に示すテーブルには、データ種別とデータ価値単価との対応関係が示されている。その他に、サービス名、回線、リアルタイム性、優先度クラス、サービスＱｏＳも含まれている。サービス名、データ種別は、それぞれサービスＩＤ、データＩＤにより表されている。遠隔制御クラウドアプリは、車両２の遠隔制御を実行するアプリケーションを意味する。走行異常検出クラウドアプリは、車両２の走行に何らかの異常が生じたことを、車両外部で検出するアプリケーションを意味し、図３に示す「走行異常検出」は走行異常検出クラウドアプリを簡略化して表記したものである。故障診断クラウドアプリは、車両２が故障したか否かの診断を車両外部で検出するアプリケーションを意味し、図３に示す「故障診断」は故障診断クラウドアプリを簡略化して表示したものである。

送信頻度は、送信データを送信する頻度を示している。リアルタイム性、優先度クラスは図３で説明した内容と同じである。ＱｏＳは、通信の品質要求である。図４の例では、ＱｏＳは具体的には伝送遅延の許容値と伝送容量である。

データ価値単価は、単位データ量に対する価格である。この図４に示すテーブルは、予め設定することができる。また、サーバ３や他の無線通信端末１００から送信されたクエリにより設定されていてもよい。また、データ価値単価は、ユーザが所定の変更操作を行うなどして変更することもできる。

データ価値単価を具体的に見ると、図４の中では、遠隔制御クラウドアプリが要求する画像データの単価が最も高い。次に高いデータ価値単価は、故障診断クラウドアプリが要求するＣＡＮデータである。このＣＡＮデータは、優先度クラスはＵ＿Ｐ７であり、走行異常検出クラウドアプリが要求する画像データの優先度クラスであるＵ＿Ｐ３よりも低い。しかし、データ価値単価は、故障診断クラウドアプリが要求するＣＡＮデータのほうが高くなっている。

本実施形態の送信価値単価決定部１１２は、データ価値単価決定部１１１が決定したデータ価値単価を、そのまま、送信データ価値単価に決定する。この送信データ価値単価は、次に説明する送信順序制御部１１３において送信閾値ＴＨと比較する値であり、送信データを送信する価値があるか否かを判断するための値である。

送信順序制御部１１３は、送信価値単価決定部１１２が決定した送信データ価値単価が予め設定した送信閾値ＴＨ以上である送信データを送信順序付与対象とする。よって、優先度クラスが高い送信データであっても、データ価値単価が送信閾値ＴＨよりも低い送信データには送信順序が付与されない。その結果、優先度クラスが低くても、送信データ価値単価が高い送信データが優先して送信されることになる。

リソース割り当て部１１４は、まず、優先度バッファ１０２に保存されている送信データのうち、帯域確保型および帯域保証型の通信方式で送信する送信データに対して、通信リソースを割り当てる。続いて、ベストエフォート型で送信する送信データに対して通信リソースを割り当てる。ただし、ベストエフォート型で送信する送信データに対しては、送信順序制御部１１３が付与した送信順序が高い送信データから順番に、通信リソースを割り当てる。送信順序が付与された後の通信リソースの割り当て処理は公知の種々の処理が採用できる。また、通信リソースには、周波数帯域およびタイムスロットの少なくとも一方を含む。

［フローチャート］
図５に第１実施形態において制御部１０４が実行する処理をフローチャートで示している。図５に示す処理はデータ分類部１１０が送信データを取得した場合に開始する。ステップ（以下、ステップを省略する）Ｓ１はデータ分類部１１０が実行する処理であり、送信データを、優先度クラス別に優先度バッファ１０２へ挿入する。

Ｓ２は送信順序制御部１１３が実行する処理であり、帯域確保型および帯域保証型で送信する送信データのスケジューリングを行う。スケジューリングの方法は、ＰＱ（Ｐｒｉｏｒｉｔｙ Ｑｕｅｕｉｎｇ）、ＣＢＱ（Ｃｌａｓｓ－Ｂａｓｅｄ Ｑｕｅｕｉｎｇ）、ＷＲＲ（Ｗｅｉｇｈｔｅｄ Ｒｏｕｎｄ－ｒｏｂｉｎ）等、公知の種々のスケジューリング方法を用いることができる。

Ｓ３はリソース割り当て部１１４が実行する処理であり、Ｓ２で決定した送信順序に従って優先度バッファ１０２から送信データを取り出して通信リソースを割り当てる。通信リソースを割り当てられた送信データは、無線通信部１０１から、その通信リソースで送信されることになる。

Ｓ４では、通信リソースが残っているか否かを判断する。Ｓ４はリソース割り当て部１１４が実行する。Ｓ４の判断がＮＯであれば図５に示す処理を終了する。Ｓ４の判断がＹＥＳであればＳ５に進む。

Ｓ５はデータ価値単価決定部１１１が実行する処理であり、優先度バッファ１０２に格納されているベストエフォート型の送信データに対するデータ価値単価を、記憶部１０３に記憶されているテーブルから取得する。

Ｓ６は送信価値単価決定部１１２の処理である。第１実施形態では、Ｓ５で取得したデータ価値単価をそのまま送信データ価値単価とする。

Ｓ７は送信順序制御部１１３が実行する処理であり、Ｓ６で決定した送信データ価値単価に基づいて、優先度バッファ１０２に記憶されているベストエフォートデータの送信順序を決定する。なお、ベストエフォートデータは、ベストエフォート型の送信方式で送信する送信データを意味する。Ｓ７の処理は図６に詳しく示す。

図６において、Ｓ７１ではベストエフォート型の送信データにおいて最大の優先度クラスにある送信データの送信データ価値単価を抽出する。Ｓ７２では、ベストエフォート型の送信データにおいて最大の優先度クラスにある送信データに、送信データ価値単価が送信閾値ＴＨ以上である送信データがあるか否かを判断する。この判断がＹＥＳであればＳ７３に進む。

Ｓ７３では、最大の優先度クラスにある送信データのうち、送信データ価値単価が送信閾値ＴＨ以上である送信データに対して送信順序を付与する。送信順序の決定方法は、Ｓ２と同様、公知の種々のスケジューリング方法を用いることができる。

Ｓ７２の判断がＮＯである場合またはＳ７３を実行した場合はＳ７４に進む。Ｓ７４では、次の優先度クラスにある送信データの送信データ価値単価を抽出する。Ｓ７５では、Ｓ７４で抽出した送信データ価値単価に送信閾値ＴＨ以上の送信データ価値単価があるか否かを判断する。この判断がＹＥＳであればＳ７６に進む。

Ｓ７６では、Ｓ７４で送信データ価値単価を抽出した送信データのうち、送信データ価値単価が送信閾値ＴＨ以上である送信データに対して、Ｓ７３と同様にして送信順序を付与する。Ｓ７５の判断がＮＯである場合またはＳ７６を実行した場合はＳ７７に進む。

Ｓ７７では、優先度バッファ１０２に記憶されている送信データに、さらに下の優先度クラスにある送信データがあるか否かを判断する。この判断がＹＥＳであればＳ７４に戻り、ＮＯであれば図６の処理を終了する。

この図６に示す処理の適用例を図３を用いて説明する。図３には、優先度クラス別に分けられたキューも示されている。各キューは優先度バッファ１０２の一部要素である。優先度クラスがＵ＿Ｐ３のキューには、ｄ３１、ｄ３２の２セットの送信データが入っている。優先度クラスがＵ＿Ｐ７のキューには、ｄ７１、ｄ７２、ｄ７３、ｄ７４の４セットの送信データが入っている。優先度クラスがＵ＿Ｐ９のキューには、ｄ９１の送信データが入っている。これらのうち、ｄ７１、ｄ７２の送信データ価値単価が送信閾値ＴＨを超えており、残りの送信データの送信データ価値単価は送信閾値ＴＨ以上ではないとする。

この場合、優先度クラスがＵ＿Ｐ３であっても、ｄ３１、ｄ３２は送信順序が付与されない一方で、優先度クラスがＵ＿Ｐ７であるｄ７１、ｄ７２には送信順序が付与される。

説明を図５に戻す。Ｓ８はリソース割り当て部１１４が実行する処理であり、Ｓ７で送信順序を付与したベストエフォート型の通信方式で送信する送信データに対して、通信リソースを割り当てる。

［第１実施形態のまとめ］
この第１実施形態では、優先度バッファ１０２に格納されたベストエフォート型で送信する送信データに対しては、送信データの種別により定まる優先度クラスに加えて、データ価値単価を決定し（Ｓ５）、これを送信データ価値単価とする（Ｓ６）。そして、この送信データ価値単価が送信閾値ＴＨ以上の送信データを送信順序付与対象として、優先度クラスに基づいて送信順序を付与する（Ｓ７）。

これにより、優先度クラスが高くても、送信データ価値単価が低い送信データには送信順序が付与されないことになる。その結果、送信する価値が高い送信データを優先して送信することができる。

＜第２実施形態＞
次に、第２実施形態を説明する。この第２実施形態以下の説明において、それまでに使用した符号と同一の番号の符号を有する要素は、特に言及する場合を除き、それ以前の実施形態における同一符号の要素と同一である。また、構成の一部のみを説明している場合、構成の他の部分については先に説明した実施形態を適用できる。
第２実施形態の無線通信端末２００の制御部２０４は、図７に示す送信価値単価決定部２１２の機能が、第１実施形態の送信価値単価決定部１１２の機能と相違する。送信価値単価決定部２１２は、優先度バッファ１０２の同じ優先度クラスに、同じ送信データがある場合、同じ送信データに対するデータ価値単価を加算して送信データ価値単価とする。

ここでの同じ送信データは、データ種別が同じであることを意味する。図８は、図３からベストエフォート部分を抽出した表である。図８においては、Ｕ＿Ｐ７の優先度クラスに、サービスＩＤは異なるが、データ種別が同じである送信データがある。具体的には、図８では、走行異常検出サービスと故障診断サービスが、ともに送信データがＣＡＮデータになっている。

図４に示したように、走行異常検出クラウドアプリのＣＡＮデータのデータ価値単価は０．８円／ＭＢである。また、故障診断クラウドアプリのＣＡＮデータのデータ価値単価は０．６円／ＭＢである。これらは、優先度クラスが同じであり、かつ、データ種別が同じである。よって、第２実施形態では、これら２つのデータ価値単価を加算して送信データ価値単価とする。これにより、優先度クラスがＵ＿Ｐ７のＣＡＮデータの送信データ価値単価は、２．４円／ＭＢになる。

このように送信データ価値単価が、複数のデータ価値単価の加算により算出された場合、加算された複数のデータ価値単価に対応する各送信データは、別々の送信データではなく、１つの送信データとして扱われて送信される。よって、送信データ量を削減することもできる。

この第２実施形態のようにすることで、優先度クラスが低くても、同じ優先度クラスに同じデータ種別の送信データがある場合には、その送信データが送信されやすくなる。なお、送信データ価値単価が複数のデータ価値単価が加算された値である場合に、その送信データ価値単価となった送信データを、上の優先度クラスの送信データよりも優先して送信したい場合、上の優先度クラスに属する送信データのデータ価値単価よりも高い送信閾値ＴＨを設定しておけばよい。

＜第３実施形態＞
第３実施形態の無線通信端末３００は、図９に示す制御部３０４の送信価値単価決定部３１２の機能が、第２実施形態の送信価値単価決定部２１２の機能と相違する。第２実施形態の送信価値単価決定部２１２は、優先度クラスが同じであり、かつ、送信データの種別が同じであれば、データ価値単価を加算していた。

これに対して、第３実施形態の送信価値単価決定部３１２は、個々の送信データを別々に扱い、優先度クラスが同じであり、かつ、送信データの種別が同じであれば、データ価値単価を加算して送信データ価値単価とする。

図１０、図１１を用いて、第３実施形態の送信価値単価決定部３１２の処理を具体的に説明する。図１０は、図４の一部を抽出した表である。図１０に示すように、走行検出クラウドアプリと故障診断クラウドアプリは、ともに、送信データがＣＡＮデータである。ただし、走行検出クラウドアプリは送信頻度が１００ｍｓ周期であるのに対して、故障診断クラウドアプリは送信周期が１ｓである。

図１０の例において送信価値単価決定部３１２が決定する送信データ価値単価を図１１に示す。図１１には、走行異常検出クラウドアプリのＣＡＮデータのデータ価値単価と、故障診断クラウドアプリのＣＡＮデータのデータ価値単価を加算して送信データ価値単価を決定することが示されている。図１１において、送信データ価値単価の色は価値単価の高さを示している。

走行異常検出クラウドアプリと故障診断クラウドアプリは、ともに、送信データの種別がＣＡＮデータであり、優先度クラスはともにＵ＿Ｐ７である。ただし、送信タイミングが重なるのは１秒周期である。そのため、送信データ価値単価は１秒周期で高くなる。このときの送信データ価値単価は、０．８＋１．６＝２．４（円／ＭＢ）である。その他のタイミングでは、故障診断クラウドアプリは送信データを送信しないことから、その他のタイミングでの送信データ価値単価は走行異常検出クラウドアプリにより定まるデータ価値単価と同じ、すなわち、０．８（円／ＭＢ）である。

データ価値単価を加算して送信データ価値単価とすると送信閾値ＴＨを超えやすくなるので、データ価値単価が加算されて決定された送信データ価値単価となった送信データは、優先して送信されやすくなる。このことを図１２、図１３を用いて具体的に説明する。

図１２には、走行異常検出クラウドアプリのＣＡＮデータのデータ価値単価、故障診断クラウドアプリのＣＡＮデータのデータ価値単価を、送信閾値ＴＨと比較して示している。図１２に示すように、ＣＡＮデータのデータ価値単価は、走行異常検出クラウドアプリも故障診断クラウドアプリも、送信閾値ＴＨを超えていない。そのため、この送信閾値ＴＨとの比較では、ＣＡＮデータに送信順序が付与されない。

これに対して、図１３に示すように、送信データ価値単価は、データ価値単価が加算された部分が送信閾値ＴＨを超える。したがって、データ価値単価が加算されて決定された送信データ価値単価となった送信データには送信順序が付与されて送信されることになる。

＜第４実施形態＞
図１４は、第４実施形態における無線通信端末４００の構成を示すブロック図である。無線通信端末４００の制御部４０４は、包含関係判断部４１５と判定用価値単価算出部４１６を備える。また、送信価値単価決定部４１２の処理が、これまでの実施形態と相違する。

包含関係判断部４１５は、優先度バッファ１０２の同じ優先度クラスに同じ種別の送信データのセットが２セットある場合、それら２セットの送信データのセットに積集合が存在しているか否かを判断する。さらに、積集合がある場合、その積集合が部分集合であるか、包含関係のない集合であるかを判断する。

具体例で説明する。たとえば、第３実施形態では、ある送信タイミングにおけるＣＡＮデータに複数のデータがあるか否かは考慮せずに、ある送信タイミングにおけるＣＡＮデータを１つのデータとしていた。これに対して、第４実施形態では、ある送信タイミングにおけるＣＡＮデータに複数のデータが含まれている場合に、ＣＡＮデータに含まれている複数のデータを別々に扱う。以下、説明の便宜上、これら複数のデータをＣＡＮ＿ＩＤで区別する。

走行異常検出クラウドアプリが必要とするＣＡＮデータがＣＡＮ＿ＩＤ＝１、２、３、４であるとする。一方、故障診断クラウドアプリが必要とするＣＡＮデータがＣＡＮ＿ＩＤ＝１、２、３、４、・・・１９、２０であるとする。この具体例では、積集合は｛ＣＡＮ＿ＩＤ：１、２、３、４｝になる。

これらはともにＣＡＮデータであることから、同じ種別の送信データのセットに該当する。また、これらＣＡＮデータは、ともに優先度クラスがＵ＿Ｐ７、つまり、同じ優先度クラスの送信データである。したがって、走行異常検出クラウドアプリが必要とするＣＡＮデータと故障診断クラウドアプリが必要とするＣＡＮデータに積集合があるか否かを判断する。

図１５には、この具体例をベン図で示している。図１５に示すように、この具体例の場合、走行異常検出クラウドアプリが必要とするＣＡＮデータは、故障診断クラウドアプリが必要とするＣＡＮデータの部分集合になる。なお、以下での説明の便宜上、走行異常検出クラウドアプリのＣＡＮデータの集合を集合Ａ、故障診断クラウドアプリのＣＡＮデータの集合を集合Ｂとしている。

部分集合は積集合の一態様であることから、走行異常検出クラウドアプリが必要とするＣＡＮデータと、故障診断クラウドアプリが必要とするＣＡＮデータに積集合が存在していることになる。

判定用価値単価算出部４１６は、包含関係判断部４１５が、部分集合があると判断した場合に、判定用価値単価Ｖ_ｊを算出する。この判定用価値単価Ｖ_ｊは、積集合を共有する２つの送信データを分割するか否かを判定するために用いる値である。

判定用価値単価Ｖ_ｊは式１で表される。式１において、Ｎ_ａ、Ｎ_ｂは、第１送信データのデータ数と第２送信データのデータ数である。第１送信データと第２送信データは、積集合を共有する２つの送信データである。上記具体例では、第１送信データは走行異常検出クラウドアプリのＣＡＮデータすなわち集合Ａであり、第２送信データは故障診断クラウドアプリのＣＡＮデータすなわち集合Ｂである。また、Ｖ_ａは第１送信データのデータ価値単価であり、Ｖ_ｂは第２送信データのデータ価値単価である。

式１において、分子の第１項は、部分集合である集合Ａに対するデータ価値であり、集合Ａのデータ価値単価Ｖ_ａと集合Ａのデータ数Ｎ_ａの積である。分子の第２項は、部分集合に対する上位集合である集合Ｂに対するデータ価値であり、集合Ｂのデータ価値単価Ｖ_ｂと集合Ｂのデータ数Ｎ_ｂの積である。よって、式１は、部分集合のデータ価値と上位集合のデータ価値の和を上位集合のデータ数で割ることを意味する。

送信価値単価決定部４１２は、図１６に示す条件式が成立するか否かを判断する。すなわち、部分集合があると判断した場合には、条件式ｆ１、ｆ２が成立するか否かを判断する。

条件式ｆ１は、部分集合である集合Ａのデータ価値単価Ｖ_ａが判定用価値単価Ｖ_ｊ以下であるか否かを判断する式である。条件式ｆ１がＴＲＵＥであれば、集合Ａと集合Ｂの和集合の送信データ価値単価Ｖ_{ｔ（Ａ＋Ｂ）}は、図１６にも示すように、Ｖ_ｂ＋（Ｎ_ａ／Ｎ_ｂ）×Ｖ_ａにより算出する。また、この場合、集合Ａと集合Ｂの和集合を全体として１つの送信データとする。

一方、条件式ｆ１がＦＡＬＳＥであれば、集合Ａと集合Ｂの両方の属する送信データと、集合Ｂのみに属する送信データの２つに送信データを分けて、送信データ価値単価を決定する。集合Ａと集合Ｂの両方の属する送信データの送信データ価値単価は集合Ａのデータ価値単価Ｖ_ａと集合Ｂのデータ価値単価Ｖ_ｂの和とする。集合Ｂのうち、集合Ａには属さない送信データの送信データ価値単価は、集合Ｂのデータ価値単価Ｖ_ｂとする。

条件式ｆ２は、部分集合である集合Ｂのデータ価値単価Ｖ_ｂが判定用価値単価Ｖ_ｊ以下であるか否かを判断する式である。条件式ｆ２がＴＲＵＥであれば、集合Ａと集合Ｂの和集合の送信データ価値単価Ｖ_{ｔ（Ａ＋Ｂ）}は、図１６にも示すように、Ｖ_ａ＋（Ｎ_ｂ／Ｎ_ａ）×Ｖ_ｂにより算出する。また、この場合、集合Ａと集合Ｂの和集合を全体として１つの送信データとする。

条件式ｆ２がＦＡＬＳＥであれば、集合Ａと集合Ｂの両方の属する送信データと、集合Ｂのみに属する送信データの２つに送信データを分けて、送信データ価値単価を決定する。集合Ａと集合Ｂの両方の属する送信データの送信データ価値単価は集合Ａのデータ価値単価Ｖ_ａと集合Ｂのデータ価値単価Ｖ_ｂの和とする。集合Ａのうち、集合Ｂには属さない送信データの送信データ価値単価は、集合Ａのデータ価値単価Ｖ_ａとする。

包含関係判断部４１５において包含関係がないと判断された場合には、送信価値単価決定部４１２は、集合Ａのデータ価値単価Ｖ_ａが集合Ｂのデータ価値単価Ｖ_ｂ以下であるという条件式ｆ３が成立するか否かを判断する。

この条件式ｆ３がＴＲＵＥであれば、集合Ｂの送信データと、集合Ａのうち集合Ｂには属さない送信データに分けて、送信データ価値単価Ｖ_ｔを決定する。集合Ｂの送信データ価値単価Ｖ_ｔＢは、図１６にも示すように、Ｖ_ｂ＋（Ｎ_ａ／Ｎ_ｂ）×Ｖ_ａにより算出する。集合Ａのうち集合Ｂには属さない送信データの送信データ価値単価Ｖ_{ｔ（Ａ－Ｂ）}は、集合Ａのデータ価値単価Ｖ_ａとする。

条件式ｆ３がＦＡＬＳＥである場合には、集合Ａの送信データと、集合Ｂのうち集合Ａには属さない送信データに分けて、送信データ価値単価Ｖ_ｔを決定する。集合Ａの送信データ価値単価Ｖ_ｔＡは、図１６にも示すように、Ｖ_ａ＋（Ｎ_ｂ／Ｎ_ａ）×Ｖ_ｂにより算出する。集合Ａのうち集合Ｂには属さない送信データの送信データ価値単価Ｖ_{ｔ（Ｂ－Ａ）}は、集合Ｂのデータ価値単価Ｖ_ｂとする。

図１７を用いて、送信価値単価決定部４１２が決定する送信データ価値単価の具体例を説明する。図１７には、走行異常検出アプリのＣＡＮデータのデータ価値単価と、故障診断クラウドアプリのＣＡＮデータのデータ価値単価を加算して送信データ価値単価を決定することが示されている。

図１７において、個々の四角が送信データのセット、すなわち、集合Ａ、あるいは、集合Ｂを示している。また、四角の色の濃さがデータ価値単価の高さを示しており、四角の縦方向長さはデータ量を示している。

図１７の例では、データ価値単価が加算されて決定された送信データ価値単価は、１．６＋（４／２０）×０．８＝１．７６（円／ＭＢ）になる。この送信データ価値単価が送信閾値ＴＨと比較されて送信順序を付与するか否かが決定される。

故障診断クラウドアプリがＣＡＮデータを要求していないタイミングに対しては、故障診断クラウドアプリのためのＣＡＮデータは優先度バッファには格納されない。よって、このときの送信データ価値単価は、走行異常検出クラウドアプリのＣＡＮデータのデータ価値単価、すなわち、０．８（円／ＭＢ）になる。

この図１７には示していないが、図１６において送信データ価値単価を２種類算出している場合、それら２種類の送信データ価値単価に対応する集合に送信データを分割して、分割後の送信データを１つの送信単位として送信順序を付与する。

＜第５実施形態＞
図１８は、第５実施形態における無線通信端末５００の構成を示すブロック図である。無線通信端末５００の制御部５０４は、導出関係判断部５１５と判定用価値単価算出部５１６を備える。また、送信価値単価決定部５１２の処理が、これまでの実施形態と相違する。

導出関係判断部５１５は、優先度バッファ１０２の同じ優先度クラスに同じ種別の送信データのセットが２セットあるとき、それら２セットの送信データに導出関係があるか否かを判断する。

導出関係は、それら２セットの送信データのセットの一方を第１送信データ、他方を第２送信データとしたとき、第１送信データが導出元データとなり、第１送信データを抽象化して、導出先データである第２送信データが導出できる関係である。

具体例で説明する。図１９には、導出関係を例示している。ＢＭＰ、ＪＰＥＧ、ＪＰＥＧ２０００は画像形式である。ＪＰＥＧおよびＪＰＥＧ２０００の画像データは、ＢＭＰから生成することができるので、ＢＭＰデータは導出元データすなわち第１送信データとなり、第２送信データとしてＪＰＥＧ、ＪＰＥＧ２０００を導出できる関係にある。

また、歩行者が写っているＢＭＰ画像データを解析すれば、画像に写っている歩行者を検出できる。同様に、歩行者や前方車両が写っているＪＰＥＧ画像データを解析すれば、画像に写っている歩行者および前方車両を検出できる。つまり、画像データと画像解析により検出できる物体との関係も導出関係である。この場合、第１送信データは画像データであり、第２送信データは画像解析により検出できる物体名である。また、全体の画像データを第１送信データとし、物体が写っている部分の画像データを第２送信データとすることもできる。

どのような種別の送信データを導出元データとして、どのような導出先データが導出できるかは、記憶部１０３などの不揮発性の記憶媒体に予め記憶されている。

図１９に示すように、導出元データから導出先データを導出することは、データの抽象化を意味する。よって、導出関係は抽象化の関係とも言える。

この抽象化の程度を抽象化度αとする。たとえば、ＪＰＥＧデータの圧縮率を２０％とすると、抽象度化度αは０．２である。なお、圧縮率は、圧縮前のデータサイズに対する、圧縮後のデータサイズの比である。

判定用価値単価算出部５１６は、導出関係判断部５１５が、導出関係があると判断した場合に、判定用価値単価Ｖ_ｊを算出する。この判定用価値単価Ｖ_ｊは、式２から算出する。
（式２） Ｖ_ｊ＝Ｖ_ａ＋αＶ_ｂ
式２は、実質的には第４実施形態で説明した式１と同じである。本実施形態において、式１の分母を考えると、導出元の送信データのサイズと導出先の送信データのサイズを比較することになる。抽象化度αの最大値を１と考えると、導出元の送信データのサイズは１と考えることができる。よって、本実施形態において、式１の分母を考えると１になる。

また、同様に、Ｎ_ａも１になる。そして、Ｎ_ｂはαと考えることができる。よって、式２が得られる。以上より、式２は、実質的には式１と同じである。

送信価値単価決定部５１２は、式３に示す条件式が成立するか否かを判断する。式３の条件式は、条件式ｆ２と同じである。式３は導出先の送信データである集合Ｂのデータ価値単価Ｖ_ｂが判定用価値単価Ｖ_ｊ以下であるか否かを判断する式である。
（式３） Ｖ_ｂ≦Ｖ_ｊ
式３に式２を代入して変形すると、式４が得られる。
（式４） Ｖ_ａ≧（１―α）Ｖ_ｂ
式４の条件式がＴＲＵＥであれば、集合Ａと集合Ｂの和集合の送信データ価値単価Ｖ_{ｔ（Ａ＋Ｂ）}は、Ｖ_ａ＋αＶ_ｂにより算出する。「Ｖ_ａ＋αＶ_ｂ」は、条件式ｆ２がＴＲＵＥのときに用いるデータ価値単価の算出式において、Ｎ_ｂ＝α、Ｎ_ａ＝１とした式である。本実施形態において、集合Ａと集合Ｂの和集合は、導出元の送信データを意味する。

式４の条件式がＦＡＬＳＥであれば、集合Ａと集合Ｂの両方に属する送信データと、集合Ｂのみに属する送信データの２つに送信データを分けて、送信データ価値単価を決定する。

これらの送信データ価値単価は、図１６において条件式ｆ２がＦＡＬＳＥになったときと同じであり、集合Ａと集合Ｂの両方に属する送信データの送信データ価値単価は集合Ａのデータ価値単価Ｖ_ａと集合Ｂのデータ価値単価Ｖ_ｂの和とする。そして、この値を、導出元の送信データの送信データ価値単価とする。一方、集合Ａのうち、集合Ｂには属さない送信データの送信データ価値単価は、集合Ａのデータ価値単価Ｖ_ａとする。そして、この値を、導出先の送信データの送信データ価値単価とする。

図２０には、データ価値単価を加算して送信データ価値単価を決定する具体例を示している。図２０には、２つのサービスが示されている。一つのサービスは、サービス名が定点監視であり、画像フォーマットはＢＭＰ、要求周期（すなわちデータ送信周期）は０．００３３秒、撮像場所が特定の交差点、データ価値単価が１．８円／ＭＢである。こちらが第１送信データになる。

もう一つのサービスは、サービス名が走行異常検出であり、画像フォーマットはＪＰＥＧ、要求周期は０．００３３秒、データ価値単価が０．４円／ＭＢである。こちらが第２送信データになる。

この例において式４の条件式が成立する。よって、２つの送信データを分割せずに、１セットの送信データとして送信データ価値単価を決定する。図２０の例では、走行異常検出サービスは、継続的に送信データを必要としている。これに対して、定点監視サービスは、要求周期は走行異常検出サービスと同じであるが、送信データを必要とするタイミングは、走行異常検出サービスが送信データを必要とするタイミングの一部である。

ＢＭＰデータの送信タイミングでは、ＢＭＰデータのみが送信される。ＢＭＰデータが送信されればＪＰＥＧデータは導出できるからである。ＪＰＥＧデータが送信されないことで、送信データ量を少なくすることができる。

またＢＭＰデータの送信データ価値単価は式２により算出される。具体的には、１．８＋０．２×０．４＝１．８８になる。ＪＰＥＧデータとしての価値も備えるので、送信データ価値単価はＢＭＰデータのデータ価値単価よりも高くなる。送信データ価値単価が高くなるので優先的に送信される。

＜第６実施形態＞
これまで説明してきた実施形態では、データ価値単価は固定値であった。この第６実施形態では、データ価値単価を、装置状態を検索キーとして検索する。図２１に第６実施形態の無線通信端末６００の構成を示す。

第６実施形態の無線通信端末６００の制御部６０４は、装置状態取得部６１７を備え、また、データ価値単価決定部６１１の処理がこれまでの実施形態と相違する。

装置状態取得部６１７は、無線通信端末６００が搭載されている移動装置、すなわち車両２の予め定めた種類の装置状態を取得する。装置状態には、たとえば、車両２の現在位置、現在時刻、車両の動作状態がある。また、車両２の動作状態は、たとえば、走行中か否か、充電中か否か、ワイパ動作中か否か、などがある。これら装置状態は、ＣＡＮなどを介して取得する。

データ価値単価決定部６１１は、優先度バッファ１０２に記憶されている送信データのデータ価値単価を決定する点は、これまでの実施形態のデータ価値単価決定部１１１と同じである。ただし、本実施形態のデータ価値単価決定部６１１は、装置状態取得部６１７が取得した装置状態、および、データ価値マップから、優先度バッファ１０２に記憶されている送信データのデータ価値単価を取得する。データ価値マップは記憶部１０３に記憶されている。

図２２には、データ価値マップの一例を示している。図２２に示すデータ価値マップは、サブノートＩＤである位置別に、故障診断サービスについてのＣＡＮデータのデータ価値単価、走行異常検出サービスについてのＣＡＮデータと画像データのデータ価値単価が定まるマップである。ここでの位置は現在位置を意味する。現在位置は装置状態の一例であり、ＣＡＮデータ、画像データは送信データの種別である。よって、このデータ価値マップは、装置状態と送信データの種別からデータ価値単価が定まる関係の一例である。

データ価値単価決定部６１１は、このデータ価値マップから、装置状態取得部６１７が取得した現在位置に対応するデータ価値単価を検索して、データ価値単価を決定する。

なお、図２２では、装置状態として、現在位置が示されているが、現在時刻、走行中か否かなど、現在位置以外の他の装置状態と送信データの種別からデータ価値単価が定まる関係でもよい。また、データ価値マップは、現在位置とワイパ動作中か否かなど、複数の装置状態と送信データの種別からデータ価値単価が定まる関係でもよい。

このデータ価値マップを用いてデータ価値単価を決定することで、データ価値単価を動的に変化させることができる。たとえば、走行異常検出サービスにおいて、交通流が少なくデータ不足の場所や時間、規制が生じやすい場所のデータ価値単価を高くするなどの変更が可能になる。これにより、送信する価値がより高い送信データを優先して送信することができる。

＜第７実施形態＞
前述した第６実施形態では装置状態を検索キーとしてデータ価値単価を検索した。それに対して第７実施形態では、メタデータを検索キーとしてデータ価値単価を検索する。図２３に第７実施形態の無線通信端末７００の構成を示す。

第７実施形態の無線通信端末７００の制御部７０４は、はメタデータ取得部７１７を備え、また、データ価値単価決定部７１１の処理が、これまでの実施形態とは相違する。

メタデータ取得部７１７は、送信データのメタデータを取得する。メタデータは送信データに付随するデータである。たとえば、送信データが画像データであれば画質、誤り率などがメタデータである。送信データが、センサから得たデータであれば、計測位置、計測時間がメタデータの例である。メタデータは、ＣＡＮなどを介して取得する。取得したメタデータは、送信データに対応付けて優先度バッファ１０２に記憶される。

データ価値単価決定部７１１は、送信データに対応付けて優先度バッファ１０２に保存されているメタデータ、および、データ価値マップから、優先度バッファ１０２に記憶されている送信データのデータ価値単価を取得する。データ価値マップは記憶部１０３に記憶されている。

第７実施形態におけるデータ価値マップは、図２２で説明したデータ価値マップにおいて装置状態の列に代えてメタデータの列があるマップである。

このデータ価値マップを用いてデータ価値単価を決定することで、データ価値単価を動的に変化させることができる。本実施形態でも、たとえば、走行異常検出サービスにおいて、交通流が少なくデータ不足の場所や時間に計測されたセンサデータのデータ価値単価を高くするなどの変更が可能になる。よって、本実施形態でも、送信する価値がより高い送信データを優先して送信することができる。

＜第８実施形態＞
第８実施形態では、データ価値単価を乱数で決定する。図２４に第８実施形態の無線通信端末８００の構成を示す。第８実施形態の無線通信端末８００の制御部８０４は、データ価値単価決定部８１１の処理が、これまでの実施形態とは相違する。

データ価値単価決定部８１１は、データ価値単価を乱数により決定する。たとえば、図５に示す処理において、あるデータ種別に対して電源オン後に最初に実行するＳ５では、データ価値単価の初期値として、乱数で生成した値を用いる。

データ価値単価を乱数により決定することは、ある狭い地域に多数の無線通信端末１００が存在する場合に有効である。同じサービスの同じデータ種別の送信データに対するデータ価値単価が固定値であると、どの無線通信端末１００も送信データを送信しない状況や、反対に、どの無線通信端末１００も送信データを送信する状況が生じやすい。

しかし、たとえば、道路異常が検出された場所の画像データは、通信品質の要求は高いが、どれか１台の車両２に搭載された無線通信端末１００がその画像データを送信すればよい。

このような場合に、データ価値単価を乱数で決定することが有効である。したがって、車両２の周囲の予め設定された範囲内に、他の無線通信端末１００が規定数以上存在すると判断できた場合に、データ価値単価を乱数で決定するようにしてもよい。また、データ種別を画像に限定するなど、データ種別を限定して、データ価値単価を乱数で決定してもよい。

データ価値単価を乱数で決定する場合、その乱数は確率分布に従う乱数とすることができる。確率分布は、たとえば、平均が第１実施形態で説明した固定値となる正規分布とすることができる。平均が第１実施形態で説明した固定値となるようにすれば、全車両２の合計データ価値単価は変えずに、いずれかの無線通信端末１００から送信データが送信される可能性を高くすることができる。

なお、確率分布の平均を第１実施形態で説明した固定値とすると、固定値を用いた場合よりも、実際に送信される送信データのデータ価値単価の平均は高くなる。そこで、確率分布の平均を、第１実施形態で説明した固定値よりも低くしてもよい。また、分散値を大きくしたり、上限値を設けたりしてもよい。

＜第９実施形態＞
図２５に第９実施形態の無線通信端末９００の構成を示す。第９実施形態の無線通信端末９００の制御部９０４は、送信価値単価決定部９１２、送信順序制御部９１３、リソース割り当て部９１４の処理が、これまでの実施形態とは相違する。

前述の実施形態では、ある送信データに対して送信データ価値単価は一度のみ決定していた。しかし、送信データ価値単価を決定してから実際に送信データが送信されるまでに、ある程度の時間がある場合もある。そして、送信データ価値単価を決定してから実際に送信データが送信されるまでに、データ価値単価の加算が可能な送信データが優先度バッファ１０２に格納される可能性がある。

また、送信データ価値単価を決定してから実際に送信データが送信されるまでに、優先度バッファ１０２に格納されていた送信データが、送信不要になる可能性もある。送信不要になる状況は、データ供給部６などから、送信データの削除要求が供給される場合などに生じる。

また、データ価値マップが、ユーザや、サービスを実行するアプリケーションからの指示により変更されることも考えられる。

さらには、ベストエフォート型の送信データは、前述したようにリアルタイム性がｓｏｆｔであり、送信までの時間経過によりデータ価値が低下する。そこで、時間経過に応じて送信データ価値単価を減少させることも考えられる。なお、時間経過に伴う送信データ価値の減少量あるいは減少関数は、サービス毎に定義することができる。

これらのことを考慮して、送信価値単価決定部９１２は、送信データ価値単価を決定した後も、送信データが送信されるまで送信データ価値単価を逐次再決定する。

また、送信価値単価決定部９１２は、第２実施形態の送信価値単価決定部２１２と同様、優先度バッファ１０２の同じ優先度クラスに、同じ送信データがある場合、同じ送信データに対するデータ価値単価を加算して送信データ価値単価とする。

さらに、送信価値単価決定部９１２は、送信データ価値単価の算出に用いたデータ価値単価に対応する送信データの削除要求を、送信データを提供したデータ供給部６から取得した場合には、削除要求のあった送信データのデータ価値単価を減算して、送信データ価値単価を再決定する。

送信データ価値単価が変更された場合、送信順序制御部９１３は、送信順序を再付与する。リソース割り当て部９１４は、送信順序が変更になった場合には通信リソースを再度割り当てる。

＜第１０実施形態＞
図２６に第１０実施形態の無線通信端末１０００の構成を示す。第１０実施形態の無線通信端末１０００の制御部１００４は、送信順序制御部１０１３の処理が、これまでの実施形態とは相違する。

送信順序制御部１０１３は、図２７に示すように、送信閾値ＴＨ１、送信閾値ＴＨ２の２つの送信閾値ＴＨを備える。また、ＴＨ１＞ＴＨ２である。送信データは、送信閾値ＴＨ１、ＴＨ２との大小関係を色の濃さで表している。送信データｄ３１、ｄ７１、ｄ７２の送信データ価値単価は送信閾値ＴＨ１よりも高い。送信データｄ３２、ｄ７３、ｄ７４、ｄ９１の送信データ価値単価は送信閾値Ｔ２よりも高いが、送信閾値ＴＨ１よりは低い。

送信順序制御部１０１３は、２つの送信閾値ＴＨを値が大きい送信閾値ＴＨから順番に用いて送信順序を付与する。

図２７の例では、送信閾値ＴＨ１を先に用いる。送信閾値ＴＨ１よりも値が大きい送信データ価値単価は送信データｄ３１、ｄ７１、ｄ７２である。この３つの送信データｄ３１、ｄ７１、ｄ７２のうち、送信データｄ３１の優先度クラスが高い。したがって、送信データｄ３１に、最初に送信順序が付与される。図２７においてＴｎ（ｎ＝１、２，３・・・）は、送信順序を表している。

送信順序が２番目になる送信データは送信データｄ７１であり、３番目になる送信データは送信データｄ７２である。４番目以降の送信順序となる送信データは、送信閾値ＴＨ１よりも送信データ価値単価が低い送信データになる。具体的には、ｄ３２→ｄ７３→ｄ７４→ｄ９１の順に送信順序が付与される。

このように２つの送信閾値ＴＨを設けることで、送信データ価値単価が高い送信データの送信順序を早くしやすくなる。なお、送信閾値ＴＨを３つ以上、設けてもよい。

以上、本発明の実施形態を説明したが、本発明は上述の実施形態に限定されるものではなく、次の変形例も本発明の技術的範囲に含まれ、さらに、下記以外にも要旨を逸脱しない範囲内で種々変更して実施できる。

＜変形例１＞
送信データを分割する場合はそれぞれの送信データに対してヘッダを付与する必要がある。そのため、分割しない場合に比べると通信容量は増加する。そこで、差集合の要素が少ない場合は分割しないとする判断を行ってもよい。

＜変形例２＞
前述の実施形態では、上り送信について説明したが、下り送信にも本発明は同様に適用できる。

２：車両（移動装置） ３：サーバ ４：基地局 ５：通信回線網 ６：データ供給部 １００、２００、３００、４００、５００、６００、７００、８００、９００、１０００：無線通信端末 １０１：無線通信部 １０２：優先度バッファ １０３：記憶部 １１０：データ分類部 １１１、６１１、７１１、８１１：データ価値単価決定部 １１２、２１２、３１２、４１２、５１２、９１２：送信価値単価決定部 １１３、９１３、１０１３：送信順序制御部 １１４、９１４：リソース割り当て部 ４１５：包含関係判断部 ４１６、５１６：判定用価値単価算出部 ５１５：導出関係判断部 ６１７：装置状態取得部 ７１７：メタデータ取得部 抽象化度：α

Claims (11)

1. 送信データをデータ供給部から取得し、取得した前記送信データを前記送信データの種別により定まる通信品質要求に基づいて優先度クラス別に分類して、優先度クラス別に優先度バッファに記憶するデータ分類部（１１０）と、
   前記優先度バッファに記憶されている前記送信データのデータ価値単価を決定するデータ価値単価決定部（１１１、６１１、７１１、８１１）と、
   前記データ価値単価決定部が決定した前記データ価値単価に基づいて送信データ価値単価を決定する送信価値単価決定部（１１２、２１２、３１２、４１２、５１２、９１２）と、
   前記送信価値単価決定部が決定した前記送信データ価値単価が予め設定した送信閾値以上である前記送信データを送信順序付与対象として、前記データ分類部が分類した前記優先度クラスに基づいて、送信順序を付与する送信順序制御部（１１３、９１３、１０１３）と、
   前記送信順序制御部が決定した前記送信順序に基づいて、前記送信データに通信リソースを割り当てるリソース割り当て部（１１４、９１４）と、
   前記リソース割り当て部が割り当てた通信リソースで前記送信データを送信する送信部（１０１）とを備える無線通信端末。
2. 請求項１において、
   前記送信価値単価決定部（２１２、３１２、９１２）は、前記優先度バッファの同じ前記優先度クラスに同じデータ種別の前記送信データがある場合、同じデータ種別の前記送信データに対する前記データ価値単価を加算して前記送信データ価値単価とする無線通信端末。
3. 請求項２において、
   前記送信価値単価決定部（９１２）は、前記送信データ価値単価が複数の前記データ価値単価を加算して決定した値であり、かつ、前記送信データ価値単価の算出に用いた前記データ価値単価に対応する前記送信データの削除要求を前記データ供給部から取得した場合には、前記送信データ価値単価から、削除要求のあった前記送信データの前記データ価値単価を減算して、前記送信データ価値単価を再決定する無線通信端末。
4. 請求項２または３において、
   同じ前記優先度バッファに同じ種別の前記送信データのセットが２セットあり、かつ、それら２セットの前記送信データのセットに積集合が存在している場合に、前記積集合が部分集合であるか、包含関係のない集合であるかを判断する包含関係判断部（４１５）と、
   前記包含関係判断部が、前記積集合が前記部分集合であると判断した場合に、前記部分集合に対するデータ価値を、前記部分集合である前記送信データの前記データ価値単価（Ｖ_ａ）および前記部分集合のデータ数（Ｎ_ａ）から算出し、前記部分集合に対する上位集合のデータ価値を、前記上位集合である前記送信データの前記データ価値単価（Ｖ_ｂ）および前記上位集合のデータ数（Ｎ_ｂ）から算出し、さらに、前記部分集合に対するデータ価値と前記上位集合に対するデータ価値の和を前記上位集合のデータ数で割ることで判定用価値単価（Ｖ_ｊ）を算出する判定用価値単価算出部（４１６）とを備え、
   前記送信価値単価決定部（４１２）は、前記判定用価値単価（Ｖ_ｊ）が前記部分集合である前記送信データの前記データ価値単価（Ｖ_ａ）よりも低い場合には、前記部分集合のデータ数（Ｎ_ａ）を前記上位集合のデータ数（Ｎ_ｂ）で割った値を前記部分集合の前記送信データの前記データ価値単価（Ｖ_ａ）に乗じた値と、前記上位集合の前記送信データの前記データ価値単価（Ｖ_ｂ）との和を、前記送信データ価値単価とする無線通信端末。
5. 請求項４において、
   前記送信価値単価決定部（４１２）は、
   前記包含関係判断部が、前記積集合が部分集合でないと判断した場合に、２セットの前記送信データのうち、前記送信データ価値単価が高い側を第１送信データ、他方を第２送信データとしたとき、
   前記第１送信データの前記送信データ価値単価（Ｖ_ｔＡ）を、前記第２送信データのデータ数（Ｎ_ｂ）を前記第１送信データのデータ数（Ｎ_ａ）で割った値（Ｎ_ｂ／Ｎ_ａ）に前記第２送信データの前記データ価値単価（Ｖ_ｂ）を乗じた値と、前記第１送信データの前記データ価値単価（Ｖ_ａ）の和とし、
   前記第２送信データのうち、前記第１送信データに含まれないデータの前記送信データ価値単価（Ｖ_{ｔ（Ｂ－Ａ}）を、前記第２送信データの前記データ価値単価（Ｖ_ｂ）とする無線通信端末。
6. 請求項２または３において、
   同じ前記優先度バッファに同じ種別の前記送信データのセットが２セットあり、かつ、それら２セットの前記送信データのセットの一方を第１送信データ、他方を第２送信データとしたとき、前記第１送信データが導出元データとなり、前記第１送信データを抽象化して前記第２送信データが導出できる導出関係があるか否かを判断する導出関係判断部（５１５）と、
   前記導出関係判断部が前記導出関係があると判断した場合に、前記第１送信データに対する前記データ価値単価（Ｖ_ａ）と、前記第１送信データに対する前記第２送信データの抽象化度（α）に前記第２送信データの前記データ価値単価（Ｖ_ｂ）を乗じた値との和を判定用価値単価（Ｖ_ｊ）として算出する判定用価値単価算出部（５１６）とを備え、
   前記送信価値単価決定部（５１２）は、前記判定用価値単価（Ｖ_ｊ）が前記第２送信データのデータ価値単価（Ｖ_ｂ）以上であれば、前記判定用価値単価（Ｖ_ｊ）を前記第１送信データの前記送信データ価値単価とする無線通信端末。
7. 請求項１～６のいずれか１項において、
   前記無線通信端末は移動装置（２）に搭載されており、
   前記無線通信端末は、
   前記移動装置の予め定めた種類の状態である装置状態を取得する装置状態取得部（６１７）を備え、
   前記データ価値単価決定部（６１１）は、前記装置状態取得部が取得した前記装置状態、および、前記装置状態と前記送信データの種別から前記データ価値単価が定まる関係に基づいて、前記優先度バッファに記憶されている前記送信データの前記データ価値単価を決定する無線通信端末。
8. 請求項１～６のいずれか１項において、
   前記優先度バッファに記憶されている前記送信データのメタデータを取得するメタデータ取得部（７１７）を備え、
   前記データ価値単価決定部（７１１）は、前記メタデータ取得部が取得した前記メタデータ、および、前記メタデータと前記送信データの種別から前記データ価値単価が定まる関係に基づいて、前記優先度バッファに記憶されている前記送信データの前記データ価値単価を決定する無線通信端末。
9. 請求項１～６のいずれか１項において、
   前記データ価値単価決定部（８１１）は、前記送信データのデータ価値単価を乱数で決定する無線通信端末。
10. 請求項１～９のいずれか１項において、
    前記送信価値単価決定部（９１２）は、前記送信データ価値単価を決定した後も、前記送信データが送信されるまで前記送信データ価値単価を逐次再決定し、
    前記送信順序制御部（９１３）は、前記送信データ価値単価が変更になった場合には前記送信順序を再付与し、
    前記リソース割り当て部（９１４）は、前記送信順序が変更になった場合には前記通信リソースを再度割り当てる無線通信端末。
11. 請求項１～１０のいずれか１項において、
    前記送信順序制御部（１０１３）は、前記送信閾値として、互いに大きさが異なる複数の前記送信閾値を設定しており、複数の前記送信閾値のうち、値が大きい前記送信閾値から順に用いて前記送信順序付与対象を決定する無線通信端末。

Images