特許 5677524 通信制御装置、通信制御システム及び通信制御方法

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

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

(11)【特許番号】5677524

(24)【登録日】2015年1月9日

(45)【発行日】2015年2月25日

(54)【発明の名称】通信制御装置、通信制御システム及び通信制御方法

(51)【国際特許分類】

   H04L 12/801 20130101AFI20150205BHJP

   G06F 13/00 20060101ALI20150205BHJP

   H04L 12/70 20130101ALI20150205BHJP

【ＦＩ】

   H04L12/801

   G06F13/00 357Z

   H04L12/70 100Z

【請求項の数】12

【全頁数】20

(21)【出願番号】特願2013-148858(P2013-148858)

(22)【出願日】2013年7月17日

(65)【公開番号】特開2015-23364(P2015-23364A)

(43)【公開日】2015年2月2日

【審査請求日】2013年8月6日

(73)【特許権者】

【識別番号】000208891

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

(74)【代理人】

【識別番号】100166006

【弁理士】

【氏名又は名称】泉 通博

(74)【代理人】

【識別番号】100124084

【弁理士】

【氏名又は名称】黒岩 久人

(72)【発明者】

【氏名】杉田 徹哉

(72)【発明者】

【氏名】寺下 雅人

【審査官】 大石 博見

(56)【参考文献】

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

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

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

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

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

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

Ｈ０４Ｌ １２／８０１

Ｇ０６Ｆ １３／００

Ｈ０４Ｌ １２／７０

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

【請求項1】

端末からサーバに送信されたリクエストの数を監視するトラヒック監視部と、
前記リクエストの数に基づいて輻輳を検出する輻輳検出部と、
前記輻輳検出部が前記輻輳を検出した場合に、前記端末に対して前記サーバが送信するレスポンスの代わりとなる代理レスポンスを送信する代理応答部とを備える、
通信制御装置。

【請求項2】

前記代理応答部は、前記輻輳検出部が前記輻輳を検出した場合に、前記端末に対して、前記リクエストに対応するアプリケーションに対して輻輳制御効果がある前記代理レスポンスを送信する、
請求項１に記載の通信制御装置。

【請求項3】

前記トラヒック監視部は、前記サーバから送信された前記レスポンスの数を監視し、
前記輻輳検出部は、前記リクエストの数と前記レスポンスの数との比率に基づいて前記輻輳を検出する、
請求項１又は２に記載の通信制御装置。

【請求項4】

前記トラヒック監視部は、前記サーバにリクエストを送信した前記端末の数を監視し、
前記輻輳検出部は、前記リクエストの数と前記レスポンスの数との比率、及び前記端末の数に基づいて前記輻輳を検出する、
請求項３に記載の通信制御装置。

【請求項5】

前記トラヒック監視部は、複数の前記端末のうちの一部の端末から送信された前記リクエストの数と、当該サーバから前記一部の端末に送信された前記レスポンスの数とを監視する、
請求項３又は４に記載の通信制御装置。

【請求項6】

前記代理応答部は、前記リクエストに基づいて前記サーバが管理するアプリケーションを特定し、複数のプロトコルのうち、当該アプリケーションに対して輻輳制御効果があるプロトコルを選択し、選択したプロトコルに対応する前記代理レスポンスを送信する、
請求項３から５のいずれか１項に記載の通信制御装置。

【請求項7】

前記代理応答部は、前記リクエストに基づいて前記アプリケーションが備える機能を特定し、前記複数のプロトコルのうち、当該機能に対して輻輳制御効果があるプロトコルを選択する、
請求項６に記載の通信制御装置。

【請求項8】

前記代理応答部は、前記リクエストに基づいて前記端末のオペレーティングシステムを特定し、前記複数のプロトコルのうち、当該オペレーティングシステム上で実行される前記アプリケーションの機能に対して輻輳制御効果があるプロトコルを選択する、
請求項７に記載の通信制御装置。

【請求項9】

前記代理応答部は、前記サーバの代わりに前記代理レスポンスを送信した後、前記トラヒック監視部が監視した前記リクエストの数と前記レスポンスの数との比率に基づいて、前記代理レスポンスを送信したことによる輻輳制御効果を測定し、前記輻輳制御効果に基づいて、未だ選択されていない前記複数のプロトコルから、前記輻輳制御効果があるプロトコルを再選択する、
請求項６から８のいずれか１項に記載の通信制御装置。

【請求項10】

前記代理応答部は、
前記代理レスポンスを送信する対象である制御対象端末数を算出し、
前記輻輳時に前記端末が前記リクエストを送信する輻輳時リトライ間隔に相当する時間において前記代理レスポンスを送信可能な端末数と、前記制御対象端末数とに基づいて、前記代理レスポンスを送信する対象の前記端末の集合を示すブロックの数を算出し、
前記ブロックの数と、前記輻輳が発生していない場合に前記端末がリクエストを送信する通常時リトライ間隔とに基づいて、１ブロックあたりの前記代理レスポンスを送信する制御を実行する制御実行時間を特定し、
前記ブロックのそれぞれについて、当該制御実行時間にわたって前記制御を実行する、
請求項１から９のいずれか１項に記載の通信制御装置。

【請求項11】

端末と、前記端末とサーバとの間の通信を制御する通信制御装置とを備える通信制御システムであって、
前記端末は、前記サーバにリクエストを送信し、
前記通信制御装置は、
前記端末から前記サーバに送信された前記リクエストの数を監視するトラヒック監視部と、
前記リクエストの数に基づいて輻輳を検出する輻輳検出部と、
前記輻輳検出部が前記輻輳を検出した場合に、前記端末に対して前記サーバが送信するレスポンスの代わりに代理レスポンスを送信する代理応答部とを有する通信制御装置と、
を備える、
通信制御システム。

【請求項12】

端末とサーバとの間の通信を制御する通信制御方法であって、
前記端末から前記サーバに送信されたリクエストの数を監視するステップと、
前記リクエストの数に基づいて輻輳を検出するステップと、
前記輻輳を検出した場合に、前記端末に対して前記サーバが送信するレスポンスの代わりに代理レスポンスを送信するステップと、を備える、
通信制御方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、輻輳を制御する通信制御装置、通信制御システム及び通信制御方法に関する。

【背景技術】

【0002】

従来、ネットワーク障害への対策として、リクエストに対応するレスポンスがあるか否かに基づいてアクセス成否回数を計数して、当該アクセス成否回数からアクセス成功率を算出し、当該アクセス成功率に基づいて、ネットワーク障害があるか否かを判定する方法が知られている（例えば、特許文献１参照）。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２００９−１７１００９号公報

【発明の概要】

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

【0004】

ところで、サーバにおいて障害が発生すると、端末からのリクエストに対応するサーバからのレスポンスが遅くなる。そして、サーバとの通信を行なっていた端末は、サーバからレスポンスを受信できなかった場合に、サーバに対してリクエストの再送を繰り返す。すると、サーバにおいて障害が発生していない場合に比べて、端末からサーバに送信されるリクエスト数が増加して輻輳が発生する。

【0005】

しかしながら、従来の、アクセス成否回数から求められたアクセス成功率に基づいて、ネットワーク障害があるか否かを判定する方法では、リクエストに対応するレスポンスがあるか否かに基づいてアクセス成否回数を計数することから、アクセス成否回数の算出が遅くなってしまう。このため、輻輳の検出を早期に行うことができないという問題があった。

【0006】

そこで、本発明はこれらの課題を解決するためになされたものであり、輻輳の発生を早期に検出して制御することができる通信制御装置、通信制御システム及び通信制御方法を提供することを目的とする。

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

【0007】

本発明の第１の態様に係る通信制御装置（例えば、後述の通信制御装置１）は、端末からサーバに送信されたリクエストの数を監視するトラヒック監視部（例えば、後述のトラヒック監視部１２１）と、前記リクエストの数に基づいて輻輳を検出する輻輳検出部（例えば、後述の輻輳検出部１２２）と、前記輻輳検出部が前記輻輳を検出した場合に、前記端末に対して前記サーバが送信するレスポンスの代わりとなる代理レスポンスを送信する代理応答部（例えば、後述の代理応答部１２３）とを備えることを特徴とする。

【0008】

この発明によれば、輻輳検出部がリクエストの数に基づいて輻輳を検出するので、サーバからリクエストに対応するレスポンスが送信されない場合であっても早期に輻輳を検出することができる。また、代理応答部が、端末に対してサーバが送信するレスポンスの代わりとなる代理レスポンスを送信するので、端末において代理レスポンスに基づいてエラー表示等を行わせて、レスポンスを受信しないことによるリクエストの再送を抑制することができる。よって、通信制御装置は、輻輳の発生を早期に検出して制御することができる。

【0009】

また、前記トラヒック監視部は、前記サーバから送信された前記レスポンスの数を監視し、前記輻輳検出部は、前記リクエストの数と前記レスポンスの数との比率に基づいて前記輻輳を検出することを特徴とする。

【0010】

この発明によれば、輻輳検出部が、リクエストの数と、サーバから送信されたレスポンスの数との比率に基づいて輻輳を検出するので、通信制御装置は、サーバにおいて障害等が発生してレスポンスが正常に送信されていない場合に輻輳を検出することができる。よって、通信制御装置は、リクエストの数のみに基づいて輻輳を検出する場合に比べて、精度よく輻輳を検出することができる。

【0011】

また、前記トラヒック監視部は、前記サーバにリクエストを送信した前記端末の数を監視し、前記輻輳検出部は、前記リクエストの数と前記レスポンスの数との比率、及び前記端末の数に基づいて前記輻輳を検出することを特徴とする。

【0012】

この発明によれば、通信制御装置は、サーバに対してリクエストを送信している端末の数が多い場合に限定して輻輳を検出することができるので、限られた台数の端末が意図的に再送を繰り返しているときに輻輳と検出せず、さらに精度よく輻輳を検出することができる。

【0013】

また、前記トラヒック監視部は、複数の前記端末のうちの一部の端末から送信された前記リクエストの数と、当該サーバから前記一部の端末に送信された前記レスポンスの数とを監視することを特徴とする。

【0014】

ここで、一の通信事業者のコアネットワークを介して通信する端末は、数千万台である。この発明によれば、通信制御装置は、例えば、数千万台の端末からサンプリングした数千台の端末に基づいて輻輳を検出することができるので、通信制御装置を過負荷とすることなく、輻輳を検出することができる。

【0015】

また、前記代理応答部は、前記リクエストに基づいて前記サーバが管理するアプリケーションを特定し、複数のプロトコルのうち、当該アプリケーションに対して輻輳制御効果があるプロトコルを選択し、選択したプロトコルに対応する前記代理レスポンスを送信する。
また、前記代理応答部は、前記リクエストに基づいて前記アプリケーションが備える機能を特定し、前記複数のプロトコルのうち、当該機能に対して輻輳制御効果があるプロトコルを選択する。
また、前記代理応答部は、前記リクエストに基づいて前記端末のオペレーティングシステムを特定し、前記複数のプロトコルのうち、当該オペレーティングシステム上で実行される前記アプリケーションの機能に対して輻輳制御効果があるプロトコルを選択する。

【0016】

この発明によれば、通信制御装置は、アプリケーションの機能それぞれに対して適したプロトコルによって代理レスポンスを送信するので、効果的に輻輳を制御することができる。また、通信制御装置は、アプリケーションがオペレーティングシステムごとに異なる通信制御を行っていても、アプリケーションごと、かつ、オペレーティングシステムごとに、輻輳制御効果があるプロトコルを選択して効果的に輻輳を制御することができる。

【0017】

また、前記代理応答部は、前記サーバの代わりに前記代理レスポンスを送信した後、前記トラヒック監視部が監視した前記リクエストの数と前記レスポンスの数との比率に基づいて、前記代理レスポンスを送信したことによる輻輳制御効果を測定し、前記輻輳制御効果に基づいて、未だ選択されていない前記複数のプロトコルから、前記輻輳制御効果があるプロトコルを再選択する。

【0018】

この発明によれば、通信制御装置は、選択したプロトコルによる輻輳制御効果がない場合に、新たにプロトコルを選択して輻輳制御を行う。このようにすることで、通信制御装置は、一のプロトコルによる輻輳制御効果が小さい場合であっても、複数のプロトコルによって輻輳制御を行うので、より確実に輻輳を制御することができる。

【0019】

また、前記代理応答部は、前記代理レスポンスを送信する対象である制御対象端末数を算出し、前記輻輳時に前記端末が前記リクエストを送信する輻輳時リトライ間隔に相当する時間において前記代理レスポンスを送信可能な端末数と、前記制御対象端末数とに基づいて、前記代理レスポンスを送信する対象の前記端末の集合を示すブロックの数を算出し、前記ブロックの数と、前記輻輳が発生していない場合に前記端末がリクエストを送信する通常時リトライ間隔とに基づいて、１ブロックあたりの前記代理レスポンスを送信する制御を実行する制御実行時間を特定し、前記ブロックのそれぞれについて、当該制御実行時間にわたって前記制御を実行することを特徴とする。

【0020】

この発明によれば、通信制御装置は、例えば、制御対象端末数が数千万台であっても、分割して処理を行うことで、通信制御装置に係る負荷を大幅に抑制することができる。また、処理を複数のブロックに分割し、さらに複数のブロックそれぞれの制御実行時間を、正常時リトライ間隔に基づいて調整するので、複数のブロックそれぞれについて、均一に輻輳制御を行うことができる。また、通信制御装置は、各ブロックに対して制御を行った後、当該制御の効果の有無を判定し、効果があると判定した場合にのみ、次のブロックに対して制御を行う。これにより、負荷を抑制する効果のない制御を行った場合の影響範囲を一のブロックに限定し、他のブロックに対する当該制御の実行を防止することができる。

