JP2017103527A - 通信装置及び通信方法 - Google Patents

Abstract

【課題】センサとサーバとの間でゲートウェイの役割を実現するに際して、送信時間制限を考慮してゲートウェイ間でデータを集約し、ゲートウェイによるモバイル通信への同時接続数の削減を図るとともに、混雑している基地局に接続されたゲートウェイが集約先ゲートウェイとして選択されることを回避する。【解決手段】センサ２とサーバ３との間でゲートウェイの役割を果たす通信装置１であって、前記センサ２からデータを受信するセンサ通信部１１と、センサ２から受信したデータをゲートウェイ通信部１３又はサーバ通信部１４のどちらに出力するかを判定する制御部１２とを備え、前記制御部１２は、集約要求パケットを近隣通信装置へ送信し、該近隣通信装置が基地局から取得したモバイル通信の混雑情報及び前記集約要求パケットを解析して得た集約承認パケットを基に前記判定を行う。【選択図】図１

Description

本発明は、ゲートウェイの役割を果たす通信装置に関し、詳しくは、センサ等の機器から受信したデータを複数のゲートウェイ間で通信して集約することで、LTE等のモバイル通信の同時接続数の削減を目的とする通信装置及び通信方法に関する。

機器同士が通信し所望の処理を行うシステムとして、M2M（Machine to Machine Communication）やIoT（Internet of Things）が存在する。これらのシステムは、自販機の在庫管理や農場の監視、ビルマネジメント、スマートメータなど、幅広い分野で活用されている。

上述のシステムにおいては、センサ等の機器からネットワークを通じてデータを収集するため、通信機能を備えたゲートウェイが利用される。センサ等の機器は、有線接続の他、Wi-Fi、Bluetooth(登録商標)等ローカル無線でゲートウェイに接続され、ゲートウェイへデータを送信する。ゲートウェイは、FTTH等の固定回線、4G(LTE)や3G等のモバイル通信を介してインターネットに接続され、センサ等の機器から受信したデータをサーバ等へ送信する。モバイル通信は、回線工事等の手間がなく設置が容易であり、M2M/IoT向けのモバイル通信モジュールが各社より提供されている。近年では、ソフトウェアで高度な制御が可能な高機能ゲートウェイも登場している。

ところで、近年M2M/IoT分野へ920MHz帯無線が適用されている。920MHz帯は免許不要の周波数帯である。920MHz帯の無線規格として、IEEE802.15.4/4g（Zigbee(登録商標)920/Wi-SUN）、IEEE802.11ah等があり、Wi-SUNはスマートメータへ応用されている。通信距離が数百ｍ程度であることから、各家庭間に設置されたスマートメータ間の通信にも適している。

一方、920MHz帯の利用について、ARIB標準規格「920MHz帯テレメータ用、テレコントロール用及びデータ伝送用無線設備」（ARIB STD-T108）にて規定されている。同規格では、図１２の表に示されるように、920MHz帯の送信時間制限について、１時間あたりの送信時間総和は360秒以下であることが規定されている。

特許文献１では、M2Mネットワークにおいて、パケット配信の信頼性の改善、送信遅延の低減を目的とし、ノード間の通信の衝突を最小化するようにノードをクラスタリングする方法を提供している。各ノードの残りエネルギーの割合等の情報をもとにノードがクラスタヘッドになる能力（CHC）を決定し、CHCが高いノードほどクラスタヘッドとして選択される確率が高くなるようにノードをクラスタリングする。大域パラメータを用いずに各ノードで分散的に制御する。

特許文献２では、無線ネットワークのエネルギー消費を低減するとともに、ネットワークのロバスト性、信頼性、実時間性能を改善する無線装置と制御方法を提供している。複数のサブノードは集約ノードへとデータを集約する。サブノードにはランダムなスリープ時間が設定されることでエネルギー消費量を低減する。集約ノードはサブノードの状態をモニタする。サブノードがアクティブの場合はサブノードからデータを取得し、サブノードがスリープの場合は所定のアルゴリズムに従ってサブノードのデータを推定する。

非特許文献１では、スマートグリッドの普及に伴い、電力使用情報等の多量の小規模データによって通信ネットワークに多大な負荷がかかるのに備え、データを集約・圧縮する技術を提供している。ゲートウェイに集約されたデータを解析し、時間的類似性と空間的類似性の高いメタデータを有する複数のセンサからのデータを時空間ブロックで集約することでメタデータ情報量の削減を実現する。

LTE等のモバイル通信では、無線リソースの同時接続数に制限があるため、データ送信完了後一定時間経過すると無線リソースを開放する。モバイル通信を用いてデータを送信するゲートウェイが、無線リソースを開放するまでの時間よりも短い間隔でデータを送信する場合、無線リソースを開放せず、同時接続数を圧迫するという課題があった。

従来技術（特許文献１、特許文献２、非特許文献１）では、複数のノード（ゲートウェイ）のデータを１つのノードに集約して送信することで、同時接続数を削減する。この際、データを集約するために920MHz帯無線を利用することが考えられる。
しかしながら、従来技術では、前述の920MHz無線における１時間あたりの送信時間総和の制限が考慮されておらず、この送信時間制限によってゲートウェイ間でデータを集約できない場合があるという課題があった。

そこで、本発明者らは、ゲートウェイによるLTE等のモバイル通信の同時接続数を削減するため、複数のゲートウェイ間で920MHz帯無線を用いてデータを集約する技術を提案した（特許文献３）。この技術によれば、前述の920MHz帯無線における１時間あたりの送信時間総和の制限を考慮し、各ゲートウェイの920MHz帯無線での送信時間に応じて集約先ゲートウェイを決定する。また、より多くのゲートウェイのデータを集約できるよう、既に多くのゲートウェイのデータを集約しているゲートウェイを優先的に集約先ゲートウェイとして選択する。

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

多数のセンサによる時空間センシングデータの効率的な集約送信技術（大阪大学、KDDI）

