JP4570586B2 - トラヒック制御方法とシステムおよびプログラム - Google Patents

Description

本発明は、ＩＥＴＦ（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、b_h）を用いて、トークンレートr_kの一次式として計算することで求め（例σ_hk＝ｒ_k×ａ_h）、また、ピークレートＰ_kとして、ユーザ契約時に決定されるサービスネットワークの最大スループット（Ｐ）を用いる。

尚、バーストサイズは一般式として、σ_hk＝r_ｋ×a_ｈ＋ｂ_ｈと設定される。また、バーストサイズ係数(a_h,b_h)は、予めユーザ端末２のユーザとの契約で当該ユーザ端末２からの要求帯域に対する品質クラス（ｈ）が決定されているものとする。

さらに、従来の仮想リソース管理技術において積み上げ帯域の算出に用いる式（ｋ）におけるサービスネットワーク内のリソース量（バッファ量Ｂ_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）、ＳＩＰ、Ｈ．３２３等があるが、本発明は、これらのシグナリングにより、その有効性が限定されるものではない。

本発明に係るトラヒック制御システムの構成例を示すブロック図である。 図１におけるトラヒック制御システムの動作原理を示す説明図である。 図１におけるリソース管理装置の第１の処理動作例を示すフローチャートである。 図１におけるリソース管理装置の第２の処理動作例を示すフローチャートである。 図１におけるリソース管理装置の第３の処理動作例を示すフローチャートである。 図１におけるリソース管理装置の第４の処理動作例を示すフローチャートである。 図１におけるリソース管理装置の第５の処理動作例を示すフローチャートである。 従来技術におけるトークンバケットから送出されるトラヒックの最悪パターンである極値ＯＮ／ＯＦＦ過程を示す説明図である。 従来技術におけるトークンバケットから送出されるトラヒック量とトークンバケットパラメータの関係を示す説明図である。 従来技術におけるバッファ量と帯域の関係を示す説明図である。 従来技術のキューイングシステムにおけるバッファ量と利用している帯域とそれぞれの時間の関係を示す説明図である。 従来技術における仮想バッファ／トラヒックモデルの動作例を示す説明図である。

符号の説明

１：リソース管理装置（ＱｏＳ管理装置）、１ａ：セッション制御機能（セッション制御部）、１ｂ：リソース管理／受付判定機能（リソース管理／受付判定部）、２：ユーザ端末、３：ポリシー制御装置、４：ＵＮＩ、５，６：ネットワーク。

Claims (9)

1. トークンバケットモデルにおけるパラメータを用いて見なし帯域を求め、求めた見なし帯域の積み上げ処理結果と予め定められた使用上限帯域とを比較してサービスネットワークへの入力トラヒックに対する受付判定を行うシステムのトラヒック制御方法であって、
   セッションフローｋ（ｋ＝１，２，…，Ｎ）のトークンレートｒkを入力する第１のステップ、
   該入力されたトークンレートｒkと予め当該セッションフローの品質クラスｈに応じて設定され記憶装置に記憶された係数を用いて、一次式により当該セッションフローｋに対するバーストサイズσhkを求める第２のステップ、
   該求めたバーストサイズσhkと上記入力されたトークンレートｒk、および、予め設定され記憶装置に記憶された当該サービスネットワークの最大スループットＰと予め当該品質クラスｈに応じて設定され記憶装置に記憶された当該サービスネットワークにおけるバッファ時間定数Ｄhを用いて、下記の式（イ）で見なし帯域ｃhkを求める第３のステップ、
   該求めた見なし帯域chkと上記入力されたトークンレートｒkとを用いて、下記の式（ロ）で当該品質クラスｈの積み上げ処理結果shkを求める第４のステップ、
   該求めた品質クラスｈの積み上げ処理結果ｓhkと予め当該品質クラスｈに対応して定められた使用上限帯域とを比較し、積み上げ処理結果ｓhkが使用上限帯域以下の場合に受け付け可と判定し、使用上限帯域より大きい場合に受け付け不可と判定する第５のステップ
   を有することを特徴とするトラヒック制御方法。
   式（イ）： ｃhk＝Ｐ／［１＋｛Ｄh×（Ｐ−ｒk）｝／σhk］
   式（ロ）： ｓhk＝Σmax（ｒk，ｃhk）、 （ｋ＝１，２，…，Ｎ）
2. 請求項１に記載のトラヒック制御方法であって、
   予め当該セッションフローの品質クラスhに応じて設定され記憶装置に記憶されたバーストサイズ係数ａ_hを用いて
   式（ハ）： σ_hk＝ｒ_k×ａ_h
   により各品質クラス間でバーストサイズσ_hkを求めることを特徴とするトラヒック制御方法。
