特許 6525323 通信装置及び通信方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6525323

(24)【登録日】2019年5月17日

(45)【発行日】2019年6月5日

(54)【発明の名称】通信装置及び通信方法

(51)【国際特許分類】

   H04W 40/02 20090101AFI20190527BHJP

   H04W 4/38 20180101ALI20190527BHJP

   H04W 28/06 20090101ALI20190527BHJP

   H04W 84/18 20090101ALI20190527BHJP

【ＦＩ】

   H04W40/02 130

   H04W4/38

   H04W40/02 110

   H04W28/06

   H04W84/18 110

【請求項の数】12

【全頁数】16

(21)【出願番号】特願2015-233369(P2015-233369)

(22)【出願日】2015年11月30日

(65)【公開番号】特開2017-17670(P2017-17670A)

(43)【公開日】2017年1月19日

【審査請求日】2018年3月7日

(31)【優先権主張番号】特願2015-131526(P2015-131526)

(32)【優先日】2015年6月30日

(33)【優先権主張国】JP

(73)【特許権者】

【識別番号】000208891

【氏名又は名称】ＫＤＤＩ株式会社

(74)【代理人】

【識別番号】100092772

【弁理士】

【氏名又は名称】阪本 清孝

(74)【代理人】

【識別番号】100119688

【弁理士】

【氏名又は名称】田邉 壽二

(72)【発明者】

【氏名】吉田 将也

(72)【発明者】

【氏名】吉原 貴仁

【審査官】 三枝 保裕

(56)【参考文献】

【文献】 特開２０１６−０３６０７７（ＪＰ，Ａ）

【文献】 国際公開第２０１４／２０８０４５（ＷＯ，Ａ１）

【文献】 特開２００７−２２８０７６（ＪＰ，Ａ）

【文献】 大塚 紘史，ＩｏＴ時代のネットワークに関するシステムインテグレーションからの一考察，電子情報通信学会技術研究報告 Ｖｏｌ．１１４ Ｎｏ．１６３，日本，一般社団法人電子情報通信学会 The Institute of Electronics,Information and Communication Engineers，２０１４年 ７月２４日

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｂ ７／２４− ７／２６

Ｈ０４Ｗ ４／００−９９／００

(57)【特許請求の範囲】

【請求項1】

単一又は複数のセンサとサーバとの間でゲートウェイの役割を果たす通信装置であって、
前記センサからデータを受信するセンサ通信部と、
前記センサから受信したデータを近隣通信装置へと送信するとともに、近隣通信装置から送信されるデータを受信するゲートウェイ通信部と、
前記センサから受信したデータと前記近隣通信装置から受信したデータを前記サーバへ送信するサーバ通信部と、
前記センサから受信したデータを前記ゲートウェイ通信部又は前記サーバ通信部のどちらに出力するかを判定する制御部と、を備え、
前記制御部は、集約要求パケットを近隣通信装置へ送信し、該近隣通信装置が前記集約要求パケットを解析して得た集約承認パケットを基に前記判定を行うとともに、
前記ゲートウェイ通信部は、920MHz帯無線を利用し、前記制御部は920MHz帯無線の送信時間制限を考慮して前記判定を行う
ことを特徴とする通信装置。

【請求項2】

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

【請求項3】

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

【請求項4】

前記集約要求パケットには、集約要求パケット送信元アドレスと前記センサから受信するデータレートを含む請求項２又は請求項３に記載の通信装置。

【請求項5】

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

【請求項6】

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

【請求項7】

前記集約承認パケットには、集約承認パケット送信元アドレスと既にデータを集約しているゲートウェイ数を含む請求項５に記載の通信装置。

【請求項8】

前記近隣通信装置からデータを受信した際に、所定時間受信待機し、所定時間内に受信した複数のデータを集約する請求項１に記載の通信装置。

【請求項9】

複数のデータを集約する際に、データを圧縮してデータサイズを削減する請求項８に記載の通信装置。

【請求項10】

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

【請求項11】

前記各通信装置には、固定回線に接続されたアクセスポイントを含む請求項１０に記載の通信方法。

【請求項12】

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

【発明の詳細な説明】

【技術分野】

【0001】

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

【背景技術】

【0002】

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

【0003】

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

【0004】

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

【0005】

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

【0006】

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

【0007】

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

【0008】

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

【先行技術文献】

【特許文献】

【0009】

【特許文献1】特開２０１４−２０４４３６号公報

【特許文献2】特開２０１２−１００２５９号公報

【非特許文献】

【0010】

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