本発明者らが特許文献３に提案した技術では、各ゲートウェイの920MHz帯無線での送信時間に応じて集約先のゲートウェイを決定し、複数のゲートウェイのデータを一つのゲートウェイに集約するようになっている。そのため、LTE等のモバイル通信の同時接続数は削減されるが、駅前や繁華街など、携帯電話等によるモバイル通信の接続数が多い基地局に接続されたゲートウェイが集約先として選択される場合がある。この場合、接続数が多い基地局に接続された携帯電話等によるモバイル通信において、通信劣化が発生するという懸念があった。

本発明は上記実情に鑑みて提案されたものであり、センサとサーバとの間でゲートウェイの役割を実現するに際して、送信時間制限を考慮してゲートウェイ間でデータを集約することを可能とするとともに、混雑している（例えば、モバイル通信の接続数が多い）基地局に接続されたゲートウェイが集約先ゲートウェイとして選択されることを回避する通信装置及び通信方法を提供することを目的としている。

上記目的を達成するため請求項１の発明は、単一又は複数のセンサとサーバとの間でゲートウェイの役割を果たす通信装置であって、次の構成を含む。
前記センサからデータを受信するセンサ通信部。
前記センサから受信したデータを近隣通信装置へと送信するとともに、近隣通信装置から送信されるデータを受信するゲートウェイ通信部。
前記センサから受信したデータと前記近隣通信装置から受信したデータを前記サーバへ送信するサーバ通信部。
前記センサから受信したデータを前記ゲートウェイ通信部又は前記サーバ通信部のどちらに出力するかを判定する制御部。
そして、前記制御部は、集約要求パケットを近隣通信装置へ送信し、該近隣通信装置が基地局から取得したモバイル通信の混雑情報及び前記集約要求パケットを解析して得た集約承認パケットを基に前記判定を行うことを特徴としている。

請求項２は、請求項１の通信装置において、
前記ゲートウェイ通信部は、920MHz帯無線を利用し、前記制御部は920MHz帯無線の送信時間制限を考慮して前記判定を行うことを特徴としている。

請求項３は、請求項２の通信装置において、
前記ゲートウェイ通信部は、920MHz帯無線での送信時間の総和が、920MHz帯の送信時間制限を超えない場合に、集約要求パケットを前記近隣通信装置に送信することを特徴としている。

請求項４は、請求項２の通信装置において、
前記ゲートウェイ通信部は、920MHz帯無線での送信時間の総和が、920MHz帯の送信時間制限を超えない場合で、且つ、所定の時間が経過した場合に、集約要求パケットを近隣通信装置に送信することを特徴としている。

請求項５は、請求項１の通信装置において、
前記集約要求パケットには、集約要求パケット送信元アドレスと前記センサから受信するデータレートを含むことを特徴としている。

請求項６は、請求項１の通信装置において、
前記集約要求パケットには、通信経路上でのホップ数を含み、前記判定は前記ホップ数を考慮する請求項１に記載の通信装置。

請求項７は、請求項６の通信装置において、
前記ホップ数が所定値以下の場合に集約要求パケットを送信することを特徴としている。

請求項８は、請求項１の通信装置において、
前記制御部は、モバイル通信の混雑情報として、基地局から所定時間間隔でLTE接続数を取得することを特徴としている。

請求項９は、請求項６の通信装置において、
前記制御部は、モバイル通信の混雑情報として、基地局から所定時間間隔でLTE接続数を取得することを特徴としている。

請求項１０は、請求項８又は請求項９の通信装置において、
前記LTE接続数は、前記所定時間間隔の平均接続数とすることを特徴としている。

請求項１１は、請求項１又は請求項６の通信装置において、
前記制御部は、モバイル通信の混雑情報として、基地局から所定時間間隔でトラフィック量を取得することを特徴としている。

請求項１２は、請求項１１の通信装置において、
前記トラフィック量は、前記所定時間間隔の平均トラフィック量とすることを特徴としている。

請求項１３は、請求項１の通信装置において、
前記集約要求パケットを受信した際に、前記センサから受信するデータレートと、前記近隣通信装置から受信するデータレートの合計が、前記サーバ通信部で送信可能なデータレート以下になる場合に前記集約承認パケットを返信することを特徴としている。

請求項１４は、請求項９の通信装置において、
前記集約承認パケットには、集約承認パケット送信元アドレスと既にデータを集約しているゲートウェイ数、ホップ数、基地局から取得したモバイル通信の混雑情報を含むことを特徴としている。

請求項１５は、請求項１３の通信装置において、
前記集約承認パケットを送信した近隣通信装置を集約先ゲートウェイとして選択することを特徴としている。

請求項１４は、請求項１４の通信装置において、
通信装置が前記集約承認パケットを複数受信した場合は、集約承認パケットに含まれるホップ数、集約承認パケットに含まれる集約ゲートウェイ数、集約承認パケットに含まれる基地局のLTE接続数に応じて、集約先ゲートウェイを選択することを特徴としている。

請求項１７は、請求項１６の通信装置において、
前記集約先ゲートウェイの選択に際して、集約承認パケットに含まれる基地局のLTE接続数が所定値以下、集約承認パケットに含まれる集約ゲートウェイ数が最大、集約承認パケットに含まれるホップ数が最小、の順に判定して集約先ゲートウェイを決定することを特徴としている。

請求項１８は、請求項１６の通信装置において、
前記集約承認パケットに含まれる基地局のLTE接続数がいずれも所定値よりも大きい場合は、この条件を無視し、集約承認パケットに含まれる集約ゲートウェイ数が最大、集約承認パケットに含まれるホップ数が最小、の順に判定して集約先ゲートウェイを決定することを特徴としている。

請求項１９は、請求項１の通信装置において、
前記近隣通信装置からデータを受信した際に、所定時間受信待機し、所定時間内に受信した複数のデータを集約することを特徴としている。

請求項２０は、請求項１９の通信装置において、
複数のデータを集約する際に、データを圧縮してデータサイズを削減することを特徴としている。

