JP6494535B2

JP6494535B2 - 近距離無線ネットワークの輻輳に応じて広域無線ネットワークへの制御信号を抑制する無線ゲートウェイ、プログラム及び方法

Info

Publication number: JP6494535B2
Application number: JP2016000293A
Authority: JP
Inventors: 大輔荒井; 智彦大岸
Original assignee: KDDI Corp
Current assignee: KDDI Corp
Priority date: 2016-01-04
Filing date: 2016-01-04
Publication date: 2019-04-03
Anticipated expiration: 2036-01-04
Also published as: JP2017123508A

Description

本発明は、広域無線ネットワークへ発信する制御信号（シグナリング）の輻輳を抑制する技術に関する。

近年、ＩｏＴ(Internet of Things)／Ｍ２Ｍ(Machine-to-Machine)デバイスを用いた通信サービスが普及してきている。大量に分散設置されたＩｏＴ／Ｍ２Ｍデバイスは、自動的に、比較的小容量の情報パケットを頻繁に発信する。この点で、ユーザによって操作されるスマートフォンや携帯電話機のように、データをバースト的に送受信する通信とは異なる。そのために、モバイルネットワークとしてのＬＴＥ(Long Term Evolution)網に対する、端末やデバイスから発生するシグナリングのトラヒックパターンも変化してきている。

従来、制御信号のトラヒック量が増加する原因として、端末にインストールされたアプリケーションが、サーバプッシュ機能（例えばメッセージの着信確認におけるリアルタイム的通信）を実現するために、定期的にネットワークに接続することがある。これに対し、アプリケーション毎に実現しているサーバプッシュ機能を集約し、制御信号のトラヒック量を削減する技術がある（例えば非特許文献１参照）。但し、多数の端末からネットワークへの接続のタイミングが同期することによって発生する制御信号スパイクを、直接的に防ぐことは難しい。

また、多数の端末間で同時に発生するネットワーク接続のタイミングをずらすことを目的とした、アプリケーション開発者向けガイドラインも策定されている（例えば非特許文献２参照）。但し、大量に存在する全てのアプリケーションが、ガイドラインに従うことは現実的に困難である。

更に、ハードウェアベースの通信制御方式ＮＳＲＭ(Network Socket Request Management)によってネットワーク接続を時間的に集約し、接続回数を削減することによって、制御信号のトラヒック量を削減する技術もある（例えば非特許文献３参照）。この技術によれば、端末の通信インタフェースを制御するチップに実装され、バックグランド状態（ユーザが操作していない状態）の時間（例えば１０分間のうちの１分間）でのみ、アプリケーションに対して通信を許可する（例えば非特許文献４参照）。ＮＳＲＭをハードウェアベースで実装した場合、例えば１０分間のうち１分間のみ通信を許可するなど、長時間に渡って通信を制限するという問題もある。

一方で、ユーザ操作中の通信に対して、端末が制御信号スパイクの抑制通信制御を実行した場合、ユーザの体感品質の劣化が懸念される。そのために、抑制通信制御は、バックグランド状態に限って実行するのが好ましい。

更に、端末毎にネットワーク接続のタイミングを分散させるべく、一時的な送信キューを備える技術もある（例えば非特許文献４及び特許文献１参照）。この技術によれば、各端末が、制御信号スパイクの発生が懸念される際に、送信キューに送信パケットを一時的に振り分ける。具体的には、端末が、バックグランド時に、ソフトウェアベースで数秒程度、パケット送信を停止させる。ハードウェアベースで実装する技術と比較して、実装上の制約が少なく、ネットワーク接続の集約によって制限される時間帯をできる限り短くすることができる。この技術は、ユーザにとって体感品質が劣化しないように、バックグラウンドに限って通信制御を実行する。例えば端末のディスプレイがＯＦＦであれば、バックグラウンドであると判断する。

更に、多数の端末が一斉にネットワークに接続する場面として、端末が緊急地震速報(ETWS(Earthquake and Tsunami Warning Systems)又はEEWS(Earthquake Early Warning System))を受信した際に、通信タイミングを制御する技術もある（例えば非特許文献５参照）。

図１は、デバイスが無線ゲートウェイを介してインターネットに接続するシステム構成図である。

ＩｏＴ／Ｍ２Ｍデバイス２は、例えばＬＴＥ網のような広域無線ネットワークに直接的に接続する場合もあれば、無線ゲートウェイ１を介して広域無線ネットワークに接続する場合もある。無線ゲートウェイを介した場合であっても、その配下の少なくとも１つのデバイスがパケットを発信する毎に、無線ゲートウェイは、ＬＴＥ網に接続しなければならない。端末やデバイスは、ＬＴＥ網に情報パケットを発信する毎に、基地局に対して無線リソースの割当要求を送信し、複数の制御信号をやりとりする。割当要求の送信タイミングは、例えばＲＡＣＨ(Random Access CHannel)によってランダムに決定される。

ここで、広域無線ネットワークから見た場合、例えば定時毎に、基地局に対して大量の数の制御信号が発生する傾向がある。例えば毎朝７時丁度のようなタイミングでは、膨大な数の無線リソースの割当要求が同時に発生する。このような場合、ＬＴＥ網は、制御信号スパイクの発生よって、多数の制御信号を処理できなくなる場合がある。

特開２０１５−２０７８３５号公報

Open Mobile Alliance, Always Online Infrastructure (AOI)、[online]、［平成２７年１２月１８日検索］、インターネット＜URL:http://member.openmobilealliance.org/ftp/Public documents/CD/AOI/＞ GSMA Technical Projects, Smarter Apps for Smarter Phones, GSMA Smarter App documents, April 2012、[online]、［平成２７年１２月１８日検索］、インターネット＜URL:http://www.gsma.com/technicalprojects/smarter-afpps-for-smarter-phones＞ Qualcomm, Managing Background Data Traffic in Mobile Devices, Qualcomm Incorporated, January 2012、[online]、［平成２７年１２月１８日検索］、インターネット＜URL:http://www.qualcomm.com/media/documents/managing-background-data-traffi c-mobile-devices＞荒井大輔、渡里雅史、大岸智彦、「LTE制御信号スパイクの発生を抑制する端末制御方式の提案と評価」、電子情報通信学会信学技報 Vol.114 No.29 文献番号：IN2014-13 発表日 2014/05/08、[online]、［平成２７年１２月１８日検索］、インターネット＜URL: http://ci.nii.ac.jp/naid/40020089430＞ Daisuke Arai, Tomohiko Ogishi, Masafumi Watari, Shigehiro Ano, Masakatsu Nishigaki, Hiroshi Mineno: UE-based Network Access Timing Control Scheme for Avoiding Signaling Spikes, Proceedings of 2015 IEEE International Conference on Communications (Mobile and Wireless Networking Symposium), pp.3604-3609, June 2015. 3GPP TR 37.868 V11.0.0 (2011-09)、[online]、［平成２７年１２月１８日検索］、インターネット＜http://www.qtc.jp/3GPP/Specs/37868-b00.pdf＞

図２は、従来技術における多数のデバイスからのパケット転送を表す説明図である。

図２によれば、複数のＩｏＴ／Ｍ２Ｍデバイス２が、広域無線ネットワークへ、直接的に、又は、無線ゲートウェイ（スマートフォン）１を介して間接的に、パケットを送信している。各デバイス２は、自ら必要時にパケットを自動的に発信する。無線ゲートウェイ１は、デバイス２との間で近距離無線ネットワークによって接続されており、デバイス２からパケットを受信する。

図２によれば、例えば７：００丁度のような定時に、多数のデバイス２が一斉同時に、パケットを発信しようとしている。これによって、広域無線ネットワークから見ると、大量のシグナリング（制御信号）が突発的に発生する。広域無線ネットワークは、このような制御信号スパイクの負荷に耐えることができるように、通信事業設備を増強する必要があり、コストの増加にもつながる。

１台のスマートフォン配下で、複数のデバイスが同一タイミングで発信し、スマートフォンがそのパケットを転送したとしても、広域無線ネットワークで直ぐに輻輳が発生するわけではない。しかしながら、膨大な数のユーザによって、膨大な数のデバイスが使用されており、それらのデバイスは、様々な場面で、送信タイミングも一致する傾向が強い。例えば、特定の地域に突発的な災害や気象の変化が発生した場合、活動量の変化を通知するデバイスが存在した場合には、その地域にあるスマートフォンから、デバイスの通信を実行するために制御信号が同時刻に発生し、輻輳が発生する。また例えば、緊急地震速報(ETWS(Earthquake and Tsunami Warning Systems)又はEEWS(Earthquake Early Warning System))を受信した場合もある（例えば非特許文献５参照）。

