JP4681507B2 - 要求解釈方法、および、要求解釈装置 - Google Patents

Description

本発明は、要求解釈方法、および、要求解釈装置に関する。

これまでの技術では、ＧＭＰＬＳ（非特許文献１）やＭＰＬＳ（非特許文献２）などのパスを計算するにはネットワークトポロジ・ネットワーク・リソースなどのネットワークに関する情報やユーザプログラムが利用する明確な通信時間、通信帯域を指定して計算を実施していた。
ＩＥＴＦ、"Generalized Multi-Protocol Label Switching (GMPLS) Architecture"、[online]、［平成１８年５月２３日検索］、インターネット＜ＵＲＬ：http://www.ietf.org/rfc/rfc3945.txt＞ ＩＥＴＦ、"Multiprotocol Label Switching Architecture"、[online]、［平成１８年５月２３日検索］、インターネット＜ＵＲＬ：http://www.ietf.org/rfc/rfc3031.txt＞

これまでの経路計算アルゴリズムでは、ＯＳＰＦなどのルーティングプロトコルで定義されたリンクコストをメトリックとして最短経路を計算するものや、残余帯域が一定以上のリンクを用いて前記リンクコストを利用し最短経路を計算するものがあった。

しかしながら、これらのパス計算方法はユーザプログラムからの要求に即したものではない。ネットワークが混雑した時間に通信要求を行うことにより、利用コストの増大や要求の受付ができないといった問題がある。

そこで、本発明は、前記した問題を解決し、ユーザプログラムからの要求に即した経路を計算することを主な目的とする。

前記課題を解決するために、本発明は、通信網上に設定されるユーザ端末間の通信を通信制御するために、前記通信制御の対象となる通信に関する通信開始時刻、通信終了時刻、および、通信必要帯域を示した制御条件から、前記通信網に関するネットワークトポロジ、ネットワークリソース、および、前記制御条件をもとに作成される抽出条件を満たす通信制御情報をもとに、前記制御条件を満たすサービス案を作成する要求解釈方法であって、コンピュータが、（手順１）から（手順５）までを実行することにより、経路計算をＫ回（Ｋは、１以上の整数）繰り返すことで、前記サービス案を作成することを特徴とする要求解釈方法。
（手順１）Ｋ＝１とし、前記通信開始時刻から通信終了時刻までを計算対象時間帯とする
（手順２）前記ネットワークリソースの情報を用いて、前記計算対象時間帯における前記ネットワークトポロジを構成する各リンクのメトリックを求め、ルーティングプロトコルのコストとして前記求めたメトリックを設定する
（手順３）Ｋ−ＴＨ ＳＨＯＲＴＥＳＴ ＰＡＴＨを求めるアルゴリズムを用いて、前記計算対象時間帯における前記ネットワークトポロジ上の経路のうち、前記（手順２）で設定したメトリックがＫ番目に最小になる経路を求める
（手順４）前記計算対象時間帯に含まれる部分時間帯ごとに順に選択し、前記選択した部分時間帯における前記（手順３）で求めた経路を構成する各リンクの残余帯域を前記ネットワークリソースの情報から取得し、前記取得した残余帯域のうちの最小の残余帯域を求め、前記求めた最小の残余帯域が前記通信必要帯域以上のときには、前記選択した部分時間帯における経路を前記（手順３）で求めた経路として採用する
（手順５）前記計算対象時間帯に含まれる部分時間帯のうち、すべての部分時間帯において、前記（手順４）で採用された経路が存在するときには、前記（手順４）で採用された結果である部分時間帯ごとの経路を前記サービス案として作成して処理を終了するとともに、前記計算対象時間帯に含まれる部分時間帯のうち、前記（手順４）で採用された経路が存在しない部分時間帯が存在するときには、前記（手順４）で採用された経路が存在しない部分時間帯を次回の前記計算対象時間帯とし、前記Ｋに１を加算し、前記（手順２）に戻る

これにより、クライアントのユーザプログラムから受信した転送データ量、通信品質の要求レベルなどのパラメータから、最適なサービス品質を求めることができる。

本発明は、前記（手順２）において、残余帯域に由来する値をメトリックとして設定することを特徴とする。

これにより、クライアントのユーザプログラムから受信した転送データ量、通信品質の要求レベルなどのパラメータから、最適なサービス品質を求めることができる。

本発明は、前記（手順２）において、途中のネットワーク装置による転送遅延または各リンクで発生する伝搬遅延に由来する値をメトリックとして設定することを特徴とする。

これにより、クライアントのユーザプログラムから受信した転送データ量、通信品質の要求レベルなどのパラメータから、最適なサービス品質を求めることができる。

本発明は、前記（手順２）において、ネットワーク装置間の距離に由来する値をメトリックとして設定することを特徴とする。

これにより、クライアントのユーザプログラムから受信した転送データ量、通信品質の要求レベルなどのパラメータから、最適なサービス品質を求めることができる。

また、本発明は、前記要求解釈方法を実行する要求解釈装置である。

本発明は、クライアントのユーザプログラムから受信した転送データ量、通信品質の要求レベルなどのパラメータから、最適なサービス品質を求めることを特徴とする。この本発明により、制御条件に従って、ユーザやユーザプログラムでは利用できない情報を用いて、帯域や通信時間などを決定することが可能である。

つまり、ユーザプログラムからの要求条件を考慮して経路計算を行う際に、ユーザプログラムの通信特性やネットワークトポロジ・ネットワークリソース・通信制御情報を利用して経路計算を行うことで、前記の問題を解決する。

以下に、本発明が適用される通信システムの一実施形態について、図面を参照して詳細に説明する。

図１は、通信システム全体を示す構成図である。通信システムは、ユーザプログラムからの通信開始時刻、通信終了時刻、および、通信帯域に関して複数のパターンを作成することが可能な所定の範囲を示した制御要求（例えば、適用範囲もしくはサービスレベルが提示された要求）に対してパス提供を実行することを特徴とする。

