JPWO2019168153A1 - 制御装置、通信制御方法、及びプログラム - Google Patents

Abstract

データ送信元の処理負荷が増大することを抑制しつつ、通信回線を安定的に確保する。制御装置は、所定のネットワークの内部に配置され、通信トラフィックを受信する、受信部と、通信トラフィックを宛先側に送信する、送信処理を実行する、送信部と、通信トラフィックに含まれる、所定の時間内における通信セッション数を計数する、トラフィック分析部と、通信セッション数が所定のセッション数閾値を超える場合、ネットワークが閑散状態になるまで、通信トラフィックを保持し、送信部に送信処理の実行を保留させる、送信管理部と、を備える。

Description

［関連出願についての記載］
本発明は、日本国特許出願：特願２０１８−０３８０２７号（２０１８年 ３月 ２日出願）の優先権主張に基づくものであり、同出願の全記載内容は引用をもって本書に組み込み記載されているものとする。
本発明は、制御装置、通信制御方法、及びプログラムに関する。

ＯＳ（Operating System）の提供元が最新バージョン（アップデート）を公開する場合等において、コンテンツサーバが、同一の時間帯に、複数の端末に対してデータを配信する場合がある。その場合、当該時間帯に、通信トラフィックが集中し、通信帯域の輻輳が発生する場合がある。通信帯域の輻輳が発生した場合、通信遅延が発生する。そこで、通信帯域の輻輳を回避する技術が望まれている。

特許文献１においては、ネットワークにおける輻輳が発生した場合、輻輳に係る端末装置からの信号を転送することを制限する技術が記載されている。

特許文献２においては、データ配信先ドメインからのデータ配信要求メッセージ数が予め定められたセッション数に達すると、その後に生じるセッション要求の受け付けを停止する技術が記載されている。

特許文献３においては、セッション要求における着信端末を、その着信端末のアドレス等に基づいてグルーピングし、グループ毎の輻輳を検出する技術が記載されている。特許文献３に記載されたセッション技術においては、輻輳が検出されたグループに属する、着信端末に向けたデータを破棄することで、輻輳規制を行う。

特開２００９−２１９０５８号公報 特開２００５−２４４９０４号公報 特開２００５−１６７７７１号公報

なお、上記先行技術文献の開示を、本書に引用をもって繰り込むものとする。以下の分析は、本発明の観点からなされたものである。

上記の通り、コンテンツサーバが、同一の時間帯に、複数の端末に対してデータを配信する場合、通信帯域の輻輳が発生する場合がある。さらに、通信帯域の輻輳が発生した場合、通信遅延が発生する。

また、通信帯域の輻輳が発生し、データの配信が終了しない場合には、送信側（コンテンツサーバ）、又は受信側（端末）は、通信帯域状態が不明な状態において、再送信処理、再受信処理（所謂、リトライ）を繰り返す。その結果、通信帯域の輻輳が発生した場合、通信困難な状態にも関わらず、再送信処理、再受信処理が繰り返される。

特許文献１−３に記載された技術においては、通信帯域の輻輳が発生した場合、通信を中継する装置が、輻輳に係るデータを破棄する。そのため、特許文献１−３に記載された技術においては、輻輳が解消された際に、データ送信元は、信号を再送信する必要がある。従って、特許文献１−３に記載された技術においては、データ送信元は、データの送信処理を完了するためには、同一の送信処理を再実行する必要がある。

そこで、本発明は、データ送信元の処理負荷が増大することを抑制しつつ、通信回線を安定的に確保することに貢献する制御装置、通信制御方法、及びプログラムを提供することを目的とする。

第１の視点によれば、制御装置が提供される。前記制御装置は、所定のネットワークの内部に配置される。前記制御装置は、通信トラフィックを受信する、受信部を備える。さらに、前記制御装置は、前記通信トラフィックを宛先側に送信する、送信処理を実行する、送信部を備える。さらに、前記通信トラフィックに含まれる、所定の時間内における通信セッション数を計数する、トラフィック分析部を備える。さらに、前記制御装置は、前記通信セッション数が所定のセッション数閾値を超える場合、前記ネットワークが閑散状態になるまで、前記通信トラフィックを保持し、前記送信部に前記送信処理の実行を保留させる、送信管理部を備える。

第２の視点によれば、通信制御方法が提供される。前記通信制御方法は、所定のネットワークの内部で通信トラフィックを受信する工程を含む。さらに、前記通信制御方法は、前記通信トラフィックに含まれる、所定の時間内における通信セッション数を計数する工程を含む。さらに、前記通信制御方法は、前記通信セッション数が所定のセッション数閾値を超える場合、前記ネットワークが閑散状態になるまで、前記通信トラフィックを保持し、前記通信トラフィックを宛先側に送信する処理を保留する工程を含む。
なお、本方法は、所定のネットワーク内に配置され、通信トラフィックを中継する、制御装置という、特定の機械に結び付けられている。

第３の視点によれば、プログラムが提供される。前記プログラムは、所定のネットワークの内部で通信トラフィックを受信する処理を、制御装置を制御するコンピュータに実行させる。さらに、前記プログラムは、前記通信トラフィックに含まれる、所定の時間内における通信セッション数を計数する処理を、前記コンピュータに実行させる。さらに、前記プログラムは、前記通信セッション数が所定のセッション数閾値を超える場合、前記ネットワークが閑散状態になるまで、前記通信トラフィックを保持し、前記通信トラフィックを宛先側に送信する処理を保留する処理を、前記コンピュータに実行させる。
なお、これらのプログラムは、コンピュータが読み取り可能な記憶媒体に記録することができる。記憶媒体は、半導体メモリ、ハードディスク、磁気記録媒体、光記録媒体等の非トランジェント（non-transient）なものとすることができる。本発明は、コンピュータプログラム製品として具現することも可能である。

各視点によれば、データ送信元の処理負荷が増大することを抑制しつつ、通信回線を安定的に確保することに貢献する制御装置、通信制御方法、及びプログラムが提供される。

一実施形態の概要を説明するための図である。 通信システムの全体構成の一例を示すブロック図である。 通信管理ＤＢ１５１の一例を示す図である。 トラフィック管理ＤＢ１５２の一例を示す図である。 制御装置１０の動作の一例を示すフローチャートである。

初めに、図１を用いて一実施形態の概要について説明する。なお、この概要に付記した図面参照符号は、理解を助けるための一例として各要素に便宜上付記したものであり、この概要の記載はなんらの限定を意図するものではない。また、各ブロック図のブロック間の接続線は、双方向及び単方向の双方を含む。一方向矢印については、主たる信号（データ）の流れを模式的に示すものであり、双方向性を排除するものではない。さらに、本願開示に示す回路図、ブロック図、内部構成図、接続図などにおいて、明示は省略するが、入力ポート及び出力ポートが各接続線の入力端及び出力端のそれぞれに存在する。入出力インターフェイスも同様である。

上述の通り、データ送信元の処理負荷が増大することを抑制しつつ、通信回線を安定的に確保することに貢献する制御装置が望まれる。

そこで、一例として、図１に示す制御装置１０００を提供する。制御装置１０００は、受信部１００１と、送信部１００２と、トラフィック分析部１００３と、送信管理部１００４とを備える。

制御装置１０００は、所定のネットワーク内に配置される。例えば、制御装置１０００は、コアネットワーク内に配置される。

受信部１００１は、通信トラフィックを受信する。送信部１００２は、受信部１００１が受信した通信トラフィックを、宛先側に送信する。トラフィック分析部１００３は、受信部１００１が受信した通信トラフィックに含まれる、所定の時間内における通信セッション数を計数する。送信管理部１００４は、通信セッション数が所定のセッション数閾値を超える場合、ネットワークが閑散状態になるまで、通信トラフィックを保持し、送信部１００２に送信処理の実行を保留させる。ここで、閑散状態とは、通信帯域の輻輳が発生していない状態であって、所定の通信品質を満たして通信可能な状態を意味するものとする。

つまり、ネットワークが閑散状態ではない場合には、制御装置１０００は、所定の閾値を越える、セッション数の通信トラフィックを、制御装置１０００の内部で保持する。そして、ネットワークが閑散状態になった場合に、制御装置１０００は、保持した通信トラフィックを、宛先側に送信（転送）する。そのため、データの送信元が、同時にデータを大量配信した場合であっても、制御装置１０００は、データの送信タイミングを制御することで、通信帯域の輻輳が発生することを回避できる。さらに、制御装置１０００は、データの送信処理を保留する場合には、当該データを送信するまで、当該データを保持する。そのため、制御装置１０００は、データの送信元に、同一のデータを再送信することを要求しない。従って、制御装置１０００は、データ送信元の処理負荷が増大することを抑制しつつ、通信回線を安定的に確保することに貢献する。

［第１の実施形態］
第１の実施形態について、図面を用いて詳細に説明する。なお、以下の説明においては、所定の時間内に、同一のデータ送信元に対応する、所定の閾値を越える通信セッションが発生した場合、「同時大量通信」が発生したと表現する。

図２は、本実施形態に係る通信システムの全体構成の一例を示すブロック図である。

制御装置１０は、所定のネットワークに配置される。本実施形態に係る通信システムにおいては、制御装置１０は、コアネットワーク１に配置される。以下の説明においては、制御装置１０が、インターネット３側のコンテンツサーバから複数の端末（２０ａ、２０ｂ、２０ｃ）宛のデータを受信する場合を例示して説明する。ただし、これは、本実施形態に係る制御装置１０を、インターネット３側のコンテンツサーバから複数の端末（２０ａ、２０ｂ、２０ｃ）宛のデータを受信する装置に限定する趣旨ではない。

端末２０は、アクセスネットワーク２を介して、コアネットワーク１と接続する。

制御装置１０は、受信部１１と、送信部１２と、トラフィック分析部１３と、送信管理部１４と、記憶部１５とを含んで構成される。記憶部１５は、通信管理ＤＢ（Database；データベース）１５１と、トラフィック管理ＤＢ１５２とを格納する。

制御装置１０の各モジュールは、制御装置１０に搭載されたコンピュータに、そのハードウェアを用いて、制御装置１０に動作を実行させるコンピュータプログラムにより実現してもよい。

記憶部１５は、制御装置１０が属するネットワークに関して、データ送信元を示す情報と、セッション数閾値とを対応付けて格納する。具体的には、通信管理ＤＢ１５１は、データ送信元を示す情報と、セッション数閾値とを対応付けて格納する。または、通信管理ＤＢ１５１は、データ送信元を示す情報と、当該データ送信元が送信予定の総データサイズと、セッション数閾値とを対応付けて格納してもよい。以下の説明では、送信予定の総データサイズを、配信データサイズと呼ぶ。