【0021】

本発明の第２の態様に係る通信制御システムは、端末と、前記端末とサーバとの間の通信を制御する通信制御装置とを備える通信制御システムであって、前記端末は、前記サーバにリクエストを送信し、前記通信制御装置は、前記端末から前記サーバに送信された前記リクエストの数を監視するトラヒック監視部と、前記リクエストの数に基づいて輻輳を検出する輻輳検出部と、前記輻輳検出部が前記輻輳を検出した場合に、前記端末に対して前記サーバが送信するレスポンスの代わりに代理レスポンスを送信する代理応答部とを有する通信制御装置と、を備えることを特徴とする。

【0022】

本発明の第３の態様に係る通信制御方法は、端末とサーバとの間の通信を制御する通信制御方法であって、前記端末から前記サーバに送信されたリクエストの数を監視するステップと、前記リクエストの数に基づいて輻輳を検出するステップと、前記輻輳を検出した場合に、前記端末に対して前記サーバが送信するレスポンスの代わりに代理レスポンスを送信するステップと、を備える。

【0023】

これらの発明によれば、第１の態様に係る通信制御装置と同等の効果を奏することができる。

【発明の効果】

【0024】

本発明によれば、輻輳の発生を早期に検出して制御することができる。

【図面の簡単な説明】

【0025】

【図1】第１の実施形態に係る通信制御システムの概要図である。

【図2】第１の実施形態に係る通信制御装置の機能構成図である。

【図3】第１の実施形態に係る輻輳監視処理のフローチャートである。

【図4】第１の実施形態に係る輻輳制御処理のフローチャートである。

【図5】第１の実施形態に係る制御効果測定処理のフローチャートである。

【図6】第１の実施形態に係るプロトコル別効果情報の一例を示す図である。

【図7】第１の実施形態に係る制御効果測定処理の検証結果を示す図である。

【図8】第２の実施形態に係る複数のブロックに分割して輻輳制御を行った場合のトラヒックの変化を説明する図である。

【図9】第２の実施形態に係る輻輳制御処理のフローチャートである。

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

【0026】

以下、本発明の実施形態について説明する。
＜第１の実施形態＞
［通信制御システムＳの概要］
図１は、第１の実施形態に係る通信制御システムＳの概要図である。
通信制御システムＳは、通信制御装置１と、複数の携帯端末２（携帯端末２Ａ、携帯端末２Ｂ、携帯端末２Ｃ・・・）と、複数のサーバ３（サーバ３Ａ、サーバ３Ｂ、サーバ３Ｃ）と、コアネットワーク４と、Ｌ１（レイヤ１）スイッチ５と、ゲートウェイ６と、インターネット７とを備える。

【0027】

携帯端末２は、コアネットワーク４、Ｌ１スイッチ５、ゲートウェイ６及びインターネット７を介してサーバ３に通信可能に接続されている。携帯端末２は、サーバ３との通信を行うアプリケーションがインストールされている。携帯端末２において当該アプリケーションが実行されると、当該アプリケーションは、サーバ３に対して定期的にリクエストを送信する。ここで、リクエストとは、携帯端末２からサーバ３に対して送信されるコマンド全般を示す。携帯端末２は、サーバ３からレスポンスを受信できる場合、すなわち、通常時には、通常時のリトライ間隔でリクエストを送信し、サーバ３から当該リクエストに対する応答であるレスポンスを受信できなかった場合には、輻輳時のリトライ間隔でリクエストをサーバ３に再送する。

【0028】

コアネットワーク４は、所定の通信事業者の基幹通信回線である。Ｌ１スイッチ５は、コアネットワーク４を通過するパケットをレイヤ１で複製する装置であり、携帯端末２が送信するリクエストをサーバ３及び通信制御装置１に送信するとともに、当該リクエストに対応するレスポンスを携帯端末２及び通信制御装置１に送信する。

【0029】

サーバ３は、携帯端末２にインストールされているアプリケーションに係るサービスを提供するものであり、例えば、アプリケーションサーバである。サーバ３は、携帯端末２において起動中のアプリケーションからリクエストを受信すると、携帯端末２にレスポンスを送信する。

【0030】

通信制御装置１は、Ｌ１スイッチ５を介して、コアネットワーク４におけるトラヒックを監視することによりサーバ３の障害に起因する輻輳の発生を検出し、当該輻輳を抑制する輻輳制御を行う。具体的には、通信制御装置１は、コアネットワーク４におけるトラヒックを監視して、一部の携帯端末２からサーバ３に送信されたリクエストの数と、サーバ３から当該携帯端末２に送信されたレスポンスの数とを集計する（図１の（１））。その後、サーバ３のいずれかにおいて障害が発生し、当該サーバ３がダウンすると（図１の（２））、当該サーバ３との通信を行っていた携帯端末２は、当該サーバ３に対して大量のリクエストを送信し（図１の（３））、輻輳が発生する。通信制御装置１は、集計したリクエストの数とレスポンスの数とに基づいて、サーバ３の障害に起因する輻輳を検出する。通信制御装置１は、サーバ３の障害に起因した輻輳を検出した場合に、携帯端末２が当該サーバ３に対して送信したリクエストに対して、当該サーバ３の代わりとなる代理レスポンスを送信する（図１の（４））。

【0031】

［通信制御装置１の構成］
続いて、通信制御装置１が備える機能について説明する。図２は、第１の実施形態に係る通信制御装置１の機能構成図である。

【0032】

通信制御装置１は、記憶部１１と、制御部１２とを備える。
記憶部１１は、例えば、ＲＯＭ及びＲＡＭ等により構成される。記憶部１１は、通信制御装置１を機能させるための各種プログラムを記憶する。記憶部１１は、外部メモリ等の記憶媒体に記憶されたプログラムや外部装置から取得したプログラムを記憶してもよい。

【0033】

制御部１２は、例えば、ＣＰＵにより構成される。制御部１２は、記憶部１１に記憶されている各種プログラムを実行することにより、通信制御装置１に係る機能を統括的に制御する。制御部１２は、トラヒック監視部１２１と、輻輳検出部１２２と、代理応答部１２３とを備える。

【0034】

トラヒック監視部１２１は、携帯端末２からサーバ３に送信されたリクエストの数と、サーバ３から送信されたレスポンスの数と、サーバ３にリクエストを送信した携帯端末２の数とを監視する。輻輳検出部１２２は、トラヒック監視部１２１が集計したリクエストの数とレスポンスの数との比率、及びリクエスト端末数に基づいてサーバ３の障害に起因する輻輳を検出する。

【0035】

トラヒック監視部１２１及び輻輳検出部１２２は、協働して輻輳監視処理を繰り返し実行する。以下、トラヒック監視部１２１及び輻輳検出部１２２の機能について、フローチャートを用いながら説明する。図３は、第１の実施形態に係る輻輳監視処理のフローチャートである。

【0036】

まず、トラヒック監視部１２１は、複数の携帯端末２のうちの一部の携帯端末２からサーバ３に対して送信されたリクエストの数と、当該サーバ３から当該一部の携帯端末に送信されたレスポンスの数とを監視する。具体的には、トラヒック監視部１２１は、所定期間において一部の携帯端末２からサーバ３に送信されたリクエストの数を集計する（Ｓ１）。トラヒック監視部１２１は、所定期間において、サーバ３から一部の携帯端末２に送信されたレスポンスの数を集計する（Ｓ２）。これら一部の携帯端末２を、監視対象とされている携帯端末２ともいう。ここで、トラヒック監視部１２１は、リクエストに含まれているサーバ３のＩＰアドレスとポート番号、及びレスポンスに含まれているサーバ３のＩＰアドレスとポート番号に基づいて、複数のサーバ３のそれぞれについて、リクエストの数及びレスポンスの数を集計する。すなわち、トラヒック監視部１２１は、リクエスト及びレスポンスに含まれているＩＰアドレスとポート番号がサーバ３のＩＰアドレスとポート番号に一致している場合に、リクエストの数及びレスポンスの数を集計する。

【0037】

輻輳検出部１２２は、サーバ３から携帯端末２に送信されるレスポンスを解析して所定期間におけるエラーレスポンスの数を計数する。輻輳検出部１２２は、記憶部１１に予め記憶されている、サーバ３における障害の発生を検出するための閾値を取得する。輻輳検出部１２２は、エラーレスポンスの数が閾値より大きいか否かを判定する（Ｓ３）。輻輳検出部１２２は、エラーレスポンスの数が閾値より大きい場合（判定がＹｅｓの場合）、Ｓ１１に処理を移し、エラーレスポンスの数が閾値以下の場合（判定がＮｏの場合）、Ｓ４に処理を移す。

【0038】

続いて、輻輳検出部１２２は、トラヒック監視部１２１が所定期間に集計したリクエストの数とレスポンスの数との比率を算出することにより、サーバ３の応答率を算出する（Ｓ４）。

【0039】

続いて、輻輳検出部１２２は、現在の日時に対応する基準応答率を取得する（Ｓ５）。具体的には、記憶部１１には、各曜日の各時間帯と、当該各曜日の各時間帯において輻輳が発生していない場合のサーバ３の平均的な応答率である基準応答率とを関連付けた基準応答情報が記憶されている。輻輳検出部１２２は、記憶部１１に記憶されている基準応答情報を参照して、現在時刻に対応する基準応答率を取得する。

【0040】

続いて、輻輳検出部１２２は、Ｓ４において算出された応答率が、Ｓ５において取得された基準応答率よりも低いか否かを判定する（Ｓ６）。輻輳検出部１２２は、応答率が基準応答率よりも低いと判定した場合（判定がＹｅｓの場合）、Ｓ８に処理を移し、応答率が基準応答率以上と判定した場合（判定がＮｏの場合）、Ｓ７に処理を移す。

【0041】

輻輳検出部１２２は、Ｓ６において、応答率が基準応答率以上であると判定した場合、輻輳が発生していないので、所定時間（例えば、１分）待機する（Ｓ７）。その後、輻輳検出部１２２は、Ｓ１に処理を移す。これにより、トラヒック監視部１２１においてリクエスト及びレスポンスの集計が行われ、輻輳の監視が継続して行われる。

【0042】

Ｓ６において、輻輳検出部１２２が、応答率が基準応答率よりも低いと判定した場合、トラヒック監視部１２１は、サーバ３に対してリクエストを送信している携帯端末２の数、すなわち、リクエスト端末数を集計する。

【0043】

続いて、輻輳検出部１２２は、現在の日時に対応する基準端末数を取得する（Ｓ９）。具体的には、記憶部１１には、各曜日の各時間帯と、当該各曜日の各時間帯において輻輳が発生していない場合の平均的なリクエスト端末数を示す基準端末数とを関連付けた基準端末数情報が記憶されている。輻輳検出部１２２は、記憶部１１に記憶されている基準端末数情報を参照して、現在時刻に対応する基準端末数を取得する。

【0044】

続いて、輻輳検出部１２２は、Ｓ８において集計されたリクエスト端末数が、Ｓ９において取得された基準端末数よりも多いか否かを判定する（Ｓ１０）。輻輳検出部１２２は、リクエスト端末数が基準端末数よりも多いと判定した場合（判定がＹｅｓの場合）、輻輳が発生していることを検出してＳ１１に処理を移す。輻輳検出部１２２は、リクエスト端末数が基準端末数以下と判定した場合（判定がＮｏの場合）、Ｓ７に処理を移す。

【0045】

続いて、代理応答部１２３は、輻輳制御処理を実行する（Ｓ１１）。この処理については、後述する。

【0046】

続いて、代理応答部１２３の機能について説明する。代理応答部１２３は、輻輳検出部１２２が輻輳を検出した場合に、輻輳制御処理を実行することにより、携帯端末２に対してサーバ３が送信するレスポンスの代わりとなる代理レスポンスを送信する。以下、代理応答部１２３が実行する輻輳制御処理の詳細について、フローチャートを用いながら説明する。図４は、第１の実施形態に係る輻輳制御処理のフローチャートである。

【0047】

まず、代理応答部１２３は、携帯端末２からサーバ３に送信されたリクエストに含まれている宛先、すなわち、サーバ３のＩＰアドレスとポート番号に基づいて、輻輳中のサービスである輻輳サービスを特定する（Ｓ２１）。ここで、サービスとは、サーバ３において管理されているアプリケーションに係るサービスを示す。

【0048】

具体的には、記憶部１１には、サーバ３のＩＰアドレスとポート番号と、当該サーバ３が管理するアプリケーションの名称とを関連付けた管理テーブルが記憶されている。代理応答部１２３は、管理テーブルを参照して、リクエストに含まれるＩＰアドレスとポート番号に対応するアプリケーション名を特定することにより、リクエストに基づいてサーバ３が管理するアプリケーションを特定する。

【0049】

ここで、管理テーブルにおいて、ＩＰアドレスとポート番号と、アプリケーションが備える機能とを関連付けておき、代理応答部１２３が、リクエストに基づいて、アプリケーションが備える機能を特定してもよい。また、管理テーブルにおいて、ＩＰアドレスとポート番号と、携帯端末２のオペレーティングシステム（以下、ＯＳという。）の種別とを関連付けておき、代理応答部１２３が、リクエストに基づいて、携帯端末２のＯＳの種別を特定してもよい。ここで、アプリケーションが備える機能とは、例えば、通話機能やメッセージ送信機能、バックグラウンド処理に関する機能であり、サーバ３に対してリクエストを送信する機能である。

【0050】

続いて、代理応答部１２３は、輻輳時のリトライ間隔を取得する（Ｓ２２）。具体的には、記憶部１１には、サーバ３が管理するアプリケーション名と、輻輳時に携帯端末２から当該サーバ３に送信されるリクエストのリトライ間隔（輻輳時のリトライ間隔）とを関連付けた輻輳時リトライ情報が記憶されている。代理応答部１２３は、輻輳時リトライ情報に基づいて、Ｓ２１で特定したアプリケーションの輻輳時のリトライ間隔を取得する。

【0051】

続いて、代理応答部１２３は、輻輳時のリトライ間隔に基づいて、輻輳制御実行時間を決定する（Ｓ２３）。具体的には、代理応答部１２３は、輻輳時のリトライ間隔を輻輳制御実行時間とする。このように輻輳時のリトライ間隔を輻輳制御実行時間とすると、通信制御装置１は、輻輳制御の実行中に、携帯端末２からリクエストを１回以上受信することができる。そして、通信制御装置１が、当該リクエストに対して代理レスポンスを送信することで、携帯端末２では、エラー表示等が行われ、サーバ３へのリクエストの送信が一定時間にわたって抑制される。

【0052】

続いて、代理応答部１２３は、Ｓ２１で特定されたアプリケーション（輻輳サービス）を管理するサーバ３にリクエストを送信している携帯端末２を、代理レスポンスを送信する対象である制御対象端末と特定し、制御対象端末の数である制御対象端末数を取得する（Ｓ２４）。具体的には、Ｌ１スイッチ５は、携帯端末２からコアネットワーク４を介してサーバ３に送信されるリクエストを複製し、サーバ３及び通信制御装置１に供給する。そして、代理応答部１２３は、当該リクエストの数を集計することにより、制御対象端末数を特定する。

【0053】

続いて、代理応答部１２３は、未実施の制御の中で最も優先度が高い制御を選択する（Ｓ２５）。優先度が高い制御の選択は、以下のように行われる。
まず、記憶部１１には、アプリケーション名と、複数のプロトコルのそれぞれの当該アプリケーションに係る輻輳制御効果を示す情報と、を関連付けたプロトコル別効果情報が記憶されている。図６は、第１の実施形態に係るプロトコル別効果情報の一例を示す図である。図６には、一例として、携帯端末２のＯＳの種別が「ＯＳ１」である場合のアプリケーションＡ〜Ｆについての、各プロトコルの輻輳制御効果を示す情報が示されている。

【0054】

例えば、「ＩＣＭＰ１（ＴＹＰＥ３）」は、ＩＣＭＰプロトコルにおける「宛先到達不能」を示しており、「ＩＣＭＰ２（ＴＹＰＥ４）」は、ＩＣＭＰプロトコルにおける「始点抑制」を示している。また、「ＳＹＮ１（ＦＩＮ）」は、ＴＣＰプロトコルにおける「ＦＩＮ（終了）フラグ」を示しており、「ＳＹＮ２（ＲＳＴ）」は、ＴＣＰプロトコルにおける「ＲＳＴ（リセット）フラグ」を示している。図６には、携帯端末２のＯＳの種別が「ＯＳ２」である場合のアプリケーションＡ、Ｂについての、各プロトコルの輻輳制御効果を示す情報が示されている。ここでは、各プロトコルの輻輳制御効果を示す情報として「◎」、「○」、「△」、「×」の４種類の情報が示されている。例えば、「◎」は、輻輳制御効果が最も高いことを示しており、「×」は、輻輳制御効果が最も低いことを示している。各プロトコルの輻輳制御効果を示す情報は、代理応答部１２３によるプロトコルの選択に用いられる。図６に示されているように、アプリケーションＡ及びアプリケーションＢは、同一のアプリケーションであっても、携帯端末２のＯＳの種別ごとに、輻輳制御効果が高いプロトコルが異なっている。

【0055】

代理応答部１２３は、プロトコル別効果情報を参照して、複数のプロトコルのうち、アプリケーションに対して輻輳制御効果があるプロトコルを選択する。具体的には、代理応答部１２３は、複数のプロトコルのうち、アプリケーションに対して最も輻輳制御効果が高いプロトコルを選択する。ここで、代理応答部１２３は、アプリケーションの機能ごとに輻輳制御効果があるプロトコルを選択してもよい。また、代理応答部１２３は、ＯＳ上で実行されるアプリケーションの機能に対して輻輳制御効果があるプロトコルを選択してもよい。

【0056】

続いて、代理応答部１２３は、サーバ３からの応答を待つか否かを判定する（Ｓ２６）。具体的には、サーバ３ごとに予め応答を待つか否かの設定値を予め記憶部１１に記憶させておき、代理応答部１２３は、当該設定値に基づいてサーバ３からの応答を待つか否かを判定する。代理応答部１２３は、サーバ３からの応答を待つ場合、Ｓ２７に処理を移し、サーバ３からの応答を待たない場合、Ｓ２８に処理を移す。

【0057】

続いて、代理応答部１２３は、サーバ３からレスポンスを受信している制御対象端末があるか確認する（Ｓ２７）。代理応答部１２３は、レスポンスの受信が確認できた場合には、サーバ３が復旧して正常にレスポンスを送信することにより輻輳が解消できると判定し、本フローチャートの処理を終了する。代理応答部１２３は、当該レスポンスが確認できなかった場合には、Ｓ２８に処理を移す。

【0058】

続いて、代理応答部１２３は、Ｓ２３において決定された輻輳制御実行時間にわたって、輻輳制御を実行する（Ｓ２８）。具体的には、代理応答部１２３は、Ｓ２３において決定された輻輳制御実行時間内に、トラヒック監視部１２１が制御対象端末である携帯端末２からサーバ３にリクエストを送信したことを検出すると、当該携帯端末２に対して代理レスポンスを送信する。なお、この制御において、監視対象とされている携帯端末２については、後述する制御効果測定を正確に行うため、輻輳制御の実行を遅延させてもよい。

【0059】

代理応答部１２３は、制御効果測定処理を行い、Ｓ２７において実行した制御の効果を測定する（Ｓ２９）。制御効果測定処理の詳細については、後述する。
続いて、代理応答部１２３は、Ｓ２９において測定された制御効果が閾値よりも高いか否かを判定する（Ｓ３０）。代理応答部１２３は、効果の割合が閾値よりも高いと判定した場合（判定がＹｅｓの場合）、輻輳制御処理を終了する。また、代理応答部１２３は、効果の割合が閾値以下と判定した場合（判定がＮｏの場合）、Ｓ２５に処理を移す。Ｓ２５に処理を移すことにより、代理応答部１２３は、プロトコル別効果情報を参照することにより、未だ選択されていない複数のプロトコルから輻輳制御効果があるプロトコルを再選択する。

