図面 (/)

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

出願人 KDDI株式会社
発明者 荒井大輔大岸智彦
出願日 2016年1月4日 (3年6ヶ月経過) 出願番号 2016-000293
公開日 2017年7月13日 (2年0ヶ月経過) 公開番号 2017-123508
状態 特許登録済
技術分野 移動無線通信システム 広域データ交換
主要キーワード ウェアラブルデバイス 設定遅延量 近距離無線インタフェース 到着頻度 テザリング 制御ウィンドウ 広域無線ネットワーク カーネルプログラム
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2017年7月13日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (8)

課題

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

解決手段

近距離無線ネットワークを介して複数のデバイス2から受信したパケットを、所定時間だけ一時的に蓄積する輻輳検知バッファ11と、輻輳検知バッファに所定数以上のパケットが蓄積されたか否かを判定する輻輳判定手段12と、輻輳判定手段によって真と判定された際に、輻輳検知バッファ11から出力されたパケットを蓄積する送信遅延バッファ13と、送信遅延バッファに蓄積されたパケットを、任意の時間タイミングで、広域無線ネットワークへ送信する待ち状態制御手段14とを有する。

概要

背景

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

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

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

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

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

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

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

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

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

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

概要

複数のデバイスが近距離無線ネットワークを介して接続する無線ゲートウェイについて、これらデバイスが発信したパケット基づく広域無線ネットワークへの制御信号を抑制することができる無線ゲートウェイ、プログラム及び方法を提供する。近距離無線ネットワークを介して複数のデバイス2から受信したパケットを、所定時間だけ一時的に蓄積する輻輳検知バッファ11と、輻輳検知バッファに所定数以上のパケットが蓄積されたか否かを判定する輻輳判定手段12と、輻輳判定手段によって真と判定された際に、輻輳検知バッファ11から出力されたパケットを蓄積する送信遅延バッファ13と、送信遅延バッファに蓄積されたパケットを、任意の時間タイミングで、広域無線ネットワークへ送信する待ち状態制御手段14とを有する。

目的

また、多数の端末間で同時に発生するネットワーク接続のタイミングをずらすことを目的とした

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

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

請求項2

前記待ち状態制御手段は、前記広域無線ネットワークに対して無線リソース割り当てを要求した後、前記送信遅延バッファから取得したパケットを送信することを特徴とする請求項1に記載の無線ゲートウェイ。

請求項3

前記輻輳検知バッファ及び前記送信遅延バッファは、Linux(登録商標)におけるNetfilter機能のOUTPUTチェインによって構成され、前記待ち状態制御手段は、他の端末又は無線ゲートウェイとの間で分散して設定された異なる時間タイミングで、バッファしている送信パケットバースト的に送信することを特徴とする請求項1又は2に記載の無線ゲートウェイ。

請求項4

前記輻輳検知バッファは、デバイスから受信したパケットのみを蓄積し、前記送信遅延バッファは、前記輻輳検知バッファから出力されたパケットと、アプリケーション及び/又はユーザデータに基づいて送信すべきパケットとの両方を蓄積することを特徴とする請求項1から3のいずれか1項に記載の無線ゲートウェイ。

請求項5

前記デバイスから発信されるパケットには、製造種別を表すデバイスIDが付与されており、前記輻輳検知バッファは、前記デバイスID毎にパケットを蓄積し、前記輻輳判定手段は、前記デバイスID毎に、所定数以上のパケットが蓄積されたか否かを判定することを特徴とする請求項1から4のいずれか1項に記載の無線ゲートウェイ。

請求項6

前記パケットは、IoT(Internet of Things)/M2M(Machine-to-Machine)デバイスから発信されたものであり、当該無線ゲートウェイは、ユーザ操作に基づくスマートフォンであることを特徴とする請求項1から5のいずれか1項に記載の無線ゲートウェイ。

請求項7

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

請求項8

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

技術分野

0001

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

背景技術

0002

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

0003

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

0004

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

0005

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

0006

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

0007

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

0008

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

0009

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

0010

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

0011

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

0012

特開2015−207835号公報

先行技術

0013

Open Mobile Alliance, Always Online Infrastructure (AOI)、[online]、[平成27年12月18日検索]、インターネット<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]、[平成27年12月18日検索]、インターネット<URL:http://www.gsma.com/technicalprojects/smarter-afpps-for-smarter-phones>
Qualcomm, Managing Background Data Traffic in Mobile Devices, Qualcomm Incorporated, January 2012、[online]、[平成27年12月18日検索]、インターネット<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]、[平成27年12月18日検索]、インターネット<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 2015IEEE International Conference on Communications (Mobile and Wireless Networking Symposium), pp.3604-3609, June 2015.
3GPP TR 37.868 V11.0.0 (2011-09)、[online]、[平成27年12月18日検索]、インターネット<http://www.qtc.jp/3GPP/Specs/37868-b00.pdf>

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

0014

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

0015

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

0016

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

0017

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

0018

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

0019

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

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

0020

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

0021

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

0022

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

0023

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

0024

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

0025

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

0026

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

0027

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

発明の効果

0028

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

0029

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

図面の簡単な説明

0030

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

実施例

0031

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

0032

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

0033

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

0034

広域無線ネットワークは、例えばLTEや3Gのような広域通信網であり、近距離無線ネットワークは、例えばBluetooth(登録商標)やZigbee(登録商標)、PLCであってもよいし、無線LAN(Local Area Network)であってもよい。無線ゲートウェイ1は、近距離無線ネットワークを介して、複数のデバイス2と通信することができる。デバイス2は、例えばタグやウェアラブルデバイスのようなIoT/M2Mデバイスである。

0035

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

0036

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

0037

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

0038

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

0039

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

0040

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

0041

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

0042

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

0043

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

0044

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

0045

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

0046

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

0047

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

0048

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

0049

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

0050

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

0051

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

0052

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

0053

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

0054

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

0055

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

0056

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

0057

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

0058

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

0059

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

0060

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

0061

1無線ゲートウェイ
11輻輳検知バッファ
12輻輳判定部
13送信遅延バッファ
14待ち状態制御部
2IoT/M2M対応のデバイス

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