このように、大量のＩｏＴ／Ｍ２Ｍデバイスが広域無線ネットワークに接続することによって、無線リソースの割当要求（制御信号）が発生するタイミングの重複が発生しやすくなり、結果的に、輻輳に基づく通信品質の劣化が発生する原因となる。

そこで、本発明は、複数のデバイスが近距離無線ネットワークを介して接続する無線ゲートウェイについて、これらデバイスから発信されたパケットに基づく広域無線ネットワークへの制御信号を抑制することができる無線ゲートウェイ、プログラム及び方法を提供することを目的とする。

本発明によれば、複数のデバイスと近距離無線ネットワークを介して接続すると共に、他方で広域無線ネットワークと通信可能な無線ゲートウェイにおいて、
近距離無線ネットワークを介して複数のデバイスから受信したパケットを、所定時間だけ一時的に蓄積する輻輳検知バッファと、
輻輳検知バッファに所定数以上のパケットが蓄積されたか否かを判定する輻輳判定手段と、
輻輳判定手段によって真と判定された際に、輻輳検知バッファから出力されたパケットを蓄積する送信遅延バッファと、
送信遅延バッファに蓄積されたパケットを、任意の時間タイミングで、広域無線ネットワークへ送信する待ち状態制御手段と
を有することを特徴とする。

本発明の無線ゲートウェイにおける他の実施形態によれば、
待ち状態制御手段は、広域無線ネットワークに対して無線リソースの割り当てを要求した後、送信遅延バッファから取得したパケットを送信することも好ましい。

本発明の無線ゲートウェイにおける他の実施形態によれば、
輻輳検知バッファ及び送信遅延バッファは、Linux（登録商標）におけるNetfilter機能のOUTPUTチェインによって構成され、
待ち状態制御手段は、他の端末又は無線ゲートウェイとの間で分散して設定された異なる時間タイミングで、バッファしている送信パケットをバースト的に送信することも,好ましい。

本発明の無線ゲートウェイにおける他の実施形態によれば、
輻輳検知バッファは、デバイスから受信したパケットのみを蓄積し、
送信遅延バッファは、輻輳検知バッファから出力されたパケットと、アプリケーション及び／又はユーザデータに基づいて送信すべきパケットとの両方を蓄積する
ことも好ましい。

本発明の無線ゲートウェイにおける他の実施形態によれば、
デバイスから発信されるパケットには、製造種別を表すデバイスＩＤが付与されており、
輻輳検知バッファは、デバイスＩＤ毎にパケットを蓄積し、
輻輳判定手段は、デバイスＩＤ毎に、所定数以上のパケットが蓄積されたか否かを判定することも好ましい。

本発明の無線ゲートウェイにおける他の実施形態によれば、
パケットは、ＩｏＴ(Internet of Things)／Ｍ２Ｍ(Machine-to-Machine)デバイスから発信されたものであり、
当該無線ゲートウェイは、ユーザ操作に基づくスマートフォンであることも好ましい。

本発明によれば、複数のデバイスと近距離無線ネットワークを介して接続すると共に、他方で広域無線ネットワークと通信可能な装置に搭載されたコンピュータを機能させる無線ゲートウェイ用のプログラムにおいて、
近距離無線ネットワークを介して複数のデバイスから受信したパケットを、所定時間だけ一時的に蓄積する輻輳検知バッファと、
輻輳検知バッファに所定数以上のパケットが蓄積されたか否かを判定する輻輳判定手段と、
輻輳判定手段によって真と判定された際に、輻輳検知バッファから出力されたパケットを蓄積する送信遅延バッファと、
送信遅延バッファに蓄積されたパケットを、任意の時間タイミングで、広域無線ネットワークへ送信する待ち状態制御手段と
してコンピュータを機能させることを特徴とする。

本発明によれば、複数のデバイスと近距離無線ネットワークを介して接続すると共に、他方で広域無線ネットワークと通信可能な装置のパケット転送方法において、
装置は、
近距離無線ネットワークを介して複数のデバイスから受信したパケットを、所定時間だけ一時的に蓄積する第１のステップと、
第１のステップについて所定数以上のパケットが蓄積されたか否かを判定する第２のステップと、
第２のステップによって真と判定された際に、輻輳検知バッファから出力されたパケットを蓄積する第３のステップと、
第３のステップによって蓄積されたパケットを、任意の時間タイミングで、広域無線ネットワークへ送信する第４のステップと
を有することを特徴とする。

本発明の無線ゲートウェイ、プログラム及び方法によれば、複数のデバイスが近距離無線ネットワークを介して接続する無線ゲートウェイについて、これらデバイスから発信されたパケットに基づく広域無線ネットワークへの制御信号を抑制することができる。

本発明の無線ゲートウェイによれば、近距離無線ネットワーク側の輻輳状態を検知し、輻輳発生と判定した場合のみ、広域無線ネットワークへ送信すべきパケット（デバイスからのパケット、アプリケーションからのパケット、ユーザデータのパケットを含む）に遅延を付与する。これによって、広域無線ネットワークのシステム全体で見たときに、膨大な数の端末やデバイスから発生する無線リソースの割当要求に基づく制御信号スパイクの発生を抑制することができる。

デバイスが無線ゲートウェイを介してインターネットに接続するシステム構成図である。従来技術における多数のデバイスからのパケット転送を表す説明図である。本発明における無線ゲートウェイの機能構成図である。異なるトラヒックモデルを表すグラフである。多数のデバイスについてほぼ同時にパケットを発信した回数を表すグラフであある。送信有効／無効タイミングを表す説明図である。本発明における多数のデバイスからのパケット転送の分散を表す説明図である。

以下、本発明の実施の形態について、図面を用いて詳細に説明する。

図３は、本発明における無線ゲートウェイの機能構成図である。

本発明の無線ゲートウェイ１は、複数のデバイスと近距離無線ネットワークを介して接続すると共に、他方で広域無線ネットワークと通信可能なものである。無線ゲートウェイ１は、アクセスポイントのような専用機であってもよいし、テザリングを想定したユーザ所有のスマートフォンや携帯電話機であってもよい。

広域無線ネットワークは、例えばＬＴＥや３Ｇのような広域通信網であり、近距離無線ネットワークは、例えばBluetooth（登録商標）やZigbee（登録商標）、PLCであってもよいし、無線ＬＡＮ(Local Area Network)であってもよい。無線ゲートウェイ１は、近距離無線ネットワークを介して、複数のデバイス２と通信することができる。デバイス２は、例えばタグやウェアラブルデバイスのようなＩｏＴ／Ｍ２Ｍデバイスである。

無線ゲートウェイ１は、デバイス２から近距離無線ネットワークを介して受信したパケットを、広域無線ネットワークを介して所定のアプリケーションサーバへ転送する。無線ゲートウェイ１がスマートフォンである場合、デバイスのパケットの転送制御用のベースアプリケーション（無線ゲートウェイ用のプログラム）として構成されたものであってもよい。

尚、本発明によって抑制される広域無線ネットワークの制御信号スパイクは、通信開始時に、スマートフォン（無線ゲートウェイ）が基地局へ送信する、無線リソースの割当要求（Random Access Channel, RACH）に基づく。即ち、大量のデータの送受信に基づく輻輳とは異なる。また、本発明によれば、端末が広域無線ネットワークと通信開始前の状態（無線リソースの割当前）を前提としており、広域無線ネットワークから端末へ、何らかの輻輳制御信号を送信することもできない。

図３の無線ゲートウェイ１によれば、輻輳検知バッファ１１と、輻輳判定部１２と、送信遅延バッファ１３と、待ち状態制御部１４とを有する。これら機能構成部は、装置に搭載されたコンピュータを機能させる無線ゲートウェイ用のプログラムを実行することによって実現される。これら機能は、スマートフォンに搭載されたＯＳ(Operating System)のカーネルプログラムに適用されたものであることが好ましい。具体的には、Android（登録商標）OSのカーネルとなるLinux（登録商標）に適用されたものであってもよい。尚、これら機能構成部の処理の流れは、パケット転送方法としても理解できる。

［輻輳検知バッファ１１］
輻輳検知バッファ１１は、近距離無線ネットワークを介して複数のデバイス２から受信したパケットを、所定時間だけ一時的に蓄積する。ここで、輻輳検知バッファ１１は、デバイス２から受信したパケットのみを蓄積する。輻輳検知バッファ１１は、具体的には、後述する送信遅延バッファ１３と共に、Linux（登録商標）におけるNetfilter機能のOUTPUTチェインによって構成される。