【0060】

続いて、制御効果測定処理の詳細について説明する。制御効果測定処理において、代理応答部１２３は、サーバ３の代わりにレスポンスを送信した後、トラヒック監視部１２１が監視したリクエストの数とレスポンスの数との比率に基づいて、代理レスポンスを送信したことによる輻輳制御効果を測定する。図５は、第１の実施形態に係る制御効果測定処理のフローチャートである。

【0061】

まず、代理応答部１２３は、監視対象の携帯端末２における輻輳サービスの応答率を取得する（Ｓ３１）。具体的には、代理応答部１２３は、トラヒック監視部１２１が監視対象としている一部の携帯端末２から送信されたリクエストの数と、当該一部の携帯端末２に送信されたレスポンスの数とに基づいて応答率を取得する。以下、Ｓ３１において取得する応答率を応答率（ａ）という。

【0062】

続いて、代理応答部１２３は、制御後の端末における輻輳サービスの応答率を取得する（Ｓ３２）。具体的には、代理応答部１２３は、輻輳制御処理のＳ２４において特定された制御対象端末から送信されたリクエストの数と、当該制御対象端末に送信されたレスポンスの数とに基づいて応答率を取得する。以下、Ｓ３２において取得する応答率を応答率（ｂ）という。

【0063】

続いて、代理応答部１２３は、Ｓ３１において取得した応答率（ａ）が、Ｓ３２において取得した応答率（ｂ）に比べて小さいか否かを判定する（Ｓ３３）。代理応答部１２３は、応答率（ａ）が応答率（ｂ）に比べて小さいと判定した場合（判定がＹｅｓの場合）、「効果有り」と判定する（Ｓ３４）。応答率（ａ）が応答率（ｂ）以上であると判定した場合（判定がＮｏの場合）、「効果無し」と判定する（Ｓ３８）。

【0064】

代理応答部１２３は、「効果有り」と判定した場合、応答率（ａ）と応答率（ｂ）とに基づいて、効果割合を算出する（Ｓ３５）。具体的には、代理応答部１２３は、応答率（ａ）に対する応答率（ｂ）の割合、すなわち応答率の増加率を効果割合として算出する。
続いて、代理応答部１２３は、制御方法及び効果割合を記録する（Ｓ３６）。ここで、制御方法とは、複数のプロトコルのそれぞれに基づく制御の種別を示し、代理応答部１２３は、複数のプロトコルに関連付けて、効果割合の数値を記憶部１１に記憶させる。

【0065】

続いて、代理応答部１２３は、算出した効果割合に基づいて、制御方法の優先度を変更する（Ｓ３７）。具体的には、代理応答部１２３は、記憶部１１に記録した効果割合の数値に基づいて、効果割合を「◎」、「○」、「△」、「×」の４種類の輻輳制御効果を示す情報のいずれかに分類し、プロトコル別効果情報を更新する。これにより、プロトコル別効果情報を動的に変更して、次回実行される輻輳制御処理においてプロトコルの優先度を動的に変更することができる。

【0066】

続いて、代理応答部１２３は、応答率（ａ）と応答率（ｂ）とに基づいて、制御効果を算出する（Ｓ３９）。具体的には、代理応答部１２３は、効果割合の数値に基づいて分類した輻輳制御効果を示す情報に基づいて、制御効果を示す数値を算出する。例えば、輻輳制御効果を示す情報が「◎」の場合に、制御効果は最大値を示し、Ｓ３８において「効果無し」と判定された場合に、制御効果は最小値を示す。

【0067】

［検証結果］
続いて、上述の輻輳制御処理についての検証結果を示す。
図７は、第１の実施形態に係る制御効果測定処理の検証結果を示す図である。検証では、１台の携帯端末２をＬ２スイッチ及びルータを介してサーバ３と接続させた状態において、ルータによって携帯端末２とサーバ３との通信を遮断して、疑似的にサーバ３がダウンした状態を模擬した。そして、通信制御装置１が、Ｌ２スイッチを介して携帯端末２に代理レスポンスを行った。

【0068】

例えば、アプリケーションＡのバックグラウンド処理は、代理レスポンスを送信していない場合には、１分間にリクエストが８回発生したが、通信制御装置１によって、代理レスポンスとして、ＴＣＰプロトコルのＳＹＮ／ＡＣＫフラグを送信し、その後、ＦＩＮフラグを送信した。この結果、１分間のリクエストが３回に軽減された。

【0069】

また、アプリケーションＢのアプリケーションの起動処理は、代理レスポンスを送信していない場合には、１分間にリクエストが８回発生したが、通信制御装置１によって、代理レスポンスとして、ＩＣＭＰプロトコルのＴＹＰＥ３（宛先到達不能）を送信した。この結果、１分間のリクエストが２回に軽減された。

【0070】

また、アプリケーションＣのバックグラウンド処理は、代理レスポンスを送信していない場合には、１分間にリクエストが１２回発生したが、通信制御装置１によって、代理レスポンスとして、ＤＮＳエラー（問い合わせ不明）を送信した。この結果、１分間のリクエストが１回に軽減された。

【0071】

［第１の実施形態における効果］
以上のとおり、第１の実施形態に係る通信制御装置１は、携帯端末２からサーバ３に送信されたリクエストの数を監視するトラヒック監視部１２１と、リクエストの数に基づいて輻輳を検出する輻輳検出部１２２と、輻輳検出部１２２が輻輳を検出した場合に、携帯端末２に対してサーバ３が送信するレスポンスの代わりとなる代理レスポンスを送信する代理応答部１２３とを備える。

【0072】

通信制御装置１は、輻輳検出部１２２がリクエストの数に基づいて輻輳を検出するので、サーバ３からリクエストに対応するレスポンスが送信されない場合であっても早期に輻輳を検出することができる。また、代理応答部１２３が、携帯端末２に対してサーバ３が送信するレスポンスの代わりとなる代理レスポンスを送信するので、携帯端末２において代理レスポンスに基づいてエラー表示等を行わせて、サーバ３からレスポンスを受信しないことによるリクエストの再送を抑制することができる。よって、通信制御装置１は、輻輳の発生を早期に検出して制御することができる。ここでの制御とは、例えばリクエスト数の３割減等の間引きをさせたり、リクエストそのものを停止させたりすることを指す。

【0073】

＜第２の実施形態＞
［制御対象端末に対する輻輳制御を分割して実行する］
続いて、第２の実施形態について説明する。第２の実施形態は、代理応答部１２３が、輻輳制御処理において、制御対象端末に対する輻輳制御を分割して実行する点で第１の実施形態と異なり、その他の点では同じである。

【0074】

第２の実施形態の代理応答部１２３は、輻輳制御の携帯端末２である制御対象端末の数（制御対象端末数）を算出する。ここで、制御対象端末数は、例えば、数千万台であり、通信制御装置１は、輻輳時のリトライ間隔（例えば、１０秒）に相当する時間において、全ての制御対象端末に対して代理レスポンスを送信することができない。

【0075】

ここで、携帯端末２は、サーバ３からレスポンスを受信できる場合、すなわち、通常時には、通常時のリトライ間隔でリクエストを送信し、サーバ３からレスポンスを受信できなかった場合には、輻輳時のリトライ間隔でリクエストをサーバ３に再送する。そして、携帯端末２は、代理レスポンスを受信することにより、通常時のリトライ間隔（例えば、１分）に相当する時間にわたって待機し、その後、サーバ３に対してリクエストを再送する。

【0076】

つまり、携帯端末２は、輻輳検出時に代理レスポンスを受信すると、通常時のリトライ間隔に相当する時間にわたって待機するので、リトライ間隔は、輻輳時のリトライ間隔から通常時のリトライ間隔になる。よって、通常時のリトライ間隔に相当する時間において、全ての制御対象端末に対して代理レスポンスを送信すれば、全ての制御対象端末は、リトライ間隔が、輻輳時のリトライ間隔から通常時のリトライ間隔になる。

【0077】

そこで、代理応答部１２３は、通常時のリトライ間隔を、輻輳制御を行う輻輳制御実行時間に決定する。そして、代理応答部１２３は、輻輳時に携帯端末２がリクエストを送信する輻輳時リトライ間隔に相当する時間において代理レスポンスを送信可能な端末数と、制御対象端末数とに基づいて、制御対象端末のうち、一部の制御対象端末を含むブロックを複数生成する。ここで、ブロックとは、一の輻輳時のリトライ間隔に相当する時間において代理レスポンスを送信する対象となる一部の制御対象端末の集合である。例えば、制御対象端末数が、６００万台であり、一度に処理可能な端末数（輻輳時リトライ間隔に相当する時間において代理レスポンスを送信可能な端末数）が１００万台である場合、ブロック数は６に決定される。代理応答部１２３は、複数のブロックのそれぞれについて、順番に代理レスポンスを送信する。

【0078】

図８は、第２の実施形態に係る複数のブロックに分割して輻輳制御を行った場合のトラヒックの変化を説明する図である。例えば、図８に示されるように、制御対象端末がブロックＡからブロックＦの６個のブロックに分割されるものとする。また、輻輳時のリトライ間隔が１０秒であり、通常時のリトライ間隔が６０秒であるものとする。

【0079】

代理応答部１２３は、輻輳制御実行時間と、ブロック数とに基づいて、１ブロックあたりの制御実行時間を決定する。具体的には、代理応答部１２３は、通常時のリトライ間隔を輻輳制御実行時間とし、当該輻輳制御実行時間をブロック数で除算することにより、１ブロックあたりの制御実行時間を決定する。

【0080】

図８に示す例では、１ブロックあたりの制御実行時間は、１０秒に決定される。なお、１ブロックあたりの制御実行時間が、輻輳時のリトライ間隔に相当する時間よりも長い場合、代理応答部１２３は、１ブロックあたりの制御実行時間を、輻輳時のリトライ間隔に相当する時間としてもよい。例えば、輻輳時のリトライ間隔に相当する時間が１０秒であり、１ブロックあたりの制御実行時間が１５秒である場合、代理応答部１２３は、１０秒間にわたって制御を行うことで、１ブロックに含まれる全ての制御対象端末に対して、輻輳時のリトライ間隔に相当する時間以内に代理レスポンスを送信することができる。

【0081】

続いて、代理応答部１２３は、各ブロックに含まれる制御対象端末に対して、決定した制御実行時間ずつ代理レスポンスを送信する。図８に示す例では、代理応答部１２３は、０秒から１０秒の間に、ブロックＡに含まれる制御対象端末について輻輳制御を行う。すると、ブロックＡに含まれる制御対象端末に対応するトラヒックは、通常時のリトライ間隔に相当する時間（６０秒）にわたって抑制される。続いて、代理応答部１２３が、１０秒から２０秒の間に、ブロックＢに含まれる制御対象端末について輻輳制御を行うと、ブロックＢに含まれる制御対象端末に対応するトラヒックは、通常時のリトライ間隔に相当する時間にわたって抑制される。同様に、代理応答部１２３は、２０秒から６０秒の間に、ブロックＣ、ブロックＤ、ブロックＥ、ブロックＦの順番で、１０秒ずつ輻輳制御を行う。これにより、代理応答部１２３は、ブロックの処理順にトラヒックを抑制することができる。

【0082】

続いて、フローチャートを参照しながら、第２の実施形態に係る代理応答部１２３の輻輳制御処理について説明する。図９は、第２の実施形態に係る輻輳制御処理のフローチャートである。

【0083】

まず、代理応答部１２３は、携帯端末２からサーバ３に送信されたリクエストに含まれている宛先に基づいて、輻輳中のサービスである輻輳サービス（アプリケーション）を特定する（Ｓ４１）。
続いて、代理応答部１２３は、通常時のリトライ間隔を取得する（Ｓ４２）。具体的には、記憶部１１には、サーバ３が管理するアプリケーション名と、通常時のリトライ間隔とを関連付けた通常時リトライ情報が記憶されている。代理応答部１２３は、通常時リトライ情報に基づいて、通常時のリトライ間隔を取得する。

【0084】

続いて、代理応答部１２３は、Ｓ４２において取得した通常時のリトライ間隔に基づいて、輻輳制御実行時間を決定する（Ｓ４３）。具体的には、代理応答部１２３は、通常時のリトライ間隔を輻輳制御実行時間とする。
続いて、代理応答部１２３は、制御対象端末数と、一度に処理可能な端末数とを取得する（Ｓ４４）。例えば、代理応答部１２３は、輻輳時のリトライ間隔に相当する時間内に代理レスポンスを送信できる携帯端末２の数を制御対象端末数として取得する。

【0085】

続いて、代理応答部１２３は、Ｓ４４において取得した、制御対象端末数と、一度に処理可能な端末数とに基づいて、ブロックの数を決定する。
続いて、代理応答部１２３は、Ｓ４３において決定した輻輳制御実行時間と、Ｓ４５において決定したブロック数とに基づいて、１ブロックあたりの制御実行時間を算出する（Ｓ４６）。

【0086】

続いて、代理応答部１２３は、未実施の制御の中で最も優先度が高い制御を選択する（Ｓ４７）。
続いて、代理応答部１２３は、サーバ３からの応答を待つか否かを判定する（Ｓ４８）。代理応答部１２３は、サーバ３からの応答を待つ場合、Ｓ４９に処理を移し、サーバ３からの応答を待たない場合、Ｓ５０に処理を移す。
続いて、代理応答部１２３は、サーバ３からレスポンスを受信している制御対象端末があるか確認する（Ｓ４９）。