請求項２１は、単一又は複数のセンサからデータを受信しサーバへアップロードする複数の通信装置間で行われる通信方法であって、
前記各通信装置は前記センサと前記サーバとの間でゲートウェイの役割を果たすとともに、
前記センサからのデータを受信した一つの通信装置は、920MHz帯無線での送信時間の総和が920MHz帯の送信時間制限を超えない場合に、前記データを集約する集約要求パケットを他の通信装置へ送信し、
前記他の通信装置は、前記センサから受信するデータレートと、近隣通信装置から受信するデータレートの合計が、前記通信装置間で送信可能なデータレート以下になる場合に、前記一つの通信装置へ集約承認パケットを返信し、
前記一つの通信装置は、集約承認パケットに含まれる既に集約しているゲートウェイ数及び前記他の通信装置が接続される基地局の混雑状況を考慮してデータを集約する通信装置を決定し、該通信装置へ前記920MHz帯無線で前記データを出力し、前記基地局におけるモバイル通信の混雑状況を考慮して前記データを集約する通信装置がアップロードする
ことを特徴としている。

請求項２２は、請求項２１の通信方法において、
前記各通信装置には、固定回線に接続されたアクセスポイントを含むことを特徴としている。

請求項２３は、請求項２２の通信方法において、
通信装置がアクセスポイントである場合、実際の集約数に所定値を加算した値を集約数として集約承認パケットを返信することを特徴としている。

請求項１の通信装置及び請求項２１の通信方法によれば、センサから受信したデータをゲートウェイ通信部又はサーバ通信部のどちらに出力するかを制御部が判定することで、データの送信先をサーバからゲートウェイに切り替え、当該ゲートウェイからサーバへ纏めて（ゲートウェイ間でデータを集約して）送信することで、ゲートウェイによるモバイル通信への同時接続数を削減することができる。
その際、モバイル通信の基地局の混雑状況を考慮してデータを集約するゲートウェイを選択するので、携帯電話等によりモバイル通信が混雑している基地局に接続されたゲートウェイが集約先として選択されることを回避することができる。

請求項２〜４によれば、１時間に360秒を超えての送信ができないという920MHz帯無線の特徴を考慮して判定を行うことができる。

請求項５によれば、集約要求パケット送信元アドレスとセンサから受信するデータレートを考慮して制御部での判定を行うことができる。

請求項６によれば、通信経路上でのホップ数を考慮して制御部での判定を行うことができる。

請求項７によれば、ホップ数を考慮して集約要求パケットの送信先を限定し、集約先に適したゲートウェイのみに集約承認パケットを要求することができる。

請求項８乃至請求項１０によれば、基地局に接続されているLTE接続数で基地局の混雑状況を考慮して制御部で判定を行うことができる。

請求項１１及び請求項１２によれば、トラフィック量により基地局の混雑状況を考慮して制御部で判定を行うことができる。

請求項１３によれば、集約要求パケット送信元アドレスとセンサから受信するデータレートを考慮して制御部での判定を行うことができる。

請求項１４によれば、集約承認パケットに、既にデータを集約しているゲートウェイ数、ホップ数、基地局のLTE接続数を考慮して制御部での判定を行うことができる。

請求項１５によれば、請求項１３で集約承認パケットを返信したゲートウェイを集約先ゲートウェイに選択することができる。

請求項１６によれば、集約承認パケットに含まれるホップ数、集約ゲートウェイ数及びLTE接続数に応じて、集約先ゲートウェイを選択させることができる。

請求項１７によれば、集約先ゲートウェイを決定するに際して、集約承認パケットに含まれるホップ数、集約ゲートウェイ数及びLTE接続数における優先順位を決めることができる。

請求項１８によれば、前記集約承認パケットに含まれるLTE接続数がいずれも所定値よりも大きい場合は、この条件を無視し、集約ゲートウェイ数とホップ数で集約先ゲートウェイを決定することができる。

請求項１９によれば、所定時間内に受信した複数のデータを集約することで集約の効率化を図ることができる。

請求項２０によれば、データを圧縮してデータサイズを削減することで、集約の効率化を図ることができる。

請求項２２によれば、アクセスポイントを集約先ゲートウェイに選択することができる。

請求項２３によれば、アクセスポイントを集約先ゲートウェイに選択し易くすることができる。

本発明の通信装置の構成を示すブロック図である。 本発明の通信装置を適用した通信システムにおいて基地局の混雑状況（想定環境）を説明するためモデル図である。 通信装置の制御部における処理手順を示すフローチャートである。 複数通信装置を使用し、センサからのデータを各通信装置が受信してサーバへアップロードする通信システムにおいて、データを受信した通信装置が他の通信装置（ゲートウェイ）へ集約要求を送信した状態を示すモデル図である。 複数通信装置を使用し、センサからのデータを各通信装置が受信してサーバへアップロードする通信システムにおいて、他の通信装置（ゲートウェイ）が集約承認を送信した状態を示すモデル図である。 複数通信装置を使用し、センサからのデータを各通信装置が受信してサーバへアップロードする通信システムにおいて、920MHz帯を使用してデータ送信宛先を変更した状態を示すモデル図である。 複数通信装置を使用し、センサからのデータを各通信装置が受信してサーバへアップロードする通信システムにおいて、920MHz帯での送信を停止し、LTEに切り替えた状態を示すモデル図である。 本発明の通信装置を使用した通信システムにおいて、電力センサから波形データを収集する場合のモデル図である。 本発明の通信装置を適用しない通信システムでデータを収集する場合のモデル図である。 本発明の通信装置を適用した通信システムでデータを収集する場合のモデル図である。 本発明の通信装置で接続数の上限を「３」、ホップ数の上限を「３」に設定して適用した通信システムでデータを収集する場合のモデル図である。 920MHz帯無線テレメータ用、テレコントロール用及びデータ伝送用無線設備におけるARIB標準規格を示す表である。

本発明の通信装置は、M2M/IoTの普及を想定して複数台設置し、各通信装置がセンサとサーバとの間でゲートウェイの役割を果たす環境下での使用を前提としている。M2M/IoT分野では、免許不要な920MHz帯無線が適用されているので、通信装置（ゲートウェイ）間を920MHz帯無線で通信することで、通信装置に接続されたセンサから受信したデータを最適な通信装置に集約し、この通信装置からサーバへデータを送信することで、サーバ・通信装置間のモバイル通信における同時接続数の削減を目的とする。

