JPH02185134A - 網内リソース管理方法 - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 〔産業上の利用分野〕 本発明は、低速から高速までの種々の通信速度で１時間
的変動を伴うバーストトラヒックに対して、ユーザから
の実時間通信や高信頼度通信等の種々の通信品質を同時
に満足させることが可能で、かつ網内リソースを効率よ
く運用させることが可能な網内リソース管理方法に関す
る。

〔従来の技術〕

従来より、固定ルート上でパケット形式により通信を行
う方式としては、例えば、「スタテイスティカル、スイ
ッチング、アーキテクチャーズ、：７オ＋、７ユーチヤ
ー、サービセスｊ　　（Ｋｕｌｔｚｏｒ。

Ｍｏｎｔｇｏｍｅｒｙ　：　５ｔａｔｉｓｔｉｃａｌ　
　Ｉ　Ｓ　Ｓ’　８４．Ｍａｙ１９８４）に記載された
高速パケット交換方式がある。

上記高速パケット交換方式においては、呼設定の流量制
御論理として、呼設定時に発加入者にその呼の最大スル
ープットを宣言させ、ルーチングはこの宣言値により行
ってしぐる。なお、ここで、スループットとは、単位時
間当りのパケット転送箇所を言い、スロット型の場合に
は、スロットの筒数を言う。

パケット通信網においては、交換機や多重化装置、およ
びクロスコネクト等のノードと、これらのノードおよび
ユーザ端末を接続する伝送路等のリンクにより構成され
、該リンクおよびバッファ等の網内リソースを共用する
。また、パケット通信網では、これらの網内リソースを
共用して、トラヒック間の統計的多重を行い、さらには
、エンドツーエンド遅延品質、廃棄品質等の通信品質を
確率的に保証する１通常、トラヒック属性パラメータお
よび通信品質を表わすサービスクラスの値が規定されて
おり、ユーザは１通信要求を行う呼。

または回線のトラヒック属性、および通信品質に応じて
、そのトラヒック属性パラメータ値、およびサービスク
ラス値を決定して、呼または回線の設定要求時にそれら
の値を網に対して申告する。

〔発明が解決しようとするｌｌＩ題〕

第５図（ａ）（ｂ）は、それぞれ従来の網内リソース管
理方法の処理フローチャートであって、第５図（ａ）は
、高信頼度通信のために開発され、データ通信を対象と
するパケット交換方式（Ｘ、２５）における網内リソー
ス管理方法、第５図（ｂ）は、６４　Ｋｂ／ｓを基本と
する一定速度通信を前提にした回線交換方式における網
内リソース管理方法である。

第５図（ａ）においては、ユーザから呼接続要求がある
と（ステップ１）、呼設定フェーズ（２）で呼設定処理
（ステップ２１）を行った後、次の情報転送フェーズ（
３）に移り、ウィンドウフロー制御（ステップ３１）を
行う。ウィンドウフロー制御は、受信側のバッファの大
きさに応じて連続して受信できるパケット数（ウィンド
ウサイズ）により、送受信を制御する方法である。

数百ミリ秒程度の遅延時間を許容するパケット交換方式
では、情報転送フェーズにおいて、トラヒック負荷が増
大した場合には、遅延させることにより網内リソースの
有効利用を行っていた。すなわち、具体的には、ウィン
ドウフロ、−制御によりトラヒック負荷の時間的な均衡
化を図り、その結果、網内リソースの有効利用を図るこ
とができた。このパケット交換方式では、呼設定フェー
ズにおける呼レベルでのトラヒック管理、例えばトラヒ
ック状況の管理による呼接続の受付判断等の機能の導入
は行っていなかった。

次に、第５図（ｂ）において、呼接続要求があると（ス
テップ１）、呼設定フェーズ（２）で同時接続数等の管
理（ステップ２４）を行うことにより、呼の受付は判断
を行い（ステップ２３）、受理されたものについて呼接
続処理（ステップ２１）を行い、拒否されたものについ
ては呼損（２２）となっていた。呼接続処理（ステップ
２１）が行われたものについて、情報転送フェーズ（３
）ではフロー制御を行わず、ノーアクションであった。

