JP4346032B2 - 品質保証サービスを実現する受付判定方法とトラヒック制御方法およびそのシステム - Google Patents
品質保証サービスを実現する受付判定方法とトラヒック制御方法およびそのシステム Download PDFInfo
- Publication number
- JP4346032B2 JP4346032B2 JP2005040024A JP2005040024A JP4346032B2 JP 4346032 B2 JP4346032 B2 JP 4346032B2 JP 2005040024 A JP2005040024 A JP 2005040024A JP 2005040024 A JP2005040024 A JP 2005040024A JP 4346032 B2 JP4346032 B2 JP 4346032B2
- Authority
- JP
- Japan
- Prior art keywords
- bandwidth
- link
- service providing
- session flow
- traffic
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Telephonic Communication Services (AREA)
Description
本発明は、ＵＮＩ（Ｕｓｅｒ−Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ）間の品質保証サービスを提供するための品質保証サービスを実現する受付判定方法およびトラヒック制御方法、ならびにそのシステムに関する。
ブロードバンド回線が低価格でユーザに提供されるようになり、インターネットは急激に普及してきている。それに伴って、様々なサービスがインターネットを介して提供されるようになり、その通信品質が重要視されるようになっている。特に、リアルタイムな映像、音声サービスに対してはネットワーク上におけるデータ転送品質が大きく影響するが、インターネットでは、そのデータ転送品質を保証する仕組みがないため、従来では、ＩＰ閉域網としてネットワークを構築し、データ転送品質を保証する技術と組み合わせて品質保証型のサービスを提供することが検討されている。
ＩＰ網においては、データ転送品質を保証するサービスモデルとして、主にＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋｆｏｒｃｅ）（標準化団体）で検討されたＩｎｔｓｅｒｖとＤｉｆｆｓｅｒｖに分けられる。
Ｉｎｔｓｅｒｖは、ネットワーク経路上の帯域を確保した上で、その確保した品質に応じたサービスを受けるモデルである。Ｉｎｔｓｅｒｖモデルでは、ｅｎｄ−ｔｏ−ｅｎｄでネットワーク経路上の帯域を予約するプロトコルであるＲＳＶＰ（Ｒｅｓｏｕｒｃｅ Ｒｅｓｅｒｖａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）を用いて、遅延、パケット損失率を厳密に保証するサービスクラス（Ｇｕａｒａｎｔｅｅｄ Ｓｅｒｖｉｃｅ）か、優先サービスクラス（Ｃｏｎｔｒｏｌｌｅｄ−ｌｏａｄ Ｓｅｒｖｉｃｅ）を提供する。
Ｉｎｔｓｅｒｖは、ネットワーク経路上の帯域を確保した上で、その確保した品質に応じたサービスを受けるモデルである。Ｉｎｔｓｅｒｖモデルでは、ｅｎｄ−ｔｏ−ｅｎｄでネットワーク経路上の帯域を予約するプロトコルであるＲＳＶＰ（Ｒｅｓｏｕｒｃｅ Ｒｅｓｅｒｖａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）を用いて、遅延、パケット損失率を厳密に保証するサービスクラス（Ｇｕａｒａｎｔｅｅｄ Ｓｅｒｖｉｃｅ）か、優先サービスクラス（Ｃｏｎｔｒｏｌｌｅｄ−ｌｏａｄ Ｓｅｒｖｉｃｅ）を提供する。
ＲＳＶＰリクエストはネットワーク内の各転送ノードによりフォワーディングされ、リクエストを受ける転送ノードは管理する帯域情報をもとにリクエストされるサービスが提供可能か否かを判断し、提供可能な場合にはｅｎｄ−ｔｏ−ｅｎｄで帯域を確保し、コネクションを確立させる。ＲＳＶＰリクエストはトークンバケットモデルに従ったトラヒック規定を含んでおり、トークンバケットパラメータに従った帯域確保を行なう。
しかしながら、品質保証型のサービスを提供するためには、ＲＳＶＰを用いたＩｎｔｓｅｒｖでは、ネットワーク転送ノードにおいて、ＲＳＶＰに関連する情報を全てリアルタイムに管理し、かつパケット転送を行う必要があるため、統一された受付判定を行わなければならないという課題と、サービスプロバイダはネットワーク内のリソースに応じて提供できる転送品質を規定し、これを監視しなければならないという課題がある（例えば、Ｓ．Ｓｈｅｎｋｅｒ，ａｎｄ Ｊ．Ｗｒｏｃｌａｗｓｋｉ，“Ｇｅｎｅｒａｌ Ｃｈａｒａｃｔｅｒｉｚａｔｉｏｎ Ｐａｒａｍｅｔｅｒｓ ｆｏｒ Ｉｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅ Ｎｅｔｗｏｒｋ Ｅｌｅｍｅｎｔｓ，”Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ ＲＦＣ２２１５，Ｓｅｐ．１９９７（ｐｐ．７〜ｐｐ．１１）（非特許文献１参照）、Ｊ．Ｗｒｏｃｌａｗｓｋｉ，“Ｓｐｅｃｉｆｉｃａｔｉｏｎ ｏｆ ｔｈｅ Ｃｏｎｔｒｏｌｌｅｄ−Ｌｏａｄ Ｎｅｔｗｏｒｋ Ｅｌｅｍｅｎｔ Ｓｅｒｖｉｃｅ，”Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ，ＲＦＣ２２１１，Ｓｅｐ．１９９７（ｐｐ．２〜ｐｐ．４）（非特許文献２参照）。および、Ｓ．Ｓｈｅｎｋｅｒ Ｃ．Ｐａｒｔｒｉｄｇｅ，ａｎｄ Ｒ． Ｇｕｅｒｉｎ，“Ｓｐｅｃｉｆｉｃａｔｉｏｎ ｏｆ Ｇｕａｒａｎｔｅｅｄ Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ，”Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ，ＲＦＣ２２１２，Ｓｅｐ．１９９７（ｐｐ．３〜ｐｐ．４）（非特許文献３参照））。
しかしながら、品質保証型のサービスを提供するためには、ＲＳＶＰを用いたＩｎｔｓｅｒｖでは、ネットワーク転送ノードにおいて、ＲＳＶＰに関連する情報を全てリアルタイムに管理し、かつパケット転送を行う必要があるため、統一された受付判定を行わなければならないという課題と、サービスプロバイダはネットワーク内のリソースに応じて提供できる転送品質を規定し、これを監視しなければならないという課題がある（例えば、Ｓ．Ｓｈｅｎｋｅｒ，ａｎｄ Ｊ．Ｗｒｏｃｌａｗｓｋｉ，“Ｇｅｎｅｒａｌ Ｃｈａｒａｃｔｅｒｉｚａｔｉｏｎ Ｐａｒａｍｅｔｅｒｓ ｆｏｒ Ｉｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅ Ｎｅｔｗｏｒｋ Ｅｌｅｍｅｎｔｓ，”Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ ＲＦＣ２２１５，Ｓｅｐ．１９９７（ｐｐ．７〜ｐｐ．１１）（非特許文献１参照）、Ｊ．Ｗｒｏｃｌａｗｓｋｉ，“Ｓｐｅｃｉｆｉｃａｔｉｏｎ ｏｆ ｔｈｅ Ｃｏｎｔｒｏｌｌｅｄ−Ｌｏａｄ Ｎｅｔｗｏｒｋ Ｅｌｅｍｅｎｔ Ｓｅｒｖｉｃｅ，”Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ，ＲＦＣ２２１１，Ｓｅｐ．１９９７（ｐｐ．２〜ｐｐ．４）（非特許文献２参照）。および、Ｓ．Ｓｈｅｎｋｅｒ Ｃ．Ｐａｒｔｒｉｄｇｅ，ａｎｄ Ｒ． Ｇｕｅｒｉｎ，“Ｓｐｅｃｉｆｉｃａｔｉｏｎ ｏｆ Ｇｕａｒａｎｔｅｅｄ Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ，”Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ，ＲＦＣ２２１２，Ｓｅｐ．１９９７（ｐｐ．３〜ｐｐ．４）（非特許文献３参照））。
一方、Ｄｉｆｆｓｅｒｖは、ネットワーク内において転送パケットにマーキングすることにより、クラス分けを行い、ネットワーク転送ノードにおけるパケットスケジューリングにより、クラスごとの転送品質の差異化を行なうモデルである。Ｄｉｆｆｓｅｒｖモデルでは、規定されたＰＨＢ（Ｐｅｒ−Ｈｏｐ Ｂｅｈａｖｉｏｒ）により各ネットワーク転送ノードでの転送品質が確保される。サービスクラスに対応するＰＨＢは完全優先であるＥＦ（Ｅｘｐｅｄｉｔｅｄ Ｆｏｒｗａｒｄｉｎｇ）、最低帯域保証であるＡＦ（Ａｓｓｕｒｅｄ Ｆｏｒｗａｒｄｉｎｇ）が規定されており、市販のネットワーク転送ノードにも実装が進んでいる。
Ｄｉｆｆｓｅｒｖでは、ネットワーク転送ノードごとの転送品質を差異化し、各転送ノードでの制御のみを規定するだけであるため、Ｉｎｔｓｅｒｖにおけるスケールしないという課題を解決する。しかしながら、品質保証型のサービスを提供するためには、サービス提供網内で統一された利用帯域に関する受付判定を行わなければならないという課題と、サービスプロバイダはネットワーク内のリソースに応じて提供できる転送品質を規定し、これを監視しなければならないという課題は、依然として残っている（例えば、Ｓ．Ｂｌａｋｅ，Ｄ．Ｂｌａｃｋ，Ｍ．Ｃａｒｌｓｏｎ， ａｎｄ Ｅ．Ｄａｖｉｅｓ， Ｚ．Ｗａｎｇ，Ｗ．Ｗｅｉｓｓ“Ａｎ Ａｒｃｈｉｔｅｃｔｕｒｅ ｆｏｒ Ｄｉｆｆｅｒｅｎｔｉａｔｅｄ Ｓｅｒｖｉｃｅ，”Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ，ＲＦＣ ２４７５，Ｄｅｃ．１９９８（ｐｐ．８〜ｐｐ．１１）または（ｐｐ．２０〜ｐｐ．２４）（非特許文献４参照）。Ｂ．Ｄａｖｉｅ，Ａ．Ｃｈａｒｎｙ， Ｊ．Ｃ．Ｒ．Ｂｅｎｎｅｔｔ，Ｋ．Ｂｅｎｓｏｎ，Ｊ．Ｙ．ＬｅＢｏｕｄｅｃ，Ｗ．Ｃｏｕｒｔｎｅｙ，Ｓ．Ｄａｖａｒｉ，Ｖ．Ｆｉｒｏｉｕ，ａｎｄ Ｄ．Ｓｔｉｌｉａｄｉｓ，“Ａｎ Ｅｘｐｅｄｉｔｅｄ Ｆｏｒｗａｒｄｉｎｇ ＰＨＢ（Ｐｅｒ−Ｈｏｐ Ｂｅｈａｖｉｏｒ），”Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ，ＲＦＣ３２４６，Ｍａｒ．２００２（ｐｐ．２−ｐｐ．８）（非特許文献５参照）。
Ｊ．Ｈｅｉｎａｎｅｎ，Ｆ．Ｂａｋｅｒ，Ｗ．Ｗｅｉｓｓ．ａｎｄ Ｊ．Ｗｒｏｃｌａｗｓｋｉ，“Ａｓｓｕｒｅｄ Ｆｏｒｗａｒｄｉｎｇ ＰＨＢ Ｇｒｏｕｐ，”ＩｎｔｅｒｎｅｔＥｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ，ＲＦＣ２５９７，Ｊｕｎ １９９９（ｐｐ．２−ｐｐ．３）（非特許文献６参照）。）
Ｊ．Ｈｅｉｎａｎｅｎ，Ｆ．Ｂａｋｅｒ，Ｗ．Ｗｅｉｓｓ．ａｎｄ Ｊ．Ｗｒｏｃｌａｗｓｋｉ，“Ａｓｓｕｒｅｄ Ｆｏｒｗａｒｄｉｎｇ ＰＨＢ Ｇｒｏｕｐ，”ＩｎｔｅｒｎｅｔＥｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ，ＲＦＣ２５９７，Ｊｕｎ １９９９（ｐｐ．２−ｐｐ．３）（非特許文献６参照）。）
サービス提供品質の規定に関してはＩＴＵ−Ｔ（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｕｎｉｏｎ−Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ ｒｅｍｍｅｎｄａｔｉｏｎ）において、サービス品質を規定するためのパラメータ定義、転送品質クラス規定、サービスモデルが勧告化されている。しかしながら、ＩＴＵ−Ｔ勧告Ｙ．１５４１における規定された転送品質をＹ．１２２１におけるサービスモデルで実現する方法に関しては、検討されておらず、サービスプロバイダはネットワーク内のリソースに応じて提供できる転送品質を規定し、これを監視しなければならないという課題が依然として残る（例えば、ＩＴＵ−Ｔ勧告Ｙ．１５４１（ｐｐ．５−ｐｐ．６）（非特許文献７参照）。ＩＴＵ−Ｔ勧告Ｙ．１２２１（ｐｐ．６−ｐｐ．７）（非特許文献８参照）。）。
利用帯域に関する受付判定モデルとしては、トークンバケットパラメータに従ったネットワークへの入力トラヒックに対して受付判定を行う，仮想バッファ／トランクモデルがある。仮想バッファ／トランクモデルでは、トークンバケットモデルに従ったトラヒックの最悪条件をＯＮ／ＯＦＦトラヒックとしてモデル化し、申告帯域に対して、比例したバッファ量を仮想的に割り当てることによって、ネットワーク帯域を管理する帯域管理サーバによる各ネットワーク転送ノードのバッファ量を考慮した実効帯域（Ｅｆｆｅｃｔｉｖｅ Ｂａｎｄｗｉｄｔｈ）の積み上げ管理を以下の考え方に基づいて行い、論理的パケット損失率ゼロの受付判定を行う。
（トークンバケットから送出されるトラヒックの最悪条件）
トークンバケットで規定されるトラヒックに関しては、図３に示す極値ＯＮ／ＯＦＦ過程（Ｔｏｎの期間はピークレートＰでパケットを送出し、Ｔｏｆｆの期間はパケットを送出しない）が最悪条件と考えられる。すなわち、極値ＯＮ／ＯＦＦ過程はトークンバケットから送出されるトラヒックパターンの中では、ネットワークに対して最も負荷が大きく、極値ＯＮ／ＯＦＦ過程でのトラヒックパターンの受付判定で、論理的パケットロス率がゼロである条件を満足すれば、そのほかのトラヒックパターンにおいても論理的パケットロス率がゼロである条件を十分満足する。時刻０からｔまでの間にトークンバケットから送出されるトラヒック量Ω（ｔ）とトークンバケットパラメータ（トークンレートｒ，バケットサイズσ，ピークレートＰ）、およびＴｏｎ，Ｔｏｆｆの関係は図４に示すように表わすことができ、図１、図２の関係から極値ＯＮ／ＯＦＦ過程におけるＴｏｎ，Ｔｏｆｆはトークンバケットパラメータで表わすことができ、次式（１）（２）で表わされる。
トークンバケットで規定されるトラヒックに関しては、図３に示す極値ＯＮ／ＯＦＦ過程（Ｔｏｎの期間はピークレートＰでパケットを送出し、Ｔｏｆｆの期間はパケットを送出しない）が最悪条件と考えられる。すなわち、極値ＯＮ／ＯＦＦ過程はトークンバケットから送出されるトラヒックパターンの中では、ネットワークに対して最も負荷が大きく、極値ＯＮ／ＯＦＦ過程でのトラヒックパターンの受付判定で、論理的パケットロス率がゼロである条件を満足すれば、そのほかのトラヒックパターンにおいても論理的パケットロス率がゼロである条件を十分満足する。時刻０からｔまでの間にトークンバケットから送出されるトラヒック量Ω（ｔ）とトークンバケットパラメータ（トークンレートｒ，バケットサイズσ，ピークレートＰ）、およびＴｏｎ，Ｔｏｆｆの関係は図４に示すように表わすことができ、図１、図２の関係から極値ＯＮ／ＯＦＦ過程におけるＴｏｎ，Ｔｏｆｆはトークンバケットパラメータで表わすことができ、次式（１）（２）で表わされる。
（極値ＯＮ／ＯＦＦ過程トラヒックが使用するリソース量（ｂ，ｃ）の特性）
図５に示すように、トークンバケットから送出された１本のセッションフローが確定的なキューイングシステムにおいてサービスされることを考える。
ｖ（ｔ）を時刻ｔにおけるバッファ量，ｂを使用するバッファ量の最大値，ｕ（ｔ）を時刻ｔにおける利用帯域，ｃを利用可能な最大帯域とする。図６に示す“キューイングシステムのバッファ量と滞留している時間”と“キューイングシステムにおいて利用している帯域とその時間”との関係に着目すると、このキューイングシステムサービス窓口でのｂｕｓｙ ｐｅｒｉｏｄ Ｄｏｎとｉｄｌｅ ｐｅｒｉｏｄ Ｄｏｆｆとの関係は、次式（３）（４）で表わされる。
図５に示すように、トークンバケットから送出された１本のセッションフローが確定的なキューイングシステムにおいてサービスされることを考える。
ｖ（ｔ）を時刻ｔにおけるバッファ量，ｂを使用するバッファ量の最大値，ｕ（ｔ）を時刻ｔにおける利用帯域，ｃを利用可能な最大帯域とする。図６に示す“キューイングシステムのバッファ量と滞留している時間”と“キューイングシステムにおいて利用している帯域とその時間”との関係に着目すると、このキューイングシステムサービス窓口でのｂｕｓｙ ｐｅｒｉｏｄ Ｄｏｎとｉｄｌｅ ｐｅｒｉｏｄ Ｄｏｆｆとの関係は、次式（３）（４）で表わされる。
以上の表現を用いてキューイングシステムにおけるｂｕｓｙ ｐｅｒｉｏｄである時間の割合を（３），（４）式を用いて表わすと、次式（５）が成立する。
（仮想バッファ／トランクモデル）
今、トークンバケットパラメータ（ｒｋ，σｋ，Ｐｋ）を持つセッションフローｋ（ｋ＝１，２，・・，ｋ）がリソース（バッファ量Ｂｉｊ，リンク帯域Ｃｉｊ）を持つノードｉからノードｊへ至るリンクｉｊに多重されることを考える。このとき、図７に示すように各セッションフローｋに対してリンク帯域ｃｋ（ｒｋ≦ｃｋ≦Ｐｋ）を仮想的に割り当てることを考える。ただし、仮想リソースの総量はリンク帯域Ｃを上回らないようにする。すなわち、
今、トークンバケットパラメータ（ｒｋ，σｋ，Ｐｋ）を持つセッションフローｋ（ｋ＝１，２，・・，ｋ）がリソース（バッファ量Ｂｉｊ，リンク帯域Ｃｉｊ）を持つノードｉからノードｊへ至るリンクｉｊに多重されることを考える。このとき、図７に示すように各セッションフローｋに対してリンク帯域ｃｋ（ｒｋ≦ｃｋ≦Ｐｋ）を仮想的に割り当てることを考える。ただし、仮想リソースの総量はリンク帯域Ｃを上回らないようにする。すなわち、
実際のバッファ使用量の最大値ｂは、仮想バッファ使用量の和Σｂｋを上回ることはないので、次式（９）が成り立てば、論理的なパケットロスがゼロになる。
この方式では、一般的にバッファ量とリンク帯域という２種類のリソース使用量を管理しなければならないが、（ｂｋ，ｃｋ）が下式（１０）を満たせば、バッファ使用量＝リンク使用帯域となるため、どちらか一つのリソース管理を行うだけでよい。
この場合、上式（８）および上式（１０）から仮想リンク帯域ｃｋは、下式（１１）となる。
しかしながら、サービス提供網内のリソース（バッファ量Ｂｉｊ，リンク帯域Ｃｉｊ）をあらかじめ見積もる必要があるという課題と、実効帯域ｅｋ，ｉｊはトークンバケットパラメータに依存し、さらにサービス提供網において経由する全てのリンクにおけるリンク帯域とバッファ量に依存するため、実効帯域ｅｋ，ｉｊを積み上げ帯域として受付判定を行う仮想バッファ／トランクモデルは、論理的パケットロスをゼロにすることはできるが、各リンクごとに実効帯域ｅｋ，ｉｊを計算するためスケールしないという課題と、申告されるトークンバケットパラメータ（ｒｋ，σｋ，Ｐｋ）の組み合わせによっては、実効帯域ｅｋ，ｉｊが極端に大きくなり、サービス提供網における収容率が下がるという課題と、トークンバケットパラメータ（ｒｋ，σｋ，Ｐｋ）の全てを自由に指定することを許可するため、パラメータ数が多く、管理が煩雑になるという課題とがある（例えば、Ａ．Ｅｌｗａｌｉｄ，Ｄ．Ｍｉｔｒａ，ａｎｄ Ｒ．Ｈ．Ｗｅｎｔｗｏｒｔｈ，“Ａ Ｎｅｗ Ａｐｐｒｏａｃｈ ｆｏｒ Ａｌｌｏｃａｔｉｎｇ Ｂｕｆｆｅｒｓ ａｎｄ Ｂａｎｄｗｉｄｔｈ ｔｏ Ｈｅｔｒｏｇｅｎｅｏｕｓ，Ｒｅｇｕｌａｔｅｄ Ｔｒａｆｆｉｃ ｉｎ ａｎ ＡＴＭ ｎｏｄｅ，”ＩＥＥＥ Ｊｏｕｒｎａｌ ｏｎ Ｓｅｌｅｃｔｅｄ Ａｒｅａｓ ｉｎ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ，１３（６）：１１１５−１１２７，Ａｕｇ．１９９５．（非特許文献９参照））。
ＩｎｔｓｅｒｖまたはＤｉｆｆｓｅｒｖまたはＩＴＵ−Ｔ勧告Ｙ．１２２１サービスモデルに仮想バッファ／トランクモデルを適用することにより、Ｉｎｔｓｅｒｖ，Ｄｉｆｆｓｅｒｖのサービス提供網内で統一された受付判定を行なわなければならないという課題は、解決可能である。
しかしながら、品質保証型のサービスを提供するためには、仮想バッファ／トランクモデルにおける課題が残っており、さらに、Ｉｎｔｓｅｒｖ，Ｄｉｆｆｓｅｒｖ，ＩＴＵ−Ｔ勧告Ｙ．１２２１における，サービスプロバイダはネットワーク内のリソースに応じて提供できる転送品質を規定し、これを監視しなければならないという課題が依然として残る。
しかしながら、品質保証型のサービスを提供するためには、仮想バッファ／トランクモデルにおける課題が残っており、さらに、Ｉｎｔｓｅｒｖ，Ｄｉｆｆｓｅｒｖ，ＩＴＵ−Ｔ勧告Ｙ．１２２１における，サービスプロバイダはネットワーク内のリソースに応じて提供できる転送品質を規定し、これを監視しなければならないという課題が依然として残る。
Ｓ．Ｓｈｅｎｋｅｒ，ａｎｄ Ｊ．Ｗｒｏｃｌａｗｓｋｉ，"Ｇｅｎｅｒａｌ Ｃｈａｒａｃｔｅｒｉｚａｔｉｏｎ Ｐａｒａｍｅｔｅｒｓ ｆｏｒ Ｉｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅ Ｎｅｔｗｏｒｋ Ｅｌｅｍｅｎｔｓ，"Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ ＲＦＣ２２１５，Ｓｅｐ．１９９７（ｐｐ．７〜ｐｐ．１１）
Ｊ．Ｗｒｏｃｌａｗｓｋｉ，"Ｓｐｅｃｉｆｉｃａｔｉｏｎ ｏｆ ｔｈｅ Ｃｏｎｔｒｏｌｌｅｄ−Ｌｏａｄ Ｎｅｔｗｏｒｋ Ｅｌｅｍｅｎｔ Ｓｅｒｖｉｃｅ，"Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ，ＲＦＣ２２１１，Ｓｅｐ．１９９７（ｐｐ．２〜ｐｐ．４）
Ｓ．Ｓｈｅｎｋｅｒ Ｃ．Ｐａｒｔｒｉｄｇｅ，ａｎｄ Ｒ． Ｇｕｅｒｉｎ，"Ｓｐｅｃｉｆｉｃａｔｉｏｎ ｏｆ Ｇｕａｒａｎｔｅｅｄ Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ，"Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ，ＲＦＣ２２１２，Ｓｅｐ．１９９７（ｐｐ．３〜ｐｐ．４）
Ｓ．Ｂｌａｋｅ，Ｄ．Ｂｌａｃｋ，Ｍ．Ｃａｒｌｓｏｎ， ａｎｄ Ｅ．Ｄａｖｉｅｓ， Ｚ．Ｗａｎｇ，Ｗ．Ｗｅｉｓｓ"Ａｎ Ａｒｃｈｉｔｅｃｔｕｒｅ ｆｏｒ Ｄｉｆｆｅｒｅｎｔｉａｔｅｄ Ｓｅｒｖｉｃｅ，"Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ，ＲＦＣ ２４７５，Ｄｅｃ．１９９８（ｐｐ．８〜ｐｐ．１１）または（ｐｐ．２０〜ｐｐ．２４）。
Ｂ．Ｄａｖｉｅ，Ａ．Ｃｈａｒｎｙ， Ｊ．Ｃ．Ｒ．Ｂｅｎｎｅｔｔ，Ｋ．Ｂｅｎｓｏｎ，Ｊ．Ｙ．ＬｅＢｏｕｄｅｃ，Ｗ．Ｃｏｕｒｔｎｅｙ，Ｓ．Ｄａｖａｒｉ，Ｖ．Ｆｉｒｏｉｕ，ａｎｄ Ｄ．Ｓｔｉｌｉａｄｉｓ，"Ａｎ Ｅｘｐｅｄｉｔｅｄ Ｆｏｒｗａｒｄｉｎｇ ＰＨＢ（Ｐｅｒ−Ｈｏｐ Ｂｅｈａｖｉｏｒ），"Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ，ＲＦＣ３２４６，Ｍａｒ．２００２（ｐｐ．２−ｐｐ．８）。
Ｊ．Ｈｅｉｎａｎｅｎ，Ｆ．Ｂａｋｅｒ，Ｗ．Ｗｅｉｓｓ．ａｎｄ Ｊ．Ｗｒｏｃｌａｗｓｋｉ，"Ａｓｓｕｒｅｄ Ｆｏｒｗａｒｄｉｎｇ ＰＨＢ Ｇｒｏｕｐ，"ＩｎｔｅｒｎｅｔＥｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ，ＲＦＣ２５９７，Ｊｕｎ １９９９（ｐｐ．２−ｐｐ．３）
ＩＴＵ−Ｔ勧告Ｙ．１５４１（ｐｐ．５−ｐｐ．６）
ＩＴＵ−Ｔ勧告Ｙ．１２２１（ｐｐ．６−ｐｐ．７）
Ａ．Ｅｌｗａｌｉｄ，Ｄ．Ｍｉｔｒａ，ａｎｄ Ｒ．Ｈ．Ｗｅｎｔｗｏｒｔｈ，"Ａ Ｎｅｗ Ａｐｐｒｏａｃｈ ｆｏｒ Ａｌｌｏｃａｔｉｎｇ Ｂｕｆｆｅｒｓ ａｎｄ Ｂａｎｄｗｉｄｔｈ ｔｏ Ｈｅｔｒｏｇｅｎｅｏｕｓ，Ｒｅｇｕｌａｔｅｄ Ｔｒａｆｆｉｃ ｉｎ ａｎ ＡＴＭ ｎｏｄｅ，"ＩＥＥＥ Ｊｏｕｒｎａｌ ｏｎ Ｓｅｌｅｃｔｅｄ Ａｒｅａｓ ｉｎ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ，１３（６）：１１１５−１１２７，Ａｕｇ．１９９５．
前述のように、ユーザ網内装置からサービス提供網に流入するセッションフローのトラヒック特性をトークンバケットモデル（リーキーバケットモデル）によりＵＮＩトラヒック規定し、ＵＮＩ間品質保証を提供するサービス提供網において、１）仮想バッファ／トランクモデルの、あらかじめサービス提供網内の各ネットワーク転送ノードのリンクにおけるバッファ量を見積もる必要があるという課題があり、また、２）サービス提供網では、ネットワーク内の各リンクごとに実効帯域を計算する必要があるため、スケールしないという課題があり、また、３）ユーザが帯域要求時にトークンバケットパラメータである，トークンレート、バーストサイズ、ピークレートを全て自由に指定することを許可するため、サービス提供網における収容率が上がらないという課題があり、また、４）帯域要求時のサービス提供網側でのパラメータ管理が煩雑になるという課題があった。
（目的）
本発明の目的は、上記１）〜４）の課題を解決し、従来の品質保証型サービスモデルである，Ｉｎｔｓｅｒｖ，Ｄｉｆｆｓｅｒｖ，ＩＴＵ−Ｔ勧告Ｙ．１２２１におけるサービスプロバイダはネットワーク内のリソースに応じて提供できる転送品質を規定し、これを監視しなければならないという課題を解決することが可能な品質保証サービスを実現する受付判定方法およびトラヒック制御方法、ならびにそのシステムを提供することにある。
本発明の目的は、上記１）〜４）の課題を解決し、従来の品質保証型サービスモデルである，Ｉｎｔｓｅｒｖ，Ｄｉｆｆｓｅｒｖ，ＩＴＵ−Ｔ勧告Ｙ．１２２１におけるサービスプロバイダはネットワーク内のリソースに応じて提供できる転送品質を規定し、これを監視しなければならないという課題を解決することが可能な品質保証サービスを実現する受付判定方法およびトラヒック制御方法、ならびにそのシステムを提供することにある。
図１は、本発明による品質保証サービスを実現する受付判定システムの基本構成図であり、図２は本発明において、集線を行わないリンクを受付判定対象外とすることの説明図である。
本発明のサービス提供網の受付判定システムは、図１に示すユーザからの帯域要求に対して受付を行う帯域管理サーバＳと、帯域管理サーバＳに帯域要求やパラメータを送信する際の仲介をするサービス制御サーバＳＳと、ゲートウェイルータＧＷと、コアルータＲで構成されたサービス提供網Ｎに、ユーザ網Ｕ１，Ｕ２におけるターミナル装置（ただし、ターミナル装置は端末、ルータ、スイッチ、サーバ等を指す）ＴＥから流入するセッションフローのトラヒック特性をトークンバケットモデル（リーキーバケットモデル）によりＵＮＩトラヒック規定し、ＵＮＩ間品質保証を提供する。なお、図１において、Ｎはサービス提供網Ｎ、Ｕ１，Ｕ２はユーザ網である。ユーザ網Ｕ１，Ｕ２のターミナル装置ＴＥから帯域管理サーバＳに対して帯域要求が行われると、それに応じてサーバＳから回答がターミナル装置ＴＥに回答が送られる。
帯域管理サーバＳは、コンピュータ制御により該帯域管理サーバ内のリソースデータベースにおけるサービス提供網Ｎ内の各転送ノードの接続情報、リンクリソース情報（ノードｉからノードｊへのリンクｉｊにおけるリンク帯域Ｃｉｊ、バッファ量Ｂｉｊ）を管理し、また、帯域管理サーバＳは、該帯域管理サーバ内のリソースデータベースまたは受付判定部の演算回路を動作して種々の演算を実行する。
本発明のサービス提供網の受付判定システムは、図１に示すユーザからの帯域要求に対して受付を行う帯域管理サーバＳと、帯域管理サーバＳに帯域要求やパラメータを送信する際の仲介をするサービス制御サーバＳＳと、ゲートウェイルータＧＷと、コアルータＲで構成されたサービス提供網Ｎに、ユーザ網Ｕ１，Ｕ２におけるターミナル装置（ただし、ターミナル装置は端末、ルータ、スイッチ、サーバ等を指す）ＴＥから流入するセッションフローのトラヒック特性をトークンバケットモデル（リーキーバケットモデル）によりＵＮＩトラヒック規定し、ＵＮＩ間品質保証を提供する。なお、図１において、Ｎはサービス提供網Ｎ、Ｕ１，Ｕ２はユーザ網である。ユーザ網Ｕ１，Ｕ２のターミナル装置ＴＥから帯域管理サーバＳに対して帯域要求が行われると、それに応じてサーバＳから回答がターミナル装置ＴＥに回答が送られる。
帯域管理サーバＳは、コンピュータ制御により該帯域管理サーバ内のリソースデータベースにおけるサービス提供網Ｎ内の各転送ノードの接続情報、リンクリソース情報（ノードｉからノードｊへのリンクｉｊにおけるリンク帯域Ｃｉｊ、バッファ量Ｂｉｊ）を管理し、また、帯域管理サーバＳは、該帯域管理サーバ内のリソースデータベースまたは受付判定部の演算回路を動作して種々の演算を実行する。
（請求項１，３について）
本発明のサービス提供網の帯域管理サーバでは、ＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）、ＣＯＰＳ等のネットワーク管理プロトコルまたはポリシー管理プロトコル等の手段により、サービス提供網内の各転送ノードにおけるＩＦの接続情報、リンク帯域、ＩＦにおけるバッファ量を取得、または設定を行う。さらに、取得、設定した（Ｃｉｊ，Ｂｉｊ）の値を用いて以下の各リンクｉｊでの許容遅延量Ｄｉｊを計算する。
本発明のサービス提供網の帯域管理サーバでは、ＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）、ＣＯＰＳ等のネットワーク管理プロトコルまたはポリシー管理プロトコル等の手段により、サービス提供網内の各転送ノードにおけるＩＦの接続情報、リンク帯域、ＩＦにおけるバッファ量を取得、または設定を行う。さらに、取得、設定した（Ｃｉｊ，Ｂｉｊ）の値を用いて以下の各リンクｉｊでの許容遅延量Ｄｉｊを計算する。
Ｄｉｊは、サービス提供網内の各ＩＦのリンク帯域、バッファ量に依存した値であるため、この値を含んでいる従来の式（１１）における実効帯域ｅｋ，ｉｊは各リンクごとに異なった値となり、受付判定を行うためには、各リンクごとに積み上げ帯域を計算しなくてはならない。
ここで、本発明では、論理的パケットロスをゼロとする条件を変えずに、実効帯域ｅｋ，ｉｊをリンクごとのリソース量により変化しない実効帯域を求める。そのためには、単純にＤｉｊを変化させたときの実効帯域ｅｋ，ｉｊの最大値を実効帯域とみなすことで安全側の判定となり、論理的パケットロスをゼロとする条件は変わらない。この場合、式（１１）からＤｉｊの最小値を用いることになる。ただし、サービス提供網のリンクの中には、ネットワークの構成上集線をしないために転送待ちが発生せず、受付判定を必要としないリンクも存在する。そのようなリンクでは、通常、Ｄｉｊの値は小さく、そのため単純にＤｉｊの最小値をとると、そのような受付判定の対象とならないリンクを選んでしまい、収容効率が必要以上に悪くなってしまう。そこで、Ｄｉｊの最小値を計算する際のリンクの集合を以下の方法で計算する。
ここで、本発明では、論理的パケットロスをゼロとする条件を変えずに、実効帯域ｅｋ，ｉｊをリンクごとのリソース量により変化しない実効帯域を求める。そのためには、単純にＤｉｊを変化させたときの実効帯域ｅｋ，ｉｊの最大値を実効帯域とみなすことで安全側の判定となり、論理的パケットロスをゼロとする条件は変わらない。この場合、式（１１）からＤｉｊの最小値を用いることになる。ただし、サービス提供網のリンクの中には、ネットワークの構成上集線をしないために転送待ちが発生せず、受付判定を必要としないリンクも存在する。そのようなリンクでは、通常、Ｄｉｊの値は小さく、そのため単純にＤｉｊの最小値をとると、そのような受付判定の対象とならないリンクを選んでしまい、収容効率が必要以上に悪くなってしまう。そこで、Ｄｉｊの最小値を計算する際のリンクの集合を以下の方法で計算する。
サービス提供網内の全てのリンクの集合Ａの中で、転送ノードｎに直接接続されているリンクでノードｎより他ノードに至るリンクの集合をＳ（ｎ，Ｏ）、他ノードよりノードｎに至るリンクの集合をＳ（ｎ，Ｉ）とする。このとき、一回目の手順として、以下の条件を満たすリンクの集合を求める。
さらに、リンクｉｊによりノードｊへ至るトラヒックの最大帯域をＣｉｊとみなすのは過大であり、実際には、Σｈｉ∈Ｓ（ｉ，Ｉ）−｛ｊｉ｝Ｃｈｉで抑えられるため、ノードｊに至るリンクの集合からリンクｉｊを除外し、代わりにＳ（ｉ，Ｉ）−｛ｊｉ｝に含まれるリンクを加える。すなわち、下式（１５）とする。
ここでは、最終的に求められたサービス提供網内のリンクの集合を次式（１６）とし、
以上に計算されたＤｍｉｎは、受付判定の対象となるリンクにおけるＤｉｊの中で最小となるため、サービス提供網内で統一的な値として用いる。この値を用いた次式（１８）の実効帯域を計算し、
セッションフローｋが経由するリンクｉｊにおける受付判定
（請求項２，４，５について）
さらに、収容効率を考えると、上式（１９）で計算されるｅｋはトークンレートｒｋよりも大きく、ピークレートＰｋよりも小さい値であるため、ｅｋ＝ｒｋとなる場合が一番収容効率が良い。従って、次式（２０）となる。
さらに、収容効率を考えると、上式（１９）で計算されるｅｋはトークンレートｒｋよりも大きく、ピークレートＰｋよりも小さい値であるため、ｅｋ＝ｒｋとなる場合が一番収容効率が良い。従って、次式（２０）となる。
従って、セッションフローｋのパラメータσｋ，ｒｋおよびネットワークリソース量（Ｃｉｊ，Ｂｉｊ）から計算された固定値Ｄｍｉｎが式（２０）を満たすとき、セッションフローｋの実効帯域はトークンレートｒｋに等しくなる。
上式（２１）は、セッションフローのトークンパラメータが任意の値を取り得る場合には必ずしも成り立たないが、ＵＮＩでセッションフローｋのトークンバケットパラメータに関して規定できるのであれば、上式（２０）を満たすように（バーストサイズσを規定するように）することで収容効率を最大化することができる。具体的な手続きとしては、以下に述べる通りである。
上式（２１）は、セッションフローのトークンパラメータが任意の値を取り得る場合には必ずしも成り立たないが、ＵＮＩでセッションフローｋのトークンバケットパラメータに関して規定できるのであれば、上式（２０）を満たすように（バーストサイズσを規定するように）することで収容効率を最大化することができる。具体的な手続きとしては、以下に述べる通りである。
サービス提供条件のＵＮＩトラヒック規定として、セッションフロー接続要求時にフロー識別情報（送信元アドレス、送信先アドレス、送信元ポート番号、送信先ポート番号）に加え、トークンレートｒｋをユーザ網装置からサービス提供網側の帯域管理サーバへ申告し、バケットサイズσｋは式（２１）によりサービス提供網側の帯域管理サーバにおいて自動的に計算する。さらに、ピークレートはユーザ網に接続される物理回線帯域とし、帯域管理サーバでは、帯域要求時にはフロー識別情報からセッションフローが経由するリンクｉｊの集合を計算し、トークンレートｒｋの積み上げ計算により、以下の受付判定を行う。
セッションフローｋが経由するリンクｉｊにおける受付判定
（請求項６，７について）
さらに、ＵＮＩトラヒック規定をサービス提供網側で監視する場合、帯域管理サーバは受け付けたセッションフローに対しては、申告されるセッションフロー識別情報と、トークンレートｒｋ，式（２１）で計算されるバケットサイズσｋを用いて、サービス提供網において（セッションフローｋの平均制限帯域）＝（トークンレートｒｋ），（平均バーストサイズ）＝（バケットサイズσｋ）として転送トラヒック流量を監視し、監視流量内のトラヒックのみをサービス提供網内に透過させるようにトラヒック制御を行う。
さらに、ＵＮＩトラヒック規定をサービス提供網側で監視する場合、帯域管理サーバは受け付けたセッションフローに対しては、申告されるセッションフロー識別情報と、トークンレートｒｋ，式（２１）で計算されるバケットサイズσｋを用いて、サービス提供網において（セッションフローｋの平均制限帯域）＝（トークンレートｒｋ），（平均バーストサイズ）＝（バケットサイズσｋ）として転送トラヒック流量を監視し、監視流量内のトラヒックのみをサービス提供網内に透過させるようにトラヒック制御を行う。
（請求項２，４，５について）
本発明によるサービス提供条件のＵＮＩトラヒック規定をまとめると、以下のようになる。
１）トークンレートｒ：ユーザ網から、サービス提供網へ申告
２）バケットサイズσ：式（２２）により、サービス提供網において計算
３）ピークレートＰ：物理回線帯域（リンク帯域）
本発明によるサービス提供条件のＵＮＩトラヒック規定をまとめると、以下のようになる。
１）トークンレートｒ：ユーザ網から、サービス提供網へ申告
２）バケットサイズσ：式（２２）により、サービス提供網において計算
３）ピークレートＰ：物理回線帯域（リンク帯域）
ここで、図２の説明を行う。
図の１から６は図１に示したサービス提供網Ｎ内のゲートウェイルータ（ＧＷ）あるいはコアルータＲ）のいずれかに相当する。図１のネットワークではルータ３，４に着目したリンク集合として、Ｓ（３，Ｉ）はルータ３に入力する方向のリンク集合を示しており、この集合における各リンク帯域Ｃ１３，Ｃ２３，Ｃ４３とＣ３４を比較すると、式１３より１０Ｇｂｐｓ＞１Ｇｂｐｓ＋１Ｇｂｐｓであるので、Ｌ（１）＝｛３４｝となる。これは集線を行なっていないリンクであるため、全てのリンク集合の中から除外できる。従って、式（１４）より、Ｓ（３，Ｏ）：＝｛３１，３２｝であり、式（１５）よりＳ（４，Ｉ）：＝｛１３，２３，５４，６４｝である。
一方、ルータ４に着目して同様に考えると、各リンク帯域Ｃ５４，Ｃ６４，Ｃ３４とＣ４３を比較すると式（１３）より、１０Ｇｂｐｓ＜１０Ｇｂｐｓ＋１０Ｇｂｐｓであるので、Ｌ（１）＝Φとなり、従って、ルータ３，４に着目したときのＬ（１）は、Ｌ（１）＝｛３４｝となる。
同様に、２回目の手順を考えるとＬ（２）＝Φであり、手続きは終了する。
このとき、式（１６）からＳ（２）＝｛３１，３２，４３，４５，４６｝であるから、Ｄｍｉｎ〔Ｂ３１／Ｃ３１，Ｂ３２／Ｃ３２，Ｂ４３／Ｃ４３，Ｂ４５／Ｃ４５，Ｂ４６／Ｃ４６〕となる。
図の１から６は図１に示したサービス提供網Ｎ内のゲートウェイルータ（ＧＷ）あるいはコアルータＲ）のいずれかに相当する。図１のネットワークではルータ３，４に着目したリンク集合として、Ｓ（３，Ｉ）はルータ３に入力する方向のリンク集合を示しており、この集合における各リンク帯域Ｃ１３，Ｃ２３，Ｃ４３とＣ３４を比較すると、式１３より１０Ｇｂｐｓ＞１Ｇｂｐｓ＋１Ｇｂｐｓであるので、Ｌ（１）＝｛３４｝となる。これは集線を行なっていないリンクであるため、全てのリンク集合の中から除外できる。従って、式（１４）より、Ｓ（３，Ｏ）：＝｛３１，３２｝であり、式（１５）よりＳ（４，Ｉ）：＝｛１３，２３，５４，６４｝である。
一方、ルータ４に着目して同様に考えると、各リンク帯域Ｃ５４，Ｃ６４，Ｃ３４とＣ４３を比較すると式（１３）より、１０Ｇｂｐｓ＜１０Ｇｂｐｓ＋１０Ｇｂｐｓであるので、Ｌ（１）＝Φとなり、従って、ルータ３，４に着目したときのＬ（１）は、Ｌ（１）＝｛３４｝となる。
同様に、２回目の手順を考えるとＬ（２）＝Φであり、手続きは終了する。
このとき、式（１６）からＳ（２）＝｛３１，３２，４３，４５，４６｝であるから、Ｄｍｉｎ〔Ｂ３１／Ｃ３１，Ｂ３２／Ｃ３２，Ｂ４３／Ｃ４３，Ｂ４５／Ｃ４５，Ｂ４６／Ｃ４６〕となる。
本発明によれば、ユーザ網内装置からサービス提供網に流入するセッションフローのトラヒック特性をトークンバケットモデル（リーキーバケットモデル）によりＵＮＩトラヒック規定し、ＵＮＩ間品質保証を提供するサービス提供網における受付判定方法とトラヒック制御方法およびシステムにおいて、以下の（課題１）〜（課題５）を解決することができる。
（課題１）帯域要求を受け付ける帯域管理サーバにおいて、セッションフローｋの実効帯域ｅｋを計算すると、このｅｋはリンクｉｊには依存しない値となり、実効帯域ｅｋを用いて、受付判定を行えば、同一セッションフローに対する実効帯域のリンクごとの計算を省略でき、ｅｋ≧ｅｋ，ｉｊとなり、受付判定としては従来のｅｋ，ｉｊを用いて行う判定よりも、安全側となるため、論理的パケットロスを依然としてゼロのままとしている。
従って、本発明における帯域管理サーバにおいて自動的にこのｅｋを計算し、積み上げ管理し、受付判定をすることにより、論理的ロスゼロという転送品質を確保しながら、従来のあらかじめサービス提供網内の各転送ノードのリンクにおけるバッファを見積もる必要があるという課題と、サービス提供網ではネットワーク内の各リンクごとに実効帯域を計算する必要があるためスケールしないという課題を、解決する。
従って、本発明における帯域管理サーバにおいて自動的にこのｅｋを計算し、積み上げ管理し、受付判定をすることにより、論理的ロスゼロという転送品質を確保しながら、従来のあらかじめサービス提供網内の各転送ノードのリンクにおけるバッファを見積もる必要があるという課題と、サービス提供網ではネットワーク内の各リンクごとに実効帯域を計算する必要があるためスケールしないという課題を、解決する。
（課題２）さらに、上記実効帯域ｅｋとトークンレートｒｋを等しくし、トークンバケットパラメータに関する関係式を見出すことにより、論理的ロスゼロという転送品質を確保しながら、トークンレートｒｋによる帯域積み上げ計算が可能になり、収容効率を最大とした受付判定が可能となる。これにより、サービス提供網における収容率が上がらないという課題を解決することができる。
（課題３）サービス提供条件としては、ＵＮＩトラヒック規定として、トークンレートｒｋはユーザ網装置からネットワーク側の帯域管理サーバへ申告することとし、バケットサイズσｋは申告されたｒｋをもとに式（２２）によりサービス提供網側で計算され、さらにピークレートＰｋはユーザ網に接続される物理回線帯域とすることにより、帯域要求ごとに申告するパラメータはトークンレートのみとなり、帯域要求時のパラメータ管理が煩雑になるという課題を解決できる。
（課題４）また、ＵＮＩトラヒック規定におけるＤｍｉｎはサービス提供網内のリソース量に応じて計算、規定する値であり、論理的ロスゼロという転送品質を確保しながら、１ｈｏｐでの許容遅延量をＤｍｉｎとする転送品質を規定しており、サービス提供網においてプロバイダはネットワーク内のリソースに応じて提供できる転送品質を規定しなければならないという課題を解決することができる。
（課題５）このとき、トークンレートｒｋとバケットサイズσｋを用いてセッションフローｋごとの転送トラヒック流量をサービス提供網側で監視し、監視流量内のトラヒックのみをサービス提供網内に透過させるようにトラヒック制御を行うことにより、転送品質を監視しなければならないという課題を解決することができる。
以下、本発明の実施例を図面により詳細に説明する。
（実施例１）
図８は、本発明の実施例１に係る受付判定方法の動作フローチャートである。
実施例１においては、ユーザ網におけるＴＥ（ターミナル装置）からの帯域要求がサービス制御サーバを経由し、帯域管理サーバＳに送信され、アクセス網およびコア網により構成されるサービス提供網Ｎの受付判定を行うものとする。ただし、ターミナル装置ＴＥは端末、ルータ、スイッチ、サーバ等を指し、トークンバケットモデルに従ったトラヒック転送を行うものとする。
（実施例１）
図８は、本発明の実施例１に係る受付判定方法の動作フローチャートである。
実施例１においては、ユーザ網におけるＴＥ（ターミナル装置）からの帯域要求がサービス制御サーバを経由し、帯域管理サーバＳに送信され、アクセス網およびコア網により構成されるサービス提供網Ｎの受付判定を行うものとする。ただし、ターミナル装置ＴＥは端末、ルータ、スイッチ、サーバ等を指し、トークンバケットモデルに従ったトラヒック転送を行うものとする。
受付判定部、監視制御部、リソースＤＢにより構成される帯域管理サーバにおいて、リソースＤＢはサービス提供網Ｎ内のゲートウェイルータＧＷおよびコアルータＲの各リンクｉｊにおけるリンク帯域Ｃｉｊとバッファ量ＢｉｊをＳＮＭＰ，ＣＯＰＳ等のネットワーク管理プロトコルまたはポリシー管理プロトコル等の手段を用いて、取得あるいは設定を行い、リンクが２重化等が行われている場合でも、論理的に１リンクとしてみなせる場合には、合計のリンク帯域をＣｉｊ、合計のバッファ量をＢｉｊとし、同様に取得、設定を行い、アクセス網においても、コア網と同様に取得、設定を行う（ステップ２０１）。
帯域管理サーバＳにおけるリソースＤＢは、取得、設定したリンク帯域Ｃｉｊとリンク集合Ｓ（ｎ，Ｉ），Ｓ（ｎ，Ｏ）の情報を元に、条件式（１３）〜（１５）の計算を繰り返し行い、この条件を適用しても、リンクの集合Ｌ（Ｎ）が全て空集合になるまで条件適用を行い、式（１６）によりＳ（Ｎ）を決定する（ステップ２０２，２０３）。
帯域管理サーバＳにおけるリソースＤＢは、式（１７）により許容遅延量Ｄｍｉｎの計算を行う（ステップ２０４）。
ユーザ網Ｕ１，Ｕ２におけるターミナル装置ＴＥは、帯域要求時にトークンバケットパラメータ（ｒｋ，σｋ，Ｐｋ）の申告をサービス制御サーバＳＳを経由して帯域管理サーバＳに行う（ステップ２０５）。
帯域管理サーバＳにおけるリソースＤＢは、式（１７）により許容遅延量Ｄｍｉｎの計算を行う（ステップ２０４）。
ユーザ網Ｕ１，Ｕ２におけるターミナル装置ＴＥは、帯域要求時にトークンバケットパラメータ（ｒｋ，σｋ，Ｐｋ）の申告をサービス制御サーバＳＳを経由して帯域管理サーバＳに行う（ステップ２０５）。
帯域管理サーバＳにおける受付判定部は、セッションフロー識別情報（送信元アドレス、送信先アドレス、送信元ポート番号、送信先ポート番号）によりセッションフローｋが経由するリンクｉｊの集合を計算し、申告されたトークンバケットパラメータ（ｒｋ，σｋ，Ｐｋ）を用いて、実効帯域ｅｋを計算し、式（１９）による受付判定を行い（ステップ２０６）、受付許可の場合には、受付許可通知をサービス制御サーバを経由してターミナル装置ＴＥに対して行い（ステップ２０７）、受付不可の場合には、受付拒否通知をターミナル装置ＴＥに対して行う（ステップ２０８）。
（実施例２）
図９は、本発明の実施例２に係る品質保証サービスを実現する受付判定方法の動作フローチャートである。
本実施例２においては、図１に示すように、ユーザ網におけるターミナル装置ＴＥからの帯域要求がサービス制御サーバＳＳを経由し、帯域管理サーバＳに送られ、アクセス網およびコア網によって構成されるサービス提供網Ｎの受付判定を行うものである。ただし、ターミナル装置は端末、ルータ、スイッチ、サーバ等を指し、トークンバケットモデルに従ったトラヒック転送を行うものとする。
図９は、本発明の実施例２に係る品質保証サービスを実現する受付判定方法の動作フローチャートである。
本実施例２においては、図１に示すように、ユーザ網におけるターミナル装置ＴＥからの帯域要求がサービス制御サーバＳＳを経由し、帯域管理サーバＳに送られ、アクセス網およびコア網によって構成されるサービス提供網Ｎの受付判定を行うものである。ただし、ターミナル装置は端末、ルータ、スイッチ、サーバ等を指し、トークンバケットモデルに従ったトラヒック転送を行うものとする。
受付判定部、監視制御部、リソースＤＢにより構成される帯域管理サーバＳにおいて、リソースＤＢはサービス提供網ＮのゲートウェイルータＧＷおよびコアルータＲの各リンクｉｊにおけるリンク帯域Ｃｉｊとバッファ量ＢｉｊをＳＮＭＰ，ＣＯＰＳ等のネットワーク管理プロトコルまたはポリシー管理プロトコル等の手段を用いて、取得、あるいは設定を行い、リンクが２重化等が行われている場合でも、論理的に１リンクとしてみなせる場合には、合計のリンク帯域をＣｉｊ、合計のバッファ量をＢｉｊとし、同様に取得、設定を行い、アクセス網においても、コア網と同様に取得、設定を行う（ステップ３０１）。
帯域管理サーバＳにおけるリソースＤＢは、取得、設定したリンク帯域Ｃｉｊとバッファ量Ｂｉｊの値を元に、式（２１）のＤｍｉｎを計算する（ステップ３０２）。
帯域管理サーバＳにおけるリソースＤＢは、取得、設定したリンク帯域Ｃｉｊとバッファ量Ｂｉｊの値を元に、式（２１）のＤｍｉｎを計算する（ステップ３０２）。
ユーザ網Ｕ１，２におけるターミナル装置ＴＥは、帯域要求時にトークンレートｒｋの申告をサービス制御サーバＳＳを経由して帯域管理サーバＳに行う（ステップ３０３）。
帯域管理サーバにおける受付判定部は、セッションフロー識別情報（送信元アドレス、送信先アドレス、送信元ポート番号、送信先ポート番号）によりセッションフローｋが経由するリンクｉｊの集合を計算し、申告されたトークンレートｒｋを用いて、式（２３）による受付判定を行い（ステップ３０４）、受付不可の場合には、受付拒否通知をサービス制御サーバＳＳを経由してターミナル装置ＴＥに対して行う（ステップ３０５）。
帯域管理サーバＳにおける監視制御部は、受付可の場合には、申告されたトークンレートｒｋと、式（２２）でバケットサイズσｋを計算し、これをＵＮＩトラヒック規定値とし（ステップ３０６）、サービス制御サーバＳＳを経由して、ターミナル装置ＴＥに対してサービス受付許可通知を行い、バケットサイズσｋを通知する（ステップ３０７）。
帯域管理サーバにおける受付判定部は、セッションフロー識別情報（送信元アドレス、送信先アドレス、送信元ポート番号、送信先ポート番号）によりセッションフローｋが経由するリンクｉｊの集合を計算し、申告されたトークンレートｒｋを用いて、式（２３）による受付判定を行い（ステップ３０４）、受付不可の場合には、受付拒否通知をサービス制御サーバＳＳを経由してターミナル装置ＴＥに対して行う（ステップ３０５）。
帯域管理サーバＳにおける監視制御部は、受付可の場合には、申告されたトークンレートｒｋと、式（２２）でバケットサイズσｋを計算し、これをＵＮＩトラヒック規定値とし（ステップ３０６）、サービス制御サーバＳＳを経由して、ターミナル装置ＴＥに対してサービス受付許可通知を行い、バケットサイズσｋを通知する（ステップ３０７）。
（実施例３）
図１０は、本発明の実施例３に係る品質保証サービスを実現する受付判定方法およびトラヒック制御方法の動作フローチャートである。
本実施例３においては、図１に示すように、ユーザ網Ｕ１，Ｕ２におけるターミナル装置ＴＥからの帯域要求がサービス制御サーバＳＳを経由して帯域管理サーバＳに送られ、アクセス網およびコア網により構成されるサービス提供網Ｎの受付判定を行うものとする。ただし、ターミナル装置ＴＥは、端末、ルータ、スイッチ、サーバ等を指し、トークンバケットモデルに従ったトラヒック転送を行うものとする。
図１０は、本発明の実施例３に係る品質保証サービスを実現する受付判定方法およびトラヒック制御方法の動作フローチャートである。
本実施例３においては、図１に示すように、ユーザ網Ｕ１，Ｕ２におけるターミナル装置ＴＥからの帯域要求がサービス制御サーバＳＳを経由して帯域管理サーバＳに送られ、アクセス網およびコア網により構成されるサービス提供網Ｎの受付判定を行うものとする。ただし、ターミナル装置ＴＥは、端末、ルータ、スイッチ、サーバ等を指し、トークンバケットモデルに従ったトラヒック転送を行うものとする。
受付判定部、監視制御部、リソースＤＢにより構成される帯域管理サーバＳにおいて、リソースＤＢはサービス提供網Ｎ内のゲートウェイルータＧＷおよびコアルータＲの各リンクｉｊにおけるリンク帯域Ｃｉｊとバッファ量ＢｉｊをＳＮＭＰ，ＣＯＰＳ等のネットワーク管理プロトコルまたはポリシー管理プロトコル等の手段を用いて、取得、あるいは設定を行い、リンクが２重化等が行われている場合でも、論理的に１リンクとしてみなせる場合には、合計のリンク帯域をＣｉｊ、合計のバッファ量をＢｉｊとし、同様に取得、設定を行い、アクセス網においても、コア網と同様に取得、設定を行う（ステップ４０１）。
帯域管理サーバＳにおけるリソースＤＢは、取得、設定したリンク帯域Ｃｉｊとバッファ量Ｂｉｊの値を元に、式（２１）のＤｍｉｎを計算する（ステップ４０２）。
ユーザ網におけるターミナル装置ＴＥは、帯域要求時にトークンレートｒｋの申告をサービス制御サーバＳＳを経由して帯域管理サーバＳに行う（ステップ４０３）。
帯域管理サーバＳにおける受付判定部は、セッションフロー識別情報（送信元アドレス、送信先アドレス、送信元ポート番号、送信先ポート番号）によりセッションフローｋが経由するリンクｉｊの集合を計算し、申告されたトークンレートｒｋを用いて、式（２３）による受付判定を行い（ステップ４０４）、受付不可の場合には、受付拒否通知をサービス制御サーバＳＳを経由してターミナル装置ＴＥに対して行う（ステップ４０５）。
ユーザ網におけるターミナル装置ＴＥは、帯域要求時にトークンレートｒｋの申告をサービス制御サーバＳＳを経由して帯域管理サーバＳに行う（ステップ４０３）。
帯域管理サーバＳにおける受付判定部は、セッションフロー識別情報（送信元アドレス、送信先アドレス、送信元ポート番号、送信先ポート番号）によりセッションフローｋが経由するリンクｉｊの集合を計算し、申告されたトークンレートｒｋを用いて、式（２３）による受付判定を行い（ステップ４０４）、受付不可の場合には、受付拒否通知をサービス制御サーバＳＳを経由してターミナル装置ＴＥに対して行う（ステップ４０５）。
帯域管理サーバＳにおける監視制御部は、受付可の場合、申告されたトークンレートｒｋと、式（２２）でバケットサイズσｋを計算し、これをＵＮＩトラヒック規定値とし（ステップ４０６）、ゲートウェイルータＧＷに対して当該セッションフローの平均制限帯域＝トークンレートｒｋ，平均バーストサイズ＝バケットサイズσｋとして、転送トラヒック量を監視し、この監視流量内トラヒックのみをサービス提供網に透過させるようトラヒック制御を行い（ステップ４０７）、帯域管理サーバＳにおける受付判定部は、受付可の場合には、サービス制御サーバＳＳを経由してターミナル装置ＴＥに対してサービス受付許可通知を行う（ステップ４０８）。
（実施例４）
図１１は、本発明の実施例４に係る受付判定システムの構成図である。
本実施例においては、ユーザ網Ｕ１，Ｕ２におけるターミナル装置ＴＥからの帯域要求がサービス制御サーバＳＳを経由し、帯域管理サーバＳに送られ、アクセス網およびコア網によって構成されるサービス提供網Ｎの受付判定を行うものとする。ただし、ターミナル装置ＴＥは端末、ルータ、スイッチ、サーバ等を指し、トークンバケットモデルに従ったトラヒック転送を行うものとする。
図１１は、本発明の実施例４に係る受付判定システムの構成図である。
本実施例においては、ユーザ網Ｕ１，Ｕ２におけるターミナル装置ＴＥからの帯域要求がサービス制御サーバＳＳを経由し、帯域管理サーバＳに送られ、アクセス網およびコア網によって構成されるサービス提供網Ｎの受付判定を行うものとする。ただし、ターミナル装置ＴＥは端末、ルータ、スイッチ、サーバ等を指し、トークンバケットモデルに従ったトラヒック転送を行うものとする。
受付判定部Ｓ１およびリソースＤＢ・Ｓ３により構成される帯域管理サーバＳにおいて、リソースＤＢ・Ｓ３は、サービス提供網内のゲートウェイルータＧＷおよびコアルータＲの各リンクｉｊにおけるリンク帯域Ｃｉｊとバッファ量ＢｉｊをＳＮＭＰ，ＣＯＰＳ等のネットワーク管理プロトコルまたはポリシー管理プロトコル等の手段を用いて、取得あるいは設定を行い、リンクが２重化等が行われている場合でも、論理的に１リンクとしてみなせる場合には、合計のリンク帯域をＣｉｊ、合計のバッファ量をＢｉｊとし、同様に取得、設定を行い、アクセス網においても、コア網と同様に取得、設定を行う手段１（リソースＤＢ・Ｓ３から延長する矢印）を有する。
また、帯域管理サーバＳにおけるリソースＤＢ・Ｓ３は、取得、設定したリンク帯域Ｃｉｊとバッファ量Ｂｉｊの値を元に、条件（１３）〜（１５）の計算を繰り返し行い、この条件を適用しても、リンクの集合Ｌ（Ｎ）が全て空集合になるまで条件適用を行い、式（１６）によりＳ（Ｎ）を決定し、式（１７）により許容遅延量Ｄｍｉｎの計算を行う手段２（リソースＤＢ・Ｓ３の一部を構成する部分）を有する。
ユーザ網におけるターミナル装置ＴＥは、帯域要求時にトークンバケットパラメータ（ｒｋ，σｋ，Ｐｋ）の申告をサービス制御サーバＳＳを経由して帯域管理サーバＳに行う手段３（ＴＥからサービス制御サーバＳＳに向かう矢印）を有する。
ユーザ網におけるターミナル装置ＴＥは、帯域要求時にトークンバケットパラメータ（ｒｋ，σｋ，Ｐｋ）の申告をサービス制御サーバＳＳを経由して帯域管理サーバＳに行う手段３（ＴＥからサービス制御サーバＳＳに向かう矢印）を有する。
帯域管理サーバＳにおける受付判定部Ｓ１は、セッションフロー識別情報（送信元アドレス、送信先アドレス、送信元ポート番号、送信先ポート番号）によりセッションフローｋが経由するリンクｉｊの集合を計算し、申告されたトークンバケットパラメータ（ｒｋ，σｋ，Ｐｋ）を用いて、実効帯域ｅｋを計算し、式（１９）による受付判定を行う手段４（受付判定部の一部を構成する部分）を有する。
受付許可の場合には、受付許可通知をサービス制御サーバＳＳを経由してターミナル装置ＴＥに対して行い、受付不可の場合には、受付拒否通知をターミナル装置ＴＥに対して行う手段５（帯域管理サーバＳからサービス制御サーバＳＳを介してＴＥに延長する矢印）を有する。
受付許可の場合には、受付許可通知をサービス制御サーバＳＳを経由してターミナル装置ＴＥに対して行い、受付不可の場合には、受付拒否通知をターミナル装置ＴＥに対して行う手段５（帯域管理サーバＳからサービス制御サーバＳＳを介してＴＥに延長する矢印）を有する。
（実施例５）
図１２は、本発明の実施例５に係る受付判定システムおよびトラヒック制御システムの構成図である。
本実施例においては、ユーザ網におけるターミナル装置ＴＥからの帯域要求がサービス制御サーバＳＳを経由し、帯域管理サーバＳに送られ、アクセス網およびコア網によって構成されるサービス提供網Ｎの受付判定を行うものとする。ただし、ターミナル装置ＴＥは、端末、ルータ、スイッチ、サーバ等を指し、トークンパケットモデルに従ったトラヒック転送を行うものとする。
図１２は、本発明の実施例５に係る受付判定システムおよびトラヒック制御システムの構成図である。
本実施例においては、ユーザ網におけるターミナル装置ＴＥからの帯域要求がサービス制御サーバＳＳを経由し、帯域管理サーバＳに送られ、アクセス網およびコア網によって構成されるサービス提供網Ｎの受付判定を行うものとする。ただし、ターミナル装置ＴＥは、端末、ルータ、スイッチ、サーバ等を指し、トークンパケットモデルに従ったトラヒック転送を行うものとする。
受付判定部Ｓ１、監視制御部Ｓ２、リソースＤＢ・Ｓ３によって構成される帯域管理サーバＳにおいて、リソースＤＢ・Ｓ３は、サービス提供網Ｎ内のゲートウェイルータＧＷおよびコアルータＲの各リンクｉｊにおけるリンク帯域Ｃｉｊとバッファ量ＢｉｊをＳＮＭＰ，ＣＯＰＳ等のネットワーク管理プロトコルまたはポリシー管理プロトコル等の手段を用いて、取得あるいは設定を行い、リンクが２重化等が行われている場合でも、論理的に１リンクとしてみなせる場合には、合計のリンク帯域をＣｉｊ、合計のバッファ量をＢｉｊとし、同様に取得、設定を行い、アクセス網においても、コア網と同様に取得、設定を行う手段１（リソースＤＢ・Ｓ３から延長する複数の矢印）を有する。
また、帯域管理サーバＳにおけるリソースＤＢ・Ｓ３は、取得，設定したリンク帯域Ｃｉｊとバッファ量Ｂｉｊの値に元に、式（２１）のＤｍｉｎを計算する手段２（リソースＤＢ・Ｓ３の一部を構成する部分）を有する。
また、ユーザ網におけるターミナル装置ＴＥは、帯域要求時にトークンレートｒｋの申告をサービス制御サーバＳＳを経由して帯域管理サーバＳに行う手段３（ＴＥからサーバス制御サーバＳＳを経由して帯域管理サーバＳに延長する矢印）を有する。
また、帯域管理サーバＳにおける受付判定部Ｓ１は、セッションフロー識別情報（送信元アドレス、送信先アドレス、送信元ポート番号、送信先ポート番号）によりセッションフローｋが経由するリンクｉｊの集合を計算し、申告されたトークンレートｒｋを用いて、式（２３）による受付判定を行う手段４（受付判定部Ｓ一の一部を構成する部分）を有する。
また、ユーザ網におけるターミナル装置ＴＥは、帯域要求時にトークンレートｒｋの申告をサービス制御サーバＳＳを経由して帯域管理サーバＳに行う手段３（ＴＥからサーバス制御サーバＳＳを経由して帯域管理サーバＳに延長する矢印）を有する。
また、帯域管理サーバＳにおける受付判定部Ｓ１は、セッションフロー識別情報（送信元アドレス、送信先アドレス、送信元ポート番号、送信先ポート番号）によりセッションフローｋが経由するリンクｉｊの集合を計算し、申告されたトークンレートｒｋを用いて、式（２３）による受付判定を行う手段４（受付判定部Ｓ一の一部を構成する部分）を有する。
また、受付不可の場合には、受付拒否通知をサービス制御サーバＳＳを経由してターミナル装置ＴＥに対して行う手段５（帯域管理サーバＳからサービス制御サーバＳＳを経由してＴＥに延長する矢印）を有する。
また、帯域管理サーバＳにおける監視制御部Ｓ２は、受付可の場合、申告されたトークンレートｒｋと、式（２２）でバケットサイズσｋを計算し、ＵＮＩトラヒック規定値とする手段６（監視制御部Ｓ２からゲートウェイルータＧＷに向う矢印）を有する。
また、ゲートウェイルータＧＷに対して当該セッションフローの平均制限帯域＝トークンレートｒｋ，平均バーストサイズ＝バケットサイズσｋとして、転送トラヒック量を監視し、この監視流量内トラヒックのみをサービス提供網Ｎに透過させるようトラヒック制御を行う手段７（帯域管理サーバＳからサービス制御サーバＳＳを経由してＵＮＩに延長する矢印）を有する。
また、帯域管理サーバＳにおける受付判定部Ｓ１は、受付可の場合、サービス制御サーバＳＳを経由してターミナル装置ＴＥに対してサービス受付許可通知を行う手段８（受付判定部Ｓ１の一部を構成する部分）を有する。
また、帯域管理サーバＳにおける監視制御部Ｓ２は、受付可の場合、申告されたトークンレートｒｋと、式（２２）でバケットサイズσｋを計算し、ＵＮＩトラヒック規定値とする手段６（監視制御部Ｓ２からゲートウェイルータＧＷに向う矢印）を有する。
また、ゲートウェイルータＧＷに対して当該セッションフローの平均制限帯域＝トークンレートｒｋ，平均バーストサイズ＝バケットサイズσｋとして、転送トラヒック量を監視し、この監視流量内トラヒックのみをサービス提供網Ｎに透過させるようトラヒック制御を行う手段７（帯域管理サーバＳからサービス制御サーバＳＳを経由してＵＮＩに延長する矢印）を有する。
また、帯域管理サーバＳにおける受付判定部Ｓ１は、受付可の場合、サービス制御サーバＳＳを経由してターミナル装置ＴＥに対してサービス受付許可通知を行う手段８（受付判定部Ｓ１の一部を構成する部分）を有する。
なお、本発明における転送トラヒック量監視により違反したトラヒックの扱いについては、廃棄させるか、または、違反トラヒックへのリマーキングをして下位優先度のサービスクラスに送るか、廃棄優先度を高くして廃棄し易くさせる方式を考えることができるが、本発明では、このような転送トラヒック量監視により違反したトラヒックの扱いに関して限定されるものではない。
また、本発明では、ＩＰ電話サービス、映像コミュニケーションサービス、ストリーミング配信等、の要求品質が厳しいサービスをアプリケーションとして利用することができ、上記課題を解決する。従って、本発明はこれらアプリケーションに固有の技術、プロトコルによりその有効性が限定されるものではない。
さらに、本発明では、サービス制御を行うためのプロトコルとして、ＨＴＴＰ、ＳＩＰ、Ｈ．３２３等があるが、これらのシグナリングにより、その有効性が限定されるものではない。
また、本発明では、ＩＰ電話サービス、映像コミュニケーションサービス、ストリーミング配信等、の要求品質が厳しいサービスをアプリケーションとして利用することができ、上記課題を解決する。従って、本発明はこれらアプリケーションに固有の技術、プロトコルによりその有効性が限定されるものではない。
さらに、本発明では、サービス制御を行うためのプロトコルとして、ＨＴＴＰ、ＳＩＰ、Ｈ．３２３等があるが、これらのシグナリングにより、その有効性が限定されるものではない。
ｒ：セッションフローのトークンレートを表すトークンバケットパラメータ
σ：セッションフローのバケットサイズを表すトークンバケットパラメータ
Ｐ：セッションフローのピークレートを表すトークンバケットパラメータ
Ｔ０Ｎ：セッションが極値ＯＮ／ＯＦＦ過程に従ってピークレートＰでパケットを送出する期間の長さ
Ｔｏｆｆ：セッションが極値ＯＮ／ＯＦＦ過程に従ってパケットを送出しない期間の長さ
ｂ：ネットワークノードが出力リンク用に割り当てているバッファ容量
ｃ：ネットワークノードからの出力リンクの帯域
Ｄｏｎ：仮想キューイングシステムにおけるｂｕｓｙ期間長
Ｄｏｆｆ：仮想キューイングシステムにおけるｉｄｌｅ期間長
ｒｋ，σｋ，Ｐｋ：特定のセッションフローｋのトークンバケットパラメータ
Ｃｉｊ：ノードｉからノードｊへ至るリンクｉｊのリンク帯域
Ｂｉｊ：ノードｉからノードｊへ至るリンクｉｊに対して、ノードｉの出力インターフェースに用意されるバッファ容量
Ｄｉｊ：ノードｉからノードｊに至るリンクｉｊに対して、ノードｉの出力インターフェースで発生する最大遅延時間
ｃｋ：セッションフローｋに割り当てられる仮想帯域
ｂｋ：セッションフローｋに割り当てられる仮想バッファ容量
ｅｋ，ｉｊ：リンクｉｊ上でセッションフローｋに割り当てられる実効帯域
Ｄｍｉｎ：ネットワーク上の全ノードで統一的に用いられる許容遅延時間
ｅｋ：セッションフローｋに割り当てられるネットワーク上で統一的な実効帯域
Ｓ（ｎ，Ｏ）：ノードｎから他ノードへ至るリンクの集合
Ｓ（ｎ，Ｉ）：他ノードからノードｎへ至るリンクの集合
Ｌ（Ｎ）：Ｎ回目の手順において、あるノードに着目したときの集線効果がなく、受付判定の必要のないリンクの集合
σ：セッションフローのバケットサイズを表すトークンバケットパラメータ
Ｐ：セッションフローのピークレートを表すトークンバケットパラメータ
Ｔ０Ｎ：セッションが極値ＯＮ／ＯＦＦ過程に従ってピークレートＰでパケットを送出する期間の長さ
Ｔｏｆｆ：セッションが極値ＯＮ／ＯＦＦ過程に従ってパケットを送出しない期間の長さ
ｂ：ネットワークノードが出力リンク用に割り当てているバッファ容量
ｃ：ネットワークノードからの出力リンクの帯域
Ｄｏｎ：仮想キューイングシステムにおけるｂｕｓｙ期間長
Ｄｏｆｆ：仮想キューイングシステムにおけるｉｄｌｅ期間長
ｒｋ，σｋ，Ｐｋ：特定のセッションフローｋのトークンバケットパラメータ
Ｃｉｊ：ノードｉからノードｊへ至るリンクｉｊのリンク帯域
Ｂｉｊ：ノードｉからノードｊへ至るリンクｉｊに対して、ノードｉの出力インターフェースに用意されるバッファ容量
Ｄｉｊ：ノードｉからノードｊに至るリンクｉｊに対して、ノードｉの出力インターフェースで発生する最大遅延時間
ｃｋ：セッションフローｋに割り当てられる仮想帯域
ｂｋ：セッションフローｋに割り当てられる仮想バッファ容量
ｅｋ，ｉｊ：リンクｉｊ上でセッションフローｋに割り当てられる実効帯域
Ｄｍｉｎ：ネットワーク上の全ノードで統一的に用いられる許容遅延時間
ｅｋ：セッションフローｋに割り当てられるネットワーク上で統一的な実効帯域
Ｓ（ｎ，Ｏ）：ノードｎから他ノードへ至るリンクの集合
Ｓ（ｎ，Ｉ）：他ノードからノードｎへ至るリンクの集合
Ｌ（Ｎ）：Ｎ回目の手順において、あるノードに着目したときの集線効果がなく、受付判定の必要のないリンクの集合
Claims (8)
- コンピュータ制御により、ユーザ網内装置からサービス提供網に流入するセッションフローのトラヒック特性をトークンバケットモデルによりＵＮＩトラヒック規定し、ＵＮＩ間品質保証を提供するサービス提供網の受付判定方法において、
帯域管理サーバが、該帯域管理サーバ内のリソースデータベースにアクセスして、前記サービス提供網内の各転送ノードの接続情報、リンクリソース情報（ノードｉからノードｊへのリンクｉｊにおけるリンク帯域Ｃｉｊ、バッファ量Ｂｉｊ）を読み取る手順と、
前記帯域管理サーバが、該帯域管理サーバ内の受付判定部の演算回路を動作して演算することで、各セッションフローｋへ割り当てる実効帯域ｅｋ，ｉｊを経路を構成するリンクｉｊに依存することなく、前記サービス提供網内で共通した値ｅｋとする手順と、
前記受付判定部の演算回路で、前記リンク帯域Ｃｉｊと全セッションフローの実効帯域Σｋｅｋを比較演算し、演算結果により前記ユーザ網内装置から要求されたセッションフローの受付可否を判定する手順と
を有することを特徴とするセッションフローごとの受付判定方法。 - コンピュータ制御により、ユーザ網内装置からサービス提供網に流入するセッションフローのトラヒック特性をトークンバケットモデルによりＵＮＩトラヒック規定し、ＵＮＩ間品質保証を提供するサービス提供網の受付判定方法において、
帯域管理サーバが、該帯域管理サーバ内のリソースデータベースにアクセスして、前記サービス提供網内の各転送ノードの接続情報、リンク帯域Ｃｉｊおよびバッファ量Ｂｉｊを含むリンクリソース情報を読み取る手順と、
該帯域管理サーバ内の受付判定部の演算回路を動作して演算することで、前記リンク帯域Ｃｉｊと前記ユーザ網内装置から要求されるセッションフローｋごとのトークンレートｒｋの積み上げ計算値Σｋｒｋを比較して、要求されたセッションフローの受付可否を判定する手順と、
前記演算回路での演算の結果、受付が可能と判定されたとき、セッションフローｋごとのバケットサイズを前記サービス提供網側で計算し、計算した結果のバケットサイズをＵＮＩトラヒック規定値と決定する手順と
を有することを特徴とするセッションフローごとの受付判定方法。 - 請求項１に記載のセッションフローごとの受付判定方法において、
前記セッションフローｋへ割り当てる実効帯域ｅｋ，ｉｊを経由を構成するリンクｉｊに依存することなく、サービス提供網内で共通した値ｅｋとする手順は、
前記サービス提供網内の全てのリンクの集合をＡとし、該Ａの中からトラヒックの集線効果のあるリンクを抽出する手順と、
抽出したリンクの集合をＳとするとき、
セッションフローｋの実効帯域を、当該セッションフローｋのトークンレートｒｋとバケットサイズσｋおよびピークレートＰｋを用いて、
を有することを特徴とするセッションフローごとの受付判定方法。 - 請求項２に記載のセッションフローごとの受付判定方法において、
前記受付が可能なとき、セッションフローｋごとのバケットサイズをサービス提供網側で計算し、ＵＮＩトラヒック規定値とする手順は、
前記セッションフローｋのバケットサイズσｋを、全てのリンク集合Ａから、
であることを特徴とするセッションフローごとの受付判定方法。 - 請求項４に記載のセッションフローごとの受付判定方法において、
前記セッションフローｋのバケットサイズσｋを、
全てのリンク集合Ａからトラヒックの集線効果のあるリンクを抽出したリンク集合Ｓから
であることを特徴とするセッションフローごとの受付判定方法。 - コンピュータ制御により、ユーザ網内装置からサービス提供網に流入するセッションフローのトラヒック特性をトークンバケットモデルによりＵＮＩトラヒック規定し、ＵＮＩ間品質保証を提供するサービス提供網のトラヒック制御方法において、
帯域管理サーバ内の監視制御部は、請求項１から請求項５のいずれかに記載のセッションフローごとの受付判定方法における受付判定部が、前記帯域管理サーバによって動作させられて、各セッションフローｋへ割り当てる実効帯域ｅｋ，ｉｊを経路を構成するリンクｉｊに依存することなく、前記サービス提供網内で共通した値ｅｋとし、前記リンク帯域Ｃｉｊと全セッションフローの実効帯域Σｋｅｋを比較演算し、演算結果により前記ユーザ網内装置から要求されたセッションフローの受付を可と判定した場合、申告されたトークンレートｒｋ，計算済みのバケットサイズσｋのパラメータを用いて、前記サービス提供網がセッションフローごとに（平均制限帯域）＝（トークンレート）、（平均バーストサイズ）＝（バケットサイズ）として転送トラヒック量を監視し、監視流量内のトラヒックのみを前記サービス提供網内に透過させることを特徴とするトラヒック制御方法。 - コンピュータ制御により、ユーザ網内装置からサービス提供網に流入するセッションフローのトラヒック特性をトークンバケットモデルによりＵＮＩトラヒック規定し、ＵＮＩ間品質保証を提供するサービス提供網のトラヒック制御システムにおいて、
帯域管理サーバは、
サービス提供網内の各転送ノードの接続情報、リンクリソース情報（ノードｉからノードｊへのリンクｉｊにおけるリンク帯域Ｃｉｊ、バッファ量Ｂｉｊ）を把握する手段を有するリソースＤＢと、
請求項１から請求項５のいずれかに記載のセッションフローごとの受付判定方法における受付判定部と、
該受付判定部が、前記帯域管理サーバによって動作させられて、各セッションフローｋへ割り当てる実効帯域ｅｋ，ｉｊを経路を構成するリンクｉｊに依存することなく、前記サービス提供網内で共通した値ｅｋとし、前記リンク帯域Ｃｉｊと全セッションフローの実効帯域Σｋｅｋを比較演算し、演算結果により前記ユーザ網内装置から要求されたセッションフローの受付を可と判定した場合、セッションフローｋごとに（平均制限帯域）＝（トークンレート），（平均バーストサイズ）＝（バケットサイズ）として転送トラヒック量を監視し、監視流量内トラヒックのみを前記サービス提供網に透過させるようにトラヒック制御を行う手段を備えた監視制御部とを有することを特徴とするトラヒック制御システム。 - コンピュータ制御により、ユーザ網内装置からサービス提供網に流入するセッションフローのトラヒック特性をトークンバケットモデルによりＵＮＩトラヒック規定し、ＵＮＩ間品質保証を提供するサービス提供網の受付判定システムにおいて、
帯域管理サーバは、
サービス提供網内の各転送ノードの接続情報、リンクリソース情報（ノードｉからノードｊへのリンクｉｊにおけるリンク帯域Ｃｉｊ、バッファ量Ｂｉｊ）を把握する手段、および、各セッションフローｋへの割り当てる実効帯域ｅｋを経路を構成するリンクｉｊに依存せず網内で共通した値ｅｋとする手段を備えたリソースＤＢと、
リンク帯域Ｃｉｊと全セッションフローの実効帯域Σｋｅｋを比較して、要求されたセッションフローの受付判定を行う受付判定部とを有することを特徴とする受付判定システム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2005040024A JP4346032B2 (ja) | 2005-02-17 | 2005-02-17 | 品質保証サービスを実現する受付判定方法とトラヒック制御方法およびそのシステム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2005040024A JP4346032B2 (ja) | 2005-02-17 | 2005-02-17 | 品質保証サービスを実現する受付判定方法とトラヒック制御方法およびそのシステム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2006229516A JP2006229516A (ja) | 2006-08-31 |
| JP4346032B2 true JP4346032B2 (ja) | 2009-10-14 |
Family
ID=36990482
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2005040024A Active JP4346032B2 (ja) | 2005-02-17 | 2005-02-17 | 品質保証サービスを実現する受付判定方法とトラヒック制御方法およびそのシステム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4346032B2 (ja) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8326149B2 (en) * | 2009-01-20 | 2012-12-04 | Pmc Sierra Ltd. | Dynamic bandwidth allocation in a passive optical network in which different optical network units transmit at different rates |
-
2005
- 2005-02-17 JP JP2005040024A patent/JP4346032B2/ja active Active
Also Published As
| Publication number | Publication date |
|---|---|
| JP2006229516A (ja) | 2006-08-31 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Roberts et al. | Quality of service by flow–aware networking | |
| WO2005022848A1 (en) | Flexible admission control for different traffic classes in a communication network | |
| AU2002339309B2 (en) | Traffic restriction by means of reliability check for a packet-oriented connectionless network with QoS transmission | |
| Lu et al. | An architectural framework for support of quality of service in packet networks | |
| Gelenbe et al. | Admission of QoS aware users in a smart network | |
| Mammeri | Framework for parameter mapping to provide end-to-end QoS guarantees in IntServ/DiffServ architectures | |
| JP4390731B2 (ja) | 呼受付判定方法とシステムおよびプログラム | |
| JP2007325224A (ja) | トラヒック制御方法とシステムおよびプログラム | |
| JP4346032B2 (ja) | 品質保証サービスを実現する受付判定方法とトラヒック制御方法およびそのシステム | |
| Menth et al. | Threshold configuration and routing optimization for PCN-based resilient admission control | |
| JP5194025B2 (ja) | 複数のアプリケーション・フローの間での複数のネットワーク・リソースの共有を最適化する方法 | |
| Koucheryavy et al. | A top-down approach to VoD traffic transmission over DiffServ domain using AF PHB class | |
| Alipour et al. | Adaptive admission control for quality of service guarantee in differentiated services networks | |
| Holness et al. | Dynamic congestion control mechanisms for MPLS networks | |
| KR100563663B1 (ko) | 인터넷 서비스 품질 보장을 위한 밴드위드 브로커의 정책 결정 방법 | |
| Bakiras et al. | Quality of service support in differentiated services packet networks | |
| Stojanović et al. | A novel approach for providing quality of service in multi service IP networks | |
| Császár et al. | Resilient reduced-state resource reservation | |
| Lima et al. | Distributed Admission Control in Multiservice IP Networks: Concurrency Issues. | |
| Lee et al. | Flow-aware link dimensioning for guaranteed-QoS services in broadband convergence networks | |
| Stokkink | Performance evaluation of severe congestion handling solutions for multilevel service in rmd domains | |
| Krile et al. | Bandwidth optimization in SLA negotiation process | |
| Morishima et al. | Field-trial of dynamic SLA in diffserv-capable network | |
| Menth | Efficiency of PCN-based network admission control with flow termination | |
| Gyires | An extension of Integrated Services with active networking for providing quality of service in networks with long-range dependent traffic |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20070116 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20090123 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20090203 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090402 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20090417 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090616 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20090710 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20090710 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 4346032 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120724 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130724 Year of fee payment: 4 |
|
| S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313531 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |