JP2020137099A - 通信ネットワーク制御システム、中央通信制御装置、通信制御方法及び通信制御プログラム - Google Patents

Abstract

【課題】本開示は、災害やイベント時などに局所的に発生するネットワーク輻輳及びサーバ側への通信の集中を低減し、重要な通信が行えるようにすることを目的とする。【解決手段】本開示に係る通信ネットワーク制御システムは、機器（９２、９３）の通信を制御する、複数の通信制御装置（２０、３０）と、複数の通信制御装置に対して通信制御情報を配信する中央通信制御装置（１０）と、を備え、中央通信制御装置（１０）は、位置情報と紐付いたイベント情報を収集し、収集したイベント情報を用いて、通信量の増加する可能性のある地域を判定し、通信量の増加する可能性のある地域がある場合には、当該地域の通信を優先する通信制御情報を生成し、生成した通信制御情報を複数の通信制御装置（２０，３０）に配信する。【選択図】図２

Description

本開示は、通信ネットワーク制御システム、中央通信制御装置、通信制御方法及び通信制御プログラムに関する。

ＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）機器の通信制御を行うために、種々のＩｏＴシステムが提案されている（例えば、特許文献１〜３参照。）。例えば、関連する第１のＩｏＴシステムは、ＩｏＴ機器側で通信の重要性を動的に判断し、通信の優先度等を変更し制御する。関連する第２のＩｏＴシステムは、ＩｏＴ機器側で通信時間をランダムにずらす、若しくは予め設定された通信時間帯で通信を行う、または、サーバ側からＩｏＴ機器側にラウンドロビン的にポーリング（クロール）して通信する。関連する第３のＩｏＴシステムは、データセンタ側のリソースを予め確保し、負荷（通信）の状況に応じて、仮想サーバを臨時に増設する。関連する第４のＩｏＴシステムは、同時通信可能数の上限を設ける。

このように、関連するＩｏＴシステムは、イベント・ドリブン型通信（自律分散型）又はサーバからのラウンドロビン的なポーリング型の通信形態が用いられており、ＩｏＴシステム全体の通信制御を行う機構は用いられなかった。

ＩｏＴ機器は、災害（台風、地震、大雨洪水、等）や、企画イベント開催に伴う騒乱等の事象が発生した際、各種通信を高頻度に行う傾向がある。一方、これらの事象の発生時においては、局地的なネットワーク輻輳及びサーバ側への通信の集中が発生し、これらが要因となって、災害発生後の安全確認情報、深刻な事態の発生通知などの真に重要な通信が正常に行えない場合がある。このような場合においては、関連する第１〜第４のＩｏＴシステムは、以下の問題がある。図１を参照しながら、具体的に説明する。

関連する第１のＩｏＴシステムは、ＩｏＴ機器９３側では、ネットワーク輻輳やサーバ９２側の通信の集中の発生が事前に装置側で判断・検知できず、サーバ９２と通信を行い通信が失敗してはじめて分かる。そして、その後に、優先通信サービスに切換える等の通信制御を行うため、正常に通信ができない可能性が高まる、またその通信により、ネットワーク輻輳を増長させてしまう恐れがある。また関連する第１のＩｏＴシステムは、サーバ９２側では、ＩｏＴ機器９３側で優先度を決めて通信するため、ネットワーク輻輳およびサーバ９２側で通信の集中が発生した際に、サーバ９２側で真に重要な通信を選別して通信する事ができない問題がある。例えば、広範囲な災害等が発生した場合、各地のＩｏＴ機器９３で一斉に通信を始めるため、サーバ９２側の通信集中が発生し、真に重要な通信（重大な損傷を知らせる通知など）の通信が行えなくなる。

関連する第２のＩｏＴシステムでは以下の問題が生じる。ランダムにずらした場合、ＩｏＴ機器９３側ではネットワーク輻輳やサーバ９２側の通信集中を確実には回避できず、サーバ９２側では真に重要な通信を選別して通信する事ができない。予め設定された通信時間帯で通信を行う場合、ＩｏＴ機器９３側では真に通信するべき時にサーバ９２と通信する事ができず、サーバ９２側では真に通信するべきＩｏＴ機器９３と通信する事ができない。

関連する第３のＩｏＴシステムでは以下の問題が生じる。データセンタのリソースを予め確保する際にどれだけリソースを確保しなければいいか分からない。また仮想サーバの増設はコストの観点から好ましくない。またサーバ９２のリソースを他者と共有している場合は、確実に増設できるとは限らない。また物理的な回線の帯域は増設できないので、それ以上の通信の集中が発生した際には、通信できないＩｏＴ機器９３が発生する。また物理回線を他のサービス利用者と共用している場合、他の通信も集中した際は、確実に通信する事ができない。

関連する第４のＩｏＴシステムでは、真に通信するべきＩｏＴ機器９３を選別して通信する事ができない。

国際公開第２００８／１２６２８０号公報 特開２０１３−１５７７１９号公報 特表２０１５−５１０２０１号公報

本開示は、関連する第１〜第４のＩｏＴシステムでは解決できなかった課題を解決する、すなわち、災害やイベント時などに局所的に発生するネットワーク輻輳及びサーバ側への通信の集中を低減し、真に重要な通信が行えるようにすることを目的とする。

自然災害の発生および企画型イベント開催等の情報に伴うネットワーク輻輳やサーバ側の通信集中の発生（発生場所及び日時）をある程度事前に予想できる情報が、各所から電子情報として配信されている。これらの情報を活用すれば、ネットワーク輻輳やサーバ側の通信集中をある程度事前に予想できる。