このように、呼設定フェーズ（２）においては、同時接
続呼数の管理を行っており、特に過負荷における網内リ
ソース管理を実現してきた。このようなパケット交換方
式では、情報転送フェーズでのトラヒック管理機能は不
要であった。

低速から高速までの時間的な変動を伴うトラヒックを同
時に収容し、さらには、実時間通信要求、高信頼度通信
要求等の種々の通信品質を同時に満足させることを前提
とする通信網が提案されているが、未だに具体的な網内
リソース管理方法については考えられていない。ＣＣＩ
ＴＴ　　５ＧＸＶＩＩＩ　　１．　１２１においては、
網における網内リソース管理方法の大枠の規定があるだ
けである。具体的には、ユーザがバーストトラヒック属
性および要求品質クラスを申告することにより、網はそ
の値を基にして網内リソース管理を実現する必要がある
ことが規定されているのみである。その他の具体的な規
定、さらに具体的な網内リソースの管理方法については
未だ規定されていない。

本発明の目的は、このような従来の課題を解決し、マル
チメディア統合網、例えばＡＴＭ交換機において、低速
から高速までの種々の通信速度を持ち、時間的な変動を
伴うバーストトラヒックに対して、ユーザからの実時間
通信、高信頼度通信等の種々の通信品質の要求を同時に
満足させることが可能であり、かつ網内リソースを効率
的に運用することが可能な網内リソース管理方法を提供
することにある。

〔課題を解決するための手段〕

上記目的を達成するため１本発明の網内リソース管理方
法は、交換機、多重化装置およびクロスコネクトを含む
ノードと、該ノードおよびユーザ端末を結合する伝送路
を含むリンクにより構成され、該リンクおよびバッファ
等の網内リソースを共用し、呼接続ないし回線設定要求
時に、ユーザが申告するトラヒック属性値および通信品
質を表わすサービスクラス、ならびに網内リソース使用
状況に基づいて、各ノードが必要となるリソース量を導
出するパケット通信網において、該呼ないし回線をユー
ザが申告したトラヒック属性値とリンク容量から導かれ
る値で決まるクラス１およびクラス２に分離し、各ノー
ドは、呼接続ないし回線設定要求時にユーザが申告する
トラヒック属性値、サービスクラス、および上記呼ない
し回線の接続要求時点での網内使用リソース量をリンク
容量より減算して得られる空きリソース量を基に、上記
呼ないし回線の要求トラヒック属性と要求品質を満足さ
せるために必要なリソース量を導出し、該必要リソース
量が空きリソース量よりも大きい場合には上記呼を呼損
とし、該必要リソース量が空きリソース量より小さい場
合には、先ず上記接続要求呼ないし回線がクラス１かク
ラス２のどちらに属するかを、伝送路容量とユーザが申
告したトラヒック属性値により決定し、上記呼ないし回
線がクラス１の場合には呼接続処理ないし回線設定処理
に移行し、上記呼ないし回線がクラス２の場合には、リ
ンク容量に対して該呼ないし回線の要求品質を満足させ
るために必要なリソース量を導出し、該リソース量を割
り当てリソース量として、ノードが上記割り当てリソー
ス量を上記呼ないし回線用のリソースとして割り当て、
呼接続処理ないし回線設定処理に移行し、上記呼が呼切
断要求を行うか、上記回線が回線切断処理を行うまで、
上記割り当てリソース量を該呼ないし回線用として割り
当てておくことに特徴がある。

〔作　　用〕