図３は、通信管理ＤＢ１５１の一例を示す図である。図３に示す通信管理ＤＢ１５１は、データ送信元のドメインと、配信データサイズと、セッション数閾値とを対応付けて格納する。例えば、図３は、データの送信元のドメイン「ＡＡＡ．ＢＢＢ．ＣＣＣ．ＤＤＤ」に対応するコンテンツサーバが、５００ＭＢｙｔｅのデータを配信する場合、所定の時間内のセッション数の上限は、５０００であることを示す。

さらに、記憶部１５は、制御装置１０が属するネットワークに関して、閑散予想時間帯を示す情報と、通信利用帯域に関する情報とを対応付けて格納する。具体的には、トラフィック管理ＤＢ１５２は、制御装置１０が属するネットワークに関して、閑散予想時間帯を示す情報と、通信利用帯域に関する情報とを対応付けて格納する。ここで、閑散予想時間帯とは、制御装置１０が属するネットワークが閑散状態になる、と予想される時間帯を意味する。

または、トラフィック管理ＤＢ１５２は、制御装置１０が属するネットワークに関して、閑散予想時間帯を示す情報と、通信利用予想帯域と、空き予想帯域と、閑散状態であるか否かを示す情報とを、対応付けて格納してもよい。ここで、通信利用予想帯域は、利用されることが予想される帯域を意味する。また、空き予想帯域は、通信に利用されていないことが予想される帯域を意味する。また、以下の説明では、閑散状態であるか否かを示す情報を、閑散時間帯フラグと呼ぶ。

図４は、トラフィック管理ＤＢ１５２の一例を示す図である。図４に示すトラフィック管理ＤＢ１５２は、時間帯と、通信利用予想帯域と、空き予想帯域と、閑散時間帯フラグとを対応付けて格納する。ここで、図４においては、閑散時間帯フラグ＝「０」は、ネットワークが閑散状態ではないことを示すものとする。一方、図４においては、閑散時間帯フラグ＝「１」は、ネットワークが閑散状態であることを示すものとする。その場合、図４は、０時０分以降から１時０分未満（即ち、時間帯「００：００〜０１：００」）において、ネットワークが閑散状態ではないことを示す。さらに、図４は、０時０分以降から１時０分未満において、通信利用予想帯域は、１．２Ｇｂｐｓであり、空き予想帯域は、０．８Ｇｂｐｓであることを示す。また、図４は、１時０分以降から２時０分未満（即ち、時間帯「０１：００〜０２：００」）は、ネットワークが閑散状態であることを示す。さらに、図４は、１時０分以降から２時０分未満まで、通信利用予想帯域は、１．０Ｇｂｐｓであり、空き予想帯域は、１．０Ｇｂｐｓであることを示す。

受信部１１は、通信トラフィックを受信する。例えば、受信部１１は、インターネット３側のコンテンツサーバから、複数の端末（２０ａ、２０ｂ、２０ｃ）宛のデータを含む、通信トラフィックを受信する。なお、以下の説明においては、端末（２０ａ、２０ｂ、２０ｃ）を、夫々区別する必要がない場合には、端末２０と表記する。また、図２においては、３つの端末（２０ａ、２０ｂ、２０ｃ）を記載するが、これは、データの宛先を、３つの端末に限定する趣旨ではない。受信部１１は、１、２又は４以上の端末２０宛てのデータを含む、通信トラフィックを受信しても良いことは勿論である。

送信部１２は、受信部１１が受信した通信トラフィックを宛先側（即ち、端末２０側）に送信する処理（以下、送信処理と呼ぶ）を実行する。以下の説明では、受信部１１が受信した通信トラフィックを、受信通信トラフィックとも呼ぶ。

トラフィック分析部１３は、受信通信トラフィックを分析（測定）する。具体的には、トラフィック分析部１３は、受信通信トラフィックに基づいて、通信利用帯域を特定する。

また、トラフィック分析部１３は、時間帯毎（例えば、１時間毎）の通信利用帯域の統計値（例えば、平均値）を算出する。例えば、トラフィック分析部１３は、時間帯毎（例えば、１時間毎）の通信利用帯域に関して、所定の期間（例えば、１ヶ月間）における統計値（例えば、平均値）を算出してもよい。

トラフィック分析部１３は、所定の時間帯に対応する通信利用帯域の統計値に基づいて、当該時間帯において、ネットワークが閑散状態になる傾向があるか否かを判断する。例えば、トラフィック分析部１３は、所定の時間帯に対応する通信利用帯域の統計値が、所定の閾値以下である場合、ネットワークが閑散状態になる傾向があると判断してもよい。一方、トラフィック分析部１３は、所定の時間帯に対応する通信利用帯域の統計値が、所定の閾値を越える場合、ネットワークが閑散状態ではない傾向があると判断してもよい。

そして、トラフィック分析部１３は、対応する時間帯において、ネットワークが閑散状態になる傾向があると判断したとする。その場合、トラフィック分析部１３は、当該時間帯と、ネットワークが閑散状態であることを示す情報（例えば、閑散時間帯フラグ＝「１」）とを対応付けて、トラフィック管理ＤＢ１５２に登録する。

一方、トラフィック分析部１３は、対応する時間帯において、ネットワークが閑散状態ではない傾向があると判断したとする。その場合、トラフィック分析部１３は、当該時間帯と、ネットワークが閑散状態ではないことを示す情報（例えば、閑散時間帯フラグ＝「０」）とを対応付けて、トラフィック管理ＤＢ１５２に登録する。