そこで、本開示は、
サーバやＩｏＴ機器等の各機器の通信を制御する通信制御装置と、
各通信制御装置を制御する中央通信制御装置と、
を備えるシステムにおいて、
中央通信制御装置が、
災害予報やイベントなどの位置情報と紐付いたイベント情報に基づいて、ネットワーク輻輳やサーバ側の通信集中を検出又は予測し、
当該検出又は予測に基づいて、サーバ装置と各ＩｏＴ機器との間の通信が地理的かつ時間的に分散するように、地域ごとの通信スケジュールなどの通信制御情報を生成し、
前記通信制御情報を各通信制御装置に配信する。

具体的には、本開示に係る通信ネットワーク制御システムは、
地理的に分散して配置されている複数の機器が接続されている通信ネットワークに含まれる前記機器ごとに備わり、配信された通信制御情報に従って個々の前記機器の通信を制御する、複数の通信制御装置と、
前記複数の通信制御装置に対して前記通信制御情報を配信する中央通信制御装置と、を備え、
前記中央通信制御装置は、
位置情報と紐付いたイベント情報を収集し、
収集したイベント情報を用いて、通信量の増加する可能性のある地域を判定し、
通信量の増加する可能性のある地域がある場合には、当該地域の通信を優先する通信制御情報を生成し、
生成した通信制御情報を前記複数の通信制御装置に配信する。

前記中央通信制御装置は、
収集したイベント情報を用いて、通信量の増加する可能性のある地域及び時間を判定し、
通信量の増加する可能性のある地域がある場合には、通信量の増加する可能性のある時間において当該地域の通信を優先する通信制御情報を生成する、
構成態様を採用しうる。

前記複数の機器はサーバを含み、
サーバに備わる前記通信制御装置は、配信された通信制御情報に従い、通信量の増加する可能性のある時間に、通信量の増加する可能性のある地域との通信を優先する、
構成態様を採用しうる。

前記複数の機器は、ＩｏＴ機器を含み、
サーバに備わる前記通信制御装置は、前記中央通信制御装置から受信した通信制御情報を用いて、サーバと通信を行うＩｏＴ機器のアクセスコントロールリストを作成し、前記アクセスコントロールリストを各ＩｏＴ機器へ配信し、
ＩｏＴ機器に備わる前記通信制御装置は、サーバに備わる前記通信制御装置から受信したアクセスコントロールリストに従って、サーバへのアクセスを行う、
構成態様を採用しうる。
ここで、前記通信制御情報は、地域を特定する情報として市外局番が用いられ、
前記アクセスコントロールリストのサブネットＩＤに市外局番が割り当てられていてもよい。

具体的には、本開示に係る中央通信制御装置は、
地理的に分散して配置されている複数の機器が接続されている通信ネットワークに含まれる前記機器ごとに備わり、配信された通信制御情報に従って個々の前記機器の通信を制御する、複数の通信制御装置と、
前記複数の通信制御装置に対して前記通信制御情報を配信する中央通信制御装置と、を備える通信ネットワーク制御システムにおける、前記中央通信制御装置であって、
位置情報と紐付いたイベント情報を収集し、
収集したイベント情報を用いて、通信量の増加する可能性のある地域を判定し、
通信量の増加する可能性のある地域がある場合には、当該地域の通信を優先する通信制御情報を生成し、
生成した通信制御情報を前記複数の通信制御装置に配信する。

具体的には、本開示に係る通信制御方法は、
地理的に分散して配置されている複数の機器が接続されている通信ネットワークに含まれる前記機器ごとに備わり、配信された通信制御情報に従って個々の前記機器の通信を制御する、複数の通信制御装置と、
前記複数の通信制御装置に対して前記通信制御情報を配信する中央通信制御装置と、を備える通信ネットワーク制御システムにおける、
前記中央通信制御装置が実行する通信制御方法であって、
前記中央通信制御装置は、
位置情報と紐付いたイベント情報を収集し、
収集したイベント情報を用いて、通信量の増加する可能性のある地域を判定し、
通信量の増加する可能性のある地域がある場合には、当該地域の通信を優先する通信制御情報を生成し、
生成した通信制御情報を前記複数の通信制御装置に配信する。

具体的には、本開示に係る通信制御プログラムは、本開示に係る中央通信制御装置に備わる各機能をコンピュータに実現させるためのプログラムであり、本開示に係る中央通信制御方法に備わる各手順をコンピュータに実行させるためのプログラムである。本開示に係る通信制御プログラムは、記録媒体に記録されていてもよく、ネットワークを通して提供することも可能である。

なお、上記各開示は、可能な限り組み合わせることができる。

本開示によれば、災害やイベント時などに局所的に発生するネットワーク輻輳及びサーバ側への通信の集中を低減し、真に重要な通信が行えるようにすることが可能となる。

本開示に関連するＩｏＴシステムの構成の一例を示す。 本開示に係るシステム構成の概要を示す。 本実施形態に係るシステム構成の一例を示す。 位置情報の対応付けのデータベースモデル例である。 スケジューリング情報を配信するフレーム構成の一例を示す。 各機器のアドレス割当例を示す。 サーバ側の通信制御装置の構成の一例を示す。 ＩｏＴ機器側の通信制御装置の構成の一例を示す。 中央通信制御装置の処理フローの一例を示す。 サーバ側のスケジューリング情報受信部の処理フローの一例を示す。 サーバ側のスケジューリング情報処理部の処理フローの一例を示す。 ＩｏＴ機器側のスケジューリング情報受信部の処理フローの一例を示す。 ＩｏＴ機器側のスケジューリング情報処理部の処理フローの一例を示す。 第２の実施形態に係るシステムの動作例を示す。 第３の実施形態に係るシステムの動作例を示す。 第４の実施形態に係るシステムの動作例を示す。 第５の実施形態に係るシステムの動作例を示す。 第６の実施形態に係るシステムの動作例を示す。 第７の実施形態に係るシステムの動作例を示す。