輻輳検知バッファ１１によって遅延される所定時間は、輻輳発生を検知するために必要な時間分だけであって、非常に短い時間とし、具体的には例えば１００ミリ秒以下であってもよい。そのバッファは、デバイス２からのパケットの発生傾向を分析できる程度のものである。本発明によれば、前述した非特許文献５に記載された技術と比較して、輻輳発生の有無に関わらず、輻輳検知バッファによって輻輳検知のための遅延が常に付与される点で相違する。

［輻輳判定部１２］
輻輳判定部１２は、輻輳検知バッファ１１に所定数以上のパケットが蓄積された場合、輻輳発生と判定する。輻輳判定部１２は、輻輳検知バッファ１１に蓄積されたパケット毎に、「デバイスＩＤ及び受信時刻」を記録して管理するものであってもよい。受信時刻から現在時刻までの時間差を算出し、その時間差が所定時間範囲となるパケットの数を計数する。即ち、所定時間範囲のパケット数が所定数以上となる場合、近距離無線ネットワークで「輻輳発生」と判定する。

輻輳判定部１２は、デバイス２からのパケットの発生頻度を判定している。ここで、輻輳判定部１２は、輻輳検知バッファ１１に蓄積されたパケット数に関わらず、例えばトラヒックモデルに基づいて輻輳時（Synchronized）／通常時を判定するものであってもよい（例えば非特許文献６参照）。

図４は、異なるトラヒックモデルを表すグラフである。

図４によれば、横軸を経過時間（単位：秒）とし、縦軸をトラヒック発生確率とする。輻輳判定部１２は、デバイスからのパケットの発生頻度が、トラヒックモデル１又はトラヒックモデル２のいずれに近いのか？によって判定する。トラヒックモデル２に近いと判定された場合、「輻輳発生」と判定する。

＜デバイスＩＤ毎に輻輳を検知する実施形態＞
デバイス２から発信されるパケットには、製造種別を表すデバイスＩＤが付与されている。製造種別とは、例えばメーカ種別であってもよい。具体的には、近距離無線インタフェースにBluetooth（登録商標）を用いる場合、Bluetoothアドレス（48bit）が使用されており、このうち24bitは、ＯＵＩ(Organizationally Unique Identifier)と称され、製造者を識別することができる。この実施形態では、輻輳検知バッファ１１は、デバイスＩＤ毎にパケットを蓄積する。これによって、輻輳判定部１２は、デバイスＩＤ毎に、所定数以上のパケットが蓄積されたか否かを判定することができる。

デバイスからのパケットの到着頻度によって輻輳を判定する本発明によれば、通常状態（輻輳が発生していない状態）には、デバイスからのパケットの到着頻度に偏りが無いことを暗黙的に期待している（偏りがあった場合、高頻度にパケットが到着していることで、本来、輻輳ではないにもかかわらず輻輳と判定し、パケットに遅延を不必要に付与することになる）。特に、同一メーカのデバイスほど、実装上、同一の送信タイミングでパケットを発信しようとする傾向がある。例えばAndroid（登録商標）OS対応のスマートフォンには、AndroidOS対応の周辺デバイスが接続する。その場合、ユーザに対してデバイス間で相互に連携したサービスを提供することができる一方で、それら複数のデバイスの送信タイミングも一致する傾向が強い。

図５は、多数のデバイスについてほぼ同時にパケットを発信した回数を表すグラフであある。図５によれば、特定のデバイス同士で、ほぼ同時にパケットを発信した回数が多いことが確認できる。

そこで、本発明によれば、同時に発生する可能性が高いデバイスを、論理的に単一のデバイスとして扱うこととする。例えばメーカＡによって製造され、連携して動作する複数のデバイスが存在した場合、これらデバイス群から発信されたパケットを、本発明のように論理的に単一のデバイスとしない場合には、輻輳判定を誤判定する可能性がある。具体的には、同一のメーカであれば、同時期に複数のデバイスから通信が発生することは、通常状態（輻輳が発生していない）であるにもかかわらず、誤って、輻輳状態と判定する可能性がある。

尚、他の実施形態として、パケットの発生頻度を事前に学習し、同じタイミングで通信を行う可能性の高いデバイスをクラスタリングし、クラスタ毎に輻輳検知バッファを備えたものであってもよい。