さらに、トラフィック分析部１３は、通信利用帯域の統計値を、トラフィック管理ＤＢ１５２に登録する。具体的には、トラフィック分析部１３は、受信部１１が受信通信トラフィックを受信した時間帯に関して、通信利用帯域の統計値を、通信利用予想帯域として登録する。さらに、トラフィック分析部１３は、受信部１１が受信通信トラフィックを受信した時間帯に関して、トラフィック管理ＤＢ１５２に登録されている空き予想帯域を、通信利用予想帯域に基づいて更新する。

さらに、トラフィック分析部１３は、受信通信トラフィックに基づいて、データ送信元を示す情報と、送信予定の総データサイズを特定する。さらに、トラフィック分析部１３は、受信通信トラフィックに含まれる、所定の時間内における通信セッション数を計数する。例えば、トラフィック分析部１３は、データ送信元のドメイン毎に、所定の時間内における通信セッション数を計数してもよい。

そして、トラフィック分析部１３は、受信通信トラフィックに対応する、データ送信元を示す情報と、当該データ送信元が送信予定の総データサイズと、所定の時間内における通信セッション数とを対応付けた、通信情報を生成する。

さらに、トラフィック分析部１３は、制御装置１０が属するネットワークが、閑散状態であるか否かを判断する。上記の通り、閑散状態とは、通信帯域の輻輳が発生しておらず、所定の通信品質を満たして通信可能な状態を意味するものとする。また、以下の説明では、制御装置１０が属するネットワークとは、コアネットワーク１であるものとする。

具体的には、トラフィック分析部１３は、データ送信元に対応する、セッション数閾値を、記憶部１５から取得する。より具体的には、トラフィック分析部１３は、生成した通信情報に含まれるデータ送信元に、対応するセッション数閾値を取得する。そして、トラフィック分析部１３は、生成した通信情報に含まれるデータ送信元毎に、所定の時間内における通信セッション数が、同じデータ送信元に対応するセッション数閾値を越えるか否かを判断する。

通信セッション数がセッション数閾値を超えるデータ送信元が、生成された通信情報に含まれる場合、制御装置１０が属するネットワークが閑散状態ではない、とトラフィック分析部１３は判断する。換言すると、通信セッション数がセッション数閾値を超えるデータ送信元が、生成された通信情報に含まれる場合、同時大量通信が発生した、とトラフィック分析部１３は判断する。

一方、通信セッション数がセッション数閾値を超えるデータ送信元が、生成された通信情報に含まれない場合、制御装置１０が属するネットワークが閑散状態である、とトラフィック分析部１３は判断する。

そして、通信セッション数がセッション数閾値を超える場合には、送信管理部１４は、制御装置１０が属するネットワークが閑散状態になるまで、受信通信トラフィックを保持する。さらに、通信セッション数がセッション数閾値を超える場合には、送信管理部１４は、制御装置１０が属するネットワークが閑散状態になるまで、送信部１２に送信処理の実行を保留させる。

または、通信セッション数がセッション数閾値を超える場合には、制御装置１０が属するネットワークが閑散状態である、とトラフィック分析部１３が判断するまで、送信管理部１４は、受信通信トラフィックを保持する。さらに、通信セッション数がセッション数閾値を超える場合には、制御装置１０が属するネットワークが閑散状態である、とトラフィック分析部１３が判断するまで、送信管理部１４は、送信部１２に送信処理の実行を保留させる。

換言すると、同時大量通信が発生した、とトラフィック分析部１３が判断した場合、送信管理部１４は、制御装置１０が属するネットワークが閑散状態になるまで、受信通信トラフィックを保持し、送信部１２に送信処理の実行を保留させる。

さらに、同時大量通信が発生した、とトラフィック分析部１３が判断した後、トラフィック管理ＤＢ１５２に登録された閑散予想時間帯の開始時刻を超えた場合、制御装置１０が属するネットワークが閑散状態である、とトラフィック分析部１３は判断する。

その場合、通信セッション数がセッション数閾値を超える場合には、送信管理部１４は、閑散予想時間帯の開始時刻まで、受信通信トラフィックを保持し、送信部１２に送信処理の実行を保留させる。換言すると、同時大量通信が発生した、とトラフィック分析部１３が判断した場合、送信管理部１４は、トラフィック管理ＤＢ１５２に登録された閑散予想時間帯の開始時刻を超えるまで、受信通信トラフィックを保持し、送信部１２に送信処理の実行を保留させる。

次に、本実施形態に係る制御装置１０の動作について詳細に説明する。なお、以下の説明では、通信管理ＤＢ１５１は、図３に示す情報を格納する場合を例示して説明する。また、トラフィック管理ＤＢ１５２は、図４に示す情報を格納する場合を例示して説明する。そして、インターネット３側に配置される、ドメイン「ＡＡＡ．ＢＢＢ．ＣＣＣ．ＤＤＤ」であるコンテンツサーバが、１００００台の端末２０宛に、５００ＭＢｙｔｅの一斉データ配信を、２３：００に行ったとする。