以下、本開示の実施形態について、図面を参照しながら詳細に説明する。なお、本開示は、以下に示す実施形態に限定されるものではない。これらの実施の例は例示に過ぎず、本開示は当業者の知識に基づいて種々の変更、改良を施した形態で実施することができる。なお、本明細書及び図面において符号が同じ構成要素は、相互に同一のものを示すものとする。

（本開示に係る通信ネットワーク制御システムの概要）
図２に、本開示に係るシステム構成の一例を示す。本開示に係る通信ネットワーク制御システムは、中央通信制御装置１０、サーバ９２側に配置される通信制御装置２０、ＩｏＴ機器９３側に配置される通信制御装置３０を備える。本開示に係る通信ネットワークでは、サーバ９２が、地理的に分散して配置されている複数のＩｏＴ機器９３と接続されている。通信制御装置２０はサーバ９２の通信制御を行い、通信制御装置３０はＩｏＴ機器９３の通信制御を行う。通信制御装置を、本開示では、ＣＰＥ（Ｃｕｓｔｏｍｅｒ Ｐｒｅｍｉｓｅｓ Ｅｑｕｉｐｍｅｎｔ）と称する。

自然災害においては、事前にその発生種別、時間、場所がある程度予見でき、その情報は、気象庁（気象業務支援センタ）から防災気象情報として電子情報で配信されている。また企画型イベントに伴う事象規制情報が、日本道路交通情報センターから、避難情報や国民保護情報が、マルチメディア振興センター（Ｌアラート）から、それぞれ電子情報が配信されている。中央通信制御装置１０は、これらの位置情報と紐付いた情報を「イベント情報」としてサーバ９７から収集する。

中央通信制御装置１０は、収集したこれらの情報に基づいて、通信量が一時的に増加し、災害等の事象発生に伴う輻輳や、多量の通信が発生する地域及び時間帯を予想し、通信スケジューリングを計画し、通信制御装置２０及び３０に事前に配信する事で、通信を地理的及び時間的に分散する。これにより、ネットワーク輻輳の回避およびサーバ側の通信集中を抑制し、真に重要性の高い通信を確実に行えるようにする。

（中央通信制御装置１０の動作）
・気象庁／日本道路交通情報センター／Ｌアラート等のサーバ９７から配信されるイベント情報を受信し、事象発生に伴って、ネットワーク輻輳やサーバ側通信集中が発生する場所及び時間帯を予想し、契約者情報から、契約者の機器設置場所に応じた通信スケジューリングを計画し、各機器に通信制御情報を事前に配信する。
・事象発生中においても、逐次配信される情報に基づいて、通信スケジュールを適宜変更し、各機器に再配信する。

（中央通信制御装置１０が各装置に配信する通信制御情報例）
・ＩｏＴ機器９３側：真に重要な通信を行うべき時間帯およびその優先度並びに不要不急な通信を抑制すべき時間帯等
・サーバ９２側：真に重要な通信を行う可能性のあるＩｏＴ機器９３の一覧およびその時間帯並びにその優先度等

（ＩｏＴ機器９３側の動作）
通信制御装置３０は、中央通信制御装置１０から配信された通信スケジューリング等の通信制御情報に従って、ＩｏＴ機器９３の通信制御を行う。例えば、優先通信サービスの使用、通信帯域の制限、各種優先度識別子の付加、通信フロー制御、通信パスの確保設定、自装置内または近隣代替サーバへの通信の蓄積並びに遅延再送信による不要不急な通信の抑制等が例示できる。

（サーバ９２側の動作）
通信制御装置２０は、中央通信制御装置１０から配信された通信スケジューリング等の通信制御情報に従って、通信制御を行う。例えば、事前の通信パスの確保設定、各通信の通信帯域の割当、通信フロー制御、通信対象リスト以外の装置に関する通信の抑制、配信された通信対象毎の優先度情報に基づく、通信の選別（通信の抑制）等が例示できる。万一、通信の集中が発生した場合は、より積極的な通信制御を行う。例えば、通信対象リスト以外の装置に関する通信の排除、配信された通信対象毎の優先度情報に基づく、通信の選別（通信の排除）等が例示できる。ここで、「通信対象」は、サーバ９２と通信を行っている任意の装置であり、例えば、ＩｏＴ機器９３が例示できる。

（本開示の効果）
本開示は、中央通信制御装置１０が、事前に配信される情報を用いて通信スケジュールを計画し、各装置にスケジューリング情報等の通信制御情報を事前に配信する。これにより、本開示は、通信を地理的かつ時間的に分散し、局所的に発生するネットワーク輻輳の回避・低減、サーバ側の通信の集中を抑制し、真に重要な通信が確実に行える様になる。

ここで、ＩｏＴ機器９３側に事前に配信される通信制御情報は、例えば、真に重要な通信を行うべき時間帯およびその優先度並びに不要不急な通信を抑制するべき時間帯等である。サーバ９２側に事前に配信される情報は、例えば、真に重要な通信を行う可能性のあるＩｏＴ機器９３の一覧およびその時間帯並びにその優先度等である。以下に説明する実施形態では、「通信制御情報」が「スケジューリング情報」である例について説明するが、本開示はこれに限定されない。

また更に、本開示は、中央通信制御装置１０が、災害等の事象発生中においては、逐一配信される通信制御情報に基づき、スケジューリング情報の変更や、通信の優先度に関する情報を逐一配信する。これにより、本開示は、通信を地理的かつ時間的な分散を最適化すると共に、万一、サーバ９２側で通信の集中が発生した際に、通信の優先度に関する情報を用いて、サーバ９２側で重要な通信を選別する事が可能となり、真に重要な通信を確実に行うことができる様になる。