本発明においては、種々の通信品質や通信速度を要求す
る通信メディアを効率的に収容できるマルチメディア統
合網、例えばＡＴＭ交換網において１通信中の全呼の各
々の通信品質を良好に保持し、かつ交換機リソースを有
効に運用することができるようにする。すなわち、本発
明の網内リソース管理方法では、ユーザが申告するトラ
ヒック属性を基にして網内リソース管理クラスに分離し
、クラス１呼のトラヒック量を観測するとともに、クラ
ス２呼の要求通信品質を満足できるだけの割り当て容量
を管理し、また要求呼に対して品質が満足できるだけの
容量が確保できるが否がを判断し、呼接続を受は付ける
が否がを判定する。呼接続を受理できる場合のクラス２
呼の必要帯域の確定的な割り当て機能を持つ。

請求項１は本発明の第１の実施例に、請求項２は第２の
実施例に、請求項３は第３の実施例に、請求項４は第４
の実施例に、また請求項５は第５の実施例に、それぞれ
対応している。

本発明を要約すると、（ｉ）制御クラスとして、統計的
な多重化効果が大きく期待できるクラス１と、多重化効
果が余り期待できないクラス２とを導入し、これらのク
ラス対応のリソース管理を行う。（ｎ）クラス１に属す
る呼のリソース管理は、観測値を基に行う。（■）クラ
ス２に属する呼のリソース管理は、その呼が要求する通
信品質を満足できるだけのリソース量を導出し、その量
を基に行う。（ｉｖ）ユーザが要求する通信品質を満足
させることができ、かつリソースの使用効率の向上を図
ることが可能な呼受付判定機能を設ける。

これにより、（イ）伝送路容量、バッファ容量等の網内
リソースを有効に利用することができる。

（ロ）網は、ユーザが要求する種々の通信品質を同時に
保証することができる。（ハ）本発明者が提案したが、
本発明とは別出願であるｒ網内リソース制御パラメータ
Ｊ、１＃！内リソース割り当て方法」、および「モニタ
リング方式Ｊを本発明と組み合わせることにより、この
効果をさらに向上させることが可能である。

〔実施例〕

以下、本発明の実施例を、図面により詳細に説明する。

第１図（ａ）は１本発明の第１の実施例を示す網内リソ
ース管理方法の処理フローチャートである。

本発明の網内リソース管理方法では、呼または回線をユ
ーザが申告したトラヒック属性値とリンク容量とから導
かれる値で決まるクラス１とクラス２に分離する。そし
て、呼接続ないし回線設定要求時点でのクラス１呼の使
用リソース量を、上記時点で同時接続されているクラス
１の呼および回線のトラヒック量と定義し、呼接続ない
し回線設定要求時点でのクラス２呼の使用リソース量を
、上記時点で同時接続されているクラス２の呼および回
線に対して、それぞれの設定時に決定された割り当てリ
ソース量の合計量と定義し、呼接続ないし回線設定時点
での上記クラス１呼の使用リソース量とクラス２呼の使
用リソース量の加算値を、上記時点での網内使用リソー
ス量と定義する。

また、本実施例のリソース管理プログラムは、次のサブ
ルーチンプログラムから構成される。すなわち、ユーザ
の申告値を基に呼接続要求時点での空きリソース量より
、呼受付判定基準値を導出するサブルーチン２５、上記
基準値と網内リソース使用状況により、呼接続要求に対
する受理判断を行うサブルーチン２３、クラス１または
２領域を判定するサブルーチン２６、割り当てるべき網
内リソース量を伝送路容量を基準として決定するサブル
ーチン２７、割り当てるべき網内リソース量を、呼接続
時点での空きリソース量を基準として決定するサブルー
チン２９．および割り当てられた網内リソース量を管理
するサブルーチン２８である。

第１図（ａ）において、交換機は呼接続要求を受けると
（ステップ１）、呼設定フェーズ（２）で、先ずユーザ
申告パラメータ値を基に、ステップ２３で行う接続要求
の受付可否判断を行うために必要となる基準値を導出す
る（ステップ２５）。なお。