ステップＳ１において、受信部１１は、通信トラフィックを受信する。具体的には、データ送信元のコンテンツサーバから送信された通信トラフィックが、コアネットワーク１内において、制御装置１０を通過する際に、受信部１１は、当該通信トラフィックを受信する。例えば、受信部１１は、ドメイン「ＡＡＡ．ＢＢＢ．ＣＣＣ．ＤＤＤ」であるコンテンツサーバが送信した、５００ＭＢｙｔｅのデータであって、セッション数が１００００である、通信トラフィックを受信する。

ステップＳ２において、トラフィック分析部１３は、受信部１１が受信した通信トラフィック（受信通信トラフィック）を分析する。

ステップＳ３において、トラフィック分析部１３は、受信通信トラフィックに対応する通信利用帯域を、トラフィック管理ＤＢ１５２に登録する。トラフィック分析部１３は、受信部１１が受信通信トラフィックを受信した時間帯に関して、受信通信トラフィックに対応する通信利用帯域に基づいて、トラフィック管理ＤＢ１５２に登録されている通信利用帯域、及び空き予想帯域を更新する。

ステップＳ４において、制御装置１０が属するネットワークが、閑散状態であるか否かを、トラフィック分析部１３は判断する。制御装置１０が属するネットワークが、閑散状態である場合（ステップＳ４のＹｅｓ分岐）には、制御装置１０は、受信通信トラフィックを宛先側に送信する（ステップＳ５）。具体的には、制御装置１０が属するネットワークが、閑散状態である場合には、送信管理部１４は、受信通信トラフィックを宛先側に送信する処理を、送信部１２に実行させる。つまり、制御装置１０は、受信通信トラフィックを受信すると、受信通信トラフィックを保持することなく、受信通信トラフィックを宛先側に、順次、転送する。

一方、制御装置１０が属するネットワークが、閑散状態ではない場合（ステップＳ４のＮｏ分岐）には、トラフィック分析部１３は、データ送信元を示す情報と、配信データサイズと、通信セッション数とを、受信通信トラフィックに基づいて特定する（ステップＳ６）。

ステップＳ７において、取得した通信セッション数が、データ送信元及び配信データサイズに対応する、セッション数閾値を超えているか否かを、トラフィック分析部１３は判断する。取得した通信セッション数が、データ送信元及び配信データサイズに対応する、セッション数閾値を超えていない場合（ステップＳ７のＮｏ分岐）には、制御装置１０は、受信通信トラフィックを宛先側に送信する（ステップＳ８）。具体的には、取得した通信セッション数が、データ送信元及び配信データサイズに対応する、セッション数閾値を超えていない場合には、送信管理部１４は、受信通信トラフィックを宛先側に送信する処理を、送信部１２に実行させる。つまり、制御装置１０は、受信通信トラフィックを受信すると、受信通信トラフィックを保持することなく、受信通信トラフィックを宛先側に、順次、転送する。

一方、取得した通信セッション数が、データ送信元及び配信データサイズに対応する、セッション数閾値を超えている場合（ステップＳ７のＹｅｓ分岐）には、ステップＳ９に遷移する。

例えば、トラフィック分析部１３は、データ送信元のドメイン（データ送信元を示す情報）が「ＡＡＡ．ＢＢＢ．ＣＣＣ．ＤＤＤ」であることを、受信通信トラフィックに基づいて特定したとする。また、トラフィック分析部１３は、配信データサイズが５００ＭＢｙｔｅであることを、受信通信トラフィックに基づいて特定したとする。さらに、トラフィック分析部１３は、通信セッション数が１００００であることを、受信通信トラフィックに基づいて特定したとする。そして、上記の通り、通信管理ＤＢ１５１は、図３に示す情報を格納するとする。その場合、取得した通信セッション数（即ち、１００００）が、セッション数閾値（即ち、５０００）を超えている、とトラフィック分析部１３は判断する。そのため、制御装置１０は、ステップＳ９の処理に遷移する。

ステップＳ９において、送信管理部１４は、トラフィック管理ＤＢ１５２から、閑散予想時間帯に関する情報と、空き予想帯域に関する情報とを取得する。

ステップＳ１０において、送信管理部１４は、閑散予想時間帯まで、送信処理の実行を保留する。具体的には、送信管理部１４は、閑散予想時間帯まで、通信トラフィックを保持し、送信部１２に送信処理の実行を保留させる。そして、閑散予想時間帯の開始時刻を越えた場合、制御装置１０は、送信を保留した受信通信トラフィックを、宛先側に送信する（ステップＳ１１）。具体的には、閑散予想時間帯の開始時刻を越えた場合、送信管理部１４は、送信を保留した受信通信トラフィックを、宛先側に送信する処理を、送信部１２に実行させる。

例えば、上記の通り、トラフィック管理ＤＢ１５２は、図４に示す情報を格納するとする。そして、ドメイン「ＡＡＡ．ＢＢＢ．ＣＣＣ．ＤＤＤ」であるコンテンツサーバが、１００００台の端末２０宛に、５００ＭＢｙｔｅの一斉データ配信を、２３：００に行ったとする。その場合、図４に示すトラフィック管理ＤＢ１５２に基づいて、データ配信開始以降の時間帯であって、０時０分以降から１時０分未満には、ネットワークが閑散状態ではない、と送信管理部１４は判断する。しかし、図４に示すトラフィック管理ＤＢ１５２に基づいて、データ配信開始以降の時間帯であって、１時０分以降から２時０分未満には、ネットワークが閑散状態になる、と送信管理部１４は判断する。つまり、送信管理部１４は、データ配信開始以降の時間帯であって、１時０分以降から２時０分未満の時間帯を、閑散予想時間帯であると特定する。