［送信遅延バッファ１３］
送信遅延バッファ１３は、輻輳判定部１２によって真（輻輳発生）と判定された際に、輻輳検知バッファから出力されたパケットと蓄積する。それに加えて、送信遅延バッファ１３は、アプリケーション及び／又はユーザデータに基づいて送信すべきパケットも蓄積するものであってもよい。送信遅延バッファ１３は、動的に生成されて、消去されるものであってもよい。

［待ち状態制御部１４］
待ち状態制御部１４は、送信遅延バッファ１３に蓄積されたパケットを、任意の時間タイミングで、広域無線ネットワークへ送信する。待ち状態制御部１４は、アプリケーションレベルで、パケット送信に基づくタイムアウトに影響のない範囲の時間タイミングで、バッファしている送信パケットをバースト的に送信する。具体的には、例えば８秒間に、１秒間ずつ、送信許可を得るように動作するものであってもよい。待ち状態制御部１４は、広域無線ネットワークに対して無線リソースの割り当てを要求した後、送信遅延バッファから取得したパケットを送信する。

ここでの「待ち状態時間」とは、例えば数秒〜１分間程度の短い時間である。待ち状態時間の中には、送信有効タイミング「Enable状態」と送信無効タイミング「Disable状態」とが含まれる。送信無効タイミングは、送信有効タイミングとは異なって通信を制御しており、アプリケーションに対するユーザの体感品質への影響も考慮して比較的短い時間（長くても１分以内）とする。

図６は、送信有効／無効タイミングを表す説明図である。

図６によれば、パケットの送信の可否は、パケット送信制御部１２のNetfilter機能における制御ウィンドウ(Control Window)によって制御される。制御ウィンドウは、送信有効タイミング「Enable状態」と、送信無効タイミング「Disable状態」とがある。Disable状態で発生したパケットは、次のEnable状態になるまで、送信が保留される。これによって、同時に発生したパケットは、その送信が遅延されることとなる。尚、遅延時間について、端末１毎に分散して設定された異なる時間タイミングで、パケットが送信されるように、待ち状態時間の最初の送信無効タイミング「Disable状態」の長さは、当該パケット送信プログラムによって機能する端末毎に分散して設定される。これによって、他の端末又は無線ゲートウェイとの間で分散して設定された異なる時間タイミングで、バッファしている送信パケットをバースト的に送信し、制御信号スパイクが抑制される。

図７は、本発明における多数のデバイスからのパケット転送の分散を表す説明図である。

図７によれば、従来技術の図２と比較して多数のデバイスから受信したパケットの送信タイミングが、複数の端末間で分散されている。送信遅延バッファは、送信有効タイミング(Enable)の際に、異なる時間タイミングで各送信遅延バッファからバースト的にパケットを送信する。

端末毎に、Control Windowの送信有効タイミングが分散して設定されている。Control Windowは、RRC_connectedのタイミングをずらすものであって、例えば端末固有の識別子や電話番号から、時刻差が設定される。例えば最大８秒間を、１秒毎に８段階に設定し、識別子の末番号に応じて自らの設定遅延量を認識する。端末毎にControl WindowsのEnable時刻がずれている。図７によれば、多数のデバイスのパケットが、送信遅延バッファに応じて遅延されている。これによって、通信事業設備に係る突発的な大量の送信パケットの発生が分散される。

無線ゲートウェイ１は、デバイス２から受信したパケットを、無線リソース（RRC：Radio Resource Control）がアクティブ状態の際に、広域無線ネットワークへ送信する。スマートフォンと広域無線ネットワークとの間は、常時接続しているわけではなく、アイドル状態（RRC_IDLE）とアクティブ状態（RRC_CONNECTED）とを交互に切り替えている。各デバイスが送信パケットを発生させる毎に、スマートフォンは、ネットワークに対してセッション確立のためのシーケンスを実行する。その際、ネットワークの通信事業設備に対して、多数のシグナリングを発生する。

以上、詳細に説明したように、本発明の無線ゲートウェイ、プログラム及び方法によれば、複数のデバイスが近距離無線ネットワークを介して接続する無線ゲートウェイについて、これらデバイスから発信されたパケットに基づく広域無線ネットワークへの制御信号を抑制することができる。

前述した本発明の種々の実施形態について、本発明の技術思想及び見地の範囲の種々の変更、修正及び省略は、当業者によれば容易に行うことができる。前述の説明はあくまで例であって、何ら制約しようとするものではない。本発明は、特許請求の範囲及びその均等物として限定するものにのみ制約される。