基準値の導出方法については、前述の「網内リソース管
理パラメータ」（別途出願中）を参照されたい）。具体
的には、呼接続要求受信時における空きリソース量に対
して、要求呼を含む同時接続呼の要求品質を同時に満足
させるために必要となる要求呼に対する必要リソース量
を導出する。なお、必要リソース量の導出方法について
は、前述のｒ網内リソース割り当て方法」　（本願と同
日に出願）を参照されたい。この必要リソース量が、呼
接続時点での空きリソース量より大きい場合には、呼損
とする（ステップ２２）。一方、必要リソース量が空き
リソース量より小さい場合には、呼接続要求を受理して
、以下の処理手順に従って実行する（ステップ２３）。

すなわち、呼接続要求呼が上記ユーザ申告値を基に統計
的な多重化効果が十分に期待できるクラス１領域呼か、
あるいは統計的な多重化効果が期待できないクラス２領
域呼であるかを判断する（ステップ２６）。判断の結果
、接続要求呼がクラス１領域呼である場合、呼設定処理
を実行しくステップ２１）、情報転送フェーズ（３）に
移行する。

一方、呼がクラス２領域呼である場合には、伝送路容量
に対して、接続要求呼の品質を満足できるだけの網内リ
ソース量を導出し、その量をその接続要求呼の網内リソ
ースとして割り当てる（ステップ２７）。各ノードは、
呼が呼切断要求を行うまで、または回線が回線切断処理
を行うまで、割り当てリソース量を呼または回線用とし
て割り当てておく。なお、品質を満足できるだけの網内
リソース量を導出する方法は、別途出願中の前記ｒ網内
リソース割り当て方法」を参照されたい。

また１割り当て状況およびクラス１呼のトラヒック観測
値は、網内リソース管理サブルーチン（２８）により管
理されている。このリソース管理サブルーチン２８では
、情報転送フェーズ（３）のクラス１領域呼に対する網
内リソース使用状況の観測プログラム３２におけるトラ
ヒック観測値を常時管理している。本実施例では、以上
の動作を各交換機毎に独立して行う。

第１図（ｂ）は、本発明の第２の実施例を示す網内リソ
ース管理方法の処理フローチャートである。

第１図（ｂ）では、（ａ）の網内リソース割り当て処理
ステップ２７について、各交換機が管理するクラス２呼
に対する割り当てリソース量を、伝送路容量に対してで
はなく、呼接続要求時点での空きリソース量に対して、
接続要求呼の要求品質を保証できるだけの容量としてい
る（ステップ２９）。

すなわち、各ノードは、クラス２に属する呼または回線
に対する割り当てリソース量を、呼受付判定基準値つま
り必要リソース量と同じ値にしている。これ以外の処理
は、全て第１の実施例と同じである。

第１図（Ｑ）は１本発明の第３および第４の実施例を示
す網内リソース管理方法の処理フローチャートである。

また、第２図（ａ）は、第３の実施例における割り当て
リソース量の更新アルゴリズムを示す図である。

第３の実施例では、網内リソース管理プログラム２８に
関して、各交換機が管理するクラス２呼に対する割り当
てリソース量を呼接続要求時点毎に、または一定周期毎
のいずれかの時点系列における各々の時点での同時接続
呼に対して、使用可能リソース量Ｖという概念を導入す
る。先ず、第２図（ａ）に示すように、この使用可能リ
ソース量Ｖ値を伝送路容量■。と定義しくステップ１０
１）。

ユーザが申告したトラヒック属性値の最も大きな呼、例
えば申告ピークスルーブツト値の最も大きな呼に注目し
て（ｉ＝１．ｉ≦Ｎ）（ステップ１０２）、このＶ値に
対して呼の要求品質を満足させるために必要な割り当て
リソース量Ｒ０を決定する（ステップ１０３）。次に、
そのリソース量ＲｉをＶ値より減算した値を新たなＶ値
としくステップ１０４）、次にユーザが申告したトラヒ
ック属性値の２番目に大きな呼に注目して（ステップ１
０５，１０２）。

このＶ値に対して呼の要求品質を満足させるために必要
な割り当てリソース量を決定する（ステップ１０３）。