【発明の概要】

【発明が解決しようとする課題】

【0011】

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

【0012】

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

【0013】

本発明は上記実情に鑑みて提案されたものであり、センサとサーバとの間でゲートウェイの役割を実現するに際して、送信時間制限を考慮してゲートウェイ間でデータを集約することを可能とした通信装置を提供することを目的としている。

【課題を解決するための手段】

【0014】

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

【0017】

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

【0018】

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

【0019】

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

【0020】

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

【0021】

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

【0022】

請求項７は、請求項５の通信装置において、
前記集約承認パケットには、集約承認パケット送信元アドレスと既にデータを集約しているゲートウェイ数を含むことを特徴としている。

【0023】

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

【0024】

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

【0025】

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

【0026】

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

【0027】

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

【発明の効果】

【0028】

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

【0029】

また、制御部におけるゲートウェイ通信部又はサーバ通信部のどちらに出力するかの判定について、集約要求パケット及び集約承認パケットを参考にするので、送信先のゲートウェイの状況を考慮して切り替えを行うことができる。

【0030】

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

【0031】

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

【0032】

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

【0033】

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

【0034】

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

【0035】

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

【0036】

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

【0037】

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

【図面の簡単な説明】

【0038】

【図1】本発明の通信装置の構成を示すブロック図である。

【図2】通信装置の制御部における処理手順を示すフローチャートである。

【図3】複数通信装置を使用し、センサからのデータを各通信装置が受信してサーバへアップロードする通信システムにおいて、データを受信した通信装置が他の通信装置（ゲートウェイ）へ集約要求を送信した状態を示すモデル図である。

【図4】複数通信装置を使用し、センサからのデータを各通信装置が受信してサーバへアップロードする通信システムにおいて、他の通信装置（ゲートウェイ）が集約承認を送信した状態を示すモデル図である。

【図5】複数通信装置を使用し、センサからのデータを各通信装置が受信してサーバへアップロードする通信システムにおいて、920MHz帯を使用してデータ送信宛先を変更した状態を示すモデル図である。

【図6】複数通信装置を使用し、センサからのデータを各通信装置が受信してサーバへアップロードする通信システムにおいて、920MHz帯での送信を停止し、LTEに切り替えた状態を示すモデル図である。

【図7】本発明の通信装置でホップ数の上限を「３」に設定して適用した通信システムでデータを収集する場合のモデル図である。

【図8】本発明の通信装置を使用した通信システムにおいて、電力センサから波形データを収集する場合のモデル図である。

【図9】本発明の通信装置を適用しない通信システムでデータを収集する場合のモデル図である。

【図10】本発明の通信装置を適用した通信システムでデータを収集する場合のモデル図である。

【図11】920MHz帯無線テレメータ用、テレコントロール用及びデータ伝送用無線設備におけるARIB標準規格を示す表である。

【発明を実施するための形態】

【0039】

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

【0040】

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

【0041】

以下、本発明に係る通信装置（ゲートウェイ）の実施形態の一例について、図面を参照して説明する。
通信装置１は、図１のブロック図に示すように、センサ２からデータを取得するセンサ通信部１１と、センサ２から受け取ったデータの送付先を決める制御部１２と、制御部１２から受け取ったデータを近隣ゲートウェイ（通信装置１）へ送信するゲートウェイ通信部１３と、制御部１２から受け取ったデータをサーバ３へ送信するサーバ通信部１４とを備えて構成されている。

【0042】

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

【0043】

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

【0044】

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

【0045】

【数1】

【0046】

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

【0047】

【数2】

【0048】

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

【0049】

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

【0050】

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

【0051】

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

【0052】

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

【0053】

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

【0054】

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

【0055】

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

【0056】

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

【0057】

集約要求パケットには、集約要求送信元アドレスと、データレートa(g)の情報が含まれる。
集約要求送信元アドレスは、集約要求パケットを送信したゲートウェイを一意に特定できるアドレスである。集約要求送信元アドレスとして、サービス固有のアドレスの他、MACアドレス、IPアドレスが利用できる。
データレートa(g)は、ゲートウェイgがセンサから受信する総データレート（bps）である。

【0058】

また、集約要求パケットに、通信経路上でのホップ数の情報を含めてもよい。ホップ数は、集約要求パケットを送信したゲートウェイから、集約要求パケットを受信したゲートウェイまでの通信経路上での中継数である。集約要求パケットを送信したゲートウェイと直接通信するゲートウェイのホップ数を「１」とし、集約要求パケットが転送されるごとに「１」ずつ増加する。