基幹網１（請求項における通信網）は、広帯域なリンクで構成されるＩＰ（Internet Protocol）ネットワークである。基幹網１は、例えば、光クロスコネクト（ＯＸＣ：Optical cross Connect）（図示せず）などの基幹網装置とノード３で構成される。基幹網全体の状態は、例えば、ＯＳＰＦ−ＴＥ（Open Shortest Path First-Traffic Engineering）等により管理されている。

なお、基幹網１は、共有網上のベストエフォートによる通信と個別の品質保証による通信の両方が可能なネットワークとして構成されていてもよい。なお、制御を行う対象となるネットワークは、基幹網１だけではなく、基幹網１のリソースの一部から構成される仮想的なネットワークでもよい。

周辺網２（２ａ，２ｂ）は、ユーザ端末４を直接接続するネットワークであり、エッジルータとなるノード３によって基幹網１と接続する。周辺網２は、たとえばイーサネット（登録商標）のようなＬＡＮ（Local Area Network）を利用して構成されていて、周辺網２の各通信装置がＬＡＮのネットワークケーブル（図示せず）とネットワークハブ（図示せず）やルータ（図示せず）などの中継機器を介して、相互にＩＰによる通信が可能となっている。

ノード３（３ａ，３ｂ）は、ＩＰによる基幹網１の通信装置であるが、ＩＰの代わりに一般的なネットワークによる通信装置としてもよい。ノード３は、Ｄｉｆｆｓｅｒｖによる転送順位制御や、ＭＰＬＳやＧＭＰＬＳ等の通信制御技術を用いた品質制御が可能である。

ユーザ端末４（４ａ，４ｂ）は、ユーザプログラム処理部１０が１つ以上のユーザプログラムを実行する。

ユーザプログラム処理部１０は、ユーザプログラムを実行することにより、相互にユーザプログラムのデータを通信する。

通信制御装置５は、ノード３間でＤｉｆｆｓｅｒｖの転送順位制御や、ＭＰＬＳやＧＭＰＬＳのパスを設定することで、ユーザプログラム処理部１０間の通信を制御する。なお、通信制御装置５およびノード３は、演算処理を行う際に用いられる記憶手段としてのメモリと、前記演算処理を行う演算処理装置とを少なくとも備えるコンピュータとして構成される。なお、メモリはＲＡＭ（Random Access Memory）などにより構成される。演算処理はＣＰＵ（Central Processing Unit）によって構成される演算処理装置が、メモリ上のプログラムを実行することで実現される。

通信制御装置５は、制御要求受付部２０、制御要求処理部３０、ネットワークトポロジ管理部４１、ネットワークリソース管理部４２、制御情報管理部５０、および、通信制御指示部６０を有する。構成の詳細および構成間の信号の詳細は、後記するフローチャートの説明にて明らかにする。

ネットワークトポロジ管理部４１は、基幹網１について、ネットワークトポロジ（ネットワークの形状）を記憶手段に管理する。また、基幹網１に加えて周辺網２のネットワークトポロジを管理していてもよいし、周辺網２のネットワークトポロジだけでもよい。ただし、基幹網１と周辺網２を通信制御の対象とする場合は、ネットワークトポロジ管理部４１は、基幹網１と周辺網２のネットワークトポロジを記憶手段に管理することとする。また、周辺網２のみを通信制御の対象とする場合は、少なくとも周辺網２のネットワークトポロジを記憶手段に管理することとする。

ネットワークリソース管理部４２は、基幹網１について、ノード間のリンクについての帯域、距離、または、伝播遅延などのネットワークリソースを記憶手段に管理する。また、基幹網１に加えて周辺網２のネットワークリソースを管理していてもよいし、周辺網２のネットワークリソースだけでもよい。ただし、基幹網１と周辺網２を通信制御の対象とする場合は、ネットワークリソース管理部４２は、基幹網１と周辺網２のネットワークリソースを記憶手段に管理することとする。また、周辺網２のみを通信制御の対象とする場合は、少なくとも周辺網２のネットワークリソースを記憶手段に管理することとする。

なお、基幹網１に関するネットワークトポロジおよびネットワークリソースは、ノード３であるルータによって分散的に管理されるか、もしくはノード３でないサーバにより集中的もしくは分散的に管理されてもよい。また、ルータがネットワークトポロジ、サーバがネットワークリソースを管理するなど両者が併用されてもよい。例えば、ＯＳＰＦ−ＴＥを用いた場合は、ネットワークトポロジとネットワークリソースの両方が管理可能になる。

さらに、周辺網２に関するネットワークトポロジおよびネットワークリソースは、ノード３または周辺網２の内部に設置されたルータ、もしくはその両方によって分散的に管理されるか、それ以外のサーバにより集中的もしくは分散的に管理されてもよい。また、ルータがネットワークトポロジ、サーバがネットワークリソースを管理するなど両者が併用されてもよい。例えば、ＯＳＰＦ−ＴＥを用いた場合は、ネットワークトポロジとネットワークリソースの両方が管理可能になる。

このようにネットワークトポロジ管理部４１とネットワークリソース管理部４２が同一の技術により実現されていてもよい。

図２は、制御要求受付部２０を示す構成図である。構成の詳細および構成間の信号の詳細は、後記するフローチャートの説明にて明らかにする。

図３は、制御要求処理部３０を示す構成図である。構成の詳細および構成間の信号の詳細は、後記するフローチャートの説明にて明らかにする。制御要求処理部３０は、要求解釈部３１、および、通信履歴情報ＤＢ３２を有する。

図４は、制御情報管理部５０を示す構成図である。構成の詳細および構成間の信号の詳細は、後記するフローチャートの説明にて明らかにする。制御情報管理部５０は、制御情報抽出部５１、制御情報蓄積部５２、制御情報ＤＢ５３、および、制御情報検出部５４を有する。

図５は、通信システムの処理を示すフローチャートである。以下、図５を主に参照しつつ、適宜図２〜図４を参照して、通信システムの処理を説明する。

ユーザプログラム処理部１０ａは、制御要求受付部２０に対して、制御要求と通信開始時刻、通信終了時刻、および、通信帯域に関して複数のパターンを作成することが可能な所定の範囲を示した制御条件を通知する（Ｓ１１）。