再び、そのリソース量Ｒ，をＶ値より減算した値を新た
なＶ値とし、以下、割り当てリソース量更新周期時点で
の同時接続呼の全てに対して、同じ処理を繰り返す。交
換機は、各呼に対して決定した割り当てリソース量を新
たな割り当てリソース量として更新・管理する。

このように、更新時点毎に、その時点での要求スループ
ット値の大きな呼、例えば要求ピークスループット値の
大きな呼から順番に、　ｉ’ＦＪり当でリソース量を決
定し直して行く。この処理を、簡単な例で説明する。い
ま、更新時点での同時接続呼数が５であった場合、この
中で要求スループット値の最も大きな呼、例えば要求ピ
ークスループット値が最も大きな呼Ｃ１に注目する。　
そして、先ず使用可能リソース量Ｖ（＝Ｖ、）に対して
、その呼Ｃ１の品質を満足させるために必要な割り当て
リソース量Ｒ工を決定し、Ｖ＝Ｖ−Ｒ□とする３次に、
２番目に大きな要求スループット値を有する呼Ｃ２に注
目して、このＶ値に対して呼Ｃ２の品質を満足させるた
めに必要な割り当てリソース量Ｒａを決定し、Ｖ＝Ｖ−
Ｒ２とする。次に、３番目に大きな要求スループット値
を有する呼Ｃ１に注目して、そのＶ値に対してその呼Ｃ
３の品質を満足させるために必要な割り当てリソース量
Ｒ２を決定し、Ｖ＝Ｖ−Ｒ，とする、残りの２呼に対し
ても、同じような処理を実行して、それらの処理で決定
された値Ｒ０〜Ｒｓ値を各々の呼に対する割り当てリソ
ース量として、交換機が管理するのである。

第１図（ｃ）および第２図（ｂ）は１本発明の第４の実
施例を示す網内リソース管理方法の処理フローチャート
である。

第４の実施例では、第３の実施例のように、使用可能リ
ソース量Ｖの更新を各呼毎に行うのではなく、同一スル
ープット特性を有するスループットクラス毎に更新を行
う、この更新のアルゴリズムを、第２図（ｂ）に示す。

すなわち、割り当てリソース量Ｒ工を決定した後（ステ
ップ２０３）、ＲＪ＝ＲＪ＋Ｒ□としくステップ２０４
）、次のスルーブツトクラスでなければ、■は前の値の
ままでｉのみを１だけインクリメントして再び必要なリ
ソース量Ｒ□を決定する（ステップ２０３）。なお、次
のスループットクラスであれば、　Ｖ＝Ｖ−ＲＪとし、
ｊを１だけインクリメントし、　Ｒ、＝　０とする（ス
テップ２０６）。

第１図（Ｃ）および第２図（ａ）（ｂ）は、本発明の第
５の実施例を示す網内リソース管理方法の処理フローチ
ャートでもある。

第５の実施例では、第３または第４の実施例において、
呼受付は判断を以下に示す手順により実行する。

接続要求呼または回線がクラス１の場合には、その呼ま
たは回線の接続要求時点での「呼受付判定基準量」が「
空きリソース量」より小さいとき呼接続要求を受理しく
ステップ２６．２１）、またそうでない場合には呼損と
する（ステップ２２）。

一方、接続要求呼または回線がクラス２の場合には、そ
の接続要求呼または回線を含むクラス２の呼または回線
に対して、Ｉｒ割当リソース量」を更新し、そのリソー
ス量の同時接続クラス２呼または回線の加算値であるｒ
クラス２呼の使用リソース量」とｒクラス１呼の使用リ
ソース量」の加算値が網内リソース量より小さいときに
は、呼接続要求を受理しくステップ２１）、そうでない
場合には呼損とする（ステップ２２）。

第３図（ａ）は、本発明の第６の実施例を示す網内リソ
ース管理方法の処理フローチャートである。

第６の実施例では、第１図（ａ）に示す第１の実施例に
おいて、全呼を、統計的な多重化効果が十分に期待でき
ないクラス２として扱った場合である。第３図（ａ）に
示すように、先ずユーザの申告値を基に呼接続要求時点
での空きリソース量より。