【0059】

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

【0060】

［S3］集約承認受信
近隣ゲートウェイ１が集約要求を受信し、所定の条件を満たした場合、集約承認パケットを通信装置（ゲートウェイ）１Ａへ送信して返答する（図４）。集約承認パケットの送信は[S13]で後述する。集約承認パケットは、現時点で集約している集約ゲートウェイ数と、集約承認送信元アドレスの情報を含む。集約要求パケットにホップ数の情報が含まれる場合は、集約承認パケットにもホップ数の情報が含まれる。
集約ゲートウェイ数は、集約承認パケットを送信したゲートウェイが、送信承認パケットを送信した時点で集約している（データを受信している）ゲートウェイの数である。

【0061】

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

【0062】

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

【0063】

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

【0064】

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

【0065】

［S4］宛先ゲートウェイ設定
通信装置（ゲートウェイ）１Ａが１つの集約承認パケットのみ受信した場合は、集約承認パケットに含まれる集約承認送信元アドレスを宛先として設定する。
通信装置（ゲートウェイ）１Ａが複数の集約承認パケットを受信した場合は、集約承認パケットに含まれる集約ゲートウェイ数を比較し、集約ゲートウェイ数（集約数）が一番大きいゲートウェイを宛先として設定する。前述したように、ゲートウェイ以外に、光通信などの固定回線に接続されたアクセスポイント（ルータ）についても集約先として利用してもよい。
これにより、既により多くのゲートウェイのデータを集約しているゲートウェイに追加してデータを集約することができ、モバイル通信の同時接続数削減効果を高める。
集約ゲートウェイ数が一番大きいゲートウェイが複数ある場合はいずれかのゲートウェイを選択する。この場合、送信時間の増加を防ぐ（詳細は後述する）ために、ホップ数が少ないゲートウェイを選択する。ホップ数も同じ場合、選択するゲートウェイは、ランダム、IDが一番小さい、一番最初に集約承認パケットを受信、などの手段で決めればよい。

【0066】

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

【0067】

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

【0068】

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

【0069】

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

【0070】

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

【0071】

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

【0072】

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

【0073】

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

【0074】

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

【0075】

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

【0076】

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

【0077】

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

【0078】

【数3】

【0079】

集約要求パケットに含まれるa(g)の情報を元にこれらの値を計算し、A(h)＜Cとなる場合のみ、集約条件を満たすと判定し、集約承認パケットを送信する（[S14]）。
また、ホップ数を考慮する場合は、集約要求パケットは複数のゲートウェイを経由（ホップ）して転送される。中継するゲートウェイは920MHz帯無線を用いてデータを中継するため、ホップ数が増加するにつれ、多くのゲートウェイで920MHz帯無線での送信時間が増加する。これにより、920MHz帯無線の送信時間制限に達し、集約ができなくなることを避けるため、集約要求パケットを中継するホップ数に上限を設ける。
すなわち、送信要求パケットに含まれるホップ数が所定値未満の場合のみ集約要求パケットを近隣ゲートウェイへ転送する。
上記所定値は任意に設定するパラメータである。所定値を「１」とした場合、隣接ゲートウェイ（920MHz帯無線を用いて直接通信できるゲートウェイ）のみとデータを集約することとなる。

【0080】

例えば、図７において、ホップ数を考慮してゲートウェイ１Ａが集約要求パケットを送信する例を考える。ホップ数の上限を「３」とした場合、ゲートウェイＡ１が送信した集約要求パケットは、最大でホップ数上限の３ホップ先まで送信される。従って図７の例では、ゲートウェイ１Ｂ，１Ｃ，１Ｄ，１Ｅ，１Ｆ，１Ｇが集約要求パケットを受信することになる。なお、図７中、４は通信装置（ゲートウェイ）１が接続される基地局、６は基地局４に対してモバイル通信で接続されている携帯電話である。
集約要求パケットを受信したゲートウェイ１Ｂ〜１Ｇは、それぞれ自身のアドレス、集約数、ホップ数を含めた集約承認パケットをゲートウェイ１Ａに対し送信する。
ゲートウェイ１Ｂ〜１Ｇから集約承認パケットを受信したゲートウェイ１Ａは、集約承認パケットに含まれる情報から、ゲートウェイ１Ｂ〜１Ｇの中から宛先ゲートウェイを決定することができる。

【0081】

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

【0082】

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

【0083】

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

【0084】

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

【0085】

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

【0086】

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

【符号の説明】

【0087】

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

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】