なお、制御条件は、クライアント上で実行されるユーザプログラムから通信実行要求と通信元ＩＰアドレス・通信先ＩＰアドレス・ユーザプログラム名・ユーザプログラム識別子・プロトコル名・プロトコル識別子・ポート番号・帯域・転送する必要があるデータ量とその方向・許容できる通信遅延、通信遅延の影響を大きく受ける通信であるか否か・通信を行う画像や映像や音声の品質レベル・通信用インターフェイスやディスクの読み書きの速度やメモリの読み書きの速度やＣＰＵなどによる計算能力に由来する通信元計算機の最大通信速度・通信用インターフェイスやディスクの読み書きの速度やメモリの読み書きの速度やＣＰＵなどによる計算能力等に由来する通信先計算機の最大通信速度・最低限必要となる通信速度・通信を開始可能になる時刻・通信を必ず開始している必要がある時刻・通信が終了可能になる時刻・通信を必ず終了している必要がある時刻・通信途中での帯域変更の可否・通信途中での経路変更の可否、必要とする故障時復旧方式、必要とするパスの信頼性や稼働率、許容する最大無通信時間、許容する最大コストなどの中の１つもしくは複数のパラメータにより規定される。

制御要求受付部２０は、制御要求処理部３０（図３の要求解釈部３１）に対して、Ｓ１１で受信した情報を通知する（Ｓ１２）。

制御要求処理部３０（図３の要求解釈部３１）は、ネットワークトポロジ管理部４１に対して、ネットワークトポロジを要求する（Ｓ２１）。

ネットワークトポロジ管理部４１は、制御要求処理部３０（図３の要求解釈部３１）に対して、Ｓ２１の要求への返答として、ネットワークトポロジを通知する（Ｓ２２）。なお、Ｓ２２の処理は、Ｓ２１の処理を行わなくても、所定の契機により実行してもよい。所定の契機は、例えば、定期的、あるいは、ネットワークトポロジまたはネットワークリソースの変更があったときである。

制御要求処理部３０（図３の要求解釈部３１）は、ネットワークリソース管理部４２に対して、ネットワークリソースを要求する（Ｓ２３）。

ネットワークリソース管理部４２は、制御要求処理部３０（図３の要求解釈部３１）に対して、Ｓ２３の要求への返答として、ネットワークリソースを通知する（Ｓ２４）。なお、Ｓ２４の処理は、Ｓ２３の処理を行わなくても、所定の契機により実行してもよい。所定の契機は、例えば、定期的、あるいは、ネットワークトポロジまたはネットワークリソースの変更があったときである。

なお、Ｓ２１〜Ｓ２４の具体的な実現方法として、以下の（１）〜（３）の３方法を例示する。
（１）ネットワークトポロジまたはネットワークリソースが、ルーティングプロトコルなどを用いて各ノード３で分散的に管理されていることがある。そのときには、通信制御装置５が受信したルーティングプロトコルのメッセージに含まれるネットワークトポロジまたはネットワークリソースを、要求解釈部３１に通知する。通知する契機は、定期的、制御要求処理部３０から要求があったとき、または、ネットワークトポロジまたはネットワークリソースの変更があったときである。
（２）通信制御装置５は、基幹網１に接続されているノード３（ルータやサーバ）に対してルーティングプロトコルなどの情報、もしくはルーティングプロトコルなどの情報から抽出されたネットワークトポロジを通知するように要求を行い、その要求への返答を要求解釈部３１に通知する。
（３）ネットワークトポロジまたはネットワークリソースが、所定のサーバに格納されていることがある。そのときには、所定のサーバに対してネットワークトポロジまたはネットワークリソースの要求を行い、その要求への返答を要求解釈部３１に通知する。

制御要求処理部３０（図３の要求解釈部３１）は、制御情報管理部５０（図４の制御情報抽出部５１）に対して、Ｓ１２の制御要求と、Ｓ１２の制御条件を利用して作成した通信制御情報の抽出条件とを、通知する（Ｓ２５）。なお、Ｓ２１、Ｓ２３、および、Ｓ２５は、順不同である。

制御情報管理部５０（図４の制御情報抽出部５１）は、制御情報管理部５０（図４の制御情報ＤＢ５３）に対して、Ｓ２５の抽出条件に合致する通信制御情報の検索を指示する（Ｓ２６）。

制御情報管理部５０（図４の制御情報ＤＢ５３）は、制御情報管理部５０（図４の制御情報抽出部５１）に対して、Ｓ２６の指示に合致する通信制御情報を抽出して応答する（Ｓ２７）。

制御情報管理部５０（図４の制御情報抽出部５１）は、制御要求処理部３０（図３の要求解釈部３１）に対して、Ｓ２７で抽出された通信制御情報を通知する（Ｓ２８）。

要求解釈部３１は、Ｓ２２、Ｓ２４、および、Ｓ２８で受信した情報を元に、Ｓ１２で受信した要求に適合し、かつ、通信開始時刻、通信終了時刻、および、通信帯域が明確になったサービス案を１つもしくは複数作成する。以下、サービス案の作成方法を例示する。
・通信対地間の伝播遅延を最も小さくする方法
・消費するリンク数と必要とする帯域で求められるのべ消費帯域を最も小さくする方法
・パスを設定すると残余帯域が所定値以下になるリンクを利用しない経路を利用する方法
・所定の時間範囲内で最もネットワークが空いている時間に通信を行うようにする方法
・通信途中でパスを切り替えることにより、途中からより低遅延なパスに切り替えたり、より低コストで利用できるパスに切り替えたりする方法
・通信途中で帯域を変更することにより各リンクの残余帯域が所定値以下にならないようにしたり、各リンクの残余帯域の分散を最小化したりする方法
・帯域変更を行わないですむような方法
・途中で経路変更をしないですむような方法
・途中でどのような変更が行われてもかまわないので、低コストで実現できる通信方法

