呼受付制御方法、呼受付制御システム、及びネットワークシステム
【課題】安定した収容効率を実現するための受付判定技術を提供する。
【解決手段】呼受付制御方法において、新規セッションフローの受付要求を受信する受信ステップと、リソース割り当て方法の候補として、ピーク割り当てあるいは平均割り当ての２種類のいずれかを選択する選択ステップと、既に接続しているセッションフローへの割り当てリソース量に、前記選択されたリソース割り当て方法により定まるリソース量を加えた割り当てリソース総量が、リソース設備総量に収まる範囲内であれば前記新規セッションフローの要求を受け付ける受付判定ステップと、を備え、前記選択ステップにおいて、前記既に接続しているセッションフローへの割り当てリソース量に、前記新規セッションフローへの割り当てリソース量を加えて得られる帯域リソース量とバッファリソース量の比が、帯域リソースの設備総量とバッファリソースの設備総量の比により近くなる割り当て方法を選択する。
【解決手段】呼受付制御方法において、新規セッションフローの受付要求を受信する受信ステップと、リソース割り当て方法の候補として、ピーク割り当てあるいは平均割り当ての２種類のいずれかを選択する選択ステップと、既に接続しているセッションフローへの割り当てリソース量に、前記選択されたリソース割り当て方法により定まるリソース量を加えた割り当てリソース総量が、リソース設備総量に収まる範囲内であれば前記新規セッションフローの要求を受け付ける受付判定ステップと、を備え、前記選択ステップにおいて、前記既に接続しているセッションフローへの割り当てリソース量に、前記新規セッションフローへの割り当てリソース量を加えて得られる帯域リソース量とバッファリソース量の比が、帯域リソースの設備総量とバッファリソースの設備総量の比により近くなる割り当て方法を選択する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、IP網やMPLS網を用いて品質保証型サービスを提供するネットワーク事業者が、ユーザからの接続要求に対して、品質保証の実現可否を判断し、品質保証が実現可能であれば接続要求を受け入れてサービスを提供し、品質保証が実現不可能であれば接続要求を拒否する、受付判定の技術に関するものである。
【背景技術】
【０００２】
ブロードバンド回線が低価格でユーザに提供されるようになり、インターネットは急激に普及している。様々なサービスがインターネットを介して提供されるようになるとともに、その通信品質が重要視されるようになった。
【０００３】
特にリアルタイムな映像、音声サービスに対してはネットワーク上におけるデータ転送品質が大きく影響するが、インターネットではそのデータ転送品質を保証する仕組みがないため、現在ではIP閉域網としてネットワークを構築し、データ転送品質を保証する技術と組み合わせて品質保証型のサービスを提供することが検討されている。
【０００４】
IP網において、データ転送品質を保証するサービスモデルとしては、主にIETFで検討されたIntservとDiffservに分けられる。
【０００５】
Intservは、end-to-endでネットワーク経路上の帯域を予約するプロトコルであるRSVP(Resource Reservation Protocol)を用いて、ネットワーク経路上の帯域を確保した上で、その確保した品質に応じたサービスを受けるモデルであるが、RSVPに関する情報を全てリアルタイムに管理する必要があるため、スケールしないという課題を持っていることが知られている（非特許文献１、非特許文献２参照）。
Diffservは、ネットワーク内において転送パケットにマーキングすることによりクラス分けを行い、ネットワーク転送ノードにおけるパケットスケジューリングにより、クラスごとの転送品質の差異化を行なうモデルである。Diffservモデルでは規定されたPHB (Per-Hop Behavior) によって各ネットワーク転送ノードでの転送品質が確保される。
【０００６】
サービスクラスに対応するPHBは完全優先であるEF(Expedited Forwarding)、最低帯域保証であるAF(Assured Forwarding)が規定されており、市販のネットワーク転送ノードにも実装が進んでいる。
【０００７】
Diffservではネットワーク転送ノードごとの転送品質を差異化し、各転送ノードでの制御のみを規定するだけであるため、Intservにおけるスケールしないという課題を解決する。しかしながら、品質保証型のサービスを提供するためには、サービス提供網内で統一された利用帯域に関する受付判定を行なわなければならないという課題と、サービスプロバイダはネットワーク内のリソースに応じてサービス提供品質を規定しなければならないという課題は依然として残っている（非特許文献３、非特許文献４、非特許文献５参照）。
【０００８】
サービス提供品質の規定に関してはITU-Tにおいて、サービス品質を規定するためのパラメータ定義、転送品質クラス規定、サービスモデルが勧告化されている。
【０００９】
しかしながら、ITU-T勧告Y.1541における規定された転送品質をY.1221におけるサービスモデルで実現する手段に関しては検討されておらず、サービスプロバイダはネットワーク内のリソースに応じてサービス提供品質を規定しなければならない、という課題が依然として残る（非特許文献６、非特許文献７、非特許文献８参照）。
利用帯域に関する受付判定モデルとしては、トークンバケットパラメータに従ったネットワークへの入力トラヒックに対して受付判定を行なう、仮想バッファ/トランクモデルがある。仮想バッファ/トランクモデルでは、トークンバケットモデルに従ったトラヒックの最悪条件をON/OFFトラヒックとしてモデル化し、申告帯域に対して、比例したバッファ量を仮想的に割り当てることによって、ネットワーク帯域を管理する帯域管理サーバによる各ネットワーク転送ノードのバッファ量を考慮した実効帯域(effective bandwidth)の積み上げ管理を以下の考え方に基づき行ない、論理的パケット損失率ゼロの受付判定を行なう。
（トークンバケットから送出されるトラヒックの最大量）
トークンバケットで規定されるトラヒックに関しては、時刻0からtまでに発生するトラヒックの最大量A(t)は、
A(t) = min {Pt, σ+ρt} （１）
で規定される。これを図１に示す。ここで、P、ρ、σはトークンバケットのパラメータであり、それぞれピークレート、平均レート、バケットサイズを表す。
【００１０】
このとき、ピークレートでトラヒック送出が可能な最大時間長をTとすると、式（１）から、
PT=σ＋ρT
となり、
T=σ／（P−ρ） （２）
を得る。
（トークンバケットから送出されるトラヒックが使用するリソース量(b、c)の特性）
図2に示すように、トークンバケットから送出された1本のセッションフローが確定的なキューイングシステムにおいてサービスされることを考える。
【００１１】
ここでは、v(t)を時刻tにおける使用バッファ量、bを使用バッファ量の最大値、u(t)を時刻tにおける利用帯域、cを利用可能な最大帯域、ただしρ ≦c ≦ Pとする。
【００１２】
フローが最大量A(t)でデータ送出するとき、時刻0よりTまでの間は、使用バッファ量はP−c ≧0のレートで増加し、それ以降は
c−ρのレートで減少することになるため、
b = v(T) = (P−c)T = σ（P−c）／（P−ρ） （３）
が得られる。これを図３に示す。
【００１３】
（仮想バッファ/トランクモデル）
今、トークンバケットパラメータ(Pk, ρk, σk)を持つセッションフローk , (k = 1, 2, ..., K) がバッファ量B、リンク帯域Cを持つノードに多重されることを考える。このとき、図4に示すように各セッションフローkに対してリンク帯域ck (ρk ≦ck ≦Pk) を仮想的に割り当てることを考える。ただし、仮想リソースの総量はリンク帯域Cを上回らないようにする。すなわち、下記のとおりの関係とする。
c1＋c2＋・・・＋cK ≦ C （４）
このとき、セッションフローkが使用する仮想的なバッファリソースの最大値bkは、式（３）と同様に、
bk = σk （Pk−ck）／（Pk−ρk） （５）
で表すことが出来る。全フローによる実際のバッファ使用量の最大量bは、仮想バッファ使用量の和を上回ることはないので、
Σbk = Σ σk （Pk−ck）／（Pk−ρk）≦ B （６）
が成り立てば、論理的なパケットロスがゼロになる。言い換えると、式（５）を満たすK組の仮想リソース (bk, ck)に対して、式（４）および（６）が成り立てば、当該リンクにおける論理的なパケットロスはゼロになる。
各セッションフローに割り当てる仮想リソースを決定する第一の方法は、ckを
ck = Pk／（1+B (Pk−ρk)／（C σｋ）） （７）
で与えるものである（非特許文献９参照）。
【００１４】
この方法では、結果として得られるbkの値が、
bk／B＝ck／C （８）
という関係を満たし、仮想帯域と仮想バッファ量のそれぞれが本来のリソース量に占める割合が等しくなり、リソース管理が簡単になるという利点がある。
【００１５】
仮想リソース割り当ての第二の方法として、式（６）で表される仮想バッファ量の総和を最小化するような割当方法が考えられている。この方式を定式化すると、
min{Σσk （Pk−ck）／（Pk−ρk）｝ （９）
ただし、
Σck ≦C、 ρ≦ck ≦Pk （１０）
となる。式（９）の解となるような仮想帯域割り当ては、以下の手順で求められる。
【００１６】
先ず全てのフローに対してρkに等しい仮想帯域を割り当てる。
【００１７】
その後、余った帯域C−Σρkについては、フローごとに以下の式
Tk = σk ／（Pk−ρk） （１１）
で計算されたピークレート送出可能時間Tkについて、Tkの値の大きなフローから順番に、Pk−ρkだけ新たに追加して割り当てていく。
【００１８】
この方式で仮想帯域ckを割り当てた場合、式（６）が最小化されることが知られている（非特許文献１０参照）。
上記のような式（６）が成り立つことを条件とする受付判定法は、論理的なパケットロスをゼロとし、かつノードでの最大遅延時間もB／Cで保証できるため、フローの品質を保証することが可能な方式である。
ここで、第一の方法と第二の方法を比較すると、第一の方法はリソース割り当ての計算が簡単であることが利点となる。第二の方法では計算された最大バッファ使用量は第一の方法で計算される最大バッファ使用量以下となることが保証されているため、受付判定に用いた場合に、より多くのセッションを受け付けられ、収容効率に優れるという利点がある。
【００１９】
以上説明したように、仮想バッファ/トランクモデルを適用することによって、品質を保証した受付判定が可能となる。しかしながら、第一の方法では収容効率、第二の方法では計算の複雑さと管理すべき情報量の多さが課題となる。
【先行技術文献】
【非特許文献】
【００２０】
【非特許文献１】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.
【特許文献】
【００２１】
【特許文献１】特願２００９−１５５５４２号
【発明の概要】
【発明が解決しようとする課題】
【００２２】
上記の課題を解決する手段として、特許文献１（未公開先願）には第三の方法が提案されている。
【００２３】
特許文献１には、あらかじめ設定された閾値ZとTkの値を比較して、Tk＞Zが成り立つ場合には当該フローに対してピーク帯域Pkおよびバッファ容量0を割り当て、Ｔk≦Zが成り立つ場合には平均帯域ρkおよびバッファ容量σkを割り当てるという方法が第三の方法として提案されている。
【００２４】
この方法で各フローに割り当てられる帯域リソースおよびバッファリソースの総和は、閾値Zが適切に設定されれば仮想バッファ／トランクモデルにより実現される任意のリソース割り当ての中で最適なものとなり、第二の方法と同等の収容効率が実現可能であるにも関わらず、計算の複雑さと管理すべき情報量については第一の方法の定数倍にすぎず、第二の方法よりも優れている。しかしながら、収容効率を最大化できる閾値Zの値は接続を要求するフロー全体の特性により変化するため、あらかじめ閾値Zを適切な値に設定しておくことは困難であり、適宜修正する必要があるという課題が残る。
【００２５】
（本発明が解決しようとする課題の具体的な説明）
以下、本発明が解決しようとする課題について、より具体的に説明する。
【００２６】
ここで、仮想リソース割り当てに関する技術は、以下のように表現できる。
【００２７】
いま、セッションフローkのトラヒックパラメータ (Pk, ρk, σk) に対し、X軸方向に帯域リソース量、Y軸方向にバッファリソース量をとる２次元平面上の方向ベクトルを
【００２８】
【数１】
とおく。このとき、セッションフローkが使用するリソース量 (ck, bk) は、２つの方向ベクトルの内分点、
すなわち、
【００２９】
【数２】
であらわすことが可能であり、αk＝1のときがピークレート割当（Pk, 0）, αk＝０のときが平均レート割当 (ρk、σk) に相当する。これは図５に示すとおりである。
【００３０】
次に、セッションフローが複数の場合を考える。セッションフロー数＝2のとき、セッションフローkおよびlのトラヒックパラメータをそれぞれ(Pk, ρk, σk), (Pｌ, ρｌ, σｌ) とおく。ただし、σk/（Pk−ρk）≧σl/（Pl−ρl）とする。このときセッションフローk、lに割り当てられるリソース量の合計は、式(13)で示される方向ベクトルの内分点の合成
【００３１】
【数３】
で示される。ただし、
【００３２】
【数４】
式(14)によるリソース量の合計がとり得る範囲は、図６の四辺形R1-R2-R4-R3の内部領域により与えられる。ここで、R1はセッションフローk, lともに平均レート割当、R2はセッションフローkにピーク割当、セッションフローlに平均割当、R3はセッションフローkに平均割当、セッションフロー lにピーク割当、R4はセッションフローk, lともにピーク割当を実施した場合に相当し、線分R1-R2はセッションフローlに平均割当、線分R2-R4はセッションフローkにピーク割当、線分R1-R3はセッションフローkに平均割当、線分R3-R4はセッションフローlにピーク割当とした場合に相当する。効率的なリソース割当という観点からは、線分R1-R2またはR2-R4上の割当が、帯域リソース、バッファリソースともに少なめの割当となり、線分R1-R3またはR3-R4の割当や、四辺形の内部領域の割当よりも望ましい。
【００３３】
一般的にセッションフロー数がより多い場合では、図7に示すように、リソース割当の合計値は、2次元上の多角形領域であらわすことが可能である。全セッションフローに平均割当を行った場合の点
【００３４】
【数５】
と、全セッションフローにピーク割当を行った場合の点
【００３５】
【数６】
を結ぶ曲線の下限値は、以下のように作成できる。
（手順1）接続セッションフローを、式（１１）のTkが大きい順に並びかえる。
（手順2）最もTkの値が大きいセッションフロー1に対して、ベクトルva(1)をベクトルvp(1)に置き換えた
【００３６】
【数７】
とRAを結ぶ線分を考える。この線分が、セッションフロー1に対するリソース割当のみを式（１３）の範囲で変化させた場合の、全体のリソース割当量に相当する。
【００３７】
(手順3）次にTkの値が大きいセッションフロー2に対して同様の動作を行う。
以下順番にセッションフローnまで繰り返し、点RPに至る曲線を得る。
【００３８】
ここで、式（１１）のTkは、上記手順2、3で作成する線分の傾きの大きさに相当するため、これを下回るリソース割当は実現不可能であり、下限となる。また、曲線の傾きは単調非減少であり、下に凸な曲線となる。
【００３９】
同様に、RAとRPを結ぶ曲線の上限値は、以下の手順で算出できる。
【００４０】
（手順1'）接続セッションフローを、式（１１）のTkが大きい順に並びかえる。
【００４１】
（手順2'）最もTkの値が小さいセッションフローnに対し、ベクトルva(n)をvp(n)に置き換えた
【００４２】
【数８】
とRAを結ぶ線分を考える。この線分が、セッションフローnに対するリソース割当のみを式（１３）の範囲で変化させた場合の、全体のリソース割当量に相当する。
【００４３】
(手順3'）次にTkの値が小さいセッションフローn-1に対して同様の動作を行う。以下セッションフロー1まで繰り返し、点RPに至る曲線を得る。
【００４４】
下限値の曲線と同様、手順1'〜手順3'を上回るリソース割当は実現不可能であり、上限となる。また、曲線の傾きは単調非増加であり、上に凸な曲線となる。したがって、両曲線に囲まれた領域は、凸多角形となる。
【００４５】
この領域と、式（４）および式（６）で規定される長方形領域OBDCが交わる部分が、論理的パケットロスを0とできるリソース割当の実現値に相当する。特に、RAとRPを結ぶ下に凸な曲線が、効率的なリソース割当に相当する。
従来技術における第一の方法では、リソース量を示すベクトル(ck、 bk) の傾きが、C/Bと一致するように、αの値は
α＝(Cσ−Bρ）／（Cσ＋B（P−ρ）） （１５）
で決定される。これを図８に示す。この第一の方法では、αはセッションフローのトラヒックパラメータにより変化するが、算出方法は式（14）で一意に与えられ、他のセッションフローの影響を受けないことと、割当済みバッファリソースの、全バッファリソースに対する割合と、割当済み帯域リソースの、全帯域リソースに対する割合が等しくなり、どちらか一方のリソース割当のみを管理すれば良いというメリットがある。しかしながら、この第一の方法においては、リソースの割当方法の効率が必ずしも良くないという課題がある。つまり、図９では、第一の方法による、2つのセッションフローへのリソース割当の合計量がS1で示されているが、割当済みバッファリソースの、全バッファリソースに対する割合と、割当済み帯域リソースの、全帯域リソースに対する割合が等しくなるようなリソース割当の合計値がS2となるような、より効率の良い2セッションフローへのリソース割当が存在する。
【００４６】
第一の方法のもう一つの課題は、図１０に示すように、σk/ρｋ＜B/Cとなるようなセッションフローに対しては、式（７）によるリソース割当は実行できないことである。この場合、例えば図１０にあるように（ρk, ρk×B/C）というような、必要以上にバッファリソースを消費してしまう。
【００４７】
従来技術における第二の方法は、図7における点RAを始点として、点RPに至る下に凸な曲線を追跡し、辺CD上の点RQを求めることに相当している。点RRのY軸座標がB以下であることと、多角形領域と四角形OBDCが交わることは同値であるため、従来技術における第二の方法は、仮想リソース割り当て方式の中で最適な方式の一つといえる。しかしながら、第二の方法では、下に凸な曲線RA-RPを構成するすべての点の情報を常に管理する必要がある。この点に関して、第二の方法は以下に挙げるような問題点を有する。
【００４８】
(1)曲線RA-RPは接続セッションフロー数に等しい数の点により構成され、セッションフロー数に伴って増加する。
【００４９】
(2)下に凸な曲線を構成するためには、式(11)にあるTkの値が降順となるように並び替えておく必要があり、新規セッションフローを接続するごとに順序を改める必要がある。
【００５０】
(3)接続終了や新規セッションフローの追加によりすべての点の位置が変化するため、再計算が必要となる。
【００５１】
以上の問題点は、実時間性を要求される受付判定において処理時間の増加をもたらすという課題につながっている。
【００５２】
第三の方法では、図7における下に凸多角形領域内の1点(以下、この点をRRとする）を点RAおよびRPと併せて常に管理し、曲線RA-RR-RPが四角形OBDCと交わるか否かによりリソース割当の可否を判断する。この方法で得られる曲線RA-RR-RPは、凸多角形の性質から常に凸多角形の領域内に存在するので、曲線上の点はすべてリソース割当総量の候補となりうる。この曲線は、従来の第二の方法で得られる下に凸な曲線より常に上にあるため、リソース割当の効率性としては第二の方法の方が優れるが、管理する曲線上の点がセッションフロー数に関係なく3点と一定であり、新規接続セッションまたは終了セッションの情報のみを用いて更新可能であることから、第二の方法が持つ課題を克服した方法となっている。また、第三の方法では、従来技術における第一の方法における式（７）によるリソース割当が実施できないようなセッションフローについても問題なく対応可能であり、第一の方法よりも効率性としては勝っていることが期待できる。
【００５３】
ここで、第三の方法における点RRは、以下の手続きにより各セッションフローに割り当てられるリソースの総和により定められる。
【００５４】
(1) セッションフロー数＝０、すなわちリソース割り当てが行われていない時点において、閾値Zをあらかじめ設定しておく。
【００５５】
(2) 接続を要求するセッションフローkのトラヒックパラメータ (Pk, ρk, σk) に対し、式(11)のTkを計算し、Tk>Zであればベクトルvp(k)＝(Pk, 0)、Tk≦Zであれば、ベクトルva(k)＝（ρk, σk）に相当するリソースを割り当てる。
【００５６】
この方法の問題点は、実現される収容効率が閾値Zに依存することである。特許文献1では閾値Zの値を逐次変更していくことで収容効率を改善しているが、閾値Zの値が安定するまで時間がかかるという課題は依然として残っている。
【００５７】
本発明は上記の点に鑑みてなされたものであり、安定した収容効率を実現するための受付判定技術を提供することを目的とする。
【課題を解決するための手段】
【００５８】
上記の課題を解決するために、本発明は、新規セッションフローに帯域およびバッファの２種類のリソースを個別に割り当てて、当該新規セッションフローの通信を行う通信装置の設備量に収まる範囲内で前記新規セッションフローを受け付ける制御を行う呼受付制御システムが実行する呼受付制御方法であって、前記新規セッションフローの受付要求を受信する受信ステップと、前記新規セッションフローへのリソース割り当て方法の候補として、ピーク割り当てあるいは平均割り当ての２種類のいずれかを選択する選択ステップと、既に接続しているセッションフローへの割り当てリソース量に、前記選択ステップにおいて選択されたリソース割り当て方法により定まるリソース量を加えた割り当てリソース総量が、前記通信装置のリソース設備総量に収まる範囲内であれば前記新規セッションフローの要求を受け付ける受付判定ステップと、を有し、前記選択ステップにおいて、前記既に接続しているセッションフローへの割り当てリソース量に、前記新規セッションフローへの割り当てリソース量を加えて得られる帯域リソース量とバッファリソース量の比が、前記通信装置における帯域リソースの設備総量とバッファリソースの設備総量の比により近くなる割り当て方法を選択することを特徴とする呼受付制御方法として構成される。
【００５９】
また、前記呼受付制御方法は、全セッションフローにピーク割り当てを実施するリソース割り当て方法により定まるピーク割り当てリソース総量と、全セッションフローに平均割り当てを実施するリソース割り当て方法により定まる平均割り当てリソース総量とを算出するステップを有し、前記受付判定ステップにおいて、前記割り当てリソース総量が、前記リソース設備総量に収まる範囲内にない場合に、帯域リソースとバッファリソースとを２つの軸としたグラフ上で、前記割り当てリソース総量を示す点と、前記ピーク割り当てリソース総量を示す点とを結ぶ線分上、もしくは、前記割り当てリソース総量を示す点と、前記平均割り当てリソース総量を示す点とを結ぶ線分上に、前記リソース設備総量の範囲に収まる点があれば、前記リソース設備総量の範囲に収まる割り当てが可能であると判断して、前記新規セッションフローの要求を受け付けるようにしてもよい。
【００６０】
また、本発明は、上記呼受付制御の実施の適した呼受付制御システムとして構成することもできるし、当該呼受付制御システムを備える複数の通信装置を伝送路で接続して構成されたネットワークシステムとして構成することもできる。また、本発明は、上記呼受付制御システムを備えるネットワーク制御装置と、伝送路で接続された複数の通信装置とを備えたネットワークシステムであって、前記ネットワーク制御装置は、前記新規セッションフローの通信経路上の各通信装置が有する設備量に収まる範囲内で前記新規セッションフローを受け付ける制御を行うことを特徴とするネットワークシステムとして構成することもできる。
【発明の効果】
【００６１】
本発明によれば、第三の方法で調整すべきパラメータである閾値Zを用いることなく判定を行うことにより、安定した収容効率を実現できる受付判定法を実現できる。本発明に係る技術では、管理情報や計算量は第三の方法と同程度のオーダであるうえ、各セッションフローに対するリソース割り当てはピーク割り当て、あるいは平均割り当てのどちらかに限定されるため、従来技術における第一の方法よりも収容効率は向上する。
【００６２】
さらに、リソース割当の実行可能な領域が凸多角形となる性質から、全セッションフローに対してピーク割り当てを行う方式および全セッションフローに対して平均割り当てを行う方式を加えた3種類のリソース割当方法に対応する３点を結ぶ線分上の全ての点が実行可能な領域内にある性質を利用して、３種類のリソース割当が全て設備量を超過していても実行可能な、効率的なリソース割当が可能な場合が存在することを判定することで、より収容効率を向上させられる受付判定方法が実現可能となる。
【図面の簡単な説明】
【００６３】
【図１】トークンバケットで規定されるトラヒックの最大量A(t)を示す図である。
【図２】キューイングシステムを示す図である。
【図３】使用バッファ量v(t)の変化を示す図である。
【図４】各セッションフローkに対してリンク帯域ckを仮想的に割り当てた状態を示す図である。
【図５】セッションフローkが使用するリソース量 (ck, bk)を示す図である。
【図６】セッションフローkおよびlに割り当てられるリソース量の合計がとり得る範囲を示す図である。
【図７】一般のリソース割当の合計値の範囲に相当する2次元上の多角形領域を示す図である。
【図８】従来技術における第一の方法におけるαの値の算出方法を説明するための図である。
【図９】第一の方法の課題を説明するための図である。
【図１０】第一の方法のもう一つの課題を説明するための図である。
【図１１】実施例１における受付判定方法の処理手順を示す図である。
【図１２】実施例２における受付判定方法の処理手順を示す図である。
【図１３】実施例２における受付判定方法の処理手順（サブフロー１）を示す図である。
【図１４】実施例２における受付判定方法の処理手順（サブフロー２）を示す図である。
【図１５】RRpまたはRRaが四角形OBCDの外部にあるが、設備量(C, B)の範囲内に収まる組み合わせが存在することを説明するための図である。
【図１６】RRpまたはRRaが四角形OBCDの外部にあるが、設備量(C, B)の範囲内に収まる組み合わせが存在することを説明するための図である。
【図１７】実施例３を説明するための図である。
【図１８】実施例４を説明するための図である。
【図１９】受付制御部１００の機能構成図である。
【図２０】新たなセッションフローに対するリソース割り当て方法の例を説明するための図である。
【図２１】新たなセッションフローに対するリソース割り当て方法の例を説明するための図である。
【発明を実施するための形態】
【００６４】
以下、図面を参照して本発明の実施例を説明する。各実施例の説明にあたり用いる記号を以下のように定める。
【００６５】
接続セッションフローのうち、ピーク割り当てを実施するフローの集合をΩp、平均割当を実施するフローの集合をΩaとする。
【００６６】
接続セッションフロー全体に割り当てたリソース量の総量を、RRとする。
【００６７】
接続セッションフローのピークレートの合計値をP、平均レートの合計値をρ、バケットサイズの合計値をσ、接続セッションフローの総数をNとする。
【００６８】
ピーク割当を行った場合のリソース総量をRP＝（P, 0）、平均割当を行った場合のリソース総量をRA=（ρ, σ）とする。なお、RR、RP、RAはいずれもベクトルである。また、以下の説明における各点もベクトルである。
【００６９】
（実施例１）
図11に、実施例１における受付判定方法の処理手順を示す。なお、ここでの処理は、後述する実施例における装置（ルータ、ネットワーク制御装置）により実行することを想定しているが、処理を実行する装置はルータやネットワーク制御装置に限られるわけではない。例えば、一般的なコンピュータに、以下の処理アルゴリズムを記述したプログラムを実行させて処理を行うようにしてもよい。ただし、ルータやネットワーク制御装置においても、その内部で以下の処理を実行する主体は、ＣＰＵとメモリとを有するコンピュータに相当する機能部（後述する受付制御機能部１００に相当）であるから、一般的なコンピュータにより処理を行う場合と、ルータやネットワーク制御装置で処理を行う場合とで、受付判定方法の処理として実質的な違いはない。つまり、いずれの場合も、各種パラメータや各変数の値がメモリ等の記憶手段に格納され、プログラムに従って、ＣＰＵにより適宜読み出されて処理が行われる。また、プログラムを用いる方式の他、処理アルゴリズムをハードウェアロジック回路として実現し、当該ハードウェアロジック回路が受付判定方法の処理を行うようにしてもよい。実施例２でも同様である。この場合、当該ハードウェアロジック回路が後述する受付制御機能部１００に相当する。
【００７０】
ステップ１）初期条件として接続セッションフローが存在しない状況を仮定し、Ωp={}、Ωa={}、RR=(0, 0)とする。
【００７１】
ステップ２）トラヒックパラメータ（Pk, ρk, σk)を有する、新規受付を要求するセッションフローkが到着した場合（つまり、新規受付要求を受信した場合）、ステップ３へ進む。トラヒックパラメータ(Pj, ρj, σj)を有する、既接続セッションフローjの終了要求が到着した場合、ステップ１０へ進む。
【００７２】
ステップ３）新規受付要求から、トラヒックパラメータ（Pk, ρk, σk)を取得し、セッションkを接続した場合に必要となるリソース量の総和の候補RRp、RRaを以下のように定め、これら2点と直線y=(B/C)xとの距離に比例した値Dp、Daを計算する。
RRp = (xp, yp) = RR+(Pk, 0)
RRa = (xa, Ya) = RR+(ρk, σk)
Dp = |B・xp - C・yp|
Da = |B・xa - C・ya|
ステップ４）ステップ３において計算した値であるDpとDa とを比較し、Dp ≦ Daならばステップ５へ、Dp > Daならばステップ８へ進む。なお、ここでの選択は、既に接続しているセッションフローへの割り当てリソース量に、新規セッションフローへの割り当てリソース量を加えて得られる帯域リソース量とバッファリソース量の比(yp/xpまたはya/xa)が、帯域リソースの設備総量とバッファリソースの設備総量の比(B/C)により近くなる割り当て方法を選択することに相当する。実施例２でも同様である。
【００７３】
ステップ５）RRpが四角形OBCDの内部にあるかどうかをチェックする。すなわち
xp ≦ C かつ yp ≦ B
が成り立つかどうかをチェックし、成り立てば、ステップ６に進み、成り立たない場合はステップ７に進む。
【００７４】
ステップ６）セッションフローkを含むリソース割り当てが設備量(C, B)の範囲内に収まると判断し、セッションフローkの受付を許可し、RR=RRpとし、kをΩpに加えてステップ２へ進む。
【００７５】
ステップ７）セッションフローkの受付を拒否し、ステップ２へ進む。
【００７６】
ステップ８）RRaが四角形OBCDの内部にあるかどうかをチェックする。すなわち
xa ≦ C かつ ya ≦ B
が成り立つかどうかをチェックし、成り立てば、ステップ９に進み、成り立たない場合はステップ７に進んでセッションフローkの受付を拒否する。
【００７７】
ステップ９）セッションフローkを含むリソース割り当てが設備量(C, B)の範囲内に収まると判断し、セッションフローkの受付を許可し、RR=RRaとし、kをΩaに加えてステップ２へ進む。
【００７８】
ステップ１０）接続終了要求からトラヒックパラメータ(Pj, ρj, σj)を取得し、セッションフローjがΩpに含まれるかどうかをチェックする。すなわち、セッションフローjに対してピーク割り当てを行っていたかどうかをチェックする。セッションフローjがΩpに含まれていた場合はステップ１１に進み、含まれていない場合はステップ１２に進む。
【００７９】
ステップ１１）RR = RR -(Pj, 0)とし、Ωpからセッションフローjを除外する。セッションフローjの接続を終了した後、ステップ2へ進む。
【００８０】
ステップ１２）セッションフローjがΩaに含まれる、すなわち平均割当を行っていた場合は、RR = RR -(ρk, σk)とし、Ωaからセッションフローjを除外する。セッションフローjの接続を終了した後、ステップ2へ進む。
【００８１】
（実施例２）
次に、図１２、図１３、図１４のフローチャートを参照して、実施例２に係る受付判定方法を説明する。
【００８２】
ステップ１）初期条件として接続セッションフローが存在しない状況を仮定し、Ωp={}、Ωa={}、RR=(0, 0)、RP=(0, 0)、RA=(0, 0)とする。
【００８３】
ステップ２）トラヒックパラメータ（Pk, ρk, σk)を有する、新規受付を要求するセッションフローkが到着した場合（つまり、新規受付要求を受信した場合）、ステップ３へ進む。トラヒックパラメータ(Pj, ρj, σj)を有する、既接続セッションフローjの終了要求が到着した場合、ステップ１０へ進む。
【００８４】
ステップ３）新規受付要求から、トラヒックパラメータ（Pk, ρk, σk)を取得し、セッションkを接続した場合に必要となるリソース量の総和の候補RRp、RRaを以下の様に定め、これら2点と直線y=(B/C)xとの距離に比例した値Dp、 Daを計算する。
RRp = (xp, yp) = RR+(Pk, 0)
RRa = (xa, Ya) = RR+(ρk, σk)
Dp = |B・xp - C・yp|
Da = |B・xa - C・ya|
さらに、RP'=(P, 0) = RP+(Pk, 0)、RA'= (ρ, σ) = RA+(ρk, σk)を計算する。
【００８５】
ステップ４）ステップ３において計算した値であるDpとDa とを比較し、Dp ≦ Daならばサブフロー１（図１３）へ進み（ステップ１００）、Dp > Daならばサブフロー２（図１４）へ進む（ステップ２００）。
【００８６】
以下、図１３を参照してサブフロー１を説明する。
【００８７】
ステップ１０１）xpとCとの比較、及びypとBとの比較を行う。比較の結果、{xp≦Cかつyp≦B}が成り立てばステップ１０２に進み、{xp＞Cかつyp≦B}が成り立てばステップ１０３に進み、{xp≦C かつ yp＞B}が成り立てばステップ１０５に進み、{xp＞C かつ yp＞B}が成り立てばステップ１０６に進む。
【００８８】
ステップ１０２）この場合、{xp≦Cかつyp≦B}であるから、RRpが四角形OBCDの内部にある。すなわち、セッションフローkを含むリソース割り当てが設備量(C, B)の範囲内に収まり、セッションフローkの受付が可能と判断し、接続可能の結果をもってステップ５（図１２）に進む。
【００８９】
ステップ１０３）この場合、｛xp＞Cかつyp≦B｝が成り立っており、なおかつ
(yp -σ) (C -ρ）/ (xp -ρ) + σ≦B
が成り立つかどうかをチェックする。成り立っている場合、RRpは四角形OBCDの外部にあるが、図１５に示すように、RRpとRA'を結ぶ線分が四角形OBCDと交わっているため、セッションフローkを含むリソース割り当ての全体量として、設備量(C, B)の範囲内に収まる組み合わせが存在するので、セッションフローkの受付が可能と判断し、ステップ１０２に進む。成り立たない場合は、ステップ１０４に進む。
【００９０】
ステップ１０４）接続不可の結果をもってステップ５（図１２）に進む。
【００９１】
ステップ１０５）この場合、｛xp≦C かつ yp＞B｝が成り立ち、なおかつ
yp (C -P）/ (xp -P) ≦ B
が成り立つかどうかをチェックする。成り立っている場合、RRpは四角形OBCDの外部にあるが、図１６に示すとおり、RRpとRP'を結ぶ線分が四角形OBCDと交わっているため、セッションフローkを含むリソース割り当ての全体量として、設備量(C，B)の範囲内に収まる組み合わせが存在するので、セッションフローkの受付が可能と判断し、ステップ１０２に進む。成り立たない場合は、ステップ１０６に進む。
【００９２】
ステップ１０６）接続不可の結果を保持してステップ５（図１２）に進む。
【００９３】
次に、図１４を参照してサブフロー２を説明する。
【００９４】
ステップ２０１）xaとCとの比較、及びyaとBとの比較を行う。比較の結果、{xa≦Cかつya≦B}が成り立てばステップ２０２に進み、{xa＞Cかつya≦B}が成り立てばステップ２０３に進み、{xa≦C かつ ya＞B}が成り立てばステップ２０５に進み、{xa＞C かつ ya＞B}が成り立てばステップ２０６に進む。
【００９５】
ステップ２０２）この場合、{xa≦Cかつya≦B}であるから、RRaが四角形OBCDの内部にある。すなわち、セッションフローkを含むリソース割り当てが設備量(C, B)の範囲内に収まり、セッションフローkの受付が可能と判断し、接続可能の結果をもってステップ７（図１２）に進む。
【００９６】
ステップ２０３）この場合、｛xa＞Cかつya≦B｝が成り立っており、なおかつ
(ya -σ) (C -ρ）/ (xa -ρ) + σ≦B
が成り立つかどうかをチェックする。成り立つ場合、RRaは四角形OBCDの外部にあるが、図１５に示すように、RRaとRA'を結ぶ線分が四角形OBCDと交わっているため、セッションフローkを含むリソース割り当ての全体量として、設備量(C, B)の範囲内に収まる組み合わせが存在するので、セッションフローkの受付が可能と判断し、ステップ２０２に進む。成り立たない場合は、ステップ２０４に進む。
【００９７】
ステップ２０４）接続不可の結果をもってステップ７（図１２）に進む。
【００９８】
ステップ２０５）この場合、｛xa≦C かつ ya＞B｝が成り立ち、なおかつ
ya (C -P）/ (xa -P) ≦ B
が成り立つかどうかをチェックする。成り立っている場合、RRaは四角形OBCDの外部にあるが、図１６に示すとおり、RRaとRP'を結ぶ線分が四角形OBCDと交わっているため、セッションフローkを含むリソース割り当ての全体量として、設備量(C，B)の範囲内に収まる組み合わせが存在するので、セッションフローkの受付が可能と判断し、ステップ２０２に進む。成り立たない場合は、ステップ２０６に進む。
【００９９】
ステップ２０６）接続不可の結果を保持してステップ７（図１２）に進む。
【０１００】
以下、図１２に戻って説明を続ける。
【０１０１】
ステップ５）サブフロー１での処理結果が、「接続可能」である場合、ステップ６に進み、「接続不可」である場合、ステップ９に進む。
【０１０２】
ステップ６）セッションフローkの接続を許可し、RR=RRp、RP=RP'、RA=RA'とし、kをΩpに加えてステップ２へ進む。
【０１０３】
ステップ７）サブフロー１での処理結果が、「接続可能」である場合、ステップ８に進み、「接続不可」である場合、ステップ９に進む。
【０１０４】
ステップ８）セッションフローkの接続を許可し、RR=RRa、RP=RP'、RA=RA'とし、kをΩpに加えてステップ２へ進む。
【０１０５】
ステップ９）セッションフローkの受付を拒否し、ステップ２へ進む。
【０１０６】
ステップ１０）接続終了要求からトラヒックパラメータ(Pj, ρj, σj)を取得し、セッションフローjがΩpに含まれるかどうかをチェックする。すなわち、セッションフローjに対してピーク割り当てを行っていたかどうかをチェックする。セッションフローjがΩpに含まれていた場合はステップ１１に進み、含まれていない場合はステップ１２に進む。
【０１０７】
ステップ１１）RR = RR -(Pj, 0)、RP = RP -(Pj, 0)、RA = RA - (ρj, σj) とし、Ωpからセッションフローjを除外する。セッションフローjの接続を終了した後、ステップ2へ進む。
【０１０８】
ステップ１２）セッションフローjがΩaに含まれる、すなわち平均割当を行っていた場合は、RR = RR - (ρj, σj)、RP = RP -(Pj, 0)、RA = RA -(ρj, σj)とし、Ωaからセッションフローjを除外する。セッションフローjの接続を終了した後、ステップ２へ進む。
【０１０９】
（実施例３）
次に、本発明の実施例３について説明する。本実施例では、図１７に示すネットワークシステム上において、本発明の受付判定方法を実現した形態の例を示す。図１７に示すネットワークシステムは、通信ルータ１４、１５、１６が伝送路で接続されて構成される通信ネットワーク１０に、ユーザのターミナル装置（TE）１１、１８がユーザネットワークインタフェース装置１３、１７を介して接続されるとともに、ネットワーク制御装置１２が接続されたシステムである。本実施例では、各通信ルータ（R）が、実施例１または実施例２で説明した受付判定処理を実行する機能を有しており、各通信ルータ（R）が、ネットワーク制御装置１２からの要求に基づいて受付判定処理を行う。
【０１１０】
以下、このネットワークシステムで実行される受付判定方法の例を説明する。以下で説明する各ステップ番号は、図１７に示すステップ番号と対応している。
【０１１１】
ステップ１）ユーザのターミナル装置（TE）１１から、新規セッションフローの接続要求が、トラヒックパラメータ情報とともにネットワーク制御装置１２に通知される。
【０１１２】
ステップ２）ネットワーク制御装置１２は、新規セッションの通信経路上の通信ルータ（R）１４、１５を識別し、当該通信ルータ（R）１４、１５に、新規セッションフローのトラヒックパラメータを新規受付要求として通知する。
【０１１３】
ステップ３）各通信ルータ（R）１４、１５は、新規セッションフローを受け付けることで自身が有する設備量の範囲内でのリソース割当が可能かどうかを、実施例1または2の方法を用いて判定し、受付可否をネットワーク制御装置１２に通知する。
【０１１４】
ステップ４）ネットワーク制御装置１２は、新規セッションフローの通信経路上のすべての通信ルータ（R）１４、１５から新規セッションフローの受付許可が得られた場合、新規セッションフローの接続許可をユーザのターミナル装置（TE）１１および通信ルータ（R）１４、１５に通知する(新規セッションフローの接続）。もしいずれかの通信ルータ（R）から受付不可を通知された場合、新規セッションフローは受け付けられないのでユーザのターミナル装置（TE)１１に接続拒否を通知し、通信ルータ（R）１４、１５には新規セッションフローの通信終了を通知する(ステップ7へ）。
【０１１５】
ステップ５）通信中のセッションフローを終了する場合、ユーザのターミナル装置（TE）１８からネットワーク制御装置１２に当該セッションの終了が通知される。
【０１１６】
ステップ６）ネットワーク制御装置１２は、当該セッションの通信系路上の通信ルータ（R）１６に対し、当該セッションの通信終了を通知する。
【０１１７】
ステップ７）接続終了要求を受信した通信ルータ（R）は、実施例１または実施例２で説明した処理を行うことにより、通信終了したセッションフローに関する情報を削除する。
【０１１８】
(実施例４）
次に、本発明の実施例４について説明する。本実施例では、図１７に示す構成と同様の、図１８に示すネットワークシステム上において、本発明の受付判定方法を実現した形態の例を示す。本実施例では、ネットワーク制御装置１２が、通信ネットワーク１０を構成する各通信ルータ（R）の設備情報等を有しており、ネットワーク制御装置１２が、受付判定処理を行うこととしている。
ステップ１）ユーザのターミナル装置（TE）１１から、新規セッションフローの接続要求が、トラヒックパラメータ情報とともにネットワーク制御装置１２に通知される。
【０１１９】
ステップ２）ネットワーク制御装置１２は、新規セッションフローの通信経路上の通信ルータ（R）において、新規セッションフローを受け付けることで各通信ルータ（R）が有する設備量の範囲内でのリソース割当が可能かどうかを、実施例１または２の方法を用いて判定し、受付可否を判定する。
【０１２０】
ステップ３）ネットワーク制御装置１２は、新規セッションフローの通信経路上のすべての通信ルータ（R）において、設備量の範囲内でのリソース割当が可能と判断した場合、新規セッションフローの接続許可をユーザターミナル装置（TE）１１に通知する(新規セッションフローの接続）。もしいずれかの通信ルータ（R）において、設備量の範囲内でのリソース割当が不可と判断した場合、新規セッションフローは受け付けられないのでユーザターミナル装置（TE)１１に接続拒否を通知する。
【０１２１】
ステップ４）通信中のセッションフローを終了する場合、ユーザのターミナル装置（TE）１８からネットワーク制御装置１２に当該セッションフローの終了が通知される。
【０１２２】
ステップ５）ネットワーク制御装置１２は、実施例１または２で説明した処理を行うことにより、当該セッションフローに関する情報を削除する。
（装置構成）
上記実施例３における各通信ルータ内、及び上記実施例３におけるネットワーク制御装置１２内のそれぞれにおいて、実施例１あるいは実施例２の受付判定方法を実行する受付制御機能部１００を備えている。なお、当該受付制御機能部１００を備えるシステム（もしくは装置）を呼受付制御システムと呼ぶことができる。また、受付制御機能部１００自身を呼受付制御システムと呼んでもよい。
【０１２３】
受付制御機能部１００の機能構成例を図１９に示す。図１９に示すように、受付制御機能部１００は、入出力部１１０、セッションフロー情報記憶部１２０、リソース割り当て状態記憶部１３０、演算機能部１４０を備える。
【０１２４】
入出力部１１０は、ユーザのターミナル装置（TE）からのセッションフローの接続要求およびセッションフロー終了要求の受け取りや、新規セッションフローの接続許可あるいは拒否通知など、外部との情報の入出力を実行する。すなわち、入出力部１１０は、新規セッションフローの受付要求を受信する受信手段を含む。
【０１２５】
セッションフロー情報記憶部１２０は、接続セッションフローおよび新規接続要求セッションフローのパラメータ（Pk, ρk, σk）、ピーク割り当てを実行するセッションフローの集合Ωp、および平均割り当てを実行するセッションフローの集合Ωaの情報を記憶する。
【０１２６】
リソース割り当て状態記憶部１３０は、全セッションフローへ割り当てたリソース状況にかかわる情報RR、RRp、RRa、RP、RA、RP'、RA'を記憶する。
【０１２７】
演算機能部１４０は、セッションフロー情報記憶部１２０およびリソース割り当て状態記憶部１３０内の情報を読み出して、新規セッションフローの接続要求を受け入れた場合にリソースが不足するか否かを判定するのに必要な演算（実施例１または実施例２のアルゴリズム）を実行し、接続要求の受付可否を入出力部１１０へ通知する、更に、新規セッションフローを接続する場合には、当該セッションフローへピーク割り当て、平均割り当てのどちらとするかをセッションフロー情報記憶部１２０へ通知し、ΩpあるいはΩaを更新させるとともに、新たなリソース割り当て状態RR（およびRP、RA）をリソース割り当て状態記憶部１３０へ通知し、当該情報を更新させる。セッションフロー終了の情報を入出力部１１０から受け取った場合には、当該セッションフローの情報をセッションフロー情報記憶部１２０へ通知し、当該セッションフローのパラメータを削除させ、ΩpあるいはΩaを更新させるとともに、新たなリソース割り当て状態RR（およびRP、RA）をリソース割り当て状態記憶部１３０へ通知し、当該情報を更新させる。
【０１２８】
すなわち、演算機能部１４０と、セッションフロー情報記憶部１２０と、リソース割り当て状態記憶部１３０とで、新規セッションフローへのリソース割り当て方法の候補として、ピーク割り当てあるいは平均割り当ての２種類のいずれかを選択する選択手段と、既に接続しているセッションフローへの割り当てリソース量に、前記選択手段において選択されたリソース割り当て方法により定まるリソース量を加えた割り当てリソース総量が、前記通信装置のリソース設備総量に収まる範囲内であれば前記新規セッションフローの要求を受け付ける受付判定手段とを構成している。
【０１２９】
ここで、前記選択手段は、前記既に接続しているセッションフローへの割り当てリソース量に、前記新規セッションフローへの割り当てリソース量を加えて得られる帯域リソース量とバッファリソース量の比が、前記通信装置における帯域リソースの設備総量とバッファリソースの設備総量の比により近くなる割り当て方法を選択する。
【０１３０】
また、上記構成には、全セッションフローにピーク割り当てを実施するリソース割り当て方法により定まるピーク割り当てリソース総量と、全セッションフローに平均割り当てを実施するリソース割り当て方法により定まる平均割り当てリソース総量とを算出する手段が含まれ、前記受付判定手段は、前記割り当てリソース総量が、前記リソース設備総量に収まる範囲内にない場合に、帯域リソースとバッファリソースとを２つの軸としたグラフ上で、前記割り当てリソース総量を示す点と、前記ピーク割り当てリソース総量を示す点とを結ぶ線分上、もしくは、前記割り当てリソース総量を示す点と、前記平均割り当てリソース総量を示す点とを結ぶ線分上に、前記リソース設備総量の範囲に収まる点があれば、前記リソース設備総量の範囲に収まる割り当てが可能であると判断して、前記新規セッションフローの要求を受け付ける機能を備える。
【０１３１】
（実施の形態の効果）
上記のとおり、各実施例を用いて説明した本発明に係る技術では、ピークレート、平均レート、バケットサイズで規定するトークンバケットモデルで通信セッションフローの特性を現すネットワークで、各セッションフローに対する排他的なリソース割当により論理的パケット損失をゼロにすることで品質保証を実現する受付判定技術に関して、接続セッションフローの本数に依存せず、一定の管理情報と処理量を要するのみで、効率的なリソース割当が可能な方法が実現可能となる。
【０１３２】
一般に仮想バッファ/トランクモデルを用いた仮想リソース割り当て方法においては、帯域リソースとバッファリソースのどちらかが早く枯渇してしまう方式では収容効率が悪くなるため、割り当てリソースの総量が四角形OBCDの対角線ODに沿っている状況が望ましい。従来技術による第一の方法では、これを実現するために各セッションフローへの個別割り当てリソース量がOD上の点となるようにしているが、これは収容効率の面で劣る。従来技術による第二の方法および第三の方法では、収容効率を最大化するため、各セッションフローへのリソース割り当てをピーク割り当てあるいは平均割り当てのどちらかに限定する手法を採用しているが、第二の方法では管理情報や計算量の多さが課題となり、第三の方法では収容効率を最大化するために設定すべき閾値が直接求めることが難しいという課題を有していた。
【０１３３】
一方、本発明に係る技術（実施例１または実施例２で説明した方法）では、新たなセッションフローに対するリソース割り当て量をピーク割り当てあるいは平均割り当てのどちらかにすべきかを決定する仕組みとして、既に接続済みのセッションフローへの割り当てリソースの総量と、新たなセッションフローに対するリソース割り当てとの合計が線分ODに近づくような選択を行っている。
【０１３４】
すなわち、実施例１または実施例２において、図２０に示すように、dp<daである場合、すなわち、Dpに対応するdpがDaに対応するdaより小さい場合、RRaよりもRRpが線分ODに近い。従って、新規セッションフローkに対するリソース割り当てはピーク割り当て(Pk, 0)を採用している（図１１のステップ４、６、及び図１２のステップ４、６）。
【０１３５】
逆に、図２１に示すように、dpがdaより大きい場合、RRpよりもRRaが線分ODに近い。従って、新規セッションフローkに対するリソース割り当ては平均割り当て（ρk, σk)を採用している（図１１のステップ４、９、及び図１２のステップ４、８）。
【０１３６】
このような選択を行うことで、割り当てリソースの総量がバランスよく消費され、結果として収容効率があがることが期待される。本発明に係る技術では、管理情報や計算量は既存の第三の方法と同程度のオーダにとどまるうえ、第三の方法で最適化が必要となる閾値を用いる必要がないという効果を有する。
【産業上の利用可能性】
【０１３７】
本発明は、IP網やMPLS網を用いて品質保証型サービスを提供するネットワークにおける受付判定に適用できる。
【０１３８】
本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において、種々変更・応用が可能である。
【符号の説明】
【０１３９】
１０ 通信ネットワーク
１１、１８ ターミナル装置
１２ ネットワーク制御装置
１３、１７ ユーザネットワークインタフェース装置
１４、１５、１６ 通信ルータ
１００ 受付制御機能部
１１０ 入出力部
１２０ セッションフロー情報記憶部
１３０ リソース割り当て状態記憶部
１４０ 演算機能部
【技術分野】
【０００１】
本発明は、IP網やMPLS網を用いて品質保証型サービスを提供するネットワーク事業者が、ユーザからの接続要求に対して、品質保証の実現可否を判断し、品質保証が実現可能であれば接続要求を受け入れてサービスを提供し、品質保証が実現不可能であれば接続要求を拒否する、受付判定の技術に関するものである。
【背景技術】
【０００２】
ブロードバンド回線が低価格でユーザに提供されるようになり、インターネットは急激に普及している。様々なサービスがインターネットを介して提供されるようになるとともに、その通信品質が重要視されるようになった。
【０００３】
特にリアルタイムな映像、音声サービスに対してはネットワーク上におけるデータ転送品質が大きく影響するが、インターネットではそのデータ転送品質を保証する仕組みがないため、現在ではIP閉域網としてネットワークを構築し、データ転送品質を保証する技術と組み合わせて品質保証型のサービスを提供することが検討されている。
【０００４】
IP網において、データ転送品質を保証するサービスモデルとしては、主にIETFで検討されたIntservとDiffservに分けられる。
【０００５】
Intservは、end-to-endでネットワーク経路上の帯域を予約するプロトコルであるRSVP(Resource Reservation Protocol)を用いて、ネットワーク経路上の帯域を確保した上で、その確保した品質に応じたサービスを受けるモデルであるが、RSVPに関する情報を全てリアルタイムに管理する必要があるため、スケールしないという課題を持っていることが知られている（非特許文献１、非特許文献２参照）。
Diffservは、ネットワーク内において転送パケットにマーキングすることによりクラス分けを行い、ネットワーク転送ノードにおけるパケットスケジューリングにより、クラスごとの転送品質の差異化を行なうモデルである。Diffservモデルでは規定されたPHB (Per-Hop Behavior) によって各ネットワーク転送ノードでの転送品質が確保される。
【０００６】
サービスクラスに対応するPHBは完全優先であるEF(Expedited Forwarding)、最低帯域保証であるAF(Assured Forwarding)が規定されており、市販のネットワーク転送ノードにも実装が進んでいる。
【０００７】
Diffservではネットワーク転送ノードごとの転送品質を差異化し、各転送ノードでの制御のみを規定するだけであるため、Intservにおけるスケールしないという課題を解決する。しかしながら、品質保証型のサービスを提供するためには、サービス提供網内で統一された利用帯域に関する受付判定を行なわなければならないという課題と、サービスプロバイダはネットワーク内のリソースに応じてサービス提供品質を規定しなければならないという課題は依然として残っている（非特許文献３、非特許文献４、非特許文献５参照）。
【０００８】
サービス提供品質の規定に関してはITU-Tにおいて、サービス品質を規定するためのパラメータ定義、転送品質クラス規定、サービスモデルが勧告化されている。
【０００９】
しかしながら、ITU-T勧告Y.1541における規定された転送品質をY.1221におけるサービスモデルで実現する手段に関しては検討されておらず、サービスプロバイダはネットワーク内のリソースに応じてサービス提供品質を規定しなければならない、という課題が依然として残る（非特許文献６、非特許文献７、非特許文献８参照）。
利用帯域に関する受付判定モデルとしては、トークンバケットパラメータに従ったネットワークへの入力トラヒックに対して受付判定を行なう、仮想バッファ/トランクモデルがある。仮想バッファ/トランクモデルでは、トークンバケットモデルに従ったトラヒックの最悪条件をON/OFFトラヒックとしてモデル化し、申告帯域に対して、比例したバッファ量を仮想的に割り当てることによって、ネットワーク帯域を管理する帯域管理サーバによる各ネットワーク転送ノードのバッファ量を考慮した実効帯域(effective bandwidth)の積み上げ管理を以下の考え方に基づき行ない、論理的パケット損失率ゼロの受付判定を行なう。
（トークンバケットから送出されるトラヒックの最大量）
トークンバケットで規定されるトラヒックに関しては、時刻0からtまでに発生するトラヒックの最大量A(t)は、
A(t) = min {Pt, σ+ρt} （１）
で規定される。これを図１に示す。ここで、P、ρ、σはトークンバケットのパラメータであり、それぞれピークレート、平均レート、バケットサイズを表す。
【００１０】
このとき、ピークレートでトラヒック送出が可能な最大時間長をTとすると、式（１）から、
PT=σ＋ρT
となり、
T=σ／（P−ρ） （２）
を得る。
（トークンバケットから送出されるトラヒックが使用するリソース量(b、c)の特性）
図2に示すように、トークンバケットから送出された1本のセッションフローが確定的なキューイングシステムにおいてサービスされることを考える。
【００１１】
ここでは、v(t)を時刻tにおける使用バッファ量、bを使用バッファ量の最大値、u(t)を時刻tにおける利用帯域、cを利用可能な最大帯域、ただしρ ≦c ≦ Pとする。
【００１２】
フローが最大量A(t)でデータ送出するとき、時刻0よりTまでの間は、使用バッファ量はP−c ≧0のレートで増加し、それ以降は
c−ρのレートで減少することになるため、
b = v(T) = (P−c)T = σ（P−c）／（P−ρ） （３）
が得られる。これを図３に示す。
【００１３】
（仮想バッファ/トランクモデル）
今、トークンバケットパラメータ(Pk, ρk, σk)を持つセッションフローk , (k = 1, 2, ..., K) がバッファ量B、リンク帯域Cを持つノードに多重されることを考える。このとき、図4に示すように各セッションフローkに対してリンク帯域ck (ρk ≦ck ≦Pk) を仮想的に割り当てることを考える。ただし、仮想リソースの総量はリンク帯域Cを上回らないようにする。すなわち、下記のとおりの関係とする。
c1＋c2＋・・・＋cK ≦ C （４）
このとき、セッションフローkが使用する仮想的なバッファリソースの最大値bkは、式（３）と同様に、
bk = σk （Pk−ck）／（Pk−ρk） （５）
で表すことが出来る。全フローによる実際のバッファ使用量の最大量bは、仮想バッファ使用量の和を上回ることはないので、
Σbk = Σ σk （Pk−ck）／（Pk−ρk）≦ B （６）
が成り立てば、論理的なパケットロスがゼロになる。言い換えると、式（５）を満たすK組の仮想リソース (bk, ck)に対して、式（４）および（６）が成り立てば、当該リンクにおける論理的なパケットロスはゼロになる。
各セッションフローに割り当てる仮想リソースを決定する第一の方法は、ckを
ck = Pk／（1+B (Pk−ρk)／（C σｋ）） （７）
で与えるものである（非特許文献９参照）。
【００１４】
この方法では、結果として得られるbkの値が、
bk／B＝ck／C （８）
という関係を満たし、仮想帯域と仮想バッファ量のそれぞれが本来のリソース量に占める割合が等しくなり、リソース管理が簡単になるという利点がある。
【００１５】
仮想リソース割り当ての第二の方法として、式（６）で表される仮想バッファ量の総和を最小化するような割当方法が考えられている。この方式を定式化すると、
min{Σσk （Pk−ck）／（Pk−ρk）｝ （９）
ただし、
Σck ≦C、 ρ≦ck ≦Pk （１０）
となる。式（９）の解となるような仮想帯域割り当ては、以下の手順で求められる。
【００１６】
先ず全てのフローに対してρkに等しい仮想帯域を割り当てる。
【００１７】
その後、余った帯域C−Σρkについては、フローごとに以下の式
Tk = σk ／（Pk−ρk） （１１）
で計算されたピークレート送出可能時間Tkについて、Tkの値の大きなフローから順番に、Pk−ρkだけ新たに追加して割り当てていく。
【００１８】
この方式で仮想帯域ckを割り当てた場合、式（６）が最小化されることが知られている（非特許文献１０参照）。
上記のような式（６）が成り立つことを条件とする受付判定法は、論理的なパケットロスをゼロとし、かつノードでの最大遅延時間もB／Cで保証できるため、フローの品質を保証することが可能な方式である。
ここで、第一の方法と第二の方法を比較すると、第一の方法はリソース割り当ての計算が簡単であることが利点となる。第二の方法では計算された最大バッファ使用量は第一の方法で計算される最大バッファ使用量以下となることが保証されているため、受付判定に用いた場合に、より多くのセッションを受け付けられ、収容効率に優れるという利点がある。
【００１９】
以上説明したように、仮想バッファ/トランクモデルを適用することによって、品質を保証した受付判定が可能となる。しかしながら、第一の方法では収容効率、第二の方法では計算の複雑さと管理すべき情報量の多さが課題となる。
【先行技術文献】
【非特許文献】
【００２０】
【非特許文献１】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.
【特許文献】
【００２１】
【特許文献１】特願２００９−１５５５４２号
【発明の概要】
【発明が解決しようとする課題】
【００２２】
上記の課題を解決する手段として、特許文献１（未公開先願）には第三の方法が提案されている。
【００２３】
特許文献１には、あらかじめ設定された閾値ZとTkの値を比較して、Tk＞Zが成り立つ場合には当該フローに対してピーク帯域Pkおよびバッファ容量0を割り当て、Ｔk≦Zが成り立つ場合には平均帯域ρkおよびバッファ容量σkを割り当てるという方法が第三の方法として提案されている。
【００２４】
この方法で各フローに割り当てられる帯域リソースおよびバッファリソースの総和は、閾値Zが適切に設定されれば仮想バッファ／トランクモデルにより実現される任意のリソース割り当ての中で最適なものとなり、第二の方法と同等の収容効率が実現可能であるにも関わらず、計算の複雑さと管理すべき情報量については第一の方法の定数倍にすぎず、第二の方法よりも優れている。しかしながら、収容効率を最大化できる閾値Zの値は接続を要求するフロー全体の特性により変化するため、あらかじめ閾値Zを適切な値に設定しておくことは困難であり、適宜修正する必要があるという課題が残る。
【００２５】
（本発明が解決しようとする課題の具体的な説明）
以下、本発明が解決しようとする課題について、より具体的に説明する。
【００２６】
ここで、仮想リソース割り当てに関する技術は、以下のように表現できる。
【００２７】
いま、セッションフローkのトラヒックパラメータ (Pk, ρk, σk) に対し、X軸方向に帯域リソース量、Y軸方向にバッファリソース量をとる２次元平面上の方向ベクトルを
【００２８】
【数１】
とおく。このとき、セッションフローkが使用するリソース量 (ck, bk) は、２つの方向ベクトルの内分点、
すなわち、
【００２９】
【数２】
であらわすことが可能であり、αk＝1のときがピークレート割当（Pk, 0）, αk＝０のときが平均レート割当 (ρk、σk) に相当する。これは図５に示すとおりである。
【００３０】
次に、セッションフローが複数の場合を考える。セッションフロー数＝2のとき、セッションフローkおよびlのトラヒックパラメータをそれぞれ(Pk, ρk, σk), (Pｌ, ρｌ, σｌ) とおく。ただし、σk/（Pk−ρk）≧σl/（Pl−ρl）とする。このときセッションフローk、lに割り当てられるリソース量の合計は、式(13)で示される方向ベクトルの内分点の合成
【００３１】
【数３】
で示される。ただし、
【００３２】
【数４】
式(14)によるリソース量の合計がとり得る範囲は、図６の四辺形R1-R2-R4-R3の内部領域により与えられる。ここで、R1はセッションフローk, lともに平均レート割当、R2はセッションフローkにピーク割当、セッションフローlに平均割当、R3はセッションフローkに平均割当、セッションフロー lにピーク割当、R4はセッションフローk, lともにピーク割当を実施した場合に相当し、線分R1-R2はセッションフローlに平均割当、線分R2-R4はセッションフローkにピーク割当、線分R1-R3はセッションフローkに平均割当、線分R3-R4はセッションフローlにピーク割当とした場合に相当する。効率的なリソース割当という観点からは、線分R1-R2またはR2-R4上の割当が、帯域リソース、バッファリソースともに少なめの割当となり、線分R1-R3またはR3-R4の割当や、四辺形の内部領域の割当よりも望ましい。
【００３３】
一般的にセッションフロー数がより多い場合では、図7に示すように、リソース割当の合計値は、2次元上の多角形領域であらわすことが可能である。全セッションフローに平均割当を行った場合の点
【００３４】
【数５】
と、全セッションフローにピーク割当を行った場合の点
【００３５】
【数６】
を結ぶ曲線の下限値は、以下のように作成できる。
（手順1）接続セッションフローを、式（１１）のTkが大きい順に並びかえる。
（手順2）最もTkの値が大きいセッションフロー1に対して、ベクトルva(1)をベクトルvp(1)に置き換えた
【００３６】
【数７】
とRAを結ぶ線分を考える。この線分が、セッションフロー1に対するリソース割当のみを式（１３）の範囲で変化させた場合の、全体のリソース割当量に相当する。
【００３７】
(手順3）次にTkの値が大きいセッションフロー2に対して同様の動作を行う。
以下順番にセッションフローnまで繰り返し、点RPに至る曲線を得る。
【００３８】
ここで、式（１１）のTkは、上記手順2、3で作成する線分の傾きの大きさに相当するため、これを下回るリソース割当は実現不可能であり、下限となる。また、曲線の傾きは単調非減少であり、下に凸な曲線となる。
【００３９】
同様に、RAとRPを結ぶ曲線の上限値は、以下の手順で算出できる。
【００４０】
（手順1'）接続セッションフローを、式（１１）のTkが大きい順に並びかえる。
【００４１】
（手順2'）最もTkの値が小さいセッションフローnに対し、ベクトルva(n)をvp(n)に置き換えた
【００４２】
【数８】
とRAを結ぶ線分を考える。この線分が、セッションフローnに対するリソース割当のみを式（１３）の範囲で変化させた場合の、全体のリソース割当量に相当する。
【００４３】
(手順3'）次にTkの値が小さいセッションフローn-1に対して同様の動作を行う。以下セッションフロー1まで繰り返し、点RPに至る曲線を得る。
【００４４】
下限値の曲線と同様、手順1'〜手順3'を上回るリソース割当は実現不可能であり、上限となる。また、曲線の傾きは単調非増加であり、上に凸な曲線となる。したがって、両曲線に囲まれた領域は、凸多角形となる。
【００４５】
この領域と、式（４）および式（６）で規定される長方形領域OBDCが交わる部分が、論理的パケットロスを0とできるリソース割当の実現値に相当する。特に、RAとRPを結ぶ下に凸な曲線が、効率的なリソース割当に相当する。
従来技術における第一の方法では、リソース量を示すベクトル(ck、 bk) の傾きが、C/Bと一致するように、αの値は
α＝(Cσ−Bρ）／（Cσ＋B（P−ρ）） （１５）
で決定される。これを図８に示す。この第一の方法では、αはセッションフローのトラヒックパラメータにより変化するが、算出方法は式（14）で一意に与えられ、他のセッションフローの影響を受けないことと、割当済みバッファリソースの、全バッファリソースに対する割合と、割当済み帯域リソースの、全帯域リソースに対する割合が等しくなり、どちらか一方のリソース割当のみを管理すれば良いというメリットがある。しかしながら、この第一の方法においては、リソースの割当方法の効率が必ずしも良くないという課題がある。つまり、図９では、第一の方法による、2つのセッションフローへのリソース割当の合計量がS1で示されているが、割当済みバッファリソースの、全バッファリソースに対する割合と、割当済み帯域リソースの、全帯域リソースに対する割合が等しくなるようなリソース割当の合計値がS2となるような、より効率の良い2セッションフローへのリソース割当が存在する。
【００４６】
第一の方法のもう一つの課題は、図１０に示すように、σk/ρｋ＜B/Cとなるようなセッションフローに対しては、式（７）によるリソース割当は実行できないことである。この場合、例えば図１０にあるように（ρk, ρk×B/C）というような、必要以上にバッファリソースを消費してしまう。
【００４７】
従来技術における第二の方法は、図7における点RAを始点として、点RPに至る下に凸な曲線を追跡し、辺CD上の点RQを求めることに相当している。点RRのY軸座標がB以下であることと、多角形領域と四角形OBDCが交わることは同値であるため、従来技術における第二の方法は、仮想リソース割り当て方式の中で最適な方式の一つといえる。しかしながら、第二の方法では、下に凸な曲線RA-RPを構成するすべての点の情報を常に管理する必要がある。この点に関して、第二の方法は以下に挙げるような問題点を有する。
【００４８】
(1)曲線RA-RPは接続セッションフロー数に等しい数の点により構成され、セッションフロー数に伴って増加する。
【００４９】
(2)下に凸な曲線を構成するためには、式(11)にあるTkの値が降順となるように並び替えておく必要があり、新規セッションフローを接続するごとに順序を改める必要がある。
【００５０】
(3)接続終了や新規セッションフローの追加によりすべての点の位置が変化するため、再計算が必要となる。
【００５１】
以上の問題点は、実時間性を要求される受付判定において処理時間の増加をもたらすという課題につながっている。
【００５２】
第三の方法では、図7における下に凸多角形領域内の1点(以下、この点をRRとする）を点RAおよびRPと併せて常に管理し、曲線RA-RR-RPが四角形OBDCと交わるか否かによりリソース割当の可否を判断する。この方法で得られる曲線RA-RR-RPは、凸多角形の性質から常に凸多角形の領域内に存在するので、曲線上の点はすべてリソース割当総量の候補となりうる。この曲線は、従来の第二の方法で得られる下に凸な曲線より常に上にあるため、リソース割当の効率性としては第二の方法の方が優れるが、管理する曲線上の点がセッションフロー数に関係なく3点と一定であり、新規接続セッションまたは終了セッションの情報のみを用いて更新可能であることから、第二の方法が持つ課題を克服した方法となっている。また、第三の方法では、従来技術における第一の方法における式（７）によるリソース割当が実施できないようなセッションフローについても問題なく対応可能であり、第一の方法よりも効率性としては勝っていることが期待できる。
【００５３】
ここで、第三の方法における点RRは、以下の手続きにより各セッションフローに割り当てられるリソースの総和により定められる。
【００５４】
(1) セッションフロー数＝０、すなわちリソース割り当てが行われていない時点において、閾値Zをあらかじめ設定しておく。
【００５５】
(2) 接続を要求するセッションフローkのトラヒックパラメータ (Pk, ρk, σk) に対し、式(11)のTkを計算し、Tk>Zであればベクトルvp(k)＝(Pk, 0)、Tk≦Zであれば、ベクトルva(k)＝（ρk, σk）に相当するリソースを割り当てる。
【００５６】
この方法の問題点は、実現される収容効率が閾値Zに依存することである。特許文献1では閾値Zの値を逐次変更していくことで収容効率を改善しているが、閾値Zの値が安定するまで時間がかかるという課題は依然として残っている。
【００５７】
本発明は上記の点に鑑みてなされたものであり、安定した収容効率を実現するための受付判定技術を提供することを目的とする。
【課題を解決するための手段】
【００５８】
上記の課題を解決するために、本発明は、新規セッションフローに帯域およびバッファの２種類のリソースを個別に割り当てて、当該新規セッションフローの通信を行う通信装置の設備量に収まる範囲内で前記新規セッションフローを受け付ける制御を行う呼受付制御システムが実行する呼受付制御方法であって、前記新規セッションフローの受付要求を受信する受信ステップと、前記新規セッションフローへのリソース割り当て方法の候補として、ピーク割り当てあるいは平均割り当ての２種類のいずれかを選択する選択ステップと、既に接続しているセッションフローへの割り当てリソース量に、前記選択ステップにおいて選択されたリソース割り当て方法により定まるリソース量を加えた割り当てリソース総量が、前記通信装置のリソース設備総量に収まる範囲内であれば前記新規セッションフローの要求を受け付ける受付判定ステップと、を有し、前記選択ステップにおいて、前記既に接続しているセッションフローへの割り当てリソース量に、前記新規セッションフローへの割り当てリソース量を加えて得られる帯域リソース量とバッファリソース量の比が、前記通信装置における帯域リソースの設備総量とバッファリソースの設備総量の比により近くなる割り当て方法を選択することを特徴とする呼受付制御方法として構成される。
【００５９】
また、前記呼受付制御方法は、全セッションフローにピーク割り当てを実施するリソース割り当て方法により定まるピーク割り当てリソース総量と、全セッションフローに平均割り当てを実施するリソース割り当て方法により定まる平均割り当てリソース総量とを算出するステップを有し、前記受付判定ステップにおいて、前記割り当てリソース総量が、前記リソース設備総量に収まる範囲内にない場合に、帯域リソースとバッファリソースとを２つの軸としたグラフ上で、前記割り当てリソース総量を示す点と、前記ピーク割り当てリソース総量を示す点とを結ぶ線分上、もしくは、前記割り当てリソース総量を示す点と、前記平均割り当てリソース総量を示す点とを結ぶ線分上に、前記リソース設備総量の範囲に収まる点があれば、前記リソース設備総量の範囲に収まる割り当てが可能であると判断して、前記新規セッションフローの要求を受け付けるようにしてもよい。
【００６０】
また、本発明は、上記呼受付制御の実施の適した呼受付制御システムとして構成することもできるし、当該呼受付制御システムを備える複数の通信装置を伝送路で接続して構成されたネットワークシステムとして構成することもできる。また、本発明は、上記呼受付制御システムを備えるネットワーク制御装置と、伝送路で接続された複数の通信装置とを備えたネットワークシステムであって、前記ネットワーク制御装置は、前記新規セッションフローの通信経路上の各通信装置が有する設備量に収まる範囲内で前記新規セッションフローを受け付ける制御を行うことを特徴とするネットワークシステムとして構成することもできる。
【発明の効果】
【００６１】
本発明によれば、第三の方法で調整すべきパラメータである閾値Zを用いることなく判定を行うことにより、安定した収容効率を実現できる受付判定法を実現できる。本発明に係る技術では、管理情報や計算量は第三の方法と同程度のオーダであるうえ、各セッションフローに対するリソース割り当てはピーク割り当て、あるいは平均割り当てのどちらかに限定されるため、従来技術における第一の方法よりも収容効率は向上する。
【００６２】
さらに、リソース割当の実行可能な領域が凸多角形となる性質から、全セッションフローに対してピーク割り当てを行う方式および全セッションフローに対して平均割り当てを行う方式を加えた3種類のリソース割当方法に対応する３点を結ぶ線分上の全ての点が実行可能な領域内にある性質を利用して、３種類のリソース割当が全て設備量を超過していても実行可能な、効率的なリソース割当が可能な場合が存在することを判定することで、より収容効率を向上させられる受付判定方法が実現可能となる。
【図面の簡単な説明】
【００６３】
【図１】トークンバケットで規定されるトラヒックの最大量A(t)を示す図である。
【図２】キューイングシステムを示す図である。
【図３】使用バッファ量v(t)の変化を示す図である。
【図４】各セッションフローkに対してリンク帯域ckを仮想的に割り当てた状態を示す図である。
【図５】セッションフローkが使用するリソース量 (ck, bk)を示す図である。
【図６】セッションフローkおよびlに割り当てられるリソース量の合計がとり得る範囲を示す図である。
【図７】一般のリソース割当の合計値の範囲に相当する2次元上の多角形領域を示す図である。
【図８】従来技術における第一の方法におけるαの値の算出方法を説明するための図である。
【図９】第一の方法の課題を説明するための図である。
【図１０】第一の方法のもう一つの課題を説明するための図である。
【図１１】実施例１における受付判定方法の処理手順を示す図である。
【図１２】実施例２における受付判定方法の処理手順を示す図である。
【図１３】実施例２における受付判定方法の処理手順（サブフロー１）を示す図である。
【図１４】実施例２における受付判定方法の処理手順（サブフロー２）を示す図である。
【図１５】RRpまたはRRaが四角形OBCDの外部にあるが、設備量(C, B)の範囲内に収まる組み合わせが存在することを説明するための図である。
【図１６】RRpまたはRRaが四角形OBCDの外部にあるが、設備量(C, B)の範囲内に収まる組み合わせが存在することを説明するための図である。
【図１７】実施例３を説明するための図である。
【図１８】実施例４を説明するための図である。
【図１９】受付制御部１００の機能構成図である。
【図２０】新たなセッションフローに対するリソース割り当て方法の例を説明するための図である。
【図２１】新たなセッションフローに対するリソース割り当て方法の例を説明するための図である。
【発明を実施するための形態】
【００６４】
以下、図面を参照して本発明の実施例を説明する。各実施例の説明にあたり用いる記号を以下のように定める。
【００６５】
接続セッションフローのうち、ピーク割り当てを実施するフローの集合をΩp、平均割当を実施するフローの集合をΩaとする。
【００６６】
接続セッションフロー全体に割り当てたリソース量の総量を、RRとする。
【００６７】
接続セッションフローのピークレートの合計値をP、平均レートの合計値をρ、バケットサイズの合計値をσ、接続セッションフローの総数をNとする。
【００６８】
ピーク割当を行った場合のリソース総量をRP＝（P, 0）、平均割当を行った場合のリソース総量をRA=（ρ, σ）とする。なお、RR、RP、RAはいずれもベクトルである。また、以下の説明における各点もベクトルである。
【００６９】
（実施例１）
図11に、実施例１における受付判定方法の処理手順を示す。なお、ここでの処理は、後述する実施例における装置（ルータ、ネットワーク制御装置）により実行することを想定しているが、処理を実行する装置はルータやネットワーク制御装置に限られるわけではない。例えば、一般的なコンピュータに、以下の処理アルゴリズムを記述したプログラムを実行させて処理を行うようにしてもよい。ただし、ルータやネットワーク制御装置においても、その内部で以下の処理を実行する主体は、ＣＰＵとメモリとを有するコンピュータに相当する機能部（後述する受付制御機能部１００に相当）であるから、一般的なコンピュータにより処理を行う場合と、ルータやネットワーク制御装置で処理を行う場合とで、受付判定方法の処理として実質的な違いはない。つまり、いずれの場合も、各種パラメータや各変数の値がメモリ等の記憶手段に格納され、プログラムに従って、ＣＰＵにより適宜読み出されて処理が行われる。また、プログラムを用いる方式の他、処理アルゴリズムをハードウェアロジック回路として実現し、当該ハードウェアロジック回路が受付判定方法の処理を行うようにしてもよい。実施例２でも同様である。この場合、当該ハードウェアロジック回路が後述する受付制御機能部１００に相当する。
【００７０】
ステップ１）初期条件として接続セッションフローが存在しない状況を仮定し、Ωp={}、Ωa={}、RR=(0, 0)とする。
【００７１】
ステップ２）トラヒックパラメータ（Pk, ρk, σk)を有する、新規受付を要求するセッションフローkが到着した場合（つまり、新規受付要求を受信した場合）、ステップ３へ進む。トラヒックパラメータ(Pj, ρj, σj)を有する、既接続セッションフローjの終了要求が到着した場合、ステップ１０へ進む。
【００７２】
ステップ３）新規受付要求から、トラヒックパラメータ（Pk, ρk, σk)を取得し、セッションkを接続した場合に必要となるリソース量の総和の候補RRp、RRaを以下のように定め、これら2点と直線y=(B/C)xとの距離に比例した値Dp、Daを計算する。
RRp = (xp, yp) = RR+(Pk, 0)
RRa = (xa, Ya) = RR+(ρk, σk)
Dp = |B・xp - C・yp|
Da = |B・xa - C・ya|
ステップ４）ステップ３において計算した値であるDpとDa とを比較し、Dp ≦ Daならばステップ５へ、Dp > Daならばステップ８へ進む。なお、ここでの選択は、既に接続しているセッションフローへの割り当てリソース量に、新規セッションフローへの割り当てリソース量を加えて得られる帯域リソース量とバッファリソース量の比(yp/xpまたはya/xa)が、帯域リソースの設備総量とバッファリソースの設備総量の比(B/C)により近くなる割り当て方法を選択することに相当する。実施例２でも同様である。
【００７３】
ステップ５）RRpが四角形OBCDの内部にあるかどうかをチェックする。すなわち
xp ≦ C かつ yp ≦ B
が成り立つかどうかをチェックし、成り立てば、ステップ６に進み、成り立たない場合はステップ７に進む。
【００７４】
ステップ６）セッションフローkを含むリソース割り当てが設備量(C, B)の範囲内に収まると判断し、セッションフローkの受付を許可し、RR=RRpとし、kをΩpに加えてステップ２へ進む。
【００７５】
ステップ７）セッションフローkの受付を拒否し、ステップ２へ進む。
【００７６】
ステップ８）RRaが四角形OBCDの内部にあるかどうかをチェックする。すなわち
xa ≦ C かつ ya ≦ B
が成り立つかどうかをチェックし、成り立てば、ステップ９に進み、成り立たない場合はステップ７に進んでセッションフローkの受付を拒否する。
【００７７】
ステップ９）セッションフローkを含むリソース割り当てが設備量(C, B)の範囲内に収まると判断し、セッションフローkの受付を許可し、RR=RRaとし、kをΩaに加えてステップ２へ進む。
【００７８】
ステップ１０）接続終了要求からトラヒックパラメータ(Pj, ρj, σj)を取得し、セッションフローjがΩpに含まれるかどうかをチェックする。すなわち、セッションフローjに対してピーク割り当てを行っていたかどうかをチェックする。セッションフローjがΩpに含まれていた場合はステップ１１に進み、含まれていない場合はステップ１２に進む。
【００７９】
ステップ１１）RR = RR -(Pj, 0)とし、Ωpからセッションフローjを除外する。セッションフローjの接続を終了した後、ステップ2へ進む。
【００８０】
ステップ１２）セッションフローjがΩaに含まれる、すなわち平均割当を行っていた場合は、RR = RR -(ρk, σk)とし、Ωaからセッションフローjを除外する。セッションフローjの接続を終了した後、ステップ2へ進む。
【００８１】
（実施例２）
次に、図１２、図１３、図１４のフローチャートを参照して、実施例２に係る受付判定方法を説明する。
【００８２】
ステップ１）初期条件として接続セッションフローが存在しない状況を仮定し、Ωp={}、Ωa={}、RR=(0, 0)、RP=(0, 0)、RA=(0, 0)とする。
【００８３】
ステップ２）トラヒックパラメータ（Pk, ρk, σk)を有する、新規受付を要求するセッションフローkが到着した場合（つまり、新規受付要求を受信した場合）、ステップ３へ進む。トラヒックパラメータ(Pj, ρj, σj)を有する、既接続セッションフローjの終了要求が到着した場合、ステップ１０へ進む。
【００８４】
ステップ３）新規受付要求から、トラヒックパラメータ（Pk, ρk, σk)を取得し、セッションkを接続した場合に必要となるリソース量の総和の候補RRp、RRaを以下の様に定め、これら2点と直線y=(B/C)xとの距離に比例した値Dp、 Daを計算する。
RRp = (xp, yp) = RR+(Pk, 0)
RRa = (xa, Ya) = RR+(ρk, σk)
Dp = |B・xp - C・yp|
Da = |B・xa - C・ya|
さらに、RP'=(P, 0) = RP+(Pk, 0)、RA'= (ρ, σ) = RA+(ρk, σk)を計算する。
【００８５】
ステップ４）ステップ３において計算した値であるDpとDa とを比較し、Dp ≦ Daならばサブフロー１（図１３）へ進み（ステップ１００）、Dp > Daならばサブフロー２（図１４）へ進む（ステップ２００）。
【００８６】
以下、図１３を参照してサブフロー１を説明する。
【００８７】
ステップ１０１）xpとCとの比較、及びypとBとの比較を行う。比較の結果、{xp≦Cかつyp≦B}が成り立てばステップ１０２に進み、{xp＞Cかつyp≦B}が成り立てばステップ１０３に進み、{xp≦C かつ yp＞B}が成り立てばステップ１０５に進み、{xp＞C かつ yp＞B}が成り立てばステップ１０６に進む。
【００８８】
ステップ１０２）この場合、{xp≦Cかつyp≦B}であるから、RRpが四角形OBCDの内部にある。すなわち、セッションフローkを含むリソース割り当てが設備量(C, B)の範囲内に収まり、セッションフローkの受付が可能と判断し、接続可能の結果をもってステップ５（図１２）に進む。
【００８９】
ステップ１０３）この場合、｛xp＞Cかつyp≦B｝が成り立っており、なおかつ
(yp -σ) (C -ρ）/ (xp -ρ) + σ≦B
が成り立つかどうかをチェックする。成り立っている場合、RRpは四角形OBCDの外部にあるが、図１５に示すように、RRpとRA'を結ぶ線分が四角形OBCDと交わっているため、セッションフローkを含むリソース割り当ての全体量として、設備量(C, B)の範囲内に収まる組み合わせが存在するので、セッションフローkの受付が可能と判断し、ステップ１０２に進む。成り立たない場合は、ステップ１０４に進む。
【００９０】
ステップ１０４）接続不可の結果をもってステップ５（図１２）に進む。
【００９１】
ステップ１０５）この場合、｛xp≦C かつ yp＞B｝が成り立ち、なおかつ
yp (C -P）/ (xp -P) ≦ B
が成り立つかどうかをチェックする。成り立っている場合、RRpは四角形OBCDの外部にあるが、図１６に示すとおり、RRpとRP'を結ぶ線分が四角形OBCDと交わっているため、セッションフローkを含むリソース割り当ての全体量として、設備量(C，B)の範囲内に収まる組み合わせが存在するので、セッションフローkの受付が可能と判断し、ステップ１０２に進む。成り立たない場合は、ステップ１０６に進む。
【００９２】
ステップ１０６）接続不可の結果を保持してステップ５（図１２）に進む。
【００９３】
次に、図１４を参照してサブフロー２を説明する。
【００９４】
ステップ２０１）xaとCとの比較、及びyaとBとの比較を行う。比較の結果、{xa≦Cかつya≦B}が成り立てばステップ２０２に進み、{xa＞Cかつya≦B}が成り立てばステップ２０３に進み、{xa≦C かつ ya＞B}が成り立てばステップ２０５に進み、{xa＞C かつ ya＞B}が成り立てばステップ２０６に進む。
【００９５】
ステップ２０２）この場合、{xa≦Cかつya≦B}であるから、RRaが四角形OBCDの内部にある。すなわち、セッションフローkを含むリソース割り当てが設備量(C, B)の範囲内に収まり、セッションフローkの受付が可能と判断し、接続可能の結果をもってステップ７（図１２）に進む。
【００９６】
ステップ２０３）この場合、｛xa＞Cかつya≦B｝が成り立っており、なおかつ
(ya -σ) (C -ρ）/ (xa -ρ) + σ≦B
が成り立つかどうかをチェックする。成り立つ場合、RRaは四角形OBCDの外部にあるが、図１５に示すように、RRaとRA'を結ぶ線分が四角形OBCDと交わっているため、セッションフローkを含むリソース割り当ての全体量として、設備量(C, B)の範囲内に収まる組み合わせが存在するので、セッションフローkの受付が可能と判断し、ステップ２０２に進む。成り立たない場合は、ステップ２０４に進む。
【００９７】
ステップ２０４）接続不可の結果をもってステップ７（図１２）に進む。
【００９８】
ステップ２０５）この場合、｛xa≦C かつ ya＞B｝が成り立ち、なおかつ
ya (C -P）/ (xa -P) ≦ B
が成り立つかどうかをチェックする。成り立っている場合、RRaは四角形OBCDの外部にあるが、図１６に示すとおり、RRaとRP'を結ぶ線分が四角形OBCDと交わっているため、セッションフローkを含むリソース割り当ての全体量として、設備量(C，B)の範囲内に収まる組み合わせが存在するので、セッションフローkの受付が可能と判断し、ステップ２０２に進む。成り立たない場合は、ステップ２０６に進む。
【００９９】
ステップ２０６）接続不可の結果を保持してステップ７（図１２）に進む。
【０１００】
以下、図１２に戻って説明を続ける。
【０１０１】
ステップ５）サブフロー１での処理結果が、「接続可能」である場合、ステップ６に進み、「接続不可」である場合、ステップ９に進む。
【０１０２】
ステップ６）セッションフローkの接続を許可し、RR=RRp、RP=RP'、RA=RA'とし、kをΩpに加えてステップ２へ進む。
【０１０３】
ステップ７）サブフロー１での処理結果が、「接続可能」である場合、ステップ８に進み、「接続不可」である場合、ステップ９に進む。
【０１０４】
ステップ８）セッションフローkの接続を許可し、RR=RRa、RP=RP'、RA=RA'とし、kをΩpに加えてステップ２へ進む。
【０１０５】
ステップ９）セッションフローkの受付を拒否し、ステップ２へ進む。
【０１０６】
ステップ１０）接続終了要求からトラヒックパラメータ(Pj, ρj, σj)を取得し、セッションフローjがΩpに含まれるかどうかをチェックする。すなわち、セッションフローjに対してピーク割り当てを行っていたかどうかをチェックする。セッションフローjがΩpに含まれていた場合はステップ１１に進み、含まれていない場合はステップ１２に進む。
【０１０７】
ステップ１１）RR = RR -(Pj, 0)、RP = RP -(Pj, 0)、RA = RA - (ρj, σj) とし、Ωpからセッションフローjを除外する。セッションフローjの接続を終了した後、ステップ2へ進む。
【０１０８】
ステップ１２）セッションフローjがΩaに含まれる、すなわち平均割当を行っていた場合は、RR = RR - (ρj, σj)、RP = RP -(Pj, 0)、RA = RA -(ρj, σj)とし、Ωaからセッションフローjを除外する。セッションフローjの接続を終了した後、ステップ２へ進む。
【０１０９】
（実施例３）
次に、本発明の実施例３について説明する。本実施例では、図１７に示すネットワークシステム上において、本発明の受付判定方法を実現した形態の例を示す。図１７に示すネットワークシステムは、通信ルータ１４、１５、１６が伝送路で接続されて構成される通信ネットワーク１０に、ユーザのターミナル装置（TE）１１、１８がユーザネットワークインタフェース装置１３、１７を介して接続されるとともに、ネットワーク制御装置１２が接続されたシステムである。本実施例では、各通信ルータ（R）が、実施例１または実施例２で説明した受付判定処理を実行する機能を有しており、各通信ルータ（R）が、ネットワーク制御装置１２からの要求に基づいて受付判定処理を行う。
【０１１０】
以下、このネットワークシステムで実行される受付判定方法の例を説明する。以下で説明する各ステップ番号は、図１７に示すステップ番号と対応している。
【０１１１】
ステップ１）ユーザのターミナル装置（TE）１１から、新規セッションフローの接続要求が、トラヒックパラメータ情報とともにネットワーク制御装置１２に通知される。
【０１１２】
ステップ２）ネットワーク制御装置１２は、新規セッションの通信経路上の通信ルータ（R）１４、１５を識別し、当該通信ルータ（R）１４、１５に、新規セッションフローのトラヒックパラメータを新規受付要求として通知する。
【０１１３】
ステップ３）各通信ルータ（R）１４、１５は、新規セッションフローを受け付けることで自身が有する設備量の範囲内でのリソース割当が可能かどうかを、実施例1または2の方法を用いて判定し、受付可否をネットワーク制御装置１２に通知する。
【０１１４】
ステップ４）ネットワーク制御装置１２は、新規セッションフローの通信経路上のすべての通信ルータ（R）１４、１５から新規セッションフローの受付許可が得られた場合、新規セッションフローの接続許可をユーザのターミナル装置（TE）１１および通信ルータ（R）１４、１５に通知する(新規セッションフローの接続）。もしいずれかの通信ルータ（R）から受付不可を通知された場合、新規セッションフローは受け付けられないのでユーザのターミナル装置（TE)１１に接続拒否を通知し、通信ルータ（R）１４、１５には新規セッションフローの通信終了を通知する(ステップ7へ）。
【０１１５】
ステップ５）通信中のセッションフローを終了する場合、ユーザのターミナル装置（TE）１８からネットワーク制御装置１２に当該セッションの終了が通知される。
【０１１６】
ステップ６）ネットワーク制御装置１２は、当該セッションの通信系路上の通信ルータ（R）１６に対し、当該セッションの通信終了を通知する。
【０１１７】
ステップ７）接続終了要求を受信した通信ルータ（R）は、実施例１または実施例２で説明した処理を行うことにより、通信終了したセッションフローに関する情報を削除する。
【０１１８】
(実施例４）
次に、本発明の実施例４について説明する。本実施例では、図１７に示す構成と同様の、図１８に示すネットワークシステム上において、本発明の受付判定方法を実現した形態の例を示す。本実施例では、ネットワーク制御装置１２が、通信ネットワーク１０を構成する各通信ルータ（R）の設備情報等を有しており、ネットワーク制御装置１２が、受付判定処理を行うこととしている。
ステップ１）ユーザのターミナル装置（TE）１１から、新規セッションフローの接続要求が、トラヒックパラメータ情報とともにネットワーク制御装置１２に通知される。
【０１１９】
ステップ２）ネットワーク制御装置１２は、新規セッションフローの通信経路上の通信ルータ（R）において、新規セッションフローを受け付けることで各通信ルータ（R）が有する設備量の範囲内でのリソース割当が可能かどうかを、実施例１または２の方法を用いて判定し、受付可否を判定する。
【０１２０】
ステップ３）ネットワーク制御装置１２は、新規セッションフローの通信経路上のすべての通信ルータ（R）において、設備量の範囲内でのリソース割当が可能と判断した場合、新規セッションフローの接続許可をユーザターミナル装置（TE）１１に通知する(新規セッションフローの接続）。もしいずれかの通信ルータ（R）において、設備量の範囲内でのリソース割当が不可と判断した場合、新規セッションフローは受け付けられないのでユーザターミナル装置（TE)１１に接続拒否を通知する。
【０１２１】
ステップ４）通信中のセッションフローを終了する場合、ユーザのターミナル装置（TE）１８からネットワーク制御装置１２に当該セッションフローの終了が通知される。
【０１２２】
ステップ５）ネットワーク制御装置１２は、実施例１または２で説明した処理を行うことにより、当該セッションフローに関する情報を削除する。
（装置構成）
上記実施例３における各通信ルータ内、及び上記実施例３におけるネットワーク制御装置１２内のそれぞれにおいて、実施例１あるいは実施例２の受付判定方法を実行する受付制御機能部１００を備えている。なお、当該受付制御機能部１００を備えるシステム（もしくは装置）を呼受付制御システムと呼ぶことができる。また、受付制御機能部１００自身を呼受付制御システムと呼んでもよい。
【０１２３】
受付制御機能部１００の機能構成例を図１９に示す。図１９に示すように、受付制御機能部１００は、入出力部１１０、セッションフロー情報記憶部１２０、リソース割り当て状態記憶部１３０、演算機能部１４０を備える。
【０１２４】
入出力部１１０は、ユーザのターミナル装置（TE）からのセッションフローの接続要求およびセッションフロー終了要求の受け取りや、新規セッションフローの接続許可あるいは拒否通知など、外部との情報の入出力を実行する。すなわち、入出力部１１０は、新規セッションフローの受付要求を受信する受信手段を含む。
【０１２５】
セッションフロー情報記憶部１２０は、接続セッションフローおよび新規接続要求セッションフローのパラメータ（Pk, ρk, σk）、ピーク割り当てを実行するセッションフローの集合Ωp、および平均割り当てを実行するセッションフローの集合Ωaの情報を記憶する。
【０１２６】
リソース割り当て状態記憶部１３０は、全セッションフローへ割り当てたリソース状況にかかわる情報RR、RRp、RRa、RP、RA、RP'、RA'を記憶する。
【０１２７】
演算機能部１４０は、セッションフロー情報記憶部１２０およびリソース割り当て状態記憶部１３０内の情報を読み出して、新規セッションフローの接続要求を受け入れた場合にリソースが不足するか否かを判定するのに必要な演算（実施例１または実施例２のアルゴリズム）を実行し、接続要求の受付可否を入出力部１１０へ通知する、更に、新規セッションフローを接続する場合には、当該セッションフローへピーク割り当て、平均割り当てのどちらとするかをセッションフロー情報記憶部１２０へ通知し、ΩpあるいはΩaを更新させるとともに、新たなリソース割り当て状態RR（およびRP、RA）をリソース割り当て状態記憶部１３０へ通知し、当該情報を更新させる。セッションフロー終了の情報を入出力部１１０から受け取った場合には、当該セッションフローの情報をセッションフロー情報記憶部１２０へ通知し、当該セッションフローのパラメータを削除させ、ΩpあるいはΩaを更新させるとともに、新たなリソース割り当て状態RR（およびRP、RA）をリソース割り当て状態記憶部１３０へ通知し、当該情報を更新させる。
【０１２８】
すなわち、演算機能部１４０と、セッションフロー情報記憶部１２０と、リソース割り当て状態記憶部１３０とで、新規セッションフローへのリソース割り当て方法の候補として、ピーク割り当てあるいは平均割り当ての２種類のいずれかを選択する選択手段と、既に接続しているセッションフローへの割り当てリソース量に、前記選択手段において選択されたリソース割り当て方法により定まるリソース量を加えた割り当てリソース総量が、前記通信装置のリソース設備総量に収まる範囲内であれば前記新規セッションフローの要求を受け付ける受付判定手段とを構成している。
【０１２９】
ここで、前記選択手段は、前記既に接続しているセッションフローへの割り当てリソース量に、前記新規セッションフローへの割り当てリソース量を加えて得られる帯域リソース量とバッファリソース量の比が、前記通信装置における帯域リソースの設備総量とバッファリソースの設備総量の比により近くなる割り当て方法を選択する。
【０１３０】
また、上記構成には、全セッションフローにピーク割り当てを実施するリソース割り当て方法により定まるピーク割り当てリソース総量と、全セッションフローに平均割り当てを実施するリソース割り当て方法により定まる平均割り当てリソース総量とを算出する手段が含まれ、前記受付判定手段は、前記割り当てリソース総量が、前記リソース設備総量に収まる範囲内にない場合に、帯域リソースとバッファリソースとを２つの軸としたグラフ上で、前記割り当てリソース総量を示す点と、前記ピーク割り当てリソース総量を示す点とを結ぶ線分上、もしくは、前記割り当てリソース総量を示す点と、前記平均割り当てリソース総量を示す点とを結ぶ線分上に、前記リソース設備総量の範囲に収まる点があれば、前記リソース設備総量の範囲に収まる割り当てが可能であると判断して、前記新規セッションフローの要求を受け付ける機能を備える。
【０１３１】
（実施の形態の効果）
上記のとおり、各実施例を用いて説明した本発明に係る技術では、ピークレート、平均レート、バケットサイズで規定するトークンバケットモデルで通信セッションフローの特性を現すネットワークで、各セッションフローに対する排他的なリソース割当により論理的パケット損失をゼロにすることで品質保証を実現する受付判定技術に関して、接続セッションフローの本数に依存せず、一定の管理情報と処理量を要するのみで、効率的なリソース割当が可能な方法が実現可能となる。
【０１３２】
一般に仮想バッファ/トランクモデルを用いた仮想リソース割り当て方法においては、帯域リソースとバッファリソースのどちらかが早く枯渇してしまう方式では収容効率が悪くなるため、割り当てリソースの総量が四角形OBCDの対角線ODに沿っている状況が望ましい。従来技術による第一の方法では、これを実現するために各セッションフローへの個別割り当てリソース量がOD上の点となるようにしているが、これは収容効率の面で劣る。従来技術による第二の方法および第三の方法では、収容効率を最大化するため、各セッションフローへのリソース割り当てをピーク割り当てあるいは平均割り当てのどちらかに限定する手法を採用しているが、第二の方法では管理情報や計算量の多さが課題となり、第三の方法では収容効率を最大化するために設定すべき閾値が直接求めることが難しいという課題を有していた。
【０１３３】
一方、本発明に係る技術（実施例１または実施例２で説明した方法）では、新たなセッションフローに対するリソース割り当て量をピーク割り当てあるいは平均割り当てのどちらかにすべきかを決定する仕組みとして、既に接続済みのセッションフローへの割り当てリソースの総量と、新たなセッションフローに対するリソース割り当てとの合計が線分ODに近づくような選択を行っている。
【０１３４】
すなわち、実施例１または実施例２において、図２０に示すように、dp<daである場合、すなわち、Dpに対応するdpがDaに対応するdaより小さい場合、RRaよりもRRpが線分ODに近い。従って、新規セッションフローkに対するリソース割り当てはピーク割り当て(Pk, 0)を採用している（図１１のステップ４、６、及び図１２のステップ４、６）。
【０１３５】
逆に、図２１に示すように、dpがdaより大きい場合、RRpよりもRRaが線分ODに近い。従って、新規セッションフローkに対するリソース割り当ては平均割り当て（ρk, σk)を採用している（図１１のステップ４、９、及び図１２のステップ４、８）。
【０１３６】
このような選択を行うことで、割り当てリソースの総量がバランスよく消費され、結果として収容効率があがることが期待される。本発明に係る技術では、管理情報や計算量は既存の第三の方法と同程度のオーダにとどまるうえ、第三の方法で最適化が必要となる閾値を用いる必要がないという効果を有する。
【産業上の利用可能性】
【０１３７】
本発明は、IP網やMPLS網を用いて品質保証型サービスを提供するネットワークにおける受付判定に適用できる。
【０１３８】
本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において、種々変更・応用が可能である。
【符号の説明】
【０１３９】
１０ 通信ネットワーク
１１、１８ ターミナル装置
１２ ネットワーク制御装置
１３、１７ ユーザネットワークインタフェース装置
１４、１５、１６ 通信ルータ
１００ 受付制御機能部
１１０ 入出力部
１２０ セッションフロー情報記憶部
１３０ リソース割り当て状態記憶部
１４０ 演算機能部
【特許請求の範囲】
【請求項１】
新規セッションフローに帯域およびバッファの２種類のリソースを個別に割り当てて、当該新規セッションフローの通信を行う通信装置の設備量に収まる範囲内で前記新規セッションフローを受け付ける制御を行う呼受付制御システムが実行する呼受付制御方法であって、
前記新規セッションフローの受付要求を受信する受信ステップと、
前記新規セッションフローへのリソース割り当て方法の候補として、ピーク割り当てあるいは平均割り当ての２種類のいずれかを選択する選択ステップと、
既に接続しているセッションフローへの割り当てリソース量に、前記選択ステップにおいて選択されたリソース割り当て方法により定まるリソース量を加えた割り当てリソース総量が、前記通信装置のリソース設備総量に収まる範囲内であれば前記新規セッションフローの要求を受け付ける受付判定ステップと、を有し、
前記選択ステップにおいて、前記既に接続しているセッションフローへの割り当てリソース量に、前記新規セッションフローへの割り当てリソース量を加えて得られる帯域リソース量とバッファリソース量の比が、前記通信装置における帯域リソースの設備総量とバッファリソースの設備総量の比により近くなる割り当て方法を選択する
ことを特徴とする呼受付制御方法。
【請求項２】
全セッションフローにピーク割り当てを実施するリソース割り当て方法により定まるピーク割り当てリソース総量と、全セッションフローに平均割り当てを実施するリソース割り当て方法により定まる平均割り当てリソース総量とを算出するステップを有し、
前記受付判定ステップにおいて、前記割り当てリソース総量が、前記リソース設備総量に収まる範囲内にない場合に、帯域リソースとバッファリソースとを２つの軸としたグラフ上で、前記割り当てリソース総量を示す点と、前記ピーク割り当てリソース総量を示す点とを結ぶ線分上、もしくは、前記割り当てリソース総量を示す点と、前記平均割り当てリソース総量を示す点とを結ぶ線分上に、前記リソース設備総量の範囲に収まる点があれば、前記リソース設備総量の範囲に収まる割り当てが可能であると判断して、前記新規セッションフローの要求を受け付ける
ことを特徴とする請求項１に記載の呼受付制御方法。
【請求項３】
新規セッションフローに帯域およびバッファの２種類のリソースを個別に割り当てて、当該新規セッションフローの通信を行う通信装置の設備量に収まる範囲内で前記新規セッションフローを受け付ける制御を行う呼受付制御システムであって、
前記新規セッションフローの受付要求を受信する受信手段と、
前記新規セッションフローへのリソース割り当て方法の候補として、ピーク割り当てあるいは平均割り当ての２種類のいずれかを選択する選択手段と、
既に接続しているセッションフローへの割り当てリソース量に、前記選択手段により選択されたリソース割り当て方法により定まるリソース量を加えた割り当てリソース総量が、前記通信装置のリソース設備総量に収まる範囲内であれば前記新規セッションフローの要求を受け付ける受付判定手段と、を有し、
前記選択手段は、前記既に接続しているセッションフローへの割り当てリソース量に、前記新規セッションフローへの割り当てリソース量を加えて得られる帯域リソース量とバッファリソース量の比が、前記通信装置における帯域リソースの設備総量とバッファリソースの設備総量の比により近くなる割り当て方法を選択する
ことを特徴とする呼受付制御システム。
【請求項４】
全セッションフローにピーク割り当てを実施するリソース割り当て方法により定まるピーク割り当てリソース総量と、全セッションフローに平均割り当てを実施するリソース割り当て方法により定まる平均割り当てリソース総量とを算出する手段を有し、
前記受付判定手段は、前記割り当てリソース総量が、前記リソース設備総量に収まる範囲内にない場合に、帯域リソースとバッファリソースとを２つの軸としたグラフ上で、前記割り当てリソース総量を示す点と、前記ピーク割り当てリソース総量を示す点とを結ぶ線分上、もしくは、前記割り当てリソース総量を示す点と、前記平均割り当てリソース総量を示す点とを結ぶ線分上に、前記リソース設備総量の範囲に収まる点があれば、前記リソース設備総量の範囲に収まる割り当てが可能であると判断して、前記新規セッションフローの要求を受け付ける
ことを特徴とする請求項３に記載の呼受付制御システム。
【請求項５】
請求項３または４に記載の呼受付制御システムを備える複数の通信装置を伝送路で接続して構成されたネットワークシステム。
【請求項６】
請求項３または４に記載の呼受付制御システムを備えるネットワーク制御装置と、伝送路で接続された複数の通信装置とを備えたネットワークシステムであって、
前記ネットワーク制御装置は、前記新規セッションフローの通信経路上の各通信装置が有する設備量に収まる範囲内で前記新規セッションフローを受け付ける制御を行う
ことを特徴とするネットワークシステム。
【請求項１】
新規セッションフローに帯域およびバッファの２種類のリソースを個別に割り当てて、当該新規セッションフローの通信を行う通信装置の設備量に収まる範囲内で前記新規セッションフローを受け付ける制御を行う呼受付制御システムが実行する呼受付制御方法であって、
前記新規セッションフローの受付要求を受信する受信ステップと、
前記新規セッションフローへのリソース割り当て方法の候補として、ピーク割り当てあるいは平均割り当ての２種類のいずれかを選択する選択ステップと、
既に接続しているセッションフローへの割り当てリソース量に、前記選択ステップにおいて選択されたリソース割り当て方法により定まるリソース量を加えた割り当てリソース総量が、前記通信装置のリソース設備総量に収まる範囲内であれば前記新規セッションフローの要求を受け付ける受付判定ステップと、を有し、
前記選択ステップにおいて、前記既に接続しているセッションフローへの割り当てリソース量に、前記新規セッションフローへの割り当てリソース量を加えて得られる帯域リソース量とバッファリソース量の比が、前記通信装置における帯域リソースの設備総量とバッファリソースの設備総量の比により近くなる割り当て方法を選択する
ことを特徴とする呼受付制御方法。
【請求項２】
全セッションフローにピーク割り当てを実施するリソース割り当て方法により定まるピーク割り当てリソース総量と、全セッションフローに平均割り当てを実施するリソース割り当て方法により定まる平均割り当てリソース総量とを算出するステップを有し、
前記受付判定ステップにおいて、前記割り当てリソース総量が、前記リソース設備総量に収まる範囲内にない場合に、帯域リソースとバッファリソースとを２つの軸としたグラフ上で、前記割り当てリソース総量を示す点と、前記ピーク割り当てリソース総量を示す点とを結ぶ線分上、もしくは、前記割り当てリソース総量を示す点と、前記平均割り当てリソース総量を示す点とを結ぶ線分上に、前記リソース設備総量の範囲に収まる点があれば、前記リソース設備総量の範囲に収まる割り当てが可能であると判断して、前記新規セッションフローの要求を受け付ける
ことを特徴とする請求項１に記載の呼受付制御方法。
【請求項３】
新規セッションフローに帯域およびバッファの２種類のリソースを個別に割り当てて、当該新規セッションフローの通信を行う通信装置の設備量に収まる範囲内で前記新規セッションフローを受け付ける制御を行う呼受付制御システムであって、
前記新規セッションフローの受付要求を受信する受信手段と、
前記新規セッションフローへのリソース割り当て方法の候補として、ピーク割り当てあるいは平均割り当ての２種類のいずれかを選択する選択手段と、
既に接続しているセッションフローへの割り当てリソース量に、前記選択手段により選択されたリソース割り当て方法により定まるリソース量を加えた割り当てリソース総量が、前記通信装置のリソース設備総量に収まる範囲内であれば前記新規セッションフローの要求を受け付ける受付判定手段と、を有し、
前記選択手段は、前記既に接続しているセッションフローへの割り当てリソース量に、前記新規セッションフローへの割り当てリソース量を加えて得られる帯域リソース量とバッファリソース量の比が、前記通信装置における帯域リソースの設備総量とバッファリソースの設備総量の比により近くなる割り当て方法を選択する
ことを特徴とする呼受付制御システム。
【請求項４】
全セッションフローにピーク割り当てを実施するリソース割り当て方法により定まるピーク割り当てリソース総量と、全セッションフローに平均割り当てを実施するリソース割り当て方法により定まる平均割り当てリソース総量とを算出する手段を有し、
前記受付判定手段は、前記割り当てリソース総量が、前記リソース設備総量に収まる範囲内にない場合に、帯域リソースとバッファリソースとを２つの軸としたグラフ上で、前記割り当てリソース総量を示す点と、前記ピーク割り当てリソース総量を示す点とを結ぶ線分上、もしくは、前記割り当てリソース総量を示す点と、前記平均割り当てリソース総量を示す点とを結ぶ線分上に、前記リソース設備総量の範囲に収まる点があれば、前記リソース設備総量の範囲に収まる割り当てが可能であると判断して、前記新規セッションフローの要求を受け付ける
ことを特徴とする請求項３に記載の呼受付制御システム。
【請求項５】
請求項３または４に記載の呼受付制御システムを備える複数の通信装置を伝送路で接続して構成されたネットワークシステム。
【請求項６】
請求項３または４に記載の呼受付制御システムを備えるネットワーク制御装置と、伝送路で接続された複数の通信装置とを備えたネットワークシステムであって、
前記ネットワーク制御装置は、前記新規セッションフローの通信経路上の各通信装置が有する設備量に収まる範囲内で前記新規セッションフローを受け付ける制御を行う
ことを特徴とするネットワークシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【公開番号】特開２０１２−４８４１（Ｐ２０１２−４８４１Ａ）
【公開日】平成２４年１月５日（２０１２．１．５）
【国際特許分類】
【出願番号】特願２０１０−１３７７５９（Ｐ２０１０−１３７７５９）
【出願日】平成２２年６月１６日（２０１０．６．１６）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
【公開日】平成２４年１月５日（２０１２．１．５）
【国際特許分類】
【出願日】平成２２年６月１６日（２０１０．６．１６）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
[ Back to top ]