１無線ゲートウェイ
１１輻輳検知バッファ
１２輻輳判定部
１３送信遅延バッファ
１４待ち状態制御部
２ＩｏＴ／Ｍ２Ｍ対応のデバイス

Claims

複数のデバイスと近距離無線ネットワークを介して接続すると共に、他方で広域無線ネットワークと通信可能な無線ゲートウェイにおいて、
近距離無線ネットワークを介して複数のデバイスから受信したパケットを、所定時間だけ一時的に蓄積する輻輳検知バッファと、
前記輻輳検知バッファに所定数以上のパケットが蓄積されたか否かを判定する輻輳判定手段と、
前記輻輳判定手段によって真と判定された際に、前記輻輳検知バッファから出力されたパケットを蓄積する送信遅延バッファと、
前記送信遅延バッファに蓄積されたパケットを、任意の時間タイミングで、広域無線ネットワークへ送信する待ち状態制御手段と
を有することを特徴とする無線ゲートウェイ。
前記待ち状態制御手段は、前記広域無線ネットワークに対して無線リソースの割り当てを要求した後、前記送信遅延バッファから取得したパケットを送信する
ことを特徴とする請求項１に記載の無線ゲートウェイ。
前記輻輳検知バッファ及び前記送信遅延バッファは、Linux（登録商標）におけるNetfilter機能のOUTPUTチェインによって構成され、
前記待ち状態制御手段は、他の端末又は無線ゲートウェイとの間で分散して設定された異なる時間タイミングで、バッファしている送信パケットをバースト的に送信する
ことを特徴とする請求項１又は２に記載の無線ゲートウェイ。
前記輻輳検知バッファは、デバイスから受信したパケットのみを蓄積し、
前記送信遅延バッファは、前記輻輳検知バッファから出力されたパケットと、アプリケーション及び／又はユーザデータに基づいて送信すべきパケットとの両方を蓄積する
ことを特徴とする請求項１から３のいずれか１項に記載の無線ゲートウェイ。
前記デバイスから発信されるパケットには、製造種別を表すデバイスＩＤが付与されており、
前記輻輳検知バッファは、前記デバイスＩＤ毎にパケットを蓄積し、
前記輻輳判定手段は、前記デバイスＩＤ毎に、所定数以上のパケットが蓄積されたか否かを判定する
ことを特徴とする請求項１から４のいずれか１項に記載の無線ゲートウェイ。
前記パケットは、ＩｏＴ(Internet of Things)／Ｍ２Ｍ(Machine-to-Machine)デバイスから発信されたものであり、
当該無線ゲートウェイは、ユーザ操作に基づくスマートフォンである
ことを特徴とする請求項１から５のいずれか１項に記載の無線ゲートウェイ。
複数のデバイスと近距離無線ネットワークを介して接続すると共に、他方で広域無線ネットワークと通信可能な装置に搭載されたコンピュータを機能させる無線ゲートウェイ用のプログラムにおいて、
近距離無線ネットワークを介して複数のデバイスから受信したパケットを、所定時間だけ一時的に蓄積する輻輳検知バッファと、
前記輻輳検知バッファに所定数以上のパケットが蓄積されたか否かを判定する輻輳判定手段と、
前記輻輳判定手段によって真と判定された際に、前記輻輳検知バッファから出力されたパケットを蓄積する送信遅延バッファと、
前記送信遅延バッファに蓄積されたパケットを、任意の時間タイミングで、広域無線ネットワークへ送信する待ち状態制御手段と
してコンピュータを機能させることを特徴とする無線ゲートウェイ用のプログラム。
複数のデバイスと近距離無線ネットワークを介して接続すると共に、他方で広域無線ネットワークと通信可能な装置のパケット転送方法において、
前記装置は、
近距離無線ネットワークを介して複数のデバイスから受信したパケットを、所定時間だけ一時的に蓄積する第１のステップと、
第１のステップについて所定数以上のパケットが蓄積されたか否かを判定する第２のステップと、
第２のステップによって真と判定された際に、前記輻輳検知バッファから出力されたパケットを蓄積する第３のステップと、
第３のステップによって蓄積されたパケットを、任意の時間タイミングで、広域無線ネットワークへ送信する第４のステップと
を有することを特徴とする装置のパケット転送方法。