ゲートウェイの例としては、ホームゲートウェイ等のゲートウェイ用に開発された装置の他、ルータやスイッチ等のネットワーク機器、ArduinoやRaspberryPi等の汎用開発ボード、スマートフォンやPC等の情報端末が挙げられる。

以下、本発明に係る通信装置（ゲートウェイ）の実施形態の一例について、図面を参照して説明する。
通信装置１は、図１のブロック図に示すように、センサ２からデータを取得するセンサ通信部１１と、センサ２から受け取ったデータの送付先を決める制御部１２と、制御部１２から受け取ったデータを近隣ゲートウェイ（通信装置１）へ送信するゲートウェイ通信部１３と、制御部１２から受け取ったデータをサーバ３へ送信するサーバ通信部１４とを備えて構成されている。
制御部１２は、当該通信装置１が接続される基地局での混雑状況を把握するため、所定時間間隔で基地局４からモバイル通信に関する混雑情報を取得する。モバイル通信の混雑情報は、例えば、LTE接続数やトラフィック量とする。また、基地局４から取得するLTE接続数は、例えば、所定時間間隔内における平均接続数であり、トラフィック量は、例えば、所定時間間隔内における平均トラフィック量である。

センサ通信部１１は、センサ２と通信することでデータを受信し、制御部１２へデータを出力する。センサ通信部１１とセンサ２との接続には、シリアルケーブルやUSBケーブル等の有線接続の他、Wi-FiやBluetooth(登録商標)等のローカル無線通信を用いる。センサ通信部１１と接続し各種のデータを送信するセンサ２は、1つでも良いし複数でも良い。

センサ２は、通信装置１とは別の装置として動作しても良いし、通信装置１の一部として組み込まれていても良い。センサ２の例としては、温度センサ、電力センサ、カメラ等が挙げられる。

センシングされるデータの種類やサイズはセンサ２の種類によって異なる。例えば、ゲートウェイgにS個のセンサが接続され、センサsのデータレートをd(s)（bps）で表すものとすると、ゲートウェイgがセンサ通信部１１を介して受信する総データレートa(g)（bps）は数１で表される。

例えば、S=3（個）のセンサ２が通信装置（ゲートウェイ）１に接続され、各センサ２が10秒に1回100bitのデータをゲートウェイgに送信するとする。このとき、各センサ２のデータレートは100/10=10(bps)であり、ゲートウェイgの総データデートa(g)は数２で計算される。

制御部１２は、センサ２から受信したデータをゲートウェイ通信部１３へ出力するかサーバ通信部１４へ出力するかを判定する。また、制御部１２は、必要に応じて他の通信装置（ゲートウェイ）１が取得したデータを受信する。
判定は、集約要求パケットを近隣通信装置１へ送信し、近隣通信装置１が集約要求パケットを解析して送信した集約承認パケットを基に行われる。その際に、920MHz帯無線の送信時間制限（１時間に360秒を超えて送信できないこと）や、近隣通信装置１側における総データレートが閾値を超えないこと、等を考慮して判定が行なわれる。判定処理の詳細手順については、図３のフローチャートを用いて後述する。

ゲートウェイ通信部１３は、制御部１２から受け取ったデータについて920MHz帯無線を用いて近隣ゲートウェイ（通信装置１）へ送信する。また、近隣ゲートウェイ（通信装置１）から送信されるデータを受信する。

サーバ通信部１４は、制御部１２から受け取ったデータ（近隣ゲートウェイから受信したデータを含む）をLTE等のモバイル通信を用いてサーバ３へ送信する。

したがって上述した通信装置１によれば、センサ２から受信したデータをゲートウェイ通信部１３又はサーバ通信部１４のどちらに出力するかを制御部１２が判定することで、データの送信先をサーバ２から近隣通信装置１（ゲートウェイ）に切り替え、当該ゲートウェイからサーバ２へ纏めて送信、すなわちゲートウェイ間でデータを集約して送信することで、通信装置（ゲートウェイ）１によるモバイル通信への同時接続数を削減することができる。

データの集約に際しては、混雑している基地局に接続された近隣通信装置（ゲートウェイ）が集約先ゲートウェイとして選択されることを回避する。
例えば図２に示すように、各基地局４に複数の通信装置（ゲートウェイ）１や携帯電話６が接続されている場合を想定する。
この例では、基地局４に１個の通信装置（ゲートウェイ）１及び３個の携帯電話６がLTE接続（LTE接続数４）されている中央上のセル（混雑度：高）、基地局４に１個の通信装置（ゲートウェイ）１及び２個の携帯電話６がLTE接続（LTE接続数３）されている左下のセル（混雑度：中）、基地局４に１個の通信装置（ゲートウェイ）１及び１個の携帯電話６がLTE接続（LTE接続数２）されている右下のセル（混雑度：低）が存在している。
この場合、通信装置１Ａのデータの送信先を決めるに際して、LTE接続数の上限が３に設定されている場合、中央上のセル、左下のセルはLTE接続数が上限である「３」以上であるので、右下のセル（混雑度：低）の基地局４に接続されている通信装置（ゲートウェイ）１Ｄが集約先ゲートウェイとして選択される。選択処理の詳細手順については、図３のフローチャートを用いて後述する。

次に、制御部１２における詳細処理について、図３のフローチャート及び図４〜図７のモデル図を参照して説明する。
通信システムは、複数の通信装置１を使用し、センサ２からのデータを各通信装置１が受信してサーバ３へアップロードするよう構成されている。通信システムにおいては、通信装置1同士の通信は920MHz帯無線（例えばWi-SUN）が用いられ、通信装置１とセンサ２間の通信はローカル無線通信（例えばWi-Fi）が用いられ、通信装置１とサーバ３２間の通信はモバイル通信（例えばLTE）がそれぞれ用いられている。

また、通信装置（ゲートウェイ）１以外に、光通信などの固定回線に接続されたアクセスポイント（ルータ）５についても集約先として利用する。この場合、アクセスポイント（ルータ）５において、通信装置（ゲートウェイ）１との間を920MHz帯無線で通信可能に設定されている。
アクセスポイント５を利用することで、固定回線に接続されたアクセスポイント５にデータを送信し、固定回線を介してサーバ３へデータを送信することが可能となり、LTE等のモバイル通信の同時接続数を削減できる。