（第１の実施形態）
図３に、本実施形態に係るシステム構成の一例を示す。本開示に係るシステムは、中央通信制御装置１０が、サーバ側契約者データベース１１、ＩｏＴ機器側契約者データベース１２、位置情報対応データベース１３、スケジューリング処理部１４、を備える。

本実施形態では、中央通信制御装置１０は、気象情報サーバ９４から気象情報を取得し、交通情報サーバ９５から道路交通情報を取得し、災害情報サーバ９６から避難情報及び国民保護情報を取得する。気象情報を取得する気象情報サーバ９４は、例えば、気象庁が管理するサーバである。道路交通情報を取得する交通情報サーバ９５は、例えば日本道路交通情報センター（Ｊａｐａｎ Ｒｏａｄ Ｔｒａｆｆｉｃ Ｉｎｆｏｒｍａｔｉｏｎ Ｃｅｎｔｅｒ；ＪＡＲＴＩＣ）が管理するサーバである。避難情報及び国民保護情報を取得する災害情報サーバ９６は、例えば、災害情報共有システムのＬアラートのサーバである。中央通信制御装置１０は、気象情報サーバ９４、交通情報サーバ９５及び災害情報サーバ９６と直接接続されていてもよいが、通信ネットワークで接続されていてもよい。

サーバ側契約者データベース１１は、サーバ９２の設置場所、市外局番、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスを格納する。ＩｏＴ機器側契約者データベース１２は、ＩｏＴ機器９３の設置場所、市外局番、ＩＰアドレスを格納する。位置情報対応データベース１３は、中央通信制御装置１０の収集したイベント情報を、位置情報と紐付けて格納する。

スケジューリング処理部１４は、位置情報対応データベース１３に格納されたイベント情報に基づき、通信スケジュールを策定し、通信スケジューリング情報を通信制御装置２０及び３０に配信する。

位置情報対応データベース１３は、気象情報サーバ９４、交通情報サーバ９５及び災害情報サーバ９６から取得したイベント情報を位置情報と関連付けて格納する。例えば、中央通信制御装置１０は、図４に示すようなデータベースを参照して、各所から配信されるイベント情報に関連する位置情報を市外局番（０ＡＢＣＤ番号〈ＭＡ〉）に変換して、位置情報対応データベース１３に格納する。

図４に示すように、サーバ側契約者表及びＩｏＴ機器側契約者表が位置対応表に関連付けられている。サーバ側契約者表は、サーバ側契約者データベース１１に格納されている、サーバ９２の設置場所、ＩＰアドレス、市外局番を紐付けるテーブルである。ＩｏＴ機器側契約者表は、ＩｏＴ機器側契約者データベース１２に格納されている、ＩｏＴ機器９３の設置場所、ＩＰアドレス、市外局番を紐付けるテーブルである。位置対応表は、配信フラグビット位置と市外局番とを対応づけるテーブルである。「配信フラグビット位置」については後述する。

図４に示すように、交差点コード表、全国地方公共団体コード表、気象警報注意報発表区域表（一次／二次細分区域）、河川コード表、火山コード表が、位置対応表に関連付けられている。交差点コード表は、交差点番号と交差点名称を対応付ける。全国地方公共団体コード表は、地方公共団体コードと地方公共団体名称を対応づける。気象警報注意報発表区域表（一次／二次細分区域）は、発表区域コードと発表区域名称を対応づける。河川コード表は、河川コードと河川名称を対応付ける。火山コード表は、火山コードと火山名称を対応付ける。

気象情報に発表区域名称及び河川名称が含まれている場合、気象警報注意報発表区域表（一次／二次細分区域）及び河川コード表を参照することで、気象情報に含まれている河川名称を市外局番に変換することができる。気象情報に発表区域名称及び火山名称が含まれている場合、気象警報注意報発表区域表（一次／二次細分区域）及び火山コード表を参照することで、火山名称を市外局番に変換することができる。

道路交通情報に地方公共団体名称及び交差点名称が含まれている場合、地方公共団体コード表及び交差点コード表を参照することで、交差点名称を市外局番に変換することができる。

Ｌアラートの情報は、地方公共団体名称が含まれるため、全国地方公共団体コード表を参照することで、市外局番に変換することができる。

図５に、スケジューリング情報を配信するフレーム構成の一例を示す。スケジューリング情報を配信するフレームは、配信対象ＭＡビット列、通信制御開始年月日時分秒、通信制御終了年月日時分秒、制御種別コード、各種通信制御コード、を含む。制御種別コードは制御対象を示すコードである。制御対象としては、例えば、優先度、ウィンドウサイズ、通信帯域、通信パスが例示できる。各種通信制御コードは、制御対象に対する具体的な制御内容を示すコードである。「制御対象」が優先度の場合、制御内容としては、例えば、０〜７の優先度のうちの特定の優先度「７」にする旨や、優先度６以下の通信の優先度を０に変更する旨が例示できる。

「配信対象ＭＡビット列」は、通信制御の対象となる地域を示すビット列であり、市外局番「ＡＢＣＤ」の４桁分の情報で表される。各所から配信されるイベント情報に紐付く位置情報であってもよい。市外局番「ＡＢＣＤ」の４桁分の情報ビット数は、９×９×９×１０＝７２９０ビットとなる。このように、中央通信処理装置１０は、各所から配信される情報の位置情報を市外局番（０ＡＢＣＤ番号〈ＭＡ〉）に変換し、更に「配信対象ＭＡビット列」に変換した上で、通信制御装置２０及び３０にブロードキャスト配信する。