要求解釈部３１は、例えば、ユーザプログラムからの通信条件として必要とする帯域が明確に定まっていて、必要とする通信時間が明確に定まっていて、経路の切り替えが不可能な場合には、次の（１）から（４）の手順を順に実行することで、サービス案を作成する。
（１）ユーザ端末４間の通信の通信開始時刻におけるネットワークトポロジ、ネットワークリソース、および、通信制御情報を用いて、通信制御を必要とする通信時間の間は必要とされる帯域を残余帯域として有するリンクのみで構成される計算用ネットワークトポロジを作成する
（２）ネットワークリソースを用いて前記（１）の各リンクのメトリックとして遅延を計算用ネットワークトポロジに設定する
（３）ダイクストラアルゴリズムを用いて前記（２）で設定された計算用ネットワークトポロジの中から最も合計メトリックの小さな経路を求める
（４）前記（３）で求めた経路を１つのサービス案とする

この（１）から（４）の手順を順に実行することで、通信遅延をできるだけ小さくしたい（通信遅延に対して敏感に影響を受ける通信である）といった要求である場合、指定された通信時刻の間、通信帯域で最も通信遅延の小さな経路を設計することが可能になり、従ってユーザプログラムの要求を満たすことができる。

要求解釈部３１は、通信履歴情報ＤＢ３２にアクセスして、通信履歴情報ＤＢ３２に格納されている情報を利用してサービス案を作成してもよい（Ｓ２９）。なお、通信履歴情報ＤＢ３２は、ユーザごとに、どのようなサービスを採用するかの履歴を格納する。さらに、通信履歴情報ＤＢ３２は、ユーザプログラムごとに、ユーザプログラム名、ユーザプログラム識別子、プロトコル名、プロトコル識別子、ポート番号、ならびに、通信を行う画像、映像、および、音声の品質レベルのうちの少なくとも１つの情報から適切な通信時間の長さと帯域を決定するのに必要な情報を格納する。

採用されるサービス案は、例えば、ＩＰ電話の用途で通信制御を行う場合、通信履歴情報ＤＢ３２を利用しないときには、一般的な通信の大部分が収容できるような利用時間を採用し、通信制御のサービス案を作成する。一方、通信履歴情報ＤＢ３２を利用するときには、ＩＰ電話に特化してその通信の大部分が収容できるような利用時間を採用し、通信制御のサービス案を作成する。

制御要求処理部３０（図３の要求解釈部３１）は、制御要求受付部２０に対して、Ｓ２８またはＳ２９をもとに作成されたサービス案を通知する（Ｓ３１）。

制御要求受付部２０は、ユーザプログラム処理部１０に対して、Ｓ３１で通知されたサービス案を通知する（Ｓ３２）。

ユーザプログラム処理部１０は、Ｓ３１で通知されたサービス案から通信制御に利用するサービス案を、ユーザの希望により、選択する（Ｓ４０）。

ユーザプログラム処理部１０は、制御要求受付部２０に対して、Ｓ４０で選択されたサービス案を通知する（Ｓ４１）。

制御要求受付部２０は、制御情報管理部５０（図４の制御情報蓄積部５２）に対して、Ｓ４１で通知されたサービス案を通信制御情報として送信し、蓄積するように要求する（Ｓ４２）。

制御情報管理部５０（図４の制御情報蓄積部５２）は、制御情報管理部５０（図４の制御情報ＤＢ５３）に対して、Ｓ４２で要求された通信制御情報を蓄積する（Ｓ４３）。

制御情報管理部５０（図４の制御情報蓄積部５２）は、制御情報管理部５０（図４の制御情報検出部５４）に対して、Ｓ４２で要求された通信制御情報が即座に通信を開始する必要のあるサービスであった場合は、Ｓ４３と同時に、即座に通信を開始するサービスがあること、または、即座に通信を開始するサービスそのものを通知する（Ｓ４４）。

通信制御指示部６０は、制御情報管理部５０（図４の制御情報検出部５４）に対して、パスの設定や解放や状態変更などの通信制御情報を要求する（Ｓ５０）。なお、Ｓ５０が発生する契機は、例えば、定期的である。また、Ｓ５０は、省略してもよい。

図４の制御情報検出部５４は、図４の制御情報ＤＢ５３に対して、通信制御する必要がある通信制御情報の検出を実施する（Ｓ５１）。なお、Ｓ５１の実行契機は、例えば以下の契機が挙げられる。
・定期的
・Ｓ５０の通信制御指示部６０からの要求を受けたとき
・Ｓ４４の制御情報蓄積部５２からの要求を受けたとき
・制御情報ＤＢ５３の制御情報が存在する時刻のタイマをトリガとする。例えば、８：００，１０：３０，１２：００から通信を開始（通信制御を実行）する予定となっている場合、それぞれの時刻（８：００，１０：３０，１２：００）になったときに、通信制御を行うべき制御情報が存在していると通知する。

図４の制御情報ＤＢ５３は、図４の制御情報検出部５４に対して、Ｓ５１の通信制御情報の検出に対する検出結果として、通信制御情報を通知する（Ｓ５２）。

図４の制御情報検出部５４は、通信制御指示部６０に対して、Ｓ５２で通知された通信制御情報を通知する（Ｓ５３）。

通信制御指示部６０は、基幹網１に対して、Ｓ５３の通信制御情報に従って通信制御を実行する（Ｓ６０）。また、通信制御は、基幹網１と周辺網２を対象としてもよいし、周辺網２だけを対象としてもよい。なお、通信制御は、例えば、以下の方法が例示される。
・基幹網１の装置と通信を行い、Ｄｉｆｆｓｅｒｖによるパケット転送優先制御の設定を変更する
・ルータ等のノード３に対してＲＳＶＰ−ＴＥなどのＭＰＬＳやＧＭＰＬＳ等のシグナリングプロトコルを用いてパスを制御する
・各ノード３にＣＬＩを利用してアクセスしたり、ＴＬ１などのプロトコルを用いて各ノード３にアクセスしたりしてパスを制御する。なお、ＣＬＩでアクセスするプロトコルは、例えば、ｔｅｌｎｅｔ，ｓｓｈなどが挙げられる。

ユーザプログラム処理部１０は、通信相手のユーザプログラム処理部１０に対して、Ｓ６０で通信制御された通信を行う（Ｓ７０）。