先ず、センサ２からデータを取得する通信装置（ゲートウェイ）１Ａ（アドレス192.168.10.12）の制御部１２における処理手順について説明する。

［S1］起動
通信装置（ゲートウェイ）１Ａを電源に接続し起動する。

［S2］集約要求送信
次に、通信装置（ゲートウェイ）１Ａが他の通信装置（ゲートウェイ）１へ集約要求を送信する（図４）。
すなわち、通信装置（ゲートウェイ）１Ａのゲートウェイ通信部（920MHz帯無線）１３を用いてセンサ２のデータを近隣ゲートウェイ１へと集約するため、近隣ゲートウェイ１に対して集約要求パケットを起動から一定時間経過後にブロードキャストする。
図４では、通信装置１Ａ（アドレス192.168.10.12）が、近隣の３つのゲートウェイ１（アドレス192.168.10.10）,（アドレス192.168.10.11），（アドレス192.168.10.13）及びアクセスポイント５（アドレス192.168.10.14）に対して集約要求パケットを送付する。
なお、この状態では、通信装置（ゲートウェイ）１Ａのセンサ２が取得したデータは、モバイル通信（LTE）を用いてサーバ３へ送信されている。

集約要求パケットには、集約要求送信元アドレスと、データレートa(g)、経由数であるホップ数の情報が含まれる。
集約要求送信元アドレスは、集約要求パケットを送信したゲートウェイを一意に特定できるアドレスである。集約要求送信元アドレスとして、サービス固有のアドレスの他、MACアドレス、IPアドレスが利用できる。
データレートa(g)は、ゲートウェイgがセンサから受信する総データレート（bps）である。
ホップ数は、集約要求パケットを送信したゲートウェイから、集約要求パケットを受信したゲートウェイまでの通信経路上での中継数である。集約要求パケットを送信したゲートウェイと直接通信するゲートウェイのホップ数を「１」とし、集約要求パケットが転送（後述する[S16]）されるごとに「１」ずつ増加する。

集約要求パケットを受信した際の動作は[S11][S12]で後述する。

［S3］集約承認受信
近隣ゲートウェイ１が集約要求を受信し、所定の条件を満たした場合、集約承認パケットを通信装置（ゲートウェイ）１Ａへ送信して返答する（図５）。集約承認パケットの送信は[S13]で後述する。集約承認パケットは、現時点で集約している集約ゲートウェイ数、集約承認送信元アドレスの情報、ホップ数、基地局でのモバイル通信の混雑情報（LTE接続数やトラフィック量）を含む。

集約ゲートウェイ数は、集約承認パケットを送信したゲートウェイが、送信承認パケットを送信した時点で集約している（データを受信している）ゲートウェイの数である。
集約承認送信元アドレスは、集約承認パケットを送信したゲートウェイを一意に特定できるアドレスである。集約承認送信元アドレスとして、サービス固有のアドレスの他、MACアドレス、IPアドレスが利用できる。

ホップ数は、[S2]で前述のとおり、集約要求パケットを送信したゲートウェイから、集約要求パケットを受信したゲートウェイまでのホップ数である。
基地局でのLTE接続数は、基地局に対し携帯電話やゲートウェイ等がモバイル通信で接続している数である。接続数の取得については[S19][S20]で後述する。

集約要求パケットはブロードキャスト送信するため、通信装置（ゲートウェイ）１Ａが複数のゲートウェイから集約承認パケットを受信することがある。この際、集約要求パケットを受信した複数のゲートウェイから集約承認パケットが送信され、衝突が起こる可能性が考えられる。920MHz帯無線であるIEEE802.15.4/4eやIEEE802.11ahでは、MAC層の衝突回避を提供しているため、これを用いて衝突を回避する。

通信装置（ゲートウェイ）１Ａが少なくとも1つの集約承認パケットを受信した場合は、ゲートウェイ通信部（920MHz帯無線）を用いてデータを近隣ゲートウェイに送信するため、後述する[S4]でデータ送信先を当該近隣ゲートウェイに設定する（図６）。図６の場合、モバイル通信（LTE）を用いたサーバ３への送信から、宛先をアクセスポイント５（アドレス192.168.10.14）へ変更した920MHz帯無線（Wi-SUN）による送信に切り替える。

一方、通信装置（ゲートウェイ）１Ａが集約承認パケットをひとつも受信しなかった場合は、サーバ通信部（モバイル通信）１４を用いてデータをサーバ３へ送信するため、後述する[S5]でデータ送信先をサーバ３へ設定する。

［S4］宛先ゲートウェイ設定
通信装置（ゲートウェイ）１Ａが１つの集約承認パケットのみ受信した場合は、集約承認パケットに含まれる集約承認送信元アドレスを宛先として設定する。
通信装置（ゲートウェイ）１Ａが複数の集約承認パケットを受信した場合は、以下のイ．ロ．ハの順に従い、アクセスポイントも含まれる宛先ゲートウェイ（集約先ゲートウェイ）を決定する。
イ．集約承認パケットに含まれる基地局接続数が所定値より小さい
ロ．集約承認パケットに含まれる集約ゲートウェイ数が最大
ハ．集約承認パケットに含まれるホップ数が最小
上記イにより、駅前や繁華街など、携帯電話等によるモバイル通信の接続数が多いエリアに設置されたゲートウェイが集約先として選択されることが回避される。
上記イにおける所定値は、任意に設定するパラメータである。モバイル基地局のLTE接続数の上限は基地局の製品ごとに異なるが、おおよそ数百台程度である。この値を用いて、所定値を（基地局の接続数上限の８０％）などに設定すればよい。
集約承認パケットに含まれる集約ゲートウェイ数がいずれも所定値より大きい場合（いずれのゲートウェイも携帯電話等によるモバイル通信の接続数が多いエリアに設置されている場合）は、上記ロ，ハのみに従い宛先ゲートウェイを決定する。
上記ロにより、既により多くのゲートウェイのデータを集約しているゲートウェイに追加してデータを集約することができ、モバイル通信の同時接続数の削減効果を高めることができる。
上記イ．ロ．ハについて、同じ条件のゲートウェイが複数ある場合は、ランダム、IDが一番小さい、最初に集約承認パケットを受信、などの手段で集約先ゲートウェイを決めればよい。