「位置対応表」に格納される「配信フラグビット位置」は、「配信対象ＭＡビット列」の何ビット目を立てるかを示す情報である。例えば、「配信対象ＭＡビット列」のＡＢＣＤの各桁で１０種の数字が利用できる場合、すなわち１０×１０×１０×１０＝１００００ｂｉｔが「配信対象ＭＡビット列」で用いられる場合、市外局番が「０９２」であれば、「配信フラグビット位置」を９２００〜９２９９ｂｉｔに設定し、「ＡＢＣＤ」を「９２ＸＸ」と表すことができる。この「ＸＸ」は「配信フラグビット位置」に用いられる「００」〜「９９」の任意の数字である。このように、図５の「配信対象ＭＡビット列」には、複数の市外局番を格納可能であり、０９２〜０９７といった市外局番の範囲の指定も可能である。

「配信対象ＭＡビット列」が図５に示すような９×９×９×１０＝７２９０ｂｉｔの場合、市外局番の数字「０９２」を「９２ＸＸ」と表すことができない。そこで、本開示では、市外局番に対応したビット位置が簡単に導出できるよう、位置対応表を参照する。例えば、市外局番「０９２」に対応する「配信フラグビット位置」として６５７１〜６６６０ｂｉｔを対応付ける。これにより、位置対応表を参照することで、「配信対象ＭＡビット列」から市外局番を簡単に導出することができる。

スケジューリング情報を配信するフレームは、一見、長大なビット列であるが、バイト換算すると９１２バイトである。プリアンブルを除いた先頭からＦＣＳまでの全情報で１３６５バイト、つまり、イーサネット（登録商標）フレーム（Ｅｔｈｅｒｎｅｔ Ｆｒａｍｅ）の最大フレーム長である１５１８バイト以下に収まる。このため、イーサネットおよびＩＰｖ６のＵＤＰのヘッダや他の必要な情報を実装しても十分実装でき、１つのパケットで十分にスケジューリング情報を全装置に対してブロードキャスト配信が可能である。したがって、緊急地震速報や国民保護情報等の情報に基づく緊急性の高いスケジュール配信においても速やかな配信が可能である。

サーバ９２側は、中央通信処理装置１０から配信されたスケジューリング情報に基いて、各ＩｏＴ機器９３との通信を行うが、ＩＰｖ６のＵＬＡ（ユニークローカルＩＰｖ６ユニキャストアドレス）やサイトローカルアドレスを用いてＩｏＴ機器９３側のアドレス割当を行うと、効率的な処理が行える。

図６に、各ＩｏＴ機器９３のアドレス割当例を示す。ＵＬＡを用いたアドレス割当実装例であり、ＵＬＡのサブネットＩＤ（２バイト）の各ニブル（４ビット）に対して市外局番（０ＡＢＣＤ番号〈ＭＡ〉）の各番号領域を割り当てている。このようにすれば、サーバ９２側は受信したスケジューリング情報の配信対象ＭＡビット列から、ＡＣＬ（アクセスコントロールリスト）を設定する際に、サブネットＩＤに対して市外局番情報を割り当ててＡＣＬを生成すればよいので、効率的な処理が行える。またＩｏＴ機器９３側では自身に設定されているＩＰｖ６アドレスのサブネットＩＤを用いて、受信したスケジューリング情報が自身が対象かどうかの判定が容易に行える。

図７に、サーバ９２側の通信制御装置２０の構成の一例を示す。通信制御装置２０は、ルータ部２１、スケジューリング情報処理部２２、スケジューリング情報受信部２３、通信対象リスト２４、スケジューリングＤＢ２５を備える。

通信対象リスト２４は、サーバ９２と通信を行う通信対象のリストを格納する。通信対象のリストは、通信対象となるＩｏＴ機器９３の設置場所、市外局番、ＩＰアドレスを含む。スケジューリングＤＢ２５は、通信対象との通信スケジュールを格納するデータベースである。

図８に、ＩｏＴ機器９３側の通信制御装置３０の構成の一例を示す。通信制御装置３０は、ルータ部３１、スケジューリング情報処理部３２、スケジューリング情報受信部３３、スケジューリングＤＢ３５を備える。スケジューリングＤＢ３５は、制御対象であるＩｏＴ機器９３の通信スケジュールを格納するデータベースである。

図９に、中央通信制御装置１０の処理フローの一例を示す。中央通信制御装置１０は、ステップＳ１０１を行い、その後ステップＳ１０２〜Ｓ１０４を行い、その後ステップＳ１０５を行う。
ステップＳ１０１では、中央通信制御装置１０が、防災気象情報等のイベント情報を受信する。
ステップＳ１０２では、中央通信制御装置１０が、イベント情報から、優先対象地域情報および日時情報を抽出する。ステップＳ１０３では、中央通信制御装置１０が、対象地域情報を市外局番情報に変換する。ステップＳ１０４では、中央通信制御装置１０が、スケジューリング情報パケットの情報を組み立てる。
ステップＳ１０５では、中央通信制御装置１０が、対象地域に関らず、スケジューリング情報パケットをブロードキャスト配信する。

図１０に、サーバ９２側のスケジューリング情報受信部２３がスケジューリング情報を受信した際の通信制御装置２０の処理フローの一例を示す。
まずスケジューリング情報のパケットを受信する（Ｓ２１１）。
次に、パケット中の配信対象ＭＡビット列に通信対象が含まれているかどうかを判断する（Ｓ２１２）。例えば、スケジューリング情報処理部２２は、通信対象リスト２４のＩｏＴ機器９３の設置場所を示す市外局番のなかに、通信スケジューリング情報中の配信対象ＭＡビット列と一致するものがあるか否かを判定する。
配信対象ＭＡビット列に通信対象が含まれていない場合、処理を終了する。
一方、配信対象ＭＡビット列に通信対象が含まれている場合、スケジューリング情報処理部２２は、スケジューリングＤＢ２５から通信スケジュールを読み出し、通信スケジューリング情報に従って、通信対象との通信スケジュールを設定し、スケジューリングＤＢ２５を更新する（Ｓ２１３）。

