(57)【要約】【課題】ピークレート、平均レート、バケットサイズで規定するトークンバケットモデルで通信セッションフローの特性を表すネットワークで論理的パケット損失をゼロにすることで品質保証を実現でき、セッションフローの本数に依存せず、効率的なリソース割当が可能な呼受付制御技術の提供。【解決手段】平均割当、ピーク割当、第３のリソース割当の３種類のリソース割当法を機能させ（Ｓ１０３〜Ｓ１０４）、３種類のリソース割当法で得られたリソース量が設備量に収まっている場合（Ｓ１０５：Ｙ）、または、３種類のリソース割当法で得られるリソース量が全て設備量を超えている場合でも帯域とバッファのリソース量を横軸と縦軸にしたグラフ上に３種類のリソース割当法で得られたリソース量をプロットし３つの点のそれぞれを結ぶ線分上に設備量の範囲に収まっている点がある場合に（Ｓ１０６：Ｙ）、新規セッションフローの接続を許可する（Ｓ１０７）。【選択図】図１
2011015025.tif 000002
【特許請求の範囲】
【請求項１】
接続セッションフローにリンク帯域およびバッファ量の２種類のリソースを個別に割り当てて、設備量に収まる範囲内で新規接続セッションフローを受け付けるコンピュータを用いた呼受付制御方法において、
コンピュータ制御により、平均レートリソース割当法、ピークレートリソース割当法の２種類のリソース割当法に加え、第３のリソース割当法を含めた３種類のリソース割当法を同時に機能させる手順と、
コンピュータ制御により、前記３種類のリソース割当法のいずれかで得られたリソース量の総和が設備量に収まっている場合に、あるいは、前記３種類のリソース割当法のそれぞれで得られるリソース量の総和が全て設備量を超えている場合であっても前記リンク帯域およびバッファ量の２種類のリソース量を横軸と縦軸にしたグラフ上に前記３種類のリソース割当法のそれぞれで得られたリソース量の総和をプロットしたとき該プロットされた３つの点のそれぞれを結ぶ線分上に設備量の範囲に収まっている点がある場合に、新規セッションフローの接続を許可する手順と
を有することを特徴とする呼受付制御方法。
【請求項２】
請求項１記載の呼受付制御方法において、
前記第３のリソース割当法は、ピークレートＰｋ，平均レートρｋ，バケットサイズσｋのトークンバケットパラメータを持つセッションフローｋ（ｋ=１,２,・・・，Ｋ)がバッファ量Ｂ,リンク帯域Ｃを持つノードに多重される場合、σｋ／（Ｐｋ-ρｋ）が一定の閾値Ｘを超えるセッションフローに対してはピークレートリソース割当法を、σｋ／（Ｐｋ-ρｋ）が前記一定の閾値Ｘ未満であるセッションフローに対しては平均レートリソース割当法を行うリソース割当法であることを特徴とする呼受付制御方法。
【請求項３】
請求項１または２記載の呼受付制御方法において、
前記第３のリソース割当法では、第３のリソース割当法によるリソース割当が設備量を超える状況があった場合、リンク帯域リソースが超過した場合には、リソース割当法として、リンク帯域リソースをより少なく、バッファリソースをより多く与えるリソース割当法に変更し、逆にバッファリソース割当が設備量を超える状況があった場合、リソース割当法として、リンク帯域リソースをより多く、バッファリソースをより少なく与えるリソース割当法に変更する
ことを特徴とする呼受付制御方法。
【請求項４】
請求項３記載の呼受付制御方法において、
前記第３のリソース割当法では、前記一定の閾値Ｘについて、第３のリソース割り当て方法によるリソース配分が設備量を超える状況があった場合、帯域リソースが超過した場合には該一定の閾値Ｘを一定値ｄｘだけ大きく変更し、バッファリソースが超過した場合には該一定の閾値Ｘを一定値ｄｘだけ小さく変更することを特徴とする呼受付制御方法。
【請求項５】
請求項３または４記載の呼受付制御方法において、
前記変更は、セッションフローの接続数が０になった時点で実行することを特徴とする呼受付制御方法。
【請求項６】
コンピュータに、請求項１から５のいずれかに記載の呼受付制御方法における各手順を実行させるためのプログラム。
【請求項７】
接続セッションフローにリンク帯域およびバッファ量の２種類のリソースを個別に割り当てて、設備量に収まる範囲内で新規接続セッションフローを受け付けるコンピュータを用いた呼受付制御装置において、
コンピュータ制御により、平均レートリソース割当法、ピークレートリソース割当法の２種類のリソース割当法に加え、第３のリソース割当法を含めた３種類のリソース割当法を同時に機能させる手段と、
コンピュータ制御により、前記３種類のリソース割当法のいずれかで得られたリソース量の総和が設備量に収まっている場合に、あるいは、前記３種類のリソース割当法のそれぞれで得られるリソース量の総和が全て設備量を超えている場合であっても前記リンク帯域およびバッファ量の２種類のリソース量を横軸と縦軸にしたグラフ上に前記３種類のリソース割当法のそれぞれで得られたリソース量の総和をプロットしたとき該プロットされた３つの点のそれぞれを結ぶ線分上に設備量の範囲に収まる点がある場合に、新規セッションフローの接続を許可する手段と
を有することを特徴とする呼受付制御装置。
【請求項８】
請求項７記載の呼受付制御装置を内蔵したことを特徴とする通信ルータ。
【請求項９】
請求項７記載の呼受付制御装置を内蔵したことを特徴とするネットワーク制御装置。
【請求項１０】
請求項８記載の通信ルータまたは請求項９記載のネットワーク制御装置を用いたことを特徴とするネットワーク。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＰ（Internet Protocol；インターネット・プロトコル）網やＭＰＬＳ（MultiProtocol Label Switching）網を用いて品質保証型サービスを提供するネットワーク事業者が、ユーザからの接続要求に対して、品質保証の実現可否を判断し、品質保証が実現可能であれば接続要求を受け入れてサービスを提供し、品質保証が実現不可能であれば接続要求を拒否する呼受付制御方法および装置、ならびにそのためのプログラムに関する。
【背景技術】
【０００２】
近年、ブロードバンド回線が低価格でユーザに提供されるようになり、インターネットは急激に普及している。この普及に伴い、様々なサービスがインターネットを介して提供されるようになるとともに、その通信品質が重要視されるようになった。
【０００３】
特に、リアルタイムによる映像や音声サービスに対してはネットワーク上におけるデータ転送品質が大きく影響するが、インターネットではそのデータ転送品質を保証する仕組みがないため、現在ではＩＰ閉域網としてネットワークを構築し、データ転送品質を保証する技術と組み合わせて品質保証型のサービスを提供することが検討されている。
【０００４】
ＩＰ網において、データ転送品質を保証するサービスモデルとして、主にＩＥＴＦ（Internet Engineering Task Force）で検討されたＩｎｔｆｓｅｒｖ（イントサーブ，Integrated Services）とＤｉｆｆｓｅｒｖ(ディフサーブ，Differentiated Services)に分けられる。
【０００５】
Ｉｎｔｆｓｅｒｖは、ｅｎｄ-ｔｏ-ｅｎｄでネットワーク経路上の帯域を予約するプロトコルであるＲＳＶＰ（Resource Reservation Protocol；ネットワーク上で送信先までの帯域を予約し、通信品質を確保するプロトコル）を用いて、ネットワーク経路上の帯域を確保した上で、その確保した品質に応じたサービスを受けるモデルであるが、ＲＳＶＰに関する情報を全てリアルタイムで管理する必要があるため、スケールしないという課題を持っていることが知られている（非特許文献１、非特許文献２参照）。
【０００６】
Ｄｉｆｆｓｅｒｖは、ネットワーク内において転送パケットにマーキングすることによりクラス分けを行い、ネットワーク転送ノードにおけるパケットスケジューリングにより、クラスごとの転送品質の差異化を行なうモデルである。Ｄｉｆｆｓｅｒｖモデルでは規定されたＰＨＢ（Per-Hop Behavior） によって各ネットワーク転送ノードでの転送品質が確保される。
【０００７】
サービスクラスに対応するＰＨＢは完全優先であるＥＦ（Expedited Forwarding）、最低帯域保証であるＡＦ（Assured Forwarding）が規定されており、市販のネットワーク転送ノードにも実装が進んでいる。
【０００８】
Ｄｉｆｆｓｅｒｖではネットワーク転送ノードごとの転送品質を差異化し、各転送ノードでの制御のみを規定するだけであるため、Ｉｎｔｆｓｅｒｖにおけるスケールしないという課題を解決する。しかしながら、品質保証型のサービスを提供するためには、サービス提供網内で統一された利用帯域に関する受付判定を行なわなければならないという課題と、サービスプロバイダはネットワーク内のリソースに応じてサービス提供品質を規定しなければならないという課題は依然として残っている（非特許文献３、非特許文献４、非特許文献５参照）。
【０００９】
サービス提供品質の規定に関してはＩＴＵ-Ｔにおいて、サービス品質を規定するためのパラメータ定義、転送品質クラス規定、サービスモデルが勧告化されている。
【００１０】
しかしながら、ＩＴＵ-Ｔ勧告 Y.1541における規定された転送品質をY.1221におけるサービスモデルで実現する手段に関しては検討されておらず、サービスプロバイダはネットワーク内のリソースに応じてサービス提供品質を規定しなければならない、という課題が依然として残る（非特許文献６、非特許文献７、非特許文献８参照）。
【００１１】
利用帯域に関する受付判定モデルとしては、トークンバケットパラメータに従ったネットワークへの入力トラヒックに対して受付判定を行なう仮想バッファ/トランクモデルがある。仮想バッファ/トランクモデルでは、トークンバケットモデルに従ったトラヒックの最悪条件をＯＮ／ＯＦＦトラヒックとしてモデル化し、申告帯域に対して、比例したバッファ量を仮想的に割り当てることによって、ネットワーク帯域を管理する帯域管理サーバによる各ネットワーク転送ノードのバッファ量を考慮した実効帯域（effective bandwidth）の積み上げ管理を以下の考え方に基づき行ない、論理的パケット損失率ゼロの受付判定を行なう。
【００１２】
＜トークンバケットから送出されるトラヒックの最大量＞
トークンバケットで規定されるトラヒックに関しては、時刻０からtまでに発生するトラヒックの最大量Ａ(ｔ)は、
Ａ(ｔ)=ｍｉｎ{Ｐｔ,σ+ρｔ}        ・・・・・・・・・・（１）
で規定される（図７参照）。ここで、ｍｉｎ｛，｝は｛，｝内の最小値を示し、Ｐ，ρ，σはトークンバケットのパラメータであり、それぞれピークレート，平均レート，バケットサイズを表している。
【００１３】
このとき、ピークレートでトラヒック送出が可能な最大時間長をＴとすると、式（１）から、ＰＴ=σ＋ρＴとなり、
Ｔ=σ／（Ｐ-ρ）                              ・・・・・（２）
を得る。
【００１４】
＜トークンバケットから送出されるトラヒックが使用するリソース量（ｂ,ｃ)の特性＞
図８に示すように、トークンバケットから送出された１本のセッションフローが確定的なキューイングシステムにおいてサービスされることを考える。
【００１５】
ｖ(ｔ)を時刻ｔにおける使用バッファ量、ｂを使用バッファ量の最大値、ｃをセッションフローに対して割り当てるリンク帯域、ただしρ≦ｃ≦Ｐとする。
【００１６】
フローが最大量Ａ(ｔ)でデータ送出するとき、時刻０よりＴまでの間は、使用バッファ量はＰ-ｃ≧０のレートで増加し、それ以降は
ｃ-ρのレートで減少することになるため、
ｂ=ｖ(Ｔ)=(Ｐ-ｃ)Ｔ=σ（Ｐ-ｃ）／（Ｐ-ρ）    ・・・・・・（３）
が得られる（図９参照）。
【００１７】
＜仮想バッファ/トランクモデル＞
今、トークンバケットパラメータ（Ｐｋ,ρｋ,σｋ）を持つセッションフローｋ（ｋ=１,２,・・・，Ｋ)がバッファ量Ｂ,リンク帯域Ｃを持つノードに多重されることを考える。
【００１８】
このとき、図１０に示すように各セッションフローｋに対してリンク帯域ｃｋ（ρｋ≦ｃｋ≦Ｐｋ)を仮想的に割り当てることを考える。ただし、仮想リソースの総量はリンク帯域Ｃを上回らないようにする。すなわち、
ｃ１＋ｃ２＋・・・＋ｃＫ≦Ｃ    ・・・・・・・・・・・・（４）
とする。
【００１９】
このとき、セッションフローｋが使用する仮想的なバッファリソースの最大値ｂｋは、式（３）と同様に、
ｂｋ=σｋ（Ｐｋ-ｃｋ）／（Ｐｋ-ρｋ）    ・・・・・・・（５）
で表すことができる。
【００２０】
全フローによる実際のバッファ使用量の最大値ｂは、仮想バッファ使用量の和を上回ることはないので、
Σｂｋ=Σσｋ（Ｐｋ-ｃｋ）／（Ｐｋ-ρｋ）≦Ｂ  ・・・・・（６）
が成り立てば、論理的なパケットロスがゼロになる。
【００２１】
言い換えると、式（５）を満たすＫ組の仮想リソース（ｂｋ,ｃｋ)に対して、式（４）および（６）が成り立てば、当該リンクにおける論理的なパケットロスはゼロになる。
【００２２】
各セッションフローに割り当てる仮想リソースを決定する第一の方法は、ｃｋを、
ｃｋ=Ｐｋ／（１+Ｂ(Ｐｋ-ρｋ)／（Ｃσｋ））    ・・・・・（７）
で与える（非特許文献９参照）。
【００２３】
この方法では、結果として得られるｂｋの値が、
ｂｋ／Ｂ＝ｃｋ／Ｃ      ・・・・・・・・・・・・・・・・・（８）
という関係を満たし、仮想帯域と仮想バッファ量のそれぞれが本来のリソース量に占める割合が等しくなり、リソース管理が簡単になるという利点がある。
【００２４】
仮想リソース割り当ての第二の方法として、式（６）で表される仮想バッファ量の総和を最小化するような割当方法が考えられている。この方式を定式化すると、
ｍｉｎ{Σσｋ（Ｐｋ-ｃｋ）／（Ｐｋ-ρｋ）｝    ・・・・・（９）
ただし、
Σｃｋ≦Ｃ,        ρ≦ｃｋ≦Ｐｋ        ・・・・・・・・・・・（１０）
となる。式（９）の解となるような仮想帯域割り当ては、以下の手順で求められる。
【００２５】
先ず、全てのフローに対してρｋに等しい仮想帯域を割り当てる。
その後、余った帯域Ｃ-Σρｋについては、フローごとに以下の式、
Ｔｋ=σｋ／（Ｐｋ-ρｋ）        ・・・・・・・・・（１１）
で計算されたピークレート送出可能時間Ｔｋについて、Ｔｋの値の大きなフローから順番に、Ｐｋ-ρｋだけ新たに追加して割り当てていく。この方式で仮想帯域ｃｋを割り当てた場合、式（６）が最小化されることが知られている（非特許文献１０参照）。
【００２６】
式（６）が成り立つことを条件とする受付判定法は、論理的なパケットロスをゼロとし、かつノードでの最大遅延時間もＢ／Ｃで保証できるため、フローの品質を保証することが可能な方式である。
【００２７】
第一の方法と第二の方法を比較すると、第一の方法はリソース割り当ての計算が簡単であることが利点となる。
【００２８】
第二の方法では計算された最大バッファ使用量は、第一の方法で計算される最大バッファ使用量以下となることが保証されているため、受付判定に用いた場合により多くのセッションを受け付けられ、収容効率に優れるという利点がある。
【００２９】
以上述べたように、仮想バッファ/トランクモデルを適用することによって、品質を保証した受付判定が可能となる。しかしながら、第一の方法では収容効率、第二の方法では計算の複雑さと管理すべき情報量の多さが課題となる。
【先行技術文献】
【非特許文献】
【００３０】
【非特許文献１】S.  Shenker and J.  Wroclawski,  “General Characterization Parameters for Integrated Service Network Elements,”Internet Engineering Task Force, RFC2215, Sep. 1997.
【非特許文献２】R. Braden, L. Zhang, S. Berson, S. Herzog and S. Jamin, “Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification,”  Internet Engineering Task Force, RFC2205, Sep. 1997.
【非特許文献３】S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang and  W. Weiss, “An Architecture for Differentiated Service,” Internet Engineering Task Force, RFC2475, Dec. 1998.
【非特許文献４】B. Davie, A. Charny, J. C.\ R. Bennett, K. Benson, J. Y. Le Boudec, W. Courtney, S. Davari, V. Firoiu and D. Stiliadis, “An Expedited Forwarding PHB (Per-Hop Behavior）,” Internet Engineering Task Force, RFC3246, Mar. 2002.
【非特許文献５】J. Heinanen, F. Baker, W. Weiss and J. Wroclawski, “Assured Forwarding PHB Group,” Internet Engineering Task Force, RFC2597, Jun. 1999.
【非特許文献６】“IP packet transfer and availability performance parameters,” ITU-T Recommendation Y.1540
【非特許文献７】“Network Performance Objectives for IP-Based Services,” ITU-T Recommendation Y.1541
【非特許文献８】“Traffic control and congestion control in IPbased networks,” ITU-T Recommendation Y.1221
【非特許文献９】A. Elwalid, D. Mitra and R. H.\ Wentworth, “A New Approach for Allocating Buffers and Bandwidth to Heterogeneous, Regulated Traffic in an ATM node,'‘ IEEE Journal on Selected Areas in Communications, vol. 13, no. 6, pp. 1115-1127, Aug. 1995.
【非特許文献１０】F. L. Preste, Z.-L. Zhang, J. Kurose and D. Towsley,  “Source Time Scale and Optimal Buffer/Bandwidth Tradeoff for Heterogenous Regulated Traffic in a Network Node,” IEEE/ACM Transactions on Networking, vol. 7, no. 4, pp. 490--501, Aug. 1999.
【発明の概要】
【発明が解決しようとする課題】
【００３１】
仮想リソース割り当てに関する技術は、以下のように表現できる。
いま、セッションフローｋのトラヒックパラメータ（Ｐｋ，ρｋ,σｋ）に対し、Ｘ軸方向に帯域リソース量、Ｙ軸方向にバッファリソース量をとる２次元平面上の方向ベクトルを、
ｖｐ(ｋ)＝(Ｐｋ,０)，ｖａ(ｋ)＝（ρｋ,σｋ）    ・・・・（１２）
とおく。
【００３２】
このとき、セッションフローｋが使用するリソース量（ｃｋ,ｂｋ）は、２つの方向ベクトルの内分点、すなわち、
ｖ(ｋ,α)＝（ｃｋ,ｂｋ）＝αｋ・ｖｐ(ｋ)＋（１-αｋ）・ｖａ(ｋ),(０≦αｋ≦１)
・・・・・・・・・・・・・・・・・・（１３）
であらわすことが可能であり、αｋ＝１のときがピークレート割当（Ｐｋ,０），αｋ＝０のときが平均レート割当（ρｋ,σｋ)に相当する（図１１）。
【００３３】
次に、セッションフローが複数の場合を考える。セッションフロー数＝２のとき、セッションフローｋおよびｌのトラヒックパラメータをそれぞれ（Ｐｋ，ρｋ,σｋ)，（Ｐｌ，ρｌ,σｌ)とおく。ただし、σｋ/（Ｐｋ-ρｋ）≧σｌ/（Ｐｌ-ρｌ）とする。
【００３４】
このときセッションフローｋ，ｌに割り当てられるリソース量の合計は、式（１３）で示される方向ベクトルの内分点の合成、
αｋ・ｖｐ(ｋ)＋（１-αｋ）・ｖａ(ｋ)＋αｌ・ｖｐ(ｌ)＋（１-αｌ）・ｖａ(ｌ),(０≦αｋ,αｌ≦１)
・・・・・・・・・・・（１４）
で示される。ただし、ｖｐ(ｋ)＝(Ｐｋ,０)，ｖａ(ｋ)＝（ρｋ,σｋ），ｖｐ(ｌ)＝(Ｐｌ,０)，ｖａ(ｌ)＝（ρｌ,σｌ）。
【００３５】
式（１４）によるリソース量の合計がとり得る範囲は、図１２の四辺形Ｒ１-Ｒ２-Ｒ４-Ｒ３の内部領域により与えられる。ここで、Ｒ１はセッションフローｋ,ｌともに平均レート割当、Ｒ２はセッションフローｋにピーク割当、セッションフローｌに平均割当、Ｒ３はセッションフローｋに平均割当、セッションフローｌにピーク割当、Ｒ４はセッションフローｋ，ｌともにピーク割当を実施した場合に相当し、線分Ｒ１-Ｒ２はセッションフローｌに平均割当、線分Ｒ２-Ｒ４はセッションフローｋにピーク割当、線分Ｒ１-Ｒ３はセッションフローｋに平均割当、線分Ｒ３-Ｒ４はセッションフローｌにピーク割当とした場合に相当する。
【００３６】
効率的なリソース割当という観点からは、線分Ｒ１-Ｒ２またはＲ２-Ｒ４上の割当が、帯域リソース、バッファリソースともに少なめの割当となり、線分Ｒ１-Ｒ３またはＲ３-Ｒ４の割当や、四辺形の内部領域の割当よりも望ましい。
【００３７】
一般的にセッションフロー数がより多い場合では、図１３に示すように、リソース割当の合計値は、２次元上の多角形領域であらわすことが可能である。全セッションフローに平均割当を行った場合の点、
ＲＡ＝ｖａ(１)＋ｖａ(２)＋・・・ｖａ(n)
と、全セッションフローにピーク割当を行った場合の点
ＲＰ＝ｖｐ(１)＋ｖｐ(２)＋・・・＋ｖｐ(n)
を結ぶ曲線の下限値は、以下のように作成できる。
【００３８】
（手順１）接続セッションフローを、式（１１）のＴｋが大きい順に並びかえる。
（手順２）最もＴｋの値が大きいセッションフロー１に対して、ｖａ(１)をｖｐ(１)に置き換えた
ＲＡ’=ｖｐ(１)＋ｖａ(２)＋・・・＋ｖａ(n)
とＲＡを結ぶ線分を考える。この線分が、セッションフロー１に対するリソース割当のみを式（１３）の範囲で変化させた場合の、全体のリソース割当量に相当する。
【００３９】
（手順３）次にＴｋの値が大きいセッションフロー２に対して同様の動作を行う。以下順番にセッションフローnまで繰り返し、点ＲＰに至る曲線を得る。
【００４０】
式（１１）のＴｋは、上記（手順２），（手順３）で作成する線分の傾きの大きさに相当するため、これを下回るリソース割当は実現不可能であり、下限となる。また、曲線の傾きは単調非減少であり,下に凸な曲線となる。
【００４１】
同様に、ＲＡとＲＰを結ぶ曲線の上限値は、
（手順１’）接続セッションフローを、式（１１）のＴｋが大きい順に並びかえる。
（手順２’）最もＴｋの値が小さいセッションフローnに対し、ｖａ(n)をｖｐ(n)に置き換えた
ＲＡ’’=ｖａ(１)＋ｖａ(２)＋・・・＋ｖｐ(n)
とＲＡを結ぶ線分を考える。この線分が、セッションフローnに対するリソース割当のみを式（１３）の範囲で変化させた場合の、全体のリソース割当量に相当する。
（手順３’）次にＴｋの値が小さいセッションフローｎ-１に対して同様の動作を行う。以下セッションフロー１まで繰り返し、点ＲＰに至る曲線を得る。
【００４２】
下限値の曲線と同様、（手順１’）〜（手順３’）を上回るリソース割当は実現不可能であり、上限となる。また、曲線の傾きは単調非増加であり,上に凸な曲線となる。したがって、両曲線に囲まれた領域は、凸多角形となる。
【００４３】
この領域と、式（４）および式（６）で規定される長方形領域ＯＢＣＤが交わる部分が、論理的パケットロスを０とできるリソース割当の実現値に相当する。特に、ＲＡとＲＰを結ぶ下に凸な曲線が、効率的なリソース割当に相当する。
【００４４】
従来技術における第一の方法では、リソース量を示すベクトル（ｃｋ,ｂｋ)の傾きが、Ｃ/Ｂと一致するように、αの値は
α＝(Ｃσ-Ｂρ）／（Ｃσ＋Ｂ（Ｐ-ρ））        ・・・・（１５）
で決定される（図１４参照）。
【００４５】
この第一の方法では、αはセッションフローのトラヒックパラメータにより変化するが、算出方法は式（１４）で一意に与えられ、他のセッションフローの影響を受けないことと、割当済みバッファリソースの、全バッファリソースに対する割合と、割当済み帯域リソースの、全帯域リソースに対する割合が等しくなり、どちらか一方のリソース割当のみを管理すれば良いというメリットがある。しかしながら、この第一の方法においては、リソースの割当方法の効率が必ずしも良くないという課題がある。
【００４６】
図１５では、第一の方法による、２つのセッションフローへのリソース割当の合計量がＳ１で示されているが、割当済みバッファリソースの、全バッファリソースに対する割合と、割当済み帯域リソースの、全帯域リソースに対する割合が等しくなるようなリソース割当の合計値がＳ２となるような、より効率の良い２セッションフローへのリソース割当が存在する。
【００４７】
第一の方法のもう一つの課題は、図１６に示すように、（σｋ/ρｋ＜Ｂ/Ｃ）となるようなセッションフローに対しては、式（７）によるリソース割当は実行できないことである。この場合、例えば図１６にあるように（ρｋ,ρｋ×Ｂ/Ｃ）というような、必要以上にバッファリソースを消費してしまう。
【００４８】
従来技術における第二の方法は、図１３における点ＲＡを始点として、点ＲＰに至る下に凸な曲線を追跡し、辺ＣＤ上の点ＲＱを求めることに相当している。点ＲＲのＹ軸座標がＢ以下であることと、多角形領域と四角形ＯＢＤＣが交わることは同値であるため、従来技術における第二の方法は、仮想リソース割り当て方式の中で最適な方式の一つといえる。
【００４９】
しかしながら、第二の方法では、下に凸な曲線ＲＡ-ＲＰを構成する全ての点の情報を常に管理する必要がある。この点に関して、第二の方法は以下に挙げるような問題点を有する。
【００５０】
（１）曲線ＲＡ-ＲＰは接続セッションフロー数に等しい数の点により構成され、セッションフロー数に伴って増加する。
【００５１】
（２）下に凸な曲線を構成するためには、式（１１）にあるＴｋの値が降順となるように並び替えておく必要があり,新規セッションフローを接続するごとに順序を改める必要がある。
【００５２】
（３）接続終了や新規セッションフローの追加により全ての点の位置が変化するため、再計算が必要となる。
以上の問題点は、実時間性を要求される受付判定において処理時間の増加をもたらすという課題につながっている。
【００５３】
そこで、本発明は、ピークレート、平均レート、バケットサイズで規定するトークンバケットモデルで通信セッションフローの特性を表すネットワークで、各セッションフローに対する排他的なリソース割当法により論理的パケット損失をゼロにすることで品質保証を実現することができ、接続セッションフローの本数に依存せず、一定の管理情報と処理量を要するのみで、効率的なリソース割当が可能な呼受付制御方法および装置、ならびにそのためのプログラムを提供することである。
【課題を解決するための手段】
【００５４】
本発明では、図１３における下に凸多角形領域内の１点（以下、この点をＲＲとする）を点ＲＡおよびＲＰと併せて常に管理し、曲線ＲＡ-ＲＲ-ＲＰが四角形ＯＢＤＣと交わるか否かによりリソース割当の可否を判断するようにしている。この方法で得られる曲線ＲＡ-ＲＲ-ＲＰは、凸多角形の性質から常に凸多角形の領域内に存在するので、曲線上の点は全てリソース割当総量の候補となりうる。
【００５５】
この曲線は、従来の第二の方法で得られる下に凸な曲線より常に上にあるため、リソース割当の効率性としては第二の方法の方が優れるが、管理する曲線上の点がセッションフロー数に関係なく３点と一定であり、新規接続セッションまたは終了セッションの情報のみを用いて更新可能であることから、第二の方法が持つ課題を克服した方法となっている。
【００５６】
また、本発明では、従来技術における第一の方法における式（７）によるリソース割当が実施できないようなセッションフローについても問題なく対応可能であり、第一の方法よりも効率性としては勝っていることが期待できる。
【００５７】
以下、本発明のより具体的な構成を述べる。
ａ）本発明に係る呼受付制御方法は、接続セッションフローにリンク帯域およびバッファ量の２種類のリソースを個別に割り当てて、設備量に収まる範囲内で新規接続セッションフローを受け付けるコンピュータを用いた呼受付制御方法において、コンピュータ制御により、平均レートリソース割当法、ピークレートリソース割当法の２種類のリソース割当法に加え、第３のリソース割当法を含めた３種類のリソース割当法を同時に機能させる手順と、コンピュータ制御により、前記３種類のリソース割当法のいずれかで得られたリソース量の総和が設備量に収まっている場合に、あるいは、前記３種類のリソース割当法のそれぞれで得られるリソース量の総和が全て設備量を超えている場合であっても前記リンク帯域およびバッファ量の２種類のリソース量を横軸と縦軸にしたグラフ上に前記３種類のリソース割当法のそれぞれで得られたリソース量の総和をプロットしたとき該プロットされた３つの点のそれぞれを結ぶ線分上に設備量の範囲に収まっている点がある場合に、新規セッションフローの接続を許可する手順とを有することを特徴としている。
【００５８】
ｂ）また、上記ａ）において、前記第３のリソース割当法は、ピークレートＰｋ，平均レートρｋ，バケットサイズσｋのトークンバケットパラメータを持つセッションフローｋ（ｋ=１,２,・・・，Ｋ)がバッファ量Ｂ,リンク帯域Ｃを持つノードに多重される場合、σｋ／（Ｐｋ-ρｋ）が一定の閾値Ｘを超えるセッションフローに対してはピークレートリソース割当法を、σｋ／（Ｐｋ-ρｋ）が前記一定の閾値Ｘ未満であるセッションフローに対しては平均レートリソース割当法を行うリソース割当法であることを特徴としている。
【００５９】
このように、排他的なリソース割当法により論理的パケット損失をゼロにすることで品質保証を実現することができ、接続セッションフローの本数に依存せず、一定の管理情報と処理量を要するのみで、効率的なリソース割当が可能になる。
【００６０】
ｃ）また、上記ａ）またはｂ）において、前記第３のリソース割当法では、第３のリソース割当法によるリソース割当が設備量を超える状況があった場合、リンク帯域リソースが超過した場合には、リソース割当法として、リンク帯域リソースをより少なく、バッファリソースをより多く与えるリソース割当法に変更し、逆にバッファリソース割当が設備量を超える状況があった場合、リソース割当法として、リンク帯域リソースをより多く、バッファリソースをより少なく与えるリソース割当法に変更することを特徴としている。
この場合、第３のリソース割当法によりリソース配分が設備量を超える確率を小さくすることができ受付可能セッションフロー数を増加させ、収容効率を高めることができる。
【００６１】
ｄ）上記ｃ）において、第３のリソース割当法では、一定の閾値Ｘについて、第３のリソース割り当て方法によるリソース配分が設備量を超える状況があった場合、帯域リソースが超過した場合には該一定の閾値Ｘを一定値ｄｘだけ大きく変更し、バッファリソースが超過した場合には該一定の閾値Ｘを一定値ｄｘだけ小さく変更することを特徴としている。
このような第３のリソース割当法を採用することにより、リソース割当が設備量を超える確率を小さくすることで受付可能セッションフロー数を増加させ、収容効率を高めることができる。
【００６２】
ｅ）また、上記ｃ）またはｄ）において、前記変更は、セッションフローの接続数が０になった時点で実行することを特徴としている。
このように、リソース割当法の変更や一定の閾値の変更を、セッションフローの接続数が０となった時点で実行することにより、第３のリソース割当法により個別のセッションフローに割り当てられたリソース量が、セッションフローの接続中に変化してしまうことを防ぐことができる。
【００６３】
ｆ）本発明に係るプログラムは、コンピュータに、上記ａ）からｅ）のいずれかの呼受付制御方法における各手順を実行させるプログラムである。
【００６４】
ｇ）本発明に係る呼受付制御装置は、接続セッションフローにリンク帯域およびバッファ量の２種類のリソースを個別に割り当てて、設備量に収まる範囲内で新規接続セッションフローを受け付けるコンピュータを用いた呼受け付け制御装置において、コンピュータ制御により、平均レートリソース割当法、ピークレートリソース割当法の２種類のリソース割当法に加え、第３のリソース割当法を含めた３種類のリソース割当法を同時に機能させる手段と、コンピュータ制御により、前記３種類のリソース割当法のいずれかで得られたリソース量の総和が設備量に収まっている場合に、あるいは、前記３種類のリソース割当法のそれぞれで得られるリソース量の総和が全て設備量を超えている場合であっても前記リンク帯域およびバッファ量の２種類のリソース量を横軸と縦軸にしたグラフ上に前記３種類のリソース割当法のそれぞれで得られたリソース量の総和をプロットしたとき該プロットされた３つの点のそれぞれを結ぶ線分上に設備量の範囲に収まる点がある場合に、新規セッションフローの接続を許可する手段とを有することを特徴としている。
【００６５】
ｈ）本発明に係る通信ルータまたはネットワーク制御装置は、上記ｇ）の呼受付制御装置を内蔵したことを特徴とし、本発明に係るネットワークは、このような通信ルータまたはネットワーク制御装置を用いたことを特徴とするネットワークである。
【発明の効果】
【００６６】
本発明によれば、ピークレート、平均レート、バケットサイズで規定するトークンバケットモデルで通信セッションフローの特性を表すネットワークで、各セッションフローに対する排他的なリソース割当法により論理的パケット損失をゼロにすることで品質保証を実現することができ、接続セッションフローの本数に依存せず、一定の管理情報と処理量を要するのみで、効率的なリソース割当が可能な呼受付制御方法および装置、ならびにそのためのプログラムを実現することができる。
【図面の簡単な説明】
【００６７】
【図１】本発明に係る呼受付制御方法を説明するためのフローチャートである（実施例１）。
【図２】ピークレートリソース割当法、平均レートリソース割当法、第３のリソース割当法によるリソース量の総和の全てが四角形ＯＢＣＤの外部にあるが、線分（Ｐ’，０）-（Ｆ’，Ｇ’)が四角形ＯＢＣＤと交わっている場合の例を説明するための図である。
【図３】ピークレートリソース割当法、平均レートリソース割当法、第３のリソース割当法によるリソース量の総和の全てが四角形ＯＢＣＤの外部にあるが、線分（Ｆ’，Ｇ’）-（ρ’，σ’）が四角形ＯＢＣＤと交わっている場合の例を説明するための図である。
【図４】本発明に係る呼受付制御方法を説明するためのフローチャートである（実施例３）。
【図５】本発明に係る実施例６を説明するための図である（本発明に係る呼受付制御方法を通信ルータに組み込んだ例）。
【図６】本発明に係る実施例７を説明するための図である（本発明に係る呼受付制御方法をネットワーク制御装置に組み込んだ例）。
【図７】トークンバケットで規定されるセッションフローから転送されるデータの最大量の時間経過を示す図である。
【図８】トークンバケットで規定される１本のセッションフローから転送されるデータが仮想バッファ／トランクシステムに加わる様子を模した図である。
【図９】トークンバケットで規定されるセッションフローが仮想バッファ／トランクシステムに加わった時の仮想バッファ使用量の時間経過を示す図である。
【図１０】トークンバケットで規定される複数のセッションフローが仮想バッファ／トランクシステムに加わる様子を模した図である。
【図１１】Ｘ軸方向に帯域リソース量、Ｙ軸方向にバッファリソース量をとる２次元平面を用いてセッションフローが使用するリソース量を説明するための図である（その１）。
【図１２】Ｘ軸方向に帯域リソース量、Ｙ軸方向にバッファリソース量をとる２次元平面を用いてセッションフローが使用するリソース量を説明するための図である（その２；リソース量の合計がとり得る範囲を示す）。
【図１３】Ｘ軸方向に帯域リソース量、Ｙ軸方向にバッファリソース量をとる２次元平面を用いてセッションフローが使用するリソース量を説明するための図である（その３；セッションフロー数がより多い場合）。
【図１４】Ｘ軸方向に帯域リソース量、Ｙ軸方向にバッファリソース量をとる２次元平面を用いてセッションフローが使用するリソース量を説明するための図である（その４;リソース量を示すベクトルが（リンク帯域Ｃ／バッファ量Ｂ）と一致する場合）。
【図１５】Ｘ軸方向に帯域リソース量、Ｙ軸方向にバッファリソース量をとる２次元平面を用いてセッションフローが使用するリソース量を説明するための図である（その５）。
【図１６】Ｘ軸方向に帯域リソース量、Ｙ軸方向にバッファリソース量をとる２次元平面を用いてセッションフローが使用するリソース量を説明するための図である（その６）。
【発明を実施するための形態】
【００６８】
＜概要＞
本発明は、ピークレートリソース割当法、平均レートリソース割当法という簡便な割当法に加え、新たに第３のリソース割当法を計算するのみで受付判定を行うことにより、従来技術における第二の方法のような、リソース効率には優れるが受付判定に必要な情報量や計算量がセッションフロー数とともに増加してしまう状況を回避することで、大規模ネットワークにおいても実装可能な方法を実現したものである。
【００６９】
また、リソース割当の実行可能な領域が凸多角形となる性質から、３種類のリソース割当法に対応する３点を結ぶ線分上の全ての点が実行可能な領域内にある性質を利用して、３種類のリソース割当が全て設備量を超過していても実行可能な、効率的なリソース割当が可能な場合が存在することを判定することで、より多くのセッションフローを受付可能な判定方法を実現可能とした。
【００７０】
さらに、第３のリソース割当法において、周期的に割当方法を見直す（更新）ことにより、収容効率をさらに高めることが可能となる方法を提案する。
【００７１】
＜記号の説明＞
本発明の実施例の説明で用いる記号を以下のように定める。
接続セッションフローのピークレートの合計値をＰ、平均レートの合計値をρ、バケットサイズの合計値をσ、接続セッションフローの総数をＮとする。ピーク割当を行った場合のリソース総量をＲＰ＝（Ｐ,０）、平均割当を行った場合のリソース総量をＲＡ＝（ρ，σ）とする。
【００７２】
セッションフローｋのトラヒックパラメータ（Ｐｋ,ρｋ,σｋ）に対し、ピークレートリソース割当法、平均レートリソース割当法以外の第３のリソース割当法を決め、その割当法による帯域リソースの決定方法を関数ｆ（Ｐｋ,ρｋ,σｋ）、バッファリソースの決定方法を関数ｇ（Ｐｋ,ρｋ,σｋ)とする。
【００７３】
上記第３のリソース割当法を行った場合のリソース総量をＲＲ＝（Ｆ,Ｇ）とする。上記第３のリソース割当法を行った場合のリソース総量ＲＲが、設備量を超過した場合の値を（Ｃ*，Ｂ*）とする。
【００７４】
受付判定を行うため、既接続セッションフローと新規受付を要求するセッションフローのリソース量の合計値を表す記号として、Ｒ’，ρ’，σ’，Ｆ’，Ｇ’を用いる。
【００７５】
ネットワークノードの設備量として、帯域リソース量の上限値をＣ、バッファリソース量の上限値をＢとする。
【００７６】
＜実施例１＞
図１は、本発明に係る呼受付制御方法の一実施例を説明するためのフローチャートである。
（ステップＳ１０１）
初期条件として接続セッションフローが存在しない状況を仮定し、Ｐ，ρ，σ，Ｆ，Ｇを全て０とする。
【００７７】
（ステップＳ１０２）
トラヒックパラメータ（Ｐｋ,ρｋ,σｋ）を有する新規受付を要求するセッションフローｋが到着したか、接続終了かを判断し、新規受付を要求するセッションフローｋが到着した場合はステップＳ１０３に移り、接続終了の場合はステップＳ１０９に移る。
【００７８】
（ステップＳ１０３）
ステップＳ１０２で新規セッションフローｋが到着した場合は、そのトラヒックパラメータ（Ｐｋ,ρｋ,σｋ）を抽出する。
【００７９】
（ステップＳ１０４）
セッションフローｋを接続した場合に必要となるリソース量の総和を以下のように計算する。
Ｐ’＝Ｐ+Ｐｋ，ρ’＝ρ＋ρｋ，σ’＝σ＋σｋ，Ｆ’=Ｆ＋ｆ（Ｐｋ,ρｋ,σｋ)，Ｇ’＝Ｇ＋ｇ（Ｐｋ,ρｋ,σｋ)
【００８０】
（ステップＳ１０５）
ピークレートリソース割当法、平均レートリソース割当法、第３のリソース割当法によるリソース量の総和（Ｐ’，０）、（ρ’，σ’）、（Ｆ’，Ｇ’）のいずれかが四角形ＯＢＣＤの内部にある、すなわち、
Ｐ’≦Ｃ
ρ’≦Ｃ  かつ  σ’≦Ｂ
Ｆ’≦Ｃかつ  Ｇ’≦Ｂ
のいずれかが成り立てば（ステップＳ１０５：Ｙ）、設備量（Ｃ，Ｂ）の範囲内でセッションフローｋを含むリソース割当が設備量の範囲内に収まると判断し、ステップＳ１０７へ移る。上記条件の全てが成り立たない場合は（ステップＳ１０５：Ｎ）、ステップＳ１０６へ移る。
【００８１】
（ステップＳ１０６）
ピークレートリソース割当法、平均レートリソース割当法、第３のリソース割当法によるリソース量の総和（Ｐ’，０）、（ρ’，σ’）、（Ｆ’，Ｇ’）の全てが四角形ＯＢＣＤの外部にある場合であっても、線分（Ｐ’，０）-（Ｆ’，Ｇ’)が四角形ＯＢＣＤと交わっている場合（図２参照）、あるいは線分（Ｆ’，Ｇ’）-（ρ’，σ’）が四角形ＯＢＣＤと交わっている場合（図３参照）は、設備量（Ｃ,Ｂ）の範囲内でセッションフローｋを含むリソース割当で、設備量の範囲内に収まると判断できるので、ステップＳ１０７へ移る。上記条件が成り立たない場合は、ステップＳ１０８へ移る。
【００８２】
（ステップＳ１０７）
既接続セッションおよびセッションｋに対して、設備量の範囲内に収まるリソース割当が可能であると判断し、セッションフローｋの接続を受け付け、ピークレートリソース割当法、平均レートリソース割当法、第３のリソース割当法によるリソース量の総和を更新し、Ｐ＝Ｐ’、ρ＝ρ’、σ＝σ’、Ｆ＝Ｆ’、Ｇ＝Ｇ’とする。
【００８３】
（ステップＳ１０８）
既接続セッションフローおよびセッションフローｋに対して、設備量の範囲内に収まるリソース割当が不可能であると判断し、セッションフローｋの接続を拒否する。
【００８４】
（ステップＳ１０９）
トラヒックパラメータ（Ｐｊ,ρｊ,σｊ)を有する既接続セッションフローｊの終了要求が到着した場合にそのパラメータＰｊ,ρｊ,σｊを抽出する。
【００８５】
（ステップＳ１１０）
セッションフローｊの接続を終了する。ピークレートリソース割当法、平均レートリソース割当法、第３のリソース割当法によるリソース量の総和を更新し、Ｐ＝Ｐ-Ｐｊ、ρ＝ρ-ρｊ、σ＝σ-σｊ、Ｆ＝Ｆ-ｆ（Ｐｊ,ρｊ,σｊ)、Ｇ＝Ｇ-ｇ（Ｐｊ,ρｊ,σｊ)とする。
【００８６】
＜実施例２＞
本実施例では、実施例１における第３のリソース割当法として、特に以下の式を用いる。
ｆ（Ｐｋ,ρｋ,σｋ)＝ρｋ  ｉｆ σｋ／（Ｐｋ-ρｋ）≦Ｘ
＝Ｐｋ  ｉｆ σｋ／（Ｐｋ-ρｋ）＞Ｘ
ｇ（Ｐｋ,ρｋ,σｋ)＝σｋ  ｉｆ σｋ／（Ｐｋ-ρｋ）≦Ｘ
＝０    ｉｆ σｋ／（Ｐｋ-ρｋ）＞Ｘ
【００８７】
これは、σｋ／（Ｐｋ-ρｋ）の値が一定の閾値Ｘを超えるセッションフローに対してはピークレートリソース割当を行い、Ｘ未満のセッションフローに対しては平均レートリソース割当を行う方法に相当し、図１３における下に凸な曲線上の１点に対応する例である。その他の実施方法については、実施例１と同一である。
【００８８】
＜実施例３＞
本実施例では、実施例１における第３のリソース割当法の効率を向上させるため、周期的に実施例２で示した関数ｆ、ｇを更新することを特徴とする例である。図４は、本実施例を説明するためのフローチャートである。
【００８９】
（ステップＳ２０１）
初期条件として、接続セッションフローが存在しない状況を仮定し、Ｐ，ρ，σ，Ｆ，Ｇ，Ｎ，Ｃ*，Ｂ*を全て０とする。
【００９０】
（ステップＳ２０２）
トラヒックパラメータ（Ｐｋ,ρｋ,σｋ)を有する新規受付を要求するセッションフローｋが到着したか、接続終了かを判断し、新規受付を要求するセッションフローｋが到着した場合はステップＳ２０３に移り、接続終了の場合はステップＳ２１１に移る。
【００９１】
（ステップＳ２０３）
ステップＳ２０２で新規セッションフローｋが到着した場合は、そのトラヒックパラメータ（Ｐｋ,ρｋ,σｋ）を抽出する。
【００９２】
（ステップＳ２０４）
セッションフローｋを接続した場合に必要となるリソース量の総和を以下のように計算する。
Ｐ’＝Ｐ+Ｐｋ，ρ’＝ρ＋ρｋ，σ’＝σ＋σｋ，Ｆ’=Ｆ＋ｆ（Ｐｋ,ρｋ,σｋ)，Ｇ’＝Ｇ＋ｇ（Ｐｋ,ρｋ,σｋ)
【００９３】
（ステップＳ２０５）
ピークレートリソース割当法、平均レートリソース割当法、第３のリソース割当法によるリソース量の総和（Ｐ’，０）、（ρ’，σ’）、（Ｆ’，Ｇ’）のいずれかが四角形ＯＢＣＤの内部にある、すなわち、
Ｐ’≦Ｃ
ρ’≦Ｃ かつ σ’≦Ｂ
Ｆ’≦Ｃ かつ Ｇ’≦Ｂ
のいずれかが成り立てば、設備量（Ｃ，Ｂ）の範囲内でセッションフローｋを含むリソース割当が設備量の範囲内に収まると判断し、ステップＳ２０９へ移る。上記条件の全てが成り立たない場合は、ステップＳ２０６へ移る。
【００９４】
（ステップＳ２０６，ステップＳ２０７）
第３のリソース割当法によるリソース量の総和（Ｆ’，Ｇ’）が四角形ＯＢＣＤの外部に出た場合、（Ｃ*，Ｂ*）の値が初期値から更新されていなければ（ステップＳ２０６：Ｙ）、（Ｆ’，Ｇ’）により更新する（ステップＳＳ２０７）。既に（Ｃ*，Ｂ*）の値が更新済みである場合は（ステップＳ２０６：Ｎ）、さらに更新を行わないでステップＳ２０８に移る。
【００９５】
（ステップＳ２０８）
ピークレートリソース割当法、平均レートリソース割当法、第３のリソース割当法によるリソース量の総和（Ｐ’，０）、（ρ’，σ’）、（Ｆ’，Ｇ’）の全てが四角形ＯＢＣＤの外部にある場合であっても、線分（Ｐ’，０）-（Ｆ’，Ｇ’)が四角形ＯＢＣＤと交わっている（図２参照）、あるいは線分（Ｆ’，Ｇ’）-（ρ’，σ’）が四角形ＯＢＣＤと交わっていれば（図３参照）、設備量（Ｃ,Ｂ）の範囲内でセッションｋを含むリソース割当で、設備量の範囲内に収まると判断できるので、ステップ６へ移る。上記条件が成り立たない場合は、ステップＳ２０９へ移る。
【００９６】
（ステップＳ２０９）
既接続セッションフローおよびセッションフローｋに対して、設備量の範囲内に収まるリソース割当が可能であると判断し、セッションフローｋの接続を受け付ける。ピークレートリソース割当法、平均レートリソース割当法、第３のリソース割当法によるリソース量の総和を更新し、Ｐ＝Ｐ’、ρ＝ρ’、σ＝σ’、Ｆ＝Ｆ’、Ｇ＝Ｇ’、Ｎ＝Ｎ＋１とする。
【００９７】
（ステップＳ２１０）
既接続セッションフローおよびセッションフローｋに対して、設備量の範囲内に収まるリソース割当が不可能であると判断し、セッションフローｋの接続を拒否する。
【００９８】
（ステップＳ２１１）
トラヒックパラメータ（Ｐｊ,ρｊ,σｊ)を有する既接続セッションフローｊの終了要求が到着した場合にそのパラメータＰｊ,ρｊ,σｊを抽出する。
【００９９】
（ステップＳ２１２）
セッションフローｊの接続を終了する。ピークレートリソース割当法、平均レートリソース割当法、第３のリソース割当法によるリソース量の総和を更新し、Ｐ＝Ｐ-Ｐｊ、ρ＝ρ-ρｊ、σ＝σ-σｊ、Ｆ＝Ｆ-ｆ（Ｐｊ,ρｊ,σｊ)、Ｇ＝Ｇ-ｇ（Ｐｊ,ρｊ,σｊ)、Ｎ＝Ｎ-１とする。
【０１００】
（ステップＳ２１３）
Ｎ＝０であれば、初期条件同様接続セッションフローが存在しない状況となるので、（Ｃ*，Ｂ*）の値が更新されていれば（ステップＳ２１３：Ｙ）、第３のリソース割当法を改善する余地があると判断し、ステップＳ２１４で関数ｆ(.),ｇ(.)を更新する。
【０１０１】
図２に示すように、（Ｂ*／Ｃ*＞Ｂ／Ｃ）であれば、第３のリソース割当法はバッファリソースの割当が多めであると判断し、バッファリソースの割当が少なく、かつ帯域リソースの割当が多くなるように関数ｆ(.)，ｇ(.)の更新を検討する。反対に、図３に示すように、（Ｂ*／Ｃ*＜Ｂ／Ｃ）であれば、第３のリソース割当法は帯域リソースの割当が多めであると判断し、帯域リソースの割当が少なく、かつバッファリソースの割当が多くなるように関数ｆ(.)，ｇ(.)の更新を検討する。
【０１０２】
この更新（変更）は、セッションフローの接続数が０になった時点で実行する。これにより、第３のリソース割当法により個別のセッションフローに割り当てられたリソース量が、セッションフローの接続中に変化してしまうことを防ぐことができる。
【０１０３】
（Ｂ*／Ｃ*＝Ｂ／Ｃ）であれば、第３のリソース割当法は、帯域リソース、バッファリソースのバランスがとれた割当となっていると判断し、特に関数ｆ(.)，g(.)の更新は検討しない。
【０１０４】
＜実施例４＞
本実施例では、実施例３における第３のリソース割当法として、特に以下の式を用いる。
ｆ（Ｐｋ,ρｋ,σｋ)＝Ｐｋ  ｉｆ σｋ／（Ｐｋ-ρｋ）≦Ｘ
＝ρｋ  ｉｆ σｋ／（Ｐｋ-ρｋ）＞Ｘ
ｇ（Ｐｋ,ρｋ,σｋ)＝０    ｉｆ σｋ／（Ｐｋ-ρｋ）≦Ｘ
＝σｋ  ｉｆ σｋ／（Ｐｋ-ρｋ）＞Ｘ
【０１０５】
これは、σｋ／（Ｐｋ-ρｋ）の値が一定の閾値Ｘを超えるセッションフローに対してはピークレートリソース割当を行い、Ｘ未満のセッションフローに対しては平均レートリソース割当を行う方法に相当し、図１３における下に凸な曲線上の１点に対応する例である。その他の実施方法については、実施例３と同一である。
【０１０６】
＜実施例５＞
本実施例では、実施例４に示す方法において、関数ｆ(.)，ｇ(.)の更新方法として、特に以下の方法を用いる。
Ｂ*／Ｃ*＞Ｂ／Ｃならば、Ｘ＝Ｘ-ｄｘ
Ｂ*／Ｃ*＜Ｂ／Ｃならば、Ｘ＝Ｘ＋ｄｘ
すなわち、Ｂ*／Ｃ*とＢ／Ｃの大小関係により、実施例４で用いる閾値Ｘを、一定値ｄｘだけ変化させる。
例えば、（Ｂ*／Ｃ*＞Ｂ／Ｃ）であれば、閾値Ｘをｄｘだけ小さくし、ピーク割当を行うセッションフローが多くなることで帯域リソースの割当が多くなるよう調整し、反対に（Ｂ*／Ｃ*＜Ｂ／Ｃ）であれば、閾値Ｘをｄｘだけ大きくし、平均割当を行うセッションフロー数が多くなることでバッファリソースの割当が多くなるように調整する。その他の実施方法については、実施例４と同一である。
【０１０７】
この一定の閾値の変更（調整）は、セッションフローの接続数が０になった時点で実行する。これにより、第３のリソース割当法により個別のセッションフローに割り当てられたリソース量が、セッションフローの接続中に変化してしまうことを防ぐことができる。
【０１０８】
なお、本発明に係るコンピュータを用いた呼受付制御方法（特に図１，４のフローチャート参照）は、後述するように（実施例６，７参照）、通信ルータやネットワーク制御装置などのネットワーク機器を構成するコンピュータのＣＰＵやメモリなどのハードウェアにより、当該処理に対応するプログラムを読み込んで実行することにより実現される。なお、当該処理に対応するプログラムは、インターネットなどのネットワークを介して、またＣＤ-ＲＯＭ、ＤＶＤ、ＦＤなどの記録媒体を介して市場に流通させることができることはいうまでもない。
【０１０９】
＜実施例６＞
本実施例は、図５に示すネットワーク上において、本発明に係る呼受付制御方法を実現した実施例である（通信ルータが本発明に係る呼受付制御装置の機能を備えている場合）。
【０１１０】
（ステップ（ａ））
ユーザのターミナル装置（ＴＥ）１１から、新規セッションフローの接続要求が、トラヒックパラメータ情報とともにネットワーク制御装置１２に通知される。ＵＮＩ １３は、ユーザネットワーク・インタフェース装置である。
【０１１１】
（ステップ（ｂ））
ネットワーク制御装置１２は、新規セッションの通信経路上の通信ルータ（Ｒ）１４,１５に、新規セッションフローのトラヒックパラメータを通知する。
【０１１２】
（ステップ（ｃ））
各通信ルータ（Ｒ）１４，１５は、新規セッションフローを受け付ける。これにより、通信ルータ（Ｒ）１４，１５・・が有する設備量の範囲内でのリソース割当が可能かどうかを、実施例１〜６のいずれかの方法を用いて判定し、受付可否をネットワーク制御装置１２に通知する。
【０１１３】
（ステップ（ｄ））
ネットワーク制御装置１２は、新規セッションフローの通信経路上の全ての通信ルータ（Ｒ）１４，１５・・から新規セッションフローの受付許可が得られた場合、新規セッションフローの接続許可をユーザのターミナル装置（ＴＥ）１１および通信ルータ（Ｒ）１４，１５・・に通知する（新規セッションフローの接続）。
【０１１４】
もしいずれかの通信ルータ（Ｒ）から受付不可を通知された場合、新規セッションフローは受け付けられないのでユーザのターミナル装置（ＴＥ）１１に接続拒否を通知し、通信ルータ（Ｒ）１４，１５には新規セッションフローの通信終了を通知する（ステップ（ｇ）へ）。
【０１１５】
（ステップ（ｅ））
通信中のセッションフローを終了する場合、ユーザのターミナル装置（ＴＥ）１８からネットワーク制御装置１２に当該セッションの終了が通知される。
【０１１６】
（ステップ（ｆ））
ネットワーク制御装置１２は、当該セッションの通信系路上の通信ルータ（Ｒ）１６に対し、当該セッションの通信終了を通知する。
【０１１７】
（ステップ（ｇ））
通信ルータ（Ｒ）１６は、通信終了したセッションフローに関する情報を削除する。
【０１１８】
＜実施例７＞
本実施例は、図６に示すネットワーク上において、本発明に係る呼受付制御方法を実現した実施例である（ネットワーク制御装置が本発明に係る呼受付制御装置の機能を備えている場合）。
【０１１９】
（ステップ（ａ））
ユーザのターミナル装置（ＴＥ）１１から、新規セッションフローの接続要求が、トラヒックパラメータ情報とともにネットワーク制御装置１２に通知される。ＵＮＩ １３は、ユーザネットワーク・インタフェース装置である。
【０１２０】
（ステップ（ｂ））
ネットワーク制御装置１２は、新規セッションフローの通信経路上の通信ルータ（Ｒ）１４，１５，１６において、新規セッションフローを受け付けることでこれら各通信ルータ（Ｒ）１４，１５，１６が有する設備量の範囲内でのリソース割当が可能かどうかを、実施例１〜６のいずれかの方法を用いて判定し、受付可否を判定する。
【０１２１】
（ステップ（ｃ））
ネットワーク制御装置１２は、新規セッションフローの通信経路上の全ての通信ルータ（Ｒ）において、設備量の範囲内でのリソース割当が可能と判断した場合、新規セッションフローの接続許可をユーザターミナル装置（ＴＥ）に通知する（新規セッションフローの接続）。
【０１２２】
もしいずれかの通信ルータ（Ｒ）において、設備量の範囲内でのリソース割当が不可と判断した場合、新規セッションフローは受け付けられないのでユーザターミナル装置（ＴＥ）１１に接続拒否を通知する。
【０１２３】
（ステップ（ｄ））
通信中のセッションフローを終了する場合、ユーザのターミナル装置（ＴＥ）１８からネットワーク制御装置１２に当該セッションフローの終了が通知される。
【０１２４】
（ステップ（ｅ））
ネットワーク制御装置１２は、当該セッションフローに関する情報を削除する。
【０１２５】
上記実施例によれば、論理的パケット損失をゼロにすることで品質保証を実現でき、接続セッションフローの本数に依存せず、一定の管理情報と処理量を要するのみで効率的なリソース割当が可能になる。
【符号の説明】
【０１２６】
１１：ＴＥ（ユーザターミナル装置）
１２：ネットワーク制御装置
１３：ＵＮＩ（ユーザネットワーク・インタフェース装置）
Ａ（ｔ）：トラヒックの最大量
Ｐ：ピークレート
Ｔ：ピークレートでトラヒック送出可能な最大時間長
σ：バケットサイズ
ｖ（ｔ）：時刻ｔの使用バッファ量
ｂ：使用バッファ量の最大値
ｃ：セッションフローに対して割り当てるリンク帯域
Ｂ：バッファ量
Ｃ：リンク帯域
ρ：平均レート
【図１】
2011015025.tif 000003
【図２】
2011015025.tif 000004
【図３】
2011015025.tif 000005
【図４】
2011015025.tif 000006
【図５】
2011015025.tif 000007
【図６】
2011015025.tif 000008
【図７】
2011015025.tif 000009
【図８】
2011015025.tif 000010
【図９】
2011015025.tif 000011
【図１０】
2011015025.tif 000012
【図１１】
2011015025.tif 000013
【図１２】
2011015025.tif 000014
【図１３】
2011015025.tif 000015
【図１４】
2011015025.tif 000016
【図１５】
2011015025.tif 000017
【図１６】
2011015025.tif 000018