3. 請求項２に記載のトラヒック制御方法であって、
   バーストサイズ係数ａ_hと上記バッファ時間定数Ｄ_hを同じ値とし、
   上記式（イ）と上記式（ロ）の代わりに、下記の式（二）を用いて上記品質クラスｈの積み上げ処理結果ｓ_hkを求める第６のステップを有することを特徴とするトラヒック制御方法。
   式（二）： ｓ_hk＝Σ（ｒ_k）、 （ｋ＝１，２，…，Ｎ）
4. 請求項１から請求項３のいずれかに記載のトラヒック制御方法であって、
   予め当該品質クラスｈに対応して設定され記憶装置に記憶されたアプリケーションの帯域に依存しないバースト時間定数ｂ_hを上記求めたバーストサイズσ_hkに加算する第７のステップと、
   該バースト時間定数ｂ_hを加算したバーストサイズを上記式（イ）におけるバーストサイズσ_hkに代入して、上記見なし帯域c_ｈｋを求める第８のステップと
   を有することを特徴とするトラヒック制御方法。
5. 請求項１から請求項４のいずれかに記載のトラヒック制御方法であって、
   上記受け付け可と判定した場合、
   予め記憶装置に記憶された、サービスネットワークごとに決定されるＵＮＩからポリシー制御ポイントまでの遅延ゆらぎ定数ｄを上記求めたバーストサイズσ_hkに乗算して、ポリシー制御に用いる制御バーストサイズを求める第９のステップを有することを特徴とするトラヒック制御方法。
6. 請求項１から請求項５のいずれかに記載のトラヒック制御方法であって、
   上記受け付け可と判定した場合、
   予め記憶装置に記憶された、アプリケーションの帯域に依存しない制御ゆらぎ定数ｅを上記求めたバーストサイズσ_hkに加算して、ポリシー制御に用いる制御バーストサイズを求める第１０のステップを有することを特徴とするトラヒック制御方法。
7. コンピュータに、請求項１から請求項６のいずれかに記載のトラヒック制御方法における各ステップでの処理を実行させるためのプログラム。
8. トークンバケットモデルにおけるパラメータを用いて見なし帯域を求め、求めた見なし帯域の積み上げ処理結果と予め定められた使用上限帯域とを比較してサービスネットワークへの入力トラヒックに対する受付判定を行うトラヒック制御システムであって、
   請求項１におけるバーストサイズ係数ａ_hを含む各品質クラスごとに予め対応つけて設定されたバーストサイズ係数と、請求項１におけるバッファ時間定数Ｄ_hを含む各品質クラスごとに予め対応つけて設定されたバッファ時間定数、および、請求項１における最大スループットＰを記憶する記憶手段と、
   請求項１における上記第１のステップの処理を実行して上記トークンレートｒ_kを入力する手段と、
   請求項１における上記第２のステップの処理を実行して上記バーストサイズσ_hkを求める手段と、
   請求項１における上記第３のステップの処理を実行して上記見なし帯域ｃ_hkを求める手段と、
   請求項１における上記第４のステップの処理を実行して上記積み上げ処理結果ｓ_hkを求める手段と、
   請求項１における上記第５のステップの処理を実行して上記受け付け可否の判定を行う手段と
   を有することを特徴とするトラヒック制御システム。
9. 請求項８に記載のトラヒック制御システムであって、
   請求項２における上記第６のステップの処理を実行して上記積み上げ処理結果ｓ_hkを求める手段と、
   請求項４における上記バースト時間定数ｂ_hを含む各品質クラスごとに予め対応つけて設定されたバースト時間定数を記憶する記憶装置を具備すると共に上記第７のステップの処理を実行して上記バースト時間定数ｂ_hの上記求めたバーストサイズσ_hkへの加算を行う手段と、
   請求項４における上記第８のステップの処理を実行して上記見なし帯域ｃ_hkを求める手段と、
   請求項５における上記遅延ゆらぎ定数ｄを記憶する記憶装置を具備すると共に上記第９のステップの処理を実行して上記ポリシー制御に用いる制御バーストサイズを求める手段と、
   請求項６における上記制御ゆらぎ定数ｅを記憶する記憶装置を具備すると共に上記第１０のステップの処理を実行して上記ポリシー制御に用いる制御バーストサイズを求める手段の少なくともいずれか一つを有することを特徴とするトラヒック制御システム。

Images