ここで、サーバ９２側の通信スケジュールの設定は、例えば、優先通信サービスの使用、通信パスの設定、優先度識別子の付加、通信帯域の制限、通信フローの制御（ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）ウィンドウ制御等）、通信対象リスト以外の装置に関する通信の抑制・排除が例示できる。優先度識別子の付加としては、例えば、ＩＰｖ４パケットのヘッダに設定された送受信の優先順位を指定するＴｏＳ（Ｔｙｐｅ ｏｆ Ｓｅｒｖｉｃｅ）、イーサネットフレームのＶＬＡＮタグに設定された送受信の優先順位を指定するＣｏＳ（Ｃｌａｓｓ ｏｆ Ｓｅｒｖｉｃｅ）、ＩＰｖ６パケットのヘッダ内の８ｂｉｔの情報で、優先順位を指定するＴＣ（Ｔｒａｆｆｉｃ Ｃｌａｓｓ）が例示できる。

図１１に、サーバ９２側のスケジューリング情報処理部２２の処理フローの一例を示す。スケジューリング情報処理部２２は、スケジューリングＤＢ２５を参照し（Ｓ２２１）、スケジュール時刻が到来したときに（Ｓ２２２においてＹｅｓ）、ルータ部２１に対して各種通信制御のコマンド指示／解除を行う（Ｓ２２３）。

図１２に、ＩｏＴ機器９３側のスケジューリング情報受信部３３の処理フローの一例を示す。スケジューリング情報のパケットを受信すると（Ｓ３１１）、パケット中の配信対象ＭＡビット列から対象かどうかを判断する（Ｓ３１２）。そして、対象である場合は（Ｓ３１２においてＹｅｓ）、スケジューリングＤＢ３５から通信スケジュールを読み出し、通信スケジューリング情報に従って制御対象のＩｏＴ機器９３の通信スケジュールを設定し、スケジューリングＤＢ３５を更新する。一方、対象でない場合は（Ｓ３１２においてＮｏ）、処理を終了する。

ここで、スケジューリング情報受信部３３は、自装置の所属するＭＡ番号（０ＡＢＣＤ番号）を保持する。これにより、ステップＳ３１２において、受信したスケジューリング情報の制御対象に自装置が含まれるかどうかの判定を行う。

図１３に、ＩｏＴ機器９３側のスケジューリング情報処理部３２の処理フローの一例を示す。スケジューリング情報処理部３２は、スケジューリングＤＢ３５を参照し（Ｓ３２１）、スケジュール時刻が到来したときに（Ｓ３２２においてＹｅｓ）、ルータ部３１に対して各種通信制御のコマンド指示／解除を行う（Ｓ３２３）。

ＩｏＴ機器９３の通信スケジュールの設定は、例えば、優先通信サービスの使用、通信パスの設定、優先度識別子の付加（ＴｏＳ，ＣｏＳ，ＴＣ等）、通信帯域の制限、通信フローの制御（ＴＣＰウィンドウ制御等）、自装置内又は近隣代替サーバへの通信の蓄積、並びに遅延再送信による不要不急な通信の抑制が例示できる。

（第２の実施形態）
図１４を参照しながら、台風発生時の本開示に係るシステムの動作の一例を説明する。本実施形態は、台風来襲前に、気象予報情報から、来襲予定地域およびサーバに対して事前に通信のスケジューリング情報の配信を行う。

中央通信制御装置１０は、１月５日の朝〜昼に九州に台風が来襲し、１月６日の昼〜夕に関西に台風が来襲する、という情報を、イベント情報として取得する。この場合、中央通信制御装置１０は、スケジューリング情報として、第１〜第４のフレームをブロードキャスト配信する。

・第１のフレーム
通信制御開始年月日時分秒：○○○○年１月５日５時００分○秒
通信制御終了年月日時分秒：○○○○年１月５日１２時００分○秒
配信対象ＭＡビット列：０９２〜０９７，０９８２〜０９８７，０９９
制御種別コード：優先度識別子（ＴＣ）の変更
各種通信制御コード：全通信の優先度を７へ変更
ここで、「０９２〜０９７，０９８２〜０９８７，０９９」は九州の市外局番である。
・第２のフレーム
通信制御開始年月日時分秒：○○○○年１月５日５時００分○秒
通信制御終了年月日時分秒：○○○○年１月５日１８時００分○秒
配信対象ＭＡビット列：０１〜０４
制御種別コード：優先度識別子（ＴＣ）の変更
各種通信制御コード：優先度６以下の通信の優先度を０へ変更
ここで、「０１〜０４」は東日本の市外局番である。
・第３のフレーム
通信制御開始年月日時分秒：○○○○年１月５日１２時００分○秒
通信制御終了年月日時分秒：○○○○年１月５日１８時００分○秒
配信対象ＭＡビット列：０６，０７２〜０７５，０７７１〜０７７５，０７８〜０７９
制御種別コード：優先度識別子（ＴＣ）の変更
各種通信制御コード：全通信の優先度を７へ変更
ここで、「０６，０７２〜０７５，０７７１〜０７７５，０７８〜０７９」は関西の市外局番である。
・第４のフレーム
通信制御開始年月日時分秒：○○○○年１月５日５時００分○秒
通信制御終了年月日時分秒：○○○○年１月５日１８時００分○秒
配信対象ＭＡビット列：０１〜０４
制御種別コード：ＴＣＰウィンドウサイズの変更
各種通信制御コード：優先度６以下の通信のウィンドウサイズを１３００バイトに変更
ここで、「０１〜０４」は東日本の市外局番である。

各通信制御装置３０は、第１〜第３のフレームに従い、以下のような通信制御を行う。例えば、九州の通信制御装置３０は、１月５日の１月５日５時００分〜１２時００分に優先度「７」で通信する。関西の通信制御装置３０は、１月５日の１２時００分〜１８時００分に優先度「７」で通信する。東日本の通信制御装置３０は、１月５日の５時００分〜１８時００分に優先度「０」で通信する。

通信制御装置２０は、第４のフレームに従い、以下のような通信制御を行う。１月５日の５時００分〜１８時００分の間は、優先度６以下の通信のウィンドウサイズを１３００バイトにする。これにより、本実施形態では、サーバ９２は台風が来襲する地域の通信を優先的に受信するため、真に重要な通信を受信することができる。

（第３の実施形態）
図１５を参照しながら、台風来襲中の本開示に係るシステムの動作の一例を説明する。本実施形態は、事前配信された通信スケジュールに従い通信制御を行う。また、最新の台風情報から、スケジューリング情報を適宜変更して配信する。

中央通信制御装置１０は、台風の九州の上陸時に特別警報が熊本に発令され、台風の進路が変わり、関西へは来襲しない、という情報を、イベント情報として取得する。この場合、中央通信制御装置１０は、通信制御装置２０及び３０に、以下のスケジューリング情報を配信する。

例えば、中央通信制御装置１０は、九州の通信制御装置３０に対しては優先通信サービスを使って通信し、関西及び東日本の通信制御装置３０に対しては不要不急な通信を抑制する旨のスケジューリング情報を配信する。ここで、優先通信サービスを使った通信としては、例えば、優先度を「７」することが例示できる。不要不急な通信を抑制するための制御としては、例えば、第２の実施形態と同様に、優先度を「０」とすることが例示できる。

例えば、中央通信制御装置１０は、通信制御装置２０に対し、熊本からの通信を優先し、関西からは重要通信は来ない見込みである旨、のスケジューリング情報を配信する。熊本からの通信を優先し、関西からは重要通信は来ない見込みの制御としては、例えば、優先度「７」の通信を優先することが例示できる。

本実施形態では、サーバ９２は熊本からの通信を優先的に受信するため、真に重要な通信を受信することができる。

（第４の実施形態）
図１６を参照しながら、地震発生前の本開示に係るシステムの動作の一例を説明する。本実施形態は、緊急地震速報（予報）に基づき地震発生地域およびサーバに対して通信のスケジューリング情報の配信を行う。

中央通信制御装置１０は、地域「宮城中部」、予想震度「震度５」到達予定時間「２０秒後」などの緊急地震速報（予報）を、イベント情報として取得する。この場合、中央通信制御装置１０は、通信制御装置２０及び３０に、以下のスケジューリング情報を配信する。

例えば、中央通信制御装置１０は、通信制御装置２０に対し、２０秒後に東日本の装置から重要通信がある見込みである旨、及び特に宮城からの通信を優先する旨、のスケジューリング情報を配信する。

例えば、中央通信制御装置１０は、東日本の通信制御装置３０に対しては２０秒後以降に優先通信を使って通信し、九州及び関西の通信制御装置３０に対しては２０秒後以降に不要不急な通信を抑制する旨のスケジューリング情報を配信する。

（第５の実施形態）
図１７を参照しながら、地震発生後の本開示に係るシステムの動作の一例を説明する。本実施形態は、配信された通信スケジュールに従い通信制御を行う。また、震度速報等の地震情報から、スケジューリング情報を適宜変更して配信する。

中央通信制御装置１０は、各地の震度情報を取得する。例えば、岩手の震度６であり、大阪の震度が１であり、熊本の震度が０である旨を、イベント情報として取得する。この場合、中央通信制御装置１０は、通信制御装置２０及び３０に、以下のスケジューリング情報を配信する。

例えば、中央通信制御装置１０は、通信制御装置２０に対し、九州からは重要通信は来ない見込みである旨、及び岩手からの通信を優先する旨、のスケジューリング情報を配信する。

例えば、中央通信制御装置１０は、東日本の通信制御装置３０に対しては優先通信サービスを使って通信し、九州及び関西の通信制御装置３０に対しては不要不急な通信を抑制する旨のスケジューリング情報を配信する。

本実施形態では、サーバ９２は岩手からの通信を優先的に受信するため、真に重要な通信を受信することができる。

（第６の実施形態）
図１８を参照しながら、イベント開催日前日の本開示に係るシステムの動作の一例を説明する。本実施形態は、道路交通情報に基づき交通規制地域およびサーバに対して通信のスケジューリング情報の配信を行う。

中央通信制御装置１０は、明日の昼〜夜に大阪でイベントに伴う交通規制が実施予定である旨を、イベント情報として取得する。この場合、中央通信制御装置１０は、通信制御装置２０及び３０に、以下のスケジューリング情報を配信する。

例えば、中央通信制御装置１０は、通信制御装置２０に対し、明日の昼〜夜に関西の装置から優先通信がある見込みである旨、のスケジューリング情報を配信する。

例えば、中央通信制御装置１０は、関西の通信制御装置３０に対しては明日の昼〜夜に優先通信サービスを使って通信する旨、のスケジューリング情報を配信する。

（第７の実施形態）
図１９を参照しながら、イベント開催日の本開示に係るシステムの動作の一例を説明する。本実施形態は、事前配信された通信スケジュールに従い通信制御を行う。また、最新の道路規制情報から、スケジューリング情報を適宜変更して配信する。