アクセスポイントが選択可能な環境下である場合、アクセスポイントを優先的に集約先として選択するため、集約要求パケットを受信したアクセスポイントは、実際の集約数に大きい値（100などの固定値）を足した値を集約承認パケットに含める集約数として、集約承認パケットを返信すればよい。これにより、[S4]で集約先を選択する際に、アクセスポイントが宛先（集約先）として選択され易くなる。
また、アクセスポイントであることを明示する方法としては、集約承認パケットにアクセスポイントであるかないかのフラグを設定し、このフラグにより優先的に選択し易くするようにしてもよい。

［S5］宛先サーバ設定
通信装置（ゲートウェイ）１Ａが集約承認パケットをひとつも受信しなかった場合、データを収集するサーバ３を宛先として設定する。サーバ３のアドレス等は、事前にわかっている、あるいはDNS等により取得できるものとする。
なお、データの収集先は、便宜上サーバとしているが、PCやスマホ、M2Mプラットフォームなどでも良い。

［S6］センサからデータ受信
通信装置（ゲートウェイ）１Ａのセンサ通信部１１を通じ、センサ２からデータを受信する。受信した場合は [S4]または[S5]で設定した宛先にデータを送信する（[S17]）。

［S7］ゲートウェイからデータ受信
通信装置（ゲートウェイ）１Ａのゲートウェイ通信部１３を通じ、近隣ゲートウェイからデータを受信する。受信したデータをメモリ等の記憶領域に保持し、所定時間w受信待機する。受信待機中に更に近隣ゲートウェイからデータを受信した場合は、記憶領域に追加する。

受信待機中に、センサからデータを受信した場合（[S8]）、または、受信待機時間wが経過した場合（[S9]）に、受信待機を終了する。
受信待機時間wは、任意に設定するパラメータである。受信待機時間wを0に設定することで、近隣ゲートウェイからデータを受信後、直ちにサーバへとデータを送信することができる。受信待機時間wを大きくすることで、データ集約の機会を増加させる。

［S10］データを複数受信
[S7][S8]にて複数のデータを受信した場合、受信したデータを集約する。
ひとつのデータのみ受信した場合は、受信したデータを送信する（[S17]）。

［S11］データ集約
受信した複数のデータを集約する。複数のデータを集約する方法としては、複数の送信元アドレスと複数のデータをまとめて、一つのパケットとする方法が挙げられる。複数のパケットをひとつのパケットにまとめることで、ヘッダサイズの削減によるトラフィック削減効果が期待できる。

また、複数のデータを圧縮する方法が考えられる。複数のデータを圧縮することで、データサイズを削減し、トラフィック削減効果が期待できる。
いずれも、サーバ側には、受信した一つのパケットを複数のゲートウェイからの複数のデータとして解釈する仕組みが必要になる。
サーバ側にこのような仕組みを組み込めない場合は、受信したデータを集約せず、そのままサーバ３へ送信すれば良い。その場合、上記のようなトラフィック削減効果は得られないが、当初の目的である同時接続数削減の効果は得ることができる。

一般的に、M2M/IoTのデータサイズは、スマートフォン等のデータサイズと比較して小さいことが多い。M2M/IoT用のゲートウェイに対し、スマートフォン等と同等の帯域が割り当てられた場合、過剰に割り当てられた帯域が無駄となることがある。データを集約することで、この帯域の無駄を削減する効果も期待される。

［S12］集約要求受信
近隣ゲートウェイが送信した集約要求パケットを受信する。受信した場合は[S13]で後述の通り、集約条件を満たすか判定する。

［S13］集約条件を満たす場合
より多くのゲートウェイでデータを集約するほど、同時接続数削減の効果は大きくなる。しかしながら、LTE等のモバイル通信の帯域には制約があり、一定時間に送信できるデータ量には限界がある。この限界を超えて近隣ゲートウェイからデータを受信、集約した場合、すべてのデータをサーバ３へ送信しきれなくなる。
そこで、モバイル通信で送信可能なデータレートCと、センサ２や近隣ゲートウェイから受信するデータレートを比較し、集約要求パケットを送信したゲートウェイのデータを受信・集約可能かを判断する。

ここで、G個の近隣ゲートウェイからデータを受信し、ゲートウェイhが送信する総データレートA(h)（bps）は次の数３で表される

集約要求パケットに含まれるa(g)の情報を元にこれらの値を計算し、A(h)＜Cとなる場合のみ、集約条件を満たすと判定し、集約承認パケットを送信する（[S14]）。

［S15］
集約要求パケットは複数のゲートウェイを経由（ホップ）して転送される。中継するゲートウェイは920MHz帯無線を用いてデータを中継するため、ホップ数が増加するにつれ、多くのゲートウェイで920MHz帯無線での送信時間が増加する。これにより、920MHz帯無線の送信時間制限に達し、集約ができなくなることを避けるため、集約要求パケットを中継するホップ数に上限を設ける。
すなわち、送信要求パケットに含まれるホップ数が所定値未満の場合のみ集約要求パケットを近隣ゲートウェイへ転送する（[S16]）。
上記所定値は任意に設定するパラメータである。所定値を「1」とした場合、隣接ゲートウェイ（920MHz帯無線を用いて直接通信できるゲートウェイ）のみとデータを集約することとなる。

［S18］総送信時間が所定値以上
上述したように、920MHz帯無線は1時間に360秒を超えての送信ができないという制約がある。そこで、[S17]でデータを送信後、これまでの920MHz帯での総送信時間を計算し、所定値以上であれば、宛先をサーバに設定（[S5]）し、920MHz帯無線（Wi-SUN）による送信を停止してモバイル通信(LTE)での送信に切り替える（図７）。前記所定値は設定可能なパラメータとし、360-α（秒）（αはマージン）のように設定すればよい。