呼受付判定基準値を導出する（ステップ２５）。

次に、要求リソース量が呼接続時点での空きリソース量
より大きい場合には呼損とする（ステップ２３．２２）
、一方、要求リソース量が空きリソース量より小さい場
合には、呼接続要求を受は付けて、全ての呼が多重化効
果が期待できないクラス２であるため、網内リソースの
割り当て処理を行い（ステップ２７）、呼接続処理を行
う（ステップ２１）。そして、情報転送フェーズ（３）
で各種情報転送処理を行う（ステップ３３）。

すなわち、この実施例では、交換処理能力および伝送路
容量が、端末が要求するスループット値に対して十分に
大きくできない場合や、専用網的な使用を行う場合等に
おいて適用すれば、特に効果が大である。

第３図（ｂ）は、本発明の第７の実施例を示す網内リソ
ース管理方法の処理フローチャートである。

第３図（ｂ）の実施例で、第３図（ａ）と異なる点は、
各ノードが、クラス１に属する呼または回線に対する割
り当てリソース量を、呼受付判定基準値と同じ値にして
いる点である。それ以外は、全く同じ処理となる。

先ず、呼対応の割り当て量を導出しくステップ２５）１
次に、要求リソース量が呼接続時点での空きリソース量
より大きい場合には呼損とする（ステップ２３．２２）
。一方、要求リソース量が空きリソース量より小さい場
合には、呼接続要求を受は付けて、全ての呼が多重化効
果が期待できないクラス２であるため、網内リソースの
割り当て処理を行い（ステップ２７）、呼接続処理を行
う（ステップ２１）。そして、情報転送フェーズ（３）
で各種情報転送処理を行う（ステップ３３）、網内リソ
ース管理の処理（ステップ２８）も、第３図（ａ）と同
じである。

第３図（ｃ）は１本発明の第８の実施例を示す網内リソ
ース管理方法の処理フローチャートである。

この実施例においては、網内リソース管理プログラム２
８に関して、各交換機が管理するクラス２呼に対する割
り当てリソース量を呼接続要求時点毎に、または一定周
期毎のいずれかの時点系列における各々の時点での同時
接続呼に対して、使用可能リソース量Ｖという概念を導
入する。例えば、更新時点毎に、その時点での要求スル
ープット値の大きな呼、例えば要求ピークスルーグツ１
〜値の大きな呼から順番に、割り当てリソース量を決定
し直して行く。

次に、本発明の第９の実施例を説明する。この実施例は
、第１図（Ｑ）および第２図（ａ）（ｂ）を基にした第
５の実施例の応用となる網内リソース管理方法である。

第９の実施例では、第３または第４の実施例において、
呼受付は判断を以下に示す手順により実行する。

接続要求呼または回線の全呼を、クラス２として扱った
場合である。その接続要求呼または回線を含むクラス２
の呼または回線に対して、「割当リソース量Ｊを更新し
、そのリソース量の同時接続クラス２呼または回線の加
算値であるｒクラス２呼の使用リソース量Ｊが網内リソ
ース量より小さいときには、呼接続要求を受理し、そう
でない場合には呼損とする。

第４図は、本発明の第１０の実施例を示す網内リソース
管理方法である。

第１０実施例は、第１の実施例において、全呼を統計的
な多重化効果が十分に期待できるクラス１として扱った
場合の実施例である。

第４図において、交換機は呼接続要求を受けると（ステ
ップ１）、呼設定フェーズ（２）で、先ずユーザ申告パ
ラメータ値を基に、ステップ２３で行う接続要求の受付
可否判断を行うために必要となる基準値を導出する（ス
テップ２５）。具体的には。

呼接続要求受信時における空きリソース量に対して、要
求呼を含む同時接続呼の要求品質を同時に満足させるた
めに必要となる要求呼に対する必要リソース量を導出す
る。この必要リソース量が、呼接続時点での空きリソー
ス量より大きい場合には、呼損とする（ステップ２２）
。一方、必要リソース量が空きリソース量より小さい場
合には、呼接続要求を受理する（ステップ２３）。