その場合、送信管理部１４は、１時０分まで、受信通信トラフィックを保持し、送信処理の実行を送信部１２に保留させる。そして、送信管理部１４は、１時０分以降に、送信を保留した受信通信トラフィックを、宛先側に送信する処理を、送信部１２に実行させる。それにより、制御装置１０は、通信帯域の輻輳を回避して、ドメイン「ＡＡＡ．ＢＢＢ．ＣＣＣ．ＤＤＤ」であるコンテンツサーバが送信した、５００ＭＢｙｔｅのデータを、１００００台の端末２０宛に送信することが可能になる。

以上のように、本実施形態に係る制御装置１０は、所定の時間内の通信セッション数に基づいて、同時大量通信であるか否かを判断する。そして、本実施形態に係る制御装置１０は、同時大量通信が発生した場合には、予め設定した閑散予想時間帯まで、当該同時大量通信に対応する通信トラフィックを保持し、閑散予想時間帯の開始時刻を越えた場合、当該通信トラフィックに対応するデータを、宛先側に送信する。それにより、本実施形態に係る制御装置１０は、通信帯域の輻輳を回避することに貢献する。さらに、本実施形態に係る制御装置１０は、受信トラフィックを保持するので、データの送信元に、同一のデータを再送信することを要求しない。従って、本実施形態に係る制御装置１０は、データ送信元の処理負荷が増大することを抑制しつつ、通信回線を安定的に確保することに貢献する。

また、本実施形態に係る制御装置１０は、同時大量通信が発生した場合、閑散予想時間帯に、宛先側にデータを転送することで、データの送信タイミングを制御する。そのため、通信が集中する時間帯（所謂、「ピークアワー」）に、同時大量通信が発生した場合、本実施形態に係る制御装置１０は、通信が集中することを抑制することに貢献する。

また、ＭＶＮＯ（Mobile Virtual Network Operator）事業者が、通信帯域の輻輳を回避するために、ＭＮＯ（Mobile Network Operator）との契約帯域を引き上げる場合がある。その結果、ＭＶＮＯ事業者は、通信帯域の輻輳を回避するためには、コストを増大させる必要が生じる。しかし、本実施形態に係る制御装置１０は、閑散予想時間帯に、データを、宛先側に送信することで、通信帯域の輻輳を回避する。従って、本実施形態に係る制御装置１０は、ＭＶＮＯ事業者に、コストを低減させることに貢献する。

また、通信帯域の輻輳が発生し、データの配信が終了しない場合には、送信側（コンテンツサーバ）、又は受信側（端末）は、再送信処理、再受信処理（所謂、リトライ）を繰り返す。送信側又は受信側がリトライを繰り返すと、通信帯域（空き帯域）が無駄に消費されることになる。しかし、本実施形態に係る制御装置１０は、受信トラフィックを保持し、閑散予想時間帯に、宛先側にデータを転送することで、データの送信タイミングを制御する。従って、本実施形態に係る制御装置１０は、送信側（コンテンツサーバ）、又は受信側（端末）がリトライを繰り返すことを回避できる。その結果、本実施形態に係る制御装置１０は、通信帯域（空き帯域）の無駄な消費を抑制することに貢献する。

［第２の実施形態］
次に、第２の実施形態について、図面を用いて詳細に説明する。

本実施形態は、閑散予想時間帯に、空き予想帯域を所定のサイズを越えて使用した場合には、送信処理を中断し、次の閑散予想時間帯に、送信処理を再開する形態である。なお、本実施形態における説明では、上記の実施形態と重複する部分の説明は省略する。さらに、本実施形態における説明では、上記の実施形態と同一の構成要素には、同一の符号を付し、その説明を省略する。また、本実施形態における説明では、上記の実施形態と同一の作用効果についても、その説明を省略する。

本実施形態に係る通信システムの全体構成は、図２に示す通りである。

本実施形態に係る送信管理部１４は、閑散予想時間帯に、送信部１２に送信処理を実行させ、閑散予想時間帯と通信利用帯域に関する情報とに基づいて、空き予想帯域を推定する。そして、本実施形態に係る送信管理部１４は、閑散予想時間帯に、空き予想帯域を所定のサイズを超えて使用した場合には、送信部１２に送信処理を中断させ、次の閑散予想時間帯に、送信部１２に送信処理の実行を再開させる。

つまり、本実施形態に係る制御装置１０は、閑散予想時間帯に、送信処理を開始した場合であっても、空き帯域が減少した場合には、次の閑散予想時間帯まで、送信処理を中断する。従って、本実施形態に係る制御装置１０は、データ送信元の処理負荷が増大することを抑制しつつ、より一層、通信回線を安定的に確保することに貢献する。

上記の説明においては、制御装置１０がコアネットワーク１に配置される形態について説明した。しかし、これは、制御装置１０がコアネットワーク１に配置される構成に限定する趣旨ではない。制御装置１０は、コアネットワーク以外のネットワークに配置されてもよいことは勿論である。