[S19]前回基地局接続数取得から所定時間経過
[S4]で述べたように、モバイル通信基地局への接続数が少ないゲートウェイを集約先ゲートウェイとして決定する。ゲートウェイは自身が接続しているゲートウェイの接続数を知る必要があるため、ゲートウェイは所定時間経過ごとに（所定時間間隔で）モバイル通信を通じて基地局から接続数を取得する（[S20]）。
携帯電話等のモバイル端末は常時基地局に接続しているとは限らず、また移動するため、基地局への接続数は時間に応じて変化する。そこで、取得する基地局の接続数は所定時間間隔での平均接続数とすればよい。これにより、一時的な接続数の増減による影響を抑えることができる。平均接続数の他、最大接続数や、取得時の接続数としてもよい。

上記所定時間は任意に設定するパラメータである。１時間ごとに基地局の接続数を取得するなど、固定値としてもよい。短時間で接続数が変化する基地局（携帯電話を持った人の増減が多いエリアに設置された基地局など）は短い時間を設定するなど、動的に設定してもよい。
基地局で接続数を管理していない場合は、モバイル通信を介して任意のサーバ等から接続数を取得してもよい。

［S21］集約要求送信条件を満たす
920MHz帯無線は1時間に360秒を超えての送信ができないという制約がある。そこで、「920MHz帯での送信時間の総和が所定値以下」かつ「前回集約要求送信から所定時間tが経過」を集約要求送信条件とし、これを満たす場合のみ集約要求を送信する（[S2]）。

これにより、920Mhz帯無線の制約の範囲内で、ゲートウェイ間でデータを集約する。
所定時間tは設定可能なパラメータである。tを無限大に設定することで、集約するゲートウェイを変更しないよう設定できる。前記所定値は設定可能なパラメータとし、360-α（秒）（αはマージン）のように設定すればよい。

続いて、センサとサーバとの間でゲートウェイの役割を果たす複数の通信装置を使用してデータを収集する場合の具体例について、図８〜図１０を参照しながら説明する。
収集するデータとしては、例えば図８に示すように、家庭に備えられた電力センサから10秒に1回波形データを取得し、ゲートウェイ（通信装置１）を介してサーバ３へアップロードする例を考える。
ゲートウェイ（通信装置１）は、Wi-Fiモジュールと、LTEモジュール、Wi-SUNモジュールを搭載している。電力センサ２とゲートウェイ１はWi-Fiで接続されている。電力センサ２から受信したデータはLTEを用いてサーバ３へ送信される。LTEは30秒通信が行われなかった場合にのみ無線リソースを開放するものとする。

本発明の通信装置を適用しない通信システムでデータを収集する例を図９に示す。六角形のエリア（f1,f2,f3）はLTEのセルを表す。それぞれのセルに、図８に示したゲートウェイ3台ずつが設置されている。本発明の通信装置を適用しない場合、各ゲートウェイがLTEを介してサーバへデータを送信する。各々10秒に1回データを送信するため、いずれも無線リソースは開放されない。すなわち、各セルにおいて常時「３」接続が確立されている状態となるため、LTEを利用するスマートフォンやモバイルルータの接続数を圧迫する可能性がある。

一方、本発明の通信装置を適用した通信システムでデータを収集する例を図１０に示す。LTEのセルサイズはおおよそ1-3km程度である。Wi-SUNの通信距離は数百m程度であるため、セル内にゲートウェイ間で十分通信できると言える。同一のセルに設置された３つのゲートウェイのデータを集約する。これにより、LTEの各セルにおける同時接続数を削減する。この時、各ゲートウェイが上記のシーケンスにしたがって動作することで、920MHz帯無線の送信時間の制約の範囲内でデータを集約することが可能となる。

続いて、本発明の特徴部分である集約先ゲートウェイの決定の仕方について、図１１を参照して説明する。図１１において、ゲートウェイ１Ａが集約要求パケットを送信する例を考える。基地局の接続数の上限は「３」，ホップ数の上限は「３」とする。
ゲートウェイＡ１が送信した集約要求パケットは、最大でホップ数上限の３ホップ先まで送信される。従ってこの例では、ゲートウェイ１Ｂ，１Ｃ，１Ｄ，１Ｅ，１Ｆ，１Ｇが集約要求パケットを受信する。
集約要求パケットを受信したゲートウェイ１Ｂ〜１Ｇは、それぞれ自身のアドレス、集約数、基地局におけるLTE接続数、ホップ数を含めた集約承認パケットをゲートウェイ１Ａに対し送信する。
ゲートウェイ１Ｂ〜１Ｇから集約承認パケットを受信したゲートウェイ１Ａは、集約承認パケットに含まれる情報から、宛先ゲートウェイを決定する。

この例では、図１１に示すように、左上セルはLTE接続数４で混雑度が高、左下セルはLTE接続数３で混雑度が中、右下セルはLTE接続数４で混雑度が高、右上セルはLTE接続数２で混雑度が低、となっている。ゲートウェイ１Ｂ〜１Ｆが接続している各基地局４のLTE接続数は、「３」又は「４」である。これは、基地局の接続数上限の「３」以上である（[S4]の１を満たさない）ため、ゲートウェイ１Ｂ〜１Ｆは集約先ゲートウェイとして選択されない。
一方、ゲートウェイ１Ｇが接続する基地局４の接続数は「２」（接続数の上限「３」より少ない）かつ、ホップ数は「２」（ホップ数の上限「３」より少ない）であるため、ゲートウェイ１Ａは、ゲートウェイ１Ｇを集約先ゲートウェイとして宛先に設定し、920MHz帯無線を用いてデータを送信する。ゲートウェイ１Ｇは、ゲートウェイ１Ａから受信したデータを集約し、モバイル通信を通じてサーバへ送信する。これにより、ゲートウェイ１Ａによるモバイル通信接続が削減される。

上述した通信方法によれば、920Mhz帯無線の送信時間制限と、基地局におけるモバイル通信の混雑状況（LTE接続数やトラフィック量）を考慮して集約先ゲートウェイを決定し、ゲートウェイ間でデータを集約することで、モバイル通信の接続数が多い基地局に接続されたゲートウェイが集約先ゲートウェイとして選択されることを回避しつつ、ゲートウェイによるモバイル通信への同時接続数を削減することができる。