次に、呼接続要求呼は全て上記ユーザ申告値を基に統計
的な多重化効果が十分に期待できるクラス１領域呼であ
るため、受理された呼接続要求は、呼設定処理を実行し
くステップ２１）、情報転送フェーズ（３）に移行する
。また、割り当て状況およびクラスｌ呼のトラヒック観
測値は、網内リソース管理サブルーチン（２８）により
管理されている。

このリソース管理サブルーチン２８では、情報転送フェ
ーズ（３）のクラス１領域呼に対する網内リソース使用
状況の観測プログラム３２におけるトラヒック観測値を
常時管理している。

この実施例では、交換機処理能力および伝送路容量が、
端末が要求するスルーブツトに対して十分に大きい場合
、あるいは入力トラヒラ特に規制を加える場合、例えば
、端末が要求するビークスループット値を伝送路容量の
数％程度に規制する場合、公衆網的な運用を行う場合等
に適用すれば、特にその効果が大である。また、本実施
例の場合には、複雑な制御を行う必要がなく、簡単な方
法で実現可能である。

〔発明の効果〕

以上説明したように、本発明によれば、種々の属性を持
つバーストトラヒックに対して、伝送路容量やバッファ
容量等の網内リソースを有効に利用することができ、か
つ網は、ユーザからの種々の要求品質を同時に保証する
ことが可能である。

【図面の簡単な説明】

第１図は本発明の第１〜第４の実施例を示す網内リソー
ス管理方法の処理フローチャート、第２図は第３および
第４の実施例における割り当てリソース量の更新アルゴ
リズムを示すフローチャート、第３図は本発明の第６〜
第８の実施例を示す網内リソース管理方法の処理フロー
チャート、第４図は本発明の第１０の実施例を示す網内
リソース管理方法の処理フローチャート、第５図は従来
のパケット交換方式および回線交換方式の網内リソース
管理方法の処理フローチャートである。 ■＝呼接続要求ブロック、２：呼設定フロー制御ブロッ
ク、３：情報転送フェーズブロック、２１：呼設定処理
、２２：呼損処理、２３：呼受付判断処理、２４：同時
接続呼数の管理、２５：呼受付判定基準値の導出処理、
２６：クラス１／２領域識別処理、２７：要求品質を保
証できるだけの網内リソース割り岩で量を伝送路容量を
基準値として導出する処理、２８：網内リソース管理、
２９：リソース割り当て比率より導出する処理、３１：
ウィンドウフロー制御処理、３２：クラス１領域呼に対
する網内リソース使用状況の観測処理、３３：各種情ｆ
ｉ１転送フェーズ。

Claims (5)

【特許請求の範囲】
1. （１）交換機、多重化装置およびクロスコネクトを含む
   ノードと、該ノードおよびユーザ端末を結合する伝送路
   を含むリンクにより構成され、該リンクおよびバッファ
   を含む網内リソースを共用し、呼接続ないし回線設定要
   求時に、ユーザが申告するトラヒック属性値および通信
   品質を表わすサービスクラス、ならびに網内リソース使
   用状況に基づいて、各ノードが必要となるリソース量を
   導出するパケット通信網において、該呼ないし回線をユ
   ーザが申告したトラヒック属性値とリンク容量から導か
   れる値で決まるクラス１およびクラス２に分離し、各ノ
   ードは、呼接続ないし回線設定要求時にユーザが申告す
   るトラヒック属性値、サービスクラス、および上記呼な
   いし回線の接続要求時点での網内使用リソース量をリン
   ク容量より減算して得られる空きリソース量を基に、上
   記呼ないし回線の要求トラヒック属性と要求品質を満足
   させるために必要なリソース量を導出し、該必要リソー
   ス量が空きリソース量よりも大きい場合には上記呼を呼
   損とし、該必要リソース量が空きリソース量より小さい
   場合には、先ず上記接続要求呼ないし回線がクラス１か
   クラス２のどちらに属するかを、伝送路容量とユーザが
   申告したトラヒック属性値により決定し、上記呼ないし
   回線がクラス１の場合には呼接続処理ないし回線設定処
   理に移行し、上記呼ないし回線がクラス２の場合に、は
   、リンク容量に対して該呼ないし回線の要求品質を満足
   させるために必要なリソース量を導出し、該リソース量
   を割り当てリソース量として、ノードが上記割り当てリ
   ソース量を上記呼ないし回線用のリソースとして割り当
   て、呼接続処理ないし回線設定処理に移行し、上記呼が
   呼切断要求を行うか、上記回線が回線切断処理を行うま
   で、上記割り当てリソース量を該呼ないし回線用として
   割り当てておくことを特徴とする網内リソース管理方法
   。
