(57)【特許請求の範囲】
【請求項１】
複数の通信装置からなるネットワークにおいて、通信装置に対するスリープ制御を行うスリープ制御装置であって、
予め設定された閾値情報を保持する記憶手段と、
前記ネットワークにおける各通信装置からトラヒック情報を取得するトラヒック情報取得手段と、
前記閾値情報により定められる時間帯において、前記トラヒック情報から算出されたトラヒック総量が、前記閾値情報により定められるトラヒック量よりも小さい場合に、所定の通信装置を通常状態からスリープ状態に移行させる制御手段と、を備えるスリープ制御装置であり、
前記スリープ制御装置は、前記ネットワークから、予め定めた検出対象サービスについてのフロー情報を取得する手段を更に備え、
前記制御手段は、前記フロー情報に示される前記検出対象サービスのトラヒック状態が予め定めた条件を満たす場合に、通常状態にある通信装置のスリープ状態への移行を行なわない
ことを特徴とするスリープ制御装置。
【請求項２】
前記予め定めた条件は、前記フロー情報から算出される転送量の増加率が前記閾値情報により定められる閾値を超えることである
ことを特徴とする請求項１に記載のスリープ制御装置。
【請求項３】
前記時間帯は、前記閾値情報に含まれるスリープ時刻とウェイクアップ時刻間の時間帯である
ことを特徴とする請求項１又は２に記載のスリープ制御装置。
【請求項４】
前記閾値情報により定められるトラヒック量は、前記複数の通信装置の中で最大の最大帯域を有する通信装置の当該最大帯域に、前記閾値情報に規定された割合を乗じて得られる値である
ことを特徴とする請求項１ないし３のうちいずれか１項に記載のスリープ制御装置。
【請求項５】
前記所定の通信装置は、前記最大の最大帯域を有する通信装置以外の通信装置であることを特徴とする請求項４に記載のスリープ制御装置。
【請求項６】
複数の通信装置からなるネットワークにおいて、通信装置に対するスリープ制御を行うスリープ制御装置が実行するスリープ制御方法であって、
前記ネットワークにおける各通信装置からトラヒック情報を取得するトラヒック情報取得ステップと、
記憶手段に保持されている閾値情報により定められる時間帯において、前記トラヒック情報から算出されたトラヒック総量が、前記閾値情報により定められるトラヒック量よりも小さい場合に、所定の通信装置を通常状態からスリープ状態に移行させる制御ステップと、を備えるスリープ制御方法であり、
前記スリープ制御方法は、前記ネットワークから、予め定めた検出対象サービスについてのフロー情報を取得するステップを更に備え、
前記制御ステップにおいて、前記スリープ制御装置は、前記フロー情報に示される前記検出対象サービスのトラヒック状態が予め定めた条件を満たす場合に、通常状態にある通信装置のスリープ状態への移行を行なわない
ことを特徴とするスリープ制御方法。
【請求項７】
コンピュータを、請求項１ないし５のうちのいずれか１項に記載のスリープ制御装置における各手段として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信ネットワークの省電力化のための技術に関連する。
【背景技術】
【０００２】
通信ネットワークの消費電力量は、トラヒックの増加に比例して増加を続けており、昨今の環境意識の高まりから、ネットワーク全体の省電力化が求められている。通信ネットワークの省電力化を実現する技術として、通信装置のスリープ技術がある。スリープ技術は、通信装置をスリープ状態（待機状態やシャットダウン状態）へ移行することで、通信装置自体の消費電力量を削減する技術である。
【０００３】
例えば、装置内を流れるトラヒック流量が少ない時に、トラヒックを一部の通信装置やデバイスに移行させることで、トラヒックが流れていない通信装置を作りだし、更にこの通信装置をスリープ状態へ移行させることで、通信ネットワーク全体の電力消費量を削減することができる。
【０００４】
現在の通信装置の消費電力は、通信装置の負荷（トラヒック流量）によってほとんど変動しないことから、トラヒックがほとんど流れていない状態は非常に電力効率が悪い状態であるといえる。そのため、スリープ技術により、通信ネットワーク全体のトラヒック変動に応じて柔軟にスリープ制御を行うことにより、ネットワーク全体の電力効率を向上できると期待されている。
【０００５】
また、非特許文献1によると、全国規模のトラヒックは早朝をボトム、深夜をピークとする日変動をしていることが分かる。すなわち、大規模な通信ネットワークでは、日中はトラヒックが多いため、多くの通信装置を稼働させ、逆に深夜帯は一部の通信装置をスリープさせ、通信ネットワーク全体の消費電力を削減可能であると考えられる。
【０００６】
一方、頻繁なスリープ制御は、故障率に影響を与えるため、キャリアグレードの装置では、スリープ制御をできるだけ少ない回数に留めることが望ましい。しかし、切替回数が少ないと、トラヒック変動に対して消費電力を柔軟に変更できないため、省電力化の効果が薄くなると考えられる。そのため、通信ネットワークの品質に影響を与えない範囲で、スリープ状態の時間を延ばす制御が必要である。
【０００７】
なお、本明細書において、ルータ等の通信装置が起動し、通信処理を行っている状態を「通常状態」とし、通信装置が停止し、通信処理を行っていない状態を「スリープ状態」とする。
【先行技術文献】
【非特許文献】
【０００８】
【非特許文献１】"我が国のインターネットにおけるトラヒックの集計・試算," 総務省  報道資料, Sept. 2011.
【非特許文献２】"ネットワークの電力消費量を削減する分散型省電力プロトコルの提案," 2009信学総大, B-7-105, p249, May 2009.
【発明の概要】
【発明が解決しようとする課題】
【０００９】
スリープ制御において、通信装置の通常状態とスリープ状態間の移行には、一定時間の移行時間が発生するが、特にスリープ状態から通常状態に移行する際に、リンク帯域以上のトラヒックが発生した場合は、パケットロスや転送遅延等が発生する可能性が考えられる。これを回避するためには、トラヒックの変動を考慮した制御が必要である。
【００１０】
この問題に対し、非特許文献2では、定期的にルータの利用率を監視し、期間の異なる二つの移動平均から利用率の増減傾向を推測する手法を用いている。しかし本手法では、トラヒック流量がリンク帯域より大幅に小さい値であっても増加傾向と判別された時点で、通常状態への移行制御を行ってしまう。これにより、スリープ状態の期間が短くなる可能性があることから、電力削減効果は低くなると考えられる。したがって、よりリンク帯域に近いトラヒックの時点で制御をかけられるような手法が望ましい。
【００１１】
更に、より精度の高い制御を行うためには、突発的なトラヒック変動に対しても迅速に検知できることが望ましい。
【００１２】
例えば映像サービスなどは転送量が多く突発的な変動による影響が大きいと考えられるため、トラヒックの総量だけでなく、DPI（Deep Packet Inspection）装置により判別したサービスごとのトラヒック変動からもスリープ制御ができるのであれば、より精度の高い制御が期待できる。しかし、現在はサービスごとのフロー情報を用いてスリープ制御を行う方法が確立されていない。
【００１３】
本発明は上記の点に鑑みてなされたものであり、従来技術よりも電力削減効果の高いスリープ制御の技術を提供することを目的とする。また、電力削減効果が高く、しかも突発的なトラヒック変動に対しても迅速に対応可能な精度の高いスリープ制御の技術を提供することを目的とする。
【課題を解決するための手段】
【００１４】
上記の課題を解決するために、本発明は、複数の通信装置からなるネットワークにおいて、通信装置に対するスリープ制御を行うスリープ制御装置であって、
予め設定された閾値情報を保持する記憶手段と、
前記ネットワークにおける各通信装置からトラヒック情報を取得するトラヒック情報取得手段と、
前記閾値情報により定められる時間帯において、前記トラヒック情報から算出されたトラヒック総量が、前記閾値情報により定められるトラヒック量よりも小さい場合に、所定の通信装置を通常状態からスリープ状態に移行させる制御手段と、を備えるスリープ制御装置であり、
前記スリープ制御装置は、前記ネットワークから、予め定めた検出対象サービスについてのフロー情報を取得する手段を更に備え、
前記制御手段は、前記フロー情報に示される前記検出対象サービスのトラヒック状態が予め定めた条件を満たす場合に、通常状態にある通信装置のスリープ状態への移行を行なわないことを特徴とするスリープ制御装置として構成される。
【００１６】
前記予め定めた条件は、例えば、前記フロー情報から算出される転送量の増加率が前記閾値情報により定められる閾値を超えることである。前記時間帯は、例えば、前記閾値情報に含まれるスリープ時刻とウェイクアップ時刻間の時間帯である。
【００１７】
また、前記閾値情報により定められるトラヒック量は、例えば、前記複数の通信装置の中で最大の最大帯域を有する通信装置の当該最大帯域に、前記閾値情報に規定された割合を乗じて得られる値である。また、前記所定の通信装置は、例えば、前記最大の最大帯域を有する通信装置以外の通信装置である。
【００１８】
また、本発明は、上記スリープ制御装置が実行するスリープ制御方法、及び、コンピュータをスリープ制御装置における各手段として機能させるためのプログラムとして構成することもできる。
【発明の効果】
【００１９】
本発明の一実施形態によれば、従来技術よりも電力削減効果の高いスリープ制御の技術を提供することが可能となる。
【００２０】
すなわち、過去のトラヒック変動から一日のトラヒック変動特性をモデル化し、予め閾値を設定する手法を採用したことにより、例えばスリープ状態に移行する深夜や通常状態に移行する朝方というように時間帯を絞り込むことや、トラヒックの流量が少ない早朝はトラヒックの小規模な変動で通常状態へ移行しないことを考慮して、スリープ状態をより長く保持する制御を実現できる。
【００２１】
また、本発明の一実施形態によれば、電力削減効果が高く、しかも突発的なトラヒック変動に対しても迅速に対応可能な精度の高いスリープ制御の技術を提供することが可能となる。つまり、個々のサービスごとに設定した検出条件の閾値データを利用することでより精度の高い制御が可能になる。
【図面の簡単な説明】
【００２２】
【図１】本発明の実施の形態に係るシステムの全体構成図である。
【図２】ルータ１０の機能構成図である。
【図３】DPI装置３０の機能構成図である。
【図４】管理サーバ４０の機能構成図である。
【図５】ルータ情報保持部４５に格納されるルータ情報テーブルの例を示す図である。
【図６】閾値情報管理部４４に格納される閾値データの例を示す図である。
【図７】フロー情報の例を示す図である。
【図８】制御イメージを示す図である。
【図９】スリープ制御処理例１を示すフローチャートである。
【図１０】トラヒック総量閾値によるスリープ制御の概要を示す図である。
【図１１】スリープ制御処理例２を示すフローチャートである。
【図１２】効果を説明するための図である。
【発明を実施するための形態】
【００２３】
以下、図面を参照して本発明の実施の形態を説明する。なお、以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。
【００２４】
（システム構成）  
図１に、本発明の実施の形態に係るシステムの全体構成図を示す。図１に示すように、本実施の形態のシステムは、DPI装置３０、管理サーバ４０、ルータ１０、２０を有し、これらが通信可能なように互いにネットワーク接続されて構成されている。ルータ１０、２０は、通信事業者のネットワーク１００においてパケット転送を行う通信装置である。通信事業者のネットワーク１００は、そのエッジの配置されたゲートウェイ装置１０１、１０２を介して、インターネット１０４、ユーザ端末１０３に接続されている。
【００２５】
DPI装置３０は、管理サーバ４０から検出対象サービスの情報を受け取り、当該検出対象サービスのトラヒックを検出した場合に、そのフロー情報を管理サーバ４０に通知する装置である。管理サーバ４０は、管理するルータそれぞれについての状態と、DPI装置３０から受信するフロー情報に基づいて、ルータに対するスリープ制御を行う装置である。
【００２６】
図２に、ルータ１０の機能構成図を示す。ルータ２０も同様の構成であるため、図２にはルータ１０のみを示している。
【００２７】
図２に示すように、ルータ１０は、インタフェースA１１、インタフェースB１２、パケット処理部１３、インタフェースC１４、ルータ情報管理部１５、電源管理部１６を備える。
【００２８】
インタフェースA１１、B１２は、ネットワーク１００側と通信を行うインタフェースである。パケット処理部１３は、パケット送受信のための処理を行う。ルータ情報管理部１５は、パケット処理部１３からトラヒック情報（MIBなど）を取得し、メモリ等の記憶手段に保持する機能を有する。トラヒック情報は定期的に更新される。電源管理部１６は、インタフェースC１４から受信する管理サーバ４０からのスリープ制御に係る制御要求に従って、ルータ１０１の状態を移行させる機能を有する。
【００２９】
インタフェースC１４は、管理サーバ４０と通信を行うインタフェースであり、管理サーバ４０からルータ情報の要求を受けた場合、ルータ情報管理部１５からMIB情報を受け取り、管理サーバ２０１へ送信する機能、管理サーバ２０１からスリープ制御の要求を受け、電源管理部１６に通知する機能等を有する。
【００３０】
なお、ルータ１０１の構成のうち、インタフェースC１４と電源管理部１６以外は、既存のルータにも備えられている。つまり、既存のルータにインタフェースC１４と電源管理部１６を追加したものが本実施の形態におけるルータである。
【００３１】
図３に、DPI装置３０の機能構成図を示す。図３に示すように、本実施の形態に係るDPI装置３０は、インタフェースA３１、インタフェースB３２、インタフェースC３３、パケット処理部３４、パケット比較部３５、フロー情報処理部３６を含む。
【００３２】
インタフェースA３１、インタフェースB３２は、それぞれ異なるルータと接続されるインタフェースであり、インタフェースC３３は、管理サーバ４０と通信を行うインタフェースである。パケット処理部３４は、インタフェースA３１、B３２を介したパケット送受信のための処理や、インタフェースＡ３１とインタフェースＢ３２間を流れるパケットのミラーリングを行う機能を有する。
【００３３】
パケット比較部３５は、管理サーバ４０から通知され、フロー情報通知部３６から受け取った検出対象サービスの情報をメモリ等の記憶手段に保持し、パケット処理部３４によりミラーリングされたパケットを監視し、検出対象サービスに合致するパケットがあるかどうかを判別し、あった場合は該当フローのフロー情報をフロー情報処理部３６に通知する機能を有する。
【００３４】
フロー情報処理部３６は、検出対象サービスに係るフロー情報を管理サーバ４０に通知する機能、管理サーバ４０から新たな検出対象サービスの情報を受け取った場合に、パケット比較部３５に当該情報を通知する機能を有する。
【００３５】
図４に、管理サーバ４０の機能構成図を示す。図４に示すように、本実施の形態に係る管理サーバ４０は、インタフェースA４１、インタフェースB４２、スリープ制御部４３、閾値情報保持部４４、ルータ情報保持部４５を有する。  
インタフェースA４１はルータと通信を行うインタフェースであり、インタフェースB４２はDPI装置３０と通信を行うインタフェースである。
【００３６】
スリープ制御部４３は、管理するルータそれぞれについて、ルータの状態を確認し、ルータ情報テーブルとして各ルータの状態をルータ情報保持部４５に格納する機能、DPI装置３０へ閾値データの検出対象サービスを送る機能、DPI装置３０から検出対象サービスごとのフロー情報を取得する機能、及び、閾値データ、ルータ情報テーブル、サービスごとのフロー情報をもとに、スリープ制御処理によって各ルータに対してスリープ制御を行う機能などを備える。
【００３７】
閾値情報保持部４４には、予め設定された閾値データが格納される。ルータ情報保持部４５には、上記のルータ情報テーブルが格納される。
【００３８】
図５に、ルータ情報保持部４５に格納されるルータ情報テーブルの例を示す。図５に示すように、ルータ情報テーブルには、装置ID：ルータを識別するためのID、状態：    ルータの状態（0：スリープ状態、1：通常状態）、最大帯域：ルータが転送できる最大帯域 [Mbps]、スリープ処理時間：通常状態からスリープ状態への移行にかかる時間 [秒]、ウェイクアップ処理時間    ：スリープ状態から通常状態への移行にかかる時間 [秒]、トラヒック情報ログ：トラヒック情報 [Mbps]が格納される。
【００３９】
上記の情報のうち、「状態」は、スリープ制御部４３による現在の制御内容に基づく情報であり、「トラヒック情報ログ」は、ルータから収集された現在のトラヒック情報である。これら以外は予め格納される情報である。
【００４０】
図６に、閾値情報管理部４４に格納される閾値データの例を示す。図５に示すように、閾値データは、トラヒック閾値割合：スリープ時の最大帯域に対する割合、スリープ時刻：スリープ状態へ移行する時刻（hhmm表記）、ウェイクアップ時刻：通常状態へ移行する時刻（hhmm表記）、検出対象サービス：検出サービス（例としてIPアドレスで表記）、
検出対象サービスの検出条件：検出条件（例として1秒当たりの転送量の増加割合で表記）を含む。検出対象サービスに関するデータについては、検出対象サービス毎のデータを含む。
【００４１】
トラヒック閾値割合、スリープ時刻、ウェイクアップ時刻は、過去のトラヒック変動から一日のトラヒック変動特性をモデル化することにより決定されたものである。なお、本実施の形態では、「トラヒック閾値割合」を用い、最大帯域と乗算したものを判定閾値として使用しているが、閾値情報として、判定閾値となるトラヒック量（転送量）を設定してもよい。検出対象サービス及びその検出条件については、個々のサービスの提供状況や特性などに基づいて決定されたものである。
【００４２】
図７に、サービスごとにDPI装置３０から取得され、スリープ制御部４３によりスリープ制御の判断に用いられるフロー情報の例を示す。図７に示すように、フロー情報は、サービス名：サービス（例えばIPアドレスで表記）、現在の転送量：現在の転送量 [Mbps]、t秒前の転送量：t秒前の転送量 [Mbps]を含む。
【００４３】
管理サーバ４０は、通信インタフェースを持ち、ＣＰＵ及びメモリ等を有するコンピュータに、本実施の形態で説明する処理内容を記述したプログラムを実行させることにより実現可能である。すなわち、管理サーバ４０が有する機能（特にスリープ制御部４３の機能）は、当該管理サーバ４０を構成するコンピュータに内蔵されるＣＰＵやメモリなどのハードウェア資源を用いて、プログラムを実行することによって実現することが可能である。また、上記プログラムは、コンピュータが読み取り可能な記録媒体（可搬メモリ等）に記録して、保存したり、配布したりすることが可能である。また、上記プログラムをインターネットや電子メールなど、ネットワークを通して提供することも可能である。
【００４４】
（スリープ制御概要）
次に、本実施の形態におけるスリープ制御がどのようにして行われるかの制御概要を図８を適宜参照して説明する。
【００４５】
各ルータがそれぞれ通常状態にある場合（例：図８の（１）の領域）、以下のような制御が行われる。
【００４６】
管理サーバ４０は、定期的に各ルータからトラヒック情報を取得し、ルータ情報テーブルを更新するとともに、閾値データの検出対象サービスをもとに、DPI装置３０からフロー情報を取得する。そして、管理サーバ４０はルータ情報テーブル、閾値データ、フロー情報から、スリープ制御処理（具体的処理は後述）によってルータの状態を判断する。
【００４７】
いずれのルータも通常状態のまま継続であれば、上記のトラヒック情報取得処理に戻る。また、判断の結果、いずれかのルータがスリープ状態へ移行する場合、管理サーバ４０は該当ルータの電源管理部に対して、スリープ状態へ移行を要求する。これにより、スリープ状態へ移行を要求されたルータはスリープ状態へ移行し、消費電力が削減される。
【００４８】
いずれかのルータがスリープ状態にある場合（例：図８の（２）の領域）、以下のような制御が行われる。
【００４９】
管理サーバ４０は、定期的に各ルータからトラヒック情報を取得し、ルータ情報テーブルを更新するとともに、閾値データの検出対象サービスをもとに、DPI装置３０からフロー情報を取得する。そして、管理サーバ４０はルータ情報テーブル、閾値データ、フロー情報から、スリープ制御処理（具体的処理は後述）によってルータの状態を判断する。
【００５０】
いずれのルータも現在の状態のまま継続であれば、上記のトラヒック情報取得処理に戻る。また、判断の結果、いずれかのルータが通常状態へ移行する場合、管理サーバ４０は該当ルータの電源管理部に対して、通常状態へ移行を要求する。これにより、通常状態へ移行を要求されたルータは通常状態へ移行し、トラヒックの処理を行う。
【００５１】
（スリープ制御処理例１）
次に、管理サーバ４０のスリープ制御部４３により実行されるスリープ制御処理例１を図９のフローチャートを参照して詳細に説明する。この処理例１は、サービス毎のフロー情報を使用しない例である。
【００５２】
ステップ１）管理しているすべてのルータから転送量を示すトラヒック情報を取得し、ルータ情報テーブルとしてルータ情報保持部４５に保存する。
【００５３】
ステップ２）すべてのルータの転送量の和（トラヒック総量）を計算し、その和が、最大帯域が最も大きいルータの最大帯域×トラヒック閾値より小さいかどうかを判断する。判断の結果、Ｙｅｓであればステップ３に進み、Ｎｏであればステップ５に進む。なお、ここでのすべてのルータの転送量の和とは、通常状態にあるすべてのルータの転送量の和である。
【００５４】
ステップ３）現時刻、スリープ時刻、ウェイクアップ時刻を取得し、スリープ時刻＜現時刻＜ウェイクアップ時刻であるかどうかを判断する。判断の結果、Ｙｅｓであればステップ４に進み、Ｎｏであればステップ５に進む。
【００５５】
ステップ４）最大帯域が最も大きいルータ以外のルータをスリープ状態へ変更し、ルータ情報テーブルを更新する。既にスリープ状態である場合はスリープ状態を継続する。
【００５６】
ステップ５）ステップ２、３でＮｏの場合、スリープ状態であるすべてのルータを通常状態に変更する。通常状態であったルータはそのまま通常状態を継続する。
【００５７】
上記の処理は例えば一定時間間隔で繰り返し行われる。なお、上記の例では、スリープ状態に変更する条件を満たしたときに、スリープ状態にせずに通常状態を継続させるルータを、最大帯域が最も大きいルータとしているが、スリープ状態にせずに通常状態を継続させるルータを複数定めてもよい（例えば最大帯域が所定値以上の複数ルータ）。その場合は、ステップ２での判断は、例えば「通常状態を継続させると定めたルータの最大帯域の和×予め定めた閾値」と転送量の和との比較により行うことができる。これらの点は、後述する処理例２の場合での同様である。
【００５８】
図１０は、図９のフローチャートで示したトラヒック総量閾値によるスリープ制御の概要を示す図である。図１０に示すように、トラヒックが高いことが統計上把握されているウェイクアップ時刻からスリープ時刻までの間はスリープ状態への制御は行われず、トラヒックが低下するスリープ時刻以降に、閾値を下回ったことを条件にしてスリープ状態への制御が行われる。スリープ時刻後、ウェイクアップ時刻に近くなり、トラヒックが閾値を超えたところで通常状態への制御が行われる。
【００５９】
（スリープ制御処理例２）
次に、管理サーバ４０のスリープ制御部４３により実行されるスリープ制御処理例２を図１１のフローチャートを参照して説明する。この処理例２は、処理例１での閾値制御に加えて、サービス毎のフロー情報を使用した制御を行う例である。なお、省電力化の効果を得るために、サービス毎のフロー情報を使用した制御を行うことは必須ではない。処理例１のようにトラヒック総量の閾値制御のみでも、省電力化の効果は得られる。処理例２により、より精度の高い制御を行うことができる。
【００６０】
ステップ１１）管理しているすべてのルータから転送量を示すトラヒック情報を取得し、ルータ情報テーブルとしてルータ情報保持部４５に保存する。
【００６１】
ステップ１２）すべてのルータの転送量の和を計算し、その和が、最大帯域が最も大きいルータの最大帯域×トラヒック閾値より小さいかどうかを判断する。判断の結果、Ｙｅｓであればステップ１３に進み、Ｎｏであればステップ１７に進む。なお、ここでのすべてのルータの転送量の和とは、通常状態にあるすべてのルータの転送量の和である。
【００６２】
ステップ１３）現時刻、スリープ時刻、ウェイクアップ時刻を取得し、スリープ時刻＜現時刻＜ウェイクアップ時刻であるかどうかを判断する。判断の結果、Ｙｅｓであればステップ１４に進み、Ｎｏであればステップ１７に進む。
【００６３】
ステップ１４）DPI装置３０へn個（ｎは１以上の整数）の検出対象サービス情報を送り、n個のフロー情報を取得する。
【００６４】
ステップ１５）検出されたフロー情報をもとに算出した増加率が閾値（増加率）を超えているかどうかを判断する。より具体的には、本例では、t秒間における転送量の傾きが閾値の増加率を超えるかどうかを判断する。すなわち、（現在の転送量−ｔ秒前の転送量）÷ｔ秒にて各検出対象サービスの増加率を算出し、n個のフロー情報のうち、一つでも閾値の増加率を超えている場合はステップ１５の判定結果をＹｅｓとする。ステップ１５でＹｅｓの場合はステップ１７に進み、Ｎｏの場合はステップ１６に進む。
【００６５】
ステップ１６）最大帯域が最も大きいルータ以外のルータをスリープ状態へ変更し、ルータ情報テーブルを更新する。既にスリープ状態である場合はスリープ状態を継続する。
【００６６】
ステップ１７）ステップ１２、１３でＮｏの場合、もしくは、ステップ１５でＹｅｓの場合、スリープ状態であるすべてのルータを通常状態に変更する。通常状態であったルータはそのまま通常状態を継続する。
【００６７】
なお、上記の例では、検出条件として転送量の増加率を用いているが、これは一例に過ぎずない。検出条件として、トラヒックの増加率のほかに、プロトコル種別や転送量などを用いてもよい。すなわち、例えば、いずれかの検出対象サービスにおいて、特定のプロトコル種別のパケットが検出されたら通常状態への移行を行う（もしくは、スリープ状態への移行を行わない）制御や、いずれかの検出対象サービスにおいて、転送量が閾値を超えたら通常状態への移行を行う（もしくは、スリープ状態への移行を行わない）制御などを行ってもよい。つまり、DPI装置３０から取得されたフロー情報に示される検出対象サービスのトラフィック状態が予め定めた条件を満たす場合に上記制御を行う。
【００６８】
（実施の形態の効果について）
本実施の形態で説明したように、過去のトラヒック変動特性に基づいた帯域や時間帯の閾値データを利用することで、実際のトラヒック変動に即した制御が可能になる。特にトラヒックが少ない時間帯においては、トラヒックの小さい変動に対して過敏にスリープ制御を行わなくなるため、ルータのスリープ状態を持続でき、省電力効果を高めることが可能である。
【００６９】
また、本実施の形態で説明したように、過去のトラヒック変動特性に基づいた帯域や時間帯の閾値データを利用することに加えて、DPI装置にて検出されたサービスごとのフロー情報と、個々のサービスごとに設定した検出条件の閾値データを利用することで、トラヒックの総量の変動を利用した制御と比較し、より精度の高い制御が可能になる。
【００７０】
例として、本実施の形態のようにサービスごとにトラヒックの増減率を閾値として設定した場合、トラヒック総量としては減少傾向であっても、あるサービスのみトラヒックが増加しているような状況を検出できるため、通常状態からスリープ状態へ移行する際の判断を適切にできると考えられる。  
図１２を用いてこの効果を説明する。図１２には、サービスＢのトラヒックが増加して、およそ８分のところでトラヒックの総量が閾値を超える場合を示している。この状況で、トラヒックの総量だけでスリープ制御を判断すると、スリープへ移行してしまい、サービスBのトラヒック増加に対応できず、リンク溢れを起こす可能性ある。一方、サービスごとに増加率を判断することにより、サービスBの増加率に基づいて、スリープへの移行を行わないことを判断できるため、適切に対応できる。
【００７１】
本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において、種々変更・応用が可能である。
【符号の説明】
【００７２】
１００  ネットワーク
１０１、１０２  ゲートウェイ装置
１０３  ユーザ端末
１０、２０  ルータ
１１  インタフェースA
１２  インタフェースB
１３  パケット処理部
１４  インタフェースC
１５  ルータ情報管理部
１６  電源管理部
３０  DPI装置
３１  インタフェースA
３２  インタフェースB
３３  インタフェースC
３４  パケット処理部
３５  パケット比較部
３６  フロー情報処理部
４０  管理サーバ
４１  インタフェースA
４２  インタフェースB
４３  スリープ制御部
４４  閾値情報保持部
４５  ルータ情報保持部
【図１】
0005700842.tif 000002
【図２】
0005700842.tif 000003
【図３】
0005700842.tif 000004
【図４】
0005700842.tif 000005
【図５】
0005700842.tif 000006
【図６】
0005700842.tif 000007
【図７】
0005700842.tif 000008
【図８】
0005700842.tif 000009
【図９】
0005700842.tif 000010
【図１０】
0005700842.tif 000011
【図１１】
0005700842.tif 000012
【図１２】
0005700842.tif 000013