１…通信装置（ゲートウェイ）、 ２…センサ、 ３…サーバ、 ４…基地局、 ５…アクセスポイント、 ６…携帯電話、 １１…センサ通信部、 １２…制御部、 １３…ゲートウェイ通信部、 １４…サーバ通信部。

Claims (23)

1. 単一又は複数のセンサとサーバとの間でゲートウェイの役割を果たす通信装置であって、
   前記センサからデータを受信するセンサ通信部と、
   前記センサから受信したデータを近隣通信装置へと送信するとともに、近隣通信装置から送信されるデータを受信するゲートウェイ通信部と、
   前記センサから受信したデータと前記近隣通信装置から受信したデータを前記サーバへ送信するサーバ通信部と、
   前記センサから受信したデータを前記ゲートウェイ通信部又は前記サーバ通信部のどちらに出力するかを判定する制御部とを備え、
   前記制御部は、集約要求パケットを近隣通信装置へ送信し、該近隣通信装置が基地局から取得したモバイル通信の混雑情報及び前記集約要求パケットを解析して得た集約承認パケットを基に前記判定を行う
   ことを特徴とする通信装置。
2. 前記ゲートウェイ通信部は、920MHz帯無線を利用し、前記制御部は920MHz帯無線の送信時間制限を考慮して前記判定を行う請求項１に記載の通信装置。
3. 前記ゲートウェイ通信部は、920MHz帯無線での送信時間の総和が、920MHz帯の送信時間制限を超えない場合に、集約要求パケットを前記近隣通信装置に送信する請求項２に記載の通信装置。
4. 前記ゲートウェイ通信部は、920MHz帯無線での送信時間の総和が、920MHz帯の送信時間制限を超えない場合で、且つ、所定の時間が経過した場合に、集約要求パケットを近隣通信装置に送信する請求項２に記載の通信装置。
5. 前記集約要求パケットには、集約要求パケット送信元アドレスと前記センサから受信するデータレートを含む請求項１に記載の通信装置。
6. 前記集約要求パケットには、通信経路上でのホップ数を含み、前記判定は前記ホップ数を考慮する請求項１に記載の通信装置。
7. 前記ホップ数が所定値以下の場合に集約要求パケットを送信する請求項６に記載の通信装置。
8. 前記制御部は、モバイル通信の混雑情報として、基地局から所定時間間隔でLTE接続数を取得する請求項１に記載の通信装置。
9. 前記制御部は、モバイル通信の混雑情報として、基地局から所定時間間隔でLTE接続数を取得する請求項６に記載の通信装置。
10. 前記LTE接続数は、前記所定時間間隔の平均接続数とする請求項８又は請求項９に記載の通信装置。
11. 前記制御部は、モバイル通信の混雑情報として、基地局から所定時間間隔でトラフィック量を取得する請求項１又は請求項６に記載の通信装置。
12. 前記トラフィック量は、前記所定時間間隔の平均トラフィック量とする請求項１１に記載の通信装置。
13. 前記集約要求パケットを受信した際に、前記センサから受信するデータレートと、前記近隣通信装置から受信するデータレートの合計が、前記サーバ通信部で送信可能なデータレート以下になる場合に前記集約承認パケットを返信する請求項１に記載の通信装置。
14. 前記集約承認パケットには、集約承認パケット送信元アドレスと既にデータを集約しているゲートウェイ数、ホップ数、基地局のLTE接続数を含む請求項９に記載の通信装置。
15. 前記集約承認パケットを送信した近隣通信装置を集約先ゲートウェイとして選択する請求項１３に記載の通信装置。
16. 通信装置が前記集約承認パケットを複数受信した場合は、集約承認パケットに含まれるホップ数、集約承認パケットに含まれる集約ゲートウェイ数、集約承認パケットに含まれる基地局のLTE接続数に応じて、集約先ゲートウェイを選択する請求項１４に記載の通信装置。
17. 前記集約先ゲートウェイの選択に際して、集約承認パケットに含まれる基地局のLTE接続数が所定値以下、集約承認パケットに含まれる集約ゲートウェイ数が最大、集約承認パケットに含まれるホップ数が最小、の順に判定して集約先ゲートウェイを決定する請求項１６に記載の通信装置。
18. 前記集約承認パケットに含まれる基地局のLTE接続数がいずれも所定値よりも大きい場合は、この条件を無視し、集約承認パケットに含まれる基地局のLTE接続数が最大、集約承認パケットに含まれるホップ数が最小、の順に判定して集約先ゲートウェイを決定する請求項１６に記載の通信装置。
19. 前記近隣通信装置からデータを受信した際に、所定時間受信待機し、所定時間内に受信した複数のデータを集約する請求項１に記載の通信装置。
20. 複数のデータを集約する際に、データを圧縮してデータサイズを削減する請求項１９に記載の通信装置。
21. 単一又は複数のセンサからデータを受信しサーバへアップロードする複数の通信装置間で行われる通信方法であって、
    前記各通信装置は前記センサと前記サーバとの間でゲートウェイの役割を果たすとともに、
    前記センサからのデータを受信した一つの通信装置は、920MHz帯無線での送信時間の総和が920MHz帯の送信時間制限を超えない場合に、前記データを集約する集約要求パケットを他の通信装置へ送信し、
    前記他の通信装置は、前記センサから受信するデータレートと、近隣通信装置から受信するデータレートの合計が、前記通信装置間で送信可能なデータレート以下になる場合に、前記一つの通信装置へ集約承認パケットを返信し、
    前記一つの通信装置は、集約承認パケットに含まれる既に集約しているゲートウェイ数及び前記他の通信装置が接続される基地局の混雑状況を考慮してデータを集約する通信装置を決定し、該通信装置へ前記920MHz帯無線で前記データを出力し、前記基地局におけるモバイル通信の混雑状況を考慮して前記データを集約する通信装置がアップロードする
    ことを特徴とする通信方法。
22. 前記各通信装置には、固定回線に接続されたアクセスポイントを含む請求項２１に記載の通信方法。
23. 通信装置がアクセスポイントである場合、実際の集約数に所定値を加算した値を集約数として集約承認パケットを返信する請求項２２に記載の通信方法。