(57)【要約】【課題】送信する価値が高い送信データを優先して送信することができる無線通信端末を提供する。【解決手段】送信データをデータ供給部６から取得し、取得した送信データを送信データの種別により定まる通信品質要求に基づいて優先度クラス別に分類して優先度バッファ１０２に記憶するデータ分類部１１０と、優先度バッファ１０２に記憶されている送信データのデータ価値単価を決定するデータ価値単価決定部１１１と、データ価値単価に基づいて送信データ価値単価を決定する送信価値単価決定部１１２と、送信データ価値単価が予め設定した送信閾値以上である送信データを送信順序付与対象として、優先度クラスに基づいて送信順序を付与する送信順序制御部１１３と、送信順序に基づいて、送信データに通信リソースを割り当てるリソース割り当て部１１４と、リソース割り当て部１１４が割り当てた通信リソースで送信データを送信する送信部１０１とを備える。【選択図】図２
2018182430.tif 000002
【特許請求の範囲】
【請求項１】
送信データをデータ供給部から取得し、取得した前記送信データを前記送信データの種別により定まる通信品質要求に基づいて優先度クラス別に分類して、優先度クラス別に優先度バッファに記憶するデータ分類部（１１０）と、
前記優先度バッファに記憶されている前記送信データのデータ価値単価を決定するデータ価値単価決定部（１１１、６１１、７１１、８１１）と、
前記データ価値単価決定部が決定した前記データ価値単価に基づいて送信データ価値単価を決定する送信価値単価決定部（１１２、２１２、３１２、４１２、５１２、９１２）と、
前記送信価値単価決定部が決定した前記送信データ価値単価が予め設定した送信閾値以上である前記送信データを送信順序付与対象として、前記データ分類部が分類した前記優先度クラスに基づいて、送信順序を付与する送信順序制御部（１１３、９１３、１０１３）と、
前記送信順序制御部が決定した前記送信順序に基づいて、前記送信データに通信リソースを割り当てるリソース割り当て部（１１４、９１４）と、
前記リソース割り当て部が割り当てた通信リソースで前記送信データを送信する送信部（１０１）とを備える無線通信端末。
【請求項２】
請求項１において、
前記送信価値単価決定部（２１２、３１２、９１２）は、前記優先度バッファの同じ前記優先度クラスに同じ前記送信データがある場合、同じ前記送信データに対する前記データ価値単価を加算して前記送信データ価値単価とする無線通信端末。
【請求項３】
請求項２において、
前記送信価値単価決定部（９１２）は、前記送信データ価値単価が複数の前記データ価値単価を加算して決定した値であり、かつ、前記送信データ価値単価の算出に用いた前記データ価値単価に対応する前記送信データの削除要求を前記データ供給部から取得した場合には、前記送信データ価値単価から、削除要求のあった前記送信データの前記データ価値単価を減算して、前記送信データ価値単価を再決定する無線通信端末。
【請求項４】
請求項２または３において、
同じ前記優先度バッファに同じ種別の前記送信データのセットが２セットあり、かつ、それら２セットの前記送信データのセットに積集合が存在している場合に、前記積集合が部分集合であるか、包含関係のない集合であるかを判断する包含関係判断部（４１５）と、
前記包含関係判断部が、前記積集合が前記部分集合であると判断した場合に、前記部分集合に対するデータ価値を、前記部分集合である前記送信データの前記データ価値単価（Ｖａ）および前記部分集合のデータ数（Ｎａ）から算出し、前記部分集合に対する上位集合のデータ価値を、前記上位集合である前記送信データの前記データ価値単価（Ｖｂ）および前記上位集合のデータ数（Ｎｂ）から算出し、さらに、前記部分集合に対するデータ価値と前記上位集合に対するデータ価値の和を前記上位集合のデータ数で割ることで判定用価値単価（Ｖｊ）を算出する判定用価値単価算出部（４１６）とを備え、
前記送信価値単価決定部（４１２）は、前記判定用価値単価（Ｖｊ）が前記部分集合である前記送信データの前記データ価値単価（Ｖａ）よりも低い場合には、前記部分集合のデータ数（Ｎａ）を前記上位集合のデータ数（Ｎｂ）で割った値を前記部分集合の前記送信データの前記データ価値単価（Ｖａ）に乗じた値と、前記上位集合の前記送信データの前記データ価値単価（Ｖｂ）との和を、前記送信データ価値単価とする無線通信端末。
【請求項５】
請求項４において、
前記送信価値単価決定部（４１２）は、
前記包含関係判断部が、前記積集合が部分集合でないと判断した場合に、２セットの前記送信データのうち、前記送信データ価値単価が高い側を第１送信データ、他方を第２送信データとしたとき、
前記第１送信データの前記送信データ価値単価（ＶｔＡ）を、前記第２送信データのデータ数（Ｎｂ）を前記第１送信データのデータ数（Ｎａ）で割った値（Ｎｂ／Ｎａ）に前記第２送信データの前記データ価値単価（Ｖｂ）を乗じた値と、前記第１送信データの前記データ価値単価（Ｖａ）の和とし、
前記第２送信データのうち、前記第１送信データに含まれないデータの前記送信データ価値単価（Ｖｔ（Ｂ−Ａ）を、前記第２送信データの前記データ価値単価（Ｖｂ）とする無線通信端末。
【請求項６】
請求項２または３において、
同じ前記優先度バッファに同じ種別の前記送信データのセットが２セットあり、かつ、それら２セットの前記送信データのセットの一方を第１送信データ、他方を第２送信データとしたとき、前記第１送信データが導出元データとなり、前記第１送信データを抽象化して前記第２送信データが導出できる導出関係があるか否かを判断する導出関係判断部（５１５）と、
前記導出関係判断部が前記導出関係があると判断した場合に、前記第１送信データに対する前記データ価値単価（Ｖａ）と、前記第１送信データに対する前記第２送信データの抽象化度（α）に前記第２送信データの前記データ価値単価（Ｖｂ）を乗じた値との和を判定用価値単価（Ｖｊ）として算出する判定用価値単価算出部（５１６）とを備え、
前記送信価値単価決定部（５１２）は、前記判定用価値単価（Ｖｊ）が前記第２送信データのデータ価値単価（Ｖｂ）以上であれば、前記判定用価値単価（Ｖｊ）を前記第１送信データの前記送信データ価値単価とする無線通信端末。
【請求項７】
請求項１〜６のいずれか１項において、
前記無線通信端末は移動装置（２）に搭載されており、
前記無線通信端末は、
前記移動装置の予め定めた種類の状態である装置状態を取得する装置状態取得部（６１７）を備え、
前記データ価値単価決定部（６１１）は、前記装置状態取得部が取得した前記装置状態、および、前記装置状態と前記送信データの種別から前記データ価値単価が定まる関係に基づいて、前記優先度バッファに記憶されている前記送信データの前記データ価値単価を決定する無線通信端末。
【請求項８】
請求項１〜６のいずれか１項において、
前記優先度バッファに記憶されている前記送信データのメタデータを取得するメタデータ取得部（７１７）を備え、
前記データ価値単価決定部（７１１）は、前記メタデータ取得部が取得した前記メタデータ、および、前記メタデータと前記送信データの種別から前記データ価値単価が定まる関係に基づいて、前記優先度バッファに記憶されている前記送信データの前記データ価値単価を決定する無線通信端末。  
【請求項９】
請求項１〜６のいずれか１項において、
前記データ価値単価決定部（８１１）は、前記送信データのデータ価値単価を乱数で決定する無線通信端末。
【請求項１０】
請求項１〜９のいずれか１項において、
前記送信価値単価決定部（９１２）は、前記送信データ価値単価を決定した後も、前記送信データが送信されるまで前記送信データ価値単価を逐次再決定し、
前記送信順序制御部（９１３）は、前記送信データ価値単価が変更になった場合には前記送信順序を再付与し、
前記リソース割り当て部（９１４）は、前記送信順序が変更になった場合には前記通信リソースを再度割り当てる無線通信端末。
【請求項１１】
請求項１〜１０のいずれか１項において、
前記送信順序制御部（１０１３）は、前記送信閾値として、互いに大きさが異なる複数の前記送信閾値を設定しており、複数の前記送信閾値のうち、値が大きい前記送信閾値から順に用いて前記送信順序付与対象を決定する無線通信端末。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線通信端末に関し、特に、データの送信順序を決定する技術に関する。
【背景技術】
【０００２】
特許文献１では、パケットを、通信品質に関する要求値を持つパケットと、通信品質に関する要求値を持たないパケットに分け、通信品質に関する要求値が高いパケットを優先して送信する。通信品質としては、伝送速度、伝送遅延、ジッタが例示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００４−１４０６０４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
通信品質に関する要求値が高くても、優先して送信する必要がないデータもある。たとえば、以下の例がある。無線通信端末が車両に搭載されており、車載カメラが撮像した画像により道路異常が検出された場合、その場所の画像を撮像した画像データは、道路を管理するサーバ等に迅速に送信される必要がある。そのため、道路異常が発生している場所の画像データを送信する無線通信端末は、通信品質に関する要求値を高くすることが想定される。
【０００５】
しかし、１つの無線通信端末が、道路異常が発生している場所の画像データを送信すればよい。したがって、１つの無線通信端末が、道路異常が発生している場所の画像データを送信した後は、通信品質に関する要求値が高くても、道路異常が発生している場所の画像データは、優先して送信する必要がない。
【０００６】
本発明は、この事情に基づいて成されたものであり、その目的とするところは、送信する価値が高い送信データを優先して送信することができる無線通信端末を提供することにある。
【課題を解決するための手段】
【０００７】
上記目的は独立請求項に記載の特徴の組み合わせにより達成され、また、下位請求項は、発明の更なる有利な具体例を規定する。特許請求の範囲に記載した括弧内の符号は、一つの態様として後述する実施形態に記載の具体的手段との対応関係を示すものであって、本発明の技術的範囲を限定するものではない。
【０００８】
上記目的を達成するための本発明は、
送信データをデータ供給部から取得し、取得した送信データを送信データの種別により定まる通信品質要求に基づいて優先度クラス別に分類して、優先度クラス別に優先度バッファに記憶するデータ分類部（１１０）と、
優先度バッファに記憶されている送信データのデータ価値単価を決定するデータ価値単価決定部（１１１、６１１、７１１、８１１）と、
データ価値単価決定部が決定したデータ価値単価に基づいて送信データ価値単価を決定する送信価値単価決定部（１１２、２１２、３１２、４１２、５１２、９１２）と、
送信価値単価決定部が決定した送信データ価値単価が予め設定した送信閾値以上である送信データを送信順序付与対象として、データ分類部が分類した優先度クラスに基づいて、送信順序を付与する送信順序制御部（１１３、９１３、１０１３）と、
送信順序制御部が決定した送信順序に基づいて、送信データに通信リソースを割り当てるリソース割り当て部（１１４、９１４）と、
リソース割り当て部が割り当てた通信リソースで送信データを送信する送信部（１０１）とを備える無線通信端末である。
【０００９】
本発明では、送信データに対して、データの種別により定まる優先度クラスに加え、データ価値単価を決定し、このデータ価値単価に基づいて送信データ価値単価を決定する。この送信データ価値単価が送信閾値以上の送信データを送信順序付与対象として、優先度クラスに基づいて送信順序を付与する。
【００１０】
これにより、優先度クラスが高くても、送信データ価値単価が低い送信データには送信順序が付与されないことになる。その結果、送信する価値が高い送信データを優先して送信することができる。
【図面の簡単な説明】
【００１１】
【図１】第１実施形態の無線通信端末１００の使用状態を示す図である。
【図２】図１の無線通信端末１００の構成図である。
【図３】第１実施形態における優先度クラスを示す図である。
【図４】データ種別とデータ価値単価との対応関係を示すテーブルである。
【図５】第１実施形態において制御部１０４が実行する処理をフローチャートで示している。
【図６】図５のＳ７の詳細処理を示すフローチャートである。
【図７】第２実施形態の無線通信端末２００の構成図である。
【図８】図３からベストエフォート部分を抽出した表である。
【図９】第３実施形態の無線通信端末３００の構成図である。
【図１０】図４の一部を抽出した表である。
【図１１】データ価値単価を加算して送信データ価値単価を決定する図である。
【図１２】データ価値単価を送信閾値ＴＨと比較して示す図である。
【図１３】データ価値単価が加算された部分が送信閾値ＴＨを超えることを示す図である。
【図１４】第４実施形態における無線通信端末４００の構成を示すブロック図である。
【図１５】包含関係にある集合Ａと集合Ｂを示す図である。
【図１６】送信価値単価決定部４１２が実行する処理を説明する図である。
【図１７】送信価値単価決定部４１２が決定する送信データ価値単価の具体例を説明する図である。
【図１８】第５実施形態における無線通信端末５００の構成を示すブロック図である。
【図１９】導出関係を示す図である。
【図２０】データ価値単価を加算して送信データ価値単価を決定する具体例を示す図である。
【図２１】第６実施形態の無線通信端末６００の構成を示すブロック図である。
【図２２】データ価値マップの一例を示す図である。
【図２３】第７実施形態の無線通信端末７００の構成を示す図である。
【図２４】第８実施形態の無線通信端末８００の構成を示す図である。
【図２５】第９実施形態の無線通信端末９００の構成を示す図である。
【図２６】第１０実施形態の無線通信端末１０００の構成を示す図である。
【図２７】２つの送信閾値ＴＨ１、ＴＨ２と送信データ価値単価の関係を示す図である。
【発明を実施するための形態】
【００１２】
＜第１実施形態＞
以下、本発明の実施形態を図面に基づいて説明する。図１は、本発明が適用された無線通信端末１００の使用状態を示している。図１に示す無線通信端末１００は、移動装置である車両２で用いられ、車両２とともに移動する。
【００１３】
無線通信端末１００は、サーバ３との間でデータの通信を行う。データの通信は送信と受信がある。無線通信端末１００とサーバ３との間の通信は、基地局４と通信回線網５とを介して行われる。無線通信端末１００からサーバ３へのデータ送信は上り送信であり、サーバ３から無線通信端末１００への送信は下り送信である。
【００１４】
［無線通信端末１００の構成］
無線通信端末１００は、図２に示すように、無線通信部１０１、優先度バッファ１０２、記憶部１０３、制御部１０４を備えている。無線通信部１０１は、電波で信号の送受信を行い、基地局４、通信回線網５を介して、サーバ３と通信を行う。無線通信部１０１が送受信を行う電波の周波数は、法規上、許容されていれば特に制限はない。また、通信方式は、移動通信システムで用いられているＬＴＥなどの通信方式に限られず、無線ＬＡＮなどの狭域通信を組み合わせて用いてもよい。無線通信部１０１は無線送信機能を備えており、請求項の送信部として機能する。
【００１５】
優先度バッファ１０２は、無線通信端末１００が送信するデータ（以下、送信データ）を一時的に記憶する。優先度バッファ１０２は、複数の優先度クラス別に送信データを格納する構成である。
【００１６】
本実施形態では、優先度クラスは、送信データのリアルタイム性に関する要求の高さにより定められている。図３に本実施形態における優先度クラスを例示している。図３には、優先度クラスとして、Ｃｏｎｔｒｏｌ、Ｕ＿Ｐ１、Ｕ＿Ｐ３、Ｕ＿Ｐ７、Ｕ＿Ｐ９が示されている。Ｃｏｎｔｒｏｌは制御チャネルを使用する優先度クラスという意味であり、最も優先度が高いことを意味する。Ｕ＿Ｐ１、Ｕ＿Ｐ３、Ｕ＿Ｐ７、Ｕ＿Ｐ９において、「Ｕ」はアップリンクであることを示しており、数字は小さいほど優先度が高い。
【００１７】
図３において、優先度クラスの上の行にはリアルタイム性に関する要求の高さが示されている。「Ｈａｒｄ」は、デッドラインまでに処理が行われないと重大な問題が生じることを意味する。「ｆｉｒｍ」は、デッドラインまでに処理が行われなくても、重大な問題が生じることはないが、デッドライン以降に処理を行っても処理の価値はゼロであることを意味する。
【００１８】
「ｓｏｆｔ」は、デッドラインまでに処理が行われなくても、重大な問題が生じることはなく、また、デッドライン以降に処理が行われる場合、処理の価値は、即座にゼロにはならず、徐々に低下することを意味する。
【００１９】
優先度クラスがＣｏｎｔｒｏｌに対応するリアルタイム性には、ｈａｒｄ以外にｕｎｋｎｏｗｎもある。リアルタイム性が不明の場合、リアルタイム性がｈｒａｄである可能性もあるからである。
【００２０】
リアルタイム性がｈｒａｄまたはｕｎｋｎｏｗｎ、優先度クラスがＣｏｎｔｒｏｌになっている送信データは、帯域確保型の通信方式でデータを送信する。優先度クラスがｆｉｒｍ、優先度クラスがＵ＿Ｐ１になっている送信データは、帯域保証型の通信方式でデータを送信する。リアルタイム性がｓｏｆｔなっている送信データは、ベストエフォート型の通信方式でデータを送信する。
【００２１】
このようにリアルタイム性は、デッドラインまでに処理が行われるか否かを指標としており、デッドラインまでに処理が行われるか否かには、伝送速度、伝送遅延が関係する。したがって、送信データのリアルタイム性に関する要求の高さにより優先度クラスを決定することは、送信データの種別により定まる通信品質要求に基づいて優先度クラスを定めていることになる。
【００２２】
図３においてサービスＩＤは、送信データを利用して実行する処理、あるいは、送信データの送信要求を特定するＩＤである。データＩＤは、サービスＩＤにより特定されるサービスにおいて必要となるデータを特定するＩＤである。なお、理解を容易にするために、図３では、サービスＩＤ、データＩＤともに単語で示さしているが、実際には、サービスＩＤ、データＩＤは数字列あるいは数字と文字の組み合わせで表現される。図３では、サービスＩＤとして示されている単語が、実行するサービスの種別を意味し、データＩＤとして示されている単語が送信データの種別を意味する。
【００２３】
「クエリ」は、送信データの送信要求である。クエリは、データ種別のいずれかに該当する送信データではないので、データＩＤは付与されておらず、また送信データ自体ではないことから、送信データは不明なのでリアルタイム性はｕｎｋｎｏｗｎになっている。
【００２４】
「電子牽引」は、電子制御により後続車両を牽引する制御であり、送信データは、後続車両を制御する制御信号になる。「遠隔監視」は、監視地点を、監視地点から離れた位置から監視するサービスであり、送信データは、その地点を撮像した画像データになる。
【００２５】
優先度クラスがＵ＿Ｐ３の「走行異常検出」は、車両２の走行異常を検出するサービスであり、送信データは、走行異常を検出しているときに車載前方カメラで撮像した画像データである。優先度クラスがＵ＿Ｐ７の「走行異常検出」は、車両２の走行異常を検出するサービスであり、送信データはＣＡＮデータである。なお、「ＣＡＮ」は登録商標である。「故障診断」は、車両２の故障を診断するサービスであり、送信データはＣＡＮデータである。
【００２６】
優先度クラスがＵ＿Ｐ９の「走行異常検出」は、車両２の走行異常を検出するサービスである点で優先度クラスがＵ＿Ｐ３の「走行異常検出」と同じである。また、送信データも優先度クラスがＵ＿Ｐ３と同じく画像データである。ただし「（ｓａｖｅ）」と表記されている。これは、送信要求があったときに送信できるように、保存しておくという意味である。この送信データは、当然、リアルタイム性の要求は高くない。したがって、優先度クラスは低くなっているのである。
【００２７】
記憶部１０３は、不揮発性の記憶媒体であり、図４に示すテーブルを記憶している。図４に示すテーブルの説明は後述する。
【００２８】
制御部１０４は、ＣＰＵ、ＲＡＭ、ＲＯＭ、Ｉ／Ｏ、およびこれらの構成を接続するバスラインなどを備えたコンピュータである。ＲＯＭには、汎用的なコンピュータを制御部１０４として機能させるためのプログラムが格納されている。なお、上述のプログラムは、非遷移的実体的記録媒体（non- transitory tangible storage medium）に格納されていればよく、その具体的な記憶媒体はＲＯＭに限らない。たとえば、フラッシュメモリに上述のプログラムが保存されていてもよい。ＣＰＵがこのプログラムを実行することは、制御プログラムに対応する方法が実行されることに相当する。
【００２９】
この制御部１０４は、ＣＰＵがＲＯＭに格納されているプログラムを実行することによって、図２に示す各部の機能を提供する。すなわち、制御部１０４は機能ブロックとして、データ分類部１１０、データ価値単価決定部１１１、送信価値単価決定部１１２、送信順序制御部１１３、リソース割り当て部１１４を備える。
【００３０】
なお、制御部１０４が備える機能ブロックの一部または全部は、一つあるいは複数のＩＣ等を用いて（換言すればハードウェアとして）実現してもよい。また、制御部１０４が備える機能ブロックの一部又は全部は、ＣＰＵによるソフトウェアの実行とハードウェア部材の組み合わせによって実現されてもよい。
【００３１】
制御部１０４は、車両２に備えられたデータ供給部６から、車内通信線を介して送信データを取得する。データ供給部６は、たとえば、車両２に搭載された種々のセンサである。センサにはカメラも含まれる。また、制御信号やＣＡＮデータを供給するＥＣＵもデータ供給部６の一例である。
【００３２】
データ分類部１１０は、データ供給部６から取得した送信データを、優先度クラス別に分類して、優先度クラス別に優先度バッファ１０２に格納する。優先度クラスは、送信データのリアルタイム性に関する要求の高さに基づいて決定する。どの種別の送信データが、どの優先度クラスに分類されるかは、予め定められている。
【００３３】
データ価値単価決定部１１１は、優先度バッファ１０２に記憶されている送信データのうち、リアルタイム性がｓｏｆｔ、よって、ベストエフォート型の通信方式で送信する送信データについてのデータ価値単価を決定する。送信データのデータ価値単価は、図４に示すテーブルに定められている。
【００３４】
図４に示すテーブルには、データ種別とデータ価値単価との対応関係が示されている。その他に、サービス名、回線、リアルタイム性、優先度クラス、サービスＱｏＳも含まれている。サービス名、データ種別は、それぞれサービスＩＤ、データＩＤにより表されている。遠隔制御クラウドアプリは、車両２の遠隔制御を実行するアプリケーションを意味する。走行異常検出クラウドアプリは、車両２の走行に何らかの異常が生じたことを、車両外部で検出するアプリケーションを意味し、図３に示す「走行異常検出」は走行異常検出クラウドアプリを簡略化して表記したものである。故障診断クラウドアプリは、車両２が故障したか否かの診断を車両外部で検出するアプリケーションを意味し、図３に示す「故障診断」は故障診断クラウドアプリを簡略化して表示したものである。
【００３５】
送信頻度は、送信データを送信する頻度を示している。リアルタイム性、優先度クラスは図３で説明した内容と同じである。ＱｏＳは、通信の品質要求である。図４の例では、ＱｏＳは具体的には伝送遅延の許容値と伝送容量である。
【００３６】
データ価値単価は、単位データ量に対する価格である。この図４に示すテーブルは、予め設定することができる。また、サーバ３や他の無線通信端末１００から送信されたクエリにより設定されていてもよい。また、データ価値単価は、ユーザが所定の変更操作を行うなどして変更することもできる。
【００３７】
データ価値単価を具体的に見ると、図４の中では、遠隔制御クラウドアプリが要求する画像データの単価が最も高い。次に高いデータ価値単価は、故障診断クラウドアプリが要求するＣＡＮデータである。このＣＡＮデータは、優先度クラスはＵ＿Ｐ７であり、走行異常検出クラウドアプリが要求する画像データの優先度クラスであるＵ＿Ｐ３よりも低い。しかし、データ価値単価は、故障診断クラウドアプリが要求するＣＡＮデータのほうが高くなっている。
【００３８】
本実施形態の送信価値単価決定部１１２は、データ価値単価決定部１１１が決定したデータ価値単価を、そのまま、送信データ価値単価に決定する。この送信データ価値単価は、次に説明する送信順序制御部１１３において送信閾値ＴＨと比較する値であり、送信データを送信する価値があるか否かを判断するための値である。
【００３９】
送信順序制御部１１３は、送信価値単価決定部１１２が決定した送信データ価値単価が予め設定した送信閾値ＴＨ以上である送信データを送信順序付与対象とする。よって、優先度クラスが高い送信データであっても、データ価値単価が送信閾値ＴＨよりも低い送信データには送信順序が付与されない。その結果、優先度クラスが低くても、送信データ価値単価が高い送信データが優先して送信されることになる。
【００４０】
リソース割り当て部１１４は、まず、優先度バッファ１０２に保存されている送信データのうち、帯域確保型および帯域保証型の通信方式で送信する送信データに対して、通信リソースを割り当てる。続いて、ベストエフォート型で送信する送信データに対して通信リソースを割り当てる。ただし、ベストエフォート型で送信する送信データに対しては、送信順序制御部１１３が付与した送信順序が高い送信データから順番に、通信リソースを割り当てる。送信順序が付与された後の通信リソースの割り当て処理は公知の種々の処理が採用できる。また、通信リソースには、周波数帯域およびタイムスロットの少なくとも一方を含む。
【００４１】
［フローチャート］
図５に第１実施形態において制御部１０４が実行する処理をフローチャートで示している。図５に示す処理はデータ分類部１１０が送信データを取得した場合に開始する。ステップ（以下、ステップを省略する）Ｓ１はデータ分類部１１０が実行する処理であり、送信データを、優先度クラス別に優先度バッファ１０２へ挿入する。
【００４２】
Ｓ２は送信順序制御部１１３が実行する処理であり、帯域確保型および帯域保証型で送信する送信データのスケジューリングを行う。スケジューリングの方法は、ＰＱ（Ｐｒｉｏｒｉｔｙ  Ｑｕｅｕｉｎｇ）、ＣＢＱ（Ｃｌａｓｓ−Ｂａｓｅｄ  Ｑｕｅｕｉｎｇ）、ＷＲＲ（Ｗｅｉｇｈｔｅｄ  Ｒｏｕｎｄ−ｒｏｂｉｎ）等、公知の種々のスケジューリング方法を用いることができる。
【００４３】
Ｓ３はリソース割り当て部１１４が実行する処理であり、Ｓ２で決定した送信順序に従って優先度バッファ１０２から送信データを取り出して通信リソースを割り当てる。通信リソースを割り当てられた送信データは、無線通信部１０１から、その通信リソースで送信されることになる。
【００４４】
Ｓ４では、通信リソースが残っているか否かを判断する。Ｓ４はリソース割り当て部１１４が実行する。Ｓ４の判断がＮＯであれば図５に示す処理を終了する。Ｓ４の判断がＹＥＳであればＳ５に進む。
【００４５】
Ｓ５はデータ価値単価決定部１１１が実行する処理であり、優先度バッファ１０２に格納されているベストエフォート型の送信データに対するデータ価値単価を、記憶部１０３に記憶されているテーブルから取得する。
【００４６】
Ｓ６は送信価値単価決定部１１２の処理である。第１実施形態では、Ｓ５で取得したデータ価値単価をそのまま送信データ価値単価とする。
【００４７】
Ｓ７は送信順序制御部１１３が実行する処理であり、Ｓ６で決定した送信データ価値単価に基づいて、優先度バッファ１０２に記憶されているベストエフォートデータの送信順序を決定する。なお、ベストエフォートデータは、ベストエフォート型の送信方式で送信する送信データを意味する。Ｓ７の処理は図６に詳しく示す。
【００４８】
図６において、Ｓ７１ではベストエフォート型の送信データにおいて最大の優先度クラスにある送信データの送信データ価値単価を抽出する。Ｓ７２では、ベストエフォート型の送信データにおいて最大の優先度クラスにある送信データに、送信データ価値単価が送信閾値ＴＨ以上である送信データがあるか否かを判断する。この判断がＹＥＳであればＳ７３に進む。
【００４９】
Ｓ７３では、最大の優先度クラスにある送信データのうち、送信データ価値単価が送信閾値ＴＨ以上である送信データに対して送信順序を付与する。送信順序の決定方法は、Ｓ２と同様、公知の種々のスケジューリング方法を用いることができる。
【００５０】
Ｓ７２の判断がＮＯである場合またはＳ７３を実行した場合はＳ７４に進む。Ｓ７４では、次の優先度クラスにある送信データの送信データ価値単価を抽出する。Ｓ７５では、Ｓ７４で抽出した送信データ価値単価に送信閾値ＴＨ以上の送信データ価値単価があるか否かを判断する。この判断がＹＥＳであればＳ７６に進む。
【００５１】
Ｓ７６では、Ｓ７４で送信データ価値単価を抽出した送信データのうち、送信データ価値単価が送信閾値ＴＨ以上である送信データに対して、Ｓ７３と同様にして送信順序を付与する。Ｓ７５の判断がＮＯである場合またはＳ７６を実行した場合はＳ７７に進む。
【００５２】
Ｓ７７では、優先度バッファ１０２に記憶されている送信データに、さらに下の優先度クラスにある送信データがあるか否かを判断する。この判断がＹＥＳであればＳ７４に戻り、ＮＯであれば図６の処理を終了する。
【００５３】
この図６に示す処理の適用例を図３を用いて説明する。図３には、優先度クラス別に分けられたキューも示されている。各キューは優先度バッファ１０２の一部要素である。優先度クラスがＵ＿Ｐ３のキューには、ｄ３１、ｄ３２の２セットの送信データが入っている。優先度クラスがＵ＿Ｐ７のキューには、ｄ７１、ｄ７２、ｄ７３、ｄ７４の４セットの送信データが入っている。優先度クラスがＵ＿Ｐ９のキューには、ｄ９１の送信データが入っている。これらのうち、ｄ７１、ｄ７２の送信データ価値単価が送信閾値ＴＨを超えており、残りの送信データの送信データ価値単価は送信閾値ＴＨ以上ではないとする。
【００５４】
この場合、優先度クラスがＵ＿Ｐ３であっても、ｄ３１、ｄ３２は送信順序が付与されない一方で、優先度クラスがＵ＿Ｐ７であるｄ７１、ｄ７２には送信順序が付与される。
【００５５】
説明を図５に戻す。Ｓ８はリソース割り当て部１１４が実行する処理であり、Ｓ７で送信順序を付与したベストエフォート型の通信方式で送信する送信データに対して、通信リソースを割り当てる。
【００５６】
［第１実施形態のまとめ］
この第１実施形態では、優先度バッファ１０２に格納されたベストエフォート型で送信する送信データに対しては、送信データの種別により定まる優先度クラスに加えて、データ価値単価を決定し（Ｓ５）、これを送信データ価値単価とする（Ｓ６）。そして、この送信データ価値単価が送信閾値ＴＨ以上の送信データを送信順序付与対象として、優先度クラスに基づいて送信順序を付与する（Ｓ７）。
【００５７】
これにより、優先度クラスが高くても、送信データ価値単価が低い送信データには送信順序が付与されないことになる。その結果、送信する価値が高い送信データを優先して送信することができる。
【００５８】
＜第２実施形態＞
次に、第２実施形態を説明する。この第２実施形態以下の説明において、それまでに使用した符号と同一の番号の符号を有する要素は、特に言及する場合を除き、それ以前の実施形態における同一符号の要素と同一である。また、構成の一部のみを説明している場合、構成の他の部分については先に説明した実施形態を適用できる。
第２実施形態の無線通信端末２００の制御部２０４は、図７に示す送信価値単価決定部２１２の機能が、第１実施形態の送信価値単価決定部１１２の機能と相違する。送信価値単価決定部２１２は、優先度バッファ１０２の同じ優先度クラスに、同じ送信データがある場合、同じ送信データに対するデータ価値単価を加算して送信データ価値単価とする。
【００５９】
ここでの同じ送信データは、データ種別が同じであることを意味する。図８は、図３からベストエフォート部分を抽出した表である。図８においては、Ｕ＿Ｐ７の優先度クラスに、サービスＩＤは異なるが、データ種別が同じである送信データがある。具体的には、図８では、走行異常検出サービスと故障診断サービスが、ともに送信データがＣＡＮデータになっている。
【００６０】
図４に示したように、走行異常検出クラウドアプリのＣＡＮデータのデータ価値単価は０．８円／ＭＢである。また、故障診断クラウドアプリのＣＡＮデータのデータ価値単価は０．６円／ＭＢである。これらは、優先度クラスが同じであり、かつ、データ種別が同じである。よって、第２実施形態では、これら２つのデータ価値単価を加算して送信データ価値単価とする。これにより、優先度クラスがＵ＿Ｐ７のＣＡＮデータの送信データ価値単価は、２．４円／ＭＢになる。
【００６１】
このように送信データ価値単価が、複数のデータ価値単価の加算により算出された場合、加算された複数のデータ価値単価に対応する各送信データは、別々の送信データではなく、１つの送信データとして扱われて送信される。よって、送信データ量を削減することもできる。
【００６２】
この第２実施形態のようにすることで、優先度クラスが低くても、同じ優先度クラスに同じデータ種別の送信データがある場合には、その送信データが送信されやすくなる。なお、送信データ価値単価が複数のデータ価値単価が加算された値である場合に、その送信データ価値単価となった送信データを、上の優先度クラスの送信データよりも優先して送信したい場合、上の優先度クラスに属する送信データのデータ価値単価よりも高い送信閾値ＴＨを設定しておけばよい。
【００６３】
＜第３実施形態＞
第３実施形態の無線通信端末３００は、図９に示す制御部３０４の送信価値単価決定部３１２の機能が、第２実施形態の送信価値単価決定部２１２の機能と相違する。第２実施形態の送信価値単価決定部２１２は、優先度クラスが同じであり、かつ、送信データの種別が同じであれば、データ価値単価を加算していた。
【００６４】
これに対して、第３実施形態の送信価値単価決定部３１２は、個々の送信データを別々に扱い、優先度クラスが同じであり、かつ、送信データの種別が同じであれば、データ価値単価を加算して送信データ価値単価とする。
【００６５】
図１０、図１１を用いて、第３実施形態の送信価値単価決定部３１２の処理を具体的に説明する。図１０は、図４の一部を抽出した表である。図１０に示すように、走行検出クラウドアプリと故障診断クラウドアプリは、ともに、送信データがＣＡＮデータである。ただし、走行検出クラウドアプリは送信頻度が１００ｍｓ周期であるのに対して、故障診断クラウドアプリは送信周期が１ｓである。
【００６６】
図１０の例において送信価値単価決定部３１２が決定する送信データ価値単価を図１１に示す。図１１には、走行異常検出クラウドアプリのＣＡＮデータのデータ価値単価と、故障診断クラウドアプリのＣＡＮデータのデータ価値単価を加算して送信データ価値単価を決定することが示されている。図１１において、送信データ価値単価の色は価値単価の高さを示している。
【００６７】
走行異常検出クラウドアプリと故障診断クラウドアプリは、ともに、送信データの種別がＣＡＮデータであり、優先度クラスはともにＵ＿Ｐ７である。ただし、送信タイミングが重なるのは１秒周期である。そのため、送信データ価値単価は１秒周期で高くなる。このときの送信データ価値単価は、０．８＋１．６＝２．４（円／ＭＢ）である。その他のタイミングでは、故障診断クラウドアプリは送信データを送信しないことから、その他のタイミングでの送信データ価値単価は走行異常検出クラウドアプリにより定まるデータ価値単価と同じ、すなわち、０．８（円／ＭＢ）である。
【００６８】
データ価値単価を加算して送信データ価値単価とすると送信閾値ＴＨを超えやすくなるので、データ価値単価が加算されて決定された送信データ価値単価となった送信データは、優先して送信されやすくなる。このことを図１２、図１３を用いて具体的に説明する。
【００６９】
図１２には、走行異常検出クラウドアプリのＣＡＮデータのデータ価値単価、故障診断クラウドアプリのＣＡＮデータのデータ価値単価を、送信閾値ＴＨと比較して示している。図１２に示すように、ＣＡＮデータのデータ価値単価は、走行異常検出クラウドアプリも故障診断クラウドアプリも、送信閾値ＴＨを超えていない。そのため、この送信閾値ＴＨとの比較では、ＣＡＮデータに送信順序が付与されない。
【００７０】
これに対して、図１３に示すように、送信データ価値単価は、データ価値単価が加算された部分が送信閾値ＴＨを超える。したがって、データ価値単価が加算されて決定された送信データ価値単価となった送信データには送信順序が付与されて送信されることになる。
【００７１】
＜第４実施形態＞
図１４は、第４実施形態における無線通信端末４００の構成を示すブロック図である。無線通信端末４００の制御部４０４は、包含関係判断部４１５と判定用価値単価算出部４１６を備える。また、送信価値単価決定部４１２の処理が、これまでの実施形態と相違する。
【００７２】
包含関係判断部４１５は、優先度バッファ１０２の同じ優先度クラスに同じ種別の送信データのセットが２セットある場合、それら２セットの送信データのセットに積集合が存在しているか否かを判断する。さらに、積集合がある場合、その積集合が部分集合であるか、包含関係のない集合であるかを判断する。
【００７３】
具体例で説明する。たとえば、第３実施形態では、ある送信タイミングにおけるＣＡＮデータに複数のデータがあるか否かは考慮せずに、ある送信タイミングにおけるＣＡＮデータを１つのデータとしていた。これに対して、第４実施形態では、ある送信タイミングにおけるＣＡＮデータに複数のデータが含まれている場合に、ＣＡＮデータに含まれている複数のデータを別々に扱う。以下、説明の便宜上、これら複数のデータをＣＡＮ＿ＩＤで区別する。
【００７４】
走行異常検出クラウドアプリが必要とするＣＡＮデータがＣＡＮ＿ＩＤ＝１、２、３、４であるとする。一方、故障診断クラウドアプリが必要とするＣＡＮデータがＣＡＮ＿ＩＤ＝１、２、３、４、・・・１９、２０であるとする。この具体例では、積集合は｛ＣＡＮ＿ＩＤ：１、２、３、４｝になる。
【００７５】
これらはともにＣＡＮデータであることから、同じ種別の送信データのセットに該当する。また、これらＣＡＮデータは、ともに優先度クラスがＵ＿Ｐ７、つまり、同じ優先度クラスの送信データである。したがって、走行異常検出クラウドアプリが必要とするＣＡＮデータと故障診断クラウドアプリが必要とするＣＡＮデータに積集合があるか否かを判断する。
【００７６】
図１５には、この具体例をベン図で示している。図１５に示すように、この具体例の場合、走行異常検出クラウドアプリが必要とするＣＡＮデータは、故障診断クラウドアプリが必要とするＣＡＮデータの部分集合になる。なお、以下での説明の便宜上、走行異常検出クラウドアプリのＣＡＮデータの集合を集合Ａ、故障診断クラウドアプリのＣＡＮデータの集合を集合Ｂとしている。
【００７７】
部分集合は積集合の一態様であることから、走行異常検出クラウドアプリが必要とするＣＡＮデータと、故障診断クラウドアプリが必要とするＣＡＮデータに積集合が存在していることになる。
【００７８】
判定用価値単価算出部４１６は、包含関係判断部４１５が、部分集合があると判断した場合に、判定用価値単価Ｖｊを算出する。この判定用価値単価Ｖｊは、積集合を共有する２つの送信データを分割するか否かを判定するために用いる値である。
【００７９】
判定用価値単価Ｖｊは式１で表される。式１において、Ｎａ、Ｎｂは、第１送信データのデータ数と第２送信データのデータ数である。第１送信データと第２送信データは、積集合を共有する２つの送信データである。上記具体例では、第１送信データは走行異常検出クラウドアプリのＣＡＮデータすなわち集合Ａであり、第２送信データは故障診断クラウドアプリのＣＡＮデータすなわち集合Ｂである。また、Ｖａは第１送信データのデータ価値単価であり、Ｖｂは第２送信データのデータ価値単価である。
【数１】
2018182430.tif 000003
【００８０】
式１において、分子の第１項は、部分集合である集合Ａに対するデータ価値であり、集合Ａのデータ価値単価Ｖａと集合Ａのデータ数Ｎａの積である。分子の第２項は、部分集合に対する上位集合である集合Ｂに対するデータ価値であり、集合Ｂのデータ価値単価Ｖｂと集合Ｂのデータ数Ｎｂの積である。よって、式１は、部分集合のデータ価値と上位集合のデータ価値の和を上位集合のデータ数で割ることを意味する。
【００８１】
送信価値単価決定部４１２は、図１６に示す条件式が成立するか否かを判断する。すなわち、部分集合があると判断した場合には、条件式ｆ１、ｆ２が成立するか否かを判断する。
【００８２】
条件式ｆ１は、部分集合である集合Ａのデータ価値単価Ｖａが判定用価値単価Ｖｊ以下であるか否かを判断する式である。条件式ｆ１がＴＲＵＥであれば、集合Ａと集合Ｂの和集合の送信データ価値単価Ｖｔ（Ａ＋Ｂ）は、図１６にも示すように、Ｖｂ＋（Ｎａ／Ｎｂ）×Ｖａにより算出する。また、この場合、集合Ａと集合Ｂの和集合を全体として１つの送信データとする。
【００８３】
一方、条件式ｆ１がＦＡＬＳＥであれば、集合Ａと集合Ｂの両方の属する送信データと、集合Ｂのみに属する送信データの２つに送信データを分けて、送信データ価値単価を決定する。集合Ａと集合Ｂの両方の属する送信データの送信データ価値単価は集合Ａのデータ価値単価Ｖａと集合Ｂのデータ価値単価Ｖｂの和とする。集合Ｂのうち、集合Ａには属さない送信データの送信データ価値単価は、集合Ｂのデータ価値単価Ｖｂとする。
【００８４】
条件式ｆ２は、部分集合である集合Ｂのデータ価値単価Ｖｂが判定用価値単価Ｖｊ以下であるか否かを判断する式である。条件式ｆ２がＴＲＵＥであれば、集合Ａと集合Ｂの和集合の送信データ価値単価Ｖｔ（Ａ＋Ｂ）は、図１６にも示すように、Ｖａ＋（Ｎｂ／Ｎａ）×Ｖｂにより算出する。また、この場合、集合Ａと集合Ｂの和集合を全体として１つの送信データとする。
【００８５】
条件式ｆ２がＦＡＬＳＥであれば、集合Ａと集合Ｂの両方の属する送信データと、集合Ｂのみに属する送信データの２つに送信データを分けて、送信データ価値単価を決定する。集合Ａと集合Ｂの両方の属する送信データの送信データ価値単価は集合Ａのデータ価値単価Ｖａと集合Ｂのデータ価値単価Ｖｂの和とする。集合Ａのうち、集合Ｂには属さない送信データの送信データ価値単価は、集合Ａのデータ価値単価Ｖａとする。
【００８６】
包含関係判断部４１５において包含関係がないと判断された場合には、送信価値単価決定部４１２は、集合Ａのデータ価値単価Ｖａが集合Ｂのデータ価値単価Ｖｂ以下であるという条件式ｆ３が成立するか否かを判断する。
【００８７】
この条件式ｆ３がＴＲＵＥであれば、集合Ｂの送信データと、集合Ａのうち集合Ｂには属さない送信データに分けて、送信データ価値単価Ｖｔを決定する。集合Ｂの送信データ価値単価ＶｔＢは、図１６にも示すように、Ｖｂ＋（Ｎａ／Ｎｂ）×Ｖａにより算出する。集合Ａのうち集合Ｂには属さない送信データの送信データ価値単価Ｖｔ（Ａ−Ｂ）は、集合Ａのデータ価値単価Ｖａとする。
【００８８】
条件式ｆ３がＦＡＬＳＥである場合には、集合Ａの送信データと、集合Ｂのうち集合Ａには属さない送信データに分けて、送信データ価値単価Ｖｔを決定する。集合Ａの送信データ価値単価ＶｔＡは、図１６にも示すように、Ｖａ＋（Ｎｂ／Ｎａ）×Ｖｂにより算出する。集合Ａのうち集合Ｂには属さない送信データの送信データ価値単価Ｖｔ（Ｂ−Ａ）は、集合Ｂのデータ価値単価Ｖｂとする。
【００８９】
図１７を用いて、送信価値単価決定部４１２が決定する送信データ価値単価の具体例を説明する。図１７には、走行異常検出アプリのＣＡＮデータのデータ価値単価と、故障診断クラウドアプリのＣＡＮデータのデータ価値単価を加算して送信データ価値単価を決定することが示されている。
【００９０】
図１７において、個々の四角が送信データのセット、すなわち、集合Ａ、あるいは、集合Ｂを示している。また、四角の色の濃さがデータ価値単価の高さを示しており、四角の縦方向長さはデータ量を示している。
【００９１】
図１７の例では、データ価値単価が加算されて決定された送信データ価値単価は、１．６＋（４／２０）×０．８＝１．７６（円／ＭＢ）になる。この送信データ価値単価が送信閾値ＴＨと比較されて送信順序を付与するか否かが決定される。
【００９２】
故障診断クラウドアプリがＣＡＮデータを要求していないタイミングに対しては、故障診断クラウドアプリのためのＣＡＮデータは優先度バッファには格納されない。よって、このときの送信データ価値単価は、走行異常検出クラウドアプリのＣＡＮデータのデータ価値単価、すなわち、０．８（円／ＭＢ）になる。
【００９３】
この図１７には示していないが、図１６において送信データ価値単価を２種類算出している場合、それら２種類の送信データ価値単価に対応する集合に送信データを分割して、分割後の送信データを１つの送信単位として送信順序を付与する。
【００９４】
＜第５実施形態＞
図１８は、第５実施形態における無線通信端末５００の構成を示すブロック図である。無線通信端末５００の制御部５０４は、導出関係判断部５１５と判定用価値単価算出部５１６を備える。また、送信価値単価決定部５１２の処理が、これまでの実施形態と相違する。
【００９５】
導出関係判断部５１５は、優先度バッファ１０２の同じ優先度クラスに同じ種別の送信データのセットが２セットあるとき、それら２セットの送信データに導出関係があるか否かを判断する。
【００９６】
導出関係は、それら２セットの送信データのセットの一方を第１送信データ、他方を第２送信データとしたとき、第１送信データが導出元データとなり、第１送信データを抽象化して、導出先データである第２送信データが導出できる関係である。
【００９７】
具体例で説明する。図１９には、導出関係を例示している。ＢＭＰ、ＪＰＥＧ、ＪＰＥＧ２０００は画像形式である。ＪＰＥＧおよびＪＰＥＧ２０００の画像データは、ＢＭＰから生成することができるので、ＢＭＰデータは導出元データすなわち第１送信データとなり、第２送信データとしてＪＰＥＧ、ＪＰＥＧ２０００を導出できる関係にある。
【００９８】
また、歩行者が写っているＢＭＰ画像データを解析すれば、画像に写っている歩行者を検出できる。同様に、歩行者や前方車両が写っているＪＰＥＧ画像データを解析すれば、画像に写っている歩行者および前方車両を検出できる。つまり、画像データと画像解析により検出できる物体との関係も導出関係である。この場合、第１送信データは画像データであり、第２送信データは画像解析により検出できる物体名である。また、全体の画像データを第１送信データとし、物体が写っている部分の画像データを第２送信データとすることもできる。
【００９９】
どのような種別の送信データを導出元データとして、どのような導出先データが導出できるかは、記憶部１０３などの不揮発性の記憶媒体に予め記憶されている。
【０１００】
図１９に示すように、導出元データから導出先データを導出することは、データの抽象化を意味する。よって、導出関係は抽象化の関係とも言える。
【０１０１】
この抽象化の程度を抽象化度αとする。たとえば、ＪＰＥＧデータの圧縮率を２０％とすると、抽象度化度αは０．２である。なお、圧縮率は、圧縮前のデータサイズに対する、圧縮後のデータサイズの比である。
【０１０２】
判定用価値単価算出部５１６は、導出関係判断部５１５が、導出関係があると判断した場合に、判定用価値単価Ｖｊを算出する。この判定用価値単価Ｖｊは、式２から算出する。
（式２）  Ｖｊ＝Ｖａ＋αＶｂ
式２は、実質的には第４実施形態で説明した式１と同じである。本実施形態において、式１の分母を考えると、導出元の送信データのサイズと導出先の送信データのサイズを比較することになる。抽象化度αの最大値を１と考えると、導出元の送信データのサイズは１と考えることができる。よって、本実施形態において、式１の分母を考えると１になる。
【０１０３】
また、同様に、Ｎａも１になる。そして、Ｎｂはαと考えることができる。よって、式２が得られる。以上より、式２は、実質的には式１と同じである。
【０１０４】
送信価値単価決定部５１２は、式３に示す条件式が成立するか否かを判断する。式３の条件式は、条件式ｆ２と同じである。式３は導出先の送信データである集合Ｂのデータ価値単価Ｖｂが判定用価値単価Ｖｊ以下であるか否かを判断する式である。
（式３）  Ｖｂ≦Ｖｊ
式３に式２を代入して変形すると、式４が得られる。
（式４）  Ｖａ≧（１―α）Ｖｂ
式４の条件式がＴＲＵＥであれば、集合Ａと集合Ｂの和集合の送信データ価値単価Ｖｔ（Ａ＋Ｂ）は、Ｖａ＋αＶｂにより算出する。「Ｖａ＋αＶｂ」は、条件式ｆ２がＴＲＵＥのときに用いるデータ価値単価の算出式において、Ｎｂ＝α、Ｎａ＝１とした式である。本実施形態において、集合Ａと集合Ｂの和集合は、導出元の送信データを意味する。
【０１０５】
式４の条件式がＦＡＬＳＥであれば、集合Ａと集合Ｂの両方に属する送信データと、集合Ｂのみに属する送信データの２つに送信データを分けて、送信データ価値単価を決定する。
【０１０６】
これらの送信データ価値単価は、図１６において条件式ｆ２がＦＡＬＳＥになったときと同じであり、集合Ａと集合Ｂの両方に属する送信データの送信データ価値単価は集合Ａのデータ価値単価Ｖａと集合Ｂのデータ価値単価Ｖｂの和とする。そして、この値を、導出元の送信データの送信データ価値単価とする。一方、集合Ａのうち、集合Ｂには属さない送信データの送信データ価値単価は、集合Ａのデータ価値単価Ｖａとする。そして、この値を、導出先の送信データの送信データ価値単価とする。
【０１０７】
図２０には、データ価値単価を加算して送信データ価値単価を決定する具体例を示している。図２０には、２つのサービスが示されている。一つのサービスは、サービス名が定点監視であり、画像フォーマットはＢＭＰ、要求周期（すなわちデータ送信周期）は０．００３３秒、撮像場所が特定の交差点、データ価値単価が１．８円／ＭＢである。こちらが第１送信データになる。
【０１０８】
もう一つのサービスは、サービス名が走行異常検出であり、画像フォーマットはＪＰＥＧ、要求周期は０．００３３秒、データ価値単価が０．４円／ＭＢである。こちらが第２送信データになる。
【０１０９】
この例において式４の条件式が成立する。よって、２つの送信データを分割せずに、１セットの送信データとして送信データ価値単価を決定する。図２０の例では、走行異常検出サービスは、継続的に送信データを必要としている。これに対して、定点監視サービスは、要求周期は走行異常検出サービスと同じであるが、送信データを必要とするタイミングは、走行異常検出サービスが送信データを必要とするタイミングの一部である。
【０１１０】
ＢＭＰデータの送信タイミングでは、ＢＭＰデータのみが送信される。ＢＭＰデータが送信されればＪＰＥＧデータは導出できるからである。ＪＰＥＧデータが送信されないことで、送信データ量を少なくすることができる。
【０１１１】
またＢＭＰデータの送信データ価値単価は式２により算出される。具体的には、１．８＋０．２×０．４＝１．８８になる。ＪＰＥＧデータとしての価値も備えるので、送信データ価値単価はＢＭＰデータのデータ価値単価よりも高くなる。送信データ価値単価が高くなるので優先的に送信される。
【０１１２】
＜第６実施形態＞
これまで説明してきた実施形態では、データ価値単価は固定値であった。この第６実施形態では、データ価値単価を、装置状態を検索キーとして検索する。図２１に第６実施形態の無線通信端末６００の構成を示す。
【０１１３】
第６実施形態の無線通信端末６００の制御部６０４は、装置状態取得部６１７を備え、また、データ価値単価決定部６１１の処理がこれまでの実施形態と相違する。
【０１１４】
装置状態取得部６１７は、無線通信端末６００が搭載されている移動装置、すなわち車両２の予め定めた種類の装置状態を取得する。装置状態には、たとえば、車両２の現在位置、現在時刻、車両の動作状態がある。また、車両２の動作状態は、たとえば、走行中か否か、充電中か否か、ワイパ動作中か否か、などがある。これら装置状態は、ＣＡＮなどを介して取得する。
【０１１５】
データ価値単価決定部６１１は、優先度バッファ１０２に記憶されている送信データのデータ価値単価を決定する点は、これまでの実施形態のデータ価値単価決定部１１１と同じである。ただし、本実施形態のデータ価値単価決定部６１１は、装置状態取得部６１７が取得した装置状態、および、データ価値マップから、優先度バッファ１０２に記憶されている送信データのデータ価値単価を取得する。データ価値マップは記憶部１０３に記憶されている。
【０１１６】
図２２には、データ価値マップの一例を示している。図２２に示すデータ価値マップは、サブノートＩＤである位置別に、故障診断サービスについてのＣＡＮデータのデータ価値単価、走行異常検出サービスについてのＣＡＮデータと画像データのデータ価値単価が定まるマップである。ここでの位置は現在位置を意味する。現在位置は装置状態の一例であり、ＣＡＮデータ、画像データは送信データの種別である。よって、このデータ価値マップは、装置状態と送信データの種別からデータ価値単価が定まる関係の一例である。
【０１１７】
データ価値単価決定部６１１は、このデータ価値マップから、装置状態取得部６１７が取得した現在位置に対応するデータ価値単価を検索して、データ価値単価を決定する。
【０１１８】
なお、図２２では、装置状態として、現在位置が示されているが、現在時刻、走行中か否かなど、現在位置以外の他の装置状態と送信データの種別からデータ価値単価が定まる関係でもよい。また、データ価値マップは、現在位置とワイパ動作中か否かなど、複数の装置状態と送信データの種別からデータ価値単価が定まる関係でもよい。
【０１１９】
このデータ価値マップを用いてデータ価値単価を決定することで、データ価値単価を動的に変化させることができる。たとえば、走行異常検出サービスにおいて、交通流が少なくデータ不足の場所や時間、規制が生じやすい場所のデータ価値単価を高くするなどの変更が可能になる。これにより、送信する価値がより高い送信データを優先して送信することができる。
【０１２０】
＜第７実施形態＞
前述した第６実施形態では装置状態を検索キーとしてデータ価値単価を検索した。それに対して第７実施形態では、メタデータを検索キーとしてデータ価値単価を検索する。図２３に第７実施形態の無線通信端末７００の構成を示す。
【０１２１】
第７実施形態の無線通信端末７００の制御部７０４は、はメタデータ取得部７１７を備え、また、データ価値単価決定部７１１の処理が、これまでの実施形態とは相違する。
【０１２２】
メタデータ取得部７１７は、送信データのメタデータを取得する。メタデータは送信データに付随するデータである。たとえば、送信データが画像データであれば画質、誤り率などがメタデータである。送信データが、センサから得たデータであれば、計測位置、計測時間がメタデータの例である。メタデータは、ＣＡＮなどを介して取得する。取得したメタデータは、送信データに対応付けて優先度バッファ１０２に記憶される。
【０１２３】
データ価値単価決定部７１１は、送信データに対応付けて優先度バッファ１０２に保存されているメタデータ、および、データ価値マップから、優先度バッファ１０２に記憶されている送信データのデータ価値単価を取得する。データ価値マップは記憶部１０３に記憶されている。
【０１２４】
第７実施形態におけるデータ価値マップは、図２２で説明したデータ価値マップにおいて装置状態の列に代えてメタデータの列があるマップである。
【０１２５】
このデータ価値マップを用いてデータ価値単価を決定することで、データ価値単価を動的に変化させることができる。本実施形態でも、たとえば、走行異常検出サービスにおいて、交通流が少なくデータ不足の場所や時間に計測されたセンサデータのデータ価値単価を高くするなどの変更が可能になる。よって、本実施形態でも、送信する価値がより高い送信データを優先して送信することができる。
【０１２６】
＜第８実施形態＞
第８実施形態では、データ価値単価を乱数で決定する。図２４に第８実施形態の無線通信端末８００の構成を示す。第８実施形態の無線通信端末８００の制御部８０４は、データ価値単価決定部８１１の処理が、これまでの実施形態とは相違する。
【０１２７】
データ価値単価決定部８１１は、データ価値単価を乱数により決定する。たとえば、図５に示す処理において、あるデータ種別に対して電源オン後に最初に実行するＳ５では、データ価値単価の初期値として、乱数で生成した値を用いる。
【０１２８】
データ価値単価を乱数により決定することは、ある狭い地域に多数の無線通信端末１００が存在する場合に有効である。同じサービスの同じデータ種別の送信データに対するデータ価値単価が固定値であると、どの無線通信端末１００も送信データを送信しない状況や、反対に、どの無線通信端末１００も送信データを送信する状況が生じやすい。
【０１２９】
しかし、たとえば、道路異常が検出された場所の画像データは、通信品質の要求は高いが、どれか１台の車両２に搭載された無線通信端末１００がその画像データを送信すればよい。
【０１３０】
このような場合に、データ価値単価を乱数で決定することが有効である。したがって、車両２の周囲の予め設定された範囲内に、他の無線通信端末１００が規定数以上存在すると判断できた場合に、データ価値単価を乱数で決定するようにしてもよい。また、データ種別を画像に限定するなど、データ種別を限定して、データ価値単価を乱数で決定してもよい。
【０１３１】
データ価値単価を乱数で決定する場合、その乱数は確率分布に従う乱数とすることができる。確率分布は、たとえば、平均が第１実施形態で説明した固定値となる正規分布とすることができる。平均が第１実施形態で説明した固定値となるようにすれば、全車両２の合計データ価値単価は変えずに、いずれかの無線通信端末１００から送信データが送信される可能性を高くすることができる。
【０１３２】
なお、確率分布の平均を第１実施形態で説明した固定値とすると、固定値を用いた場合よりも、実際に送信される送信データのデータ価値単価の平均は高くなる。そこで、確率分布の平均を、第１実施形態で説明した固定値よりも低くしてもよい。また、分散値を大きくしたり、上限値を設けたりしてもよい。
【０１３３】
＜第９実施形態＞
図２５に第９実施形態の無線通信端末９００の構成を示す。第９実施形態の無線通信端末９００の制御部９０４は、送信価値単価決定部９１２、送信順序制御部９１３、リソース割り当て部９１４の処理が、これまでの実施形態とは相違する。
【０１３４】
前述の実施形態では、ある送信データに対して送信データ価値単価は一度のみ決定していた。しかし、送信データ価値単価を決定してから実際に送信データが送信されるまでに、ある程度の時間がある場合もある。そして、送信データ価値単価を決定してから実際に送信データが送信されるまでに、データ価値単価の加算が可能な送信データが優先度バッファ１０２に格納される可能性がある。
【０１３５】
また、送信データ価値単価を決定してから実際に送信データが送信されるまでに、優先度バッファ１０２に格納されていた送信データが、送信不要になる可能性もある。送信不要になる状況は、データ供給部６などから、送信データの削除要求が供給される場合などに生じる。
【０１３６】
また、データ価値マップが、ユーザや、サービスを実行するアプリケーションからの指示により変更されることも考えられる。
【０１３７】
さらには、ベストエフォート型の送信データは、前述したようにリアルタイム性がｓｏｆｔであり、送信までの時間経過によりデータ価値が低下する。そこで、時間経過に応じて送信データ価値単価を減少させることも考えられる。なお、時間経過に伴う送信データ価値の減少量あるいは減少関数は、サービス毎に定義することができる。
【０１３８】
これらのことを考慮して、送信価値単価決定部９１２は、送信データ価値単価を決定した後も、送信データが送信されるまで送信データ価値単価を逐次再決定する。
【０１３９】
また、送信価値単価決定部９１２は、第２実施形態の送信価値単価決定部２１２と同様、優先度バッファ１０２の同じ優先度クラスに、同じ送信データがある場合、同じ送信データに対するデータ価値単価を加算して送信データ価値単価とする。
【０１４０】
さらに、送信価値単価決定部９１２は、送信データ価値単価の算出に用いたデータ価値単価に対応する送信データの削除要求を、送信データを提供したデータ供給部６から取得した場合には、削除要求のあった送信データのデータ価値単価を減算して、送信データ価値単価を再決定する。
【０１４１】
送信データ価値単価が変更された場合、送信順序制御部９１３は、送信順序を再付与する。リソース割り当て部９１４は、送信順序が変更になった場合には通信リソースを再度割り当てる。
【０１４２】
＜第１０実施形態＞
図２６に第１０実施形態の無線通信端末１０００の構成を示す。第１０実施形態の無線通信端末１０００の制御部１００４は、送信順序制御部１０１３の処理が、これまでの実施形態とは相違する。
【０１４３】
送信順序制御部１０１３は、図２７に示すように、送信閾値ＴＨ１、送信閾値ＴＨ２の２つの送信閾値ＴＨを備える。また、ＴＨ１＞ＴＨ２である。送信データは、送信閾値ＴＨ１、ＴＨ２との大小関係を色の濃さで表している。送信データｄ３１、ｄ７１、ｄ７２の送信データ価値単価は送信閾値ＴＨ１よりも高い。送信データｄ３２、ｄ７３、ｄ７４、ｄ９１の送信データ価値単価は送信閾値Ｔ２よりも高いが、送信閾値ＴＨ１よりは低い。
【０１４４】
送信順序制御部１０１３は、２つの送信閾値ＴＨを値が大きい送信閾値ＴＨから順番に用いて送信順序を付与する。
【０１４５】
図２７の例では、送信閾値ＴＨ１を先に用いる。送信閾値ＴＨ１よりも値が大きい送信データ価値単価は送信データｄ３１、ｄ７１、ｄ７２である。この３つの送信データｄ３１、ｄ７１、ｄ７２のうち、送信データｄ３１の優先度クラスが高い。したがって、送信データｄ３１に、最初に送信順序が付与される。図２７においてＴｎ（ｎ＝１、２，３・・・）は、送信順序を表している。
【０１４６】
送信順序が２番目になる送信データは送信データｄ７１であり、３番目になる送信データは送信データｄ７２である。４番目以降の送信順序となる送信データは、送信閾値ＴＨ１よりも送信データ価値単価が低い送信データになる。具体的には、ｄ３２→ｄ７３→ｄ７４→ｄ９１の順に送信順序が付与される。
【０１４７】
このように２つの送信閾値ＴＨを設けることで、送信データ価値単価が高い送信データの送信順序を早くしやすくなる。なお、送信閾値ＴＨを３つ以上、設けてもよい。
【０１４８】
以上、本発明の実施形態を説明したが、本発明は上述の実施形態に限定されるものではなく、次の変形例も本発明の技術的範囲に含まれ、さらに、下記以外にも要旨を逸脱しない範囲内で種々変更して実施できる。
【０１４９】
＜変形例１＞
送信データを分割する場合はそれぞれの送信データに対してヘッダを付与する必要がある。そのため、分割しない場合に比べると通信容量は増加する。そこで、差集合の要素が少ない場合は分割しないとする判断を行ってもよい。
【０１５０】
＜変形例２＞
前述の実施形態では、上り送信について説明したが、下り送信にも本発明は同様に適用できる。
【符号の説明】
【０１５１】
２：車両（移動装置）  ３：サーバ  ４：基地局  ５：通信回線網  ６：データ供給部  １００、２００、３００、４００、５００、６００、７００、８００、９００、１０００：無線通信端末  １０１：無線通信部  １０２：優先度バッファ  １０３：記憶部  １１０：データ分類部  １１１、６１１、７１１、８１１：データ価値単価決定部  １１２、２１２、３１２、４１２、５１２、９１２：送信価値単価決定部  １１３、９１３、１０１３：送信順序制御部  １１４、９１４：リソース割り当て部  ４１５：包含関係判断部  ４１６、５１６：判定用価値単価算出部  ５１５：導出関係判断部  ６１７：装置状態取得部  ７１７：メタデータ取得部  抽象化度：α
【図１】
2018182430.tif 000004
【図２】
2018182430.tif 000005
【図３】
2018182430.tif 000006
【図４】
2018182430.tif 000007
【図５】
2018182430.tif 000008
【図６】
2018182430.tif 000009
【図７】
2018182430.tif 000010
【図８】
2018182430.tif 000011
【図９】
2018182430.tif 000012
【図１０】
2018182430.tif 000013
【図１１】
2018182430.tif 000014
【図１２】
2018182430.tif 000015
【図１３】
2018182430.tif 000016
【図１４】
2018182430.tif 000017
【図１５】
2018182430.tif 000018
【図１６】
2018182430.tif 000019
【図１７】
2018182430.tif 000020
【図１８】
2018182430.tif 000021
【図１９】
2018182430.tif 000022
【図２０】
2018182430.tif 000023
【図２１】
2018182430.tif 000024
【図２２】
2018182430.tif 000025
【図２３】
2018182430.tif 000026
【図２４】
2018182430.tif 000027
【図２５】
2018182430.tif 000028
【図２６】
2018182430.tif 000029
【図２７】
2018182430.tif 000030