また、上記の説明においては、制御装置１０が、インターネット３側から複数の端末２０宛の通信トラフィックを受信する形態について説明した。しかし、これは、制御装置１０が、インターネット３側から複数の端末２０宛の通信トラフィックを受信する形態に限定する趣旨ではない。制御装置１０は、端末２０からインターネット３側に対する通信トラフィックを受信してもよいことは勿論である。その場合、トラフィック分析部１３は、端末２０からインターネット３側に対する通信トラフィックに基づいて、同時大量通信の有無を判断してもよいことは勿論である。制御装置１０は、端末２０からインターネット３側に対する同時大量通信を検出した場合には、不正アクセスが発生したと判断しても良い。その場合、制御装置１０は、検出した同時大量通信に対応する通信を遮断してもよい。それにより、制御装置１０は、ネットワークのセキュリティを向上することに貢献する。

また、上記の説明においては、制御装置１０が、通信管理ＤＢ１５１と、トラフィック管理ＤＢ１５２とを含んで構成される形態について説明した。しかし、制御装置１０とは異なる情報処理装置（コンピュータ、図示せず）が、通信管理ＤＢ１５１、トラフィック管理ＤＢ１５２を格納しても良いことは勿論である。また、通信管理ＤＢ１５１、トラフィック管理ＤＢ１５２は夫々異なる情報処理装置（コンピュータ、図示せず）に格納されても良いことは勿論である。

また、上記の説明においては、トラフィック分析部１３が、データ送信元のドメイン毎に、通信セッション数を計数する形態について説明した。しかし、トラフィック分析部１３は、データ送信元のアドレス毎に、通信セッション数を計数してもよいことは勿論である。例えば、トラフィック分析部１３は、データ送信元のＩＰ（Internet Protocol）アドレス毎に、通信セッション数を計数してもよい。また、例えば、トラフィック分析部１３は、データ送信元のＭＡＣ（Media Access Control）アドレス毎に、通信セッション数を計数してもよい。

また、上記の説明においては、トラフィック分析部１３が、所定の時間帯に対応する通信利用帯域の統計値に基づいて、当該時間帯において、ネットワークが閑散状態になる傾向があるか否かを判断する形態について説明した。しかし、トラフィック分析部１３は、所定の時間帯に対応する空き帯域の統計値に基づいて、ネットワークが閑散状態になる傾向があるか否かを判断してもよいことは勿論である。

また、上記の説明においては、トラフィック分析部１３が、受信トラフィックを分析し、トラフィック管理ＤＢ１５２に、閑散予想時間帯を登録する形態について説明した。しかし、制御装置１０の管理者等が、閑散予想時間帯を制御装置１０に入力してもよいことは勿論である。つまり、制御装置１０は、制御装置１０の管理者等の操作に基づいて、トラフィック管理ＤＢ１５２に、閑散予想時間帯を登録しても良いことは勿論である。

また、上記の説明においては、トラフィック管理ＤＢ１５２が、閑散予想時間帯を、１時間単位で管理する形態について説明した。しかし、これは、トラフィック管理ＤＢ１５２が、閑散予想時間帯を、１時間単位で管理することに限定する趣旨ではない。トラフィック管理ＤＢ１５２は、閑散予想時間帯を、任意の時間単位で管理してもよいことは勿論である。

上述の実施形態の一部又は全部は、以下の形態のようにも記載され得るが、以下には限られない。

（形態１）上記第１の視点に係る制御装置の通りである。

（形態２）前記トラフィック分析部は、データ送信元毎に、前記通信セッション数を計数する、好ましくは形態１に記載の制御装置。

（形態３）前記トラフィック分析部は、データ送信元のドメイン毎に、前記通信セッション数を計数する、好ましくは形態１又は２に記載の制御装置。

（形態４）前記トラフィック分析部は、前記ネットワークが閑散状態であるか否かを判断し、前記送信管理部は、前記通信セッション数が前記セッション数閾値を超える場合、ネットワークが閑散状態である、とトラフィック分析部が判断するまで、前記通信トラフィックを保持し、前記送信部に前記送信処理の実行を保留させる、好ましくは形態１乃至３のいずれか一に記載の制御装置。

（形態５）データ送信元を示す情報と、前記セッション数閾値とを対応付けて格納する、記憶部をさらに備え、前記トラフィック分析部は、データ送信元に対応する、前記セッション数閾値を、前記記憶部から取得し、前記送信管理部は、前記通信セッション数が、取得したセッション数閾値を超える場合には、前記ネットワークが閑散状態になるまで、前記通信トラフィックを保持し、前記送信部に前記送信処理の実行を保留させる、好ましくは形態１乃至４のいずれか一に記載の制御装置。

（形態６）前記記憶部は、閑散予想時間帯を示す情報を記憶し、前記トラフィック分析部は、前記閑散予想時間帯の開始時刻を超える場合、前記ネットワークが閑散状態であると判断し、前記送信管理部は、前記通信セッション数が前記セッション数閾値を超える場合には、前記閑散予想時間帯の開始時刻を越えるまで、前記通信トラフィックを保持し、前記送信部に前記送信処理の実行を保留させる、好ましくは形態５に記載の制御装置。

（形態７）前記記憶部は、前記閑散予想時間帯を示す情報と、通信利用帯域に関する情報とを対応付けて格納し、前記送信管理部は、前記閑散予想時間帯に、前記送信部に前記送信処理を実行させ、前記閑散予想時間帯と前記通信利用帯域に関する情報とに基づいて、空き予想帯域を推定し、前記閑散予想時間帯に、前記空き予想帯域を所定のサイズを超えて使用した場合には、前記送信部に前記送信処理を中断させ、次の前記閑散予想時間帯に、前記送信部に前記送信処理の実行を再開させる、好ましくは形態６に記載の制御装置。

（形態８）上記第２の視点に係る通信制御方法の通りである。

（形態９）上記第３の視点に係るプログラムの通りである。

なお、上記の形態８、９に示す形態は、形態１に示す形態と同様に、形態２乃至７に示す形態に展開することが可能である。

なお、上記の特許文献の開示を、本書に引用をもって繰り込むものとする。本発明の全開示（請求の範囲を含む）の枠内において、さらにその基本的技術思想に基づいて、実施形態の変更・調整が可能である。また、本発明の全開示の枠内において種々の開示要素（各請求項の各要素、各実施形態の各要素、各図面の各要素等を含む）の多様な組み合わせ、ないし、選択（部分的削除を含む）が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。特に、本書に記載した数値範囲については、当該範囲内に含まれる任意の数値ないし小範囲が、別段の記載のない場合でも具体的に記載されているものと解釈されるべきである。本発明で、アルゴリズム、ソフトウェア、ないしフローチャート或いは自動化されたプロセスステップが示された場合、コンピュータが用いられることは自明であり、またコンピュータにはプロセッサ及びメモリないし記憶装置が付設されることも自明である。よってその明示を欠く場合にも、本願には、これらの要素が当然記載されているものと解される。

１ コアネットワーク
２ アクセスネットワーク
３ インターネット
１０、１０００ 制御装置
１１、１００１ 受信部
１２、１００２ 送信部
１３、１００３ トラフィック分析部
１４、１００４ 送信管理部
１５ 記憶部
２０、２０ａ〜２０ｃ 端末
１５１ 通信管理ＤＢ
１５２ トラフィック管理ＤＢ

Claims (9)

1. 所定のネットワークの内部に配置され、
   通信トラフィックを受信する、受信部と、
   前記通信トラフィックを宛先側に送信する、送信処理を実行する、送信部と、
   前記通信トラフィックに含まれる、所定の時間内における通信セッション数を計数する、トラフィック分析部と、
   前記通信セッション数が所定のセッション数閾値を超える場合、前記ネットワークが閑散状態になるまで、前記通信トラフィックを保持し、前記送信部に前記送信処理の実行を保留させる、送信管理部と、
   を備える、制御装置。
2. 前記トラフィック分析部は、データ送信元毎に、前記通信セッション数を計数する、請求項１に記載の制御装置。
3. 前記トラフィック分析部は、データ送信元のドメイン毎に、前記通信セッション数を計数する、請求項１又は２に記載の制御装置。
4. 前記トラフィック分析部は、前記ネットワークが閑散状態であるか否かを判断し、
   前記送信管理部は、前記通信セッション数が前記セッション数閾値を超える場合、ネットワークが閑散状態である、とトラフィック分析部が判断するまで、前記通信トラフィックを保持し、前記送信部に前記送信処理の実行を保留させる、請求項１乃至３のいずれか一に記載の制御装置。
5. データ送信元を示す情報と、前記セッション数閾値とを対応付けて格納する、記憶部をさらに備え、
   前記トラフィック分析部は、データ送信元に対応する、前記セッション数閾値を、前記記憶部から取得し、
   前記送信管理部は、前記通信セッション数が、取得したセッション数閾値を超える場合、前記ネットワークが閑散状態になるまで、前記通信トラフィックを保持し、前記送信部に前記送信処理の実行を保留させる、請求項１乃至４のいずれか一に記載の制御装置。
6. 前記記憶部は、閑散予想時間帯を示す情報を記憶し、
   前記トラフィック分析部は、前記閑散予想時間帯の開始時刻を超える場合、前記ネットワークが閑散状態であると判断し、
   前記送信管理部は、前記通信セッション数が前記セッション数閾値を超える場合、前記閑散予想時間帯の開始時刻を越えるまで、前記通信トラフィックを保持し、前記送信部に前記送信処理の実行を保留させる、請求項５に記載の制御装置。
7. 前記記憶部は、前記閑散予想時間帯を示す情報と、通信利用帯域に関する情報とを対応付けて格納し、
   前記送信管理部は、前記閑散予想時間帯に、前記送信部に前記送信処理を実行させ、前記閑散予想時間帯と前記通信利用帯域に関する情報とに基づいて、空き予想帯域を推定し、前記閑散予想時間帯に、前記空き予想帯域を所定のサイズを超えて使用した場合には、前記送信部に前記送信処理を中断させ、次の前記閑散予想時間帯に、前記送信部に前記送信処理の実行を再開させる、請求項６に記載の制御装置。
8. 所定のネットワークの内部で通信トラフィックを受信する工程と、
   前記通信トラフィックに含まれる、所定の時間内における通信セッション数を計数する工程と、
   前記通信セッション数が所定のセッション数閾値を超える場合には、前記ネットワークが閑散状態になるまで、前記通信トラフィックを保持し、前記通信トラフィックを宛先側に送信する処理を保留する工程と、
   を含む、通信制御方法。
9. 所定のネットワークの内部で通信トラフィックを受信する処理と、
   前記通信トラフィックに含まれる、所定の時間内における通信セッション数を計数する処理と、
   前記通信セッション数が所定のセッション数閾値を超える場合には、前記ネットワークが閑散状態になるまで、前記通信トラフィックを保持し、前記通信トラフィックを宛先側に送信する処理を保留する処理と、
   を、制御装置を制御するコンピュータに実行させるプログラム。

Images