【0087】

続いて、代理応答部１２３は、ブロックごとに輻輳制御を実行する（Ｓ５０）。代理応答部１２３は、Ｓ４６において算出された制御実行時間が、輻輳時のリトライ間隔に相当する時間よりも長い場合、輻輳時のリトライ間隔に相当する時間にわたって代理レスポンスを送信する。代理応答部１２３は、Ｓ４６において算出された１ブロックあたりの制御実行時間が、輻輳時のリトライ間隔に相当する時間よりも短い場合、Ｓ４６において算出された制御実行時間にわたって代理レスポンスを送信する。なお、１ブロックあたりの制御実行時間が、輻輳時のリトライ間隔に相当する時間よりも短い場合には、１ブロックに対応する制御対象端末の一部に代理レスポンスが送信される。

【0088】

より具体的には、代理応答部１２３は、Ｓ４６において算出された制御実行時間内に、トラヒック監視部１２１が制御中のブロックに対応する制御対象端末である携帯端末２からサーバ３にリクエストを送信したことを検出すると、当該携帯端末２に対して代理レスポンスを送信する。ここで、１ブロックあたりの制御実行時間が、輻輳時のリトライ間隔よりも短くなる場合には、１ブロックに含まれる制御対象端末の全てに対して代理レスポンスを送信できないものの、一定の割合で代理レスポンスを送信することができることから、ブロック１に含まれる一部の制御対象端末に係るトラヒックを抑制することができる。

【0089】

代理応答部１２３は、制御効果測定処理を行い、Ｓ５０において実行した制御の効果を測定する（Ｓ５１）。制御効果測定処理は、第１の実施形態の制御効果測定処理と同様の処理を行うので、説明を省略する。

【0090】

続いて、代理応答部１２３は、Ｓ５１において測定された制御効果が閾値よりも高いか否かを判定する（Ｓ５２）。代理応答部１２３は、制御効果が閾値よりも高いと判定した場合（判定がＹｅｓの場合）、Ｓ５３に処理を移す。また、代理応答部１２３は、制御効果が閾値以下と判定した場合（判定がＮｏの場合）、Ｓ４７に処理を移す。

【0091】

続いて、代理応答部１２３は、全ての処理対象端末に対して制御を行ったか否か、すなわち、全てのブロックについて輻輳制御処理を行ったか否かを判定する（Ｓ５３）。代理応答部１２３は、全ての処理対象端末に対して制御を行ったと判定した場合（判定がＹｅｓの場合）、輻輳制御処理を終了し、全ての処理対象端末に対して制御を行っていないと判定した場合（判定がＮｏの場合）、Ｓ４８に処理を移す。

【0092】

［第２の実施形態における効果］
以上のとおり、第２の実施形態に係る代理応答部１２３は、代理レスポンスを送信する対象である制御対象端末数を算出し、輻輳時に携帯端末２がリクエストを送信する輻輳時リトライ間隔に相当する時間において代理レスポンスを送信可能な端末数と、制御対象端末数とに基づいて、代理レスポンスを送信する対象の携帯端末２の集合を示すブロックの数を算出し、ブロックの数と、輻輳が発生していない場合に携帯端末２がリクエストを送信する通常時リトライ間隔とに基づいて、１ブロックあたりの制御を実行する制御実行時間を特定し、ブロックのそれぞれについて、当該制御実行時間にわたって制御を実行する。

【0093】

この発明によれば、通信制御装置１は、例えば、制御対象端末数が数千万台であっても、分割して処理を行うことで、通信制御装置１に係る負荷を大幅に抑制することができる。また、処理を複数のブロックに分割し、さらに複数のブロックそれぞれの制御実行時間を、正常時リトライ間隔に基づいて調整するので、複数のブロックそれぞれについて、均一に輻輳制御を行うことができる。

【0094】

＜第３の実施形態＞
［リクエスト数に基づいて輻輳状態を判定する］
続いて、第３の実施形態について説明する。第３の実施形態は、輻輳検出部１２２が、レスポンス数を用いずに、リクエスト数に基づいて輻輳を判定する点で第１の実施形態と異なり、その他の点では同じである。

【0095】

第３の実施形態に係るトラヒック監視部１２１は、所定期間に携帯端末２からサーバ３に送信されたリクエストの数と、サーバ３にリクエストを送信した携帯端末２の数とを監視する。具体的には、トラヒック監視部１２１は、リクエストに宛先情報として含まれているサーバ３のＩＰアドレスとポート番号に基づいて、所定期間に携帯端末２からサーバ３に送信されたリクエストの数を集計する。また、トラヒック監視部１２１は、リクエストに送信元情報として含まれている携帯端末２のＩＰアドレスとポート番号に基づいて、所定期間にサーバ３にリクエストを送信した携帯端末２の数を集計する。

【0096】

輻輳検出部１２２は、トラヒック監視部１２１が集計したリクエストの数、及びリクエスト端末数に基づいてサーバ３の障害に起因する輻輳を検出する。具体的には、輻輳検出部１２２は、複数の所定期間においてトラヒック監視部１２１が集計したリクエストの数の変化率を算出する。そして、輻輳検出部１２２は、当該変化率が閾値を超えた場合、すなわち、リクエストの数が急上昇した場合に、輻輳を検出する。

【0097】

［第３の実施形態における効果］
以上のとおり、第３の実施形態に係る通信制御装置１は、携帯端末２からサーバ３に送信されたリクエストの数を監視するトラヒック監視部１２１と、リクエストの数に基づいて輻輳を検出する輻輳検出部１２２と、輻輳検出部１２２が輻輳を検出した場合に、携帯端末２に対してサーバ３が送信するレスポンスの代わりとなる代理レスポンスを送信する代理応答部１２３とを備える。

【0098】

この発明によれば、トラヒック監視部１２１がレスポンスを集計する必要がないので、レスポンスを集計する場合に比べて、通信制御装置１にかかる負荷を軽減することができる。また、輻輳検出部１２２がリクエストの数のみに基づいて輻輳を検出するので、サーバからリクエストに対応するレスポンスが送信されない場合であっても早期に輻輳を検出することができる。

【0099】

以上、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態に記載の範囲には限定されない。上記実施の形態に、多様な変更又は改良を加えることが可能であることが当業者に明らかである。特に、装置の分散・統合の具体的な実施形態は以上に図示するものに限られず、その全部又は一部について、種々の付加等に応じて、又は、機能負荷に応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。

【符号の説明】

【0100】

１・・・通信制御装置、１１・・・記憶部、１２・・・制御部、１２１・・・トラヒック監視部、１２２・・・輻輳検出部、１２３・・・代理応答部、２・・・携帯端末、３・・・サーバ、４・・・コアネットワーク、５・・・Ｌ１スイッチ、６・・・ゲートウェイ、７・・・インターネット、Ｓ・・・通信制御システム

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】