中央通信制御装置１０は、イベントに伴う交通規制が今日の昼から明朝に延長された旨を、イベント情報として取得する。この場合、中央通信制御装置１０は、通信制御装置２０及び３０に、以下のスケジューリング情報を配信する。延長された旨は、例えば、「通信制御開始年月日時分秒」及び「通信制御終了年月日時分秒」を再度設定することで行う。

例えば、中央通信制御装置１０は、通信制御装置２０に対し、スケジュールが変更され、明朝まで関西の装置は優先通信を行う旨、のスケジューリング情報を配信する。

例えば、中央通信制御装置１０は、関西の通信制御装置３０に対してはスケジュール変更し、明朝まで優先通信サービスを使って通信する旨、のスケジューリング情報を配信する。

本実施形態では、サーバ９２は関西からの通信を優先的に受信するため、ネットワーク輻輳を回避し、真に重要な通信を受信することができる。

本開示の各装置はコンピュータとプログラムによっても実現でき、プログラムを記録媒体に記録することも、ネットワークを通して提供することも可能である。

本開示は情報通信産業に適用することができる。

１０：中央通信制御装置
１１：サーバ側契約者データベース
１２：ＩｏＴ機器側契約者データベース
１３：位置情報対応データベース
１４：スケジューリング処理部
２０、３０：通信制御装置
２１：ルータ部
２２：スケジューリング情報処理部
２３：スケジューリング情報受信部
２４：通信対象リスト
２５、３５：スケジューリングＤＢ
３１：ルータ部
３２：スケジューリング情報処理部
３３：スケジューリング情報受信部
９２：サーバ
９３：ＩｏＴ機器
９４：気象情報サーバ
９５：交通情報サーバ
９６：災害情報サーバ
９７：サーバ

Claims (8)

1. 地理的に分散して配置されている複数の機器が接続されている通信ネットワークに含まれる前記機器ごとに備わり、配信された通信制御情報に従って個々の前記機器の通信を制御する、複数の通信制御装置と、
   前記複数の通信制御装置に対して前記通信制御情報を配信する中央通信制御装置と、を備え、
   前記中央通信制御装置は、
   位置情報と紐付いたイベント情報を収集し、
   収集したイベント情報を用いて、通信量の増加する可能性のある地域を判定し、
   通信量の増加する可能性のある地域がある場合には、当該地域の通信を優先する通信制御情報を生成し、
   生成した通信制御情報を前記複数の通信制御装置に配信する、
   通信ネットワーク制御システム。
2. 前記中央通信制御装置は、
   収集したイベント情報を用いて、通信量の増加する可能性のある地域及び時間を判定し、
   通信量の増加する可能性のある地域がある場合には、通信量の増加する可能性のある時間において当該地域の通信を優先する通信制御情報を生成する、
   請求項１に記載の通信ネットワーク制御システム。
3. 前記複数の機器はサーバを含み、
   サーバに備わる前記通信制御装置は、配信された通信制御情報に従い、通信量の増加する可能性のある時間に、通信量の増加する可能性のある地域との通信を優先する、
   請求項２に記載の通信ネットワーク制御システム。
4. 前記複数の機器は、ＩｏＴ機器を含み、
   サーバに備わる前記通信制御装置は、前記中央通信制御装置から受信した通信制御情報を用いて、サーバと通信を行うＩｏＴ機器のアクセスコントロールリストを作成し、前記アクセスコントロールリストを各ＩｏＴ機器へ配信し、
   ＩｏＴ機器に備わる前記通信制御装置は、サーバに備わる前記通信制御装置から受信したアクセスコントロールリストに従って、サーバへのアクセスを行う、
   請求項３に記載の通信ネットワーク制御システム。
5. 前記通信制御情報は、地域を特定する情報として市外局番が用いられ、
   前記アクセスコントロールリストのサブネットＩＤに市外局番が割り当てられている、
   請求項４に記載の通信ネットワーク制御システム。
6. 地理的に分散して配置されている複数の機器が接続されている通信ネットワークに含まれる前記機器ごとに備わり、配信された通信制御情報に従って個々の前記機器の通信を制御する、複数の通信制御装置と、
   前記複数の通信制御装置に対して前記通信制御情報を配信する中央通信制御装置と、を備える通信ネットワーク制御システムにおける、前記中央通信制御装置であって、
   位置情報と紐付いたイベント情報を収集し、
   収集したイベント情報を用いて、通信量の増加する可能性のある地域を判定し、
   通信量の増加する可能性のある地域がある場合には、当該地域の通信を優先する通信制御情報を生成し、
   生成した通信制御情報を前記複数の通信制御装置に配信する、
   中央通信制御装置。
7. 地理的に分散して配置されている複数の機器が接続されている通信ネットワークに含まれる前記機器ごとに備わり、配信された通信制御情報に従って個々の前記機器の通信を制御する、複数の通信制御装置と、
   前記複数の通信制御装置に対して前記通信制御情報を配信する中央通信制御装置と、を備える通信ネットワーク制御システムにおける、
   前記中央通信制御装置が実行する通信制御方法であって、
   前記中央通信制御装置は、
   位置情報と紐付いたイベント情報を収集し、
   収集したイベント情報を用いて、通信量の増加する可能性のある地域を判定し、
   通信量の増加する可能性のある地域がある場合には、当該地域の通信を優先する通信制御情報を生成し、
   生成した通信制御情報を前記複数の通信制御装置に配信する、
   通信制御方法。
8. 請求項６に記載の中央通信制御装置に備わる各機能を、コンピュータに実現させるための通信制御プログラム。

Images