以下、要求解釈部（要求解釈装置）３１が実行する要求解釈処理の詳細を説明する。なお、要求解釈処理の対象となるネットワークシステムは、図１に記載されたものが例示されるが、必ずしも図１のネットワークに限定されることはない。以下の手段を有するネットワークシステムが、要求解釈処理の対象となるネットワークシステムの別の一例である。
・パスを設定することで特定のサイト間もしくは特定の計算機間もしくは特定のユーザプログラム間に対して通信帯域などを保証することができる手段
・パスを設定・解放あるいは帯域などの制御条件の変更などの通信制御を実施する時刻とそのパスをどのような条件（両端のサイト識別子、ユーザ識別子、ユーザプログラム識別子など）で提供するかの情報である通信制御情報を蓄積する手段
・前記の蓄積した通信制御情報で必要となる制御はネットワークリソースの不足などが発生せず必ず実行ができるようにネットワークリソースの許容量を超える要求は受け付けをしない手段
・前記の蓄積した情報に従って制御が必要な時刻に通信制御を実行する手段

図６は、サービス案の作成方法の一例を説明するためのフローチャートである。このフローチャートは、ユーザプログラムの要求条件として、必要とする帯域が明確に定まっていて、必要とする通信時間が明確に定まっていて、経路の切り替えが可能な場合に、実行される。図６の各処理を実行する主体は、要求解釈部３１である。

Ｓ１０１は、ユーザプログラムから要求条件を受け付ける処理である。

Ｓ１０２は、トポロジ情報を計算用ネットワークトポロジとして定義する処理である。つまり、基幹ネットワークのネットワークトポロジ情報とネットワークリソース情報と通信制御情報蓄積機能に蓄積されている通信制御情報を用いて通信開始時刻の時点でユーザプログラムが必要とする帯域を残余帯域として有し利用可能なリンクのみで構成されたトポロジを計算用ネットワークトポロジとする。

Ｓ１０３は、ユーザプログラムが必要としている通信開始時刻から終了時刻までの間の時間帯を経路を求める対象時間帯とする処理である。Ｓ１０３は、Ｓ１０２の実行後からＳ１０５の実行直後までであれば、どこで実行してもよいが、まとめる手順以降に入れると記述がさらに複雑になる。経路を求める対象とする時間としてユーザプログラムが指定した通信開始時刻と通信終了時刻の間と定義する。

Ｓ１０４は、計算用ネットワークトポロジにメトリックを設定する処理である。つまり、計算用ネットワークトポロジの各リンクにメトリックをして割り当てる。これにより、パス計算アルゴリズムを用いることで目的とする経路を計算することが可能となる。計算用ネットワークトポロジのメトリックの付け方として４つの例を挙げる。
（１）コスト例（ＯＳＰＦなどのルーティングプロトコルのリンクコスト）：ＯＳＰＦ−ＴＥなどのルーティングプロトコルで利用しているリンクコストを、計算用ネットワークトポロジのメトリックとして利用する。
（２）コスト例（残余帯域）：各リンクの残余帯域を元にして算出される値を、計算用ネットワークトポロジのメトリックとして利用する。
（３）コスト例（遅延）：各リンクでかかる伝播遅延とリンクの接続先の装置での転送遅延のどちらかもしくは両方の合計値から算出される値を、計算用ネットワークトポロジのメトリックとして利用する。
（４）コスト例（物理的な距離）：各リンク間の物理的な距離から算出される値をメトリックとして利用する。

Ｓ１０５は、最短経路を求めるアルゴリズムを用いて最もメトリックの小さな経路を求める処理である。つまり、ダイクストラアルゴリズムなどの最短経路を求めるアルゴリズムを用いて計算用ネットワークトポロジの中で最も合計メトリックの小さな経路を求める。

そして、経路中の最低帯域をまとめる。図７に示されたネットワークおよびその時間帯別の残余帯域から、経路の各リンクの最低帯域をまとめる（Ｍｉｎ（各リンクの残余帯域）を求める）。なお、本明細書では、関数Ｍｉｎ（第１引数，第２引数，…）は、引数の中から最小値となる引数を選択する処理を示す。なお、図７に示されたネットワークの詳細を、表１に示す。

Ｓ１０６は、「求めた経路で帯域不足が発生する時間帯がある」という判定条件を満たすか否かを判定する処理である。この判定条件は、「求めた経路で通信対象となる時刻すべてにおいて必要とする帯域での通信が可能である」と言い換えることもできる。Ｓ１０６の判定条件を満たすときには（Ｓ１０６，Ｙｅｓ）、Ｓ１０７に処理を移行し、Ｓ１０６の判定条件を満たさないときには（Ｓ１０６，Ｎｏ）、Ｓ１１０に処理を移行する。

Ｓ１１０は、求められた時間帯・経路の対応をサービス案とする処理である。つまり、これまで求めたすべてを利用してサービス案の１つとする。

Ｓ１０７は、帯域不足が発生した時間帯を経路を求める対象時間帯とする処理である。つまり、必要な帯域を満たさない時間については別の経路を求める作業が必要になる。必要な帯域を満たしている時間帯については求めた経路・時間帯にてサービスを行うと決定する。また、必要な帯域を満たさない時間については、今後の手順において経路を求める対象とする時間として決定する。通信を必要とする時間の間にすべての時間で通信が可能であった場合には、求めた経路をサービス案として定義する。

Ｓ１０８は、Ｋ−ＴＨ ＳＨＯＲＴＥＳＴ ＰＡＴＨを求めるアルゴリズムを用いて先の経路の次に合計メトリックの小さな経路を計算する処理である。つまり、Ｋ−ＴＨ ＳＨＯＲＴＥＳＴ ＰＡＴＨを求めるアルゴリズムを用いて、前の処理で計算した経路の次にメトリックの小さな経路を計算する。処理をＳ１０６に戻す。

なお、サービス案が作成されるか一定の回数を繰り返したり一定時間計算を実行したりしたところで指定された条件でのサービスは提供できないとして処理を終了する。

図８は、サービス案の作成方法の一例を説明するためのフローチャートである。このフローチャートは、ユーザプログラムの要求条件として、通信に必要な帯域が明確であり、通信の開始時刻と終了時刻の範囲が指定され通信実行時間の長さが明確であり、経路切り替えが不能な場合に、実行される。図８の各処理を実行する主体は、要求解釈部３１である。

