(57)【特許請求の範囲】
【請求項１】
顧客毎に、当該顧客の通信トラフィックの量の時間的変化のパターンを示すトラフィックパターンを計測する計測手段と、
前記計測手段により計測された各顧客のトラフィックパターンに基づき、複数の通信チャネルの各々に対して、当該通信チャネルを使用する顧客を割り当てる割当手段と、
前記顧客宛の配信データを配信する通信チャネルとして、前記割当手段が当該顧客を割り当てた通信チャネルを選択する制御を行う配信制御手段と、
を備え、
前記割当手段は、前記複数の通信チャネルの各々について、当該通信チャネルに割り当てられる１以上の顧客の前記トラフィックパターンを合計した合計パターンが、当該通信チャネルの通信路容量に収まるよう、前記複数の通信チャネルの各々に対して割り当てる１以上の顧客を決定し、
前記割当手段は、
前記各顧客の前記トラフィックパターンのパターン形状の特徴を表す特徴ベクトルを求める手段と、
前記特徴ベクトル同士の類似度に基づいて前記各顧客を複数のクラスタにクラスタ分けするクラスタ分け手段と、
前記クラスタ分け手段によりクラスタ分けされたクラスタ毎に、当該クラスタに属する特徴ベクトルの範囲を記憶するクラスタ範囲情報記憶手段と、
前記複数の通信チャネルの各々について、当該通信チャネルに割り当てられる１以上の顧客の前記トラフィックパターンを合計した合計パターンが当該通信チャネルの通信路容量に収まる顧客の組合せを、それら顧客の属するクラスタの組合せで表現したものを、当該通信チャネルに割当可能なクラスタの組合せとして記憶する組合せ情報記憶手段と、
を備え、前記各顧客のトラフィックパターンの特徴ベクトルが属するクラスタを前記クラスタ範囲情報記憶手段に記憶された情報から求め、求めた前記各顧客に対応するクラスタに基づき、前記組合せ情報記憶手段に記憶された前記通信チャネルに割当可能なクラスタの組合せを満たす前記顧客の組合せの中から、当該通信チャネルに割り当てる顧客の組合せを求める、
ことを特徴とする通信管理システム。
【請求項２】
前記配信制御手段は、
前記複数の通信チャネルのうち少なくとも１つの通信チャネルについて、当該通信チャネルに割り当てられた各顧客宛の配信データのある時点での合計量が当該通信チャネルの通信路容量を超過する場合に、超過した分の配信データを当該通信チャネルから削除し、当該超過した分の配信データの配信経路を当該時点で通信路容量に空きのある他の一以上の通信チャネルにスイッチするスイッチ制御を行うスイッチ制御手段、
を備えることを特徴とする、請求項１に記載の通信管理システム。
【請求項３】
前記スイッチ制御手段は、前記複数の通信チャネルのうち、当該通信チャネルに割り当てられた顧客のトラフィックパターンを合計した合計パターンの示す前記超過の時点での通信トラフィックの量よりも通信路容量が多い通信チャネルを、前記空きのある他の一以上の通信チャネルとして選択する、ことを特徴とする請求項２に記載の通信管理システム。
【請求項４】
前記配信制御手段は、
前記通信チャネルに割り当てられた各顧客宛の配信データのある時点での合計量が当該通信チャネルの通信路容量を超過する場合には、その時点の配信データのうち、当該配信データの重要度に基づき決まる当該配信データの配信保証時刻がその時点より後のものを、次の時点以降にシフトするシフト手段、
を備え、
前記スイッチ制御手段は、前記シフト手段によりすべての配信データを当該配信データの配信保証時刻までシフトしたとしても、前記複数の通信チャネルのうち少なくとも１つの通信チャネルについて、当該通信チャネルに割り当てられた各顧客宛の配信データのある時点での合計量が当該通信チャネルの通信路容量を超過する場合に、超過した分の配信データを当該通信チャネルから削除し、当該超過した分の配信データの配信経路を当該時点で通信路容量に空きのある他の一以上の通信チャネルにスイッチする、
ことを特徴とする、請求項２又は３に記載の通信管理システム。
【請求項５】
前記各顧客からスケジュール項目の登録を受け付けるスケジュール登録手段であって、前記顧客から登録されたスケジュール項目に対応づけて当該顧客宛に配信すべき配信データの登録を受け付けるスケジュール登録手段、を更に備え、
前記配信制御手段は、前記スケジュール登録手段に登録された前記スケジュール項目の予定時刻を、当該スケジュール項目に対応づけて登録された前記配信データの配信指定時刻とし、当該配信データを当該配信指定時刻に配信するよう制御する、
ことを特徴とする請求項１〜３のいずれか１項に記載の通信管理システム。
【請求項６】
前記スケジュール項目に対応づけて登録された前記配信データの配信指定時刻に当該配信データの重要度に応じて決まる許容遅延時間を加算した配信保証時刻を求める手段、を更に備え、
前記配信制御手段は、当該通信チャネルに割り当てられた各顧客宛の配信データのある時点での合計量が当該通信チャネルの通信路容量を超過する場合には、その時点の配信データのうち前記配信保証時刻がその時点より後のものを、次の時点以降にシフトする、
ことを特徴とする請求項５に記載の通信管理システム。
【請求項７】
前記複数の通信チャネルのうちのベストエフォート型の通信チャネルについて、その通信チャネルの実効的な通信路容量の時間的変化のパターンを計測する容量パターン計測手段、を更に備え、
前記割当手段は、ベストエフォート型の通信チャネルについては、当該通信チャネルに割り当てられる１以上の顧客の前記トラフィックパターンを合計した合計パターンが、前記容量パターン計測手段により計測された当該通信チャネルの実効的な通信路容量の時間的変化のパターンに収まるよう、当該通信チャネルに対して割り当てる１以上の顧客を決定する、
ことを特徴とする請求項１〜６のいずれか１項に記載の通信管理システム。
【請求項８】
コンピュータを、
顧客毎に、当該顧客の通信トラフィックの量の時間的変化のパターンを示すトラフィックパターンを計測する計測手段、
前記計測手段により計測された各顧客のトラフィックパターンに基づき、複数の通信チャネルの各々に対して、当該通信チャネルを使用する顧客を割り当てる割当手段、
前記顧客宛の配信データを配信する通信チャネルとして、前記割当手段が当該顧客を割り当てた通信チャネルを選択する制御を行う配信制御手段、
として機能させるためのプログラムであって、
前記割当手段は、前記複数の通信チャネルの各々について、当該通信チャネルに割り当てられる１以上の顧客の前記トラフィックパターンを合計した合計パターンが、当該通信チャネルの通信路容量に収まるよう、前記複数の通信チャネルの各々に対して割り当てる１以上の顧客を決定し、
前記割当手段は、
前記各顧客の前記トラフィックパターンのパターン形状の特徴を表す特徴ベクトルを求める手段と、
前記特徴ベクトル同士の類似度に基づいて前記各顧客を複数のクラスタにクラスタ分けするクラスタ分け手段と、
前記クラスタ分け手段によりクラスタ分けされたクラスタ毎に、当該クラスタに属する特徴ベクトルの範囲を記憶するクラスタ範囲情報記憶手段と、
前記複数の通信チャネルの各々について、当該通信チャネルに割り当てられる１以上の顧客の前記トラフィックパターンを合計した合計パターンが当該通信チャネルの通信路容量に収まる顧客の組合せを、それら顧客の属するクラスタの組合せで表現したものを、当該通信チャネルに割当可能なクラスタの組合せとして記憶する組合せ情報記憶手段と、
を備え、前記各顧客のトラフィックパターンの特徴ベクトルが属するクラスタを前記クラスタ範囲情報記憶手段に記憶された情報から求め、求めた前記各顧客に対応するクラスタに基づき、前記組合せ情報記憶手段に記憶された前記通信チャネルに割当可能なクラスタの組合せを満たす前記顧客の組合せの中から、当該通信チャネルに割り当てる顧客の組合せを求める、
ことを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信管理システム及びプログラムに関する。
【背景技術】
【０００２】
特許文献１に開示されるシステムでは、負荷分散指示にもとづき、トラフィックを複数の経路に振り分ける。管理データベースは、統計情報を格納管理する。負荷分散制御部は、管理データベース内の統計情報にもとづいて、入口ノードと出口ノード間の経路の負荷分散計算を行って、負荷分散指示を出力し、１つの負荷分散計算が終わる毎に、統計情報の予測値により管理データベースの統計情報を更新する。
【０００３】
特許文献２に開示される優先制御システムは、優先制御時間帯を優先権として発行することにより、優先制御時間帯での接続要求をユーザに促す。これにより、短時間に集中していた接続要求を時間的に分散すると共に、特定の優先制御時間帯にのみ優先的な制御を行うことで移動通信システムへの負荷を低減する。
【０００４】
特許文献３に開示される帯域制御装置は、制御対象通信装置及び／又は制御対象通信装置と接続する通信装置から、制御対象通信装置を経由する回線のトラフィックと相関のあるトラフィック相関情報を収集する情報収集手段と、トラフィック相関情報から、互いに異なるアルゴリズムにより前記回線の帯域を算出する複数の帯域算出手段と、各帯域算出手段が算出した前記回線の帯域と、前記回線のトラフィックの実測値との関係の履歴に基づき、帯域算出手段を選択する選択手段と、選択した帯域算出手段が算出した前記回線の帯域を、制御対象通信装置に設定する手段と、を備える。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００４−１４７０６０号公報
【特許文献２】特開２００７−０５３６７６号公報
【特許文献３】特開２００８−１９９４５１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
本発明は、複数の通信チャネルを複数の顧客により共用する場合において、本発明を用いない場合に比べて、それら通信チャネルをより効率的に利用できるようにすることを目的とする。
【課題を解決するための手段】
【０００７】
請求項１に係る発明は、顧客毎に、当該顧客の通信トラフィックの量の時間的変化のパターンを示すトラフィックパターンを計測する計測手段と、前記計測手段により計測された各顧客のトラフィックパターンに基づき、複数の通信チャネルの各々に対して、当該通信チャネルを使用する顧客を割り当てる割当手段と、前記顧客宛の配信データを配信する通信チャネルとして、前記割当手段が当該顧客を割り当てた通信チャネルを選択する制御を行う配信制御手段と、を備え、前記割当手段は、前記複数の通信チャネルの各々について、当該通信チャネルに割り当てられる１以上の顧客の前記トラフィックパターンを合計した合計パターンが、当該通信チャネルの通信路容量に収まるよう、前記複数の通信チャネルの各々に対して割り当てる１以上の顧客を決定し、前記割当手段は、前記各顧客の前記トラフィックパターンのパターン形状の特徴を表す特徴ベクトルを求める手段と、前記特徴ベクトル同士の類似度に基づいて前記各顧客を複数のクラスタにクラスタ分けするクラスタ分け手段と、前記クラスタ分け手段によりクラスタ分けされたクラスタ毎に、当該クラスタに属する特徴ベクトルの範囲を記憶するクラスタ範囲情報記憶手段と、前記複数の通信チャネルの各々について、当該通信チャネルに割り当てられる１以上の顧客の前記トラフィックパターンを合計した合計パターンが当該通信チャネルの通信路容量に収まる顧客の組合せを、それら顧客の属するクラスタの組合せで表現したものを、当該通信チャネルに割当可能なクラスタの組合せとして記憶する組合せ情報記憶手段と、を備え、前記各顧客のトラフィックパターンの特徴ベクトルが属するクラスタを前記クラスタ範囲情報記憶手段に記憶された情報から求め、求めた前記各顧客に対応するクラスタに基づき、前記組合せ情報記憶手段に記憶された前記通信チャネルに割当可能なクラスタの組合せを満たす前記顧客の組合せの中から、当該通信チャネルに割り当てる顧客の組合せを求める、ことを特徴とする通信管理システムである。
【０００８】
請求項２に係る発明は、前記配信制御手段は、前記複数の通信チャネルのうち少なくとも１つの通信チャネルについて、当該通信チャネルに割り当てられた各顧客宛の配信データのある時点での合計量が当該通信チャネルの通信路容量を超過する場合に、超過した分の配信データを当該通信チャネルから削除し、当該超過した分の配信データの配信経路を当該時点で通信路容量に空きのある他の一以上の通信チャネルにスイッチするスイッチ制御を行うスイッチ制御手段、を備えることを特徴とする、請求項１に記載の通信管理システムである。
【０００９】
請求項３に係る発明は、前記スイッチ制御手段は、前記複数の通信チャネルのうち、当該通信チャネルに割り当てられた顧客のトラフィックパターンを合計した合計パターンの示す前記超過の時点での通信トラフィックの量よりも通信路容量が多い通信チャネルを、前記空きのある他の一以上の通信チャネルとして選択する、ことを特徴とする請求項２に記載の通信管理システムである。
【００１０】
請求項４に係る発明は、前記配信制御手段は、前記通信チャネルに割り当てられた各顧客宛の配信データのある時点での合計量が当該通信チャネルの通信路容量を超過する場合には、その時点の配信データのうち、当該配信データの重要度に基づき決まる当該配信データの配信保証時刻がその時点より後のものを、次の時点以降にシフトするシフト手段、を備え、前記スイッチ制御手段は、前記シフト手段によりすべての配信データを当該配信データの配信保証時刻までシフトしたとしても、前記複数の通信チャネルのうち少なくとも１つの通信チャネルについて、当該通信チャネルに割り当てられた各顧客宛の配信データのある時点での合計量が当該通信チャネルの通信路容量を超過する場合に、超過した分の配信データを当該通信チャネルから削除し、当該超過した分の配信データの配信経路を当該時点で通信路容量に空きのある他の一以上の通信チャネルにスイッチする、ことを特徴とする、請求項２又は３に記載の通信管理システムである。
【００１１】
請求項５に係る発明は、前記各顧客からスケジュール項目の登録を受け付けるスケジュール登録手段であって、前記顧客から登録されたスケジュール項目に対応づけて当該顧客宛に配信すべき配信データの登録を受け付けるスケジュール登録手段、を更に備え、前記配信制御手段は、前記スケジュール登録手段に登録された前記スケジュール項目の予定時刻を、当該スケジュール項目に対応づけて登録された前記配信データの配信指定時刻とし、当該配信データを当該配信指定時刻に配信するよう制御する、ことを特徴とする請求項１〜３のいずれか１項に記載の通信管理システムである。
【００１２】
請求項６に係る発明は、前記スケジュール項目に対応づけて登録された前記配信データの配信指定時刻に当該配信データの重要度に応じて決まる許容遅延時間を加算した配信保証時刻を求める手段、を更に備え、前記配信制御手段は、当該通信チャネルに割り当てられた各顧客宛の配信データのある時点での合計量が当該通信チャネルの通信路容量を超過する場合には、その時点の配信データのうち前記配信保証時刻がその時点より後のものを、次の時点以降にシフトする、ことを特徴とする請求項５に記載の通信管理システムである。
【００１４】
請求項７に係る発明は、前記複数の通信チャネルのうちのベストエフォート型の通信チャネルについて、その通信チャネルの実効的な通信路容量の時間的変化のパターンを計測する容量パターン計測手段、を更に備え、前記割当手段は、ベストエフォート型の通信チャネルについては、当該通信チャネルに割り当てられる１以上の顧客の前記トラフィックパターンを合計した合計パターンが、前記容量パターン計測手段により計測された当該通信チャネルの実効的な通信路容量の時間的変化のパターンに収まるよう、当該通信チャネルに対して割り当てる１以上の顧客を決定する、ことを特徴とする請求項１〜６のいずれか１項に記載の通信管理システムである。
【００１５】
請求項８に係る発明は、コンピュータを、顧客毎に、当該顧客の通信トラフィックの量の時間的変化のパターンを示すトラフィックパターンを計測する計測手段、前記計測手段により計測された各顧客のトラフィックパターンに基づき、複数の通信チャネルの各々に対して、当該通信チャネルを使用する顧客を割り当てる割当手段、前記顧客宛の配信データを配信する通信チャネルとして、前記割当手段が当該顧客を割り当てた通信チャネルを選択する制御を行う配信制御手段、として機能させるためのプログラムであって、前記割当手段は、前記複数の通信チャネルの各々について、当該通信チャネルに割り当てられる１以上の顧客の前記トラフィックパターンを合計した合計パターンが、当該通信チャネルの通信路容量に収まるよう、前記複数の通信チャネルの各々に対して割り当てる１以上の顧客を決定し、前記割当手段は、前記各顧客の前記トラフィックパターンのパターン形状の特徴を表す特徴ベクトルを求める手段と、前記特徴ベクトル同士の類似度に基づいて前記各顧客を複数のクラスタにクラスタ分けするクラスタ分け手段と、前記クラスタ分け手段によりクラスタ分けされたクラスタ毎に、当該クラスタに属する特徴ベクトルの範囲を記憶するクラスタ範囲情報記憶手段と、前記複数の通信チャネルの各々について、当該通信チャネルに割り当てられる１以上の顧客の前記トラフィックパターンを合計した合計パターンが当該通信チャネルの通信路容量に収まる顧客の組合せを、それら顧客の属するクラスタの組合せで表現したものを、当該通信チャネルに割当可能なクラスタの組合せとして記憶する組合せ情報記憶手段と、を備え、前記各顧客のトラフィックパターンの特徴ベクトルが属するクラスタを前記クラスタ範囲情報記憶手段に記憶された情報から求め、求めた前記各顧客に対応するクラスタに基づき、前記組合せ情報記憶手段に記憶された前記通信チャネルに割当可能なクラスタの組合せを満たす前記顧客の組合せの中から、当該通信チャネルに割り当てる顧客の組合せを求める、ことを特徴とするプログラムである。
【発明の効果】
【００１６】
請求項１又は８に係る発明によれば、複数の通信チャネルを複数の顧客により共用する場合において、本発明を用いない場合に比べて、それら通信チャネルをより効率的に利用できるようにすることができると共に、個々の顧客のトラフィックパターン同士を実際に合計して合計パターンを求め、その合計パターンが通信チャネルの通信路容量に収まるかどうかを判定するよりも低い計算負荷で、通信チャネルに割り当てる１以上の顧客を求めることができる。
【００１７】
請求項２に係る発明によれば、トラフィックパターンの合計パターンから想定されるトラフィック量以上の配信データが到来した場合でも、通信チャネルのオーバーフローの可能性を低減することができる。
【００１８】
請求項３に係る発明によれば、各通信チャネルのリアルタイムの空き容量を求めることでスイッチ先の他の通信チャネルを求める方式よりも低い計算負荷で、スイッチ先の他の通信チャネルを求めることができる。
【００１９】
請求項４に係る発明によれば、配信タイミングの遅延により通信チャネルのオーバーフローを防ぎつつも、遅延だけではオーバーフローを防げない場合にも他の通信チャネルへのスイッチによりオーバーフローの可能性を低減することができる。
【００２０】
請求項５に係る発明によれば、各顧客のスケジュールに合わせた時刻に配信データを配信することができる。
【００２１】
請求項６に係る発明によれば、各配信データの重要度に応じた遅延により通信チャネルのオーバーフローの可能性を低減することができる。
【００２３】
請求項７に係る発明によれば、ベストエフォート型の通信チャネルに対して、この発明を用いない場合よりも適切に顧客を割り当てることができる。
【図面の簡単な説明】
【００２４】
【図１】実施形態の通信管理方式が適用されるネットワーク環境の一例を示す図である。
【図２】通信管理システムの構成の一例を示す図である。
【図３】顧客組織のトラフィックパターンの例を示す図である。
【図４】トラフィックパターンＤＢのデータ内容の一例を示す図である。
【図５】チャネル特徴ＤＢのデータ内容の一例を示す図である。
【図６】複数の顧客組織の組合せ方の違いによる、トラフィックパターンの合計の違いを説明するための図である。
【図７】トラフィックパターンの特徴ベクトルのクラスタ分けの例を示す図である。
【図８】トラフィックパターンの特徴ベクトルのクラスタ分けの例を示す図である。
【図９】クラスタの部分的な重複を許すクラスタ分けの例を示す図である。
【図１０】パターンクラスタ情報ＤＢのデータ内容の一例を示す図である。
【図１１】割当可能組合せＤＢのデータ内容の一例を示す図である。
【図１２】チャネル割当ＤＢのデータ内容の一例を示す図である。
【図１３】合計パターンＤＢのデータ内容の一例を示す図である。
【図１４】トラフィック制御部の構成の一例を示す図である。
【図１５】配信スケジュール記憶部のデータ内容の一例を示す図である。
【図１６】トラフィック・シェーパー・スイッチャーによるトラフィックシェーピング（パケットシフト）の手順の一例を示す図である。
【図１７】トラフィック・シェーパー・スイッチャーによるチッピング・スイッチングの手順の一例を示す図である。
【図１８】トラフィックシェーピング（パケットシフト）を説明するための図である。
【発明を実施するための形態】
【００２５】
図１に示すように、本実施形態の通信管理を担う通信管理システム１００は、一例として、複数の顧客組織２０内の端末２２に対して情報処理サービスを提供するサービスシステム１０に適用される。すなわち、本実施形態の通信管理システム１００は、サービスシステム１０が顧客組織２０内の端末２２に対して情報処理サービスを提供する際の通信トラフィックを管理する。本実施形態の通信管理方式は、サービスシステム１０自体の形態には依存しない。例えば、サービスシステム１０は、単体のサーバであってもよいし、複数のコンピュータからなるいわゆるクラウド型のシステムであってもよい。また、本実施形態の通信管理方式は、サービスシステム１０が提供する情報処理サービスの内容にも依存しない。
【００２６】
本実施形態では、サービスシステム１０を運営する事業者は、通信事業者（いわゆる「通信キャリア」）から複数の通信チャネル３０−１〜３０−３（以下、通信チャネル３０と総称する）を借り受け、それら複数の通信チャネル３０を用いて複数の顧客組織２０にサービスを提供する。もちろん、サービスシステム１０と顧客組織２０との間の通信経路全体を、運営事業者が借り受けた通信チャネル３０で賄う必要はなく、それら両者の間に別のネットワーク３５が介在してもよい。例えば、通信チャネル３０として携帯電話回線（例えば３Ｇネットワーク）を用い、サービスシステム１０と端末２２との間をインターネット経由で接続する場合、通信チャネル３０はサービスシステム１０・インターネット間及びインターネット・端末２２間の部分をカバーするのみであり、インターネット（ネットワーク３５の一例）部分はバックボーン等によりカバーされる。なお、運営事業者が契約する通信事業者は１つでなくてもよく、例えば、複数の通信事業者からそれぞれ１以上の通信チャネル３０を借り受け、サービスシステム１０のために利用してもよい。
【００２７】
通信チャネル３０は、無線及び有線のいずれであってもよい。サービスシステム１０は、無線の通信チャネル３０のみを用いるものであってもよいし、有線の通信チャネル３０のみを用いるものであってもよいし、無線と有線を併用するものであってもよい。また、通信チャネル３０は、帯域保証型でもベストエフォート型でもよい。サービスシステム１０の運営事業者は、契約している顧客組織２０群のために必要な通信路容量や通信路品質に応じて、個々の通信チャネル３０のコスト（レンタル費用等）も考慮しつつ、１以上の通信事業者から借り受ける通信チャネル３０を増減させる。例えば、顧客組織２０の増加により通信帯域不足が生じた場合には、通信事業者から新たな通信チャネル３０を借り受ける。
【００２８】
帯域保証型であれ、ベストエフォート型であれ、個々の通信チャネル３０には、通信路容量（帯域幅）がある。ベストエフォート型の場合、通信路容量はあくまで上限であり、常に保証されるわけではない。通信路容量は通信チャネル３０毎に異なっていてよい。
【００２９】
図１では通信チャネル３０を３つ示しているが、サービスシステム１０が利用する通信チャネル３０の数は３つに限らない。
【００３０】
顧客組織２０は、企業や団体などのように複数の個人を含んだ組織である。サービスシステム１０は、顧客組織２０に対してそれぞれ１以上の通信チャネル３０を割り当て、割り当てた通信チャネル３０を介して、その顧客組織２０内の各端末２２と通信し、サービスを提供する。サービスシステム１０が無線及び有線の通信チャネル３０を併用する場合、顧客組織２０は、無線のみ利用、有線のみ利用、無線と有線の併用のいずれかを選択する。
【００３１】
端末２２は、スマートフォン、タブレットＰＣ、携帯電話機等のような携帯情報端末、パーソナルコンピュータ、サーバ、デジタル複合機（コピー機、プリンタ、スキャナ、ファクシミリ等の機能を併せ持った多機能装置）等のように、情報処理機能とネットワークを介した通信機能を備えた装置であれば、どのようなものであってもよい。
【００３２】
本実施形態では、１つの通信チャネル３０に対して、１以上の顧客組織２０を割り当てる。サービスシステム１０は、サービス提供契約を結んだ複数の顧客組織２０との通信を、通信事業者から借り受けた複数の通信チャネル３０にて賄う。本実施形態の１つの側面では、サービスシステム１０が利用する（すなわちキャリアから借り受けている）複数の通信チャネル３０に対する複数の顧客組織２０の割り当ての最適化を目指す。このための管理を行うのが、通信管理システム１００である。
【００３３】
図２に、通信管理システム１００の内部構成の一例を示す。
【００３４】
図２において、トラフィックパターンＤＢ（データベース）１０２は、各顧客組織２０のトラフィックパターンのデータを記憶したデータベースである。ここでいう「顧客組織２０のトラフィックパターン」とは、その顧客組織２０がサービスシステム１０との間で行う通信のトラフィック量の、ある定められた期間（例えば１日、１週間、１ヶ月、１年等）の中での時間的な変化のパターンである。
【００３５】
トラフィックパターンは、トラフィックパターン計測部１１２により計測される。すなわち、トラフィックパターン計測部１１２は、各顧客組織２０がトラフィック制御部２００を介して行う通信のトラフィック量を計測し、その計測結果を統計的に処理することで、顧客組織２０毎の通信トラフィック量の時間変化の典型的なパターン、すなわちトラフィックパターンを求める。ある顧客組織２０について、例えば、１日２４時間での通信トラフィック量の変化パターンを何日間かにわたって計測し、それら何日分かの変化パターンを時間帯毎に平均することで、その顧客組織２０の１日のトラフィックパターンが求められる。１日のトラフィックパターンは、平日・休日別に求めてもよいし、曜日毎に求めてもよい。個人のトラフィックパターンは様々な要因により一定しないことが多いが、ある程度以上の人数が所属する企業等の顧客組織２０のトラフィックパターンは、個々人のランダム性が相殺され、ある程度安定したパターンとなる。顧客組織２０の規模が十分大きい場合、１日２４時間のトラフィックパターンは、ある時刻をピークとするガウス分布に近い形となると考えられる。
【００３６】
サービスシステム１０と顧客組織２０との間で有線と無線の両方の通信チャネル３０が用いられる場合には、その顧客組織２０のトラフィックパターンは、有線と無線のそれぞれについて求めるようにしてもよい。有線の通信チャネル３０は顧客組織２０のオフィス内のパーソナルコンピュータ等で用いられるのに対し、無線の通信チャネル３０はスマートフォン等の携帯情報端末を持ったユーザにより出先で使用されることが多く、互いに異なる特性を持つからである。
【００３７】
顧客組織２０のトラフィックパターンは、その顧客組織２０が遂行している業務の特性を反映したものとなる。例えば銀行のように客先回りが夕方に集中するような業務では、無線通信のトラフィックパターンは夕方にピークを示すことになる。業種毎に、トラフィックパターンに特有の傾向が存在する。
【００３８】
図３に、３つの顧客組織２０（顧客Ａ〜Ｃ）のトラフィックパターンを例示する。なお、これらトラフィックパターンはあくまで例示のための模式的なものであり、実際のトラフィックパターンはこのようなきれいな釣り鐘形になるとは限らない。
【００３９】
図３に示されるのは、１日２４時間の平均的なトラフィックパターンであり、横軸が０時〜２４時までの時刻を示し、縦軸がトラフィック量（すなわち顧客組織の使用する帯域幅）を示す。図３に例示した各顧客Ａ〜Ｃのトラフィックパターンは、それぞれトラフィック量のピーク時刻とパターンの広がり幅が異なっている。
【００４０】
図４に、トラフィックパターンＤＢ１０２に登録されているデータの一例を示す。この例では、顧客組織２０の識別情報（図では「顧客ＩＤ」と表記）に対応づけて、トラフィックパターンそのもの（生データ）と、そのトラフィックパターンの特徴ベクトルとが登録されている。
【００４１】
トラフィックパターンの特徴ベクトルは、トラフィックパターンの形状の特徴を表すベクトルである。例えば１日のトラフィックパターンの場合、トラフィック量のピーク時刻Ｔmaxと、ピークトラフィック量（ピーク帯域幅）Ｂmaxとを成分とするベクトル（Ｔmax，Ｂmax）を特徴ベクトルとしてもよい。また、そのベクトル（Ｔmax，Ｂmax）を極座標表示した場合の、そのベクトルの大きさｒと偏角θを成分とするベクトル（ｒ，θ）を特徴ベクトルとしてもよい。また、ピーク時刻、ピークトラフィック量、及び半値幅（トラフィック量がピークトラフィック量の半分になる時刻同士の時間幅）の３つの成分からなるベクトル、又はそれを極座標表示した場合のベクトルの大きさｒ及び２つの偏角θ及びφからなるベクトルを、特徴ベクトルとしてもよい。
【００４２】
特徴ベクトルとしてどのようなものを用いるかは、トラフィックパターン群の形状の複雑さなどに応じて定めてもよい。例えば、すべての顧客組織２０のトラフィックパターンがガウス分布形状で十分に近似できる場合は、上述したピーク時刻、ピークトラフィック量、及び半値幅の３つの成分からなる特徴ベクトルを用いればよい。もっと複雑な形状のトラフィックパターンを含む場合には、それら複雑な形状のトラフィックパターンも十分な制度で近似できるだけの数の成分からなる特徴ベクトルを用いればよい。なお、特徴ベクトルで、すべての顧客組織２０のトラフィックパターンに十分近いパターンを再現できる場合には、トラフィックパターンＤＢ１０２にトラフィックパターンの生データを登録する必要はない。
【００４３】
再び図２の説明に戻ると、サービスの提供対象に新たな顧客組織２０が追加される場合、管理者が顧客登録部１１４からその顧客組織２０の情報をシステムに登録する。これにより、トラフィックパターンＤＢ１０２にその顧客組織２０のエントリが作成される。この新規追加の時点では、その顧客組織２０のトラフィックパターンは不明なので、例えば、デフォルトとして用意されているトラフィックパターン（及び／又はその特徴ベクトル）をその顧客組織２０のトラフィックパターンとして仮に登録して用いてもよい。そして、後述するチャネル割り当ての際には、この新規顧客についてはこの仮登録したトラフィックパターンを用いて割当先の通信チャネル３０を判定するようにしてもよい。そして、割り当てた通信チャネル３０を用いてその新規顧客に対してサービスを提供している間に、トラフィックパターン計測部１１２がその新規顧客の実際のトラフィックパターンを計測してトラフィックパターンＤＢ１０２に登録し、登録したトラフィックパターンを用いて通信チャネル３０の割り当ての見直しを行ってもよい。
【００４４】
ここで、デフォルトのトラフィックパターンを複数種類用意しておき、インタビュー等により得た顧客組織２０の情報から、その顧客組織２０に合ったトラフィックパターンを選んで仮登録してもよい。また、業界毎にトラフィックパターンに特徴がある場合も少なくないので、デフォルトのトラフィックパターンを業界毎に用意しておき、新規顧客の属する業界を入力すると、その業界用のデフォルトトラフィックパターンが仮登録されるようにしてもよい。
【００４５】
チャネル特徴ＤＢ１０４は、サービスシステム１０が使用する各通信チャネル３０の特徴の情報を記憶するデータベースである。チャネル特徴ＤＢ１０４には、例えば、図５に示すように、個々の通信チャネル３０の識別情報（「チャネルＩＤ」）に対応づけて、その通信チャネルの種類を示すチャネルタイプと、その通信チャネルの帯域幅（通信路容量）を表す「チャネル帯域幅」とが登録される。チャネルタイプは、帯域保証型及びベストエフォート型のいずれであるかを示す情報である。また、サービスシステム１０が、無線と有線の通信チャネル３０を併用する場合、各通信チャネル３０が無線、有線のいずれであるかを示す情報もチャネル特徴ＤＢ１０４に登録する。
【００４６】
チャネル帯域幅には、帯域保証型の場合は、通信事業者から借り受けた当該通信チャネル３０の帯域幅そのものを登録すればよい。ベストエフォート型の場合は、当該通信チャネル３０のベストエフォートの上限の帯域幅を登録してもよいが、チャネル帯域測定部１１８により測定した当該通信チャネル３０の実効帯域幅（すなわち実効伝送速度）の時間的な変化のパターンを登録してもよい。
【００４７】
ここでいう通信チャネル３０の実効帯域幅とは、ベストエフォートの上限帯域幅から、サービスシステム１０以外の利用者（他の業者など）によるその通信チャネル３０の利用帯域を除いた残りの帯域幅のことであり、サービスシステム１０が利用できると期待できる帯域幅のことである。もちろん、この実効帯域幅は確実に保証されるものではないが、ある程度十分な量のサンプル計測を行って統計的に求めることで、ある程度高い信頼性が得られる。
【００４８】
例えば、サービスシステム１０の運営事業者が、通信事業者から新たにベストエフォート型の通信チャネル３０を借り受けた場合に、運営事業者内の管理者がチャネル登録・削除部１１６からその通信チャネル３０をチャネル特徴ＤＢ１０４に登録すると共に、チャネル帯域測定部１１８にその通信チャネル３０の実効帯域幅の時間的な変化パターンを測定させ、その測定結果をチャネル特徴ＤＢ１０４に登録させるようにしてもよい。
【００４９】
割当可能組合せ探索部１０９は、サービスシステム１０が利用する各通信チャネル３０に対して割り当て可能な顧客組織２０の組合せを探索する。基本的な考え方は、通信チャネル３０毎に、顧客組織２０の組合せのうち、組合せ内の各顧客組織のトラフィックパターンを合計した合計パターン（すなわち各トラフィックパターンが示す各時刻のトラフィック量を時刻毎に加算してできるトラフィックパターン）が、当該通信チャネル３０のチャネル帯域幅に収容可能な組合せを探索するというものである。ここでは、単一の顧客組織２０も「組合せ」として取り扱う。
【００５０】
例えば、図３に例示した顧客Ａ〜Ｃのトラフィックパターン（それぞれピークのトラフィック量は「１」）の組合せを考える。仮にこれら３つのトラフィックパターンのピーク時刻が一致しているとすると、図６の（ａ）に示すように、それら３つの合計パターンのピークのトラフィック量は「３」となり、（少なくともそのピーク時刻において）チャネル帯域幅が「３」以上である通信チャネル３０にしか収容できない。これに対して、図３の例では、３つのトラフィックパターンのピーク時刻は互いにずれており、これらを合計した合計パターンは、図６の（ｂ）に示すものとなる。この合計パターンのピーク値は「１．５」であり、（少なくともそのピークの時刻において）チャネル帯域幅が「１．５」以上である通信チャネル３０であれば収容できる。
【００５１】
顧客組織２０のトラフィックパターンも通信チャネル３０のチャネル帯域幅（特にベストエフォート型の場合）も共にある程度統計的なものであって厳密なものではないので、合計パターンが通信チャネル３０のチャネル帯域幅に「収容可能」という場合、合計パターンが「完全に」チャネル帯域幅内に収まる（すなわちパターンのどの時刻のトラフィック量も、チャネル帯域幅を超えない）ようにする必要はない。例えばチャネル帯域幅＋１０％を許容範囲とするなどのようにチャネル帯域幅に許容範囲を設け、合計パターンがその許容範囲を超えなければ「収容可能」と判断するようにしてもよい。
【００５２】
ベストエフォート型の通信チャネル３０の場合、合計パターンが、当該通信チャネル３０の実効帯域幅の時間的変化パターンに対して「収容可能」となる顧客組織２０の組合せを求めればよい。
【００５３】
サービスシステム１０が無線と有線の通信チャネル３０を併用する場合、割当可能組合せ探索部１０９は、無線の通信チャネル３０に割り当てる組合せは、各顧客組織２０の無線通信のトラフィックパターンから求め、有線の通信チャネル３０に割り当てる組合せは、各顧客組織２０の有線通信のトラフィックパターンから求める。
【００５４】
割当可能組合せ探索部１０９は、顧客組織２０をトラフィックパターンの類似度に基づいてクラスタリング（クラスタ分け）し、各通信チャネル３０に対して割当可能なクラスタの組合せを求めるようにしてもよい。クラスタリングは、例えば、各顧客組織２０のトラフィックパターンの特徴ベクトル同士の距離（特徴ベクトルの各成分を座標軸とする空間内での距離）に基づいて行えばよい。すなわち、特徴ベクトル同士が近い顧客組織２０をクラスタにまとめればよい。
【００５５】
例えば、シミュレーションにより様々な特徴ベクトルに対応するトラフィックパターンのサンプルを多数生成し、それらトラフィックパターンの様々な組合せが収容可能かどうかを通信チャネル３０毎に調べればよい。これにより、個々の通信チャネル３０に収容可能な「組合せ」を構成する個々のトラフィックパターンの特徴ベクトルの範囲が求められる。この範囲をクラスタとすればよい。シミュレーションにより発生したトラフィックパターンのサンプルを用いる代わりに、実際の顧客組織２０のトラフィックパターンをサンプルとして用いて、同様のクラスタリングを行ってもよい。このようにして、各クラスタの範囲と、各通信チャネル３０に割当可能なクラスタの組合せとが求められる。通信チャネル３０に割当可能なクラスタの組合せは、当該通信チャネル３０に割当可能な顧客組織２０の組合せを、それら各顧客組織２０の属するクラスタの組合せで表現したものである。なお、サービスシステム１０が無線と有線の通信チャネル３０を併用する場合、無線の通信チャネル３０については各顧客の無線通信のトラフィックパターンから、有線の通信チャネル３０について各顧客の有線通信のトラフィックパターンから、それら各チャネルに割当可能なクラスタの組合せを求めるようにすればよい。
【００５６】
例えば、図７には、ピーク帯域幅Ｂmaxとピーク時刻Ｔmaxを成分とする特徴ベクトルの特徴空間内に形成された４つのクラスタＣ１〜Ｃ４を例示している。また、図８には、その特徴ベクトルを極座標表現に変換したものである別の特徴ベクトル（ｒ，θ）の特徴空間内に形成された４つのクラスタＣ１〜Ｃ４を例示している。いずれの図においても、クラスタ内の個々の丸印が、各顧客組織２０（の特徴ベクトル）を示している。
【００５７】
図７及び図８の例ではクラスタ同士は互いに重複していないが、クラスタ同士が部分的に重複するようにクラスタ分けしてもよい。このようにクラスタが部分的に重複した例を図９に示す。図９の例では、クラスタＣ５は、クラスタＣ１，Ｃ２，Ｃ３，Ｃ４にそれぞれ部分的に重複している。クラスタ同士が部分的に重複している場合、クラスタ同士の重複部分に属する顧客組織２０（特徴ベクトル）は、それら重複するクラスタのすべてに属するものとして取り扱えばよい。
【００５８】
求められたクラスタ分けの情報は、パターンクラスタ情報ＤＢ１０６に登録される。図１０にパターンクラスタ情報ＤＢ１０６のデータ内容の一例を示す。この例では、パターンクラスタ情報ＤＢ１０６には、個々のクラスタの識別情報（「クラスタＩＤ」）に対応づけて、そのクラスタの範囲定義が登録されている。図１０の例は、極座標表示の特徴ベクトル（ｒ，θ）のクラスタ分けの例を示しており、クラスタの範囲定義として、その特徴ベクトルの特徴空間（ｒ，θ）における中心の座標と半径を用いている。すなわち、この例では、クラスタは中心と半径により規定される円の内部の領域である。なお、このような円形のクラスタはあくまで一例に過ぎず、クラスタの形状はどのようなものであってもよい。
【００５９】
なお、サービスシステム１０が無線と有線の通信チャネル３０を併用する場合、クラスタ分けは無線と有線のそれぞれについて求めるようにすればよい。
【００６０】
また、割当可能組合せ探索部１０９が求めた、各通信チャネル３０に割当可能なクラスタの組合せは、割当可能組合せＤＢ１０８に登録される。図１１に、割当可能組合せＤＢ１０８のデータ内容の一例を示す。この例では、割当可能組合せＤＢ１０８には、通信チャネル３０毎に、その通信チャネル３０の識別情報（「チャネルＩＤ」）に対応づけて、その通信チャネル３０に割当可能なクラスタの組合せが登録される。図１１の例では、例えば通信チャネル「Ｃｈ２」には、（１）クラスタＣ１に属する２つの顧客組織２０の組合せ、（２）クラスタＣ１に属する１つの顧客組織２０とクラスタＣ２に属する１つの顧客組織２０とクラスタＣ３に属する１つの顧客組織２０とからなる組合せ、（３）クラスタＣ１に属する１つの顧客組織２０とクラスタＣ３に属する２つの顧客組織２０とからなる組合せ、…が割当可能である。
【００６１】
ここで、図１１の例では、割当可能組合せＤＢ１０８には、各通信チャネル３０に割当可能なクラスタの組合せのうち、トラフィック量の観点で上限の組合せのみを登録している。すなわち、チャネルＣｈ１に対して組合せ「Ｃ１＋Ｃ２」を割当可能ということは、組合せ「Ｃ１」（すなわちＣ１に属する顧客１つのみ）や組合せ「Ｃ２」（すなわちＣ２に属する顧客１つのみ）も当然割当可能であるが、そのような、より小さい組合せは省略している。
【００６２】
なお、帯域保証の通信チャネル３０については、チャネル帯域幅（通信路容量）に応じて割当可能なクラスタの組合せが決まる。したがって、帯域保証の通信チャネル３０群については、割当可能組合せＤＢ１０８に、個々の通信チャネル３０について割当可能なクラスタの組合せをそれぞれ個別に登録する代わりに、チャネル帯域幅毎に、そのチャネル帯域幅に応じたクラスタの組合せを登録するようにしてもよい。
【００６３】
割当可能組合せ探索部１０９は、例えば通信事業者から新たに借り受けた通信チャネル３０をチャネル登録・削除部１１６によりチャネル特徴ＤＢ１０４に登録する際に、その新たな通信チャネル３０について、割当可能なクラスタの組合せを求め、割当可能組合せＤＢ１０８に登録するようにすればよい。
【００６４】
チャネル割当決定部１１０は、サービスシステム１０が利用する各通信チャネル３０に対して顧客組織２０の組合せを決定する。この組合せの決定は、トラフィックパターンＤＢ１０２、パターンクラスタ情報ＤＢ１０６及び割当可能組合せＤＢ１０８を参照して行う。
【００６５】
この組合せの決定処理では、まず、トラフィックパターンＤＢ１０２に登録された各顧客組織２０の特徴ベクトルから、パターンクラスタ情報ＤＢ１０６を参照することにより、それら各顧客組織２０が属するクラスタを特定する。例えば、顧客Ａの特徴ベクトルがクラスタＣ１の範囲内に属する場合、クラスタＣ１は顧客Ａの属するクラスタと判定される。１つの顧客が複数のクラスタに属する場合は、それら複数のクラスタがすべてその顧客の所属クラスタと判定される。このようにしてすべての顧客組織２０の所属クラスタが判定されると、割当可能組合せＤＢ１０８に記憶された各通信チャネル３０に割当可能なクラスタの組合せを満たし、且つすべての顧客組織２０が必ずいずれか１つの通信チャネルに割り当てられるよう、個々の通信チャネル３０に対して割り当てる顧客組織２０の組合せを求める。
【００６６】
例えば、サービスシステム１０が利用する通信チャネル３０がＣｈ１，Ｃｈ２の２つであり、クラスタＣ１に属する顧客Ａ及びＢとクラスタＣ２に属する顧客Ｃ及びＤ及びＥからなる５つの顧客組織が存在するという簡単な例で考えてみる。この例において、チャネルＣｈ１に割当可能な組合せが「Ｃ１＋Ｃ２」であり、チャネルＣｈ２に割当可能な組合せが「Ｃ１＋Ｃ１＋Ｃ２」と「Ｃ１＋Ｃ２＋Ｃ２」であるとする。この場合、チャネルＣｈ１には２×３＝６通りの顧客組合せが割当可能であり、チャネルＣｈ２には１×３＋２×３＝９通りの顧客組合せが割当可能となる。このうち、顧客Ａ〜Ｅを重複無く、且つ上記割当可能なクラスタの組合せを満たすようにチャネルＣｈ１及びＣｈ２に割り当てる組合せは、Ｃｈ１に対してＣ１から１つの顧客とＣ２から１つの顧客を選んだ組合せ（この組合せは６通りある）を割り当て、残ったＣ１の顧客１つとＣ２の顧客２つをＣｈ２に割り当てる組合せとするものだけであり、結局合計６通りである。この６通りのいずれかを採用すればよい。
【００６７】
チャネル割当決定部１１０は、このような方法で各通信チャネル３０に対して割り当てる顧客組織２０の組合せを決定する。ある通信チャネル３０に対して割り当てられた組合せに属する顧客組織２０のトラフィックパターンの合計パターンは、その通信チャネル３０に「収容可能」なものとなる。
【００６８】
このチャネル割当決定部１１０による割当の決定処理は、例えば、顧客登録部１１４により顧客組織２０が新規登録された場合に行う。１つの例では、既存の割当状況を完全にクリアし、その新規登録された顧客組織２０を含むすべての顧客組織２０を対象として上述の割り当て組合せの決定処理を行う。新規登録直後でその登録された顧客組織２０のトラフィックパターンが不明の場合は、デフォルトのトラフィックパターン（及びその特徴ベクトル）をその顧客組織２０の情報として仮登録し、この仮登録情報を用いて割り当て組合せの決定処理を行えばよい。また、その新規顧客に対するサービス提供開始後ある程度時間が経過し、その新規顧客の実際のトラフィックパターンが求められた後に、その実際のトラフィックパターンの特徴ベクトルを用いて、再度すべての顧客組織２０を対象に再度上述の割り当て組合せの決定処理を行うようにしてもよい。
【００６９】
なお、新たな顧客組織２０が追加されたとき、上述のように既存の割当状況を完全にクリアして再度一から割当を再計算する代わりに、一部の通信チャネル３０のみを割当の再計算の対象とし、残りの通信チャネル３０についての割当は従前のまま維持するようにしてもよい。例えば、割り当てられた顧客組織２０のトラフィックパターンの合計（上述した「合計パターン」）に対するチャネル帯域幅の余裕の大きいものから順に、予め定められた数又は予め定められた割合の通信チャネル３０を、割当の再計算の対象として選べばよい。
【００７０】
顧客組織２０の新規追加に伴う割当の再計算において、割当可能組合せＤＢ１０８に登録されたクラスタ組合せの範囲内でどのように顧客組合せを替えても、その新規顧客を含むすべての顧客組織２０をもれなくいずれかの通信チャネル３０に割り当てる顧客組合せが求められない場合、チャネル割当決定部１１０は、通信チャネル３０が不足している旨を管理者に報知する。この報知に従い、管理者は、通信事業者から新たな通信チャネル３０を借り受けてチャネル特徴ＤＢ１０４に登録し、この新たな通信チャネル３０に割当可能なクラスタの組合せを割当可能組合せ探索部１０９により求め、割当可能組合せＤＢ１０８に登録する。そして、例えば、この新たな通信チャネル３０に対して、新規追加された顧客組織２０を割り当てる。
【００７１】
このように、顧客組織２０の増加により既存の通信チャネル３０群で全顧客組織２０がまかなえなくなった場合に初めて通信チャネル３０を追加することで、通信チャネル３０の数が最小化され、ひいては通信チャネル３０のためのコストが過大となる可能性が低くなる。
【００７２】
また、サービスシステム１０のサービス対象となる顧客組織２０が削除された場合に、チャネル割当決定部１１０により、残った顧客組織２０群の通信チャネル３０群に対する割当を再計算してもよい。この再計算においては、例えば使用中の通信チャネル３０のうちどれかを使用せずに、残りの顧客組織２０群を収容できないかどうかを調べるようにしてもよい。この再計算により、１つの顧客組織２０も割り当てられない通信チャネル３０ができた場合、その通信チャネル３０を予備として確保したり、通信事業者にその通信チャネル３０を返却（契約解除）したりしてもよい。
【００７３】
また、トラフィックパターン計測部１１２が各顧客組織２０のトラフィックパターンを継続的に計測し、この計測結果に基づいてトラフィックパターンＤＢ１０２に登録された各顧客組織２０のトラフィックパターンを定期的に更新し、その定期的な更新に応じてチャネル割当決定部１１０が定期的に各顧客組織２０の通信チャネル３０群に対する割当を再計算してもよい。この定期的な再計算により、通信チャネル３０群が足りていないことや余っていることも分かり、足りていなければ通信チャネル３０を追加し、余っていれば通信チャネル３０を返却するなどの対処が可能となる。
【００７４】
チャネル割当決定部１１０が求めた各顧客組織２０の通信チャネル３０への割当結果は、チャネル割当ＤＢ１２０に登録される。図１２にチャネル割当ＤＢ１２０のデータ内容の一例を示す。この例では、チャネル割当ＤＢ１２０には、顧客組織２０の顧客ＩＤに対応づけて、その顧客組織２０の割当先の通信チャネル３０のＩＤが登録される。このチャネル割当ＤＢ１２０は、トラフィック制御部２００での基本的なチャネル選択処理に用いられる。
【００７５】
すなわち、トラフィック制御部２００は、例えば、サービスシステム１０からある顧客組織２０に属する端末２２宛の送信データを受け取った場合、その顧客組織２０に対応する通信チャネル３０をチャネル割当ＤＢ１２０から検索し、検索した通信チャネル３０を介してその端末２２宛にその送信データを送る。ただし、チャネル割当ＤＢ１２０に登録されたチャネル割当は、あくまでトラフィックパターンという比較的長期的なトラフィック量変化の傾向に基づくものであるので、顧客組織２０のトラフィックが突発的に増えると通信チャネル３０がオーバーフローしてしまう場合がある。そこで、本実施形態では、突発的なトラフィックの増加に対処する制御手段を用意している。これについては、後で図１４等を参照して詳しく説明する。
【００７６】
図２の説明に戻ると、チャネル割当決定部１１０は、各顧客組織２０の通信チャネル３０への割当結果に応じて、通信チャネル３０毎に、その通信チャネル３０に割り当てられた顧客組織２０のトラフィックパターンの合計パターンを求め、その合計パターンを合計パターンＤＢ１２２に登録する。図１３に、合計パターンＤＢ１２２のデータ内容の一例を示す。合計パターンＤＢ１２２に登録する合計パターンは、生のパターン（すなわち有る定められた期間におけるトラフィック量の時間変化の波形そのもの）であってもよいし、その生のパターンを再現できる特徴ベクトルであってもよい。この合計パターンＤＢ１２２は、前述した突発的なトラフィック増加に対応するための制御手段に利用される。
【００７７】
以下、図１４を参照して、トラフィック制御部２００の詳細について説明する。以下の例では、トラフィック制御部２００は、サービスシステム１０が顧客組織２０内の端末２２に対してデータを配信する場合の、通信チャネル３０群へのデータの送出の制御を行う場合を例にとる。
【００７８】
この例では、各顧客組織２０内の各ユーザは、サービスシステム１０に対してデータ配信の指示を行う。サービスシステム１０は、図１４に示すように、各ユーザからのデータ配信の指示を受け付ける配信指示受付部２５０を有する。ユーザからの配信指示には、できるだけ速やかに配信することを指示する即時型のものと、配信時刻を指定する予約型のものとがあってよい。予約型の配信指示については、スケジュール管理アプリケーションやグループウェアと連動させてもよい。例えば、サービスシステム１０がスケジュール管理アプリケーション等のサービスを顧客組織２０に提供している場合、そのスケジュール管理アプリ等が、ユーザから登録されたスケジュール（例えば「○○時○○分〜××時××分までの会議」など）に対応づけて、そのスケジュールにおいて使用する文書等のデータの指定を受け付け、そのスケジュールの予定時刻にその指定されたデータを配信する旨の配信指示（言い換えれば配信予約）を配信指示受付部２５０に行う等である。
【００７９】
配信対象のデータは、例えば配信ＤＢ２６０に保持される。例えば、サービスシステム１０が提供するオンラインストレージサービスやオンライン文書作成・保存サービスのデータベースが、配信ＤＢ２６０の一例である。この例では、スケジュール管理アプリ等は、登録されるスケジュールに対応する配信対象データの入力画面を提供し、その入力画面にて、オンラインストレージサービス等に保存されたデータの一覧を呼び出し、その一覧から配信対象データを受け付けるようにしてもよい。配信ＤＢ２６０は１つに限られるものではなく、例えばサービスシステム１０が提供するサービス毎のデータベースをそれぞれ配信ＤＢ２６０としてもよい。
【００８０】
即時型及び予約型のいずれの場合も、配信指示（或いは配信対象データ）に対して「重要度」又は「優先度」（以下「重要度」と総称する）を指定できるようにしてもよい。重要度が高いほど、ユーザが指定した配信時刻が守られやすい（すなわち、即時型の場合は配信指示の受付時点から、予約型の場合は予約された時刻からの、実際に配信される時刻までの時間差が少ない）。配信指示に対する重要度は、例えばユーザが指定できるようにしてもよいし、顧客組織２０毎に固定値をあらかじめ定めておいてもよい。後者は、例えば顧客組織２０毎に契約で重要度（又は指定した配信時刻に対して許容する遅延時間）を定めるなどの形で行えばよい。この場合、選択可能な重要度の範囲を顧客組織２０毎に契約で定めておき、ユーザは個々の配信指示毎にその範囲内で希望する重要度を選択できるようにしてもよい。
【００８１】
配信指示が即時型か予約型かは、例えば、配信指示の入力先のサービスに応じて自動的に決定される。例えば、スケジュール管理アプリに登録する予定に対して関連づけられる配信指示は予約型であり、データ転送サービスに対して行われる配信指示は即時型である。
【００８２】
配信指示の際、ユーザは、前述した配信対象データや配信時刻の指定の他に、配信データの宛先が指示できるようにしてもよい。宛先は、例えば、ユーザ自身の携帯端末、ユーザが所属する顧客組織２０内のサーバやデジタル複合機等であり、配信指示の際これら宛先の候補の中からユーザが選択できるようにしてもよい。なお、宛先がユーザの携帯端末に固定されるような場合のように、配信指示を行ったユーザが特定されれば自動的に宛先の決まるサービス態様も考えられる。
【００８３】
配信指示受付部２５０が受け付けた配信指示の情報は、配信スケジュール記憶部２５２に記憶される。図１５に配信スケジュール記憶部２５２に記憶されるデータ内容の一例を示す。この例では、配信指示の識別情報（指示ＩＤ）毎に、その配信指示を発したユーザの所属する顧客組織２０のＩＤ（顧客ＩＤ）、そのユーザのユーザＩＤ、宛先（配信先）のアドレス情報、配信対象データの識別情報（配信データＩＤ。配信データの本体は配信ＤＢ２６０内に存在）、配信指定時刻、配信保証時刻が登録されている。配信指定時刻は、即時型の配信指示の場合はその配信指示の受付時刻であり、予約型の配信時刻の場合は予約された時刻（例えばスケジュール管理アプリ等に登録されたスケジュールの開始時刻）である。配信保証時刻は、この時刻までに配信対象データが配信されるように保証する時刻である。配信保証時刻は、配信指定時刻と重要度から決定する。例えば、指定された重要度から、許容される遅延時間を決定し、その許容遅延時間を配信指定時刻に加算することで、配信保証時刻を求める。重要度と許容遅延時間との関係は、サービスシステム１０にあらかじめ設定されている。
【００８４】
図１４に示すトラフィック制御部２００は、配信部２０２、各通信チャネル３０にそれぞれ対応するキュー２０４、及びトラフィック・シェーパー・スイッチャー（「ＴＳＳ」と略す）２０６を備える。
【００８５】
配信部２０２は、配信スケジュール記憶部２５２の中から、配信指定時刻の到来した配信指示を求め、求めた配信指示における配信対象データを配信ＤＢ２６０から取得して、対応する通信チャネル３０のキュー２０４に挿入（エンキュー）する。このとき、「対応する通信チャネル３０」は、その取り出した配信指示の情報から顧客ＩＤを認識し、その顧客ＩＤに割り当てられた通信チャネル３０をチャネル割当ＤＢ１２０から検索することで特定する。また、「配信指定時刻が到来した」時点とは、より厳密には、その配信指定時刻を、キュー２０４による遅延やインターネット等のネットワークを経由した送信による遅延等を考慮した時間だけ前倒しした時刻、が到来した時点を意味する。配信部２０２は、例えば、配信対象データをパケット単位に分割し、各パケットのヘッダに宛先の情報や配信保証時刻の情報を埋め込んだ上で、キュー２０４に挿入する。
【００８６】
キュー２０４は、複数の配信対象データを先入れ先出し方式で保持するバッファである。すなわち、キュー２０４に入れられた配信対象データは、先入れ先出し順に、対応する通信チャネル３０へと送出されることになる。配信対象データがキュー２０４に入れられて（エンキューされて）から、対応する通信チャネル３０に送出（デキュー）されるまでには、ある程度の時間がかかる（すなわち遅延が生じる）。この遅延時間内に、ＴＳＳ２０６が、キュー２０４に対応する通信チャネル３０がオーバーフローしないよう、以下に示すようにして、キュー２０４内の配信対象データ（パケット）を調整する。
【００８７】
ＴＳＳ２０６は、各通信チャネル３０に対応する各キュー２０４を監視し、それら通信チャネル３０のオーバーフローを防止するための制御を行う。この制御は、トラフィックシェーピングと、チッピング・スイッチング（chipping & switching）の２段階からなる。
【００８８】
トラフィックシェーピングは、キュー２０４内の配信対象データ（パケット）を遅延（後の時間へのシフト）させることで、対応する通信チャネル３０の帯域幅を超えないようにする制御である。トラフィックシェーピングは、パケットシフトと呼んでもよい。遅延の上限は配信保証時刻である。すなわち、この制御では、個々の配信対象データは、対応する配信保証時刻以降には遅延されない。
【００８９】
トラフィックシェーピングのみでは通信チャネル３０をオーバーフロー（すなわちトラフィック量が通信チャネル３０のチャネル帯域幅を超過）してしまう場合には、チッピング・スイッチング制御を行う。この制御は、キュー２０４内のパケットのうち、対応する通信チャネル３０のチャネル帯域幅を超過するものを切り取り（チッピング）、その切り取ったパケット群を空きのある別の通信チャネル３０経由に切り替える（スイッチング）制御である。
【００９０】
１つの例として、図１４の構成では、スイッチング先の通信チャネル３０として、割り当てられた顧客組織２０のトラフィックパターンの合計（＝合計パターン）に対するチャネル帯域幅の余裕が大きいものを選択する。すなわち、他の各通信チャネル３０毎に、当該通信チャネル３０のチャネル帯域幅をチャネル特徴ＤＢ１０４から、合計パターンを合計パターンＤＢ１２２からそれぞれ取得し、取得した合計パターンから現在の時刻のトラフィック量を求め、その現在時刻のトラフィック量をチャネル帯域幅から減算する。この減算結果が、当該通信チャネル３０の空き帯域幅である。例えばこの空き帯域幅（空き容量）が大きい通信チャネル３０から順に、チッピングしたパケット群のトラフィック量を収容できる空き容量が確保できるだけの数の通信チャネル３０を選択する。そして、選択した通信チャネル３０に対応するキュー２０４に、チッピングしたパケットを挿入する。
【００９１】
また、別の例として、ＣＴに空きのある別の通信チャネル３０を探し、見つかった通信チャネル３０のキュー２０４のＣＴに対して、チッピングしたパケット群を挿入する。空き通信チャネル３０が１つだけではチッピングしたパケット群の総トラフィック量をまかなえない場合は、チッピングしたパケット群を複数の空き通信チャネル３０のＣＴに分散してもよい。ＴＳＳ２０６は、すべての通信チャネル３０のキュー２０４を監視しているので、このような制御が可能である。
【００９２】
また、更に別の例として、通信チャネル３０からオーバーフローしたパケット群のスイッチ先とする通信チャネル３０を用意しておく方式も考えられる。この方式では、スイッチ先とする通信チャネル３０には、割り当てる顧客組織２０の数を少なくするなどにより、帯域に余裕を持たせておく。
【００９３】
ＴＳＳ２０６の処理手順の一例を図１６及び図１７に示す。図１６は主としてトラフィックシェーピングの手順を示し、図１７は主としてチッピング・スイッチングの手順を示す。図１６及び図１７の手順は、１つのキュー２０４（すなわち１つの通信チャネル３０）についてのものであり、ＴＳＳ２０６はこの手順を各キュー２０４についてそれぞれ実行する。
【００９４】
この手順の前提として、キュー２０４には、図１８に示すようにタイムスロットが規定されており、同一タイムスロット内のパケットは、同一時刻に通信チャネル３０へと送出されるものとする。図１８の左側には、上から順に、１つの通信チャネル３０に割り当てられた２つの顧客Ａ及びＢのトラフィック量の時間的な推移と、それら両者を併せた合計のトラフィック量の時間的な推移が示されている。図において、タイムスロット内の色つきの正方形が個々のパケットを示し、パケット内の数字は、そのパケットの配信保証時刻を示している。例えば、パケット内の数字が「１」の場合、そのパケットの配信保証時刻は、図中の時刻ｔ１である。顧客ＡとＢのトラフィックの合計は、図１８の左側の最下部に示すように、通信チャネル３０のチャネル帯域幅を超過している。
【００９５】
図１６の手順（トラフィックシェーピング）では、ＴＳＳ２０６は、対象とするキュー２０４内のタイムスロットを早い時刻のものから順に処理していき、キュー２０４内のすべてのタイムスロットを処理し終わるまで処理を繰り返す。
【００９６】
まず、ＴＳＳ２０６は、未処理の次のタイムスロット（ＮＴ：Next Time slot）が有るかどうかを判定し（Ｓ１０）、あれば、そのＮＴを現タイムスロット（ＣＴ：Current Time slot）にセットする（Ｓ１２）。次に、ＣＴ内の合計トラフィック量（すなわち顧客ＡとＢのパケットの合計量）が通信チャネル３０のチャネル帯域幅（容量）を超過するかどうかを判定する（Ｓ１４）。超過しない場合は、Ｓ１０に戻って、更に次のタイムスロットを調べる。
【００９７】
なお、通信チャネル３０がベストエフォート型の場合、Ｓ１４での判定の基準となるチャネル帯域幅として、チャネル特徴ＤＢ１０４に登録されている当該通信チャネル３０のチャネル帯域幅の時間的変化パターンにおいて、ＣＴの時刻に対応するチャネル帯域幅の値を用いてもよい。
【００９８】
Ｓ１４で「超過する」と判定した場合、ＴＳＳ２０６は、ＣＴ内にある未処理のパケットを１つ取り出し（Ｓ１６）、取り出したパケットの配信保証時刻が現在時刻（ＣＴ）以前であるかどうかを判定する（Ｓ１８）。この判定の結果が否定（Ｎｏ）、すなわちそのパケットの配信保証時刻がＣＴより後であれば、そのパケットを次のタイムスロットへとシフトする（Ｓ２０）。これにより、ＣＴの合計トラフィック量が１パケット分減る。この１パケット分減ったＣＴの合計トラフィック量がまだチャネル帯域幅を超えているか否かを判定し（Ｓ２２）、超えていなければ（判定結果＝Ｎｏ）、Ｓ１０に戻って次のタイムスロットの処理に移る。まだ超えていれば（判定結果＝Ｙｅｓ）、Ｓ２４に進む。
【００９９】
一方、Ｓ１８の判定結果が肯定（Ｙｅｓ）、すなわちそのパケットの配信保証時刻が現在時刻以前であれば、そのパケットはＣＴに残したままとし、Ｓ２４に進む。
【０１００】
Ｓ２４では、ＴＳＳ２０６は、ＣＴ内のすべてのパケットについてＳ１８のチェック（及び必要に応じてＳ２０及びＳ２２の処理）が終わったかどうかを確認し、終わっていなければＳ１６に戻り、ＣＴから次の未処理のパケットを取り出し、Ｓ１８以降の処理を繰り返す。
【０１０１】
図１８の例では、パケットシフト（トラフィックシェーピング）前にはチャネル帯域幅を超える時刻のあったトラフィックが、Ｓ１６からＳ２４の処理の繰り返しにより、チャネル帯域幅を超える時刻がない形へと整形されている。
【０１０２】
しかし、パケットシフトだけでは通信チャネル３０のオーバーフローが解消されない場合もある。この場合、第２段階のチッピング・スイッチング処理を行うことになる。
【０１０３】
すなわち、Ｓ２４の判定結果がＹｅｓ（すなわち、ＣＴ内の全パケットについてＳ１８の判定完了）となった場合、その時点でＣＴ内にある残りのトラフィック量はチャネル帯域幅を超過している。この場合、図１７の処理に進む。
【０１０４】
図１７の手順では、ＴＳＳ２０６は、ＣＴ（現タイムスロット）内に残っているパケットのうち、対応する通信チャネル３０のチャネル帯域幅を超過する分を、ＣＴから削除する（チッピング）対象として選択する（Ｓ２６）。また、ＴＳＳ２０６は、チッピング対象のパケット群を振り向け先、すなわちスイッチ先の空き通信チャネルを探す（Ｓ２８）。
【０１０５】
１つの例では、Ｓ２８では、他の各通信チャネル３０のうち、空き容量（＝「（チャネル帯域幅）−（合計パターンにおけるＣＴの時刻でのトラフィック量）」）が、チッピング対象のパケット群の総トラフィック量より大きい通信チャネル３０をスイッチ先として選択する。空き容量がチッピングしたパケット群の総トラフィック量より大きい通信チャネル３０が無い場合は、空き容量の合計がその総トラフィック量以上である複数の通信チャネルをスイッチ先として選択する。
【０１０６】
別の例では、Ｓ２８では、他の各通信チャネル３０について、当該通信チャネル３０のチャネル帯域幅と、当該通信チャネル３０に対応するキュー２０４のＣＴ内のトラフィック量とから、ＣＴの空き容量を求める。そして、ＣＴの空き容量の合計が、Ｓ２６でチッピング対象としたパケット群の総トラフィック量以上となる通信チャネル３０の組合せ（１つの通信チャネル３０だけでまかなえるのであれば、１つでもよい）を、スイッチ先の空きチャネルとして選択する。
【０１０７】
そして、Ｓ２６でチッピング対象としたパケット群をＣＴから削除し（チッピング）、それらチッピングしたパケット群を、Ｓ２８で選択した１以上の通信チャネル３０に対して、それら各通信チャネル３０（又はＣＴ）の空き容量に応じた量ずつスイッチする（Ｓ３０）。これにより、ＣＴに残るトラフィック量はチャネル帯域幅以下となるので、対応する通信チャネル３０をオーバーフローしなくなる。
【０１０８】
なお、Ｓ２６でチッピング対象に選択したパケット群の総トラフィック量を引き受けることができる他の通信チャネル３０の組合せがＳ２８で見つからなかった場合、図１７の手順では、チッピング対象に選択したパケット群のチッピング及びスイッチングは行わず、元のＣＴに残す。この場合、ＣＴに残った超過分のパケットの取扱は、通信チャネル３０側の取扱に任される。また、別の例として、チッピング対象のパケット群の総トラフィック量を引き受けることができる他の通信チャネル３０の組合せがＳ２８で見つからなかった場合、チッピング対象に選択したパケット群をＣＴから削除（パケットドロップ）するようにしてもよい。
【０１０９】
以上の例では、チッピング対象のパケット群の総トラフィック量を引き受けることができる他の通信チャネル３０の組合せがＳ２８で見つからなかった場合に、超過分のパケットのスイッチングをまったく行わないが、これは一例に過ぎない。この代わりに、空き容量のある通信チャネル３０に対して、超過分のうちその空き容量に応じた量のパケットをスイッチし、スイッチしきれずに残ったパケットのみ、元のＣＴに残したり、ドロップしたりするようにしてもよい。
【０１１０】
Ｓ３０により、ＣＴについての処理が完了する。その後、ＴＳＳ２０６はＳ１０に戻り、次のタイムスロットの処理に移行する。
【０１１１】
なお、以上に説明した手順はあくまで一例に過ぎない。変形例として、図１６のＳ１６において、ＣＴ内のパケットのうち、配信保証時刻が最も遅いものを取り出すようにしてもよい。このようにすれば、配信保証時刻が遅いパケットから順に配信が後回しにされることになり、全体として配信保証時刻が早い順に配信されるようになる。この場合、Ｓ２４の判定は、「ＣＴ内に配信保証時刻がＣＴより後のパケットがなくなった」か否かを判定するものとすればよい。
【０１１２】
以上では、本実施形態のトラフィック制御を、ユーザの配信指示に係るデータの配信処理に適用するケースを例示した。しかし、本実施形態のトラフィック制御の適用先はこのような場合に限らない。例えば、マシン間通信（いわゆるＭ２Ｍ：Machine to Machine）におけるサービスシステム１０から端末２２へのデータ配信にも、本実施形態の制御は適用可能である。
【０１１３】
以上に例示した通信管理システム１００及びトラフィック制御部２００は、例えば、汎用のコンピュータに上述の各機能モジュールの処理を表すプログラムを実行させることにより実現してもよい。ここで、コンピュータは、例えば、ハードウエアとして、ＣＰＵ等のマイクロプロセッサ、ランダムアクセスメモリ（ＲＡＭ）およびリードオンリメモリ（ＲＯＭ）等のメモリ（一次記憶）、ＨＤＤ（ハードディスクドライブ）を制御するＨＤＤコントローラ、各種Ｉ／Ｏ（入出力）インタフェース、ローカルエリアネットワークなどのネットワークとの接続のための制御を行うネットワークインタフェース等が、たとえばバスを介して接続された回路構成を有する。また、そのバスに対し、例えばＩ／Ｏインタフェース経由で、ＣＤやＤＶＤなどの可搬型ディスク記録媒体に対する読み取り及び／又は書き込みのためのディスクドライブ、フラッシュメモリなどの各種規格の可搬型の不揮発性記録媒体に対する読み取り及び／又は書き込みのためのメモリリーダライタ、などが接続されてもよい。上に例示した各機能モジュールの処理内容が記述されたプログラムがＣＤやＤＶＤ等の記録媒体を経由して、又はネットワーク等の通信手段経由で、ハードディスクドライブ等の固定記憶装置に保存され、コンピュータにインストールされる。固定記憶装置に記憶されたプログラムがＲＡＭに読み出されＣＰＵ等のマイクロプロセッサにより実行されることにより、上に例示した機能モジュール群が実現される。
【０１１４】
なお、以上に例示した通信管理システム１００又はトラフィック制御部２００の機能モジュール群を、ネットワークを介して相互に通信可能な複数のコンピュータに分散して実装し、それら分散された機能モジュール群がネットワークを介して相互に通信することで、上述した通信管理システム１００又はトラフィック制御部２００の機能を実現するようにしてもよい。
【０１１５】
また、通信管理システム１００又はトラフィック制御部２００の機能モジュール群のうちの一部又は全部を、専用ＬＳＩ(Large Scale Integration)、ＡＳＩＣ（Application Specific Integrated Circuit、特定用途向け集積回路）又はＦＰＧＡ（Field Programmable Gate Array）、或いはディスクリート回路要素等のハードウエア回路として構成してもよい。
【符号の説明】
【０１１６】
１０  サービスシステム、２０  顧客組織、２２  端末、３０  通信チャネル、１００  通信管理システム、１０２  トラフィックパターンＤＢ（データベース）、１０４  チャネル特徴ＤＢ、１０６  パターンクラスタ情報ＤＢ、１０８  割当可能組合せＤＢ、１０９  割当可能組合せ探索部、１１０  チャネル割当決定部、１１２  トラフィックパターン計測部、１１４  顧客登録部、１１６  チャネル登録・削除部、１１８  チャネル帯域測定部、１２０  チャネル割当ＤＢ、１２２  合計パターンＤＢ、２００  トラフィック制御部、２０２  配信部、２０４  キュー、２０６  トラフィック・シェーパー・スイッチャー、２５０  配信指示受付部、２５２  配信スケジュール記憶部、２６０  配信ＤＢ。
【図１】
0005949115.tif 000002
【図２】
0005949115.tif 000003
【図３】
0005949115.tif 000004
【図４】
0005949115.tif 000005
【図５】
0005949115.tif 000006
【図６】
0005949115.tif 000007
【図７】
0005949115.tif 000008
【図８】
0005949115.tif 000009
【図９】
0005949115.tif 000010
【図１０】
0005949115.tif 000011
【図１１】
0005949115.tif 000012
【図１２】
0005949115.tif 000013
【図１３】
0005949115.tif 000014
【図１４】
0005949115.tif 000015
【図１５】
0005949115.tif 000016
【図１６】
0005949115.tif 000017
【図１７】
0005949115.tif 000018
【図１８】
0005949115.tif 000019