(58)【調査した分野】(Int.Cl.,DB名)
【発明を実施するための形態】
【0014】
はじめに本発明の一実施形態の概要について図面を参照して説明する。なお、この概要に付記した図面参照符号は、理解を助けるための一例として各要素に便宜上付記したものであり、本発明を図示の態様に限定することを意図するものではない。また、以降の説明で参照する図面等のブロック間の接続線は、双方向及び単方向の双方を含む。一方向矢印については、主たる信号(データ)の流れを模式的に示すものであり、双方向性を排除するものではない。
【0015】
本発明は、その一実施形態において、
図1に示すように、情報収集手段11と、優先度決定手段12と、サービス提供手段13と、を備えるサーバ10にて実現できる。より具体的には、情報収集手段11は、モバイルネットワーク30に接続し、サービス提供対象となる端末20に関する情報を収集する。優先度決定手段12は、前記情報収集手段11にて収集された前記端末20に関する情報に基づいて、前記端末20に提供するサービスの優先度を決定する。サービス提供手段13は、前記優先度決定手段12にて決定された優先度に従って、前記サービスに対応するアプリケーションを動作させ、前記端末20にサービスを提供する。
【0016】
例えば、
図2に示すように、モバイルネットワーク30に接続し、サービス提供対象となる端末20の種類が、車載端末(自動車車載型機器)と、スマートフォンの2種類であったとする。この場合、優先度決定手段12は、情報収集手段11にて収集された情報に基づいて、端末20に提供するサービスのうち、車載端末(自動車車載型機器)向けと、スマートフォン向けのサービスの優先度を他のサービスより相対的に高くする。
【0017】
サービス提供手段13は、前記優先度決定手段12にて決定された優先度に従って、車載端末(自動車車載型機器)向けと、スマートフォン向けのサービスに対応するアプリケーションを動作させ、サービスを提供する。これにより、端末へのサービスの提供主体となるサーバにおけるアプリケーションの動作を最適化させることができる。
【0018】
なお、サービス提供手段13における優先度の利用形態としては、優先度の高いアプリケーションの起動、メモリへの常駐や優先度の低いアプリケーションの終了が考えられる。優先度の利用形態としては、これらに限られず、例えば、優先度の高いアプリケーションに割り当てるCPU(Central Processing Unit)やメモリの量を多くする等の割り当てリソース量の増減制御を行ってもよい。
【0019】
情報収集手段11が収集する情報も端末の種類に限られない。例えば、情報収集手段11が端末の送受信データ量や、データの送信形態(データ送信頻度、1回あたりとのデータ送信量)を収集することとしてもよい。送受信データ量や、データの送信形態(データ送信頻度、1回あたりとのデータ送信量)に基づいて、端末の種別や端末が利用するであろうサービスを推定し、サービスの優先度を決定することもできる。
【0020】
[第1の実施形態]
続いて、本発明の第1の実施形態について図面を参照して詳細に説明する。
図3は、本発明の第1の実施形態のモバイルエッジコンピューティングシステムの構成を示す図である。
図3を参照すると、基地局1と、端末2と、MEC(モバイルエッジコンピューティング)サーバ3と、コアネットワーク4と、インターネット5と、監視装置6とを含む構成が示されている。
【0021】
MECサーバ3は、端末2へのサービスの提供や端末2の制御、端末2と情報を授受するためのアプリケーションを搭載し、監視装置6から得た情報を用いて端末2にサービスを提供する。このようなMECサーバ3は、コアネットワーク4に配置した独立したサーバであってもよいが、基地局1内に実装することもできる。
【0022】
コアネットワーク4は、基地局1からの信号を送受信し、端末2をインターネット5に接続するためのスイッチやパケット交換機能等を持つサーバで構成される。
【0023】
監視装置6は、基地局1を監視する装置である。具体的には、監視装置6は、基地局1からのアラームを蓄積・表示する機能や、パフォーマンスモニタデータを収集、蓄積、表示し、コアネットワーク4へ転送する機能や、基地局1のファイル版数の管理や更新を制御する機能を有している。また、監視装置6は、基地局1が収集するパフォーマンスデータを、必要に応じて、または周期的にMECサーバ3へ報告する機能を有している。本実施形態では、このパフォーマンスデータがMECサーバ3においてアプリケーションの優先度決定に使用される。
【0024】
なお、基地局1、端末2、インターネット5は当事者によく知られているので説明は割愛する。なお、
図3の例では、端末2としてスマートフォンを図示しているが、端末2はスマートフォンや携帯電話(フィーチャーフォン)に限られない。例えば、
図1の符号20に示されているように、車載端末、無線アクセスポイント、自動販売機、監視カメラ、無人航空機(ドローン)、スマートメータ等、IoTデバイスと呼ばれる種々のものが想定される。
【0025】
続いて、本実施形態のMECサーバ3について説明する。
図4は、本発明の第1の実施形態のMECサーバ3の構成を示す図である。
図4を参照すると、MECサーバ3と、監視装置6とを接続した構成が示されている。
【0026】
監視装置6は、基地局1が収集するパフォーマンスモニタデータをMECサーバ3に送信する。監視装置6によるパフォーマンスモニタデータの送信は、プッシュ型、プル型の双方が考えられる。例えば、監視装置6が、MECサーバ3からデータ要求を受信したタイミングでパフォーマンスモニタデータを送信することとしてもよい。また、監視装置6が、予め決められた周期で、MECサーバ3へパフォーマンスモニタデータを送信することとしてもよい。
【0027】
MECサーバ3は、情報収集部31と、制御部32と、アプリケーションプログラムを格納する記憶部33と、端末情報記憶部34と、優先度記憶部35と備えている。
【0028】
情報収集部31は、MECサーバ3と監視装置6との間のパフォーマンスデータをやりとりするインターフェースを司る上記した情報収集手段に相当する。具体的には、情報収集部31は、監視装置6からパフォーマンスモニタデータを周期的に受信したり、監視装置6に対しパフォーマンスモニタデータを要求し、受信する機能を持つ。さらに、本実施形態の情報収集部31は、監視装置6から取得したパフォーマンスモニタデータをMECサーバ3内で扱いやすい形式に変換し、端末情報記憶部34に保存する機能、送信エラー時の再送やデータフォーマットのチェック等を行う機能を有している。
【0029】
図5は、端末情報記憶部34に保存される端末情報の一例を示す図である。情報収集部31は、パフォーマンスモニタデータを、
図5のようなMECサーバ3内で扱いやすい形式の端末情報に変換する。基地局1が周期的に収集し、監視装置6が取りまとめたパフォーマンスモニタデータそのものは、パフォーマンスに関するすべてのデータが入っており、MECサーバ3におけるアプリケーション優先度の決定に必要のないデータも多い。そこで、情報収集部31は、パフォーマンスモニタデータを、MECサーバ3が扱いやすい形式に編集する。
図5の例では、Cell IDで特定される基地局毎に、提供中のサービスと、接続している端末2の種類が登録されている。また、それぞれの端末種別毎に、カウンタIDで特定されるカウンタ種別のカウンタデータが格納される。なお、パフォーマンスモニタデータのデータ収集項目は、オペレータ(携帯キャリア)により異なるが、
図5の例では、セル配下に存在している端末の数や呼処理の各パラメータの数、基地局そのもののCPU使用率やメモリ等の装置ハードウェアの性能項目等の一般的な項目を収集している(
図8参照)。
【0030】
図6は、
図5のサービスIDフィールドに設定されるIDとその内容の例を示すテーブルである。
図6の例では、自動車安全運転支援サービスは、車載端末向けの運転支援アプリケーションによって実現される。盗難・犯罪監視サービスは、通信機能付き監視カメラ向けの犯罪情報等の情報提供アプリケーションによって実現される。自動販売機サービスは、通信機能付き自動販売機向けのリアルタイム管理アプリケーションによって実現される。料金メータ計測サービスは、スマートメータ向けのリアルタイム計測アプリケーションによって実現される。料金メータ計測サービスは、スマートメータ向けのリアルタイム計測アプリケーションによって実現される。社会インフラ監視サービスは、路面センサ向けの交通量計測アプリケーションによって実現される。もちろん、サービスの例は、
図6に示した例に限られず、記憶部33に保持されたアプリケーションにより提供されるさまざまなサービスに対応付けて登録される。
【0031】
図7は、
図5の端末種別IDフィールドに設定されるIDとその内容の例を示すテーブルである。
図7の例では、スマートフォン、フィーチャフォン、路面センサ、自動販売機、スマートメータ、自動車車載型機器、監視カメラが登録されている。もちろん、端末種別の例は、
図7に示した例に限られず、基地局1に接続してサービスの提供対象となりうる端末種別が追加される。
【0032】
図8は、
図5のカウンタIDフィールドに設定されるIDとその内容(監視項目)の例を示すテーブルである。
図8の例では、発呼数、成功したハンドオーバ回数(HO回数(成功))、失敗したハンドオーバ回数(HO回数(失敗))、CPU使用率、メモリ使用率が登録されている。もちろん、これら監視項目は、
図8に示した例に限られず、パフォーマンスモニタデータやその他監視装置6が入手可能な測定項目を選択することができる。
【0033】
記憶部33には、端末2の機能や端末2の種類毎に、さまざまなサービスに対応するアプリケーションが格納される(
図6参照)。それぞれのアプリケーションは、端末2等と情報をやりとりしたり、端末へ指示信号を送信したりする機能を有している。
【0034】
制御部32は、端末情報記憶部34に設定された情報に基づいて、端末20に提供するサービスに対応するアプリケーションの優先度を決定し、優先度記憶部35を更新する。また、制御部32は、優先度記憶部35に設定された優先度に基づいて、記憶部33からアプリケーションを読み出して動作させる。従って、本実施形態の制御部32が、上記した、優先度決定手段12とサービス提供手段13に対応することになる。
【0035】
図9は、本発明の第1の実施形態のMECサーバ3が保持する優先度情報を格納するテーブルの一例を示す図である。
図9の例では、MECサーバ3で提供可能なアプリケーション(サービスID)毎に、優先度が設定されている。
図9の例では、優先度は−20から19までの値を持ち、最優先のアプリケーションに−20が設定される(これは、Linux(登録商標)のNiceコマンドで取りうるNI値に準じた値となっている。)。また、この優先度の値は、初期値としては、同じ優先度(例えば、「0」)に設定されているが、基地局配下のセルに接続されている端末の種類に偏りがあり、あるいくつかの特定の種類の端末やサービスが集中していることが、監視装置6から送られてくるパフォーマンスモニタデータにより判明した場合に、優先度を上げる(値を減らす)処理が行われる。また例えば、基地局配下の端末の数は少なくても、重要なサービス(例えば監視カメラによる盗難犯罪抑止機能)については優先度を上げる(値を減らす)処理が行われる。また、
図9のアプリケーション種別は、
図6のサービスIDと一対一で対応している。また、
図9の例では「固定フラグ」フィールドが設けられている。このフラグがオンのとき(
図9ではNo.02と、No.05に“ON”が付与されている)、そのアプリケーションは優先度を変更されることはない。従って、
図9の例では、サービスID=02の通信機能付き監視カメラ向けの犯罪情報等の情報提供アプリケーションが最も高い優先度を持つことになる。また、この通信機能付き監視カメラ向けの犯罪情報等の情報提供アプリケーションは、固定フラグが“ON”になっているので、基本的に優先度は変更されない。また、
図9の例では、サービスID=01の自動車安全運転支援サービスを提供する運転支援アプリケーションが次に高い優先度を持つことになる。また、この運転支援アプリケーションは、固定フラグがオフになっているので、上記端末情報に基づいた優先度の変更が行われる。
【0036】
続いて、本実施形態の動作について図面を参照して詳細に説明する。
図10は、本発明の第1の実施形態の動作(情報収集処理)を表したシーケンス図である。まず、MECサーバ3内の情報収集部31は、監視装置6から定期的(例えば5分毎)に、基地局1が収集するパフォーマンスモニタデータを入手する(ステップS001)。なお、パフォーマンスモニタデータの入手方法としては、FTP(File Transfer Protocol)用いて転送を受ける方法やデータコピー等の任意の方法が考えられる。
【0037】
次に、情報収集部31は、入手したパフォーマンスモニタデータのフォーマットをチェックする(ステップS002)。前記チェックの結果、パフォーマンスモニタデータのフォーマットに問題がなければ、情報収集部31は、パフォーマンスモニタデータを
図5に示す端末情報に変換して、端末情報記憶部34に登録されているデータの更新を行う(ステップS003)。一方、パフォーマンスモニタデータのフォーマットに問題があった場合、情報収集部31は、監視装置6にパフォーマンスモニタデータの再送を要求する(ステップS005)。これを受けた監視装置6は、再送準備をして(ステップS006)、再度パフォーマンスモニタデータを送信する。
【0038】
ステップS003にて、端末情報記憶部34のデータ更新が完了すると、情報収集部31は、制御部32に、端末情報記憶部34のデータが更新されたことを通知する(ステップS004)。なお、入手したパフォーマンスモニタデータは、MECサーバ3に一定期間保存した後、記憶装置の容量を確保するため削除する(ステップS007)。
【0039】
続いて、情報収集部31から端末情報の更新通知を受けた制御部32の動作について図面を参照して詳細に説明する。
図11は、本発明の第1の実施形態の動作(優先度変更処理)を表したシーケンス図である。
図11を参照すると、まず、制御部32は、情報収集部31からデータ更新通知を受信すると(ステップS101)、制御部32は、端末情報記憶部34から、最新の端末情報を読み出して参照する(ステップS102)。
【0040】
制御部32は、読み出した端末情報に基づいて、アプリケーションの優先度を決定し、優先度記憶部35の優先度テーブルの内容を更新する(ステップS103)。例えば、
図5の端末情報が得られている場合、制御部32は、カウンタID=1の発呼数が上位のCell ID=001のエントリに注目する。エントリNo.001のサービスIDは01であることから、制御部32は、
図9のサービスID=アプリケーション種別01(自動車安全運転支援)の優先度を上げる(他と比べて上位=マイナス値を増やす)。
【0041】
なお前述したように、盗難や犯罪防止に関わる監視カメラに関してのアプリケーションや、路上の振動や温度等を検知する路面センサ等のアプリケーションである場合、発呼数に関係なく、他と比べて優先度を上位に設定しておき、固定とする方法でもよい。その際は、
図9の固定フラグをONとし、システムパラメータとして予め設定しておく。
【0042】
前記優先度の変更後、制御部32は優先度テーブルの内容に従って、アプリケーションの優先度を変更する(ステップS104)。アプリケーションの優先度を変更する方法としては、種々の方法を採ることができるが、例えば、制御部32が、OS(Operating System)のコマンドを用いて優先度を変更する方法を採ることができる。もちろん、前述のとおり、各アプリケーションに割り当てるリソースを変更する方法も採用可能である。
【0043】
なお、
図4のMECサーバ3における制御部32及び情報収集部31は、MECサーバ3上で動作するアプリケーションと、これらを実行するプロセッサで実現されるが、本実施形態では、優先度の変更対象となるアプリケーションをMECサーバ3上のアプリケーションと区別して表記している。また、制御部32及び情報収集部31の優先度は、他のアプリケーションよりも高く設定される。これにより、他のアプリケーションの動作が、制御部32及び情報収集部31によるパフォーマンスデータの受信や蓄積動作及びアプリケーションの優先度を制御する処理に影響しないようにすることができる。
【0044】
以上説明したように、本実施形態によれば、MECサーバ3において、各種の端末2のために用意されているさまざまなアプリケーションのすべてを起動させておく必要はなくなる。換言すれば、ある時点で重要なサービスや頻度の高いサービスに対応するアプリケーションを優先して動作させておけばよく、MECサーバ3のリソースを有効に活用することが可能となる。
【0045】
以上、本発明の各実施形態を説明したが、本発明は、上記した実施形態に限定されるものではなく、本発明の基本的技術的思想を逸脱しない範囲で、更なる変形・置換・調整を加えることができる。例えば、各図面に示したネットワーク構成、各要素の構成、メッセージの表現形態は、本発明の理解を助けるための一例であり、これらの図面に示した構成に限定されるものではない。
【0046】
例えば、上記した実施形態では、パフォーマンスモニタデータに含まれる発呼数に注目して優先度を上げる例を説明したが、その他のカウンタ値に基づいて優先度を上げたり、下げたりすることもできる。例えば、車載端末のHO回数(成功)が多い場合、当該エリアでの車載端末の移動が活発であることを示している。これに伴い、利用度が高くなることが予想される自動車安全運転支援アプリケーションの優先度を上げることができる。また、逆に、車載端末のHO回数(成功)が少ない場合、当該エリアでの車載端末の移動が少ないことを示している。これに伴い、利用度が低くなることが予想される自動車安全運転支援アプリケーションの優先度を下げることができる。また、
図5の複数のカウンタ値の組み合わせが特定の条件を満たしているかや、ある基地局において端末から利用されているサービスの組み合わせにより、アプリケーションの優先度を変更することもできる。
【0047】
例えば、上記した実施形態では、監視装置6が基地局から得たパフォーマンスモニタデータを用いて優先度を変更するものとして説明したが、端末情報として、基地局1や監視装置6が独自に収集する情報を用いることもできる。
【0048】
例えば、上記した実施形態では、重要度の高いアプリケーションについて固定フラグをONにして、優先度の変更を行わないものとして説明したが、逆に、重要度の低いアプリケーションや、応答性が求められないアプリケーションについて優先度を低く設定し、固定フラグを立ててもよい。
【0049】
また、上記した実施形態では、アプリケーションの実行主体はMECサーバ3であるものとして説明したが、アプリケーションの実行主体はMECサーバ3でなくてもよい。例えば、コアネットワーク4やインターネット5やクラウド基盤(図示省略)に配置されている別のサービス提供サーバにおけるアプリケーションの優先度を変更することもできる。これにより、当該別のサーバにおけるアプリケーションの動作を最適化することができる。また、サーバは物理的に独立したサーバに限定されるものではなく、コアネットワーク4やクラウド基盤(図示省略)上で動作する仮想サーバであってもよい。
【0050】
また、上記した実施形態では、監視装置6がMECサーバ3に、定期的に(例えば5分毎)、パフォーマンスモニタデータを送信するものとして説明したが、パフォーマンスモニタデータの送信の送信周期は可変でもよい。または、MECサーバ3が、監視装置6にパフォーマンスモニタデータの送信を要求し、監視装置6は、MECサーバ3からの要求受信を契機に、パフォーマンスモニタデータの送信を行うものとしてもよい。その場合はMECサーバ3内部に、監視装置6へパフォーマンスモニタデータの送信を要求する仕組みを設けることになる。
【0051】
最後に、本発明の好ましい形態を要約する。
[第1の形態]
(上記第1の視点によるサーバ参照)
[第2の形態]
上記したサーバは、優先度の決定の際に参照する端末に関する情報として、端末の種類情報を用いることができる。
[第3の形態]
上記したサーバは、優先度の決定の際に参照する端末に関する情報として、前記端末の動作状態を示す情報(CPU使用率、メモリ使用率等)を用いることができる。
[第4の形態]
上記したサーバは、優先度の決定の際に参照する端末に関する情報として、前記端末の前記モバイルネットワークに属する基地局から取得したパフォーマンスモニタデータから選択した情報を用いることができる。
[第5の形態]
上記したサーバは、前記端末に関する情報に基づいて、利用度の高いサービスの優先度を、他のサービスの優先度よりも高くすることができる。
[第6の形態]
上記したサーバは、前記端末に関する情報に基づいて、重要度の高いサービスの優先度を、他のサービスの優先度よりも高くすることができる。
[第7の形態]
上記したサーバは、前記優先度に基づいて、前記サービスに対応するアプリケーションを起動するか否かを決定することができる。
[第8の形態]
上記したサーバは、前記優先度に基づいて、前記サービスに対応するアプリケーションに割り当てるリソース量を増減することができる。
[第9の形態]
上記したサーバのサービス提供手段は、優先度を固定するフラグが設定されているアプリケーションについて、優先度の変更を行わない構成を採ることができる。
[第10の形態]
(上記第2の視点によるサービス提供システム参照)
[第11の形態]
(上記第3の視点によるサービス提供方法参照)
[第12の形態]
(上記第4の視点によるプログラム参照)
なお、上記第10〜第12の形態は、第1の形態と同様に、第2〜第9の形態に展開することが可能である。
【0052】
なお、上記の特許文献の開示を、本書に引用をもって繰り込むものとする。本発明の全開示(請求の範囲を含む)の枠内において、さらにその基本的技術思想に基づいて、実施形態ないし実施例の変更・調整が可能である。また、本発明の開示の枠内において種々の開示要素(各請求項の各要素、各実施形態ないし実施例の各要素、各図面の各要素等を含む)の多様な組み合わせ、ないし選択が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。特に、本書に記載した数値範囲については、当該範囲内に含まれる任意の数値ないし小範囲が、別段の記載のない場合でも具体的に記載されているものと解釈されるべきである。