Ｓ２０１は、ユーザプログラムから要求条件を受け付ける処理である。

Ｓ２０２は、トポロジ情報を計算用ネットワークトポロジとして定義する処理である。つまり、基幹ネットワークのネットワークトポロジ情報そのものをトポロジを計算用ネットワークトポロジとする。

Ｓ２０３は、計算用ネットワークトポロジにメトリックを設定する処理である。つまり、計算用ネットワークトポロジの各リンクにメトリックを割り当てる。これにより、パス計算アルゴリズムを用いることで経路を計算することができる。計算用ネットワークトポロジのメトリックの付け方は、例えば、Ｓ１０４に示した例で示される。

Ｓ２０４は、最短経路を求めるアルゴリズムを用いて最もメトリックの小さな経路を求める処理である。つまり、ダイクストラアルゴリズムなどの最短経路を求めるアルゴリズムを用いて計算用ネットワークトポロジの中で最も合計メトリックの小さな経路を求める。

Ｓ２０５は、通信の開始時刻と終了時刻の範囲内において、各リンクの最低残余帯域でまとめる処理である。つまり、図７に示すように求めた経路の各リンクの最低帯域をまとめる（Ｍｉｎ（各リンクの残余帯域）を求める）。

Ｓ２０６は、「指定された通信時間を確保することができる」という判定条件を満たすか否かを判定する処理である。Ｓ２０６の判定条件は、「求めた経路で通信対象となる時刻すべてにおいて必要とする帯域での通信が可能である」と言い換えることもできる。Ｓ２０６の判定条件を満たすときには（Ｓ２０６，Ｙｅｓ）、Ｓ２１０に処理を移行し、Ｓ２０６の判定条件を満たさないときには（Ｓ２０６，Ｎｏ）、Ｓ２０７に処理を移行する。

Ｓ２１０は、求められた時間帯・経路をサービス案とする処理である。つまり、これまで求めたすべてを利用してサービス案の１つとし、サービスを行うと決定する。

Ｓ２０７は、Ｋ−ＴＨ ＳＨＯＲＴＥＳＴ ＰＡＴＨを求めるアルゴリズムを用いて、先の経路の次に合計メトリックの小さな経路を計算する処理である。つまり、Ｋ−ＴＨ ＳＨＯＲＴＥＳＴ ＰＡＴＨを求めるアルゴリズムを用いて、前の処理で計算した経路の次にメトリックの小さな経路を計算する。処理をＳ２０５に戻す。

なお、サービス案が作成されるか一定の回数を繰り返したり一定時間計算を実行したりしたところで指定された条件でのサービスは提供できないとして処理を終了する。

図９は、サービス案の作成方法の一例を説明するためのフローチャートである。このフローチャートは、ユーザプログラムの要求条件として、必要とする最低限必要な帯域と通信可能な最大帯域が指定されており、通信を行う必要のある通信量が明確に定まっており、通信時間を開始する時刻が明確に定まっていて通信実行時問の長さが明確でなく、帯域の変更が不可能であり、経路の切り替えが不可能である場合に、実行される。図９の各処理を実行する主体は、要求解釈部３１である。

Ｓ３０１は、ユーザプログラムから要求条件を受け付ける処理である。

Ｓ３０２は、トポロジ情報を計算用ネットワークトポロジとして定義する処理である。つまり、基幹ネットワークのネットワークトポロジ情報そのものをトポロジを計算用ネットワークトポロジとする。

Ｓ３０３は、計算用ネットワークトポロジにメトリックを設定する処理である。つまり、計算用ネットワークトポロジの各リンクにメトリックを割り当てる。これにより、パス計算アルゴリズムを用いることで経路を計算することができる。計算用ネットワークトポロジのメトリックの付け方は、例えば、Ｓ１０４に示した例で示される。

Ｓ３０４は、最短経路を求めるアルゴリズムを用いて最もメトリックの小さな経路を計算する処理である。つまり、ダイクストラアルゴリズムなどの最短経路を求めるアルゴリズムを用いて計算用ネットワークトポロジの中で最も合計メトリックの小さな経路を求める。

Ｓ３０５は、通信の開始時刻と終了時刻の範囲内において、各リンクの最低残余帯域でまとめる処理である。つまり、図７に示すように求めた経路の各リンクの最低帯域をまとめる（Ｍｉｎ（各リンクの残余帯域）を求める）。

Ｓ３０６は、通信開始時点の残余帯域もしくは最大通信速度の小さな方の値を通信帯域として定義する処理である。Ｓ３０６は、通信帯域のネゴシエーションを行うと表現してもよい。

以下、表２で示された時間帯別の残余帯域をもとに、時間帯別の通信速度を決定するケースを３つ例示する。

第１ケースは、通信速度の再定義が可能であるケースを示す。このケースでは、最小通信速度が１００Ｍｂｐｓであり、最大通信速度が１０００Ｍｂｐｓである。まず、１２：００において、Ｍｉｎ（残余帯域＝８００Ｍｂｐｓ，最大通信速度＝１０００Ｍｂｐｓ）より、通信速度が８００Ｍｂｐｓと定義される。次に、１２：０５において、Ｍｉｎ（残余帯域＝３２０Ｍｂｐｓ，最大通信速度＝１０００Ｍｂｐｓ）より、通信速度が３２０Ｍｂｐｓと再定義される。そして、以降通信速度不足は発生せず、１２：１７までには通信を完了できる。

第２ケースは、通信速度の再定義が不可能なため、他の経路を探す必要があるケースを示す。このケースでは、最小通信速度が３５０Ｍｂｐｓであり、最大通信速度が１０００Ｍｂｐｓである。まず、１２：００において、Ｍｉｎ（残余帯域＝８００Ｍｂｐｓ，最大通信速度＝１０００Ｍｂｐｓ）より、通信速度が８００Ｍｂｐｓと定義される。次に、１２：０５において、Ｍｉｎ（残余帯域＝３２０Ｍｂｐｓ，最大通信速度＝１０００Ｍｂｐｓ）より、通信速度が３２０Ｍｂｐｓと再定義される。しかし、再定義された３２０Ｍｂｐｓは、最小通信速度の３５０Ｍｂｐｓに満たないため、この再定義は無効となり、他の経路を探す必要がある。

第３ケースは、通信速度の再定義が可能であるケースを示す。このケースでは、最小通信速度が１００Ｍｂｐｓであり、最大通信速度が５６０Ｍｂｐｓである。まず、１２：００において、Ｍｉｎ（残余帯域＝８００Ｍｂｐｓ，最大通信速度＝５６０Ｍｂｐｓ）より、通信速度が５６０Ｍｂｐｓと定義される。次に、１２：０５において、Ｍｉｎ（残余帯域＝３２０Ｍｂｐｓ，最大通信速度＝５６０Ｍｂｐｓ）より、通信速度が３２０Ｍｂｐｓと再定義される。そして、以降通信速度不足は発生せず、１２：１７までには通信を完了できる。

Ｓ３０７は、「定義した通信速度が最低通信速度を下回らない」という判定条件を満たすか否かを判定する処理である。Ｓ３０７の判定条件を満たすときには（Ｓ３０７，Ｙｅｓ）、Ｓ３０８に処理を移行し、Ｓ３０７の判定条件を満たさないときには（Ｓ３０７，Ｎｏ）、Ｓ３１０に処理を移行する。

Ｓ３１０は、Ｋ−ＴＨ ＳＨＯＲＴＥＳＴ ＰＡＴＨを求めるアルゴリズムを用いて先の経路の次に合計メトリックの小さな経路を計算する処理である。処理をＳ３０５に戻す。

Ｓ３０８は、「定義した通信帯域で帯域不足が発生せずに指定された通信量が確保できる」という判定条件を満たすか否かを判定する処理である。Ｓ３０８の判定条件を満たすときには（Ｓ３０８，Ｙｅｓ）、Ｓ３１１に処理を移行し、Ｓ３０８の判定条件を満たさないときには（Ｓ３０８，Ｎｏ）、Ｓ３０９に処理を移行する。

Ｓ３１１は、求められた時間帯・帯域・経路をサービス案とする処理である。つまり、通信量が確保できたときの経路・帯域・時間帯をサービス案として決定する。

Ｓ３０９は、帯域不足が発生した時点の帯域を新しい通信速度として定義する処理である。処理をＳ３０７に戻す。

以上の作業を繰り返し、サービス案が作成されるか一定の回数を繰り返したり一定時間計算を実行したりしたところで指定された条件でのサービスは提供できないとして処理を終了する。

以上、サービス案の作成手順を３つ（図６，図８，および、図９）例示した。これらのサービス案の作成手順による顕著な効果について、説明する。

まず、経路を計算する際に使用されるメトリックについて、（１：ルーティングプロトコルのリンクコスト）だけではく、（２：残余帯域）、（３：遅延）、および、（４：物理的な距離）を活用する（Ｓ１０４、Ｓ２０３、Ｓ３０３）特徴を有する。後者３つのパラメータは、ユーザからの通信制御の要求と対応づけやすいので、これらのパラメータを反映した経路を計算することで、ユーザが所望する通信制御を実現しやすくなる。

次に、経路を計算した結果について、ユーザプログラムからの要求条件を満たしているか否かを照合し（Ｓ１０６、Ｓ２０６、Ｓ３０７、Ｓ３０８）、満たしていないときには経路計算をやり直す（Ｓ１０８、Ｓ２０７、Ｓ３１０）特徴を有する。これにより、単にメトリックに最適化した経路計算を実行する方式に比べ、ユーザプログラムから要求条件をより直接的に反映した、ユーザが所望する通信制御を実現しやすくなる。

そして、経路を計算する回数について、複数回繰り返す特徴を有する。１回目は、最短経路を求めるアルゴリズムを用いて最もメトリックの小さな経路（換言すると１番目に適した経路）を計算する（Ｓ１０５、Ｓ２０４、Ｓ３０４）。２回目以降は、Ｋ−ＴＨ ＳＨＯＲＴＥＳＴ ＰＡＴＨを求めるアルゴリズムを用いて、Ｋ番目に適した経路を計算する（Ｓ１０８、Ｓ２０７、Ｓ３１０）。これにより、要求条件を満たす経路の候補のうち、メトリックに最適化した経路の候補を選択でき、ユーザが所望する通信制御を実現しやすくなる。

なお、前記のフローチャートにより規定されるサービス案作成方法は、コンピュータに実行させることも可能であり、この場合にはコンピュータ内のハードディスクなどに格納されるサービス案作成プログラムをコンピュータが実行することにより行われる。

このサービス案作成プログラムは、ＣＤ−ＲＯＭやフレキシブルディスクなどの記録媒体、あるいはインターネットなどのネットワークや電話回線などの通信回線のように情報を伝送する機能を有する電送媒体により供給される。

また、このサービス案作成プログラムは、前記した処理の一部を実現するためのものであってもよい。さらに、前記した処理を別の装置にすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であってもよい。

このように本実施形態によれば、ユーザプログラムが決定できない要素を残した状態の条件を提示し、ネットワークの情報を利用して詳細な条件とパスを決定することで、ネットワークリソースの利用効率を向上させ、通信コストを低減することができ、通信制御の許諾確率を向上させることができる。

従って、ユーザプログラムは要求受け付け・サービス提案機能から提案されたサービス案に従って通信をすることで、ネットワークが混雑している時間や場所を回避して、通信を行うことが可能となり、ネットワークリソースの利用効率を向上させることができる。

本発明の一実施形態に関する通信システム全体を示す構成図である。 本発明の一実施形態に関する制御要求受付部を示す構成図である。 本発明の一実施形態に関する制御要求処理部を示す構成図である。 本発明の一実施形態に関する制御情報管理部を示す構成図である。 本発明の一実施形態に関する通信システムの処理を示すフローチャートである。 本発明の一実施形態に関するサービス案の作成手順を示すフローチャートである。 本発明の一実施形態に関する残余帯域をまとめる手続きを示す説明図である。 本発明の一実施形態に関するサービス案の作成手順を示すフローチャートである。 本発明の一実施形態に関するサービス案の作成手順を示すフローチャートである。

符号の説明

