(57)【特許請求の範囲】
【請求項１】
トークンバケットモデルにおけるパラメータを用いて見なし帯域を求め、求めた見なし帯域の積み上げ処理結果と予め定められた使用上限帯域とを比較してサービスネットワークへの入力トラヒックに対する受付判定を行うシステムのトラヒック制御方法であって、
セッションフローｋ（ｋ＝１，２，…，Ｎ）のトークンレートｒkを入力する第１のステップ、
該入力されたトークンレートｒkと予め当該セッションフローの品質クラスｈに応じて設定され記憶装置に記憶された係数を用いて、一次式により当該セッションフローｋに対するバーストサイズσhkを求める第２のステップ、
該求めたバーストサイズσhkと上記入力されたトークンレートｒk、および、予め設定され記憶装置に記憶された当該サービスネットワークの最大スループットＰと予め当該品質クラスｈに応じて設定され記憶装置に記憶された当該サービスネットワークにおけるバッファ時間定数Ｄhを用いて、下記の式（イ）で見なし帯域ｃhkを求める第３のステップ、
該求めた見なし帯域chkと上記入力されたトークンレートｒkとを用いて、下記の式（ロ）で当該品質クラスｈの積み上げ処理結果shkを求める第４のステップ、
該求めた品質クラスｈの積み上げ処理結果ｓhkと予め当該品質クラスｈに対応して定められた使用上限帯域とを比較し、積み上げ処理結果ｓhkが使用上限帯域以下の場合に受け付け可と判定し、使用上限帯域より大きい場合に受け付け不可と判定する第５のステップ
を有することを特徴とするトラヒック制御方法。
式（イ）： ｃhk＝Ｐ／［１＋｛Ｄh×（Ｐ−ｒk）｝／σhk］
式（ロ）： ｓhk＝Σmax（ｒk，ｃhk）、 （ｋ＝１，２，…，Ｎ）
【請求項２】
請求項１に記載のトラヒック制御方法であって、
予め当該セッションフローの品質クラスhに応じて設定され記憶装置に記憶されたバーストサイズ係数ａhを用いて
式（ハ）：  σhk＝ｒk×ａh
により各品質クラス間でバーストサイズσhkを求めることを特徴とするトラヒック制御方法。
【請求項３】
請求項２に記載のトラヒック制御方法であって、
バーストサイズ係数ａhと上記バッファ時間定数Ｄhを同じ値とし、
上記式（イ）と上記式（ロ）の代わりに、下記の式（二）を用いて上記品質クラスｈの積み上げ処理結果ｓhkを求める第６のステップを有することを特徴とするトラヒック制御方法。
式（二）：  ｓhk＝Σ（ｒk）、  （ｋ＝１，２，…，Ｎ）
【請求項４】
請求項１から請求項３のいずれかに記載のトラヒック制御方法であって、
予め当該品質クラスｈに対応して設定され記憶装置に記憶されたアプリケーションの帯域に依存しないバースト時間定数ｂhを上記求めたバーストサイズσhkに加算する第７のステップと、
該バースト時間定数ｂhを加算したバーストサイズを上記式（イ）におけるバーストサイズσhkに代入して、上記見なし帯域cｈｋを求める第８のステップと
を有することを特徴とするトラヒック制御方法。
【請求項５】
請求項１から請求項４のいずれかに記載のトラヒック制御方法であって、
上記受け付け可と判定した場合、
予め記憶装置に記憶された、サービスネットワークごとに決定されるＵＮＩからポリシー制御ポイントまでの遅延ゆらぎ定数ｄを上記求めたバーストサイズσhkに乗算して、ポリシー制御に用いる制御バーストサイズを求める第９のステップを有することを特徴とするトラヒック制御方法。
【請求項６】
請求項１から請求項５のいずれかに記載のトラヒック制御方法であって、
上記受け付け可と判定した場合、
予め記憶装置に記憶された、アプリケーションの帯域に依存しない制御ゆらぎ定数ｅを上記求めたバーストサイズσhkに加算して、ポリシー制御に用いる制御バーストサイズを求める第１０のステップを有することを特徴とするトラヒック制御方法。
【請求項７】
コンピュータに、請求項１から請求項６のいずれかに記載のトラヒック制御方法における各ステップでの処理を実行させるためのプログラム。
【請求項８】
トークンバケットモデルにおけるパラメータを用いて見なし帯域を求め、求めた見なし帯域の積み上げ処理結果と予め定められた使用上限帯域とを比較してサービスネットワークへの入力トラヒックに対する受付判定を行うトラヒック制御システムであって、
請求項１におけるバーストサイズ係数ａhを含む各品質クラスごとに予め対応つけて設定されたバーストサイズ係数と、請求項１におけるバッファ時間定数Ｄhを含む各品質クラスごとに予め対応つけて設定されたバッファ時間定数、および、請求項１における最大スループットＰを記憶する記憶手段と、
請求項１における上記第１のステップの処理を実行して上記トークンレートｒkを入力する手段と、
請求項１における上記第２のステップの処理を実行して上記バーストサイズσhkを求める手段と、
請求項１における上記第３のステップの処理を実行して上記見なし帯域ｃhkを求める手段と、
請求項１における上記第４のステップの処理を実行して上記積み上げ処理結果ｓhkを求める手段と、
請求項１における上記第５のステップの処理を実行して上記受け付け可否の判定を行う手段と
を有することを特徴とするトラヒック制御システム。
【請求項９】
請求項８に記載のトラヒック制御システムであって、
請求項２における上記第６のステップの処理を実行して上記積み上げ処理結果ｓhkを求める手段と、
請求項４における上記バースト時間定数ｂhを含む各品質クラスごとに予め対応つけて設定されたバースト時間定数を記憶する記憶装置を具備すると共に上記第７のステップの処理を実行して上記バースト時間定数ｂhの上記求めたバーストサイズσhkへの加算を行う手段と、
請求項４における上記第８のステップの処理を実行して上記見なし帯域ｃhkを求める手段と、
請求項５における上記遅延ゆらぎ定数ｄを記憶する記憶装置を具備すると共に上記第９のステップの処理を実行して上記ポリシー制御に用いる制御バーストサイズを求める手段と、
請求項６における上記制御ゆらぎ定数ｅを記憶する記憶装置を具備すると共に上記第１０のステップの処理を実行して上記ポリシー制御に用いる制御バーストサイズを求める手段の少なくともいずれか一つを有することを特徴とするトラヒック制御システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＥＴＦ（Internet Engineering Task Force）提案のＳＩＰ（Session Initiation Protocol）等のセッション制御を用いて音声や動画のリアルタイム配信やテレビ電話などのＩＰ（Internet Protocol）ネットワークサービスを提供する技術に係り、特に、トークンバケットモデルにより規制されたトラヒックに対する確定的なのＱｏＳ（Quality of Service）保証を効率的に行うのに好適な技術に関するものである。
【背景技術】
【０００２】
近年、ＮＧＮ（Next Generation Network）の議論が活発に進められ、機能アーキテクチャをはじめとした国際標準化が行われている。ＮＧＮは次世代の様々なネットワークサービスに対するＱｏＳ通信インフラの提供を目指しており、例えば、非特許文献１、非特許文献２においては、ＱｏＳ管理を実施するＲＡＣＳ（Resource and Admission Control Subsystem）と呼ばれるリソース管理／受付制御機能が考えられている。
【０００３】
リソース管理／受付制御機能においては、ＳＩＰ等のセッション制御機能からの帯域要求に基づいて、ネットワークリソースの払出し管理を行ってネットワークリソースの上限値を基にリソース管理を実施し、当該帯域要求に対する受付可否の判定を行う。
【０００４】
受付判定で受付が許可された要求に対しては、トランスポート機能に対してポリシー制御を行うことによって、エンドユーザ間（end-to-end）でのＱｏＳを提供することが検討されている。
【０００５】
このリソース管理／受付制御機能においてＱｏＳ確保する考え方は、ネットワークにおける設備リソース量を、帯域要求に応じて配分し、サービス終了までネットワーク側で確保するということである。
【０００６】
例えば、ユーザまたはアプリケーションからセッション制御機能に、ある帯域量が要求されると、セッション制御機能はリソース管理／受付制御機能に要求帯域量を通知し、リソース管理／受付制御機能は、ネットワークリソース量を上限として、受付管理し、セッション制御機能を介してユーザまたはアプリケーションに対して許可、拒否の通知を行い、許可の場合には、ポリシー制御機能に対して、要求帯域量を設定し、実際のトラヒックが通過できるようにする。
【０００７】
許可された要求に対しては、例えば非特許文献３に記載のように、ＩＥＴＦ（Internet Engineering Task Force） Diffserにおけるポリシー制御機能において実際のトラヒック流入に対して監視を行う。
【０００８】
ＮＧＮでは、様々なトラヒック特性、品質要求条件を持つアプリケーションを収容することが想定されているため、リソース管理／受付制御機能（ＲＡＣＳ）としての処理は、主に、ＳＩＰ等のセッション接続要求を機に、これらを品質クラスごとに実施すること、さらに、リアルタイムに実施することが要求される。
【０００９】
このためは、品質クラスごとにリソース量の論理抽象化を行う必要がある。具体的には、アプリケーションから要求されるリソース量と、管理するネットワークリソース量の論理化を品質クラスごとに行い、かつ処理を高速に行う必要がある。
【００１０】
このようなリソース管理／受付制御機能における要求リソース量の論理化に関しては、トラヒック監視としてDiffservのポリシー制御機能を用いることから、非特許文献３に記載のように、トークンバケットモデルで行うことになる。
【００１１】
従って、アプリケーション側でも、トークンバケットモデルに従ったバースト制限内でトラヒックを送出する必要があり、これをＵＮＩ（User-Network Interface）におけるトラヒック規定とする。トークンバケットモデルでは、トークンレート（長時間の平均レートを規制する）とバーストサイズ（バーストの大きさを規制する）およびピークレート（バースト転送時の最大レートを規制する）の３パラメータでトラヒックを規定する。
【００１２】
このトークンバケットパラメータを考慮して、ネットワークへの入力トラヒックに対する受付判定を行う技術として、例えば、非特許文献４に記載の仮想リソース管理技術がある。
【００１３】
この仮想リソース管理技術では、トークンバケットモデルに従ったトラヒックの最悪条件をＯＮ／ＯＦＦトラヒックとしてモデル化し、申告帯域に対して、比例したバッファ量を仮想的に割り当てることによって、ネットワーク帯域を管理する帯域管理サーバによる各ネットワーク転送ノードのバッファ量を考慮した実効帯域（Ｅｆｆｅｃｔｉｖｅ  Ｂａｎｄｗｉｄｔｈ）の積み上げ管理を以下の考え方に基づいて行い、論理的パケット損失率ゼロの受付判定を行う。以下、図８〜図１２を用いて、その詳細を説明する。
【００１４】
まず、トークンバケットから送出されるトラヒックの最悪条件に関して説明する。トークンバケットで規定されるトラヒックに関しては、図８に示す極値ＯＮ／ＯＦＦ過程（Ｔonの期間はピークレートＰでパケットを送出し、Ｔoffの期間はパケットを送出しない）が最悪条件と考えられる。
【００１５】
すなわち、極値ＯＮ／ＯＦＦ過程は、トークンバケットから送出されるトラヒックパターンの中では、ネットワークに対して最も負荷が大きく、極値ＯＮ／ＯＦＦ過程でのトラヒックパターンの受付判定で、論理的パケットロス率がゼロである条件を満足すれば、そのほかのトラヒックパターンにおいても論理的パケットロス率がゼロである条件を十分満足する。
【００１６】
時刻０からｔまでの間にトークンバケットから送出されるトラヒック量Ω（ｔ）とトークンバケットパラメータ（トークンレートｒ，バケットサイズσ，ピークレートＰ）、およびＴon，Ｔoffの関係は、図９に示すように表わすことができ、これらの図８、図９で示される関係から、極値ＯＮ／ＯＦＦ過程におけるＴon，Ｔoffはトークンバケットパラメータで表わすことができ、下記の式（ａ）および式（ｂ）で表わされる。
【００１７】
式（ａ）：  Ｔon＝σ／（Ｐ−ｒ）
【００１８】
式（ｂ）：  Ｔoff＝σ／ｒ
【００１９】
次に、極値ＯＮ／ＯＦＦ過程トラヒックが使用するリソース量（ｂ，ｃ）の特性について説明する。図１０に示すように、トークンバケットから送出された１本のセッションフローが確定的なキューイングシステムにおいてサービスされることを考える。
【００２０】
ここでは、ｖ（ｔ）を時刻ｔにおけるバッファ量とし、ｂを使用するバッファ量の最大値、ｕ（ｔ）を時刻ｔにおける利用帯域、ｃを利用可能な最大帯域とする。
【００２１】
図１１に示す「キューイングシステムのバッファ量と滞留している時間」と「キューイングシステムにおいて利用している帯域とその時間」との関係に着目すると、このキューイングシステムサービス窓口での、「ｂｕｓｙ  ｐｅｒｉｏｄ：サーバが稼働状態である時間」Ｄonと、「ｉｄｌｅ  ｐｅｒｉｏｄ：サーバがアイドル状態である時間」Ｄoffとの関係は、下記の式（ｃ）と式（ｄ）で表わされる。
【００２２】
式（ｃ）：  Ｄon＝Ｔon＋（ｂ／ｃ）
【００２３】
式（ｄ）：  Ｄoff＝Ｔoff−（ｂ／ｃ）
【００２４】
以上の表現を用いてキューイングシステムにおけるｂｕｓｙ  ｐｅｒｉｏｄである時間の割合を式（ｃ）と式（ｄ）を用いて表わすと、次の式（ｅ）が成立する。
【００２５】
式（ｅ）：  ｒ／ｃ＝Ｄon／（Ｄon＋Ｄoff）
＝Ｔon／（Ｔon＋Ｔoff）＋ｂ／｛ｃ×（Ｔon＋Ｔoff）｝
【００２６】
さらに、式（ｅ）を変形すると、下記の式（ｆ）が成り立つ。
【００２７】
式（ｆ）：  ｂ＝ｃ×（Ｔon＋Ｔoff）×［（ｒ／ｃ）−｛Ｔon／（Ｔon＋Ｔoff）｝］
＝σ−｛σ×（ｃ−ｒ）／（Ｐ−ｒ）｝
【００２８】
次に、仮想リソース技術について説明する。今、トークンバケットパラメータ（トークンレートｒk、バーストサイズσk、ピークレートＰk）を持つセッションフローｋ（k＝１，２，・・，k）がリソース（バッファ量Ｂij，リンク帯域Ｃij）を持つノードｉからノードｊへ至るリンクijに多重されることを考える。
【００２９】
このとき、図１２に示すように、各セッションフローｋに対してリンク帯域ｃk（ｒk≦ｃk≦Ｐk）を仮想的に割り当てることを考える。ただし、この仮想リソース（ｃk）の総量はリンク帯域Ｃijを上回らないようにする。すなわち、下記の式（ｇ）とする。
【００３０】
式（ｇ）：  Σｃk≦Ｃij
【００３１】
このとき、セッションフローｋが使用する仮想的なバッファリソースの最大値ｂkは、上述の式（ｆ）の結果を用いて、下記の式（ｈ）と表わすことができる。
【００３２】
式（ｈ）：  ｂk＝σk−｛σk×（ｃk−ｒk）／（Ｐk−ｒk）｝
【００３３】
実際のバッファ使用量の最大値ｂは、仮想バッファ使用量の和Σｂkを上回ることはないので、次の式（ｉ）が成り立てば、論理的なパケットロスがゼロになる。
【００３４】
式（ｉ）  Σｂk≦Ｂij
【００３５】
言い換えると、上述の式（ｉ）を満たすＫ組の仮想リソース（仮想バッファｂk、見なし帯域ｃk）に対して、上述の式（ｇ）および上述の式（ｉ）が成り立てば、当該リンクにおける論理的なパケットロスはゼロになる。
【００３６】
この技術では、一般的にバッファ量とリンク帯域という２種類のリソース使用量を管理しなければならないが、仮想リソース（仮想バッファｂk、見なし帯域ｃk）が下記の式（ｊ）を満たせば、バッファ使用量＝リンク使用帯域となるため、どちらか一つのリソース管理を行うだけでよい。
【００３７】
式（ｊ）：  Ｂij／Ｃij＝ｂk／ｃk
【００３８】
この場合、上述の式（ｈ）および式（ｊ）から見なし帯域ｃkは、下記の式（ｋ）となる。
【００３９】
式（ｋ）：  ｃk＝Ｐk／［１＋｛Ｂij×（Ｐk−ｒk）｝／（Ｃij×σk）］
【００４０】
この式（ｋ）で与えられた見なし帯域ｃkを、セッションフローｋのリンクijにおける実効帯域ｅk,ijとすれば、この実効帯域ｅk,ijは、セッションフローｋをリンクij（ノードリンクi，j）において論理的パケットロスがゼロの状態で多重し、積み上げ計算することができる帯域値である。
【００４１】
このように、上記仮想リソース管理技術においては、トークンバケットパラメータ（トークンレートｒk、バーストサイズσk、ピークレートＰk）、および、ネットワークにおける物理リンクijにおけるバッフア量Ｂij、リンク帯域Ｃijを用い、見なし帯域cｋを、上述の式（ｋ）で計算する。
【００４２】
そして、上述の式（ｋ）で求められる帯域値ｃkを管理することによって、帯域に加えて、要求されるバースト量、およびネットワークリソース量を考慮した管理を行うことができる。すなわち、要求される帯域とバッフア量の両方の管理を、帯域管理のみで実施することが可能であり、管理データの削減、判定処理の高速化を図ることが可能である。
【００４３】
しかしながら、この仮想リソース管理技術では、これらの積み上げ帯域を計算するパラメータの取得技術、または品質クラスごとの管理技術に関しての考慮がなされていない。
【００４４】
すなわち、上述の式（ｋ）における見なし帯域cｋは、品質クラスごとの帯域値、バッフア量を考慮したものではない。そのため、品質クラスごとにネットワークリソースを管理することができないとの第１の課題がある。
【００４５】
また、上述の式（ｋ）における積み上げ帯域値ｃkは、品質クラスごとに許可するバーストの大きさを考慮していないため、高品質クラスにおいて大きなバーストを許可してしまい、品質劣化が生じるという第２の課題がある。
【００４６】
さらに、ＳＩＰ等のセクション制御機能による帯域要求に基づく形で、上述の式（ｋ）における見なし帯域cｋを計算する場合、要求される帯域値がトークンレートに対応するが、残りのトークンバケットパラメータであるバーストサイズとピークレートを決めなくてはならない。
【００４７】
これらバーストサイズとピークレートのいずれのパラメータも、アプリケーションの送出特性を反映したパラメータ値が理想であり、ＱｏＳ確保の観点からは、ある程度安全側に大きく見積もる必要があることから、ピークレートに関しては、サービスネットワークにおける最大スループットをネットワーク側で与えて定数とすることで問題は起こらない。
【００４８】
しかし、バーストサイズに関しては、定数でネットワーク側において与えた場合、狭帯域の要求に対しては許可するバーストが大きすぎ、広帯域の要求に対しては許可するバーストが小さすぎるという第３の課題がある。
【００４９】
また、トークンレートとバーストサイズおよびピークレートの３つのトークンバケットパラメータは、ＮＧＮにおけるＲＡＣＳ機能アーキテクチャでは、ポリシー制御パラメータとなる。
【００５０】
すなわち、本パラメータ値をポリシー制御ポイントでトラヒック監視することにより、これを通過するトラヒック量がパラメータ値を超えていた場合にそのトラヒックは廃棄する。逆に、このトラヒック監視では、ＵＮＩ条件としてこのパラメータ値以内の流量でトラヒックが流入した場合には、廃棄せずに通過をさせなくてはならない。
【００５１】
しかしながら、実際には、ＲＡＣＳ機能アーキテクチャにおいて、ＵＮＩ規定点とトラヒック監視ポイントが異なっている場合には、ＵＮＩ規定点からトラヒック監視ポイントまでの遅延ゆらぎの影響により、規定内のトラヒックでも廃棄されてしまうという第４の課題がある。
【００５２】
【非特許文献１】European Telecommunications Standards Institute, ”Telecommunications and Internet converged Services and Protocols for Advanced Networking （TISPAN）;ＮＧＮ Functional Architecture Release 1,” ETSI ES 282 001,2005.
【非特許文献２】European Telecommunications Standards Institute,” Telecommunications and Internet converged Services and Protocols for Advanced Networking （TISPAN）Resource and Admission Control Subsystem（ＲＡＣＳ）Functional Architecture,” ETSI ES 282 003,2006.
【非特許文献３】S. Blake, D. Black, M. Carlson, and E. Davies, Z. Wang, W. Weiss,”An Architecture for Differentiated Service,” Internet Engineering Task Force, RFC 2475, Dec. 1998.
【非特許文献４】宮坂昌宏，岩井隆典，笠原英樹，土屋利明，  “規制されたＩＰトラヒックに対する受付判定方式，”  信学技報，NS2005-7,pp.25-28，2005.
【発明の開示】
【発明が解決しようとする課題】
【００５３】
解決しようとする問題点は、従来の、ＳＩＰ等のセッション制御からの帯域要求に基づきネットワークリソース管理を実施するＱｏＳ確保技術においては、仮想リソース管理技術での「積み上げ帯域値ｃk」は、（１）品質クラスごとの帯域値およびバッフア量を考慮したものではないため、品質クラスごとにネットワークリソース管理を行うことができないという点と、（２）品質クラスごとに許可するバーストの大きさを考慮していないため、高品質クラスにおいて大きなバーストを許可してしまい、品質劣化が生じてしまう点、（３）バーストサイズを定数でネットワーク側において与えた場合、狭帯域の要求に対しては許可するバーストが大きすぎ、逆に広帯域の要求に対しては許可するバーストが小さすぎるという点、（４）ＮＧＮでのＲＡＣＳ機能アーキクチャにおける、ＵＮＩ規定点とトラヒック監視ポイントが異なっている場合には、ＵＮＩ規定点からトラヒック監視ポイントまでの遅延揺らぎの影響により、規定内のトラヒックでも廃棄されてしまうという点である。
【００５４】
本発明の目的は、これら従来技術の課題を解決し、ＱｏＳ制御を効率的に行い、音声や動画のリアルタイム配信やテレビ電話などのネットワークサービスの品質を向上させることを可能とすることである。
【課題を解決するための手段】
【００５５】
上記目的を達成するため、本発明では、従来の仮想リソース管理技術による上記式（ｋ）による積み上げ帯域の算出に用いたトークンバケットパラメータ（トークンレートｒk、バーストサイズσk、ピークレートＰk）の内、トークンレート（要求された帯域値ｒk）に関してのみはそのまま積み上げ帯域の算出に利用し、他の２つのパラメータの内、バーストサイズは、予め各品質クラスごとに定められた定数（例えば品質クラスｈに対しては定数ａh）を用いて、上記要求された帯域値ｒkの一次式とすることで求め（例えばσhk＝ｒk×ａh）、また、ピークレートＰkとして、サービスネットワークの最大スループット（Ｐ）を用い、さらに、サービスネットワーク内のリソース量（バッファ量Ｂij、リンク帯域Ｃij）の代わりに、予め各品質クラスごとに定められたサービスネットワークにおけるバッファ時間（例えば品質クラスｈに対しては、バッファ時間Ｄh＝品質クラスｈのバッファ量÷品質クラスｈの割り当て帯域であり、品質クラスｈにおけるバッフア量がすべて読み出されるまでの最大時間である）を用いて、式「ｃhk＝Ｐ／［１＋｛Ｄh×（Ｐ−ｒk）／σhk｝］」により、当該品質クラスｈの積み上げ帯域（見なし帯域ｃhk）を求めることを特徴とする。
【発明の効果】
【００５６】
本発明によれば、品質クラスごとのネットワークリソース管理を行うことができ、ＱｏＳ制御を効率的に行い、音声や動画のリアルタイム配信やテレビ電話などのネットワークサービスの品質を向上させることが可能である。
【発明を実施するための最良の形態】
【００５７】
以下、図を用いて本発明の最良の実施形態例を説明する。図１は、本発明に係るトラヒック制御システムの構成例を示すブロック図であり、図２は、図１におけるトラヒック制御システムの動作原理を示す説明図、図３は、図１におけるリソース管理装置の第１の処理動作例を示すフローチャート、図４は、図１におけるリソース管理装置の第２の処理動作例を示すフローチャート、図５は、図１におけるリソース管理装置の第３の処理動作例を示すフローチャート、図６は、図１におけるリソース管理装置の第４の処理動作例を示すフローチャート、図７は、図１におけるリソース管理装置の第５の処理動作例を示すフローチャートである。
【００５８】
図１において、１は本発明に係る処理動作を行うリソース管理装置（図中「ＱｏＳ管理装置」と記載）、２はユーザ端末、３はポリシー制御装置、４はＵＮＩ、５，６はネットワークであり、リソース管理装置１は、ユーザ端末２からの帯域要求に基づいてセッションの管理を実施するセッション制御機能１ａ（図中「セッション制御部」と記載）と、サービスネットワークのリソース制御を実施するリソース管理／受付判定機能１ｂ（図中「リソース管理／受付判定部」と記載）を有する。
【００５９】
ユーザ端末２は、ＣＰＵ（Central Processing Unit）や主メモリ、表示装置、入力装置、外部記憶装置、通信制御装置等を具備したコンピュータ構成からなり、光ディスク駆動装置等を介してＣＤ−ＲＯＭ等の記憶媒体に記録されたプログラムやデータを外部記憶装置内にインストールした後、この外部記憶装置から主メモリに読み込みＣＰＵで処理することにより、ネットワーク５，６を介しての通信等を実行する。
【００６０】
リソース管理装置１とポリシー制御装置３もコンピュータ構成としプログラムを用いて各機能を実現する構成とすることもよいが、本例では、ハードウェア構成として高速化を図る。
【００６１】
このリソース管理装置１とポリシー制御装置３は、トークンバケットモデルによるトラヒック制御を行い、ユーザ端末２等に対するネットワーク５，６でのデータ転送品質の保証（ＱｏＳ保証）を行う。
【００６２】
すなわち、リソース管理装置１は、セッション制御部１ａにより、ＳＩＰ等のセッション制御からの帯域要求を受け取り、リソース管理／受付判定部１ｂにより、当該帯域要求に対する仮想リソース管理処理を実施して受付判定を行う。
【００６３】
ポリシー制御装置３は、ネットワーク６に流入するトラヒックが、受け付けた要求に違反していないか否かを監視し、違反したトラヒックの流入を防止する機能を有する。
【００６４】
本例のリソース管理装置１は、ＳＩＰ等のセッション制御からの帯域要求に基づき、仮想リソース管理技術を用いてＱｏＳ確保処理を行うが、この仮想リソース管理技術において「積み上げ帯域値」を求める際、品質クラスごとの帯域値およびバッフア量を考慮し、品質クラスごとにネットワークリソース管理を行うことを特徴とする。
【００６５】
すなわち、図２（ａ）に示すように、従来の仮想リソース管理技術では、ネットワークリソースを、物理リンク単位または経路単位には単一のものと考え、帯域とバッフア量を考慮した積み上げ帯域を計算し、ネットワークリソースを上限とした積み上げ管理を実施している。
【００６６】
これに対して、図２（ｂ）に示すように、本例（本発明）の仮想リソース管理技術では、ネットワークリソースを品質クラス単位に分割して管理すると共に、バーストサイズと積み上げ帯域値を、品質クラスごとに計算して積み上げ管理を実施する。
【００６７】
具体的には、ユーザ端末２からの帯域要求をセッション制御機能１ａで受け取ると、セッション制御機能１ａからリソース管理／受付判定機能１ｂに要求帯域値が通知され、リソース管理／受付判定機能１ｂは、通知された要求帯域値に基づき受付判定を実施し、ポリシー制御機能３に対して制御パラメータを通知することにより、ＱｏＳ確保動作を行う。
【００６８】
リソース管理／受付判定機能１ｂによる受付判定動作において、従来技術のトークンバケットモデルでは、長時間の平均レートを規制するトークンレートｒkと、バーストの大きさを規制するトークンバケットサイズ（バーストサイズ）σk、および、バースト転送時の最大レートを規制するピークレートＰkの３つのパラメータをＳＩＰ等のセッション制御からの要求時に決定し、決定した各３つのパラメータ（ｒk、σk、Ｐk）と、サービスネットワーク内のリソース量（バッファ量Ｂij、リンク帯域Ｃij）を用いて、式（ｋ）（ｃk＝Ｐk／［１＋｛Ｂij×（Ｐk−ｒk）｝／（Ｃij×σk）］）により、積み上げ帯域（見なし帯域）ｃkを求めているが、本例では、トークンレートｒkのみ要求を受け、バーストサイズσkは、予め品質クラスごとに定められたバーストサイズ係数（品質クラスｈに対して係数ａh、bh）を用いて、トークンレートrkの一次式として計算することで求め（例σhk＝ｒk×ａh）、また、ピークレートＰkとして、ユーザ契約時に決定されるサービスネットワークの最大スループット（Ｐ）を用いる。
【００６９】
尚、バーストサイズは一般式として、σhk＝rｋ×aｈ＋ｂｈと設定される。また、バーストサイズ係数(ah,bh)は、予めユーザ端末２のユーザとの契約で当該ユーザ端末２からの要求帯域に対する品質クラス（ｈ）が決定されているものとする。
【００７０】
さらに、従来の仮想リソース管理技術において積み上げ帯域の算出に用いる式（ｋ）におけるサービスネットワーク内のリソース量（バッファ量Ｂij、リンク帯域Ｃij）の代わりに、本例では、予め品質クラスごとに定められたサービスネットワークにおけるバッファ時間（例えば品質クラスｈに対してはバッファ時間Ｄh＝品質クラスｈのバッファ量÷品質クラスｈの割り当て帯域で、品質クラスｈにおけるバッフア量がすべて読み出されるまでの最大時間である）を用い、式「ｃhk＝Ｐ／［１＋｛Ｄh×（Ｐ−ｒk）／σhk｝］」により、当該品質クラスｈの積み上げ帯域（見なし帯域）ｃhkを求める。
【００７１】
以下、このような本発明に係る受付判定動作の＜第１の実施例＞に関して、図３を用いて詳細に説明する。
【００７２】
図３に示す受付判定動作は、図１におけるユーザ端末２からの帯域要求に基づいてセッションの管理を実施するセッション制御機能１ａと、サービスネットワークのリソース制御を実施するリソース管理／受付判定機能１ｂにより実施される。
【００７３】
尚、リソース管理／受付判定機能１ｂは、予めネットワークサービスを提供する側で設定される品質クラス（ｈ）ごとのバーストサイズ（σhk）を求める際に用いる品質クラス（ｈ）ごとに定められた定数（ａh）と、従来の仮想リソース管理技術における積み上げ帯域算出用の式（ｋ）におけるピークレートＰkの代わりに用いるサービスネットワークの最大スループットＰおよびサービスネットワーク内のリソース量（バッファ量Ｂij、リンク帯域Ｃij）の代わりに用いる、予め品質クラスごとに定められたサービスネットワークにおけるバッファ時間（Ｄh）を、記憶装置に記憶管理しておく。
【００７４】
リソース管理／受付判定機能１ｂは、セッション制御機能１ａからセッションｋ（ｋ＝１，２，・・・，Ｎ）ごとに通知される帯域値ｒkを入力すると（ステップＳ３０１）、まず、この帯域値ｒkと、当該セッションｋの品質クラスｈに対応付けて記憶装置に記憶している定数ａhとから、当該セッションｋに対するバーストサイズσhkを下記の式（１）を用いて求める（ステップＳ３０２）。
【００７５】
式（１）：σhk＝ｒk×ａh
【００７６】
次に、リソース管理／受付判定機能１ｂは、式（１）で求めたバーストサイズσhkと、記憶装置に記憶している定数Ｐ（サービスネットワークで最大スループットを表す定数）および当該品質クラスに対応する定数Ｄh（サービスネットワークにおける当該品質クラスｈのバッフア時間を表す定数）を用いて、当該セッションの積み上げ帯域ｃhkを下記の式（２）で計算する（ステップＳ３０３）。
【００７７】
式（２）： ｃhk＝Ｐ／［１＋｛Ｄh×（Ｐ−ｒk）／σhk｝］
【００７８】
そして、リソース管理／受付判定機能１ｂは、下記の式（３）による計算を当該品質クラスｈに対して行うことで、積み上げ処理を実施し、予め当該品質クラスｈに対して定められた使用上限帯域と比較して、積み上げ処理の結果の値ｓhkが使用上限帯域以下の場合は受付可とし、使用上限帯域より大きい場合には受付不可とし、その判定結果をセッション制御機能１ａに通知する（ステップＳ３０４）。
【００７９】
式（３）：ｓhk＝Σmax（ｒk,ｃhk）、  （ｋ＝１，２，…，Ｎ）
【００８０】
次に、図４を用いて、本発明に係る受付判定動作の＜第２の実施例＞に関して、その詳細を説明する。
【００８１】
図４に示す受付判定動作は、図１におけるユーザ端末２からの帯域要求に基づいてセッションの管理を実施するセッション制御機能１ａと、サービスネットワークのリソース制御を実施するリソース管理／受付判定機能１ｂ、および、サービスネットワークヘのトラヒック流入に対してトラヒック監視・規制を実施するポリシー制御機能３により実施され、かつ、リソース管理／受付判定機能１ｂにおいては、最大スループットＰと、「定数ａh」を含む各品質クラスごとのバーストサイズ係数および各品質クラスごとのバッファ時間（Ｄh）を記憶装置に記憶管理しておく。
【００８２】
リソース管理／受付判定機能１ｂは、セッション制御機能１ａからセッションｋ（ｋ＝１，２，・・・，Ｎ）ごとに通知される帯域値ｒkを入力すると（ステップＳ４０１）、まず、この帯域値ｒkと、当該セッションｋの品質クラスｈに対応して記憶装置に記憶しているバーストサイズ係数ａhとから、当該セッションｋに対するバーストサイズσhkを下記の式（４）を用いて求める（ステップＳ４０２）。
【００８３】
式（４）：σhk＝ｒk×ａh
【００８４】
次に、リソース管理／受付判定機能１ｂは、次の式（５）による計算を行うことで、品質クラスｈでの積み上げ処理を実施し、当該品質クラスｈの使用上限帯域と比較して、積み上げ処理の結果の値ｓhkが使用上限帯域以下の場合は受付可とし、使用上限帯域より大きい場合には受付不可とする（ステップＳ４０３）。尚、この処理は、上述の第１の実施例におけるステップＳ３０３の積み上げ帯域値の計算において「ａh＝Ｄh」とした場合に相当する。
【００８５】
式（５）：ｓhk＝Σ（ｒk）、  （ｋ＝１，２，…，Ｎ）
【００８６】
さらに、リソース管理／受付判定機能１ｂは、サービスネットワーク（５）ごとに決定されるＵＮＩ（４）からポリシー制御ポイント（３）までの遅延ゆらぎを表す定数であるｄを予め記憶装置に記憶管理しており、ステップＳ４０３の処理における受付判定の結果が受付可であった場合、制御バーストサイズσ'hkを下記の式（６）で求める（ステップＳ４０４）。
【００８７】
式（６）：σ'hk＝ｒk×ａh×ｄ
【００８８】
そして、リソース管理／受付判定機能１ｂは、算出した制御バーストサイズσ'hkと、セッション制御機能１ａから通知された帯域値ｒkをポリシー制御機能３に通知する（ステップＳ４０５）。
【００８９】
次に、図５を用いて、本発明に係る受付判定動作の＜第３の実施例＞に関して、その詳細を説明する。
【００９０】
図５に示す受付判定動作は、図１におけるユーザ端末２からの帯域要求に基づいてセッションの管理を実施するセッション制御機能１ａと、サービスネットワークのリソース制御を実施するリソース管理／受付判定機能１ｂ、および、サービスネットワークヘのトラヒック流入に対してトラヒック監視・規制を実施するポリシー制御機能３により実施され、かつ、リソース管理／受付判定機能１ｂにおいては、最大スループットＰおよび予め各品質クラスごとに定められたバーストサイズ係数（品質クラスｈに対して定数ａh）とバッファ時間（品質クラスｈに対しては定数Ｄh）、ならびに、ＵＮＩからポリシー制御ポイントまでの遅延ゆらぎを表す定数ｄを予め記憶装置に記憶管理しておく。
【００９１】
リソース管理／受付判定機能１ｂは、セッション制御機能１ａからセッションｋ（ｋ＝１，２，・・・，Ｎ）ごとに通知される帯域値ｒkを入力すると（ステップＳ５０１）、まず、この帯域値ｒkと、当該セッションｋの品質クラスｈに対応して記憶装置に記憶している定数ａhとから、当該セッションに対するバーストサイズσhkを下記の式（７）を用いて求める（ステップＳ５０２）。
【００９２】
式（７）：σhk＝ｒk×ａh
【００９３】
次に、リソース管理／受付判定機能１ｂは、式（７）で求めたバーストサイズσhkと、記憶装置に記憶している定数Ｐ（サービスネットワークで最大スループットを表す定数）および定数Ｄh（サービスネットワークにおける品質クラスｈのバッフア時間を表す定数）を用いて、当該品質クラスｈの当該セッションの積み上げ帯域ｃhkを下記の式（８）で計算する（ステップＳ５０３）。
【００９４】
式（８）： ｃhk＝Ｐ／［１＋｛Ｄh×（Ｐ−ｒk）／σhk｝］
【００９５】
そして、リソース管理／受付判定機能１ｂは、下記の式（９）による計算を行うことで、当該品質クラスｈの積み上げ処理を実施し、当該品質クラスｈに対して予め定められた使用上限帯域と比較して、積み上げ処理の結果の値ｓhkが使用上限帯域以下の場合は受付可とし、使用上限帯域より大きい場合には受付不可とし、その判定結果をセッション制御機能１ａに通知する（ステップＳ５０４）。
【００９６】
式（９）：ｓhk＝Σmax（ｒk,ｃhk）、  （ｋ＝１，２，…，Ｎ）
【００９７】
ステップＳ５０４の処理における受付判定の結果が受付可であった場合、リソース管理／受付判定機能１ｂは、記憶装置に記憶している遅延ゆらぎを表す定数ｄを用いて、制御バーストサイズσ'hkを下記の式（１０）で求める（ステップＳ５０５）。
【００９８】
式（１０）：σ'hk＝ｒk×ａh×ｄ
【００９９】
そして、リソース管理／受付判定機能１ｂは、算出した制御バーストサイズσ'hkと、セッション制御機能１ａから通知された帯域値ｒkをポリシー制御機能３に通知する（ステップＳ５０６）。
【０１００】
次に、図６を用いて、本発明に係る受付判定動作の＜第４の実施例＞に関して、その詳細を説明する。
【０１０１】
図６に示す受付判定動作は、図１におけるユーザ端末２からの帯域要求に基づいてセッションの管理を実施するセッション制御機能１ａと、サービスネットワークのリソース制御を実施するリソース管理／受付判定機能１ｂ、および、サービスネットワークヘのトラヒック流入に対してトラヒック監視・規制を実施するポリシー制御機能３により実施され、かつ、リソース管理／受付判定機能１ｂにおいては、最大スループットＰおよび予め各品質クラスごとに定められたバーストサイズ係数（品質クラスｈに対し定数ａh、ｂｈ）とバッファ時間（品質クラスｈに対しては定数Ｄh）、ＵＮＩからポリシー制御ポイントまでの遅延ゆらぎを表す定数ｄおよびアプリケーションの帯域に依存しない制御ゆらぎを表す定数ｅを予め記憶装置に記憶管理しておく。
【０１０２】
リソース管理／受付判定機能１ｂは、セッション制御機能１ａからセッションｋ（ｋ＝１，２，・・・，Ｎ）ごとに通知される帯域値ｒkを入力すると（ステップＳ６０１）、まず、この帯域値ｒkと、当該セッションｋの品質クラスｈに対応して記憶装置に記憶している定数ａhおよび定数ｂhから、当該セッションに対するバーストサイズσhkを下記の式（１１）を用いて求める（ステップＳ６０２）。
【０１０３】
式（１１）：σhk＝ｒk×ａh＋ｂh
【０１０４】
次に、リソース管理／受付判定機能１ｂは、式（１１）で求めたバーストサイズσhkと、記憶装置に記憶している定数Ｐ（サービスネットワークで最大スループットを表す定数）および定数Ｄh（サービスネットワークにおける当該品質クラスｈのバッフア時間を表す定数）を用いて、当該品質クラスｈのセッションｋの積み上げ帯域ｃhkを下記の式（１２）で計算する（ステップＳ６０３）。
【０１０５】
式（１２）： ｃhk＝Ｐ／［１＋｛Ｄh×（Ｐ−ｒk）｝／σhk］
【０１０６】
そして、リソース管理／受付判定機能１ｂは、下記の式（１３）による計算を行うことで、当該品質クラスｈの積み上げ処理を実施し、当該品質クラスｈに予め対応付けて定められた使用上限帯域と比較して、積み上げ処理の結果の値ｓhkが使用上限帯域以下の場合は受付可とし、使用上限帯域より大きい場合には受付不可とし、その判定結果をセッション制御機能１ａに通知する（ステップＳ６０４）。
【０１０７】
式（１３）：ｓhk＝Σmax（ｒk,ｃhk）、  （ｋ＝１，２，…，Ｎ）
【０１０８】
ステップＳ６０４の処理における受付判定の結果が受付可であった場合、リソース管理／受付判定機能１ｂは、記憶装置に記憶している遅延ゆらぎ定数ｄと制御ゆらぎ定数ｅを用いて、制御バーストサイズσ'hkを下記の式（１４）で求める（ステップＳ６０５）。
【０１０９】
式（１４）：σ'hk＝ｒk×ａh×ｄ＋ｅ
【０１１０】
そして、リソース管理／受付判定機能１ｂは、算出した制御バーストサイズσ'hkと、セッション制御機能１ａから通知された帯域値ｒkをポリシー制御機能３に通知する（ステップＳ６０６）。
【０１１１】
次に、図７を用いて、本発明に係る受付判定動作の＜第５の実施例＞に関して、その詳細を説明する。
【０１１２】
図７に示す受付判定動作は、図１におけるユーザ端末２からの帯域要求に基づいてセッションの管理を実施するセッション制御機能１ａと、サービスネットワークのリソース制御を実施するリソース管理／受付判定機能１ｂ、および、サービスネットワークヘのトラヒック流入に対してトラヒック監視・規制を実施するポリシー制御機能３により実施され、かつ、リソース管理／受付判定機能１ｂにおいては、最大スループットＰおよび予め各品質クラスごとに定められたバーストサイズ係数（品質クラスｈに対して定数ａh）とバッファ時間（品質クラスｈに対しては定数Ｄh）、ならびに、ＵＮＩからポリシー制御ポイントまでの遅延ゆらぎを表す定数ｄとアプリケーションの帯域に依存しない制御ゆらぎを表す定数ｅを予め記憶装置に記憶管理しておく。
【０１１３】
リソース管理／受付判定機能１ｂは、セッション制御機能１ａからセッションｋ（ｋ＝１，２，・・・，Ｎ）ごとに通知される帯域値ｒkを入力すると（ステップＳ７０１）、まず、この帯域値ｒkと、当該セッションｋの品質クラスｈに対応して記憶装置に記憶している定数ａh、同じく記憶装置に記憶している遅延ゆらぎ定数ｄと制御ゆらぎ定数ｅから、当該セッションｋの制御バーストサイズσ'hkを下記の式（１５）を用いて求める（ステップＳ７０２）。
【０１１４】
式（１５）：σ'hk＝ｒk×ａh×ｄ＋ｅ
【０１１５】
そして、リソース管理／受付判定機能１ｂは、算出した制御バーストサイズσ'hkと、セッション制御機能１ａから通知された帯域値ｒkをポリシー制御機能３に通知する（ステップＳ７０３）。
【０１１６】
以上、図１〜図７を用いて説明したように、本例では、ユーザ端末２からセッション制御機能１ａを介して帯域値のみが通知され、これに基づいたＱｏＳ確保を行う際に、積み上げ帯域値ｃkにおいて、品質クラスごとのバッフア時間を表す定数（品質クラスｈではＤh）、品質クラスごとのアプリケーションバーストサイズを表す定数（品質クラスｈでは定数ａh）を導入することによって、品質クラスごとにネットワークリソース管理を行うことができると共に、品質クラスごとに許可するバーストの大きさを考慮でき、高品質クラスにおいて大きなバーストを許可してしまい品質劣化が生じるという課題を回避することができる。
【０１１７】
また、本例では、トークンバケットパラメータのうち、トークンレートを通知される帯域値とし、バーストサイズを品質クラスごとに規定される比例係数、例えば品質クラスｈにおける定数ａhを用いて、一次式の形で計算する。このことにより、バーストサイズを定数で与えた場合に起こる、狭帯域の要求に対しては許可するバーストサイズが大きすぎ、広帯域の要求に対しては許可するバーストサイズが小さすぎるという課題を回避することができる。
【０１１８】
さらに、本例では、ＵＮIからポリシー制御ポイントまでの遅延ゆらぎを表す定数ｄと、制御ゆらぎを表す定数ｅをサービスネットワークで決められる定数として保持し、例えは一次式の形で新たに制御バーストサイズを計算する。このことによって、ＵＮＩ規定点とトラヒック監視ポイントが異なっている場合においてＵＮＩ規定点からトラヒック監視ポイントまでの遅延ゆらぎの影響により、規定内のトラヒックでも廃棄されてしまうという課題を回避することができる。
【０１１９】
尚、本発明は、図１〜図７を用いて説明した例に限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能である。例えば、本例では、リソース管理装置１やポリシー制御装置３をコンピュータ構成としても良いとしたが、この場合、キーボードや光ディスクの駆動装置の無いコンピュータ構成としても良い。また、記憶媒体として、光ディスクやＦＤ（Flexible Disk）等を用いることでも良い。また、プログラムのインストールに関しても、通信装置を介してネットワーク経由でプログラムをダウンロードしてインストールすることでも良い。
【０１２０】
また、本例では、予めユーザ端末２のユーザとの契約で当該ユーザ端末２からの要求帯域に対する品質クラス（ｈ）が決定されているものとしているが、ユーザ端末２からの帯域要求時に、その都度、品質クラス（ｈ）を決定することでも良い。
【０１２１】
また、本例では、ＵＮＩトラヒック規定に従ったポリシー制御を行っており、違反したトラヒックの扱いについては、廃棄または、ＤＳＣＰリマーキングをして下位優先度のサービスクラスに送るか廃棄優先度を高くして廃棄しやすくさせる方式を考えることができるが、本発明は、このポリシー制御方式に限定されるものではない。
【０１２２】
また、本例の適用例としては、ＩＰ電話ナービスや映像コミュニケーションサービス、ストリーミング配信等の、要求品質が厳しいサービスをアプリケーションとして利用することができ、従って、本発明は、これらアプリケーションに固有の技術、プロトコルによりその有効性が限定されるものではない。
【０１２３】
また、本例でのセッション制御を行うためのプロトコルとして、ＨＴＴＰ（Hyper Text Transfer Protocol）、ＳＩＰ、Ｈ．３２３等があるが、本発明は、これらのシグナリングにより、その有効性が限定されるものではない。
【図面の簡単な説明】
【０１２４】
【図１】本発明に係るトラヒック制御システムの構成例を示すブロック図である。
【図２】図１におけるトラヒック制御システムの動作原理を示す説明図である。
【図３】図１におけるリソース管理装置の第１の処理動作例を示すフローチャートである。
【図４】図１におけるリソース管理装置の第２の処理動作例を示すフローチャートである。
【図５】図１におけるリソース管理装置の第３の処理動作例を示すフローチャートである。
【図６】図１におけるリソース管理装置の第４の処理動作例を示すフローチャートである。
【図７】図１におけるリソース管理装置の第５の処理動作例を示すフローチャートである。
【図８】従来技術におけるトークンバケットから送出されるトラヒックの最悪パターンである極値ＯＮ／ＯＦＦ過程を示す説明図である。
【図９】従来技術におけるトークンバケットから送出されるトラヒック量とトークンバケットパラメータの関係を示す説明図である。
【図１０】従来技術におけるバッファ量と帯域の関係を示す説明図である。
【図１１】従来技術のキューイングシステムにおけるバッファ量と利用している帯域とそれぞれの時間の関係を示す説明図である。
【図１２】従来技術における仮想バッファ／トラヒックモデルの動作例を示す説明図である。
【符号の説明】
【０１２５】
１：リソース管理装置（ＱｏＳ管理装置）、１ａ：セッション制御機能（セッション制御部）、１ｂ：リソース管理／受付判定機能（リソース管理／受付判定部）、２：ユーザ端末、３：ポリシー制御装置、４：ＵＮＩ、５，６：ネットワーク。
【図１】
0004570586.tif 000002
【図２】
0004570586.tif 000003
【図３】
0004570586.tif 000004
【図４】
0004570586.tif 000005
【図５】
0004570586.tif 000006
【図６】
0004570586.tif 000007
【図７】
0004570586.tif 000008
【図８】
0004570586.tif 000009
【図９】
0004570586.tif 000010
【図１０】
0004570586.tif 000011
【図１１】
0004570586.tif 000012
【図１２】
0004570586.tif 000013