2. （２）請求項１記載の網内リソース管理方法において、
   各ノードは、クラス２に属する呼ないし回線に対する割
   り当てリソース量を、前記必要リソース量と同じ値にす
   ることを特徴とする網内リソース管理方法。
3. （３）請求項１または２記載の網内リソース管理方法に
   おいて、各ノードは、クラス２に属する呼ないし回線の
   割り当てリソース量を、呼ないし回線設定時に決定した
   後、該リソース量の割り当てを呼切断時まで継続させず
   、使用可能リソース量Ｖを導入して、該Ｖの初期値をリ
   ンク容量Ｖ＿０とし、呼ないし回線接続要求時点ごとか
   、予め定めた周期ごとに、該時点ごとの同時接続呼ない
   し同時接続回線に対して、ユーザが申告したトラヒック
   属性値の最も大きな呼ないし回線に注目して、上記Ｖ＿
   ０値に対して該呼ないし回線の要求品質を満足させるた
   めに必要な割り当てリソース量を決定し、該値を該呼な
   いし回線の割り当てリソース量の更新値とし、さらに該
   値をＶ値より減算した値を新たなＶ値とし、次にユーザ
   が申告したトラヒック属性値の２番目に大きな呼ないし
   回線に注目して、該Ｖ値に対して該呼ないし回線の要求
   品質を満足させるために必要な割り当てリソース量を決
   定して、該値を該呼ないし回線の割り当てリソース量の
   更新値とし、さらに該値をＶ値より減算した値を新たな
   Ｖ値とし、以下、該時点までのクラス２の同時接続呼な
   いし同時接続回線の全てに対して同じ処理を繰り返すこ
   とにより、全ての割り当てリソース量を更新し、各ノー
   ドは更新されたクラス２の呼ないし回線の割り当てリソ
   ース量を用いて制御することを特徴とする網内リソース
   管理方法。
4. （４）請求項３記載の網内リソース管理方法において、
   ユーザが申告するトラヒック属性に複数のクラスに分離
   されたスループットクラスの概念を導入し、クラス２の
   呼ないし回線ごとに前記使用可能リソース量Ｖを更新す
   ることなく、上記スループットクラスごとに該使用可能
   リソース量Ｖを更新することを特徴とする網内リソース
   管理方法。
5. （５）請求項３または４記載の網内リソース管理方法に
   おいて、接続要求呼ないし回線がクラス１の場合には、
   該呼ないし回線の接続要求時点での必要リソース量が空
   きリソース量より小さいとき、呼接続要求を受理し、必
   要リソース量が空きリソース量より大きいとき呼損とし
   、接続要求呼ないし回線がクラス２の場合には、該接続
   要求呼ないし回線を含むクラス２の呼ないし回線に対し
   て、割り当てリソース量を更新し、該割り当てリソース
   量の同時接続クラス２呼ないし回線の加算値であるクラ
   ス２呼の使用リソース量とクラス１呼の使用リソース量
   の加算値が網内リソース量より小さい場合には、呼接続
   要求を受理し、網内リソース量より大きい場合には呼損
   とすることを特徴とする網内リソース管理方法。