１ 基幹網
２ 周辺網
３ ノード
４ ユーザ端末
５ 通信制御装置
１０ ユーザプログラム処理部
２０ 制御要求受付部
３０ 制御要求処理部
３１ 要求解釈部
３２ 通信特性情報ＤＢ
４１ ネットワークトポロジ管理部
４２ ネットワークリソース管理部
５０ 制御情報管理部
５１ 制御情報抽出部
５２ 制御情報蓄積部
５３ 制御情報ＤＢ
５４ 制御情報検出部
６０ 通信制御指示部

Claims (8)

1. 通信網上に設定されるユーザ端末間の通信を通信制御するために、前記通信制御の対象となる通信に関する通信開始時刻、通信終了時刻、および、通信必要帯域を示した制御条件から、前記通信網に関するネットワークトポロジ、ネットワークリソース、および、前記制御条件をもとに作成される抽出条件を満たす通信制御情報をもとに、前記制御条件を満たすサービス案を作成する要求解釈方法であって、
   コンピュータが、（手順１）から（手順５）までを実行することにより、経路計算をＫ回（Ｋは、１以上の整数）繰り返すことで、前記サービス案を作成することを特徴とする要求解釈方法。
   （手順１）Ｋ＝１とし、前記通信開始時刻から通信終了時刻までを計算対象時間帯とする
   （手順２）前記ネットワークリソースの情報を用いて、前記計算対象時間帯における前記ネットワークトポロジを構成する各リンクのメトリックを求め、ルーティングプロトコルのコストとして前記求めたメトリックを設定する
   （手順３）Ｋ−ＴＨ ＳＨＯＲＴＥＳＴ ＰＡＴＨを求めるアルゴリズムを用いて、前記計算対象時間帯における前記ネットワークトポロジ上の経路のうち、前記（手順２）で設定したメトリックがＫ番目に最小になる経路を求める
   （手順４）前記計算対象時間帯に含まれる部分時間帯ごとに順に選択し、前記選択した部分時間帯における前記（手順３）で求めた経路を構成する各リンクの残余帯域を前記ネットワークリソースの情報から取得し、前記取得した残余帯域のうちの最小の残余帯域を求め、前記求めた最小の残余帯域が前記通信必要帯域以上のときには、前記選択した部分時間帯における経路を前記（手順３）で求めた経路として採用する
   （手順５）前記計算対象時間帯に含まれる部分時間帯のうち、すべての部分時間帯において、前記（手順４）で採用された経路が存在するときには、前記（手順４）で採用された結果である部分時間帯ごとの経路を前記サービス案として作成して処理を終了するとともに、前記計算対象時間帯に含まれる部分時間帯のうち、前記（手順４）で採用された経路が存在しない部分時間帯が存在するときには、前記（手順４）で採用された経路が存在しない部分時間帯を次回の前記計算対象時間帯とし、前記Ｋに１を加算し、前記（手順２）に戻る
2. 前記（手順２）において、残余帯域に由来する値をメトリックとして設定することを特徴とする請求項１に記載の要求解釈方法。
3. 前記（手順２）において、途中のネットワーク装置による転送遅延または各リンクで発生する伝搬遅延に由来する値をメトリックとして設定することを特徴とする請求項１に記載の要求解釈方法。
4. 前記（手順２）において、ネットワーク装置間の距離に由来する値をメトリックとして設定することを特徴とする請求項１に記載の要求解釈方法。
5. 通信網上に設定されるユーザ端末間の通信を通信制御するために、前記通信制御の対象となる通信に関する通信開始時刻、通信終了時刻、および、通信必要帯域を示した制御条件から、前記通信網に関するネットワークトポロジ、ネットワークリソース、および、前記制御条件をもとに作成される抽出条件を満たす通信制御情報をもとに、前記制御条件を満たすサービス案を作成する要求解釈装置であって、
   前記要求解釈装置が、（手順１）から（手順５）までを実行することにより、経路計算をＫ回（Ｋは、１以上の整数）繰り返すことで、前記サービス案を作成することを特徴とする要求解釈装置。
   （手順１）Ｋ＝１とし、前記通信開始時刻から通信終了時刻までを計算対象時間帯とする
   （手順２）前記ネットワークリソースの情報を用いて、前記計算対象時間帯における前記ネットワークトポロジを構成する各リンクのメトリックを求め、ルーティングプロトコルのコストとして前記求めたメトリックを設定する
   （手順３）Ｋ−ＴＨ ＳＨＯＲＴＥＳＴ ＰＡＴＨを求めるアルゴリズムを用いて、前記計算対象時間帯における前記ネットワークトポロジ上の経路のうち、前記（手順２）で設定したメトリックがＫ番目に最小になる経路を求める
   （手順４）前記計算対象時間帯に含まれる部分時間帯ごとに順に選択し、前記選択した部分時間帯における前記（手順３）で求めた経路を構成する各リンクの残余帯域を前記ネットワークリソースの情報から取得し、前記取得した残余帯域のうちの最小の残余帯域を求め、前記求めた最小の残余帯域が前記通信必要帯域以上のときには、前記選択した部分時間帯における経路を前記（手順３）で求めた経路として採用する
   （手順５）前記計算対象時間帯に含まれる部分時間帯のうち、すべての部分時間帯において、前記（手順４）で採用された経路が存在するときには、前記（手順４）で採用された結果である部分時間帯ごとの経路を前記サービス案として作成して処理を終了するとともに、前記計算対象時間帯に含まれる部分時間帯のうち、前記（手順４）で採用された経路が存在しない部分時間帯が存在するときには、前記（手順４）で採用された経路が存在しない部分時間帯を次回の前記計算対象時間帯とし、前記Ｋに１を加算し、前記（手順２）に戻る
6. 前記（手順２）において、残余帯域に由来する値をメトリックとして設定することを特徴とする請求項５に記載の要求解釈装置。
7. 前記（手順２）において、途中のネットワーク装置による転送遅延または各リンクで発生する伝搬遅延に由来する値をメトリックとして設定することを特徴とする請求項５に記載の要求解釈装置。
8. 前記（手順２）において、ネットワーク装置間の距離に由来する値をメトリックとして設定することを特徴とする請求項５に記載の要求解釈装置。

Images